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 <[email protected]> >>>> --- >>>> .../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
