On Sun, Jul 26, 2009 at 7:49 PM, Praveen G K<praveen.gk@xxxxxxxxx> wrote: > 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. This patch does the job. Thanks! >> >>> 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
