Re: [PATCH 1/3] PM: domains: Drop the performance state vote for a device at detach

03.09.2021 17:03, Ulf Hansson пишет:

On Fri, 3 Sept 2021 at 11:58, Dmitry Osipenko [off-list ref] wrote:

quoted

03.09.2021 11:22, Ulf Hansson пишет:

quoted

On Fri, 3 Sept 2021 at 08:01, Dmitry Osipenko [off-list ref] wrote:

quoted

02.09.2021 13:16, Ulf Hansson пишет:

quoted

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.

quoted

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? 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.