Re: Board level compatibility matching

On 8/1/08, David Gibson [off-list ref] wrote:

On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
 > On 7/31/08, David Gibson [off-list ref] wrote:
 > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
 > >  > On 7/31/08, David Gibson [off-list ref] wrote:

[snip]

quoted

quoted

 > That is what I'm doing now. But it requires every board to add a file

 > >  > to arch/powerpc/platforms.  Can we have some common code to make the
 > >  > fabric device? Can it be an OF device instead of a platform one? An OF
 > >  > device could be compatible with boardname-fabric, generic-fabric. That
 > >  > allows a stub fabric driver to always bind.
 > >
 > >
 > > There are several ways to do this, and which is the most sensible
 > >  depends on the specific design, and whether / how many boards the
 > >  design is shared amongst.
 > >
 > >  In some cases it's suitable to have a "fake" device node for the sound
 > >  wiring, to which a fabric driver can bind.  I think I've argued
 > >  against this approach in the past, but I've since been convinced that
 > >  it is a reasonable approach for some situations.  There's precedent,
 > >  too, a number of Apple device trees do this.
 > >
 > >  In other cases it may be possible to deduce the correct fabric driver
 > >  from the interconnections of individual sound components.
 > >
 > >  In yet others, we need board-specific platform code to instantiate the
 > >  fabric driver.  In some cases that's simply the most straightforward
 > >  way to do things.  In others it's not ideal, but we can use it as a
 > >  fallback technique because deployed device trees simply don't have
 > >  sufficient information in other places to use another approach.
 > >
 > >  There doesn't have to be One True Method for doing this.
 >
 > We're running into a need for the true method. With ALSA you need to
 > have the codec driver, i2s/ac97 driver and the fabric driver all load
 > and say here I am before ALSA can finish binding. ALSA won't complete
 > initializing on boards without all three.
 >
 > So what do you do on board that doesn't need a fabric driver? That's
 > why you want the fake device with the compatible string =
 > board-fabric, noop-fabric. Now you know for sure one of those two
 > drivers will bind.


No... that would be exactly my example of a case where instantiating
 the fabric driver from the platform code isn't ideal, but is a usable
 fallback option.


 > Why does the fake fabric device need to be in the device tree? Can't
 > we just dynamically create it as part of the boot process?


Um.. yes.. that would be exactly what instantiating it from the
 platform code does.

Platform devices are missing the compatible chain process. If we do
this with platform drivers the boot code creates a 'fabric' device
then I'll have to ensure that my board-fabric driver gets probed
before default-fabric because they both want to bind to the fabric
device.

I can do this, but building ordering dependencies like this is not the
most robust way to do things. With an OF device the ordering is
obvious via the compatible attribute.

 --
 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