venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

Hi,

On a mainline port of the Xiaomi 11 Lite 5G NE (sm7325-xiaomi-lisa,
SM7325 "kodiak", sc7280-compatible venus, kernel 7.1.2, postmarketOS),
the Venus decoder works fine (H264/VP9/HEVC/MPEG2 via v4l2 m2m), but
executing any encoder job instantly hard-resets the SoC below the
kernel. I've spent considerable effort narrowing this down and I
believe I've hit the limit of what can be done without wrapper/GDSC
documentation.

Reproducer (100%):

  ffmpeg -f lavfi -i testsrc2=size=176x144:rate=10 -vf format=nv12 \
    -c:v h264_v4l2m2m -b:v 100k -t 5 /tmp/e.mp4

With venus dyndbg + custom HFI tracing on UART, the full session
negotiates cleanly: SYS_INIT, SESSION_INIT (acked), all
SET_PROPERTY/SET_BUFFERS (accepted), LOAD_RESOURCES (acked), START
(acked), 4x ETB. The SoC dies the instant the first FTB is issued and
the engine starts executing — no SYS_ERROR, no EBD/FBD, no SMMU fault,
nothing from the kernel. XBL log after reboot shows "PM: Reset by
PSHOLD / Warm Reset", i.e. a TZ/secure-level reset. HEVC dies
identically (engine-level, not codec-specific).

What I've verified/excluded (all cross-checked against the downstream
yupik tree):
- memory-region (0x8b200000/0x500000), SMMU SID (0x2180/0x20), CP
ranges (cp 0x0+0x25800000, nonpixel 0x1000000+0x24800000), clock set,
GDSC offsets (0x3004/0x2004): all match downstream.
- Firmware: vendor vpu20_1v.mbn, Xiaomi-signed (Xiaomi Root CA /
Attestation CA in the cert chain), reproduced with two firmware stacks
(old and HyperOS OS2.0.8.0 coherent TZ+vpu pair). Venus hw version
6.40.a.
- Reproduced identically with the iris driver (sc7280 platform data) —
two independent implementations, same silent reset.
- Encoder scratch buffer sizes x4: no change. Runtime PM pinned: no change.

The interesting part is the power matrix around vcodec_control_v4():

1. Stock (dev_pm_genpd_set_hwmode, HW_CTRL_TRIGGER on mvs0_gdsc):
set_hwmode returns 0, engine powers up on first frame -> instant
PSHOLD reset.
2. Forced legacy path: WRAPPER_VCODEC0_MMCC_POWER_STATUS BIT(1) never
asserts (readl_poll_timeout -110, register reads 0x0). No crash — but
ignoring the timeout shows the engine never leaves clamps: session
runs to FTB, zero EBD/FBD, fw eventually non-idle ("wait for cpu and
video core idle fail").
3. GDSC forced SW-mode via genpd, or ALWAYS_ON: same as (2) — rail up,
engine clamped, no execution, no crash.
4. video_cc_xo_clk (0x7018 branch + 0x7000 RCG): missing entirely from
mainline videocc-sc7280.c, downstream marks it CLK_IS_CRITICAL. Ported
it (confirmed on at 19.2 MHz in clk_summary): no behavioral change in
any mode.
5. Dropping en_rest_wait_val/en_few_wait_val/clk_dis_wait_val from
mvs0_gdsc (keeping XBL defaults): still resets, but behavior became
nondeterministic across runs (one run showed a msg-queue response
after FTB before dying) — smells like power-ramp timing.

So: the encoder engine only actually executes when the MVS0 GDSC is
under HW control, and that execution/power-up hard-resets the SoC;
every software-controlled arrangement leaves the engine clamped (MMCC
handshake never completes). Downstream (msm-vidc + gdsc-regulator with
qcom,support-hw-trigger) uses hw-trigger on the same silicon and
encodes fine under Android, so the hardware is capable — something in
the mainline hw-trigger power-up sequencing differs fatally on kodiak.

Questions for people with wrapper/GDSC documentation:
- What does the hw-triggered MVS0 power-up require on kodiak/sc7280
beyond what mainline gdsc.c + venus do today (AON config? NoC LPI
handshake? different GDSCR sequencing)?
- Is the sm7280_reg_preset ({0xb0088, 0}) sufficient for this part, or
does downstream program additional AON/wrapper registers before
encode?

I can test patches quickly (UART attached, one-command reproducer,
full HFI traces of both healthy decode and dying encode sessions
available on request).

Thanks,
Del'aRun

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Bryan O'Donoghue]

On 20/07/2026 13:22, Kirill Ermolitskiy wrote:
> Hi,
> 
> On a mainline port of the Xiaomi 11 Lite 5G NE (sm7325-xiaomi-lisa,
> SM7325 "kodiak", sc7280-compatible venus, kernel 7.1.2, postmarketOS),
> the Venus decoder works fine (H264/VP9/HEVC/MPEG2 via v4l2 m2m), but
> executing any encoder job instantly hard-resets the SoC below the
> kernel. I've spent considerable effort narrowing this down and I
> believe I've hit the limit of what can be done without wrapper/GDSC
> documentation.
> 
> Reproducer (100%):
> 
>    ffmpeg -f lavfi -i testsrc2=size=176x144:rate=10 -vf format=nv12 \
>      -c:v h264_v4l2m2m -b:v 100k -t 5 /tmp/e.mp4
> 
> With venus dyndbg + custom HFI tracing on UART, the full session
> negotiates cleanly: SYS_INIT, SESSION_INIT (acked), all
> SET_PROPERTY/SET_BUFFERS (accepted), LOAD_RESOURCES (acked), START
> (acked), 4x ETB. The SoC dies the instant the first FTB is issued and
> the engine starts executing — no SYS_ERROR, no EBD/FBD, no SMMU fault,
> nothing from the kernel. XBL log after reboot shows "PM: Reset by
> PSHOLD / Warm Reset", i.e. a TZ/secure-level reset. HEVC dies
> identically (engine-level, not codec-specific).
> 
> What I've verified/excluded (all cross-checked against the downstream
> yupik tree):
> - memory-region (0x8b200000/0x500000), SMMU SID (0x2180/0x20), CP
> ranges (cp 0x0+0x25800000, nonpixel 0x1000000+0x24800000), clock set,
> GDSC offsets (0x3004/0x2004): all match downstream.
> - Firmware: vendor vpu20_1v.mbn, Xiaomi-signed (Xiaomi Root CA /
> Attestation CA in the cert chain), reproduced with two firmware stacks
> (old and HyperOS OS2.0.8.0 coherent TZ+vpu pair). Venus hw version
> 6.40.a.
> - Reproduced identically with the iris driver (sc7280 platform data) —
> two independent implementations, same silent reset.
> - Encoder scratch buffer sizes x4: no change. Runtime PM pinned: no change.
> 
> The interesting part is the power matrix around vcodec_control_v4():
> 
> 1. Stock (dev_pm_genpd_set_hwmode, HW_CTRL_TRIGGER on mvs0_gdsc):
> set_hwmode returns 0, engine powers up on first frame -> instant
> PSHOLD reset.
> 2. Forced legacy path: WRAPPER_VCODEC0_MMCC_POWER_STATUS BIT(1) never
> asserts (readl_poll_timeout -110, register reads 0x0). No crash — but
> ignoring the timeout shows the engine never leaves clamps: session
> runs to FTB, zero EBD/FBD, fw eventually non-idle ("wait for cpu and
> video core idle fail").
> 3. GDSC forced SW-mode via genpd, or ALWAYS_ON: same as (2) — rail up,
> engine clamped, no execution, no crash.
> 4. video_cc_xo_clk (0x7018 branch + 0x7000 RCG): missing entirely from
> mainline videocc-sc7280.c, downstream marks it CLK_IS_CRITICAL. Ported
> it (confirmed on at 19.2 MHz in clk_summary): no behavioral change in
> any mode.
> 5. Dropping en_rest_wait_val/en_few_wait_val/clk_dis_wait_val from
> mvs0_gdsc (keeping XBL defaults): still resets, but behavior became
> nondeterministic across runs (one run showed a msg-queue response
> after FTB before dying) — smells like power-ramp timing.
> 
> So: the encoder engine only actually executes when the MVS0 GDSC is
> under HW control, and that execution/power-up hard-resets the SoC;
> every software-controlled arrangement leaves the engine clamped (MMCC
> handshake never completes). Downstream (msm-vidc + gdsc-regulator with
> qcom,support-hw-trigger) uses hw-trigger on the same silicon and
> encodes fine under Android, so the hardware is capable — something in
> the mainline hw-trigger power-up sequencing differs fatally on kodiak.
> 
> Questions for people with wrapper/GDSC documentation:
> - What does the hw-triggered MVS0 power-up require on kodiak/sc7280
> beyond what mainline gdsc.c + venus do today (AON config? NoC LPI
> handshake? different GDSCR sequencing)?
> - Is the sm7280_reg_preset ({0xb0088, 0}) sufficient for this part, or
> does downstream program additional AON/wrapper registers before
> encode?
> 
> I can test patches quickly (UART attached, one-command reproducer,
> full HFI traces of both healthy decode and dying encode sessions
> available on request).
> 
> Thanks,
> Del'aRun

Quite likely to be operating point failure i.e. not ramping voltage to 
match clock.

Anyway we're doing a new kernel release so I'll try to replicate on 8250 
which is ~ the same silicon.

---
bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

Tested forcing all venus_opp_table entries to rpmhpd_opp_turbo_l1
(verified via /sys/firmware/devicetree) — encoder still hard-resets
identically at first frame. So if it's an operating-point failure,
it's not the CX vote via required-opps; possibly a different rail
(MX/MMCX?) or something the OPP framework doesn't reach on kodiak.

---
Del'aRun


пн, 20 июл. 2026 г. в 16:55, Bryan O'Donoghue <bod@kernel.org>:
>
> On 20/07/2026 13:22, Kirill Ermolitskiy wrote:
> > Hi,
> >
> > On a mainline port of the Xiaomi 11 Lite 5G NE (sm7325-xiaomi-lisa,
> > SM7325 "kodiak", sc7280-compatible venus, kernel 7.1.2, postmarketOS),
> > the Venus decoder works fine (H264/VP9/HEVC/MPEG2 via v4l2 m2m), but
> > executing any encoder job instantly hard-resets the SoC below the
> > kernel. I've spent considerable effort narrowing this down and I
> > believe I've hit the limit of what can be done without wrapper/GDSC
> > documentation.
> >
> > Reproducer (100%):
> >
> >    ffmpeg -f lavfi -i testsrc2=size=176x144:rate=10 -vf format=nv12 \
> >      -c:v h264_v4l2m2m -b:v 100k -t 5 /tmp/e.mp4
> >
> > With venus dyndbg + custom HFI tracing on UART, the full session
> > negotiates cleanly: SYS_INIT, SESSION_INIT (acked), all
> > SET_PROPERTY/SET_BUFFERS (accepted), LOAD_RESOURCES (acked), START
> > (acked), 4x ETB. The SoC dies the instant the first FTB is issued and
> > the engine starts executing — no SYS_ERROR, no EBD/FBD, no SMMU fault,
> > nothing from the kernel. XBL log after reboot shows "PM: Reset by
> > PSHOLD / Warm Reset", i.e. a TZ/secure-level reset. HEVC dies
> > identically (engine-level, not codec-specific).
> >
> > What I've verified/excluded (all cross-checked against the downstream
> > yupik tree):
> > - memory-region (0x8b200000/0x500000), SMMU SID (0x2180/0x20), CP
> > ranges (cp 0x0+0x25800000, nonpixel 0x1000000+0x24800000), clock set,
> > GDSC offsets (0x3004/0x2004): all match downstream.
> > - Firmware: vendor vpu20_1v.mbn, Xiaomi-signed (Xiaomi Root CA /
> > Attestation CA in the cert chain), reproduced with two firmware stacks
> > (old and HyperOS OS2.0.8.0 coherent TZ+vpu pair). Venus hw version
> > 6.40.a.
> > - Reproduced identically with the iris driver (sc7280 platform data) —
> > two independent implementations, same silent reset.
> > - Encoder scratch buffer sizes x4: no change. Runtime PM pinned: no change.
> >
> > The interesting part is the power matrix around vcodec_control_v4():
> >
> > 1. Stock (dev_pm_genpd_set_hwmode, HW_CTRL_TRIGGER on mvs0_gdsc):
> > set_hwmode returns 0, engine powers up on first frame -> instant
> > PSHOLD reset.
> > 2. Forced legacy path: WRAPPER_VCODEC0_MMCC_POWER_STATUS BIT(1) never
> > asserts (readl_poll_timeout -110, register reads 0x0). No crash — but
> > ignoring the timeout shows the engine never leaves clamps: session
> > runs to FTB, zero EBD/FBD, fw eventually non-idle ("wait for cpu and
> > video core idle fail").
> > 3. GDSC forced SW-mode via genpd, or ALWAYS_ON: same as (2) — rail up,
> > engine clamped, no execution, no crash.
> > 4. video_cc_xo_clk (0x7018 branch + 0x7000 RCG): missing entirely from
> > mainline videocc-sc7280.c, downstream marks it CLK_IS_CRITICAL. Ported
> > it (confirmed on at 19.2 MHz in clk_summary): no behavioral change in
> > any mode.
> > 5. Dropping en_rest_wait_val/en_few_wait_val/clk_dis_wait_val from
> > mvs0_gdsc (keeping XBL defaults): still resets, but behavior became
> > nondeterministic across runs (one run showed a msg-queue response
> > after FTB before dying) — smells like power-ramp timing.
> >
> > So: the encoder engine only actually executes when the MVS0 GDSC is
> > under HW control, and that execution/power-up hard-resets the SoC;
> > every software-controlled arrangement leaves the engine clamped (MMCC
> > handshake never completes). Downstream (msm-vidc + gdsc-regulator with
> > qcom,support-hw-trigger) uses hw-trigger on the same silicon and
> > encodes fine under Android, so the hardware is capable — something in
> > the mainline hw-trigger power-up sequencing differs fatally on kodiak.
> >
> > Questions for people with wrapper/GDSC documentation:
> > - What does the hw-triggered MVS0 power-up require on kodiak/sc7280
> > beyond what mainline gdsc.c + venus do today (AON config? NoC LPI
> > handshake? different GDSCR sequencing)?
> > - Is the sm7280_reg_preset ({0xb0088, 0}) sufficient for this part, or
> > does downstream program additional AON/wrapper registers before
> > encode?
> >
> > I can test patches quickly (UART attached, one-command reproducer,
> > full HFI traces of both healthy decode and dying encode sessions
> > available on request).
> >
> > Thanks,
> > Del'aRun
>
> Quite likely to be operating point failure i.e. not ramping voltage to
> match clock.
>
> Anyway we're doing a new kernel release so I'll try to replicate on 8250
> which is ~ the same silicon.
>
> ---
> bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Bryan O'Donoghue]

On 20/07/2026 17:28, Kirill Ermolitskiy wrote:
> Tested forcing all venus_opp_table entries to rpmhpd_opp_turbo_l1
> (verified via /sys/firmware/devicetree) — encoder still hard-resets
> identically at first frame. So if it's an operating-point failure,
> it's not the CX vote via required-opps; possibly a different rail
> (MX/MMCX?) or something the OPP framework doesn't reach on kodiak.
> 
> ---
> Del'aRun

In which case let's try constraining the pixel and non-pixel IOVAs.

Give this a go

https://patch.msgid.link/20260601041336.9497-2-daniel@quora.org

* Adapted to the appropriate dtsi obvs.

---
bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

Adapted Daniel's patch to kodiak: added the reserved-memory node with
iommu-addresses covering [0, 0x25800000) for &venus plus a second
memory-region entry. Since downstream yupik's non-secure pool is exactly
0x25800000-0xe0000000 and venus runs with a 32-bit DMA mask (top-down
allocations land above 0xe0000000), I additionally reserved
[0xe0000000, 4GiB). Both reservations confirmed via the iommu group's
reserved_regions:

0x0000000000000000 0x00000000257fffff reserved
0x00000000e0000000 0x00000000ffffffff reserved

Encoder still hard-resets identically at the first FTB. So on kodiak it
doesn't look like an IOVA-window/SID issue — or at least not only that.

One more finding from diffing against downstream: mainline's
sm7280_reg_preset zeroes the whole of 0xb0088 (AON region), while
downstream applies it with mask 0x11, preserving the remaining bits. On
this device the register holds 0x3 at core boot, so mainline does
clobber a live bit. Preserving it (read-modify-write with downstream's
mask) doesn't change the encoder outcome, but it's probably worth fixing
regardless — same for video_cc_xo_clk, which downstream marks
CLK_IS_CRITICAL and mainline videocc-sc7280 doesn't register at all
(ported it, confirmed running at 19.2 MHz; no behavioral change either).

That exhausts what I can usefully test blind: DT constants (fw region,
SMMU SID, CP ranges, clocks, GDSC offsets — all match downstream), power
sequencing (hwmode / forced SW / GDSC always-on / legacy MMCC handshake /
GDSC wait values), XO clock, max CX votes via required-opps, IOVA
windows, two firmware stacks (old and coherent OS2.0.8.0 TZ+vpu pair),
and both venus and iris — every variant that actually executes the
encode engine resets the SoC at the first frame, silently, below the
kernel (PSHOLD warm reset). Full two-sided HFI traces of healthy decode
and dying encode sessions available; happy to test patches on hardware.

пн, 20 июл. 2026 г. в 23:36, Bryan O'Donoghue <bod@kernel.org>:
>
> On 20/07/2026 17:28, Kirill Ermolitskiy wrote:
> > Tested forcing all venus_opp_table entries to rpmhpd_opp_turbo_l1
> > (verified via /sys/firmware/devicetree) — encoder still hard-resets
> > identically at first frame. So if it's an operating-point failure,
> > it's not the CX vote via required-opps; possibly a different rail
> > (MX/MMCX?) or something the OPP framework doesn't reach on kodiak.
> >
> > ---
> > Del'aRun
>
> In which case let's try constraining the pixel and non-pixel IOVAs.
>
> Give this a go
>
> https://patch.msgid.link/20260601041336.9497-2-daniel@quora.org
>
> * Adapted to the appropriate dtsi obvs.
>
> ---
> bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Bryan O'Donoghue]

On 20/07/2026 21:41, Kirill Ermolitskiy wrote:
> Adapted Daniel's patch to kodiak: added the reserved-memory node with
> iommu-addresses covering [0, 0x25800000) for &venus plus a second
> memory-region entry. Since downstream yupik's non-secure pool is exactly
> 0x25800000-0xe0000000 and venus runs with a 32-bit DMA mask (top-down
> allocations land above 0xe0000000), I additionally reserved
> [0xe0000000, 4GiB). Both reservations confirmed via the iommu group's
> reserved_regions:
> 
> 0x0000000000000000 0x00000000257fffff reserved
> 0x00000000e0000000 0x00000000ffffffff reserved
> 
> Encoder still hard-resets identically at the first FTB. So on kodiak it
> doesn't look like an IOVA-window/SID issue — or at least not only that.
> 
> One more finding from diffing against downstream: mainline's
> sm7280_reg_preset zeroes the whole of 0xb0088 (AON region), while
> downstream applies it with mask 0x11, preserving the remaining bits. On
> this device the register holds 0x3 at core boot, so mainline does
> clobber a live bit. Preserving it (read-modify-write with downstream's
> mask) doesn't change the encoder outcome, but it's probably worth fixing
> regardless — same for video_cc_xo_clk, which downstream marks
> CLK_IS_CRITICAL and mainline videocc-sc7280 doesn't register at all
> (ported it, confirmed running at 19.2 MHz; no behavioral change either).
> 
> That exhausts what I can usefully test blind: DT constants (fw region,
> SMMU SID, CP ranges, clocks, GDSC offsets — all match downstream), power
> sequencing (hwmode / forced SW / GDSC always-on / legacy MMCC handshake /
> GDSC wait values), XO clock, max CX votes via required-opps, IOVA
> windows, two firmware stacks (old and coherent OS2.0.8.0 TZ+vpu pair),
> and both venus and iris — every variant that actually executes the
> encode engine resets the SoC at the first frame, silently, below the
> kernel (PSHOLD warm reset). Full two-sided HFI traces of healthy decode
> and dying encode sessions available; happy to test patches on hardware.

Eh it's not clear to me if you are running the venus or iris driver. 
Both are supported - can you flip the switch in your defconfig ?

Perhaps you are testing both already - if not please try the other driver.

---
bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

Primary testing was on venus (CONFIG_VIDEO_QCOM_VENUS, confirmed via the
device's driver symlink). I did test iris once earlier — identical
silent reset at first encode frame — but that predates the IOVA
reservations and the video_cc_xo_clk port, so I'm rebuilding with
CONFIG_VIDEO_QCOM_IRIS right now to re-verify iris with all current
fixes in place. Will report back shortly.

---
Del'aRun

вт, 21 июл. 2026 г. в 01:31, Bryan O'Donoghue <bod@kernel.org>:
>
> On 20/07/2026 21:41, Kirill Ermolitskiy wrote:
> > Adapted Daniel's patch to kodiak: added the reserved-memory node with
> > iommu-addresses covering [0, 0x25800000) for &venus plus a second
> > memory-region entry. Since downstream yupik's non-secure pool is exactly
> > 0x25800000-0xe0000000 and venus runs with a 32-bit DMA mask (top-down
> > allocations land above 0xe0000000), I additionally reserved
> > [0xe0000000, 4GiB). Both reservations confirmed via the iommu group's
> > reserved_regions:
> >
> > 0x0000000000000000 0x00000000257fffff reserved
> > 0x00000000e0000000 0x00000000ffffffff reserved
> >
> > Encoder still hard-resets identically at the first FTB. So on kodiak it
> > doesn't look like an IOVA-window/SID issue — or at least not only that.
> >
> > One more finding from diffing against downstream: mainline's
> > sm7280_reg_preset zeroes the whole of 0xb0088 (AON region), while
> > downstream applies it with mask 0x11, preserving the remaining bits. On
> > this device the register holds 0x3 at core boot, so mainline does
> > clobber a live bit. Preserving it (read-modify-write with downstream's
> > mask) doesn't change the encoder outcome, but it's probably worth fixing
> > regardless — same for video_cc_xo_clk, which downstream marks
> > CLK_IS_CRITICAL and mainline videocc-sc7280 doesn't register at all
> > (ported it, confirmed running at 19.2 MHz; no behavioral change either).
> >
> > That exhausts what I can usefully test blind: DT constants (fw region,
> > SMMU SID, CP ranges, clocks, GDSC offsets — all match downstream), power
> > sequencing (hwmode / forced SW / GDSC always-on / legacy MMCC handshake /
> > GDSC wait values), XO clock, max CX votes via required-opps, IOVA
> > windows, two firmware stacks (old and coherent OS2.0.8.0 TZ+vpu pair),
> > and both venus and iris — every variant that actually executes the
> > encode engine resets the SoC at the first frame, silently, below the
> > kernel (PSHOLD warm reset). Full two-sided HFI traces of healthy decode
> > and dying encode sessions available; happy to test patches on hardware.
>
> Eh it's not clear to me if you are running the venus or iris driver.
> Both are supported - can you flip the switch in your defconfig ?
>
> Perhaps you are testing both already - if not please try the other driver.
>
> ---
> bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

Re-verified with iris (CONFIG_VIDEO_QCOM_IRIS, venus disabled; ffmpeg
confirms 'iris_driver' on card 'Iris Encoder'), this time with all
current fixes in place — the IOVA reservations and video_cc_xo_clk apply
regardless of driver since they live in DT/videocc. Identical result:
silent PSHOLD reset at the first encode frame.

So that's now confirmed twice across both drivers, with and without the
accumulated fixes. Decode works fine on both; only encode execution is
fatal. Ready to test whatever you'd like to try next once you've had a
go on 8250.

---
Del'aRun

вт, 21 июл. 2026 г. в 01:38, Kirill Ermolitskiy <00vopoj00@gmail.com>:
>
> Primary testing was on venus (CONFIG_VIDEO_QCOM_VENUS, confirmed via the
> device's driver symlink). I did test iris once earlier — identical
> silent reset at first encode frame — but that predates the IOVA
> reservations and the video_cc_xo_clk port, so I'm rebuilding with
> CONFIG_VIDEO_QCOM_IRIS right now to re-verify iris with all current
> fixes in place. Will report back shortly.
>
> ---
> Del'aRun
>
> вт, 21 июл. 2026 г. в 01:31, Bryan O'Donoghue <bod@kernel.org>:
> >
> > On 20/07/2026 21:41, Kirill Ermolitskiy wrote:
> > > Adapted Daniel's patch to kodiak: added the reserved-memory node with
> > > iommu-addresses covering [0, 0x25800000) for &venus plus a second
> > > memory-region entry. Since downstream yupik's non-secure pool is exactly
> > > 0x25800000-0xe0000000 and venus runs with a 32-bit DMA mask (top-down
> > > allocations land above 0xe0000000), I additionally reserved
> > > [0xe0000000, 4GiB). Both reservations confirmed via the iommu group's
> > > reserved_regions:
> > >
> > > 0x0000000000000000 0x00000000257fffff reserved
> > > 0x00000000e0000000 0x00000000ffffffff reserved
> > >
> > > Encoder still hard-resets identically at the first FTB. So on kodiak it
> > > doesn't look like an IOVA-window/SID issue — or at least not only that.
> > >
> > > One more finding from diffing against downstream: mainline's
> > > sm7280_reg_preset zeroes the whole of 0xb0088 (AON region), while
> > > downstream applies it with mask 0x11, preserving the remaining bits. On
> > > this device the register holds 0x3 at core boot, so mainline does
> > > clobber a live bit. Preserving it (read-modify-write with downstream's
> > > mask) doesn't change the encoder outcome, but it's probably worth fixing
> > > regardless — same for video_cc_xo_clk, which downstream marks
> > > CLK_IS_CRITICAL and mainline videocc-sc7280 doesn't register at all
> > > (ported it, confirmed running at 19.2 MHz; no behavioral change either).
> > >
> > > That exhausts what I can usefully test blind: DT constants (fw region,
> > > SMMU SID, CP ranges, clocks, GDSC offsets — all match downstream), power
> > > sequencing (hwmode / forced SW / GDSC always-on / legacy MMCC handshake /
> > > GDSC wait values), XO clock, max CX votes via required-opps, IOVA
> > > windows, two firmware stacks (old and coherent OS2.0.8.0 TZ+vpu pair),
> > > and both venus and iris — every variant that actually executes the
> > > encode engine resets the SoC at the first frame, silently, below the
> > > kernel (PSHOLD warm reset). Full two-sided HFI traces of healthy decode
> > > and dying encode sessions available; happy to test patches on hardware.
> >
> > Eh it's not clear to me if you are running the venus or iris driver.
> > Both are supported - can you flip the switch in your defconfig ?
> >
> > Perhaps you are testing both already - if not please try the other driver.
> >
> > ---
> > bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Dmitry Baryshkov]

On Tue, Jul 21, 2026 at 01:48:17AM +0400, Kirill Ermolitskiy wrote:
> Re-verified with iris (CONFIG_VIDEO_QCOM_IRIS, venus disabled; ffmpeg
> confirms 'iris_driver' on card 'Iris Encoder'), this time with all
> current fixes in place — the IOVA reservations and video_cc_xo_clk apply
> regardless of driver since they live in DT/videocc. Identical result:
> silent PSHOLD reset at the first encode frame.
> 
> So that's now confirmed twice across both drivers, with and without the
> accumulated fixes. Decode works fine on both; only encode execution is
> fatal. Ready to test whatever you'd like to try next once you've had a
> go on 8250.

This sounds like the issue which was hit on the QCM2290 because of the
lack of secure context support...

-- 
With best wishes
Dmitry

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

That fits the data here well. Downstream yupik-vidc describes four
context banks for the video core:

non_secure_cb: iommus = <&apps_smmu 0x2180 0x0020>;
secure_bitstream_cb: iommus = <&apps_smmu 0x2181 0x0004>; (secure)
secure_pixel_cb: iommus = <&apps_smmu 0x2183 0x0000>; (secure)
secure_non_pixel_cb: iommus = <&apps_smmu 0x2184 0x0020>; (secure)

Mainline programs only the non-secure one (0x2180/0x20, which matches
what's in kodiak.dtsi). The three secure banks are TZ-managed downstream
and mainline never asks TZ to set them up — there's simply no call for
it. If the encode engine emits transactions on those secure SIDs
regardless of session type (in line with the SID-selection-by-IOVA-window
behavior Vikash described for iris), an unconfigured secure SID on this
vendor TZ would explain the silent PSHOLD precisely — and why decode,
which stays on the non-secure SID, works fine.

For the record, the one TZ call mainline does make —
qcom_scm_mem_protect_video_var() — returns 0 on this device (verified
with instrumentation), so the CP ranges themselves are programmed
successfully; the secure CBs are just never requested.

Could you point me to the QCM2290 discussion/fix? I'm curious whether it
was worked around (and how, e.g. an additional scm call to configure the
secure banks), or whether it ended up as a hard limitation of that TZ.

---
Del'aRun

вт, 21 июл. 2026 г. в 02:01, Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com>:
>
> On Tue, Jul 21, 2026 at 01:48:17AM +0400, Kirill Ermolitskiy wrote:
> > Re-verified with iris (CONFIG_VIDEO_QCOM_IRIS, venus disabled; ffmpeg
> > confirms 'iris_driver' on card 'Iris Encoder'), this time with all
> > current fixes in place — the IOVA reservations and video_cc_xo_clk apply
> > regardless of driver since they live in DT/videocc. Identical result:
> > silent PSHOLD reset at the first encode frame.
> >
> > So that's now confirmed twice across both drivers, with and without the
> > accumulated fixes. Decode works fine on both; only encode execution is
> > fatal. Ready to test whatever you'd like to try next once you've had a
> > go on 8250.
>
> This sounds like the issue which was hit on the QCM2290 because of the
> lack of secure context support...
>
> --
> With best wishes
> Dmitry

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Bryan O'Donoghue]

On 21/07/2026 00:03, Kirill Ermolitskiy wrote:
> non_secure_cb: iommus = <&apps_smmu 0x2180 0x0020>;
> secure_bitstream_cb: iommus = <&apps_smmu 0x2181 0x0004>; (secure)
> secure_pixel_cb: iommus = <&apps_smmu 0x2183 0x0000>; (secure)
> secure_non_pixel_cb: iommus = <&apps_smmu 0x2184 0x0020>; (secure)
> 
> Mainline programs only the non-secure one (0x2180/0x20, which matches
> what's in kodiak.dtsi). The three secure banks are TZ-managed downstream
> and mainline never asks TZ to set them up — there's simply no call for
> it. If the encode engine emits transactions on those secure SIDs
> regardless of session type (in line with the SID-selection-by-IOVA-window
> behavior Vikash described for iris), an unconfigured secure SID on this
> vendor TZ would explain the silent PSHOLD precisely — and why decode,
> which stays on the non-secure SID, works fine.

As I understand the defintion of the IOVA bug, when the IOVA is below a 
600MB threshold the unexpected SID is generated by the firmware.

It sounds like 600MB isn't the right address fulcrum on this platform.

---
bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

Both follow-up experiments done:

(a) Pinned allocations into a narrow window right above 600MB
([0x25800000, 0x30000000)) — identical reset at first encode frame.
Together with the earlier runs that's three tested positions across the
legal window (bottom, just under 0xe0000000, just under 4GiB), all
fatal, so there's no address fulcrum to be found here.

(b) Mapped the downstream "secure" SIDs (0x2181/0x4, 0x2183/0x0,
0x2184/0x20) into the non-secure context via the iommus property. The
system boots fine and decode works with those SMRs in place — encode
still resets identically.

So the fatal access doesn't appear to be SMMU-translated DMA at all:
neither buffer placement nor stream mapping changes anything. That
leaves firmware-side access to a TZ-protected resource during encode
execution — consistent with Dmitry's QCM2290 parallel. Vikash, Dikshita:
does the vpu20 firmware lineage require TZ-side secure context/CB setup
for encode on this family, and is there an interface HLOS is expected to
call that mainline doesn't?

---
Del'aRun


вт, 21 июл. 2026 г. в 03:23, Bryan O'Donoghue <bod@kernel.org>:

>
> On 21/07/2026 00:03, Kirill Ermolitskiy wrote:
> > non_secure_cb: iommus = <&apps_smmu 0x2180 0x0020>;
> > secure_bitstream_cb: iommus = <&apps_smmu 0x2181 0x0004>; (secure)
> > secure_pixel_cb: iommus = <&apps_smmu 0x2183 0x0000>; (secure)
> > secure_non_pixel_cb: iommus = <&apps_smmu 0x2184 0x0020>; (secure)
> >
> > Mainline programs only the non-secure one (0x2180/0x20, which matches
> > what's in kodiak.dtsi). The three secure banks are TZ-managed downstream
> > and mainline never asks TZ to set them up — there's simply no call for
> > it. If the encode engine emits transactions on those secure SIDs
> > regardless of session type (in line with the SID-selection-by-IOVA-window
> > behavior Vikash described for iris), an unconfigured secure SID on this
> > vendor TZ would explain the silent PSHOLD precisely — and why decode,
> > which stays on the non-secure SID, works fine.
>
> As I understand the defintion of the IOVA bug, when the IOVA is below a
> 600MB threshold the unexpected SID is generated by the firmware.
>
> It sounds like 600MB isn't the right address fulcrum on this platform.
>
> ---
> bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Vikash Garodia]

Hello,

On 7/21/2026 2:07 PM, Kirill Ermolitskiy wrote:
> Both follow-up experiments done:
> 
> (a) Pinned allocations into a narrow window right above 600MB
> ([0x25800000, 0x30000000)) — identical reset at first encode frame.
> Together with the earlier runs that's three tested positions across the
> legal window (bottom, just under 0xe0000000, just under 4GiB), all
> fatal, so there's no address fulcrum to be found here.
> 
> (b) Mapped the downstream "secure" SIDs (0x2181/0x4, 0x2183/0x0,
> 0x2184/0x20) into the non-secure context via the iommus property. The
> system boots fine and decode works with those SMRs in place — encode
> still resets identically.
> 
> So the fatal access doesn't appear to be SMMU-translated DMA at all:
> neither buffer placement nor stream mapping changes anything. That
> leaves firmware-side access to a TZ-protected resource during encode
> execution — consistent with Dmitry's QCM2290 parallel. Vikash, Dikshita:
> does the vpu20 firmware lineage require TZ-side secure context/CB setup
> for encode on this family, and is there an interface HLOS is expected to
> call that mainline doesn't?
> 

Could you please try one experiment to write this register 
unconditionally i.e remove the IF(..) condition ?

https://github.com/torvalds/linux/blob/b95f03f04d475aa6719d15a636ddf32222d55657/drivers/media/platform/qcom/venus/firmware.c#L205

Regards,
Vikash

> ---
> Del'aRun
> 
> 
> вт, 21 июл. 2026 г. в 03:23, Bryan O'Donoghue <bod@kernel.org>:
> 
>>
>> On 21/07/2026 00:03, Kirill Ermolitskiy wrote:
>>> non_secure_cb: iommus = <&apps_smmu 0x2180 0x0020>;
>>> secure_bitstream_cb: iommus = <&apps_smmu 0x2181 0x0004>; (secure)
>>> secure_pixel_cb: iommus = <&apps_smmu 0x2183 0x0000>; (secure)
>>> secure_non_pixel_cb: iommus = <&apps_smmu 0x2184 0x0020>; (secure)
>>>
>>> Mainline programs only the non-secure one (0x2180/0x20, which matches
>>> what's in kodiak.dtsi). The three secure banks are TZ-managed downstream
>>> and mainline never asks TZ to set them up — there's simply no call for
>>> it. If the encode engine emits transactions on those secure SIDs
>>> regardless of session type (in line with the SID-selection-by-IOVA-window
>>> behavior Vikash described for iris), an unconfigured secure SID on this
>>> vendor TZ would explain the silent PSHOLD precisely — and why decode,
>>> which stays on the non-secure SID, works fine.
>>
>> As I understand the defintion of the IOVA bug, when the IOVA is below a
>> 600MB threshold the unexpected SID is generated by the firmware.
>>
>> It sounds like 600MB isn't the right address fulcrum on this platform.
>>
>> ---
>> bod

Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight

[Kirill Ermolitskiy]

Confirmed — the unconditional CPU_CS_VCICMD_ARP_OFF write fixes encode
completely. 176x144 runs at 53x realtime; v4l2-ctl streams a valid
1280x720 (aligned to 736) H.264 bitstream through the encoder; decode
unaffected; sessions restart cleanly; dmesg clean throughout. No more
resets.
Separately, kodiak looks like it also
wants the hamoa-style IOVA reservation in dtsi — I can send that on its
own.

---
Del'aRun

вт, 21 июл. 2026 г. в 15:14, Vikash Garodia <vikash.garodia@oss.qualcomm.com>:
>
> Hello,
>
> On 7/21/2026 2:07 PM, Kirill Ermolitskiy wrote:
> > Both follow-up experiments done:
> >
> > (a) Pinned allocations into a narrow window right above 600MB
> > ([0x25800000, 0x30000000)) — identical reset at first encode frame.
> > Together with the earlier runs that's three tested positions across the
> > legal window (bottom, just under 0xe0000000, just under 4GiB), all
> > fatal, so there's no address fulcrum to be found here.
> >
> > (b) Mapped the downstream "secure" SIDs (0x2181/0x4, 0x2183/0x0,
> > 0x2184/0x20) into the non-secure context via the iommus property. The
> > system boots fine and decode works with those SMRs in place — encode
> > still resets identically.
> >
> > So the fatal access doesn't appear to be SMMU-translated DMA at all:
> > neither buffer placement nor stream mapping changes anything. That
> > leaves firmware-side access to a TZ-protected resource during encode
> > execution — consistent with Dmitry's QCM2290 parallel. Vikash, Dikshita:
> > does the vpu20 firmware lineage require TZ-side secure context/CB setup
> > for encode on this family, and is there an interface HLOS is expected to
> > call that mainline doesn't?
> >
>
> Could you please try one experiment to write this register
> unconditionally i.e remove the IF(..) condition ?
>
> https://github.com/torvalds/linux/blob/b95f03f04d475aa6719d15a636ddf32222d55657/drivers/media/platform/qcom/venus/firmware.c#L205
>
> Regards,
> Vikash
>
> > ---
> > Del'aRun
> >
> >
> > вт, 21 июл. 2026 г. в 03:23, Bryan O'Donoghue <bod@kernel.org>:
> >
> >>
> >> On 21/07/2026 00:03, Kirill Ermolitskiy wrote:
> >>> non_secure_cb: iommus = <&apps_smmu 0x2180 0x0020>;
> >>> secure_bitstream_cb: iommus = <&apps_smmu 0x2181 0x0004>; (secure)
> >>> secure_pixel_cb: iommus = <&apps_smmu 0x2183 0x0000>; (secure)
> >>> secure_non_pixel_cb: iommus = <&apps_smmu 0x2184 0x0020>; (secure)
> >>>
> >>> Mainline programs only the non-secure one (0x2180/0x20, which matches
> >>> what's in kodiak.dtsi). The three secure banks are TZ-managed downstream
> >>> and mainline never asks TZ to set them up — there's simply no call for
> >>> it. If the encode engine emits transactions on those secure SIDs
> >>> regardless of session type (in line with the SID-selection-by-IOVA-window
> >>> behavior Vikash described for iris), an unconfigured secure SID on this
> >>> vendor TZ would explain the silent PSHOLD precisely — and why decode,
> >>> which stays on the non-secure SID, works fine.
> >>
> >> As I understand the defintion of the IOVA bug, when the IOVA is below a
> >> 600MB threshold the unexpected SID is generated by the firmware.
> >>
> >> It sounds like 600MB isn't the right address fulcrum on this platform.
> >>
> >> ---
> >> bod
>