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

[Aurelien Jarno <aurelien@aurel32.net>]

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

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy