Re: [PATCH 2/6 Revised] SPI omap2_mcspi: Add max_clk_div field to mcspi platform config

[Tony Lindgren <tony@atomide.com>]

* Felipe Balbi <me@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