1. 26 11月, 2018 3 次提交
    • F
      usb: dwc3: gadget: track number of TRBs per request · 09fe1f8d
      Felipe Balbi 提交于
      This will help us remove the wait_event() from our ->dequeue().
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      09fe1f8d
    • F
      usb: dwc3: gadget: combine unaligned and zero flags · 1a22ec64
      Felipe Balbi 提交于
      Both flags are used for the same purpose in dwc3: appending an extra
      TRB at the end to deal with controller requirements. By combining both
      flags into one, we make it clear that the situation is the same and
      that they should be treated equally.
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      1a22ec64
    • T
      usb: dwc3: Add workaround for isoc start transfer failure · d92021f6
      Thinh Nguyen 提交于
      In DWC_usb31 version 1.70a-ea06 and prior, for highspeed and fullspeed
      isochronous IN, BIT[15:14] of the 16-bit microframe number reported by
      the XferNotReady event are invalid. The driver uses this number to
      schedule the isochronous transfer and passes it to the START TRANSFER
      command. Because this number is invalid, the command may fail. If
      BIT[15:14] matches the internal 16-bit microframe, the START TRANSFER
      command will pass and the transfer will start at the scheduled time, if
      it is off by 1, the command will still pass, but the transfer will start
      2 seconds in the future. For all other conditions, the START TRANSFER
      command will fail with bus-expiry.
      
      In order to workaround this issue, we can test for the correct
      combination of BIT[15:14] by sending START TRANSFER commands with
      different values of BIT[15:14]: 'b00, 'b01, 'b10, and 'b11. Each
      combination is 2^14 uframe apart (or 2 seconds). 4 seconds into the
      future will result in a bus-expiry status. As the result, within the 4
      possible combinations for BIT[15:14], there will be 2 successful and 2
      failure START COMMAND status. One of the 2 successful command status
      will result in a 2-second delay start. The smaller BIT[15:14] value is
      the correct combination.
      
      Since there are only 4 outcomes and the results are ordered, we can
      simply test 2 START TRANSFER commands with BIT[15:14] combinations 'b00
      and 'b01 to deduce the smaller successful combination.
      
      Let test0 = test status for combination 'b00 and test1 = test status for
      'b01 of BIT[15:14]. The correct combination is as follow:
      
      if test0 fails and test1 passes, BIT[15:14] is 'b01
      if test0 fails and test1 fails, BIT[15:14] is 'b10
      if test0 passes and test1 fails, BIT[15:14] is 'b11
      if test0 passes and test1 passes, BIT[15:14] is 'b00
      
      Synopsys STAR 9001202023: Wrong microframe number for isochronous IN
      endpoints.
      Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      d92021f6
  2. 14 11月, 2018 1 次提交
  3. 06 11月, 2018 1 次提交
    • T
      usb: dwc3: gadget: Properly check last unaligned/zero chain TRB · ba3a51ac
      Thinh Nguyen 提交于
      Current check for the last extra TRB for zero and unaligned transfers
      does not account for isoc OUT. The last TRB of the Buffer Descriptor for
      isoc OUT transfers will be retired with HWO=0. As a result, we won't
      return early. The req->remaining will be updated to include the BUFSIZ
      count of the extra TRB, and the actual number of transferred bytes
      calculation will be wrong.
      
      To fix this, check whether it's a short or zero packet and the last TRB
      chain bit to return early.
      
      Fixes: c6267a51 ("usb: dwc3: gadget: align transfers to wMaxPacketSize")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: NFelipe Balbi <felipe.balbi@linux.intel.com>
      ba3a51ac
  4. 02 10月, 2018 1 次提交
  5. 05 9月, 2018 1 次提交
  6. 30 7月, 2018 1 次提交
  7. 21 5月, 2018 32 次提交