[PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Leonard Crestez]

Changes since v2:
 * Print with dev_info if link fails on resume (Lucas)
 * Add a comment on imx7d pci irq mappings (Andrey)
 * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)

The ltssm_disable does not return an error because it can't be usefully
handled, reversing partial suspend is a nightmare and unlikely to work.

 * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)

Series is against linux-next tag next-20180724 where the reset patch was
already accepted. The imx7d.dtsi patch is also useful standalone.

Link to v2: https://lkml.org/lkml/2018/7/20/472

Leonard Crestez (2):
  Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"
  PCI: imx: Initial imx7d pm support

 arch/arm/boot/dts/imx7d.dtsi          | 12 ++--
 drivers/pci/controller/dwc/pci-imx6.c | 97 +++++++++++++++++++++++++--
 2 files changed, 100 insertions(+), 9 deletions(-)

-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 1/2] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"

[Leonard Crestez]

This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.

That commit followed the reference manual but unfortunately the imx7d
manual is incorrect.

Tested with ath9k pcie card and confirmed internally.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm/boot/dts/imx7d.dtsi | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 7cbc2ffa4b3a..7234e8330a57 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -124,14 +124,18 @@
 		num-lanes = <1>;
 		interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
 		interrupt-names = "msi";
 		#interrupt-cells = <1>;
 		interrupt-map-mask = <0 0 0 0x7>;
-		interrupt-map = <0 0 0 1 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 0 2 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 0 3 &intc GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
-				<0 0 0 4 &intc GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>;
+		/*
+		 * Reference manual lists pci irqs incorrectly
+		 * Real hardware ordering is same as imx6: D+MSI, C, B, A
+		 */
+		interrupt-map = <0 0 0 1 &intc GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 0 2 &intc GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 0 3 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+				<0 0 0 4 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>;
 		clocks = <&clks IMX7D_PCIE_CTRL_ROOT_CLK>,
 			 <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>,
 			 <&clks IMX7D_PCIE_PHY_ROOT_CLK>;
 		clock-names = "pcie", "pcie_bus", "pcie_phy";
 		assigned-clocks = <&clks IMX7D_PCIE_CTRL_ROOT_SRC>,
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 2/2] PCI: imx: Initial imx7d pm support

[Leonard Crestez]

On imx7d the pcie-phy power domain is turned off in suspend and this can
make the system hang after resume when attempting any read from PCI.

Fix this by adding minimal suspend/resume code from the nxp internal
tree. This will prepare for powering down on suspend and reset the block
on resume.

Code is only for imx7d but a very similar sequence can be used for
other socs.

The original author is mostly Richard Zhu <hongxing.zhu@nxp.com>, this
patch adjusts the code to the upstream imx7d implemention using reset
controls and power domains.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/pci/controller/dwc/pci-imx6.c | 97 +++++++++++++++++++++++++--
 1 file changed, 92 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 4a9a673b4777..65b6d1015723 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -540,10 +540,28 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
 
 	dev_err(dev, "Speed change timeout\n");
 	return -EINVAL;
 }
 
+static void imx6_pcie_ltssm_enable(struct device *dev)
+{
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+
+	switch (imx6_pcie->variant) {
+	case IMX6Q:
+	case IMX6SX:
+	case IMX6QP:
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX6Q_GPR12_PCIE_CTL_2,
+				   IMX6Q_GPR12_PCIE_CTL_2);
+		break;
+	case IMX7D:
+		reset_control_deassert(imx6_pcie->apps_reset);
+		break;
+	}
+}
+
 static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
 {
 	struct dw_pcie *pci = imx6_pcie->pci;
 	struct device *dev = pci->dev;
 	u32 tmp;
@@ -558,15 +576,11 @@ static int imx6_pcie_establish_link(struct imx6_pcie *imx6_pcie)
 	tmp &= ~PCIE_RC_LCR_MAX_LINK_SPEEDS_MASK;
 	tmp |= PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1;
 	dw_pcie_writel_dbi(pci, PCIE_RC_LCR, tmp);
 
 	/* Start LTSSM. */
-	if (imx6_pcie->variant == IMX7D)
-		reset_control_deassert(imx6_pcie->apps_reset);
-	else
-		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
-				   IMX6Q_GPR12_PCIE_CTL_2, 1 << 10);
+	imx6_pcie_ltssm_enable(dev);
 
 	ret = imx6_pcie_wait_for_link(imx6_pcie);
 	if (ret)
 		goto err_reset_phy;
 
