On 05/07/11 07:19 AM, Tony Lindgren wrote: > * Raphaël Assénat <raph@xxxxxx> [110704 12:51]: >> >> The am3505 is apparently so similar to the 3430 that it was treated as such >> (omap_chip.oc was being set to CHIP_IS_OMAP3430ES3_1). There are however a >> few differences that need to be addressed. I have therefore created a new >> CHIP_IS and patched clocks, hwmod and power management related files >> consequently. My system now boots until it complains that it is unable >> to mount its root filesystem. > > Can you please describe where you need CHIP_IS for am3505? It seems that > your patches just enable the same CHIP_IS_OMAP3430 features for am3505 too? Actually it's only needed for the 3505/3517 specific UART 4 which should not be registered on real OMAP3430's. (see struct omap_hwmod am35xx_uart4_hwmod; in omap_hwmod_3xxx_data.c) But there are also cases where OMAP3430 hwmods must not be registered on AM35xx. For instance, omap3xxx_timer12_hwmod since timer12 does not exist general purpose AM3505's. > I'd rather see us improve the code so we can support am3505 properly without > a need to patch all over the place.. Maybe instead of having one big array of hwmods registered for all CPUs in omap_hwmod_3xxx_data we could have a separate one for am35xx (and maybe, eventually others) such as: static __initdata struct omap_hwmod *omap3xxx_hwmods[] static __initdata struct omap_hwmod *am35xx_hwmods[] ...and maybe also a 'common' array. The init function would then register the appropriate hwmod array(s). The only thing I don't like is that for this to work we would have to keep setting CHIP_IS_OMAP3430 even on AM35xx CPUs. But maybe we could change the behaviour of omap_hwmod_register to trust the caller and accept the hwmods without looking at the omap_chip member. By doing this I think we could drop all the .omap_chip = OMAP_CHIP_INIT(...) instances. Otherwise I think the current approach, despite the size of the initial patch, has at least the benefit of being explicit and less confusing than (ab)using the CHIP_IS from a different CPU. Best regards, Raphaël Assénat -- 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
