Re: Revisited, audio codec device tree entries.

["Jon Smirl" <jonsmirl@gmail.com>]

On 11/18/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> On Sun, Nov 18, 2007 at 11:31:13PM +0000, Matt Sealey wrote:
> > Matt Sealey wrote:
> > > Jon Smirl wrote:
> > >
> > > If you require the codec to be subservient to some "fabric" then I
> > > suggest you make a "sound" node with a compatible entry which is
> > > defined as something specific to your board (digispeaker,audio) and
> > > let your driver pick that up and then switch on the model (rather like
> > > Apple's layout-id) of that device to pick out the specifics of that
> > > fabric. If it needs an audio codec (ac97 or i2s) and a control
> > > interface (i2c or spi) then it knows which ones it is looking for
> > > based on the model.
> >
> > Sigh, I suck, I forgot the example :D
> >
> > And I forgot the rant you guys usually get - for god's sake, why isn't
> > anyone using the "model" property? Do I have to whine about this some
> > more to get your attention, guys? name, device_type, compatible and
> > model are your tools for building device trees and detecting
> > things. That's FOUR unique properties.
> >
> > How come I only see device trees defined using "name", with the same
> > device_type, and "compatible"? This is braindead design.
>
> Gah!  For the benefit of others on this list who may be misled.
>
> *Neither* of you correctly understands the device tree, what I've seen
> of *both* your suggested approaches is crap.

I'm awaiting guidance on how to do the device tree. I just want to
figure out some way of getting my drivers loaded. I make no claim to
having any expertise in device tree design.

There are two classes of codecs, ones where control/data is combined
and one where they are separate. Common examples - combined: ac97, hda
- separate i2s + i2c. Then there is this fabric stuff which glues a
generic codec driver into a specific board layout. While a generic
AC97 design may not need a fabric driver, most other designs need it.

If someone were to put an example into the Docmentation file, I'd follow it.

>
> The device tree describes the _hardware_.  If you start reasoning
> about how to lay out the device tree based on your driver model,
> you're already wrong.
>
> Matt, the various properties you list do not mean what you think they
> mean.
>
> name - should be named according to the generic names convention.
> It's pretty much arbitrary, meant for human readability of the device
> tree.  Drivers should not depend on it (some do, historically, but new
> drivers and trees should not).
>
> device_type - indicates the open firmware method interface for the
> device.  Therefore, meaningless in flattened trees.  No new driver
> should use this.
>
> compatible - *this* is the one for driver selection.  It describes the
> hardware level interface(s) of the device.
>
> model - usually just for debugging / diagnosis / human-readable
> purposes, describes exact model / revision of the hardware.  It can be
> used to enable driver quirks / workarounds for when various devices
> are supposed to be compatible (as encoded in 'compatible') but
> aren't, due to hardware bugs.  However, you should never aim to use it
> this way in design.
>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                 | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>


-- 
Jon Smirl
jonsmirl@gmail.com