1. 05 Nov, 2017 3 commits
  2. 01 Nov, 2017 7 commits
  3. 30 Oct, 2017 8 commits
    • Claudio Foellmi's avatar
      i2c: omap: Trigger bus recovery in lockup case · 93367bfc
      Claudio Foellmi authored
      A very conservative check for bus activity (to prevent interference
      in multimaster setups) prevented the bus recovery methods from being
      triggered in the case that SDA or SCL was stuck low.
      This defeats the purpose of the recovery mechanism, which was introduced
      for exactly this situation (a slave device keeping SDA pulled down).
      
      Also added a check to make sure SDA is low before attempting recovery.
      If SDA is not stuck low, recovery will not help, so we can skip it.
      
      Note that bus lockups can persist across reboots. The only other options
      are to reset or power cycle the offending slave device, and many i2c
      slaves do not even have a reset pin.
      
      If we see that one of the lines is low for the entire timeout duration,
      we can actually be sure that there is no other master driving the bus.
      It is therefore save for us to attempt a bus recovery.
      Signed-off-by: default avatarClaudio Foellmi <claudio.foellmi@ergon.ch>
      Tested-by: default avatarVignesh R <vigneshr@ti.com>
      Reviewed-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      [wsa: fixed one return code to -EBUSY]
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      93367bfc
    • Linus Walleij's avatar
      i2c: gpio: Add support for named gpios in DT · 05c74778
      Linus Walleij authored
      This adds support for using the "sda" and "scl" GPIOs in
      device tree instead of anonymously using index 0 and 1 of
      the "gpios" property.
      
      We add a helper function to retrieve the GPIO descriptors
      and some explicit error handling since the probe may have
      to be deferred. At least this happened to me when moving
      to using named "sda" and "scl" lines (all of a sudden this
      started to probe before the GPIO driver) so we need to
      gracefully defer probe when we ge -ENOENT in the error
      pointer.
      Suggested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      05c74778
    • Geert Uytterhoeven's avatar
      dt-bindings: i2c: i2c-gpio: Add support for named gpios · 7d29f509
      Geert Uytterhoeven authored
      The current i2c-gpio DT bindings use a single unnamed "gpios" property
      to refer to the SDA and SCL signal lines by index.  This is error-prone
      for the casual DT writer and reviewer, as one has to look up the order
      in the DT bindings.
      
      Fix this by amending the DT bindings to use two separate named gpios
      properties, and deprecate the old unnamed variant.
      
      Take this opportunity to clearly deprecate the "i2c-gpio,sda-open-drain"
      and "i2c-gpio,scl-open-drain" flags as well. The commit describes
      in detail what these flags actually mean, and why they should not be
      used in new device trees.
      
      Cc: devicetree@vger.kernel.org
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      [Augmented to what I and Rob would like]
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      7d29f509
    • Linus Walleij's avatar
      i2c: gpio: Local vars in probe · b9ab0517
      Linus Walleij authored
      By creating local variables for *dev and *np, the code become
      much easier to read, in my opinion.
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b9ab0517
    • Linus Walleij's avatar
      i2c: gpio: Augment all boardfiles to use open drain · 4d0ce62c
      Linus Walleij authored
      We now handle the open drain mode internally in the I2C GPIO
      driver, but we will get warnings from the gpiolib that we
      override the default mode of the line so it becomes open
      drain.
      
      We can fix all in-kernel users by simply passing the right
      flag along in the descriptor table, and we already touched
      all of these files in the series so let's just tidy it up.
      
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Acked-by: default avatarOlof Johansson <olof@lixom.net>
      Acked-by: default avatarLee Jones <lee.jones@linaro.org>
      Acked-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Acked-by: default avatarWu, Aaron <Aaron.Wu@analog.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      4d0ce62c
    • Linus Walleij's avatar
      i2c: gpio: Enforce open drain through gpiolib · 7bb75029
      Linus Walleij authored
      The I2C GPIO bitbang driver currently emulates open drain
      behaviour by implementing what the gpiolib already does:
      not actively driving the line high, instead setting it to
      input.
      
      This makes no sense. Use the new facility in gpiolib to
      request the lines enforced into open drain mode, and let
      the open drain emulation already present in the gpiolib
      kick in and handle this.
      
      As a bonus: if the GPIO driver in the back-end actually
      supports open drain in hardware using the .set_config()
      callback, it will be utilized. That's correct: we never
      used that hardware feature before, instead relying on
      emulating open drain even if the GPIO controller could
      actually handle this for us.
      
      Users will sometimes get messages like this:
      gpio-485 (?): enforced open drain please flag it properly
        in DT/ACPI DSDT/board file
      gpio-486 (?): enforced open drain please flag it properly
        in DT/ACPI DSDT/board file
      i2c-gpio gpio-i2c: using lines 485 (SDA) and 486 (SCL)
      
      Which is completely proper: since the line is used as
      open drain, it should actually be flagged properly with
      e.g.
      
      gpios = <&gpio0 5 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>,
              <&gpio0 6 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
      
      Or similar facilities in board file descriptor tables
      or ACPI DSDT.
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      7bb75029
    • Linus Walleij's avatar
      gpio: Make it possible for consumers to enforce open drain · f926dfc1
      Linus Walleij authored
      Some busses, like I2C, strictly need to have the line handled
      as open drain, i.e. not actively driven high. For this reason
      the i2c-gpio.c bit-banged I2C driver is reimplementing open
      drain handling outside of gpiolib.
      
      This is not very optimal. Instead make it possible for a
      consumer to explcitly express that the line must be handled
      as open drain instead of allowing local hacks papering over
      this issue.
      
      The descriptor tables, whether DT, ACPI or board files, should
      of course have flagged these lines as open drain. E.g.:
      enum gpio_lookup_flags GPIO_OPEN_DRAIN for a board file, or
      gpios = <&foo 42 GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN>; in a
      device tree using <dt-bindings/gpio/gpio.h>
      
      But more often than not, these descriptors are wrong. So
      we need to make it possible for consumers to enforce this
      open drain behaviour.
      
      We now have two new enumerated GPIO descriptor config flags:
      GPIOD_OUT_LOW_OPEN_DRAIN and GPIOD_OUT_HIGH_OPEN_DRAIN
      that will set up the lined enforced as open drain as output
      low or high, using open drain (if the driver supports it)
      or using open drain emulation (setting the line as input
      to drive it high) from the gpiolib core.
      
      Cc: linux-gpio@vger.kernel.org
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      f926dfc1
    • 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
      NEVER COME BACK.
      
      Special conversion for the different boards utilizing
      I2C-GPIO:
      
      - 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>
      Acked-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      b2e63555
  4. 28 Oct, 2017 16 commits
  5. 27 Oct, 2017 6 commits