> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Tony Lindgren
> Sent: Wednesday, July 06, 2011 12:26 PM
> To: Raphaël Assénat; Paul Walmsley
> Cc: [email protected]
> Subject: Re: AM3505/3517 support
>
> * Raphaël Assénat <[email protected]> [110705 07:30]:
> > On 05/07/11 07:19 AM, Tony Lindgren wrote:
> > > * Raphaël Assénat <[email protected]> [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 <[email protected]>
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 [email protected]
> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
