[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Hans de Goede]

Hi Ian, Paul,

Here is a patch to fix the problems where most usb devices will no longer
work after a "usb reset ", when connected to the otg controller in host
mode + a related cleanup patch.

Ian I would like to send out a PR with these 2 as fixed for v2015.07, can
you review them please? Note I've not tested this with the otg in gadget
mode, but we do not have gadget mode enabled by default anywhere atm, so
I still consider this suitable as a bugfix for v2015.07.

Paul, can you test these with gadget mode? Specifically if they help the
problem you were seeing when switching roles?

Also this bit from the kernel code for the sunxi glue may be relevant
to your problems:

        if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
                /* ep0 FADDR must be 0 when (re)entering peripheral mode */
                musb_ep_select(musb->mregs, 0);
                musb_writeb(musb->mregs, MUSB_FADDR, 0);
        }

This is from the interrupt handler in the sunxi-musb glue in the kernel,
maybe we can do the same, and/or maybe we need to do:

	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
	musb_ep_select(musb->mregs, 0);
	musb_writeb(musb->mregs, MUSB_FADDR, 0);

From sunxi_musb_disable?

From my experience sofar we should avoid doing a full reset from musb_stop /
sunxi_musb_disable as musb_init_controller never gets re-run, so doing a
full reset leaves things in a bad state where only ep0 still seems to work,
this may be what you were seeing before.

Regards,

Hans

[U-Boot] [PATCH 1/2] sunxi: musb: Do not fully reset the controler from sunxi_musb_disable

[Hans de Goede]

Fully resetting the controller is a too big hammer, and the musb_core will
then afterwards fail to communicate with any endpoints other then 0 as
too much state was cleared.

Instead report vbus low for 200ms which will effectively end the current
session without needing to do a full reset.

This fixes usb mass-storage devices no longer working after a "usb reset"

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/usb/musb-new/sunxi.c | 52 ++++++++++++++++++++++++++------------------
 1 file changed, 31 insertions(+), 21 deletions(-)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index e8a3a23..42c6725 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -157,6 +157,17 @@ static void USBC_ForceIdToHigh(__iomem void *base)
 	musb_writel(base, USBC_REG_o_ISCR, reg_val);
 }
 
+static void USBC_ForceVbusValidToLow(__iomem void *base)
+{
+	u32 reg_val;
+
+	reg_val = musb_readl(base, USBC_REG_o_ISCR);
+	reg_val &= ~(0x03 << USBC_BP_ISCR_FORCE_VBUS_VALID);
+	reg_val |= (0x02 << USBC_BP_ISCR_FORCE_VBUS_VALID);
+	reg_val = USBC_WakeUp_ClearChangeDetect(reg_val);
+	musb_writel(base, USBC_REG_o_ISCR, reg_val);
+}
+
 static void USBC_ForceVbusValidToHigh(__iomem void *base)
 {
 	u32 reg_val;
@@ -205,42 +216,41 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void *__hci)
 	return retval;
 }
 
+/* musb_core does not call enable / disable in a balanced manner <sigh> */
+static bool enabled = false;
+
 static void sunxi_musb_enable(struct musb *musb)
 {
 	pr_debug("%s():\n", __func__);
 
+	if (enabled)
+		return;
+
 	/* select PIO mode */
 	musb_writeb(musb->mregs, USBC_REG_o_VEND0, 0);
 
-	if (is_host_enabled(musb)) {
-		/* port power on */
-		sunxi_usb_phy_power_on(0);
-	}
+	if (is_host_enabled(musb))
+		sunxi_usb_phy_power_on(0); /* port power on */
+
+	USBC_ForceVbusValidToHigh(musb->mregs);
+
+	enabled = true;
 }
 
 static void sunxi_musb_disable(struct musb *musb)
 {
-	struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-
 	pr_debug("%s():\n", __func__);
 
-	/* Put the controller back in a pristane state for "usb reset" */
-	if (musb->is_active) {
-		sunxi_usb_phy_exit(0);
-#ifdef CONFIG_SUNXI_GEN_SUN6I
-		clrbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_GATE_OFFSET_USB0);
-#endif
-		clrbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_USB0);
+	if (!enabled)
+		return;
 
-		mdelay(10);
+	if (is_host_enabled(musb))
+		sunxi_usb_phy_power_off(0); /* port power off */
 
-		setbits_le32(&ccm->ahb_gate0, 1 << AHB_GATE_OFFSET_USB0);
-#ifdef CONFIG_SUNXI_GEN_SUN6I
-		setbits_le32(&ccm->ahb_reset0_cfg, 1 << AHB_GATE_OFFSET_USB0);
-#endif
-		sunxi_usb_phy_init(0);
-		musb->is_active = 0;
-	}
+	USBC_ForceVbusValidToLow(musb->mregs);
+	mdelay(200); /* Wait for the current session to timeout */
+
+	enabled = false;
 }
 
 static int sunxi_musb_init(struct musb *musb)
-- 
2.4.3

[U-Boot] [PATCH 1/2] sunxi: musb: Do not fully reset the controler from sunxi_musb_disable

[Ian Campbell]

On Sun, 2015-06-14 at 12:40 +0200, Hans de Goede wrote:
> Fully resetting the controller is a too big hammer, and the musb_core will
> then afterwards fail to communicate with any endpoints other then 0 as
> too much state was cleared.
> 
> Instead report vbus low for 200ms which will effectively end the current
> session without needing to do a full reset.
> 
> This fixes usb mass-storage devices no longer working after a "usb reset"
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>

One question (which turned into two) (both more for the musb maint than
you):

> +/* musb_core does not call enable / disable in a balanced manner <sigh> */
> +static bool enabled = false;

Is this sufficient, or should we be reference counting? Or should the
core be fixed?

Ian.

[U-Boot] [PATCH 1/2] sunxi: musb: Do not fully reset the controler from sunxi_musb_disable

[Hans de Goede]

Hi,

On 06/14/2015 01:46 PM, Ian Campbell wrote:
> On Sun, 2015-06-14 at 12:40 +0200, Hans de Goede wrote:
>> Fully resetting the controller is a too big hammer, and the musb_core will
>> then afterwards fail to communicate with any endpoints other then 0 as
>> too much state was cleared.
>>
>> Instead report vbus low for 200ms which will effectively end the current
>> session without needing to do a full reset.
>>
>> This fixes usb mass-storage devices no longer working after a "usb reset"
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Ian Campbell <ijc@hellion.org.uk>
>
> One question (which turned into two) (both more for the musb maint than
> you):
>
>> +/* musb_core does not call enable / disable in a balanced manner <sigh> */
>> +static bool enabled = false;
>
> Is this sufficient, or should we be reference counting? Or should the
> core be fixed?

The u-boot musb-new code is a copy of the kernel code, and both are of,
ah, interesting quality. One problem is that the core calls
musb_platform_disable as part of musb_init_controller and thus before
musb_platform_enable is ever called.

Ideally the core would not do this, but in u-boot it is used on 4
different SoCs and in the kernel even more, and chances are that that
call was added to put the hw in a clean state on some SoC...

Basically my approach for these kind of problems in the musb core so
far has been to work around them were possible, so as to not cause
any regressions on other SoCs.

Regards,

Hans

[U-Boot] [PATCH 2/2] sunxi: musb: Remove unused sunxi_musb_exit method

[Hans de Goede]

Remove the unused sunxi_musb_exit method, there is no code in u-boot
calling the exit method, and our implementation was broken as it did
not disable the clocks and asserted reset.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/usb/musb-new/sunxi.c | 34 ----------------------------------
 1 file changed, 34 deletions(-)

diff --git a/drivers/usb/musb-new/sunxi.c b/drivers/usb/musb-new/sunxi.c
index 42c6725..052e065 100644
--- a/drivers/usb/musb-new/sunxi.c
+++ b/drivers/usb/musb-new/sunxi.c
@@ -105,16 +105,6 @@ static void USBC_EnableIdPullUp(__iomem void *base)
 	musb_writel(base, USBC_REG_o_ISCR, reg_val);
 }
 
