Felipe Balbi wrote:
> On Tue, Jul 06, 2010 at 09:57:09AM +0200, ext Tony Lindgren wrote:
> >Sounds like we should first fix thing before adding new code
> >that will make fixing the basic issues harder.
>
> my idea to deal with this is to have a set of "platform glue drivers".
> So omap2430.c, blackfin.c, tusb6010 and davinci.c would become a
> platform driver themselves that would instantiate musb-hdrc
> platform_driver and the correct dma driver (inventra, omap, cppi, etc).
>
> It would look something like:
>
> #include <plat/usb.h>
>
> static struct musb_hdrc_ops omap2430_musb_ops = {
> .readb = generic_readb,
> .readw = generic_readw,
> .readl = generic_readl,
> .writeb = generic_writeb,
> .writew = generic_writew,
> .writel = generic_writel,
> };
>
> static struct musb_platform_data omap2430_musb_data = {
> .ops = &omap2430_musb_ops,
> .mode = -EINVAL, /* change it later */
> };
>
> static int __init omap2430_musb_probe(struct platform_device *pdev)
> {
> struct omap24030_musb_platform_data pdata = pdev->dev.platform_data;
>
> musb = platform_device_alloc("musb-hdrc", -1);
>
> /* check error */
>
> musb->dev.parent = &pdev->dev;
> omap2430_musb_data.mode = pdata->mode;
> /* initialize every other necessary field */
>
> platform_device_add_data(musb, &omap2430_musb_data);
>
> dma = platform_device_alloc("dma-inventra", -1);
>
> /* check error */
>
> dma->dev.parent = &pdev->dev;
>
> /* add both devices */
>
> return 0;
> }
>
> static int omap2430_musb_suspend(struct platform_device *pdev,
> pm_message_t state)
> {
> return omap2430_musb_save_context(pdev);
> }
>
> static int omap2430_musb_resume(stuct platform_device *pdev)
> {
> omap2430_musb_restore_context(pdev);
> }
>
> this would allow us to factor-out save/restore context, get rid of all
> exported functions (by just adding every necessary function to
> musb_hdrc_ops) and compile in every single musb file in one driver and
> still have it working. Boards would, then, just instantiate
> musb-omap2430/musb-blackfin/musb-tusb6010/musb-davinci
> platform_driver(s) and the rest would be done on runtime, since only the
> driver that matches would actually probe.
>
> How does that sound ??
>
Like it is done in ehci-hcd.c/ohci-hcd.c?
This looks much easier to maintain.
Do you already have a patch doing this, or would you like me to spin one
for RFC/RFT?
- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
