[Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Bryan Wu]

Hi folks,

Here is our bug tracker,
https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3788

ZiO! CF card reader is here:
http://www.psism.com/zio.htm

- Firstly, MUSB is working as in host mode which can be figured out by
the debug message.
- Enumeration of the ZiO! CF card reader is OK.
- When the upper drivers/usb/storage/shuttle_usbat.c try to send out
the first packet:
--
        /* Enable peripheral control signals */
        rc = usbat_write_user_io(us,
                                 USBAT_UIO_OE1 | USBAT_UIO_OE0,
                                 USBAT_UIO_EPAD | USBAT_UIO_1);
        if (rc != USB_STOR_XFER_GOOD)
                return USB_STOR_TRANSPORT_ERROR;
--

- Finally, we got VBUS_ERROR interrupt in peripheral mode. I don't
know how to recover it.
If I am not wrong, the ZiO! CF card reader must have dropped the VBUS
and this triggered the mode change of MUSB.

Are you guys have any idea about this?

B.T.W, I found the packet sequence of
drivers/usb/storage/shuttle_usbat.c is not the same as Windows Host
does.
So I modified the code to send out the same packet as Windows Host.
The result is the same.

Thanks a lot
-Bryan Wu

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Felipe Balbi]

On Mon, 7 Apr 2008 03:15:38 -0700, "Bryan Wu" <cooloney@kernel.org> wrote:
> Hi folks,
> 
> Here is our bug tracker,
>
https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3788
> 
> ZiO! CF card reader is here:
> http://www.psism.com/zio.htm
> 
> - Firstly, MUSB is working as in host mode which can be figured out by
> the debug message.
> - Enumeration of the ZiO! CF card reader is OK.
> - When the upper drivers/usb/storage/shuttle_usbat.c try to send out
> the first packet:
> --
>         /* Enable peripheral control signals */
>         rc = usbat_write_user_io(us,
>                                  USBAT_UIO_OE1 | USBAT_UIO_OE0,
>                                  USBAT_UIO_EPAD | USBAT_UIO_1);
>         if (rc != USB_STOR_XFER_GOOD)
>                 return USB_STOR_TRANSPORT_ERROR;
> --
> 
> - Finally, we got VBUS_ERROR interrupt in peripheral mode. I don't
> know how to recover it.
> If I am not wrong, the ZiO! CF card reader must have dropped the VBUS
> and this triggered the mode change of MUSB.
> 
> Are you guys have any idea about this?
> 
> B.T.W, I found the packet sequence of
> drivers/usb/storage/shuttle_usbat.c is not the same as Windows Host
> does.
> So I modified the code to send out the same packet as Windows Host.
> The result is the same.

It's probably drawing more the 100mA, try using a self-powered usb hub
attached
to musb and zio to hub.

> 
> Thanks a lot
> -Bryan Wu
> --
> 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
-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Bryan Wu]

On Mon, Apr 7, 2008 at 3:19 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>
>
>
>  On Mon, 7 Apr 2008 03:15:38 -0700, "Bryan Wu" <cooloney@kernel.org> wrote:
>  > Hi folks,
>  >
>  > Here is our bug tracker,
>  >
>  https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3788
>  >
>  > ZiO! CF card reader is here:
>  > http://www.psism.com/zio.htm
>  >
>  > - Firstly, MUSB is working as in host mode which can be figured out by
>  > the debug message.
>  > - Enumeration of the ZiO! CF card reader is OK.
>  > - When the upper drivers/usb/storage/shuttle_usbat.c try to send out
>  > the first packet:
>  > --
>  >         /* Enable peripheral control signals */
>  >         rc = usbat_write_user_io(us,
>  >                                  USBAT_UIO_OE1 | USBAT_UIO_OE0,
>  >                                  USBAT_UIO_EPAD | USBAT_UIO_1);
>  >         if (rc != USB_STOR_XFER_GOOD)
>  >                 return USB_STOR_TRANSPORT_ERROR;
>  > --
>  >
>  > - Finally, we got VBUS_ERROR interrupt in peripheral mode. I don't
>  > know how to recover it.
>  > If I am not wrong, the ZiO! CF card reader must have dropped the VBUS
>  > and this triggered the mode change of MUSB.
>  >
>  > Are you guys have any idea about this?
>  >
>  > B.T.W, I found the packet sequence of
>  > drivers/usb/storage/shuttle_usbat.c is not the same as Windows Host
>  > does.
>  > So I modified the code to send out the same packet as Windows Host.
>  > The result is the same.
>
>  It's probably drawing more the 100mA, try using a self-powered usb hub
>  attached
>  to musb and zio to hub.
>

So that means it's possible related with the hardware design?
Unfortunately, there is no self-powered usb hub on my side.
Only have normal full-speed usb hub which is powered by usb host. So
maybe we should add this kind of usb devices to the black list of MUSB
driver.

Thanks
-Bryan

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Felipe Balbi]

On Mon, 7 Apr 2008 03:35:38 -0700, "Bryan Wu" <cooloney@kernel.org> wrote:
> On Mon, Apr 7, 2008 at 3:19 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>>
>>
>>
>>  On Mon, 7 Apr 2008 03:15:38 -0700, "Bryan Wu" <cooloney@kernel.org>
> wrote:
>>  > Hi folks,
>>  >
>>  > Here is our bug tracker,
>>  >
>> 
>
https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3788
>>  >
>>  > ZiO! CF card reader is here:
>>  > http://www.psism.com/zio.htm
>>  >
>>  > - Firstly, MUSB is working as in host mode which can be figured out
> by
>>  > the debug message.
>>  > - Enumeration of the ZiO! CF card reader is OK.
>>  > - When the upper drivers/usb/storage/shuttle_usbat.c try to send out
>>  > the first packet:
>>  > --
>>  >         /* Enable peripheral control signals */
>>  >         rc = usbat_write_user_io(us,
>>  >                                  USBAT_UIO_OE1 | USBAT_UIO_OE0,
>>  >                                  USBAT_UIO_EPAD | USBAT_UIO_1);
>>  >         if (rc != USB_STOR_XFER_GOOD)
>>  >                 return USB_STOR_TRANSPORT_ERROR;
>>  > --
>>  >
>>  > - Finally, we got VBUS_ERROR interrupt in peripheral mode. I don't
>>  > know how to recover it.
>>  > If I am not wrong, the ZiO! CF card reader must have dropped the VBUS
>>  > and this triggered the mode change of MUSB.
>>  >
>>  > Are you guys have any idea about this?
>>  >
>>  > B.T.W, I found the packet sequence of
>>  > drivers/usb/storage/shuttle_usbat.c is not the same as Windows Host
>>  > does.
>>  > So I modified the code to send out the same packet as Windows Host.
>>  > The result is the same.
>>
>>  It's probably drawing more the 100mA, try using a self-powered usb hub
>>  attached
>>  to musb and zio to hub.
>>
> 
> So that means it's possible related with the hardware design?
> Unfortunately, there is no self-powered usb hub on my side.
> Only have normal full-speed usb hub which is powered by usb host. So
> maybe we should add this kind of usb devices to the black list of MUSB
> driver.

MUSB can only source up to 100mA on the bus, which is perfectly ok on the 
otg point of view. If you attach a device that needs more than 100mA you'll
get
a vbus error.

To have a clue about how much your reader does attach it to you host pc and
issue
lsusb -v -d <vendorid>:<productid> and check the MaxPower field. Of course
this is just
a string and if the manufacturer decided to mess it up it's not our fault
:-p

The correct way to measure the current consumption would be with a
multimeter, but the
string usually give you a clue :-)


-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Bryan Wu]

On Mon, Apr 7, 2008 at 3:46 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>
>
>
>  On Mon, 7 Apr 2008 03:35:38 -0700, "Bryan Wu" <cooloney@kernel.org> wrote:
>  > On Mon, Apr 7, 2008 at 3:19 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>  >>
>  >>
>  >>
>  >>  On Mon, 7 Apr 2008 03:15:38 -0700, "Bryan Wu" <cooloney@kernel.org>
>  > wrote:
>  >>  > Hi folks,
>  >>  >
>  >>  > Here is our bug tracker,
>  >>  >
>  >>
>  >
>  https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3788
>  >>  >
>  >>  > ZiO! CF card reader is here:
>  >>  > http://www.psism.com/zio.htm
>  >>  >
>  >>  > - Firstly, MUSB is working as in host mode which can be figured out
>  > by
>  >>  > the debug message.
>  >>  > - Enumeration of the ZiO! CF card reader is OK.
>  >>  > - When the upper drivers/usb/storage/shuttle_usbat.c try to send out
>  >>  > the first packet:
>  >>  > --
>  >>  >         /* Enable peripheral control signals */
>  >>  >         rc = usbat_write_user_io(us,
>  >>  >                                  USBAT_UIO_OE1 | USBAT_UIO_OE0,
>  >>  >                                  USBAT_UIO_EPAD | USBAT_UIO_1);
>  >>  >         if (rc != USB_STOR_XFER_GOOD)
>  >>  >                 return USB_STOR_TRANSPORT_ERROR;
>  >>  > --
>  >>  >
>  >>  > - Finally, we got VBUS_ERROR interrupt in peripheral mode. I don't
>  >>  > know how to recover it.
>  >>  > If I am not wrong, the ZiO! CF card reader must have dropped the VBUS
>  >>  > and this triggered the mode change of MUSB.
>  >>  >
>  >>  > Are you guys have any idea about this?
>  >>  >
>  >>  > B.T.W, I found the packet sequence of
>  >>  > drivers/usb/storage/shuttle_usbat.c is not the same as Windows Host
>  >>  > does.
>  >>  > So I modified the code to send out the same packet as Windows Host.
>  >>  > The result is the same.
>  >>
>  >>  It's probably drawing more the 100mA, try using a self-powered usb hub
>  >>  attached
>  >>  to musb and zio to hub.
>  >>
>  >
>  > So that means it's possible related with the hardware design?
>  > Unfortunately, there is no self-powered usb hub on my side.
>  > Only have normal full-speed usb hub which is powered by usb host. So
>  > maybe we should add this kind of usb devices to the black list of MUSB
>  > driver.
>
>  MUSB can only source up to 100mA on the bus, which is perfectly ok on the
>  otg point of view. If you attach a device that needs more than 100mA you'll
>  get
>  a vbus error.
>

Right.
>From the device descriptor, if the MaxPower is greater than 100mA, our
usb OTG stack should refuse it, right?

>  To have a clue about how much your reader does attach it to you host pc and
>  issue
>  lsusb -v -d <vendorid>:<productid> and check the MaxPower field. Of course
>  this is just
>  a string and if the manufacturer decided to mess it up it's not our fault
>  :-p
>
>  The correct way to measure the current consumption would be with a
>  multimeter, but the
>  string usually give you a clue :-)
>

Thanks, that is pretty handy for us.
But I found the MaxPower of my ZiO! is 100mA, too bad.
--
$ sudo lsusb -v -d 04e6:1010

Bus 002 Device 003: ID 04e6:1010 SCM Microsystems, Inc. USBAT-2
CompactFlash Card Reader
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        16
  idVendor           0x04e6 SCM Microsystems, Inc.
  idProduct          0x1010 USBAT-2 CompactFlash Card Reader
  bcdDevice            0.05
  iManufacturer           1 SHUTTLE
  iProduct                2 SCM Micro USBAT-02
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      1
      bInterfaceProtocol    255
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0001
  Self Powered
--

-Bryan Wu

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Felipe Balbi]

On Mon, 7 Apr 2008 04:08:33 -0700, "Bryan Wu" <cooloney@kernel.org> wrote:
> On Mon, Apr 7, 2008 at 3:46 AM, Felipe Balbi <me@felipebalbi.com> wrote:
>>
>>
>>
>>  On Mon, 7 Apr 2008 03:35:38 -0700, "Bryan Wu" <cooloney@kernel.org>
> wrote:
>>  > On Mon, Apr 7, 2008 at 3:19 AM, Felipe Balbi <me@felipebalbi.com>
> wrote:
>>  >>
>>  >>
>>  >>
>>  >>  On Mon, 7 Apr 2008 03:15:38 -0700, "Bryan Wu" <cooloney@kernel.org>
>>  > wrote:
>>  >>  > Hi folks,
>>  >>  >
>>  >>  > Here is our bug tracker,
>>  >>  >
>>  >>
>>  >
>> 
>
https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3788
>>  >>  >
>>  >>  > ZiO! CF card reader is here:
>>  >>  > http://www.psism.com/zio.htm
>>  >>  >
>>  >>  > - Firstly, MUSB is working as in host mode which can be figured
> out
>>  > by
>>  >>  > the debug message.
>>  >>  > - Enumeration of the ZiO! CF card reader is OK.
>>  >>  > - When the upper drivers/usb/storage/shuttle_usbat.c try to send
> out
>>  >>  > the first packet:
>>  >>  > --
>>  >>  >         /* Enable peripheral control signals */
>>  >>  >         rc = usbat_write_user_io(us,
>>  >>  >                                  USBAT_UIO_OE1 | USBAT_UIO_OE0,
>>  >>  >                                  USBAT_UIO_EPAD | USBAT_UIO_1);
>>  >>  >         if (rc != USB_STOR_XFER_GOOD)
>>  >>  >                 return USB_STOR_TRANSPORT_ERROR;
>>  >>  > --
>>  >>  >
>>  >>  > - Finally, we got VBUS_ERROR interrupt in peripheral mode. I
> don't
>>  >>  > know how to recover it.
>>  >>  > If I am not wrong, the ZiO! CF card reader must have dropped the
> VBUS
>>  >>  > and this triggered the mode change of MUSB.
>>  >>  >
>>  >>  > Are you guys have any idea about this?
>>  >>  >
>>  >>  > B.T.W, I found the packet sequence of
>>  >>  > drivers/usb/storage/shuttle_usbat.c is not the same as Windows
> Host
>>  >>  > does.
>>  >>  > So I modified the code to send out the same packet as Windows
> Host.
>>  >>  > The result is the same.
>>  >>
>>  >>  It's probably drawing more the 100mA, try using a self-powered usb
> hub
>>  >>  attached
>>  >>  to musb and zio to hub.
>>  >>
>>  >
>>  > So that means it's possible related with the hardware design?
>>  > Unfortunately, there is no self-powered usb hub on my side.
>>  > Only have normal full-speed usb hub which is powered by usb host. So
>>  > maybe we should add this kind of usb devices to the black list of
> MUSB
>>  > driver.
>>
>>  MUSB can only source up to 100mA on the bus, which is perfectly ok on
> the
>>  otg point of view. If you attach a device that needs more than 100mA
> you'll
>>  get
>>  a vbus error.
>>
> 
> Right.
> From the device descriptor, if the MaxPower is greater than 100mA, our
> usb OTG stack should refuse it, right?
> 
>>  To have a clue about how much your reader does attach it to you host pc
> and
>>  issue
>>  lsusb -v -d <vendorid>:<productid> and check the MaxPower field. Of
> course
>>  this is just
>>  a string and if the manufacturer decided to mess it up it's not our
> fault
>>  :-p
>>
>>  The correct way to measure the current consumption would be with a
>>  multimeter, but the
>>  string usually give you a clue :-)
>>
> 
> Thanks, that is pretty handy for us.
> But I found the MaxPower of my ZiO! is 100mA, too bad.

I recall having some issues on 100mA devices. During enumeration some
current spikes
a few mAs above 100mA were occuring and we couldn't enumerate the device
due to vbus_err
interrupt. If you check drivers/usb/musb/tusb6010.c you'll see that we've
implemented
a retry condition for those cases. The same retry can be found in
musb_core.c

Maybe you could use something similar on your blackfin. BTW, if I can ask
which OTG transceiver are you using ?


-- 
Best Regards,

Felipe Balbi
http://felipebalbi.com
me@felipebalbi.com

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[David Brownell]

On Monday 07 April 2008, Felipe Balbi wrote:
> I recall having some issues on 100mA devices. During enumeration some
> current spikes a few mAs above 100mA were occuring and we couldn't
> enumerate the device due to vbus_err interrupt.

Yeah, I think the Mentor core is unduly sensitive to voltage
fluctuation during enumeration.  There's supposed to be about
100 msec before VBUS must stabilize ... but the silicon doesn't
seem to accept routine instabilities in that period, and then
reports inappropriate VBUS errors.


> If you check drivers/usb/musb/tusb6010.c you'll see that we've 
> implemented a retry condition for those cases. The same retry can
> be found in musb_core.c

The DaVinci support needed the same kind of logic.  All in
all this is painful stuff to sort out, and it seems that
each platform rediscovers it.  It would be better if the
silicon itself weren't fighting back so hard...

- Dave

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Felipe Balbi]

On Mon, Apr 07, 2008 at 09:05:09AM -0700, David Brownell wrote:
> On Monday 07 April 2008, Felipe Balbi wrote:
> > I recall having some issues on 100mA devices. During enumeration some
> > current spikes a few mAs above 100mA were occuring and we couldn't
> > enumerate the device due to vbus_err interrupt.
> 
> Yeah, I think the Mentor core is unduly sensitive to voltage
> fluctuation during enumeration.  There's supposed to be about
> 100 msec before VBUS must stabilize ... but the silicon doesn't
> seem to accept routine instabilities in that period, and then
> reports inappropriate VBUS errors.
> 
> 
> > If you check drivers/usb/musb/tusb6010.c you'll see that we've 
> > implemented a retry condition for those cases. The same retry can
> > be found in musb_core.c
> 
> The DaVinci support needed the same kind of logic.  All in
> all this is painful stuff to sort out, and it seems that
> each platform rediscovers it.  It would be better if the
> silicon itself weren't fighting back so hard...

Good point.

-- 
Best Regards,

Felipe Balbi
me@felipebalbi.com
http://blog.felipebalbi.com

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Bryan Wu]

On Tue, Apr 8, 2008 at 12:05 AM, David Brownell <david-b@pacbell.net> wrote:
> On Monday 07 April 2008, Felipe Balbi wrote:
>  > I recall having some issues on 100mA devices. During enumeration some
>  > current spikes a few mAs above 100mA were occuring and we couldn't
>  > enumerate the device due to vbus_err interrupt.
>
>  Yeah, I think the Mentor core is unduly sensitive to voltage
>  fluctuation during enumeration.  There's supposed to be about
>  100 msec before VBUS must stabilize ... but the silicon doesn't
>  seem to accept routine instabilities in that period, and then
>  reports inappropriate VBUS errors.
>

For this VBUS error, Blackfin MUSB port follows other platforms idea to retry.

But to this bug, the ZiO card reader will trigger the mode change
maybe due to the VBUS drop.
It should be different as the VBUS error in the enumeration, because
the enumeration of the ZiO
is OK.

And for our development board EZKIT548, it can provide 500mA current
at 5V as it claimed in manual
with a external regular. So from my point of view, this bug is not
related with 100mA current limit issue.

>
>
>  > If you check drivers/usb/musb/tusb6010.c you'll see that we've
>  > implemented a retry condition for those cases. The same retry can
>  > be found in musb_core.c
>
>  The DaVinci support needed the same kind of logic.  All in
>  all this is painful stuff to sort out, and it seems that
>  each platform rediscovers it.  It would be better if the
>  silicon itself weren't fighting back so hard...
>

Yes, I reported this to our silicon designers.

-Bryan

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Bryan Wu]

On Tue, Apr 8, 2008 at 3:06 PM, Bryan Wu <cooloney@kernel.org> wrote:
> On Tue, Apr 8, 2008 at 12:05 AM, David Brownell <david-b@pacbell.net> wrote:
>  > On Monday 07 April 2008, Felipe Balbi wrote:
>  >  > I recall having some issues on 100mA devices. During enumeration some
>  >  > current spikes a few mAs above 100mA were occuring and we couldn't
>  >  > enumerate the device due to vbus_err interrupt.
>  >
>  >  Yeah, I think the Mentor core is unduly sensitive to voltage
>  >  fluctuation during enumeration.  There's supposed to be about
>  >  100 msec before VBUS must stabilize ... but the silicon doesn't
>  >  seem to accept routine instabilities in that period, and then
>  >  reports inappropriate VBUS errors.
>  >
>
>  For this VBUS error, Blackfin MUSB port follows other platforms idea to retry.
>
>  But to this bug, the ZiO card reader will trigger the mode change
>  maybe due to the VBUS drop.
>  It should be different as the VBUS error in the enumeration, because
>  the enumeration of the ZiO
>  is OK.
>
>  And for our development board EZKIT548, it can provide 500mA current
>  at 5V as it claimed in manual
>  with a external regular. So from my point of view, this bug is not
>  related with 100mA current limit issue.
>
>

These days I tried hard to workaround this issue, but failed:

- When VBUS_ERR happens in OTG_A_HOST state and the OTG is in
peripheral mode, I try to start a new session and power on VBUS.
- CONNECT IRQ fired and OTG is switch back to host mode.
- In CONNECT IRQ handler, I rescan the musb->endpoint[i].in_qh or
musb->endpoint[i].out_qh. Then resume the urb transfer which was
stopped by the wrong VBUS_ERR mode switch IRQ. or just dequeue the urb
to call off the transfer.
- But the ZiO does not reply anymore. No IRQ from USB hardware. World
keeps silence.

I think this kind of devices maybe should be added to the blacklist of
the musb otg driver.

Do you guys have some idea about that?

Thanks a lot
-Bryan Wu

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[Felipe Balbi]

On Thu, Apr 10, 2008 at 07:24:50PM +0800, Bryan Wu wrote:
> I think this kind of devices maybe should be added to the blacklist of
> the musb otg driver.
> 
> Do you guys have some idea about that?

overcurrent protection is triggering fine, that's why you're getting
vbus_err. Blacklist shouldn't be in the kernel, what we should do is
just notify the user about this error (needed for otg certification)
but never blacklist anything.

On the other hand, musb core seems to behave in a quite silly way when
it comes to current spikes on read/write operations (after enumeration
and after you can access the device). It should rely on its capacitors
on case of vbus drop and only trigger vbus_err interrupt if it really
couldn't recover from it after capacitors are discharged otherwise it
should stay silently and filter out such current spikes.

I'm still looking into how to filter this out in software but it's been
quite a challenge as you noticed yourself.

Let's try to keep going on this, otherwise user experience will be
awful with several mass storage devices.

-- 
Best Regards,

Felipe Balbi
me@felipebalbi.com
http://blog.felipebalbi.com

Re: [Help 1/2] MUSB: ZiO! CF card reader will trigger a change from MUSB host mode to MUSB peripheral mode

[David Brownell]

On Thursday 10 April 2008, Bryan Wu wrote:
> >  And for our development board EZKIT548, it can provide 500mA current
> >  at 5V as it claimed in manual
> >  with a external regular. So from my point of view, this bug is not
> >  related with 100mA current limit issue.

It's *supposed* to be able to provide that much ... steady
state.  But the issue here is current spikes that cause the
voltage to drop too low.

Did you stick a scope on that signal and *verify* that the
voltage never dropped below the valid level?


> These days I tried hard to workaround this issue, but failed:
> 
> - When VBUS_ERR happens in OTG_A_HOST state and the OTG is in
> peripheral mode, I try to start a new session and power on VBUS.
> - CONNECT IRQ fired and OTG is switch back to host mode.

It needs to re-enumerate at this point, including USB reset.


> - In CONNECT IRQ handler, I rescan the musb->endpoint[i].in_qh or
> musb->endpoint[i].out_qh. Then resume the urb transfer which was
> stopped by the wrong VBUS_ERR mode switch IRQ. or just dequeue the urb
> to call off the transfer.
> - But the ZiO does not reply anymore. No IRQ from USB hardware. World
> keeps silence.

That's compatible with the voltage actually dropping too low,
so that the peripheral AND host see the session as broken.

Sometimes it can help to put a powered hub in between the
musb host and the peripheral ...

- Dave




--
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