1. 19 10月, 2017 1 次提交
    • L
      pinctrl: adi2: Fix Kconfig build problem · 1c363531
      Linus Walleij 提交于
      The build robot is complaining on Blackfin:
      
      drivers/pinctrl/pinctrl-adi2.c: In function 'port_setup':
      >> drivers/pinctrl/pinctrl-adi2.c:221:21: error: dereferencing
         pointer to incomplete type 'struct gpio_port_t'
            writew(readw(&regs->port_fer) & ~BIT(offset),
                              ^~
      drivers/pinctrl/pinctrl-adi2.c: In function 'adi_gpio_ack_irq':
      >> drivers/pinctrl/pinctrl-adi2.c:266:18: error: dereferencing
      pointer to incomplete type 'struct bfin_pint_regs'
            if (readl(&regs->invert_set) & pintbit)
                           ^~
      It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
      to compile.
      
      The Blackfin architecture was re-defining the Kconfig
      PINCTRL symbol which is not OK, so replaced this with
      PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
      just like most arches do.
      
      Further, the old GPIO driver symbol GPIO_ADI was possible to
      select at the same time as selecting PINCTRL. This was not
      working because the arch-local <asm/gpio.h> header contains
      an explicit #ifndef PINCTRL clause making compilation break
      if you combine them. The same is true for DEBUG_MMRS.
      
      Make sure the ADI2 pinctrl driver is not selected at the same
      time as the old GPIO implementation. (This should be converted
      to use gpiolib or pincontrol and move to drivers/...) Also make
      sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
      the same time as the new PINCTRL implementation, and only make
      PINCTRL_ADI2 selectable for the Blackfin families that actually
      have it.
      
      This way it is still possible to add e.g. I2C-based pin
      control expanders on the Blackfin.
      
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Huanhuan Feng <huanhuan.feng@analog.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      1c363531
  2. 17 10月, 2017 1 次提交
  3. 12 10月, 2017 1 次提交
  4. 11 10月, 2017 1 次提交
  5. 31 8月, 2017 1 次提交
  6. 21 8月, 2017 1 次提交
  7. 14 8月, 2017 1 次提交
  8. 23 6月, 2017 1 次提交
  9. 31 5月, 2017 1 次提交
    • A
      pinctrl: mcp23s08: improve I2C Kconfig dependency · adeac775
      Arnd Bergmann 提交于
      With "SPI_MASTER=y && I2C=m", we can build mcp23s08 as a built-in driver,
      which then results in a link failure:
      
      drivers/pinctrl/built-in.o: In function `mcp23s08_probe_one.isra.0':
      :(.text+0x7910): undefined reference to `__devm_regmap_init_i2c'
      drivers/pinctrl/built-in.o: In function `mcp23s08_init':
      :(.init.text+0x110): undefined reference to `i2c_register_driver'
      drivers/pinctrl/built-in.o: In function `mcp23s08_exit':
      :(.exit.text+0x3c): undefined reference to `i2c_del_driver'
      
      To avoid the problem, this adds another dependency on I2C that enforces
      mcp23s08 to be a loadable module whenever the I2C core is a module.
      
      Fixes: 64ac43e6 ("gpio: mcp23s08: move to pinctrl")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NSebastian Reichel <sebastian.reichel@collabora.co.uk>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      adeac775
  10. 29 5月, 2017 1 次提交
  11. 23 5月, 2017 3 次提交
  12. 22 5月, 2017 2 次提交
    • P
      pinctrl: add a pinctrl driver for the Ingenic jz47xx SoCs · b5c23aa4
      Paul Cercueil 提交于
      This driver handles pin configuration and pin muxing for the
      JZ4740 and JZ4780 SoCs from Ingenic.
      Signed-off-by: NPaul Cercueil <paul@crapouillou.net>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      b5c23aa4
    • S
      pinctrl: add ZTE ZX pinctrl driver support · cbff0c4d
      Shawn Guo 提交于
      The pin controller on ZTE ZX platforms is kinda of hybrid.  It consists
      of a main controller and an auxiliary one.  For example, on ZX296718 SoC,
      the main controller is TOP_PMM and the auxiliary one is AON_IOCFG.  Both
      controllers work together to control pin multiplexing and configuration.
      
      For most of pins, the pinmux function is controlled by main controller
      only, and this type of pins are meant by term 'TOP pins'.  For other
      pins, the pinmux is controlled by both main and auxiliary controllers,
      as the available multiplexing functions for the pin spread in both
      controllers.  This type of pins are called 'AON pins'.  Though pinmux
      implementation is quite different, pinconf is same for both types of
      pins.  Both are controlled by auxiliary controller, i.e. AON_IOCFG on
      ZX296718.
      
      The patch adds the ZTE ZX core pinctrl driver to support this hybrid
      pin controller as well as ZX296718 SoC specific pin data.
      Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      cbff0c4d
  13. 07 4月, 2017 1 次提交
  14. 10 1月, 2017 1 次提交
    • N
      pinctrl: Introduce TI IOdelay configuration driver · 003910eb
      Nishanth Menon 提交于
      SoC family such as DRA7 family of processors have, in addition
      to the regular muxing of pins (as done by pinctrl-single), a separate
      hardware module called IODelay which is also expected to be configured.
      The "IODelay" module has it's own register space that is independent
      of the control module and the padconf register area.
      
      With recent changes to the pinctrl framework, we can now support
      this hardware with a reasonably minimal driver by using #pinctrl-cells,
      GENERIC_PINCTRL_GROUPS and GENERIC_PINMUX_FUNCTIONS.
      
      It is advocated strongly in TI's official documentation considering
      the existing design of the DRA7 family of processors during mux or
      IODelay reconfiguration, there is a potential for a significant glitch
      which may cause functional impairment to certain hardware. It is
      hence recommended to do as little of muxing as absolutely necessary
      without I/O isolation (which can only be done in initial stages of
      bootloader).
      
      NOTE: with the system wide I/O isolation scheme present in DRA7 SoC
      family, it is not reasonable to do stop all I/O operations for every
      such pad configuration scheme. So, we will let it glitch when used in
      this mode.
      
      Even with the above limitation, certain functionality such as MMC has
      mandatory need for IODelay reconfiguration requirements, depending on
      speed of transfer. In these cases, with careful examination of usecase
      involved, the expected glitch can be controlled such that it does not
      impact functionality.
      
      In short, IODelay module support as a padconf driver being introduced
      here is not expected to do SoC wide I/O Isolation and is meant for
      a limited subset of IODelay configuration requirements that need to
      be dynamic and whose glitchy behavior will not cause functionality
      failure for that interface.
      
      IMPORTANT NOTE: we take the approach of keeping LOCK_BITs cleared
      to 0x0 at all times, even when configuring Manual IO Timing Modes.
      This is done by eliminating the LOCK_BIT=1 setting from Step
      of the Manual IO timing Mode configuration procedure. This option
      leaves the CFG_* registers unprotected from unintended writes to the
      CTRL_CORE_PAD_* registers while Manual IO Timing Modes are configured.
      
      This approach is taken to allow for a generic driver to exist in kernel
      world that has to be used carefully in required usecases.
      Signed-off-by: NNishanth Menon <nm@ti.com>
      Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
      [tony@atomide.com: updated to use generic pinctrl functions, added
       binding documentation, updated comments]
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      003910eb
  15. 03 1月, 2017 5 次提交
  16. 07 12月, 2016 1 次提交
  17. 08 11月, 2016 1 次提交
  18. 29 10月, 2016 1 次提交
    • A
      pinctrl: max77620: add OF dependency · 24d6a91c
      Arnd Bergmann 提交于
      Drivers using pinconf_generic_params tables cannot be built with
      CONFIG_OF disabled:
      
      drivers/pinctrl/pinctrl-max77620.c:53:44: error: array type has incomplete element type ‘struct pinconf_generic_params’
      drivers/pinctrl/pinctrl-max77620.c:55:3: error: field name not in record or union initializer
      drivers/pinctrl/pinctrl-max77620.c:55:3: note: (near initialization for ‘max77620_cfg_params’)
      drivers/pinctrl/pinctrl-max77620.c:56:3: error: field name not in record or union initializer
      
      This adds a dependency for max77620 to disallow that configuration.
      
      Alternatively, we could rework the pinctrl infrastructure to make the
      configuration valid for compile-testing.
      
      Cc: Krzysztof Kozlowski <krzk@kernel.org>
      Cc: Lee Jones <lee.jones@linaro.org>
      Fixes: 453943dc8f45 ("mfd: Enable compile testing for max77620 and max77686")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      24d6a91c
  19. 24 10月, 2016 1 次提交
    • N
      pinctrl: Add SX150X GPIO Extender Pinctrl Driver · 9e80f906
      Neil Armstrong 提交于
      Since the I2C sx150x GPIO expander driver uses platform_data to manage
      the pins configurations, rewrite the driver as a pinctrl driver using
      pinconf to get/set pin configurations from DT or debugfs.
      
      The pinctrl driver is functionnally equivalent as the gpio-only driver
      and can use DT for pinconf. The platform_data confirmation is dropped.
      
      This patchset removed the gpio-only driver and selects the Pinctrl driver
      config instead. This patchset also migrates the gpio dt-bindings to pinctrl
      and add the pinctrl optional properties.
      
      The driver was tested with a SX1509 device on a BeagleBone black with
      interrupt support and on an X86_64 machine over an I2C to USB converter.
      
      This is a fixed version that builds and runs on non-OF platforms and on
      arm based OF. The GPIO version is removed and the bindings are also moved
      to the pinctrl bindings.
      
      Changes since v2
       - rebased on v4.9-rc1
       - removed MODULE_DEVICE_TABLE as in upstream bb411e77
         ("gpio: sx150x: fix implicit assumption module.h is present")
      
      Changes since v1
       - Fix Kconfig descriptions on pinctrl and gpio
       - Fix Kconfig dependency
       - Remove oscio support for non-789 devices
       - correct typo in dt bindings
       - remove probe reset for non-789 devices
      
      Changes since RFC
       - Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms
       - No more rely on OF_GPIO config
       - Moved and enhanced bindings to pinctrl bindings
       - Removed gpio-sx150x.c
       - Temporary select PINCTRL_SX150X when GPIO_SX150X
       - Temporary mark GPIO_SX150X as deprecated
      Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
      Tested-by: NPeter Rosin <peda@axentia.se>
      Acked-by: NRob Herring <robh@kernel.org>
      ested-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      9e80f906
  20. 07 9月, 2016 1 次提交
    • A
      pinctrl: Add core support for Aspeed SoCs · 4d3d0e42
      Andrew Jeffery 提交于
      The Aspeed SoCs typically provide more than 200 pins for GPIO and other
      functions. The signal enabled on a pin is determined on a priority
      basis, where a given pin can provide a number of different signal types.
      
      In addition to the priority levels, the Aspeed pin controllers describe
      the signal active on a pin by compound logical expressions involving
      multiple operators, registers and bits. Some difficulty arises as a
      pin's function bit masks for each priority level are frequently not the
      same (i.e. we cannot just flip a bit to change from a high to low
      priority signal), or even in the same register(s). Some configuration
      bits affect multiple pins, while in other cases the signals for a bus
      must each be enabled individually.
      
      Together, these features give rise to some complexity in the
      implementation. A more complete description of the complexities is
      provided in the associated header file.
      
      The patch doesn't implement pinctrl/pinmux/pinconf for any particular
      Aspeed SoC, rather it adds the framework for defining pinmux
      configurations.
      Signed-off-by: NAndrew Jeffery <andrew@aj.id.au>
      Reviewed-by: NJoel Stanley <joel@jms.id.au>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      4d3d0e42
  21. 23 6月, 2016 2 次提交
    • P
      pinctrl: as3722: convert PINCTRL_AS3722 from bool to tristate · 9385f35d
      Paul Gortmaker 提交于
      The Kconfig currently controlling compilation of this code is:
      
      config PINCTRL_AS3722
              bool "Pinctrl and GPIO driver for ams AS3722 PMIC"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      During an audit for non-modular drivers using modular infrastructure
      this driver showed up.
      
      But rather than demodularize it, Laxman indicated that it would be
      prefereable to instead convert the driver option to tristate.
      
      This does that, and confirms that it will compile and modpost as
      such.  However, since I do not have the hardware to confirm that
      no new runtime issues exist when modular, that remains untested.
      
      Cc: Laxman Dewangan <ldewangan@nvidia.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      9385f35d
    • P
      pinctrl: palmas: convert PINCTRL_PALMAS from bool to tristate · 767b8ce3
      Paul Gortmaker 提交于
      The Kconfig currently controlling compilation of this code is:
      
      config PINCTRL_PALMAS
              bool "Pinctrl driver for the PALMAS Series MFD devices"
      
      ...meaning that it currently is not being built as a module by anyone.
      
      During an audit for non-modular drivers using modular infrastructure
      this driver showed up.
      
      But rather than demodularize it, Laxman indicated that it would be
      prefereable to instead convert the driver option to tristate.
      
      This does that, and confirms that it will compile and modpost as
      such.  However, since I do not have the hardware to confirm that
      no new runtime issues exist when modular, that remains untested.
      
      Cc: Laxman Dewangan <ldewangan@nvidia.com>
      Cc: Linus Walleij <linus.walleij@linaro.org>
      Cc: linux-gpio@vger.kernel.org
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      767b8ce3
  22. 15 6月, 2016 1 次提交
    • A
      pinctrl: max77620: select PINMUX · 79f28b9f
      Arnd Bergmann 提交于
      The recently added max77620 driver fails to build when CONFIG_PINMUX
      is not set:
      
      pinctrl/pinctrl-max77620.c:272:21: error: variable 'max77620_pinmux_ops' has initializer but incomplete type
       static const struct pinmux_ops max77620_pinmux_ops = {
                           ^~~~~~~~~~
      pinctrl/pinctrl-max77620.c:273:2: error: unknown field 'get_functions_count' specified in initializer
      
      This adds the Kconfig 'select' statement that was clearly meant
      to be there and is used in all other pinmux drivers.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      79f28b9f
  23. 30 5月, 2016 2 次提交
  24. 16 2月, 2016 1 次提交
  25. 06 2月, 2016 1 次提交
  26. 05 2月, 2016 1 次提交
  27. 27 1月, 2016 1 次提交
  28. 10 12月, 2015 1 次提交
  29. 01 12月, 2015 1 次提交
  30. 17 11月, 2015 1 次提交
  31. 22 9月, 2015 1 次提交