Commit 884e0d3d authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'mfd-next-5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd

Pull MFD updates from Lee Jones:
 "Core Frameworks
   - Make better attempt at matching device with the correct OF node
   - Allow batch removal of hierarchical sub-devices

  New Drivers
   - Add STM32 Clocksource driver
   - Add support for Khadas System Control Microcontroller

  Driver Removal
   - Remove unused driver for TI's SMSC ECE1099

  New Device Support
   - Add support for Intel Emmitsburg PCH to Intel LPSS PCI
   - Add support for Intel Tiger Lake PCH-H to Intel LPSS PCI
   - Add support for Dialog DA revision to Dialog DA9063

  New Functionality
   - Add support for AXP803 to be probed by I2C

  Fix-ups
   - Numerous W=1 warning fixes
   - Device Tree changes (stm32-lptimer, gateworks-gsc, khadas,mcu, stmfx, cros-ec, j721e-system-controller)
   - Enabled Regmap 'fast I/O' in stm32-lptimer
   - Change BUG_ON to WARN_ON in arizona-core
   - Remove superfluous code/initialisation (madera, max14577)
   - Trivial formatting/spelling issues (madera-core, madera-i2c, da9055, max77693-private)
   - Switch to of_platform_populate() in sprd-sc27xx-spi
   - Expand out set/get brightness/pwm macros in lm3533-ctrlbank
   - Disable IRQs on suspend in motorola-cpcap
   - Clean-up error handling in intel_soc_pmic_mrfld
   - Ensure correct removal order of sub-devices in madera
   - Many s/HTTP/HTTPS/ link changes
   - Ensure name used with Regmap is unique in syscon

  Bug Fixes
   - Properly 'put' clock on unbind and error in arizona-core
   - Fix revision handling in da9063
   - Fix 'assignment of read-only location' error in kempld-core
   - Avoid using the Regmap API when atomic in rn5t618
   - Redefine volatile register description in rn5t618
   - Use locking to protect event handler in dln2"

* tag 'mfd-next-5.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (76 commits)
  mfd: syscon: Use a unique name with regmap_config
  mfd: Replace HTTP links with HTTPS ones
  mfd: dln2: Run event handler loop under spinlock
  mfd: madera: Improve handling of regulator unbinding
  mfd: mfd-core: Add mechanism for removal of a subset of children
  mfd: intel_soc_pmic_mrfld: Simplify the return expression of intel_scu_ipc_dev_iowrite8()
  mfd: max14577: Remove redundant initialization of variable current_bits
  mfd: rn5t618: Fix caching of battery related registers
  mfd: max77693-private: Drop a duplicated word
  mfd: da9055: pdata.h: Drop a duplicated word
  mfd: rn5t618: Make restart handler atomic safe
  mfd: kempld-core: Fix 'assignment of read-only location' error
  mfd: axp20x: Allow the AXP803 to be probed by I2C
  mfd: da9063: Add support for latest DA silicon revision
  mfd: da9063: Fix revision handling to correctly select reg tables
  dt-bindings: mfd: st,stmfx: Remove I2C unit name
  dt-bindings: mfd: ti,j721e-system-controller.yaml: Add J721e system controller
  mfd: motorola-cpcap: Disable interrupt for suspend
  mfd: smsc-ece1099: Remove driver
  mfd: core: Add OF_MFD_CELL_REG() helper
  ...
