RE: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2010-01-07 Thread Sripathy, Vishwanath 
Nishant,
Have you tested your opp patches on 3630? Apparently opp changes in wip branch 
does not even boot on ZOOM3 board.

Vishwa

 -Original Message-
 From: Menon, Nishanth
 Sent: Thursday, January 07, 2010 5:16 AM
 To: Kevin Hilman
 Cc: linux-omap; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan; Paul
 Walmsley; Dasgupta, Romit; Premi, Sanjeev; Shilimkar, Santosh; Aguirre, 
 Sergio;
 Gopinath, Thara; Sripathy, Vishwanath; K, Ambresh
 Subject: Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp
 
 Kevin Hilman had written, on 12/22/2009 10:45 AM, the following:
  Menon, Nishanth n...@ti.com writes:
 
  Kevin Hilman said the following on 12/19/2009 04:42 AM:
  Nishanth Menon n...@ti.com writes:
 
 
  SmartReflex implements a get_opp to search through the opp table,
  replace it with the accessor function as it is a duplicate of
  freq_to_opp
 
  SmartReflex is not quite working with this version which is in
  pm-wip-opp.  My (untested) theory below...
 
  [...]
 
  Ambresh and I  just tested the very latest of the pm-wip-opp branch
  and checked. Voltage transitions and SR adjustments are happily
  happening on SDP3430 ES3.1 at the very least (verified with a scope on
  vdd1).
 
  and if you look closely in the code, sr2.vdd_opp_clk-rate and
  sr1.vdd_opp_clk-rate are based on
  sr1.vdd_opp_clk = clk_get(NULL, dpll1_ck)
  sr2.vdd_opp_clk = clk_get(NULL, l3_ick);
 
  now, if the dpll1_ck -rate and l3_ick-rate are not exact frequencies
  as the opp tables, I think we have a clockframework bug and the code
  here is correct. we should fix the clockframework/find the rootcause
  elsewhere.
 
  Now is the clockframework wrong? we added a patch to print the
  frequencies and checked if IS_ERR(opp) is true - not a single call
  while using cpu_freq transitions resulted in an error value and all
  the frequencies we printed were from the OPP table
 
  Might be good to hear your rationale for saying this result..
 
  Part of my rationale was that the PM branch version get_vdd1_opp()
  does an approximate match (actually the equivalent of
  opp_find_freq_ceil() via get_opp.)  So you replaced an approximate
  match with an exact match.  That may be the right solution and point
  to a bug elsewhere, but it was not an equivalent replacement, and
  probably should've been done in a separate patch with
  justification/rationale.  I didn't catch it during initial review.
 
  But the primary reason I noticed it in the first place was that I was
  seeing DVFS errors on n900, which is the only platform I have that
  actually can do SmartReflex.  Specifically, sr_reset_voltage() is
  failing for VDD1.  Dumping out the clock rates used in get_vdd1_opp()
  show that the clocks rates are close, but not the exact value used in
  the OPP table.
 
  Here is the patch I used to add some debugging, and I see that for the
  250MHz OPP, the clock framework rate is 24960 and for the 125MHz
  OPP, the clock rate is 12480.  As I said, close, but clearly an
  find with exact match is going to fail.
 
  Below the patch, is the console dump and backtrace of how get_vdd1_opp()
  was called so you can see the call chain.
 
  Kevin
 
  diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-
 omap2/smartreflex.c
  index d341857..01a3dbd 100644
  --- a/arch/arm/mach-omap2/smartreflex.c
  +++ b/arch/arm/mach-omap2/smartreflex.c
  @@ -155,6 +155,8 @@ static u8 get_vdd1_opp(void)
  mpu_opps == NULL)
  return 0;
 
  +   printk(%s: sr1.vdd_opp_clk-rate = %d\n, __func__,
  +  sr1.vdd_opp_clk-rate);
  opp = opp_find_freq_exact(mpu_opps, sr1.vdd_opp_clk-rate, true);
  if (IS_ERR(opp))
  return 0;
  @@ -451,6 +453,7 @@ static int sr_reset_voltage(int srid)
  target_opp_no = get_vdd1_opp();
  if (!target_opp_no) {
  pr_info(Current OPP unknown: Cannot reset voltage\n);
  +   __backtrace();
  return 1;
  }
 
 
 
  /sys/devices/system/cpu/cpu0/cpufreq # echo 25  scaling_setspeed
  get_vdd1_opp: sr1.vdd_opp_clk-rate = 24960
  Current OPP unknown: Cannot reset voltage
  [c0042c98] (sr_reset_voltage+0x0/0x190) from [c0043094]
 (sr_stop_vddautocomap+0x12c/0x148)
   r7:0001 r6:0001 r5:c03ac878 r4:
  [c0042f68] (sr_stop_vddautocomap+0x0/0x148) from [c0043388]
 (sr_voltagescale_vcbypass+0x2c/0x170)
 [...]
 
 Throws up my hands! 3430 on N900/SDP3430 should be essentially the same!
 
 Configuration:
 ==
 kernel:
 git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
 branch:
 pm-wip-opp 6e1276f omap3:pm: remove map3_[mpu|dsp|l3]_rate_tables
 Applied my bugfix: http://patchwork.kernel.org/patch/71457/
 
 I have a 3430 ES3.1 SDP3430 where I did run the test:
 
 Log Patch: http://pastebin.mozilla.org/695225
 Test script: http://pastebin.mozilla.org/695226 (I call this test-me.sh)
 Result log

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2010-01-07 Thread Romit Dasgupta 
Sripathy, Vishwanath wrote:
 Nishant,
 Have you tested your opp patches on 3630? Apparently opp changes in wip 
 branch does not even boot on ZOOM3 board.
 
 Vishwa
