RE: [PATCH v4 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
Hi, > >On Thu, Feb 14, 2019 at 07:45:13PM +, Pawel Laszczak wrote: >> This patch introduce new Cadence USBSS DRD driver to linux kernel. > >Nit, "Linux" :) > >> The Cadence USBSS DRD Driver is a highly configurable IP Core whichi > >"whichi"? > >> can be instantiated as Dual-Role Device (DRD), Peripheral Only and >> Host Only (XHCI)configurations. >> >> The current driver has been validated with FPGA burned. We have support > >I can not parse that sentance, sorry. what does "with FPGA burned" >mean? I met with such sentence, and It's means that implementation (IP Core) Is loaded to FPGA. Maybe it was used from some historical reason, and nowadays it is not correct. I will replace it with ".. which is used on FPGA prototyping." > >> for PCIe bus, which is used on FPGA prototyping. >> >> The host side of USBSS-DRD controller is compliance with XHCI > >"compliant" > >> specification, so it works with standard XHCI linux driver. > >"Linux" > >> >> Signed-off-by: Pawel Laszczak >> --- >> drivers/usb/Kconfig|2 + >> drivers/usb/Makefile |2 + >> drivers/usb/cdns3/Kconfig | 44 + >> drivers/usb/cdns3/Makefile | 14 + >> drivers/usb/cdns3/cdns3-pci-wrap.c | 155 +++ >> drivers/usb/cdns3/core.c | 403 ++ >> drivers/usb/cdns3/core.h | 116 ++ >> drivers/usb/cdns3/debug.h | 168 +++ >> drivers/usb/cdns3/debugfs.c| 164 +++ >> drivers/usb/cdns3/drd.c| 365 + >> drivers/usb/cdns3/drd.h| 162 +++ >> drivers/usb/cdns3/ep0.c| 907 + >> drivers/usb/cdns3/gadget-export.h | 28 + >> drivers/usb/cdns3/gadget.c | 2003 >> drivers/usb/cdns3/gadget.h | 1207 + >> drivers/usb/cdns3/host-export.h| 28 + >> drivers/usb/cdns3/host.c | 72 + >> drivers/usb/cdns3/trace.c | 23 + >> drivers/usb/cdns3/trace.h | 404 ++ >> 19 files changed, 6267 insertions(+) >> create mode 100644 drivers/usb/cdns3/Kconfig >> create mode 100644 drivers/usb/cdns3/Makefile >> create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c >> create mode 100644 drivers/usb/cdns3/core.c >> create mode 100644 drivers/usb/cdns3/core.h >> create mode 100644 drivers/usb/cdns3/debug.h >> create mode 100644 drivers/usb/cdns3/debugfs.c >> create mode 100644 drivers/usb/cdns3/drd.c >> create mode 100644 drivers/usb/cdns3/drd.h >> create mode 100644 drivers/usb/cdns3/ep0.c >> create mode 100644 drivers/usb/cdns3/gadget-export.h >> create mode 100644 drivers/usb/cdns3/gadget.c >> create mode 100644 drivers/usb/cdns3/gadget.h >> create mode 100644 drivers/usb/cdns3/host-export.h >> create mode 100644 drivers/usb/cdns3/host.c >> create mode 100644 drivers/usb/cdns3/trace.c >> create mode 100644 drivers/usb/cdns3/trace.h >> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig >> index 987fc5ba6321..5f9334019d04 100644 >> --- a/drivers/usb/Kconfig >> +++ b/drivers/usb/Kconfig >> @@ -112,6 +112,8 @@ source "drivers/usb/usbip/Kconfig" >> >> endif >> >> +source "drivers/usb/cdns3/Kconfig" >> + >> source "drivers/usb/mtu3/Kconfig" >> >> source "drivers/usb/musb/Kconfig" >> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile >> index 7d1b8c82b208..ab125b966cac 100644 >> --- a/drivers/usb/Makefile >> +++ b/drivers/usb/Makefile >> @@ -12,6 +12,8 @@ obj-$(CONFIG_USB_DWC3) += dwc3/ >> obj-$(CONFIG_USB_DWC2) += dwc2/ >> obj-$(CONFIG_USB_ISP1760) += isp1760/ >> >> +obj-$(CONFIG_USB_CDNS3) += cdns3/ >> + >> obj-$(CONFIG_USB_MON) += mon/ >> obj-$(CONFIG_USB_MTU3) += mtu3/ >> >> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig >> new file mode 100644 >> index ..27cb3d8dbe3d >> --- /dev/null >> +++ b/drivers/usb/cdns3/Kconfig >> @@ -0,0 +1,44 @@ >> +config USB_CDNS3 >> +tristate "Cadence USB3 Dual-Role Controller" >> +depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA >> +help >> + Say Y here if your system has a cadence USB3 dual-role controller. >> + It supports: dual-role switch, Host-only, and Peripheral-only. >> + >> + If you choose to build this driver is a dynamically linked >> + as module, the module will be called cdns3.ko. >> + >> +if USB_CDNS3 >> + >> +config USB_CDNS3_GADGET >> +bool "Cadence USB3 device controller" >> +depends on USB_GADGET >> +help >> + Say Y here to enable device controller functionality of the >> + cadence USBSS-DEV driver. >> + >> + This controller supports FF, HS and SS mode. It doesn't support >> + LS and SSP mode. >> + >> +config USB_CDNS3_HOST >> +bool "Cadence USB3 host controller" >> +depends on USB_XHCI_HCD >> +help >> + Say Y here to enable host controller functionality of the >> + cadence driver. >> + >> +
Re: [PATCH 8/8] usb: dwc3: Add Amlogic G12A DWC3 glue
Hi,
On 02/03/2019 11:29, Martin Blumenstingl wrote:
> Hi Neil,
>
>>> +static int dwc3_meson_g12a_debugfs_init(struct dwc3_meson_g12a *priv)
>>> +{
>>> + priv->root = debugfs_create_dir("dwc3-meson-g12a", NULL);
>>> + if (IS_ERR(priv->root))
>>> + return PTR_ERR(priv->root);
>>> +
>>> + debugfs_create_file("mode_force", 0600, priv->root, priv,
>>> + &dwc3_meson_g12a_mode_force_fops);
>>> +
>>> + debugfs_create_file("otg_id", 0400, priv->root, priv,
>>> + &dwc3_meson_g12a_otg_id_fops);
>>> +
>>> + return 0;
>>> +}
> I just stumbled across the "USB role switch framework", see [0]
> it seems to provide a userspace API as well and two in-kernel drivers
> are using this framework already
> (drivers/usb/gadget/udc/renesas_usb3.c,
> drivers/usb/roles/intel-xhci-usb-role-switch.c)
Just added support for it, works perfectly :-)
Neil
>
>
> [0]
> https://elixir.bootlin.com/linux/v5.0-rc8/source/drivers/usb/roles/class.c#L246
>
Re: [PATCH v4 6/6] usb:cdns3 Fix for stuck packets in on-chip OUT buffer.
Hi, On 21/02/2019 09:14, Felipe Balbi wrote: > > Hi, > > (please break your emails at 80-columns) > > Pawel Laszczak writes: One more thing. Workaround has implemented algorithm that decide for which endpoint it should be enabled. e.g for composite device MSC+NCM+ACM it should work only for ACM OUT endpoint. >>> >>> If ACM driver didn't queue the request for ACM OUT endpoint, why does the >>> controller accept the data at all? >>> >>> I didn't understand why we need a workaround for this. It should be standard >>> behaviour to NAK data if function driver didn't request for all endpoints. >> >> Yes, I agree with you. Controller shouldn’t accept such packet. As I know >> this >> behavior will be fixed in RTL. >> >> But I assume that some older version of this controller are one the market, >> and driver should work correct with them. >> >> In the feature this workaround can be limited only to selected controllers. >> >> Even now I assume that it can be enabled/disabled by module parameter. > > no module parameters, please. Use revision detection in runtime. > This is about whether to enable or disable the workaround. By default we don't want this workaround to be enabled. I'm debating whether we should have this workaround at all or not. It has the following problems. 1) It ACKs packets even when gadget end is not ready to accept the transfers. 2) It stores these packets in a temporary buffer and then pushes them to the gadget driver whenever the gadget driver is ready to process the data. 3) Since the gadget driver can become ready at an indefinite time in the future, it poses 2 problems: a) It is sending stale data to the sink. (problematic at next protocol level?) b) If this temporary buffer runs out we still hit the lock up issue. I think the right solution is to make sure that the gadget driver is always reading all the enabled OUT endpoints *or* (keep the OUT endpoints disabled if gadget driver is not ready to process OUT transfers). cheers, -roger -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH v2 7/8] usb: dwc2: Add Amlogic G12A DWC2 Params
This patchs sets the params for the DWC2 Controller found in the
Amlogic G12A SoC family.
It mainly sets the settings reported incorrect by the driver,
leaving the remaining detected automatically by the driver and
provided by the DT node.
Signed-off-by: Neil Armstrong
---
drivers/usb/dwc2/params.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 24ff5f21cb25..442113246cba 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -121,6 +121,16 @@ static void dwc2_set_amlogic_params(struct dwc2_hsotg
*hsotg)
p->power_down = DWC2_POWER_DOWN_PARAM_NONE;
}
+static void dwc2_set_amlogic_g12a_params(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_core_params *p = &hsotg->params;
+
+ p->lpm = false;
+ p->lpm_clock_gating = false;
+ p->besl = false;
+ p->hird_threshold_en = false;
+}
+
static void dwc2_set_amcc_params(struct dwc2_hsotg *hsotg)
{
struct dwc2_core_params *p = &hsotg->params;
@@ -167,6 +177,8 @@ const struct of_device_id dwc2_of_match_table[] = {
.data = dwc2_set_amlogic_params },
{ .compatible = "amlogic,meson-gxbb-usb",
.data = dwc2_set_amlogic_params },
+ { .compatible = "amlogic,meson-g12a-usb",
+ .data = dwc2_set_amlogic_g12a_params },
{ .compatible = "amcc,dwc-otg", .data = dwc2_set_amcc_params },
{ .compatible = "st,stm32f4x9-fsotg",
.data = dwc2_set_stm32f4x9_fsotg_params },
--
2.20.1
[PATCH v2 6/8] phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY Driver
This adds support for the shared USB3 + PCIE PHY found in the
Amlogic G12A SoC Family.
It supports USB3 Host mode or PCIE 2.0 mode, depending on the layout of
the board.
Selection is done by the #phy-cells, making the mode static and exclusive.
Signed-off-by: Neil Armstrong
---
drivers/phy/amlogic/Kconfig | 11 +
drivers/phy/amlogic/Makefile | 1 +
.../phy/amlogic/phy-meson-g12a-usb3-pcie.c| 411 ++
3 files changed, 423 insertions(+)
create mode 100644 drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
diff --git a/drivers/phy/amlogic/Kconfig b/drivers/phy/amlogic/Kconfig
index 560ff0f1ed4c..4c08c1ccdd04 100644
--- a/drivers/phy/amlogic/Kconfig
+++ b/drivers/phy/amlogic/Kconfig
@@ -47,3 +47,14 @@ config PHY_MESON_G12A_USB2
Enable this to support the Meson USB2 PHYs found in Meson
G12A SoCs.
If unsure, say N.
+
+config PHY_MESON_G12A_USB3_PCIE
+ tristate "Meson G12A USB3+PCIE Combo PHY driver"
+ default ARCH_MESON
+ depends on OF && (ARCH_MESON || COMPILE_TEST)
+ select GENERIC_PHY
+ select REGMAP_MMIO
+ help
+ Enable this to support the Meson USB3 + PCIE Combo PHY found
+ in Meson G12A SoCs.
+ If unsure, say N.
diff --git a/drivers/phy/amlogic/Makefile b/drivers/phy/amlogic/Makefile
index 7d4d10f5a6b3..fdd008e1b19b 100644
--- a/drivers/phy/amlogic/Makefile
+++ b/drivers/phy/amlogic/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
obj-$(CONFIG_PHY_MESON_GXL_USB2) += phy-meson-gxl-usb2.o
obj-$(CONFIG_PHY_MESON_G12A_USB2) += phy-meson-g12a-usb2.o
obj-$(CONFIG_PHY_MESON_GXL_USB3) += phy-meson-gxl-usb3.o
+obj-$(CONFIG_PHY_MESON_G12A_USB3_PCIE) += phy-meson-g12a-usb3-pcie.o
diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
new file mode 100644
index ..c95518d51f17
--- /dev/null
+++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Amlogic G12A USB3 + PCIE Combo PHY driver
+ *
+ * Copyright (C) 2017 Amlogic, Inc. All rights reserved
+ * Copyright (C) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PHY_R0 0x00
+ #define PHY_R0_PCIE_POWER_STATE GENMASK(4, 0)
+ #define PHY_R0_PCIE_USB3_SWITCH GENMASK(6, 5)
+
+#define PHY_R1 0x04
+ #define PHY_R1_PHY_TX1_TERM_OFFSET GENMASK(4, 0)
+ #define PHY_R1_PHY_TX0_TERM_OFFSET GENMASK(9, 5)
+ #define PHY_R1_PHY_RX1_EQ GENMASK(12, 10)
+ #define PHY_R1_PHY_RX0_EQ GENMASK(15, 13)
+ #define PHY_R1_PHY_LOS_LEVELGENMASK(20, 16)
+ #define PHY_R1_PHY_LOS_BIAS GENMASK(23, 21)
+ #define PHY_R1_PHY_REF_CLKDIV2 BIT(24)
+ #define PHY_R1_PHY_MPLL_MULTIPLIER GENMASK(31, 25)
+
+#define PHY_R2 0x08
+ #define PHY_R2_PCS_TX_DEEMPH_GEN2_6DB GENMASK(5, 0)
+ #define PHY_R2_PCS_TX_DEEMPH_GEN2_3P5DB GENMASK(11, 6)
+ #define PHY_R2_PCS_TX_DEEMPH_GEN1 GENMASK(17, 12)
+ #define PHY_R2_PHY_TX_VBOOST_LVLGENMASK(20, 18)
+
+#define PHY_R4 0x10
+ #define PHY_R4_PHY_CR_WRITE BIT(0)
+ #define PHY_R4_PHY_CR_READ BIT(1)
+ #define PHY_R4_PHY_CR_DATA_IN GENMASK(17, 2)
+ #define PHY_R4_PHY_CR_CAP_DATA BIT(18)
+ #define PHY_R4_PHY_CR_CAP_ADDR BIT(19)
+
+#define PHY_R5 0x14
+ #define PHY_R5_PHY_CR_DATA_OUT GENMASK(15, 0)
+ #define PHY_R5_PHY_CR_ACK BIT(16)
+ #define PHY_R5_PHY_BS_OUT BIT(17)
+
+struct phy_g12a_usb3_pcie_priv {
+ struct regmap *regmap;
+ struct regmap *regmap_cr;
+ struct clk *clk_ref;
+ struct reset_control*reset;
+ struct phy *phy;
+ unsigned intmode;
+};
+
+static const struct regmap_config phy_g12a_usb3_pcie_regmap_conf = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = PHY_R5,
+};
+
+static int phy_g12a_usb3_pcie_cr_bus_addr(struct phy_g12a_usb3_pcie_priv *priv,
+
[PATCH v2 8/8] usb: dwc3: Add Amlogic G12A DWC3 glue
Adds support for Amlogic G12A USB Control Glue HW. The Amlogic G12A SoC Family embeds 2 USB Controllers : - a DWC3 IP configured as Host for USB2 and USB3 - a DWC2 IP configured as Peripheral USB2 Only A glue connects these both controllers to 2 USB2 PHYs, and optionnally to an USB3+PCIE Combo PHY shared with the PCIE controller. The Glue configures the UTMI 8bit interfaces for the USB2 PHYs, including routing of the OTG PHY between the DWC3 and DWC2 controllers, and setups the on-chip OTG mode selection for this PHY. This drivers supports the on-probe setup of the OTG mode, and manually via a debugfs interface. The IRQ mode change detect is yet to be added in a future patchset, mainly due to lack of hardware to validate on. Signed-off-by: Neil Armstrong --- drivers/usb/dwc3/Kconfig | 10 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-meson-g12a.c | 601 + 3 files changed, 612 insertions(+) create mode 100644 drivers/usb/dwc3/dwc3-meson-g12a.c diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 1a0404fda596..21ce7368d325 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -93,6 +93,16 @@ config USB_DWC3_KEYSTONE Support of USB2/3 functionality in TI Keystone2 platforms. Say 'Y' or 'M' here if you have one such device +config USB_DWC3_MESON_G12A + tristate "Amlogic Meson G12A Platforms" + depends on OF && COMMON_CLK + depends on ARCH_MESON || COMPILE_TEST + default USB_DWC3 + select USB_ROLE_SWITCH + help + Support USB2/3 functionality in Amlogic G12A platforms. +Say 'Y' or 'M' if you have one such device. + config USB_DWC3_OF_SIMPLE tristate "Generic OF Simple Glue Layer" depends on OF && COMMON_CLK diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile index 6e3ef6144e5d..ae86da0dc5bd 100644 --- a/drivers/usb/dwc3/Makefile +++ b/drivers/usb/dwc3/Makefile @@ -47,6 +47,7 @@ obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o obj-$(CONFIG_USB_DWC3_HAPS)+= dwc3-haps.o obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o +obj-$(CONFIG_USB_DWC3_MESON_G12A) += dwc3-meson-g12a.o obj-$(CONFIG_USB_DWC3_OF_SIMPLE) += dwc3-of-simple.o obj-$(CONFIG_USB_DWC3_ST) += dwc3-st.o obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o diff --git a/drivers/usb/dwc3/dwc3-meson-g12a.c b/drivers/usb/dwc3/dwc3-meson-g12a.c new file mode 100644 index ..75942614a034 --- /dev/null +++ b/drivers/usb/dwc3/dwc3-meson-g12a.c @@ -0,0 +1,601 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * USB Glue for Amlogic G12A SoCs + * + * Copyright (c) 2019 BayLibre, SAS + * Author: Neil Armstrong + */ + +/* + * The USB is organized with a glue around the DWC3 Controller IP as : + * - Control registers for each USB2 Ports + * - Control registers for the USB PHY layer + * - SuperSpeed PHY can be enabled only if port is used + * + * TOFIX: + * - Add dynamic OTG switching with ID change interrupt + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* USB2 Ports Control Registers */ + +#define U2P_REG_SIZE 0x20 + +#define U2P_R0 0x0 + #define U2P_R0_HOST_DEVICE BIT(0) + #define U2P_R0_POWER_OK BIT(1) + #define U2P_R0_HAST_MODEBIT(2) + #define U2P_R0_POWER_ON_RESET BIT(3) + #define U2P_R0_ID_PULLUPBIT(4) + #define U2P_R0_DRV_VBUS BIT(5) + +#define U2P_R1 0x4 + #define U2P_R1_PHY_READYBIT(0) + #define U2P_R1_ID_DIG BIT(1) + #define U2P_R1_OTG_SESSION_VALIDBIT(2) + #define U2P_R1_VBUS_VALID BIT(3) + +/* USB Glue Control Registers */ + +#define USB_R0 0x80 + #define USB_R0_P30_LANE0_TX2RX_LOOPBACK BIT(17) + #define USB_R0_P30_LANE0_EXT_PCLK_REQ BIT(18) + #define USB_R0_P30_PCS_RX_LOS_MASK_VAL_MASK GENMASK(28, 19) + #define USB_R0_U2D_SS_SCALEDOWN_MODE_MASK GENMASK(30, 29) + #define USB_R0_U2D_ACT BIT(31) + +#define USB_R1 0x84 + #define USB_R1_U3H_BIGENDIAN_GS BIT(0) + #define USB_R1_U3H_PME_ENABLE BIT(1) + #define USB_R1_U3H_HUB_PORT_O
[PATCH v2 5/8] phy: amlogic: add Amlogic G12A USB2 PHY Driver
This adds support for the USB2 PHY found in the Amlogic G12A SoC Family.
It supports Host and/or Peripheral mode, depending on it's position.
The first PHY is only used as Host, but the second supports Dual modes
defined by the USB Control Glue HW in front of the USB Controllers.
Signed-off-by: Neil Armstrong
---
drivers/phy/amlogic/Kconfig | 11 ++
drivers/phy/amlogic/Makefile | 1 +
drivers/phy/amlogic/phy-meson-g12a-usb2.c | 190 ++
3 files changed, 202 insertions(+)
create mode 100644 drivers/phy/amlogic/phy-meson-g12a-usb2.c
diff --git a/drivers/phy/amlogic/Kconfig b/drivers/phy/amlogic/Kconfig
index 23fe1cda2f70..560ff0f1ed4c 100644
--- a/drivers/phy/amlogic/Kconfig
+++ b/drivers/phy/amlogic/Kconfig
@@ -36,3 +36,14 @@ config PHY_MESON_GXL_USB3
Enable this to support the Meson USB3 PHY and OTG detection
IP block found in Meson GXL and GXM SoCs.
If unsure, say N.
+
+config PHY_MESON_G12A_USB2
+ tristate "Meson G12A USB2 PHY driver"
+ default ARCH_MESON
+ depends on OF && (ARCH_MESON || COMPILE_TEST)
+ select GENERIC_PHY
+ select REGMAP_MMIO
+ help
+ Enable this to support the Meson USB2 PHYs found in Meson
+ G12A SoCs.
+ If unsure, say N.
diff --git a/drivers/phy/amlogic/Makefile b/drivers/phy/amlogic/Makefile
index 4fd8848c194d..7d4d10f5a6b3 100644
--- a/drivers/phy/amlogic/Makefile
+++ b/drivers/phy/amlogic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
obj-$(CONFIG_PHY_MESON_GXL_USB2) += phy-meson-gxl-usb2.o
+obj-$(CONFIG_PHY_MESON_G12A_USB2) += phy-meson-g12a-usb2.o
obj-$(CONFIG_PHY_MESON_GXL_USB3) += phy-meson-gxl-usb3.o
diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb2.c
b/drivers/phy/amlogic/phy-meson-g12a-usb2.c
new file mode 100644
index ..4712a9464ac9
--- /dev/null
+++ b/drivers/phy/amlogic/phy-meson-g12a-usb2.c
@@ -0,0 +1,190 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Meson G12A USB2 PHY driver
+ *
+ * Copyright (C) 2017 Martin Blumenstingl
+ * Copyright (C) 2017 Amlogic, Inc. All rights reserved
+ * Copyright (C) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PHY_CTRL_R00x0
+#define PHY_CTRL_R10x4
+#define PHY_CTRL_R20x8
+#define PHY_CTRL_R30xc
+#define PHY_CTRL_R40x10
+#define PHY_CTRL_R50x14
+#define PHY_CTRL_R60x18
+#define PHY_CTRL_R70x1c
+#define PHY_CTRL_R80x20
+#define PHY_CTRL_R90x24
+#define PHY_CTRL_R10 0x28
+#define PHY_CTRL_R11 0x2c
+#define PHY_CTRL_R12 0x30
+#define PHY_CTRL_R13 0x34
+#define PHY_CTRL_R14 0x38
+#define PHY_CTRL_R15 0x3c
+#define PHY_CTRL_R16 0x40
+#define PHY_CTRL_R17 0x44
+#define PHY_CTRL_R18 0x48
+#define PHY_CTRL_R19 0x4c
+#define PHY_CTRL_R20 0x50
+#define PHY_CTRL_R21 0x54
+#define PHY_CTRL_R22 0x58
+#define PHY_CTRL_R23 0x5c
+
+#define RESET_COMPLETE_TIME1000
+#define PLL_RESET_COMPLETE_TIME100
+
+struct phy_meson_g12a_usb2_priv {
+ struct device *dev;
+ struct regmap *regmap;
+ struct clk *clk;
+ struct reset_control*reset;
+};
+
+static const struct regmap_config phy_meson_g12a_usb2_regmap_conf = {
+ .reg_bits = 8,
+ .val_bits = 32,
+ .reg_stride = 4,
+ .max_register = PHY_CTRL_R23,
+};
+
+static int phy_meson_g12a_usb2_init(struct phy *phy)
+{
+ struct phy_meson_g12a_usb2_priv *priv = phy_get_drvdata(phy);
+ int ret;
+
+ ret = reset_control_reset(priv->reset);
+ if (ret)
+ return ret;
+
+ udelay(RESET_COMPLETE_TIME);
+
+ /* usb2_otg_aca_en == 0 */
+ regmap_update_bits(priv->regmap, PHY_CTRL_R21, BIT(2), 0);
+
+ /* PLL Setup : 24MHz * 20 / 1 = 480MHz */
+ regmap_write(pr
[PATCH v2 4/8] dt-bindings: usb: dwc3: Add Amlogic G12A DWC3 Glue Bindings
Adds the bindings for the Amlogic G12A USB Glue HW.
The Amlogic G12A SoC Family embeds 2 USB Controllers :
- a DWC3 IP configured as Host for USB2 and USB3
- a DWC2 IP configured as Peripheral USB2 Only
A glue connects these both controllers to 2 USB2 PHYs,
and optionnally to an USB3+PCIE Combo PHY shared with the PCIE controller.
The Glue configures the UTMI 8bit interfaces for the USB2 PHYs, including
routing of the OTG PHY between the DWC3 and DWC2 controllers, and
setups the on-chip OTG mode selection for this PHY.
The PHYs phandles are passed to the Glue node since the Glue controls the
interface with the PHY, not the DWC3 controller.
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/usb/amlogic,dwc3.txt | 88 +++
1 file changed, 88 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt
b/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt
index 9a8b631904fd..b9f04e617eb7 100644
--- a/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/amlogic,dwc3.txt
@@ -40,3 +40,91 @@ Example device nodes:
phy-names = "usb2-phy", "usb3-phy";
};
};
+
+Amlogic Meson G12A DWC3 USB SoC Controller Glue
+
+The Amlogic G12A embeds a DWC3 USB IP Core configured for USB2 and USB3
+in host-only mode, and a DWC2 IP Core configured for USB2 peripheral mode
+only.
+
+A glue connects the DWC3 core to USB2 PHYs and optionnaly to an USB3 PHY.
+
+One of the USB2 PHY can be re-routed in peripheral mode to a DWC2 USB IP.
+
+The DWC3 Glue controls the PHY routing and power, an interrupt line is
+connected to the Glue to serve as OTG ID change detection.
+
+Required properties:
+- compatible: Should be "amlogic,meson-g12a-usb-ctrl"
+- clocks: a handle for the "USB" clock
+- resets: a handle for the shared "USB" reset line
+- reg: The base address and length of the registers
+- interrupts: the interrupt specifier for the OTG detection
+- phys:handle to used PHYs on the system
+ - a <0> phandle can be used if a PHY is not used
+- phy-names: names of the used PHYs on the system :
+ - "usb2-phy0" for USB2 PHY0 if USBHOST_A port is used
+ - "usb2-phy1" for USB2 PHY1 if USBOTG_B port is used
+ - "usb3-phy0" for USB3 PHY if USB3_0 is used
+- dr_mode: should be "host", "peripheral", or "otg" depending on
+ the usage and configuration of the OTG Capable port.
+ - "host" and "peripheral" means a fixed Host or Device only connection
+ - "otg" means the port can be used as both Host or Device and
+ be switched automatically using the OTG ID pin.
+
+Optional properties:
+- vbus-supply: should be a phandle to the regulator controlling the VBUS
+ power supply when used in OTG switchable mode
+
+Required child nodes:
+
+A child node must exist to represent the core DWC3 IP block. The name of
+the node is not important. The content of the node is defined in dwc3.txt.
+
+A child node must exist to represent the core DWC2 IP block. The name of
+the node is not important. The content of the node is defined in dwc2.txt.
+
+PHY documentation is provided in the following places:
+- Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
+- Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
+
+Example device nodes:
+ usb: usb@ffe09000 {
+ compatible = "amlogic,meson-g12a-usb-ctrl";
+ reg = <0x0 0xffe09000 0x0 0xa0>;
+ interrupts = ;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ clocks = <&clkc CLKID_USB>;
+ resets = <&reset RESET_USB>;
+
+ dr_mode = "otg";
+
+ phys = <&usb2_phy0>, <&usb2_phy1>,
+ <&usb3_pcie_phy PHY_TYPE_USB3>;
+ phy-names = "usb2-phy0", "usb2-phy1", "usb3-phy0";
+
+ dwc2: usb@ff40 {
+ compatible = "amlogic,meson-g12a-usb",
"snps,dwc2";
+ reg = <0x0 0xff40 0x0 0x4>;
+ interrupts = ;
+ clocks = <&clkc CLKID_USB1_DDR_BRIDGE>;
+ clock-names = "ddr";
+ phys = <&usb2_phy1>;
+ dr_mode = "peripheral";
+ g-rx-fifo-size = <192>;
+ g-np-tx-fifo-size = <128>;
+ g-tx-fifo-size = <128 128 16 16 16>;
+ };
+
+ dwc3: usb@ff50 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0xff50 0x0 0x10>;
+ interrupts = ;
+
[PATCH v2 3/8] dt-bindings: usb: dwc2: Add Amlogic G12A DWC2 Compatible
Adds the specific compatible string for the DWC2 IP found in the Amlogic G12A SoC Family. Signed-off-by: Neil Armstrong Reviewed-by: Martin Blumenstingl Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/usb/dwc2.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt index 6dc3c4a34483..e150b7b227c9 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -14,6 +14,7 @@ Required properties: - "amlogic,meson8-usb": The DWC2 USB controller instance in Amlogic Meson8 SoCs; - "amlogic,meson8b-usb": The DWC2 USB controller instance in Amlogic Meson8b SoCs; - "amlogic,meson-gxbb-usb": The DWC2 USB controller instance in Amlogic S905 SoCs; + - "amlogic,meson-g12a-usb": The DWC2 USB controller instance in Amlogic G12A SoCs; - "amcc,dwc-otg": The DWC2 USB controller instance in AMCC Canyonlands 460EX SoCs; - snps,dwc2: A generic DWC2 USB controller with default parameters. - "st,stm32f4x9-fsotg": The DWC2 USB FS/HS controller instance in STM32F4x9 SoCs -- 2.20.1
[PATCH v2 2/8] dt-bindings: phy: Add Amlogic G12A USB3+PCIE Combo PHY Bindings
Add the Amlogic G12A Family USB3 + PCIE Combo PHY Bindings.
This PHY can provide exclusively USB3 or PCIE support on shared I/Os.
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
---
.../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 +++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
new file mode 100644
index ..7cfc17e2df31
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt
@@ -0,0 +1,22 @@
+* Amlogic G12A USB3 + PCIE Combo PHY binding
+
+Required properties:
+- compatible: Should be "amlogic,meson-g12a-usb3-pcie-phy"
+- #phys-cells: must be 1. The cell number is used to select the phy mode
+ as defined in between PHY_TYPE_USB3 and PHY_TYPE_PCIE
+- reg: The base address and length of the registers
+- clocks: a phandle to the 100MHz reference clock of this PHY
+- clock-names: must be "ref_clk"
+- resets: phandle to the reset lines for the PHY control
+- reset-names: must be "phy"
+
+Example:
+ usb3_pcie_phy: phy@46000 {
+ compatible = "amlogic,g12a-usb3-pcie-phy";
+ reg = <0x0 0x46000 0x0 0x2000>;
+ clocks = <&clkc CLKID_PCIE_PLL>;
+ clock-names = "ref_clk";
+ resets = <&reset RESET_PCIE_PHY>;
+ reset-names = "phy";
+ #phy-cells = <1>;
+ };
--
2.20.1
[PATCH v2 1/8] dt-bindings: phy: Add Amlogic G12A USB2 PHY Bindings
Add the Amlogic G12A Family USB2 OTG PHY Bindings
The PHY can work in host or peripheral modes depending on it's position.
Configuration of the mode is part of the USBCTRL registers which are
outside of the PHY registers.
Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
Reviewed-by: Rob Herring
---
.../bindings/phy/meson-g12a-usb2-phy.txt | 22 +++
1 file changed, 22 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
b/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
new file mode 100644
index ..a6ebc3dea159
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt
@@ -0,0 +1,22 @@
+* Amlogic G12A USB2 PHY binding
+
+Required properties:
+- compatible: Should be "amlogic,meson-g12a-usb2-phy"
+- reg: The base address and length of the registers
+- #phys-cells: must be 0 (see phy-bindings.txt in this directory)
+- clocks: a phandle to the clock of this PHY
+- clock-names: must be "xtal"
+- resets: a phandle to the reset line of this PHY
+- reset-names: must be "phy"
+- phy-supply: see phy-bindings.txt in this directory
+
+Example:
+ usb2_phy0: phy@36000 {
+ compatible = "amlogic,g12a-usb2-phy";
+ reg = <0x0 0x36000 0x0 0x2000>;
+ clocks = <&xtal>;
+ clock-names = "xtal";
+ resets = <&reset RESET_USB_PHY21>;
+ reset-names = "phy";
+ #phy-cells = <0>;
+ };
--
2.20.1
[PATCH v2 0/8] arm64: meson: Add support for USB on Amlogic G12A
This patchset adds support for USB on Amlogic G12A SoCs. This patchset is composed with : - bindings of the PHYs - bindings of the USB Control Glue - PHY Drivers - USB Control Glue driver Device Tree nodes will be added in a separate patchset. The Amlogic G12A USB Complex is composed of : - 2 USB Controllers : * DWC3 for USB2 and USB3 Host functionality * DWC2 for USB2 Peripheral functionality - 2 USB2 OTG PHYs, only a single one will be routed to either DWC2 to DWC3 - 1 USB3 PHY shared with PCIE funcionnality - A Glue to control PHY routing, setup and OTG detection The Glue configures the UTMI 8bit interfaces for the USB2 PHYs, including routing of the OTG PHY between the DWC3 and DWC2 controllers, and setups the on-chip OTG mode selection for this PHY. This drivers supports the on-probe setup of the OTG mode, and manually via the USB Role interface. The IRQ mode change detect is yet to be added in a future patchset, mainly due to lack of hardware to validate on. Changes since v1 at [0]: - USB2 PHY Bindings: collected tags and updated commit log - USB3/PCIE PHY Bindings: collected tag and updated reset list - DWC2 Compatible: collected tags - DWC3 Glue Bindings: - removed clock-names and reset-names for single entries - removed ports graph for PHYs and replaced by phys list with phy-names - added dr_mode and optional vbus-supply - fixed example - USB2 PHY Driver: removed USB_SUPPORT and otg.h include - USB3/PCIE PHY Driver: removed USB_SUPPORT, fixed comment and unused reg variable - USB Glue Driver: - Moved debugfs I/F to USB_ROLE_SWITCH framework - Integrated USB Glue Control Registers offset - Removed of graph parsing to use devm_phy_optional_get() - Fixed PHY mode handling and OTG switching - Simplified PHY calls by removing the NULL test - Added optional vbus regulator handling [1] https://lkml.kernel.org/r/20190212151413.24632-1-narmstr...@baylibre.com Neil Armstrong (8): dt-bindings: phy: Add Amlogic G12A USB2 PHY Bindings dt-bindings: phy: Add Amlogic G12A USB3+PCIE Combo PHY Bindings dt-bindings: usb: dwc2: Add Amlogic G12A DWC2 Compatible dt-bindings: usb: dwc3: Add Amlogic G12A DWC3 Glue Bindings phy: amlogic: add Amlogic G12A USB2 PHY Driver phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY Driver usb: dwc2: Add Amlogic G12A DWC2 Params usb: dwc3: Add Amlogic G12A DWC3 glue .../bindings/phy/meson-g12a-usb2-phy.txt | 22 + .../bindings/phy/meson-g12a-usb3-pcie-phy.txt | 22 + .../devicetree/bindings/usb/amlogic,dwc3.txt | 88 +++ .../devicetree/bindings/usb/dwc2.txt | 1 + drivers/phy/amlogic/Kconfig | 22 + drivers/phy/amlogic/Makefile | 2 + drivers/phy/amlogic/phy-meson-g12a-usb2.c | 190 ++ .../phy/amlogic/phy-meson-g12a-usb3-pcie.c| 411 drivers/usb/dwc2/params.c | 12 + drivers/usb/dwc3/Kconfig | 10 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-meson-g12a.c| 601 ++ 12 files changed, 1382 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb2-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/meson-g12a-usb3-pcie-phy.txt create mode 100644 drivers/phy/amlogic/phy-meson-g12a-usb2.c create mode 100644 drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c create mode 100644 drivers/usb/dwc3/dwc3-meson-g12a.c -- 2.20.1
RE: [PATCH v4 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
Hi, > >hi, >On Thu, 2019-02-14 at 19:45 +, Pawel Laszczak wrote: >> This patch introduce new Cadence USBSS DRD driver to linux kernel. >> >> The Cadence USBSS DRD Driver is a highly configurable IP Core whichi >> can be instantiated as Dual-Role Device (DRD), Peripheral Only and >> Host Only (XHCI)configurations. >> >> The current driver has been validated with FPGA burned. We have support >> for PCIe bus, which is used on FPGA prototyping. >> >> The host side of USBSS-DRD controller is compliance with XHCI >> specification, so it works with standard XHCI linux driver. >> >> Signed-off-by: Pawel Laszczak >> --- >> drivers/usb/Kconfig|2 + >> drivers/usb/Makefile |2 + >> drivers/usb/cdns3/Kconfig | 44 + >> drivers/usb/cdns3/Makefile | 14 + >> drivers/usb/cdns3/cdns3-pci-wrap.c | 155 +++ >> drivers/usb/cdns3/core.c | 403 ++ >> drivers/usb/cdns3/core.h | 116 ++ >> drivers/usb/cdns3/debug.h | 168 +++ >> drivers/usb/cdns3/debugfs.c| 164 +++ >> drivers/usb/cdns3/drd.c| 365 + >> drivers/usb/cdns3/drd.h| 162 +++ >> drivers/usb/cdns3/ep0.c| 907 + >> drivers/usb/cdns3/gadget-export.h | 28 + >> drivers/usb/cdns3/gadget.c | 2003 >> drivers/usb/cdns3/gadget.h | 1207 + >> drivers/usb/cdns3/host-export.h| 28 + >> drivers/usb/cdns3/host.c | 72 + >> drivers/usb/cdns3/trace.c | 23 + >> drivers/usb/cdns3/trace.h | 404 ++ >> 19 files changed, 6267 insertions(+) >> create mode 100644 drivers/usb/cdns3/Kconfig >> create mode 100644 drivers/usb/cdns3/Makefile >> create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c >> create mode 100644 drivers/usb/cdns3/core.c >> create mode 100644 drivers/usb/cdns3/core.h >> create mode 100644 drivers/usb/cdns3/debug.h >> create mode 100644 drivers/usb/cdns3/debugfs.c >> create mode 100644 drivers/usb/cdns3/drd.c >> create mode 100644 drivers/usb/cdns3/drd.h >> create mode 100644 drivers/usb/cdns3/ep0.c >> create mode 100644 drivers/usb/cdns3/gadget-export.h >> create mode 100644 drivers/usb/cdns3/gadget.c >> create mode 100644 drivers/usb/cdns3/gadget.h >> create mode 100644 drivers/usb/cdns3/host-export.h >> create mode 100644 drivers/usb/cdns3/host.c >> create mode 100644 drivers/usb/cdns3/trace.c >> create mode 100644 drivers/usb/cdns3/trace.h >> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig >> index 987fc5ba6321..5f9334019d04 100644 >> --- a/drivers/usb/Kconfig >> +++ b/drivers/usb/Kconfig >> @@ -112,6 +112,8 @@ source "drivers/usb/usbip/Kconfig" >> >> endif >> >> +source "drivers/usb/cdns3/Kconfig" >> + >> source "drivers/usb/mtu3/Kconfig" >> >> source "drivers/usb/musb/Kconfig" >> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile >> index 7d1b8c82b208..ab125b966cac 100644 >> --- a/drivers/usb/Makefile >> +++ b/drivers/usb/Makefile >> @@ -12,6 +12,8 @@ obj-$(CONFIG_USB_DWC3) += dwc3/ >> obj-$(CONFIG_USB_DWC2) += dwc2/ >> obj-$(CONFIG_USB_ISP1760) += isp1760/ >> >> +obj-$(CONFIG_USB_CDNS3) += cdns3/ >> + >> obj-$(CONFIG_USB_MON) += mon/ >> obj-$(CONFIG_USB_MTU3) += mtu3/ >> >> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig >> new file mode 100644 >> index ..27cb3d8dbe3d >> --- /dev/null >> +++ b/drivers/usb/cdns3/Kconfig >> @@ -0,0 +1,44 @@ >> +config USB_CDNS3 >> +tristate "Cadence USB3 Dual-Role Controller" >> +depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA >> +help >> + Say Y here if your system has a cadence USB3 dual-role controller. >> + It supports: dual-role switch, Host-only, and Peripheral-only. >> + >> + If you choose to build this driver is a dynamically linked >> + as module, the module will be called cdns3.ko. >> + >> +if USB_CDNS3 >> + >> +config USB_CDNS3_GADGET >> +bool "Cadence USB3 device controller" >> +depends on USB_GADGET >> +help >> + Say Y here to enable device controller functionality of the >> + cadence USBSS-DEV driver. >> + >> + This controller supports FF, HS and SS mode. It doesn't support >> + LS and SSP mode. >> + >> +config USB_CDNS3_HOST >> +bool "Cadence USB3 host controller" >> +depends on USB_XHCI_HCD >> +help >> + Say Y here to enable host controller functionality of the >> + cadence driver. >> + >> + Host controller is compliant with XHCI so it will use >> + standard XHCI driver. >> + >> +config USB_CDNS3_PCI_WRAP >> +tristate "Cadence USB3 support on PCIe-based platforms" >> +depends on USB_PCI && ACPI >> +default USB_CDNS3 >> +help >> + If you're using the USBSS Core IP with a PCIe, please say >> + 'Y' or 'M' here. >> + >> + If you c
Re: [PATCH v3 00/12] Add support for usb on Hikey960
Hi, On 02/03/2019 09:04, Yu Chen wrote: > The patchset adds support for usb functionality of Hikey960, includes: > - dwc3 driver for Hisilicon Kirin Soc hi3660 > - usb driver for HiKey960 board > - some adjustment in dwc3, usb gadget and typec driver > - dts for support usb of HiKey960 > > This patchset based on patchset https://lkml.org/lkml/2019/1/25/344 > of Heikki Krogerus > Works fine on my board, thanks for keeping this up. Tested-by: Valentin Schneider > Yu Chen (12): > dt-bindings: phy: Add support for HiSilicon's hi3660 USB PHY > dt-bindings: misc: Add bindings for HiSilicon usb hub and data role > switch functionality on HiKey960 > usb: dwc3: dwc3-of-simple: Add support for dwc3 of Hisilicon Soc > Platform > usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc > usb: dwc3: Execute GCTL Core Soft Reset while switch mdoe for > Hisilicon Kirin Soc > usb: dwc3: Increase timeout for CmdAct cleared by device controller > phy: Add usb phy support for hi3660 Soc of Hisilicon > usb: roles: Add usb role switch notifier. > usb: dwc3: Registering a role switch in the DRD code. > hikey960: Support usb functionality of Hikey960 > usb: gadget: Add configfs attribuite for controling > match_existing_only > dts: hi3660: Add support for usb on Hikey960 > > .../bindings/misc/hisilicon-hikey-usb.txt | 52 + > .../devicetree/bindings/phy/phy-hi3660-usb3.txt| 28 +++ > MAINTAINERS| 8 + > arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dts | 53 + > arch/arm64/boot/dts/hisilicon/hi3660.dtsi | 74 +++ > drivers/misc/Kconfig | 6 + > drivers/misc/Makefile | 1 + > drivers/misc/hisi_hikey_usb.c | 167 +++ > drivers/phy/hisilicon/Kconfig | 10 + > drivers/phy/hisilicon/Makefile | 1 + > drivers/phy/hisilicon/phy-hi3660-usb3.c| 232 > + > drivers/usb/dwc3/Kconfig | 1 + > drivers/usb/dwc3/core.c| 43 > drivers/usb/dwc3/core.h| 10 + > drivers/usb/dwc3/drd.c | 58 +- > drivers/usb/dwc3/dwc3-of-simple.c | 4 +- > drivers/usb/dwc3/gadget.c | 2 +- > drivers/usb/gadget/configfs.c | 32 +++ > drivers/usb/roles/class.c | 20 +- > include/linux/usb/role.h | 46 > 20 files changed, 844 insertions(+), 4 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/misc/hisilicon-hikey-usb.txt > create mode 100644 Documentation/devicetree/bindings/phy/phy-hi3660-usb3.txt > create mode 100644 drivers/misc/hisi_hikey_usb.c > create mode 100644 drivers/phy/hisilicon/phy-hi3660-usb3.c >
Re: [xhci-hcd][linux 4.20.13] autosuspend on causes a single cpu core to stay in kernel mode using 100% of said cpu core.
On 3.3.2019 16.30, Greg KH wrote: On Sun, Mar 03, 2019 at 03:15:27PM +0100, Farelka kek wrote: usbcore.autosuspend higher than -1, causes 1 cpu core to never step down from kernel mode. Some hardware does not aupport autosuspend, so leaving it at -1 is good. It happens on a core i5-7200U laptop, an acer f5-573g-50ec Disabling usb autosuspend causes the cpu not to idle at, minimum of 25% cpu usage. Is this a regression from earlier kernel versions? If so, any chance you can run 'git bisect' to find the offending commit? It could be the following patch: 2f31a67 usb: xhci: Prevent bus suspend if a port connect change or polling state is detected It caused similar issues on MacBookPro because of broken usb card reader stuck in polling state. Farelka kek, If that's the case for you, could you try a fix I wrote? I added the fix on top of 4.20.13 in a suspend_fix branch: git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git suspend_fix https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=suspend_fix -Mathias
Linux Kernel problem - euphony logs
Euphony logs logs.tar.gz Description: application/gzip
RE: [PATCH v4 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
>From: Pawel Laszczak >Sent: Monday, March 4, 2019 12:02 PM >To: Chunfeng Yun >Cc: devicet...@vger.kernel.org; gre...@linuxfoundation.org; >felipe.ba...@linux.intel.com; mark.rutl...@arm.com; linux- >u...@vger.kernel.org; hdego...@redhat.com; heikki.kroge...@linux.intel.com; >andy.shevche...@gmail.com; robh...@kernel.org; >rog...@ti.com; linux-ker...@vger.kernel.org; jbergsa...@ti.com; >nsek...@ti.com; n...@ti.com; Suresh Punnoose >; peter.c...@nxp.com; Rahul Kumar >Subject: RE: [PATCH v4 5/6] usb:cdns3 Add Cadence USB3 DRD Driver > >Hi, >> >>hi, >>On Thu, 2019-02-14 at 19:45 +, Pawel Laszczak wrote: >>> This patch introduce new Cadence USBSS DRD driver to linux kernel. >>> >>> The Cadence USBSS DRD Driver is a highly configurable IP Core whichi >>> can be instantiated as Dual-Role Device (DRD), Peripheral Only and >>> Host Only (XHCI)configurations. >>> >>> The current driver has been validated with FPGA burned. We have support >>> for PCIe bus, which is used on FPGA prototyping. >>> >>> The host side of USBSS-DRD controller is compliance with XHCI >>> specification, so it works with standard XHCI linux driver. >>> >>> Signed-off-by: Pawel Laszczak >>> --- >>> drivers/usb/Kconfig|2 + >>> drivers/usb/Makefile |2 + >>> drivers/usb/cdns3/Kconfig | 44 + >>> drivers/usb/cdns3/Makefile | 14 + >>> drivers/usb/cdns3/cdns3-pci-wrap.c | 155 +++ >>> drivers/usb/cdns3/core.c | 403 ++ >>> drivers/usb/cdns3/core.h | 116 ++ >>> drivers/usb/cdns3/debug.h | 168 +++ >>> drivers/usb/cdns3/debugfs.c| 164 +++ >>> drivers/usb/cdns3/drd.c| 365 + >>> drivers/usb/cdns3/drd.h| 162 +++ >>> drivers/usb/cdns3/ep0.c| 907 + >>> drivers/usb/cdns3/gadget-export.h | 28 + >>> drivers/usb/cdns3/gadget.c | 2003 >>> drivers/usb/cdns3/gadget.h | 1207 + >>> drivers/usb/cdns3/host-export.h| 28 + >>> drivers/usb/cdns3/host.c | 72 + >>> drivers/usb/cdns3/trace.c | 23 + >>> drivers/usb/cdns3/trace.h | 404 ++ >>> 19 files changed, 6267 insertions(+) >>> create mode 100644 drivers/usb/cdns3/Kconfig >>> create mode 100644 drivers/usb/cdns3/Makefile >>> create mode 100644 drivers/usb/cdns3/cdns3-pci-wrap.c >>> create mode 100644 drivers/usb/cdns3/core.c >>> create mode 100644 drivers/usb/cdns3/core.h >>> create mode 100644 drivers/usb/cdns3/debug.h >>> create mode 100644 drivers/usb/cdns3/debugfs.c >>> create mode 100644 drivers/usb/cdns3/drd.c >>> create mode 100644 drivers/usb/cdns3/drd.h >>> create mode 100644 drivers/usb/cdns3/ep0.c >>> create mode 100644 drivers/usb/cdns3/gadget-export.h >>> create mode 100644 drivers/usb/cdns3/gadget.c >>> create mode 100644 drivers/usb/cdns3/gadget.h >>> create mode 100644 drivers/usb/cdns3/host-export.h >>> create mode 100644 drivers/usb/cdns3/host.c >>> create mode 100644 drivers/usb/cdns3/trace.c >>> create mode 100644 drivers/usb/cdns3/trace.h >>> >>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig >>> index 987fc5ba6321..5f9334019d04 100644 >>> --- a/drivers/usb/Kconfig >>> +++ b/drivers/usb/Kconfig >>> @@ -112,6 +112,8 @@ source "drivers/usb/usbip/Kconfig" >>> >>> endif >>> >>> +source "drivers/usb/cdns3/Kconfig" >>> + >>> source "drivers/usb/mtu3/Kconfig" >>> >>> source "drivers/usb/musb/Kconfig" >>> diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile >>> index 7d1b8c82b208..ab125b966cac 100644 >>> --- a/drivers/usb/Makefile >>> +++ b/drivers/usb/Makefile >>> @@ -12,6 +12,8 @@ obj-$(CONFIG_USB_DWC3)+= dwc3/ >>> obj-$(CONFIG_USB_DWC2) += dwc2/ >>> obj-$(CONFIG_USB_ISP1760) += isp1760/ >>> >>> +obj-$(CONFIG_USB_CDNS3)+= cdns3/ >>> + >>> obj-$(CONFIG_USB_MON) += mon/ >>> obj-$(CONFIG_USB_MTU3) += mtu3/ >>> >>> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig >>> new file mode 100644 >>> index ..27cb3d8dbe3d >>> --- /dev/null >>> +++ b/drivers/usb/cdns3/Kconfig >>> @@ -0,0 +1,44 @@ >>> +config USB_CDNS3 >>> + tristate "Cadence USB3 Dual-Role Controller" >>> + depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA >>> + help >>> + Say Y here if your system has a cadence USB3 dual-role controller. >>> + It supports: dual-role switch, Host-only, and Peripheral-only. >>> + >>> + If you choose to build this driver is a dynamically linked >>> + as module, the module will be called cdns3.ko. >>> + >>> +if USB_CDNS3 >>> + >>> +config USB_CDNS3_GADGET >>> +bool "Cadence USB3 device controller" >>> +depends on USB_GADGET >>> +help >>> + Say Y here to enable device controller functionality of the >>> + cadence USBSS-DEV driver. >>> + >>> + This controller supports FF, HS and SS mode. It doesn't support >>> + LS and SSP m
[PATCH] usb: dwc2: Set lpm mode parameters depend on HW configuration
If core not supported lpm, i.e. BCM2835 then confusing warnings seen
in log.
To avoid these warnings, added function dwc2_set_param_lpm() to set
lpm and other lpm related parameters based on lpm support by core.
Signed-off-by: Minas Harutyunyan
---
drivers/usb/dwc2/params.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
index 24ff5f21cb25..ffbdb8e11673 100644
--- a/drivers/usb/dwc2/params.c
+++ b/drivers/usb/dwc2/params.c
@@ -273,6 +273,23 @@ static void dwc2_set_param_power_down(struct dwc2_hsotg
*hsotg)
hsotg->params.power_down = val;
}
+static void dwc2_set_param_lpm(struct dwc2_hsotg *hsotg)
+{
+ struct dwc2_core_params *p = &hsotg->params;
+
+ p->lpm = hsotg->hw_params.lpm_mode;
+ if (p->lpm) {
+ p->lpm_clock_gating = true;
+ p->besl = true;
+ p->hird_threshold_en = true;
+ p->hird_threshold = 4;
+ } else {
+ p->lpm_clock_gating = false;
+ p->besl = false;
+ p->hird_threshold_en = false;
+ }
+}
+
/**
* dwc2_set_default_params() - Set all core parameters to their
* auto-detected default values.
@@ -291,6 +308,7 @@ static void dwc2_set_default_params(struct dwc2_hsotg
*hsotg)
dwc2_set_param_speed(hsotg);
dwc2_set_param_phy_utmi_width(hsotg);
dwc2_set_param_power_down(hsotg);
+ dwc2_set_param_lpm(hsotg);
p->phy_ulpi_ddr = false;
p->phy_ulpi_ext_vbus = false;
@@ -303,11 +321,6 @@ static void dwc2_set_default_params(struct dwc2_hsotg
*hsotg)
p->reload_ctl = (hw->snpsid >= DWC2_CORE_REV_2_92a);
p->uframe_sched = true;
p->external_id_pin_ctl = false;
- p->lpm = true;
- p->lpm_clock_gating = true;
- p->besl = true;
- p->hird_threshold_en = true;
- p->hird_threshold = 4;
p->ipg_isoc_en = false;
p->service_interval = false;
p->max_packet_count = hw->max_packet_count;
--
2.11.0
Re: Linux Kernel - problem
On 4.3.2019 14.17, Cezary Lenkiewicz wrote: Hello, I have problem with Euphony system - this is linux for audio. I talking with Euphony support but they say that the problem is in the linux kernel. Please show my conversation with euphony: https://euphony-audio.com/hesk/ticket.php?track=T4N-M6G-XHAE&e=missionfanboy%40gmail.com&Refresh=49662 Can you fix this PLEASE ? Feb 28 17:11:34 euphony kernel: xhci_hcd :04:00.0: ERROR: unexpected command completion code 0x11. Feb 28 17:11:34 euphony kernel: usb 5-1.1: Not enough bandwidth for altsetting 1 Completion code 0x11 (17) is parameter error, this means some value in a context parameter is invalid. Many of these context parameter are taken from the descriptors of the attached usb device (device, interface, endpoint descriptors) More details are needed, output of "lsusb -v", and dynamic debug of xhci and usbcore would be a good start -Mathias
Re: [regression] USB power management failure to suspend / high CPU usage
On 26.2.2019 0.11, Ivan Mironov wrote:
On Wed, 2019-02-20 at 19:28 +0200, Mathias Nyman wrote:
On 14.2.2019 20.04, Eric Blau wrote:
On Thu, Feb 14, 2019 at 9:56 AM Mathias Nyman
wrote:
Thanks for looking into this, Mathias. Now that you point this out, on
older kernels where suspend and resume works, I noticed the following
log messages emitted when resuming from suspend:
Feb 06 18:58:05 eric-macbookpro kernel: usb usb2-port3: Cannot enable.
Maybe the USB cable is bad?
Attached a testpatch that should react to ports stuck in polling state,
and warm reset them.
It doesn't limit the numbers of reset tries, or allow system suspend with ports
stuck in polling state, but I'd like to know how the MacBook reacts to it
Can you test it with debugging enabled?
Hi Mathias,
Thanks for the patch. I tested it against 4.20.8 and got a couple
successful suspends but on the third attempt I got the same failure
again. I noticed after the first suspend/resume, the card reader
showed as "Link:Compliance" but on later attempts it showed stuck in
Polling again.
I've attached the logs with debugging enabled.
Thanks, logs show that several resets won't recover the card reader.
I'm taking a different approach, USB3 ports in polling state should
automatically move to connected/enabled. So instead of preventing
suspend if a port is found in polling I'll let it try to finish link
training for some time, and then just continue with suspend if it fails.
Patch attached.
This won't fix the broken card reader, but should allow your MacBook to suspend.
After this we can start looking at fixing the card reader, Ivan Miranov sent
some
proposal for this.
-Mathias
Hi Mathias,
I applied your patch on top of v5.0-rc8 and tested it on my laptop.
It fixes the suspend problem from the kernel side, but there is another
one: starting with the second suspend, XHCI controller wakes up the
system just after few seconds after suspending. Laptop keeps looping
through suspend/resume while lid is closed.
Such behaviour is quite stable: I was able to reproduce this three
times with reboots in between. Corresponding dmesg and traces are here
(from one run only):
https://github.com/im-0/investigate-card-reader-suspend-problem-on-mbp11.4/tree/master/test-22
After disabling ACPI wake up on XHC1 (echo XHC1 >/proc/acpi/wakeup),
everything works as expected: suspend/resume works fine multiple times,
card reader remains missing after the first suspend/resume.
Thanks, logs show it's no longer in a similar loop attempting so suspend
the bus, but device instead goes between polling, rxDetect and compliance,
modes, sometimes with cold attach status flag seen.
Most of the time is now spent resetting the device.
I have yet another patch, this one will just log the portstatus.
I'd like to know if we are doing something odd when resuming the port
that causes it to get stuck.
Patch attached, can you try it out?
Also available from my port-debug branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git port-debug
-Mathias
>From c32bd41c2d44f14cbfaf26de1c40387e770ccc53 Mon Sep 17 00:00:00 2001
From: Mathias Nyman
Date: Fri, 1 Mar 2019 08:38:50 +0200
Subject: [PATCH] xhci: add more port debugging
Signed-off-by: Mathias Nyman
---
drivers/usb/host/xhci-hub.c | 53 +++-
drivers/usb/host/xhci-ring.c | 12 ++
drivers/usb/host/xhci.c | 15 +
3 files changed, 56 insertions(+), 24 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index e2eece6..6ba1a78 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -487,8 +487,8 @@ static void xhci_disable_port(struct usb_hcd *hcd, struct xhci_hcd *xhci,
/* Write 1 to disable the port */
writel(port_status | PORT_PE, addr);
port_status = readl(addr);
- xhci_dbg(xhci, "disable port, actual port %d status = 0x%x\n",
- wIndex, port_status);
+ xhci_dbg(xhci, "disable port %d-%d, portsc: 0x%x\n",
+ hcd->self.busnum, wIndex + 1, port_status);
}
static void xhci_clear_port_change_bit(struct xhci_hcd *xhci, u16 wValue,
@@ -537,8 +537,9 @@ static void xhci_clear_port_change_bit(struct xhci_hcd *xhci, u16 wValue,
/* Change bits are all write 1 to clear */
writel(port_status | status, addr);
port_status = readl(addr);
- xhci_dbg(xhci, "clear port %s change, actual port %d status = 0x%x\n",
- port_change_bit, wIndex, port_status);
+
+ xhci_dbg(xhci, "clear port%d %s change, portsc: 0x%x\n",
+ wIndex + 1, port_change_bit, port_status);
}
struct xhci_hub *xhci_get_rhub(struct usb_hcd *hcd)
@@ -565,13 +566,16 @@ static void xhci_set_port_power(struct xhci_hcd *xhci, struct usb_hcd *hcd,
rhub = xhci_get_rhub(hcd);
port = rhub->ports[index];
temp = readl(port->addr);
+
+ xhci_dbg(xhci, "set port power %d-%d %s, portsc: 0x%x\n",
+ hcd->self.busnum, index + 1, on ? "ON" : "OFF", temp);
+
temp = xhci_port_state_to_neutral(temp);
+
if (on) {
/*
Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers
Hi Hans, On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote: > Hi Heikki, > > On 28-02-19 15:47, Heikki Krogerus wrote: > > Hi Hans, > > > > On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote: > > > Hi, > > > > > > On 28-02-19 10:15, Heikki Krogerus wrote: > > > > > > > I've been thinking about this... Do we actually need to link the > > > > correct drm_connector to the Type-C connector? Perhaps we can make > > > > this work by just linking the GFX device to the Type-C connector. > > > > > > What use is it to the kms driver if it gets an event there is a DP > > > hotplug with x lanes and orientation foo, if we are not telling it > > > on which DP port it is ? kms devices already have multiple DP ports > > > and more then one could be hooked-up to type-c connectors. > > > > I was looking at this series. You walk trough every DP port in the > > system when the DP alt mode driver broadcasts the event, but maybe > > that's different. Never mind. > > Right, my "simple / naive" solution simply tells the kms driver to > check all DP ports for connection state changes, similar to how > running "xrandr" under Xorg causes the kms driver to re-check the > connection status of all ports. Actually running xrandr under Xorg > after plugging in the cable, is how I did my initial DP over Type-C > testing on the GPD win. > > But once we start passing extra-info, I believe the kms driver needs > to know to which connector that info belongs. > > > > > > > Well, I don't think we can deny the GPU driver (in this case) the > > > > information that we have and that is relevant to it, just because it > > > > seems difficult to deliver that information to the right location. > > > > > > Right, but this does not require a tight-coupling. My original > > > proposal can do this if we pass a data struct with an identifier > > > for the DP port for which the event is to the notifier. I suggest using > > > a string for identifier, something like: ":00:02.0/DP-1" this > > > event struct could then also contain all the info we want to pass. > > > > I do agree that we should not tie the objects (device entries) > > representing these components in kernel together, but I assume that we > > agree now that the connection between the two - the USB Type-C > > connector and the DisplayPort - must be described somewhere, either in > > firmware or build-in? So I guess we are talking implementation details > > here, right? > > Right. > > > If that is the case... > > > > That string identifier you proposed would basically provide the > > details about the connection, so if we know those details, we might as > > well use "normal" ways to describe the connection and just extract > > them in runtime in the function that our DP alt mode driver calls. I > > think the connection has to be defined in i915 on CHT in any case. > > Interesting, I think the connection should be described in the fwnode > for the fusb302 device for the CHT/GPD win case. Specifically I think > this fits well as a property of the dp altmode. OK, you are correct. I was stupidly still thinking about the driver loading order, but the order does not matter. > > The DP alt mode driver should definitely not need to pass anything > > else to the notifier other than handle to itself (actually, handle > > straight to the port device would be better) as an identifier. The > > notifier function needs to be the one that determines the actual > > connection using that handle. Even if the target DP is described using > > a string like you propose, then that string has to come from > > somewhere, most likely from a device property. The notifier function > > can just as well extract it, we don't need to pass it separately. > > > > Here's my suggestion for function prototype: > > > > int drm_typec_dp_notification(struct device *typec_port_dev, > >struct typec_displayport_data *data); > > How about instead of the port_dev we pass in the altmode object and > we have a method to get the fwnode for the altmode? Then the > drm_typec_dp_notification() function can get info from that fwnode > to implement the connection finding you describe below: We can pass the altmode object, np, but let's not decide which fwnode we'll ultimately use. I'm still leaning towards the connector node. > > So that function finds the connection between typec_port_dev and the > > correct DP in runtime, possibly by letting i915 (or what ever GPU > > driver) to do that. Once the function is done, it decrements any ref > > counts that it incremented before returning. > > > > That struct typec_displayport_data has all the information we have - > > the current pin assignment from the Configure VDO, HPD IRQ from the > > last Status Update, etc. - so it needs to be passed as payload to the > > notifier. > > Ack. > > So I believe that this discussion ties into the discussion from the: > "[PATCH 0/2] platform/x86: intel_cht_int33fe: Start using sof
Re: [xhci-hcd][linux 4.20.13] autosuspend on causes a single cpu core to stay in kernel mode using 100% of said cpu core.
Ups I just realised I didn't sent the message to the mailing list, but instead send it to greg only; Basically the problem was happening a month ago on version 4.20.7 ,I have reported it to my distros bug report but I didn't got any response about it. It was consistent on every reboot and shutdown. Even installing a kernel package which previously didn't had any issues didn't fixed the issue so kernels 4.20 - 4.20.7 were also eating one of my cpu cores. (I didn't had any other older version at the time because I did a clean install of windows and then of linux). I run linux with 1 less cpu core for about a week until I found out that I can disable autosuspend. I tried to trigger the error this time around on versions 4.20-4.20.13 even on 4.20.7 where it first occured. And it refuses to happen again, the only thing I really have from this occurrence is perf data, which I used to find out which kernel module was eating my cpu core. This issue was happening regardless of connected usb devices and regardless of whether I was putting the machine to sleep or not. pon., 4 mar 2019 o 13:28 Mathias Nyman napisał(a): > > On 3.3.2019 16.30, Greg KH wrote: > > On Sun, Mar 03, 2019 at 03:15:27PM +0100, Farelka kek wrote: > >> usbcore.autosuspend higher than -1, causes 1 cpu core to never step > >> down from kernel mode. > > > > Some hardware does not aupport autosuspend, so leaving it at -1 is good. > > > >> It happens on a core i5-7200U laptop, an acer f5-573g-50ec > >> Disabling usb autosuspend causes the cpu not to idle at, minimum of > >> 25% cpu usage. > > > > Is this a regression from earlier kernel versions? If so, any chance > > you can run 'git bisect' to find the offending commit? > > > > It could be the following patch: > > 2f31a67 usb: xhci: Prevent bus suspend if a port connect change or polling > state is detected > > It caused similar issues on MacBookPro because of broken usb card reader stuck > in polling state. > > Farelka kek, If that's the case for you, could you try a fix I wrote? > I added the fix on top of 4.20.13 in a suspend_fix branch: > > git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git suspend_fix > https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=suspend_fix > > -Mathias
Re: [xhci-hcd][linux 4.20.13] autosuspend on causes a single cpu core to stay in kernel mode using 100% of said cpu core.
bugs.archlinux.org/task/61682?getfile=17197 I forgot here's perf.data.xz that I gathered pon., 4 mar 2019 o 16:51 Farelka kek napisał(a): > > Ups I just realised I didn't sent the message to the mailing list, but > instead send it to greg only; > Basically the problem was happening a month ago on version 4.20.7 ,I > have reported it to my distros bug report but I didn't got any > response about it. > It was consistent on every reboot and shutdown. > Even installing a kernel package which previously didn't had any > issues didn't fixed the issue so kernels 4.20 - 4.20.7 were also > eating one of my cpu cores. > (I didn't had any other older version at the time because I did a > clean install of windows and then of linux). > I run linux with 1 less cpu core for about a week until I found out > that I can disable autosuspend. > > I tried to trigger the error this time around on versions 4.20-4.20.13 > even on 4.20.7 where it first occured. And it refuses to happen again, > the only thing I really have from this occurrence is perf data, which > I used to find out which kernel module was eating my cpu core. > This issue was happening regardless of connected usb devices and > regardless of whether I was putting the machine to sleep or not. > > pon., 4 mar 2019 o 13:28 Mathias Nyman > napisał(a): > > > > On 3.3.2019 16.30, Greg KH wrote: > > > On Sun, Mar 03, 2019 at 03:15:27PM +0100, Farelka kek wrote: > > >> usbcore.autosuspend higher than -1, causes 1 cpu core to never step > > >> down from kernel mode. > > > > > > Some hardware does not aupport autosuspend, so leaving it at -1 is good. > > > > > >> It happens on a core i5-7200U laptop, an acer f5-573g-50ec > > >> Disabling usb autosuspend causes the cpu not to idle at, minimum of > > >> 25% cpu usage. > > > > > > Is this a regression from earlier kernel versions? If so, any chance > > > you can run 'git bisect' to find the offending commit? > > > > > > > It could be the following patch: > > > > 2f31a67 usb: xhci: Prevent bus suspend if a port connect change or polling > > state is detected > > > > It caused similar issues on MacBookPro because of broken usb card reader > > stuck > > in polling state. > > > > Farelka kek, If that's the case for you, could you try a fix I wrote? > > I added the fix on top of 4.20.13 in a suspend_fix branch: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git suspend_fix > > https://git.kernel.org/pub/scm/linux/kernel/git/mnyman/xhci.git/commit/?h=suspend_fix > > > > -Mathias
Re: [regression] USB power management failure to suspend / high CPU usage
On Mon, Feb 25, 2019 at 5:11 PM Ivan Mironov wrote: > > It fixes the suspend problem from the kernel side, but there is another > one: starting with the second suspend, XHCI controller wakes up the > system just after few seconds after suspending. Laptop keeps looping > through suspend/resume while lid is closed. Hmm, I didn't see the same behavior on my MacBook, but maybe it is because I disable lid power events in /etc/systemd/logind.conf. Suspend/resume worked reliably for a week doing probably about a dozen suspend/resume cycles with Mathias' patch. -Eric
Re: [PATCH v5 1/6] dt-bindings: usb: musb: Add support for MediaTek musb controller
On Sun, Feb 24, 2019 at 7:36 PM Min Guo wrote: > > Hi Rob, > On Fri, 2019-02-22 at 10:49 -0600, Rob Herring wrote: > > On Tue, Feb 19, 2019 at 03:36:30PM +0800, min@mediatek.com wrote: > > > From: Min Guo > > > > > > This adds support for MediaTek musb controller in > > > host, peripheral and otg mode. > > > > > > Signed-off-by: Min Guo > > > --- > > > changes in v5: > > > suggested by Rob: > > > 1. Modify compatible as > > > - compatible : should be one of: > > >"mediatek,mt-2701" > > >... > > >followed by "mediatek,mtk-musb" > > > 2. Add usb connector child node > > > > > > changes in v4: > > > suggested by Sergei: > > > 1. String alignment > > > > > > changes in v3: > > > 1. no changes > > > > > > changes in v2: > > > suggested by Bin: > > > 1. Modify DRC to DRD > > > suggested by Rob: > > > 2. Drop the "-musb" in compatible > > > 3. Remove phy-names > > > 4. Add space after comma in clock-names > > > --- > > > .../devicetree/bindings/usb/mediatek,musb.txt | 54 > > > ++ > > > 1 file changed, 54 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > b/Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > new file mode 100644 > > > index 000..0632e6e > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > @@ -0,0 +1,54 @@ > > > +MediaTek musb DRD/OTG controller > > > +--- > > > + > > > +Required properties: > > > + - compatible : should be one of: > > > + "mediatek,mt-2701" > > > > That looks like a top-level SoC compatible and doesn't match the > > example. > "mediatek,mt-2701" is an example, just to describe a specific SOC. > May I modify compatibel like: > compatible : should be "mediatek,mtk-musb" No, you should fix the example adding "mediatek,mtk-musb". Rob
Re: [PATCH] USB: usb.h: tweak struct urb to remove wasted space
On Sa, 2019-03-02 at 15:36 +0100, Greg Kroah-Hartman wrote: > On Sat, Mar 02, 2019 at 02:51:41PM +0100, Oliver Neukum wrote: > > On Sa, 2019-03-02 at 09:00 +0100, Greg Kroah-Hartman wrote: > > > On Fri, Mar 01, 2019 at 08:44:13PM +0100, Oliver Neukum wrote: > > > > On Fr, 2019-03-01 at 18:22 +0100, Greg Kroah-Hartman wrote: > > > > > By moving one field around in 'struct urb' we reduce the size of the > > > > > structure by 8 bytes. > > > > > > > > If you are going for this I have to ask why unlink and status > > > > are full size ints anyway. > > > > > > History, they hold a "normal" negative error code. I guess we could > > > turn them into s16, if it really matters, but that feels odd to me. > > > > Returning internal error codes to user space is a bug. > > Where does status and unlink end up going to userspace? Maybe through > usbfs? Nowhere, I hope. Sorry for the confusion. I hope I fixed that some time ago. My point here is that using the external errnos for internal error report is not an advantage. In fact, it is a bad idea. A byte would be ample to record internal errors. Regards Oliver
Re: [PATCH v3 04/12] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
Hi Yu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v5.0 next-20190304]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Yu-Chen/Add-support-for-usb-on-Hikey960/20190305-062824
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-x010-201909 (attached as .config)
compiler: gcc-8 (Debian 8.2.0-21) 8.2.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/usb/dwc3/core.c:1855:14: error: 'dwc3_complete' undeclared here (not
>> in a function); did you mean 'complete'?
.complete = dwc3_complete,
^
complete
vim +1855 drivers/usb/dwc3/core.c
1852
1853 static const struct dev_pm_ops dwc3_dev_pm_ops = {
1854 SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
> 1855 .complete = dwc3_complete,
1856 SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
1857 dwc3_runtime_idle)
1858 };
1859
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH] [v2]USB:serial:pl2303:add new Pull-Up mode to support PL2303HXD (TYPE_HX)
Hi Johan, Do you have time to review the two patch? Johan Hovold 於 2019年2月19日 週二 下午4:51寫道： > > On Tue, Feb 19, 2019 at 02:41:28PM +0800, Charles Yeh wrote: > > Hi Johan & Greg, > > > > > > Do you have received a new patch"[PATCH] [v2]USB:serial:pl2303:add new > > Pull-Up mode to support PL2303HXD (TYPE_HX)"? > > > > If you have received a new patch, has the content been confirmed? > > > > Or tell me where needs to be modified. > > Yes, both patches you sent last week are in my queue. I just haven't had > time to review them yet. > > Johan
Re: [PATCH v5 1/6] dt-bindings: usb: musb: Add support for MediaTek musb controller
Hi Rob, On Mon, 2019-03-04 at 11:42 -0600, Rob Herring wrote: > On Sun, Feb 24, 2019 at 7:36 PM Min Guo wrote: > > > > Hi Rob, > > On Fri, 2019-02-22 at 10:49 -0600, Rob Herring wrote: > > > On Tue, Feb 19, 2019 at 03:36:30PM +0800, min@mediatek.com wrote: > > > > From: Min Guo > > > > > > > > This adds support for MediaTek musb controller in > > > > host, peripheral and otg mode. > > > > > > > > Signed-off-by: Min Guo > > > > --- > > > > changes in v5: > > > > suggested by Rob: > > > > 1. Modify compatible as > > > > - compatible : should be one of: > > > >"mediatek,mt-2701" > > > >... > > > >followed by "mediatek,mtk-musb" > > > > 2. Add usb connector child node > > > > > > > > changes in v4: > > > > suggested by Sergei: > > > > 1. String alignment > > > > > > > > changes in v3: > > > > 1. no changes > > > > > > > > changes in v2: > > > > suggested by Bin: > > > > 1. Modify DRC to DRD > > > > suggested by Rob: > > > > 2. Drop the "-musb" in compatible > > > > 3. Remove phy-names > > > > 4. Add space after comma in clock-names > > > > --- > > > > .../devicetree/bindings/usb/mediatek,musb.txt | 54 > > > > ++ > > > > 1 file changed, 54 insertions(+) > > > > create mode 100644 > > > > Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > > > > > > diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > > b/Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > > new file mode 100644 > > > > index 000..0632e6e > > > > --- /dev/null > > > > +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt > > > > @@ -0,0 +1,54 @@ > > > > +MediaTek musb DRD/OTG controller > > > > +--- > > > > + > > > > +Required properties: > > > > + - compatible : should be one of: > > > > + "mediatek,mt-2701" > > > > > > That looks like a top-level SoC compatible and doesn't match the > > > example. > > "mediatek,mt-2701" is an example, just to describe a specific SOC. > > May I modify compatibel like: > > compatible : should be "mediatek,mtk-musb" > > No, you should fix the example adding "mediatek,mtk-musb". OK. > Rob Regards, Min.
RE: [PATCH v4 5/6] usb:cdns3 Add Cadence USB3 DRD Driver
Hi,
On Mon, 2019-03-04 at 11:01 +, Pawel Laszczak wrote:
> Hi,
> >
> >hi,
> >On Thu, 2019-02-14 at 19:45 +, Pawel Laszczak wrote:
> >> This patch introduce new Cadence USBSS DRD driver to linux kernel.
> >>
> >> The Cadence USBSS DRD Driver is a highly configurable IP Core whichi
> >> can be instantiated as Dual-Role Device (DRD), Peripheral Only and
> >> Host Only (XHCI)configurations.
> >>
> >> The current driver has been validated with FPGA burned. We have support
> >> for PCIe bus, which is used on FPGA prototyping.
> >>
> >> The host side of USBSS-DRD controller is compliance with XHCI
> >> specification, so it works with standard XHCI linux driver.
> >>
> >> Signed-off-by: Pawel Laszczak
> >> ---
[...]
> >> diff --git a/drivers/usb/cdns3/Kconfig b/drivers/usb/cdns3/Kconfig
> >> new file mode 100644
> >> index ..27cb3d8dbe3d
> >> --- /dev/null
> >> +++ b/drivers/usb/cdns3/Kconfig
> >> @@ -0,0 +1,44 @@
> >> +config USB_CDNS3
> >> + tristate "Cadence USB3 Dual-Role Controller"
> >> + depends on USB_SUPPORT && (USB || USB_GADGET) && HAS_DMA
> >> + help
> >> +Say Y here if your system has a cadence USB3 dual-role controller.
> >> +It supports: dual-role switch, Host-only, and Peripheral-only.
> >> +
> >> +If you choose to build this driver is a dynamically linked
> >> +as module, the module will be called cdns3.ko.
> >> +
> >> +if USB_CDNS3
> >> +
> >> +config USB_CDNS3_GADGET
> >> +bool "Cadence USB3 device controller"
> >> +depends on USB_GADGET
> >> +help
> >> + Say Y here to enable device controller functionality of the
> >> + cadence USBSS-DEV driver.
> >> +
> >> + This controller supports FF, HS and SS mode. It doesn't support
> >> + LS and SSP mode.
> >> +
> >> +config USB_CDNS3_HOST
> >> +bool "Cadence USB3 host controller"
> >> +depends on USB_XHCI_HCD
> >> +help
> >> + Say Y here to enable host controller functionality of the
> >> + cadence driver.
> >> +
> >> + Host controller is compliant with XHCI so it will use
> >> + standard XHCI driver.
> >> +
> >> +config USB_CDNS3_PCI_WRAP
> >> + tristate "Cadence USB3 support on PCIe-based platforms"
> >> + depends on USB_PCI && ACPI
> >> + default USB_CDNS3
> >> + help
> >> +If you're using the USBSS Core IP with a PCIe, please say
> >> +'Y' or 'M' here.
> >> +
> >> +If you choose to build this driver as module it will
> >> +be dynamically linked and module will be called cdns3-pci.ko
> >> +
> >> +endif
> >> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
> >> new file mode 100644
> >> index ..8f9438593375
> >> --- /dev/null
> >> +++ b/drivers/usb/cdns3/Makefile
> >> @@ -0,0 +1,14 @@
> >> +# SPDX-License-Identifier: GPL-2.0
> >> +# define_trace.h needs to know how to find our header
> >> +CFLAGS_trace.o:= -I$(src)
> >> +
> >> +cdns3-y := core.o drd.o trace.o
> >> +
> >> +obj-$(CONFIG_USB_CDNS3) += cdns3.o
> >> +ifneq ($(CONFIG_DEBUG_FS),)
> >> + cdns3-y += debugfs.o
> >> +endif
> >> +
> >> +cdns3-$(CONFIG_USB_CDNS3_GADGET) += gadget.o ep0.o
> >> +cdns3-$(CONFIG_USB_CDNS3_HOST)+= host.o
> >> +obj-$(CONFIG_USB_CDNS3_PCI_WRAP) += cdns3-pci-wrap.o
> >when build as module:
> >CONFIG_USB_CDNS3=m
> >CONFIG_USB_CDNS3_GADGET=m
> >CONFIG_USB_CDNS3_HOST=m
>
> How you set such configuration ? From make menuconfig it's impossible.
I checked again, I changed it directly for easy test, sorry
>
> >there is an error:
> >ERROR: "cdns3_handshake" [drivers/usb/cdns3/cdns3.ko] undefined!
> >
> >when only set:
> >CONFIG_USB_CDNS3=y
> >also encounter errors:
> >drivers/usb/cdns3/drd.o: In function `cdns3_drd_switch_gadget':
> >/drivers/usb/cdns3/drd.c:173: undefined reference to `cdns3_handshake'
> >drivers/usb/cdns3/drd.o: In function `cdns3_drd_switch_host':
> >drivers/usb/cdns3/drd.c:139: undefined reference to `cdns3_handshake'
>
> I will check this.
> Thanks.
>
> >
> >
> >
> >> diff --git a/drivers/usb/cdns3/cdns3-pci-wrap.c
> >> b/drivers/usb/cdns3/cdns3-pci-wrap.c
> >> new file mode 100644
> >> index ..d0b2d3d9b983
> >> --- /dev/null
> >> +++ b/drivers/usb/cdns3/cdns3-pci-wrap.c
> >> @@ -0,0 +1,155 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Cadence USBSS PCI Glue driver
> >> + *
> >> + * Copyright (C) 2018 Cadence.
> >> + *
> >> + * Author: Pawel Laszczak
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +struct cdns3_wrap {
> >> + struct platform_device *plat_dev;
> >> + struct pci_dev *hg_dev;
> >> + struct resource dev_res[4];
> >> +};
> >> +
> >> +struct cdns3_wrap wrap;
> >not used in fact?
>
> Yes, I forgot to remove it.
> >
> >> +
> >> +#define RES_IRQ_ID0
> >> +#define RES_HOST_ID 1
Re: [PATCH] usb: introduce usb_ep_type_string() function
Hi,
On Fri, 2019-03-01 at 17:21 +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 01, 2019 at 02:58:23PM +0800, Chunfeng Yun wrote:
> > In some places, the code prints a human-readable USB endpoint
> > transfer type (e.g. "bulk"). This involves a switch statement
> > sometimes wrapped around in ({ ... }) block leading to code
> > repetition.
> > To make this scenario easier, here introduces usb_ep_type_string()
> > function, which returns a human-readable name of provided
> > endpoint type.
> > It also changes a few places switch was used to use this
> > new function.
> >
> > Signed-off-by: Chunfeng Yun
> > ---
> > drivers/usb/common/common.c | 16
> > drivers/usb/core/endpoint.c | 18 ++
> > drivers/usb/core/hcd.c | 17 ++---
> > drivers/usb/dwc3/debugfs.c | 23 ---
> > drivers/usb/gadget/udc/aspeed-vhub/epn.c | 6 +-
> > drivers/usb/gadget/udc/dummy_hcd.c | 16 +---
> > drivers/usb/host/xhci-trace.h| 19 ++-
> > include/linux/usb/ch9.h | 8
> > 8 files changed, 36 insertions(+), 87 deletions(-)
> >
> > diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> > index 48277bbc15e4..2174dd9ec176 100644
> > --- a/drivers/usb/common/common.c
> > +++ b/drivers/usb/common/common.c
> > @@ -16,6 +16,22 @@
> > #include
> > #include
> >
> > +static const char *const ep_type_names[] = {
> > + [USB_ENDPOINT_XFER_CONTROL] = "ctrl",
> > + [USB_ENDPOINT_XFER_ISOC] = "isoc",
> > + [USB_ENDPOINT_XFER_BULK] = "bulk",
> > + [USB_ENDPOINT_XFER_INT] = "intr",
> > +};
> > +
> > +const char *usb_ep_type_string(int ep_type)
> > +{
> > + if (ep_type < 0 || ep_type >= ARRAY_SIZE(ep_type_names))
> > + return "unknown";
> > +
> > + return ep_type_names[ep_type];
> > +}
> > +EXPORT_SYMBOL_GPL(usb_ep_type_string);
> > +
> > const char *usb_otg_state_string(enum usb_otg_state state)
> > {
> > static const char *const names[] = {
> > diff --git a/drivers/usb/core/endpoint.c b/drivers/usb/core/endpoint.c
> > index 1c2c04079676..afa43f9a47b2 100644
> > --- a/drivers/usb/core/endpoint.c
> > +++ b/drivers/usb/core/endpoint.c
> > @@ -60,23 +60,9 @@ static ssize_t type_show(struct device *dev, struct
> > device_attribute *attr,
> > char *buf)
> > {
> > struct ep_device *ep = to_ep_device(dev);
> > - char *type = "unknown";
> > + int ep_type = usb_endpoint_type(ep->desc);
> >
> > - switch (usb_endpoint_type(ep->desc)) {
> > - case USB_ENDPOINT_XFER_CONTROL:
> > - type = "Control";
> > - break;
> > - case USB_ENDPOINT_XFER_ISOC:
> > - type = "Isoc";
> > - break;
> > - case USB_ENDPOINT_XFER_BULK:
> > - type = "Bulk";
> > - break;
> > - case USB_ENDPOINT_XFER_INT:
> > - type = "Interrupt";
> > - break;
> > - }
> > - return sprintf(buf, "%s\n", type);
> > + return sprintf(buf, "%s\n", usb_ep_type_string(ep_type));
>
> You just changed a user/kernel API here, the strings are now different
> from what they used to be :(
How about using these type string to keep them unchanged?
I need help from Felipe and Mathias to check whether the changes in dwc3
and xhci have side effect or not, and waiting for their comments
Thanks
>
> That's not ok, odds are you will break tools if you do this.
>
> > }
> > static DEVICE_ATTR_RO(type);
> >
> > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
> > index 015b126ce455..193ee92b2fdb 100644
> > --- a/drivers/usb/core/hcd.c
> > +++ b/drivers/usb/core/hcd.c
> > @@ -1875,23 +1875,10 @@ void usb_hcd_flush_endpoint(struct usb_device *udev,
> > /* kick hcd */
> > unlink1(hcd, urb, -ESHUTDOWN);
> > dev_dbg (hcd->self.controller,
> > - "shutdown urb %pK ep%d%s%s\n",
> > + "shutdown urb %pK ep%d%s-%s\n",
> > urb, usb_endpoint_num(&ep->desc),
> > is_in ? "in" : "out",
> > - ({ char *s;
> > -
> > -switch (usb_endpoint_type(&ep->desc)) {
> > -case USB_ENDPOINT_XFER_CONTROL:
> > - s = ""; break;
> > -case USB_ENDPOINT_XFER_BULK:
> > - s = "-bulk"; break;
> > -case USB_ENDPOINT_XFER_INT:
> > - s = "-intr"; break;
> > -default:
> > - s = "-iso"; break;
> > - };
> > - s;
> > - }));
> > + usb_ep_type_string(usb_endpoint_type(&ep->desc)));
>
> You also changed the message here for control endpoints, but that's not
> a big deal, it's ok.
>
> >
Re: [PATCH v3 04/12] usb: dwc3: Add splitdisable quirk for Hisilicon Kirin Soc
Hi Yu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on balbi-usb/next]
[also build test ERROR on v5.0 next-20190304]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Yu-Chen/Add-support-for-usb-on-Hikey960/20190305-062824
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: x86_64-randconfig-u0-03051004 (attached as .config)
compiler: gcc-5 (Debian 5.5.0-3) 5.4.1 20171010
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/usb/dwc3/core.c:1855:14: error: 'dwc3_complete' undeclared here (not
>> in a function)
.complete = dwc3_complete,
^
vim +/dwc3_complete +1855 drivers/usb/dwc3/core.c
1852
1853 static const struct dev_pm_ops dwc3_dev_pm_ops = {
1854 SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
> 1855 .complete = dwc3_complete,
1856 SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
1857 dwc3_runtime_idle)
1858 };
1859
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
RE: [PATCH 1/2] usb: chipiea: add flags for id and vbus from external block
Hi Peter,
> -Original Message-
> From: Peter Chen
> Sent: 2019年3月1日 11:04
> To: Jun Li
> Cc: gre...@linuxfoundation.org; linux-usb@vger.kernel.org; dl-linux-imx
>
> Subject: RE: [PATCH 1/2] usb: chipiea: add flags for id and vbus from
> external block
>
>
> > >
> > >
> > > > drivers/usb/chipidea/core.c | 2 ++ include/linux/usb/chipidea.h
> > > > |
> > > > 4
> > > > 2 files changed, 6 insertions(+)
> > > >
> > > > diff --git a/drivers/usb/chipidea/core.c
> > > > b/drivers/usb/chipidea/core.c index
> > > > 7bfcbb2..0bfa850 100644
> > > > --- a/drivers/usb/chipidea/core.c
> > > > +++ b/drivers/usb/chipidea/core.c
> > > > @@ -706,6 +706,7 @@ static int ci_get_platdata(struct device *dev,
> > > > cable->edev = ext_vbus;
> > > >
> > > > if (!IS_ERR(ext_vbus)) {
> > > > + platdata->ext_vbus = true;
> > > > ret = extcon_get_state(cable->edev, EXTCON_USB);
> > > > if (ret)
> > > > cable->connected = true;
> > > > @@ -718,6 +719,7 @@ static int ci_get_platdata(struct device *dev,
> > > > cable->edev = ext_id;
> > > >
> > > > if (!IS_ERR(ext_id)) {
> > > > + platdata->ext_id = true;
> > > > ret = extcon_get_state(cable->edev, EXTCON_USB_HOST);
> > > > if (ret)
> > > > cable->connected = true;
> > > > diff --git a/include/linux/usb/chipidea.h
> > > > b/include/linux/usb/chipidea.h index
> > > > 911e05a..cd72d82 100644
> > > > --- a/include/linux/usb/chipidea.h
> > > > +++ b/include/linux/usb/chipidea.h
> > > > @@ -70,6 +70,10 @@ struct ci_hdrc_platform_data {
> > > > struct regulator*reg_vbus;
> > > > struct usb_otg_caps ci_otg_caps;
> > > > booltpl_support;
> > > > + /* ID state is from external event out side of USB */
> > > > + boolext_id;
> > > > + /* VBUS state is from external event out side of USB */
> > > > + boolext_vbus;
> > >
> > > We already have struct ci_hdrc_cable at this structure, please use it
> > > instead.
> >
> > I am going to extend ci_hdrc_cable also for type-C case, which has no
> > edev, So it's OK to add a flag in ci_hdrc_cable for both edev and
> > type-C to indicate external block is used?
> >
>
> Why there is no external cable (edev) for Type-C case? If there is no
> external cable
> phandle at controller dts, how driver knows the Type-C connection occurs?
The new usb_role class doesn't depends on edev, see how this can work on dwc3:
https://patchwork.kernel.org/patch/10836519/
Li Jun
>
> Peter
RE: [PATCH v2 2/2] usb: typec: add typec switch via GPIO control
Hi Andy,
> -Original Message-
> From: Andy Shevchenko
> Sent: 2019年3月3日 0:27
> To: Jun Li
> Cc: robh...@kernel.org; heikki.kroge...@linux.intel.com;
> gre...@linuxfoundation.org; hdego...@redhat.com; linux-usb@vger.kernel.org;
> devicet...@vger.kernel.org; dl-linux-imx
> Subject: Re: [PATCH v2 2/2] usb: typec: add typec switch via GPIO control
>
> On Fri, Mar 1, 2019 at 3:25 AM Jun Li wrote:
> >
> > This patch adds a simple typec switch driver which only needs a GPIO
> > to switch the super speed active channel according to typec
> > orientation.
>
> FWIW,
> Reviewed-by: Andy Shevchenko
>
> One minor below.
>
> >
> > Signed-off-by: Li Jun
> > ---
> >
> > Changes for v2:
> > - Use the correct head files for gpio api and of_device_id:
> > #include
> > #include
> > - Add driver dependency on GPIOLIB
> >
> > drivers/usb/typec/mux/Kconfig | 7 +++
> > drivers/usb/typec/mux/Makefile | 1 +
> > drivers/usb/typec/mux/gpio-switch.c | 105
> >
> > 3 files changed, 113 insertions(+)
> >
> > diff --git a/drivers/usb/typec/mux/Kconfig
> > b/drivers/usb/typec/mux/Kconfig index 01ed0d5..27120e6 100644
> > --- a/drivers/usb/typec/mux/Kconfig
> > +++ b/drivers/usb/typec/mux/Kconfig
> > @@ -9,4 +9,11 @@ config TYPEC_MUX_PI3USB30532
> > Say Y or M if your system has a Pericom PI3USB30532 Type-C cross
> > switch / mux chip found on some devices with a Type-C port.
> >
> > +config TYPEC_SWITCH_GPIO
> > + tristate "Simple Super Speed Active Switch via GPIO"
> > + depends on GPIOLIB
> > + help
> > + Say Y or M if your system has a typec super speed channel
> > + switch via a simple GPIO control.
> > +
> > endmenu
> > diff --git a/drivers/usb/typec/mux/Makefile
> > b/drivers/usb/typec/mux/Makefile index 1332e46..e29377c 100644
> > --- a/drivers/usb/typec/mux/Makefile
> > +++ b/drivers/usb/typec/mux/Makefile
> > @@ -1,3 +1,4 @@
> > # SPDX-License-Identifier: GPL-2.0
> >
> > obj-$(CONFIG_TYPEC_MUX_PI3USB30532)+= pi3usb30532.o
> > +obj-$(CONFIG_TYPEC_SWITCH_GPIO)+= gpio-switch.o
> > diff --git a/drivers/usb/typec/mux/gpio-switch.c
> > b/drivers/usb/typec/mux/gpio-switch.c
> > new file mode 100644
> > index 000..b01844c
> > --- /dev/null
> > +++ b/drivers/usb/typec/mux/gpio-switch.c
> > @@ -0,0 +1,105 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/**
>
> > + * gpio-switch.c - typec switch via a simple GPIO control.
>
> If under any circumstances file will be renamed this become outdated.
> So, better not to include file name in the file.
OK, I will remove this.
Thanks
Li Jun
>
> > + *
> > + * Copyright 2019 NXP
> > + * Author: Jun Li
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct gpio_typec_switch {
> > + struct typec_switch sw;
> > + struct mutex lock;
> > + struct gpio_desc *ss_sel;
> > +};
> > +
> > +static int switch_gpio_set(struct typec_switch *sw,
> > + enum typec_orientation orientation) {
> > + struct gpio_typec_switch *gpio_sw = container_of(sw,
> > + struct gpio_typec_switch, sw);
> > +
> > + mutex_lock(&gpio_sw->lock);
> > +
> > + switch (orientation) {
> > + case TYPEC_ORIENTATION_NORMAL:
> > + gpiod_set_value_cansleep(gpio_sw->ss_sel, 1);
> > + break;
> > + case TYPEC_ORIENTATION_REVERSE:
> > + gpiod_set_value_cansleep(gpio_sw->ss_sel, 0);
> > + break;
> > + case TYPEC_ORIENTATION_NONE:
> > + break;
> > + }
> > +
> > + mutex_unlock(&gpio_sw->lock);
> > +
> > + return 0;
> > +}
> > +
> > +static int typec_switch_gpio_probe(struct platform_device *pdev) {
> > + struct gpio_typec_switch*gpio_sw;
> > + struct device *dev = &pdev->dev;
> > + int ret;
> > +
> > + gpio_sw = devm_kzalloc(dev, sizeof(*gpio_sw), GFP_KERNEL);
> > + if (!gpio_sw)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, gpio_sw);
> > +
> > + gpio_sw->sw.dev = dev;
> > + gpio_sw->sw.set = switch_gpio_set;
> > + mutex_init(&gpio_sw->lock);
> > +
> > + /* Get the super speed active channel selection GPIO */
> > + gpio_sw->ss_sel = devm_gpiod_get(dev, NULL, GPIOD_OUT_LOW);
> > + if (IS_ERR(gpio_sw->ss_sel))
> > + return PTR_ERR(gpio_sw->ss_sel);
> > +
> > + ret = typec_switch_register(&gpio_sw->sw);
> > + if (ret) {
> > + dev_err(dev, "Error registering typec switch: %d\n", ret);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int typec_switch_gpio_remove(struct platform_device *pdev) {
> > + struct gpio_typec_switch *gpio_sw =
> > +platform_get_drvdata(pdev);
>
Re: [PATCH 0/3] Propagate DP-over-Type-C hotplug events from Type-C subsys to drm-drivers
Hi, On 04-03-19 16:17, Heikki Krogerus wrote: Hi Hans, On Thu, Feb 28, 2019 at 05:54:21PM +0100, Hans de Goede wrote: Hi Heikki, On 28-02-19 15:47, Heikki Krogerus wrote: Hi Hans, On Thu, Feb 28, 2019 at 12:24:25PM +0100, Hans de Goede wrote: Hi, On 28-02-19 10:15, Heikki Krogerus wrote: I've been thinking about this... Do we actually need to link the correct drm_connector to the Type-C connector? Perhaps we can make this work by just linking the GFX device to the Type-C connector. What use is it to the kms driver if it gets an event there is a DP hotplug with x lanes and orientation foo, if we are not telling it on which DP port it is ? kms devices already have multiple DP ports and more then one could be hooked-up to type-c connectors. I was looking at this series. You walk trough every DP port in the system when the DP alt mode driver broadcasts the event, but maybe that's different. Never mind. Right, my "simple / naive" solution simply tells the kms driver to check all DP ports for connection state changes, similar to how running "xrandr" under Xorg causes the kms driver to re-check the connection status of all ports. Actually running xrandr under Xorg after plugging in the cable, is how I did my initial DP over Type-C testing on the GPD win. But once we start passing extra-info, I believe the kms driver needs to know to which connector that info belongs. Well, I don't think we can deny the GPU driver (in this case) the information that we have and that is relevant to it, just because it seems difficult to deliver that information to the right location. Right, but this does not require a tight-coupling. My original proposal can do this if we pass a data struct with an identifier for the DP port for which the event is to the notifier. I suggest using a string for identifier, something like: ":00:02.0/DP-1" this event struct could then also contain all the info we want to pass. I do agree that we should not tie the objects (device entries) representing these components in kernel together, but I assume that we agree now that the connection between the two - the USB Type-C connector and the DisplayPort - must be described somewhere, either in firmware or build-in? So I guess we are talking implementation details here, right? Right. If that is the case... That string identifier you proposed would basically provide the details about the connection, so if we know those details, we might as well use "normal" ways to describe the connection and just extract them in runtime in the function that our DP alt mode driver calls. I think the connection has to be defined in i915 on CHT in any case. Interesting, I think the connection should be described in the fwnode for the fusb302 device for the CHT/GPD win case. Specifically I think this fits well as a property of the dp altmode. OK, you are correct. I was stupidly still thinking about the driver loading order, but the order does not matter. The DP alt mode driver should definitely not need to pass anything else to the notifier other than handle to itself (actually, handle straight to the port device would be better) as an identifier. The notifier function needs to be the one that determines the actual connection using that handle. Even if the target DP is described using a string like you propose, then that string has to come from somewhere, most likely from a device property. The notifier function can just as well extract it, we don't need to pass it separately. Here's my suggestion for function prototype: int drm_typec_dp_notification(struct device *typec_port_dev, struct typec_displayport_data *data); How about instead of the port_dev we pass in the altmode object and we have a method to get the fwnode for the altmode? Then the drm_typec_dp_notification() function can get info from that fwnode to implement the connection finding you describe below: We can pass the altmode object, np, but let's not decide which fwnode we'll ultimately use. I'm still leaning towards the connector node. So that function finds the connection between typec_port_dev and the correct DP in runtime, possibly by letting i915 (or what ever GPU driver) to do that. Once the function is done, it decrements any ref counts that it incremented before returning. That struct typec_displayport_data has all the information we have - the current pin assignment from the Configure VDO, HPD IRQ from the last Status Update, etc. - so it needs to be passed as payload to the notifier. Ack. So I believe that this discussion ties into the discussion from the: "[PATCH 0/2] platform/x86: intel_cht_int33fe: Start using software nodes" Mail thread. As discussed there I agree that adding a usb_connector child fwnode to the fwnode for the fusb302 to describe things like sink- and source-pdos is a good idea. Our last few mails were discussing describing supported alt-modes on the connector by adding altmode child-nodes to th
