linux ehci ehci_urb_enqueue之qh_urb_transaction()分析（一）

 

以下文字会对linux usb hcd driver中的ehci_urb_enqueue函数做一些说明。

先把该函数罗列一下。

1. /*

2.  * non-error returns are a promise to giveback() the urb later

3.  * we drop ownership so next owner (or urb unlink) can get it

4.  *

5.  * urb + dev is in hcd.self.controller.urb_list

6.  * we're queueing TDs onto software and hardware lists

7.  *

8.  * hcd-specific init for hcpriv hasn't been done yet

9.  *

10.  * NOTE:  control, bulk, and interrupt share the same code to append TDs

11.  * to a (possibly active) QH, and the same QH scanning code.

12.  */

13. static int ehci_urb_enqueue (

14.  struct usb_hcd *hcd,

15.  struct urb *urb,

16.  gfp_t mem_flags

17. ) {

18.  struct ehci_hcd *ehci = hcd_to_ehci (hcd);

19.  struct list_head qtd_list;

 

20.  INIT_LIST_HEAD (&qtd_list);

 

21.  switch (usb_pipetype (urb->pipe)) {

22.  case PIPE_CONTROL:

23.  /* qh_completions() code doesn't handle all the fault cases

24.   * in multi-TD control transfers.  Even 1KB is rare anyway.

25.   */

26.  if (urb->transfer_buffer_length > (16 * 1024))

27.  return -EMSGSIZE;

28.  /* FALLTHROUGH */

29.  /* case PIPE_BULK: */

30.  default:

31.  if (!qh_urb_transaction (ehci, urb, &qtd_list, mem_flags))

32.  return -ENOMEM;

33.  return submit_async(ehci, urb, &qtd_list, mem_flags);

 

34.  case PIPE_INTERRUPT:

35.  if (!qh_urb_transaction (ehci, urb, &qtd_list, mem_flags))

36.  return -ENOMEM;

37.  return intr_submit(ehci, urb, &qtd_list, mem_flags);

 

38.  case PIPE_ISOCHRONOUS:

39.  if (urb->dev->speed == USB_SPEED_HIGH)

40.  return itd_submit (ehci, urb, mem_flags);

41.  else

42.  return sitd_submit (ehci, urb, mem_flags);

43.  }

44. }

    ehci_urb_enqueue()函数作为一个回调函数，主要用于实现EHCI指定的数据结构的组织。对它的调用是由usb_submit_urb()一路传下来的。我们知道usb整个系统很复杂，但是从抽象的层面上来说，usb作为一种传输接口，在一个通信模型中扮演信道的角色，即负责数据的传输，那么它是不会对数据做处理的，但是作为信道发送的数据要满足一定的条件，即传输协议，对我们这一层面来说就是EHCI所做的规定，这是一个协议层，ehci_urb_enqueue()其实就是实现了EHCI这一层上HCD(host controller driver)与硬件的读写接口。

代码执行到ehci_urb_enqueue()处，就代表driver有数据要与usb交换（收或发），driver的这些请求由urb传过来，关于urb相关的内容这里不多讲，相关内容可以参考LDD3中usb device driver一节。

 

先概述一下EHCI与CPU的数据交换方式，它是通过在内存中建立一块共享的内存区域，通过DMA的方式实现的。数据在usb设备和HC间传输不需要CPU的干预，但是需要CPU告诉HC共享区域的地址和长度信息（还有usb设备的信息）等，那么CPU就会把共享内存区域的地址、长度等信息构造成HC能识别的表，再把这些表交给HC，那么HC就会按这张表所记录的信息在指定的内存地址处进行数据的传输，传输完成后，以中断的方式通知CPU一次传输的完成，而这些表就是有EHCI spec规定的iTD,QH,qTD等描述符。

 

    下面会按照代码流程往下讲。

    函数ehci_urb_enqueue()首先从hcd中取得当前关联的HC（host controller）的ehci的数据结构，并在这里声明一个队列头qtd_list，并对其初始化，qtd_list用于管理EHCI中的qtd数据结构。接下来是一个switch语句，用于选择当前传输请求的类型，usb传输有四种不同的方式，控制、中断、批量、等时，这些信息都存放在urb中。可以看到控制和批量传输处理方式是相同的，那么就先从这里入手，跟进去看看。

接下来进入到qh_urb_transaction里面，代码列在下面。

1. /*

2.  * create a list of filled qtds for this URB; won't link into qh.

3.  */

4. static struct list_head *

5. qh_urb_transaction (

6.  struct ehci_hcd *ehci,

7.  struct urb *urb,

8.  struct list_head *head,

9.  gfp_t flags

10. ) {

11.  struct ehci_qtd *qtd, *qtd_prev;

12.  dma_addr_t buf;

13.  int len, this_sg_len, maxpacket;

14.  int is_input;

15.  u32 token;

16.  int i;

17.  struct scatterlist *sg;

 

18.  /*

19.   * URBs map to sequences of QTDs:  one logical transaction

20.   */

21.  qtd = ehci_qtd_alloc (ehci, flags);

22.  if (unlikely (!qtd))

23.  return NULL;

24.  list_add_tail (&qtd->qtd_list, head);

25.  qtd->urb = urb;

 

26.  token = QTD_STS_ACTIVE;

27.  token |= (EHCI_TUNE_CERR << 10);

28.  /* for split transactions, SplitXState initialized to zero */

 

29.  len = urb->transfer_buffer_length;

30.  is_input = usb_pipein (urb->pipe);

31.  if (usb_pipecontrol (urb->pipe)) {

32.  /* SETUP pid */

33.  qtd_fill(ehci, qtd, urb->setup_dma,

34.  sizeof (struct usb_ctrlrequest),

35.  token | (2 /* "setup" */ << 8), 8);

 

36.  /* ... and always at least one more pid */

37.  token ^= QTD_TOGGLE;

38.  qtd_prev = qtd;

39.  qtd = ehci_qtd_alloc (ehci, flags);

40.  if (unlikely (!qtd))

41.  goto cleanup;

42.  qtd->urb = urb;

43.  qtd_prev->hw_next = QTD_NEXT(ehci, qtd->qtd_dma);

44.  list_add_tail (&qtd->qtd_list, head);

 

45.  /* for zero length DATA stages, STATUS is always IN */

46.  if (len == 0)

47.  token |= (1 /* "in" */ << 8);

48.  }

 

49.  /*

50.   * data transfer stage:  buffer setup

51.   */

52.  i = urb->num_mapped_sgs;

53.  if (len > 0 && i > 0) {

54.  sg = urb->sg;

55.  buf = sg_dma_address(sg);

 

56.  /* urb->transfer_buffer_length may be smaller than the

57.   * size of the scatterlist (or vice versa)

58.   */

59.  this_sg_len = min_t(int, sg_dma_len(sg), len);

60.  } else {

61.  sg = NULL;

62.  buf = urb->transfer_dma;

63.  this_sg_len = len;

64.  }

 

65.  if (is_input)

66.  token |= (1 /* "in" */ << 8);

67.  /* else it's already initted to "out" pid (0 << 8) */

 

68.  maxpacket = max_packet(usb_maxpacket(urb->dev, urb->pipe, !is_input));

 

69.  /*

70.   * buffer gets wrapped in one or more qtds;

71.   * last one may be "short" (including zero len)

72.   * and may serve as a control status ack

73.   */

74.  for (;;) {

75.  int this_qtd_len;

 

76.  this_qtd_len = qtd_fill(ehci, qtd, buf, this_sg_len, token,

77.  maxpacket);

78.  this_sg_len -= this_qtd_len;

79.  len -= this_qtd_len;

80.  buf += this_qtd_len;

 

81.  /*

82.   * short reads advance to a "magic" dummy instead of the next

83.   * qtd ... that forces the queue to stop, for manual cleanup.

84.   * (this will usually be overridden later.)

85.   */

86.  if (is_input)

87.  qtd->hw_alt_next = ehci->async->hw->hw_alt_next;

 

88.  /* qh makes control packets use qtd toggle; maybe switch it */

89.  if ((maxpacket & (this_qtd_len + (maxpacket - 1))) == 0)

90.  token ^= QTD_TOGGLE;

 

91.  if (likely(this_sg_len <= 0)) {

92.  if (--i <= 0 || len <= 0)

93.  break;

94.  sg = sg_next(sg);

95.  buf = sg_dma_address(sg);

96.  this_sg_len = min_t(int, sg_dma_len(sg), len);

97.  }

 

98.  qtd_prev = qtd;

99.  qtd = ehci_qtd_alloc (ehci, flags);

100.  if (unlikely (!qtd))

101.  goto cleanup;

102.  qtd->urb = urb;

103.  qtd_prev->hw_next = QTD_NEXT(ehci, qtd->qtd_dma);

104.  list_add_tail (&qtd->qtd_list, head);

105.  }

 

106.  /*

107.   * unless the caller requires manual cleanup after short reads,

108.   * have the alt_next mechanism keep the queue running after the

109.   * last data qtd (the only one, for control and most other cases).

110.   */

111.  if (likely ((urb->transfer_flags & URB_SHORT_NOT_OK) == 0

112.  || usb_pipecontrol (urb->pipe)))

113.  qtd->hw_alt_next = EHCI_LIST_END(ehci);

 

114.  /*

115.   * control requests may need a terminating data "status" ack;

116.   * other OUT ones may need a terminating short packet

117.   * (zero length).

118.   */

119.  if (likely (urb->transfer_buffer_length != 0)) {

120.  int one_more = 0;

 

121.  if (usb_pipecontrol (urb->pipe)) {

122.  one_more = 1;

123.  token ^= 0x0100; /* "in" <--> "out"  */

124.  token |= QTD_TOGGLE; /* force DATA1 */

125.  } else if (usb_pipeout(urb->pipe)

126.  && (urb->transfer_flags & URB_ZERO_PACKET)

127.  && !(urb->transfer_buffer_length % maxpacket)) {

128.  one_more = 1;

129.  }

130.  if (one_more) {

131.  qtd_prev = qtd;

132.  qtd = ehci_qtd_alloc (ehci, flags);

133.  if (unlikely (!qtd))

134.  goto cleanup;

135.  qtd->urb = urb;

136.  qtd_prev->hw_next = QTD_NEXT(ehci, qtd->qtd_dma);

137.  list_add_tail (&qtd->qtd_list, head);

 

138.  /* never any data in such packets */

139.  qtd_fill(ehci, qtd, 0, 0, token, 0);

140.  }

141.  }

 

142.  /* by default, enable interrupt on urb completion */

143.  if (likely (!(urb->transfer_flags & URB_NO_INTERRUPT)))

144.  qtd->hw_token |= cpu_to_hc32(ehci, QTD_IOC);

145.  return head;

 

146. cleanup:

147.  qtd_list_free (ehci, urb, head);

148.  return NULL;

149. }

