On Wed Jun 15 10:58:28 2005 Alan Stern wrote:
> On Wed, 15 Jun 2005, Aric D. Blumer wrote:
>
> > Hello,
> >
> > I hope I'm using the correct email address to contact you.
>
> Yes. It's appropriate to CC: these things to the linux-usb-devel mailing
> list too, and I've taken the liberty of doing so.
OK. Thanks.
> . . .
> > Bulk IN -> Data 0/1 -> Stall
> >
> > In looking at the USB spec version 2.0, bulk-in cannot take this state
> > path. On page 221, it reads, "When the host is ready to receive bulk
> > data, it issues an IN token. The function endpoint responds by returning
> > either a data packet or, should it be unable to return data, a NAK or
> > STALL handshake." So the data packet and stall are mutually exclusive.
>
> The actual sequence of packets depends not on the host but on the USB
> hardware controller driver for the gadget. Your diagram indicates
> that the host sends an IN packet, then the gadget sends a DATA packet,
> and then the gadget sends a STALL packet. That certainly is not a
> legal sequence; the device is not allowed to send STALL (or anything
> else) without the host soliciting a response. Are you certain there
> isn't another IN packet between the DATA and the STALL?
>
> The intended behavior is that the buffer, including its final short
> packet, will be sent to the host. Following that, in response to the
> next IN packet the device should send a STALL. If the device doesn't
> behave this way, the fault lies in the controller driver and not in
> file_storage.c. You didn't mention which controller driver you are
> using; which one is it?
I am bringing up the PXA27x UDC driver. It is based on the pxa2xx_udc.c
code, and in the handling of this particular case, it is the same. So
I'd expect the PXA25x devices to do the same thing, but I don't have
anything to test it on.
This is what I believe is happening: The start_transfer() call enqueues
the data packet to the bulk-in FIFO. Then, halt_bulk_in_endpoint()
calls usb_ep_set_halt(). In the PXA UDC drivers, this function sets the
FST (force stall) bit for the endpoint as well as the FEF (flush
endpoint FIFO) bit. It seems to me from the PXA docs that setting the
FST bit is correct (subsequent IN token requests will be stalled), but
setting the FEF bit can't be right--it would likely remove the packet we
just enqueued to the host. But removing FEF from the assignment does
not fix the problem.
So on closer inspection, I think I was wrong: the stall is not actually
sent, but the host apparently doesn't get the complete packet and times
out when the FST bit is set.
I've done some further tests, and I've definitely narrowed the problem
down to the FST setting:
*ep->reg_udccsr = UDCCSR_FST;
If I take that line and only that line out, it works. With the
assignment, it doesn't. Now to try to figure out why. Any tips from
folks experienced in this would be appreciated. I'm next going to try
to figure out when SST is cleared in this sequence (which also flushes
the IN fifo).
Aric.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
