| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <ec59c235f11664a0a90f14b86bd63f74fb7f6d27.camel@toradex.com>
Date: Mon, 19 Sep 2022 15:22:29 +0000
From: Marcel Ziswiler <marcel.ziswiler@...adex.com>
To: "vkoul@...nel.org" <vkoul@...nel.org>,
"richard.leitner@...ux.dev" <richard.leitner@...ux.dev>,
"alexander.stein@...tq-group.com" <alexander.stein@...tq-group.com>,
"robh@...nel.org" <robh@...nel.org>,
"l.stach@...gutronix.de" <l.stach@...gutronix.de>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"hongxing.zhu@....com" <hongxing.zhu@....com>,
"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
"tharvey@...eworks.com" <tharvey@...eworks.com>,
"marex@...x.de" <marex@...x.de>
CC: "linux-phy@...ts.infradead.org" <linux-phy@...ts.infradead.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-imx@....com" <linux-imx@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v7 3/7] arm64: dts: imx8mp-evk: Add PCIe support
Hi Richard et. al.
Thank you very much for the i.MX 8MP PCIe support work.
On Fri, 2022-09-02 at 16:58 +0800, Richard Zhu wrote:
> Add PCIe support on i.MX8MP EVK board.
>
> Signed-off-by: Richard Zhu <hongxing.zhu-3arQi8VN3Tc@...lic.gmane.org>
> Tested-by: Marek Vasut <marex-ynQEQJNshbs@...lic.gmane.org>
> Tested-by: Richard Leitner <richard.leitner-WcANXNA0UjBBDgjK7y7TUQ@...lic.gmane.org>
> Tested-by: Alexander Stein <alexander.stein-W3o+9BuWjQaZox4op4iWzw@...lic.gmane.org>
> Reviewed-by: Lucas Stach <l.stach-bIcnvbaLZ9MEGnE8C9+IrQ@...lic.gmane.org>
> ---
> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 53 ++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> index f6b017ab5f53..9f1469db554d 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> @@ -5,6 +5,7 @@
>
> /dts-v1/;
>
> +#include <dt-bindings/phy/phy-imx8-pcie.h>
> #include "imx8mp.dtsi"
>
> / {
> @@ -33,6 +34,12 @@ memory@...00000 {
> <0x1 0x00000000 0 0xc0000000>;
> };
>
> + pcie0_refclk: pcie0-refclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <100000000>;
> + };
> +
> reg_can1_stby: regulator-can1-stby {
> compatible = "regulator-fixed";
> regulator-name = "can1-stby";
> @@ -55,6 +62,17 @@ reg_can2_stby: regulator-can2-stby {
> enable-active-high;
> };
>
> + reg_pcie0: regulator-pcie {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie0_reg>;
> + regulator-name = "MPCIE_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + gpio = <&gpio2 6 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> reg_usdhc2_vmmc: regulator-usdhc2 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> @@ -350,6 +368,28 @@ &i2c5 {
> */
> };
>
> +&pcie_phy {
> + fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
While this indeed works on the EVK so far I failed to get this to work on our Verdin iMX8M Plus which requires
the fsl,refclk-pad-mode to be IMX8_PCIE_REFCLK_PAD_OUTPUT. It is not quite clear to me what kind of clocks I
would need specifying in that case.
Has anybody by any chance tried on any such HW design?
For reference [1] on the Verdin iMX8M Mini the same works very well but the clocking seems rather different.
Okay, I still get quite some PCIe devices which only intermittently work upstream while NXP's downstream seems
to configure something slightly differently which makes all those work just fine very consistently. Not sure
whether anybody also observed any such issues? Here it goes for some of the oddities I am seeing:
[ 0.959224] ehci-pci: EHCI PCI platform driver
[ 0.988467] ohci-pci: OHCI PCI platform driver
[ 1.472555] imx6q-pcie 33800000.pcie: host bridge /soc@...cie@...00000 ranges:
[ 1.479848] imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
[ 1.492083] imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000
[ 1.716687] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[ 1.722275] imx6q-pcie 33800000.pcie: iATU regions: 4 ob, 4 ib, align 64K, limit 4G
[ 2.725927] imx6q-pcie 33800000.pcie: Phy link never came up
[ 3.735497] imx6q-pcie 33800000.pcie: Phy link never came up
[ 3.741324] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
[ 3.747700] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 3.753204] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 3.759406] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
[ 3.766334] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[ 3.772369] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[ 3.778660] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[ 3.785426] pci 0000:00:00.0: supports D1
[ 3.789452] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[ 3.798043] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 3.806222] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 3.812879] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
[ 3.819693] pci 0000:00:00.0: BAR 6: assigned [mem 0x18100000-0x1810ffff pref]
[ 3.826943] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 3.832134] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[ 3.838433] pcieport 0000:00:00.0: PME: Signaling with IRQ 205
[ 3.846113] pcieport 0000:00:00.0: AER: enabled with IRQ 205
=> Link might succeed on 3rd try. That's with an Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz (rev 1a).
[ 0.960023] ehci-pci: EHCI PCI platform driver
[ 0.989203] ohci-pci: OHCI PCI platform driver
[ 1.484831] imx6q-pcie 33800000.pcie: host bridge /soc@...cie@...00000 ranges:
[ 1.492125] imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
[ 1.504358] imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000
[ 1.728462] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[ 1.735760] imx6q-pcie 33800000.pcie: iATU regions: 4 ob, 4 ib, align 64K, limit 4G
[ 2.051318] imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up
[ 3.035507] imx6q-pcie 33800000.pcie: Phy link never came up
[ 3.841078] imx6q-pcie 33800000.pcie: PCIe Gen.1 x1 link up
[ 3.846838] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
[ 3.853218] pci_bus 0000:00: root bus resource [bus 00-ff]
[ 3.858725] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 3.864923] pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
[ 3.871842] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
[ 3.877881] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
[ 3.884174] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
[ 3.890943] pci 0000:00:00.0: supports D1
[ 3.894967] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
[ 3.903559] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 3.918350] pci 0000:01:00.0: [10ec:b852] type 00 class 0xffffff
[ 3.924562] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
[ 3.931221] pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
[ 3.938032] pci 0000:00:00.0: BAR 6: assigned [mem 0x18100000-0x1810ffff pref]
[ 3.945279] pci 0000:00:00.0: PCI bridge to [bus 01]
[ 3.950473] pcieport 0000:00:00.0: enabling device (0000 -> 0002)
[ 3.956769] pcieport 0000:00:00.0: PME: Signaling with IRQ 205
[ 3.964202] pcieport 0000:00:00.0: AER: enabled with IRQ 205
=> Strangely link at first succeeds, then fails again but later succeeds on 3rd try. That's with a Realtek
Semiconductor Co., Ltd. Device b852 (rev ff).
A Qualcomm QCA6390 Wireless Network Adapter I never saw working upstream but it works consistently reliably
using NXP's downstream.
Any insight much appreciated and sorry for kinda high-jacking this thread. If I should rather report this
separately let me know and I am happy to do so.
Thanks!
> + clocks = <&pcie0_refclk>;
> + clock-names = "ref";
> + status = "okay";
> +};
> +
> +&pcie {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pcie0>;
> + reset-gpio = <&gpio2 7 GPIO_ACTIVE_LOW>;
> + clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
> + <&clk IMX8MP_CLK_PCIE_ROOT>,
> + <&clk IMX8MP_CLK_HSIO_AXI>;
> + clock-names = "pcie", "pcie_aux", "pcie_bus";
> + assigned-clocks = <&clk IMX8MP_CLK_PCIE_AUX>;
> + assigned-clock-rates = <10000000>;
> + assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_50M>;
> + vpcie-supply = <®_pcie0>;
> + status = "okay";
> +};
> +
> &snvs_pwrkey {
> status = "okay";
> };
> @@ -502,6 +542,19 @@ MX8MP_IOMUXC_SPDIF_TX__I2C5_SCL 0x400001c2
> >;
> };
>
> + pinctrl_pcie0: pcie0grp {
> + fsl,pins = <
> + MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B 0x61 /* open drain, pull up */
> + MX8MP_IOMUXC_SD1_DATA5__GPIO2_IO07 0x41
> + >;
> + };
> +
> + pinctrl_pcie0_reg: pcie0reggrp {
> + fsl,pins = <
> + MX8MP_IOMUXC_SD1_DATA4__GPIO2_IO06 0x41
> + >;
> + };
> +
> pinctrl_pmic: pmicgrp {
> fsl,pins = <
> MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x000001c0
Cheers
Marcel
Powered by blists - more mailing lists