• Linus Walleij's avatar
    i2c: gpio: Convert to use descriptors · b2e63555
    Linus Walleij authored
    This converts the GPIO-based I2C-driver to using GPIO
    descriptors instead of the old global numberspace-based
    GPIO interface. We:
    - Convert the driver to unconditionally grab two GPIOs
      from the device by index 0 (SDA) and 1 (SCL) which
      will work fine with device tree and descriptor tables.
      The existing device trees will continue to work just
      like before, but without any roundtrip through the
      global numberspace.
    - Brutally convert all boardfiles still passing global
      GPIOs by registering descriptor tables associated with
      the devices instead so this driver does not need to keep
      supporting passing any GPIO numbers as platform data.
    There is no stepwise approach as elegant as this, I
    strongly prefer this big hammer over any antsteps for this
    conversion. This way the old GPIO numbers go away and
    Special conversion for the different boards utilizing
    - EP93xx (arch/arm/mach-ep93xx): pretty straight forward as
      all boards were using the same two GPIO lines, just define
      these two in a lookup table for "i2c-gpio" and register
      these along with the device. None of them define any
      other platform data so just pass NULL as platform data.
      This platform selects GPIOLIB so all should be smooth.
      The pins appear on a gpiochip for bank "G" as pins 1 (SDA)
      and 0 (SCL).
    - IXP4 (arch/arm/mach-ixp4): descriptor tables have to
      be registered for each board separately. They all use
      "IXP4XX_GPIO_CHIP" so it is pretty straight forward.
      Most board define no other platform data than SCL/SDA
      so they can drop the #include of <linux/i2c-gpio.h> and
      assign NULL to platform data.
      The "goramo_mlr" (Goramo Multilink Router) board is a bit
      worrisome: it implements its own I2C bit-banging in the
      board file, and optionally registers an I2C serial port,
      but claims the same GPIO lines for itself in the board file.
      This is not going to work: there will be competition for the
      GPIO lines, so delete the optional extra I2C bus instead, no
      I2C devices are registered on it anyway, there are just hints
      that it may contain an EEPROM that may be accessed from
      userspace. This needs to be fixed up properly by the serial
      clock using I2C emulation so drop a note in the code.
    - KS8695 board acs5k (arch/arm/mach-ks8695/board-acs5.c)
      has some platform data in addition to the pins so it needs to
      be kept around sans GPIO lines. Its GPIO chip is named
      "KS8695" and the arch selects GPIOLIB.
    - PXA boards (arch/arm/mach-pxa/*) use some of the platform
      data so it needs to be preserved here. The viper board even
      registers two GPIO I2Cs. The gpiochip is named "gpio-pxa" and
      the arch selects GPIOLIB.
    - SA1100 Simpad (arch/arm/mach-sa1100/simpad.c) defines a GPIO
      I2C bus, and the arch selects GPIOLIB.
    - Blackfin boards (arch/blackfin/bf533 etc) for these I assume
      their I2C GPIOs refer to the local gpiochip defined in
      arch/blackfin/kernel/bfin_gpio.c names "BFIN-GPIO".
      The arch selects GPIOLIB. The boards get spiked with
      IF_ENABLED(I2C_GPIO) but that is a side effect of it
      being like that already (I would just have Kconfig select
      I2C_GPIO and get rid of them all.) I also delete any
      platform data set to 0 as it will get that value anyway
      from static declartions of platform data.
    - The MIPS selects GPIOLIB and the Alchemy machine is using
      two local GPIO chips, one of them has a GPIO I2C. We need
      to adjust the local offset from the global number space here.
      The ATH79 has a proper GPIO driver in drivers/gpio/gpio-ath79.c
      and AFAICT the chip is named "ath79-gpio" and the PB44
      PCF857x expander spawns from this on GPIO 1 and 0. The latter
      board only use the platform data to specify pins so it can be
      cut altogether after this.
    - The MFD Silicon Motion SM501 is a special case. It dynamically
      spawns an I2C bus off the MFD using sm501_create_subdev().
      We use an approach to dynamically create a machine descriptor
      table and attach this to the "SM501-LOW" or "SM501-HIGH"
      gpiochip. We use chip-local offsets to grab the right lines.
      We can get rid of two local static inline helpers as part
      of this refactoring.
    Cc: Steven Miao <realmz6@gmail.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Cc: Magnus Damm <magnus.damm@gmail.com>
    Cc: Ben Dooks <ben.dooks@codethink.co.uk>
    Cc: Heiko Schocher <hs@denx.de>
    Acked-by: default avatarWu, Aaron <Aaron.Wu@analog.com>
    Acked-by: default avatarOlof Johansson <olof@lixom.net>
    Acked-by: default avatarLee Jones <lee.jones@linaro.org>
    Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
Last commit
Last update
include/mach Loading commit data...
Kconfig Loading commit data...
Makefile Loading commit data...
Makefile.boot Loading commit data...
assabet.c Loading commit data...
badge4.c Loading commit data...
cerf.c Loading commit data...
clock.c Loading commit data...
collie.c Loading commit data...
generic.c Loading commit data...
generic.h Loading commit data...
h3100.c Loading commit data...
h3600.c Loading commit data...
h3xxx.c Loading commit data...
hackkit.c Loading commit data...
jornada720.c Loading commit data...
jornada720_ssp.c Loading commit data...
lart.c Loading commit data...
nanoengine.c Loading commit data...
neponset.c Loading commit data...
pci-nanoengine.c Loading commit data...
pleb.c Loading commit data...
pm.c Loading commit data...
shannon.c Loading commit data...
simpad.c Loading commit data...
sleep.S Loading commit data...
ssp.c Loading commit data...