Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The pm8916-bms-vm interrupt triggers every 50s #313

Open
aa889788 opened this issue May 16, 2023 · 5 comments
Open

The pm8916-bms-vm interrupt triggers every 50s #313

aa889788 opened this issue May 16, 2023 · 5 comments

Comments

@aa889788
Copy link

the driver set the sample interval default to 100ms, and fifo count to 2, the irq should trigger every 200ms, but it triggers about 50s each

~ # dmesg | grep pm8916
[    0.686436] genirq: Flags mismatch irq 28. 00002003 (200f000.spmi:pmic@0:extcon@1300) vs. 00002003 (pm8916_lbc)
[   51.864523] pm8916_bms_vm_fifo_update_done_irq
[  105.370233] pm8916_bms_vm_fifo_update_done_irq
[  158.875939] pm8916_bms_vm_fifo_update_done_irq
[  212.382626] pm8916_bms_vm_fifo_update_done_irq
[  265.888328] pm8916_bms_vm_fifo_update_done_irq
[  319.395013] pm8916_bms_vm_fifo_update_done_irq
[  372.900722] pm8916_bms_vm_fifo_update_done_irq
[  426.406423] pm8916_bms_vm_fifo_update_done_irq
[  479.913109] pm8916_bms_vm_fifo_update_done_irq
[  533.419793] pm8916_bms_vm_fifo_update_done_irq
[  586.925501] pm8916_bms_vm_fifo_update_done_irq
[  640.432188] pm8916_bms_vm_fifo_update_done_irq
[  693.938874] pm8916_bms_vm_fifo_update_done_irq
[  747.445552] pm8916_bms_vm_fifo_update_done_irq
[  800.951261] pm8916_bms_vm_fifo_update_done_irq
[  854.456972] pm8916_bms_vm_fifo_update_done_irq
[  907.963650] pm8916_bms_vm_fifo_update_done_irq
[  961.469359] pm8916_bms_vm_fifo_update_done_irq
[ 1014.976042] pm8916_bms_vm_fifo_update_done_irq
[ 1068.482722] pm8916_bms_vm_fifo_update_done_irq
[ 1121.989405] pm8916_bms_vm_fifo_update_done_irq
[ 1175.496094] pm8916_bms_vm_fifo_update_done_irq
[ 1229.002771] pm8916_bms_vm_fifo_update_done_irq
[ 1282.508483] pm8916_bms_vm_fifo_update_done_irq
[ 1336.015164] pm8916_bms_vm_fifo_update_done_irq
[ 1389.520873] pm8916_bms_vm_fifo_update_done_irq
[ 1443.026082] pm8916_bms_vm_fifo_update_done_irq
[ 1496.532964] pm8916_bms_vm_fifo_update_done_irq

@TravMurav

@TravMurav
Copy link
Member

This hardware block is broken in many more ways than this, I remember seeing it timing wrong but decided it works good enough in any case given we can only do so much with it.

Not like I can wave a magic wand and fix a hardware bug in all of those chips in existence anyway...

@aa889788
Copy link
Author

This hardware block is broken in many more ways than this, I remember seeing it timing wrong but decided it works good enough in any case given we can only do so much with it.

Not like I can wave a magic wand and fix a hardware bug in all of those chips in existence anyway...

I want to implement a daemon to update the bat LEDs when capacity and status(charging discharging) changed, but the bms trigger the uevent only every 50s, so is there any possibilities to trigger the bms changed event when charger online status changed?

@TravMurav
Copy link
Member

This hardware block is broken in many more ways than this, I remember seeing it timing wrong but decided it works good enough in any case given we can only do so much with it.
Not like I can wave a magic wand and fix a hardware bug in all of those chips in existence anyway...

I want to implement a daemon to update the bat LEDs when capacity and status(charging discharging) changed, but the bms trigger the uevent only every 50s, so is there any possibilities to trigger the bms changed event when charger online status changed?

For this you should track your charger, not fuel-gauge.
Also FWIW there is a led trigger that enables the led when device is charging

@aa889788
Copy link
Author

aa889788 commented May 16, 2023

This hardware block is broken in many more ways than this, I remember seeing it timing wrong but decided it works good enough in any case given we can only do so much with it.
Not like I can wave a magic wand and fix a hardware bug in all of those chips in existence anyway...

I want to implement a daemon to update the bat LEDs when capacity and status(charging discharging) changed, but the bms trigger the uevent only every 50s, so is there any possibilities to trigger the bms changed event when charger online status changed?

For this you should track your charger, not fuel-gauge.
Also FWIW there is a led trigger that enables the led when device is charging

There are 4 LEDs to show the capacity and status, no suitable triggers for it, maybe I could listen the LBC online event and read the bms/uevent to get the status

@TravMurav
Copy link
Member

This hardware block is broken in many more ways than this, I remember seeing it timing wrong but decided it works good enough in any case given we can only do so much with it.
Not like I can wave a magic wand and fix a hardware bug in all of those chips in existence anyway...

I want to implement a daemon to update the bat LEDs when capacity and status(charging discharging) changed, but the bms trigger the uevent only every 50s, so is there any possibilities to trigger the bms changed event when charger online status changed?

For this you should track your charger, not fuel-gauge.
Also FWIW there is a led trigger that enables the led when device is charging

There are 4 LEDs to show the capacity and status, no suitable triggers for it, maybe I could listen the LBC online event and read the bms/uevent to get the status

Yes, if you want to track the online status, you'd track the lbc property that should change immediately, and for the capacity you'd track the bms update event

K9100ii pushed a commit to K9100ii/msm8916-mainline-linux that referenced this issue Dec 22, 2023
We can see that "bswap32: Takes an unsigned 32-bit number in either big-
or little-endian format and returns the equivalent number with the same
bit width but opposite endianness" in BPF Instruction Set Specification,
so it should clear the upper 32 bits in "case 32:" for both BPF_ALU and
BPF_ALU64.

[root@linux fedora]# echo 1 > /proc/sys/net/core/bpf_jit_enable
[root@linux fedora]# modprobe test_bpf

Before:
test_bpf: msm8916-mainline#313 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 jited:1 ret 1460850314 != -271733879 (0x5712ce8a != 0xefcdab89)FAIL (1 times)
test_bpf: msm8916-mainline#317 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 jited:1 ret -1460850316 != 271733878 (0xa8ed3174 != 0x10325476)FAIL (1 times)

After:
test_bpf: msm8916-mainline#313 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 jited:1 4 PASS
test_bpf: msm8916-mainline#317 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 jited:1 4 PASS

Fixes: 4ebf921 ("LoongArch: BPF: Support unconditional bswap instructions")
Acked-by: Hengqi Chen <[email protected]>
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
M0Rf30 pushed a commit to M0Rf30/linux that referenced this issue Apr 13, 2024
[ Upstream commit a51cd6b ]

In case when is64 == 1 in emit(A64_REV32(is64, dst, dst), ctx) the
generated insn reverses byte order for both high and low 32-bit words,
resuling in an incorrect swap as indicated by the jit test:

[ 9757.262607] test_bpf: msm8916-mainline#312 BSWAP 16: 0x0123456789abcdef -> 0xefcd jited:1 8 PASS
[ 9757.264435] test_bpf: msm8916-mainline#313 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89 jited:1 ret 1460850314 != -271733879 (0x5712ce8a != 0xefcdab89)FAIL (1 times)
[ 9757.266260] test_bpf: msm8916-mainline#314 BSWAP 64: 0x0123456789abcdef -> 0x67452301 jited:1 8 PASS
[ 9757.268000] test_bpf: msm8916-mainline#315 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 jited:1 8 PASS
[ 9757.269686] test_bpf: msm8916-mainline#316 BSWAP 16: 0xfedcba9876543210 -> 0x1032 jited:1 8 PASS
[ 9757.271380] test_bpf: msm8916-mainline#317 BSWAP 32: 0xfedcba9876543210 -> 0x10325476 jited:1 ret -1460850316 != 271733878 (0xa8ed3174 != 0x10325476)FAIL (1 times)
[ 9757.273022] test_bpf: msm8916-mainline#318 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe jited:1 7 PASS
[ 9757.274721] test_bpf: msm8916-mainline#319 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 jited:1 9 PASS

Fix this by forcing 32bit variant of rev32.

Fixes: 1104247 ("bpf, arm64: Support unconditional bswap")
Signed-off-by: Artem Savkov <[email protected]>
Tested-by: Puranjay Mohan <[email protected]>
Acked-by: Puranjay Mohan <[email protected]>
Acked-by: Xu Kuohai <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Alexei Starovoitov <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
barni2000 pushed a commit to msm8953-mainline/linux that referenced this issue Jun 21, 2024
[ Upstream commit 8ecf3c1 ]

Recent additions in BPF like cpu v4 instructions, test_bpf module
exhibits the following failures:

  test_bpf: #82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: #83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: #84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: #85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: #86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)

  test_bpf: #165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)
  test_bpf: #166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)

  test_bpf: #169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)
  test_bpf: #170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: #172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: msm8916-mainline#313 BSWAP 16: 0x0123456789abcdef -> 0xefcd
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 301 PASS
  test_bpf: msm8916-mainline#314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 555 PASS
  test_bpf: msm8916-mainline#315 BSWAP 64: 0x0123456789abcdef -> 0x67452301
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 268 PASS
  test_bpf: msm8916-mainline#316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 269 PASS
  test_bpf: msm8916-mainline#317 BSWAP 16: 0xfedcba9876543210 -> 0x1032
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 460 PASS
  test_bpf: msm8916-mainline#318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 320 PASS
  test_bpf: msm8916-mainline#319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 222 PASS
  test_bpf: msm8916-mainline#320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 273 PASS

  test_bpf: msm8916-mainline#344 BPF_LDX_MEMSX | BPF_B
  eBPF filter opcode 0091 (@5) unsupported
  jited:0 432 PASS
  test_bpf: msm8916-mainline#345 BPF_LDX_MEMSX | BPF_H
  eBPF filter opcode 0089 (@5) unsupported
  jited:0 381 PASS
  test_bpf: msm8916-mainline#346 BPF_LDX_MEMSX | BPF_W
  eBPF filter opcode 0081 (@5) unsupported
  jited:0 505 PASS

  test_bpf: torvalds#490 JMP32_JA: Unconditional jump: if (true) return 1
  eBPF filter opcode 0006 (@1) unsupported
  jited:0 261 PASS

  test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed]

Fix them by adding missing processing.

Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions")
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants