Arm SCMI updates for v6.7
Main additions this time include:
1. SCMI v3.2 clock configuration support:
This helps to retrieve the enabled state of a clock as well as allow
to set OEM specific clock configurations.
2. Support for generic performance scaling(DVFS):
The current SCMI DVFS support is limited to the CPUs in the kernel.
This extension enables it to used for all kind of devices and not
only for the CPUs. It updates the SCMI cpufreq to utilize the power
domain bindings. It also adds a more generic SCMI performance domain
based on the genpd framework that as be used for all the non-CPU
devices.
3. Extend the generic performance scaling(DVFS) support for firmware
driver OPPs:
Consumer drivers for devices that are attached to the SCMI performance
domain can't make use of the current OPP library to scale performance
as the OPPs are firmware driven and often obtained from the firmware
rather than the device tree. These changes extend the generic OPP
and genpd PM domain frameworks to identify and utilise these firmware
driven OPPs.
4. SCMI v3.2 clock parent support:
This enables the support for discovering and changing parent clocks
and extending the SCMI clk driver to use the same.
5. Qualcom SMC/HVC transport support:
The Qualcomm virtual platforms require capability id in the hypervisor
call to identify which doorbell to assert when supporting multiple
SMC/HVC based SCMI transport channels. Extra parameter is added to
support the same and the same is obtained at the fixed address in the
shared memory which is initialised by the firmware.
6. Move the existing SCMI power domain driver under drivers/pmdomain
Apart from the above main changes, it also include couple of minor fixes
and cosmetic reworks.
* tag 'scmi-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: (37 commits)
firmware: arm_scmi: Add qcom smc/hvc transport support
dt-bindings: arm: Add new compatible for smc/hvc transport for SCMI
firmware: arm_scmi: Convert u32 to unsigned long to align with arm_smccc_1_1_invoke()
clk: scmi: Add support for clock {set,get}_parent
firmware: arm_scmi: Add support for clock parents
clk: scmi: Free scmi_clk allocated when the clocks with invalid info are skipped
firmware: arm_scpi: Use device_get_match_data()
firmware: arm_scmi: Add generic OPP support to the SCMI performance domain
firmware: arm_scmi: Specify the performance level when adding an OPP
firmware: arm_scmi: Simplify error path in scmi_dvfs_device_opps_add()
OPP: Extend support for the opp-level beyond required-opps
OPP: Switch to use dev_pm_domain_set_performance_state()
OPP: Extend dev_pm_opp_data with a level
OPP: Add dev_pm_opp_add_dynamic() to allow more flexibility
PM: domains: Implement the ->set_performance_state() callback for genpd
PM: domains: Introduce dev_pm_domain_set_performance_state()
firmware: arm_scmi: Rename scmi_{msg_,}clock_config_{get,set}_{2,21}
firmware: arm_scmi: Do not use !! on boolean when setting msg->flags
firmware: arm_scmi: Move power-domain driver to the pmdomain dir
pmdomain: arm: Add the SCMI performance domain
...
Link: https://lore.kernel.org/r/20231010124347.1620040-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This change adds the support for SCMI message exchange on Qualcomm
virtual platforms.
The hypervisor associates an object-id also known as capability-id
with each smc/hvc doorbell object. The capability-id is used to
identify the doorbell from the VM's capability namespace, similar
to a file-descriptor.
The hypervisor, in addition to the function-id, expects the capability-id
to be passed in x1 register when SMC/HVC call is invoked.
The capability-id is allocated by the hypervisor on bootup and is stored in
the shmem region by the firmware before starting Linux.
Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/20231009191437.27926-3-quic_nkela@quicinc.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Both pc->async_powercap_cap_set and ignore_dresp are already boolean.
Use of !! on them is obviously dubious.
Sparse reports:
drivers/firmware/arm_scmi/powercap.c:363:17: warning: dubious: x & !y
drivers/firmware/arm_scmi/powercap.c:363:17: warning: dubious: x & !y
Remove the unnecessary !! and get rid of the warning.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230921085257.3125744-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
To enable support for performance scaling (DVFS) for generic devices with
the SCMI performance protocol, let's add an SCMI performance domain. This
is being modelled as a genpd provider, with support for performance scaling
through genpd's ->set_performance_state() callback.
Note that, this adds the initial support that allows consumer drivers for
attached devices, to vote for a new performance state via calling the
dev_pm_genpd_set_performance_state(). However, this should be avoided as
it's in most cases preferred to use the OPP library to vote for a new OPP
instead. The support using the OPP library isn't part of this change, but
needs to be implemented from subsequent changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230919121605.7304-1-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Most scmi_perf_proto_ops are already using an "u32 domain" as an
in-parameter to indicate what performance domain we shall operate upon.
However, some of the ops are using a "struct device *dev", which means that
an additional OF parsing is needed each time the perf ops gets called, to
find the corresponding domain-id.
To avoid the above, but also to make the code more consistent, let's
replace the in-parameter "struct device *dev" with an "u32 domain". Note
that, this requires us to make some corresponding changes to the scmi
cpufreq driver, so let's do that too.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-5-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Similar to other protocol ops, it's useful for an scmi module driver to get
some generic information of a performance domain. Therefore, let's add a
new callback to provide this information. The information is currently
limited to the name of the performance domain and whether the set-level
operation is supported, although this can easily be extended if we find the
need for it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230825112633.236607-3-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Support clock .state_get operation against SCMI platform servers that do
not support v3.2 CONFIG_GET dedicated command: while talking with these
platforms the command CLOCK_ATTRIBUTES can be used to gather the current
clock states.
Note that, in case of shared resources, the retrieved clock state 'flavour'
(virtual vs physical) depends on the backend SCMI platform server specific
kind of implementation.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230826125308.462328-5-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI v3.2 introduces a new clock CONFIG_SET message format that can
optionally carry also OEM specific configuration values beside the usual
clock enable/disable requests.
Refactor internal helpers and add support to use such new format when
talking to a v3.2 compliant SCMI platform.
Support existing enable/disable operations across different clock protocol
versions: this patch still does not add protocol operations to support the
new OEM specific optional configuration capabilities.
No functional change for the SCMI drivers users of the related enable and
disable clock operations.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230826125308.462328-3-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI clock enable/disable operations come in 2 different flavours which
simply just differ in how the underlying SCMI transactions is carried on:
atomic or not.
Currently we expose such SCMI operations through 2 distinctly named
wrappers, that, in turn, are wrapped into another couple of similarly and
distinctly named callbacks inside SCMI clock driver user.
Reduce the churn of duplicated wrappers by adding a param to SCMI clock
enable/disable operations to ask for atomic operation while removing the
_atomic version of such operations.
No functional change.
CC: Michael Turquette <mturquette@baylibre.com>
CC: Stephen Boyd <sboyd@kernel.org>
CC: linux-clk@vger.kernel.org
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20230826125308.462328-2-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Pull ARM SoC cleanups from Arnd Bergmann:
"These are all minor cleanups for platform specific code in arch/arm/
and some of the associated drivers. The majority of these are work
done by Rob Herring to improve the way devicetreee header files are
handled"
* tag 'soc-arm-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (49 commits)
ARM: davinci: Drop unused includes
ARM: s5pv210: Explicitly include correct DT includes
ARM: dove: Drop unused includes
ARM: mvebu: Explicitly include correct DT includes
Documentation/process: maintainer-soc: document dtbs_check requirement for Samsung
MAINTAINER: samsung: document dtbs_check requirement for Samsung
Documentation/process: maintainer-soc: add clean platforms profile
MAINTAINERS: soc: reference maintainer profile
ARM: nspire: Remove unused header file mmio.h
ARM: nspire: Use syscon-reboot to handle restart
soc: fsl: Explicitly include correct DT includes
soc: xilinx: Explicitly include correct DT includes
soc: sunxi: Explicitly include correct DT includes
soc: rockchip: Explicitly include correct DT includes
soc: mediatek: Explicitly include correct DT includes
soc: aspeed: Explicitly include correct DT includes
firmware: Explicitly include correct DT includes
bus: Explicitly include correct DT includes
ARM: spear: Explicitly include correct DT includes
ARM: mvebu: Explicitly include correct DT includes
...
Pull ARM SoC driver updates from Arnd Bergmann:
"The main change this time was the introduction of the drivers/genpd
subsystem that gets split out from drivers/soc to keep common
functionality together.
The SCMI driver subsystem gets an update to version 3.2 of the
specification. There are also updates to memory, reset and other
firmware drivers.
On the soc driver side, the updates are mostly cleanups across a
number of Arm platforms. On driver for loongarch adds power management
for DT based systems, another driver is for HiSilicon's Arm server
chips with their HCCS system health interface.
The remaining updates for the most part add support for additional
hardware in existing drivers or contain minor cleanups. Most of these
are for the Qualcomm Snapdragon platform"
* tag 'soc-drivers-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (136 commits)
bus: fsl-mc: Use common ranges functions
soc: kunpeng_hccs: fix some sparse warnings about incorrect type
soc: loongson2_pm: add power management support
soc: dt-bindings: add loongson-2 pm
soc: rockchip: grf: Fix SDMMC not working on RK3588 with bus-width > 1
genpd: rockchip: Add PD_VO entry for rv1126
bus: ti-sysc: Fix cast to enum warning
soc: kunpeng_hccs: add MAILBOX dependency
MAINTAINERS: remove OXNAS entry
dt-bindings: interrupt-controller: arm,versatile-fpga-irq: mark oxnas compatible as deprecated
irqchip: irq-versatile-fpga: remove obsolete oxnas compatible
soc: qcom: aoss: Tidy up qmp_send() callers
soc: qcom: aoss: Format string in qmp_send()
soc: qcom: aoss: Move length requirements from caller
soc: kunpeng_hccs: fix size_t format string
soc: ti: k3-socinfo.c: Add JTAG ID for AM62PX
dt-bindings: firmware: qcom: scm: Updating VMID list
firmware: imx: scu-irq: support identifying SCU wakeup source from sysfs
firmware: imx: scu-irq: enlarge the IMX_SC_IRQ_NUM_GROUP
firmware: imx: scu-irq: add imx_scu_irq_get_status
...
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20230803-dt-header-cleanups-for-soc-v2-17-d8de2cc88bff@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
SCMI v3.2 adds PERF protocol support to optionally define performance
domains that cannot be represented on a linear scale; the platform firmware
can declare the performance levels of a domain as being 'level indexed' and
provide an indicative frequency associated to each of those levels, with
such indexes not required anymore to be contiguous nor to satisfy any
linear-scaling constraint: when level-indexing is available for a domain,
the platform will expect to deal with SCMI requests using indexes instead
of performance levels for that domain.
Add level-indexing mode support to the PERF protocol implementation while
maintaining unchanged the protocol operations interface exposed by PERF;
all the required mapping from performamce levels/frequencies to the
corresponding level indexes is carried out transparently by the core PERF
protocol support: as a consequence no change is either required in any
SCMI driver using the PERF protocol, even when using level indexing.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230717161246.1761777-3-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI transport based on SMC can optionally use an additional IRQ to
signal message completion. The associated interrupt handler is currently
allocated using devres but on shutdown the core SCMI stack will call
.chan_free() well before any managed cleanup is invoked by devres.
As a consequence, the arrival of a late reply to an in-flight pending
transaction could still trigger the interrupt handler well after the
SCMI core has cleaned up the channels, with unpleasant results.
Inhibit further message processing on the IRQ path by explicitly freeing
the IRQ inside .chan_free() callback itself.
Fixes: dd820ee21d ("firmware: arm_scmi: Augment SMC/HVC to allow optional interrupt")
Reported-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230719173533.2739319-1-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Pull ARM SoC driver updates from Arnd Bergmann:
"Nothing surprising in the SoC specific drivers, with the usual
updates:
- Added or improved SoC driver support for Tegra234, Exynos4121,
RK3588, as well as multiple Mediatek and Qualcomm chips
- SCMI firmware gains support for multiple SMC/HVC transport and
version 3.2 of the protocol
- Cleanups amd minor changes for the reset controller, memory
controller, firmware and sram drivers
- Minor changes to amd/xilinx, samsung, tegra, nxp, ti, qualcomm,
amlogic and renesas SoC specific drivers"
* tag 'soc-drivers-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (118 commits)
dt-bindings: interrupt-controller: Convert Amlogic Meson GPIO interrupt controller binding
MAINTAINERS: add PHY-related files to Amlogic SoC file list
drivers: meson: secure-pwrc: always enable DMA domain
tee: optee: Use kmemdup() to replace kmalloc + memcpy
soc: qcom: geni-se: Do not bother about enable/disable of interrupts in secondary sequencer
dt-bindings: sram: qcom,imem: document qdu1000
soc: qcom: icc-bwmon: Fix MSM8998 count unit
dt-bindings: soc: qcom,rpmh-rsc: Require power-domains
soc: qcom: socinfo: Add Soc ID for IPQ5300
dt-bindings: arm: qcom,ids: add SoC ID for IPQ5300
soc: qcom: Fix a IS_ERR() vs NULL bug in probe
soc: qcom: socinfo: Add support for new fields in revision 19
soc: qcom: socinfo: Add support for new fields in revision 18
dt-bindings: firmware: scm: Add compatible for SDX75
soc: qcom: mdt_loader: Fix split image detection
dt-bindings: memory-controllers: drop unneeded quotes
soc: rockchip: dtpm: use C99 array init syntax
firmware: tegra: bpmp: Add support for DRAM MRQ GSCs
soc/tegra: pmc: Use devm_clk_notifier_register()
soc/tegra: pmc: Simplify debugfs initialization
...
scmi_xfer_raw_worker_init() is specifying a flag, WQ_SYSFS, as @max_active.
Fix it by or'ing WQ_SYSFS into @flags so that it actually enables sysfs
interface and using 0 for @max_active for the default setting.
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: 3c3d818a93 ("firmware: arm_scmi: Add core raw transmission support")
Link: https://lore.kernel.org/r/ZEGTnajiQm7mkkZS@slm.duckdns.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Arm SCMI updates for v6.4
The main and only new addition this time around is the support for
unidirectional mailbox channels. SCMI communicates between the agent
and the platform using one bidirectional 'a2p' channel used by the agent
to send SCMI commands and synchronously receive the related replies, and
an optional 'p2a' unidirectional channel used to asynchronously receive
delayed responses and notifications emitted from the platform.
In order to support platforms that support only unidirectional mailbox
hardware channels, the existing bindings are extended to support the
same. Both bidirectional and unidirectional channels support for the
SCMI mailbox can coexist. The correct and effective combination of
defined 'mboxes' and 'shmem' descriptors determines the type of the
mailbox channel.
This also contains a fix for the transfers allocation on Rx channel
especially when the base protocol doesn't use Rx channel while some
of the protocols can have dedicated Rx channels.
* tag 'scmi-updates-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_scmi: Add support for unidirectional mailbox channels
dt-bindings: firmware: arm,scmi: Support mailboxes unidirectional channels
firmware: arm_scmi: Fix xfers allocation on Rx channel
firmware: arm_scmi: Use the bitmap API to allocate bitmaps
firmware: arm_scmi: Fix device node validation for mailbox transport
firmware: arm_scmi: Fix raw coexistence mode behaviour on failure path
firmware: arm_scmi: Remove duplicate include header inclusion
firmware: arm_scmi: Return a literal instead of a variable
firmware: arm_scmi: Clean up a return statement in scmi_probe
Link: https://lore.kernel.org/r/20230417145743.1904318-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Two distinct pools of xfer descriptors are allocated at initialization
time: one (Tx) used to provide xfers to track commands and their replies
(or delayed replies) and another (Rx) to pick xfers from to be used for
processing notifications.
Such pools, though, are allocated globally to be used by the whole SCMI
instance, they are not allocated per-channel and as such the allocation of
notifications xfers cannot be simply skipped if no Rx channel was found for
the base protocol common channel, because there could be defined more
optional per-protocol dedicated channels that instead support Rx channels.
Change the conditional check to skip allocation for the notification pool
only if no Rx channel has been detected on any per-channel protocol at all.
Fixes: 4ebd8f6dea ("firmware: arm_scmi: Add receive buffer support for notifications")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230326203449.3492948-1-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
When mailboxes are used as a transport it is possible to setup the SCMI
transport layer, depending on the underlying channels configuration, to use
one or two mailboxes, associated, respectively, to one or two, distinct,
shared memory areas: any other combination should be treated as invalid.
Add more strict checking of SCMI mailbox transport device node descriptors.
Fixes: 5c8a47a5a9 ("firmware: arm_scmi: Make scmi core independent of the transport type")
Cc: <stable@vger.kernel.org> # 4.19
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230307162324.891866-1-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
When SCMI raw coexistence mode is enabled make the core stack probe
successfully even when the initial base protocol exchanges with the
platform/server failed.
This behaviour enables the system to boot with a broken regular SCMI
stack but with a fully functional and accessible SCMI raw debugfs
interface that can be used to further debug the issue.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230223152330.2707260-1-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Pull ARM SoC driver updates from Arnd Bergmann:
"As usual, there are lots of minor driver changes across SoC platforms
from NXP, Amlogic, AMD Zynq, Mediatek, Qualcomm, Apple and Samsung.
These usually add support for additional chip variations in existing
drivers, but also add features or bugfixes.
The SCMI firmware subsystem gains a unified raw userspace interface
through debugfs, which can be used for validation purposes.
Newly added drivers include:
- New power management drivers for StarFive JH7110, Allwinner D1 and
Renesas RZ/V2M
- A driver for Qualcomm battery and power supply status
- A SoC device driver for identifying Nuvoton WPCM450 chips
- A regulator coupler driver for Mediatek MT81xxv"
* tag 'soc-drivers-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (165 commits)
power: supply: Introduce Qualcomm PMIC GLINK power supply
soc: apple: rtkit: Do not copy the reg state structure to the stack
soc: sunxi: SUN20I_PPU should depend on PM
memory: renesas-rpc-if: Remove redundant division of dummy
soc: qcom: socinfo: Add IDs for IPQ5332 and its variant
dt-bindings: arm: qcom,ids: Add IDs for IPQ5332 and its variant
dt-bindings: power: qcom,rpmpd: add RPMH_REGULATOR_LEVEL_LOW_SVS_L1
firmware: qcom_scm: Move qcom_scm.h to include/linux/firmware/qcom/
MAINTAINERS: Update qcom CPR maintainer entry
dt-bindings: firmware: document Qualcomm SM8550 SCM
dt-bindings: firmware: qcom,scm: add qcom,scm-sa8775p compatible
soc: qcom: socinfo: Add Soc IDs for IPQ8064 and variants
dt-bindings: arm: qcom,ids: Add Soc IDs for IPQ8064 and variants
soc: qcom: socinfo: Add support for new field in revision 17
soc: qcom: smd-rpm: Add IPQ9574 compatible
soc: qcom: pmic_glink: remove redundant calculation of svid
soc: qcom: stats: Populate all subsystem debugfs files
dt-bindings: soc: qcom,rpmh-rsc: Update to allow for generic nodes
soc: qcom: pmic_glink: add CONFIG_NET/CONFIG_OF dependencies
soc: qcom: pmic_glink: Introduce altmode support
...
When the raw support is enabled and configured in co-existence mode the
normal SCMI drivers are allowed to register with the SCMI core and
operate as usual alongside the raw operations.
SCMI normal and raw messages will be kept segregated from each other,
but only at the transaction level. Any further possible interference at
the protocol layer will have instead to be handled by the user to attain
reliable results while using the raw transactions.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lore.kernel.org/r/20230118121426.492864-17-cristian.marussi@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
