* [v2 PATCH 1/6] usb: mtu3: fix error code for getting extcon device
From: Chunfeng Yun @ 2018-01-03 8:53 UTC (permalink / raw)
To: linux-arm-kernel
When failing to get extcon device, extcon_get_edev_by_phandle()
may return different error codes, but not only -EPROBE_DEFER,
so can't always return -EPROBE_DEFER, and fix it.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_plat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 3650fd1..5b2110b 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -308,7 +308,7 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
otg_sx->edev = extcon_get_edev_by_phandle(ssusb->dev, 0);
if (IS_ERR(otg_sx->edev)) {
dev_err(ssusb->dev, "couldn't get extcon device\n");
- return -EPROBE_DEFER;
+ return PTR_ERR(otg_sx->edev);
}
}
--
1.9.1
^ permalink raw reply related
* [v2 PATCH 2/6] usb: mtu3: supports remote wakeup for mt2712 with two SSUSB IPs
From: Chunfeng Yun @ 2018-01-03 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41c6b0f2e959c07eff261060e57fd180a750071a.1514967463.git.chunfeng.yun@mediatek.com>
The old way of usb wakeup only supports platform with single SSUSB IP,
such as mt8173, but mt2712 has two SSUSB IPs, so rebuild its flow and
also supports the new glue layer of usb wakeup on mt2712 which is
different from mt8173.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3.h | 11 +++--
drivers/usb/mtu3/mtu3_dr.h | 3 +-
drivers/usb/mtu3/mtu3_host.c | 115 +++++++++++++++++++++----------------------
drivers/usb/mtu3/mtu3_plat.c | 8 +--
4 files changed, 70 insertions(+), 67 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 3c888d9..2cd00a2 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -229,7 +229,10 @@ struct otg_switch_mtk {
* @u3p_dis_msk: mask of disabling usb3 ports, for example, bit0==1 to
* disable u3port0, bit1==1 to disable u3port1,... etc
* @dbgfs_root: only used when supports manual dual-role switch via debugfs
- * @wakeup_en: it's true when supports remote wakeup in host mode
+ * @uwk_en: it's true when supports remote wakeup in host mode
+ * @uwk: syscon including usb wakeup glue layer between SSUSB IP and SPM
+ * @uwk_reg_base: the base address of the wakeup glue layer in @uwk
+ * @uwk_vers: the version of the wakeup glue layer
*/
struct ssusb_mtk {
struct device *dev;
@@ -253,8 +256,10 @@ struct ssusb_mtk {
int u3p_dis_msk;
struct dentry *dbgfs_root;
/* usb wakeup for host mode */
- bool wakeup_en;
- struct regmap *pericfg;
+ bool uwk_en;
+ struct regmap *uwk;
+ u32 uwk_reg_base;
+ u32 uwk_vers;
};
/**
diff --git a/drivers/usb/mtu3/mtu3_dr.h b/drivers/usb/mtu3/mtu3_dr.h
index c179192..ae1598d 100644
--- a/drivers/usb/mtu3/mtu3_dr.h
+++ b/drivers/usb/mtu3/mtu3_dr.h
@@ -18,8 +18,7 @@ int ssusb_wakeup_of_property_parse(struct ssusb_mtk *ssusb,
struct device_node *dn);
int ssusb_host_enable(struct ssusb_mtk *ssusb);
int ssusb_host_disable(struct ssusb_mtk *ssusb, bool suspend);
-int ssusb_wakeup_enable(struct ssusb_mtk *ssusb);
-void ssusb_wakeup_disable(struct ssusb_mtk *ssusb);
+void ssusb_wakeup_set(struct ssusb_mtk *ssusb, bool enable);
#else
diff --git a/drivers/usb/mtu3/mtu3_host.c b/drivers/usb/mtu3/mtu3_host.c
index d237d7e..259beef 100644
--- a/drivers/usb/mtu3/mtu3_host.c
+++ b/drivers/usb/mtu3/mtu3_host.c
@@ -18,66 +18,77 @@
#include "mtu3.h"
#include "mtu3_dr.h"
-#define PERI_WK_CTRL1 0x404
-#define UWK_CTL1_IS_C(x) (((x) & 0xf) << 26)
-#define UWK_CTL1_IS_E BIT(25)
-#define UWK_CTL1_IDDIG_C(x) (((x) & 0xf) << 11) /* cycle debounce */
-#define UWK_CTL1_IDDIG_E BIT(10) /* enable debounce */
-#define UWK_CTL1_IDDIG_P BIT(9) /* polarity */
-#define UWK_CTL1_IS_P BIT(6) /* polarity for ip sleep */
+/* mt8173 etc */
+#define PERI_WK_CTRL1 0x4
+#define WC1_IS_C(x) (((x) & 0xf) << 26) /* cycle debounce */
+#define WC1_IS_EN BIT(25)
+#define WC1_IS_P BIT(6) /* polarity for ip sleep */
+
+/* mt2712 etc */
+#define PERI_SSUSB_SPM_CTRL 0x0
+#define SSC_IP_SLEEP_EN BIT(4)
+#define SSC_SPM_INT_EN BIT(1)
+
+enum ssusb_uwk_vers {
+ SSUSB_UWK_V1 = 1,
+ SSUSB_UWK_V2,
+};
/*
* ip-sleep wakeup mode:
* all clocks can be turn off, but power domain should be kept on
*/
-static void ssusb_wakeup_ip_sleep_en(struct ssusb_mtk *ssusb)
+static void ssusb_wakeup_ip_sleep_set(struct ssusb_mtk *ssusb, bool enable)
{
- u32 tmp;
- struct regmap *pericfg = ssusb->pericfg;
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_P;
- tmp &= ~(UWK_CTL1_IS_C(0xf));
- tmp |= UWK_CTL1_IS_C(0x8);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp | UWK_CTL1_IS_E);
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- dev_dbg(ssusb->dev, "%s(): WK_CTRL1[P6,E25,C26:29]=%#x\n",
- __func__, tmp);
-}
-
-static void ssusb_wakeup_ip_sleep_dis(struct ssusb_mtk *ssusb)
-{
- u32 tmp;
-
- regmap_read(ssusb->pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_E;
- regmap_write(ssusb->pericfg, PERI_WK_CTRL1, tmp);
+ u32 reg, msk, val;
+
+ switch (ssusb->uwk_vers) {
+ case SSUSB_UWK_V1:
+ reg = ssusb->uwk_reg_base + PERI_WK_CTRL1;
+ msk = WC1_IS_EN | WC1_IS_C(0xf) | WC1_IS_P;
+ val = enable ? (WC1_IS_EN | WC1_IS_C(0x8)) : 0;
+ break;
+ case SSUSB_UWK_V2:
+ reg = ssusb->uwk_reg_base + PERI_SSUSB_SPM_CTRL;
+ msk = SSC_IP_SLEEP_EN | SSC_SPM_INT_EN;
+ val = enable ? msk : 0;
+ break;
+ default:
+ return;
+ };
+ regmap_update_bits(ssusb->uwk, reg, msk, val);
}
int ssusb_wakeup_of_property_parse(struct ssusb_mtk *ssusb,
struct device_node *dn)
{
- struct device *dev = ssusb->dev;
+ struct of_phandle_args args;
+ int ret;
- /*
- * Wakeup function is optional, so it is not an error if this property
- * does not exist, and in such case, no need to get relative
- * properties anymore.
- */
- ssusb->wakeup_en = of_property_read_bool(dn, "mediatek,enable-wakeup");
- if (!ssusb->wakeup_en)
+ /* wakeup function is optional */
+ ssusb->uwk_en = of_property_read_bool(dn, "wakeup-source");
+ if (!ssusb->uwk_en)
return 0;
- ssusb->pericfg = syscon_regmap_lookup_by_phandle(dn,
- "mediatek,syscon-wakeup");
- if (IS_ERR(ssusb->pericfg)) {
- dev_err(dev, "fail to get pericfg regs\n");
- return PTR_ERR(ssusb->pericfg);
- }
+ ret = of_parse_phandle_with_fixed_args(dn,
+ "mediatek,syscon-wakeup", 2, 0, &args);
+ if (ret)
+ return ret;
- return 0;
+ ssusb->uwk_reg_base = args.args[0];
+ ssusb->uwk_vers = args.args[1];
+ ssusb->uwk = syscon_node_to_regmap(args.np);
+ of_node_put(args.np);
+ dev_info(ssusb->dev, "uwk - reg:0x%x, version:%d\n",
+ ssusb->uwk_reg_base, ssusb->uwk_vers);
+
+ return PTR_ERR_OR_ZERO(ssusb->uwk);
+}
+
+void ssusb_wakeup_set(struct ssusb_mtk *ssusb, bool enable)
+{
+ if (ssusb->uwk_en)
+ ssusb_wakeup_ip_sleep_set(ssusb, enable);
}
static void host_ports_num_get(struct ssusb_mtk *ssusb)
@@ -235,17 +246,3 @@ void ssusb_host_exit(struct ssusb_mtk *ssusb)
of_platform_depopulate(ssusb->dev);
ssusb_host_cleanup(ssusb);
}
-
-int ssusb_wakeup_enable(struct ssusb_mtk *ssusb)
-{
- if (ssusb->wakeup_en)
- ssusb_wakeup_ip_sleep_en(ssusb);
-
- return 0;
-}
-
-void ssusb_wakeup_disable(struct ssusb_mtk *ssusb)
-{
- if (ssusb->wakeup_en)
- ssusb_wakeup_ip_sleep_dis(ssusb);
-}
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 5b2110b..628d5ce 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -282,8 +282,10 @@ static int get_ssusb_rscs(struct platform_device *pdev, struct ssusb_mtk *ssusb)
/* if host role is supported */
ret = ssusb_wakeup_of_property_parse(ssusb, node);
- if (ret)
+ if (ret) {
+ dev_err(dev, "failed to parse uwk property\n");
return ret;
+ }
/* optional property, ignore the error if it does not exist */
of_property_read_u32(node, "mediatek,u3p-dis-msk",
@@ -457,7 +459,7 @@ static int __maybe_unused mtu3_suspend(struct device *dev)
ssusb_host_disable(ssusb, true);
ssusb_phy_power_off(ssusb);
ssusb_clks_disable(ssusb);
- ssusb_wakeup_enable(ssusb);
+ ssusb_wakeup_set(ssusb, true);
return 0;
}
@@ -473,7 +475,7 @@ static int __maybe_unused mtu3_resume(struct device *dev)
if (!ssusb->is_host)
return 0;
- ssusb_wakeup_disable(ssusb);
+ ssusb_wakeup_set(ssusb, false);
ret = ssusb_clks_enable(ssusb);
if (ret)
goto clks_err;
--
1.9.1
^ permalink raw reply related
* [v2 PATCH 3/6] dt-bindings: usb: mtu3: update USB wakeup properties
From: Chunfeng Yun @ 2018-01-03 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41c6b0f2e959c07eff261060e57fd180a750071a.1514967463.git.chunfeng.yun@mediatek.com>
Add two arguments in "mediatek,syscon-wakeup" to support multi
wakeup glue layer between SSUSB and SPM, and use standard property
"wakeup-source" to replace the private "mediatek,enable-wakeup"
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
index b2271d8..d589a1e 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
@@ -42,9 +42,14 @@ Optional properties:
- enable-manual-drd : supports manual dual-role switch via debugfs; usually
used when receptacle is TYPE-A and also wants to support dual-role
mode.
- - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
- - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
- control register, it depends on "mediatek,enable-wakeup".
+ - wakeup-source: enable USB remote wakeup of host mode.
+ - mediatek,syscon-wakeup : phandle to syscon used to access the register
+ of the USB wakeup glue layer between SSUSB and SPM; it depends on
+ "wakeup-source", and has two arguments:
+ - the first one : register base address of the glue layer in syscon;
+ - the second one : hardware version of the glue layer
+ - 1 : used by mt8173 etc
+ - 2 : used by mt2712 etc
- mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
bit1 for u3port1, ... etc;
@@ -71,8 +76,8 @@ ssusb: usb at 11271000 {
vbus-supply = <&usb_p0_vbus>;
extcon = <&extcon_usb>;
dr_mode = "otg";
- mediatek,enable-wakeup;
- mediatek,syscon-wakeup = <&pericfg>;
+ wakeup-source;
+ mediatek,syscon-wakeup = <&pericfg 0x400 1>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
--
1.9.1
^ permalink raw reply related
* [v2 PATCH 4/6] usb: xhci-mtk: supports remote wakeup for mt2712 with two xHCI IPs
From: Chunfeng Yun @ 2018-01-03 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41c6b0f2e959c07eff261060e57fd180a750071a.1514967463.git.chunfeng.yun@mediatek.com>
The old way of usb wakeup only supports platform with single xHCI IP,
such as mt8173, but mt2712 has two xHCI IPs, so rebuild its flow and
supports the new glue layer of usb wakeup on mt2712 which is different
from mt8173.
Due to there is a hardware bug with the LINE STATE wakeup mode on
mt8173 which causes wakeup failure by low speed devices, and also
because IP SLEEP mode can cover all functions of LINE STATE mode,
it is unused in fact, and will not support it later, so remove it at
the same time.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/host/xhci-mtk.c | 177 +++++++++++++++-----------------------------
drivers/usb/host/xhci-mtk.h | 6 +-
2 files changed, 65 insertions(+), 118 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index b62a1d2..53187ff 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -57,26 +57,21 @@
/* u2_phy_pll register */
#define CTRL_U2_FORCE_PLL_STB BIT(28)
-#define PERI_WK_CTRL0 0x400
-#define UWK_CTR0_0P_LS_PE BIT(8) /* posedge */
-#define UWK_CTR0_0P_LS_NE BIT(7) /* negedge for 0p linestate*/
-#define UWK_CTL1_1P_LS_C(x) (((x) & 0xf) << 1)
-#define UWK_CTL1_1P_LS_E BIT(0)
-
-#define PERI_WK_CTRL1 0x404
-#define UWK_CTL1_IS_C(x) (((x) & 0xf) << 26)
-#define UWK_CTL1_IS_E BIT(25)
-#define UWK_CTL1_0P_LS_C(x) (((x) & 0xf) << 21)
-#define UWK_CTL1_0P_LS_E BIT(20)
-#define UWK_CTL1_IDDIG_C(x) (((x) & 0xf) << 11) /* cycle debounce */
-#define UWK_CTL1_IDDIG_E BIT(10) /* enable debounce */
-#define UWK_CTL1_IDDIG_P BIT(9) /* polarity */
-#define UWK_CTL1_0P_LS_P BIT(7)
-#define UWK_CTL1_IS_P BIT(6) /* polarity for ip sleep */
-
-enum ssusb_wakeup_src {
- SSUSB_WK_IP_SLEEP = 1,
- SSUSB_WK_LINE_STATE = 2,
+/* usb remote wakeup registers in syscon */
+/* mt8173 etc */
+#define PERI_WK_CTRL1 0x4
+#define WC1_IS_C(x) (((x) & 0xf) << 26) /* cycle debounce */
+#define WC1_IS_EN BIT(25)
+#define WC1_IS_P BIT(6) /* polarity for ip sleep */
+
+/* mt2712 etc */
+#define PERI_SSUSB_SPM_CTRL 0x0
+#define SSC_IP_SLEEP_EN BIT(4)
+#define SSC_SPM_INT_EN BIT(1)
+
+enum ssusb_uwk_vers {
+ SSUSB_UWK_V1 = 1,
+ SSUSB_UWK_V2,
};
static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
@@ -296,112 +291,58 @@ static void xhci_mtk_clks_disable(struct xhci_hcd_mtk *mtk)
}
/* only clocks can be turn off for ip-sleep wakeup mode */
-static void usb_wakeup_ip_sleep_en(struct xhci_hcd_mtk *mtk)
+static void usb_wakeup_ip_sleep_set(struct xhci_hcd_mtk *mtk, bool enable)
{
- u32 tmp;
- struct regmap *pericfg = mtk->pericfg;
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_P;
- tmp &= ~(UWK_CTL1_IS_C(0xf));
- tmp |= UWK_CTL1_IS_C(0x8);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp | UWK_CTL1_IS_E);
-
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- dev_dbg(mtk->dev, "%s(): WK_CTRL1[P6,E25,C26:29]=%#x\n",
- __func__, tmp);
+ u32 reg, msk, val;
+
+ switch (mtk->uwk_vers) {
+ case SSUSB_UWK_V1:
+ reg = mtk->uwk_reg_base + PERI_WK_CTRL1;
+ msk = WC1_IS_EN | WC1_IS_C(0xf) | WC1_IS_P;
+ val = enable ? (WC1_IS_EN | WC1_IS_C(0x8)) : 0;
+ break;
+ case SSUSB_UWK_V2:
+ reg = mtk->uwk_reg_base + PERI_SSUSB_SPM_CTRL;
+ msk = SSC_IP_SLEEP_EN | SSC_SPM_INT_EN;
+ val = enable ? msk : 0;
+ break;
+ default:
+ return;
+ };
+ regmap_update_bits(mtk->uwk, reg, msk, val);
}
-static void usb_wakeup_ip_sleep_dis(struct xhci_hcd_mtk *mtk)
+static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
+ struct device_node *dn)
{
- u32 tmp;
+ struct of_phandle_args args;
+ int ret;
- regmap_read(mtk->pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_IS_E;
- regmap_write(mtk->pericfg, PERI_WK_CTRL1, tmp);
-}
+ /* Wakeup function is optional */
+ mtk->uwk_en = of_property_read_bool(dn, "wakeup-source");
+ if (!mtk->uwk_en)
+ return 0;
-/*
-* for line-state wakeup mode, phy's power should not power-down
-* and only support cable plug in/out
-*/
-static void usb_wakeup_line_state_en(struct xhci_hcd_mtk *mtk)
-{
- u32 tmp;
- struct regmap *pericfg = mtk->pericfg;
-
- /* line-state of u2-port0 */
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_0P_LS_P;
- tmp &= ~(UWK_CTL1_0P_LS_C(0xf));
- tmp |= UWK_CTL1_0P_LS_C(0x8);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp);
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- regmap_write(pericfg, PERI_WK_CTRL1, tmp | UWK_CTL1_0P_LS_E);
-
- /* line-state of u2-port1 */
- regmap_read(pericfg, PERI_WK_CTRL0, &tmp);
- tmp &= ~(UWK_CTL1_1P_LS_C(0xf));
- tmp |= UWK_CTL1_1P_LS_C(0x8);
- regmap_write(pericfg, PERI_WK_CTRL0, tmp);
- regmap_write(pericfg, PERI_WK_CTRL0, tmp | UWK_CTL1_1P_LS_E);
-}
+ ret = of_parse_phandle_with_fixed_args(dn,
+ "mediatek,syscon-wakeup", 2, 0, &args);
+ if (ret)
+ return ret;
-static void usb_wakeup_line_state_dis(struct xhci_hcd_mtk *mtk)
-{
- u32 tmp;
- struct regmap *pericfg = mtk->pericfg;
-
- /* line-state of u2-port0 */
- regmap_read(pericfg, PERI_WK_CTRL1, &tmp);
- tmp &= ~UWK_CTL1_0P_LS_E;
- regmap_write(pericfg, PERI_WK_CTRL1, tmp);
-
- /* line-state of u2-port1 */
- regmap_read(pericfg, PERI_WK_CTRL0, &tmp);
- tmp &= ~UWK_CTL1_1P_LS_E;
- regmap_write(pericfg, PERI_WK_CTRL0, tmp);
-}
+ mtk->uwk_reg_base = args.args[0];
+ mtk->uwk_vers = args.args[1];
+ mtk->uwk = syscon_node_to_regmap(args.np);
+ of_node_put(args.np);
+ dev_info(mtk->dev, "uwk - reg:0x%x, version:%d\n",
+ mtk->uwk_reg_base, mtk->uwk_vers);
-static void usb_wakeup_enable(struct xhci_hcd_mtk *mtk)
-{
- if (mtk->wakeup_src == SSUSB_WK_IP_SLEEP)
- usb_wakeup_ip_sleep_en(mtk);
- else if (mtk->wakeup_src == SSUSB_WK_LINE_STATE)
- usb_wakeup_line_state_en(mtk);
-}
+ return PTR_ERR_OR_ZERO(mtk->uwk);
-static void usb_wakeup_disable(struct xhci_hcd_mtk *mtk)
-{
- if (mtk->wakeup_src == SSUSB_WK_IP_SLEEP)
- usb_wakeup_ip_sleep_dis(mtk);
- else if (mtk->wakeup_src == SSUSB_WK_LINE_STATE)
- usb_wakeup_line_state_dis(mtk);
}
-static int usb_wakeup_of_property_parse(struct xhci_hcd_mtk *mtk,
- struct device_node *dn)
+static void usb_wakeup_set(struct xhci_hcd_mtk *mtk, bool enable)
{
- struct device *dev = mtk->dev;
-
- /*
- * wakeup function is optional, so it is not an error if this property
- * does not exist, and in such case, no need to get relative
- * properties anymore.
- */
- of_property_read_u32(dn, "mediatek,wakeup-src", &mtk->wakeup_src);
- if (!mtk->wakeup_src)
- return 0;
-
- mtk->pericfg = syscon_regmap_lookup_by_phandle(dn,
- "mediatek,syscon-wakeup");
- if (IS_ERR(mtk->pericfg)) {
- dev_err(dev, "fail to get pericfg regs\n");
- return PTR_ERR(mtk->pericfg);
- }
-
- return 0;
+ if (mtk->uwk_en)
+ usb_wakeup_ip_sleep_set(mtk, enable);
}
static int xhci_mtk_setup(struct usb_hcd *hcd);
@@ -583,8 +524,10 @@ static int xhci_mtk_probe(struct platform_device *pdev)
&mtk->u3p_dis_msk);
ret = usb_wakeup_of_property_parse(mtk, node);
- if (ret)
+ if (ret) {
+ dev_err(dev, "failed to parse uwk property\n");
return ret;
+ }
mtk->num_phys = of_count_phandle_with_args(node,
"phys", "#phy-cells");
@@ -768,7 +711,7 @@ static int __maybe_unused xhci_mtk_suspend(struct device *dev)
xhci_mtk_host_disable(mtk);
xhci_mtk_phy_power_off(mtk);
xhci_mtk_clks_disable(mtk);
- usb_wakeup_enable(mtk);
+ usb_wakeup_set(mtk, true);
return 0;
}
@@ -778,7 +721,7 @@ static int __maybe_unused xhci_mtk_resume(struct device *dev)
struct usb_hcd *hcd = mtk->hcd;
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- usb_wakeup_disable(mtk);
+ usb_wakeup_set(mtk, false);
xhci_mtk_clks_enable(mtk);
xhci_mtk_phy_power_on(mtk);
xhci_mtk_host_enable(mtk);
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 6b74ce5..cc59d80 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -122,8 +122,12 @@ struct xhci_hcd_mtk {
struct regmap *pericfg;
struct phy **phys;
int num_phys;
- int wakeup_src;
bool lpm_support;
+ /* usb remote wakeup */
+ bool uwk_en;
+ struct regmap *uwk;
+ u32 uwk_reg_base;
+ u32 uwk_vers;
};
static inline struct xhci_hcd_mtk *hcd_to_mtk(struct usb_hcd *hcd)
--
1.9.1
^ permalink raw reply related
* [v2 PATCH 5/6] dt-bindings: usb: mtk-xhci: update USB wakeup properties
From: Chunfeng Yun @ 2018-01-03 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41c6b0f2e959c07eff261060e57fd180a750071a.1514967463.git.chunfeng.yun@mediatek.com>
Add two arguments in "mediatek,syscon-wakeup" to support multi
wakeup glue layer between SSUSB and SPM, and use standard property
"wakeup-source" to replace the private "mediatek,wakeup-src"
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
.../devicetree/bindings/usb/mediatek,mtk-xhci.txt | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
index 3059596..5842868 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
@@ -35,10 +35,14 @@ Required properties:
- phys : a list of phandle + phy specifier pairs
Optional properties:
- - mediatek,wakeup-src : 1: ip sleep wakeup mode; 2: line state wakeup
- mode;
- - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
- control register, it depends on "mediatek,wakeup-src".
+ - wakeup-source : enable USB remote wakeup;
+ - mediatek,syscon-wakeup : phandle to syscon used to access the register
+ of the USB wakeup glue layer between xHCI and SPM; it depends on
+ "wakeup-source", and has two arguments:
+ - the first one : register base address of the glue layer in syscon;
+ - the second one : hardware version of the glue layer
+ - 1 : used by mt8173 etc
+ - 2 : used by mt2712 etc
- mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
bit1 for u3port1, ... etc;
- vbus-supply : reference to the VBUS regulator;
@@ -64,8 +68,8 @@ usb30: usb at 11270000 {
vusb33-supply = <&mt6397_vusb_reg>;
vbus-supply = <&usb_p1_vbus>;
usb3-lpm-capable;
- mediatek,syscon-wakeup = <&pericfg>;
- mediatek,wakeup-src = <1>;
+ mediatek,syscon-wakeup = <&pericfg 0x400 1>;
+ wakeup-source;
};
2nd: dual-role mode with xHCI driver
--
1.9.1
^ permalink raw reply related
* [v2 PATCH 6/6] arm64: dts: mt8173: update properties about USB wakeup
From: Chunfeng Yun @ 2018-01-03 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41c6b0f2e959c07eff261060e57fd180a750071a.1514967463.git.chunfeng.yun@mediatek.com>
Use new binding about USB wakeup which now supports multi USB
wakeup glue layer between SSUSB and SPM.
Meanwhile remove dummy clocks of USB wakeup.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 2 +-
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 12 +++---------
2 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 1c3634f..0acba1f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -505,7 +505,7 @@
vbus-supply = <&usb_p0_vbus>;
extcon = <&extcon_usb>;
dr_mode = "otg";
- mediatek,enable-wakeup;
+ wakeup-source;
pinctrl-names = "default", "id_float", "id_ground";
pinctrl-0 = <&usb_id_pins_float>;
pinctrl-1 = <&usb_id_pins_float>;
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 26396ef..9263d9f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -731,15 +731,9 @@
<&u3port0 PHY_TYPE_USB3>,
<&u2port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
- clocks = <&topckgen CLK_TOP_USB30_SEL>,
- <&clk26m>,
- <&pericfg CLK_PERI_USB0>,
- <&pericfg CLK_PERI_USB1>;
- clock-names = "sys_ck",
- "ref_ck",
- "wakeup_deb_p0",
- "wakeup_deb_p1";
- mediatek,syscon-wakeup = <&pericfg>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>, <&clk26m>;
+ clock-names = "sys_ck", "ref_ck";
+ mediatek,syscon-wakeup = <&pericfg 0x400 1>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
--
1.9.1
^ permalink raw reply related
* [LINUX PATCH 3/4] dmaengine: xilinx_dma: Fix compilation warning
From: Appana Durga Kedareswara Rao @ 2018-01-03 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103052746.GI18649@localhost>
Hi,
<Snip>
>>> >BTW whats with LINUX tag in patches, pls drop them
>>>
>>> Ok will mention the Linux tag info in the cover letter patch from the
>>> next patch series on wards...
>>
>>Please wrap your replies within 80chars. It is very hard to read! I have reflown
>for
>>readability
>
>Sure will take care of it next time onwards...
>
>>
>>Can you explain what you mean by that info, what are you trying to convey?
>
>What I mean here is will mention the Linux kernel tag
>Information in the cover letter patch...
Oops sorry I misunderstood your comment...
In my company we have internally different projects
To differentiate b/w them we usually use LINUX prefix
By mistake I have added the LINUX prefix in this patch series
I have removed it in the v2 series...
Regards,
Kedar.
>
>Regards,
>Kedar.
>
>>
>>--
>>~Vinod
^ permalink raw reply
* [PATCH] s3mci: mark debug_regs[] as static
From: Arnd Bergmann @ 2018-01-03 9:26 UTC (permalink / raw)
To: linux-arm-kernel
The global array clashes with a newly added symbol of the same name:
drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of `debug_regs'
drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
We should fix both, this one addresses the s3cmci driver by removing
the symbol from the global namespace.
Fixes: 9bdd203b4dc8 ("s3cmci: add debugfs support for examining driver and hardware state")
Fixes: b3ec9a6736f2 ("staging: ccree: staging: ccree: replace sysfs by debugfs interface")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/mmc/host/s3cmci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 36daee1e6588..24b27e0957e7 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -1421,7 +1421,7 @@ static const struct file_operations s3cmci_fops_state = {
#define DBG_REG(_r) { .addr = S3C2410_SDI##_r, .name = #_r }
-struct s3cmci_reg {
+static struct s3cmci_reg {
unsigned short addr;
unsigned char *name;
} debug_regs[] = {
--
2.9.0
^ permalink raw reply related
* [PATCH v3 1/6] ARM: dts: imx6: Add initial support for phyCORE-i.MX 6 SOM
From: Stefan Riedmüller @ 2018-01-03 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171227021840.GV23070@X250>
On 27.12.2017 03:18, Shawn Guo wrote:
> On Fri, Dec 22, 2017 at 11:59:08AM +0100, Stefan Riedmueller wrote:
>> This patch adds basic support for PHYTEC phyCORE-i.MX 6 SOM with i.MX
>> 6Quad/Dual or i.MX 6DualLight/Solo.
>>
>> Signed-off-by: Christian Hemp <c.hemp@phytec.de>
>> Signed-off-by: Stefan Christ <s.christ@phytec.de>
>> Signed-off-by: Christoph Fritz <chf.fritz@googlemail.com>
>> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
>> ---
>> arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi | 282 ++++++++++++++++++++++
>> 1 file changed, 282 insertions(+)
>> create mode 100644 arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
>> new file mode 100644
>> index 0000000..8501ac6
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/imx6qdl-phytec-phycore-som.dtsi
>> @@ -0,0 +1,282 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (C) 2017 PHYTEC Messtechnik GmbH
>> + * Author: Christian Hemp <c.hemp@phytec.de>
>> + */
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +
>> +/ {
>> + model = "PHYTEC phyCORE-i.MX 6";
>> + compatible = "phytec,imx6qdl-pcm058", "fsl,imx6qdl";
>> +
>> + aliases {
>> + rtc1 = &da9062_rtc;
>> + rtc2 = &snvs_rtc;
>> + };
>> +
>> + /*
>> + * Set the minimum memory size here and
>> + * let the bootloader set the real size.
>> + */
>> + memory at 10000000 {
>> + device_type = "memory";
>> + reg = <0x10000000 0x8000000>;
>> + };
>> +
>> + gpio_leds_som: somleds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_gpioleds_som>;
>> +
>> + som_green {
> We generally use hyphen rather than underscore in node name. Also I
> would suggest to have 'led' in the name to tell what the device is,
> maybe 'led-green'?
Hi Shawn,
OK. I'll change it to som-led-green.
>> + label = "phycore:green";
>> + gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
>> + linux,default-trigger = "heartbeat";
>> + };
>> + };
>> +};
>> +
>> +&ecspi1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ecspi1>;
>> + cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>;
>> + status = "okay";
>> +
>> + flash: flash at 0 {
> While it's all good to name the node in a general way, the label can be
> specific, like:
>
> m25p80: flash at 0 {
> ...
> }
>
> Even better, if the label is not really needed, just drop it.
We use the label to cover our possible module variants where some can have
the flash not populated. We do this by only enabling the required nodes
in the dts files. Thats why I would like to keep the label and if possible
keep it generic.
>> + compatible = "m25p80";
>> + spi-max-frequency = <20000000>;
>> + reg = <0>;
>> + status = "disabled";
>> + };
>> +};
>> +
>> +&fec {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_enet>;
>> + phy-handle = <ðphy>;
>> + phy-mode = "rgmii";
>> + phy-supply = <&vdd_eth_io>;
>> + phy-reset-gpios = <&gpio1 14 GPIO_ACTIVE_LOW>;
>> + status = "disabled";
>> +
>> + mdio {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + ethphy: ethernet-phy at 3 {
>> + reg = <3>;
>> + txc-skew-ps = <1680>;
>> + rxc-skew-ps = <1860>;
>> + };
>> + };
>> +};
>> +
>> +&gpmi {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_gpmi_nand>;
>> + nand-on-flash-bbt;
>> + status = "disabled";
>> +};
>> +
>> +&i2c3 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_i2c3>;
>> + clock-frequency = <400000>;
>> + status = "okay";
>> +
>> + eeprom: eeprom at 50 {
> Is the label used at all?
Actually it's supposed to, but I forget to take it to the dts file.
I would add status = "disabled" here and status = "okay" in the dts files
of this patchset if it is okay to keep the label.
>> + compatible = "atmel,24c32";
>> + reg = <0x50>;
>> + };
>> +
>> + pmic0: pmic at 58 {
> Ditto
I'll drop this label.
>
>> + compatible = "dlg,da9062";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_pmic>;
>> + reg = <0x58>;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
>> + interrupt-controller;
>> +
>> + da9062_rtc: rtc {
>> + compatible = "dlg,da9062-rtc";
>> + };
>> +
>> + da9062_wdt: watchdog {
> Ditto
I'll drop this label.
>> + compatible = "dlg,da9062-watchdog";
>> + };
>> +
>> + da9062_reg: regulators {
> Ditto
>
> Shawn
I'll drop this label.
Thanks,
Stefan
>> + vdd_arm: buck1 {
>> + regulator-name = "vdd_arm";
>> + regulator-min-microvolt = <730000>;
>> + regulator-max-microvolt = <1380000>;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_soc: buck2 {
>> + regulator-name = "vdd_soc";
>> + regulator-min-microvolt = <730000>;
>> + regulator-max-microvolt = <1380000>;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_ddr3_1p5: buck3 {
>> + regulator-name = "vdd_ddr3";
>> + regulator-min-microvolt = <1500000>;
>> + regulator-max-microvolt = <1500000>;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_eth_1p2: buck4 {
>> + regulator-name = "vdd_eth";
>> + regulator-min-microvolt = <1200000>;
>> + regulator-max-microvolt = <1200000>;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_snvs: ldo1 {
>> + regulator-name = "vdd_snvs";
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_high: ldo2 {
>> + regulator-name = "vdd_high";
>> + regulator-min-microvolt = <3000000>;
>> + regulator-max-microvolt = <3000000>;
>> + regulator-always-on;
>> + };
>> +
>> + vdd_eth_io: ldo3 {
>> + regulator-name = "vdd_eth_io";
>> + regulator-min-microvolt = <2500000>;
>> + regulator-max-microvolt = <2500000>;
>> + };
>> +
>> + vdd_emmc_1p8: ldo4 {
>> + regulator-name = "vdd_emmc";
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + };
>> + };
>> + };
>> +};
>> +
>> +®_arm {
>> + vin-supply = <&vdd_arm>;
>> +};
>> +
>> +®_pu {
>> + vin-supply = <&vdd_soc>;
>> +};
>> +
>> +®_soc {
>> + vin-supply = <&vdd_soc>;
>> +};
>> +
>> +&snvs_poweroff {
>> + status = "okay";
>> +};
>> +
>> +&usdhc4 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_usdhc4>;
>> + bus-width = <8>;
>> + non-removable;
>> + vmmc-supply = <&vdd_emmc_1p8>;
>> + status = "disabled";
>> +};
>> +
>> +&iomuxc {
>> + pinctrl_enet: enetgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
>> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
>> + MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
>> + MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
>> + MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
>> + MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
>> + MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
>> + MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
>> + MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
>> + MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
>> + MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
>> + MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
>> + MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
>> + MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
>> + MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
>> + MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
>> + MX6QDL_PAD_SD2_DAT1__GPIO1_IO14 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_gpioleds_som: gpioledssomgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_GPIO_4__GPIO1_IO04 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_gpmi_nand: gpminandgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_NANDF_CLE__NAND_CLE 0xb0b1
>> + MX6QDL_PAD_NANDF_ALE__NAND_ALE 0xb0b1
>> + MX6QDL_PAD_NANDF_WP_B__NAND_WP_B 0xb0b1
>> + MX6QDL_PAD_NANDF_RB0__NAND_READY_B 0xb000
>> + MX6QDL_PAD_NANDF_CS0__NAND_CE0_B 0xb0b1
>> + MX6QDL_PAD_NANDF_CS1__NAND_CE1_B 0xb0b1
>> + MX6QDL_PAD_NANDF_CS2__NAND_CE2_B 0xb0b1
>> + MX6QDL_PAD_NANDF_CS3__NAND_CE3_B 0xb0b1
>> + MX6QDL_PAD_SD4_CMD__NAND_RE_B 0xb0b1
>> + MX6QDL_PAD_SD4_CLK__NAND_WE_B 0xb0b1
>> + MX6QDL_PAD_NANDF_D0__NAND_DATA00 0xb0b1
>> + MX6QDL_PAD_NANDF_D1__NAND_DATA01 0xb0b1
>> + MX6QDL_PAD_NANDF_D2__NAND_DATA02 0xb0b1
>> + MX6QDL_PAD_NANDF_D3__NAND_DATA03 0xb0b1
>> + MX6QDL_PAD_NANDF_D4__NAND_DATA04 0xb0b1
>> + MX6QDL_PAD_NANDF_D5__NAND_DATA05 0xb0b1
>> + MX6QDL_PAD_NANDF_D6__NAND_DATA06 0xb0b1
>> + MX6QDL_PAD_NANDF_D7__NAND_DATA07 0xb0b1
>> + MX6QDL_PAD_SD4_DAT0__NAND_DQS 0x00b1
>> + >;
>> + };
>> +
>> + pinctrl_i2c3: i2c3grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_GPIO_6__I2C3_SDA 0x4001b8b1
>> + MX6QDL_PAD_GPIO_5__I2C3_SCL 0x4001b8b1
>> + >;
>> + };
>> +
>> + pinctrl_ecspi1: ecspi1grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_EIM_D16__ECSPI1_SCLK 0x100b1
>> + MX6QDL_PAD_EIM_D17__ECSPI1_MISO 0x100b1
>> + MX6QDL_PAD_EIM_D18__ECSPI1_MOSI 0x100b1
>> + MX6QDL_PAD_EIM_D19__GPIO3_IO19 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_pmic: pmicgrp {
>> + fsl,pins = <
>> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
>> + >;
>> + };
>> +
>> + pinctrl_usdhc4: usdhc4grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD4_CMD__SD4_CMD 0x17059
>> + MX6QDL_PAD_SD4_CLK__SD4_CLK 0x10059
>> + MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
>> + MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
>> + MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
>> + MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
>> + MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
>> + MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
>> + MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
>> + MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
>> + >;
>> + };
>> +};
>> --
>> 2.7.4
>>
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
From: Ganapatrao Kulkarni @ 2018-01-03 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <410d1cf1-c2f4-53a9-77e5-24323a960739@arm.com>
Hi Marc,
On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>> When an interrupt is moved across node collections on ThunderX2
>
> node collections?
ok, i will rephrase it.
i was intended to say cross NUMA node collection/cpu affinity change.
>
>> multi Socket platform, an interrupt stops routed to new collection
>> and results in loss of interrupts.
>>
>> Adding workaround to issue INV after MOVI for cross-node collection
>> move to flush out the cached entry.
>>
>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>> ---
>> Documentation/arm64/silicon-errata.txt | 1 +
>> arch/arm64/Kconfig | 11 +++++++++++
>> drivers/irqchip/irq-gic-v3-its.c | 24 ++++++++++++++++++++++++
>> 3 files changed, 36 insertions(+)
>>
>> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
>> index fc1c884..fb27cb5 100644
>> --- a/Documentation/arm64/silicon-errata.txt
>> +++ b/Documentation/arm64/silicon-errata.txt
>> @@ -63,6 +63,7 @@ stable kernels.
>> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
>> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
>> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
>> +| Cavium | ThunderX2 ITS | #174 | CAVIUM_ERRATUM_174 |
>> | Cavium | ThunderX2 SMMUv3| #74 | N/A |
>> | Cavium | ThunderX2 SMMUv3| #126 | N/A |
>> | | | | |
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index c9a7e9e..71a7e30 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>
>> If unsure, say Y.
>>
>> +config CAVIUM_ERRATUM_174
>> + bool "Cavium ThunderX2 erratum 174"
>> + depends on NUMA
>
> Why? This system will be affected no matter whether NUMA is selected or not.
it does not makes sense to enable on non-NUMA/single socket platforms.
By default NUMA is enabled on ThunderX2 dual socket platforms.
>
>> + default y
>> + help
>> + LPI stops routed to redistributors after inter node collection
>> + move in ITS. Enable workaround to invalidate ITS entry after
>> + inter-node collection move.
>
> That's a very terse description. Nobody knows what an LPI, a
> redistributor or a collection is. Please explain what the erratum is in
> layman's terms (Cavium ThunderX2 systems may loose interrupts on
> affinity change) so that people understand whether or not they are affected.
ok, i will rephrase it in next version.
>
>> +
>> + If unsure, say Y.
>> +
>> config CAVIUM_ERRATUM_22375
>> bool "Cavium erratum 22375, 24313"
>> default y
>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>> index 06f025f..d8b9c96 100644
>> --- a/drivers/irqchip/irq-gic-v3-its.c
>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>> @@ -46,6 +46,7 @@
>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>>
>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>
>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>> if (cpu != its_dev->event_map.col_map[id]) {
>> target_col = &its_dev->its->collections[cpu];
>> its_send_movi(its_dev, target_col, id);
>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
>> + /* Issue INV for cross node collection move. */
>> + if (cpu_to_node(cpu) !=
>> + cpu_to_node(its_dev->event_map.col_map[id]))
>> + its_send_inv(its_dev, id);
>> + }
>
> What happens if an interrupt happens after the MOV, but before the INV?
there can be drop, if interrupt happens before INV, however, it is
highly unlikely that we will hit the issue since MOVI and INV are
executed back to back. this workaround fixed issue seen on couple of
IOs.
>
>> its_dev->event_map.col_map[id] = cpu;
>> irq_data_update_effective_affinity(d, cpumask_of(cpu));
>> }
>> @@ -2904,6 +2911,15 @@ static int its_force_quiescent(void __iomem *base)
>> }
>> }
>>
>> +static bool __maybe_unused its_enable_quirk_cavium_174(void *data)
>> +{
>> + struct its_node *its = data;
>> +
>> + its->flags |= ITS_FLAGS_WORKAROUND_CAVIUM_174;
>> +
>> + return true;
>> +}
>> +
>> static bool __maybe_unused its_enable_quirk_cavium_22375(void *data)
>> {
>> struct its_node *its = data;
>> @@ -3031,6 +3047,14 @@ static const struct gic_quirk its_quirks[] = {
>> .init = its_enable_quirk_hip07_161600802,
>> },
>> #endif
>> +#ifdef CONFIG_CAVIUM_ERRATUM_174
>> + {
>> + .desc = "ITS: Cavium ThunderX2 erratum 174",
>> + .iidr = 0x13f, /* ThunderX2 pass A1/A2/B0 */
>
> Do all 3 revisions have the same IIDR?
yes.
>
>> + .mask = 0xffffffff,
>> + .init = its_enable_quirk_cavium_174,
>> + },
>> +#endif
>> {
>> }
>> };
>>
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
thanks
Ganapat
^ permalink raw reply
* [PATCH v3 01/34] clk_ops: change round_rate() to return unsigned long
From: Mauro Carvalho Chehab @ 2018-01-03 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514835793-1104-2-git-send-email-pure.logic@nexus-software.ie>
Em Mon, 1 Jan 2018 19:42:40 +0000
Bryan O'Donoghue <pure.logic@nexus-software.ie> escreveu:
> Right now it is not possible to return a value larger than LONG_MAX on 32
> bit systems. You can pass a rate of ULONG_MAX but can't return anything
> past LONG_MAX due to the fact both the rounded_rate and negative error
> codes are represented in the return value of round_rate().
>
> Most implementations either return zero on error or don't return error
> codes at all. A minority of implementations do return a negative number -
> typically -EINVAL or -ENODEV.
>
> At the higher level then callers of round_rate() typically and rightly
> check for a value of <= 0.
>
> It is possible then to convert round_rate() to an unsigned long return
> value and change error code indication for the minority from -ERRORCODE to
> a simple 0.
>
> This patch is the first step in making it possible to scale round_rate past
> LONG_MAX, later patches will change the previously mentioned minority of
> round_rate() implementations to return zero only on error if those
> implementations currently return a negative error number. Implementations
> that do not return an error code of < 0 will be left as-is.
>
> drivers/media/platform/omap3isp/isp.c | 4 ++--
Acked-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Thanks,
Mauro
^ permalink raw reply
* [PATCH 3/4] bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
From: Linus Walleij @ 2018-01-03 10:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bcac00c71b29c359b59053a30d817a8f17d6731d.1514898134.git.baruch@tkos.co.il>
On Tue, Jan 2, 2018 at 2:19 PM, Baruch Siach <baruch@tkos.co.il> wrote:
> +config GPIO_BCM_EXP
> + bool "Broadcom Exp GPIO"
> + depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
> + help
> + Turn on GPIO support for Broadcom chips using the firmware mailbox
> + to communicate with VideoCore on BCM283x chips.
Should this be
default RASPBERRYPI_FIRMWARE
So it is always available if the firmware interface is there?
> +#include <linux/err.h>
> +#include <linux/gpio.h>
Just use
#include <linux/driver.h>
> +#define MODULE_NAME "brcmexp-gpio"
> +#define NUM_GPIO 8
> +
> +struct brcmexp_gpio {
> + struct gpio_chip gc;
> + struct device *dev;
> + struct rpi_firmware *fw;
> +};
> +
> +struct gpio_set_config {
> + u32 gpio, direction, polarity, term_en, term_pull_up, state;
> +};
> +
> +struct gpio_get_config {
> + u32 gpio, direction, polarity, term_en, term_pull_up;
> +};
Seems to support some pin control stuff, hm?
The pull ups seems unused though so OK.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
From: Marc Zyngier @ 2018-01-03 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKTKpr444LU_RuDYoYydSht2JsLHdViibOKLA6ykgGL-_FKtCQ@mail.gmail.com>
On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
> Hi Marc,
>
> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>>> When an interrupt is moved across node collections on ThunderX2
>>
>> node collections?
>
> ok, i will rephrase it.
> i was intended to say cross NUMA node collection/cpu affinity change.
>
>>
>>> multi Socket platform, an interrupt stops routed to new collection
>>> and results in loss of interrupts.
>>>
>>> Adding workaround to issue INV after MOVI for cross-node collection
>>> move to flush out the cached entry.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>>> ---
>>> Documentation/arm64/silicon-errata.txt | 1 +
>>> arch/arm64/Kconfig | 11 +++++++++++
>>> drivers/irqchip/irq-gic-v3-its.c | 24 ++++++++++++++++++++++++
>>> 3 files changed, 36 insertions(+)
>>>
>>> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
>>> index fc1c884..fb27cb5 100644
>>> --- a/Documentation/arm64/silicon-errata.txt
>>> +++ b/Documentation/arm64/silicon-errata.txt
>>> @@ -63,6 +63,7 @@ stable kernels.
>>> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
>>> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
>>> +| Cavium | ThunderX2 ITS | #174 | CAVIUM_ERRATUM_174 |
>>> | Cavium | ThunderX2 SMMUv3| #74 | N/A |
>>> | Cavium | ThunderX2 SMMUv3| #126 | N/A |
>>> | | | | |
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index c9a7e9e..71a7e30 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>>
>>> If unsure, say Y.
>>>
>>> +config CAVIUM_ERRATUM_174
>>> + bool "Cavium ThunderX2 erratum 174"
>>> + depends on NUMA
>>
>> Why? This system will be affected no matter whether NUMA is selected or not.
>
> it does not makes sense to enable on non-NUMA/single socket platforms.
> By default NUMA is enabled on ThunderX2 dual socket platforms.
<quote>
config ARCH_THUNDER2
bool "Cavium ThunderX2 Server Processors"
select GPIOLIB
help
This enables support for Cavium's ThunderX2 CN99XX family of
server processors.
</quote>
Do you see any NUMA here? I can perfectly compile a kernel with both
sockets, and not using NUMA. NUMA has to do with memory, and not interrupts.
>
>>
>>> + default y
>>> + help
>>> + LPI stops routed to redistributors after inter node collection
>>> + move in ITS. Enable workaround to invalidate ITS entry after
>>> + inter-node collection move.
>>
>> That's a very terse description. Nobody knows what an LPI, a
>> redistributor or a collection is. Please explain what the erratum is in
>> layman's terms (Cavium ThunderX2 systems may loose interrupts on
>> affinity change) so that people understand whether or not they are affected.
>
> ok, i will rephrase it in next version.
>>
>>> +
>>> + If unsure, say Y.
>>> +
>>> config CAVIUM_ERRATUM_22375
>>> bool "Cavium erratum 22375, 24313"
>>> default y
>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>> index 06f025f..d8b9c96 100644
>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>> @@ -46,6 +46,7 @@
>>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
>>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>>>
>>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>>
>>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>>> if (cpu != its_dev->event_map.col_map[id]) {
>>> target_col = &its_dev->its->collections[cpu];
>>> its_send_movi(its_dev, target_col, id);
>>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
>>> + /* Issue INV for cross node collection move. */
>>> + if (cpu_to_node(cpu) !=
>>> + cpu_to_node(its_dev->event_map.col_map[id]))
>>> + its_send_inv(its_dev, id);
>>> + }
>>
>> What happens if an interrupt happens after the MOV, but before the INV?
>
> there can be drop, if interrupt happens before INV, however, it is
> highly unlikely that we will hit the issue since MOVI and INV are
> executed back to back. this workaround fixed issue seen on couple of
> IOs.
Really? So this doesn't fix anything, and the device may just wait
forever for the CPU to service an LPI that was never delivered. I'm
sorry, but that's not an acceptable workaround.
I can see two solutions:
1) you inject an interrupt after the INV as you may have lost at least one
2) you restrict the affinity of LPIs to a single socket
(1) will generate spurious interrupts, but will be safe. (2) will result
in an unbalanced system. Pick your poison...
You may be able to achieve something by disabling the LPI before
performing the MOVI/INV sequence, and reenable it afterwards, but only
you can tell if this could work with your HW.
In any case, I won't take a workaround that leaves any chance of loosing
an interrupt.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] soc: renesas: rcar-sysc: Mark rcar_sysc_matches[] __initconst
From: Simon Horman @ 2018-01-03 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXGVM1qkBNPDN_rrN5mby-iGy8s8VgEz_KmYswmufVohQ@mail.gmail.com>
On Tue, Jan 02, 2018 at 03:50:19PM +0100, Geert Uytterhoeven wrote:
> Hi Simon,
>
> On Wed, Dec 20, 2017 at 9:25 AM, Simon Horman <horms@verge.net.au> wrote:
> > On Tue, Dec 19, 2017 at 04:54:44PM +0100, Geert Uytterhoeven wrote:
...
> Thank you.
> Please note this is a patch intended for your soc-for-v4.16 branch ;-)
Thanks, I had missed that important detail.
I have applied it to that branch.
^ permalink raw reply
* [PATCH] nokia N9: Add support for magnetometer and touchscreen
From: Pavel Machek @ 2018-01-03 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102172720.ghtez4d3d2fgcmj6@earth.universe>
On Tue 2018-01-02 18:27:20, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jan 02, 2018 at 02:17:22PM +0100, Pavel Machek wrote:
> > This adds dts support for magnetometer and touchscreen on Nokia N9.
>
> I think it makes sense to have this splitted.
Creating more work for everyone for little gain? Meh.
> > diff --git a/arch/arm/boot/dts/omap3-n9.dts b/arch/arm/boot/dts/omap3-n9.dts
> > index 39e35f8..57a6679 100644
> > --- a/arch/arm/boot/dts/omap3-n9.dts
> > +++ b/arch/arm/boot/dts/omap3-n9.dts
> > @@ -36,6 +57,22 @@
> > };
> > };
> > };
> > +
> > + touch at 4b {
>
> touchscreen@
Ok.
> > + compatible = "atmel,maxtouch";
> > + reg = <0x4b>;
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <29 2>; /* gpio_61, IRQF_TRIGGER_FALLING*/
>
> reset-gpios = <&gpio3 17 GPIO_ACTIVE_SOMETHING>;
>
> > + vdd-supply = <&vio>;
> > + avdd-supply = <&vaux1>;
>
> Those two are not mentioned in the binding and not supported by the
> driver as far as I can see?
Driver will need to be fixed, AFAICT :-(.
> Touchscreen with the same settings is required for n950, so it
> should be in the shared n950 + n9 file.
In future, settings will be different for n9/n950: calibration matrix
is different as panel is rotated in different way. Still it probably
makes sense to share. Ok.
> > +&i2c3 {
> > + ak8975 at 0f {
> > + compatible = "asahi-kasei,ak8975";
> > + reg = <0x0f>;
> > + };
> > };
>
> Looking at the N9 board file this is missing a rotation matrix. This
> is supported by the binding:
>
> Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
Do you have an idea how the rotation matrix should look like? I don't
currently have an userland software that could calibrate and test the
sensor, so I'd prefer to merge basic binding now and do calibration
later.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/f2e1f8bd/attachment.sig>
^ permalink raw reply
* [bpf-next V4 PATCH 09/14] thunderx: setup xdp_rxq_info
From: Jesper Dangaard Brouer @ 2018-01-03 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <151497504273.18176.10177133999720101758.stgit@firesoul>
This driver uses a bool scheme for "enable"/"disable" when setting up
different resources. Thus, the hook points for xdp_rxq_info is done
in the same function call nicvf_rcv_queue_config(). This is activated
through enable/disable via nicvf_config_data_transfer(), which is tied
into nicvf_stop()/nicvf_open().
Extending driver packet handler call-path nicvf_rcv_pkt_handler() with
a pointer to the given struct rcv_queue, in-order to access the
xdp_rxq_info data area (in nicvf_xdp_rx()).
V2: Driver have no proper error path for failed XDP RX-queue info reg,
as nicvf_rcv_queue_config is a void function.
Cc: linux-arm-kernel at lists.infradead.org
Cc: Sunil Goutham <sgoutham@cavium.com>
Cc: Robert Richter <rric@kernel.org>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 11 +++++++----
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 4 ++++
drivers/net/ethernet/cavium/thunder/nicvf_queues.h | 2 ++
3 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index 52b3a6044f85..21618d0d694f 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -521,7 +521,7 @@ static void nicvf_unmap_page(struct nicvf *nic, struct page *page, u64 dma_addr)
static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
struct cqe_rx_t *cqe_rx, struct snd_queue *sq,
- struct sk_buff **skb)
+ struct rcv_queue *rq, struct sk_buff **skb)
{
struct xdp_buff xdp;
struct page *page;
@@ -545,6 +545,7 @@ static inline bool nicvf_xdp_rx(struct nicvf *nic, struct bpf_prog *prog,
xdp.data = (void *)cpu_addr;
xdp_set_data_meta_invalid(&xdp);
xdp.data_end = xdp.data + len;
+ xdp.rxq = &rq->xdp_rxq;
orig_data = xdp.data;
rcu_read_lock();
@@ -698,7 +699,8 @@ static inline void nicvf_set_rxhash(struct net_device *netdev,
static void nicvf_rcv_pkt_handler(struct net_device *netdev,
struct napi_struct *napi,
- struct cqe_rx_t *cqe_rx, struct snd_queue *sq)
+ struct cqe_rx_t *cqe_rx,
+ struct snd_queue *sq, struct rcv_queue *rq)
{
struct sk_buff *skb = NULL;
struct nicvf *nic = netdev_priv(netdev);
@@ -724,7 +726,7 @@ static void nicvf_rcv_pkt_handler(struct net_device *netdev,
/* For XDP, ignore pkts spanning multiple pages */
if (nic->xdp_prog && (cqe_rx->rb_cnt == 1)) {
/* Packet consumed by XDP */
- if (nicvf_xdp_rx(snic, nic->xdp_prog, cqe_rx, sq, &skb))
+ if (nicvf_xdp_rx(snic, nic->xdp_prog, cqe_rx, sq, rq, &skb))
return;
} else {
skb = nicvf_get_rcv_skb(snic, cqe_rx,
@@ -781,6 +783,7 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
struct cqe_rx_t *cq_desc;
struct netdev_queue *txq;
struct snd_queue *sq = &qs->sq[cq_idx];
+ struct rcv_queue *rq = &qs->rq[cq_idx];
unsigned int tx_pkts = 0, tx_bytes = 0, txq_idx;
spin_lock_bh(&cq->lock);
@@ -811,7 +814,7 @@ static int nicvf_cq_intr_handler(struct net_device *netdev, u8 cq_idx,
switch (cq_desc->cqe_type) {
case CQE_TYPE_RX:
- nicvf_rcv_pkt_handler(netdev, napi, cq_desc, sq);
+ nicvf_rcv_pkt_handler(netdev, napi, cq_desc, sq, rq);
work_done++;
break;
case CQE_TYPE_SEND:
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
index f38ea349aa00..14e62c6ac342 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c
@@ -760,6 +760,7 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
if (!rq->enable) {
nicvf_reclaim_rcv_queue(nic, qs, qidx);
+ xdp_rxq_info_unreg(&rq->xdp_rxq);
return;
}
@@ -772,6 +773,9 @@ static void nicvf_rcv_queue_config(struct nicvf *nic, struct queue_set *qs,
/* all writes of RBDR data to be loaded into L2 Cache as well*/
rq->caching = 1;
+ /* Driver have no proper error path for failed XDP RX-queue info reg */
+ WARN_ON(xdp_rxq_info_reg(&rq->xdp_rxq, nic->netdev, qidx) < 0);
+
/* Send a mailbox msg to PF to config RQ */
mbx.rq.msg = NIC_MBOX_MSG_RQ_CFG;
mbx.rq.qs_num = qs->vnic_id;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
index 178ab6e8e3c5..7d1e4e2aaad0 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.h
@@ -12,6 +12,7 @@
#include <linux/netdevice.h>
#include <linux/iommu.h>
#include <linux/bpf.h>
+#include <net/xdp.h>
#include "q_struct.h"
#define MAX_QUEUE_SET 128
@@ -255,6 +256,7 @@ struct rcv_queue {
u8 start_qs_rbdr_idx; /* RBDR idx in the above QS */
u8 caching;
struct rx_tx_queue_stats stats;
+ struct xdp_rxq_info xdp_rxq;
} ____cacheline_aligned_in_smp;
struct cmp_queue {
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Simon Horman @ 2018-01-03 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102093823.o6km656xdef7jnwf@verge.net.au>
On Tue, Jan 02, 2018 at 10:38:24AM +0100, Simon Horman wrote:
> Hi Vladimir,
>
> Happy New Year!
>
> On Fri, Dec 22, 2017 at 12:22:09PM +0200, Vladimir Zapolskiy wrote:
> > Hi Simon,
> >
> > On 12/22/2017 10:40 AM, Simon Horman wrote:
> > > On Fri, Dec 22, 2017 at 09:32:03AM +0100, Simon Horman wrote:
> > >> On Thu, Dec 21, 2017 at 05:18:58PM +0200, Vladimir Zapolskiy wrote:
> > >>> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> > >>>
> > >>> The present change is a bug fix for AVB link iteratively up/down.
> > >>>
> > >>> Steps to reproduce:
> > >>> - start AVB TX stream (Using aplay via MSE),
> > >>> - disconnect+reconnect the eth cable,
> > >>> - after a reconnection the eth connection goes iteratively up/down
> > >>> without user interaction,
> > >>> - this may heal after some seconds or even stay for minutes.
> > >>>
> > >>> As the documentation specifies, the "renesas,no-ether-link" option
> > >>> should be used when a board does not provide a proper AVB_LINK signal.
> > >>> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> > >>> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
> > >>>
> > >>> Choosing to keep or remove the "renesas,no-ether-link" option will
> > >>> have impact on the code flow in the following ways:
> > >>> - keeping this option enabled may lead to unexpected behavior since
> > >>> the RX & TX are enabled/disabled directly from adjust_link function
> > >>> without any HW interrogation,
> > >>> - removing this option, the RX & TX will only be enabled/disabled after
> > >>> HW interrogation. The HW check is made through the LMON pin in PSR
> > >>> register which specifies AVB_LINK signal value (0 - at low level;
> > >>> 1 - at high level).
> > >>>
> > >>> In conclusion, the present change is also a safety improvement because
> > >>> it removes the "renesas,no-ether-link" option leading to a proper way
> > >>> of detecting the link state based on HW interrogation and not on
> > >>> software heuristic.
> > >>>
> > >>> Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
> > >>
> > >> The above shuffles the code around but does not introduce the problem
> > >> as far as I can see. Instead I think we should use:
> > >>
> > >> Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
> > >> Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
> > >>
> > >>> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> > >>> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> > >
> > > I have applied this a fix for v4.15 with the updated Fixes tags above.
> > >
> >
> > thank you, I was unsure if you expected to get changes which can be used
> > as a base without patch application conflicts (my done choice) or changes,
> > which originally intorduced the bug, but formally require slightly
> > different fixes due to code changes in the middle. If it would be needed,
> > hopefully linux-stable maintainers can resolve the trivial conflicts.
> >
> > Also you may find this information from the cover letter useful,
> > someone may want to check the relevant board schematics and send
> > similar fixes (if applicable after schematics review and testing):
> >
> > Note that DTS files for V3M Starter Kit, Draak and Eagle boards
> > contain the same property, the files are untouched due to unavailable
> > schematics to verify if the fix applies to these boards as well.
>
> Thanks. I took a quick look and my findings so far are:
>
> * Eagle: This approach seems applicable as AVB_LINK appears to be hooked up
> * V3M Starter Kit: This approach seems applicable as AVB0_LINK appears to be
> hooked up
> * Draak: I don't seem to be able to locate documentation at this time
I have now obtained Draak documentation. It seems that this approach is
applicable to that board too as AVB0_LINK appears to be hooked up.
> Are you interested in creating follow-up patches?
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Graeme Gregory @ 2018-01-03 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8_6y3dU81ZS4WWCfpRZkfjGo_+_K--e3go_3_xXwBErQ@mail.gmail.com>
On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
> On 18 December 2017 at 10:17, Marcin Wojtas <mw@semihalf.com> wrote:
> > Hi,
> >
> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
> > First three patches introduce fwnode helpers for obtaining PHY
> > information from nodes and also MDIO fwnode API for registering
> > the bus with its PHY/devices.
> >
> > Following patches update code of the mvmdio and mvpp2 drivers
> > to support ACPI tables handling. The latter is done in 4 steps,
> > as can be seen in the commits. For the details, please
> > refer to the commit messages.
> >
> > Drivers operation was tested on top of the net-next branch
> > with both DT and ACPI. Although for compatibility reasons
> > with older platforms, the mvmdio driver keeps using
> > of_ MDIO registering, new fwnode_ one proved to fully work
> > with DT as well (tested on MacchiatoBin board).
> >
> > mvpp2/mvmdio driver can work with the ACPI representation, as exposed
> > on a public branch:
> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> > It was compiled together with the most recent Tianocore EDK2 revision.
> > Please refer to the firmware build instruction on MacchiatoBin board:
> > http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
> >
> > Above support configures 1G to use its PHY normally. 10G can work now
> > only with the link interrupt mode. Somehow reading of the
> > string property in fwnode_mdiobus_child_is_phy works only with
> > DT and cannot cope with 10G PHY nodes as in:
> > https://pastebin.com/3JnYpU0A
> >
> > Above root cause will be further checked. In the meantime I will
> > appreciate any comments or remarks for the kernel patches.
> >
>
> Hi Marcin,
>
> I have added linux-acpi and Graeme to cc. I think it makes sense to
> discuss the way you describe the device topology before looking at the
> patches in more detail.
>
> In particular, I would like to request feedback on the use of
> [redundant] 'reg' properties and the use of _DSD + compatible to
> describe PHYs. Usually, we try to avoid this, given that it is
> essentially a ACPI encapsulated DT dialect that is difficult to
> support in drivers unless they are based on DT to begin with. Also,
> non-standard _DSD properties require a vendor prefix, it is not
> freeform.
>
> For reference, the ACPI description is here (starting at line 175)
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/72d5ac23b20dd74d479daa5e40ba443264b31261/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl
>
So the representation of PHY's with _DSD was kind of formalised here
http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
This is already in use in the kernel, and that DSDT seems to be along the same
lines. So seems ok in that manner.
The "reg", 0 property seems a little odd, it would probably make more
sense to check for the lack of ranges passed in in ACPI manner _CRS.
Graeme
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/373e76fd/attachment.sig>
^ permalink raw reply
* [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support
From: Marcin Wojtas @ 2018-01-03 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103110048.GA21230@xora-haswell>
Hi Graeme,
2018-01-03 12:00 GMT+01:00 Graeme Gregory <graeme.gregory@linaro.org>:
> On Mon, Dec 18, 2017 at 10:40:31AM +0100, Ard Biesheuvel wrote:
>> On 18 December 2017 at 10:17, Marcin Wojtas <mw@semihalf.com> wrote:
>> > Hi,
>> >
>> > This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
>> > First three patches introduce fwnode helpers for obtaining PHY
>> > information from nodes and also MDIO fwnode API for registering
>> > the bus with its PHY/devices.
>> >
>> > Following patches update code of the mvmdio and mvpp2 drivers
>> > to support ACPI tables handling. The latter is done in 4 steps,
>> > as can be seen in the commits. For the details, please
>> > refer to the commit messages.
>> >
>> > Drivers operation was tested on top of the net-next branch
>> > with both DT and ACPI. Although for compatibility reasons
>> > with older platforms, the mvmdio driver keeps using
>> > of_ MDIO registering, new fwnode_ one proved to fully work
>> > with DT as well (tested on MacchiatoBin board).
>> >
>> > mvpp2/mvmdio driver can work with the ACPI representation, as exposed
>> > on a public branch:
>> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
>> > It was compiled together with the most recent Tianocore EDK2 revision.
>> > Please refer to the firmware build instruction on MacchiatoBin board:
>> > http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
>> >
>> > Above support configures 1G to use its PHY normally. 10G can work now
>> > only with the link interrupt mode. Somehow reading of the
>> > string property in fwnode_mdiobus_child_is_phy works only with
>> > DT and cannot cope with 10G PHY nodes as in:
>> > https://pastebin.com/3JnYpU0A
>> >
>> > Above root cause will be further checked. In the meantime I will
>> > appreciate any comments or remarks for the kernel patches.
>> >
>>
>> Hi Marcin,
>>
>> I have added linux-acpi and Graeme to cc. I think it makes sense to
>> discuss the way you describe the device topology before looking at the
>> patches in more detail.
>>
>> In particular, I would like to request feedback on the use of
>> [redundant] 'reg' properties and the use of _DSD + compatible to
>> describe PHYs. Usually, we try to avoid this, given that it is
>> essentially a ACPI encapsulated DT dialect that is difficult to
>> support in drivers unless they are based on DT to begin with. Also,
>> non-standard _DSD properties require a vendor prefix, it is not
>> freeform.
>>
>> For reference, the ACPI description is here (starting at line 175)
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/72d5ac23b20dd74d479daa5e40ba443264b31261/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl
>>
> So the representation of PHY's with _DSD was kind of formalised here
>
> http://www.uefi.org/sites/default/files/resources/nic-request-v2.pdf
>
> This is already in use in the kernel, and that DSDT seems to be along the same
> lines. So seems ok in that manner.
>
> The "reg", 0 property seems a little odd, it would probably make more
> sense to check for the lack of ranges passed in in ACPI manner _CRS.
>
I already agreed with 'reg' being awkward in the later emails.
Wouldn't _ADR be more appropriate to specify PHY address on MDIO bus?
Thanks,
Marcin
^ permalink raw reply
* [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver
From: graeme.gregory at linaro.org @ 2018-01-03 11:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171231192354.GB20455@lunn.ch>
On Sun, Dec 31, 2017 at 08:23:54PM +0100, Andrew Lunn wrote:
> > * Modify way of obtaining interrupts - with ACPI they are resources
> > bound to struct platform_device and it's not possible to obtain
> > them directly from the child node. Hence a formula is used, depending
> > on the port_id and number of possible CPUs.
>
> Hi Marcin
>
> I know nothing about ACPI. Is this limitation with respect to
> interrupts fundamental to ACPI, or just that nobody has implemented
> flexible interrupt support yet?
>
The infrastructure is there to traverse trees of children, but I don't
think there any helper functions.
Graeme
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180103/bf301cec/attachment-0001.sig>
^ permalink raw reply
* [PATCH V4 22/26] video: fbdev: intelfb: deprecate pci_get_bus_and_slot()
From: Bartlomiej Zolnierkiewicz @ 2018-01-03 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7099e2af-4704-4611-94c0-830483de4578@codeaurora.org>
On Tuesday, January 02, 2018 08:38:24 AM Sinan Kaya wrote:
> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
> >
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> >
> > Find the domain number from pdev.
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Any feedback here ? most of the remaining patches have the ACK except these.
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH V4 23/26] video: fbdev: nvidia: deprecate pci_get_bus_and_slot()
From: Bartlomiej Zolnierkiewicz @ 2018-01-03 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6a6b51ff-42d5-29cc-167e-f4ed74d7ac36@codeaurora.org>
On Tuesday, January 02, 2018 08:38:03 AM Sinan Kaya wrote:
> On 12/19/2017 12:37 AM, Sinan Kaya wrote:
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
> >
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> >
> > struct nvidia_par has a pointer to struct pci_dev. Use the pci_dev
> > member to extract the domain information and pass it to
> > pci_get_domain_bus_and_slot() function.
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Any feedback here ? most of the remaining patches have the ACK except these.
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH V4 24/26] video: fbdev: riva: deprecate pci_get_bus_and_slot()
From: Bartlomiej Zolnierkiewicz @ 2018-01-03 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <04f4cf20-9b57-3eff-79b6-abfda1258174@codeaurora.org>
On Tuesday, January 02, 2018 08:37:32 AM Sinan Kaya wrote:
> On 12/19/2017 12:38 AM, Sinan Kaya wrote:
> > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> > where a PCI device is present. This restricts the device drivers to be
> > reused for other domain numbers.
> >
> > Getting ready to remove pci_get_bus_and_slot() function in favor of
> > pci_get_domain_bus_and_slot().
> >
> > struct riva_par has a pointer to struct pci_dev. Use the pci_dev member
> > to extract the domain information.
> >
> > Change the function signature for CalcStateExt and RivaGetConfig to pass
> > in struct pci_dev in addition to RIVA_HW_INST so that code inside the
> > riva_hw.c can also calculate domain number and pass it to
> > pci_get_domain_bus_and_slot().
> >
> > Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
>
> Any feedback here, most of the remaining patches have the ACK except these?
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [net-next: PATCH v2 5/5] net: mvpp2: enable ACPI support in the driver
From: Marcin Wojtas @ 2018-01-03 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180103111611.GB21230@xora-haswell>
Graeme,
2018-01-03 12:16 GMT+01:00 <graeme.gregory@linaro.org>:
> On Sun, Dec 31, 2017 at 08:23:54PM +0100, Andrew Lunn wrote:
>> > * Modify way of obtaining interrupts - with ACPI they are resources
>> > bound to struct platform_device and it's not possible to obtain
>> > them directly from the child node. Hence a formula is used, depending
>> > on the port_id and number of possible CPUs.
>>
>> Hi Marcin
>>
>> I know nothing about ACPI. Is this limitation with respect to
>> interrupts fundamental to ACPI, or just that nobody has implemented
>> flexible interrupt support yet?
>>
> The infrastructure is there to traverse trees of children, but I don't
> think there any helper functions.
>
Thanks, so if I implement such, do you expect any formal issues that
prevent its acceptance?
Best regards,
Marcin
^ permalink raw reply
* [PATCH] irqchip/gic-v3-its: Add workaround for ThunderX2 erratum #174
From: Ganapatrao Kulkarni @ 2018-01-03 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <da5b60cf-2ede-720e-b957-4e88325a7810@arm.com>
On Wed, Jan 3, 2018 at 3:43 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 03/01/18 09:35, Ganapatrao Kulkarni wrote:
>> Hi Marc,
>>
>> On Wed, Jan 3, 2018 at 2:17 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On 03/01/18 06:32, Ganapatrao Kulkarni wrote:
>>>> When an interrupt is moved across node collections on ThunderX2
>>>
>>> node collections?
>>
>> ok, i will rephrase it.
>> i was intended to say cross NUMA node collection/cpu affinity change.
>>
>>>
>>>> multi Socket platform, an interrupt stops routed to new collection
>>>> and results in loss of interrupts.
>>>>
>>>> Adding workaround to issue INV after MOVI for cross-node collection
>>>> move to flush out the cached entry.
>>>>
>>>> Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
>>>> ---
>>>> Documentation/arm64/silicon-errata.txt | 1 +
>>>> arch/arm64/Kconfig | 11 +++++++++++
>>>> drivers/irqchip/irq-gic-v3-its.c | 24 ++++++++++++++++++++++++
>>>> 3 files changed, 36 insertions(+)
>>>>
>>>> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
>>>> index fc1c884..fb27cb5 100644
>>>> --- a/Documentation/arm64/silicon-errata.txt
>>>> +++ b/Documentation/arm64/silicon-errata.txt
>>>> @@ -63,6 +63,7 @@ stable kernels.
>>>> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
>>>> | Cavium | ThunderX Core | #30115 | CAVIUM_ERRATUM_30115 |
>>>> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
>>>> +| Cavium | ThunderX2 ITS | #174 | CAVIUM_ERRATUM_174 |
>>>> | Cavium | ThunderX2 SMMUv3| #74 | N/A |
>>>> | Cavium | ThunderX2 SMMUv3| #126 | N/A |
>>>> | | | | |
>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>>> index c9a7e9e..71a7e30 100644
>>>> --- a/arch/arm64/Kconfig
>>>> +++ b/arch/arm64/Kconfig
>>>> @@ -461,6 +461,17 @@ config ARM64_ERRATUM_843419
>>>>
>>>> If unsure, say Y.
>>>>
>>>> +config CAVIUM_ERRATUM_174
>>>> + bool "Cavium ThunderX2 erratum 174"
>>>> + depends on NUMA
>>>
>>> Why? This system will be affected no matter whether NUMA is selected or not.
>>
>> it does not makes sense to enable on non-NUMA/single socket platforms.
>> By default NUMA is enabled on ThunderX2 dual socket platforms.
>
> <quote>
> config ARCH_THUNDER2
> bool "Cavium ThunderX2 Server Processors"
> select GPIOLIB
> help
> This enables support for Cavium's ThunderX2 CN99XX family of
> server processors.
> </quote>
>
> Do you see any NUMA here? I can perfectly compile a kernel with both
> sockets, and not using NUMA. NUMA has to do with memory, and not interrupts.
ok, i will remote it.
>
>>
>>>
>>>> + default y
>>>> + help
>>>> + LPI stops routed to redistributors after inter node collection
>>>> + move in ITS. Enable workaround to invalidate ITS entry after
>>>> + inter-node collection move.
>>>
>>> That's a very terse description. Nobody knows what an LPI, a
>>> redistributor or a collection is. Please explain what the erratum is in
>>> layman's terms (Cavium ThunderX2 systems may loose interrupts on
>>> affinity change) so that people understand whether or not they are affected.
>>
>> ok, i will rephrase it in next version.
>>>
>>>> +
>>>> + If unsure, say Y.
>>>> +
>>>> config CAVIUM_ERRATUM_22375
>>>> bool "Cavium erratum 22375, 24313"
>>>> default y
>>>> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
>>>> index 06f025f..d8b9c96 100644
>>>> --- a/drivers/irqchip/irq-gic-v3-its.c
>>>> +++ b/drivers/irqchip/irq-gic-v3-its.c
>>>> @@ -46,6 +46,7 @@
>>>> #define ITS_FLAGS_CMDQ_NEEDS_FLUSHING (1ULL << 0)
>>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_22375 (1ULL << 1)
>>>> #define ITS_FLAGS_WORKAROUND_CAVIUM_23144 (1ULL << 2)
>>>> +#define ITS_FLAGS_WORKAROUND_CAVIUM_174 (1ULL << 3)
>>>>
>>>> #define RDIST_FLAGS_PROPBASE_NEEDS_FLUSHING (1 << 0)
>>>>
>>>> @@ -1119,6 +1120,12 @@ static int its_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
>>>> if (cpu != its_dev->event_map.col_map[id]) {
>>>> target_col = &its_dev->its->collections[cpu];
>>>> its_send_movi(its_dev, target_col, id);
>>>> + if (its_dev->its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_174) {
>>>> + /* Issue INV for cross node collection move. */
>>>> + if (cpu_to_node(cpu) !=
>>>> + cpu_to_node(its_dev->event_map.col_map[id]))
>>>> + its_send_inv(its_dev, id);
>>>> + }
>>>
>>> What happens if an interrupt happens after the MOV, but before the INV?
>>
>> there can be drop, if interrupt happens before INV, however, it is
>> highly unlikely that we will hit the issue since MOVI and INV are
>> executed back to back. this workaround fixed issue seen on couple of
>> IOs.
>
> Really? So this doesn't fix anything, and the device may just wait
> forever for the CPU to service an LPI that was never delivered. I'm
> sorry, but that's not an acceptable workaround.
>
> I can see two solutions:
> 1) you inject an interrupt after the INV as you may have lost at least one
> 2) you restrict the affinity of LPIs to a single socket
>
> (1) will generate spurious interrupts, but will be safe. (2) will result
> in an unbalanced system. Pick your poison...
>
> You may be able to achieve something by disabling the LPI before
> performing the MOVI/INV sequence, and reenable it afterwards, but only
> you can tell if this could work with your HW.
thanks for the suggestion, i will try out disable/enable LPI.
the sequence would be,
Disable LPI in rdist of cpu1
MOVI from cpu1 to cpu2
INV
enable LPI in rdist of cpu1
>
> In any case, I won't take a workaround that leaves any chance of loosing
> an interrupt.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
thanks
Ganapat
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox