On Mon, 7 Apr 2008 03:44:12 -0700, "Bryan Wu" <cooloney@xxxxxxxxxx> wrote: > On Mon, Apr 7, 2008 at 3:21 AM, Felipe Balbi <me@xxxxxxxxxxxxxxx> wrote: >> >> >> >> On Mon, 7 Apr 2008 03:16:31 -0700, "Bryan Wu" <cooloney@xxxxxxxxxx> > wrote: >> > Hi folks, >> > >> > Here are our trackers, I think following bugs are the same issue: >> > USB-IDE cable: >> > >> > https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3789 >> > MicroSD card reader: >> > >> > https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3790 >> > 30G iPod: >> > >> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.25-rc8/2.6.25-rc8-mm1/2.6.25-rc8-mm1.bz2 >> > SD card reader: >> > >> > https://blackfin.uclinux.org/gf/project/uclinux-dist/tracker/?action=TrackerItemEdit&tracker_id=141&tracker_item_id=3807 >> > >> > a) For the MODE_SENSE(6) SCSI command, these bug usb devices will >> > reply stall when host wait for 1st CSW >> > b) Linux host will clear halt of the endpoint. >> > c) Linux host will wait for the 2nd CSW, but no RX IRQ at all. Then >> > USB reset operation will be triggered by Linux host stack >> > when time out >> > d) The same bug usb devices is OK on Linux host PC, because they will >> > reply to 2nd CSW in the right way. >> > e) So I hacked the usb-storage driver code, the Linux host on > Blackfin >> > will not wait for the 2nc CSW. Then this bug is gone. >> > >> > This is just a workaround for that, it should not be the right way. >> > Does anyone here meet this issue before, on Davinci or OMAP? >> > We always need a real fix, thanks a lot >> >> I've seen this already with n800/n810. > > Oh, thanks god. I'm not the only one struggling in this bug. > >> It came up after a merge with >> mainline >> that changed usb subsystem a bit. Tony made musb driver work again > after >> the merge >> but still some issues that should be addressed. >> > > So is that fixed in linux-omap git repo? Maybe I should update my > local copy with it. > >> If you wanna dig more on this... patches are welcome :-) >> > > My patch is simply skip to start 2cn CSW operation as below: > -- > Index: drivers/usb/storage/transport.c > =================================================================== > --- drivers/usb/storage/transport.c (revision 4075) > +++ drivers/usb/storage/transport.c (working copy) > @@ -1034,9 +1034,11 @@ int usb_stor_Bulk_transport(struct scsi_ > > /* get the status again */ > US_DEBUGP("Attempting to get CSW (2nd try)...\n"); > - result = usb_stor_bulk_transfer_buf(us, us->recv_bulk_pipe, > + bcs->Status = US_BULK_STAT_OK; > + goto bcs_status; > +/* result = usb_stor_bulk_transfer_buf(us, us->recv_bulk_pipe, > bcs, US_BULK_CS_WRAP_LEN, NULL); > - } > +*/ } maybe this command triggers a current spike on the zio reader which is causing the vbus drop ? could be... > > /* if we still have a failure at this point, we're in trouble */ > US_DEBUGP("Bulk status result = %d\n", result); > @@ -1078,6 +1080,7 @@ int usb_stor_Bulk_transport(struct scsi_ > } > } > > +bcs_status: > /* based on the status code, we report good or bad */ > switch (bcs->Status) { > case US_BULK_STAT_OK: > -- > > I just don't understand why they are OK on Linux host PC and failed on > Linux Host embedded MUSB OTG. > > Thanks a lot > -Bryan -- Best Regards, Felipe Balbi http://felipebalbi.com me@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
