Re: Smartreflex on 'pm-wip/voltdm' Branch

2011-03-30 Thread Gulati, Shweta
Hi,

On Mon, Mar 28, 2011 at 9:57 PM, Kevin Hilman khil...@ti.com wrote:
 Vishwa, Shweta,

 Vishwanath Sripathy vishwanath...@ti.com writes:

 [...]

 I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems
 an issue with reading VP registers.
 For OMAP3 and OMAP4 reading debugfs entries shows constant voltage.

 Thanks for testing.

 [...]

 I did a quick debug on this and found that the root cause of the issue is
 in usage of ffs (because of this, i2c slave address was configured wrongly
 in vc).
 Basically ffs returns the position of the first (least significant) bit
 set in the word and the least significant bit is position 1 where as our
 bit operation assumes that least significant position is 0.

 Vishwa, Thanks for findingg this.  Indeed, I had assumed ffs() was zero based,
 but it is 1 based.

 I tested the attached patch on OMAP3 and it seems to work fine.
Attached, is Patch which fixes the Issue, It works Fine for OMAP3 and
OMAP4 SDP boards.
 Kevin,
 You may want to incorporate this change in your next version if this seems
 OK to you.

 Yes, I will fix this in forthcoming versions.

 Thanks,

 Kevin




-- 
Thanks,
Regards,
Shweta


0001-OMAP2-PM-Ensure-Bitshifts-are-calculated-accurately.patch
Description: Binary data


Re: Smartreflex on 'pm-wip/voltdm' Branch

2011-03-30 Thread Kevin Hilman
Hi Shweta,

Gulati, Shweta shweta.gul...@ti.com writes:

[...]

 I did a quick debug on this and found that the root cause of the issue is
 in usage of ffs (because of this, i2c slave address was configured wrongly
 in vc).
 Basically ffs returns the position of the first (least significant) bit
 set in the word and the least significant bit is position 1 where as our
 bit operation assumes that least significant position is 0.

 Vishwa, Thanks for findingg this.  Indeed, I had assumed ffs() was zero 
 based,
 but it is 1 based.

 I tested the attached patch on OMAP3 and it seems to work fine.
 Attached, is Patch which fixes the Issue, It works Fine for OMAP3 and
 OMAP4 SDP boards.

Thanks for the patch, but my voltage cleanup series is work-in-progress,
and a moving target at the moment.  I've changed (again) the way I'm
splitting up the code so this patch won't apply directly.

I will however change to using __ffs instead of ffs.  Thanks for
pointing that out.  I wasn't aware of the difference between __ffs() and
ffs()

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 info at  http://vger.kernel.org/majordomo-info.html


Smartreflex on 'pm-wip/voltdm' Branch

2011-03-28 Thread Gulati, Shweta
Kevin,

I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems
an issue with reading VP registers.
For OMAP3 and OMAP4 reading debugfs entries shows constant voltage.
Logs are:

OMAP3:
# cat /debug/voltage/vdd_mpu_iva/curr_nominal_volt
120
# cat /debug/voltage/vdd_core/curr_nominal_volt
120
# echo 1  /debug/voltage/vdd_mpu_iva/smartreflex/autocomp
[  311.680816] omap_device: smartreflex.0: new worst case activate
latency 0: 91552
# echo 1  /debug/voltage/vdd_core/smartreflex/autocomp
# cat /debug/voltage/vdd_core/vp/curr_volt
90
# cat /debug/voltage/vdd_mpu_iva/vp/curr_volt
90


OMAP4:
 # cat /debug/voltage/vdd_core/curr_nominal_volt
120
# cat /debug/voltage/vdd_mpu/curr_nominal_volt
1375000
# cat /debug/voltage/vdd_iva/curr_nominal_volt
1188000
#
# echo 1  /debug/voltage/vdd_mpu/smartreflex/autocomp
[   61.514038] omap_device: smartreflex.2: new worst case activate
latency 0: 30517
# echo 1  /debug/voltage/vdd_core/smartreflex/autocomp
# echo 1  /debug/voltage/vdd_mpu/smartreflex/autocomp
#
# cat /debug/voltage/vdd_iva/curr_nominal_volt
1188000
# cat /debug/voltage/vdd_iva/vp/curr_volt
120
#
# echo 1  /debug/voltage/vdd_iva/smartreflex/autocomp
# cat /debug/voltage/vdd_iva/vp/curr_volt
812500
#
# cat /debug/voltage/vdd_mpu/vp/curr_volt
812500
# cat /debug/voltage/vdd_core/vp/curr_volt
812500
#

