Hi Tomi, Vignesh, On 14/02/24 14:53, Tomi Valkeinen wrote: > On 14/02/2024 11:10, Tomi Valkeinen wrote: >> Hi, >> >> On 15/01/2024 14:57, Devarsh Thakkar wrote: >>> TI keystone display subsystem present in AM65 and other SoCs such as AM62 >>> support two separate register spaces namely "common" and "common1" which >>> can be used by two separate hosts to program the display controller as >>> described in respective Technical Reference Manuals [1]. >>> >>> The common1 register space has similar set of configuration registers as >>> supported in common register space except the global configuration >>> registers which are exclusive to common region. >>> >>> This adds binding for "common1" register region too as supported by the >>> hardware. >>> >>> [1]: >>> AM62x TRM: >>> https://www.ti.com/lit/pdf/spruiv7 (Section 14.8.9.1 DSS Registers) >>> >>> AM65x TRM: >>> https://www.ti.com/lit/pdf/spruid7 (Section 12.6.5 DSS Registers) >>> >>> Signed-off-by: Devarsh Thakkar <devarsht@xxxxxx> >>> --- >>> .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 7 +++++-- >>> 1 file changed, 5 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >>> b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >>> index b6767ef0d24d..55e3e490d0e6 100644 >>> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >>> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml >>> @@ -37,6 +37,7 @@ properties: >>> - description: OVR2 overlay manager for vp2 >>> - description: VP1 video port 1 >>> - description: VP2 video port 2 >>> + - description: common1 DSS register area >>> reg-names: >>> items: >>> @@ -47,6 +48,7 @@ properties: >>> - const: ovr2 >>> - const: vp1 >>> - const: vp2 >>> + - const: common1 >>> clocks: >>> items: >>> @@ -147,9 +149,10 @@ examples: >>> <0x04a07000 0x1000>, /* ovr1 */ >>> <0x04a08000 0x1000>, /* ovr2 */ >>> <0x04a0a000 0x1000>, /* vp1 */ >>> - <0x04a0b000 0x1000>; /* vp2 */ >>> + <0x04a0b000 0x1000>, /* vp2 */ >>> + <0x04a01000 0x1000>; /* common1 */ >>> reg-names = "common", "vidl1", "vid", >>> - "ovr1", "ovr2", "vp1", "vp2"; >>> + "ovr1", "ovr2", "vp1", "vp2", "common1"; >>> ti,am65x-oldi-io-ctrl = <&dss_oldi_io_ctrl>; >>> power-domains = <&k3_pds 67 TI_SCI_PD_EXCLUSIVE>; >>> clocks = <&k3_clks 67 1>, >> >> Looks fine to me, I'll apply to drm-misc-next. > > Hmm, now thinking about this, doesn't this cause dtb checks to start failing, > as the dtbs are missing one entry? Is it better to merge these kind of changes > with the dts changes? Or does it matter? > Yes if one get's applied and other doesn't then there will be such issues. I am sending shortly both the dt-binding and device-tree patches together, as long as both look fine and ready to be accepted by respective maintainers, I think both can get merged to respective trees and land in linux-next without causing any issues. Regards Devarsh > Tomi >
