drm/etnaviv: detecting disabled Vivante GPU?

drm/etnaviv: detecting disabled Vivante GPU?

[Andre Przywara]

Hi,

the Allwinner A523/A527/T527 family of SoCs feature a Vivante
"VIP9000"(?) NPU, though it seems to be disabled on many SKUs.
See https://linux-sunxi.org/A523#Family_of_sun55iw3 for a table, the
row labelled "NPU" indicates which model has the IP. We suspect it's
all the same die, with the NPU selectively fused off on some packages.

Board vendors seem to use multiple SKUs of the SoC on the same board,
so it's hard to say which particular board has the NPU or not. We
figured that on unsupported SoCs all the NPU registers read as 0,
though, so were wondering if that could be considered as a bail-out
check for the driver?
At the moment I get this, on a SoC with a disabled NPU:
[    1.677612] etnaviv etnaviv: bound 7122000.npu (ops gpu_ops)
[    1.683849] etnaviv-gpu 7122000.npu: model: GC0, revision: 0
[    1.690020] etnaviv-gpu 7122000.npu: Unknown GPU model
[    1.696145] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
[    1.953053] etnaviv-gpu 7122000.npu: GPU not yet idle, mask: 0x00000000

Chen-Yu got this on his board featuring the NPU:
    etnaviv-gpu 7122000.npu: model: GC9000, revision: 9003

If I get the code correctly, then etnaviv_gpu_init() correctly detects
the "unsupported" GPU model, and returns -ENXIO, but load_gpu() in
etnaviv_drv.c then somewhat ignores this, since it keeps looking for more
GPUs, and fails to notice that *none* showed up:
/sys/kernel/debug/dri/etnaviv/gpu is empty in my case.

Quick questions:
- Is reading 0 from VIVS_HI_CHIP_IDENTITY (or any other of the ID
  registers) an invalid ID, so we can use that to detect those disabled
  NPUs? If not, can any other register used to check this? The whole
  block seems to be RAZ/WI when the NPU is disabled.

- Would it be acceptable to change the logic to error out of the
  driver's init or probe routine when no GPU/NPU has been found, at
  best with a proper error message? As it stands at the moment, the
  driver is loaded, but of course nothing is usable, so it keeps
  confusing users.

Happy to provide a patch, but just wanted to test the waters.

Cheers,
Andre

Re: drm/etnaviv: detecting disabled Vivante GPU?

[Icenowy Zheng]

在 2025-09-04星期四的 00:29 +0100，Andre Przywara写道：
> Hi,
> 
> the Allwinner A523/A527/T527 family of SoCs feature a Vivante
> "VIP9000"(?) NPU, though it seems to be disabled on many SKUs.
> See https://linux-sunxi.org/A523#Family_of_sun55iw3 for a table, the
> row labelled "NPU" indicates which model has the IP. We suspect it's
> all the same die, with the NPU selectively fused off on some
> packages.
> 
> Board vendors seem to use multiple SKUs of the SoC on the same board,

In the case of Amlogic things, they seem to provide different DT's, see
arch/arm64/boot/dts/amlogic/meson-g12b-a311d-bananapi-m2s.dts and
arch/arm64/boot/dts/amlogic/meson-g12b-s922x-bananapi-m2s.dts ; the
A311D is NPU-equipped SKU. (Although I don't know why they included
different DTSI's and then still enable &npu node in a311d variant of
board DT)

> so it's hard to say which particular board has the NPU or not. We
> figured that on unsupported SoCs all the NPU registers read as 0,
> though, so were wondering if that could be considered as a bail-out
> check for the driver?
> At the moment I get this, on a SoC with a disabled NPU:
> [    1.677612] etnaviv etnaviv: bound 7122000.npu (ops gpu_ops)
> [    1.683849] etnaviv-gpu 7122000.npu: model: GC0, revision: 0
> [    1.690020] etnaviv-gpu 7122000.npu: Unknown GPU model
> [    1.696145] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> [    1.953053] etnaviv-gpu 7122000.npu: GPU not yet idle, mask:
> 0x00000000
> 
> Chen-Yu got this on his board featuring the NPU:
>     etnaviv-gpu 7122000.npu: model: GC9000, revision: 9003
> 
> If I get the code correctly, then etnaviv_gpu_init() correctly
> detects
> the "unsupported" GPU model, and returns -ENXIO, but load_gpu() in
> etnaviv_drv.c then somewhat ignores this, since it keeps looking for
> more
> GPUs, and fails to notice that *none* showed up:
> /sys/kernel/debug/dri/etnaviv/gpu is empty in my case.
> 
> Quick questions:
> - Is reading 0 from VIVS_HI_CHIP_IDENTITY (or any other of the ID
>   registers) an invalid ID, so we can use that to detect those
> disabled
>   NPUs? If not, can any other register used to check this? The whole
>   block seems to be RAZ/WI when the NPU is disabled.
> 
> - Would it be acceptable to change the logic to error out of the
>   driver's init or probe routine when no GPU/NPU has been found, at
>   best with a proper error message? As it stands at the moment, the
>   driver is loaded, but of course nothing is usable, so it keeps
>   confusing users.
> 
> Happy to provide a patch, but just wanted to test the waters.
> 
> Cheers,
> Andre

Re: drm/etnaviv: detecting disabled Vivante GPU?

[Christian Gmeiner]

Hi

>
> the Allwinner A523/A527/T527 family of SoCs feature a Vivante
> "VIP9000"(?) NPU, though it seems to be disabled on many SKUs.
> See https://linux-sunxi.org/A523#Family_of_sun55iw3 for a table, the
> row labelled "NPU" indicates which model has the IP. We suspect it's
> all the same die, with the NPU selectively fused off on some packages.
>
> Board vendors seem to use multiple SKUs of the SoC on the same board,
> so it's hard to say which particular board has the NPU or not. We
> figured that on unsupported SoCs all the NPU registers read as 0,
> though, so were wondering if that could be considered as a bail-out
> check for the driver?
> At the moment I get this, on a SoC with a disabled NPU:
> [    1.677612] etnaviv etnaviv: bound 7122000.npu (ops gpu_ops)
> [    1.683849] etnaviv-gpu 7122000.npu: model: GC0, revision: 0
> [    1.690020] etnaviv-gpu 7122000.npu: Unknown GPU model
> [    1.696145] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> [    1.953053] etnaviv-gpu 7122000.npu: GPU not yet idle, mask: 0x00000000
>
> Chen-Yu got this on his board featuring the NPU:
>     etnaviv-gpu 7122000.npu: model: GC9000, revision: 9003
>
> If I get the code correctly, then etnaviv_gpu_init() correctly detects
> the "unsupported" GPU model, and returns -ENXIO, but load_gpu() in
> etnaviv_drv.c then somewhat ignores this, since it keeps looking for more
> GPUs, and fails to notice that *none* showed up:
> /sys/kernel/debug/dri/etnaviv/gpu is empty in my case.
>

Looks fine to me - no wrong behavior.

> Quick questions:
> - Is reading 0 from VIVS_HI_CHIP_IDENTITY (or any other of the ID
>   registers) an invalid ID, so we can use that to detect those disabled
>   NPUs? If not, can any other register used to check this? The whole
>   block seems to be RAZ/WI when the NPU is disabled.
>
> - Would it be acceptable to change the logic to error out of the
>   driver's init or probe routine when no GPU/NPU has been found, at
>   best with a proper error message? As it stands at the moment, the
>   driver is loaded, but of course nothing is usable, so it keeps
>   confusing users.
>

From an application standpoint, it’s not confusing since there is no etnaviv
device to interact with. The user might wonder about the kernel messages,
but that’s actually caused by an incorrect device tree. If the SoC doesn’t
have an NPU, it shouldn’t be enabled in the DTS.

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info/privacypolicy

Re: drm/etnaviv: detecting disabled Vivante GPU?

[Andre Przywara]

On Thu, 4 Sep 2025 12:10:30 +0200
Christian Gmeiner <christian.gmeiner@gmail.com> wrote:

