mbox series

[v3,0/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support

Message ID cover.1686063941.git.oleksii_moisieiev@epam.com
Headers
Series firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support |

Message

Oleksii Moisieiev June 6, 2023, 4:22 p.m. UTC 
  This Patch series is intended to introduce the potential 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 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

---
Oleksii Moisieiev (4):
  firmware: arm_scmi: Add optional flags to extended names helper
  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/driver.c            |  10 +-
 drivers/firmware/arm_scmi/perf.c              |   3 +-
 drivers/firmware/arm_scmi/pinctrl.c           | 836 ++++++++++++++++++
 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                | 554 ++++++++++++
 include/linux/scmi_protocol.h                 |  47 +
 17 files changed, 1530 insertions(+), 11 deletions(-)
 create mode 100644 drivers/firmware/arm_scmi/pinctrl.c
 create mode 100644 drivers/pinctrl/pinctrl-scmi.c

Comments

Cristian Marussi June 30, 2023, 10:38 a.m. UTC | #1 
On Tue, Jun 06, 2023 at 04:22:26PM +0000, Oleksii Moisieiev wrote:
> This Patch series is intended to introduce the potential 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.
> 

Hi Oleksii,

sorry this review has been a bit delayed, I tested V3 in my setup and found no
practical issue. I'll post a few comments/remarks along the series.

Beside addressing pending comments, I suppose that the next step will be anyway
to address the upcoming changes in the new v3.2 BETA regarding support for
multiple type/value set/get operations as requested by Peng.

Thanks,
Cristian
Oleksii Moisieiev July 3, 2023, 12:58 p.m. UTC | #2 
Hi Cristian,

Thanks for the testing and for the review.
I will address all comments and v4 will be with v3.2 BETA changes.

Best regards,
Oleksii.

On Fri, Jun 30, 2023 at 11:38:47AM +0100, Cristian Marussi wrote:
> On Tue, Jun 06, 2023 at 04:22:26PM +0000, Oleksii Moisieiev wrote:
> > This Patch series is intended to introduce the potential 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.
> > 
> 
> Hi Oleksii,
> 
> sorry this review has been a bit delayed, I tested V3 in my setup and found no
> practical issue. I'll post a few comments/remarks along the series.
> 
> Beside addressing pending comments, I suppose that the next step will be anyway
> to address the upcoming changes in the new v3.2 BETA regarding support for
> multiple type/value set/get operations as requested by Peng.
> 
> Thanks,
> Cristian