* [PATCH v2 2/7] usb: mtu3: remove repeated setting of gadget state
From: Chunfeng Yun @ 2018-05-10 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b82c11302a81368bd6936424d081ede3340b431.1525930818.git.chunfeng.yun@mediatek.com>
The usb_add_gadget_udc() will set the gadget state as
USB_STATE_NOTATTACHED, so we needn't set it again.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3_gadget.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index f05f10f..de0de01 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -660,14 +660,10 @@ int mtu3_gadget_setup(struct mtu3 *mtu)
mtu3_gadget_init_eps(mtu);
ret = usb_add_gadget_udc(mtu->dev, &mtu->g);
- if (ret) {
+ if (ret)
dev_err(mtu->dev, "failed to register udc\n");
- return ret;
- }
- usb_gadget_set_state(&mtu->g, USB_STATE_NOTATTACHED);
-
- return 0;
+ return ret;
}
void mtu3_gadget_cleanup(struct mtu3 *mtu)
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/7] usb: mtu3: fix an unrecognized issue when connected with PC
From: Chunfeng Yun @ 2018-05-10 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b82c11302a81368bd6936424d081ede3340b431.1525930818.git.chunfeng.yun@mediatek.com>
When boot on the platform with the USB cable connected to Win7,
the Win7 will pop up an error dialog: "USB Device not recognized",
but finally the Win7 can enumerate it successfully.
The root cause is as the following:
When the xHCI driver set PORT_POWER of the OTG port, and if both
IDPIN and VBUS_VALID are high at the same time, the MTU3 controller
will set SESSION and pull up DP, so the Win7 can detect existence
of USB device, but if the mtu3 driver can't switch to device mode
during the debounce time, the Win7 can not enumerate it.
Here to fix it by removing the 1s delayed EXTCON register to speed up
mode switch.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/mtu3.h | 4 ----
drivers/usb/mtu3/mtu3_dr.c | 25 +++----------------------
2 files changed, 3 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 2cd00a2..a56fee0 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -197,9 +197,6 @@ struct mtu3_gpd_ring {
* @edev: external connector used to detect vbus and iddig changes
* @vbus_nb: notifier for vbus detection
* @vbus_nb: notifier for iddig(idpin) detection
-* @extcon_reg_dwork: delay work for extcon notifier register, waiting for
-* xHCI driver initialization, it's necessary for system bootup
-* as device.
* @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
* @manual_drd_enabled: it's true when supports dual-role device by debugfs
* to switch host/device modes depending on user input.
@@ -209,7 +206,6 @@ struct otg_switch_mtk {
struct extcon_dev *edev;
struct notifier_block vbus_nb;
struct notifier_block id_nb;
- struct delayed_work extcon_reg_dwork;
bool is_u3_drd;
bool manual_drd_enabled;
};
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index db7562d..80083e0 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -238,15 +238,6 @@ static int ssusb_extcon_register(struct otg_switch_mtk *otg_sx)
return 0;
}
-static void extcon_register_dwork(struct work_struct *work)
-{
- struct delayed_work *dwork = to_delayed_work(work);
- struct otg_switch_mtk *otg_sx =
- container_of(dwork, struct otg_switch_mtk, extcon_reg_dwork);
-
- ssusb_extcon_register(otg_sx);
-}
-
/*
* We provide an interface via debugfs to switch between host and device modes
* depending on user input.
@@ -407,18 +398,10 @@ int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
{
struct otg_switch_mtk *otg_sx = &ssusb->otg_switch;
- if (otg_sx->manual_drd_enabled) {
+ if (otg_sx->manual_drd_enabled)
ssusb_debugfs_init(ssusb);
- } else {
- INIT_DELAYED_WORK(&otg_sx->extcon_reg_dwork,
- extcon_register_dwork);
-
- /*
- * It is enough to delay 1s for waiting for
- * host initialization
- */
- schedule_delayed_work(&otg_sx->extcon_reg_dwork, HZ);
- }
+ else
+ ssusb_extcon_register(otg_sx);
return 0;
}
@@ -429,6 +412,4 @@ void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
if (otg_sx->manual_drd_enabled)
ssusb_debugfs_exit(ssusb);
- else
- cancel_delayed_work(&otg_sx->extcon_reg_dwork);
}
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/7] usb: mtu3: fix operation failure when test TEST_J/K
From: Chunfeng Yun @ 2018-05-10 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b82c11302a81368bd6936424d081ede3340b431.1525930818.git.chunfeng.yun@mediatek.com>
There is an error dialog popped up in PC when test TEST_J/K
by EHSETT tool, due to not waiting for the completion of
control transfer. Here fix it by entering test mode after
Status Stage finish.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2:
1. reset test_mode as default value when controller is reset
2. use readl_poll_timeout_atomic()
---
drivers/usb/mtu3/mtu3_gadget.c | 1 +
drivers/usb/mtu3/mtu3_gadget_ep0.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index de0de01..5c60a8c 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -719,4 +719,5 @@ void mtu3_gadget_reset(struct mtu3 *mtu)
mtu->u1_enable = 0;
mtu->u2_enable = 0;
mtu->delayed_status = false;
+ mtu->test_mode = false;
}
diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index d67b540..d3fc51b 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -7,6 +7,7 @@
* Author: Chunfeng.Yun <chunfeng.yun@mediatek.com>
*/
+#include <linux/iopoll.h>
#include <linux/usb/composite.h>
#include "mtu3.h"
@@ -263,6 +264,7 @@ static int handle_test_mode(struct mtu3 *mtu, struct usb_ctrlrequest *setup)
{
void __iomem *mbase = mtu->mac_base;
int handled = 1;
+ u32 value;
switch (le16_to_cpu(setup->wIndex) >> 8) {
case TEST_J:
@@ -292,6 +294,14 @@ static int handle_test_mode(struct mtu3 *mtu, struct usb_ctrlrequest *setup)
if (mtu->test_mode_nr == TEST_PACKET_MODE)
ep0_load_test_packet(mtu);
+ /* send status before entering test mode. */
+ value = mtu3_readl(mbase, U3D_EP0CSR) & EP0_W1C_BITS;
+ mtu3_writel(mbase, U3D_EP0CSR, value | EP0_SETUPPKTRDY | EP0_DATAEND);
+
+ /* wait for ACK status sent by host, ignore timeout error */
+ readl_poll_timeout_atomic(mbase + U3D_EP0CSR, value,
+ !(value & EP0_DATAEND), 100, 5000);
+
mtu3_writel(mbase, U3D_USB2_TEST_MODE, mtu->test_mode_nr);
mtu->ep0_state = MU3D_EP0_STATE_SETUP;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/7] usb: mtu3: make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3
From: Chunfeng Yun @ 2018-05-10 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b82c11302a81368bd6936424d081ede3340b431.1525930818.git.chunfeng.yun@mediatek.com>
In fact the driver depends on EXTCON only when it's configed as
USB_MTU3_DUAL_ROLE, so make USB_MTU3_DUAL_ROLE depend on EXTCON but
not USB_MTU3.
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/usb/mtu3/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd619..8daf277 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
- depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+ depends on (USB || USB_GADGET) && HAS_DMA
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
@@ -40,6 +40,7 @@ config USB_MTU3_GADGET
config USB_MTU3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || USB_GADGET=USB_MTU3))
+ depends on (EXTCON=y || EXTCON=USB_MTU3)
help
This is the default mode of working of MTU3 controller where
both host and gadget features are enabled.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 6/7] usb: mtu3: re-enable controller to accept LPM request after LPM resume
From: Chunfeng Yun @ 2018-05-10 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b82c11302a81368bd6936424d081ede3340b431.1525930818.git.chunfeng.yun@mediatek.com>
After the controller receives a LPM request, it will reject the LPM
request, and need software to re-enable it after LPM resume if the
controller doesn't remote wakeup from L1 automatically
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2:
add this patch
---
drivers/usb/mtu3/mtu3_core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index b1b99a8..65ff53a 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -176,7 +176,7 @@ static void mtu3_intr_enable(struct mtu3 *mtu)
mtu3_writel(mbase, U3D_LV1IESR, value);
/* Enable U2 common USB interrupts */
- value = SUSPEND_INTR | RESUME_INTR | RESET_INTR;
+ value = SUSPEND_INTR | RESUME_INTR | RESET_INTR | LPM_RESUME_INTR;
mtu3_writel(mbase, U3D_COMMON_USB_INTR_ENABLE, value);
if (mtu->is_u3_ip) {
@@ -692,6 +692,12 @@ static irqreturn_t mtu3_u2_common_isr(struct mtu3 *mtu)
if (u2comm & RESET_INTR)
mtu3_gadget_reset(mtu);
+ if (u2comm & LPM_RESUME_INTR) {
+ if (!(mtu3_readl(mbase, U3D_POWER_MANAGEMENT) & LPM_HRWE))
+ mtu3_setbits(mbase, U3D_USB20_MISC_CONTROL,
+ LPM_U3_ACK_EN);
+ }
+
return IRQ_HANDLED;
}
--
1.9.1
^ permalink raw reply related
* [PATCH v2 7/7] usb: mtu3: fix uncontinuous SeqN issue after disable EP
From: Chunfeng Yun @ 2018-05-10 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b82c11302a81368bd6936424d081ede3340b431.1525930818.git.chunfeng.yun@mediatek.com>
Reset EP when disable it to reset data toggle for U2 EP, and
SeqN, flow control status etc for U3 EP, this can avoid
issue of uncontinuous SeqN
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
v2:
add this patch
---
drivers/usb/mtu3/mtu3_core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index 65ff53a..0bc2b39 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -400,6 +400,10 @@ void mtu3_deconfig_ep(struct mtu3 *mtu, struct mtu3_ep *mep)
mtu3_setbits(mbase, U3D_QIECR0, QMU_RX_DONE_INT(epnum));
}
+ /* reset: u2 - data toggle, u3 - SeqN, flow control status etc */
+ mtu3_setbits(mbase, U3D_EP_RST, EP_RST(mep->is_in, epnum));
+ mtu3_clrbits(mbase, U3D_EP_RST, EP_RST(mep->is_in, epnum));
+
ep_fifo_free(mep);
dev_dbg(mtu->dev, "%s: %s\n", __func__, mep->name);
--
1.9.1
^ permalink raw reply related
* Add MediaTek XS-PHY driver
From: Chunfeng Yun @ 2018-05-10 6:10 UTC (permalink / raw)
To: linux-arm-kernel
>From 2ca1243f228633ca9dd96d3e4068af9e2936cd51 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun <chunfeng.yun@mediatek.com>
Date: Thu, 10 May 2018 13:55:52 +0800
Subject: [PATCH v3 0/2] Add MediaTek XS-PHY driver
This patch series support the SuperSpeedPlus XS-PHY transceiver for
USB3.1 GEN2 controller on MediaTek chips. The driver supports multiple
USB2.0, USB3.1 GEN2 ports.
v3: changes in binding (suggested by Rob)
1. use the correct name of SoC as soc-model's example
v2: changes in binding (suggested by Rob)
1. list all valid SoCs for compatible
2. move required child nodes after parent optional ones
3. remove status property in example
4. move banks layout example before dts one
5. remove phy binding example
6. add #address-cells, #size-cells, ranges properties for parent node
Chunfeng Yun (2):
dt-bindings: add MediaTek XS-PHY binding
phy: mediatek: add XS-PHY driver
.../devicetree/bindings/phy/phy-mtk-xsphy.txt | 110 ++++
drivers/phy/mediatek/Kconfig | 9 +
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-xsphy.c | 600 +++++++++++++++++++++
4 files changed, 720 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
create mode 100644 drivers/phy/mediatek/phy-mtk-xsphy.c
--
1.9.1
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: add MediaTek XS-PHY binding
From: Chunfeng Yun @ 2018-05-10 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525932629-10603-1-git-send-email-chunfeng.yun@mediatek.com>
Add a DT binding documentation of XS-PHY for MediaTek SoCs
with USB3.1 GEN2 controller
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
.../devicetree/bindings/phy/phy-mtk-xsphy.txt | 110 ++++++++++++++++++++
1 file changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
new file mode 100644
index 0000000..7f2b16f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
@@ -0,0 +1,110 @@
+MediaTek XS-PHY binding
+--------------------------
+
+The XS-PHY controller supports physical layer functionality for USB3.1
+GEN2 controller on MediaTek SoCs.
+
+Required properties (controller (parent) node):
+ - compatible : should be "mediatek,<soc-model>-xsphy", "mediatek,xsphy",
+ soc-model is the name of SoC, such as mt3611 etc;
+ when using "mediatek,xsphy" compatible string, you need SoC specific
+ ones in addition, one of:
+ - "mediatek,mt3611-xsphy"
+
+ - #address-cells, #size-cells : should use the same values as the root node
+ - ranges: must be present
+
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple U3 ports,
+ exclude port's private register, if only U2 ports provided,
+ shouldn't use the property.
+ - mediatek,src-ref-clk-mhz : u32, frequency of reference clock for slew rate
+ calibrate
+ - mediatek,src-coef : u32, coefficient for slew rate calibrate, depends on
+ SoC process
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology.
+
+Required properties (port (child) node):
+- reg : address and length of the register set for the port.
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : must contain
+ "ref": 48M reference clock for HighSpeed analog phy; and 26M
+ reference clock for SuperSpeedPlus analog phy, sometimes is
+ 24M, 25M or 27M, depended on platform.
+- #phy-cells : should be 1
+ cell after port phandle is phy type from:
+ - PHY_TYPE_USB2
+ - PHY_TYPE_USB3
+
+The following optional properties are only for debug or HQA test
+Optional properties (PHY_TYPE_USB2 port (child) node):
+- mediatek,eye-src : u32, the value of slew rate calibrate
+- mediatek,eye-vrt : u32, the selection of VRT reference voltage
+- mediatek,eye-term : u32, the selection of HS_TX TERM reference voltage
+- mediatek,efuse-intr : u32, the selection of Internal Resistor
+
+Optional properties (PHY_TYPE_USB3 port (child) node):
+- mediatek,efuse-intr : u32, the selection of Internal Resistor
+- mediatek,efuse-tx-imp : u32, the selection of TX Impedance
+- mediatek,efuse-rx-imp : u32, the selection of RX Impedance
+
+Banks layout of xsphy
+-------------------------------------------------------------
+port offset bank
+u2 port0 0x0000 MISC
+ 0x0100 FMREG
+ 0x0300 U2PHY_COM
+u2 port1 0x1000 MISC
+ 0x1100 FMREG
+ 0x1300 U2PHY_COM
+u2 port2 0x2000 MISC
+ ...
+u31 common 0x3000 DIG_GLB
+ 0x3100 PHYA_GLB
+u31 port0 0x3400 DIG_LN_TOP
+ 0x3500 DIG_LN_TX0
+ 0x3600 DIG_LN_RX0
+ 0x3700 DIG_LN_DAIF
+ 0x3800 PHYA_LN
+u31 port1 0x3a00 DIG_LN_TOP
+ 0x3b00 DIG_LN_TX0
+ 0x3c00 DIG_LN_RX0
+ 0x3d00 DIG_LN_DAIF
+ 0x3e00 PHYA_LN
+ ...
+
+DIG_GLB & PHYA_GLB are shared by U31 ports.
+
+Example:
+
+u3phy: usb-phy at 11c40000 {
+ compatible = "mediatek,mt3611-xsphy", "mediatek,xsphy";
+ reg = <0 0x11c43000 0 0x0200>;
+ mediatek,src-ref-clk-mhz = <26>;
+ mediatek,src-coef = <17>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ u2port0: usb-phy at 11c40000 {
+ reg = <0 0x11c40000 0 0x0400>;
+ clocks = <&clk48m>;
+ clock-names = "ref";
+ mediatek,eye-src = <4>;
+ #phy-cells = <1>;
+ };
+
+ u3port0: usb-phy at 11c43000 {
+ reg = <0 0x11c43400 0 0x0500>;
+ clocks = <&clk26m>;
+ clock-names = "ref";
+ mediatek,efuse-intr = <28>;
+ #phy-cells = <1>;
+ };
+};
+
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/2] phy: mediatek: add XS-PHY driver
From: Chunfeng Yun @ 2018-05-10 6:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525932629-10603-1-git-send-email-chunfeng.yun@mediatek.com>
Support XS-PHY for MediaTek SoCs with USB3.1 GEN2 controller
Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
---
drivers/phy/mediatek/Kconfig | 9 +
drivers/phy/mediatek/Makefile | 1 +
drivers/phy/mediatek/phy-mtk-xsphy.c | 600 ++++++++++++++++++++++++++++++++++
3 files changed, 610 insertions(+)
create mode 100644 drivers/phy/mediatek/phy-mtk-xsphy.c
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 88ab4e2..8857d00 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -12,3 +12,12 @@ config PHY_MTK_TPHY
different banks layout, the T-PHY with shared banks between
multi-ports is first version, otherwise is second veriosn,
so you can easily distinguish them by banks layout.
+
+config PHY_MTK_XSPHY
+ tristate "MediaTek XS-PHY Driver"
+ depends on ARCH_MEDIATEK && OF
+ select GENERIC_PHY
+ help
+ Enable this to support the SuperSpeedPlus XS-PHY transceiver for
+ USB3.1 GEN2 controllers on MediaTek chips. The driver supports
+ multiple USB2.0, USB3.1 GEN2 ports.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 1bdab14..ee49edc 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -4,3 +4,4 @@
#
obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
+obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
diff --git a/drivers/phy/mediatek/phy-mtk-xsphy.c b/drivers/phy/mediatek/phy-mtk-xsphy.c
new file mode 100644
index 0000000..020cd02
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-xsphy.c
@@ -0,0 +1,600 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek USB3.1 gen2 xsphy Driver
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Chunfeng Yun <chunfeng.yun@mediatek.com>
+ *
+ */
+
+#include <dt-bindings/phy/phy.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/phy/phy.h>
+#include <linux/platform_device.h>
+
+/* u2 phy banks */
+#define SSUSB_SIFSLV_MISC 0x000
+#define SSUSB_SIFSLV_U2FREQ 0x100
+#define SSUSB_SIFSLV_U2PHY_COM 0x300
+
+/* u3 phy shared banks */
+#define SSPXTP_SIFSLV_DIG_GLB 0x000
+#define SSPXTP_SIFSLV_PHYA_GLB 0x100
+
+/* u3 phy banks */
+#define SSPXTP_SIFSLV_DIG_LN_TOP 0x000
+#define SSPXTP_SIFSLV_DIG_LN_TX0 0x100
+#define SSPXTP_SIFSLV_DIG_LN_RX0 0x200
+#define SSPXTP_SIFSLV_DIG_LN_DAIF 0x300
+#define SSPXTP_SIFSLV_PHYA_LN 0x400
+
+#define XSP_U2FREQ_FMCR0 ((SSUSB_SIFSLV_U2FREQ) + 0x00)
+#define P2F_RG_FREQDET_EN BIT(24)
+#define P2F_RG_CYCLECNT GENMASK(23, 0)
+#define P2F_RG_CYCLECNT_VAL(x) ((P2F_RG_CYCLECNT) & (x))
+
+#define XSP_U2FREQ_MMONR0 ((SSUSB_SIFSLV_U2FREQ) + 0x0c)
+
+#define XSP_U2FREQ_FMMONR1 ((SSUSB_SIFSLV_U2FREQ) + 0x10)
+#define P2F_RG_FRCK_EN BIT(8)
+#define P2F_USB_FM_VALID BIT(0)
+
+#define XSP_USBPHYACR0 ((SSUSB_SIFSLV_U2PHY_COM) + 0x00)
+#define P2A0_RG_INTR_EN BIT(5)
+
+#define XSP_USBPHYACR1 ((SSUSB_SIFSLV_U2PHY_COM) + 0x04)
+#define P2A1_RG_INTR_CAL GENMASK(23, 19)
+#define P2A1_RG_INTR_CAL_VAL(x) ((0x1f & (x)) << 19)
+#define P2A1_RG_VRT_SEL GENMASK(14, 12)
+#define P2A1_RG_VRT_SEL_VAL(x) ((0x7 & (x)) << 12)
+#define P2A1_RG_TERM_SEL GENMASK(10, 8)
+#define P2A1_RG_TERM_SEL_VAL(x) ((0x7 & (x)) << 8)
+
+#define XSP_USBPHYACR5 ((SSUSB_SIFSLV_U2PHY_COM) + 0x014)
+#define P2A5_RG_HSTX_SRCAL_EN BIT(15)
+#define P2A5_RG_HSTX_SRCTRL GENMASK(14, 12)
+#define P2A5_RG_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12)
+
+#define XSP_USBPHYACR6 ((SSUSB_SIFSLV_U2PHY_COM) + 0x018)
+#define P2A6_RG_BC11_SW_EN BIT(23)
+#define P2A6_RG_OTG_VBUSCMP_EN BIT(20)
+
+#define XSP_U2PHYDTM1 ((SSUSB_SIFSLV_U2PHY_COM) + 0x06C)
+#define P2D_FORCE_IDDIG BIT(9)
+#define P2D_RG_VBUSVALID BIT(5)
+#define P2D_RG_SESSEND BIT(4)
+#define P2D_RG_AVALID BIT(2)
+#define P2D_RG_IDDIG BIT(1)
+
+#define SSPXTP_PHYA_GLB_00 ((SSPXTP_SIFSLV_PHYA_GLB) + 0x00)
+#define RG_XTP_GLB_BIAS_INTR_CTRL GENMASK(21, 16)
+#define RG_XTP_GLB_BIAS_INTR_CTRL_VAL(x) ((0x3f & (x)) << 16)
+
+#define SSPXTP_PHYA_LN_04 ((SSPXTP_SIFSLV_PHYA_LN) + 0x04)
+#define RG_XTP_LN0_TX_IMPSEL GENMASK(4, 0)
+#define RG_XTP_LN0_TX_IMPSEL_VAL(x) (0x1f & (x))
+
+#define SSPXTP_PHYA_LN_14 ((SSPXTP_SIFSLV_PHYA_LN) + 0x014)
+#define RG_XTP_LN0_RX_IMPSEL GENMASK(4, 0)
+#define RG_XTP_LN0_RX_IMPSEL_VAL(x) (0x1f & (x))
+
+#define XSP_REF_CLK 26 /* MHZ */
+#define XSP_SLEW_RATE_COEF 17
+#define XSP_SR_COEF_DIVISOR 1000
+#define XSP_FM_DET_CYCLE_CNT 1024
+
+struct xsphy_instance {
+ struct phy *phy;
+ void __iomem *port_base;
+ struct clk *ref_clk; /* reference clock of anolog phy */
+ u32 index;
+ u32 type;
+ /* only for HQA test */
+ int efuse_intr;
+ int efuse_tx_imp;
+ int efuse_rx_imp;
+ /* u2 eye diagram */
+ int eye_src;
+ int eye_vrt;
+ int eye_term;
+};
+
+struct mtk_xsphy {
+ struct device *dev;
+ void __iomem *glb_base; /* only shared u3 sif */
+ struct xsphy_instance **phys;
+ int nphys;
+ int src_ref_clk; /* MHZ, reference clock for slew rate calibrate */
+ int src_coef; /* coefficient for slew rate calibrate */
+};
+
+static void u2_phy_slew_rate_calibrate(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ int calib_val;
+ int fm_out;
+ u32 tmp;
+
+ /* use force value */
+ if (inst->eye_src)
+ return;
+
+ /* enable USB ring oscillator */
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp |= P2A5_RG_HSTX_SRCAL_EN;
+ writel(tmp, pbase + XSP_USBPHYACR5);
+ udelay(1); /* wait clock stable */
+
+ /* enable free run clock */
+ tmp = readl(pbase + XSP_U2FREQ_FMMONR1);
+ tmp |= P2F_RG_FRCK_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMMONR1);
+
+ /* set cycle count as 1024 */
+ tmp = readl(pbase + XSP_U2FREQ_FMCR0);
+ tmp &= ~(P2F_RG_CYCLECNT);
+ tmp |= P2F_RG_CYCLECNT_VAL(XSP_FM_DET_CYCLE_CNT);
+ writel(tmp, pbase + XSP_U2FREQ_FMCR0);
+
+ /* enable frequency meter */
+ tmp = readl(pbase + XSP_U2FREQ_FMCR0);
+ tmp |= P2F_RG_FREQDET_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMCR0);
+
+ /* ignore return value */
+ readl_poll_timeout(pbase + XSP_U2FREQ_FMMONR1, tmp,
+ (tmp & P2F_USB_FM_VALID), 10, 200);
+
+ fm_out = readl(pbase + XSP_U2FREQ_MMONR0);
+
+ /* disable frequency meter */
+ tmp = readl(pbase + XSP_U2FREQ_FMCR0);
+ tmp &= ~P2F_RG_FREQDET_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMCR0);
+
+ /* disable free run clock */
+ tmp = readl(pbase + XSP_U2FREQ_FMMONR1);
+ tmp &= ~P2F_RG_FRCK_EN;
+ writel(tmp, pbase + XSP_U2FREQ_FMMONR1);
+
+ if (fm_out) {
+ /* (1024 / FM_OUT) x reference clock frequency x coefficient */
+ tmp = xsphy->src_ref_clk * xsphy->src_coef;
+ tmp = (tmp * XSP_FM_DET_CYCLE_CNT) / fm_out;
+ calib_val = DIV_ROUND_CLOSEST(tmp, XSP_SR_COEF_DIVISOR);
+ } else {
+ /* if FM detection fail, set default value */
+ calib_val = 3;
+ }
+ dev_dbg(xsphy->dev, "phy.%d, fm_out:%d, calib:%d (clk:%d, coef:%d)\n",
+ inst->index, fm_out, calib_val,
+ xsphy->src_ref_clk, xsphy->src_coef);
+
+ /* set HS slew rate */
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp &= ~P2A5_RG_HSTX_SRCTRL;
+ tmp |= P2A5_RG_HSTX_SRCTRL_VAL(calib_val);
+ writel(tmp, pbase + XSP_USBPHYACR5);
+
+ /* disable USB ring oscillator */
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp &= ~P2A5_RG_HSTX_SRCAL_EN;
+ writel(tmp, pbase + XSP_USBPHYACR5);
+}
+
+static void u2_phy_instance_init(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 tmp;
+
+ /* DP/DM BC1.1 path Disable */
+ tmp = readl(pbase + XSP_USBPHYACR6);
+ tmp &= ~P2A6_RG_BC11_SW_EN;
+ writel(tmp, pbase + XSP_USBPHYACR6);
+
+ tmp = readl(pbase + XSP_USBPHYACR0);
+ tmp |= P2A0_RG_INTR_EN;
+ writel(tmp, pbase + XSP_USBPHYACR0);
+}
+
+static void u2_phy_instance_power_on(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 index = inst->index;
+ u32 tmp;
+
+ tmp = readl(pbase + XSP_USBPHYACR6);
+ tmp |= P2A6_RG_OTG_VBUSCMP_EN;
+ writel(tmp, pbase + XSP_USBPHYACR6);
+
+ tmp = readl(pbase + XSP_U2PHYDTM1);
+ tmp |= P2D_RG_VBUSVALID | P2D_RG_AVALID;
+ tmp &= ~P2D_RG_SESSEND;
+ writel(tmp, pbase + XSP_U2PHYDTM1);
+
+ dev_dbg(xsphy->dev, "%s(%d)\n", __func__, index);
+}
+
+static void u2_phy_instance_power_off(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 index = inst->index;
+ u32 tmp;
+
+ tmp = readl(pbase + XSP_USBPHYACR6);
+ tmp &= ~P2A6_RG_OTG_VBUSCMP_EN;
+ writel(tmp, pbase + XSP_USBPHYACR6);
+
+ tmp = readl(pbase + XSP_U2PHYDTM1);
+ tmp &= ~(P2D_RG_VBUSVALID | P2D_RG_AVALID);
+ tmp |= P2D_RG_SESSEND;
+ writel(tmp, pbase + XSP_U2PHYDTM1);
+
+ dev_dbg(xsphy->dev, "%s(%d)\n", __func__, index);
+}
+
+static void u2_phy_instance_set_mode(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst,
+ enum phy_mode mode)
+{
+ u32 tmp;
+
+ tmp = readl(inst->port_base + XSP_U2PHYDTM1);
+ switch (mode) {
+ case PHY_MODE_USB_DEVICE:
+ tmp |= P2D_FORCE_IDDIG | P2D_RG_IDDIG;
+ break;
+ case PHY_MODE_USB_HOST:
+ tmp |= P2D_FORCE_IDDIG;
+ tmp &= ~P2D_RG_IDDIG;
+ break;
+ case PHY_MODE_USB_OTG:
+ tmp &= ~(P2D_FORCE_IDDIG | P2D_RG_IDDIG);
+ break;
+ default:
+ return;
+ }
+ writel(tmp, inst->port_base + XSP_U2PHYDTM1);
+}
+
+static void phy_parse_property(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ struct device *dev = &inst->phy->dev;
+
+ switch (inst->type) {
+ case PHY_TYPE_USB2:
+ device_property_read_u32(dev, "mediatek,efuse-intr",
+ &inst->efuse_intr);
+ device_property_read_u32(dev, "mediatek,eye-src",
+ &inst->eye_src);
+ device_property_read_u32(dev, "mediatek,eye-vrt",
+ &inst->eye_vrt);
+ device_property_read_u32(dev, "mediatek,eye-term",
+ &inst->eye_term);
+ dev_dbg(dev, "intr:%d, src:%d, vrt:%d, term:%d\n",
+ inst->efuse_intr, inst->eye_src,
+ inst->eye_vrt, inst->eye_term);
+ break;
+ case PHY_TYPE_USB3:
+ device_property_read_u32(dev, "mediatek,efuse-intr",
+ &inst->efuse_intr);
+ device_property_read_u32(dev, "mediatek,efuse-tx-imp",
+ &inst->efuse_tx_imp);
+ device_property_read_u32(dev, "mediatek,efuse-rx-imp",
+ &inst->efuse_rx_imp);
+ dev_dbg(dev, "intr:%d, tx-imp:%d, rx-imp:%d\n",
+ inst->efuse_intr, inst->efuse_tx_imp,
+ inst->efuse_rx_imp);
+ break;
+ default:
+ dev_err(xsphy->dev, "incompatible phy type\n");
+ return;
+ }
+}
+
+static void u2_phy_props_set(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 tmp;
+
+ if (inst->efuse_intr) {
+ tmp = readl(pbase + XSP_USBPHYACR1);
+ tmp &= ~P2A1_RG_INTR_CAL;
+ tmp |= P2A1_RG_INTR_CAL_VAL(inst->efuse_intr);
+ writel(tmp, pbase + XSP_USBPHYACR1);
+ }
+
+ if (inst->eye_src) {
+ tmp = readl(pbase + XSP_USBPHYACR5);
+ tmp &= ~P2A5_RG_HSTX_SRCTRL;
+ tmp |= P2A5_RG_HSTX_SRCTRL_VAL(inst->eye_src);
+ writel(tmp, pbase + XSP_USBPHYACR5);
+ }
+
+ if (inst->eye_vrt) {
+ tmp = readl(pbase + XSP_USBPHYACR1);
+ tmp &= ~P2A1_RG_VRT_SEL;
+ tmp |= P2A1_RG_VRT_SEL_VAL(inst->eye_vrt);
+ writel(tmp, pbase + XSP_USBPHYACR1);
+ }
+
+ if (inst->eye_term) {
+ tmp = readl(pbase + XSP_USBPHYACR1);
+ tmp &= ~P2A1_RG_TERM_SEL;
+ tmp |= P2A1_RG_TERM_SEL_VAL(inst->eye_term);
+ writel(tmp, pbase + XSP_USBPHYACR1);
+ }
+}
+
+static void u3_phy_props_set(struct mtk_xsphy *xsphy,
+ struct xsphy_instance *inst)
+{
+ void __iomem *pbase = inst->port_base;
+ u32 tmp;
+
+ if (inst->efuse_intr) {
+ tmp = readl(xsphy->glb_base + SSPXTP_PHYA_GLB_00);
+ tmp &= ~RG_XTP_GLB_BIAS_INTR_CTRL;
+ tmp |= RG_XTP_GLB_BIAS_INTR_CTRL_VAL(inst->efuse_intr);
+ writel(tmp, xsphy->glb_base + SSPXTP_PHYA_GLB_00);
+ }
+
+ if (inst->efuse_tx_imp) {
+ tmp = readl(pbase + SSPXTP_PHYA_LN_04);
+ tmp &= ~RG_XTP_LN0_TX_IMPSEL;
+ tmp |= RG_XTP_LN0_TX_IMPSEL_VAL(inst->efuse_tx_imp);
+ writel(tmp, pbase + SSPXTP_PHYA_LN_04);
+ }
+
+ if (inst->efuse_rx_imp) {
+ tmp = readl(pbase + SSPXTP_PHYA_LN_14);
+ tmp &= ~RG_XTP_LN0_RX_IMPSEL;
+ tmp |= RG_XTP_LN0_RX_IMPSEL_VAL(inst->efuse_rx_imp);
+ writel(tmp, pbase + SSPXTP_PHYA_LN_14);
+ }
+}
+
+static int mtk_phy_init(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+ int ret;
+
+ ret = clk_prepare_enable(inst->ref_clk);
+ if (ret) {
+ dev_err(xsphy->dev, "failed to enable ref_clk\n");
+ return ret;
+ }
+
+ switch (inst->type) {
+ case PHY_TYPE_USB2:
+ u2_phy_instance_init(xsphy, inst);
+ u2_phy_props_set(xsphy, inst);
+ break;
+ case PHY_TYPE_USB3:
+ u3_phy_props_set(xsphy, inst);
+ break;
+ default:
+ dev_err(xsphy->dev, "incompatible phy type\n");
+ clk_disable_unprepare(inst->ref_clk);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int mtk_phy_power_on(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+
+ if (inst->type == PHY_TYPE_USB2) {
+ u2_phy_instance_power_on(xsphy, inst);
+ u2_phy_slew_rate_calibrate(xsphy, inst);
+ }
+
+ return 0;
+}
+
+static int mtk_phy_power_off(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+
+ if (inst->type == PHY_TYPE_USB2)
+ u2_phy_instance_power_off(xsphy, inst);
+
+ return 0;
+}
+
+static int mtk_phy_exit(struct phy *phy)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+
+ clk_disable_unprepare(inst->ref_clk);
+ return 0;
+}
+
+static int mtk_phy_set_mode(struct phy *phy, enum phy_mode mode)
+{
+ struct xsphy_instance *inst = phy_get_drvdata(phy);
+ struct mtk_xsphy *xsphy = dev_get_drvdata(phy->dev.parent);
+
+ if (inst->type == PHY_TYPE_USB2)
+ u2_phy_instance_set_mode(xsphy, inst, mode);
+
+ return 0;
+}
+
+static struct phy *mtk_phy_xlate(struct device *dev,
+ struct of_phandle_args *args)
+{
+ struct mtk_xsphy *xsphy = dev_get_drvdata(dev);
+ struct xsphy_instance *inst = NULL;
+ struct device_node *phy_np = args->np;
+ int index;
+
+ if (args->args_count != 1) {
+ dev_err(dev, "invalid number of cells in 'phy' property\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ for (index = 0; index < xsphy->nphys; index++)
+ if (phy_np == xsphy->phys[index]->phy->dev.of_node) {
+ inst = xsphy->phys[index];
+ break;
+ }
+
+ if (!inst) {
+ dev_err(dev, "failed to find appropriate phy\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ inst->type = args->args[0];
+ if (!(inst->type == PHY_TYPE_USB2 ||
+ inst->type == PHY_TYPE_USB3)) {
+ dev_err(dev, "unsupported phy type: %d\n", inst->type);
+ return ERR_PTR(-EINVAL);
+ }
+
+ phy_parse_property(xsphy, inst);
+
+ return inst->phy;
+}
+
+static const struct phy_ops mtk_xsphy_ops = {
+ .init = mtk_phy_init,
+ .exit = mtk_phy_exit,
+ .power_on = mtk_phy_power_on,
+ .power_off = mtk_phy_power_off,
+ .set_mode = mtk_phy_set_mode,
+ .owner = THIS_MODULE,
+};
+
+static const struct of_device_id mtk_xsphy_id_table[] = {
+ { .compatible = "mediatek,xsphy", },
+ { },
+};
+MODULE_DEVICE_TABLE(of, mtk_xsphy_id_table);
+
+static int mtk_xsphy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *child_np;
+ struct phy_provider *provider;
+ struct resource *glb_res;
+ struct mtk_xsphy *xsphy;
+ struct resource res;
+ int port, retval;
+
+ xsphy = devm_kzalloc(dev, sizeof(*xsphy), GFP_KERNEL);
+ if (!xsphy)
+ return -ENOMEM;
+
+ xsphy->nphys = of_get_child_count(np);
+ xsphy->phys = devm_kcalloc(dev, xsphy->nphys,
+ sizeof(*xsphy->phys), GFP_KERNEL);
+ if (!xsphy->phys)
+ return -ENOMEM;
+
+ xsphy->dev = dev;
+ platform_set_drvdata(pdev, xsphy);
+
+ glb_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ /* optional, may not exist if no u3 phys */
+ if (glb_res) {
+ /* get banks shared by multiple u3 phys */
+ xsphy->glb_base = devm_ioremap_resource(dev, glb_res);
+ if (IS_ERR(xsphy->glb_base)) {
+ dev_err(dev, "failed to remap glb regs\n");
+ return PTR_ERR(xsphy->glb_base);
+ }
+ }
+
+ xsphy->src_ref_clk = XSP_REF_CLK;
+ xsphy->src_coef = XSP_SLEW_RATE_COEF;
+ /* update parameters of slew rate calibrate if exist */
+ device_property_read_u32(dev, "mediatek,src-ref-clk-mhz",
+ &xsphy->src_ref_clk);
+ device_property_read_u32(dev, "mediatek,src-coef", &xsphy->src_coef);
+
+ port = 0;
+ for_each_child_of_node(np, child_np) {
+ struct xsphy_instance *inst;
+ struct phy *phy;
+
+ inst = devm_kzalloc(dev, sizeof(*inst), GFP_KERNEL);
+ if (!inst) {
+ retval = -ENOMEM;
+ goto put_child;
+ }
+
+ xsphy->phys[port] = inst;
+
+ phy = devm_phy_create(dev, child_np, &mtk_xsphy_ops);
+ if (IS_ERR(phy)) {
+ dev_err(dev, "failed to create phy\n");
+ retval = PTR_ERR(phy);
+ goto put_child;
+ }
+
+ retval = of_address_to_resource(child_np, 0, &res);
+ if (retval) {
+ dev_err(dev, "failed to get address resource(id-%d)\n",
+ port);
+ goto put_child;
+ }
+
+ inst->port_base = devm_ioremap_resource(&phy->dev, &res);
+ if (IS_ERR(inst->port_base)) {
+ dev_err(dev, "failed to remap phy regs\n");
+ retval = PTR_ERR(inst->port_base);
+ goto put_child;
+ }
+
+ inst->phy = phy;
+ inst->index = port;
+ phy_set_drvdata(phy, inst);
+ port++;
+
+ inst->ref_clk = devm_clk_get(&phy->dev, "ref");
+ if (IS_ERR(inst->ref_clk)) {
+ dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
+ retval = PTR_ERR(inst->ref_clk);
+ goto put_child;
+ }
+ }
+
+ provider = devm_of_phy_provider_register(dev, mtk_phy_xlate);
+ return PTR_ERR_OR_ZERO(provider);
+
+put_child:
+ of_node_put(child_np);
+ return retval;
+}
+
+static struct platform_driver mtk_xsphy_driver = {
+ .probe = mtk_xsphy_probe,
+ .driver = {
+ .name = "mtk-xsphy",
+ .of_match_table = mtk_xsphy_id_table,
+ },
+};
+
+module_platform_driver(mtk_xsphy_driver);
+
+MODULE_AUTHOR("Chunfeng Yun <chunfeng.yun@mediatek.com>");
+MODULE_DESCRIPTION("MediaTek USB XS-PHY driver");
+MODULE_LICENSE("GPL v2");
--
1.7.9.5
^ permalink raw reply related
* [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices
From: Sean Wang @ 2018-05-10 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6033F916-F103-4F07-9912-695B5B49F30F@holtmann.org>
On Tue, 2018-05-08 at 13:18 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
> >>>>> +
[ ... ]
> >
> > I'm happy to do with btmon. just the environment with buildroot the BT
> > running on seems there's a missing support for btmon. I can start to use
> > btmon once I change the environment to Debian.
> >
> >> So all the MTK vendor commands respond with a vendor event? Or are there some that do the standard command status/complete handling?
> >>
> >
> > yes, mtk controller after mt7622 (included), its MTK vendors command
> > (opcode 0xfc6f) always respond with a vendor event id 0xe4. And they
> > don't do any standard status/complete handling.
> then we need to figure out where the __hci_cmd_sync_ev causes a problem. Since normally that should just work for you.
>
Okay. I will look into more about the issue after I finished the v2
based on btuart driver. By the way, I've ported the btmon to my board,
these vendor commands/events reported via btmon looks like below shown
up
> HCI Event: Unknown (0xe4) plen 5
[hci0] 11.213593
02 01 01 00 00 .....
> HCI Event: Unknown (0xe4) plen 5
[hci0] 11.214272
02 01 01 00 00 .....
< HCI Command: Vendor (0x3f|0x006f) plen 5
[hci0] 11.214318
01 07 01 00 04 .....
> HCI Event: Unknown (0xe4) plen 5
[hci0] 11.214438
02 07 01 00 00 .....
< HCI Command: Vendor (0x3f|0x006f) plen 6
[hci0] 13.229379
01 06 02 00 00 01 ......
> HCI Event: Unknown (0xe4) plen 5
[hci0] 13.307729
02 06 01 00 00 .....
> > BTW, mtk controller before mt7622, such as mt7623, its MTK vendor
> > command always go with completely specific format, not with hci format.
>
> What does that mean? Do you have an example?
>
what I meant is that these vendor commands and events applied on old
SoCs prior to MT7622 always use completely proprietary format rather
than any BT packet to setup the BT controller.
for example:
- vendor command
01 06 02 00 00 01
- vendor event
02 06 01 00 00
> Regards
>
> Marcel
>
^ permalink raw reply
* [PATCH v2 01/26] drm/bridge: allow optionally specifying an owner .odev device
From: Andrzej Hajda @ 2018-05-10 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5abcab35-8a78-a02a-9f22-321da55d9858@axentia.se>
On 10.05.2018 00:21, Peter Rosin wrote:
> On 2018-05-09 17:53, Peter Rosin wrote:
>> On 2018-05-09 17:08, Andrzej Hajda wrote:
>>> On 04.05.2018 15:51, Peter Rosin wrote:
>>>> Bridge drivers can now (temporarily, in a transition phase) select if
>>>> they want to provide a full owner device or keep just providing an
>>>> of_node.
>>>>
>>>> By providing a full owner device, the bridge drivers no longer need
>>>> to provide an of_node since that node is available via the owner
>>>> device.
>>>>
>>>> When all bridge drivers provide an owner device, that will become
>>>> mandatory and the .of_node member will be removed.
>>>>
>>>> Signed-off-by: Peter Rosin <peda@axentia.se>
>>>> ---
>>>> drivers/gpu/drm/drm_bridge.c | 3 ++-
>>>> drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +++-
>>> What is the reason to put rockchip here? Shouldn't be in separate patch?
>> Because the rockchip driver peeks into the bridge struct and all the
>> changes in this patch relate to making the new .odev member optional in
>> the transition phase, when the bridge can have either a new-style odev
>> or an old style of_node.
>>
>> I guess this rockchip change could be patch 2, but it has to come first
>> after this patch and it makes no sense on its own. Hence, one patch.
>>
>> This rockchip_lvds interaction is also present in patch 24/26
>> drm/bridge: remove the .of_node member
>>
>> I can split them if you want, but I personally don't see the point.
> I had a second look, and maybe the series should start with a patch like
> this instead, so that the rockchip_lvds.c hunks can be removed from
> patch 1/26 and 24/26. That would perhaps be slightly cleaner?
>
> On the other hand, it's orthogonal and this series can be left as is
> (with the benefit of me not having to do another iteration and you all
> not having another bunch of messages to sift through). The below
> patch could easily be (adjusted and) applied later instead. Or not,
> since the right fix is to do this with the newfangled static image
> format mechanism from Jacopo Mondi, and it might be easier to just do
> it right.
>
> State your preference.
For me the current version is OK, it maybe lacks explanation why do you
need to touch rockchip, from my PoV it did not seem so obvious.
Somebody should fix rockchip to use Jacopo's approach instead of
violating abstractions, but this is another story.
With or without added missing explanation:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
?--
Regards
Andrzej
>
> Cheers,
> Peter
>
> >From dee27b36a36acd271459d1489336b56132097425 Mon Sep 17 00:00:00 2001
> From: Peter Rosin <peda@axentia.se>
> Date: Wed, 9 May 2018 23:58:24 +0200
> Subject: [PATCH] drm/rockchip: lvds: do not dig into the DT of remote bridges
>
> The driver is trying to find the needed "data-mapping" for
> interacting with the following bridge in the graphics chain.
> But, doing so is bad since it is done w/o regard of the
> compatible of the remote bridge, so the value of "data-mapping"
> might not mean what this driver assumes. It is also pointless
> since no bridge has any documented "data-mapping" DT property
> and no dts file show any undocumented use.
>
> Just remove the inappropriate code.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> index 4bd94b167d2c..fa3f4bf9712f 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
> @@ -377,8 +377,6 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
> }
> if (lvds->panel)
> remote = lvds->panel->dev->of_node;
> - else
> - remote = lvds->bridge->of_node;
> if (of_property_read_string(dev->of_node, "rockchip,output", &name))
> /* default set it as output rgb */
> lvds->output = DISPLAY_OUTPUT_RGB;
^ permalink raw reply
* [PATCH v2 25/26] drm/bridge: require the owner .odev to be filled in on drm_bridge_add/attach
From: Andrzej Hajda @ 2018-05-10 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135212.26977-26-peda@axentia.se>
On 04.05.2018 15:52, Peter Rosin wrote:
> The .odev owner device will be handy to have around.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
?--
Regards
Andrzej
> ---
> drivers/gpu/drm/drm_bridge.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index df084db33494..78d186b6831b 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -70,6 +70,9 @@ static LIST_HEAD(bridge_list);
> */
> void drm_bridge_add(struct drm_bridge *bridge)
> {
> + if (WARN_ON(!bridge->odev))
> + return;
> +
> mutex_lock(&bridge_lock);
> list_add_tail(&bridge->list, &bridge_list);
> mutex_unlock(&bridge_lock);
> @@ -115,6 +118,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> if (!encoder || !bridge)
> return -EINVAL;
>
> + if (WARN_ON(!bridge->odev))
> + return -EINVAL;
> +
> if (previous && (!previous->dev || previous->encoder != encoder))
> return -EINVAL;
>
^ permalink raw reply
* [PATCH] bpf, arm32: Correct check_imm24
From: Russell King - ARM Linux @ 2018-05-10 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510032013.GB26016@udknight>
On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote:
> imm24 is signed, so the right range is:
> [-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
2 << (24 - 1) is the same as 1 << 24.
> -#define check_imm(bits, imm) do { \
> - if ((((imm) > 0) && ((imm) >> (bits))) || \
> - (((imm) < 0) && (~(imm) >> (bits)))) { \
> - pr_info("[%2d] imm=%d(0x%x) out of range\n", \
> - i, imm, imm); \
> +#define check_imm_range(min, max, imm) do { \
> + if (imm < min || imm > max) { \
> + pr_info("[%2d] imm=%d is out of range\n", \
> + i, imm); \
> return -EINVAL; \
> } \
> } while (0)
> -#define check_imm24(imm) check_imm(24, imm)
> +#define check_imm24(imm) check_imm_range(-16777216, 16777215, imm)
How is this any different?
If imm is 16777216, then "imm > max" in your version is true.
In the original version, "imm > 0" is true, so we then test for
"16777216 >> 24" being non-zero. That's also true, so the test
condition fires.
If imm is 16777215, then "imm > max" is false in your version.
In the original version, the conditions also evaluate to false.
For the -16777217 case, "imm < min" in your version is true.
In the original version, "imm < 0" is true, so we then test for
"~(-16777217) >> 24" being non-zero. This is the same as
"16777216 >> 24" being non-zero, which is true so the condition
fires.
With -16777216, the same thing happens, both end up evaluating
to false.
So, the two cases end up producing identical results, and there
is no actual effect from this change.
However, your commit message is correct - there is a bug here.
That's obvious when you mask the "imm" value with 0x00ffffff,
and realise that an imm value of -16777216 ends up having the
same value in the instruction as an imm value of 0. So, the
range of "imm" is _half_ that.
#define check_imm(bits, imm) do { \
- if ((((imm) > 0) && ((imm) >> (bits))) || \
- (((imm) < 0) && (~(imm) >> (bits)))) { \
+ if ((((imm) > 0) && ((imm) >> (bits - 1))) || \
+ (((imm) < 0) && (~(imm) >> (bits - 1)))) { \
pr_info("[%2d] imm=%d(0x%x) out of range\n", \
i, imm, imm); \
would fix it. Alternatively:
#define check_imm(bits, imm) do { \
- if ((((imm) > 0) && ((imm) >> (bits))) || \
- (((imm) < 0) && (~(imm) >> (bits)))) { \
+ if ((imm) >= (1 << ((bits) - 1)) || \
+ (imm) < -(1 << ((bits) - 1))) { \
pr_info("[%2d] imm=%d(0x%x) out of range\n", \
i, imm, imm); \
would also fix it.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync@8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer
From: Andrzej Hajda @ 2018-05-10 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180504135212.26977-27-peda@axentia.se>
On 04.05.2018 15:52, Peter Rosin wrote:
> If the bridge supplier is unbound, this will bring the bridge consumer
> down along with the bridge. Thus, there will no longer linger any
> dangling pointers from the bridge consumer (the drm_device) to some
> non-existent bridge supplier.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/gpu/drm/drm_bridge.c | 18 ++++++++++++++++++
> include/drm/drm_bridge.h | 2 ++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 78d186b6831b..0259f0a3ff27 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -26,6 +26,7 @@
> #include <linux/mutex.h>
>
> #include <drm/drm_bridge.h>
> +#include <drm/drm_device.h>
> #include <drm/drm_encoder.h>
>
> #include "drm_crtc_internal.h"
> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct drm_bridge *bridge,
> if (bridge->dev)
> return -EBUSY;
>
> + if (encoder->dev->dev != bridge->odev) {
I wonder why device_link_add does not handle this case (self dependency)
silently as noop, as it seems to be a correct behavior.
> + bridge->link = device_link_add(encoder->dev->dev,
> + bridge->odev, 0);
> + if (!bridge->link) {
> + dev_err(bridge->odev, "failed to link bridge to %s\n",
> + dev_name(encoder->dev->dev));
> + return -EINVAL;
> + }
> + }
> +
> bridge->dev = encoder->dev;
> bridge->encoder = encoder;
>
> if (bridge->funcs->attach) {
> ret = bridge->funcs->attach(bridge);
> if (ret < 0) {
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> bridge->dev = NULL;
> bridge->encoder = NULL;
> return ret;
> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
> if (bridge->funcs->detach)
> bridge->funcs->detach(bridge);
>
> + if (bridge->link)
> + device_link_del(bridge->link);
> + bridge->link = NULL;
> +
> bridge->dev = NULL;
> }
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index b656e505d11e..804189c63a4c 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
> * @list: to keep track of all added bridges
> * @timings: the timing specification for the bridge, if any (may
> * be NULL)
> + * @link: drm consumer <-> bridge supplier
Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
to the bridge" would be better.
Anyway:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
?--
Regards
Andrzej
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -271,6 +272,7 @@ struct drm_bridge {
> struct drm_bridge *next;
> struct list_head list;
> const struct drm_bridge_timings *timings;
> + struct device_link *link;
>
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
^ permalink raw reply
* [PATCH 3/8] firmware: arm_scmi: rename get_transition_latency and add_opps_to_device
From: Rafael J. Wysocki @ 2018-05-10 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525885634-22348-4-git-send-email-sudeep.holla@arm.com>
On Wed, May 9, 2018 at 7:07 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Most of the scmi code follows the suggestion from Greg KH on a totally
> different thread[0] to have the subsystem name first, followed by the
> noun and finally the verb with couple of these exceptions.
>
> This patch fixes them so that all the functions names are aligned to
> on practice.
>
> [0] https://www.spinics.net/lists/arm-kernel/msg583673.html
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
ACK for the cpufreq driver changes and I'm assuming this to go in via the arch.
> ---
> drivers/cpufreq/scmi-cpufreq.c | 4 ++--
> drivers/firmware/arm_scmi/perf.c | 10 +++++-----
> include/linux/scmi_protocol.h | 10 +++++-----
> 3 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
> index b4dbc77459b6..50b1551ba894 100644
> --- a/drivers/cpufreq/scmi-cpufreq.c
> +++ b/drivers/cpufreq/scmi-cpufreq.c
> @@ -117,7 +117,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> return -ENODEV;
> }
>
> - ret = handle->perf_ops->add_opps_to_device(handle, cpu_dev);
> + ret = handle->perf_ops->device_opps_add(handle, cpu_dev);
> if (ret) {
> dev_warn(cpu_dev, "failed to add opps to the device\n");
> return ret;
> @@ -164,7 +164,7 @@ static int scmi_cpufreq_init(struct cpufreq_policy *policy)
> /* SCMI allows DVFS request for any domain from any CPU */
> policy->dvfs_possible_from_any_cpu = true;
>
> - latency = handle->perf_ops->get_transition_latency(handle, cpu_dev);
> + latency = handle->perf_ops->transition_latency_get(handle, cpu_dev);
> if (!latency)
> latency = CPUFREQ_ETERNAL;
>
> diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
> index 987c64d19801..611ab08e6174 100644
> --- a/drivers/firmware/arm_scmi/perf.c
> +++ b/drivers/firmware/arm_scmi/perf.c
> @@ -349,8 +349,8 @@ static int scmi_dev_domain_id(struct device *dev)
> return clkspec.args[0];
> }
>
> -static int scmi_dvfs_add_opps_to_device(const struct scmi_handle *handle,
> - struct device *dev)
> +static int scmi_dvfs_device_opps_add(const struct scmi_handle *handle,
> + struct device *dev)
> {
> int idx, ret, domain;
> unsigned long freq;
> @@ -383,7 +383,7 @@ static int scmi_dvfs_add_opps_to_device(const struct scmi_handle *handle,
> return 0;
> }
>
> -static int scmi_dvfs_get_transition_latency(const struct scmi_handle *handle,
> +static int scmi_dvfs_transition_latency_get(const struct scmi_handle *handle,
> struct device *dev)
> {
> struct perf_dom_info *dom;
> @@ -432,8 +432,8 @@ static struct scmi_perf_ops perf_ops = {
> .level_set = scmi_perf_level_set,
> .level_get = scmi_perf_level_get,
> .device_domain_id = scmi_dev_domain_id,
> - .get_transition_latency = scmi_dvfs_get_transition_latency,
> - .add_opps_to_device = scmi_dvfs_add_opps_to_device,
> + .transition_latency_get = scmi_dvfs_transition_latency_get,
> + .device_opps_add = scmi_dvfs_device_opps_add,
> .freq_set = scmi_dvfs_freq_set,
> .freq_get = scmi_dvfs_freq_get,
> };
> diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
> index a171c1e293e8..f4c9fc0fc755 100644
> --- a/include/linux/scmi_protocol.h
> +++ b/include/linux/scmi_protocol.h
> @@ -85,8 +85,8 @@ struct scmi_clk_ops {
> * @level_set: sets the performance level of a domain
> * @level_get: gets the performance level of a domain
> * @device_domain_id: gets the scmi domain id for a given device
> - * @get_transition_latency: gets the DVFS transition latency for a given device
> - * @add_opps_to_device: adds all the OPPs for a given device
> + * @transition_latency_get: gets the DVFS transition latency for a given device
> + * @device_opps_add: adds all the OPPs for a given device
> * @freq_set: sets the frequency for a given device using sustained frequency
> * to sustained performance level mapping
> * @freq_get: gets the frequency for a given device using sustained frequency
> @@ -102,10 +102,10 @@ struct scmi_perf_ops {
> int (*level_get)(const struct scmi_handle *handle, u32 domain,
> u32 *level, bool poll);
> int (*device_domain_id)(struct device *dev);
> - int (*get_transition_latency)(const struct scmi_handle *handle,
> + int (*transition_latency_get)(const struct scmi_handle *handle,
> struct device *dev);
> - int (*add_opps_to_device)(const struct scmi_handle *handle,
> - struct device *dev);
> + int (*device_opps_add)(const struct scmi_handle *handle,
> + struct device *dev);
> int (*freq_set)(const struct scmi_handle *handle, u32 domain,
> unsigned long rate, bool poll);
> int (*freq_get)(const struct scmi_handle *handle, u32 domain,
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH] armpmu: broadcast overflow irq on multi-core system having one muxed SPI for PMU.
From: Hoeun Ryu @ 2018-05-10 8:36 UTC (permalink / raw)
To: linux-arm-kernel
From: Hoeun Ryu <hoeun.ryu@lge.com>
On some SoCs like i.MX6DL/QL have only one muxed SPI for multi-core system.
On the systems, a CPU can be interrupted by overflow irq but it is possible that
the overflow actually occurs on another CPU.
This patch broadcasts the irq using smp_call_function() so that other CPUs can
check and handle their overflows by themselves when a overflow doesn't actually
occur on the interrupted CPU.
Local irq is enabled and preemption is disabled temporarily to call
smp_call_function_many() in armpmu_dispatch_irq() as the smp_call_function_many()
doesn't allow to be called with irq-disabled.
The callback for smp_call_function_many() is __armpmu_handle_irq() and the
function calls armpmu->handle_irq() with an invalid irq_num because
smp_call_func_t has only one parameter and armpmu pointer is handed over by the
pointer. It can be a problem if irq_num parameter is used by handlers but no
handler uses the irq parameter for now. We could have another approach removing
irq_num argument itself in handle_irq() function.
Signed-off-by: Hoeun Ryu <hoeun.ryu@lge.com>
---
drivers/perf/arm_pmu.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 48 insertions(+), 3 deletions(-)
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 1a0d340..3d65e44 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -322,6 +322,29 @@ validate_group(struct perf_event *event)
return 0;
}
+static void __armpmu_handle_irq(void *dev)
+{
+ struct arm_pmu *armpmu;
+ u64 start_clock, finish_clock;
+ irqreturn_t ret;
+
+ armpmu = *(void **)dev;
+ start_clock = sched_clock();
+ /*
+ * irq_num should not be used by the handler, we don't have irq_num for
+ * the first place. There is no handler using the irq_num argument for now.
+ * smp_call_func_t has one function argument and irq number cannot be handed
+ * over to this callback because we need dev pointer here.
+ * If you need valid irq_num, you need to declare a wrapper struct having
+ * irq_num and dev pointer.
+ */
+ ret = armpmu->handle_irq(-1, armpmu);
+ if (ret == IRQ_HANDLED) {
+ finish_clock = sched_clock();
+ perf_sample_event_took(finish_clock - start_clock);
+ }
+}
+
static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
{
struct arm_pmu *armpmu;
@@ -340,9 +363,31 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
start_clock = sched_clock();
ret = armpmu->handle_irq(irq, armpmu);
- finish_clock = sched_clock();
-
- perf_sample_event_took(finish_clock - start_clock);
+ /*
+ * The handler just returns with IRQ_NONE when it checks the overflow
+ * and the overflow doesn't occur on the CPU.
+ *
+ * Some SoCs like i.MX6 have one muxed SPI on multi-core system.
+ * On the systems , the irq should be broadcasted to other CPUs so that the
+ * CPUs can check their own PMU overflow.
+ */
+ if (ret == IRQ_HANDLED) {
+ finish_clock = sched_clock();
+ perf_sample_event_took(finish_clock - start_clock);
+ } else if (ret == IRQ_NONE) {
+ struct cpumask mask;
+
+ cpumask_copy(&mask, cpu_online_mask);
+ cpumask_clear_cpu(raw_smp_processor_id(), &mask);
+ if (!cpumask_empty(&mask)) {
+ /* smp_call_function cannot be called with irq disabled */
+ local_irq_enable();
+ preempt_disable();
+ smp_call_function_many(&mask, __armpmu_handle_irq, dev, 0);
+ preempt_enable();
+ local_irq_disable();
+ }
+ }
return ret;
}
--
2.1.4
^ permalink raw reply related
* [PATCH 1/2] i2c: exynos5: remove some dead code
From: Andrzej Hajda @ 2018-05-10 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509194532.28929-1-peda@axentia.se>
On 09.05.2018 21:45, Peter Rosin wrote:
> The else branch cannot be taken as i will always equal num.
> Get rid of the whole construct.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/i2c/busses/i2c-exynos5.c | 12 +-----------
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
> index 12ec8484e653..a2cbc779c33a 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -727,17 +727,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
> goto out;
> }
>
> - if (i == num) {
> - ret = num;
> - } else {
> - /* Only one message, cannot access the device */
> - if (i == 1)
> - ret = -EREMOTEIO;
> - else
> - ret = i;
> -
> - dev_warn(i2c->dev, "xfer message failed\n");
> - }
> + ret = num;
>
> out:
> clk_disable(i2c->clk);
You can go further and remove "out:" label, use break instead, and at
the end use "return (i == num) ? num : ret;" or sth similar.
With this change you can add:
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
?--
Regards
Andrzej
^ permalink raw reply
* [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules
From: Russell King - ARM Linux @ 2018-05-10 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87k1scs0f8.fsf@xmission.com>
On Wed, May 09, 2018 at 09:35:07PM -0500, Eric W. Biederman wrote:
> Mathieu Poirier <mathieu.poirier@linaro.org> writes:
>
> > On Tue, May 08, 2018 at 11:59:38PM -0500, Eric W. Biederman wrote:
> >> Kim Phillips <kim.phillips@arm.com> writes:
> >>
> >> > This patch is in the context of allowing the Coresight h/w
> >> > trace driver suite to be loaded as modules. Coresight uses
> >> > find_task_by_vpid when running in direct capture mode (via sysfs)
> >> > when getting/setting the context ID comparator to trigger on
> >> > (/sys/bus/coresight/devices/<x>.etm/ctxid_pid).
> >>
> >> Aside from my objection about how bad an interface a pid in sysfs is.
> >> The implementation of coresight_vpid_to_pid is horrible.
> >>
> >> The code should be just:
> >>
> >> static inline pid_t coresight_vpid_to_pid(pid_t vpid)
> >> {
> >> rcu_read_lock();
> >> pid = pid_nr(find_vpid(vpid));
> >> rcu_read_unlock();
> >>
> >> return pid;
> >> }
> >> Which takes find_task_by_vpid out of the picture.
> >
> > Many thanks for pointing out the right way to do this. When Chunyan added
> > this feature she broadly published her work and find_task_by_vpid() is the
> > function she was asked to used.
>
> Clearly no one was thinking through the implications of a sysfs file
> which does not have pid namespace support on namespacing. I am quite
> upset at this mess of an API. It is not a maintainable way to do things.
>
> >> But reading further I am seeing code writing a pid to hardware. That is
> >> broken. That is a layering violation of the first order. Giving
> >> implementation details like that to hardware.
> >
> > This is how the feature works - as Robin pointed out tracers are designed to
> > match pid values with the CPU's contextID register. The input value has no
> > other effect than triggering trace collection, which has absolutely no baring on
> > the CPU.
>
> So please tell me how we make the tracer pid namespace aware. Or is it
> guaranteed that only the global root user will use this functionality?
>
> As you are taking a vpid it looks like users with lesser privileges are
> able to request this. From the other reply it appears this is the
> value the tracer returns to put in logs. Perhaps I missed it but I
> didn't see anything that translated from the global pid to something
> else. Which would make using this feature in a pid namespace confusing
> and a problematic information leak if I have understood what has been
> said so far.
Let's look to see what's placed into the context ID register - this is
done by arch/arm/mm/context.c::contextidr_notifier():
pid = task_pid_nr(thread->task) << ASID_BITS;
This is documented in linux/sched.h as:
* task_xid_nr() : global id, i.e. the id seen from the init namespace;
So, what ends up in the context ID register is the _global_ PID, not a
namespace specific PID. This means the hardware deals with global PID
values.
It seems quite logical to use the global PID value for the hardware,
because that is a globally unique value - especially as the hardware
uses this for filtering events. So asking for a namespace's pid 1
gets mapped to the global pid value, which won't match some other
namespace's pid 1.
The problem comes _if_ the event stream delivered to userspace contains
the global PID values and the event stream is being looked at from
within a namespace.
This does not leak information from other namespaces because of the
uniqueness of the global PID. However, what it does leak is the value
of the global PID which is meaningless in the namespace. So, before
the event stream is delivered to userspace, this value needs to be
re-written to the namespace's PID value.
Things get more yucky with this when you look at the ctxid_masks stuff
- which looks to me like it implements a mask on the PID value. Masks
on the pid value are irrelevant from within a namespace, because the
mask is applied to the global PID value, not the namespace's PID value.
You can't really define how a set of namespace PIDs will map to global
PIDs, so masking the context ID PID value in the presence of namespaces
is pretty useless - and potentially ends up being an information leak.
As for the sysfs file thing, I think the simple solution to that is
the sysfs file should accept a PID value in the current namespace,
and translate that to the global namespace - and the global PID value
should be stored. When reading, the global PID value should be
translated back to the current namespace, or an error/empty given if
the PID doesn't exist in that namespace. The current solution to
store the vpid and simply return it irrespective of the namespace is
just nonsense.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync@8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply
* [PATCH 2/2] i2c: exynos5: remove pointless initializers
From: Andrzej Hajda @ 2018-05-10 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180509194532.28929-2-peda@axentia.se>
On 09.05.2018 21:45, Peter Rosin wrote:
> The variables are always assigned before use anyway.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
> ---
> drivers/i2c/busses/i2c-exynos5.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
> index a2cbc779c33a..185fba37e830 100644
> --- a/drivers/i2c/busses/i2c-exynos5.c
> +++ b/drivers/i2c/busses/i2c-exynos5.c
> @@ -707,7 +707,7 @@ static int exynos5_i2c_xfer(struct i2c_adapter *adap,
> struct i2c_msg *msgs, int num)
> {
> struct exynos5_i2c *i2c = adap->algo_data;
> - int i = 0, ret = 0, stop = 0;
> + int i, ret, stop;
I hope gcc is smart enough to not complain in case of ret.
I think you can merge both patches into one.
Regards
Andrzej
>
> if (i2c->suspended) {
> dev_err(i2c->dev, "HS-I2C is not initialized.\n");
^ permalink raw reply
* [PATCH] bpf, arm32: Correct check_imm24
From: Wang YanQing @ 2018-05-10 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180510075656.GS16141@n2100.armlinux.org.uk>
On Thu, May 10, 2018 at 08:56:57AM +0100, Russell King - ARM Linux wrote:
> On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote:
> > imm24 is signed, so the right range is:
> > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1]
>
> 2 << (24 - 1) is the same as 1 << 24.
>
> > -#define check_imm(bits, imm) do { \
> > - if ((((imm) > 0) && ((imm) >> (bits))) || \
> > - (((imm) < 0) && (~(imm) >> (bits)))) { \
> > - pr_info("[%2d] imm=%d(0x%x) out of range\n", \
> > - i, imm, imm); \
> > +#define check_imm_range(min, max, imm) do { \
> > + if (imm < min || imm > max) { \
> > + pr_info("[%2d] imm=%d is out of range\n", \
> > + i, imm); \
> > return -EINVAL; \
> > } \
> > } while (0)
> > -#define check_imm24(imm) check_imm(24, imm)
> > +#define check_imm24(imm) check_imm_range(-16777216, 16777215, imm)
>
> How is this any different?
>
> If imm is 16777216, then "imm > max" in your version is true.
> In the original version, "imm > 0" is true, so we then test for
> "16777216 >> 24" being non-zero. That's also true, so the test
> condition fires.
>
> If imm is 16777215, then "imm > max" is false in your version.
> In the original version, the conditions also evaluate to false.
>
> For the -16777217 case, "imm < min" in your version is true.
> In the original version, "imm < 0" is true, so we then test for
> "~(-16777217) >> 24" being non-zero. This is the same as
> "16777216 >> 24" being non-zero, which is true so the condition
> fires.
>
> With -16777216, the same thing happens, both end up evaluating
> to false.
>
> So, the two cases end up producing identical results, and there
> is no actual effect from this change.
>
> However, your commit message is correct - there is a bug here.
> That's obvious when you mask the "imm" value with 0x00ffffff,
> and realise that an imm value of -16777216 ends up having the
> same value in the instruction as an imm value of 0. So, the
> range of "imm" is _half_ that.
>
> #define check_imm(bits, imm) do { \
> - if ((((imm) > 0) && ((imm) >> (bits))) || \
> - (((imm) < 0) && (~(imm) >> (bits)))) { \
> + if ((((imm) > 0) && ((imm) >> (bits - 1))) || \
> + (((imm) < 0) && (~(imm) >> (bits - 1)))) { \
> pr_info("[%2d] imm=%d(0x%x) out of range\n", \
> i, imm, imm); \
>
> would fix it. Alternatively:
>
> #define check_imm(bits, imm) do { \
> - if ((((imm) > 0) && ((imm) >> (bits))) || \
> - (((imm) < 0) && (~(imm) >> (bits)))) { \
> + if ((imm) >= (1 << ((bits) - 1)) || \
> + (imm) < -(1 << ((bits) - 1))) { \
> pr_info("[%2d] imm=%d(0x%x) out of range\n", \
> i, imm, imm); \
>
> would also fix it.
Hi!
Sorry for confusion, I make a mistake here, the real fix I want to
submit is [8388607, -8388608], this range has the same effect as your
suggestion.
Will you fix it? or I resend another version?
Thanks.
^ permalink raw reply
* [PATCH] arm64: msm8916: fix gic_irq_domain_translate warnings
From: Amit Kucheria @ 2018-05-10 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180418163415.21646-1-srinivas.kandagatla@linaro.org>
On Wed, Apr 18, 2018 at 7:34 PM, <srinivas.kandagatla@linaro.org> wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>
> Remove the usage of IRQ_TYPE_NONE to fix loud warnings from
> patch (83a86fbb5b56b "irqchip/gic: Loudly complain about
> the use of IRQ_TYPE_NONE").
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Tested-by: Amit Kucheria <amit.kucheria@linaro.org>
(boot report here:
https://storage.kernelci.org/qcom-lt/integration-linux-qcomlt/v4.17-rc4-247-gbe94bee41bf6/arm64/defconfig/lab-bjorn/boot-apq8016-sbc.txt)
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index cfbd72186762..5d66a575c7e1 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -180,7 +180,7 @@
>
> pmu {
> compatible = "arm,cortex-a53-pmu";
> - interrupts = <GIC_PPI 7 GIC_CPU_MASK_SIMPLE(4)>;
> + interrupts = <GIC_PPI 7 (GIC_CPU_MASK_SIMPLE(4)| IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> thermal-zones {
> @@ -513,7 +513,7 @@
> blsp_i2c2: i2c at 78b6000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078b6000 0x500>;
> - interrupts = <GIC_SPI 96 0>;
> + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>;
> clock-names = "iface", "core";
> @@ -528,7 +528,7 @@
> blsp_i2c4: i2c at 78b8000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078b8000 0x500>;
> - interrupts = <GIC_SPI 98 0>;
> + interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP4_I2C_APPS_CLK>;
> clock-names = "iface", "core";
> @@ -543,7 +543,7 @@
> blsp_i2c6: i2c at 78ba000 {
> compatible = "qcom,i2c-qup-v2.2.1";
> reg = <0x078ba000 0x500>;
> - interrupts = <GIC_SPI 100 0>;
> + interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_AHB_CLK>,
> <&gcc GCC_BLSP1_QUP6_I2C_APPS_CLK>;
> clock-names = "iface", "core";
> @@ -575,7 +575,7 @@
> "mi2s-bit-clk3";
> #sound-dai-cells = <1>;
>
> - interrupts = <0 160 0>;
> + interrupts = <0 160 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "lpass-irq-lpaif";
> reg = <0x07708000 0x10000>;
> reg-names = "lpass-lpaif";
> @@ -595,7 +595,7 @@
> reg = <0x07824900 0x11c>, <0x07824000 0x800>;
> reg-names = "hc_mem", "core_mem";
>
> - interrupts = <0 123 0>, <0 138 0>;
> + interrupts = <0 123 IRQ_TYPE_LEVEL_HIGH>, <0 138 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "hc_irq", "pwr_irq";
> clocks = <&gcc GCC_SDCC1_APPS_CLK>,
> <&gcc GCC_SDCC1_AHB_CLK>,
> @@ -612,7 +612,7 @@
> reg = <0x07864900 0x11c>, <0x07864000 0x800>;
> reg-names = "hc_mem", "core_mem";
>
> - interrupts = <0 125 0>, <0 221 0>;
> + interrupts = <0 125 IRQ_TYPE_LEVEL_HIGH>, <0 221 IRQ_TYPE_LEVEL_HIGH>;
> interrupt-names = "hc_irq", "pwr_irq";
> clocks = <&gcc GCC_SDCC2_APPS_CLK>,
> <&gcc GCC_SDCC2_AHB_CLK>,
> @@ -819,7 +819,7 @@
> iommu-ctx at 2000 {
> compatible = "qcom,msm-iommu-v1-ns";
> reg = <0x2000 0x1000>;
> - interrupts = <GIC_SPI 242 0>;
> + interrupts = <GIC_SPI 242 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
>
> @@ -864,7 +864,7 @@
> "bus_clk",
> "vsync_clk";
>
> - interrupts = <0 72 0>;
> + interrupts = <0 72 IRQ_TYPE_LEVEL_HIGH>;
>
> interrupt-controller;
> #interrupt-cells = <1>;
> --
> 2.16.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V3] ARM: dts: da850-evm: use phandles to extend nodes
From: Sekhar Nori @ 2018-05-10 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180507123721.9264-1-aford173@gmail.com>
On Monday 07 May 2018 06:07 PM, Adam Ford wrote:
> Many node labels in the device tree (like serial0, serial1, etc) are being
> redefined, so let's modernize the device tree by using phandles to
> extend the existing nodes. This helps reduce the whitespace.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
I applied this without the pmic changes. I am not convinced about those.
The tps node is already being referred to as phandle. I am not sure
referring to each individual regulator using phandle is needed. Other
files like am335x-evm.dts don't do it as well.
Another thing is whether we really need the tp6507x.dtsi file. It does
not seem to contain much and also da850-evm.dts is the only file
including it. So it seems pretty pointless to me.
Here is what I committed.
Thanks,
Sekhar
---8<---
commit ae62a32d6019a8225e2c32e631b8b0d039151131 (refs/heads/v4.18/dt)
Author: Adam Ford <aford173@gmail.com>
AuthorDate: Mon May 7 07:37:21 2018 -0500
Commit: Sekhar Nori <nsekhar@ti.com>
CommitDate: Thu May 10 14:01:15 2018 +0530
ARM: dts: da850-evm: use phandles to extend nodes
Many node labels in the device tree (like serial0, serial1, etc) are being
redefined, so let's modernize the device tree by using phandles to
extend the existing nodes. This helps reduce the whitespace.
Signed-off-by: Adam Ford <aford173@gmail.com>
[nsekhar at ti.com: drop tps6507x related changes]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 339cae353302..9389f95f4094 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -27,143 +27,6 @@
spi0 = &spi1;
};
- soc at 1c00000 {
- pmx_core: pinmux at 14120 {
- status = "okay";
-
- mcasp0_pins: pinmux_mcasp0_pins {
- pinctrl-single,bits = <
- /*
- * AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
- * AFSR, AMUTE
- */
- 0x00 0x11111111 0xffffffff
- /* AXR11, AXR12 */
- 0x04 0x00011000 0x000ff000
- >;
- };
- nand_pins: nand_pins {
- pinctrl-single,bits = <
- /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[4], EMA_CS[3] */
- 0x1c 0x10110110 0xf0ff0ff0
- /*
- * EMA_D[0], EMA_D[1], EMA_D[2],
- * EMA_D[3], EMA_D[4], EMA_D[5],
- * EMA_D[6], EMA_D[7]
- */
- 0x24 0x11111111 0xffffffff
- /* EMA_A[1], EMA_A[2] */
- 0x30 0x01100000 0x0ff00000
- >;
- };
- };
- serial0: serial at 42000 {
- status = "okay";
- };
- serial1: serial at 10c000 {
- status = "okay";
- };
- serial2: serial at 10d000 {
- status = "okay";
- };
- rtc0: rtc at 23000 {
- status = "okay";
- };
- i2c0: i2c at 22000 {
- status = "okay";
- clock-frequency = <100000>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_pins>;
-
- tps: tps at 48 {
- reg = <0x48>;
- };
- tlv320aic3106: tlv320aic3106 at 18 {
- #sound-dai-cells = <0>;
- compatible = "ti,tlv320aic3106";
- reg = <0x18>;
- status = "okay";
-
- /* Regulators */
- IOVDD-supply = <&vdcdc2_reg>;
- /* Derived from VBAT: Baseboard 3.3V / 1.8V */
- AVDD-supply = <&vbat>;
- DRVDD-supply = <&vbat>;
- DVDD-supply = <&vbat>;
- };
- tca6416: gpio at 20 {
- compatible = "ti,tca6416";
- reg = <0x20>;
- gpio-controller;
- #gpio-cells = <2>;
- };
- };
- wdt: wdt at 21000 {
- status = "okay";
- };
- mmc0: mmc at 40000 {
- max-frequency = <50000000>;
- bus-width = <4>;
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mmc0_pins>;
- };
- spi1: spi at 30e000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;
- flash: m25p80 at 0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "m25p64";
- spi-max-frequency = <30000000>;
- m25p,fast-read;
- reg = <0>;
- partition at 0 {
- label = "U-Boot-SPL";
- reg = <0x00000000 0x00010000>;
- read-only;
- };
- partition at 1 {
- label = "U-Boot";
- reg = <0x00010000 0x00080000>;
- read-only;
- };
- partition at 2 {
- label = "U-Boot-Env";
- reg = <0x00090000 0x00010000>;
- read-only;
- };
- partition at 3 {
- label = "Kernel";
- reg = <0x000a0000 0x00280000>;
- };
- partition at 4 {
- label = "Filesystem";
- reg = <0x00320000 0x00400000>;
- };
- partition at 5 {
- label = "MAC-Address";
- reg = <0x007f0000 0x00010000>;
- read-only;
- };
- };
- };
- mdio: mdio at 224000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mdio_pins>;
- bus_freq = <2200000>;
- };
- eth0: ethernet at 220000 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&mii_pins>;
- };
- gpio: gpio at 226000 {
- status = "okay";
- };
- };
vbat: fixedregulator0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -200,6 +63,153 @@
};
};
+&pmx_core {
+ status = "okay";
+
+ mcasp0_pins: pinmux_mcasp0_pins {
+ pinctrl-single,bits = <
+ /*
+ * AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
+ * AFSR, AMUTE
+ */
+ 0x00 0x11111111 0xffffffff
+ /* AXR11, AXR12 */
+ 0x04 0x00011000 0x000ff000
+ >;
+ };
+ nand_pins: nand_pins {
+ pinctrl-single,bits = <
+ /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[4], EMA_CS[3] */
+ 0x1c 0x10110110 0xf0ff0ff0
+ /*
+ * EMA_D[0], EMA_D[1], EMA_D[2],
+ * EMA_D[3], EMA_D[4], EMA_D[5],
+ * EMA_D[6], EMA_D[7]
+ */
+ 0x24 0x11111111 0xffffffff
+ /* EMA_A[1], EMA_A[2] */
+ 0x30 0x01100000 0x0ff00000
+ >;
+ };
+};
+
+&serial0 {
+ status = "okay";
+};
+
+&serial1 {
+ status = "okay";
+};
+
+&serial2 {
+ status = "okay";
+};
+
+&rtc0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+
+ tps: tps at 48 {
+ reg = <0x48>;
+ };
+ tlv320aic3106: tlv320aic3106 at 18 {
+ #sound-dai-cells = <0>;
+ compatible = "ti,tlv320aic3106";
+ reg = <0x18>;
+ status = "okay";
+
+ /* Regulators */
+ IOVDD-supply = <&vdcdc2_reg>;
+ /* Derived from VBAT: Baseboard 3.3V / 1.8V */
+ AVDD-supply = <&vbat>;
+ DRVDD-supply = <&vbat>;
+ DVDD-supply = <&vbat>;
+ };
+ tca6416: gpio at 20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&wdt {
+ status = "okay";
+};
+
+&mmc0 {
+ max-frequency = <50000000>;
+ bus-width = <4>;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+};
+
+&spi1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi1_pins &spi1_cs0_pin>;
+ flash: m25p80 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p64";
+ spi-max-frequency = <30000000>;
+ m25p,fast-read;
+ reg = <0>;
+ partition at 0 {
+ label = "U-Boot-SPL";
+ reg = <0x00000000 0x00010000>;
+ read-only;
+ };
+ partition at 1 {
+ label = "U-Boot";
+ reg = <0x00010000 0x00080000>;
+ read-only;
+ };
+ partition at 2 {
+ label = "U-Boot-Env";
+ reg = <0x00090000 0x00010000>;
+ read-only;
+ };
+ partition at 3 {
+ label = "Kernel";
+ reg = <0x000a0000 0x00280000>;
+ };
+ partition at 4 {
+ label = "Filesystem";
+ reg = <0x00320000 0x00400000>;
+ };
+ partition at 5 {
+ label = "MAC-Address";
+ reg = <0x007f0000 0x00010000>;
+ read-only;
+ };
+ };
+};
+
+&mdio {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ bus_freq = <2200000>;
+};
+
+ð0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mii_pins>;
+};
+
+&gpio {
+ status = "okay";
+};
+
/include/ "tps6507x.dtsi"
&tps {
^ permalink raw reply related
* [PATCH v1 0/5] Add sdmmc UHS support to ROC-RK3328-CC board.
From: djw at t-chip.com.cn @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
From: Levin Du <djw@t-chip.com.cn>
Hi all, this is an attemp to add sdmmc UHS support to the
ROC-RK3328-CC board.
This patch series adds a new compatible `rockchip,gpio-syscon` to
the gpio-syscon driver for general Rockchip SoC usage..
A new gpio controller named `gpio_syscon10` is defined in
rk3328.dtsi so that all rk3328 boards has access to it.
The ROC-RK3328-CC board use the new gpio <&gpio_syscon10 1> in
gpio-regulator to control the signal voltage of the sdmmc.
It is essential for UHS support which requires 1.8V signal voltage.
Many thanks to Heiko's great advice!
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt .
- Split into small patches.
- Add gpio-syscon10 to rk3328 for general use.
- Sort dts properties in sdmmc node.
Heiko Stuebner (1):
gpio: syscon: allow fetching syscon from parent node
Levin Du (4):
gpio: syscon: Add gpio-syscon for rockchip
arm64: dts: rockchip: Add gpio-syscon10 to rk3328
arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc
.../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 30 ++++++++++++++++
arch/arm64/boot/dts/rockchip/rk3328.dtsi | 6 ++++
drivers/gpio/gpio-syscon.c | 32 +++++++++++++++++
4 files changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
--
2.7.4
^ permalink raw reply
* [reset-control] How to initialize hardware state with the shared reset line?
From: Masahiro Yamada @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi.
The previous thread was:
"usb: dwc3: support clocks and resets for DWC3 core"
https://patchwork.kernel.org/patch/10349623/
I changed the subject because
I think this is rather reset-control topic than USB.
I am searching for a good way to initialize hardware devices
in the following situation:
- two or more hardware devices share the same reset line
- those devices are not reset before booting the kernel
(i.e. flip flops in RTL are random state at driver probe)
- the hardware IP is used by various SoCs,
and this issue only appears only on some.
Specifically, the DWC3 USB IP case is in my mind,
but this should apply to any hardware in general.
Issue in detail
---------------
The DWC3 USB IP is very popular and used by various SoCs
as you see in drivers/usb/dwc3/.
SoCs are using the same RTL as provided by Synopsys.
(SoC vendors could tweak the RTL if they like,
but it would rarely happen because it would just be troublesome)
So, let's assume we use the same IP with the same RTL version.
It is *compatible* in terms of device tree.
In this case, we should avoid differentiating the driver code per-SoC.
In fact, we ended up with
commit ff0a632 ("usb: dwc3: of-simple: add support for shared and
pulsed reset lines")
commit e8284db ("usb: dwc3: of-simple: add support for the Amlogic
Meson GXL and AXG SoCs")
This means, the difference that comes from the reset _provider_
must be implemented in the reset _consumer_.
This is unfortunate.
So, I wonder if we can support it in sub-system level somehow
instead of messing up the reset consumer driver.
- The reset topology is SoC-dependent.
A reset line is dedicated for single hardware for some SoCs,
and shared by multiple hardware for others.
- The reset policy (pulse reset, level reset, or both of them)
are SoC-dependent (reset controller dependent).
RTL generally contains state machines.
The initial state of flip flops are undefined on power-on
hence the initial state of state machines are also undefined.
So, digital circuits needs explicit reset in general.
In some cases, the reset is performed before booting the kernel.
- power-on reset
(FFs are put into defined state on power-on automatically)
- a reset controller assert reset lines by default
(FFs are fixed to defined state. If a reset consumer
driver deasserts the reset line, HW starts from the define state)
- Firmware may reset the hardware before booting the kernel
If nothing above is done, and the reset line is shared by multiple devices,
we do not have a good way to put the hardware into the sane state.
Reset consumers choose the required reset type:
- Shared reset:
reset_control_assert / reset_control_deassert work like
clock_disable / clock_enable.
The consumer must be tolerant to the situation where the HW may
not reset-asserted.
- Exclusive reset:
It is guaranteed reset_control_assert() really asserts the reset line,
but only one reset consumer grabs the reset line at the same time.
As above, the state machines in digital circuits must start from a
defined state.
So, we want exclusive reset to reset the FFs.
However, this is too much requirement
since it is a reset line is often shared.
How to save such an Amlogic case?
Hogging solve the problem?
--------------------------
I was thinking of a solution.
I may be missing something, but
one solution might be reset hogging on the
reset provider side. This allows us to describe
the initial state of reset lines in the reset controller.
The idea for "reset-hog" is similar to:
- "gpio-hog" defined in
Documentation/devicetree/bindings/gpio/gpio.txt
- "assigned-clocks" defined in
Documetation/devicetree/bindings/clock/clock-bindings.txt
For example,
reset-controller {
....
line_a {
reset-hog;
resets = <1>;
reset-assert;
};
}
When the reset controller is registered,
the reset ID '1' is asserted.
So, all reset consumers that share the reset line '1'
will start from the asserted state
(i.e. defined state machine state).
>From the discussion with Martin Blumenstingl
(https://lkml.org/lkml/2018/4/28/115),
the problem for Amlogic is that
the reset line is "de-asserted" by default.
If so, the 'reset-hog' would fix the problem,
and DWC3 driver would be able to use
shared, level reset, I think.
I think something may be missing from my mind,
but I hope this will prompt the discussion,
and we will find a better idea.
Thanks.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v1 2/5] gpio: syscon: Add gpio-syscon for rockchip
From: djw at t-chip.com.cn @ 2018-05-10 9:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1525943800-14095-1-git-send-email-djw@t-chip.com.cn>
From: Levin Du <djw@t-chip.com.cn>
Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
which do not belong to the general pinctrl.
Adding gpio-syscon support makes controlling regulator or
LED using these special pins very easy by reusing existing
drivers, such as gpio-regulator and led-gpio.
Signed-off-by: Levin Du <djw@t-chip.com.cn>
---
Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
.../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++++++++++++++++++++++
drivers/gpio/gpio-syscon.c | 30 ++++++++++++++++
2 files changed, 71 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
new file mode 100644
index 0000000..e4c1650
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
@@ -0,0 +1,41 @@
+* Rockchip GPIO support for GRF_SOC_CON registers
+
+Required properties:
+- compatible: Should contain "rockchip,gpio-syscon".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+ the second cell is used to specify the gpio polarity:
+ 0 = Active high,
+ 1 = Active low.
+- gpio,syscon-dev: Should contain <grf_phandle syscon_offset 0>.
+ If declared as child of the grf node, the grf_phandle can be 0.
+
+Example:
+
+1. As child of grf node:
+
+ grf: syscon at ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+
+ gpio_syscon10: gpio-syscon10 {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <0 0x0428 0>;
+ };
+ };
+
+
+2. Not child of grf node:
+
+ grf: syscon at ff100000 {
+ compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+ //...
+ };
+
+ gpio_syscon10: gpio-syscon10 {
+ compatible = "rockchip,gpio-syscon";
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio,syscon-dev = <&grf 0x0428 0>;
+ };
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 7325b86..e24b408 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -135,6 +135,32 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio = {
.dat_bit_offset = 0x40 * 8 + 8,
};
+static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+ struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
+ unsigned int offs;
+ u8 bit;
+ u32 data;
+ int ret;
+
+ offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
+ bit = offs % SYSCON_REG_BITS;
+ data = (val ? BIT(bit) : 0) | BIT(bit + 16);
+ ret = regmap_write(priv->syscon,
+ (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
+ data);
+ if (ret < 0)
+ dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
+}
+
+static const struct syscon_gpio_data rockchip_gpio_syscon = {
+ /* Rockchip GRF_SOC_CON Bits 0-15 */
+ .flags = GPIO_SYSCON_FEAT_OUT,
+ .bit_count = 16,
+ .set = rockchip_gpio_set,
+};
+
#define KEYSTONE_LOCK_BIT BIT(0)
static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
@@ -175,6 +201,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
.compatible = "ti,keystone-dsp-gpio",
.data = &keystone_dsp_gpio,
},
+ {
+ .compatible = "rockchip,gpio-syscon",
+ .data = &rockchip_gpio_syscon,
+ },
{ }
};
MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
--
2.7.4
^ permalink raw reply related
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