Hi Felipe,
On 12/6/2018 10:01 PM, Felipe Balbi wrote:
> Hi,
>
> Thinh Nguyen <thinh.nguyen@xxxxxxxxxxxx> writes:
>>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>>> index 679c12e14522..2de563124fc1 100644
>>>> --- a/drivers/usb/dwc3/gadget.c
>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>> @@ -2254,6 +2254,19 @@ static int dwc3_gadget_ep_reclaim_completed_trb(struct dwc3_ep *dep,
>>>> if (chain && (trb->ctrl & DWC3_TRB_CTRL_HWO))
>>>> trb->ctrl &= ~DWC3_TRB_CTRL_HWO;
>>>>
>>>> + /*
>>>> + * For isochronous transfers, the first TRB in a service interval must
>>>> + * have the Isoc-First type. Track and report its interval frame number.
>>>> + */
>>>> + if (usb_endpoint_xfer_isoc(dep->endpoint.desc) &&
>>>> + (trb->ctrl & DWC3_TRBCTL_ISOCHRONOUS_FIRST)) {
>>>> + unsigned int frame_number;
>>>> +
>>>> + frame_number = DWC3_TRB_CTRL_GET_SID_SOFN(trb->ctrl);
>>>> + frame_number &= ~(dep->interval - 1);
>>>> + req->request.frame_number = frame_number;
>>>> + }
>>> could you refresh my memory on how this is going to be used?
>>>
>> Sure. This informs the upper layer driver what interval the isoc request
>> went out. The users can use this information for applications that
>> require synchronization with the host.
> Thanks. Do you have an example of a gadget that would use it? Perhaps
> g_webcam can rely on this to improve its scheduling? I have this in my
> testing/next already, just looking for an actual user :-)
>
One of our internal IP validation tools uses this to track the isoc data
against the interval it should be in, and it has its custom protocol for
synchronization with the host. But beside debugging purposes, I can also
see that it can be useful for devices that are time-sensitive. I'm not
familiar with g_webcam, but I can imagine that this option can be useful
for it.
When the user queues for a request, it now has the control of what data
should come next. That is, when the user queues for a request, the user
can get the current frame number by calling usb_gadget_frame_number().
Base on the current frame number and what interval the request went out,
the user can determine what data should be queued next and discard any
stale ones. Without this usb_request->frame_number, the user will not
know how many intervals the request is delayed by.
Thinh