> Hi
> 
> >
> > the Allwinner A523/A527/T527 family of SoCs feature a Vivante
> > "VIP9000"(?) NPU, though it seems to be disabled on many SKUs.
> > See https://linux-sunxi.org/A523#Family_of_sun55iw3 for a table, the
> > row labelled "NPU" indicates which model has the IP. We suspect it's
> > all the same die, with the NPU selectively fused off on some packages.
> >
> > Board vendors seem to use multiple SKUs of the SoC on the same board,
> > so it's hard to say which particular board has the NPU or not. We
> > figured that on unsupported SoCs all the NPU registers read as 0,
> > though, so were wondering if that could be considered as a bail-out
> > check for the driver?
> > At the moment I get this, on a SoC with a disabled NPU:
> > [    1.677612] etnaviv etnaviv: bound 7122000.npu (ops gpu_ops)
> > [    1.683849] etnaviv-gpu 7122000.npu: model: GC0, revision: 0
> > [    1.690020] etnaviv-gpu 7122000.npu: Unknown GPU model
> > [    1.696145] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> > [    1.953053] etnaviv-gpu 7122000.npu: GPU not yet idle, mask: 0x00000000
> >
> > Chen-Yu got this on his board featuring the NPU:
> >     etnaviv-gpu 7122000.npu: model: GC9000, revision: 9003
> >
> > If I get the code correctly, then etnaviv_gpu_init() correctly detects
> > the "unsupported" GPU model, and returns -ENXIO, but load_gpu() in
> > etnaviv_drv.c then somewhat ignores this, since it keeps looking for more
> > GPUs, and fails to notice that *none* showed up:
> > /sys/kernel/debug/dri/etnaviv/gpu is empty in my case.
> >  
> 
> Looks fine to me - no wrong behavior.
> 
> > Quick questions:
> > - Is reading 0 from VIVS_HI_CHIP_IDENTITY (or any other of the ID
> >   registers) an invalid ID, so we can use that to detect those disabled
> >   NPUs? If not, can any other register used to check this? The whole
> >   block seems to be RAZ/WI when the NPU is disabled.
> >
> > - Would it be acceptable to change the logic to error out of the
> >   driver's init or probe routine when no GPU/NPU has been found, at
> >   best with a proper error message? As it stands at the moment, the
> >   driver is loaded, but of course nothing is usable, so it keeps
> >   confusing users.
> >  
> 
> From an application standpoint, it’s not confusing since there is no etnaviv
> device to interact with. The user might wonder about the kernel messages,
> but that’s actually caused by an incorrect device tree. If the SoC doesn’t
> have an NPU, it shouldn’t be enabled in the DTS.

You have a point there, but as I mentioned above, that sounds tricky to
do: I have two boards that looks otherwise identical, but one has an A527,
the other an T527. And still both don't have the NPU, since only some
T527s feature it. So putting this on the user to use the right DT (or
U-Boot defconfig) does not sound very nice.

And in contrast to many other devices described in DTs, we *can* safely
detect the existence of this NPU: each of the SoCs have all the clock
gates and resets, and accesses to the MMIO frame do not fault - and the
kernel code apparently can cope with this situation already. So yeah, we
could smear something into U-Boot, to put a status = "disabled"; in there,
but I would like to avoid that, especially if the kernel is almost there
already.

Cheers,
Andre

 

Re: drm/etnaviv: detecting disabled Vivante GPU?

[Muhammed Subair]

Hello

The board I have is A527 , and the legacy (5.15.147)  kernel detecting npu as shown below,
However https://linux-sunxi.org/A523#Family_of_sun55iw3 shows that there is no npu, not sure whether information is correct in this link.

