Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 8月, 2017 1 次提交
  3. 07 8月, 2017 1 次提交
  5. 26 7月, 2017 1 次提交
  7. 14 6月, 2017 1 次提交
    • G
      spi: Generalize SPI "master" to "controller" · 8caab75f
      由 Geert Uytterhoeven 提交于 
      Now struct spi_master is used for both SPI master and slave controllers,
it makes sense to rename it to struct spi_controller, and replace
"master" by "controller" where appropriate.

For now this conversion is done for SPI core infrastructure only.
Wrappers are provided for backwards compatibility, until all SPI drivers
have been converted.

Noteworthy details:
  - SPI_MASTER_GPIO_SS is retained, as it only makes sense for SPI
    master controllers,
  - spi_busnum_to_master() is retained, as it looks up masters only,
  - A new field spi_device.controller is added, but spi_device.master is
    retained for compatibility (both are always initialized by
    spi_alloc_device()),
  - spi_flash_read() is used by SPI masters only.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      8caab75f
  9. 26 5月, 2017 1 次提交
    • G
      spi: core: Add support for registering SPI slave controllers · 6c364062
      由 Geert Uytterhoeven 提交于 
      Add support for registering SPI slave controllers using the existing SPI
master framework:
  - SPI slave controllers must use spi_alloc_slave() instead of
    spi_alloc_master(), and should provide an additional callback
    "slave_abort" to abort an ongoing SPI transfer request,
  - SPI slave controllers are added to a new "spi_slave" device class,
  - SPI slave handlers can be bound to the SPI slave device represented
    by an SPI slave controller using a DT child node named "slave",
  - Alternatively, (un)binding an SPI slave handler to the SPI slave
    device represented by an SPI slave controller can be done by
    (un)registering the slave device through a sysfs virtual file named
    "slave".

From the point of view of an SPI slave protocol handler, an SPI slave
controller looks almost like an ordinary SPI master controller. The only
exception is that a transfer request will block on the remote SPI
master, and may be cancelled using spi_slave_abort().
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>
      6c364062
  11. 14 5月, 2017 2 次提交
  13. 22 4月, 2017 1 次提交
  15. 19 4月, 2017 1 次提交
    • H
      spi: double time out tolerance · 833bfade
      由 Hauke Mehrtens 提交于 
      The generic SPI code calculates how long the issued transfer would take
and adds 100ms in addition to the timeout as tolerance. On my 500 MHz
Lantiq Mips SoC I am getting timeouts from the SPI like this when the
system boots up:

m25p80 spi32766.4: SPI transfer timed out
blk_update_request: I/O error, dev mtdblock3, sector 2
SQUASHFS error: squashfs_read_data failed to read block 0x6e

After increasing the tolerance for the timeout to 200ms I haven't seen
these SPI transfer time outs any more.
The Lantiq SPI driver in use here has an extra work queue in between,
which gets triggered when the controller send the last word and the
hardware FIFOs used for reading and writing are only 8 words long.
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NMark Brown <broonie@kernel.org>
      833bfade
  17. 06 3月, 2017 2 次提交
  19. 02 3月, 2017 1 次提交
  21. 07 2月, 2017 1 次提交
  23. 01 2月, 2017 2 次提交
    • J
      spi: fix device-node leaks · 8324147f
      由 Johan Hovold 提交于 
      Make sure to release the device-node reference taken in
of_register_spi_device() on errors and when deregistering the device.

Fixes: 284b0189 ("spi: Add OF binding support for SPI busses")
Signed-off-by: NJohan Hovold <johan@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      8324147f
    • D
      spi: When no dma_chan map buffers with spi_master's parent · 88b0aa54
      由 Daniel Kurtz 提交于 
      Back before commit 1dccb598 ("arm64: simplify dma_get_ops"), for
arm64, devices for which dma_ops were not explicitly set were automatically
configured to use swiotlb_dma_ops, since this was hard-coded as the
global "dma_ops" in arm64_dma_init().

