On Wed, Jun 29, 2011 at 2:00 AM, Kevin Hilman <khilman@xxxxxx> wrote: > "T Krishnamoorthy, Balaji" <balajitk@xxxxxx> writes: > >> On Tue, Jun 28, 2011 at 10:52 PM, Paul Walmsley <paul@xxxxxxxxx> wrote: >>> (cc'ing Adrian also) >>> >>> Hi Balaji >>> >>> On Wed, 22 Jun 2011, Balaji T K wrote: >>> >>>> Use runtime autosuspend APIs to enable auto suspend delay >>> >>> Does this really need to use runtime autosuspend? Seems to me that since >>> PM runtime is just controlling the MMC IP blocks and not the regulators in >>> this instance, this could simply use pm_runtime_put*() and just avoid the >>> extra power wastage and complexity involved in autosuspend. >>> >> >> 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. > As Paul mentioned, the timeout value here is probably usecase depeend > There is no direct relationship to the use case. Block layer buffers and reworks the order of requests and they are usually queued together. Having no context save / restore penalty for each request is definitely desirable. (As I understand, MMC can lose context independent of MPU on OMAP4). -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