[   13.887892] npu[106][106] vipcore, platform device compatible=allwinner,npu
[   13.890322] npu[106][106] vipcore, platform driver device=0xffffff80c1a11c10
[   13.890394] npu[106][106] vipcore irq number is 116.
[   13.890471] vipcore 7122000.npu: supply npu not found, using dummy regulator
[   13.892589] npu[106][106] NPU Use VF3, use freq 696
[   13.892754] npu[106][106] Get NPU Regulator Control FAIL!
[   13.892766] npu[106][106] Want set npu vol(1000000) now vol(-22)
[   13.938664] npu[106][106] core_0, request irqline=116, name=vipcore_0
[   13.938889] npu[106][106] vipcore, allocate page for video memory, size: 0x2000000bytes
[   13.938900] npu[106][106] vipcore, video memory heap size is more than 4Mbyte,only can allocate 4M byte from page
[   13.938948] npu[106][106] vipcore, cpu_physical=0x10cc00000, vip_physical=0x10cc00000, vip_memsize=0x400000
[   13.940230] npu[106][106] VIPLite driver version 1.13.0.0-AW-2023-01-09
[   25.090905] sunxi:sunxi_pd_test-0.pd-npu-test:[WARN]: runtime_suspend disable clock

While with new patches in upstream 6.17.rc4 shows below ,

# dmesg | grep  7122000 
[   21.988215] etnaviv-gpu 7122000.npu: probe with driver etnaviv-gpu failed with error -110
[   21.988173] etnaviv-gpu 7122000.npu: deferred probe timeout, ignoring dependency
[   21.988215] etnaviv-gpu 7122000.npu: probe with driver etnaviv-gpu failed with error -110

Have the full source code and schematic, happy to provide any support required.

Subair

* Re: drm/etnaviv: detecting disabled Vivante GPU?
  2025-09-04 10:10 ` Christian Gmeiner
@ 2025-09-04 10:36   ` Andre Przywara
  0 siblings, 0 replies; 4+ messages in thread
From: Andre Przywara @ 2025-09-04 10:36 UTC (permalink / raw)
  To: Christian Gmeiner
  Cc: Lucas Stach, Russell King, etnaviv, dri-devel, linux-kernel,
	Chen-Yu Tsai, linux-sunxi

On Thu, 4 Sep 2025 12:10:30 +0200
Christian Gmeiner  wrote:

> Hi
> 
> >
> > the Allwinner A523/A527/T527 family of SoCs feature a Vivante
> > "VIP9000"(?) NPU, though it seems to be disabled on many SKUs.
> > See https://linux-sunxi.org/A523#Family_of_sun55iw3 for a table, the
> > row labelled "NPU" indicates which model has the IP. We suspect it's
> > all the same die, with the NPU selectively fused off on some packages.
> >
> > Board vendors seem to use multiple SKUs of the SoC on the same board,
> > so it's hard to say which particular board has the NPU or not. We
> > figured that on unsupported SoCs all the NPU registers read as 0,
> > though, so were wondering if that could be considered as a bail-out
> > check for the driver?
> > At the moment I get this, on a SoC with a disabled NPU:
> > [    1.677612] etnaviv etnaviv: bound 7122000.npu (ops gpu_ops)
> > [    1.683849] etnaviv-gpu 7122000.npu: model: GC0, revision: 0
> > [    1.690020] etnaviv-gpu 7122000.npu: Unknown GPU model
> > [    1.696145] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> > [    1.953053] etnaviv-gpu 7122000.npu: GPU not yet idle, mask: 0x00000000
> >
> > Chen-Yu got this on his board featuring the NPU:
> >     etnaviv-gpu 7122000.npu: model: GC9000, revision: 9003
> >
> > If I get the code correctly, then etnaviv_gpu_init() correctly detects
> > the "unsupported" GPU model, and returns -ENXIO, but load_gpu() in
> > etnaviv_drv.c then somewhat ignores this, since it keeps looking for more
> > GPUs, and fails to notice that *none* showed up:
> > /sys/kernel/debug/dri/etnaviv/gpu is empty in my case.
> >  
> 
> Looks fine to me - no wrong behavior.
> 
> > Quick questions:
> > - Is reading 0 from VIVS_HI_CHIP_IDENTITY (or any other of the ID
> >   registers) an invalid ID, so we can use that to detect those disabled
> >   NPUs? If not, can any other register used to check this? The whole
> >   block seems to be RAZ/WI when the NPU is disabled.
> >
> > - Would it be acceptable to change the logic to error out of the
> >   driver's init or probe routine when no GPU/NPU has been found, at
> >   best with a proper error message? As it stands at the moment, the
> >   driver is loaded, but of course nothing is usable, so it keeps
> >   confusing users.
> >  
> 
> From an application standpoint, it’s not confusing since there is no etnaviv
> device to interact with. The user might wonder about the kernel messages,
> but that’s actually caused by an incorrect device tree. If the SoC doesn’t
> have an NPU, it shouldn’t be enabled in the DTS.

