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