1. 16 6月, 2011 1 次提交
  2. 02 6月, 2011 1 次提交
  3. 31 5月, 2011 1 次提交
    • P
      dmaengine: shdma: Fix up fallout from runtime PM changes. · 5c2de444
      Paul Mundt 提交于
      The runtime PM changes introduce sh_dmae_rst() wrapping via the
      runtime_resume helper, depending on dev_get_drvdata() to fetch the
      platform data needed for the DMAOR initialization default at a time
      where drvdata hasn't yet been established by the probe path, resulting
      in general probe misery:
      
              Unable to handle kernel NULL pointer dereference at virtual address 000000c4
              pc = 8025adee
              *pde = 00000000
              Oops: 0000 [#1]
              Modules linked in:
      
              Pid : 1, Comm:           swapper
              CPU : 0                  Not tainted  (3.0.0-rc1-00012-g9436b4ab-dirty #1456)
      
              PC is at sh_dmae_rst+0x28/0x86
              PR is at sh_dmae_rst+0x22/0x86
              PC  : 8025adee SP  : 9e803d10 SR  : 400080f1 TEA : 000000c4
              R0  : 000000c4 R1  : 0000fff8 R2  : 00000000 R3  : 00000040
              R4  : 000000f0 R5  : 00000000 R6  : 00000000 R7  : 804f184c
              R8  : 00000000 R9  : 804dd0e8 R10 : 80283204 R11 : ffffffda
              R12 : 000000a0 R13 : 804dd18c R14 : 9e803d10
              MACH: 00000000 MACL: 00008f20 GBR : 00000000 PR  : 8025ade8
      
              Call trace:
              [<8025ae70>] sh_dmae_runtime_resume+0x24/0x34
              [<80283238>] pm_generic_runtime_resume+0x34/0x3c
              [<80283370>] rpm_callback+0x4a/0x7e
              [<80283efc>] rpm_resume+0x240/0x384
              [<80283f54>] rpm_resume+0x298/0x384
              [<8028428c>] __pm_runtime_resume+0x44/0x7c
              [<8038a358>] __ioremap_caller+0x0/0xec
              [<80284296>] __pm_runtime_resume+0x4e/0x7c
              [<8038a358>] __ioremap_caller+0x0/0xec
              [<80666254>] sh_dmae_probe+0x180/0x6a0
              [<802803ae>] platform_drv_probe+0x26/0x2e
      
      Fix up the ordering accordingly.
      Signed-off-by: NPaul Mundt <lethal@linux-sh.org>
      5c2de444
  4. 27 5月, 2011 3 次提交
  5. 25 5月, 2011 4 次提交
  6. 23 5月, 2011 4 次提交
  7. 19 5月, 2011 2 次提交
  8. 13 5月, 2011 5 次提交
  9. 12 5月, 2011 1 次提交
    • N
      dmaengine: at_hdmac: pause: no need to wait for FIFO empty · de7a2f9f
      Nicolas Ferre 提交于
      With the addition of the "pause" feature, an active wait was introduced
      to check the "FIFO empty" event. This event was not always happening and
      a timout contition was needed.
      But, in some cases, this event depend on the peripheral connected to the
      channel that is paused: FIFO becomes empty if the peripheral consumes data.
      The timeout is pretty difficult to evaluate. Moreover, this check is not
      needed.
      In conclusion, it seems sensible to entirely remove the checking of
      "FIFO empty" status when pausing.
      Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
      [commit msg edited for grammer]
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      de7a2f9f
  10. 09 5月, 2011 10 次提交
  11. 02 5月, 2011 5 次提交
  12. 26 4月, 2011 1 次提交
  13. 11 4月, 2011 1 次提交
  14. 06 4月, 2011 1 次提交