tree 533b0c9c3d81ed36732c69350139a0ca56d085cb
parent 7928b2cbe55b2a410a0f5c1f154610059c57b1b2
author Linus Walleij <linus.walleij@linaro.org> 1518439530 +0100
committer Mark Brown <broonie@kernel.org> 1518624161 +0000
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlqEXbATHGJyb29uaWVA
 a2VybmVsLm9yZwAKCRAk1otyXVSH0M2tB/0dS74dENHZ/nC42uw6mMyXdDd4Urnr
 jXD6f6gb1kj+AAjgVKFDzaaEtdLH5BABgsIPG2L5C1TjA2ho1t8M3E7aGwbpUB7h
 tiblh3eZDwXf9rsJLniEsJy0CXAjOI+eSvSvFIsIpcqsNtD114YDuWOKAoF4JmMb
 k6B9/S2QBrxFPwF3qqTXytpfrfYxODKaftphUuMN78badPT30o5DshuSJ6qai1mS
 cLoEuF70gJdnWjndaiEg2z/GZSFmKSxmh5DeKOmFMBmj8Sp+reabEsV7XdrPURue
 4V/i9R1D7de3uvtTNehRudlObblGVLgPRV4txYvwv4PbqnAM9ERWXbQP
 =NewD
 -----END PGP SIGNATURE-----

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>