| Message ID | 20220812120337.5580-1-cniedermaier@dh-electronics.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ARM: dts: imx6qdl-dhcom: Move IPU iomux node from PDK2 to SoM file | expand |
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
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.
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
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
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 */
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(-)