-static void USBC_DisableIdPullUp(__iomem void *base)
-{
-	u32 reg_val;
-
-	reg_val = musb_readl(base, USBC_REG_o_ISCR);
-	reg_val &= ~(1 << USBC_BP_ISCR_ID_PULLUP_EN);
-	reg_val = USBC_WakeUp_ClearChangeDetect(reg_val);
-	musb_writel(base, USBC_REG_o_ISCR, reg_val);
-}
-
 static void USBC_EnableDpDmPullUp(__iomem void *base)
 {
 	u32 reg_val;
@@ -125,16 +115,6 @@ static void USBC_EnableDpDmPullUp(__iomem void *base)
 	musb_writel(base, USBC_REG_o_ISCR, reg_val);
 }
 
-static void USBC_DisableDpDmPullUp(__iomem void *base)
-{
-	u32 reg_val;
-
-	reg_val = musb_readl(base, USBC_REG_o_ISCR);
-	reg_val &= ~(1 << USBC_BP_ISCR_DPDM_PULLUP_EN);
-	reg_val = USBC_WakeUp_ClearChangeDetect(reg_val);
-	musb_writel(base, USBC_REG_o_ISCR, reg_val);
-}
-
 static void USBC_ForceIdToLow(__iomem void *base)
 {
 	u32 reg_val;
@@ -292,22 +272,8 @@ static int sunxi_musb_init(struct musb *musb)
 	return 0;
 }
 
-static int sunxi_musb_exit(struct musb *musb)
-{
-	pr_debug("%s():\n", __func__);
-
-	USBC_DisableDpDmPullUp(musb->mregs);
-	USBC_DisableIdPullUp(musb->mregs);
-	sunxi_usb_phy_power_off(0);
-	sunxi_usb_phy_exit(0);
-
-	return 0;
-}
-
 const struct musb_platform_ops sunxi_musb_ops = {
 	.init		= sunxi_musb_init,
-	.exit		= sunxi_musb_exit,
-
 	.enable		= sunxi_musb_enable,
 	.disable	= sunxi_musb_disable,
 };
-- 
2.4.3

[U-Boot] [PATCH 2/2] sunxi: musb: Remove unused sunxi_musb_exit method

[Ian Campbell]

On Sun, 2015-06-14 at 12:40 +0200, Hans de Goede wrote:
> Remove the unused sunxi_musb_exit method, there is no code in u-boot
> calling the exit method, and our implementation was broken as it did
> not disable the clocks and asserted reset.

Seems to me the call should either be called (and the hooks fixed) or
removed from the core but so far as sunxi goes:

> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Paul Kocialkowski]

Le dimanche 14 juin 2015 ? 12:40 +0200, Hans de Goede a ?crit :
> Hi Ian, Paul,
> 
> Here is a patch to fix the problems where most usb devices will no longer
> work after a "usb reset ", when connected to the otg controller in host
> mode + a related cleanup patch.

This works fine for an USB storage device and an USB2 keyboard but does
not work with an USB1 keyboard, with error:

sunxi# usb reset
resetting USB...
USB0:   scanning bus 0 for devices... USB device descriptor short read
(expected 8, got 0)
No USB Device found

> Paul, can you test these with gadget mode? Specifically if they help the
> problem you were seeing when switching roles?

It doesn't fix the problem as-is, I still get enumerating problems from
the host. Also, note that musb_stop is not called from the gadget code,
so sunxi_musb_disable (musb_platform_disable) is not called either. I
had to add a dirty call in usb_gadget_unregister_driver to test the
code.

> Also this bit from the kernel code for the sunxi glue may be relevant
> to your problems:
> 
>         if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>                 /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>                 musb_ep_select(musb->mregs, 0);
>                 musb_writeb(musb->mregs, MUSB_FADDR, 0);
>         }
> 
> This is from the interrupt handler in the sunxi-musb glue in the kernel,
> maybe we can do the same, and/or maybe we need to do:
> 
> 	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
> 	musb_ep_select(musb->mregs, 0);
> 	musb_writeb(musb->mregs, MUSB_FADDR, 0);
> 
> From sunxi_musb_disable?

Thanks for those pointers, I'll try to look into that when I have time
to properly debug the issue.

> From my experience sofar we should avoid doing a full reset from musb_stop /
> sunxi_musb_disable as musb_init_controller never gets re-run, so doing a
> full reset leaves things in a bad state where only ep0 still seems to work,
> this may be what you were seeing before.

That makes sense, but what is done currently doesn't seem to be enough
to bring everything back up. Hopefully, setting the EP0 FADDR will help.

Thanks a lot for your work, as usual!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150615/20439ba4/attachment.sig>

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Hans de Goede]

Hi,

On 15-06-15 21:21, Paul Kocialkowski wrote:
> Le dimanche 14 juin 2015 ? 12:40 +0200, Hans de Goede a ?crit :
>> Hi Ian, Paul,
>>
>> Here is a patch to fix the problems where most usb devices will no longer
>> work after a "usb reset ", when connected to the otg controller in host
>> mode + a related cleanup patch.
>
> This works fine for an USB storage device and an USB2 keyboard but does
> not work with an USB1 keyboard, with error:
>
> sunxi# usb reset
> resetting USB...
> USB0:   scanning bus 0 for devices... USB device descriptor short read
> (expected 8, got 0)
> No USB Device found

Hmm, did you test my sunxi-wip branch perhaps? This bug does exist there,
but it is the result of me refactoring things so that the musb code can
use the device-model when build in host mode, which will allow enabling
both the otg port in host mode and regular usb hosts in a single build,
which is esp. useful for boards which have the otg hooked up in host-only
mode (e.g. connected to an usb-a receptacle, or usb <-> sata bridge).

I've just retested current u-boot/master with just this patch and the
problem you are describing does not happen then.

Sorry about my sunxi-wip being broken atm I try to always keep it 100%
functional, but well it is a wip tree after all.

Regards,

Hans

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Paul Kocialkowski]

Le mercredi 17 juin 2015 ? 15:39 +0200, Hans de Goede a ?crit :
> Hi,
> 
> On 15-06-15 21:21, Paul Kocialkowski wrote:
> > Le dimanche 14 juin 2015 ? 12:40 +0200, Hans de Goede a ?crit :
> >> Hi Ian, Paul,
> >>
> >> Here is a patch to fix the problems where most usb devices will no longer
> >> work after a "usb reset ", when connected to the otg controller in host
> >> mode + a related cleanup patch.
> >
> > This works fine for an USB storage device and an USB2 keyboard but does
> > not work with an USB1 keyboard, with error:
> >
> > sunxi# usb reset
> > resetting USB...
> > USB0:   scanning bus 0 for devices... USB device descriptor short read
> > (expected 8, got 0)
> > No USB Device found
> 
> Hmm, did you test my sunxi-wip branch perhaps? This bug does exist there,
> but it is the result of me refactoring things so that the musb code can
> use the device-model when build in host mode, which will allow enabling
> both the otg port in host mode and regular usb hosts in a single build,
> which is esp. useful for boards which have the otg hooked up in host-only
> mode (e.g. connected to an usb-a receptacle, or usb <-> sata bridge).

This is nice, thanks a lot for all your work!

I did however test on top of the regular U-Boot tree. I'll try again in
a few days to see if it still happens.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150619/27357958/attachment.sig>

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Marek Vasut]

On Sunday, June 14, 2015 at 12:40:11 PM, Hans de Goede wrote:
> Hi Ian, Paul,
> 
> Here is a patch to fix the problems where most usb devices will no longer
> work after a "usb reset ", when connected to the otg controller in host
> mode + a related cleanup patch.
> 
> Ian I would like to send out a PR with these 2 as fixed for v2015.07, can
> you review them please? Note I've not tested this with the otg in gadget
> mode, but we do not have gadget mode enabled by default anywhere atm, so
> I still consider this suitable as a bugfix for v2015.07.
> 
> Paul, can you test these with gadget mode? Specifically if they help the
> problem you were seeing when switching roles?
> 
> Also this bit from the kernel code for the sunxi glue may be relevant
> to your problems:
> 
>         if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>                 /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>                 musb_ep_select(musb->mregs, 0);
>                 musb_writeb(musb->mregs, MUSB_FADDR, 0);
>         }
> 
> This is from the interrupt handler in the sunxi-musb glue in the kernel,
> maybe we can do the same, and/or maybe we need to do:
> 
> 	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
> 	musb_ep_select(musb->mregs, 0);
> 	musb_writeb(musb->mregs, MUSB_FADDR, 0);
> 
> From sunxi_musb_disable?
> 
> From my experience sofar we should avoid doing a full reset from musb_stop
> / sunxi_musb_disable as musb_init_controller never gets re-run, so doing a
> full reset leaves things in a bad state where only ep0 still seems to
> work, this may be what you were seeing before.

Hi,

do you want me to pick this via u-boot-usb/master ?

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Hans de Goede]

Hi,

On 19-06-15 14:35, Marek Vasut wrote:
> On Sunday, June 14, 2015 at 12:40:11 PM, Hans de Goede wrote:
>> Hi Ian, Paul,
>>
>> Here is a patch to fix the problems where most usb devices will no longer
>> work after a "usb reset ", when connected to the otg controller in host
>> mode + a related cleanup patch.
>>
>> Ian I would like to send out a PR with these 2 as fixed for v2015.07, can
>> you review them please? Note I've not tested this with the otg in gadget
>> mode, but we do not have gadget mode enabled by default anywhere atm, so
>> I still consider this suitable as a bugfix for v2015.07.
>>
>> Paul, can you test these with gadget mode? Specifically if they help the
>> problem you were seeing when switching roles?
>>
>> Also this bit from the kernel code for the sunxi glue may be relevant
>> to your problems:
>>
>>          if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>>                  /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>>                  musb_ep_select(musb->mregs, 0);
>>                  musb_writeb(musb->mregs, MUSB_FADDR, 0);
>>          }
>>
>> This is from the interrupt handler in the sunxi-musb glue in the kernel,
>> maybe we can do the same, and/or maybe we need to do:
>>
>> 	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
>> 	musb_ep_select(musb->mregs, 0);
>> 	musb_writeb(musb->mregs, MUSB_FADDR, 0);
>>
>>  From sunxi_musb_disable?
>>
>>  From my experience sofar we should avoid doing a full reset from musb_stop
>> / sunxi_musb_disable as musb_init_controller never gets re-run, so doing a
>> full reset leaves things in a bad state where only ep0 still seems to
>> work, this may be what you were seeing before.
>
> Hi,
>
> do you want me to pick this via u-boot-usb/master ?

No, I've already send a pull-req for them via u-boot-sunxi/master and they
are already merged :)

Regards,

Hans

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Marek Vasut]

On Friday, June 19, 2015 at 03:07:04 PM, Hans de Goede wrote:
> Hi,
> 
> On 19-06-15 14:35, Marek Vasut wrote:
> > On Sunday, June 14, 2015 at 12:40:11 PM, Hans de Goede wrote:
> >> Hi Ian, Paul,
> >> 
> >> Here is a patch to fix the problems where most usb devices will no
> >> longer work after a "usb reset ", when connected to the otg controller
> >> in host mode + a related cleanup patch.
> >> 
> >> Ian I would like to send out a PR with these 2 as fixed for v2015.07,
> >> can you review them please? Note I've not tested this with the otg in
> >> gadget mode, but we do not have gadget mode enabled by default anywhere
> >> atm, so I still consider this suitable as a bugfix for v2015.07.
> >> 
> >> Paul, can you test these with gadget mode? Specifically if they help the
> >> problem you were seeing when switching roles?
> >> 
> >> Also this bit from the kernel code for the sunxi glue may be relevant
> >> 
> >> to your problems:
> >>          if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb))
> >>          {
> >>          
> >>                  /* ep0 FADDR must be 0 when (re)entering peripheral
> >>                  mode */ musb_ep_select(musb->mregs, 0);
> >>                  musb_writeb(musb->mregs, MUSB_FADDR, 0);
> >>          
> >>          }
> >> 
> >> This is from the interrupt handler in the sunxi-musb glue in the kernel,
> >> 
> >> maybe we can do the same, and/or maybe we need to do:
> >> 	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
> >> 	musb_ep_select(musb->mregs, 0);
> >> 	musb_writeb(musb->mregs, MUSB_FADDR, 0);
> >> 	
> >>  From sunxi_musb_disable?
> >>  
> >>  From my experience sofar we should avoid doing a full reset from
> >>  musb_stop
> >> 
> >> / sunxi_musb_disable as musb_init_controller never gets re-run, so doing
> >> a full reset leaves things in a bad state where only ep0 still seems to
> >> work, this may be what you were seeing before.
> > 
> > Hi,
> > 
> > do you want me to pick this via u-boot-usb/master ?
> 
> No, I've already send a pull-req for them via u-boot-sunxi/master and they
> are already merged :)

OK, roger.

Best regards,
Marek Vasut

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Maxime Ripard]

Hi,

On Sun, Jun 14, 2015 at 12:40:11PM +0200, Hans de Goede wrote:
> Paul, can you test these with gadget mode? Specifically if they help the
> problem you were seeing when switching roles?
> 
> Also this bit from the kernel code for the sunxi glue may be relevant
> to your problems:
> 
>         if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>                 /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>                 musb_ep_select(musb->mregs, 0);
>                 musb_writeb(musb->mregs, MUSB_FADDR, 0);
>         }
> 
> This is from the interrupt handler in the sunxi-musb glue in the kernel,
> maybe we can do the same, and/or maybe we need to do:
> 
> 	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
> 	musb_ep_select(musb->mregs, 0);
> 	musb_writeb(musb->mregs, MUSB_FADDR, 0);
> 
> From sunxi_musb_disable?

So, I was affected by this issue on a SinA33, even when not switching
roles (since the SinA33 is peripheral only). The issue I was seeing
what that when I was two subsequent use of any gadget (fastboot, USB
ethernet traffic), the second would silently fail on U-boot side with
the host failing to enumerate the device.

Paul pointed me to that thread, and your suggestion on EP0 seems like
a good lead, since the ugly http://pastebin.com/9Y6S9Hpw makes it work.

Thanks,
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150626/ab5df87f/attachment.sig>

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Hans de Goede]

Hi,

On 26-06-15 12:20, Maxime Ripard wrote:
> Hi,
>
> On Sun, Jun 14, 2015 at 12:40:11PM +0200, Hans de Goede wrote:
>> Paul, can you test these with gadget mode? Specifically if they help the
>> problem you were seeing when switching roles?
>>
>> Also this bit from the kernel code for the sunxi glue may be relevant
>> to your problems:
>>
>>          if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>>                  /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>>                  musb_ep_select(musb->mregs, 0);
>>                  musb_writeb(musb->mregs, MUSB_FADDR, 0);
>>          }
>>
>> This is from the interrupt handler in the sunxi-musb glue in the kernel,
>> maybe we can do the same, and/or maybe we need to do:
>>
>> 	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
>> 	musb_ep_select(musb->mregs, 0);
>> 	musb_writeb(musb->mregs, MUSB_FADDR, 0);
>>
>>  From sunxi_musb_disable?
>
> So, I was affected by this issue on a SinA33, even when not switching
> roles (since the SinA33 is peripheral only). The issue I was seeing
> what that when I was two subsequent use of any gadget (fastboot, USB
> ethernet traffic), the second would silently fail on U-boot side with
> the host failing to enumerate the device.
>
> Paul pointed me to that thread, and your suggestion on EP0 seems like
> a good lead, since the ugly http://pastebin.com/9Y6S9Hpw makes it work.

Ah, that is not that ugly actually, I can take that as is if you want me
too just submit it to the u-boot list with me in the Cc and I'll pick it
up and put it in u-boot-sunxi/next

Regards,

Hans

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Maxime Ripard]

On Fri, Jun 26, 2015 at 01:01:12PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 26-06-15 12:20, Maxime Ripard wrote:
> >Hi,
> >
> >On Sun, Jun 14, 2015 at 12:40:11PM +0200, Hans de Goede wrote:
> >>Paul, can you test these with gadget mode? Specifically if they help the
> >>problem you were seeing when switching roles?
> >>
> >>Also this bit from the kernel code for the sunxi glue may be relevant
> >>to your problems:
> >>
> >>         if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
> >>                 /* ep0 FADDR must be 0 when (re)entering peripheral mode */
> >>                 musb_ep_select(musb->mregs, 0);
> >>                 musb_writeb(musb->mregs, MUSB_FADDR, 0);
> >>         }
> >>
> >>This is from the interrupt handler in the sunxi-musb glue in the kernel,
> >>maybe we can do the same, and/or maybe we need to do:
> >>
> >>	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
> >>	musb_ep_select(musb->mregs, 0);
> >>	musb_writeb(musb->mregs, MUSB_FADDR, 0);
> >>
> >> From sunxi_musb_disable?
> >
> >So, I was affected by this issue on a SinA33, even when not switching
> >roles (since the SinA33 is peripheral only). The issue I was seeing
> >what that when I was two subsequent use of any gadget (fastboot, USB
> >ethernet traffic), the second would silently fail on U-boot side with
> >the host failing to enumerate the device.
> >
> >Paul pointed me to that thread, and your suggestion on EP0 seems like
> >a good lead, since the ugly http://pastebin.com/9Y6S9Hpw makes it work.
> 
> Ah, that is not that ugly actually, I can take that as is if you want me
> too just submit it to the u-boot list with me in the Cc and I'll pick it
> up and put it in u-boot-sunxi/next

I don't know, it felt quick and dirty while doing it :)

I haven't tested it with host though, so you'll probably want to give
that a test run, I'll submit it some time this week.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150628/78cc1cca/attachment.sig>

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Hans de Goede]

Hi,

On 26-06-15 12:20, Maxime Ripard wrote:
> Hi,
>
> On Sun, Jun 14, 2015 at 12:40:11PM +0200, Hans de Goede wrote:
>> Paul, can you test these with gadget mode? Specifically if they help the
>> problem you were seeing when switching roles?
>>
>> Also this bit from the kernel code for the sunxi glue may be relevant
>> to your problems:
>>
>>          if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>>                  /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>>                  musb_ep_select(musb->mregs, 0);
>>                  musb_writeb(musb->mregs, MUSB_FADDR, 0);
>>          }
>>
>> This is from the interrupt handler in the sunxi-musb glue in the kernel,
>> maybe we can do the same, and/or maybe we need to do:
>>
>> 	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
>> 	musb_ep_select(musb->mregs, 0);
>> 	musb_writeb(musb->mregs, MUSB_FADDR, 0);
>>
>>  From sunxi_musb_disable?
>
> So, I was affected by this issue on a SinA33, even when not switching
> roles (since the SinA33 is peripheral only).

Missed this the first reply, are you sure, that is somewhat weird. I mean
it is possible if they did not hook up the id pin, or do not allow you
to send out +5v, but it is weird. I guess they did route the real usb-host
to an USB-A receptacle on that board, so it is not a big deal, right ?

Regards,

Hans

[U-Boot] [PATCH 0/2] sunxi: musb: Fix "usb reset" handling

[Maxime Ripard]

On Fri, Jun 26, 2015 at 01:02:51PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 26-06-15 12:20, Maxime Ripard wrote:
> >Hi,
> >
> >On Sun, Jun 14, 2015 at 12:40:11PM +0200, Hans de Goede wrote:
> >>Paul, can you test these with gadget mode? Specifically if they help the
> >>problem you were seeing when switching roles?
> >>
> >>Also this bit from the kernel code for the sunxi glue may be relevant
> >>to your problems:
> >>
> >>         if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
> >>                 /* ep0 FADDR must be 0 when (re)entering peripheral mode */
> >>                 musb_ep_select(musb->mregs, 0);
> >>                 musb_writeb(musb->mregs, MUSB_FADDR, 0);
> >>         }
> >>
> >>This is from the interrupt handler in the sunxi-musb glue in the kernel,
> >>maybe we can do the same, and/or maybe we need to do:
> >>
> >>	/* ep0 FADDR must be 0 when (re)entering peripheral mode */
> >>	musb_ep_select(musb->mregs, 0);
> >>	musb_writeb(musb->mregs, MUSB_FADDR, 0);
> >>
> >> From sunxi_musb_disable?
> >
> >So, I was affected by this issue on a SinA33, even when not switching
> >roles (since the SinA33 is peripheral only).
> 
> Missed this the first reply, are you sure, that is somewhat weird. I mean
> it is possible if they did not hook up the id pin, or do not allow you
> to send out +5v, but it is weird. I guess they did route the real usb-host
> to an USB-A receptacle on that board, so it is not a big deal, right ?

Yeah, I'm sure, or at least that's what the schematics say. VBUS comes
straight from the DC-5V (without any GPIO in between), goes through a
jumper (you read me right....), which is even un-populated on the
boards Chen-Yu and I got.

So it seems like while the board has the ID pin routed, it's actually
not able to provide VBUS (which is kind of weird, but anyway).

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150626/9e9b9abd/attachment.sig>