Re: [PATCH v5 5/8] clk: qcom: gcc-msm8939: mark Venus core GDSCs as hardware controlled

[Bryan O'Donoghue <bod@kernel.org>]

On 09/05/2026 13:00, Erikas Bitovtas wrote:
> across reboots, so when I reverted the patch, I was actually testing
> against decoder, not encoder.
> 
> So, the result is the same when the patch is applied, when it is
> reverted, and when testing against v1 where the cores are enabled only
> for decoding.

OK but this is testing encoding

v4l2-ctl --verbose
--set-fmt-video-out=width=1280,height=720,pixelformat=NV12
--set-selection-output target=crop,top=0,left=0,width=1280,height=720
--set-fmt-video=pixelformat=H26
4 --stream-mmap --stream-out-mmap
--stream-from=cyclists_1280x720_92frames.yuv
--stream-to=/tmp/cyclists_1280x720_92frames.h264 -d /dev/video1

I think the GDSC patch specifically isn't too much of a concern.

1. Core0 works as decoder
2. Core1 doesn't work right now.
    So what I'm trying to ask is if we could test it both
    as an encoder or as a decoder.

If decoder works when both cores are declared decoder, we know there's a 
problem with encoder and could potentially proceed with upstream decoder 
x 2.

OTOH if Core1 can't be coaxed into working in either mode, we are better 
off either holding off on this series until the breakages is root caused 
or leaving out Core1 entirely for now.

i.e. there is no utility in declaring an encoder or decoder to userspace 
that is known to be broken.

---
bod