2019-05-27 06:55:06 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2009-01-06 22:41:41 +00:00
|
|
|
/*
|
2023-08-07 12:40:56 +00:00
|
|
|
* SPI host driver using generic bitbanged GPIO
|
2009-01-06 22:41:41 +00:00
|
|
|
*
|
|
|
|
* Copyright (C) 2006,2008 David Brownell
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
* Copyright (C) 2017 Linus Walleij
|
2009-01-06 22:41:41 +00:00
|
|
|
*/
|
2024-05-17 19:42:01 +00:00
|
|
|
#include <linux/gpio/consumer.h>
|
2009-01-06 22:41:41 +00:00
|
|
|
#include <linux/kernel.h>
|
2024-05-17 19:42:01 +00:00
|
|
|
#include <linux/mod_devicetable.h>
|
2011-07-03 19:44:29 +00:00
|
|
|
#include <linux/module.h>
|
2009-01-06 22:41:41 +00:00
|
|
|
#include <linux/platform_device.h>
|
2024-05-17 19:42:01 +00:00
|
|
|
#include <linux/property.h>
|
2009-01-06 22:41:41 +00:00
|
|
|
|
|
|
|
#include <linux/spi/spi.h>
|
|
|
|
#include <linux/spi/spi_bitbang.h>
|
|
|
|
#include <linux/spi/spi_gpio.h>
|
|
|
|
|
|
|
|
/*
|
2023-08-07 12:40:56 +00:00
|
|
|
* This bitbanging SPI host driver should help make systems usable
|
2009-01-06 22:41:41 +00:00
|
|
|
* when a native hardware SPI engine is not available, perhaps because
|
|
|
|
* its driver isn't yet working or because the I/O pins it requires
|
|
|
|
* are used for other purposes.
|
|
|
|
*
|
|
|
|
* platform_device->driver_data ... points to spi_gpio
|
|
|
|
*
|
|
|
|
* spi->controller_state ... reserved for bitbang framework code
|
|
|
|
*
|
2023-08-07 12:40:56 +00:00
|
|
|
* spi->controller->dev.driver_data ... points to spi_gpio->bitbang
|
2009-01-06 22:41:41 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
struct spi_gpio {
|
|
|
|
struct spi_bitbang bitbang;
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
struct gpio_desc *sck;
|
|
|
|
struct gpio_desc *miso;
|
|
|
|
struct gpio_desc *mosi;
|
|
|
|
struct gpio_desc **cs_gpios;
|
2009-01-06 22:41:41 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*----------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Because the overhead of going through four GPIO procedure calls
|
|
|
|
* per transferred bit can make performance a problem, this code
|
|
|
|
* is set up so that you can use it in either of two ways:
|
|
|
|
*
|
|
|
|
* - The slow generic way: set up platform_data to hold the GPIO
|
|
|
|
* numbers used for MISO/MOSI/SCK, and issue procedure calls for
|
|
|
|
* each of them. This driver can handle several such busses.
|
|
|
|
*
|
|
|
|
* - The quicker inlined way: only helps with platform GPIO code
|
|
|
|
* that inlines operations for constant GPIOs. This can give
|
|
|
|
* you tight (fast!) inner loops, but each such bus needs a
|
|
|
|
* new driver. You'll define a new C file, with Makefile and
|
|
|
|
* Kconfig support; the C code can be a total of six lines:
|
|
|
|
*
|
|
|
|
* #define DRIVER_NAME "myboard_spi2"
|
|
|
|
* #define SPI_MISO_GPIO 119
|
|
|
|
* #define SPI_MOSI_GPIO 120
|
|
|
|
* #define SPI_SCK_GPIO 121
|
|
|
|
* #define SPI_N_CHIPSEL 4
|
2011-06-06 07:16:30 +00:00
|
|
|
* #include "spi-gpio.c"
|
2009-01-06 22:41:41 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef DRIVER_NAME
|
|
|
|
#define DRIVER_NAME "spi_gpio"
|
|
|
|
|
|
|
|
#define GENERIC_BITBANG /* vs tight inlines */
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*----------------------------------------------------------------------*/
|
|
|
|
|
2015-01-05 12:01:03 +00:00
|
|
|
static inline struct spi_gpio *__pure
|
2012-09-05 09:04:35 +00:00
|
|
|
spi_to_spi_gpio(const struct spi_device *spi)
|
2009-01-06 22:41:41 +00:00
|
|
|
{
|
|
|
|
const struct spi_bitbang *bang;
|
2012-09-05 09:04:35 +00:00
|
|
|
struct spi_gpio *spi_gpio;
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
bang = spi_controller_get_devdata(spi->controller);
|
2009-01-06 22:41:41 +00:00
|
|
|
spi_gpio = container_of(bang, struct spi_gpio, bitbang);
|
2012-09-05 09:04:35 +00:00
|
|
|
return spi_gpio;
|
|
|
|
}
|
|
|
|
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
/* These helpers are in turn called by the bitbang inlines */
|
2009-01-06 22:41:41 +00:00
|
|
|
static inline void setsck(const struct spi_device *spi, int is_on)
|
|
|
|
{
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
|
|
|
|
|
|
|
|
gpiod_set_value_cansleep(spi_gpio->sck, is_on);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline void setmosi(const struct spi_device *spi, int is_on)
|
|
|
|
{
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
|
|
|
|
|
|
|
|
gpiod_set_value_cansleep(spi_gpio->mosi, is_on);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int getmiso(const struct spi_device *spi)
|
|
|
|
{
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2018-07-28 08:19:14 +00:00
|
|
|
if (spi->mode & SPI_3WIRE)
|
|
|
|
return !!gpiod_get_value_cansleep(spi_gpio->mosi);
|
|
|
|
else
|
|
|
|
return !!gpiod_get_value_cansleep(spi_gpio->miso);
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
}
|
2009-01-06 22:41:41 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* NOTE: this clocks "as fast as we can". It "should" be a function of the
|
|
|
|
* requested device clock. Software overhead means we usually have trouble
|
|
|
|
* reaching even one Mbit/sec (except when we can inline bitops), so for now
|
|
|
|
* we'll just assume we never need additional per-bit slowdowns.
|
|
|
|
*/
|
|
|
|
#define spidelay(nsecs) do {} while (0)
|
|
|
|
|
2011-06-06 07:16:30 +00:00
|
|
|
#include "spi-bitbang-txrx.h"
|
2009-01-06 22:41:41 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* These functions can leverage inline expansion of GPIO calls to shrink
|
|
|
|
* costs for a txrx bit, often by factors of around ten (by instruction
|
|
|
|
* count). That is particularly visible for larger word sizes, but helps
|
|
|
|
* even with default 8-bit words.
|
|
|
|
*
|
|
|
|
* REVISIT overheads calling these functions for each word also have
|
|
|
|
* significant performance costs. Having txrx_bufs() calls that inline
|
|
|
|
* the txrx_word() logic would help performance, e.g. on larger blocks
|
|
|
|
* used with flash storage or MMC/SD. There should also be ways to make
|
|
|
|
* GCC be less stupid about reloading registers inside the I/O loops,
|
|
|
|
* even without inlined GPIO calls; __attribute__((hot)) on GCC 4.3?
|
|
|
|
*/
|
|
|
|
|
|
|
|
static u32 spi_gpio_txrx_word_mode0(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2009-01-06 22:41:41 +00:00
|
|
|
{
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha0(spi, nsecs, 0, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static u32 spi_gpio_txrx_word_mode1(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2009-01-06 22:41:41 +00:00
|
|
|
{
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha1(spi, nsecs, 0, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha1(spi, nsecs, 0, flags, word, bits);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static u32 spi_gpio_txrx_word_mode2(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2009-01-06 22:41:41 +00:00
|
|
|
{
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha0(spi, nsecs, 1, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha0(spi, nsecs, 1, flags, word, bits);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static u32 spi_gpio_txrx_word_mode3(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2009-01-06 22:41:41 +00:00
|
|
|
{
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha1(spi, nsecs, 1, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha1(spi, nsecs, 1, flags, word, bits);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
2010-06-30 20:27:37 +00:00
|
|
|
/*
|
|
|
|
* These functions do not call setmosi or getmiso if respective flag
|
2023-07-10 15:49:28 +00:00
|
|
|
* (SPI_CONTROLLER_NO_RX or SPI_CONTROLLER_NO_TX) is set, so they are safe to
|
2010-06-30 20:27:37 +00:00
|
|
|
* call when such pin is not present or defined in the controller.
|
|
|
|
* A separate set of callbacks is defined to get highest possible
|
|
|
|
* speed in the generic case (when both MISO and MOSI lines are
|
|
|
|
* available), as optimiser will remove the checks when argument is
|
|
|
|
* constant.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static u32 spi_gpio_spec_txrx_word_mode0(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2010-06-30 20:27:37 +00:00
|
|
|
{
|
2023-08-07 12:40:56 +00:00
|
|
|
flags = spi->controller->flags;
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha0(spi, nsecs, 0, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha0(spi, nsecs, 0, flags, word, bits);
|
2010-06-30 20:27:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static u32 spi_gpio_spec_txrx_word_mode1(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2010-06-30 20:27:37 +00:00
|
|
|
{
|
2023-08-07 12:40:56 +00:00
|
|
|
flags = spi->controller->flags;
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha1(spi, nsecs, 0, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha1(spi, nsecs, 0, flags, word, bits);
|
2010-06-30 20:27:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static u32 spi_gpio_spec_txrx_word_mode2(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2010-06-30 20:27:37 +00:00
|
|
|
{
|
2023-08-07 12:40:56 +00:00
|
|
|
flags = spi->controller->flags;
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha0(spi, nsecs, 1, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha0(spi, nsecs, 1, flags, word, bits);
|
2010-06-30 20:27:37 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static u32 spi_gpio_spec_txrx_word_mode3(struct spi_device *spi,
|
2018-07-28 08:19:13 +00:00
|
|
|
unsigned nsecs, u32 word, u8 bits, unsigned flags)
|
2010-06-30 20:27:37 +00:00
|
|
|
{
|
2023-08-07 12:40:56 +00:00
|
|
|
flags = spi->controller->flags;
|
2022-02-19 13:15:48 +00:00
|
|
|
if (unlikely(spi->mode & SPI_LSB_FIRST))
|
|
|
|
return bitbang_txrx_le_cpha1(spi, nsecs, 1, flags, word, bits);
|
|
|
|
else
|
|
|
|
return bitbang_txrx_be_cpha1(spi, nsecs, 1, flags, word, bits);
|
2010-06-30 20:27:37 +00:00
|
|
|
}
|
|
|
|
|
2009-01-06 22:41:41 +00:00
|
|
|
/*----------------------------------------------------------------------*/
|
|
|
|
|
|
|
|
static void spi_gpio_chipselect(struct spi_device *spi, int is_active)
|
|
|
|
{
|
2012-09-05 09:04:35 +00:00
|
|
|
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
|
2009-01-06 22:41:41 +00:00
|
|
|
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
/* set initial clock line level */
|
2009-01-06 22:41:41 +00:00
|
|
|
if (is_active)
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
gpiod_set_value_cansleep(spi_gpio->sck, spi->mode & SPI_CPOL);
|
|
|
|
|
|
|
|
/* Drive chip select line, if we have one */
|
2019-04-03 04:01:27 +00:00
|
|
|
if (spi_gpio->cs_gpios) {
|
2023-03-10 17:32:03 +00:00
|
|
|
struct gpio_desc *cs = spi_gpio->cs_gpios[spi_get_chipselect(spi, 0)];
|
2009-01-06 22:41:41 +00:00
|
|
|
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
/* SPI chip selects are normally active-low */
|
|
|
|
gpiod_set_value_cansleep(cs, (spi->mode & SPI_CS_HIGH) ? is_active : !is_active);
|
2009-04-02 23:57:07 +00:00
|
|
|
}
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
2024-07-12 19:21:23 +00:00
|
|
|
static void spi_gpio_set_mosi_idle(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
|
|
|
|
|
|
|
|
gpiod_set_value_cansleep(spi_gpio->mosi,
|
|
|
|
!!(spi->mode & SPI_MOSI_IDLE_HIGH));
|
|
|
|
}
|
|
|
|
|
2009-01-06 22:41:41 +00:00
|
|
|
static int spi_gpio_setup(struct spi_device *spi)
|
|
|
|
{
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
struct gpio_desc *cs;
|
2012-09-05 09:04:35 +00:00
|
|
|
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
|
2024-05-17 19:42:02 +00:00
|
|
|
int ret;
|
2012-09-05 09:04:36 +00:00
|
|
|
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
/*
|
|
|
|
* The CS GPIOs have already been
|
|
|
|
* initialized from the descriptor lookup.
|
|
|
|
*/
|
2019-04-03 04:01:27 +00:00
|
|
|
if (spi_gpio->cs_gpios) {
|
2023-03-10 17:32:03 +00:00
|
|
|
cs = spi_gpio->cs_gpios[spi_get_chipselect(spi, 0)];
|
2024-05-17 19:42:02 +00:00
|
|
|
if (!spi->controller_state && cs) {
|
|
|
|
ret = gpiod_direction_output(cs, !(spi->mode & SPI_CS_HIGH));
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2019-04-03 04:01:27 +00:00
|
|
|
}
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
|
2024-05-17 19:42:02 +00:00
|
|
|
return spi_bitbang_setup(spi);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
2018-07-28 08:19:14 +00:00
|
|
|
static int spi_gpio_set_direction(struct spi_device *spi, bool output)
|
|
|
|
{
|
|
|
|
struct spi_gpio *spi_gpio = spi_to_spi_gpio(spi);
|
2018-11-01 21:25:04 +00:00
|
|
|
int ret;
|
2018-07-28 08:19:14 +00:00
|
|
|
|
|
|
|
if (output)
|
|
|
|
return gpiod_direction_output(spi_gpio->mosi, 1);
|
2018-11-01 21:25:04 +00:00
|
|
|
|
2022-12-07 23:08:53 +00:00
|
|
|
/*
|
|
|
|
* Only change MOSI to an input if using 3WIRE mode.
|
|
|
|
* Otherwise, MOSI could be left floating if there is
|
|
|
|
* no pull resistor connected to the I/O pin, or could
|
|
|
|
* be left logic high if there is a pull-up. Transmitting
|
|
|
|
* logic high when only clocking MISO data in can put some
|
|
|
|
* SPI devices in to a bad state.
|
|
|
|
*/
|
|
|
|
if (spi->mode & SPI_3WIRE) {
|
|
|
|
ret = gpiod_direction_input(spi_gpio->mosi);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2018-11-01 21:25:04 +00:00
|
|
|
/*
|
|
|
|
* Send a turnaround high impedance cycle when switching
|
|
|
|
* from output to input. Theoretically there should be
|
|
|
|
* a clock delay here, but as has been noted above, the
|
|
|
|
* nsec delay function for bit-banged GPIO is simply
|
|
|
|
* {} because bit-banging just doesn't get fast enough
|
|
|
|
* anyway.
|
|
|
|
*/
|
|
|
|
if (spi->mode & SPI_3WIRE_HIZ) {
|
|
|
|
gpiod_set_value_cansleep(spi_gpio->sck,
|
|
|
|
!(spi->mode & SPI_CPOL));
|
|
|
|
gpiod_set_value_cansleep(spi_gpio->sck,
|
|
|
|
!!(spi->mode & SPI_CPOL));
|
|
|
|
}
|
|
|
|
return 0;
|
2018-07-28 08:19:14 +00:00
|
|
|
}
|
|
|
|
|
2009-01-06 22:41:41 +00:00
|
|
|
static void spi_gpio_cleanup(struct spi_device *spi)
|
|
|
|
{
|
|
|
|
spi_bitbang_cleanup(spi);
|
|
|
|
}
|
|
|
|
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
/*
|
|
|
|
* 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
|
2023-08-07 12:40:56 +00:00
|
|
|
* drivers expect to see all-ones data as the no target "response".)
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
*/
|
2019-04-03 04:01:29 +00:00
|
|
|
static int spi_gpio_request(struct device *dev, struct spi_gpio *spi_gpio)
|
2009-01-06 22:41:41 +00:00
|
|
|
{
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
spi_gpio->mosi = devm_gpiod_get_optional(dev, "mosi", GPIOD_OUT_LOW);
|
|
|
|
if (IS_ERR(spi_gpio->mosi))
|
|
|
|
return PTR_ERR(spi_gpio->mosi);
|
2009-01-06 22:41:41 +00:00
|
|
|
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
spi_gpio->miso = devm_gpiod_get_optional(dev, "miso", GPIOD_IN);
|
|
|
|
if (IS_ERR(spi_gpio->miso))
|
|
|
|
return PTR_ERR(spi_gpio->miso);
|
2009-01-06 22:41:41 +00:00
|
|
|
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
spi_gpio->sck = devm_gpiod_get(dev, "sck", GPIOD_OUT_LOW);
|
2019-09-07 11:51:16 +00:00
|
|
|
return PTR_ERR_OR_ZERO(spi_gpio->sck);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
2019-04-03 04:01:27 +00:00
|
|
|
static int spi_gpio_probe_pdata(struct platform_device *pdev,
|
2023-08-07 12:40:56 +00:00
|
|
|
struct spi_controller *host)
|
2019-04-03 04:01:27 +00:00
|
|
|
{
|
|
|
|
struct device *dev = &pdev->dev;
|
|
|
|
struct spi_gpio_platform_data *pdata = dev_get_platdata(dev);
|
2023-08-07 12:40:56 +00:00
|
|
|
struct spi_gpio *spi_gpio = spi_controller_get_devdata(host);
|
2019-04-03 04:01:27 +00:00
|
|
|
int i;
|
2012-09-05 09:04:36 +00:00
|
|
|
|
2019-04-03 04:01:27 +00:00
|
|
|
#ifdef GENERIC_BITBANG
|
|
|
|
if (!pdata || !pdata->num_chipselect)
|
|
|
|
return -ENODEV;
|
|
|
|
#endif
|
|
|
|
/*
|
2023-08-07 12:40:56 +00:00
|
|
|
* The host needs to think there is a chipselect even if not
|
2019-04-03 04:01:27 +00:00
|
|
|
* connected
|
|
|
|
*/
|
2023-08-07 12:40:56 +00:00
|
|
|
host->num_chipselect = pdata->num_chipselect ?: 1;
|
2012-09-05 09:04:36 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
spi_gpio->cs_gpios = devm_kcalloc(dev, host->num_chipselect,
|
2019-04-03 04:01:27 +00:00
|
|
|
sizeof(*spi_gpio->cs_gpios),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!spi_gpio->cs_gpios)
|
|
|
|
return -ENOMEM;
|
2012-09-05 09:04:36 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
for (i = 0; i < host->num_chipselect; i++) {
|
2019-04-03 04:01:27 +00:00
|
|
|
spi_gpio->cs_gpios[i] = devm_gpiod_get_index(dev, "cs", i,
|
|
|
|
GPIOD_OUT_HIGH);
|
|
|
|
if (IS_ERR(spi_gpio->cs_gpios[i]))
|
|
|
|
return PTR_ERR(spi_gpio->cs_gpios[i]);
|
|
|
|
}
|
2012-09-05 09:04:36 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-12-07 16:57:14 +00:00
|
|
|
static int spi_gpio_probe(struct platform_device *pdev)
|
2009-01-06 22:41:41 +00:00
|
|
|
{
|
|
|
|
int status;
|
2023-08-07 12:40:56 +00:00
|
|
|
struct spi_controller *host;
|
2009-01-06 22:41:41 +00:00
|
|
|
struct spi_gpio *spi_gpio;
|
2019-04-03 04:01:23 +00:00
|
|
|
struct device *dev = &pdev->dev;
|
2024-05-17 19:42:01 +00:00
|
|
|
struct fwnode_handle *fwnode = dev_fwnode(dev);
|
2019-04-03 04:01:24 +00:00
|
|
|
struct spi_bitbang *bb;
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
host = devm_spi_alloc_host(dev, sizeof(*spi_gpio));
|
|
|
|
if (!host)
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
return -ENOMEM;
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2024-05-17 19:42:01 +00:00
|
|
|
if (fwnode) {
|
|
|
|
device_set_node(&host->dev, fwnode);
|
|
|
|
host->use_gpio_descriptors = true;
|
|
|
|
} else {
|
2023-08-07 12:40:56 +00:00
|
|
|
status = spi_gpio_probe_pdata(pdev, host);
|
2024-05-17 19:42:01 +00:00
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
}
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
spi_gpio = spi_controller_get_devdata(host);
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2019-04-03 04:01:29 +00:00
|
|
|
status = spi_gpio_request(dev, spi_gpio);
|
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>
2018-02-12 12:45:30 +00:00
|
|
|
if (status)
|
|
|
|
return status;
|
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
host->bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 32);
|
|
|
|
host->mode_bits = SPI_3WIRE | SPI_3WIRE_HIZ | SPI_CPHA | SPI_CPOL |
|
2024-07-12 19:21:23 +00:00
|
|
|
SPI_CS_HIGH | SPI_LSB_FIRST | SPI_MOSI_IDLE_LOW |
|
|
|
|
SPI_MOSI_IDLE_HIGH;
|
2019-04-03 04:01:29 +00:00
|
|
|
if (!spi_gpio->mosi) {
|
|
|
|
/* HW configuration without MOSI pin
|
|
|
|
*
|
2023-07-10 15:49:28 +00:00
|
|
|
* No setting SPI_CONTROLLER_NO_RX here - if there is only
|
2019-04-03 04:01:29 +00:00
|
|
|
* a MOSI pin connected the host can still do RX by
|
|
|
|
* changing the direction of the line.
|
|
|
|
*/
|
2023-08-07 12:40:56 +00:00
|
|
|
host->flags = SPI_CONTROLLER_NO_TX;
|
2019-04-03 04:01:29 +00:00
|
|
|
}
|
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
host->bus_num = pdev->id;
|
|
|
|
host->setup = spi_gpio_setup;
|
|
|
|
host->cleanup = spi_gpio_cleanup;
|
2019-04-03 04:01:27 +00:00
|
|
|
|
2019-04-03 04:01:24 +00:00
|
|
|
bb = &spi_gpio->bitbang;
|
2024-02-07 18:40:30 +00:00
|
|
|
bb->ctlr = host;
|
2019-07-16 20:46:51 +00:00
|
|
|
/*
|
|
|
|
* There is some additional business, apart from driving the CS GPIO
|
|
|
|
* line, that we need to do on selection. This makes the local
|
|
|
|
* callback for chipselect always get called.
|
|
|
|
*/
|
2023-08-07 12:40:56 +00:00
|
|
|
host->flags |= SPI_CONTROLLER_GPIO_SS;
|
2019-04-03 04:01:24 +00:00
|
|
|
bb->chipselect = spi_gpio_chipselect;
|
|
|
|
bb->set_line_direction = spi_gpio_set_direction;
|
2024-07-12 19:21:23 +00:00
|
|
|
bb->set_mosi_idle = spi_gpio_set_mosi_idle;
|
2010-06-30 20:27:37 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
if (host->flags & SPI_CONTROLLER_NO_TX) {
|
2019-04-03 04:01:24 +00:00
|
|
|
bb->txrx_word[SPI_MODE_0] = spi_gpio_spec_txrx_word_mode0;
|
|
|
|
bb->txrx_word[SPI_MODE_1] = spi_gpio_spec_txrx_word_mode1;
|
|
|
|
bb->txrx_word[SPI_MODE_2] = spi_gpio_spec_txrx_word_mode2;
|
|
|
|
bb->txrx_word[SPI_MODE_3] = spi_gpio_spec_txrx_word_mode3;
|
2019-04-03 04:01:25 +00:00
|
|
|
} else {
|
|
|
|
bb->txrx_word[SPI_MODE_0] = spi_gpio_txrx_word_mode0;
|
|
|
|
bb->txrx_word[SPI_MODE_1] = spi_gpio_txrx_word_mode1;
|
|
|
|
bb->txrx_word[SPI_MODE_2] = spi_gpio_txrx_word_mode2;
|
|
|
|
bb->txrx_word[SPI_MODE_3] = spi_gpio_txrx_word_mode3;
|
2010-06-30 20:27:37 +00:00
|
|
|
}
|
2019-04-03 04:01:24 +00:00
|
|
|
bb->setup_transfer = spi_bitbang_setup_transfer;
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2019-04-03 04:01:33 +00:00
|
|
|
status = spi_bitbang_init(&spi_gpio->bitbang);
|
|
|
|
if (status)
|
|
|
|
return status;
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
return devm_spi_register_controller(&pdev->dev, host);
|
2009-01-06 22:41:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
MODULE_ALIAS("platform:" DRIVER_NAME);
|
|
|
|
|
2024-05-17 19:42:01 +00:00
|
|
|
static const struct of_device_id spi_gpio_dt_ids[] = {
|
|
|
|
{ .compatible = "spi-gpio" },
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(of, spi_gpio_dt_ids);
|
|
|
|
|
2009-01-06 22:41:41 +00:00
|
|
|
static struct platform_driver spi_gpio_driver = {
|
2012-09-05 09:04:36 +00:00
|
|
|
.driver = {
|
|
|
|
.name = DRIVER_NAME,
|
2024-05-17 19:42:01 +00:00
|
|
|
.of_match_table = spi_gpio_dt_ids,
|
2012-09-05 09:04:36 +00:00
|
|
|
},
|
2011-10-05 17:29:49 +00:00
|
|
|
.probe = spi_gpio_probe,
|
2009-01-06 22:41:41 +00:00
|
|
|
};
|
2011-10-05 17:29:49 +00:00
|
|
|
module_platform_driver(spi_gpio_driver);
|
2009-01-06 22:41:41 +00:00
|
|
|
|
2023-08-07 12:40:56 +00:00
|
|
|
MODULE_DESCRIPTION("SPI host driver using generic bitbanged GPIO ");
|
2009-01-06 22:41:41 +00:00
|
|
|
MODULE_AUTHOR("David Brownell");
|
|
|
|
MODULE_LICENSE("GPL");
|