You have a point there, but as I mentioned above, that sounds tricky to
do: I have two boards that looks otherwise identical, but one has an A527,
the other an T527. And still both don't have the NPU, since only some
T527s feature it. So putting this on the user to use the right DT (or
U-Boot defconfig) does not sound very nice.

And in contrast to many other devices described in DTs, we *can* safely
detect the existence of this NPU: each of the SoCs have all the clock
gates and resets, and accesses to the MMIO frame do not fault - and the
kernel code apparently can cope with this situation already. So yeah, we
could smear something into U-Boot, to put a status = "disabled"; in there,
but I would like to avoid that, especially if the kernel is almost there
already.

Cheers,
Andre

Re: drm/etnaviv: detecting disabled Vivante GPU?

[Lucas Stach]

Hi Andre,

Am Donnerstag, dem 04.09.2025 um 00:29 +0100 schrieb Andre Przywara:
> Hi,
> 
> the Allwinner A523/A527/T527 family of SoCs feature a Vivante
> "VIP9000"(?) NPU, though it seems to be disabled on many SKUs.
> See https://linux-sunxi.org/A523#Family_of_sun55iw3 for a table, the
> row labelled "NPU" indicates which model has the IP. We suspect it's
> all the same die, with the NPU selectively fused off on some packages.
> 
> Board vendors seem to use multiple SKUs of the SoC on the same board,
> so it's hard to say which particular board has the NPU or not. We
> figured that on unsupported SoCs all the NPU registers read as 0,
> though, so were wondering if that could be considered as a bail-out
> check for the driver?
> At the moment I get this, on a SoC with a disabled NPU:
> [    1.677612] etnaviv etnaviv: bound 7122000.npu (ops gpu_ops)
> [    1.683849] etnaviv-gpu 7122000.npu: model: GC0, revision: 0
> [    1.690020] etnaviv-gpu 7122000.npu: Unknown GPU model
> [    1.696145] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> [    1.953053] etnaviv-gpu 7122000.npu: GPU not yet idle, mask: 0x00000000
> 
> Chen-Yu got this on his board featuring the NPU:
>     etnaviv-gpu 7122000.npu: model: GC9000, revision: 9003
> 
> If I get the code correctly, then etnaviv_gpu_init() correctly detects
> the "unsupported" GPU model, and returns -ENXIO, but load_gpu() in
> etnaviv_drv.c then somewhat ignores this, since it keeps looking for more
> GPUs, and fails to notice that *none* showed up:
> /sys/kernel/debug/dri/etnaviv/gpu is empty in my case.
> 
> Quick questions:
> - Is reading 0 from VIVS_HI_CHIP_IDENTITY (or any other of the ID
>   registers) an invalid ID, so we can use that to detect those disabled
>   NPUs? If not, can any other register used to check this? The whole
>   block seems to be RAZ/WI when the NPU is disabled.
> 
Yes, 0 is not a valid core ID.

> - Would it be acceptable to change the logic to error out of the
>   driver's init or probe routine when no GPU/NPU has been found, at
>   best with a proper error message? As it stands at the moment, the
>   driver is loaded, but of course nothing is usable, so it keeps
>   confusing users.

Yes, I think it would be fine to not expose the DRM device at all if no
usable GPU core has been found.

However, I think it would still be good if your bootloader would fix up
the DT to avoid probing the driver at all if possible. It may work on
your system but access to a disabled GPU MMIO is not RAZ/WI everywhere.

On i.MX8M* we have a similar situation with disabled peripherals. There
the bootloader can detect which peripherals are active by looking at
the SoC fuses and fixes up the DT status property accordingly. Not sure
if you may have something similar on the Allwinner.

Regards,
Lucas

Re: drm/etnaviv: detecting disabled Vivante GPU?

