Re: [PATCH/RFC 09/14] dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator

Re: [PATCH/RFC 09/14] dt-bindings: clock: Document Renesas R-Car X5H Clock Pulse Generator

[Marek Vasut]

On 4/21/26 8:11 PM, Geert Uytterhoeven wrote:
> Document support for the Renesas R-Car X5H Clock Pulse Generator,
> and add definitions for a very limited and preliminary set of clocks.
> 
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

I managed to implement U-Boot CPG remap driver based on these bindings, 
and the bindings also fit for U-Boot on RSIP direct hardware access CPG 
driver.

Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Tested-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

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

[Marek Vasut]

On 4/21/26 8:11 PM, Geert Uytterhoeven wrote:

Hello Geert,

> +  '#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 ?

> +  '#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 ?

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 ?

Thank you !

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

[Geert Uytterhoeven]

Hi Marek,

On Thu, 7 May 2026 at 00:58, Marek Vasut <marek.vasut@mailbox.org> 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.

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

> > +  '#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.
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.

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Marek Vasut]

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

Hello Geert,

> On Thu, 7 May 2026 at 00:58, Marek Vasut <marek.vasut@mailbox.org> 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 !

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

[Geert Uytterhoeven]

Hi Marek,

On Thu, 7 May 2026 at 23:36, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 5/7/26 9:37 AM, Geert Uytterhoeven wrote:
> > On Thu, 7 May 2026 at 00:58, Marek Vasut <marek.vasut@mailbox.org> 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)

We could.  I did consider it (with a shift of 8 cfr. 256 modules),
but see below...

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

They are only tied together in the sense that a module (hardware block)
is part of a power domain, and has module standby (clock) control.
Some power domains are backed by MDLC hardware registers,
others are not, hence the need for the additional definitions in
<dt-bindings/power/renesas,r8a78000-mdlc.h>.
I am not aware (yet) of modules that are part of a power domain,
but do not have module standby control. If these exist, we
need an additional definition (R8A78000_MDLC_MODULE_NONE?) in
<dt-bindings/power/renesas,r8a78000-mdlc.h>.

Due to this separation, and due to a possible future need for expansion
(R8A78000_MDLC_MODULE_NONE, MDLCs with more than 256 modules, ...),
I went for two cells.

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

I (and I believe the DT maintainers) are not so fond of defines for
numbers that can be (more or less) just read from the documentation.
(and 0xff should be R8A78000_MDLC_PD_APL?)

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

OK.

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

OK,

>
> >        - The second power domain specifier cell is the clock domain part, and

Upon second thought: s/clock domain/module standby/

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

Thanks, looks like R8A78000_MDLC_PD_CMN should be dropped.

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

So we do have a few modules (I found a few more) that are part of
power domains, but do no support module standby.  One more reason to
decouple them in power-domains.

However, CPU cores are controlled through PSCI (the slightly less evil
brother of SCMI? ;-), so
Documentation/devicetree/bindings/arm/psci.yaml applies, too?

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

R8A78000_MLDC_PD_HSCIF0 is a not a full sub-domain, but merely standby
(clock) control inside the PD_APL clock domain?


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Marek Vasut]

On 5/8/26 10:26 AM, Geert Uytterhoeven wrote:

Hello Geert,

>> 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)
> 
> We could.  I did consider it (with a shift of 8 cfr. 256 modules),
> but see below...
> 
>> 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.
> 
> They are only tied together in the sense that a module (hardware block)
> is part of a power domain, and has module standby (clock) control.
> Some power domains are backed by MDLC hardware registers,
> others are not, hence the need for the additional definitions in
> <dt-bindings/power/renesas,r8a78000-mdlc.h>.
> I am not aware (yet) of modules that are part of a power domain,
> but do not have module standby control. If these exist, we
> need an additional definition (R8A78000_MDLC_MODULE_NONE?) in
> <dt-bindings/power/renesas,r8a78000-mdlc.h>.

Maybe TAUJ3 in AON domain? I think HSCN also has abundance of examples.

> Due to this separation, and due to a possible future need for expansion
> (R8A78000_MDLC_MODULE_NONE, MDLCs with more than 256 modules, ...),
> I went for two cells.

I think I won't push for a single cell either, two cells are OK with me too.

>> 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 ?
> 
> I (and I believe the DT maintainers) are not so fond of defines for
> numbers that can be (more or less) just read from the documentation.

OK

> (and 0xff should be R8A78000_MDLC_PD_APL?)

I think AON would have to be 0xff , since it is superdomain of APL ?

>>> 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 ...
> 
> OK.
> 
>>>           (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 ...
> 
> OK,
> 
>>
>>>         - The second power domain specifier cell is the clock domain part, and
> 
> Upon second thought: s/clock domain/module standby/

If you could even mention that this refers to "Module STOP" column bit, 
that would even clearer.

>>>           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.
> 
> Thanks, looks like R8A78000_MDLC_PD_CMN should be dropped.
> 
>> 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>;
>>     ...
>> };
> 
> So we do have a few modules (I found a few more) that are part of
> power domains, but do no support module standby.  One more reason to
> decouple them in power-domains.

I think HSCN is a really good example ?

> However, CPU cores are controlled through PSCI (the slightly less evil
> brother of SCMI? ;-), so
> Documentation/devicetree/bindings/arm/psci.yaml applies, too?

We can indeed control cores purely via PSCI , yes.

(Upstream TFA needs one more platform patch to make this operable)

>> 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>;
>>     ...
>> };
> 
> R8A78000_MLDC_PD_HSCIF0 is a not a full sub-domain, but merely standby
> (clock) control inside the PD_APL clock domain?
Do you consider R8A78000_MDLC_PD_AC00 a full sub-domain ? Because that 
one looks very similar to R8A78000_MDLC_PD_HSCIF0 , except the former 
controls a core, the later an UART IP.

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

[Marek Vasut]

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, or a Power Domain number, as defined in
> +        <dt-bindings/power/renesas,r8a78000-mdlc.h>,
> +      - 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
> +
> +  '#reset-cells':
> +    description:
> +      The single reset specifier cell must be the module number (0x00-0xff).
> +    const: 1
Just one more question -- the power-domain-cells second cell and 
reset-cells are always going to be identical values, correct ? If so, it 
would be nice to keep the description: aligned, and maybe even indicate 
in the description that those two values have to be the same.

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

[Geert Uytterhoeven]

Hi Marek,

On Thu, 7 May 2026 at 23:53, Marek Vasut <marek.vasut@mailbox.org> 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, or a Power Domain number, as defined in
> > +        <dt-bindings/power/renesas,r8a78000-mdlc.h>,
> > +      - 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
> > +
> > +  '#reset-cells':
> > +    description:
> > +      The single reset specifier cell must be the module number (0x00-0xff).
> > +    const: 1
> Just one more question -- the power-domain-cells second cell and
> reset-cells are always going to be identical values, correct ? If so, it

Yes they are.

> would be nice to keep the description: aligned, and maybe even indicate
> in the description that those two values have to be the same.

I thought that was obvious (but apparently it is not)? The descriptions
are identical, except for the latter not explaining again what a module
number is composed of...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Marek Vasut]

On 5/8/26 9:47 AM, Geert Uytterhoeven wrote:

Hello Geert,

> On Thu, 7 May 2026 at 23:53, Marek Vasut <marek.vasut@mailbox.org> 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, or a Power Domain number, as defined in
>>> +        <dt-bindings/power/renesas,r8a78000-mdlc.h>,
>>> +      - 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
>>> +
>>> +  '#reset-cells':
>>> +    description:
>>> +      The single reset specifier cell must be the module number (0x00-0xff).
>>> +    const: 1
>> Just one more question -- the power-domain-cells second cell and
>> reset-cells are always going to be identical values, correct ? If so, it
> 
> Yes they are.
> 
>> would be nice to keep the description: aligned, and maybe even indicate
>> in the description that those two values have to be the same.
> 
> I thought that was obvious (but apparently it is not)? The descriptions
> are identical, except for the latter not explaining again what a module
> number is composed of...

Please do spell it out in the document, this is a complicated topic and 
every little bit of extra clarity helps.

Thank you !
-- 
Best regards,
Marek Vasut

Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()

[Geert Uytterhoeven]

Hi Cristian,

