> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of Tony Lindgren > Sent: Wednesday, July 06, 2011 12:26 PM > To: Raphaël Assénat; Paul Walmsley > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: AM3505/3517 support > > * 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. [sp] AM35x is already supported in the kernel. Specifically for the changes being discussed, see this commit: commit 3cc4a2fc2ed7727828f410ab092111cb56cefd61 Author: Ranjith Lohithakshan <ranjithl@xxxxxx> Date: Wed Feb 24 12:05:55 2010 -0700 AM35xx: Add clock support for new modules on AM35xx I believe this patch already contains most AM35xx specific changes related to clocks. > > > > 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. [sp] I did sumbit a similar patch making 2 arrays, but Paul has sumbitted an updated patch that seemes to do away with need to make 2 arrays. http://marc.info/?l=linux-omap&m=129983254729228&w=2 > > > > 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 > -- 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
