1. 18 1月, 2013 7 次提交
    • P
      usb: dwc3: gadget: correct return from ep_queue · 15f86bde
      Pratyush Anand 提交于
      Its better to return from each if condition as they are mutually
      exclusive.
      Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      15f86bde
    • P
      usb: dwc3: gadget: fix missed isoc · 7efea86c
      Pratyush Anand 提交于
      There are two reasons to generate missed isoc.
      
      1. when the host does not poll for all the data.
      2. because of application-side delays that prevent all the data from
      being transferred in programmed microframe.
      
      Current code was able to handle first case only.  This patch handles
      scenario 2 as well.Scenario 2 sometime may occur with complex gadget
      application, however it can be easily reproduced for testing purpose as
      follows:
      
      a. use isoc binterval as 1 in f_sourcesink.
      b. use pattern=0
      c. introduce a delay of 150us deliberately in source_sink_complete, so
      that after few frames it lands into scenario 2.
      d. now run testusb 16 (isoc in  test). You will notice that if this
      patch is not applied then isoc transfer is not able to recover after
      first missed.
      
      Current patch's approach is as under:
      
      If missed isoc occurs and there is no request queued then issue END
      TRANSFER, so that core generates next xfernotready and we will issue a
      fresh START TRANSFER.
      If there are still queued request then wait, do not issue either END or
      UPDATE TRANSFER, just attach next request in request_list during giveback.
      If any future queued request is successfully transferred then we will issue
      UPDATE TRANSFER for all request in the request_list.
      
      Cc: <stable@vger.kernel.org> # v3.6 v3.7 v3.8
      Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7efea86c
    • P
      usb: dwc3: Enable usb2 LPM only when connected as usb2.0 · 2b758350
      Pratyush Anand 提交于
      Synopsys says:
      The HIRD Threshold field must be set to ‘0’ when the device core is
      operating in super speed mode.
      
      This patch implements above statement.
      
      Cc: <stable@vger.kernel.org> # v3.6 v3.7 v3.8
      Acked-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2b758350
    • F
      usb: dwc3: debugfs: convert our regdump to use regsets · d7668024
      Felipe Balbi 提交于
      regset is a generic implementation of regdump
      utility through debugfs.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      d7668024
    • F
      usb: dwc3: gadget: don't redefine 'ret' · 7dbdf4e4
      Felipe Balbi 提交于
      we have an extra 'ret' variable shadowing a previous
      definition. Remove it.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7dbdf4e4
    • J
      usb: dwc3: exynos: use devm_ functions · 20b97dc1
      Jingoo Han 提交于
      The devm_ functions allocate memory that is released when a driver
      detaches. This makes the code smaller and a bit simpler.
      Signed-off-by: NJingoo Han <jg1.han@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      20b97dc1
    • F
      usb: dwc3: decrease event buffer size · 5da93478
      Felipe Balbi 提交于
      Currently we're allocating an entire page to
      serve as our event buffer. Provided our events
      are 4 bytes long, it's very unlikely we will
      even trigger 1k events at once.
      
      Even in the worst case scenario where every
      endpoint triggers one event and we still have
      a couple of error events, that would still
      be less than 40 events.
      
      In order to cope with future versions of the
      IP which could (or could not) increase the
      amount of possible events to trigger
      simultaneously, we're using an arbitrary size
      of 64 events for our event buffer.
      
      We're saving 3840 bytes by doing so.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      5da93478
  2. 13 12月, 2012 1 次提交
  3. 22 11月, 2012 3 次提交
  4. 16 11月, 2012 1 次提交
  5. 08 11月, 2012 1 次提交
  6. 06 11月, 2012 2 次提交
  7. 31 10月, 2012 1 次提交
  8. 19 10月, 2012 1 次提交
  9. 15 10月, 2012 4 次提交
  10. 11 9月, 2012 4 次提交
  11. 07 9月, 2012 3 次提交
  12. 31 8月, 2012 3 次提交
    • M
      usb: gadget: get rid of USB_GADGET_{DUAL,SUPER}SPEED · 85b8614d
      Michal Nazarewicz 提交于
      This commit removes USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED
      Kconfig options.  Since now kernel allows many UDC drivers to be
      compiled, those options may turn to no longer be valid.  For
      instance, if someone decides to build UDC that supports super
      speed and UDC that supports high speed only, the latter will be
      "assumed" to support super speed since USB_GADGET_SUPERSPEED will
      be selected by the former.
      
      The test of whether CONFIG_USB_GADGET_*SPEED was defined was just
      an optimisation which removed otherwise dead code (ie. if UDC is
      not dual speed, there is no need to handle cases that can happen
      if speed is high).  This commit removes those checks.
      Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      85b8614d
    • C
      usb: dwc3: set up burst size only superspeed mode · d2e9a13a
      Chanho Park 提交于
      When connection is established non-ss mode, endpoint.maxburst is correctly set
      to 0, this means that current code will set maxburst bitfield on DEPCFG's
      parameter 0 to the highest possible value (0x0f) which is wrong.
      
      Even though this hasn't caused any issues so far (HW seems to ignore that when
      not running in SS mode) we want to make sure maxburst bitfield is only set to
      anything other than zero if we're running on SuperSpeed mode. In order to
      achieve that, let's check for gadget's operating speed before setting maxburst
      bitfield when issuing DEPCFG command.
      
      [ balbi@ti.com : improved commit log a bit in order to clarify the situation ]
      Signed-off-by: NChanho Park <chanho61.park@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      d2e9a13a
    • O
      usb: dwc3: core: memory ordering fix in close · 2a540edf
      Oliver Neukum 提交于
      As a bitmap is used for free/used. As a device freed
      all memory operations must be scheduled before the bitmap
      is manipulated.
      Signed-off-by: NOliver Neukum <oneukum@suse.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2a540edf
  13. 15 8月, 2012 1 次提交
    • F
      usb: dwc3: gadget: warn about endpoint already enabled before changing ep name · c6f83f38
      Felipe Balbi 提交于
      In case some gadget driver tries to enable an endpoint
      which is already enabled, we print a nice WARN so we
      can track broken gadget drivers. The only problem is that
      we're printing the WARN when we already changed endpoint's
      name, which would result in endpoints named as:
      
      ep1in-bulk-bulk-bulk-bulk-bulk-bulk-bulk
      
      To prevent that, we will continue to print the WARN,
      but do so before changing endpoint's name and return
      early.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      c6f83f38
  14. 10 8月, 2012 1 次提交
  15. 09 8月, 2012 1 次提交
  16. 07 8月, 2012 2 次提交
    • P
      usb: dwc3: gadget: correct missed isoc when endpoint is busy · 79c9046e
      Pratyush Anand 提交于
      When MISSED_ISOC is set, BUSY is also set. Since, we are handling
      MISSED_ISOC as a separate case in third scenario, therefore handle only
      BUSY but not MISSED_ISOC in second scenario.
      Signed-off-by: NPratyush Anand <pratyush.anand@st.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      79c9046e
    • M
      usb: dwc3: gadget: Fix sparse warnings · 348e026f
      Moiz Sonasath 提交于
      This patch fixes the following sparse warnings:
      
      drivers/usb/dwc3/gadget.c:1096:7: warning: symbol 'ret' shadows an earlier one
      drivers/usb/dwc3/gadget.c:1058:8: originally declared here
      drivers/usb/dwc3/gadget.c:1100:16: warning: symbol 'dwc' shadows an earlier one
      drivers/usb/dwc3/gadget.c:1057:15: originally declared here
      drivers/usb/dwc3/gadget.c:1118:16: warning: symbol 'dwc' shadows an earlier one
      drivers/usb/dwc3/gadget.c:1057:15: originally declared here
      drivers/usb/dwc3/gadget.c:1800:19: warning: symbol 'dep' shadows an earlier one
      drivers/usb/dwc3/gadget.c:1778:18: originally declared here
      
      Also, fix the potential checkpatch errors around the if() loops that
      this fix patch can create.
      Signed-off-by: NMoiz Sonasath <m-sonasath@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      348e026f
  17. 03 8月, 2012 4 次提交
    • F
      usb: dwc3: ep0: make sure to reinitilize ep1 on STALL · 2dfe37d4
      Felipe Balbi 提交于
      When issuing SetStall on ep0, we must make sure to
      reinitialize all flags on physical ep1 too.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2dfe37d4
    • F
      usb: dwc3: ep0: fix status phase delayed status direction · 7125d584
      Felipe Balbi 提交于
      commit 68d3e668 (usb: dwc3: ep0: fix for possible early
      delayed_status) added handling for early delayed status,
      but the current code only works because so far delayed
      status will always be on the IN direction.
      
      This patch makes the code more robust by making sure that
      we can handle all directions properly.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      7125d584
    • F
      usb: dwc3: ep0: drop XferNotReady(DATA) support · 2e3db064
      Felipe Balbi 提交于
      Due to the late Silicon limitation found, we are
      now pre-starting DATA phase's TRBs. If, still, we
      get XferNotReady(DATA) we will ignore it unless
      we're getting it for the wrong direction.
      
      In that case we must keep the error case handling
      plus add a ENDTRANSFER command to forcefully end
      the Data TRB we started previously, then continue
      to SetStall and so on.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2e3db064
    • F
      usb: dwc3: ep0: move DATA phase away from on-demand · fca8892a
      Felipe Balbi 提交于
      We uncovered a limitation of this core WRT to the
      Link Layer Compliance Suite's TD7.06.
      
      On that test, host will start a GetDescriptor(DEVICE)
      standard request, but it will do so only on the
      SETUP phase, meaning there will *NOT* be any DATA or
      STATUS phases.
      
      The idea of the test is to verify robustness of the
      IP WRT framing errors, so the test will send a
      sequence of different SETUP_DPs each with a different
      framing error and the Suite expects us to be able to
      receive all SETUP_DPs with no timeouts.
      
      This core, has the ability to tell us which phase the
      host is expecting before we start it. Whenever we
      receive a TP or DP when no transfers are cached on
      the internal IP's caches, the IP will generate a
      XferNotReady event with status informing us (in case
      of physical ep0/ep1) if it's related to DATA or STATUS
      phases - SETUP phase is expected to be prestarted.
      
      Because we're always waiting for XferNotReady
      events for DATA and STATUS phases, we will never
      be able to know that the Host wants to start another
      SETUP phase instead, which will render us "not
      compliant" with TD7.06.
      
      In order to "fix" the problem we must not rely
      on XferNotReady events for the DATA phase  and try
      to always pre-start DATA transfers on physical
      endpoints 0 and 1. If host goes back to SETUP phase
      from DATA phase we will receive a XferComplete for
      that phase with TRB's status set to SETUP_PENDING,
      which is only useful for printing a debugging log as
      the core expects us to still go through to the STATUS
      phase, initiate a CONTROL_STATUS TRB just so it
      completes right away and, only then, we go back to
      the pending SETUP phase.
      
      SNPS has decided to modify the programming model of
      the core so that on-demand DATA phases will not be
      supported anymore. Note that this limitation does not
      affect 2-stage transfers, meaning that if TD7.06 would
      start a 2-stage transfer instead of a 3-stage transfer,
      we would receive a "fake" XferNotReady(STATUS) which
      would complete right after being initiated with
      SETUP_PENDING status.
      
      Other endpoints are also not affected, so we can still
      use on-demand transfers on Bulk/Isoc/Interrupt endpoints.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      fca8892a