[RFC PATCH 3/4] usb: dwc3: add quirk to be compatible for AMD NL

[Huang Rui]

This patch add a quirk to be compatible for AMD NL SoC

Some specific behaviors on NL:
- configure USB3 PIPE registers
- enable GCTL disscramble
- enable U2EXIT_LFPS
- enable hibernation at the global level
- set LPM errata dissabled

Signed-off-by: Huang Rui <ray.huang-***@public.gmane.org>
---
drivers/usb/dwc3/core.c | 33 ++++++++++++++++++++++++++++++++-
drivers/usb/dwc3/core.h | 5 +++++
drivers/usb/dwc3/dwc3-pci.c | 14 ++++++++++++++
drivers/usb/dwc3/gadget.c | 8 ++++++++
drivers/usb/dwc3/platform_data.h | 1 +
5 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}

/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ * @dwc: Pointer to our controller context structure
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;
+
+ reg |= DWC3_GUSB3PIPECTL_DEP1P2P3(1) | DWC3_GUSB3PIPECTL_TX_DEEPH(1);
+
+ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+
+ mdelay(100);
+}
+
+/**
* dwc3_free_one_event_buffer - Frees one event buffer
* @dwc: Pointer to our controller context structure
* @evt: Pointer to event buffer to be freed
@@ -412,9 +431,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err0;

+ if (dwc->quirks & DWC3_AMD_NL_PLAT)
+ dwc3_core_nl_set_pipe3(dwc);
+
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
- reg &= ~DWC3_GCTL_DISSCRAMBLE;
+
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg |= DWC3_GCTL_DISSCRAMBLE;
+ reg |= DWC3_GCTL_U2EXIT_LFPS;
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;
+ } else
+ reg &= ~DWC3_GCTL_DISSCRAMBLE;

switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc->hwparams.hwparams1)) {
case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
@@ -695,6 +724,8 @@ static int dwc3_probe(struct platform_device *pdev)

dwc->needs_fifo_resize = pdata->tx_fifo_resize;
dwc->dr_mode = pdata->dr_mode;
+
+ dwc->quirks = pdata->quirks;
}

/* default to superspeed if no maximum_speed passed */
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index ccde369..a1c7dc5 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -642,6 +642,7 @@ struct dwc3_scratchpad_array {
* @u1u2: only used on revisions <1.83a for workaround
* @maximum_speed: maximum speed requested (mainly for testing purposes)
* @revision: revision register contents
+ * @quirks: represents different SOCs hardware work-arounds and quirks
* @dr_mode: requested mode of operation
* @usb2_phy: pointer to USB2 PHY
* @usb3_phy: pointer to USB3 PHY
@@ -745,6 +746,10 @@ struct dwc3 {
#define DWC3_REVISION_270A 0x5533270a
#define DWC3_REVISION_280A 0x5533280a

+ u32 quirks;
+
+#define DWC3_AMD_NL_PLAT (1 << 0)
+
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
enum dwc3_link_state link_state;
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index cebbd01..7f471ff 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -25,6 +25,9 @@
#include <linux/usb/otg.h>
#include <linux/usb/usb_phy_generic.h>

+#include "platform_data.h"
+#include "core.h"
+
/* FIXME define these in <linux/pci_ids.h> */
#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 0xabcd
@@ -102,6 +105,9 @@ static int dwc3_pci_probe(struct pci_dev *pci,
struct dwc3_pci *glue;
int ret;
struct device *dev = &pci->dev;
+ struct dwc3_platform_data dwc3_pdata;
+
+ memset(&dwc3_pdata, 0x00, sizeof(dwc3_pdata));

glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -148,6 +154,14 @@ static int dwc3_pci_probe(struct pci_dev *pci,

pci_set_drvdata(pci, glue);

+ if (pci->vendor == PCI_VENDOR_ID_AMD &&
+ pci->device == PCI_DEVICE_ID_AMD_NL)
+ dwc3_pdata.quirks |= DWC3_AMD_NL_PLAT;
+
+ ret = platform_device_add_data(dwc3, &dwc3_pdata, sizeof(dwc3_pdata));
+ if (ret)
+ goto err3;
+
dma_set_coherent_mask(&dwc3->dev, dev->coherent_dma_mask);

dwc3->dev.dma_mask = dev->dma_mask;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;

dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;

+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ } else
+ reg = 0;
+
ret = usb_add_gadget_udc(dwc->dev, &dwc->gadget);
if (ret) {
dev_err(dwc->dev, "failed to register udc\n");
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index 7db34f0..b0ef7fa 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,5 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+ u32 quirks;
};

[Huang Rui]

This patch adds some undefined register macros on DWC3 spec 2.80a, these macros
will be used on AMD NL specific configuration.

Signed-off-by: Huang Rui <ray.huang-***@public.gmane.org>
---
drivers/usb/dwc3/core.h | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 66f6256..ccde369 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -166,6 +166,7 @@
#define DWC3_GCTL_SCALEDOWN(n) ((n) << 4)
#define DWC3_GCTL_SCALEDOWN_MASK DWC3_GCTL_SCALEDOWN(3)
#define DWC3_GCTL_DISSCRAMBLE (1 << 3)
+#define DWC3_GCTL_U2EXIT_LFPS (1 << 2)
#define DWC3_GCTL_GBLHIBERNATIONEN (1 << 1)
#define DWC3_GCTL_DSBLCLKGTNG (1 << 0)

@@ -175,7 +176,14 @@

/* Global USB3 PIPE Control Register */
#define DWC3_GUSB3PIPECTL_PHYSOFTRST (1 << 31)
+#define DWC3_GUSB3PIPECTL_U2SSINP3OK (1 << 29)
+#define DWC3_GUSB3PIPECTL_UX_EXITINPX (1 << 27)
+#define DWC3_GUSB3PIPECTL_U1U2EXITFAIL (1 << 25)
+#define DWC3_GUSB3PIPECTL_DEP1P2P3(n) ((n) << 19)
+#define DWC3_GUSB3PIPECTL_DEPOCHANGE (1 << 18)
#define DWC3_GUSB3PIPECTL_SUSPHY (1 << 17)
+#define DWC3_GUSB3PIPECTL_RX_DETOPOLL (1 << 8)
+#define DWC3_GUSB3PIPECTL_TX_DEEPH(n) ((n) << 1)

/* Global TX Fifo Size Register */
#define DWC3_GTXFIFOSIZ_TXFDEF(n) ((n) & 0xffff)
@@ -243,6 +251,7 @@
#define DWC3_DCTL_TRGTULST_SS_INACT (DWC3_DCTL_TRGTULST(6))

/* These apply for core versions 1.94a and later */
+#define DWC3_DCTL_LPM_ERRATA(n) ((n) << 20)
#define DWC3_DCTL_KEEP_CONNECT (1 << 19)
#define DWC3_DCTL_L1_HIBER_EN (1 << 18)
#define DWC3_DCTL_CRS (1 << 17)

[Huang Rui]

This patch implemented a feature to dynamic switch to host or device role under
debugfs for some physical limitation that unable to leverage connector A/B
cables (ID pin) to change roles.

The default role should be set as OTG mode. Then use below commands:

[1] switch to host:
echo host > /sys/kernel/debug/dwc3.0.auto/mode

[2] switch to device:
echo device > /sys/kernel/debug/dwc3.0.auto/mode

[3] switch to otg (default mode):
echo otg > /sys/kernel/debug/dwc3.0.auto/mode

Signed-off-by: Huang Rui <ray.huang-***@public.gmane.org>
---
drivers/usb/dwc3/Makefile | 2 +-
drivers/usb/dwc3/core.c | 4 +-
drivers/usb/dwc3/core.h | 6 ++
drivers/usb/dwc3/debugfs.c | 19 ++++--
drivers/usb/dwc3/drd.c | 163 +++++++++++++++++++++++++++++++++++++++++++++
drivers/usb/dwc3/drd.h | 30 +++++++++
drivers/usb/dwc3/gadget.c | 92 ++++++++++++++++---------
drivers/usb/dwc3/gadget.h | 3 +
drivers/usb/dwc3/host.c | 2 +
9 files changed, 280 insertions(+), 41 deletions(-)
create mode 100644 drivers/usb/dwc3/drd.c
create mode 100644 drivers/usb/dwc3/drd.h

diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index bb34fbc..115bbc7 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -13,7 +13,7 @@ ifneq ($(filter y,$(CONFIG_USB_DWC3_HOST) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
endif

ifneq ($(filter y,$(CONFIG_USB_DWC3_GADGET) $(CONFIG_USB_DWC3_DUAL_ROLE)),)
- dwc3-y += gadget.o ep0.o
+ dwc3-y += gadget.o ep0.o drd.o
endif

ifneq ($(CONFIG_DEBUG_FS),)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6138c5d..7b50584 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -61,7 +61,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
* @dwc: pointer to our context structure
*/
-static int dwc3_core_soft_reset(struct dwc3 *dwc)
+int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32 reg;
int ret;
@@ -228,7 +228,7 @@ static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)
*
* Returns 0 on success otherwise negative errno.
*/
-static int dwc3_event_buffers_setup(struct dwc3 *dwc)
+int dwc3_event_buffers_setup(struct dwc3 *dwc)
{
struct dwc3_event_buffer *evt;
int n;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index a1c7dc5..3a30f33 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -643,6 +643,8 @@ struct dwc3_scratchpad_array {
* @maximum_speed: maximum speed requested (mainly for testing purposes)
* @revision: revision register contents
* @quirks: represents different SOCs hardware work-arounds and quirks
+ * @has_gadget: true when gadget is initialized
+ * @has_xhci: true when xhci is initialized
* @dr_mode: requested mode of operation
* @usb2_phy: pointer to USB2 PHY
* @usb3_phy: pointer to USB3 PHY
@@ -750,6 +752,8 @@ struct dwc3 {

#define DWC3_AMD_NL_PLAT (1 << 0)

+ bool has_gadget;
+ bool has_xhci;
enum dwc3_ep0_next ep0_next_event;
enum dwc3_ep0_state ep0state;
enum dwc3_link_state link_state;
@@ -935,6 +939,8 @@ struct dwc3_gadget_ep_cmd_params {
/* prototypes */
void dwc3_set_mode(struct dwc3 *dwc, u32 mode);
int dwc3_gadget_resize_tx_fifos(struct dwc3 *dwc);
+int dwc3_core_soft_reset(struct dwc3 *dwc);
+int dwc3_event_buffers_setup(struct dwc3 *dwc);

#if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
int dwc3_host_init(struct dwc3 *dwc);
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..76384df 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -32,6 +32,7 @@
#include "gadget.h"
#include "io.h"
#include "debug.h"
+#include "drd.h"

#define dump_register(nm) \
{ \
@@ -394,7 +395,6 @@ static ssize_t dwc3_mode_write(struct file *file,
{
struct seq_file *s = file->private_data;
struct dwc3 *dwc = s->private;
- unsigned long flags;
u32 mode = 0;
char buf[32];

@@ -410,10 +410,19 @@ static ssize_t dwc3_mode_write(struct file *file,
if (!strncmp(buf, "otg", 3))
mode |= DWC3_GCTL_PRTCAP_OTG;

- if (mode) {
- spin_lock_irqsave(&dwc->lock, flags);
- dwc3_set_mode(dwc, mode);
- spin_unlock_irqrestore(&dwc->lock, flags);
+ switch (mode) {
+ case DWC3_GCTL_PRTCAP_DEVICE:
+ dwc3_drd_to_device(dwc);
+ break;
+ case DWC3_GCTL_PRTCAP_HOST:
+ dwc3_drd_to_host(dwc);
+ break;
+ case DWC3_GCTL_PRTCAP_OTG:
+ dwc3_drd_to_otg(dwc);
+ break;
+ default:
+ /* Should never happen */
+ break;
}
return count;
}
diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
new file mode 100644
index 0000000..53d9a9eb
--- /dev/null
+++ b/drivers/usb/dwc3/drd.c
@@ -0,0 +1,163 @@
+/**
+ * drd.c - DesignWare USB3 DRD Controller Dual Role Switch Funciton File
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ *
+ * Author: Huang Rui <ray.huang-***@public.gmane.org>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#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/usb/ch9.h>
+#include <linux/usb/gadget.h>
+#include <linux/usb/composite.h>
+
+#include "core.h"
+#include "gadget.h"
+#include "io.h"
+#include "drd.h"
+
+
+int dwc3_drd_to_host(struct dwc3 *dwc)
+{
+ int ret;
+ unsigned long flags = 0;
+
+ if (dwc->has_xhci)
+ dwc3_host_exit(dwc);
+ if (dwc->has_gadget)
+ dwc3_gadget_stop_on_switch(dwc);
+
+ ret = dwc3_core_soft_reset(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "soft reset failed\n");
+ goto err0;
+ }
+
+ spin_lock_irqsave(&dwc->lock, flags);
+ ret = dwc3_event_buffers_setup(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to setup event buffers\n");
+ goto err0;
+ }
+
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_HOST);
+
+ ret = dwc3_host_init(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to init host\n");
+ goto err0;
+ }
+err0:
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ return ret;
+}
+
+int dwc3_drd_to_device(struct dwc3 *dwc)
+{
+ int ret;
+ unsigned long timeout, flags = 0;
+ u32 reg;
+
+ if (dwc->has_xhci)
+ dwc3_host_exit(dwc);
+ if (dwc->has_gadget)
+ dwc3_gadget_stop_on_switch(dwc);
+
+ ret = dwc3_core_soft_reset(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "soft reset failed\n");
+ goto err0;
+ }
+
+ spin_lock_irqsave(&dwc->lock, flags);
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_DEVICE);
+
+ /* issue device SoftReset too */
+ timeout = jiffies + msecs_to_jiffies(500);
+ dwc3_writel(dwc->regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
+ do {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ if (!(reg & DWC3_DCTL_CSFTRST))
+ break;
+
+ if (time_after(jiffies, timeout)) {
+ dev_err(dwc->dev, "Reset Timed Out\n");
+ ret = -ETIMEDOUT;
+ goto err0;
+ }
+
+ cpu_relax();
+ } while (true);
+
+ ret = dwc3_event_buffers_setup(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to setup event buffers\n");
+ goto err0;
+ }
+
+ ret = dwc3_gadget_restart(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to restart gadget\n");
+ goto err0;
+ }
+err0:
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ return ret;
+}
+
+int dwc3_drd_to_otg(struct dwc3 *dwc)
+{
+ int ret = 0;
+ unsigned long flags = 0;
+
+ if (dwc->has_xhci)
+ dwc3_host_exit(dwc);
+ if (dwc->has_gadget)
+ dwc3_gadget_stop_on_switch(dwc);
+
+ ret = dwc3_core_soft_reset(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "soft reset failed\n");
+ goto err0;
+ }
+
+ spin_lock_irqsave(&dwc->lock, flags);
+ ret = dwc3_event_buffers_setup(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to setup event buffers\n");
+ goto err0;
+ }
+
+ dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
+
+ ret = dwc3_host_init(dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to init host\n");
+ goto err0;
+ }
+
+err0:
+ spin_unlock_irqrestore(&dwc->lock, flags);
+ return ret;
+}
diff --git a/drivers/usb/dwc3/drd.h b/drivers/usb/dwc3/drd.h
new file mode 100644
index 0000000..14d4944
--- /dev/null
+++ b/drivers/usb/dwc3/drd.h
@@ -0,0 +1,30 @@
+/**
+ * drd.c - DesignWare USB3 DRD Controller Dual Role Switch Funciton Header
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ *
+ * Author: Huang Rui <ray.huang-***@public.gmane.org>
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __DRIVERS_USB_DWC3_DRD_H
+#define __DRIVERS_USB_DWC3_DRD_H
+
+#include "core.h"
+#include "gadget.h"
+#include "io.h"
+
+extern int dwc3_drd_to_host(struct dwc3 *dwc);
+extern int dwc3_drd_to_device(struct dwc3 *dwc);
+extern int dwc3_drd_to_otg(struct dwc3 *dwc);
+
+#endif /* __DRIVERS_USB_DWC3_CORE_H */
+
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8277065..84252f3 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1501,37 +1501,13 @@ static void dwc3_gadget_disable_irq(struct dwc3 *dwc)
static irqreturn_t dwc3_interrupt(int irq, void *_dwc);
static irqreturn_t dwc3_thread_interrupt(int irq, void *_dwc);

-static int dwc3_gadget_start(struct usb_gadget *g,
- struct usb_gadget_driver *driver)
+int dwc3_gadget_restart(struct dwc3 *dwc)
{
- struct dwc3 *dwc = gadget_to_dwc(g);
- struct dwc3_ep *dep;
- unsigned long flags;
int ret = 0;
- int irq;
u32 reg;
+ struct dwc3_ep *dep;

- irq = platform_get_irq(to_platform_device(dwc->dev), 0);
- ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
- IRQF_SHARED, "dwc3", dwc);
- if (ret) {
- dev_err(dwc->dev, "failed to request irq #%d --> %d\n",
- irq, ret);
- goto err0;
- }
-
- spin_lock_irqsave(&dwc->lock, flags);
-
- if (dwc->gadget_driver) {
- dev_err(dwc->dev, "%s is already bound to %s\n",
- dwc->gadget.name,
- dwc->gadget_driver->driver.name);
- ret = -EBUSY;
- goto err1;
- }
-
- dwc->gadget_driver = driver;
-
+ dwc->has_gadget = true;
reg = dwc3_readl(dwc->regs, DWC3_DCFG);
reg &= ~(DWC3_DCFG_SPEED_MASK);

@@ -1579,7 +1555,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
false);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
- goto err2;
+ goto err0;
}

dep = dwc->eps[1];
@@ -1587,7 +1563,7 @@ static int dwc3_gadget_start(struct usb_gadget *g,
false);
if (ret) {
dev_err(dwc->dev, "failed to enable %s\n", dep->name);
- goto err3;
+ goto err1;
}

/* begin to receive SETUP packets */
@@ -1596,16 +1572,54 @@ static int dwc3_gadget_start(struct usb_gadget *g,

dwc3_gadget_enable_irq(dwc);

- spin_unlock_irqrestore(&dwc->lock, flags);
-
return 0;

-err3:
+err1:
__dwc3_gadget_ep_disable(dwc->eps[0]);

-err2:
+err0:
dwc->gadget_driver = NULL;

+ return ret;
+}
+
+static int dwc3_gadget_start(struct usb_gadget *g,
+ struct usb_gadget_driver *driver)
+{
+ struct dwc3 *dwc = gadget_to_dwc(g);
+ unsigned long flags;
+ int ret = 0;
+ int irq;
+
+ irq = platform_get_irq(to_platform_device(dwc->dev), 0);
+ ret = request_threaded_irq(irq, dwc3_interrupt, dwc3_thread_interrupt,
+ IRQF_SHARED, "dwc3", dwc);
+ if (ret) {
+ dev_err(dwc->dev, "failed to request irq #%d --> %d\n",
+ irq, ret);
+ goto err0;
+ }
+
+ spin_lock_irqsave(&dwc->lock, flags);
+
+ if (dwc->gadget_driver) {
+ dev_err(dwc->dev, "%s is already bound to %s\n",
+ dwc->gadget.name,
+ dwc->gadget_driver->driver.name);
+ ret = -EBUSY;
+ goto err1;
+ }
+
+ dwc->gadget_driver = driver;
+
+ ret = dwc3_gadget_restart(dwc);
+ if (ret)
+ goto err1;
+
+ spin_unlock_irqrestore(&dwc->lock, flags);
+
+ return 0;
+
err1:
spin_unlock_irqrestore(&dwc->lock, flags);

@@ -1615,6 +1629,16 @@ err0:
return ret;
}

+
+int dwc3_gadget_stop_on_switch(struct dwc3 *dwc)
+{
+ dwc->has_gadget = false;
+ __dwc3_gadget_ep_disable(dwc->eps[0]);
+ __dwc3_gadget_ep_disable(dwc->eps[1]);
+
+ return 0;
+}
+
static int dwc3_gadget_stop(struct usb_gadget *g,
struct usb_gadget_driver *driver)
{
@@ -2669,6 +2693,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err3;
}

+ dwc->has_gadget = true;
dwc->gadget.ops = &dwc3_gadget_ops;
dwc->gadget.max_speed = USB_SPEED_SUPER;
dwc->gadget.speed = USB_SPEED_UNKNOWN;
@@ -2729,6 +2754,7 @@ err0:

void dwc3_gadget_exit(struct dwc3 *dwc)
{
+ dwc->has_gadget = false;
usb_del_gadget_udc(&dwc->gadget);

dwc3_gadget_free_endpoints(dwc);
diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
index 178ad89..b3f628a 100644
--- a/drivers/usb/dwc3/gadget.h
+++ b/drivers/usb/dwc3/gadget.h
@@ -103,4 +103,7 @@ static inline u32 dwc3_gadget_ep_get_transfer_index(struct dwc3 *dwc, u8 number)
return DWC3_DEPCMD_GET_RSC_IDX(res_id);
}

+int dwc3_gadget_restart(struct dwc3 *dwc);
+int dwc3_gadget_stop_on_switch(struct dwc3 *dwc);
+
#endif /* __DRIVERS_USB_DWC3_GADGET_H */
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..dc6d5f0 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -40,6 +40,7 @@ int dwc3_host_init(struct dwc3 *dwc)
xhci->dev.dma_parms = dwc->dev->dma_parms;

dwc->xhci = xhci;
+ dwc->has_xhci = true;

ret = platform_device_add_resources(xhci, dwc->xhci_resources,
DWC3_XHCI_RESOURCES_NUM);
@@ -77,5 +78,6 @@ err0:

void dwc3_host_exit(struct dwc3 *dwc)
{
+ dwc->has_xhci = false;
platform_device_unregister(dwc->xhci);
}

[Felipe Balbi]

Hi,

Post by Huang Rui
This patch implemented a feature to dynamic switch to host or device
role under debugfs for some physical limitation that unable to
leverage connector A/B cables (ID pin) to change roles.
echo host > /sys/kernel/debug/dwc3.0.auto/mode
echo device > /sys/kernel/debug/dwc3.0.auto/mode
echo otg > /sys/kernel/debug/dwc3.0.auto/mode

thanks, but not thanks. This is not how things should be done.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6138c5d..7b50584 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -61,7 +61,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
*/
-static int dwc3_core_soft_reset(struct dwc3 *dwc)
+int dwc3_core_soft_reset(struct dwc3 *dwc)

this should not be exposed.

Post by Huang Rui
@@ -228,7 +228,7 @@ static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)
*
* Returns 0 on success otherwise negative errno.
*/
-static int dwc3_event_buffers_setup(struct dwc3 *dwc)
+int dwc3_event_buffers_setup(struct dwc3 *dwc)

this should not be exposed.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index a1c7dc5..3a30f33 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -643,6 +643,8 @@ struct dwc3_scratchpad_array {

you shouldn't need these.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..76384df 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -32,6 +32,7 @@
#include "gadget.h"
#include "io.h"
#include "debug.h"
+#include "drd.h"

and debugfs is definitely *not* the way to get this going.

What you need here is something to talk to usbcore and udc-core and
orchestrate the mode change through usb_add_hcd()/usb_add_gadget_udc()
and their counterparts.

George Cherian is already working on a version of that.

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui
This patch implemented a feature to dynamic switch to host or device
role under debugfs for some physical limitation that unable to
leverage connector A/B cables (ID pin) to change roles.
echo host > /sys/kernel/debug/dwc3.0.auto/mode
echo device > /sys/kernel/debug/dwc3.0.auto/mode
echo otg > /sys/kernel/debug/dwc3.0.auto/mode

thanks, but not thanks. This is not how things should be done.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 6138c5d..7b50584 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -61,7 +61,7 @@ void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
*/
-static int dwc3_core_soft_reset(struct dwc3 *dwc)
+int dwc3_core_soft_reset(struct dwc3 *dwc)

this should not be exposed.

Post by Huang Rui
@@ -228,7 +228,7 @@ static int dwc3_alloc_event_buffers(struct dwc3 *dwc, unsigned length)
*
* Returns 0 on success otherwise negative errno.
*/
-static int dwc3_event_buffers_setup(struct dwc3 *dwc)
+int dwc3_event_buffers_setup(struct dwc3 *dwc)

this should not be exposed.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index a1c7dc5..3a30f33 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -643,6 +643,8 @@ struct dwc3_scratchpad_array {

you shouldn't need these.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
index 9ac37fe..76384df 100644
--- a/drivers/usb/dwc3/debugfs.c
+++ b/drivers/usb/dwc3/debugfs.c
@@ -32,6 +32,7 @@
#include "gadget.h"
#include "io.h"
#include "debug.h"
+#include "drd.h"

and debugfs is definitely *not* the way to get this going.
What you need here is something to talk to usbcore and udc-core and
orchestrate the mode change through usb_add_hcd()/usb_add_gadget_udc()
and their counterparts.
George Cherian is already working on a version of that.

I saw your tree have a dwc3-role-switch branch, is that you mentioned
here for the working.

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi
What you need here is something to talk to usbcore and udc-core and
orchestrate the mode change through usb_add_hcd()/usb_add_gadget_udc()
and their counterparts.
George Cherian is already working on a version of that.

I saw your tree have a dwc3-role-switch branch, is that you mentioned
here for the working.

unfortunately not, what George is working is not there yet :-s

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi
What you need here is something to talk to usbcore and udc-core and
orchestrate the mode change through usb_add_hcd()/usb_add_gadget_udc()
and their counterparts.
George Cherian is already working on a version of that.

I saw your tree have a dwc3-role-switch branch, is that you mentioned
here for the working.

unfortunately not, what George is working is not there yet :-s

So I will drop for this patch on V2, and focus on AMD NL support
patches submission firstly, is that OK?

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi
What you need here is something to talk to usbcore and udc-core and
orchestrate the mode change through usb_add_hcd()/usb_add_gadget_udc()
and their counterparts.
George Cherian is already working on a version of that.

I saw your tree have a dwc3-role-switch branch, is that you mentioned
here for the working.

unfortunately not, what George is working is not there yet :-s

So I will drop for this patch on V2, and focus on AMD NL support
patches submission firstly, is that OK?

yup, that's fine. Thanks

[Huang Rui]

Add PCI device ID of AMD NL.

Signed-off-by: Huang Rui <ray.huang-***@public.gmane.org>
---
drivers/usb/dwc3/dwc3-pci.c | 2 ++
1 file changed, 2 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 436fb08..cebbd01 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -30,6 +30,7 @@
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 0xabcd
#define PCI_DEVICE_ID_INTEL_BYT 0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
+#define PCI_DEVICE_ID_AMD_NL 0x7912

struct dwc3_pci {
struct device *dev;
@@ -183,6 +184,7 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
},
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL), },
{ } /* Terminating Entry */
};
MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);

[Felipe Balbi]

Post by Huang Rui
Add PCI device ID of AMD NL.
---
drivers/usb/dwc3/dwc3-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 436fb08..cebbd01 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -30,6 +30,7 @@
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 0xabcd
#define PCI_DEVICE_ID_INTEL_BYT 0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
+#define PCI_DEVICE_ID_AMD_NL 0x7912
struct dwc3_pci {
struct device *dev;
@@ -183,6 +184,7 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
},
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL), },

this patch causes a build breakage.

[Huang Rui]

Hi Felipe,

Post by Felipe Balbi

Post by Huang Rui
Add PCI device ID of AMD NL.
---
drivers/usb/dwc3/dwc3-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 436fb08..cebbd01 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -30,6 +30,7 @@
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 0xabcd
#define PCI_DEVICE_ID_INTEL_BYT 0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
+#define PCI_DEVICE_ID_AMD_NL 0x7912
struct dwc3_pci {
struct device *dev;
@@ -183,6 +184,7 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
},
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL), },

this patch causes a build breakage.

That's strange, I tested it once again in my side based on your "next"
branch and didn't find any build error. If I misunderstood your
meaning, please correct me. :)

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
Add PCI device ID of AMD NL.
---
drivers/usb/dwc3/dwc3-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 436fb08..cebbd01 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -30,6 +30,7 @@
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 0xabcd
#define PCI_DEVICE_ID_INTEL_BYT 0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
+#define PCI_DEVICE_ID_AMD_NL 0x7912
struct dwc3_pci {
struct device *dev;
@@ -183,6 +184,7 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
},
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL), },

