<Tero.Kristo@xxxxxxxxx> writes: > > >>-----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.) :) > OK, I've sent an updated patch to the list, along with a revert of the original so it's easier to sned upstream. Kevin -- 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