函数开头的注释说，为urb创建并填充的qtd链表，但是并未加入到qh中。这里先要对EHCI中的qTD和qh做一些说明。先上图，如图1为qtd的数据结构图。

 

图1

下面是qTD对应的数据结构定义

1. /*

2.  * EHCI Specification 0.95 Section 3.5

3.  * QTD: describe data transfer components (buffer, direction, ...)

4.  * See Fig 3-6 "Queue Element Transfer Descriptor Block Diagram".

5.  *

6.  * These are associated only with "QH" (Queue Head) structures,

7.  * used with control, bulk, and interrupt transfers.

8.  */

9. struct ehci_qtd {

10.  /* first part defined by EHCI spec */

11.  __hc32 hw_next; /* see EHCI 3.5.1 */

12.  __hc32 hw_alt_next;    /* see EHCI 3.5.2 */

13.  __hc32 hw_token;       /* see EHCI 3.5.3 */

14. #define QTD_TOGGLE (1 << 31) /* data toggle */

15. #define QTD_LENGTH(tok) (((tok)>>16) & 0x7fff)

16. #define QTD_IOC (1 << 15) /* interrupt on complete */

17. #define QTD_CERR(tok) (((tok)>>10) & 0x3)

18. #define QTD_PID(tok) (((tok)>>8) & 0x3)

19. #define QTD_STS_ACTIVE (1 << 7) /* HC may execute this */

20. #define QTD_STS_HALT (1 << 6) /* halted on error */

21. #define QTD_STS_DBE (1 << 5) /* data buffer error (in HC) */

22. #define QTD_STS_BABBLE (1 << 4) /* device was babbling (qtd halted) */

23. #define QTD_STS_XACT (1 << 3) /* device gave illegal response */

24. #define QTD_STS_MMF (1 << 2) /* incomplete split transaction */

25. #define QTD_STS_STS (1 << 1) /* split transaction state */

26. #define QTD_STS_PING (1 << 0) /* issue PING? */

 

27. #define ACTIVE_BIT(ehci) cpu_to_hc32(ehci, QTD_STS_ACTIVE)

28. #define HALT_BIT(ehci) cpu_to_hc32(ehci, QTD_STS_HALT)

29. #define STATUS_BIT(ehci) cpu_to_hc32(ehci, QTD_STS_STS)

 

30.  __hc32 hw_buf [5];        /* see EHCI 3.5.4 */

31.  __hc32 hw_buf_hi [5];        /* Appendix B */

 

32.  /* the rest is HCD-private */

33.  dma_addr_t qtd_dma; /* qtd address */

34.  struct list_head qtd_list; /* sw qtd list */

35.  struct urb *urb; /* qtd's urb */

36.  size_t length; /* length of buffer */

37. } __attribute__ ((aligned (32)))

    

