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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.