On 24-06-04 14:38:40, Konrad Dybcio wrote:
On 6/4/24 14:20, Johan Hovold wrote:
On Tue, Jun 04, 2024 at 02:00:10PM +0200, Konrad Dybcio wrote:Ok, good. I was scared of double-sourcing of parts that are not identical
On 6/3/24 14:52, Johan Hovold wrote:
As I just mentioned in my reply on the PHY patch, this does not seem to
work on the CRD were the link still come up as 2-lane (also with the
clocks fixed):
qcom-pcie 1bf8000.pci: PCIe Gen.4 x2 link up
So something appears to be wrong here or in the PHY changes.
Is the device on the other end x4-capable? Or does it not matter in
this log line?
Yes, of course. It's the CRD as I wrote above, and you can tell from
other log entries:
pci 0007:01:00.0: 31.506 Gb/s available PCIe bandwidth, limited by 16.0 GT/s PCIe x2 link at 0007:00:00.0 (capable of 63.012 Gb/s with 16.0 GT/s PCIe x4 link)
lspci and what Windows reports.
in spec..
On my CRD, there is a KBG50ZNS256G.
[1] suggests this wasn't ever achieved.. which makes the cover letter of
this series a bit misleading..
True ...
What does the TCSR check return? If 0, can you hardcode it to 1 and see if
the link comes up at x4?
TCSR check returns 1. But that is not enough. The PCIe controller needs to
handles some stuff about margining. See the following patchset.
https://lore.kernel.org/linux-pci/20240501163610.8900-3-quic_schintav@xxxxxxxxxxx/
But even with this, I'm not able to get 4-lanes mode to work (yet).
So it must be something else in the controller driver that is needed.
IIRC, this is the first Qualcomm platform that would support Gen4 with
4-lanes upstream. Maybe I'm wrong.