[Andre Przywara]

On Wed, 10 Sep 2025 09:28:19 +0200
Lucas Stach <l.stach@pengutronix.de> wrote:

> Hi Andre,
> 
> Am Donnerstag, dem 04.09.2025 um 00:29 +0100 schrieb Andre Przywara:
> > Hi,
> > 
> > the Allwinner A523/A527/T527 family of SoCs feature a Vivante
> > "VIP9000"(?) NPU, though it seems to be disabled on many SKUs.
> > See https://linux-sunxi.org/A523#Family_of_sun55iw3 for a table, the
> > row labelled "NPU" indicates which model has the IP. We suspect it's
> > all the same die, with the NPU selectively fused off on some packages.
> > 
> > Board vendors seem to use multiple SKUs of the SoC on the same board,
> > so it's hard to say which particular board has the NPU or not. We
> > figured that on unsupported SoCs all the NPU registers read as 0,
> > though, so were wondering if that could be considered as a bail-out
> > check for the driver?
> > At the moment I get this, on a SoC with a disabled NPU:
> > [    1.677612] etnaviv etnaviv: bound 7122000.npu (ops gpu_ops)
> > [    1.683849] etnaviv-gpu 7122000.npu: model: GC0, revision: 0
> > [    1.690020] etnaviv-gpu 7122000.npu: Unknown GPU model
> > [    1.696145] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> > [    1.953053] etnaviv-gpu 7122000.npu: GPU not yet idle, mask: 0x00000000
> > 
> > Chen-Yu got this on his board featuring the NPU:
> >     etnaviv-gpu 7122000.npu: model: GC9000, revision: 9003
> > 
> > If I get the code correctly, then etnaviv_gpu_init() correctly detects
> > the "unsupported" GPU model, and returns -ENXIO, but load_gpu() in
> > etnaviv_drv.c then somewhat ignores this, since it keeps looking for more
> > GPUs, and fails to notice that *none* showed up:
> > /sys/kernel/debug/dri/etnaviv/gpu is empty in my case.
> > 
> > Quick questions:
> > - Is reading 0 from VIVS_HI_CHIP_IDENTITY (or any other of the ID
> >   registers) an invalid ID, so we can use that to detect those disabled
> >   NPUs? If not, can any other register used to check this? The whole
> >   block seems to be RAZ/WI when the NPU is disabled.
> >   
> Yes, 0 is not a valid core ID.

Ah, thanks, that helps to identify the situation (see below).

> > - Would it be acceptable to change the logic to error out of the
> >   driver's init or probe routine when no GPU/NPU has been found, at
> >   best with a proper error message? As it stands at the moment, the
> >   driver is loaded, but of course nothing is usable, so it keeps
> >   confusing users.  
> 
> Yes, I think it would be fine to not expose the DRM device at all if no
> usable GPU core has been found.
> 
> However, I think it would still be good if your bootloader would fix up
> the DT to avoid probing the driver at all if possible. It may work on
> your system but access to a disabled GPU MMIO is not RAZ/WI everywhere.

Yes, I agree, Allwinner is "nice" by using RAZ/WI if possible, but indeed
most other platforms SERROR out when touching an address without a device.

> On i.MX8M* we have a similar situation with disabled peripherals. There
> the bootloader can detect which peripherals are active by looking at
> the SoC fuses and fixes up the DT status property accordingly. Not sure
> if you may have something similar on the Allwinner.

We have code for DT patching in U-Boot, and use that already for some
Allwinner boards. I don't know if we can identify the actual fuse used. We
could use the SoC package identifier (first word of the SID eFUSE device,
cf. the second row in here [1]), but that would require maintenance, as new
IDs will show up, and we don't know every single one even now.
Another method would be to just ungate the clock and de-assert the reset,
then read the NPU ID register (0x18?) to see if it's zero or not. Probably
the most robust, but involves a bit more code, as we probably would need
some pseudo-device to fetch those reset/clock details from the DT.

I guess the current situation works as well, for now, but I will look at a
U-Boot patch, just wanted to check if we can avoid that.

Cheers,
Andre