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

Thu Dec 5 07:27:08 UTC 2024

On 04/12/2024 11:11, Michal Wilczynski wrote:
> 
> 
> 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 at 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.

So add resets to GPU. You said here that VO has reset registers, so it
should be a reset controller.

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

No, you miss the point of how device nodes are supposed to look like.
Don't bring your driver architecture here.

You cannot have regmap/syscon if you do not have reg. Your VOSYS is a
clock, reset and whatever-provider. Your power domain - if it does not
have reg - just does not exist. There is no such device and we do not
care if you have such device DRIVER.

> 
> 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 at ffef528050 {
> 	compatible = "thead,th1520-clk-vo";
> 	reg = <0xff 0xef528050 0x0 0x8>;
> 	#clock-cells = <1>;
> };
> 
> pd: power-domain at ffef528000 {
> 	compatible = "thead,th1520-pd";
> 	reg = <0xff 0xef528000 0x0 0x8>;
> 	#power-domain-cells = <1>;
> };

I don't think you really get the point here. Clock controllers and power
domains per one clock or domain are also a no-go.

Best regards,
Krzysztof