@@ -680,10 +694,82 @@ static int imx6_add_pcie_port(struct imx6_pcie *imx6_pcie,
 
 static const struct dw_pcie_ops dw_pcie_ops = {
 	.link_up = imx6_pcie_link_up,
 };
 
+#ifdef CONFIG_PM_SLEEP
+static void imx6_pcie_ltssm_disable(struct device *dev)
+{
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+
+	switch (imx6_pcie->variant) {
+	case IMX6SX:
+	case IMX6QP:
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX6Q_GPR12_PCIE_CTL_2, 0);
+		break;
+	case IMX7D:
+		reset_control_assert(imx6_pcie->apps_reset);
+		break;
+	default:
+		dev_err(dev, "ltssm_disable not supported\n");
+	}
+}
+
+static void imx6_pcie_clk_disable(struct imx6_pcie *imx6_pcie)
+{
+	clk_disable_unprepare(imx6_pcie->pcie);
+	clk_disable_unprepare(imx6_pcie->pcie_phy);
+	clk_disable_unprepare(imx6_pcie->pcie_bus);
+
+	if (imx6_pcie->variant == IMX7D) {
+		regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
+				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL,
+				   IMX7D_GPR12_PCIE_PHY_REFCLK_SEL);
+	}
+}
+
+static int imx6_pcie_suspend_noirq(struct device *dev)
+{
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+
+	if (imx6_pcie->variant != IMX7D)
+		return 0;
+
+	imx6_pcie_clk_disable(imx6_pcie);
+	imx6_pcie_ltssm_disable(dev);
+
+	return 0;
+}
+
+static int imx6_pcie_resume_noirq(struct device *dev)
+{
+	int ret;
+	struct imx6_pcie *imx6_pcie = dev_get_drvdata(dev);
+	struct pcie_port *pp = &imx6_pcie->pci->pp;
+
+	if (imx6_pcie->variant != IMX7D)
+		return 0;
+
+	imx6_pcie_assert_core_reset(imx6_pcie);
+	imx6_pcie_init_phy(imx6_pcie);
+	imx6_pcie_deassert_core_reset(imx6_pcie);
+	dw_pcie_setup_rc(pp);
+
+	ret = imx6_pcie_establish_link(imx6_pcie);
+	if (ret < 0)
+		dev_info(dev, "pcie link is down after resume.\n");
+
+	return 0;
+}
+#endif
+
+static const struct dev_pm_ops imx6_pcie_pm_ops = {
+	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(imx6_pcie_suspend_noirq,
+				      imx6_pcie_resume_noirq)
+};
+
 static int imx6_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct dw_pcie *pci;
 	struct imx6_pcie *imx6_pcie;
@@ -846,10 +932,11 @@ static const struct of_device_id imx6_pcie_of_match[] = {
 static struct platform_driver imx6_pcie_driver = {
 	.driver = {
 		.name	= "imx6q-pcie",
 		.of_match_table = imx6_pcie_of_match,
 		.suppress_bind_attrs = true,
+		.pm = &imx6_pcie_pm_ops,
 	},
 	.probe    = imx6_pcie_probe,
 	.shutdown = imx6_pcie_shutdown,
 };
 
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 1/2] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"

[Lucas Stach]

QW0gRGllbnN0YWcsIGRlbiAyNC4wNy4yMDE4LCAxOToxNCArMDMwMCBzY2hyaWViIExlb25hcmQg
Q3Jlc3RlejoKPiBUaGlzIHJldmVydHMgY29tbWl0IDFjODZjOWRkODJmODU5YjQ3NDQ3NGE3ZmVl
MGQ1MTk1ZGEyYzljMWQuCj4gCj4gVGhhdCBjb21taXQgZm9sbG93ZWQgdGhlIHJlZmVyZW5jZSBt
YW51YWwgYnV0IHVuZm9ydHVuYXRlbHkgdGhlIGlteDdkCj4gbWFudWFsIGlzIGluY29ycmVjdC4K
PiAKPiBUZXN0ZWQgd2l0aCBhdGg5ayBwY2llIGNhcmQgYW5kIGNvbmZpcm1lZCBpbnRlcm5hbGx5
Lgo+IAo+IFNpZ25lZC1vZmYtYnk6IExlb25hcmQgQ3Jlc3RleiA8bGVvbmFyZC5jcmVzdGV6QG54
cC5jb20+CgpBY2tlZC1ieTogTHVjYXMgU3RhY2ggPGwuc3RhY2hAcGVuZ3V0cm9uaXguZGU+Cgo+
IC0tLQo+IMKgYXJjaC9hcm0vYm9vdC9kdHMvaW14N2QuZHRzaSB8IDEyICsrKysrKysrLS0tLQo+
IMKgMSBmaWxlIGNoYW5nZWQsIDggaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkKPiAKPiBk
aWZmIC0tZ2l0IGEvYXJjaC9hcm0vYm9vdC9kdHMvaW14N2QuZHRzaSBiL2FyY2gvYXJtL2Jvb3Qv
ZHRzL2lteDdkLmR0c2kKPiBpbmRleCA3Y2JjMmZmYTRiM2EuLjcyMzRlODMzMGE1NyAxMDA2NDQK
PiAtLS0gYS9hcmNoL2FybS9ib290L2R0cy9pbXg3ZC5kdHNpCj4gKysrIGIvYXJjaC9hcm0vYm9v
dC9kdHMvaW14N2QuZHRzaQo+IEBAIC0xMjQsMTQgKzEyNCwxOCBAQAo+ID4gwqAJCW51bS1sYW5l
cyA9IDwxPjsKPiA+IMKgCQlpbnRlcnJ1cHRzID0gPEdJQ19TUEkgMTIyIElSUV9UWVBFX0xFVkVM
X0hJR0g+Owo+ID4gwqAJCWludGVycnVwdC1uYW1lcyA9ICJtc2kiOwo+ID4gwqAJCSNpbnRlcnJ1
cHQtY2VsbHMgPSA8MT47Cj4gPiDCoAkJaW50ZXJydXB0LW1hcC1tYXNrID0gPDAgMCAwIDB4Nz47
Cj4gPiAtCQlpbnRlcnJ1cHQtbWFwID0gPDAgMCAwIDEgJmludGMgR0lDX1NQSSAxMjIgSVJRX1RZ
UEVfTEVWRUxfSElHSD4sCj4gPiAtCQkJCTwwIDAgMCAyICZpbnRjIEdJQ19TUEkgMTIzIElSUV9U
WVBFX0xFVkVMX0hJR0g+LAo+ID4gLQkJCQk8MCAwIDAgMyAmaW50YyBHSUNfU1BJIDEyNCBJUlFf
VFlQRV9MRVZFTF9ISUdIPiwKPiA+IC0JCQkJPDAgMCAwIDQgJmludGMgR0lDX1NQSSAxMjUgSVJR
X1RZUEVfTEVWRUxfSElHSD47Cj4gPiArCQkvKgo+ID4gKwkJwqAqIFJlZmVyZW5jZSBtYW51YWwg
bGlzdHMgcGNpIGlycXMgaW5jb3JyZWN0bHkKPiA+ICsJCcKgKiBSZWFsIGhhcmR3YXJlIG9yZGVy
aW5nIGlzIHNhbWUgYXMgaW14NjogRCtNU0ksIEMsIEIsIEEKPiA+ICsJCcKgKi8KPiA+ICsJCWlu
dGVycnVwdC1tYXAgPSA8MCAwIDAgMSAmaW50YyBHSUNfU1BJIDEyNSBJUlFfVFlQRV9MRVZFTF9I
SUdIPiwKPiA+ICsJCQkJPDAgMCAwIDIgJmludGMgR0lDX1NQSSAxMjQgSVJRX1RZUEVfTEVWRUxf
SElHSD4sCj4gPiArCQkJCTwwIDAgMCAzICZpbnRjIEdJQ19TUEkgMTIzIElSUV9UWVBFX0xFVkVM
X0hJR0g+LAo+ID4gKwkJCQk8MCAwIDAgNCAmaW50YyBHSUNfU1BJIDEyMiBJUlFfVFlQRV9MRVZF
TF9ISUdIPjsKPiA+IMKgCQljbG9ja3MgPSA8JmNsa3MgSU1YN0RfUENJRV9DVFJMX1JPT1RfQ0xL
PiwKPiA+IMKgCQkJwqA8JmNsa3MgSU1YN0RfUExMX0VORVRfTUFJTl8xMDBNX0NMSz4sCj4gPiDC
oAkJCcKgPCZjbGtzIElNWDdEX1BDSUVfUEhZX1JPT1RfQ0xLPjsKPiA+IMKgCQljbG9jay1uYW1l
cyA9ICJwY2llIiwgInBjaWVfYnVzIiwgInBjaWVfcGh5IjsKPiA+IMKgCQlhc3NpZ25lZC1jbG9j
a3MgPSA8JmNsa3MgSU1YN0RfUENJRV9DVFJMX1JPT1RfU1JDPiwKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBs
aXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5m
cmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK

