> -----Original Message----- > From: Kevin Hilman [mailto:khilman@xxxxxxxxxxxxxxxxxxx] > 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@xxxxxxxxx> 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 > > > > > -- 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
