On 11/22, Jon Hunter wrote: > > On 22/11/16 18:26, Kevin Hilman wrote: > > Jon Hunter <jonathanh@xxxxxxxxxx> writes: > > > >> However, I would rather the client of > >> the power-domains specify which power-domains they require and > >> dynamically nested the power-domains at runtime. This is slightly > >> different to what I proposed in this RFC, but it is not really beyond > >> the bounds of what we support today IMO. What is missing is a means to > >> do this dynamically and not statically. > >> > >> By the way, I am not sure if you are suggesting that for devices that > >> may need multiple power-domains we should architect the driver > >> differently and split it up in some way such that we have a power-domain > >> per device. But for the case of the Tegra XHCI it is quite complex > >> because the driver loads firmware which runs on a micro-controller and > >> we need to manage the various power-domains that are used. > > > > IMO, constructing a network of new struct devices just to workaround > > limitations in the framework doesn't sound quite right either. > > I agree. > Marek is attempting to do this for the samsung clock controller[1] (patch #5 is informative). From what I can tell they have one DT node for their clock controller because it's one register address space to control clocks. But, certain clocks exposed by that driver only work when certain power domains are enabled. For example, they have a clock controller that exposes clock signals for multimedia hardware blocks like video accelerators, gpus, and cameras. The clocks seem to have been placed inside different power domains for the multimedia hardware they're associated with, so there may be 10 or so power domains that need to be enabled at different times for different clocks to work. If the GPU power domain isn't enabled when the GPU clocks are touched by the driver, things break, etc. In the proposed patchset, we have the top-level clock controller node with subnodes for each power domain that needs to be associated with clocks inside these different multimedia blocks. So we end up with one parent device and attached driver for the clock driver, and then that driver populates child nodes as devices and matches up clocks with child nodes while registering clks with clk_register(). Because we pass a dev pointer to clk_register, we associate different devices with different clocks all from the same top-level clock controller device driver. Then clk framework calls runtime_pm APIs with devices used during clk registration. Some of those devices don't have any driver bound to them, which feels odd. This seems like a case where we really want a better way to explicitly control power domains without making up subnodes and registering struct devices just to work around the one device to one genpd construct we have today. Maybe power domains just don't map to genpd though and that's the disconnect. [1] http://lkml.kernel.org/r/1477311130-6534-1-git-send-email-m.szyprowski@xxxxxxxxxxx -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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
