Re: Re: [PATCH] arm64: dts: qcom: kodiak: Add missing clock votes for lpass_tlmm

[Val Packett <val@packett.cool>]

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 <luca.weiss@fairphone.com>
>> Tested-by: Bhushan Shah <bhushan.shah@machinesoul.in> # 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