mirror of
https://github.com/torvalds/linux.git
synced 2026-05-17 19:17:29 +02:00
cdcf626314
Few main features include:
1. SCMI transport as stand-alone drivers
Currently the SCMI transport layer is being built embedded into in
the core SCMI stack. Some of these transports, despite being currently
part of the main SCMI module, are indeed also registered with different
subsystems like optee or virtio, and actively probed also by those.
This leads to a few awkward and convoluted tricks to properly handle
such interactions at boot time in the SCMI stack.
This change adds the new logic to the core SCMI stack so that each
existing transport is transitioned to be a standi-alone driver. With
that all the probe deferral and awkward retries between the SCMI
core stack and the transports has been removed, since no more needed.
2. Support for obtaining transport descriptors from the devicetree
SCMI platform firmwares might have different designs depending on
the platform. Some of the transport descriptors rely on such design.
E.g. the maximum receive channel timeout value might vary depending
on the specific underlying hardware and firmware design choices.
This change adds support for max-rx-timeout-ms property to describe
the transport needs of a specific platform design. It will be extended
in the future to obtain other such hardware/firmware dependent
transport related descriptors.
3. NXP i.MX95 specific SCMI vendor protocol extensions
SCMI specification allows vendor or platform-specific extensions to
the interface. NXP i.MX95 System Manager(SM) that implements SCMI
extends the interface to implement couple of vendor/platform specific
protocol, namely:
a. Battery Backed Module(BBM) Protocol
This protocol is intended provide access to the battery-backed
module. This contains persistent storage (GPR), an RTC, and the
ON/OFF button. The protocol can also provide access to similar
functions implemented via external board components.
b. MISC Protocol for misc settings
This includes controls that are misc settings/actions that must
be exposed from the SM to agents. They are device specific and
are usually define to access bit fields in various mix block
control modules, IOMUX_GPR, and other GPR/CSR owned by the SM.
4. SCMI debug/tracking metrics
Since SCMI involves interaction with the entity(software, firmware
and/or hardware) providing services or features, it is quite useful
to track certain metrics(for pure debugging purposes) like how many
messages were sent or received, were there any failures, what kind
of failures, ..etc. This feature adds support for the same via debugfs.
Apart from these main features, there are some miscellaneous updates, fixes
and cleanups.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmbRy5cACgkQAEG6vDF+
4pimmRAAy+JMVqmgw33e9zvQ6mXsncTO2YXWYVgM3g+IypwpIwdPryUt9NA9xR8w
BHc0hlsCVsLmww4epb5fnztqN7YmvP5NUQhe4ZNRE72Bak5fidThdsNhCOBtlt25
WwK0447UglHU/aF8VT2ufRhnMYIJDixazsvz0vp7wJpIPbfuS7r2WZXzw8fBXizH
oXiYZLsgcv2WAKY5Q9DQhfYzosYhp9BPNYSV2luyYPZNPUbal2WNoAp1tLOQaLNY
a+vtgOiyZPvltFewWVTNk2q6EhSyuiA/qHlM2Lp3aVuscA+h7Wa+RjHFN1YQHw/b
+hNmljDyUGDBsbNLR9EdmV2dutsLE3Sk0/4H5V+sXEuB+q2gaOUVfpsDW52o7LLW
s6DCDX47/9t+7y0uaApQnzUlskJonEBGq1Qm1siNiCpRR6SbABjcXFl654Tu61dr
bv31uEOjxYzqQXXsYdQvAIDAg1VSlUcyr4ITHMifj9mBZrQMvrizjlbpRGSOQsJv
NNIxPcvEsCq07tHvD0sQqaNLZN/5VEVCqdNqGBDBsLCPDVKIqc2DxK2udUt8exVE
WCHLJb+DT1Gd6eQ00KQKx8umJeXPLehtBCvBdlDTHPKZWrFenQFPkKZsnqeNuneS
IDIdyfbWrMgalwzDTgOZWxDcydkxXKNhpn7k2x/BzWGGhwtfHSI=
=fUHS
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmbVkXIACgkQYKtH/8kJ
UicZlA//eDFRRTxL5MOHhVY5hpn8Sn0a59Wz0S1x+xy5WnGxxh6EMnyLGr8vxmGp
FREvraghX0/ftPIvDMRD2WgR93R96Q0d10tmLf9Es7iG9WskXqNsWBkTijCdvst4
1iEC/wSu8ab2HGhtoUIM1Wt9R+RlkS7UE0TPRzchGQTM9FdytVv9qECtX9JGi7Wn
CvCgcFGifKyOzigm3a4kf3FPtB8Y/ggPLOoDyIHOlM8lrdGmDh5PXuzbeKMxwSt1
YBZS4T5QaWvwaT8ZOraAMYjNN+PmiL587JbY9L+H+VwPV5VpoxlNmNo3wjkAb1q/
hg4huRJlN7BvN1wTQtsnDpzt4VgnIDOh+RXJ/ulUKSGLQ3TosV88FFIGfAO+KTBP
PaQI4taxcyhsnhl4ab040jumfUbeK8DHwCc1P/HsejYy6H9bmjwFV8WCbSZTNH6g
if6fcGRYIzw8MzeqtTH1qjLwhqYt/iXUahHzzONWzskvzR/kPV1x/mSPQNVcJ51e
rL6D485CjZh85pY7Pvn4+Ylur9uIe9wealipfSFzWlAgo57sTY6xrilO20UHnR6t
n+202dPG8TAoDrpomLsF04rbuV4uhv0gWhtIyCzaJHYfgCUgAQvzniR2T6IaOTM3
ks/SZ0j+sv65/KJd8rO1tZHwgEVwmDElRzO9CPF3pQxMrzKG5iw=
=28qZ
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm SCMI updates for v6.12
Few main features include:
1. SCMI transport as stand-alone drivers
Currently the SCMI transport layer is being built embedded into in
the core SCMI stack. Some of these transports, despite being currently
part of the main SCMI module, are indeed also registered with different
subsystems like optee or virtio, and actively probed also by those.
This leads to a few awkward and convoluted tricks to properly handle
such interactions at boot time in the SCMI stack.
This change adds the new logic to the core SCMI stack so that each
existing transport is transitioned to be a standi-alone driver. With
that all the probe deferral and awkward retries between the SCMI
core stack and the transports has been removed, since no more needed.
2. Support for obtaining transport descriptors from the devicetree
SCMI platform firmwares might have different designs depending on
the platform. Some of the transport descriptors rely on such design.
E.g. the maximum receive channel timeout value might vary depending
on the specific underlying hardware and firmware design choices.
This change adds support for max-rx-timeout-ms property to describe
the transport needs of a specific platform design. It will be extended
in the future to obtain other such hardware/firmware dependent
transport related descriptors.
3. NXP i.MX95 specific SCMI vendor protocol extensions
SCMI specification allows vendor or platform-specific extensions to
the interface. NXP i.MX95 System Manager(SM) that implements SCMI
extends the interface to implement couple of vendor/platform specific
protocol, namely:
a. Battery Backed Module(BBM) Protocol
This protocol is intended provide access to the battery-backed
module. This contains persistent storage (GPR), an RTC, and the
ON/OFF button. The protocol can also provide access to similar
functions implemented via external board components.
b. MISC Protocol for misc settings
This includes controls that are misc settings/actions that must
be exposed from the SM to agents. They are device specific and
are usually define to access bit fields in various mix block
control modules, IOMUX_GPR, and other GPR/CSR owned by the SM.
4. SCMI debug/tracking metrics
Since SCMI involves interaction with the entity(software, firmware
and/or hardware) providing services or features, it is quite useful
to track certain metrics(for pure debugging purposes) like how many
messages were sent or received, were there any failures, what kind
of failures, ..etc. This feature adds support for the same via debugfs.
Apart from these main features, there are some miscellaneous updates, fixes
and cleanups.
* tag 'scmi-updates-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (31 commits)
rtc: support i.MX95 BBM RTC
input: keyboard: support i.MX95 BBM module
firmware: imx: Add i.MX95 MISC driver
firmware: arm_scmi: Add initial support for i.MX MISC protocol
firmware: arm_scmi: Add initial support for i.MX BBM protocol
firmware: arm_scmi: Add NXP i.MX95 SCMI documentation
dt-bindings: firmware: Add i.MX95 SCMI Extension protocol
firmware: arm_scmi: Replace comma with the semicolon
firmware: arm_scmi: Replace the use of of_node_put() to __free(device_node)
firmware: arm_scmi: Fix trivial whitespace/coding style issues
firmware: arm_scmi: Use max-rx-timeout-ms from devicetree
dt-bindings: firmware: arm,scmi: Introduce property max-rx-timeout-ms
firmware: arm_scmi: Remove const from transport descriptors
firmware: arm_scmi: Simplify with scoped for each OF child loop
firmware: arm_scmi: Update various protocols versions
firmware: arm_scmi: Remove legacy transport-layer code
firmware: arm_scmi: Make VirtIO transport a standalone driver
firmware: arm_scmi: Make OPTEE transport a standalone driver
firmware: arm_scmi: Make SMC transport a standalone driver
firmware: arm_scmi: Make MBOX transport a standalone driver
...
Link: https://lore.kernel.org/r/20240830135918.2383664-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
||
|---|---|---|
| .. | ||
| gameport | ||
| joystick | ||
| keyboard | ||
| misc | ||
| mouse | ||
| rmi4 | ||
| serio | ||
| tablet | ||
| tests | ||
| touchscreen | ||
| apm-power.c | ||
| evbug.c | ||
| evdev.c | ||
| ff-core.c | ||
| ff-memless.c | ||
| input-compat.c | ||
| input-compat.h | ||
| input-core-private.h | ||
| input-leds.c | ||
| input-mt.c | ||
| input-poller.c | ||
| input-poller.h | ||
| input.c | ||
| joydev.c | ||
| Kconfig | ||
| Makefile | ||
| matrix-keymap.c | ||
| mousedev.c | ||
| sparse-keymap.c | ||
| touchscreen.c | ||
| vivaldi-fmap.c | ||