All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Kevin Hilman <khilman@kernel.org>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Lina Iyer <lina.iyer@linaro.org>,
	Andy Gross <andy.gross@linaro.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()
Date: Thu, 12 May 2016 22:28:22 +0200	[thread overview]
Message-ID: <CAJZ5v0jTAM74asCM5gG5wBWn+gvSQ21_W6dY9WQD+cMybUnEEg@mail.gmail.com> (raw)
In-Reply-To: <4661739.p5SU9QcIps@avalon>

On Thu, May 12, 2016 at 9:01 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hello,
>
> On Wednesday 27 Apr 2016 16:23:49 Ulf Hansson wrote:
>> [...]
>>
>> >> Following you reasoning, I agree!
>> >>
>> >> Let's put this patch on hold for a little while. I am already working
>> >> on changing genpd, so it shouldn't take long before I can post some
>> >> additional genpd patches improving the behaviour.
>> >
>> > I'd like to see something merged for v4.7 if possible. I agree that my
>> > patch isn't a long term solution (we want to avoid adding additional
>> > fields to the device power structure), but it has the benefit of being
>> > available now and fixing the problem I ran into with drivers that would
>> > be broken on v4.7 without a fix. Do you think you could get a better fix
>> > ready in time for v4.7 ? If so I'm fine with dropping this patch, but
>> > otherwise I'd prefer to get it merged and reverted as part of your better
>> > implementation for v4.8.
>>
>> My impression was that devices becomes unnecessary resumed when they
>> don't need to. They won't stay resumed as the PM core invokes
>> pm_runtime_put() in the system PM complete phase.
>>
>> So, in the end I think we are trying to optimize a behaviour here, but
>> not fix something that is "broken", correct?
>>
>> Anyway, I have no objections to your proposed solution, so I leave it
>> to Rafael and Kevin to decide what to do.
>
> Kevin, Rafael, any comment ? I need to fix PM support in a driver that is
> currently broken partly due to this issue. Which of "PM / Runtime: Only force-
> resume device if it has been force-suspended" and this patch should we merge,
> if any ?

My and Kevin's assumption was that Ulf would provide a better fix
shortly, but I'm not sure how realistic that is.

Ulf?

WARNING: multiple messages have this Message-ID (diff)
From: rafael@kernel.org (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume()
Date: Thu, 12 May 2016 22:28:22 +0200	[thread overview]
Message-ID: <CAJZ5v0jTAM74asCM5gG5wBWn+gvSQ21_W6dY9WQD+cMybUnEEg@mail.gmail.com> (raw)
In-Reply-To: <4661739.p5SU9QcIps@avalon>

On Thu, May 12, 2016 at 9:01 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hello,
>
> On Wednesday 27 Apr 2016 16:23:49 Ulf Hansson wrote:
>> [...]
>>
>> >> Following you reasoning, I agree!
>> >>
>> >> Let's put this patch on hold for a little while. I am already working
>> >> on changing genpd, so it shouldn't take long before I can post some
>> >> additional genpd patches improving the behaviour.
>> >
>> > I'd like to see something merged for v4.7 if possible. I agree that my
>> > patch isn't a long term solution (we want to avoid adding additional
>> > fields to the device power structure), but it has the benefit of being
>> > available now and fixing the problem I ran into with drivers that would
>> > be broken on v4.7 without a fix. Do you think you could get a better fix
>> > ready in time for v4.7 ? If so I'm fine with dropping this patch, but
>> > otherwise I'd prefer to get it merged and reverted as part of your better
>> > implementation for v4.8.
>>
>> My impression was that devices becomes unnecessary resumed when they
>> don't need to. They won't stay resumed as the PM core invokes
>> pm_runtime_put() in the system PM complete phase.
>>
>> So, in the end I think we are trying to optimize a behaviour here, but
>> not fix something that is "broken", correct?
>>
>> Anyway, I have no objections to your proposed solution, so I leave it
>> to Rafael and Kevin to decide what to do.
>
> Kevin, Rafael, any comment ? I need to fix PM support in a driver that is
> currently broken partly due to this issue. Which of "PM / Runtime: Only force-
> resume device if it has been force-suspended" and this patch should we merge,
> if any ?

My and Kevin's assumption was that Ulf would provide a better fix
shortly, but I'm not sure how realistic that is.

Ulf?

  reply	other threads:[~2016-05-12 20:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-21 10:34 [PATCH] PM / Runtime: Defer resuming of the device in pm_runtime_force_resume() Ulf Hansson
2016-04-21 10:34 ` Ulf Hansson
2016-04-21 17:31 ` Laurent Pinchart
2016-04-21 17:31   ` Laurent Pinchart
2016-04-21 20:57   ` Laurent Pinchart
2016-04-21 20:57     ` Laurent Pinchart
2016-04-22 20:27     ` Kevin Hilman
2016-04-22 20:27       ` Kevin Hilman
2016-04-25  8:15       ` Ulf Hansson
2016-04-25  8:15         ` Ulf Hansson
2016-04-25 13:32   ` Ulf Hansson
2016-04-25 13:32     ` Ulf Hansson
2016-04-25 16:52     ` Laurent Pinchart
2016-04-25 16:52       ` Laurent Pinchart
2016-04-27 14:23       ` Ulf Hansson
2016-04-27 14:23         ` Ulf Hansson
2016-05-12 19:01         ` Laurent Pinchart
2016-05-12 19:01           ` Laurent Pinchart
2016-05-12 20:28           ` Rafael J. Wysocki [this message]
2016-05-12 20:28             ` Rafael J. Wysocki
2016-05-13 13:59             ` Ulf Hansson
2016-05-13 13:59               ` Ulf Hansson
2016-04-21 19:23 ` Rafael J. Wysocki
2016-04-21 19:23   ` Rafael J. Wysocki
2016-04-22  6:58   ` Ulf Hansson
2016-04-22  6:58     ` Ulf Hansson

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=CAJZ5v0jTAM74asCM5gG5wBWn+gvSQ21_W6dY9WQD+cMybUnEEg@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=andy.gross@linaro.org \
    --cc=khilman@kernel.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=len.brown@intel.com \
    --cc=lina.iyer@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=sergei.shtylyov@cogentembedded.com \
    --cc=stern@rowland.harvard.edu \
    --cc=ulf.hansson@linaro.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.