Re: Venus probe issues on SM6350 SoC

["Luca Weiss" <luca.weiss@fairphone.com>]

Hi Bryan,

On Mon Mar 31, 2025 at 11:47 AM CEST, Bryan O'Donoghue wrote:
> On 31/03/2025 07:43, Luca Weiss wrote:
>>> Also why not turn those apss_smmu entires you have commented out back on ?
>>>
>>> https://github.com/z3ntu/linux/ 
>>> commit/281d07ae965ce0101bdb528e98bf8c00c94f86ec#diff- 
>>> ea117dfbd122406c02e5b143ee0969a3de21416b6c192e3b5ad024571f6e4bffR2016
>> As far as I can see, other SoCs only have the IOMMU that is downstream
>> non_secure_cb.
>> 
>> But unfortunately applying both changes (RETAIN_FF_ENABLE + iommus)
>> doesn't change anything, it's still the same error:
>> 
>> [   82.603202] qcom-venus aa00000.video-codec: venus_cpu_and_video_core_idle:1535 cpu_status=0 (OK 0) ctrl_status=1 (OK 0)
>> [   82.604738] qcom-venus aa00000.video-codec: venus_cpu_and_video_core_idle:1535 cpu_status=0 (OK 0) ctrl_status=1 (OK 0)
>> [   82.606263] qcom-venus aa00000.video-codec: venus_cpu_and_video_core_idle:1535 cpu_status=0 (OK 0) ctrl_status=1 (OK 0)
>> [   82.606273] qcom-venus aa00000.video-codec: venus_cpu_and_video_core_idle:1535 cpu_status=0 (OK 0) ctrl_status=1 (OK 0)
>> [   82.606280] qcom-venus aa00000.video-codec: wait for cpu and video core idle fail (-110)
>> [   82.606287] venus_probe:505 ret=-110
>> [   82.610767] venus_hfi_destroy:1690
>> [   82.610783] qcom-venus aa00000.video-codec: probe with driver qcom-venus failed with error -110
>> 
>> Also one thing I can add from my notes, what I didn't write yet. This is
>> how the register looks with msm-4.19 downstream. IIRC the values here
>> are not directly comparable because of bitmasks and stuff.
>> 
>> [   48.936285] __prepare_pc_iris2:267 DBG
>> [   48.940352] __prepare_pc_iris2:299 DBG wfi_status=0 ctrl_status=40000001
>> [   48.947624] __prepare_pc_iris2:299 DBG wfi_status=1 ctrl_status=101
>> [   48.954212] __prepare_pc_iris2:301 DBG
>> [   48.958178] __prepare_pc_iris2:314 DBG
>> 
>> Regards
>
> I wonder are all of the clocks going that are required to get the core 
> booting ?
>
> Taking a quick look I'd recommend keeping
>
> SLEEP_CLK and AHB_CLK always-on
>
> https://github.com/z3ntu/linux/blob/04f855c2b70302c9ddcd47b1fee4a2dc84fb5ba6/drivers/clk/qcom/videocc-sm6350.c#L301C1-L302C58
>
> It might be an idea to set all of the interface clocks always-on and see 
> if that makes a difference, rolling back individually if it works.
>
> - VIDEO_CC_IRIS_AHB_CLK
> - VIDEO_CC_MVS0_AXI_CLK
> - VIDEO_CC_SLEEP_CLK
> - VIDEO_CC_VENUS_AHB_CLK

How do I best do this? Adding ".flags = CLK_IS_CRITICAL," to these four
clocks make them be stuck at probe time.

[    0.459004] ------------[ cut here ]------------
[    0.459069] video_cc_mvs0_axi_clk status stuck at 'off'
[    0.459093] WARNING: CPU: 2 PID: 74 at drivers/clk/qcom/clk-branch.c:87 clk_branch_toggle+0x194/0x1ac

I guess some other clock or power domain that's required for this clock
si not on yet?

Same with
[    0.466604] video_cc_venus_ahb_clk status stuck at 'off'

But it looks like VIDEO_CC_IRIS_AHB_CLK and VIDEO_CC_SLEEP_CLK can turn
on correctly with the CRITICAL flag.

Regards
Luca


> ... and if we are going that far might as well do the whole array which 
> is small enough
>
> https://github.com/z3ntu/linux/blob/04f855c2b70302c9ddcd47b1fee4a2dc84fb5ba6/drivers/clk/qcom/videocc-sm6350.c#L293
>
> Is it possible the AHB and AXI clocks are on => read/write transactions 
> would work but one of the core-clocks is off => no boot on the remote end ?
>
> ---
> bod