When build with rv1126_defconfig:
before:
text data bss dec hex filename
7820 144 0 7964 1f1c drivers/media/platform/rockchip/cif/hw.o
after:
text data bss dec hex filename
4301 144 0 4445 115d drivers/media/platform/rockchip/cif/hw.o
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I0dee5f7f43da3eb58a65342319ccb77b5501e0ce
When build with rv1126_defconfig:
before:
text data bss dec hex filename
17063 144 0 17207 4337 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.o
after:
text data bss dec hex filename
7387 144 0 7531 1d6b drivers/net/ethernet/stmicro/stmmac/dwmac-rk.o
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I941f79357f686f5d35e727abea2fe26c4ea0dafa
When build with rv1126_defconfig:
before:
text data bss dec hex filename
8796 156 4 8956 22fc drivers/soc/rockchip/rockchip_pvtm.o
after:
text data bss dec hex filename
4508 156 4 4668 123c drivers/soc/rockchip/rockchip_pvtm.o
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I8c49713ebc48586aa4f08fb3ec965890c2beb1a2
This is an attempt to rehash commit 0cf884e819 ("usb: dwc2: add bus
suspend/resume for dwc2") on ToT. That commit was reverted in commit
b0bb9bb6ce ("Revert "usb: dwc2: add bus suspend/resume for dwc2"")
because apparently it broke the Altera SOCFPGA.
With all the changes that have happened to dwc2 in the meantime, it's
possible that the Altera SOCFPGA will just magically work with this
change now. ...and it would be good to get bus suspend/resume
implemented.
This change is a forward port of one that's been living in the Chrome
OS 3.14 kernel tree.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: Iba408750729ce6c8f1cb0c94a5e8891c7b240014
(cherry picked from commit 6f6d70597c)
clk init on time_init() which is before pure_initcall.
So call rockchip_soc_id_init() before call soc_is_rk3308b().
Change-Id: Iece3673bc7309ef9193df99f2a95e4b930613a3e
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Allow rockchip_soc_id_init() called before pure_initcall.
Change-Id: Ie0d3a18e96df02c2d6ab4aa3e17ea102685cd0c4
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
This patch provides the implementation of Collision Avoidance introduced
in PD3.0. The start of each Atomic Message Sequence (AMS) initiated by
the port will be denied if the current AMS is not interruptible. The
Source port will set the CC to SinkTxNG if it is going to initiate an
AMS, and SinkTxOk otherwise. Meanwhile, any AMS initiated by a Sink port
will be denied in TCPM if the port partner (Source) sets SinkTxNG except
for HARD_RESET and SOFT_RESET.
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Kyle Tso <kyletso@google.com>
Link: https://lore.kernel.org/r/20210114145053.1952756-2-kyletso@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Change-Id: Id0531c88ab8612745e042699a60f8a794415db36
(cherry picked from commit 0908c5aca3)
In this case playback_path set to ON, and then play music.
when playback close, stream mute power off the dac,
but the playback_path do not be set to OFF, so we must
power on the dac again.
Signed-off-by: XiaoTan Luo <lxt@rock-chips.com>
Change-Id: I7baa8518ccbb567cb146c5739f9a125da320e674
[Fix and using new sound APIs (snd_soc_kcontrol_component()/snd_soc_component_get_drvdata())]
Change-Id: I52487370ce33b057d9cf774b7c0cef06f2c98bca
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
[Fix and using new sound APIs (snd_soc_kcontrol_component()/snd_soc_component_get_drvdata())]
Change-Id: I6bc36626a8952ef28789dfacf57c2b27580a3467
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Use devm_clk_bulk_get_all instead of devm_clk_bulk_get. So we don't need
the complicated operation.
Change-Id: Idbe7668bd26b744f8d8b7d79d5eb99fa891bd0be
Signed-off-by: Simon Xue <xxm@rock-chips.com>
PD 3.0 spec defines a new mechanism for power role swap called
Fast role swap. This change enables TCPM to support FRS when
acting as sink.
Once the explicit contract is negotiated, sink port is
expected to query the source port for sink caps to
determine whether the source is FRS capable.
Bits 23 & 24 of fixed pdo of the sink caps from the source, when
set, indicates the current needed by the source when fast role
swap is in progress(Implicit contract phasae). 0 indicates that
the source does not support Fast Role Swap.
Upon receiving the FRS signal from the source,
TCPC(TCPM_FRS_EVENT) informs TCPM to start the Fast role swap sequence.
1. TCPM sends FRS PD message: FR_SWAP_SEND
2. If response is not received within the expiry of
SenderResponseTimer, Error recovery is triggered.:
FR_SWAP_SEND_TIMEOUT
3. Upon receipt of the accept message, TCPM waits for
PSSourceOffTimer for PS_READY message from the partner:
FR_SWAP_SNK_SRC_NEW_SINK_READY.
TCPC is expected to autonomously turn on vbus once the FRS
signal is received and vbus voltage falls below vsafe5v within
tSrcFrSwap. This is different from traditional power role swap
where the vbus sourcing is turned on by TCPM.
4. By this time, TCPC most likely would have started to
source vbus, TCPM waits for tSrcFrSwap to see if the
lower level TCPC driver signals TCPM_SOURCING_VBUS event:
FR_SWAP_SNK_SRC_SOURCE_VBUS_APPLIED.
5. When TCPC signals sourcing vbus, TCPM sends PS_READY msg and
changes the CC pin from Rd to Rp. This is the end of fast
role swap sequence and TCPM initiates the sequnce to negotiate
explicit contract by transitioning into SRC_STARTUP after
SwapSrcStart.
The code is written based on the sequence described in "Figure 8-107:
Dual-role Port in Sink to Source Fast Role Swap State Diagram" of
USB Power Delivery Specification Revision 3.0, Version 1.2.
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20201008061556.1402293-7-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Change-Id: I1316c4498187dc67a5d652341ddb48118a201acf
(cherry picked from commit 8dc4bd0736)
This issue found on yocto builing the kernel.
yocto/build/tmp/work-shared/rockchip-rk3568-evb/kernel-source/scripts/mkimg:
line 227:./scripts/io-domain.sh: No such file or directory
arch/arm64/Makefile:203: recipe for target 'rk3568-evb1-ddr4-v10-linux.img' failed
make[2]: *** [rk3568-evb1-ddr4-v10-linux.img] Error 127
Makefile:146: recipe for target 'sub-make' failed
Fixes: b25c12a00a ("scripts: add io-domain.sh for rk356x io-domain check")
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Change-Id: Id6d496fe886ce79c9efee30a5f4d2cd270d34efd
The rockchip platforms, such as RK3399 and RK3568
otg port enable pm runtime to swith peripheral and
host mode. During dwc3 core probe, there are two
place which may call pm_runtime_put_sync_suspend(),
one is in dwc3_rockchip_async_probe(), the other one
is in the drd_work called from dwc3_core_init_mode().
The dwc3_rockchip_async_probe() and drd_work are
scheduled asynchronously, and the order of their
execution is randomly.
If the drd_work is handled prior to the async probe,
there's no problem, but if the async probe is handled
firstly, the pm_runtime_put_sync_suspend() will be
duplicated twice. If this issue happens, the value of
dwc3 power.usage_count is -1, in other words, the
runtime put/suspend operations is unbalanced, and
fail to do dwc3_runtime_suspend/resume.
This patch avoids do pm_runtime_put_sync_suspend()
in the drd_work if no usb connected.
Fixes: bb4c791a42 ("usb: dwc3: core: add pm runtime for drd mode")
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
Change-Id: I088a7ddb60eb817093810fe874d5fdb242c73ca7
Enable lt8619c HDMI to BT656/BT1120 bridge driver for hdmi-in
application. Which found on rk3568-evb6-ddr3-v10.
Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
Change-Id: Idd8bdfd2f2d2cc4af9e1d47e3002ebcee1252df5
1. Support procfs, both debugfs and procfs.
2. Modify the debug node name:
/sys/kernel/debug/rga2_debug/rga2
-> /sys/kernel/debug/rkrga/debug
-> /proc/rkrga/debug (add)
3. Add a node to view the driver version number: driver_version.
4. Add CONFIG_ROCKCHIP_RGA2_PROC_FS/ROCKCHIP_RGA2_DEBUG_FS/
ROCKCHIP_RGA2_DEBUGGER, Where CONFIG_ROCKCHIP_RGA2_PROC_FS
defaults to n, CONFIG_ROCKCHIP_RGA2_DEBUGGER defaults to y.
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: I89a971f18301ffa9cc7ac1962ebeee5e97d209aa
ROLE_CONTROL register would not have the actual CC terminations
unless the port does not set ROLE_CONTROL.DRP. For DRP ports,
CC_STATUS.cc1/cc2 indicates the final terminations applied
when TCPC enters potential_connect_as_source/_sink.
For DRP ports, infer port role from CC_STATUS and set corresponding
CC terminations before setting the orientation.
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Link: https://lore.kernel.org/r/20200901025927.3596190-4-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
Change-Id: I108119eb0d9accf5697b9d69f1188766c2bdb0b9
(cherry picked from commit 57ce64668f)
"tReceiverResponse 15 ms Section 6.6.2
The receiver of a Message requiring a response Shall respond
within tReceiverResponse in order to ensure that the
sender’s SenderResponseTimer does not expire."
When the cpu complex is busy running other lower priority
work items, TCPM's work queue sometimes does not get scheduled
on time to meet the above requirement from the spec.
Moving to kthread_work apis to run with real time priority.
Further, as observed in 1ff688209e, moving to hrtimers to
overcome scheduling latency while scheduling the delayed work.
TCPM has three work streams:
1. tcpm_state_machine
2. vdm_state_machine
3. event_work
tcpm_state_machine and vdm_state_machine both schedule work in
future i.e. delayed. Hence each of them have a corresponding
hrtimer, tcpm_state_machine_timer & vdm_state_machine_timer.
When work is queued right away kthread_queue_work is used.
Else, the relevant timer is programmed and made to queue
the kthread_work upon timer expiry.
kthread_create_worker only creates one kthread worker thread,
hence single threadedness of workqueue is retained.
Change-Id: Iafd9ca68a00b61e39cc9de2609eaef2c277eabb0
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20200818192758.2562908-1-badhri@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Wang Jie <dave.wang@rock-chips.com>
(cherry picked from commit 3ed8e1c2ac)
According to commit 9bde4e671f ("drm/rockchip: vop: fix iommu crash
with async atomic")
These two callback were added to avoid iommu crash on async
commit caused by drm_atomic_clean_old_fb after drm_atomic_async_commit.
drm_atomic_clean_old_fb was removed after commit
e00fb8564e ("drm: Stop updating plane->crtc/fb/old_fb on atomic drivers")
So we can remove them to make life simpler.
Change-Id: Iea1f2dbadd9bcfad5b8447831c0d31068d4fa97b
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
We assign window between vp by plane_mask now, no
need to check which vp is activated from register.
Change-Id: I89d22f253dcd26898dc79304d51b8a8d9e802bb2
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
Rockchip platforms don't support HS200 or HS400 at low speed, so
we must limit it.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: I40eb9f117fd83789b6ab7a16d44049e16786698b
As we mask our SDHCI controller as SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
host->max_clk is derived from core clock in the first place. Then
f_max works together with it.
If we adjust loader's core clk setting, such as 50MHz, we will get
50MHz for host->max_clk, because .get_max_clock() reads core clk
when probing driver. That will lead f_max be set to 50MHz as well,
no matter if max-frequency is set higher than 50MHz.
We can simple solve this problem by assigning core clk as 200MHz
in the first place and then let max-frequency property takes over
it.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: Idb2fdb8f68881d0286d977dc3718b74c30d3bc67
