ASoC: Device tree binding to dummy codec

ASoC: Device tree binding to dummy codec

[jonsmirl]

Allwinner CPUs have an on-chip codec that supports line out. This is a
monolithic block that does not implement anything like standard I2S.
We have implemented this by internally making a soc_card and then
binding the DAI to a dummy NOP codec to make ASoC happy.

But now someone wants to add a MAX9768 amplifier which needs a codec
driver to implement volume control.

So how should this be implemented? You want to use simple-audio-card
when the MAX9768 is present.

But what about the dummy-codec case? Using simple-audio-card to bind
to a dummy-codec clutters things up a lot. Plus the dummy-codec is not
currently exposed to device trees.

And then there is the ordering problem, how do I know for sure MAX9768
is not going to be bound so that it is safe to bind to dummy-codec.
Or should binding to MAX9768 simply override a binding to the
dummy-codec?

If my dummy-codec is exposed into the device trees then this generates
a bunch of NOP clutter in the tree using simple-audio-card to bind it.

Another idea, maybe one of those NOP SDPIF codecs could get an alias
name like NOP or Dummy.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: ASoC: Device tree binding to dummy codec

[Lars-Peter Clausen]

Cc ASoC maintainers.

On 07/26/2014 05:18 PM, jonsmirl@gmail.com wrote:
> Allwinner CPUs have an on-chip codec that supports line out. This is a
> monolithic block that does not implement anything like standard I2S.
> We have implemented this by internally making a soc_card and then
> binding the DAI to a dummy NOP codec to make ASoC happy.
>
> But now someone wants to add a MAX9768 amplifier which needs a codec
> driver to implement volume control.
>
> So how should this be implemented? You want to use simple-audio-card
> when the MAX9768 is present.
>
> But what about the dummy-codec case? Using simple-audio-card to bind
> to a dummy-codec clutters things up a lot. Plus the dummy-codec is not
> currently exposed to device trees.
>
> And then there is the ordering problem, how do I know for sure MAX9768
> is not going to be bound so that it is safe to bind to dummy-codec.
> Or should binding to MAX9768 simply override a binding to the
> dummy-codec?
>
> If my dummy-codec is exposed into the device trees then this generates
> a bunch of NOP clutter in the tree using simple-audio-card to bind it.
>
> Another idea, maybe one of those NOP SDPIF codecs could get an alias
> name like NOP or Dummy.

Hi,

The dummy CODEC is a ASoC specific software construct, it should not appear 
in the description of the hardware. The reason why ASoC requires CODEC for 
successfully instantiate is due its history. When ASoC was initially 
designed and implemented your typical embedded audio system had 3 main 
components, the DMA, the I2C or AC97 CPU DAI and the CODEC with the CODEC 
DAI. And while the ASoC framework as gained support for more configurations 
over the years the basic requirement that at least one CODEC is present in 
the system has remained. So the correct solution in this case is to adopt 
the framework so it can properly support this new class of device it was 
previously not designed to handle. I've been working on removing the 
requirement that at least one CODEC needs to be present in the system by 
moving the abstraction level in the ASoC core to snd_soc_component level. 
This is mostly done and the final missing pieces are scheduled for 
submission after the next merge window closes.

While this restructuring allows for CODEC-less systems, it does not allow 
for DAI-less systems yet. At least if you want to have a PCM device. To 
properly support DAI-less systems 3 major pieces are missing:
* Currently the DAIs are entry and exit points of the PCM streams into the 
DAPM graph. This needs to be reworked so that there is a native 
representation of the PCM device in the DAPM graph which is used as the 
entry and exit point instead.
* Support for creating a PCM device without specifying a DAI link. Right now 
the only way in ASoC to create a PCM device is by having a DAI link. For 
systems without DAIs and DAI links we need an alternative. Preferably the 
driver for the on-chip CODEC should be able to create the PCM device itself 
since it is basically embedded in its hardware.
* Proper devicetree bindings for this kind of devices

