On Wed, Mar 9, 2011 at 10:14 AM, Bernard Blackham wrote: >> On Wed, 2011-03-09 at 16:49, Bernard Blackham wrote: >> > The DFU spec says that bwPollTimeout is the amount of time that >> > should pass between DFU_GETSTATUS requests. If the status is >> > already good, we do not need to sleep as we will not poll again. >> > >> > This speeds up DFU downloads directly into memory. >>
The patch looks fine to me. If I understand the 1.1 spec correctly, the bwPollTimeout only needs to be honoured by the host in the dfuDNBUSY case. On the other hand, I would expect an ideal device to adjust the bwPollTimeout according to what kind of operation it is busy with, thus set a small value (or zero) when writing to RAM, and likewise, set it to zero if the status is not dfuDNBUSY. This is the case for the devices I tested it on, so no speed-up was seen here. But your patch will certainly help those less ideal devices out there :) > One point to note - like the OpenMoko version (which it was based > upon), the current u-boot patch does not populate bwPollTimeout > correctly. I will be posting a fixed patch shortly, so it will not > need a quirk. If people ask, please direct them to fix their u-boot > instead :) Great. Please consider adjusting the bwPollTimeout as explained above, looking at your maple patch it seems like it is currently hardcoded to 5 ms in all cases. BTW, I found this comment in your code: /* FIXME: only accept getstatus if bwPollTimeout * has elapsed */ IMO, this should be respected by the host, so that you don't need to take care of it in the device. Also wondering about your USB_REQ_DFU_DETACH extension. Can you not use a zero-length DNLOAD to enter dfuMANIFEST-WAIT-RESET? Regards, Tormod _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