Re: [PATCH v3 2/2] PCI: imx: Initial imx7d pm support

[Lucas Stach]

QW0gRGllbnN0YWcsIGRlbiAyNC4wNy4yMDE4LCAxOToxNCArMDMwMCBzY2hyaWViIExlb25hcmQg
Q3Jlc3RlejoKPiBPbiBpbXg3ZCB0aGUgcGNpZS1waHkgcG93ZXIgZG9tYWluIGlzIHR1cm5lZCBv
ZmYgaW4gc3VzcGVuZCBhbmQgdGhpcyBjYW4KPiBtYWtlIHRoZSBzeXN0ZW0gaGFuZyBhZnRlciBy
ZXN1bWUgd2hlbiBhdHRlbXB0aW5nIGFueSByZWFkIGZyb20gUENJLgo+IAo+IEZpeCB0aGlzIGJ5
IGFkZGluZyBtaW5pbWFsIHN1c3BlbmQvcmVzdW1lIGNvZGUgZnJvbSB0aGUgbnhwIGludGVybmFs
Cj4gdHJlZS4gVGhpcyB3aWxsIHByZXBhcmUgZm9yIHBvd2VyaW5nIGRvd24gb24gc3VzcGVuZCBh
bmQgcmVzZXQgdGhlIGJsb2NrCj4gb24gcmVzdW1lLgo+IAo+IENvZGUgaXMgb25seSBmb3IgaW14
N2QgYnV0IGEgdmVyeSBzaW1pbGFyIHNlcXVlbmNlIGNhbiBiZSB1c2VkIGZvcgo+IG90aGVyIHNv
Y3MuCj4gCj4gPiBUaGUgb3JpZ2luYWwgYXV0aG9yIGlzIG1vc3RseSBSaWNoYXJkIFpodSA8aG9u
Z3hpbmcuemh1QG54cC5jb20+LCB0aGlzCj4gcGF0Y2ggYWRqdXN0cyB0aGUgY29kZSB0byB0aGUg
dXBzdHJlYW0gaW14N2QgaW1wbGVtZW50aW9uIHVzaW5nIHJlc2V0Cj4gY29udHJvbHMgYW5kIHBv
d2VyIGRvbWFpbnMuCj4gCj4gU2lnbmVkLW9mZi1ieTogTGVvbmFyZCBDcmVzdGV6IDxsZW9uYXJk
LmNyZXN0ZXpAbnhwLmNvbT4KClJldmlld2VkLWJ5OiBMdWNhcyBTdGFjaCA8bC5zdGFjaEBwZW5n
dXRyb25peC5kZT4KCj4gLS0tCj4gwqBkcml2ZXJzL3BjaS9jb250cm9sbGVyL2R3Yy9wY2ktaW14
Ni5jIHwgOTcgKysrKysrKysrKysrKysrKysrKysrKysrKy0tCj4gwqAxIGZpbGUgY2hhbmdlZCwg
OTIgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKPiAKPiBkaWZmIC0tZ2l0IGEvZHJpdmVy
cy9wY2kvY29udHJvbGxlci9kd2MvcGNpLWlteDYuYyBiL2RyaXZlcnMvcGNpL2NvbnRyb2xsZXIv
ZHdjL3BjaS1pbXg2LmMKPiBpbmRleCA0YTlhNjczYjQ3NzcuLjY1YjZkMTAxNTcyMyAxMDA2NDQK
PiAtLS0gYS9kcml2ZXJzL3BjaS9jb250cm9sbGVyL2R3Yy9wY2ktaW14Ni5jCj4gKysrIGIvZHJp
dmVycy9wY2kvY29udHJvbGxlci9kd2MvcGNpLWlteDYuYwo+IEBAIC01NDAsMTAgKzU0MCwyOCBA
QCBzdGF0aWMgaW50IGlteDZfcGNpZV93YWl0X2Zvcl9zcGVlZF9jaGFuZ2Uoc3RydWN0IGlteDZf
cGNpZSAqaW14Nl9wY2llKQo+IMKgCj4gPiDCoAlkZXZfZXJyKGRldiwgIlNwZWVkIGNoYW5nZSB0
aW1lb3V0XG4iKTsKPiA+IMKgCXJldHVybiAtRUlOVkFMOwo+IMKgfQo+IMKgCj4gK3N0YXRpYyB2
b2lkIGlteDZfcGNpZV9sdHNzbV9lbmFibGUoc3RydWN0IGRldmljZSAqZGV2KQo+ICt7Cj4gPiAr
CXN0cnVjdCBpbXg2X3BjaWUgKmlteDZfcGNpZSA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOwo+ICsK
PiA+ICsJc3dpdGNoIChpbXg2X3BjaWUtPnZhcmlhbnQpIHsKPiA+ICsJY2FzZSBJTVg2UToKPiA+
ICsJY2FzZSBJTVg2U1g6Cj4gPiArCWNhc2UgSU1YNlFQOgo+ID4gKwkJcmVnbWFwX3VwZGF0ZV9i
aXRzKGlteDZfcGNpZS0+aW9tdXhjX2dwciwgSU9NVVhDX0dQUjEyLAo+ID4gKwkJCQnCoMKgwqBJ
TVg2UV9HUFIxMl9QQ0lFX0NUTF8yLAo+ID4gKwkJCQnCoMKgwqBJTVg2UV9HUFIxMl9QQ0lFX0NU
TF8yKTsKPiA+ICsJCWJyZWFrOwo+ID4gKwljYXNlIElNWDdEOgo+ID4gKwkJcmVzZXRfY29udHJv
bF9kZWFzc2VydChpbXg2X3BjaWUtPmFwcHNfcmVzZXQpOwo+ID4gKwkJYnJlYWs7Cj4gPiArCX0K
PiArfQo+ICsKPiDCoHN0YXRpYyBpbnQgaW14Nl9wY2llX2VzdGFibGlzaF9saW5rKHN0cnVjdCBp
bXg2X3BjaWUgKmlteDZfcGNpZSkKPiDCoHsKPiA+IMKgCXN0cnVjdCBkd19wY2llICpwY2kgPSBp
bXg2X3BjaWUtPnBjaTsKPiA+IMKgCXN0cnVjdCBkZXZpY2UgKmRldiA9IHBjaS0+ZGV2Owo+ID4g
wqAJdTMyIHRtcDsKPiBAQCAtNTU4LDE1ICs1NzYsMTEgQEAgc3RhdGljIGludCBpbXg2X3BjaWVf
ZXN0YWJsaXNoX2xpbmsoc3RydWN0IGlteDZfcGNpZSAqaW14Nl9wY2llKQo+ID4gwqAJdG1wICY9
IH5QQ0lFX1JDX0xDUl9NQVhfTElOS19TUEVFRFNfTUFTSzsKPiA+IMKgCXRtcCB8PSBQQ0lFX1JD
X0xDUl9NQVhfTElOS19TUEVFRFNfR0VOMTsKPiA+IMKgCWR3X3BjaWVfd3JpdGVsX2RiaShwY2ks
IFBDSUVfUkNfTENSLCB0bXApOwo+IMKgCj4gPiDCoAkvKiBTdGFydCBMVFNTTS4gKi8KPiA+IC0J
aWYgKGlteDZfcGNpZS0+dmFyaWFudCA9PSBJTVg3RCkKPiA+IC0JCXJlc2V0X2NvbnRyb2xfZGVh
c3NlcnQoaW14Nl9wY2llLT5hcHBzX3Jlc2V0KTsKPiA+IC0JZWxzZQo+ID4gLQkJcmVnbWFwX3Vw
ZGF0ZV9iaXRzKGlteDZfcGNpZS0+aW9tdXhjX2dwciwgSU9NVVhDX0dQUjEyLAo+ID4gLQkJCQnC
oMKgwqBJTVg2UV9HUFIxMl9QQ0lFX0NUTF8yLCAxIDw8IDEwKTsKPiA+ICsJaW14Nl9wY2llX2x0
c3NtX2VuYWJsZShkZXYpOwo+IMKgCj4gPiDCoAlyZXQgPSBpbXg2X3BjaWVfd2FpdF9mb3JfbGlu
ayhpbXg2X3BjaWUpOwo+ID4gwqAJaWYgKHJldCkKPiA+IMKgCQlnb3RvIGVycl9yZXNldF9waHk7
Cj4gwqAKPiBAQCAtNjgwLDEwICs2OTQsODIgQEAgc3RhdGljIGludCBpbXg2X2FkZF9wY2llX3Bv
cnQoc3RydWN0IGlteDZfcGNpZSAqaW14Nl9wY2llLAo+IMKgCj4gwqBzdGF0aWMgY29uc3Qgc3Ry
dWN0IGR3X3BjaWVfb3BzIGR3X3BjaWVfb3BzID0gewo+ID4gwqAJLmxpbmtfdXAgPSBpbXg2X3Bj
aWVfbGlua191cCwKPiDCoH07Cj4gwqAKPiArI2lmZGVmIENPTkZJR19QTV9TTEVFUAo+ICtzdGF0
aWMgdm9pZCBpbXg2X3BjaWVfbHRzc21fZGlzYWJsZShzdHJ1Y3QgZGV2aWNlICpkZXYpCj4gK3sK
PiA+ICsJc3RydWN0IGlteDZfcGNpZSAqaW14Nl9wY2llID0gZGV2X2dldF9kcnZkYXRhKGRldik7
Cj4gKwo+ID4gKwlzd2l0Y2ggKGlteDZfcGNpZS0+dmFyaWFudCkgewo+ID4gKwljYXNlIElNWDZT
WDoKPiA+ICsJY2FzZSBJTVg2UVA6Cj4gPiArCQlyZWdtYXBfdXBkYXRlX2JpdHMoaW14Nl9wY2ll
LT5pb211eGNfZ3ByLCBJT01VWENfR1BSMTIsCj4gPiArCQkJCcKgwqDCoElNWDZRX0dQUjEyX1BD
SUVfQ1RMXzIsIDApOwo+ID4gKwkJYnJlYWs7Cj4gPiArCWNhc2UgSU1YN0Q6Cj4gPiArCQlyZXNl
dF9jb250cm9sX2Fzc2VydChpbXg2X3BjaWUtPmFwcHNfcmVzZXQpOwo+ID4gKwkJYnJlYWs7Cj4g
PiArCWRlZmF1bHQ6Cj4gPiArCQlkZXZfZXJyKGRldiwgImx0c3NtX2Rpc2FibGUgbm90IHN1cHBv
cnRlZFxuIik7Cj4gPiArCX0KPiArfQo+ICsKPiArc3RhdGljIHZvaWQgaW14Nl9wY2llX2Nsa19k
aXNhYmxlKHN0cnVjdCBpbXg2X3BjaWUgKmlteDZfcGNpZSkKPiArewo+ID4gKwljbGtfZGlzYWJs
ZV91bnByZXBhcmUoaW14Nl9wY2llLT5wY2llKTsKPiA+ICsJY2xrX2Rpc2FibGVfdW5wcmVwYXJl
KGlteDZfcGNpZS0+cGNpZV9waHkpOwo+ID4gKwljbGtfZGlzYWJsZV91bnByZXBhcmUoaW14Nl9w
Y2llLT5wY2llX2J1cyk7Cj4gKwo+ID4gKwlpZiAoaW14Nl9wY2llLT52YXJpYW50ID09IElNWDdE
KSB7Cj4gPiArCQlyZWdtYXBfdXBkYXRlX2JpdHMoaW14Nl9wY2llLT5pb211eGNfZ3ByLCBJT01V
WENfR1BSMTIsCj4gPiArCQkJCcKgwqDCoElNWDdEX0dQUjEyX1BDSUVfUEhZX1JFRkNMS19TRUws
Cj4gPiArCQkJCcKgwqDCoElNWDdEX0dQUjEyX1BDSUVfUEhZX1JFRkNMS19TRUwpOwo+ID4gKwl9
Cj4gK30KPiArCj4gK3N0YXRpYyBpbnQgaW14Nl9wY2llX3N1c3BlbmRfbm9pcnEoc3RydWN0IGRl
dmljZSAqZGV2KQo+ICt7Cj4gPiArCXN0cnVjdCBpbXg2X3BjaWUgKmlteDZfcGNpZSA9IGRldl9n
ZXRfZHJ2ZGF0YShkZXYpOwo+ICsKPiA+ICsJaWYgKGlteDZfcGNpZS0+dmFyaWFudCAhPSBJTVg3
RCkKPiA+ICsJCXJldHVybiAwOwo+ICsKPiA+ICsJaW14Nl9wY2llX2Nsa19kaXNhYmxlKGlteDZf
cGNpZSk7Cj4gPiArCWlteDZfcGNpZV9sdHNzbV9kaXNhYmxlKGRldik7Cj4gKwo+ID4gKwlyZXR1
cm4gMDsKPiArfQo+ICsKPiArc3RhdGljIGludCBpbXg2X3BjaWVfcmVzdW1lX25vaXJxKHN0cnVj
dCBkZXZpY2UgKmRldikKPiArewo+ID4gKwlpbnQgcmV0Owo+ID4gKwlzdHJ1Y3QgaW14Nl9wY2ll
ICppbXg2X3BjaWUgPSBkZXZfZ2V0X2RydmRhdGEoZGV2KTsKPiA+ICsJc3RydWN0IHBjaWVfcG9y
dCAqcHAgPSAmaW14Nl9wY2llLT5wY2ktPnBwOwo+ICsKPiA+ICsJaWYgKGlteDZfcGNpZS0+dmFy
aWFudCAhPSBJTVg3RCkKPiA+ICsJCXJldHVybiAwOwo+ICsKPiA+ICsJaW14Nl9wY2llX2Fzc2Vy
dF9jb3JlX3Jlc2V0KGlteDZfcGNpZSk7Cj4gPiArCWlteDZfcGNpZV9pbml0X3BoeShpbXg2X3Bj
aWUpOwo+ID4gKwlpbXg2X3BjaWVfZGVhc3NlcnRfY29yZV9yZXNldChpbXg2X3BjaWUpOwo+ID4g
Kwlkd19wY2llX3NldHVwX3JjKHBwKTsKPiArCj4gPiArCXJldCA9IGlteDZfcGNpZV9lc3RhYmxp
c2hfbGluayhpbXg2X3BjaWUpOwo+ID4gKwlpZiAocmV0IDwgMCkKPiA+ICsJCWRldl9pbmZvKGRl
diwgInBjaWUgbGluayBpcyBkb3duIGFmdGVyIHJlc3VtZS5cbiIpOwo+ICsKPiA+ICsJcmV0dXJu
IDA7Cj4gK30KPiArI2VuZGlmCj4gKwo+ICtzdGF0aWMgY29uc3Qgc3RydWN0IGRldl9wbV9vcHMg
aW14Nl9wY2llX3BtX29wcyA9IHsKPiA+ICsJU0VUX05PSVJRX1NZU1RFTV9TTEVFUF9QTV9PUFMo
aW14Nl9wY2llX3N1c3BlbmRfbm9pcnEsCj4gPiArCQkJCcKgwqDCoMKgwqDCoGlteDZfcGNpZV9y
ZXN1bWVfbm9pcnEpCj4gK307Cj4gKwo+IMKgc3RhdGljIGludCBpbXg2X3BjaWVfcHJvYmUoc3Ry
dWN0IHBsYXRmb3JtX2RldmljZSAqcGRldikKPiDCoHsKPiA+IMKgCXN0cnVjdCBkZXZpY2UgKmRl
diA9ICZwZGV2LT5kZXY7Cj4gPiDCoAlzdHJ1Y3QgZHdfcGNpZSAqcGNpOwo+ID4gwqAJc3RydWN0
IGlteDZfcGNpZSAqaW14Nl9wY2llOwo+IEBAIC04NDYsMTAgKzkzMiwxMSBAQCBzdGF0aWMgY29u
c3Qgc3RydWN0IG9mX2RldmljZV9pZCBpbXg2X3BjaWVfb2ZfbWF0Y2hbXSA9IHsKPiDCoHN0YXRp
YyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIGlteDZfcGNpZV9kcml2ZXIgPSB7Cj4gPiDCoAkuZHJp
dmVyID0gewo+ID4gPiDCoAkJLm5hbWUJPSAiaW14NnEtcGNpZSIsCj4gPiDCoAkJLm9mX21hdGNo
X3RhYmxlID0gaW14Nl9wY2llX29mX21hdGNoLAo+ID4gwqAJCS5zdXBwcmVzc19iaW5kX2F0dHJz
ID0gdHJ1ZSwKPiA+ICsJCS5wbSA9ICZpbXg2X3BjaWVfcG1fb3BzLAo+ID4gwqAJfSwKPiA+IMKg
CS5wcm9iZcKgwqDCoMKgPSBpbXg2X3BjaWVfcHJvYmUsCj4gPiDCoAkuc2h1dGRvd24gPSBpbXg2
X3BjaWVfc2h1dGRvd24sCj4gwqB9Owo+IMKgCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1h
cm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcv
bWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Leonard Crestez]

