On 07/10/16 10:14, Kevin Hilman wrote: > Jon Hunter <jonathanh@xxxxxxxxxx> writes: > >> Some devices may require more than one PM domain to operate and this is >> not currently by the PM domain framework. Furthermore, the current Linux >> 'device' structure only allows devices to be associated with a single PM >> domain and so cannot easily be associated with more than one. To allow >> devices to be associated with more than one PM domain, if multiple >> domains are defined for a given device (eg. via device-tree), then: >> 1. Create a new PM domain for this device. The name of the new PM domain >> created matches the device name for which it was created for. >> 2. Register the new PM domain as a sub-domain for all PM domains >> required by the device. >> 3. Attach the device to the new PM domain. > > Did you look at what might be involved to extend struct device to hace a > list of pm_domains? Like Ulf, I'm a bit unsettled by this > implementation that has to work around the basic limitation in the > driver model. I had but it was going to be a much bigger and intrusive change. So I went with this as a initial idea to see if others also had a need for it. I am happy to start looking at extended the device struct if this is the preferred path and I would agree that would make most sense. > Having devices in multitple domains is needed for SoCs I'm familiar with > also, so is a needed feature. Ok great. > I think removing the struct device limitation and corresponding > assumptions in the driver and PM core is a prerequisite for this > feature. > > Doing that will lead to several questions about how to handle runtime PM > operations (e.g. which of the multiple PM domains should the one to call > the drivers runtime PM hooks when a device changes runtime PM state?) Right. My initial thought would be that at least for device-tree based configuration, that the order in which the pm-domains are defined in DT would determine the order in which the pm-domains are power-on/off. > Anyways, even with the potential complexities, I think attempting this > is the right way forward. Ok. I will start having a think about this but will probably not get back to this for a few weeks. Cheers Jon -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
