If dw-hdmi is not used as the final output port, it is
only used as a bridge but not a connector.
Change-Id: Ie730f47d6075db74c0c54374849fd938c13f5ba8
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Because hdmirx phy only support yuv420 when input mode is 4K-60Hz,
y2r should be enabled.
Change-Id: I1eca2c6783c63e07cb13b617bb32ff81f2229c7d
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Now that we have arm_smccc_1_1_get_conduit(), we can hide the PSCI
implementation details from the arm64 cpu errata code, so let's do so.
As arm_smccc_1_1_get_conduit() implicitly checks that the SMCCC version
is at least SMCCC_VERSION_1_1, we no longer need to check this
explicitly where switch statements have a default case, e.g. in
has_ssbd_mitigation().
There should be no functional change as a result of this patch.
Change-Id: I2cfbe314cdcd59da923ff845015c8852acf92a3f
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit c98bd29917)
Now that we have arm_smccc_1_1_get_conduit(), we can hide the PSCI
implementation details from the arm spectre-v2 code, so let's do so.
As arm_smccc_1_1_get_conduit() implicitly checks that the SMCCC version
is at least SMCCC_VERSION_1_1, we no longer need to check this
explicitly where switch statements have a default case.
There should be no functional change as a result of this patch.
Change-Id: I61ad42fbdc1d2d684846e8eef54609889b101be3
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 6848253dde)
This reverts commit f818feceb5.
TF-A do not support resume its right now.
Change-Id: Ibfd120242406feeae9171aa9d657b9cb6366e154
Signed-off-by: Wu Liangqing <wlq@rock-chips.com>
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>
