Re: [PATCH v4 0/5] powervr: MT8173 GPU support

[YoungJoon Lee]

Hi Chen-Yu,

Thank you. Updating the firmware fixed the issue.

I replaced my previous firmware blob with the official v1.1 firmware:

  FW version v1.1 (build 6976702 OS)

  SHA256:
  e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44

After rebooting, the driver loaded the new firmware successfully:

  powervr 13000000.gpu: [drm] loaded firmware
  powervr/rogue_4.40.2.51_v1.fw
  powervr 13000000.gpu: [drm] FW version v1.1
  (build 6976702 OS)

I then ran:

  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary

This now completes successfully and detects the PowerVR Rogue GX6250.
The previous "GPU device lost" error no longer occurs.

So the issue was caused by the older, non-official firmware blob I was
using, rather than the v4 kernel series or my kernel configuration.

Thank you for pointing this out, and sorry for the noise.

Tested-by: YoungJoon Lee <getfeus@xxxxxxxxx>

Best regards,
YoungJoon

2026年7月29日(水) 12:32 Chen-Yu Tsai <wenst@xxxxxxxxxxxx>:
>
> On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus@xxxxxxxxx> wrote:
> >
> > Hi Chen-Yu,
> >
> > Thank you for posting the v4 series.
> >
> > I tested the complete v4 series on my MT8173 Chromebook, but I am
> > seeing a GPU device loss as soon as Mesa initializes the Vulkan device.
> >
> > My current setup is:
> >
> >   Board: Google Elm / Acer Chromebook R13 (CB5-312T)
> >   Kernel:
> >     linux-next next-20260727
> >     commit: 33d6e5134c70446eddafbb3fd5ad088e848a7ad6
> >     (next-20260727-5-g33d6e5134c70)
> >
> >   Kernel release: 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
> >
> >   Mesa: 26.1.5
> >   vulkan-powervr: 26.1.5
> >   Firmware:
> >     rogue_4.40.2.51_v1.fw
> >     SHA256:
> >     f44b7056992fb4057c987dcd7073468bec628aa56cb9815b1162f1cb7c1d73f2
>
> My firmware blob is different from yours:
>
> powervr 13000000.gpu: [drm] loaded firmware powervr/rogue_4.40.2.51_v1.fw
> powervr 13000000.gpu: [drm] FW version v1.0 (build 6503725 OS)
>
> SHA256: 1456504351bd041f0bf96667403ad32460fc7b807c09858df1f083e207323e4a
>
> Funny thing is neither of ours match the official firmware blobs released
> by Imagination [1].
>
> The latest version is "FW version v1.1 (build 6976702 OS)" with
> SHA256: e6bf10aaf442798fd81df9b9122e7e85900aafe77fcbec34b426af435c2b1c44
>
> This version also works for me.
>
> The "initial version" is "FW version v1.0 (build 6734358 OS)" with
> SHA256: baa227de4f297b7c0928c6535d15affd80aa9c5f528d2d5dc4b764ad050d22f2
>
> And this version also works.
>
> It seems your firmware build is even older than mine. I suggest you
> update it and try again?
>
> [1] https://gitlab.freedesktop.org/imagination/linux-firmware/-/blob/powervr/powervr/rogue_4.40.2.51_v1.fw
>
>
> > All five patches applied cleanly. The PowerVR driver probes, loads the
> > firmware, and creates the DRM render node successfully.
> >
> > However, when I run the following from an SSH session without GDM or
> > another graphical session running:
> >
> >   PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
> >
> > Mesa prints the expected GX6250 warnings:
> >
> >   Missing reset support for brn51764
> >   Missing reset support for brn58839
> >   Missing support for brn62269
> >
> > The command then hangs, and the kernel reports:
> >
> >   powervr 13000000.gpu: [drm] *ERROR* GPU device lost
> >
> > There are no additional timeout, MMU fault, firmware, clock, or runtime
> > PM messages immediately before the device-lost message.
> >
> > I originally also observed the same failure when GDM started GNOME
> > Shell, but reproducing it with vulkaninfo from a non-graphical SSH
> > session indicates that this is not specific to Mutter or GNOME.
> >
> > Since your cover letter reports that vkmark and glmark2-es2-drm work
> > with Mesa 26.1.5, I suspect that there may be a difference in the
> > kernel configuration or another part of the test environment.
> >
> > Could you please share the following details from your working setup?
> >
> >   1. The exact Chromebook board/model used for testing
>
> The codename is "telesu", which is basically a hana in a different case.
>
> >   2. The exact kernel base commit
>
> I have a whole bunch of patches on top of next-20260727, but none
> that should affect this.
>
> >   3. The kernel configuration, or at least the relevant DRM, PM,
> >      generic power-domain, IOMMU, and MediaTek clock options
>
> All relevant options are built-in.
>
> >   4. Whether CONFIG_DRM_POWERVR was built-in or built as a module
>
> Module.
>
> >   5. The firmware SHA256
>
> See above.
>
> >   6. The kernel command line and bootloader used
>
> Chromebook's builtin bootloader.
>
> cmdline:
>
>     cros_secure root=PARTUUID=824526A4-24EE-344D-85A2-20630C42D31A
>     console=tty0 console=ttyS0,115200n8 earlycon ro text drm.debug=0x106
>     panic=30 rootwait log_buf_len=1M no_console_suspend
>
> AFAICT nothing special.
>
> >   7. Whether `vulkaninfo --summary` also completes successfully
> >
> > My current relevant configuration includes:
> >
> > CONFIG_PM_SLEEP=y
> > CONFIG_PM=y
> > CONFIG_PM_GENERIC_DOMAINS=y
> > CONFIG_MODULES=y
> > CONFIG_DMA_SHARED_BUFFER=y
> > CONFIG_DRM_POWERVR=m
> > CONFIG_DRM_MEDIATEK=y
> > CONFIG_SYNC_FILE=y
> > CONFIG_COMMON_CLK_MT8173_MFGTOP=y
> > CONFIG_IOMMU_SUPPORT=y
> > CONFIG_ARM_SMMU=y
> > CONFIG_MTK_IOMMU=y
> >
> > I would be happy to test additional patches or provide any further
> > logs, kernel configuration, or debugging information if that would
> > help.
>
> As mentioned above, please try updating your firmware blob. Your
> version is even older than mine, and neither of ours is the "official"
> release.
>
>
> Thanks
> ChenYu
>
>
> > Thanks,
> > YoungJoon Lee
> >
> > 2026年7月29日(水) 0:28 AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@xxxxxxxxxxxxx>:
> > >
> > > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > > <angelogioacchino.delregno@xxxxxxxxxxxxx> wrote:
> > > >>
> > > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney@xxxxxxxxxx> wrote:
> > > >>>>
> > > >>>> Hi Chen-Yu,
> > > >>>>
> > > >>>> On Tue, Jul 28, 2026 at 05:17:58PM +0800, Chen-Yu Tsai wrote:
> > > >>>>> Hi everyone,
> > > >>>>>
> > > >>>>> This is v4 of my MT8173 PowerVR GPU support series.
> > > >>>>>
> > > >>>>> This time around Mesa was ready for basic testing, using both vulkanmark
> > > >>>>> and glmark2-es2-drm (with Zink). Details below.
> > > >>>>>
> > > >>>>> Changes since v3 (all in the clk driver patch):
> > > >>>>> - Changed pm_runtime_put() to pm_runtime_put_sync()
> > > >>>>> - Added missing of_node_put() in remove function
> > > >>>>>
> > > >>>>> Changes since v2 (all in the clk driver patch):
> > > >>>>> - Made COMMON_CLK_MT8173_MFGTOP depend on PM
> > > >>>>>     - Needed since the driver implements PM domains using the generic PM
> > > >>>>>       domain library, which also depends on PM
> > > >>>>>     - Fixes build breakage (kernel test robot)
> > > >>>>> - Fixed "RST_DELAY_CNT" name (Brian)
> > > >>>>> - Dropped unused mfg_desc (Brian)
> > > >>>>> - Added check of clk_prepare_enable()'s return value in
> > > >>>>>     clk_mt8173_mfgtop_power_on() (Brian)
> > > >>>>> - Saved error value for return in IS_ERR(data->clk_26m) branch
> > > >>>>>     (Dan Carpenter / kernel test robot w/ smatch)
> > > >>>>>
> > > >>>>> Changes since v1:
> > > >>>>> - Adapted to changed DT bindings
> > > >>>>> - Dropped driver change
> > > >>>>> - Use same power domain for "a" and "b" GPU power domains
> > > >>>>>
> > > >>>>>
> > > >>>>> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > > >>>>> some Chromebooks.
> > > >>>>
> > > >>>> I'm making a pull for Stephen for the clk changes. Should patches 1,2,4
> > > >>>> go through the clk tree? Patches 3,5 go through the DRM tree?
> > > >>>
> > > >>> Only patches 1 and 2 should go through the clock tree.
> > > >>>
> > > >>> Patch 3, 4, 5 can all go through the soc tree if Angelo wants to pick up
> > > >>> DT binding patches. Otherwise I can push patch 3 through drm-misc.
> > > >>>
> > > >>
> > > >> Not sure if I can really take the DRM bindings patch through soc.
> > > >>
> > > >> I will take the devicetree ones exactly right now, even though it's going to
> > > >> give warnings.
> > > >>
> > > >> I trust that you'll make the binding get into linux-next before it's too late.
> > > >
> > > > Rob beat me to it. :D
> > >
> > > Love it!
> > >
> > > Thanks Rob :-D
> > >
> > > Cheers,
> > > Angelo