[PATCH v3 0/5] Add support for SW babble Control

[PATCH v3 0/5] Add support for SW babble Control

[George Cherian]

Series add support for SW babble control logic found in 
new silicon versions of AM335x. Runtime differentiation of
silicon version is done by checking the BABBLE_CTL register.
For newer silicon the register default value read is 0x4 and
for older versions its 0x0.

Patch 1 -> Convert recover work to delayed work.
Patch 2 -> usb_phy_vbus_(off/_on) are NOPs for am335x PHY
	   so use usb_phy(_shutdown/_init) in musb_platform_reset()
Patch 3 -> Add return value for musb_platform_reset() in prepration
	   to support SW babble_ctrl
Patch 4 -> Add the sw_babble_control()
Patch 5 -> Enable sw babble control for newer silicon
	
v2 -> v3 : Modify musb_platform_reset() to return zero on success.

v1 -> v2 : Fixed the issue with Patch 5. In v1 it was not calling 
	   sw_babble_control().

George Cherian (5):
  usb: musb: core: Convert babble recover work to delayed work
  usb: musb: dsps: Call usb_phy(_shutdown/_init) during
    musb_platform_reset()
  usb: musb: core: Convert the musb_platform_reset to have a return
    value.
  usb: musb: dsps: Add the sw_babble_control()
  usb: musb: dsps: Enable sw babble control for newer silicon

 drivers/usb/musb/musb_core.c | 49 ++++++++++++++------------
 drivers/usb/musb/musb_core.h | 12 ++++---
 drivers/usb/musb/musb_dsps.c | 83 ++++++++++++++++++++++++++++++++++++++++++--
 drivers/usb/musb/musb_regs.h |  7 ++++
 4 files changed, 121 insertions(+), 30 deletions(-)

-- 
1.8.3.1

[PATCH v3 1/5] usb: musb: core: Convert babble recover work to delayed work

[George Cherian]

During babble condition both first disconnect of devices are
initiated. Make sure MUSB controller is reset and re-initialized
after all disconnects.

To acheive this schedule a delayed work for babble rrecovery.

While at that convert udelay to usleep_range.
Refer Documentation/timers/timers-howto.txt

Signed-off-by: George Cherian <george.cherian@ti.com>
---
 drivers/usb/musb/musb_core.c | 15 ++++++++-------
 drivers/usb/musb/musb_core.h |  2 +-
 2 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 61da471..dcadc62 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -850,7 +850,8 @@ b_host:
 
 	/* handle babble condition */
 	if (int_usb & MUSB_INTR_BABBLE)
-		schedule_work(&musb->recover_work);
+		schedule_delayed_work(&musb->recover_work,
+				      msecs_to_jiffies(100));
 
 #if 0
 /* REVISIT ... this would be for multiplexing periodic endpoints, or
@@ -1753,16 +1754,16 @@ static void musb_irq_work(struct work_struct *data)
 /* Recover from babble interrupt conditions */
 static void musb_recover_work(struct work_struct *data)
 {
-	struct musb *musb = container_of(data, struct musb, recover_work);
+	struct musb *musb = container_of(data, struct musb, recover_work.work);
 	int status;
 
 	musb_platform_reset(musb);
 
 	usb_phy_vbus_off(musb->xceiv);
-	udelay(100);
+	usleep_range(100, 200);
 
 	usb_phy_vbus_on(musb->xceiv);
-	udelay(100);
+	usleep_range(100, 200);
 
 	/*
 	 * When a babble condition occurs, the musb controller removes the
@@ -1945,7 +1946,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
 
 	/* Init IRQ workqueue before request_irq */
 	INIT_WORK(&musb->irq_work, musb_irq_work);
-	INIT_WORK(&musb->recover_work, musb_recover_work);
+	INIT_DELAYED_WORK(&musb->recover_work, musb_recover_work);
 	INIT_DELAYED_WORK(&musb->deassert_reset_work, musb_deassert_reset);
 	INIT_DELAYED_WORK(&musb->finish_resume_work, musb_host_finish_resume);
 
@@ -2041,7 +2042,7 @@ fail4:
 
 fail3:
 	cancel_work_sync(&musb->irq_work);
-	cancel_work_sync(&musb->recover_work);
+	cancel_delayed_work_sync(&musb->recover_work);
 	cancel_delayed_work_sync(&musb->finish_resume_work);
 	cancel_delayed_work_sync(&musb->deassert_reset_work);
 	if (musb->dma_controller)
@@ -2107,7 +2108,7 @@ static int musb_remove(struct platform_device *pdev)
 		dma_controller_destroy(musb->dma_controller);
 
 	cancel_work_sync(&musb->irq_work);
-	cancel_work_sync(&musb->recover_work);
+	cancel_delayed_work_sync(&musb->recover_work);
 	cancel_delayed_work_sync(&musb->finish_resume_work);
 	cancel_delayed_work_sync(&musb->deassert_reset_work);
 	musb_free(musb);
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 47e8874..423cd00 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -297,7 +297,7 @@ struct musb {
 
 	irqreturn_t		(*isr)(int, void *);
 	struct work_struct	irq_work;
-	struct work_struct	recover_work;
+	struct delayed_work	recover_work;
 	struct delayed_work	deassert_reset_work;
 	struct delayed_work	finish_resume_work;
 	u16			hwvers;
-- 
1.8.3.1

[PATCH v3 2/5] usb: musb: dsps: Call usb_phy(_shutdown/_init) during musb_platform_reset()

[George Cherian]

For DSPS platform usb_phy_vbus(_off/_on) are NOPs.
So during musb_platform_reset() call usb_phy(_shutdown/_init)

Signed-off-by: George Cherian <george.cherian@ti.com>
---
 drivers/usb/musb/musb_dsps.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 51beb13..74c4193 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -543,7 +543,11 @@ static void dsps_musb_reset(struct musb *musb)
 	const struct dsps_musb_wrapper *wrp = glue->wrp;
 
 	dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
-	udelay(100);
+	usleep_range(100, 200);
+	usb_phy_shutdown(musb->xceiv);
+	usleep_range(100, 200);
+	usb_phy_init(musb->xceiv);
+
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
1.8.3.1

[PATCH v3 3/5] usb: musb: core: Convert the musb_platform_reset to have a return value.

[George Cherian]

Currently musb_platform_reset() is only used by dsps.
In case of BABBLE interrupt for other platforms the  musb_platform_reset()
is a NOP. In such situations no need to re-initialize the endpoints.
Also in the latest silicon revision of AM335x, we do have a babble recovery
mechanism without resetting the IP block. In preperation to add that support
its better to have a rest_done return for  musb_platform_reset().

Signed-off-by: George Cherian <george.cherian@ti.com>
---
 drivers/usb/musb/musb_core.c | 38 +++++++++++++++++++++-----------------
 drivers/usb/musb/musb_core.h | 10 ++++++----
 drivers/usb/musb/musb_dsps.c |  3 ++-
 3 files changed, 29 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index dcadc62..1f8b175 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1755,28 +1755,32 @@ static void musb_irq_work(struct work_struct *data)
 static void musb_recover_work(struct work_struct *data)
 {
 	struct musb *musb = container_of(data, struct musb, recover_work.work);
-	int status;
+	int status, ret;
 
-	musb_platform_reset(musb);
+	ret  = musb_platform_reset(musb);
+	if (ret  < 0)
+		return;
 
-	usb_phy_vbus_off(musb->xceiv);
-	usleep_range(100, 200);
+	if (!ret) {
+		usb_phy_vbus_off(musb->xceiv);
+		usleep_range(100, 200);
 
-	usb_phy_vbus_on(musb->xceiv);
-	usleep_range(100, 200);
+		usb_phy_vbus_on(musb->xceiv);
+		usleep_range(100, 200);
 
-	/*
-	 * When a babble condition occurs, the musb controller removes the
-	 * session bit and the endpoint config is lost.
-	 */
-	if (musb->dyn_fifo)
-		status = ep_config_from_table(musb);
-	else
-		status = ep_config_from_hw(musb);
+		/*
+		 * When a babble condition occurs, the musb controller removes the
+		 * session bit and the endpoint config is lost.
+		 */
+		if (musb->dyn_fifo)
+			status = ep_config_from_table(musb);
+		else
+			status = ep_config_from_hw(musb);
 
-	/* start the session again */
-	if (status == 0)
-		musb_start(musb);
+		/* start the session again */
+		if (status == 0)
+			musb_start(musb);
+	}
 }
 
 /* --------------------------------------------------------------------------
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 423cd00..3ccb428 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -192,7 +192,7 @@ struct musb_platform_ops {
 
 	int	(*set_mode)(struct musb *musb, u8 mode);
 	void	(*try_idle)(struct musb *musb, unsigned long timeout);
-	void	(*reset)(struct musb *musb);
+	int	(*reset)(struct musb *musb);
 
 	int	(*vbus_status)(struct musb *musb);
 	void	(*set_vbus)(struct musb *musb, int on);
@@ -554,10 +554,12 @@ static inline void musb_platform_try_idle(struct musb *musb,
 		musb->ops->try_idle(musb, timeout);
 }
 
-static inline void musb_platform_reset(struct musb *musb)
+static inline int  musb_platform_reset(struct musb *musb)
 {
-	if (musb->ops->reset)
-		musb->ops->reset(musb);
+	if (!musb->ops->reset)
+		return -EINVAL;
+
+	return musb->ops->reset(musb);
 }
 
 static inline int musb_platform_get_vbus_status(struct musb *musb)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 74c4193..f6f3087 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,7 +536,7 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
 	return 0;
 }
 
-static void dsps_musb_reset(struct musb *musb)
+static int dsps_musb_reset(struct musb *musb)
 {
 	struct device *dev = musb->controller;
 	struct dsps_glue *glue = dev_get_drvdata(dev->parent);
@@ -548,6 +548,7 @@ static void dsps_musb_reset(struct musb *musb)
 	usleep_range(100, 200);
 	usb_phy_init(musb->xceiv);
 
+	return 0;
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
1.8.3.1

[PATCH v3 4/5] usb: musb: dsps: Add the sw_babble_control()

[George Cherian]

Add sw_babble_control() logic to differentiate between transient
babble and real babble condition. Also add the SW babble control
register definitions.

Babble control register logic is implemented in the latest
revision of AM335x.

Signed-off-by: George Cherian <george.cherian@ti.com>
---
 drivers/usb/musb/musb_dsps.c | 50 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/usb/musb/musb_regs.h |  7 +++++++
 2 files changed, 57 insertions(+)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index f6f3087..eb1985a 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -536,6 +536,56 @@ static int dsps_musb_set_mode(struct musb *musb, u8 mode)
 	return 0;
 }
 
+static int sw_babble_control(struct musb *musb)
+{
+	int timeout = 10;
+	u8 babble_ctl, session_restart = 0;
+
+	babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+	dev_dbg(musb->controller, "babble: MUSB_BABBLE_CTL value %x\n",
+		babble_ctl);
+	/*
+	 * check line monitor flag to check whether babble is
+	 * due to noise
+	 */
+	dev_dbg(musb->controller, "STUCK_J is %s\n",
+		babble_ctl & MUSB_BABBLE_STUCK_J ? "set" : "reset");
+
+	if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+		/*
+		 * babble is due to noise, then set transmit idle (d7 bit)
+		 * to resume normal operation
+		 */
+		babble_ctl = musb_readb(musb->mregs, MUSB_BABBLE_CTL);
+		babble_ctl |= MUSB_BABBLE_FORCE_TXIDLE;
+		dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, babble_ctl);
+
+		/* wait till line monitor flag cleared */
+		dev_dbg(musb->controller, "Set TXIDLE, wait J to clear\n");
+		do {
+			babble_ctl = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+			udelay(1);
+		} while ((babble_ctl & MUSB_BABBLE_STUCK_J) && timeout--);
+
+		/* check whether stuck_at_j bit cleared */
+		if (babble_ctl & MUSB_BABBLE_STUCK_J) {
+			/*
+			 * real babble condition is occured
+			 * restart the controller to start the
+			 * session again
+			 */
+			dev_dbg(musb->controller, "J not cleared, misc (%x)\n",
+				babble_ctl);
+			session_restart = 1;
+		}
+
+	} else {
+		session_restart = 1;
+	}
+
+	return session_restart;
+}
+
 static int dsps_musb_reset(struct musb *musb)
 {
 	struct device *dev = musb->controller;
diff --git a/drivers/usb/musb/musb_regs.h b/drivers/usb/musb/musb_regs.h
index 03f2655..b9bcda5 100644
--- a/drivers/usb/musb/musb_regs.h
+++ b/drivers/usb/musb/musb_regs.h
@@ -72,6 +72,12 @@
 #define MUSB_DEVCTL_HR		0x02
 #define MUSB_DEVCTL_SESSION	0x01
 
+/* BABBLE_CTL */
+#define MUSB_BABBLE_FORCE_TXIDLE	0x80
+#define MUSB_BABBLE_SW_SESSION_CTRL	0x40
+#define MUSB_BABBLE_STUCK_J		0x20
+#define MUSB_BABBLE_RCV_DISABLE		0x04
+
 /* MUSB ULPI VBUSCONTROL */
 #define MUSB_ULPI_USE_EXTVBUS	0x01
 #define MUSB_ULPI_USE_EXTVBUSIND 0x02
@@ -246,6 +252,7 @@
  */
 
 #define MUSB_DEVCTL		0x60	/* 8 bit */
+#define MUSB_BABBLE_CTL		0x61	/* 8 bit */
 
 /* These are always controlled through the INDEX register */
 #define MUSB_TXFIFOSZ		0x62	/* 8-bit (see masks) */
-- 
1.8.3.1

[PATCH v3 5/5] usb: musb: dsps: Enable sw babble control for newer silicon

[George Cherian]

Find whether we are running on newer silicon. The babble control
register reads 0x4 by default in newer silicon as opposed to 0
in old versions of AM335x. Based on this enable the sw babble
control logic.

Signed-off-by: George Cherian <george.cherian@ti.com>
---
 drivers/usb/musb/musb_dsps.c | 34 ++++++++++++++++++++++++++++------
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index eb1985a..1ae6681 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -136,6 +136,7 @@ struct dsps_glue {
 	const struct dsps_musb_wrapper *wrp; /* wrapper register offsets */
 	struct timer_list timer;	/* otg_workaround timer */
 	unsigned long last_timer;    /* last timer data for each instance */
+	bool sw_babble_enabled;
 
 	struct dsps_context context;
 	struct debugfs_regset32 regset;
@@ -469,6 +470,16 @@ static int dsps_musb_init(struct musb *musb)
 	val &= ~(1 << wrp->otg_disable);
 	dsps_writel(musb->ctrl_base, wrp->phy_utmi, val);
 
+	/*
+	 *  Check whether the dsps version has babble control enabled.
+	 * In latest silicon revision the babble control logic is enabled.
+	 * If MUSB_BABBLE_CTL returns 0x4 then we have the babble control
+	 * logic enabled.
+	 */
+	val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
+	if (val == MUSB_BABBLE_RCV_DISABLE)
+		glue->sw_babble_enabled = true;
+
 	ret = dsps_musb_dbg_init(musb, glue);
 	if (ret)
 		return ret;
@@ -591,14 +602,25 @@ static int dsps_musb_reset(struct musb *musb)
 	struct device *dev = musb->controller;
 	struct dsps_glue *glue = dev_get_drvdata(dev->parent);
 	const struct dsps_musb_wrapper *wrp = glue->wrp;
+	int session_restart = 0;
 
-	dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
-	usleep_range(100, 200);
-	usb_phy_shutdown(musb->xceiv);
-	usleep_range(100, 200);
-	usb_phy_init(musb->xceiv);
+	if (glue->sw_babble_enabled)
+		session_restart = sw_babble_control(musb);
+	/*
+	 * In case of new silicon version babble condition can be recovered
+	 * without resetting the MUSB. But for older silicon versions, MUSB
+	 * reset is needed
+	 */
+	if (session_restart || !glue->sw_babble_enabled) {
+		dsps_writel(musb->ctrl_base, wrp->control, (1 << wrp->reset));
+		usleep_range(100, 200);
+		usb_phy_shutdown(musb->xceiv);
+		usleep_range(100, 200);
+		usb_phy_init(musb->xceiv);
+		session_restart = 1;
+	}
 
-	return 0;
+	return !session_restart;
 }
 
 static struct musb_platform_ops dsps_ops = {
-- 
1.8.3.1

Re: [PATCH v3 0/5] Add support for SW babble Control

[Daniel Mack]

Hi George,

On 05/13/2014 10:31 AM, George Cherian wrote:
> Series add support for SW babble control logic found in 
> new silicon versions of AM335x. Runtime differentiation of
> silicon version is done by checking the BABBLE_CTL register.
> For newer silicon the register default value read is 0x4 and
> for older versions its 0x0.

I tested this on a AM33xx platform and don't see any regression at
least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
Anything particular you want me to test as well?


Thanks,
Daniel

Re: [PATCH v3 0/5] Add support for SW babble Control

[George Cherian]

On 5/13/2014 3:16 PM, Daniel Mack wrote:
> Hi George,
>
> On 05/13/2014 10:31 AM, George Cherian wrote:
>> Series add support for SW babble control logic found in
>> new silicon versions of AM335x. Runtime differentiation of
>> silicon version is done by checking the BABBLE_CTL register.
>> For newer silicon the register default value read is 0x4 and
>> for older versions its 0x0.
> I tested this on a AM33xx platform and don't see any regression at
> least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
> Anything particular you want me to test as well?
Are you seeing a wrapper restart done always or does it continue with a 
restart
after the babble condition?

You can check for
"musb_hdrc: setup fifo_mode 4" prints .
>
>
> Thanks,
> Daniel
>


-- 
-George

Re: [PATCH v3 0/5] Add support for SW babble Control

[Daniel Mack]

On 05/13/2014 01:57 PM, George Cherian wrote:
> On 5/13/2014 3:16 PM, Daniel Mack wrote:
>> On 05/13/2014 10:31 AM, George Cherian wrote:
>>> Series add support for SW babble control logic found in
>>> new silicon versions of AM335x. Runtime differentiation of
>>> silicon version is done by checking the BABBLE_CTL register.
>>> For newer silicon the register default value read is 0x4 and
>>> for older versions its 0x0.
>> I tested this on a AM33xx platform and don't see any regression at
>> least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
>> Anything particular you want me to test as well?
> Are you seeing a wrapper restart done always or does it continue with a 
> restart
> after the babble condition?

MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is
called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns
0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means
(babble_ctl & MUSB_BABBLE_STUCK_J) is false, and hence
sw_babble_control() returns 1. Consequently, the glue is fully reset in
this case. Does this help?

FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled:

[   54.066124] CAUTION: musb: Babble Interrupt Occurred
[   54.071856] usb 1-1: USB disconnect, device number 8
[   54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4
[   54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


I only have one exact USB device to reproduce the babble condition, so I
guess this is all I can do for now.


Thanks,
Daniel

Re: [PATCH v3 0/5] Add support for SW babble Control

[George Cherian]

On 5/13/2014 5:50 PM, Daniel Mack wrote:
> On 05/13/2014 01:57 PM, George Cherian wrote:
>> On 5/13/2014 3:16 PM, Daniel Mack wrote:
>>> On 05/13/2014 10:31 AM, George Cherian wrote:
>>>> Series add support for SW babble control logic found in
>>>> new silicon versions of AM335x. Runtime differentiation of
>>>> silicon version is done by checking the BABBLE_CTL register.
>>>> For newer silicon the register default value read is 0x4 and
>>>> for older versions its 0x0.
>>> I tested this on a AM33xx platform and don't see any regression at
>>> least. This hardware has MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE.
>>> Anything particular you want me to test as well?
>> Are you seeing a wrapper restart done always or does it continue with a
>> restart
>> after the babble condition?
> MUSB_BABBLE_CTL == MUSB_BABBLE_RCV_DISABLE, so sw_babble_control() is
> called from dsps_musb_reset(). However, MUSB_BABBLE_CTL still returns
> 0x04 (MUSB_BABBLE_RCV_DISABLE) inside that function, which means
> (babble_ctl & MUSB_BABBLE_STUCK_J) is false, and hence
> sw_babble_control() returns 1.
Ah.... Missed a critical portion....
My bad...

I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
can you try with the following patch.

diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
  	 * logic enabled.
  	 */
  	val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
-	if (val == MUSB_BABBLE_RCV_DISABLE)
+	if (val == MUSB_BABBLE_RCV_DISABLE) {
  		glue->sw_babble_enabled = true;
+		val |= MUSB_BABBLE_SW_SESSION_CTRL;
+	        dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
+	}
  
  	ret = dsps_musb_dbg_init(musb, glue);
  	if (ret)
-- 1.8.3.1

I will resend the series, if this works fine.
Thanks for all your help.

>   Consequently, the glue is fully reset in
> this case. Does this help?
>
> FWIW, this is the output of dsps_musb_reset() with dev_dbg() enabled:
>
> [   54.066124] CAUTION: musb: Babble Interrupt Occurred
> [   54.071856] usb 1-1: USB disconnect, device number 8
> [   54.159495] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 4
> [   54.166446] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>
>
> I only have one exact USB device to reproduce the babble condition, so I
> guess this is all I can do for now.
Same with me also . I also have only one device with which i get the issue.
>
>
> Thanks,
> Daniel
>


-- 
-George

Re: [PATCH v3 0/5] Add support for SW babble Control

[Daniel Mack]

Hi George,

On 05/13/2014 02:57 PM, George Cherian wrote:
> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
> can you try with the following patch.
> 
> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
> index 1ae6681..1160cd1 100644
> --- a/drivers/usb/musb/musb_dsps.c
> +++ b/drivers/usb/musb/musb_dsps.c
> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>   	 * logic enabled.
>   	 */
>   	val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
> -	if (val == MUSB_BABBLE_RCV_DISABLE)
> +	if (val == MUSB_BABBLE_RCV_DISABLE) {
>   		glue->sw_babble_enabled = true;
> +		val |= MUSB_BABBLE_SW_SESSION_CTRL;
> +	        dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
> +	}
>   
>   	ret = dsps_musb_dbg_init(musb, glue);
>   	if (ret)

MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?


[   19.672373] CAUTION: musb: Babble Interrupt Occurred
[   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[   19.685815] usb 1-1: USB disconnect, device number 3
[   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
[   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset


I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?

Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?


Daniel

Re: [PATCH v3 0/5] Add support for SW babble Control

[George Cherian]

Hi Daniel,

On 5/13/2014 6:44 PM, Daniel Mack wrote:
> Hi George,
>
> On 05/13/2014 02:57 PM, George Cherian wrote:
>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL reg.
>> can you try with the following patch.
>>
>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
>> index 1ae6681..1160cd1 100644
>> --- a/drivers/usb/musb/musb_dsps.c
>> +++ b/drivers/usb/musb/musb_dsps.c
>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>    	 * logic enabled.
>>    	 */
>>    	val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>> -	if (val == MUSB_BABBLE_RCV_DISABLE)
>> +	if (val == MUSB_BABBLE_RCV_DISABLE) {
>>    		glue->sw_babble_enabled = true;
>> +		val |= MUSB_BABBLE_SW_SESSION_CTRL;
>> +	        dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>> +	}
>>    
>>    	ret = dsps_musb_dbg_init(musb, glue);
>>    	if (ret)
> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
> without the patch: a full glue reset is conducted. Do I get you right
> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
> MUSB_BABBLE_SW_SESSION_CTRL is set?
>
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an 
IP reset .
2) Babble condition - which could be recovered from only by doing an IP 
reset.

Looks like you are always hitting case 2 (Most times am also hitting the 
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of 
now to
reproduce this case consistently.
> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
> (a_wait_bcon)
> [   19.685815] usb 1-1: USB disconnect, device number 3
> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value 44
> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>
>
> I don't quite follow, especially as I lack documentation of the IP core.
> How do you test babble errors, is there any way to force them to happen
> reliably?

There is no 100% reliable method to force it to happen. Following is
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
> Anyway, the full glue layer solves this rare condition quite well for
> me. Is there any downside of this?
>
>
> Daniel
>


-- 
-George

Re: [PATCH v3 0/5] Add support for SW babble Control

[Daniel Mack]

On 05/13/2014 03:24 PM, George Cherian wrote:
> Basically, there are 2 types of babble conditions.
> 1) Transient babble condition - which could be recovered from without an 
> IP reset .
> 2) Babble condition - which could be recovered from only by doing an IP 
> reset.

Ok, thanks for the explanation.

> Looks like you are always hitting case 2 (Most times am also hitting the 
> same).

Seems like, yes.

> There is no 100% reliable method to force it to happen. Following is
> my setup ,
> I have a HUB with 4 devices connected , which gives me a Babble interrupt
> on both connects and disconnects ( Not always though).

I also get them at disconnects, but only with one specific USB device.

But as I don't ever see case 1) above, I can't say if your approach
works. What I can say, though, is that your patches don't break the
recovery from babble conditions that I experienced :)


Daniel

Re: [PATCH v3 0/5] Add support for SW babble Control

[Bin Liu]

Hi,

On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com> wrote:
> Hi Daniel,
>
>
> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>
>> Hi George,
>>
>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>
>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
>>> reg.
>>> can you try with the following patch.
>>>
>>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
>>> index 1ae6681..1160cd1 100644
>>> --- a/drivers/usb/musb/musb_dsps.c
>>> +++ b/drivers/usb/musb/musb_dsps.c
>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>          * logic enabled.
>>>          */
>>>         val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>                 glue->sw_babble_enabled = true;
>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>> +       }
>>>         ret = dsps_musb_dbg_init(musb, glue);
>>>         if (ret)
>>
>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>> without the patch: a full glue reset is conducted. Do I get you right
>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>
> Basically, there are 2 types of babble conditions.
> 1) Transient babble condition - which could be recovered from without an IP
> reset .
> 2) Babble condition - which could be recovered from only by doing an IP
> reset.
>
> Looks like you are always hitting case 2 (Most times am also hitting the
> same).
> Case 1 is really hard to reproduce. I don't have a reliable method as of now
> to
> reproduce this case consistently.
>
>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>> (a_wait_bcon)
>> [   19.685815] usb 1-1: USB disconnect, device number 3
>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
>> 44
>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>
>>
>> I don't quite follow, especially as I lack documentation of the IP core.
>> How do you test babble errors, is there any way to force them to happen
>> reliably?
>
>
> There is no 100% reliable method to force it to happen. Following is

I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.

But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.

So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.

Regards,
-Bin.

> my setup ,
> I have a HUB with 4 devices connected , which gives me a Babble interrupt
> on both connects and disconnects ( Not always though).
>
>> Anyway, the full glue layer solves this rare condition quite well for
>> me. Is there any downside of this?
>>
>>
>> Daniel
>>
>
>
> --
> -George
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/5] Add support for SW babble Control

[George Cherian]

On 5/14/2014 12:07 AM, Bin Liu wrote:
> Hi,
>
> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com> wrote:
>> Hi Daniel,
>>
>>
>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>> Hi George,
>>>
>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
>>>> reg.
>>>> can you try with the following patch.
>>>>
>>>> diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
>>>> index 1ae6681..1160cd1 100644
>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>           * logic enabled.
>>>>           */
>>>>          val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>                  glue->sw_babble_enabled = true;
>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>> +       }
>>>>          ret = dsps_musb_dbg_init(musb, glue);
>>>>          if (ret)
>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>>> without the patch: a full glue reset is conducted. Do I get you right
>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>
>> Basically, there are 2 types of babble conditions.
>> 1) Transient babble condition - which could be recovered from without an IP
>> reset .
>> 2) Babble condition - which could be recovered from only by doing an IP
>> reset.
>>
>> Looks like you are always hitting case 2 (Most times am also hitting the
>> same).
>> Case 1 is really hard to reproduce. I don't have a reliable method as of now
>> to
>> reproduce this case consistently.
>>
>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>> (a_wait_bcon)
>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
>>> 44
>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>
>>>
>>> I don't quite follow, especially as I lack documentation of the IP core.
>>> How do you test babble errors, is there any way to force them to happen
>>> reliably?
>>
>> There is no 100% reliable method to force it to happen. Following is
> I have a way to force babble happen reliably - shorting DP or DM to
> VBUS. I opened the far-end plug of the USB cable, so I can easily
> short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
> But the interesting thing is that with TI 3.2 kernel, shorting DP or
> DM to VBUS causes MISC register to be 0x4, but the result is
> completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
>
> So in the 3.2 kernel, the babble handing resets the controller, but
> the 3.12.10 does not.
>
> Regards,
> -Bin.
>
>> my setup ,
>> I have a HUB with 4 devices connected , which gives me a Babble interrupt
>> on both connects and disconnects ( Not always though).
>>
>>> Anyway, the full glue layer solves this rare condition quite well for
>>> me. Is there any downside of this?
>>>
>>>
>>> Daniel
>>>
>>
>> --
>> -George
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
-George

