Noralf Trønnes wrote: > > In all cases, the driver on the host knows/has available how many bytes > > were successfully transfered. > > I was thinking about the device, that it could get out of sync. Let's > say the host sends a 1k framebuffer and half of it gets transferred and > the rest fails for some reason. Lubomir's MCU implementation has an > endpoint max size of 64 bytes and a callback is called for each packet. > If the 1k transfer fails at some point, will the device be able to > detect this and know that the next time the rx callback is called that > this is the start of a new framebuffer update? Ah! No, a device can not detect that the host intended to send more (bulk) packets but e.g. timed out. I can't immediately think of other reasons for a larger transfer to fail, which still allow communication to continue. When the host recognizes a timeout with partial data transfer it could simply send the remaining data in a new transfer. While the device can not detect host intent, the protocol could allow devices to specify requirements, e.g. that the host always sends full frames. In any case, please avoid making a control request mandatory for frame transfer. Because control requests are scheduled differently onto the wire and because they consist of more packets than bulk data, a control request will interrupt a bulk data stream and likely introduce unneccessary latency. If synchronization is always required then I'd suggest to place it inline with frame data, e.g. in the first packet byte. If synchronization is only required in rare cases then a control transfer is probably the better choice, to not waste any inline bytes. But the optimum would be that the device can describe its needs to the host and the host driver ensures that the device always receives the data it needs. Do you think this is possible? Kind regards //Peter _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
