linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Z.q. Hou" <zhiqiang.hou@nxp.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gustavo.pimentel@synopsys.com" <gustavo.pimentel@synopsys.com>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	Leo Li <leoyang.li@nxp.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
	"M.h. Lian" <minghuan.lian@nxp.com>
Subject: RE: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
Date: Tue, 20 Aug 2019 00:12:31 +0000	[thread overview]
Message-ID: <DB8PR04MB6747FDA7787D986D5FB851E384AB0@DB8PR04MB6747.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20190819192440.GT253360@google.com>

Hi Bjorn,

Thanks a lot for your comments!

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: 2019年8月20日 3:25
> To: Z.q. Hou <zhiqiang.hou@nxp.com>
> Cc: linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> linux-kernel@vger.kernel.org; gustavo.pimentel@synopsys.com;
> jingoohan1@gmail.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>;
> lorenzo.pieralisi@arm.com; M.h. Lian <minghuan.lian@nxp.com>
> Subject: Re: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property
> from PCIe nodes
> 
> On Mon, Aug 12, 2019 at 04:22:27AM +0000, Z.q. Hou wrote:
> > From: Hou Zhiqiang <Zhiqiang.Hou@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?

Will add in v2.
As the Layerscape PCIe controller link training is completed automatically during
the power on reset. It doesn't need software to bring up. So I think it should be the
former.

Thanks,
Zhiqiang

> > Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@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
> >

  reply	other threads:[~2019-08-20  0:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12  4:22 [PATCH 0/4] Layerscape: Remove num-lanes property from PCIe nodes Z.q. Hou
2019-08-12  4:22 ` [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from Required properties Z.q. Hou
2019-08-12  8:45   ` Andrew Murray
2019-08-13  3:07     ` Z.q. Hou
2019-08-13  4:35       ` Kishon Vijay Abraham I
2019-08-19 19:20   ` Bjorn Helgaas
2019-08-19 23:57     ` Z.q. Hou
2019-08-12  4:22 ` [PATCH 2/4] PCI: dwc: Return directly when num-lanes is not found Z.q. Hou
2019-08-12  8:34   ` Andrew Murray
2019-08-13  3:13     ` Z.q. Hou
2019-08-12  4:22 ` [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes Z.q. Hou
2019-08-12  8:35   ` Andrew Murray
2019-08-13  3:13     ` Z.q. Hou
2019-08-19 19:24   ` Bjorn Helgaas
2019-08-20  0:12     ` Z.q. Hou [this message]
2019-08-12  4:22 ` [PATCH 4/4] arm64: dts: fsl: " Z.q. Hou
2019-08-12  8:35   ` Andrew Murray
2019-08-13  3:14     ` Z.q. Hou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DB8PR04MB6747FDA7787D986D5FB851E384AB0@DB8PR04MB6747.eurprd04.prod.outlook.com \
    --to=zhiqiang.hou@nxp.com \
    --cc=devicetree@vger.kernel.org \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=helgaas@kernel.org \
    --cc=jingoohan1@gmail.com \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=minghuan.lian@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).