On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:
> Changes since v2:
>  * Print with dev_info if link fails on resume (Lucas)
>  * Add a comment on imx7d pci irq mappings (Andrey)
>  * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)
> 
> The ltssm_disable does not return an error because it can't be usefully
> handled, reversing partial suspend is a nightmare and unlikely to work.
> 
>  * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)
> 
> Series is against linux-next tag next-20180724 where the reset patch was
> already accepted. The imx7d.dtsi patch is also useful standalone.
> 
> Link to v2: https://lkml.org/lkml/2018/7/20/472

This is a gentle reminder that this series was reviewed by Lucas two
weeks ago but not yet included.

--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Lorenzo Pieralisi]

On Wed, Aug 08, 2018 at 10:53:52AM +0000, Leonard Crestez wrote:
> On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:
> > Changes since v2:
> >  * Print with dev_info if link fails on resume (Lucas)
> >  * Add a comment on imx7d pci irq mappings (Andrey)
> >  * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)
> > 
> > The ltssm_disable does not return an error because it can't be usefully
> > handled, reversing partial suspend is a nightmare and unlikely to work.
> > 
> >  * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)
> > 
> > Series is against linux-next tag next-20180724 where the reset patch was
> > already accepted. The imx7d.dtsi patch is also useful standalone.
> > 
> > Link to v2: https://lkml.org/lkml/2018/7/20/472
> 
> This is a gentle reminder that this series was reviewed by Lucas two
> weeks ago but not yet included.

Does this series have a functional dependency on the reset fix ? If yes
we can have a bisection proplem depending on which tree gets merged
first.

Please let me know.

Thanks,
Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Leonard Crestez]

On Wed, 2018-08-08 at 12:14 +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 08, 2018 at 10:53:52AM +0000, Leonard Crestez wrote:
> > On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:
> > > Changes since v2:
> > >  * Print with dev_info if link fails on resume (Lucas)
> > >  * Add a comment on imx7d pci irq mappings (Andrey)
> > >  * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)
> > > 
> > > The ltssm_disable does not return an error because it can't be usefully
> > > handled, reversing partial suspend is a nightmare and unlikely to work.
> > > 
> > >  * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)
> > > 
> > > Series is against linux-next tag next-20180724 where the reset patch was
> > > already accepted. The imx7d.dtsi patch is also useful standalone.
> > > 
> > > Link to v2: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F7%2F20%2F472&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cc1e98512a50246c457a208d5fd2021dc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636693236811248777&sdata=gxs1%2BfevIaBmQCVcJLUK41ml8CK2zLg%2FFKGGV%2F%2FHSLQ%3D&reserved=0
> > 
> > This is a gentle reminder that this series was reviewed by Lucas two
> > weeks ago but not yet included.
> 
> Does this series have a functional dependency on the reset fix ? If yes
> we can have a bisection proplem depending on which tree gets merged
> first.