Re: [PATCH v3 0/5] Add support for SW babble Control

[Bin Liu]

George,

On Wed, May 14, 2014 at 12:37 AM, George Cherian <george.cherian@ti.com> wrote:
> On 5/14/2014 12:07 AM, Bin Liu wrote:
>>
>> Hi,
>>
>> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com>
>> wrote:
>>>
>>> Hi Daniel,
>>>
>>>
>>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>>>
>>>> Hi George,
>>>>
>>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>>>
>>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
>>>>> reg.
>>>>> can you try with the following patch.
>>>>>
>>>>> diff --git a/drivers/usb/musb/musb_dsps.c
>>>>> b/drivers/usb/musb/musb_dsps.c
>>>>> index 1ae6681..1160cd1 100644
>>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>>           * logic enabled.
>>>>>           */
>>>>>          val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>>                  glue->sw_babble_enabled = true;
>>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>>> +       }
>>>>>          ret = dsps_musb_dbg_init(musb, glue);
>>>>>          if (ret)
>>>>
>>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>>>> without the patch: a full glue reset is conducted. Do I get you right
>>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
>>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>>
>>> Basically, there are 2 types of babble conditions.
>>> 1) Transient babble condition - which could be recovered from without an
>>> IP
>>> reset .
>>> 2) Babble condition - which could be recovered from only by doing an IP
>>> reset.
>>>
>>> Looks like you are always hitting case 2 (Most times am also hitting the
>>> same).
>>> Case 1 is really hard to reproduce. I don't have a reliable method as of
>>> now
>>> to
>>> reproduce this case consistently.
>>>
>>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>>> (a_wait_bcon)
>>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
>>>> 44
>>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>>
>>>>
>>>> I don't quite follow, especially as I lack documentation of the IP core.
>>>> How do you test babble errors, is there any way to force them to happen
>>>> reliably?
>>>
>>>
>>> There is no 100% reliable method to force it to happen. Following is
>>
>> I have a way to force babble happen reliably - shorting DP or DM to
>> VBUS. I opened the far-end plug of the USB cable, so I can easily
>> short DP or DM to VBUS.
>
> Good to know that you have a reliable way to test babble condition.
> Can you please do a quick test on 3.15.0-rc4 with the series applied?
> In case of any assistance please do let me know.

Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?

