On 13/06/2024 11:53, Lad, Prabhakar wrote: > Hi Krzysztof, > > Thank you for the review. > > On Tue, Jun 11, 2024 at 8:02 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: >> >> On 11/06/2024 01:32, Prabhakar wrote: >>> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> >>> >>> Document the device tree bindings for the Renesas RZ/V2H(P) SoC >>> Clock Pulse Generator (CPG). >>> >>> CPG block handles the below operations: >>> - Generation and control of clock signals for the IP modules >>> - Generation and control of resets >>> - Control over booting >>> - Low power consumption and power supply domains >>> >>> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> >> >> Since this is not a finished work (RFC), only limited review follows. >> >> >>> +$id: http://devicetree.org/schemas/clock/renesas,rzv2h-cpg.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: Renesas RZ/V2H(P) Clock Pulse Generator (CPG) >>> + >>> +maintainers: >>> + - Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> >>> + >>> +description: | >> >> Do not need '|' unless you need to preserve formatting. >> > OK. > >>> + On Renesas RZ/V2H(P) SoCs, the CPG (Clock Pulse Generator) handles generation >>> + and control of clock signals for the IP modules, generation and control of resets, >>> + and control over booting, low power consumption and power supply domains. >>> + >>> +properties: >>> + compatible: >>> + const: renesas,r9a09g057-cpg >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + clocks: >>> + maxItems: 1 >>> + >>> + clock-names: >>> + description: >>> + Clock source to CPG on QEXTAL pin. >>> + const: qextal >>> + >>> + '#clock-cells': >>> + description: | >>> + - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" >>> + and a core clock reference, as defined in >>> + <dt-bindings/clock/r9a09g057-cpg.h>, >> >> So second cell is not used? >> > It will be used for blocks using core clocks. > >>> + - For module clocks, the two clock specifier cells must be "CPG_MOD" and >>> + a module number. The module number is calculated as the CLKON register >>> + offset index multiplied by 16, plus the actual bit in the register >>> + used to turn the CLK ON. For example, for CGC_GIC_0_GICCLK, the >>> + calculation is (1 * 16 + 3) = 19. >> >> You should not have different values. Make it const: 1 and just use IDs. >> > Are you suggesting not to differentiate between core/mod clocks. They > are differentiated because the MOD clocks can turned ON/OFF but where > as with the core clocks we cannot turn them ON/OF so the driver needs > to know this, hence two specifiers are used. Every driver knows it... I am really, what is the problem here? Are you saying the drivers create some unknown clocks? Anyway, that's not an argument for bindings. Fix your driver design. Best regards, Krzysztof
