Update kernel source for Redmi Note 3 SDN(Kenzo) #64
Comments
|
Sorry didn't check that there was an issue already there for this. Closing this. Link here: #60 |
acervenky
pushed a commit
to acervenky/quax_raphael-q
that referenced
this issue
Dec 7, 2019
commit b803974 upstream. This fixes the below calltrace when the CONFIG_DMA_API_DEBUG is enabled. DMA-API: thunderx_mmc 0000:01:01.4: cpu touching an active dma mapped cacheline [cln=0x000000002fdf9800] WARNING: CPU: 21 PID: 1 at kernel/dma/debug.c:596 debug_dma_assert_idle+0x1f8/0x270 Modules linked in: CPU: 21 PID: 1 Comm: init Not tainted 5.3.0-rc1-next-20190725-yocto-standard+ MiCode#64 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 80400009 (Nzcv daif +PAN -UAO) pc : debug_dma_assert_idle+0x1f8/0x270 lr : debug_dma_assert_idle+0x1f8/0x270 sp : ffff0000113cfc10 x29: ffff0000113cfc10 x28: 0000ffff8c880000 x27: ffff800bc72a0000 x26: ffff000010ff8000 x25: ffff000010ff8940 x24: ffff000010ff8968 x23: 0000000000000000 x22: ffff000010e83700 x21: ffff000010ea2000 x20: ffff000010e835c8 x19: ffff800bc2c73300 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff000010e835c8 x14: 6d20616d64206576 x13: 69746361206e6120 x12: 676e696863756f74 x11: 20757063203a342e x10: 31303a31303a3030 x9 : 303020636d6d5f78 x8 : 3230303030303030 x7 : 00000000000002fd x6 : ffff000010fd57d0 x5 : 0000000000000000 x4 : ffff0000106c5210 x3 : 00000000ffffffff x2 : 0000800bee9c0000 x1 : 57d5843f4aa62800 x0 : 0000000000000000 Call trace: debug_dma_assert_idle+0x1f8/0x270 wp_page_copy+0xb0/0x688 do_wp_page+0xa8/0x5b8 __handle_mm_fault+0x600/0xd00 handle_mm_fault+0x118/0x1e8 do_page_fault+0x200/0x500 do_mem_abort+0x50/0xb0 el0_da+0x20/0x24 ---[ end trace a005534bd23e109f ]--- DMA-API: Mapped at: debug_dma_map_sg+0x94/0x350 cvm_mmc_request+0x3c4/0x988 __mmc_start_request+0x9c/0x1f8 mmc_start_request+0x7c/0xb0 mmc_blk_mq_issue_rq+0x5c4/0x7b8 Signed-off-by: Kevin Hao <haokexin@gmail.com> Fixes: ba3869f ("mmc: cavium: Add core MMC driver for Cavium SOCs") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mi-code
pushed a commit
that referenced
this issue
May 6, 2023
load_bpf_file() should fail if ioctl with command PERF_EVENT_IOC_ENABLE and PERF_EVENT_IOC_SET_BPF fails. When they do fail, proper error messages are printed. With this change, the below "syscall_tp" run shows that the maximum number of bpf progs attaching to the same perf tracepoint is indeed enforced. $ ./syscall_tp -i 64 prog #0: map ids 4 5 ... prog #63: map ids 382 383 $ ./syscall_tp -i 65 prog #0: map ids 4 5 ... prog #64: map ids 388 389 ioctl PERF_EVENT_IOC_SET_BPF failed err Argument list too long Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
YumeMichi
pushed a commit
to YumeMichi/Xiaomi_Kernel_OpenSource
that referenced
this issue
Jun 24, 2023
ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
enable it in a config. It leads to using find_next_bit() which is less
efficient:
0000000000000000 <find_first_bit>:
0: aa0003e4 mov x4, x0
4: aa0103e0 mov x0, x1
8: b4000181 cbz x1, 38 <find_first_bit+0x38>
c: f9400083 ldr x3, [x4]
10: d2800802 mov x2, #0x40 // MiCode#64
14: 91002084 add x4, x4, #0x8
18: b40000c3 cbz x3, 30 <find_first_bit+0x30>
1c: 14000008 b 3c <find_first_bit+0x3c>
20: f8408483 ldr x3, [x4], MiCode#8
24: 91010045 add x5, x2, #0x40
28: b50000c3 cbnz x3, 40 <find_first_bit+0x40>
2c: aa0503e2 mov x2, x5
30: eb02001f cmp x0, x2
34: 54ffff68 b.hi 20 <find_first_bit+0x20> // b.pmore
38: d65f03c0 ret
3c: d2800002 mov x2, #0x0 // #0
40: dac00063 rbit x3, x3
44: dac01063 clz x3, x3
48: 8b020062 add x2, x3, x2
4c: eb02001f cmp x0, x2
50: 9a829000 csel x0, x0, x2, ls // ls = plast
54: d65f03c0 ret
...
0000000000000118 <_find_next_bit.constprop.1>:
118: eb02007f cmp x3, x2
11c: 540002e2 b.cs 178 <_find_next_bit.constprop.1+0x60> // b.hs, b.nlast
120: d346fc66 lsr x6, x3, MiCode#6
124: f8667805 ldr x5, [x0, x6, lsl MiCode#3]
128: b4000061 cbz x1, 134 <_find_next_bit.constprop.1+0x1c>
12c: f8667826 ldr x6, [x1, x6, lsl MiCode#3]
130: 8a0600a5 and x5, x5, x6
134: ca0400a6 eor x6, x5, x4
138: 92800005 mov x5, #0xffffffffffffffff // #-1
13c: 9ac320a5 lsl x5, x5, x3
140: 927ae463 and x3, x3, #0xffffffffffffffc0
144: ea0600a5 ands x5, x5, x6
148: 54000120 b.eq 16c <_find_next_bit.constprop.1+0x54> // b.none
14c: 1400000e b 184 <_find_next_bit.constprop.1+0x6c>
150: d346fc66 lsr x6, x3, MiCode#6
154: f8667805 ldr x5, [x0, x6, lsl MiCode#3]
158: b4000061 cbz x1, 164 <_find_next_bit.constprop.1+0x4c>
15c: f8667826 ldr x6, [x1, x6, lsl MiCode#3]
160: 8a0600a5 and x5, x5, x6
164: eb05009f cmp x4, x5
168: 540000c1 b.ne 180 <_find_next_bit.constprop.1+0x68> // b.any
16c: 91010063 add x3, x3, #0x40
170: eb03005f cmp x2, x3
174: 54fffee8 b.hi 150 <_find_next_bit.constprop.1+0x38> // b.pmore
178: aa0203e0 mov x0, x2
17c: d65f03c0 ret
180: ca050085 eor x5, x4, x5
184: dac000a5 rbit x5, x5
188: dac010a5 clz x5, x5
18c: 8b0300a3 add x3, x5, x3
190: eb03005f cmp x2, x3
194: 9a839042 csel x2, x2, x3, ls // ls = plast
198: aa0203e0 mov x0, x2
19c: d65f03c0 ret
...
0000000000000238 <find_next_bit>:
238: a9bf7bfd stp x29, x30, [sp, #-16]!
23c: aa0203e3 mov x3, x2
240: d2800004 mov x4, #0x0 // #0
244: aa0103e2 mov x2, x1
248: 910003fd mov x29, sp
24c: d2800001 mov x1, #0x0 // #0
250: 97ffffb2 bl 118 <_find_next_bit.constprop.1>
254: a8c17bfd ldp x29, x30, [sp], MiCode#16
258: d65f03c0 ret
Enabling find_{first,next}_bit() would also benefit for_each_{set,clear}_bit().
On A-53 find_first_bit() is almost twice faster than find_next_bit(), according
to lib/find_bit_benchmark (thanks to Alexey for testing):
GENERIC_FIND_FIRST_BIT=n:
[7126084.948181] find_first_bit: 47389224 ns, 16357 iterations
[7126085.032315] find_first_bit: 19048193 ns, 655 iterations
GENERIC_FIND_FIRST_BIT=y:
[ 84.158068] find_first_bit: 27193319 ns, 16406 iterations
[ 84.233005] find_first_bit: 11082437 ns, 656 iterations
GENERIC_FIND_FIRST_BIT=n bloats the kernel despite that it disables generation
of find_{first,next}_bit():
yury:linux$ scripts/bloat-o-meter vmlinux vmlinux.ffb
add/remove: 4/1 grow/shrink: 19/251 up/down: 564/-1692 (-1128)
...
Overall, GENERIC_FIND_FIRST_BIT=n is harmful both in terms of performance and
code size, and it's better to have GENERIC_FIND_FIRST_BIT enabled.
Tested-by: Alexey Klimov <aklimov@redhat.com>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210225135700.1381396-2-yury.norov@gmail.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: atndko <z1281552865@gmail.com>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Change-Id: Idbea6884a499eb41bec524e583af5fd11c7600d2
YumeMichi
pushed a commit
to YumeMichi/Xiaomi_Kernel_OpenSource
that referenced
this issue
Jul 12, 2023
ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
enable it in a config. It leads to using find_next_bit() which is less
efficient:
0000000000000000 <find_first_bit>:
0: aa0003e4 mov x4, x0
4: aa0103e0 mov x0, x1
8: b4000181 cbz x1, 38 <find_first_bit+0x38>
c: f9400083 ldr x3, [x4]
10: d2800802 mov x2, #0x40 // MiCode#64
14: 91002084 add x4, x4, #0x8
18: b40000c3 cbz x3, 30 <find_first_bit+0x30>
1c: 14000008 b 3c <find_first_bit+0x3c>
20: f8408483 ldr x3, [x4], MiCode#8
24: 91010045 add x5, x2, #0x40
28: b50000c3 cbnz x3, 40 <find_first_bit+0x40>
2c: aa0503e2 mov x2, x5
30: eb02001f cmp x0, x2
34: 54ffff68 b.hi 20 <find_first_bit+0x20> // b.pmore
38: d65f03c0 ret
3c: d2800002 mov x2, #0x0 // #0
40: dac00063 rbit x3, x3
44: dac01063 clz x3, x3
48: 8b020062 add x2, x3, x2
4c: eb02001f cmp x0, x2
50: 9a829000 csel x0, x0, x2, ls // ls = plast
54: d65f03c0 ret
...
0000000000000118 <_find_next_bit.constprop.1>:
118: eb02007f cmp x3, x2
11c: 540002e2 b.cs 178 <_find_next_bit.constprop.1+0x60> // b.hs, b.nlast
120: d346fc66 lsr x6, x3, MiCode#6
124: f8667805 ldr x5, [x0, x6, lsl MiCode#3]
128: b4000061 cbz x1, 134 <_find_next_bit.constprop.1+0x1c>
12c: f8667826 ldr x6, [x1, x6, lsl MiCode#3]
130: 8a0600a5 and x5, x5, x6
134: ca0400a6 eor x6, x5, x4
138: 92800005 mov x5, #0xffffffffffffffff // #-1
13c: 9ac320a5 lsl x5, x5, x3
140: 927ae463 and x3, x3, #0xffffffffffffffc0
144: ea0600a5 ands x5, x5, x6
148: 54000120 b.eq 16c <_find_next_bit.constprop.1+0x54> // b.none
14c: 1400000e b 184 <_find_next_bit.constprop.1+0x6c>
150: d346fc66 lsr x6, x3, MiCode#6
154: f8667805 ldr x5, [x0, x6, lsl MiCode#3]
158: b4000061 cbz x1, 164 <_find_next_bit.constprop.1+0x4c>
15c: f8667826 ldr x6, [x1, x6, lsl MiCode#3]
160: 8a0600a5 and x5, x5, x6
164: eb05009f cmp x4, x5
168: 540000c1 b.ne 180 <_find_next_bit.constprop.1+0x68> // b.any
16c: 91010063 add x3, x3, #0x40
170: eb03005f cmp x2, x3
174: 54fffee8 b.hi 150 <_find_next_bit.constprop.1+0x38> // b.pmore
178: aa0203e0 mov x0, x2
17c: d65f03c0 ret
180: ca050085 eor x5, x4, x5
184: dac000a5 rbit x5, x5
188: dac010a5 clz x5, x5
18c: 8b0300a3 add x3, x5, x3
190: eb03005f cmp x2, x3
194: 9a839042 csel x2, x2, x3, ls // ls = plast
198: aa0203e0 mov x0, x2
19c: d65f03c0 ret
...
0000000000000238 <find_next_bit>:
238: a9bf7bfd stp x29, x30, [sp, #-16]!
23c: aa0203e3 mov x3, x2
240: d2800004 mov x4, #0x0 // #0
244: aa0103e2 mov x2, x1
248: 910003fd mov x29, sp
24c: d2800001 mov x1, #0x0 // #0
250: 97ffffb2 bl 118 <_find_next_bit.constprop.1>
254: a8c17bfd ldp x29, x30, [sp], MiCode#16
258: d65f03c0 ret
Enabling find_{first,next}_bit() would also benefit for_each_{set,clear}_bit().
On A-53 find_first_bit() is almost twice faster than find_next_bit(), according
to lib/find_bit_benchmark (thanks to Alexey for testing):
GENERIC_FIND_FIRST_BIT=n:
[7126084.948181] find_first_bit: 47389224 ns, 16357 iterations
[7126085.032315] find_first_bit: 19048193 ns, 655 iterations
GENERIC_FIND_FIRST_BIT=y:
[ 84.158068] find_first_bit: 27193319 ns, 16406 iterations
[ 84.233005] find_first_bit: 11082437 ns, 656 iterations
GENERIC_FIND_FIRST_BIT=n bloats the kernel despite that it disables generation
of find_{first,next}_bit():
yury:linux$ scripts/bloat-o-meter vmlinux vmlinux.ffb
add/remove: 4/1 grow/shrink: 19/251 up/down: 564/-1692 (-1128)
...
Overall, GENERIC_FIND_FIRST_BIT=n is harmful both in terms of performance and
code size, and it's better to have GENERIC_FIND_FIRST_BIT enabled.
Tested-by: Alexey Klimov <aklimov@redhat.com>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210225135700.1381396-2-yury.norov@gmail.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: atndko <z1281552865@gmail.com>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Change-Id: Idbea6884a499eb41bec524e583af5fd11c7600d2
YumeMichi
pushed a commit
to YumeMichi/Xiaomi_Kernel_OpenSource
that referenced
this issue
Jul 12, 2023
ARM64 doesn't implement find_first_{zero}_bit in arch code and doesn't
enable it in a config. It leads to using find_next_bit() which is less
efficient:
0000000000000000 <find_first_bit>:
0: aa0003e4 mov x4, x0
4: aa0103e0 mov x0, x1
8: b4000181 cbz x1, 38 <find_first_bit+0x38>
c: f9400083 ldr x3, [x4]
10: d2800802 mov x2, #0x40 // MiCode#64
14: 91002084 add x4, x4, #0x8
18: b40000c3 cbz x3, 30 <find_first_bit+0x30>
1c: 14000008 b 3c <find_first_bit+0x3c>
20: f8408483 ldr x3, [x4], MiCode#8
24: 91010045 add x5, x2, #0x40
28: b50000c3 cbnz x3, 40 <find_first_bit+0x40>
2c: aa0503e2 mov x2, x5
30: eb02001f cmp x0, x2
34: 54ffff68 b.hi 20 <find_first_bit+0x20> // b.pmore
38: d65f03c0 ret
3c: d2800002 mov x2, #0x0 // #0
40: dac00063 rbit x3, x3
44: dac01063 clz x3, x3
48: 8b020062 add x2, x3, x2
4c: eb02001f cmp x0, x2
50: 9a829000 csel x0, x0, x2, ls // ls = plast
54: d65f03c0 ret
...
0000000000000118 <_find_next_bit.constprop.1>:
118: eb02007f cmp x3, x2
11c: 540002e2 b.cs 178 <_find_next_bit.constprop.1+0x60> // b.hs, b.nlast
120: d346fc66 lsr x6, x3, MiCode#6
124: f8667805 ldr x5, [x0, x6, lsl MiCode#3]
128: b4000061 cbz x1, 134 <_find_next_bit.constprop.1+0x1c>
12c: f8667826 ldr x6, [x1, x6, lsl MiCode#3]
130: 8a0600a5 and x5, x5, x6
134: ca0400a6 eor x6, x5, x4
138: 92800005 mov x5, #0xffffffffffffffff // #-1
13c: 9ac320a5 lsl x5, x5, x3
140: 927ae463 and x3, x3, #0xffffffffffffffc0
144: ea0600a5 ands x5, x5, x6
148: 54000120 b.eq 16c <_find_next_bit.constprop.1+0x54> // b.none
14c: 1400000e b 184 <_find_next_bit.constprop.1+0x6c>
150: d346fc66 lsr x6, x3, MiCode#6
154: f8667805 ldr x5, [x0, x6, lsl MiCode#3]
158: b4000061 cbz x1, 164 <_find_next_bit.constprop.1+0x4c>
15c: f8667826 ldr x6, [x1, x6, lsl MiCode#3]
160: 8a0600a5 and x5, x5, x6
164: eb05009f cmp x4, x5
168: 540000c1 b.ne 180 <_find_next_bit.constprop.1+0x68> // b.any
16c: 91010063 add x3, x3, #0x40
170: eb03005f cmp x2, x3
174: 54fffee8 b.hi 150 <_find_next_bit.constprop.1+0x38> // b.pmore
178: aa0203e0 mov x0, x2
17c: d65f03c0 ret
180: ca050085 eor x5, x4, x5
184: dac000a5 rbit x5, x5
188: dac010a5 clz x5, x5
18c: 8b0300a3 add x3, x5, x3
190: eb03005f cmp x2, x3
194: 9a839042 csel x2, x2, x3, ls // ls = plast
198: aa0203e0 mov x0, x2
19c: d65f03c0 ret
...
0000000000000238 <find_next_bit>:
238: a9bf7bfd stp x29, x30, [sp, #-16]!
23c: aa0203e3 mov x3, x2
240: d2800004 mov x4, #0x0 // #0
244: aa0103e2 mov x2, x1
248: 910003fd mov x29, sp
24c: d2800001 mov x1, #0x0 // #0
250: 97ffffb2 bl 118 <_find_next_bit.constprop.1>
254: a8c17bfd ldp x29, x30, [sp], MiCode#16
258: d65f03c0 ret
Enabling find_{first,next}_bit() would also benefit for_each_{set,clear}_bit().
On A-53 find_first_bit() is almost twice faster than find_next_bit(), according
to lib/find_bit_benchmark (thanks to Alexey for testing):
GENERIC_FIND_FIRST_BIT=n:
[7126084.948181] find_first_bit: 47389224 ns, 16357 iterations
[7126085.032315] find_first_bit: 19048193 ns, 655 iterations
GENERIC_FIND_FIRST_BIT=y:
[ 84.158068] find_first_bit: 27193319 ns, 16406 iterations
[ 84.233005] find_first_bit: 11082437 ns, 656 iterations
GENERIC_FIND_FIRST_BIT=n bloats the kernel despite that it disables generation
of find_{first,next}_bit():
yury:linux$ scripts/bloat-o-meter vmlinux vmlinux.ffb
add/remove: 4/1 grow/shrink: 19/251 up/down: 564/-1692 (-1128)
...
Overall, GENERIC_FIND_FIRST_BIT=n is harmful both in terms of performance and
code size, and it's better to have GENERIC_FIND_FIRST_BIT enabled.
Tested-by: Alexey Klimov <aklimov@redhat.com>
Signed-off-by: Yury Norov <yury.norov@gmail.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210225135700.1381396-2-yury.norov@gmail.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: atndko <z1281552865@gmail.com>
Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com>
Change-Id: Idbea6884a499eb41bec524e583af5fd11c7600d2
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
Please update the source for the kernel for the Redmi Note 3 SDN(Kenzo), which has already been pushed out to devices. The newer kernel fixes fingerprint and front camera not working in AOSP based ROMs and hopefully VoLTE too. It has been 5 months since the released sources have not been updated. Xiaomi has changed the manufacturer for the fingerprint reader I think and that has caused a big problem for the community. Please help us out.
Thanks!
The text was updated successfully, but these errors were encountered: