From: Bryan O'Donoghue <bod@kernel.org>
To: Kirill Ermolitskiy <00vopoj00@gmail.com>
Cc: linux-media@vger.kernel.org, vikash.garodia@oss.qualcomm.com,
dikshita.agarwal@oss.qualcomm.com, linux-arm-msm@vger.kernel.org
Subject: Re: venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight
Date: Mon, 20 Jul 2026 22:31:00 +0100 [thread overview]
Message-ID: <1bc74fac-859b-46fd-91ef-16c40c8f9a7f@kernel.org> (raw)
In-Reply-To: <CADRRrN35SjSPqYH+kUowf3RCcKgnGqVQAKTd73vqMLgdz1q5AQ@mail.gmail.com>
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
next prev parent reply other threads:[~2026-07-20 21:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <MOR1FYP_9xkM8GfpziB5D4Q3H5XLHq6MowZkeFMhI_49wkvgOVxXHbtJYMHHnToR_DOz2HU3N102cMMRPNWfLA==@protonmail.internalid>
2026-07-20 12:22 ` venus: encoder job execution hard-resets SoC on SM7325 (sc7280-compatible) — extensive analysis, need wrapper/GDSC insight Kirill Ermolitskiy
2026-07-20 12:55 ` Bryan O'Donoghue
2026-07-20 16:28 ` Kirill Ermolitskiy
2026-07-20 19:36 ` Bryan O'Donoghue
2026-07-20 20:41 ` Kirill Ermolitskiy
2026-07-20 21:31 ` Bryan O'Donoghue [this message]
2026-07-20 21:38 ` Kirill Ermolitskiy
2026-07-20 21:48 ` Kirill Ermolitskiy
2026-07-20 22:01 ` Dmitry Baryshkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1bc74fac-859b-46fd-91ef-16c40c8f9a7f@kernel.org \
--to=bod@kernel.org \
--cc=00vopoj00@gmail.com \
--cc=dikshita.agarwal@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=vikash.garodia@oss.qualcomm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox