"Nayak, Rajendra" <rnayak@xxxxxx> writes: >> -----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. Yes, backing out your latest series results in a booting kernel. 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
