Re: [RFC WIP PATCH] venus: add qcom,no-low-power property

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 10/04/2024 14:14, Bryan O'Donoghue wrote:
> On 10/04/2024 13:23, Marc Gonzalez wrote:
>> FWIW, I get the same behavior with 854x480 and 2560x1440:
>>
>> 1) If mpv runs with '--length=N' (play only part of the file)
>> then mpv exits cleanly, with no kernel messages.
> 
> On -next ?
> 
> I think you mentioned before you were doing your work on an older kernel 
> and forward porting patches ?
> 
>> 2) If mpv plays the entire file, then mpv hangs at the end
>> (needs CTRL-C to exit) and driver prints to kernel:
>> [68643.935888] qcom-venus cc00000.video-codec: session error: event 
>> id:1001 (deadb000), session id:79d42000
>> [68643.935995] qcom-venus-decoder cc00000.video-codec:video-decoder: 
>> dec: event : 1001
> 
> Hmm
> 
> #define HFI_ERR_SESSION_FATAL                0x1001
> 
> Something is causing the firmware to return this packet to you.
> 
> Probably worth tracing the last five messages sent by the firmware prior 
> to that to see if we can root-cause.
> 
> ---
> bod

BTW I think you've found two bugs here

1. When we receive a fatal error from firmware we don't "bug out"
    properly. So we hang forever waiting for more events which
    won't come.
    We should fix the handling of SESSION_FATAL to => termination.
    Clearly after HFI_ERR_SESSION_FATAL we should be completely done
    not hanging around waiting for additional inputs.

2. Why do we get a fatal error for the session ?
    Are we continuing to send commands to the firmware after
    termination maybe - so is there a incongruous context
    between firmware and Linux ?

I don't think either is a blocker specifically for your DTS submission 
so I think you should go ahead with your DTS stuff.

Also though, I think 1) we don't exit properly on HFI_ERR_SESSION_FATAL 
and 2) we should root-cause why HFI_ERR_SESSION_FATAL is generated at all.

---
bod