All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	linux-pm@vger.kernel.org
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Stephan Gerhold <stephan@gerhold.net>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach
Date: Fri, 3 Sep 2021 09:01:00 +0300	[thread overview]
Message-ID: <08335cd4-7dc8-3b8b-d63f-374585ffa373@gmail.com> (raw)
In-Reply-To: <20210902101634.827187-2-ulf.hansson@linaro.org>

02.09.2021 13:16, Ulf Hansson пишет:
> When a device is detached from its genpd, genpd loses track of the device,
> including its performance state vote that may have been requested for it.
> 
> Rather than relying on the consumer driver to drop the performance state
> vote for its device, let's do it internally in genpd when the device is
> getting detached. In this way, we makes sure that the aggregation of the
> votes in genpd becomes correct.

This is a dangerous behaviour in a case where performance state
represents voltage. If hardware is kept active on detachment, say it's
always-on, then it may be a disaster to drop the voltage for the active
hardware.

It's safe to drop performance state only if you assume that there is a
firmware behind kernel which has its own layer of performance management
and it will prevent the disaster by saying 'nope, I'm not doing this'.

The performance state should be persistent for a device and it should be
controlled in a conjunction with runtime PM. If platform wants to drop
performance state to zero on detachment, then this behaviour should be
specific to that platform.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	linux-pm@vger.kernel.org
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	Stephan Gerhold <stephan@gerhold.net>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach
Date: Fri, 3 Sep 2021 09:01:00 +0300	[thread overview]
Message-ID: <08335cd4-7dc8-3b8b-d63f-374585ffa373@gmail.com> (raw)
In-Reply-To: <20210902101634.827187-2-ulf.hansson@linaro.org>

02.09.2021 13:16, Ulf Hansson пишет:
> When a device is detached from its genpd, genpd loses track of the device,
> including its performance state vote that may have been requested for it.
> 
> Rather than relying on the consumer driver to drop the performance state
> vote for its device, let's do it internally in genpd when the device is
> getting detached. In this way, we makes sure that the aggregation of the
> votes in genpd becomes correct.

This is a dangerous behaviour in a case where performance state
represents voltage. If hardware is kept active on detachment, say it's
always-on, then it may be a disaster to drop the voltage for the active
hardware.

It's safe to drop performance state only if you assume that there is a
firmware behind kernel which has its own layer of performance management
and it will prevent the disaster by saying 'nope, I'm not doing this'.

The performance state should be persistent for a device and it should be
controlled in a conjunction with runtime PM. If platform wants to drop
performance state to zero on detachment, then this behaviour should be
specific to that platform.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-09-03  6:01 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-02 10:16 [PATCH 0/3] PM: domains: Improvements for performance states in genpd Ulf Hansson
2021-09-02 10:16 ` Ulf Hansson
2021-09-02 10:16 ` [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach Ulf Hansson
2021-09-02 10:16   ` Ulf Hansson
2021-09-03  6:01   ` Dmitry Osipenko [this message]
2021-09-03  6:01     ` Dmitry Osipenko
2021-09-03  8:22     ` Ulf Hansson
2021-09-03  8:22       ` Ulf Hansson
2021-09-03  9:58       ` Dmitry Osipenko
2021-09-03  9:58         ` Dmitry Osipenko
2021-09-03 14:03         ` Ulf Hansson
2021-09-03 14:03           ` Ulf Hansson
2021-09-05  8:26           ` Dmitry Osipenko
2021-09-05  8:26             ` Dmitry Osipenko
2021-09-06 10:24             ` Ulf Hansson
2021-09-06 10:24               ` Ulf Hansson
2021-09-06 14:11               ` Dmitry Osipenko
2021-09-06 14:11                 ` Dmitry Osipenko
2021-09-06 17:34                 ` Ulf Hansson
2021-09-06 17:34                   ` Ulf Hansson
2021-09-06 19:33                   ` Dmitry Osipenko
2021-09-06 19:33                     ` Dmitry Osipenko
2021-09-07 10:16                     ` Ulf Hansson
2021-09-07 10:16                       ` Ulf Hansson
2021-09-09 13:48                       ` Dmitry Osipenko
2021-09-09 13:48                         ` Dmitry Osipenko
2021-09-09 14:45                         ` Ulf Hansson
2021-09-09 14:45                           ` Ulf Hansson
2021-09-02 10:16 ` [PATCH 2/3] PM: domains: Restructure some code in __genpd_dev_pm_attach() Ulf Hansson
2021-09-02 10:16   ` Ulf Hansson
2021-09-02 10:16 ` [PATCH 3/3] PM: domains: Add a ->dev_get_performance_state() callback to genpd Ulf Hansson
2021-09-02 10:16   ` Ulf Hansson
2021-09-03  6:00   ` Dmitry Osipenko
2021-09-03  6:00     ` Dmitry Osipenko
2021-09-03  8:55     ` Ulf Hansson
2021-09-03  8:55       ` Ulf Hansson
2021-09-03 10:06       ` Dmitry Osipenko
2021-09-03 10:06         ` Dmitry Osipenko
2021-09-03 14:09         ` Ulf Hansson
2021-09-03 14:09           ` Ulf Hansson
2021-09-05  9:11           ` Dmitry Osipenko
2021-09-05  9:11             ` Dmitry Osipenko
2021-09-06 10:53             ` Ulf Hansson
2021-09-06 10:53               ` Ulf Hansson
2021-09-06 14:35               ` Dmitry Osipenko
2021-09-06 14:35                 ` Dmitry Osipenko
2021-09-07  3:40                 ` Viresh Kumar
2021-09-07  3:40                   ` Viresh Kumar
2021-09-07  8:10                   ` Dmitry Osipenko
2021-09-07  8:10                     ` Dmitry Osipenko
2021-09-07  9:57                 ` Ulf Hansson
2021-09-07  9:57                   ` Ulf Hansson
2021-09-09 13:48                   ` Dmitry Osipenko
2021-09-09 13:48                     ` Dmitry Osipenko
2021-09-09 14:39                     ` Ulf Hansson
2021-09-09 14:39                       ` Ulf Hansson
2021-09-10 11:24                       ` Dmitry Osipenko
2021-09-10 11:24                         ` Dmitry Osipenko

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=08335cd4-7dc8-3b8b-d63f-374585ffa373@gmail.com \
    --to=digetx@gmail.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=rnayak@codeaurora.org \
    --cc=stephan@gerhold.net \
    --cc=thierry.reding@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --cc=viresh.kumar@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.