1. 26 11月, 2013 12 次提交
    • S
      usb: musb: only cancel work if it is initialized · 66fadea5
      Sebastian Andrzej Siewior 提交于
      Since commit c5340bd1 ("usb: musb: cancel work on removal") the workqueue
      is cancelled but then if we bail out before the workqueue is setup we
      get this:
      
      |INFO: trying to register non-static key.
      |the code is fine but needs lockdep annotation.
      |turning off the locking correctness validator.
      |CPU: 0 PID: 708 Comm: modprobe Not tainted 3.12.0+ #435
      |[<c00867bc>] (lock_acquire+0xf0/0x108) from [<c00529d0>] (flush_work+0x38/0x2ec)
      |[<c00529d0>] (flush_work+0x38/0x2ec) from [<c0052d24>] (__cancel_work_timer+0xa0/0x134)
      |[<c0052d24>] (__cancel_work_timer+0xa0/0x134) from [<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc])
      |[<bf0e4ae4>] (musb_free+0x40/0x60 [musb_hdrc]) from [<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc])
      |[<bf0e5364>] (musb_probe+0x678/0xb78 [musb_hdrc]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
      |[<c0294bf0>] (platform_drv_probe+0x1c/0x24) from [<c0293970>] (driver_probe_device+0x90/0x224)
      |[<c0293970>] (driver_probe_device+0x90/0x224) from [<c0291ef0>] (bus_for_each_drv+0x60/0x8c)
      |[<c0291ef0>] (bus_for_each_drv+0x60/0x8c) from [<c02938bc>] (device_attach+0x80/0xa4)
      |[<c02938bc>] (device_attach+0x80/0xa4) from [<c0292b24>] (bus_probe_device+0x88/0xac)
      |[<c0292b24>] (bus_probe_device+0x88/0xac) from [<c0291490>] (device_add+0x388/0x6c8)
      |[<c0291490>] (device_add+0x388/0x6c8) from [<c02952a0>] (platform_device_add+0x188/0x22c)
      |[<c02952a0>] (platform_device_add+0x188/0x22c) from [<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps])
      |[<bf11ea30>] (dsps_probe+0x294/0x394 [musb_dsps]) from [<c0294bf0>] (platform_drv_probe+0x1c/0x24)
      |platform musb-hdrc.1.auto: Driver musb-hdrc requests probe deferral
      |musb-hdrc musb-hdrc.1.auto: musb_init_controller failed with status -517
      
      This patch moves the init part to earlier part so it can be cleaned as
      part of the fail3 label because now it is surrounded by the fail4 label.
      Step two is to remove it from musb_free() and add it to the two cleanup
      paths (error path and device removal) separately.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      66fadea5
    • M
      usb: gadget: composite: reset delayed_status on reset_config · 2bac51a1
      Michael Grzeschik 提交于
      The delayed_status value is used to keep track of status response
      packets on ep0. It needs to be reset or the set_config function would
      still delay the answer, if the usb device got unplugged while waiting
      for setup_continue to be called.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      2bac51a1
    • S
      usb: musb: musb_cppi41: handle pre-mature TX complete interrupt · a655f481
      Sebastian Andrzej Siewior 提交于
      The TX-complete interrupt of the CPPI41 on AM335x fires too early.
      Adding a loop and counting how long it takes until the
      MUSB_TXCSR_TXPKTRDY bit is cleared I see
      FS:
      |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadc54002, len=1514 is_tx=1
      |cppi41_dma_callback() 74 loops
      |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8802, len=1514 is_tx=1
      |cppi41_dma_callback() 66 loops
      |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadcd8002, len=1514 is_tx=1
      |cppi41_dma_callback() 136 loops
      |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=64, mode=0, dma_addr=0xadf55802, len=1514 is_tx=1
      |cppi41_dma_callback() 136 loops
      
      avg: 110 - 150us
      
      HS:
      |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xaca6f002, len=1514 is_tx=1
      |cppi41_dma_callback() 0 loops
      |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f802, len=1514 is_tx=1
      |cppi41_dma_callback() 2 loops
      |musb-hdrc musb-hdrc.0.auto: configure ep1/80 packet_sz=512, mode=0, dma_addr=0xadd6f002, len=1514 is_tx=1
      |cppi41_dma_callback() 13 loops
      
      avg: 2us
      
      for the same test case. One loop means a udelay(1). The delay seems to
      depend on the packet size. On HS the bit is always cleared for small
      packet sizes while on FS it is never the case, it mostly around 110us.
      This testing has been performed with g_ether (musb as device) and using BULK
      transfers.
      
      INTR transfers are way more fun: during init the gadget sends a INT
      packet to the host and cppi41 says "transfer done" shortly after. The
      MUSB_TXCSR_TXPKTRDY bit is set even seconds later. The reason is that the host
      did not try to receive it, it does so after the interface (on host side) has
      been configured. Until this happens, that packet remains in musb's FIFO.
      
      To fix this, two things are done:
      - No DMA transfers for INT based endpoints. These transfer are usually
        very small and rare so it is likely better to skip the DMA engine and
        stuff the four bytes directly into the FIFO
      - on HS we poll up to 25us and hope that bit goes away. If not we setup
        a hrtimer to poll for it. The 140us delay is a rule of thumb. In FS
        the command
        | ping 10.10.10.10 -c1 -s65130
        creates about 44 1514bytes transfers. About 19 of them need a second
        timer to complete.
      Reported-by: NBin Liu <b-liu@ti.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      a655f481
    • S
      usb: musb: musb_cppi41: factor most of cppi41_dma_callback() into cppi41_trans_done() · d373a853
      Sebastian Andrzej Siewior 提交于
      This patch moves most of the logic in cppi41_dma_callback() into
      cppi41_trans_done() where it can be called from another function.
      Instead of computing "transferred" (the number of bytes transferred in
      the last transaction) in cppi41_trans_done() the member
      "cppi41_channel->prog_len" is now set to 0 if the transfer as a whole
      can be considered as done. If it is != 0 then the next iteration is
      assumed.
      This is a preparation for a workaround.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      d373a853
    • H
      usb: phy: generic: fix a compiler warning · 37cfbc42
      Heikki Krogerus 提交于
      Just because it annoys me.
      Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      37cfbc42
    • A
      usb: phy-generic: fix nop xceiv probe · dc52c574
      Aaro Koskinen 提交于
      Commit bd27fa44 (usb: phy: generic:
      Don't use regulator framework for RESET line) introduced regression: All
      users of usb_nop_xceiv_register() will fail because there is no platform
      data and the default reset GPIO is 0 which is a valid GPIO. Fix that.
      Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
      Acked-by: NRoger Quadros <rogerq@ti.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      dc52c574
    • A
      usb: fix musb gadget to enable OTG mode conditionally · fd3923a9
      Apelete Seketeli 提交于
      The musb driver is usable in host, gadget or dual role mode depending
      on the kernel configuration.
      
      However, the musb gadget part of the driver is enabling OTG mode
      whether the driver is built for dual role or gadget only mode. This
      induces a bug for gadget only USB device controllers where the kernel
      tries to use Host Negotiation Protocol with such controllers, which
      causes a panic.
      
      This behaviour is now fixed by enabling OTG mode only when musb driver
      is built for dual role mode.
      Signed-off-by: NApelete Seketeli <apelete@seketeli.net>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      fd3923a9
    • L
      usb: gadget: fix pxa25x compilation problems · b144e4ab
      Linus Walleij 提交于
      In commit
      88f718e3
      "ARM: pxa: delete the custom GPIO header"
      we removed the implicit inclusion of <mach/gpio.h>
      from <linux/gpio.h>.
      
      The pxa25x_udc was not using that, but it was relying
      on <linux/gpio.h> to implictly include <mach/gpio.h>
      which in turn implicitly included <mach/hardware.h>,
      which was needed for the driver to compile.
      
      Fix this up by explicitly including the necessary
      <mach/hardware.h> header.
      Reported-by: NRussell King <linux@arm.linux.org.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      b144e4ab
    • R
      usb: gadget: s3c-hsotg: fix disconnect handling · d18f7116
      Robert Baldyga 提交于
      This patch moves s3c_hsotg_disconnect function call from USBSusp interrupt
      handler to SET_ADDRESS request handler.
      
      It's because disconnected state can't be detected directly, because this
      hardware doesn't support Disconnected interrupt for device mode. For both
      Suspend and Disconnect events there is one interrupt USBSusp, but calling
      s3c_hsotg_disconnect from this interrupt handler causes config reset in
      composite layer, which is not undesirable for Suspended state.
      
      For this reason s3c_hsotg_disconnect is called from SET_ADDRESS request
      handler, which occurs always after disconnection, so we do disconnect
      immediately before we are connected again. It's probably only way we
      can do handle disconnection correctly.
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      d18f7116
    • R
      usb: gadget: s3c-hsotg: fix spinlock locking · 93f599f2
      Robert Baldyga 提交于
      This patch adds missing spinlock locking in s3c_hsotg_complete_setup function,
      and unlocking for gadget setup call.
      Signed-off-by: NRobert Baldyga <r.baldyga@samsung.com>
      Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      93f599f2
    • F
      usb: phy: generic: fix how we find out about our resources · af9f51c5
      Felipe Balbi 提交于
      instead of having each user of generic phy find
      out about its own resources and pass it to the
      core layer, have th core layer itself figure that
      out. It's as simple as moving a piece of code
      around. This fixes a big regression caused during
      the merge window where am335x-based platforms
      wouldn't be able to probe their PHY driver.
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      af9f51c5
    • M
      usb: phy: remove dead code · 39189c98
      Michal Nazarewicz 提交于
      Commit [4d175f34: usb: phy: nop: Defer clock prepare until PHY init]
      removed a goto reaching behind a “return ret” at the end of the function
      thus removing the only possible way that statement could be reached, and
      so rendering it a dead code.  This commit cleans it up by removing said
      dead code.
      Signed-off-by: NMichal Nazarewicz <mina86@mina86.com>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      39189c98
  2. 22 11月, 2013 3 次提交
  3. 21 11月, 2013 22 次提交
  4. 20 11月, 2013 3 次提交
    • D
      drm/i915: Fix gen3 self-refresh watermarks · f727b490
      Daniel Vetter 提交于
      This regression has been introduced in
      
      commit 4fe8590a
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Wed Sep 4 18:25:22 2013 +0300
      
          drm/i915: Use adjusted_mode appropriately when computing watermarks
      
      I guess we should renable the enabled local variable into something a
      notch more descriptive, but that's something for -next.
      
      The effect on my i945gme netbook is pretty severe amounts of underruns
      - usually the very first pixel gets used for the entire screeen.
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f727b490
    • T
      drm/ttm: Remove set_need_resched from the ttm fault handler · c58f009e
      Thomas Hellstrom 提交于
      Addresses
      "[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE".
      
      In the first occurence it was used to try to be nice while releasing the
      mmap_sem and retrying the fault to work around a locking inversion.
      The second occurence was never used.
      
      There has been some discussion whether we should change the locking order to
      mmap_sem -> bo_reserve. This patch doesn't address that issue, and leaves
      that locking order undefined. The solution that we release the mmap_sem if
      tryreserve fails and wait for the buffer to become unreserved is something
      we want in any case, and follows how the core vm system waits for pages
      to be come unlocked while releasing the mmap_sem.
      
      The code also outlines what needs to be changed if we want to establish the
      locking order as mmap_sem -> bo::reserve.
      
      One slight issue that remains with this code is that the fault handler might
      be prone to starvation if another thread countinously reserves the buffer.
      IMO that usage pattern is highly unlikely.
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      c58f009e
    • T
      drm/ttm: Don't move non-existing data · 0bc25425
      Thomas Hellstrom 提交于
      If ttm_bo_move_memcpy was instructed to move a non-populated ttm to
      io memory, it would first populate the ttm, then move the data and then
      destroy the ttm. That's stupid. However, some drivers might have relied on
      this to clear io memory from old stuff. So instead of a NOP, which would
      be the most efficient, just clear the destination.
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>
      0bc25425