Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 06 1月, 2016 1 次提交
  3. 13 12月, 2015 1 次提交
    • M
      spi: add spi_message_init_no_memset to avoid zeroing the spi_message · 49ddedf3
      由 Martin Sperl 提交于 
      In the spi_loopback_test driver there is the need to initialize
a spi_message that is filled with values from a static structure.

Applying spi_message_init to such a prefilled structure results in
all the settings getting reset to zero, which is not what we want.
Copying each field of spi_message separately instead always includes
the risk that some new fields have not been implemented in the copying
code.

So here we introduce a version of spi_message_init called
spi_message_init_no_memset that does not fill the structure
with zero first, but only initializes the relevant list_heads.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      49ddedf3
  5. 02 12月, 2015 1 次提交
  7. 28 10月, 2015 1 次提交
  9. 24 10月, 2015 1 次提交
  11. 21 9月, 2015 1 次提交
  13. 20 9月, 2015 1 次提交
  15. 17 9月, 2015 2 次提交
    • N
      spi: bitbang: Replace spinlock by mutex · c15f6ed3
      由 Nicolas Boichat 提交于 
      chipselect (in the case of spi-gpio: spi_gpio_chipselect, which
calls gpiod_set_raw_value_cansleep) can sleep, so we should not
hold a spinlock while calling it from spi_bitbang_setup.

This issue was introduced by this commit, which converted spi-gpio
to cansleep variants:
d9dda5a1 "spi: spi-gpio: Use 'cansleep' variants to access GPIO"

Replacing the lock variable by a mutex fixes the issue: This is
safe as all instances where the lock is used are called from
contexts that can sleep.

Finally, update spi-ppc4xx and and spi-s3c24xx to use mutex
functions, as they directly hold the lock for similar purpose.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      c15f6ed3
    • G
      spi: fix kernel-doc warnings in spi.h · 0243ed44
      由 Geliang Tang 提交于 
      Fix the following 'make htmldocs' warnings:

  .//include/linux/spi/spi.h:71: warning: No description found for parameter 'lock'
  .//include/linux/spi/spi.h:71: warning: Excess struct/union/enum/typedef member 'clock' description in 'spi_statistics'
Signed-off-by: NGeliang Tang <geliangtang@163.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      0243ed44
  17. 07 7月, 2015 1 次提交
    • M
      spi: expose spi_master and spi_device statistics via sysfs · eca2ebc7
      由 Martin Sperl 提交于 
      per spi-master statistics accessible as:
  /sys/class/spi_master/spi*/statistics/*

per spi-device statistics accessible via:
  /sys/class/spi_master/spi*/spi*.*/statistics/*

The following statistics are exposed as separate "files" inside
these directories:
* messages              number of spi_messages
* transfers             number of spi_transfers
* bytes                 number of bytes transferred
* bytes_rx              number of bytes transmitted
* bytes_tx              number of bytes received
* errors                number of errors encounterd
* timedout              number of messages that have timed out
* spi_async             number of spi_messages submitted using spi_async
* spi_sync              number of spi_messages submitted using spi_sync
* spi_sync_immediate    number of spi_messages submitted using spi_sync,
                        that are handled immediately without a context switch
                        to the spi_pump worker-thread
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      eca2ebc7
  19. 31 5月, 2015 1 次提交
  21. 08 4月, 2015 1 次提交
    • G
      spi: Make master->handle_err() callback optional to avoid crashes · ff61eb42
      由 Geert Uytterhoeven 提交于 
      If a driver doesn't implement the master->handle_err() callback and an
SPI transfer fails, the kernel will crash with a NULL pointer
dereference:

    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c0003000
    [00000000] *pgd=80000040004003, *pmd=00000000
    Internal error: Oops: 80000206 [#1] SMP ARM
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc7-koelsch-05861-g1fc9fdd4add4f783 #1046
    Hardware name: Generic R8A7791 (Flattened Device Tree)
    task: eec359c0 ti: eec54000 task.ti: eec54000
    PC is at 0x0
    LR is at spi_transfer_one_message+0x1cc/0x1f0

Make the master->handle_err() callback optional to avoid the crash.

Also fix a spelling mistake in the callback documentation while we're at
it.

Fixes: b716c4ff ("spi: introduce master->handle_err() callback")
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      ff61eb42
  23. 19 3月, 2015 1 次提交
    • B
      cc2520: Add support for CC2591 amplifier. · f0b7d43c
      由 Brad Campbell 提交于 
      The TI CC2521 is an RF power amplifier that is designed to interface
with the CC2520. Conveniently, it directly interfaces with the CC2520
and does not require any pins to be connected to a
microcontroller/processor. Adding a CC2591 increases the CC2520's range,
which is useful for border router and other wall-powered applications.

Using the CC2591 with the CC2520 requires configuring the CC2520 GPIOs
that are connected to the CC2591 to correctly set the CC2591 into TX and
RX modes. Further, TI recommends that the CC2520_TXPOWER and
CC2520_AGCCTRL1 registers are set differently to maximize the CC2591's
performance. These settings are covered in TI Application Note AN065.

This patch adds an optional `amplified` field to the cc2520 entry in the
device tree. If present, the CC2520 will be configured to operate with a
CC2591.

The expected pin mapping is:
CC2520 GPIO0 --> CC2591 EN
CC2520 GPIO5 --> CC2591 PAEN
Signed-off-by: NBrad Campbell <bradjc5@gmail.com>
Acked-by: NVarka Bhadram <varkabhadram@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f0b7d43c
  25. 09 3月, 2015 1 次提交
    • L
      spi: Remove support for legacy PM · ea022bbb
      由 Lars-Peter Clausen 提交于 
      All SPI drivers have been converted from legacy suspend/resume callbacks to
dev_pm_ops. So we can finally remove support for legacy PM from the SPI
core.

Since there aren't any special bus specific things to do during
suspend/resume and since the PM core will automatically fallback directly to
using the device's PM ops if no bus PM ops are specified there is no need to
have any special SPI bus PM ops.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      ea022bbb
  27. 07 3月, 2015 1 次提交
  29. 03 3月, 2015 1 次提交
  31. 28 2月, 2015 1 次提交
  33. 05 2月, 2015 1 次提交
  35. 24 12月, 2014 1 次提交
  37. 22 12月, 2014 1 次提交
  39. 11 12月, 2014 1 次提交
    • M
      spi: Pump transfers inside calling context for spi_sync() · 0461a414
      由 Mark Brown 提交于 
      If we are using the standard SPI message pump (which all drivers should be
transitioning over to) then special case the message enqueue and instead of
starting the worker thread to push messages to the hardware do so in the
context of the caller if the controller is idle. This avoids a context
switch in the common case where the controller has a single user in a
single thread, for short PIO transfers there may be no need to context
switch away from the calling context to complete the transfer.

The code is a bit more complex than is desirable in part due to the need
to handle drivers not using the standard queue and in part due to handling
the various combinations of bus locking and asynchronous submission in
interrupt context.

It is still suboptimal since it will still wake the message pump for each
transfer in order to schedule idling of the hardware and if multiple
contexts are using the controller simultaneously a caller may end up
pumping a message for some random other thread rather than for itself,
and if the thread ends up deferring due to another context idling the
hardware then it will just busy wait.  It can, however, have the benefit
of aggregating power up and down of the hardware when a caller performs
a series of transfers back to back without any need for the use of
spi_async().
Signed-off-by: NMark Brown <broonie@kernel.org>
      0461a414
  41. 25 11月, 2014 1 次提交
  43. 18 9月, 2014 1 次提交
  45. 05 9月, 2014 1 次提交
  47. 13 8月, 2014 1 次提交
  49. 01 7月, 2014 1 次提交
    • G
      spi: sh-msiof: Add DMA support · b0d0ce8b
      由 Geert Uytterhoeven 提交于 
      Add DMA support to the MSIOF driver using platform data.

As MSIOF DMA is limited to 32-bit words (requiring byte/wordswapping for
smaller wordsizes), and the group length is limited to 256 words, DMA is
performed on two fixed pages, allocated and mapped at driver initialization
time.

Performance figures (in Mbps) on r8a7791/koelsch at different SPI clock
frequencies for 1024-byte and 4096-byte transfers:

                   1024 bytes           4096 bytes
  -  3.25 MHz: PIO  2.1, DMA  2.6 | PIO  2.8, DMA  3.1
  -  6.5  MHz: PIO  3.2, DMA  4.4 | PIO  5.0, DMA  5.9
  - 13    MHz: PIO  4.2, DMA  6.6 | PIO  8.2, DMA 10.7
  - 26    MHz: PIO  5.9, DMA 10.4 | PIO 12.4, DMA 18.4

Note that DMA is only faster than PIO for transfers that exceed the FIFO
size (typically 64 words / 256 bytes).

Also note that large transfers (larger than the group length for DMA, or
larger than the FIFO size for PIO), should use cs-gpio (with the
appropriate pinmux setup), as the hardware chipselect will be deasserted in
between chunks.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@linaro.org>
      b0d0ce8b
  51. 23 6月, 2014 1 次提交
  53. 02 6月, 2014 1 次提交
  55. 27 4月, 2014 1 次提交
  57. 15 4月, 2014 1 次提交
  59. 29 3月, 2014 1 次提交
  61. 19 2月, 2014 1 次提交
  63. 05 2月, 2014 2 次提交
    • M
      spi: Make core DMA mapping functions generate scatterlists · 6ad45a27
      由 Mark Brown 提交于 
      We cannot unconditionally use dma_map_single() to map data for use with
SPI since transfers may exceed a page and virtual addresses may not be
provided with physically contiguous pages. Further, addresses allocated
using vmalloc() need to be mapped differently to other addresses.

Currently only the MXS driver handles all this, a few drivers do handle
the possibility that buffers may not be physically contiguous which is
the main potential problem but many don't even do that. Factoring this
out into the core will make it easier for drivers to do a good job so if
the driver is using the core DMA code then generate a scatterlist
instead of mapping to a single address so do that.

This code is mainly based on a combination of the existing code in the MXS
and PXA2xx drivers. In future we should be able to extend it to allow the
core to concatenate adjacent transfers if they are compatible, improving
performance.

Currently for simplicity clients are not allowed to use the scatterlist
when they do DMA mapping, in the future the existing single address
mappings will be replaced with use of the scatterlist most likely as
part of pre-verifying transfers.

This change makes it mandatory to use scatterlists when using the core DMA
mapping so update the s3c64xx driver to do this when used with dmaengine.
Doing so makes the code more ugly but it is expected that the old s3c-dma
code can be removed very soon.
Signed-off-by: NMark Brown <broonie@linaro.org>
      6ad45a27
    • M
      spi: Provide core support for full duplex devices · 3a2eba9b
      由 Mark Brown 提交于 
      It is fairly common for SPI devices to require that one or both transfer
directions is always active. Currently drivers open code this in various
ways with varying degrees of efficiency. Start factoring this out by
providing flags SPI_MASTER_MUST_TX and SPI_MASTER_MUST_RX. These will cause
the core to provide buffers for the requested direction if none are
specified in the underlying transfer.

Currently this is fairly inefficient since we actually allocate a data
buffer which may get large, support for mapping transfers using a
scatterlist will allow us to avoid this for DMA based transfers.
Signed-off-by: NMark Brown <broonie@linaro.org>
      3a2eba9b
  65. 03 2月, 2014 1 次提交
    • M
      spi: Provide core support for DMA mapping transfers · 99adef31
      由 Mark Brown 提交于 
      The process of DMA mapping buffers for SPI transfers does not vary between
devices so in order to save duplication of code in drivers this can be
factored out into the core, allowing it to be integrated with the work that
is being done on factoring out the common elements from the data path
including more sharing of dmaengine code.

In order to use this masters need to provide a can_dma() operation and while
the hardware is prepared they should ensure that DMA channels are provided
in tx_dma and rx_dma. The core will then ensure that the buffers are mapped
for DMA prior to calling transfer_one_message().

Currently the cleanup on error is not complete, this needs to be improved.
Signed-off-by: NMark Brown <broonie@linaro.org>
      99adef31
  67. 28 1月, 2014 2 次提交
  69. 22 1月, 2014 2 次提交
  71. 13 1月, 2014 1 次提交