* Raphaël Assénat <raph@xxxxxx> [110705 07:30]: > 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. Sounds like we should be able to handle both uart and gptimer12 the same way as we'll be handling the hwmod reset for special cases like gptimer12 for secure mode. So addding Paul to Cc. Basically we can have a am35xx specific arch_initcall that sets the special flags for these devices like noreset, disabled or unavailable. In this case we would just set some devices as unavailable on am35xx. > > 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. Well let's see how far we can get with passing the special case flags with omap2_init_devices(). Initially we can call that from the board-*.c file that should get your board booting. Then we can add the am35xx specific arch_initcall. Regards, Tony -- 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
