On Mon, Jul 14, 2008 at 11:21:12AM -0600, Grant Likely wrote:
On Mon, Jul 14, 2008 at 10:53 AM, Mark Brown
Incidentally, nobody ever really commented on my suggestion to do something DMI-like
I'm feeling stupid; what does "DMI" stand for?
Desktop Management Interface, a standard BIOS interface for getting system data on x86 class hardware. Of particular interest here is the fact that it contains various ID strings for things like motherboard and chassis - on Linux drivers can be automatically loaded based on these strings. See drivers/misc/thinkpad_acpi.c for an example of a driver that does this.
Note that it's *not* binding a driver, it just provides the hooks to enable the modules to be automatically loaded and to let drivers query information in DMI.
Yes, we have APIs for matching against device trees. Personally, I'm leaning towards having the powerpc platform code (arch/powerpc/platforms/* stuff; not ASoC platform stuff) register a platform device for the machine driver and let as many machine drivers as needed be written. Hopefully we'll be able to do at least one
That would be what I'd expected initially - it is, after all, what other platforms are doing here.
generic machine driver that will be usable by most PowerPC boards, but I don't think it is a requirement or even realistic to shoehorn all powerpc sound circuits into a single driver.
Yes, that'd be completely unrealistic.
I don't mind - you can call it what you like inside PowerPC-specific code.
Oh help! Don't tell us that! Otherwise we'll always be talking across purposes. When ambiguous, let's just be sure to always refer to them as "ASoC machine drivers". :-)
Feh, from now on I shall me naming all new concepts with pwgen :) .