This Issue is not reproduced on 'pm-core' branch, seems in the voltage
Layer Clean up Patches somewhere some thing is goofed up.


Thanks,
Regards,
Shweta
--
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: Smartreflex on 'pm-wip/voltdm' Branch

2011-03-28 Thread Vishwanath Sripathy
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
 ow...@vger.kernel.org] On Behalf Of Gulati, Shweta
 Sent: Monday, March 28, 2011 4:23 PM
 To: linux-omap@vger.kernel.org; Kevin Hilman
 Subject: Smartreflex on 'pm-wip/voltdm' Branch

 Kevin,

 I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems
 an issue with reading VP registers.
 For OMAP3 and OMAP4 reading debugfs entries shows constant voltage.
 Logs are:

 OMAP3:
 # cat /debug/voltage/vdd_mpu_iva/curr_nominal_volt
 120
 # cat /debug/voltage/vdd_core/curr_nominal_volt
 120
 # echo 1  /debug/voltage/vdd_mpu_iva/smartreflex/autocomp
 [  311.680816] omap_device: smartreflex.0: new worst case activate
 latency 0: 91552
 # echo 1  /debug/voltage/vdd_core/smartreflex/autocomp
 # cat /debug/voltage/vdd_core/vp/curr_volt
 90
 # cat /debug/voltage/vdd_mpu_iva/vp/curr_volt
 90


 OMAP4:
  # cat /debug/voltage/vdd_core/curr_nominal_volt
 120
 # cat /debug/voltage/vdd_mpu/curr_nominal_volt
 1375000
 # cat /debug/voltage/vdd_iva/curr_nominal_volt
 1188000
 #
 # echo 1  /debug/voltage/vdd_mpu/smartreflex/autocomp
 [   61.514038] omap_device: smartreflex.2: new worst case activate
 latency 0: 30517
 # echo 1  /debug/voltage/vdd_core/smartreflex/autocomp
 # echo 1  /debug/voltage/vdd_mpu/smartreflex/autocomp
 #
 # cat /debug/voltage/vdd_iva/curr_nominal_volt
 1188000
 # cat /debug/voltage/vdd_iva/vp/curr_volt
 120
 #
 # echo 1  /debug/voltage/vdd_iva/smartreflex/autocomp
 # cat /debug/voltage/vdd_iva/vp/curr_volt
 812500
 #
 # cat /debug/voltage/vdd_mpu/vp/curr_volt
 812500
 # cat /debug/voltage/vdd_core/vp/curr_volt
 812500
 #

 This Issue is not reproduced on 'pm-core' branch, seems in the voltage
 Layer Clean up Patches somewhere some thing is goofed up.
I did a quick debug on this and found that the root cause of the issue is
in usage of ffs (because of this, i2c slave address was configured wrongly
in vc).
Basically ffs returns the position of the first (least significant) bit
set in the word and the least significant bit is position 1 where as our
bit operation assumes that least significant position is 0.
I tested the attached patch on OMAP3 and it seems to work fine.

Kevin,
You may want to incorporate this change in your next version if this seems
OK to you.

Vishwa


 Thanks,
 Regards,
 Shweta
 --
 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


vc_fix.patch
Description: Binary data


Re: Smartreflex on 'pm-wip/voltdm' Branch

2011-03-28 Thread Kevin Hilman
Vishwa, Shweta,

Vishwanath Sripathy vishwanath...@ti.com writes:

[...]

 I am testing Smartreflex on your Branch 'pm-wip/voltdm'. There seems
 an issue with reading VP registers.
 For OMAP3 and OMAP4 reading debugfs entries shows constant voltage.

Thanks for testing.

[...]

 I did a quick debug on this and found that the root cause of the issue is
 in usage of ffs (because of this, i2c slave address was configured wrongly
 in vc).
 Basically ffs returns the position of the first (least significant) bit
 set in the word and the least significant bit is position 1 where as our
 bit operation assumes that least significant position is 0.

Vishwa, Thanks for findingg this.  Indeed, I had assumed ffs() was zero based,
but it is 1 based.  

 I tested the attached patch on OMAP3 and it seems to work fine.

 Kevin,
 You may want to incorporate this change in your next version if this seems
 OK to you.

Yes, I will fix this in forthcoming versions.

Thanks,

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 info at  http://vger.kernel.org/majordomo-info.html