Although if it wasn't a Heisenbug at the very least it's a Schroedenbug! I noticed that it shouldn't've ever worked, as it didn't seem like we were setting IPR if it wasn't a short packet. In write_ep0_fifo(), I changed/added:
} else if (ep->dev->req_pending) ep0start(ep->dev, UDCCS0_IPR, "IN"); else UDCCS0 = UDCCS0_IPR;
That seems to get at least one packet (16 bytes) through, but shortly thereafter, the host seems to reset me. Do I need to set more bits?
No, IPR is set _implicitly_ when the FIFO fills ... that's why it's only set _explicitly_ to send short packets. See the UDC spec; you just made it send a full packet (16 bytes) followed by a ZLP. Which the host sees as a failed read (too short), and that's what causes the reset. (That's typical for device side controllers.)
I seem to recall that IPR is wierd in various ways though. Isn't that the bit that you can't read -- but which, when the host clears it, you get an IRQ? So if there's an IRQ that doesn't have any obvious source, you've got to conclude it was IPR clearing. Not conducive to robust behavior, and it's one of the things that's made me avoid touching any of the IRQ/PIO code since it seemed to fall "into the groove" and behave in all the regression tests.
I'll have to see if the 2.6.0-test8-rmk1 patch works for me; there are so many missing PXA drivers that all I can really test on 2.6 is booting on NFS-over-Ether-over-USB, which works just fine (even with DMA!), at least on a PXA255.
- Dave
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
