From: Ulf Hansson <ulf.hansson@linaro.org> To: Dmitry Osipenko <digetx@gmail.com> Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>, Viresh Kumar <viresh.kumar@linaro.org>, Linux PM <linux-pm@vger.kernel.org>, 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 <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach Date: Mon, 6 Sep 2021 12:24:51 +0200 [thread overview] Message-ID: <CAPDyKFoyszG2Wo3jbXK562XgpqXns_GPqm7nNu8WOdMCXYUOMQ@mail.gmail.com> (raw) In-Reply-To: <6603212d-f36c-afff-6222-8125de5b7b79@gmail.com> On Sun, 5 Sept 2021 at 10:26, Dmitry Osipenko <digetx@gmail.com> wrote: > > 03.09.2021 17:03, Ulf Hansson пишет: > > On Fri, 3 Sept 2021 at 11:58, Dmitry Osipenko <digetx@gmail.com> wrote: > >> > >> 03.09.2021 11:22, Ulf Hansson пишет: > >>> On Fri, 3 Sept 2021 at 08:01, Dmitry Osipenko <digetx@gmail.com> wrote: > >>>> > >>>> 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. > >>> > >>> I understand your concern, but at this point, genpd can't help to fix this. > >>> > >>> Genpd has no information about the device, unless it's attached to it. > >>> For now and for these always on HWs, we simply need to make sure the > >>> device stays attached, in one way or the other. > >> > >> This indeed requires to redesign GENPD to make it more coupled with a > >> device, but this is not a real problem for any of the current API users > >> AFAIK. Ideally the state should be persistent to make API more universal. > > > > Right. In fact this has been discussed in the past. In principle, the > > idea was to attach to genpd at device registration, rather than at > > driver probe. > > > > Although, this is not very easy to implement - and it seems like the > > churns to do, have not been really worth it. At least so far. > > > >> > >> Since for today we assume that device should be suspended at the time of > >> the detachment (if the default OPP state isn't used), it may be better > >> to add a noisy warning message if pstate!=0, keeping the state untouched > >> if it's not zero. > > > > That would just be very silly in my opinion. > > > > When the device is detached (suspended or not), it may cause it's PM > > domain to be powered off - and there is really nothing we can do about > > that from the genpd point of view. > > > > As stated, the only current short term solution is to avoid detaching > > the device. Anything else, would just be papering of the issue. > > What about to re-evaluate the performance state of the domain after > detachment instead of setting the state to zero? I am not suggesting to set the performance state of the genpd to zero, but to drop a potential vote for a performance state for the *device* that is about to be detached. Calling genpd_set_performance_state(dev, 0), during detach will have the same effect as triggering a re-evaluation of the performance state for the genpd, but after the detach. > This way PD driver may > take an action on detachment if performance isn't zero, before hardware > is crashed, for example it may emit a warning. Not sure I got that. Exactly when do you want to emit a warning and for what reason? Do you want to add a check somewhere to see if 'gpd_data->performance_state' is non zero - and then print a warning? Kind regards Uffe
WARNING: multiple messages have this Message-ID (diff)
From: Ulf Hansson <ulf.hansson@linaro.org> To: Dmitry Osipenko <digetx@gmail.com> Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>, Viresh Kumar <viresh.kumar@linaro.org>, Linux PM <linux-pm@vger.kernel.org>, 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 <linux-arm-kernel@lists.infradead.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org> Subject: Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach Date: Mon, 6 Sep 2021 12:24:51 +0200 [thread overview] Message-ID: <CAPDyKFoyszG2Wo3jbXK562XgpqXns_GPqm7nNu8WOdMCXYUOMQ@mail.gmail.com> (raw) In-Reply-To: <6603212d-f36c-afff-6222-8125de5b7b79@gmail.com> On Sun, 5 Sept 2021 at 10:26, Dmitry Osipenko <digetx@gmail.com> wrote: > > 03.09.2021 17:03, Ulf Hansson пишет: > > On Fri, 3 Sept 2021 at 11:58, Dmitry Osipenko <digetx@gmail.com> wrote: > >> > >> 03.09.2021 11:22, Ulf Hansson пишет: > >>> On Fri, 3 Sept 2021 at 08:01, Dmitry Osipenko <digetx@gmail.com> wrote: > >>>> > >>>> 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. > >>> > >>> I understand your concern, but at this point, genpd can't help to fix this. > >>> > >>> Genpd has no information about the device, unless it's attached to it. > >>> For now and for these always on HWs, we simply need to make sure the > >>> device stays attached, in one way or the other. > >> > >> This indeed requires to redesign GENPD to make it more coupled with a > >> device, but this is not a real problem for any of the current API users > >> AFAIK. Ideally the state should be persistent to make API more universal. > > > > Right. In fact this has been discussed in the past. In principle, the > > idea was to attach to genpd at device registration, rather than at > > driver probe. > > > > Although, this is not very easy to implement - and it seems like the > > churns to do, have not been really worth it. At least so far. > > > >> > >> Since for today we assume that device should be suspended at the time of > >> the detachment (if the default OPP state isn't used), it may be better > >> to add a noisy warning message if pstate!=0, keeping the state untouched > >> if it's not zero. > > > > That would just be very silly in my opinion. > > > > When the device is detached (suspended or not), it may cause it's PM > > domain to be powered off - and there is really nothing we can do about > > that from the genpd point of view. > > > > As stated, the only current short term solution is to avoid detaching > > the device. Anything else, would just be papering of the issue. > > What about to re-evaluate the performance state of the domain after > detachment instead of setting the state to zero? I am not suggesting to set the performance state of the genpd to zero, but to drop a potential vote for a performance state for the *device* that is about to be detached. Calling genpd_set_performance_state(dev, 0), during detach will have the same effect as triggering a re-evaluation of the performance state for the genpd, but after the detach. > This way PD driver may > take an action on detachment if performance isn't zero, before hardware > is crashed, for example it may emit a warning. Not sure I got that. Exactly when do you want to emit a warning and for what reason? Do you want to add a check somewhere to see if 'gpd_data->performance_state' is non zero - and then print a warning? Kind regards Uffe _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-06 10:25 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 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 [this message] 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=CAPDyKFoyszG2Wo3jbXK562XgpqXns_GPqm7nNu8WOdMCXYUOMQ@mail.gmail.com \ --to=ulf.hansson@linaro.org \ --cc=bjorn.andersson@linaro.org \ --cc=digetx@gmail.com \ --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=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: 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.