[PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Geert Uytterhoeven]

Using the Imagination Technologies PowerVR Series 6 GPU requires a
proprietary firmware image, which is currently only available for Texas
Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
prevent asking the user about this driver when configuring a kernel
without Texas Instruments K3 Multicore SoC support.

Fixes: 4babef0708656c54 ("drm/imagination: Add skeleton PowerVR driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
---
v2:
  - Add Reviewed-by,
  - Clarify the firmware dependency.
---
 drivers/gpu/drm/imagination/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/imagination/Kconfig b/drivers/gpu/drm/imagination/Kconfig
index 3bfa2ac212dccb73..af492dbd9afd4ed9 100644
--- a/drivers/gpu/drm/imagination/Kconfig
+++ b/drivers/gpu/drm/imagination/Kconfig
@@ -6,6 +6,7 @@ config DRM_POWERVR
 	depends on ARM64
 	depends on DRM
 	depends on PM
+	depends on ARCH_K3 || COMPILE_TEST
 	select DRM_EXEC
 	select DRM_GEM_SHMEM_HELPER
 	select DRM_SCHED
-- 
2.34.1

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Hi,

On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> Using the Imagination Technologies PowerVR Series 6 GPU requires a
> proprietary firmware image, which is currently only available for Texas
> Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> prevent asking the user about this driver when configuring a kernel
> without Texas Instruments K3 Multicore SoC support.

This wasn't making sense the first time you sent it, and now that commit
log is just plain wrong. We have firmwares for the G6110, GX6250,
GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
Renesas, Mediatek, Rockchip, TI and StarFive, so across three
architectures and 5 platforms. In two months.

We won't keep up, and there's no point in trying to. Especially so when
the only benefit is for make defconfig users to hit 'enter' one time
less.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Geert Uytterhoeven]

Hi Maxime,

On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org> wrote:
> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > proprietary firmware image, which is currently only available for Texas
> > Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > prevent asking the user about this driver when configuring a kernel
> > without Texas Instruments K3 Multicore SoC support.
>
> This wasn't making sense the first time you sent it, and now that commit
> log is just plain wrong. We have firmwares for the G6110, GX6250,
> GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> Renesas, Mediatek, Rockchip, TI and StarFive, so across three

I am so happy to be proven wrong!
Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.

> architectures and 5 platforms. In two months.

That sounds like great progress, thanks a lot!

Where can I find these firmwares? Linux-firmware[1] seems to lack all
but the original K3 AM62x one.

Thanks again!

[1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>
> Hi Maxime,
>
> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org> wrote:
> > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > proprietary firmware image, which is currently only available for Texas
> > > Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > prevent asking the user about this driver when configuring a kernel
> > > without Texas Instruments K3 Multicore SoC support.
> >
> > This wasn't making sense the first time you sent it, and now that commit
> > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
>
> I am so happy to be proven wrong!
> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
>
> > architectures and 5 platforms. In two months.
>
> That sounds like great progress, thanks a lot!
>
Geert,

> Where can I find these firmwares? Linux-firmware[1] seems to lack all
> but the original K3 AM62x one.

I think PowerVR has a repo [1], but the last time I checked it, the
BVNC for the firmware didn't match what was necessary for the GX6250
on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
is.  I haven't tried recently because I was told more documentation
for firmware porting would be delayed until everything was pushed into
the kernel and Mesa.  Maybe there is a better repo and/or newer
firmware somewhere else.

adam

[1] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads


>
> Thanks again!
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> >
> > Hi Maxime,
> >
> > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > proprietary firmware image, which is currently only available for Texas
> > > > Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > prevent asking the user about this driver when configuring a kernel
> > > > without Texas Instruments K3 Multicore SoC support.
> > >
> > > This wasn't making sense the first time you sent it, and now that commit
> > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> >
> > I am so happy to be proven wrong!
> > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> >
> > > architectures and 5 platforms. In two months.
> >
> > That sounds like great progress, thanks a lot!
> >
> Geert,
>
> > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > but the original K3 AM62x one.
>
> I think PowerVR has a repo [1], but the last time I checked it, the
> BVNC for the firmware didn't match what was necessary for the GX6250
> on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
> is.  I haven't tried recently because I was told more documentation
> for firmware porting would be delayed until everything was pushed into
> the kernel and Mesa.  Maybe there is a better repo and/or newer
> firmware somewhere else.
>
I should have doubled checked the repo contents before I sent my last
e-mail , but it appears the firmware  [2] for the RZ/G2M, might be
present now. I don't know if there are driver updates necessary. I
checked my e-mails, but I didn't see any notification, or I would have
tried it earlier.  Either way, thank you Frank for adding it.  I'll
try to test when I have some time.

> adam
>
> [1] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads

[2] - https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b

>
>
> >
> > Thanks again!
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> >
> > Gr{oetje,eeting}s,
> >
> >                         Geert
> >
> > --
> > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> >
> > In personal conversations with technical people, I call myself a hacker. But
> > when I'm talking to journalists I just say "programmer" or something like that.
> >                                 -- Linus Torvalds

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> > >
> > > Hi Maxime,
> > >
> > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > > proprietary firmware image, which is currently only available for Texas
> > > > > Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > prevent asking the user about this driver when configuring a kernel
> > > > > without Texas Instruments K3 Multicore SoC support.
> > > >
> > > > This wasn't making sense the first time you sent it, and now that commit
> > > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> > >
> > > I am so happy to be proven wrong!
> > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> > >
> > > > architectures and 5 platforms. In two months.
> > >
> > > That sounds like great progress, thanks a lot!
> > >
> > Geert,
> >
> > > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > > but the original K3 AM62x one.
> >
> > I think PowerVR has a repo [1], but the last time I checked it, the
> > BVNC for the firmware didn't match what was necessary for the GX6250
> > on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
> > is.  I haven't tried recently because I was told more documentation
> > for firmware porting would be delayed until everything was pushed into
> > the kernel and Mesa.  Maybe there is a better repo and/or newer
> > firmware somewhere else.
> >
> I should have doubled checked the repo contents before I sent my last
> e-mail , but it appears the firmware  [2] for the RZ/G2M, might be
> present now. I don't know if there are driver updates necessary. I
> checked my e-mails, but I didn't see any notification, or I would have
> tried it earlier.  Either way, thank you Frank for adding it.  I'll
> try to test when I have some time.
>

I don't have the proper version of Mesa setup yet, but for what it's
worth, the firmware loads without error, and it doesn't hang.

[    9.787836] powervr fd000000.gpu: [drm] loaded firmware
powervr/rogue_4.45.2.58_v1.fw
[    9.787861] powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)


adam
> > adam
> >
> > [1] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
>
> [2] - https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
>
> >
> >
> > >
> > > Thanks again!
> > >
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> > >
> > > Gr{oetje,eeting}s,
> > >
> > >                         Geert
> > >
> > > --
> > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> > >
> > > In personal conversations with technical people, I call myself a hacker. But
> > > when I'm talking to journalists I just say "programmer" or something like that.
> > >                                 -- Linus Torvalds

RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Biju Das]

Hi Adam Ford,

> -----Original Message-----
> From: Adam Ford <aford173@gmail.com>
> Sent: Thursday, February 15, 2024 11:36 PM
> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> ARCH_K3
> 
> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> >
> > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > <geert@linux-m68k.org> wrote:
> > > >
> > > > Hi Maxime,
> > > >
> > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org>
> wrote:
> > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> wrote:
> > > > > > Using the Imagination Technologies PowerVR Series 6 GPU
> > > > > > requires a proprietary firmware image, which is currently only
> > > > > > available for Texas Instruments K3 AM62x SoCs.  Hence add a
> > > > > > dependency on ARCH_K3, to prevent asking the user about this
> > > > > > driver when configuring a kernel without Texas Instruments K3
> Multicore SoC support.
> > > > >
> > > > > This wasn't making sense the first time you sent it, and now
> > > > > that commit log is just plain wrong. We have firmwares for the
> > > > > G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, which can
> > > > > be found on (at least) Renesas, Mediatek, Rockchip, TI and
> > > > > StarFive, so across three
> > > >
> > > > I am so happy to be proven wrong!
> > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-
> W.
> > > >
> > > > > architectures and 5 platforms. In two months.
> > > >
> > > > That sounds like great progress, thanks a lot!
> > > >
> > > Geert,
> > >
> > > > Where can I find these firmwares? Linux-firmware[1] seems to lack
> > > > all but the original K3 AM62x one.
> > >
> > > I think PowerVR has a repo [1], but the last time I checked it, the
> > > BVNC for the firmware didn't match what was necessary for the GX6250
> > > on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
> > > is.  I haven't tried recently because I was told more documentation
> > > for firmware porting would be delayed until everything was pushed
> > > into the kernel and Mesa.  Maybe there is a better repo and/or newer
> > > firmware somewhere else.
> > >
> > I should have doubled checked the repo contents before I sent my last
> > e-mail , but it appears the firmware  [2] for the RZ/G2M, might be
> > present now. I don't know if there are driver updates necessary. I
> > checked my e-mails, but I didn't see any notification, or I would have
> > tried it earlier.  Either way, thank you Frank for adding it.  I'll
> > try to test when I have some time.
> >
> 
> I don't have the proper version of Mesa setup yet, but for what it's
> worth, the firmware loads without error, and it doesn't hang.

Based on [1] and [2],

kmscube should work on R-Car as it works on RZ/G2L with panfrost as earlier version of RZ/G2L
which uses drm based on RCar-Du, later changed to rzg2l-du.

[1]
https://elixir.bootlin.com/mesa/mesa-24.0.1/source/src/gallium/targets/dri/meson.build#L95

and 

[2]
https://elixir.bootlin.com/mesa/mesa-24.0.1/source/src/gallium/targets/dri/target.c#L123

Cheers,
Biju

> 
> [    9.787836] powervr fd000000.gpu: [drm] loaded firmware
> powervr/rogue_4.45.2.58_v1.fw
> [    9.787861] powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336
> OS)
> 
> 

Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 3348 bytes --]

On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> Hi Adam Ford,
> 
> > -----Original Message-----
> > From: Adam Ford <aford173@gmail.com>
> > Sent: Thursday, February 15, 2024 11:36 PM
> > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> > ARCH_K3
> > 
> > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> > >
> > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > > >
> > > > > Hi Maxime,
> > > > >
> > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org>
> > wrote:
> > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> > wrote:
> > > > > > > Using the Imagination Technologies PowerVR Series 6 GPU
> > > > > > > requires a proprietary firmware image, which is currently only
> > > > > > > available for Texas Instruments K3 AM62x SoCs.  Hence add a
> > > > > > > dependency on ARCH_K3, to prevent asking the user about this
> > > > > > > driver when configuring a kernel without Texas Instruments K3
> > Multicore SoC support.
> > > > > >
> > > > > > This wasn't making sense the first time you sent it, and now
> > > > > > that commit log is just plain wrong. We have firmwares for the
> > > > > > G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models, which can
> > > > > > be found on (at least) Renesas, Mediatek, Rockchip, TI and
> > > > > > StarFive, so across three
> > > > >
> > > > > I am so happy to be proven wrong!
> > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-
> > W.
> > > > >
> > > > > > architectures and 5 platforms. In two months.
> > > > >
> > > > > That sounds like great progress, thanks a lot!
> > > > >
> > > > Geert,
> > > >
> > > > > Where can I find these firmwares? Linux-firmware[1] seems to lack
> > > > > all but the original K3 AM62x one.
> > > >
> > > > I think PowerVR has a repo [1], but the last time I checked it, the
> > > > BVNC for the firmware didn't match what was necessary for the GX6250
> > > > on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
> > > > is.  I haven't tried recently because I was told more documentation
> > > > for firmware porting would be delayed until everything was pushed
> > > > into the kernel and Mesa.  Maybe there is a better repo and/or newer
> > > > firmware somewhere else.
> > > >
> > > I should have doubled checked the repo contents before I sent my last
> > > e-mail , but it appears the firmware  [2] for the RZ/G2M, might be
> > > present now. I don't know if there are driver updates necessary. I
> > > checked my e-mails, but I didn't see any notification, or I would have
> > > tried it earlier.  Either way, thank you Frank for adding it.  I'll
> > > try to test when I have some time.
> > >
> > 
> > I don't have the proper version of Mesa setup yet, but for what it's
> > worth, the firmware loads without error, and it doesn't hang.
> 
> Based on [1] and [2],
> 
> kmscube should work on R-Car as it works on RZ/G2L with panfrost as earlier version of RZ/G2L
> which uses drm based on RCar-Du, later changed to rzg2l-du.

IIRC, the mesa support isn't there yet for kmscube to start.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Biju Das]

Hi Maxime Ripard,

> -----Original Message-----
> From: Maxime Ripard <mripard@kernel.org>
> Sent: Friday, February 16, 2024 9:05 AM
> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> ARCH_K3
> 
> On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > Hi Adam Ford,
> >
> > > -----Original Message-----
> > > From: Adam Ford <aford173@gmail.com>
> > > Sent: Thursday, February 15, 2024 11:36 PM
> > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> > > on
> > > ARCH_K3
> > >
> > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> > > >
> > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
> wrote:
> > > > >
> > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > > <geert@linux-m68k.org> wrote:
> > > > > >
> > > > > > Hi Maxime,
> > > > > >
> > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > > > <mripard@kernel.org>
> > > wrote:
> > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> > > wrote:
> > > > > > > > Using the Imagination Technologies PowerVR Series 6 GPU
> > > > > > > > requires a proprietary firmware image, which is currently
> > > > > > > > only available for Texas Instruments K3 AM62x SoCs.  Hence
> > > > > > > > add a dependency on ARCH_K3, to prevent asking the user
> > > > > > > > about this driver when configuring a kernel without Texas
> > > > > > > > Instruments K3
> > > Multicore SoC support.
> > > > > > >
> > > > > > > This wasn't making sense the first time you sent it, and now
> > > > > > > that commit log is just plain wrong. We have firmwares for
> > > > > > > the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
> > > > > > > which can be found on (at least) Renesas, Mediatek,
> > > > > > > Rockchip, TI and StarFive, so across three
> > > > > >
> > > > > > I am so happy to be proven wrong!
> > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > > > > > R-Car M3-
> > > W.
> > > > > >
> > > > > > > architectures and 5 platforms. In two months.
> > > > > >
> > > > > > That sounds like great progress, thanks a lot!
> > > > > >
> > > > > Geert,
> > > > >
> > > > > > Where can I find these firmwares? Linux-firmware[1] seems to
> > > > > > lack all but the original K3 AM62x one.
> > > > >
> > > > > I think PowerVR has a repo [1], but the last time I checked it,
> > > > > the BVNC for the firmware didn't match what was necessary for
> > > > > the GX6250 on the RZ/G2M.  I can't remember what the
> > > > > corresponding R-Car3 model is.  I haven't tried recently because
> > > > > I was told more documentation for firmware porting would be
> > > > > delayed until everything was pushed into the kernel and Mesa.
> > > > > Maybe there is a better repo and/or newer firmware somewhere else.
> > > > >
> > > > I should have doubled checked the repo contents before I sent my
> > > > last e-mail , but it appears the firmware  [2] for the RZ/G2M,
> > > > might be present now. I don't know if there are driver updates
> > > > necessary. I checked my e-mails, but I didn't see any
> > > > notification, or I would have tried it earlier.  Either way, thank
> > > > you Frank for adding it.  I'll try to test when I have some time.
> > > >
> > >
> > > I don't have the proper version of Mesa setup yet, but for what it's
> > > worth, the firmware loads without error, and it doesn't hang.
> >
> > Based on [1] and [2],
> >
> > kmscube should work on R-Car as it works on RZ/G2L with panfrost as
> > earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
> to rzg2l-du.
> 
> IIRC, the mesa support isn't there yet for kmscube to start.

What about glmark2? I tested glmark2 as well.

Cheers,
Biju

Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 4256 bytes --]

