The GMAC0/1 and MMU0/1(PCIe, SATA, USB OTG1) support CCI
(Cache Coherent Interconnect), Mark them as such.
Hardware feature for CCI were enabled at U-Boot miniloader level.
Note that MMU2 for USB OTG0 doesn't support CCI.
Change-Id: Ie632fc2ad987c3972076f65559c043b3da67d858
Signed-off-by: David Wu <david.wu@rock-chips.com>
Signed-off-by: Yifeng Zhao <yifeng.zhao@rock-chips.com>
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
Signed-off-by: William Wu <william.wu@rock-chips.com>
According to VESA DisplayPort Ver.1.4a - 5.1.1.1 Video
Colorimetry and CEA-861-F - 5.1 Default Encoding Parameters,
YCbCr format default use limit range. RGB format default
use limit range for CEA timing(except 640x480p or color depth
is 6 bit), and other timing should use full range.
The VOP Video Port only support full range when output RGB
format. So we just default config RGB format as full range
and YCbCr format as limit range.
Change-Id: I27e60c314c8cd17f69aa85eb380357fd8a78990f
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Fixes: 80647eb888 ("media: i2c: rk628: fix csc process mode and add range switch by user")
Signed-off-by: Jianwei Fan <jianwei.fan@rock-chips.com>
Change-Id: I2ffd203fa69ce7d73a38f00be47ef3ee9a8fcd07
Fixes: dfb6365006 ("media: i2c: rk628: clear interrupt should before process it")
Signed-off-by: Jianwei Fan <jianwei.fan@rock-chips.com>
Change-Id: Id13a298c69b20f87f3b808524b387144510739a7
If a request is dequeued, the transfer is cancelled.
Give back all the started requests.
Fixes: 2007d5815e ("usb: dwc3: gadget: properly skip over trbs on ep_dequeue")
Change-Id: I7a4d4e58435fb630681891a79bd5e04c19dbbdbd
Signed-off-by: William Wu <william.wu@rock-chips.com>
Current EP0 dequeue path will share the same as other EPs. However, there
are some special considerations that need to be made for EP0 transfers:
- EP0 transfers never transition into the started_list
- EP0 only has one active request at a time
In case there is a vendor specific control message for a function over USB
FFS, then there is no guarantee on the timeline which the DATA/STATUS stage
is responded to. While this occurs, any attempt to end transfers on
non-control EPs will end up having the DWC3_EP_DELAY_STOP flag set, and
defer issuing of the end transfer command. If the USB FFS application
decides to timeout the control transfer, or if USB FFS AIO path exits, the
USB FFS driver will issue a call to usb_ep_dequeue() for the ep0 request.
In case of the AIO exit path, the AIO FS blocks until all pending USB
requests utilizing the AIO path is completed. However, since the dequeue
of ep0 req does not happen properly, all non-control EPs with the
DWC3_EP_DELAY_STOP flag set will not be handled, and the AIO exit path will
be stuck waiting for the USB FFS data endpoints to receive a completion
callback.
Fix is to utilize dwc3_ep0_reset_state() in the dequeue API to ensure EP0
is brought back to the SETUP state, and ensures that any deferred end
transfer commands are handled. This also will end any active transfers
on EP0, compared to the previous implementation which directly called
giveback only.
Fixes: fcd2def663 ("usb: dwc3: gadget: Refactor dwc3_gadget_ep_dequeue")
Cc: stable <stable@kernel.org>
Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com>
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Link: https://lore.kernel.org/r/20231206201814.32664-1-quic_wcheng@quicinc.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 730e12fbec53ab59dd807d981a204258a4cfb29a)
Change-Id: I8f3749ebdc13b86e79713ca813b454cb1dacdb34
For the non-standard cables that double Rp connected to VBUS, when
husb311 detects one of CC is Rp, let do clear the another CC status
in anyway to dodge being stuck in the SNK_ATTACH_WAIT state.
[ 59.366185] VBUS on
[ 59.403488] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected]
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Change-Id: Ief2f01c97d1a7be81bca7dd26ecd975d35ea9877
Previous versions did not update the post csc status in
real time. This causes post csc was not properly closed
when post csc prop is cleared.
Change-Id: I9c65961517166bc0fb7b700e9b06fdfad1251f4f
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Because we can't gate the clock when using ufs, so we remove
UFSHCD_CAP_CLK_GATING support. However, ufshcd_runtime_suspend still
be called which can still call ufshcd_suspend->ufshcd_setup_clocks,
then ufshcd_setup_clocks() still tries to gate the clock which we
don't actually allow. Except for gating clock, ufshcd_suspend also send
H8 to the device. This rule is applied to system PM as well.
So the problem looks like:
[ T217] ueventd: restorecon_recursive: /sys/devices/platform/regulatory.0
[ T146] ufshcd-rockchip 2a2d0000.ufs: uic cmd 0x14 with arg3 0x0 completion timeout
[ T146] ufshcd-rockchip 2a2d0000.ufs: dme-reset: error code -110
Remove them together with UFSHCD_CAP_CLK_GATING.
BTW, no matter whether we call ufshcd_*_suspend/resume or not, wlun RPM
make sure all status come back:
[ 29.213545][ T146] Workqueue: pm pm_runtime_work
[ 29.213567][ T146] Call trace:
[ 29.213578][ T146] dump_backtrace+0xec/0x10c
[ 29.213598][ T146] show_stack+0x14/0x1c
[ 29.213616][ T146] dump_stack_lvl+0x68/0x88
[ 29.213631][ T146] dump_stack+0x14/0x34
[ 29.213644][ T146] ufshcd_hba_enable+0x32c/0x3b4
[ 29.213659][ T146] ufshcd_host_reset_and_restore+0x54/0x12c
[ 29.213674][ T146] ufshcd_reset_and_restore+0x60/0x1f8
[ 29.213693][ T146] __ufshcd_wl_resume+0xa0/0x4a8
[ 29.213710][ T146] ufshcd_wl_runtime_resume+0x38/0x154
[ 29.213726][ T146] scsi_runtime_resume+0x58/0x80
[ 29.213746][ T146] __rpm_callback+0x78/0x3bc
[ 29.213765][ T146] rpm_resume+0x434/0x670
[ 29.213782][ T146] __rpm_callback+0x1ac/0x3bc
[ 29.213799][ T146] rpm_resume+0x458/0x670
[ 29.213816][ T146] pm_runtime_work+0x9c/0xa0
[ 29.213833][ T146] process_one_work+0x1a4/0x3b0
[ 29.213847][ T146] worker_thread+0x258/0x428
[ 29.213861][ T146] kthread+0xe8/0x1b4
[ 29.213878][ T146] ret_from_fork+0x10/0x20
Fixes: 83dbc34b20 （“scsi: ufs: rockchip: Fix stability issues and add WB support”）
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: I30fcdf35575a882b1095c5f991d82e429eccd1ce
The tp of some screens has strict timing requirements (especially the
display and tp are integrated on a screen IC), while kernel-6.1 does
not have fb function. The notifier is added to correlate the sleep and
wake-up timing of display and tp. For screens with low requirements
for tp and display timing, you can choose whether to use it to notify
on wake-up and sleep.
Type: Function
Redmine ID: #474634#468692
Associated modifications: N/A
Test: N/A
Signed-off-by: Zhibin Huang <zhibin.huang@rock-chips.com>
Change-Id: I11cb63564fce97b6ca6b02cf12bc19db5d82124b
The mode comparison helps to confirm whether the display
mode of uboot logo is valid of the drm mode list in kernel.
The mode stored in dts has been fixed by .mode_fixup()
in uboot, which helps to deal with some workarounds, so
it is also needed to call .mode_fixup() when getting mode
list in kernel.
Change-Id: I2c74e66365a5e305ec8322316fdb7472e6df9fcd
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
If using the hdmi2dp ext borad, eDP uses the hardware
link of HDMI, whose phy is multiplexed with eDP, and
the HDMI controller does not actually work.
Change-Id: If3d3983ef5b14c1181f4c7fae5fb96969061656c
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
1.Reading edid consecutively 16 bytes at a time to
reduce the time consumed.
2.Increase the number of retries on failure to ensure
successful transfer.
Change-Id: I0ea92a4a80634771d1ecc7abe573986649a908e4
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
EDID will be clear when hdmi suspend. Linux system may not
actively read EDID when hdmi resume. So hdmi driver needs to read
edid when hdmi resume.
Change-Id: I2d37dc2fa278ba339fdb0294a9aa3d82150ea055
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
In RK3588, as default config, the dclk_vop2's clock tree
as follow:
pll_v0pll
v0pll
dclk_vop2_src
dclk_vop2
In the above case, we think that the dclk_vop2 will be the
input parameter in rockchip_drm_dclk_round_rate function.
By getting the parent clocks's parent clock, we can find
v0pll.
However, the input parameter is dclk_vop2_src instead of
dclk_vop2 now. And we can't find the v0pll which will filter
more display mode that may supported by VOP.
For RK3576, It has the same issue.
To avoid this issue happen, It just need to get the parent
clock in rockchip_drm_dclk_round_rate function.
Fixes: aebca4f07f ("drm/rockchip: vop2: filter unsupported mode when can't get correct dclk")
Change-Id: Ib041e0614a2d67354a4d22e14aaa625b07edcf35
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
RK3588_EDP dones not support hsync/vsync polarity configuration,
while RK3576_EDP does.
Change-Id: Ic24628333a81427e2141adcf544a05254a1586e0
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Disable UFS related clock in runtime is proved to be incorrect and
mismatch state between host and device should be recovered by reset the
controller to make sure each part is in the beginning status.
Meanwhile, we have verified WB works fine by test, so add WB support
as well.
Change-Id: I5af675576ef2b43ebe5061af204ba1fff5f3f233
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
dts config multi nvp6324, if previous nvp6324 register failed,
it will set i2c addr to 0xff, cause later nvp6324 register failed,
so fix it.
Signed-off-by: Wang Panzhenzhuan <randy.wang@rock-chips.com>
Change-Id: I39a4a9a59432918582ad23d918b316b66e99a632
When both CC1 and CC2 pins are simultaneously pulled up, it often leads
to the double Rp to Vbus cable being stuck in the SNK_ATTACH_WAIT state.
And the state machine fails to transition to the SNK_ATTACHED state.
Therefore, it is recommended to focus on transitioning the sink port to
the SNK_DEBOUNCED state instead. By doing so, the desired outcome can be
achieved more effectively.
[ 134.525750] VBUS on
[ 134.713240] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected]
[ 134.713249] state change TOGGLING -> SNK_ATTACH_WAIT [rev3 NONE_AMS]
Change-Id: Ib21f4f0322a193678a5f22007a515b3b19772b40
Signed-off-by: Michael Wu <michael@allwinnertech.com>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
Link: https://lore.kernel.org/linux-usb/20240312011300.75081-1-michael@allwinnertech.com/
The USB Type-C Cable and Connector Specification defines the wire
connections for the USB Type-C to USB 2.0 Standard-A cable assembly
(Release 2.2, Chapter 3.5.2).
The Notes says that Pin A5 (CC) of the USB Type-C plug shall be connected
to Vbus through a resister Rp.
However, there is a large amount of such double Rp connected to Vbus
non-standard cables which produced by UGREEN circulating on the market, and
it can affects the normal operations of the state machine easily,
especially to CC1 and CC2 be pulled up at the same time.
In fact, we can regard those cables as sink to avoid abnormal state.
Message as follow:
[ 58.900212] VBUS on
[ 59.265433] CC1: 0 -> 3, CC2: 0 -> 3 [state TOGGLING, polarity 0, connected]
[ 62.623308] CC1: 3 -> 0, CC2: 3 -> 0 [state TOGGLING, polarity 0, disconnected]
[ 62.625006] VBUS off
[ 62.625012] VBUS VSAFE0V
Change-Id: I415db22b0012ace9535039bc4c8e5ec113482e33
Signed-off-by: Michael Wu <michael@allwinnertech.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20230920063030.66312-1-michael@allwinnertech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
(cherry picked from commit dbc1defec1aa7d8d80da3ea9e3ddafbcfca8f822)
