Re: AM3505/3517 support

["Raphaël Assénat" <raph@8d.com>]

On 05/07/11 07:19 AM, Tony Lindgren wrote:
> * Raphaël Assénat <raph@8d.com> [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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html