1. 18 9月, 2015 2 次提交
  2. 05 8月, 2015 2 次提交
  3. 04 8月, 2015 1 次提交
  4. 01 8月, 2015 1 次提交
    • J
      spi: pxa2xx: Add support for Intel Sunrisepoint · 34cadd9c
      Jarkko Nikula 提交于
      Major difference in LPSS SPI between Intel Sunrisepoint PCH and earlier
      platforms is an integrated DMA (iDMA) engine. iDMA is an IP that is private
      for each LPSS host controller (UART/SPI/I2C). Other differences are private
      register space offset, a few private registers that are in different
      location and FIFO thresholds.
      
      Intel Sunrisepoint LPSS SPI and iDMA devices are probed and registered in
      MFD layer as platform devices. Here these compound devices are detected by
      matching against known PCI IDs. This allows us to share
      pxa2xx_spi_acpi_get_pdata() for setting up the platform data instead of
      duplicating it in MFD part.
      
      This patch adds configuration for Intel Sunrisepoint LPSS SPI, above
      detection and DMA filter function that picks the DMA channel only from an
      associated iDMA block.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      34cadd9c
  5. 15 6月, 2015 1 次提交
  6. 05 6月, 2015 3 次提交
  7. 31 3月, 2015 1 次提交
  8. 25 3月, 2015 2 次提交
  9. 24 3月, 2015 1 次提交
  10. 28 1月, 2015 1 次提交
  11. 30 12月, 2014 1 次提交
    • M
      spi/pxa2xx: Clear cur_chip pointer before starting next message · c957e8f0
      Mika Westerberg 提交于
      Once the current message is finished, the driver notifies SPI core about
      this by calling spi_finalize_current_message(). This function queues next
      message to be transferred. If there are more messages in the queue, it is
      possible that the driver is asked to transfer the next message at this
      point.
      
      When spi_finalize_current_message() returns the driver clears the
      drv_data->cur_chip pointer to NULL. The problem is that if the driver
      already started the next message clearing drv_data->cur_chip will cause
      NULL pointer dereference which crashes the kernel like:
      
       BUG: unable to handle kernel NULL pointer dereference at 0000000000000048
       IP: [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
       PGD 78bb8067 PUD 37712067 PMD 0
       Oops: 0000 [#1] SMP
       Modules linked in:
       CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G           O   3.18.0-rc4-mjo #5
       Hardware name: Intel Corp. VALLEYVIEW B3 PLATFORM/NOTEBOOK, BIOS MNW2CRB1.X64.0071.R30.1408131301 08/13/2014
       task: ffff880077f9f290 ti: ffff88007a820000 task.ti: ffff88007a820000
       RIP: 0010:[<ffffffffa0022bc8>]  [<ffffffffa0022bc8>] cs_deassert+0x18/0x70 [spi_pxa2xx_platform]
       RSP: 0018:ffff88007a823d08  EFLAGS: 00010202
       RAX: 0000000000000008 RBX: ffff8800379a4430 RCX: 0000000000000026
       RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800379a4430
       RBP: ffff88007a823d18 R08: 00000000ffffffff R09: 000000007a9bc65a
       R10: 000000000000028f R11: 0000000000000005 R12: ffff880070123e98
       R13: ffff880070123de8 R14: 0000000000000100 R15: ffffc90004888000
       FS:  0000000000000000(0000) GS:ffff880079a80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: 0000000000000048 CR3: 000000007029b000 CR4: 00000000001007e0
       Stack:
        ffff88007a823d58 ffff8800379a4430 ffff88007a823d48 ffffffffa0022c89
        0000000000000000 ffff8800379a4430 0000000000000000 0000000000000006
        ffff88007a823da8 ffffffffa0023be0 ffff88007a823dd8 ffffffff81076204
       Call Trace:
        [<ffffffffa0022c89>] giveback+0x69/0xa0 [spi_pxa2xx_platform]
        [<ffffffffa0023be0>] pump_transfers+0x710/0x740 [spi_pxa2xx_platform]
        [<ffffffff81076204>] ? pick_next_task_fair+0x744/0x830
        [<ffffffff81049679>] tasklet_action+0xa9/0xe0
        [<ffffffff81049a0e>] __do_softirq+0xee/0x280
        [<ffffffff81049bc0>] run_ksoftirqd+0x20/0x40
        [<ffffffff810646df>] smpboot_thread_fn+0xff/0x1b0
        [<ffffffff810645e0>] ? SyS_setgroups+0x150/0x150
        [<ffffffff81060f9d>] kthread+0xcd/0xf0
        [<ffffffff81060ed0>] ? kthread_create_on_node+0x180/0x180
        [<ffffffff8187a82c>] ret_from_fork+0x7c/0xb0
      
      Fix this by clearing drv_data->cur_chip before we call spi_finalize_current_message().
      Reported-by: NMartin Oldfield <m@mjoldfield.com>
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      c957e8f0
  12. 23 12月, 2014 3 次提交
  13. 22 12月, 2014 1 次提交
  14. 13 12月, 2014 1 次提交
  15. 27 11月, 2014 1 次提交
  16. 25 11月, 2014 1 次提交
  17. 06 11月, 2014 1 次提交
    • D
      spi: pxa2xx: toggle clocks on suspend if not disabled by runtime PM · 2b9375b9
      Dmitry Eremin-Solenikov 提交于
      If PM_RUNTIME is enabled, it is easy to trigger the following backtrace
      on pxa2xx hosts:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8()
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104
      [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14)
      [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c)
      [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24)
      [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8)
      [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34)
      [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54)
      [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74)
      [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8)
      [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208)
      [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0)
      [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8)
      [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc)
      [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc)
      [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4)
      [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec)
      [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24)
      ---[ end trace 46524156d8faa4f6 ]---
      
      This happens because suspend function tries to disable a clock that is
      already disabled by runtime_suspend callback. Add if
      (!pm_runtime_suspended()) checks to suspend/resume path.
      
      Fixes: 7d94a505 (spi/pxa2xx: add support for runtime PM)
      Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Reported-by: NAndrea Adami <andrea.adami@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      2b9375b9
  18. 20 10月, 2014 1 次提交
  19. 18 9月, 2014 1 次提交
  20. 20 8月, 2014 1 次提交
  21. 17 6月, 2014 1 次提交
  22. 01 6月, 2014 1 次提交
  23. 30 4月, 2014 1 次提交
  24. 15 4月, 2014 1 次提交
  25. 23 2月, 2014 1 次提交
  26. 16 1月, 2014 1 次提交
  27. 13 1月, 2014 1 次提交
  28. 28 11月, 2013 1 次提交
  29. 24 11月, 2013 1 次提交
  30. 17 10月, 2013 1 次提交
  31. 26 9月, 2013 1 次提交
  32. 05 9月, 2013 1 次提交
    • M
      spi/pxa2xx: check status register as well to determine if the device is off · 269e4a41
      Mika Westerberg 提交于
      The current interrupt handler calls pm_runtime_suspended() to check if the
      device is suspended or not. However, runtime PM status of the device is
      only set to suspended once all PM runtime suspend hooks have executed.
      
      In case of Intel Lynxpoint we have the device bound to the ACPI power
      domain and its runtime suspend hook will put the device to D3hot (or D3cold
      if possible). This means that the device is powered off before its state is
      set to runtime suspended. While in this state the device might get an
      interrupt that is meant for another device (as the interrupt line is
      shared), and because the device is powered off accessing its registers will
      return 0xffffffff that the driver misinterprets as an invalid state.
      
      When this happens user will see messages like below on the console:
      
        pxa2xx-spi INT33C0:00: bad message state in interrupt handler
      
      Fix this by checking the status register for ~0 and returning IRQ_NONE in
      that case.
      Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      269e4a41
  33. 30 7月, 2013 1 次提交