对bulk传输usb_submit_urb()一次提交的传输请求会在qh_urb_transaction()函数中被组成一个qTD的链表队列。一次USB的传输请求是由usb_submit_urb()提交的，要传输相关的数据、地址等信息都放在URB中，qh_urb_transaction()函数就是对URB携带的信息整合到EHCI能识别的数据结构中，即构造相应的qTD，即图1的5个buffer pointer指向地址起始处，total bytes to transfer标明了传输长度。

在Driver中为每个endpoint分配一个qh，qh后面跟上一列qTD，先不管EHCI中对qh的管理模式，如前面的传输概述所述，记住qtd、qh是一些内存地址的索引表，即包含有发送源和接收地的信息表就行，其他的细节在讲到相关的代码时，再做详细介绍，这里单独的讨论Driver对一个qh和它引导的一列qtd的管理方法。

对usb_submit_urb()提交来的请求，首先是构造qtd（当然前提是请求的类型是bulk或interrupt，control类型。假设这里是bulk请求）。

qtd的数据构成形式是由EHCI spec指定的，构造qtd就是按这个标准进行的。如图1，各个字段的意义可参考EHCI的spec，在具体讲到相关的处理代码时根据需要再讲解。对应的DRIVER中给出了对数据段的数据结构体struct ehci_qtd 。struct ehci_qtd 前面的各字段是一一对应的，后面的字段用于软件层面的调用和记录相关信息，如注释。

 

图2

先从总体上描述最终后的数据组织形式，如图2所示，白色方框指代一个qtd，深色为qh，图中的双线箭头是HCD的连接方式，而HC用到的qtd是单向连接的，对应于图1中的next qTD pointer字段，qtd间就是通过这个pointer相连的，HC在处理完当前的qtd后根据这个pointer去找寻下一个qtd。HC先找到QH，再读取QH的信息，QH中有一次传输所需要device的地址、端点等与要传输相关的信息，endpoint是USB传输的最小点，数据的交换是与endpoint联系在一起的。图中强调了末尾处的qtd的IOC位为1，前面的各个IOC为0，IOC为1，意味着当HC完成该qtd的数据传输后，如前面提到的EHCI的通信方式，会在下一个中断周期产生硬件中断信号，表明数据成功传输。这里为什么只对末尾的qtd的IOC置1呢？HCD会把一次完整的数据传输请求放在一个qtd链表中（当一个qtd能描述完当前的请求时，链表长度为1），当最后一个qtd被传输后才认为一次请求全部传输完成，也就是说一个qtd list实际上才代表一次完整的逻辑上连续数据传输，当这组关联的qtd全部被传输完成后，才能算一次请求被处理，接着HC才发出一个中断，之后就会调用urb上的complete回调函数。

 

从上看还是比较简单的，下面结合代码说说我的理解。