Now that global "dma_ops" has been removed, all devices much have their
dma_ops explicitly set by a call to arch_setup_dma_ops(), otherwise the
device is assigned dummy_dma_ops, and thus calls to map_sg for such a
device will fail (return 0).

Mediatek SPI uses DMA but does not use a dma channel.  Support for this
was added by commit c37f45b5 ("spi: support spi without dma channel
to use can_dma()"), which uses the master_spi dev to DMA map buffers.

The master_spi device is not a platform device, rather it is created
in spi_alloc_device(), and therefore its dma_ops are never set.

Therefore, when the mediatek SPI driver when it does DMA (for large SPI
transactions > 32 bytes), SPI will use spi_map_buf()->dma_map_sg() to
map the buffer for use in DMA.  But dma_map_sg()->dma_map_sg_attrs() returns
0, because ops->map_sg is dummy_dma_ops->__dummy_map_sg, and hence
spi_map_buf() returns -ENOMEM (-12).

Fix this by using the real spi_master's parent device which should be a
real physical device with DMA properties.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Fixes: c37f45b5 ("spi: support spi without dma channel to use can_dma()")
Cc: Leilk Liu <leilk.liu@mediatek.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      88b0aa54
  25. 18 1月, 2017 1 次提交
  27. 16 12月, 2016 1 次提交
  29. 23 11月, 2016 1 次提交
    • J
      spi: use sg_next for walking through the allocated scatterlist table · 8dd4a016
      由 Juan Gutierrez 提交于 
      A null dereference or Oops exception might occurs when reading at once the
whole content of an spi-nor of big enough size that requires an scatterlist
table that does not fit into one single page.

The spi_map_buf function is ignoring the chained sg case by dereferenceing
the scatterlist elements in an array fashion. This wrongly assumes that
the allocation of the scatterlist elements are contiguous. This is true as
long as the scatterlist table fits within a PAGE_SIZE. However, for
allocation where the scatter table is bigger than that, the pages allocated
by sg_alloc might not be contigous.

The sg table can be properly walked by sg_next instead of using an array.
Signed-off-by: NJuan Gutierrez <juan.gutierrez@nxp.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      8dd4a016
  31. 26 10月, 2016 1 次提交
    • D
      spi: change post transfer udelay() to usleep_range() for long delays · 8244bd3a
      由 Daniel Kurtz 提交于 
      The spi_transfer parameter delay_usecs allows specifying a time to wait
after transferring a spi message.  This wait can be quite long - some
devices, such as some Chrome OS ECs, require as much as 2000 usecs after
a SPI transaction, before it can respond.

(cf: arch/arm64/boot/dts/nvidia/tegra132-norrin.dts:
   google,cros-ec-spi-msg-delay = <2000>
)

Blocking a CPU for 2 msecs in a busy loop like this doesn't seem very
friendly to other processes, so change the blocking delay to a sleep
to allow other things to use this CPU (or so it can sleep).

This should be safe to do, because:
 (a) A post-transaction delay like this is always specified as a minimum
     wait time
 (b) A delay here is most likely not very time sensitive, as it occurs
     after all data has been transferred
 (c) This delay occurs in a non-critical section of the spi worker thread
     so where it is safe to sleep.

Two caveats:
 1) To avoid penalizing short delays, still use udelay for delays < 10us.
 2) usleep_range() very often picks the upper bound, an upper bounds 10%
    should be plenty.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      8244bd3a
  33. 25 10月, 2016 1 次提交
  35. 21 10月, 2016 1 次提交
    • T
      spi: Add Flag to Enable Slave Select with GPIO Chip Select. · 8eee6b9d
      由 Thor Thayer 提交于 
      Some SPI masters require slave selection before the transfer
can begin [1]. The SPI framework currently selects the chip using
either 1) the internal CS mechanism or 2) the GPIO CS, but not both.

This patch adds a new master->flags define to indicate both the GPIO
CS and the internal chip select mechanism should be used.

Tested On:
    Altera CycloneV development kit
    Compile tested for build errors on x86_64 (allyesconfigs)

[1] DesignWare dw_apb_ssi Databook, Version 3.20a (page 39)
Signed-off-by: NThor Thayer <tthayer@opensource.altera.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      8eee6b9d
  37. 12 10月, 2016 1 次提交
    • P
      kthread: kthread worker API cleanup · 3989144f
      由 Petr Mladek 提交于 
      A good practice is to prefix the names of functions by the name
of the subsystem.

The kthread worker API is a mix of classic kthreads and workqueues.  Each
worker has a dedicated kthread.  It runs a generic function that process
queued works.  It is implemented as part of the kthread subsystem.

This patch renames the existing kthread worker API to use
the corresponding name from the workqueues API prefixed by
kthread_:

__init_kthread_worker()		-> __kthread_init_worker()
init_kthread_worker()		-> kthread_init_worker()
init_kthread_work()		-> kthread_init_work()
insert_kthread_work()		-> kthread_insert_work()
queue_kthread_work()		-> kthread_queue_work()
flush_kthread_work()		-> kthread_flush_work()
flush_kthread_worker()		-> kthread_flush_worker()

Note that the names of DEFINE_KTHREAD_WORK*() macros stay
as they are. It is common that the "DEFINE_" prefix has
precedence over the subsystem names.

Note that INIT() macros and init() functions use different
naming scheme. There is no good solution. There are several
reasons for this solution:

  + "init" in the function names stands for the verb "initialize"
    aka "initialize worker". While "INIT" in the macro names
    stands for the noun "INITIALIZER" aka "worker initializer".

  + INIT() macros are used only in DEFINE() macros

  + init() functions are used close to the other kthread()
    functions. It looks much better if all the functions
    use the same scheme.

  + There will be also kthread_destroy_worker() that will
    be used close to kthread_cancel_work(). It is related
    to the init() function. Again it looks better if all
    functions use the same naming scheme.

  + there are several precedents for such init() function
    names, e.g. amd_iommu_init_device(), free_area_init_node(),
    jump_label_init_type(),  regmap_init_mmio_clk(),

  + It is not an argument but it was inconsistent even before.

[arnd@arndb.de: fix linux-next merge conflict]
 Link: http://lkml.kernel.org/r/20160908135724.1311726-1-arnd@arndb.de
Link: http://lkml.kernel.org/r/1470754545-17632-3-git-send-email-pmladek@suse.comSuggested-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NPetr Mladek <pmladek@suse.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Josh Triplett <josh@joshtriplett.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Borislav Petkov <bp@suse.de>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3989144f
  39. 11 10月, 2016 1 次提交
    • T
      spi: Add Flag to Enable Slave Select with GPIO Chip Select. · 6b1576aa
      由 Thor Thayer 提交于 
      Some SPI masters require slave selection before the transfer
can begin [1]. The SPI framework currently selects the chip using
either 1) the internal CS mechanism or 2) the GPIO CS, but not both.

This patch adds a new master->flags define to indicate both the GPIO
CS and the internal chip select mechanism should be used.

Tested On:
    Altera CycloneV development kit
    Compile tested for build errors on x86_64 (allyesconfigs)

[1] DesignWare dw_apb_ssi Databook, Version 3.20a (page 39)
Signed-off-by: NThor Thayer <tthayer@opensource.altera.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      6b1576aa
  41. 03 9月, 2016 1 次提交
  43. 17 8月, 2016 1 次提交
  45. 10 8月, 2016 1 次提交
  47. 25 7月, 2016 1 次提交
    • M
      spi: Split bus and I/O locking · ef4d96ec
      由 Mark Brown 提交于 
      The current SPI code attempts to use bus_lock_mutex for two purposes. One
is to implement spi_bus_lock() which grants exclusive access to the bus.
The other is to serialize access to the physical hardware. This duplicate
purpose causes confusion which leads to cases where access is not locked
when a caller holds the bus lock mutex. Fix this by splitting out the I/O
functionality into a new io_mutex.

This means taking both mutexes in the DMA path, replacing the existing
mutex with the new I/O one in the message pump (the mutex now always
being taken in the message pump) and taking the bus lock mutex in
spi_sync(), allowing __spi_sync() to have no mutex handling.

