Subject: Re: [PATCH/RFC 10/14] dt-bindings: power: Document Renesas R-Car X5H Module Controller

From: Marek Vasut <[email-masked]>
Date: Thu, 7 May 2026 23:36:17 +0200

On 5/7/26 9:37 AM, Geert Uytterhoeven wrote:

Hello Geert,

> On Thu, 7 May 2026 at 00:58, Marek Vasut <[email-masked]> wrote:
>> On 4/21/26 8:11 PM, Geert Uytterhoeven wrote:
>>> +  '#power-domain-cells':
>>> +    description: |
>>> +      - The first power domain specifier cell must be either the Module
>>> +        Power Domain Gating (MPDG) register index (0x00-0x3f) from the
>>> +        datasheet,
>>
>> I agree with this part.
>>
>>> or a Power Domain number, as defined in
>>> +        <dt-bindings/power/renesas,r8a78000-mdlc.h>,
>>
>> I do not understand this part, please see end of this email ...
>>
>>> +      - The second power domain specifier cell must be the module number
>>> +        (0x00-0xff), composed of the Module System Reset (MSRES) register index
>>> +        in the high nibble, and the Module Reset Destination bitfield index in
>>> +        the low nibble.
>>> +    const: 2
>>
>> I am unsure about this part.
>>
>> There are multiple MDLC blocks, AON, SCP, HSCN, and so on. Each MDLC
>> block contains multiple Module Power Domain Gating registers (MPDGn) and
>> multiple Module System RESet register (MSRES) .
>>
>> I do understand and agree that the first power-domains-cells cell must
>> be the identifier of power domain within the MDLC block.
>>
>> However, I do not understand the second cell. The MDLC bindings already
>> contain reset-cells, which should be used to refer to a reset within the
>> MDLC block. Resets within the MDLC block are operated using the MSRES
>> registers. Why are resets conflated into power-domain-cells ?
> 
> The Module Reset Destination bitfields in the MSRES registers are
> 2-bit wide, and control both Reset and Module Standby.  Hence the
> same register bitfields are referred to in the power-domains and
> resets properties, through the module number.
> 
> Module Standby controls the clock(s) going into the module,
> and is modelled as an SCMI clock (SCP_CLOCK_ID_MDLC_*) by the SCP
> firmware. This is very similar to how MSTP (Module Stop) clocks are
> handled on earlier R-Car SoCs (except that the SCP_CLOCK_ID_MDLC_*
> clocks have a zero rate :-(.
> 
> Summarized, the first cell is the power domain part, and the second
> cell is the clock domain part.

Thank you for the clarification.

Since there are up to 32 MPDG registers, and 256 resets, can we encode 
both into a single cell ?

(mpdg_register_offset << 16) | (reset_bit_offset << 0)

I cannot tell whether this is much better, but it at least ties the PD 
components (power domain and clock domain) into a single value, which 
matches reality a bit better. The current split power domain and clock 
domain description in two cells gives me the illusion that it is 
possible to mix and match power domains and clock domains in DT 
description, but in fact the two cells are strongly tied together.

If we cannot encode the two into a single cell, maybe we can at least 
have some sort of macro for this, e.g. this (0xff as no MPDG register 
bits for this block):
#define R8A78000_MDLC_PD_HSCIF0 (0xff << 16) ((0x5 << 4) | (0x3 << 0))

What do you think ?

> So perhaps I will clarify like this:
> 
>        - The first power domain specifier cell is the power domain part, and
>          must be either the Module Power Domain Gating (MPDG) register index

... for power domains which are backed by MDPG bits, and which can be 
controlled in that manner ...

>          (0x00-0x3f) from the datasheet, or a Power Domain number, as defined in
>          <dt-bindings/power/renesas,r8a78000-mdlc.h>,

... for power domains which are always on, and for which there are no 
MPDG bits which can be used to control them ...

>        - The second power domain specifier cell is the clock domain part, and
>          must be the module number (0x00-0xff), composed of the Module System
>          Reset (MSRES) register index in the high nibble, and the Module Reset
>          Destination bitfield index in the low nibble.

I can understand this.

>>> +  '#reset-cells':
>>> +    description:
>>> +      The single reset specifier cell must be the module number (0x00-0xff).
>>> +    const: 1
>>
>> [...]
>>
>>> +#ifndef __DT_BINDINGS_POWER_RENESAS_R8A78000_MDLC_H__
>>> +#define __DT_BINDINGS_POWER_RENESAS_R8A78000_MDLC_H__
>>> +
>>> +/* R-Car X5H MDLC Power Domains */
>>> +
>>> +#define R8A78000_MDLC_PD_AON                 0x40
>>> +#define R8A78000_MDLC_PD_SCP                 0x41
>>> +#define R8A78000_MDLC_PD_APL                 0x42
>>> +#define R8A78000_MDLC_PD_CMN                 0x43
>>> +#define R8A78000_MDLC_PD_ACL                 0x44
>> ... what do these numbers represent ? Shouldn't those be register
>> offsets from MDLC MPDG00 according to power-domain-cells ?
> 
> These are Power Domains that are not backed by any of the 64 Module
> Power Domain Gating (MPDG) registers in MDLC blocks.

I suspect that might not be entirely correct for all of them, please 
read on and see CMN below.

> It is not clear to me if they can be controlled manually, probably
> they are just always sequenced automatically on power-up.  As the
> documentation does treat them as separate domains (see e.g. Table 14.1
> Power Supply Voltage Monitor Functions), I figured they would better be
> exposed as separate domains, instead of as a single always-on domain,
> like on earlier R-Car SoCs (cfr. R8A779*_PD_ALWAYS_ON domains number
> 32 or 64).
> 
> See also the X5H_Power_domain_structure.xlsx attachment in the R-Car
> X5H documentation.

This is indeed helpful piece of documentation, together with X5H_MS, but 
I think the later is still being updated.

Let's take PD_AC00 , AP core 0 , as a domain of interest. My 
understanding is, that the domain structure for PD_AC00 looks as follows:

PD_AON {
   PD_SCP { };
   PD_APL {
     hierarchy is SYSSS
     always-power-on
     PD_CMN {
       hierarchy is CMNN
       power-gating-bit is MDLC_CMNN 20
       PD_APU0 {
         hierarchy is SYSSS
         power-gating is done by APMU
         PD_ACL0 {
           hierarchy is CMNN
           power-gating-bit is MDLC_CMNN 16
           PD_AC00 {
             hierarchy is CMNN
             power-gating-bit is MDLC_CMNN 0
           };
           ...
         };
         ...
       };
       ...
     };
     ...
     PD_HSCIF0 {
       hierarchy is PERW
       power-gating-bit is MDLC_PERW 23
     };
   };
   ...
};

With this in mind, I think CPU 0 DT node should refer to the PD_AC00 
power domain this way:

cpu@0 {
   ...
   power-domains = <&mdlc_cmnn R8A78000_MDLC_PD_AC00>;
   ...
};

The MDLC driver would pass the PD_AC00 domain ID to matching SCMI power 
domain management protocol call, or, for bare-metal MDLC driver, would 
have to internally encode PD hierarchy, walk it, and apply PD operations 
in each step.

I think even for SCIF/HSCIF, the power domain reference should be 
something along the lines of the following description. The MDLC driver 
should internally encode that R8A78000_MLDC_PD_HSCIF0 is a sub-domain of 
R8A78000_MDLC_PD_APL .

serial@c0710000 {
   ...
   power-domains = <&mdlc_perw R8A78000_MDLC_PD_HSCIF0>;
   ...
};

>> If those are power domain IDs, then I am unsure why e.g. for SCIF the
>> domain ID is R8A78000_MDLC_PD_APL in [PATCH/RFC 13/14] arm64: dts:
>> renesas: r8a78000: Add CPG/MDLC nodes . Could you please expand on that ?
> 
> See the "Module Standby" attachment X5H_MS.xlsx in the R-Car X5H
> documentation. The "PERW" tab shows that all PERW devices are located
> in the PD_APL power domain, which is always-on.
> This is different from e.g. the UFS controllers: they are located in
> their own PD_UFS0 and PD_UFS1 power domains, which are controlled
> through the Module Power Domain Gating registers (MPDGn) (cfr. the
> "PERE" tab).
Thank you for this clarification !