On Thu, Jun 30, 2011 at 6:10 AM, Paul Walmsley <paul@xxxxxxxxx> wrote: > + Venkat > > Hi Balaji > > On Wed, 29 Jun 2011, T Krishnamoorthy, Balaji wrote: > >> On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman <khilman@xxxxxx> wrote: >> > "T Krishnamoorthy, Balaji" <balajitk@xxxxxx> writes: >> >> >> >> I have seen some instabilities if delay is very less, on some >> >> production boards. The previous implementation used 100ms delay >> >> before disabling the clocks. >> > >> > And your new one is using 50ms. How did this value come about? >> >> I don't have any specific affinity to this number, but when requests are >> bursty, they arrive within a few 10s of ms within each other. Didn't >> want to have the context/save restore penalty associated with every >> request. > > Kevin and I just chatted a little bit about this. It seems best to > separate the work done on the autosuspend timeout from the runtime PM > conversion. > > So how about this: please send a new version of these patches with the > previous value, 100ms, for the autosuspend timeout. That should hopefully > minimize the behavior change here for existing users. And hopefully we'll > be able to get the series in for this merge window. > > Then later, we need to come back to this autosuspend timeout issue. > Ok. -- 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
