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.