On 29 March 2015 at 12:53, Konstantin Dorfman <kdorfman@xxxxxxxxxxxxxx> wrote: > > > On 03/28/2015 12:52 AM, NeilBrown wrote: >> >> On Fri, 27 Mar 2015 12:15:15 +0100 Ulf Hansson <ulf.hansson@xxxxxxxxxx> >> wrote: >> >>> Currently those host drivers which have deployed runtime PM, deals with >>> the runtime PM reference counting entirely by themselves. >>> >>> Since host drivers don't know when the core will send the next request >>> through some of the host_ops callbacks, they need to handle runtime PM >>> get/put between each an every request. >>> >>> In quite many cases this has some negative effects, since it leads to a >>> high frequency of scheduled runtime PM suspend operations. That due to >>> the runtime PM reference count will normally reach zero in-between >>> every request. > > > It would be nice to have some numbers about this suspend/resume jitter of > platform device pm due to time between consecutive requests within burst of > requests. > > Probably we can tune autosuspend timer of specific platform device to avoid > this. No, that's not going to do the trick. What $subject patch does, is to decrease the frequency for when the host device's runtime PM reference count reaches zero. Thus preventing us from telling the runtime PM core to schedule a suspend operation, when we actually know it isn't needed. > > Implementing the patch in a way that you are suggesting will imply that the > mmc core will always use double buffering request polling scheme and the > existing mechanism of "request burst" definition. $subject patch will improve behaviour when handling "bursts", but that's just one case for when mmc core knows that it's going to send a sequence of commands/requests. For example, the core also send sequences from the mmc_rescan() work, system PM suspend, etc. Kind regards Uffe -- 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