On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> Hi Maxime Ripard,
> 
> > -----Original Message-----
> > From: Maxime Ripard <mripard@kernel.org>
> > Sent: Friday, February 16, 2024 9:05 AM
> > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> > ARCH_K3
> > 
> > On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > > Hi Adam Ford,
> > >
> > > > -----Original Message-----
> > > > From: Adam Ford <aford173@gmail.com>
> > > > Sent: Thursday, February 15, 2024 11:36 PM
> > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> > > > on
> > > > ARCH_K3
> > > >
> > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> > > > >
> > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
> > wrote:
> > > > > >
> > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > > > <geert@linux-m68k.org> wrote:
> > > > > > >
> > > > > > > Hi Maxime,
> > > > > > >
> > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > > > > <mripard@kernel.org>
> > > > wrote:
> > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> > > > wrote:
> > > > > > > > > Using the Imagination Technologies PowerVR Series 6 GPU
> > > > > > > > > requires a proprietary firmware image, which is currently
> > > > > > > > > only available for Texas Instruments K3 AM62x SoCs.  Hence
> > > > > > > > > add a dependency on ARCH_K3, to prevent asking the user
> > > > > > > > > about this driver when configuring a kernel without Texas
> > > > > > > > > Instruments K3
> > > > Multicore SoC support.
> > > > > > > >
> > > > > > > > This wasn't making sense the first time you sent it, and now
> > > > > > > > that commit log is just plain wrong. We have firmwares for
> > > > > > > > the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
> > > > > > > > which can be found on (at least) Renesas, Mediatek,
> > > > > > > > Rockchip, TI and StarFive, so across three
> > > > > > >
> > > > > > > I am so happy to be proven wrong!
> > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > > > > > > R-Car M3-
> > > > W.
> > > > > > >
> > > > > > > > architectures and 5 platforms. In two months.
> > > > > > >
> > > > > > > That sounds like great progress, thanks a lot!
> > > > > > >
> > > > > > Geert,
> > > > > >
> > > > > > > Where can I find these firmwares? Linux-firmware[1] seems to
> > > > > > > lack all but the original K3 AM62x one.
> > > > > >
> > > > > > I think PowerVR has a repo [1], but the last time I checked it,
> > > > > > the BVNC for the firmware didn't match what was necessary for
> > > > > > the GX6250 on the RZ/G2M.  I can't remember what the
> > > > > > corresponding R-Car3 model is.  I haven't tried recently because
> > > > > > I was told more documentation for firmware porting would be
> > > > > > delayed until everything was pushed into the kernel and Mesa.
> > > > > > Maybe there is a better repo and/or newer firmware somewhere else.
> > > > > >
> > > > > I should have doubled checked the repo contents before I sent my
> > > > > last e-mail , but it appears the firmware  [2] for the RZ/G2M,
> > > > > might be present now. I don't know if there are driver updates
> > > > > necessary. I checked my e-mails, but I didn't see any
> > > > > notification, or I would have tried it earlier.  Either way, thank
> > > > > you Frank for adding it.  I'll try to test when I have some time.
> > > > >
> > > >
> > > > I don't have the proper version of Mesa setup yet, but for what it's
> > > > worth, the firmware loads without error, and it doesn't hang.
> > >
> > > Based on [1] and [2],
> > >
> > > kmscube should work on R-Car as it works on RZ/G2L with panfrost as
> > > earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
> > to rzg2l-du.
> > 
> > IIRC, the mesa support isn't there yet for kmscube to start.
> 
> What about glmark2? I tested glmark2 as well.

It's not really a matter of kmscube itself, but the interaction with the
compositor entirely. You can run a headless vulkan rendering, but an
application that renders to a window won't work.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
>
> On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> > Hi Maxime Ripard,
> >
> > > -----Original Message-----
> > > From: Maxime Ripard <mripard@kernel.org>
> > > Sent: Friday, February 16, 2024 9:05 AM
> > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> > > ARCH_K3
> > >
> > > On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > > > Hi Adam Ford,
> > > >
> > > > > -----Original Message-----
> > > > > From: Adam Ford <aford173@gmail.com>
> > > > > Sent: Thursday, February 15, 2024 11:36 PM
> > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> > > > > on
> > > > > ARCH_K3
> > > > >
> > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> > > > > >
> > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > > > > <geert@linux-m68k.org> wrote:
> > > > > > > >
> > > > > > > > Hi Maxime,
> > > > > > > >
> > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > > > > > <mripard@kernel.org>
> > > > > wrote:
> > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> > > > > wrote:
> > > > > > > > > > Using the Imagination Technologies PowerVR Series 6 GPU
> > > > > > > > > > requires a proprietary firmware image, which is currently
> > > > > > > > > > only available for Texas Instruments K3 AM62x SoCs.  Hence
> > > > > > > > > > add a dependency on ARCH_K3, to prevent asking the user
> > > > > > > > > > about this driver when configuring a kernel without Texas
> > > > > > > > > > Instruments K3
> > > > > Multicore SoC support.
> > > > > > > > >
> > > > > > > > > This wasn't making sense the first time you sent it, and now
> > > > > > > > > that commit log is just plain wrong. We have firmwares for
> > > > > > > > > the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
> > > > > > > > > which can be found on (at least) Renesas, Mediatek,
> > > > > > > > > Rockchip, TI and StarFive, so across three
> > > > > > > >
> > > > > > > > I am so happy to be proven wrong!
> > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > > > > > > > R-Car M3-
> > > > > W.
> > > > > > > >
> > > > > > > > > architectures and 5 platforms. In two months.
> > > > > > > >
> > > > > > > > That sounds like great progress, thanks a lot!
> > > > > > > >
> > > > > > > Geert,
> > > > > > >
> > > > > > > > Where can I find these firmwares? Linux-firmware[1] seems to
> > > > > > > > lack all but the original K3 AM62x one.
> > > > > > >
> > > > > > > I think PowerVR has a repo [1], but the last time I checked it,
> > > > > > > the BVNC for the firmware didn't match what was necessary for
> > > > > > > the GX6250 on the RZ/G2M.  I can't remember what the
> > > > > > > corresponding R-Car3 model is.  I haven't tried recently because
> > > > > > > I was told more documentation for firmware porting would be
> > > > > > > delayed until everything was pushed into the kernel and Mesa.
> > > > > > > Maybe there is a better repo and/or newer firmware somewhere else.
> > > > > > >
> > > > > > I should have doubled checked the repo contents before I sent my
> > > > > > last e-mail , but it appears the firmware  [2] for the RZ/G2M,
> > > > > > might be present now. I don't know if there are driver updates
> > > > > > necessary. I checked my e-mails, but I didn't see any
> > > > > > notification, or I would have tried it earlier.  Either way, thank
> > > > > > you Frank for adding it.  I'll try to test when I have some time.
> > > > > >
> > > > >
> > > > > I don't have the proper version of Mesa setup yet, but for what it's
> > > > > worth, the firmware loads without error, and it doesn't hang.
> > > >
> > > > Based on [1] and [2],
> > > >
> > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost as
> > > > earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
> > > to rzg2l-du.
> > >
> > > IIRC, the mesa support isn't there yet for kmscube to start.
> >
> > What about glmark2? I tested glmark2 as well.
>
> It's not really a matter of kmscube itself, but the interaction with the
> compositor entirely. You can run a headless vulkan rendering, but an
> application that renders to a window won't work.

I have made a little progress.  I have Ubuntu running on an RZ/G2M
(Rogue GX6250) with a device tree configuring the GPU and the GPU
loads with firmware.

  powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
  powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
  [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0

drmdevice lists card0 and renderD128
--- Checking the number of DRM device available ---
--- Devices reported 2 ---
--- Retrieving devices information (PCI device revision is ignored) ---
device[0]
+-> available_nodes 0x05
+-> nodes
|   +-> nodes[0] /dev/dri/card0
|   +-> nodes[2] /dev/dri/renderD128
+-> bustype 0002
|   +-> platform
|       +-> fullname /soc/gpu@fd000000
+-> deviceinfo
    +-> platform
        +-> compatible
                    renesas,r8a774a1-gpu
                    img,img-axe

There is more to this dump, but it seems to repeat. I wanted to show
that it seems like it's trying to work.

I think I need to modify the powervr code in mesa to recognize the
renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not
sure, and I am hoping someone might be able to provide some guidance,
since I think I am missing something somewhere. I modified
pvr_device.c in the mesa driver to attempt do this:

/* This is the list of supported DRM render/display driver configs. */
static const struct pvr_drm_device_config pvr_drm_configs[] = {
   DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
   DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
   DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"),
};

When I run modetest -M rcar-du, I can see the encoders and connectors
and I can display test patterns, so the rcar-du is working.

I built Mesa 24.0.1 with the following options:

meson setup builddir -Dvulkan-drivers=imagination-experimental
-Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast

I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
documentation for the powerVR, and I have exported the variable for
VK_ICD_FILENAMES to point to the powervr json file.

when I try to run glmark2-drm, I was expecting the GL reddered to be
the powervr, but it keeps using the
GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)

I realize this driver is still in its infancy, but I was hoping
someone could give me some guidance to let me know if the work to do
is on the Mesa side or the rcar-du driver side, or something else.

I rebuilt both libdrm and mesa.  While I don't get any errors, I also
don't get the hardware acceleration I was hoping for.

I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm

...but it only renders with llvmpipe

    glmark2 2023.01
=======================================================
    OpenGL Information
    GL_VENDOR:      Mesa
    GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
    GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
    Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
    Surface Size:   3840x2160 fullscreen


I am not as familiar with the Mesa side, but if I can get this working
to a point where something is rendered, even if it's not 100%
compliant, I'd like to push patches to the kernel and/or Mesa if
necessary.

adam




>
> Maxime

RE: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Biju Das]

Hi Adam,