this patch causes a build breakage.

That's strange, I tested it once again in my side based on your "next"
branch and didn't find any build error. If I misunderstood your
meaning, please correct me. :)

no, I just misread your patch. I'm sorry. I thought the PCI Device ID
was set to the quirk which was not defined here. I apologize, this patch
is 100% correct.

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
Add PCI device ID of AMD NL.
---
drivers/usb/dwc3/dwc3-pci.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 436fb08..cebbd01 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -30,6 +30,7 @@
#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3 0xabcd
#define PCI_DEVICE_ID_INTEL_BYT 0x0f37
#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
+#define PCI_DEVICE_ID_AMD_NL 0x7912
struct dwc3_pci {
struct device *dev;
@@ -183,6 +184,7 @@ static const struct pci_device_id dwc3_pci_id_table[] = {
},
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL), },

this patch causes a build breakage.

That's strange, I tested it once again in my side based on your "next"
branch and didn't find any build error. If I misunderstood your
meaning, please correct me. :)

no, I just misread your patch. I'm sorry. I thought the PCI Device ID
was set to the quirk which was not defined here. I apologize, this patch
is 100% correct.

It doesn't matter, thanks a lot to your kindly support. :)

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.

U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.

RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

Post by Huang Rui
+ reg |= DWC3_GUSB3PIPECTL_DEP1P2P3(1) | DWC3_GUSB3PIPECTL_TX_DEEPH(1);

DEP1P2P3 and DEP0CHANGE seem to be required only for faulty PHYs too, I
need to see an erratum.

Post by Huang Rui
+ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+
+ mdelay(100);
+}
+
+/**
* dwc3_free_one_event_buffer - Frees one event buffer
@@ -412,9 +431,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err0;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT)
+ dwc3_core_nl_set_pipe3(dwc);
+
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
- reg &= ~DWC3_GCTL_DISSCRAMBLE;
+
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg |= DWC3_GCTL_DISSCRAMBLE;

you're disabling scrambling ? What about EMI ? Why doesn't your device
work with scrambling ? I need to see an erratum before I can accept
this.

Post by Huang Rui
+ reg |= DWC3_GCTL_U2EXIT_LFPS;

hmm, seems like this bit was added due to a faulty host which was found.
I need to see an erratum before I can accept this.

Post by Huang Rui
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;

looks like this should always be set for all versions of the core
configured with hibernation.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index cebbd01..7f471ff 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -25,6 +25,9 @@
#include <linux/usb/otg.h>
#include <linux/usb/usb_phy_generic.h>
+#include "platform_data.h"
+#include "core.h"

you should never need to include "core.h", why are you including
"core.h" ???

Post by Huang Rui
@@ -102,6 +105,9 @@ static int dwc3_pci_probe(struct pci_dev *pci,
struct dwc3_pci *glue;
int ret;
struct device *dev = &pci->dev;
+ struct dwc3_platform_data dwc3_pdata;
+
+ memset(&dwc3_pdata, 0x00, sizeof(dwc3_pdata));
glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -148,6 +154,14 @@ static int dwc3_pci_probe(struct pci_dev *pci,
pci_set_drvdata(pci, glue);
+ if (pci->vendor == PCI_VENDOR_ID_AMD &&
+ pci->device == PCI_DEVICE_ID_AMD_NL)
+ dwc3_pdata.quirks |= DWC3_AMD_NL_PLAT;

this looks wrong. It looks like you need several quirk bits for each of
the workarounds you need. Having a single bit for "my device" is wrong
and if your next device fixes one or two of these errata, you'd still
have to introduce a new "my new device" bit, instead of just clearing
the ones which were fixed.

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.

Paul, can you comment ?

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Post by Felipe Balbi

Post by Huang Rui
+ reg |= DWC3_GUSB3PIPECTL_DEP1P2P3(1) | DWC3_GUSB3PIPECTL_TX_DEEPH(1);

DEP1P2P3 and DEP0CHANGE seem to be required only for faulty PHYs too, I
need to see an erratum.

Post by Huang Rui
+ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+
+ mdelay(100);
+}
+
+/**
* dwc3_free_one_event_buffer - Frees one event buffer
@@ -412,9 +431,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err0;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT)
+ dwc3_core_nl_set_pipe3(dwc);
+
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
- reg &= ~DWC3_GCTL_DISSCRAMBLE;
+
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg |= DWC3_GCTL_DISSCRAMBLE;

you're disabling scrambling ? What about EMI ? Why doesn't your device
work with scrambling ? I need to see an erratum before I can accept
this.

Sorry, disabling scrambling is workaround for debugging the temporary
simulation board, needn't be set for the SoC chip. Will update in v2.

Post by Felipe Balbi

Post by Huang Rui
+ reg |= DWC3_GCTL_U2EXIT_LFPS;

hmm, seems like this bit was added due to a faulty host which was found.
I need to see an erratum before I can accept this.

Post by Huang Rui
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;

looks like this should always be set for all versions of the core
configured with hibernation.

yes, amd nl chip will support hibernation.

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index cebbd01..7f471ff 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -25,6 +25,9 @@
#include <linux/usb/otg.h>
#include <linux/usb/usb_phy_generic.h>
+#include "platform_data.h"
+#include "core.h"

you should never need to include "core.h", why are you including
"core.h" ???

Because I defined DWC3_AMD_NL_PLAT in dwc3 struture at core.h. I think
this quirk might be included on most of the source files like core.c,
gadget.c. If I added into platform_data.h, it would make these source
files include "platform_data.h" either. So I add DWC3_AMD_NL_PLAT into
core.h.

So should I define DWC3_AMD_NL_PLAT and other QUIRKS at
platform_data.h or create a quirks.h file?

Post by Felipe Balbi

Post by Huang Rui
@@ -102,6 +105,9 @@ static int dwc3_pci_probe(struct pci_dev *pci,
struct dwc3_pci *glue;
int ret;
struct device *dev = &pci->dev;
+ struct dwc3_platform_data dwc3_pdata;
+
+ memset(&dwc3_pdata, 0x00, sizeof(dwc3_pdata));
glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -148,6 +154,14 @@ static int dwc3_pci_probe(struct pci_dev *pci,
pci_set_drvdata(pci, glue);
+ if (pci->vendor == PCI_VENDOR_ID_AMD &&
+ pci->device == PCI_DEVICE_ID_AMD_NL)
+ dwc3_pdata.quirks |= DWC3_AMD_NL_PLAT;

this looks wrong. It looks like you need several quirk bits for each of
the workarounds you need. Having a single bit for "my device" is wrong
and if your next device fixes one or two of these errata, you'd still
have to introduce a new "my new device" bit, instead of just clearing
the ones which were fixed.

I got it, so do you mean:
if I set "disabling scrambling" workaround, I should use a macro as
DWC3_DISSCRAMBING_QUIRK to present this specific setting. Then use the
Deivce ID to enable these kinds of the quirks I need, is that right?

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits are required by HW. I am asking them, will let you know
why.

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
example:

"
This bit is added for SS PHY workaround where SS PHY ...
"

It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.

Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches. Then, load g_mass_storage with a backing storage of your
choice and run my msc.c/msc.sh tools which you can get from [1] and [2];
post the logs for that too. Last, but not least, please USB30CV (chapter
9 and Link Layer test, at least) just so we know there isn't anything
new with your version of the core, which I suppose is 2.80a, based on
the LPM Errata bits.

This is just because I don't have access to the HW myself, so I can't
verify your patches. One thing I can tell you, with my testing/next,
dwc3 is really stable. I have every test passing except for Halt
Endpoint which I'm debugging right now.

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
+ reg |= DWC3_GUSB3PIPECTL_DEP1P2P3(1) | DWC3_GUSB3PIPECTL_TX_DEEPH(1);

DEP1P2P3 and DEP0CHANGE seem to be required only for faulty PHYs too, I
need to see an erratum.

Post by Huang Rui
+ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+
+ mdelay(100);
+}
+
+/**
* dwc3_free_one_event_buffer - Frees one event buffer
@@ -412,9 +431,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err0;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT)
+ dwc3_core_nl_set_pipe3(dwc);
+
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
- reg &= ~DWC3_GCTL_DISSCRAMBLE;
+
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg |= DWC3_GCTL_DISSCRAMBLE;

you're disabling scrambling ? What about EMI ? Why doesn't your device
work with scrambling ? I need to see an erratum before I can accept
this.

Sorry, disabling scrambling is workaround for debugging the temporary
simulation board, needn't be set for the SoC chip. Will update in v2.

oh, alright. Then let's not merge this in mainline. I guess I have an
idea which simulation board you're using :-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
+ reg |= DWC3_GCTL_U2EXIT_LFPS;

hmm, seems like this bit was added due to a faulty host which was found.
I need to see an erratum before I can accept this.

Post by Huang Rui
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;

looks like this should always be set for all versions of the core
configured with hibernation.

yes, amd nl chip will support hibernation.

in that case, we do this:

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..584dcde 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -449,6 +449,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
case DWC3_GHWPARAMS1_EN_PWROPT_HIB:
/* enable hibernation here */
dwc->nr_scratch = DWC3_GHWPARAMS4_HIBER_SCRATCHBUFS(hwparams4);
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;
break;
default:
dev_dbg(dwc->dev, "No power optimization available\n");

