RE: [PATCH] Fixed OMAP3 version check

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

>-----Original Message-----
>From: ext Tony Lindgren [mailto:tony@xxxxxxxxxxx] 
>Sent: 25 September, 2008 14:50
>To: Kristo Tero (Nokia-D/Tampere)
>Cc: Balbi Felipe (Nokia-D/Helsinki); linux-omap@xxxxxxxxxxxxxxx
>Subject: Re: [PATCH] Fixed OMAP3 version check
>
>* Tony Lindgren <tony@xxxxxxxxxxx> [080925 14:47]:
>> * Tero.Kristo@xxxxxxxxx <Tero.Kristo@xxxxxxxxx> [080925 14:45]:
>> >  
>> > 
>> > >-----Original Message-----
>> > >From: Balbi Felipe (Nokia-D/Helsinki)
>> > >Sent: 25 September, 2008 14:41
>> > >To: ext Tony Lindgren
>> > >Cc: Balbi Felipe (Nokia-D/Helsinki); Kristo Tero 
>(Nokia-D/Tampere); 
>> > >linux-omap@xxxxxxxxxxxxxxx
>> > >Subject: Re: [PATCH] Fixed OMAP3 version check
>> > >
>> > >On Thu, Sep 25, 2008 at 01:31:21PM +0300, Tony Lindgren wrote:
>> > >> * Felipe Balbi <felipe.balbi@xxxxxxxxx> [080925 13:24]:
>> > >> > On Thu, Sep 25, 2008 at 01:17:51PM +0300, Tony Lindgren wrote:
>> > >> > > Hi,
>> > >> > > 
>> > >> > > * Tero Kristo <tero.kristo@xxxxxxxxx> [080916 14:59]:
>> > >> > > > CPU version was reported incorrectly (e.g. ES3.0 
>instead of
>> > >> > > > ES2.1.) Also added a piece of optimization for CPU
>> > >type check (omap_type()).
>> > >> > > > 
>> > >> > > > Signed-off-by: Tero Kristo <tero.kristo@xxxxxxxxx>
>> > >> > > > ---
>> > >> > > >  arch/arm/mach-omap2/id.c |    7 +++++--
>> > >> > > >  1 files changed, 5 insertions(+), 2 deletions(-)
>> > >> > > > 
>> > >> > > > diff --git a/arch/arm/mach-omap2/id.c
>> > >b/arch/arm/mach-omap2/id.c
>> > >> > > > index ab7a6e9..4e2b449 100644
>> > >> > > > --- a/arch/arm/mach-omap2/id.c
>> > >> > > > +++ b/arch/arm/mach-omap2/id.c
>> > >> > > > @@ -37,7 +37,10 @@ EXPORT_SYMBOL(omap_chip_is);
>> > >> > > >  
>> > >> > > >  int omap_type(void)
>> > >> > > >  {
>> > >> > > > -	u32 val = 0;
>> > >> > > > +	static u32 val;
>> > >> > > > +
>> > >> > > > +	if (val != 0)
>> > >> > > > +		return val;
>> > >> > > 
>> > >> > > Hmm I guess this would return a random val? :)
>> > >> > 
>> > >> > it would return 0, look that val is static.
>> > >> 
>> > >> Ah, sorry I did not see the static. So this is to cache the
>> > >result to
>> > >> optimize it? I'd assume this function is only needed during
>> > >some init
>> > >> code hopefully where performance does not matter..
>> > >
>> > >Yeah, it's not like we're gonna check the revision after 
>the board 
>> > >is botted all up I guess.
>> > 
>> > PM code will need to either cache the type information or 
>call this 
>> > check every time when entering off-mode. Some things work 
>> > differently in secure chips. Could probably just cache 
>this inside PM code.
>> 
>> How about setting up the save and restore registers properly for GP 
>> and HS omap once during PM init?
>
>To clarify: Set the save and restore registers and needed 
>functions only once during PM init depending on the omap type.

That would be possible also. We only have two additional things to do in
secure OMAP chips anyway, so it is not a big deal. Need to get the damn
thing working first though, can think about optimizations later. >.<

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

[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux