From: xobs@kosagi.com (Sean Cross)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 3/3] PCI: imx6: Add support for i.MX6 PCIe controller
Date: Mon, 16 Sep 2013 13:57:31 +0800 [thread overview]
Message-ID: <52369DCB.80101@kosagi.com> (raw)
In-Reply-To: <CAJ+vNU2GGfW0SQV1NnROMBtN5V_ANrjLJw2_+tWCRDsYG8BEeQ@mail.gmail.com>
On 14/9/13 7:50 AM, Tim Harvey wrote:
> Sean,
>
> Thanks for your work - I'm glad to see an i.MX6 PCIe host controller
> driver finally getting some upstream attention!
>
> I've tested this under several scenarios and am running into some issues.
>
> I found that on an IMX6DL I had to enable the sata_ref_100m clock
> additionally or a readl to the host address registers would hang (like
> the core had no clock). I've run into this before with the IMX6DL and
> don't quite understand why the core would be clocked off the sata clock.
>
> When going through a switch (Gateworks GW5400-B has a PLX PEX8609
> 8-port PCIe switch) I found that the CPU would randomly hang sometime
> after bootup. I found that installing an abort handler (from the
> Freescale BSP) seemed to resolve this. Additionally when going
> through a switch, I could not read config space of the switch dev or
> anything beyond it so it doesn't look like the driver supports
> switches/bridges.
As Richard Zhu mentioned, all devices should have sata_ref_100m
enabled. I'll make this change in v5.
I don't have a PCIe switch handy, so I can't test your handler, but the
reasoning does make sense. I'll add the abort handler code into the
driver. I'd be curious to know if this is a Designware limitation, or
if it's the sort of thing that this hardware is capable of supporting.
Freescale recommends using the SATA clock to drive the external bus. I
don't quite understand the reasoning, but it seems to have to do with a
number of dividers and multipliers it goes through, some of which are
fixed, and they all expect a 100 MHz clock. They are starting to change
the names of the clocks in the documentation from "SATA" and "PCIE" to
"100Mhz" and "125Mhz" because of the ambiguity.
--
Sean Cross
next prev parent reply other threads:[~2013-09-16 5:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-13 9:40 [PATCH v4 0/3] Add PCIe support for i.MX6q Sean Cross
2013-09-13 9:40 ` [PATCH v4 1/3] ARM: imx: Add LVDS general-purpose clocks to i.MX6Q Sean Cross
2013-09-13 12:42 ` Shawn Guo
2013-09-13 9:40 ` [PATCH v4 2/3] ARM: imx6q: Add PCIe bits to GPR syscon definition Sean Cross
2013-09-13 12:45 ` Shawn Guo
2013-09-13 9:40 ` [PATCH v4 3/3] PCI: imx6: Add support for i.MX6 PCIe controller Sean Cross
2013-09-14 23:54 ` Bjorn Helgaas
[not found] ` <CAJ+vNU2GGfW0SQV1NnROMBtN5V_ANrjLJw2_+tWCRDsYG8BEeQ@mail.gmail.com>
2013-09-16 5:57 ` Sean Cross [this message]
2013-09-16 6:06 ` Shawn Guo
2013-09-16 6:54 ` Sean Cross
2013-09-16 9:01 ` Shawn Guo
2013-09-16 22:53 ` Jingoo Han
2013-09-16 6:22 ` Jingoo Han
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=52369DCB.80101@kosagi.com \
--to=xobs@kosagi.com \
--cc=linux-arm-kernel@lists.infradead.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