that'll work for everybody with hibernation enabled in coreConsultant.

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index cebbd01..7f471ff 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -25,6 +25,9 @@
#include <linux/usb/otg.h>
#include <linux/usb/usb_phy_generic.h>
+#include "platform_data.h"
+#include "core.h"

you should never need to include "core.h", why are you including
"core.h" ???

Because I defined DWC3_AMD_NL_PLAT in dwc3 struture at core.h. I think
this quirk might be included on most of the source files like core.c,
gadget.c. If I added into platform_data.h, it would make these source
files include "platform_data.h" either. So I add DWC3_AMD_NL_PLAT into
core.h.

but you're using a platform_data, right ? And you're passing the quirk
through platform data, right ? It just makes sense to define all that
inside platform_data.h :-)

Post by Huang Rui
So should I define DWC3_AMD_NL_PLAT and other QUIRKS at
platform_data.h or create a quirks.h file?

platform_data.h makes sense to me :-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
@@ -102,6 +105,9 @@ static int dwc3_pci_probe(struct pci_dev *pci,
struct dwc3_pci *glue;
int ret;
struct device *dev = &pci->dev;
+ struct dwc3_platform_data dwc3_pdata;
+
+ memset(&dwc3_pdata, 0x00, sizeof(dwc3_pdata));
glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -148,6 +154,14 @@ static int dwc3_pci_probe(struct pci_dev *pci,
pci_set_drvdata(pci, glue);
+ if (pci->vendor == PCI_VENDOR_ID_AMD &&
+ pci->device == PCI_DEVICE_ID_AMD_NL)
+ dwc3_pdata.quirks |= DWC3_AMD_NL_PLAT;

this looks wrong. It looks like you need several quirk bits for each of
the workarounds you need. Having a single bit for "my device" is wrong
and if your next device fixes one or two of these errata, you'd still
have to introduce a new "my new device" bit, instead of just clearing
the ones which were fixed.

if I set "disabling scrambling" workaround, I should use a macro as
DWC3_DISSCRAMBING_QUIRK to present this specific setting. Then use the
Deivce ID to enable these kinds of the quirks I need, is that right?

perfect :-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits are required by HW. I am asking them, will let you know
why.

Alright, thanks. What we need is a way for detecting that LPM Errata is
enabled, rather than checking if we're running on AMD :-) Aparently we
can only check for LPM Errata Enabled through an XHCI register; kinda
weird.

cheers and happy hacking

[1] https://gitorious.org/usb/usb-tools/source/7eb7ef21de6cd124e0e0d0e7df9ddfff0e2f548e:msc.c
[2] https://gitorious.org/usb/usb-tools/source/7eb7ef21de6cd124e0e0d0e7df9ddfff0e2f548e:msc.sh

[Felipe Balbi]

Hi,

Post by Felipe Balbi
This is just because I don't have access to the HW myself, so I can't
verify your patches. One thing I can tell you, with my testing/next,
dwc3 is really stable. I have every test passing except for Halt
Endpoint which I'm debugging right now.

alright, found the problem. I'll push to my testing/next in a bit.

[Huang Rui]

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.

For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Post by Felipe Balbi
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.

Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

Post by Felipe Balbi
Then, load g_mass_storage with a backing storage of your
choice and run my msc.c/msc.sh tools which you can get from [1] and [2];
post the logs for that too. Last, but not least, please USB30CV (chapter
9 and Link Layer test, at least) just so we know there isn't anything
new with your version of the core, which I suppose is 2.80a, based on
the LPM Errata bits.

OK, will post the logs to you.

Post by Felipe Balbi
This is just because I don't have access to the HW myself, so I can't
verify your patches. One thing I can tell you, with my testing/next,
dwc3 is really stable. I have every test passing except for Halt
Endpoint which I'm debugging right now.

OK, I got it. Will rebase my patches to testing/next.

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
+ reg |= DWC3_GUSB3PIPECTL_DEP1P2P3(1) | DWC3_GUSB3PIPECTL_TX_DEEPH(1);

DEP1P2P3 and DEP0CHANGE seem to be required only for faulty PHYs too, I
need to see an erratum.

Post by Huang Rui
+ dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
+
+ mdelay(100);
+}
+
+/**
* dwc3_free_one_event_buffer - Frees one event buffer
@@ -412,9 +431,19 @@ static int dwc3_core_init(struct dwc3 *dwc)
if (ret)
goto err0;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT)
+ dwc3_core_nl_set_pipe3(dwc);
+
reg = dwc3_readl(dwc->regs, DWC3_GCTL);
+
reg &= ~DWC3_GCTL_SCALEDOWN_MASK;
- reg &= ~DWC3_GCTL_DISSCRAMBLE;
+
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg |= DWC3_GCTL_DISSCRAMBLE;

you're disabling scrambling ? What about EMI ? Why doesn't your device
work with scrambling ? I need to see an erratum before I can accept
this.

Sorry, disabling scrambling is workaround for debugging the temporary
simulation board, needn't be set for the SoC chip. Will update in v2.

oh, alright. Then let's not merge this in mainline. I guess I have an
idea which simulation board you're using :-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
+ reg |= DWC3_GCTL_U2EXIT_LFPS;

hmm, seems like this bit was added due to a faulty host which was found.
I need to see an erratum before I can accept this.

Post by Huang Rui
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;

looks like this should always be set for all versions of the core
configured with hibernation.

yes, amd nl chip will support hibernation.

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..584dcde 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -449,6 +449,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
/* enable hibernation here */
dwc->nr_scratch = DWC3_GHWPARAMS4_HIBER_SCRATCHBUFS(hwparams4);
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;
break;
dev_dbg(dwc->dev, "No power optimization available\n");
that'll work for everybody with hibernation enabled in coreConsultant.

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index cebbd01..7f471ff 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -25,6 +25,9 @@
#include <linux/usb/otg.h>
#include <linux/usb/usb_phy_generic.h>
+#include "platform_data.h"
+#include "core.h"

you should never need to include "core.h", why are you including
"core.h" ???

Because I defined DWC3_AMD_NL_PLAT in dwc3 struture at core.h. I think
this quirk might be included on most of the source files like core.c,
gadget.c. If I added into platform_data.h, it would make these source
files include "platform_data.h" either. So I add DWC3_AMD_NL_PLAT into
core.h.

but you're using a platform_data, right ? And you're passing the quirk
through platform data, right ? It just makes sense to define all that
inside platform_data.h :-)

OK, I got it. Will update it in V2.

Post by Felipe Balbi

Post by Huang Rui
So should I define DWC3_AMD_NL_PLAT and other QUIRKS at
platform_data.h or create a quirks.h file?

platform_data.h makes sense to me :-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
@@ -102,6 +105,9 @@ static int dwc3_pci_probe(struct pci_dev *pci,
struct dwc3_pci *glue;
int ret;
struct device *dev = &pci->dev;
+ struct dwc3_platform_data dwc3_pdata;
+
+ memset(&dwc3_pdata, 0x00, sizeof(dwc3_pdata));
glue = devm_kzalloc(dev, sizeof(*glue), GFP_KERNEL);
if (!glue)
@@ -148,6 +154,14 @@ static int dwc3_pci_probe(struct pci_dev *pci,
pci_set_drvdata(pci, glue);
+ if (pci->vendor == PCI_VENDOR_ID_AMD &&
+ pci->device == PCI_DEVICE_ID_AMD_NL)
+ dwc3_pdata.quirks |= DWC3_AMD_NL_PLAT;

this looks wrong. It looks like you need several quirk bits for each of
the workarounds you need. Having a single bit for "my device" is wrong
and if your next device fixes one or two of these errata, you'd still
have to introduce a new "my new device" bit, instead of just clearing
the ones which were fixed.

if I set "disabling scrambling" workaround, I should use a macro as
DWC3_DISSCRAMBING_QUIRK to present this specific setting. Then use the
Deivce ID to enable these kinds of the quirks I need, is that right?

perfect :-)

Thanks.

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits are required by HW. I am asking them, will let you know
why.

Alright, thanks. What we need is a way for detecting that LPM Errata is
enabled, rather than checking if we're running on AMD :-) Aparently we
can only check for LPM Errata Enabled through an XHCI register; kinda
weird.
cheers and happy hacking
[1] https://gitorious.org/usb/usb-tools/source/7eb7ef21de6cd124e0e0d0e7df9ddfff0e2f548e:msc.c
[2] https://gitorious.org/usb/usb-tools/source/7eb7ef21de6cd124e0e0d0e7df9ddfff0e2f548e:msc.sh
--
balbi

Felipe, it's pleasure to leverage your dwc3 ip driver on AMD platform
for me. Thanks to support. :)

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.

Post by Huang Rui

Post by Felipe Balbi
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.

Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.

NOP is a perfectly valid use-case :-) We still want to know that version
x of AMD's PHY is quirky on these or that case :-)

Post by Huang Rui

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.

If you want, you can definitely defer a v2 until v3.18-rc1 is tagged.
I'll send a few fixes I have pending when that happens too. All my
latest fixes are on my testing/next branch, btw. I'll add Cc: stable to
most of them, but you might want to cherry-pick a few that I don't to
your vendor tree, if you have it.

Post by Huang Rui

Post by Felipe Balbi
Then, load g_mass_storage with a backing storage of your
choice and run my msc.c/msc.sh tools which you can get from [1] and [2];
post the logs for that too. Last, but not least, please USB30CV (chapter
9 and Link Layer test, at least) just so we know there isn't anything
new with your version of the core, which I suppose is 2.80a, based on
the LPM Errata bits.

OK, will post the logs to you.

thanks :-)

Post by Huang Rui

Post by Felipe Balbi
This is just because I don't have access to the HW myself, so I can't
verify your patches. One thing I can tell you, with my testing/next,
dwc3 is really stable. I have every test passing except for Halt
Endpoint which I'm debugging right now.

OK, I got it. Will rebase my patches to testing/next.

that'll help me, thanks

Post by Huang Rui
Felipe, it's pleasure to leverage your dwc3 ip driver on AMD platform
for me. Thanks to support. :)

hey, don't mention it. I'm happy to have several users on a single
driver. Everybody can benefit from fixes ;-)

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.

I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of "fpga". I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.

Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.

NOP is a perfectly valid use-case :-) We still want to know that version
x of AMD's PHY is quirky on these or that case :-)

I can use the SMBus revsion ID for different chips version of amd. You
can refer usb/host/pci-quirks.c, I already added the different chip
version macros there for xHC. If PHY version updates, the chip version
must update too.

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.

Yes, I am doing these testing.

An issue meet your msc.c.

***@hr-slim:~/felipe/usb-tools$ gcc -Wall -O2 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -o msc msc.c
/tmp/ccUBcDC4.o: In function `do_write':
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o: In function `do_read':
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o: In function `do_writev':
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined references to `clock_gettime' follow
collect2: ld returned 1 exit status

Any idea?

Post by Felipe Balbi
If you want, you can definitely defer a v2 until v3.18-rc1 is tagged.

Do you mean: when kernel upgrade to v3.18-rc1, then I rebase my
patches to testing branch (v3.18-rc1+) to send V2, is that right?

Post by Felipe Balbi
I'll send a few fixes I have pending when that happens too. All my
latest fixes are on my testing/next branch, btw. I'll add Cc: stable to
most of them, but you might want to cherry-pick a few that I don't to
your vendor tree, if you have it.

That's great. I expect to port to some LTS and late stable kernels
such as 3.10, 3.12, 3.14 and etc.

Thanks,
Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Then, load g_mass_storage with a backing storage of your
choice and run my msc.c/msc.sh tools which you can get from [1] and [2];
post the logs for that too. Last, but not least, please USB30CV (chapter
9 and Link Layer test, at least) just so we know there isn't anything
new with your version of the core, which I suppose is 2.80a, based on
the LPM Errata bits.

OK, will post the logs to you.

thanks :-)

Post by Huang Rui

Post by Felipe Balbi
This is just because I don't have access to the HW myself, so I can't
verify your patches. One thing I can tell you, with my testing/next,
dwc3 is really stable. I have every test passing except for Halt
Endpoint which I'm debugging right now.

OK, I got it. Will rebase my patches to testing/next.

that'll help me, thanks

Post by Huang Rui
Felipe, it's pleasure to leverage your dwc3 ip driver on AMD platform
for me. Thanks to support. :)

hey, don't mention it. I'm happy to have several users on a single
driver. Everybody can benefit from fixes ;-)
--
balbi

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.

I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of "fpga". I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).

while that's a nice idea, it wouldn't work for everybody; only AMD.

If there's no "generic" way implemented by Synopsys into the RTL, then
we better not add anything.

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.

Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.

NOP is a perfectly valid use-case :-) We still want to know that version
x of AMD's PHY is quirky on these or that case :-)

I can use the SMBus revsion ID for different chips version of amd. You
can refer usb/host/pci-quirks.c, I already added the different chip
version macros there for xHC. If PHY version updates, the chip version
must update too.

Please provide a patch and let's discuss :-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.

Yes, I am doing these testing.
An issue meet your msc.c.
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined references to `clock_gettime' follow
collect2: ld returned 1 exit status
Any idea?

builds fine here:

$ make clean
CLEAN clean
$ make
CC companion-desc.o
LINK companion-desc
CC testmode.o
LINK testmode
CC cleware.o
LINK cleware
CC control.o
LINK control
CC device-reset.o
LINK device-reset
CC msc.o
LINK msc
CC testusb.o
LINK testusb
CC serialc.o
LINK serialc
CC acmc.o
LINK acmc
CC switchbox.o
LINK switchbox
CC seriald.o
LINK seriald
CC acmd.o
LINK acmd

Perhaps something with the GCC version you're using ?

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)

Post by Huang Rui

Post by Felipe Balbi
If you want, you can definitely defer a v2 until v3.18-rc1 is tagged.

Do you mean: when kernel upgrade to v3.18-rc1, then I rebase my
patches to testing branch (v3.18-rc1+) to send V2, is that right?

that's correct. We're in the middle of the merge window and no patches
will be picked up anyway :-)

Post by Huang Rui

Post by Felipe Balbi
I'll send a few fixes I have pending when that happens too. All my
latest fixes are on my testing/next branch, btw. I'll add Cc: stable to
most of them, but you might want to cherry-pick a few that I don't to
your vendor tree, if you have it.

That's great. I expect to port to some LTS and late stable kernels
such as 3.10, 3.12, 3.14 and etc.

yeah, fixes which are marked with Cc: stable will be backported by the
stable team; if patches don't apply cleanly, Greg will ask me to
manually backport ;-)

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.

I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of "fpga". I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).

while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no "generic" way implemented by Synopsys into the RTL, then
we better not add anything.

Because the RTL is frozen.

I checked the spec again of GUID:

1) To store the version or revision of your system
2) To store hardware configurations that are outside the core
3) As a scratch register.

As 2) described, it also makes sence the store the HW configuration (FPGA
version) on this register.

Can we split the 32bit space to two 16bit area, one of them stores the HW
configuration, and the other stores the kernel version? I think other SOC
(especially x86-based) would use this method. :)

It looks like there isn't another register can program into the version info.

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
It's alright that AMD PHY needs this bit, but then, let's get
confirmation from IP/SoC/SilVal team and add a proper comment stating
why we need them. This is so we don't forget that $version of AMD's PHY
needs workarounds for A, B, and C silicon errata.

Yes, but currently, I needn't write AMD own phy driver. There isn't
any requirement from HW side to program the phy register. So I used
NOP USB transceiver driver till now.

NOP is a perfectly valid use-case :-) We still want to know that version
x of AMD's PHY is quirky on these or that case :-)

I can use the SMBus revsion ID for different chips version of amd. You
can refer usb/host/pci-quirks.c, I already added the different chip
version macros there for xHC. If PHY version updates, the chip version
must update too.

Please provide a patch and let's discuss :-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.

Yes, I am doing these testing.
An issue meet your msc.c.
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined references to `clock_gettime' follow
collect2: ld returned 1 exit status
Any idea?

$ make clean
CLEAN clean
$ make
CC companion-desc.o
LINK companion-desc
CC testmode.o
LINK testmode
CC cleware.o
LINK cleware
CC control.o
LINK control
CC device-reset.o
LINK device-reset
CC msc.o
LINK msc
CC testusb.o
LINK testusb
CC serialc.o
LINK serialc
CC acmc.o
LINK acmc
CC switchbox.o
LINK switchbox
CC seriald.o
LINK seriald
CC acmd.o
LINK acmd
Perhaps something with the GCC version you're using ?
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm

-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

Post by Felipe Balbi
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)

My gcc version is 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) before. After I
upgrade to gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1), then make the repo
again.

***@hr-ub:~/felipe/usb-tools$ make
LINK companion-desc
companion-desc.o: In function `main':
/home/ray/felipe/usb-tools/companion-desc.c:219: undefined reference to `libusb_init'
/home/ray/felipe/usb-tools/companion-desc.c:221: undefined reference to `libusb_open_device_with_vid_pid'
companion-desc.o: In function `do_test':
/home/ray/felipe/usb-tools/companion-desc.c:176: undefined reference to `libusb_get_device'
/home/ray/felipe/usb-tools/companion-desc.c:178: undefined reference to `libusb_get_device_descriptor'
companion-desc.o: In function `check_configurations':
/home/ray/felipe/usb-tools/companion-desc.c:153: undefined reference to `libusb_get_config_descriptor'
companion-desc.o: In function `main':
/home/ray/felipe/usb-tools/companion-desc.c:239: undefined reference to `libusb_close'
/home/ray/felipe/usb-tools/companion-desc.c:242: undefined reference to `libusb_exit'
companion-desc.o: In function `do_test':
/home/ray/felipe/usb-tools/companion-desc.c:163: undefined reference to `libusb_free_config_descriptor'
collect2: error: ld returned 1 exit status
make: *** [companion-desc] Error 1

It looks like libusb header is not found. My libusb version is below, can you
see which version of libusb in your side?

***@hr-ub:~$ dpkg -l | grep libusb
ii libgusb2:amd64 0.1.6-5
ii libusb-0.1-4:amd64 2:0.1.12-23.3ubuntu1
ii libusb-1.0-0:amd64 2:1.0.17-1ubuntu2
ii libusb-1.0-0-dbg:amd64 2:1.0.17-1ubuntu2
ii libusb-1.0-0-dev:amd64 2:1.0.17-1ubuntu2
ii libusb-1.0-doc 2:1.0.17-1ubuntu2
ii libusb-dev 2:0.1.12-23.3ubuntu1
ii libusbmuxd2 1.0.8-2ubuntu1


Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.

I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of "fpga". I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).

while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no "generic" way implemented by Synopsys into the RTL, then
we better not add anything.

Because the RTL is frozen.
1) To store the version or revision of your system
2) To store hardware configurations that are outside the core
3) As a scratch register.
As 2) described, it also makes sence the store the HW configuration (FPGA
version) on this register.
Can we split the 32bit space to two 16bit area, one of them stores the HW
configuration, and the other stores the kernel version? I think other SOC
(especially x86-based) would use this method. :)
It looks like there isn't another register can program into the version info.

the problem is that we won't have something that will work for
everybody. Note that the register can be used as scratch register as
well and there's really no way we will be able to get every RTL designer
in every company out there who's licensing this core to agree on using
this register the exact same way.

Unless it ships already built into the RTL Synopsys delivers, there's
no way we can use it in the core dwc3 driver ;-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.

Yes, I am doing these testing.
An issue meet your msc.c.
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined references to `clock_gettime' follow
collect2: ld returned 1 exit status
Any idea?

$ make clean
CLEAN clean
$ make
CC companion-desc.o
LINK companion-desc
CC testmode.o
LINK testmode
CC cleware.o
LINK cleware
CC control.o
LINK control
CC device-reset.o
LINK device-reset
CC msc.o
LINK msc
CC testusb.o
LINK testusb
CC serialc.o
LINK serialc
CC acmc.o
LINK acmc
CC switchbox.o
LINK switchbox
CC seriald.o
LINK seriald
CC acmd.o
LINK acmd
Perhaps something with the GCC version you're using ?
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)

My gcc version is 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) before. After I
upgrade to gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1), then make the repo
again.
LINK companion-desc
/home/ray/felipe/usb-tools/companion-desc.c:219: undefined reference to `libusb_init'
/home/ray/felipe/usb-tools/companion-desc.c:221: undefined reference to `libusb_open_device_with_vid_pid'
/home/ray/felipe/usb-tools/companion-desc.c:176: undefined reference to `libusb_get_device'
/home/ray/felipe/usb-tools/companion-desc.c:178: undefined reference to `libusb_get_device_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:153: undefined reference to `libusb_get_config_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:239: undefined reference to `libusb_close'
/home/ray/felipe/usb-tools/companion-desc.c:242: undefined reference to `libusb_exit'
/home/ray/felipe/usb-tools/companion-desc.c:163: undefined reference to `libusb_free_config_descriptor'
collect2: error: ld returned 1 exit status
make: *** [companion-desc] Error 1
It looks like libusb header is not found. My libusb version is below, can you
see which version of libusb in your side?

hmmm, which gcc version are you using ? It could be that some linker
versions a bit more pedantic about the order of where you pass linker
flags, dunno.

I'll google it tomorrow and see if I can find anything.

Post by Huang Rui
ii libgusb2:amd64 0.1.6-5
ii libusb-0.1-4:amd64 2:0.1.12-23.3ubuntu1
ii libusb-1.0-0:amd64 2:1.0.17-1ubuntu2
ii libusb-1.0-0-dbg:amd64 2:1.0.17-1ubuntu2
ii libusb-1.0-0-dev:amd64 2:1.0.17-1ubuntu2
ii libusb-1.0-doc 2:1.0.17-1ubuntu2
ii libusb-dev 2:0.1.12-23.3ubuntu1

my tools are libusb1.0 only, not libusb-0.1. But you have both
libraries, it should work.

[Felipe Balbi]

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.

I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of "fpga". I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).

while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no "generic" way implemented by Synopsys into the RTL, then
we better not add anything.

Because the RTL is frozen.
1) To store the version or revision of your system
2) To store hardware configurations that are outside the core
3) As a scratch register.
As 2) described, it also makes sence the store the HW configuration (FPGA
version) on this register.
Can we split the 32bit space to two 16bit area, one of them stores the HW
configuration, and the other stores the kernel version? I think other SOC
(especially x86-based) would use this method. :)
It looks like there isn't another register can program into the version info.

the problem is that we won't have something that will work for
everybody. Note that the register can be used as scratch register as
well and there's really no way we will be able to get every RTL designer
in every company out there who's licensing this core to agree on using
this register the exact same way.
Unless it ships already built into the RTL Synopsys delivers, there's
no way we can use it in the core dwc3 driver ;-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.

Yes, I am doing these testing.
An issue meet your msc.c.
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined references to `clock_gettime' follow
collect2: ld returned 1 exit status
Any idea?

$ make clean
CLEAN clean
$ make
CC companion-desc.o
LINK companion-desc
CC testmode.o
LINK testmode
CC cleware.o
LINK cleware
CC control.o
LINK control
CC device-reset.o
LINK device-reset
CC msc.o
LINK msc
CC testusb.o
LINK testusb
CC serialc.o
LINK serialc
CC acmc.o
LINK acmc
CC switchbox.o
LINK switchbox
CC seriald.o
LINK seriald
CC acmd.o
LINK acmd
Perhaps something with the GCC version you're using ?
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)

My gcc version is 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) before. After I
upgrade to gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1), then make the repo
again.
LINK companion-desc
/home/ray/felipe/usb-tools/companion-desc.c:219: undefined reference to `libusb_init'
/home/ray/felipe/usb-tools/companion-desc.c:221: undefined reference to `libusb_open_device_with_vid_pid'
/home/ray/felipe/usb-tools/companion-desc.c:176: undefined reference to `libusb_get_device'
/home/ray/felipe/usb-tools/companion-desc.c:178: undefined reference to `libusb_get_device_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:153: undefined reference to `libusb_get_config_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:239: undefined reference to `libusb_close'
/home/ray/felipe/usb-tools/companion-desc.c:242: undefined reference to `libusb_exit'
/home/ray/felipe/usb-tools/companion-desc.c:163: undefined reference to `libusb_free_config_descriptor'
collect2: error: ld returned 1 exit status
make: *** [companion-desc] Error 1

alright, libraries should be listed last. But only a few GCC versions
are more anal about it. Anyway, pushed a patch on Makefile, see if it
works for you.

[Huang Rui]

Post by Felipe Balbi

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}
/**
+ * dwc3_core_nl_set_pipe3 - Configure USB3 PHY Interface for NL
+ */
+static void dwc3_core_nl_set_pipe3(struct dwc3 *dwc)
+{
+ u32 reg = 0;
+
+ reg |= DWC3_GUSB3PIPECTL_U2SSINP3OK | DWC3_GUSB3PIPECTL_UX_EXITINPX
+ | DWC3_GUSB3PIPECTL_UX_EXITINPX | DWC3_GUSB3PIPECTL_U1U2EXITFAIL
+ | DWC3_GUSB3PIPECTL_DEPOCHANGE | DWC3_GUSB3PIPECTL_RX_DETOPOLL;

UX_EXITINPX is supposed to be used with a faulty PHY, I need to see an
erratum before I can accept it. You have also duplicated the bit in this
initialization.
U1U2EXITFAIL -> also a workaround bit and I need to see an erratum.
RX_DETOPOLL -> it seems like it's safe to leave this one out as it can
only be proven to work with this bit after going through full USB
certification.

What do you mean of the faulty PHY?
We would use AMD PHY to talk with DWC3 controller.

Look at the description of each of those bits and you'll see it mentions
they're supposed to be used for workarounds. Here's UX_EXIT_IN_PX, as an
"
This bit is added for SS PHY workaround where SS PHY ...
"

Got it, so faulty PHY you meant that some special PHYs didn't not meet
the standards someplace.
For simulation board, we used vendor provided PHY. But on SOC, we
will use AMD PHY. I will re-check again to confirm which workarounds
need on simulation board and which workarounds need on SOC.

Thanks, that's great. I wonder if there's a way to detect that we're
running on FPGA. Can you check with your HW designers ? I'll go dig on
Synopsys databook myself too on Monday.

I checked with HW designers, they can update the origin value of GUID
register of FPGA to add ASCII codes as prefix of "fpga". I can checked
it before driver re-writes it as kernel version (I see you latest
testing branch have this behavior).

while that's a nice idea, it wouldn't work for everybody; only AMD.
If there's no "generic" way implemented by Synopsys into the RTL, then
we better not add anything.

Because the RTL is frozen.
1) To store the version or revision of your system
2) To store hardware configurations that are outside the core
3) As a scratch register.
As 2) described, it also makes sence the store the HW configuration (FPGA
version) on this register.
Can we split the 32bit space to two 16bit area, one of them stores the HW
configuration, and the other stores the kernel version? I think other SOC
(especially x86-based) would use this method. :)
It looks like there isn't another register can program into the version info.

the problem is that we won't have something that will work for
everybody. Note that the register can be used as scratch register as
well and there's really no way we will be able to get every RTL designer
in every company out there who's licensing this core to agree on using
this register the exact same way.
Unless it ships already built into the RTL Synopsys delivers, there's
no way we can use it in the core dwc3 driver ;-)

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Also, I'd have to ask you to provide full boot logs of your platform
booting with my testing/next (where all the latest patches are) plus
your patches.

I will provide the boot logs to you. Actually, I already did the
gadget mass storage and gadget zero testing with my patches under 3.14
before.

v3.14 is rather old, if you're sending patches upstream. I'd rather see
patches tested with either next or latest Linus' tag. My testing/next
branch is also usually fine too.

Yes, I am doing these testing.
An issue meet your msc.c.
/home/ray/felipe/usb-tools/msc.c:275: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:308: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:332: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:349: undefined reference to `clock_gettime'
/home/ray/felipe/usb-tools/msc.c:401: undefined reference to `clock_gettime'
/tmp/ccUBcDC4.o:/home/ray/felipe/usb-tools/msc.c:407: more undefined references to `clock_gettime' follow
collect2: ld returned 1 exit status
Any idea?

$ make clean
CLEAN clean
$ make
CC companion-desc.o
LINK companion-desc
CC testmode.o
LINK testmode
CC cleware.o
LINK cleware
CC control.o
LINK control
CC device-reset.o
LINK device-reset
CC msc.o
LINK msc
CC testusb.o
LINK testusb
CC serialc.o
LINK serialc
CC acmc.o
LINK acmc
CC switchbox.o
LINK switchbox
CC seriald.o
LINK seriald
CC acmd.o
LINK acmd
Perhaps something with the GCC version you're using ?
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-15' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --wi

th-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu

Post by Felipe Balbi

Post by Felipe Balbi

Post by Huang Rui

Post by Felipe Balbi
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-15)

My gcc version is 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) before. After I
upgrade to gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1), then make the repo
again.
LINK companion-desc
/home/ray/felipe/usb-tools/companion-desc.c:219: undefined reference to `libusb_init'
/home/ray/felipe/usb-tools/companion-desc.c:221: undefined reference to `libusb_open_device_with_vid_pid'
/home/ray/felipe/usb-tools/companion-desc.c:176: undefined reference to `libusb_get_device'
/home/ray/felipe/usb-tools/companion-desc.c:178: undefined reference to `libusb_get_device_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:153: undefined reference to `libusb_get_config_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:239: undefined reference to `libusb_close'
/home/ray/felipe/usb-tools/companion-desc.c:242: undefined reference to `libusb_exit'
/home/ray/felipe/usb-tools/companion-desc.c:163: undefined reference to `libusb_free_config_descriptor'
collect2: error: ld returned 1 exit status
make: *** [companion-desc] Error 1

alright, libraries should be listed last. But only a few GCC versions
are more anal about it. Anyway, pushed a patch on Makefile, see if it
works for you.

Felipe, I am on Chinese holiday in the past week. And back to work on
patch refine.

After fetch your latest codes of usbtool, anything is good except a
arm gcc error, since I used x86 platform.

***@hr-ub:~/felipe/usb-tools$ make
CC companion-desc.o
LINK companion-desc
CC testmode.o
LINK testmode
CC cleware.o
LINK cleware
CC control.o
LINK control
CC device-reset.o
LINK device-reset
CC msc.o
LINK msc
CC testusb.o
LINK testusb
CC serialc.o
LINK serialc
CC acmc.o
LINK acmc
CC switchbox.o
LINK switchbox
CC seriald.o
/bin/sh: 1: arm-linux-gcc: not found
make: *** [seriald.o] Error 127

But it does't block my building. Because I can comment CROSS_COMPILE at
makefile.

I am testing my driver and dwc3 controller with MSC tool currently, and will
let you know message log later.

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

On Thu, Oct 09, 2014 at 01:10:36PM +0800, Huang Rui wrote:

<snip>

Post by Huang Rui

Post by Felipe Balbi

Post by Felipe Balbi
LINK companion-desc
/home/ray/felipe/usb-tools/companion-desc.c:219: undefined reference to `libusb_init'
/home/ray/felipe/usb-tools/companion-desc.c:221: undefined reference to `libusb_open_device_with_vid_pid'
/home/ray/felipe/usb-tools/companion-desc.c:176: undefined reference to `libusb_get_device'
/home/ray/felipe/usb-tools/companion-desc.c:178: undefined reference to `libusb_get_device_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:153: undefined reference to `libusb_get_config_descriptor'
/home/ray/felipe/usb-tools/companion-desc.c:239: undefined reference to `libusb_close'
/home/ray/felipe/usb-tools/companion-desc.c:242: undefined reference to `libusb_exit'
/home/ray/felipe/usb-tools/companion-desc.c:163: undefined reference to `libusb_free_config_descriptor'
collect2: error: ld returned 1 exit status
make: *** [companion-desc] Error 1

alright, libraries should be listed last. But only a few GCC versions
are more anal about it. Anyway, pushed a patch on Makefile, see if it
works for you.

