AM3505/3517 support

AM3505/3517 support

[Raphaël Assénat]

Hello,

We have a custom designed based on the AM3505 and we wish to run a modern kernel
on it. Unfortunately, it seems a lot of efforts have been made to support other 
OMAP chips and that some work is still required to support the AM3505/3517 
completely. (does not boot as-is)

Is there anyone working on this right now? Not knowing, I have already started
working on it.

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.

I will send my patches in a moment for comments and hopefully, after a 
few iterations, they will be acceptable. I know a lot of cleanup is 
happening right now and as a result my patches may not apply or conflict. 
Please let me know and I will be happy to rebase them as needed.

Looking forward to your comments and help. 

One of the next things I'll look at is how to properly support the ZCN package.
Right now, the CBB package is used (board-am3517evm.c for instance) but there
are differences that prevent some GPIOs from being configured properly. It would
be nice to know if someone is working on this before I start...

Best regards,
Raphaël Assénat
8D Technologies inc.
--
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

RE: AM3505/3517 support

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Raphaël Assénat
> Sent: Tuesday, July 05, 2011 12:59 AM
> To: linux-omap@vger.kernel.org
> Subject: AM3505/3517 support
> 
> Hello,
> 
> We have a custom designed based on the AM3505 and we wish to 
> run a modern kernel
> on it. Unfortunately, it seems a lot of efforts have been 
> made to support other 
> OMAP chips and that some work is still required to support 
> the AM3505/3517 
> completely. (does not boot as-is)
> 
> Is there anyone working on this right now? Not knowing, I 
> have already started
> working on it.
> 
> 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.
> 
> I will send my patches in a moment for comments and 
> hopefully, after a 
> few iterations, they will be acceptable. I know a lot of cleanup is 
> happening right now and as a result my patches may not apply 
> or conflict. 
> Please let me know and I will be happy to rebase them as needed.
> 
> Looking forward to your comments and help. 
> 
> One of the next things I'll look at is how to properly 
> support the ZCN package.
> Right now, the CBB package is used (board-am3517evm.c for 
> instance) but there
> are differences that prevent some GPIOs from being configured 
> properly. It would
> be nice to know if someone is working on this before I start...

Raphael,

The AM35x support has been trailing on the linux-omap. Usually,
due to delays in dependency resolution:

If you are not specifically looking for the latest kernel,
revision you can get the sources from:
http://arago-project.org/git/projects/?p=linux-omap3.git

Use the tag: v2.6.37_OMAPPSP_04.02.00.07

This tree is supported by TI. The patches contained here, are
being reworked for upstream submission...

~sanjeev

> 
> Best regards,
> Raphaël Assénat
> 8D Technologies inc.
> --
> 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
> --
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

Re: AM3505/3517 support

[Raphaël Assénat]

On 05/07/11 05:59 AM, Premi, Sanjeev wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org 
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Raphaël Assénat
>> Sent: Tuesday, July 05, 2011 12:59 AM
>> To: linux-omap@vger.kernel.org
>> Subject: AM3505/3517 support
>>
>> Hello,
>>
>> We have a custom designed based on the AM3505 and we wish to 
>> run a modern kernel
>> on it. Unfortunately, it seems a lot of efforts have been 
>> made to support other 
>> OMAP chips and that some work is still required to support 
>> the AM3505/3517 
>> completely. (does not boot as-is)
>>
>> Is there anyone working on this right now? Not knowing, I 
>> have already started
>> working on it.
>>
>> 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.
>>
>> I will send my patches in a moment for comments and 
>> hopefully, after a 
>> few iterations, they will be acceptable. I know a lot of cleanup is 
>> happening right now and as a result my patches may not apply 
>> or conflict. 
>> Please let me know and I will be happy to rebase them as needed.
>>
>> Looking forward to your comments and help. 
>>
>> One of the next things I'll look at is how to properly 
>> support the ZCN package.
>> Right now, the CBB package is used (board-am3517evm.c for 
>> instance) but there
>> are differences that prevent some GPIOs from being configured 
>> properly. It would
>> be nice to know if someone is working on this before I start...
> 
> Raphael,
> 
> The AM35x support has been trailing on the linux-omap. Usually,
> due to delays in dependency resolution:
> 
> If you are not specifically looking for the latest kernel,
> revision you can get the sources from:
> http://arago-project.org/git/projects/?p=linux-omap3.git
> 
> Use the tag: v2.6.37_OMAPPSP_04.02.00.07
> 
> This tree is supported by TI. The patches contained here, are
> being reworked for upstream submission...
When possible, I prefer working on the latest version. But at least
I'll have a look to make sure I'm not duplicating anyone's work.

By the way, is there a specific mailing list for discussing
this git tree?

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

RE: AM3505/3517 support

[Premi, Sanjeev]

