Skip to contentSkip to conversation

usb: gadget: Add start_frame to usb_request

PATCH New Felipe Balbi 1 participant 1 message Nov 15, 2018 USB

lore
Share & tools
lore
#0 lore raw

PATCH 1/2 usb: gadget: Add start_frame to usb_request

Hi,

Quoted 31 lines · Thinh Nguyen

Hi Felipe,

Quoted 28 lines · Felipe Balbi

Hi,

Quoted 25 lines · Thinh Nguyen

Similar to URB's start_frame, add a field start_frame to the usb_request to report the scheduled (micro)frame number of an isochronous transfer. This option is useful for debugging purposes.

---
 include/linux/usb/gadget.h | 3 +++
 1 file changed, 3 insertions(+)
include/linux/usb/gadget.h +1 -0
index e5cd84a0f84a..ed9dbbce55ee 100644
@@ -50,6 +50,7 @@ struct usb_ep;
  * @short_not_ok: When reading data, makes short packets be
  *     treated as errors (queue stops advancing till cleanup).
  * @dma_mapped: Indicates if request has been mapped to DMA (internal)
+ * @start_frame: the reported (micro)frame of the scheduled isoc transfer
  * @complete: Function called when request completes, so this request and
  *	its buffer may be re-used.  The function will always be called with
  *	interrupts disabled, and it must not sleep.
@@ -107,6 +108,8 @@ struct usb_request {
 	unsigned		short_not_ok:1;
 	unsigned		dma_mapped:1;
 
Quoted 8 lines
Quoted 4 lines

include/linux/usb/gadget.h struct usb_request { · line 111

Quoted 1 line
include/linux/usb/gadget.h +1 -0
+	int			start_frame;		/* ISO ONLY */

this name is a bit misleading. I can see functions trying to use it to request that a particular request start on a specific frame. Would "started_frame" be a better name, perhaps?

What do you think of changing this field name to "frame_number"? It's generic enough so that this field can potentially be updated in the future to be used as a starting frame in the future, for synchronization.

I don't mind, but remember changing semantics will mean auditing every user of this :-)