Messages in this thread | | | Date | Wed, 27 May 2009 23:24:24 +0100 | From | Mark Brown <> | Subject | Re: [RFC] [PATCH] Device Tree on ARM platform |
| |
On Wed, May 27, 2009 at 02:50:27PM -0400, Jon Smirl wrote: > On Wed, May 27, 2009 at 12:32 PM, Mark Brown
> > This worries me too, my experiences with OF device tree handling for > > ASoC have been pretty negative - but then audio is one of the worst > > cases for handling within the device tree.
> ASoC is where I2C was a year ago. I2C had it's own module loading > conventions. OF assumes the subsystem is going to follow the standard > kernel module loading conventions. I2C has now been fixed to use the > standard conventions and it happily works with OF now.
As I just said to Grant this is not the case any more, unless you are using AC97. You can instantiate all the component drivers for an ASoC card via the normal device model methods, the overwhelming majority of my ASoC work is done on systems that do exactly this.
> The fight with ASoC is that two different entities are trying to link > the modules together - ASoC (machine drivers) and the device tree > code. There should only be one system linking everything together.
That's not the fundamental problem that machine drivers solve, though they do the basic tab A into slot B stuff too. The biggest problem that machine drivers solve is that they allow us to set up the clocks used in the audio subsystem in a way that is appropriate for the system based on how it's wired up and what it's supposed to do. As I just said to Grant any OS neutral expression of this configuration suitable for use in a device tree would need to be able to provide some constraints and a wiring diagram. These would then be used together with constraints from the current runtime configuration to calculate an actual clock configuration for the system.
If we had a cross-platform clock framework which was capable of handling this then producing a generic machine driver would be more tractable but there's no visible prospect of that happening any time soon.
Please read back over the original soc-of-simple thread, it goes into the problems in a bit more detail.
> But you want these ASoC machine drivers on ARM because ARM doesn't > have device trees.
This is nothing to do with the device trees, as I believe I've mentioned before the existing ARM equivalents of the device tree are exactly equivalent to it for device loading as far as things outside arch/arm are concerned.
> I2C had the same problem. I2C wanted everything loaded form machine > drivers. The machine drivers are now optional. ASoC can be fixed in > the same way.
It's very easy to say things like this but there's quite a way to go before they can be delivered upon; if it were straightforward to handle I'd expect that soc-of-simple would be able to cope with it.
| |