Yes, without the reset fix I expect hangs.

Maybe the reset fix should be pulled in the pci tree? I don't know how
these issues are sorted out.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Lorenzo Pieralisi]

On Wed, Aug 08, 2018 at 11:37:14AM +0000, Leonard Crestez wrote:
> On Wed, 2018-08-08 at 12:14 +0100, Lorenzo Pieralisi wrote:
> > On Wed, Aug 08, 2018 at 10:53:52AM +0000, Leonard Crestez wrote:
> > > On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:
> > > > Changes since v2:
> > > >  * Print with dev_info if link fails on resume (Lucas)
> > > >  * Add a comment on imx7d pci irq mappings (Andrey)
> > > >  * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)
> > > > 
> > > > The ltssm_disable does not return an error because it can't be usefully
> > > > handled, reversing partial suspend is a nightmare and unlikely to work.
> > > > 
> > > >  * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)
> > > > 
> > > > Series is against linux-next tag next-20180724 where the reset patch was
> > > > already accepted. The imx7d.dtsi patch is also useful standalone.
> > > > 
> > > > Link to v2: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2018%2F7%2F20%2F472&data=02%7C01%7Cleonard.crestez%40nxp.com%7Cc1e98512a50246c457a208d5fd2021dc%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636693236811248777&sdata=gxs1%2BfevIaBmQCVcJLUK41ml8CK2zLg%2FFKGGV%2F%2FHSLQ%3D&reserved=0
> > > 
> > > This is a gentle reminder that this series was reviewed by Lucas two
> > > weeks ago but not yet included.
> > 
> > Does this series have a functional dependency on the reset fix ? If yes
> > we can have a bisection proplem depending on which tree gets merged
> > first.
> 
> Yes, without the reset fix I expect hangs.
> 
> Maybe the reset fix should be pulled in the pci tree? I don't know how
> these issues are sorted out.

Well either I pull that fix into the PCI tree (but it is already -rc8
and I can't guarantee v4.19 inclusion - I shall try) or I can ack these
patches and Philippe will send them upstream on my behalf, atop the
reset fix above.

When will the reset fix will be sent to Linus ? Please let me know
how you want to proceed.

Thanks,
Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Leonard Crestez]

On Wed, 2018-08-08 at 15:19 +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 08, 2018 at 11:37:14AM +0000, Leonard Crestez wrote:
> > On Wed, 2018-08-08 at 12:14 +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Aug 08, 2018 at 10:53:52AM +0000, Leonard Crestez wrote:
> > > > On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:
> > > > > Changes since v2:
> > > > >  * Print with dev_info if link fails on resume (Lucas)
> > > > >  * Add a comment on imx7d pci irq mappings (Andrey)
> > > > >  * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)
> > > > > 
> > > > > The ltssm_disable does not return an error because it can't be usefully
> > > > > handled, reversing partial suspend is a nightmare and unlikely to work.
> > > > > 
> > > > >  * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)
> > > > > 
> > > > > Series is against linux-next tag next-20180724 where the reset patch was
> > > > > already accepted. The imx7d.dtsi patch is also useful standalone.
> > > > 
> > > > This is a gentle reminder that this series was reviewed by Lucas two
> > > > weeks ago but not yet included.
> > > 
> > > Does this series have a functional dependency on the reset fix ? If yes
> > > we can have a bisection proplem depending on which tree gets merged
> > > first.
> > 
> > Yes, without the reset fix I expect hangs.
> > 
> > Maybe the reset fix should be pulled in the pci tree? I don't know how
> > these issues are sorted out.
> 
> Well either I pull that fix into the PCI tree (but it is already -rc8
> and I can't guarantee v4.19 inclusion - I shall try) or I can ack these
> patches and Philippe will send them upstream on my behalf, atop the
> reset fix above.
> 
> When will the reset fix will be sent to Linus ? Please let me know
> how you want to proceed.

I have some other unsent changes for imx pci+dts+reset standing by.
Since these changes qualify more as "pm features" than fixes I don't
really mind skipping 4.19.

Pulling pci features into the reset tree doesn't make much sense to me.

Maybe this kind of stuff could go through Shawn's tree? There shouldn't
be any interaction with non-imx stuff.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Lorenzo Pieralisi]

On Wed, Aug 08, 2018 at 02:58:15PM +0000, Leonard Crestez wrote:
> On Wed, 2018-08-08 at 15:19 +0100, Lorenzo Pieralisi wrote:
> > On Wed, Aug 08, 2018 at 11:37:14AM +0000, Leonard Crestez wrote:
> > > On Wed, 2018-08-08 at 12:14 +0100, Lorenzo Pieralisi wrote:
> > > > On Wed, Aug 08, 2018 at 10:53:52AM +0000, Leonard Crestez wrote:
> > > > > On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:
> > > > > > Changes since v2:
> > > > > >  * Print with dev_info if link fails on resume (Lucas)
> > > > > >  * Add a comment on imx7d pci irq mappings (Andrey)
> > > > > >  * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)
> > > > > > 
> > > > > > The ltssm_disable does not return an error because it can't be usefully
> > > > > > handled, reversing partial suspend is a nightmare and unlikely to work.
> > > > > > 
> > > > > >  * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)
> > > > > > 
> > > > > > Series is against linux-next tag next-20180724 where the reset patch was
> > > > > > already accepted. The imx7d.dtsi patch is also useful standalone.
> > > > > 
> > > > > This is a gentle reminder that this series was reviewed by Lucas two
> > > > > weeks ago but not yet included.
> > > > 
> > > > Does this series have a functional dependency on the reset fix ? If yes
> > > > we can have a bisection proplem depending on which tree gets merged
> > > > first.
> > > 
> > > Yes, without the reset fix I expect hangs.
> > > 
> > > Maybe the reset fix should be pulled in the pci tree? I don't know how
> > > these issues are sorted out.
> > 
> > Well either I pull that fix into the PCI tree (but it is already -rc8
> > and I can't guarantee v4.19 inclusion - I shall try) or I can ack these
> > patches and Philippe will send them upstream on my behalf, atop the
> > reset fix above.
> > 
> > When will the reset fix will be sent to Linus ? Please let me know
> > how you want to proceed.
> 
> I have some other unsent changes for imx pci+dts+reset standing by.
> Since these changes qualify more as "pm features" than fixes I don't
> really mind skipping 4.19.

OK that's fine by me, resend this series and the new patches at
v4.19-rc1 and I will pull the changes into the pci tree then.

> Pulling pci features into the reset tree doesn't make much sense to me.

I was just giving you an option.

> Maybe this kind of stuff could go through Shawn's tree? There shouldn't
> be any interaction with non-imx stuff.

As I said, I can ack the changes for Shawn to pick them up but if
Shawn's tree goes to Linus via eg arm-soc we are back to square
one, it is just too late.

I have no problem taking these changes in the PCI tree for v4.20 as long
as we plan the dependencies in advance.

Lorenzo

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Leonard Crestez]

