From f2c2e9ebb2cf476c09e59d073db031fbf7ef4914 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Wed, 20 Oct 2021 14:36:11 +0300 Subject: ARM: dts: imx6qp-prtwd3: update RGMII delays for sja1105 switch In the new behavior, the sja1105 driver expects there to be explicit RGMII delays present on the fixed-link ports, otherwise it will complain that it falls back to legacy behavior, which is to apply RGMII delays incorrectly derived from the phy-mode string. In this case, the legacy behavior of the driver is to apply both RX and TX delays. To preserve that, add explicit 2 nanosecond delays, which are identical with what the driver used to add (a 90 degree phase shift). The delays from the phy-mode are ignored by new kernels (it's still RGMII as long as it's "rgmii*" something), and the explicit {rx,tx}-internal-delay-ps properties are ignored by old kernels, so the change works both ways. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Oleksij Rempel Signed-off-by: Shawn Guo --- arch/arm/boot/dts/imx6qp-prtwd3.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/imx6qp-prtwd3.dts b/arch/arm/boot/dts/imx6qp-prtwd3.dts index 7648e8a02000..cf6571cc4682 100644 --- a/arch/arm/boot/dts/imx6qp-prtwd3.dts +++ b/arch/arm/boot/dts/imx6qp-prtwd3.dts @@ -178,6 +178,8 @@ label = "cpu"; ethernet = <&fec>; phy-mode = "rgmii-id"; + rx-internal-delay-ps = <2000>; + tx-internal-delay-ps = <2000>; fixed-link { speed = <100>; -- cgit v1.2.3 From e691f9282a89e24a8e87cdb91a181c6283ee5124 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Wed, 20 Oct 2021 14:36:12 +0300 Subject: ARM: dts: ls1021a-tsn: update RGMII delays for sja1105 switch In the new behavior, the sja1105 driver expects there to be explicit RGMII delays present on the fixed-link ports, otherwise it will complain that it falls back to legacy behavior, which is to apply RGMII delays incorrectly derived from the phy-mode string. In this case, the legacy behavior of the driver is to not apply delays in any direction (mostly because the SJA1105T can't do that, so this board uses PCB traces). To preserve that but also silence the driver, use explicit delays of 0 ns. The delay information from the phy-mode is ignored by new kernels (it's still RGMII as long as it's "rgmii*" something), and the explicit {rx,tx}-internal-delay-ps properties are ignored by old kernels, so the change works both ways. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Shawn Guo --- arch/arm/boot/dts/ls1021a-tsn.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/ls1021a-tsn.dts b/arch/arm/boot/dts/ls1021a-tsn.dts index ff0ffb22768b..1ea32fff4120 100644 --- a/arch/arm/boot/dts/ls1021a-tsn.dts +++ b/arch/arm/boot/dts/ls1021a-tsn.dts @@ -91,6 +91,8 @@ /* Internal port connected to eth2 */ ethernet = <&enet2>; phy-mode = "rgmii"; + rx-internal-delay-ps = <0>; + tx-internal-delay-ps = <0>; reg = <4>; fixed-link { -- cgit v1.2.3 From 25501d8d3ab3f5dc83799731dfb8ebaf03ca5000 Mon Sep 17 00:00:00 2001 From: Vladimir Oltean Date: Wed, 20 Oct 2021 14:36:13 +0300 Subject: arm64: dts: lx2160abluebox3: update RGMII delays for sja1105 switch In the new behavior, the sja1105 driver expects there to be explicit RGMII delays present on the fixed-link ports, otherwise it will complain that it falls back to legacy behavior, which is to apply RGMII delays incorrectly derived from the phy-mode string. In this case, the legacy behavior of the driver is to apply both RX and TX delays. To preserve that, add explicit 2 nanosecond delays, which are identical with what the driver used to add (a 90 degree phase shift). The delays from the phy-mode are ignored by new kernels (it's still RGMII as long as it's "rgmii*" something), and the explicit {rx,tx}-internal-delay-ps properties are ignored by old kernels, so the change works both ways. Signed-off-by: Vladimir Oltean Signed-off-by: Shawn Guo --- arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts index b21be03da0af..042c486bdda2 100644 --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-bluebox3.dts @@ -386,6 +386,8 @@ reg = <2>; ethernet = <&dpmac17>; phy-mode = "rgmii-id"; + rx-internal-delay-ps = <2000>; + tx-internal-delay-ps = <2000>; fixed-link { speed = <1000>; @@ -529,6 +531,8 @@ reg = <2>; ethernet = <&dpmac18>; phy-mode = "rgmii-id"; + rx-internal-delay-ps = <2000>; + tx-internal-delay-ps = <2000>; fixed-link { speed = <1000>; -- cgit v1.2.3 From c88c5e461939a06ae769a01649d5c6b5a156f883 Mon Sep 17 00:00:00 2001 From: Mathew McBride Date: Mon, 22 Nov 2021 02:55:54 +0000 Subject: arm64: dts: ten64: remove redundant interrupt declaration for gpio-keys gpio-keys already 'inherits' the interrupts from the controller of the specified GPIO, so having another declaration is redundant. On >=v5.15 this started causing an oops under gpio_keys_probe as the IRQ was already claimed. Signed-off-by: Mathew McBride Fixes: 418962eea358 ("arm64: dts: add device tree for Traverse Ten64 (LS1088A)") Cc: stable@vger.kernel.org Signed-off-by: Shawn Guo --- arch/arm64/boot/dts/freescale/fsl-ls1088a-ten64.dts | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-ten64.dts b/arch/arm64/boot/dts/freescale/fsl-ls1088a-ten64.dts index 3063851c2fb9..d3f03dcbb8c3 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-ten64.dts +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-ten64.dts @@ -38,7 +38,6 @@ powerdn { label = "External Power Down"; gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; - interrupts = <&gpio1 17 IRQ_TYPE_EDGE_FALLING>; linux,code = ; }; @@ -46,7 +45,6 @@ admin { label = "ADMIN button"; gpios = <&gpio3 8 GPIO_ACTIVE_HIGH>; - interrupts = <&gpio3 8 IRQ_TYPE_EDGE_RISING>; linux,code = ; }; }; -- cgit v1.2.3 From e5e6268f77badf18bd6ab435364cfe21c7396c31 Mon Sep 17 00:00:00 2001 From: Martin Kepplinger Date: Wed, 24 Nov 2021 09:37:03 +0100 Subject: arm64: dts: imx8mq: remove interconnect property from lcdif The mxsfb driver handling imx8mq lcdif doesn't yet request the interconnect bandwidth that's needed at runtime when the description is present in the DT node. So remove that description and bring it back when it's supported. Fixes: ad1abc8a03fd ("arm64: dts: imx8mq: Add interconnect for lcdif") Signed-off-by: Martin Kepplinger Signed-off-by: Shawn Guo --- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi index 972766b67a15..71bf497f99c2 100644 --- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi @@ -524,8 +524,6 @@ <&clk IMX8MQ_VIDEO_PLL1>, <&clk IMX8MQ_VIDEO_PLL1_OUT>; assigned-clock-rates = <0>, <0>, <0>, <594000000>; - interconnects = <&noc IMX8MQ_ICM_LCDIF &noc IMX8MQ_ICS_DRAM>; - interconnect-names = "dram"; status = "disabled"; port@0 { -- cgit v1.2.3 From 737e65c7956795b3553781fb7bc82fce1c39503f Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Wed, 24 Nov 2021 15:45:41 -0300 Subject: ARM: dts: imx6ull-pinfunc: Fix CSI_DATA07__ESAI_TX0 pad name According to the i.MX6ULL Reference Manual, pad CSI_DATA07 may have the ESAI_TX0 functionality, not ESAI_T0. Also, NXP's i.MX Config Tools 10.0 generates dtsi with the MX6ULL_PAD_CSI_DATA07__ESAI_TX0 naming, so fix it accordingly. There are no devicetree users in mainline that use the old name, so just remove the old entry. Fixes: c201369d4aa5 ("ARM: dts: imx6ull: add imx6ull support") Reported-by: George Makarov Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo --- arch/arm/boot/dts/imx6ull-pinfunc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/imx6ull-pinfunc.h b/arch/arm/boot/dts/imx6ull-pinfunc.h index eb025a9d4759..7328d4ef8559 100644 --- a/arch/arm/boot/dts/imx6ull-pinfunc.h +++ b/arch/arm/boot/dts/imx6ull-pinfunc.h @@ -82,6 +82,6 @@ #define MX6ULL_PAD_CSI_DATA04__ESAI_TX_FS 0x01F4 0x0480 0x0000 0x9 0x0 #define MX6ULL_PAD_CSI_DATA05__ESAI_TX_CLK 0x01F8 0x0484 0x0000 0x9 0x0 #define MX6ULL_PAD_CSI_DATA06__ESAI_TX5_RX0 0x01FC 0x0488 0x0000 0x9 0x0 -#define MX6ULL_PAD_CSI_DATA07__ESAI_T0 0x0200 0x048C 0x0000 0x9 0x0 +#define MX6ULL_PAD_CSI_DATA07__ESAI_TX0 0x0200 0x048C 0x0000 0x9 0x0 #endif /* __DTS_IMX6ULL_PINFUNC_H */ -- cgit v1.2.3 From 042b67799e2991e301df8269e166d8bc5944495e Mon Sep 17 00:00:00 2001 From: Adam Ford Date: Sun, 28 Nov 2021 06:50:07 -0600 Subject: soc: imx: imx8m-blk-ctrl: Fix imx8mm mipi reset Most of the blk-ctrl reset bits are found in one register, however there are two bits in offset 8 for pulling the MIPI DPHY out of reset and one of them needs to be set when IMX8MM_DISPBLK_PD_MIPI_CSI is brought out of reset or the MIPI_CSI hangs. Since MIPI_DSI is impacted, add the additional one for MIPI_DSI too. Fixes: 926e57c065df ("soc: imx: imx8m-blk-ctrl: add DISP blk-ctrl") Signed-off-by: Adam Ford Reviewed-by: Fabio Estevam Reviewed-by: Lucas Stach Reviewed-by: Laurent Pinchart Tested by: Tim Harvey Signed-off-by: Shawn Guo --- drivers/soc/imx/imx8m-blk-ctrl.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/soc/imx/imx8m-blk-ctrl.c b/drivers/soc/imx/imx8m-blk-ctrl.c index 519b3651d1d9..c2f076b56e24 100644 --- a/drivers/soc/imx/imx8m-blk-ctrl.c +++ b/drivers/soc/imx/imx8m-blk-ctrl.c @@ -17,6 +17,7 @@ #define BLK_SFT_RSTN 0x0 #define BLK_CLK_EN 0x4 +#define BLK_MIPI_RESET_DIV 0x8 /* Mini/Nano DISPLAY_BLK_CTRL only */ struct imx8m_blk_ctrl_domain; @@ -36,6 +37,15 @@ struct imx8m_blk_ctrl_domain_data { const char *gpc_name; u32 rst_mask; u32 clk_mask; + + /* + * i.MX8M Mini and Nano have a third DISPLAY_BLK_CTRL register + * which is used to control the reset for the MIPI Phy. + * Since it's only present in certain circumstances, + * an if-statement should be used before setting and clearing this + * register. + */ + u32 mipi_phy_rst_mask; }; #define DOMAIN_MAX_CLKS 3 @@ -78,6 +88,8 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd) /* put devices into reset */ regmap_clear_bits(bc->regmap, BLK_SFT_RSTN, data->rst_mask); + if (data->mipi_phy_rst_mask) + regmap_clear_bits(bc->regmap, BLK_MIPI_RESET_DIV, data->mipi_phy_rst_mask); /* enable upstream and blk-ctrl clocks to allow reset to propagate */ ret = clk_bulk_prepare_enable(data->num_clks, domain->clks); @@ -99,6 +111,8 @@ static int imx8m_blk_ctrl_power_on(struct generic_pm_domain *genpd) /* release reset */ regmap_set_bits(bc->regmap, BLK_SFT_RSTN, data->rst_mask); + if (data->mipi_phy_rst_mask) + regmap_set_bits(bc->regmap, BLK_MIPI_RESET_DIV, data->mipi_phy_rst_mask); /* disable upstream clocks */ clk_bulk_disable_unprepare(data->num_clks, domain->clks); @@ -120,6 +134,9 @@ static int imx8m_blk_ctrl_power_off(struct generic_pm_domain *genpd) struct imx8m_blk_ctrl *bc = domain->bc; /* put devices into reset and disable clocks */ + if (data->mipi_phy_rst_mask) + regmap_clear_bits(bc->regmap, BLK_MIPI_RESET_DIV, data->mipi_phy_rst_mask); + regmap_clear_bits(bc->regmap, BLK_SFT_RSTN, data->rst_mask); regmap_clear_bits(bc->regmap, BLK_CLK_EN, data->clk_mask); @@ -480,6 +497,7 @@ static const struct imx8m_blk_ctrl_domain_data imx8mm_disp_blk_ctl_domain_data[] .gpc_name = "mipi-dsi", .rst_mask = BIT(5), .clk_mask = BIT(8) | BIT(9), + .mipi_phy_rst_mask = BIT(17), }, [IMX8MM_DISPBLK_PD_MIPI_CSI] = { .name = "dispblk-mipi-csi", @@ -488,6 +506,7 @@ static const struct imx8m_blk_ctrl_domain_data imx8mm_disp_blk_ctl_domain_data[] .gpc_name = "mipi-csi", .rst_mask = BIT(3) | BIT(4), .clk_mask = BIT(10) | BIT(11), + .mipi_phy_rst_mask = BIT(16), }, }; -- cgit v1.2.3 From 4ebd29f91629e69da7d57390cdc953772eee03ab Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Mon, 6 Dec 2021 12:38:28 +0100 Subject: soc: imx: Register SoC device only on i.MX boards At the moment, using the ARM32 multi_v7_defconfig always results in two SoCs being exposed in sysfs. This is wrong, as far as I'm aware the Qualcomm DragonBoard 410c does not actually make use of a i.MX SoC. :) qcom-db410c:/sys/devices/soc0$ grep . * family:Freescale i.MX machine:Qualcomm Technologies, Inc. APQ 8016 SBC revision:0.0 serial_number:0000000000000000 soc_id:Unknown qcom-db410c:/sys/devices/soc1$ grep . * family:Snapdragon machine:APQ8016 ... This happens because imx_soc_device_init() registers the soc device unconditionally, even when running on devices that do not make use of i.MX. Arnd already reported this more than a year ago and even suggested a fix similar to this commit, but for some reason it was never submitted. Fix it by checking if the "__mxc_cpu_type" variable was actually initialized by earlier platform code. On devices without i.MX it will simply stay 0. Cc: Peng Fan Fixes: d2199b34871b ("ARM: imx: use device_initcall for imx_soc_device_init") Reported-by: Arnd Bergmann Link: https://lore.kernel.org/r/CAK8P3a0hxO1TmK6oOMQ70AHSWJnP_CAq57YMOutrxkSYNjFeuw@mail.gmail.com/ Signed-off-by: Stephan Gerhold Reviewed-by: Fabio Estevam Reviewed-by: Peng Fan Signed-off-by: Shawn Guo --- drivers/soc/imx/soc-imx.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/soc/imx/soc-imx.c b/drivers/soc/imx/soc-imx.c index ac6d856ba228..77bc12039c3d 100644 --- a/drivers/soc/imx/soc-imx.c +++ b/drivers/soc/imx/soc-imx.c @@ -36,6 +36,10 @@ static int __init imx_soc_device_init(void) int ret; int i; + /* Return early if this is running on devices with different SoCs */ + if (!__mxc_cpu_type) + return 0; + if (of_machine_is_compatible("fsl,ls1021a")) return 0; -- cgit v1.2.3 From 39e660687ac0c57499134765abbecf71cfd11eae Mon Sep 17 00:00:00 2001 From: Martin Haaß Date: Sun, 12 Dec 2021 09:30:30 -0300 Subject: ARM: dts: imx6qdl-wandboard: Fix Ethernet support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently, the imx6q-wandboard Ethernet does not transmit any data. This issue has been exposed by commit f5d9aa79dfdf ("ARM: imx6q: remove clk-out fixup for the Atheros AR8031 and AR8035 PHYs"). Fix it by describing the qca,clk-out-frequency property as suggested by the commit above. Fixes: 77591e42458d ("ARM: dts: imx6qdl-wandboard: add ethernet PHY description") Signed-off-by: Martin Haaß Tested-by: Fabio Estevam Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo --- arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi index b62a0dbb033f..ec6fba5ee8fd 100644 --- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi +++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi @@ -309,6 +309,7 @@ ethphy: ethernet-phy@1 { reg = <1>; + qca,clk-out-frequency = <125000000>; }; }; }; -- cgit v1.2.3 From 849e087ba68ac6956c11016ce34f9f10a09a4186 Mon Sep 17 00:00:00 2001 From: Zhang Ying-22455 Date: Tue, 14 Dec 2021 01:23:33 -0600 Subject: arm64: dts: lx2160a: fix scl-gpios property name Fix the typo in the property name. Fixes: d548c217c6a3c ("arm64: dts: add QorIQ LX2160A SoC support") Signed-off-by: Zhang Ying Signed-off-by: Li Yang Signed-off-by: Shawn Guo --- arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi index dc8661ebd1f6..2433e6f2eda8 100644 --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi @@ -719,7 +719,7 @@ clock-names = "i2c"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - scl-gpio = <&gpio2 15 GPIO_ACTIVE_HIGH>; + scl-gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>; status = "disabled"; }; @@ -768,7 +768,7 @@ clock-names = "i2c"; clocks = <&clockgen QORIQ_CLK_PLATFORM_PLL QORIQ_CLK_PLL_DIV(16)>; - scl-gpio = <&gpio2 16 GPIO_ACTIVE_HIGH>; + scl-gpios = <&gpio2 16 GPIO_ACTIVE_HIGH>; status = "disabled"; }; -- cgit v1.2.3