Hi,

As defined by the documentation, write is asynchronous, you can only
be sure write is complete when usb_ep_callback is called.
In practice, there are some hacks in current drivers to make write
block if previous one is not completed (active polling on FIFO for the
dw driver, semaphore for stm32 one).

Today there is no transfer concept at usb device driver level, you
only read/write the TX/RX hardware FIFO (usb_dw), this is up to each
class driver to manage packet splitting and transfer start/end,
including short/zero packet management.
This also means that class drivers need to know the endpoint FIFO size
to delineate packets and transfers. This is significant extra work for
each class driver and not really agnostic.

This is why I would like to introduce transfer concept, letting the
device drivers deal with transfer management.
The interface could be something like: usb_transfer(endpoint, buffer,
buffer_len, callback, flags)
The implementation is hardware specific but usb controller usually
have registers to program transfer size, packet count and IRQ to
indicate transfer completion, FIFO empty...
This is a simplified version of Linux USB Request Block (URB).

Regards,
Loic


On 31 January 2018 at 09:28, andrei.emeltchenko@...
<andrei.emeltchenko.news@...> wrote:

Hi,

On Wed, Jan 31, 2018 at 08:09:12AM +0530, Sundar Subramaniyan wrote:

Hi Paul,
On Tue, Jan 30, 2018 at 9:55 PM, Paul Sokolovsky
<[1]paul.sokolovsky@...> wrote:


A good clarification thus would be:

1. bytes_ret is always not-NULL.
2. There can always be short writes, number of bytes written is
returned in *bytes_ret, caller must retry with remaining data as
needed.

Note that this doesn't call for updates to existing drivers - they can
keep accepting bytes_ret as NULL, and loop/block inside. But clients
of this API definitely need to be updated, because otherwise they
simply won't work with some drivers.

I think the same too. For now, new drivers should handle both the methods
to be coherent with the API definition. If ret_bytes is NULL, then it
shall to
a blocked write taking care of fragmentation of the packet internally
within
the driver. Otherwise if it is != NULL, it can let the upper layer do the
fragmentation
and shall *not* block-wait for the completion of the current write on the
USB bus,
since we have write callback for notification purpose.

I think we do not have now this requirement not to block-wait. When
working with sending fragmented packets you would prefer to block until all
fragments are sent.

Best regards
Andrei Emeltchenko
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel