From: Mark Brown <broonie@kernel.org>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Takashi Iwai <tiwai@suse.com>, Daniel Mack <daniel@zonque.org>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Jaroslav Kysela <perex@perex.cz>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org,
patches@opensource.wolfsonmicro.com
Subject: Re: [RFC PATCH v2 0/7] AC97 device/driver model revamp
Date: Wed, 24 Aug 2016 12:39:53 +0100 [thread overview]
Message-ID: <20160824113953.GF22076@sirena.org.uk> (raw)
In-Reply-To: <87twebphh4.fsf@belgarion.home>
[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]
On Tue, Aug 23, 2016 at 06:39:35PM +0200, Robert Jarzmik wrote:
> In the old ac97 bus, the match function was always returning "true", and the
> driver did probe. With this new implementation, the ac97 is discovered and
> sound/soc/codecs/wm9713.c#wm9713_ac97_probe() is called. I don't export
> ac97_bus_type (nor want to do it), and only _one_ device is created upon
> discovery, while the wm97xx-core.c would benefic a second ac97 device.
> I'm wondering how to work around this :
> - either I add a wm97xx-ts ac97 device in wm9713_ac97_probe()
> - or I add a platform device in wm9713_ac97_probe() and add a new
> platform_driver in wm97xx-core ...
> - or something smarter
That device really should be a MFD.
> What's behind this question is : should I keep to my initial solution of 1 ac97
> device discovered is bound on the ac97 to _at most_ 1 ac97 driver, or is there a
> know smart way to have several drivers for one device (that sounds a bit heretic
> regarding my understanding of the device/driver model but who knows ...) ?
MFDs are how we do multiple drivers per device.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
patches@opensource.wolfsonmicro.com,
Liam Girdwood <lgirdwood@gmail.com>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
Takashi Iwai <tiwai@suse.com>, Daniel Mack <daniel@zonque.org>,
Jaroslav Kysela <perex@perex.cz>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 0/7] AC97 device/driver model revamp
Date: Wed, 24 Aug 2016 12:39:53 +0100 [thread overview]
Message-ID: <20160824113953.GF22076@sirena.org.uk> (raw)
In-Reply-To: <87twebphh4.fsf@belgarion.home>
[-- Attachment #1.1: Type: text/plain, Size: 1098 bytes --]
On Tue, Aug 23, 2016 at 06:39:35PM +0200, Robert Jarzmik wrote:
> In the old ac97 bus, the match function was always returning "true", and the
> driver did probe. With this new implementation, the ac97 is discovered and
> sound/soc/codecs/wm9713.c#wm9713_ac97_probe() is called. I don't export
> ac97_bus_type (nor want to do it), and only _one_ device is created upon
> discovery, while the wm97xx-core.c would benefic a second ac97 device.
> I'm wondering how to work around this :
> - either I add a wm97xx-ts ac97 device in wm9713_ac97_probe()
> - or I add a platform device in wm9713_ac97_probe() and add a new
> platform_driver in wm97xx-core ...
> - or something smarter
That device really should be a MFD.
> What's behind this question is : should I keep to my initial solution of 1 ac97
> device discovered is bound on the ac97 to _at most_ 1 ac97 driver, or is there a
> know smart way to have several drivers for one device (that sounds a bit heretic
> regarding my understanding of the device/driver model but who knows ...) ?
MFDs are how we do multiple drivers per device.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: broonie@kernel.org (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 0/7] AC97 device/driver model revamp
Date: Wed, 24 Aug 2016 12:39:53 +0100 [thread overview]
Message-ID: <20160824113953.GF22076@sirena.org.uk> (raw)
In-Reply-To: <87twebphh4.fsf@belgarion.home>
On Tue, Aug 23, 2016 at 06:39:35PM +0200, Robert Jarzmik wrote:
> In the old ac97 bus, the match function was always returning "true", and the
> driver did probe. With this new implementation, the ac97 is discovered and
> sound/soc/codecs/wm9713.c#wm9713_ac97_probe() is called. I don't export
> ac97_bus_type (nor want to do it), and only _one_ device is created upon
> discovery, while the wm97xx-core.c would benefic a second ac97 device.
> I'm wondering how to work around this :
> - either I add a wm97xx-ts ac97 device in wm9713_ac97_probe()
> - or I add a platform device in wm9713_ac97_probe() and add a new
> platform_driver in wm97xx-core ...
> - or something smarter
That device really should be a MFD.
> What's behind this question is : should I keep to my initial solution of 1 ac97
> device discovered is bound on the ac97 to _at most_ 1 ac97 driver, or is there a
> know smart way to have several drivers for one device (that sounds a bit heretic
> regarding my understanding of the device/driver model but who knows ...) ?
MFDs are how we do multiple drivers per device.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160824/63a791a6/attachment-0001.sig>
next prev parent reply other threads:[~2016-08-24 12:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 20:26 [RFC PATCH v2 0/7] AC97 device/driver model revamp Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 1/7] ALSA: ac97: split out the generic ac97 registers Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 2/7] ALSA: ac97: add an ac97 bus Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 3/7] ASoC: add new ac97 bus support Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 4/7] ASoC: wm9713: add ac97 new " Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 5/7] ASoC: pxa: switch to new ac97 " Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 6/7] ARM: pxa: mioa701 convert to the new AC97 bus Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 7/7] ASoC: mioa701_wm9713: convert to new ac97 bus Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-05-27 20:26 ` Robert Jarzmik
2016-08-23 16:39 ` [RFC PATCH v2 0/7] AC97 device/driver model revamp Robert Jarzmik
2016-08-23 16:39 ` Robert Jarzmik
2016-08-23 16:39 ` Robert Jarzmik
2016-08-24 11:39 ` Mark Brown [this message]
2016-08-24 11:39 ` Mark Brown
2016-08-24 11:39 ` Mark Brown
2016-08-29 7:49 ` Robert Jarzmik
2016-08-29 7:49 ` Robert Jarzmik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160824113953.GF22076@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=daniel@zonque.org \
--cc=haojian.zhuang@gmail.com \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
--cc=perex@perex.cz \
--cc=robert.jarzmik@free.fr \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.