>-----Original Message----- >From: ext Tony Lindgren [mailto:tony@xxxxxxxxxxx] >Sent: 17 June, 2009 12:58 >To: Paul Walmsley >Cc: Kristo Tero (Nokia-D/Tampere); Kevin Hilman; >linux-omap@xxxxxxxxxxxxxxx >Subject: Re: [PATCH 0/2] adding back some features > >* Paul Walmsley <paul@xxxxxxxxx> [090617 01:35]: >> code comment below: >> >> On Wed, 17 Jun 2009, Tony Lindgren wrote: >> >> > * Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> [090615 09:05]: >> > > Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes: >> > > >> > > > Tony Lindgren <tony@xxxxxxxxxxx> writes: >> > > > >> > > >> Hi, >> > > >> >> > > >> * Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> [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.kristo@xxxxxxxxx> >> > > Date: Thu Oct 9 17:47:02 2008 +0300 >> > > >> > > OMAP3: SRAM size fix for HS/EMU devices >> > > >> > > Signed-off-by: Tero Kristo <tero.kristo@xxxxxxxxx> >> > > Signed-off-by: Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxxxxx> >> > > >> > > 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 majordomo@xxxxxxxxxxxxxxx >> > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html