On Tue, 11 Jan 2005, Vladimir Trukhin wrote:

> As far as I got, read_fifo() function is called either in handle_ep() or 
> in pxa2xx_ep_queue() calls.
> 
> During the time shown in the logs from the previous letter most sending 
> operations are done by handle_ep() call which, in turn, is called from 
> interrupt service routine pxa2xx_udc_irq(). So, for most sending 
> operations interrupts occur. But not for the case with sending response 
> to READ FORMAT CAPACITIES.
> 
> Here is a part of the new log:
> 
> -----------------------------------------------------------
> udc: pxa2xx_udc: pxa2xx_ep_queue: insert into queue (time: 7806.73297 s):
> g_file_storage gadget: get_next_command: after start_transfer (time: 
> 7806.73328 s):
> g_file_storage gadget: get_next_command: wait for next packet (time: 
> 7806.73359 s):
> g_file_storage gadget: get_next_command: wakeup (time: 7806.73393 s):

This extra wakeup must be from the completion of the previous bulk-in 
message.

> g_file_storage gadget: get_next_command: wait for next packet (time: 
> 7806.73421 s):
> 
> udc: pxa2xx_udc: pxa2xx_udc_irq: not RST (time: 7806.78041 
> s):                 <------ !!!!!!!

Okay, that looks normal.

<...>
> udc: pxa2xx_udc: pxa2xx_ep_queue: insert into queue (time: 7806.80195 s):
> g_file_storage gadget: get_next_command: after start_transfer (time: 
> 7806.80226 s):
> g_file_storage gadget: get_next_command: wait for next packet (time: 
> 7806.80257 s):
> g_file_storage gadget: get_next_command: wakeup (time: 7806.80291 s):
> g_file_storage gadget: get_next_command: wait for next packet (time: 
> 7806.80320 s):
> 
>                                                                         
> <-------------  No Interrupts!!!

Either Windows didn't send a packet or else the PXA didn't interrupt when 
the packet was received.  The second is more likely.  Could this be 
related to the endpoint halt that occurs earlier?  True, that halt is for 
the bulk-in endpoint, not the bulk-out.  And you said that this works okay 
with a Linux host, which will also provoke a bulk-in endpoint halt.

> Does somebody have an idea why interrupts may not happen?

Not me; I don't know anything about the pxa2xx_udc driver.  Maybe someone 
else does.

Alan Stern



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to