On 23/02/2022 21:19, Maciej W. Rozycki wrote:
On Wed, 23 Feb 2022, Bjorn Helgaas wrote:
+ dw_pcie_dbi_ro_wr_dis(dw);
+}
+
static int fu740_pcie_start_link(struct dw_pcie *pci)
{
struct device *dev = pci->dev;
struct fu740_pcie *afp = dev_get_drvdata(dev);
+ /* Force PCIe gen1 otherwise Unmatched board does not probe */
+ fu740_pcie_force_gen1(pci, afp);
I guess the "Unmatched" board is the only thing we need to care about
here? Are there or will there be other boards that don't need this?
I wonder if this is the other side of a supposed erratum observed here:
<https://lore.kernel.org/all/alpine.DEB.2.21.2202010240190.58572@xxxxxxxxxxxxxxxxx/>
Downstream there's the same ASMedia ASM2824 PCIe switch whose downstream
ports don't want to train with a Pericom part above Gen1.
Of course we don't know an ASM2824 is there until we have successfully
negotiated the link, so we may have to generalise my proposal if we can
find a way similar to what I have done for U-boot that does not disturb
Linux's operation. This is because there are PCIe option cards out there
with the ASM2824 onboard, so it could be possible for the problem to
trigger anywhere where the conditions for the erratum are met.
Also in that case retraining should work with the cap removed to get a
higher final speed just as with the Pericom part.
Possibly. I have just been working on a patch to better force Gen1
speeds and then restore the config which is working on my Unmatched
board.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
