gadget pxa25x_udc g_serial stall problem
Igor Grinberg
grinberg at compulab.co.il
Tue Sep 14 03:42:26 EDT 2010
cc'ed LAKML
On 09/13/10 19:22, Quintin Pitts wrote:
> Hi all,
>
> I'm using linux 2.6.34.1 getting code to work with ViewSonic V210/V110
> platform - pxa255/pxa250 processor.
>
> Under 2.6.34.1 for a arm pxa255 processor, was having a problem getting
> g_serial to work with out stalling on output lines longer than 64 bytes.
>
> Problem was that any command - like free, ls -l etc... would hang from a
> connected minicom session.
>
> Able to log in OK and do small commands that would send less than 64
> bytes at a time.
>
> But anything over 64 bytes of output per line would hang/stall. No
> output to the connected computer session. (ep1in-bulk no more output).
>
> Debugging logs with additional information (list_empty and ep->stopped
> added to message) reported on a free command - produced this for logs.
>
> [ 652.983793] gs_write: ttyGS0 (c0456000) writing 2 bytes
> [ 653.000699] ttyGS0: tx len=2, 0x0d 0x0a 0x73 ...
> [ 653.017493] udc: ep1in-bulk queue req c04768c0, len 2 buf c0476900 list_empty 1 ep->stopped 0
> [ 653.038368] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04768c0
> [ 653.056191] gs_flush_chars: (0,c0456000)
> [ 653.093561] gs_write_room: (0,c0456000) room=8191
> [ 653.111007] gs_write: ttyGS0 (c0456000) writing 71 bytes
>
> Here is the first partial line coming over.
> [ 653.128571] ttyGS0: tx len=64, 0x20 0x20 0x20 ...
> [ 653.145391] udc: ep1in-bulk queue req c04768c0, len 64 buf c0476900 list_empty 1 ep->stopped 0
>
> write fifo - good 64 bytes
> [ 653.166609] udc: wrote ep1in-bulk 64 bytes/L 0 left c04768c0
> [ 653.184456] ttyGS0: tx len=7, 0x62 0x75 0x66 ...
> [ 653.201211] udc: ep1in-bulk queue req c04768c0, len 7 buf c0476900 list_empty 1 ep->stopped 1
>
> Problem additional 7 chars and ep->stopped - pio_irq never gets
> enabled after it has been disabled.
>
> After this point no more data output (ep1in-bulk) is sent.
>
> [ 653.234600] gs_write_room: (0,c0456000) room=8191
> [ 653.252453] gs_write: ttyGS0 (c0456000) writing 2 bytes
> [ 653.270258] ttyGS0: tx len=2, 0x0d 0x0a 0x47 ...
> [ 653.288050] udc: ep1in-bulk queue req c0476840, len 2 buf c0476880 list_empty 0 ep->stopped 0
> [ 653.309317] gs_flush_chars: (0,c0456000)
> [ 653.333737] gs_write_room: (0,c0456000) room=8191
> [ 653.351545] gs_write: ttyGS0 (c0456000) writing 71 bytes
> [ 653.369767] ttyGS0: tx len=64, 0x20 0x20 0x4d ...
> [ 653.387546] udc: ep1in-bulk queue req c04767c0, len 64 buf c0476800 list_empty 0 ep->stopped 0
> [ 653.409704] ttyGS0: tx len=7, 0x20 0x20 0x20 ...
> [ 653.428329] udc: ep1in-bulk queue req c0476740, len 7 buf c0476780 list_empty 0 ep->stopped 0
> [ 653.458930] gs_write_room: (0,c0456000) room=8191
> [ 653.477806] gs_write: ttyGS0 (c0456000) writing 2 bytes
> [ 653.496439] ttyGS0: tx len=2, 0x0d 0x0a 0x47 ...
> [ 653.515178] udc: ep1in-bulk queue req c04766c0, len 2 buf c0476700 list_empty 0 ep->stopped 0
> [ 653.538072] gs_flush_chars: (0,c0456000)
> [ 653.564064] gs_write_room: (0,c0456000) room=8191
> [ 653.583293] gs_write: ttyGS0 (c0456000) writing 45 bytes
> [ 653.602765] ttyGS0: tx len=45, 0x20 0x53 0x77 ...
> [ 653.622085] udc: ep1in-bulk queue req c0476640, len 45 buf c0476680 list_empty 0 ep->stopped 0
> .... Etc ....
> [ 653.982333] gs_write: ttyGS0 (c0456000) writing 2 bytes
> [ 654.001840] ttyGS0: tx len=2, 0x23 0x20 0x47 ...
> [ 654.021619] udc: ep1in-bulk queue req c0476940, len 2 buf c0476980 list_empty 0 ep->stopped 0
>
> While I don't have it recorded the /sys/kernel/debug/pxa25x_udc would
> show queues in ep1in-bulk something like below - this isn't the actual
> from the above session.
>
> ep1in-bulk max 64 pio udccs 0b irqs 18
> req c04758c0 len 0/7 buf c0475900
> req c0475840 len 0/2 buf c0475880
> req c04757c0 len 0/64 buf c0475800
> req c0475740 len 0/7 buf c0475780
> req c04756c0 len 0/2 buf c0475700
> req c0475640 len 0/45 buf c0475680
> req c04755c0 len 0/2 buf c0475600
> req c0475540 len 0/45 buf c0475580
> req c04754c0 len 0/2 buf c0475500
> req c0475940 len 0/2 buf c0475980
>
> In every case a manual enable of the pio_irq 0x40600050 would release
> the hang/stall and process the output and all is well again until next
> long line after queue is processed. Also while it was hung session
> still active - can do commands and still working (maybe until queues or
> memory used up) - just no output.
>
> # devmem2 0x40600050 w
> /dev/mem opened.
> Memory mapped at address 0x40006000.
> Value at address 0x40600050 (0x40006050): 0xFA
> # devmem2 0x40600050 w 0xF8
> /dev/mem opened.
> Memory mapped at address 0x40006000.
> [ 1640.173457] udc: wrote ep1in-bulk 7 bytes/L/S 0 left c04768c0
>
> Value at address 0x40600050 (0x40006050): 0xFA
> [ 1640.191668] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c0476840
> [ 1640.208856] udc: wrote ep1in-bulk 64 bytes/L 0 left c04767c0
> [ 1640.225778] udc: wrote ep1in-bulk 7 bytes/L/S 0 left c0476740
> [ 1640.242338] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04766c0
> [ 1640.258716] udc: wrote ep1in-bulk 45 bytes/L/S 0 left c0476640
> [ 1640.274840] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04765c0
> [ 1640.290379] udc: wrote ep1in-bulk 45 bytes/L/S 0 left c0476540
> [ 1640.306121] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c04764c0
> [ 1640.320844] udc: wrote ep1in-bulk 2 bytes/L/S 0 left c0476940
> Written 0xF8; readback 0xF8
>
> So right or wrong after experimenting and testing the below patch in
> pxa25x_udc.c in function pxa25x_ep_queue fixed my problems.
>
> Both g_serial and g_ether under a pxa255 and pxa250 platforms - perform
> flawlessly in my testing at the moment.
>
> So... If the experts could review and look to see what really should be
> done or maybe already resolved...
>
> Here is what I did.
>
> Thanks,
>
> Quintin.
>
> This is against a 2.6.34.1 kernel source.
>
> --- a/drivers/usb/gadget/pxa25x_udc.c 2010-07-05 13:24:10.000000000 -0500
> +++ b/drivers/usb/gadget/pxa25x_udc.c 2010-09-12 16:06:34.000000000 -0500
> @@ -753,7 +753,8 @@ pxa25x_ep_queue(struct usb_ep *_ep, stru
>
> if (likely (req && ep->desc))
> pio_irq_enable(ep->bEndpointAddress);
> - }
> + } else if (!ep->stopped && req && ep->desc)
> + pio_irq_enable(ep->bEndpointAddress);
>
> /* pio or dma irq handler advances the queue. */
> if (likely(req != NULL))
>
>
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Igor.
More information about the linux-arm-kernel
mailing list