On Mon, Aug 12, 2019 at 04:22:27AM +0000, Z.q. Hou wrote: > From: Hou Zhiqiang <zhiqiang....@nxp.com> > > On FSL Layerscape SoCs, the number of lanes assigned to PCIe > controller is not fixed, it is determined by the selected > SerDes protocol in the RCW (Reset Configuration Word), and > the PCIe link training is completed automatically base on > the selected SerDes protocol, and the link width set-up is > updated by hardware. So the num-lanes is not needed to > specify the link width. > > The current num-lanes indicates the max lanes PCIe controller > can support up to, instead of the lanes assigned to the PCIe > controller. This can result in PCIe link training fail after > hot-reset. So remove the num-lanes to avoid set-up to incorrect > link width.
It would be useful to explain *why* "num-lanes" in DT causes a link training failure. Maybe the code programs "num-lanes" somewhere, overriding what hardware automatically sensed? Maybe the code tries to bring up exactly "num-lanes" lanes even if not all are present? > Signed-off-by: Hou Zhiqiang <zhiqiang....@nxp.com> > --- > arch/arm/boot/dts/ls1021a.dtsi | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi > index 464df4290ffc..2f6977ada447 100644 > --- a/arch/arm/boot/dts/ls1021a.dtsi > +++ b/arch/arm/boot/dts/ls1021a.dtsi > @@ -874,7 +874,6 @@ > #address-cells = <3>; > #size-cells = <2>; > device_type = "pci"; > - num-lanes = <4>; > num-viewport = <6>; > bus-range = <0x0 0xff>; > ranges = <0x81000000 0x0 0x00000000 0x40 0x00010000 0x0 > 0x00010000 /* downstream I/O */ > @@ -899,7 +898,6 @@ > #address-cells = <3>; > #size-cells = <2>; > device_type = "pci"; > - num-lanes = <4>; > num-viewport = <6>; > bus-range = <0x0 0xff>; > ranges = <0x81000000 0x0 0x00000000 0x48 0x00010000 0x0 > 0x00010000 /* downstream I/O */ > -- > 2.17.1 >