I read these linux-usb emails in Gmail, and  am not aware of any easy
way to extract patches from Gmail.

BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.

Thanks,
-Bin.

>
>> But the interesting thing is that with TI 3.2 kernel, shorting DP or
>> DM to VBUS causes MISC register to be 0x4, but the result is
>> completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
>>
>> So in the 3.2 kernel, the babble handing resets the controller, but
>> the 3.12.10 does not.
>>
>> Regards,
>> -Bin.
>>
>>> my setup ,
>>> I have a HUB with 4 devices connected , which gives me a Babble interrupt
>>> on both connects and disconnects ( Not always though).
>>>
>>>> Anyway, the full glue layer solves this rare condition quite well for
>>>> me. Is there any downside of this?
>>>>
>>>>
>>>> Daniel
>>>>
>>>
>>> --
>>> -George
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> -George
>

Re: [PATCH v3 0/5] Add support for SW babble Control

[Bin Liu]

George,

On Wed, May 14, 2014 at 9:34 AM, Bin Liu <binmlist@gmail.com> wrote:
> George,
>
> On Wed, May 14, 2014 at 12:37 AM, George Cherian <george.cherian@ti.com> wrote:
>> On 5/14/2014 12:07 AM, Bin Liu wrote:
>>>
>>> Hi,
>>>
>>> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com>
>>> wrote:
>>>>
>>>> Hi Daniel,
>>>>
>>>>
>>>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>>>>
>>>>> Hi George,
>>>>>
>>>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>>>>
>>>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
>>>>>> reg.
>>>>>> can you try with the following patch.
>>>>>>
>>>>>> diff --git a/drivers/usb/musb/musb_dsps.c
>>>>>> b/drivers/usb/musb/musb_dsps.c
>>>>>> index 1ae6681..1160cd1 100644
>>>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>>>           * logic enabled.
>>>>>>           */
>>>>>>          val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>>>                  glue->sw_babble_enabled = true;
>>>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>>>> +       }
>>>>>>          ret = dsps_musb_dbg_init(musb, glue);
>>>>>>          if (ret)
>>>>>
>>>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>>>>> without the patch: a full glue reset is conducted. Do I get you right
>>>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
>>>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>>>
>>>> Basically, there are 2 types of babble conditions.
>>>> 1) Transient babble condition - which could be recovered from without an
>>>> IP
>>>> reset .
>>>> 2) Babble condition - which could be recovered from only by doing an IP
>>>> reset.
>>>>
>>>> Looks like you are always hitting case 2 (Most times am also hitting the
>>>> same).
>>>> Case 1 is really hard to reproduce. I don't have a reliable method as of
>>>> now
>>>> to
>>>> reproduce this case consistently.
>>>>
>>>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>>>> (a_wait_bcon)
>>>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
>>>>> 44
>>>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>>>
>>>>>
>>>>> I don't quite follow, especially as I lack documentation of the IP core.
>>>>> How do you test babble errors, is there any way to force them to happen
>>>>> reliably?
>>>>
>>>>
>>>> There is no 100% reliable method to force it to happen. Following is
>>>
>>> I have a way to force babble happen reliably - shorting DP or DM to
>>> VBUS. I opened the far-end plug of the USB cable, so I can easily
>>> short DP or DM to VBUS.
>>
>> Good to know that you have a reliable way to test babble condition.
>> Can you please do a quick test on 3.15.0-rc4 with the series applied?
>> In case of any assistance please do let me know.
>
> Sure, but could you please re-send those patches to my corporate email
> so that I can apply them from Thunderbird?

You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.

But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.

Thanks,
-Bin.

>
> I read these linux-usb emails in Gmail, and  am not aware of any easy
> way to extract patches from Gmail.
>
> BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
> handling is similar to this patch set. With TI3.12.10, MISC is always
> 0x64, so MUSB never restarts.
>
> Thanks,
> -Bin.
>
>>
>>> But the interesting thing is that with TI 3.2 kernel, shorting DP or
>>> DM to VBUS causes MISC register to be 0x4, but the result is
>>> completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
>>>
>>> So in the 3.2 kernel, the babble handing resets the controller, but
>>> the 3.12.10 does not.
>>>
>>> Regards,
>>> -Bin.
>>>
>>>> my setup ,
>>>> I have a HUB with 4 devices connected , which gives me a Babble interrupt
>>>> on both connects and disconnects ( Not always though).
>>>>
>>>>> Anyway, the full glue layer solves this rare condition quite well for
>>>>> me. Is there any downside of this?
>>>>>
>>>>>
>>>>> Daniel
>>>>>
>>>>
>>>> --
>>>> -George
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>>
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> -George
>>

Re: [PATCH v3 0/5] Add support for SW babble Control

[George Cherian]

Hi Bin,

On 5/14/2014 10:13 PM, Bin Liu wrote:
> George,
>
> On Wed, May 14, 2014 at 9:34 AM, Bin Liu <binmlist@gmail.com> wrote:
>> George,
>>
>> On Wed, May 14, 2014 at 12:37 AM, George Cherian <george.cherian@ti.com> wrote:
>>> On 5/14/2014 12:07 AM, Bin Liu wrote:
>>>> Hi,
>>>>
>>>> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com>
>>>> wrote:
>>>>> Hi Daniel,
>>>>>
>>>>>
>>>>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>>>>> Hi George,
>>>>>>
>>>>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
>>>>>>> reg.
>>>>>>> can you try with the following patch.
>>>>>>>
>>>>>>> diff --git a/drivers/usb/musb/musb_dsps.c
>>>>>>> b/drivers/usb/musb/musb_dsps.c
>>>>>>> index 1ae6681..1160cd1 100644
>>>>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>>>>            * logic enabled.
>>>>>>>            */
>>>>>>>           val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>>>>                   glue->sw_babble_enabled = true;
>>>>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>>>>> +       }
>>>>>>>           ret = dsps_musb_dbg_init(musb, glue);
>>>>>>>           if (ret)
>>>>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>>>>>> without the patch: a full glue reset is conducted. Do I get you right
>>>>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
>>>>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>>>>
>>>>> Basically, there are 2 types of babble conditions.
>>>>> 1) Transient babble condition - which could be recovered from without an
>>>>> IP
>>>>> reset .
>>>>> 2) Babble condition - which could be recovered from only by doing an IP
>>>>> reset.
>>>>>
>>>>> Looks like you are always hitting case 2 (Most times am also hitting the
>>>>> same).
>>>>> Case 1 is really hard to reproduce. I don't have a reliable method as of
>>>>> now
>>>>> to
>>>>> reproduce this case consistently.
>>>>>
>>>>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>>>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>>>>> (a_wait_bcon)
>>>>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>>>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
>>>>>> 44
>>>>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>>>>
>>>>>>
>>>>>> I don't quite follow, especially as I lack documentation of the IP core.
>>>>>> How do you test babble errors, is there any way to force them to happen
>>>>>> reliably?
>>>>>
>>>>> There is no 100% reliable method to force it to happen. Following is
>>>> I have a way to force babble happen reliably - shorting DP or DM to
>>>> VBUS. I opened the far-end plug of the USB cable, so I can easily
>>>> short DP or DM to VBUS.
>>> Good to know that you have a reliable way to test babble condition.
>>> Can you please do a quick test on 3.15.0-rc4 with the series applied?
>>> In case of any assistance please do let me know.
>> Sure, but could you please re-send those patches to my corporate email
>> so that I can apply them from Thunderbird?
> You don't have to resend the patches. Nishanth Menon showed me a way
> to extract the patch from Gmail - Thanks Nishanth.
>
> But which repo do you want to me test with? The first patch ([PATCH v2
> 1/5] usb: musb: core: Convert babble recover work to delayed work)
> does not apply to v3.15-rc4 tag. the current musb_core.c does not have
> the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
> Thanks,
> -Bin.
>
>> I read these linux-usb emails in Gmail, and  am not aware of any easy
>> way to extract patches from Gmail.
>>
>> BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
>> handling is similar to this patch set. With TI3.12.10, MISC is always
>> 0x64, so MUSB never restarts.
>>
>> Thanks,
>> -Bin.
>>
>>>> But the interesting thing is that with TI 3.2 kernel, shorting DP or
>>>> DM to VBUS causes MISC register to be 0x4, but the result is
>>>> completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
>>>>
>>>> So in the 3.2 kernel, the babble handing resets the controller, but
>>>> the 3.12.10 does not.
>>>>
>>>> Regards,
>>>> -Bin.
>>>>
>>>>> my setup ,
>>>>> I have a HUB with 4 devices connected , which gives me a Babble interrupt
>>>>> on both connects and disconnects ( Not always though).
>>>>>
>>>>>> Anyway, the full glue layer solves this rare condition quite well for
>>>>>> me. Is there any downside of this?
>>>>>>
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>> --
>>>>> -George
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>>>>
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>> --
>>> -George
>>>


-- 
-George

Re: [PATCH v3 0/5] Add support for SW babble Control

[Bin Liu]

George,

On Thu, May 15, 2014 at 1:28 AM, George Cherian <george.cherian@ti.com> wrote:
> Hi Bin,
>
>
> On 5/14/2014 10:13 PM, Bin Liu wrote:
>>
>> George,
>>
>> On Wed, May 14, 2014 at 9:34 AM, Bin Liu <binmlist@gmail.com> wrote:
>>>
>>> George,
>>>
>>> On Wed, May 14, 2014 at 12:37 AM, George Cherian <george.cherian@ti.com>
>>> wrote:
>>>>
>>>> On 5/14/2014 12:07 AM, Bin Liu wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi Daniel,
>>>>>>
>>>>>>
>>>>>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>>>>>>
>>>>>>> Hi George,
>>>>>>>
>>>>>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>>>>>>
>>>>>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
>>>>>>>> MUSB_BABBLE_CTL
>>>>>>>> reg.
>>>>>>>> can you try with the following patch.
>>>>>>>>
>>>>>>>> diff --git a/drivers/usb/musb/musb_dsps.c
>>>>>>>> b/drivers/usb/musb/musb_dsps.c
>>>>>>>> index 1ae6681..1160cd1 100644
>>>>>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>>>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>>>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>>>>>            * logic enabled.
>>>>>>>>            */
>>>>>>>>           val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>>>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>>>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>>>>>                   glue->sw_babble_enabled = true;
>>>>>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>>>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>>>>>> +       }
>>>>>>>>           ret = dsps_musb_dbg_init(musb, glue);
>>>>>>>>           if (ret)
>>>>>>>
>>>>>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>>>>>>> without the patch: a full glue reset is conducted. Do I get you right
>>>>>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
>>>>>>> when
>>>>>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>>>>>
>>>>>> Basically, there are 2 types of babble conditions.
>>>>>> 1) Transient babble condition - which could be recovered from without
>>>>>> an
>>>>>> IP
>>>>>> reset .
>>>>>> 2) Babble condition - which could be recovered from only by doing an
>>>>>> IP
>>>>>> reset.
>>>>>>
>>>>>> Looks like you are always hitting case 2 (Most times am also hitting
>>>>>> the
>>>>>> same).
>>>>>> Case 1 is really hard to reproduce. I don't have a reliable method as
>>>>>> of
>>>>>> now
>>>>>> to
>>>>>> reproduce this case consistently.
>>>>>>
>>>>>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>>>>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>>>>>> (a_wait_bcon)
>>>>>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>>>>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
>>>>>>> value
>>>>>>> 44
>>>>>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>>>>>
>>>>>>>
>>>>>>> I don't quite follow, especially as I lack documentation of the IP
>>>>>>> core.
>>>>>>> How do you test babble errors, is there any way to force them to
>>>>>>> happen
>>>>>>> reliably?
>>>>>>
>>>>>>
>>>>>> There is no 100% reliable method to force it to happen. Following is
>>>>>
>>>>> I have a way to force babble happen reliably - shorting DP or DM to
>>>>> VBUS. I opened the far-end plug of the USB cable, so I can easily
>>>>> short DP or DM to VBUS.
>>>>
>>>> Good to know that you have a reliable way to test babble condition.
>>>> Can you please do a quick test on 3.15.0-rc4 with the series applied?
>>>> In case of any assistance please do let me know.
>>>
>>> Sure, but could you please re-send those patches to my corporate email
>>> so that I can apply them from Thunderbird?
>>
>> You don't have to resend the patches. Nishanth Menon showed me a way
>> to extract the patch from Gmail - Thanks Nishanth.
>>
>> But which repo do you want to me test with? The first patch ([PATCH v2
>> 1/5] usb: musb: core: Convert babble recover work to delayed work)
>> does not apply to v3.15-rc4 tag. the current musb_core.c does not have
>> the recovery work for musb. Please let me know what I missed.
>
> Oops I missed to mention the same.
> Please try on
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master

The test is done. The babble always causes STUCK_J is reset,
MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.

Do you think when re-start happens the driver should print a message
on console saying re-start due to babble? It would help debug the
babble problems while the dynamic debug is off.

Thanks,
-Bin.

>
>> Thanks,
>> -Bin.
>>
>>> I read these linux-usb emails in Gmail, and  am not aware of any easy
>>> way to extract patches from Gmail.
>>>
>>> BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
>>> handling is similar to this patch set. With TI3.12.10, MISC is always
>>> 0x64, so MUSB never restarts.
>>>
>>> Thanks,
>>> -Bin.
>>>
>>>>> But the interesting thing is that with TI 3.2 kernel, shorting DP or
>>>>> DM to VBUS causes MISC register to be 0x4, but the result is
>>>>> completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
>>>>>
>>>>> So in the 3.2 kernel, the babble handing resets the controller, but
>>>>> the 3.12.10 does not.
>>>>>
>>>>> Regards,
>>>>> -Bin.
>>>>>
>>>>>> my setup ,
>>>>>> I have a HUB with 4 devices connected , which gives me a Babble
>>>>>> interrupt
>>>>>> on both connects and disconnects ( Not always though).
>>>>>>
>>>>>>> Anyway, the full glue layer solves this rare condition quite well for
>>>>>>> me. Is there any downside of this?
>>>>>>>
>>>>>>>
>>>>>>> Daniel
>>>>>>>
>>>>>> --
>>>>>> -George
>>>>>>
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap"
>>>>>> in
>>>>>>
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>
>>>> --
>>>> -George
>>>>
>
>
> --
> -George
>

Re: [PATCH v3 0/5] Add support for SW babble Control

[George Cherian]

Hi Bin,

On 5/15/2014 8:49 PM, Bin Liu wrote:
> George,
>
> On Thu, May 15, 2014 at 1:28 AM, George Cherian <george.cherian@ti.com> wrote:
>> Hi Bin,
>>
>>
>> On 5/14/2014 10:13 PM, Bin Liu wrote:
>>> George,
>>>
>>> On Wed, May 14, 2014 at 9:34 AM, Bin Liu <binmlist@gmail.com> wrote:
>>>> George,
>>>>
>>>> On Wed, May 14, 2014 at 12:37 AM, George Cherian <george.cherian@ti.com>
>>>> wrote:
>>>>> On 5/14/2014 12:07 AM, Bin Liu wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tue, May 13, 2014 at 8:24 AM, George Cherian <george.cherian@ti.com>
>>>>>> wrote:
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>>
>>>>>>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>>>>>>> Hi George,
>>>>>>>>
>>>>>>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>>>>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
>>>>>>>>> MUSB_BABBLE_CTL
>>>>>>>>> reg.
>>>>>>>>> can you try with the following patch.
>>>>>>>>>
>>>>>>>>> diff --git a/drivers/usb/musb/musb_dsps.c
>>>>>>>>> b/drivers/usb/musb/musb_dsps.c
>>>>>>>>> index 1ae6681..1160cd1 100644
>>>>>>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>>>>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>>>>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>>>>>>             * logic enabled.
>>>>>>>>>             */
>>>>>>>>>            val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>>>>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>>>>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>>>>>>                    glue->sw_babble_enabled = true;
>>>>>>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>>>>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>>>>>>> +       }
>>>>>>>>>            ret = dsps_musb_dbg_init(musb, glue);
>>>>>>>>>            if (ret)
>>>>>>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
>>>>>>>> without the patch: a full glue reset is conducted. Do I get you right
>>>>>>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
>>>>>>>> when
>>>>>>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>>>>>>
>>>>>>> Basically, there are 2 types of babble conditions.
>>>>>>> 1) Transient babble condition - which could be recovered from without
>>>>>>> an
>>>>>>> IP
>>>>>>> reset .
>>>>>>> 2) Babble condition - which could be recovered from only by doing an
>>>>>>> IP
>>>>>>> reset.
>>>>>>>
>>>>>>> Looks like you are always hitting case 2 (Most times am also hitting
>>>>>>> the
>>>>>>> same).
>>>>>>> Case 1 is really hard to reproduce. I don't have a reliable method as
>>>>>>> of
>>>>>>> now
>>>>>>> to
>>>>>>> reproduce this case consistently.
>>>>>>>
>>>>>>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>>>>>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>>>>>>> (a_wait_bcon)
>>>>>>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>>>>>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
>>>>>>>> value
>>>>>>>> 44
>>>>>>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>>>>>>
>>>>>>>>
>>>>>>>> I don't quite follow, especially as I lack documentation of the IP
>>>>>>>> core.
>>>>>>>> How do you test babble errors, is there any way to force them to
>>>>>>>> happen
>>>>>>>> reliably?
>>>>>>>
>>>>>>> There is no 100% reliable method to force it to happen. Following is
>>>>>> I have a way to force babble happen reliably - shorting DP or DM to
>>>>>> VBUS. I opened the far-end plug of the USB cable, so I can easily
>>>>>> short DP or DM to VBUS.
>>>>> Good to know that you have a reliable way to test babble condition.
>>>>> Can you please do a quick test on 3.15.0-rc4 with the series applied?
>>>>> In case of any assistance please do let me know.
>>>> Sure, but could you please re-send those patches to my corporate email
>>>> so that I can apply them from Thunderbird?
>>> You don't have to resend the patches. Nishanth Menon showed me a way
>>> to extract the patch from Gmail - Thanks Nishanth.
>>>
>>> But which repo do you want to me test with? The first patch ([PATCH v2
>>> 1/5] usb: musb: core: Convert babble recover work to delayed work)
>>> does not apply to v3.15-rc4 tag. the current musb_core.c does not have
>>> the recovery work for musb. Please let me know what I missed.
>> Oops I missed to mention the same.
>> Please try on
>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
> The test is done. The babble always causes STUCK_J is reset,
> MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.
Thankyou Bin for the help.

Can I get a Tested-by from you?
> Do you think when re-start happens the driver should print a message
> on console saying re-start due to babble? It would help debug the
> babble problems while the dynamic debug is off.

It prints  out a message saying babble condition occured.
More over, it re-enumerates all the devices connected  as part of Musb 
re-start.
Don't you think that is sufficient enough ?
> Thanks,
> -Bin.
>
>>> Thanks,
>>> -Bin.
>>>
>>>> I read these linux-usb emails in Gmail, and  am not aware of any easy
>>>> way to extract patches from Gmail.
>>>>
>>>> BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
>>>> handling is similar to this patch set. With TI3.12.10, MISC is always
>>>> 0x64, so MUSB never restarts.
>>>>
>>>> Thanks,
>>>> -Bin.
>>>>
>>>>>> But the interesting thing is that with TI 3.2 kernel, shorting DP or
>>>>>> DM to VBUS causes MISC register to be 0x4, but the result is
>>>>>> completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
>>>>>>
>>>>>> So in the 3.2 kernel, the babble handing resets the controller, but
>>>>>> the 3.12.10 does not.
>>>>>>
>>>>>> Regards,
>>>>>> -Bin.
>>>>>>
>>>>>>> my setup ,
>>>>>>> I have a HUB with 4 devices connected , which gives me a Babble
>>>>>>> interrupt
>>>>>>> on both connects and disconnects ( Not always though).
>>>>>>>
>>>>>>>> Anyway, the full glue layer solves this rare condition quite well for
>>>>>>>> me. Is there any downside of this?
>>>>>>>>
>>>>>>>>
>>>>>>>> Daniel
>>>>>>>>
>>>>>>> --
>>>>>>> -George
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap"
>>>>>>> in
>>>>>>>
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>>
>>>>> --
>>>>> -George
>>>>>
>>
>> --
>> -George
>>


-- 
-George

Re: [PATCH v3 0/5] Add support for SW babble Control

[Bin Liu]

Hi George,

On Mon, May 19, 2014 at 3:40 AM, George Cherian <george.cherian@ti.com> wrote:
> Hi Bin,
>
>
> On 5/15/2014 8:49 PM, Bin Liu wrote:
>>
>> George,
>>
>> On Thu, May 15, 2014 at 1:28 AM, George Cherian <george.cherian@ti.com>
>> wrote:
>>>
>>> Hi Bin,
>>>
>>>
>>> On 5/14/2014 10:13 PM, Bin Liu wrote:
>>>>
>>>> George,
>>>>
>>>> On Wed, May 14, 2014 at 9:34 AM, Bin Liu <binmlist@gmail.com> wrote:
>>>>>
>>>>> George,
>>>>>
>>>>> On Wed, May 14, 2014 at 12:37 AM, George Cherian
>>>>> <george.cherian@ti.com>
>>>>> wrote:
>>>>>>
>>>>>> On 5/14/2014 12:07 AM, Bin Liu wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tue, May 13, 2014 at 8:24 AM, George Cherian
>>>>>>> <george.cherian@ti.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>>
>>>>>>>> On 5/13/2014 6:44 PM, Daniel Mack wrote:
>>>>>>>>>
>>>>>>>>> Hi George,
>>>>>>>>>
>>>>>>>>> On 05/13/2014 02:57 PM, George Cherian wrote:
>>>>>>>>>>
>>>>>>>>>> I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
>>>>>>>>>> MUSB_BABBLE_CTL
>>>>>>>>>> reg.
>>>>>>>>>> can you try with the following patch.
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/usb/musb/musb_dsps.c
>>>>>>>>>> b/drivers/usb/musb/musb_dsps.c
>>>>>>>>>> index 1ae6681..1160cd1 100644
>>>>>>>>>> --- a/drivers/usb/musb/musb_dsps.c
>>>>>>>>>> +++ b/drivers/usb/musb/musb_dsps.c
>>>>>>>>>> @@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
>>>>>>>>>>             * logic enabled.
>>>>>>>>>>             */
>>>>>>>>>>            val = dsps_readb(musb->mregs, MUSB_BABBLE_CTL);
>>>>>>>>>> -       if (val == MUSB_BABBLE_RCV_DISABLE)
>>>>>>>>>> +       if (val == MUSB_BABBLE_RCV_DISABLE) {
>>>>>>>>>>                    glue->sw_babble_enabled = true;
>>>>>>>>>> +               val |= MUSB_BABBLE_SW_SESSION_CTRL;
>>>>>>>>>> +               dsps_writeb(musb->mregs, MUSB_BABBLE_CTL, val);
>>>>>>>>>> +       }
>>>>>>>>>>            ret = dsps_musb_dbg_init(musb, glue);
>>>>>>>>>>            if (ret)
>>>>>>>>>
>>>>>>>>> MUSB_BABBLE_STUCK_J still remains unset, so I get the same result
>>>>>>>>> as
>>>>>>>>> without the patch: a full glue reset is conducted. Do I get you
>>>>>>>>> right
>>>>>>>>> that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
>>>>>>>>> when
>>>>>>>>> MUSB_BABBLE_SW_SESSION_CTRL is set?
>>>>>>>>>
>>>>>>>> Basically, there are 2 types of babble conditions.
>>>>>>>> 1) Transient babble condition - which could be recovered from
>>>>>>>> without
>>>>>>>> an
>>>>>>>> IP
>>>>>>>> reset .
>>>>>>>> 2) Babble condition - which could be recovered from only by doing an
>>>>>>>> IP
>>>>>>>> reset.
>>>>>>>>
>>>>>>>> Looks like you are always hitting case 2 (Most times am also hitting
>>>>>>>> the
>>>>>>>> same).
>>>>>>>> Case 1 is really hard to reproduce. I don't have a reliable method
>>>>>>>> as
>>>>>>>> of
>>>>>>>> now
>>>>>>>> to
>>>>>>>> reproduce this case consistently.
>>>>>>>>
>>>>>>>>> [   19.672373] CAUTION: musb: Babble Interrupt Occurred
>>>>>>>>> [   19.677776] musb_stage0_irq 789: unhandled DISCONNECT transition
>>>>>>>>> (a_wait_bcon)
>>>>>>>>> [   19.685815] usb 1-1: USB disconnect, device number 3
>>>>>>>>> [   19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
>>>>>>>>> value
>>>>>>>>> 44
>>>>>>>>> [   19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I don't quite follow, especially as I lack documentation of the IP
>>>>>>>>> core.
>>>>>>>>> How do you test babble errors, is there any way to force them to
>>>>>>>>> happen
>>>>>>>>> reliably?
>>>>>>>>
>>>>>>>>
>>>>>>>> There is no 100% reliable method to force it to happen. Following is
>>>>>>>
>>>>>>> I have a way to force babble happen reliably - shorting DP or DM to
>>>>>>> VBUS. I opened the far-end plug of the USB cable, so I can easily
>>>>>>> short DP or DM to VBUS.
>>>>>>
>>>>>> Good to know that you have a reliable way to test babble condition.
>>>>>> Can you please do a quick test on 3.15.0-rc4 with the series applied?
>>>>>> In case of any assistance please do let me know.
>>>>>
>>>>> Sure, but could you please re-send those patches to my corporate email
>>>>> so that I can apply them from Thunderbird?
>>>>
>>>> You don't have to resend the patches. Nishanth Menon showed me a way
>>>> to extract the patch from Gmail - Thanks Nishanth.
>>>>
>>>> But which repo do you want to me test with? The first patch ([PATCH v2
>>>> 1/5] usb: musb: core: Convert babble recover work to delayed work)
>>>> does not apply to v3.15-rc4 tag. the current musb_core.c does not have
>>>> the recovery work for musb. Please let me know what I missed.
>>>
>>> Oops I missed to mention the same.
>>> Please try on
>>> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
>>
>> The test is done. The babble always causes STUCK_J is reset,
>> MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.
>
> Thankyou Bin for the help.
>
> Can I get a Tested-by from you?

Yes, sure.

>
>> Do you think when re-start happens the driver should print a message
>> on console saying re-start due to babble? It would help debug the
>> babble problems while the dynamic debug is off.
>
>
> It prints  out a message saying babble condition occured.

That is good, but I think we also want to know the babble type - the
controller is reset or not.

> More over, it re-enumerates all the devices connected  as part of Musb
> re-start.

Sometimes the custom board has hw or sw issue, for example USB
basically does not functional, maybe after babble there is no
re-enumeration, then we cannot tell if controller reset happened or
not from the log. I think a specific message telling that will
helpful.

Regards,
-Bin.

> Don't you think that is sufficient enough ?
>
>> Thanks,
>> -Bin.
>>
>>>> Thanks,
>>>> -Bin.
>>>>
>>>>> I read these linux-usb emails in Gmail, and  am not aware of any easy
>>>>> way to extract patches from Gmail.
>>>>>
>>>>> BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
>>>>> handling is similar to this patch set. With TI3.12.10, MISC is always
>>>>> 0x64, so MUSB never restarts.
>>>>>
>>>>> Thanks,
>>>>> -Bin.
>>>>>
>>>>>>> But the interesting thing is that with TI 3.2 kernel, shorting DP or
>>>>>>> DM to VBUS causes MISC register to be 0x4, but the result is
>>>>>>> completely opposite in TI 3.12.10 kernel, which cause MISC to be
>>>>>>> 0x64.
>>>>>>>
>>>>>>> So in the 3.2 kernel, the babble handing resets the controller, but
>>>>>>> the 3.12.10 does not.
>>>>>>>
>>>>>>> Regards,
>>>>>>> -Bin.
>>>>>>>
>>>>>>>> my setup ,
>>>>>>>> I have a HUB with 4 devices connected , which gives me a Babble
>>>>>>>> interrupt
>>>>>>>> on both connects and disconnects ( Not always though).
>>>>>>>>
>>>>>>>>> Anyway, the full glue layer solves this rare condition quite well
>>>>>>>>> for
>>>>>>>>> me. Is there any downside of this?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>> --
>>>>>>>> -George
>>>>>>>>
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>> linux-omap"
>>>>>>>> in
>>>>>>>>
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -George
>>>>>>
>>>
>>> --
>>> -George
>>>
>
>
> --
> -George
>