1. 09 5月, 2018 1 次提交
  2. 24 3月, 2018 1 次提交
  3. 23 3月, 2018 21 次提交
  4. 15 2月, 2018 1 次提交
    • L
      spi: spi-gpio: Rewrite to use GPIO descriptors · 9b00bc7b
      Linus Walleij 提交于
      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: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      9b00bc7b
  5. 03 1月, 2018 1 次提交
  6. 02 1月, 2018 14 次提交
  7. 18 12月, 2017 1 次提交