[alsa-devel] ALSA SoC device tree bindings
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
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:
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)?
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
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.
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
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.
participants (4)
-
Jeremy Kerr -
Jon Smirl -
Mark Brown -
Timur Tabi