> -----Original Message-----
> From: Adam Ford <aford173@gmail.com>
> Sent: Sunday, February 18, 2024 11:26 PM
> Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> on ARCH_K3
> 
> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
> >
> > On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> > > Hi Maxime Ripard,
> > >
> > > > -----Original Message-----
> > > > From: Maxime Ripard <mripard@kernel.org>
> > > > Sent: Friday, February 16, 2024 9:05 AM
> > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > depend on
> > > > ARCH_K3
> > > >
> > > > On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > > > > Hi Adam Ford,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Adam Ford <aford173@gmail.com>
> > > > > > Sent: Thursday, February 15, 2024 11:36 PM
> > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > > > depend on
> > > > > > ARCH_K3
> > > > > >
> > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com>
> wrote:
> > > > > > >
> > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford
> > > > > > > <aford173@gmail.com>
> > > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > > > > > <geert@linux-m68k.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Maxime,
> > > > > > > > >
> > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > > > > > > <mripard@kernel.org>
> > > > > > wrote:
> > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert
> > > > > > > > > > Uytterhoeven
> > > > > > wrote:
> > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6
> > > > > > > > > > > GPU requires a proprietary firmware image, which is
> > > > > > > > > > > currently only available for Texas Instruments K3
> > > > > > > > > > > AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > > > > > > > prevent asking the user about this driver when
> > > > > > > > > > > configuring a kernel without Texas Instruments K3
> > > > > > Multicore SoC support.
> > > > > > > > > >
> > > > > > > > > > This wasn't making sense the first time you sent it,
> > > > > > > > > > and now that commit log is just plain wrong. We have
> > > > > > > > > > firmwares for the G6110, GX6250, GX6650, BXE-4-32, and
> > > > > > > > > > BXS-4-64 models, which can be found on (at least)
> > > > > > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so
> > > > > > > > > > across three
> > > > > > > > >
> > > > > > > > > I am so happy to be proven wrong!
> > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > > > > > > > > R-Car M3-
> > > > > > W.
> > > > > > > > >
> > > > > > > > > > architectures and 5 platforms. In two months.
> > > > > > > > >
> > > > > > > > > That sounds like great progress, thanks a lot!
> > > > > > > > >
> > > > > > > > Geert,
> > > > > > > >
> > > > > > > > > Where can I find these firmwares? Linux-firmware[1]
> > > > > > > > > seems to lack all but the original K3 AM62x one.
> > > > > > > >
> > > > > > > > I think PowerVR has a repo [1], but the last time I
> > > > > > > > checked it, the BVNC for the firmware didn't match what
> > > > > > > > was necessary for the GX6250 on the RZ/G2M.  I can't
> > > > > > > > remember what the corresponding R-Car3 model is.  I
> > > > > > > > haven't tried recently because I was told more
> > > > > > > > documentation for firmware porting would be delayed until
> everything was pushed into the kernel and Mesa.
> > > > > > > > Maybe there is a better repo and/or newer firmware somewhere
> else.
> > > > > > > >
> > > > > > > I should have doubled checked the repo contents before I
> > > > > > > sent my last e-mail , but it appears the firmware  [2] for
> > > > > > > the RZ/G2M, might be present now. I don't know if there are
> > > > > > > driver updates necessary. I checked my e-mails, but I didn't
> > > > > > > see any notification, or I would have tried it earlier.
> > > > > > > Either way, thank you Frank for adding it.  I'll try to test
> when I have some time.
> > > > > > >
> > > > > >
> > > > > > I don't have the proper version of Mesa setup yet, but for
> > > > > > what it's worth, the firmware loads without error, and it
> doesn't hang.
> > > > >
> > > > > Based on [1] and [2],
> > > > >
> > > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost
> > > > > as earlier version of RZ/G2L which uses drm based on RCar-Du,
> > > > > later changed
> > > > to rzg2l-du.
> > > >
> > > > IIRC, the mesa support isn't there yet for kmscube to start.
> > >
> > > What about glmark2? I tested glmark2 as well.
> >
> > It's not really a matter of kmscube itself, but the interaction with
> > the compositor entirely. You can run a headless vulkan rendering, but
> > an application that renders to a window won't work.
> 
> I have made a little progress.  I have Ubuntu running on an RZ/G2M (Rogue
> GX6250) with a device tree configuring the GPU and the GPU loads with
> firmware.
> 
>   powervr fd000000.gpu: [drm] loaded firmware
> powervr/rogue_4.45.2.58_v1.fw
>   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
>   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> 
> drmdevice lists card0 and renderD128
> --- Checking the number of DRM device available ---
> --- Devices reported 2 ---
> --- Retrieving devices information (PCI device revision is ignored) ---
> device[0]
> +-> available_nodes 0x05
> +-> nodes
> |   +-> nodes[0] /dev/dri/card0
> |   +-> nodes[2] /dev/dri/renderD128
> +-> bustype 0002
> |   +-> platform
> |       +-> fullname /soc/gpu@fd000000
> +-> deviceinfo
>     +-> platform
>         +-> compatible
>                     renesas,r8a774a1-gpu
>                     img,img-axe
> 
> There is more to this dump, but it seems to repeat. I wanted to show that
> it seems like it's trying to work.
> 
> I think I need to modify the powervr code in mesa to recognize the
> renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not sure,
> and I am hoping someone might be able to provide some guidance, since I
> think I am missing something somewhere. I modified pvr_device.c in the
> mesa driver to attempt do this:
> 
> /* This is the list of supported DRM render/display driver configs. */
> static const struct pvr_drm_device_config pvr_drm_configs[] = {
>    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
>    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
>    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"), };
> 
> When I run modetest -M rcar-du, I can see the encoders and connectors and
> I can display test patterns, so the rcar-du is working.
> 
> I built Mesa 24.0.1 with the following options:
> 
> meson setup builddir -Dvulkan-drivers=imagination-experimental
> -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> 
> I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> documentation for the powerVR, and I have exported the variable for
> VK_ICD_FILENAMES to point to the powervr json file.
> 
> when I try to run glmark2-drm, I was expecting the GL reddered to be the
> powervr, but it keeps using the
> GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> 
> I realize this driver is still in its infancy, but I was hoping someone
> could give me some guidance to let me know if the work to do is on the
> Mesa side or the rcar-du driver side, or something else.
> 
> I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> don't get the hardware acceleration I was hoping for.
> 
> I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> 
> ...but it only renders with llvmpipe
> 
>     glmark2 2023.01
> =======================================================
>     OpenGL Information
>     GL_VENDOR:      Mesa
>     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
>     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
>     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
>     Surface Size:   3840x2160 fullscreen
> 
> 
> I am not as familiar with the Mesa side, but if I can get this working to
> a point where something is rendered, even if it's not 100% compliant, I'd
> like to push patches to the kernel and/or Mesa if necessary.

FYI, the glmark2 I tested on RZ/G2L with panfrost is with wayland window system [1].

Maybe there should be an panfrost equivalent package for powevr is available in mesa??
That is the only difference w.r.to panfrost.

PACKAGECONFIG_append_pn-mesa = " egl kmsro panfrost"


[1] https://renesas.info/wiki/RZ-G/Panfrost_for_RZG2L


Cheers,
Biju

Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Mon, Feb 19, 2024 at 1:45 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
>
> Hi Adam,
>
> > -----Original Message-----
> > From: Adam Ford <aford173@gmail.com>
> > Sent: Sunday, February 18, 2024 11:26 PM
> > Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> > on ARCH_K3
> >
> > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
> > >
> > > On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> > > > Hi Maxime Ripard,
> > > >
> > > > > -----Original Message-----
> > > > > From: Maxime Ripard <mripard@kernel.org>
> > > > > Sent: Friday, February 16, 2024 9:05 AM
> > > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > > depend on
> > > > > ARCH_K3
> > > > >
> > > > > On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > > > > > Hi Adam Ford,
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Adam Ford <aford173@gmail.com>
> > > > > > > Sent: Thursday, February 15, 2024 11:36 PM
> > > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > > > > depend on
> > > > > > > ARCH_K3
> > > > > > >
> > > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com>
> > wrote:
> > > > > > > >
> > > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford
> > > > > > > > <aford173@gmail.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > > > > > > <geert@linux-m68k.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Maxime,
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > > > > > > > <mripard@kernel.org>
> > > > > > > wrote:
> > > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert
> > > > > > > > > > > Uytterhoeven
> > > > > > > wrote:
> > > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6
> > > > > > > > > > > > GPU requires a proprietary firmware image, which is
> > > > > > > > > > > > currently only available for Texas Instruments K3
> > > > > > > > > > > > AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > > > > > > > > prevent asking the user about this driver when
> > > > > > > > > > > > configuring a kernel without Texas Instruments K3
> > > > > > > Multicore SoC support.
> > > > > > > > > > >
> > > > > > > > > > > This wasn't making sense the first time you sent it,
> > > > > > > > > > > and now that commit log is just plain wrong. We have
> > > > > > > > > > > firmwares for the G6110, GX6250, GX6650, BXE-4-32, and
> > > > > > > > > > > BXS-4-64 models, which can be found on (at least)
> > > > > > > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so
> > > > > > > > > > > across three
> > > > > > > > > >
> > > > > > > > > > I am so happy to be proven wrong!
> > > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > > > > > > > > > R-Car M3-
> > > > > > > W.
> > > > > > > > > >
> > > > > > > > > > > architectures and 5 platforms. In two months.
> > > > > > > > > >
> > > > > > > > > > That sounds like great progress, thanks a lot!
> > > > > > > > > >
> > > > > > > > > Geert,
> > > > > > > > >
> > > > > > > > > > Where can I find these firmwares? Linux-firmware[1]
> > > > > > > > > > seems to lack all but the original K3 AM62x one.
> > > > > > > > >
> > > > > > > > > I think PowerVR has a repo [1], but the last time I
> > > > > > > > > checked it, the BVNC for the firmware didn't match what
> > > > > > > > > was necessary for the GX6250 on the RZ/G2M.  I can't
> > > > > > > > > remember what the corresponding R-Car3 model is.  I
> > > > > > > > > haven't tried recently because I was told more
> > > > > > > > > documentation for firmware porting would be delayed until
> > everything was pushed into the kernel and Mesa.
> > > > > > > > > Maybe there is a better repo and/or newer firmware somewhere
> > else.
> > > > > > > > >
> > > > > > > > I should have doubled checked the repo contents before I
> > > > > > > > sent my last e-mail , but it appears the firmware  [2] for
> > > > > > > > the RZ/G2M, might be present now. I don't know if there are
> > > > > > > > driver updates necessary. I checked my e-mails, but I didn't
> > > > > > > > see any notification, or I would have tried it earlier.
> > > > > > > > Either way, thank you Frank for adding it.  I'll try to test
> > when I have some time.
> > > > > > > >
> > > > > > >
> > > > > > > I don't have the proper version of Mesa setup yet, but for
> > > > > > > what it's worth, the firmware loads without error, and it
> > doesn't hang.
> > > > > >
> > > > > > Based on [1] and [2],
> > > > > >
> > > > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost
> > > > > > as earlier version of RZ/G2L which uses drm based on RCar-Du,
> > > > > > later changed
> > > > > to rzg2l-du.
> > > > >
> > > > > IIRC, the mesa support isn't there yet for kmscube to start.
> > > >
> > > > What about glmark2? I tested glmark2 as well.
> > >
> > > It's not really a matter of kmscube itself, but the interaction with
> > > the compositor entirely. You can run a headless vulkan rendering, but
> > > an application that renders to a window won't work.
> >
> > I have made a little progress.  I have Ubuntu running on an RZ/G2M (Rogue
> > GX6250) with a device tree configuring the GPU and the GPU loads with
> > firmware.
> >
> >   powervr fd000000.gpu: [drm] loaded firmware
> > powervr/rogue_4.45.2.58_v1.fw
> >   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
> >   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> >
> > drmdevice lists card0 and renderD128
> > --- Checking the number of DRM device available ---
> > --- Devices reported 2 ---
> > --- Retrieving devices information (PCI device revision is ignored) ---
> > device[0]
> > +-> available_nodes 0x05
> > +-> nodes
> > |   +-> nodes[0] /dev/dri/card0
> > |   +-> nodes[2] /dev/dri/renderD128
> > +-> bustype 0002
> > |   +-> platform
> > |       +-> fullname /soc/gpu@fd000000
> > +-> deviceinfo
> >     +-> platform
> >         +-> compatible
> >                     renesas,r8a774a1-gpu
> >                     img,img-axe
> >
> > There is more to this dump, but it seems to repeat. I wanted to show that
> > it seems like it's trying to work.
> >
> > I think I need to modify the powervr code in mesa to recognize the
> > renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not sure,
> > and I am hoping someone might be able to provide some guidance, since I
> > think I am missing something somewhere. I modified pvr_device.c in the
> > mesa driver to attempt do this:
> >
> > /* This is the list of supported DRM render/display driver configs. */
> > static const struct pvr_drm_device_config pvr_drm_configs[] = {
> >    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
> >    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
> >    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"), };
> >
> > When I run modetest -M rcar-du, I can see the encoders and connectors and
> > I can display test patterns, so the rcar-du is working.
> >
> > I built Mesa 24.0.1 with the following options:
> >
> > meson setup builddir -Dvulkan-drivers=imagination-experimental
> > -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> >
> > I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> > documentation for the powerVR, and I have exported the variable for
> > VK_ICD_FILENAMES to point to the powervr json file.
> >
> > when I try to run glmark2-drm, I was expecting the GL reddered to be the
> > powervr, but it keeps using the
> > GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> >
> > I realize this driver is still in its infancy, but I was hoping someone
> > could give me some guidance to let me know if the work to do is on the
> > Mesa side or the rcar-du driver side, or something else.
> >
> > I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> > don't get the hardware acceleration I was hoping for.
> >
> > I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> > MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> >
> > ...but it only renders with llvmpipe
> >
> >     glmark2 2023.01
> > =======================================================
> >     OpenGL Information
> >     GL_VENDOR:      Mesa
> >     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> >     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
> >     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
> >     Surface Size:   3840x2160 fullscreen
> >
> >
> > I am not as familiar with the Mesa side, but if I can get this working to
> > a point where something is rendered, even if it's not 100% compliant, I'd
> > like to push patches to the kernel and/or Mesa if necessary.
>
> FYI, the glmark2 I tested on RZ/G2L with panfrost is with wayland window system [1].
>
> Maybe there should be an panfrost equivalent package for powevr is available in mesa??
> That is the only difference w.r.to panfrost.
>
> PACKAGECONFIG_append_pn-mesa = " egl kmsro panfrost"
>

I am not using Yocto, because I am using Ubuntu, but I have build Mesa
per the instructions they provided, but the glue that connects the
powervr to the rcar-du isn't as clear.  I looked at the panfrost
implementation, but I didn't see anything obvious.   It looks like the
panfrost integrates with the kms driver, which I was rather expecting
powervr would do.  I can tell the mesa library is build built and
loaded but it's not attempting to use it for some reason

The GX6250 that is supported looks like it needs some additional
look-up-tables added to src/imagination/common/pvr_device_info.c
inside Mesa because the LUT they have is for a different BVNC despite
the firmware for the BVNC being posted.  I'll have to see if I can
find documentation for the the features that are enabled or not within
this variant of the the GX6250.

adam

>
> [1] https://renesas.info/wiki/RZ-G/Panfrost_for_RZG2L
>
>
> Cheers,
> Biju
>

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Maxime Ripard]

[-- Attachment #1: Type: text/plain, Size: 10433 bytes --]

On Mon, Feb 19, 2024 at 10:38:12AM -0600, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 1:45 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> >
> > Hi Adam,
> >
> > > -----Original Message-----
> > > From: Adam Ford <aford173@gmail.com>
> > > Sent: Sunday, February 18, 2024 11:26 PM
> > > Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> > > on ARCH_K3
> > >
> > > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
> > > >
> > > > On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> > > > > Hi Maxime Ripard,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Maxime Ripard <mripard@kernel.org>
> > > > > > Sent: Friday, February 16, 2024 9:05 AM
> > > > > > Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > > > depend on
> > > > > > ARCH_K3
> > > > > >
> > > > > > On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > > > > > > Hi Adam Ford,
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Adam Ford <aford173@gmail.com>
> > > > > > > > Sent: Thursday, February 15, 2024 11:36 PM
> > > > > > > > Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should
> > > > > > > > depend on
> > > > > > > > ARCH_K3
> > > > > > > >
> > > > > > > > On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford
> > > > > > > > > <aford173@gmail.com>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > > > > > > > <geert@linux-m68k.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Maxime,
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > > > > > > > > > > <mripard@kernel.org>
> > > > > > > > wrote:
> > > > > > > > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert
> > > > > > > > > > > > Uytterhoeven
> > > > > > > > wrote:
> > > > > > > > > > > > > Using the Imagination Technologies PowerVR Series 6
> > > > > > > > > > > > > GPU requires a proprietary firmware image, which is
> > > > > > > > > > > > > currently only available for Texas Instruments K3
> > > > > > > > > > > > > AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > > > > > > > > > prevent asking the user about this driver when
> > > > > > > > > > > > > configuring a kernel without Texas Instruments K3
> > > > > > > > Multicore SoC support.
> > > > > > > > > > > >
> > > > > > > > > > > > This wasn't making sense the first time you sent it,
> > > > > > > > > > > > and now that commit log is just plain wrong. We have
> > > > > > > > > > > > firmwares for the G6110, GX6250, GX6650, BXE-4-32, and
> > > > > > > > > > > > BXS-4-64 models, which can be found on (at least)
> > > > > > > > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so
> > > > > > > > > > > > across three
> > > > > > > > > > >
> > > > > > > > > > > I am so happy to be proven wrong!
> > > > > > > > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > > > > > > > > > > R-Car M3-
> > > > > > > > W.
> > > > > > > > > > >
> > > > > > > > > > > > architectures and 5 platforms. In two months.
> > > > > > > > > > >
> > > > > > > > > > > That sounds like great progress, thanks a lot!
> > > > > > > > > > >
> > > > > > > > > > Geert,
> > > > > > > > > >
> > > > > > > > > > > Where can I find these firmwares? Linux-firmware[1]
> > > > > > > > > > > seems to lack all but the original K3 AM62x one.
> > > > > > > > > >
> > > > > > > > > > I think PowerVR has a repo [1], but the last time I
> > > > > > > > > > checked it, the BVNC for the firmware didn't match what
> > > > > > > > > > was necessary for the GX6250 on the RZ/G2M.  I can't
> > > > > > > > > > remember what the corresponding R-Car3 model is.  I
> > > > > > > > > > haven't tried recently because I was told more
> > > > > > > > > > documentation for firmware porting would be delayed until
> > > everything was pushed into the kernel and Mesa.
> > > > > > > > > > Maybe there is a better repo and/or newer firmware somewhere
> > > else.
> > > > > > > > > >
> > > > > > > > > I should have doubled checked the repo contents before I
> > > > > > > > > sent my last e-mail , but it appears the firmware  [2] for
> > > > > > > > > the RZ/G2M, might be present now. I don't know if there are
> > > > > > > > > driver updates necessary. I checked my e-mails, but I didn't
> > > > > > > > > see any notification, or I would have tried it earlier.
> > > > > > > > > Either way, thank you Frank for adding it.  I'll try to test
> > > when I have some time.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't have the proper version of Mesa setup yet, but for
> > > > > > > > what it's worth, the firmware loads without error, and it
> > > doesn't hang.
> > > > > > >
> > > > > > > Based on [1] and [2],
> > > > > > >
> > > > > > > kmscube should work on R-Car as it works on RZ/G2L with panfrost
> > > > > > > as earlier version of RZ/G2L which uses drm based on RCar-Du,
> > > > > > > later changed
> > > > > > to rzg2l-du.
> > > > > >
> > > > > > IIRC, the mesa support isn't there yet for kmscube to start.
> > > > >
> > > > > What about glmark2? I tested glmark2 as well.
> > > >
> > > > It's not really a matter of kmscube itself, but the interaction with
> > > > the compositor entirely. You can run a headless vulkan rendering, but
> > > > an application that renders to a window won't work.
> > >
> > > I have made a little progress.  I have Ubuntu running on an RZ/G2M (Rogue
> > > GX6250) with a device tree configuring the GPU and the GPU loads with
> > > firmware.
> > >
> > >   powervr fd000000.gpu: [drm] loaded firmware
> > > powervr/rogue_4.45.2.58_v1.fw
> > >   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
> > >   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> > >
> > > drmdevice lists card0 and renderD128
> > > --- Checking the number of DRM device available ---
> > > --- Devices reported 2 ---
> > > --- Retrieving devices information (PCI device revision is ignored) ---
> > > device[0]
> > > +-> available_nodes 0x05
> > > +-> nodes
> > > |   +-> nodes[0] /dev/dri/card0
> > > |   +-> nodes[2] /dev/dri/renderD128
> > > +-> bustype 0002
> > > |   +-> platform
> > > |       +-> fullname /soc/gpu@fd000000
> > > +-> deviceinfo
> > >     +-> platform
> > >         +-> compatible
> > >                     renesas,r8a774a1-gpu
> > >                     img,img-axe
> > >
> > > There is more to this dump, but it seems to repeat. I wanted to show that
> > > it seems like it's trying to work.
> > >
> > > I think I need to modify the powervr code in mesa to recognize the
> > > renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not sure,
> > > and I am hoping someone might be able to provide some guidance, since I
> > > think I am missing something somewhere. I modified pvr_device.c in the
> > > mesa driver to attempt do this:
> > >
> > > /* This is the list of supported DRM render/display driver configs. */
> > > static const struct pvr_drm_device_config pvr_drm_configs[] = {
> > >    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
> > >    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
> > >    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"), };
> > >
> > > When I run modetest -M rcar-du, I can see the encoders and connectors and
> > > I can display test patterns, so the rcar-du is working.
> > >
> > > I built Mesa 24.0.1 with the following options:
> > >
> > > meson setup builddir -Dvulkan-drivers=imagination-experimental
> > > -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> > >
> > > I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> > > documentation for the powerVR, and I have exported the variable for
> > > VK_ICD_FILENAMES to point to the powervr json file.
> > >
> > > when I try to run glmark2-drm, I was expecting the GL reddered to be the
> > > powervr, but it keeps using the
> > > GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> > >
> > > I realize this driver is still in its infancy, but I was hoping someone
> > > could give me some guidance to let me know if the work to do is on the
> > > Mesa side or the rcar-du driver side, or something else.
> > >
> > > I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> > > don't get the hardware acceleration I was hoping for.
> > >
> > > I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> > > MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> > >
> > > ...but it only renders with llvmpipe
> > >
> > >     glmark2 2023.01
> > > =======================================================
> > >     OpenGL Information
> > >     GL_VENDOR:      Mesa
> > >     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> > >     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
> > >     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
> > >     Surface Size:   3840x2160 fullscreen
> > >
> > >
> > > I am not as familiar with the Mesa side, but if I can get this working to
> > > a point where something is rendered, even if it's not 100% compliant, I'd
> > > like to push patches to the kernel and/or Mesa if necessary.
> >
> > FYI, the glmark2 I tested on RZ/G2L with panfrost is with wayland window system [1].
> >
> > Maybe there should be an panfrost equivalent package for powevr is available in mesa??
> > That is the only difference w.r.to panfrost.
> >
> > PACKAGECONFIG_append_pn-mesa = " egl kmsro panfrost"
> >
> 
> I am not using Yocto, because I am using Ubuntu, but I have build Mesa
> per the instructions they provided, but the glue that connects the
> powervr to the rcar-du isn't as clear.  I looked at the panfrost
> implementation, but I didn't see anything obvious.   It looks like the
> panfrost integrates with the kms driver, which I was rather expecting
> powervr would do.  I can tell the mesa library is build built and
> loaded but it's not attempting to use it for some reason

I think the reason is what Matt was hinting at: the driver doesn't
support OpenGL at the moment, and you're trying to use an OpenGL
application.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Matt Coster]

[-- Attachment #1.1: Type: text/plain, Size: 10128 bytes --]

Hi Adam,

On 19/02/2024 16:38, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 1:45 AM Biju Das <biju.das.jz@bp.renesas.com> wrote:
>>
>> Hi Adam,
>>
>>> -----Original Message-----
>>> From: Adam Ford <aford173@gmail.com>
>>> Sent: Sunday, February 18, 2024 11:26 PM
>>> Subject: Re: RE: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend
>>> on ARCH_K3
>>>
>>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
>>>>
>>>> On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
>>>>> Hi Maxime Ripard,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Maxime Ripard <mripard@kernel.org>
>>>>>> Sent: Friday, February 16, 2024 9:05 AM
>>>>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should
>>>>>> depend on
>>>>>> ARCH_K3
>>>>>>
>>>>>> On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
>>>>>>> Hi Adam Ford,
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Adam Ford <aford173@gmail.com>
>>>>>>>> Sent: Thursday, February 15, 2024 11:36 PM
>>>>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should
>>>>>>>> depend on
>>>>>>>> ARCH_K3
>>>>>>>>
>>>>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com>
>>> wrote:
>>>>>>>>>
>>>>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford
>>>>>>>>> <aford173@gmail.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
>>>>>>>>>> <geert@linux-m68k.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Maxime,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
>>>>>>>>>>> <mripard@kernel.org>
>>>>>>>> wrote:
>>>>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert
>>>>>>>>>>>> Uytterhoeven
>>>>>>>> wrote:
>>>>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6
>>>>>>>>>>>>> GPU requires a proprietary firmware image, which is
>>>>>>>>>>>>> currently only available for Texas Instruments K3
>>>>>>>>>>>>> AM62x SoCs.  Hence add a dependency on ARCH_K3, to
>>>>>>>>>>>>> prevent asking the user about this driver when
>>>>>>>>>>>>> configuring a kernel without Texas Instruments K3
>>>>>>>> Multicore SoC support.
>>>>>>>>>>>>
>>>>>>>>>>>> This wasn't making sense the first time you sent it,
>>>>>>>>>>>> and now that commit log is just plain wrong. We have
>>>>>>>>>>>> firmwares for the G6110, GX6250, GX6650, BXE-4-32, and
>>>>>>>>>>>> BXS-4-64 models, which can be found on (at least)
>>>>>>>>>>>> Renesas, Mediatek, Rockchip, TI and StarFive, so
>>>>>>>>>>>> across three
>>>>>>>>>>>
>>>>>>>>>>> I am so happy to be proven wrong!
>>>>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
>>>>>>>>>>> R-Car M3-
>>>>>>>> W.
>>>>>>>>>>>
>>>>>>>>>>>> architectures and 5 platforms. In two months.
>>>>>>>>>>>
>>>>>>>>>>> That sounds like great progress, thanks a lot!
>>>>>>>>>>>
>>>>>>>>>> Geert,
>>>>>>>>>>
>>>>>>>>>>> Where can I find these firmwares? Linux-firmware[1]
>>>>>>>>>>> seems to lack all but the original K3 AM62x one.
>>>>>>>>>>
>>>>>>>>>> I think PowerVR has a repo [1], but the last time I
>>>>>>>>>> checked it, the BVNC for the firmware didn't match what
>>>>>>>>>> was necessary for the GX6250 on the RZ/G2M.  I can't
>>>>>>>>>> remember what the corresponding R-Car3 model is.  I
>>>>>>>>>> haven't tried recently because I was told more
>>>>>>>>>> documentation for firmware porting would be delayed until
>>> everything was pushed into the kernel and Mesa.
>>>>>>>>>> Maybe there is a better repo and/or newer firmware somewhere
>>> else.
>>>>>>>>>>
>>>>>>>>> I should have doubled checked the repo contents before I
>>>>>>>>> sent my last e-mail , but it appears the firmware  [2] for
>>>>>>>>> the RZ/G2M, might be present now. I don't know if there are
>>>>>>>>> driver updates necessary. I checked my e-mails, but I didn't
>>>>>>>>> see any notification, or I would have tried it earlier.
>>>>>>>>> Either way, thank you Frank for adding it.  I'll try to test
>>> when I have some time.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't have the proper version of Mesa setup yet, but for
>>>>>>>> what it's worth, the firmware loads without error, and it
>>> doesn't hang.
>>>>>>>
>>>>>>> Based on [1] and [2],
>>>>>>>
>>>>>>> kmscube should work on R-Car as it works on RZ/G2L with panfrost
>>>>>>> as earlier version of RZ/G2L which uses drm based on RCar-Du,
>>>>>>> later changed
>>>>>> to rzg2l-du.
>>>>>>
>>>>>> IIRC, the mesa support isn't there yet for kmscube to start.
>>>>>
>>>>> What about glmark2? I tested glmark2 as well.
>>>>
>>>> It's not really a matter of kmscube itself, but the interaction with
>>>> the compositor entirely. You can run a headless vulkan rendering, but
>>>> an application that renders to a window won't work.
>>>
>>> I have made a little progress.  I have Ubuntu running on an RZ/G2M (Rogue
>>> GX6250) with a device tree configuring the GPU and the GPU loads with
>>> firmware.
>>>
>>>   powervr fd000000.gpu: [drm] loaded firmware
>>> powervr/rogue_4.45.2.58_v1.fw
>>>   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
>>>   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
>>>
>>> drmdevice lists card0 and renderD128
>>> --- Checking the number of DRM device available ---
>>> --- Devices reported 2 ---
>>> --- Retrieving devices information (PCI device revision is ignored) ---
>>> device[0]
>>> +-> available_nodes 0x05
>>> +-> nodes
>>> |   +-> nodes[0] /dev/dri/card0
>>> |   +-> nodes[2] /dev/dri/renderD128
>>> +-> bustype 0002
>>> |   +-> platform
>>> |       +-> fullname /soc/gpu@fd000000
>>> +-> deviceinfo
>>>     +-> platform
>>>         +-> compatible
>>>                     renesas,r8a774a1-gpu
>>>                     img,img-axe
>>>
>>> There is more to this dump, but it seems to repeat. I wanted to show that
>>> it seems like it's trying to work.
>>>
>>> I think I need to modify the powervr code in mesa to recognize the
>>> renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not sure,
>>> and I am hoping someone might be able to provide some guidance, since I
>>> think I am missing something somewhere. I modified pvr_device.c in the
>>> mesa driver to attempt do this:
>>>
>>> /* This is the list of supported DRM render/display driver configs. */
>>> static const struct pvr_drm_device_config pvr_drm_configs[] = {
>>>    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
>>>    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
>>>    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"), };
>>>
>>> When I run modetest -M rcar-du, I can see the encoders and connectors and
>>> I can display test patterns, so the rcar-du is working.
>>>
>>> I built Mesa 24.0.1 with the following options:
>>>
>>> meson setup builddir -Dvulkan-drivers=imagination-experimental
>>> -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
>>>
>>> I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
>>> documentation for the powerVR, and I have exported the variable for
>>> VK_ICD_FILENAMES to point to the powervr json file.
>>>
>>> when I try to run glmark2-drm, I was expecting the GL reddered to be the
>>> powervr, but it keeps using the
>>> GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
>>>
>>> I realize this driver is still in its infancy, but I was hoping someone
>>> could give me some guidance to let me know if the work to do is on the
>>> Mesa side or the rcar-du driver side, or something else.
>>>
>>> I rebuilt both libdrm and mesa.  While I don't get any errors, I also
>>> don't get the hardware acceleration I was hoping for.
>>>
>>> I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
>>> MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
>>>
>>> ...but it only renders with llvmpipe
>>>
>>>     glmark2 2023.01
>>> =======================================================
>>>     OpenGL Information
>>>     GL_VENDOR:      Mesa
>>>     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
>>>     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
>>>     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
>>>     Surface Size:   3840x2160 fullscreen
>>>
>>>
>>> I am not as familiar with the Mesa side, but if I can get this working to
>>> a point where something is rendered, even if it's not 100% compliant, I'd
>>> like to push patches to the kernel and/or Mesa if necessary.
>>
>> FYI, the glmark2 I tested on RZ/G2L with panfrost is with wayland window system [1].
>>
>> Maybe there should be an panfrost equivalent package for powevr is available in mesa??
>> That is the only difference w.r.to panfrost.
>>
>> PACKAGECONFIG_append_pn-mesa = " egl kmsro panfrost"
>>
> 
> I am not using Yocto, because I am using Ubuntu, but I have build Mesa
> per the instructions they provided, but the glue that connects the
> powervr to the rcar-du isn't as clear.  I looked at the panfrost
> implementation, but I didn't see anything obvious.   It looks like the
> panfrost integrates with the kms driver, which I was rather expecting
> powervr would do.  I can tell the mesa library is build built and
> loaded but it's not attempting to use it for some reason
> 
> The GX6250 that is supported looks like it needs some additional
> look-up-tables added to src/imagination/common/pvr_device_info.c
> inside Mesa because the LUT they have is for a different BVNC despite
> the firmware for the BVNC being posted.  I'll have to see if I can
> find documentation for the the features that are enabled or not within
> this variant of the the GX6250.

You can find device info for some devices which are not fully supported
(yet) in [2], including what I think should be the GX6250 you’re looking
at. I’m not sure how up to date that branch’s base is, so probably best
to cherry-pick the change(s) you need.

Matt

[2]: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/devinfo

> adam
> 
>>
>> [1] https://renesas.info/wiki/RZ-G/Panfrost_for_RZG2L
>>
>>
>> Cheers,
>> Biju
>>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Matt Coster]

[-- Attachment #1.1: Type: text/plain, Size: 8109 bytes --]

Hi Adam,

On 18/02/2024 23:26, Adam Ford wrote:
> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
>>
>> On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
>>> Hi Maxime Ripard,
>>>
>>>> -----Original Message-----
>>>> From: Maxime Ripard <mripard@kernel.org>
>>>> Sent: Friday, February 16, 2024 9:05 AM
>>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
>>>> ARCH_K3
>>>>
>>>> On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
>>>>> Hi Adam Ford,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Adam Ford <aford173@gmail.com>
>>>>>> Sent: Thursday, February 15, 2024 11:36 PM
>>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
>>>>>> on
>>>>>> ARCH_K3
>>>>>>
>>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
>>>>>>>
>>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
>>>> wrote:
>>>>>>>>
>>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
>>>>>>>> <geert@linux-m68k.org> wrote:
>>>>>>>>>
>>>>>>>>> Hi Maxime,
>>>>>>>>>
>>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
>>>>>>>>> <mripard@kernel.org>
>>>>>> wrote:
>>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
>>>>>> wrote:
>>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU
>>>>>>>>>>> requires a proprietary firmware image, which is currently
>>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs.  Hence
>>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user
>>>>>>>>>>> about this driver when configuring a kernel without Texas
>>>>>>>>>>> Instruments K3
>>>>>> Multicore SoC support.
>>>>>>>>>>
>>>>>>>>>> This wasn't making sense the first time you sent it, and now
>>>>>>>>>> that commit log is just plain wrong. We have firmwares for
>>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
>>>>>>>>>> which can be found on (at least) Renesas, Mediatek,
>>>>>>>>>> Rockchip, TI and StarFive, so across three
>>>>>>>>>
>>>>>>>>> I am so happy to be proven wrong!
>>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
>>>>>>>>> R-Car M3-
>>>>>> W.
>>>>>>>>>
>>>>>>>>>> architectures and 5 platforms. In two months.
>>>>>>>>>
>>>>>>>>> That sounds like great progress, thanks a lot!
>>>>>>>>>
>>>>>>>> Geert,
>>>>>>>>
>>>>>>>>> Where can I find these firmwares? Linux-firmware[1] seems to
>>>>>>>>> lack all but the original K3 AM62x one.
>>>>>>>>
>>>>>>>> I think PowerVR has a repo [1], but the last time I checked it,
>>>>>>>> the BVNC for the firmware didn't match what was necessary for
>>>>>>>> the GX6250 on the RZ/G2M.  I can't remember what the
>>>>>>>> corresponding R-Car3 model is.  I haven't tried recently because
>>>>>>>> I was told more documentation for firmware porting would be
>>>>>>>> delayed until everything was pushed into the kernel and Mesa.
>>>>>>>> Maybe there is a better repo and/or newer firmware somewhere else.
>>>>>>>>
>>>>>>> I should have doubled checked the repo contents before I sent my
>>>>>>> last e-mail , but it appears the firmware  [2] for the RZ/G2M,
>>>>>>> might be present now. I don't know if there are driver updates
>>>>>>> necessary. I checked my e-mails, but I didn't see any
>>>>>>> notification, or I would have tried it earlier.  Either way, thank
>>>>>>> you Frank for adding it.  I'll try to test when I have some time.
>>>>>>>
>>>>>>
>>>>>> I don't have the proper version of Mesa setup yet, but for what it's
>>>>>> worth, the firmware loads without error, and it doesn't hang.
>>>>>
>>>>> Based on [1] and [2],
>>>>>
>>>>> kmscube should work on R-Car as it works on RZ/G2L with panfrost as
>>>>> earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
>>>> to rzg2l-du.
>>>>
>>>> IIRC, the mesa support isn't there yet for kmscube to start.
>>>
>>> What about glmark2? I tested glmark2 as well.
>>
>> It's not really a matter of kmscube itself, but the interaction with the
>> compositor entirely. You can run a headless vulkan rendering, but an
>> application that renders to a window won't work.
> 
> I have made a little progress.  I have Ubuntu running on an RZ/G2M
> (Rogue GX6250) with a device tree configuring the GPU and the GPU
> loads with firmware.
> 
>   powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
>   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
>   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> 
> drmdevice lists card0 and renderD128
> --- Checking the number of DRM device available ---
> --- Devices reported 2 ---
> --- Retrieving devices information (PCI device revision is ignored) ---
> device[0]
> +-> available_nodes 0x05
> +-> nodes
> |   +-> nodes[0] /dev/dri/card0
> |   +-> nodes[2] /dev/dri/renderD128
> +-> bustype 0002
> |   +-> platform
> |       +-> fullname /soc/gpu@fd000000
> +-> deviceinfo
>     +-> platform
>         +-> compatible
>                     renesas,r8a774a1-gpu
>                     img,img-axe
> 
> There is more to this dump, but it seems to repeat. I wanted to show
> that it seems like it's trying to work.
> 
> I think I need to modify the powervr code in mesa to recognize the
> renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not
> sure, and I am hoping someone might be able to provide some guidance,
> since I think I am missing something somewhere. I modified
> pvr_device.c in the mesa driver to attempt do this:
> 
> /* This is the list of supported DRM render/display driver configs. */
> static const struct pvr_drm_device_config pvr_drm_configs[] = {
>    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
>    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
>    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"),
> };
> 
> When I run modetest -M rcar-du, I can see the encoders and connectors
> and I can display test patterns, so the rcar-du is working.
> 
> I built Mesa 24.0.1 with the following options:
> 
> meson setup builddir -Dvulkan-drivers=imagination-experimental
> -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> 
> I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> documentation for the powerVR, and I have exported the variable for
> VK_ICD_FILENAMES to point to the powervr json file.
> 
> when I try to run glmark2-drm, I was expecting the GL reddered to be
> the powervr, but it keeps using the
> GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> 
> I realize this driver is still in its infancy, but I was hoping
> someone could give me some guidance to let me know if the work to do
> is on the Mesa side or the rcar-du driver side, or something else.
> 
> I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> don't get the hardware acceleration I was hoping for.
> 
> I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> 
> ...but it only renders with llvmpipe
> 
>     glmark2 2023.01
> =======================================================
>     OpenGL Information
>     GL_VENDOR:      Mesa
>     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
>     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
>     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
>     Surface Size:   3840x2160 fullscreen
> 
> 
> I am not as familiar with the Mesa side, but if I can get this working
> to a point where something is rendered, even if it's not 100%
> compliant, I'd like to push patches to the kernel and/or Mesa if
> necessary.
> 
> adam
> 
> 
> 
> 
>>
>> Maxime

I suggest you try running Vulkan demos (we use Sascha Willems’ [1])
instead of GL at this stage. Support for Zink is currently under heavy
development so you may have trouble differentiating between issues with
your kernel changes and the incompleteness in Mesa.

Matt

[1]: https://github.com/SaschaWillems/Vulkan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Mon, Feb 19, 2024 at 3:00 AM Matt Coster <Matt.Coster@imgtec.com> wrote:
>
> Hi Adam,
>
> On 18/02/2024 23:26, Adam Ford wrote:
> > On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
> >>
> >> On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> >>> Hi Maxime Ripard,
> >>>
> >>>> -----Original Message-----
> >>>> From: Maxime Ripard <mripard@kernel.org>
> >>>> Sent: Friday, February 16, 2024 9:05 AM
> >>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> >>>> ARCH_K3
> >>>>
> >>>> On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> >>>>> Hi Adam Ford,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Adam Ford <aford173@gmail.com>
> >>>>>> Sent: Thursday, February 15, 2024 11:36 PM
> >>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> >>>>>> on
> >>>>>> ARCH_K3
> >>>>>>
> >>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> >>>>>>>
> >>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> >>>>>>>> <geert@linux-m68k.org> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi Maxime,
> >>>>>>>>>
> >>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> >>>>>>>>> <mripard@kernel.org>
> >>>>>> wrote:
> >>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> >>>>>> wrote:
> >>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU
> >>>>>>>>>>> requires a proprietary firmware image, which is currently
> >>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs.  Hence
> >>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user
> >>>>>>>>>>> about this driver when configuring a kernel without Texas
> >>>>>>>>>>> Instruments K3
> >>>>>> Multicore SoC support.
> >>>>>>>>>>
> >>>>>>>>>> This wasn't making sense the first time you sent it, and now
> >>>>>>>>>> that commit log is just plain wrong. We have firmwares for
> >>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
> >>>>>>>>>> which can be found on (at least) Renesas, Mediatek,
> >>>>>>>>>> Rockchip, TI and StarFive, so across three
> >>>>>>>>>
> >>>>>>>>> I am so happy to be proven wrong!
> >>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> >>>>>>>>> R-Car M3-
> >>>>>> W.
> >>>>>>>>>
> >>>>>>>>>> architectures and 5 platforms. In two months.
> >>>>>>>>>
> >>>>>>>>> That sounds like great progress, thanks a lot!
> >>>>>>>>>
> >>>>>>>> Geert,
> >>>>>>>>
> >>>>>>>>> Where can I find these firmwares? Linux-firmware[1] seems to
> >>>>>>>>> lack all but the original K3 AM62x one.
> >>>>>>>>
> >>>>>>>> I think PowerVR has a repo [1], but the last time I checked it,
> >>>>>>>> the BVNC for the firmware didn't match what was necessary for
> >>>>>>>> the GX6250 on the RZ/G2M.  I can't remember what the
> >>>>>>>> corresponding R-Car3 model is.  I haven't tried recently because
> >>>>>>>> I was told more documentation for firmware porting would be
> >>>>>>>> delayed until everything was pushed into the kernel and Mesa.
> >>>>>>>> Maybe there is a better repo and/or newer firmware somewhere else.
> >>>>>>>>
> >>>>>>> I should have doubled checked the repo contents before I sent my
> >>>>>>> last e-mail , but it appears the firmware  [2] for the RZ/G2M,
> >>>>>>> might be present now. I don't know if there are driver updates
> >>>>>>> necessary. I checked my e-mails, but I didn't see any
> >>>>>>> notification, or I would have tried it earlier.  Either way, thank
> >>>>>>> you Frank for adding it.  I'll try to test when I have some time.
> >>>>>>>
> >>>>>>
> >>>>>> I don't have the proper version of Mesa setup yet, but for what it's
> >>>>>> worth, the firmware loads without error, and it doesn't hang.
> >>>>>
> >>>>> Based on [1] and [2],
> >>>>>
> >>>>> kmscube should work on R-Car as it works on RZ/G2L with panfrost as
> >>>>> earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
> >>>> to rzg2l-du.
> >>>>
> >>>> IIRC, the mesa support isn't there yet for kmscube to start.
> >>>
> >>> What about glmark2? I tested glmark2 as well.
> >>
> >> It's not really a matter of kmscube itself, but the interaction with the
> >> compositor entirely. You can run a headless vulkan rendering, but an
> >> application that renders to a window won't work.
> >
> > I have made a little progress.  I have Ubuntu running on an RZ/G2M
> > (Rogue GX6250) with a device tree configuring the GPU and the GPU
> > loads with firmware.
> >
> >   powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> >   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
> >   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> >
> > drmdevice lists card0 and renderD128
> > --- Checking the number of DRM device available ---
> > --- Devices reported 2 ---
> > --- Retrieving devices information (PCI device revision is ignored) ---
> > device[0]
> > +-> available_nodes 0x05
> > +-> nodes
> > |   +-> nodes[0] /dev/dri/card0
> > |   +-> nodes[2] /dev/dri/renderD128
> > +-> bustype 0002
> > |   +-> platform
> > |       +-> fullname /soc/gpu@fd000000
> > +-> deviceinfo
> >     +-> platform
> >         +-> compatible
> >                     renesas,r8a774a1-gpu
> >                     img,img-axe
> >
> > There is more to this dump, but it seems to repeat. I wanted to show
> > that it seems like it's trying to work.
> >
> > I think I need to modify the powervr code in mesa to recognize the
> > renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not
> > sure, and I am hoping someone might be able to provide some guidance,
> > since I think I am missing something somewhere. I modified
> > pvr_device.c in the mesa driver to attempt do this:
> >
> > /* This is the list of supported DRM render/display driver configs. */
> > static const struct pvr_drm_device_config pvr_drm_configs[] = {
> >    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
> >    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
> >    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"),
> > };
> >
> > When I run modetest -M rcar-du, I can see the encoders and connectors
> > and I can display test patterns, so the rcar-du is working.
> >
> > I built Mesa 24.0.1 with the following options:
> >
> > meson setup builddir -Dvulkan-drivers=imagination-experimental
> > -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> >
> > I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> > documentation for the powerVR, and I have exported the variable for
> > VK_ICD_FILENAMES to point to the powervr json file.
> >
> > when I try to run glmark2-drm, I was expecting the GL reddered to be
> > the powervr, but it keeps using the
> > GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> >
> > I realize this driver is still in its infancy, but I was hoping
> > someone could give me some guidance to let me know if the work to do
> > is on the Mesa side or the rcar-du driver side, or something else.
> >
> > I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> > don't get the hardware acceleration I was hoping for.
> >
> > I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> > MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> >
> > ...but it only renders with llvmpipe
> >
> >     glmark2 2023.01
> > =======================================================
> >     OpenGL Information
> >     GL_VENDOR:      Mesa
> >     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> >     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
> >     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
> >     Surface Size:   3840x2160 fullscreen
> >
> >
> > I am not as familiar with the Mesa side, but if I can get this working
> > to a point where something is rendered, even if it's not 100%
> > compliant, I'd like to push patches to the kernel and/or Mesa if
> > necessary.
> >
> > adam
> >
> >
> >
> >
> >>
> >> Maxime
>
> I suggest you try running Vulkan demos (we use Sascha Willems’ [1])
> instead of GL at this stage. Support for Zink is currently under heavy
> development so you may have trouble differentiating between issues with
> your kernel changes and the incompleteness in Mesa.

I hacked the look-up-tables in the Mesa PowerVR driver to match the
values of the other GX6250. I know there must be some minor
differences, but I don't know what they are right now.
I also had to tweak   src/imagination/vulkan/pvr_device.c again to the
following:
  DEF_CONFIG("renesas,r8a774a1-gpu", "renesas,du-r8a774a1"),

I am not positive that is the correct thing to do, but with that, I
can now run vulkaninfo.
I know that it's not fully Vulkan compliant yet, but it appears there
is some progress:

Layers: count = 2
=================
VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan
version 1.3.211, layer version 1:
        Layer Extensions: count = 0
        Devices: count = 2
                GPU id = 0 (Imagination PowerVR Rogue GX6250)
                Layer-Device Extensions: count = 0

                GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
                Layer-Device Extensions: count = 0

VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.3.211,
layer version 1:
        Layer Extensions: count = 0
        Devices: count = 2
                GPU id = 0 (Imagination PowerVR Rogue GX6250)
                Layer-Device Extensions: count = 0

                GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
                Layer-Device Extensions: count = 0


I then tried to redndr with vkgears, but it didn't redner.  When I run
vkgears, I get the following:

LAYER:            Searching for layer manifest files
LAYER:               In following locations:
LAYER:                  /home/aford/.config/vulkan/implicit_layer.d
LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/implicit_layer.d
LAYER:                  /etc/xdg/vulkan/implicit_layer.d
LAYER:                  /etc/vulkan/implicit_layer.d
LAYER:                  /home/aford/.local/share/vulkan/implicit_layer.d
LAYER:                  /usr/share/ubuntu/vulkan/implicit_layer.d
LAYER:                  /usr/share/gnome/vulkan/implicit_layer.d
LAYER:                  /usr/local/share/vulkan/implicit_layer.d
LAYER:                  /usr/share/vulkan/implicit_layer.d
LAYER:                  /var/lib/snapd/desktop/vulkan/implicit_layer.d
LAYER:               Found the following files:
LAYER:
/usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json
LAYER:            Searching for layer manifest files
LAYER:               In following locations:
LAYER:                  /home/aford/.config/vulkan/explicit_layer.d
LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/explicit_layer.d
LAYER:                  /etc/xdg/vulkan/explicit_layer.d
LAYER:                  /etc/vulkan/explicit_layer.d
LAYER:                  /home/aford/.local/share/vulkan/explicit_layer.d
LAYER:                  /usr/share/ubuntu/vulkan/explicit_layer.d
LAYER:                  /usr/share/gnome/vulkan/explicit_layer.d
LAYER:                  /usr/local/share/vulkan/explicit_layer.d
LAYER:                  /usr/share/vulkan/explicit_layer.d
LAYER:                  /var/lib/snapd/desktop/vulkan/explicit_layer.d
LAYER:               Found the following files:
LAYER:
/usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
ERROR:            loader_validate_instance_extensions: Instance
extension VK_KHR_wayland_surface not supported by available ICDs or
enabled layers.
Failed to create Vulkan instance.

I have tried running in X.org mode instead of Wayland, but I get a
different set of errors:

[ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 11102.014]    compiled for 1.21.1.7, module version = 0.0.2
[ 11102.014]    ABI class: X.Org Video Driver, version 25.2
[ 11102.015] (II) FBDEV(0): using default device
[ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
[ 11102.016] (EE)
Fatal server error:
or all framebuffer devices
[ 11102.016] (EE)
[ 11102.017] (EE)
Please consult the The X.Org Foundation support at http://wiki.x.org  for help.

I think I am close.

adam
>
> Matt
>
> [1]: https://github.com/SaschaWillems/Vulkan

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Matt Coster]

[-- Attachment #1.1: Type: text/plain, Size: 13459 bytes --]

Hi Adam,

On 19/02/2024 20:38, Adam Ford wrote:
> On Mon, Feb 19, 2024 at 3:00 AM Matt Coster <Matt.Coster@imgtec.com> wrote:
>>
>> Hi Adam,
>>
>> On 18/02/2024 23:26, Adam Ford wrote:
>>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
>>>>
>>>> On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
>>>>> Hi Maxime Ripard,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Maxime Ripard <mripard@kernel.org>
>>>>>> Sent: Friday, February 16, 2024 9:05 AM
>>>>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
>>>>>> ARCH_K3
>>>>>>
>>>>>> On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
>>>>>>> Hi Adam Ford,
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Adam Ford <aford173@gmail.com>
>>>>>>>> Sent: Thursday, February 15, 2024 11:36 PM
>>>>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
>>>>>>>> on
>>>>>>>> ARCH_K3
>>>>>>>>
>>>>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
>>>>>>>>>> <geert@linux-m68k.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Maxime,
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
>>>>>>>>>>> <mripard@kernel.org>
>>>>>>>> wrote:
>>>>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
>>>>>>>> wrote:
>>>>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU
>>>>>>>>>>>>> requires a proprietary firmware image, which is currently
>>>>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs.  Hence
>>>>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user
>>>>>>>>>>>>> about this driver when configuring a kernel without Texas
>>>>>>>>>>>>> Instruments K3
>>>>>>>> Multicore SoC support.
>>>>>>>>>>>>
>>>>>>>>>>>> This wasn't making sense the first time you sent it, and now
>>>>>>>>>>>> that commit log is just plain wrong. We have firmwares for
>>>>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
>>>>>>>>>>>> which can be found on (at least) Renesas, Mediatek,
>>>>>>>>>>>> Rockchip, TI and StarFive, so across three
>>>>>>>>>>>
>>>>>>>>>>> I am so happy to be proven wrong!
>>>>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
>>>>>>>>>>> R-Car M3-
>>>>>>>> W.
>>>>>>>>>>>
>>>>>>>>>>>> architectures and 5 platforms. In two months.
>>>>>>>>>>>
>>>>>>>>>>> That sounds like great progress, thanks a lot!
>>>>>>>>>>>
>>>>>>>>>> Geert,
>>>>>>>>>>
>>>>>>>>>>> Where can I find these firmwares? Linux-firmware[1] seems to
>>>>>>>>>>> lack all but the original K3 AM62x one.
>>>>>>>>>>
>>>>>>>>>> I think PowerVR has a repo [1], but the last time I checked it,
>>>>>>>>>> the BVNC for the firmware didn't match what was necessary for
>>>>>>>>>> the GX6250 on the RZ/G2M.  I can't remember what the
>>>>>>>>>> corresponding R-Car3 model is.  I haven't tried recently because
>>>>>>>>>> I was told more documentation for firmware porting would be
>>>>>>>>>> delayed until everything was pushed into the kernel and Mesa.
>>>>>>>>>> Maybe there is a better repo and/or newer firmware somewhere else.
>>>>>>>>>>
>>>>>>>>> I should have doubled checked the repo contents before I sent my
>>>>>>>>> last e-mail , but it appears the firmware  [2] for the RZ/G2M,
>>>>>>>>> might be present now. I don't know if there are driver updates
>>>>>>>>> necessary. I checked my e-mails, but I didn't see any
>>>>>>>>> notification, or I would have tried it earlier.  Either way, thank
>>>>>>>>> you Frank for adding it.  I'll try to test when I have some time.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I don't have the proper version of Mesa setup yet, but for what it's
>>>>>>>> worth, the firmware loads without error, and it doesn't hang.
>>>>>>>
>>>>>>> Based on [1] and [2],
>>>>>>>
>>>>>>> kmscube should work on R-Car as it works on RZ/G2L with panfrost as
>>>>>>> earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
>>>>>> to rzg2l-du.
>>>>>>
>>>>>> IIRC, the mesa support isn't there yet for kmscube to start.
>>>>>
>>>>> What about glmark2? I tested glmark2 as well.
>>>>
>>>> It's not really a matter of kmscube itself, but the interaction with the
>>>> compositor entirely. You can run a headless vulkan rendering, but an
>>>> application that renders to a window won't work.
>>>
>>> I have made a little progress.  I have Ubuntu running on an RZ/G2M
>>> (Rogue GX6250) with a device tree configuring the GPU and the GPU
>>> loads with firmware.
>>>
>>>   powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
>>>   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
>>>   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
>>>
>>> drmdevice lists card0 and renderD128
>>> --- Checking the number of DRM device available ---
>>> --- Devices reported 2 ---
>>> --- Retrieving devices information (PCI device revision is ignored) ---
>>> device[0]
>>> +-> available_nodes 0x05
>>> +-> nodes
>>> |   +-> nodes[0] /dev/dri/card0
>>> |   +-> nodes[2] /dev/dri/renderD128
>>> +-> bustype 0002
>>> |   +-> platform
>>> |       +-> fullname /soc/gpu@fd000000
>>> +-> deviceinfo
>>>     +-> platform
>>>         +-> compatible
>>>                     renesas,r8a774a1-gpu
>>>                     img,img-axe
>>>
>>> There is more to this dump, but it seems to repeat. I wanted to show
>>> that it seems like it's trying to work.
>>>
>>> I think I need to modify the powervr code in mesa to recognize the
>>> renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not
>>> sure, and I am hoping someone might be able to provide some guidance,
>>> since I think I am missing something somewhere. I modified
>>> pvr_device.c in the mesa driver to attempt do this:
>>>
>>> /* This is the list of supported DRM render/display driver configs. */
>>> static const struct pvr_drm_device_config pvr_drm_configs[] = {
>>>    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
>>>    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
>>>    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"),
>>> };
>>>
>>> When I run modetest -M rcar-du, I can see the encoders and connectors
>>> and I can display test patterns, so the rcar-du is working.
>>>
>>> I built Mesa 24.0.1 with the following options:
>>>
>>> meson setup builddir -Dvulkan-drivers=imagination-experimental
>>> -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
>>>
>>> I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
>>> documentation for the powerVR, and I have exported the variable for
>>> VK_ICD_FILENAMES to point to the powervr json file.
>>>
>>> when I try to run glmark2-drm, I was expecting the GL reddered to be
>>> the powervr, but it keeps using the
>>> GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
>>>
>>> I realize this driver is still in its infancy, but I was hoping
>>> someone could give me some guidance to let me know if the work to do
>>> is on the Mesa side or the rcar-du driver side, or something else.
>>>
>>> I rebuilt both libdrm and mesa.  While I don't get any errors, I also
>>> don't get the hardware acceleration I was hoping for.
>>>
>>> I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
>>> MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
>>>
>>> ...but it only renders with llvmpipe
>>>
>>>     glmark2 2023.01
>>> =======================================================
>>>     OpenGL Information
>>>     GL_VENDOR:      Mesa
>>>     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
>>>     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
>>>     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
>>>     Surface Size:   3840x2160 fullscreen
>>>
>>>
>>> I am not as familiar with the Mesa side, but if I can get this working
>>> to a point where something is rendered, even if it's not 100%
>>> compliant, I'd like to push patches to the kernel and/or Mesa if
>>> necessary.
>>>
>>> adam
>>>
>>>
>>>
>>>
>>>>
>>>> Maxime
>>
>> I suggest you try running Vulkan demos (we use Sascha Willems’ [1])
>> instead of GL at this stage. Support for Zink is currently under heavy
>> development so you may have trouble differentiating between issues with
>> your kernel changes and the incompleteness in Mesa.
> 
> I hacked the look-up-tables in the Mesa PowerVR driver to match the
> values of the other GX6250. I know there must be some minor
> differences, but I don't know what they are right now.

In case you missed my other email, we have device info for the GX6250
variant you’re using in [2]. I’ve been informed that branch should be
usable as-is – can you give that a try?

> I also had to tweak   src/imagination/vulkan/pvr_device.c again to the
> following:
>   DEF_CONFIG("renesas,r8a774a1-gpu", "renesas,du-r8a774a1"),

Ah yes, not perfectly as-is then. These lines (pvr_drm_configs) declare
the pairing of GPU to display hardware. You’ll still need this tweak.

> I am not positive that is the correct thing to do, but with that, I
> can now run vulkaninfo.
> I know that it's not fully Vulkan compliant yet, but it appears there
> is some progress:
> 
> Layers: count = 2
> =================
> VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan
> version 1.3.211, layer version 1:
>         Layer Extensions: count = 0
>         Devices: count = 2
>                 GPU id = 0 (Imagination PowerVR Rogue GX6250)
>                 Layer-Device Extensions: count = 0
> 
>                 GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
>                 Layer-Device Extensions: count = 0
> 
> VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.3.211,
> layer version 1:
>         Layer Extensions: count = 0
>         Devices: count = 2
>                 GPU id = 0 (Imagination PowerVR Rogue GX6250)
>                 Layer-Device Extensions: count = 0
> 
>                 GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
>                 Layer-Device Extensions: count = 0
> 
> 
> I then tried to redndr with vkgears, but it didn't redner.  When I run
> vkgears, I get the following:
> 
> LAYER:            Searching for layer manifest files
> LAYER:               In following locations:
> LAYER:                  /home/aford/.config/vulkan/implicit_layer.d
> LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/implicit_layer.d
> LAYER:                  /etc/xdg/vulkan/implicit_layer.d
> LAYER:                  /etc/vulkan/implicit_layer.d
> LAYER:                  /home/aford/.local/share/vulkan/implicit_layer.d
> LAYER:                  /usr/share/ubuntu/vulkan/implicit_layer.d
> LAYER:                  /usr/share/gnome/vulkan/implicit_layer.d
> LAYER:                  /usr/local/share/vulkan/implicit_layer.d
> LAYER:                  /usr/share/vulkan/implicit_layer.d
> LAYER:                  /var/lib/snapd/desktop/vulkan/implicit_layer.d
> LAYER:               Found the following files:
> LAYER:
> /usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json
> LAYER:            Searching for layer manifest files
> LAYER:               In following locations:
> LAYER:                  /home/aford/.config/vulkan/explicit_layer.d
> LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/explicit_layer.d
> LAYER:                  /etc/xdg/vulkan/explicit_layer.d
> LAYER:                  /etc/vulkan/explicit_layer.d
> LAYER:                  /home/aford/.local/share/vulkan/explicit_layer.d
> LAYER:                  /usr/share/ubuntu/vulkan/explicit_layer.d
> LAYER:                  /usr/share/gnome/vulkan/explicit_layer.d
> LAYER:                  /usr/local/share/vulkan/explicit_layer.d
> LAYER:                  /usr/share/vulkan/explicit_layer.d
> LAYER:                  /var/lib/snapd/desktop/vulkan/explicit_layer.d
> LAYER:               Found the following files:
> LAYER:
> /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> ERROR:            loader_validate_instance_extensions: Instance
> extension VK_KHR_wayland_surface not supported by available ICDs or
> enabled layers.
> Failed to create Vulkan instance.
> 
> I have tried running in X.org mode instead of Wayland, but I get a
> different set of errors:

We haven’t been testing with window systems yet – can you try building
the Sascha Willems demos [1] with -DUSE_D2D_WSI=ON and try running
triangle?

Matt

[2]: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/devinfo

> [ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> [ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
> [ 11102.014]    compiled for 1.21.1.7, module version = 0.0.2
> [ 11102.014]    ABI class: X.Org Video Driver, version 25.2
> [ 11102.015] (II) FBDEV(0): using default device
> [ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
> [ 11102.016] (EE)
> Fatal server error:
> or all framebuffer devices
> [ 11102.016] (EE)
> [ 11102.017] (EE)
> Please consult the The X.Org Foundation support at http://wiki.x.org  for help.
> 
> I think I am close.
> 
> adam
>>
>> Matt
>>
>> [1]: https://github.com/SaschaWillems/Vulkan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Tue, Feb 20, 2024 at 3:21 AM Matt Coster <Matt.Coster@imgtec.com> wrote:
>
> Hi Adam,
>
> On 19/02/2024 20:38, Adam Ford wrote:
> > On Mon, Feb 19, 2024 at 3:00 AM Matt Coster <Matt.Coster@imgtec.com> wrote:
> >>
> >> Hi Adam,
> >>
> >> On 18/02/2024 23:26, Adam Ford wrote:
> >>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
> >>>>
> >>>> On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> >>>>> Hi Maxime Ripard,
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Maxime Ripard <mripard@kernel.org>
> >>>>>> Sent: Friday, February 16, 2024 9:05 AM
> >>>>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> >>>>>> ARCH_K3
> >>>>>>
> >>>>>> On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> >>>>>>> Hi Adam Ford,
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Adam Ford <aford173@gmail.com>
> >>>>>>>> Sent: Thursday, February 15, 2024 11:36 PM
> >>>>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> >>>>>>>> on
> >>>>>>>> ARCH_K3
> >>>>>>>>
> >>>>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
> >>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> >>>>>>>>>> <geert@linux-m68k.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi Maxime,
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> >>>>>>>>>>> <mripard@kernel.org>
> >>>>>>>> wrote:
> >>>>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> >>>>>>>> wrote:
> >>>>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU
> >>>>>>>>>>>>> requires a proprietary firmware image, which is currently
> >>>>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs.  Hence
> >>>>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user
> >>>>>>>>>>>>> about this driver when configuring a kernel without Texas
> >>>>>>>>>>>>> Instruments K3
> >>>>>>>> Multicore SoC support.
> >>>>>>>>>>>>
> >>>>>>>>>>>> This wasn't making sense the first time you sent it, and now
> >>>>>>>>>>>> that commit log is just plain wrong. We have firmwares for
> >>>>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
> >>>>>>>>>>>> which can be found on (at least) Renesas, Mediatek,
> >>>>>>>>>>>> Rockchip, TI and StarFive, so across three
> >>>>>>>>>>>
> >>>>>>>>>>> I am so happy to be proven wrong!
> >>>>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> >>>>>>>>>>> R-Car M3-
> >>>>>>>> W.
> >>>>>>>>>>>
> >>>>>>>>>>>> architectures and 5 platforms. In two months.
> >>>>>>>>>>>
> >>>>>>>>>>> That sounds like great progress, thanks a lot!
> >>>>>>>>>>>
> >>>>>>>>>> Geert,
> >>>>>>>>>>
> >>>>>>>>>>> Where can I find these firmwares? Linux-firmware[1] seems to
> >>>>>>>>>>> lack all but the original K3 AM62x one.
> >>>>>>>>>>
> >>>>>>>>>> I think PowerVR has a repo [1], but the last time I checked it,
> >>>>>>>>>> the BVNC for the firmware didn't match what was necessary for
> >>>>>>>>>> the GX6250 on the RZ/G2M.  I can't remember what the
> >>>>>>>>>> corresponding R-Car3 model is.  I haven't tried recently because
> >>>>>>>>>> I was told more documentation for firmware porting would be
> >>>>>>>>>> delayed until everything was pushed into the kernel and Mesa.
> >>>>>>>>>> Maybe there is a better repo and/or newer firmware somewhere else.
> >>>>>>>>>>
> >>>>>>>>> I should have doubled checked the repo contents before I sent my
> >>>>>>>>> last e-mail , but it appears the firmware  [2] for the RZ/G2M,
> >>>>>>>>> might be present now. I don't know if there are driver updates
> >>>>>>>>> necessary. I checked my e-mails, but I didn't see any
> >>>>>>>>> notification, or I would have tried it earlier.  Either way, thank
> >>>>>>>>> you Frank for adding it.  I'll try to test when I have some time.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> I don't have the proper version of Mesa setup yet, but for what it's
> >>>>>>>> worth, the firmware loads without error, and it doesn't hang.
> >>>>>>>
> >>>>>>> Based on [1] and [2],
> >>>>>>>
> >>>>>>> kmscube should work on R-Car as it works on RZ/G2L with panfrost as
> >>>>>>> earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
> >>>>>> to rzg2l-du.
> >>>>>>
> >>>>>> IIRC, the mesa support isn't there yet for kmscube to start.
> >>>>>
> >>>>> What about glmark2? I tested glmark2 as well.
> >>>>
> >>>> It's not really a matter of kmscube itself, but the interaction with the
> >>>> compositor entirely. You can run a headless vulkan rendering, but an
> >>>> application that renders to a window won't work.
> >>>
> >>> I have made a little progress.  I have Ubuntu running on an RZ/G2M
> >>> (Rogue GX6250) with a device tree configuring the GPU and the GPU
> >>> loads with firmware.
> >>>
> >>>   powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> >>>   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
> >>>   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> >>>
> >>> drmdevice lists card0 and renderD128
> >>> --- Checking the number of DRM device available ---
> >>> --- Devices reported 2 ---
> >>> --- Retrieving devices information (PCI device revision is ignored) ---
> >>> device[0]
> >>> +-> available_nodes 0x05
> >>> +-> nodes
> >>> |   +-> nodes[0] /dev/dri/card0
> >>> |   +-> nodes[2] /dev/dri/renderD128
> >>> +-> bustype 0002
> >>> |   +-> platform
> >>> |       +-> fullname /soc/gpu@fd000000
> >>> +-> deviceinfo
> >>>     +-> platform
> >>>         +-> compatible
> >>>                     renesas,r8a774a1-gpu
> >>>                     img,img-axe
> >>>
> >>> There is more to this dump, but it seems to repeat. I wanted to show
> >>> that it seems like it's trying to work.
> >>>
> >>> I think I need to modify the powervr code in mesa to recognize the
> >>> renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not
> >>> sure, and I am hoping someone might be able to provide some guidance,
> >>> since I think I am missing something somewhere. I modified
> >>> pvr_device.c in the mesa driver to attempt do this:
> >>>
> >>> /* This is the list of supported DRM render/display driver configs. */
> >>> static const struct pvr_drm_device_config pvr_drm_configs[] = {
> >>>    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
> >>>    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
> >>>    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"),
> >>> };
> >>>
> >>> When I run modetest -M rcar-du, I can see the encoders and connectors
> >>> and I can display test patterns, so the rcar-du is working.
> >>>
> >>> I built Mesa 24.0.1 with the following options:
> >>>
> >>> meson setup builddir -Dvulkan-drivers=imagination-experimental
> >>> -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> >>>
> >>> I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> >>> documentation for the powerVR, and I have exported the variable for
> >>> VK_ICD_FILENAMES to point to the powervr json file.
> >>>
> >>> when I try to run glmark2-drm, I was expecting the GL reddered to be
> >>> the powervr, but it keeps using the
> >>> GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> >>>
> >>> I realize this driver is still in its infancy, but I was hoping
> >>> someone could give me some guidance to let me know if the work to do
> >>> is on the Mesa side or the rcar-du driver side, or something else.
> >>>
> >>> I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> >>> don't get the hardware acceleration I was hoping for.
> >>>
> >>> I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> >>> MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> >>>
> >>> ...but it only renders with llvmpipe
> >>>
> >>>     glmark2 2023.01
> >>> =======================================================
> >>>     OpenGL Information
> >>>     GL_VENDOR:      Mesa
> >>>     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> >>>     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
> >>>     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
> >>>     Surface Size:   3840x2160 fullscreen
> >>>
> >>>
> >>> I am not as familiar with the Mesa side, but if I can get this working
> >>> to a point where something is rendered, even if it's not 100%
> >>> compliant, I'd like to push patches to the kernel and/or Mesa if
> >>> necessary.
> >>>
> >>> adam
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> Maxime
> >>
> >> I suggest you try running Vulkan demos (we use Sascha Willems’ [1])
> >> instead of GL at this stage. Support for Zink is currently under heavy
> >> development so you may have trouble differentiating between issues with
> >> your kernel changes and the incompleteness in Mesa.
> >
> > I hacked the look-up-tables in the Mesa PowerVR driver to match the
> > values of the other GX6250. I know there must be some minor
> > differences, but I don't know what they are right now.
>
> In case you missed my other email, we have device info for the GX6250
> variant you’re using in [2]. I’ve been informed that branch should be
> usable as-is – can you give that a try?

I did  migrate to the branch you referenced and remove my hacked
lookup-table, but I get similar results.

>
> > I also had to tweak   src/imagination/vulkan/pvr_device.c again to the
> > following:
> >   DEF_CONFIG("renesas,r8a774a1-gpu", "renesas,du-r8a774a1"),
>
> Ah yes, not perfectly as-is then. These lines (pvr_drm_configs) declare
> the pairing of GPU to display hardware. You’ll still need this tweak.
>
> > I am not positive that is the correct thing to do, but with that, I
> > can now run vulkaninfo.
> > I know that it's not fully Vulkan compliant yet, but it appears there
> > is some progress:
> >
> > Layers: count = 2
> > =================
> > VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan
> > version 1.3.211, layer version 1:
> >         Layer Extensions: count = 0
> >         Devices: count = 2
> >                 GPU id = 0 (Imagination PowerVR Rogue GX6250)
> >                 Layer-Device Extensions: count = 0
> >
> >                 GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
> >                 Layer-Device Extensions: count = 0
> >
> > VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.3.211,
> > layer version 1:
> >         Layer Extensions: count = 0
> >         Devices: count = 2
> >                 GPU id = 0 (Imagination PowerVR Rogue GX6250)
> >                 Layer-Device Extensions: count = 0
> >
> >                 GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
> >                 Layer-Device Extensions: count = 0
> >
> >
> > I then tried to redndr with vkgears, but it didn't redner.  When I run
> > vkgears, I get the following:
> >
> > LAYER:            Searching for layer manifest files
> > LAYER:               In following locations:
> > LAYER:                  /home/aford/.config/vulkan/implicit_layer.d
> > LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/implicit_layer.d
> > LAYER:                  /etc/xdg/vulkan/implicit_layer.d
> > LAYER:                  /etc/vulkan/implicit_layer.d
> > LAYER:                  /home/aford/.local/share/vulkan/implicit_layer.d
> > LAYER:                  /usr/share/ubuntu/vulkan/implicit_layer.d
> > LAYER:                  /usr/share/gnome/vulkan/implicit_layer.d
> > LAYER:                  /usr/local/share/vulkan/implicit_layer.d
> > LAYER:                  /usr/share/vulkan/implicit_layer.d
> > LAYER:                  /var/lib/snapd/desktop/vulkan/implicit_layer.d
> > LAYER:               Found the following files:
> > LAYER:
> > /usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json
> > LAYER:            Searching for layer manifest files
> > LAYER:               In following locations:
> > LAYER:                  /home/aford/.config/vulkan/explicit_layer.d
> > LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/explicit_layer.d
> > LAYER:                  /etc/xdg/vulkan/explicit_layer.d
> > LAYER:                  /etc/vulkan/explicit_layer.d
> > LAYER:                  /home/aford/.local/share/vulkan/explicit_layer.d
> > LAYER:                  /usr/share/ubuntu/vulkan/explicit_layer.d
> > LAYER:                  /usr/share/gnome/vulkan/explicit_layer.d
> > LAYER:                  /usr/local/share/vulkan/explicit_layer.d
> > LAYER:                  /usr/share/vulkan/explicit_layer.d
> > LAYER:                  /var/lib/snapd/desktop/vulkan/explicit_layer.d
> > LAYER:               Found the following files:
> > LAYER:
> > /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> > ERROR:            loader_validate_instance_extensions: Instance
> > extension VK_KHR_wayland_surface not supported by available ICDs or
> > enabled layers.
> > Failed to create Vulkan instance.
> >
> > I have tried running in X.org mode instead of Wayland, but I get a
> > different set of errors:
>
> We haven’t been testing with window systems yet – can you try building
> the Sascha Willems demos [1] with -DUSE_D2D_WSI=ON and try running
> triangle?

I didn't realize you hadn't tried window systems yet.

I'll give that a try.  I appreciate the suggestions.

adam
>
> Matt
>
> [2]: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/devinfo
>
> > [ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> > [ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
> > [ 11102.014]    compiled for 1.21.1.7, module version = 0.0.2
> > [ 11102.014]    ABI class: X.Org Video Driver, version 25.2
> > [ 11102.015] (II) FBDEV(0): using default device
> > [ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
> > [ 11102.016] (EE)
> > Fatal server error:
> > or all framebuffer devices
> > [ 11102.016] (EE)
> > [ 11102.017] (EE)
> > Please consult the The X.Org Foundation support at http://wiki.x.org  for help.
> >
> > I think I am close.
> >
> > adam
> >>
> >> Matt
> >>
> >> [1]: https://github.com/SaschaWillems/Vulkan

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Tue, Feb 20, 2024 at 5:26 AM Adam Ford <aford173@gmail.com> wrote:
>
> On Tue, Feb 20, 2024 at 3:21 AM Matt Coster <Matt.Coster@imgtec.com> wrote:
> >
> > Hi Adam,
> >
> > On 19/02/2024 20:38, Adam Ford wrote:
> > > On Mon, Feb 19, 2024 at 3:00 AM Matt Coster <Matt.Coster@imgtec.com> wrote:
> > >>
> > >> Hi Adam,
> > >>
> > >> On 18/02/2024 23:26, Adam Ford wrote:
> > >>> On Fri, Feb 16, 2024 at 8:14 AM Maxime Ripard <mripard@kernel.org> wrote:
> > >>>>
> > >>>> On Fri, Feb 16, 2024 at 09:13:14AM +0000, Biju Das wrote:
> > >>>>> Hi Maxime Ripard,
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Maxime Ripard <mripard@kernel.org>
> > >>>>>> Sent: Friday, February 16, 2024 9:05 AM
> > >>>>>> Subject: Re: RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on
> > >>>>>> ARCH_K3
> > >>>>>>
> > >>>>>> On Fri, Feb 16, 2024 at 08:47:46AM +0000, Biju Das wrote:
> > >>>>>>> Hi Adam Ford,
> > >>>>>>>
> > >>>>>>>> -----Original Message-----
> > >>>>>>>> From: Adam Ford <aford173@gmail.com>
> > >>>>>>>> Sent: Thursday, February 15, 2024 11:36 PM
> > >>>>>>>> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend
> > >>>>>>>> on
> > >>>>>>>> ARCH_K3
> > >>>>>>>>
> > >>>>>>>> On Thu, Feb 15, 2024 at 11:22 AM Adam Ford <aford173@gmail.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com>
> > >>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > >>>>>>>>>> <geert@linux-m68k.org> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Hi Maxime,
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard
> > >>>>>>>>>>> <mripard@kernel.org>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>> On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven
> > >>>>>>>> wrote:
> > >>>>>>>>>>>>> Using the Imagination Technologies PowerVR Series 6 GPU
> > >>>>>>>>>>>>> requires a proprietary firmware image, which is currently
> > >>>>>>>>>>>>> only available for Texas Instruments K3 AM62x SoCs.  Hence
> > >>>>>>>>>>>>> add a dependency on ARCH_K3, to prevent asking the user
> > >>>>>>>>>>>>> about this driver when configuring a kernel without Texas
> > >>>>>>>>>>>>> Instruments K3
> > >>>>>>>> Multicore SoC support.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> This wasn't making sense the first time you sent it, and now
> > >>>>>>>>>>>> that commit log is just plain wrong. We have firmwares for
> > >>>>>>>>>>>> the G6110, GX6250, GX6650, BXE-4-32, and BXS-4-64 models,
> > >>>>>>>>>>>> which can be found on (at least) Renesas, Mediatek,
> > >>>>>>>>>>>> Rockchip, TI and StarFive, so across three
> > >>>>>>>>>>>
> > >>>>>>>>>>> I am so happy to be proven wrong!
> > >>>>>>>>>>> Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g.
> > >>>>>>>>>>> R-Car M3-
> > >>>>>>>> W.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> architectures and 5 platforms. In two months.
> > >>>>>>>>>>>
> > >>>>>>>>>>> That sounds like great progress, thanks a lot!
> > >>>>>>>>>>>
> > >>>>>>>>>> Geert,
> > >>>>>>>>>>
> > >>>>>>>>>>> Where can I find these firmwares? Linux-firmware[1] seems to
> > >>>>>>>>>>> lack all but the original K3 AM62x one.
> > >>>>>>>>>>
> > >>>>>>>>>> I think PowerVR has a repo [1], but the last time I checked it,
> > >>>>>>>>>> the BVNC for the firmware didn't match what was necessary for
> > >>>>>>>>>> the GX6250 on the RZ/G2M.  I can't remember what the
> > >>>>>>>>>> corresponding R-Car3 model is.  I haven't tried recently because
> > >>>>>>>>>> I was told more documentation for firmware porting would be
> > >>>>>>>>>> delayed until everything was pushed into the kernel and Mesa.
> > >>>>>>>>>> Maybe there is a better repo and/or newer firmware somewhere else.
> > >>>>>>>>>>
> > >>>>>>>>> I should have doubled checked the repo contents before I sent my
> > >>>>>>>>> last e-mail , but it appears the firmware  [2] for the RZ/G2M,
> > >>>>>>>>> might be present now. I don't know if there are driver updates
> > >>>>>>>>> necessary. I checked my e-mails, but I didn't see any
> > >>>>>>>>> notification, or I would have tried it earlier.  Either way, thank
> > >>>>>>>>> you Frank for adding it.  I'll try to test when I have some time.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> I don't have the proper version of Mesa setup yet, but for what it's
> > >>>>>>>> worth, the firmware loads without error, and it doesn't hang.
> > >>>>>>>
> > >>>>>>> Based on [1] and [2],
> > >>>>>>>
> > >>>>>>> kmscube should work on R-Car as it works on RZ/G2L with panfrost as
> > >>>>>>> earlier version of RZ/G2L which uses drm based on RCar-Du, later changed
> > >>>>>> to rzg2l-du.
> > >>>>>>
> > >>>>>> IIRC, the mesa support isn't there yet for kmscube to start.
> > >>>>>
> > >>>>> What about glmark2? I tested glmark2 as well.
> > >>>>
> > >>>> It's not really a matter of kmscube itself, but the interaction with the
> > >>>> compositor entirely. You can run a headless vulkan rendering, but an
> > >>>> application that renders to a window won't work.
> > >>>
> > >>> I have made a little progress.  I have Ubuntu running on an RZ/G2M
> > >>> (Rogue GX6250) with a device tree configuring the GPU and the GPU
> > >>> loads with firmware.
> > >>>
> > >>>   powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
> > >>>   powervr fd000000.gpu: [drm] FW version v1.0 (build 6513336 OS)
> > >>>   [drm] Initialized powervr 1.0.0 20230904 for fd000000.gpu on minor 0
> > >>>
> > >>> drmdevice lists card0 and renderD128
> > >>> --- Checking the number of DRM device available ---
> > >>> --- Devices reported 2 ---
> > >>> --- Retrieving devices information (PCI device revision is ignored) ---
> > >>> device[0]
> > >>> +-> available_nodes 0x05
> > >>> +-> nodes
> > >>> |   +-> nodes[0] /dev/dri/card0
> > >>> |   +-> nodes[2] /dev/dri/renderD128
> > >>> +-> bustype 0002
> > >>> |   +-> platform
> > >>> |       +-> fullname /soc/gpu@fd000000
> > >>> +-> deviceinfo
> > >>>     +-> platform
> > >>>         +-> compatible
> > >>>                     renesas,r8a774a1-gpu
> > >>>                     img,img-axe
> > >>>
> > >>> There is more to this dump, but it seems to repeat. I wanted to show
> > >>> that it seems like it's trying to work.
> > >>>
> > >>> I think I need to modify the powervr code in mesa to recognize the
> > >>> renesas,r8a774a1-gpu and associate it with the rcar-du, but I am not
> > >>> sure, and I am hoping someone might be able to provide some guidance,
> > >>> since I think I am missing something somewhere. I modified
> > >>> pvr_device.c in the mesa driver to attempt do this:
> > >>>
> > >>> /* This is the list of supported DRM render/display driver configs. */
> > >>> static const struct pvr_drm_device_config pvr_drm_configs[] = {
> > >>>    DEF_CONFIG("mediatek,mt8173-gpu", "mediatek-drm"),
> > >>>    DEF_CONFIG("ti,am62-gpu", "ti,am625-dss"),
> > >>>    DEF_CONFIG("renesas,r8a774a1-gpu", "rcar-du"),
> > >>> };
> > >>>
> > >>> When I run modetest -M rcar-du, I can see the encoders and connectors
> > >>> and I can display test patterns, so the rcar-du is working.
> > >>>
> > >>> I built Mesa 24.0.1 with the following options:
> > >>>
> > >>> meson setup builddir -Dvulkan-drivers=imagination-experimental
> > >>> -Dimagination-srv=true -Dtools=all -Dgallium-drivers=zink,kmsro,swrast
> > >>>
> > >>> I have tried to set PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 the Mesa
> > >>> documentation for the powerVR, and I have exported the variable for
> > >>> VK_ICD_FILENAMES to point to the powervr json file.
> > >>>
> > >>> when I try to run glmark2-drm, I was expecting the GL reddered to be
> > >>> the powervr, but it keeps using the
> > >>> GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> > >>>
> > >>> I realize this driver is still in its infancy, but I was hoping
> > >>> someone could give me some guidance to let me know if the work to do
> > >>> is on the Mesa side or the rcar-du driver side, or something else.
> > >>>
> > >>> I rebuilt both libdrm and mesa.  While I don't get any errors, I also
> > >>> don't get the hardware acceleration I was hoping for.
> > >>>
> > >>> I even tried  PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1
> > >>> MESA_LOADER_DRIVER_OVERRIDE=zink MESA_DEBUG=contect glmark2-drm
> > >>>
> > >>> ...but it only renders with llvmpipe
> > >>>
> > >>>     glmark2 2023.01
> > >>> =======================================================
> > >>>     OpenGL Information
> > >>>     GL_VENDOR:      Mesa
> > >>>     GL_RENDERER:    llvmpipe (LLVM 15.0.7, 128 bits)
> > >>>     GL_VERSION:     4.5 (Compatibility Profile) Mesa 24.0.1
> > >>>     Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=32 stencil=0 samples=0
> > >>>     Surface Size:   3840x2160 fullscreen
> > >>>
> > >>>
> > >>> I am not as familiar with the Mesa side, but if I can get this working
> > >>> to a point where something is rendered, even if it's not 100%
> > >>> compliant, I'd like to push patches to the kernel and/or Mesa if
> > >>> necessary.
> > >>>
> > >>> adam
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> Maxime
> > >>
> > >> I suggest you try running Vulkan demos (we use Sascha Willems’ [1])
> > >> instead of GL at this stage. Support for Zink is currently under heavy
> > >> development so you may have trouble differentiating between issues with
> > >> your kernel changes and the incompleteness in Mesa.
> > >
> > > I hacked the look-up-tables in the Mesa PowerVR driver to match the
> > > values of the other GX6250. I know there must be some minor
> > > differences, but I don't know what they are right now.
> >
> > In case you missed my other email, we have device info for the GX6250
> > variant you’re using in [2]. I’ve been informed that branch should be
> > usable as-is – can you give that a try?
>
> I did  migrate to the branch you referenced and remove my hacked
> lookup-table, but I get similar results.
>
> >
> > > I also had to tweak   src/imagination/vulkan/pvr_device.c again to the
> > > following:
> > >   DEF_CONFIG("renesas,r8a774a1-gpu", "renesas,du-r8a774a1"),
> >
> > Ah yes, not perfectly as-is then. These lines (pvr_drm_configs) declare
> > the pairing of GPU to display hardware. You’ll still need this tweak.

Should I push this tweak to gitlab?  I think there are a few other
Renesas SoC's that have the same GX6250 GPU.

> >
> > > I am not positive that is the correct thing to do, but with that, I
> > > can now run vulkaninfo.
> > > I know that it's not fully Vulkan compliant yet, but it appears there
> > > is some progress:
> > >
> > > Layers: count = 2
> > > =================
> > > VK_LAYER_MESA_device_select (Linux device selection layer) Vulkan
> > > version 1.3.211, layer version 1:
> > >         Layer Extensions: count = 0
> > >         Devices: count = 2
> > >                 GPU id = 0 (Imagination PowerVR Rogue GX6250)
> > >                 Layer-Device Extensions: count = 0
> > >
> > >                 GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
> > >                 Layer-Device Extensions: count = 0
> > >
> > > VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.3.211,
> > > layer version 1:
> > >         Layer Extensions: count = 0
> > >         Devices: count = 2
> > >                 GPU id = 0 (Imagination PowerVR Rogue GX6250)
> > >                 Layer-Device Extensions: count = 0
> > >
> > >                 GPU id = 1 (llvmpipe (LLVM 15.0.7, 128 bits))
> > >                 Layer-Device Extensions: count = 0
> > >
> > >
> > > I then tried to redndr with vkgears, but it didn't redner.  When I run
> > > vkgears, I get the following:
> > >
> > > LAYER:            Searching for layer manifest files
> > > LAYER:               In following locations:
> > > LAYER:                  /home/aford/.config/vulkan/implicit_layer.d
> > > LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/implicit_layer.d
> > > LAYER:                  /etc/xdg/vulkan/implicit_layer.d
> > > LAYER:                  /etc/vulkan/implicit_layer.d
> > > LAYER:                  /home/aford/.local/share/vulkan/implicit_layer.d
> > > LAYER:                  /usr/share/ubuntu/vulkan/implicit_layer.d
> > > LAYER:                  /usr/share/gnome/vulkan/implicit_layer.d
> > > LAYER:                  /usr/local/share/vulkan/implicit_layer.d
> > > LAYER:                  /usr/share/vulkan/implicit_layer.d
> > > LAYER:                  /var/lib/snapd/desktop/vulkan/implicit_layer.d
> > > LAYER:               Found the following files:
> > > LAYER:
> > > /usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json
> > > LAYER:            Searching for layer manifest files
> > > LAYER:               In following locations:
> > > LAYER:                  /home/aford/.config/vulkan/explicit_layer.d
> > > LAYER:                  /etc/xdg/xdg-ubuntu/vulkan/explicit_layer.d
> > > LAYER:                  /etc/xdg/vulkan/explicit_layer.d
> > > LAYER:                  /etc/vulkan/explicit_layer.d
> > > LAYER:                  /home/aford/.local/share/vulkan/explicit_layer.d
> > > LAYER:                  /usr/share/ubuntu/vulkan/explicit_layer.d
> > > LAYER:                  /usr/share/gnome/vulkan/explicit_layer.d
> > > LAYER:                  /usr/local/share/vulkan/explicit_layer.d
> > > LAYER:                  /usr/share/vulkan/explicit_layer.d
> > > LAYER:                  /var/lib/snapd/desktop/vulkan/explicit_layer.d
> > > LAYER:               Found the following files:
> > > LAYER:
> > > /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> > > ERROR:            loader_validate_instance_extensions: Instance
> > > extension VK_KHR_wayland_surface not supported by available ICDs or
> > > enabled layers.
> > > Failed to create Vulkan instance.
> > >
> > > I have tried running in X.org mode instead of Wayland, but I get a
> > > different set of errors:
> >
> > We haven’t been testing with window systems yet – can you try building
> > the Sascha Willems demos [1] with -DUSE_D2D_WSI=ON and try running
> > triangle?
>
> I didn't realize you hadn't tried window systems yet.
>
> I'll give that a try.  I appreciate the suggestions.
>
> adam
> >
> > Matt

Matt,

I cloned and built the repo you suggested with  -DUSE_D2D_WSI=ON, and
cmake threw a warning:

CMake Warning (dev) at
/usr/share/cmake-3.27/Modules/FindPackageHandleStandardArgs.cmake:438
(message):
  The package name passed to `find_package_handle_standard_args` (WAYLAND)
  does not match the name of the calling package (Wayland).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):

I then built with make and executed the triangle demo with the following dump:

INFO | LAYER:     Insert instance layer "VK_LAYER_MESA_device_select"
(libVkLayer_MESA_device_select.so)
LAYER:            vkCreateInstance layer callstack setup to:
LAYER:               <Application>
LAYER:                 ||
LAYER:               <Loader>
LAYER:                 ||
LAYER:               VK_LAYER_MESA_device_select
LAYER:                       Type: Implicit
LAYER:                           Disable Env Var:  NODEVICE_SELECT
LAYER:                       Manifest:
/usr/share/vulkan/implicit_layer.d/VkLayer_MESA_device_select.json
LAYER:                       Library:  libVkLayer_MESA_device_select.so
LAYER:                 ||
LAYER:               <Drivers>
WARNING:          terminator_CreateInstance: Failed to CreateInstance
in ICD 2.  Skipping ICD.
WARNING:          terminator_CreateInstance: Failed to CreateInstance
in ICD 5.  Skipping ICD.
MESA: error: Render device '/dev/dri/renderD128' has no compatible
display device.
DEBUG:            Copying old device 0 into new device 0
DEBUG:            Copying old device 1 into new device 1
DEBUG:            Copying old device 0 into new device 0
DEBUG:            Copying old device 1 into new device 1
DEBUG:            Copying old device 0 into new device 0
DEBUG:            Copying old device 1 into new device 1
INFO | LAYER:     Failed to find vkGetDeviceProcAddr in layer
"libVkLayer_MESA_device_select.so"
LAYER:            vkCreateDevice layer callstack setup to:
LAYER:               <Application>
LAYER:                 ||
LAYER:               <Loader>
LAYER:                 ||
LAYER:               <Device>
LAYER:                   Using "Imagination PowerVR Rogue GX6250" with
driver: "/usr/lib/aarch64-linux-gnu/libvulkan_powervr_mesa.so"
Validation error: Incorrect coeff register usage list.

/* USC program */

Aborted (core dumped)

When the renderD128 has no compatible display device, does that mean
there is more I should have done to somehow connect the rcar-du to the
GX6250?

> >
> > [2]: https://gitlab.freedesktop.org/imagination/mesa/-/tree/dev/devinfo
> >
> > > [ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> > > [ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
> > > [ 11102.014]    compiled for 1.21.1.7, module version = 0.0.2
> > > [ 11102.014]    ABI class: X.Org Video Driver, version 25.2
> > > [ 11102.015] (II) FBDEV(0): using default device
> > > [ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
> > > [ 11102.016] (EE)
> > > Fatal server error:
> > > or all framebuffer devices
> > > [ 11102.016] (EE)
> > > [ 11102.017] (EE)
> > > Please consult the The X.Org Foundation support at http://wiki.x.org  for help.
> > >
> > > I think I am close.
> > >
> > > adam
> > >>
> > >> Matt
> > >>
> > >> [1]: https://github.com/SaschaWillems/Vulkan

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Erico Nunes]

Hi,

On Mon, Feb 19, 2024 at 9:38 PM Adam Ford <aford173@gmail.com> wrote:
> /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> ERROR:            loader_validate_instance_extensions: Instance
> extension VK_KHR_wayland_surface not supported by available ICDs or
> enabled layers.
> Failed to create Vulkan instance.
>
> I have tried running in X.org mode instead of Wayland, but I get a
> different set of errors:
>
> [ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> [ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
> [ 11102.014]    compiled for 1.21.1.7, module version = 0.0.2
> [ 11102.014]    ABI class: X.Org Video Driver, version 25.2
> [ 11102.015] (II) FBDEV(0): using default device
> [ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
> [ 11102.016] (EE)
> Fatal server error:
> or all framebuffer devices
> [ 11102.016] (EE)
> [ 11102.017] (EE)
> Please consult the The X.Org Foundation support at http://wiki.x.org  for help.


The wayland and xcb extensions are not really supported at the moment
in Mesa for powervr, so this kind of use case does not really work
yet. For a first test, indeed the Sascha Willems triangle with
-DUSE_D2D_WSI=ON is probably best.

One thing I can add is that most Wayland compositors use OpenGL for
rendering and will only expose linux dmabuf capability if accelerated
OpenGL support is found by the compositor. So even if you manage to
hack some WSI functionality to be exposed by the Vulkan driver, it
still won't work out of the box with regular compositors since there
is no zink/OpenGL support yet. There is some experimental Vulkan
renderer support in some compositors but last time I tried they hit
other limitations due to the early state of powervr Vulkan in Mesa.

I did some work related to this and managed to run a Vulkan triangle
with Wayland and a modified compositor so far. So at least we could
get the client side out of the way soon. But that depends on a Mesa
development branch from Imagination which is being heavily reworked,
so we need to wait for that rework to make its way into upstream Mesa
before making progress on that work being upstreamed.


Erico

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Tue, Feb 20, 2024 at 5:55 AM Erico Nunes <nunes.erico@gmail.com> wrote:
>
> Hi,
>
> On Mon, Feb 19, 2024 at 9:38 PM Adam Ford <aford173@gmail.com> wrote:
> > /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json
> > ERROR:            loader_validate_instance_extensions: Instance
> > extension VK_KHR_wayland_surface not supported by available ICDs or
> > enabled layers.
> > Failed to create Vulkan instance.
> >
> > I have tried running in X.org mode instead of Wayland, but I get a
> > different set of errors:
> >
> > [ 11102.013] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
> > [ 11102.014] (II) Module fbdevhw: vendor="X.Org Foundation"
> > [ 11102.014]    compiled for 1.21.1.7, module version = 0.0.2
> > [ 11102.014]    ABI class: X.Org Video Driver, version 25.2
> > [ 11102.015] (II) FBDEV(0): using default device
> > [ 11102.016] (II) modeset(G0): using drv /dev/dri/card1
> > [ 11102.016] (EE)
> > Fatal server error:
> > or all framebuffer devices
> > [ 11102.016] (EE)
> > [ 11102.017] (EE)
> > Please consult the The X.Org Foundation support at http://wiki.x.org  for help.
>
>
> The wayland and xcb extensions are not really supported at the moment
> in Mesa for powervr, so this kind of use case does not really work
> yet. For a first test, indeed the Sascha Willems triangle with
> -DUSE_D2D_WSI=ON is probably best.
>
> One thing I can add is that most Wayland compositors use OpenGL for
> rendering and will only expose linux dmabuf capability if accelerated
> OpenGL support is found by the compositor. So even if you manage to
> hack some WSI functionality to be exposed by the Vulkan driver, it
> still won't work out of the box with regular compositors since there
> is no zink/OpenGL support yet. There is some experimental Vulkan
> renderer support in some compositors but last time I tried they hit
> other limitations due to the early state of powervr Vulkan in Mesa.

If I disable the GUI, do you think it would render via kms/drm?  I was
having issues starting Ubuntu with X11.

>
> I did some work related to this and managed to run a Vulkan triangle
> with Wayland and a modified compositor so far. So at least we could
> get the client side out of the way soon. But that depends on a Mesa
> development branch from Imagination which is being heavily reworked,
> so we need to wait for that rework to make its way into upstream Mesa
> before making progress on that work being upstreamed.

OK.  I won't spend any more time on it.  I knew the driver was in its
infancy, but I didn't realize how much.

I'll likely push my existing device tree changes to the Geert's
Renesas tree so the GPU node can be added which should make this
easier in the future.  I can push my tweak via gitlab, adding
DEF_CONFIG("renesas,r8a774a1-gpu", "renesas,du-r8a774a1"), if you
think that would be accepted.

adam
>
>
> Erico

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Frank Binns]

Hi Adam,

Sorry for not responding sooner. I've recently just returned from paternity
leave, so just catching up on everything.

On Thu, 2024-02-15 at 11:22 -0600, Adam Ford wrote:
> On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com> wrote:
> > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > <geert@linux-m68k.org> wrote:
> > > Hi Maxime,
> > > 
> > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > > proprietary firmware image, which is currently only available for Texas
> > > > > Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > prevent asking the user about this driver when configuring a kernel
> > > > > without Texas Instruments K3 Multicore SoC support.
> > > > 
> > > > This wasn't making sense the first time you sent it, and now that commit
> > > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> > > 
> > > I am so happy to be proven wrong!
> > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> > > 
> > > > architectures and 5 platforms. In two months.
> > > 
> > > That sounds like great progress, thanks a lot!
> > > 
> > Geert,
> > 
> > > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > > but the original K3 AM62x one.
> > 
> > I think PowerVR has a repo [1], but the last time I checked it, the
> > BVNC for the firmware didn't match what was necessary for the GX6250
> > on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
> > is.  I haven't tried recently because I was told more documentation
> > for firmware porting would be delayed until everything was pushed into
> > the kernel and Mesa.  Maybe there is a better repo and/or newer
> > firmware somewhere else.
> > 
> I should have doubled checked the repo contents before I sent my last
> e-mail , but it appears the firmware  [2] for the RZ/G2M, might be
> present now. I don't know if there are driver updates necessary. I
> checked my e-mails, but I didn't see any notification, or I would have
> tried it earlier.  Either way, thank you Frank for adding it.  I'll
> try to test when I have some time.
> 

You may have noticed from one of Matt's emails that we now have a set of repos
(linux, linux-firmware and Mesa) in our own area on freedesktop.org GitLab:
https://gitlab.freedesktop.org/imagination/

We'll be using this as a staging area for work that isn't ready to be upstreamed
yet (including firmware binaries).


> > adam
> > 
> > [1] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
> 
> [2] - https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
> 

This is now the place to get the firmware for devices that aren't yet supported
upstream:
https://gitlab.freedesktop.org/imagination/linux-firmware/-/commits/powervr/?ref_type=HEADS

With the firmware for the Renesas variant of GX6250 being found in this commit:
https://gitlab.freedesktop.org/imagination/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b

Thanks
Frank

> > 
> > > Thanks again!
> > > 
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> > > 
> > > Gr{oetje,eeting}s,
> > > 
> > >                         Geert
> > > 
> > > --
> > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> > > 
> > > In personal conversations with technical people, I call myself a hacker. But
> > > when I'm talking to journalists I just say "programmer" or something like that.
> > >                                 -- Linus Torvalds

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Adam Ford]

On Tue, Mar 5, 2024 at 5:58 AM Frank Binns <Frank.Binns@imgtec.com> wrote:
>
> Hi Adam,
>
> Sorry for not responding sooner. I've recently just returned from paternity
> leave, so just catching up on everything.

Congratulations!

>
> On Thu, 2024-02-15 at 11:22 -0600, Adam Ford wrote:
> > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com> wrote:
> > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > <geert@linux-m68k.org> wrote:
> > > > Hi Maxime,
> > > >
> > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > > > proprietary firmware image, which is currently only available for Texas
> > > > > > Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > > prevent asking the user about this driver when configuring a kernel
> > > > > > without Texas Instruments K3 Multicore SoC support.
> > > > >
> > > > > This wasn't making sense the first time you sent it, and now that commit
> > > > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> > > >
> > > > I am so happy to be proven wrong!
> > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> > > >
> > > > > architectures and 5 platforms. In two months.
> > > >
> > > > That sounds like great progress, thanks a lot!
> > > >
> > > Geert,
> > >
> > > > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > > > but the original K3 AM62x one.
> > >
> > > I think PowerVR has a repo [1], but the last time I checked it, the
> > > BVNC for the firmware didn't match what was necessary for the GX6250
> > > on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
> > > is.  I haven't tried recently because I was told more documentation
> > > for firmware porting would be delayed until everything was pushed into
> > > the kernel and Mesa.  Maybe there is a better repo and/or newer
> > > firmware somewhere else.
> > >
> > I should have doubled checked the repo contents before I sent my last
> > e-mail , but it appears the firmware  [2] for the RZ/G2M, might be
> > present now. I don't know if there are driver updates necessary. I
> > checked my e-mails, but I didn't see any notification, or I would have
> > tried it earlier.  Either way, thank you Frank for adding it.  I'll
> > try to test when I have some time.
> >
>
> You may have noticed from one of Matt's emails that we now have a set of repos
> (linux, linux-firmware and Mesa) in our own area on freedesktop.org GitLab:
> https://gitlab.freedesktop.org/imagination/
>
> We'll be using this as a staging area for work that isn't ready to be upstreamed
> yet (including firmware binaries).
>

I tried to play with these a little, but it seems like there is still
a fair amount of work to be done on the 6XT series. I tried to add the
device tree support for several Renesas boards, but the series was
NAK'd due to an inability to test it.
>
> > > adam
> > >
> > > [1] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
> >
> > [2] - https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
> >
>
> This is now the place to get the firmware for devices that aren't yet supported
> upstream:
> https://gitlab.freedesktop.org/imagination/linux-firmware/-/commits/powervr/?ref_type=HEADS
>
I've been following several of these repos and checking for software
updates in both the Firmware, driver and userspace layers.

> With the firmware for the Renesas variant of GX6250 being found in this commit:
> https://gitlab.freedesktop.org/imagination/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
>

If your group thinks they have stuff they want tested, I am willing to
test them on the two platforms I have if I am CC'd on anything.

Thanks for the work your group has done so far.  It'll be nice to see the work.

adam

> Thanks
> Frank
>
> > >
> > > > Thanks again!
> > > >
> > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> > > >
> > > > Gr{oetje,eeting}s,
> > > >
> > > >                         Geert
> > > >
> > > > --
> > > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> > > >
> > > > In personal conversations with technical people, I call myself a hacker. But
> > > > when I'm talking to journalists I just say "programmer" or something like that.
> > > >                                 -- Linus Torvalds

Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Frank Binns]

On Tue, 2024-03-05 at 07:47 -0600, Adam Ford wrote:
> On Tue, Mar 5, 2024 at 5:58 AM Frank Binns <Frank.Binns@imgtec.com> wrote:
> > Hi Adam,
> > 
> > Sorry for not responding sooner. I've recently just returned from paternity
> > leave, so just catching up on everything.
> 
> Congratulations!
> 

Thanks!

> > On Thu, 2024-02-15 at 11:22 -0600, Adam Ford wrote:
> > > On Thu, Feb 15, 2024 at 11:10 AM Adam Ford <aford173@gmail.com> wrote:
> > > > On Thu, Feb 15, 2024 at 10:54 AM Geert Uytterhoeven
> > > > <geert@linux-m68k.org> wrote:
> > > > > Hi Maxime,
> > > > > 
> > > > > On Thu, Feb 15, 2024 at 5:18 PM Maxime Ripard <mripard@kernel.org> wrote:
> > > > > > On Thu, Feb 15, 2024 at 01:50:09PM +0100, Geert Uytterhoeven wrote:
> > > > > > > Using the Imagination Technologies PowerVR Series 6 GPU requires a
> > > > > > > proprietary firmware image, which is currently only available for Texas
> > > > > > > Instruments K3 AM62x SoCs.  Hence add a dependency on ARCH_K3, to
> > > > > > > prevent asking the user about this driver when configuring a kernel
> > > > > > > without Texas Instruments K3 Multicore SoC support.
> > > > > > 
> > > > > > This wasn't making sense the first time you sent it, and now that commit
> > > > > > log is just plain wrong. We have firmwares for the G6110, GX6250,
> > > > > > GX6650, BXE-4-32, and BXS-4-64 models, which can be found on (at least)
> > > > > > Renesas, Mediatek, Rockchip, TI and StarFive, so across three
> > > > > 
> > > > > I am so happy to be proven wrong!
> > > > > Yeah, GX6650 is found on e.g. R-Car H3, and GX6250 on e.g. R-Car M3-W.
> > > > > 
> > > > > > architectures and 5 platforms. In two months.
> > > > > 
> > > > > That sounds like great progress, thanks a lot!
> > > > > 
> > > > Geert,
> > > > 
> > > > > Where can I find these firmwares? Linux-firmware[1] seems to lack all
> > > > > but the original K3 AM62x one.
> > > > 
> > > > I think PowerVR has a repo [1], but the last time I checked it, the
> > > > BVNC for the firmware didn't match what was necessary for the GX6250
> > > > on the RZ/G2M.  I can't remember what the corresponding R-Car3 model
> > > > is.  I haven't tried recently because I was told more documentation
> > > > for firmware porting would be delayed until everything was pushed into
> > > > the kernel and Mesa.  Maybe there is a better repo and/or newer
> > > > firmware somewhere else.
> > > > 
> > > I should have doubled checked the repo contents before I sent my last
> > > e-mail , but it appears the firmware  [2] for the RZ/G2M, might be
> > > present now. I don't know if there are driver updates necessary. I
> > > checked my e-mails, but I didn't see any notification, or I would have
> > > tried it earlier.  Either way, thank you Frank for adding it.  I'll
> > > try to test when I have some time.
> > > 
> > 
> > You may have noticed from one of Matt's emails that we now have a set of repos
> > (linux, linux-firmware and Mesa) in our own area on freedesktop.org GitLab:
> > https://gitlab.freedesktop.org/imagination/
> > 
> > We'll be using this as a staging area for work that isn't ready to be upstreamed
> > yet (including firmware binaries).
> > 
> 
> I tried to play with these a little, but it seems like there is still
> a fair amount of work to be done on the 6XT series. I tried to add the
> device tree support for several Renesas boards, but the series was
> NAK'd due to an inability to test it.

I've not had a chance to properly read through that thread yet and I seem to
remember that, when I had a quick skim through the DT bindings patch, there was
some feedback I wanted to give. I'll try to get to that sooner rather than
later.

Anyway, in principle I don't think there should be an issue with upstreaming
device tree bindings. The thing that needs to be avoided is baking in the uapi
before sufficient testing has been done (passing the Vulkan conformance test
suite will give us enough confidence). As long as we don't add the compatibles
into the `struct of_device_id` table in the driver, we should be fine in this
regard.

Sorry if this conflicts with anything Matt already said. We're still very new to
working with the upstream kernel and are being cautious to avoid any mistakes
that may come back to bite us.

> > > > adam
> > > > 
> > > > [1] https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/tree/powervr/powervr?ref_type=heads
> > > 
> > > [2] - https://gitlab.freedesktop.org/frankbinns/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
> > > 
> > 
> > This is now the place to get the firmware for devices that aren't yet supported
> > upstream:
> > https://gitlab.freedesktop.org/imagination/linux-firmware/-/commits/powervr/?ref_type=HEADS
> > 
> I've been following several of these repos and checking for software
> updates in both the Firmware, driver and userspace layers.
> 
> > With the firmware for the Renesas variant of GX6250 being found in this commit:
> > https://gitlab.freedesktop.org/imagination/linux-firmware/-/commit/fecb3caebf29f37221fe0a20236e5e1415d39d0b
> > 
> 
> If your group thinks they have stuff they want tested, I am willing to
> test them on the two platforms I have if I am CC'd on anything.
> 

Thank you for the offer, that is very much appreciated!

Do you happen to know if those platforms (or ones with the same SoC in) are
available for purchase?

> Thanks for the work your group has done so far.  It'll be nice to see the work.
> 

No problem at all :)

Thanks
Frank

> adam
> 
> > Thanks
> > Frank
> > 
> > > > > Thanks again!
> > > > > 
> > > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> > > > > 
> > > > > Gr{oetje,eeting}s,
> > > > > 
> > > > >                         Geert
> > > > > 
> > > > > --
> > > > > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> > > > > 
> > > > > In personal conversations with technical people, I call myself a hacker. But
> > > > > when I'm talking to journalists I just say "programmer" or something like that.
> > > > >                                 -- Linus Torvalds

RE: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3

[Biju Das]

Hi Frank,

> -----Original Message-----
> From: Frank Binns <Frank.Binns@imgtec.com>
> Sent: Tuesday, March 5, 2024 4:43 PM
> Subject: Re: [PATCH v2] drm/imagination: DRM_POWERVR should depend on ARCH_K3
> 
> On Tue, 2024-03-05 at 07:47 -0600, Adam Ford wrote:
> > On Tue, Mar 5, 2024 at 5:58 AM Frank Binns <Frank.Binns@imgtec.com> wrote:
> > > Hi Adam,
> 
> Thank you for the offer, that is very much appreciated!
> 
> Do you happen to know if those platforms (or ones with the same SoC in) are available for purchase?

One such platform available here[1]

[1]
https://www.amazon.de/LIMENAMICS-Hochleistungs-Board-hochaufl%C3%B6sende-fortschrittlicher-Generation/dp/B08RNMSDY3/ref?th=1

Cheers,
Biju