Den 14.07.2020 21.38, skrev Peter Stuge: > 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? > Looking at the host driver I see that I need to fix it so that it requeues the update if it fails (on SET_BUFFER or bulk out). Currently it just goes back to sleep waiting for userspace to announce a new change. I would like to avoid having a special case for retrying the failing part of a bulk transfer for devices that only want full updates, I would prefer to use the common error path of retrying the whole update. This is my suggestion for the new flag: /* * Always send the entire framebuffer when flushing changes. * The GUD_DRM_USB_REQ_SET_BUFFER request will not be sent before each bulk transfer, * it will only be sent if the previous bulk transfer had failed. This is done to * inform the device that the previous update failed and that a new one is started. * * This flag can not be used in combination with compression. */ #define GUD_DRM_DISPLAY_FLAG_FULL_UPDATE BIT(1) Noralf. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