函数qh_urb_transaction ()的参数列表中有urb和head，urb是usb device driver的核心，由上层传来，在这里要把urb上携带的读写请求关联到qtd上。实际用到urb的主要内容是数据buffer的长度、地址以及读写方向，而这些信息都要转化到qtd中去。参数head对应图2中的qtd_list，最终填充的qtd将会连在这个head上。

/*

 * URBs map to sequences of QTDs:  one logical transaction

 */

qtd = ehci_qtd_alloc (ehci, flags);

if (unlikely (!qtd))

return NULL;

list_add_tail (&qtd->qtd_list, head);

qtd->urb = urb;

函数qh_urb_transaction从18-25行，如上所示，用函数ehci_qtd_alloc()分配了第一个qtd内存空间，返回后检查分配结果，为空则分配失败直接return，否则分配成功，成功就把此次分配的qtd加入head所引导的队列中，head变量作为qh_urb_transaction参数传入，初始为空队列，在之后的每分配一个qtd的对象都会被加入到head队列中，即成功从qh_urb_transaction返回后，调用者将通过head获取到已分配的qtd内容。

1. /* Allocate the key transfer structures from the previously allocated pool */

 

2. static inline void ehci_qtd_init(struct ehci_hcd *ehci, struct ehci_qtd *qtd,

3. dma_addr_t dma)

4. {

5.     memset (qtd, 0, sizeof *qtd);

6.     qtd->qtd_dma = dma;

7.     qtd->hw_token = cpu_to_hc32(ehci, QTD_STS_HALT);

8.     qtd->hw_next = EHCI_LIST_END(ehci);

9.     qtd->hw_alt_next = EHCI_LIST_END(ehci);

10.     INIT_LIST_HEAD (&qtd->qtd_list);

11. }

 

12. static struct ehci_qtd *ehci_qtd_alloc (struct ehci_hcd *ehci, gfp_t flags)

13. {

14.     struct ehci_qtd *qtd;

15.     dma_addr_t dma;

 

16.     qtd = dma_pool_alloc (ehci->qtd_pool, flags, &dma);

17.     if (qtd != NULL) {

18.         ehci_qtd_init(ehci, qtd, dma);

19.     }

20.     return qtd;

21. }

进入到ehci_qtd_alloc()函数中，如上代码段，可以看到与之相关的处理过程，16行是真正分配了内存空间，dma_pool_alloc从预先准备的DMA内存池中分配一段空间，dma_pool_alloc相关可参考LDD3的相关内容，这个预先分配的DMA内存池ehci->qtd_pool是在EHCI Driver initial阶段分配的。接着判断分配情况，如果OK，就调用ehci_qtd_init()对刚分配qtd空间初始化。

函数ehci_qtd_init()首先对图1中的qtd整个空间初始化为零，接着把qtd自身所处的物理地址填入qtd->qtd_dma中，hw_token的第7位为状态位，值设为0，HC会忽略该qtd，hw_next后没有可用的qtd，即当前qtd后不再跟一个qtd，hw_alt_next字段处理方式相同，这里不是用该字段，最后初始化qtd->qtd_list，以便能联入队列中。总结一下，ehci_qtd_init做了两件事，一是从DMA内存池中分配一个qtd的空间；一是对分配的空间初始化，使其当前状态暂时不能用于传输，并且使其暂时不指向下一个qtd。

 

token = QTD_STS_ACTIVE;

token |= (EHCI_TUNE_CERR << 10);

回到qh_urb_transaction中，有如上两句，变量token即对应于qtd spec中的qTD token字段，在没有写入到qtd的对应字段前作为临时变量存在。结合spec可知，token的第7位标明当前的qtd的有效性，为1，表示该qtd的状态位为active，that is，该qtd可以用于数据传输，该qtd交给HC后，HC会把对它处理，并在处理完后，回写该位为0。[11:10]两位用于错误计数，也由HC在出错后回写。

 

len = urb->transfer_buffer_length;

is_input = usb_pipein (urb->pipe);

