* Paul Walmsley <paul@xxxxxxxxx> [110707 12:09]: > On Tue, 5 Jul 2011, Tony Lindgren wrote: > > > * 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. > > So the idea would be to mark those devices as unavailable from the board > file? > > It sounds possible, but AM35xx also has some devices that are not present > on 34xx chips, like the VPFE, EMAC, and HECC. And there are probably some > other devices that are present on 34xx that are not present on AM35xx, > like SSI, MSPRO, D2D, etc. I suggested to do this initially from board-*.c file to get the board booting. But in the long run this could fixed up with an am35xx arch_initcall like I suggested where the arch_initcall would set up the am35xx specific devices. > I'd suggest adding a separate CHIP_IS_* for those AM35xx chips, as it > sounds like Raphaël has done, since they are different silicon, unlike the > 34xx HS and GP chips, which just have some eFuse differences. The problem is that we're really talking about a very similar chip to other omap3 chips. To me it seems something is wrong if we have to patch all over where the CHIP_IS_* is being used just to add support for a slightly different chip variant. Whatever we need to do we should be able to dynamically based on the SoC features detected. > ... > > This is a bit of a side issue, but right now, the CHIP_IS_* macros are > kind of messed up for OMAP3. That CHIP_IS_OMAP3430 macro is the main > problem. The different CHIP_IS_OMAP* bits were intended to be mutually > exclusive, so only one bit would be set at runtime for a given SoC. Then > superset definitions would be defined as combinations of those bits, for > use with data structures that are common to multiple OMAP3 SoCs. We do > this the right way with OMAP2 and OMAP4, just not with OMAP3. > > I have a patch for this, but part of it involves renaming some > CHIP_IS_OMAP3430 to CHIP_IS_OMAP3XXX, so I've been hesitant to post it -- > sounds like that would be grounds for flaming? Or maybe it can be posted > as a 'cleanup' patch for the 3.2 time frame? Well let's fix things properly so we only need minimal patching to add proper am3505 and 4460 support. If that means renaming something then let's do it. But if it still means that we again have to patch the CHIP_IS all over the place for future omaps, then we really need a better way to fix this. How about if we just had a list for each SoC that listed the devices it has? Then adding support for a new SoC would be just a question of initializing the list and adding the new devices. Patching existing devices would not be needed in that case, and CHIP_IS would only be need to be initialized in one place instead of repeating it for each device. 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
