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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <9314a841-d983-0254-c30a-4500864d0a1b@ti.com>
Date: Wed, 14 Feb 2024 16:53:07 +0530
From: Devarsh Thakkar <devarsht@...com>
To: Tomi Valkeinen <tomi.valkeinen@...asonboard.com>, <conor+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <robh+dt@...nel.org>,
        "Raghavendra,
 Vignesh" <vigneshr@...com>
CC: <praneeth@...com>, <nm@...com>, <vigneshr@...com>, <a-bhatia1@...com>,
        <j-luthra@...com>, <kristo@...nel.org>, <jyri.sarha@....fi>,
        <airlied@...il.com>, <daniel@...ll.ch>,
        <maarten.lankhorst@...ux.intel.com>, <mripard@...nel.org>,
        <tzimmermann@...e.de>, <dri-devel@...ts.freedesktop.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devarsht@...com>
Subject: Re: [PATCH 1/2] dt-bindings: display: ti,am65x-dss: Add support for
 common1 region

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