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

[Alex Elder]

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@xxxxxxxxxxxx> 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