- Lars

Re: ASoC: Device tree binding to dummy codec

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 2408 bytes --]

On Mon, Jul 28, 2014 at 08:24:39AM +0200, Lars-Peter Clausen wrote:
> Cc ASoC maintainers.

Jon, you should really know to CC maintainers.

> > So how should this be implemented? You want to use simple-audio-card
> > when the MAX9768 is present.

You do - why?  It's not immediately obvious to me that this fits well,
there's a good reason why lots of the functionality there is done as a
library...

> While this restructuring allows for CODEC-less systems, it does not allow
> for DAI-less systems yet. At least if you want to have a PCM device. To
> properly support DAI-less systems 3 major pieces are missing:

To be honest I don't see a great need to remove the requirement for a
DAI - even with the CODEC baked into the SoC there will often be some
form of IP separation and the stubbing isn't really the blocker to
supporting anything.

> * Support for creating a PCM device without specifying a DAI link. Right now
> the only way in ASoC to create a PCM device is by having a DAI link. For
> systems without DAIs and DAI links we need an alternative. Preferably the
> driver for the on-chip CODEC should be able to create the PCM device itself
> since it is basically embedded in its hardware.

Another and probably simpler way of approaching this is to allow more
than one thing in the card to provide DAI links.  That meshes better
with DPCM as it stands and sidesteps the need to deal with carrying
digital stream configuration information through DAPM which is where you
end up otherwise since you really want DPCM systems to be able to behave
in a similar way.

A good proportion of these systems do actually seem to have physical I2S
interfaces as well to allow people to change up to a better CODEC if
they want so might actually want to be DPCM systems really.

> * Proper devicetree bindings for this kind of devices

What bindings would we have?  It should be transparent to device tree
since shouldn't be representing the internals of devices in the device
tree, that's redundant and adds to complication.  For device tree we
just want the external connection points of each device to be visible
and that's already handled.

What we do want is better support for building the card up from multiple
sources of data so that all the in-SoC stuff can be done by the drivers
for the components in the SoC instead of requring bits of it to be in
the machine driver as we do curently with DPCM.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC: Device tree binding to dummy codec

[jonsmirl]

On Mon, Jul 28, 2014 at 7:20 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jul 28, 2014 at 08:24:39AM +0200, Lars-Peter Clausen wrote:
>> Cc ASoC maintainers.
>
> Jon, you should really know to CC maintainers.

Are the all CC'd now? I thought the ALSA list was sufficient.

So how do I set this hardware up?

on-chip codec - it is ADC/DAC with FIFIO directly attached. There is
no separate bus. on-chip codec supports things like mic1, mic2, line
in, line out, hp out. Most boards populate only a subset of the jacks.
Right now the device driver makes a dummy codec and internally creates
a card and links everything together.
http://git.elopez.com.ar/linux/src/abc050fbbaa5302b76ac585954cd207961fc9159/sound/soc/sunxi/sunxi-codec.c?at=sunxi-codec

Then someone came along and wanted to add a MAX9768. We're stuck
because the way the driver is built it doesn't support the external
MAX9768 codec driver.  MAX9768 is just an amp with I2C control of
volume.

So how should the device tree look for no external amp? Right now
there is just a device node and the driver makes a card/dummy-codec
internally.

How should the device tree look when there is an external amp?  Maybe
this amp should just be a chip of the device node?

How should the various jack populations be handled in the device tree?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: ASoC: Device tree binding to dummy codec

[jonsmirl]

