From: Kevin Hilman <khilman@ti.com>
To: "Dong, Chuanxiao" <chuanxiao.dong@intel.com>
Cc: Balaji T K <balajitk@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"cjb@laptop.org" <cjb@laptop.org>,
"tony@atomide.com" <tony@atomide.com>,
"madhu.cr@ti.com" <madhu.cr@ti.com>,
"b-cousson@ti.com" <b-cousson@ti.com>,
"paul@pwsan.com" <paul@pwsan.com>,
"kishore.kadiyala@ti.com" <kishore.kadiyala@ti.com>
Subject: Re: [PATCHv4 2/3] MMC: OMAP: HSMMC: add runtime pm support
Date: Wed, 13 Jul 2011 07:59:54 -0700 [thread overview]
Message-ID: <87sjqaql91.fsf@ti.com> (raw)
In-Reply-To: <5D8008F58939784290FAB48F5497519846C4113396@shsmsx502.ccr.corp.intel.com> (Chuanxiao Dong's message of "Wed, 13 Jul 2011 17:09:08 +0800")
"Dong, Chuanxiao" <chuanxiao.dong@intel.com> writes:
[...]
>>
>> Basially, the question is: can the driver be reworked such that a system
>> suspend does not need to runtime resume the device? For most devices,
>> we kind of expect that if the device is runtime suspended, a system
>> suspend will have nothing extra to do, but this driver runtime resumes
>> the device during system suspend in order to do "stuff", which I
>> admitedly don't fully undestand.
>>
>> Ideally, the "stuff" needed for runtime suspend and system suspend could
>> be made to be common such that a system suspend of a runtime suspended
>> device would be a noop.
>>
>> Is this possible?
>>
>> Kevin
>
> During system suspended patch, a callback named .prepare will be first
> done before .suspend is called, and .complete callback will be called
> after .resume is called. These two callbacks are in pair. If driver
> can implement the .prepare and hold the usage count in this callback,
> then runtime pm suspend/resume will not happen during device
> suspending. So there will be no need to add pm_runtime_get* and
> pm_runtime_put* in .suspend/.resume.
That doesn't avoid the problem, since the device is still runtime
resumed and then re-suspended during system suspend.
My basic question is this: why does this device need to be runtime
resumed during system suspend? Why can't it just stay runtime
suspended?
Kevin
next prev parent reply other threads:[~2011-07-13 14:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 16:39 [PATCHv4 0/3] OMAP: HSMMC: cleanup and runtime pm Balaji T K
2011-07-01 16:39 ` [PATCHv4 1/3] MMC: OMAP: HSMMC: Remove lazy_disable Balaji T K
2011-07-01 16:39 ` [PATCHv4 2/3] MMC: OMAP: HSMMC: add runtime pm support Balaji T K
2011-07-08 18:24 ` Kevin Hilman
2011-07-13 9:09 ` Dong, Chuanxiao
2011-07-13 14:59 ` Kevin Hilman [this message]
2011-07-13 15:34 ` S, Venkatraman
2011-07-13 15:56 ` Kevin Hilman
2011-07-01 16:39 ` [PATCHv4 3/3] MMC: OMAP: HSMMC: Remove unused iclk Balaji T K
[not found] ` <8762nlzy1d.fsf@ti.com>
[not found] ` <CANrkHUb-i4cQmGzrDjcooZPRvyQLSd0+kqLMA04hGzgVjCT+=A@mail.gmail.com>
2011-07-04 18:05 ` [PATCHv4 0/3] OMAP: HSMMC: cleanup and runtime pm S, Venkatraman
2011-07-05 17:43 ` Kevin Hilman
2011-07-09 22:30 ` Chris Ball
2011-07-09 22:33 ` Paul Walmsley
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=87sjqaql91.fsf@ti.com \
--to=khilman@ti.com \
--cc=b-cousson@ti.com \
--cc=balajitk@ti.com \
--cc=chuanxiao.dong@intel.com \
--cc=cjb@laptop.org \
--cc=kishore.kadiyala@ti.com \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=madhu.cr@ti.com \
--cc=paul@pwsan.com \
--cc=tony@atomide.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox