The main addition is the initial support for the notifications and
memory transaction descriptor changes added in FF-A v1.1 specification.
The notification mechanism enables a requester/sender endpoint to notify
a service provider/receiver endpoint about an event with non-blocking
semantics. A notification is akin to the doorbell between two endpoints
in a communication protocol that is based upon the doorbell/mailbox
mechanism.
The framework is responsible for the delivery of the notification from
the ender to the receiver without blocking the sender. The receiver
endpoint relies on the OS scheduler for allocation of CPU cycles to
handle a notification.
OS is referred as the receiver’s scheduler in the context of notifications.
The framework is responsible for informing the receiver’s scheduler that
the receiver must be run since it has a pending notification.
The series also includes support for the new format of memory transaction
descriptors introduced in v1.1 specification.
Apart from the main additions, it includes minor fixes to re-enable FF-A
drivers usage of 32bit mode of messaging and kernel warning due to the
missing assignment of IDR allocation ID to the FFA device. It also adds
emitting 'modalias' to the base attribute of FF-A devices.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmUlJuUACgkQAEG6vDF+
4pinPRAAzLFtehLNhpC2BsEbvdJo/bSeGl1OAricml3gyU45W7AamAPuplA9E871
GxXMYbH5+mnqz5cHaYBb8KGm5dRENrtKgrwMITg3jOlqdz9HWy2MLgbSmvqbXNsU
5O8iZDvFOTCMLSEI6gWnaiKRpAzDSFu0/FH86xv+9+pbjmjL3iDjFlbxbGLFYk+L
gqHLdx4iW6aD6geC2n8oDO6UWCNLaHpXaJSAE6pfh/7pkuKMWYjVwivKxrMA9Saw
WjoyBdjUgir9w6qJauR94MGMnbPTd378MzBrEWMo04I2ubLCVwiPVDEEu7jZGrBV
2n5DD8/0fSak9KEEozRKnj9umhmvHN9Of72qBLNZ0K4zmq8Fs00woXIlnUNH0dcZ
qZN/ZEDXpD51OsgMH+ojojaqFEcFynEQIQjibiv1Ju16F+1PIABCyODgb58fIa71
WvRUXVttkml6boY7KqGIDRiSRfEIZfoWqKucFpEbRwCXLLqc2VJ4UYUiYB1B3fD1
g3ZuQXhurwfLG7SwrKK4KWFLHTSNj4IuixeqsAM+PYyTE5iquP3xpqYgbb99n9VT
SWCyQdw0e+DyAhzmx0ZZZtCO2f54JQY852jHSkQFQsRNcK+h2exYxjIE7NfgfIGG
H1NvJjumunOZEOZr+Wwz74wDJDMoLvMJTGr4ovIkNn/xb+4lcHU=
=bHXY
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUto10ACgkQYKtH/8kJ
UidIlw//e0ZkLIffq0d9svTie4NHxxb8AEu8sqnxr1HcinpCfa2Cwi6utt+y5XXc
Ti7T7Jj/BKnwTfNXw6REvKplBhMGMQFkKcrX7lSnDpPhzCj8Ls0j78ac52KfmVpi
HmzRchsdKtKBYKZOBA+gnBABu38O9QvuteDKJXx8vzowztYJpHc/UmE5qYHwVWDT
kKqNzFo34zvLS/ephZZFV113ji3foQiOFCWtx408nfcUvW/g8H3xRp6njPlmP0Ue
PhFbR3qsEV/nLTafypACsxSappuHngtInXZA2cpA6LKc0oS426rTvY6i167amOq4
ktcqmVdD6mbNEApTsB5O32TK+AI2rPvCh6OCS0x0M6+yWhZVGjZXZgzr1Ma3uphz
dD3HcXYEaMHJQVAu8npVo5x3UEApOts+SX7QY4IlekzCzr1guhnWKnmxTS8jYx2Z
HzwJatmvb+ENzbZHX2R1Y53keue/oq0AkYva0gNVK6F7ELjowDmV0l02qm5G0aBC
3Pa1KEYpb34qagwknzFjGubBrJcPX/sdzt1KWUoCLDbveb+HCaPKlGipOs3PjMLy
s/IeGH7LED3XbfxDpsRuzkwgtKzuvmdaWfgccx56rPjMlh763fvS16DB2PUiJ4FP
qv7fu98hvVG2Z2eFVHib3FT6isw4NVmsXRzc6uW54nVKj2pQmRY=
=QaJo
-----END PGP SIGNATURE-----
Merge tag 'ffa-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm FF-A updates for v6.7
The main addition is the initial support for the notifications and
memory transaction descriptor changes added in FF-A v1.1 specification.
The notification mechanism enables a requester/sender endpoint to notify
a service provider/receiver endpoint about an event with non-blocking
semantics. A notification is akin to the doorbell between two endpoints
in a communication protocol that is based upon the doorbell/mailbox
mechanism.
The framework is responsible for the delivery of the notification from
the ender to the receiver without blocking the sender. The receiver
endpoint relies on the OS scheduler for allocation of CPU cycles to
handle a notification.
OS is referred as the receiver’s scheduler in the context of notifications.
The framework is responsible for informing the receiver’s scheduler that
the receiver must be run since it has a pending notification.
The series also includes support for the new format of memory transaction
descriptors introduced in v1.1 specification.
Apart from the main additions, it includes minor fixes to re-enable FF-A
drivers usage of 32bit mode of messaging and kernel warning due to the
missing assignment of IDR allocation ID to the FFA device. It also adds
emitting 'modalias' to the base attribute of FF-A devices.
* tag 'ffa-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Upgrade the driver version to v1.1
firmware: arm_ffa: Update memory descriptor to support v1.1 format
firmware: arm_ffa: Switch to using ffa_mem_desc_offset() accessor
KVM: arm64: FFA: Remove access of endpoint memory access descriptor array
firmware: arm_ffa: Simplify the computation of transmit and fragment length
firmware: arm_ffa: Add notification handling mechanism
firmware: arm_ffa: Add interface to send a notification to a given partition
firmware: arm_ffa: Add interfaces to request notification callbacks
firmware: arm_ffa: Add schedule receiver callback mechanism
firmware: arm_ffa: Initial support for scheduler receiver interrupt
firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface
firmware: arm_ffa: Implement the FFA_NOTIFICATION_GET interface
firmware: arm_ffa: Implement the FFA_NOTIFICATION_SET interface
firmware: arm_ffa: Implement the FFA_RUN interface
firmware: arm_ffa: Implement the notification bind and unbind interface
firmware: arm_ffa: Implement notification bitmap create and destroy interfaces
firmware: arm_ffa: Update the FF-A command list with v1.1 additions
firmware: arm_ffa: Emit modalias for FF-A devices
firmware: arm_ffa: Allow the FF-A drivers to use 32bit mode of messaging
firmware: arm_ffa: Assign the missing IDR allocation ID to the FFA device
Link: https://lore.kernel.org/r/20231010124354.1620064-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmUlJnAACgkQAEG6vDF+
4phxrw/+KLuLGg0QXTps4trI1E9cTAivpnEe6sWM27TZ792k6TecqWbRSJyvkrtg
MB9R9bIQobgGrQ2iFH+DQ+MOxjHI5qraoPV7rxcN+TzDlRsRJ6U51buFXyZpLvrp
BtcHgKVZ+Xhi9jCxykMJ18XfJv6Fm6D7/B0PCsBC0nOC2BQdq0mxZamEiiBKFiSK
6jtPXVBPracguush3rYVVio70O0ReIxMacIUAy3Oi5bH01DOx9lg2781KBBtrWKg
4RdnQS3uwUIpGn7cBn+Mmj/kh2QzKguRkdhuaFImgBI49+DVWsgQ05IstF1TA1SG
BlUWZOBr/CvcDH7xAc5FVJaIqbNvKQq4dss91AiXqmz2dzOCwJ+F1JafwUY9jLmI
fS6SfyDaSLMpx8SPDGVWippgpHWY/3dqtBxoqOvILTiYDz7ZXPWUeavn6dtr9gTU
nDWZNN6bj9EpTzVjSzMeCIiAjyjd2SGDyL9iuhUqA8pw4fidTJvbSpcAUOdkN7F5
coNZUlzv8pYB8mlBmCO4kETlTesQdt5ZjdTzCE529BuErGAwBqq/XZ/x9mhXfzwS
ojBwbgcejjnSFRC5XoW+LnZpruL5m1e+fe7aUfAcCSM/MqYOLQgKryT8mJOJnV0/
5H/WwBYeX+OxlLa0+znGzPChk4OgukARAA+oJ401e7gNHZg7DVw=
=IbXh
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUtovkACgkQYKtH/8kJ
UierUQ/9GT2ZV3lmuumsRudWVT0Uhe8ktCQElzaA7H6rHFYLMogYkVeEa97HhmN6
sFIQ8BdsPyLl8IIjLN/uGNcz3JjbjQjnZoiIjHrwquWKDLe1KsKZeb6SGwcWn4nG
c/e+CPVg7bLoUQnPJrAXQ9ksZ+1EsieuujVC0iYVWYKrauXYSNq3/H5QhVJlYDEs
c6MYoOrFrz9kP4Ecqo5oYCmd5l2bANYIHP6cOk2rTvJgO6dsT9QmEw2djmVadGHj
cQZd+kt0Y8Iezn+cX4kwq8WYl0YOk9+OLsjtIozxhRcglTxMmpBSCdFxAV2LRjiS
12tp2HJMNQgx5c187CCckoeoIpkjSvTJhzRHBxnzb/wzonaGm42ERCu93vSyp6G0
xccI/rEvjiJmlrBa8up30v+zFEe7II8u2TarnkxWVQ157Ww8bdWKZPq7pKsKrxm0
tYnDhMJxosxEh6xSjurBZTJoJTnPZQKE+IUAClpCUzszf1hWHeJUbo2CsfuJw7RH
3jUtM9nfSJCT6GFyM8wxwH/RP2Rt3U9olrW4zoZz7jkxHcLuOgJGQyFYgLHKrmsP
ez3zFEiGAYysoJuSy7so0KEzjLkVhqO+XFdBtctOkRJ+tajx6i1ute9oQvOqs/TJ
/CIuBl3+XECcNGm3InEI0aCillFAw69LKYupcUlNrcKJ9f0zFec=
=u9+1
-----END PGP SIGNATURE-----
Merge tag 'scmi-updates-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
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>
Just a single update to use __counted_by annotation in config bus driver
in preparation to the upcoming versions of the toolchains(GCC and Clang)
with __counted_by attribute.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmUf2VQACgkQAEG6vDF+
4pj89g//Wf4B+AozvSXxo01ggmJBtV9ha3N4Z/PLUVEH97pm63NB8iyf+vrkguhp
sMHwq6obmPyZ9CfBj0wtaBvsQVSd3Ns/oA5GiWG8jA9b7wSFvExlrZsAVr30f9TA
b7AZNJjMveRTRSVxTPtxIHA4wKOvvYvwjamXMMAzF6p6o2/DYqEhhRysTz3H4BJ8
stO2DrL3BXm/yIhFYwe8yNzFdfSmeOgH3H5eXwgt2qHmnBtvotUqgsU2uWklV9RA
ipwvsL6HPc6tUSxuoPugUSleSBBlzBUOSCZlYZCcWPPhkfpNW+kGbrfBWgYX/zLT
1xVK0e9Xg9ugKmGzFZZ36vqKWRpOsdWk9eP5Yoc12XUZz6UBy7maLSgXCRIlXe1A
BI7kZiTCJchDtnmU81G8j06oNMRuryjFLZEaQXKL7kbJ0dpVU4B+1mqDzEwG6XLI
U3attFRf5Iaz9J8axkwhVDAvEmpcZlPBGeqcTC8v+E+5EZkadqDo4k7gDWClV+u4
J5BadlKLbvulimyaCzReKx/P2eSLukpeziUb/JazuYE2ul2uD8XqhX551/lvRzfz
l8DHoCm+1uRsEi6YNDCBtqCJ7V9pxYIB9ZMaj5kkER93+02xtETNkRHrjoEPLUoJ
eCKfxhMAfFNFgJdz1vLO9OBvLxigIVFI8zWmy496yzwn1EtsOc8=
=1h5m
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUtossACgkQYKtH/8kJ
UieJeg/+OSlH8lYMWb8I8oXm812VNNlEeqYV++xSPIRiyP1wJNrPAhzFTOF1Up73
mjWTe9RfGhIsDmDWCd97MefMl2hdU8KAK9UgNJzvcKXvPYe7gQUugHHXzJAKD86E
jvJqWphyUe4zWR7QwgU6/1GrQ6NmKFWkdwcIpbthZivjgdbc3DM1emKH7Eez6YUX
Ih4/x8/OWkwbFlN1gJ8qxLFMk06KbHcEc7Nai3NliCzEhdhWxzPJY1EtjAOH6Iwn
4Ih+hFvHUYAApEKxArP+5shBYF91GR3vqjW1VYiDcBgYP17g9gDPu0LN0p7uS2lU
MUJVRn/nNE2ZC11rhfqKKI0DlKsRCdhohuu6OZ9qBb+Xx4zARtwUOPD+J0w3Fj1h
iidtdeMWUdHMA77ZHeN5hdeMALG1NRfgG69TikcfsUJV8/ZgdS7cVM+Rd4PZLIKV
SIPwMRfNnDZuRltJxJ4ccCcEPD1/k2JbMjLzV0Eizm4KSMBMx5yrkEm8K3ATUwo6
SmP1fKlu2v3f/smLhyCMeM6BolXclnXcx7VRHFkYi5pII1NMA0GRdM4Zprs5sAgj
mtrhWe4CV8ZMFPF4IdP+O0T/OeRi/Vg4SW1nglnLBc3G5ROmz7yO73K6Kfvb2P+u
Z8Woge+W2N8joeccAZnecPwf7F5cCRYOOPhtYO3aVkr6pwMlV8Y=
=qKzd
-----END PGP SIGNATURE-----
Merge tag 'vexpress-update-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm Vexpress updates for v6.7
Just a single update to use __counted_by annotation in config bus driver
in preparation to the upcoming versions of the toolchains(GCC and Clang)
with __counted_by attribute.
* tag 'vexpress-update-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
bus: vexpress-config: Annotate struct vexpress_syscfg_func with __counted_by
Link: https://lore.kernel.org/r/20231010124339.1620012-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This PR contains the patches I sent in the series available at
https://lore.kernel.org/all/20230925095532.1984344-1-u.kleine-koenig@pengutronix.de
that were not yet picked up in next as of next-20231013.
It converts all drivers below drivers/soc to let their remove callback
return void. See commit 5c5a7680e6 ("platform: Provide a remove
callback that returns no value") for the rationale.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmUrDBAACgkQj4D7WH0S
/k4SdggAk4dtkMnhFT1gUZjaYJWKibyuIWhCu6EkDTlLlefEWQFFT6NX5Vdz59i6
/XUurcZx4eVtXq89L4/BI/cTjhrrlMIFlZwtK63a1tniUh3mK6RIanIlIOQMoai+
P4B4V1RSIlj72njB6tJ8gVO2XU5W8I6hKNvZs7ZXyJp4KgRZqZyniV7os72ExJrm
H4NNcoiifRS2j1213xfyWyEA40yHj2aywGaXP7gjKm+AU4F6DxDwFJ8YhOvEnsu1
8Uda4J+Bs7+y46O9yqpLutI9W7mpBvk+2CAgzeIE+beEO221xNhgoTklvmT3DEbb
FvHcYHiNWzrpgwsNSwG+qXaSuy/vwQ==
=0IZS
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmUtolQACgkQYKtH/8kJ
UidseA/+PhpQ6ntmfjygZM2aY/WSbq3qFMTlFH17OFaGSBGcNP7gpFy5RbtpIem5
Y9jeofVmaA4nTLjkpZcJQdCiDCqw5U1Ew0P7dt+cBtnEwfDQk/OfNwaD8Zbr5i27
hG8AeY/2AiqINaxt13ZYECnwv5w+tob2ZkrvWVW0ykJdqBLO9U4lBWIFx9YvhnpV
jO0bUuDeKj34vhFzd2v6w+Py/xfJlTpgXbPgtO8AQ06kmpAk5ayj9ccqGvYXwEYw
BuO4Xht2L0yE3nQVFNuG27WXjVqAdH1lEX/KTaYFqgyj8zRHbU7dM/qqa4UO7OqY
9URF8IOPJYjrvoOxskv+IVOCosslxMOMYw8KrKuWx7ZuFh/NwQOjz6oOvzrp3tkl
Kk5Fkoc0TayzYIPS4dTeVuiZDwUj+44tYIxtHqDjyUGBXH96CpyAuX57NK3nyRNK
Iv6TsvKH9GexZqjpRK2j89ltVcABTSenTsx3LVl/fWO9UmhohoVvbC1ZbGJmT3Sf
0v8RIedRWcWGrctMfzu4P/dyOkznc/utlqlL2ZoIB8LSyu5mUXDY8vycb+3Z9O07
xKTVlEYY6XeW6hJ10f6Meom8+4+XUbcBw+++bFeUJ35kywxQtOFMf9bYBC7YSF5Y
9f68uZIspUyXOj+q8n5nvZ6FYkj1HDPzBuBHxznaupIcpXcJ5uw=
=YJuL
-----END PGP SIGNATURE-----
Merge tag 'platform-remove-void-soc-for-6.7-rc' of https://git.pengutronix.de/git/ukl/linux into soc/drivers
Convert drivers/soc to struct platform_driver::remove_new()
This PR contains the patches I sent in the series available at
https://lore.kernel.org/all/20230925095532.1984344-1-u.kleine-koenig@pengutronix.de
that were not yet picked up in next as of next-20231013.
It converts all drivers below drivers/soc to let their remove callback
return void. See commit 5c5a7680e6 ("platform: Provide a remove
callback that returns no value") for the rationale.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230925095532.1984344-32-u.kleine-koenig@pengutronix.de
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231016072911.27148-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/r/20230925095532.1984344-18-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230925095532.1984344-16-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20230925095532.1984344-15-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/r/20230925095532.1984344-14-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Acked-by: Gabriel Somlo <gsomlo@gmail.com>
Link: https://lore.kernel.org/r/20230925095532.1984344-13-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/r/20230925095532.1984344-12-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/r/20230925095532.1984344-11-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/r/20230925095532.1984344-10-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/r/20230925095532.1984344-9-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Acked-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20230925095532.1984344-8-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Acked-by: Herve Codina <herve.codina@bootlin.com>
Link: https://lore.kernel.org/r/20230925095532.1984344-7-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Link: https://lore.kernel.org/r/20230925095532.1984344-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.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>
Introduce compatible "qcom,scmi-smc" for SCMI smc/hvc transport channel for
Qualcomm virtual platforms.
This compatible mandates populating an additional parameter 'capability-id'
from the last 8 bytes of the shmem channel.
Signed-off-by: Nikunj Kela <quic_nkela@quicinc.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/20231009191437.27926-2-quic_nkela@quicinc.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
All the parameters to arm_smccc_1_1_invoke() are unsigned long which
aligns well on both 32-bit and 64-bit Arm based platforms. Let us store
all the members in the structure scmi_smc used as the parameters to the
arm_smccc_1_1_invoke() call as unsigned long.
Cc: Cristian Marussi <cristian.marussi@arm.com>
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20231009152049.1428872-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Update memory transaction descriptor structure to accommodate couple of
new entries in v1.1 which were previously marked reserved and MBZ(must
be zero).
It also removes the flexible array member ep_mem_access in the memory
transaction descriptor structure as it need not be at fixed offset.
Also update ffa_mem_desc_offset() accessor to handle both old and new
formats of memory transaction descriptors.
The updated ffa_mem_region structure aligns with new format in v1.1 and
hence the driver/user must take care not to use members beyond and
including ep_mem_offset when using the old format.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-16-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In preparation to add support to the new memory transaction descriptor,
the ep_mem_access member needs to be removed and hence even the macro
COMPOSITE_OFFSET(). Let us switch to using the new ffa_mem_desc_offset()
accessor in ffa_setup_and_transmit().
This will enable adding the support for new format transparently without
any changes here again.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-15-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
FF-A v1.1 removes the fixed location of endpoint memory access descriptor
array within the memory transaction descriptor structure. In preparation
to remove the ep_mem_access member from the ffa_mem_region structure,
provide the accessor to fetch the offset and use the same in FF-A proxy
implementation.
The accessor take the FF-A version as the argument from which the memory
access descriptor format can be determined. v1.0 uses the old format while
v1.1 onwards use the new format specified in the v1.1 specification.
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: Will Deacon <will@kernel.org>
Cc: Quentin Perret <qperret@google.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-14-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI v3.2 spec introduces CLOCK_POSSIBLE_PARENTS_GET, CLOCK_PARENT_SET
and CLOCK_PARENT_GET. Add support for these to enable clock parents
and use them in the clock driver.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20231004-scmi-clock-v3-v5-1-1b8a1435673e@nxp.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add the missing devm_kfree() when we skip the clocks with invalid or
missing information from the firmware.
Cc: Cristian Marussi <cristian.marussi@arm.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Fixes: 6d6a1d82ea ("clk: add support for clocks provided by SCMI")
Link: https://lore.kernel.org/r/20231004193600.66232-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20231006224650.445424-1-robh@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The computation of endpoint memory access descriptor's composite memory
region descriptor offset is using COMPOSITE_CONSTITUENTS_OFFSET which is
unnecessary complicated. Composite memory region descriptor always follow
the endpoint memory access descriptor array and hence it is computed
accordingly. COMPOSITE_CONSTITUENTS_OFFSET is useless and wrong for any
input other than endpoint memory access descriptor count.
Let us drop the usage of COMPOSITE_CONSTITUENTS_OFFSET to simplify the
computation of total transmit and fragment length in the memory
transactions.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-13-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
With all the necessary plumbing in place, let us add handling the
notifications as part of schedule receiver interrupt handler. In order
to do so, we need to just register scheduling callback on behalf of the
driver partition.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-12-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The framework provides an interface to the sender endpoint to specify
the notification to signal to the receiver endpoint. A sender signals
a notification by requesting its partition manager to set the
corresponding bit in the notifications bitmap of the receiver.
Expose the ability to send a notification to another partition.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-11-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Enable client drivers to register a callback function that will be
called when one or more notifications are pending for a target
partition as part of schedule receiver interrupt handling.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-9-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The Framework uses the schedule receiver interrupt to inform the
receiver’s scheduler that the receiver must be run to handle a pending
notification. A receiver’s scheduler can obtain the description of the
schedule receiver interrupt by invoking the FFA_FEATURES interface.
The delivery of the physical schedule receiver interrupt from the secure
state to the non-secure state depends upon the state of the interrupt
controller as configured by the hypervisor.
The schedule seceiver interrupt is assumed to be a SGI. The Arm GIC
specification defines 16 SGIs. It recommends that they are equally
divided between the non-secure and secure states. OS like Linux kernel
in the non-secure state typically do not have SGIs to spare. The usage
of SGIs in the secure state is however limited. It is more likely that
software in the Secure world does not use all the SGIs allocated to it.
It is recommended that the secure world software donates an unused SGI
to the normal world for use as the schedule receiver interrupt. This
implies that secure world software must configure the SGI in the GIC
as a non-secure interrupt before presenting it to the normal world.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-8-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The receiver’s scheduler uses the FFA_NOTIFICATION_INFO_GET interface
to retrieve the list of endpoints that have pending notifications and
must be run. A notification could be signaled by a sender in the secure
world to a VM. The Hypervisor needs to determine which VM and vCPU
(in case a per-vCPU notification is signaled) has a pending notification
in this scenario. It must obtain this information through an invocation
of the FFA_NOTIFICATION_INFO_GET.
Add the implementation of the NOTIFICATION_INFO_GET interface
and prepare to use this to handle the schedule receiver interrupt.
Implementation of handling notifications will be added later.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-7-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The framework provides an interface to the receiver to determine the
identity of the notification. A receiver endpoint must use the
FFA_NOTIFICATION_GET interface to retrieve its pending notifications
and handle them.
Add the support for FFA_NOTIFICATION_GET to allow the caller(receiver)
to fetch its pending notifications from other partitions in the system.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-6-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The framework provides an interface to the sender to specify the
notification to signal to the receiver. A sender signals a notification
by requesting its partition manager to set the corresponding bit in the
notifications bitmap of the receiver invoking FFA_NOTIFICATION_SET.
Implement the FFA_NOTIFICATION_SET to enable the caller(sender) to send
the notifications for any other partitions in the system.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-5-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
FFA_RUN is used by a scheduler to allocate CPU cycles to a target
endpoint execution context specified in the target information parameter.
If the endpoint execution context is in the waiting/blocked state, it
transitions to the running state.
Expose the ability to call FFA_RUN in order to give any partition in the
system cpu cycles to perform IMPDEF functionality.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-4-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
A receiver endpoint must bind a notification to any sender endpoint
before the latter can signal the notification to the former. The receiver
assigns one or more doorbells to a specific sender. Only the sender can
ring these doorbells.
A receiver uses the FFA_NOTIFICATION_BIND interface to bind one or more
notifications to the sender. A receiver un-binds a notification from a
sender endpoint to stop the notification from being signaled. It uses
the FFA_NOTIFICATION_UNBIND interface to do this.
Allow the FF-A driver to be able to bind and unbind a given notification
ID to a specific partition ID. This will be used to register and
unregister notification callbacks from the FF-A client drivers.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-3-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
On systems without a hypervisor the responsibility of requesting the
creation of the notification bitmaps in the SPM falls to the FF-A driver.
We use FFA features to determine if the ABI is supported, if it is not
we can assume there is a hypervisor present and will take care of ensure
the relevant notifications bitmaps are created on this partitions behalf.
An endpoint’s notification bitmaps needs to be setup before it configures
its notifications and before other endpoints and partition managers can
start signaling these notifications.
Add interface to create and destroy the notification bitmaps and use the
same to do the necessary setup during the initialisation and cleanup
during the module exit.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-2-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Arm Firmware Framework for A-profile(FFA) v1.1 introduces notifications
and indirect messaging based upon notifications support and extends some
of the memory interfaces.
Let us add all the newly supported FF-A function IDs in the spec.
Also update to the error values and associated handling.
Link: https://lore.kernel.org/r/20231005-ffa_v1-1_notif-v4-1-cddd3237809c@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In order to enable libkmod lookups for FF-A device objects to their
corresponding module, add 'modalias' to the base attribute of FF-A
devices.
Tested-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com>
Link: https://lore.kernel.org/r/20231005175640.379631-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
An FF-A ABI could support both the SMC32 and SMC64 conventions.
A callee that runs in the AArch64 execution state and implements such
an ABI must implement both SMC32 and SMC64 conventions of the ABI.
So the FF-A drivers will need the option to choose the mode irrespective
of FF-A version and the partition execution mode flag in the partition
information.
Let us remove the check on the FF-A version for allowing the selection
of 32bit mode of messaging. The driver will continue to set the 32-bit
mode if the partition execution mode flag specified that the partition
supports only 32-bit execution.
Fixes: 106b11b1cc ("firmware: arm_ffa: Set up 32bit execution mode flag using partiion property")
Link: https://lore.kernel.org/r/20231005142823.278121-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Commit 19b8766459 ("firmware: arm_ffa: Fix FFA device names for logical
partitions") added an ID to the FFA device using ida_alloc() and append
the same to "arm-ffa" to make up a unique device name. However it missed
to stash the id value in ffa_dev to help freeing the ID later when the
device is destroyed.
Due to the missing/unassigned ID in FFA device, we get the following
warning when the FF-A device is unregistered.
| ida_free called for id=0 which is not allocated.
| WARNING: CPU: 7 PID: 1 at lib/idr.c:525 ida_free+0x114/0x164
| CPU: 7 PID: 1 Comm: swapper/0 Not tainted 6.6.0-rc4 #209
| pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : ida_free+0x114/0x164
| lr : ida_free+0x114/0x164
| Call trace:
| ida_free+0x114/0x164
| ffa_release_device+0x24/0x3c
| device_release+0x34/0x8c
| kobject_put+0x94/0xf8
| put_device+0x18/0x24
| klist_devices_put+0x14/0x20
| klist_next+0xc8/0x114
| bus_for_each_dev+0xd8/0x144
| arm_ffa_bus_exit+0x30/0x54
| ffa_init+0x68/0x330
| do_one_initcall+0xdc/0x250
| do_initcall_level+0x8c/0xac
| do_initcalls+0x54/0x94
| do_basic_setup+0x1c/0x28
| kernel_init_freeable+0x104/0x170
| kernel_init+0x20/0x1a0
| ret_from_fork+0x10/0x20
Fix the same by actually assigning the ID in the FFA device this time
for real.
Fixes: 19b8766459 ("firmware: arm_ffa: Fix FFA device names for logical partitions")
Link: https://lore.kernel.org/r/20231003085932.3553985-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
To allow a consumer driver to use the OPP library to scale the performance
for its device, let's dynamically add the OPP table when the device gets
attached to its SCMI performance domain.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230925131715.138411-10-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
To enable the performance level to be used for OPPs, let's convert into
using the dev_pm_opp_add_dynamic() API when creating them. This will be
particularly useful for the SCMI performance domain, as shown through
subsequent changes.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230925131715.138411-9-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Let's simplify the code in scmi_dvfs_device_opps_add() by using
dev_pm_opp_remove_all_dynamic() in the error path.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Link: https://lore.kernel.org/r/20230925131715.138411-8-ulf.hansson@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
This is the merge of immutable point in PM OPP tree shared with SCMI so
that the SCMI changes based on these OPP changes can be merged via the
SCMI tree.
* 'opp/pm-domain-scmi' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm:
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()
