SR1: VDD autocomp is not active

SR1: VDD autocomp is not active

[Sergey Lapin]

Hi, all!

on my OMAP3525-based custom board I get SR1: VDD autocomp is not
active and SR2: VDD autocomp is not active
quite frequently with PM branch. What that means, and how to fix it?

Thanks a lot,
S.

RE: SR1: VDD autocomp is not active

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org 
> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Sergey Lapin
> Sent: Tuesday, December 01, 2009 5:24 PM
> To: linux-omap@vger.kernel.org
> Subject: SR1: VDD autocomp is not active
> 
> Hi, all!
> 
> on my OMAP3525-based custom board I get SR1: VDD autocomp is not
> active and SR2: VDD autocomp is not active
> quite frequently with PM branch. What that means, and how to fix it?

Do you see them while trying to set the sr_vdd[1|2]_autocomp?
OR
During normal execution?

What is the silicon version reported when Linux kernel boot up?

~sanjeev

> 
> Thanks a lot,
> S.
> --
> 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: SR1: VDD autocomp is not active

[Sergey Lapin]

On Tue, Dec 1, 2009 at 7:08 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Sergey Lapin
>> Sent: Tuesday, December 01, 2009 5:24 PM
>> To: linux-omap@vger.kernel.org
>> Subject: SR1: VDD autocomp is not active
>>
>> Hi, all!
>>
>> on my OMAP3525-based custom board I get SR1: VDD autocomp is not
>> active and SR2: VDD autocomp is not active
>> quite frequently with PM branch. What that means, and how to fix it?
>
> Do you see them while trying to set the sr_vdd[1|2]_autocomp?
> OR
> During normal execution?
During normal execution.

>
> What is the silicon version reported when Linux kernel boot up?
OMAP3525 ES2.1 (l2cache iva neon isp )

S.

RE: SR1: VDD autocomp is not active

[Premi, Sanjeev]

________________________________________
From: Sergey Lapin [slapinid@gmail.com]
Sent: Tuesday, December 01, 2009 10:34 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: SR1: VDD autocomp is not active

On Tue, Dec 1, 2009 at 7:08 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: linux-omap-owner@vger.kernel.org
>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Sergey Lapin
>> Sent: Tuesday, December 01, 2009 5:24 PM
>> To: linux-omap@vger.kernel.org
>> Subject: SR1: VDD autocomp is not active
>>
>> Hi, all!
>>
>> on my OMAP3525-based custom board I get SR1: VDD autocomp is not
>> active and SR2: VDD autocomp is not active
>> quite frequently with PM branch. What that means, and how to fix it?
>
> Do you see them while trying to set the sr_vdd[1|2]_autocomp?
> OR
> During normal execution?
During normal execution.

>
> What is the silicon version reported when Linux kernel boot up?
OMAP3525 ES2.1 (l2cache iva neon isp )

I did notice an earlier mail where you mentioned about using an older
kernel version. have to back-ported patches specific to silicon
identification on this kernel/

It appears that efuse data required for SmartReflex to work may not
be available on this silicon... leading to these messages.

Right now, I am away from source code, will be able to verify in the
morning.

S.

Re: SR1: VDD autocomp is not active

[Sergey Lapin]

Hi, all! It seems discussion went off-list somehow, so I won't delete
some quoting.

On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: Sergey Lapin [mailto:slapinid@gmail.com]
>> Sent: Wednesday, December 02, 2009 1:54 AM
>> To: Premi, Sanjeev
>> Subject: Re: SR1: VDD autocomp is not active
>>
>> > I did notice an earlier mail where you mentioned about
>> using an older
>> > kernel version. have to back-ported patches specific to silicon
>> > identification on this kernel/
>> I use PM branch of linux-omap git.
>> I just need to make my patches less disgusting by properly
>> porting these.
>> Actually now I think I could do this work even without
>> appropriate tree, since
>> amount of patches is not that big and API is not too different.  These
>> patches are
>> not required to make board basically run.
>>
>> >
>> > It appears that efuse data required for SmartReflex to work may not
>> > be available on this silicon... leading to these messages.
>> >
>> > Right now, I am away from source code, will be able to verify in the
>> > morning.
>> Thanks, looking forward for your reply.
>
> You should try this with an ES3.1 silicon. If sr_enable() fails, we might
> see this issue.
It seems I only have ES2.1 silicon, so what should I do
- disable SR functionality at all
- somehow set values the other way?
It seems SR is possible on this silicon, only efuse data are absent,
so is there a way I could somehow fake these (with some known working values),
so the stuff works?

Thanks a lot,
S.



>
>>
>> S.
>>

RE: SR1: VDD autocomp is not active

[Premi, Sanjeev]

> -----Original Message-----
> From: Sergey Lapin [mailto:slapinid@gmail.com] 
> Sent: Wednesday, December 02, 2009 5:35 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: SR1: VDD autocomp is not active
> 
> Hi, all! It seems discussion went off-list somehow, so I won't delete
> some quoting.
> 
> On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev <premi@ti.com> wrote:
> >> -----Original Message-----
> >> From: Sergey Lapin [mailto:slapinid@gmail.com]
> >> Sent: Wednesday, December 02, 2009 1:54 AM
> >> To: Premi, Sanjeev
> >> Subject: Re: SR1: VDD autocomp is not active
> >>
> >> > I did notice an earlier mail where you mentioned about
> >> using an older
> >> > kernel version. have to back-ported patches specific to silicon
> >> > identification on this kernel/
> >> I use PM branch of linux-omap git.
> >> I just need to make my patches less disgusting by properly
> >> porting these.
> >> Actually now I think I could do this work even without
> >> appropriate tree, since
> >> amount of patches is not that big and API is not too 
> different.  These
> >> patches are
> >> not required to make board basically run.
> >>
> >> >
> >> > It appears that efuse data required for SmartReflex to 
> work may not
> >> > be available on this silicon... leading to these messages.
> >> >
> >> > Right now, I am away from source code, will be able to 
> verify in the
> >> > morning.
> >> Thanks, looking forward for your reply.
> >
> > You should try this with an ES3.1 silicon. If sr_enable() 
> fails, we might
> > see this issue.
> It seems I only have ES2.1 silicon, so what should I do
> - disable SR functionality at all
[sp] Yes. It will be a good starting point.

> - somehow set values the other way?
[sp] It will be difficult for you to ascertain these values.

> It seems SR is possible on this silicon, only efuse data are absent,
> so is there a way I could somehow fake these (with some known 
> working values),
> so the stuff works?

[sp] The code will allow you to do so; but without right values
     kernel execution can go haywire.

Best regards,
Sanjeev

> 
> Thanks a lot,
> S.
> 
> 
> 
> >
> >>
> >> S.
> >>
> 

Re: SR1: VDD autocomp is not active

[Sergey Lapin]

On Wed, Dec 2, 2009 at 3:19 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> -----Original Message-----
>> From: Sergey Lapin [mailto:slapinid@gmail.com]
>> Sent: Wednesday, December 02, 2009 5:35 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: SR1: VDD autocomp is not active
>>
>> Hi, all! It seems discussion went off-list somehow, so I won't delete
>> some quoting.
>>
>> On Wed, Dec 2, 2009 at 2:38 PM, Premi, Sanjeev <premi@ti.com> wrote:
>> >> -----Original Message-----
>> >> From: Sergey Lapin [mailto:slapinid@gmail.com]
>> >> Sent: Wednesday, December 02, 2009 1:54 AM
>> >> To: Premi, Sanjeev
>> >> Subject: Re: SR1: VDD autocomp is not active
>> >>
>> >> > I did notice an earlier mail where you mentioned about
>> >> using an older
>> >> > kernel version. have to back-ported patches specific to silicon
>> >> > identification on this kernel/
>> >> I use PM branch of linux-omap git.
>> >> I just need to make my patches less disgusting by properly
>> >> porting these.
>> >> Actually now I think I could do this work even without
>> >> appropriate tree, since
>> >> amount of patches is not that big and API is not too
>> different.  These
>> >> patches are
>> >> not required to make board basically run.
>> >>
>> >> >
>> >> > It appears that efuse data required for SmartReflex to
>> work may not
>> >> > be available on this silicon... leading to these messages.
>> >> >
>> >> > Right now, I am away from source code, will be able to
>> verify in the
>> >> > morning.
>> >> Thanks, looking forward for your reply.
>> >
>> > You should try this with an ES3.1 silicon. If sr_enable()
>> fails, we might
>> > see this issue.
>> It seems I only have ES2.1 silicon, so what should I do
>> - disable SR functionality at all
> [sp] Yes. It will be a good starting point.
>
>> - somehow set values the other way?
> [sp] It will be difficult for you to ascertain these values.
>
>> It seems SR is possible on this silicon, only efuse data are absent,
>> so is there a way I could somehow fake these (with some known
>> working values),
>> so the stuff works?
>
> [sp] The code will allow you to do so; but without right values
>     kernel execution can go haywire.

Is it possible somehow to identify right silicon revision before ordering?
I mean by part number or something?

Also, is there some safe numbers somebody knows about, or is there
some way of generating them?

S.

Re: SR1: VDD autocomp is not active

[Sergey Lapin]

>>
>> [sp] The code will allow you to do so; but without right values
>>     kernel execution can go haywire.
>
> Is it possible somehow to identify right silicon revision before ordering?
> I mean by part number or something?
Sorry for my ignorance, I've found answer on first question (answer is
to read errata properly).

>
> Also, is there some safe numbers somebody knows about, or is there
> some way of generating them?
I still persist with this question, though.

Re: SR1: VDD autocomp is not active

[Sergey Lapin]

On Wed, Dec 2, 2009 at 4:33 PM, Sergey Lapin <slapinid@gmail.com> wrote:
>>>
>>> [sp] The code will allow you to do so; but without right values
>>>     kernel execution can go haywire.
>>
>> Is it possible somehow to identify right silicon revision before ordering?
>> I mean by part number or something?
> Sorry for my ignorance, I've found answer on first question (answer is
> to read errata properly).
>
>>
>> Also, is there some safe numbers somebody knows about, or is there
>> some way of generating them?
> I still persist with this question, though.
>
Resume: kernel seems to hang wit SRF disabled and PM enabled.
As I have advantage of saving lots of power with PM.
disabling SRF seems not to be an option. So
it either have to be left as is or numbers should be provided
(possibly for even better tasty power saving!)

Thanks a lot for your help,
S.

RE: SR1: VDD autocomp is not active

[Premi, Sanjeev]

> -----Original Message-----
> From: Sergey Lapin [mailto:slapinid@gmail.com] 
> Sent: Wednesday, December 02, 2009 7:04 PM
> To: Premi, Sanjeev
> Cc: linux-omap@vger.kernel.org
> Subject: Re: SR1: VDD autocomp is not active
> 
> >>
> >> [sp] The code will allow you to do so; but without right values
> >>     kernel execution can go haywire.
> >
> > Is it possible somehow to identify right silicon revision 
> before ordering?
> > I mean by part number or something?
> Sorry for my ignorance, I've found answer on first question (answer is
> to read errata properly).
> 
> >
> > Also, is there some safe numbers somebody knows about, or is there
> > some way of generating them?
> I still persist with this question, though.

[sp] These numbers are based on silicon characterization process.
     There is no other way to generate them. The numbers can change
     between silicon lots.

Best regards,
Sanjeev

Re: SR1: VDD autocomp is not active

[Nishanth Menon]

Premi, Sanjeev said the following on 12/02/2009 04:23 PM:
>> -----Original Message-----
>> From: Sergey Lapin [mailto:slapinid@gmail.com] 
>> Sent: Wednesday, December 02, 2009 7:04 PM
>> To: Premi, Sanjeev
>> Cc: linux-omap@vger.kernel.org
>> Subject: Re: SR1: VDD autocomp is not active
>>
>>     
>>>> [sp] The code will allow you to do so; but without right values
>>>>     kernel execution can go haywire.
>>>>         
Actually the entire silicon can go haywire due to bad voltages. :( yep
kernel can go crazy as a result..

>>> Is it possible somehow to identify right silicon revision 
>>>       
>> before ordering?
>>     
>>> I mean by part number or something?
>>>       
>> Sorry for my ignorance, I've found answer on first question (answer is
>> to read errata properly).
>>
>>     
>>> Also, is there some safe numbers somebody knows about, or is there
>>> some way of generating them?
>>>       
>> I still persist with this question, though.
>>     
>
> [sp] These numbers are based on silicon characterization process.
>      There is no other way to generate them. The numbers can change
>      between silicon lots.
>
>   
Actually can change even between silicons themselves. This is part of
EFUSE values which we write on to each of the silicon. If the chip does
not have SR NVALUES EFUSED, two options:
a) Get a new chip which has SR enabled (or a platform such as zoom2 with
3430 ES3.1 silicon)
b) Disable smartreflex :(

Regards,
Nishanth Menon

PS: NOT recommended: you could choose to play around with my original
patch for SR http://marc.info/?l=linux-omap&m=125623250803526&w=2 esp
looking at the script involved. but I would not recommend to use it on a
production system.