if (usb_pipecontrol (urb->pipe)) {

/* SETUP pid */

qtd_fill(ehci, qtd, urb->setup_dma,

sizeof (struct usb_ctrlrequest),

token | (2 /* "setup" */ << 8), 8);

 

/* ... and always at least one more pid */

token ^= QTD_TOGGLE;

qtd_prev = qtd;

qtd = ehci_qtd_alloc (ehci, flags);

if (unlikely (!qtd))

goto cleanup;

qtd->urb = urb;

qtd_prev->hw_next = QTD_NEXT(ehci, qtd->qtd_dma);

list_add_tail (&qtd->qtd_list, head);

 

/* for zero length DATA stages, STATUS is always IN */

if (len == 0)

token |= (1 /* "in" */ << 8);

}

函数qh_urb_transaction()的29行处代码，从urb中读取请求的信息，包括总共要传输的数据长度，此次传输的方向，是向device读还是写。接着判断当前的请求是否为Control类型，这些信息都是可以直接从urb中直接获取到的。

这里假设请求的类型为Control类型，进入到if中分析一下流程。从if的条件可知，满足就意味着当前的urb请求为控制请求，在上层调用函数usb_fill_control_urb来初始化Control请求，其中设置了urb->setup_packet指向了一个用于控制的命令包，经过在usb_submit_urb()中用DMA映射后urb->setup_dma中保留了相应的物理地址，if中的处理就是要将该命令包的地址信息填入qtd中。

这里出现了一个重要的函数qtd_fill,顾名思义，该函数用于填充一个qtd结构，代码如下：

1. /* fill a qtd, returning how much of the buffer we were able to queue up */

 

2. static int

3. qtd_fill(struct ehci_hcd *ehci, struct ehci_qtd *qtd, dma_addr_t buf,

4.    size_t len, int token, int maxpacket)

5. {

6.  int i, count;

7.  u64 addr = buf;

 

8.  /* one buffer entry per 4K ... first might be short or unaligned */

9.  qtd->hw_buf[0] = cpu_to_hc32(ehci, (u32)addr);

10.  qtd->hw_buf_hi[0] = cpu_to_hc32(ehci, (u32)(addr >> 32));

11.  count = 0x1000 - (buf & 0x0fff); /* rest of that page */

12.  if (likely (len < count)) /* ... iff needed */

13.  count = len;

14.  else {

15.  buf +=  0x1000;

16.  buf &= ~0x0fff;

 

17.  /* per-qtd limit: from 16K to 20K (best alignment) */

18.  for (i = 1; count < len && i < 5; i++) {

19.  addr = buf;

20.  qtd->hw_buf[i] = cpu_to_hc32(ehci, (u32)addr);

21.  qtd->hw_buf_hi[i] = cpu_to_hc32(ehci,

22.  (u32)(addr >> 32));

23.  buf += 0x1000;

24.  if ((count + 0x1000) < len)

25.  count += 0x1000;

26.  else

27.  count = len;

28.  }

 

29.  /* short packets may only terminate transfers */

30.  if (count != len)

31.  count -= (count % maxpacket);

32.  }

33.  qtd->hw_token = cpu_to_hc32(ehci, (count << 16) | token);

34.  qtd->length = count;

 

35.  return count;

36. }

函数qtd_fill首行有注释，说填充一个qtd,并返回当前qtd所承载的数据长度。一个qtd最大能索引的地址范围是5×4K的，如图1，对应了5个pointer，单个pointer索引范围为4k，所以如果要使用qtd索引的数据长度超过20K是需要增加多个qtd，通过返回值可以知道已被处理的长度。

 

图3

先贴张图，图中左边箭头的起始端是pointer，对应qtd的后5个字段，箭头指向处为物理内存地址段，黄色部分为数据段，这就是前面概述中说的内存地址索引表，函数qtd_fill目的就是按上图所示把pointer和要指向的物理内存地址关联起来。

qtd->hw_buf[0] = cpu_to_hc32(ehci, (u32)addr);

qtd->hw_buf_hi[0] = cpu_to_hc32(ehci, (u32)(addr >> 32));

count = 0x1000 - (buf & 0x0fff); /* rest of that page */

