Re: [PATCH v2 00/14] ARM: shmobile: Add CPG Clock Domains

[Kevin Hilman <khilman@kernel.org>]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Thu, May 28, 2015 at 8:53 PM, Geert Uytterhoeven
> <geert+renesas@glider.be> wrote:
>>         Hi all,
>>
>> This patch series adds Clock Domain support to the Clock Pulse Generator
>> (CPG) Module Stop (MSTP) Clocks driver using the generic PM Domain, to
>> be used on shmobile SoCs without device power domains (R-Car Gen1 and
>> Gen2, RZ).  This allows to power-manage the module clocks of SoC devices
>> that are part of the CPG Clock Domain using Runtime PM, or for system
>> suspend/resume, similar to SoCs with device power domains (SH-Mobile and
>> R-Mobile).
>>
>> SoC devices that are part of the CPG Clock Domain and can be
>> power-managed through an MSTP clock are tagged in DT with a proper
>> "power-domains" property. This applies to most on-SoC devices, which
>> have a one-to-one mapping from SoC device to DT device node.
>> Notable exceptions are "display" and "sound" device nodes, which
>> represent multiple SoC devices, each having their own MSTP clocks. Hence
>> drivers for such devices still have to manage their (multiple module)
>> clocks themselves.
>>
>> The (MSTP) clock to use for power-management is found by scanning for
>> clocks that are compatible with "renesas,cpg-mstp-clocks".
>> Before, the "first" clock tied to each device (con_id NULL) was used,
>> being a bit ad-hoc. It was suggested to use the "fck" clock instead,
>> but this may conflict with DT bindings for devices we don't control
>> (e.g. GIC-400 plans to mandate "clk" for the clk-name of its single
>> clock). Looking for real MSTP clocks avoids this problem.
>>
>> Logically, the CPG Clock Domain operates on the SoC CPG/MSTP block.
>> As there's no single device node in DT representing this block (there
>> are separate device nodes for the CPG and for the individual MSTP
>> clocks), I bound the logic to the CPG device node.
>> Perhaps this is something we should change for future SoCs?
>
> Inside Renesas, we've been discussing this face-to-face, but haven't
> reached a conclusion yet.
>
> In Linux terminology, "PM domain" is a higher-level abstraction than
> just (hardware) "power domain" (sometimes called "power area").
> A "PM domain" is any collection of devices that are power-managed
> similarly. As such it covers not only hardware power domains, but also
> clock domains, and even firmware controlled devices (e.g. as used by the
> Linux ACPI subsystem).
>
> I find it a bit unfortunate this was not reflected in the DT bindings
> for Generic PM domains, which use "power-domains" properties, making
> believe people this is about hardware power domains only.
>
> One other point of confusion is that there are multiple kernel
> subsystems that can (or seem to be able to) be used for the same
> purpose. Both regulators and power domains are used to "control power".
> The same is true for clocks vs. clock domains.
> My point of view is that the regulator and clock subsystems are more
> about the properties of regulators (voltage, current) resp. clocks
> (frequencies), while power/clock domains are about being active or
> inactive.
>
> On Renesas SoCs (SH/R-Mobile, R-Car, RZ), the MSTP (Module Standby and
> Software Reset) block is very intimately tied to the CPG (Clock Pulse
> Generator) block.
>
> The MSTP block provides two functions:
>   1. Module Standby: "Clock supply to specified modules is stopped by
>      setting the module stop control register bits."
>      However, the clock supply to a module is not stopped until all CPUs
>      in the SoC agree.  Indeed, there are separate MSTP registers for
>      application (Cortex-A) and real-time (SH and/or Cortex-R) cores.
>   2. Reset control. to perform a software reset of a specific module.
>
> Given the second function, perhaps the MSTP bits shouldn't have been
> moduled as clocks, but it made sense at the time of introduction, and
> IMHO it still does.
>
> However, due to the module standby function, all connected devices are
> grouped into a collection of devices that are power-managed similarly,
> by controlling the clock supply to the individual modules. So this
> warrants the use of a PM domain.

Agreed.

So,  what is the main objection to using PM domains for this?  Is it
only a terminology issue?

> Alternative solutions that have been proposed are:
>
>   1. | Explicit opt-in in drivers (from Laurent)
>      | As the driver knows best which clock it wants to manage, the
>      | driver could tell runtime PM if/when which clock to use.
>
>      My rebuttal here is twofold:
>        - Does the driver know best? It may know it may need to enable a
>          clock. But the clock may be optional: on some SoCs, the same IP
>          core may be present without the Module Standby feature (e.g.
>          the GPIO blocks on R-Car Gen1 are not documented to have MSTP
>          bits, while they do on R-Car Gen2). Why would the driver have
>          to care?
>
>          The hardware documentation clearly states the purpose of the
>          MSTP clocks: when a module is not in use, its module clock can
>          be stopped to reduce power consumption.  All of this should be
>          described in DT. We already have the clocks in DT. If a module
>          has an MSTP clock, it means the module can be put in standby
>          mode. This is the same for all modules, hence for all drivers.
>
>        - The idea is to reduce the amount of boilerplate code, not to
>          increase it. The more code we can move into platform code, the
>          less drivers have to care.
>
>          This is the real power behind the abstraction of runtime PM.
>          The driver only has to tell runtime PM when it wants to "use"
>          the hardware module, using pm_runtime_{get_sync,put}().
>          It doesn't have to know this involves enabling clocks and/or
>          power domains, or parent devices. All of this is taken care of
>          by a small piece of platform code, and the generic code.

Exactly, this is real power of this abstraction when used fully.

>          As not all drivers are runtime PM-aware yet, calls to
>          pm_runtime_*() functions may have to be added, though. But
>          that's it.
>
>      Side note: Laurent has been mostly involved with multimedia devices.
>      And let display and sound be the two exceptions where there's no
>      one-to-one mapping from SoC devices to DT device nodes...
>      Hence the multimedia drivers would have to manage the (multiple)
>      module clocks anyway.
>
>      Perhaps the display and sound bindings can be reworked, to better
>      describe the hardware structure, and expose a one-to-one mapping
>      between MSTP clocks and hardware modules, too?
>
>   2. | Handling MSTP clocks automatically in a similar way that the current
>      | code handles the first clock, without requiring usage of a
>      | power-domain property in DT (from Magnus)
>      | As there are already "clocks = <...>" links from device nodes to MSTP
>      | clocks in DT, we can just scan for those, without requiring
>      | (superfluous) "power-domains = <...>" properties in DT.
>
>      Indeed, given the presence of a link to an MSTP clock in a device
>      node, we know the module can be put in standby mode.
>      But without the standard "power-domains" property, we would need
>      our own specialized code to scan all nodes for MSTP clocks (through
>      a platform_bus notifier again?), and add the corresponding devices
>      to the clock domain.  Hence the "power-domains" properties allow to
>      use the generic code, and thus share more code with other SoCs.

IMO, a clear win.

>      In addition, a "power-domains" property gives a strong clue to
>      people not familiar with Renesas SoCs and their MSTP clocks.

As a regular reviewer of PM code for SoCs that I'm not familiar with,
this is another big win from my perspective.

Kevin