On 1/20/26 7:53 AM, Bhushan Shah wrote:
On Friday, 9 January 2026 21:08:32 IST Bhushan Shah wrote:
On Friday, 9 January 2026 20:44:34 IST Luca Weiss wrote:
Without the correct clock votes set, we may be hitting a synchronous
external abort error when touching the lpi registers.
Internal error: synchronous external abort: 0000000096000010 [#1] SMP
<...>
Call trace:
lpi_gpio_read.isra.0+0x2c/0x58 (P)
pinmux_enable_setting+0x218/0x300
pinctrl_commit_state+0xb0/0x280
pinctrl_select_state+0x28/0x48
pinctrl_bind_pins+0x1f4/0x2a0
really_probe+0x64/0x3a8
Add the clocks to fix that.
Platforms with this SoC using AudioReach won't be impacted due to
qcs6490-audioreach.dtsi already setting clocks & clock-names for
q6prmcc. The sc7280-chrome-common.dtsi has also been adjusted to keep
the behavior the same as they also do not use Elite with q6afecc.
Signed-off-by: Luca Weiss <[email protected]>
Tested-by: Bhushan Shah <[email protected]> # On fairphone-fp5
As a follow-up;
While this fixes original abort, it seems on some coldboots or as such(?); it
fails
to vote the clocks and then eventually soundcard fails to probe, so there is
still
some issue that needs to be solved.
[ 17.944296] Bluetooth: hci0: Frame reassembly failed (-84)
[ 20.961100] qcom-q6afe aprsvc:service:4:4: AFE failed to vote (3)
[ 20.961131] Failed to prepare clk 'core': -110
[ 20.961137] qcom-sc7280-lpass-lpi-pinctrl 33c0000.pinctrl: error -ETIMEDOUT:
Can't enable clocks
[ 20.961144] qcom-sc7280-lpass-lpi-pinctrl 33c0000.pinctrl: probe with driver
qcom-sc7280-lpass-lpi-pinctrl failed with error -110
So far I was not able to find a precise pattern to this, but doing bunch of
coldboots
is most easiest way to reproduce I have found.
This issue has appeared for a fellow postmarketOS user in the audio
chatroom on the sm8250-xiaomi-pipa, the most interesting thing is the
error code that was returned:
[ 10.823380] PDR: Indication received from msm/adsp/audio_pd, state:
0x1fffffff, trans-id: 1
[ 10.823413] qcom,apr
17300000.remoteproc:glink-edge.apr_audio_svc.-1.-1: Adding APR/GPR dev:
aprsvc:service:4:3
[ 10.823476] qcom,apr
17300000.remoteproc:glink-edge.apr_audio_svc.-1.-1: Adding APR/GPR dev:
aprsvc:service:4:4
[ 10.825541] qcom,apr
17300000.remoteproc:glink-edge.apr_audio_svc.-1.-1: Adding APR/GPR dev:
aprsvc:service:4:7
[ 10.826034] platform 17300000.remoteproc:glink-edge:apr:service@7:dais:
Adding to iommu group 28
[ 10.826399] qcom,apr
17300000.remoteproc:glink-edge.apr_audio_svc.-1.-1: Adding APR/GPR dev:
aprsvc:service:4:8
[ 10.827469] qcom-q6afe aprsvc:service:4:4: cmd = 0x100f4 returned error
= 0x16
[ 10.827512] qcom-q6afe aprsvc:service:4:4: Unknown cmd 0x100f4
…
[ 14.052896] qcom-q6afe aprsvc:service:4:4: AFE failed to vote (3)
[ 14.052934] va_macro 3370000.codec: probe with driver va_macro failed
with error -110
Uhh, 0x16 is out of the known range of error codes!
q6dsp-errno.h both upstream and downstream ends at 0x15! Wat?!
(Also the "Unknown cmd" error message is confusing, it makes it seem
like the ADSP had told us that it doesn't know the cmd, but in reality
the *error handler* hit a path where it's an unknown opcode for its
processing of the response!)
Thanks,
~val
