On 8/1/08, David Gibson <[EMAIL PROTECTED]> wrote: > On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote: > > On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote: > > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote: > > > > On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote: > > [snip] > > > > > 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 [EMAIL PROTECTED] _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
