[PATCH v2 0/7] Introduce SpacemiT K1 PCIe phy and host controller
Manivannan Sadhasivam
mani at kernel.org
Thu Oct 30 23:10:20 PDT 2025
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 at 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
--
மணிவண்ணன் சதாசிவம்
More information about the linux-riscv
mailing list