ALSA SoC device tree bindings

ALSA SoC device tree bindings

[Jeremy Kerr]

Hi all,

>From some discussions at the previous Ubuntu Developer Summit, I've put up a 
page on the devicetree.org wiki with the ultimate goal of describing device 
tree bindings for ALSA System on Chip devices.

At this stage, we're just looking at how to structure device in the device 
tree. The bindings for specific devices will come as required (ie, as we add 
device tree support for them).

So - if you're interested in the ALSA and/or device tree areas, please take a 
look at the notes from UDS:

 http://devicetree.org/SoC_Audio

- if you have any comments or suggestions, please let me know, or add to the 
page (or the discussion for the page). I intend for this document to become a 
more formal specification, but we still have a way to go before that happens.

If you'd like an introduction to device trees, Grant has a good walkthrough-
style document at:

 http://devicetree.org/Device_Tree_Usage

Cheers,


Jeremy

Re: ALSA SoC device tree bindings

[Mark Brown]

On Wed, Jun 23, 2010 at 08:30:13PM +0800, Jeremy Kerr wrote:

> From some discussions at the previous Ubuntu Developer Summit, I've put up a 
> page on the devicetree.org wiki with the ultimate goal of describing device 
> tree bindings for ALSA System on Chip devices.

Please do remember to CC maintainers on e-mails if you're looking for a
response, this is standard practice for kernel stuff due to the number
of high volume mailing lists and busy maintainers.  I've added Liam into
the CCs.

> So - if you're interested in the ALSA and/or device tree areas, please take a 
> look at the notes from UDS:

>  http://devicetree.org/SoC_Audio

A few comments:

 - There's no mention of clocking in the page, which is one of the more
   exciting bits of this stuff.  Reading the page I'm not sure that
   we've even fully captured the problem definition.

 - I'm not sure what "ALSA quirking" is?

 - "i2s" isn't the best thing to use in a property name, I2S is just one
   of several different standards for interconn

 - How does the way you're defining the audio links cope with multi-drop
   links (eg, bluetooth and cellular modem on the same bus)?

Re: ALSA SoC device tree bindings

[Timur Tabi]

On Wed, Jun 23, 2010 at 7:30 AM, Jeremy Kerr <jeremy.kerr@canonical.com> wrote:

> - if you have any comments or suggestions, please let me know, or add to the
> page (or the discussion for the page). I intend for this document to become a
> more formal specification, but we still have a way to go before that happens.

Please consider using the MPC8610 HPCD board as a reference
implementation, instead of i.MX boards.  This is a PowerPC board that
has long since support OF bindings for ASoC drivers, so the code is
more robust.  ARM only recently got basic OF support, and AFAIK, none
of the audio drivers support it.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: ALSA SoC device tree bindings

[Mark Brown]

On Wed, Jun 23, 2010 at 08:30:13PM +0800, Jeremy Kerr wrote:

> At this stage, we're just looking at how to structure device in the device 
> tree. The bindings for specific devices will come as required (ie, as we add 
> device tree support for them).

Actually, re-reading the page I'm not sure it really captures my
understanding of the discussion (and all the previous discussions we've
had on the lists and so on) at all.  Reading the page the idea that a
machine specific driver is normal and expected doesn't come over at all
well, especially in the design section which doesn't make any mention at
all of machine specific drivers.

As I keep saying the main thing I'm looking for from any device tree
binding is something that I can point people at so we don't need to go
through the rehashings of this subject which come up every time someone
decides they want to use device trees.

Re: ALSA SoC device tree bindings

[Jon Smirl]

On Sun, Jun 27, 2010 at 5:42 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Jun 23, 2010 at 08:30:13PM +0800, Jeremy Kerr wrote:
>
>> At this stage, we're just looking at how to structure device in the device
>> tree. The bindings for specific devices will come as required (ie, as we add
>> device tree support for them).
>
> Actually, re-reading the page I'm not sure it really captures my
> understanding of the discussion (and all the previous discussions we've
> had on the lists and so on) at all.  Reading the page the idea that a
> machine specific driver is normal and expected doesn't come over at all
> well, especially in the design section which doesn't make any mention at
> all of machine specific drivers.

Do we really want to call them machine drivers? Machine drivers
already exist in the basic non-audio platform code. Calling the audio
drivers machine drivers overloads the term. In the Apple audio code
they are called fabric drivers.


> As I keep saying the main thing I'm looking for from any device tree
> binding is something that I can point people at so we don't need to go
> through the rehashings of this subject which come up every time someone
> decides they want to use device trees.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: ALSA SoC device tree bindings

[Mark Brown]

On 27 Jun 2010, at 13:39, Jon Smirl wrote:
> On Sun, Jun 27, 2010 at 5:42 AM, Mark Brown

>> well, especially in the design section which doesn't make any mention at
>> all of machine specific drivers.

> Do we really want to call them machine drivers? Machine drivers
> already exist in the basic non-audio platform code. Calling the audio
> drivers machine drivers overloads the term. In the Apple audio code
> they are called fabric drivers.

They've been called machine drivers for years. If you find this confusing
I'd suggest qualifying the name ("ASoC machine drivers"), I don't think
renaming them would be worthwhile just for PowerPC. Given the similarity
of their role I'm having a hard time seeing the overlap as a bad thing even
for the people who have difficulty with this.