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 <[email protected]>
---
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 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 <[email protected]>
> ---
"[DO NOT MERGE PATCH 2/2]" but no rationale here as to why this cannot
be merged? What's the problem with it?
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
>
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 <[email protected]>
>> ---
>
> "[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 <[email protected]>
> >> ---
> >
> > "[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.
I see. Please note this in your patches, under the --- line, in the
future to avoid confusion.
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 <[email protected]>
> >> ---
> >
> > "[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