From: Bjorn Helgaas <helgaas@kernel.org>
To: Tim Harvey <tharvey@gateworks.com>
Cc: Lucas Stach <l.stach@pengutronix.de>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Fabio Estevam <fabio.estevam@freescale.com>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org
Subject: Re: [PATCH v2] PCI: imx6: add dt prop for link gen, default to gen1
Date: Wed, 24 Feb 2016 14:03:57 -0600 [thread overview]
Message-ID: <20160224200357.GB31108@localhost> (raw)
In-Reply-To: <CAJ+vNU0ar_d=2n4Yz3QX4qidSkH6PBLyfB8-w-ErLOYzwqj7rw@mail.gmail.com>
[+cc Rob, devicetree list]
On Wed, Dec 02, 2015 at 08:35:06AM -0800, Tim Harvey wrote:
> On Wed, Nov 25, 2015 at 3:14 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, Nov 19, 2015 at 06:12:45AM -0800, Tim Harvey wrote:
> >> Freescale has stated [1] that the LVDS clock source of the IMX6 does not pass
> >> the PCI Gen2 clock jitter test, therefore unless an external Gen2 compliant
> >> external clock source is present and supplied back to the IMX6 PCIe core
> >> via LVDS CLK1/CLK2 you can not claim Gen2 compliance.
> >>
> >> Add a dt property to specify gen1 vs gen2 and check this before allowing
> >> a Gen2 link.
> >>
> >> We default to Gen1 if the property is not present because at this time there
> >> are no IMX6 boards in mainline that 'input' a clock on LVDS CLK1/CLK2.
> >>
> >> In order to be Gen2 compliant on IMX6 you need to:
> >> - have a Gen2 compliant external clock generator and route that clock back
> >> to either LVDS CLK1 or LVDS CLK2 as an input.
> >> (see IMX6SX-SabreSD reference design)
> >> - specify this clock in the pcie node in the dt
> >> (ie IMX6QDL_CLK_LVDS1_IN or IMX6QDL_CLK_LVDS2_IN instead of
> >> IMX6QDL_CLK_LVDS1_GATE which configures it as a CLK output)
> >>
> >> [1] https://community.freescale.com/message/453209
> >>
> >> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> >> ---
> >> v2:
> >> - moved dt property to designware core
> >>
> >> .../devicetree/bindings/pci/designware-pcie.txt | 1 +
> >> drivers/pci/host/pci-imx6.c | 16 ++++++++++------
> >> drivers/pci/host/pcie-designware.c | 4 ++++
> >> drivers/pci/host/pcie-designware.h | 1 +
> >> 4 files changed, 16 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> >> index 9f4faa8..a9a94b9 100644
> >> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> >> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> >> @@ -26,3 +26,4 @@ Optional properties:
> >> - bus-range: PCI bus numbers covered (it is recommended for new devicetrees to
> >> specify this property, to keep backwards compatibility a range of 0x00-0xff
> >> is assumed if not present)
> >> +- max-link-speed: Specify PCI gen for link capability (ie 2 for gen2)
> >
> > Is there some sort of DT or OF spec that lists "max-link-speed" as a
> > generic property? I see Lucas' desire to have this be common across
> > DesignWare PCIe cores. Should it be moved up a level even from there,
> > i.e., to bindings/pci/pci.txt?
>
> I don't know what the general consensus is here. As your the PCI
> maintainer I would leave that up to you. Are there other platforms
> that need to link at a lesser capability than the host controller is
> capable of? I am only aware of the IMX6 and SPEAr13XX [1]
This is really a devicetree question, not a PCI one, so I added Rob
and the devicetree list in case they have any comments on this.
> > It might be worth mentioning in pci/fsl,imx6q-pcie.txt that we limit
> > the link to gen1 unless max-link-speed is present and has the value
> > "2".
This default seems backwards. It seems like we'd want to configure
the link to go as fast as possible unless we have a quirk, e.g.,
"max-link-speed", that imposes a device-specific link. In other
words, why don't we penalize the broken board instead of penalizing
all the working ones?
> [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pci/spear13xx-pcie.txt#n14
next prev parent reply other threads:[~2016-02-24 20:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 14:58 [PATCH RFC] PCI: imx6: add dt prop for link gen, default to gen1 Tim Harvey
2015-11-05 15:40 ` Fabio Estevam
2015-11-06 1:15 ` Zhu Richard
2015-11-06 9:36 ` Lucas Stach
2015-11-06 19:59 ` Tim Harvey
2015-11-10 9:49 ` Lucas Stach
2015-11-19 14:12 ` [PATCH v2] " Tim Harvey
2015-11-19 14:19 ` Lucas Stach
2015-11-25 23:14 ` Bjorn Helgaas
2015-12-02 16:35 ` Tim Harvey
2015-12-17 15:09 ` Tim Harvey
2016-02-24 19:35 ` Akshay Bhat
2016-02-24 19:52 ` Bjorn Helgaas
2016-02-24 20:03 ` Bjorn Helgaas [this message]
2016-02-24 20:35 ` Rob Herring
2016-02-29 14:41 ` Tim Harvey
2016-03-01 15:02 ` Bjorn Helgaas
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=20160224200357.GB31108@localhost \
--to=helgaas@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@freescale.com \
--cc=l.stach@pengutronix.de \
--cc=linux-pci@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=tharvey@gateworks.com \
/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).