On 11/18/07, Matt Sealey <[EMAIL PROTECTED]> wrote:
> I'd suggest something like this:
>
> [EMAIL PROTECTED] {
> \\ this is our magic audio fabric
> device_type = "digispeaker,flinger";
>
> \\ it's actually just an i2s pcm codec
> compatible = "mpc5200-psc-i2s";
>
> \\ and this defines the layout Jon picked for the DACs
> \\ just like Apple's layout-id value
> model = "flinger,2"
>
> [EMAIL PROTECTED] {
> compatible = "TXN,tas5504";
> codec-control = <&codec-control>;
> }
>
> \\ and every i2s driver on the planet will just ignore these
> \\ unless it's one of our boards
> digispeaker,amp-control = <&-control>
> }
This forces a single fabric driver for audio buses that can support
more than one device (like ac97). I can live with that, but is it ok
for the design?
> Then you control the fabric for your boards and get to attach
> whatever the hell you want to those codecs, control interfaces
> and special little tweak features you always wanted.
>
> Be careful cross-referencing devices with each other,
> for instance in your example you made the i2c codec device
> point back to an i2s handle - it's a good idea, but not well
> executed in my opinion as it lacks context.
>
> Isn't the primary concern of an audio codec, to play audio?
>
> Therefore, shouldn't the audio codec point back to it's control
> interface? Also, why give the name as 'i2s-handle'? Surely it
> could be any interface. In reverse, it would be, perhaps, as
> above, i2c-handle, but then what if you change the interface
> type (for instance a bunch of Wolfson codecs can do i2c and
> spi for control). Your property name is obselete, then and
> drivers will need to switch on property names to find out
> which control interface is present.
Others have pointed out that device trees are organized by control
interface. So the codec node should be under i2c and back point to
their data stream. We could use something like codec-data instead of
i2s-handle.
I don't have a strong opinion on how to organize this stuff. I just
need some way to get the ASOC fabric drivers loaded. Actually ASOC
calls them 'machine' drivers, it is Apple's audio code that call them
fabric drivers.
>
> What they should really do, is be told where their control
> interface handle is, then you can look at that handle and
> the device it contains - that device itself will tell you the
> bus type, any devices under it, and any quirky things you
> need to do besides (above, &codec-control etc. would point to
>
> [EMAIL PROTECTED] {
> [EMAIL PROTECTED] {
> blah
> }
> }
>
> [EMAIL PROTECTED] {
> [EMAIL PROTECTED] {
> blah
> }
> }
>
> [EMAIL PROTECTED] {
> [EMAIL PROTECTED] {
> compatible = "gpio-bit";
> bit = "1";
> open-drain;
> }
> }
>
> If you couldn't tell it's a device on an i2c bus then you
> are coding your driver badly. And you can have lots of
> codecs, and just back reference which control interface
> they have. I dunno.
>
> Remember, it doesn't matter what NAME you give it, the name
> is for people to read, device_type is what you search for,
> and phandles let you attach specific devices to each other.
> compatible is for when you want to tell people "it acts the
> same as this" and model is to give you the enviable ability
> to define PRECISELY what you are looking at beyond a chip
> name. I'd suggest we use all of them for great justice.
>
> --
> Matt Sealey <[EMAIL PROTECTED]>
> Genesi, Manager, Developer Relations
>
--
Jon Smirl
[EMAIL PROTECTED]
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
