[PATCH v4 0/5] powervr: MT8173 GPU support
Chen-Yu Tsai
wenst at chromium.org
Thu Jul 30 01:37:12 PDT 2026
On Wed, Jul 29, 2026 at 5:35 PM YoungJoon Lee <getfeus at gmail.com> wrote:
>
> Hi Chen-Yu,
>
> A follow-up to my previous email.
>
> The official v1.1 firmware did fix the original "GPU device lost"
> problem.
>
> The following now works correctly:
>
> PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vulkaninfo --summary
>
> The driver initializes successfully and detects the PowerVR Rogue
> GX6250.
>
> However, while testing actual rendering, I found another issue which
> appears to be unrelated to the firmware.
>
> Kernel:
>
> Linux 7.2.0-rc5-next-20260727-stb-cbm-next-pvr-v4+
>
> Board:
>
> Google Elm (Acer Chromebook R13 / MT8173)
>
> Mesa:
>
> mesa 26.1.5
> vulkan-powervr 26.1.5
>
> Firmware:
>
> rogue_4.40.2.51_v1.fw
> FW version v1.1 (build 6976702 OS)
>
> Kernel command line:
>
> powervr.exp_hw_support=1
>
> Test command:
>
> PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 glmark2-es2-drm
>
> Renderer:
>
> GL_RENDERER:
> zink Vulkan 1.2
> (PowerVR Rogue GX6250)
>
> The benchmark progresses normally:
>
> build (VBO off) 212 FPS
> build (VBO on) 216 FPS
> texture nearest 174 FPS
> texture linear 173 FPS
> texture mipmap 174 FPS
> shading gouraud 165 FPS
> shading blinn-phong 135 FPS
> shading phong 99 FPS
>
> It consistently hangs at:
>
> shading=cel
>
> Immediately afterwards the kernel reports:
>
> refcount_t: underflow; use-after-free
>
> The first warning is:
>
> pvr_free_list_put()
> -> pvr_hwrt_dataset_release()
> -> pvr_hwrt_dataset_put()
> -> pvr_ioctl_destroy_hwrt_dataset()
>
> followed by:
>
> refcount_warn_saturate()
>
> Shortly afterwards another kernel Oops occurs:
>
> Unable to handle kernel NULL pointer dereference
>
> The second backtrace shows:
>
> pvr_gem_object_create()
> -> pvr_fw_object_create()
> -> pvr_hwrt_dataset_create()
> -> pvr_ioctl_create_hwrt_dataset()
>
> The glmark2 process remains as:
>
> glmark2-es2-drm <defunct>
I think this is more related to the unsupported nature of the GX6250,
and not specific to MT8173. Maybe someone else on the Imagination or
DRM mailing lists has a better idea of what's going on.
ChenYu
> The system is otherwise still reachable through SSH.
>
> I collected additional diagnostics, including:
>
> - complete dmesg
> - complete kernel journal
> - kernel configuration
> - PowerVR module information
> - userspace package versions
> - process/thread state
> - runtime PM state
> - running Device Tree
>
> I can send any of these if they would help.
>
> Also, please disregard my previous Tested-by tag for now, since this
> rendering issue was discovered afterwards.
>
> Thank you again for your help.
>
> Best regards,
>
> YoungJoon Lee
>
> 2026年7月29日(水) 13:38 YoungJoon Lee <getfeus at gmail.com>:
> >
> > 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 at gmail.com>
> >
> > Best regards,
> > YoungJoon
> >
> > 2026年7月29日(水) 12:32 Chen-Yu Tsai <wenst at chromium.org>:
> > >
> > > On Wed, Jul 29, 2026 at 8:08 AM YoungJoon Lee <getfeus at gmail.com> 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 at collabora.com>:
> > > > >
> > > > > On 7/28/26 16:44, Chen-Yu Tsai wrote:
> > > > > > On Tue, Jul 28, 2026 at 10:33 PM AngeloGioacchino Del Regno
> > > > > > <angelogioacchino.delregno at collabora.com> wrote:
> > > > > >>
> > > > > >> On 7/28/26 15:13, Chen-Yu Tsai wrote:
> > > > > >>> On Tue, Jul 28, 2026 at 9:10 PM Brian Masney <bmasney at redhat.com> 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
More information about the Linux-mediatek
mailing list