Felipe, I am on Chinese holiday in the past week. And back to work on
patch refine.
After fetch your latest codes of usbtool, anything is good except a
arm gcc error, since I used x86 platform.
CC companion-desc.o
LINK companion-desc
CC testmode.o
LINK testmode
CC cleware.o
LINK cleware
CC control.o
LINK control
CC device-reset.o
LINK device-reset
CC msc.o
LINK msc
CC testusb.o
LINK testusb
CC serialc.o
LINK serialc
CC acmc.o
LINK acmc
CC switchbox.o
LINK switchbox
CC seriald.o
/bin/sh: 1: arm-linux-gcc: not found
make: *** [seriald.o] Error 127

don't worry about that. Some of the tools need to run on the target but
you're not doing that :-) You can make a specific tool by e.g. "make msc".

Post by Huang Rui
But it does't block my building. Because I can comment CROSS_COMPILE at
makefile.
I am testing my driver and dwc3 controller with MSC tool currently, and will
let you know message log later.

Cool, thanks.

[Huang Rui]

Post by Huang Rui

Hi,
=20
=20

=20
<snip>
=20

=20
don't worry about that. Some of the tools need to run on the target=

but

Post by Huang Rui

you're not doing that :-) You can make a specific tool by e.g. "mak=

e msc".

Post by Huang Rui

=20

But it does't block my building. Because I can comment CROSS_COMP=

ILE at

Post by Huang Rui

makefile.
=20
I am testing my driver and dwc3 controller with MSC tool currentl=

y, and will

Post by Huang Rui

let you know message log later.

=20
Cool, thanks.
=20

=20
I have completed a round of MSC testing. All the test cases are passe=

d. Please

Post by Huang Rui
=20
Starting test suite: 2014=E5=B9=B4 10=E6=9C=88 09=E6=97=A5 =E6=98=9F=E6=

=9C=9F=E5=9B=9B 18:02:41 CST

Post by Huang Rui
test 0a: simple 4k read/write
test 0: sent 3.91 MB read 0.03 MB/s write 0.03 MB/=

s ... success

Post by Huang Rui
test 0b: simple 8k read/write
test 0: sent 7.81 MB read 6.15 MB/s write 5.96 MB/=

s ... success

Post by Huang Rui
test 0c: simple 16k read/write
test 0: sent 15.62 MB read 14.30 MB/s write 12.97 MB/=

s ... success

Post by Huang Rui
test 0d: simple 32k read/write
test 0: sent 31.25 MB read 18.26 MB/s write 17.10 MB/=

s ... success

Post by Huang Rui
test 0e: simple 64k read/write
test 0: sent 62.50 MB read 22.00 MB/s write 16.33 MB/=

s ... success

Post by Huang Rui
test 1: simple 1-sector read/write
test 1: sent 500.00 kB read 1.05 MB/s write 0.93 MB/=

s ... success

Post by Huang Rui
test 2: simple 8-sectors read/write
test 2: sent 3.91 MB read 6.52 MB/s write 6.10 MB/=

s ... success

Post by Huang Rui
test 3: simple 32-sectors read/write
test 3: sent 15.62 MB read 14.33 MB/s write 13.14 MB/=

s ... success

Post by Huang Rui
test 4: simple 64-sectors read/write
test 4: sent 31.25 MB read 17.79 MB/s write 16.38 MB/=

s ... success

Post by Huang Rui
test 5a: scatter/gather for 2-sectors buflen 4k
test 5: sent 1000.00 kB read 1.85 MB/s write 1.56 MB/=

s ... success

Post by Huang Rui
test 5b: scatter/gather for 2-sectors buflen 8k
test 5: sent 1000.00 kB read 1.91 MB/s write 1.63 MB/=

s ... success

Post by Huang Rui
test 5c: scatter/gather for 2-sectors buflen 16k
test 5: sent 1000.00 kB read 1.94 MB/s write 1.62 MB/=

s ... success

Post by Huang Rui
test 5d: scatter/gather for 2-sectors buflen 32k
test 5: sent 1000.00 kB read 1.93 MB/s write 1.64 MB/=

s ... success

Post by Huang Rui
test 5e: scatter/gather for 2-sectors buflen 64k
test 5: sent 1000.00 kB read 1.96 MB/s write 1.68 MB/=

s ... success

Post by Huang Rui
test 6a: scatter/gather for 8-sectors buflen 4k
test 6: sent 3.91 MB read 6.53 MB/s write 6.05 MB/=

s ... success

Post by Huang Rui
test 6b: scatter/gather for 8-sectors buflen 8k
test 6: sent 3.91 MB read 6.56 MB/s write 5.98 MB/=

s ... success

Post by Huang Rui
test 6c: scatter/gather for 8-sectors buflen 16k
test 6: sent 3.91 MB read 6.55 MB/s write 6.15 MB/=

s ... success

Post by Huang Rui
test 6d: scatter/gather for 8-sectors buflen 32k
test 6: sent 3.91 MB read 6.51 MB/s write 6.06 MB/=

s ... success

Post by Huang Rui
test 6e: scatter/gather for 8-sectors buflen 64k
test 6: sent 3.91 MB read 6.50 MB/s write 6.06 MB/=

s ... success

Post by Huang Rui
test 7a: scatter/gather for 32-sectors buflen 16k
test 7: sent 15.62 MB read 14.23 MB/s write 12.99 MB/=

s ... success

Post by Huang Rui
test 7b: scatter/gather for 32-sectors buflen 32k
test 7: sent 15.62 MB read 14.27 MB/s write 12.91 MB/=

s ... success

Post by Huang Rui
test 7c: scatter/gather for 32-sectors buflen 64k
test 7: sent 15.62 MB read 14.73 MB/s write 13.00 MB/=

s ... success

Post by Huang Rui
test 8a: scatter/gather for 64-sectors buflen 32k
test 8: sent 31.25 MB read 18.42 MB/s write 16.65 MB/=

s ... success

Post by Huang Rui
test 8b: scatter/gather for 64-sectors buflen 64k
test 8: sent 31.25 MB read 17.70 MB/s write 16.39 MB/=

s ... success

Post by Huang Rui
test 9: scatter/gather for 128-sectors buflen 64k
test 9: sent 62.50 MB read 21.14 MB/s write 16.07 MB/=

s ... success

Post by Huang Rui
test 10: read over the end of the block device
test 10: sent 62.01 MB read 0.00 MB/s write 0.00 MB/=

s ... success

Post by Huang Rui
test 11: lseek past the end of the block device
test 11: sent 0.00 B read 0.00 MB/s write 0.00 MB/s=

... success

Post by Huang Rui
test 12: write over the end of the block device
test 12: sent 0.00 B read 0.00 MB/s write 0.00 MB/s=

... success

Post by Huang Rui
test 13: write 1 sg, read 8 random size sgs
test 13: sent 62.50 MB read 21.61 MB/s write 16.21 MB/=

s ... success

Post by Huang Rui
test 14: write 8 random size sgs, read 1 sg
test 14: sent 62.50 MB read 22.52 MB/s write 18.61 MB/=

s ... success

Post by Huang Rui
test 15: write and read 8 random size sgs
test 15: sent 62.50 MB read 22.31 MB/s write 19.28 MB/=

s ... success

Post by Huang Rui
test 16a: read with heap allocated buffer
test 16: sent 62.50 MB read 21.69 MB/s write 0.00 MB/=

s ... success

Post by Huang Rui
test 16b: read with stack allocated buffer
test 16: sent 62.50 MB read 21.42 MB/s write 0.00 MB/=

s ... success

Post by Huang Rui
test 17a: write with heap allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 19.94 MB/s=

... success

Post by Huang Rui
test 17b: write with stack allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 20.09 MB/s=

... success

Post by Huang Rui
test 18a: write 0x00 and read it back
test 18: sent 62.50 MB read 21.94 MB/s write 16.96 MB/=

s ... success

Post by Huang Rui
test 18b: write 0xff and read it back
test 18: sent 62.50 MB read 19.89 MB/s write 15.51 MB/=

s ... success

Post by Huang Rui
test 18c: write 0x55 and read it back
test 18: sent 62.50 MB read 22.00 MB/s write 16.62 MB/=

s ... success

Post by Huang Rui
test 18d: write 0xaa and read it back
test 18: sent 62.50 MB read 21.81 MB/s write 16.53 MB/=

s ... success

Post by Huang Rui
test 18e: write 0x11 and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 17.00 MB/=

s ... success

Post by Huang Rui
test 18f: write 0x22 and read it back
test 18: sent 62.50 MB read 21.66 MB/s write 16.44 MB/=

s ... success

Post by Huang Rui
test 18g: write 0x44 and read it back
test 18: sent 62.50 MB read 22.23 MB/s write 17.08 MB/=

s ... success

Post by Huang Rui
test 18h: write 0x88 and read it back
test 18: sent 62.50 MB read 21.54 MB/s write 16.17 MB/=

s ... success

Post by Huang Rui
test 18i: write 0x33 and read it back
test 18: sent 62.50 MB read 21.20 MB/s write 16.58 MB/=

s ... success

Post by Huang Rui
test 18j: write 0x66 and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.13 MB/=

s ... success

Post by Huang Rui
test 18k: write 0x99 and read it back
test 18: sent 62.50 MB read 21.92 MB/s write 16.36 MB/=

s ... success

Post by Huang Rui
test 18l: write 0xcc and read it back
test 18: sent 62.50 MB read 22.37 MB/s write 16.74 MB/=

s ... success

Post by Huang Rui
test 18m: write 0x77 and read it back
test 18: sent 62.50 MB read 22.34 MB/s write 16.24 MB/=

s ... success

Post by Huang Rui
test 18n: write 0xbb and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.23 MB/=

s ... success

Post by Huang Rui
test 18o: write 0xdd and read it back
test 18: sent 62.50 MB read 21.38 MB/s write 16.48 MB/=

s ... success

Post by Huang Rui
test 18p: write 0xee and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 16.15 MB/=

s ... success

Post by Huang Rui
Test suite ended: 2014=E5=B9=B4 10=E6=9C=88 09=E6=97=A5 =E6=98=9F=E6=9C=

=9F=E5=9B=9B 18:13:36 CST

Post by Huang Rui
=20
I enabled dwc3 and gadget debug/verbose configuration, the whole test=

ing dmesg

Post by Huang Rui
log is overflow (more than 100000 lines).
=20
Do you want to see the whole testing dmesg, with which debug level
enablement?
=20

=46urthermore, I used file storage gadget.

Bus 001 Device 007: ID 0525:a4a5 Netchip Technology, Inc. Linux-USB Fil=
e Storage Gadget

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Huang Rui]

Hi,
=20
=20

<snip>

=20
don't worry about that. Some of the tools need to run on the target b=

ut

you're not doing that :-) You can make a specific tool by e.g. "make =

msc".

=20

But it does't block my building. Because I can comment CROSS_COMPIL=

E at

makefile.
=20
I am testing my driver and dwc3 controller with MSC tool currently,=

and will

let you know message log later.

=20
Cool, thanks.
=20

I have completed a round of MSC testing. All the test cases are passed.=
Please
see below result:

***@hr-ub:/home/ray/felipe/usb-tools# ./msc.sh -o /dev/sdb1
Starting test suite: 2014=E5=B9=B4 10=E6=9C=88 09=E6=97=A5 =E6=98=9F=E6=
=9C=9F=E5=9B=9B 18:02:41 CST
test 0a: simple 4k read/write
test 0: sent 3.91 MB read 0.03 MB/s write 0.03 MB/s =
=2E.. success
test 0b: simple 8k read/write
test 0: sent 7.81 MB read 6.15 MB/s write 5.96 MB/s =
=2E.. success
test 0c: simple 16k read/write
test 0: sent 15.62 MB read 14.30 MB/s write 12.97 MB/s =
=2E.. success
test 0d: simple 32k read/write
test 0: sent 31.25 MB read 18.26 MB/s write 17.10 MB/s =
=2E.. success
test 0e: simple 64k read/write
test 0: sent 62.50 MB read 22.00 MB/s write 16.33 MB/s =
=2E.. success
test 1: simple 1-sector read/write
test 1: sent 500.00 kB read 1.05 MB/s write 0.93 MB/s =
=2E.. success
test 2: simple 8-sectors read/write
test 2: sent 3.91 MB read 6.52 MB/s write 6.10 MB/s =
=2E.. success
test 3: simple 32-sectors read/write
test 3: sent 15.62 MB read 14.33 MB/s write 13.14 MB/s =
=2E.. success
test 4: simple 64-sectors read/write
test 4: sent 31.25 MB read 17.79 MB/s write 16.38 MB/s =
=2E.. success
test 5a: scatter/gather for 2-sectors buflen 4k
test 5: sent 1000.00 kB read 1.85 MB/s write 1.56 MB/s =
=2E.. success
test 5b: scatter/gather for 2-sectors buflen 8k
test 5: sent 1000.00 kB read 1.91 MB/s write 1.63 MB/s =
=2E.. success
test 5c: scatter/gather for 2-sectors buflen 16k
test 5: sent 1000.00 kB read 1.94 MB/s write 1.62 MB/s =
=2E.. success
test 5d: scatter/gather for 2-sectors buflen 32k
test 5: sent 1000.00 kB read 1.93 MB/s write 1.64 MB/s =
=2E.. success
test 5e: scatter/gather for 2-sectors buflen 64k
test 5: sent 1000.00 kB read 1.96 MB/s write 1.68 MB/s =
=2E.. success
test 6a: scatter/gather for 8-sectors buflen 4k
test 6: sent 3.91 MB read 6.53 MB/s write 6.05 MB/s =
=2E.. success
test 6b: scatter/gather for 8-sectors buflen 8k
test 6: sent 3.91 MB read 6.56 MB/s write 5.98 MB/s =
=2E.. success
test 6c: scatter/gather for 8-sectors buflen 16k
test 6: sent 3.91 MB read 6.55 MB/s write 6.15 MB/s =
=2E.. success
test 6d: scatter/gather for 8-sectors buflen 32k
test 6: sent 3.91 MB read 6.51 MB/s write 6.06 MB/s =
=2E.. success
test 6e: scatter/gather for 8-sectors buflen 64k
test 6: sent 3.91 MB read 6.50 MB/s write 6.06 MB/s =
=2E.. success
test 7a: scatter/gather for 32-sectors buflen 16k
test 7: sent 15.62 MB read 14.23 MB/s write 12.99 MB/s =
=2E.. success
test 7b: scatter/gather for 32-sectors buflen 32k
test 7: sent 15.62 MB read 14.27 MB/s write 12.91 MB/s =
=2E.. success
test 7c: scatter/gather for 32-sectors buflen 64k
test 7: sent 15.62 MB read 14.73 MB/s write 13.00 MB/s =
=2E.. success
test 8a: scatter/gather for 64-sectors buflen 32k
test 8: sent 31.25 MB read 18.42 MB/s write 16.65 MB/s =
=2E.. success
test 8b: scatter/gather for 64-sectors buflen 64k
test 8: sent 31.25 MB read 17.70 MB/s write 16.39 MB/s =
=2E.. success
test 9: scatter/gather for 128-sectors buflen 64k
test 9: sent 62.50 MB read 21.14 MB/s write 16.07 MB/s =
=2E.. success
test 10: read over the end of the block device
test 10: sent 62.01 MB read 0.00 MB/s write 0.00 MB/s =
=2E.. success
test 11: lseek past the end of the block device
test 11: sent 0.00 B read 0.00 MB/s write 0.00 MB/s .=
=2E. success
test 12: write over the end of the block device
test 12: sent 0.00 B read 0.00 MB/s write 0.00 MB/s .=
=2E. success
test 13: write 1 sg, read 8 random size sgs
test 13: sent 62.50 MB read 21.61 MB/s write 16.21 MB/s =
=2E.. success
test 14: write 8 random size sgs, read 1 sg
test 14: sent 62.50 MB read 22.52 MB/s write 18.61 MB/s =
=2E.. success
test 15: write and read 8 random size sgs
test 15: sent 62.50 MB read 22.31 MB/s write 19.28 MB/s =
=2E.. success
test 16a: read with heap allocated buffer
test 16: sent 62.50 MB read 21.69 MB/s write 0.00 MB/s =
=2E.. success
test 16b: read with stack allocated buffer
test 16: sent 62.50 MB read 21.42 MB/s write 0.00 MB/s =
=2E.. success
test 17a: write with heap allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 19.94 MB/s .=
=2E. success
test 17b: write with stack allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 20.09 MB/s .=
=2E. success
test 18a: write 0x00 and read it back
test 18: sent 62.50 MB read 21.94 MB/s write 16.96 MB/s =
=2E.. success
test 18b: write 0xff and read it back
test 18: sent 62.50 MB read 19.89 MB/s write 15.51 MB/s =
=2E.. success
test 18c: write 0x55 and read it back
test 18: sent 62.50 MB read 22.00 MB/s write 16.62 MB/s =
=2E.. success
test 18d: write 0xaa and read it back
test 18: sent 62.50 MB read 21.81 MB/s write 16.53 MB/s =
=2E.. success
test 18e: write 0x11 and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 17.00 MB/s =
=2E.. success
test 18f: write 0x22 and read it back
test 18: sent 62.50 MB read 21.66 MB/s write 16.44 MB/s =
=2E.. success
test 18g: write 0x44 and read it back
test 18: sent 62.50 MB read 22.23 MB/s write 17.08 MB/s =
=2E.. success
test 18h: write 0x88 and read it back
test 18: sent 62.50 MB read 21.54 MB/s write 16.17 MB/s =
=2E.. success
test 18i: write 0x33 and read it back
test 18: sent 62.50 MB read 21.20 MB/s write 16.58 MB/s =
=2E.. success
test 18j: write 0x66 and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.13 MB/s =
=2E.. success
test 18k: write 0x99 and read it back
test 18: sent 62.50 MB read 21.92 MB/s write 16.36 MB/s =
=2E.. success
test 18l: write 0xcc and read it back
test 18: sent 62.50 MB read 22.37 MB/s write 16.74 MB/s =
=2E.. success
test 18m: write 0x77 and read it back
test 18: sent 62.50 MB read 22.34 MB/s write 16.24 MB/s =
=2E.. success
test 18n: write 0xbb and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.23 MB/s =
=2E.. success
test 18o: write 0xdd and read it back
test 18: sent 62.50 MB read 21.38 MB/s write 16.48 MB/s =
=2E.. success
test 18p: write 0xee and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 16.15 MB/s =
=2E.. success
Test suite ended: 2014=E5=B9=B4 10=E6=9C=88 09=E6=97=A5 =E6=98=9F=E6=9C=
=9F=E5=9B=9B 18:13:36 CST

