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>
(cherry picked from commit 11040889af)
Change-Id: I312846528b8e5e2251784e8c43548b895243ef54
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
SMCCC 1.1 calls may use either HVC or SMC depending on the PSCI
conduit. Rather than coding this in every call site, provide a macro
which uses the correct instruction. The macro also handles the case
where no conduit is configured/available returning a not supported error
in res, along with returning the conduit used for the call.
This allow us to remove some duplicated code and will be useful later
when adding paravirtualized time hypervisor calls.
Signed-off-by: Steven Price <steven.price@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
(cherry picked from commit 541625ac47)
Change-Id: I870c88fae413a0d46c242f840938e1a3578a942f
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
SMCCC callers are currently amassing a collection of enums for the SMCCC
conduit, and are having to dig into the PSCI driver's internals in order
to figure out what to do.
Let's clean this up, with common SMCCC_CONDUIT_* definitions, and an
arm_smccc_1_1_get_conduit() helper that abstracts the PSCI driver's
internal state.
We can kill off the PSCI_CONDUIT_* definitions once we've migrated users
over to the new interface.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
(cherry picked from commit 6b7fe77c33)
Change-Id: I4e2d92b6f641eedc759b2f7a7e1c576a7935b8b2
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit ee7a9c9f67)
Change-Id: Ia371408eb8e2b26c0b3b39de9ed86baa3d2f87b9
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.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>
(cherry picked from commit 58ecdf03db)
Change-Id: I366d810e11789b5c1ea038e85c2cd04e5452c72b
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit 22d1f76109)
Change-Id: Ib69d24aaf3e4b8d00713a578d1647c19f3334ea8
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit 38c927fbeb)
Change-Id: Ie6411e89580a35ea78a32eeeb74756e2d62e528f
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit 46cc7c286c)
Change-Id: Iac0772348af94f83690c06d340f8493e92618e76
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit 3748daf7fb)
Change-Id: Ia5ae7c7740afaba0dc2f87b50f65a9e0da91377e
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit 2747a967c8)
Change-Id: I2e44aebdda6b29bd3739f63aba1bb755453e55d6
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.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>
(cherry picked from commit 5b65af8f60)
Change-Id: I7c67371e158c1856f318e9084a78f4fe8c36c9b6
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit c29a628976)
Change-Id: I674c5f34787af25febf9325b02c2c9af797641ee
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit 37bbffcb19)
Change-Id: I913d3fd7041b6226918840aa644f098ec43f8bf7
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit d9350f21e5)
Change-Id: Ie82ea97ae27ef08022b9326c02671378f99dfd57
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
def_mode picture_aspect_ratio is no HDMI_PICTURE_ASPECT_NONE,
but Android set mode, the picture_aspect_ratio is HDMI_PICTURE_ASPECT_NONE,
When comparing the new mode with the old mode, the two are inconsistent,
so the mode will be changed.
Signed-off-by: Shunqing Chen <csq@rock-chips.com>
Change-Id: Ide07f9f7251a4ad22d4c27136005be77f1dfd4e2
Actually from test, it seems the expected DATA timeout is broken
for some CMD transfers which is wired, so we have to add
SDHCI_QUIRK_BROKEN_TIMEOUT_VAL for sdhci core to always set max
timeout value
Change-Id: Ib41ca137f700f939a13c9f9d0fc30cb8590f1183
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Set SSC downward spread spectrum for PCIe and set proper
RMJ for inner 100M and external 100M refclk.
Change-Id: Ic7d9d1651f7687858e6c5e399bc98ee03b5ee964
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
This is back from android mainline with conflict fix from
(f2bcdb43a7 ANDROID: staging: ion: Skip sync if not mapped)
Only sync the sg-list of an Ion dma-buf attachment when the attachment
is actually mapped on the device.
dma-bufs may be synced at any time. It can be reached from user space
via DMA_BUF_IOCTL_SYNC, so there are no guarantees from callers on when
syncs may be attempted, and dma_buf_end_cpu_access() and
dma_buf_begin_cpu_access() may not be paired.
Since the sg_list's dma_address isn't set up until the buffer is used
on the device, and dma_map_sg() is called on it, the dma_address will be
NULL if sync is attempted on the dma-buf before it's mapped on a device.
Change-Id: I11f7c13cfc7fa9672df803457c1708e60bf51ae7
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Gate bus clock will make DLL module lost tuning value.
Change-Id: I3af2d7c6601acbdeb4eb732e597d7d5725e0354b
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Fixes: 008340a82 ("drivers: rkflash: Change to use the api which the oob area available")
Change-Id: I140aa76a2acb73271ba04b7060030dc06a2353e6
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
Clear UDMA interrupt first before starting a new transfer. Otherwise,
the new interrupt corresponding to new transfer may be cleared
when clear the last interrupt which finally cause transfer timeout.
Change-Id: I4d232e41cdfaa68178cdd99942aefa717032c1b9
Signed-off-by: Simon Xue <xxm@rock-chips.com>
This is needed by rk3566-rk817-tablet-rkg11 with mic array
Signed-off-by: Binyuan Lan <lby@rock-chips.com>
Change-Id: I6c1083b402273bfa1492c9a2f851a76a5c71ab7d
