The RK3566 OTG port supports USB 2.0 only, and make the internal
2.0 utmi clock to be routed as the 3.0 (pipe) clock. We find
that if the ACLK_PIPE is set to 400MHz, the DWC3 controller may
suspend the USB 2.0 PHY due to some unknown reason during usb
enumeration, and the utmi clock will be gated off, it makes the
DWC3 controller to work abnormally.
This patch adds dis_u2_susphy_quirk for RK3566 OTG to avoid USB
2.0 PHY enter suspend mode if the suspend conditions of DWC3
controller are valid. And the USB 2.0 PHY suspend mode can be
controlled in the PHY driver.
Change-Id: I5b00e8da8e5865d78cd706fe00476773aef8f8d5
Signed-off-by: William Wu <william.wu@rock-chips.com>
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>
