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>

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>

Add an interface analogous to ->can_dma() for spi_flash_read()
interface. This will enable SPI controller drivers to inform SPI core
when not to do DMA mappings.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Invoke the proper function while initializing
a dynamically allocated spi_message to avoid
NULL pointer dereference during resources deallocation.
Signed-off-by: NEmiliano Ingrassia <ingrassia@epigenesys.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Generic device properties support statically defined property sets. For
them to be usable, we need to attach these property sets before devices
are registered and probed. Allowing to attach property list to
spi_board_info structure will allow non-ACPI non-DT boards switch to using
generic properties and get rid of custom platform data.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

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>

Simplify spi_write() and spi_read() using the spi_sync_transfer()
helper.

This requires moving spi_sync_transfer() up.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

Recently a maximum transfer size was was introduced in struct spi_master.
However there are also spi controllers with a maximum message size, e.g.
fsl-espi has a max message size of 64KB.
Introduce a hook max_message_size to deal with such limitations.

Also make sure that spi_max_transfer_size doesn't return greater values
than spi_max_message_size, even if hook max_transfer_size is not set.
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

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>

If hook spi_flash_read is implemented the fast flash read feature
is enabled for all devices attached to the respective master.

In most cases there is just one flash chip, however there are also
devices with more than one flash chip, namely some WiFi routers.
Then the fast flash read feature can be used for the first chip only.
OpenWRT implemented an own handling of this case, using controller_data
element of spi_device to hold the information whether fast flash read
can be used for a device.

This patch adds hook flash_read_supported to spi_master which is
used to extend spi_flash_read_supported() by checking whether the
fast flash read feature can be used for a specific spi_device.

If the hook is not implemented the default behavior is to allow
fast flash read for all devices (if spi_flash_read is implemented).
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

The kernel-doc has to be just before the structure definition but the one
for struct spi_replaced_transfers was before a structure declaration and
that confuses kernel-doc which complains with the following build error:

.//include/linux/spi/spi.h:933: error: Cannot parse struct or union!
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fixes docbook parsing error because documentation
is not directly followed by the structure, but typedef
used in structure.

Reordering should solve that issue.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

In addition to providing direct access to SPI bus, some spi controller
hardwares (like ti-qspi) provide special port (like memory mapped port)
that are optimized to improve SPI flash read performance.
This means the controller can automatically send the SPI signals
required to read data from the SPI flash device.
For this, SPI controller needs to know flash specific information like
read command to use, dummy bytes and address width.

Introduce spi_flash_read() interface to support accelerated read
over SPI flash devices. SPI master drivers can implement this callback to
support interfaces such as memory mapped read etc. m25p80 flash driver
and other flash drivers can call this make use of such interfaces. The
interface should only be used with SPI flashes and cannot be used with
other SPI devices.
Signed-off-by: NVignesh R <vigneshr@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add spi_split_transfers_maxsize method that splits
spi_transfers transparently into multiple transfers
that are below the given max-size.

This makes use of the spi_res framework via
spi_replace_transfers to allocate/free the extra
transfers as well as reverting back the changes applied
while processing the spi_message.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add the spi_replace_transfers method that can get used
to replace some spi_transfers from a spi_message with other
transfers.
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

SPI resource management framework used while processing a spi_message
via the spi-core.

The basic idea is taken from devres, but as the allocation may happen
fairly frequently, some provisioning (in the form of an unused spi_device
pointer argument to spi_res_alloc) has been made so that at a later stage
we may implement reuse objects allocated earlier avoiding the repeated
allocation by keeping a cache of objects that we can reuse.

This framework can get used for:
* rewriting spi_messages
  * to fullfill alignment requirements of the spi_master HW
  * to fullfill transfer length requirements
    (e.g: transfers need to be less than 64k)
  * consolidate spi_messages with multiple transfers into a single transfer
  when the total transfer length is below a threshold.
* reimplement spi_unmap_buf without explicitly needing to check if it has
  been mapped
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

In Windows it is up to the SPI host controller driver to handle the ACPI
DeviceSelection as it likes. The SPI core does not take any part in it.
This is different in Linux because we always expect to have chip select in
range of 0 .. master->num_chipselect - 1.

In order to support this in Linux we need a way to allow the driver to
translate between ACPI DeviceSelection field and Linux chip select number
so provide a new optional hook ->fw_translate_cs() that can be used by a
driver to handle translation and call this hook if set during SPI slave
ACPI enumeration.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fix kernel-doc warning for missing struct field notation.

..//include/linux/spi/spi.h:540: warning: No description found for parameter 'max_transfer_size'

[Meaningful subject -- broonie]
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

On some SPI controllers it is not feasible to transfer arbitrary amount
of data at once.

When the limit on transfer size is a few kilobytes at least it makes
sense to use the SPI hardware rather than reverting to gpio driver.

The protocol drivers need a way to check that they do not sent overly
long messages, though.
Signed-off-by: NMichal Suchanek <hramrach@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

Uninline spi_unregister_device() in preparation of adding more code to
it. Add kerneldoc documentation while we're at it.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add spi_register_driver helper macro that adds THIS_MODULE to
spi_driver for the registering driver. We rename and modify
the existing spi_register_driver to enable this.
Signed-off-by: NAndrew F. Davis <afd@ti.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When building docs with make htmldocs, warnings about not having
a description for the return value are reported, i.e:

warning: No description found for return value of 'spi_write'

Fix these by following the kernel-doc conventions explained in
Documentation/kernel-doc-nano-HOWTO.txt.
Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

report transfer sizes as a histogram via the following files:
  /sys/class/spi_master/spi*/statistics/transfer_bytes_histo_*
  /sys/class/spi_master/spi*/spi*.*/statistics/transfer_bytes_histo_*
Signed-off-by: NMartin Sperl <kernel@martin.sperl.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

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>

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>

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>

This callback would be useful to handle an error that occurs in the generic
implementation of transfer_one_message(). The good candidate for this is to
drain FIFO and / or to terminate DMA transfers when timeout happened.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

alway -> always
Signed-off-by: NMarcin Bis <marcin@bis.org.pl>
Signed-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

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>

This adds the function spi_transfer_is_last() which can be used by
drivers to know whether a given transfer is the last one in the
current message.
Signed-off-by: NBeniamino Galvani <b.galvani@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

These are all arguments or fields that got added without updating the
kerneldoc comments.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

This patch fix spelling typo in Documentation/DocBook.
It is because .html and .xml files are generated by make htmldocs,
I have to fix a typo within the source files.
Signed-off-by: NMasanari Iida <standby24x7@gmail.com>
Acked-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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>

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>

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>