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
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Mon, Sep 16, 2013 at 02:54:32PM +0800, Sean Cross wrote:
> >>@@ -116,6 +116,22 @@> >> arm,data-latency = <4 2 3>;> >> };> >>+ pcie: pcie@0x01000000 {> >>+ compatible = "fsl,imx6-pcie", "snps,dw-pcie";> >We generally use particular SoC name to specify the compatible string.> >So "fsl,imx6q-pcie" will be more appropriate.> Any reason to specify imx6q in particular? It's also present on the> imx6d, imx6dl, and imx6s (basically, everything but the imx6sl).
The compatible naming is not about coverage but versioning. We
generally encode the name of the SoC that firstly integrates the block
to specify the version.
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Monday, September 16, 2013 6:02 PM, Shawn Guo wrote:
> On Mon, Sep 16, 2013 at 02:54:32PM +0800, Sean Cross wrote:> > >>@@ -116,6 +116,22 @@> > >> arm,data-latency = <4 2 3>;> > >> };> > >>+ pcie: pcie@0x01000000 {> > >>+ compatible = "fsl,imx6-pcie", "snps,dw-pcie";> > >We generally use particular SoC name to specify the compatible string.> > >So "fsl,imx6q-pcie" will be more appropriate.> > Any reason to specify imx6q in particular? It's also present on the> > imx6d, imx6dl, and imx6s (basically, everything but the imx6sl).> > The compatible naming is not about coverage but versioning. We> generally encode the name of the SoC that firstly integrates the block> to specify the version.>
Yes, you're right. :-)
The name of the first SoC would be used.
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html