lkml.org 
[lkml]   [2016]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH 0/3] PM / Domains: Add support for devices that require multiple domains
    From
    Date
    Hi Stephen,

    Thanks for pointing to my patches, but I would like to clarify a few things.

    On 2016-11-24 03:30, Stephen Boyd wrote:
    > On 11/22, Jon Hunter wrote:
    >> On 22/11/16 18:26, Kevin Hilman wrote:
    >>> Jon Hunter <jonathanh@nvidia.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).

    You probably meant patch #3 / #4, which is a patch for Exynos 4412
    ( https://marc.info/?l=linux-arm-kernel&m=147731142926053&w=2 ).

    Patch #5 is for Exynos 5433, which already has separate nodes for
    each clock sub-controller, so there is no problem to add generic
    power domains there (see multiple CMU nodes):

    https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/exynos/exynos5433.dtsi#n261

    > 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.

    This is valid only for the Exynos4412 case (and not-yet-posted
    Exynos5422), which has a single clock controller node and patch #4
    added a sub-node for ISP clocks part (the only one which in fact
    is in the other power domain).

    > 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.

    Right, this is how I did it for Exynos4412 case.

    > Some of those devices don't have
    > any driver bound to them, which feels odd.

    Well, I don't get this. In the proposed patches each sub-node has
    a separate driver, none is left without a driver.

    > 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.

    Having an API for full control over multiple power domain assigned to
    a single device node might indeed solve somehow this problem, but as
    long as runtime pm is tied to struct device, this will again end in
    creating virtual sub-devices per each power domain to fit runtime pm
    principles. However we might be able to avoid creating sub-nodes in
    the device tree.

    Best regards
    --
    Marek Szyprowski, PhD
    Samsung R&D Institute Poland

    \
     
     \ /
      Last update: 2016-11-29 12:34    [W:3.434 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site