On Thu, May 14, 2009 at 1:57 PM, Jon Smirl <jonsmirl@xxxxxxxxx> wrote:
> On Thu, May 14, 2009 at 1:40 PM, Mark Brown
> <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> 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.
>
> Now I see what you mean. I need to make the codec into a device so
> that I can dynamically load and find it. On PowerPC the codecs don't
> have to be compiled in, they can be on an initrd. The code in
> of_simple will find the right driver and get it into memory. The
> platform device is what triggers the kernel to go searching for the
> module on initrd.
I'm juggling too many balls. ASoC needs some more rework to make the
modules load dynamically. The codecs need to implement .id_table.
.id_table is pretty trivial
static const struct i2c_device_id ds1682_id[] = {
{ "ds1682", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, ds1682_id);
static struct i2c_driver ds1682_driver = {
.driver = {
.name = "ds1682",
},
.probe = ds1682_probe,
.remove = ds1682_remove,
.id_table = ds1682_id,
};
> The .name field is what lets the kernel find the module on initrd....
> static struct platform_driver wm9712_driver =
> {
> .probe = wm9712_probe,
> .driver = {
> .name = "wm9712",
> },
> };
>
>
> The i2c core just went through this same change. Previously i2c
> drivers had to be compiled in. Now they can just be on initrd and
> loaded on demand by the device tree. The equivalent to of_simple for
> i2c is in drivers/of/of_i2c.c. It is much smaller since more of the
> support has been pushed into the i2c core.
>
> This isn't platform specific, other platforms could implement this but
> they don't have anything like a device tree telling them which modules
> to load. A device tree is a probing mechanism for devices that can't
> be probed.
>
> --
> Jon Smirl
> jonsmirl@xxxxxxxxx
>
--
Jon Smirl
jonsmirl@xxxxxxxxx
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
