[alsa-devel] [PATCH 1/2] powerpc: add platform registration for ALSA SoC drivers
Grant Likely
grant.likely at secretlab.ca
Thu Apr 29 07:58:34 EST 2010
On Wed, Apr 28, 2010 at 2:35 PM, Timur Tabi <timur.tabi at gmail.com> wrote:
> On Tue, Apr 27, 2010 at 5:09 AM, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
>
>> Keep in mind that it's perfectly kosher to create nodes for "virtual"
>> devices. IE. We could imagine a node for the "sound subsystem" that
>> doesn't actually correspond to any physical device but contain the
>> necessary properties that binds everything together. You could even have
>> multiple of these if you have separate set of sound HW that aren't
>> directly dependant.
>
> First, I want to officially retract this patch. I've talked with
> Grant, and we've come up with a different approach to this problem.
>
> Second, how about this binding for the virtual sound node? It would
> be a root-level node.
>
> sound-devices {
> sound0 {
> ssi = &ssi0;
> playback-dma = &dma00;
> capture-dma = &dma01;
> codec = &cs4270;
> }
> };
The sound0 node needs a compatible value, the sound-device node should
probably have one too.
The sound0 node should have something board specific like
"fsl,mpc8610hpcd-sound" to make it clear that the binding really only
applies to this particular board. It would also be a good idea to
prefix all of the property names with 'fsl,' to avoid conflicting with
any future common bindings or conventions. Other boards can use the
same binding, but they would get a different compatible value (the
driver could bind on both).
I'm not a huge fan of the name "sound-devices" for the parent node.
There are other sorts of things that we need 'virtual' device nodes to
describe. It would be nice to have a single place for collecting
nodes for stuff like this. Perhaps this:
system {
compatible = "system-devices";
sound0 {
compatible = "fsl,mpc8610hpcd-sound";
fsl,ssi = &ssi0;
fsl,playback-dma = &dma00;
fsl,capture-dma = &dma01;
fsl,codec = &cs4270;
};
};
But I really don't have any knowledge of what has been done previously
in this regard or if any conventions have been established. Ben, any
thoughts?
g.
More information about the Linuxppc-dev
mailing list