On Mon, 27 Apr 2026 at 01:03, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > On Tue, Apr 21, 2026 at 08:11:38PM +0200, Geert Uytterhoeven wrote:
> > > > Currently non-SCMI drivers cannot find out what the specific versions of
> > > > each SCMI provider implementation on the running system are.
> > >
> > > Thanks for your patches....this is not a proper full review of the series,
> > > BUT this patch catched my eye..
> > >
> > > Indeed, yes, it is deliberate that the SCMI version information is NOT
> > > exposed out of the SCMI world, since being the SCMI an attempt to
> > > standardize a common FW interface (as in [1] of course), you should not
> > > know what runs inside the black-box, it should be irrelevant...
> > >
> > > ...indeed the versioning is used inside the SCMI stack to deal properly
> > > with different protocol versions implemented by the server OR to apply
> > > proper quirks when needed, but all the rest should be standard....
> > >
> > > ...you should NOT really behave differently based on the underneath
> > > protocol or firmare implementation version...it is the SCMI stack that
> > > should behave properly, transparently...
> >
> > Oh well...
> >
> > > Having said that...I understand that at least it could be useful to be able
> > > to query the SCMI stack to know, even from non-SCMI drivers, WHICH quirks
> > > have been applied/activated at run time...but anything more than that it
> >
> > I see no need for that, but we can discover which quirks have been
> > applied from the kernel log ;-)
>
> Ok so I may have misunderstood...it seemed to me, glancing through the
> series that you wanted sort of reconfigure other non-SCMI drivers based
> on the SCMI FW version assuming that some quirks were applied BUT also
> that some sort of corrective workaround was needed additionally...so
> what I was saying was that: is not more straightforward to be possibly
> able to check if a quirk has been applied instead of querying the
> version from outside ?

I am not sure I can implement everything as quirks...
Also, as quirks.h lives under drivers/firmware/arm_scmi/, accessing
quirks.h elsewhere requires a relative include path.

> > > Also because this should be one of the selling point of the SCMI stack
> > > in a virtualized environment: you can ship the same kernel drivers with
> > > the same DT and you know that ID=<N> will always identify the specific
> > > resource that is needed by your driver without worrying about the fact
> > > that in reality in the backstage the effectively managed physical resource
> > > could be different across different platforms, because that does not matter
> >
> > This sounds strange to me, do I understand it correctly?
> > So the ID should (1) be tied to the use-case, and not to the underlying
> > hardware, and (2) be the same for different platforms?
> >
> > For (1): Then we must not put these IDs in DT at all, as DT is supposed
> >     to describe the hardware (and firmware IDs in DT were IMHO already
> >     a stretch before).
> > For (2): How can there be a contiguous list of IDs, as not all platforms
> >     may have the same underlying hardware?
>
> I would NOT say that an SCMI FW must behave like this regarding IDs, but it
> is a possible SCMI deployed setup that can be useful in virtualized setups
>
> I mean, the DT describes the hardware of course BUT when you refer to
> some of this hardware DT bits from some other subsystem by referencing a
> phandle, even in the non-SCMI world, you are in fact selecting a specific
> resource that fit you use case, right ? Can we say this ?
> I mean you needed that specific clock or regulator that you described
> previously so as to be able to enable some other piece of HW...

OK.

> Now, the SCMI provides an abstraction on top of this, since you really
> discover domain IDs of a specific class (clocks/regulators etc) you are
> in fact describing an HW abstraction that you then refer with the usual
> phandle...also because there is NOT so much SCMI hardware to describe,
> given that the HW is handled transparently (opaquely really :P) by the
> driver on the FW side...
>
> ...you basically obtain such domain ID, usable as phandles through dynamic
> SCMI enumeration so that you can use it all over your DT to make use of such
> resources...
>
> ...on top of this, consider that the SCMI server CAN provide to its agents
> a per-agent-view of the world, IOW it can (and should) expose to a specific
> agent ONLY the resources needed by that agent, i.e. it can expose the set
> of resources 1-N to two distinct agents and that does NOT mean that the
> underlying physical resource mapped by ID=3 in both agents has to be
> effectively the same piece of hardware: it could be the case, and this
> would be useful to exposed and managed properly a shared resource, or
> it could also be that the same ID=3 could refer to completely distinct
> pieces of the same class of hardware...(same protocol same class of
> resource...)
>
> In fact the SCMI server provides an abstraction, sometime a mere illusion
> to the agents...
>
> So in a virtualized ennvironment you could expose the same ID to a pair
> of distinct agents on distinct VMs, so that you can use the same driver
> and same DT despite the fact that maybe the underlying resources are
> distinct pieces of hardware ...

I am not sure how this can actually work.  Many clock, reset, and
power domain resources cannot just be remapped to different hardware,
as they are related to other hardware resources described in DT,
which are not handled by SCMI.

