>-----Original Message-----
>From: ext Tony Lindgren [mailto:t...@atomide.com]
>Sent: 17 June, 2009 12:58
>To: Paul Walmsley
>Cc: Kristo Tero (Nokia-D/Tampere); Kevin Hilman;
>linux-omap@vger.kernel.org
>Subject: Re: [PATCH 0/2] adding back some features
>
>* Paul Walmsley <p...@pwsan.com> [090617 01:35]:
>> code comment below:
>>
>> On Wed, 17 Jun 2009, Tony Lindgren wrote:
>>
>> > * Kevin Hilman <khil...@deeprootsystems.com> [090615 09:05]:
>> > > Kevin Hilman <khil...@deeprootsystems.com> writes:
>> > >
>> > > > Tony Lindgren <t...@atomide.com> writes:
>> > > >
>> > > >> Hi,
>> > > >>
>> > > >> * Kevin Hilman <khil...@deeprootsystems.com> [090612 15:13]:
>> > > >>> Here's a couple patches to add-back some feature dropped in
>> > > >>> the mainline sync. These are needed for the PM
>branch among other things.
>> > > >>>
>> > > >>> Applies to linux-omap master.
>> > > >>>
>> > > >>> Kevin Hilman (1):
>> > > >>> OMAP2/3: SoC IDs: add omap_type() for determining GP/EMU/HS
>> > > >>
>> > > >> Is there any reason to get this one into mainline early?
>> > > >
>> > > > Well, the PM branch has a dependency, but also the recenetly
>> > > > submitted qwatchdog driver has a dependency.
>> > > >
>> > > >> If not, I suggest you keep this in your pm branch for next
>> > > >> merge window that I can keep merging to l-o master as needed.
>> > > >>
>> > > >> However, if omap_type() is by other queues earlier,
>then I can
>> > > >> add it into my upstream queue. If this blocks several queues
>> > > >> from being rebased against mainline kernel, that alone might
>> > > >> already be a good enough reason to get it in early.
>> > > >
>> > > > I think it should go via your upstream queue. I
>imagine some of
>> > > > the other upcoming driver submissions from TI will have a
>> > > > dependency as well since there is still some missing
>EMU/HS support ind drivers.
>> > >
>> > > Also, I'm carrying this SRAM patch below for HS/EMU that
>could go
>> > > into Paul's SRAM/SDRC queue if this omap_type() gets
>merged sooner
>> > > rather than later.
>> >
>> > Hmm, the HS omap sram.c patch below for sure justifies
>fixing it as
>> > incorrect SRAM size can cause nasty bugs.
>> >
>> > Will add both omap_type and the sram.c patch below to omap-fixes.
>> >
>> > Regards,
>> >
>> > Tony
>> >
>> > > Kevin
>> > >
>> > > commit 106588e30f070d9a8d5906d409e0b9aad89edc9e
>> > > Author: Tero Kristo <tero.kri...@nokia.com>
>> > > Date: Thu Oct 9 17:47:02 2008 +0300
>> > >
>> > > OMAP3: SRAM size fix for HS/EMU devices
>> > >
>> > > Signed-off-by: Tero Kristo <tero.kri...@nokia.com>
>> > > Signed-off-by: Kevin Hilman <khil...@ti.deeprootsystems.com>
>> > >
>> > > diff --git a/arch/arm/plat-omap/sram.c
>b/arch/arm/plat-omap/sram.c
>> > > old mode 100644 new mode 100755 index 65006df..f40bd2d
>> > > --- a/arch/arm/plat-omap/sram.c
>> > > +++ b/arch/arm/plat-omap/sram.c
>> > > @@ -131,9 +131,15 @@ void __init omap_detect_sram(void)
>> > > if (cpu_class_is_omap2()) {
>> > > if (is_sram_locked()) {
>> > > if (cpu_is_omap34xx()) {
>> > > - omap_sram_base =
>OMAP3_SRAM_PUB_VA;
>> > > - omap_sram_start =
>OMAP3_SRAM_PUB_PA;
>> > > - omap_sram_size =
>0x8000; /* 32K */
>> > > + if (omap_type() ==
>OMAP2_DEVICE_TYPE_GP) {
>> > > + omap_sram_base
>= OMAP3_SRAM_PUB_VA;
>> > > + omap_sram_start
>= OMAP3_SRAM_PUB_PA;
>> > > + omap_sram_size
>= 0x8000; /* 32K */
>> > > + } else {
>>
>> This would be better if it specifically tested for HS and
>EMU devices.
>> There are at least two other omap_type() possibilities here, "TEST"
>> and "BAD"
>
>Tero, can you please repost? I will hold on sending out the
>omap-fixes for that, and refresh omap-fixes with the updated patch.
I'll try to look at this tomorrow if I happen to have time, I am currently
quite busy fixing some bugs in our code base. However, if you need it right now
and if someone wants to re-write this to check against TEST and BAD, I am of
course okay with that (rather simple fix actually.) :)
-Tero
>
>Tony
>
>
>> > > + omap_sram_base
>= OMAP3_SRAM_PUB_VA;
>> > > + omap_sram_start
>= OMAP3_SRAM_PUB_PA;
>> > > + omap_sram_size
>= 0x7000; /* 28K */
>> > > + }
>> > > } else {
>> > > omap_sram_base =
>OMAP2_SRAM_PUB_VA;
>> > > omap_sram_start =
>OMAP2_SRAM_PUB_PA;
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe
>> > linux-omap" in the body of a message to majord...@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>> >
>>
>>
>> - Paul
>--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
