RE: [PATCH] PCI: dwc: Change the inheritance between the abstracted structures
Hi Bjorn,
Thanks a lot for the comments!
> -Original Message-
> From: Bjorn Helgaas
> Sent: 2021年4月7日 1:09
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> lorenzo.pieral...@arm.com; r...@kernel.org; bhelg...@google.com;
> Kishon Vijay Abraham I ; Jingoo Han
> ; Richard Zhu ; Lucas
> Stach ; Murali Karicheri ;
> M.h. Lian ; Mingkai Hu ;
> Roy Zang ; Yue Wang ;
> Jonathan Chocron ; Thomas Petazzoni
> ; Jesper Nilsson
> ; Gustavo Pimentel
> ; Xiaowei Song
> ; Binghui Wang ;
> Stanimir Varbanov ; Pratyush Anand
> ; Kunihiko Hayashi
> ; Jason Yan ;
> Thierry Reding
> Subject: Re: [PATCH] PCI: dwc: Change the inheritance between the
> abstracted structures
>
> On Tue, Apr 06, 2021 at 05:28:25PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > Currently the core struct dw_pcie includes both struct pcie_port and
> > dw_pcie_ep and the RC and EP platform drivers directly includes the
> > dw_pcie. So it results in a RC or EP platform driver has 2 indirect
> > parents pcie_port and dw_pcie_ep, but it doesn't make sense let RC
> > platform driver includes the dw_pcie_ep and so does the EP platform
> > driver.
> >
> > This patch makes the struct pcie_port and dw_pcie_ep includes the core
> > struct dw_pcie and the RC and EP platform drivers include struct
> > pcie_port and dw_pcie_ep respectively.
>
> I really like the way this patch is heading. There's a lot of historical
> cruft in
> these drivers and this is a good step to cleaning it up. Thanks a lot for
> working on this!
>
> What does this patch apply to? It doesn't apply cleanly to either my "main"
> branch or the "next" branch. Try to send things that apply to "main" and if
> it needs to apply on top of something else, mention what that is.
Sorry, this patch was workout in several months ago, but seems my mailbox failed
to send it out that time, I can rebase it in these days if necessary.
>
> > diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c
> > b/drivers/pci/controller/dwc/pci-dra7xx.c
> > index 12726c63366f..0e914df6eaba 100644
> > --- a/drivers/pci/controller/dwc/pci-dra7xx.c
> > +++ b/drivers/pci/controller/dwc/pci-dra7xx.c
> > @@ -85,7 +85,8 @@
> > #define PCIE_B0_B1_TSYNCEN BIT(0)
> >
> > struct dra7xx_pcie {
> > - struct dw_pcie *pci;
> > + struct pcie_port*pp;
> > + struct dw_pcie_ep *ep;
>
> 1) This is not related to your patch, but I think "pcie_port" used to
>make more sense before we had endpoint drivers, but now it's the
>wrong name. Root Ports and Endpoints both have "PCIe Ports", but
>IIUC "struct pcie_port" only applies to Root Ports, and "struct
>dw_pcie_ep" is the analogue for Endpoints.
>
>It would be nice to coordinate these names with a separate patch,
>e.g., maybe "dw_pcie_rc" (or "dw_pcie_rp") and "dw_pcie_ep".
Cannot agree more!
>
> 2) We allocate struct dra7xx_pcie for both RPs and EPs. But IIUC, RPs
>only use "struct pcie_port", and EPs only use "struct dw_pcie_ep".
>It doesn't seem right to keep both pointers when only one is ever
>used.
The reason is this driver is for both RC mode and EP mode, and they are
using the same private struct dra7xx_pcie.
Do you have some suggestion on this case? Add a union of RC struct
in the driver private struct and uses the corresponding union member
according to the PCIe controller's mode, is it better?
Struct dra7xxx_pcie {
...
union {
struct pcie_port pp;
struct dw_pcie_ep ep;
} type;
...
}
>
> 3) I'm not sure why these should be pointers at all. Why can't they
>be directly embedded, e.g., "struct pcie_port pp" instead of
>"struct pcie_port *pp"? Obviously this would have to be done in a
>way that we allocate an RC-specific structure or an EP-specific
>one.
Agree, and this change can be done in a separate patch.
>
> > void __iomem*base; /* DT ti_conf */
> > int phy_count; /* DT phy-names count */
> > struct phy **phy;
>
> > @@ -796,6 +798,17 @@ static int __init dra7xx_pcie_probe(struct
> > platform_device *pdev)
> >
> > switch (mode) {
> > case DW_PCIE_RC_TYPE:
> > + pp = devm_kzalloc(dev, sizeof(*pp), GFP_KERNEL);
>
> We know "mode" right after the of_match_device() at the top of this
> function. I think we should
RE: [PATCH] PCI: dwc: Change the inheritance between the abstracted structures
Hi Lorenzo and All,
Any comments on this patch?
Thanks,
Zhiqiang
> -Original Message-
> From: Z.q. Hou
> Sent: 2021年1月29日 17:40
> To: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> lorenzo.pieral...@arm.com; r...@kernel.org; bhelg...@google.com
> Cc: Z.q. Hou ; Kishon Vijay Abraham I
> ; Jingoo Han ; Richard Zhu
> ; Lucas Stach ; Murali
> Karicheri ; M.h. Lian ;
> Mingkai Hu ; Roy Zang ; Yue
> Wang ; Jonathan Chocron
> ; Thomas Petazzoni
> ; Jesper Nilsson
> ; Gustavo Pimentel
> ; Xiaowei Song
> ; Binghui Wang ;
> Stanimir Varbanov ; Pratyush Anand
> ; Kunihiko Hayashi
> ; Jason Yan ;
> Thierry Reding
> Subject: [PATCH] PCI: dwc: Change the inheritance between the abstracted
> structures
>
> From: Hou Zhiqiang
>
> Currently the core struct dw_pcie includes both struct pcie_port
> and dw_pcie_ep and the RC and EP platform drivers directly
> includes the dw_pcie. So it results in a RC or EP platform driver
> has 2 indirect parents pcie_port and dw_pcie_ep, but it doesn't
> make sense let RC platform driver includes the dw_pcie_ep and
> so does the EP platform driver.
>
> This patch makes the struct pcie_port and dw_pcie_ep includes
> the core struct dw_pcie and the RC and EP platform drivers
> include struct pcie_port and dw_pcie_ep respectively.
>
> Signed-off-by: Hou Zhiqiang
> Cc: Kishon Vijay Abraham I
> Cc: Lorenzo Pieralisi
> Cc: Rob Herring
> Cc: Bjorn Helgaas
> Cc: Jingoo Han
> Cc: Richard Zhu
> Cc: Lucas Stach
> Cc: Murali Karicheri
> Cc: Minghuan Lian
> Cc: Mingkai Hu
> Cc: Roy Zang
> Cc: Yue Wang
> Cc: Jonathan Chocron
> Cc: Thomas Petazzoni
> Cc: Jesper Nilsson
> Cc: Gustavo Pimentel
> Cc: Xiaowei Song
> Cc: Binghui Wang
> Cc: Stanimir Varbanov
> Cc: Pratyush Anand
> Cc: Kunihiko Hayashi
> Cc: Jason Yan
> Cc: Thierry Reding
> ---
> drivers/pci/controller/dwc/pci-dra7xx.c | 74 +---
> drivers/pci/controller/dwc/pci-exynos.c | 26 +--
> drivers/pci/controller/dwc/pci-imx6.c | 46 +++--
> drivers/pci/controller/dwc/pci-keystone.c | 79 +---
> .../pci/controller/dwc/pci-layerscape-ep.c| 18 +-
> drivers/pci/controller/dwc/pci-layerscape.c | 51 +++---
> drivers/pci/controller/dwc/pci-meson.c| 25 +--
> drivers/pci/controller/dwc/pcie-al.c | 21 ++-
> drivers/pci/controller/dwc/pcie-armada8k.c| 17 +-
> drivers/pci/controller/dwc/pcie-artpec6.c | 74 +---
> .../pci/controller/dwc/pcie-designware-host.c | 2 +-
> .../pci/controller/dwc/pcie-designware-plat.c | 38 ++--
> drivers/pci/controller/dwc/pcie-designware.h | 72
> drivers/pci/controller/dwc/pcie-histb.c | 27 +--
> drivers/pci/controller/dwc/pcie-intel-gw.c| 42 +++--
> drivers/pci/controller/dwc/pcie-kirin.c | 42 +++--
> drivers/pci/controller/dwc/pcie-qcom.c| 40 ++---
> drivers/pci/controller/dwc/pcie-spear13xx.c | 16 +-
> drivers/pci/controller/dwc/pcie-tegra194.c| 169 +++---
> drivers/pci/controller/dwc/pcie-uniphier-ep.c | 14 +-
> drivers/pci/controller/dwc/pcie-uniphier.c| 17 +-
> 21 files changed, 557 insertions(+), 353 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c
> b/drivers/pci/controller/dwc/pci-dra7xx.c
> index 12726c63366f..0e914df6eaba 100644
> --- a/drivers/pci/controller/dwc/pci-dra7xx.c
> +++ b/drivers/pci/controller/dwc/pci-dra7xx.c
> @@ -85,7 +85,8 @@
> #define PCIE_B0_B1_TSYNCEN BIT(0)
>
> struct dra7xx_pcie {
> - struct dw_pcie *pci;
> + struct pcie_port*pp;
> + struct dw_pcie_ep *ep;
> void __iomem*base; /* DT ti_conf */
> int phy_count; /* DT phy-names count */
> struct phy **phy;
> @@ -290,11 +291,19 @@ static void dra7xx_pcie_msi_irq_handler(struct
> irq_desc *desc)
> static irqreturn_t dra7xx_pcie_irq_handler(int irq, void *arg)
> {
> struct dra7xx_pcie *dra7xx = arg;
> - struct dw_pcie *pci = dra7xx->pci;
> - struct device *dev = pci->dev;
> - struct dw_pcie_ep *ep = >ep;
> + struct dw_pcie_ep *ep;
> + struct dw_pcie *pci;
> + struct device *dev;
> u32 reg;
>
> + if (dra7xx->mode == DW_PCIE_RC_TYPE) {
> + pci = to_dw_pcie_from_pp(dra7xx->pp);
> + } else {
> + ep = dra7xx->ep;
> + pci = to_dw_pcie_from_ep(ep);
> + }
> +
> + dev = pci->dev;
> reg = dra7xx_pcie_readl(dra7xx,
> PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN);
>
> if (reg & ERR_SYS)
> @@ -447,11 +456,10 @@
RE: [PATCH 0/4] PCI: dwc: Refine the EP code no functionality change
Hi Lorenzo, Rob and Bjorn, Any comments on this series? Thanks, Zhiqiang > -Original Message- > From: Z.q. Hou > Sent: 2021年1月7日 17:11 > To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org; > linux-arm-ker...@axis.com; lorenzo.pieral...@arm.com; r...@kernel.org; > bhelg...@google.com > Cc: kis...@ti.com; M.h. Lian ; > jesper.nils...@axis.com; jingooh...@gmail.com; > gustavo.pimen...@synopsys.com; hayashi.kunih...@socionext.com; Z.q. > Hou > Subject: [PATCH 0/4] PCI: dwc: Refine the EP code no functionality change > > From: Hou Zhiqiang > > Tune the EP mode code slightly to make it more readable. > > Hou Zhiqiang (4): > PCI: dwc: Change to use an array to store the structure of functions > PCI: dwc: Add CFG offset info into function's represented structure > PCI: dwc: Rename callback function func_conf_select and its instance > PCI: dwc: Change the parameter of function dw_pcie_ep_reset_bar() > > drivers/pci/controller/dwc/pci-dra7xx.c | 2 +- > .../pci/controller/dwc/pci-layerscape-ep.c| 8 +- > drivers/pci/controller/dwc/pcie-artpec6.c | 2 +- > .../pci/controller/dwc/pcie-designware-ep.c | 192 -- > .../pci/controller/dwc/pcie-designware-plat.c | 3 +- > drivers/pci/controller/dwc/pcie-designware.h | 11 +- > drivers/pci/controller/dwc/pcie-uniphier-ep.c | 3 +- > 7 files changed, 96 insertions(+), 125 deletions(-) > > -- > 2.17.1
RE: [PATCH 0/7] PCI: layerscape: Add power management support
Hi Lorenzo, > -Original Message- > From: Lorenzo Pieralisi > Sent: 2021年3月23日 19:15 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org; > shawn...@kernel.org; Leo Li ; > gustavo.pimen...@synopsys.com; M.h. Lian ; > Mingkai Hu ; Roy Zang > Subject: Re: [PATCH 0/7] PCI: layerscape: Add power management support > > On Mon, Sep 07, 2020 at 01:37:54PM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > This patch series is to add PCIe power management support for NXP > > Layerscape platfroms. > > > > Hou Zhiqiang (7): > > PCI: dwc: Fix a bug of the case dw_pci->ops is NULL > > PCI: layerscape: Change to use the DWC common link-up check > function > > dt-bindings: pci: layerscape-pci: Add a optional property big-endian > > arm64: dts: layerscape: Add big-endian property for PCIe nodes > > dt-bindings: pci: layerscape-pci: Update the description of SCFG > > property > > dts: arm64: ls1043a: Add SCFG phandle for PCIe nodes > > PCI: layerscape: Add power management support > > > > .../bindings/pci/layerscape-pci.txt | 6 +- > > .../arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 + > > .../arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 6 + > > .../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 3 + > > drivers/pci/controller/dwc/pci-layerscape.c | 473 > ++ > > drivers/pci/controller/dwc/pcie-designware.c | 12 +- > > drivers/pci/controller/dwc/pcie-designware.h | 1 + > > 7 files changed, 388 insertions(+), 114 deletions(-) > > I don't know which patches are still applicable, I will mark this series as > superseded since you will have to rebase it anyway - please let me know > what's the plan. I'll rebase this series on the latest base. Thanks, Zhiqiang > > Thanks, > Lorenzo
RE: [PATCH] PCI: dwc: Move forward the iATU detection process
Hi,
Yes, they are fix the same issue.
Rob and other contributors sent so many patches to refine the drivers and make
the code brief and more readable, so I don't think we should just focus on the
fixes of this issue. I don't think it is a good choice that your patch move
some of the software perspective initializations into hardware ones.
Thanks
Zhiqiang
> -Original Message-
> From: Kunihiko Hayashi
> Sent: 2021年1月26日 13:26
> To: Z.q. Hou
> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
> lorenzo.pieral...@arm.com; r...@kernel.org; bhelg...@google.com;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com;
> jaswinder.si...@linaro.org; masami.hirama...@linaro.org
> Subject: Re: [PATCH] PCI: dwc: Move forward the iATU detection process
>
> Hi,
>
> This looks to me the same fix as my posted patch[1].
> Is this more effective than mine?
>
> Thank you,
>
> [1]
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .spinics.net%2Flists%2Flinux-pci%2Fmsg103889.htmldata=04%7C01%
> 7CZhiqiang.Hou%40nxp.com%7Cd9fa58aac4774c9dd61b08d8c1bad128%7C
> 686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637472355412202563
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Mt3B4jQ1Q1fu%2
> FAz9s4Y4eieHv7nYorvvT2pKlqFLE9k%3Dreserved=0
>
> On 2021/01/25 13:48, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > In the dw_pcie_ep_init(), it depends on the detected iATU region
> > numbers to allocate the in/outbound window management bit map.
> > It fails after the commit 281f1f99cf3a ("PCI: dwc: Detect number of
> > iATU windows").
> >
> > So this patch move the iATU region detection into a new function, move
> > forward the detection to the very beginning of functions
> > dw_pcie_host_init() and dw_pcie_ep_init(). And also remove it from the
> > dw_pcie_setup(), since it's more like a software perspective
> > initialization step than hardware setup.
> >
> > Fixes: 281f1f99cf3a ("PCI: dwc: Detect number of iATU windows")
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 2 ++
> > drivers/pci/controller/dwc/pcie-designware-host.c | 2 ++
> > drivers/pci/controller/dwc/pcie-designware.c | 11 ---
> > drivers/pci/controller/dwc/pcie-designware.h | 1 +
> > 4 files changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index bcd1cd9ba8c8..fcf935bf6f5e 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -707,6 +707,8 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> > }
> > }
> >
> > + dw_pcie_iatu_detect(pci);
> > +
> > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "addr_space");
> > if (!res)
> > return -EINVAL;
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > index 8a84c005f32b..8eae817c138d 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > @@ -316,6 +316,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
> > return PTR_ERR(pci->dbi_base);
> > }
> >
> > + dw_pcie_iatu_detect(pci);
> > +
> > bridge = devm_pci_alloc_host_bridge(dev, 0);
> > if (!bridge)
> > return -ENOMEM;
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 5b72a5448d2e..5b9bf02d918b 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -654,11 +654,9 @@ static void dw_pcie_iatu_detect_regions(struct
> dw_pcie *pci)
> > pci->num_ob_windows = ob;
> > }
> >
> > -void dw_pcie_setup(struct dw_pcie *pci)
> > +void dw_pcie_iatu_detect(struct dw_pcie *pci)
> > {
> > - u32 val;
> > struct device *dev = pci->dev;
> > - struct device_node *np = dev->of_node;
> > struct platform_device *pdev = to_platform_device(dev);
> >
> > if (pci->version >= 0x480A || (!pci->version && @@ -687,6 +685,13
> > @@ void dw_pcie_setup(struct dw_pcie *pci)
> >
> > dev_info(pci->dev, "Detected iATU regions: %u outbound, %u
> inbound",
RE: [PATCHv9] arm64: dts: layerscape: Add PCIe EP node for ls1088a
Hi Shawn,
Thanks a lot for your comments!
> -Original Message-
> From: Shawn Guo
> Sent: 2020年11月1日 16:55
> To: Z.q. Hou
> Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; robh...@kernel.org; Leo Li
> ; Xiaowei Bao
> Subject: Re: [PATCHv9] arm64: dts: layerscape: Add PCIe EP node for ls1088a
>
> On Mon, Oct 26, 2020 at 12:27:59PM +0800, Zhiqiang Hou wrote:
> > From: Xiaowei Bao
> >
> > Add PCIe EP node for ls1088a to support EP mode.
> >
> > Signed-off-by: Xiaowei Bao
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Andrew Murray
> > ---
> > V9:
> > - Rebase the patch since V8 patch was not accepted due to conflict.
> > - Correct the number of outbound windows.
> > - Add lables for EP nodes.
> >
> > .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > index ff5805206a28..8d8e610acba6 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > @@ -517,6 +517,17 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep1: pcie-ep@340 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
>
> Missing space in between compatibles.
Will fix in v10.
Regards,
Zhiqiang
>
> Shawn
>
> > + reg = <0x00 0x0340 0x0 0x0010
> > + 0x20 0x 0x8 0x>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <24>;
> > + num-ob-windows = <256>;
> > + max-functions = /bits/ 8 <2>;
> > + status = "disabled";
> > + };
> > +
> > pcie2: pcie@350 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x0350 0x0 0x0010 /* controller
> registers */
> > @@ -543,6 +554,16 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep2: pcie-ep@350 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > + reg = <0x00 0x0350 0x0 0x0010
> > + 0x28 0x 0x8 0x>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <6>;
> > + num-ob-windows = <6>;
> > + status = "disabled";
> > + };
> > +
> > pcie3: pcie@360 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x0360 0x0 0x0010 /* controller
> registers */
> > @@ -569,6 +590,16 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep3: pcie-ep@360 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > + reg = <0x00 0x0360 0x0 0x0010
> > + 0x30 0x 0x8 0x>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <6>;
> > + num-ob-windows = <6>;
> > + status = "disabled";
> > + };
> > +
> > smmu: iommu@500 {
> > compatible = "arm,mmu-500";
> > reg = <0 0x500 0 0x80>;
> > --
> > 2.17.1
> >
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Lorenzo and Richard, > -Original Message- > From: Lorenzo Pieralisi > Sent: 2020年10月20日 17:55 > To: Z.q. Hou > Cc: Kishon Vijay Abraham I ; Bjorn Helgaas > ; linux-kernel@vger.kernel.org; > linux-...@vger.kernel.org; r...@kernel.org; bhelg...@google.com; > gustavo.pimen...@synopsys.com > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Tue, Oct 20, 2020 at 02:13:13AM +, Z.q. Hou wrote: > > [...] > > > > > For NXP Layerscape platforms (the ls1028a and ls2088a are also NXP > > > Layerscape platform), as the error response to AXI/AHB was enabled, > > > it will get UR error and trigger SError on AXI bus when it accesses > > > a non-existent BDF on a link down bus. I'm not clear about how it > > > happens on dra7xxx and imx6, since they doesn't enable the error > response to AXI/AHB. > > > > > > That's exactly the case with DRA7xx as the error response is enabled > > > by default in the platform integration. > > > > Got feedback from the imx6 owner that imx6 like the dra7xx has the > > error response enabled by default. Now it's clear that the problem on > > all these platforms is the same. > > On IMX6, enabled by default and read-only ? Or it can be changed ? The AXI/AHB Bridge Slave Error Response Register is a common register of DWC IP, so I think it should be writeable. Richard, can you help to confirm? > What's the plan for layerscape on this matter ? I trend to change it back to the default error response behavior so that won't cause any error on CFG access, and have sent out the patch. And for the link up check before CFG accesses, in the DWC databoot (4.40a), it requires link up check before generating CFG requests, so need Gustavo help to make sure the reason of this requirement, any potential impact without the link up check. Thanks, Zhiqiang > > Lorenzo
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Bjorn, Lorenzo and Kishon, > -Original Message- > From: Kishon Vijay Abraham I > Sent: 2020年10月19日 13:41 > To: Z.q. Hou ; Bjorn Helgaas > Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; > r...@kernel.org; lorenzo.pieral...@arm.com; bhelg...@google.com; > gustavo.pimen...@synopsys.com > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > Hi Hou, > > On 19/10/20 10:54 am, Z.q. Hou wrote: > > Hello Bjorn, > > > > Thanks a lot for your comments! > > > >> -Original Message----- > >> From: Bjorn Helgaas > >> Sent: 2020年10月16日 6:48 > >> To: Z.q. Hou > >> Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; > >> r...@kernel.org; lorenzo.pieral...@arm.com; bhelg...@google.com; > >> gustavo.pimen...@synopsys.com > >> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > >> dw_child_pcie_ops > >> > >> On Wed, Sep 16, 2020 at 01:41:30PM +0800, Zhiqiang Hou wrote: > >>> From: Hou Zhiqiang > >>> > >>> On NXP Layerscape platforms, it results in SError in the enumeration > >>> of the PCIe controller, which is not connecting with an Endpoint > >>> device. And it doesn't make sense to enumerate the Endpoints when > >>> the PCIe link is down. So this patch added the link up check to > >>> avoid to fire configuration transactions on link down bus. > >> > >> Lorenzo already applied this, but a couple questions: > >> > >> You call out NXP Layerscape specifically, but doesn't this affect > >> other DWC-based platforms, too? You later mentioned imx6, Kishon > >> mentioned dra7xx, Michael mentioned ls1028a, Naresh mentioned ls2088 > >> (probably both the same as your "NXP Layerscape"). > > > > For NXP Layerscape platforms (the ls1028a and ls2088a are also NXP > Layerscape platform), as the error response to AXI/AHB was enabled, it will > get UR error and trigger SError on AXI bus when it accesses a non-existent > BDF on a link down bus. I'm not clear about how it happens on dra7xxx and > imx6, since they doesn't enable the error response to AXI/AHB. > > That's exactly the case with DRA7xx as the error response is enabled by > default in the platform integration. Got feedback from the imx6 owner that imx6 like the dra7xx has the error response enabled by default. Now it's clear that the problem on all these platforms is the same. Thanks, Zhiqiang > > Thanks > Kishon > > > > >> > >> The backtrace below contains a bunch of irrelevant info. The > >> timestamps are pointless. The backtrace past > >> pci_scan_single_device+0x80/0x100 or so really doesn't add anything > either. > >> > >> It'd be nice to have a comment in the code because the code *looks* > >> wrong and racy. Without a hint, everybody who sees it will have to > >> dig through the history to see why we tolerate the race. > > > > Yes, agree, but seems the cause of the SError on dra7xx and imx6 is > different from Layerscape platforms, we need to make it clear first. > > > > Thanks, > > Zhiqiang > > > >> > >>> [0.807773] SError Interrupt on CPU2, code 0xbf02 -- SError > >>> [0.807775] CPU: 2 PID: 1 Comm: swapper/0 Not tainted > >> 5.9.0-rc5-next-20200914-1-gf965d3ec86fa #67 > >>> [0.807776] Hardware name: LS1046A RDB Board (DT) > >>> [0.80] pstate: 2085 (nzCv daIf -PAN -UAO BTYPE=--) > >>> [0.807778] pc : pci_generic_config_read+0x3c/0xe0 > >>> [0.807778] lr : pci_generic_config_read+0x24/0xe0 > >>> [0.807779] sp : 80001003b7b0 > >>> [0.807780] x29: 80001003b7b0 x28: 80001003ba74 > >>> [0.807782] x27: 000971d96800 x26: 00096e77e0a8 > >>> [0.807784] x25: 80001003b874 x24: 80001003b924 > >>> [0.807786] x23: 0004 x22: > >>> [0.807788] x21: x20: 80001003b874 > >>> [0.807790] x19: 0004 x18: > >>> [0.807791] x17: 00c0 x16: fe0025981840 > >>> [0.807793] x15: b94c75b69948 x14: 62203a383634203a > >>> [0.807795] x13: 666e6f635f726568 x12: 202c31203d207265 > >>> [0.807797] x11: 626d756e3e2d7375 x10: 656877202c307830 > >>> [0.807799] x9 : 203d206e66766564 x8 : 0908 > >>> [0.807801] x7 : 0908 x6 : 80001090 > >>&
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hello Bjorn, Thanks a lot for your comments! > -Original Message- > From: Bjorn Helgaas > Sent: 2020年10月16日 6:48 > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; > r...@kernel.org; lorenzo.pieral...@arm.com; bhelg...@google.com; > gustavo.pimen...@synopsys.com > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Wed, Sep 16, 2020 at 01:41:30PM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > On NXP Layerscape platforms, it results in SError in the enumeration > > of the PCIe controller, which is not connecting with an Endpoint > > device. And it doesn't make sense to enumerate the Endpoints when the > > PCIe link is down. So this patch added the link up check to avoid to > > fire configuration transactions on link down bus. > > Lorenzo already applied this, but a couple questions: > > You call out NXP Layerscape specifically, but doesn't this affect other > DWC-based platforms, too? You later mentioned imx6, Kishon mentioned > dra7xx, Michael mentioned ls1028a, Naresh mentioned ls2088 (probably > both the same as your "NXP Layerscape"). For NXP Layerscape platforms (the ls1028a and ls2088a are also NXP Layerscape platform), as the error response to AXI/AHB was enabled, it will get UR error and trigger SError on AXI bus when it accesses a non-existent BDF on a link down bus. I'm not clear about how it happens on dra7xxx and imx6, since they doesn't enable the error response to AXI/AHB. > > The backtrace below contains a bunch of irrelevant info. The timestamps > are pointless. The backtrace past > pci_scan_single_device+0x80/0x100 or so really doesn't add anything either. > > It'd be nice to have a comment in the code because the code *looks* wrong > and racy. Without a hint, everybody who sees it will have to dig through > the history to see why we tolerate the race. Yes, agree, but seems the cause of the SError on dra7xx and imx6 is different from Layerscape platforms, we need to make it clear first. Thanks, Zhiqiang > > > [0.807773] SError Interrupt on CPU2, code 0xbf02 -- SError > > [0.807775] CPU: 2 PID: 1 Comm: swapper/0 Not tainted > 5.9.0-rc5-next-20200914-1-gf965d3ec86fa #67 > > [0.807776] Hardware name: LS1046A RDB Board (DT) > > [0.80] pstate: 2085 (nzCv daIf -PAN -UAO BTYPE=--) > > [0.807778] pc : pci_generic_config_read+0x3c/0xe0 > > [0.807778] lr : pci_generic_config_read+0x24/0xe0 > > [0.807779] sp : 80001003b7b0 > > [0.807780] x29: 80001003b7b0 x28: 80001003ba74 > > [0.807782] x27: 000971d96800 x26: 00096e77e0a8 > > [0.807784] x25: 80001003b874 x24: 80001003b924 > > [0.807786] x23: 0004 x22: > > [0.807788] x21: x20: 80001003b874 > > [0.807790] x19: 0004 x18: > > [0.807791] x17: 00c0 x16: fe0025981840 > > [0.807793] x15: b94c75b69948 x14: 62203a383634203a > > [0.807795] x13: 666e6f635f726568 x12: 202c31203d207265 > > [0.807797] x11: 626d756e3e2d7375 x10: 656877202c307830 > > [0.807799] x9 : 203d206e66766564 x8 : 0908 > > [0.807801] x7 : 0908 x6 : 80001090 > > [0.807802] x5 : 00096e77e080 x4 : > > [0.807804] x3 : 0003 x2 : 84fa3440ff7e7000 > > [0.807806] x1 : x0 : 800010034000 > > [0.807808] Kernel panic - not syncing: Asynchronous SError Interrupt > > [0.807809] CPU: 2 PID: 1 Comm: swapper/0 Not tainted > 5.9.0-rc5-next-20200914-1-gf965d3ec86fa #67 > > [0.807810] Hardware name: LS1046A RDB Board (DT) > > [0.807811] Call trace: > > [0.807812] dump_backtrace+0x0/0x1c0 > > [0.807813] show_stack+0x18/0x28 > > [0.807814] dump_stack+0xd8/0x134 > > [0.807814] panic+0x180/0x398 > > [0.807815] add_taint+0x0/0xb0 > > [0.807816] arm64_serror_panic+0x78/0x88 > > [0.807817] do_serror+0x68/0x180 > > [0.807818] el1_error+0x84/0x100 > > [0.807818] pci_generic_config_read+0x3c/0xe0 > > [0.807819] dw_pcie_rd_other_conf+0x78/0x110 > > [0.807820] pci_bus_read_config_dword+0x88/0xe8 > > [0.807821] pci_bus_generic_read_dev_vendor_id+0x30/0x1b0 > > [0.807822] pci_bus_read_dev_vendor_id+0x4c/0x78 > > [0.807823] pci_scan_single_device+0x80/0x100 > > [0.807824] pci_scan_slot+0x38/0x130 > > [0.807825] pci_scan_child_bus_extend+0x54/0x2a0 > > [0.807826] pci_scan_child_bus+0x14/0x20 > > [0.807827
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Kishon, > -Original Message- > From: Kishon Vijay Abraham I > Sent: 2020年10月1日 21:32 > To: Rob Herring > Cc: Gustavo Pimentel ; Z.q. Hou > ; Lorenzo Pieralisi ; > linux-kernel@vger.kernel.org; PCI ; Bjorn > Helgaas ; Michael Walle ; Ard > Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > Hi Rob, > > On 30/09/20 8:31 pm, Rob Herring wrote: > > On Wed, Sep 30, 2020 at 8:22 AM Kishon Vijay Abraham I > wrote: > >> > >> Hi, > >> > >> On 29/09/20 10:41 pm, Rob Herring wrote: > >>> On Tue, Sep 29, 2020 at 10:24 AM Gustavo Pimentel > >>> wrote: > >>>> > >>>> On Tue, Sep 29, 2020 at 5:5:41, Z.q. Hou > wrote: > >>>> > >>>>> Hi Lorenzo, > >>>>> > >>>>> Thanks a lot for your comments! > >>>>> > >>>>>> -Original Message- > >>>>>> From: Lorenzo Pieralisi > >>>>>> Sent: 2020年9月28日 17:39 > >>>>>> To: Z.q. Hou > >>>>>> Cc: Rob Herring ; linux-kernel@vger.kernel.org; > >>>>>> PCI ; Bjorn Helgaas > >>>>>> ; Gustavo Pimentel > >>>>>> ; Michael Walle > >>>>>> ; Ard Biesheuvel > >>>>>> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > >>>>>> dw_child_pcie_ops > >>>>>> > >>>>>> On Thu, Sep 24, 2020 at 04:24:47AM +, Z.q. Hou wrote: > >>>>>>> Hi Rob, > >>>>>>> > >>>>>>> Thanks a lot for your comments! > >>>>>>> > >>>>>>>> -Original Message- > >>>>>>>> From: Rob Herring > >>>>>>>> Sent: 2020年9月18日 23:28 > >>>>>>>> To: Z.q. Hou > >>>>>>>> Cc: linux-kernel@vger.kernel.org; PCI > >>>>>>>> ; Lorenzo Pieralisi > >>>>>>>> ; Bjorn Helgaas > >>>>>>>> ; Gustavo Pimentel > >>>>>>>> ; Michael Walle > >>>>>> ; > >>>>>>>> Ard Biesheuvel > >>>>>>>> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus > >>>>>>>> of dw_child_pcie_ops > >>>>>>>> > >>>>>>>> On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou > > >>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Rob, > >>>>>>>>> > >>>>>>>>> Thanks a lot for your comments! > >>>>>>>>> > >>>>>>>>>> -Original Message- > >>>>>>>>>> From: Rob Herring > >>>>>>>>>> Sent: 2020年9月17日 4:29 > >>>>>>>>>> To: Z.q. Hou > >>>>>>>>>> Cc: linux-kernel@vger.kernel.org; PCI > >>>>>>>>>> ; Lorenzo Pieralisi > >>>>>>>>>> ; Bjorn Helgaas > >>>>>>>>>> ; Gustavo Pimentel > >>>>>>>>>> ; Michael Walle > >>>>>>>> ; > >>>>>>>>>> Ard Biesheuvel > >>>>>>>>>> Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus > >>>>>>>>>> of dw_child_pcie_ops > >>>>>>>>>> > >>>>>>>>>> On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou > >>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> From: Hou Zhiqiang > >>>>>>>>>>> > >>>>>>>>>>> On NXP Layerscape platforms, it results in SError in the > >>>>>>>>>>> enumeration of the PCIe controller, which is not connecting > >>>>>>>>>>> with an Endpoint device. And it doesn't make sense to > >>>>>>>>>>> enumerate the Endpoints when the PCIe link is down. So this > >>>>>>>>>>> patch added the link up check to avoid to fire configuration > >>>>>> transactions on link down bus. > >&g
RE: [PATCH] PCI: layerscape: Change back to the default error response behavior
Hi Rob and Kishon, > -Original Message- > From: Rob Herring > Sent: 2020年9月30日 23:08 > To: Kishon Vijay Abraham I > Cc: Z.q. Hou ; PCI ; > linux-kernel@vger.kernel.org; linux-arm-kernel > ; Lorenzo Pieralisi > ; Bjorn Helgaas ; M.h. > Lian ; Roy Zang ; Mingkai > Hu ; Leo Li > Subject: Re: [PATCH] PCI: layerscape: Change back to the default error > response behavior > > On Wed, Sep 30, 2020 at 8:29 AM Kishon Vijay Abraham I > wrote: > > > > Hi Hou, > > > > On 29/09/20 6:43 pm, Zhiqiang Hou wrote: > > > From: Hou Zhiqiang > > > > > > In the current error response behavior, it will send a SLVERR > > > response to device's internal AXI slave system interface when the > > > PCIe controller experiences an erroneous completion (UR, CA and CT) > > > from an external completer for its outbound non-posted request, > > > which will result in SError and crash the kernel directly. > > > This patch change back it to the default behavior to increase the > > > robustness of the kernel. In the default behavior, it always sends > > > an OKAY response to the internal AXI slave interface when the > > > controller gets these erroneous completions. And the AER driver will > > > report and try to recover these errors. > > > > I don't think not forwarding any error interrupts is a good idea. > > Interrupts would be fine. Abort/SError is not. I think it is pretty clear > what the > correct behavior is for config accesses. I agree with Rob. > > > Maybe > > you could disable it while reading configuration space registers > > (vendorID and deviceID) and then enable error forwarding back? > > To add to the locking (or lack of) problems in config accesses? If take this approach, during the hole of CFG access, the error of MEM_rd will also not be forwarded, so it's not a reliable mechanism for user. Thanks, Zhiqiang > > Rob
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
> -Original Message- > From: Rob Herring > Sent: 2020年9月30日 1:11 > To: Gustavo Pimentel > Cc: Z.q. Hou ; Lorenzo Pieralisi > ; linux-kernel@vger.kernel.org; PCI > ; Bjorn Helgaas ; > Michael Walle ; Ard Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Tue, Sep 29, 2020 at 10:24 AM Gustavo Pimentel > wrote: > > > > On Tue, Sep 29, 2020 at 5:5:41, Z.q. Hou wrote: > > > > > Hi Lorenzo, > > > > > > Thanks a lot for your comments! > > > > > > > -----Original Message- > > > > From: Lorenzo Pieralisi > > > > Sent: 2020年9月28日 17:39 > > > > To: Z.q. Hou > > > > Cc: Rob Herring ; linux-kernel@vger.kernel.org; > > > > PCI ; Bjorn Helgaas > > > > ; Gustavo Pimentel > > > > ; Michael Walle > ; > > > > Ard Biesheuvel > > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > > > > dw_child_pcie_ops > > > > > > > > On Thu, Sep 24, 2020 at 04:24:47AM +, Z.q. Hou wrote: > > > > > Hi Rob, > > > > > > > > > > Thanks a lot for your comments! > > > > > > > > > > > -Original Message- > > > > > > From: Rob Herring > > > > > > Sent: 2020年9月18日 23:28 > > > > > > To: Z.q. Hou > > > > > > Cc: linux-kernel@vger.kernel.org; PCI > > > > > > ; Lorenzo Pieralisi > > > > > > ; Bjorn Helgaas > > > > > > ; Gustavo Pimentel > > > > > > ; Michael Walle > > > > ; > > > > > > Ard Biesheuvel > > > > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus > > > > > > of dw_child_pcie_ops > > > > > > > > > > > > On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi Rob, > > > > > > > > > > > > > > Thanks a lot for your comments! > > > > > > > > > > > > > > > -Original Message- > > > > > > > > From: Rob Herring > > > > > > > > Sent: 2020年9月17日 4:29 > > > > > > > > To: Z.q. Hou > > > > > > > > Cc: linux-kernel@vger.kernel.org; PCI > > > > > > > > ; Lorenzo Pieralisi > > > > > > > > ; Bjorn Helgaas > > > > > > > > ; Gustavo Pimentel > > > > > > > > ; Michael Walle > > > > > > ; > > > > > > > > Ard Biesheuvel > > > > > > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in > > > > > > > > map_bus of dw_child_pcie_ops > > > > > > > > > > > > > > > > On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > From: Hou Zhiqiang > > > > > > > > > > > > > > > > > > On NXP Layerscape platforms, it results in SError in the > > > > > > > > > enumeration of the PCIe controller, which is not > > > > > > > > > connecting with an Endpoint device. And it doesn't make > > > > > > > > > sense to enumerate the Endpoints when the PCIe link is > > > > > > > > > down. So this patch added the link up check to avoid to > > > > > > > > > fire configuration > > > > transactions on link down bus. > > > > > > > > > > > > > > > > Michael reported the same issue as well. > > > > > > > > > > > > > > > > What happens if the link goes down between the check and > > > > > > > > the > > > > access? > > > > > > > > > > > > > > This patch cannot cover this case, and will get the SError. > > > > > > > But I think it makes sense to avoid firing transactions on link > > > > > > > down > bus. > > > > > > > > > > > > That's impossible to do without a race even in h/w. > > > > > > > > > > Agree. > > > > > > > &g
RE: [PATCH] PCI: layerscape: Change back to the default error response behavior
Hi Bjorn,
Thanks a lot for your comments!
> -Original Message-
> From: Bjorn Helgaas
> Sent: 2020年9月29日 23:03
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; lorenzo.pieral...@arm.com;
> r...@kernel.org; bhelg...@google.com; M.h. Lian
> ; Roy Zang ; Mingkai Hu
> ; Leo Li
> Subject: Re: [PATCH] PCI: layerscape: Change back to the default error
> response behavior
>
> On Tue, Sep 29, 2020 at 09:13:28PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > In the current error response behavior, it will send a SLVERR response
> > to device's internal AXI slave system interface when the PCIe
> > controller experiences an erroneous completion (UR, CA and CT) from an
> > external completer for its outbound non-posted request, which will
> > result in SError and crash the kernel directly.
>
> Possible wording:
>
> As currently configured, when the PCIe controller receives a
> Completion with UR or CA status, or a Completion Timeout occurs, it
> sends a SLVERR response to the internal AXI slave system interface,
> which results in SError and a kernel crash.
>
> Please add a blank line between paragraphs, and s/This patch change back
> it/Change it/ below.
>
> > This patch change back it to the default behavior to increase the
> > robustness of the kernel. In the default behavior, it always sends an
> > OKAY response to the internal AXI slave interface when the controller
> > gets these erroneous completions. And the AER driver will report and
> > try to recover these errors.
>
> This reverts 84d897d69938 ("PCI: layerscape: Change default error response
> behavior"), so please mention that in the commit log, probably as:
>
> Fixes: 84d897d69938 ("PCI: layerscape: Change default error response
> behavior")
>
> Maybe it also needs a stable tag, e.g., v4.15+?
Thanks for your good suggestions! Will fix in v2.
>
> Since this is a pure revert, whatever problem 84d897d69938 fixed must now
> be fixed in some other way. Otherwise, this revert would just be
> reintroducing the problem fixed by 84d897d69938.
>
> This commit log should mention that what that other fix is.
>
> AER is only a reporting mechanism, it is asynchronous to the instruction
> stream, and it's optional (may not be implemented in the hardware, and may
> not be supported by the kernel), so I'm not super convinced that it can be the
> answer to this problem.
>
The commit 84d897d69938 ("PCI: layerscape: Change default error response
behavior") doesn't fix any issue, it just enable a feature of DesignWare PCIe
IP that it allows error response to AXI slave interface, which are not enabled
on all other platforms with DWC IP. As mentioned in that commit it will also
send an OKAY response to AXI slave interface for erroneous completion of
non-post transaction including CFG and MEM_rd transactions, however upstream
won't support for platforms aborting on CFG accesses, so we have to change it
back to the default error response behavior and bear the error of MEM_rd isn't
forwarded, just like other DWC IP platforms.
I remember the SError interrupt mechanism is also asynchronous abort and it is
only a reporting mechanism. Contrast with the AER, it will make the kernel
crash. So both of these 2 mechanism cannot ensure the data integrity, generally
the upper layer data transfer protocol has its own mechanism to ensure the data
integrity, it's not a issue for almost users. If one really wants a kernel
crash when there is error of MEM_rd, he can enable this in his local code.
Thanks,
Zhiqiang
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pci-layerscape.c | 11 ---
> > 1 file changed, 11 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
> > b/drivers/pci/controller/dwc/pci-layerscape.c
> > index f24f79a70d9a..e92ab8a77046 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> > @@ -30,8 +30,6 @@
> >
> > /* PEX Internal Configuration Registers */
> > #define PCIE_STRFMR1 0x71c /* Symbol Timer & Filter Mask
> Register1 */
> > -#define PCIE_ABSERR0x8d0 /* Bridge Slave Error Response
> Register */
> > -#define PCIE_ABSERR_SETTING0x9401 /* Forward error of
> non-posted request */
> >
> > #define PCIE_IATU_NUM 6
> >
> > @@ -123,14 +121,6 @@ static int ls_pcie_link_up(struct dw_pcie *pci)
> > return 1;
> > }
> >
> > -/* Forward error response of outbound non-posted reque
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Lorenzo, Thanks a lot for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2020年9月28日 17:39 > To: Z.q. Hou > Cc: Rob Herring ; linux-kernel@vger.kernel.org; PCI > ; Bjorn Helgaas ; > Gustavo Pimentel ; Michael Walle > ; Ard Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Thu, Sep 24, 2020 at 04:24:47AM +, Z.q. Hou wrote: > > Hi Rob, > > > > Thanks a lot for your comments! > > > > > -Original Message----- > > > From: Rob Herring > > > Sent: 2020年9月18日 23:28 > > > To: Z.q. Hou > > > Cc: linux-kernel@vger.kernel.org; PCI ; > > > Lorenzo Pieralisi ; Bjorn Helgaas > > > ; Gustavo Pimentel > > > ; Michael Walle > ; > > > Ard Biesheuvel > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > > > dw_child_pcie_ops > > > > > > On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou > wrote: > > > > > > > > Hi Rob, > > > > > > > > Thanks a lot for your comments! > > > > > > > > > -Original Message- > > > > > From: Rob Herring > > > > > Sent: 2020年9月17日 4:29 > > > > > To: Z.q. Hou > > > > > Cc: linux-kernel@vger.kernel.org; PCI > > > > > ; Lorenzo Pieralisi > > > > > ; Bjorn Helgaas > > > > > ; Gustavo Pimentel > > > > > ; Michael Walle > > > ; > > > > > Ard Biesheuvel > > > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > > > > > dw_child_pcie_ops > > > > > > > > > > On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou > > > > > > > > wrote: > > > > > > > > > > > > From: Hou Zhiqiang > > > > > > > > > > > > On NXP Layerscape platforms, it results in SError in the > > > > > > enumeration of the PCIe controller, which is not connecting > > > > > > with an Endpoint device. And it doesn't make sense to > > > > > > enumerate the Endpoints when the PCIe link is down. So this > > > > > > patch added the link up check to avoid to fire configuration > transactions on link down bus. > > > > > > > > > > Michael reported the same issue as well. > > > > > > > > > > What happens if the link goes down between the check and the > access? > > > > > > > > This patch cannot cover this case, and will get the SError. > > > > But I think it makes sense to avoid firing transactions on link down > > > > bus. > > > > > > That's impossible to do without a race even in h/w. > > > > Agree. > > > > > > > > > > It's a racy check. I'd like to find an alternative solution. > > > > > It's even worse if Layerscape is used in ECAM mode. I looked at > > > > > the EDK2 setup for layerscape[1] and it looks like root ports > > > > > are just skipped if link > > > is down. > > > > > Maybe a link down just never happens once up, but if so, then we > > > > > only need to check it once and fail probe. > > > > > > > > Many customers connect the FPGA Endpoint, which may establish PCIe > > > > link after the PCIe enumeration and then rescan the PCIe bus, so I > > > > think it should not exit the probe of root port even if there is > > > > not link up > > > during enumeration. > > > > > > That's a good reason. I want to unify the behavior here as it varies > > > per platform currently and wasn't sure which way to go. > > > > > > > > > > > I've dug into this a bit more and am curious about the > > > > > PCIE_ABSERR register setting which is set to: > > > > > > > > > > #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of > > > > > non-posted request */ > > > > > > > > > > It seems to me this is not what we want at least for config > > > > > accesses, but commit 84d897d6993 where this was added seems to > > > > > say otherwise. Is it not possible to configure the response per access > type? > > > > > > > > Thanks a lot for your investigation! > > > > The story is like this: Some customers worry about these silent > > > > error (DWC PCIe IP won't
RE: [PATCH v6 04/11] PCI: designware-ep: Modify MSI and MSIX CAP way of finding
Hi Bjorn,
Thanks a lot for your comments!
> -Original Message-
> From: Bjorn Helgaas
> Sent: 2020年9月24日 4:16
> To: Xiaowei Bao
> Cc: Z.q. Hou ; M.h. Lian
> ; Mingkai Hu ;
> bhelg...@google.com; robh...@kernel.org; shawn...@kernel.org; Leo Li
> ; kis...@ti.com; lorenzo.pieral...@arm.com; Roy
> Zang ; amur...@thegoodpenguin.co.uk;
> jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> andrew.mur...@arm.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH v6 04/11] PCI: designware-ep: Modify MSI and MSIX
> CAP way of finding
>
> s/MSIX/MSI-X/ (subject and below)
>
> On Sat, Mar 14, 2020 at 11:30:31AM +0800, Xiaowei Bao wrote:
> > Each PF of EP device should have it's own MSI or MSIX capabitily
> > struct, so create a dw_pcie_ep_func struct and remove the msi_cap and
> > msix_cap to this struct from dw_pcie_ep, and manage the PFs with a
> > list.
>
> s/capabitily/capability/
>
> I know Lorenzo has already applied this, but for the future, or in case there
> are other reasons to update this patch.
>
> There are a bunch of unnecessary initializations below for future cleanup.
Yes, and there are many calling of dw_pcie_ep_func_select() to get func_offset,
I plan to submit a separate patch to clean up.
Thanks,
Zhiqiang
>
> > Signed-off-by: Xiaowei Bao
> > ---
> > v3:
> > - This is a new patch, to fix the issue of MSI and MSIX CAP way of
> >finding.
> > v4:
> > - Correct some word of commit message.
> > v5:
> > - No change.
> > v6:
> > - Fix up the compile error.
> >
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 135
> +---
> > drivers/pci/controller/dwc/pcie-designware.h| 18 +++-
> > 2 files changed, 134 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 933bb89..fb915f2 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -19,6 +19,19 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > pci_epc_linkup(epc);
> > }
> >
> > +struct dw_pcie_ep_func *
> > +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no) {
> > + struct dw_pcie_ep_func *ep_func;
> > +
> > + list_for_each_entry(ep_func, >func_list, list) {
> > + if (ep_func->func_no == func_no)
> > + return ep_func;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8
> > func_no) {
> > unsigned int func_offset = 0;
> > @@ -59,6 +72,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci,
> enum pci_barno bar)
> > __dw_pcie_ep_reset_bar(pci, func_no, bar, 0); }
> >
> > +static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8
> func_no,
> > + u8 cap_ptr, u8 cap)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
>
> Unnecessary initialization.
>
> > + u8 cap_id, next_cap_ptr;
> > + u16 reg;
> > +
> > + if (!cap_ptr)
> > + return 0;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
> > + cap_id = (reg & 0x00ff);
> > +
> > + if (cap_id > PCI_CAP_ID_MAX)
> > + return 0;
> > +
> > + if (cap_id == cap)
> > + return cap_ptr;
> > +
> > + next_cap_ptr = (reg & 0xff00) >> 8;
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
> > +
> > +static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8
> > +func_no, u8 cap) {
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
>
> Unnecessary initialization.
>
> > + u8 next_cap_ptr;
> > + u16 reg;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
> > + next_cap_ptr = (reg & 0x00ff);
> > +
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
> > +
> > static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> >struct pci_epf_header *hdr)
> &
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Rob, Thanks a lot for your comments! > -Original Message- > From: Rob Herring > Sent: 2020年9月18日 23:28 > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; PCI ; Lorenzo > Pieralisi ; Bjorn Helgaas > ; Gustavo Pimentel > ; Michael Walle ; > Ard Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Fri, Sep 18, 2020 at 5:02 AM Z.q. Hou wrote: > > > > Hi Rob, > > > > Thanks a lot for your comments! > > > > > -Original Message- > > > From: Rob Herring > > > Sent: 2020年9月17日 4:29 > > > To: Z.q. Hou > > > Cc: linux-kernel@vger.kernel.org; PCI ; > > > Lorenzo Pieralisi ; Bjorn Helgaas > > > ; Gustavo Pimentel > > > ; Michael Walle > ; > > > Ard Biesheuvel > > > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > > > dw_child_pcie_ops > > > > > > On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou > > > > wrote: > > > > > > > > From: Hou Zhiqiang > > > > > > > > On NXP Layerscape platforms, it results in SError in the > > > > enumeration of the PCIe controller, which is not connecting with > > > > an Endpoint device. And it doesn't make sense to enumerate the > > > > Endpoints when the PCIe link is down. So this patch added the link > > > > up check to avoid to fire configuration transactions on link down bus. > > > > > > Michael reported the same issue as well. > > > > > > What happens if the link goes down between the check and the access? > > > > This patch cannot cover this case, and will get the SError. > > But I think it makes sense to avoid firing transactions on link down bus. > > That's impossible to do without a race even in h/w. Agree. > > > > It's a racy check. I'd like to find an alternative solution. It's > > > even worse if Layerscape is used in ECAM mode. I looked at the EDK2 > > > setup for layerscape[1] and it looks like root ports are just skipped if > > > link > is down. > > > Maybe a link down just never happens once up, but if so, then we > > > only need to check it once and fail probe. > > > > Many customers connect the FPGA Endpoint, which may establish PCIe > > link after the PCIe enumeration and then rescan the PCIe bus, so I > > think it should not exit the probe of root port even if there is not link up > during enumeration. > > That's a good reason. I want to unify the behavior here as it varies per > platform currently and wasn't sure which way to go. > > > > > I've dug into this a bit more and am curious about the PCIE_ABSERR > > > register setting which is set to: > > > > > > #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of non-posted > > > request */ > > > > > > It seems to me this is not what we want at least for config > > > accesses, but commit 84d897d6993 where this was added seems to say > > > otherwise. Is it not possible to configure the response per access type? > > > > Thanks a lot for your investigation! > > The story is like this: Some customers worry about these silent error > > (DWC PCIe IP won't forward the error of outbound non-post request by > > default), so we were pushed to enable the error forwarding to AXI in > > the commit > > 84d897d6993 as you saw. But it cannot differentiate the config > > transactions from the MEM_rd, except the Vendor ID access, which is > > controlled by a separate bit and it was set to not forward error of access > of Vendor ID. > > So we think it's okay to enable the error forwarding, the SError > > should not occur, because after the enumeration it won't access the > non-existent functions. > > We've rejected upstream support for platforms aborting on config > accesses[1]. I think there's clear consensus that aborting is the wrong > behavior. > > Do MEM_wr errors get forwarded? Seems like that would be enough. Also, > wouldn't page faults catch most OOB accesses anyways? You need things > page aligned anyways with an IOMMU and doing userspace access or guest > assignment. Yes, errors of MEM_wr can be forwarded. > > Here's another idea, how about only enabling forwarding errors if the link is > up? If really would need to be configured any time the link state changes > rather than just at probe. I'm not sure if you have a way to disable it on > link > down though. Dug deeper into this issue and found the setting of not forwarding error of non-existent Vender ID access counts on the link partner: 1. When there is a link partner (namely link up), it will return 0x when read non-existent function Vendor ID and won't forward error to AXI. 2. When no link partner (link down), it will forward the error of reading non-existent function Vendor ID to AXI and result in SError. I think this is a DWC PCIe IP specific issue but not get feedback from design team. I'm thinking to disable this error forwarding just like other platforms, since when these errors (UR, CA and CT) are detected, AER driver can also report the error and try to recover. Thanks, Zhiqiang > > Rob
RE: [PATCH 6/7] dts: arm64: ls1043a: Add SCFG phandle for PCIe nodes
Hi Shawn, Thanks a lot for your comments! > -Original Message- > From: Shawn Guo > Sent: 2020年9月21日 21:17 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org; > Leo Li ; lorenzo.pieral...@arm.com; > gustavo.pimen...@synopsys.com; M.h. Lian ; > Mingkai Hu ; Roy Zang > Subject: Re: [PATCH 6/7] dts: arm64: ls1043a: Add SCFG phandle for PCIe > nodes > > On Mon, Sep 07, 2020 at 01:38:00PM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > The LS1043A PCIe controller has some control registers in SCFG block, > > so add the SCFG phandle for each PCIe controller DT node. > > > > Signed-off-by: Hou Zhiqiang > > 'arm64: dts: ...' for subject prefix. Will correct it in next version. Regards, Zhiqiang > > Shawn
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Bjorn, Thanks a lot for your comments! > -Original Message- > From: Bjorn Helgaas > Sent: 2020年9月18日 20:47 > To: Z.q. Hou > Cc: Rob Herring ; linux-kernel@vger.kernel.org; PCI > ; Lorenzo Pieralisi ; > Bjorn Helgaas ; Gustavo Pimentel > ; Michael Walle ; > Ard Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Fri, Sep 18, 2020 at 11:02:07AM +, Z.q. Hou wrote: > > > But now the SError is exactly caused by the first access of the > > non-existent function, I dug into the kernel enumeration code and > > found it will fire a 4Byte CFG read transaction to read the Vendor ID > > and Device ID together, so I suspect the root cause is access the > > Device ID of a non-existent function triggers SError. > > > > So the alternative solution seems to correct the PCIe enumeration, I > > will submit a patch to let the first access only read the Vendor ID. > > If it is incorrect for the first access to be a 32-bit read of both the Vendor > and the Device ID, please cite the relevant section of the spec in your patch. > > I don't like to make changes to generic code to accommodate specific pieces > of hardware because then we restrict future changes based on some device > that will soon be obsolete and forgotten. > > I'm pretty sure the spec language about CRS handling is careful to talk about > "reads that *include* Vendor ID", not just "reads of Vendor ID", so the > implication is that it covers 32-bit reads as well as 16-bit reads. > Yes, I agree with you that we must be carful with the generic code. NXP Layerscape SError aside, it turns out to be more complex, limiting the first CFG access to 16-bit Vendor ID also causes SError, the hardware behavior seems not the same as the described of the register PCIE_ABSERR. For the PCIe enumeration, I found the descriptions of Vendor ID and Device ID in the PCI Express Base Specification, Rev. 4.0 Version 1.0 (pasted below), it recommends to read Vendor ID to determine the presentence of a function and use the Device ID (with Vendor ID and Revision ID) to determine the driver needed. But in section 2.3.2 Completion Handling Rules, it seems, as you said, not limit to 16-bit Vendor ID, so I want to hear your and Rob's suggestion on this change. 7.5.1.1.1 Vendor ID Register (Offset 00h) The Vendor ID register is HwInit and the value in this register identifies the manufacturer of the Function. In keeping with PCI-SIG procedures, valid vendor identifiers must be allocated by the PCI-SIG to ensure uniqueness. Each vendor must have at least one Vendor ID. It is recommended that software read the Vendor ID register to determine if a Function is present, where a value of h indicates that no Function is present. 7.5.1.1.2 Device ID Register (Offset 02h) The Device ID register is HwInit and the value in this register identifies the particular Function. The Device ID must be allocated by the vendor. The Device ID, in conjunction with the Vendor ID and Revision ID, are used as one mechanism for software to determine which driver should be loaded. The vendor must ensure that the chosen values do not result in the use of an incompatible device driver. Regards, Zhiqiang > Bjorn
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Michael, Thanks a lot for your comments! > -Original Message- > From: Michael Walle > Sent: 2020年9月18日 19:14 > To: Z.q. Hou > Cc: Rob Herring ; linux-kernel@vger.kernel.org; PCI > ; Lorenzo Pieralisi ; > Bjorn Helgaas ; Gustavo Pimentel > ; Ard Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > Hi Zhiqiang, > > > So the alternative solution seems to correct the PCIe enumeration, I > > will submit a patch to let the first access only read the Vendor ID. > > Please put me on CC of that patch. Saw more comments on this, I'll discuss more with Rob and Bjorn, and must act prudently. Regards, Zhiqiang > > Thanks, > -michael
RE: [PATCH] PCI: dwc: Added link up check in map_bus of dw_child_pcie_ops
Hi Rob, Thanks a lot for your comments! > -Original Message- > From: Rob Herring > Sent: 2020年9月17日 4:29 > To: Z.q. Hou > Cc: linux-kernel@vger.kernel.org; PCI ; Lorenzo > Pieralisi ; Bjorn Helgaas > ; Gustavo Pimentel > ; Michael Walle ; > Ard Biesheuvel > Subject: Re: [PATCH] PCI: dwc: Added link up check in map_bus of > dw_child_pcie_ops > > On Tue, Sep 15, 2020 at 11:49 PM Zhiqiang Hou > wrote: > > > > From: Hou Zhiqiang > > > > On NXP Layerscape platforms, it results in SError in the enumeration > > of the PCIe controller, which is not connecting with an Endpoint > > device. And it doesn't make sense to enumerate the Endpoints when the > > PCIe link is down. So this patch added the link up check to avoid to > > fire configuration transactions on link down bus. > > Michael reported the same issue as well. > > What happens if the link goes down between the check and the access? This patch cannot cover this case, and will get the SError. But I think it makes sense to avoid firing transactions on link down bus. > It's a racy check. I'd like to find an alternative solution. It's even worse > if > Layerscape is used in ECAM mode. I looked at the EDK2 setup for > layerscape[1] and it looks like root ports are just skipped if link is down. > Maybe a link down just never happens once up, but if so, then we only need > to check it once and fail probe. Many customers connect the FPGA Endpoint, which may establish PCIe link after the PCIe enumeration and then rescan the PCIe bus, so I think it should not exit the probe of root port even if there is not link up during enumeration. > > I've dug into this a bit more and am curious about the PCIE_ABSERR register > setting which is set to: > > #define PCIE_ABSERR_SETTING 0x9401 /* Forward error of non-posted > request */ > > It seems to me this is not what we want at least for config accesses, but > commit 84d897d6993 where this was added seems to say otherwise. Is it not > possible to configure the response per access type? Thanks a lot for your investigation! The story is like this: Some customers worry about these silent error (DWC PCIe IP won't forward the error of outbound non-post request by default), so we were pushed to enable the error forwarding to AXI in the commit 84d897d6993 as you saw. But it cannot differentiate the config transactions from the MEM_rd, except the Vendor ID access, which is controlled by a separate bit and it was set to not forward error of access of Vendor ID. So we think it's okay to enable the error forwarding, the SError should not occur, because after the enumeration it won't access the non-existent functions. But now the SError is exactly caused by the first access of the non-existent function, I dug into the kernel enumeration code and found it will fire a 4Byte CFG read transaction to read the Vendor ID and Device ID together, so I suspect the root cause is access the Device ID of a non-existent function triggers SError. So the alternative solution seems to correct the PCIe enumeration, I will submit a patch to let the first access only read the Vendor ID. Thanks, Zhiqiang > > This appears to be a standard DWC register as the tegra driver defines this > address as PORT_LOGIC_AMBA_ERROR_RESPONSE_DEFAULT. Perhaps > someone can shed some light on what this register contains. > > Rob > > [1] > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.lin > aro.org%2Fleg%2Fnoupstream%2Fedk2-platforms.git%2Ftree%2FSilicon%2F > NXP%2FLibrary%2FPciHostBridgeLib%2FPciHostBridgeLib.c%3Fh%3Ddevelop > er-box%23n756data=02%7C01%7CZhiqiang.Hou%40nxp.com%7Cfa38 > f3e83d0c49983e0c08d85a7f2d5e%7C686ea1d3bc2b4c6fa92cd99c5c301635 > %7C0%7C0%7C637358849549791506sdata=bJ3uDUm%2FT%2FzC6qz > GX7NNHQZdDxNFZ%2BBtcEQ3sLQIE4M%3Dreserved=0 > > > > > > [0.807773] SError Interrupt on CPU2, code 0xbf02 -- SError > > [0.807775] CPU: 2 PID: 1 Comm: swapper/0 Not tainted > 5.9.0-rc5-next-20200914-1-gf965d3ec86fa #67 > > [0.807776] Hardware name: LS1046A RDB Board (DT) > > [0.80] pstate: 2085 (nzCv daIf -PAN -UAO BTYPE=--) > > [0.807778] pc : pci_generic_config_read+0x3c/0xe0 > > [0.807778] lr : pci_generic_config_read+0x24/0xe0 > > [0.807779] sp : 80001003b7b0 > > [0.807780] x29: 80001003b7b0 x28: 80001003ba74 > > [0.807782] x27: 000971d96800 x26: 00096e77e0a8 > > [0.807784] x25: 80001003b874 x24: 80001003b924 > > [0.807786] x23: 0004 x22: > > [0.807788] x21: x20: 80001003b874 > > [0.807790] x19: 0004 x18: > > [0.807791] x17: 00c0 x
RE: [PATCHv7 04/12] PCI: designware-ep: Modify MSI and MSIX CAP way of finding
Hi Rob,
> -Original Message-
> From: Rob Herring
> Sent: 2020年9月11日 2:10
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linuxppc-...@lists.ozlabs.org; bhelg...@google.com;
> lorenzo.pieral...@arm.com; shawn...@kernel.org; Leo Li
> ; kis...@ti.com; gustavo.pimen...@synopsys.com;
> Roy Zang ; jingooh...@gmail.com;
> andrew.mur...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: Re: [PATCHv7 04/12] PCI: designware-ep: Modify MSI and MSIX CAP
> way of finding
>
> On Tue, Aug 11, 2020 at 05:54:33PM +0800, Zhiqiang Hou wrote:
> > From: Xiaowei Bao
> >
> > Each PF of EP device should have its own MSI or MSIX capabitily
> > struct, so create a dw_pcie_ep_func struct and move the msi_cap and
> > msix_cap to this struct from dw_pcie_ep, and manage the PFs via a
> > list.
> >
> > Signed-off-by: Xiaowei Bao
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V7:
> > - Rebase the patch without functionality change.
> >
> > .../pci/controller/dwc/pcie-designware-ep.c | 139
> +++---
> > drivers/pci/controller/dwc/pcie-designware.h | 18 ++-
> > 2 files changed, 136 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 56bd1cd71f16..4680a51c49c0 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -28,6 +28,19 @@ void dw_pcie_ep_init_notify(struct dw_pcie_ep
> *ep)
> > } EXPORT_SYMBOL_GPL(dw_pcie_ep_init_notify);
> >
> > +struct dw_pcie_ep_func *
> > +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no) {
> > + struct dw_pcie_ep_func *ep_func;
> > +
> > + list_for_each_entry(ep_func, >func_list, list) {
> > + if (ep_func->func_no == func_no)
> > + return ep_func;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8
> > func_no) {
> > unsigned int func_offset = 0;
> > @@ -68,6 +81,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci,
> enum pci_barno bar)
> > __dw_pcie_ep_reset_bar(pci, func_no, bar, 0); }
> >
> > +static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8
> func_no,
> > + u8 cap_ptr, u8 cap)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
> > + u8 cap_id, next_cap_ptr;
> > + u16 reg;
> > +
> > + if (!cap_ptr)
> > + return 0;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
> > + cap_id = (reg & 0x00ff);
> > +
> > + if (cap_id > PCI_CAP_ID_MAX)
> > + return 0;
> > +
> > + if (cap_id == cap)
> > + return cap_ptr;
> > +
> > + next_cap_ptr = (reg & 0xff00) >> 8;
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
> > +
> > +static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8
> > +func_no, u8 cap) {
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
> > + u8 next_cap_ptr;
> > + u16 reg;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
> > + next_cap_ptr = (reg & 0x00ff);
> > +
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
>
> These are almost the same as __dw_pcie_find_next_cap and
> dw_pcie_find_capability. Please modify them to take a function offset and
> work for both host and endpoints.
>
I sent out v8 patches but without the rework of the functions of finding
capability, I will submit a separate patch to do this.
> > +
> > static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> >struct pci_epf_header *hdr)
> > {
> > @@ -257,13 +311,18 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> *epc, u8 func_no)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > unsigned int func_offset = 0;
> > + struct dw_pcie_ep_func *ep_func;
> >
> > - if (!ep->msi_cap)
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > +
RE: [PATCHv7 00/12]PCI: dwc: Add the multiple PF support for DWC and Layerscape
Hi Lorenzo, Thanks a lot for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2020年9月18日 0:20 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linuxppc-...@lists.ozlabs.org; robh...@kernel.org; bhelg...@google.com; > shawn...@kernel.org; Leo Li ; kis...@ti.com; > gustavo.pimen...@synopsys.com; Roy Zang ; > jingooh...@gmail.com; andrew.mur...@arm.com; Mingkai Hu > ; M.h. Lian > Subject: Re: [PATCHv7 00/12]PCI: dwc: Add the multiple PF support for DWC > and Layerscape > > On Tue, Aug 11, 2020 at 05:54:29PM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > Add the PCIe EP multiple PF support for DWC and Layerscape, and use a > > list to manage the PFs of each PCIe controller; add the doorbell MSIX > > function for DWC; and refactor the Layerscape EP driver due to some > > difference in Layercape platforms PCIe integration. > > > > Hou Zhiqiang (1): > > misc: pci_endpoint_test: Add driver data for Layerscape PCIe > > controllers > > > > Xiaowei Bao (11): > > PCI: designware-ep: Add multiple PFs support for DWC > > PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode > > PCI: designware-ep: Move the function of getting MSI capability > > forward > > PCI: designware-ep: Modify MSI and MSIX CAP way of finding > > dt-bindings: pci: layerscape-pci: Add compatible strings for ls1088a > > and ls2088a > > PCI: layerscape: Fix some format issue of the code > > PCI: layerscape: Modify the way of getting capability with different > > PEX > > PCI: layerscape: Modify the MSIX to the doorbell mode > > PCI: layerscape: Add EP mode support for ls1088a and ls2088a > > arm64: dts: layerscape: Add PCIe EP node for ls1088a > > misc: pci_endpoint_test: Add LS1088a in pci_device_id table > > > > .../bindings/pci/layerscape-pci.txt | 2 + > > .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 +++ > > drivers/misc/pci_endpoint_test.c | 8 +- > > .../pci/controller/dwc/pci-layerscape-ep.c| 100 +-- > > .../pci/controller/dwc/pcie-designware-ep.c | 258 > ++ > > drivers/pci/controller/dwc/pcie-designware.c | 59 ++-- > > drivers/pci/controller/dwc/pcie-designware.h | 48 +++- > > 7 files changed, 410 insertions(+), 96 deletions(-) > > Side note: I will change it for you but please keep Signed-off-by: > tags together in the log instead of mixing them with other tags randomly. > > Can you rebase this series against my pci/dwc branch please and send a v8 ? > > I will apply it then. I'll rebase this series and put the Signed-off-by tags together today. Regards, Zhiqiang > > Thanks, > Lorenzo
RE: [PATCH 7/7] PCI: layerscape: Add power management support
Hi Rob,
Thanks a lot for your comments!
> -Original Message-
> From: Rob Herring
> Sent: 2020年9月15日 9:30
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com;
> shawn...@kernel.org; Leo Li ;
> lorenzo.pieral...@arm.com; gustavo.pimen...@synopsys.com; M.h. Lian
> ; Mingkai Hu ; Roy Zang
>
> Subject: Re: [PATCH 7/7] PCI: layerscape: Add power management support
>
> On Mon, Sep 07, 2020 at 01:38:01PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > Add PME_Turn_Off/PME_TO_Ack handshake sequence, and finally put the
> > PCIe controller into D3 state after the L2/L3 ready state transition
> > process completion.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pci-layerscape.c | 384
> ++-
> > drivers/pci/controller/dwc/pcie-designware.h | 1 +
> > 2 files changed, 383 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
> > b/drivers/pci/controller/dwc/pci-layerscape.c
> > index be404c16bcbe..ca9ea07f77c1 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> > @@ -3,13 +3,16 @@
> > * PCIe host controller driver for Freescale Layerscape SoCs
> > *
> > * Copyright (C) 2014 Freescale Semiconductor.
> > + * Copyright 2020 NXP
> > *
> > * Author: Minghuan Lian
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -27,17 +30,66 @@
> > #define PCIE_ABSERR0x8d0 /* Bridge Slave Error Response
> Register */
> > #define PCIE_ABSERR_SETTING0x9401 /* Forward error of
> non-posted request */
> >
> > +#define PCIE_PM_SCR0x44
> > +#define PCIE_PM_SCR_PMEPS_D0 0x0
> > +#define PCIE_PM_SCR_PMEPS_D3 0x3
> > +
> > +#define PCIE_LNKCTL0x80 /* PCIe link ctrl Register */
>
> Use the common defines.
>
OK, will change in next version.
>
> > +
> > +/* PF Message Command Register */
> > +#define LS_PCIE_PF_MCR 0x2c
> > +#define PF_MCR_PTOMR BIT(0)
> > +#define PF_MCR_EXL2S BIT(1)
> > +
> > +/* LS1021A PEXn PM Write Control Register */
> > +#define SCFG_PEXPMWRCR(idx)(0x5c + (idx) * 0x64)
> > +#define PMXMTTURNOFF BIT(31)
> > +#define SCFG_PEXSFTRSTCR 0x190
> > +#define PEXSR(idx) BIT(idx)
> > +
> > +/* LS1043A PEX PME control register */
> > +#define SCFG_PEXPMECR 0x144
> > +#define PEXPME(idx)BIT(31 - (idx) * 4)
> > +
> > +/* LS1043A PEX LUT debug register */
> > +#define LS_PCIE_LDBG 0x7fc
> > +#define LDBG_SRBIT(30)
> > +#define LDBG_WEBIT(31)
> > +
> > #define PCIE_IATU_NUM 6
> >
> > +#define LS_PCIE_IS_L2(v) \
> > + (((v) & PORT_LOGIC_LTSSM_STATE_MASK) ==
> PORT_LOGIC_LTSSM_STATE_L2)
> > +
> > +struct ls_pcie;
> > +
> > +struct ls_pcie_host_pm_ops {
> > + int (*pm_init)(struct ls_pcie *pcie);
> > + void (*send_turn_off_message)(struct ls_pcie *pcie);
> > + void (*exit_from_l2)(struct ls_pcie *pcie); };
> > +
> > struct ls_pcie_drvdata {
> > + const u32 pf_off;
> > + const u32 lut_off;
> > const struct dw_pcie_host_ops *ops;
> > + const struct ls_pcie_host_pm_ops *pm_ops;
> > };
> >
> > struct ls_pcie {
> > struct dw_pcie *pci;
> > const struct ls_pcie_drvdata *drvdata;
> > + void __iomem *pf_base;
> > + void __iomem *lut_base;
> > + bool big_endian;
> > + bool ep_presence;
> > + bool pm_support;
> > + struct regmap *scfg;
> > + int index;
> > };
> >
> > +#define ls_pcie_lut_readl_addr(addr) ls_pcie_lut_readl(pcie, addr)
> > +#define ls_pcie_pf_readl_addr(addr)ls_pcie_pf_readl(pcie, addr)
> > #define to_ls_pcie(x) dev_get_drvdata((x)->dev)
> >
> > static bool ls_pcie_is_bridge(struct ls_pcie *pcie) @@ -86,6 +138,208
> > @@ static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
> > iowrite32(PCIE_ABSERR_SETTING, pci->dbi_base + PCIE_ABSERR); }
> >
> > +static u32 ls_pcie_lut_readl(struct ls_pcie *pcie, u32 off) {
> > + if (pcie->big_endian)
> > + return ioread32be(pcie->
RE: [PATCH 2/7] PCI: layerscape: Change to use the DWC common link-up check function
Hi Rob, Thanks a lot for your review! > -Original Message- > From: Rob Herring > Sent: 2020年9月15日 9:20 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; bhelg...@google.com; > shawn...@kernel.org; Leo Li ; > lorenzo.pieral...@arm.com; gustavo.pimen...@synopsys.com; M.h. Lian > ; Mingkai Hu ; Roy Zang > > Subject: Re: [PATCH 2/7] PCI: layerscape: Change to use the DWC common > link-up check function > > On Mon, Sep 07, 2020 at 01:37:56PM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > The current Layerscape PCIe driver directly uses the physical layer > > LTSSM code to check the link-up state, which treats the > L0 states as > > link-up. This is not correct, since there is not explicit map between > > link-up state and LTSSM. So this patch changes to use the DWC common > > link-up check function. > > > > Signed-off-by: Hou Zhiqiang > > --- > > drivers/pci/controller/dwc/pci-layerscape.c | 141 > > ++-- > > 1 file changed, 10 insertions(+), 131 deletions(-) > > IIRC, the common function uses a debug register. I've been wondering do > the common PCIe config space registers not work on DWC? If you have an > answer, that would be great for some potential additional cleanups. > You're right it uses a port debug register, but I'm not sure if the Link status Register of common PCIe config space works or not on DWC. Gustavo, can you help answer this query? Regards, Zhiqiang > Either way, > > Reviewed-by: Rob Herring
RE: [PATCH 5/7] dt-bindings: pci: layerscape-pci: Update the description of SCFG property
Hi Rob, Thanks a lot for your review and ack! Regards, Zhiqiang > -Original Message- > From: Rob Herring > Sent: 2020年9月15日 9:31 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; M.h. Lian > ; devicet...@vger.kernel.org; > gustavo.pimen...@synopsys.com; robh...@kernel.org; Mingkai Hu > ; Roy Zang ; > shawn...@kernel.org; Leo Li ; > bhelg...@google.com; lorenzo.pieral...@arm.com > Subject: Re: [PATCH 5/7] dt-bindings: pci: layerscape-pci: Update the > description of SCFG property > > On Mon, 07 Sep 2020 13:37:59 +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > Update the description of the second entry of 'fsl,pcie-scfg' > > property, as the LS1043A PCIe controller also has some control > > registers in SCFG block, while it has 3 controllers. > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/pci/layerscape-pci.txt | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Acked-by: Rob Herring
RE: [PATCH 3/7] dt-bindings: pci: layerscape-pci: Add a optional property big-endian
Hi Rob, Thanks a lot for your review and ack! Regards, Zhiqiang > -Original Message- > From: Rob Herring > Sent: 2020年9月15日 9:31 > To: Z.q. Hou > Cc: bhelg...@google.com; linux-kernel@vger.kernel.org; > shawn...@kernel.org; Leo Li ; > linux-...@vger.kernel.org; M.h. Lian ; > robh...@kernel.org; gustavo.pimen...@synopsys.com; > lorenzo.pieral...@arm.com; Roy Zang ; Mingkai Hu > ; devicet...@vger.kernel.org > Subject: Re: [PATCH 3/7] dt-bindings: pci: layerscape-pci: Add a optional > property big-endian > > On Mon, 07 Sep 2020 13:37:57 +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > This property is to indicate the endianness when accessing the PEX_LUT > > and PF register block, so if these registers are implemented in > > big-endian, specify this property. > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 > > 1 file changed, 4 insertions(+) > > > > Acked-by: Rob Herring
RE: [PATCH 1/7] PCI: dwc: Fix a bug of the case dw_pci->ops is NULL
Hi Rob, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Rob Herring > Sent: 2020年9月15日 9:16 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; bhelg...@google.com; > shawn...@kernel.org; Leo Li ; > lorenzo.pieral...@arm.com; gustavo.pimen...@synopsys.com; M.h. Lian > ; Mingkai Hu ; Roy Zang > > Subject: Re: [PATCH 1/7] PCI: dwc: Fix a bug of the case dw_pci->ops is NULL > > On Mon, Sep 07, 2020 at 01:37:55PM +0800, Zhiqiang Hou wrote: > > From: Hou Zhiqiang > > > > The dw_pci->ops may be a NULL, and fix it by adding one more check. > > > > Signed-off-by: Hou Zhiqiang > > --- > > drivers/pci/controller/dwc/pcie-designware.c | 12 ++-- > > 1 file changed, 6 insertions(+), 6 deletions(-) > > Reviewed-by: Rob Herring > > Note that this may conflict with my 40 patch clean-up series. > > Rob
RE: [PATCHv7 12/12] misc: pci_endpoint_test: Add driver data for Layerscape PCIe controllers
Hi Rob,
Thanks a lot for your review and ack!
Regards,
Zhiqiang
> -Original Message-
> From: Rob Herring
> Sent: 2020年9月11日 2:18
> To: Z.q. Hou
> Cc: bhelg...@google.com; shawn...@kernel.org; M.h. Lian
> ; Leo Li ;
> linuxppc-...@lists.ozlabs.org; robh...@kernel.org;
> linux-arm-ker...@lists.infradead.org; Roy Zang ;
> andrew.mur...@arm.com; linux-...@vger.kernel.org;
> lorenzo.pieral...@arm.com; gustavo.pimen...@synopsys.com; Mingkai Hu
> ; linux-kernel@vger.kernel.org;
> jingooh...@gmail.com; kis...@ti.com; devicet...@vger.kernel.org
> Subject: Re: [PATCHv7 12/12] misc: pci_endpoint_test: Add driver data for
> Layerscape PCIe controllers
>
> On Tue, 11 Aug 2020 17:54:41 +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > The commit 0a121f9bc3f5 ("misc: pci_endpoint_test: Use streaming DMA
> > APIs for buffer allocation") changed to use streaming DMA APIs,
> > however,
> > dma_map_single() might not return a 4KB aligned address, so add the
> > default_data as driver data for Layerscape PCIe controllers to make it
> > 4KB aligned.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V7:
> > - New patch.
> >
> > drivers/misc/pci_endpoint_test.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
>
> Acked-by: Rob Herring
RE: [PATCHv7 04/12] PCI: designware-ep: Modify MSI and MSIX CAP way of finding
Hi Rob,
Thanks a lot for your comments!
> -Original Message-
> From: Rob Herring
> Sent: 2020年9月11日 2:10
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linuxppc-...@lists.ozlabs.org; bhelg...@google.com;
> lorenzo.pieral...@arm.com; shawn...@kernel.org; Leo Li
> ; kis...@ti.com; gustavo.pimen...@synopsys.com;
> Roy Zang ; jingooh...@gmail.com;
> andrew.mur...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: Re: [PATCHv7 04/12] PCI: designware-ep: Modify MSI and MSIX CAP
> way of finding
>
> On Tue, Aug 11, 2020 at 05:54:33PM +0800, Zhiqiang Hou wrote:
> > From: Xiaowei Bao
> >
> > Each PF of EP device should have its own MSI or MSIX capabitily
> > struct, so create a dw_pcie_ep_func struct and move the msi_cap and
> > msix_cap to this struct from dw_pcie_ep, and manage the PFs via a
> > list.
> >
> > Signed-off-by: Xiaowei Bao
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V7:
> > - Rebase the patch without functionality change.
> >
> > .../pci/controller/dwc/pcie-designware-ep.c | 139
> +++---
> > drivers/pci/controller/dwc/pcie-designware.h | 18 ++-
> > 2 files changed, 136 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 56bd1cd71f16..4680a51c49c0 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -28,6 +28,19 @@ void dw_pcie_ep_init_notify(struct dw_pcie_ep
> *ep)
> > } EXPORT_SYMBOL_GPL(dw_pcie_ep_init_notify);
> >
> > +struct dw_pcie_ep_func *
> > +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no) {
> > + struct dw_pcie_ep_func *ep_func;
> > +
> > + list_for_each_entry(ep_func, >func_list, list) {
> > + if (ep_func->func_no == func_no)
> > + return ep_func;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8
> > func_no) {
> > unsigned int func_offset = 0;
> > @@ -68,6 +81,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci,
> enum pci_barno bar)
> > __dw_pcie_ep_reset_bar(pci, func_no, bar, 0); }
> >
> > +static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8
> func_no,
> > + u8 cap_ptr, u8 cap)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
> > + u8 cap_id, next_cap_ptr;
> > + u16 reg;
> > +
> > + if (!cap_ptr)
> > + return 0;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
> > + cap_id = (reg & 0x00ff);
> > +
> > + if (cap_id > PCI_CAP_ID_MAX)
> > + return 0;
> > +
> > + if (cap_id == cap)
> > + return cap_ptr;
> > +
> > + next_cap_ptr = (reg & 0xff00) >> 8;
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
> > +
> > +static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8
> > +func_no, u8 cap) {
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + unsigned int func_offset = 0;
> > + u8 next_cap_ptr;
> > + u16 reg;
> > +
> > + func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > + reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
> > + next_cap_ptr = (reg & 0x00ff);
> > +
> > + return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
>
> These are almost the same as __dw_pcie_find_next_cap and
> dw_pcie_find_capability. Please modify them to take a function offset and
> work for both host and endpoints.
Yes, will rework in next version.
>
> > +
> > static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> >struct pci_epf_header *hdr)
> > {
> > @@ -257,13 +311,18 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> *epc, u8 func_no)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > unsigned int func_offset = 0;
> > + struct dw_pcie_ep_func *ep_func;
> >
> > - if (!ep->msi_cap)
> > + ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > + if (!ep_func)
> > + return -EINVAL;
> >
RE: [PATCHv7 02/12] PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
Hi Rob,
Thanks a lot for your comments!
> -Original Message-
> From: Rob Herring
> Sent: 2020年9月11日 1:58
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linuxppc-...@lists.ozlabs.org; bhelg...@google.com;
> lorenzo.pieral...@arm.com; shawn...@kernel.org; Leo Li
> ; kis...@ti.com; gustavo.pimen...@synopsys.com;
> Roy Zang ; jingooh...@gmail.com;
> andrew.mur...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: Re: [PATCHv7 02/12] PCI: designware-ep: Add the doorbell mode of
> MSI-X in EP mode
>
> On Tue, Aug 11, 2020 at 05:54:31PM +0800, Zhiqiang Hou wrote:
> > From: Xiaowei Bao
> >
> > Add the doorbell mode of MSI-X in DWC EP driver.
> >
> > Signed-off-by: Xiaowei Bao
> > Reviewed-by: Andrew Murray
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V7:
> > - Rebase the patch without functionality change.
> >
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 14 ++
> > drivers/pci/controller/dwc/pcie-designware.h| 12
> > 2 files changed, 26 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index e5bd3a5ef380..e76b504ed465 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -471,6 +471,20 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep
> *ep, u8 func_no,
> > return 0;
> > }
> >
> > +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8
> > +func_no,
>
> return void. It never has an error.
>
> It could also just be an inline function.
Yes, make sense and will change in next version.
Thanks,
Zhiqiang
>
> > + u16 interrupt_num)
> > +{
> > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > + u32 msg_data;
> > +
> > + msg_data = (func_no << PCIE_MSIX_DOORBELL_PF_SHIFT) |
> > + (interrupt_num - 1);
> > +
> > + dw_pcie_writel_dbi(pci, PCIE_MSIX_DOORBELL, msg_data);
> > +
> > + return 0;
> > +}
> > +
> > int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > u16 interrupt_num)
> > {
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index 89f8271ec5ee..745b4938225a 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -97,6 +97,9 @@
> > #define PCIE_MISC_CONTROL_1_OFF0x8BC
> > #define PCIE_DBI_RO_WR_EN BIT(0)
> >
> > +#define PCIE_MSIX_DOORBELL 0x948
> > +#define PCIE_MSIX_DOORBELL_PF_SHIFT24
> > +
> > #define PCIE_PL_CHK_REG_CONTROL_STATUS 0xB20
> > #define PCIE_PL_CHK_REG_CHK_REG_START BIT(0)
> > #define PCIE_PL_CHK_REG_CHK_REG_CONTINUOUS BIT(1)
> > @@ -434,6 +437,8 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep
> *ep, u8 func_no,
> > u8 interrupt_num);
> > int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> > u16 interrupt_num);
> > +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8
> func_no,
> > + u16 interrupt_num);
> > void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> > #else static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep) @@
> > -475,6 +480,13 @@ static inline int dw_pcie_ep_raise_msix_irq(struct
> dw_pcie_ep *ep, u8 func_no,
> > return 0;
> > }
> >
> > +static inline int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep
> *ep,
> > +u8 func_no,
> > +u16 interrupt_num)
> > +{
> > + return 0;
> > +}
> > +
> > static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum
> > pci_barno bar) { }
> > --
> > 2.17.1
> >
RE: [PATCHv7 10/12] arm64: dts: layerscape: Add PCIe EP node for ls1088a
Hi Rob,
Thanks a lot for your comments!
> -Original Message-
> From: Rob Herring
> Sent: 2020年9月11日 0:48
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linuxppc-...@lists.ozlabs.org; bhelg...@google.com;
> lorenzo.pieral...@arm.com; shawn...@kernel.org; Leo Li
> ; kis...@ti.com; gustavo.pimen...@synopsys.com;
> Roy Zang ; jingooh...@gmail.com;
> andrew.mur...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: Re: [PATCHv7 10/12] arm64: dts: layerscape: Add PCIe EP node for
> ls1088a
>
> On Tue, Aug 11, 2020 at 05:54:39PM +0800, Zhiqiang Hou wrote:
> > From: Xiaowei Bao
> >
> > Add PCIe EP node for ls1088a to support EP mode.
> >
> > Signed-off-by: Xiaowei Bao
> > Reviewed-by: Andrew Murray
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V7:
> > - Rebase the patch without functionality change.
> >
> > .../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > index 169f4742ae3b..915592141f1b 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > @@ -499,6 +499,17 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep@340 {
>
> pci-ep@...
The DT node name must be "xxx-xx" style? If yes, the LS1046A EP node also has
the name "pcie_ep", it also need to be fixed.
Thanks,
Zhiqiang
>
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > + reg = <0x00 0x0340 0x0 0x0010
> > + 0x20 0x 0x8 0x>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <24>;
> > + num-ob-windows = <128>;
> > + max-functions = /bits/ 8 <2>;
> > + status = "disabled";
> > + };
> > +
> > pcie@350 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x0350 0x0 0x0010 /* controller
> registers */
> > @@ -525,6 +536,16 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep@350 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > + reg = <0x00 0x0350 0x0 0x0010
> > + 0x28 0x 0x8 0x>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <6>;
> > + num-ob-windows = <8>;
> > + status = "disabled";
> > + };
> > +
> > pcie@360 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x0360 0x0 0x0010 /* controller
> registers */
> > @@ -551,6 +572,16 @@
> > status = "disabled";
> > };
> >
> > + pcie_ep@360 {
> > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > + reg = <0x00 0x0360 0x0 0x0010
> > + 0x30 0x 0x8 0x>;
> > + reg-names = "regs", "addr_space";
> > + num-ib-windows = <6>;
> > + num-ob-windows = <8>;
> > + status = "disabled";
> > + };
> > +
> > smmu: iommu@500 {
> > compatible = "arm,mmu-500";
> > reg = <0 0x500 0 0x80>;
> > --
> > 2.17.1
> >
RE: [PATCH 1/7] PCI: dwc: Fix a bug of the case dw_pci->ops is NULL
Hi Gustavo,
Thanks a lot for your review and ack!
Regards,
Zhiqiang
> -Original Message-
> From: Gustavo Pimentel
> Sent: 2020年9月9日 17:29
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.com
> Cc: M.h. Lian ; Mingkai Hu
> ; Roy Zang
> Subject: RE: [PATCH 1/7] PCI: dwc: Fix a bug of the case dw_pci->ops is NULL
>
> Hi Hou,
>
> On Mon, Sep 7, 2020 at 6:37:55, Zhiqiang Hou
> wrote:
>
> > From: Hou Zhiqiang
> >
> > The dw_pci->ops may be a NULL, and fix it by adding one more check.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pcie-designware.c | 12 ++--
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index b723e0cc41fb..bdf8938da9cd 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -140,7 +140,7 @@ u32 dw_pcie_read_dbi(struct dw_pcie *pci, u32
> reg, size_t size)
> > int ret;
> > u32 val;
> >
> > - if (pci->ops->read_dbi)
> > + if (pci->ops && pci->ops->read_dbi)
> > return pci->ops->read_dbi(pci, pci->dbi_base, reg, size);
> >
> > ret = dw_pcie_read(pci->dbi_base + reg, size, ); @@ -155,7
> > +155,7 @@ void dw_pcie_write_dbi(struct dw_pcie *pci, u32 reg, size_t
> > size, u32 val) {
> > int ret;
> >
> > - if (pci->ops->write_dbi) {
> > + if (pci->ops && pci->ops->write_dbi) {
> > pci->ops->write_dbi(pci, pci->dbi_base, reg, size, val);
> > return;
> > }
> > @@ -200,7 +200,7 @@ u32 dw_pcie_read_atu(struct dw_pcie *pci, u32
> reg, size_t size)
> > int ret;
> > u32 val;
> >
> > - if (pci->ops->read_dbi)
> > + if (pci->ops && pci->ops->read_dbi)
> > return pci->ops->read_dbi(pci, pci->atu_base, reg, size);
> >
> > ret = dw_pcie_read(pci->atu_base + reg, size, ); @@ -214,7
> > +214,7 @@ void dw_pcie_write_atu(struct dw_pcie *pci, u32 reg, size_t
> > size, u32 val) {
> > int ret;
> >
> > - if (pci->ops->write_dbi) {
> > + if (pci->ops && pci->ops->write_dbi) {
> > pci->ops->write_dbi(pci, pci->atu_base, reg, size, val);
> > return;
> > }
> > @@ -283,7 +283,7 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie
> > *pci, int index, int type, {
> > u32 retries, val;
> >
> > - if (pci->ops->cpu_addr_fixup)
> > + if (pci->ops && pci->ops->cpu_addr_fixup)
> > cpu_addr = pci->ops->cpu_addr_fixup(pci, cpu_addr);
> >
> > if (pci->iatu_unroll_enabled) {
> > @@ -470,7 +470,7 @@ int dw_pcie_link_up(struct dw_pcie *pci) {
> > u32 val;
> >
> > - if (pci->ops->link_up)
> > + if (pci->ops && pci->ops->link_up)
> > return pci->ops->link_up(pci);
> >
> > val = readl(pci->dbi_base + PCIE_PORT_DEBUG1);
> > --
> > 2.17.1
>
> Looks good to me.
>
> Acked-by: Gustavo Pimentel
>
>
>
RE: [PATCHv2] PCI: designware-ep: Fix the Header Type check
Hi Rob,
Thanks a lot for your review!
Regards,
Zhiqiang
> -Original Message-
> From: Rob Herring
> Sent: 2020年8月18日 21:52
> To: Z.q. Hou
> Cc: linux-kernel@vger.kernel.org; PCI ; Lorenzo
> Pieralisi ; Bjorn Helgaas
> ; Andrew Murray
> ; Jingoo Han ;
> Gustavo Pimentel
> Subject: Re: [PATCHv2] PCI: designware-ep: Fix the Header Type check
>
> On Tue, Aug 18, 2020 at 3:35 AM Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > The current check will result in the multiple function device fails to
> > initialize. So fix the check by masking out the multiple function bit.
> >
> > Fixes: 0b24134f7888 ("PCI: dwc: Add validation that PCIe core is set
> > to correct mode")
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V2:
> > - Add marco PCI_HEADER_TYPE_MASK and print the masked value.
> >
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 3 ++-
> > include/uapi/linux/pci_regs.h | 1 +
> > 2 files changed, 3 insertions(+), 1 deletion(-)
>
> Reviewed-by: Rob Herring
RE: [PATCH] PCI: designware-ep: Fix the Header Type check
Hi Rob,
Thanks a lot for your comments!
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: 2020年8月14日 23:51
> To: Z.q. Hou
> Cc: linux-kernel@vger.kernel.org; PCI ; Lorenzo
> Pieralisi ; Bjorn Helgaas
> ; Andrew Murray ;
> Jingoo Han ; Gustavo Pimentel
>
> Subject: Re: [PATCH] PCI: designware-ep: Fix the Header Type check
>
> On Fri, Aug 14, 2020 at 2:15 AM Zhiqiang Hou
> wrote:
> >
> > From: Hou Zhiqiang
> >
> > The current check will result in the multiple function device fails to
> > initialize. So fix the check by masking out the multiple function bit.
> >
> > Fixes: 0b24134f7888 ("PCI: dwc: Add validation that PCIe core is set
> > to correct mode")
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pcie-designware-ep.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 4680a51c49c0..4b7abfb1e669 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -654,7 +654,7 @@ int dw_pcie_ep_init_complete(struct dw_pcie_ep
> *ep)
> > int i;
> >
> > hdr_type = dw_pcie_readb_dbi(pci, PCI_HEADER_TYPE);
> > - if (hdr_type != PCI_HEADER_TYPE_NORMAL) {
> > + if (hdr_type & 0x7f != PCI_HEADER_TYPE_NORMAL) {
>
> Should have () around 'hdr_type & 0x7f'.
>
> > dev_err(pci->dev,
> > "PCIe controller is not set to EP mode
> (hdr_type:0x%x)!\n",
> > hdr_type);
>
> However, shouldn't the printed value be masked too? I'd just do:
>
> hdr_type = dw_pcie_readb_dbi(pci, PCI_HEADER_TYPE) & 0x7f;
>
> Perhaps add a #define too. '0x7f' is used in several places.
All these are good suggestions, will make it in next version.
Thanks,
Zhiqiang
>
> Rob
RE: [PATCH v6 00/11] Add the multiple PF support for DWC and Layerscape
Hi Lorenzo, > -Original Message- > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] > Sent: 2020年7月6日 18:47 > To: Xiaowei Bao > Cc: Z.q. Hou ; M.h. Lian ; > Mingkai Hu ; bhelg...@google.com; > robh...@kernel.org; shawn...@kernel.org; Leo Li ; > kis...@ti.com; Roy Zang ; > amur...@thegoodpenguin.co.uk; jingooh...@gmail.com; > gustavo.pimen...@synopsys.com; andrew.mur...@arm.com; > linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > linuxppc-...@lists.ozlabs.org > Subject: Re: [PATCH v6 00/11] Add the multiple PF support for DWC and > Layerscape > > On Sat, Mar 14, 2020 at 11:30:27AM +0800, Xiaowei Bao wrote: > > Add the PCIe EP multiple PF support for DWC and Layerscape, add the > > doorbell MSIX function for DWC, use list to manage the PF of one PCIe > > controller, and refactor the Layerscape EP driver due to some > > platforms difference. > > > > Xiaowei Bao (11): > > PCI: designware-ep: Add multiple PFs support for DWC > > PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode > > PCI: designware-ep: Move the function of getting MSI capability > > forward > > PCI: designware-ep: Modify MSI and MSIX CAP way of finding > > dt-bindings: pci: layerscape-pci: Add compatible strings for ls1088a > > and ls2088a > > PCI: layerscape: Fix some format issue of the code > > PCI: layerscape: Modify the way of getting capability with different > > PEX > > PCI: layerscape: Modify the MSIX to the doorbell mode > > PCI: layerscape: Add EP mode support for ls1088a and ls2088a > > arm64: dts: layerscape: Add PCIe EP node for ls1088a > > misc: pci_endpoint_test: Add LS1088a in pci_device_id table > > > > .../devicetree/bindings/pci/layerscape-pci.txt | 2 + > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 +++ > > drivers/misc/pci_endpoint_test.c | 2 + > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 100 ++-- > > drivers/pci/controller/dwc/pcie-designware-ep.c| 255 > + > > drivers/pci/controller/dwc/pcie-designware.c | 59 +++-- > > drivers/pci/controller/dwc/pcie-designware.h | 48 +++- > > 7 files changed, 404 insertions(+), 93 deletions(-) > > Can you rebase it against v5.8-rc1 please ? Yes, I will help to rebase. Thanks, Zhiqiang > > Thanks, > Lorenzo
RE: [PATCH] PCI: ERR: Don't override the status returned by error_detect()
Hi Kuppuswamy,
Thanks a lot for your comments and sorry for my late response!
> -Original Message-
> From: Kuppuswamy, Sathyanarayanan
>
> Sent: 2020年5月29日 12:25
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; rus...@russell.cc; sbobr...@linux.ibm.com;
> ooh...@gmail.com; bhelg...@google.com
> Subject: Re: [PATCH] PCI: ERR: Don't override the status returned by
> error_detect()
>
>
>
> On 5/28/20 9:04 PM, Z.q. Hou wrote:
> > Hi Kuppuswamy,
> >
> >> -Original Message-
> >> From: Kuppuswamy, Sathyanarayanan
> >>
> >> Sent: 2020年5月29日 5:19
> >> To: Z.q. Hou ; linux-...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; rus...@russell.cc;
> >> sbobr...@linux.ibm.com; ooh...@gmail.com; bhelg...@google.com
> >> Subject: Re: [PATCH] PCI: ERR: Don't override the status returned by
> >> error_detect()
> >>
> >> Hi,
> >>
> >> On 5/27/20 1:31 AM, Zhiqiang Hou wrote:
> >>> From: Hou Zhiqiang
> >>>
> >>> The commit 6d2c89441571 ("PCI/ERR: Update error status after
> >>> reset_link()") overrode the 'status' returned by the error_detect()
> >>> call back function, which is depended on by the next step. This
> >>> overriding makes the Endpoint driver's required info (kept in the
> >>> var
> >>> status) lost, so it results in the fatal errors' recovery failed and
> >>> then kernel
> >> panic.
> >> Can you explain why updating status affects the recovery ?
> >
> > Take the e1000e as an example:
> > Once a fatal error is reported by e1000e, the e1000e's error_detect()
> > will be called and it will return PCI_ERS_RESULT_NEED_RESET to request
> > a slot reset, the return value is stored in the '' of the
> > calling pci_walk_bus(bus,report_frozen_detected, ).
> > If you update the 'status' with the reset_link()'s return value
> > (PCI_ERS_RESULT_RECOVERED if the reset link succeed), then the
> > 'status' has the value PCI_ERS_RESULT_RECOVERED and e1000e's request
> > PCI_ERS_RESULT_NEED_RESET lost, then e1000e's callback function
> > .slot_reset() will be skipped and directly call the .resume().
> I believe you are working with non hotplug capable device. If yes, then this
> issue will be addressed by the following patch.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org
> %2Flkml%2F2020%2F5%2F6%2F1545data=02%7C01%7Czhiqiang.hou%4
> 0nxp.com%7C4f0ad836e4384f40400f08d80388383c%7C686ea1d3bc2b4c6fa92
> cd99c5c301635%7C0%7C1%7C637263230875781678sdata=ap0PUMzse
> xIuCnOpBCFPW%2BrUEwMWgAYzT7yxGP8pjio%3Dreserved=0
I'll try this patch, seems it also override the 'status' in the
pci_channel_io_frozen
Case but it make sense for me.
Thanks,
Zhiqiang
> >
> > So this is how the update of 'status' break the handshake between RC's
> > AER driver and the Endpoint's protocol driver error_handlers, then result in
> the recovery failure.
> >
> >>>
> >>> In the e1000e case, the error logs:
> >>> pcieport 0002:00:00.0: AER: Uncorrected (Fatal) error received:
> >>> 0002:01:00.0 e1000e 0002:01:00.0: AER: PCIe Bus Error:
> >>> severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent
> >>> ID) pcieport 0002:00:00.0: AER: Root Port link has been reset
> >> As per above commit log, it looks like link is reset correctly.
> >
> > Yes, see my comments above.
> >
> > Thanks,
> > Zhiqiang
> >
> >>> SError Interrupt on CPU0, code 0xbf02 -- SError
> >>> CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
> >>> 5.7.0-rc7-next-20200526 #8 Hardware name: LS1046A RDB Board (DT)
> >>> pstate: 8005 (Nzcv daif -PAN -UAO BTYPE=--) pc :
> >>> __pci_enable_msix_range+0x4c8/0x5b8
> >>> lr : __pci_enable_msix_range+0x480/0x5b8
> >>> sp : 80001116bb30
> >>> x29: 80001116bb30 x28: 0003
> >>> x27: 0003 x26:
> >>> x25: 00097243e0a8 x24: 0001
> >>> x23: 00097243e2d8 x22:
> >>> x21: 0003 x20: 00095bd46080
> >>> x19: 00097243e000 x18:
> >>> x17: x16:
> >>> x15: b958fa0e9948 x14: 00095bd46303
> >>> x13: 00095bd46302 x12: 0038
> >>> x11: 0040 x10: b958fa101e68
> >>> x9 : b958fa101e60 x8 : 0908
> >>> x7 : 0908 x6
RE: [PATCH] PCI: ERR: Don't override the status returned by error_detect()
Hi Kuppuswamy,
> -Original Message-
> From: Kuppuswamy, Sathyanarayanan
>
> Sent: 2020年5月29日 5:19
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; rus...@russell.cc; sbobr...@linux.ibm.com;
> ooh...@gmail.com; bhelg...@google.com
> Subject: Re: [PATCH] PCI: ERR: Don't override the status returned by
> error_detect()
>
> Hi,
>
> On 5/27/20 1:31 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang
> >
> > The commit 6d2c89441571 ("PCI/ERR: Update error status after
> > reset_link()") overrode the 'status' returned by the error_detect()
> > call back function, which is depended on by the next step. This
> > overriding makes the Endpoint driver's required info (kept in the var
> > status) lost, so it results in the fatal errors' recovery failed and then
> > kernel
> panic.
> Can you explain why updating status affects the recovery ?
Take the e1000e as an example:
Once a fatal error is reported by e1000e, the e1000e's error_detect() will be
called and it will return PCI_ERS_RESULT_NEED_RESET to request a slot reset,
the return value is stored in the '' of the calling
pci_walk_bus(bus,report_frozen_detected, ).
If you update the 'status' with the reset_link()'s return value
(PCI_ERS_RESULT_RECOVERED if the reset link succeed), then the 'status' has
the value PCI_ERS_RESULT_RECOVERED and e1000e's request
PCI_ERS_RESULT_NEED_RESET lost, then e1000e's callback function .slot_reset()
will be skipped and directly call the .resume().
So this is how the update of 'status' break the handshake between RC's AER
driver
and the Endpoint's protocol driver error_handlers, then result in the recovery
failure.
> >
> > In the e1000e case, the error logs:
> > pcieport 0002:00:00.0: AER: Uncorrected (Fatal) error received:
> > 0002:01:00.0 e1000e 0002:01:00.0: AER: PCIe Bus Error:
> > severity=Uncorrected (Fatal), type=Inaccessible, (Unregistered Agent
> > ID) pcieport 0002:00:00.0: AER: Root Port link has been reset
> As per above commit log, it looks like link is reset correctly.
Yes, see my comments above.
Thanks,
Zhiqiang
> > SError Interrupt on CPU0, code 0xbf02 -- SError
> > CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
> > 5.7.0-rc7-next-20200526 #8 Hardware name: LS1046A RDB Board (DT)
> > pstate: 8005 (Nzcv daif -PAN -UAO BTYPE=--) pc :
> > __pci_enable_msix_range+0x4c8/0x5b8
> > lr : __pci_enable_msix_range+0x480/0x5b8
> > sp : 80001116bb30
> > x29: 80001116bb30 x28: 0003
> > x27: 0003 x26:
> > x25: 00097243e0a8 x24: 0001
> > x23: 00097243e2d8 x22:
> > x21: 0003 x20: 00095bd46080
> > x19: 00097243e000 x18:
> > x17: x16:
> > x15: b958fa0e9948 x14: 00095bd46303
> > x13: 00095bd46302 x12: 0038
> > x11: 0040 x10: b958fa101e68
> > x9 : b958fa101e60 x8 : 0908
> > x7 : 0908 x6 : 80001160
> > x5 : 00095bd46800 x4 : 00096e7f6080
> > x3 : x2 :
> > x1 : x0 : Kernel panic - not
> > syncing: Asynchronous SError Interrupt
> > CPU: 0 PID: 111 Comm: irq/76-aerdrv Not tainted
> > 5.7.0-rc7-next-20200526 #8
> >
> > I think it's the expected result that "if the initial value of error
> > status is PCI_ERS_RESULT_DISCONNECT or
> PCI_ERS_RESULT_NO_AER_DRIVER
> > then even after successful recovery (using reset_link())
> > pcie_do_recovery() will report the recovery result as failure" which
> > is described in commit 6d2c89441571 ("PCI/ERR: Update error status after
> reset_link()").
> >
> > Refer to the Documentation/PCI/pci-error-recovery.rst.
> > As the error_detect() is mandatory callback if the pci_err_handlers is
> > implemented, if it return the PCI_ERS_RESULT_DISCONNECT, it means the
> > driver doesn't want to recover at all; For the case
> > PCI_ERS_RESULT_NO_AER_DRIVER, if the pci_err_handlers is not
> > implemented, the failure is more expected.
> >
> > Fixes: commit 6d2c89441571 ("PCI/ERR: Update error status after
> > reset_link()")
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/pcie/err.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c index
> > 14bb8f54723e..84f72342259c 100644
> > --- a/drivers/pci/pcie/err.c
> > +++ b/drivers/pci/pcie/err.c
> > @@ -165,8 +165,7 @@ pci_
RE: [PATCH v3 00/11] *** SUBJECT HERE ***
Xiaowei, > -Original Message- > From: Xiaowei Bao > Sent: 2019年9月2日 11:17 > To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; > Leo Li ; kis...@ti.com; lorenzo.pieral...@arm.com; > M.h. Lian ; Mingkai Hu ; > Roy Zang ; jingooh...@gmail.com; > gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org > Cc: a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou > ; Xiaowei Bao > Subject: [PATCH v3 00/11] *** SUBJECT HERE *** > > *** BLURB HERE *** Add subject and blurb for this series. Thanks, Zhiqiang > > Xiaowei Bao (11): > PCI: designware-ep: Add multiple PFs support for DWC > PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode > PCI: designware-ep: Move the function of getting MSI capability > forward > PCI: designware-ep: Modify MSI and MSIX CAP way of finding > dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a > and ls2088a > PCI: layerscape: Fix some format issue of the code > PCI: layerscape: Modify the way of getting capability with different > PEX > PCI: layerscape: Modify the MSIX to the doorbell mode > PCI: layerscape: Add EP mode support for ls1088a and ls2088a > arm64: dts: layerscape: Add PCIe EP node for ls1088a > misc: pci_endpoint_test: Add LS1088a in pci_device_id table > > .../devicetree/bindings/pci/layerscape-pci.txt | 4 +- > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31 +++ > drivers/misc/pci_endpoint_test.c | 1 + > drivers/pci/controller/dwc/pci-layerscape-ep.c | 100 ++-- > drivers/pci/controller/dwc/pcie-designware-ep.c| 255 > + > drivers/pci/controller/dwc/pcie-designware.c | 59 +++-- > drivers/pci/controller/dwc/pcie-designware.h | 48 +++- > 7 files changed, 404 insertions(+), 94 deletions(-) > > -- > 2.9.5
RE: [PATCHv2 1/4] dt-bindings: PCI: designware: Remove the num-lanes from Required properties
Hi Rob, Thanks a lot for your review! Thanks, Zhiqiang > -Original Message- > From: Rob Herring > Sent: 2019年8月28日 0:58 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; > andrew.mur...@arm.com; M.h. Lian ; Z.q. Hou > > Subject: Re: [PATCHv2 1/4] dt-bindings: PCI: designware: Remove the > num-lanes from Required properties > > On Tue, 20 Aug 2019 07:28:43 +, "Z.q. Hou" wrote: > > From: Hou Zhiqiang > > > > The num-lanes is not a mandatory property, e.g. on FSL Layerscape > > SoCs, the PCIe link training is completed automatically base on the > > selected SerDes protocol, it doesn't need the num-lanes to set-up the > > link width. > > > > It is previously in both Required and Optional properties, let's > > remove it from the Required properties. > > > > Signed-off-by: Hou Zhiqiang > > --- > > V2: > > - Reworded the change log and subject. > > - Fixed a typo in subject. > > > > Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - > > 1 file changed, 1 deletion(-) > > > > Reviewed-by: Rob Herring
RE: [PATCH v4 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
Hi Xiaowei,
> -Original Message-
> From: Xiaowei Bao
> Sent: 2019年8月23日 16:27
> To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> Leo Li ; M.h. Lian ;
> Mingkai Hu ; Roy Zang ;
> lorenzo.pieral...@arm.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org; Z.q.
> Hou
> Cc: bhelg...@google.com; Xiaowei Bao ; Z.q. Hou
>
> Subject: [PATCH v4 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
>
> LS1028a implements 2 PCIe 3.0 controllers.
>
> Signed-off-by: Xiaowei Bao
> Signed-off-by: Hou Zhiqiang
> ---
> v2:
> - Fix up the legacy INTx allocate failed issue.
> v3:
> - No change.
> v4:
> - Remove the num-lanes proparty.
> depends on:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.kernel.org%2Fproject%2Flinux-pci%2Flist%2F%3Fseries%3D162215
> mp;data=02%7C01%7Czhiqiang.hou%40nxp.com%7C07a39c8a38114852ad8
> 808d727a50ea8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63
> 7021462174809487sdata=MTVsUPPoy2NrMjpXG4BMocHIN0Gbkh3W
> 8SN622QMLI8%3Dreserved=0
>
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 50
> ++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index 72b9a75..a25f9d9 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -625,6 +625,56 @@
> };
> };
>
> + pcie@340 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010 /* controller
> registers */
> +0x80 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> + interrupts = , /* PME
> interrupt */
> + ; /* aer
> interrupt */
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x80 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> + msi-parent = <>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1 0 0 GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2 0 0 GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3 0 0 GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4 0 0 GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
lost the property num-viewport.
> +
> + pcie@350 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0350 0x0 0x0010 /* controller
> registers */
> +0x88 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> + interrupts = ,
> + ;
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x88 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x88 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> + msi-parent = <>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1 0 0 GIC_SPI 114
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2 0 0 GIC_SPI 115
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3 0 0 GIC_SPI 116
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4 0 0 GIC_SPI 117
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
Ditto
Thanks,
Zhiqiang
> +
> pcie@1f000 { /* Integrated Endpoint Root Complex */
> compatible = "pci-host-ecam-generic";
> reg = <0x01 0xf000 0x0 0x10>;
> --
> 2.9.5
RE: [PATCHv2 1/4] dt-bindings: PCI: designware: Remove the num-lanes from Required properties
Hi Andrew, Thanks a lot for your review! Thanks, Zhiqiang > -Original Message- > From: Andrew Murray > Sent: 2019年8月20日 17:23 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; M.h. Lian > > Subject: Re: [PATCHv2 1/4] dt-bindings: PCI: designware: Remove the > num-lanes from Required properties > > On Tue, Aug 20, 2019 at 07:28:43AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > The num-lanes is not a mandatory property, e.g. on FSL Layerscape > > SoCs, the PCIe link training is completed automatically base on the > > selected SerDes protocol, it doesn't need the num-lanes to set-up the > > link width. > > > > It is previously in both Required and Optional properties, let's > > remove it from the Required properties. > > > > Signed-off-by: Hou Zhiqiang > > --- > > Reviewed-by: Andrew Murray > > > > V2: > > - Reworded the change log and subject. > > - Fixed a typo in subject. > > > > Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > index 5561a1c060d0..bd880df39a79 100644 > > --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > @@ -11,7 +11,6 @@ Required properties: > > the ATU address space. > > (The old way of getting the configuration address space from > "ranges" > > is deprecated and should be avoided.) > > -- num-lanes: number of lanes to use > > RC mode: > > - #address-cells: set to <3> > > - #size-cells: set to <2> > > -- > > 2.17.1 > >
[PATCHv2 4/4] arm64: dts: fsl: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang Remove the num-lanes to avoid the driver setting the link width. 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 after power on reset. So the num-lanes is not needed for Layerscape PCIe. The current num-lanes was added erroneously, which actually indicates the max lanes PCIe controller can support up to, instead of the lanes assigned to the PCIe controller. And the link width set by SerDes protocol will be overridden by the num-lanes, hence the subsequent re-taining will fail when the assigned lanes does not equal to num-lanes. Signed-off-by: Hou Zhiqiang Reviewed-by: Andrew Murray --- V2: - Reworded the change log. arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 - arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 -- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 3 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 5 files changed, 17 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi index ec6257a5b251..119c597ca867 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi @@ -486,7 +486,6 @@ #address-cells = <3>; #size-cells = <2>; device_type = "pci"; - num-lanes = <4>; num-viewport = <2>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index 71d9ed9ff985..c084c7a4b6a6 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi @@ -677,7 +677,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <4>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ @@ -704,7 +703,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ @@ -731,7 +729,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x50 0x0001 0x0 0x0001 /* downstream I/O */ diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi index b0ef08b090dd..d4c1da3d4bde 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi @@ -649,7 +649,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <4>; num-viewport = <8>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ @@ -671,7 +670,6 @@ reg-names = "regs", "addr_space"; num-ib-windows = <6>; num-ob-windows = <8>; - num-lanes = <2>; status = "disabled"; }; @@ -687,7 +685,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <8>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ @@ -709,7 +706,6 @@ reg-names = "regs", "addr_space"; num-ib-windows = <6>; num-ob-windows = <8>; - num-lanes = <2>; status = "disabled"; }; @@ -725,7 +721,6 @@ #size-cells = <2>;
[PATCHv2 1/4] dt-bindings: PCI: designware: Remove the num-lanes from Required properties
From: Hou Zhiqiang The num-lanes is not a mandatory property, e.g. on FSL Layerscape SoCs, the PCIe link training is completed automatically base on the selected SerDes protocol, it doesn't need the num-lanes to set-up the link width. It is previously in both Required and Optional properties, let's remove it from the Required properties. Signed-off-by: Hou Zhiqiang --- V2: - Reworded the change log and subject. - Fixed a typo in subject. Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index 5561a1c060d0..bd880df39a79 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -11,7 +11,6 @@ Required properties: the ATU address space. (The old way of getting the configuration address space from "ranges" is deprecated and should be avoided.) -- num-lanes: number of lanes to use RC mode: - #address-cells: set to <3> - #size-cells: set to <2> -- 2.17.1
[PATCHv2 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang Remove the num-lanes to avoid the driver setting the link width. 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 after power on reset. So the num-lanes is not needed for Layerscape PCIe. The current num-lanes was added erroneously, which actually indicates the max lanes PCIe controller can support up to, instead of the lanes assigned to the PCIe controller. And the link width set by SerDes protocol will be overridden by the num-lanes, hence the subsequent re-taining will fail when the assigned lanes does not equal to num-lanes. Signed-off-by: Hou Zhiqiang Reviewed-by: Andrew Murray --- V2: - Reworded the change log. 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 = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* 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 = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ -- 2.17.1
[PATCHv2 2/4] PCI: dwc: Return directly when num-lanes is not found
From: Hou Zhiqiang
The num-lanes is optional, so probably it isn't added
on some platforms. The subsequent programming is base
on the num-lanes, hence return when it is not found.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Andrew Murray
---
V2:
- No change.
drivers/pci/controller/dwc/pcie-designware.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index 7d25102c304c..0a89bfd1636e 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -423,8 +423,10 @@ void dw_pcie_setup(struct dw_pcie *pci)
ret = of_property_read_u32(np, "num-lanes", );
- if (ret)
- lanes = 0;
+ if (ret) {
+ dev_dbg(pci->dev, "property num-lanes isn't found\n");
+ return;
+ }
/* Set the number of lanes */
val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
--
2.17.1
[PATCHv2 0/4] Layerscape: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang On FSL Layerscape SoCs, the number of lanes assigned to PCIe controller is not fixed, it is determined by the selected SerDes protocol. 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. Hou Zhiqiang (4): dt-bindings: PCI: designware: Remove the num-lanes from Required properties PCI: dwc: Return directly when num-lanes is not found ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes arm64: dts: fsl: Remove num-lanes property from PCIe nodes Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - arch/arm/boot/dts/ls1021a.dtsi| 2 -- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi| 1 - arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 3 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi| 6 -- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 3 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi| 4 drivers/pci/controller/dwc/pcie-designware.c | 6 -- 8 files changed, 4 insertions(+), 22 deletions(-) -- 2.17.1
RE: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
Hi Bjorn, Thanks a lot for your comments! > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 2019年8月20日 3:25 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com; > shawn...@kernel.org; Leo Li ; > lorenzo.pieral...@arm.com; M.h. Lian > Subject: Re: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property > from PCIe nodes > > On Mon, Aug 12, 2019 at 04:22:27AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > 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 > > --- > > 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 = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* 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 = <0x8100 0x0 0x 0x48 0x0001 0x0 > 0x0001 /* downstream I/O */ > > -- > > 2.17.1 > >
RE: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from Required properties
Hi Bjorn, Thanks a lot for your comments! > -Original Message- > From: Bjorn Helgaas [mailto:helg...@kernel.org] > Sent: 2019年8月20日 3:20 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; robh...@kernel.org; mark.rutl...@arm.com; > shawn...@kernel.org; Leo Li ; > lorenzo.pieral...@arm.com; M.h. Lian > Subject: Re: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from > Required properties > > In subject: > > s/dt-bingings/dt-bindings/ > > Also, possibly > > s/PCI:/PCI: designware:/ > I'll fix them in v2. Thanks, Zhiqiang > since this only applies to designware-pcie.txt. > > On Mon, Aug 12, 2019 at 04:22:16AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > The num-lanes is not a mandatory property, e.g. on FSL Layerscape > > SoCs, the PCIe link training is completed automatically base on the > > selected SerDes protocol, it doesn't need the num-lanes to set-up the > > link width. > > > > It has been added in the Optional properties. This patch is to remove > > it from the Required properties. > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > index 5561a1c060d0..bd880df39a79 100644 > > --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > @@ -11,7 +11,6 @@ Required properties: > > the ATU address space. > > (The old way of getting the configuration address space from "ranges" > > is deprecated and should be avoided.) > > -- num-lanes: number of lanes to use > > RC mode: > > - #address-cells: set to <3> > > - #size-cells: set to <2> > > -- > > 2.17.1 > >
RE: [PATCHv3 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
Hi Xiaowei,
> -Original Message-
> From: Xiaowei Bao
> Sent: 2019年8月6日 14:16
> To: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.com; a...@arndb.de; gre...@linuxfoundation.org;
> M.h. Lian ; Mingkai Hu ;
> Z.q. Hou ; Roy Zang ;
> kstew...@linuxfoundation.org; pombreda...@nexb.com;
> shawn@rock-chips.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org
> Cc: Xiaowei Bao ; Z.q. Hou
>
> Subject: [PATCHv3 2/3] arm64: dts: ls1028a: Add PCIe controller DT nodes
>
> LS1028a implements 2 PCIe 3.0 controllers.
>
> Signed-off-by: Xiaowei Bao
> Signed-off-by: Hou Zhiqiang
> ---
> v2:
> - Fix up the legacy INTx allocate failed issue.
> v3:
> - no change.
>
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 52
> ++
> 1 file changed, 52 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index aef5b06..0b542ed 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -503,6 +503,58 @@
> status = "disabled";
> };
>
> + pcie@340 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010 /* controller
> registers */
> +0x80 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> + interrupts = , /* PME
> interrupt */
> + ; /* aer
> interrupt */
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + num-lanes = <4>;
Remove the num-lanes, it is not needed by Layerscape PCIe controllers. see:
http://patchwork.ozlabs.org/project/linux-pci/list/?series=124488
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x80 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> + msi-parent = <>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1 0 0 GIC_SPI 109
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2 0 0 GIC_SPI 110
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3 0 0 GIC_SPI 111
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4 0 0 GIC_SPI 112
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> + pcie@350 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0350 0x0 0x0010 /* controller
> registers */
> +0x88 0x 0x0 0x2000>; /* configuration
> space */
> + reg-names = "regs", "config";
> + interrupts = ,
> + ;
> + interrupt-names = "pme", "aer";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + device_type = "pci";
> + dma-coherent;
> + num-lanes = <4>;
Ditto
> + bus-range = <0x0 0xff>;
> + ranges = <0x8100 0x0 0x 0x88 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x88 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> + msi-parent = <>;
> + #interrupt-cells = <1>;
> + interrupt-map-mask = <0 0 0 7>;
> + interrupt-map = < 0 0 1 0 0 GIC_SPI 114
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 2 0 0 GIC_SPI 115
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 3 0 0 GIC_SPI 116
> IRQ_TYPE_LEVEL_HIGH>,
> + < 0 0 4 0 0 GIC_SPI 117
> IRQ_TYPE_LEVEL_HIGH>;
> + status = "disabled";
> + };
> +
> pcie@1f000 { /* Integrated Endpoint Root Complex */
> compatible = "pci-host-ecam-generic";
> reg = <0x01 0xf000 0x0 0x10>;
> --
> 2.9.5
[PATCHv8 3/7] dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controller
From: Hou Zhiqiang
Add PCIe Gen4 controller DT bindings of NXP Layerscape SoCs.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Rob Herring
---
V8:
- No change.
.../bindings/pci/layerscape-pcie-gen4.txt | 52 +++
MAINTAINERS | 8 +++
2 files changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
new file mode 100644
index ..b40fb5d15d3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
@@ -0,0 +1,52 @@
+NXP Layerscape PCIe Gen4 controller
+
+This PCIe controller is based on the Mobiveil PCIe IP and thus inherits all
+the common properties defined in mobiveil-pcie.txt.
+
+Required properties:
+- compatible: should contain the platform identifier such as:
+ "fsl,lx2160a-pcie"
+- reg: base addresses and lengths of the PCIe controller register blocks.
+ "csr_axi_slave": Bridge config registers
+ "config_axi_slave": PCIe controller registers
+- interrupts: A list of interrupt outputs of the controller. Must contain an
+ entry for each entry in the interrupt-names property.
+- interrupt-names: It could include the following entries:
+ "intr": The interrupt that is asserted for controller interrupts
+ "aer": Asserted for aer interrupt when chip support the aer interrupt with
+none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
+ "pme": Asserted for pme interrupt when chip support the pme interrupt with
+none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
+- dma-coherent: Indicates that the hardware IP block can ensure the coherency
+ of the data transferred from/to the IP block. This can avoid the software
+ cache flush/invalid actions, and improve the performance significantly.
+- msi-parent : See the generic MSI binding described in
+ Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+Example:
+
+ pcie@340 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010 /* controller registers
*/
+ 0x80 0x 0x0 0x1000>; /* configuration space
*/
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /* controller
interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+ msi-parent = <>;
+ ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 110
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 111
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 112
IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d88e0d3960b..f9c1153ef60a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12324,6 +12324,14 @@ L: linux-arm-ker...@lists.infradead.org
S: Maintained
F: drivers/pci/controller/dwc/*layerscape*
+PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER
+M: Hou Zhiqiang
+L: linux-...@vger.kernel.org
+L: linux-arm-ker...@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
+F: drivers/pci/controller/mobibeil/pcie-layerscape-gen4.c
+
PCI DRIVER FOR GENERIC OF HOSTS
M: Will Deacon
L: linux-...@vger.kernel.org
--
2.17.1
[PATCHv8 2/7] PCI: mobiveil: Make mobiveil_host_init() can be used to re-init host
From: Hou Zhiqiang
Make the mobiveil_host_init() function can be used to re-init
host controller's PAB and GPEX CSR register block, as NXP
integrated Mobiveil IP has to reset and then re-init the PAB
and GPEX CSR registers upon hot-reset.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Subrahmanya Lingappa
---
V8:
- Re-generate the patch on the new code base.
.../controller/mobiveil/pcie-mobiveil-host.c | 43 ++-
.../pci/controller/mobiveil/pcie-mobiveil.h | 3 +-
2 files changed, 24 insertions(+), 22 deletions(-)
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
index 995487c4f760..775754522363 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
@@ -215,16 +215,21 @@ static void mobiveil_pcie_enable_msi(struct mobiveil_pcie
*pcie)
writel_relaxed(1, pcie->apb_csr_base + MSI_ENABLE_OFFSET);
}
-static int mobiveil_host_init(struct mobiveil_pcie *pcie)
+int mobiveil_host_init(struct mobiveil_pcie *pcie, bool reinit)
{
u32 value, pab_ctrl, type;
struct resource_entry *win;
- /* setup bus numbers */
- value = csr_readl(pcie, PCI_PRIMARY_BUS);
- value &= 0xff00;
- value |= 0x00ff0100;
- csr_writel(pcie, value, PCI_PRIMARY_BUS);
+ pcie->ib_wins_configured = 0;
+ pcie->ob_wins_configured = 0;
+
+ if (!reinit) {
+ /* setup bus numbers */
+ value = csr_readl(pcie, PCI_PRIMARY_BUS);
+ value &= 0xff00;
+ value |= 0x00ff0100;
+ csr_writel(pcie, value, PCI_PRIMARY_BUS);
+ }
/*
* program Bus Master Enable Bit in Command Register in PAB Config
@@ -270,7 +275,7 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
program_ib_windows(pcie, WIN_NUM_0, 0, 0, MEM_WINDOW_TYPE, IB_WIN_SIZE);
/* Get the I/O and memory ranges from DT */
- resource_list_for_each_entry(win, >resources) {
+ resource_list_for_each_entry(win, pcie->resources) {
if (resource_type(win->res) == IORESOURCE_MEM) {
type = MEM_WINDOW_TYPE;
} else if (resource_type(win->res) == IORESOURCE_IO) {
@@ -541,8 +546,6 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
resource_size_t iobase;
int ret;
- INIT_LIST_HEAD(>resources);
-
ret = mobiveil_pcie_parse_dt(pcie);
if (ret) {
dev_err(dev, "Parsing DT failed, ret: %x\n", ret);
@@ -551,34 +554,35 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
/* parse the host bridge base addresses from the device tree file */
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- >resources, );
+ >windows, );
if (ret) {
dev_err(dev, "Getting bridge resources failed\n");
return ret;
}
+ pcie->resources = >windows;
+
/*
* configure all inbound and outbound windows and prepare the RC for
* config access
*/
- ret = mobiveil_host_init(pcie);
+ ret = mobiveil_host_init(pcie, false);
if (ret) {
dev_err(dev, "Failed to initialize host\n");
- goto error;
+ return ret;
}
ret = mobiveil_pcie_interrupt_init(pcie);
if (ret) {
dev_err(dev, "Interrupt init failed\n");
- goto error;
+ return ret;
}
- ret = devm_request_pci_bus_resources(dev, >resources);
+ ret = devm_request_pci_bus_resources(dev, pcie->resources);
if (ret)
- goto error;
+ return ret;
/* Initialize bridge */
- list_splice_init(>resources, >windows);
bridge->dev.parent = dev;
bridge->sysdata = pcie;
bridge->busnr = pcie->rp.root_bus_nr;
@@ -589,13 +593,13 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
ret = mobiveil_bringup_link(pcie);
if (ret) {
dev_info(dev, "link bring-up failed\n");
- goto error;
+ return ret;
}
/* setup the kernel resources for the newly added PCIe root bus */
ret = pci_scan_root_bus_bridge(bridge);
if (ret)
- goto error;
+ return ret;
bus = bridge->bus;
@@ -605,7 +609,4 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
pci_bus_add_devices(bus);
return 0;
-error:
- pci_free_resource_list(>resources);
- return ret;
}
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index 4825e30030cd..4f17a9837fe9 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++
[PATCHv8 1/7] PCI: mobiveil: Refactor Mobiveil PCIe Host Bridge IP driver
From: Hou Zhiqiang
Refactor the Mobiveil PCIe Host Bridge IP driver to make
it easier to add support for both RC and EP mode driver.
This patch moved the Mobiveil driver to an new directory
'drivers/pci/controller/mobiveil' and refactor it according
to the RC and EP abstraction.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
Reviewed-by: Subrahmanya Lingappa
---
V8:
- Re-generate the patch on the new code base.
MAINTAINERS | 2 +-
drivers/pci/controller/Kconfig| 11 +-
drivers/pci/controller/Makefile | 2 +-
drivers/pci/controller/mobiveil/Kconfig | 24 +
drivers/pci/controller/mobiveil/Makefile | 4 +
.../pcie-mobiveil-host.c} | 525 +++---
.../controller/mobiveil/pcie-mobiveil-plat.c | 59 ++
.../pci/controller/mobiveil/pcie-mobiveil.c | 227
.../pci/controller/mobiveil/pcie-mobiveil.h | 189 +++
9 files changed, 592 insertions(+), 451 deletions(-)
create mode 100644 drivers/pci/controller/mobiveil/Kconfig
create mode 100644 drivers/pci/controller/mobiveil/Makefile
rename drivers/pci/controller/{pcie-mobiveil.c =>
mobiveil/pcie-mobiveil-host.c} (54%)
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.h
diff --git a/MAINTAINERS b/MAINTAINERS
index df85ee4dbdc7..0d88e0d3960b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12367,7 +12367,7 @@ M: Hou Zhiqiang
L: linux-...@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/pci/mobiveil-pcie.txt
-F: drivers/pci/controller/pcie-mobiveil.c
+F: drivers/pci/controller/mobiveil/pcie-mobiveil*
PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support)
M: Thomas Petazzoni
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index fe9f9f13ce11..dec8e038cb17 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -241,16 +241,6 @@ config PCIE_MEDIATEK
Say Y here if you want to enable PCIe controller support on
MediaTek SoCs.
-config PCIE_MOBIVEIL
- bool "Mobiveil AXI PCIe controller"
- depends on ARCH_ZYNQMP || COMPILE_TEST
- depends on OF
- depends on PCI_MSI_IRQ_DOMAIN
- help
- Say Y here if you want to enable support for the Mobiveil AXI PCIe
- Soft IP. It has up to 8 outbound and inbound windows
- for address translation and it is a PCIe Gen4 IP.
-
config PCIE_TANGO_SMP8759
bool "Tango SMP8759 PCIe controller (DANGEROUS)"
depends on ARCH_TANGO && PCI_MSI && OF
@@ -282,4 +272,5 @@ config VMD
module will be called vmd.
source "drivers/pci/controller/dwc/Kconfig"
+source "drivers/pci/controller/mobiveil/Kconfig"
endmenu
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index d56a507495c5..b79a615041a0 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -26,11 +26,11 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o
obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
-obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
+obj-y += mobiveil/
# The following drivers are for devices that use the generic ACPI
diff --git a/drivers/pci/controller/mobiveil/Kconfig
b/drivers/pci/controller/mobiveil/Kconfig
new file mode 100644
index ..64343c07bfed
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+
+menu "Mobiveil PCIe Core Support"
+ depends on PCI
+
+config PCIE_MOBIVEIL
+ bool
+
+config PCIE_MOBIVEIL_HOST
+bool
+ depends on PCI_MSI_IRQ_DOMAIN
+select PCIE_MOBIVEIL
+
+config PCIE_MOBIVEIL_PLAT
+ bool "Mobiveil AXI PCIe controller"
+ depends on ARCH_ZYNQMP || COMPILE_TEST
+ depends on OF
+ select PCIE_MOBIVEIL_HOST
+ help
+ Say Y here if you want to enable support for the Mobiveil AXI PCIe
+ Soft IP. It has up to 8 outbound and inbound windows
+ for address translation and it is a PCIe Gen4 IP.
+
+endmenu
diff --git a/drivers/pci/controller/mobiveil/Makefile
b/drivers/pci/controller/mobiveil/Makefile
new file mode 100644
index ..9fb6d1c6504d
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
+obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
+obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
[PATCHv8 6/7] arm64: dts: lx2160a: Add PCIe controller DT nodes
From: Hou Zhiqiang
The LX2160A integrated 6 PCIe Gen4 controllers.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
---
V8:
- No change.
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 163 ++
1 file changed, 163 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 4720a8e7304c..1856b0691e0b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -977,5 +977,168 @@
};
};
};
+
+ pcie@340 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
+ 0x80 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 110
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 111
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 112
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@350 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
+ 0x88 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 114
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 115
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 116
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 117
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@360 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
+ 0x90 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <256>;
+ ppio-wins = <24>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x90 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+
[PATCHv8 5/7] PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
From: Hou Zhiqiang
This PCIe controller is based on the Mobiveil GPEX IP, which is
compatible with the PCI Express™ Base Specification, Revision 4.0.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
---
V8:
- Clear the interrupt status register before enabling interrupts.
- Disable interrupts when detected a RESET event.
drivers/pci/controller/mobiveil/Kconfig | 10 +
drivers/pci/controller/mobiveil/Makefile | 1 +
.../mobiveil/pcie-layerscape-gen4.c | 274 ++
.../pci/controller/mobiveil/pcie-mobiveil.h | 16 +-
4 files changed, 299 insertions(+), 2 deletions(-)
create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
diff --git a/drivers/pci/controller/mobiveil/Kconfig
b/drivers/pci/controller/mobiveil/Kconfig
index 64343c07bfed..c823be8dab1c 100644
--- a/drivers/pci/controller/mobiveil/Kconfig
+++ b/drivers/pci/controller/mobiveil/Kconfig
@@ -21,4 +21,14 @@ config PCIE_MOBIVEIL_PLAT
Soft IP. It has up to 8 outbound and inbound windows
for address translation and it is a PCIe Gen4 IP.
+config PCIE_LAYERSCAPE_GEN4
+ bool "Freescale Layerscape PCIe Gen4 controller"
+ depends on PCI
+ depends on OF && (ARM64 || ARCH_LAYERSCAPE)
+ depends on PCI_MSI_IRQ_DOMAIN
+ select PCIE_MOBIVEIL_HOST
+ help
+ Say Y here if you want PCIe Gen4 controller support on
+ Layerscape SoCs. The PCIe controller can work in RC or
+ EP mode according to RCW[HOST_AGT_PEX] setting.
endmenu
diff --git a/drivers/pci/controller/mobiveil/Makefile
b/drivers/pci/controller/mobiveil/Makefile
index 9fb6d1c6504d..99d879de32d6 100644
--- a/drivers/pci/controller/mobiveil/Makefile
+++ b/drivers/pci/controller/mobiveil/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
+obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie-layerscape-gen4.o
diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
new file mode 100644
index ..1c4663a359d2
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
@@ -0,0 +1,274 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe Gen4 host controller driver for NXP Layerscape SoCs
+ *
+ * Copyright 2019 NXP
+ *
+ * Author: Zhiqiang Hou
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-mobiveil.h"
+
+/* LUT and PF control registers */
+#define PCIE_LUT_OFF 0x8
+#define PCIE_PF_OFF0xc
+#define PCIE_PF_INT_STAT 0x18
+#define PF_INT_STAT_PABRST BIT(31)
+
+#define PCIE_PF_DBG0x7fc
+#define PF_DBG_LTSSM_MASK 0x3f
+#define PF_DBG_LTSSM_L00x2d /* L0 state */
+#define PF_DBG_WE BIT(31)
+#define PF_DBG_PABRBIT(27)
+
+#define to_ls_pcie_g4(x) platform_get_drvdata((x)->pdev)
+
+struct ls_pcie_g4 {
+ struct mobiveil_pcie pci;
+ struct delayed_work dwork;
+ int irq;
+};
+
+static inline u32 ls_pcie_g4_lut_readl(struct ls_pcie_g4 *pcie, u32 off)
+{
+ return ioread32(pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
+}
+
+static inline void ls_pcie_g4_lut_writel(struct ls_pcie_g4 *pcie,
+u32 off, u32 val)
+{
+ iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
+}
+
+static inline u32 ls_pcie_g4_pf_readl(struct ls_pcie_g4 *pcie, u32 off)
+{
+ return ioread32(pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
+}
+
+static inline void ls_pcie_g4_pf_writel(struct ls_pcie_g4 *pcie,
+ u32 off, u32 val)
+{
+ iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
+}
+
+static bool ls_pcie_g4_is_bridge(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = >pci;
+ u32 header_type;
+
+ header_type = csr_readb(mv_pci, PCI_HEADER_TYPE);
+ header_type &= 0x7f;
+
+ return header_type == PCI_HEADER_TYPE_BRIDGE;
+}
+
+static int ls_pcie_g4_link_up(struct mobiveil_pcie *pci)
+{
+ struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
+ u32 state;
+
+ state = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
+ state = state & PF_DBG_LTSSM_MASK;
+
+ if (state == PF_DBG_LTSSM_L0)
+ return 1;
+
+ return 0;
+}
+
+static void ls_pcie_g4_disable_interrupt(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = >pci;
+
+ csr_writel(mv_pci, 0, PAB_INTP_AMBA_MISC_ENB);
+}
+
+static void ls_pcie_g4_enable_interrupt(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = >pci;
+ u32 val;
+
+ /* Clear the interrupt status */
+
[PATCHv8 7/7] arm64: defconfig: Enable CONFIG_PCIE_LAYERSCAPE_GEN4
From: Hou Zhiqiang Enable the PCIe Gen4 controller driver for Layerscape SoCs. Signed-off-by: Hou Zhiqiang Reviewed-by: Minghuan Lian --- V8: - No change. arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 97c507803210..721a144ef75b 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -189,6 +189,7 @@ CONFIG_PCI_HOST_THUNDER_PEM=y CONFIG_PCI_HOST_THUNDER_ECAM=y CONFIG_PCIE_ROCKCHIP_HOST=m CONFIG_PCI_LAYERSCAPE=y +CONFIG_PCIE_LAYERSCAPE_GEN4=y CONFIG_PCI_HISI=y CONFIG_PCIE_QCOM=y CONFIG_PCIE_ARMADA_8K=y -- 2.17.1
[PATCHv8 4/7] PCI: mobiveil: Add 8-bit and 16-bit CSR register accessors
From: Hou Zhiqiang
There are some 8-bit and 16-bit registers in PCIe configuration
space, so add these accessors accordingly.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
Reviewed-by: Subrahmanya Lingappa
---
V8:
- No change.
.../pci/controller/mobiveil/pcie-mobiveil.h | 20 +++
1 file changed, 20 insertions(+)
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index 4f17a9837fe9..8c07f69e0330 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -182,9 +182,29 @@ static inline u32 csr_readl(struct mobiveil_pcie *pcie,
u32 off)
return csr_read(pcie, off, 0x4);
}
+static inline u32 csr_readw(struct mobiveil_pcie *pcie, u32 off)
+{
+ return csr_read(pcie, off, 0x2);
+}
+
+static inline u32 csr_readb(struct mobiveil_pcie *pcie, u32 off)
+{
+ return csr_read(pcie, off, 0x1);
+}
+
static inline void csr_writel(struct mobiveil_pcie *pcie, u32 val, u32 off)
{
csr_write(pcie, val, off, 0x4);
}
+static inline void csr_writew(struct mobiveil_pcie *pcie, u32 val, u32 off)
+{
+ csr_write(pcie, val, off, 0x2);
+}
+
+static inline void csr_writeb(struct mobiveil_pcie *pcie, u32 val, u32 off)
+{
+ csr_write(pcie, val, off, 0x1);
+}
+
#endif /* _PCIE_MOBIVEIL_H */
--
2.17.1
[PATCHv8 0/7] PCI: refactor Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs
From: Hou Zhiqiang
This patch set is aim to refactor the Mobiveil driver and add
PCIe support for NXP Layerscape series SoCs integrated Mobiveil's
PCIe Gen4 controller.
This patch set depends on:
http://patchwork.ozlabs.org/patch/1131624/
Hou Zhiqiang (7):
PCI: mobiveil: Refactor Mobiveil PCIe Host Bridge IP driver
PCI: mobiveil: Make mobiveil_host_init() can be used to re-init host
dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controller
PCI: mobiveil: Add 8-bit and 16-bit CSR register accessors
PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
arm64: dts: lx2160a: Add PCIe controller DT nodes
arm64: defconfig: Enable CONFIG_PCIE_LAYERSCAPE_GEN4
MAINTAINERS | 10 +-
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 163 +
arch/arm64/configs/defconfig | 1 +
drivers/pci/controller/Kconfig| 11 +-
drivers/pci/controller/Makefile | 2 +-
drivers/pci/controller/mobiveil/Kconfig | 34 ++
drivers/pci/controller/mobiveil/Makefile | 5 +
.../mobiveil/pcie-layerscape-gen4.c | 274 +
.../pcie-mobiveil-host.c} | 566 --
.../controller/mobiveil/pcie-mobiveil-plat.c | 59 ++
.../pci/controller/mobiveil/pcie-mobiveil.c | 227 +++
.../pci/controller/mobiveil/pcie-mobiveil.h | 222 +++
12 files changed, 1103 insertions(+), 471 deletions(-)
create mode 100644 drivers/pci/controller/mobiveil/Kconfig
create mode 100644 drivers/pci/controller/mobiveil/Makefile
create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
rename drivers/pci/controller/{pcie-mobiveil.c =>
mobiveil/pcie-mobiveil-host.c} (52%)
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.h
--
2.17.1
RE: [PATCH 4/4] arm64: dts: fsl: Remove num-lanes property from PCIe nodes
Hi Andrew, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Andrew Murray > Sent: 2019年8月12日 16:36 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; M.h. Lian > > Subject: Re: [PATCH 4/4] arm64: dts: fsl: Remove num-lanes property from > PCIe nodes > > On Mon, Aug 12, 2019 at 04:22:33AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > 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. > > > > Signed-off-by: Hou Zhiqiang > > --- > > arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 - > > arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 --- > > arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 -- > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 3 --- > > arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 > > 5 files changed, 17 deletions(-) > > > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > index ec6257a5b251..119c597ca867 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi > > @@ -486,7 +486,6 @@ > > #address-cells = <3>; > > #size-cells = <2>; > > device_type = "pci"; > > - num-lanes = <4>; > > num-viewport = <2>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* downstream I/O */ > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > index 71d9ed9ff985..c084c7a4b6a6 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi > > @@ -677,7 +677,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <4>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* downstream I/O */ > > @@ -704,7 +703,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <2>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 > 0x0001 /* downstream I/O */ > > @@ -731,7 +729,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <2>; > > num-viewport = <6>; > > bus-range = <0x0 0xff>; > > ranges = <0x8100 0x0 0x 0x50 0x0001 0x0 > 0x0001 /* downstream I/O */ > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > index b0ef08b090dd..d4c1da3d4bde 100644 > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi > > @@ -649,7 +649,6 @@ > > #size-cells = <2>; > > device_type = "pci"; > > dma-coherent; > > - num-lanes = <4>;
RE: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
Hi Andrew, Thanks a lot for your review! Regards, Zhiqiang > -Original Message- > From: Andrew Murray > Sent: 2019年8月12日 16:35 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; M.h. Lian > > Subject: Re: [PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property > from PCIe nodes > > On Mon, Aug 12, 2019 at 04:22:27AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > 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. > > > > Signed-off-by: Hou Zhiqiang > > --- > > 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 = <0x8100 0x0 0x 0x40 0x0001 0x0 > 0x0001 /* 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 = <0x8100 0x0 0x 0x48 0x0001 0x0 > 0x0001 /* downstream I/O */ > > Reviewed-by: Andrew Murray > > > -- > > 2.17.1 > >
RE: [PATCH 2/4] PCI: dwc: Return directly when num-lanes is not found
Hi Andrew,
Thanks a lot for your review!
B.R,
Zhiqiang
> -Original Message-
> From: Andrew Murray
> Sent: 2019年8月12日 16:34
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com;
> jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.com; M.h. Lian
>
> Subject: Re: [PATCH 2/4] PCI: dwc: Return directly when num-lanes is not
> found
>
> On Mon, Aug 12, 2019 at 04:22:22AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > The num-lanes is optional, so probably it isn't added on some
> > platforms. The subsequent programming is base on the num-lanes, hence
> > return when it is not found.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > drivers/pci/controller/dwc/pcie-designware.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 7d25102c304c..0a89bfd1636e 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -423,8 +423,10 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >
> >
> > ret = of_property_read_u32(np, "num-lanes", );
> > - if (ret)
> > - lanes = 0;
> > + if (ret) {
> > + dev_dbg(pci->dev, "property num-lanes isn't found\n");
> > + return;
> > + }
>
> The existing code would assign a value of 0 to lanes when num-lanes isn't
> specified, however this value isn't supported by the following switch
> statement - thus we'd also print an error and return.
>
> Therefore the only and subtle effect effect of this patch is to change a
> dev_err to a dev_dbg when num-lanes isn't specified and avoid a read of
> PCIE_PORT_LINK_CONTROL.
>
> Given that num-lanes is described as optional this makes perfect sense.
> Though the commit message/hunk does give the apperance that this
> provides a more functional change.
>
> Anyway:
>
> Reviewed-by: Andrew Murray
>
>
> >
> > /* Set the number of lanes */
> > val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
> > --
> > 2.17.1
> >
RE: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from Required properties
Hi Andrew, Thanks a lot for your comments! > -Original Message- > From: Andrew Murray > Sent: 2019年8月12日 16:45 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; devicet...@vger.kernel.org; > linux-kernel@vger.kernel.org; gustavo.pimen...@synopsys.com; > jingooh...@gmail.com; bhelg...@google.com; robh...@kernel.org; > mark.rutl...@arm.com; shawn...@kernel.org; Leo Li > ; lorenzo.pieral...@arm.com; M.h. Lian > ; Kishon Vijay Abraham I ; > Gabriele Paoloni > Subject: Re: [PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from > Required properties > > On Mon, Aug 12, 2019 at 04:22:16AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > The num-lanes is not a mandatory property, e.g. on FSL Layerscape > > SoCs, the PCIe link training is completed automatically base on the > > selected SerDes protocol, it doesn't need the num-lanes to set-up the > > link width. > > > > It has been added in the Optional properties. This patch is to remove > > it from the Required properties. > > For clarity, maybe this paragraph can be reworded to: > > "It is previously in both Required and Optional properties, let's remove it > from the Required properties". Agree and will change in v2. > > I don't understand why this property is previously in both required and > optional... > > It looks like num-lanes was first made optional back in > 2015 and removed from the Required section (907fce090253). > But then re-added back into the Required section in 2017 with the adition of > bindings for EP mode (b12befecd7de). > > Is num-lanes actually required for EP mode? Kishon, please help to answer this query? Thanks, Zhiqiang > > Thanks, > > Andrew Murray > > > > > Signed-off-by: Hou Zhiqiang > > --- > > Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > index 5561a1c060d0..bd880df39a79 100644 > > --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt > > +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt > > @@ -11,7 +11,6 @@ Required properties: > > the ATU address space. > > (The old way of getting the configuration address space from > "ranges" > > is deprecated and should be avoided.) > > -- num-lanes: number of lanes to use > > RC mode: > > - #address-cells: set to <3> > > - #size-cells: set to <2> > > -- > > 2.17.1 > >
[PATCH 1/4] dt-bingings: PCI: Remove the num-lanes from Required properties
From: Hou Zhiqiang The num-lanes is not a mandatory property, e.g. on FSL Layerscape SoCs, the PCIe link training is completed automatically base on the selected SerDes protocol, it doesn't need the num-lanes to set-up the link width. It has been added in the Optional properties. This patch is to remove it from the Required properties. Signed-off-by: Hou Zhiqiang --- Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index 5561a1c060d0..bd880df39a79 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -11,7 +11,6 @@ Required properties: the ATU address space. (The old way of getting the configuration address space from "ranges" is deprecated and should be avoided.) -- num-lanes: number of lanes to use RC mode: - #address-cells: set to <3> - #size-cells: set to <2> -- 2.17.1
[PATCH 2/4] PCI: dwc: Return directly when num-lanes is not found
From: Hou Zhiqiang
The num-lanes is optional, so probably it isn't added
on some platforms. The subsequent programming is base
on the num-lanes, hence return when it is not found.
Signed-off-by: Hou Zhiqiang
---
drivers/pci/controller/dwc/pcie-designware.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index 7d25102c304c..0a89bfd1636e 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -423,8 +423,10 @@ void dw_pcie_setup(struct dw_pcie *pci)
ret = of_property_read_u32(np, "num-lanes", );
- if (ret)
- lanes = 0;
+ if (ret) {
+ dev_dbg(pci->dev, "property num-lanes isn't found\n");
+ return;
+ }
/* Set the number of lanes */
val = dw_pcie_readl_dbi(pci, PCIE_PORT_LINK_CONTROL);
--
2.17.1
[PATCH 0/4] Layerscape: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang On FSL Layerscape SoCs, the number of lanes assigned to PCIe controller is not fixed, it is determined by the selected SerDes protocol. 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. Hou Zhiqiang (4): dt-bingings: PCI: Remove the num-lanes from Required properties PCI: dwc: Return directly when num-lanes is not found ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes arm64: dts: fsl: Remove num-lanes property from PCIe nodes Documentation/devicetree/bindings/pci/designware-pcie.txt | 1 - arch/arm/boot/dts/ls1021a.dtsi| 2 -- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi| 1 - arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi| 3 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi| 6 -- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 3 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi| 4 drivers/pci/controller/dwc/pcie-designware.c | 6 -- 8 files changed, 4 insertions(+), 22 deletions(-) -- 2.17.1
[PATCH 4/4] arm64: dts: fsl: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang 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. Signed-off-by: Hou Zhiqiang --- arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 1 - arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi | 3 --- arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 6 -- arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 3 --- arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 4 5 files changed, 17 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi index ec6257a5b251..119c597ca867 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi @@ -486,7 +486,6 @@ #address-cells = <3>; #size-cells = <2>; device_type = "pci"; - num-lanes = <4>; num-viewport = <2>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi index 71d9ed9ff985..c084c7a4b6a6 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi @@ -677,7 +677,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <4>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ @@ -704,7 +703,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ @@ -731,7 +729,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <6>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x50 0x0001 0x0 0x0001 /* downstream I/O */ diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi index b0ef08b090dd..d4c1da3d4bde 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1046a.dtsi @@ -649,7 +649,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <4>; num-viewport = <8>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* downstream I/O */ @@ -671,7 +670,6 @@ reg-names = "regs", "addr_space"; num-ib-windows = <6>; num-ob-windows = <8>; - num-lanes = <2>; status = "disabled"; }; @@ -687,7 +685,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <8>; bus-range = <0x0 0xff>; ranges = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ @@ -709,7 +706,6 @@ reg-names = "regs", "addr_space"; num-ib-windows = <6>; num-ob-windows = <8>; - num-lanes = <2>; status = "disabled"; }; @@ -725,7 +721,6 @@ #size-cells = <2>; device_type = "pci"; dma-coherent; - num-lanes = <2>; num-viewport = <8>; bus-range = <0x0 0xff>;
[PATCH 3/4] ARM: dts: ls1021a: Remove num-lanes property from PCIe nodes
From: Hou Zhiqiang 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. Signed-off-by: Hou Zhiqiang --- 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 = <0x8100 0x0 0x 0x40 0x0001 0x0 0x0001 /* 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 = <0x8100 0x0 0x 0x48 0x0001 0x0 0x0001 /* downstream I/O */ -- 2.17.1
RE: [PATCHv2 3/3] PCI: layerscape: Add LS1028a support
Hi Xiaowei,
> -Original Message-
> From: Xiaowei Bao [mailto:xiaowei@nxp.com]
> Sent: 2019年8月5日 12:05
> To: bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; Leo Li ; kis...@ti.com;
> lorenzo.pieral...@arm.com; a...@arndb.de; gre...@linuxfoundation.org;
> M.h. Lian ; Mingkai Hu ;
> Z.q. Hou ; Roy Zang ;
> kstew...@linuxfoundation.org; pombreda...@nexb.com;
> shawn@rock-chips.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org
> Cc: Xiaowei Bao
> Subject: [PATCHv2 3/3] PCI: layerscape: Add LS1028a support
>
> Add support for the LS1028a PCIe controller.
>
> Signed-off-by: Xiaowei Bao
> ---
> v2:
> - no change.
>
> drivers/pci/controller/dwc/pci-layerscape.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
> b/drivers/pci/controller/dwc/pci-layerscape.c
> index 3a5fa26..8c556e1 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -236,6 +236,14 @@ static const struct ls_pcie_drvdata ls1043_drvdata =
> {
> .dw_pcie_ops = _ls_pcie_ops,
> };
>
> +static const struct ls_pcie_drvdata ls1028a_drvdata = {
> + .lut_offset = 0x8,
> + .ltssm_shift = 0,
> + .lut_dbg = 0x407fc,
> + .ops = _pcie_host_ops,
> + .dw_pcie_ops = _ls_pcie_ops,
> +};
> +
Reuse the driver data structure of LS2088 instead add a new one.
- Zhiqiang
> static const struct ls_pcie_drvdata ls1046_drvdata = {
> .lut_offset = 0x8,
> .ltssm_shift = 24,
> @@ -263,6 +271,7 @@ static const struct ls_pcie_drvdata ls2088_drvdata =
> { static const struct of_device_id ls_pcie_of_match[] = {
> { .compatible = "fsl,ls1012a-pcie", .data = _drvdata },
> { .compatible = "fsl,ls1021a-pcie", .data = _drvdata },
> + { .compatible = "fsl,ls1028a-pcie", .data = _drvdata },
> { .compatible = "fsl,ls1043a-pcie", .data = _drvdata },
> { .compatible = "fsl,ls1046a-pcie", .data = _drvdata },
> { .compatible = "fsl,ls2080a-pcie", .data = _drvdata },
> --
> 2.9.5
RE: [PATCHv6 00/28] PCI: mobiveil: fixes for Mobiveil PCIe Host Bridge IP driver
Hi Lorenzo, Thanks for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月8日 19:35 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv6 00/28] PCI: mobiveil: fixes for Mobiveil PCIe Host > Bridge IP driver > > On Fri, Jul 05, 2019 at 05:56:28PM +0800, Hou Zhiqiang wrote: > > This patch set is to add fixes for Mobiveil PCIe Host driver. > > Splited #2, #3, #9 and #10 of v5 patches. > > > > Hou Zhiqiang (28): > > PCI: mobiveil: Unify register accessors > > PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI > > PCI: mobiveil: Fix PCI base address in MEM/IO outbound windows > > PCI: mobiveil: Update the resource list traversal function > > PCI: mobiveil: Use WIN_NUM_0 explicitly for CFG outbound window > > PCI: mobiveil: Use the 1st inbound window for MEM inbound > > transactions > > PCI: mobiveil: Fix the Class Code field > > PCI: mobiveil: Move the link up waiting out of mobiveil_host_init() > > PCI: mobiveil: Move IRQ chained handler setup out of DT parse > > PCI: mobiveil: Initialize Primary/Secondary/Subordinate bus numbers > > PCI: mobiveil: Fix devfn check in mobiveil_pcie_valid_device() > > dt-bindings: PCI: mobiveil: Change gpio_slave and apb_csr to optional > > PCI: mobiveil: Reformat the code for readability > > PCI: mobiveil: Make the register updating more readable > > PCI: mobiveil: Revise the MEM/IO outbound window initialization > > PCI: mobiveil: Fix the returned error number > > PCI: mobiveil: Remove an unnecessary return value check > > PCI: mobiveil: Remove redundant var definitions and register read > > operations > > PCI: mobiveil: Fix the valid check for inbound and outbound window > > PCI: mobiveil: Add the statistic of initialized inbound windows > > PCI: mobiveil: Clear the target fields before updating the register > > PCI: mobiveil: Mask out the lower 10-bit hardcode window size > > PCI: mobiveil: Add upper 32-bit CPU base address setup in outbound > > window > > PCI: mobiveil: Add upper 32-bit PCI base address setup in inbound > > window > > PCI: mobiveil: Fix the CPU base address setup in inbound window > > PCI: mobiveil: Move PCIe PIO enablement out of inbound window > routine > > PCI: mobiveil: Fix infinite-loop in the INTx process > > PCI: mobiveil: Fix the potential INTx missing problem > > > > .../devicetree/bindings/pci/mobiveil-pcie.txt |2 + > > drivers/pci/controller/pcie-mobiveil.c | 529 > > > 2 files changed, 318 insertions(+), 213 deletions(-) > > > > OK, I rewrote most of commit logs, dropped patch 25 since I do not > understand the commit log, pushed to pci/mobiveil tentatively for v5.3. The patch #25 is to fix the wrongly programming of the CPU base address of the inbound windows. The current code set the CPU base address with the PCI base address parameter which is the caller passed to set the PCI base address of the inbound window, and the upper 32-bit of the CPU base address of the inbound window is not set in current code. So it means the current code only support 1:1 inbound window setting & the CPU base address must be < 4GB. It won't work if in future someone change it to non 1:1 mapping or the CPU base address of the inbound window > 4GB. So, I will resend it separately. > Having said that, you should improve commit logs writing it took me too > much time to check them all and rewrite them. > > Never ever again post a massive series like this mixing refactoring fixes and > clean-ups it was painful to review/rebase, please split patch series into > small > chunks to make my life much easier. I understand it is wearisome, but I just want to make it better and easier to add new driver for other developers. I will try to not mix the distinct changes so that easy to maintain. Thank you so much for recomposing of these changelogs. > Please check my pci/mobiveil branch and report back if something is not in > order. Yes, and thanks again. B.R, Zhiqiang > Lorenzo
RE: [PATCHv5 02/20] PCI: mobiveil: Format the code without functionality change
Hi Lorenzo, > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月4日 18:57 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 02/20] PCI: mobiveil: Format the code without > functionality change > > On Thu, Jul 04, 2019 at 03:00:37AM +, Z.q. Hou wrote: > > [...] > > > > If you can manage to rebase patches on pci/mobiveil on top of > > > v5.2-rc1, send them separately so that I can merge them as a base > > > for the subsequent patches to be applied. > > > > You meant send the patches one by one, which you requested to split, > > and other patches without any changes can be send together, right? > > First step, rebase my branch above against v5.2-rc1 *without* this patch. > Then apply all the patches I requested to split (inclusive of this one) on > top of > it and send the whole patch series in one go. > > Please let me know if that's still unclear. It's clear now. Thanks, Zhiqiang > Thanks, > Lorenzo > > > > If you have any questions please ask, do not post patches if there > > > is something that is not clear. > > > > Yes, I'll, thanks for your guide again! > > > > B.R, > > Zhiqiang > > > > > > > > Lorenzo > > > > > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > > > > b/drivers/pci/controller/pcie-mobiveil.c > > > > index d55c7e780c6e..b87471f08a40 100644 > > > > --- a/drivers/pci/controller/pcie-mobiveil.c > > > > +++ b/drivers/pci/controller/pcie-mobiveil.c > > > > @@ -31,38 +31,40 @@ > > > > * translation tables are grouped into windows, each window > > > > registers > > > are > > > > * grouped into blocks of 4 or 16 registers each > > > > */ > > > > -#define PAB_REG_BLOCK_SIZE 16 > > > > -#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > +#define PAB_REG_BLOCK_SIZE 16 > > > > +#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > > > > > -#define PAB_REG_ADDR(offset, win) (offset + (win * > > > > PAB_REG_BLOCK_SIZE)) -#define PAB_EXT_REG_ADDR(offset, win) > > > > (offset > > > + > > > > (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > +#define PAB_REG_ADDR(offset, win) \ > > > > + (offset + (win * PAB_REG_BLOCK_SIZE)) > > > > +#define PAB_EXT_REG_ADDR(offset, win) \ > > > > + (offset + (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > > > > > -#define LTSSM_STATUS 0x0404 > > > > -#define LTSSM_STATUS_L0_MASK 0x3f > > > > -#define LTSSM_STATUS_L0 0x2d > > > > +#define LTSSM_STATUS 0x0404 > > > > +#define LTSSM_STATUS_L0_MASK 0x3f > > > > +#define LTSSM_STATUS_L0 0x2d > > > > > > > > -#define PAB_CTRL 0x0808 > > > > -#define AMBA_PIO_ENABLE_SHIFT 0 > > > > -#define PEX_PIO_ENABLE_SHIFT 1 > > > > -#define PAGE_SEL_SHIFT13 > > > > -#define PAGE_SEL_MASK 0x3f > > > > -#define PAGE_LO_MASK 0x3ff > > > > -#define PAGE_SEL_OFFSET_SHIFT 10 > > > > +#define PAB_CTRL 0x0808 > > > > +#define AMBA_PIO_ENABLE_SHIFT 0 > > > > +#define PEX_PIO_ENABLE_SHIFT 1 > > > > +#define PAGE_SEL_SHIFT13 > > > > +#define PAGE_SEL_MASK 0x3f > > > > +#define PAGE_LO_MASK 0x3ff > > > > +#define PAGE_SEL_OFFSET_SHIFT 10 > > > > > > > > -#define PAB_AXI_PIO_CTRL 0x0840 > > > > -#define APIO_EN_MASK 0xf > > > > +#define PAB_AXI_PIO_CTRL 0x0840 > > > > +#define APIO_EN_MASK 0xf > > > > > > > > -#define PAB_PEX_PIO_CTRL 0x08c0 > > > > -#define PIO_ENABLE_SHIFT 0 > > > > +#define PAB_PEX_PIO_CTRL 0x08c0 > > > > +#define PIO_ENABLE_SHIFT 0 > > > > > > > > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c > > > > -#define PAB_INTP_AMBA_MISC_STAT
RE: [PATCHv5 02/20] PCI: mobiveil: Format the code without functionality change
Hi Lorenzo, Thanks for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月3日 23:19 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 02/20] PCI: mobiveil: Format the code without > functionality change > > On Fri, Apr 12, 2019 at 08:35:24AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > Just format the code without functionality change. > > > > Signed-off-by: Hou Zhiqiang > > Reviewed-by: Minghuan Lian > > --- > > V5: > > - Retouched the subject. > > > > drivers/pci/controller/pcie-mobiveil.c | 261 > > + > > 1 file changed, 137 insertions(+), 124 deletions(-) > > Ok, dropping this patch means that everything else should be rebased. So > what I am going to do: > > - I will publish a branch (pci/mobiveil) where I added the patches > that are ready to be merged with commit logs rewritten; this patch > is part of it but in the final version it must be split as requested. > - You have to split this patch and the other patches I requested > you to split but do NOT modify the patches with my commit logs > rewritten in pci/mobiveil, it took me time to rewrite them. Yes, will split them and won't modify the commit logs, and thanks a lot for your help! > > If you can manage to rebase patches on pci/mobiveil on top of v5.2-rc1, > send them separately so that I can merge them as a base for the subsequent > patches to be applied. You meant send the patches one by one, which you requested to split, and other patches without any changes can be send together, right? > > If you have any questions please ask, do not post patches if there is > something that is not clear. Yes, I'll, thanks for your guide again! B.R, Zhiqiang > > Lorenzo > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > > b/drivers/pci/controller/pcie-mobiveil.c > > index d55c7e780c6e..b87471f08a40 100644 > > --- a/drivers/pci/controller/pcie-mobiveil.c > > +++ b/drivers/pci/controller/pcie-mobiveil.c > > @@ -31,38 +31,40 @@ > > * translation tables are grouped into windows, each window registers > are > > * grouped into blocks of 4 or 16 registers each > > */ > > -#define PAB_REG_BLOCK_SIZE 16 > > -#define PAB_EXT_REG_BLOCK_SIZE 4 > > +#define PAB_REG_BLOCK_SIZE 16 > > +#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > -#define PAB_REG_ADDR(offset, win) (offset + (win * > > PAB_REG_BLOCK_SIZE)) -#define PAB_EXT_REG_ADDR(offset, win) (offset > + > > (win * PAB_EXT_REG_BLOCK_SIZE)) > > +#define PAB_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_REG_BLOCK_SIZE)) > > +#define PAB_EXT_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > -#define LTSSM_STATUS 0x0404 > > -#define LTSSM_STATUS_L0_MASK 0x3f > > -#define LTSSM_STATUS_L0 0x2d > > +#define LTSSM_STATUS 0x0404 > > +#define LTSSM_STATUS_L0_MASK 0x3f > > +#define LTSSM_STATUS_L0 0x2d > > > > -#define PAB_CTRL 0x0808 > > -#define AMBA_PIO_ENABLE_SHIFT 0 > > -#define PEX_PIO_ENABLE_SHIFT 1 > > -#define PAGE_SEL_SHIFT13 > > -#define PAGE_SEL_MASK 0x3f > > -#define PAGE_LO_MASK 0x3ff > > -#define PAGE_SEL_OFFSET_SHIFT 10 > > +#define PAB_CTRL 0x0808 > > +#define AMBA_PIO_ENABLE_SHIFT 0 > > +#define PEX_PIO_ENABLE_SHIFT 1 > > +#define PAGE_SEL_SHIFT13 > > +#define PAGE_SEL_MASK 0x3f > > +#define PAGE_LO_MASK 0x3ff > > +#define PAGE_SEL_OFFSET_SHIFT 10 > > > > -#define PAB_AXI_PIO_CTRL 0x0840 > > -#define APIO_EN_MASK 0xf > > +#define PAB_AXI_PIO_CTRL 0x0840 > > +#define APIO_EN_MASK 0xf > > > > -#define PAB_PEX_PIO_CTRL 0x08c0 > > -#define PIO_ENABLE_SHIFT 0 > > +#define PAB_PEX_PIO_CTRL 0x08c0 > > +#define PIO_ENABLE_SHIFT 0 > > > > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c > > -#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > +#define PAB_INTP_AMBA_MISC_STAT
RE: [PATCHv5 02/20] PCI: mobiveil: Format the code without functionality change
Hi Lorenzo, Thanks for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月3日 23:10 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 02/20] PCI: mobiveil: Format the code without > functionality change > > On Fri, Apr 12, 2019 at 08:35:24AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > Just format the code without functionality change. > > > > Signed-off-by: Hou Zhiqiang > > Reviewed-by: Minghuan Lian > > --- > > V5: > > - Retouched the subject. > > > > drivers/pci/controller/pcie-mobiveil.c | 261 > > + > > 1 file changed, 137 insertions(+), 124 deletions(-) > > Again, I will drop this patch. You tend to do multiple changes in one single > patch, I understand this patch is just reformatting/renaming variables but at > least I would separate indentation changes from changes where eg you add > local variables. > > At least try to group the changes you are making instead of mixing them all > up. Yes, will spilt it. B.R, Zhiqiang > > Thanks, > Lorenzo > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c > > b/drivers/pci/controller/pcie-mobiveil.c > > index d55c7e780c6e..b87471f08a40 100644 > > --- a/drivers/pci/controller/pcie-mobiveil.c > > +++ b/drivers/pci/controller/pcie-mobiveil.c > > @@ -31,38 +31,40 @@ > > * translation tables are grouped into windows, each window registers > are > > * grouped into blocks of 4 or 16 registers each > > */ > > -#define PAB_REG_BLOCK_SIZE 16 > > -#define PAB_EXT_REG_BLOCK_SIZE 4 > > +#define PAB_REG_BLOCK_SIZE 16 > > +#define PAB_EXT_REG_BLOCK_SIZE 4 > > > > -#define PAB_REG_ADDR(offset, win) (offset + (win * > > PAB_REG_BLOCK_SIZE)) -#define PAB_EXT_REG_ADDR(offset, win) (offset > + > > (win * PAB_EXT_REG_BLOCK_SIZE)) > > +#define PAB_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_REG_BLOCK_SIZE)) > > +#define PAB_EXT_REG_ADDR(offset, win) \ > > + (offset + (win * PAB_EXT_REG_BLOCK_SIZE)) > > > > -#define LTSSM_STATUS 0x0404 > > -#define LTSSM_STATUS_L0_MASK 0x3f > > -#define LTSSM_STATUS_L0 0x2d > > +#define LTSSM_STATUS 0x0404 > > +#define LTSSM_STATUS_L0_MASK 0x3f > > +#define LTSSM_STATUS_L0 0x2d > > > > -#define PAB_CTRL 0x0808 > > -#define AMBA_PIO_ENABLE_SHIFT 0 > > -#define PEX_PIO_ENABLE_SHIFT 1 > > -#define PAGE_SEL_SHIFT13 > > -#define PAGE_SEL_MASK 0x3f > > -#define PAGE_LO_MASK 0x3ff > > -#define PAGE_SEL_OFFSET_SHIFT 10 > > +#define PAB_CTRL 0x0808 > > +#define AMBA_PIO_ENABLE_SHIFT 0 > > +#define PEX_PIO_ENABLE_SHIFT 1 > > +#define PAGE_SEL_SHIFT13 > > +#define PAGE_SEL_MASK 0x3f > > +#define PAGE_LO_MASK 0x3ff > > +#define PAGE_SEL_OFFSET_SHIFT 10 > > > > -#define PAB_AXI_PIO_CTRL 0x0840 > > -#define APIO_EN_MASK 0xf > > +#define PAB_AXI_PIO_CTRL 0x0840 > > +#define APIO_EN_MASK 0xf > > > > -#define PAB_PEX_PIO_CTRL 0x08c0 > > -#define PIO_ENABLE_SHIFT 0 > > +#define PAB_PEX_PIO_CTRL 0x08c0 > > +#define PIO_ENABLE_SHIFT 0 > > > > #define PAB_INTP_AMBA_MISC_ENB 0x0b0c > > -#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > +#define PAB_INTP_AMBA_MISC_STAT0x0b1c > > #define PAB_INTP_INTX_MASK0x01e0 > > #define PAB_INTP_MSI_MASK 0x8 > > > > -#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > > -#define WIN_ENABLE_SHIFT 0 > > -#define WIN_TYPE_SHIFT1 > > +#define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0, win) > > +#define WIN_ENABLE_SHIFT 0 > > +#define WIN_TYPE_SHIFT1 > > > > #define PAB_EXT_AXI_AMAP_SIZE(win) PAB_EXT_REG_ADDR(0xbaf0, > win) > > > > @@ -70,16 +72,16 @@ > > #define AXI_WINDOW_ALIGN_MASK 3 > > > > #define PAB_AXI_AMAP_PEX_WIN_L(win)PAB_RE
RE: [PATCHv5 03/20] PCI: mobiveil: Correct the returned error number
Hi Lorenzo,
Thanks for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年7月3日 22:17
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 03/20] PCI: mobiveil: Correct the returned error
> number
>
> On Fri, Apr 12, 2019 at 08:35:30AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > This patch corrects the returned error number by convention, and
> > removes an unnecessary error check.
>
> Two distinct changes, two patches, please split and repost.
Yes, will split and rebase on the new branch.
Thanks,
Zhiqiang
>
> Lorenzo
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index b87471f08a40..563210e731d3 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -819,7 +819,7 @@ static int mobiveil_pcie_init_irq_domain(struct
> > mobiveil_pcie *pcie)
> >
> > if (!pcie->intx_domain) {
> > dev_err(dev, "Failed to get a INTx IRQ domain\n");
> > - return -ENODEV;
> > + return -ENOMEM;
> > }
> >
> > raw_spin_lock_init(>intx_mask_lock);
> > @@ -845,11 +845,9 @@ static int mobiveil_pcie_probe(struct
> platform_device *pdev)
> > /* allocate the PCIe port */
> > bridge = devm_pci_alloc_host_bridge(dev, sizeof(*pcie));
> > if (!bridge)
> > - return -ENODEV;
> > + return -ENOMEM;
> >
> > pcie = pci_host_bridge_priv(bridge);
> > - if (!pcie)
> > - return -ENOMEM;
> >
> > pcie->pdev = pdev;
> >
> > @@ -866,7 +864,7 @@ static int mobiveil_pcie_probe(struct
> platform_device *pdev)
> > >resources, );
> > if (ret) {
> > dev_err(dev, "Getting bridge resources failed\n");
> > - return -ENOMEM;
> > + return ret;
> > }
> >
> > /*
> > --
> > 2.17.1
> >
RE: [PATCHv5 00/20] PCI: mobiveil: fixes for Mobiveil PCIe Host Bridge IP driver
Hi Lorenzo, Thanks a lot for your comments! > -Original Message- > From: Lorenzo Pieralisi > Sent: 2019年7月3日 18:33 > To: Z.q. Hou > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com; > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li > ; catalin.mari...@arm.com; will.dea...@arm.com; > Mingkai Hu ; M.h. Lian ; > Xiaowei Bao > Subject: Re: [PATCHv5 00/20] PCI: mobiveil: fixes for Mobiveil PCIe Host > Bridge IP driver > > On Fri, Apr 12, 2019 at 08:35:11AM +, Z.q. Hou wrote: > > From: Hou Zhiqiang > > > > This patch set is to add fixes for Mobiveil PCIe Host driver. > > And these patches are splited from the thread below: > > > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpatch > > > work.ozlabs.org%2Fproject%2Flinux-pci%2Flist%2F%3Fseries%3D96417 > p;d > > > ata=02%7C01%7Czhiqiang.hou%40nxp.com%7C0d32165274bf4c678b4808d > 6ffa1e42 > > > f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63697746817272 > 2471 > > > sdata=RLgfyNRBIRePuLFTCQe4RQYleeXDevwtVN4I6ZFkS1s%3Dreserv > ed=0 > > > > Hou Zhiqiang (20): > > PCI: mobiveil: Unify register accessors > > PCI: mobiveil: Format the code without functionality change > > PCI: mobiveil: Correct the returned error number > > PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI > > PCI: mobiveil: Correct PCI base address in MEM/IO outbound windows > > PCI: mobiveil: Replace the resource list iteration function > > PCI: mobiveil: Use WIN_NUM_0 explicitly for CFG outbound window > > PCI: mobiveil: Use the 1st inbound window for MEM inbound > transactions > > PCI: mobiveil: Correct inbound/outbound window setup routines > > PCI: mobiveil: Fix the INTx process errors > > PCI: mobiveil: Correct the fixup of Class Code field > > PCI: mobiveil: Move the link up waiting out of mobiveil_host_init() > > PCI: mobiveil: Move IRQ chained handler setup out of DT parse > > PCI: mobiveil: Initialize Primary/Secondary/Subordinate bus numbers > > PCI: mobiveil: Fix the checking of valid device > > PCI: mobiveil: Add link up condition check > > PCI: mobiveil: Complete initialization of host even if no PCIe link > > PCI: mobiveil: Disable IB and OB windows set by bootloader > > PCI: mobiveil: Add 8-bit and 16-bit register accessors > > dt-bindings: PCI: mobiveil: Change gpio_slave and apb_csr to > > optional > > > > .../devicetree/bindings/pci/mobiveil-pcie.txt | 2 + > > drivers/pci/controller/pcie-mobiveil.c| 578 +++--- > > 2 files changed, 368 insertions(+), 212 deletions(-) > > I am putting together a branch with the patches I would like to queue, for > the ones I requested to split please wait for me, I will publish the branch > and > will ask you to rebase on top of it. > Ok, will split them and rebase on the new branch. Thanks, Zhiqiang > Lorenzo
RE: [PATCHv5 10/20] PCI: mobiveil: Fix the INTx process errors
Hi Lorenzo,
Thanks a lot for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月29日 1:06
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 10/20] PCI: mobiveil: Fix the INTx process errors
>
> On Fri, Apr 12, 2019 at 08:36:12AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > In the loop block, there is not code to update the loop key, this
> > patch updates the loop key by re-read the INTx status register.
> >
> > This patch also add the clearing of the handled INTx status.
>
> This is two bugs and that requires two patches, each of them fixing a specific
> issue.
>
> So split the patch into two and repost it.
Yes, will split it.
Thanks,
Zhiqiang
> Lorenzo
>
> > Note: Need MV to test this fix.
> >
> > Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
> > driver")
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 13 +
> > 1 file changed, 9 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 4ba458474e42..78e575e71f4d 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -361,6 +361,7 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> > /* Handle INTx */
> > if (intr_status & PAB_INTP_INTX_MASK) {
> > shifted_status = csr_readl(pcie, PAB_INTP_AMBA_MISC_STAT);
> > + shifted_status &= PAB_INTP_INTX_MASK;
> > shifted_status >>= PAB_INTX_START;
> > do {
> > for_each_set_bit(bit, _status, PCI_NUM_INTX) {
> > @@
> -372,12
> > +373,16 @@ static void mobiveil_pcie_isr(struct irq_desc *desc)
> > dev_err_ratelimited(dev, "unexpected
> > IRQ,
> INT%d\n",
> > bit);
> >
> > - /* clear interrupt */
> > - csr_writel(pcie,
> > - shifted_status << PAB_INTX_START,
> > + /* clear interrupt handled */
> > + csr_writel(pcie, 1 << (PAB_INTX_START + bit),
> >PAB_INTP_AMBA_MISC_STAT);
> > }
> > - } while ((shifted_status >> PAB_INTX_START) != 0);
> > +
> > + shifted_status = csr_readl(pcie,
> > + PAB_INTP_AMBA_MISC_STAT);
> > + shifted_status &= PAB_INTP_INTX_MASK;
> > + shifted_status >>= PAB_INTX_START;
> > + } while (shifted_status != 0);
> > }
> >
> > /* read extra MSI status register */
> > --
> > 2.17.1
> >
RE: [PATCHv5 09/20] PCI: mobiveil: Correct inbound/outbound window setup routines
Hi Lorenzo,
Thanks a lot for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月29日 0:42
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 09/20] PCI: mobiveil: Correct inbound/outbound
> window setup routines
>
> On Fri, Apr 12, 2019 at 08:36:06AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Outbound window routine:
> > - Remove unused var definitions and register read operations.
> > - Add the upper 32-bit cpu address setup of the window.
> > - Instead of blindly write, only change the fields specified.
> > - Mask the lower bits of window size in case override the
> >control bits.
> > - Check if the passing window number is available, instead of
> >the total number of the initialized windows.
> >
> > Inbound window routine:
> > - Add parameter 'u64 cpu_addr' to specify the cpu address
> >of the window instead of using 'pci_addr'.
> > - Change 'int pci_addr' to 'u64 pci_addr', and add setup
> >of the upper 32-bit PCI address of the window.
> > - Move the PCIe PIO master enablement to mobiveil_host_init().
> > - Instead of blindly write, only change the fields specified.
> > - Mask the lower bits of window size in case override the
> >control bits.
> > - Check if the passing window number is available, instead of
> >the total number of the initialized windows.
> > - And add the statistic of initialized inbound windows.
> >
> > Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP
> > driver")
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 70
> > +++---
> > 1 file changed, 42 insertions(+), 28 deletions(-)
>
> There are two things to be done here:
>
> 1) Separate fixes from refactoring
> 2) Each fix should be standalone and solve one problem only
>
> The commit log is a list of changes, some of which I can't parse.
>
> You should split this patch as described above and repost it separately but
> first I will try to merge what I can from this series, do not repost as yet.
>
Yes, will split it.
Thanks,
Zhiqiang
> Thanks,
> Lorenzo
>
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index e88afc792a5c..4ba458474e42 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -65,9 +65,13 @@
> > #define PAB_AXI_AMAP_CTRL(win) PAB_REG_ADDR(0x0ba0,
> win)
> > #define WIN_ENABLE_SHIFT 0
> > #define WIN_TYPE_SHIFT1
> > +#define WIN_TYPE_MASK 0x3
> > +#define WIN_SIZE_SHIFT10
> > +#define WIN_SIZE_MASK 0x3f
> >
> > #define PAB_EXT_AXI_AMAP_SIZE(win) PAB_EXT_REG_ADDR(0xbaf0,
> win)
> >
> > +#define PAB_EXT_AXI_AMAP_AXI_WIN(win)
> PAB_EXT_REG_ADDR(0x80a0, win)
> > #define PAB_AXI_AMAP_AXI_WIN(win) PAB_REG_ADDR(0x0ba4, win)
> > #define AXI_WINDOW_ALIGN_MASK 3
> >
> > @@ -82,8 +86,10 @@
> > #define PAB_PEX_AMAP_CTRL(win) PAB_REG_ADDR(0x4ba0,
> win)
> > #define AMAP_CTRL_EN_SHIFT0
> > #define AMAP_CTRL_TYPE_SHIFT 1
> > +#define AMAP_CTRL_TYPE_MASK 3
> >
> > #define PAB_EXT_PEX_AMAP_SIZEN(win)PAB_EXT_REG_ADDR(0xbef0,
> win)
> > +#define PAB_EXT_PEX_AMAP_AXI_WIN(win)
> PAB_EXT_REG_ADDR(0xb4a0, win)
> > #define PAB_PEX_AMAP_AXI_WIN(win) PAB_REG_ADDR(0x4ba4,
> win)
> > #define PAB_PEX_AMAP_PEX_WIN_L(win)PAB_REG_ADDR(0x4ba8,
> win)
> > #define PAB_PEX_AMAP_PEX_WIN_H(win)PAB_REG_ADDR(0x4bac,
> win)
> > @@ -455,49 +461,51 @@ static int mobiveil_pcie_parse_dt(struct
> > mobiveil_pcie *pcie) }
> >
> > static void program_ib_windows(struct mobiveil_pcie *pcie, int
> win_num,
> > - int pci_addr, u32 type, u64 size)
> > + u64 cpu_addr, u64 pci_addr, u32 type, u64
RE: [PATCHv5 08/20] PCI: mobiveil: Use the 1st inbound window for MEM inbound transactions
Hi Lorenzo,
Thanks a lot for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月29日 0:02
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 08/20] PCI: mobiveil: Use the 1st inbound window for
> MEM inbound transactions
>
> On Fri, Apr 12, 2019 at 08:36:00AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > The inbound windows have independent register set against outbound
> windows.
> > This patch change the MEM inbound window to the first one.
>
> You mean that windows 0 can be used as well as window 1 for inbound
> windows so it is better to opt for window 0 for consistency ?
I mean the inbound windows and outbound windows are independent, they
have themselves' registers, and both serial number starts from 0:
Inbound windows: #0, #1, #2...
Outbound windows: #0, #1, #2...
Thanks,
Zhiqiang
> Lorenzo
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index df71c11b4810..e88afc792a5c 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -616,7 +616,7 @@ static int mobiveil_host_init(struct mobiveil_pcie
> *pcie)
> >CFG_WINDOW_TYPE, resource_size(pcie->ob_io_res));
> >
> > /* memory inbound translation window */
> > - program_ib_windows(pcie, WIN_NUM_1, 0, MEM_WINDOW_TYPE,
> IB_WIN_SIZE);
> > + program_ib_windows(pcie, WIN_NUM_0, 0, MEM_WINDOW_TYPE,
> > +IB_WIN_SIZE);
> >
> > /* Get the I/O and memory ranges from DT */
> > resource_list_for_each_entry(win, >resources) {
> > --
> > 2.17.1
> >
RE: [PATCHv5 04/20] PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI
Hi Lorenzo,
Thanks a lot for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月28日 19:36
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> MSI_FLAG_MULTI_PCI_MSI
>
> On Mon, Jun 17, 2019 at 10:34:35AM +, Z.q. Hou wrote:
>
> [...]
>
> > > There is nothing obvious. Write what you are fixing in the commit
> > > log and I will apply the patch, I won't write the commit log for
> > > you. Anyone should be able to understand why a patch was needed by
> > > reading the commit log, it is as important as writing the code itself.
> >
> > With the flag MSI_FLAG_MULTI_PCI_MSI, when the Endpoint allocates
> > multiple MSI, it will trigger the "WARN_ON(nr_irqs != 1);" in
> > mobiveil_irq_msi_domain_alloc(), this is the issue this patch want to
> > fix.
>
> And that's wrong. Marc explained why this controller does not support Multi
> MSI and that's what should go in the commit log, triggering a WARN_ON is
> the least of the problems (and the WARN_ON can even be removed after
> this patch is applied), if it was used as a bandaid to prevent allocating
> Multi
> MSI it is even more broken.
>
Yes, I agree, the root cause is hardware limitation, is the following changelog
acceptable?
Changelog:
The Mobiveil internal MSI controller uses separate target address per MSI,
so, it is unable to support Multiple MSI feature, which requires the same
target address and incremental MSI_DATA values. This patch is to remove
the flag MSI_FLAG_MULTI_PCI_MSI.
Thanks,
Zhiqiang
> Lorenzo
>
> > Thanks,
> > Zhiqiang
> >
> > >
> > > Thanks,
> > > Lorenzo
> > >
> > > > Thanks,
> > > > Zhiqiang
> > > >
> > > > >
> > > > > Lorenzo
> > > > >
> > > > > > Subbu, did you test with Endpoint supporting multi MSI?
> > > > > >
> > > > > > Thanks,
> > > > > > Zhiqiang
> > > > > >
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Lorenzo
> > > > > > >
> > > > > > > > Fixes: 1e913e58335f ("PCI: mobiveil: Add MSI support")
> > > > > > > > Signed-off-by: Hou Zhiqiang
> > > > > > > > Reviewed-by: Minghuan Lian
> > > > > > > > ---
> > > > > > > > V5:
> > > > > > > > - Corrected the subject.
> > > > > > > >
> > > > > > > > drivers/pci/controller/pcie-mobiveil.c | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > > > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > > > > > index 563210e731d3..a0dd337c6214 100644
> > > > > > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > > > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > > > > > @@ -703,7 +703,7 @@ static struct irq_chip
> > > > > > > > mobiveil_msi_irq_chip = {
> > > > > > > >
> > > > > > > > static struct msi_domain_info mobiveil_msi_domain_info = {
> > > > > > > > .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> > > > > > > MSI_FLAG_USE_DEF_CHIP_OPS |
> > > > > > > > - MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
> > > > > > > > + MSI_FLAG_PCI_MSIX),
> > > > > > > > .chip = _msi_irq_chip,
> > > > > > > > };
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.17.1
> > > > > > > >
[PATCHv7 6/7] arm64: dts: lx2160a: Add PCIe controller DT nodes
From: Hou Zhiqiang
The LX2160A integrated 6 PCIe Gen4 controllers.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
---
V7:
- No change.
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 163 ++
1 file changed, 163 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index e6fdba39453c..591192699c94 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -972,5 +972,168 @@
};
};
};
+
+ pcie@340 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
+ 0x80 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 110
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 111
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 112
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@350 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
+ 0x88 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 114
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 115
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 116
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 117
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@360 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
+ 0x90 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <256>;
+ ppio-wins = <24>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x90 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+
[PATCHv7 5/7] PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
From: Hou Zhiqiang
This PCIe controller is based on the Mobiveil GPEX IP, which is
compatible with the PCI Express™ Base Specification, Revision 4.0.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
---
V7:
- No change.
drivers/pci/controller/mobiveil/Kconfig | 10 +
drivers/pci/controller/mobiveil/Makefile | 1 +
.../mobiveil/pcie-layerscape-gen4.c | 255 ++
.../pci/controller/mobiveil/pcie-mobiveil.h | 16 +-
4 files changed, 280 insertions(+), 2 deletions(-)
create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
diff --git a/drivers/pci/controller/mobiveil/Kconfig
b/drivers/pci/controller/mobiveil/Kconfig
index 64343c07bfed..c823be8dab1c 100644
--- a/drivers/pci/controller/mobiveil/Kconfig
+++ b/drivers/pci/controller/mobiveil/Kconfig
@@ -21,4 +21,14 @@ config PCIE_MOBIVEIL_PLAT
Soft IP. It has up to 8 outbound and inbound windows
for address translation and it is a PCIe Gen4 IP.
+config PCIE_LAYERSCAPE_GEN4
+ bool "Freescale Layerscape PCIe Gen4 controller"
+ depends on PCI
+ depends on OF && (ARM64 || ARCH_LAYERSCAPE)
+ depends on PCI_MSI_IRQ_DOMAIN
+ select PCIE_MOBIVEIL_HOST
+ help
+ Say Y here if you want PCIe Gen4 controller support on
+ Layerscape SoCs. The PCIe controller can work in RC or
+ EP mode according to RCW[HOST_AGT_PEX] setting.
endmenu
diff --git a/drivers/pci/controller/mobiveil/Makefile
b/drivers/pci/controller/mobiveil/Makefile
index 9fb6d1c6504d..99d879de32d6 100644
--- a/drivers/pci/controller/mobiveil/Makefile
+++ b/drivers/pci/controller/mobiveil/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
+obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie-layerscape-gen4.o
diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
new file mode 100644
index ..51543555c75d
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe Gen4 host controller driver for NXP Layerscape SoCs
+ *
+ * Copyright 2019 NXP
+ *
+ * Author: Zhiqiang Hou
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-mobiveil.h"
+
+/* LUT and PF control registers */
+#define PCIE_LUT_OFF 0x8
+#define PCIE_PF_OFF0xc
+#define PCIE_PF_INT_STAT 0x18
+#define PF_INT_STAT_PABRST BIT(31)
+
+#define PCIE_PF_DBG0x7fc
+#define PF_DBG_LTSSM_MASK 0x3f
+#define PF_DBG_LTSSM_L00x2d /* L0 state */
+#define PF_DBG_WE BIT(31)
+#define PF_DBG_PABRBIT(27)
+
+#define to_ls_pcie_g4(x) platform_get_drvdata((x)->pdev)
+
+struct ls_pcie_g4 {
+ struct mobiveil_pcie pci;
+ struct delayed_work dwork;
+ int irq;
+};
+
+static inline u32 ls_pcie_g4_lut_readl(struct ls_pcie_g4 *pcie, u32 off)
+{
+ return ioread32(pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
+}
+
+static inline void ls_pcie_g4_lut_writel(struct ls_pcie_g4 *pcie,
+u32 off, u32 val)
+{
+ iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
+}
+
+static inline u32 ls_pcie_g4_pf_readl(struct ls_pcie_g4 *pcie, u32 off)
+{
+ return ioread32(pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
+}
+
+static inline void ls_pcie_g4_pf_writel(struct ls_pcie_g4 *pcie,
+ u32 off, u32 val)
+{
+ iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
+}
+
+static bool ls_pcie_g4_is_bridge(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = >pci;
+ u32 header_type;
+
+ header_type = csr_readb(mv_pci, PCI_HEADER_TYPE);
+ header_type &= 0x7f;
+
+ return header_type == PCI_HEADER_TYPE_BRIDGE;
+}
+
+static int ls_pcie_g4_link_up(struct mobiveil_pcie *pci)
+{
+ struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
+ u32 state;
+
+ state = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
+ state = state & PF_DBG_LTSSM_MASK;
+
+ if (state == PF_DBG_LTSSM_L0)
+ return 1;
+
+ return 0;
+}
+
+static void ls_pcie_g4_reinit_hw(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = >pci;
+ struct device *dev = _pci->pdev->dev;
+ u32 val, act_stat;
+ int to = 100;
+
+ /* Poll for pab_csb_reset to set and PAB activity to clear */
+ do {
+ usleep_range(10, 15);
+ val = ls_pcie_g4_pf_readl(pcie, PCIE_PF_INT_STAT);
+ act_stat = csr_readl(mv_pci, PAB_ACTIVITY_STAT);
+ } while
[PATCHv7 7/7] arm64: defconfig: Enable CONFIG_PCIE_LAYERSCAPE_GEN4
From: Hou Zhiqiang Enable the PCIe Gen4 controller driver for Layerscape SoCs. Signed-off-by: Hou Zhiqiang Reviewed-by: Minghuan Lian --- V7: - No change. arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index fbbc065415d4..8d587f99 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -187,6 +187,7 @@ CONFIG_PCI_HOST_THUNDER_PEM=y CONFIG_PCI_HOST_THUNDER_ECAM=y CONFIG_PCIE_ROCKCHIP_HOST=m CONFIG_PCI_LAYERSCAPE=y +CONFIG_PCIE_LAYERSCAPE_GEN4=y CONFIG_PCI_HISI=y CONFIG_PCIE_QCOM=y CONFIG_PCIE_ARMADA_8K=y -- 2.17.1
[PATCHv7 4/7] PCI: mobiveil: Add 8-bit and 16-bit CSR register accessors
From: Hou Zhiqiang
There are some 8-bit and 16-bit registers in PCIe configuration
space, so add these accessors accordingly.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
Reviewed-by: Subrahmanya Lingappa
---
V7:
- New patch moved from the fixes series.
.../pci/controller/mobiveil/pcie-mobiveil.h | 20 +++
1 file changed, 20 insertions(+)
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index 159b0142a2bc..a729a4f879fe 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
@@ -185,9 +185,29 @@ static inline u32 csr_readl(struct mobiveil_pcie *pcie,
u32 off)
return csr_read(pcie, off, 0x4);
}
+static inline u32 csr_readw(struct mobiveil_pcie *pcie, u32 off)
+{
+ return csr_read(pcie, off, 0x2);
+}
+
+static inline u32 csr_readb(struct mobiveil_pcie *pcie, u32 off)
+{
+ return csr_read(pcie, off, 0x1);
+}
+
static inline void csr_writel(struct mobiveil_pcie *pcie, u32 val, u32 off)
{
csr_write(pcie, val, off, 0x4);
}
+static inline void csr_writew(struct mobiveil_pcie *pcie, u32 val, u32 off)
+{
+ csr_write(pcie, val, off, 0x2);
+}
+
+static inline void csr_writeb(struct mobiveil_pcie *pcie, u32 val, u32 off)
+{
+ csr_write(pcie, val, off, 0x1);
+}
+
#endif /* _PCIE_MOBIVEIL_H */
--
2.17.1
[PATCHv7 2/7] PCI: mobiveil: Make mobiveil_host_init() can be used to re-init host
From: Hou Zhiqiang
Make the mobiveil_host_init() function can be used to re-init
host controller's PAB and GPEX CSR register block, as NXP
integrated Mobiveil IP has to reset and then re-init the PAB
and GPEX CSR registers upon hot-reset.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Subrahmanya Lingappa
---
V7:
- No change.
.../controller/mobiveil/pcie-mobiveil-host.c | 41 ++-
.../pci/controller/mobiveil/pcie-mobiveil.h | 3 +-
2 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
index c4b98a31d426..fc401af030de 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
@@ -219,7 +219,7 @@ static void mobiveil_pcie_enable_msi(struct mobiveil_pcie
*pcie)
writel_relaxed(1, pcie->apb_csr_base + MSI_ENABLE_OFFSET);
}
-static int mobiveil_host_init(struct mobiveil_pcie *pcie)
+int mobiveil_host_init(struct mobiveil_pcie *pcie, bool reinit)
{
u32 value, pab_ctrl, type;
struct resource_entry *win;
@@ -231,11 +231,16 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
for (i = 0; i < pcie->ppio_wins; i++)
mobiveil_pcie_disable_ib_win(pcie, i);
- /* setup bus numbers */
- value = csr_readl(pcie, PCI_PRIMARY_BUS);
- value &= 0xff00;
- value |= 0x00ff0100;
- csr_writel(pcie, value, PCI_PRIMARY_BUS);
+ pcie->ib_wins_configured = 0;
+ pcie->ob_wins_configured = 0;
+
+ if (!reinit) {
+ /* setup bus numbers */
+ value = csr_readl(pcie, PCI_PRIMARY_BUS);
+ value &= 0xff00;
+ value |= 0x00ff0100;
+ csr_writel(pcie, value, PCI_PRIMARY_BUS);
+ }
/*
* program Bus Master Enable Bit in Command Register in PAB Config
@@ -281,7 +286,7 @@ static int mobiveil_host_init(struct mobiveil_pcie *pcie)
program_ib_windows(pcie, WIN_NUM_0, 0, 0, MEM_WINDOW_TYPE, IB_WIN_SIZE);
/* Get the I/O and memory ranges from DT */
- resource_list_for_each_entry(win, >resources) {
+ resource_list_for_each_entry(win, pcie->resources) {
if (resource_type(win->res) == IORESOURCE_MEM) {
type = MEM_WINDOW_TYPE;
} else if (resource_type(win->res) == IORESOURCE_IO) {
@@ -552,8 +557,6 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
resource_size_t iobase;
int ret;
- INIT_LIST_HEAD(>resources);
-
ret = mobiveil_pcie_parse_dt(pcie);
if (ret) {
dev_err(dev, "Parsing DT failed, ret: %x\n", ret);
@@ -562,34 +565,35 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
/* parse the host bridge base addresses from the device tree file */
ret = devm_of_pci_get_host_bridge_resources(dev, 0, 0xff,
- >resources, );
+ >windows, );
if (ret) {
dev_err(dev, "Getting bridge resources failed\n");
return ret;
}
+ pcie->resources = >windows;
+
/*
* configure all inbound and outbound windows and prepare the RC for
* config access
*/
- ret = mobiveil_host_init(pcie);
+ ret = mobiveil_host_init(pcie, false);
if (ret) {
dev_err(dev, "Failed to initialize host\n");
- goto error;
+ return ret;
}
ret = mobiveil_pcie_interrupt_init(pcie);
if (ret) {
dev_err(dev, "Interrupt init failed\n");
- goto error;
+ return ret;
}
- ret = devm_request_pci_bus_resources(dev, >resources);
+ ret = devm_request_pci_bus_resources(dev, pcie->resources);
if (ret)
- goto error;
+ return ret;
/* Initialize bridge */
- list_splice_init(>resources, >windows);
bridge->dev.parent = dev;
bridge->sysdata = pcie;
bridge->busnr = pcie->rp.root_bus_nr;
@@ -604,7 +608,7 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
/* setup the kernel resources for the newly added PCIe root bus */
ret = pci_scan_root_bus_bridge(bridge);
if (ret)
- goto error;
+ return ret;
bus = bridge->bus;
@@ -614,7 +618,4 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
pci_bus_add_devices(bus);
return 0;
-error:
- pci_free_resource_list(>resources);
- return ret;
}
diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
index dda40b31a3b6..159b0142a2bc 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil.h
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil.h
[PATCHv7 3/7] dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controller
From: Hou Zhiqiang
Add PCIe Gen4 controller DT bindings of NXP Layerscape SoCs.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Rob Herring
---
V7:
- No change.
.../bindings/pci/layerscape-pcie-gen4.txt | 52 +++
MAINTAINERS | 8 +++
2 files changed, 60 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
new file mode 100644
index ..b40fb5d15d3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
@@ -0,0 +1,52 @@
+NXP Layerscape PCIe Gen4 controller
+
+This PCIe controller is based on the Mobiveil PCIe IP and thus inherits all
+the common properties defined in mobiveil-pcie.txt.
+
+Required properties:
+- compatible: should contain the platform identifier such as:
+ "fsl,lx2160a-pcie"
+- reg: base addresses and lengths of the PCIe controller register blocks.
+ "csr_axi_slave": Bridge config registers
+ "config_axi_slave": PCIe controller registers
+- interrupts: A list of interrupt outputs of the controller. Must contain an
+ entry for each entry in the interrupt-names property.
+- interrupt-names: It could include the following entries:
+ "intr": The interrupt that is asserted for controller interrupts
+ "aer": Asserted for aer interrupt when chip support the aer interrupt with
+none MSI/MSI-X/INTx mode,but there is interrupt line for aer.
+ "pme": Asserted for pme interrupt when chip support the pme interrupt with
+none MSI/MSI-X/INTx mode,but there is interrupt line for pme.
+- dma-coherent: Indicates that the hardware IP block can ensure the coherency
+ of the data transferred from/to the IP block. This can avoid the software
+ cache flush/invalid actions, and improve the performance significantly.
+- msi-parent : See the generic MSI binding described in
+ Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+Example:
+
+ pcie@340 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010 /* controller registers
*/
+ 0x80 0x 0x0 0x1000>; /* configuration space
*/
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /* controller
interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ dma-coherent;
+ bus-range = <0x0 0xff>;
+ msi-parent = <>;
+ ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 110
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 111
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 112
IRQ_TYPE_LEVEL_HIGH>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2c1cc66d61a9..030a9f31dadb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12098,6 +12098,14 @@ L: linux-arm-ker...@lists.infradead.org
S: Maintained
F: drivers/pci/controller/dwc/*layerscape*
+PCI DRIVER FOR NXP LAYERSCAPE GEN4 CONTROLLER
+M: Hou Zhiqiang
+L: linux-...@vger.kernel.org
+L: linux-arm-ker...@lists.infradead.org
+S: Maintained
+F: Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
+F: drivers/pci/controller/mobibeil/pcie-layerscape-gen4.c
+
PCI DRIVER FOR GENERIC OF HOSTS
M: Will Deacon
L: linux-...@vger.kernel.org
--
2.17.1
[PATCHv7 0/7] PCI: refactor Mobiveil driver and add PCIe Gen4 driver for NXP Layerscape SoCs
From: Hou Zhiqiang
This patch set is aim to refactor the Mobiveil driver and add
PCIe support for NXP Layerscape series SoCs integrated Mobiveil's
PCIe Gen4 controller.
This patch set depends on:
http://patchwork.ozlabs.org/project/linux-pci/list/?series=102378
Hou Zhiqiang (7):
PCI: mobiveil: Refactor Mobiveil PCIe Host Bridge IP driver
PCI: mobiveil: Make mobiveil_host_init() can be used to re-init host
dt-bindings: PCI: Add NXP Layerscape SoCs PCIe Gen4 controller
PCI: mobiveil: Add 8-bit and 16-bit CSR register accessors
PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
arm64: dts: lx2160a: Add PCIe controller DT nodes
arm64: defconfig: Enable CONFIG_PCIE_LAYERSCAPE_GEN4
.../bindings/pci/layerscape-pcie-gen4.txt | 52 ++
MAINTAINERS | 10 +-
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 163 +
arch/arm64/configs/defconfig | 1 +
drivers/pci/controller/Kconfig| 11 +-
drivers/pci/controller/Makefile | 2 +-
drivers/pci/controller/mobiveil/Kconfig | 34 +
drivers/pci/controller/mobiveil/Makefile | 5 +
.../mobiveil/pcie-layerscape-gen4.c | 255
.../pcie-mobiveil-host.c} | 588 --
.../controller/mobiveil/pcie-mobiveil-plat.c | 59 ++
.../pci/controller/mobiveil/pcie-mobiveil.c | 248
.../pci/controller/mobiveil/pcie-mobiveil.h | 225 +++
13 files changed, 1160 insertions(+), 493 deletions(-)
create mode 100644
Documentation/devicetree/bindings/pci/layerscape-pcie-gen4.txt
create mode 100644 drivers/pci/controller/mobiveil/Kconfig
create mode 100644 drivers/pci/controller/mobiveil/Makefile
create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
rename drivers/pci/controller/{pcie-mobiveil.c =>
mobiveil/pcie-mobiveil-host.c} (51%)
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.h
--
2.17.1
[PATCHv7 1/7] PCI: mobiveil: Refactor Mobiveil PCIe Host Bridge IP driver
From: Hou Zhiqiang
Refactor the Mobiveil PCIe Host Bridge IP driver to make
it easier to add support for both RC and EP mode driver.
This patch moved the Mobiveil driver to an new directory
'drivers/pci/controller/mobiveil' and refactor it according
to the RC and EP abstraction.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
Reviewed-by: Subrahmanya Lingappa
---
V7:
- As the patch adding 8-bit and 16-bit CSR register accessors
is moved back, removed the lines of 8-bit and 16-bit CSR
accessors.
MAINTAINERS | 2 +-
drivers/pci/controller/Kconfig| 11 +-
drivers/pci/controller/Makefile | 2 +-
drivers/pci/controller/mobiveil/Kconfig | 24 +
drivers/pci/controller/mobiveil/Makefile | 4 +
.../pcie-mobiveil-host.c} | 549 +++---
.../controller/mobiveil/pcie-mobiveil-plat.c | 59 ++
.../pci/controller/mobiveil/pcie-mobiveil.c | 248
.../pci/controller/mobiveil/pcie-mobiveil.h | 192 ++
9 files changed, 617 insertions(+), 474 deletions(-)
create mode 100644 drivers/pci/controller/mobiveil/Kconfig
create mode 100644 drivers/pci/controller/mobiveil/Makefile
rename drivers/pci/controller/{pcie-mobiveil.c =>
mobiveil/pcie-mobiveil-host.c} (54%)
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 52ae92fe305b..2c1cc66d61a9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12141,7 +12141,7 @@ M: Hou Zhiqiang
L: linux-...@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/pci/mobiveil-pcie.txt
-F: drivers/pci/controller/pcie-mobiveil.c
+F: drivers/pci/controller/mobiveil/pcie-mobiveil*
PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support)
M: Thomas Petazzoni
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index fe9f9f13ce11..dec8e038cb17 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -241,16 +241,6 @@ config PCIE_MEDIATEK
Say Y here if you want to enable PCIe controller support on
MediaTek SoCs.
-config PCIE_MOBIVEIL
- bool "Mobiveil AXI PCIe controller"
- depends on ARCH_ZYNQMP || COMPILE_TEST
- depends on OF
- depends on PCI_MSI_IRQ_DOMAIN
- help
- Say Y here if you want to enable support for the Mobiveil AXI PCIe
- Soft IP. It has up to 8 outbound and inbound windows
- for address translation and it is a PCIe Gen4 IP.
-
config PCIE_TANGO_SMP8759
bool "Tango SMP8759 PCIe controller (DANGEROUS)"
depends on ARCH_TANGO && PCI_MSI && OF
@@ -282,4 +272,5 @@ config VMD
module will be called vmd.
source "drivers/pci/controller/dwc/Kconfig"
+source "drivers/pci/controller/mobiveil/Kconfig"
endmenu
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index d56a507495c5..b79a615041a0 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -26,11 +26,11 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o
obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
-obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
+obj-y += mobiveil/
# The following drivers are for devices that use the generic ACPI
diff --git a/drivers/pci/controller/mobiveil/Kconfig
b/drivers/pci/controller/mobiveil/Kconfig
new file mode 100644
index ..64343c07bfed
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+
+menu "Mobiveil PCIe Core Support"
+ depends on PCI
+
+config PCIE_MOBIVEIL
+ bool
+
+config PCIE_MOBIVEIL_HOST
+bool
+ depends on PCI_MSI_IRQ_DOMAIN
+select PCIE_MOBIVEIL
+
+config PCIE_MOBIVEIL_PLAT
+ bool "Mobiveil AXI PCIe controller"
+ depends on ARCH_ZYNQMP || COMPILE_TEST
+ depends on OF
+ select PCIE_MOBIVEIL_HOST
+ help
+ Say Y here if you want to enable support for the Mobiveil AXI PCIe
+ Soft IP. It has up to 8 outbound and inbound windows
+ for address translation and it is a PCIe Gen4 IP.
+
+endmenu
diff --git a/drivers/pci/controller/mobiveil/Makefile
b/drivers/pci/controller/mobiveil/Makefile
new file mode 100644
index ..9fb6d1c6504d
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
RE: [PATCHv5 10/20] PCI: mobiveil: Fix the INTx process errors
Hi Karthikeyan,
> -Original Message-
> From: Karthikeyan Mitran [mailto:m.karthike...@mobiveil.co.in]
> Sent: 2019年6月19日 13:29
> To: Lorenzo Pieralisi
> Cc: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> catalin.mari...@arm.com; will.dea...@arm.com; Mingkai Hu
> ; M.h. Lian ; Xiaowei Bao
>
> Subject: Re: [PATCHv5 10/20] PCI: mobiveil: Fix the INTx process errors
>
> On Fri, Jun 14, 2019 at 4:14 PM Lorenzo Pieralisi
> wrote:
> >
> > On Fri, Jun 14, 2019 at 12:38:51PM +0530, Karthikeyan Mitran wrote:
> > > Hi Lorenzo and Hou Zhiqiang
> > > PAB_INTP_AMBA_MISC_STAT does have other status in the higher bits,
> > > it should have been masked before checking for the status
> >
> > You are the maintainer for this driver, so if there is something to be
> > changed you must post a patch to that extent, I do not understand what
> > the above means, write the code to fix it, I won't do it.
> >
> > I am getting a bit annoyed with this Mobiveil driver so either you
> > guys sort this out or I will have to remove it from the kernel.
> >
> > > Acked-by: Karthikeyan Mitran
> >
> > Ok I assume this means you tested it but according to what you say
> > above, are there still issues with this code path ? Should we update
> > the patch ?
> Tested-by: Karthikeyan Mitran This patch
> fixes the INTx status extraction and handling, I don't see any need to update
> this patch.
Thanks a lot for your test!
Zhiqiang
> >
> > Moreover:
> >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkern
> >
> elnewbies.org%2FPatchCulturedata=02%7C01%7Czhiqiang.hou%40nx
> p.com
> > %7C1445570163bb479cae3708d6f47709fb%7C686ea1d3bc2b4c6fa92cd99
> c5c301635
> > %7C0%7C0%7C636965189438647036sdata=xXQ5MCPuXV08Cd%2Fi
> TBnkAmOVGOsH
> > XFi7e1xcvlYIwiA%3Dreserved=0
> >
> > Please read it and never top-post.
> Thank you very much, for the information.
>
> >
> > Thanks,
> > Lorenzo
> >
> > > On Wed, Jun 12, 2019 at 8:38 PM Lorenzo Pieralisi
> > > wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 08:36:12AM +, Z.q. Hou wrote:
> > > > > From: Hou Zhiqiang
> > > > >
> > > > > In the loop block, there is not code to update the loop key,
> > > > > this patch updates the loop key by re-read the INTx status
> > > > > register.
> > > > >
> > > > > This patch also add the clearing of the handled INTx status.
> > > > >
> > > > > Note: Need MV to test this fix.
> > > >
> > > > This means INTX were never tested and current code handling them
> > > > is, AFAICS, an infinite loop which is very very bad.
> > > >
> > > > This is a gross bug and must be fixed as soon as possible.
> > > >
> > > > I want Karthikeyan ACK and Tested-by on this patch.
> > > >
> > > > Lorenzo
> > > >
> > > > > Fixes: 9af6bcb11e12 ("PCI: mobiveil: Add Mobiveil PCIe Host
> > > > > Bridge IP driver")
> > > > > Signed-off-by: Hou Zhiqiang
> > > > > Reviewed-by: Minghuan Lian
> > > > > Reviewed-by: Subrahmanya Lingappa
>
> > > > > ---
> > > > > V5:
> > > > > - Corrected and retouched the subject and changelog.
> > > > >
> > > > > drivers/pci/controller/pcie-mobiveil.c | 13 +
> > > > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > > index 4ba458474e42..78e575e71f4d 100644
> > > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > > @@ -361,6 +361,7 @@ static void mobiveil_pcie_isr(struct irq_desc
> *desc)
> > > > > /* Handle INTx */
> > > > > if (intr_status & PAB_INTP_INTX_MASK) {
> > > > > shifted_status = csr_readl(pcie,
> > > > > PAB_INTP_AMBA_MISC_STAT);
> > > > > + shifted_status &= PAB_INTP_INTX_MASK;
> > > > >
RE: [PATCHv5 18/20] PCI: mobiveil: Disable IB and OB windows set by bootloader
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月17日 17:31
> To: Z.q. Hou
> Cc: bhelg...@google.com; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 18/20] PCI: mobiveil: Disable IB and OB windows set
> by bootloader
>
> On Sat, Jun 15, 2019 at 05:03:33AM +, Z.q. Hou wrote:
> > Hi Lorenzo,
> >
> > > -Original Message-
> > > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > > Sent: 2019年6月13日 0:24
> > > To: Z.q. Hou ; bhelg...@google.com
> > > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > robh...@kernel.org; mark.rutl...@arm.com;
> > > robh+l.subrahma...@mobiveil.co.in;
> > > shawn...@kernel.org; Leo Li ;
> > > catalin.mari...@arm.com; will.dea...@arm.com; Mingkai Hu
> > > ; M.h. Lian ; Xiaowei
> Bao
> > >
> > > Subject: Re: [PATCHv5 18/20] PCI: mobiveil: Disable IB and OB
> > > windows set by bootloader
> > >
> > > On Fri, Apr 12, 2019 at 08:37:00AM +, Z.q. Hou wrote:
> > > > From: Hou Zhiqiang
> > > >
> > > > Disable all inbound and outbound windows before set up the windows
> > > > in kernel, in case transactions match the window set by bootloader.
> > >
> > > There must be no PCI transactions ongoing at bootloader<->OS handover.
> > >
> >
> > Yes, exact.
> >
> > > The bootloader needs fixing and this patch should be dropped, the
> > > host bridge driver assumes the host bridge state is disabled,
> >
> > The host bridge driver should not assumes the host state is disabled,
> > actually u-boot enable/initialize the host and without disabling it
> > when transfer the control to Linux.
>
> Fix the bootloader and drop this patch, I explain to you why.
This patch is just to avoid uboot driver windows setup and Linux driver windows
setup overlap issue, please drop it if you don't think it's needed .
Thanks,
Zhiqiang
>
> > > it will program the bridge
> > > apertures from scratch with no ongoing transactions, anything
> > > deviating from this behaviour is a bootloader bug and a recipe for
> > > disaster.
> >
> > The point of this patch is not to fix the ongoing transaction issue,
> > it is to avoid a potential issue which is caused by the outbound
> > window enabled by bootloader overlapping with Linux enabled.
>
> See above.
>
> Lorenzo
>
> > Thanks,
> > Zhiqiang
> >
> > > Lorenzo
> > >
> > > > Signed-off-by: Hou Zhiqiang
> > > > Reviewed-by: Minghuan Lian
> > > > Reviewed-by: Subrahmanya Lingappa
> > > > ---
> > > > V5:
> > > > - No functionality change.
> > > >
> > > > drivers/pci/controller/pcie-mobiveil.c | 25
> > > > +
> > > > 1 file changed, 25 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > index 8dc87c7a600e..411e9779da12 100644
> > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > @@ -565,6 +565,24 @@ static int mobiveil_bringup_link(struct
> > > mobiveil_pcie *pcie)
> > > > return -ETIMEDOUT;
> > > > }
> > > >
> > > > +static void mobiveil_pcie_disable_ib_win(struct mobiveil_pcie
> > > > +*pcie, int idx) {
> > > > + u32 val;
> > > > +
> > > > + val = csr_readl(pcie, PAB_PEX_AMAP_CTRL(idx));
> > > > + val &= ~(1 << AMAP_CTRL_EN_SHIFT);
> > > > + csr_writel(pcie, val, PAB_PEX_AMAP_CTRL(idx)); }
> > > > +
> > > > +static void mobiveil_pcie_disable_ob_win(struct mobiveil_pcie
> > > > +*pcie, int idx) {
> > > > + u32 val;
> > > > +
> > > > + val = csr_readl(pcie, PAB_AXI_AMAP_CTRL(idx));
> > > > + val &= ~(1 << WIN_ENABLE_SHIFT);
> > > > + csr_writel(pcie, val, PAB_AXI_AMAP_CTRL(idx)); }
> > > > +
> > > > static void mobiveil_pcie_enable_msi(struct mobiveil_pcie *pcie) {
> > > > phys_addr_t msg_addr = pcie->pcie_reg_base; @@ -585,6 +603,13
> @@
> > > > static int mobiveil_host_init(struct mobiveil_pcie *pcie) {
> > > > u32 value, pab_ctrl, type;
> > > > struct resource_entry *win;
> > > > + int i;
> > > > +
> > > > + /* Disable all inbound/outbound windows */
> > > > + for (i = 0; i < pcie->apio_wins; i++)
> > > > + mobiveil_pcie_disable_ob_win(pcie, i);
> > > > + for (i = 0; i < pcie->ppio_wins; i++)
> > > > + mobiveil_pcie_disable_ib_win(pcie, i);
> > > >
> > > > /* setup bus numbers */
> > > > value = csr_readl(pcie, PCI_PRIMARY_BUS);
> > > > --
> > > > 2.17.1
> > > >
RE: [PATCHv5 04/20] PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月17日 17:34
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> MSI_FLAG_MULTI_PCI_MSI
>
> On Sat, Jun 15, 2019 at 01:30:39AM +, Z.q. Hou wrote:
> > Hi Lorenzo,
> >
> > > -Original Message-
> > > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > > Sent: 2019年6月12日 21:08
> > > To: Z.q. Hou
> > > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> > > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> > > ; catalin.mari...@arm.com;
> will.dea...@arm.com;
> > > Mingkai Hu ; M.h. Lian
> ;
> > > Xiaowei Bao
> > > Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> > > MSI_FLAG_MULTI_PCI_MSI
> > >
> > > On Wed, Jun 12, 2019 at 11:34:51AM +, Z.q. Hou wrote:
> > > > Hi Lorenzo,
> > > >
> > > > Thanks a lot for your comments!
> > > >
> > > > > -Original Message-
> > > > > From: Lorenzo Pieralisi
> > > > > Sent: 2019年6月12日 1:00
> > > > > To: Z.q. Hou
> > > > > Cc: linux-...@vger.kernel.org;
> > > > > linux-arm-ker...@lists.infradead.org;
> > > > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > > > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> > > > > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> > > > > ; catalin.mari...@arm.com;
> > > will.dea...@arm.com;
> > > > > Mingkai Hu ; M.h. Lian
> > > ;
> > > > > Xiaowei Bao
> > > > > Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> > > > > MSI_FLAG_MULTI_PCI_MSI
> > > > >
> > > > > On Fri, Apr 12, 2019 at 08:35:36AM +, Z.q. Hou wrote:
> > > > > > From: Hou Zhiqiang
> > > > > >
> > > > > > The current code does not support multiple MSIs, so remove the
> > > > > > corresponding flag from the msi_domain_info structure.
> > > > >
> > > > > Please explain me what's the problem before removing multi MSI
> support.
> > > >
> > > > NXP LX2 PCIe use the GIC-ITS instead of Mobiveil IP internal MSI
> > > > controller, so, I didn't encounter problem.
> > >
> > > Well, you sent a patch to fix an issue, explain me the issue you are
> > > fixing then, aka what have you sent this patch for ?
> >
> > I did not face issue, as I have explained NXP does not use the
> > Mobiveil IP's MSI controller. But obviously the MSI allocate function
> > does not support multiple MSI, so I submitted this patch.
>
> There is nothing obvious. Write what you are fixing in the commit log and I
> will
> apply the patch, I won't write the commit log for you. Anyone should be able
> to understand why a patch was needed by reading the commit log, it is as
> important as writing the code itself.
With the flag MSI_FLAG_MULTI_PCI_MSI, when the Endpoint allocates multiple
MSI, it will trigger the "WARN_ON(nr_irqs != 1);" in
mobiveil_irq_msi_domain_alloc(),
this is the issue this patch want to fix.
Thanks,
Zhiqiang
>
> Thanks,
> Lorenzo
>
> > Thanks,
> > Zhiqiang
> >
> > >
> > > Lorenzo
> > >
> > > > Subbu, did you test with Endpoint supporting multi MSI?
> > > >
> > > > Thanks,
> > > > Zhiqiang
> > > >
> > > > >
> > > > > Thanks,
> > > > > Lorenzo
> > > > >
> > > > > > Fixes: 1e913e58335f ("PCI: mobiveil: Add MSI support")
> > > > > > Signed-off-by: Hou Zhiqiang
> > > > > > Reviewed-by: Minghuan Lian
> > > > > > ---
> > > > > > V5:
> > > > > > - Corrected the subject.
> > > > > >
> > > > > > drivers/pci/controller/pcie-mobiveil.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > > > index 563210e731d3..a0dd337c6214 100644
> > > > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > > > @@ -703,7 +703,7 @@ static struct irq_chip
> > > > > > mobiveil_msi_irq_chip = {
> > > > > >
> > > > > > static struct msi_domain_info mobiveil_msi_domain_info = {
> > > > > > .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> > > > > MSI_FLAG_USE_DEF_CHIP_OPS |
> > > > > > - MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
> > > > > > + MSI_FLAG_PCI_MSIX),
> > > > > > .chip = _msi_irq_chip,
> > > > > > };
> > > > > >
> > > > > > --
> > > > > > 2.17.1
> > > > > >
RE: [PATCHv5 19/20] PCI: mobiveil: Add 8-bit and 16-bit register accessors
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月17日 17:29
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 19/20] PCI: mobiveil: Add 8-bit and 16-bit register
> accessors
>
> On Sat, Jun 15, 2019 at 01:13:48AM +, Z.q. Hou wrote:
> > Hi Lorenzo,
> >
> > > -Original Message-
> > > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> > > Sent: 2019年6月12日 21:54
> > > To: Z.q. Hou
> > > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> > > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> > > ; catalin.mari...@arm.com;
> will.dea...@arm.com;
> > > Mingkai Hu ; M.h. Lian
> ;
> > > Xiaowei Bao
> > > Subject: Re: [PATCHv5 19/20] PCI: mobiveil: Add 8-bit and 16-bit
> > > register accessors
> > >
> > > On Fri, Apr 12, 2019 at 08:37:05AM +, Z.q. Hou wrote:
> > > > From: Hou Zhiqiang
> > > >
> > > > There are some 8-bit and 16-bit registers in PCIe configuration
> > > > space, so add accessors for them.
> > > >
> > > > Signed-off-by: Hou Zhiqiang
> > > > Reviewed-by: Minghuan Lian
> > > > Reviewed-by: Subrahmanya Lingappa
> > > > ---
> > > > V5:
> > > > - Corrected and retouched the subject and changelog.
> > > > - No functionality change.
> > > >
> > > > drivers/pci/controller/pcie-mobiveil.c | 20
> > > > 1 file changed, 20 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > index 411e9779da12..456adfee393c 100644
> > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > @@ -268,11 +268,31 @@ static u32 csr_readl(struct mobiveil_pcie
> > > > *pcie,
> > > u32 off)
> > > > return csr_read(pcie, off, 0x4); }
> > > >
> > > > +static u32 csr_readw(struct mobiveil_pcie *pcie, u32 off) {
> > > > + return csr_read(pcie, off, 0x2); }
> > > > +
> > > > +static u32 csr_readb(struct mobiveil_pcie *pcie, u32 off) {
> > > > + return csr_read(pcie, off, 0x1); }
> > > > +
> > > > static void csr_writel(struct mobiveil_pcie *pcie, u32 val, u32
> > > > off) {
> > > > csr_write(pcie, val, off, 0x4);
> > > > }
> > > >
> > > > +static void csr_writew(struct mobiveil_pcie *pcie, u32 val, u32
> > > > +off) {
> > > > + csr_write(pcie, val, off, 0x2);
> > > > +}
> > > > +
> > > > +static void csr_writeb(struct mobiveil_pcie *pcie, u32 val, u32
> > > > +off) {
> > > > + csr_write(pcie, val, off, 0x1);
> > > > +}
> > > > +
> > >
> > > They are not used so you should drop this patch.
> >
> > NXP Layerscape PCIe Gen4 controller driver will use them, so don't
> > drop it.
>
> You add functions when they are needed, so drop this patch and squash it to
> the patch that use these functions.
>
Yes, agree, please drop it from this patch set.
Thanks,
Zhiqiang
> Lorenzo
>
> > Thanks,
> > Zhiqiang
> >
> > >
> > > Lorenzo
> > >
> > > > static bool mobiveil_pcie_link_up(struct mobiveil_pcie *pcie) {
> > > > return (csr_readl(pcie, LTSSM_STATUS) &
> > > > --
> > > > 2.17.1
> > > >
RE: [PATCHv5 18/20] PCI: mobiveil: Disable IB and OB windows set by bootloader
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月13日 0:24
> To: Z.q. Hou ; bhelg...@google.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> catalin.mari...@arm.com; will.dea...@arm.com; Mingkai Hu
> ; M.h. Lian ; Xiaowei Bao
>
> Subject: Re: [PATCHv5 18/20] PCI: mobiveil: Disable IB and OB windows set
> by bootloader
>
> On Fri, Apr 12, 2019 at 08:37:00AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Disable all inbound and outbound windows before set up the windows in
> > kernel, in case transactions match the window set by bootloader.
>
> There must be no PCI transactions ongoing at bootloader<->OS handover.
>
Yes, exact.
> The bootloader needs fixing and this patch should be dropped, the host bridge
> driver assumes the host bridge state is disabled,
The host bridge driver should not assumes the host state is disabled, actually
u-boot enable/initialize the host and without disabling it when transfer the
control to Linux.
> it will program the bridge
> apertures from scratch with no ongoing transactions, anything deviating from
> this behaviour is a bootloader bug and a recipe for disaster.
The point of this patch is not to fix the ongoing transaction issue, it is to
avoid
a potential issue which is caused by the outbound window enabled by bootloader
overlapping with Linux enabled.
Thanks,
Zhiqiang
> Lorenzo
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - No functionality change.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 8dc87c7a600e..411e9779da12 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -565,6 +565,24 @@ static int mobiveil_bringup_link(struct
> mobiveil_pcie *pcie)
> > return -ETIMEDOUT;
> > }
> >
> > +static void mobiveil_pcie_disable_ib_win(struct mobiveil_pcie *pcie,
> > +int idx) {
> > + u32 val;
> > +
> > + val = csr_readl(pcie, PAB_PEX_AMAP_CTRL(idx));
> > + val &= ~(1 << AMAP_CTRL_EN_SHIFT);
> > + csr_writel(pcie, val, PAB_PEX_AMAP_CTRL(idx)); }
> > +
> > +static void mobiveil_pcie_disable_ob_win(struct mobiveil_pcie *pcie,
> > +int idx) {
> > + u32 val;
> > +
> > + val = csr_readl(pcie, PAB_AXI_AMAP_CTRL(idx));
> > + val &= ~(1 << WIN_ENABLE_SHIFT);
> > + csr_writel(pcie, val, PAB_AXI_AMAP_CTRL(idx)); }
> > +
> > static void mobiveil_pcie_enable_msi(struct mobiveil_pcie *pcie) {
> > phys_addr_t msg_addr = pcie->pcie_reg_base; @@ -585,6 +603,13 @@
> > static int mobiveil_host_init(struct mobiveil_pcie *pcie) {
> > u32 value, pab_ctrl, type;
> > struct resource_entry *win;
> > + int i;
> > +
> > + /* Disable all inbound/outbound windows */
> > + for (i = 0; i < pcie->apio_wins; i++)
> > + mobiveil_pcie_disable_ob_win(pcie, i);
> > + for (i = 0; i < pcie->ppio_wins; i++)
> > + mobiveil_pcie_disable_ib_win(pcie, i);
> >
> > /* setup bus numbers */
> > value = csr_readl(pcie, PCI_PRIMARY_BUS);
> > --
> > 2.17.1
> >
RE: [PATCHv5 17/20] PCI: mobiveil: Complete initialization of host even if no PCIe link
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月12日 22:35
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 17/20] PCI: mobiveil: Complete initialization of host
> even if no PCIe link
>
> On Fri, Apr 12, 2019 at 08:36:54AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Sometimes there is not a PCIe Endpoint stalled in the slot, so do not
> > exit when the PCIe link is not up. And degrade the print level of link
> > up info.
>
> So what's the point of probing if the link does not initialize ?
A simple case is plug in a PCIe device after the Linux boot up, then rescan the
device.
If exit when PCIe link is not up, the PCIe controller is not initialized
completely, the
rescan cannot work.
Thanks,
Zhiqiang
> Lorenzo
>
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 6 ++
> > 1 file changed, 2 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 1ee3ea2570c0..8dc87c7a600e 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -560,7 +560,7 @@ static int mobiveil_bringup_link(struct
> mobiveil_pcie *pcie)
> > usleep_range(LINK_WAIT_MIN, LINK_WAIT_MAX);
> > }
> >
> > - dev_err(>pdev->dev, "link never came up\n");
> > + dev_info(>pdev->dev, "link never came up\n");
> >
> > return -ETIMEDOUT;
> > }
> > @@ -926,10 +926,8 @@ static int mobiveil_pcie_probe(struct
> platform_device *pdev)
> > bridge->swizzle_irq = pci_common_swizzle;
> >
> > ret = mobiveil_bringup_link(pcie);
> > - if (ret) {
> > + if (ret)
> > dev_info(dev, "link bring-up failed\n");
> > - goto error;
> > - }
> >
> > /* setup the kernel resources for the newly added PCIe root bus */
> > ret = pci_scan_root_bus_bridge(bridge);
> > --
> > 2.17.1
> >
RE: [PATCHv5 04/20] PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月12日 21:08
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> MSI_FLAG_MULTI_PCI_MSI
>
> On Wed, Jun 12, 2019 at 11:34:51AM +, Z.q. Hou wrote:
> > Hi Lorenzo,
> >
> > Thanks a lot for your comments!
> >
> > > -Original Message-----
> > > From: Lorenzo Pieralisi
> > > Sent: 2019年6月12日 1:00
> > > To: Z.q. Hou
> > > Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> > > l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> > > ; catalin.mari...@arm.com;
> will.dea...@arm.com;
> > > Mingkai Hu ; M.h. Lian
> ;
> > > Xiaowei Bao
> > > Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> > > MSI_FLAG_MULTI_PCI_MSI
> > >
> > > On Fri, Apr 12, 2019 at 08:35:36AM +, Z.q. Hou wrote:
> > > > From: Hou Zhiqiang
> > > >
> > > > The current code does not support multiple MSIs, so remove the
> > > > corresponding flag from the msi_domain_info structure.
> > >
> > > Please explain me what's the problem before removing multi MSI support.
> >
> > NXP LX2 PCIe use the GIC-ITS instead of Mobiveil IP internal MSI
> > controller, so, I didn't encounter problem.
>
> Well, you sent a patch to fix an issue, explain me the issue you are fixing
> then,
> aka what have you sent this patch for ?
I did not face issue, as I have explained NXP does not use the Mobiveil IP's
MSI controller.
But obviously the MSI allocate function does not support multiple MSI, so I
submitted this patch.
Thanks,
Zhiqiang
>
> Lorenzo
>
> > Subbu, did you test with Endpoint supporting multi MSI?
> >
> > Thanks,
> > Zhiqiang
> >
> > >
> > > Thanks,
> > > Lorenzo
> > >
> > > > Fixes: 1e913e58335f ("PCI: mobiveil: Add MSI support")
> > > > Signed-off-by: Hou Zhiqiang
> > > > Reviewed-by: Minghuan Lian
> > > > ---
> > > > V5:
> > > > - Corrected the subject.
> > > >
> > > > drivers/pci/controller/pcie-mobiveil.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > > > b/drivers/pci/controller/pcie-mobiveil.c
> > > > index 563210e731d3..a0dd337c6214 100644
> > > > --- a/drivers/pci/controller/pcie-mobiveil.c
> > > > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > > > @@ -703,7 +703,7 @@ static struct irq_chip mobiveil_msi_irq_chip =
> > > > {
> > > >
> > > > static struct msi_domain_info mobiveil_msi_domain_info = {
> > > > .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> > > MSI_FLAG_USE_DEF_CHIP_OPS |
> > > > - MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
> > > > + MSI_FLAG_PCI_MSIX),
> > > > .chip = _msi_irq_chip,
> > > > };
> > > >
> > > > --
> > > > 2.17.1
> > > >
RE: [PATCHv5 19/20] PCI: mobiveil: Add 8-bit and 16-bit register accessors
Hi Lorenzo,
> -Original Message-
> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
> Sent: 2019年6月12日 21:54
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 19/20] PCI: mobiveil: Add 8-bit and 16-bit register
> accessors
>
> On Fri, Apr 12, 2019 at 08:37:05AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > There are some 8-bit and 16-bit registers in PCIe configuration space,
> > so add accessors for them.
> >
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > Reviewed-by: Subrahmanya Lingappa
> > ---
> > V5:
> > - Corrected and retouched the subject and changelog.
> > - No functionality change.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 20
> > 1 file changed, 20 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 411e9779da12..456adfee393c 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -268,11 +268,31 @@ static u32 csr_readl(struct mobiveil_pcie *pcie,
> u32 off)
> > return csr_read(pcie, off, 0x4);
> > }
> >
> > +static u32 csr_readw(struct mobiveil_pcie *pcie, u32 off) {
> > + return csr_read(pcie, off, 0x2);
> > +}
> > +
> > +static u32 csr_readb(struct mobiveil_pcie *pcie, u32 off) {
> > + return csr_read(pcie, off, 0x1);
> > +}
> > +
> > static void csr_writel(struct mobiveil_pcie *pcie, u32 val, u32 off)
> > {
> > csr_write(pcie, val, off, 0x4);
> > }
> >
> > +static void csr_writew(struct mobiveil_pcie *pcie, u32 val, u32 off)
> > +{
> > + csr_write(pcie, val, off, 0x2);
> > +}
> > +
> > +static void csr_writeb(struct mobiveil_pcie *pcie, u32 val, u32 off)
> > +{
> > + csr_write(pcie, val, off, 0x1);
> > +}
> > +
>
> They are not used so you should drop this patch.
NXP Layerscape PCIe Gen4 controller driver will use them, so don't drop it.
Thanks,
Zhiqiang
>
> Lorenzo
>
> > static bool mobiveil_pcie_link_up(struct mobiveil_pcie *pcie) {
> > return (csr_readl(pcie, LTSSM_STATUS) &
> > --
> > 2.17.1
> >
RE: [PATCHv5 16/20] PCI: mobiveil: Add link up condition check
Hi Lorenzo,
Thanks a lot for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月12日 1:18
> To: Z.q. Hou ; bhelg...@google.com
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> robh...@kernel.org; mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> catalin.mari...@arm.com; will.dea...@arm.com; Mingkai Hu
> ; M.h. Lian ; Xiaowei Bao
>
> Subject: Re: [PATCHv5 16/20] PCI: mobiveil: Add link up condition check
>
> NB: Please trim the CC list and keep it to concerned maintainers.
>
> On Fri, Apr 12, 2019 at 08:36:48AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > Avoid to issue CFG transactions to link partner when the PCIe link is
> > not up.
> >
> > Signed-off-by: Hou Zhiqiang
> > ---
> > V5:
> > - Corrected the subject.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 621852078caf..1ee3ea2570c0 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -283,6 +283,10 @@ static bool mobiveil_pcie_valid_device(struct
> > pci_bus *bus, unsigned int devfn) {
> > struct mobiveil_pcie *pcie = bus->sysdata;
> >
> > + /* If there is no link, then there is no device */
> > + if (bus->number > pcie->root_bus_nr && !mobiveil_pcie_link_up(pcie))
>
> I think Bjorn mentioned this a million times already, eg:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flinux-pci%2F20190411201535.GS256045%40google.com%2F
> p;data=02%7C01%7Czhiqiang.hou%40nxp.com%7Cffb4c8dcebe4493a375908
> d6ee90b471%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63695
> 8702637973543sdata=m%2FqV5zohqyBMUDT7zrVjF%2FLtYeJZO36rdY
> eMTPGGbHg%3Dreserved=0
>
> this is racy and gives a false sense of robustness. We have code in the kernel
> that checks the link but adding more seems silly to me, so I am inclined to
> drop this patch.
>
Understand, drop it.
Thanks,
Zhiqiang
> Lorenzo
>
> > + return false;
> > +
> > /* Only one device down on each root port */
> > if ((bus->number == pcie->root_bus_nr) && (devfn > 0))
> > return false;
> > --
> > 2.17.1
> >
RE: [PATCHv5 04/20] PCI: mobiveil: Remove the flag MSI_FLAG_MULTI_PCI_MSI
Hi Lorenzo,
Thanks a lot for your comments!
> -Original Message-
> From: Lorenzo Pieralisi
> Sent: 2019年6月12日 1:00
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; mark.rutl...@arm.com;
> l.subrahma...@mobiveil.co.in; shawn...@kernel.org; Leo Li
> ; catalin.mari...@arm.com; will.dea...@arm.com;
> Mingkai Hu ; M.h. Lian ;
> Xiaowei Bao
> Subject: Re: [PATCHv5 04/20] PCI: mobiveil: Remove the flag
> MSI_FLAG_MULTI_PCI_MSI
>
> On Fri, Apr 12, 2019 at 08:35:36AM +, Z.q. Hou wrote:
> > From: Hou Zhiqiang
> >
> > The current code does not support multiple MSIs, so remove the
> > corresponding flag from the msi_domain_info structure.
>
> Please explain me what's the problem before removing multi MSI support.
NXP LX2 PCIe use the GIC-ITS instead of Mobiveil IP internal MSI controller,
so, I didn't encounter problem.
Subbu, did you test with Endpoint supporting multi MSI?
Thanks,
Zhiqiang
>
> Thanks,
> Lorenzo
>
> > Fixes: 1e913e58335f ("PCI: mobiveil: Add MSI support")
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > ---
> > V5:
> > - Corrected the subject.
> >
> > drivers/pci/controller/pcie-mobiveil.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/pcie-mobiveil.c
> > b/drivers/pci/controller/pcie-mobiveil.c
> > index 563210e731d3..a0dd337c6214 100644
> > --- a/drivers/pci/controller/pcie-mobiveil.c
> > +++ b/drivers/pci/controller/pcie-mobiveil.c
> > @@ -703,7 +703,7 @@ static struct irq_chip mobiveil_msi_irq_chip = {
> >
> > static struct msi_domain_info mobiveil_msi_domain_info = {
> > .flags = (MSI_FLAG_USE_DEF_DOM_OPS |
> MSI_FLAG_USE_DEF_CHIP_OPS |
> > - MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
> > + MSI_FLAG_PCI_MSIX),
> > .chip = _msi_irq_chip,
> > };
> >
> > --
> > 2.17.1
> >
RE: [PATCHv6 5/6] arm64: dts: lx2160a: Add PCIe controller DT nodes
Hi Karthikeyan,
Thanks a lot for your comments!
> -Original Message-
> From: Karthikeyan Mitran [mailto:m.karthike...@mobiveil.co.in]
> Sent: 2019年6月3日 13:13
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; robh...@kernel.org; a...@arndb.de;
> mark.rutl...@arm.com; l.subrahma...@mobiveil.co.in;
> shawn...@kernel.org; Leo Li ;
> lorenzo.pieral...@arm.com; catalin.mari...@arm.com;
> will.dea...@arm.com; Mingkai Hu ; M.h. Lian
> ; Xiaowei Bao
> Subject: Re: [PATCHv6 5/6] arm64: dts: lx2160a: Add PCIe controller DT nodes
>
> Hi Hou Zhiqiang
>Two instances [@360 and @380] of the six has a different
> window count, the RC can not have more than 8 windows.
> apio-wins = <256>; //Can we change it to 8
> ppio-wins = <24>;//Can we change it to 8
>
I checked with hardware team, the PCIe controllers @360 and @380 support
up to x8 and SRIOV, these 2 controllers have different number of inbound and
outbound
windows from the other 4 PCIe controllers which are support up to x4 and not
support
SRIOV.
> On Tue, May 28, 2019 at 12:20 PM Z.q. Hou wrote:
> >
> > From: Hou Zhiqiang
> >
> > The LX2160A integrated 6 PCIe Gen4 controllers.
> >
> > Signed-off-by: Hou Zhiqiang
> > Reviewed-by: Minghuan Lian
> > ---
> > V6:
> > - No change.
> >
> > .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 163
> > ++
> > 1 file changed, 163 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > index 125a8cc2c5b3..7a2b91ff1fbc 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > @@ -964,5 +964,168 @@
> > };
> > };
> > };
> > +
> > + pcie@340 {
> > + compatible = "fsl,lx2160a-pcie";
> > + reg = <0x00 0x0340 0x0 0x0010
> /* controller registers */
> > + 0x80 0x 0x0 0x1000>;
> /* configuration space */
> > + reg-names = "csr_axi_slave",
> "config_axi_slave";
> > + interrupts = IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
> > + IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
> > + IRQ_TYPE_LEVEL_HIGH>; /* controller interrupt */
> > + interrupt-names = "aer", "pme", "intr";
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + device_type = "pci";
> > + dma-coherent;
> > + apio-wins = <8>;
> > + ppio-wins = <8>;
> > + bus-range = <0x0 0xff>;
> > + ranges = <0x8200 0x0 0x4000 0x80
> 0x4000 0x0 0x4000>; /* non-prefetchable memory */
> > + msi-parent = <>;
> > + #interrupt-cells = <1>;
> > + interrupt-map-mask = <0 0 0 7>;
> > + interrupt-map = < 0 0 1 0 0 GIC_SPI
> 109 IRQ_TYPE_LEVEL_HIGH>,
> > + < 0 0 2 0 0
> GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>,
> > + < 0 0 3 0 0
> GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>,
> > + < 0 0 4 0 0
> GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
> > + status = "disabled";
> > + };
> > +
> > + pcie@350 {
> > + compatible = "fsl,lx2160a-pcie";
> > + reg = <0x00 0x0350 0x0 0x0010
> /* controller registers */
> > + 0x88 0x 0x0 0x1000>;
> /* configuration space */
> > + reg-names = "csr_axi_slave",
> "config_axi_slave";
> > + interrupts = IRQ_TYPE_LEVEL_HIGH>, /* AER interrupt */
> > + IRQ_TYPE_LEVEL_HIGH>, /* PME interrupt */
> > + IRQ_TYPE_LEVEL_HIGH>; /* controll
[PATCHv6 5/6] arm64: dts: lx2160a: Add PCIe controller DT nodes
From: Hou Zhiqiang
The LX2160A integrated 6 PCIe Gen4 controllers.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
---
V6:
- No change.
.../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 163 ++
1 file changed, 163 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 125a8cc2c5b3..7a2b91ff1fbc 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -964,5 +964,168 @@
};
};
};
+
+ pcie@340 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010 /* controller
registers */
+ 0x80 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x80 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 109
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 110
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 111
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 112
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@350 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0350 0x0 0x0010 /* controller
registers */
+ 0x88 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <8>;
+ ppio-wins = <8>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x88 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = < 0 0 1 0 0 GIC_SPI 114
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 2 0 0 GIC_SPI 115
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 3 0 0 GIC_SPI 116
IRQ_TYPE_LEVEL_HIGH>,
+ < 0 0 4 0 0 GIC_SPI 117
IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ };
+
+ pcie@360 {
+ compatible = "fsl,lx2160a-pcie";
+ reg = <0x00 0x0360 0x0 0x0010 /* controller
registers */
+ 0x90 0x 0x0 0x1000>; /*
configuration space */
+ reg-names = "csr_axi_slave", "config_axi_slave";
+ interrupts = , /* AER
interrupt */
+, /* PME
interrupt */
+; /*
controller interrupt */
+ interrupt-names = "aer", "pme", "intr";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ dma-coherent;
+ apio-wins = <256>;
+ ppio-wins = <24>;
+ bus-range = <0x0 0xff>;
+ ranges = <0x8200 0x0 0x4000 0x90 0x4000 0x0
0x4000>; /* non-prefetchable memory */
+ msi-parent = <>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+
[PATCHv6 4/6] PCI: mobiveil: Add PCIe Gen4 RC driver for NXP Layerscape SoCs
From: Hou Zhiqiang
This PCIe controller is based on the Mobiveil GPEX IP, which is
compatible with the PCI Express™ Base Specification, Revision 4.0.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
---
V6:
- Change the file name pci-layerscape-gen4.c to pcie-layerscape-gen4.c.
- Change the macro name to PCIE_LAYERSCAPE_GEN4.
- Change the L0 state macro name to PF_DBG_LTSSM_L0.
- Romve the punctuation at end of error messages.
- Move the allocation of host bridge structure here and squash the
allocations.
drivers/pci/controller/mobiveil/Kconfig | 10 +
drivers/pci/controller/mobiveil/Makefile | 1 +
.../mobiveil/pcie-layerscape-gen4.c | 255 ++
.../pci/controller/mobiveil/pcie-mobiveil.h | 16 +-
4 files changed, 280 insertions(+), 2 deletions(-)
create mode 100644 drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
diff --git a/drivers/pci/controller/mobiveil/Kconfig
b/drivers/pci/controller/mobiveil/Kconfig
index 64343c07bfed..c823be8dab1c 100644
--- a/drivers/pci/controller/mobiveil/Kconfig
+++ b/drivers/pci/controller/mobiveil/Kconfig
@@ -21,4 +21,14 @@ config PCIE_MOBIVEIL_PLAT
Soft IP. It has up to 8 outbound and inbound windows
for address translation and it is a PCIe Gen4 IP.
+config PCIE_LAYERSCAPE_GEN4
+ bool "Freescale Layerscape PCIe Gen4 controller"
+ depends on PCI
+ depends on OF && (ARM64 || ARCH_LAYERSCAPE)
+ depends on PCI_MSI_IRQ_DOMAIN
+ select PCIE_MOBIVEIL_HOST
+ help
+ Say Y here if you want PCIe Gen4 controller support on
+ Layerscape SoCs. The PCIe controller can work in RC or
+ EP mode according to RCW[HOST_AGT_PEX] setting.
endmenu
diff --git a/drivers/pci/controller/mobiveil/Makefile
b/drivers/pci/controller/mobiveil/Makefile
index 9fb6d1c6504d..99d879de32d6 100644
--- a/drivers/pci/controller/mobiveil/Makefile
+++ b/drivers/pci/controller/mobiveil/Makefile
@@ -2,3 +2,4 @@
obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_MOBIVEIL_HOST) += pcie-mobiveil-host.o
obj-$(CONFIG_PCIE_MOBIVEIL_PLAT) += pcie-mobiveil-plat.o
+obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie-layerscape-gen4.o
diff --git a/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
new file mode 100644
index ..51543555c75d
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/pcie-layerscape-gen4.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe Gen4 host controller driver for NXP Layerscape SoCs
+ *
+ * Copyright 2019 NXP
+ *
+ * Author: Zhiqiang Hou
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-mobiveil.h"
+
+/* LUT and PF control registers */
+#define PCIE_LUT_OFF 0x8
+#define PCIE_PF_OFF0xc
+#define PCIE_PF_INT_STAT 0x18
+#define PF_INT_STAT_PABRST BIT(31)
+
+#define PCIE_PF_DBG0x7fc
+#define PF_DBG_LTSSM_MASK 0x3f
+#define PF_DBG_LTSSM_L00x2d /* L0 state */
+#define PF_DBG_WE BIT(31)
+#define PF_DBG_PABRBIT(27)
+
+#define to_ls_pcie_g4(x) platform_get_drvdata((x)->pdev)
+
+struct ls_pcie_g4 {
+ struct mobiveil_pcie pci;
+ struct delayed_work dwork;
+ int irq;
+};
+
+static inline u32 ls_pcie_g4_lut_readl(struct ls_pcie_g4 *pcie, u32 off)
+{
+ return ioread32(pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
+}
+
+static inline void ls_pcie_g4_lut_writel(struct ls_pcie_g4 *pcie,
+u32 off, u32 val)
+{
+ iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_LUT_OFF + off);
+}
+
+static inline u32 ls_pcie_g4_pf_readl(struct ls_pcie_g4 *pcie, u32 off)
+{
+ return ioread32(pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
+}
+
+static inline void ls_pcie_g4_pf_writel(struct ls_pcie_g4 *pcie,
+ u32 off, u32 val)
+{
+ iowrite32(val, pcie->pci.csr_axi_slave_base + PCIE_PF_OFF + off);
+}
+
+static bool ls_pcie_g4_is_bridge(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = >pci;
+ u32 header_type;
+
+ header_type = csr_readb(mv_pci, PCI_HEADER_TYPE);
+ header_type &= 0x7f;
+
+ return header_type == PCI_HEADER_TYPE_BRIDGE;
+}
+
+static int ls_pcie_g4_link_up(struct mobiveil_pcie *pci)
+{
+ struct ls_pcie_g4 *pcie = to_ls_pcie_g4(pci);
+ u32 state;
+
+ state = ls_pcie_g4_pf_readl(pcie, PCIE_PF_DBG);
+ state = state & PF_DBG_LTSSM_MASK;
+
+ if (state == PF_DBG_LTSSM_L0)
+ return 1;
+
+ return 0;
+}
+
+static void ls_pcie_g4_reinit_hw(struct ls_pcie_g4 *pcie)
+{
+ struct mobiveil_pcie *mv_pci = >pci;
+ struct device *dev = _pci->pdev->dev;
+ u32 val,
[PATCHv6 6/6] arm64: defconfig: Enable CONFIG_PCIE_LAYERSCAPE_GEN4
From: Hou Zhiqiang Enable the PCIe Gen4 controller driver for Layerscape SoCs. Signed-off-by: Hou Zhiqiang Reviewed-by: Minghuan Lian --- V6: - Change the macro name to CONFIG_PCIE_LAYERSCAPE_GEN4. arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index e1a84db2bd7b..6821452a15f9 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -191,6 +191,7 @@ CONFIG_PCI_HOST_THUNDER_PEM=y CONFIG_PCI_HOST_THUNDER_ECAM=y CONFIG_PCIE_ROCKCHIP_HOST=m CONFIG_PCI_LAYERSCAPE=y +CONFIG_PCIE_LAYERSCAPE_GEN4=y CONFIG_PCI_HISI=y CONFIG_PCIE_QCOM=y CONFIG_PCIE_ARMADA_8K=y -- 2.17.1
[PATCHv6 1/6] PCI: mobiveil: Refactor Mobiveil PCIe Host Bridge IP driver
From: Hou Zhiqiang
Refactor the Mobiveil PCIe Host Bridge IP driver to make
it easier to add support for both RC and EP mode driver.
This patch moved the Mobiveil driver to an new directory
'drivers/pci/controller/mobiveil' and refactor it according
to the RC and EP abstraction.
Signed-off-by: Hou Zhiqiang
Reviewed-by: Minghuan Lian
Reviewed-by: Subrahmanya Lingappa
---
V6:
- Move the allocation of host birdge structure to main driver,
and squash the allocation of private structure into the host
bridge structure allocation.
MAINTAINERS | 2 +-
drivers/pci/controller/Kconfig| 11 +-
drivers/pci/controller/Makefile | 2 +-
drivers/pci/controller/mobiveil/Kconfig | 24 +
drivers/pci/controller/mobiveil/Makefile | 4 +
.../pcie-mobiveil-host.c} | 569 +++---
.../controller/mobiveil/pcie-mobiveil-plat.c | 59 ++
.../pci/controller/mobiveil/pcie-mobiveil.c | 248
.../pci/controller/mobiveil/pcie-mobiveil.h | 212 +++
9 files changed, 637 insertions(+), 494 deletions(-)
create mode 100644 drivers/pci/controller/mobiveil/Kconfig
create mode 100644 drivers/pci/controller/mobiveil/Makefile
rename drivers/pci/controller/{pcie-mobiveil.c =>
mobiveil/pcie-mobiveil-host.c} (53%)
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil-plat.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.c
create mode 100644 drivers/pci/controller/mobiveil/pcie-mobiveil.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 992f1dd06318..c066128d69ec 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12063,7 +12063,7 @@ M: Hou Zhiqiang
L: linux-...@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/pci/mobiveil-pcie.txt
-F: drivers/pci/controller/pcie-mobiveil.c
+F: drivers/pci/controller/mobiveil/pcie-mobiveil*
PCI DRIVER FOR MVEBU (Marvell Armada 370 and Armada XP SOC support)
M: Thomas Petazzoni
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 011c57cae4b0..b4d1e211b6d1 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -241,16 +241,6 @@ config PCIE_MEDIATEK
Say Y here if you want to enable PCIe controller support on
MediaTek SoCs.
-config PCIE_MOBIVEIL
- bool "Mobiveil AXI PCIe controller"
- depends on ARCH_ZYNQMP || COMPILE_TEST
- depends on OF
- depends on PCI_MSI_IRQ_DOMAIN
- help
- Say Y here if you want to enable support for the Mobiveil AXI PCIe
- Soft IP. It has up to 8 outbound and inbound windows
- for address translation and it is a PCIe Gen4 IP.
-
config PCIE_TANGO_SMP8759
bool "Tango SMP8759 PCIe controller (DANGEROUS)"
depends on ARCH_TANGO && PCI_MSI && OF
@@ -282,4 +272,5 @@ config VMD
module will be called vmd.
source "drivers/pci/controller/dwc/Kconfig"
+source "drivers/pci/controller/mobiveil/Kconfig"
endmenu
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index d56a507495c5..b79a615041a0 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -26,11 +26,11 @@ obj-$(CONFIG_PCIE_ROCKCHIP) += pcie-rockchip.o
obj-$(CONFIG_PCIE_ROCKCHIP_EP) += pcie-rockchip-ep.o
obj-$(CONFIG_PCIE_ROCKCHIP_HOST) += pcie-rockchip-host.o
obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
-obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
+obj-y += mobiveil/
# The following drivers are for devices that use the generic ACPI
diff --git a/drivers/pci/controller/mobiveil/Kconfig
b/drivers/pci/controller/mobiveil/Kconfig
new file mode 100644
index ..64343c07bfed
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0
+
+menu "Mobiveil PCIe Core Support"
+ depends on PCI
+
+config PCIE_MOBIVEIL
+ bool
+
+config PCIE_MOBIVEIL_HOST
+bool
+ depends on PCI_MSI_IRQ_DOMAIN
+select PCIE_MOBIVEIL
+
+config PCIE_MOBIVEIL_PLAT
+ bool "Mobiveil AXI PCIe controller"
+ depends on ARCH_ZYNQMP || COMPILE_TEST
+ depends on OF
+ select PCIE_MOBIVEIL_HOST
+ help
+ Say Y here if you want to enable support for the Mobiveil AXI PCIe
+ Soft IP. It has up to 8 outbound and inbound windows
+ for address translation and it is a PCIe Gen4 IP.
+
+endmenu
diff --git a/drivers/pci/controller/mobiveil/Makefile
b/drivers/pci/controller/mobiveil/Makefile
new file mode 100644
index ..9fb6d1c6504d
--- /dev/null
+++ b/drivers/pci/controller/mobiveil/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
