1. 24 Apr, 2017 12 commits
  2. 11 Apr, 2017 2 commits
  3. 10 Apr, 2017 1 commit
  4. 07 Apr, 2017 7 commits
  5. 04 Apr, 2017 1 commit
  6. 30 Mar, 2017 3 commits
    • Geert Uytterhoeven's avatar
      pinctrl: sh-pfc: r8a7795: Add SCIF_CLK support · d14a39ed
      Geert Uytterhoeven authored
      Add pins, groups, and a function for SCIF_CLK on R-Car H3 ES2.0.
      SCIF_CLK is the external clock source for the Baud Rate Generator for
      External Clock (BRG) on (H)SCIF serial ports.
      
      Extracted from a big patch in the BSP by Takeshi Kihara.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Takeshi Kihara <takeshi.kihara.df@renesas.com>
      d14a39ed
    • Geert Uytterhoeven's avatar
      pinctrl: sh-pfc: r8a7795: Add SCIF support · e7ad4d3c
      Geert Uytterhoeven authored
      Add pins, groups, and functions for all SCIF serial ports on R-Car H3
      ES2.0.
      
      Extracted from a big patch in the BSP by Takeshi Kihara.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Takeshi Kihara <takeshi.kihara.df@renesas.com>
      e7ad4d3c
    • Geert Uytterhoeven's avatar
      pinctrl: sh-pfc: r8a7795: Add support for R-Car H3 ES2.0 · b205914c
      Geert Uytterhoeven authored
      The Pin Function Controller module in the R-Car H3 ES2.0 differs from
      ES1.x in many ways.
      
      The goal is twofold:
        1. Support both the ES1.x and ES2.0 SoC revisions in a single binary
           for now,
        2. Make it clear which code supports ES1.x, so it can easily be
           identified and removed later, when production SoCs are deemed
           ubiquitous.
      
      Hence this patch:
        1. Extracts the support for R-Car H3 ES1.x into a separate file, as
           the differences are quite large,
        2. Adds code for detecting the SoC revision at runtime using the new
           soc_device_match() API, and selecting pinctrl tables for the actual
           SoC revision,
        3. Replaces the core register and bitfield definitions by their
           counterparts for R-Car H3 ES2.0.
      
      The addition of pins, groups, and functions for the various on-chip
      devices is left to subsequent patches.
      
      The R-Car H3 ES2.0 register and bitfield definitions were extracted from
      a patch in the BSP by Takeshi Kihara.
      Signed-off-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Cc: Takeshi Kihara <takeshi.kihara.df@renesas.com>
      b205914c
  7. 28 Mar, 2017 11 commits
  8. 24 Mar, 2017 1 commit
  9. 23 Mar, 2017 2 commits
    • Charles Keepax's avatar
      pinctrl: samsung: Use devres version of gpiochip_add_data · f69ae4f5
      Charles Keepax authored
      Use devm_gpiochip_add_data to simplify the error path in
      samsung_gpiolib_register.
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      f69ae4f5
    • Charles Keepax's avatar
      pinctrl: samsung: Register pinctrl before GPIO · 1abd18d1
      Charles Keepax authored
      If we request a GPIO hog, then gpiochip_add_data will attempt
      to request some of its own GPIOs. The driver also uses
      gpiochip_generic_request which means that for any GPIO request to
      succeed the pinctrl needs to be registered. Currently however the
      driver registers the GPIO and then the pinctrl meaning all GPIO hog
      requests will fail, which then in turn causes the whole driver to fail
      probe.
      
      Fix this up by ensuring we register the pinctrl first. This
      does require us to manually set the GPIO base for the
      pinctrl. Fortunately the driver already assigns a fixed GPIO base, in
      samsung_gpiolib_register, and uses the same calculation it does for
      the pin_base. Meaning the two will always be the same and allowing us
      to reuse the pinbase and avoid the issue.
      
      Although currently there are no users of GPIO hogs in mainline
      there are plenty of Samsung based boards that are widely used for
      development purposes of other hardware. Indeed we hit this issue
      whilst attaching some additional hardware to an Arndale system.
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      1abd18d1