| Message ID | 1455979079-9030-1-git-send-email-robert.jarzmik@free.fr (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Feb 20, 2016 at 03:37:56PM +0100, Robert Jarzmik wrote: > +WM9713 audio CODEC > + > +This devices supports I2C. No, it clearly doesn't... The problem with doing this is that since AC'97 is an enumerable bus we really shouldn't need to list AC'97 CODECs in the device tree. Instead we should be probing at runtime (as the non-ASoC AC'97 code does) or something similar.
Mark Brown <broonie@kernel.org> writes: > On Sat, Feb 20, 2016 at 03:37:56PM +0100, Robert Jarzmik wrote: > >> +WM9713 audio CODEC >> + >> +This devices supports I2C. > > No, it clearly doesn't... Right, it supports AC97. > The problem with doing this is that since AC'97 is an enumerable bus we really > shouldn't need to list AC'97 CODECs in the device tree. Ok, I understand that. > Instead we should be probing at runtime (as the non-ASoC AC'97 code does) or > something similar. When you say "non-ASoC AC'97 code", which file are you referring to ? Is it sound/pci/ac97/ac97_codec.c ? If so is there already a table of tuples (AC97_VENDOR_ID1, AC97_VENDOR_ID2) -> (platform device, platform device data) and a matching mechanism already available to the ASoC drivers ? Cheers.
On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote: > Mark Brown <broonie@kernel.org> writes: > > Instead we should be probing at runtime (as the non-ASoC AC'97 code does) or > > something similar. > When you say "non-ASoC AC'97 code", which file are you referring to ? Is it > sound/pci/ac97/ac97_codec.c ? Yes. > If so is there already a table of tuples (AC97_VENDOR_ID1, AC97_VENDOR_ID2) -> > (platform device, platform device data) and a matching mechanism already > available to the ASoC drivers ? ASoC doesn't really support the enumeration very well, you can use ac97.c as the CODEC but that's about it. There is a generic AC'97 PXA driver in sound/arm, if your system can use that that'd be a better route to DT integration for it I think. Did you try that, if there are problems with that perhaps we can improve that driver, it should be simpler.
Mark Brown <broonie@kernel.org> writes: > On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote: >> Mark Brown <broonie@kernel.org> writes: Removed DT people from this conversation. >> > Instead we should be probing at runtime (as the non-ASoC AC'97 code does) or >> > something similar. > >> When you say "non-ASoC AC'97 code", which file are you referring to ? Is it >> sound/pci/ac97/ac97_codec.c ? > > Yes. > >> If so is there already a table of tuples (AC97_VENDOR_ID1, AC97_VENDOR_ID2) -> >> (platform device, platform device data) and a matching mechanism already >> available to the ASoC drivers ? > > ASoC doesn't really support the enumeration very well, you can use > ac97.c as the CODEC but that's about it. > There is a generic AC'97 PXA driver in sound/arm, if your system can use that > that'd be a better route to DT integration for it I think. I'm open on the topic. Historically, I use sound/soc/pxa/pxa2xx-ac97.c since 2008. I know it works, but if you think I should examine sound/arm/pxa2xx-ac97.c, let's do that. > Did you try that, if there are problems with that perhaps we can improve that > driver, it should be simpler. I will. By now I fail to see how this will help in the wm9713 probing and detection ... Until I make the try, here is what I have as a device-tree extract in [1], which is my candidate for sound/soc/pxa/zylonite.c replacement.. If we conclude that wm9713 shouldn't be in device-tree, then I'm curious how the DAI bindings (simple-audio-card,dai-link*) should be handled. Cheers.
On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote: > Mark Brown <broonie@kernel.org> writes: > > On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > > There is a generic AC'97 PXA driver in sound/arm, if your system can use that > > that'd be a better route to DT integration for it I think. > I'm open on the topic. > Historically, I use sound/soc/pxa/pxa2xx-ac97.c since 2008. I know it works, but > if you think I should examine sound/arm/pxa2xx-ac97.c, let's do that. > > > Did you try that, if there are problems with that perhaps we can improve that > > driver, it should be simpler. > I will. By now I fail to see how this will help in the wm9713 probing and > detection ... It will eumerate the AC'97 bus by itself and does not need the CODEC to be described. > Until I make the try, here is what I have as a device-tree extract in [1], which > is my candidate for sound/soc/pxa/zylonite.c replacement.. If we conclude that > wm9713 shouldn't be in device-tree, then I'm curious how the DAI bindings > (simple-audio-card,dai-link*) should be handled. They should be created as a function of enumerating the CODEC. If you use the genric AC'97 stuff it doesn't use ASoC at all and this happens as a side effect.
Mark Brown <broonie@kernel.org> writes: > On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote: >> Mark Brown <broonie@kernel.org> writes: >> > On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote: >> I will. By now I fail to see how this will help in the wm9713 probing and >> detection ... > > It will eumerate the AC'97 bus by itself and does not need the CODEC to > be described. I think I still don't get it. So let's rephrase it another way : how will the function wm9713_probe() be called, ie. what is the possible function backtrace leading to that call ? >> Until I make the try, here is what I have as a device-tree extract in [1], >> which is my candidate for sound/soc/pxa/zylonite.c replacement.. If we >> conclude that wm9713 shouldn't be in device-tree, then I'm curious how the >> DAI bindings (simple-audio-card,dai-link*) should be handled. > > They should be created as a function of enumerating the CODEC. If you > use the genric AC'97 stuff it doesn't use ASoC at all and this happens > as a side effect. I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI specific, not generic, so what is "generic AC'97 stuff" ? I will never be able to use it as on my platforms CONFIG_PCI=n. Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I can have a look at to understand ? Cheers.
On Sat, Feb 20, 2016 at 11:24:02PM +0100, Robert Jarzmik wrote: Please fix your mail client to word wrap within paragraphs at something substantially less than 80 columns. Doing this makes your messages much easier to read and reply to. > Mark Brown <broonie@kernel.org> writes: > > On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote: > > It will eumerate the AC'97 bus by itself and does not need the CODEC to > > be described. > I think I still don't get it. > So let's rephrase it another way : how will the function wm9713_probe() be > called, ie. what is the possible function backtrace leading to that call ? It will not be called, the generic AC'97 code will be used. > > They should be created as a function of enumerating the CODEC. If you > > use the genric AC'97 stuff it doesn't use ASoC at all and this happens > > as a side effect. > I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI specific, > not generic, so what is "generic AC'97 stuff" ? I will never be able to use it > as on my platforms CONFIG_PCI=n. That is the generic code, there is no PCI dependency. > Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I > can have a look at to understand ? Some Atmel boards do this IIRC, as does the AACI driver (via AMBA but same effect).
Mark Brown <broonie@kernel.org> writes: >> > It will eumerate the AC'97 bus by itself and does not need the CODEC to >> > be described. > >> I think I still don't get it. > >> So let's rephrase it another way : how will the function wm9713_probe() be >> called, ie. what is the possible function backtrace leading to that call ? > > It will not be called, the generic AC'97 code will be used. Ok, if it's not called no code in sound/soc/codecs/wm9713.c will be used, right ? In that case wm9713_set_dai_clkdiv() will never be used, nor will the wm9713_audio_map or wm9713_dapm_widgets be created, which will break all userspace programs relying on these mixers and DAPM routes. Or am I missing something ? >> Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I >> can have a look at to understand ? > > Some Atmel boards do this IIRC, as does the AACI driver (via AMBA but > same effect). I suppose you mean sound/arm/aaci.c, which is more a platform_data like driver (if I understood the integrator code correctly). I suppose we can achieve comparable result with sound/arm/pxa2xx-ac97.c, but as to know if the functionality will be comparable to sound/soc/pxa/pxa2xx-ac97.c, it's hard to say. If I count the DMA requestors, I see 5 in the sound/soc version, and 2 in sound/arm. That makes me believe the sound/arm version is inferior. Cheers.
On Fri, Feb 26, 2016 at 02:33:49AM +0100, Robert Jarzmik wrote: > Mark Brown <broonie@kernel.org> writes: > > It will not be called, the generic AC'97 code will be used. > Ok, if it's not called no code in sound/soc/codecs/wm9713.c will be used, right > ? > In that case wm9713_set_dai_clkdiv() will never be used, nor will the > wm9713_audio_map or wm9713_dapm_widgets be created, which will break all > userspace programs relying on these mixers and DAPM routes. > Or am I missing something ? No, you're not missing anything - that'll be what happens. If you need to preserve the userspace ABI on your board you'd need a much bigger (but very welcome) refactoring of the AC'97 code to be less hacky and use the device model more directly, or at least define a generic AC'97 binding somehow. All the AC'97 support has never really been properly moved over to the device model and unfortunately nobody's yet cared about it for device tree except in the simple cases supported by the generic AC'97 code. I appreciate that this isn't very helpful, it's an unfortunate consequence of DT as an ABI. We probably want to end up with something like what the Intel folks have been doing recently for HDA to get that working within ASoC.
Mark Brown <broonie@kernel.org> writes: > On Fri, Feb 26, 2016 at 02:33:49AM +0100, Robert Jarzmik wrote: >> Mark Brown <broonie@kernel.org> writes: > >> > It will not be called, the generic AC'97 code will be used. > >> Ok, if it's not called no code in sound/soc/codecs/wm9713.c will be used, right >> ? >> In that case wm9713_set_dai_clkdiv() will never be used, nor will the >> wm9713_audio_map or wm9713_dapm_widgets be created, which will break all >> userspace programs relying on these mixers and DAPM routes. > >> Or am I missing something ? > > No, you're not missing anything - that'll be what happens. If you need > to preserve the userspace ABI on your board you'd need a much bigger > (but very welcome) refactoring of the AC'97 code to be less hacky and > use the device model more directly, or at least define a generic AC'97 > binding somehow. All the AC'97 support has never really been properly > moved over to the device model and unfortunately nobody's yet cared > about it for device tree except in the simple cases supported by the > generic AC'97 code. I appreciate that this isn't very helpful, it's > an unfortunate consequence of DT as an ABI. > > We probably want to end up with something like what the Intel folks have > been doing recently for HDA to get that working within ASoC. Ok, let me think about it and propose something, an approach. I must admit I like the structure I saw in drivers/amba/bus.c, ie. to have something like : - a bus driver core (sound/ac97/bus.c ?) Split between this and sound/pci/ac97_codec.c I don't know yet. => an instance of this bus will be instanciated from each snd_ac97_bus() call just as now => bus_register(&ac97_bustype) => ac97_bus_probe/remove(), match/uevent/dev_attrs => ac97_driver_register(struct ac97_driver *drv) - a ac97 driver structure (struct ac97_driver) with : => u32 vendor_id (vendor_id = lambda(vendor_id1, vendor_id2)) => u32 vendor_id_mask (mask of bits to match) ... - each ac97 controller will call snd_ac97_bus(). In my case, that's sound/arm/pxa2xx-ac97.c or sound/soc/pxa2xx-ac97.c, whatever. - each ac97 codec will subscribe to the bus ac97_driver_register(struct ac97_driver *drv, u32 vendor_id, u32 vendor_mask) For example wm9713.c will call : ac97_driver_register(drv, AC97_VENDOR(0x...., 0x....), 0xffffffff); Well, if I'm totally mistaken, tell me. If not it will take me a bit of time to write is down properly in a Documentation/ file. Cheers.
On Fri, Feb 26, 2016 at 10:04:15PM +0100, Robert Jarzmik wrote: > Ok, let me think about it and propose something, an approach. > I must admit I like the structure I saw in drivers/amba/bus.c, ie. to have > something like : ... > Well, if I'm totally mistaken, tell me. If not it will take me a bit of time to > write is down properly in a Documentation/ file. That seems pretty reasonable at first pass I think, the main issue is just managing the transition safely for all the users. There's a lot of fragility in the AC'97 hardware and software so people have been very reluctant to touch it. Equally I think a lot of the more problematic users probably aren't in use any more so you can probably get away with more now than would have been the case in the past.
diff --git a/Documentation/devicetree/bindings/sound/wm9713.txt b/Documentation/devicetree/bindings/sound/wm9713.txt new file mode 100644 index 000000000000..761001bc3201 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wm9713.txt @@ -0,0 +1,14 @@ +WM9713 audio CODEC + +This devices supports I2C. + +Required properties: + - compatible : + "wlf,wm9713" + +Example: + wm9713: wm9713@0 { + compatible = "wlf,wm9713"; + #sound-dai-cells = <1>; + status = "okay"; + };
This adds a binding for the Wolfson WM9713 audio codec. Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr> --- Documentation/devicetree/bindings/sound/wm9713.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/wm9713.txt