Vishwa,
  did you try on top of my OPP patches?

Thanks,
-Romit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2010-01-07 Thread Sripathy, Vishwanath 
Yes Vijay tried with your OPP patches on 3630 ZOOM3 and it seems to work.

Vishwa

 -Original Message-
 From: Dasgupta, Romit
 Sent: Thursday, January 07, 2010 2:23 PM
 To: Sripathy, Vishwanath
 Cc: Menon, Nishanth; Kevin Hilman; linux-omap; Cousson, Benoit; Chikkature
 Rajashekar, Madhusudhan; Paul Walmsley; Premi, Sanjeev; Shilimkar, Santosh;
 Aguirre, Sergio; Gopinath, Thara; K, Ambresh
 Subject: Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp
 
 Sripathy, Vishwanath wrote:
  Nishant,
  Have you tested your opp patches on 3630? Apparently opp changes in wip 
  branch
 does not even boot on ZOOM3 board.
 
  Vishwa
 Vishwa,
   did you try on top of my OPP patches?
 
 Thanks,
 -Romit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2010-01-07 Thread Nishanth Menon 

Sripathy, Vishwanath said the following on 01/07/2010 02:35 AM:

Nishant,
Have you tested your opp patches on 3630? Apparently opp changes in wip branch 
does not even boot on ZOOM3 board.
  
The original series was tested and reported with results. I have'nt had 
a chance to try with the newer patch set. if there are patches, they are 
most welcome meanwhile. I will also try to do some on SDP3630 later today.



Vishwa

  

-Original Message-
From: Menon, Nishanth
Sent: Thursday, January 07, 2010 5:16 AM
To: Kevin Hilman
Cc: linux-omap; Cousson, Benoit; Chikkature Rajashekar, Madhusudhan; Paul
Walmsley; Dasgupta, Romit; Premi, Sanjeev; Shilimkar, Santosh; Aguirre, Sergio;
Gopinath, Thara; Sripathy, Vishwanath; K, Ambresh
Subject: Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp


being a nitpick: could we avoid top-posting please?



Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2010-01-07 Thread Nishanth Menon 

Nishanth Menon had written, on 01/07/2010 06:15 AM, the following:

Sripathy, Vishwanath said the following on 01/07/2010 02:35 AM:

Nishant,
Have you tested your opp patches on 3630? Apparently opp changes in wip branch 
does not even boot on ZOOM3 board.
  
The original series was tested and reported with results. I have'nt had 
a chance to try with the newer patch set. if there are patches, they are 
most welcome meanwhile. I will also try to do some on SDP3630 later today.



[...]
http://pastebin.mozilla.org/695411 has the boot log on SDP3630! as 
reported previously clock framework is crashing, that is probably 
because the clock framework changes for 3630 corresponding to 3630 OPPs 
are not available.


the scripts and kernel details are part of
http://marc.info/?l=linux-omapm=126282159227739w=2

--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2010-01-06 Thread Nishanth Menon 

Kevin Hilman had written, on 12/22/2009 10:45 AM, the following:

Menon, Nishanth n...@ti.com writes:


Kevin Hilman said the following on 12/19/2009 04:42 AM:

Nishanth Menon n...@ti.com writes:

  

SmartReflex implements a get_opp to search through the opp table,
replace it with the accessor function as it is a duplicate of
freq_to_opp


SmartReflex is not quite working with this version which is in
pm-wip-opp.  My (untested) theory below...

[...]
  

Ambresh and I  just tested the very latest of the pm-wip-opp branch
and checked. Voltage transitions and SR adjustments are happily
happening on SDP3430 ES3.1 at the very least (verified with a scope on
vdd1).

and if you look closely in the code, sr2.vdd_opp_clk-rate and
sr1.vdd_opp_clk-rate are based on
sr1.vdd_opp_clk = clk_get(NULL, dpll1_ck)
sr2.vdd_opp_clk = clk_get(NULL, l3_ick);

now, if the dpll1_ck -rate and l3_ick-rate are not exact frequencies
as the opp tables, I think we have a clockframework bug and the code
here is correct. we should fix the clockframework/find the rootcause
elsewhere.

Now is the clockframework wrong? we added a patch to print the
frequencies and checked if IS_ERR(opp) is true - not a single call
while using cpu_freq transitions resulted in an error value and all
the frequencies we printed were from the OPP table

Might be good to hear your rationale for saying this result..


Part of my rationale was that the PM branch version get_vdd1_opp()
does an approximate match (actually the equivalent of
opp_find_freq_ceil() via get_opp.)  So you replaced an approximate
match with an exact match.  That may be the right solution and point
to a bug elsewhere, but it was not an equivalent replacement, and
probably should've been done in a separate patch with
justification/rationale.  I didn't catch it during initial review.

But the primary reason I noticed it in the first place was that I was
seeing DVFS errors on n900, which is the only platform I have that
actually can do SmartReflex.  Specifically, sr_reset_voltage() is
failing for VDD1.  Dumping out the clock rates used in get_vdd1_opp()
show that the clocks rates are close, but not the exact value used in
the OPP table.

Here is the patch I used to add some debugging, and I see that for the
250MHz OPP, the clock framework rate is 24960 and for the 125MHz
OPP, the clock rate is 12480.  As I said, close, but clearly an
find with exact match is going to fail.

Below the patch, is the console dump and backtrace of how get_vdd1_opp()
was called so you can see the call chain.

Kevin

diff --git a/arch/arm/mach-omap2/smartreflex.c 
b/arch/arm/mach-omap2/smartreflex.c
index d341857..01a3dbd 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -155,6 +155,8 @@ static u8 get_vdd1_opp(void)
mpu_opps == NULL)
return 0;
 
+	printk(%s: sr1.vdd_opp_clk-rate = %d\n, __func__,

+  sr1.vdd_opp_clk-rate);
opp = opp_find_freq_exact(mpu_opps, sr1.vdd_opp_clk-rate, true);
if (IS_ERR(opp))
return 0;
@@ -451,6 +453,7 @@ static int sr_reset_voltage(int srid)
target_opp_no = get_vdd1_opp();
if (!target_opp_no) {
pr_info(Current OPP unknown: Cannot reset voltage\n);
+   __backtrace();
return 1;
}
 



/sys/devices/system/cpu/cpu0/cpufreq # echo 25  scaling_setspeed 
get_vdd1_opp: sr1.vdd_opp_clk-rate = 24960

Current OPP unknown: Cannot reset voltage
[c0042c98] (sr_reset_voltage+0x0/0x190) from [c0043094] 
(sr_stop_vddautocomap+0x12c/0x148)
 r7:0001 r6:0001 r5:c03ac878 r4:
[c0042f68] (sr_stop_vddautocomap+0x0/0x148) from [c0043388] 
(sr_voltagescale_vcbypass+0x2c/0x170)

[...]

Throws up my hands! 3430 on N900/SDP3430 should be essentially the same!

Configuration:
==
kernel: 
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git

branch:
pm-wip-opp 6e1276f omap3:pm: remove map3_[mpu|dsp|l3]_rate_tables
Applied my bugfix: http://patchwork.kernel.org/patch/71457/

I have a 3430 ES3.1 SDP3430 where I did run the test:

Log Patch: http://pastebin.mozilla.org/695225
Test script: http://pastebin.mozilla.org/695226 (I call this test-me.sh)
Result log: http://pastebin.mozilla.org/695224

