On Sat, Jul 25, 2009 at 4:30 PM, Sergei Shtylyov<sshtylyov@xxxxxxxxxxxxx> wrote: > Hello. > > Praveen G K wrote: > >> Hi, >> > > Please don't top-post. Place your text below the quoted message. > >> I also notice that when I include a delay in the >> musb_gadget_halt_function, when it comes out of the >> musb_dma_completion() function, the SendStall & SentStall bits are not >> set, as compared to the case when there is no delay. >> >> So, looks like the CPU is setting the SendStall bit after issuing an >> IN request, which eventually causes the controller to reset. >> >> Please let me know of any workaround. >> > > Stall handling is still broken, especially for the mass storage gadget. The > musb_gadget driver erroneously aborts the CSW transfer after sending STALL > when halting endpoint after a short *data* transfer (usually SCSI MODE SENSE > command) where the actual command data length is less than expected -- that > causes a host to reset the bus. Then it repeats and repeats all over again. > I've posted the patch addressing this months ago but David Brownell hasn't > taken it as he expected me to also implement set_wedge() method. Here's the > link for you to try: > > http://marc.info/?l=linux-usb&m=123643624125801 Thanks for the patch info, Sergei. Will try this and get back to you. > >> Thanks, >> Praveen >> >> >> On Fri, Jul 24, 2009 at 11:17 AM, Praveen G K<praveen.gk@xxxxxxxxx> wrote: >> >>> >>> Hi, >>> >>> I am still debugging with the old kernel, and I am at a point wherein, >>> if I specify any sort of delay in the musb_gadget_set_halt function in >>> musb_gadget.c file, the enumeration is instantaneous. If not, I see a >>> reset signaling on the USB bus, because of which my controller gets >>> reset. I am trying to narrow down the reason for this race condition. >>> >>> Thanks in advance for any help, >>> Praveen Krishnan >>> >>> On Mon, Jul 20, 2009 at 12:51 AM, Felipe Balbi<felipe.balbi@xxxxxxxxx> >>> wrote: >>> >>>> >>>> hi, >>>> >>>> On Sat, Jul 18, 2009 at 02:51:13AM +0200, ext Praveen G K wrote: >>>> >>>>> >>>>> Hello all, >>>>> >>>>> I am using a MUSB gadget on TI OMAP3 processor to get the device into >>>>> mass storage mode. If I load the module with stall=0, I see that the >>>>> file storage gadget mounts the device instantaneously on the host. >>>>> But, if the stall=1 parameter is specified, it takes at least five >>>>> minutes for the device to get mounted on the host (though the >>>>> enumeration takes place quickly). >>>>> >>>>> I am not sure whether it is sending the last packet before stalling >>>>> the endpoints. >>>>> >>>> >>>> if you're still using 2.6.24 or anything older, we can't help you as I >>>> said before on private mail. Please, try to boot your board with current >>>> linux-omap-2.6.git [1] and see if the same problem happens there. If it >>>> does, then we will ask for more verbose output: >>>> >>>> echo 5 > /sys/modules/musb_hdrc/parameters/debug >>>> >>>> [1] >>>> http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary >>>> > > Felipe, this seems a known problem even with the current kernel. David is > to blame for it being still unsolved. ;-) > >>>> -- >>>> balbi > > WBR, Sergei > > > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
