[V3] spi: Add SPI mux core and GPIO-based mux driver

This patch contains the core functionality for a multiplexer on an
SPI bus. This can be useful if a board requires more SPI devices,
and thus more chip selects, than the SPI controller on the processor
has available.

The mux device is added in the device tree as a child node of the
SPI master. Then, devices can be added as children of the mux node.
The mux will appear as if it was a SPI master device, and child
nodes will appear as chip selects on the mux bus. A bindings file is
provided for the device tree bindings.

This patch also includes a driver for a GPIO-based multiplexer, which
makes use of the core code, as an example for others to follow when
implementing their own SPI mux.  A bindings file for the GPIO
implementation is also provided for the device tree bindings.

Signed-off-by: Dries Van Puymbroeck <Dries.VanPuymbroeck@barco.com>
Tested-by: Dan Donahue <ddonahue@gridcosystems.com>
---

Hi,

This is a re-submit from a previous patch.
The previous submit of this version (V2) can be found at
http://permalink.gmane.org/gmane.linux.kernel.spi.devel/13590
V1 and discussion about it on which the changes for V2 were based can be
found at http://comments.gmane.org/gmane.linux.kernel.spi.devel/12868

We've tested the core driver a bit more now, fixed 2 bugs, and removed all use
of the max speed setting of the mux. See the changelog for an overview.

I hope there is still interest in getting this to mainline? I'm still looking
forward to feedback on the changes, and if any more work is required. Let me
know also if I messed something up on the previous submits or if they just got
missed?

Thanks,

Dries Van Puymbroeck.

Change log:

Changes w.r.t. V2:
 - At driver startup, the mux would be set to "channel 0," but the child device
   settings were not copied. Fixed by adding a SPI_MUX_NO_CS define, which is
   used as the default now.

 - Compare of child max speed with mux max speed removed, as we've discussed
   that a max speed for the mux makes little sense. The DT property is still
   needed for the check in spi.c to pass, but the value is no longer used in
   the mux driver code.

 - Bug fixed which caused the lowest speed amongst all child devices to be used
   for each child device.

Changes w.r.t. V1:
 - Split the core mux functionality and the specific mux code. Core
   functionality now is in spi-mux.c, while the actual mux we use is
   in spi-barco-orka-mux-gpio.c. Using the latter as an example,
   other users should be able to add different mux implementations,
   reusing the parts in the core. spi-mux.h is also provided to be
   in include/linux/spi/

 - Changed the compatible string of the specific mux implementation
   to "barco,orka-spi-mux-gpio"

 - Changed device tree property "mux-gpios" to "gpios"

 - Changed the spi_mux_transfer_one_message and spi_mux_complete_cb
   functions according to feedback from Grant Likely: removed the
   wait queue, and call the spi_finalize_current_message call
   directly from the spi_mux_complete_cb. This removes xfer_complete
   and xfer_complete_wq, and moves child_mesg_complete
   child_mesg_context and child_mesg_dev into spi_mux_priv.

 - Renamed some structs and functions to be more in line with the
   naming in the code for I2C muxes.

 - Joined the spi_mux_gpio_probe_dt function with the
   spi_mux_gpio_probe function (and renamed to spi_add_mux)

 - Removed the values array per chip select in the specific mux code.
   The reg property is now directly used as chip select and bit mask
   for the gpio mux. (This also removes a bug where the values array
   was incorrectly allocated for sparse CS's

 - Removed of_match_ptr since driver is DT only.

Not changed w.r.t. V1:
 - spi-max-frequency is still a required DT property, even for the
   gpio mux, though it does not mean anything there. However, the
   check for this mandatory property is done by the spi core, before
   the probe function of the mux is called. This means that the mux
   code cannot get the property from its child devices before the
   check is done (and right now the core aborts the initialization if
   spi-max-frequency is not set). The only solution I see is to loosen
   the check in spi core, or requiring that muxes have this property
   too, even if it does not have meaning. If anyone has some ideas
   about this, I would appreciate them!
---
 .../bindings/spi/barco-orka-spi-mux-gpio.txt       |   35 ++++
 Documentation/devicetree/bindings/spi/spi-mux.txt  |  106 ++++++++++
 drivers/spi/Kconfig                                |   96 ++++-----
 drivers/spi/Makefile                               |   12 +-
 drivers/spi/spi-barco-orka-mux-gpio.c              |  142 +++++++++++++
 drivers/spi/spi-mux.c                              |  219 ++++++++++++++++++++
 include/linux/spi/spi-mux.h                        |   58 ++++++
 7 files changed, 607 insertions(+), 61 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/barco-orka-spi-mux-gpio.txt
 create mode 100644 Documentation/devicetree/bindings/spi/spi-mux.txt
 create mode 100644 drivers/spi/spi-barco-orka-mux-gpio.c
 create mode 100644 drivers/spi/spi-mux.c
 create mode 100644 include/linux/spi/spi-mux.h

[V3] spi: Add SPI mux core and GPIO-based mux driver

Commit Message

Patch