[PATCH u-boot-marvell 02/10] arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c

[Stefan Roese]

On 11/29/21 10:06, Pali Rohár wrote:

<snip>

>>> After this DTS change, pci-mvebu.c will just replace value of current
>>> number of lanes (which is set to 4 by serdes code) to value from DTS,
>>> which is 4. Therefore there should be no change.
>>>
>>> Could you test whole patch series with above DTS change if it works
>>> properly on Theadorable board?
>>
>> Yes, I don't see any issues with this patchset applied plus this DT
>> patch on theadorable. The PCIe links are up and with the correct width.
>>
>> What I'm wondering is, when exactly does the PCIe RP start the link
>> establishment. In my case with AXP this is still in the AXP serdes code
>> of course. But in the A38x code, it should be in the PCIe controller
>> driver now AFAIU. I see that you configure the link width in the
>> controller and do some other configuration (address windows etc), but
>> at the end you "simply" wait for the link to come up via
>> mvebu_pcie_wait_for_link(). I would have expected here some special
>> command (config bit?) to the PCIe controller to start the link
>> establishment. So when exactly does the A38x start this action?
> 
> That is interesting question... While I'm reading it again, I really do
> not know. Because you are right that mvebu_pcie_wait_for_link() is just
> waiting for a link and it "magically" comes up. I have tested it on A385
> and it is stable with different Compex Atheros cards which caused issues
> in past also on A3720.

I would prefer, to fully understand when exactly the link establishment
is started. Since this is crucial for the setup of the controller that
needs to be done *before* the link starts to come up.

Could you perhaps try to remove some of the register configurations in
the MVEBU PCIe driver to see, if the link establishment relies on this
register to be written to (e.g. PCI_EXP_LNKCAP)?

Thanks,
Stefan