* PCIe missing on RK3399 @ 2024-12-11 12:55 Vicente Bergas 2024-12-11 13:36 ` Heiko Stübner 2025-02-07 0:17 ` PCIe missing on RK3399 Trevor Woerner 0 siblings, 2 replies; 15+ messages in thread From: Vicente Bergas @ 2024-12-11 12:55 UTC (permalink / raw) To: Heiko Stübner; +Cc: open list:ARM/Rockchip SoC... Hi, i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the kernel version 6.12.3 works fine. 6.13 configuration is based on the same one as 6.12 and there aren't any significant PCI-related differences. The messages from dmesg on 6.13 don't show any PCI-related errors. Does somebody know what is going on? Regards, Vicente. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-11 12:55 PCIe missing on RK3399 Vicente Bergas @ 2024-12-11 13:36 ` Heiko Stübner 2024-12-11 15:10 ` Vicente Bergas 2025-02-07 0:17 ` PCIe missing on RK3399 Trevor Woerner 1 sibling, 1 reply; 15+ messages in thread From: Heiko Stübner @ 2024-12-11 13:36 UTC (permalink / raw) To: Vicente Bergas; +Cc: open list:ARM/Rockchip SoC... Hi Vicente, Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > kernel version 6.12.3 works fine. > > 6.13 configuration is based on the same one as 6.12 and there aren't > any significant PCI-related differences. > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > Does somebody know what is going on? so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the pcie slot. And I get: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 ... [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup [ 3.455332] of_get_named_gpiod_flags: parsed 'ep-gpios' property of node '/pcie@f8000000[0]' - status (0) [ 3.455359] gpio gpiochip4: Persistence not supported for GPIO 22 [ 3.499404] usb 3-1: new high-speed USB device number 2 using xhci-hcd [ 3.664293] rockchip-pcie f8000000.pcie: PCI host bridge to bus 0000:00 [ 3.671770] pci_bus 0000:00: root bus resource [bus 00-1f] [ 3.677936] pci_bus 0000:00: root bus resource [mem 0xfa000000-0xfbdfffff] [ 3.685680] pci_bus 0000:00: root bus resource [io 0x0000-0xfffff] (bus address [0xfbe00000-0xfbefffff]) [ 3.696474] pci 0000:00:00.0: [1d87:0100] type 01 class 0x060400 PCIe Root Port [ 3.704852] hub 3-1:1.0: USB hub found [ 3.709114] pci 0000:00:00.0: PCI bridge to [bus 00] [ 3.714682] hub 3-1:1.0: 4 ports detected [ 3.719334] pci 0000:00:00.0: bridge window [mem 0x00000000-0x000fffff] [ 3.727028] pci 0000:00:00.0: supports D1 [ 3.731523] pci 0000:00:00.0: PME# supported from D0 D1 D3hot [ 3.739745] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 3.748858] pci 0000:01:00.0: [144d:a804] type 00 class 0x010802 PCIe Endpoint [ 3.757011] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00003fff 64bit] [ 3.764358] pci 0000:01:00.0: Max Payload Size set to 256 (was 128, max 256) [ 3.772374] usb 4-1: new SuperSpeed USB device number 2 using xhci-hcd [ 3.780132] pci 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:00.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link) [ 3.803225] pci_bus 0000:01: busn_res: [bus 01-1f] end is updated to 01 [ 3.810659] pci 0000:00:00.0: bridge window [mem 0xfa000000-0xfa0fffff]: assigned [ 3.819082] pci 0000:01:00.0: BAR 0 [mem 0xfa000000-0xfa003fff 64bit]: assigned [ 3.827302] pci 0000:00:00.0: PCI bridge to [bus 01] [ 3.832873] pci 0000:00:00.0: bridge window [mem 0xfa000000-0xfa0fffff] [ 3.844769] pci_bus 0000:00: resource 4 [mem 0xfa000000-0xfbdfffff] [ 3.856277] pci_bus 0000:00: resource 5 [io 0x0000-0xfffff] [ 3.862618] pci_bus 0000:01: resource 1 [mem 0xfa000000-0xfa0fffff] [ 3.869750] pcieport 0000:00:00.0: enabling device (0000 -> 0002) [ 3.876911] pcieport 0000:00:00.0: PME: Signaling with IRQ 85 [ 3.884054] nvme nvme0: pci function 0000:01:00.0 [ 3.889336] nvme 0000:01:00.0: enabling device (0000 -> 0002) [ 3.915282] nvme nvme0: 6/0/0 default/read/poll queues [ 3.993297] nvme0n1: p1 p2 So there seems to be not some general failure. Does # ls /sys/devices/platform/f8000000.pcie list some "waiting_for_supplies" or something? _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-11 13:36 ` Heiko Stübner @ 2024-12-11 15:10 ` Vicente Bergas 2024-12-11 15:35 ` Heiko Stübner 0 siblings, 1 reply; 15+ messages in thread From: Vicente Bergas @ 2024-12-11 15:10 UTC (permalink / raw) To: Heiko Stübner; +Cc: open list:ARM/Rockchip SoC... On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: > > Hi Vicente, Hi Heiko, thanks for taking a look at it! > Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > > kernel version 6.12.3 works fine. > > > > 6.13 configuration is based on the same one as 6.12 and there aren't > > any significant PCI-related differences. > > > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > > > Does somebody know what is going on? > > so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the > pcie slot. And I get: > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 > ... > [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: > [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 > [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 > [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup > > So there seems to be not some general failure. > > Does > # ls /sys/devices/platform/f8000000.pcie > list some "waiting_for_supplies" or something? yes, indeed there is such a file in there: ### 6.13-rc2 $ ls /sys/devices/platform/f8000000.pcie power driver_override modalias of_node subsystem supplier:platform:ff720000.gpio supplier:platform:ff770000.syscon:pcie-phy supplier:platform:ff780000.gpio supplier:platform:pinctrl supplier:platform:regulator-pp3300-wifi-bt supplier:platform:regulator-wlan-pd-n uevent waiting_for_supplier $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier 1 ### 6.12.3 $ ls /sys/devices/platform/f8000000.pcie pci0000:00 power driver driver_override modalias of_node subsystem supplier:phy:phy-ff770000.syscon:pcie-phy.5 supplier:phy:phy-ff770000.syscon:pcie-phy.6 supplier:phy:phy-ff770000.syscon:pcie-phy.7 supplier:phy:phy-ff770000.syscon:pcie-phy.8 supplier:platform:ff770000.syscon:pcie-phy supplier:platform:ff780000.gpio supplier:platform:pinctrl supplier:platform:pp3300-wifi-bt supplier:platform:pp900-ap supplier:platform:wlan-pd-n supplier:regulator:regulator.17 supplier:regulator:regulator.23 supplier:regulator:regulator.25 uevent What does that mean? Regards, Vicente. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-11 15:10 ` Vicente Bergas @ 2024-12-11 15:35 ` Heiko Stübner 2024-12-11 17:31 ` Vicente Bergas 0 siblings, 1 reply; 15+ messages in thread From: Heiko Stübner @ 2024-12-11 15:35 UTC (permalink / raw) To: Vicente Bergas; +Cc: open list:ARM/Rockchip SoC... Am Mittwoch, 11. Dezember 2024, 16:10:21 CET schrieb Vicente Bergas: > On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > Hi Vicente, > > Hi Heiko, > thanks for taking a look at it! > > > Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > > > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > > > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > > > kernel version 6.12.3 works fine. > > > > > > 6.13 configuration is based on the same one as 6.12 and there aren't > > > any significant PCI-related differences. > > > > > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > > > > > Does somebody know what is going on? > > > > so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the > > pcie slot. And I get: > > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > > [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 > > ... > > [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: > > [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 > > [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 > > [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup > > > > So there seems to be not some general failure. > > > > Does > > # ls /sys/devices/platform/f8000000.pcie > > list some "waiting_for_supplies" or something? > > yes, indeed there is such a file in there: > > ### 6.13-rc2 > $ ls /sys/devices/platform/f8000000.pcie > power > driver_override > modalias > of_node > subsystem > supplier:platform:ff720000.gpio > supplier:platform:ff770000.syscon:pcie-phy > supplier:platform:ff780000.gpio > supplier:platform:pinctrl > supplier:platform:regulator-pp3300-wifi-bt > supplier:platform:regulator-wlan-pd-n > uevent > waiting_for_supplier > > $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier > 1 > > ### 6.12.3 > $ ls /sys/devices/platform/f8000000.pcie > pci0000:00 > power > driver > driver_override > modalias > of_node > subsystem > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > supplier:phy:phy-ff770000.syscon:pcie-phy.6 > supplier:phy:phy-ff770000.syscon:pcie-phy.7 > supplier:phy:phy-ff770000.syscon:pcie-phy.8 > supplier:platform:ff770000.syscon:pcie-phy > supplier:platform:ff780000.gpio > supplier:platform:pinctrl > supplier:platform:pp3300-wifi-bt > supplier:platform:pp900-ap > supplier:platform:wlan-pd-n > supplier:regulator:regulator.17 > supplier:regulator:regulator.23 > supplier:regulator:regulator.25 > uevent > > What does that mean? waiting_for_supplier means that some supplier has not yet probed and thus the driver also cannot probe yet. But your 6.13-rc2 supplier list does look way too short. In my boot on rk3399-puma-haikou above, I got: $ ls /sys/devices/platform/f8000000.pcie driver driver_override modalias of_node pci0000:00 power subsystem supplier:phy:phy-ff770000.syscon:pcie-phy.2 supplier:phy:phy-ff770000.syscon:pcie-phy.3 supplier:phy:phy-ff770000.syscon:pcie-phy.4 supplier:phy:phy-ff770000.syscon:pcie-phy.5 supplier:platform:ff770000.syscon:pcie-phy supplier:platform:ff790000.gpio supplier:platform:pinctrl supplier:platform:regulator-dc-12v supplier:platform:regulator-vcc3v3-baseboard supplier:platform:regulator-vcca-0v9 supplier:platform:regulator-vcca-1v8 supplier:regulator:regulator.10 supplier:regulator:regulator.11 supplier:regulator:regulator.29 supplier:regulator:regulator.3 uevent _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-11 15:35 ` Heiko Stübner @ 2024-12-11 17:31 ` Vicente Bergas 2024-12-12 12:12 ` Vicente Bergas 0 siblings, 1 reply; 15+ messages in thread From: Vicente Bergas @ 2024-12-11 17:31 UTC (permalink / raw) To: Heiko Stübner; +Cc: open list:ARM/Rockchip SoC... On Wed, Dec 11, 2024 at 4:35 PM Heiko Stübner <heiko@sntech.de> wrote: > > Am Mittwoch, 11. Dezember 2024, 16:10:21 CET schrieb Vicente Bergas: > > On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > Hi Vicente, > > > > Hi Heiko, > > thanks for taking a look at it! > > > > > Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > > > > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > > > > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > > > > kernel version 6.12.3 works fine. > > > > > > > > 6.13 configuration is based on the same one as 6.12 and there aren't > > > > any significant PCI-related differences. > > > > > > > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > > > > > > > Does somebody know what is going on? > > > > > > so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the > > > pcie slot. And I get: > > > > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > > > [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 > > > ... > > > [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: > > > [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 > > > [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 > > > [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup > > > > > > So there seems to be not some general failure. > > > > > > Does > > > # ls /sys/devices/platform/f8000000.pcie > > > list some "waiting_for_supplies" or something? > > > > yes, indeed there is such a file in there: > > > > ### 6.13-rc2 > > $ ls /sys/devices/platform/f8000000.pcie > > power > > driver_override > > modalias > > of_node > > subsystem > > supplier:platform:ff720000.gpio > > supplier:platform:ff770000.syscon:pcie-phy > > supplier:platform:ff780000.gpio > > supplier:platform:pinctrl > > supplier:platform:regulator-pp3300-wifi-bt > > supplier:platform:regulator-wlan-pd-n > > uevent > > waiting_for_supplier > > > > $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier > > 1 > > > > ### 6.12.3 > > $ ls /sys/devices/platform/f8000000.pcie > > pci0000:00 > > power > > driver > > driver_override > > modalias > > of_node > > subsystem > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > supplier:phy:phy-ff770000.syscon:pcie-phy.6 > > supplier:phy:phy-ff770000.syscon:pcie-phy.7 > > supplier:phy:phy-ff770000.syscon:pcie-phy.8 > > supplier:platform:ff770000.syscon:pcie-phy > > supplier:platform:ff780000.gpio > > supplier:platform:pinctrl > > supplier:platform:pp3300-wifi-bt > > supplier:platform:pp900-ap > > supplier:platform:wlan-pd-n > > supplier:regulator:regulator.17 > > supplier:regulator:regulator.23 > > supplier:regulator:regulator.25 > > uevent > > > > What does that mean? > > waiting_for_supplier means that some supplier has not yet probed > and thus the driver also cannot probe yet. > > But your 6.13-rc2 supplier list does look way too short. In my boot on > rk3399-puma-haikou above, I got: > > $ ls /sys/devices/platform/f8000000.pcie > driver > driver_override > modalias > of_node > pci0000:00 > power > subsystem > supplier:phy:phy-ff770000.syscon:pcie-phy.2 > supplier:phy:phy-ff770000.syscon:pcie-phy.3 > supplier:phy:phy-ff770000.syscon:pcie-phy.4 > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > supplier:platform:ff770000.syscon:pcie-phy > supplier:platform:ff790000.gpio > supplier:platform:pinctrl > supplier:platform:regulator-dc-12v > supplier:platform:regulator-vcc3v3-baseboard > supplier:platform:regulator-vcca-0v9 > supplier:platform:regulator-vcca-1v8 > supplier:regulator:regulator.10 > supplier:regulator:regulator.11 > supplier:regulator:regulator.29 > supplier:regulator:regulator.3 > uevent Just tested 6.13-rc2 with the DTB from 6.12.3 and it works fine. So, it is a DT issue. I suspect this commit may be the root cause: 5c96e63301978f4657c9082c55a066763c8db7b1 arm64: dts: rockchip: adapt regulator nodenames to preferred form _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-11 17:31 ` Vicente Bergas @ 2024-12-12 12:12 ` Vicente Bergas 2024-12-12 13:06 ` Heiko Stübner 2024-12-28 0:51 ` Vicente Bergas 0 siblings, 2 replies; 15+ messages in thread From: Vicente Bergas @ 2024-12-12 12:12 UTC (permalink / raw) To: Johan Jonker, Heiko Stübner; +Cc: open list:ARM/Rockchip SoC... On Wed, Dec 11, 2024 at 6:31 PM Vicente Bergas <vicencb@gmail.com> wrote: > > On Wed, Dec 11, 2024 at 4:35 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > Am Mittwoch, 11. Dezember 2024, 16:10:21 CET schrieb Vicente Bergas: > > > On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > > > Hi Vicente, > > > > > > Hi Heiko, > > > thanks for taking a look at it! > > > > > > > Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > > > > > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > > > > > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > > > > > kernel version 6.12.3 works fine. > > > > > > > > > > 6.13 configuration is based on the same one as 6.12 and there aren't > > > > > any significant PCI-related differences. > > > > > > > > > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > > > > > > > > > Does somebody know what is going on? > > > > > > > > so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the > > > > pcie slot. And I get: > > > > > > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > > > > [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 > > > > ... > > > > [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: > > > > [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 > > > > [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 > > > > [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup > > > > > > > > So there seems to be not some general failure. > > > > > > > > Does > > > > # ls /sys/devices/platform/f8000000.pcie > > > > list some "waiting_for_supplies" or something? > > > > > > yes, indeed there is such a file in there: > > > > > > ### 6.13-rc2 > > > $ ls /sys/devices/platform/f8000000.pcie > > > power > > > driver_override > > > modalias > > > of_node > > > subsystem > > > supplier:platform:ff720000.gpio > > > supplier:platform:ff770000.syscon:pcie-phy > > > supplier:platform:ff780000.gpio > > > supplier:platform:pinctrl > > > supplier:platform:regulator-pp3300-wifi-bt > > > supplier:platform:regulator-wlan-pd-n > > > uevent > > > waiting_for_supplier > > > > > > $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier > > > 1 > > > > > > ### 6.12.3 > > > $ ls /sys/devices/platform/f8000000.pcie > > > pci0000:00 > > > power > > > driver > > > driver_override > > > modalias > > > of_node > > > subsystem > > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.6 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.7 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.8 > > > supplier:platform:ff770000.syscon:pcie-phy > > > supplier:platform:ff780000.gpio > > > supplier:platform:pinctrl > > > supplier:platform:pp3300-wifi-bt > > > supplier:platform:pp900-ap > > > supplier:platform:wlan-pd-n > > > supplier:regulator:regulator.17 > > > supplier:regulator:regulator.23 > > > supplier:regulator:regulator.25 > > > uevent > > > > > > What does that mean? > > > > waiting_for_supplier means that some supplier has not yet probed > > and thus the driver also cannot probe yet. > > > > But your 6.13-rc2 supplier list does look way too short. In my boot on > > rk3399-puma-haikou above, I got: > > > > $ ls /sys/devices/platform/f8000000.pcie > > driver > > driver_override > > modalias > > of_node > > pci0000:00 > > power > > subsystem > > supplier:phy:phy-ff770000.syscon:pcie-phy.2 > > supplier:phy:phy-ff770000.syscon:pcie-phy.3 > > supplier:phy:phy-ff770000.syscon:pcie-phy.4 > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > supplier:platform:ff770000.syscon:pcie-phy > > supplier:platform:ff790000.gpio > > supplier:platform:pinctrl > > supplier:platform:regulator-dc-12v > > supplier:platform:regulator-vcc3v3-baseboard > > supplier:platform:regulator-vcca-0v9 > > supplier:platform:regulator-vcca-1v8 > > supplier:regulator:regulator.10 > > supplier:regulator:regulator.11 > > supplier:regulator:regulator.29 > > supplier:regulator:regulator.3 > > uevent > > Just tested 6.13-rc2 with the DTB from 6.12.3 and it works fine. So, > it is a DT issue. > I suspect this commit may be the root cause: > 5c96e63301978f4657c9082c55a066763c8db7b1 > arm64: dts: rockchip: adapt regulator nodenames to preferred form (Added: Johan Jonker) The 6.13-rc2 kernel with 5c96e63301978f4657c9082c55a066763c8db7b1 reverted works fine, i've just tested that to confirm. Regards, Vicente. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-12 12:12 ` Vicente Bergas @ 2024-12-12 13:06 ` Heiko Stübner 2024-12-12 16:50 ` Vicente Bergas 2024-12-28 0:51 ` Vicente Bergas 1 sibling, 1 reply; 15+ messages in thread From: Heiko Stübner @ 2024-12-12 13:06 UTC (permalink / raw) To: Johan Jonker, Vicente Bergas; +Cc: open list:ARM/Rockchip SoC... Am Donnerstag, 12. Dezember 2024, 13:12:22 CET schrieb Vicente Bergas: > On Wed, Dec 11, 2024 at 6:31 PM Vicente Bergas <vicencb@gmail.com> wrote: > > > > On Wed, Dec 11, 2024 at 4:35 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > Am Mittwoch, 11. Dezember 2024, 16:10:21 CET schrieb Vicente Bergas: > > > > On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > > > > > Hi Vicente, > > > > > > > > Hi Heiko, > > > > thanks for taking a look at it! > > > > > > > > > Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > > > > > > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > > > > > > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > > > > > > kernel version 6.12.3 works fine. > > > > > > > > > > > > 6.13 configuration is based on the same one as 6.12 and there aren't > > > > > > any significant PCI-related differences. > > > > > > > > > > > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > > > > > > > > > > > Does somebody know what is going on? > > > > > > > > > > so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the > > > > > pcie slot. And I get: > > > > > > > > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > > > > > [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 > > > > > ... > > > > > [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: > > > > > [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 > > > > > [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 > > > > > [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup > > > > > > > > > > So there seems to be not some general failure. > > > > > > > > > > Does > > > > > # ls /sys/devices/platform/f8000000.pcie > > > > > list some "waiting_for_supplies" or something? > > > > > > > > yes, indeed there is such a file in there: > > > > > > > > ### 6.13-rc2 > > > > $ ls /sys/devices/platform/f8000000.pcie > > > > power > > > > driver_override > > > > modalias > > > > of_node > > > > subsystem > > > > supplier:platform:ff720000.gpio > > > > supplier:platform:ff770000.syscon:pcie-phy > > > > supplier:platform:ff780000.gpio > > > > supplier:platform:pinctrl > > > > supplier:platform:regulator-pp3300-wifi-bt > > > > supplier:platform:regulator-wlan-pd-n > > > > uevent > > > > waiting_for_supplier > > > > > > > > $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier > > > > 1 > > > > > > > > ### 6.12.3 > > > > $ ls /sys/devices/platform/f8000000.pcie > > > > pci0000:00 > > > > power > > > > driver > > > > driver_override > > > > modalias > > > > of_node > > > > subsystem > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.6 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.7 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.8 > > > > supplier:platform:ff770000.syscon:pcie-phy > > > > supplier:platform:ff780000.gpio > > > > supplier:platform:pinctrl > > > > supplier:platform:pp3300-wifi-bt > > > > supplier:platform:pp900-ap > > > > supplier:platform:wlan-pd-n > > > > supplier:regulator:regulator.17 > > > > supplier:regulator:regulator.23 > > > > supplier:regulator:regulator.25 > > > > uevent > > > > > > > > What does that mean? > > > > > > waiting_for_supplier means that some supplier has not yet probed > > > and thus the driver also cannot probe yet. > > > > > > But your 6.13-rc2 supplier list does look way too short. In my boot on > > > rk3399-puma-haikou above, I got: > > > > > > $ ls /sys/devices/platform/f8000000.pcie > > > driver > > > driver_override > > > modalias > > > of_node > > > pci0000:00 > > > power > > > subsystem > > > supplier:phy:phy-ff770000.syscon:pcie-phy.2 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.3 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.4 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > > supplier:platform:ff770000.syscon:pcie-phy > > > supplier:platform:ff790000.gpio > > > supplier:platform:pinctrl > > > supplier:platform:regulator-dc-12v > > > supplier:platform:regulator-vcc3v3-baseboard > > > supplier:platform:regulator-vcca-0v9 > > > supplier:platform:regulator-vcca-1v8 > > > supplier:regulator:regulator.10 > > > supplier:regulator:regulator.11 > > > supplier:regulator:regulator.29 > > > supplier:regulator:regulator.3 > > > uevent > > > > Just tested 6.13-rc2 with the DTB from 6.12.3 and it works fine. So, > > it is a DT issue. > > I suspect this commit may be the root cause: > > 5c96e63301978f4657c9082c55a066763c8db7b1 > > arm64: dts: rockchip: adapt regulator nodenames to preferred form > > (Added: Johan Jonker) > > The 6.13-rc2 kernel with 5c96e63301978f4657c9082c55a066763c8db7b1 > reverted works fine, i've just tested that to confirm. though interestingly, in my test yesterday I used 6.13-rc2 kernel but including the 6.13-rc2 devicetree built from there. So that does not seem to be a general problem, but more limited to some boards. What board are you using? Heiko _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-12 13:06 ` Heiko Stübner @ 2024-12-12 16:50 ` Vicente Bergas 0 siblings, 0 replies; 15+ messages in thread From: Vicente Bergas @ 2024-12-12 16:50 UTC (permalink / raw) To: Heiko Stübner; +Cc: Johan Jonker, open list:ARM/Rockchip SoC... On Thu, Dec 12, 2024 at 2:06 PM Heiko Stübner <heiko@sntech.de> wrote: > > Am Donnerstag, 12. Dezember 2024, 13:12:22 CET schrieb Vicente Bergas: > > On Wed, Dec 11, 2024 at 6:31 PM Vicente Bergas <vicencb@gmail.com> wrote: > > > > > > On Wed, Dec 11, 2024 at 4:35 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > > > Am Mittwoch, 11. Dezember 2024, 16:10:21 CET schrieb Vicente Bergas: > > > > > On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > > > > > > > Hi Vicente, > > > > > > > > > > Hi Heiko, > > > > > thanks for taking a look at it! > > > > > > > > > > > Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > > > > > > > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > > > > > > > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > > > > > > > kernel version 6.12.3 works fine. > > > > > > > > > > > > > > 6.13 configuration is based on the same one as 6.12 and there aren't > > > > > > > any significant PCI-related differences. > > > > > > > > > > > > > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > > > > > > > > > > > > > Does somebody know what is going on? > > > > > > > > > > > > so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the > > > > > > pcie slot. And I get: > > > > > > > > > > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > > > > > > [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 > > > > > > ... > > > > > > [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: > > > > > > [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 > > > > > > [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 > > > > > > [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup > > > > > > > > > > > > So there seems to be not some general failure. > > > > > > > > > > > > Does > > > > > > # ls /sys/devices/platform/f8000000.pcie > > > > > > list some "waiting_for_supplies" or something? > > > > > > > > > > yes, indeed there is such a file in there: > > > > > > > > > > ### 6.13-rc2 > > > > > $ ls /sys/devices/platform/f8000000.pcie > > > > > power > > > > > driver_override > > > > > modalias > > > > > of_node > > > > > subsystem > > > > > supplier:platform:ff720000.gpio > > > > > supplier:platform:ff770000.syscon:pcie-phy > > > > > supplier:platform:ff780000.gpio > > > > > supplier:platform:pinctrl > > > > > supplier:platform:regulator-pp3300-wifi-bt > > > > > supplier:platform:regulator-wlan-pd-n > > > > > uevent > > > > > waiting_for_supplier > > > > > > > > > > $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier > > > > > 1 > > > > > > > > > > ### 6.12.3 > > > > > $ ls /sys/devices/platform/f8000000.pcie > > > > > pci0000:00 > > > > > power > > > > > driver > > > > > driver_override > > > > > modalias > > > > > of_node > > > > > subsystem > > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.6 > > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.7 > > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.8 > > > > > supplier:platform:ff770000.syscon:pcie-phy > > > > > supplier:platform:ff780000.gpio > > > > > supplier:platform:pinctrl > > > > > supplier:platform:pp3300-wifi-bt > > > > > supplier:platform:pp900-ap > > > > > supplier:platform:wlan-pd-n > > > > > supplier:regulator:regulator.17 > > > > > supplier:regulator:regulator.23 > > > > > supplier:regulator:regulator.25 > > > > > uevent > > > > > > > > > > What does that mean? > > > > > > > > waiting_for_supplier means that some supplier has not yet probed > > > > and thus the driver also cannot probe yet. > > > > > > > > But your 6.13-rc2 supplier list does look way too short. In my boot on > > > > rk3399-puma-haikou above, I got: > > > > > > > > $ ls /sys/devices/platform/f8000000.pcie > > > > driver > > > > driver_override > > > > modalias > > > > of_node > > > > pci0000:00 > > > > power > > > > subsystem > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.2 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.3 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.4 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > > > supplier:platform:ff770000.syscon:pcie-phy > > > > supplier:platform:ff790000.gpio > > > > supplier:platform:pinctrl > > > > supplier:platform:regulator-dc-12v > > > > supplier:platform:regulator-vcc3v3-baseboard > > > > supplier:platform:regulator-vcca-0v9 > > > > supplier:platform:regulator-vcca-1v8 > > > > supplier:regulator:regulator.10 > > > > supplier:regulator:regulator.11 > > > > supplier:regulator:regulator.29 > > > > supplier:regulator:regulator.3 > > > > uevent > > > > > > Just tested 6.13-rc2 with the DTB from 6.12.3 and it works fine. So, > > > it is a DT issue. > > > I suspect this commit may be the root cause: > > > 5c96e63301978f4657c9082c55a066763c8db7b1 > > > arm64: dts: rockchip: adapt regulator nodenames to preferred form > > > > (Added: Johan Jonker) > > > > The 6.13-rc2 kernel with 5c96e63301978f4657c9082c55a066763c8db7b1 > > reverted works fine, i've just tested that to confirm. > > though interestingly, in my test yesterday I used 6.13-rc2 kernel but > including the 6.13-rc2 devicetree built from there. So that does not seem > to be a general problem, but more limited to some boards. > > What board are you using? The rk3399-gru-kevin chromebook. The wifi card is connected to the PCIe bus. > Heiko _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-12 12:12 ` Vicente Bergas 2024-12-12 13:06 ` Heiko Stübner @ 2024-12-28 0:51 ` Vicente Bergas 2024-12-28 9:35 ` Johan Jonker 1 sibling, 1 reply; 15+ messages in thread From: Vicente Bergas @ 2024-12-28 0:51 UTC (permalink / raw) To: Johan Jonker, Heiko Stübner; +Cc: open list:ARM/Rockchip SoC... On Thu, Dec 12, 2024 at 1:12 PM Vicente Bergas <vicencb@gmail.com> wrote: > > On Wed, Dec 11, 2024 at 6:31 PM Vicente Bergas <vicencb@gmail.com> wrote: > > > > On Wed, Dec 11, 2024 at 4:35 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > Am Mittwoch, 11. Dezember 2024, 16:10:21 CET schrieb Vicente Bergas: > > > > On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: > > > > > > > > > > Hi Vicente, > > > > > > > > Hi Heiko, > > > > thanks for taking a look at it! > > > > > > > > > Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: > > > > > > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > > > > > > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > > > > > > kernel version 6.12.3 works fine. > > > > > > > > > > > > 6.13 configuration is based on the same one as 6.12 and there aren't > > > > > > any significant PCI-related differences. > > > > > > > > > > > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > > > > > > > > > > > Does somebody know what is going on? > > > > > > > > > > so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the > > > > > pcie slot. And I get: > > > > > > > > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > > > > > [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 > > > > > ... > > > > > [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: > > > > > [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 > > > > > [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 > > > > > [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup > > > > > > > > > > So there seems to be not some general failure. > > > > > > > > > > Does > > > > > # ls /sys/devices/platform/f8000000.pcie > > > > > list some "waiting_for_supplies" or something? > > > > > > > > yes, indeed there is such a file in there: > > > > > > > > ### 6.13-rc2 > > > > $ ls /sys/devices/platform/f8000000.pcie > > > > power > > > > driver_override > > > > modalias > > > > of_node > > > > subsystem > > > > supplier:platform:ff720000.gpio > > > > supplier:platform:ff770000.syscon:pcie-phy > > > > supplier:platform:ff780000.gpio > > > > supplier:platform:pinctrl > > > > supplier:platform:regulator-pp3300-wifi-bt > > > > supplier:platform:regulator-wlan-pd-n > > > > uevent > > > > waiting_for_supplier > > > > > > > > $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier > > > > 1 > > > > > > > > ### 6.12.3 > > > > $ ls /sys/devices/platform/f8000000.pcie > > > > pci0000:00 > > > > power > > > > driver > > > > driver_override > > > > modalias > > > > of_node > > > > subsystem > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.6 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.7 > > > > supplier:phy:phy-ff770000.syscon:pcie-phy.8 > > > > supplier:platform:ff770000.syscon:pcie-phy > > > > supplier:platform:ff780000.gpio > > > > supplier:platform:pinctrl > > > > supplier:platform:pp3300-wifi-bt > > > > supplier:platform:pp900-ap > > > > supplier:platform:wlan-pd-n > > > > supplier:regulator:regulator.17 > > > > supplier:regulator:regulator.23 > > > > supplier:regulator:regulator.25 > > > > uevent > > > > > > > > What does that mean? > > > > > > waiting_for_supplier means that some supplier has not yet probed > > > and thus the driver also cannot probe yet. > > > > > > But your 6.13-rc2 supplier list does look way too short. In my boot on > > > rk3399-puma-haikou above, I got: > > > > > > $ ls /sys/devices/platform/f8000000.pcie > > > driver > > > driver_override > > > modalias > > > of_node > > > pci0000:00 > > > power > > > subsystem > > > supplier:phy:phy-ff770000.syscon:pcie-phy.2 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.3 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.4 > > > supplier:phy:phy-ff770000.syscon:pcie-phy.5 > > > supplier:platform:ff770000.syscon:pcie-phy > > > supplier:platform:ff790000.gpio > > > supplier:platform:pinctrl > > > supplier:platform:regulator-dc-12v > > > supplier:platform:regulator-vcc3v3-baseboard > > > supplier:platform:regulator-vcca-0v9 > > > supplier:platform:regulator-vcca-1v8 > > > supplier:regulator:regulator.10 > > > supplier:regulator:regulator.11 > > > supplier:regulator:regulator.29 > > > supplier:regulator:regulator.3 > > > uevent > > > > Just tested 6.13-rc2 with the DTB from 6.12.3 and it works fine. So, > > it is a DT issue. > > I suspect this commit may be the root cause: > > 5c96e63301978f4657c9082c55a066763c8db7b1 > > arm64: dts: rockchip: adapt regulator nodenames to preferred form > > (Added: Johan Jonker) > > The 6.13-rc2 kernel with 5c96e63301978f4657c9082c55a066763c8db7b1 > reverted works fine, i've just tested that to confirm. > > Regards, > Vicente. Hello, i've applied this patch and it is now working for me. Please, can you check it? (DTS is not a language i am fluent with). If it is fine, i can send a proper patch with `git send-email`. --- Follow up from 5c96e63301978f4657c9082c55a066763c8db7b1: Fix more Rockchip DT regulator nodenames. diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi index 988e6ca32fac..a9ea4b0daa04 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi @@ -22,11 +22,11 @@ pp900_ap: regulator-pp900-ap { }; /* EC turns on w/ pp900_usb_en */ - pp900_usb: pp900-ap { + pp900_usb: regulator-pp900-ap { }; /* EC turns on w/ pp900_pcie_en */ - pp900_pcie: pp900-ap { + pp900_pcie: regulator-pp900-ap { }; pp3000: regulator-pp3000 { @@ -126,7 +126,7 @@ pp1800_pcie: regulator-pp1800-pcie { }; /* Always on; plain and simple */ - pp3000_ap: pp3000_emmc: pp3000 { + pp3000_ap: pp3000_emmc: regulator-pp3000 { }; pp1500_ap_io: regulator-pp1500-ap-io { @@ -160,7 +160,7 @@ pp3300_disp: regulator-pp3300-disp { }; /* EC turns on w/ pp3300_usb_en_l */ - pp3300_usb: pp3300 { + pp3300_usb: regulator-pp3300 { }; /* gpio is shared with pp1800_pcie and pinctrl is set there */ diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi index 6d9e60b01225..1a470c519db1 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi @@ -189,39 +189,39 @@ ppvar_gpu: ppvar-gpu { }; /* EC turns on w/ pp900_ddrpll_en */ - pp900_ddrpll: pp900-ap { + pp900_ddrpll: regulator-pp900-ap { }; /* EC turns on w/ pp900_pll_en */ - pp900_pll: pp900-ap { + pp900_pll: regulator-pp900-ap { }; /* EC turns on w/ pp900_pmu_en */ - pp900_pmu: pp900-ap { + pp900_pmu: regulator-pp900-ap { }; /* EC turns on w/ pp1800_s0_en_l */ - pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: pp1800 { + pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: regulator-pp1800 { }; /* EC turns on w/ pp1800_avdd_en_l */ - pp1800_avdd: pp1800 { + pp1800_avdd: regulator-pp1800 { }; /* EC turns on w/ pp1800_lid_en_l */ - pp1800_lid: pp1800_mic: pp1800 { + pp1800_lid: pp1800_mic: regulator-pp1800 { }; /* EC turns on w/ lpddr_pwr_en */ - pp1800_lpddr: pp1800 { + pp1800_lpddr: regulator-pp1800 { }; /* EC turns on w/ pp1800_pmu_en_l */ - pp1800_pmu: pp1800 { + pp1800_pmu: regulator-pp1800 { }; /* EC turns on w/ pp1800_usb_en_l */ - pp1800_usb: pp1800 { + pp1800_usb: regulator-pp1800 { }; pp3000_sd_slot: regulator-pp3000-sd-slot { @@ -263,7 +263,7 @@ pp3300_trackpad: pp3300-trackpad { }; /* EC turns on w/ usb_a_en */ - pp5000_usb_a_vbus: pp5000 { + pp5000_usb_a_vbus: regulator-pp5000 { }; ap_rtc_clk: ap-rtc-clk { _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-28 0:51 ` Vicente Bergas @ 2024-12-28 9:35 ` Johan Jonker 2025-01-13 21:02 ` Vicente Bergas 0 siblings, 1 reply; 15+ messages in thread From: Johan Jonker @ 2024-12-28 9:35 UTC (permalink / raw) To: Vicente Bergas, Heiko Stübner; +Cc: open list:ARM/Rockchip SoC... On 12/28/24 01:51, Vicente Bergas wrote: > On Thu, Dec 12, 2024 at 1:12 PM Vicente Bergas <vicencb@gmail.com> wrote: >> >> On Wed, Dec 11, 2024 at 6:31 PM Vicente Bergas <vicencb@gmail.com> wrote: >>> >>> On Wed, Dec 11, 2024 at 4:35 PM Heiko Stübner <heiko@sntech.de> wrote: >>>> >>>> Am Mittwoch, 11. Dezember 2024, 16:10:21 CET schrieb Vicente Bergas: >>>>> On Wed, Dec 11, 2024 at 2:36 PM Heiko Stübner <heiko@sntech.de> wrote: >>>>>> >>>>>> Hi Vicente, >>>>> >>>>> Hi Heiko, >>>>> thanks for taking a look at it! >>>>> >>>>>> Am Mittwoch, 11. Dezember 2024, 13:55:01 CET schrieb Vicente Bergas: >>>>>>> i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe >>>>>>> is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the >>>>>>> kernel version 6.12.3 works fine. >>>>>>> >>>>>>> 6.13 configuration is based on the same one as 6.12 and there aren't >>>>>>> any significant PCI-related differences. >>>>>>> >>>>>>> The messages from dmesg on 6.13 don't show any PCI-related errors. >>>>>>> >>>>>>> Does somebody know what is going on? >>>>>> >>>>>> so I just booted a rk3399-puma-haikou with a pci-nvme-adapter in the >>>>>> pcie slot. And I get: >>>>>> >>>>>> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] >>>>>> [ 0.000000] Linux version 6.13.0-rc2-00101-g260ae63734ff-dirty (hstuebner@phil) (aarch64-linux-gnu-gcc (Debian 14.2.0-6) 14.2.0, GNU ld (GNU Binutils for Debian) 2.43.1) #1134 SMP PREEMPT Tue Dec 10 21:06:34 CET 2024 >>>>>> ... >>>>>> [ 3.428114] rockchip-pcie f8000000.pcie: host bridge /pcie@f8000000 ranges: >>>>>> [ 3.435978] rockchip-pcie f8000000.pcie: MEM 0x00fa000000..0x00fbdfffff -> 0x00fa000000 >>>>>> [ 3.445478] rockchip-pcie f8000000.pcie: IO 0x00fbe00000..0x00fbefffff -> 0x00fbe00000 >>>>>> [ 3.455298] rockchip-pcie f8000000.pcie: using DT '/pcie@f8000000' for 'ep' GPIO lookup >>>>>> >>>>>> So there seems to be not some general failure. >>>>>> >>>>>> Does >>>>>> # ls /sys/devices/platform/f8000000.pcie >>>>>> list some "waiting_for_supplies" or something? >>>>> >>>>> yes, indeed there is such a file in there: >>>>> >>>>> ### 6.13-rc2 >>>>> $ ls /sys/devices/platform/f8000000.pcie >>>>> power >>>>> driver_override >>>>> modalias >>>>> of_node >>>>> subsystem >>>>> supplier:platform:ff720000.gpio >>>>> supplier:platform:ff770000.syscon:pcie-phy >>>>> supplier:platform:ff780000.gpio >>>>> supplier:platform:pinctrl >>>>> supplier:platform:regulator-pp3300-wifi-bt >>>>> supplier:platform:regulator-wlan-pd-n >>>>> uevent >>>>> waiting_for_supplier >>>>> >>>>> $ cat /sys/devices/platform/f8000000.pcie/waiting_for_supplier >>>>> 1 >>>>> >>>>> ### 6.12.3 >>>>> $ ls /sys/devices/platform/f8000000.pcie >>>>> pci0000:00 >>>>> power >>>>> driver >>>>> driver_override >>>>> modalias >>>>> of_node >>>>> subsystem >>>>> supplier:phy:phy-ff770000.syscon:pcie-phy.5 >>>>> supplier:phy:phy-ff770000.syscon:pcie-phy.6 >>>>> supplier:phy:phy-ff770000.syscon:pcie-phy.7 >>>>> supplier:phy:phy-ff770000.syscon:pcie-phy.8 >>>>> supplier:platform:ff770000.syscon:pcie-phy >>>>> supplier:platform:ff780000.gpio >>>>> supplier:platform:pinctrl >>>>> supplier:platform:pp3300-wifi-bt >>>>> supplier:platform:pp900-ap >>>>> supplier:platform:wlan-pd-n >>>>> supplier:regulator:regulator.17 >>>>> supplier:regulator:regulator.23 >>>>> supplier:regulator:regulator.25 >>>>> uevent >>>>> >>>>> What does that mean? >>>> >>>> waiting_for_supplier means that some supplier has not yet probed >>>> and thus the driver also cannot probe yet. >>>> >>>> But your 6.13-rc2 supplier list does look way too short. In my boot on >>>> rk3399-puma-haikou above, I got: >>>> >>>> $ ls /sys/devices/platform/f8000000.pcie >>>> driver >>>> driver_override >>>> modalias >>>> of_node >>>> pci0000:00 >>>> power >>>> subsystem >>>> supplier:phy:phy-ff770000.syscon:pcie-phy.2 >>>> supplier:phy:phy-ff770000.syscon:pcie-phy.3 >>>> supplier:phy:phy-ff770000.syscon:pcie-phy.4 >>>> supplier:phy:phy-ff770000.syscon:pcie-phy.5 >>>> supplier:platform:ff770000.syscon:pcie-phy >>>> supplier:platform:ff790000.gpio >>>> supplier:platform:pinctrl >>>> supplier:platform:regulator-dc-12v >>>> supplier:platform:regulator-vcc3v3-baseboard >>>> supplier:platform:regulator-vcca-0v9 >>>> supplier:platform:regulator-vcca-1v8 >>>> supplier:regulator:regulator.10 >>>> supplier:regulator:regulator.11 >>>> supplier:regulator:regulator.29 >>>> supplier:regulator:regulator.3 >>>> uevent >>> >>> Just tested 6.13-rc2 with the DTB from 6.12.3 and it works fine. So, >>> it is a DT issue. >>> I suspect this commit may be the root cause: >>> 5c96e63301978f4657c9082c55a066763c8db7b1 >>> arm64: dts: rockchip: adapt regulator nodenames to preferred form >> >> (Added: Johan Jonker) Hi, I used a script to find regulator nodes. Due to the strange external construction these nodes were missed. Question for Heiko: Now that we touch them do you want to keep it this way or combine them? Johan >> >> The 6.13-rc2 kernel with 5c96e63301978f4657c9082c55a066763c8db7b1 >> reverted works fine, i've just tested that to confirm. >> >> Regards, >> Vicente. > > Hello, > i've applied this patch and it is now working for me. > Please, can you check it? (DTS is not a language i am fluent with). > If it is fine, i can send a proper patch with `git send-email`. > > --- > > Follow up from 5c96e63301978f4657c9082c55a066763c8db7b1: > Fix more Rockchip DT regulator nodenames. > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > index 988e6ca32fac..a9ea4b0daa04 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > @@ -22,11 +22,11 @@ pp900_ap: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_usb_en */ > - pp900_usb: pp900-ap { > + pp900_usb: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_pcie_en */ > - pp900_pcie: pp900-ap { > + pp900_pcie: regulator-pp900-ap { > }; > > pp3000: regulator-pp3000 { > @@ -126,7 +126,7 @@ pp1800_pcie: regulator-pp1800-pcie { > }; > > /* Always on; plain and simple */ > - pp3000_ap: pp3000_emmc: pp3000 { > + pp3000_ap: pp3000_emmc: regulator-pp3000 { > }; > > pp1500_ap_io: regulator-pp1500-ap-io { > @@ -160,7 +160,7 @@ pp3300_disp: regulator-pp3300-disp { > }; > > /* EC turns on w/ pp3300_usb_en_l */ > - pp3300_usb: pp3300 { > + pp3300_usb: regulator-pp3300 { > }; > > /* gpio is shared with pp1800_pcie and pinctrl is set there */ > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > index 6d9e60b01225..1a470c519db1 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > @@ -189,39 +189,39 @@ ppvar_gpu: ppvar-gpu { > }; > > /* EC turns on w/ pp900_ddrpll_en */ > - pp900_ddrpll: pp900-ap { > + pp900_ddrpll: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_pll_en */ > - pp900_pll: pp900-ap { > + pp900_pll: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_pmu_en */ > - pp900_pmu: pp900-ap { > + pp900_pmu: regulator-pp900-ap { > }; > > /* EC turns on w/ pp1800_s0_en_l */ > - pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: pp1800 { > + pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_avdd_en_l */ > - pp1800_avdd: pp1800 { > + pp1800_avdd: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_lid_en_l */ > - pp1800_lid: pp1800_mic: pp1800 { > + pp1800_lid: pp1800_mic: regulator-pp1800 { > }; > > /* EC turns on w/ lpddr_pwr_en */ > - pp1800_lpddr: pp1800 { > + pp1800_lpddr: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_pmu_en_l */ > - pp1800_pmu: pp1800 { > + pp1800_pmu: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_usb_en_l */ > - pp1800_usb: pp1800 { > + pp1800_usb: regulator-pp1800 { > }; > > pp3000_sd_slot: regulator-pp3000-sd-slot { > @@ -263,7 +263,7 @@ pp3300_trackpad: pp3300-trackpad { > }; > > /* EC turns on w/ usb_a_en */ > - pp5000_usb_a_vbus: pp5000 { > + pp5000_usb_a_vbus: regulator-pp5000 { > }; > > ap_rtc_clk: ap-rtc-clk { _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-28 9:35 ` Johan Jonker @ 2025-01-13 21:02 ` Vicente Bergas 2025-01-16 14:36 ` [PATCH] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices Heiko Stuebner 0 siblings, 1 reply; 15+ messages in thread From: Vicente Bergas @ 2025-01-13 21:02 UTC (permalink / raw) To: Johan Jonker; +Cc: Heiko Stübner, open list:ARM/Rockchip SoC... On Sat, Dec 28, 2024 at 10:35 AM Johan Jonker <jbx6244@gmail.com> wrote: > Hi, > > I used a script to find regulator nodes. > Due to the strange external construction these nodes were missed. > Question for Heiko: > Now that we touch them do you want to keep it this way or combine them? > > Johan Hi Johan, Heiko, any progress with this issue? Regards, Vicente. _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices 2025-01-13 21:02 ` Vicente Bergas @ 2025-01-16 14:36 ` Heiko Stuebner 2025-01-17 0:44 ` Vicente Bergas 2025-02-03 8:15 ` Heiko Stuebner 0 siblings, 2 replies; 15+ messages in thread From: Heiko Stuebner @ 2025-01-16 14:36 UTC (permalink / raw) To: vicencb; +Cc: jbx6244, linux-rockchip, Heiko Stuebner rk3399-gru chromebooks have a regulator chains where one named regulator supplies multiple regulators pp900-usb pp900_pcie that supply the named peripherals. The dtsi used somewhat creative structure to describe that in creating the base node 3 times with different phandles and describing the EC dependency in a comment. This didn't register in the recent regulator-node renaming, as the additional nodes were empty, so adapt the missing node names for now. Fixes: 5c96e6330197 ("arm64: dts: rockchip: adapt regulator nodenames to preferred form") Signed-off-by: Heiko Stuebner <heiko@sntech.de> --- Hi Vicente, in theory, this should fix your issue? While we may want to restructure those regulators in some way, this below should be the smaller change to include as a fix. Heiko .../dts/rockchip/rk3399-gru-chromebook.dtsi | 8 +++---- .../boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 6 ++--- arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 22 +++++++++---------- 3 files changed, 18 insertions(+), 18 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi index 988e6ca32fac..a9ea4b0daa04 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi @@ -22,11 +22,11 @@ pp900_ap: regulator-pp900-ap { }; /* EC turns on w/ pp900_usb_en */ - pp900_usb: pp900-ap { + pp900_usb: regulator-pp900-ap { }; /* EC turns on w/ pp900_pcie_en */ - pp900_pcie: pp900-ap { + pp900_pcie: regulator-pp900-ap { }; pp3000: regulator-pp3000 { @@ -126,7 +126,7 @@ pp1800_pcie: regulator-pp1800-pcie { }; /* Always on; plain and simple */ - pp3000_ap: pp3000_emmc: pp3000 { + pp3000_ap: pp3000_emmc: regulator-pp3000 { }; pp1500_ap_io: regulator-pp1500-ap-io { @@ -160,7 +160,7 @@ pp3300_disp: regulator-pp3300-disp { }; /* EC turns on w/ pp3300_usb_en_l */ - pp3300_usb: pp3300 { + pp3300_usb: regulator-pp3300 { }; /* gpio is shared with pp1800_pcie and pinctrl is set there */ diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi index 19b23b438965..5e068377a0a2 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi @@ -92,7 +92,7 @@ pp900_s3: regulator-pp900-s3 { }; /* EC turns on pp1800_s3_en */ - pp1800_s3: pp1800 { + pp1800_s3: regulator-pp1800 { }; /* pp3300 children, sorted by name */ @@ -109,11 +109,11 @@ pp2800_cam: regulator-pp2800-avdd { }; /* EC turns on pp3300_s0_en */ - pp3300_s0: pp3300 { + pp3300_s0: regulator-pp3300 { }; /* EC turns on pp3300_s3_en */ - pp3300_s3: pp3300 { + pp3300_s3: regulator-pp3300 { }; /* diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi index 6d9e60b01225..7eca1da78cff 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi @@ -189,39 +189,39 @@ ppvar_gpu: ppvar-gpu { }; /* EC turns on w/ pp900_ddrpll_en */ - pp900_ddrpll: pp900-ap { + pp900_ddrpll: regulator-pp900-ap { }; /* EC turns on w/ pp900_pll_en */ - pp900_pll: pp900-ap { + pp900_pll: regulator-pp900-ap { }; /* EC turns on w/ pp900_pmu_en */ - pp900_pmu: pp900-ap { + pp900_pmu: regulator-pp900-ap { }; /* EC turns on w/ pp1800_s0_en_l */ - pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: pp1800 { + pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: regulator-pp1800 { }; /* EC turns on w/ pp1800_avdd_en_l */ - pp1800_avdd: pp1800 { + pp1800_avdd: regulator-pp1800 { }; /* EC turns on w/ pp1800_lid_en_l */ - pp1800_lid: pp1800_mic: pp1800 { + pp1800_lid: pp1800_mic: regulator-pp1800 { }; /* EC turns on w/ lpddr_pwr_en */ - pp1800_lpddr: pp1800 { + pp1800_lpddr: regulator-pp1800 { }; /* EC turns on w/ pp1800_pmu_en_l */ - pp1800_pmu: pp1800 { + pp1800_pmu: regulator-pp1800 { }; /* EC turns on w/ pp1800_usb_en_l */ - pp1800_usb: pp1800 { + pp1800_usb: regulator-pp1800 { }; pp3000_sd_slot: regulator-pp3000-sd-slot { @@ -259,11 +259,11 @@ ppvar_sd_card_io: ppvar-sd-card-io { }; /* EC turns on w/ pp3300_trackpad_en_l */ - pp3300_trackpad: pp3300-trackpad { + pp3300_trackpad: regulator-pp3300-trackpad { }; /* EC turns on w/ usb_a_en */ - pp5000_usb_a_vbus: pp5000 { + pp5000_usb_a_vbus: regulator-pp5000 { }; ap_rtc_clk: ap-rtc-clk { -- 2.45.2 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices 2025-01-16 14:36 ` [PATCH] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices Heiko Stuebner @ 2025-01-17 0:44 ` Vicente Bergas 2025-02-03 8:15 ` Heiko Stuebner 1 sibling, 0 replies; 15+ messages in thread From: Vicente Bergas @ 2025-01-17 0:44 UTC (permalink / raw) To: Heiko Stuebner; +Cc: jbx6244, linux-rockchip On Thu, Jan 16, 2025 at 3:36 PM Heiko Stuebner <heiko@sntech.de> wrote: > > rk3399-gru chromebooks have a regulator chains where one named regulator > supplies multiple regulators pp900-usb pp900_pcie that supply > the named peripherals. > > The dtsi used somewhat creative structure to describe that in creating > the base node 3 times with different phandles and describing the EC > dependency in a comment. > > This didn't register in the recent regulator-node renaming, as the > additional nodes were empty, so adapt the missing node names for now. > > Fixes: 5c96e6330197 ("arm64: dts: rockchip: adapt regulator nodenames to preferred form") > Signed-off-by: Heiko Stuebner <heiko@sntech.de> > --- > Hi Vicente, > > in theory, this should fix your issue? > > While we may want to restructure those regulators in some way, > this below should be the smaller change to include as a fix. > > > Heiko Thanks Heiko! Just now i am testing it on gru-kevin and it works, so: Tested-by: Vicente Bergas <vicencb@gmail.com> Regards, Vicente. > .../dts/rockchip/rk3399-gru-chromebook.dtsi | 8 +++---- > .../boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 6 ++--- > arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 22 +++++++++---------- > 3 files changed, 18 insertions(+), 18 deletions(-) > > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > index 988e6ca32fac..a9ea4b0daa04 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-chromebook.dtsi > @@ -22,11 +22,11 @@ pp900_ap: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_usb_en */ > - pp900_usb: pp900-ap { > + pp900_usb: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_pcie_en */ > - pp900_pcie: pp900-ap { > + pp900_pcie: regulator-pp900-ap { > }; > > pp3000: regulator-pp3000 { > @@ -126,7 +126,7 @@ pp1800_pcie: regulator-pp1800-pcie { > }; > > /* Always on; plain and simple */ > - pp3000_ap: pp3000_emmc: pp3000 { > + pp3000_ap: pp3000_emmc: regulator-pp3000 { > }; > > pp1500_ap_io: regulator-pp1500-ap-io { > @@ -160,7 +160,7 @@ pp3300_disp: regulator-pp3300-disp { > }; > > /* EC turns on w/ pp3300_usb_en_l */ > - pp3300_usb: pp3300 { > + pp3300_usb: regulator-pp3300 { > }; > > /* gpio is shared with pp1800_pcie and pinctrl is set there */ > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > index 19b23b438965..5e068377a0a2 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet.dtsi > @@ -92,7 +92,7 @@ pp900_s3: regulator-pp900-s3 { > }; > > /* EC turns on pp1800_s3_en */ > - pp1800_s3: pp1800 { > + pp1800_s3: regulator-pp1800 { > }; > > /* pp3300 children, sorted by name */ > @@ -109,11 +109,11 @@ pp2800_cam: regulator-pp2800-avdd { > }; > > /* EC turns on pp3300_s0_en */ > - pp3300_s0: pp3300 { > + pp3300_s0: regulator-pp3300 { > }; > > /* EC turns on pp3300_s3_en */ > - pp3300_s3: pp3300 { > + pp3300_s3: regulator-pp3300 { > }; > > /* > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > index 6d9e60b01225..7eca1da78cff 100644 > --- a/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > +++ b/arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi > @@ -189,39 +189,39 @@ ppvar_gpu: ppvar-gpu { > }; > > /* EC turns on w/ pp900_ddrpll_en */ > - pp900_ddrpll: pp900-ap { > + pp900_ddrpll: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_pll_en */ > - pp900_pll: pp900-ap { > + pp900_pll: regulator-pp900-ap { > }; > > /* EC turns on w/ pp900_pmu_en */ > - pp900_pmu: pp900-ap { > + pp900_pmu: regulator-pp900-ap { > }; > > /* EC turns on w/ pp1800_s0_en_l */ > - pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: pp1800 { > + pp1800_ap_io: pp1800_emmc: pp1800_nfc: pp1800_s0: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_avdd_en_l */ > - pp1800_avdd: pp1800 { > + pp1800_avdd: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_lid_en_l */ > - pp1800_lid: pp1800_mic: pp1800 { > + pp1800_lid: pp1800_mic: regulator-pp1800 { > }; > > /* EC turns on w/ lpddr_pwr_en */ > - pp1800_lpddr: pp1800 { > + pp1800_lpddr: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_pmu_en_l */ > - pp1800_pmu: pp1800 { > + pp1800_pmu: regulator-pp1800 { > }; > > /* EC turns on w/ pp1800_usb_en_l */ > - pp1800_usb: pp1800 { > + pp1800_usb: regulator-pp1800 { > }; > > pp3000_sd_slot: regulator-pp3000-sd-slot { > @@ -259,11 +259,11 @@ ppvar_sd_card_io: ppvar-sd-card-io { > }; > > /* EC turns on w/ pp3300_trackpad_en_l */ > - pp3300_trackpad: pp3300-trackpad { > + pp3300_trackpad: regulator-pp3300-trackpad { > }; > > /* EC turns on w/ usb_a_en */ > - pp5000_usb_a_vbus: pp5000 { > + pp5000_usb_a_vbus: regulator-pp5000 { > }; > > ap_rtc_clk: ap-rtc-clk { > -- > 2.45.2 > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices 2025-01-16 14:36 ` [PATCH] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices Heiko Stuebner 2025-01-17 0:44 ` Vicente Bergas @ 2025-02-03 8:15 ` Heiko Stuebner 1 sibling, 0 replies; 15+ messages in thread From: Heiko Stuebner @ 2025-02-03 8:15 UTC (permalink / raw) To: vicencb, Heiko Stuebner; +Cc: jbx6244, linux-rockchip On Thu, 16 Jan 2025 15:36:31 +0100, Heiko Stuebner wrote: > rk3399-gru chromebooks have a regulator chains where one named regulator > supplies multiple regulators pp900-usb pp900_pcie that supply > the named peripherals. > > The dtsi used somewhat creative structure to describe that in creating > the base node 3 times with different phandles and describing the EC > dependency in a comment. > > [...] Applied, thanks! [1/1] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices commit: f83e377977663fc3f04cf5bb444aa989311110dc Best regards, -- Heiko Stuebner <heiko@sntech.de> _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: PCIe missing on RK3399 2024-12-11 12:55 PCIe missing on RK3399 Vicente Bergas 2024-12-11 13:36 ` Heiko Stübner @ 2025-02-07 0:17 ` Trevor Woerner 1 sibling, 0 replies; 15+ messages in thread From: Trevor Woerner @ 2025-02-07 0:17 UTC (permalink / raw) To: Vicente Bergas; +Cc: Heiko Stübner, open list:ARM/Rockchip SoC... Hi, On Wed 2024-12-11 @ 01:55:01 PM, Vicente Bergas wrote: > Hi, > i've tested the Linux kernel 6.13-rc1 and rc2 and in both cases PCIe > is not detected on the RK3399 platform (rk3399-gru-kevin), whereas the > kernel version 6.12.3 works fine. > > 6.13 configuration is based on the same one as 6.12 and there aren't > any significant PCI-related differences. > > The messages from dmesg on 6.13 don't show any PCI-related errors. > > Does somebody know what is going on? I'm seeing something very similar on a different RK3399-based device. As such the proposed patch won't work in my case. I have the "Penta SATA HAT for Rock 4"[1] on a rock-pi-4a device running a bunch of disks for me. When Yocto (master) switched from 6.6.y to 6.12.y this HAT stopped working. Currently Yocto master carries recipes for both 6.6.y and 6.12.y so I'm able to pin the kernel to 6.6.y, but it would be nice to get this fixed. I only have one such setup, and it's running in "production", so I'm not overly keen to take it offline for long periods for testing. But I'm willing to do some investigation if there are suggestions to try. Currently Yocto supports 6.6.74 and 6.12.11. [1] https://shop.allnetchina.cn/products/penta-sata-hat-for-rock-pi-4 _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2025-02-07 0:18 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-12-11 12:55 PCIe missing on RK3399 Vicente Bergas 2024-12-11 13:36 ` Heiko Stübner 2024-12-11 15:10 ` Vicente Bergas 2024-12-11 15:35 ` Heiko Stübner 2024-12-11 17:31 ` Vicente Bergas 2024-12-12 12:12 ` Vicente Bergas 2024-12-12 13:06 ` Heiko Stübner 2024-12-12 16:50 ` Vicente Bergas 2024-12-28 0:51 ` Vicente Bergas 2024-12-28 9:35 ` Johan Jonker 2025-01-13 21:02 ` Vicente Bergas 2025-01-16 14:36 ` [PATCH] arm64: dts: rockchip: fix fixed-regulator renames on rk3399-gru devices Heiko Stuebner 2025-01-17 0:44 ` Vicente Bergas 2025-02-03 8:15 ` Heiko Stuebner 2025-02-07 0:17 ` PCIe missing on RK3399 Trevor Woerner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.