Patches attached (git format-patch, UBUNTU: SAUCE, against resolute 7.0.0-42.42; they also apply unchanged to 7.0.0-43.43), tested on the X13s:
0001 dt-bindings: allow a 4th power domain "mmcx" for qcom,sm8350-venus. 0002 venus driver: attach "mx" and "mmcx" (opp_pmdomain_num = 2, as f45fd3dbb5f6 does for SM8250). 0003 venus driver: use vcodec0_core as the OPP clock (otherwise votes round up 1-2 OPPs and 560 MHz is unreachable). 0004 DT: add MMCX to the venus node and replace the OPP table with the upstream iris SC8280XP table (3a52eef16b97: 240-560 MHz, required-opps = <MX>, <MMCX>). 0002 and 0004 are needed together. With an old DTB the fixed driver does not probe: no video, but no fault. An SRU justification has been added to the description. Please target this bug to Resolute (I cannot nominate series). Why the OPP table must change as well: the SAUCE table (720/1014/1098/1332 MHz, MX only) is the old SM8250 venus table. Its frequencies are video_cc_mvs0_clk_src rates. Upstream corrected the frequencies for SM8250 in 68ea007df929 and added MMCX in d5c8efda722e. On the stock kernel the decoder clock measured after probe was vcodec0_core 533 MHz (RCG 1599 MHz), with no MX or MMCX vote. From reading the code, adding "mmcx" to the old one-column table would only make venus fail to probe. Test (one boot; modules built out of tree and loaded with insmod; synthetic H.264 clips; cmdline has clk_ignore_unused pd_ignore_unused): - The kernel image is a stubble UKI with embedded DTBs, so the test DTB only took effect with "stubble.dtb_override=false" on the command line. /proc/device-tree then showed the new venus node. - 1080p30 at real-time speed (ffmpeg -re): 90/90 frames, no errors, vcodec0_core 240 MHz. Venus voted MX 128 / MMCX 64; the display kept the MMCX rail at 128. - 2160p60 at real-time speed: 180/180 frames, no errors, 240 MHz. - 2x 2160p60 in parallel, as fast as possible: 180/180 frames each, vcodec0_core 240 -> 444 MHz, votes MX 192 / MMCX 256. - Display off for 12 s during a 20 s 1080p30 real-time decode: the MMCX rail ran at venus' own vote (64), 600/600 frames, no fault. - No SMMU fault or "idle fail" in any of 8 decodes. Runtime PM suspended cleanly afterwards, and the venus IRQ count stayed low. - Display off for 60 s with venus idle: no reset, and the MMCX rail switched off completely. With the stock driver, a display-off after the fault reset the machine (one controlled test, plus two resets matching the idle screen blank). Known limitation: 1080p30 decoded as fast as possible (9-12x real time) at the 240 MHz OPP output only 63/90 and 83/90 frames in two runs, with 6 and 5 "driver decode error / corrupt decoded frame" messages. With the stock clock (MMCX held by a test module) the same clip decoded 90/90 at ~17x. Probably the driver sizes the clock for the stream's fps (default 30; ffmpeg does not set it), so faster-than-real-time decode is under- clocked. Real-time decoding was clean, including 2160p60, and no fault occurred. Upstream iris measures the input frame rate instead (5c66647a5c3e). Not tested: the 533/560 MHz OPPs, the encoder, VP9/HEVC, Firefox playback, suspend/resume, long playback, a packaged kernel build, more than one boot. Test logs (redacted): x13s-venus-fixtest-logs.tar.gz (dmesg, ffmpeg logs, pm_genpd/clock samples every 0.2 s, display-off rails logs). I will also send the series to [email protected] as [SRU][R][PATCH 0/4]. I can test further builds on the X13s. (Prepared with the help of Claude Code, an AI coding assistant. I reviewed the results. Further Claude Code sessions reviewed them against the upstream sources and the run logs, and the tests ran on the X13s as described.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2172673 Title: [X13s / SC8280XP] venus never votes MMCX: hardware video decode causes SMMU fault, firmware hang and IRQ storm, followed by hard reset To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172673/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