huh? no crash, all the frequencies and transitions are good, the rates 
of dpll1,2,3 look good! there is something definitely fishy about N900 
configuration??


--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2010-01-06 Thread Kevin Hilman 
Nishanth Menon n...@ti.com writes:

 Kevin Hilman had written, on 12/22/2009 10:45 AM, the following:
 Menon, Nishanth n...@ti.com writes:

 Kevin Hilman said the following on 12/19/2009 04:42 AM:
 Nishanth Menon n...@ti.com writes:

   
 SmartReflex implements a get_opp to search through the opp table,
 replace it with the accessor function as it is a duplicate of
 freq_to_opp
 
 SmartReflex is not quite working with this version which is in
 pm-wip-opp.  My (untested) theory below...

 [...]
   
 Ambresh and I  just tested the very latest of the pm-wip-opp branch
 and checked. Voltage transitions and SR adjustments are happily
 happening on SDP3430 ES3.1 at the very least (verified with a scope on
 vdd1).

 and if you look closely in the code, sr2.vdd_opp_clk-rate and
 sr1.vdd_opp_clk-rate are based on
 sr1.vdd_opp_clk = clk_get(NULL, dpll1_ck)
 sr2.vdd_opp_clk = clk_get(NULL, l3_ick);

 now, if the dpll1_ck -rate and l3_ick-rate are not exact frequencies
 as the opp tables, I think we have a clockframework bug and the code
 here is correct. we should fix the clockframework/find the rootcause
 elsewhere.

 Now is the clockframework wrong? we added a patch to print the
 frequencies and checked if IS_ERR(opp) is true - not a single call
 while using cpu_freq transitions resulted in an error value and all
 the frequencies we printed were from the OPP table

 Might be good to hear your rationale for saying this result..

 Part of my rationale was that the PM branch version get_vdd1_opp()
 does an approximate match (actually the equivalent of
 opp_find_freq_ceil() via get_opp.)  So you replaced an approximate
 match with an exact match.  That may be the right solution and point
 to a bug elsewhere, but it was not an equivalent replacement, and
 probably should've been done in a separate patch with
 justification/rationale.  I didn't catch it during initial review.

 But the primary reason I noticed it in the first place was that I was
 seeing DVFS errors on n900, which is the only platform I have that
 actually can do SmartReflex.  Specifically, sr_reset_voltage() is
 failing for VDD1.  Dumping out the clock rates used in get_vdd1_opp()
 show that the clocks rates are close, but not the exact value used in
 the OPP table.

 Here is the patch I used to add some debugging, and I see that for the
 250MHz OPP, the clock framework rate is 24960 and for the 125MHz
 OPP, the clock rate is 12480.  As I said, close, but clearly an
 find with exact match is going to fail.

 Below the patch, is the console dump and backtrace of how get_vdd1_opp()
 was called so you can see the call chain.

 Kevin

 diff --git a/arch/arm/mach-omap2/smartreflex.c 
 b/arch/arm/mach-omap2/smartreflex.c
 index d341857..01a3dbd 100644
 --- a/arch/arm/mach-omap2/smartreflex.c
 +++ b/arch/arm/mach-omap2/smartreflex.c
 @@ -155,6 +155,8 @@ static u8 get_vdd1_opp(void)
  mpu_opps == NULL)
  return 0;
  +   printk(%s: sr1.vdd_opp_clk-rate = %d\n, __func__,
 +   sr1.vdd_opp_clk-rate);
  opp = opp_find_freq_exact(mpu_opps, sr1.vdd_opp_clk-rate, true);
  if (IS_ERR(opp))
  return 0;
 @@ -451,6 +453,7 @@ static int sr_reset_voltage(int srid)
  target_opp_no = get_vdd1_opp();
  if (!target_opp_no) {
  pr_info(Current OPP unknown: Cannot reset voltage\n);
 +__backtrace();
  return 1;
  }
  


 /sys/devices/system/cpu/cpu0/cpufreq # echo 25 
 scaling_setspeed get_vdd1_opp: sr1.vdd_opp_clk-rate = 24960
 Current OPP unknown: Cannot reset voltage
 [c0042c98] (sr_reset_voltage+0x0/0x190) from [c0043094] 
 (sr_stop_vddautocomap+0x12c/0x148)
  r7:0001 r6:0001 r5:c03ac878 r4:
 [c0042f68] (sr_stop_vddautocomap+0x0/0x148) from [c0043388] 
 (sr_voltagescale_vcbypass+0x2c/0x170)
 [...]

 Throws up my hands! 3430 on N900/SDP3430 should be essentially the same!

 Configuration:
 ==
 kernel:
 git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
 branch:
 pm-wip-opp 6e1276f omap3:pm: remove map3_[mpu|dsp|l3]_rate_tables
 Applied my bugfix: http://patchwork.kernel.org/patch/71457/

 I have a 3430 ES3.1 SDP3430 where I did run the test:

 Log Patch: http://pastebin.mozilla.org/695225
 Test script: http://pastebin.mozilla.org/695226 (I call this test-me.sh)
 Result log: http://pastebin.mozilla.org/695224

 huh? no crash, all the frequencies and transitions are good, the rates
 of dpll1,2,3 look good! there is something definitely fishy about N900
 configuration??

