On 11/18/07, David Gibson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
