diff mbox series

[v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y

Message ID 1544768762-18124-1-git-send-email-hongxing.zhu@nxp.com
State Superseded
Headers show
Series [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y | expand

Commit Message

Hongxing Zhu Dec. 14, 2018, 6:44 a.m. UTC 
Assertion of the MSI Enable bit of RC's MSI CAP is mandatory required to
trigger MSI on i.MX6 PCIe.
This bit would be asserted when CONFIG_PCIEPORTBUS=y.
Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".

Assert it unconditionally when MSI is enabled.
Otherwise, the MSI wouldn't be triggered although the EP is present and
the MSIs are assigned.

Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
---
Changes v1 -> v2:
* Assert the MSI_EN unconditionally when MSI is supported.
Changes v2 -> v3:
* Remove the IS_ENABLED(CONFIG_PCI_MSI) since the driver depends on
PCI_MSI_IRQ_DOMAIN
* Extended with a check for pci_msi_enabled() to see if the user
explicitly want legacy IRQs
Changes v3 -> v4:
* Refer to Bjorn's comments, refine the subject and commit log and change
the PCI_MSI_CAP to PCIE_RC_IMX6_MSI_CAP.
---
 drivers/pci/controller/dwc/pci-imx6.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

kernel test robot Dec. 18, 2018, 7:23 p.m. UTC | #1 
Hi Richard,

I love your patch! Yet something to improve:

[auto build test ERROR on pci/next]
[also build test ERROR on v4.20-rc7 next-20181218]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Richard-Zhu/PCI-imx-make-msi-work-without-CONFIG_PCIEPORTBUS-y/20181217-004814
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        GCC_VERSION=7.2.0 make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/pci/controller/dwc/pci-imx6.c: In function 'imx6_pcie_probe':
>> drivers/pci/controller/dwc/pci-imx6.c:1158:27: error: 'PCIE_RC_MSI_IMX6_CAP' undeclared (first use in this function); did you mean 'PCIE_RC_IMX6_MSI_CAP'?
      dw_pcie_writew_dbi(pci, PCIE_RC_MSI_IMX6_CAP +
                              ^~~~~~~~~~~~~~~~~~~~
                              PCIE_RC_IMX6_MSI_CAP
   drivers/pci/controller/dwc/pci-imx6.c:1158:27: note: each undeclared identifier is reported only once for each function it appears in

vim +1158 drivers/pci/controller/dwc/pci-imx6.c

   994	
   995	static int imx6_pcie_probe(struct platform_device *pdev)
   996	{
   997		struct device *dev = &pdev->dev;
   998		struct dw_pcie *pci;
   999		struct imx6_pcie *imx6_pcie;
  1000		struct resource *dbi_base;
  1001		struct device_node *node = dev->of_node;
  1002		int ret;
  1003		u16 val;
  1004	
  1005		imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
  1006		if (!imx6_pcie)
  1007			return -ENOMEM;
  1008	
  1009		pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
  1010		if (!pci)
  1011			return -ENOMEM;
  1012	
  1013		pci->dev = dev;
  1014		pci->ops = &dw_pcie_ops;
  1015	
  1016		imx6_pcie->pci = pci;
  1017		imx6_pcie->variant =
  1018			(enum imx6_pcie_variants)of_device_get_match_data(dev);
  1019	
  1020		if (of_property_read_u32(node, "fsl,controller-id",
  1021					 &imx6_pcie->controller_id))
  1022			imx6_pcie->controller_id = 0;
  1023	
  1024		dbi_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
  1025		pci->dbi_base = devm_ioremap_resource(dev, dbi_base);
  1026		if (IS_ERR(pci->dbi_base))
  1027			return PTR_ERR(pci->dbi_base);
  1028	
  1029		/* Fetch GPIOs */
  1030		imx6_pcie->reset_gpio = of_get_named_gpio(node, "reset-gpio", 0);
  1031		imx6_pcie->gpio_active_high = of_property_read_bool(node,
  1032							"reset-gpio-active-high");
  1033		if (gpio_is_valid(imx6_pcie->reset_gpio)) {
  1034			ret = devm_gpio_request_one(dev, imx6_pcie->reset_gpio,
  1035					imx6_pcie->gpio_active_high ?
  1036						GPIOF_OUT_INIT_HIGH :
  1037						GPIOF_OUT_INIT_LOW,
  1038					"PCIe reset");
  1039			if (ret) {
  1040				dev_err(dev, "unable to get reset gpio\n");
  1041				return ret;
  1042			}
  1043		} else if (imx6_pcie->reset_gpio == -EPROBE_DEFER) {
  1044			return imx6_pcie->reset_gpio;
  1045		}
  1046	
  1047		/* Fetch clocks */
  1048		imx6_pcie->pcie_phy = devm_clk_get(dev, "pcie_phy");
  1049		if (IS_ERR(imx6_pcie->pcie_phy)) {
  1050			dev_err(dev, "pcie_phy clock source missing or invalid\n");
  1051			return PTR_ERR(imx6_pcie->pcie_phy);
  1052		}
  1053	
  1054		imx6_pcie->pcie_bus = devm_clk_get(dev, "pcie_bus");
  1055		if (IS_ERR(imx6_pcie->pcie_bus)) {
  1056			dev_err(dev, "pcie_bus clock source missing or invalid\n");
  1057			return PTR_ERR(imx6_pcie->pcie_bus);
  1058		}
  1059	
  1060		imx6_pcie->pcie = devm_clk_get(dev, "pcie");
  1061		if (IS_ERR(imx6_pcie->pcie)) {
  1062			dev_err(dev, "pcie clock source missing or invalid\n");
  1063			return PTR_ERR(imx6_pcie->pcie);
  1064		}
  1065	
  1066		switch (imx6_pcie->variant) {
  1067		case IMX6SX:
  1068			imx6_pcie->pcie_inbound_axi = devm_clk_get(dev,
  1069								   "pcie_inbound_axi");
  1070			if (IS_ERR(imx6_pcie->pcie_inbound_axi)) {
  1071				dev_err(dev, "pcie_inbound_axi clock missing or invalid\n");
  1072				return PTR_ERR(imx6_pcie->pcie_inbound_axi);
  1073			}
  1074			break;
  1075		case IMX8MQ:
  1076		case IMX7D:		/* FALLTHROUGH */
  1077			imx6_pcie->pciephy_reset = devm_reset_control_get_exclusive(dev,
  1078										    "pciephy");
  1079			if (IS_ERR(imx6_pcie->pciephy_reset)) {
  1080				dev_err(dev, "Failed to get PCIEPHY reset control\n");
  1081				return PTR_ERR(imx6_pcie->pciephy_reset);
  1082			}
  1083	
  1084			imx6_pcie->apps_reset = devm_reset_control_get_exclusive(dev,
  1085										 "apps");
  1086			if (IS_ERR(imx6_pcie->apps_reset)) {
  1087				dev_err(dev, "Failed to get PCIE APPS reset control\n");
  1088				return PTR_ERR(imx6_pcie->apps_reset);
  1089			}
  1090			break;
  1091		default:
  1092			break;
  1093		}
  1094	
  1095		/* Grab turnoff reset */
  1096		imx6_pcie->turnoff_reset = devm_reset_control_get_optional_exclusive(dev, "turnoff");
  1097		if (IS_ERR(imx6_pcie->turnoff_reset)) {
  1098			dev_err(dev, "Failed to get TURNOFF reset control\n");
  1099			return PTR_ERR(imx6_pcie->turnoff_reset);
  1100		}
  1101	
  1102		/* Grab GPR config register range */
  1103		imx6_pcie->iomuxc_gpr =
  1104			 syscon_regmap_lookup_by_compatible("fsl,imx6q-iomuxc-gpr");
  1105		if (IS_ERR(imx6_pcie->iomuxc_gpr)) {
  1106			dev_err(dev, "unable to find iomuxc registers\n");
  1107			return PTR_ERR(imx6_pcie->iomuxc_gpr);
  1108		}
  1109	
  1110		/* Grab PCIe PHY Tx Settings */
  1111		if (of_property_read_u32(node, "fsl,tx-deemph-gen1",
  1112					 &imx6_pcie->tx_deemph_gen1))
  1113			imx6_pcie->tx_deemph_gen1 = 0;
  1114	
  1115		if (of_property_read_u32(node, "fsl,tx-deemph-gen2-3p5db",
  1116					 &imx6_pcie->tx_deemph_gen2_3p5db))
  1117			imx6_pcie->tx_deemph_gen2_3p5db = 0;
  1118	
  1119		if (of_property_read_u32(node, "fsl,tx-deemph-gen2-6db",
  1120					 &imx6_pcie->tx_deemph_gen2_6db))
  1121			imx6_pcie->tx_deemph_gen2_6db = 20;
  1122	
  1123		if (of_property_read_u32(node, "fsl,tx-swing-full",
  1124					 &imx6_pcie->tx_swing_full))
  1125			imx6_pcie->tx_swing_full = 127;
  1126	
  1127		if (of_property_read_u32(node, "fsl,tx-swing-low",
  1128					 &imx6_pcie->tx_swing_low))
  1129			imx6_pcie->tx_swing_low = 127;
  1130	
  1131		/* Limit link speed */
  1132		ret = of_property_read_u32(node, "fsl,max-link-speed",
  1133					   &imx6_pcie->link_gen);
  1134		if (ret)
  1135			imx6_pcie->link_gen = 1;
  1136	
  1137		imx6_pcie->vpcie = devm_regulator_get_optional(&pdev->dev, "vpcie");
  1138		if (IS_ERR(imx6_pcie->vpcie)) {
  1139			if (PTR_ERR(imx6_pcie->vpcie) == -EPROBE_DEFER)
  1140				return -EPROBE_DEFER;
  1141			imx6_pcie->vpcie = NULL;
  1142		}
  1143	
  1144		platform_set_drvdata(pdev, imx6_pcie);
  1145	
  1146		ret = imx6_pcie_attach_pd(dev);
  1147		if (ret)
  1148			return ret;
  1149	
  1150		ret = imx6_add_pcie_port(imx6_pcie, pdev);
  1151		if (ret < 0)
  1152			return ret;
  1153	
  1154		if (pci_msi_enabled()) {
  1155			val = dw_pcie_readw_dbi(pci, PCIE_RC_IMX6_MSI_CAP +
  1156					PCI_MSI_FLAGS);
  1157			val |= PCI_MSI_FLAGS_ENABLE;
> 1158			dw_pcie_writew_dbi(pci, PCIE_RC_MSI_IMX6_CAP +
  1159					PCI_MSI_FLAGS, val);
  1160		}
  1161	
  1162		return 0;
  1163	}
  1164	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
Bjorn Helgaas Dec. 19, 2018, 2:12 p.m. UTC | #2 
[+cc Sven, Trent, et al from related report:
https://lore.kernel.org/linux-pci/20181218210444.5950-1-TheSven73@googlemail.com]

On Fri, Dec 14, 2018 at 06:44:15AM +0000, Richard Zhu wrote:
> Assertion of the MSI Enable bit of RC's MSI CAP is mandatory required to
> trigger MSI on i.MX6 PCIe.
> This bit would be asserted when CONFIG_PCIEPORTBUS=y.
> Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".
> 
> Assert it unconditionally when MSI is enabled.
> Otherwise, the MSI wouldn't be triggered although the EP is present and
> the MSIs are assigned.

OK, I think I finally understand most of what's going on.  Please
check the following possible changelog text:

  The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
  controls whether a Function can request service using MSI.

  i.MX6 Root Ports implement the MSI Capability and may use MSI to
  request service for events like PME, hotplug, AER, etc.  In
  addition, on i.MX6, the MSI Enable bit controls delivery of MSI
  interrupts from components below the Root Port.

  Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
  CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically also
  enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root Ports,
  it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
  As a side effect, that also enabled delivery of MSI interrupts from
  downstream components.

  After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
  portdrv, but that means imx6q-pcie must set the MSI Enable bit
  itself if downstream components use MSI.

  Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS")

I still don't understand exactly *how* MSI Enable affects MSI from
downstream components, since the downstream component just does a DMA
write, and the Root Port can't tell whether the write is to memory or
interrupt controller unless the Root Port knows where the MSI targets
are, e.g., if the interrupt controller is actually part of the RC.

Bjorn

> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> Changes v1 -> v2:
> * Assert the MSI_EN unconditionally when MSI is supported.
> Changes v2 -> v3:
> * Remove the IS_ENABLED(CONFIG_PCI_MSI) since the driver depends on
> PCI_MSI_IRQ_DOMAIN
> * Extended with a check for pci_msi_enabled() to see if the user
> explicitly want legacy IRQs
> Changes v3 -> v4:
> * Refer to Bjorn's comments, refine the subject and commit log and change
> the PCI_MSI_CAP to PCIE_RC_IMX6_MSI_CAP.
> ---
>  drivers/pci/controller/dwc/pci-imx6.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 26087b3..639bb27 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -74,6 +74,7 @@ struct imx6_pcie {
>  #define PHY_PLL_LOCK_WAIT_USLEEP_MAX	200
>  
>  /* PCIe Root Complex registers (memory-mapped) */
> +#define PCIE_RC_IMX6_MSI_CAP			0x50
>  #define PCIE_RC_LCR				0x7c
>  #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1	0x1
>  #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2	0x2
> @@ -926,6 +927,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	struct resource *dbi_base;
>  	struct device_node *node = dev->of_node;
>  	int ret;
> +	u16 val;
>  
>  	imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
>  	if (!imx6_pcie)
> @@ -1071,6 +1073,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> +	if (pci_msi_enabled()) {
> +		val = dw_pcie_readw_dbi(pci, PCIE_RC_IMX6_MSI_CAP +
> +				PCI_MSI_FLAGS);
> +		val |= PCI_MSI_FLAGS_ENABLE;
> +		dw_pcie_writew_dbi(pci, PCIE_RC_MSI_IMX6_CAP +
> +				PCI_MSI_FLAGS, val);
> +	}
> +
>  	return 0;
>  }
>  
> -- 
> 2.7.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Lucas Stach Dec. 19, 2018, 3:52 p.m. UTC | #3 
Am Mittwoch, den 19.12.2018, 08:12 -0600 schrieb Bjorn Helgaas:
> [+cc Sven, Trent, et al from related report:
> https://lore.kernel.org/linux-pci/20181218210444.5950-1-TheSven73@googlemail.com]
> 
> On Fri, Dec 14, 2018 at 06:44:15AM +0000, Richard Zhu wrote:
> > Assertion of the MSI Enable bit of RC's MSI CAP is mandatory required to
> > trigger MSI on i.MX6 PCIe.
> > This bit would be asserted when CONFIG_PCIEPORTBUS=y.
> > Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".
> > 
> > Assert it unconditionally when MSI is enabled.
> > Otherwise, the MSI wouldn't be triggered although the EP is present and
> > the MSIs are assigned.
> 
> OK, I think I finally understand most of what's going on.  Please
> check the following possible changelog text:
> 
>   The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
>   controls whether a Function can request service using MSI.
> 
>   i.MX6 Root Ports implement the MSI Capability and may use MSI to
>   request service for events like PME, hotplug, AER, etc.  In
>   addition, on i.MX6, the MSI Enable bit controls delivery of MSI
>   interrupts from components below the Root Port.
> 
>   Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
>   CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically also
>   enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root Ports,
>   it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
>   As a side effect, that also enabled delivery of MSI interrupts from
>   downstream components.
> 
>   After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
>   portdrv, but that means imx6q-pcie must set the MSI Enable bit
>   itself if downstream components use MSI.
> 
>   Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS")
> 
> I still don't understand exactly *how* MSI Enable affects MSI from
> downstream components, since the downstream component just does a DMA
> write, and the Root Port can't tell whether the write is to memory or
> interrupt controller unless the Root Port knows where the MSI targets
> are, e.g., if the interrupt controller is actually part of the RC.

The controller terminating the MSI write is part of the DWC PCIe host
controller on i.MX6, which is questionable at least when you think
about how a MSI should be self-synchronizing to memory writes, but
that's reality...

As to why the controller needs the MSI Enable bit set, I have no idea.
But then the DWC controller is known to have some funky design
limitations regarding MSI, like not forwarding legacy PCI interrupts
anymore when MSI is enabled, so it's not totally surprising that we
need some quirky setup here.

Regards,
Lucas
Hongxing Zhu Dec. 20, 2018, 5:15 a.m. UTC | #4 
Hi Bjorn:

> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: 2018年12月19日 23:52
> To: Bjorn Helgaas <helgaas@kernel.org>; Richard Zhu
> <hongxing.zhu@nxp.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Andrew Smirnov
> <andrew.smirnov@gmail.com>; linux-pci@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Sven Van
> Asbroeck <thesven73@gmail.com>; Niklas Cassel <niklas.cassel@axis.com>;
> Kishon Vijay Abraham I <kishon@ti.com>; Gustavo Pimentel
> <gustavo.pimentel@synopsys.com>; Shawn Lin <shawn.lin@rock-chips.com>;
> Trent Piepho <tpiepho@impinj.com>
> Subject: Re: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
> 
> Am Mittwoch, den 19.12.2018, 08:12 -0600 schrieb Bjorn Helgaas:
> > [+cc Sven, Trent, et al from related report:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
> >
> e.kernel.org%2Flinux-pci%2F20181218210444.5950-1-TheSven73%40google
> mai
> >
> l.com&amp;data=02%7C01%7Chongxing.zhu%40nxp.com%7C05ba3b5bb42c
> 4db9bf3b
> >
> 08d665c9f17b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 808315347
> >
> 780466&amp;sdata=ta7ffj9EPGoqAjDiS1ORvR65A2IhMUpb2Endz9%2B6zM4
> %3D&amp;
> > reserved=0]
> >
> > On Fri, Dec 14, 2018 at 06:44:15AM +0000, Richard Zhu wrote:
> > > Assertion of the MSI Enable bit of RC's MSI CAP is mandatory
> > > required to trigger MSI on i.MX6 PCIe.
> > > This bit would be asserted when CONFIG_PCIEPORTBUS=y.
> > > Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".
> > >
> > > Assert it unconditionally when MSI is enabled.
> > > Otherwise, the MSI wouldn't be triggered although the EP is present
> > > and the MSIs are assigned.
> >
> > OK, I think I finally understand most of what's going on.  Please
> > check the following possible changelog text:
> >
> >   The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> >   controls whether a Function can request service using MSI.
> >
> >   i.MX6 Root Ports implement the MSI Capability and may use MSI to
> >   request service for events like PME, hotplug, AER, etc.  In
> >   addition, on i.MX6, the MSI Enable bit controls delivery of MSI
> >   interrupts from components below the Root Port.
> >
> >   Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> >   CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically
> also
> >   enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root
> Ports,
> >   it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
> >   As a side effect, that also enabled delivery of MSI interrupts from
> >   downstream components.
> >
> >   After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
> >   portdrv, but that means imx6q-pcie must set the MSI Enable bit
> >   itself if downstream components use MSI.
> >
> >   Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS")
> >
> > I still don't understand exactly *how* MSI Enable affects MSI from
> > downstream components, since the downstream component just does a
> DMA
> > write, and the Root Port can't tell whether the write is to memory or
> > interrupt controller unless the Root Port knows where the MSI targets
> > are, e.g., if the interrupt controller is actually part of the RC.
> 
[Richard Zhu] Thanks a lot for your kindly help to craft the commit log.
I'm totally fine with it.
Just like Lucas said below, the MSI trigger conditions are part of the glue logic
 When integrate this IP into iMX6 SOC. 
The MSI Enable bit set of RC is one of the mandatory required condition to
 trigger MSI from EP.

Best Regards
Richard Zhu

> The controller terminating the MSI write is part of the DWC PCIe host
> controller on i.MX6, which is questionable at least when you think about how
> a MSI should be self-synchronizing to memory writes, but that's reality...
> 
> As to why the controller needs the MSI Enable bit set, I have no idea.
> But then the DWC controller is known to have some funky design limitations
> regarding MSI, like not forwarding legacy PCI interrupts anymore when MSI is
> enabled, so it's not totally surprising that we need some quirky setup here.
> 
> Regards,
> Lucas
Hongxing Zhu Dec. 20, 2018, 5:52 a.m. UTC | #5 
Hi Bjorn:

> -----Original Message-----
> From: Lucas Stach [mailto:l.stach@pengutronix.de]
> Sent: 2018年12月19日 23:52
> To: Bjorn Helgaas <helgaas@kernel.org>; Richard Zhu
> <hongxing.zhu@nxp.com>
> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>; Andrew Smirnov
> <andrew.smirnov@gmail.com>; linux-pci@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; Sven Van
> Asbroeck <thesven73@gmail.com>; Niklas Cassel <niklas.cassel@axis.com>;
> Kishon Vijay Abraham I <kishon@ti.com>; Gustavo Pimentel
> <gustavo.pimentel@synopsys.com>; Shawn Lin <shawn.lin@rock-chips.com>;
> Trent Piepho <tpiepho@impinj.com>
> Subject: Re: [v4] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y
> 
> Am Mittwoch, den 19.12.2018, 08:12 -0600 schrieb Bjorn Helgaas:
> > [+cc Sven, Trent, et al from related report:
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flor
> >
> e.kernel.org%2Flinux-pci%2F20181218210444.5950-1-TheSven73%40google
> mai
> >
> l.com&amp;data=02%7C01%7Chongxing.zhu%40nxp.com%7C05ba3b5bb42c
> 4db9bf3b
> >
> 08d665c9f17b%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636
> 808315347
> >
> 780466&amp;sdata=ta7ffj9EPGoqAjDiS1ORvR65A2IhMUpb2Endz9%2B6zM4
> %3D&amp;
> > reserved=0]
> >
> > On Fri, Dec 14, 2018 at 06:44:15AM +0000, Richard Zhu wrote:
> > > Assertion of the MSI Enable bit of RC's MSI CAP is mandatory
> > > required to trigger MSI on i.MX6 PCIe.
> > > This bit would be asserted when CONFIG_PCIEPORTBUS=y.
> > > Thus, the MSI works fine on i.MX6 PCIe before the commit "f3fdfc4".
> > >
> > > Assert it unconditionally when MSI is enabled.
> > > Otherwise, the MSI wouldn't be triggered although the EP is present
> > > and the MSIs are assigned.
> >
> > OK, I think I finally understand most of what's going on.  Please
> > check the following possible changelog text:
> >
> >   The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
> >   controls whether a Function can request service using MSI.
> >
> >   i.MX6 Root Ports implement the MSI Capability and may use MSI to
> >   request service for events like PME, hotplug, AER, etc.  In
> >   addition, on i.MX6, the MSI Enable bit controls delivery of MSI
> >   interrupts from components below the Root Port.
> >
> >   Prior to f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> >   CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically
> also
> >   enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root
> Ports,
> >   it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
> >   As a side effect, that also enabled delivery of MSI interrupts from
> >   downstream components.
> >
> >   After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
> >   portdrv, but that means imx6q-pcie must set the MSI Enable bit
> >   itself if downstream components use MSI.
> >
> >   Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of
> > CONFIG_PCIEPORTBUS")
> >
> > I still don't understand exactly *how* MSI Enable affects MSI from
> > downstream components, since the downstream component just does a
> DMA
> > write, and the Root Port can't tell whether the write is to memory or
> > interrupt controller unless the Root Port knows where the MSI targets
> > are, e.g., if the interrupt controller is actually part of the RC.
>
[Richard Zhu] Thanks a lot for your kindly help to craft the commit log.
I'm totally fine with it.
Just like Lucas said below, the MSI trigger conditions are part of the glue logic
When integrate this IP into iMX6 SOC. 
The MSI Enable bit set of RC is one of the mandatory required condition to
trigger MSI from EP.

Best Regards
Richard Zhu
 
> The controller terminating the MSI write is part of the DWC PCIe host
> controller on i.MX6, which is questionable at least when you think about how
> a MSI should be self-synchronizing to memory writes, but that's reality...
> 
> As to why the controller needs the MSI Enable bit set, I have no idea.
> But then the DWC controller is known to have some funky design limitations
> regarding MSI, like not forwarding legacy PCI interrupts anymore when MSI is
> enabled, so it's not totally surprising that we need some quirky setup here.
> 
> Regards,
> Lucas
diff mbox series

Patch

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 26087b3..639bb27 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -74,6 +74,7 @@  struct imx6_pcie {
 #define PHY_PLL_LOCK_WAIT_USLEEP_MAX	200
 
 /* PCIe Root Complex registers (memory-mapped) */
+#define PCIE_RC_IMX6_MSI_CAP			0x50
 #define PCIE_RC_LCR				0x7c
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1	0x1
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2	0x2
@@ -926,6 +927,7 @@  static int imx6_pcie_probe(struct platform_device *pdev)
 	struct resource *dbi_base;
 	struct device_node *node = dev->of_node;
 	int ret;
+	u16 val;
 
 	imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
 	if (!imx6_pcie)
@@ -1071,6 +1073,14 @@  static int imx6_pcie_probe(struct platform_device *pdev)
 	if (ret < 0)
 		return ret;
 
+	if (pci_msi_enabled()) {
+		val = dw_pcie_readw_dbi(pci, PCIE_RC_IMX6_MSI_CAP +
+				PCI_MSI_FLAGS);
+		val |= PCI_MSI_FLAGS_ENABLE;
+		dw_pcie_writew_dbi(pci, PCIE_RC_MSI_IMX6_CAP +
+				PCI_MSI_FLAGS, val);
+	}
+
 	return 0;
 }