Having added the support for SCMI protocols as modules in order to let
vendors extend the SCMI core with their own additions it seems odd to
then force SCMI drivers built on top to use a static device table to
declare their devices since this way any new SCMI drivers addition
would need the core SCMI device table to be updated too.
Remove the static core device table and let SCMI drivers to simply declare
which device/protocol pair they need at initialization time: the core will
then take care to generate such devices dynamically during platform
initialization or at module loading time, as long as the requested
underlying protocol is defined in the devicetree.
Link: https://lore.kernel.org/r/20210316124903.35011-39-cristian.marussi@arm.com
Tested-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>
Extend SCMI protocols accounting mechanism to address possible module
usage and add the support to possibly define new protocols as loadable
modules.
Keep the standard protocols built into the SCMI core.
Link: https://lore.kernel.org/r/20210316124903.35011-38-cristian.marussi@arm.com
Tested-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>
Notification private data is currently accessible via handle->notify_priv,
this data was indeed meant to be private to the notification core support
and not to be accessible by SCMI drivers. Make it private hiding it
inside instance descriptor struct scmi_info and accessible only via
dedicated helpers.
Link: https://lore.kernel.org/r/20210316124903.35011-36-cristian.marussi@arm.com
Tested-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>
Remove unused core scmi_xfer wrappers now that we have migrated all
protocols to the new interface based on protocol handles.
Link: https://lore.kernel.org/r/20210316124903.35011-34-cristian.marussi@arm.com
Tested-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>
Now that all protocols and drivers have been ported to the new interface
based on protocol handles and get/put operations, remove all the legacy
transient initialization code.
Link: https://lore.kernel.org/r/20210316124903.35011-33-cristian.marussi@arm.com
Tested-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>
Now that all the protocol private variable data have been moved out of
struct scmi_handle, mark all of its references as const.
Link: https://lore.kernel.org/r/20210316124903.35011-32-cristian.marussi@arm.com
Tested-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>
Port the SCMI base protocol to new protocol handles based interface.
Link: https://lore.kernel.org/r/20210316124903.35011-11-cristian.marussi@arm.com
Tested-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 an helper to access from a protocol handle, the SCMI version data
which is exposed on sysfs. Such helper will be needed by SCMI base
protocol initialization once it will be moved to new protocol handles
scheme.
Link: https://lore.kernel.org/r/20210316124903.35011-10-cristian.marussi@arm.com
Tested-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 new core SCMI transfer operations based on protocol handles to
enable protocols to builds and send their own protocol specific messages.
Keep old original scmi_xfer_ operations interface as wrappers around the
new interface in order to let coexist old and new interfaces to ease
protocol by protocol migration.
In order to support such migration the above wrappers and some
additional transient code is also introduced in this commit. It will be
later removed as a whole once the full migration of protocols and SCMI
drivers will have been completed.
Link: https://lore.kernel.org/r/20210316124903.35011-9-cristian.marussi@arm.com
Tested-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 new refactored protocol events registration helper and invoke it
from the centralized initialization process triggered by get_ops() and
friends.
Also add a `get_num_sources` as a new optional callback amongst protocol
events operations. Finally remove events registration call-sites from
within the legacy protocol init routines.
Link: https://lore.kernel.org/r/20210316124903.35011-7-cristian.marussi@arm.com
Tested-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 basic protocol handles definitions and private data helpers.
A protocol handle identifies a protocol instance initialized against a
specific handle, it embeds all the references to the core SCMI transfer
methods that will be needed by a protocol implementation to build and
send its own protocol specific messages using common core methods.
As such, in the interface, a protocol handle will be passed down from
the core to the protocol specific initialization callback at init time.
Anyways, at this point only definitions are introduced, all protocols
initialization code and SCMI drivers probing is still based on the old
interface, so no functional change.
Link: https://lore.kernel.org/r/20210316124903.35011-3-cristian.marussi@arm.com
Tested-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>
Extend common protocol registration routines and provide some new generic
protocols get/put helpers that can track protocols usage and automatically
perform the proper initialization and de-initialization on demand when
required.
Convert all standard protocols to use this new registration scheme while
keeping them all still using the usual initialization logic bound to SCMI
devices probing.
Link: https://lore.kernel.org/r/20210316124903.35011-2-cristian.marussi@arm.com
Tested-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 v3.0 introduces voltage domain protocol which provides commands to:
- Discover the voltage levels supported by a domain
- Get the configuration and voltage level of a domain
- Set the configuration and voltage level of a domain
Let us add support for the same.
Link: https://lore.kernel.org/r/20201119191051.46363-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Few commands provide the list of description partially and require
to be called consecutively until all the descriptors are fetched
completely. In such cases, we don't release the buffers and reuse
them for consecutive transmits.
However, currently we don't reset the Rx size which will be set as
per the response for the last transmit. This may result in incorrect
response size being interpretted as the firmware may repond with size
greater than the one set but we read only upto the size set by previous
response.
Let us reset the receive buffer size to max possible in such cases as
we don't know the exact size of the response.
Link: https://lore.kernel.org/r/20201012141746.32575-1-sudeep.holla@arm.com
Fixes: b6f20ff8bd ("firmware: arm_scmi: add common infrastructure and support for base protocol")
Reported-by: Etienne Carriere <etienne.carriere@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In preparation to enable building SCMI as a single module, let us move
the SCMI protocol registration call into the driver. This enables us
to also add unregistration of the SCMI protocols.
The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.
Link: https://lore.kernel.org/r/20200907195046.56615-4-sudeep.holla@arm.com
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In preparation to enable building scmi as a single module, let us move
the scmi bus {de-,}initialisation call into the driver.
The main reason for this is to keep it simple instead of maintaining
it as separate modules and dealing with all possible initcall races
and deferred probe handling. We can move it as separate modules if
needed in future.
Link: https://lore.kernel.org/r/20200907195046.56615-3-sudeep.holla@arm.com
Tested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add the core SCMI notifications protocol-registration support: allow
protocols to register their own set of supported events, during their
initialization phase. Notification core can track multiple platform
instances by their handles.
Link: https://lore.kernel.org/r/20200701155348.52864-2-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
SCMI transport operation .clear_notification() is indeed a generic method
to clear the channel in a transport dependent way, as such it could be a
useful helper also in other contexts.
Rename such method as .clear_channel(), renaming accordingly also its
already existent call-sites.
No functional change.
Link: https://lore.kernel.org/r/20200420152315.21008-2-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add common transport-layer methods to:
- fetch a notification instead of a response
- clear a pending notification
Add also all the needed support in mailbox/shmem transports.
Link: https://lore.kernel.org/r/20200327143438.5382-4-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Use the value of "arm,smc-id" property from the device tree as the first
argument for SMCCC call leaving all the other arguments as zero for now.
There is no Rx, only Tx because of smc/hvc not support Rx.
Link: https://lore.kernel.org/r/1583673879-20714-3-git-send-email-peng.fan@nxp.com
Signed-off-by: Peng Fan <peng.fan@nxp.com>
[sudeep.holla: reworded commit log/subject and fixed !HAVE_ARM_SMCCC build]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The SCMI specification is fairly independent of the transport protocol,
which can be a simple mailbox (already implemented) or anything else.
The current Linux implementation however is very much dependent on the
mailbox transport layer.
This patch makes the SCMI core code (driver.c) independent of the
mailbox transport layer and moves all mailbox related code to a new
file: mailbox.c and all struct shared_mem related code to a new file:
shmem.c.
We can now implement more transport protocols to transport SCMI
messages.
The transport protocols just need to provide struct scmi_transport_ops,
with its version of the callbacks to enable exchange of SCMI messages.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/8698a3cec199b8feab35c2339f02dc232bfd773b.1580448239.git.viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The SCMI transport layer communicates via mailboxes and shared memory with
firmware running on a microcontroller. It is platform specific how long it
takes to pass a SCMI message. The most sensitive requests are coming from
CPUFreq subsystem, which might be used by the scheduler.
Thus, there is a need to measure these delays and capture anomalies.
This change introduces trace events wrapped around transfer code.
According to Jim's suggestion a unique transfer_id is to distinguish
similar entries which might have the same message id, protocol id and
sequence. This is a case then there are some timeouts in transfers.
Suggested-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Instead of type-casting the {tx,rx}.buf all over the place while
accessing them to read/write __le{32,64} from/to the firmware, let's
use the existing {get,put}_unaligned_le{32,64} accessors to hide all
the type cast ugliness.
Suggested-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Messages that are sent to platform, also known as commands and can be:
1. Synchronous commands that block the channel until the requested work
has been completed. The platform responds to these commands over the
same channel and hence can't be used to send another command until the
previous command has completed.
2. Asynchronous commands on the other hand, the platform schedules the
requested work to complete later in time and returns almost immediately
freeing the channel for new commands. The response indicates the success
or failure in the ability to schedule the requested work. When the work
has completed, the platform sends an additional delayed response message.
Using the same transmit buffer used for sending the asynchronous command
even for the delayed response corresponding to it simplifies handling of
the delayed response. It's the caller of asynchronous command that is
responsible for allocating the completion flag that scmi driver can
complete to indicate the arrival of delayed response.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
In preparation to adding support for other two types of messages that
SCMI specification mentions, let's replace the term 'command' with the
correct term 'message'.
As per the specification the messages are of 3 types:
commands(synchronous or asynchronous), delayed responses and notifications.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
This patch corrects the SPDX License Identifier style
in header file related to Firmware Drivers for ARM SCMI
Message Protocol.
For C header files Documentation/process/license-rules.rst
mandates C-like comments (opposed to C source files where
C++ style should be used)
Changes made by using a script provided by Joe Perches here:
https://lkml.org/lkml/2019/2/7/46
Suggested-by: Joe Perches <joe@perches.com>
Signed-off-by: Nishad Kamdar <nishadkamdar@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Initially con_priv was supposedly used for transport specific data when
the SCMI driver had an abstraction to communicate with different mailbox
controllers. But after some discussions, the idea was dropped but this
variable slipped through the cracks.
This patch gets rid of this unused variable.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Just after the initial patches were queued, Jonathan Cameron mentioned
that scmi_one_xfer_{get_put} were not very clear and suggested to use
scmi_xfer_{alloc,free}. While I agree to some extent, the reason not to
have alloc/free as these are preallocated buffers and these functions
just returns a reference to free slot in that preallocated array.
However it was agreed to drop "_one" as it's implicit that we are always
dealing with one slot anyways.
This patch updates the name accordingly dropping "_one" in both {get,put}
functions. Also scmi_one_xfer_init is renamed as scmi_xfer_get_init to
reflect the fact that it gets the free slots and then initialise it.
Reported-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
There are few missing descriptions for function parameters and structure
members along with certain instances where excessive function parameters
or structure members are described.
This patch fixes all of those warnings.
Reported-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
By using FIELD_{FIT,GET,PREP} and GENMASK macro accessors we can avoid
some clumpsy custom shifting and masking macros and also improve the
code better readability.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The performance protocol is intended for the performance management of
group(s) of device(s) that run in the same performance domain. It
includes even the CPUs. A performance domain is defined by a set of
devices that always have to run at the same performance level.
For example, a set of CPUs that share a voltage domain, and have a
common frequency control, is said to be in the same performance domain.
The commands in this protocol provide functionality to describe the
protocol version, describe various attribute flags, set and get the
performance level of a domain. It also supports discovery of the list
of performance levels supported by a performance domain, and the
properties of each performance level.
This patch adds basic support for the performance protocol.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The SCMI specification encompasses various protocols. However, not every
protocol has to be present on a given platform/implementation as not
every protocol is relevant for it.
Furthermore, the platform chooses which protocols it exposes to a given
agent. The only protocol that must be implemented is the base protocol.
The base protocol is used by an agent to discover which protocols are
available to it.
In order to enumerate the discovered implemented protocols, this patch
adds support for a separate scmi protocol bus. It also adds mechanism to
register support for different protocols.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The base protocol describes the properties of the implementation and
provide generic error management. The base protocol provides commands
to describe protocol version, discover implementation specific
attributes and vendor/sub-vendor identification, list of protocols
implemented and the various agents are in the system including OSPM
and the platform. It also supports registering for notifications of
platform errors.
This protocol is mandatory. This patch adds support for the same along
with some basic infrastructure to add support for other protocols.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
The SCMI is intended to allow OSPM to manage various functions that are
provided by the hardware platform it is running on, including power and
performance functions. SCMI provides two levels of abstraction, protocols
and transports. Protocols define individual groups of system control and
management messages. A protocol specification describes the messages
that it supports. Transports describe the method by which protocol
messages are communicated between agents and the platform.
This patch adds basic infrastructure to manage the message allocation,
initialisation, packing/unpacking and shared memory management.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Cristian Marussi