1. 29 6月, 2016 1 次提交
  2. 28 4月, 2016 1 次提交
  3. 04 3月, 2016 10 次提交
    • D
      usb: dwc2: host: Totally redo the microframe scheduler · 9f9f09b0
      Douglas Anderson 提交于
      This totally reimplements the microframe scheduler in dwc2 to attempt to
      handle periodic splits properly.  The old code didn't even try, so this
      was a significant effort since periodic splits are one of the most
      complicated things in USB.
      
      I've attempted to keep the old "don't use the microframe" schduler
      around for now, but not sure it's needed.  It has also only been lightly
      tested.
      
      I think it's pretty certain that this scheduler isn't perfect and might
      have some bugs, but it seems much better than what was there before.
      With this change my stressful USB test (USB webcam + USB audio + some
      keyboards) crackles less.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      9f9f09b0
    • D
      usb: dwc2: host: Properly set even/odd frame · 9cf1a601
      Douglas Anderson 提交于
      When setting up ISO and INT transfers dwc2 needs to specify whether the
      transfer is for an even or an odd frame (or microframe if the controller
      is running in high speed mode).
      
      The controller appears to use this as a simple way to figure out if a
      transfer should happen right away (in the current microframe) or should
      happen at the start of the next microframe.  Said another way:
      
      - If you set "odd" and the current frame number is odd it appears that
        the controller will try to transfer right away.  Same thing if you set
        "even" and the current frame number is even.
      - If the oddness you set and the oddness of the frame number are
        _different_, the transfer will be delayed until the frame number
        changes.
      
      As I understand it, the above technique allows you to plan ahead of time
      where possible by always working on the next frame.  ...but it still
      allows you to properly respond immediately to things that happened in
      the previous frame.
      
      The old dwc2_hc_set_even_odd_frame() didn't really handle this concept.
      It always looked at the frame number and setup the transfer to happen in
      the next frame.  In some cases that meant that certain transactions
      would be transferred in the wrong frame.
      
      We'll try our best to set the even / odd to do the transfer in the
      scheduled frame.  If that fails then we'll do an ugly "schedule ASAP".
      We'll also modify the scheduler code to handle this and not try to
      schedule a second transfer for the same frame.
      
      Note that this change relies on the work to redo the microframe
      scheduler.  It can work atop ("usb: dwc2: host: Manage frame nums better
      in scheduler") but it works even better after ("usb: dwc2: host: Totally
      redo the microframe scheduler").
      
      With this change my stressful USB test (USB webcam + USB audio +
      keyboards) has less audio crackling than before.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      9cf1a601
    • D
      usb: dwc2: host: Manage frame nums better in scheduler · fb616e3f
      Douglas Anderson 提交于
      The dwc2 scheduler (contained in hcd_queue.c) was a bit confusing in the
      way it initted / kept track of which frames a QH was going to be active
      in.  Let's clean things up a little bit in preparation for a rewrite of
      the microframe scheduler.
      
      Specifically:
      * Old code would pick a frame number in dwc2_qh_init() and would try to
        pick it "in a slightly future (micro)frame".  As far as I can tell the
        reason for this was that there was a delay between dwc2_qh_init() and
        when we actually wanted to dwc2_hcd_qh_add().  ...but apparently this
        attempt to be slightly in the future wasn't enough because
        dwc2_hcd_qh_add() then had code to reset things if the frame _wasn't_
        in the future.  There's no reason not to just pick the frame later.
        For non-periodic QH we now pick the frame in dwc2_hcd_qh_add().  For
        periodic QH we pick the frame at dwc2_schedule_periodic() time.
      * The old "dwc2_qh_init() actually assigned to "hsotg->frame_number".
        This doesn't seem like a great idea since that variable is supposed to
        be used to keep track of which SOF the interrupt handler has seen.
        Let's be clean: anyone who wants the current frame number (instead of
        the one as of the last interrupt) should ask for it.
      * The old code wasn't terribly consistent about trying to use the frame
        that the microframe scheduler assigned to it.  In
        dwc2_sched_periodic_split() when it was scheduling the first frame it
        always "ORed" in 0x7 (!).  Since the frame goes on the wire 1 uFrame
        after next_active_frame it meant that the SSPLIT would always try for
        uFrame 0 and the transaction would happen on the low speed bus during
        uFrame 1.  This is irregardless of what the microframe scheduler
        said.
      * The old code assumed it would get called to schedule the next in a
        periodic split very quickly.  That is if next_active_frame was
        0 (transfer on wire in uFrame 1) it assumed it was getting called to
        schedule the next uFrame during uFrame 1 too (so it could queue
        something up for uFrame 2).  It should be possible to actually queue
        something up for uFrame 2 while in uFrame 2 (AKA queue up ASAP).  To
        do this, code needs to look at the previously scheduled frame when
        deciding when to next be active, not look at the current frame number.
      * If there was no microframe scheduler, the old code would check for
        whether we should be active using "qh->next_active_frame ==
        frame_number".  This seemed like a race waiting to happen.  ...plus
        there's no way that you wouldn't want to schedule if next_active_frame
        was actually less than frame number.
      
      Note that this change doesn't make 100% sense on its own since it's
      expecting some sanity in the frame numbers assigned by the microframe
      scheduler and (as per the future patch which rewries it) I think that
      the current microframe scheduler is quite insane.  However, it seems
      like splitting this up from the microframe scheduler patch makes things
      into smaller chunks and hopefully adds to clarity rather than reduces
      it.  The two patches could certainly be squashed.  Not that in the very
      least, I don't see any obvious bad behavior introduced with just this
      patch.
      
      I've attempted to keep the config parameter to disable the microframe
      scheduler in tact in this change, though I'm not sure it's worth it.
      Obviously the code is touched a lot so it's possible I regressed
      something when the microframe scheduler is disabled, though I did some
      basic testing and it seemed to work OK.  I'm still not 100% sure why you
      wouldn't want the microframe scheduler (presuming it works), so maybe a
      future patch (or a future version of this patch?) could remove that
      parameter.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      fb616e3f
    • D
      usb: dwc2: host: Split code out to make dwc2_do_reserve() · 2d3f1398
      Douglas Anderson 提交于
      This no-op change splits code out of dwc2_schedule_periodic() into a
      dwc2_do_reserve() function.  This makes it a little easier to follow the
      logic.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      2d3f1398
    • D
      usb: dwc2: host: Reorder things in hcd_queue.c · b951c6c7
      Douglas Anderson 提交于
      This no-op change just reorders a few functions in hcd_queue.c in order
      to prepare for future changes.  Motivations here:
      
      The functions dwc2_hcd_qh_free() and dwc2_hcd_qh_create() are exported
      functions.  They are not called within the file.  That means that they
      should be near the bottom so that they can easily call static helpers.
      
      The function dwc2_qh_init() is only called by dwc2_hcd_qh_create() and
      should move near the bottom with it.
      
      The only reason that the dwc2_unreserve_timer_fn() timer function (and
      its subroutine dwc2_do_unreserve()) were so high in the file was that
      they needed to be above dwc2_qh_init().  Now that dwc2_qh_init() has
      been moved down it can be moved down a bit.  A later patch will split
      the reserve code out of dwc2_schedule_periodic() and the reserve
      function should be near the unreserve function.  The reserve function
      needs to be below dwc2_find_uframe() since it calls that.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      b951c6c7
    • D
      usb: dwc2: host: Rename some fields in struct dwc2_qh · ced9eee1
      Douglas Anderson 提交于
      This no-op change just does some renames to simplify a future patch.
      
      1. The "interval" field is renamed to "host_interval" to make it more
         obvious that this interval may be 8 times the interval that the
         device sees (if we're doing split transactions).  A future patch will
         also add the "device_interval" field.
      2. The "usecs" field is renamed to "host_us" again to make it more
         obvious that this is the time for the transaction as seen by the
         host.  For split transactions the device may see a much longer
         transaction time.  A future patch will also add "device_us".
      3. The "sched_frame" field is renamed to "next_active_frame".  The name
         "sched_frame" kept confusing me because it felt like something more
         permament (the QH's reservation or something).  The name
         "next_active_frame" makes it more obvious that this field is
         constantly changing.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      ced9eee1
    • D
      usb: dwc2: host: Add a delay before releasing periodic bandwidth · 17dd5b64
      Douglas Anderson 提交于
      We'd like to be able to use HCD_BH in order to speed up the dwc2 host
      interrupt handler quite a bit.  However, according to the kernel doc for
      usb_submit_urb() (specifically the part about "Reserved Bandwidth
      Transfers"), we need to keep a reservation active as long as a device
      driver keeps submitting.  That was easy to do when we gave back the URB
      in the interrupt context: we just looked at when our queue was empty and
      released the reserved bandwidth then.  ...but now we need a little more
      complexity.
      
      We'll follow EHCI's lead in commit 9118f9eb ("USB: EHCI: improve
      interrupt qh unlink") and add a 5ms delay.  Since we don't have a whole
      timer infrastructure in dwc2, we'll just add a timer per QH.  The
      overhead for this is very small.
      
      Note that the dwc2 scheduler is pretty broken (see future patches to fix
      it).  This patch attempts to replicate all old behavior and just add the
      proper delay.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      17dd5b64
    • D
      usb: dwc2: host: Add scheduler tracing · 74fc4a75
      Douglas Anderson 提交于
      In preparation for future changes to the scheduler let's add some
      tracing that makes it easy for us to see what's happening.  By default
      this tracing will be off.
      
      By changing "core.h" you can easily trace to ftrace, the console, or
      nowhere.
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      74fc4a75
    • D
      usb: dwc2: host: Always add to the tail of queues · 94ef7aee
      Douglas Anderson 提交于
      The queues the the dwc2 host controller used are truly queues.  That
      means FIFO or first in first out.
      
      Unfortunately though the code was iterating through these queues
      starting from the head, some places in the code was adding things to the
      queue by adding at the head instead of the tail.  That means last in
      first out.  Doh.
      
      Go through and just always add to the tail.
      
      Doing this makes things much happier when I've got:
      * 7-port USB 2.0 Single-TT hub
      * - Microsoft 2.4 GHz Transceiver v7.0 dongle
      * - Jabra speakerphone playing music
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      94ef7aee
    • D
      usb: dwc2: host: Get aligned DMA in a more supported way · 3bc04e28
      Douglas Anderson 提交于
      All other host controllers who want aligned buffers for DMA do it a
      certain way.  Let's do that too instead of working behind the USB core's
      back.  This makes our interrupt handler not take forever and also rips
      out a lot of code, simplifying things a bunch.
      
      This also has the side effect of removing the 65535 max transfer size
      limit.
      
      NOTE: The actual code to allocate the aligned buffers is ripped almost
      completely from the tegra EHCI driver.  At some point in the future we
      may want to add this functionality to the USB core to share more code
      everywhere.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Acked-by: NJohn Youn <johnyoun@synopsys.com>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Tested-by: NJohn Youn <johnyoun@synopsys.com>
      Tested-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NFelipe Balbi <balbi@kernel.org>
      3bc04e28
  4. 15 12月, 2015 1 次提交
  5. 02 10月, 2015 2 次提交
  6. 27 9月, 2015 1 次提交
  7. 07 7月, 2015 1 次提交
  8. 30 4月, 2015 2 次提交
  9. 20 9月, 2014 1 次提交
    • P
      usb: dwc2: handle DMA buffer unmapping sanely · 5dce9555
      Paul Zimmerman 提交于
      The driver's handling of DMA buffers for non-aligned transfers
      was kind of nuts. For IN transfers, it left the URB DMA buffer
      mapped until the transfer completed, then synced it, copied the
      data from the bounce buffer, then synced it again.
      
      Instead of that, just call usb_hcd_unmap_urb_for_dma() to unmap
      the buffer before starting the transfer. Then no syncing is
      required when doing the copy. This should also allow handling of
      other types of mappings besides just dma_map_single() ones.
      
      Also reduce the size of the bounce buffer allocation for Isoc
      endpoints to 3K, since that's the largest possible transfer size.
      
      Tested on Raspberry Pi and Altera SOCFPGA.
      Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5dce9555
  10. 14 1月, 2014 1 次提交
  11. 26 11月, 2013 3 次提交
  12. 15 11月, 2013 1 次提交
  13. 26 9月, 2013 1 次提交
    • D
      staging: dwc2: add microframe scheduler from downstream Pi kernel · 20f2eb9c
      Dom Cobley 提交于
      The transfer scheduler in the dwc2 driver is pretty basic, not to
      mention buggy. It works fairly well with just a couple of devices
      plugged in, but if you add, say, multiple devices with periodic
      endpoints, the scheduler breaks down and can't even enumerate all
      the devices.
      
      To improve this, import the "microframe scheduler" patch from the
      driver in the downstream Raspberry Pi kernel, which is based on
      the Synopsys vendor driver. The original patch came from Denx
      (http://git.denx.de/?p=linux-denx.git) and was commited to the
      raspberrypi.org git tree by "popcornmix" (Dom Cobley).
      
      I have added a driver parameter for this, enabled by default, in
      case anyone has problems with it and needs to disable it. I don't
      think we should add a DT binding for that, though, since I plan
      to remove the option once any bugs are fixed.
      
      [raspberrypi.org patch from Dom Cobley]
      Signed-off-by: NDom Cobley <popcornmix@gmail.com>
      [adapted to dwc2 driver by Paul Zimmerman]
      Signed-off-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      20f2eb9c
  14. 17 9月, 2013 1 次提交
  15. 31 8月, 2013 1 次提交
    • M
      staging: dwc2: unshift non-bool register value constants · f9234633
      Matthijs Kooijman 提交于
      Various register fields wider than one bit have constants defined for
      their value. Previously, these registers would define the values as they
      appear in the register, so shifted to the right to the position the
      value appears in the register.
      
      This commit changes those constants to their natural values (e.g, 0, 1,
      2, etc.), as they are after shifting the register value to the right.
      This also changes all relevant code to shift the values before comparing
      them with constants.
      
      This has the advantage that the values can be stored in smaller
      variables (now they always require a u32) and makes the handling of
      these values more consistent with other register fields that represent
      natural numbers instead of enumerations (e.g., number of host channels).
      Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
      Acked-by: NPaul Zimmerman <paulz@synopsys.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f9234633
  16. 24 7月, 2013 1 次提交
  17. 11 4月, 2013 1 次提交
  18. 12 3月, 2013 1 次提交