[DO,NOT,MERGE,2/2] arm64: dts: ti: Add common1 register space for AM62x and AM65x SoCs

This adds common1 register space for AM62x and AM65x SoC's which are using
TI's Keystone display hardware and supporting it as described in
Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml.

This region is documented in respective Technical Reference Manuals [1].

[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>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++--
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

Hi Conor,

Thanks for the review.

On 15/01/24 21:44, Conor Dooley wrote:
> On Mon, Jan 15, 2024 at 06:27:16PM +0530, Devarsh Thakkar wrote:
>> This adds common1 register space for AM62x and AM65x SoC's which are using
>> TI's Keystone display hardware and supporting it as described in
>> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml.
>>
>> This region is documented in respective Technical Reference Manuals [1].
>>
>> [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>
>> ---
> 
> "[DO NOT MERGE PATCH 2/2]" but no rationale here as to why this cannot
> be merged? What's the problem with it?
> 

No problem as such from my point of view, but this is the process I follow
since maintainer trees for device-tree file and bindings are different. I
generally mark a [DO NOT MERGE] tag for device-tree file patches until binding
patch gets merged so that the device-tree patches don't get applied by mistake
if binding patch has some pending comments.

Once binding patch gets merged, I re-send the device-tree file patches again
to respective list.

Regards
Devarsh

> Cheers,
> Conor.
> 
>>  arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++--
>>  arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++--
>>  2 files changed, 6 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
>> index 464b7565d085..298bf8d5de8c 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
>> @@ -779,9 +779,10 @@ dss: dss@30200000 {
>>  		      <0x00 0x30207000 0x00 0x1000>, /* ovr1 */
>>  		      <0x00 0x30208000 0x00 0x1000>, /* ovr2 */
>>  		      <0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */
>> -		      <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */
>> +		      <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI Out */
>> +		      <0x00 0x30201000 0x00 0x1000>; /* common1 */
>>  		reg-names = "common", "vidl1", "vid",
>> -			    "ovr1", "ovr2", "vp1", "vp2";
>> +			    "ovr1", "ovr2", "vp1", "vp2", "common1";
>>  		power-domains = <&k3_pds 186 TI_SCI_PD_EXCLUSIVE>;
>>  		clocks = <&k3_clks 186 6>,
>>  			 <&dss_vp1_clk>,
>> diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> index fcea54465636..5b2d4365b911 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
>> @@ -1019,9 +1019,10 @@ dss: dss@4a00000 {
>>  		      <0x0 0x04a07000 0x0 0x1000>, /* ovr1 */
>>  		      <0x0 0x04a08000 0x0 0x1000>, /* ovr2 */
>>  		      <0x0 0x04a0a000 0x0 0x1000>, /* vp1 */
>> -		      <0x0 0x04a0b000 0x0 0x1000>; /* vp2 */
>> +		      <0x0 0x04a0b000 0x0 0x1000>, /* vp2 */
>> +		      <0x0 0x04a01000 0x0 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>;
>>  
>> -- 
>> 2.34.1
>>

On Tue, Jan 16, 2024 at 02:48:53PM +0530, Devarsh Thakkar wrote:
> Hi Conor,
> 
> Thanks for the review.
> 
> On 15/01/24 21:44, Conor Dooley wrote:
> > On Mon, Jan 15, 2024 at 06:27:16PM +0530, Devarsh Thakkar wrote:
> >> This adds common1 register space for AM62x and AM65x SoC's which are using
> >> TI's Keystone display hardware and supporting it as described in
> >> Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml.
> >>
> >> This region is documented in respective Technical Reference Manuals [1].
> >>
> >> [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>
> >> ---
> > 
> > "[DO NOT MERGE PATCH 2/2]" but no rationale here as to why this cannot
> > be merged? What's the problem with it?
> > 
> 
> No problem as such from my point of view, but this is the process I follow
> since maintainer trees for device-tree file and bindings are different. I
> generally mark a [DO NOT MERGE] tag for device-tree file patches until binding
> patch gets merged so that the device-tree patches don't get applied by mistake
> if binding patch has some pending comments.

RFC is the tag for "don't merge". Don't make-up your own tags.

Rob