1. 18 3月, 2015 1 次提交
    • B
      USB: ehci-atmel: rework clk handling · e32643a7
      Boris Brezillon 提交于
      The EHCI IP only needs the UTMI/UPLL (uclk) and the peripheral (iclk)
      clocks to work properly. Remove the useless system clock (fclk).
      
      Avoid calling set_rate on the fixed rate UTMI/IPLL clock and remove
      useless IS_ENABLED(CONFIG_COMMON_CLK) tests (all at91 platforms have been
      moved to the CCF).
      
      This patch also fixes a bug introduced by 3440ef16 (ARM: at91/dt: fix USB
      high-speed clock to select UTMI), which was leaving the usb clock
      uninitialized and preventing the OHCI driver from setting the usb clock
      rate to 48MHz.
      This bug was caused by several things:
      1/ usb clock drivers set the CLK_SET_RATE_GATE flag, which means the rate
         cannot be changed once the clock is prepared
      2/ The EHCI driver was retrieving and preparing/enabling the uhpck
         clock which was in turn preparing its parent clock (the usb clock),
         thus preventing any rate change because of 1/
      
      Fixes: 3440ef16 ("ARM: at91/dt: fix USB high-speed clock to select UTMI")
      Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
      Acked-by: NAlan Stern <stern@rowland.harvard.edu>
      Acked-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e32643a7
  2. 25 1月, 2015 2 次提交
  3. 08 11月, 2014 1 次提交
  4. 09 12月, 2013 1 次提交
  5. 31 10月, 2013 3 次提交
  6. 25 6月, 2013 1 次提交
  7. 17 5月, 2013 1 次提交
    • S
      USB: set device dma_mask without reference to global data · 3b9561e9
      Stephen Warren 提交于
      Many USB host drivers contain code such as:
      
      if (!pdev->dev.dma_mask)
              pdev->dev.dma_mask = &tegra_ehci_dma_mask;
      
      ... where tegra_ehci_dma_mask is a global. I suspect this code originated
      in commit 4a53f4e6 "USB: ehci-tegra: add probing through device tree" and
      was simply copied everywhere else.
      
      This works fine when the code is built-in, but can cause a crash when the
      code is in a module. The first module load sets up the dma_mask pointer,
      but if the module is removed and re-inserted, the value is now non-NULL,
      and hence is not updated to point at the new location, and hence points
      at a stale location within the previous module load address, which in
      turn causes a crash if the pointer is de-referenced.
      
      The simplest way of solving this seems to be to copy the code from
      ehci-platform.c, which uses the coherent_dma_mask as the target for the
      dma_mask pointer.
      Suggested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Acked-by: NTony Prisk <linux@prisktech.co.nz>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3b9561e9
  8. 09 4月, 2013 1 次提交
    • 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
  9. 23 1月, 2013 1 次提交
  10. 22 11月, 2012 3 次提交
  11. 01 11月, 2012 1 次提交
    • A
      USB: EHCI: remove ehci_port_power() routine · c73cee71
      Alan Stern 提交于
      This patch (as1623) removes the ehci_port_power() routine and all the
      places that call it.  There's no reason for ehci-hcd to change the
      port power settings; the hub driver takes care of all that stuff.
      
      There is one exception: When the controller is resumed from
      hibernation or following a loss of power, the ports that are supposed
      to be handed over to a companion controller must be powered on first.
      Otherwise the handover won't work.  This process is not visible to the
      hub driver, so it has to be handled in ehci-hcd.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c73cee71
  12. 11 8月, 2012 1 次提交
  13. 10 7月, 2012 1 次提交
    • A
      EHCI: centralize controller initialization · 1a49e2ac
      Alan Stern 提交于
      This patch (as1564c) converts the EHCI platform drivers to use the
      central ehci_setup() routine for generic controller initialization
      rather than each having its own idiosyncratic approach.
      
      The major point of difficulty lies in ehci-pci's many vendor- and
      device-specific workarounds.  Some of them have to be applied before
      calling ehci_setup() and some after, which necessitates a fair amount
      of code motion.  The other platform drivers require much smaller
      changes.
      
      One point not addressed by the patch is whether ports should be
      powered on or off following initialization.  The different drivers
      appear to handle this pretty much at random.  In fact it shouldn't
      matter, because the hub driver turns on power to all ports when it
      binds to the root hub.  Straightening that out will be left for
      another day.
      Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a49e2ac
  14. 05 4月, 2012 1 次提交
  15. 16 3月, 2012 1 次提交
  16. 04 5月, 2011 1 次提交
  17. 12 3月, 2011 1 次提交
  18. 01 12月, 2010 1 次提交
  19. 03 3月, 2010 1 次提交
  20. 23 9月, 2009 1 次提交