While we're at it hoist the mutex further up the message pump before we
power up the device so that all power up/down of the block is covered by
it and there are no races with in-line pumping of messages.
Reported-by: NRich Felker <dalias@libc.org>
Tested-by: NRich Felker <dalias@libc.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      ef4d96ec
  49. 09 7月, 2016 1 次提交
    • O
      spi / ACPI: add support for ACPI reconfigure notifications · 7f24467f
      由 Octavian Purdila 提交于 
      This patch adds supports for SPI device enumeration and removal via
ACPI reconfiguration notifications that are send as a result of an
ACPI table load or unload operation.

The code is very similar with the device tree reconfiguration code
with only small differences in the way we test and set the enumerated
state of the device:

 * the equivalent of device tree's OF_POPULATED flag is the
   flags.visited field in the ACPI device and the following wrappers
   are used to manipulate it: acpi_device_enumerated(),
   acpi_device_set_enumerated() and acpi_device_clear_enumerated()

 * the device tree code checks of status of the OF_POPULATED flag to
   avoid trying to create duplicate Linux devices in two places: once
   when the controller is probed, and once when the reconfigure event
   is received; in the ACPI code the check is performed only once when
   the ACPI namespace is searched because this code path is invoked in
   both of the two mentioned cases

The rest of the enumeration handling is similar with device tree: when
the Linux device is unregistered the ACPI device is marked as not
enumerated; also, when a device remove notification is received we
check that the device is in the enumerated state before continuing
with the removal of the Linux device.
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7f24467f
  51. 08 6月, 2016 1 次提交
    • V
      spi: Add DMA support for spi_flash_read() · f4502dd1
      由 Vignesh R 提交于 
      Few SPI devices provide accelerated read interfaces to read from
SPI-NOR flash devices. These hardwares also support DMA to transfer data
from flash to memory either via mem-to-mem DMA or dedicated slave DMA
channels. Hence, add support for DMA in order to improve throughput and
reduce CPU load.
Use spi_map_buf() to get sg table for the buffer and pass it to SPI
driver.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      f4502dd1
  53. 04 5月, 2016 1 次提交
  55. 26 4月, 2016 1 次提交
  57. 12 4月, 2016 1 次提交
  59. 18 3月, 2016 1 次提交
  61. 11 3月, 2016 1 次提交
  63. 09 3月, 2016 2 次提交
    • A
      spi: respect the maximum segment size of DMA device · df88e91b
      由 Andy Shevchenko 提交于 
      The device which is actually does DMA may have a limitation of the maximum
segment size. Respect this setting when preparing scatter-gather list.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      df88e91b
    • J
      spi: core: Fix deadlock when sending messages · 49023d2e
      由 Jon Hunter 提交于 
      The function __spi_pump_messages() is called by spi_pump_messages() and
__spi_sync(). The function __spi_sync() has an argument 'bus_locked'
that indicates if it is called with the SPI bus mutex held or not. If
'bus_locked' is false then __spi_sync() will acquire the mutex itself.

Commit 556351f1 ("spi: introduce accelerated read support for spi
flash devices") made a change to acquire the SPI bus mutex within
__spi_pump_messages(). However, this change did not check to see if the
mutex is already held. If __spi_sync() is called with the mutex held
(ie. 'bus_locked' is true), then a deadlock occurs when
__spi_pump_messages() is called.

Fix this deadlock by passing the 'bus_locked' state from __spi_sync() to
__spi_pump_messages() and only acquire the mutex if not already held. In
the case where __spi_pump_messages() is called from spi_pump_messages()
it is assumed that the mutex is not held and so call
__spi_pump_messages() with 'bus_locked' set to false. Finally, move the
unlocking of the mutex to the end of the __spi_pump_messages() function
to simplify the code and only call cond_resched() if there are no
errors.

Fixes: 556351f1 ("spi: introduce accelerated read support for spi flash devices")
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      49023d2e
  65. 22 2月, 2016 1 次提交
  67. 19 2月, 2016 2 次提交
  69. 18 2月, 2016 1 次提交