On 11/22, Jon Hunter wrote:
On 22/11/16 18:26, Kevin Hilman wrote:Marek is attempting to do this for the samsung clock
Jon Hunter <jonathanh@xxxxxxxxxx> writes:I agree.
However, I would rather the client ofIMO, constructing a network of new struct devices just to workaround
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.
limitations in the framework doesn't sound quite right either.
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.