"ext Reddy, Teerth" <teerth@xxxxxx> writes: > Hi Jouni, > >> -----Original Message----- >> From: Högander Jouni [mailto:jouni.hogander@xxxxxxxxx] >> Sent: Monday, February 15, 2010 2:27 PM >> To: Reddy, Teerth >> Cc: linux-omap@xxxxxxxxxxxxxxx; Sripathy, Vishwanath; Paul Walmsley; Kevin >> Hilman >> Subject: Re: [PATCH RFC]OMAP3:PM:Dynamic Calculation of SDRC stall latency >> during DVFS >> >> "ext Reddy, Teerth" <teerth@xxxxxx> writes: >> >> > From: Teerth Reddy <teerth@xxxxxx> >> > >> > Dynamic Calculation of SDRC stall latency during DVFS >> > >> > The patch has the changes to calculate the dpll3 clock stabilization >> delay dynamically. The SRAM delay is calibrated during bootup using the >> gptimers and used while calculating the stabilization delay. By using the >> dynamic method the dependency on the type of cache being used is removed. >> Hence there is no need of loop based calculation. >> > >> > The wait time for L3 clock stabilization is calculated using the formula >> : 4*REFCLK + 8*CLKOUTX2, which uses the M, N and M2 read from the >> registers.Since this value gives slightly less value, 2us is added as >> buffer for safety. >> > This works fine for omap3. >> >> I think you could make a difference on 3630 in this patch. 3630 has >> different formula to calculate needed delay after setting m2 divider. > > We have considered the worst case scenario and used this formula > which holds good for 3630 as well. We have used register dump and > observability signal analysis to comeup with this formula. At least the formula used in the patch is quite strictly the one used for 3430. In 3430 used oscillator and m and n selection have huge impact on needed delay (12, 19.2 etc...). In 3630 these doesn't have impact on needed delay anymore. So using own formula for 3630, would give few benefits. No need to take this delay into account in oscillator selection and on m and n selection. > > > Regards > Teerth > -- > 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 -- Jouni Högander -- 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