This RFC includes implementation of the new config_{get,set} according to the latest version of
DEN0056E document (v3.2 beta2). Current RFC series covers the implementation of the SCMI protocol
functions without integration to the pinctrl driver, which is under development.
Please review changes to start the review process before I'll be ready to post complete v5 version.
This Patch series is intended to introduce the generic driver for
pin controls over SCMI protocol, provided in the latest beta version of DEN0056 [0].
On ARM-based systems, a separate Cortex-M based System Control Processor (SCP)
provides control on pins, as well as with power, clocks, reset controllers. In this case,
kernel should use one of the possible transports, described in [0] to access SCP and
control clocks/power-domains etc. This driver is using SMC transport to communicate with SCP via
SCMI protocol and access to the Pin Control Subsystem.
The provided driver consists of 2 parts:
- firmware/arm_scmi/pinctrl.c - the SCMI pinctrl protocol inmplementation
responsible for the communication with SCP firmware.
- drivers/pinctrl/pinctrl-scmi.c - pinctrl driver, which is using pinctrl
protocol implementation to access all necessary data.
Configuration:
The scmi-pinctrl driver can be configured using DT bindings.
For example:
/ {
cpu_scp_shm: scp-shmem@0x53FF0000 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x53FF0000 0x0 0x1000>;
};
firmware {
scmi {
compatible = "arm,scmi-smc";
arm,smc-id = <0x82000002>;
shmem = <&cpu_scp_shm>;
#address-cells = <1>;
#size-cells = <0>;
scmi_pinctrl: protocol@19 {
reg = <0x18>;
#pinctrl-cells = <0>;
i2c2_pins: i2c2 {
groups = "i2c2_a";
function = "i2c2";
};
};
};
};
};
&pfc {
/delete-node/i2c2;
};
So basically, it's enough to move pfc subnode, which configures pin group that should work through
SCMI protocol to scmi_pinctrl node. The current driver implementation is using generic pinctrl dt_node
format.
I've tested this driver on the Renesas H3ULCB Kingfisher board with pinctrl driver ported to the
Arm-trusted-firmware. Unfortunately, not all hardware was possible to test because the Renesas
pinctrl driver has gaps in pins and groups numeration, when Spec [0] requires pins, groups and
functions numerations to be 0..n without gaps.
Also, sharing link to the ATF pinctrl driver I used for testing:
https://github.com/oleksiimoisieiev/arm-trusted-firmware/tree/pinctrl_rcar_m3_up
[0] https://developer.arm.com/documentation/den0056/latest
---
Changes v4 -> v5
- add new calls to scmi_protocol description for config_{get,set}
Changes v3 -> v4:
- Fixed MAINTAINERS file description
- adjusted pinctrl ops position and callback names
- add trailing coma in scmi_protocol list
- removed unneeded pi checks
- corrected selector check
- resource allocation refactoring
- scmi_*_info swap params to generate better code
- style, add trailing coma in definitions
- reworked protocol@19 format in device-tree bindings
- ordered config option and object file alphabetically
- rephrased PINCTRL_SCMI config description
- formatting fixes, removed blank lines after get_drvdata call
- code style adjustments
- add set_drvdata call
- removed goto label
- refactoring of the devm resource management
- removed pctldev != NULL check
- fix parameter name in pinconf-group-get
- probe function refactoring
- removed unneeded pmx checks
Changes v2 -> v3:
- update get_name calls as suggested by Cristian Marussi
- fixing comments
- refactoring of the dt_bindings according to the comments
Changes v1 -> v2:
- rebase patches to the latest kernel version
- use protocol helpers in the pinctrl scmi protocol driver implementation
- reworked pinctrl_ops. Removed similar calls to simplify the interface
- implementation of the .instance_deinit callback to properly clean resources
- add description of the pinctrl protocol to the device-tree schema
---
Cristian Marussi (1):
firmware: arm_scmi: Add optional flags to extended names helper
Oleksii Moisieiev (4):
drivers: firmware: scmi: Introduce scmi_get_max_msg_size function
firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
pinctrl: Implementation of the generic scmi-pinctrl driver
dt-bindings: firmware: arm,scmi: Add support for pinctrl protocol
.../bindings/firmware/arm,scmi.yaml | 53 +
MAINTAINERS | 7 +
drivers/firmware/arm_scmi/Makefile | 2 +-
drivers/firmware/arm_scmi/clock.c | 2 +-
drivers/firmware/arm_scmi/common.h | 3 +
drivers/firmware/arm_scmi/driver.c | 25 +-
drivers/firmware/arm_scmi/perf.c | 3 +-
drivers/firmware/arm_scmi/pinctrl.c | 922 ++++++++++++++++++
drivers/firmware/arm_scmi/power.c | 2 +-
drivers/firmware/arm_scmi/powercap.c | 2 +-
drivers/firmware/arm_scmi/protocols.h | 4 +-
drivers/firmware/arm_scmi/reset.c | 3 +-
drivers/firmware/arm_scmi/sensors.c | 2 +-
drivers/firmware/arm_scmi/voltage.c | 2 +-
drivers/pinctrl/Kconfig | 11 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-scmi.c | 445 +++++++++
include/linux/scmi_protocol.h | 47 +
18 files changed, 1525 insertions(+), 11 deletions(-)
create mode 100644 drivers/firmware/arm_scmi/pinctrl.c
create mode 100644 drivers/pinctrl/pinctrl-scmi.c
--
2.25.1
Hi Oleksii,
thanks for this patch, which still looks very good to me.
A question that was raised in discussion with Takahiro Akashi was how we
identify pins that can be used for GPIO and if the spec or implementation
has given any thought to that.
I can think of a few, such that:
1. Pins that can be used for GPIO all belong to some group - possibly even
one group per pin such as "gpioA1", "gpioA2", "gpioA3" etc - that can be
assigned a function named "gpio" or similar.
2. GPIO is seen as something external or "third usecase" that is handled
by pin config, not by pin mux.
If it is 1 - which I find likely - it would be good to standardize the name of
the function to be "gpio" and somehow make it clear that all pins that are
desired to be used for GPIO need to have a (group, function) tuple pair
such as ("gpio001", "gpio") that will put the pin into GPIO mode.
If the assumption is anything goes, i.e. a vendor could say something
like ("io-group-99", "generic-io") to put a certain pin into GPIO mode,
that is maybe not so optimal, because it's nice for the GPIO driver
(which will come up) to be able to figure out by e.g. string name
conventions that a pin is in GPIO mode, and which group and function
that will put it into GPIO mode.
If this generality is not desired, having standard names for GPIO
functions and groups is still going to be an upside, if it can be achieved.
But maybe this isn't attainable at this point?
Yours,
Linus Walleij