On 6/16/08, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
The driver stays in sound/soc/fsl. It's only the creation of the device that moves. You just need to add this to arch/powerpc/platforms/86xx/mpc8610_hpcd.c and remove it from mpc8610_hpcd.c. Adding this to arch/powerpc/platforms/86xx/mpc8610_hpcd.c will have no effect if the mpc8610_hpcd.c driver is not to be found.
Ok, I'll do that.
The architecture still doesn't appear right to me. fsl-dma.c is another driver that is self-creating its own device. We can certainly add code to arch/powerpc/platforms/86xx/mpc8610_hpcd.c to create a "fsl-elo" device, but it's another fake device. Plus there's already a driver for the real "fsl,eloplus-dma" hardware in the system. Needing to create fake devices is a sign that the design is not correct. dma support should probably be a library that is linked into the ssi driver and not be a standalone device driver.
I'm going to be gone for a week with no email. When I get back I'll work on where to do snd_soc_card_create("MPC8610"). If you do it in the fabric driver, then the fabric driver can never be optional. But if you don't do it in the fabric driver, how does the fabric driver find the soc_card? There's no call to retrieve the soc_card for "MPC8610".
You've complicated it by creating two fabric devices but I believe your code could be changed to only make one.
static struct platform_device alsa_fabric = { .name = "MPC8610HPCD", .id = -1, };
static struct platform_device *devices[] = { &alsa_fabric, };
platform_add_devices(&devices[0], ARRAY_SIZE(devices));
I'd rename the driver to something less generic. .name = "MPC8610HPCD-fabric",
These are all good ideas. Thanks.
--
Timur Tabi Linux kernel developer at Freescale