mbox series

[v5,0/8] RTL8231 GPIO expander support

Message ID cover.1623532208.git.sander@svanheule.net
Headers show
Series RTL8231 GPIO expander support | expand

Message

Sander Vanheule June 12, 2021, 9:12 p.m. UTC
The RTL8231 GPIO and LED expander can be configured for use as an MDIO or SMI
bus device. Currently only the MDIO mode is supported, although SMI mode
support should be fairly straightforward, once an SMI bus driver is available.

Provided features by the RTL8231:
  - Up to 37 GPIOs
    - Configurable drive strength: 8mA or 4mA (currently unsupported)
    - Input debouncing on GPIOs 31-36
  - Up to 88 LEDs in multiple scan matrix groups
    - On, off, or one of six toggling intervals
    - "single-color mode": 2×36 single color LEDs + 8 bi-color LEDs
    - "bi-color mode": (12 + 2×6) bi-color LEDs + 24 single color LEDs
  - Up to one PWM output (currently unsupported)
    - Fixed duty cycle, 8 selectable frequencies (1.2kHz - 4.8kHz)

The GPIO controller uses gpio-regmap. To support the aliased data input and
output registers, the regmap interface is extended to supported atomic,
uncached register reads. This is then used with a new quirk for gpio-regmap.

Register access is provided through a new MDIO regmap provider. The required
MDIO regmap support was merged in Mark Brown's regmap repository, and can be
found under the regmap-mdio tag:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git/tag/?h=regmap-mdio

---
Another revision of this patch series, now without (virtual) register paging.
After a few other (failed) attemps, I added a call to the regmap interface to
perform atomic, uncached register reads. Combined with the appropriate caching
of the register values, this can provide a split view of the data registers for
gpio-regmap. See patches 1/7 and 2/7.

These additions allowed the MFD core driver to be a bit less complex. The GPIO
support didn't see significant changes, so I've kept the review tags. The
bindings and LED driver are unchanged.

With this patch series (hopefully) nearing its final form, I was wondering if
this could be merged via the MFD tree, when all the necessary reviews and/or
acks are present. Would that be OK for everyone?

Changes since v4:
  - List myself as maintainer for this chip
  - Add uncached register reads to regmap; replaces virtual registers
Link: https://lore.kernel.org/lkml/cover.1622713678.git.sander@svanheule.net/

Changes since v3:
  - Drop gpio-regmap direction-before-value quirk
  - Use secondary virtual register range to enable proper read-modify-write
    behaviour on GPIO output values
  - Add pin debounce support
  - Switch to generic pinmux functions

Changes since v2:
  - MDIO regmap support was merged, so patch is dropped here
  - Implement feedback for DT bindings
  - Use correct module names in Kconfigs
  - Fix k*alloc return value checks
  - Introduce GPIO regmap quirks to set output direction first
  - pinctrl: Use static pin descriptions for pin controller
  - pinctrl: Fix gpio consumer resource leak
  - mfd: Replace CONFIG_PM-ifdef'ery
  - leds: Rename interval to interval_ms

Changes since v1:
  - Reintroduce MDIO regmap, with fixed Kconfig dependencies
  - Add configurable dir/value order for gpio-regmap direction_out call
  - Drop allocations for regmap fields that are used only on init
  - Move some definitions to MFD header
  - Add PM ops to replace driver remove for MFD
  - Change pinctrl driver to (modified) gpio-regmap
  - Change leds driver to use fwnode

Changes since RFC:
  - Dropped MDIO regmap interface. I was unable to resolve the Kconfig
    dependency issue, so have reverted to using regmap_config.reg_read/write.
  - Added pinctrl support
  - Added LED support
  - Changed root device to MFD, with pinctrl and leds child devices. Root
    device is now an mdio_device driver.

Sander Vanheule (8):
  regmap: Support atomic forced uncached reads
  gpio: regmap: Add quirk for aliased data registers
  dt-bindings: leds: Binding for RTL8231 scan matrix
  dt-bindings: mfd: Binding for RTL8231
  mfd: Add RTL8231 core device
  pinctrl: Add RTL8231 pin control and GPIO support
  leds: Add support for RTL8231 LED scan matrix
  MAINTAINERS: Add RTL8231 MFD driver

 .../bindings/leds/realtek,rtl8231-leds.yaml   | 166 +++++++
 .../bindings/mfd/realtek,rtl8231.yaml         | 190 ++++++++
 MAINTAINERS                                   |  10 +
 drivers/base/regmap/regmap.c                  |  33 ++
 drivers/gpio/gpio-regmap.c                    |   7 +-
 drivers/leds/Kconfig                          |  10 +
 drivers/leds/Makefile                         |   1 +
 drivers/leds/leds-rtl8231.c                   | 291 ++++++++++++
 drivers/mfd/Kconfig                           |   9 +
 drivers/mfd/Makefile                          |   1 +
 drivers/mfd/rtl8231.c                         | 186 ++++++++
 drivers/pinctrl/Kconfig                       |  11 +
 drivers/pinctrl/Makefile                      |   1 +
 drivers/pinctrl/pinctrl-rtl8231.c             | 438 ++++++++++++++++++
 include/linux/gpio/regmap.h                   |  13 +
 include/linux/mfd/rtl8231.h                   |  71 +++
 include/linux/regmap.h                        |   8 +
 17 files changed, 1445 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/leds/realtek,rtl8231-leds.yaml
 create mode 100644 Documentation/devicetree/bindings/mfd/realtek,rtl8231.yaml
 create mode 100644 drivers/leds/leds-rtl8231.c
 create mode 100644 drivers/mfd/rtl8231.c
 create mode 100644 drivers/pinctrl/pinctrl-rtl8231.c
 create mode 100644 include/linux/mfd/rtl8231.h

Comments

Mark Brown June 14, 2021, 10:33 a.m. UTC | #1
On Sat, Jun 12, 2021 at 11:12:31PM +0200, Sander Vanheule wrote:

> When a user wants to read a single uncached register, cache bypassing

> can be enabled. However, this is not atomic unless an external lock is

> used for the regmap. When using regcache_cache_bypass, the original

> bypass state also cannot be restored.


> Add support to atomically read a single uncached value, bypassing any

> regmap cache.


The expectation here is that if there is a need to do this for some
reason the user can arrange to do this for itself - if something is
happening that makes a normally non-volatile register volatile then 
it probably needs higher level coordination.  What's the use case?

> +int regmap_read_bypassed(struct regmap *map, unsigned int reg, unsigned int *val)


Bypassed what?  I think Andy's naming suggestion was much better.

Please also keep to 80 columns if you can, I know the requirements got
relaxed a bit but no need to do it excessively.