On Fri, Jul 07, 2017 at 03:13:48AM +0200, Rafael J. Wysocki wrote:

quoted

- Can I write new code for it or I need to depend on something?

There is nothing this code needs to depend on AFAICS, but there are existing
solutions in this problem space (ACPI power management, genpd), so it needs to
be careful enough about possible overlaps etc.

quoted

I find there is already "power state" concept at documentation.
Documentation/ABI/testing/sysfs-devices-power_state

This is ACPI-specific and only in sysfs directories representing ACPI device
objects (which aren't physical devices).

Anyway, since ACPI covers the problem space you are working in already,
your code has to be mutually exclusive with it.

quoted

- If I can write the new code for it, except the problems I want
to fix, are there any other use cases I need to consider?

I would start simple and focus on the particular problem at hand, that is
devices with two power states ("on" and "off") where the "on" state
depends on a number of clocks and/or GPIOs.  Still, I'd also avoid making
design choices that might prevent it from being extended in the future
if need be.

One major problem I can see is how to "attach" the power states framework
to a particular device (once we have discovered that it should be used with
that device).

For bus types that don't do power management of their own you could follow
ACPI (and genpd) and provide a PM domain for this purpose, but bus types
doing their own PM (like USB) will probably need to be treated differently.
In those cases the bus type code will have to know that it should call some
helpers to switch power states of devices.

After thinking more, using a power state framework is seems too heavy
for this use case. This use case is just do some clock and gpio
operations before device is created, and do some put operations
after device is deleted. We just need some helpers in one structure
(called "power sequence" or "power state") for this purpose.

For the use case, the clock and gpio operation can be done after device
is created, the power domain is more suitable.

quoted

quoted

Moreover, it assumes that all of the platforms including the IP block driven
by the controller driver in question will use the "power sequences" model,
but what if there are more generally defined power domains on them?

No, the IP block doesn't need this "power sequence", the power stuffs
(clock, gpio, regulator) are described at firmware (eg, DT), and power
operations are carried out during the probe, the device and driver match
happens before power operation.

But for devices on the bus (bus is controlled by controller), the match
information (eg, product id/vendor id) is stored at device's firmware, the
controller device needs to talk with its child first to get the match
information before the child device's probe.

Actually, that may vary from bus to bus.  In some cases the enumeration is
entirely firmware-based and in some cases devices are discoverable.

I guess you mean the latter situation and you are saying that subordinate
devices may need to be turned "on" (by means of a "power sequence") in order
to be enumerated.

Fair enough, but this is not what I meant.

The concern was that if drivers started to use "power sequences", they would
become incompatible with alternative solutions in the same problem space,
like genpd, but that need not be the case, so never mind.

"power sequence" is just used before the device is created and after the
device is deleted from the bus. I don't want to overlap with power
domain.

quoted

quoted

It looks like the power management should really be carried out by an
additional layer of code to avoid imposing platform dependencies on
controller drivers.

Further, what if there are "power sequences" for the host controllers
themselves?  Who's expected to operate those "power sequences" then?

See above.

Let me rephrase.  Assume that your host controller is a platform device and
it is not "on" when the SoC comes up.  It has to be turned "on" via a "power
sequence".  Who's expected to do that for it?

We can use power domain for it, doesn't need "power sequence" in this
series introduces.

-- 

Best Regards,
Peter Chen