OK, so for now we need to at least replace the original approximate
match with an equivalent approximate match.  Then, use an additional
patch to change it to an exact match when we find out what's happening
on N900.

Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2009-12-22 Thread Kevin Hilman 
Menon, Nishanth n...@ti.com writes:

 Kevin Hilman said the following on 12/19/2009 04:42 AM:
 Nishanth Menon n...@ti.com writes:

   
 SmartReflex implements a get_opp to search through the opp table,
 replace it with the accessor function as it is a duplicate of
 freq_to_opp
 

 SmartReflex is not quite working with this version which is in
 pm-wip-opp.  My (untested) theory below...

 [...]
   
 Ambresh and I  just tested the very latest of the pm-wip-opp branch
 and checked. Voltage transitions and SR adjustments are happily
 happening on SDP3430 ES3.1 at the very least (verified with a scope on
 vdd1).

 and if you look closely in the code, sr2.vdd_opp_clk-rate and
 sr1.vdd_opp_clk-rate are based on
 sr1.vdd_opp_clk = clk_get(NULL, dpll1_ck)
 sr2.vdd_opp_clk = clk_get(NULL, l3_ick);

 now, if the dpll1_ck -rate and l3_ick-rate are not exact frequencies
 as the opp tables, I think we have a clockframework bug and the code
 here is correct. we should fix the clockframework/find the rootcause
 elsewhere.

 Now is the clockframework wrong? we added a patch to print the
 frequencies and checked if IS_ERR(opp) is true - not a single call
 while using cpu_freq transitions resulted in an error value and all
 the frequencies we printed were from the OPP table

 Might be good to hear your rationale for saying this result..

Part of my rationale was that the PM branch version get_vdd1_opp()
does an approximate match (actually the equivalent of
opp_find_freq_ceil() via get_opp.)  So you replaced an approximate
match with an exact match.  That may be the right solution and point
to a bug elsewhere, but it was not an equivalent replacement, and
probably should've been done in a separate patch with
justification/rationale.  I didn't catch it during initial review.

But the primary reason I noticed it in the first place was that I was
seeing DVFS errors on n900, which is the only platform I have that
actually can do SmartReflex.  Specifically, sr_reset_voltage() is
failing for VDD1.  Dumping out the clock rates used in get_vdd1_opp()
show that the clocks rates are close, but not the exact value used in
the OPP table.

Here is the patch I used to add some debugging, and I see that for the
250MHz OPP, the clock framework rate is 24960 and for the 125MHz
OPP, the clock rate is 12480.  As I said, close, but clearly an
find with exact match is going to fail.

Below the patch, is the console dump and backtrace of how get_vdd1_opp()
was called so you can see the call chain.

Kevin

diff --git a/arch/arm/mach-omap2/smartreflex.c 
b/arch/arm/mach-omap2/smartreflex.c
index d341857..01a3dbd 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -155,6 +155,8 @@ static u8 get_vdd1_opp(void)
mpu_opps == NULL)
return 0;
 
+   printk(%s: sr1.vdd_opp_clk-rate = %d\n, __func__,
+  sr1.vdd_opp_clk-rate);
opp = opp_find_freq_exact(mpu_opps, sr1.vdd_opp_clk-rate, true);
if (IS_ERR(opp))
return 0;
@@ -451,6 +453,7 @@ static int sr_reset_voltage(int srid)
target_opp_no = get_vdd1_opp();
if (!target_opp_no) {
pr_info(Current OPP unknown: Cannot reset voltage\n);
+   __backtrace();
return 1;
}
 