根据spec qtd的最后5个DWord是一个物理内存地址pointer，其中pointer0的[11:0]位是当前地址偏移，即数据的起始偏移量，[31:12]位则为基地址。上面三行代码，就是pointer0的设置，如代码，只需把参数传递来的值写入其中，对应图中pointer0的指向。qtd_fill的参数buf的值为物理内存起始地址，len为总的数据长度，对应图中整个黄色区域的长度。变量count用于记录该qtd指向的实际长度。一个pointer能索引的最大长度为4K（0x1000）,而且它以高位[31:12]为基地址，即4k对齐的，而pointer0的[11:0]作为起始地址偏移量，如上图，我们的要处理的物理内存地址的起始很可能不在4k边界上，所以pointer0的[11:0]就用于将pointer调整到实际的起始地址处，说了这么多，其实想说的是第3行就是在计算pointer0所指的地址长度，开头和结尾的pointer所指向的地址长度往往会不足4K长，而一个pointer的最大值为4k，所以用0x1000减去偏移量就是剩下的长度。cpu_to_hc32()是对大小端的调整，第2行是针对64位系统的扩展。

qtd_fill()的12行判断了总共要索引长度len和pointer0已索引的长度，若len小于count，说明pointer0索引范围是用[11:0]位开始的偏移处到[11:0]+len，而不是到下一个4k边界处，说明此次要传输只需单个pointer即可，并把count的值调整为len的值，刚才说了count的作用就是记录该qtd最终索引的地址长度。相反len的长度大于count时就需要增加多个pointer了。qtd_fill()第15、16行把buf的地址值调整到据它当前值最近的一个4k的边界上，这个不难理解，结合上图就是pointer1所指的起始处。下面再上张图来解释这个两句，就非常清楚了，如图4。

 

图4

接下来是for循环，循环的目的是填充接下的几个pointer，从循环的条件“count < len && i < 5”看，要结束循环的情况有，当i小于5满足，但是count不满足小于len，说明不能当前urb传输的数据长度不足20k，一个qtd的pointer都没用完。如果是i的值不满足条件，而count小于len，说明urb所传输的数据范围需要使用到多个qtd。当然如果最后恰好两个条件都不满足，说明一个qtd的pointer刚好够用。

qtd_fill()的20行把调整后的值放入qtd的pointer中，接着buf加上0x1000调整到下一个4k边界上，注意这里buf的值经12、13行的调整后已经是4k对齐了。再而判断count+0x1000是否小于len，count加0x1000是刚才用上了一个pointer，索引范围4K，所以count要加0x1000（4k等于0x1000）。如果比len小说明还要继续增加pointer，否则当前的pointer已能完成了内存地址的覆盖，count赋成len的值。这里的过程就是，每填充使用一个pointer，count就增加0x1000后，并与len比较，看是否完成了整个地址区域的索引。             

对于len的长度来说，可能比20k大，即单个 qtd容纳不下，在这样的情况下，退出for循环后，count的值就不等于len，31行再次对count调整，减去和maxpacket的余数，count的值将是maxpacket的整数倍，这里减掉的余数部分地址段将被放到下一个qtd中去。为什么要这样做了呢？首先maxpacket是指一个endpointer一次的最大传输量，可以这样去理解，就好像是这个endpointer上有一个maxpacket大小的FIFO，每次发给它的数据都会先被缓冲到这个FIFO中，接着再对FIFO中的数据进行下一步的处理，在此期间是不能再接收数据的，等到FIFO再一次为空时才开始接收新的数据。HC会以一个qtd为单位进行数据传输，每次发送给endpointer的数据量的最大值就是maxpacket，不能超过这个值，但是可以小于这个值，如果没有从count中减去maxpacket的余数（为零除外），HC传输的最后一个包的数据就不足maxpacket那么大，当然这是没有问题的，但是会浪费掉剩余的带宽（姑且这么叫），如果恰好每一个qtd都会多这么一个尾巴，就会造成更多的浪费，现在把这些尾巴减到，其是就是把它们重新整合，使这个尾巴只能出现在最后一个qtd中,从而节省了带宽。

qtd_fill()最后两句就比较简单了，结合spec中qtd的token[30:16]指明该qtd一共用于传输的字节数，即把count的值写入到token中的[30:16]中。最后返回count的值。