[PATCH] ARM: dts: imx6qdl-dhcom: Move IPU iomux node from PDK2 to SoM file

[PATCH] ARM: dts: imx6qdl-dhcom: Move IPU iomux node from PDK2 to SoM file

[Christoph Niedermaier]

To have a variant (imx6dl/imx6q) independent access to the IPU
iomux node move them to the SoM file. Then it is possible to
access the IPU iomux node in a variant independent DTO.

Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: kernel@dh-electronics.com
To: linux-arm-kernel@lists.infradead.org
---
 arch/arm/boot/dts/imx6qdl-dhcom-pdk2.dtsi | 33 -------------------------------
 arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi  | 33 +++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-dhcom-pdk2.dtsi b/arch/arm/boot/dts/imx6qdl-dhcom-pdk2.dtsi
index fe72650295a5..6248b126b557 100644
--- a/arch/arm/boot/dts/imx6qdl-dhcom-pdk2.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-dhcom-pdk2.dtsi
@@ -332,37 +332,4 @@
 			MX6QDL_PAD_GPIO_0__GPIO1_IO00		0xb1 /* Int */
 		>;
 	};
-
-	pinctrl_ipu1_lcdif: ipu1-lcdif-grp {
-		fsl,pins = <
-			MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK	0x38
-			MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02		0x38
-			MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03		0x38
-			MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15		0x38
-			MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00	0x38
-			MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01	0x38
-			MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02	0x38
-			MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03	0x38
-			MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04	0x38
-			MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05	0x38
-			MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06	0x38
-			MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07	0x38
-			MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08	0x38
-			MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09	0x38
-			MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10	0x38
-			MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11	0x38
-			MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12	0x38
-			MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13	0x38
-			MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14	0x38
-			MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15	0x38
-			MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16	0x38
-			MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17	0x38
-			MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18	0x38
-			MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19	0x38
-			MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20	0x38
-			MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21	0x38
-			MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22	0x38
-			MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23	0x38
-		>;
-	};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi b/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi
index 5befbe13d1a3..eaa87b333164 100644
--- a/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-dhcom-som.dtsi
@@ -667,6 +667,39 @@
 		>;
 	};
 
+	pinctrl_ipu1_lcdif: ipu1-lcdif-grp {
+		fsl,pins = <
+			MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK	0x38
+			MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02		0x38
+			MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03		0x38
+			MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15		0x38
+			MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00	0x38
+			MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01	0x38
+			MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02	0x38
+			MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03	0x38
+			MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04	0x38
+			MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05	0x38
+			MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06	0x38
+			MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07	0x38
+			MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08	0x38
+			MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09	0x38
+			MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10	0x38
+			MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11	0x38
+			MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12	0x38
+			MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13	0x38
+			MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14	0x38
+			MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15	0x38
+			MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16	0x38
+			MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17	0x38
+			MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18	0x38
+			MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19	0x38
+			MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20	0x38
+			MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21	0x38
+			MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22	0x38
+			MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23	0x38
+		>;
+	};
+
 	pinctrl_pcie: pcie-grp {
 		fsl,pins = <
 			MX6QDL_PAD_CSI0_DATA_EN__GPIO5_IO20	0x1b0b1 /* Wake */
-- 
2.11.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: imx6qdl-dhcom: Move IPU iomux node from PDK2 to SoM file

[Krzysztof Kozlowski]

On 12/08/2022 15:03, Christoph Niedermaier wrote:
> To have a variant (imx6dl/imx6q) independent access to the IPU
> iomux node move them to the SoM file. 

There is no such variant using them, so the "possibility" is not a
reason for such change. The change by itself, without proper users, does
not make any sense.

> Then it is possible to
> access the IPU iomux node in a variant independent DTO.
> 
> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Marek Vasut <marex@denx.de>
> Cc: NXP Linux Team <linux-imx@nxp.com>
> Cc: kernel@dh-electronics.com
> To: linux-arm-kernel@lists.infradead.org

Similarly to other patch - git history log is not a place for it,
really. You just pasted here output of maintainers...

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: imx6qdl-dhcom: Move IPU iomux node from PDK2 to SoM file

[Marek Vasut]

On 8/12/22 15:25, Krzysztof Kozlowski wrote:
> On 12/08/2022 15:03, Christoph Niedermaier wrote:
>> To have a variant (imx6dl/imx6q) independent access to the IPU
>> iomux node move them to the SoM file.
> 
> There is no such variant using them, so the "possibility" is not a
> reason for such change. The change by itself, without proper users, does
> not make any sense.

I think it does make sense to move the IPUv3 RGB/DPI interface pinmux 
description from PDK2 carrier board DT into the common SoM DTSI, but for 
a different reason entirely.

The SoM specification states there is such an interface on the SoM pins:

"
https://wiki.dh-electronics.com/images/2/2e/DOC_DHCOM-Standard-Specification_R01_2016-11-17.pdf

Page 20

5.1.14 RGB Display
The DHCOM standard provides a parallel 24-bit RGB interface for driving 
displays.
"

And from what I can tell, for a carrier board to be compatible with the 
SoM standard above, those pins have to be used as the RGB/DPI interface 
or not used at all.

So rather than duplicate the pinmux settings in every carrier board DT, 
better move/deduplicate them into the SoM DTSI.

But it seems the commit message should be updated to reflect that.

btw. there are also downstream DTOs which do reference that pinmux 
settings label, but maybe those DTOs are not really interesting with 
regards to this specific change.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: imx6qdl-dhcom: Move IPU iomux node from PDK2 to SoM file

[Krzysztof Kozlowski]

On 12/08/2022 20:27, Marek Vasut wrote:
> On 8/12/22 15:25, Krzysztof Kozlowski wrote:
>> On 12/08/2022 15:03, Christoph Niedermaier wrote:
>>> To have a variant (imx6dl/imx6q) independent access to the IPU
>>> iomux node move them to the SoM file.
>>
>> There is no such variant using them, so the "possibility" is not a
>> reason for such change. The change by itself, without proper users, does
>> not make any sense.
> 
> I think it does make sense to move the IPUv3 RGB/DPI interface pinmux 
> description from PDK2 carrier board DT into the common SoM DTSI, but for 
> a different reason entirely.
> 
> The SoM specification states there is such an interface on the SoM pins:
> 
> "
> https://wiki.dh-electronics.com/images/2/2e/DOC_DHCOM-Standard-Specification_R01_2016-11-17.pdf
> 
> Page 20
> 
> 5.1.14 RGB Display
> The DHCOM standard provides a parallel 24-bit RGB interface for driving 
> displays.
> "
> 
> And from what I can tell, for a carrier board to be compatible with the 
> SoM standard above, those pins have to be used as the RGB/DPI interface 
> or not used at all.
> 
> So rather than duplicate the pinmux settings in every carrier board DT, 
> better move/deduplicate them into the SoM DTSI.
> 
> But it seems the commit message should be updated to reflect that.
> 
> btw. there are also downstream DTOs which do reference that pinmux 
> settings label, but maybe those DTOs are not really interesting with 
> regards to this specific change.

That's much better reasoning and it makes sense.

Best regards,
Krzysztof

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH] ARM: dts: imx6qdl-dhcom: Move IPU iomux node from PDK2 to SoM file

[Christoph Niedermaier]

From: Krzysztof Kozlowski [mailto:krzysztof.kozlowski@linaro.org]
Sent: Friday, August 12, 2022 7:41 PM
> On 12/08/2022 20:27, Marek Vasut wrote:
>> On 8/12/22 15:25, Krzysztof Kozlowski wrote:
>>> On 12/08/2022 15:03, Christoph Niedermaier wrote:
>>>> To have a variant (imx6dl/imx6q) independent access to the IPU
>>>> iomux node move them to the SoM file.
>>>
>>> There is no such variant using them, so the "possibility" is not a
>>> reason for such change. The change by itself, without proper users, does
>>> not make any sense.
>>
>> I think it does make sense to move the IPUv3 RGB/DPI interface pinmux
>> description from PDK2 carrier board DT into the common SoM DTSI, but for
>> a different reason entirely.
>>
>> The SoM specification states there is such an interface on the SoM pins:
>>
>> "
>> https://wiki.dh-electronics.com/images/2/2e/DOC_DHCOM-Standard-Specification_R01_2016-11-17.pdf
>>
>> Page 20
>>
>> 5.1.14 RGB Display
>> The DHCOM standard provides a parallel 24-bit RGB interface for driving
>> displays.
>> "
>>
>> And from what I can tell, for a carrier board to be compatible with the
>> SoM standard above, those pins have to be used as the RGB/DPI interface
>> or not used at all.
>>
>> So rather than duplicate the pinmux settings in every carrier board DT,
>> better move/deduplicate them into the SoM DTSI.
>>
>> But it seems the commit message should be updated to reflect that.
>>
>> btw. there are also downstream DTOs which do reference that pinmux
>> settings label, but maybe those DTOs are not really interesting with
>> regards to this specific change.
> 
> That's much better reasoning and it makes sense.

I will improve the commit message in V2.

Regards,
Christoph
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel