On 01/20/2017 10:52 AM, Ulf Hansson wrote:
[...]
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?
Bringing back xlate, how would that help? Wouldn't that just mean that
you will get one genpd per device? That's not an option, I think we
are all in agreement to that.
Sure, perhaps the custom xlate wouldn't be the right way to do it, as we
wouldn't be able to associate a device directly to a phandle, at least
with how it was implemented before, but I think we can skip that
entirely. Does opening up the interpretation of the cells of the
'power-domains' phandle not solve all of these issues? Is that out of
the question?
genpd_xlate_simple currently just makes sure the args_count of the
'power-domains' phandle was zero and bails if it was not. Why couldn't
we remove this check and let the driver interpret it while still using
of_genpd_add_provider_simple to register the provider? It's still a
'simple' provider from the perspective of the genpd framework and the
actual pm domain mapping will not change, but now the driver can parse
the cells and do whatever it needs to, such as reading a device id.
I think that's a bit more flexible and will avoid breaking anything that
is there today.
Regards,
Dave
Or am I missing something here?
Regarding something "common/generic", I was merely thinking of some
common bindings describing the list of phandle to device ids mapping.
However, let's not make this more complicated than it is already. So
please just ignore my suggestion so we can make this work for your
case first.
However, maybe I didn't fully understood Rob's suggestion. Perhaps Rob
can clarify once more.
Anyway, this is how interpreted Rob's suggestion:
TISCI_PM_DOMAIN_DEVLIST: tisci-pm-domain-devlist {
devs = <&serial0>, <&mmc0>;
devids = <5 10>;
}
With this, you should be to extract the devid which corresponds to the
device that has been attached to the TI SCI PM domain. Don't you
think?
Kind regards
Uffe
