1. 18 4月, 2013 2 次提交
  2. 12 4月, 2013 1 次提交
  3. 11 4月, 2013 1 次提交
  4. 10 4月, 2013 6 次提交
  5. 09 4月, 2013 5 次提交
    • M
      USB: EHCI: make ehci-msm a separate driver · 8c68e84f
      Manjunath Goudar 提交于
      Separate the  Qualcomm QSD/MSM on-chip host controller driver from
      ehci-hcd host code so that it can be built as a separate driver module.
      This work is part of enabling multi-platform kernels on ARM;
      however, note that other changes are still needed before Qualcomm QSD/MSM
      can be booted with a multi-platform kernel, which is not expected before
      3.11.
      
      With the infrastructure added by Alan Stern in patch 3e023203
      "USB: EHCI: prepare to make ehci-hcd a library module", we can
      avoid this problem by turning a bus glue into a separate
      module, as we do here for the msm bus glue.
      
      In V5 (arnd):
       - add FIXME about missing usb_add_hcd() or usb_remove_hcd() calls
      
      In V3:
       - Detailed commit message added here describing why this patch is required.
       - Arranged  #include's in alphabetical order.
       - driver.name initialized hcd_name[] = "ehci-msm" in platform_driver
         structure initialization instead of "msm-ehci", which was the reason
         why it broke in EHCI USB testing
      
      In V2:
      Tegra patch related changes removed from this patch.
      Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NDavid Brown <davidb@codeaurora.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8c68e84f
    • M
      USB: EHCI: make ehci-atmel a separate driver · 97736961
      Manjunath Goudar 提交于
      Separate the Atmel host controller driver from ehci-hcd host code
      so that it can be built as a separate driver module.
      This work is part of enabling multi-platform kernels on ARM;
      however, note that other changes are still needed before Atmel can be
      booted with a multi-platform kernel. This is currently planned for
      Linux-3.11.
      
      With the infrastructure added by Alan Stern in patch 3e023203
      "USB: EHCI: prepare to make ehci-hcd a library module", we can
      avoid this problem by turning a bus glue into a separate
      module, as we do here for the Atmel bus glue.
      
      In V4 (arnd):
       - reordered #include statements.
       - removed call to ehci_shutdown and the corresponding export
      
      In V3:
       - Detailed commit message added here about why this patch is required.
       - Replaced hcd_name string "ehci-atmel" to "atmel-ehci".
       - Inserted blank line in the Makefile to separate the EHCI drivers from
         the following non-EHCI drivers.
       - Exported ehci_shutdown symbol as it is needed by the Atmel driver.
       - Eliminated ehci_atmel_setup routine because hcd registers
         can be directly set in the ehci_atmel_drv_probe function.
      
      In V2:
        Resolved below compiler error.
        drivers/usb/host/ehci-atmel.c: In function 'ehci_atmel_drv_remove':
        drivers/usb/host/ehci-atmel.c:167: error: implicit declaration of function 'ehci_shutdown'
      Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Cc: Andrew Victor <linux@maxim.org.za>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97736961
    • M
      USB: EHCI: make ehci-s5p a separate driver · 7edb3daf
      Manjunath Goudar 提交于
      Separate the  Samsung S5P/EXYNOS host controller driver from ehci-hcd
      host code so that it can be built as a separate driver module.
      This work is part of enabling multi-platform kernels on ARM;
      however, note that other changes are still needed before S5P/EXYNOS can
      be booted with a multi-platform kernel. We currently expect those
      to get merged for 3.10.
      
      With the infrastructure added by Alan Stern in patch 3e023203
      "USB: EHCI: prepare to make ehci-hcd a library module", we can
      avoid this problem by turning a bus glue into a separate
      module, as we do here for the s5p bus glue.
      
      In V4 (arnd)
       - revert some of the pointless changes.
       - fix allocation of s5p specific data structure.
      
      In V3:
       - Detailed commit message added here, why this patch is required.
       - MODULE_LICENSE is GPL v2.
       - Added .extra_priv_size to eliminate the separate allocation of
         the s5p_ehci_hcd structure and removed .reset function pointer
         initialization.
       - Arranged  #include's in alphabetical order.
       - After using extra_priv_size initialization, struct usb_hcd *hcd
         is redundant and can be removed from the probe function.
       - Eliminated s5p_ehci_phy_enable,contents of statements moved
         into the s5p_ehci_probe
       - Eliminated s5p_ehci_phy_disable, contents of statements moved into
         the s5p_ehci_remove.
      
      In V2:
       - Tegra patch related changes removed from this patch.
      Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
      Acked-by: NJingoo Han <jg1.han@samsung.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7edb3daf
    • M
      USB: EHCI: make ehci-spear a separate driver · 7675d6ba
      Manjunath Goudar 提交于
      Separate the SPEAr host controller driver from ehci-hcd host code
      so that it can be built as a separate driver module.
      This work is part of enabling multi-platform kernels on ARM;
      however, note that other changes are still needed before SPEAr can be
      booted with a multi-platform kernel, but they are queued in the
      arm-soc tree for 3.10.
      
      With the infrastructure added by Alan Stern in patch 3e023203
      "USB: EHCI: prepare to make ehci-hcd a library module", we can
      avoid this problem by turning a bus glue into a separate
      module, as we do here for the SPEAr bus glue.
      
      In V4 (arnd):
       - renamed all 'struct spear_ehci' pointers from 'ehci' to the
         less ambiguous 'sehci'.
       - folded trivial spear_start_ehci/spear_stop_ehci functions into
         callers.
       - brought back initialization of ehci->caps.
      
      In V3:
       - Detailed commit message added here about why this patch is required.
       - Eliminated ehci_spear_setup routine because hcd registers can
         be directly set in the spear_ehci_hcd_drv_probe function.
       - spear_overrides struct initialized.
       - Converted to using .extra_priv_size for allocating spear_ehci,
         and updated all users of that structure.
       - to_spear_ehci() macro modified for spear_ehci.
      
      In V2:
       - Replaced spear as SPEAr everywhere, leaving functions/variables/config options.
      Signed-off-by: NDeepak Saxena <dsaxena@linaro.org>
      Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NViresh Kumar <viresh.linux@gmail.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: Shiraz Hashim <shiraz.hashim@st.com>
      Cc: spear-devel@list.st.com
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7675d6ba
    • M
      USB: EHCI: make ehci-orion a separate driver · a76dd463
      Manjunath Goudar 提交于
      Separate the Orion host controller driver from ehci-hcd host
      code into its own driver module because of following reason.
      
      With the multiplatform changes in arm-soc tree, it becomes
      possible to enable the mvebu platform (which uses
      ehci-orion) at the same time as other platforms that require
      a conflicting EHCI bus glue. At the moment, this results
      in a warning like
      
      drivers/usb/host/ehci-hcd.c:1297:0: warning: "PLATFORM_DRIVER" redefined [enabled by default]
      drivers/usb/host/ehci-hcd.c:1277:0: note: this is the location of the previous definition
      drivers/usb/host/ehci-orion.c:334:31: warning: 'ehci_orion_driver' defined but not used [-Wunused-variable]
      
      and an ehci driver that only works on one of them.
      
      With the infrastructure added by Alan Stern in patch 3e023203
      "USB: EHCI: prepare to make ehci-hcd a library module", we can
      avoid this problem by turning a bus glue into a separate
      module, as we do here for the orion bus glue.
      
      An earlier version of this patch was included in 3.9 but caused
      a regression there, which has subsequently been fixed.
      
      While we are here, use the opportunity to disabiguate the two
      Marvell EHCI controller implementations in Kconfig.
      
      In V4 (arnd):
      - Improve Kconfig text
      
      In V3:
      - More detail provided in commit message regarding this patch.
      - Replaced hcd_name string "ehci-orion" into "orion-ehci".
      - MODULE_LICENSE is GPL v2.
      - In ehci_init_driver calling second argument passed  as NULL instead of
        ehci_orion_overrides because ehci_orion_overrides is removed.
      
      In V2:
      - Tegra patch related changes removed from this patch.
      Signed-off-by: NManjunath Goudar <manjunath.goudar@linaro.org>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NJason Cooper <jason@lakedaemon.net>
      Tested-by: NAndrew Lunn <andrew@lunn.ch>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a76dd463
  6. 08 4月, 2013 1 次提交
  7. 04 4月, 2013 5 次提交
  8. 02 4月, 2013 2 次提交
  9. 29 3月, 2013 7 次提交
  10. 26 3月, 2013 10 次提交
    • S
      USB: EHCI: fix bug in iTD/siTD DMA pool allocation · 85ecd032
      Soeren Moch 提交于
      [Description written by Alan Stern]
      
      Soeren tracked down a very difficult bug in ehci-hcd's DMA pool
      management of iTD and siTD structures.  Some background: ehci-hcd
      gives each isochronous endpoint its own set of active and free itd's
      (or sitd's for full-speed devices).  When a new itd is needed, it is
      taken from the head of the free list, if possible.  However, itd's
      must not be used twice in a single frame because the hardware
      continues to access the data structure for the entire duration of a
      frame.  Therefore if the itd at the head of the free list has its
      "frame" member equal to the current value of ehci->now_frame, it
      cannot be reused and instead a new itd is allocated from the DMA pool.
      The entries on the free list are not released back to the pool until
      the endpoint is no longer in use.
      
      The bug arises from the fact that sometimes an itd can be moved back
      onto the free list before itd->frame has been set properly.  In
      Soeren's case, this happened because ehci-hcd can allocate one more
      itd than it actually needs for an URB; the extra itd may or may not be
      required depending on how the transfer aligns with a frame boundary.
      For example, an URB with 8 isochronous packets will cause two itd's to
      be allocated.  If the URB is scheduled to start in microframe 3 of
      frame N then it will require both itds: one for microframes 3 - 7 of
      frame N and one for microframes 0 - 2 of frame N+1.  But if the URB
      had been scheduled to start in microframe 0 then it would require only
      the first itd, which could cover microframes 0 - 7 of frame N.  The
      second itd would be returned to the end of the free list.
      
      The itd allocation routine initializes the entire structure to 0, so
      the extra itd ends up on the free list with itd->frame set to 0
      instead of a meaningful value.  After a while the itd reaches the head
      of the list, and occasionally this happens when ehci->now_frame is
      equal to 0.  Then, even though it would be okay to reuse this itd, the
      driver thinks it must get another itd from the DMA pool.
      
      For as long as the isochronous endpoint remains in use, this flaw in
      the mechanism causes more and more itd's to be taken slowly from the
      DMA pool.  Since none are released back, the pool eventually becomes
      exhausted.
      
      This reuslts in memory allocation failures, which typically show up
      during a long-running audio stream.  Video might suffer the same
      effect.
      
      The fix is very simple.  To prevent allocations from the pool when
      they aren't needed, make sure that itd's sent back to the free list
      prematurely have itd->frame set to an invalid value which can never be
      equal to ehci->now_frame.
      
      This should be applied to -stable kernels going back to 3.6.
      Signed-off-by: NSoeren Moch <smoch@web.de>
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      85ecd032
    • A
      USB: EHCI: remove unused variable in unlink_empty_async() · afc2c9a2
      Alan Stern 提交于
      This patch (as1669) removes the check_unlinks_later flag in ehci-hcd's
      unlink_empty_async().  It wasn't being used for anything and should
      have been removed in an earlier patch, but I forgot about it.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afc2c9a2
    • A
      USB: EHCI: improve end_unlink_async() · 214ac7a0
      Alan Stern 提交于
      This patch (as1665) changes the way ehci-hcd's end_unlink_async()
      routine works in order to avoid recursive execution and to be more
      efficient:
      
      	Now when an IAA cycle ends, a new one gets started up right
      	away (if it is needed) instead of waiting until the
      	just-unlinked QH has been processed.
      
      	The async_iaa list is renamed to async_idle, which better
      	expresses its new purpose: It is now the list of QHs which are
      	now completely idle and are waiting to be processed by
      	end_unlink_async().
      
      	A new flag is added to track whether an IAA cycle is in
      	progress, because the list formerly known as async_iaa no
      	longer stores the QHs waiting for the IAA to finish.
      
      	The decision about how many QHs to process when an IAA cycle
      	ends is now made at the end of the cycle, when we know the
      	current state of the hardware, rather than at the beginning.
      	This means a bunch of logic got moved from start_iaa_cycle()
      	to end_unlink_async().
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      214ac7a0
    • A
      USB: EHCI: convert singly-linked lists to list_heads · 6e018751
      Alan Stern 提交于
      This patch (as1664) converts ehci-hcd's async_unlink, async_iaa, and
      intr_unlink from singly-linked lists to standard doubly-linked
      list_heads.  Originally it didn't seem necessary to use list_heads,
      because items are always added to and removed from these lists in FIFO
      order.  But now with more list processing going on, it's easier to use
      the standard routines than continue with a roll-your-own approach.
      
      I don't know if the code ends up being notably shorter, but the
      patterns will be more familiar to any kernel hacker.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6e018751
    • A
      USB: EHCI: consolidate code in ehci_urb_dequeue() · 7655e316
      Alan Stern 提交于
      This patch (as1668) consolidates two nearly identical code paths in
      ehci_urb_dequeue().  The test for !qh can be removed because it will
      never succeed; the fact that usb_hcd_check_unlink_urb() returned 0
      means that urb must be queued and therefore urb->hcpriv must point to
      a QH.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7655e316
    • A
      USB: EHCI: split needs_rescan into two flags · 7bc782d7
      Alan Stern 提交于
      This patch (as1662) does some more QH-related cleanup in ehci-hcd.
      The qh->needs_rescan flag is currently used for two different
      purposes; the patch replaces it with two separate flags for greater
      clarity: qh->dequeue_during_giveback indicates that a completion
      handler dequeued an URB (implying that a rescan is needed), and
      qh->exception indicates that the QH is in an exceptional state
      requiring an unlink (either it encountered an I/O error or an unlink
      was requested).
      
      The new flags get set where the dequeue, exception, or unlink request
      occurred, rather than where the unlink is started.  This is so that in
      the future, if we need to, we will be able to tell apart unlinks that
      truly were required from those that were carried out merely because
      the QH wasn't being used.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bc782d7
    • A
      USB: EHCI: change return value of qh_completions() · 79bcf7b0
      Alan Stern 提交于
      This patch (as1658) cleans up the usage of qh_completions() in
      ehci-hcd.  Currently the function's return value indicates whether any
      URBs were given back; the idea was that the caller can scan the QH
      over again to handle any URBs that were dequeued by a completion
      handler.  This is not necessary; when qh_completions() is ready to
      give back dequeued URBs, it does its own rescanning.
      
      Therefore the new return value will be a flag indicating whether the
      caller needs to unlink the QH.  This is more convenient than forcing
      the caller to check qh->needs_rescan, and it makes a lot more sense --
      why should "needs_rescan" imply that an unlink is needed?  The callers
      are also changed to remove the unneeded rescans.
      
      Lastly, the check for whether qh->qtd_list is non-empty is removed
      from the start of qh_completions().  Two of the callers have to make
      this test anyway, so the same test can simply be added to the other
      two callers.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      79bcf7b0
    • A
      USB: EHCI: changes related to qh_refresh() · c1fdb68e
      Alan Stern 提交于
      This patch (as1638) makes several changes to the ehci-hcd driver, all
      related to the qh_refresh() function.  This function must be called
      whenever an idle QH gets linked back into either the async or the
      periodic schedule.
      
      	Change a BUG_ON() in the qh_update routine to a WARN_ON().
      	Since this code runs in atomic context, a BUG_ON() would
      	immediately freeze the whole system.
      
      	Remove two unneeded calls to qh_refresh(), one when a QH is
      	initialized and one when a QH becomes idle.  Adjust the
      	adjacent comments accordingly.
      
      	Move the qh_refresh() and qh_link_periodic() calls for new
      	interrupt URBs to after the new TDs have been added.
      
      	As a result of the previous two changes, qh_refresh() is never
      	called when the qtd_list is empty.  The corresponding check in
      	qh_refresh() can be removed, along with an indentation level.
      
      These changes should not cause any alteration of behavior.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c1fdb68e
    • S
      xhci: Don't warn on empty ring for suspended devices. · a83d6755
      Sarah Sharp 提交于
      When a device attached to the roothub is suspended, the endpoint rings
      are stopped.  The host may generate a completion event with the
      completion code set to 'Stopped' or 'Stopped Invalid' when the ring is
      halted.  The current xHCI code prints a warning in that case, which can
      be really annoying if the USB device is coming into and out of suspend.
      
      Remove the unnecessary warning.
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Tested-by: NStephen Hemminger <stephen@networkplumber.org>
      a83d6755
    • V
      usb: xhci: Fix TRB transfer length macro used for Event TRB. · 1c11a172
      Vivek Gautam 提交于
      Use proper macro while extracting TRB transfer length from
      Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23)
      for the same, and use it instead of TRB_LEN (bits 0:16) in
      case of event TRBs.
      
      This patch should be backported to kernels as old as 2.6.31, that
      contain the commit b10de142 "USB: xhci:
      Bulk transfer support".  This patch will have issues applying to older
      kernels.
      Signed-off-by: NVivek gautam <gautam.vivek@samsung.com>
      Signed-off-by: NSarah Sharp <sarah.a.sharp@linux.intel.com>
      Cc: stable@vger.kernel.org
      1c11a172