On Mon, Jul 28, 2014 at 8:54 AM, jonsmirl@gmail.com <jonsmirl@gmail.com> wrote:
> On Mon, Jul 28, 2014 at 7:20 AM, Mark Brown <broonie@kernel.org> wrote:
>> On Mon, Jul 28, 2014 at 08:24:39AM +0200, Lars-Peter Clausen wrote:
>>> Cc ASoC maintainers.
>>
>> Jon, you should really know to CC maintainers.
>
> Are the all CC'd now? I thought the ALSA list was sufficient.
>
> So how do I set this hardware up?
>
> on-chip codec - it is ADC/DAC with FIFIO directly attached. There is
> no separate bus. on-chip codec supports things like mic1, mic2, line
> in, line out, hp out. Most boards populate only a subset of the jacks.
> Right now the device driver makes a dummy codec and internally creates
> a card and links everything together.
> http://git.elopez.com.ar/linux/src/abc050fbbaa5302b76ac585954cd207961fc9159/sound/soc/sunxi/sunxi-codec.c?at=sunxi-codec
>
> Then someone came along and wanted to add a MAX9768. We're stuck
> because the way the driver is built it doesn't support the external
> MAX9768 codec driver.  MAX9768 is just an amp with I2C control of
> volume.
>
> So how should the device tree look for no external amp? Right now
> there is just a device node and the driver makes a card/dummy-codec
> internally.
>
> How should the device tree look when there is an external amp?  Maybe
> this amp should just be a chip of the device node?

Maybe something like this.....

i2c1: i2c@01c2b000 {
   pinctrl-names = "default";
   pinctrl-0 = <&i2c1_pins_a>;
   status = "okay";

   max9768: max9768@36 {
      compatible = "max,9768";
      reg = <0x36>;
   };
};

codec: codec@01c22c00 {
   compatible = "allwinner,sun7i-a20-codec";
   reg = <0x01c22c00 0x40>;
   interrupts = <0 30 4>;
   clocks = <&pll2 0>, <&apb0_gates 0>, <&codec_clk>;
   clock-names = "pll", "apb", "codec";
   dmas = <&dma 0 19>, <&dma 0 19>;
   dma-names = "rx", "tx";
   widgets = "Mic1 Jack", "Headphone Jack";
   external-amp = <&max9768>
   status = "okay";
};

If external amp is missing I just bind to my internal dummy-codec.


>
> How should the various jack populations be handled in the device tree?
>
> --
> Jon Smirl
> jonsmirl@gmail.com



-- 
Jon Smirl
jonsmirl@gmail.com

Re: ASoC: Device tree binding to dummy codec

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 2033 bytes --]

On Mon, Jul 28, 2014 at 08:54:13AM -0400, jonsmirl@gmail.com wrote:
> On Mon, Jul 28, 2014 at 7:20 AM, Mark Brown <broonie@kernel.org> wrote:
> > On Mon, Jul 28, 2014 at 08:24:39AM +0200, Lars-Peter Clausen wrote:
> >> Cc ASoC maintainers.

> > Jon, you should really know to CC maintainers.

> Are the all CC'd now? I thought the ALSA list was sufficient.

No, you should always CC maintainers - never assume anything sent only
to a mailing list is going to be seen or read, certainly not with any
degree of promptness.

> on-chip codec - it is ADC/DAC with FIFIO directly attached. There is
> no separate bus. on-chip codec supports things like mic1, mic2, line
> in, line out, hp out. Most boards populate only a subset of the jacks.
> Right now the device driver makes a dummy codec and internally creates
> a card and links everything together.

> http://git.elopez.com.ar/linux/src/abc050fbbaa5302b76ac585954cd207961fc9159/sound/soc/sunxi/sunxi-codec.c?at=sunxi-codec

> Then someone came along and wanted to add a MAX9768. We're stuck
> because the way the driver is built it doesn't support the external
> MAX9768 codec driver.  MAX9768 is just an amp with I2C control of
> volume.

This doesn't seem hard - just extend the binding for the device/card to
allow auxiliary devices to be specified (the matching code supports
that).

> So how should the device tree look for no external amp? Right now
> there is just a device node and the driver makes a card/dummy-codec
> internally.

Your CODEC shouldn't be a completely dummy one, at a minimum it has some
external pins which need to be described and documented.

> How should the device tree look when there is an external amp?  Maybe
> this amp should just be a chip of the device node?