I enabled dwc3 and gadget debug/verbose configuration, the whole testin=
g dmesg
log is overflow (more than 100000 lines).

Do you want to see the whole testing dmesg, with which debug level
enablement?

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Felipe Balbi

Post by Huang Rui
But it does't block my building. Because I can comment CROSS_COMPILE at
makefile.
I am testing my driver and dwc3 controller with MSC tool currently, and will
let you know message log later.

Cool, thanks.

I have completed a round of MSC testing. All the test cases are passed. Please
Starting test suite: 2014幎 10月 09日 星期四 18:02:41 CST
test 0a: simple 4k read/write
test 0: sent 3.91 MB read 0.03 MB/s write 0.03 MB/s ... success
test 0b: simple 8k read/write
test 0: sent 7.81 MB read 6.15 MB/s write 5.96 MB/s ... success
test 0c: simple 16k read/write
test 0: sent 15.62 MB read 14.30 MB/s write 12.97 MB/s ... success
test 0d: simple 32k read/write
test 0: sent 31.25 MB read 18.26 MB/s write 17.10 MB/s ... success
test 0e: simple 64k read/write
test 0: sent 62.50 MB read 22.00 MB/s write 16.33 MB/s ... success
test 1: simple 1-sector read/write
test 1: sent 500.00 kB read 1.05 MB/s write 0.93 MB/s ... success
test 2: simple 8-sectors read/write
test 2: sent 3.91 MB read 6.52 MB/s write 6.10 MB/s ... success
test 3: simple 32-sectors read/write
test 3: sent 15.62 MB read 14.33 MB/s write 13.14 MB/s ... success
test 4: simple 64-sectors read/write
test 4: sent 31.25 MB read 17.79 MB/s write 16.38 MB/s ... success
test 5a: scatter/gather for 2-sectors buflen 4k
test 5: sent 1000.00 kB read 1.85 MB/s write 1.56 MB/s ... success
test 5b: scatter/gather for 2-sectors buflen 8k
test 5: sent 1000.00 kB read 1.91 MB/s write 1.63 MB/s ... success
test 5c: scatter/gather for 2-sectors buflen 16k
test 5: sent 1000.00 kB read 1.94 MB/s write 1.62 MB/s ... success
test 5d: scatter/gather for 2-sectors buflen 32k
test 5: sent 1000.00 kB read 1.93 MB/s write 1.64 MB/s ... success
test 5e: scatter/gather for 2-sectors buflen 64k
test 5: sent 1000.00 kB read 1.96 MB/s write 1.68 MB/s ... success
test 6a: scatter/gather for 8-sectors buflen 4k
test 6: sent 3.91 MB read 6.53 MB/s write 6.05 MB/s ... success
test 6b: scatter/gather for 8-sectors buflen 8k
test 6: sent 3.91 MB read 6.56 MB/s write 5.98 MB/s ... success
test 6c: scatter/gather for 8-sectors buflen 16k
test 6: sent 3.91 MB read 6.55 MB/s write 6.15 MB/s ... success
test 6d: scatter/gather for 8-sectors buflen 32k
test 6: sent 3.91 MB read 6.51 MB/s write 6.06 MB/s ... success
test 6e: scatter/gather for 8-sectors buflen 64k
test 6: sent 3.91 MB read 6.50 MB/s write 6.06 MB/s ... success
test 7a: scatter/gather for 32-sectors buflen 16k
test 7: sent 15.62 MB read 14.23 MB/s write 12.99 MB/s ... success
test 7b: scatter/gather for 32-sectors buflen 32k
test 7: sent 15.62 MB read 14.27 MB/s write 12.91 MB/s ... success
test 7c: scatter/gather for 32-sectors buflen 64k
test 7: sent 15.62 MB read 14.73 MB/s write 13.00 MB/s ... success
test 8a: scatter/gather for 64-sectors buflen 32k
test 8: sent 31.25 MB read 18.42 MB/s write 16.65 MB/s ... success
test 8b: scatter/gather for 64-sectors buflen 64k
test 8: sent 31.25 MB read 17.70 MB/s write 16.39 MB/s ... success
test 9: scatter/gather for 128-sectors buflen 64k
test 9: sent 62.50 MB read 21.14 MB/s write 16.07 MB/s ... success
test 10: read over the end of the block device
test 10: sent 62.01 MB read 0.00 MB/s write 0.00 MB/s ... success
test 11: lseek past the end of the block device
test 11: sent 0.00 B read 0.00 MB/s write 0.00 MB/s ... success
test 12: write over the end of the block device
test 12: sent 0.00 B read 0.00 MB/s write 0.00 MB/s ... success
test 13: write 1 sg, read 8 random size sgs
test 13: sent 62.50 MB read 21.61 MB/s write 16.21 MB/s ... success
test 14: write 8 random size sgs, read 1 sg
test 14: sent 62.50 MB read 22.52 MB/s write 18.61 MB/s ... success
test 15: write and read 8 random size sgs
test 15: sent 62.50 MB read 22.31 MB/s write 19.28 MB/s ... success
test 16a: read with heap allocated buffer
test 16: sent 62.50 MB read 21.69 MB/s write 0.00 MB/s ... success
test 16b: read with stack allocated buffer
test 16: sent 62.50 MB read 21.42 MB/s write 0.00 MB/s ... success
test 17a: write with heap allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 19.94 MB/s ... success
test 17b: write with stack allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 20.09 MB/s ... success
test 18a: write 0x00 and read it back
test 18: sent 62.50 MB read 21.94 MB/s write 16.96 MB/s ... success
test 18b: write 0xff and read it back
test 18: sent 62.50 MB read 19.89 MB/s write 15.51 MB/s ... success
test 18c: write 0x55 and read it back
test 18: sent 62.50 MB read 22.00 MB/s write 16.62 MB/s ... success
test 18d: write 0xaa and read it back
test 18: sent 62.50 MB read 21.81 MB/s write 16.53 MB/s ... success
test 18e: write 0x11 and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 17.00 MB/s ... success
test 18f: write 0x22 and read it back
test 18: sent 62.50 MB read 21.66 MB/s write 16.44 MB/s ... success
test 18g: write 0x44 and read it back
test 18: sent 62.50 MB read 22.23 MB/s write 17.08 MB/s ... success
test 18h: write 0x88 and read it back
test 18: sent 62.50 MB read 21.54 MB/s write 16.17 MB/s ... success
test 18i: write 0x33 and read it back
test 18: sent 62.50 MB read 21.20 MB/s write 16.58 MB/s ... success
test 18j: write 0x66 and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.13 MB/s ... success
test 18k: write 0x99 and read it back
test 18: sent 62.50 MB read 21.92 MB/s write 16.36 MB/s ... success
test 18l: write 0xcc and read it back
test 18: sent 62.50 MB read 22.37 MB/s write 16.74 MB/s ... success
test 18m: write 0x77 and read it back
test 18: sent 62.50 MB read 22.34 MB/s write 16.24 MB/s ... success
test 18n: write 0xbb and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.23 MB/s ... success
test 18o: write 0xdd and read it back
test 18: sent 62.50 MB read 21.38 MB/s write 16.48 MB/s ... success
test 18p: write 0xee and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 16.15 MB/s ... success
Test suite ended: 2014幎 10月 09日 星期四 18:13:36 CST
I enabled dwc3 and gadget debug/verbose configuration, the whole testing dmesg

oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
A9 :-)

log is overflow (more than 100000 lines).

FYI, I barely use VERBOSE DEBUG nowadays. I generally use the
tracepoints which I've added for v3.18 merge window. That adds orders of
magnitude less overhead than debugging through dmesg/printk ;-)

Here's a sample of the kinds of messages you can get:

http://www.spinics.net/lists/linux-usb/msg112704.html

Latest patches are in testing/next (there's a bug fix for the
tracepoints in that branch which I'll send to Greg once I let them soak
in linux-next for a few days).

Do you want to see the whole testing dmesg, with which debug level
enablement?

This is good for me, thank you.

ps: FYI, I left my board running overnight the same test. It has been
pretty stable so far.

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Felipe Balbi

Post by Huang Rui
But it does't block my building. Because I can comment CROSS_COMPILE at
makefile.
I am testing my driver and dwc3 controller with MSC tool currently, and will
let you know message log later.

Cool, thanks.

I have completed a round of MSC testing. All the test cases are passed. Please
Starting test suite: 2014幎 10月 09日 星期四 18:02:41 CST
test 0a: simple 4k read/write
test 0: sent 3.91 MB read 0.03 MB/s write 0.03 MB/s ... success
test 0b: simple 8k read/write
test 0: sent 7.81 MB read 6.15 MB/s write 5.96 MB/s ... success
test 0c: simple 16k read/write
test 0: sent 15.62 MB read 14.30 MB/s write 12.97 MB/s ... success
test 0d: simple 32k read/write
test 0: sent 31.25 MB read 18.26 MB/s write 17.10 MB/s ... success
test 0e: simple 64k read/write
test 0: sent 62.50 MB read 22.00 MB/s write 16.33 MB/s ... success
test 1: simple 1-sector read/write
test 1: sent 500.00 kB read 1.05 MB/s write 0.93 MB/s ... success
test 2: simple 8-sectors read/write
test 2: sent 3.91 MB read 6.52 MB/s write 6.10 MB/s ... success
test 3: simple 32-sectors read/write
test 3: sent 15.62 MB read 14.33 MB/s write 13.14 MB/s ... success
test 4: simple 64-sectors read/write
test 4: sent 31.25 MB read 17.79 MB/s write 16.38 MB/s ... success
test 5a: scatter/gather for 2-sectors buflen 4k
test 5: sent 1000.00 kB read 1.85 MB/s write 1.56 MB/s ... success
test 5b: scatter/gather for 2-sectors buflen 8k
test 5: sent 1000.00 kB read 1.91 MB/s write 1.63 MB/s ... success
test 5c: scatter/gather for 2-sectors buflen 16k
test 5: sent 1000.00 kB read 1.94 MB/s write 1.62 MB/s ... success
test 5d: scatter/gather for 2-sectors buflen 32k
test 5: sent 1000.00 kB read 1.93 MB/s write 1.64 MB/s ... success
test 5e: scatter/gather for 2-sectors buflen 64k
test 5: sent 1000.00 kB read 1.96 MB/s write 1.68 MB/s ... success
test 6a: scatter/gather for 8-sectors buflen 4k
test 6: sent 3.91 MB read 6.53 MB/s write 6.05 MB/s ... success
test 6b: scatter/gather for 8-sectors buflen 8k
test 6: sent 3.91 MB read 6.56 MB/s write 5.98 MB/s ... success
test 6c: scatter/gather for 8-sectors buflen 16k
test 6: sent 3.91 MB read 6.55 MB/s write 6.15 MB/s ... success
test 6d: scatter/gather for 8-sectors buflen 32k
test 6: sent 3.91 MB read 6.51 MB/s write 6.06 MB/s ... success
test 6e: scatter/gather for 8-sectors buflen 64k
test 6: sent 3.91 MB read 6.50 MB/s write 6.06 MB/s ... success
test 7a: scatter/gather for 32-sectors buflen 16k
test 7: sent 15.62 MB read 14.23 MB/s write 12.99 MB/s ... success
test 7b: scatter/gather for 32-sectors buflen 32k
test 7: sent 15.62 MB read 14.27 MB/s write 12.91 MB/s ... success
test 7c: scatter/gather for 32-sectors buflen 64k
test 7: sent 15.62 MB read 14.73 MB/s write 13.00 MB/s ... success
test 8a: scatter/gather for 64-sectors buflen 32k
test 8: sent 31.25 MB read 18.42 MB/s write 16.65 MB/s ... success
test 8b: scatter/gather for 64-sectors buflen 64k
test 8: sent 31.25 MB read 17.70 MB/s write 16.39 MB/s ... success
test 9: scatter/gather for 128-sectors buflen 64k
test 9: sent 62.50 MB read 21.14 MB/s write 16.07 MB/s ... success
test 10: read over the end of the block device
test 10: sent 62.01 MB read 0.00 MB/s write 0.00 MB/s ... success
test 11: lseek past the end of the block device
test 11: sent 0.00 B read 0.00 MB/s write 0.00 MB/s ... success
test 12: write over the end of the block device
test 12: sent 0.00 B read 0.00 MB/s write 0.00 MB/s ... success
test 13: write 1 sg, read 8 random size sgs
test 13: sent 62.50 MB read 21.61 MB/s write 16.21 MB/s ... success
test 14: write 8 random size sgs, read 1 sg
test 14: sent 62.50 MB read 22.52 MB/s write 18.61 MB/s ... success
test 15: write and read 8 random size sgs
test 15: sent 62.50 MB read 22.31 MB/s write 19.28 MB/s ... success
test 16a: read with heap allocated buffer
test 16: sent 62.50 MB read 21.69 MB/s write 0.00 MB/s ... success
test 16b: read with stack allocated buffer
test 16: sent 62.50 MB read 21.42 MB/s write 0.00 MB/s ... success
test 17a: write with heap allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 19.94 MB/s ... success
test 17b: write with stack allocated buffer
test 17: sent 0.00 B read 0.00 MB/s write 20.09 MB/s ... success
test 18a: write 0x00 and read it back
test 18: sent 62.50 MB read 21.94 MB/s write 16.96 MB/s ... success
test 18b: write 0xff and read it back
test 18: sent 62.50 MB read 19.89 MB/s write 15.51 MB/s ... success
test 18c: write 0x55 and read it back
test 18: sent 62.50 MB read 22.00 MB/s write 16.62 MB/s ... success
test 18d: write 0xaa and read it back
test 18: sent 62.50 MB read 21.81 MB/s write 16.53 MB/s ... success
test 18e: write 0x11 and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 17.00 MB/s ... success
test 18f: write 0x22 and read it back
test 18: sent 62.50 MB read 21.66 MB/s write 16.44 MB/s ... success
test 18g: write 0x44 and read it back
test 18: sent 62.50 MB read 22.23 MB/s write 17.08 MB/s ... success
test 18h: write 0x88 and read it back
test 18: sent 62.50 MB read 21.54 MB/s write 16.17 MB/s ... success
test 18i: write 0x33 and read it back
test 18: sent 62.50 MB read 21.20 MB/s write 16.58 MB/s ... success
test 18j: write 0x66 and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.13 MB/s ... success
test 18k: write 0x99 and read it back
test 18: sent 62.50 MB read 21.92 MB/s write 16.36 MB/s ... success
test 18l: write 0xcc and read it back
test 18: sent 62.50 MB read 22.37 MB/s write 16.74 MB/s ... success
test 18m: write 0x77 and read it back
test 18: sent 62.50 MB read 22.34 MB/s write 16.24 MB/s ... success
test 18n: write 0xbb and read it back
test 18: sent 62.50 MB read 21.82 MB/s write 16.23 MB/s ... success
test 18o: write 0xdd and read it back
test 18: sent 62.50 MB read 21.38 MB/s write 16.48 MB/s ... success
test 18p: write 0xee and read it back
test 18: sent 62.50 MB read 22.33 MB/s write 16.15 MB/s ... success
Test suite ended: 2014幎 10月 09日 星期四 18:13:36 CST
I enabled dwc3 and gadget debug/verbose configuration, the whole testing dmesg

oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
A9 :-)

Yes, maybe have two reasons:
1) The input clock is much slower than SOC's.
2) I used high speed mode.

Because of the timing issue on FPGA, bulk write transfer would get
stuck when use more than 1MB (can pass on small file write) on super
speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)

Post by Felipe Balbi

log is overflow (more than 100000 lines).

FYI, I barely use VERBOSE DEBUG nowadays. I generally use the
tracepoints which I've added for v3.18 merge window. That adds orders of
magnitude less overhead than debugging through dmesg/printk ;-)
http://www.spinics.net/lists/linux-usb/msg112704.html
Latest patches are in testing/next (there's a bug fix for the
tracepoints in that branch which I'll send to Greg once I let them soak
in linux-next for a few days).

That's cool.

Post by Felipe Balbi

Do you want to see the whole testing dmesg, with which debug level
enablement?

This is good for me, thank you.

The test log with booting is attached. Please review.

Post by Felipe Balbi
ps: FYI, I left my board running overnight the same test. It has been
pretty stable so far.