On Wed, 2018-08-08 at 16:27 +0100, Lorenzo Pieralisi wrote:
> On Wed, Aug 08, 2018 at 02:58:15PM +0000, Leonard Crestez wrote:
> > On Wed, 2018-08-08 at 15:19 +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Aug 08, 2018 at 11:37:14AM +0000, Leonard Crestez wrote:
> > > > On Wed, 2018-08-08 at 12:14 +0100, Lorenzo Pieralisi wrote:
> > > > > On Wed, Aug 08, 2018 at 10:53:52AM +0000, Leonard Crestez wrote:
> > > > > > On Tue, 2018-07-24 at 19:14 +0300, Leonard Crestez wrote:
> > > > > > > Changes since v2:
> > > > > > >  * Print with dev_info if link fails on resume (Lucas)
> > > > > > >  * Add a comment on imx7d pci irq mappings (Andrey)
> > > > > > >  * Make imx6_pcie_ltssm_disable print an error on IMX6Q (Lucas)
> > > > > > > 
> > > > > > > The ltssm_disable does not return an error because it can't be usefully
> > > > > > > handled, reversing partial suspend is a nightmare and unlikely to work.
> > > > > > > 
> > > > > > >  * Drop "reset: imx7: Fix always writing bits as 0 (accepted by Philipp)
> > > > > > > 
> > > > > > > Series is against linux-next tag next-20180724 where the reset patch was
> > > > > > > already accepted. The imx7d.dtsi patch is also useful standalone.
> > > > > > 
> > > > > > This is a gentle reminder that this series was reviewed by Lucas two
> > > > > > weeks ago but not yet included.
> > > > > 
> > > > > Does this series have a functional dependency on the reset fix ? If yes
> > > > > we can have a bisection proplem depending on which tree gets merged
> > > > > first.
> > > > 
> > > > Yes, without the reset fix I expect hangs.

This needs further clarification: without the reset patch this will
hang on imx7 suspend/resume but this is the current behavior anyway.

Both patches are required for imx7 pci suspend and including them out
of order shouldn't break unrelated functionality.

So it should actually be fine to just include the pci changes now,
right?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Lorenzo Pieralisi]

On Fri, Aug 10, 2018 at 11:11:55AM +0000, Leonard Crestez wrote:

[...]

> This needs further clarification: without the reset patch this will
> hang on imx7 suspend/resume but this is the current behavior anyway.
> 
> Both patches are required for imx7 pci suspend and including them out
> of order shouldn't break unrelated functionality.
> 
> So it should actually be fine to just include the pci changes now,
> right?

It is a bit late for v4.19 but before considering that, this series
is actually a set of fixes, correct ? If that's the case I think
Shawn can send them upstream for a v4.19-rc*, I can ACK them if that
sounds reasonable.

Patch (2) subject must make clear you are actually fixing a problem if
we choose this course of action.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/2] PCI: imx: Initial imx7d pm support

[Shawn Guo]

On Fri, Aug 10, 2018 at 04:13:41PM +0100, Lorenzo Pieralisi wrote:
> On Fri, Aug 10, 2018 at 11:11:55AM +0000, Leonard Crestez wrote:
> 
> [...]
> 
> > This needs further clarification: without the reset patch this will
> > hang on imx7 suspend/resume but this is the current behavior anyway.
> > 
> > Both patches are required for imx7 pci suspend and including them out
> > of order shouldn't break unrelated functionality.
> > 
> > So it should actually be fine to just include the pci changes now,
> > right?
> 
> It is a bit late for v4.19 but before considering that, this series
> is actually a set of fixes, correct ? If that's the case I think
> Shawn can send them upstream for a v4.19-rc*, I can ACK them if that
> sounds reasonable.
> 
> Patch (2) subject must make clear you are actually fixing a problem if
> we choose this course of action.

This is something never worked before, so it's a new feature to me.
That said, I'm not in the position to send the PCI patch for 4.19-rc as
a fix though IMX (arm-soc) tree.

I will send the DTS patch for 4.19-rc inclusion though, since that's
indeed a fix.

Shawn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 1/2] Revert "ARM: dts: imx7d: Invert legacy PCI irq mapping"

[Shawn Guo]

On Tue, Jul 24, 2018 at 07:14:19PM +0300, Leonard Crestez wrote:
> This reverts commit 1c86c9dd82f859b474474a7fee0d5195da2c9c1d.
> 
> That commit followed the reference manual but unfortunately the imx7d
> manual is incorrect.
> 
> Tested with ath9k pcie card and confirmed internally.
> 
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

Applied, thanks.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel