Linux Media Controller development
 help / color / mirror / Atom feed
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

  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