Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains

On 01/20/2017 08:00 AM, Ulf Hansson wrote:

+ Sudeep

On 19 January 2017 at 00:03, Rob Herring [off-list ref] wrote:

quoted

On Tue, Jan 17, 2017 at 6:07 PM, Kevin Hilman [off-list ref] wrote:

quoted

Tero Kristo [off-list ref] writes:

quoted

On 17/01/17 00:12, Dave Gerlach wrote:

quoted

On 01/13/2017 08:40 PM, Rob Herring wrote:

quoted

On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach [off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

quoted

My ti,sci-id is not an index into a list of power domains, so it
should not
go in the power-domains cells and go against what the power-domains
binding
says that the cell expects. We have one single power domain, and the new
ti,sci-id binding is not something the genpd framework itself is
concerned
with as it's our property to identify a device inside a power domain,
not to
identify which power domain it is associated with.

What is the id used for? I can understand why you need to know what
power domain a device is in (as power-domains identifies), but not
what devices are in a power domain.

We have a system control processor that provides power management
services to the OS and it responsible for handling the power state of
each device. This control happens over a communication interface we have
called TI SCI (implemented at drivers/firmware/ti-sci.c). The
communication protocol uses these ids to identify each device within the
power domain so that the control processor can do what is necessary to
enable that device.

I think a minor detail here that Rob might be missing right now is,
that the ti,sci-id is only controlling the PM runtime handling, and
providing the ID per-device for this purpose only. AFAIK, it is not
really connected to the power domain anymore as such, as we don't have
power-domains / per device anymore as was the case in some earlier
revision of this work.

I think this gets to the heart of things.  IMO The confusion arises
because we're throwing around the term "power domain" when there isn't
an actual hardware power domain here.

I thought there was 1.

quoted

Unfortunately, the genpd bindings have used the terminology power-domain
when in fact genpd is more generic than that and can be used not just
for hardware power domains, but for arbitrary grouping of devices that
have common PM properties.  That's why genpd actually stands for generic
PM domain, not power domain.  Unfortunately, the bindings have grown
primarily out of the usage for hardware power domains.

Now it makes some sense.

So the question is does this PM domain grouping need to be described
in DT or not, and if so what does that look like?

Yes, it's needed and already being done. For example, we have clock
domains for several Renesas platforms.

quoted

We could continue to use the power domain binding (maybe we already
are and that ship has sailed). I'm not totally against the idea even
if there is no power domain, but I'm not sold on it either. If we do
go this route, then I still say the id should be a cell in the
power-domain phandle.

Another option is create something new either common or TI SCI
specific. It could be just a table of ids and phandles in the SCI
node. I'm much more comfortable with an isolated property in one node
than something scattered throughout the DT.

To me, this seems like the best possible solution.

However, perhaps we should also consider the SCPI Generic power domain
(drivers/firmware/scpi_pm_domain.c), because I believe it's closely
related.
To change the power state of a device, this PM domain calls
scpi_device_set|get_power_state() (drivers/firmware/arm_scpi.c), which
also needs a device id as a parameter. Very similar to our case with
the TI SCI domain.

Currently these SCPI device ids lacks corresponding DT bindings, so
the scpi_pm_domain tries to work around it by assigning ids
dynamically at genpd creation time.

That makes me wonder, whether we should think of something common/generic?

When you say something common/generic, do you mean a better binding for genpd,
or something bigger than that like a new driver? Because I do think a phandle
cell left open for the genpd provider to interpret solves both the scpi and
ti-sci problem we are facing here in the best way. Using generic PM domains lets
us do exactly what we want apart from interpreting the phandle cell with our
driver, and I feel like anything else we try at this point is just going to be
to work around that. Is bringing back genpd xlate something we can discuss?

Regards,
Dave

[...]

Kind regards
Uffe