Re: Board level compatibility matching
From: David Gibson <hidden>
Date: 2008-08-01 04:25:05
On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
On 7/31/08, David Gibson [off-list ref] wrote:quoted
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
> 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 instatiating it from the platform code does. -- 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