The PWM io input/output state is controlled by PWM mode
configuration. In order to avoid the antagonistic drive
state between the PWM pin and the external pin, keep the
PWM mode fixed in capture mode although PWM is disabled.
Change-Id: I6183987c9bef6f444726643f878c5384f63844d0
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:2386: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* rockchip_atomic_helper_update_plane copy from drm_atomic_helper_update_plane
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:2386: warning: missing initial short description on line:
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:2458: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* drm_atomic_helper_disable_plane copy from drm_atomic_helper_disable_plane
drivers/gpu/drm/rockchip/rockchip_drm_vop.c:2458: warning: missing initial short description on line:
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: Ie9d2e00238e4c45d6a8ad7581ea7482b14092a23
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:6139: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c:6210: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I24f65edf0c4900c09d5b68411a8f2dd473260ce6
The event of the notification does not match the actual status
Type: Fix
Redmine ID: N/A
Associated modifications: N/A
Test: N/A
Signed-off-by: Zhibin Huang <zhibin.huang@rock-chips.com>
Change-Id: Ib2a9cb1888c27c74cc14f0f09707a670e65f0aa2
for hardware reason, we need judge wakeup sources to avoid wakeup
screen by wrong irq when wakeup from ultra sleep
Change-Id: I5a3ef85eb71a312ba0a9e992b70ef0b14e00fc47
Signed-off-by: Zorro Liu <lyx@rock-chips.com>
spi_nor_write_sr will pollute the buffer of sr_cr buffer when calling
spi_nor_read_sr.
Change-Id: I217141297df4f448b64c61f1573e7e40d6874903
Signed-off-by: Jon Lin <jon.lin@rock-chips.com>
The crtc_clock div2 has been done at drm_mode_convert_to_origin_mode() from
the following commit:
commit 649255c0e3 ("drm/rockchip: drv: Add crtc_clock convert in
drm_mode_convert_to_{split,origin}_mode()")
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I530d9582a52cea7d432208bc835fb19be051a7a0
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
