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