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
Restore CLOCK_ALLOW_WRITE_DEBUGFS define when system is Linux
without Android runtime.
Fixes: 861a024589 ("ANDROID: clk: Enable writable debugfs files")
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I7e5e8bade70191ceeca819dbbb45d84c687925c7
the dst is device memory, when accessing dst, it need alignment, use
memcpy_toio instead of memcpy.
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Change-Id: Ie761ac1660ef841b44bc835671b7f9bd6a0f66e4
Before this patch, the rknpu mem uses the partial sync ops from dmabuf,
which is not upstream patch. this patch makes the sync ioctl to use dma
apis directly.
Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Change-Id: Id648f567af86a36459d10e96db2aec2cd4177fce
Delete unused definition and modify the error register definition.
Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
Change-Id: I255c17049bc28faf108dbca8ec0337d3ccb11555
The dsm sound may be channel disorder when play sometimes,
we can reset the rk_dsm to reconfigure the IP and make it
work well.
Signed-off-by: Jason Zhu <jason.zhu@rock-chips.com>
Change-Id: Iece70267c478c0ec60f685ab85e39ff365b16f4c