/sys/devices/system/cpu/cpu0/cpufreq # echo 25  scaling_setspeed 
get_vdd1_opp: sr1.vdd_opp_clk-rate = 24960
Current OPP unknown: Cannot reset voltage
[c0042c98] (sr_reset_voltage+0x0/0x190) from [c0043094] 
(sr_stop_vddautocomap+0x12c/0x148)
 r7:0001 r6:0001 r5:c03ac878 r4:
[c0042f68] (sr_stop_vddautocomap+0x0/0x148) from [c0043388] 
(sr_voltagescale_vcbypass+0x2c/0x170)
 r7:0001 r6:0001 r5:0030 r4:0026
[c004335c] (sr_voltagescale_vcbypass+0x0/0x170) from [c0043e00] 
(program_opp+0x1e4/0x210)
[c0043c1c] (program_opp+0x0/0x210) from [c0043f64] 
(resource_set_opp_level+0x138/0x1b0)
[c0043e2c] (resource_set_opp_level+0x0/0x1b0) from [c0044024] 
(set_opp+0x48/0x120)
[c0043fdc] (set_opp+0x0/0x120) from [c004bb48] 
(update_resource_level+0xb0/0xd4)
 r5:c03b365c r4:0002
[c004ba98] (update_resource_level+0x0/0xd4) from [c004be34] 
(resource_request+0x154/0x184)
 r7:0002 r6:c03db5a0 r5:c03b365c r4:
[c004bce0] (resource_request+0x0/0x184) from [c0043a50] (set_freq+0xb4/0xe8)
 r7:0ee6b280 r6:cf801080 r5:cf801000 r4:c0359347
[c004399c] (set_freq+0x0/0xe8) from [c004bb48] 
(update_resource_level+0xb0/0xd4)
 r8:c03d52f8 r7:0ee6b280 r6:c03dbf70 r5:c03b36a4 r4:0ee6b280
[c004ba98] (update_resource_level+0x0/0xd4) from [c004be34] 
(resource_request+0x154/0x184)
 r7:0ee6b280 r6:c03dbf70 r5:c03b36a4 r4:
[c004bce0] (resource_request+0x0/0x184) from [c004b7a4] 
(omap_pm_cpu_set_freq+0x34/0x44)
 r7:0007 r6:cfae7000 r5:cf96c100 r4:0003d090
[c004b770] (omap_pm_cpu_set_freq+0x0/0x44) from [c004ac44] 
(omap_target+0x64/0x74)

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2009-12-20 Thread Romit Dasgupta 
Kevin Hilman wrote:
 Nishanth Menon n...@ti.com writes:
 
 
 SmartReflex is not quite working with this version which is in
 pm-wip-opp.  My (untested) theory below...
Mostly you have not included SR in the build. OTOH I raised this issue earlier
that the omap cpufreq driver is not honoring CPUFREQ_RELATION_L and
CPUFREQ_RELATION_H flags. I do not understand why do we need to do a
opp_find_freq_ceil here? The validate function of the frequency resources would
have already identified if we can get this exact frequency or not.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/9] omap3: pm: sr: replace get_opp with freq_to_opp

2009-12-19 Thread Menon, Nishanth 

Kevin Hilman said the following on 12/19/2009 04:42 AM:

Nishanth Menon n...@ti.com writes:

  

SmartReflex implements a get_opp to search through the opp table,
replace it with the accessor function as it is a duplicate of
freq_to_opp



SmartReflex is not quite working with this version which is in
pm-wip-opp.  My (untested) theory below...

[...]
  
Ambresh and I  just tested the very latest of the pm-wip-opp branch and 
checked. Voltage transitions and SR adjustments are happily happening on 
SDP3430 ES3.1 at the very least (verified with a scope on vdd1).


and if you look closely in the code, sr2.vdd_opp_clk-rate and 
sr1.vdd_opp_clk-rate are based on

sr1.vdd_opp_clk = clk_get(NULL, dpll1_ck)
sr2.vdd_opp_clk = clk_get(NULL, l3_ick);

now, if the dpll1_ck -rate and l3_ick-rate are not exact frequencies 
as the opp tables, I think we have a clockframework bug and the code 
here is correct. we should fix the clockframework/find the rootcause 
elsewhere.


Now is the clockframework wrong? we added a patch to print the 
frequencies and checked if IS_ERR(opp) is true - not a single call 
while using cpu_freq transitions resulted in an error value and all the 
frequencies we printed were from the OPP table


Might be good to hear your rationale for saying this result..

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html