Just the same as any other card - allow a phandle to be provided to the
amplifier.

> How should the various jack populations be handled in the device tree?

Assuming "jack populations" are DAPM links just do it the same way as
anything else and use snd_soc_of_parse_audio_routing().

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC: Device tree binding to dummy codec

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 780 bytes --]

On Mon, Jul 28, 2014 at 09:49:27AM -0400, jonsmirl@gmail.com wrote:

> codec: codec@01c22c00 {
>    compatible = "allwinner,sun7i-a20-codec";
>    reg = <0x01c22c00 0x40>;
>    interrupts = <0 30 4>;
>    clocks = <&pll2 0>, <&apb0_gates 0>, <&codec_clk>;
>    clock-names = "pll", "apb", "codec";
>    dmas = <&dma 0 19>, <&dma 0 19>;
>    dma-names = "rx", "tx";
>    widgets = "Mic1 Jack", "Headphone Jack";
>    external-amp = <&max9768>
>    status = "okay";
> };

> If external amp is missing I just bind to my internal dummy-codec.

No, the CODEC that's in the device should be there all the time - it's
just the same as connecting an external amp to any other device,
describe the hardware in the SoC the same way all the time and then
connect any attached devices to it.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC: Device tree binding to dummy codec

[jonsmirl]

On Mon, Jul 28, 2014 at 12:27 PM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jul 28, 2014 at 09:49:27AM -0400, jonsmirl@gmail.com wrote:
>
>> codec: codec@01c22c00 {
>>    compatible = "allwinner,sun7i-a20-codec";
>>    reg = <0x01c22c00 0x40>;
>>    interrupts = <0 30 4>;
>>    clocks = <&pll2 0>, <&apb0_gates 0>, <&codec_clk>;
>>    clock-names = "pll", "apb", "codec";
>>    dmas = <&dma 0 19>, <&dma 0 19>;
>>    dma-names = "rx", "tx";
>>    widgets = "Mic1 Jack", "Headphone Jack";
>>    external-amp = <&max9768>
>>    status = "okay";
>> };
>
>> If external amp is missing I just bind to my internal dummy-codec.
>
> No, the CODEC that's in the device should be there all the time - it's
> just the same as connecting an external amp to any other device,
> describe the hardware in the SoC the same way all the time and then
> connect any attached devices to it.

Allwinner has named their on-chip audio interface 'codec'. This codec
just has two FIFOs hooked to the DAC/ADC. I coded everything in the
CPU-DAI and left the CODEC-DAI empty.

So what do you want the device tree to look like?
Example with no external amp.
Example with external amp.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: ASoC: Device tree binding to dummy codec

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 444 bytes --]

On Mon, Jul 28, 2014 at 12:33:57PM -0400, jonsmirl@gmail.com wrote:

> So what do you want the device tree to look like?
> Example with no external amp.
> Example with external amp.

To repeat what I said in a previous mail:

| Just the same as any other card - allow a phandle to be provided to the
| amplifier.

| Assuming "jack populations" are DAPM links just do it the same way as
| anything else and use snd_soc_of_parse_audio_routing().

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC: Device tree binding to dummy codec

[jonsmirl]

On Mon, Jul 28, 2014 at 12:36 PM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Jul 28, 2014 at 12:33:57PM -0400, jonsmirl@gmail.com wrote:
>
>> So what do you want the device tree to look like?
>> Example with no external amp.
>> Example with external amp.
>
> To repeat what I said in a previous mail:

I see the aux binding in soc-core.c
Where is an example of how to use it in a device tree?

