Centos-kernel-stream-9/drivers/usb/dwc3/core.c

2673 lines
67 KiB
C
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
/*
* core.c - DesignWare USB3 DRD Controller Core file
*
* Copyright (C) 2010-2011 Texas Instruments Incorporated - https://www.ti.com
*
* Authors: Felipe Balbi <balbi@ti.com>,
* Sebastian Andrzej Siewior <bigeasy@linutronix.de>
*/
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
#include <linux/clk.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/spinlock.h>
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/interrupt.h>
#include <linux/ioport.h>
#include <linux/io.h>
#include <linux/list.h>
#include <linux/delay.h>
#include <linux/dma-mapping.h>
#include <linux/of.h>
#include <linux/of_graph.h>
#include <linux/acpi.h>
#include <linux/pinctrl/consumer.h>
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
#include <linux/reset.h>
#include <linux/bitfield.h>
#include <linux/usb/ch9.h>
#include <linux/usb/gadget.h>
#include <linux/usb/of.h>
#include <linux/usb/otg.h>
#include "core.h"
#include "gadget.h"
#include "io.h"
#include "debug.h"
#include "../host/xhci-ext-caps.h"
#define DWC3_DEFAULT_AUTOSUSPEND_DELAY 5000 /* ms */
/**
* dwc3_get_dr_mode - Validates and sets dr_mode
* @dwc: pointer to our context structure
*/
static int dwc3_get_dr_mode(struct dwc3 *dwc)
{
enum usb_dr_mode mode;
struct device *dev = dwc->dev;
unsigned int hw_mode;
if (dwc->dr_mode == USB_DR_MODE_UNKNOWN)
dwc->dr_mode = USB_DR_MODE_OTG;
mode = dwc->dr_mode;
hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
switch (hw_mode) {
case DWC3_GHWPARAMS0_MODE_GADGET:
if (IS_ENABLED(CONFIG_USB_DWC3_HOST)) {
dev_err(dev,
"Controller does not support host mode.\n");
return -EINVAL;
}
mode = USB_DR_MODE_PERIPHERAL;
break;
case DWC3_GHWPARAMS0_MODE_HOST:
if (IS_ENABLED(CONFIG_USB_DWC3_GADGET)) {
dev_err(dev,
"Controller does not support device mode.\n");
return -EINVAL;
}
mode = USB_DR_MODE_HOST;
break;
default:
if (IS_ENABLED(CONFIG_USB_DWC3_HOST))
mode = USB_DR_MODE_HOST;
else if (IS_ENABLED(CONFIG_USB_DWC3_GADGET))
mode = USB_DR_MODE_PERIPHERAL;
/*
* DWC_usb31 and DWC_usb3 v3.30a and higher do not support OTG
* mode. If the controller supports DRD but the dr_mode is not
* specified or set to OTG, then set the mode to peripheral.
*/
if (mode == USB_DR_MODE_OTG && !dwc->edev &&
(!IS_ENABLED(CONFIG_USB_ROLE_SWITCH) ||
!device_property_read_bool(dwc->dev, "usb-role-switch")) &&
2020-04-12 02:20:01 +00:00
!DWC3_VER_IS_PRIOR(DWC3, 330A))
mode = USB_DR_MODE_PERIPHERAL;
}
if (mode != dwc->dr_mode) {
dev_warn(dev,
"Configuration mismatch. dr_mode forced to %s\n",
mode == USB_DR_MODE_HOST ? "host" : "gadget");
dwc->dr_mode = mode;
}
return 0;
}
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
void dwc3_enable_susphy(struct dwc3 *dwc, bool enable)
{
u32 reg;
int i;
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
for (i = 0; i < dwc->num_usb3_ports; i++) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(i));
if (enable && !dwc->dis_u3_susphy_quirk)
reg |= DWC3_GUSB3PIPECTL_SUSPHY;
else
reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(i), reg);
}
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(i));
if (enable && !dwc->dis_u2_susphy_quirk)
reg |= DWC3_GUSB2PHYCFG_SUSPHY;
else
reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(i), reg);
}
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
}
void dwc3_set_prtcap(struct dwc3 *dwc, u32 mode)
{
u32 reg;
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
reg |= DWC3_GCTL_PRTCAPDIR(mode);
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
dwc->current_dr_role = mode;
}
static void __dwc3_set_mode(struct work_struct *work)
{
struct dwc3 *dwc = work_to_dwc(work);
unsigned long flags;
int ret;
u32 reg;
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
u32 desired_dr_role;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
usb: dwc3: core: Do core softreset when switch mode From: John Stultz <john.stultz@linaro.org> According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Ferry Toth <fntoth@gmail.com> Cc: Wesley Cheng <wcheng@codeaurora.org> Cc: <stable@vger.kernel.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Wesley Cheng <wcheng@codeaurora.org> Signed-off-by: Yu Chen <chenyu56@huawei.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-15 22:20:30 +00:00
mutex_lock(&dwc->mutex);
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
spin_lock_irqsave(&dwc->lock, flags);
desired_dr_role = dwc->desired_dr_role;
spin_unlock_irqrestore(&dwc->lock, flags);
usb: dwc3: core: Do core softreset when switch mode From: John Stultz <john.stultz@linaro.org> According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Ferry Toth <fntoth@gmail.com> Cc: Wesley Cheng <wcheng@codeaurora.org> Cc: <stable@vger.kernel.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Wesley Cheng <wcheng@codeaurora.org> Signed-off-by: Yu Chen <chenyu56@huawei.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-15 22:20:30 +00:00
pm_runtime_get_sync(dwc->dev);
if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_OTG)
dwc3_otg_update(dwc, 0);
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
if (!desired_dr_role)
goto out;
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
if (desired_dr_role == dwc->current_dr_role)
goto out;
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
if (desired_dr_role == DWC3_GCTL_PRTCAP_OTG && dwc->edev)
goto out;
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_HOST:
dwc3_host_exit(dwc);
break;
case DWC3_GCTL_PRTCAP_DEVICE:
dwc3_gadget_exit(dwc);
dwc3_event_buffers_cleanup(dwc);
break;
case DWC3_GCTL_PRTCAP_OTG:
dwc3_otg_exit(dwc);
spin_lock_irqsave(&dwc->lock, flags);
dwc->desired_otg_role = DWC3_OTG_ROLE_IDLE;
spin_unlock_irqrestore(&dwc->lock, flags);
dwc3_otg_update(dwc, 1);
break;
default:
break;
}
usb: dwc3: core: Do not perform GCTL_CORE_SOFTRESET during bootup Bugzilla: http://bugzilla.redhat.com/2113003 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=48723298 Tested: HP ZBook 15 G5/80D5 Laptop ThinkPad P1 Gen5 TB4 HP zBook Fury commit 07903626d98853e605fe63e5ce149f1b7314bbea Author: Rohith Kollalsi <quic_rkollals@quicinc.com> Date: Thu Jul 14 10:26:25 2022 +0530 usb: dwc3: core: Do not perform GCTL_CORE_SOFTRESET during bootup According to the programming guide, it is recommended to perform a GCTL_CORE_SOFTRESET only when switching the mode from device to host or host to device. However, it is found that during bootup when __dwc3_set_mode() is called for the first time, GCTL_CORESOFTRESET is done with suspendable bit(BIT 17) of DWC3_GUSB3PIPECTL set. This some times leads to issues like controller going into bad state and controller registers reading value zero. Until GCTL_CORESOFTRESET is done and run/stop bit is set core initialization is not complete. Setting suspendable bit of DWC3_GUSB3PIPECTL and then performing GCTL_CORESOFTRESET is therefore not recommended. Avoid this by only performing the reset if current_dr_role is set, that is, when doing subsequent role switching. Fixes: f88359e1588b ("usb: dwc3: core: Do core softreset when switch mode") Signed-off-by: Rohith Kollalsi <quic_rkollals@quicinc.com> Link: https://lore.kernel.org/r/20220714045625.20377-1-quic_rkollals@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Torez Smith <torez@redhat.com>
2022-11-02 01:34:18 +00:00
/*
* When current_dr_role is not set, there's no role switching.
* Only perform GCTL.CoreSoftReset when there's DRD role switching.
*/
if (dwc->current_dr_role && ((DWC3_IP_IS(DWC3) ||
DWC3_VER_IS_PRIOR(DWC31, 190A)) &&
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
desired_dr_role != DWC3_GCTL_PRTCAP_OTG)) {
usb: dwc3: core: Do core softreset when switch mode From: John Stultz <john.stultz@linaro.org> According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Ferry Toth <fntoth@gmail.com> Cc: Wesley Cheng <wcheng@codeaurora.org> Cc: <stable@vger.kernel.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Wesley Cheng <wcheng@codeaurora.org> Signed-off-by: Yu Chen <chenyu56@huawei.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-15 22:20:30 +00:00
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg |= DWC3_GCTL_CORESOFTRESET;
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
/*
* Wait for internal clocks to synchronized. DWC_usb31 and
* DWC_usb32 may need at least 50ms (less for DWC_usb3). To
* keep it consistent across different IPs, let's wait up to
* 100ms before clearing GCTL.CORESOFTRESET.
*/
msleep(100);
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg &= ~DWC3_GCTL_CORESOFTRESET;
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
}
spin_lock_irqsave(&dwc->lock, flags);
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
dwc3_set_prtcap(dwc, desired_dr_role);
spin_unlock_irqrestore(&dwc->lock, flags);
usb: dwc3: Fix race between dwc3_set_mode and __dwc3_set_mode Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62c73bfea048e66168df09da6d3e4510ecda40bb commit 62c73bfea048e66168df09da6d3e4510ecda40bb Author: Sven Peter <sven@svenpeter.dev> Date: Mon, 28 Nov 2022 17:15:26 +0100 dwc->desired_dr_role is changed by dwc3_set_mode inside a spinlock but then read by __dwc3_set_mode outside of that lock. This can lead to a race condition when very quick successive role switch events happen: CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_HOST) // first role switch event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_HOST spin_unlock_irqrestore(&dwc->lock, flags); queue_work(system_freezable_wq, &dwc->drd_work); CPU B __dwc3_set_mode // .... spin_lock_irqsave(&dwc->lock, flags); // desired_dr_role is DWC3_GCTL_PRTCAP_HOST dwc3_set_prtcap(dwc, dwc->desired_dr_role); spin_unlock_irqrestore(&dwc->lock, flags); CPU A dwc3_set_mode(DWC3_GCTL_PRTCAP_DEVICE) // second event spin_lock_irqsave(&dwc->lock, flags); dwc->desired_dr_role = mode; // DWC3_GCTL_PRTCAP_DEVICE spin_unlock_irqrestore(&dwc->lock, flags); CPU B (continues running __dwc3_set_mode) switch (dwc->desired_dr_role) { // DWC3_GCTL_PRTCAP_DEVICE // .... case DWC3_GCTL_PRTCAP_DEVICE: // .... ret = dwc3_gadget_init(dwc); We then have DWC3_GCTL.DWC3_GCTL_PRTCAPDIR = DWC3_GCTL_PRTCAP_HOST and dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST but initialized the controller in device mode. It's also possible to get into a state where both host and device are intialized at the same time. Fix this race by creating a local copy of desired_dr_role inside __dwc3_set_mode while holding dwc->lock. Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: stable <stable@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Sven Peter <sven@svenpeter.dev> Link: https://lore.kernel.org/r/20221128161526.79730-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:35 +00:00
switch (desired_dr_role) {
case DWC3_GCTL_PRTCAP_HOST:
ret = dwc3_host_init(dwc);
if (ret) {
dev_err(dwc->dev, "failed to initialize host\n");
} else {
if (dwc->usb2_phy)
otg_set_vbus(dwc->usb2_phy->otg, true);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++)
phy_set_mode(dwc->usb2_generic_phy[i], PHY_MODE_USB_HOST);
for (i = 0; i < dwc->num_usb3_ports; i++)
phy_set_mode(dwc->usb3_generic_phy[i], PHY_MODE_USB_HOST);
if (dwc->dis_split_quirk) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
reg |= DWC3_GUCTL3_SPLITDISABLE;
dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
}
}
break;
case DWC3_GCTL_PRTCAP_DEVICE:
usb: dwc3: core: Do core softreset when switch mode From: John Stultz <john.stultz@linaro.org> According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Ferry Toth <fntoth@gmail.com> Cc: Wesley Cheng <wcheng@codeaurora.org> Cc: <stable@vger.kernel.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Wesley Cheng <wcheng@codeaurora.org> Signed-off-by: Yu Chen <chenyu56@huawei.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-15 22:20:30 +00:00
dwc3_core_soft_reset(dwc);
dwc3_event_buffers_setup(dwc);
if (dwc->usb2_phy)
otg_set_vbus(dwc->usb2_phy->otg, false);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
phy_set_mode(dwc->usb2_generic_phy[0], PHY_MODE_USB_DEVICE);
phy_set_mode(dwc->usb3_generic_phy[0], PHY_MODE_USB_DEVICE);
ret = dwc3_gadget_init(dwc);
if (ret)
dev_err(dwc->dev, "failed to initialize peripheral\n");
break;
case DWC3_GCTL_PRTCAP_OTG:
dwc3_otg_init(dwc);
dwc3_otg_update(dwc, 0);
break;
default:
break;
}
out:
pm_runtime_mark_last_busy(dwc->dev);
pm_runtime_put_autosuspend(dwc->dev);
usb: dwc3: core: Do core softreset when switch mode From: John Stultz <john.stultz@linaro.org> According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Ferry Toth <fntoth@gmail.com> Cc: Wesley Cheng <wcheng@codeaurora.org> Cc: <stable@vger.kernel.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Wesley Cheng <wcheng@codeaurora.org> Signed-off-by: Yu Chen <chenyu56@huawei.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-15 22:20:30 +00:00
mutex_unlock(&dwc->mutex);
}
void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
{
unsigned long flags;
usb: dwc3: core: do not queue work if dr_mode is not USB_DR_MODE_OTG Do not try to queue a drd work if dr_mode is not USB_DR_MODE_OTG because the work is not inited, this may be triggered by user try to change mode file of debugfs on a single role port, which will cause below kernel dump: [ 60.115529] ------------[ cut here ]------------ [ 60.120166] WARNING: CPU: 1 PID: 627 at kernel/workqueue.c:1473 __queue_work+0x46c/0x520 [ 60.128254] Modules linked in: [ 60.131313] CPU: 1 PID: 627 Comm: sh Not tainted 5.7.0-rc4-00022-g914a586-dirty #135 [ 60.139054] Hardware name: NXP i.MX8MQ EVK (DT) [ 60.143585] pstate: a0000085 (NzCv daIf -PAN -UAO) [ 60.148376] pc : __queue_work+0x46c/0x520 [ 60.152385] lr : __queue_work+0x314/0x520 [ 60.156393] sp : ffff8000124ebc40 [ 60.159705] x29: ffff8000124ebc40 x28: ffff800011808018 [ 60.165018] x27: ffff800011819ef8 x26: ffff800011d39980 [ 60.170331] x25: ffff800011808018 x24: 0000000000000100 [ 60.175643] x23: 0000000000000013 x22: 0000000000000001 [ 60.180955] x21: ffff0000b7c08e00 x20: ffff0000b6c31080 [ 60.186267] x19: ffff0000bb99bc00 x18: 0000000000000000 [ 60.191579] x17: 0000000000000000 x16: 0000000000000000 [ 60.196891] x15: 0000000000000000 x14: 0000000000000000 [ 60.202202] x13: 0000000000000000 x12: 0000000000000000 [ 60.207515] x11: 0000000000000000 x10: 0000000000000040 [ 60.212827] x9 : ffff800011d55460 x8 : ffff800011d55458 [ 60.218138] x7 : ffff0000b7800028 x6 : 0000000000000000 [ 60.223450] x5 : ffff0000b7800000 x4 : 0000000000000000 [ 60.228762] x3 : ffff0000bb997cc0 x2 : 0000000000000001 [ 60.234074] x1 : 0000000000000000 x0 : ffff0000b6c31088 [ 60.239386] Call trace: [ 60.241834] __queue_work+0x46c/0x520 [ 60.245496] queue_work_on+0x6c/0x90 [ 60.249075] dwc3_set_mode+0x48/0x58 [ 60.252651] dwc3_mode_write+0xf8/0x150 [ 60.256489] full_proxy_write+0x5c/0xa8 [ 60.260327] __vfs_write+0x18/0x40 [ 60.263729] vfs_write+0xdc/0x1c8 [ 60.267045] ksys_write+0x68/0xf0 [ 60.270360] __arm64_sys_write+0x18/0x20 [ 60.274286] el0_svc_common.constprop.0+0x68/0x160 [ 60.279077] do_el0_svc+0x20/0x80 [ 60.282394] el0_sync_handler+0x10c/0x178 [ 60.286403] el0_sync+0x140/0x180 [ 60.289716] ---[ end trace 70b155582e2b7988 ]--- Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-07-26 03:17:39 +00:00
if (dwc->dr_mode != USB_DR_MODE_OTG)
return;
spin_lock_irqsave(&dwc->lock, flags);
dwc->desired_dr_role = mode;
spin_unlock_irqrestore(&dwc->lock, flags);
queue_work(system_freezable_wq, &dwc->drd_work);
}
u32 dwc3_core_fifo_space(struct dwc3_ep *dep, u8 type)
{
struct dwc3 *dwc = dep->dwc;
u32 reg;
dwc3_writel(dwc->regs, DWC3_GDBGFIFOSPACE,
DWC3_GDBGFIFOSPACE_NUM(dep->number) |
DWC3_GDBGFIFOSPACE_TYPE(type));
reg = dwc3_readl(dwc->regs, DWC3_GDBGFIFOSPACE);
return DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(reg);
}
/**
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
* @dwc: pointer to our context structure
*/
int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32 reg;
int retries = 1000;
/*
* We're resetting only the device side because, if we're in host mode,
* XHCI driver will reset the host block. If dwc3 was configured for
* host-only mode, then we can return early.
*/
if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST)
return 0;
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg |= DWC3_DCTL_CSFTRST;
reg &= ~DWC3_DCTL_RUN_STOP;
dwc3_gadget_dctl_write_safe(dwc, reg);
/*
* For DWC_usb31 controller 1.90a and later, the DCTL.CSFRST bit
* is cleared only after all the clocks are synchronized. This can
* take a little more than 50ms. Set the polling rate at 20ms
* for 10 times instead.
*/
2020-04-12 02:20:01 +00:00
if (DWC3_VER_IS_WITHIN(DWC31, 190A, ANY) || DWC3_IP_IS(DWC32))
retries = 10;
do {
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
if (!(reg & DWC3_DCTL_CSFTRST))
goto done;
2020-04-12 02:20:01 +00:00
if (DWC3_VER_IS_WITHIN(DWC31, 190A, ANY) || DWC3_IP_IS(DWC32))
msleep(20);
else
udelay(1);
} while (--retries);
dev_warn(dwc->dev, "DWC3 controller soft reset failed.\n");
return -ETIMEDOUT;
done:
/*
* For DWC_usb31 controller 1.80a and prior, once DCTL.CSFRST bit
* is cleared, we must wait at least 50ms before accessing the PHY
* domain (synchronization delay).
*/
2020-04-12 02:20:01 +00:00
if (DWC3_VER_IS_WITHIN(DWC31, ANY, 180A))
msleep(50);
return 0;
}
/*
* dwc3_frame_length_adjustment - Adjusts frame length if required
* @dwc3: Pointer to our controller context structure
*/
static void dwc3_frame_length_adjustment(struct dwc3 *dwc)
{
u32 reg;
u32 dft;
2020-04-12 02:20:01 +00:00
if (DWC3_VER_IS_PRIOR(DWC3, 250A))
return;
if (dwc->fladj == 0)
return;
reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
dft = reg & DWC3_GFLADJ_30MHZ_MASK;
if (dft != dwc->fladj) {
reg &= ~DWC3_GFLADJ_30MHZ_MASK;
reg |= DWC3_GFLADJ_30MHZ_SDBND_SEL | dwc->fladj;
dwc3_writel(dwc->regs, DWC3_GFLADJ, reg);
}
}
/**
* dwc3_ref_clk_period - Reference clock period configuration
* Default reference clock period depends on hardware
* configuration. For systems with reference clock that differs
* from the default, this will set clock period in DWC3_GUCTL
* register.
* @dwc: Pointer to our controller context structure
*/
static void dwc3_ref_clk_period(struct dwc3 *dwc)
{
unsigned long period;
unsigned long fladj;
unsigned long decr;
unsigned long rate;
u32 reg;
if (dwc->ref_clk) {
rate = clk_get_rate(dwc->ref_clk);
if (!rate)
return;
period = NSEC_PER_SEC / rate;
} else if (dwc->ref_clk_per) {
period = dwc->ref_clk_per;
rate = NSEC_PER_SEC / period;
} else {
return;
}
reg = dwc3_readl(dwc->regs, DWC3_GUCTL);
reg &= ~DWC3_GUCTL_REFCLKPER_MASK;
reg |= FIELD_PREP(DWC3_GUCTL_REFCLKPER_MASK, period);
dwc3_writel(dwc->regs, DWC3_GUCTL, reg);
if (DWC3_VER_IS_PRIOR(DWC3, 250A))
return;
/*
* The calculation below is
*
* 125000 * (NSEC_PER_SEC / (rate * period) - 1)
*
* but rearranged for fixed-point arithmetic. The division must be
* 64-bit because 125000 * NSEC_PER_SEC doesn't fit in 32 bits (and
* neither does rate * period).
*
* Note that rate * period ~= NSEC_PER_SECOND, minus the number of
* nanoseconds of error caused by the truncation which happened during
* the division when calculating rate or period (whichever one was
* derived from the other). We first calculate the relative error, then
* scale it to units of 8 ppm.
*/
fladj = div64_u64(125000ULL * NSEC_PER_SEC, (u64)rate * period);
fladj -= 125000;
/*
* The documented 240MHz constant is scaled by 2 to get PLS1 as well.
*/
decr = 480000000 / rate;
reg = dwc3_readl(dwc->regs, DWC3_GFLADJ);
reg &= ~DWC3_GFLADJ_REFCLK_FLADJ_MASK
& ~DWC3_GFLADJ_240MHZDECR
& ~DWC3_GFLADJ_240MHZDECR_PLS1;
reg |= FIELD_PREP(DWC3_GFLADJ_REFCLK_FLADJ_MASK, fladj)
| FIELD_PREP(DWC3_GFLADJ_240MHZDECR, decr >> 1)
| FIELD_PREP(DWC3_GFLADJ_240MHZDECR_PLS1, decr & 1);
if (dwc->gfladj_refclk_lpm_sel)
reg |= DWC3_GFLADJ_REFCLK_LPM_SEL;
dwc3_writel(dwc->regs, DWC3_GFLADJ, reg);
}
/**
* dwc3_free_one_event_buffer - Frees one event buffer
* @dwc: Pointer to our controller context structure
* @evt: Pointer to event buffer to be freed
*/
static void dwc3_free_one_event_buffer(struct dwc3 *dwc,
struct dwc3_event_buffer *evt)
{
dma_free_coherent(dwc->sysdev, evt->length, evt->buf, evt->dma);
}
/**
* dwc3_alloc_one_event_buffer - Allocates one event buffer structure
* @dwc: Pointer to our controller context structure
* @length: size of the event buffer
*
* Returns a pointer to the allocated event buffer structure on success
* otherwise ERR_PTR(errno).
*/
static struct dwc3_event_buffer *dwc3_alloc_one_event_buffer(struct dwc3 *dwc,
unsigned int length)
{
struct dwc3_event_buffer *evt;
evt = devm_kzalloc(dwc->dev, sizeof(*evt), GFP_KERNEL);
if (!evt)
return ERR_PTR(-ENOMEM);
evt->dwc = dwc;
evt->length = length;
evt->cache = devm_kzalloc(dwc->dev, length, GFP_KERNEL);
if (!evt->cache)
return ERR_PTR(-ENOMEM);
evt->buf = dma_alloc_coherent(dwc->sysdev, length,
&evt->dma, GFP_KERNEL);
if (!evt->buf)
return ERR_PTR(-ENOMEM);
return evt;
}
/**
* dwc3_free_event_buffers - frees all allocated event buffers
* @dwc: Pointer to our controller context structure
*/
static void dwc3_free_event_buffers(struct dwc3 *dwc)
{
struct dwc3_event_buffer *evt;
evt = dwc->ev_buf;
if (evt)
dwc3_free_one_event_buffer(dwc, evt);
}
/**
* dwc3_alloc_event_buffers - Allocates @num event buffers of size @length
* @dwc: pointer to our controller context structure
* @length: size of event buffer
*
* Returns 0 on success otherwise negative errno. In the error case, dwc
* may contain some buffers allocated but not all which were requested.
*/
static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned int length)
{
struct dwc3_event_buffer *evt;
unsigned int hw_mode;
hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
if (hw_mode == DWC3_GHWPARAMS0_MODE_HOST) {
dwc->ev_buf = NULL;
return 0;
}
evt = dwc3_alloc_one_event_buffer(dwc, length);
if (IS_ERR(evt)) {
dev_err(dwc->dev, "can't allocate event buffer\n");
return PTR_ERR(evt);
}
dwc->ev_buf = evt;
return 0;
}
/**
* dwc3_event_buffers_setup - setup our allocated event buffers
* @dwc: pointer to our controller context structure
*
* Returns 0 on success otherwise negative errno.
*/
int dwc3_event_buffers_setup(struct dwc3 *dwc)
{
struct dwc3_event_buffer *evt;
u32 reg;
if (!dwc->ev_buf)
return 0;
evt = dwc->ev_buf;
evt->lpos = 0;
dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(0),
lower_32_bits(evt->dma));
dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(0),
upper_32_bits(evt->dma));
dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(0),
DWC3_GEVNTSIZ_SIZE(evt->length));
/* Clear any stale event */
reg = dwc3_readl(dwc->regs, DWC3_GEVNTCOUNT(0));
dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(0), reg);
return 0;
}
void dwc3_event_buffers_cleanup(struct dwc3 *dwc)
{
struct dwc3_event_buffer *evt;
u32 reg;
if (!dwc->ev_buf)
return;
/*
* Exynos platforms may not be able to access event buffer if the
* controller failed to halt on dwc3_core_exit().
*/
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
if (!(reg & DWC3_DSTS_DEVCTRLHLT))
return;
evt = dwc->ev_buf;
evt->lpos = 0;
dwc3_writel(dwc->regs, DWC3_GEVNTADRLO(0), 0);
dwc3_writel(dwc->regs, DWC3_GEVNTADRHI(0), 0);
dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(0), DWC3_GEVNTSIZ_INTMASK
| DWC3_GEVNTSIZ_SIZE(0));
/* Clear any stale event */
reg = dwc3_readl(dwc->regs, DWC3_GEVNTCOUNT(0));
dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(0), reg);
}
static void dwc3_core_num_eps(struct dwc3 *dwc)
{
struct dwc3_hwparams *parms = &dwc->hwparams;
dwc->num_eps = DWC3_NUM_EPS(parms);
}
static void dwc3_cache_hwparams(struct dwc3 *dwc)
{
struct dwc3_hwparams *parms = &dwc->hwparams;
parms->hwparams0 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS0);
parms->hwparams1 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS1);
parms->hwparams2 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS2);
parms->hwparams3 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS3);
parms->hwparams4 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS4);
parms->hwparams5 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS5);
parms->hwparams6 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS6);
parms->hwparams7 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS7);
parms->hwparams8 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS8);
if (DWC3_IP_IS(DWC32))
parms->hwparams9 = dwc3_readl(dwc->regs, DWC3_GHWPARAMS9);
}
static void dwc3_config_soc_bus(struct dwc3 *dwc)
{
if (dwc->gsbuscfg0_reqinfo != DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED) {
u32 reg;
reg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
reg &= ~DWC3_GSBUSCFG0_REQINFO(~0);
reg |= DWC3_GSBUSCFG0_REQINFO(dwc->gsbuscfg0_reqinfo);
dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, reg);
}
}
static int dwc3_core_ulpi_init(struct dwc3 *dwc)
{
int intf;
int ret = 0;
intf = DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3);
if (intf == DWC3_GHWPARAMS3_HSPHY_IFC_ULPI ||
(intf == DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI &&
dwc->hsphy_interface &&
!strncmp(dwc->hsphy_interface, "ulpi", 4)))
ret = dwc3_ulpi_init(dwc);
return ret;
}
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
static int dwc3_ss_phy_setup(struct dwc3 *dwc, int index)
{
u32 reg;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(index));
/*
* Make sure UX_EXIT_PX is cleared as that causes issues with some
* PHYs. Also, this bit is not supposed to be used in normal operation.
*/
reg &= ~DWC3_GUSB3PIPECTL_UX_EXIT_PX;
/*
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
* Above DWC_usb3.0 1.94a, it is recommended to set
* DWC3_GUSB3PIPECTL_SUSPHY to '0' during coreConsultant configuration.
* So default value will be '0' when the core is reset. Application
* needs to set it to '1' after the core initialization is completed.
*
* Similarly for DRD controllers, GUSB3PIPECTL.SUSPENDENABLE must be
* cleared after power-on reset, and it can be set after core
* initialization.
*/
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
if (dwc->u2ss_inp3_quirk)
reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK;
if (dwc->dis_rxdet_inp3_quirk)
reg |= DWC3_GUSB3PIPECTL_DISRXDETINP3;
if (dwc->req_p1p2p3_quirk)
reg |= DWC3_GUSB3PIPECTL_REQP1P2P3;
if (dwc->del_p1p2p3_quirk)
reg |= DWC3_GUSB3PIPECTL_DEP1P2P3_EN;
if (dwc->del_phy_power_chg_quirk)
reg |= DWC3_GUSB3PIPECTL_DEPOCHANGE;
if (dwc->lfps_filter_quirk)
reg |= DWC3_GUSB3PIPECTL_LFPSFILT;
if (dwc->rx_detect_poll_quirk)
reg |= DWC3_GUSB3PIPECTL_RX_DETOPOLL;
if (dwc->tx_de_emphasis_quirk)
reg |= DWC3_GUSB3PIPECTL_TX_DEEPH(dwc->tx_de_emphasis);
if (dwc->dis_del_phy_power_chg_quirk)
reg &= ~DWC3_GUSB3PIPECTL_DEPOCHANGE;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(index), reg);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
return 0;
}
static int dwc3_hs_phy_setup(struct dwc3 *dwc, int index)
{
u32 reg;
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(index));
/* Select the HS PHY interface */
switch (DWC3_GHWPARAMS3_HSPHY_IFC(dwc->hwparams.hwparams3)) {
case DWC3_GHWPARAMS3_HSPHY_IFC_UTMI_ULPI:
if (dwc->hsphy_interface &&
!strncmp(dwc->hsphy_interface, "utmi", 4)) {
reg &= ~DWC3_GUSB2PHYCFG_ULPI_UTMI;
break;
} else if (dwc->hsphy_interface &&
!strncmp(dwc->hsphy_interface, "ulpi", 4)) {
reg |= DWC3_GUSB2PHYCFG_ULPI_UTMI;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(index), reg);
} else {
/* Relying on default value. */
if (!(reg & DWC3_GUSB2PHYCFG_ULPI_UTMI))
break;
}
fallthrough;
case DWC3_GHWPARAMS3_HSPHY_IFC_ULPI:
default:
break;
}
switch (dwc->hsphy_mode) {
case USBPHY_INTERFACE_MODE_UTMI:
reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_8_BIT) |
DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_8_BIT);
break;
case USBPHY_INTERFACE_MODE_UTMIW:
reg &= ~(DWC3_GUSB2PHYCFG_PHYIF_MASK |
DWC3_GUSB2PHYCFG_USBTRDTIM_MASK);
reg |= DWC3_GUSB2PHYCFG_PHYIF(UTMI_PHYIF_16_BIT) |
DWC3_GUSB2PHYCFG_USBTRDTIM(USBTRDTIM_UTMI_16_BIT);
break;
default:
break;
}
/*
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
* Above DWC_usb3.0 1.94a, it is recommended to set
* DWC3_GUSB2PHYCFG_SUSPHY to '0' during coreConsultant configuration.
* So default value will be '0' when the core is reset. Application
* needs to set it to '1' after the core initialization is completed.
*
* Similarly for DRD controllers, GUSB2PHYCFG.SUSPHY must be cleared
* after power-on reset, and it can be set after core initialization.
*/
usb: dwc3: core: Prevent phy suspend during init JIRA: https://issues.redhat.com/browse/RHEL-37673 commit 6d735722063a945de56472bdc6bfcb170fd43b86 Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Wed, 17 Apr 2024 23:14:36 +0000 GUSB3PIPECTL.SUSPENDENABLE and GUSB2PHYCFG.SUSPHY should be cleared during initialization. Suspend during initialization can result in undefined behavior due to clock synchronization failure, which often seen as core soft reset timeout. The programming guide recommended these bits to be cleared during initialization for DWC_usb3.0 version 1.94 and above (along with DWC_usb31 and DWC_usb32). The current check in the driver does not account if it's set by default setting from coreConsultant. This is especially the case for DRD when switching mode to ensure the phy clocks are available to change mode. Depending on the platforms/design, some may be affected more than others. This is noted in the DWC_usb3x programming guide under the above registers. Let's just disable them during driver load and mode switching. Restore them when the controller initialization completes. Note that some platforms workaround this issue by disabling phy suspend through "snps,dis_u3_susphy_quirk" and "snps,dis_u2_susphy_quirk" when they should not need to. Cc: stable@vger.kernel.org Fixes: 9ba3aca8fe82 ("usb: dwc3: Disable phy suspend after power-on reset") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/20da4e5a0c4678c9587d3da23f83bdd6d77353e9.1713394973.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:09 +00:00
reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
if (dwc->dis_enblslpm_quirk)
reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
else
reg |= DWC3_GUSB2PHYCFG_ENBLSLPM;
if (dwc->dis_u2_freeclk_exists_quirk || dwc->gfladj_refclk_lpm_sel)
reg &= ~DWC3_GUSB2PHYCFG_U2_FREECLK_EXISTS;
/*
* Some ULPI USB PHY does not support internal VBUS supply, to drive
* the CPEN pin requires the configuration of the ULPI DRVVBUSEXTERNAL
* bit of OTG_CTRL register. Controller configures the USB2 PHY
* ULPIEXTVBUSDRV bit[17] of the GUSB2PHYCFG register to drive vBus
* with an external supply.
*/
if (dwc->ulpi_ext_vbus_drv)
reg |= DWC3_GUSB2PHYCFG_ULPIEXTVBUSDRV;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(index), reg);
return 0;
}
/**
* dwc3_phy_setup - Configure USB PHY Interface of DWC3 Core
* @dwc: Pointer to our controller context structure
*
* Returns 0 on success. The USB PHY interfaces are configured but not
* initialized. The PHY interfaces and the PHYs get initialized together with
* the core in dwc3_core_init.
*/
static int dwc3_phy_setup(struct dwc3 *dwc)
{
int i;
int ret;
for (i = 0; i < dwc->num_usb3_ports; i++) {
ret = dwc3_ss_phy_setup(dwc, i);
if (ret)
return ret;
}
for (i = 0; i < dwc->num_usb2_ports; i++) {
ret = dwc3_hs_phy_setup(dwc, i);
if (ret)
return ret;
}
return 0;
}
static int dwc3_phy_init(struct dwc3 *dwc)
{
int ret;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
int j;
usb_phy_init(dwc->usb2_phy);
usb_phy_init(dwc->usb3_phy);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++) {
ret = phy_init(dwc->usb2_generic_phy[i]);
if (ret < 0)
goto err_exit_usb2_phy;
}
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (j = 0; j < dwc->num_usb3_ports; j++) {
ret = phy_init(dwc->usb3_generic_phy[j]);
if (ret < 0)
goto err_exit_usb3_phy;
}
return 0;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
err_exit_usb3_phy:
while (--j >= 0)
phy_exit(dwc->usb3_generic_phy[j]);
err_exit_usb2_phy:
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
while (--i >= 0)
phy_exit(dwc->usb2_generic_phy[i]);
usb_phy_shutdown(dwc->usb3_phy);
usb_phy_shutdown(dwc->usb2_phy);
return ret;
}
static void dwc3_phy_exit(struct dwc3 *dwc)
{
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
for (i = 0; i < dwc->num_usb3_ports; i++)
phy_exit(dwc->usb3_generic_phy[i]);
for (i = 0; i < dwc->num_usb2_ports; i++)
phy_exit(dwc->usb2_generic_phy[i]);
usb_phy_shutdown(dwc->usb3_phy);
usb_phy_shutdown(dwc->usb2_phy);
}
static int dwc3_phy_power_on(struct dwc3 *dwc)
{
int ret;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
int j;
usb_phy_set_suspend(dwc->usb2_phy, 0);
usb_phy_set_suspend(dwc->usb3_phy, 0);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++) {
ret = phy_power_on(dwc->usb2_generic_phy[i]);
if (ret < 0)
goto err_power_off_usb2_phy;
}
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (j = 0; j < dwc->num_usb3_ports; j++) {
ret = phy_power_on(dwc->usb3_generic_phy[j]);
if (ret < 0)
goto err_power_off_usb3_phy;
}
return 0;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
err_power_off_usb3_phy:
while (--j >= 0)
phy_power_off(dwc->usb3_generic_phy[j]);
err_power_off_usb2_phy:
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
while (--i >= 0)
phy_power_off(dwc->usb2_generic_phy[i]);
usb_phy_set_suspend(dwc->usb3_phy, 1);
usb_phy_set_suspend(dwc->usb2_phy, 1);
return ret;
}
static void dwc3_phy_power_off(struct dwc3 *dwc)
{
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
for (i = 0; i < dwc->num_usb3_ports; i++)
phy_power_off(dwc->usb3_generic_phy[i]);
for (i = 0; i < dwc->num_usb2_ports; i++)
phy_power_off(dwc->usb2_generic_phy[i]);
usb_phy_set_suspend(dwc->usb3_phy, 1);
usb_phy_set_suspend(dwc->usb2_phy, 1);
}
static int dwc3_clk_enable(struct dwc3 *dwc)
{
int ret;
ret = clk_prepare_enable(dwc->bus_clk);
if (ret)
return ret;
ret = clk_prepare_enable(dwc->ref_clk);
if (ret)
goto disable_bus_clk;
ret = clk_prepare_enable(dwc->susp_clk);
if (ret)
goto disable_ref_clk;
ret = clk_prepare_enable(dwc->utmi_clk);
if (ret)
goto disable_susp_clk;
ret = clk_prepare_enable(dwc->pipe_clk);
if (ret)
goto disable_utmi_clk;
return 0;
disable_utmi_clk:
clk_disable_unprepare(dwc->utmi_clk);
disable_susp_clk:
clk_disable_unprepare(dwc->susp_clk);
disable_ref_clk:
clk_disable_unprepare(dwc->ref_clk);
disable_bus_clk:
clk_disable_unprepare(dwc->bus_clk);
return ret;
}
static void dwc3_clk_disable(struct dwc3 *dwc)
{
clk_disable_unprepare(dwc->pipe_clk);
clk_disable_unprepare(dwc->utmi_clk);
clk_disable_unprepare(dwc->susp_clk);
clk_disable_unprepare(dwc->ref_clk);
clk_disable_unprepare(dwc->bus_clk);
}
static void dwc3_core_exit(struct dwc3 *dwc)
{
dwc3_event_buffers_cleanup(dwc);
dwc3_phy_power_off(dwc);
dwc3_phy_exit(dwc);
dwc3_clk_disable(dwc);
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
reset_control_assert(dwc->reset);
}
static bool dwc3_core_is_valid(struct dwc3 *dwc)
{
u32 reg;
reg = dwc3_readl(dwc->regs, DWC3_GSNPSID);
2020-04-12 02:20:01 +00:00
dwc->ip = DWC3_GSNPS_ID(reg);
/* This should read as U3 followed by revision number */
2020-04-12 02:20:01 +00:00
if (DWC3_IP_IS(DWC3)) {
dwc->revision = reg;
2020-04-12 02:20:01 +00:00
} else if (DWC3_IP_IS(DWC31) || DWC3_IP_IS(DWC32)) {
dwc->revision = dwc3_readl(dwc->regs, DWC3_VER_NUMBER);
dwc->version_type = dwc3_readl(dwc->regs, DWC3_VER_TYPE);
} else {
return false;
}
return true;
}
static void dwc3_core_setup_global_control(struct dwc3 *dwc)
{
unsigned int power_opt;
unsigned int hw_mode;
u32 reg;
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
power_opt = DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1);
switch (power_opt) {
case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
/**
* WORKAROUND: DWC3 revisions between 2.10a and 2.50a have an
* issue which would cause xHCI compliance tests to fail.
*
* Because of that we cannot enable clock gating on such
* configurations.
*
* Refers to:
*
* STAR#9000588375: Clock Gating, SOF Issues when ref_clk-Based
* SOF/ITP Mode Used
*/
if ((dwc->dr_mode == USB_DR_MODE_HOST ||
dwc->dr_mode == USB_DR_MODE_OTG) &&
2020-04-12 02:20:01 +00:00
DWC3_VER_IS_WITHIN(DWC3, 210A, 250A))
reg |= DWC3_GCTL_DSBLCLKGTNG | DWC3_GCTL_SOFITPSYNC;
else
reg &= ~DWC3_GCTL_DSBLCLKGTNG;
break;
case DWC3_GHWPARAMS1_EN_PWROPT_HIB:
/*
* REVISIT Enabling this bit so that host-mode hibernation
* will work. Device-mode hibernation is not yet implemented.
*/
reg |= DWC3_GCTL_GBLHIBERNATIONEN;
break;
default:
/* nothing */
break;
}
/*
* This is a workaround for STAR#4846132, which only affects
* DWC_usb31 version2.00a operating in host mode.
*
* There is a problem in DWC_usb31 version 2.00a operating
* in host mode that would cause a CSR read timeout When CSR
* read coincides with RAM Clock Gating Entry. By disable
* Clock Gating, sacrificing power consumption for normal
* operation.
*/
if (power_opt != DWC3_GHWPARAMS1_EN_PWROPT_NO &&
hw_mode != DWC3_GHWPARAMS0_MODE_GADGET && DWC3_VER_IS(DWC31, 200A))
reg |= DWC3_GCTL_DSBLCLKGTNG;
/* check if current dwc3 is on simulation board */
if (dwc->hwparams.hwparams6 & DWC3_GHWPARAMS6_EN_FPGA) {
dev_info(dwc->dev, "Running with FPGA optimizations\n");
dwc->is_fpga = true;
}
WARN_ONCE(dwc->disable_scramble_quirk && !dwc->is_fpga,
"disable_scramble cannot be used on non-FPGA builds\n");
if (dwc->disable_scramble_quirk && dwc->is_fpga)
reg |= DWC3_GCTL_DISSCRAMBLE;
else
reg &= ~DWC3_GCTL_DISSCRAMBLE;
if (dwc->u2exit_lfps_quirk)
reg |= DWC3_GCTL_U2EXIT_LFPS;
/*
* WORKAROUND: DWC3 revisions <1.90a have a bug
* where the device can fail to connect at SuperSpeed
* and falls back to high-speed mode which causes
* the device to enter a Connect/Disconnect loop
*/
2020-04-12 02:20:01 +00:00
if (DWC3_VER_IS_PRIOR(DWC3, 190A))
reg |= DWC3_GCTL_U2RSTECN;
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
}
static int dwc3_core_get_phy(struct dwc3 *dwc);
static int dwc3_core_ulpi_init(struct dwc3 *dwc);
/* set global incr burst type configuration registers */
static void dwc3_set_incr_burst_type(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
/* incrx_mode : for INCR burst type. */
bool incrx_mode;
/* incrx_size : for size of INCRX burst. */
u32 incrx_size;
u32 *vals;
u32 cfg;
int ntype;
int ret;
int i;
cfg = dwc3_readl(dwc->regs, DWC3_GSBUSCFG0);
/*
* Handle property "snps,incr-burst-type-adjustment".
* Get the number of value from this property:
* result <= 0, means this property is not supported.
* result = 1, means INCRx burst mode supported.
* result > 1, means undefined length burst mode supported.
*/
ntype = device_property_count_u32(dev, "snps,incr-burst-type-adjustment");
if (ntype <= 0)
return;
vals = kcalloc(ntype, sizeof(u32), GFP_KERNEL);
if (!vals)
return;
/* Get INCR burst type, and parse it */
ret = device_property_read_u32_array(dev,
"snps,incr-burst-type-adjustment", vals, ntype);
if (ret) {
kfree(vals);
dev_err(dev, "Error to get property\n");
return;
}
incrx_size = *vals;
if (ntype > 1) {
/* INCRX (undefined length) burst mode */
incrx_mode = INCRX_UNDEF_LENGTH_BURST_MODE;
for (i = 1; i < ntype; i++) {
if (vals[i] > incrx_size)
incrx_size = vals[i];
}
} else {
/* INCRX burst mode */
incrx_mode = INCRX_BURST_MODE;
}
kfree(vals);
/* Enable Undefined Length INCR Burst and Enable INCRx Burst */
cfg &= ~DWC3_GSBUSCFG0_INCRBRST_MASK;
if (incrx_mode)
cfg |= DWC3_GSBUSCFG0_INCRBRSTENA;
switch (incrx_size) {
case 256:
cfg |= DWC3_GSBUSCFG0_INCR256BRSTENA;
break;
case 128:
cfg |= DWC3_GSBUSCFG0_INCR128BRSTENA;
break;
case 64:
cfg |= DWC3_GSBUSCFG0_INCR64BRSTENA;
break;
case 32:
cfg |= DWC3_GSBUSCFG0_INCR32BRSTENA;
break;
case 16:
cfg |= DWC3_GSBUSCFG0_INCR16BRSTENA;
break;
case 8:
cfg |= DWC3_GSBUSCFG0_INCR8BRSTENA;
break;
case 4:
cfg |= DWC3_GSBUSCFG0_INCR4BRSTENA;
break;
case 1:
break;
default:
dev_err(dev, "Invalid property\n");
break;
}
dwc3_writel(dwc->regs, DWC3_GSBUSCFG0, cfg);
}
static void dwc3_set_power_down_clk_scale(struct dwc3 *dwc)
{
u32 scale;
u32 reg;
if (!dwc->susp_clk)
return;
/*
* The power down scale field specifies how many suspend_clk
* periods fit into a 16KHz clock period. When performing
* the division, round up the remainder.
*
* The power down scale value is calculated using the fastest
* frequency of the suspend_clk. If it isn't fixed (but within
* the accuracy requirement), the driver may not know the max
* rate of the suspend_clk, so only update the power down scale
* if the default is less than the calculated value from
* clk_get_rate() or if the default is questionably high
* (3x or more) to be within the requirement.
*/
scale = DIV_ROUND_UP(clk_get_rate(dwc->susp_clk), 16000);
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
if ((reg & DWC3_GCTL_PWRDNSCALE_MASK) < DWC3_GCTL_PWRDNSCALE(scale) ||
(reg & DWC3_GCTL_PWRDNSCALE_MASK) > DWC3_GCTL_PWRDNSCALE(scale*3)) {
reg &= ~(DWC3_GCTL_PWRDNSCALE_MASK);
reg |= DWC3_GCTL_PWRDNSCALE(scale);
dwc3_writel(dwc->regs, DWC3_GCTL, reg);
}
}
static void dwc3_config_threshold(struct dwc3 *dwc)
{
u32 reg;
u8 rx_thr_num;
u8 rx_maxburst;
u8 tx_thr_num;
u8 tx_maxburst;
/*
* Must config both number of packets and max burst settings to enable
* RX and/or TX threshold.
*/
if (!DWC3_IP_IS(DWC3) && dwc->dr_mode == USB_DR_MODE_HOST) {
rx_thr_num = dwc->rx_thr_num_pkt_prd;
rx_maxburst = dwc->rx_max_burst_prd;
tx_thr_num = dwc->tx_thr_num_pkt_prd;
tx_maxburst = dwc->tx_max_burst_prd;
if (rx_thr_num && rx_maxburst) {
reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG);
reg |= DWC31_RXTHRNUMPKTSEL_PRD;
reg &= ~DWC31_RXTHRNUMPKT_PRD(~0);
reg |= DWC31_RXTHRNUMPKT_PRD(rx_thr_num);
reg &= ~DWC31_MAXRXBURSTSIZE_PRD(~0);
reg |= DWC31_MAXRXBURSTSIZE_PRD(rx_maxburst);
dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg);
}
if (tx_thr_num && tx_maxburst) {
reg = dwc3_readl(dwc->regs, DWC3_GTXTHRCFG);
reg |= DWC31_TXTHRNUMPKTSEL_PRD;
reg &= ~DWC31_TXTHRNUMPKT_PRD(~0);
reg |= DWC31_TXTHRNUMPKT_PRD(tx_thr_num);
reg &= ~DWC31_MAXTXBURSTSIZE_PRD(~0);
reg |= DWC31_MAXTXBURSTSIZE_PRD(tx_maxburst);
dwc3_writel(dwc->regs, DWC3_GTXTHRCFG, reg);
}
}
rx_thr_num = dwc->rx_thr_num_pkt;
rx_maxburst = dwc->rx_max_burst;
tx_thr_num = dwc->tx_thr_num_pkt;
tx_maxburst = dwc->tx_max_burst;
if (DWC3_IP_IS(DWC3)) {
if (rx_thr_num && rx_maxburst) {
reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG);
reg |= DWC3_GRXTHRCFG_PKTCNTSEL;
reg &= ~DWC3_GRXTHRCFG_RXPKTCNT(~0);
reg |= DWC3_GRXTHRCFG_RXPKTCNT(rx_thr_num);
reg &= ~DWC3_GRXTHRCFG_MAXRXBURSTSIZE(~0);
reg |= DWC3_GRXTHRCFG_MAXRXBURSTSIZE(rx_maxburst);
dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg);
}
if (tx_thr_num && tx_maxburst) {
reg = dwc3_readl(dwc->regs, DWC3_GTXTHRCFG);
reg |= DWC3_GTXTHRCFG_PKTCNTSEL;
reg &= ~DWC3_GTXTHRCFG_TXPKTCNT(~0);
reg |= DWC3_GTXTHRCFG_TXPKTCNT(tx_thr_num);
reg &= ~DWC3_GTXTHRCFG_MAXTXBURSTSIZE(~0);
reg |= DWC3_GTXTHRCFG_MAXTXBURSTSIZE(tx_maxburst);
dwc3_writel(dwc->regs, DWC3_GTXTHRCFG, reg);
}
} else {
if (rx_thr_num && rx_maxburst) {
reg = dwc3_readl(dwc->regs, DWC3_GRXTHRCFG);
reg |= DWC31_GRXTHRCFG_PKTCNTSEL;
reg &= ~DWC31_GRXTHRCFG_RXPKTCNT(~0);
reg |= DWC31_GRXTHRCFG_RXPKTCNT(rx_thr_num);
reg &= ~DWC31_GRXTHRCFG_MAXRXBURSTSIZE(~0);
reg |= DWC31_GRXTHRCFG_MAXRXBURSTSIZE(rx_maxburst);
dwc3_writel(dwc->regs, DWC3_GRXTHRCFG, reg);
}
if (tx_thr_num && tx_maxburst) {
reg = dwc3_readl(dwc->regs, DWC3_GTXTHRCFG);
reg |= DWC31_GTXTHRCFG_PKTCNTSEL;
reg &= ~DWC31_GTXTHRCFG_TXPKTCNT(~0);
reg |= DWC31_GTXTHRCFG_TXPKTCNT(tx_thr_num);
reg &= ~DWC31_GTXTHRCFG_MAXTXBURSTSIZE(~0);
reg |= DWC31_GTXTHRCFG_MAXTXBURSTSIZE(tx_maxburst);
dwc3_writel(dwc->regs, DWC3_GTXTHRCFG, reg);
}
}
}
/**
* dwc3_core_init - Low-level initialization of DWC3 Core
* @dwc: Pointer to our controller context structure
*
* Returns 0 on success otherwise negative errno.
*/
static int dwc3_core_init(struct dwc3 *dwc)
{
unsigned int hw_mode;
u32 reg;
int ret;
hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
/*
* Write Linux Version Code to our GUID register so it's easy to figure
* out which kernel version a bug was found.
*/
dwc3_writel(dwc->regs, DWC3_GUID, LINUX_VERSION_CODE);
ret = dwc3_phy_setup(dwc);
if (ret)
return ret;
if (!dwc->ulpi_ready) {
ret = dwc3_core_ulpi_init(dwc);
usb: dwc3: core: defer probe on ulpi_read_id timeout Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63130462c919ece0ad0d9bb5a1f795ef8d79687e commit 63130462c919ece0ad0d9bb5a1f795ef8d79687e Author: Ferry Toth <ftoth@exalondelft.nl> Date: Mon, 5 Dec 2022 21:15:27 +0100 Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present"), Dual Role support on Intel Merrifield platform broke due to rearranging the call to dwc3_get_extcon(). It appears to be caused by ulpi_read_id() masking the timeout on the first test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset() followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER. On deferred probe ulpi_read_id() finally succeeded. Due to above mentioned rearranging -EPROBE_DEFER is not returned and probe completes without phy. On Intel Merrifield the timeout on the first test write issue is reproducible but it is difficult to find the root cause. Using a mainline kernel and rootfs with buildroot ulpi_read_id() succeeds. As soon as adding ftrace / bootconfig to find out why, ulpi_read_id() fails and we can't analyze the flow. Using another rootfs ulpi_read_id() fails even without adding ftrace. We suspect the issue is some kind of timing / race, but merely retrying ulpi_read_id() does not resolve the issue. As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we need to handle the error by calling dwc3_core_soft_reset() and request -EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> Link: https://lore.kernel.org/r/20221205201527.13525-3-ftoth@exalondelft.nl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:59 +00:00
if (ret) {
if (ret == -ETIMEDOUT) {
dwc3_core_soft_reset(dwc);
ret = -EPROBE_DEFER;
}
return ret;
usb: dwc3: core: defer probe on ulpi_read_id timeout Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2190250 Upstream Status: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=63130462c919ece0ad0d9bb5a1f795ef8d79687e commit 63130462c919ece0ad0d9bb5a1f795ef8d79687e Author: Ferry Toth <ftoth@exalondelft.nl> Date: Mon, 5 Dec 2022 21:15:27 +0100 Since commit 0f0101719138 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present"), Dual Role support on Intel Merrifield platform broke due to rearranging the call to dwc3_get_extcon(). It appears to be caused by ulpi_read_id() masking the timeout on the first test write. In the past dwc3 probe continued by calling dwc3_core_soft_reset() followed by dwc3_get_extcon() which happend to return -EPROBE_DEFER. On deferred probe ulpi_read_id() finally succeeded. Due to above mentioned rearranging -EPROBE_DEFER is not returned and probe completes without phy. On Intel Merrifield the timeout on the first test write issue is reproducible but it is difficult to find the root cause. Using a mainline kernel and rootfs with buildroot ulpi_read_id() succeeds. As soon as adding ftrace / bootconfig to find out why, ulpi_read_id() fails and we can't analyze the flow. Using another rootfs ulpi_read_id() fails even without adding ftrace. We suspect the issue is some kind of timing / race, but merely retrying ulpi_read_id() does not resolve the issue. As we now changed ulpi_read_id() to return -ETIMEDOUT in this case, we need to handle the error by calling dwc3_core_soft_reset() and request -EPROBE_DEFER. On deferred probe ulpi_read_id() is retried and succeeds. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Cc: stable@vger.kernel.org Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Signed-off-by: Ferry Toth <ftoth@exalondelft.nl> Link: https://lore.kernel.org/r/20221205201527.13525-3-ftoth@exalondelft.nl Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2023-05-05 15:03:59 +00:00
}
dwc->ulpi_ready = true;
}
if (!dwc->phys_ready) {
ret = dwc3_core_get_phy(dwc);
if (ret)
goto err_exit_ulpi;
dwc->phys_ready = true;
}
ret = dwc3_phy_init(dwc);
if (ret)
goto err_exit_ulpi;
ret = dwc3_core_soft_reset(dwc);
if (ret)
goto err_exit_phy;
dwc3_core_setup_global_control(dwc);
dwc3_core_num_eps(dwc);
/* Set power down scale of suspend_clk */
dwc3_set_power_down_clk_scale(dwc);
/* Adjust Frame Length */
dwc3_frame_length_adjustment(dwc);
/* Adjust Reference Clock Period */
dwc3_ref_clk_period(dwc);
dwc3_set_incr_burst_type(dwc);
dwc3_config_soc_bus(dwc);
ret = dwc3_phy_power_on(dwc);
if (ret)
goto err_exit_phy;
ret = dwc3_event_buffers_setup(dwc);
if (ret) {
dev_err(dwc->dev, "failed to setup event buffers\n");
goto err_power_off_phy;
}
/*
* ENDXFER polling is available on version 3.10a and later of
* the DWC_usb3 controller. It is NOT available in the
* DWC_usb31 controller.
*/
2020-04-12 02:20:01 +00:00
if (DWC3_VER_IS_WITHIN(DWC3, 310A, ANY)) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL2);
reg |= DWC3_GUCTL2_RST_ACTBITLATER;
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
/*
* STAR 9001285599: This issue affects DWC_usb3 version 3.20a
* only. If the PM TIMER ECM is enabled through GUCTL2[19], the
* link compliance test (TD7.21) may fail. If the ECN is not
* enabled (GUCTL2[19] = 0), the controller will use the old timer
* value (5us), which is still acceptable for the link compliance
* test. Therefore, do not enable PM TIMER ECM in 3.20a by
* setting GUCTL2[19] by default; instead, use GUCTL2[19] = 0.
*/
if (DWC3_VER_IS(DWC3, 320A)) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL2);
reg &= ~DWC3_GUCTL2_LC_TIMER;
dwc3_writel(dwc->regs, DWC3_GUCTL2, reg);
}
/*
* When configured in HOST mode, after issuing U3/L2 exit controller
* fails to send proper CRC checksum in CRC5 field. Because of this
* behaviour Transaction Error is generated, resulting in reset and
* re-enumeration of usb device attached. All the termsel, xcvrsel,
* opmode becomes 0 during end of resume. Enabling bit 10 of GUCTL1
* will correct this problem. This option is to support certain
* legacy ULPI PHYs.
*/
if (dwc->resume_hs_terminations) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
reg |= DWC3_GUCTL1_RESUME_OPMODE_HS_HOST;
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}
2020-04-12 02:20:01 +00:00
if (!DWC3_VER_IS_PRIOR(DWC3, 250A)) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL1);
/*
* Enable hardware control of sending remote wakeup
* in HS when the device is in the L1 state.
*/
2020-04-12 02:20:01 +00:00
if (!DWC3_VER_IS_PRIOR(DWC3, 290A))
reg |= DWC3_GUCTL1_DEV_L1_EXIT_BY_HW;
usb: dwc3: Decouple USB 2.0 L1 & L2 events Bugzilla: http://bugzilla.redhat.com/2061784 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=45014530 Tested: HP ZBook 15 G5/80D5 Laptop TGL-U(QS) Laptop commit 843714bb37d9a3780160d7b4a4a72b8077a77589 Author: Jack Pham <jackp@codeaurora.org> Date: Thu Aug 12 01:26:35 2021 -0700 usb: dwc3: Decouple USB 2.0 L1 & L2 events On DWC_usb3 revisions 3.00a and newer (including DWC_usb31 and DWC_usb32) the GUCTL1 register gained the DEV_DECOUPLE_L1L2_EVT field (bit 31) which when enabled allows the controller in device mode to treat USB 2.0 L1 LPM & L2 events separately. After commit d1d90dd27254 ("usb: dwc3: gadget: Enable suspend events") the controller will now receive events (and therefore interrupts) for every state change when entering/exiting either L1 or L2 states. Since L1 is handled entirely by the hardware and requires no software intervention, there is no need to even enable these events and unnecessarily notify the gadget driver. Enable the aforementioned bit to help reduce the overall interrupt count for these L1 events that don't need to be handled while retaining the events for full L2 suspend/wakeup. Tested-by: Jun Li <jun.li@nxp.com> Tested-by: Amit Pundir <amit.pundir@linaro.org> # for RB5 (sm8250) Tested-by: John Stultz <john.stultz@linaro.org> # for HiKey960 & db845c Reviewed-by: Jun Li <jun.li@nxp.com> Acked-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Jack Pham <jackp@codeaurora.org> Link: https://lore.kernel.org/r/20210812082635.12924-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Torez Smith <torez@redhat.com>
2022-05-02 16:31:35 +00:00
/*
* Decouple USB 2.0 L1 & L2 events which will allow for
* gadget driver to only receive U3/L2 suspend & wakeup
* events and prevent the more frequent L1 LPM transitions
* from interrupting the driver.
*/
if (!DWC3_VER_IS_PRIOR(DWC3, 300A))
reg |= DWC3_GUCTL1_DEV_DECOUPLE_L1L2_EVT;
if (dwc->dis_tx_ipgap_linecheck_quirk)
reg |= DWC3_GUCTL1_TX_IPGAP_LINECHECK_DIS;
if (dwc->parkmode_disable_ss_quirk)
reg |= DWC3_GUCTL1_PARKMODE_DISABLE_SS;
if (dwc->parkmode_disable_hs_quirk)
reg |= DWC3_GUCTL1_PARKMODE_DISABLE_HS;
if (DWC3_VER_IS_WITHIN(DWC3, 290A, ANY)) {
if (dwc->maximum_speed == USB_SPEED_FULL ||
dwc->maximum_speed == USB_SPEED_HIGH)
reg |= DWC3_GUCTL1_DEV_FORCE_20_CLK_FOR_30_CLK;
else
reg &= ~DWC3_GUCTL1_DEV_FORCE_20_CLK_FOR_30_CLK;
}
dwc3_writel(dwc->regs, DWC3_GUCTL1, reg);
}
dwc3_config_threshold(dwc);
/*
* Modify this for all supported Super Speed ports when
* multiport support is added.
*/
if (hw_mode != DWC3_GHWPARAMS0_MODE_GADGET &&
(DWC3_IP_IS(DWC31)) &&
dwc->maximum_speed == USB_SPEED_SUPER) {
int i;
for (i = 0; i < dwc->num_usb3_ports; i++) {
reg = dwc3_readl(dwc->regs, DWC3_LLUCTL(i));
reg |= DWC3_LLUCTL_FORCE_GEN1;
dwc3_writel(dwc->regs, DWC3_LLUCTL(i), reg);
}
}
return 0;
err_power_off_phy:
dwc3_phy_power_off(dwc);
err_exit_phy:
dwc3_phy_exit(dwc);
err_exit_ulpi:
dwc3_ulpi_exit(dwc);
return ret;
}
static int dwc3_core_get_phy(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
struct device_node *node = dev->of_node;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
char phy_name[9];
int ret;
u8 i;
if (node) {
dwc->usb2_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 0);
dwc->usb3_phy = devm_usb_get_phy_by_phandle(dev, "usb-phy", 1);
} else {
dwc->usb2_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
dwc->usb3_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB3);
}
if (IS_ERR(dwc->usb2_phy)) {
ret = PTR_ERR(dwc->usb2_phy);
if (ret == -ENXIO || ret == -ENODEV)
dwc->usb2_phy = NULL;
else
return dev_err_probe(dev, ret, "no usb2 phy configured\n");
}
if (IS_ERR(dwc->usb3_phy)) {
ret = PTR_ERR(dwc->usb3_phy);
if (ret == -ENXIO || ret == -ENODEV)
dwc->usb3_phy = NULL;
else
return dev_err_probe(dev, ret, "no usb3 phy configured\n");
}
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++) {
if (dwc->num_usb2_ports == 1)
snprintf(phy_name, sizeof(phy_name), "usb2-phy");
else
snprintf(phy_name, sizeof(phy_name), "usb2-%u", i);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
dwc->usb2_generic_phy[i] = devm_phy_get(dev, phy_name);
if (IS_ERR(dwc->usb2_generic_phy[i])) {
ret = PTR_ERR(dwc->usb2_generic_phy[i]);
if (ret == -ENOSYS || ret == -ENODEV)
dwc->usb2_generic_phy[i] = NULL;
else
return dev_err_probe(dev, ret, "failed to lookup phy %s\n",
phy_name);
}
}
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb3_ports; i++) {
if (dwc->num_usb3_ports == 1)
snprintf(phy_name, sizeof(phy_name), "usb3-phy");
else
snprintf(phy_name, sizeof(phy_name), "usb3-%u", i);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
dwc->usb3_generic_phy[i] = devm_phy_get(dev, phy_name);
if (IS_ERR(dwc->usb3_generic_phy[i])) {
ret = PTR_ERR(dwc->usb3_generic_phy[i]);
if (ret == -ENOSYS || ret == -ENODEV)
dwc->usb3_generic_phy[i] = NULL;
else
return dev_err_probe(dev, ret, "failed to lookup phy %s\n",
phy_name);
}
}
return 0;
}
static int dwc3_core_init_mode(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
int ret;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
if (dwc->usb2_phy)
otg_set_vbus(dwc->usb2_phy->otg, false);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
phy_set_mode(dwc->usb2_generic_phy[0], PHY_MODE_USB_DEVICE);
phy_set_mode(dwc->usb3_generic_phy[0], PHY_MODE_USB_DEVICE);
ret = dwc3_gadget_init(dwc);
if (ret)
return dev_err_probe(dev, ret, "failed to initialize gadget\n");
break;
case USB_DR_MODE_HOST:
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
if (dwc->usb2_phy)
otg_set_vbus(dwc->usb2_phy->otg, true);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++)
phy_set_mode(dwc->usb2_generic_phy[i], PHY_MODE_USB_HOST);
for (i = 0; i < dwc->num_usb3_ports; i++)
phy_set_mode(dwc->usb3_generic_phy[i], PHY_MODE_USB_HOST);
ret = dwc3_host_init(dwc);
if (ret)
return dev_err_probe(dev, ret, "failed to initialize host\n");
break;
case USB_DR_MODE_OTG:
INIT_WORK(&dwc->drd_work, __dwc3_set_mode);
ret = dwc3_drd_init(dwc);
if (ret)
return dev_err_probe(dev, ret, "failed to initialize dual-role\n");
break;
default:
dev_err(dev, "Unsupported mode of operation %d\n", dwc->dr_mode);
return -EINVAL;
}
return 0;
}
static void dwc3_core_exit_mode(struct dwc3 *dwc)
{
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
dwc3_gadget_exit(dwc);
break;
case USB_DR_MODE_HOST:
dwc3_host_exit(dwc);
break;
case USB_DR_MODE_OTG:
dwc3_drd_exit(dwc);
break;
default:
/* do nothing */
break;
}
/* de-assert DRVVBUS for HOST and OTG mode */
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
}
static void dwc3_get_software_properties(struct dwc3 *dwc)
{
struct device *tmpdev;
u16 gsbuscfg0_reqinfo;
int ret;
dwc->gsbuscfg0_reqinfo = DWC3_GSBUSCFG0_REQINFO_UNSPECIFIED;
/*
* Iterate over all parent nodes for finding swnode properties
* and non-DT (non-ABI) properties.
*/
for (tmpdev = dwc->dev; tmpdev; tmpdev = tmpdev->parent) {
ret = device_property_read_u16(tmpdev,
"snps,gsbuscfg0-reqinfo",
&gsbuscfg0_reqinfo);
if (!ret)
dwc->gsbuscfg0_reqinfo = gsbuscfg0_reqinfo;
}
}
static void dwc3_get_properties(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
u8 lpm_nyet_threshold;
u8 tx_de_emphasis;
u8 hird_threshold;
u8 rx_thr_num_pkt = 0;
u8 rx_max_burst = 0;
u8 tx_thr_num_pkt = 0;
u8 tx_max_burst = 0;
u8 rx_thr_num_pkt_prd = 0;
u8 rx_max_burst_prd = 0;
u8 tx_thr_num_pkt_prd = 0;
u8 tx_max_burst_prd = 0;
usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Bugzilla: http://bugzilla.redhat.com/2061784 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=45014530 Tested: HP ZBook 15 G5/80D5 Laptop TGL-U(QS) Laptop Conflicts: In the upstream kernel, this commit was applied before commit 40edb52298df (usb: dwc3: avoid NULL access of usb_gadget_driver). For some reason 9f607a309fbe (usb: dwc3: Resize TX FIFOs to meet EP burstin) was ommited when our centos kernel was pulled forward to v5.14. The conflicts identified with this patch are due to this patch being applied "after" 40edb52298df when it should have been applied "before". Not certain why our initial centos tree glanced over 9f607a309fbe. Adding it in now. commit 9f607a309fbe95fc1f77acce5af70766a7142537 Author: Wesley Cheng <wcheng@codeaurora.org> Date: Sat Jul 10 02:13:12 2021 -0700 usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Some devices have USB compositions which may require multiple endpoints that support EP bursting. HW defined TX FIFO sizes may not always be sufficient for these compositions. By utilizing flexible TX FIFO allocation, this allows for endpoints to request the required FIFO depth to achieve higher bandwidth. With some higher bMaxBurst configurations, using a larger TX FIFO size results in better TX throughput. By introducing the check_config() callback, the resizing logic can fetch the maximum number of endpoints used in the USB composition (can contain multiple configurations), which helps ensure that the resizing logic can fulfill the configuration(s), or return an error to the gadget layer otherwise during bind time. Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1625908395-5498-4-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Torez Smith <torez@redhat.com>
2022-05-02 16:31:17 +00:00
u8 tx_fifo_resize_max_num;
const char *usb_psy_name;
int ret;
/* default to highest possible threshold */
lpm_nyet_threshold = 0xf;
/* default to -3.5dB de-emphasis */
tx_de_emphasis = 1;
/*
* default to assert utmi_sleep_n and use maximum allowed HIRD
* threshold value of 0b1100
*/
hird_threshold = 12;
usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Bugzilla: http://bugzilla.redhat.com/2061784 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=45014530 Tested: HP ZBook 15 G5/80D5 Laptop TGL-U(QS) Laptop Conflicts: In the upstream kernel, this commit was applied before commit 40edb52298df (usb: dwc3: avoid NULL access of usb_gadget_driver). For some reason 9f607a309fbe (usb: dwc3: Resize TX FIFOs to meet EP burstin) was ommited when our centos kernel was pulled forward to v5.14. The conflicts identified with this patch are due to this patch being applied "after" 40edb52298df when it should have been applied "before". Not certain why our initial centos tree glanced over 9f607a309fbe. Adding it in now. commit 9f607a309fbe95fc1f77acce5af70766a7142537 Author: Wesley Cheng <wcheng@codeaurora.org> Date: Sat Jul 10 02:13:12 2021 -0700 usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Some devices have USB compositions which may require multiple endpoints that support EP bursting. HW defined TX FIFO sizes may not always be sufficient for these compositions. By utilizing flexible TX FIFO allocation, this allows for endpoints to request the required FIFO depth to achieve higher bandwidth. With some higher bMaxBurst configurations, using a larger TX FIFO size results in better TX throughput. By introducing the check_config() callback, the resizing logic can fetch the maximum number of endpoints used in the USB composition (can contain multiple configurations), which helps ensure that the resizing logic can fulfill the configuration(s), or return an error to the gadget layer otherwise during bind time. Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1625908395-5498-4-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Torez Smith <torez@redhat.com>
2022-05-02 16:31:17 +00:00
/*
* default to a TXFIFO size large enough to fit 6 max packets. This
* allows for systems with larger bus latencies to have some headroom
* for endpoints that have a large bMaxBurst value.
*/
tx_fifo_resize_max_num = 6;
dwc->maximum_speed = usb_get_maximum_speed(dev);
dwc->max_ssp_rate = usb_get_maximum_ssp_rate(dev);
dwc->dr_mode = usb_get_dr_mode(dev);
dwc->hsphy_mode = of_usb_get_phy_mode(dev->of_node);
dwc->sysdev_is_parent = device_property_read_bool(dev,
"linux,sysdev_is_parent");
if (dwc->sysdev_is_parent)
dwc->sysdev = dwc->dev->parent;
else
dwc->sysdev = dwc->dev;
usb: dwc3: Properly set system wakeup JIRA: https://issues.redhat.com/browse/RHEL-37673 commit f9aa41130ac69d13a53ce2a153ca79c70d43f39c Author: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Date: Fri, 8 Mar 2024 02:40:25 +0000 If the device is configured for system wakeup, then make sure that the xHCI driver knows about it and make sure to permit wakeup only at the appropriate time. For host mode, if the controller goes through the dwc3 code path, then a child xHCI platform device is created. Make sure the platform device also inherits the wakeup setting for xHCI to enable remote wakeup. For device mode, make sure to disable system wakeup if no gadget driver is bound. We may experience unwanted system wakeup due to the wakeup signal from the controller PMU detecting connection/disconnection when in low power (D3). E.g. In the case of Steam Deck, the PCI PME prevents the system staying in suspend. Cc: stable@vger.kernel.org Reported-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Closes: https://lore.kernel.org/linux-usb/70a7692d-647c-9be7-00a6-06fc60f77294@igalia.com/T/#mf00d6669c2eff7b308d1162acd1d66c09f0853c7 Fixes: d07e8819a03d ("usb: dwc3: add xHCI Host support") Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Sanath S <Sanath.S@amd.com> Tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> # Steam Deck Link: https://lore.kernel.org/r/667cfda7009b502e08462c8fb3f65841d103cc0a.1709865476.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-06-10 17:29:01 +00:00
dwc->sys_wakeup = device_may_wakeup(dwc->sysdev);
ret = device_property_read_string(dev, "usb-psy-name", &usb_psy_name);
if (ret >= 0) {
dwc->usb_psy = power_supply_get_by_name(usb_psy_name);
if (!dwc->usb_psy)
dev_err(dev, "couldn't get usb power supply\n");
}
dwc->has_lpm_erratum = device_property_read_bool(dev,
"snps,has-lpm-erratum");
device_property_read_u8(dev, "snps,lpm-nyet-threshold",
&lpm_nyet_threshold);
dwc->is_utmi_l1_suspend = device_property_read_bool(dev,
"snps,is-utmi-l1-suspend");
device_property_read_u8(dev, "snps,hird-threshold",
&hird_threshold);
usb: dwc3: Add workaround for isoc start transfer failure In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed isochronous IN, BIT[15:14] of the 16-bit microframe number reported by the XferNotReady event are invalid. The driver uses this number to schedule the isochronous transfer and passes it to the START TRANSFER command. Because this number is invalid, the command may fail. If BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER command will pass and the transfer will start at the scheduled time, if it is off by 1, the command will still pass, but the transfer will start 2 seconds in the future. For all other conditions, the START TRANSFER command will fail with bus-expiry. In order to workaround this issue, we can test for the correct combination of BIT[15:14] by sending START TRANSFER commands with different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11. Each combination is 2^14 uframe apart (or 2 seconds). 4 seconds into the future will result in a bus-expiry status. As the result, within the 4 possible combinations for BIT[15:14], there will be 2 successful and 2 failure START COMMAND status. One of the 2 successful command status will result in a 2-second delay start. The smaller BIT[15:14] value is the correct combination. Since there are only 4 outcomes and the results are ordered, we can simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00 and 'b01 to deduce the smaller successful combination. Let test0 = test status for combination 'b00 and test1 = test status for 'b01 of BIT[15:14]. The correct combination is as follow: if test0 fails and test1 passes, BIT[15:14] is 'b01 if test0 fails and test1 fails, BIT[15:14] is 'b10 if test0 passes and test1 fails, BIT[15:14] is 'b11 if test0 passes and test1 passes, BIT[15:14] is 'b00 Synopsys STAR 9001202023: Wrong microframe number for isochronous IN endpoints. Signed-off-by: Thinh Nguyen <thinhn@synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-11-15 06:56:54 +00:00
dwc->dis_start_transfer_quirk = device_property_read_bool(dev,
"snps,dis-start-transfer-quirk");
dwc->usb3_lpm_capable = device_property_read_bool(dev,
"snps,usb3_lpm_capable");
dwc->usb2_lpm_disable = device_property_read_bool(dev,
"snps,usb2-lpm-disable");
dwc->usb2_gadget_lpm_disable = device_property_read_bool(dev,
"snps,usb2-gadget-lpm-disable");
device_property_read_u8(dev, "snps,rx-thr-num-pkt",
&rx_thr_num_pkt);
device_property_read_u8(dev, "snps,rx-max-burst",
&rx_max_burst);
device_property_read_u8(dev, "snps,tx-thr-num-pkt",
&tx_thr_num_pkt);
device_property_read_u8(dev, "snps,tx-max-burst",
&tx_max_burst);
device_property_read_u8(dev, "snps,rx-thr-num-pkt-prd",
&rx_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,rx-max-burst-prd",
&rx_max_burst_prd);
device_property_read_u8(dev, "snps,tx-thr-num-pkt-prd",
&tx_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
&tx_max_burst_prd);
usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Bugzilla: http://bugzilla.redhat.com/2061784 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=45014530 Tested: HP ZBook 15 G5/80D5 Laptop TGL-U(QS) Laptop Conflicts: In the upstream kernel, this commit was applied before commit 40edb52298df (usb: dwc3: avoid NULL access of usb_gadget_driver). For some reason 9f607a309fbe (usb: dwc3: Resize TX FIFOs to meet EP burstin) was ommited when our centos kernel was pulled forward to v5.14. The conflicts identified with this patch are due to this patch being applied "after" 40edb52298df when it should have been applied "before". Not certain why our initial centos tree glanced over 9f607a309fbe. Adding it in now. commit 9f607a309fbe95fc1f77acce5af70766a7142537 Author: Wesley Cheng <wcheng@codeaurora.org> Date: Sat Jul 10 02:13:12 2021 -0700 usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Some devices have USB compositions which may require multiple endpoints that support EP bursting. HW defined TX FIFO sizes may not always be sufficient for these compositions. By utilizing flexible TX FIFO allocation, this allows for endpoints to request the required FIFO depth to achieve higher bandwidth. With some higher bMaxBurst configurations, using a larger TX FIFO size results in better TX throughput. By introducing the check_config() callback, the resizing logic can fetch the maximum number of endpoints used in the USB composition (can contain multiple configurations), which helps ensure that the resizing logic can fulfill the configuration(s), or return an error to the gadget layer otherwise during bind time. Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1625908395-5498-4-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Torez Smith <torez@redhat.com>
2022-05-02 16:31:17 +00:00
dwc->do_fifo_resize = device_property_read_bool(dev,
"tx-fifo-resize");
if (dwc->do_fifo_resize)
device_property_read_u8(dev, "tx-fifo-max-num",
&tx_fifo_resize_max_num);
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
dwc->u2exit_lfps_quirk = device_property_read_bool(dev,
"snps,u2exit_lfps_quirk");
dwc->u2ss_inp3_quirk = device_property_read_bool(dev,
"snps,u2ss_inp3_quirk");
dwc->req_p1p2p3_quirk = device_property_read_bool(dev,
"snps,req_p1p2p3_quirk");
dwc->del_p1p2p3_quirk = device_property_read_bool(dev,
"snps,del_p1p2p3_quirk");
dwc->del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,del_phy_power_chg_quirk");
dwc->lfps_filter_quirk = device_property_read_bool(dev,
"snps,lfps_filter_quirk");
dwc->rx_detect_poll_quirk = device_property_read_bool(dev,
"snps,rx_detect_poll_quirk");
dwc->dis_u3_susphy_quirk = device_property_read_bool(dev,
"snps,dis_u3_susphy_quirk");
dwc->dis_u2_susphy_quirk = device_property_read_bool(dev,
"snps,dis_u2_susphy_quirk");
dwc->dis_enblslpm_quirk = device_property_read_bool(dev,
"snps,dis_enblslpm_quirk");
usb: dwc3: gadget: Add support for disabling U1 and U2 entries Gadget applications may have a requirement to disable the U1 and U2 entry based on the usecase. Below are few usecases where the disabling U1/U2 entries may be possible. Usecase 1: When combining dwc3 with an redriver for a USB Type-C device solution, it sometimes have problems with leaving U1/U2 for certain hosts, resulting in link training errors and reconnects. For this U1/U2 state entries may be avoided. Usecase 2: When performing performance benchmarking on mass storage gadget the U1 and U2 entries can be disabled. Usecase 3: When periodic transfers like ISOC transfers are used with bInterval of 1 which doesn't require the link to enter into U1 or U2 state entry (since ping is issued from host for every uframe interval). In this case the U1 and U2 entry can be disabled. Disablement of U1/U2 can be done by setting U1DevExitLat and U2DevExitLat values to 0 in the BOS descriptor. Host on seeing 0 value for U1DevExitLat and U2DevExitLat, it doesn't send SET_SEL requests to the gadget. There may be some hosts which may send SET_SEL requests even after seeing 0 in the UxDevExitLat of BOS descriptor. To aviod U1/U2 entries for these type of hosts, dwc3 controller can be programmed to reject those U1/U2 requests by not enabling ACCEPTUxENA bits in DCTL register. This patch updates the same. Signed-off-by: Anurag Kumar Vulisha <anurag.kumar.vulisha@xilinx.com> Signed-off-by: Claus H. Stovgaard <cst@phaseone.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-05-10 07:07:28 +00:00
dwc->dis_u1_entry_quirk = device_property_read_bool(dev,
"snps,dis-u1-entry-quirk");
dwc->dis_u2_entry_quirk = device_property_read_bool(dev,
"snps,dis-u2-entry-quirk");
dwc->dis_rxdet_inp3_quirk = device_property_read_bool(dev,
"snps,dis_rxdet_inp3_quirk");
dwc->dis_u2_freeclk_exists_quirk = device_property_read_bool(dev,
"snps,dis-u2-freeclk-exists-quirk");
dwc->dis_del_phy_power_chg_quirk = device_property_read_bool(dev,
"snps,dis-del-phy-power-chg-quirk");
dwc->dis_tx_ipgap_linecheck_quirk = device_property_read_bool(dev,
"snps,dis-tx-ipgap-linecheck-quirk");
dwc->resume_hs_terminations = device_property_read_bool(dev,
"snps,resume-hs-terminations");
dwc->ulpi_ext_vbus_drv = device_property_read_bool(dev,
"snps,ulpi-ext-vbus-drv");
dwc->parkmode_disable_ss_quirk = device_property_read_bool(dev,
"snps,parkmode-disable-ss-quirk");
dwc->parkmode_disable_hs_quirk = device_property_read_bool(dev,
"snps,parkmode-disable-hs-quirk");
dwc->gfladj_refclk_lpm_sel = device_property_read_bool(dev,
"snps,gfladj-refclk-lpm-sel-quirk");
dwc->tx_de_emphasis_quirk = device_property_read_bool(dev,
"snps,tx_de_emphasis_quirk");
device_property_read_u8(dev, "snps,tx_de_emphasis",
&tx_de_emphasis);
device_property_read_string(dev, "snps,hsphy_interface",
&dwc->hsphy_interface);
device_property_read_u32(dev, "snps,quirk-frame-length-adjustment",
&dwc->fladj);
device_property_read_u32(dev, "snps,ref-clock-period-ns",
&dwc->ref_clk_per);
dwc->dis_metastability_quirk = device_property_read_bool(dev,
"snps,dis_metastability_quirk");
dwc->dis_split_quirk = device_property_read_bool(dev,
"snps,dis-split-quirk");
dwc->lpm_nyet_threshold = lpm_nyet_threshold;
dwc->tx_de_emphasis = tx_de_emphasis;
dwc->hird_threshold = hird_threshold;
dwc->rx_thr_num_pkt = rx_thr_num_pkt;
dwc->rx_max_burst = rx_max_burst;
dwc->tx_thr_num_pkt = tx_thr_num_pkt;
dwc->tx_max_burst = tx_max_burst;
dwc->rx_thr_num_pkt_prd = rx_thr_num_pkt_prd;
dwc->rx_max_burst_prd = rx_max_burst_prd;
dwc->tx_thr_num_pkt_prd = tx_thr_num_pkt_prd;
dwc->tx_max_burst_prd = tx_max_burst_prd;
dwc->imod_interval = 0;
usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Bugzilla: http://bugzilla.redhat.com/2061784 Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=45014530 Tested: HP ZBook 15 G5/80D5 Laptop TGL-U(QS) Laptop Conflicts: In the upstream kernel, this commit was applied before commit 40edb52298df (usb: dwc3: avoid NULL access of usb_gadget_driver). For some reason 9f607a309fbe (usb: dwc3: Resize TX FIFOs to meet EP burstin) was ommited when our centos kernel was pulled forward to v5.14. The conflicts identified with this patch are due to this patch being applied "after" 40edb52298df when it should have been applied "before". Not certain why our initial centos tree glanced over 9f607a309fbe. Adding it in now. commit 9f607a309fbe95fc1f77acce5af70766a7142537 Author: Wesley Cheng <wcheng@codeaurora.org> Date: Sat Jul 10 02:13:12 2021 -0700 usb: dwc3: Resize TX FIFOs to meet EP bursting requirements Some devices have USB compositions which may require multiple endpoints that support EP bursting. HW defined TX FIFO sizes may not always be sufficient for these compositions. By utilizing flexible TX FIFO allocation, this allows for endpoints to request the required FIFO depth to achieve higher bandwidth. With some higher bMaxBurst configurations, using a larger TX FIFO size results in better TX throughput. By introducing the check_config() callback, the resizing logic can fetch the maximum number of endpoints used in the USB composition (can contain multiple configurations), which helps ensure that the resizing logic can fulfill the configuration(s), or return an error to the gadget layer otherwise during bind time. Signed-off-by: Wesley Cheng <wcheng@codeaurora.org> Link: https://lore.kernel.org/r/1625908395-5498-4-git-send-email-wcheng@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Torez Smith <torez@redhat.com>
2022-05-02 16:31:17 +00:00
dwc->tx_fifo_resize_max_num = tx_fifo_resize_max_num;
}
/* check whether the core supports IMOD */
bool dwc3_has_imod(struct dwc3 *dwc)
{
2020-04-12 02:20:01 +00:00
return DWC3_VER_IS_WITHIN(DWC3, 300A, ANY) ||
DWC3_VER_IS_WITHIN(DWC31, 120A, ANY) ||
DWC3_IP_IS(DWC32);
}
static void dwc3_check_params(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
unsigned int hwparam_gen =
DWC3_GHWPARAMS3_SSPHY_IFC(dwc->hwparams.hwparams3);
/* Check for proper value of imod_interval */
if (dwc->imod_interval && !dwc3_has_imod(dwc)) {
dev_warn(dwc->dev, "Interrupt moderation not supported\n");
dwc->imod_interval = 0;
}
/*
* Workaround for STAR 9000961433 which affects only version
* 3.00a of the DWC_usb3 core. This prevents the controller
* interrupt from being masked while handling events. IMOD
* allows us to work around this issue. Enable it for the
* affected version.
*/
if (!dwc->imod_interval &&
2020-04-12 02:20:01 +00:00
DWC3_VER_IS(DWC3, 300A))
dwc->imod_interval = 1;
/* Check the maximum_speed parameter */
switch (dwc->maximum_speed) {
case USB_SPEED_FULL:
case USB_SPEED_HIGH:
break;
case USB_SPEED_SUPER:
if (hwparam_gen == DWC3_GHWPARAMS3_SSPHY_IFC_DIS)
dev_warn(dev, "UDC doesn't support Gen 1\n");
break;
case USB_SPEED_SUPER_PLUS:
if ((DWC3_IP_IS(DWC32) &&
hwparam_gen == DWC3_GHWPARAMS3_SSPHY_IFC_DIS) ||
(!DWC3_IP_IS(DWC32) &&
hwparam_gen != DWC3_GHWPARAMS3_SSPHY_IFC_GEN2))
dev_warn(dev, "UDC doesn't support SSP\n");
break;
default:
dev_err(dev, "invalid maximum_speed parameter %d\n",
dwc->maximum_speed);
fallthrough;
case USB_SPEED_UNKNOWN:
switch (hwparam_gen) {
case DWC3_GHWPARAMS3_SSPHY_IFC_GEN2:
dwc->maximum_speed = USB_SPEED_SUPER_PLUS;
break;
case DWC3_GHWPARAMS3_SSPHY_IFC_GEN1:
if (DWC3_IP_IS(DWC32))
dwc->maximum_speed = USB_SPEED_SUPER_PLUS;
else
dwc->maximum_speed = USB_SPEED_SUPER;
break;
case DWC3_GHWPARAMS3_SSPHY_IFC_DIS:
dwc->maximum_speed = USB_SPEED_HIGH;
break;
default:
dwc->maximum_speed = USB_SPEED_SUPER;
break;
}
break;
}
/*
* Currently the controller does not have visibility into the HW
* parameter to determine the maximum number of lanes the HW supports.
* If the number of lanes is not specified in the device property, then
* set the default to support dual-lane for DWC_usb32 and single-lane
* for DWC_usb31 for super-speed-plus.
*/
if (dwc->maximum_speed == USB_SPEED_SUPER_PLUS) {
switch (dwc->max_ssp_rate) {
case USB_SSP_GEN_2x1:
if (hwparam_gen == DWC3_GHWPARAMS3_SSPHY_IFC_GEN1)
dev_warn(dev, "UDC only supports Gen 1\n");
break;
case USB_SSP_GEN_1x2:
case USB_SSP_GEN_2x2:
if (DWC3_IP_IS(DWC31))
dev_warn(dev, "UDC only supports single lane\n");
break;
case USB_SSP_GEN_UNKNOWN:
default:
switch (hwparam_gen) {
case DWC3_GHWPARAMS3_SSPHY_IFC_GEN2:
if (DWC3_IP_IS(DWC32))
dwc->max_ssp_rate = USB_SSP_GEN_2x2;
else
dwc->max_ssp_rate = USB_SSP_GEN_2x1;
break;
case DWC3_GHWPARAMS3_SSPHY_IFC_GEN1:
if (DWC3_IP_IS(DWC32))
dwc->max_ssp_rate = USB_SSP_GEN_1x2;
break;
}
break;
}
}
}
static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
struct device_node *np_phy;
struct extcon_dev *edev = NULL;
const char *name;
if (device_property_present(dev, "extcon"))
return extcon_get_edev_by_phandle(dev, 0);
/*
* Device tree platforms should get extcon via phandle.
* On ACPI platforms, we get the name from a device property.
* This device property is for kernel internal use only and
* is expected to be set by the glue code.
*/
if (device_property_read_string(dev, "linux,extcon-name", &name) == 0)
return extcon_get_extcon_dev(name);
/*
* Check explicitly if "usb-role-switch" is used since
* extcon_find_edev_by_node() can not be used to check the absence of
* an extcon device. In the absence of an device it will always return
* EPROBE_DEFER.
*/
if (IS_ENABLED(CONFIG_USB_ROLE_SWITCH) &&
device_property_read_bool(dev, "usb-role-switch"))
return NULL;
/*
* Try to get an extcon device from the USB PHY controller's "port"
* node. Check if it has the "port" node first, to avoid printing the
* error message from underlying code, as it's a valid case: extcon
* device (and "port" node) may be missing in case of "usb-role-switch"
* or OTG mode.
*/
np_phy = of_parse_phandle(dev->of_node, "phys", 0);
if (of_graph_is_present(np_phy)) {
struct device_node *np_conn;
np_conn = of_graph_get_remote_node(np_phy, -1, -1);
if (np_conn)
edev = extcon_find_edev_by_node(np_conn);
of_node_put(np_conn);
}
of_node_put(np_phy);
return edev;
}
static int dwc3_get_clocks(struct dwc3 *dwc)
{
struct device *dev = dwc->dev;
if (!dev->of_node)
return 0;
/*
* Clocks are optional, but new DT platforms should support all clocks
* as required by the DT-binding.
* Some devices have different clock names in legacy device trees,
* check for them to retain backwards compatibility.
*/
dwc->bus_clk = devm_clk_get_optional(dev, "bus_early");
if (IS_ERR(dwc->bus_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->bus_clk),
"could not get bus clock\n");
}
if (dwc->bus_clk == NULL) {
dwc->bus_clk = devm_clk_get_optional(dev, "bus_clk");
if (IS_ERR(dwc->bus_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->bus_clk),
"could not get bus clock\n");
}
}
dwc->ref_clk = devm_clk_get_optional(dev, "ref");
if (IS_ERR(dwc->ref_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->ref_clk),
"could not get ref clock\n");
}
if (dwc->ref_clk == NULL) {
dwc->ref_clk = devm_clk_get_optional(dev, "ref_clk");
if (IS_ERR(dwc->ref_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->ref_clk),
"could not get ref clock\n");
}
}
dwc->susp_clk = devm_clk_get_optional(dev, "suspend");
if (IS_ERR(dwc->susp_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->susp_clk),
"could not get suspend clock\n");
}
if (dwc->susp_clk == NULL) {
dwc->susp_clk = devm_clk_get_optional(dev, "suspend_clk");
if (IS_ERR(dwc->susp_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->susp_clk),
"could not get suspend clock\n");
}
}
/* specific to Rockchip RK3588 */
dwc->utmi_clk = devm_clk_get_optional(dev, "utmi");
if (IS_ERR(dwc->utmi_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->utmi_clk),
"could not get utmi clock\n");
}
/* specific to Rockchip RK3588 */
dwc->pipe_clk = devm_clk_get_optional(dev, "pipe");
if (IS_ERR(dwc->pipe_clk)) {
return dev_err_probe(dev, PTR_ERR(dwc->pipe_clk),
"could not get pipe clock\n");
}
return 0;
}
static int dwc3_get_num_ports(struct dwc3 *dwc)
{
void __iomem *base;
u8 major_revision;
u32 offset;
u32 val;
/*
* Remap xHCI address space to access XHCI ext cap regs since it is
* needed to get information on number of ports present.
*/
base = ioremap(dwc->xhci_resources[0].start,
resource_size(&dwc->xhci_resources[0]));
if (!base)
return -ENOMEM;
offset = 0;
do {
offset = xhci_find_next_ext_cap(base, offset,
XHCI_EXT_CAPS_PROTOCOL);
if (!offset)
break;
val = readl(base + offset);
major_revision = XHCI_EXT_PORT_MAJOR(val);
val = readl(base + offset + 0x08);
if (major_revision == 0x03) {
dwc->num_usb3_ports += XHCI_EXT_PORT_COUNT(val);
} else if (major_revision <= 0x02) {
dwc->num_usb2_ports += XHCI_EXT_PORT_COUNT(val);
} else {
dev_warn(dwc->dev, "unrecognized port major revision %d\n",
major_revision);
}
} while (1);
dev_dbg(dwc->dev, "hs-ports: %u ss-ports: %u\n",
dwc->num_usb2_ports, dwc->num_usb3_ports);
iounmap(base);
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
if (dwc->num_usb2_ports > DWC3_USB2_MAX_PORTS ||
dwc->num_usb3_ports > DWC3_USB3_MAX_PORTS)
return -EINVAL;
return 0;
}
static int dwc3_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct resource *res, dwc_res;
unsigned int hw_mode;
void __iomem *regs;
struct dwc3 *dwc;
int ret;
dwc = devm_kzalloc(dev, sizeof(*dwc), GFP_KERNEL);
if (!dwc)
return -ENOMEM;
dwc->dev = dev;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(dev, "missing memory resource\n");
return -ENODEV;
}
dwc->xhci_resources[0].start = res->start;
dwc->xhci_resources[0].end = dwc->xhci_resources[0].start +
DWC3_XHCI_REGS_END;
dwc->xhci_resources[0].flags = res->flags;
dwc->xhci_resources[0].name = res->name;
/*
* Request memory region but exclude xHCI regs,
* since it will be requested by the xhci-plat driver.
*/
dwc_res = *res;
dwc_res.start += DWC3_GLOBALS_REGS_START;
if (dev->of_node) {
struct device_node *parent = of_get_parent(dev->of_node);
if (of_device_is_compatible(parent, "realtek,rtd-dwc3")) {
dwc_res.start -= DWC3_GLOBALS_REGS_START;
dwc_res.start += DWC3_RTK_RTD_GLOBALS_REGS_START;
}
of_node_put(parent);
}
regs = devm_ioremap_resource(dev, &dwc_res);
if (IS_ERR(regs))
return PTR_ERR(regs);
dwc->regs = regs;
dwc->regs_size = resource_size(&dwc_res);
dwc3_get_properties(dwc);
dwc3_get_software_properties(dwc);
dwc->reset = devm_reset_control_array_get_optional_shared(dev);
if (IS_ERR(dwc->reset)) {
ret = PTR_ERR(dwc->reset);
goto err_put_psy;
}
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
ret = dwc3_get_clocks(dwc);
if (ret)
goto err_put_psy;
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
ret = reset_control_deassert(dwc->reset);
if (ret)
goto err_put_psy;
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
ret = dwc3_clk_enable(dwc);
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
if (ret)
goto err_assert_reset;
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
if (!dwc3_core_is_valid(dwc)) {
dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
ret = -ENODEV;
goto err_disable_clks;
}
platform_set_drvdata(pdev, dwc);
dwc3_cache_hwparams(dwc);
if (!dwc->sysdev_is_parent &&
DWC3_GHWPARAMS0_AWIDTH(dwc->hwparams.hwparams0) == 64) {
ret = dma_set_mask_and_coherent(dwc->sysdev, DMA_BIT_MASK(64));
if (ret)
goto err_disable_clks;
}
/*
* Currently only DWC3 controllers that are host-only capable
* can have more than one port.
*/
hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
if (hw_mode == DWC3_GHWPARAMS0_MODE_HOST) {
ret = dwc3_get_num_ports(dwc);
if (ret)
goto err_disable_clks;
} else {
dwc->num_usb2_ports = 1;
dwc->num_usb3_ports = 1;
}
spin_lock_init(&dwc->lock);
usb: dwc3: core: Do core softreset when switch mode From: John Stultz <john.stultz@linaro.org> According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Ferry Toth <fntoth@gmail.com> Cc: Wesley Cheng <wcheng@codeaurora.org> Cc: <stable@vger.kernel.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Wesley Cheng <wcheng@codeaurora.org> Signed-off-by: Yu Chen <chenyu56@huawei.com> Signed-off-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://lore.kernel.org/r/374440f8dcd4f06c02c2caf4b1efde86774e02d9.1618521663.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-15 22:20:30 +00:00
mutex_init(&dwc->mutex);
pm_runtime_get_noresume(dev);
pm_runtime_set_active(dev);
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
pm_runtime_forbid(dev);
ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
if (ret) {
dev_err(dwc->dev, "failed to allocate event buffers\n");
ret = -ENOMEM;
goto err_allow_rpm;
}
dwc->edev = dwc3_get_extcon(dwc);
if (IS_ERR(dwc->edev)) {
ret = dev_err_probe(dwc->dev, PTR_ERR(dwc->edev), "failed to get extcon\n");
goto err_free_event_buffers;
}
ret = dwc3_get_dr_mode(dwc);
if (ret)
goto err_free_event_buffers;
ret = dwc3_core_init(dwc);
if (ret) {
dev_err_probe(dev, ret, "failed to initialize core\n");
goto err_free_event_buffers;
}
dwc3_check_params(dwc);
dwc3_debugfs_init(dwc);
ret = dwc3_core_init_mode(dwc);
if (ret)
goto err_exit_debugfs;
pm_runtime_put(dev);
dma_set_max_seg_size(dev, UINT_MAX);
return 0;
err_exit_debugfs:
dwc3_debugfs_exit(dwc);
dwc3_event_buffers_cleanup(dwc);
dwc3_phy_power_off(dwc);
dwc3_phy_exit(dwc);
dwc3_ulpi_exit(dwc);
err_free_event_buffers:
dwc3_free_event_buffers(dwc);
err_allow_rpm:
pm_runtime_allow(dev);
pm_runtime_disable(dev);
pm_runtime_dont_use_autosuspend(dev);
pm_runtime_set_suspended(dev);
pm_runtime_put_noidle(dev);
err_disable_clks:
dwc3_clk_disable(dwc);
err_assert_reset:
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
reset_control_assert(dwc->reset);
err_put_psy:
if (dwc->usb_psy)
power_supply_put(dwc->usb_psy);
return ret;
}
static void dwc3_remove(struct platform_device *pdev)
{
struct dwc3 *dwc = platform_get_drvdata(pdev);
pm_runtime_get_sync(&pdev->dev);
dwc3_core_exit_mode(dwc);
usb: dwc3: core: fix kernel panic when do reboot When do system reboot, it calls dwc3_shutdown and the whole debugfs for dwc3 has removed first, when the gadget tries to do deinit, and remove debugfs for its endpoints, it meets NULL pointer dereference issue when call debugfs_lookup. Fix it by removing the whole dwc3 debugfs later than dwc3_drd_exit. [ 2924.958838] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000002 .... [ 2925.030994] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 2925.037005] pc : inode_permission+0x2c/0x198 [ 2925.041281] lr : lookup_one_len_common+0xb0/0xf8 [ 2925.045903] sp : ffff80001276ba70 [ 2925.049218] x29: ffff80001276ba70 x28: ffff0000c01f0000 x27: 0000000000000000 [ 2925.056364] x26: ffff800011791e70 x25: 0000000000000008 x24: dead000000000100 [ 2925.063510] x23: dead000000000122 x22: 0000000000000000 x21: 0000000000000001 [ 2925.070652] x20: ffff8000122c6188 x19: 0000000000000000 x18: 0000000000000000 [ 2925.077797] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000004 [ 2925.084943] x14: ffffffffffffffff x13: 0000000000000000 x12: 0000000000000030 [ 2925.092087] x11: 0101010101010101 x10: 7f7f7f7f7f7f7f7f x9 : ffff8000102b2420 [ 2925.099232] x8 : 7f7f7f7f7f7f7f7f x7 : feff73746e2f6f64 x6 : 0000000000008080 [ 2925.106378] x5 : 61c8864680b583eb x4 : 209e6ec2d263dbb7 x3 : 000074756f307065 [ 2925.113523] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff8000122c6188 [ 2925.120671] Call trace: [ 2925.123119] inode_permission+0x2c/0x198 [ 2925.127042] lookup_one_len_common+0xb0/0xf8 [ 2925.131315] lookup_one_len_unlocked+0x34/0xb0 [ 2925.135764] lookup_positive_unlocked+0x14/0x50 [ 2925.140296] debugfs_lookup+0x68/0xa0 [ 2925.143964] dwc3_gadget_free_endpoints+0x84/0xb0 [ 2925.148675] dwc3_gadget_exit+0x28/0x78 [ 2925.152518] dwc3_drd_exit+0x100/0x1f8 [ 2925.156267] dwc3_remove+0x11c/0x120 [ 2925.159851] dwc3_shutdown+0x14/0x20 [ 2925.163432] platform_shutdown+0x28/0x38 [ 2925.167360] device_shutdown+0x15c/0x378 [ 2925.171291] kernel_restart_prepare+0x3c/0x48 [ 2925.175650] kernel_restart+0x1c/0x68 [ 2925.179316] __do_sys_reboot+0x218/0x240 [ 2925.183247] __arm64_sys_reboot+0x28/0x30 [ 2925.187262] invoke_syscall+0x48/0x100 [ 2925.191017] el0_svc_common.constprop.0+0x48/0xc8 [ 2925.195726] do_el0_svc+0x28/0x88 [ 2925.199045] el0_svc+0x20/0x30 [ 2925.202104] el0_sync_handler+0xa8/0xb0 [ 2925.205942] el0_sync+0x148/0x180 [ 2925.209270] Code: a9025bf5 2a0203f5 121f0056 370802b5 (79400660) [ 2925.215372] ---[ end trace 124254d8e485a58b ]--- [ 2925.220012] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 2925.227676] Kernel Offset: disabled [ 2925.231164] CPU features: 0x00001001,20000846 [ 2925.235521] Memory Limit: none [ 2925.238580] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 5ff90af9da8f ("usb: dwc3: debugfs: Add and remove endpoint dirs dynamically") Cc: Jack Pham <jackp@codeaurora.org> Tested-by: Jack Pham <jackp@codeaurora.org> Signed-off-by: Peter Chen <peter.chen@kernel.org> Link: https://lore.kernel.org/r/20210608105656.10795-1-peter.chen@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-06-08 10:56:56 +00:00
dwc3_debugfs_exit(dwc);
dwc3_core_exit(dwc);
dwc3_ulpi_exit(dwc);
pm_runtime_allow(&pdev->dev);
pm_runtime_disable(&pdev->dev);
pm_runtime_dont_use_autosuspend(&pdev->dev);
usb: dwc3: core: don't trigger runtime pm when remove driver No need to trigger runtime pm in driver removal, otherwise if user disable auto suspend via sys file, runtime suspend may be entered, which will call dwc3_core_exit() again and there will be clock disable not balance warning: [ 2026.820154] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 2026.825268] usb usb2: USB disconnect, device number 1 [ 2026.831017] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered [ 2026.836806] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 2026.842029] usb usb1: USB disconnect, device number 1 [ 2026.848029] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered [ 2026.865889] ------------[ cut here ]------------ [ 2026.870506] usb2_ctrl_root_clk already disabled [ 2026.875082] WARNING: CPU: 0 PID: 731 at drivers/clk/clk.c:958 clk_core_disable+0xa0/0xa8 [ 2026.883170] Modules linked in: dwc3(-) phy_fsl_imx8mq_usb [last unloaded: dwc3] [ 2026.890488] CPU: 0 PID: 731 Comm: rmmod Not tainted 5.8.0-rc7-00280-g9d08cca-dirty #245 [ 2026.898489] Hardware name: NXP i.MX8MQ EVK (DT) [ 2026.903020] pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--) [ 2026.908594] pc : clk_core_disable+0xa0/0xa8 [ 2026.912777] lr : clk_core_disable+0xa0/0xa8 [ 2026.916958] sp : ffff8000121b39a0 [ 2026.920271] x29: ffff8000121b39a0 x28: ffff0000b11f3700 [ 2026.925583] x27: 0000000000000000 x26: ffff0000b539c700 [ 2026.930895] x25: 000001d7e44e1232 x24: ffff0000b76fa800 [ 2026.936208] x23: ffff0000b76fa6f8 x22: ffff800008d01040 [ 2026.941520] x21: ffff0000b539ce00 x20: ffff0000b7105000 [ 2026.946832] x19: ffff0000b7105000 x18: 0000000000000010 [ 2026.952144] x17: 0000000000000001 x16: 0000000000000000 [ 2026.957456] x15: ffff0000b11f3b70 x14: ffffffffffffffff [ 2026.962768] x13: ffff8000921b36f7 x12: ffff8000121b36ff [ 2026.968080] x11: ffff8000119e1000 x10: ffff800011bf26d0 [ 2026.973392] x9 : 0000000000000000 x8 : ffff800011bf3000 [ 2026.978704] x7 : ffff800010695d68 x6 : 0000000000000252 [ 2026.984016] x5 : ffff0000bb9881f0 x4 : 0000000000000000 [ 2026.989327] x3 : 0000000000000027 x2 : 0000000000000023 [ 2026.994639] x1 : ac2fa471aa7cab00 x0 : 0000000000000000 [ 2026.999951] Call trace: [ 2027.002401] clk_core_disable+0xa0/0xa8 [ 2027.006238] clk_core_disable_lock+0x20/0x38 [ 2027.010508] clk_disable+0x1c/0x28 [ 2027.013911] clk_bulk_disable+0x34/0x50 [ 2027.017758] dwc3_core_exit+0xec/0x110 [dwc3] [ 2027.022122] dwc3_suspend_common+0x84/0x188 [dwc3] [ 2027.026919] dwc3_runtime_suspend+0x74/0x9c [dwc3] [ 2027.031712] pm_generic_runtime_suspend+0x28/0x40 [ 2027.036419] genpd_runtime_suspend+0xa0/0x258 [ 2027.040777] __rpm_callback+0x88/0x140 [ 2027.044526] rpm_callback+0x20/0x80 [ 2027.048015] rpm_suspend+0xd0/0x418 [ 2027.051503] __pm_runtime_suspend+0x58/0xa0 [ 2027.055693] dwc3_runtime_idle+0x7c/0x90 [dwc3] [ 2027.060224] __rpm_callback+0x88/0x140 [ 2027.063973] rpm_idle+0x78/0x150 [ 2027.067201] __pm_runtime_idle+0x58/0xa0 [ 2027.071130] dwc3_remove+0x64/0xc0 [dwc3] [ 2027.075140] platform_drv_remove+0x28/0x48 [ 2027.079239] device_release_driver_internal+0xf4/0x1c0 [ 2027.084377] driver_detach+0x4c/0xd8 [ 2027.087954] bus_remove_driver+0x54/0xa8 [ 2027.091877] driver_unregister+0x2c/0x58 [ 2027.095799] platform_driver_unregister+0x10/0x18 [ 2027.100509] dwc3_driver_exit+0x14/0x1408 [dwc3] [ 2027.105129] __arm64_sys_delete_module+0x178/0x218 [ 2027.109922] el0_svc_common.constprop.0+0x68/0x160 [ 2027.114714] do_el0_svc+0x20/0x80 [ 2027.118031] el0_sync_handler+0x88/0x190 [ 2027.121953] el0_sync+0x140/0x180 [ 2027.125267] ---[ end trace 027f4f8189958f1f ]--- [ 2027.129976] ------------[ cut here ]------------ Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Cc: <stable@vger.kernel.org> Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-07-28 12:42:40 +00:00
pm_runtime_put_noidle(&pdev->dev);
/*
* HACK: Clear the driver data, which is currently accessed by parent
* glue drivers, before allowing the parent to suspend.
*/
platform_set_drvdata(pdev, NULL);
usb: dwc3: core: don't trigger runtime pm when remove driver No need to trigger runtime pm in driver removal, otherwise if user disable auto suspend via sys file, runtime suspend may be entered, which will call dwc3_core_exit() again and there will be clock disable not balance warning: [ 2026.820154] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 2026.825268] usb usb2: USB disconnect, device number 1 [ 2026.831017] xhci-hcd xhci-hcd.0.auto: USB bus 2 deregistered [ 2026.836806] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 2026.842029] usb usb1: USB disconnect, device number 1 [ 2026.848029] xhci-hcd xhci-hcd.0.auto: USB bus 1 deregistered [ 2026.865889] ------------[ cut here ]------------ [ 2026.870506] usb2_ctrl_root_clk already disabled [ 2026.875082] WARNING: CPU: 0 PID: 731 at drivers/clk/clk.c:958 clk_core_disable+0xa0/0xa8 [ 2026.883170] Modules linked in: dwc3(-) phy_fsl_imx8mq_usb [last unloaded: dwc3] [ 2026.890488] CPU: 0 PID: 731 Comm: rmmod Not tainted 5.8.0-rc7-00280-g9d08cca-dirty #245 [ 2026.898489] Hardware name: NXP i.MX8MQ EVK (DT) [ 2026.903020] pstate: 20000085 (nzCv daIf -PAN -UAO BTYPE=--) [ 2026.908594] pc : clk_core_disable+0xa0/0xa8 [ 2026.912777] lr : clk_core_disable+0xa0/0xa8 [ 2026.916958] sp : ffff8000121b39a0 [ 2026.920271] x29: ffff8000121b39a0 x28: ffff0000b11f3700 [ 2026.925583] x27: 0000000000000000 x26: ffff0000b539c700 [ 2026.930895] x25: 000001d7e44e1232 x24: ffff0000b76fa800 [ 2026.936208] x23: ffff0000b76fa6f8 x22: ffff800008d01040 [ 2026.941520] x21: ffff0000b539ce00 x20: ffff0000b7105000 [ 2026.946832] x19: ffff0000b7105000 x18: 0000000000000010 [ 2026.952144] x17: 0000000000000001 x16: 0000000000000000 [ 2026.957456] x15: ffff0000b11f3b70 x14: ffffffffffffffff [ 2026.962768] x13: ffff8000921b36f7 x12: ffff8000121b36ff [ 2026.968080] x11: ffff8000119e1000 x10: ffff800011bf26d0 [ 2026.973392] x9 : 0000000000000000 x8 : ffff800011bf3000 [ 2026.978704] x7 : ffff800010695d68 x6 : 0000000000000252 [ 2026.984016] x5 : ffff0000bb9881f0 x4 : 0000000000000000 [ 2026.989327] x3 : 0000000000000027 x2 : 0000000000000023 [ 2026.994639] x1 : ac2fa471aa7cab00 x0 : 0000000000000000 [ 2026.999951] Call trace: [ 2027.002401] clk_core_disable+0xa0/0xa8 [ 2027.006238] clk_core_disable_lock+0x20/0x38 [ 2027.010508] clk_disable+0x1c/0x28 [ 2027.013911] clk_bulk_disable+0x34/0x50 [ 2027.017758] dwc3_core_exit+0xec/0x110 [dwc3] [ 2027.022122] dwc3_suspend_common+0x84/0x188 [dwc3] [ 2027.026919] dwc3_runtime_suspend+0x74/0x9c [dwc3] [ 2027.031712] pm_generic_runtime_suspend+0x28/0x40 [ 2027.036419] genpd_runtime_suspend+0xa0/0x258 [ 2027.040777] __rpm_callback+0x88/0x140 [ 2027.044526] rpm_callback+0x20/0x80 [ 2027.048015] rpm_suspend+0xd0/0x418 [ 2027.051503] __pm_runtime_suspend+0x58/0xa0 [ 2027.055693] dwc3_runtime_idle+0x7c/0x90 [dwc3] [ 2027.060224] __rpm_callback+0x88/0x140 [ 2027.063973] rpm_idle+0x78/0x150 [ 2027.067201] __pm_runtime_idle+0x58/0xa0 [ 2027.071130] dwc3_remove+0x64/0xc0 [dwc3] [ 2027.075140] platform_drv_remove+0x28/0x48 [ 2027.079239] device_release_driver_internal+0xf4/0x1c0 [ 2027.084377] driver_detach+0x4c/0xd8 [ 2027.087954] bus_remove_driver+0x54/0xa8 [ 2027.091877] driver_unregister+0x2c/0x58 [ 2027.095799] platform_driver_unregister+0x10/0x18 [ 2027.100509] dwc3_driver_exit+0x14/0x1408 [dwc3] [ 2027.105129] __arm64_sys_delete_module+0x178/0x218 [ 2027.109922] el0_svc_common.constprop.0+0x68/0x160 [ 2027.114714] do_el0_svc+0x20/0x80 [ 2027.118031] el0_sync_handler+0x88/0x190 [ 2027.121953] el0_sync+0x140/0x180 [ 2027.125267] ---[ end trace 027f4f8189958f1f ]--- [ 2027.129976] ------------[ cut here ]------------ Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Cc: <stable@vger.kernel.org> Signed-off-by: Li Jun <jun.li@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org>
2020-07-28 12:42:40 +00:00
pm_runtime_set_suspended(&pdev->dev);
dwc3_free_event_buffers(dwc);
if (dwc->usb_psy)
power_supply_put(dwc->usb_psy);
}
#ifdef CONFIG_PM
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
static int dwc3_core_init_for_resume(struct dwc3 *dwc)
{
int ret;
ret = reset_control_deassert(dwc->reset);
if (ret)
return ret;
ret = dwc3_clk_enable(dwc);
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
if (ret)
goto assert_reset;
ret = dwc3_core_init(dwc);
if (ret)
goto disable_clks;
return 0;
disable_clks:
dwc3_clk_disable(dwc);
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
assert_reset:
reset_control_assert(dwc->reset);
return ret;
}
static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg)
{
u32 reg;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
if (!pm_runtime_suspended(dwc->dev) && !PMSG_IS_AUTO(msg)) {
dwc->susphy_state = (dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0)) &
DWC3_GUSB2PHYCFG_SUSPHY) ||
(dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0)) &
DWC3_GUSB3PIPECTL_SUSPHY);
/*
* TI AM62 platform requires SUSPHY to be
* enabled for system suspend to work.
*/
if (!dwc->susphy_state)
dwc3_enable_susphy(dwc, true);
}
usb: dwc3: core: Fix system suspend on TI AM62 platforms JIRA: https://issues.redhat.com/browse/RHEL-59052 commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 Author: Roger Quadros <rogerq@kernel.org> Date: Fri, 11 Oct 2024 13:53:24 +0300 Since commit 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init"), system suspend is broken on AM62 TI platforms. Before that commit, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during core initialization and even during core re-initialization after a system suspend/resume. These bits are required to be set for system suspend/resume to work correctly on AM62 platforms. Since that commit, the 2 SUSPHY bits are not set for DEVICE/OTG mode if gadget driver is not loaded and started. For Host mode, the 2 SUSPHY bits are set before the first system suspend but get cleared at system resume during core re-init and are never set again. This patch resovles these two issues by ensuring the 2 SUSPHY bits are set before system suspend and restored to the original state during system resume. Cc: stable@vger.kernel.org # v6.9+ Fixes: 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init") Link: https://lore.kernel.org/all/1519dbe7-73b6-4afc-bfe3-23f4f75d772f@kernel.org/ Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241011-am62-lpm-usb-v3-1-562d445625b5@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-11-28 19:54:06 +00:00
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_DEVICE:
if (pm_runtime_suspended(dwc->dev))
break;
dwc3_gadget_suspend(dwc);
usb: dwc3: move synchronize_irq() out of the spinlock protected block dwc3_gadget_suspend() is called under dwc->lock spinlock. In such context calling synchronize_irq() is not allowed. Move the problematic call out of the protected block to fix the following kernel BUG during system suspend: BUG: sleeping function called from invalid context at kernel/irq/manage.c:112 in_atomic(): 1, irqs_disabled(): 128, pid: 1601, name: rtcwake 6 locks held by rtcwake/1601: #0: f70ac2a2 (sb_writers#7){.+.+}, at: vfs_write+0x130/0x16c #1: b5fe1270 (&of->mutex){+.+.}, at: kernfs_fop_write+0xc0/0x1e4 #2: 7e597705 (kn->count#60){.+.+}, at: kernfs_fop_write+0xc8/0x1e4 #3: 8b3527d0 (system_transition_mutex){+.+.}, at: pm_suspend+0xc4/0xc04 #4: fc7f1c42 (&dev->mutex){....}, at: __device_suspend+0xd8/0x74c #5: 4b36507e (&(&dwc->lock)->rlock){....}, at: dwc3_gadget_suspend+0x24/0x3c irq event stamp: 11252 hardirqs last enabled at (11251): [<c09c54a4>] _raw_spin_unlock_irqrestore+0x6c/0x74 hardirqs last disabled at (11252): [<c09c4d44>] _raw_spin_lock_irqsave+0x1c/0x5c softirqs last enabled at (9744): [<c0102564>] __do_softirq+0x3a4/0x66c softirqs last disabled at (9737): [<c0128528>] irq_exit+0x140/0x168 Preemption disabled at: [<00000000>] (null) CPU: 7 PID: 1601 Comm: rtcwake Not tainted 5.0.0-rc3-next-20190122-00039-ga3f4ee4f8a52 #5252 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c01110f0>] (unwind_backtrace) from [<c010d120>] (show_stack+0x10/0x14) [<c010d120>] (show_stack) from [<c09a4d04>] (dump_stack+0x90/0xc8) [<c09a4d04>] (dump_stack) from [<c014c700>] (___might_sleep+0x22c/0x2c8) [<c014c700>] (___might_sleep) from [<c0189d68>] (synchronize_irq+0x28/0x84) [<c0189d68>] (synchronize_irq) from [<c05cbbf8>] (dwc3_gadget_suspend+0x34/0x3c) [<c05cbbf8>] (dwc3_gadget_suspend) from [<c05bd020>] (dwc3_suspend_common+0x154/0x410) [<c05bd020>] (dwc3_suspend_common) from [<c05bd34c>] (dwc3_suspend+0x14/0x2c) [<c05bd34c>] (dwc3_suspend) from [<c051c730>] (platform_pm_suspend+0x2c/0x54) [<c051c730>] (platform_pm_suspend) from [<c05285d4>] (dpm_run_callback+0xa4/0x3dc) [<c05285d4>] (dpm_run_callback) from [<c0528a40>] (__device_suspend+0x134/0x74c) [<c0528a40>] (__device_suspend) from [<c052c508>] (dpm_suspend+0x174/0x588) [<c052c508>] (dpm_suspend) from [<c0182134>] (suspend_devices_and_enter+0xc0/0xe74) [<c0182134>] (suspend_devices_and_enter) from [<c0183658>] (pm_suspend+0x770/0xc04) [<c0183658>] (pm_suspend) from [<c0180ddc>] (state_store+0x6c/0xcc) [<c0180ddc>] (state_store) from [<c09a9a70>] (kobj_attr_store+0x14/0x20) [<c09a9a70>] (kobj_attr_store) from [<c02d6800>] (sysfs_kf_write+0x4c/0x50) [<c02d6800>] (sysfs_kf_write) from [<c02d594c>] (kernfs_fop_write+0xfc/0x1e4) [<c02d594c>] (kernfs_fop_write) from [<c02593d8>] (__vfs_write+0x2c/0x160) [<c02593d8>] (__vfs_write) from [<c0259694>] (vfs_write+0xa4/0x16c) [<c0259694>] (vfs_write) from [<c0259870>] (ksys_write+0x40/0x8c) [<c0259870>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xed55ffa8 to 0xed55fff0) ... Fixes: 01c10880d242 ("usb: dwc3: gadget: synchronize_irq dwc irq in suspend") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-03-27 09:56:08 +00:00
synchronize_irq(dwc->irq_gadget);
dwc3_core_exit(dwc);
break;
case DWC3_GCTL_PRTCAP_HOST:
if (!PMSG_IS_AUTO(msg) && !device_may_wakeup(dwc->dev)) {
dwc3_core_exit(dwc);
break;
}
/* Let controller to suspend HSPHY before PHY driver suspends */
if (dwc->dis_u2_susphy_quirk ||
dwc->dis_enblslpm_quirk) {
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(i));
reg |= DWC3_GUSB2PHYCFG_ENBLSLPM |
DWC3_GUSB2PHYCFG_SUSPHY;
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(i), reg);
}
/* Give some time for USB2 PHY to suspend */
usleep_range(5000, 6000);
}
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++)
phy_pm_runtime_put_sync(dwc->usb2_generic_phy[i]);
for (i = 0; i < dwc->num_usb3_ports; i++)
phy_pm_runtime_put_sync(dwc->usb3_generic_phy[i]);
break;
case DWC3_GCTL_PRTCAP_OTG:
/* do nothing during runtime_suspend */
if (PMSG_IS_AUTO(msg))
break;
if (dwc->current_otg_role == DWC3_OTG_ROLE_DEVICE) {
dwc3_gadget_suspend(dwc);
usb: dwc3: move synchronize_irq() out of the spinlock protected block dwc3_gadget_suspend() is called under dwc->lock spinlock. In such context calling synchronize_irq() is not allowed. Move the problematic call out of the protected block to fix the following kernel BUG during system suspend: BUG: sleeping function called from invalid context at kernel/irq/manage.c:112 in_atomic(): 1, irqs_disabled(): 128, pid: 1601, name: rtcwake 6 locks held by rtcwake/1601: #0: f70ac2a2 (sb_writers#7){.+.+}, at: vfs_write+0x130/0x16c #1: b5fe1270 (&of->mutex){+.+.}, at: kernfs_fop_write+0xc0/0x1e4 #2: 7e597705 (kn->count#60){.+.+}, at: kernfs_fop_write+0xc8/0x1e4 #3: 8b3527d0 (system_transition_mutex){+.+.}, at: pm_suspend+0xc4/0xc04 #4: fc7f1c42 (&dev->mutex){....}, at: __device_suspend+0xd8/0x74c #5: 4b36507e (&(&dwc->lock)->rlock){....}, at: dwc3_gadget_suspend+0x24/0x3c irq event stamp: 11252 hardirqs last enabled at (11251): [<c09c54a4>] _raw_spin_unlock_irqrestore+0x6c/0x74 hardirqs last disabled at (11252): [<c09c4d44>] _raw_spin_lock_irqsave+0x1c/0x5c softirqs last enabled at (9744): [<c0102564>] __do_softirq+0x3a4/0x66c softirqs last disabled at (9737): [<c0128528>] irq_exit+0x140/0x168 Preemption disabled at: [<00000000>] (null) CPU: 7 PID: 1601 Comm: rtcwake Not tainted 5.0.0-rc3-next-20190122-00039-ga3f4ee4f8a52 #5252 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [<c01110f0>] (unwind_backtrace) from [<c010d120>] (show_stack+0x10/0x14) [<c010d120>] (show_stack) from [<c09a4d04>] (dump_stack+0x90/0xc8) [<c09a4d04>] (dump_stack) from [<c014c700>] (___might_sleep+0x22c/0x2c8) [<c014c700>] (___might_sleep) from [<c0189d68>] (synchronize_irq+0x28/0x84) [<c0189d68>] (synchronize_irq) from [<c05cbbf8>] (dwc3_gadget_suspend+0x34/0x3c) [<c05cbbf8>] (dwc3_gadget_suspend) from [<c05bd020>] (dwc3_suspend_common+0x154/0x410) [<c05bd020>] (dwc3_suspend_common) from [<c05bd34c>] (dwc3_suspend+0x14/0x2c) [<c05bd34c>] (dwc3_suspend) from [<c051c730>] (platform_pm_suspend+0x2c/0x54) [<c051c730>] (platform_pm_suspend) from [<c05285d4>] (dpm_run_callback+0xa4/0x3dc) [<c05285d4>] (dpm_run_callback) from [<c0528a40>] (__device_suspend+0x134/0x74c) [<c0528a40>] (__device_suspend) from [<c052c508>] (dpm_suspend+0x174/0x588) [<c052c508>] (dpm_suspend) from [<c0182134>] (suspend_devices_and_enter+0xc0/0xe74) [<c0182134>] (suspend_devices_and_enter) from [<c0183658>] (pm_suspend+0x770/0xc04) [<c0183658>] (pm_suspend) from [<c0180ddc>] (state_store+0x6c/0xcc) [<c0180ddc>] (state_store) from [<c09a9a70>] (kobj_attr_store+0x14/0x20) [<c09a9a70>] (kobj_attr_store) from [<c02d6800>] (sysfs_kf_write+0x4c/0x50) [<c02d6800>] (sysfs_kf_write) from [<c02d594c>] (kernfs_fop_write+0xfc/0x1e4) [<c02d594c>] (kernfs_fop_write) from [<c02593d8>] (__vfs_write+0x2c/0x160) [<c02593d8>] (__vfs_write) from [<c0259694>] (vfs_write+0xa4/0x16c) [<c0259694>] (vfs_write) from [<c0259870>] (ksys_write+0x40/0x8c) [<c0259870>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Exception stack(0xed55ffa8 to 0xed55fff0) ... Fixes: 01c10880d242 ("usb: dwc3: gadget: synchronize_irq dwc irq in suspend") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2019-03-27 09:56:08 +00:00
synchronize_irq(dwc->irq_gadget);
}
dwc3_otg_exit(dwc);
dwc3_core_exit(dwc);
break;
default:
/* do nothing */
break;
}
return 0;
}
static int dwc3_resume_common(struct dwc3 *dwc, pm_message_t msg)
{
int ret;
u32 reg;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
int i;
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_DEVICE:
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
ret = dwc3_core_init_for_resume(dwc);
if (ret)
return ret;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
dwc3_gadget_resume(dwc);
break;
case DWC3_GCTL_PRTCAP_HOST:
if (!PMSG_IS_AUTO(msg) && !device_may_wakeup(dwc->dev)) {
usb: dwc3: support clocks and resets for DWC3 core Historically, the clocks and resets are handled on the glue layer side instead of the DWC3 core. For simple cases, dwc3-of-simple.c takes care of arbitrary number of clocks and resets. The DT node structure typically looks like as follows: dwc3-glue { compatible = "foo,dwc3"; clocks = ...; resets = ...; ... dwc3 { compatible = "snps,dwc3"; ... }; } By supporting the clocks and the reset in the dwc3/core.c, it will be turned into a single node: dwc3 { compatible = "foo,dwc3", "snps,dwc3"; clocks = ...; resets = ...; ... } This commit adds the binding of clocks and resets specific to this IP. The number of clocks should generally be the same across SoCs, it is just some SoCs either tie clocks together or do not provide software control of some of the clocks. I took the clock names from the Synopsys datasheet: "ref" (ref_clk), "bus_early" (bus_clk_early), and "suspend" (suspend_clk). I found only one reset line in the datasheet, hence the reset-names property is omitted. Those clocks are required for new platforms. Enforcing the new binding breaks existing platforms since they specify clocks (and resets) in their glue layer node, but nothing in the core node. I listed such exceptional cases in the DT binding. The driver code has been relaxed to accept no clock. This change is based on the discussion [1]. I inserted reset_control_deassert() and clk_bulk_enable() before the first register access, i.e. dwc3_cache_hwparams(). [1] https://patchwork.kernel.org/patch/10284265/ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
2018-05-16 02:41:07 +00:00
ret = dwc3_core_init_for_resume(dwc);
if (ret)
return ret;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
break;
}
/* Restore GUSB2PHYCFG bits that were modified in suspend */
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++) {
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(i));
if (dwc->dis_u2_susphy_quirk)
reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
if (dwc->dis_enblslpm_quirk)
reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(i), reg);
}
usb: dwc3: core: Refactor PHY logic to support Multiport Controller JIRA: https://issues.redhat.com/browse/RHEL-59050 Conflicts: * Considering upstream merge conflict seen on commit <adeab5bfb818> ("Merge 6.9-rc7 into usb-next") for dwc3_ss_phy_setup(), as well as already applied commit <6d735722063a> ("usb: dwc3: core: Prevent phy suspend during init") for dwc3_core_init() when hw_mode equals to DWC3_GHWPARAMS0_MODE_DRD, and finally, the context change on dwc3_hs_phy_setup() commit 30a46746ca5a1ef4dad3ea72be4fd01872f89ac2 Author: Krishna Kurapati <quic_kriskura@quicinc.com> Date: Sat, 20 Apr 2024 10:18:56 +0530 Currently the DWC3 driver supports only single port controller which requires at least one HS PHY and at most one SS PHY. But the DWC3 USB controller can be connected to multiple ports and each port can have their own PHYs. Each port of the multiport controller can either be HS+SS capable or HS only capable Proper quantification of them is required to modify GUSB2PHYCFG and GUSB3PIPECTL registers appropriately. DWC3 multiport controllers are capable to service at most 15 High Speed PHYs and 4 Supser Speed PHYs. Add support for detecting, obtaining and configuring PHYs supported by a multiport controller. Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240420044901.884098-5-quic_kriskura@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-10-05 03:59:05 +00:00
for (i = 0; i < dwc->num_usb2_ports; i++)
phy_pm_runtime_get_sync(dwc->usb2_generic_phy[i]);
for (i = 0; i < dwc->num_usb3_ports; i++)
phy_pm_runtime_get_sync(dwc->usb3_generic_phy[i]);
break;
case DWC3_GCTL_PRTCAP_OTG:
/* nothing to do on runtime_resume */
if (PMSG_IS_AUTO(msg))
break;
ret = dwc3_core_init_for_resume(dwc);
if (ret)
return ret;
dwc3_set_prtcap(dwc, dwc->current_dr_role);
dwc3_otg_init(dwc);
if (dwc->current_otg_role == DWC3_OTG_ROLE_HOST) {
dwc3_otg_host_init(dwc);
} else if (dwc->current_otg_role == DWC3_OTG_ROLE_DEVICE) {
dwc3_gadget_resume(dwc);
}
break;
default:
/* do nothing */
break;
}
usb: dwc3: core: Fix system suspend on TI AM62 platforms JIRA: https://issues.redhat.com/browse/RHEL-59052 commit 705e3ce37bccdf2ed6f848356ff355f480d51a91 Author: Roger Quadros <rogerq@kernel.org> Date: Fri, 11 Oct 2024 13:53:24 +0300 Since commit 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init"), system suspend is broken on AM62 TI platforms. Before that commit, both DWC3_GUSB3PIPECTL_SUSPHY and DWC3_GUSB2PHYCFG_SUSPHY bits (hence forth called 2 SUSPHY bits) were being set during core initialization and even during core re-initialization after a system suspend/resume. These bits are required to be set for system suspend/resume to work correctly on AM62 platforms. Since that commit, the 2 SUSPHY bits are not set for DEVICE/OTG mode if gadget driver is not loaded and started. For Host mode, the 2 SUSPHY bits are set before the first system suspend but get cleared at system resume during core re-init and are never set again. This patch resovles these two issues by ensuring the 2 SUSPHY bits are set before system suspend and restored to the original state during system resume. Cc: stable@vger.kernel.org # v6.9+ Fixes: 6d735722063a ("usb: dwc3: core: Prevent phy suspend during init") Link: https://lore.kernel.org/all/1519dbe7-73b6-4afc-bfe3-23f4f75d772f@kernel.org/ Signed-off-by: Roger Quadros <rogerq@kernel.org> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Tested-by: Markus Schneider-Pargmann <msp@baylibre.com> Reviewed-by: Dhruva Gole <d-gole@ti.com> Link: https://lore.kernel.org/r/20241011-am62-lpm-usb-v3-1-562d445625b5@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Desnes Nunes <desnesn@redhat.com>
2024-11-28 19:54:06 +00:00
if (!PMSG_IS_AUTO(msg)) {
/* restore SUSPHY state to that before system suspend. */
dwc3_enable_susphy(dwc, dwc->susphy_state);
}
return 0;
}
static int dwc3_runtime_checks(struct dwc3 *dwc)
{
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_DEVICE:
if (dwc->connected)
return -EBUSY;
break;
case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
}
return 0;
}
static int dwc3_runtime_suspend(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
int ret;
if (dwc3_runtime_checks(dwc))
return -EBUSY;
ret = dwc3_suspend_common(dwc, PMSG_AUTO_SUSPEND);
if (ret)
return ret;
return 0;
}
static int dwc3_runtime_resume(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
int ret;
ret = dwc3_resume_common(dwc, PMSG_AUTO_RESUME);
if (ret)
return ret;
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_DEVICE:
if (dwc->pending_events) {
pm_runtime_put(dwc->dev);
dwc->pending_events = false;
enable_irq(dwc->irq_gadget);
}
break;
case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
}
pm_runtime_mark_last_busy(dev);
return 0;
}
static int dwc3_runtime_idle(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_DEVICE:
if (dwc3_runtime_checks(dwc))
return -EBUSY;
break;
case DWC3_GCTL_PRTCAP_HOST:
default:
/* do nothing */
break;
}
pm_runtime_mark_last_busy(dev);
pm_runtime_autosuspend(dev);
return 0;
}
#endif /* CONFIG_PM */
#ifdef CONFIG_PM_SLEEP
static int dwc3_suspend(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
int ret;
ret = dwc3_suspend_common(dwc, PMSG_SUSPEND);
if (ret)
return ret;
pinctrl_pm_select_sleep_state(dev);
return 0;
}
static int dwc3_resume(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
int ret = 0;
pinctrl_pm_select_default_state(dev);
pm_runtime_disable(dev);
pm_runtime_set_active(dev);
ret = dwc3_resume_common(dwc, PMSG_RESUME);
if (ret)
pm_runtime_set_suspended(dev);
pm_runtime_enable(dev);
return ret;
}
static void dwc3_complete(struct device *dev)
{
struct dwc3 *dwc = dev_get_drvdata(dev);
u32 reg;
if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST &&
dwc->dis_split_quirk) {
reg = dwc3_readl(dwc->regs, DWC3_GUCTL3);
reg |= DWC3_GUCTL3_SPLITDISABLE;
dwc3_writel(dwc->regs, DWC3_GUCTL3, reg);
}
}
#else
#define dwc3_complete NULL
#endif /* CONFIG_PM_SLEEP */
static const struct dev_pm_ops dwc3_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
.complete = dwc3_complete,
/*
* Runtime suspend halts the controller on disconnection. It relies on
* platforms with custom connection notification to start the controller
* again.
*/
SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
dwc3_runtime_idle)
};
#ifdef CONFIG_OF
static const struct of_device_id of_dwc3_match[] = {
{
.compatible = "snps,dwc3"
},
{
.compatible = "synopsys,dwc3"
},
{ },
};
MODULE_DEVICE_TABLE(of, of_dwc3_match);
#endif
#ifdef CONFIG_ACPI
#define ACPI_ID_INTEL_BSW "808622B7"
static const struct acpi_device_id dwc3_acpi_match[] = {
{ ACPI_ID_INTEL_BSW, 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
#endif
static struct platform_driver dwc3_driver = {
.probe = dwc3_probe,
.remove_new = dwc3_remove,
.driver = {
.name = "dwc3",
.of_match_table = of_match_ptr(of_dwc3_match),
.acpi_match_table = ACPI_PTR(dwc3_acpi_match),
.pm = &dwc3_dev_pm_ops,
},
};
module_platform_driver(dwc3_driver);
MODULE_ALIAS("platform:dwc3");
MODULE_AUTHOR("Felipe Balbi <balbi@ti.com>");
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("DesignWare USB3 DRD Controller Driver");