On Thu, 2009-05-14 at 12:43 -0400, Jon Smirl wrote:
My main objection is to your abuse of platform devices here - there is no need for this on non-PowerPC platforms and a platform device affects everyone. So long as you come up with a solution that does not impact other platforms I'm less worried.
This is the part you don't like? +static void __init efika_declare_platform_devices(void) +{
That bit's OK - it's the device you've added for the CODEC which is concerning me.
on an Efika it can exit. There were multiple discussions about this on the ppc list. The conclusion was that the mess of wires on the mainboard implementing audio really was a platform device.
I agree, this is the most sensible way to handle machine drivers.
There is a general kernel design problem in that there is no automated way to load something like an audio fabric driver. The Efika fabric driver is just example code, my Digispeaker hardware requires a board specific fabric driver since it has an external audio clock chip. Digispeaker drivers will come later after we decide on the final hardware design.
It's only really a problem on platforms using the device tree, everything else can happily define random Linux-specific platform devices in the board initialisation code and everything is happy.
The problem with fabric drivers is that they are optional and ALSA drivers can load in any order. That requires a mechanism to say registration time is now closed, proceed without waiting for a fabric driver. The core could be changed to remove this requirement by imposing ordering constraints on driver registration.
Indeed - this is only a problem due to the fact that you're trying to provide a generic machine driver.