None of these are used in a device tree that I can spot..
omap/rx51.c:static struct snd_soc_aux_dev rx51_aux_dev[] = {
omap/rx51.c: .aux_dev = rx51_aux_dev,
omap/rx51.c: .num_aux_devs = ARRAY_SIZE(rx51_aux_dev),
omap/rx51.c: rx51_aux_dev[0].codec_name = NULL;
omap/rx51.c: rx51_aux_dev[0].codec_of_node = dai_node;
samsung/speyside.c:static struct snd_soc_aux_dev speyside_aux_dev[] = {
samsung/speyside.c: .aux_dev = speyside_aux_dev,
samsung/speyside.c: .num_aux_devs = ARRAY_SIZE(speyside_aux_dev),
samsung/neo1973_wm8753.c:static struct snd_soc_aux_dev neo1973_aux_devs[] = {
samsung/neo1973_wm8753.c: .aux_dev = neo1973_aux_devs,
samsung/neo1973_wm8753.c: .num_aux_devs = ARRAY_SIZE(neo1973_aux_devs),
samsung/neo1973_wm8753.c: neo1973.num_aux_devs = 1;




>
> | Just the same as any other card - allow a phandle to be provided to the
> | amplifier.
>
> | Assuming "jack populations" are DAPM links just do it the same way as
> | anything else and use snd_soc_of_parse_audio_routing().



-- 
Jon Smirl
jonsmirl@gmail.com

Re: ASoC: Device tree binding to dummy codec

[Lars-Peter Clausen]

On 07/28/2014 06:47 PM, jonsmirl@gmail.com wrote:
> On Mon, Jul 28, 2014 at 12:36 PM, Mark Brown <broonie@kernel.org> wrote:
>> On Mon, Jul 28, 2014 at 12:33:57PM -0400, jonsmirl@gmail.com wrote:
>>
>>> So what do you want the device tree to look like?
>>> Example with no external amp.
>>> Example with external amp.
>>
>> To repeat what I said in a previous mail:
>
> I see the aux binding in soc-core.c
> Where is an example of how to use it in a device tree?

https://lkml.org/lkml/2014/4/28/318

Does pretty much them same though to what you proposed.

Re: ASoC: Device tree binding to dummy codec

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 461 bytes --]

On Mon, Jul 28, 2014 at 06:49:16PM +0200, Lars-Peter Clausen wrote:
> On 07/28/2014 06:47 PM, jonsmirl@gmail.com wrote:

> >Where is an example of how to use it in a device tree?

> https://lkml.org/lkml/2014/4/28/318

> Does pretty much them same though to what you proposed.

Right, the bit I was pointing to as problematic was the comment about
removing the description of the internal CODEC from the card if there
was an external component connected to it.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: ASoC: Device tree binding to dummy codec

[jonsmirl]

On Mon, Jul 28, 2014 at 12:49 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 07/28/2014 06:47 PM, jonsmirl@gmail.com wrote:
>>
>> On Mon, Jul 28, 2014 at 12:36 PM, Mark Brown <broonie@kernel.org> wrote:
>>>
>>> On Mon, Jul 28, 2014 at 12:33:57PM -0400, jonsmirl@gmail.com wrote:
>>>
>>>> So what do you want the device tree to look like?
>>>> Example with no external amp.
>>>> Example with external amp.
>>>
>>>
>>> To repeat what I said in a previous mail:
>>
>>
>> I see the aux binding in soc-core.c
>> Where is an example of how to use it in a device tree?
>
>
> https://lkml.org/lkml/2014/4/28/318
>
> Does pretty much them same though to what you proposed.
>

So devicetree...
    external-amp = phandle;

then internally I'll hook it up to the aux_dev instead of replacing my
codec. And yes, codec is not completely empty it has widgets for the
possible output pins.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: ASoC: Device tree binding to dummy codec

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 422 bytes --]

On Mon, Jul 28, 2014 at 12:56:27PM -0400, jonsmirl@gmail.com wrote:

> So devicetree...
>     external-amp = phandle;

> then internally I'll hook it up to the aux_dev instead of replacing my
> codec. And yes, codec is not completely empty it has widgets for the
> possible output pins.

Right, and also allow the user to specify some DAPM links to connect the
amplifier to the CODEC otherwise it'll never get powered on.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]