Take for example a serial port:

    serial@c0714000 {
            compatible = "vendor,serial"'
            reg = <0 0xc0714000 0 0x60>;
            interrupts = <GIC_ESPI 15 IRQ_TYPE_LEVEL_HIGH>;
            clocks = <&scmi_clk 42>, <&scmi_clk 43>, <&scif_clk>;
            clock-names = "fck", "brg_int", "scif_clk";
            dmas = <&dmac1 0x33>, <&dmac1 0x32>;
            dma-names = "tx", "rx";
            power-domains = <&scmi_pd 44>;
            resets = <&scmi_reset 45>;
            status = "disabled";
    };

The clock, power-domain, and reset cannot be remapped to a different
serial port instance, as they are tied intimately to this specific
instance at MMIO address 0xc0714000, which is wired to a specific ESPI
interrupt and to specific DMA controller channels.

> ...OR on the other side you could decide to share the same resource with
> different agents (say a clock) and take care, as a server, of armonizing
> conflicting requests from different agents (e.g. by refcounting enable/disable
> across all agents), WITHOUT necessarily need to expose that same resource
> with the same ID to both agents...

E.g. preventing the inadvertent disabling of shared resources like
shared parent clocks I can agree with.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()

[Geert Uytterhoeven]

Hi Cristian,

On Mon, 27 Apr 2026 at 01:03, Cristian Marussi <cristian.marussi@arm.com> wrote:
> On Fri, Apr 24, 2026 at 02:08:55PM +0200, Geert Uytterhoeven wrote:
> > On Wed, 22 Apr 2026 at 20:45, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > Also because this should be one of the selling point of the SCMI stack
> > > in a virtualized environment: you can ship the same kernel drivers with
> > > the same DT and you know that ID=<N> will always identify the specific
> > > resource that is needed by your driver without worrying about the fact
> > > that in reality in the backstage the effectively managed physical resource
> > > could be different across different platforms, because that does not matter
> >
> > This sounds strange to me, do I understand it correctly?
> > So the ID should (1) be tied to the use-case, and not to the underlying
> > hardware, and (2) be the same for different platforms?
> >
> > For (1): Then we must not put these IDs in DT at all, as DT is supposed
> >     to describe the hardware (and firmware IDs in DT were IMHO already
> >     a stretch before).
> > For (2): How can there be a contiguous list of IDs, as not all platforms
> >     may have the same underlying hardware?
>
> I would NOT say that an SCMI FW must behave like this regarding IDs, but it
> is a possible SCMI deployed setup that can be useful in virtualized setups
>
> I mean, the DT describes the hardware of course BUT when you refer to
> some of this hardware DT bits from some other subsystem by referencing a
> phandle, even in the non-SCMI world, you are in fact selecting a specific
> resource that fit you use case, right ? Can we say this ?
> I mean you needed that specific clock or regulator that you described
> previously so as to be able to enable some other piece of HW...
>
> Now, the SCMI provides an abstraction on top of this, since you really
> discover domain IDs of a specific class (clocks/regulators etc) you are
> in fact describing an HW abstraction that you then refer with the usual
> phandle...also because there is NOT so much SCMI hardware to describe,
> given that the HW is handled transparently (opaquely really :P) by the
> driver on the FW side...
>
> ...you basically obtain such domain ID, usable as phandles through dynamic
> SCMI enumeration so that you can use it all over your DT to make use of such
> resources...
>
> ...on top of this, consider that the SCMI server CAN provide to its agents
> a per-agent-view of the world, IOW it can (and should) expose to a specific
> agent ONLY the resources needed by that agent, i.e. it can expose the set
> of resources 1-N to two distinct agents and that does NOT mean that the
> underlying physical resource mapped by ID=3 in both agents has to be
> effectively the same piece of hardware: it could be the case, and this
> would be useful to exposed and managed properly a shared resource, or
> it could also be that the same ID=3 could refer to completely distinct
> pieces of the same class of hardware...(same protocol same class of
> resource...)

Exposing only the clocks/reset/power domains the agent can use,
in a contiguous list of IDS, means that the number space changes,
depending on which resources are exposed.

Suppose you have a system where you want to assign a specific hardware
block in the SoC to the realtime CPU core instead of the application
CPU core running Linux.
That means all resources used by that block must no longer be exposed
to the Linux agent, and the corresponding IDs must be removed from
the ID space exposed to Linux.  As the ID space must be sequential
and contiguous, the IDs must be renumbered, impacting resources that
are exposed to Linux.  As these IDs are used in the SoC .dtsi, they
must be changed there, too, However, these IDs have become part of
the stable DT ABI, and thus cannot be changed.

This patch series fixes that issue, too, by describing the actual
hardware in DT, and doing the mapping to exposed SCMI features in the
kernel, based on which firmware version is running on the SCP.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds