On Mon, 7 Apr 2008 03:44:12 -0700, "Bryan Wu" <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 7, 2008 at 3:21 AM, Felipe Balbi <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> On Mon, 7 Apr 2008 03:16:31 -0700, "Bryan Wu" <[EMAIL PROTECTED]>
> 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
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
