From: Jisheng Zhang <jszhang-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
To: Mika Westerberg
<mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] i2c: designware: separate ops for system_sleep_pm and runtime_pm
Date: Wed, 20 May 2015 20:34:30 +0800 [thread overview]
Message-ID: <20150520203430.24edd2a8@xhacker> (raw)
In-Reply-To: <20150520121506.GU1490-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
Dear Mika,
On Wed, 20 May 2015 15:15:06 +0300
Mika Westerberg <mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> On Wed, May 20, 2015 at 07:34:22PM +0800, Jisheng Zhang wrote:
> > Sorry for confusion. Considering one platform which doesn't support power off
> > the i2c host but it can disable the host's clock. So in such platform, when
> > the host is runtime suspended, its clock is disabled, then i2c_dw_disable() will
> > hang when s2ram.
>
> Right. This happens also when the platform powers off the device.
>
> > Except using the runtime pm API to ensure the host is in
> > a correct state, is there any other solution? AFAIK, 'dev->power.direct_complete'
> > doesn't help such case.
>
> What I had in mind is something like below:
>
> static int i2c_dw_prepare(struct device *dev)
> {
> return pm_runtime_suspended(dev);
> }
>
> static void i2c_dw_complete(struct device *dev)
> {
> if (dev->power.direct_complete)
> pm_request_resume(dev);
> }
>
> In other words it checks if the device is already runtime suspended and
> prevents ->suspend() etc. from being called.
What amazing! I wrote the same code as yours after sending out the last email.
>
> If that does not work (I didn't try as this problem does not exist on
It works! How to submit the patch? Do you mind if I cook the patch and add
you signed-off?
Thanks a lot,
Jisheng
WARNING: multiple messages have this Message-ID (diff)
From: jszhang@marvell.com (Jisheng Zhang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] i2c: designware: separate ops for system_sleep_pm and runtime_pm
Date: Wed, 20 May 2015 20:34:30 +0800 [thread overview]
Message-ID: <20150520203430.24edd2a8@xhacker> (raw)
In-Reply-To: <20150520121506.GU1490@lahna.fi.intel.com>
Dear Mika,
On Wed, 20 May 2015 15:15:06 +0300
Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
> On Wed, May 20, 2015 at 07:34:22PM +0800, Jisheng Zhang wrote:
> > Sorry for confusion. Considering one platform which doesn't support power off
> > the i2c host but it can disable the host's clock. So in such platform, when
> > the host is runtime suspended, its clock is disabled, then i2c_dw_disable() will
> > hang when s2ram.
>
> Right. This happens also when the platform powers off the device.
>
> > Except using the runtime pm API to ensure the host is in
> > a correct state, is there any other solution? AFAIK, 'dev->power.direct_complete'
> > doesn't help such case.
>
> What I had in mind is something like below:
>
> static int i2c_dw_prepare(struct device *dev)
> {
> return pm_runtime_suspended(dev);
> }
>
> static void i2c_dw_complete(struct device *dev)
> {
> if (dev->power.direct_complete)
> pm_request_resume(dev);
> }
>
> In other words it checks if the device is already runtime suspended and
> prevents ->suspend() etc. from being called.
What amazing! I wrote the same code as yours after sending out the last email.
>
> If that does not work (I didn't try as this problem does not exist on
It works! How to submit the patch? Do you mind if I cook the patch and add
you signed-off?
Thanks a lot,
Jisheng
WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <jszhang@marvell.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>, <wsa@the-dreams.de>
Cc: <linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] i2c: designware: separate ops for system_sleep_pm and runtime_pm
Date: Wed, 20 May 2015 20:34:30 +0800 [thread overview]
Message-ID: <20150520203430.24edd2a8@xhacker> (raw)
In-Reply-To: <20150520121506.GU1490@lahna.fi.intel.com>
Dear Mika,
On Wed, 20 May 2015 15:15:06 +0300
Mika Westerberg <mika.westerberg@linux.intel.com> wrote:
> On Wed, May 20, 2015 at 07:34:22PM +0800, Jisheng Zhang wrote:
> > Sorry for confusion. Considering one platform which doesn't support power off
> > the i2c host but it can disable the host's clock. So in such platform, when
> > the host is runtime suspended, its clock is disabled, then i2c_dw_disable() will
> > hang when s2ram.
>
> Right. This happens also when the platform powers off the device.
>
> > Except using the runtime pm API to ensure the host is in
> > a correct state, is there any other solution? AFAIK, 'dev->power.direct_complete'
> > doesn't help such case.
>
> What I had in mind is something like below:
>
> static int i2c_dw_prepare(struct device *dev)
> {
> return pm_runtime_suspended(dev);
> }
>
> static void i2c_dw_complete(struct device *dev)
> {
> if (dev->power.direct_complete)
> pm_request_resume(dev);
> }
>
> In other words it checks if the device is already runtime suspended and
> prevents ->suspend() etc. from being called.
What amazing! I wrote the same code as yours after sending out the last email.
>
> If that does not work (I didn't try as this problem does not exist on
It works! How to submit the patch? Do you mind if I cook the patch and add
you signed-off?
Thanks a lot,
Jisheng
next prev parent reply other threads:[~2015-05-20 12:34 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 12:31 [PATCH] i2c: designware: separate ops for system_sleep_pm and runtime_pm Jisheng Zhang
2015-05-15 12:31 ` Jisheng Zhang
2015-05-15 12:31 ` Jisheng Zhang
[not found] ` <1431693099-2292-1-git-send-email-jszhang-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
2015-05-18 8:28 ` Mika Westerberg
2015-05-18 8:28 ` Mika Westerberg
2015-05-18 8:28 ` Mika Westerberg
[not found] ` <20150518082823.GH1490-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2015-05-19 12:32 ` Jisheng Zhang
2015-05-19 12:32 ` Jisheng Zhang
2015-05-19 12:32 ` Jisheng Zhang
2015-05-19 13:15 ` Mika Westerberg
2015-05-19 13:15 ` Mika Westerberg
2015-05-19 13:15 ` Mika Westerberg
[not found] ` <20150519131516.GO1490-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2015-05-20 11:34 ` Jisheng Zhang
2015-05-20 11:34 ` Jisheng Zhang
2015-05-20 11:34 ` Jisheng Zhang
2015-05-20 12:05 ` Jisheng Zhang
2015-05-20 12:05 ` Jisheng Zhang
2015-05-20 12:05 ` Jisheng Zhang
2015-05-20 12:15 ` Mika Westerberg
2015-05-20 12:15 ` Mika Westerberg
2015-05-20 12:15 ` Mika Westerberg
[not found] ` <20150520121506.GU1490-3PARRvDOhMZrdx17CPfAsdBPR1lH4CV8@public.gmane.org>
2015-05-20 12:34 ` Jisheng Zhang [this message]
2015-05-20 12:34 ` Jisheng Zhang
2015-05-20 12:34 ` Jisheng Zhang
2015-05-20 12:38 ` Jisheng Zhang
2015-05-20 12:38 ` Jisheng Zhang
2015-05-20 12:38 ` Jisheng Zhang
2015-05-20 12:55 ` Mika Westerberg
2015-05-20 12:55 ` Mika Westerberg
2015-05-20 12:55 ` Mika Westerberg
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=20150520203430.24edd2a8@xhacker \
--to=jszhang-eyqppykdwxrbdgjk7y7tuq@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mika.westerberg-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
/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 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.