IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There are a few separately maintained driver subsystems that we merge through
the SoC tree, notable changes are:
- Memory controller updates, mainly for Tegra and Mediatek SoCs,
and clarifications for the memory controller DT bindings
- SCMI firmware interface updates, in particular a new transport based
on OPTEE and support for atomic operations.
- Cleanups to the TEE subsystem, refactoring its memory management
For SoC specific drivers without a separate subsystem, changes include
- Smaller updates and fixes for TI, AT91/SAMA5, Qualcomm and NXP
Layerscape SoCs.
- Driver support for Microchip SAMA5D29, Tesla FSD, Renesas RZ/G2L,
and Qualcomm SM8450.
- Better power management on Mediatek MT81xx, NXP i.MX8MQ
and older NVIDIA Tegra chips
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmI4nOUACgkQmmx57+YA
GNlNNhAApPQw+FKQ6yVj2EZYcaAgik8PJAJoNQWYED52iQfm5uXgjt3aQewvrPNW
nkKx5Mx+fPUfaKx5mkVOFMhME5Bw9tYbXHm2/RpRp+n8jOdUlQpAhzIPOyWPHOJS
QX6qu4t+agrQzjbOCGouAJXgyxhTJFUMviM2EgVHbQHXPtdF8i2kyanfCP7Rw8cx
sVtLwpvhbLm849+deYRXuv2Xw9I3M1Np7018s5QciimI2eLLEb+lJ/C5XWz5pMYn
M1nZ7uwCLKPCewpMETTuhKOv0ioOXyY9C1ghyiGZFhHQfoCYTu94Hrx9t8x5gQmL
qWDinXWXVk8LBegyrs8Bp4wcjtmvMMLnfWtsGSfT5uq24JOGg22OmtUNhNJbS9+p
VjEvBgkXYD7UEl5npI9v9/KQWr3/UDir0zvkuV40gJyeBWNEZ/PB8olXAxgL7wZv
cXRYSaUYYt3DKQf1k5I4GUyQtkP/4RaBy6AqvH5Sx0lCwuY6G6ISK+kCPaaSRKnX
WR+nFw84dKCu7miehmW9qSzMQ4kiSCKIDqk7ilHcwv0J2oXDrlqVPKGGGTzZjUc8
+feqM/eSoYvDDEDemuXNSnl3hc1Zlvm7Apd5AN6kdTaNgoACDYdyvGuJ3CvzcA+K
1gBHUBvGS/ODA25KnYabr7wCMgxYqf7dXfkyKIBwFHwxOnRHtgs=
=Cfbk
-----END PGP SIGNATURE-----
Merge tag 'arm-drivers-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM driver updates from Arnd Bergmann:
"There are a few separately maintained driver subsystems that we merge
through the SoC tree, notable changes are:
- Memory controller updates, mainly for Tegra and Mediatek SoCs, and
clarifications for the memory controller DT bindings
- SCMI firmware interface updates, in particular a new transport
based on OPTEE and support for atomic operations.
- Cleanups to the TEE subsystem, refactoring its memory management
For SoC specific drivers without a separate subsystem, changes include
- Smaller updates and fixes for TI, AT91/SAMA5, Qualcomm and NXP
Layerscape SoCs.
- Driver support for Microchip SAMA5D29, Tesla FSD, Renesas RZ/G2L,
and Qualcomm SM8450.
- Better power management on Mediatek MT81xx, NXP i.MX8MQ and older
NVIDIA Tegra chips"
* tag 'arm-drivers-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (154 commits)
ARM: spear: fix typos in comments
soc/microchip: fix invalid free in mpfs_sys_controller_delete
soc: s4: Add support for power domains controller
dt-bindings: power: add Amlogic s4 power domains bindings
ARM: at91: add support in soc driver for new SAMA5D29
soc: mediatek: mmsys: add sw0_rst_offset in mmsys driver data
dt-bindings: memory: renesas,rpc-if: Document RZ/V2L SoC
memory: emif: check the pointer temp in get_device_details()
memory: emif: Add check for setup_interrupts
dt-bindings: arm: mediatek: mmsys: add support for MT8186
dt-bindings: mediatek: add compatible for MT8186 pwrap
soc: mediatek: pwrap: add pwrap driver for MT8186 SoC
soc: mediatek: mmsys: add mmsys reset control for MT8186
soc: mediatek: mtk-infracfg: Disable ACP on MT8192
soc: ti: k3-socinfo: Add AM62x JTAG ID
soc: mediatek: add MTK mutex support for MT8186
soc: mediatek: mmsys: add mt8186 mmsys routing table
soc: mediatek: pm-domains: Add support for mt8186
dt-bindings: power: Add MT8186 power domains
soc: mediatek: pm-domains: Add support for mt8195
...
An SCMI platform can optionally advertise an enable latency typically
associated with a specific clock resource: add support for parsing such
optional message field and export such information in the usual publicly
accessible clock descriptor.
Link: https://lore.kernel.org/r/20220217131234.50328-8-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Introduce new _atomic variant for SCMI clock protocol operations related
to enable disable operations: when an atomic operation is required the xfer
poll_completion flag is set for that transaction.
Link: https://lore.kernel.org/r/20220217131234.50328-7-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
An SCMI agent can be configured system-wide with a well-defined atomic
threshold: only SCMI synchronous command whose latency has been advertised
by the SCMI platform to be lower or equal to this configured threshold will
be considered for atomic operations, when requested and if supported by the
underlying transport at all.
Link: https://lore.kernel.org/r/20220217131234.50328-6-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add support for .mark_txdone and .poll_done transport operations to SCMI
VirtIO transport as pre-requisites to enable atomic operations.
Add a Kernel configuration option to enable SCMI VirtIO transport polling
and atomic mode for selected SCMI transactions while leaving it default
disabled.
Link: https://lore.kernel.org/r/20220217131234.50328-4-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Skalkin <igor.skalkin@opensynergy.com>
Cc: Peter Hilber <peter.hilber@opensynergy.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a new spinlock dedicated to the access of the TX free list and a couple
of helpers to get and put messages back and forth from the free_list.
Link: https://lore.kernel.org/r/20220217131234.50328-3-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Skalkin <igor.skalkin@opensynergy.com>
Cc: Peter Hilber <peter.hilber@opensynergy.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Currently SCMI VirtIO channels are marked with a ready flag and related
lock to track channel lifetime and support proper synchronization at
shutdown when virtqueues have to be stopped.
This leads to some extended spinlocked sections with IRQs off on the RX
path to keep hold of the ready flag and does not scale well especially when
SCMI VirtIO polling mode will be introduced.
Add an SCMI VirtIO channel dedicated refcount to track active users on both
the TX and the RX path and properly enforce synchronization and cleanup at
shutdown, inhibiting further usage of the channel once freed.
Link: https://lore.kernel.org/r/20220217131234.50328-2-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Igor Skalkin <igor.skalkin@opensynergy.com>
Cc: Peter Hilber <peter.hilber@opensynergy.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
modprobe can't handle spaces in aliases. Get rid of it to fix the issue.
Link: https://lore.kernel.org/r/20220211102704.128354-1-sudeep.holla@arm.com
Fixes: aa4f886f3893 ("firmware: arm_scmi: add basic driver infrastructure for SCMI")
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The SMC calling convention designates R0-R7 as input registers in
AArch32 mode, and this conflicts with the compiler's use of R7 as a
frame pointer when building in Thumb2 mode. Generally, we don't enable
the frame pointer, and GCC happily enables the -pg profiling hooks
without them. However, Clang refuses, and errors out with the message
below:
drivers/firmware/arm_scmi/smc.c:152:2: error: write to reserved register 'R7'
arm_smccc_1_1_invoke(scmi_info->func_id, 0, 0, 0, 0, 0, 0, 0, &res);
^
include/linux/arm-smccc.h:550:4: note: expanded from macro 'arm_smccc_1_1_invoke'
arm_smccc_1_1_smc(__VA_ARGS__); \
^
Let's just disable ftrace for the compilation unit when building this
configuration.
Link: https://lore.kernel.org/r/20220203082204.1176734-11-ardb@kernel.org
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Couple of main additions:
- Support for OPTEE based SCMI transport to enable using SCMI service
provided by OPTEE on some platforms
- Support for atomic SCMI transports which enables few SCMI transactions
to be completed in atomic context. This involves other refactoring work
associated with it. It also marks SMC and OPTEE as atomic transport as
the commands are completed once the return
Other changes involves some trace and log enhancements and a miscellaneous
bug fix.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmHDMMoACgkQAEG6vDF+
4pjx9g/+IbMZFxhJkO7kar72cNA3Nf4qzQIjYoM6gxOwly+5+s3QMPdXhBCYLf/9
knDz1JVbEMtz3u6jNHGliF/p+tUq/dGnqAZvsDn3lthmhPGt1EmW9CLiGweXXfU6
hZIEpHVQGJue0US/g7BgwYDAZHuAy71BAZr5M4WcR7gjGH9KMRXFdu8mqiXMM1k5
nMdvcjBv38ZQHtJXQSwVd9yv+d31vt01t57G3NeavINlbHzHCqnKA6VdbjuFLnX5
q0ovaKDKjzurK2cL2quep7nlAAujk0q5vMSDPYmPqY2K0+aHsHlTwIQHNYOEvNTO
GXtk7DL6lMwnfKSbJXRIDMK7MgCIlk9vhm1MZNMVkmJ/moMfS/nQjMkqBmg7BRCT
sGKzLEHRuzud+KHecI/vNCZxokvC9er3OyOYD7bIVn26kWJu7EmwwHXK5E7rt8JW
o0JqtgOo0gs2yjW/A7nSVVEBA/pEYftKSkaEn/gHFSvGcB6eu4LT7s16FaHf6d++
LsBVoTuPrjTYZdkAZXbyXJbX3wuw4yyCJWB1ynrJ+udRw3lguXlI02CKshAXHIKn
BSyLPYg9juWt7fqx7/DHrzw7ZdOQW0zMugNImZBHtub2UnmGw6I7t82bQILJmMG1
wbmA9MCggo7q1D4yZeRmPvFLqOLnNyKEcviSDm4rvApsZgCo9mM=
=12H2
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into for-next/scmi
Arm SCMI firmware interface updates for v5.17
Couple of main additions:
- Support for OPTEE based SCMI transport to enable using SCMI service
provided by OPTEE on some platforms
- Support for atomic SCMI transports which enables few SCMI transactions
to be completed in atomic context. This involves other refactoring work
associated with it. It also marks SMC and OPTEE as atomic transport as
the commands are completed once the return
Other changes involves some trace and log enhancements and a miscellaneous
bug fix.
* tag 'scmi-updates-5.17' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Add new parameter to mark_txdone
firmware: arm_scmi: Add atomic mode support to smc transport
firmware: arm_scmi: Add support for atomic transports
firmware: arm_scmi: Make optee support sync_cmds_completed_on_ret
firmware: arm_scmi: Make smc support sync_cmds_completed_on_ret
firmware: arm_scmi: Add sync_cmds_completed_on_ret transport flag
firmware: arm_scmi: Make smc transport use common completions
firmware: arm_scmi: Add configurable polling mode for transports
firmware: arm_scmi: Use new trace event scmi_xfer_response_wait
include: trace: Add new scmi_xfer_response_wait event
firmware: arm_scmi: Refactor message response path
firmware: arm_scmi: Set polling timeout to max_rx_timeout_ms
firmware: arm_scmi: Perform earlier cinfo lookup call in do_xfer
firmware: arm_scmi: optee: Drop the support for the OPTEE shared dynamic buffer
firmware: arm_scmi: optee: Fix missing mutex_init()
firmware: arm_scmi: Make virtio Version_1 compliance optional
firmware: arm_scmi: Add optee transport
dt-bindings: arm: Add OP-TEE transport for SCMI
firmware: arm_scmi: Review some virtio log messages
This will enable cleanups down the road.
The idea is to disable cbs, then add "flush_queued_cbs" callback
as a parameter, this way drivers can flush any work
queued after callbacks have been disabled.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Link: https://lore.kernel.org/r/20211013105226.20225-1-mst@redhat.com
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Add a new xfer parameter to mark_txdone transport operation which enables
the SCMI core to optionally pass back into the transport layer a reference
to the xfer descriptor that is being handled.
Link: https://lore.kernel.org/r/20211220195646.44498-9-cristian.marussi@arm.com
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a Kernel configuration option to enable SCMI SMC transport atomic
mode operation for selected SCMI transactions and leave it as default
disabled.
Substitute mutex usages with busy-waiting and declare smc transport as
.atomic_enabled if such Kernel configuration option is enabled.
Link: https://lore.kernel.org/r/20211220195646.44498-8-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
An SCMI transport can be configured as .atomic_enabled in order to signal
to the SCMI core that all its TX path is executed in atomic context and
that, when requested, polling mode should be used while waiting for command
responses.
When a specific platform configuration had properly configured such a
transport as .atomic_enabled, the SCMI core will also take care not to
sleep in the corresponding RX path while waiting for a response if that
specific command transaction was requested as atomic using polling mode.
Asynchronous commands should not be used in an atomic context and so a
warning is emitted if polling was requested for an asynchronous command.
Add also a method to check, from the SCMI drivers, if the underlying SCMI
transport is currently configured to support atomic transactions: this will
be used by upper layers to determine if atomic requests can be supported at
all on this SCMI instance.
Link: https://lore.kernel.org/r/20211220195646.44498-7-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Declare each OPTEE SCMI channel as not having a completion_irq so as to
enable polling mode and then enable also .sync_cmds_completed_on_ret flag
in the OPTEE transport descriptor so that real polling is itself
effectively bypassed on the rx path: once the optee command invocation has
successfully returned the core will directly fetch the response from the
shared memory area.
Remove OPTEE SCMI transport specific .poll_done callback support since
real polling is effectively bypassed when .sync_cmds_completed_on_ret is
set.
Add OPTEE SCMI transport specific .mark_txdone callback support in order to
properly handle channel locking along the tx path.
Link: https://lore.kernel.org/r/20211220195646.44498-6-cristian.marussi@arm.com
Cc: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Enable sync_cmds_completed_on_ret in the SMC transport descriptor and
remove SMC specific .poll_done callback support since polling is bypassed
when sync_cmds_completed_on_ret is set.
Link: https://lore.kernel.org/r/20211220195646.44498-5-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a flag to let the transport signal to the core if its handling of sync
command implies that, after .send_message has returned successfully, the
requested command can be assumed to be fully and completely executed on
SCMI platform side so that any possible response value is already
immediately available to be retrieved by a .fetch_response: in other words
the polling phase can be skipped in such a case and the response values
accessed straight away.
Note that all of the above applies only when polling mode of operation was
selected by the core: if instead a completion IRQ was found to be available
the normal response processing path based on completions will still be
followed.
Link: https://lore.kernel.org/r/20211220195646.44498-4-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
When a completion irq is available use it and delegate command completion
handling to the core SCMI completion mechanism.
If no completion irq is available revert to polling, using the core common
polling machinery.
Link: https://lore.kernel.org/r/20211220195646.44498-3-cristian.marussi@arm.com
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI communications along TX channels can optionally be provided of a
completion interrupt; when such interrupt is not available, command
transactions should rely on polling, where the SCMI core takes care to
repeatedly evaluate the transport-specific .poll_done() function, if
available, to determine if and when a request was fully completed or
timed out.
Such mechanism is already present and working on a single transfer base:
SCMI protocols can indeed enable hdr.poll_completion on specific commands
ahead of each transfer and cause that transaction to be handled with
polling.
Introduce a couple of flags to be able to enforce such polling behaviour
globally at will:
- scmi_desc.force_polling: to statically switch the whole transport to
polling mode.
- scmi_chan_info.no_completion_irq: to switch a single channel dynamically
to polling mode if, at runtime, is determined that no completion
interrupt was available for such channel.
Link: https://lore.kernel.org/r/20211220195646.44498-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Use new trace event to mark start of waiting for response section.
Link: https://lore.kernel.org/r/20211129191156.29322-6-cristian.marussi@arm.com
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Use transport specific transmission timeout (max_rx_timeout_ms) also for
polling transactions.
Initially when polling mode was added, it was intended to be used only
in scheduler context and hence the choice of 100us for the polling timeout.
However the only user for that was dropped for other SCMI concurrency
issues, so it shouldn't cause any issue to increase this timeout value now.
Link: https://lore.kernel.org/r/20211129191156.29322-3-cristian.marussi@arm.com
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: Updated commit message with historical facts about 100us timeout]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Lookup cinfo data early in do_xfer so as to avoid any further init work
on xfer structure in case of error.
No functional change.
Link: https://lore.kernel.org/r/20211129191156.29322-2-cristian.marussi@arm.com
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The shared memory buffer allocated by the optee driver is normal cached
memory and can't be used with IOMEM APIs used in shmem_*.
We currently support only IO memory for shared memory and supporting
normal cached memory needs more changes and needs to be thought through
properly. So for now, let us drop the support for this OPTEE shared buffer.
Link: https://lore.kernel.org/r/20211125150730.188487-1-sudeep.holla@arm.com
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The driver allocates the mutex but not initialize it.
Use mutex_init() on it to initialize it correctly.
Link: https://lore.kernel.org/r/20211123083620.2366860-1-weiyongjun1@huawei.com
Fixes: 5f90f189a052 ("firmware: arm_scmi: Add optee transport")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Introduce a compilation option to disable strict enforcement of compliance
against VirtIO Version_1 backends, so as to allow to support also Legacy
VirtIO devices implementations.
Link: https://lore.kernel.org/r/20211115102910.7639-1-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a new transport channel to the SCMI firmware interface driver for
SCMI message exchange based on optee transport channel. The optee
transport is realized by connecting and invoking OP-TEE SCMI service
interface PTA.
Optee transport support (CONFIG_ARM_SCMI_TRANSPORT_OPTEE) is default
enabled when optee driver (CONFIG_OPTEE) is enabled. Effective optee
transport is setup upon OP-TEE SCMI service discovery at optee
device initialization. For this SCMI UUID is registered to the optee
bus for probing. This is done from the link_supplier operator of the
SCMI optee transport.
The optee transport can use a statically defined shared memory in
which case SCMI device tree node defines it using an "arm,scmi-shmem"
compatible phandle through property shmem. Alternatively, optee transport
allocates the shared memory buffer from the optee driver when no shmem
property is defined.
The protocol used to exchange SCMI message over that shared memory is
negotiated between optee transport driver and the OP-TEE service through
capabilities exchange.
OP-TEE SCMI service is integrated in OP-TEE since its release tag 3.13.0.
The service interface is published in [1].
Link: [1] https://github.com/OP-TEE/optee_os/blob/3.13.0/lib/libutee/include/pta_scmi_client.h
Link: https://lore.kernel.org/r/20211028140009.23331-2-etienne.carriere@linaro.org
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Be more verbose avoiding to use _once flavour of dev_info/_err/_notice.
Remove usage of __func_ to identify which vqueue is referred in some error
messages and explicitly name the TX/RX vqueue.
Link: https://lore.kernel.org/r/20210916103336.7243-1-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
of_genpd_add_provider_onecell may return error, so let's propagate
its return value to caller
Link: https://lore.kernel.org/r/20211116064227.20571-1-peng.fan@oss.nxp.com
Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd")
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
According to scmi specification, the response of the discover agent request
is made of:
- int32 status
- uint32 agent_id
- uint8 name[16]
but the current implementation doesn't take into account the agent_id field
and only allocates a rx buffer of SCMI_MAX_STR_SIZE length
Allocate the correct length for rx buffer and copy the name from the
correct offset in the response.
While no error were returned until v5.15, v5.16-rc1 fails with virtio_scmi
transport channel:
| arm-scmi firmware:scmi0: SCMI Notifications - Core Enabled.
| arm-scmi firmware:scmi0: SCMI Protocol v2.0 'Linaro:PMWG' Firmware version 0x2090000
| scmi-virtio virtio0: tx:used len 28 is larger than in buflen 24
Link: https://lore.kernel.org/r/20211117081856.9932-1-vincent.guittot@linaro.org
Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol")
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
During channel setup a failure in the call of scmi_vio_feed_vq_rx() leads
to an attempt to access a dev pointer by dereferencing vioch->cinfo at
a time when vioch->cinfo has still to be initialized.
Fix it by providing the device reference directly to scmi_vio_feed_vq_rx.
Link: https://lore.kernel.org/r/20211112180705.41601-1-cristian.marussi@arm.com
Fixes: 46abe13b5e3db ("firmware: arm_scmi: Add virtio transport")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Only one single SCMI Virtio device is currently supported by this driver
and it is referenced using a static global variable which is initialized
once for all during probing and nullified at virtio device removal.
Add proper SMP barriers to protect accesses to such device reference to
ensure that the initialzation state of such device is correctly observed by
all PEs at any time.
Return -EBUSY, instead of -EINVAL, and a descriptive error message if more
than one SCMI Virtio device is ever found and probed.
Link: https://lore.kernel.org/r/20210916103336.7243-3-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Remove unneeded nested irqsave/irqrestore spinlocks.
Add also a few descriptive comments to explain better the system behaviour
at shutdown time.
Link: https://lore.kernel.org/r/20210916103336.7243-2-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
virtio_scmi_exit() is only called from __exit function, so the annotation
is correct, but when the driver is built-in, the section gets discarded
and the reference from a callback pointer causes a link-time error:
`virtio_scmi_exit' referenced in section `.rodata' of drivers/firmware/arm_scmi/virtio.o:
defined in discarded section `.exit.text' of drivers/firmware/arm_scmi/virtio.o
I could not figure out a better workaround, so let's just remove that
annotation even if it wastes a couple of bytes in .text.
Link: https://lore.kernel.org/r/20210920100301.1466486-2-arnd@kernel.org
Fixes: 46abe13b5e3d ("firmware: arm_scmi: Add virtio transport")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
ARM_SCMI_TRANSPORT_VIRTIO is a 'bool' Kconfig used to include support for
the SCMI virtio transport inside the core SCMI stack; a bare transport
dependency attached here to this option, though, cannot be properly
propagated to the parent ARM_SCMI_PROTOCOL option and, as a result, it is
currently possible to configure a Kernel where SCMI core is builtin
and includes support for virtio while VirtIO core is =m.
This allowed combination breaks linking:
ARM_SCMI_PROTOCOL=y
ARM_SCMI_TRANSPORT_VIRTIO=y
VIRTIO=m
Bind the dependency in ARM_SCMI_TRANSPORT_VIRTIO to the chosen kind of
compilation of ARM_SCMI_PROTOCOL.
Link: https://lore.kernel.org/r/20210816141609.41751-1-cristian.marussi@arm.com
Fixes: 46abe13b5e3d ("firmware: arm_scmi: Add virtio transport")
Reported-by: kernel test robot <lkp@intel.com>
Suggested-by: Arnd Bergmann <arnd@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
These are updates for drivers that are tied to a particular SoC,
including the correspondig device tree bindings:
- A couple of reset controller changes for unisoc, uniphier, renesas
and zte platforms
- memory controller driver fixes for omap and tegra
- Rockchip io domain driver updates
- Lots of updates for qualcomm platforms, mostly touching their
firmware and power management drivers
- Tegra FUSE and firmware driver updateѕ
- Support for virtio transports in the SCMI firmware framework
- cleanup of ixp4xx drivers, towards enabling multiplatform
support and bringing it up to date with modern platforms
- Minor updates for keystone, mediatek, omap, renesas.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iD8DBQBhLz215t5GS2LDRf4RAjlHAJ473D0PymaTzv68EuPHThG+DEPifQCdGjLq
QGBB6JidIP8rtEdC+LWBB8I=
=M5+N
-----END PGP SIGNATURE-----
Merge tag 'drivers-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC driver updates from Arnd Bergmann:
"These are updates for drivers that are tied to a particular SoC,
including the correspondig device tree bindings:
- A couple of reset controller changes for unisoc, uniphier, renesas
and zte platforms
- memory controller driver fixes for omap and tegra
- Rockchip io domain driver updates
- Lots of updates for qualcomm platforms, mostly touching their
firmware and power management drivers
- Tegra FUSE and firmware driver updateѕ
- Support for virtio transports in the SCMI firmware framework
- cleanup of ixp4xx drivers, towards enabling multiplatform support
and bringing it up to date with modern platforms
- Minor updates for keystone, mediatek, omap, renesas"
* tag 'drivers-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (96 commits)
reset: simple: remove ZTE details in Kconfig help
soc: rockchip: io-domain: Remove unneeded semicolon
soc: rockchip: io-domain: add rk3568 support
dt-bindings: power: add rk3568-pmu-io-domain support
bus: ixp4xx: return on error in ixp4xx_exp_probe()
soc: renesas: Prefer memcpy() over strcpy()
firmware: tegra: Stop using seq_get_buf()
soc/tegra: fuse: Enable fuse clock on suspend for Tegra124
soc/tegra: fuse: Add runtime PM support
soc/tegra: fuse: Clear fuse->clk on driver probe failure
soc/tegra: pmc: Prevent racing with cpuilde driver
soc/tegra: bpmp: Remove unused including <linux/version.h>
dt-bindings: soc: ti: pruss: Add dma-coherent property
soc: ti: Remove pm_runtime_irq_safe() usage for smartreflex
soc: ti: pruss: Enable support for ICSSG subsystems on K3 AM64x SoCs
dt-bindings: soc: ti: pruss: Update bindings for K3 AM64x SoCs
firmware: arm_scmi: Use WARN_ON() to check configured transports
firmware: arm_scmi: Fix boolconv.cocci warnings
soc: mediatek: mmsys: Fix missing UFOE component in mt8173 table routing
soc: mediatek: mmsys: add MT8365 support
...
Use a WARN_ON() when SCMI stack is loaded to check the consistency of
configured SCMI transports instead of the current compile-time check
BUILD_BUG_ON() to avoid breaking bot-builds on random bad configs.
Bail-out early and noisy during SCMI stack initialization if no transport
was enabled in configuration since SCMI cannot work without at least one
enabled transport and such constraint cannot be enforced in Kconfig due to
circular dependency issues.
Link: https://lore.kernel.org/r/20210809092245.8730-1-cristian.marussi@arm.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
drivers/firmware/arm_scmi/virtio.c:225:40-45: WARNING: conversion to bool not needed here
Remove unneeded conversion to bool
Semantic patch information:
Relational and logical operators evaluate to bool,
explicit conversion is overly verbose and unneeded.
Generated by: scripts/coccinelle/misc/boolconv.cocci
Link: https://lore.kernel.org/r/20210807173127.GA43248@a24dbc127934
CC: Igor Skalkin <igor.skalkin@opensynergy.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Mailbox channels for the base protocol are setup during probe.
There can be a scenario where probe fails to acquire the base
protocol due to a timeout leading to cleaning up of all device
managed memory including the scmi_mailbox structure setup during
mailbox_chan_setup function.
| arm-scmi soc:qcom,scmi: timed out in resp(caller: version_get+0x84/0x140)
| arm-scmi soc:qcom,scmi: unable to communicate with SCMI
| arm-scmi: probe of soc:qcom,scmi failed with error -110
Now when a message arrives at cpu slightly after the timeout, the mailbox
controller will try to call the rx_callback of the client and might end
up accessing freed memory.
| rx_callback+0x24/0x160
| mbox_chan_received_data+0x44/0x94
| __handle_irq_event_percpu+0xd4/0x240
This patch frees the mailbox channels setup during probe and adds some more
error handling in case the probe fails.
Link: https://lore.kernel.org/r/1628111999-21595-1-git-send-email-rishabhb@codeaurora.org
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
This transport enables communications with an SCMI platform through virtio;
the SCMI platform will be represented by a virtio device.
Implement an SCMI virtio driver according to the virtio SCMI device spec
[1]. Virtio device id 32 has been reserved for the SCMI device [2].
The virtio transport has one Tx channel (virtio cmdq, A2P channel) and
at most one Rx channel (virtio eventq, P2A channel).
The following feature bit defined in [1] is not implemented:
VIRTIO_SCMI_F_SHARED_MEMORY.
The number of messages which can be pending simultaneously is restricted
according to the virtqueue capacity negotiated at probing time.
As soon as Rx channel message buffers are allocated or have been read
out by the arm-scmi driver, feed them back to the virtio device.
Since some virtio devices may not have the short response time exhibited
by SCMI platforms using other transports, set a generous response
timeout.
SCMI polling mode is not supported by this virtio transport since deemed
meaningless: polling mode operation is offered by the SCMI core to those
transports that could not provide a completion interrupt on the TX path,
which is never the case for virtio whose core callbacks can easily call
into core scmi_rx_callback upon messages reception.
[1] https://github.com/oasis-tcs/virtio-spec/blob/master/virtio-scmi.tex
[2] https://www.oasis-open.org/committees/ballot.php?id=3496
Link: https://lore.kernel.org/r/20210803131024.40280-16-cristian.marussi@arm.com
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: simplified driver logic, changed link_supplier and channel
available/setup logic, removed dummy callbacks ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a new opaque void *priv parameter to scmi_rx_callback which can be
optionally provided by the transport layer when invoking scmi_rx_callback
and that will be passed back to the transport layer in xfer->priv.
This can be used by transports that needs to keep track of their specific
data structures together with the valid xfers.
Link: https://lore.kernel.org/r/20210803131024.40280-15-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Some transports are also effectively registered with other kernel subsystem
in order to be properly probed and initialized; as a consequence such kind
of transports, and their related devices, might still not have been probed
and initialized at the time the main SCMI core driver is probed.
Add an optional .link_supplier() transport operation which can be used by
the core SCMI stack to dynamically check if the transport is ready and
dynamically link its device to the SCMI platform instance device.
Link: https://lore.kernel.org/r/20210803131024.40280-13-cristian.marussi@arm.com
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: reworded commit message ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add abstractions for future transports using message passing, such as
virtio. Derive the abstractions from the shared memory abstractions.
Abstract the transport SDU through the opaque struct scmi_msg_payld.
Also enable the transport to determine all other required information
about the transport SDU.
Link: https://lore.kernel.org/r/20210803131024.40280-12-cristian.marussi@arm.com
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: Adapted to new SCMI Kconfig layout, updated Copyrights ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The maximum number of simultaneously pending messages is a transport
specific quantity that is usually described statically in struct scmi_desc.
Some transports, though, can calculate such number only at run-time after
some initial transport specific setup and probing is completed; moreover
the resulting max message numbers could also be different between rx and
tx channels.
Add an optional get_max_msg() operation so that a transport can report more
accurate max message numbers for each channel type.
The value in scmi_desc.max_msg is still used as default when transport does
not provide any get_max_msg() method.
Link: https://lore.kernel.org/r/20210803131024.40280-11-cristian.marussi@arm.com
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Co-developed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: refactored how get_max_msg() is used to minimize core changes ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Upcoming new SCMI transports won't need any kind of shared memory support.
Compile shmem.c only if a shmem based transport is selected.
Link: https://lore.kernel.org/r/20210803131024.40280-10-cristian.marussi@arm.com
Co-developed-by: Peter Hilber <peter.hilber@opensynergy.com>
Signed-off-by: Igor Skalkin <igor.skalkin@opensynergy.com>
[ Peter: Adapted patch for submission to upstream. ]
Signed-off-by: Peter Hilber <peter.hilber@opensynergy.com>
[ Cristian: Adapted patch/commit_msg to new SCMI Kconfig layout ]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add configuration options to be able to select which SCMI transports have
to be compiled into the SCMI stack.
Mailbox and SMC are by default enabled if their related dependencies are
satisfied.
While doing that move all SCMI related config options in their own
dedicated submenu.
Link: https://lore.kernel.org/r/20210803131024.40280-9-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add a check for the presence of .poll_done transport operation so that
transports that do not need to support polling mode have no need to provide
a dummy .poll_done callback either and polling mode can be disabled in the
SCMI core for that tranport.
Link: https://lore.kernel.org/r/20210803131024.40280-8-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Make transport operation .clear_channel optional since some transports
do not need it and so avoid to have them implement dummy callbacks.
Link: https://lore.kernel.org/r/20210803131024.40280-7-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
