Commit Graph

61 Commits

Author SHA1 Message Date
Cristian Marussi
8d3581c252 firmware: arm_scmi: Port base protocol to new interface
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>
2021-03-29 10:00:35 +01:00
Cristian Marussi
3d5d6e84ea firmware: arm_scmi: Add helper to access protocol revision/version
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>
2021-03-29 10:00:35 +01:00
Cristian Marussi
a4a20b0975 firmware: arm_scmi: Add new protocol handle core transfer ops
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>
2021-03-29 10:00:35 +01:00
Cristian Marussi
b9f7fd907c firmware: arm_scmi: Convert events registration to protocol handles
Convert all refactored events registration routines to use protocol
handles.

In order to maintain bisectability and to allow protocols and drivers
to be later ported to the new protocol handle interface one by one,
introduce here also some transient code that will be removed later
in order to ease such transition.

Link: https://lore.kernel.org/r/20210316124903.35011-8-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>
2021-03-29 10:00:35 +01:00
Cristian Marussi
533c7095b1 firmware: arm_scmi: Refactor events registration
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>
2021-03-29 10:00:35 +01:00
Cristian Marussi
23934efe37 firmware: arm_scmi: Introduce devres get/put protocols operations
Expose to the SCMI drivers a new devres managed common protocols API
based on generic get/put methods and protocol handles.

All drivers still keep using the old API, no functional change.

Link: https://lore.kernel.org/r/20210316124903.35011-4-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>
2021-03-29 10:00:16 +01:00
Cristian Marussi
d7b6cc563a firmware: arm_scmi: Introduce protocol handle definitions
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>
2021-03-29 09:41:29 +01:00
Cristian Marussi
48dc16e2e5 firmware: arm_scmi: Extend protocol registration interfaces
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>
2021-03-29 09:40:47 +01:00
Jyoti Bhayana
f774117c96 iio/scmi: Adding support for IIO SCMI Based Sensors
This change provides ARM SCMI Protocol based IIO device.
This driver provides support for Accelerometer and Gyroscope using
SCMI Sensor Protocol extensions added in the SCMIv3.0 ARM specification

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Jyoti Bhayana <jbhayana@google.com>
Link: https://lore.kernel.org/r/20210212172235.507028-2-jbhayana@google.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20210309231259.78050-2-jbhayana@google.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
2021-03-13 16:43:04 +00:00
Cristian Marussi
a90b6543bf firmware: arm_scmi: Fix call site of scmi_notification_exit
Call scmi_notification_exit() only when SCMI platform driver instance has
been really successfully removed.

Link: https://lore.kernel.org/r/20210112191326.29091-1-cristian.marussi@arm.com
Fixes: 6b8a69131d ("firmware: arm_scmi: Enable notification core")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: Move the call outside the list mutex locking]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2021-01-13 14:30:16 +00:00
Cristian Marussi
ec88381936 firmware: arm_scmi: Add support to enumerated SCMI voltage domain device
Add SCMI voltage domain device name to the core list of supported protocol
devices so that it can be enumerated if the firmware supports it.

Link: https://lore.kernel.org/r/20201119191051.46363-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-11-20 14:55:48 +00:00
Cristian Marussi
2add5cacff firmware: arm_scmi: Add voltage domain management protocol support
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>
2020-11-20 14:55:48 +00:00
Sudeep Holla
9724722fde firmware: arm_scmi: Add missing Rx size re-initialisation
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>
2020-10-13 10:01:47 +01:00
Sudeep Holla
1eaf18e35a firmware: arm_scmi: Move scmi protocols registration into the driver
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>
2020-09-14 07:30:55 +01:00
Sudeep Holla
5a2f0a0bdf firmware: arm_scmi: Move scmi bus init and exit calls into the driver
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>
2020-09-14 07:30:48 +01:00
Cristian Marussi
481f6ccf39 firmware: arm_scmi: Add SCMI device for system power protocol
Add SCMI device for system power protocol by just adding the name "syspower"
to the list of supported core protocol devices.

Link: https://lore.kernel.org/r/20200907174657.32466-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-09-08 16:02:17 +01:00
Cristian Marussi
72a5eb9d9c firmware: arm_scmi: Remove fixed size fields from reports/scmi_event_header
Event reports are used to convey information describing events to the
registered user-callbacks: they are necessarily derived from the underlying
raw SCMI events' messages but they are not meant to expose or directly
mirror any of those messages data layout, which belong to the protocol
layer.

Using fixed size types for report fields, mirroring messages structure,
is at odd with this: get rid of them using more generic, equivalent,
typing.

Substitute scmi_event_header fixed size fields with generic types too and
shuffle around fields definitions to minimize implicit padding while
adapting involved functions.

Link: https://lore.kernel.org/r/20200710133919.39792-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-07-13 09:40:21 +01:00
Cristian Marussi
6b8a69131d firmware: arm_scmi: Enable notification core
Initialize and enable SCMI notifications core support during bus/driver
probe phase, so that protocols can start registering their supported
events during their initialization.

Link: https://lore.kernel.org/r/20200701155348.52864-5-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>
2020-07-01 17:07:26 +01:00
Sudeep Holla
d764282377 firmware: arm_scmi: Use HAVE_ARM_SMCCC_DISCOVERY instead of ARM_PSCI_FW
Commit e5bfb21d98 ("firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to
identify SMCCC v1.1 and above") introduced new config option to identify
the availability of SMCCC discoverability of version and features
transparently hiding the indirect dependency on ARM_PSCI_FW.

Commit 5a897e3ab4 ("firmware: arm_scmi: fix psci dependency") just
worked around the build dependency making SCMI SMC/HVC transport depend
on ARM_PSCI_FW at the time. Since it really just relies on SMCCC directly
and not on ARM_PSCI_FW, let us move to use CONFIG_HAVE_ARM_SMCCC_DISCOVERY
instead of CONFIG_ARM_PSCI_FW.

Link: https://lore.kernel.org/r/20200625101937.51939-1-sudeep.holla@arm.com
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-06-30 14:08:10 +01:00
Sudeep Holla
bad0d73b65 firmware: arm_scmi: Use signed integer to report transfer status
Currently the trace event 'scmi_xfer_end' reports the status of the
transfer using the unsigned status field read from the firmware which
may not be easy to interpret. It may also miss to emit any timeouts
that happen in the driver resulting in emitting garbage in the status
field in those scenarios.

Let us use signed integer so that error values are emitted out after
they are mapped from firmware error formats to standard linux error
codes. While at this, also include any timeouts in the driver itself.

Link: https://lore.kernel.org/r/20200609134503.55860-1-sudeep.holla@arm.com
Cc: Jim Quinlan <james.quinlan@broadcom.com>
Cc: Lukasz Luba <lukasz.luba@arm.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-06-30 14:07:08 +01:00
Sudeep Holla
5a897e3ab4 firmware: arm_scmi: fix psci dependency
When CONFIG_ARM_PSCI_FW is disabled but CONFIG_HAVE_ARM_SMCCC is enabled,
arm-scmi runs into a link failure:

arm-linux-gnueabi-ld: drivers/firmware/arm_scmi/smc.o: in function `smc_send_message':
smc.c:(.text+0x200): undefined reference to `arm_smccc_1_1_get_conduit'

Change from HAVE_ARM_SMCCC to ARM_PSCI_FW config dependency for now.
We rely on PSCI bindings anyways for the conduit and this should be
fine.

Link: https://lore.kernel.org/r/20200507144905.11397-1-sudeep.holla@arm.com
Fixes: 1dc6558062 ("firmware: arm_scmi: Add smc/hvc transport")
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-07 16:28:56 +01:00
Cristian Marussi
c5bceb98ce firmware: arm_scmi: Fix handling of unexpected delayed responses
Upon reception of an unexpected bogus delayed response, clear the channel
and bail-out safely.

Link: https://lore.kernel.org/r/20200420152315.21008-5-cristian.marussi@arm.com
Fixes: 4d09852b6f ("firmware: arm_scmi: Add support for notifications message processing")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:25:26 +01:00
Cristian Marussi
d04fb2b2dd firmware: arm_scmi: Clear channel for delayed responses
Clear channel properly when done processing a delayed response.
This will let the platform firmware know that the channel is now free to
use it for any new delayed response or notification.

Link: https://lore.kernel.org/r/20200420152315.21008-4-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
(sudeep.holla: Updated commit log to reflect that channel is now free for
 platform to use)
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:25:26 +01:00
Cristian Marussi
b37f5cc8d2 firmware: arm_scmi: Clear channel on reception of unexpected responses
When an unexpected response message is received we currently warn the user
and bail-out, ensure to also free the channel by invoking the transport
independent operation .clear_channel()

Link: https://lore.kernel.org/r/20200420152315.21008-3-cristian.marussi@arm.com
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-20 17:25:26 +01:00
Cristian Marussi
87dff4e63c firmware: arm_scmi: Rename .clear_notification() transport_ops
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>
2020-04-20 17:25:26 +01:00
Sudeep Holla
4d09852b6f firmware: arm_scmi: Add support for notifications message processing
Add the mechanisms to distinguish notifications from delayed responses
and command responses. Also add support to properly fetch notification
messages upon reception. Notifications processing does not continue any
further after the fetch phase.

Link: https://lore.kernel.org/r/20200327143438.5382-5-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Reworked/renamed scmi_handle_xfer_delayed_resp()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:49 +01:00
Sudeep Holla
4ebd8f6dea firmware: arm_scmi: Add receive buffer support for notifications
With all the plumbing in place, let's just add the separate dedicated
receive buffers to handle notifications that can arrive asynchronously
from the platform firmware to OS.

Also add one check to see if the platform supports any receive channels
before allocating the receive buffers: since those buffers are optionally
supported though, the whole xfer initialization is also postponed to be
able to check for their existence in advance.

Link: https://lore.kernel.org/r/20200327143438.5382-2-cristian.marussi@arm.com
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
[Changed parameters in __scmi_xfer_info_init()]
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-04-14 09:31:49 +01:00
Peng Fan
1dc6558062 firmware: arm_scmi: Add smc/hvc transport
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>
2020-04-14 09:31:48 +01:00
Viresh Kumar
5c8a47a5a9 firmware: arm_scmi: Make scmi core independent of the transport type
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>
2020-02-10 11:50:51 +00:00
Viresh Kumar
c4eb83660a firmware: arm_scmi: Move macros and helpers to common.h
Move message header specific macros and helper routines to common.h as
they will be used outside of driver.c in a later commit.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/6615db480370719b0a0241447a5f3feb8eea421f.1580448239.git.viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-02-10 11:50:47 +00:00
Viresh Kumar
71af05a7d0 firmware: arm_scmi: Update doc style comments
Fix minor formatting issues with the doc style comments.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/1bff7c0d1ad2c8b6eeff9660421f414f8c612eb2.1580448239.git.viresh.kumar@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-02-10 11:50:41 +00:00
Lukasz Luba
729d3530a5 drivers: firmware: scmi: Extend SCMI transport layer by trace events
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>
2019-12-30 12:34:37 +00:00
Sudeep Holla
4605e224db firmware: arm_scmi: Add versions and identifier attributes using dev_groups
Platform drivers now have the option to have the platform core create
and remove any needed sysfs attribute files. Using the same, let's add
the scmi firmware and protocol version attributes as well as vendor and
sub-vendor identifiers to sysfs.

It helps to identify the firmware details from the sysfs entries similar
to ARM SCPI implementation.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24 11:35:49 +00:00
Sudeep Holla
9c5c463f2a firmware: arm_scmi: Add names to scmi devices created
Now that scmi bus provides option to create named scmi device, let us
create the default devices with names. This will help to add names for
matching to respective drivers and eventually to add multiple devices
and drivers per protocol.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24 11:35:49 +00:00
Sudeep Holla
11040889af firmware: arm_scmi: Skip scmi mbox channel setup for addtional devices
Now that the scmi bus supports adding multiple devices per protocol,
and since scmi_create_protocol_device calls scmi_mbox_chan_setup,
we must avoid allocating and initialising the mbox channel if it is
already initialised.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24 11:35:49 +00:00
Sudeep Holla
ee7a9c9f67 firmware: arm_scmi: Add support for multiple device per protocol
Currently only one scmi device is created for each protocol enumerated.
However, there is requirement to make use of some procotols by multiple
kernel subsystems/frameworks. One such example is SCMI PERFORMANCE
protocol which can be used by both cpufreq and devfreq drivers.
Similarly, SENSOR protocol may be used by hwmon and iio subsystems,
and POWER protocol may be used by genpd and regulator drivers.

In order to achieve that, let us extend the scmi bus to match based
not only protocol id but also the scmi device name if one is available.

Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-12-24 11:35:48 +00:00
Sudeep Holla
58ecdf03db firmware: arm_scmi: Add support for asynchronous commands and delayed response
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>
2019-08-12 12:23:00 +01:00
Sudeep Holla
22d1f76109 firmware: arm_scmi: Add mechanism to unpack message headers
In order to identify the message type when a response arrives, we need
a mechanism to unpack the message header similar to packing. Let's
add one.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:23:00 +01:00
Sudeep Holla
38c927fbeb firmware: arm_scmi: Separate out tx buffer handling and prepare to add rx
Currently we pre-allocate transmit buffers only and use the first free
slot in that pre-allocated buffer for transmitting any new message that
are generally originated from OS to the platform firmware.

Notifications or the delayed responses on the other hand are originated
from the platform firmware and consumes by the OS. It's better to have
separate and dedicated pre-allocated buffers to handle the notifications.
We can still use the transmit buffers for the delayed responses.

In addition, let's prepare existing scmi_xfer_{get,put} for acquiring
and releasing a slot to identify the right(tx/rx) buffers.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:23:00 +01:00
Sudeep Holla
46cc7c286c firmware: arm_scmi: Add receive channel support for notifications
With scmi_mbox_chan_setup enabled to identify and setup both Tx and Rx,
let's consolidate setting up of both the channels under the function
scmi_mbox_txrx_setup.

Since some platforms may opt not to support notifications or delayed
response, they may not need support for Rx. Hence Rx is optional and
failure of setting one up is not considered fatal.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:22:59 +01:00
Sudeep Holla
3748daf7fb firmware: arm_scmi: Segregate tx channel handling and prepare to add rx
The transmit(Tx) channels are specified as the first entry and the
receive(Rx) channels are the second entry as per the device tree
bindings. Since we currently just support Tx, index 0 is hardcoded at
all required callsites.

In order to prepare for adding Rx support, let's remove those hardcoded
index and add boolean parameter to identify Tx/Rx channels when setting
them up.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:22:59 +01:00
Sudeep Holla
2747a967c8 firmware: arm_scmi: Reorder some functions to avoid forward declarations
Re-shuffling few functions to keep definitions and their usages close.
This is also needed to avoid too many unnecessary forward declarations
while adding new features(delayed response and notifications).

Keeping this separate to avoid mixing up of these trivial change that
doesn't affect functionality into the ones that does.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:22:59 +01:00
Sudeep Holla
9dc34d635c firmware: arm_scmi: Check if platform has released shmem before using
Sometimes platfom may take too long to respond to the command and OS
might timeout before platform transfer the ownership of the shared
memory region to the OS with the response.

Since the mailbox channel associated with the channel is freed and new
commands are dispatch on the same channel, OS needs to wait until it
gets back the ownership. If not, either OS may end up overwriting the
platform response for the last command(which is fine as OS timed out
that command) or platform might overwrite the payload for the next
command with the response for the old.

The latter is problematic as platform may end up interpretting the
response as the payload. In order to avoid such race, let's wait until
the OS gets back the ownership before we prepare the shared memory with
the payload for the next command.

Reported-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:22:59 +01:00
Sudeep Holla
5b65af8f60 firmware: arm_scmi: Use the term 'message' instead of 'command'
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>
2019-08-12 12:22:58 +01:00
Sudeep Holla
c29a628976 firmware: arm_scmi: Fix few trivial typos in comments
While adding new comments found couple of typos that are better fixed.

s/informfation/information/
s/statues/status/

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:22:58 +01:00
Sudeep Holla
37bbffcb19 firmware: arm_scmi: Remove extra check for invalid length message responses
scmi_xfer_get_init ensures both transmit and receive buffer lengths are
within the maximum limits. If receive buffer length is not supplied by
the caller, it's set to the maximum limit value. Receive buffer length
is never modified after that. So there's no need for the extra check
when receive transmit completion for a command essage.

Further, if the response header length is greater than the prescribed
receive buffer length, the response buffer is truncated to the latter.

Reported-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12 12:22:58 +01:00
Aditya Pakki
d9350f21e5 firmware: arm_scmi: replace of_match_device->data with of_device_get_match_data()
of_match_device can return NULL if no matching device is found though
it's highly unlikely to happen in scmi_probe as it's called only if
a valid match is found.

However we can use of_device_get_match_data() instead of
of_match_device()->data to handle NULL pointer checks and return -EINVAL
in such a scenario.

Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-04-12 18:11:18 +01:00
Steven Price
fa7fe29a64 firmware: arm_scmi: fix of_node leak in scmi_mailbox_check
of_parse_phandle_with_args() requires the caller to call of_node_put() on
the returned args->np pointer. Otherwise the reference count will remain
incremented.

However, in this case, since we don't actually use the returned pointer,
we can simply pass in NULL.

Fixes: aa4f886f38 ("firmware: arm_scmi: add basic driver infrastructure for SCMI")
Signed-off-by: Steven Price <steven.price@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-04-12 18:11:18 +01:00
Linus Torvalds
32bcbf8b6d ARM: SoC driver updates
This branch contains platform-related driver updates for ARM and ARM64.
 
 Highlights:
  - ARM SCMI (System Control & Management Interface) driver cleanups
  - Hisilicon support for LPC bus w/ ACPI
  - Reset driver updates for several platforms: Uniphier,
  - Rockchip power domain bindings and hardware descriptions for several SoCs.
  - Tegra memory controller reset improvements
 -----BEGIN PGP SIGNATURE-----
 
 iQJDBAABCAAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAlsfB94PHG9sb2ZAbGl4
 b20ubmV0AAoJEIwa5zzehBx3k2IP/i9T71QoanZ3k6o/d+YUqmTuUiA+EJWFANry
 8KSjBKmYDON/GLgRCiNZR8P0NZ3d1LgFk5gZDdhMrOtoGtd8k8q0KyqLxjKAWHt6
 opSrGucmE1gy9FvJdUkK+y148vM+Ea4SXRVOZxbLV5qm3inPwnopJjgKAfnhIn4X
 QmkSca90CyEc3kPdBdfMeAKL+7SRb4mbFHAXXVE7QiWvjrEjUkvtNVTazf5Nroc4
 PbI97zSFrmSFO4ZK0jZHCd4R2xhsJwzDQ/UKHC9C9/IdFMLfnJ7dxIf97QYn41Kl
 H46FneMZZZ1FibN+Mj5hC/tByE8FrMtWh636z031s6kkamSqLiBAZFlGpHABxQJs
 3tN1vBP40R7hzm76yQAC4Uopr5xOtmLr6KBMBBRr+Axf9jHMS4m/WP1chwZFpFjI
 Awxc0VCjBUm+haHvK85J4eHrzbWPjG+8aV5Ar5DHVo8et3MzCdX0ycoDeUT787qc
 qzEcCjGPbXHBR1aXUX8stRW5x8zoGH/4IUYMo5IGadiFuXSna6ERG9IHq3fAU5Fp
 ZzNNKedtodn9NoMr3NJJk1ndyrUr0lpXwlVqFeksRTa+INk2FHKd0cQfxwV33kS9
 wHXw+v323uxa3Tz2TXKS7PavY5yr6fZ0dLC2+xEDqHq6bsLxo1DnBEnaola+Jg+u
 9hKEuSff
 =xs+f
 -----END PGP SIGNATURE-----

Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull ARM SoC driver updates from Olof Johansson:
 "This contains platform-related driver updates for ARM and ARM64.

  Highlights:

   - ARM SCMI (System Control & Management Interface) driver cleanups

   - Hisilicon support for LPC bus w/ ACPI

   - Reset driver updates for several platforms: Uniphier,

   - Rockchip power domain bindings and hardware descriptions for
     several SoCs.

   - Tegra memory controller reset improvements"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (59 commits)
  ARM: tegra: fix compile-testing PCI host driver
  soc: rockchip: power-domain: add power domain support for px30
  dt-bindings: power: add binding for px30 power domains
  dt-bindings: power: add PX30 SoCs header for power-domain
  soc: rockchip: power-domain: add power domain support for rk3228
  dt-bindings: power: add binding for rk3228 power domains
  dt-bindings: power: add RK3228 SoCs header for power-domain
  soc: rockchip: power-domain: add power domain support for rk3128
  dt-bindings: power: add binding for rk3128 power domains
  dt-bindings: power: add RK3128 SoCs header for power-domain
  soc: rockchip: power-domain: add power domain support for rk3036
  dt-bindings: power: add binding for rk3036 power domains
  dt-bindings: power: add RK3036 SoCs header for power-domain
  dt-bindings: memory: tegra: Remove Tegra114 SATA and AFI reset definitions
  memory: tegra: Remove Tegra114 SATA and AFI reset definitions
  memory: tegra: Register SMMU after MC driver became ready
  soc: mediatek: remove unneeded semicolon
  soc: mediatek: add a fixed wait for SRAM stable
  soc: mediatek: introduce a CAPS flag for scp_domain_data
  soc: mediatek: reuse regmap_read_poll_timeout helpers
  ...
2018-06-11 18:15:22 -07:00
Sudeep Holla
632de8f542 firmware: arm_scmi: simplify exit path by returning on error
Yet another nasty indentation left out during code restructuring. It's
must simpler to return on error instead of having unnecessary indentation.

Suggested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2018-05-10 10:52:00 +01:00