Re: [RFC PATCH v1 05/14] dt-bindings: clock: thead,th1520: Add support for Video Output subsystem

[Michal Wilczynski <m.wilczynski@samsung.com>]

On 12/3/24 16:45, Krzysztof Kozlowski wrote:
> On 03/12/2024 14:41, Michal Wilczynski wrote:
>> The device tree bindings for the T-Head TH1520 SoC clocks currently
>> support only the Application Processor (AP) subsystem. This commit
>> extends the bindings to include the Video Output (VO) subsystem clocks.
>>
>> Update the YAML schema to define the VO subsystem clocks, allowing the
>> clock driver to configure and manage these clocks appropriately. This
>> addition is necessary to enable the proper operation of the video output
>> features on the TH1520 SoC.
>>
>> Signed-off-by: Michal Wilczynski <m.wilczynski@samsung.com>
>> ---
>>  .../bindings/clock/thead,th1520-clk-ap.yaml   | 31 +++++++++++++++----
>>  1 file changed, 25 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml
>> index 4a0806af2bf9..5a8f1041f766 100644
>> --- a/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml
>> +++ b/Documentation/devicetree/bindings/clock/thead,th1520-clk-ap.yaml
>> @@ -4,11 +4,13 @@
>>  $id: https://protect2.fireeye.com/v1/url?k=f595e769-941ef222-f5946c26-74fe485fb305-6d0b73471bbfc1a2&q=1&e=6b918e4d-d81f-4b44-8516-776d7b4f9dae&u=http%3A%2F%2Fdevicetree.org%2Fschemas%2Fclock%2Fthead%2Cth1520-clk-ap.yaml%23
>>  $schema: https://protect2.fireeye.com/v1/url?k=5b94114b-3a1f0400-5b959a04-74fe485fb305-0e2c50f5c24cf3e9&q=1&e=6b918e4d-d81f-4b44-8516-776d7b4f9dae&u=http%3A%2F%2Fdevicetree.org%2Fmeta-schemas%2Fcore.yaml%23
>>  
>> -title: T-HEAD TH1520 AP sub-system clock controller
>> +title: T-HEAD TH1520 sub-systems clock controller
>>  
>>  description: |
>> -  The T-HEAD TH1520 AP sub-system clock controller configures the
>> -  CPU, DPU, GMAC and TEE PLLs.
>> +  The T-HEAD TH1520 sub-systems clock controller configures the
>> +  CPU, DPU, GMAC and TEE PLLs for the AP subsystem. For the VO
>> +  subsystem clock gates can be configured for the HDMI, MIPI and
>> +  the GPU.
>>  
>>    SoC reference manual
>>    https://protect2.fireeye.com/v1/url?k=cceb6120-ad60746b-cceaea6f-74fe485fb305-b294b70f1b52a5ab&q=1&e=6b918e4d-d81f-4b44-8516-776d7b4f9dae&u=https%3A%2F%2Fopenbeagle.org%2Fbeaglev-ahead%2Fbeaglev-ahead%2F-%2Fblob%2Fmain%2Fdocs%2FTH1520%2520System%2520User%2520Manual.pdf
>> @@ -20,7 +22,9 @@ maintainers:
>>  
>>  properties:
>>    compatible:
>> -    const: thead,th1520-clk-ap
>> +    enum:
>> +      - thead,th1520-clk-ap
>> +      - thead,th1520-clk-vo
>>  
>>    reg:
>>      maxItems: 1
>> @@ -29,6 +33,17 @@ properties:
>>      items:
>>        - description: main oscillator (24MHz)
>>  
>> +  thead,vosys-regmap:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description: |
>> +      Phandle to a syscon node representing the shared register
>> +      space of the VO (Video Output) subsystem. This register space
>> +      includes both clock control registers and other control
>> +      registers used for operations like resetting the GPU. Since
> 
> 
> It seems you wanted to implement reset controller...

Thank you for your feedback.

I understand your concern about the reset controller. In the TH1520 SoC,
the GPU doesn't have its own reset controller. Instead, its reset is
managed through the power domain's registers as part of the power-up
sequence.

According to the Video Image Processing Manual 1.4.1 [1], the GPU
requires the following steps to power up:

1) Enable the GPU clock gate.
2) After 32 core clock cycles, release the GPU soft reset

Since these steps are closely tied to power management, I implemented
the reset functionality within the power-domain driver.

Because the GPU doesn't support the resets property, introducing a reset
controller wouldn't align with the existing device tree well.

[1] - https://openbeagle.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20Video%20Image%20Processing%20User%20Manual.pdf
> 
>> +      these registers reside in the same address space, access to
>> +      them is coordinated through a shared syscon regmap provided by
>> +      the specified syscon node.
> 
> Drop last sentence. syscon regmap is a Linux term, not hardware one.
> 
> Anyway, this needs to be constrained per variant.
> 
>> +
>>    "#clock-cells":
>>      const: 1
>>      description:
>> @@ -36,8 +51,6 @@ properties:
>>  
>>  required:
>>    - compatible
>> -  - reg
> 
> No, that's a clear NAK. You claim you have no address space but in the
> same time you have address space via regmap.

I see your concern. The VOSYS subsystem's address space includes
registers for various components, such as clock gates and reset
controls, which are scattered throughout the address space as specified
in the manual 4.4.1 [2]. Initially, I attempted to use a shared syscon
regmap for access, but I realize this might not be the best approach.

To address this, I'll specify the 'reg' property in each node to define
the address ranges explicitly fragmenting the address space for the VOSYS
manually.

vosys_clk: clock-controller@ffef528050 {
	compatible = "thead,th1520-clk-vo";
	reg = <0xff 0xef528050 0x0 0x8>;
	#clock-cells = <1>;
};

pd: power-domain@ffef528000 {
	compatible = "thead,th1520-pd";
	reg = <0xff 0xef528000 0x0 0x8>;
	#power-domain-cells = <1>;
};

I would be happy to proceed like this if that's okay.

[2] - https://openbeagle.org/beaglev-ahead/beaglev-ahead/-/blob/main/docs/TH1520%20System%20User%20Manual.pdf

> 
>> -  - clocks
> 
> Nope, not explained, unless you wanted to make it different per variants.
> 
>>    - "#clock-cells"
>>  
>>  additionalProperties: false
>> @@ -51,3 +64,9 @@ examples:
>>          clocks = <&osc>;
>>          #clock-cells = <1>;
>>      };
>> +
>> +    clock-controller-vo {
> 
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://protect2.fireeye.com/v1/url?k=1e9cac96-7f17b9dd-1e9d27d9-74fe485fb305-f0538482114df941&q=1&e=6b918e4d-d81f-4b44-8516-776d7b4f9dae&u=https%3A%2F%2Fdevicetree-specification.readthedocs.io%2Fen%2Flatest%2Fchapter2-devicetree-basics.html%23generic-names-recommendation
> 
> 
>> +        compatible = "thead,th1520-clk-vo";
>> +        thead,vosys-regmap = <&vosys_regmap>;
> 
> That's a "reg" property. Do not encode address space as something else.
> 
> 
>> +        #clock-cells = <1>;
>> +    };
> 
> 
> Best regards,
> Krzysztof
> 

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv