From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> To: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Ulf Hansson <ulf.hansson@stericsson.com>, "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, Chris Ball <cjb@laptop.org>, "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org> Subject: Re: [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Date: Fri, 16 Dec 2011 09:14:11 +0000 [thread overview] Message-ID: <Pine.LNX.4.64.1112160954030.6572@axis700.grange> (raw) In-Reply-To: <201112142236.26739.rjw@sisk.pl> On Wed, 14 Dec 2011, Rafael J. Wysocki wrote: > On Wednesday, December 14, 2011, Ulf Hansson wrote: [snip] > > 2. > > When executing mmc/sd commands/requests the host must always be claimed > > (and thus the host is always enabled). Why? Why cannot we save some power between IO operations - if we can do this quickly and safely without affecting functionality and throughput? > > But more important some mmc/sd > > commands must be executed as a sequence, without the host being disabled > > in between the commands (since a disable might mean that the clock to > > card gets disabled). Ok, there might well be such command sequences, but my question is: who knows about them? Is this mandated by the MMC(/SD/SDIO/...) standard or is it host-specific? Also "might mean" is actually interesting here. I think we eventually need a combination of timing-oriented PM constraints and "stateful" ones. During such a command sequence you would require the card clock to stay on. > > To solve this, the mmc_claim_host is used, to make > > sure the host is enabled during the complete command sequence. > > > > I happily continue this discussion, to see if someone more can break the > > idea about having get_sync in mmc_host_enable. :-) > > I'll leave this one to Guennadi, if you don't mind. :-) As I said above, I think, we need both - to be able to require a certain responsiveness / throughput and specific interface parameters like supplying clock, power, etc. Also notice, that setting a constraint doesn't affect in principle, when the device is allowed to suspend. This is done as usual per pm_runtime_get*() and _put*(). I think, a reasonable solution to use PM QoS to impose timing constraints but at the same time to not disable the hardware, when this is disallowed, is to tie pm_runtime_get() and _put() calls to driver's .set_ios() method, like tmio_mmc and sh_mmcif drivers currently do. Those drivers only call pm_runtime_put() when the interface clock is gated. So, as long as the core is aware, that that IO sequence has to run uninterrupted without stopping the clock between single transfers, it just has to avoid gating the clock for that period and the interface will not enter any power-saving mode. So, I don't think we need to enforce pm_runtime_get_sync() in mmc_claim_host(). Thanks Guennadi > > >> Using PM QoS as you propose, might prevent some hosts from doing > > >> runtime_suspend|resume completely and thus those might not fulfill power > > >> consumption requirements instead. > > > > > > I'm not sure what scenario you have in mind. Care to elaborate? > > > > Well, suppose a the host drivers start considering the PM QoS > > requirement, but never can fulfill the requirement of 100us for it's > > runtime_suspend callback function... > > OK, that's a valid concern. This means there should be a way for user space > to specify the constraint somehow, because it's a user space's role to define > policies. > > > >> I do not think we can take this decision at this level. Is performance more > > >> important than power save, that is kind of the question. > > > > > > Yes, it is. Also, the number used here is somewhat arbitrary. > > > > For you maybe power management is less important, but I doubt everybody > > else agree to that. It is a more complex balance I believe. > > You're right. > > > > However, since no one except for SH7372 is now using device PM QoS, no one > > > else will be affected by this change at the moment. > > > > True, but that is not a good reason for adding more stuff to the mmc core. > > Good point. > > Thanks, > Rafael > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
WARNING: multiple messages have this Message-ID (diff)
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de> To: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Ulf Hansson <ulf.hansson@stericsson.com>, "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, Chris Ball <cjb@laptop.org>, "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org> Subject: Re: [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Date: Fri, 16 Dec 2011 10:14:11 +0100 (CET) [thread overview] Message-ID: <Pine.LNX.4.64.1112160954030.6572@axis700.grange> (raw) In-Reply-To: <201112142236.26739.rjw@sisk.pl> On Wed, 14 Dec 2011, Rafael J. Wysocki wrote: > On Wednesday, December 14, 2011, Ulf Hansson wrote: [snip] > > 2. > > When executing mmc/sd commands/requests the host must always be claimed > > (and thus the host is always enabled). Why? Why cannot we save some power between IO operations - if we can do this quickly and safely without affecting functionality and throughput? > > But more important some mmc/sd > > commands must be executed as a sequence, without the host being disabled > > in between the commands (since a disable might mean that the clock to > > card gets disabled). Ok, there might well be such command sequences, but my question is: who knows about them? Is this mandated by the MMC(/SD/SDIO/...) standard or is it host-specific? Also "might mean" is actually interesting here. I think we eventually need a combination of timing-oriented PM constraints and "stateful" ones. During such a command sequence you would require the card clock to stay on. > > To solve this, the mmc_claim_host is used, to make > > sure the host is enabled during the complete command sequence. > > > > I happily continue this discussion, to see if someone more can break the > > idea about having get_sync in mmc_host_enable. :-) > > I'll leave this one to Guennadi, if you don't mind. :-) As I said above, I think, we need both - to be able to require a certain responsiveness / throughput and specific interface parameters like supplying clock, power, etc. Also notice, that setting a constraint doesn't affect in principle, when the device is allowed to suspend. This is done as usual per pm_runtime_get*() and _put*(). I think, a reasonable solution to use PM QoS to impose timing constraints but at the same time to not disable the hardware, when this is disallowed, is to tie pm_runtime_get() and _put() calls to driver's .set_ios() method, like tmio_mmc and sh_mmcif drivers currently do. Those drivers only call pm_runtime_put() when the interface clock is gated. So, as long as the core is aware, that that IO sequence has to run uninterrupted without stopping the clock between single transfers, it just has to avoid gating the clock for that period and the interface will not enter any power-saving mode. So, I don't think we need to enforce pm_runtime_get_sync() in mmc_claim_host(). Thanks Guennadi > > >> Using PM QoS as you propose, might prevent some hosts from doing > > >> runtime_suspend|resume completely and thus those might not fulfill power > > >> consumption requirements instead. > > > > > > I'm not sure what scenario you have in mind. Care to elaborate? > > > > Well, suppose a the host drivers start considering the PM QoS > > requirement, but never can fulfill the requirement of 100us for it's > > runtime_suspend callback function... > > OK, that's a valid concern. This means there should be a way for user space > to specify the constraint somehow, because it's a user space's role to define > policies. > > > >> I do not think we can take this decision at this level. Is performance more > > >> important than power save, that is kind of the question. > > > > > > Yes, it is. Also, the number used here is somewhat arbitrary. > > > > For you maybe power management is less important, but I doubt everybody > > else agree to that. It is a more complex balance I believe. > > You're right. > > > > However, since no one except for SH7372 is now using device PM QoS, no one > > > else will be affected by this change at the moment. > > > > True, but that is not a good reason for adding more stuff to the mmc core. > > Good point. > > Thanks, > Rafael > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/
next prev parent reply other threads:[~2011-12-16 9:14 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-12-12 15:46 [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first Guennadi Liakhovetski 2011-12-12 15:46 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Guennadi Liakhovetski 2011-12-13 15:18 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Ulf Hansson 2011-12-13 15:18 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Ulf Hansson 2011-12-13 16:13 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Guennadi Liakhovetski 2011-12-13 16:13 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Guennadi Liakhovetski 2011-12-13 21:08 ` Rafael J. Wysocki 2011-12-13 21:08 ` Rafael J. Wysocki 2011-12-14 9:00 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Ulf Hansson 2011-12-14 9:00 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Ulf Hansson 2011-12-14 9:27 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Linus Walleij 2011-12-14 9:27 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Linus Walleij 2011-12-14 10:28 ` Rafael J. Wysocki 2011-12-14 10:28 ` Rafael J. Wysocki 2011-12-14 15:50 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Linus Walleij 2011-12-14 15:50 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Linus Walleij 2011-12-14 10:15 ` Rafael J. Wysocki 2011-12-14 10:15 ` Rafael J. Wysocki 2011-12-14 11:12 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Ulf Hansson 2011-12-14 11:12 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Ulf Hansson 2011-12-14 21:36 ` Rafael J. Wysocki 2011-12-14 21:36 ` Rafael J. Wysocki 2011-12-16 9:14 ` Guennadi Liakhovetski [this message] 2011-12-16 9:14 ` Guennadi Liakhovetski 2011-12-19 12:17 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is Ulf Hansson 2011-12-19 12:17 ` [PATCH/RFC] mmc: add a device PM QoS constraint when a host is first claimed Ulf Hansson 2012-03-03 20:53 ` Rafael J. Wysocki 2012-03-03 20:53 ` Rafael J. Wysocki
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=Pine.LNX.4.64.1112160954030.6572@axis700.grange \ --to=g.liakhovetski@gmx.de \ --cc=cjb@laptop.org \ --cc=linux-mmc@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=linux-sh@vger.kernel.org \ --cc=rjw@sisk.pl \ --cc=ulf.hansson@stericsson.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.