> -----Original Message-----
> From: Raphaël Assénat [mailto:raph@8d.com] 
> Sent: Wednesday, July 06, 2011 7:29 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: AM3505/3517 support
> 
> On 05/07/11 05:59 AM, Premi, Sanjeev wrote:
> >> -----Original Message-----
> >> From: linux-omap-owner@vger.kernel.org 
> >> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of 
> Raphaël Assénat
> >> Sent: Tuesday, July 05, 2011 12:59 AM
> >> To: linux-omap@vger.kernel.org
> >> Subject: AM3505/3517 support
> >>
> >> Hello,
> >>
> >> We have a custom designed based on the AM3505 and we wish to 
> >> run a modern kernel
> >> on it. Unfortunately, it seems a lot of efforts have been 
> >> made to support other 
> >> OMAP chips and that some work is still required to support 
> >> the AM3505/3517 
> >> completely. (does not boot as-is)
> >>
> >> Is there anyone working on this right now? Not knowing, I 
> >> have already started
> >> working on it.
> >>
> >> 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.
> >>
> >> I will send my patches in a moment for comments and 
> >> hopefully, after a 
> >> few iterations, they will be acceptable. I know a lot of 
> cleanup is 
> >> happening right now and as a result my patches may not apply 
> >> or conflict. 
> >> Please let me know and I will be happy to rebase them as needed.
> >>
> >> Looking forward to your comments and help. 
> >>
> >> One of the next things I'll look at is how to properly 
> >> support the ZCN package.
> >> Right now, the CBB package is used (board-am3517evm.c for 
> >> instance) but there
> >> are differences that prevent some GPIOs from being configured 
> >> properly. It would
> >> be nice to know if someone is working on this before I start...
> > 
> > Raphael,
> > 
> > The AM35x support has been trailing on the linux-omap. Usually,
> > due to delays in dependency resolution:
> > 
> > If you are not specifically looking for the latest kernel,
> > revision you can get the sources from:
> > http://arago-project.org/git/projects/?p=linux-omap3.git
> > 
> > Use the tag: v2.6.37_OMAPPSP_04.02.00.07
> > 
> > This tree is supported by TI. The patches contained here, are
> > being reworked for upstream submission...
> When possible, I prefer working on the latest version. But at least
> I'll have a look to make sure I'm not duplicating anyone's work.
> 
> By the way, is there a specific mailing list for discussing
> this git tree?

[sp] There is no mailing list. But you can use the e2e.ti.com.
     Select "Linux Forum" under "Embedded Software" to post query.

~sanjeev

> 
> 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

Re: AM3505/3517 support

[Tony Lindgren]

* 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?

I'd rather see us improve the code so we can support am3505 properly without
a need to patch all over the place..

> One of the next things I'll look at is how to properly support the ZCN package.
> Right now, the CBB package is used (board-am3517evm.c for instance) but there
> are differences that prevent some GPIOs from being configured properly. It would
> be nice to know if someone is working on this before I start...

You should be able to handle the differences easily just by adding a
new package_subset to mux34xx.c, that just overrides the desired pins
in omap3_muxmodes. Eventually we will be using device tree + common
mux framework for this, but you might as well do the omap3_znc_subset
meanwhile as we can then generate the device tree entries for all of
them. That is assuming it's not a huge delta from omap3_muxmodes :)

Regards,

Tony
--
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

Re: AM3505/3517 support

[Raphaël Assénat]

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

Re: AM3505/3517 support

[Tony Lindgren]

* Raphaël Assénat <raph@8d.com> [110705 07:30]:
> 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.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: AM3505/3517 support

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
> Sent: Wednesday, July 06, 2011 12:26 PM
> To: Raphaël Assénat; Paul Walmsley
> Cc: linux-omap@vger.kernel.org
> Subject: Re: AM3505/3517 support
> 
> * Raphaël Assénat <raph@8d.com> [110705 07:30]:
> > 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.
> 
> 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@ti.com>
    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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AM3505/3517 support

[Raphaël Assénat]

On 06/07/11 04:54 AM, Premi, Sanjeev wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org 
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony Lindgren
>> Sent: Wednesday, July 06, 2011 12:26 PM
>> To: Raphaël Assénat; Paul Walmsley
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: AM3505/3517 support
>>
>> * Raphaël Assénat <raph@8d.com> [110705 07:30]:
>>> 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.
>>
>> 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@ti.com>
>     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.
Indeed, most of these changes are present in the current kernel. But right now,
it does not work as-is. Only a few things are missing and that's what I'm 
trying to address. I'll try Tony's suggestion. It should yield a much smaller
patch.
--
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

Re: AM3505/3517 support

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4600 bytes --]

On Tue, 5 Jul 2011, Tony Lindgren wrote:

> * Raphaël Assénat <raph@8d.com> [110705 07:30]:
> > 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.
> 
> 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'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.

...

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?

> 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.

For what it's worth, there are some patches here that are 3.2 material 
that hopefully will make it easier to share hwmod data between different 
chips with large portions that are similar.

> > 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.


- Paul

Re: AM3505/3517 support

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [110707 12:09]:
> On Tue, 5 Jul 2011, Tony Lindgren wrote:
> 
> > * Raphaël Assénat <raph@8d.com> [110705 07:30]:
> > > 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.
> > 
> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html