Message-ID: <20161124023014.GK6095@codeaurora.org>
Date:   Wed, 23 Nov 2016 18:30:14 -0800
From:   Stephen Boyd <sboyd@...eaurora.org>
To:     Jon Hunter <jonathanh@...dia.com>
Cc:     Kevin Hilman <khilman@...libre.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
        Rajendra Nayak <rnayak@...eaurora.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: [RFC PATCH 0/3] PM / Domains: Add support for devices that
 require multiple domains

On 11/22, Jon Hunter wrote:
> 
> On 22/11/16 18:26, Kevin Hilman wrote:
> > Jon Hunter <jonathanh@...dia.com> 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@samsung.com
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Powered by blists - more mailing lists