lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e170f5f8-f95c-4553-b088-1072345fae53@tuxon.dev>
Date: Thu, 8 Feb 2024 18:53:06 +0200
From: claudiu beznea <claudiu.beznea@...on.dev>
To: Biju Das <biju.das.jz@...renesas.com>,
 "geert+renesas@...der.be" <geert+renesas@...der.be>,
 "mturquette@...libre.com" <mturquette@...libre.com>,
 "sboyd@...nel.org" <sboyd@...nel.org>, "robh@...nel.org" <robh@...nel.org>,
 "krzysztof.kozlowski+dt@...aro.org" <krzysztof.kozlowski+dt@...aro.org>,
 "conor+dt@...nel.org" <conor+dt@...nel.org>,
 "magnus.damm@...il.com" <magnus.damm@...il.com>,
 "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
 "palmer@...belt.com" <palmer@...belt.com>,
 "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>
Cc: "linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
 "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
 Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH 01/17] dt-bindings: clock: r9a07g043-cpg: Add power domain
 IDs



On 08.02.2024 18:28, Biju Das wrote:
> 
> 
>> -----Original Message-----
>> From: claudiu beznea <claudiu.beznea@...on.dev>
>> Sent: Thursday, February 8, 2024 3:46 PM
>> Subject: Re: [PATCH 01/17] dt-bindings: clock: r9a07g043-cpg: Add power
>> domain IDs
>>
>> Hi, Biju,
>>
>> On 08.02.2024 16:30, Biju Das wrote:
>>> Hi Claudiu,
>>>
>>> Thanks for the patch.
>>>
>>>> -----Original Message-----
>>>> From: Claudiu <claudiu.beznea@...on.dev>
>>>> Sent: Thursday, February 8, 2024 12:43 PM
>>>> Subject: [PATCH 01/17] dt-bindings: clock: r9a07g043-cpg: Add power
>>>> domain IDs
>>>>
>>>> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>>>
>>>> Add power domain IDs for RZ/G2UL (R9A07G043) SoC.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
>>>> ---
>>>>  include/dt-bindings/clock/r9a07g043-cpg.h | 48
>>>> +++++++++++++++++++++++
>>>>  1 file changed, 48 insertions(+)
>>>>
>>>> diff --git a/include/dt-bindings/clock/r9a07g043-cpg.h b/include/dt-
>>>> bindings/clock/r9a07g043-cpg.h index 77cde8effdc7..eabfeec7ac37
>>>> 100644
>>>> --- a/include/dt-bindings/clock/r9a07g043-cpg.h
>>>> +++ b/include/dt-bindings/clock/r9a07g043-cpg.h
>>>> @@ -200,5 +200,53 @@
>>>>  #define R9A07G043_AX45MP_CORE0_RESETN	78	/* RZ/Five Only */
>>>>  #define R9A07G043_IAX45_RESETN		79	/* RZ/Five Only */
>>>>
>>>> +/* Power domain IDs. */
>>>> +#define R9A07G043_PD_ALWAYS_ON		0
>>>> +#define R9A07G043_PD_GIC		1
>>>> +#define R9A07G043_PD_IA55		2
>>>> +#define R9A07G043_PD_MHU		3
>>>> +#define R9A07G043_PD_CORESIGHT		4
>>>> +#define R9A07G043_PD_SYC		5
>>>> +#define R9A07G043_PD_DMAC		6
>>>> +#define R9A07G043_PD_GTM0		7
>>>> +#define R9A07G043_PD_GTM1		8
>>>> +#define R9A07G043_PD_GTM2		9
>>>> +#define R9A07G043_PD_MTU		10
>>>> +#define R9A07G043_PD_POE3		11
>>>> +#define R9A07G043_PD_WDT0		12
>>>> +#define R9A07G043_PD_SPI		13
>>>> +#define R9A07G043_PD_SDHI0		14
>>>> +#define R9A07G043_PD_SDHI1		15
>>>> +#define R9A07G043_PD_ISU		16
>>>> +#define R9A07G043_PD_CRU		17
>>>> +#define R9A07G043_PD_LCDC		18
>>>> +#define R9A07G043_PD_SSI0		19
>>>> +#define R9A07G043_PD_SSI1		20
>>>> +#define R9A07G043_PD_SSI2		21
>>>> +#define R9A07G043_PD_SSI3		22
>>>> +#define R9A07G043_PD_SRC		23
>>>> +#define R9A07G043_PD_USB0		24
>>>> +#define R9A07G043_PD_USB1		25
>>>> +#define R9A07G043_PD_USB_PHY		26
>>>> +#define R9A07G043_PD_ETHER0		27
>>>> +#define R9A07G043_PD_ETHER1		28
>>>> +#define R9A07G043_PD_I2C0		29
>>>> +#define R9A07G043_PD_I2C1		30
>>>> +#define R9A07G043_PD_I2C2		31
>>>> +#define R9A07G043_PD_I2C3		32
>>>> +#define R9A07G043_PD_SCIF0		33
>>>> +#define R9A07G043_PD_SCIF1		34
>>>> +#define R9A07G043_PD_SCIF2		35
>>>> +#define R9A07G043_PD_SCIF3		36
>>>> +#define R9A07G043_PD_SCIF4		37
>>>> +#define R9A07G043_PD_SCI0		38
>>>> +#define R9A07G043_PD_SCI1		39
>>>> +#define R9A07G043_PD_IRDA		40
>>>> +#define R9A07G043_PD_RSPI0		41
>>>> +#define R9A07G043_PD_RSPI1		42
>>>> +#define R9A07G043_PD_RSPI2		43
>>>> +#define R9A07G043_PD_CANFD		44
>>>> +#define R9A07G043_PD_ADC		45
>>>> +#define R9A07G043_PD_TSU		46
>>>
>>> Not sure from "Table 42.3 Registers for Module Standby Mode"
>>>
>>> Power domain ID has to be based on CPG_BUS_***_MSTOP or CPG_CLKON_***
>>> As former reduces number of IDs??
>>
>> If I understand correctly your point here, you want me to describe PM
>> domain in DT with something like:
>>
>> power-domains = <&cpg CPG_BUS_X_MSTOP>;
> 
> MSTOP bits are distinct for each IP.
> 
> <&cpg CPG_BUS_MCPU1_MSTOP x>; x =1..9
> 
> 2=MTU IP
> 
> 4= GPT
> 
> etc...
> 
> Is it something work??

It might work. But:

- you have to consider that some IPs have more than one MSTOP bit, thus, do
  we want to uniquely identify these with all MSTOP bits (thus the 2nd cell
  being a bitmask) or only one is enough?
- some HW blocks (e.g. OTFDE_DDR) have no MSTOP bits associated (as of my
  current research), so, only PWRDN
- some HW blocks have both MSTOP and PWRDN
- if future hardware implementation will spread the MSTOP bits for one IP
  to more than one register then this proposal will not work

Having a unique identified decoupled from MSTOP registers or PWRDN offers
support to use the same code base for future usage. This is what I can tell
at the moment.

> 
>>
>> where X={ACPU, PERI_CPU, PERI_CPU2, REG0, REG1} ?
>>
>> With this, I still see the necessity of a 3rd identifier that will be IP
>> specific to be able to uniquely match b/w DT description and registered
>> power domain. FMPOV, this will lead to a more complicated implementation.
>>
>> We need a unique ID that the pm domain xlate will use to xlate the DT
>> binding to driver data structures.
> 
> Ok.
> 
> Cheers,
> Biju
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