[PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Nayak, Rajendra]

Re-sending this patch-set with some mailer issues resolved. They now apply cleanly
with a git-am/git-apply.

Hi,

This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now
functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse.

The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis
instead of calls to SRF.

Patches apply on top of the latest pm branch from Kevin's pm tree.
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 

regards,
Rajendra

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

> Re-sending this patch-set with some mailer issues resolved. They now apply cleanly
> with a git-am/git-apply.
>
> Hi,
>
> This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now
> functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse.
>
> The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis
> instead of calls to SRF.
>
> Patches apply on top of the latest pm branch from Kevin's pm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
>

Thanks, pushing this series to PM branch.

Kevin

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

> Re-sending this patch-set with some mailer issues resolved. They now apply cleanly
> with a git-am/git-apply.
>
> Hi,
>
> This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now
> functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse.
>
> The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis
> instead of calls to SRF.
>
> Patches apply on top of the latest pm branch from Kevin's pm tree.
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 

Rajendra,

This series seems to boot on SDP and Beagle but I recetly tried on
RX51 and it hangs in omap3_sr_init().

Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
PRM write to the PRM_VP1_VLIMITTO register:

		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
					PRM_VP1_VLIMITTO_VDDMIN |
					PRM_VP1_VLIMITTO_TIMEOUT,
					OMAP3430_GR_MOD,
					OMAP3_PRM_VP1_VLIMITTO_OFFSET);


Should these min/max/timeout values be board specific?

Kevin

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Roger Quadros]

ext Kevin Hilman wrote:
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
>> Re-sending this patch-set with some mailer issues resolved. They now apply cleanly
>> with a git-am/git-apply.
>>
>> Hi,
>>
>> This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now
>> functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse.
>>
>> The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis
>> instead of calls to SRF.
>>
>> Patches apply on top of the latest pm branch from Kevin's pm tree.
>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 
> 
> Rajendra,
> 
> This series seems to boot on SDP and Beagle but I recetly tried on
> RX51 and it hangs in omap3_sr_init().
> 
> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
> PRM write to the PRM_VP1_VLIMITTO register:
> 
> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
> 					PRM_VP1_VLIMITTO_VDDMIN |
> 					PRM_VP1_VLIMITTO_TIMEOUT,
> 					OMAP3430_GR_MOD,
> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
> 
> 
> Should these min/max/timeout values be board specific?
> 
> Kevin
> --
> 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
> 

It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of CONFIG_OMAP_PM_NOOP.

Should Smartreflex option be dependent or independent of the CONFIG_OMAP_PM_??? 
setting?

-roger

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Kevin Hilman]

Roger Quadros <ext-roger.quadros@nokia.com> writes:

> ext Kevin Hilman wrote:
[...]
>>
>> Rajendra,
>>
>> This series seems to boot on SDP and Beagle but I recetly tried on
>> RX51 and it hangs in omap3_sr_init().
>>
>> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
>> PRM write to the PRM_VP1_VLIMITTO register:
>>
>> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
>> 					PRM_VP1_VLIMITTO_VDDMIN |
>> 					PRM_VP1_VLIMITTO_TIMEOUT,
>> 					OMAP3430_GR_MOD,
>> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
>>
>>
>> Should these min/max/timeout values be board specific?
>>

[...]

>
> It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of CONFIG_OMAP_PM_NOOP.
>
> Should Smartreflex option be dependent or independent of the
> CONFIG_OMAP_PM_??? setting?
>

I see the same thing on SDP as well as RX51.

It looks like the new SR code assumes a range of OPPs, but when
OMAP_PM_NONE is enabled, the omap_pm_vddX_get_opp() calls always
return zero.

In the mpu_opps array, the first entry is all zeros, resulting
in a zero VSEL which is then used to (re)program the VP.

The SR code should probably be a bit smarter about checking for valid
values.

Kevin

RE: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Nayak, Rajendra]

 

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
> Sent: Saturday, April 25, 2009 4:21 AM
> To: Roger Quadros
> Cc: Nayak, Rajendra; linux-omap
> Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
> 
> Roger Quadros <ext-roger.quadros@nokia.com> writes:
> 
> > ext Kevin Hilman wrote:
> [...]
> >>
> >> Rajendra,
> >>
> >> This series seems to boot on SDP and Beagle but I recetly tried on
> >> RX51 and it hangs in omap3_sr_init().
> >>
> >> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
> >> PRM write to the PRM_VP1_VLIMITTO register:
> >>
> >> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
> >> 					PRM_VP1_VLIMITTO_VDDMIN |
> >> 					PRM_VP1_VLIMITTO_TIMEOUT,
> >> 					OMAP3430_GR_MOD,
> >> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
> >>
> >>
> >> Should these min/max/timeout values be board specific?
> >>
> 
> [...]
> 
> >
> > It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of 
> CONFIG_OMAP_PM_NOOP.
> >
> > Should Smartreflex option be dependent or independent of the
> > CONFIG_OMAP_PM_??? setting?
> >
> 
> I see the same thing on SDP as well as RX51.
> 
> It looks like the new SR code assumes a range of OPPs, but when
> OMAP_PM_NONE is enabled, the omap_pm_vddX_get_opp() calls always
> return zero.
> 
> In the mpu_opps array, the first entry is all zeros, resulting
> in a zero VSEL which is then used to (re)program the VP.
> 
> The SR code should probably be a bit smarter about checking for valid
> values.
> 

Kevin,

I'll send in a patch to fix that.

thanks,
Rajendra

> 
> 
> 
> 
> 

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Roger Quadros]

ext Nayak, Rajendra wrote:
>  
> 
>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>> Sent: Saturday, April 25, 2009 4:21 AM
>> To: Roger Quadros
>> Cc: Nayak, Rajendra; linux-omap
>> Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
>>
>> Roger Quadros <ext-roger.quadros@nokia.com> writes:
>>
>>> ext Kevin Hilman wrote:
>> [...]
>>>> Rajendra,
>>>>
>>>> This series seems to boot on SDP and Beagle but I recetly tried on
>>>> RX51 and it hangs in omap3_sr_init().
>>>>
>>>> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
>>>> PRM write to the PRM_VP1_VLIMITTO register:
>>>>
>>>> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
>>>> 					PRM_VP1_VLIMITTO_VDDMIN |
>>>> 					PRM_VP1_VLIMITTO_TIMEOUT,
>>>> 					OMAP3430_GR_MOD,
>>>> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
>>>>
>>>>
>>>> Should these min/max/timeout values be board specific?
>>>>
>> [...]
>>
>>> It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of 
>> CONFIG_OMAP_PM_NOOP.
>>> Should Smartreflex option be dependent or independent of the
>>> CONFIG_OMAP_PM_??? setting?
>>>
>> I see the same thing on SDP as well as RX51.
>>
>> It looks like the new SR code assumes a range of OPPs, but when
>> OMAP_PM_NONE is enabled, the omap_pm_vddX_get_opp() calls always
>> return zero.
>>
>> In the mpu_opps array, the first entry is all zeros, resulting
>> in a zero VSEL which is then used to (re)program the VP.
>>
>> The SR code should probably be a bit smarter about checking for valid
>> values.
>>
> 
> Kevin,
> 
> I'll send in a patch to fix that.
> 
> thanks,
> Rajendra
> 
>>
>>
>>

I think the the X_get_opp() and X_get_freq() calls should be returning
sane values irrespective of PM layer (i.e. OMAP_PM_NOOP or OMAP_PM_NONE).
I have a patchset which does this with a little help from resource.c to get
the current OPP/frequency.
This fixes boot on RX51 for both PM_NOOP and PM_NONE with SMARTREFLEX enabled.

I just want to know if this is the right way to do. I think it would be because
Smartreflex or any other future driver will not have to worry about which PM 
layer is selected.

I will send my patchset as an RFC.

regards,
-roger

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 1692 bytes --]


Op 24 apr 2009, om 08:46 heeft Roger Quadros het volgende geschreven:

> ext Kevin Hilman wrote:
>> "Nayak, Rajendra" <rnayak@ti.com> writes:
>>> Re-sending this patch-set with some mailer issues resolved. They  
>>> now apply cleanly
>>> with a git-am/git-apply.
>>>
>>> Hi,
>>>
>>> This series fixes a set of defects/issues in Smartreflex driver.  
>>> SR autocompensation is now
>>> functional and is validated with these patches on a ES3.1 based  
>>> SDP with the N values in Efuse.
>>>
>>> The patches also make the Smartreflex driver independent of SRF by  
>>> using the OMAP PM apis
>>> instead of calls to SRF.
>>>
>>> Patches apply on top of the latest pm branch from Kevin's pm tree.
>>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap- 
>>> pm.git
>> Rajendra,
>> This series seems to boot on SDP and Beagle but I recetly tried on
>> RX51 and it hangs in omap3_sr_init().
>> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
>> PRM write to the PRM_VP1_VLIMITTO register:
>> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
>> 					PRM_VP1_VLIMITTO_VDDMIN |
>> 					PRM_VP1_VLIMITTO_TIMEOUT,
>> 					OMAP3430_GR_MOD,
>> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
>> Should these min/max/timeout values be board specific?
>> Kevin
>> --
>> 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
>
> It runs on rx51 if we set CONFIG_OMAP_PM_SRF instead of  
> CONFIG_OMAP_PM_NOOP.

I can confirm that switching to CONFIG_OMAP_PM_SRF fixes a similar  
problem I'm seeing on a gumstix overo.

regards,

Koen


[-- Attachment #2: Dit deel van het bericht is digitaal ondertekend --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

RE: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Nayak, Rajendra]

> -----Original Message-----
> From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
> Sent: Thursday, April 23, 2009 1:35 AM
> To: Nayak, Rajendra
> Cc: linux-omap
> Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
> 
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> 
> > Re-sending this patch-set with some mailer issues resolved. 
> They now apply cleanly
> > with a git-am/git-apply.
> >
> > Hi,
> >
> > This series fixes a set of defects/issues in Smartreflex 
> driver. SR autocompensation is now
> > functional and is validated with these patches on a ES3.1 
> based SDP with the N values in Efuse.
> >
> > The patches also make the Smartreflex driver independent of 
> SRF by using the OMAP PM apis
> > instead of calls to SRF.
> >
> > Patches apply on top of the latest pm branch from Kevin's pm tree.
> > 
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om
> ap-pm.git 
> 
> Rajendra,
> 
> This series seems to boot on SDP and Beagle but I recetly tried on
> RX51 and it hangs in omap3_sr_init().
> 
> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
> PRM write to the PRM_VP1_VLIMITTO register:
> 
> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
> 					PRM_VP1_VLIMITTO_VDDMIN |
> 					PRM_VP1_VLIMITTO_TIMEOUT,
> 					OMAP3430_GR_MOD,
> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
> 
> 
> Should these min/max/timeout values be board specific?

Kevin,

These values I remember we got from the SiVal team here at TI, I don't think they are board specific.
I can check up more on that from them.
Btw, does the hang happen only with my patchset applied, because the patchset does not change
any of these values.

I don't have access to the RX51 h/w this week, so I can debug more on this next week once I have access
to it.

regards,
Rajendra

> 
> Kevin
> 
> 

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Kevin Hilman]

"Nayak, Rajendra" <rnayak@ti.com> writes:

>> -----Original Message-----
>> From: Kevin Hilman [mailto:khilman@deeprootsystems.com] 
>> Sent: Thursday, April 23, 2009 1:35 AM
>> To: Nayak, Rajendra
>> Cc: linux-omap
>> Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
>> 
>> "Nayak, Rajendra" <rnayak@ti.com> writes:
>> 
>> > Re-sending this patch-set with some mailer issues resolved. 
>> They now apply cleanly
>> > with a git-am/git-apply.
>> >
>> > Hi,
>> >
>> > This series fixes a set of defects/issues in Smartreflex 
>> driver. SR autocompensation is now
>> > functional and is validated with these patches on a ES3.1 
>> based SDP with the N values in Efuse.
>> >
>> > The patches also make the Smartreflex driver independent of 
>> SRF by using the OMAP PM apis
>> > instead of calls to SRF.
>> >
>> > Patches apply on top of the latest pm branch from Kevin's pm tree.
>> > 
>> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om
>> ap-pm.git 
>> 
>> Rajendra,
>> 
>> This series seems to boot on SDP and Beagle but I recetly tried on
>> RX51 and it hangs in omap3_sr_init().
>> 
>> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
>> PRM write to the PRM_VP1_VLIMITTO register:
>> 
>> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
>> 					PRM_VP1_VLIMITTO_VDDMIN |
>> 					PRM_VP1_VLIMITTO_TIMEOUT,
>> 					OMAP3430_GR_MOD,
>> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
>> 
>> 
>> Should these min/max/timeout values be board specific?
>
> Kevin,
>
> These values I remember we got from the SiVal team here at TI, I don't think they are board specific.
> I can check up more on that from them.
> Btw, does the hang happen only with my patchset applied, because the patchset does not change
> any of these values.

Yes, backing out your latest series results in a booting kernel.

Kevin

Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Jean Pihet]

Hi,

On Friday 24 April 2009 15:09:29 Kevin Hilman wrote:
> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >> -----Original Message-----
> >> From: Kevin Hilman [mailto:khilman@deeprootsystems.com]
> >> Sent: Thursday, April 23, 2009 1:35 AM
> >> To: Nayak, Rajendra
> >> Cc: linux-omap
> >> Subject: Re: [PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver
> >>
> >> "Nayak, Rajendra" <rnayak@ti.com> writes:
> >> > Re-sending this patch-set with some mailer issues resolved.
> >>
> >> They now apply cleanly
> >>
> >> > with a git-am/git-apply.
> >> >
> >> > Hi,
> >> >
> >> > This series fixes a set of defects/issues in Smartreflex
> >>
> >> driver. SR autocompensation is now
> >>
> >> > functional and is validated with these patches on a ES3.1
> >>
> >> based SDP with the N values in Efuse.
> >>
> >> > The patches also make the Smartreflex driver independent of
> >>
> >> SRF by using the OMAP PM apis
> >>
> >> > instead of calls to SRF.
> >> >
> >> > Patches apply on top of the latest pm branch from Kevin's pm tree.
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om
> >> ap-pm.git
> >>
> >> Rajendra,
> >>
> >> This series seems to boot on SDP and Beagle but I recetly tried on
> >> RX51 and it hangs in omap3_sr_init().
> >>
> >> Using Lauterbach, I tracked it to hang in sr_configure_vp() at this
> >> PRM write to the PRM_VP1_VLIMITTO register:
> >>
> >> 		prm_write_mod_reg(PRM_VP1_VLIMITTO_VDDMAX |
> >> 					PRM_VP1_VLIMITTO_VDDMIN |
> >> 					PRM_VP1_VLIMITTO_TIMEOUT,
> >> 					OMAP3430_GR_MOD,
> >> 					OMAP3_PRM_VP1_VLIMITTO_OFFSET);
> >>
> >>
> >> Should these min/max/timeout values be board specific?
> >
> > Kevin,
> >
> > These values I remember we got from the SiVal team here at TI, I don't
> > think they are board specific. I can check up more on that from them.
> > Btw, does the hang happen only with my patchset applied, because the
> > patchset does not change any of these values.
>
> Yes, backing out your latest series results in a booting kernel.
Using the latest SR patches on Beagleboard results in a booting kernel.
BUT the problem is a board freeze when switching between OPPs. After a few 
transitions the board hangs.

Regards,
Jean

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

[PATCH 00/10] OMAP3: SR: Fixes in Smartreflex driver

[Nayak, Rajendra]

Hi,

This series fixes a set of defects/issues in Smartreflex driver. SR autocompensation is now
functional and is validated with these patches on a ES3.1 based SDP with the N values in Efuse.

The patches also make the Smartreflex driver independent of SRF by using the OMAP PM apis
instead of calls to SRF.

Patches apply on top of the latest pm branch from Kevin's pm tree.
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git 

regards,
Rajendra