Re: [PATCH v3 0/6] Generic USB Display driver

["Noralf Trønnes" <noralf@tronnes.org>]

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.