diff options
author | Linus Walleij <linus.walleij@linaro.org> | 2018-02-12 13:45:30 +0100 |
---|---|---|
committer | Mark Brown <broonie@kernel.org> | 2018-02-14 16:02:41 +0000 |
commit | 9b00bc7b901ff672a9252002d3810fdf9489bc64 (patch) | |
tree | 533b0c9c3d81ed36732c69350139a0ca56d085cb /include/linux/spi | |
parent | 7928b2cbe55b2a410a0f5c1f154610059c57b1b2 (diff) | |
download | talos-obmc-linux-9b00bc7b901ff672a9252002d3810fdf9489bc64.tar.gz talos-obmc-linux-9b00bc7b901ff672a9252002d3810fdf9489bc64.zip |
spi: spi-gpio: Rewrite to use GPIO descriptors
This converts the bit-banged GPIO SPI driver to looking up and
using GPIO descriptors to get a handle on GPIO lines for SCK,
MOSI, MISO and all CS lines.
All existing board files are converted in one go to keep it all
consistent. With these conversions I rarely find any interrim
steps that makes any sense.
Device tree probing and GPIO handling should work like before
also after this patch.
For board files, we stop using controller data to pass the GPIO
line for chip select, instead we pass this as a GPIO descriptor
lookup like everything else.
In some s3c24xx machines the names of the SPI devices were set to
"spi-gpio" rather than "spi_gpio" which can never have worked, I
fixed it working (I guess) as part of this patch set. Sometimes
I wonder how this code got upstream in the first place, it
obviously is not tested.
mach-s3c64xx/mach-smartq.c has the same problem and additionally
defines the *same* GPIO line for MOSI and MISO which is not going
to be accepted by gpiolib. As the lines were number 1,2,2 I assumed
it was a typo and use lines 1,2,3. A comment gives awat that line 0
is chip select though no actual SPI device is provided for the LCD
supposed to be on this bit-banged SPI bus. I left it intact instead
of just deleting the bus though.
Kill off board file code that try to initialize the SPI lines
to the same values that they will later be set by the spi_gpio
driver anyways. Given the huge number of weird things in these
board files I do not think this code is very tested or put in
with much afterthought anyways.
In order to assert that we do not get performance regressions on
this crucial bing-banged driver, a ran a script like this dumping the
Ilitek ILI9322 regmap 10000 times (it has no caching obviously) on
an otherwise idle system in two iterations before and after the
patches:
#!/bin/sh
for run in `seq 10000`
do
cat /debug/regmap/spi0.0/registers > /dev/null
done
Before the patch:
time test.sh
real 3m 41.03s
user 0m 29.41s
sys 3m 7.22s
time test.sh
real 3m 44.24s
user 0m 32.31s
sys 3m 7.60s
After the patch:
time test.sh
real 3m 41.32s
user 0m 28.92s
sys 3m 8.08s
time test.sh
real 3m 39.92s
user 0m 30.20s
sys 3m 5.56s
So any performance differences seems to be in the error margin.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Olof Johansson <olof@lixom.net>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Diffstat (limited to 'include/linux/spi')
-rw-r--r-- | include/linux/spi/spi_gpio.h | 49 |
1 files changed, 1 insertions, 48 deletions
diff --git a/include/linux/spi/spi_gpio.h b/include/linux/spi/spi_gpio.h index e7bd89a59cd1..9e7e83d8645b 100644 --- a/include/linux/spi/spi_gpio.h +++ b/include/linux/spi/spi_gpio.h @@ -8,64 +8,17 @@ * - id the same as the SPI bus number it implements * - dev.platform data pointing to a struct spi_gpio_platform_data * - * Or, see the driver code for information about speedups that are - * possible on platforms that support inlined access for GPIOs (no - * spi_gpio_platform_data is used). - * - * Use spi_board_info with these busses in the usual way, being sure - * that the controller_data being the GPIO used for each device's - * chipselect: - * - * static struct spi_board_info ... [] = { - * ... - * // this slave uses GPIO 42 for its chipselect - * .controller_data = (void *) 42, - * ... - * // this one uses GPIO 86 for its chipselect - * .controller_data = (void *) 86, - * ... - * }; - * - * If chipselect is not used (there's only one device on the bus), assign - * SPI_GPIO_NO_CHIPSELECT to the controller_data: - * .controller_data = (void *) SPI_GPIO_NO_CHIPSELECT; - * - * If the MISO or MOSI pin is not available then it should be set to - * SPI_GPIO_NO_MISO or SPI_GPIO_NO_MOSI. + * Use spi_board_info with these busses in the usual way. * * If the bitbanged bus is later switched to a "native" controller, * that platform_device and controller_data should be removed. */ -#define SPI_GPIO_NO_CHIPSELECT ((unsigned long)-1l) -#define SPI_GPIO_NO_MISO ((unsigned long)-1l) -#define SPI_GPIO_NO_MOSI ((unsigned long)-1l) - /** * struct spi_gpio_platform_data - parameter for bitbanged SPI master - * @sck: number of the GPIO used for clock output - * @mosi: number of the GPIO used for Master Output, Slave In (MOSI) data - * @miso: number of the GPIO used for Master Input, Slave Output (MISO) data * @num_chipselect: how many slaves to allow - * - * All GPIO signals used with the SPI bus managed through this driver - * (chipselects, MOSI, MISO, SCK) must be configured as GPIOs, instead - * of some alternate function. - * - * It can be convenient to use this driver with pins that have alternate - * functions associated with a "native" SPI controller if a driver for that - * controller is not available, or is missing important functionality. - * - * On platforms which can do so, configure MISO with a weak pullup unless - * there's an external pullup on that signal. That saves power by avoiding - * floating signals. (A weak pulldown would save power too, but many - * drivers expect to see all-ones data as the no slave "response".) */ struct spi_gpio_platform_data { - unsigned sck; - unsigned long mosi; - unsigned long miso; - u16 num_chipselect; }; |