High speed mode is stable in my FPGA board, but super speed is not
at current.

Thanks,
Rui

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi

I enabled dwc3 and gadget debug/verbose configuration, the whole testing dmesg

oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
A9 :-)

1) The input clock is much slower than SOC's.
2) I used high speed mode.

right, i'm running at highspeed too.

Post by Huang Rui
Because of the timing issue on FPGA, bulk write transfer would get
stuck when use more than 1MB (can pass on small file write) on super
speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)

These shouldn't fail. I'll leave testusb running tonight.

Post by Huang Rui

Post by Felipe Balbi

Do you want to see the whole testing dmesg, with which debug level
enablement?

This is good for me, thank you.

The test log with booting is attached. Please review.

will do.

Post by Huang Rui

Post by Felipe Balbi
ps: FYI, I left my board running overnight the same test. It has been
pretty stable so far.

High speed mode is stable in my FPGA board, but super speed is not
at current.

weird. Got any logs ? If you want to share logs I can probably help you
debugging that.

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

I enabled dwc3 and gadget debug/verbose configuration, the whole testing dmesg

oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
A9 :-)

1) The input clock is much slower than SOC's.
2) I used high speed mode.

right, i'm running at highspeed too.

Post by Huang Rui
Because of the timing issue on FPGA, bulk write transfer would get
stuck when use more than 1MB (can pass on small file write) on super
speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)

These shouldn't fail. I'll leave testusb running tonight.

Post by Huang Rui

Post by Felipe Balbi

Do you want to see the whole testing dmesg, with which debug level
enablement?

This is good for me, thank you.

The test log with booting is attached. Please review.

will do.

Post by Huang Rui

Post by Felipe Balbi
ps: FYI, I left my board running overnight the same test. It has been
pretty stable so far.

High speed mode is stable in my FPGA board, but super speed is not
at current.

weird. Got any logs ? If you want to share logs I can probably help you
debugging that.

Sure. Below is my controller as super speed mode on gadget zero test 1 (bulk
write). Test 9/10 can be passed and device is able to enumerated, so control
transfer should be OK.

Bus 007 Device 004: ID 0525:a4a0 Netchip Technology, Inc. Linux-USB "Gadget Zero"

***@hr-bak:/home/ray/usb# ./testusb.sh 1
unknown speed /dev/bus/usb/007/004 0
/dev/bus/usb/007/004 test 1 --> 110 (Connection timed out)

Host:
[ 8793.096303] usb 7-1: new SuperSpeed USB device number 4 using xhci_hcd
[ 8793.119876] usb 7-1: New USB device found, idVendor=0525, idProduct=a4a0
[ 8793.120109] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8793.120352] usb 7-1: Product: Gadget Zero
[ 8793.120493] usb 7-1: Manufacturer: Linux 3.17.0-rc5-dwc3-upstream+ with dwc3-gadget
[ 8793.120751] usb 7-1: SerialNumber: 0123456789.0123456789.0123456789
[ 8793.489749] usbtest 7-1:3.0: Linux gadget zero
[ 8793.489933] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} tests (+alt)
[ 8793.490246] usbcore: registered new interface driver usbtest
[ 8815.325781] usbcore: deregistering interface driver usbtest
[ 8819.760443] usbtest 7-1:3.0: Linux gadget zero
[ 8819.760621] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} tests (+alt)
[ 8819.760921] usbcore: registered new interface driver usbtest
[ 8891.317350] usbtest 7-1:3.0: TEST 1: write 512 bytes 20 times
[ 8901.316770] usb 7-1: test1 failed, iterations left 19, status -110 (not 0)

Device:
[ 7872.401865] udc dwc3.0.auto: registering UDC driver [zero]
[ 7872.420057] zero gadget: adding 'source/sink'/ffff88002e593e00 to config 'source/sink'/ffffffffa01ad000
[ 7872.420072] zero gadget: super speed source/sink: IN/ep1in, OUT/ep1out, ISO-IN/ep2in, ISO-OUT/ep2out, INT-IN/ep3in, INT-OUT/ep3out
[ 7872.420076] zero gadget: adding 'loopback'/ffff88002e593000 to config 'loopback'/ffffffffa01ad0e0
[ 7872.420081] zero gadget: super speed loopback: IN/ep1in, OUT/ep1out
[ 7872.420086] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[ 7872.420089] zero gadget: zero ready
[ 7872.661926] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 8/8 ===> 0
[ 7872.662505] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 18/18 ===> 0
[ 7872.663039] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 5/5 ===> 0
[ 7872.663655] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 22/22 ===> 0
[ 7872.664261] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 9/9 ===> 0
[ 7872.664890] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 140/140 ===> 0
[ 7872.665924] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 9/9 ===> 0
[ 7872.666493] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 44/44 ===> 0
[ 7872.667596] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 4/4 ===> 0
[ 7872.668135] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 24/24 ===> 0
[ 7872.668933] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 98/98 ===> 0
[ 7872.669501] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 66/66 ===> 0
[ 7872.671680] zero gadget: super-speed config #3: source/sink
[ 7872.671766] zero gadget: source/sink enabled, alt intf 0
[ 7872.671898] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 0/0 ===> 0
[ 7872.672400] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 42/42 ===> 0
[ 7970.768261] dwc3 dwc3.0.auto: request ffff88018778eb40 from ep1in completed 0/512 ===> -108
[ 7970.768277] dwc3 dwc3.0.auto: request ffff88018778e600 from ep1out completed 0/512 ===> -108
[ 7970.768349] zero gadget: source/sink enabled, alt intf 0
[ 7970.768517] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 0/0 ===> 0

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Huang Rui]

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

I enabled dwc3 and gadget debug/verbose configuration, the whole testing dmesg

oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
A9 :-)

1) The input clock is much slower than SOC's.
2) I used high speed mode.

right, i'm running at highspeed too.

Post by Huang Rui
Because of the timing issue on FPGA, bulk write transfer would get
stuck when use more than 1MB (can pass on small file write) on super
speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)

These shouldn't fail. I'll leave testusb running tonight.

Post by Huang Rui

Post by Felipe Balbi

Do you want to see the whole testing dmesg, with which debug level
enablement?

This is good for me, thank you.

The test log with booting is attached. Please review.

will do.

Post by Huang Rui

Post by Felipe Balbi
ps: FYI, I left my board running overnight the same test. It has been
pretty stable so far.

High speed mode is stable in my FPGA board, but super speed is not
at current.

weird. Got any logs ? If you want to share logs I can probably help you
debugging that.

Sure. Below is my controller as super speed mode on gadget zero test 1 (bulk
write). Test 9/10 can be passed and device is able to enumerated, so control
transfer should be OK.
Bus 007 Device 004: ID 0525:a4a0 Netchip Technology, Inc. Linux-USB "Gadget Zero"
unknown speed /dev/bus/usb/007/004 0
/dev/bus/usb/007/004 test 1 --> 110 (Connection timed out)
[ 8793.096303] usb 7-1: new SuperSpeed USB device number 4 using xhci_hcd
[ 8793.119876] usb 7-1: New USB device found, idVendor=0525, idProduct=a4a0
[ 8793.120109] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8793.120352] usb 7-1: Product: Gadget Zero
[ 8793.120493] usb 7-1: Manufacturer: Linux 3.17.0-rc5-dwc3-upstream+ with dwc3-gadget
[ 8793.120751] usb 7-1: SerialNumber: 0123456789.0123456789.0123456789
[ 8793.489749] usbtest 7-1:3.0: Linux gadget zero
[ 8793.489933] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} tests (+alt)
[ 8793.490246] usbcore: registered new interface driver usbtest
[ 8815.325781] usbcore: deregistering interface driver usbtest
[ 8819.760443] usbtest 7-1:3.0: Linux gadget zero
[ 8819.760621] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} tests (+alt)
[ 8819.760921] usbcore: registered new interface driver usbtest
[ 8891.317350] usbtest 7-1:3.0: TEST 1: write 512 bytes 20 times
[ 8901.316770] usb 7-1: test1 failed, iterations left 19, status -110 (not 0)
[ 7872.401865] udc dwc3.0.auto: registering UDC driver [zero]
[ 7872.420057] zero gadget: adding 'source/sink'/ffff88002e593e00 to config 'source/sink'/ffffffffa01ad000
[ 7872.420072] zero gadget: super speed source/sink: IN/ep1in, OUT/ep1out, ISO-IN/ep2in, ISO-OUT/ep2out, INT-IN/ep3in, INT-OUT/ep3out
[ 7872.420076] zero gadget: adding 'loopback'/ffff88002e593000 to config 'loopback'/ffffffffa01ad0e0
[ 7872.420081] zero gadget: super speed loopback: IN/ep1in, OUT/ep1out
[ 7872.420086] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[ 7872.420089] zero gadget: zero ready
[ 7872.661926] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 8/8 ===> 0
[ 7872.662505] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 18/18 ===> 0
[ 7872.663039] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 5/5 ===> 0
[ 7872.663655] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 22/22 ===> 0
[ 7872.664261] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 9/9 ===> 0
[ 7872.664890] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 140/140 ===> 0
[ 7872.665924] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 9/9 ===> 0
[ 7872.666493] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 44/44 ===> 0
[ 7872.667596] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 4/4 ===> 0
[ 7872.668135] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 24/24 ===> 0
[ 7872.668933] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 98/98 ===> 0
[ 7872.669501] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 66/66 ===> 0
[ 7872.671680] zero gadget: super-speed config #3: source/sink
[ 7872.671766] zero gadget: source/sink enabled, alt intf 0
[ 7872.671898] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 0/0 ===> 0
[ 7872.672400] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 42/42 ===> 0
[ 7970.768261] dwc3 dwc3.0.auto: request ffff88018778eb40 from ep1in completed 0/512 ===> -108
[ 7970.768277] dwc3 dwc3.0.auto: request ffff88018778e600 from ep1out completed 0/512 ===> -108
[ 7970.768349] zero gadget: source/sink enabled, alt intf 0
[ 7970.768517] dwc3 dwc3.0.auto: request ffff880186d91180 from ep0out completed 0/0 ===> 0

Add dwc3 trace log which is from your new trace event feature. :)

Thanks,
Rui

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

I enabled dwc3 and gadget debug/verbose configuration, the whole testing dmesg

oh, that's why it's so slow :-) I'm getting over 30MB/sec with a Cortex
A9 :-)

1) The input clock is much slower than SOC's.
2) I used high speed mode.

right, i'm running at highspeed too.

Post by Huang Rui
Because of the timing issue on FPGA, bulk write transfer would get
stuck when use more than 1MB (can pass on small file write) on super
speed mode. (Gadget Zero failed on 1/3/5/7 with 10s timeout)

These shouldn't fail. I'll leave testusb running tonight.

Post by Huang Rui

Post by Felipe Balbi

Do you want to see the whole testing dmesg, with which debug level
enablement?

This is good for me, thank you.

The test log with booting is attached. Please review.

will do.

Post by Huang Rui

Post by Felipe Balbi
ps: FYI, I left my board running overnight the same test. It has been
pretty stable so far.

High speed mode is stable in my FPGA board, but super speed is not
at current.

weird. Got any logs ? If you want to share logs I can probably help you
debugging that.

Sure. Below is my controller as super speed mode on gadget zero test 1 (bulk
write). Test 9/10 can be passed and device is able to enumerated, so control
transfer should be OK.
Bus 007 Device 004: ID 0525:a4a0 Netchip Technology, Inc. Linux-USB "Gadget Zero"
unknown speed /dev/bus/usb/007/004 0
/dev/bus/usb/007/004 test 1 --> 110 (Connection timed out)
[ 8793.096303] usb 7-1: new SuperSpeed USB device number 4 using xhci_hcd
[ 8793.119876] usb 7-1: New USB device found, idVendor=0525, idProduct=a4a0
[ 8793.120109] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8793.120352] usb 7-1: Product: Gadget Zero
[ 8793.120493] usb 7-1: Manufacturer: Linux 3.17.0-rc5-dwc3-upstream+ with dwc3-gadget
[ 8793.120751] usb 7-1: SerialNumber: 0123456789.0123456789.0123456789
[ 8793.489749] usbtest 7-1:3.0: Linux gadget zero
[ 8793.489933] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} tests (+alt)
[ 8793.490246] usbcore: registered new interface driver usbtest
[ 8815.325781] usbcore: deregistering interface driver usbtest
[ 8819.760443] usbtest 7-1:3.0: Linux gadget zero
[ 8819.760621] usbtest 7-1:3.0: super-speed {control in/out bulk-in bulk-out} tests (+alt)
[ 8819.760921] usbcore: registered new interface driver usbtest
[ 8891.317350] usbtest 7-1:3.0: TEST 1: write 512 bytes 20 times
[ 8901.316770] usb 7-1: test1 failed, iterations left 19, status -110 (not 0)

oh, ok. See this thread:

http://marc.info/?l=linux-usb&m=141296688426206

[Huang Rui]

Post by Huang Rui

Post by Huang Rui

Post by Felipe Balbi
Hi,

Post by Huang Rui
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b0f4d52..6138c5d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -115,6 +115,25 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
}

<snip>

Post by Huang Rui

Post by Huang Rui

Post by Felipe Balbi

Post by Huang Rui
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;

looks like this should always be set for all versions of the core
configured with hibernation.

yes, amd nl chip will support hibernation.

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..584dcde 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -449,6 +449,7 @@ static int dwc3_core_init(struct dwc3 *dwc)
/* enable hibernation here */
dwc->nr_scratch = DWC3_GHWPARAMS4_HIBER_SCRATCHBUFS(hwparams4);
+ reg |= DWC3_GCTL_GBLHIBERNATIONEN;
break;
dev_dbg(dwc->dev, "No power optimization available\n");
that'll work for everybody with hibernation enabled in coreConsultant.

Right, I will do it like this on V2.

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Paul Zimmerman]

From: linux-usb-owner-***@public.gmane.org [mailto:linux-usb-owner-***@public.gmane.org] On Behalf Of Felipe Balbi
Sent: Thursday, September 25, 2014 7:51 AM

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

[Felipe Balbi]

Hi,

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

cheers

[Paul Zimmerman]

Sent: Friday, September 26, 2014 2:40 PM

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

I just talked to one of our RTL designers. You're right, there is no
way to tell from the Device registers alone whether the controller is
configured with LPM Errata support or not.

You can tell for sure if it is *not* enabled, by checking GSNPSID, and
if the version is earlier than 2.40a, the feature wasn't available.

So for Device-mode only controllers, I guess you will need a DT property
for this.

[Felipe Balbi]

Hi,

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 2:40 PM

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

I just talked to one of our RTL designers. You're right, there is no
way to tell from the Device registers alone whether the controller is
configured with LPM Errata support or not.
You can tell for sure if it is *not* enabled, by checking GSNPSID, and
if the version is earlier than 2.40a, the feature wasn't available.

alright, we can use this for something like:

WARN(rev < 2.40a && (flags & LPM_ERRATA || of_property_read_bool("lpm-errata")),
"LPM Errata not available on dwc3 revisions <= 2.40a\n");

Post by Paul Zimmerman
So for Device-mode only controllers, I guess you will need a DT property
for this.

right, DT property and platform_data feature flag, or something. I don't
wanna call it a quirk though, although it _is_ an erratum WRT LPM
support. Dunno. Any strong feelings ?

[Paul Zimmerman]

Sent: Friday, September 26, 2014 5:54 PM

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 2:40 PM

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

I just talked to one of our RTL designers. You're right, there is no
way to tell from the Device registers alone whether the controller is
configured with LPM Errata support or not.
You can tell for sure if it is *not* enabled, by checking GSNPSID, and
if the version is earlier than 2.40a, the feature wasn't available.

WARN(rev < 2.40a && (flags & LPM_ERRATA || of_property_read_bool("lpm-errata")),
"LPM Errata not available on dwc3 revisions <= 2.40a\n");

Post by Paul Zimmerman
So for Device-mode only controllers, I guess you will need a DT property
for this.

right, DT property and platform_data feature flag, or something. I don't
wanna call it a quirk though, although it _is_ an erratum WRT LPM
support. Dunno. Any strong feelings ?

Well, it's called LPM Errata because the feature was added to the USB
spec as an erratum. It's not an erratum to our controller. But I don't
have any strong feelings about how the driver support is implemented.

[Felipe Balbi]

Hi,

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 5:54 PM

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 2:40 PM

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

I just talked to one of our RTL designers. You're right, there is no
way to tell from the Device registers alone whether the controller is
configured with LPM Errata support or not.
You can tell for sure if it is *not* enabled, by checking GSNPSID, and
if the version is earlier than 2.40a, the feature wasn't available.

WARN(rev < 2.40a && (flags & LPM_ERRATA || of_property_read_bool("lpm-errata")),
"LPM Errata not available on dwc3 revisions <= 2.40a\n");

Post by Paul Zimmerman
So for Device-mode only controllers, I guess you will need a DT property
for this.

right, DT property and platform_data feature flag, or something. I don't
wanna call it a quirk though, although it _is_ an erratum WRT LPM
support. Dunno. Any strong feelings ?

Well, it's called LPM Errata because the feature was added to the USB
spec as an erratum. It's not an erratum to our controller. But I don't
have any strong feelings about how the driver support is implemented.

how about adding a "has_lpm_erratum" to struct dwc3 which gets
initialized either through pdata or DT ? Then above WARN() would become:

WARN(dwc->revision < DWC3_REVISION_240A && dwc->has_lpm_erratum",
"LPM Erratum not available on dwc3 revisisions < 2.40a\n");

Then we're not really calling it a quirk. In fact Huang, when respining
your series, let's convert your quirk bits into single-bit fields inside
struct dwc3 and struct platform_data. Like so:

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..e233ce1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -695,11 +695,13 @@ static int dwc3_probe(struct platform_device *pdev)

if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
+ dwc->has_lpm_erratum = of_property_read_bool(node, "snps,has-lpm-erratum");

dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize");
dwc->dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
+ dwc->has_lpm_erratum = pdata->has_lpm_erratum;

dwc->needs_fifo_resize = pdata->tx_fifo_resize;
dwc->dr_mode = pdata->dr_mode;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 66f6256..23e1504 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -661,6 +661,8 @@ struct dwc3_scratchpad_array {
* @ep0_bounced: true when we used bounce buffer
* @ep0_expect_in: true when we expect a DATA IN transfer
* @has_hibernation: true when dwc3 was configured with Hibernation
+ * @has_lpm_erratum: true when core was configured with LPM Erratum. Note that
+ * there's now way for software to detect this in runtime.
* @is_selfpowered: true when we are selfpowered
* @needs_fifo_resize: not all users might want fifo resizing, flag it
* @pullups_connected: true when Run/Stop bit is set
@@ -764,6 +766,7 @@ struct dwc3 {
unsigned ep0_bounced:1;
unsigned ep0_expect_in:1;
unsigned has_hibernation:1;
+ unsigned has_lpm_erratum:1;
unsigned is_selfpowered:1;
unsigned needs_fifo_resize:1;
unsigned pullups_connected:1;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc->regs, DWC3_DCFG, reg);

+ if (dwc->has_lpm_erratum) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ }
+
dwc->start_config_issued = false;

/* Start with SuperSpeed Default */
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index 7db34f0..4bcec7c 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+
+ unsigned has_lpm_erratum:1;
};

note that I have also moved DCTL access from gadget_init to
gadget_start.

cheers

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 5:54 PM

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 2:40 PM

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

I just talked to one of our RTL designers. You're right, there is no
way to tell from the Device registers alone whether the controller is
configured with LPM Errata support or not.
You can tell for sure if it is *not* enabled, by checking GSNPSID, and
if the version is earlier than 2.40a, the feature wasn't available.

WARN(rev < 2.40a && (flags & LPM_ERRATA || of_property_read_bool("lpm-errata")),
"LPM Errata not available on dwc3 revisions <= 2.40a\n");

Post by Paul Zimmerman
So for Device-mode only controllers, I guess you will need a DT property
for this.

right, DT property and platform_data feature flag, or something. I don't
wanna call it a quirk though, although it _is_ an erratum WRT LPM
support. Dunno. Any strong feelings ?

Well, it's called LPM Errata because the feature was added to the USB
spec as an erratum. It's not an erratum to our controller. But I don't
have any strong feelings about how the driver support is implemented.

how about adding a "has_lpm_erratum" to struct dwc3 which gets
WARN(dwc->revision < DWC3_REVISION_240A && dwc->has_lpm_erratum",
"LPM Erratum not available on dwc3 revisisions < 2.40a\n");
Then we're not really calling it a quirk. In fact Huang, when respining
your series, let's convert your quirk bits into single-bit fields inside

Looks like a good suggestion.

Post by Felipe Balbi
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..e233ce1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -695,11 +695,13 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
+ dwc->has_lpm_erratum = of_property_read_bool(node, "snps,has-lpm-erratum");
dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize");
dwc->dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
+ dwc->has_lpm_erratum = pdata->has_lpm_erratum; >
dwc->needs_fifo_resize = pdata->tx_fifo_resize;
dwc->dr_mode = pdata->dr_mode;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 66f6256..23e1504 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -661,6 +661,8 @@ struct dwc3_scratchpad_array {
+ * there's now way for software to detect this in runtime.
@@ -764,6 +766,7 @@ struct dwc3 {
unsigned ep0_bounced:1;
unsigned ep0_expect_in:1;
unsigned has_hibernation:1;
+ unsigned has_lpm_erratum:1;
unsigned is_selfpowered:1;
unsigned needs_fifo_resize:1;
unsigned pullups_connected:1;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+ if (dwc->has_lpm_erratum) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ }
+
dwc->start_config_issued = false;
/* Start with SuperSpeed Default */
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index 7db34f0..4bcec7c 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+
+ unsigned has_lpm_erratum:1;
};
note that I have also moved DCTL access from gadget_init to
gadget_start.

Yes, I see. Will update it into V2.

A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.

Any idea to resolve this issue?

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Felipe Balbi]

Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 5:54 PM

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 2:40 PM

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

I just talked to one of our RTL designers. You're right, there is no
way to tell from the Device registers alone whether the controller is
configured with LPM Errata support or not.
You can tell for sure if it is *not* enabled, by checking GSNPSID, and
if the version is earlier than 2.40a, the feature wasn't available.

WARN(rev < 2.40a && (flags & LPM_ERRATA || of_property_read_bool("lpm-errata")),
"LPM Errata not available on dwc3 revisions <= 2.40a\n");

Post by Paul Zimmerman
So for Device-mode only controllers, I guess you will need a DT property
for this.

right, DT property and platform_data feature flag, or something. I don't
wanna call it a quirk though, although it _is_ an erratum WRT LPM
support. Dunno. Any strong feelings ?

Well, it's called LPM Errata because the feature was added to the USB
spec as an erratum. It's not an erratum to our controller. But I don't
have any strong feelings about how the driver support is implemented.

how about adding a "has_lpm_erratum" to struct dwc3 which gets
WARN(dwc->revision < DWC3_REVISION_240A && dwc->has_lpm_erratum",
"LPM Erratum not available on dwc3 revisisions < 2.40a\n");
Then we're not really calling it a quirk. In fact Huang, when respining
your series, let's convert your quirk bits into single-bit fields inside

Looks like a good suggestion.

Post by Felipe Balbi
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..e233ce1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -695,11 +695,13 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
+ dwc->has_lpm_erratum = of_property_read_bool(node, "snps,has-lpm-erratum");
dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize");
dwc->dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
+ dwc->has_lpm_erratum = pdata->has_lpm_erratum; >
dwc->needs_fifo_resize = pdata->tx_fifo_resize;
dwc->dr_mode = pdata->dr_mode;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 66f6256..23e1504 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -661,6 +661,8 @@ struct dwc3_scratchpad_array {
+ * there's now way for software to detect this in runtime.
@@ -764,6 +766,7 @@ struct dwc3 {
unsigned ep0_bounced:1;
unsigned ep0_expect_in:1;
unsigned has_hibernation:1;
+ unsigned has_lpm_erratum:1;
unsigned is_selfpowered:1;
unsigned needs_fifo_resize:1;
unsigned pullups_connected:1;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+ if (dwc->has_lpm_erratum) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ }
+
dwc->start_config_issued = false;
/* Start with SuperSpeed Default */
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index 7db34f0..4bcec7c 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+
+ unsigned has_lpm_erratum:1;
};
note that I have also moved DCTL access from gadget_init to
gadget_start.

Yes, I see. Will update it into V2.
A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.
Any idea to resolve this issue?

that probably won't be the case on final Silicon. I reckon you're using
Synopsys' HAPS for development, right ? That's just how Synopsys
designed the PCIe wrapper to make it easy to test with xHCI. Please make
sure to not use the same PCI header as xHCI on final silicon, otherwise
SW engineers' lifes will become more difficult :-)

Meanwhile, you can just blacklist xhci under /etc/modprobe.d/. Create a
new file (say xhci-blacklist.conf) and add this to it:

blacklist xhci-hcd

Save and restart. xhci-hcd will never load by default anymore, but you
can still manually load it.

Heikki, can you confirm if your DWC3 incarnations present this same
"feature" ? :-)

[Huang Rui]

Post by Felipe Balbi
Hi,

Post by Huang Rui

Post by Felipe Balbi

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 5:54 PM

Post by Paul Zimmerman

Sent: Friday, September 26, 2014 2:40 PM

Post by Paul Zimmerman

Post by Felipe Balbi

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 0fcc0a3..8277065 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2635,6 +2635,7 @@ static irqreturn_t dwc3_interrupt(int irq, void *_dwc)
*/
int dwc3_gadget_init(struct dwc3 *dwc)
{
+ u32 reg;
int ret;
dwc->ctrl_req = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ctrl_req),
@@ -2689,6 +2690,13 @@ int dwc3_gadget_init(struct dwc3 *dwc)
if (ret)
goto err4;
+ if (dwc->quirks & DWC3_AMD_NL_PLAT) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);

weird, why would Synopsys put this here ? It seems like this is only
useful when LPM Errata is enabled and that's, apparently, a host-side
thing.
Paul, can you comment ?

These bits contribute to how the device responds to an LPM transaction
from the host. If DCFG.LPMCap=1, they set the BESL value above which
the core will send a NYET. If DCFG.LPMCap=0, they have no effect. So
it's definitely a device-side thing, but only if the core is configured
with LPM Errata support enabled.

right, and how can SW detect if LPM Errata was enabled ? From the host
point of view, we can check bit 20 of xHCI capability register. What
about device ? I can't seem to find anything :-s

I just talked to one of our RTL designers. You're right, there is no
way to tell from the Device registers alone whether the controller is
configured with LPM Errata support or not.
You can tell for sure if it is *not* enabled, by checking GSNPSID, and
if the version is earlier than 2.40a, the feature wasn't available.

WARN(rev < 2.40a && (flags & LPM_ERRATA || of_property_read_bool("lpm-errata")),
"LPM Errata not available on dwc3 revisions <= 2.40a\n");

Post by Paul Zimmerman
So for Device-mode only controllers, I guess you will need a DT property
for this.

right, DT property and platform_data feature flag, or something. I don't
wanna call it a quirk though, although it _is_ an erratum WRT LPM
support. Dunno. Any strong feelings ?

Well, it's called LPM Errata because the feature was added to the USB
spec as an erratum. It's not an erratum to our controller. But I don't
have any strong feelings about how the driver support is implemented.

how about adding a "has_lpm_erratum" to struct dwc3 which gets
WARN(dwc->revision < DWC3_REVISION_240A && dwc->has_lpm_erratum",
"LPM Erratum not available on dwc3 revisisions < 2.40a\n");
Then we're not really calling it a quirk. In fact Huang, when respining
your series, let's convert your quirk bits into single-bit fields inside

Looks like a good suggestion.

Post by Felipe Balbi
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..e233ce1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -695,11 +695,13 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
+ dwc->has_lpm_erratum = of_property_read_bool(node, "snps,has-lpm-erratum");
dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize");
dwc->dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
+ dwc->has_lpm_erratum = pdata->has_lpm_erratum; >
dwc->needs_fifo_resize = pdata->tx_fifo_resize;
dwc->dr_mode = pdata->dr_mode;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 66f6256..23e1504 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -661,6 +661,8 @@ struct dwc3_scratchpad_array {
+ * there's now way for software to detect this in runtime.
@@ -764,6 +766,7 @@ struct dwc3 {
unsigned ep0_bounced:1;
unsigned ep0_expect_in:1;
unsigned has_hibernation:1;
+ unsigned has_lpm_erratum:1;
unsigned is_selfpowered:1;
unsigned needs_fifo_resize:1;
unsigned pullups_connected:1;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+ if (dwc->has_lpm_erratum) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ }
+
dwc->start_config_issued = false;
/* Start with SuperSpeed Default */
diff --git a/drivers/usb/dwc3/platform_data.h b/drivers/usb/dwc3/platform_data.h
index 7db34f0..4bcec7c 100644
--- a/drivers/usb/dwc3/platform_data.h
+++ b/drivers/usb/dwc3/platform_data.h
@@ -24,4 +24,6 @@ struct dwc3_platform_data {
enum usb_device_speed maximum_speed;
enum usb_dr_mode dr_mode;
bool tx_fifo_resize;
+
+ unsigned has_lpm_erratum:1;
};
note that I have also moved DCTL access from gadget_init to
gadget_start.

Yes, I see. Will update it into V2.
A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.
Any idea to resolve this issue?

that probably won't be the case on final Silicon. I reckon you're using
Synopsys' HAPS for development, right ? That's just how Synopsys
designed the PCIe wrapper to make it easy to test with xHCI. Please make
sure to not use the same PCI header as xHCI on final silicon, otherwise
SW engineers' lifes will become more difficult :-)

Unfortunately, this will go to the final solution for supporting
windows. As you known, windows doesn't support USB Device mode, so it
will act as "xHC" on windows os and PCI class code must set as
0x0c0330.

Can I add a blacklist into xhci or pci driver, to ignore the binding
behavoir on specific product id and vendor id.

Post by Felipe Balbi
Meanwhile, you can just blacklist xhci under /etc/modprobe.d/. Create a
blacklist xhci-hcd
Save and restart. xhci-hcd will never load by default anymore, but you
can still manually load it.

Yes, this is another workaround, but still do some action manually.

Thanks,
Rui

Post by Felipe Balbi
Heikki, can you confirm if your DWC3 incarnations present this same
"feature" ? :-)
--
balbi

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Heikki Krogerus]

Post by Felipe Balbi

Post by Huang Rui
A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.
Any idea to resolve this issue?

Declare a fixup quirk. I'm not a pci expert, but I think something
like this should work..

static void dwc3_fix_amd_nl_class(struct pci_dev *pdev)
{
pdev->class = 0x0c03fe;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL,
dwc3_fix_amd_nl_class);

Post by Felipe Balbi
Heikki, can you confirm if your DWC3 incarnations present this same
"feature" ? :-)

The DWC3 is not given xHCI class code on our boards.


Cheers,

[Huang Rui]

Post by Heikki Krogerus

Post by Huang Rui
A question, the dwc3 controller is the PCI-E device in my platform,
but the class code of PCI header is 0x0c0330, the same with xHC.
That's because it need to meet the windows enviroment. The dwc3
controller acted as only host mode to bind with windows xhci driver.
But on linux, sometimes, we auto-bind with xhci driver as well (class
code 0x0c0330) despite we use Pid/Vid on dwc3 driver. Then I need
rmmod xhci_hcd module and modprobe dwc3_pci module manually.
Any idea to resolve this issue?

Declare a fixup quirk. I'm not a pci expert, but I think something
like this should work..
static void dwc3_fix_amd_nl_class(struct pci_dev *pdev)
{
pdev->class = 0x0c03fe;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL,
dwc3_fix_amd_nl_class);

Heikki, your info inspires me. :)

I looked at pci driver, this update should put in pci/quirks.c.
Because the behavior of the global pci_fixups_header array is
maintained at that file.
When system inits, pci driver would load fixup devices before driver
attached. So it should define the fixup header under pci/quirks.c.

After do some tests in my side. This quirk works well.

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-***@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Paul Zimmerman]

Sent: Friday, September 26, 2014 9:31 PM

Post by Paul Zimmerman
Well, it's called LPM Errata because the feature was added to the USB
spec as an erratum. It's not an erratum to our controller. But I don't
have any strong feelings about how the driver support is implemented.

how about adding a "has_lpm_erratum" to struct dwc3 which gets
WARN(dwc->revision < DWC3_REVISION_240A && dwc->has_lpm_erratum",
"LPM Erratum not available on dwc3 revisisions < 2.40a\n");
Then we're not really calling it a quirk. In fact Huang, when respining
your series, let's convert your quirk bits into single-bit fields inside
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 4d4e854..e233ce1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -695,11 +695,13 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc->maximum_speed = of_usb_get_maximum_speed(node);
+ dwc->has_lpm_erratum = of_property_read_bool(node, "snps,has-lpm-erratum");
dwc->needs_fifo_resize = of_property_read_bool(node, "tx-fifo-resize");
dwc->dr_mode = of_usb_get_dr_mode(node);
} else if (pdata) {
dwc->maximum_speed = pdata->maximum_speed;
+ dwc->has_lpm_erratum = pdata->has_lpm_erratum;
dwc->needs_fifo_resize = pdata->tx_fifo_resize;
dwc->dr_mode = pdata->dr_mode;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 66f6256..23e1504 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -661,6 +661,8 @@ struct dwc3_scratchpad_array {
+ * there's now way for software to detect this in runtime.
@@ -764,6 +766,7 @@ struct dwc3 {
unsigned ep0_bounced:1;
unsigned ep0_expect_in:1;
unsigned has_hibernation:1;
+ unsigned has_lpm_erratum:1;
unsigned is_selfpowered:1;
unsigned needs_fifo_resize:1;
unsigned pullups_connected:1;
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+ if (dwc->has_lpm_erratum) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ }

Yes, I think this really wants to be configurable. The value used is
supposed to depend on the latencies in the system etc.

[Felipe Balbi]

Hi,

Post by Paul Zimmerman

Post by Huang Rui
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 68497b3..112352e 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1577,6 +1577,13 @@ static int dwc3_gadget_start(struct usb_gadget *g,
}
dwc3_writel(dwc->regs, DWC3_DCFG, reg);
+ if (dwc->has_lpm_erratum) {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ /* REVISIT should this be configurable ? */
+ reg |= DWC3_DCTL_LPM_ERRATA(0xf);
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ }

Yes, I think this really wants to be configurable. The value used is
supposed to depend on the latencies in the system etc.

alright, in that case we need to pass that through DT/pdata as well.