On 20/01/17 14:00, Ulf Hansson wrote: > + Sudeep > > On 19 January 2017 at 00:03, Rob Herring <robh@xxxxxxxxxx> wrote: >> >> 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. > IIUC do you mean the binding for the power domain provider to have a list of domain ids ? If so yes, we don't have one. But the idea was to have the range to be continuous and create genpd for the complete range. Though the SCPI specification lacked a command to get the max. no. of domains supported. That's the reason we had to introduce the num-domains(*) which may be optional if we have firmware interface to obtain that information. -- Regards, Sudeep (*) P.S: but it has been considered for SCMI(which is an improvement and more flexible/extensible replacement/upgrade to SCPI) which will be released soon. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
