public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Jarzmik <robert.jarzmik@free.fr>
To: Mark Brown <broonie@kernel.org>
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: Mon, 29 Aug 2016 09:49:13 +0200	[thread overview]
Message-ID: <87mvjwdngm.fsf@belgarion.home> (raw)
In-Reply-To: <20160824113953.GF22076@sirena.org.uk> (Mark Brown's message of "Wed, 24 Aug 2016 12:39:53 +0100")

Mark Brown <broonie@kernel.org> writes:

> 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.

Ok Mark, I took the bait and implemented it in
https://github.com/rjarzmik/linux/commits/work/ac97, and more specifically in :
  https://github.com/rjarzmik/linux/commit/4689ab3085b6e3959c873b4aa6dc4bc94ca5fd5c
  https://github.com/rjarzmik/linux/commit/152d57d535070871e401fab512b9babdcda9a545
  https://github.com/rjarzmik/linux/commit/903569ff077d1ea992dfc69d2f3014ce0d10fa99

I didn't send the patches for review yet as I face another kind of problem.
I converted wm9713 to an mfd device :
 - with a core in drivers/mfd
 - a codec in drivers/sound/soc/codec
 - a touchscreen in drivers/input/touchscreen
 - a battery in drivers/power/

The remaining problem is the lack of possibility to "customize" through
platform_data, which impact wm97xx_battery.c.
The reason of this is that :
 - the core in driver/mfd is "autoprobed" by the ac97 discovery mecanism
   As such, it has no platform data
 - the battery in drivers/power/wm97xx_battery.c will have its device spawned
   from the core and any platform data from it.

As you probably know wm97xx_battery needs platform data to be properly set up,
and unless I add a special "glue" in the ac97 device to provide this data I see
no other option. Would you think of something better ?

Actually the wm97xx could be even further improved by "offering" an ADC API the
battery driver could be bound to and consume just as regulators are, but that's
probably not worth it for only one old driver.

I'll post the serie within this week.

-- 
Robert

      reply	other threads:[~2016-08-29  7:49 UTC|newest]

Thread overview: 11+ 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 ` [RFC PATCH v2 1/7] ALSA: ac97: split out the generic ac97 registers 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 ` [RFC PATCH v2 3/7] ASoC: add new ac97 bus support Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 4/7] ASoC: wm9713: add ac97 new " 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 ` [RFC PATCH v2 6/7] ARM: pxa: mioa701 convert to the new AC97 bus Robert Jarzmik
2016-05-27 20:26 ` [RFC PATCH v2 7/7] ASoC: mioa701_wm9713: convert to new ac97 bus Robert Jarzmik
2016-08-23 16:39 ` [RFC PATCH v2 0/7] AC97 device/driver model revamp Robert Jarzmik
2016-08-24 11:39   ` Mark Brown
2016-08-29  7:49     ` Robert Jarzmik [this message]

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=87mvjwdngm.fsf@belgarion.home \
    --to=robert.jarzmik@free.fr \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox