* Felipe Balbi <m...@felipebalbi.com> [100315 12:12]:
> Hi,
>
> On Mon, Mar 15, 2010 at 11:52:13AM -0700, Tony Lindgren wrote:
> > Yeah I've been thinking about that too earlier. We could have common
> > devices.c with the init code, then dev24xx.c and dev34xx.c et al
> > would just call the common init functions with something like this:
> >
> >
> > static int __init dev34xx_init(void)
> > {
> > if (!cpu_is_omap34xx())
> > return -ENODEV;
> >
> > omap_init_mbox(omap34xx_mbox_resources, omap34xx_mbox_nr_resources);
> > omap_init_sti(omap34xx_sti_resources, omap34xx_sti_nr_resources);
> > ...
> >
> > return 0;
> > }
> >
> > subsys_initcall(emu_init);
> >
> > Of course that needs to be coordinated with the pending hwmod patches.
>
> sure. Exactly what I was thinking :-p
>
> > > personally I think we should have mach-omap3 and mach-omap4 directories
> > > but that would be too intrusive IMO.
> >
> > I think we can achieve most of that by right naming of the files and
> > with hwmod. Having separate directories typically means multiple copies
> > of almost the same code.
>
> could be, but we already have separated clk, pm, cpuidle, mux and soon
> to become devices. So pretty much the base support is already splitted,
> then why not completely avoiding ifdefs also with dma (which today is
> full of ifdefs and could be converted to a platform_device also).
Yeah there are tons of things that should be fixed and split into
platform_data and generic code. At least gpio.c, dma.c and i2c-omap.c
need some serious work.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