parents 18737f42 e15d7f2b
ChromeOS Embedded Controller
Google's ChromeOS EC is a Cortex-M device which talks to the AP and
implements various function such as keyboard and battery charging.
The EC can be connect through various means (I2C, SPI, LPC, RPMSG) and the
compatible string used depends on the interface. Each connection method has
its own driver which connects to the top level interface-agnostic EC driver.
Other Linux driver (such as cros-ec-keyb for the matrix keyboard) connect to
the top-level driver.
Required properties (I2C):
- compatible: "google,cros-ec-i2c"
- reg: I2C slave address
Required properties (SPI):
- compatible: "google,cros-ec-spi"
- reg: SPI chip select
Required properties (RPMSG):
- compatible: "google,cros-ec-rpmsg"
Optional properties (SPI):
- google,cros-ec-spi-pre-delay: Some implementations of the EC need a little
time to wake up from sleep before they can receive SPI transfers at a high
clock rate. This property specifies the delay, in usecs, between the
assertion of the CS to the start of the first clock pulse.
- google,cros-ec-spi-msg-delay: Some implementations of the EC require some
additional processing time in order to accept new transactions. If the delay
between transactions is not long enough the EC may not be able to respond
properly to subsequent transactions and cause them to hang. This property
specifies the delay, in usecs, introduced between transactions to account
for the time required by the EC to get back into a state in which new data
can be accepted.
Required properties (LPC):
- compatible: "google,cros-ec-lpc"
- reg: List of (IO address, size) pairs defining the interface uses
Optional properties (all):
- google,has-vbc-nvram: Some implementations of the EC include a small
nvram space used to store verified boot context data. This boolean flag
is used to specify whether this nvram is present or not.
Example for I2C:
i2c@12ca0000 {
cros-ec@1e {
reg = <0x1e>;
compatible = "google,cros-ec-i2c";
interrupts = <14 0>;
interrupt-parent = <&wakeup_eint>;
wakeup-source;
};
Example for SPI:
spi@131b0000 {
ec@0 {
compatible = "google,cros-ec-spi";
reg = <0x0>;
interrupts = <14 0>;
interrupt-parent = <&wakeup_eint>;
wakeup-source;
spi-max-frequency = <5000000>;
controller-data {
cs-gpio = <&gpf0 3 4 3 0>;
samsung,spi-cs;
samsung,spi-feedback-delay = <2>;
};
};
};
Example for LPC is not supplied as it is not yet implemented.
......@@ -79,11 +79,12 @@ properties:
description: |
conversion mode:
0 - temperature, in C*10
1 - pre-scaled voltage value
1 - pre-scaled 24-bit voltage value
2 - scaled voltage based on an optional resistor divider
and optional offset
3 - pre-scaled 16-bit voltage value
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
enum: [0, 1, 2, 3]
gw,voltage-divider-ohms:
description: Values of resistors for divider on raw ADC input
......
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/google,cros-ec.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ChromeOS Embedded Controller
maintainers:
- Benson Leung <bleung@chromium.org>
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
- Guenter Roeck <groeck@chromium.org>
description:
Google's ChromeOS EC is a microcontroller which talks to the AP and
implements various functions such as keyboard and battery charging.
The EC can be connected through various interfaces (I2C, SPI, and others)
and the compatible string specifies which interface is being used.
properties:
compatible:
oneOf:
- description:
For implementations of the EC is connected through I2C.
const: google,cros-ec-i2c
- description:
For implementations of the EC is connected through SPI.
const: google,cros-ec-spi
- description:
For implementations of the EC is connected through RPMSG.
const: google,cros-ec-rpmsg
google,cros-ec-spi-pre-delay:
description:
This property specifies the delay in usecs between the
assertion of the CS and the first clock pulse.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 0
- minimum: 0
google,cros-ec-spi-msg-delay:
description:
This property specifies the delay in usecs between messages.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- default: 0
- minimum: 0
google,has-vbc-nvram:
description:
Some implementations of the EC include a small nvram space used to
store verified boot context data. This boolean flag is used to specify
whether this nvram is present or not.
type: boolean
spi-max-frequency:
description: Maximum SPI frequency of the device in Hz.
reg:
maxItems: 1
interrupts:
maxItems: 1
required:
- compatible
if:
properties:
compatible:
contains:
enum:
- google,cros-ec-i2c
- google,cros-ec-rpmsg
then:
properties:
google,cros-ec-spi-pre-delay: false
google,cros-ec-spi-msg-delay: false
spi-max-frequency: false
additionalProperties: false
examples:
# Example for I2C
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
i2c0 {
#address-cells = <1>;
#size-cells = <0>;
cros-ec@1e {
compatible = "google,cros-ec-i2c";
reg = <0x1e>;
interrupts = <6 0>;
interrupt-parent = <&gpio0>;
};
};
# Example for SPI
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/irq.h>
spi0 {
#address-cells = <1>;
#size-cells = <0>;
cros-ec@0 {
compatible = "google,cros-ec-spi";
reg = <0x0>;
google,cros-ec-spi-msg-delay = <30>;
google,cros-ec-spi-pre-delay = <10>;
interrupts = <99 0>;
interrupt-parent = <&gpio7>;
spi-max-frequency = <5000000>;
};
};
# Example for RPMSG
- |
scp0 {
cros-ec {
compatible = "google,cros-ec-rpmsg";
};
};
...
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/khadas,mcu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Khadas on-board Microcontroller Device Tree Bindings
maintainers:
- Neil Armstrong <narmstrong@baylibre.com>
description: |
Khadas embeds a microcontroller on their VIM and Edge boards adding some
system feature as PWM Fan control (for VIM2 rev14 or VIM3), User memory
storage, IR/Key resume control, system power LED control and more.
properties:
compatible:
enum:
- khadas,mcu # MCU revision is discoverable
"#cooling-cells": # Only needed for boards having FAN control feature
const: 2
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
i2c {
#address-cells = <1>;
#size-cells = <0>;
khadas_mcu: system-controller@18 {
compatible = "khadas,mcu";
reg = <0x18>;
#cooling-cells = <2>;
};
};
......@@ -33,6 +33,9 @@ properties:
items:
- const: mux
interrupts:
maxItems: 1
"#address-cells":
const: 1
......@@ -106,11 +109,13 @@ additionalProperties: false
examples:
- |
#include <dt-bindings/clock/stm32mp1-clks.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
timer@40002400 {
compatible = "st,stm32-lptimer";
reg = <0x40002400 0x400>;
clocks = <&timer_clk>;
clock-names = "mux";
interrupts-extended = <&exti 47 IRQ_TYPE_LEVEL_HIGH>;
#address-cells = <1>;
#size-cells = <0>;
......
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/mfd/st,stmfx.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: STMicroelectonics Multi-Function eXpander (STMFX) bindings
description: ST Multi-Function eXpander (STMFX) is a slave controller using I2C for
communication with the main MCU. Its main features are GPIO expansion,
main MCU IDD measurement (IDD is the amount of current that flows
through VDD) and resistive touchscreen controller.
maintainers:
- Amelie Delaunay <amelie.delaunay@st.com>
properties:
compatible:
const: st,stmfx-0300
reg:
enum: [ 0x42, 0x43 ]
interrupts:
maxItems: 1
drive-open-drain: true
vdd-supply:
maxItems: 1
pinctrl:
type: object
properties:
compatible:
const: st,stmfx-0300-pinctrl
"#gpio-cells":
const: 2
"#interrupt-cells":
const: 2
gpio-controller: true
interrupt-controller: true
gpio-ranges:
description: if all STMFX pins[24:0] are available (no other STMFX function in use),
you should use gpio-ranges = <&stmfx_pinctrl 0 0 24>;
if agpio[3:0] are not available (STMFX Touchscreen function in use),
you should use gpio-ranges = <&stmfx_pinctrl 0 0 16>, <&stmfx_pinctrl 20 20 4>;
if agpio[7:4] are not available (STMFX IDD function in use),
you should use gpio-ranges = <&stmfx_pinctrl 0 0 20>;
maxItems: 1
patternProperties:
"^[a-zA-Z]*-pins$":
type: object
allOf:
- $ref: ../pinctrl/pinmux-node.yaml
properties:
pins: true
bias-disable: true
bias-pull-up: true
bias-pull-pin-default: true
bias-pull-down: true
drive-open-drain: true
drive-push-pull: true
output-high: true
output-low: true
additionalProperties: false
required:
- compatible
- "#gpio-cells"
- "#interrupt-cells"
- gpio-controller
- interrupt-controller
- gpio-ranges
additionalProperties: false
required:
- compatible
- reg
- interrupts
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
stmfx@42 {
compatible = "st,stmfx-0300";
reg = <0x42>;
interrupts = <8 IRQ_TYPE_EDGE_RISING>;
interrupt-parent = <&gpioi>;
vdd-supply = <&v3v3>;
stmfx_pinctrl: pinctrl {
compatible = "st,stmfx-0300-pinctrl";
#gpio-cells = <2>;
#interrupt-cells = <2>;
gpio-controller;
interrupt-controller;
gpio-ranges = <&stmfx_pinctrl 0 0 24>;
joystick_pins: joystick-pins {
pins = "gpio0", "gpio1", "gpio2", "gpio3", "gpio4";
drive-push-pull;
bias-pull-up;
};
};
};
};
...
STMicroelectonics Multi-Function eXpander (STMFX) Core bindings
ST Multi-Function eXpander (STMFX) is a slave controller using I2C for
communication with the main MCU. Its main features are GPIO expansion, main
MCU IDD measurement (IDD is the amount of current that flows through VDD) and
resistive touchscreen controller.
Required properties:
- compatible: should be "st,stmfx-0300".
- reg: I2C slave address of the device.
- interrupts: interrupt specifier triggered by MFX_IRQ_OUT signal.
Please refer to ../interrupt-controller/interrupt.txt
Optional properties:
- drive-open-drain: configure MFX_IRQ_OUT as open drain.
- vdd-supply: phandle of the regulator supplying STMFX.
Example:
stmfx: stmfx@42 {
compatible = "st,stmfx-0300";
reg = <0x42>;
interrupts = <8 IRQ_TYPE_EDGE_RISING>;
interrupt-parent = <&gpioi>;
vdd-supply = <&v3v3>;
};
Please refer to ../pinctrl/pinctrl-stmfx.txt for STMFX GPIO expander function bindings.
......@@ -26,7 +26,7 @@ Optional node:
Example:
/*
* Integrated Power Management Chip
* http://www.ti.com/lit/ds/symlink/twl6030.pdf
* https://www.ti.com/lit/ds/symlink/twl6030.pdf
*/
twl@48 {
compatible = "ti,twl6030";
......
STMicroelectronics Multi-Function eXpander (STMFX) GPIO expander bindings
ST Multi-Function eXpander (STMFX) offers up to 24 GPIOs expansion.
Please refer to ../mfd/stmfx.txt for STMFX Core bindings.
Required properties:
- compatible: should be "st,stmfx-0300-pinctrl".
- #gpio-cells: should be <2>, the first cell is the GPIO number and the second
cell is the gpio flags in accordance with <dt-bindings/gpio/gpio.h>.
- gpio-controller: marks the device as a GPIO controller.
- #interrupt-cells: should be <2>, the first cell is the GPIO number and the
second cell is the interrupt flags in accordance with
<dt-bindings/interrupt-controller/irq.h>.
- interrupt-controller: marks the device as an interrupt controller.
- gpio-ranges: specifies the mapping between gpio controller and pin
controller pins. Check "Concerning gpio-ranges property" below.
Please refer to ../gpio/gpio.txt.
Please refer to pinctrl-bindings.txt for pin configuration.
Required properties for pin configuration sub-nodes:
- pins: list of pins to which the configuration applies.
Optional properties for pin configuration sub-nodes (pinconf-generic ones):
- bias-disable: disable any bias on the pin.
- bias-pull-up: the pin will be pulled up.
- bias-pull-pin-default: use the pin-default pull state.
- bias-pull-down: the pin will be pulled down.
- drive-open-drain: the pin will be driven with open drain.
- drive-push-pull: the pin will be driven actively high and low.
- output-high: the pin will be configured as an output driving high level.
- output-low: the pin will be configured as an output driving low level.
Note that STMFX pins[15:0] are called "gpio[15:0]", and STMFX pins[23:16] are
called "agpio[7:0]". Example, to refer to pin 18 of STMFX, use "agpio2".
Concerning gpio-ranges property:
- if all STMFX pins[24:0] are available (no other STMFX function in use), you
should use gpio-ranges = <&stmfx_pinctrl 0 0 24>;
- if agpio[3:0] are not available (STMFX Touchscreen function in use), you
should use gpio-ranges = <&stmfx_pinctrl 0 0 16>, <&stmfx_pinctrl 20 20 4>;
- if agpio[7:4] are not available (STMFX IDD function in use), you
should use gpio-ranges = <&stmfx_pinctrl 0 0 20>;
Example:
stmfx: stmfx@42 {
...
stmfx_pinctrl: stmfx-pin-controller {
compatible = "st,stmfx-0300-pinctrl";
#gpio-cells = <2>;
#interrupt-cells = <2>;
gpio-controller;
interrupt-controller;
gpio-ranges = <&stmfx_pinctrl 0 0 24>;
joystick_pins: joystick {
pins = "gpio0", "gpio1", "gpio2", "gpio3", "gpio4";
drive-push-pull;
bias-pull-up;
};
};
};
Example of STMFX GPIO consumers:
joystick {
compatible = "gpio-keys";
#address-cells = <1>;
#size-cells = <0>;
pinctrl-0 = <&joystick_pins>;
pinctrl-names = "default";
button-0 {
label = "JoySel";
linux,code = <KEY_ENTER>;
interrupt-parent = <&stmfx_pinctrl>;
interrupts = <0 IRQ_TYPE_EDGE_RISING>;
};
button-1 {
label = "JoyDown";
linux,code = <KEY_DOWN>;
interrupt-parent = <&stmfx_pinctrl>;
interrupts = <1 IRQ_TYPE_EDGE_RISING>;
};
button-2 {
label = "JoyLeft";
linux,code = <KEY_LEFT>;
interrupt-parent = <&stmfx_pinctrl>;
interrupts = <2 IRQ_TYPE_EDGE_RISING>;
};
button-3 {
label = "JoyRight";
linux,code = <KEY_RIGHT>;
interrupt-parent = <&stmfx_pinctrl>;
interrupts = <3 IRQ_TYPE_EDGE_RISING>;
};
button-4 {
label = "JoyUp";
linux,code = <KEY_UP>;
interrupt-parent = <&stmfx_pinctrl>;
interrupts = <4 IRQ_TYPE_EDGE_RISING>;
};
};
leds {
compatible = "gpio-leds";
orange {
gpios = <&stmfx_pinctrl 17 1>;
};
blue {
gpios = <&stmfx_pinctrl 19 1>;
};
}
......@@ -100,7 +100,6 @@ available subsections can be seen below.
rfkill
serial/index
sm501
smsc_ece1099
switchtec
sync_file
vfio-mediated-device
......
=================================================
Msc Keyboard Scan Expansion/GPIO Expansion device
=================================================
What is smsc-ece1099?
----------------------
The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion
or GPIO Expansion device. The device supports a keyboard
scan matrix of 23x8. The device is connected to a Master
via the SMSC BC-Link interface or via the SMBus.
Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals
are multiplexed with GPIOs.
Interrupt generation
--------------------
Interrupts can be generated by an edge detection on a GPIO
pin or an edge detection on one of the bus interface pins.
Interrupts can also be detected on the keyboard scan interface.
The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if
any bit in one of the Interrupt Status registers is 1 and
the corresponding Interrupt Mask bit is also 1.
In order for software to determine which device is the source
of an interrupt, it should first read the Group Interrupt Status Register
to determine which Status register group is a source for the interrupt.
Software should read both the Status register and the associated Mask register,
then AND the two values together. Bits that are 1 in the result of the AND
are active interrupts. Software clears an interrupt by writing a 1 to the
corresponding bit in the Status register.
Communication Protocol
----------------------