We use jitter bypass mode for spdif, so do not need to set jitter mode
related bit in SPDIF_CTRL_ADDR register. Also, we need to enable
SPDIF_ENABLE bit.
(am from https://patchwork.kernel.org/patch/10417647/)
Change-Id: Ieab2803435d8747ebc3890edaf9682dca9e3a3f3
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
The rk809 sleep pin connect to rk1808 gpio0_a4.
The reserved function of the gpio0_a4 caused rk809 reset.
Change-Id: Iee36da1f67831b7e58076a614929cfac6675a99d
Signed-off-by: Shengfei Xu <xsf@rock-chips.com>
This patch adds "snps,xhci-trb-ent-quirk" for DWC3 controllers
in RK1808/RK3328/RK3399/RK3399pro-npu.
Change-Id: I708f62747150316d66459f02b399d7c9b2667636
Signed-off-by: William Wu <william.wu@rock-chips.com>
On some xHCI controllers (e.g. Rockchip RK3399/RK3328/RK1808),
which are integrated in DWC3 IP, need to enable the Evaluate
Next TRB(ENT) flag in the TRB data structure to force xHC to
pre-fetch the next TRB of a TD. It's useful for the stability
of xHCI when transfer large data.
I have verify this patch on the following three cases:
Case 1:
On RK3399/RK3399Pro platforms, I found that when USB 3.0
read/write at the same time in the following test case,
it may easily fail without this patch.
Host transfer: 1024B, 4MB, 4MB, 4MB
Device transfer: 1024B, 4MB, 4MB, 4MB
Both Host and Device transfer "24B, 4MB, 4MB, 4M" Repeatedly
until transfer fail.
Case 2:
On RK3399 platform, Type-C1 USB 3.0 port connects with HUB
and Orbbec USB 3.0 Camera with the enumeration information:
usb 5-1: new high-speed USB device number 2 using xhci-hcd
usb 5-1: New USB device found, idVendor=05e3, idProduct=0610
usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-1: Product: USB2.1 Hub
usb 5-1: Manufacturer: GenesysLogic
hub 5-1:1.0: USB hub found
hub 5-1:1.0: 2 ports detected
usb 6-1: new SuperSpeed USB device number 2 using xhci-hcd
usb 6-1: New USB device found, idVendor=05e3, idProduct=0620
usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 6-1: Product: USB3.1 Hub
usb 6-1: Manufacturer: GenesysLogic
hub 6-1:1.0: USB hub found
hub 6-1:1.0: 2 ports detected
usb 5-1.2: new high-speed USB device number 3 using xhci-hcd
usb 5-1.2: New USB device found, idVendor=2bc5, idProduct=050d
usb 5-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=3
usb 5-1.2: Product: USB
usb 5-1.2: Manufacturer: USB
usb 5-1.2: SerialNumber: USB
uvcvideo: Found UVC 1.00 device USB (2bc5:050d)
usb 6-1.2: new SuperSpeed USB device number 3 using xhci-hcd
usb 6-1.2: New USB device found, idVendor=2bc5, idProduct=060d
usb 6-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 6-1.2: Product: Orbbec(R) Astra(TM)
usb 6-1.2: Manufacturer: Orbbec(R)
Without this patch, it's possible to fail to open the Orbbec USB 3.0
camera or fail to preview image.
Case3:
On RK3399Pro platform, transfer the NPU data between the NPU USB 3.0
device and RK3399 USB 3.0 host.
Change-Id: I87b1d8b8b6912d77b988362f2f6dcd7766da8b0e
Signed-off-by: William Wu <william.wu@rock-chips.com>
If an xhci platform needs to enable the ENT flag in the TRB
to force the xHC to pre-fetch the next TRB of a TD, then
add the XHCI_TRB_ENT_QUIRK flag.
Change-Id: Ib7cc095a848f0846ad995529ad703ae4e4ee4d44
Signed-off-by: William Wu <william.wu@rock-chips.com>
According to the "6.4 Transfer Request Block (TRB)" in xHCI
Specification, the max transfer length of a TRB is 64KB.
However, on Rockchip platforms which support xHCI in DWC3 IP
have problem if transfer more then 4KB in one TRB.
We don't know the root cause, maybe it's the DWC3 Tx/Rx FIFO
related, such as RK3399, it only support Tx FIFO 4136 Bytes
and Rx FIFO 3072 Bytes for SS Bus instance.
With the patch, it can make the xHCI transfer more stable on
Rockchip platforms, but it also cause transfer performance
loss. I test on RK3399 EVB Type-C USB 3.0 port with UAS USB 3.0
SSD, it cause 10% performance loss when use dd command to read/
write the UAS USB 3.0 SSD (350MBps -> 315MBps).
Change-Id: I11b10f6618d54d4cb0a778e5c0b4216227184e47
Signed-off-by: William Wu <william.wu@rock-chips.com>
ICN6211 is a bridge chip which receives MIPI-DSI inputs and
sends RGB outputs.
MIPI-DSI supports up to 4 lanes and each lane operates at
1Gbps maximum; the totally maximum input bandwidth is 4Gbps;
and the MIPI defined ULPS(ultra-low-power state) is also supported.
ICN6211 decodes MIPI-DSI 16bpp RGB565 and 18bpp RGB666 and
24bpp RGB888 packets.
The RGB output 18 or 24 bits pixel with pixel clock range of
2MHz to 154MHz.
ICN6211 support video resolution up to FHD (1920x1080) and
WUXGA(1920x1200).
Change-Id: I85cc0dbc8e628b9b1a09371df1d92975202c5c10
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
stream raw support sensor bayer raw to
mipi to dmatx to ddr.
Change-Id: Ide24b6e9b2e5d95a6627cf046979ad62eeb9dea9
Signed-off-by: Cai YiWei <cyw@rock-chips.com>
Hdmi suspend or resume may be called before hdmi initialization. We must
verify that hdmi is initialized first.
Change-Id: I2a680209e64b9c1aebc2d9ee19d543927137afd0
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
If you try to store u64 in a kfifo (or a struct with u64 members),
then the buf member of __STRUCT_KFIFO_PTR will cause 4 bytes
padding due to alignment (note that struct __kfifo is 20 bytes
on 32 bit).
That in turn causes the __is_kfifo_ptr() to fail, which is caught
by kfifo_alloc(), which now returns EINVAL.
So, ensure that __is_kfifo_ptr() compares to the right structure.
Change-Id: I7b5c8415a6bb8f54bbc8ec50fa98e1803cda3ce8
Signed-off-by: Sean Young <sean@mess.org>
Acked-by: Stefani Seibold <stefani@seibold.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 8a866fee39)
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
It would help the other driver to install the DMA ops for
itself.
Change-Id: I4c7283bbd8889650684630e169696133fdc6801a
Signed-off-by: Randy Li <randy.li@rock-chips.com>
