Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 24 2月, 2016 1 次提交
    • S
      spi: imx: drop fallback to PIO · 99f1cf1c
      由 Sascha Hauer 提交于 
      At the moment the driver decides to fallback to PIO mode the buffers
are already mapped for DMA. It's a bug to access them with the CPU
afterwards, so we cannot just fallback to PIO mode.
It should not be necessary anyway, since we only use DMA when we
verified that it's possible in the fist place, so when prep_slave_sg
fails it's a bug, either in the SDMA driver or in the can_dma
implementation.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      99f1cf1c
  3. 19 2月, 2016 1 次提交
  5. 17 2月, 2016 2 次提交
    • S
      spi: imx: use proper dev_* functions for driver messages · 6aa800ca
      由 Sascha Hauer 提交于 
      Add a struct device * member to the private driver data and use
it to print messages using dev_* functions rather than pr_*.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      6aa800ca
    • A
      spi: imx: allow only WML aligned transfers to use DMA · 390f0ffe
      由 Anton Bondarenko 提交于 
      RX DMA tail data handling doesn't work correctly in many cases with current
implementation. It happens because SPI core was setup to generates both RX
and RX TAIL events. And RX TAIL event does not work correctly.
This can be easily verified by sending SPI transaction with size modulus
WML(32 in our case) not equal 0.

Also removing change introduced in f6ee9b58
since this change only fix usecases with transfer size from 33 to 128 bytes
and doesn't fix 129 bytes and bigger.

This is output from transaction with len 138 bytes in loopback mode at 10Mhz:
TX0000: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
TX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
TX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
TX0030: 5f 3c 35 b5 c4 8c dd 6c 11 32 3d e2 b4 b4 59 cf
TX0040: ce 23 3d 27 df a7 f9 96 fc 1e e0 66 2c 0e 7b 8c
TX0050: ca 30 42 8f bc 9f 7b ce d1 b8 b1 87 ec 8a d6 bb
TX0060: 2e 15 63 0e 3c dc a4 3a 7a 06 20 a7 93 1b 34 dd
TX0070: 4c f5 ec 88 96 68 d6 68 a0 09 6f 8e 93 47 c9 41
TX0080: db ac cf 97 89 f3 51 05 79 71

RX0000: a3 97 a2 55 53 be f1 fc f9 79 6b 52 14 13 e9 e2
RX0010: 2d 51 8e 1f 56 08 57 27 a7 05 d4 d0 52 82 77 75
RX0020: 1b 99 4a ed 58 3d 6a 52 36 d5 24 4a 68 8e ad 95
RX0030: 5f 3c 35 00 00 b5 00 00 00 c4 00 00 8c 00 00 dd
RX0040: 6c 11 32 3d e2 b4 b4 59 cf ce 23 3d 27 df a7 f9
RX0050: 96 fc 1e e0 66 2c 0e 7b 8c ca 30 42 8f 1f 1f bc
RX0060: 9f 7b ce d1 b8 b1 87 ec 8a d6 bb 2e 15 63 0e ed
RX0070: ed 3c 58 58 58 dc 3d 3d a4 6a 6a 3a 52 52 7a 36
RX0080: 06 20 a7 93 1b 34 dd 4c f5 ec

Zeros at offset 33 and 34 caused by reading empty RX FIFO which not possible
if DMA RX read was triggered by RX event. This mean DMA was triggered
by RX TAIL event.
Signed-off-by: NAnton Bondarenko <anton.bondarenko.sama@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      390f0ffe
  7. 13 2月, 2016 1 次提交
    • T
      spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit · 0e6f357a
      由 Tony Lindgren 提交于 
      Commit 5de85b9d ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind") introduced pm_runtime_reinit() that is used
to reinitialize PM runtime after -EPROBE_DEFER. This allows shutting
down the device after a failed probe.

However, for drivers using pm_runtime_use_autosuspend() this can cause
a state where suspend callback is never called after -EPROBE_DEFER.
On the following device driver probe, hardware state is different from
the PM runtime state causing omap_device to produce the following
error:

omap_device_enable() called from invalid state 1

And with omap_device and omap hardware being picky for PM, this will
block any deeper idle states in hardware.

The solution is to fix the drivers to follow the PM runtime documentation:

1. For sections of code that needs the device disabled, use
   pm_runtime_put_sync_suspend() if pm_runtime_set_autosuspend() has
   been set.

2. For driver exit code, use pm_runtime_dont_use_autosuspend() before
   pm_runtime_put_sync() if pm_runtime_use_autosuspend() has been
   set.

Fixes: 5de85b9d ("PM / runtime: Re-init runtime PM states at probe
error and driver unbind")
Cc: linux-spi@vger.kernel.org
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      0e6f357a
  9. 10 2月, 2016 1 次提交
  11. 29 1月, 2016 1 次提交
  13. 23 1月, 2016 2 次提交
  15. 16 1月, 2016 1 次提交
    • A
      spi: fix counting in spi-loopback-test code · ebea7c05
      由 Arnd Bergmann 提交于 
      These variables are always used uninitialized:

drivers/spi/spi-loopback-test.c: In function 'spi_test_run_iter':
drivers/spi/spi-loopback-test.c:768:17: warning: 'rx_count' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/spi/spi-loopback-test.c:762:17: warning: 'tx_count' may be used uninitialized in this function [-Wmaybe-uninitialized]

Adding an explicit initialization seems to be the only
workable solution here, to make the code behave correctly
and build without warning.

Fixes: 84e0c4e5 ("spi: add loopback test driver to allow for spi_master regression tests")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      ebea7c05
  17. 08 1月, 2016 1 次提交
  19. 07 1月, 2016 1 次提交
  21. 06 1月, 2016 4 次提交
  23. 05 1月, 2016 2 次提交
  25. 01 1月, 2016 3 次提交
  27. 31 12月, 2015 2 次提交
  29. 23 12月, 2015 3 次提交
  31. 16 12月, 2015 6 次提交
  33. 14 12月, 2015 3 次提交
  35. 13 12月, 2015 5 次提交