> -----Original Message----- > From: Premi, Sanjeev > Sent: Saturday, November 21, 2009 1:04 AM > To: Premi, Sanjeev; Maxime Petazzoni > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: RE: VDD1 voltage after resume from idle > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx > > [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of > Premi, Sanjeev > > Sent: Friday, November 20, 2009 11:46 PM > > To: Maxime Petazzoni > > Cc: linux-omap@xxxxxxxxxxxxxxx > > Subject: RE: VDD1 voltage after resume from idle > > > > > -----Original Message----- > > > From: Maxime Petazzoni [mailto:mpetazzoni@xxxxxxxxxx] > > > Sent: Friday, November 20, 2009 10:00 PM > > > To: Premi, Sanjeev > > > Cc: linux-omap@xxxxxxxxxxxxxxx > > > Subject: Re: VDD1 voltage after resume from idle > > > > > [snip]--[snip]--[snip] > > > > > I guess the root cause could be same. I have not been able to > > ascertain > > the reason for the voltage changing during the idle/wakeup sequence. > > Also tried to eliminate the enable_smartreflex() calls on > wakeup path. > > Sill I see voltage ramp-up. > > > > I am trying to find the cause of voltage ramping to 1.2V in > hope that > > the reason for ramp down will be just inverted reflection. > > > > With smartreflex disabled, there is no change in the voltage during > > suspend; so the problem area seems to be smartreflex. > > > > Best regards, > > Sanjeev > > Found the problem! > > In sr_configure_vp() the vsel is picked up from the OPP table > and used, > setting the voltage as expected (1.35V in my case). > > A printk confirms PRM_VC_CMD_VAL_0 is 0x3C201E00. > > By the time, kernel boots up, the value has changed to 0x30201E00. > (0x30 corresponds to 1.2V) > > [root@OMAP3EVM /]# devmem 0x4830722c 32 > 0x30201E00 > > Now, when I update the init voltage back to 3C (via devmem) > the voltage > after resume/idle-wakeup is right (as expected). > > [root@OMAP3EVM /]# devmem 0x4830722c 32 0x3c201e00 > [root@OMAP3EVM /]# > > So, I just need to find exact location where the > configuration is being > overwritten. Correction. Though I expected/assumed VSEL to be written to this Location. It wasn't the case. VSEL is used to update the ON voltage Field in PRM_VP1_CONFIG; but not the PRM_VC_CMD_VAL_0. Haven't tried (too hard) to find initiator programming this reg in kernel - so, it might be retaining values from u-boot. After ensuring that PRM_VC_CMD_VAL_0,1 are updated based on the VSEL values in current opp tables, the problem seems to be fixed. Patch from my working tree following soon for review. Will refresh it against /pm, if needed, there are no comments. Best regards, Sanjeev > > It is well past midnight now. So the patch will have to wait until > tomorrow. > > Best regards, > Sanjeev > > [snip]--[snip]--[snip] > -- 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
