[PATCH 1/2] dt-bindings: display: ti,am65x-dss: Add support for common1 region

[Devarsh Thakkar]

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 at ti.com>
>>> ---
>>>   .../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
>