Re: [PATCH 1/9] dt-bindings: display: vop2: Add missing reset properties

[Cristian Ciocaltea <cristian.ciocaltea@collabora.com>]

On 7/3/26 7:37 PM, Heiko Stübner wrote:
> Am Donnerstag, 18. Juni 2026, 10:39:14 Mitteleuropäische Sommerzeit schrieb Cristian Ciocaltea:
>> Hi Diederik,
>>
>> On 6/18/26 10:58 AM, Diederik de Haas wrote:
>>> Hi Cristian,
>>>
>>> Thanks for this series :-) Just 1 nit (at the end) ...
>>>
>>> On Wed Jun 17, 2026 at 8:52 PM CEST, Cristian Ciocaltea wrote:
>>>> Document the VOP2 resets corresponding to the AXI, AHB and DCLK_VP0..2
>>>> clocks, which are common to all supported SoCs, plus DCLK_VP3 which is
>>>> provided only on RK3588.
>>>>
>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>>> ---
>>>>  .../bindings/display/rockchip/rockchip-vop2.yaml   | 42 ++++++++++++++++++++++
>>>>  1 file changed, 42 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
>>>> index 93da1fb9adc4..d3bc5380f910 100644
>>>> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
>>>> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
>> [...]
>>
>>>> @@ -289,6 +321,16 @@ examples:
>>>>                                "dclk_vp0",
>>>>                                "dclk_vp1",
>>>>                                "dclk_vp2";
>>>> +                resets = <&cru SRST_A_VOP>,
>>>> +                         <&cru SRST_H_VOP>,
>>>> +                         <&cru SRST_VOP0>,
>>>> +                         <&cru SRST_VOP1>,
>>>> +                         <&cru SRST_VOP2>;
>>>> +                reset-names = "axi",
>>>> +                              "ahb",
>>>> +                              "dclk_vp0",
>>>> +                              "dclk_vp1",
>>>> +                              "dclk_vp2";
>>>>                  power-domains = <&power RK3568_PD_VO>;
>>>
>>> Place reset* props below power-domains (like in patch 9) ?
>>> So everyone who copies your example has the correct sorting order.
>>
>> The example doesn't strictly follow that ordering either — see e.g. the iommus
>> property — so I placed the resets right after the clocks, which keeps the
>> related properties grouped together.
>>
>> That said, I don't have a strong preference. 
>>
>> Heiko, is there a convention you'd like the Rockchip bindings to follow here?
>> Happy to reorder if so.
> 
> Please just use standard devicetree ordering, as described in the
> documentation. We generally don't want to invent new diverging things :-)

Ack. For consistency, let's also move the iommus property up into the expected
position.

Thanks,
Cristian