Received-SPF: pass (google.com: domain of linux-kernel+bounces-65120-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <9314a841-d983-0254-c30a-4500864d0a1b@ti.com>
Date: Wed, 14 Feb 2024 16:53:07 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH 1/2] dt-bindings: display: ti,am65x-dss: Add support for
 common1 region
Content-Language: en-US
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>, <conor+dt@kernel.org>,
        <krzysztof.kozlowski+dt@linaro.org>, <robh+dt@kernel.org>,
        "Raghavendra,
 Vignesh" <vigneshr@ti.com>
CC: <praneeth@ti.com>, <nm@ti.com>, <vigneshr@ti.com>, <a-bhatia1@ti.com>,
        <j-luthra@ti.com>, <kristo@kernel.org>, <jyri.sarha@iki.fi>,
        <airlied@gmail.com>, <daniel@ffwll.ch>,
        <maarten.lankhorst@linux.intel.com>, <mripard@kernel.org>,
        <tzimmermann@suse.de>, <dri-devel@lists.freedesktop.org>,
        <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <devarsht@ti.com>
References: <20240115125716.560363-1-devarsht@ti.com>
 <20240115125716.560363-2-devarsht@ti.com>
 <f8cc383e-1150-45d2-8325-a8dd69969300@ideasonboard.com>
 <839d6de4-b396-4799-8a62-9249727b6dcc@ideasonboard.com>
From: Devarsh Thakkar <devarsht@ti.com>
In-Reply-To: <839d6de4-b396-4799-8a62-9249727b6dcc@ideasonboard.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

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