Explicitly note the transfer_one and transfer_one_message are mutually
exclusive, to make the text a little more newcomers friendly.
Signed-off-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NMark Brown <broonie@linaro.org>

The documentation for spi_master.set_cs() says:

    assert or deassert chip select, true to assert

i.e. its "enable" parameter uses assertion-level logic.

This does not match the implementation of spi_set_cs(), which calls
spi_master.set_cs() with the wanted logic level of the chip select line,
which depends on the polarity of the chip select signal.

Correct the documentation to match the implementation.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

spi_write_then_read() takes a "void *" for rxbuf, so there's no need to
cast the buffer pointer to "u8 *".
Signed-off-by: NGeert Uytterhoeven <geert+renesas@linux-m68k.org>
Signed-off-by: NMark Brown <broonie@linaro.org>

Trent Piepho observed that since the current realistic maximum number of
data lines is four we can pack the spi_transfer struct more efficiently
if we use a bitfield for the number of bits, allowing the fields to fit
in a single byte along with cs_change.

If space becomes an issue further optimiation is possible by only using
the constants and packing the values chosen for them.
Reported-by: NTrent Piepho <tpiepho@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Now that spi_device->mode is a u16, the chip_select, bits_per_mode,
and mode fields pack poorly, taking 8 bytes:  four data and four
padding.  By moving (u8)bits_per_word up one position, to after
(u8)chip_select, they pack better and only use 4 bytes.
Signed-off-by: NTrent Piepho <tpiepho@gmail.com>
Reviewed-by: NSourav Poddar <sourav.poddar@ti.com>
Tested-by: Sourav Poddar <sourav.poddar@ti.com>g
Signed-off-by: NMark Brown <broonie@linaro.org>

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>

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>

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>

Help simplify the cleanup code for SPI master drivers by providing a
managed master registration function, ensuring that the master is
automatically unregistered whenever the device is unbound.
Signed-off-by: NMark Brown <broonie@linaro.org>

fix the previous patch some mistake below:
1. DT in slave node, use "spi-tx-nbits = <1/2/4>" in place of using
   "spi-tx-dual, spi-tx-quad" directly, same to rx. So correct the
   previous way to get the property in @of_register_spi_devices().
2. Change the value of transfer bit macro(SPI_NBITS_SINGLE, SPI_NBITS_DUAL
   SPI_NBITS_QUAD) to 0x01, 0x02 and 0x04 to match the actual wires.
3. Add the following check
   (1)keep the tx_nbits and rx_nbits in spi_transfer is not beyond the
      single, dual and quad.
   (2)keep tx_nbits and rx_nbits are contained by @spi_device->mode
      example: if @spi_device->mode = DUAL, then tx/rx_nbits can not be set
               to QUAD(SPI_NBITS_QUAD)
   (3)if "@spi_device->mode & SPI_3WIRE", then tx/rx_nbits should be in
      single(SPI_NBITS_SINGLE)
Signed-off-by: Nwangyuhang <wangyuhang2014@gmail.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

On a 64-bit platform, ~0UL fills 64-bits, which causes SPI_BIT_MASK(32)
not to fit into 32 bits. This causes a warning when the result is assigned
to a 32-bit variable. Use ~0U instead to prevent this. This fixes:

drivers/spi/spi-gpio.c: In function 'spi_gpio_probe':
drivers/spi/spi-gpio.c:446:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Most SPI drivers that implement runtime PM support use identical code to
do so: they acquire a runtime PM lock in prepare_transfer_hardware() and
then they release it in unprepare_transfer_hardware(). The variations in
this are mostly missing error checking and the choice to use autosuspend.

Since these runtime PM calls are normally the only thing in the prepare
and unprepare callbacks and the autosuspend API transparently does the
right thing on devices with autosuspend disabled factor all of this out
into the core with a flag to enable the behaviour.
Signed-off-by: NMark Brown <broonie@linaro.org>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Make spi core calculate the message length while
populating the other transfer parameters.

Usecase, driver can use it to populate framelength filed in their
controller.
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Allow drivers to avoid implementing their own checks for simple rates by
specifying the limits in the master structure.
Signed-off-by: NMark Brown <broonie@linaro.org>

SPI_BPW_RANGE_MASK is intended to work by calculating two masks; one
representing support for all bits up-to-and-including the "max" supported
value, and one representing support for all bits up-to-but-not-including
the "min" supported value, and then taking the difference between the
two, resulting in a mask representing support for all bits between
(inclusive) the min and max values.

However, the second mask ended up representing all bits up-to-and-
including rather up-to-but-not-including. Fix this bug.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

The parameters to SPI_BPW_RANGE_MASK() are in the range 1..32. If 32 is
used as a parameter, part of the expression is "1 << 32". Since 32 is >=
the size of the type in use, such a shift is undefined behaviour. Add
macro SPI_BIT_MASK to Implement a special case and thus avoid undefined
behaviour. Use this new macro rather than BIT() when implementing
SPI_BPW_RANGE_MASK().

This fixes build warnings such as:
drivers/spi/spi-gpio.c:446:2: warning: left shift count >= width of type [enabled by default]

SPI_BPW_MASK() already avoids this, since its parameter is also in range
1..32, yet it only shifts by up to one less than the input parameter.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@linaro.org>

Introduce two macros to make setting up spi_master.bits_per_word_mask
easier, and avoid mistakes like writing BIT(n) instead of BIT(n - 1).

SPI_BPW_MASK is for a single supported value of bits_per_word_mask.

SPI_BPW_RANGE_MASK represents a contiguous set of bit lengths.
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The return value from of_get_named_gpio is -ENOENT when the given index
matches a hole in the "cs-gpios" property phandle list. However, the
default value of cs_gpio in struct spi_device and entries of cs_gpios in
struct spi_master is -EINVAL, which is documented to indicate that a
GPIO line should not be used for the given spi_device.

This sets the default value of cs_gpio in struct spi_device and entries
of cs_gpios in struct spi_master to -ENOENT. Thus, -ENOENT is the only
value used to indicate that no GPIO line should be used.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Allow SPI masters to define the set of bits_per_word values they support.
If they do this, then the SPI core will reject transfers that attempt to
use an unsupported bits_per_word value. This eliminates the need for each
SPI driver to implement this checking in most cases.
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

This adds missing kernel-doc entries for cs_gpios in struct spi_master and
cs_gpio in struct spi_device.
Signed-off-by: NAndreas Larsson <andreas@gaisler.com>
[grant.likely: tweaked the language of the descriptions]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Quite often the pattern used for setting up and transferring a synchronous SPI
transaction looks very much like the following:

	struct spi_message msg;
	struct spi_transfer xfers[] = {
		...
	};

	spi_message_init(&msg);
	spi_message_add_tail(&xfers[0], &msg);
	...
	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);

	ret = spi_sync(&msg);

This patch adds two new helper functions for handling this case. The first
helper function spi_message_init_with_transfers() takes a spi_message and an
array of spi_transfers. It will initialize the message and then call
spi_message_add_tail() for each transfer in the array. E.g. the following

	spi_message_init(&msg);
	spi_message_add_tail(&xfers[0], &msg);
	...
	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);

can be rewritten as

	spi_message_init_with_transfers(&msg, xfers, ARRAY_SIZE(xfers));

The second function spi_sync_transfer() takes a SPI device and an array of
spi_transfers. It will allocate a new spi_message (on the stack) and add all
transfers in the array to the message. Finally it will call spi_sync() on the
message.

E.g. the follwing

	struct spi_message msg;
	struct spi_transfer xfers[] = {
		...
	};

	spi_message_init(&msg);
	spi_message_add_tail(&xfers[0], &msg);
	...
	spi_message_add_tail(&xfers[ARRAY_SIZE(xfers) - 1], &msg);

	ret = spi_sync(spi, &msg);

can be rewritten as

	struct spi_transfer xfers[] = {
		...
	};

	ret = spi_sync_transfer(spi, xfers, ARRAY_SIZE(xfers));

A coccinelle script to find such instances will follow.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NJonathan Cameron <jic23@kernel.org>

This will allow to use gpio for chip select with no modification in the
driver binding

When use the cs-gpios, the gpio number will be passed via the cs_gpio field
and the number of chip select will automatically increased with max(hw cs, gpio cs).

So if for example the controller has 2 CS lines, and the cs-gpios
property looks like this:

cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>;

Then it should be configured so that num_chipselect = 4 with the
following mapping:

cs0 : &gpio1 0 0
cs1 : native
cs2 : &gpio1 1 0
cs3 : &gpio1 2 0
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: spi-devel-general@lists.sourceforge.net
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
[grant.likely: fixed up type of cs count so min() can do type checking]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Fix kernel-doc warning in spi.h (copy/paste):

Warning(include/linux/spi/spi.h:365): No description found for parameter 'unprepare_transfer_hardware'
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

The loop count i traverses for ntrans which is unsigned
so make the loop count i also unsigned.

Fix the below warning
In file included from drivers/spi/spi-omap2-mcspi.c:38:
include/linux/spi/spi.h: In function 'spi_message_alloc':
include/linux/spi/spi.h:556: warning: comparison between signed and unsigned integer expressions

Cc: Vitaly Wool <vwool@ru.mvista.com>
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This rips the message queue in the PL022 driver out and pushes
it into (optional) common infrastructure. Drivers that want to
use the message pumping thread will need to define the new
per-messags transfer methods and leave the deprecated transfer()
method as NULL.

Most of the design is described in the documentation changes that
are included in this patch.

Since there is a queue that need to be stopped when the system
is suspending/resuming, two new calls are implemented for the
device drivers to call in their suspend()/resume() functions:
spi_master_suspend() and spi_master_resume().

ChangeLog v1->v2:
- Remove Kconfig entry and do not make the queue support optional
  at all, instead be more agressive and have it as part of the
  compulsory infrastructure.
- If the .transfer() method is implemented, delete print a small
  deprecation notice and do not start the transfer pump.
- Fix a bitrotted comment.
ChangeLog v2->v3:
- Fix up a problematic sequence courtesy of Chris Blair.
- Stop rather than destroy the queue on suspend() courtesy of
  Chris Blair.
Signed-off-by: NChris Blair <chris.blair@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

This patch introduces the module_spi_driver macro which is a convenience macro
for SPI driver modules similar to module_platform_driver. It is intended to be
used by drivers which init/exit section does nothing but register/unregister
the SPI driver. By using this macro it is possible to eliminate a few lines of
boilerplate code per SPI driver.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Currently the simple SPI I/O operations all take pointers to u8 * buffers
to operate on. This creates needless type compatibility issues and the
underlying spi_transfer structure uses void pointers anyway so convert the
API over to take void pointers too.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Currently spi_register_board_info() has to be called before its related
spi_master be registered, otherwise these board info will be just ignored.

This patch will remove this order limit, it adds a global spi master list
like the existing global board info listr. Whenever a board info or a
spi_master is registered, the spi master list or board info list
will be scanned, and a new spi device will be created if there is a
master-board info match.
Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

Added comments in kernel-doc notation for previously added struct fields.
Signed-off-by: NErnst Schwab <eschwab@online.de>
Acked-by: NRandy Dunlap <rdunlap@xenotime.net>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

SPI bus locking API to allow exclusive access to the SPI bus, especially, but
not limited to, for the mmc_spi driver.

Coded according to an outline from Grant Likely; here is his
specification (accidentally swapped function names corrected):

It requires 3 things to be added to struct spi_master.
- 1 Mutex
- 1 spin lock
- 1 flag.

The mutex protects spi_sync, and provides sleeping "for free"
The spinlock protects the atomic spi_async call.
The flag is set when the lock is obtained, and checked while holding
the spinlock in spi_async().  If the flag is checked, then spi_async()
must fail immediately.

The current runtime API looks like this:
spi_async(struct spi_device*, struct spi_message*);
spi_sync(struct spi_device*, struct spi_message*);

The API needs to be extended to this:
spi_async(struct spi_device*, struct spi_message*)
spi_sync(struct spi_device*, struct spi_message*)
spi_bus_lock(struct spi_master*)  /* although struct spi_device* might
be easier */
spi_bus_unlock(struct spi_master*)
spi_async_locked(struct spi_device*, struct spi_message*)
spi_sync_locked(struct spi_device*, struct spi_message*)

Drivers can only call the last two if they already hold the spi_master_lock().

spi_bus_lock() obtains the mutex, obtains the spin lock, sets the
flag, and releases the spin lock before returning.  It doesn't even
need to sleep while waiting for "in-flight" spi_transactions to
complete because its purpose is to guarantee no additional
transactions are added.  It does not guarantee that the bus is idle.

spi_bus_unlock() clears the flag and releases the mutex, which will
wake up any waiters.

The difference between spi_async() and spi_async_locked() is that the
locked version bypasses the check of the lock flag.  Both versions
need to obtain the spinlock.

The difference between spi_sync() and spi_sync_locked() is that
spi_sync() must hold the mutex while enqueuing a new transfer.
spi_sync_locked() doesn't because the mutex is already held.  Note
however that spi_sync must *not* continue to hold the mutex while
waiting for the transfer to complete, otherwise only one transfer
could be queued up at a time!

Almost no code needs to be written.  The current spi_async() and
spi_sync() can probably be renamed to __spi_async() and __spi_sync()
so that spi_async(), spi_sync(), spi_async_locked() and
spi_sync_locked() can just become wrappers around the common code.

spi_sync() is protected by a mutex because it can sleep
spi_async() needs to be protected with a flag and a spinlock because
it can be called atomically and must not sleep
Signed-off-by: NErnst Schwab <eschwab@online.de>
[grant.likely@secretlab.ca: use spin_lock_irqsave()]
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
Tested-by: NMatt Fleming <matt@console-pimps.org>
Tested-by: NAntonio Ospite <ospite@studenti.unina.it>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

Support two new half-duplex SPI implementation restrictions, for links
that talk to TX-only or RX-only devices.  (Existing half-duplex flavors
support both transfer directions, just not at the same time.)

Move spi_async() into the spi.c core, and stop inlining it.  Then make
that function perform error checks and reject messages that demand more
than the underlying controller can support.

Based on a patch from Marek Szyprowski which did this only for the
bitbanged GPIO driver.

Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With this patch spi drivers can use standard spi_driver.id_table and
MODULE_DEVICE_TABLE() mechanisms to bind against the devices.  Just like
we do with I2C drivers.

This is useful when a single driver supports several variants of devices
but it is not possible to detect them in run-time (like non-JEDEC chips
probing in drivers/mtd/devices/m25p80.c), and when platform_data usage is
overkill.

This patch also makes life a lot easier on OpenFirmware platforms, since
with OF we extensively use proper device IDs in modaliases.
Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add missing kernel-doc notation in spi.h for struct spi_master:

Warning(include/linux/spi/spi.h:289): No description found for parameter 'mode_bits'
Warning(include/linux/spi/spi.h:289): No description found for parameter 'flags'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add a new spi_master.flags word listing constraints relevant to that
controller.  Define the first constraint bit: a half duplex restriction.
Include that constraint in the OMAP1 MicroWire controller driver.

Have the mmc_spi host be the first customer of this flag.  Its coding
relies heavily on full duplex transfers, so it must fail when the
underlying controller driver won't perform them.

(The spi_write_then_read routine could use it too: use the
temporarily-withdrawn full-duplex speedup unless this flag is set, in
which case the existing code applies.  Similarly, any spi_master
implementing only SPI_3WIRE should set the flag.)
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add two new spi_device.mode bits to accomodate more protocol options, and
pass them through to usermode drivers:

 * SPI_NO_CS ... a second 3-wire variant, where the chipselect
   line is removed instead of a data line; transfers are still
   full duplex.

   This obviously has STRONG protocol implications since the
   chipselect transitions can't be used to synchronize state
   transitions with the SPI master.

 * SPI_READY ... defines open drain signal that's pulled low
   to pause the clock.  This defines a 5-wire variant (normal
   4-wire SPI plus READY) and two 4-wire variants (READY plus
   each of the 3-wire flavors).

   Such hardware flow control can be a big win.  There are ADC
   converters and flash chips that expose READY signals, but not
   many host controllers support it today.

The spi_bitbang code should be changed to use SPI_NO_CS instead of its
current nonportable hack.  That's a mode most hardware can easily support
(unlike SPI_READY).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: "Paulraj, Sandeep" <s-paulraj@ti.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Move some common spi_setup() error checks into the SPI framework from the
spi_master controller drivers:

 - Add a new "mode_bits" field to spi_master

 - Use that in spi_setup to validate the spi->mode value being
   requested.  Setting this new field is now mandatory for any
   controller supporting more than vanilla SPI_MODE_0.

 - Update all spi_master drivers to:

     * Initialize that field
     * Remove current spi_setup() checks using that value.

This is a net minor code shrink.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Start moving some spi_setup() functionality into the SPI core from the
various spi_master controller drivers:

 - Make that function stop being an inline;

 - Move two common idioms from drivers into that new function:
    * Default bits_per_word to 8 if that field isn't set
    * Issue a standardized dev_dbg() message

This is a net minor source code shrink, and supports enhancments found in
some follow-up patches.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This is a doc-only patch which I hope will reduce the number of
spi_master controller driver patches starting out with a common
implementation bug.

(As in: almost every spi_master driver I see starts out with its
version of this bug.  Sigh.)

It just re-emphasizes that the setup() method may be called for one
device while a transfer is active on another ...  which means that most
driver implementations shouldn't touch any registers.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>