konka tv should switch pattern after set to yuv420 10bit or
the TV might not recognize the signal.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: Ie8fba7e1ec3a4a2f2bff9943723c5862c55273d4
When switching modes, the synchronization reset time
of the four lanes cannot be too long, ldo cannot be
turned off either.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: I3b8308bf03e9f5796f93189a009d22100c642894
Fix green screen after color format switch in MI/HUAWEI TV.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: Ic73ca68029fc8ce948e9e731291d4bbd1d9c1ce2
The dst is device memory, when accessing dst, it need alignment, use
memcpy_toio instead of memcpy.
Change-Id: I2f0af816c92fdb9871ff4842e10522980e9a1c50
Signed-off-by: Chen Shunqing <csq@rock-chips.com>
When encoder slice mode is enabled the slice irq will deactivate iommu
device and get stuck. So only the last slice irq with IRQ_WAKE_THREAD
return can deactivate iommu device.
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
Change-Id: I9edb8616be56fbc3eace0528407e90f01cd33a5d
Using order 4 pages would be helpful for IOMMUs mapping, but trying to
get order 4 pages could spend quite much time in the page allocation.
From the perspective of responsiveness, the deterministic memory
allocation speed, I think, is quite important.
The order 4 allocation with __GFP_RECLAIM may spend much time in
reclaim and compation logic. __GFP_NORETRY also may affect. These cause
unpredictable delay.
To get reasonable allocation speed from dma-buf system heap, use
HIGH_ORDER_GFP for order 4 to avoid reclaim. And let me remove
meaningless __GFP_COMP for order 0.
According to my tests, order 4 with MID_ORDER_GFP could get more number
of order 4 pages but the elapsed times could be very slow.
time order 8 order 4 order 0
584 usec 0 160 0
28,428 usec 0 160 0
100,701 usec 0 160 0
76,645 usec 0 160 0
25,522 usec 0 160 0
38,798 usec 0 160 0
89,012 usec 0 160 0
23,015 usec 0 160 0
73,360 usec 0 160 0
76,953 usec 0 160 0
31,492 usec 0 160 0
75,889 usec 0 160 0
84,551 usec 0 160 0
84,352 usec 0 160 0
57,103 usec 0 160 0
93,452 usec 0 160 0
If HIGH_ORDER_GFP is used for order 4, the number of order 4 could be
decreased but the elapsed time results were quite stable and fast
enough.
time order 8 order 4 order 0
1,356 usec 0 155 80
1,901 usec 0 11 2384
1,912 usec 0 0 2560
1,911 usec 0 0 2560
1,884 usec 0 0 2560
1,577 usec 0 0 2560
1,366 usec 0 0 2560
1,711 usec 0 0 2560
1,635 usec 0 28 2112
544 usec 10 0 0
633 usec 2 128 0
848 usec 0 160 0
729 usec 0 160 0
1,000 usec 0 160 0
1,358 usec 0 160 0
2,638 usec 0 31 2064
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Reviewed-by: John Stultz <jstultz@google.com>
Link: https://patchwork.kernel.org/project/linux-mm/patch/20230303050332.10138-1-jaewon31.kim@samsung.com/
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: I352021b68684ea33e4538a8beda9399fed1d1d79
Using order 4 pages would be helpful for IOMMUs mapping, but trying to
get order 4 pages could spend quite much time in the page allocation.
From the perspective of responsiveness, the deterministic memory
allocation speed, I think, is quite important.
The order 4 allocation with __GFP_RECLAIM may spend much time in
reclaim and compation logic. __GFP_NORETRY also may affect. These cause
unpredictable delay.
To get reasonable allocation speed from dma-buf system heap, use
HIGH_ORDER_GFP for order 4 to avoid reclaim. And let me remove
meaningless __GFP_COMP for order 0.
According to my tests, order 4 with MID_ORDER_GFP could get more number
of order 4 pages but the elapsed times could be very slow.
time order 8 order 4 order 0
584 usec 0 160 0
28,428 usec 0 160 0
100,701 usec 0 160 0
76,645 usec 0 160 0
25,522 usec 0 160 0
38,798 usec 0 160 0
89,012 usec 0 160 0
23,015 usec 0 160 0
73,360 usec 0 160 0
76,953 usec 0 160 0
31,492 usec 0 160 0
75,889 usec 0 160 0
84,551 usec 0 160 0
84,352 usec 0 160 0
57,103 usec 0 160 0
93,452 usec 0 160 0
If HIGH_ORDER_GFP is used for order 4, the number of order 4 could be
decreased but the elapsed time results were quite stable and fast
enough.
time order 8 order 4 order 0
1,356 usec 0 155 80
1,901 usec 0 11 2384
1,912 usec 0 0 2560
1,911 usec 0 0 2560
1,884 usec 0 0 2560
1,577 usec 0 0 2560
1,366 usec 0 0 2560
1,711 usec 0 0 2560
1,635 usec 0 28 2112
544 usec 10 0 0
633 usec 2 128 0
848 usec 0 160 0
729 usec 0 160 0
1,000 usec 0 160 0
1,358 usec 0 160 0
2,638 usec 0 31 2064
Signed-off-by: Jaewon Kim <jaewon31.kim@samsung.com>
Reviewed-by: John Stultz <jstultz@google.com>
Link: https://patchwork.kernel.org/project/linux-mm/patch/20230303050332.10138-1-jaewon31.kim@samsung.com/
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: Ib9386a5450b57d711d100c36c75d38a033f7bcc3
1. modify the process of sending mcu cmds, not to find
crtc for each cmd repeatedly.
2. find crtc by crtc port node instead of crtc node,
in order to adapt multiple VPs like VOP2/VOP3.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Change-Id: I2b994d17b3da6ece32616d15e0a54050e3af62be
The pins of gmac0/vcc_mipicsi0 and rgb are multiplexed.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Change-Id: Idc602639641eac0b419065f2ae862ddbe1491e95
RK3588 don't support pixel repetition function,
so resolution that frequency less than 25 Mhz
is unsupported.
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Change-Id: I6c3f3af73738e5c96ef359abebbaf4884261c81e
for vdpu382 rkvdec, use soft reset first
Signed-off-by: Chandler Chen <chandler.chen@rock-chips.com>
Change-Id: I99f369609f882eae9924f6ac59d3d6e5522004ad
drivers/pci/controller/dwc/pcie-dw-rockchip.c: In function 'rk_pcie_downstream_dev_to_d0':
drivers/pci/controller/dwc/pcie-dw-rockchip.c:2207:38: error: 'struct pci_dev' has no member naned 'l1ss'
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Change-Id: I67c0ed74183bc5bf7cb8975b8bcbcc4bebaa5ad5
