The current code does the whole tx fifos resize in the function
dwc3_gadget_ep_enable() only when the ep-in is isoc type and the
maxpacket >= 1024, for example, if the usb gadget is configured
as UAC + RNDIS + UVC + ADB, then the tx fifos resize is done when
uvc streaming on, there maybe a risk that the in endpoints of the
uac/rndis/adb are using their tx fifos to transfer data while do
the whole tx fifos resize, if this case occurs, the dwc3 controller
will run into abnormal and unrecoverable state.
To fix this issue, we must make sure that there are not any in
endpoints using tx fifos to transfer data while do the whole tx
fifos resize. The patch does the tx fifos resize when the connect
done event occurs during usb gadget enumeration phase.
Change-Id: Ia793fd7895b36e771ad654e583fa3fd7bf29aac6
Signed-off-by: William Wu <william.wu@rock-chips.com>
The usb gadget core set the chosen endpoint descriptor for
each endpoints in config_ep_by_speed(), however, we want
to get the transfer type of the endpoints earlier on the
rockchip platforms for usb controller initialization
(e.g. do tx fifos resize for rockchip usb dwc3 controller),
so this patch add transfer_type in the struct usb_ep, and
set the transfer_type in the usb_ep_autoconfig_ss().
Change-Id: Ia2added218e180dda7a7ca5da09ee18d63be1ff0
Signed-off-by: William Wu <william.wu@rock-chips.com>
It take quite a long time to wait for devices to be probed
in multi-RCs system and even longer to wait for timeout
if no devices attached. Use kthread to save the boot time.
Change-Id: Ib7060679287f0a08fbb9ff437947d8a47e775b75
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
SMC/HVC can transmit only one message at the time as the shared memory
needs to be protected and the calls are synchronous.
However, in order to allow multiple threads to send SCMI messages
simultaneously, we need a larger poll of memory.
Let us just use value of 20 to keep it in sync mailbox transport
implementation. Any other value must work perfectly.
Link: https://lore.kernel.org/r/20201008143722.21888-4-etienne.carriere@linaro.org
Fixes: 1dc6558062 ("firmware: arm_scmi: Add smc/hvc transport")
Cc: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
[sudeep.holla: reworded the commit message to indicate the practicality]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
(cherry picked from commit 7adb2c8aaa)
Change-Id: I36bf5833a51c7e31f822a1eac504db28519219a3
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
gcc as well as clang now produce warnings for missing kerneldoc function
parameter.
Fix the following W=1 kernel build warning:
drivers/firmware/arm_scmi/smc.c:32:
warning: Function parameter or member 'shmem_lock' not described in 'scmi_smc'
Link: https://lore.kernel.org/r/20200709153155.22573-1-sudeep.holla@arm.com
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
(cherry picked from commit a4ee9d0194)
Change-Id: Idd4d3ffc02ea7eb0e2f7b9e2ab0fa2038d49c934
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
The scmi protocol core driver checks for the channel availability
before evaluating the shmem property. If the individual protocols
don't have separate channel assigned to them, the channel alloted
for the BASE protocol is reused automatically.
Therefore there is no need to check for the shmem property in the
parent node if it is absent in the child protocol node.
Link: https://lore.kernel.org/r/20200327163654.13389-5-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
(cherry picked from commit 4e44590ee4)
Change-Id: Icd6f501d6f943eef5059340b0f1e74364546136b
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
In order to support multiple SMC/HVC transport channels with associated
shared memory, it is better to maintain the mutex per channel instead of
existing global one.
Move the smc_mutex into the scmi_smc structure and also rename it to
shmem_lock which is more appropriate for it's use.
Link: https://lore.kernel.org/r/20200327163654.13389-2-sudeep.holla@arm.com
Tested-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
(cherry picked from commit 18988265b8)
Change-Id: I7aff40e259dfb86cb99fd1507a35331a192bf4a3
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.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>
(cherry picked from commit 1dc6558062)
Change-Id: Ie192ad571d5f0ae7fc4972a00ac9071b5c8b055b
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.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>
(cherry picked from commit 5c8a47a5a9)
Change-Id: I6ce8d261317212bb0f68bf5946f683b83f5fc2d0
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.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>
(cherry picked from commit 729d3530a5)
Change-Id: I4ddbc6f24e48e1a11f29c88d03ebba91f000284a
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
Adding trace events would help to measure the speed of the communication
channel. It can be also potentially used helpful during investigation
of some issues platforms which use different transport layer.
Update also MAINTAINERS file with information that the new trace events
are maintained.
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>
(cherry picked from commit 257d0e20ec)
Change-Id: I4349c71a5c2efdb2be06fef4e82750facc81d55a
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
(cherry picked from commit 9c5c463f2a)
Change-Id: I08fdf1fac9ef3ae900b6cbe5422a6ac928f23ca1
Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
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>
