1. Patchew
  2. linux
  3. View series

[PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller

Alex Elder posted 7 patches 2 months ago
There is a newer version of this series
.../bindings/pci/spacemit,k1-pcie-host.yaml   | 156 ++++
.../bindings/phy/spacemit,k1-combo-phy.yaml   | 114 +++
.../bindings/phy/spacemit,k1-pcie-phy.yaml    |  59 ++
.../boot/dts/spacemit/k1-bananapi-f3.dts      |  38 +
arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi  |  33 +
arch/riscv/boot/dts/spacemit/k1.dtsi          | 151 ++++
drivers/pci/controller/dwc/Kconfig            |  10 +
drivers/pci/controller/dwc/Makefile           |   1 +
drivers/pci/controller/dwc/pcie-spacemit-k1.c | 319 +++++++++
drivers/phy/Kconfig                           |  11 +
drivers/phy/Makefile                          |   1 +
drivers/phy/phy-spacemit-k1-pcie.c            | 672 ++++++++++++++++++
12 files changed, 1565 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml
create mode 100644 Documentation/devicetree/bindings/phy/spacemit,k1-combo-phy.yaml
create mode 100644 Documentation/devicetree/bindings/phy/spacemit,k1-pcie-phy.yaml
create mode 100644 drivers/pci/controller/dwc/pcie-spacemit-k1.c
create mode 100644 drivers/phy/phy-spacemit-k1-pcie.c
[PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Alex Elder 2 months ago 
This series introduces a PHY driver and a PCIe driver to support PCIe
on the SpacemiT K1 SoC.  The PCIe implementation is derived from a
Synopsys DesignWare PCIe IP.  The PHY driver supports one combination
PCIe/USB PHY as well as two PCIe-only PHYs.  The combo PHY port uses
one PCIe lane, and the other two ports each have two lanes.  All PCIe
ports operate at 5 GT/second.

The PCIe PHYs must be configured using a value that can only be
determined using the combo PHY, operating in PCIe mode.  To allow
that PHY to be used for USB, the calibration step is performed by
the PHY driver automatically at probe time.  Once this step is done,
the PHY can be used for either PCIe or USB.

Version 2 of this series incorporates suggestions made during the
review of version 1.  Specific highlights are detailed below.

					-Alex

This series is available here:
  https://github.com/riscstar/linux/tree/outgoing/pcie-v2

Between version 1 and version 2:
  - General
    - VENDOR ID 0x201f is now registered with PCI SIG: "SpacemiT
      (Hangzhou) Technology Co. Ltd"
        https://pcisig.com/membership/member-companies?combine=201f
    - The PCIe host compatible string is now "spacemit,k1-pcie"
    - Reimplemented the PHY PLL as a clock registered with the
      common clock framework, driven by an external oscillator
    - Added the external oscillator clock to the PHY binding
    - Renamed the PCIe driver source file "pcie-spacemit-k1.c"
  - Kconfig
    - Renamed the PCIe driver Kconfig option PCIE_SPACEMIT_K1
    - The PCIe driver is now defined as tristate, not Boolean
    - Updated the PCIe host Kconfig based on Bjorn H's feedback
  - DT Bindings
    - Corrected PCIe node ranges properties
    - Replaced "interrupts-extended" property with just "interrupts"
      in the PCIe host binding
    - Named the single PCIe interrupt "msi" to clarify its purpose
    - Added a new vpcie3v3-supply property for PCIe ports
    - Renamed a syscon property to align with other SpacemiT bindings
    - Removed labels and status properties in DT binding examples
    - Added a '>' to DT binding descriptions to preserve formatting
    - Consistently ended DT binding descriptions with no period
    - Dropped ".yaml" from the PCIe host compatible string
    - Dropped unneeded max-link-speed property from PCIe binding,
      relying on the hardware default value instead
    - No longer require the bus-ranges PCIe property; if not
      provided, the default value used is exactly what's desired
  - Code
    - Renamed the symbols representing the PCI vendor and device IDs
      to align with <linux/pci_ids.h>
    - Use PCIE_T_PVPERL_MS rather than 100 to represent a standard
      delay period.
    - Use platform (not dev) driver-data access functions; assignment
      is done only after the private structure is initialized
    - Deleted some unneeded includes in the PCIe driver.
    - Dropped error checking when operating on MMIO-backed regmaps
    - Added a regmap_read() call in two places, to ensure a specified
      delay occurs *after* the a MMIO write has reached its target.
    - Used ARRAY_SIZE() (not a local variable value) in a few spots
    - Now use readl_relaxed()/writel_relaxed() when operating on
      the "link" I/O memory space in the PCIe driver
    - Updated a few error messages for consistency
    - No longer specify suppress_bind_attrs in the PCIe driver
    - Now specify PCIe driver probe type as PROBE_PREFER_ASYNCHRONOUS
  - Miscellany
    - Subject on the PCIe host binding includes "pci", not "phy"
    - Clarified that the DesignWare built-in MSI controller is used
    - Use "PCIe gen2" terminology (rather than "PCIe v2")
    - No longer use (void) cast to indicate ignored return values

Here is version 1 of this series:
  https://lore.kernel.org/lkml/20250813184701.2444372-1-elder@riscstar.com/


Alex Elder (7):
  dt-bindings: phy: spacemit: add SpacemiT PCIe/combo PHY
  dt-bindings: phy: spacemit: introduce PCIe PHY
  dt-bindings: pci: spacemit: introduce PCIe host controller
  phy: spacemit: introduce PCIe/combo PHY
  PCI: spacemit: introduce SpacemiT PCIe host driver
  riscv: dts: spacemit: add a PCIe regulator
  riscv: dts: spacemit: PCIe and PHY-related updates

 .../bindings/pci/spacemit,k1-pcie-host.yaml   | 156 ++++
 .../bindings/phy/spacemit,k1-combo-phy.yaml   | 114 +++
 .../bindings/phy/spacemit,k1-pcie-phy.yaml    |  59 ++
 .../boot/dts/spacemit/k1-bananapi-f3.dts      |  38 +
 arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi  |  33 +
 arch/riscv/boot/dts/spacemit/k1.dtsi          | 151 ++++
 drivers/pci/controller/dwc/Kconfig            |  10 +
 drivers/pci/controller/dwc/Makefile           |   1 +
 drivers/pci/controller/dwc/pcie-spacemit-k1.c | 319 +++++++++
 drivers/phy/Kconfig                           |  11 +
 drivers/phy/Makefile                          |   1 +
 drivers/phy/phy-spacemit-k1-pcie.c            | 672 ++++++++++++++++++
 12 files changed, 1565 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml
 create mode 100644 Documentation/devicetree/bindings/phy/spacemit,k1-combo-phy.yaml
 create mode 100644 Documentation/devicetree/bindings/phy/spacemit,k1-pcie-phy.yaml
 create mode 100644 drivers/pci/controller/dwc/pcie-spacemit-k1.c
 create mode 100644 drivers/phy/phy-spacemit-k1-pcie.c


base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
-- 
2.48.1
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Aurelien Jarno 2 months ago 
Hi Alex,

On 2025-10-13 10:35, Alex Elder wrote:
> This series introduces a PHY driver and a PCIe driver to support PCIe
> on the SpacemiT K1 SoC.  The PCIe implementation is derived from a
> Synopsys DesignWare PCIe IP.  The PHY driver supports one combination
> PCIe/USB PHY as well as two PCIe-only PHYs.  The combo PHY port uses
> one PCIe lane, and the other two ports each have two lanes.  All PCIe
> ports operate at 5 GT/second.
> 
> The PCIe PHYs must be configured using a value that can only be
> determined using the combo PHY, operating in PCIe mode.  To allow
> that PHY to be used for USB, the calibration step is performed by
> the PHY driver automatically at probe time.  Once this step is done,
> the PHY can be used for either PCIe or USB.
> 
> Version 2 of this series incorporates suggestions made during the
> review of version 1.  Specific highlights are detailed below.

With the issues mentioned in patch 4 fixed, this patchset works fine for 
me. That said I had to disable ASPM by passing pcie_aspm=off on the 
command line, as it is now enabled by default since 6.18-rc1 [1]. At 
this stage, I am not sure if it is an issue with my NVME drive or an 
issue with the controller.

Regards
Aurelien

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3ac2ff14834a0aa056ee3ae0e4b8c641c579961

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Alex Elder 2 months ago 
On 10/16/25 11:47 AM, Aurelien Jarno wrote:
> Hi Alex,
> 
> On 2025-10-13 10:35, Alex Elder wrote:
>> This series introduces a PHY driver and a PCIe driver to support PCIe
>> on the SpacemiT K1 SoC.  The PCIe implementation is derived from a
>> Synopsys DesignWare PCIe IP.  The PHY driver supports one combination
>> PCIe/USB PHY as well as two PCIe-only PHYs.  The combo PHY port uses
>> one PCIe lane, and the other two ports each have two lanes.  All PCIe
>> ports operate at 5 GT/second.
>>
>> The PCIe PHYs must be configured using a value that can only be
>> determined using the combo PHY, operating in PCIe mode.  To allow
>> that PHY to be used for USB, the calibration step is performed by
>> the PHY driver automatically at probe time.  Once this step is done,
>> the PHY can be used for either PCIe or USB.
>>
>> Version 2 of this series incorporates suggestions made during the
>> review of version 1.  Specific highlights are detailed below.
> 
> With the issues mentioned in patch 4 fixed, this patchset works fine for
> me. That said I had to disable ASPM by passing pcie_aspm=off on the
> command line, as it is now enabled by default since 6.18-rc1 [1]. At
> this stage, I am not sure if it is an issue with my NVME drive or an
> issue with the controller.

Can you describe what symptoms you had that required you to pass
"pcie_aspm=off" on the kernel command line?

I see these lines in my boot log related to ASPM (and added by
the commit you link to), for both pcie1 and pcie2:

   pci 0000:01:00.0: ASPM: DT platform, enabling L0s-up L0s-dw L1 AS
PM-L1.1 ASPM-L1.2 PCI-PM-L1.1 PCI-PM-L1.2
   pci 0000:01:00.0: ASPM: DT platform, enabling ClockPM

   . . .

   nvme nvme0: pci function 0000:01:00.0
   nvme 0000:01:00.0: enabling device (0000 -> 0002)
   nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
   nvme nvme0: 8/0/0 default/read/poll queues
    nvme0n1: p1

My NVMe drive on pcie1 works correctly.
   https://www.crucial.com/ssd/p3/CT1000P3SSD8

   root@bananapif3:~# df /a
   Filesystem     1K-blocks     Used Available Use% Mounted on
   /dev/nvme0n1p1 960302804 32063304 879385040   4% /a
   root@bananapif3:~#

I basically want to know if there's something I should do with this
driver to address this.  (Mani, can you explain?)

Thank you.

					-Alex

> Regards
> Aurelien
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f3ac2ff14834a0aa056ee3ae0e4b8c641c579961
>
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Aurelien Jarno 1 month, 3 weeks ago 
Hi Alex,

On 2025-10-17 11:21, Alex Elder wrote:
> On 10/16/25 11:47 AM, Aurelien Jarno wrote:
> > Hi Alex,
> > 
> > On 2025-10-13 10:35, Alex Elder wrote:
> > > This series introduces a PHY driver and a PCIe driver to support PCIe
> > > on the SpacemiT K1 SoC.  The PCIe implementation is derived from a
> > > Synopsys DesignWare PCIe IP.  The PHY driver supports one combination
> > > PCIe/USB PHY as well as two PCIe-only PHYs.  The combo PHY port uses
> > > one PCIe lane, and the other two ports each have two lanes.  All PCIe
> > > ports operate at 5 GT/second.
> > > 
> > > The PCIe PHYs must be configured using a value that can only be
> > > determined using the combo PHY, operating in PCIe mode.  To allow
> > > that PHY to be used for USB, the calibration step is performed by
> > > the PHY driver automatically at probe time.  Once this step is done,
> > > the PHY can be used for either PCIe or USB.
> > > 
> > > Version 2 of this series incorporates suggestions made during the
> > > review of version 1.  Specific highlights are detailed below.
> > 
> > With the issues mentioned in patch 4 fixed, this patchset works fine for
> > me. That said I had to disable ASPM by passing pcie_aspm=off on the
> > command line, as it is now enabled by default since 6.18-rc1 [1]. At
> > this stage, I am not sure if it is an issue with my NVME drive or an
> > issue with the controller.
> 
> Can you describe what symptoms you had that required you to pass
> "pcie_aspm=off" on the kernel command line?
> 
> I see these lines in my boot log related to ASPM (and added by
> the commit you link to), for both pcie1 and pcie2:
> 
>   pci 0000:01:00.0: ASPM: DT platform, enabling L0s-up L0s-dw L1 AS
> PM-L1.1 ASPM-L1.2 PCI-PM-L1.1 PCI-PM-L1.2
>   pci 0000:01:00.0: ASPM: DT platform, enabling ClockPM
> 
>   . . .
> 
>   nvme nvme0: pci function 0000:01:00.0
>   nvme 0000:01:00.0: enabling device (0000 -> 0002)
>   nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
>   nvme nvme0: 8/0/0 default/read/poll queues
>    nvme0n1: p1
> 
> My NVMe drive on pcie1 works correctly.
>   https://www.crucial.com/ssd/p3/CT1000P3SSD8
> 
>   root@bananapif3:~# df /a
>   Filesystem     1K-blocks     Used Available Use% Mounted on
>   /dev/nvme0n1p1 960302804 32063304 879385040   4% /a
>   root@bananapif3:~#

Sorry for the delay, it took me time to test some more things and 
different SSDs. First of all I still see the issue with your v3 on top 
of v6.18-rc3, which includes some fixes for ASPM support [1].

I have tried 3 different SSDs, none of them are working, but the 
symptoms are different, although all related with ASPM (pcie_aspm=off 
workarounds the issue).

With a Fox Spirit PM18 SSD (Silicon Motion, Inc. SM2263EN/SM2263XT 
controller), I do not have more than this:
[    5.196723] nvme nvme0: pci function 0000:01:00.0
[    5.198843] nvme 0000:01:00.0: enabling device (0000 -> 0002)

With a WD Blue SN570 SSD, I get this:
[    5.199513] nvme nvme0: pci function 0000:01:00.0
[    5.201653] nvme 0000:01:00.0: enabling device (0000 -> 0002)
[    5.270334] nvme nvme0: allocated 32 MiB host memory buffer (8 segments).
[    5.277624] nvme nvme0: 8/0/0 default/read/poll queues
[   19.192350] nvme nvme0: using unchecked data buffer
[   48.108400] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
[   48.113885] nvme nvme0: Does your device have a faulty power saving mode enabled?
[   48.121346] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug
[   48.176878] nvme0n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct 0x3 / sc 0x71) 
[   48.181926] I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[   48.243670] nvme 0000:01:00.0: enabling device (0000 -> 0002)
[   48.246914] nvme nvme0: Disabling device after reset failure: -19
[   48.280495] Buffer I/O error on dev nvme0n1, logical block 0, async page read


Finally with a PNY CS1030 SSD (Phison PS5015-E15 controller), I get this:
[    5.215631] nvme nvme0: pci function 0000:01:00.0
[    5.220435] nvme 0000:01:00.0: enabling device (0000 -> 0002)
[    5.329565] nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
[   66.540485] nvme nvme0: I/O tag 28 (401c) QID 0 timeout, disable controller
[   66.585245] nvme 0000:01:00.0: probe with driver nvme failed with error -4

Note that I also tested this latest SSD on a VisionFive 2 board with exactly
the same kernel (I just moved the SSD and booted), and it works fine with ASPM
enabled (confirmed with lspci).

> I basically want to know if there's something I should do with this
> driver to address this.  (Mani, can you explain?)

I am not sure on my side how to debug that. What I know is that it is 
linked to ASPM L1, L0 works fine. In other words the SSDs work fine with 
this patch:

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 79b9651584737..1a134ec68b591 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -801,8 +801,8 @@ static void pcie_aspm_override_default_link_state(struct pcie_link_state *link)
 	if (of_have_populated_dt()) {
 		if (link->aspm_support & PCIE_LINK_STATE_L0S)
 			link->aspm_default |= PCIE_LINK_STATE_L0S;
-		if (link->aspm_support & PCIE_LINK_STATE_L1)
-			link->aspm_default |= PCIE_LINK_STATE_L1;
+//		if (link->aspm_support & PCIE_LINK_STATE_L1)
+//			link->aspm_default |= PCIE_LINK_STATE_L1;
 		override = link->aspm_default & ~link->aspm_enabled;
 		if (override)
 			pci_info(pdev, "ASPM: default states%s%s\n",

I can test more things if needed, but I don't know where to start.

Regards
Aurelien

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df5192d9bb0e38bf831fb93e8026e346aa017ca8

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Johannes Erdfelt 1 month, 3 weeks ago 
On Tue, Oct 28, 2025, Aurelien Jarno <aurelien@aurel32.net> wrote:
> Hi Alex,
> 
> On 2025-10-17 11:21, Alex Elder wrote:
> > On 10/16/25 11:47 AM, Aurelien Jarno wrote:
> > > Hi Alex,
> > > 
> > > On 2025-10-13 10:35, Alex Elder wrote:
> > > > This series introduces a PHY driver and a PCIe driver to support PCIe
> > > > on the SpacemiT K1 SoC.  The PCIe implementation is derived from a
> > > > Synopsys DesignWare PCIe IP.  The PHY driver supports one combination
> > > > PCIe/USB PHY as well as two PCIe-only PHYs.  The combo PHY port uses
> > > > one PCIe lane, and the other two ports each have two lanes.  All PCIe
> > > > ports operate at 5 GT/second.
> > > > 
> > > > The PCIe PHYs must be configured using a value that can only be
> > > > determined using the combo PHY, operating in PCIe mode.  To allow
> > > > that PHY to be used for USB, the calibration step is performed by
> > > > the PHY driver automatically at probe time.  Once this step is done,
> > > > the PHY can be used for either PCIe or USB.
> > > > 
> > > > Version 2 of this series incorporates suggestions made during the
> > > > review of version 1.  Specific highlights are detailed below.
> > > 
> > > With the issues mentioned in patch 4 fixed, this patchset works fine for
> > > me. That said I had to disable ASPM by passing pcie_aspm=off on the
> > > command line, as it is now enabled by default since 6.18-rc1 [1]. At
> > > this stage, I am not sure if it is an issue with my NVME drive or an
> > > issue with the controller.
> > 
> > Can you describe what symptoms you had that required you to pass
> > "pcie_aspm=off" on the kernel command line?
> > 
> > I see these lines in my boot log related to ASPM (and added by
> > the commit you link to), for both pcie1 and pcie2:
> > 
> >   pci 0000:01:00.0: ASPM: DT platform, enabling L0s-up L0s-dw L1 AS
> > PM-L1.1 ASPM-L1.2 PCI-PM-L1.1 PCI-PM-L1.2
> >   pci 0000:01:00.0: ASPM: DT platform, enabling ClockPM
> > 
> >   . . .
> > 
> >   nvme nvme0: pci function 0000:01:00.0
> >   nvme 0000:01:00.0: enabling device (0000 -> 0002)
> >   nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
> >   nvme nvme0: 8/0/0 default/read/poll queues
> >    nvme0n1: p1
> > 
> > My NVMe drive on pcie1 works correctly.
> >   https://www.crucial.com/ssd/p3/CT1000P3SSD8
> > 
> >   root@bananapif3:~# df /a
> >   Filesystem     1K-blocks     Used Available Use% Mounted on
> >   /dev/nvme0n1p1 960302804 32063304 879385040   4% /a
> >   root@bananapif3:~#
> 
> Sorry for the delay, it took me time to test some more things and 
> different SSDs. First of all I still see the issue with your v3 on top 
> of v6.18-rc3, which includes some fixes for ASPM support [1].
> 
> I have tried 3 different SSDs, none of them are working, but the 
> symptoms are different, although all related with ASPM (pcie_aspm=off 
> workarounds the issue).
> 
> With a Fox Spirit PM18 SSD (Silicon Motion, Inc. SM2263EN/SM2263XT 
> controller), I do not have more than this:
> [    5.196723] nvme nvme0: pci function 0000:01:00.0
> [    5.198843] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> 
> With a WD Blue SN570 SSD, I get this:
> [    5.199513] nvme nvme0: pci function 0000:01:00.0
> [    5.201653] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> [    5.270334] nvme nvme0: allocated 32 MiB host memory buffer (8 segments).
> [    5.277624] nvme nvme0: 8/0/0 default/read/poll queues
> [   19.192350] nvme nvme0: using unchecked data buffer
> [   48.108400] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
> [   48.113885] nvme nvme0: Does your device have a faulty power saving mode enabled?
> [   48.121346] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug
> [   48.176878] nvme0n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct 0x3 / sc 0x71) 
> [   48.181926] I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
> [   48.243670] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> [   48.246914] nvme nvme0: Disabling device after reset failure: -19
> [   48.280495] Buffer I/O error on dev nvme0n1, logical block 0, async page read
> 
> 
> Finally with a PNY CS1030 SSD (Phison PS5015-E15 controller), I get this:
> [    5.215631] nvme nvme0: pci function 0000:01:00.0
> [    5.220435] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> [    5.329565] nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
> [   66.540485] nvme nvme0: I/O tag 28 (401c) QID 0 timeout, disable controller
> [   66.585245] nvme 0000:01:00.0: probe with driver nvme failed with error -4
> 
> Note that I also tested this latest SSD on a VisionFive 2 board with exactly
> the same kernel (I just moved the SSD and booted), and it works fine with ASPM
> enabled (confirmed with lspci).

I have been testing this patchset recently as well, but on an Orange Pi
RV2 board instead (and an extra RV2 specific patch to enable power to
the M.2 slot).

I ran into the same symptoms you had ("QID 0 timeout" after about 60
seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
seems to work fine with the "pcie_aspm=off" workaround as well.

Of note, I don't have this problem with the vendor 6.6.63 kernel.

> > I basically want to know if there's something I should do with this
> > driver to address this.  (Mani, can you explain?)
> 
> I am not sure on my side how to debug that. What I know is that it is 
> linked to ASPM L1, L0 works fine. In other words the SSDs work fine with 
> this patch:
> 
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 79b9651584737..1a134ec68b591 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -801,8 +801,8 @@ static void pcie_aspm_override_default_link_state(struct pcie_link_state *link)
>  	if (of_have_populated_dt()) {
>  		if (link->aspm_support & PCIE_LINK_STATE_L0S)
>  			link->aspm_default |= PCIE_LINK_STATE_L0S;
> -		if (link->aspm_support & PCIE_LINK_STATE_L1)
> -			link->aspm_default |= PCIE_LINK_STATE_L1;
> +//		if (link->aspm_support & PCIE_LINK_STATE_L1)
> +//			link->aspm_default |= PCIE_LINK_STATE_L1;
>  		override = link->aspm_default & ~link->aspm_enabled;
>  		if (override)
>  			pci_info(pdev, "ASPM: default states%s%s\n",
> 
> I can test more things if needed, but I don't know where to start.

I'm not a PCIe expert, but I'm more than happy to test as well.

JE
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Alex Elder 1 month, 3 weeks ago 
On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
> On Tue, Oct 28, 2025, Aurelien Jarno <aurelien@aurel32.net> wrote:
>> Hi Alex,
>>
>> On 2025-10-17 11:21, Alex Elder wrote:
>>> On 10/16/25 11:47 AM, Aurelien Jarno wrote:
>>>> Hi Alex,
>>>>
>>>> On 2025-10-13 10:35, Alex Elder wrote:
>>>>> This series introduces a PHY driver and a PCIe driver to support PCIe
>>>>> on the SpacemiT K1 SoC.  The PCIe implementation is derived from a
>>>>> Synopsys DesignWare PCIe IP.  The PHY driver supports one combination
>>>>> PCIe/USB PHY as well as two PCIe-only PHYs.  The combo PHY port uses
>>>>> one PCIe lane, and the other two ports each have two lanes.  All PCIe
>>>>> ports operate at 5 GT/second.
>>>>>
>>>>> The PCIe PHYs must be configured using a value that can only be
>>>>> determined using the combo PHY, operating in PCIe mode.  To allow
>>>>> that PHY to be used for USB, the calibration step is performed by
>>>>> the PHY driver automatically at probe time.  Once this step is done,
>>>>> the PHY can be used for either PCIe or USB.
>>>>>
>>>>> Version 2 of this series incorporates suggestions made during the
>>>>> review of version 1.  Specific highlights are detailed below.
>>>>
>>>> With the issues mentioned in patch 4 fixed, this patchset works fine for
>>>> me. That said I had to disable ASPM by passing pcie_aspm=off on the
>>>> command line, as it is now enabled by default since 6.18-rc1 [1]. At
>>>> this stage, I am not sure if it is an issue with my NVME drive or an
>>>> issue with the controller.
>>>
>>> Can you describe what symptoms you had that required you to pass
>>> "pcie_aspm=off" on the kernel command line?
>>>
>>> I see these lines in my boot log related to ASPM (and added by
>>> the commit you link to), for both pcie1 and pcie2:
>>>
>>>    pci 0000:01:00.0: ASPM: DT platform, enabling L0s-up L0s-dw L1 AS
>>> PM-L1.1 ASPM-L1.2 PCI-PM-L1.1 PCI-PM-L1.2
>>>    pci 0000:01:00.0: ASPM: DT platform, enabling ClockPM
>>>
>>>    . . .
>>>
>>>    nvme nvme0: pci function 0000:01:00.0
>>>    nvme 0000:01:00.0: enabling device (0000 -> 0002)
>>>    nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
>>>    nvme nvme0: 8/0/0 default/read/poll queues
>>>     nvme0n1: p1
>>>
>>> My NVMe drive on pcie1 works correctly.
>>>    https://www.crucial.com/ssd/p3/CT1000P3SSD8
>>>
>>>    root@bananapif3:~# df /a
>>>    Filesystem     1K-blocks     Used Available Use% Mounted on
>>>    /dev/nvme0n1p1 960302804 32063304 879385040   4% /a
>>>    root@bananapif3:~#
>>
>> Sorry for the delay, it took me time to test some more things and
>> different SSDs. First of all I still see the issue with your v3 on top
>> of v6.18-rc3, which includes some fixes for ASPM support [1].
>>
>> I have tried 3 different SSDs, none of them are working, but the
>> symptoms are different, although all related with ASPM (pcie_aspm=off
>> workarounds the issue).
>>
>> With a Fox Spirit PM18 SSD (Silicon Motion, Inc. SM2263EN/SM2263XT
>> controller), I do not have more than this:
>> [    5.196723] nvme nvme0: pci function 0000:01:00.0
>> [    5.198843] nvme 0000:01:00.0: enabling device (0000 -> 0002)
>>
>> With a WD Blue SN570 SSD, I get this:
>> [    5.199513] nvme nvme0: pci function 0000:01:00.0
>> [    5.201653] nvme 0000:01:00.0: enabling device (0000 -> 0002)
>> [    5.270334] nvme nvme0: allocated 32 MiB host memory buffer (8 segments).
>> [    5.277624] nvme nvme0: 8/0/0 default/read/poll queues
>> [   19.192350] nvme nvme0: using unchecked data buffer
>> [   48.108400] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
>> [   48.113885] nvme nvme0: Does your device have a faulty power saving mode enabled?
>> [   48.121346] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug
>> [   48.176878] nvme0n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct 0x3 / sc 0x71)
>> [   48.181926] I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
>> [   48.243670] nvme 0000:01:00.0: enabling device (0000 -> 0002)
>> [   48.246914] nvme nvme0: Disabling device after reset failure: -19
>> [   48.280495] Buffer I/O error on dev nvme0n1, logical block 0, async page read
>>
>>
>> Finally with a PNY CS1030 SSD (Phison PS5015-E15 controller), I get this:
>> [    5.215631] nvme nvme0: pci function 0000:01:00.0
>> [    5.220435] nvme 0000:01:00.0: enabling device (0000 -> 0002)
>> [    5.329565] nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
>> [   66.540485] nvme nvme0: I/O tag 28 (401c) QID 0 timeout, disable controller
>> [   66.585245] nvme 0000:01:00.0: probe with driver nvme failed with error -4
>>
>> Note that I also tested this latest SSD on a VisionFive 2 board with exactly
>> the same kernel (I just moved the SSD and booted), and it works fine with ASPM
>> enabled (confirmed with lspci).
> 
> I have been testing this patchset recently as well, but on an Orange Pi
> RV2 board instead (and an extra RV2 specific patch to enable power to
> the M.2 slot).
> 
> I ran into the same symptoms you had ("QID 0 timeout" after about 60
> seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
> seems to work fine with the "pcie_aspm=off" workaround as well.

I don't see this problem, and haven't tried to reproduce it yet.

Mani told me I needed to add these lines to ensure the "runtime
PM hierarchy of PCIe chain" won't be "broken":

	pm_runtime_set_active()
	pm_runtime_no_callbacks()
	devm_pm_runtime_enable()

Just out of curiosity, could you try with those lines added
just before these assignments in k1_pcie_probe()?

	k1->pci.dev = dev;
	k1->pci.ops = &k1_pcie_ops;
	dw_pcie_cap_set(&k1->pci, REQ_RES);

I doubt it will fix what you're seeing, but at the moment I'm
working on something else.

Thanks.

					-Alex

> Of note, I don't have this problem with the vendor 6.6.63 kernel.
> 
>>> I basically want to know if there's something I should do with this
>>> driver to address this.  (Mani, can you explain?)
>>
>> I am not sure on my side how to debug that. What I know is that it is
>> linked to ASPM L1, L0 works fine. In other words the SSDs work fine with
>> this patch:
>>
>> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
>> index 79b9651584737..1a134ec68b591 100644
>> --- a/drivers/pci/pcie/aspm.c
>> +++ b/drivers/pci/pcie/aspm.c
>> @@ -801,8 +801,8 @@ static void pcie_aspm_override_default_link_state(struct pcie_link_state *link)
>>   	if (of_have_populated_dt()) {
>>   		if (link->aspm_support & PCIE_LINK_STATE_L0S)
>>   			link->aspm_default |= PCIE_LINK_STATE_L0S;
>> -		if (link->aspm_support & PCIE_LINK_STATE_L1)
>> -			link->aspm_default |= PCIE_LINK_STATE_L1;
>> +//		if (link->aspm_support & PCIE_LINK_STATE_L1)
>> +//			link->aspm_default |= PCIE_LINK_STATE_L1;
>>   		override = link->aspm_default & ~link->aspm_enabled;
>>   		if (override)
>>   			pci_info(pdev, "ASPM: default states%s%s\n",
>>
>> I can test more things if needed, but I don't know where to start.
> 
> I'm not a PCIe expert, but I'm more than happy to test as well.
> 
> JE
>
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Aurelien Jarno 1 month, 3 weeks ago 
On 2025-10-28 14:10, Alex Elder wrote:
> On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
> > On Tue, Oct 28, 2025, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > > Hi Alex,
> > > 
> > > On 2025-10-17 11:21, Alex Elder wrote:
> > > > On 10/16/25 11:47 AM, Aurelien Jarno wrote:
> > > > > Hi Alex,
> > > > > 
> > > > > On 2025-10-13 10:35, Alex Elder wrote:
> > > > > > This series introduces a PHY driver and a PCIe driver to support PCIe
> > > > > > on the SpacemiT K1 SoC.  The PCIe implementation is derived from a
> > > > > > Synopsys DesignWare PCIe IP.  The PHY driver supports one combination
> > > > > > PCIe/USB PHY as well as two PCIe-only PHYs.  The combo PHY port uses
> > > > > > one PCIe lane, and the other two ports each have two lanes.  All PCIe
> > > > > > ports operate at 5 GT/second.
> > > > > > 
> > > > > > The PCIe PHYs must be configured using a value that can only be
> > > > > > determined using the combo PHY, operating in PCIe mode.  To allow
> > > > > > that PHY to be used for USB, the calibration step is performed by
> > > > > > the PHY driver automatically at probe time.  Once this step is done,
> > > > > > the PHY can be used for either PCIe or USB.
> > > > > > 
> > > > > > Version 2 of this series incorporates suggestions made during the
> > > > > > review of version 1.  Specific highlights are detailed below.
> > > > > 
> > > > > With the issues mentioned in patch 4 fixed, this patchset works fine for
> > > > > me. That said I had to disable ASPM by passing pcie_aspm=off on the
> > > > > command line, as it is now enabled by default since 6.18-rc1 [1]. At
> > > > > this stage, I am not sure if it is an issue with my NVME drive or an
> > > > > issue with the controller.
> > > > 
> > > > Can you describe what symptoms you had that required you to pass
> > > > "pcie_aspm=off" on the kernel command line?
> > > > 
> > > > I see these lines in my boot log related to ASPM (and added by
> > > > the commit you link to), for both pcie1 and pcie2:
> > > > 
> > > >    pci 0000:01:00.0: ASPM: DT platform, enabling L0s-up L0s-dw L1 AS
> > > > PM-L1.1 ASPM-L1.2 PCI-PM-L1.1 PCI-PM-L1.2
> > > >    pci 0000:01:00.0: ASPM: DT platform, enabling ClockPM
> > > > 
> > > >    . . .
> > > > 
> > > >    nvme nvme0: pci function 0000:01:00.0
> > > >    nvme 0000:01:00.0: enabling device (0000 -> 0002)
> > > >    nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
> > > >    nvme nvme0: 8/0/0 default/read/poll queues
> > > >     nvme0n1: p1
> > > > 
> > > > My NVMe drive on pcie1 works correctly.
> > > >    https://www.crucial.com/ssd/p3/CT1000P3SSD8
> > > > 
> > > >    root@bananapif3:~# df /a
> > > >    Filesystem     1K-blocks     Used Available Use% Mounted on
> > > >    /dev/nvme0n1p1 960302804 32063304 879385040   4% /a
> > > >    root@bananapif3:~#
> > > 
> > > Sorry for the delay, it took me time to test some more things and
> > > different SSDs. First of all I still see the issue with your v3 on top
> > > of v6.18-rc3, which includes some fixes for ASPM support [1].
> > > 
> > > I have tried 3 different SSDs, none of them are working, but the
> > > symptoms are different, although all related with ASPM (pcie_aspm=off
> > > workarounds the issue).
> > > 
> > > With a Fox Spirit PM18 SSD (Silicon Motion, Inc. SM2263EN/SM2263XT
> > > controller), I do not have more than this:
> > > [    5.196723] nvme nvme0: pci function 0000:01:00.0
> > > [    5.198843] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> > > 
> > > With a WD Blue SN570 SSD, I get this:
> > > [    5.199513] nvme nvme0: pci function 0000:01:00.0
> > > [    5.201653] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> > > [    5.270334] nvme nvme0: allocated 32 MiB host memory buffer (8 segments).
> > > [    5.277624] nvme nvme0: 8/0/0 default/read/poll queues
> > > [   19.192350] nvme nvme0: using unchecked data buffer
> > > [   48.108400] nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0x10
> > > [   48.113885] nvme nvme0: Does your device have a faulty power saving mode enabled?
> > > [   48.121346] nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off pcie_port_pm=off" and report a bug
> > > [   48.176878] nvme0n1: I/O Cmd(0x2) @ LBA 0, 8 blocks, I/O Error (sct 0x3 / sc 0x71)
> > > [   48.181926] I/O error, dev nvme0n1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
> > > [   48.243670] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> > > [   48.246914] nvme nvme0: Disabling device after reset failure: -19
> > > [   48.280495] Buffer I/O error on dev nvme0n1, logical block 0, async page read
> > > 
> > > 
> > > Finally with a PNY CS1030 SSD (Phison PS5015-E15 controller), I get this:
> > > [    5.215631] nvme nvme0: pci function 0000:01:00.0
> > > [    5.220435] nvme 0000:01:00.0: enabling device (0000 -> 0002)
> > > [    5.329565] nvme nvme0: allocated 64 MiB host memory buffer (16 segments).
> > > [   66.540485] nvme nvme0: I/O tag 28 (401c) QID 0 timeout, disable controller
> > > [   66.585245] nvme 0000:01:00.0: probe with driver nvme failed with error -4
> > > 
> > > Note that I also tested this latest SSD on a VisionFive 2 board with exactly
> > > the same kernel (I just moved the SSD and booted), and it works fine with ASPM
> > > enabled (confirmed with lspci).
> > 
> > I have been testing this patchset recently as well, but on an Orange Pi
> > RV2 board instead (and an extra RV2 specific patch to enable power to
> > the M.2 slot).
> > 
> > I ran into the same symptoms you had ("QID 0 timeout" after about 60
> > seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
> > seems to work fine with the "pcie_aspm=off" workaround as well.
> 
> I don't see this problem, and haven't tried to reproduce it yet.
> 
> Mani told me I needed to add these lines to ensure the "runtime
> PM hierarchy of PCIe chain" won't be "broken":
> 
> 	pm_runtime_set_active()
> 	pm_runtime_no_callbacks()
> 	devm_pm_runtime_enable()
> 
> Just out of curiosity, could you try with those lines added
> just before these assignments in k1_pcie_probe()?
> 
> 	k1->pci.dev = dev;
> 	k1->pci.ops = &k1_pcie_ops;
> 	dw_pcie_cap_set(&k1->pci, REQ_RES);
> 
> I doubt it will fix what you're seeing, but at the moment I'm
> working on something else.
> 

Thanks for your fast answer. I have just tried this patch:

--- a/drivers/pci/controller/dwc/pcie-spacemit-k1.c
+++ b/drivers/pci/controller/dwc/pcie-spacemit-k1.c
@@ -271,6 +271,16 @@ static int k1_pcie_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(k1->phy),
 				     "failed to get PHY\n");
 
+	ret = pm_runtime_set_active(dev);
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "Failed to activate runtime PM\n");
+
+	pm_runtime_no_callbacks(dev);
+
+	ret = devm_pm_runtime_enable(dev);
+	if (ret < 0)
+		return dev_err_probe(dev, ret, "Failed to enable runtime PM\n");
+
 	k1->pci.dev = dev;
 	k1->pci.ops = &k1_pcie_ops;
 	dw_pcie_cap_set(&k1->pci, REQ_RES);

Unfortunately this doesn't fix the issue. On the positive side, things 
still work with it and pcie_aspm=off.

Regards
AUrelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Johannes Erdfelt 1 month, 3 weeks ago 
On Tue, Oct 28, 2025, Alex Elder <elder@riscstar.com> wrote:
> On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
> > I have been testing this patchset recently as well, but on an Orange Pi
> > RV2 board instead (and an extra RV2 specific patch to enable power to
> > the M.2 slot).
> > 
> > I ran into the same symptoms you had ("QID 0 timeout" after about 60
> > seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
> > seems to work fine with the "pcie_aspm=off" workaround as well.
> 
> I don't see this problem, and haven't tried to reproduce it yet.
> 
> Mani told me I needed to add these lines to ensure the "runtime
> PM hierarchy of PCIe chain" won't be "broken":
> 
> 	pm_runtime_set_active()
> 	pm_runtime_no_callbacks()
> 	devm_pm_runtime_enable()
> 
> Just out of curiosity, could you try with those lines added
> just before these assignments in k1_pcie_probe()?
> 
> 	k1->pci.dev = dev;
> 	k1->pci.ops = &k1_pcie_ops;
> 	dw_pcie_cap_set(&k1->pci, REQ_RES);
> 
> I doubt it will fix what you're seeing, but at the moment I'm
> working on something else.

Unfortunately there is no difference with the runtime PM hierarchy
additions.

JE
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Manivannan Sadhasivam 1 month, 2 weeks ago 
+ Aurelien

On Tue, Oct 28, 2025 at 01:48:32PM -0700, Johannes Erdfelt wrote:
> On Tue, Oct 28, 2025, Alex Elder <elder@riscstar.com> wrote:
> > On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
> > > I have been testing this patchset recently as well, but on an Orange Pi
> > > RV2 board instead (and an extra RV2 specific patch to enable power to
> > > the M.2 slot).
> > > 
> > > I ran into the same symptoms you had ("QID 0 timeout" after about 60
> > > seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
> > > seems to work fine with the "pcie_aspm=off" workaround as well.
> > 
> > I don't see this problem, and haven't tried to reproduce it yet.
> > 
> > Mani told me I needed to add these lines to ensure the "runtime
> > PM hierarchy of PCIe chain" won't be "broken":
> > 
> > 	pm_runtime_set_active()
> > 	pm_runtime_no_callbacks()
> > 	devm_pm_runtime_enable()
> > 
> > Just out of curiosity, could you try with those lines added
> > just before these assignments in k1_pcie_probe()?
> > 
> > 	k1->pci.dev = dev;
> > 	k1->pci.ops = &k1_pcie_ops;
> > 	dw_pcie_cap_set(&k1->pci, REQ_RES);
> > 
> > I doubt it will fix what you're seeing, but at the moment I'm
> > working on something else.
> 
> Unfortunately there is no difference with the runtime PM hierarchy
> additions.
> 

These are not supposed to fix the issues you were facing. I discussed with Alex
offline and figured out that L1 works fine on his BPI-F3 board with a NVMe SSD.

And I believe, Aurelien is also using that same board, but with different
SSDs. But what is puzzling me is, L1 is breaking Aurelien's setup with 3 SSDs
from different vendors. It apparently works fine on Alex's setup. So it somehow
confirms that Root Port supports and behaves correctly with L1. But at the same
time, I cannot just say without evidence that L1 is broken on all these SSDs
that you and Aurelien tested with.

So until that is figured out, I've asked Alex to disable L1 CAP in the
controller driver. So in the next version of this series, your SSDs should work
out of the box.

- Mani

-- 
மணிவண்ணன் சதாசிவம்
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Aurelien Jarno 1 month, 2 weeks ago 
Hi Mani,

On 2025-10-30 22:11, Manivannan Sadhasivam wrote:
> + Aurelien
> 
> On Tue, Oct 28, 2025 at 01:48:32PM -0700, Johannes Erdfelt wrote:
> > On Tue, Oct 28, 2025, Alex Elder <elder@riscstar.com> wrote:
> > > On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
> > > > I have been testing this patchset recently as well, but on an Orange Pi
> > > > RV2 board instead (and an extra RV2 specific patch to enable power to
> > > > the M.2 slot).
> > > > 
> > > > I ran into the same symptoms you had ("QID 0 timeout" after about 60
> > > > seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
> > > > seems to work fine with the "pcie_aspm=off" workaround as well.
> > > 
> > > I don't see this problem, and haven't tried to reproduce it yet.
> > > 
> > > Mani told me I needed to add these lines to ensure the "runtime
> > > PM hierarchy of PCIe chain" won't be "broken":
> > > 
> > > 	pm_runtime_set_active()
> > > 	pm_runtime_no_callbacks()
> > > 	devm_pm_runtime_enable()
> > > 
> > > Just out of curiosity, could you try with those lines added
> > > just before these assignments in k1_pcie_probe()?
> > > 
> > > 	k1->pci.dev = dev;
> > > 	k1->pci.ops = &k1_pcie_ops;
> > > 	dw_pcie_cap_set(&k1->pci, REQ_RES);
> > > 
> > > I doubt it will fix what you're seeing, but at the moment I'm
> > > working on something else.
> > 
> > Unfortunately there is no difference with the runtime PM hierarchy
> > additions.
> > 
> 
> These are not supposed to fix the issues you were facing. I discussed with Alex
> offline and figured out that L1 works fine on his BPI-F3 board with a NVMe SSD.
> 
> And I believe, Aurelien is also using that same board, but with different
> SSDs. But what is puzzling me is, L1 is breaking Aurelien's setup with 3 SSDs
> from different vendors. It apparently works fine on Alex's setup. So it somehow
> confirms that Root Port supports and behaves correctly with L1. But at the same
> time, I cannot just say without evidence that L1 is broken on all these SSDs
> that you and Aurelien tested with.

It could be that we have different revision of the BPI-F3 board, it's 
not impossible that I got an early-ish version. That said I just 
visually checked the PCB against the schematics, and the devices on the 
CLKREQN line appear to be installed.

If someone has contacts to check what changes have been done between the 
different board revision, that could help. Or same if there are 
different revisions of the SpacemiT K1 chip.

> So until that is figured out, I've asked Alex to disable L1 CAP in the
> controller driver. So in the next version of this series, your SSDs should work
> out of the box.

Thanks, that sounds good.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                     http://aurel32.net
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Manivannan Sadhasivam 1 month, 2 weeks ago 
On Thu, Oct 30, 2025 at 06:49:37PM +0100, Aurelien Jarno wrote:
> Hi Mani,
> 
> On 2025-10-30 22:11, Manivannan Sadhasivam wrote:
> > + Aurelien
> > 
> > On Tue, Oct 28, 2025 at 01:48:32PM -0700, Johannes Erdfelt wrote:
> > > On Tue, Oct 28, 2025, Alex Elder <elder@riscstar.com> wrote:
> > > > On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
> > > > > I have been testing this patchset recently as well, but on an Orange Pi
> > > > > RV2 board instead (and an extra RV2 specific patch to enable power to
> > > > > the M.2 slot).
> > > > > 
> > > > > I ran into the same symptoms you had ("QID 0 timeout" after about 60
> > > > > seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
> > > > > seems to work fine with the "pcie_aspm=off" workaround as well.
> > > > 
> > > > I don't see this problem, and haven't tried to reproduce it yet.
> > > > 
> > > > Mani told me I needed to add these lines to ensure the "runtime
> > > > PM hierarchy of PCIe chain" won't be "broken":
> > > > 
> > > > 	pm_runtime_set_active()
> > > > 	pm_runtime_no_callbacks()
> > > > 	devm_pm_runtime_enable()
> > > > 
> > > > Just out of curiosity, could you try with those lines added
> > > > just before these assignments in k1_pcie_probe()?
> > > > 
> > > > 	k1->pci.dev = dev;
> > > > 	k1->pci.ops = &k1_pcie_ops;
> > > > 	dw_pcie_cap_set(&k1->pci, REQ_RES);
> > > > 
> > > > I doubt it will fix what you're seeing, but at the moment I'm
> > > > working on something else.
> > > 
> > > Unfortunately there is no difference with the runtime PM hierarchy
> > > additions.
> > > 
> > 
> > These are not supposed to fix the issues you were facing. I discussed with Alex
> > offline and figured out that L1 works fine on his BPI-F3 board with a NVMe SSD.
> > 
> > And I believe, Aurelien is also using that same board, but with different
> > SSDs. But what is puzzling me is, L1 is breaking Aurelien's setup with 3 SSDs
> > from different vendors. It apparently works fine on Alex's setup. So it somehow
> > confirms that Root Port supports and behaves correctly with L1. But at the same
> > time, I cannot just say without evidence that L1 is broken on all these SSDs
> > that you and Aurelien tested with.
> 
> It could be that we have different revision of the BPI-F3 board, it's 
> not impossible that I got an early-ish version. That said I just 
> visually checked the PCB against the schematics, and the devices on the 
> CLKREQN line appear to be installed.
> 

CLKREQ# is only needed for L1 PM Substates (L1.1 and L1.2). In other ASPM states
(L0s and L1), REFCLK is supposed to be ON. So those don't need CLKREQ# assertion
by the endpoint.

The L1 issue you are facing could be due to the board routing issue also. I'm
just speculating here.

> If someone has contacts to check what changes have been done between the 
> different board revision, that could help. Or same if there are 
> different revisions of the SpacemiT K1 chip.
> 

I hope Alex can get this information.

- Mani

-- 
மணிவண்ணன் சதாசிவம்
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Alex Elder 1 month, 2 weeks ago 
On 10/31/25 1:10 AM, Manivannan Sadhasivam wrote:
> On Thu, Oct 30, 2025 at 06:49:37PM +0100, Aurelien Jarno wrote:
>> Hi Mani,
>>
>> On 2025-10-30 22:11, Manivannan Sadhasivam wrote:
>>> + Aurelien
>>>
>>> On Tue, Oct 28, 2025 at 01:48:32PM -0700, Johannes Erdfelt wrote:
>>>> On Tue, Oct 28, 2025, Alex Elder <elder@riscstar.com> wrote:
>>>>> On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
>>>>>> I have been testing this patchset recently as well, but on an Orange Pi
>>>>>> RV2 board instead (and an extra RV2 specific patch to enable power to
>>>>>> the M.2 slot).
>>>>>>
>>>>>> I ran into the same symptoms you had ("QID 0 timeout" after about 60
>>>>>> seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
>>>>>> seems to work fine with the "pcie_aspm=off" workaround as well.
>>>>>
>>>>> I don't see this problem, and haven't tried to reproduce it yet.
>>>>>
>>>>> Mani told me I needed to add these lines to ensure the "runtime
>>>>> PM hierarchy of PCIe chain" won't be "broken":
>>>>>
>>>>> 	pm_runtime_set_active()
>>>>> 	pm_runtime_no_callbacks()
>>>>> 	devm_pm_runtime_enable()
>>>>>
>>>>> Just out of curiosity, could you try with those lines added
>>>>> just before these assignments in k1_pcie_probe()?
>>>>>
>>>>> 	k1->pci.dev = dev;
>>>>> 	k1->pci.ops = &k1_pcie_ops;
>>>>> 	dw_pcie_cap_set(&k1->pci, REQ_RES);
>>>>>
>>>>> I doubt it will fix what you're seeing, but at the moment I'm
>>>>> working on something else.
>>>>
>>>> Unfortunately there is no difference with the runtime PM hierarchy
>>>> additions.
>>>>
>>>
>>> These are not supposed to fix the issues you were facing. I discussed with Alex
>>> offline and figured out that L1 works fine on his BPI-F3 board with a NVMe SSD.
>>>
>>> And I believe, Aurelien is also using that same board, but with different
>>> SSDs. But what is puzzling me is, L1 is breaking Aurelien's setup with 3 SSDs
>>> from different vendors. It apparently works fine on Alex's setup. So it somehow
>>> confirms that Root Port supports and behaves correctly with L1. But at the same
>>> time, I cannot just say without evidence that L1 is broken on all these SSDs
>>> that you and Aurelien tested with.

Aurelien, can you please confirm that your reports are with the BPI-F3
board?  I believe you identified the three SSDs that were failing.  I
am considering buying one of those models to see if I can reproduce
the problem and troubleshoot it.

>> It could be that we have different revision of the BPI-F3 board, it's
>> not impossible that I got an early-ish version. That said I just
>> visually checked the PCB against the schematics, and the devices on the
>> CLKREQN line appear to be installed.
>>
> 
> CLKREQ# is only needed for L1 PM Substates (L1.1 and L1.2). In other ASPM states
> (L0s and L1), REFCLK is supposed to be ON. So those don't need CLKREQ# assertion
> by the endpoint.
> 
> The L1 issue you are facing could be due to the board routing issue also. I'm
> just speculating here.
> 
>> If someone has contacts to check what changes have been done between the
>> different board revision, that could help. Or same if there are
>> different revisions of the SpacemiT K1 chip.
>>
> 
> I hope Alex can get this information.

I have sent a message to SpacemiT to explain that these issues are
being reported, and asking for any useful information about the
BPI-F3 (including whether there are different versions, or different
versions of firmware, and how someone can identify what they have).

Thanks.

					-Alex

> - Mani
>
Re: [PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Posted by Alex Elder 1 month, 3 weeks ago 
On 10/28/25 3:48 PM, Johannes Erdfelt wrote:
> On Tue, Oct 28, 2025, Alex Elder <elder@riscstar.com> wrote:
>> On 10/28/25 1:42 PM, Johannes Erdfelt wrote:
>>> I have been testing this patchset recently as well, but on an Orange Pi
>>> RV2 board instead (and an extra RV2 specific patch to enable power to
>>> the M.2 slot).
>>>
>>> I ran into the same symptoms you had ("QID 0 timeout" after about 60
>>> seconds). However, I'm using an Intel 600p. I can confirm my NVME drive
>>> seems to work fine with the "pcie_aspm=off" workaround as well.
>>
>> I don't see this problem, and haven't tried to reproduce it yet.
>>
>> Mani told me I needed to add these lines to ensure the "runtime
>> PM hierarchy of PCIe chain" won't be "broken":
>>
>> 	pm_runtime_set_active()
>> 	pm_runtime_no_callbacks()
>> 	devm_pm_runtime_enable()
>>
>> Just out of curiosity, could you try with those lines added
>> just before these assignments in k1_pcie_probe()?
>>
>> 	k1->pci.dev = dev;
>> 	k1->pci.ops = &k1_pcie_ops;
>> 	dw_pcie_cap_set(&k1->pci, REQ_RES);
>>
>> I doubt it will fix what you're seeing, but at the moment I'm
>> working on something else.
> 
> Unfortunately there is no difference with the runtime PM hierarchy
> additions.
> 
> JE

Thank you very much for testing.  I'll try to learn more
about this in the next day or so and will resolve it if
possible before I send the next version of this code.

					-Alex

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.