1. 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
  2. 31 5月, 2015 1 次提交
  3. 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
  4. 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
  5. 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
  6. 07 3月, 2015 1 次提交
  7. 03 3月, 2015 1 次提交
  8. 28 2月, 2015 1 次提交
  9. 05 2月, 2015 1 次提交
  10. 24 12月, 2014 1 次提交
  11. 22 12月, 2014 1 次提交
  12. 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
  13. 25 11月, 2014 1 次提交
  14. 18 9月, 2014 1 次提交
  15. 05 9月, 2014 1 次提交
  16. 13 8月, 2014 1 次提交
  17. 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
  18. 23 6月, 2014 1 次提交
  19. 02 6月, 2014 1 次提交
  20. 27 4月, 2014 1 次提交
  21. 15 4月, 2014 1 次提交
  22. 29 3月, 2014 1 次提交
  23. 19 2月, 2014 1 次提交
  24. 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
  25. 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
  26. 28 1月, 2014 2 次提交
  27. 22 1月, 2014 2 次提交
  28. 13 1月, 2014 2 次提交
  29. 08 1月, 2014 1 次提交
  30. 17 12月, 2013 1 次提交
  31. 12 12月, 2013 1 次提交
  32. 12 10月, 2013 2 次提交
    • M
      spi: Provide common spi_message processing loop · b158935f
      Mark Brown 提交于
      The loops which SPI controller drivers use to process the list of transfers
      in a spi_message are typically very similar and have some error prone areas
      such as the handling of /CS. Help simplify drivers by factoring this code
      out into the core - if drivers provide a transfer_one() function instead
      of a transfer_one_message() function the core will handle processing at the
      message level.
      
      /CS can be controlled by either setting cs_gpio or providing a set_cs
      function. If this is not possible for hardware reasons then both can be
      omitted and the driver should continue to implement manual /CS handling.
      
      This is a first step in refactoring and it is expected that there will be
      further enhancements, for example factoring out of the mapping of transfers
      for DMA and the initiation and completion of interrupt driven transfers.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      b158935f
    • M
      spi: Provide per-message prepare and unprepare operations · 2841a5fc
      Mark Brown 提交于
      Many SPI drivers perform setup and tear down on every message, usually
      doing things like DMA mapping the message. Provide hooks for them to use
      to provide such operations.
      
      This is of limited value for drivers that implement transfer_one_message()
      but will be of much greater utility with future factoring out of standard
      implementations of that function.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      2841a5fc
  33. 03 10月, 2013 1 次提交
    • L
      spi: Add a spi_w8r16be() helper · 05071aa8
      Lars-Peter Clausen 提交于
      This patch adds a new spi_w8r16be() helper, which is similar to spi_w8r16()
      except that it converts the read data word from big endian to native endianness
      before returning it. The reason for introducing this new helper is that for SPI
      slave devices it is quite common that the read 16 bit data word is in big
      endian. So users of spi_w8r16() have to convert the result to native endianness
      manually. A second reason is that in this case the endianness of the return
      value of spi_w8r16() depends on its sign. If it is negative (i.e. a error code)
      it is already in native endianness, if it is positive it is in big endian. The
      sparse code checker doesn't like this kind of mixed endianness and special
      annotations are necessary to keep it quiet (E.g. casting to be16 using __force).
      Doing the conversion to native endianness in the helper function does not
      require such annotations since we are not mixing different endiannesses in the
      same variable.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      05071aa8
  34. 17 9月, 2013 2 次提交
反馈
建议
客服 返回
顶部