lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ff96ee1f-23ad-4e7f-9ac1-11f410e459e3@imgtec.com>
Date: Tue, 24 Jun 2025 13:54:06 +0000
From: Matt Coster <Matt.Coster@...tec.com>
To: Michal Wilczynski <m.wilczynski@...sung.com>
CC: Drew Fustini <drew@...7.com>, Guo Ren <guoren@...nel.org>,
        Fu Wei
	<wefu@...hat.com>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Bartosz Golaszewski
	<brgl@...ev.pl>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Frank Binns
	<Frank.Binns@...tec.com>,
        Maarten Lankhorst
	<maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
        Alexandre Ghiti <alex@...ti.fr>, Ulf Hansson <ulf.hansson@...aro.org>,
        Marek
 Szyprowski <m.szyprowski@...sung.com>,
        Bartosz Golaszewski
	<bartosz.golaszewski@...aro.org>,
        "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>,
        "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org"
	<linux-pm@...r.kernel.org>,
        "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v6 8/8] drm/imagination: Enable PowerVR driver for RISC-V

On 23/06/2025 12:42, Michal Wilczynski wrote:
> Several RISC-V boards feature Imagination GPUs that are compatible with
> the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi
> 4A board. This commit adjusts the driver's Kconfig dependencies to allow
> the PowerVR driver to be compiled on the RISC-V architecture.
> 
> By enabling compilation on RISC-V, we expand support for these GPUs,
> providing graphics acceleration capabilities and enhancing hardware
> compatibility on RISC-V platforms.
> 
> Add a dependency on MMU to fix a build warning on RISC-V configurations
> without an MMU.
> 
> Reviewed-by: Ulf Hansson <ulf.hansson@...aro.org>
> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
> Signed-off-by: Michal Wilczynski <m.wilczynski@...sung.com>
> ---
>  drivers/gpu/drm/imagination/Kconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/imagination/Kconfig b/drivers/gpu/drm/imagination/Kconfig
> index 5f9fff43d6baadc42ebf48d91729bfbf27e06caa..a7da858a5b301e8f088e3e22f5641feb2e078681 100644
> --- a/drivers/gpu/drm/imagination/Kconfig
> +++ b/drivers/gpu/drm/imagination/Kconfig
> @@ -3,9 +3,10 @@
>  
>  config DRM_POWERVR
>  	tristate "Imagination Technologies PowerVR (Series 6 and later) & IMG Graphics"
> -	depends on ARM64
> +	depends on (ARM64 || RISCV)

There were two issues you encountered when enabling COMPILE_TEST in v5,
both of which are somewhat simple to workaround but expose underlying
assumptions we made during early development.

The first [1] is due to us assuming a 64-bit platform, which was never a
problem with the ARM64 dependency, but may actually be a problem with
RISCV given this allows for 32-bit as well. You should probably make
this (RISCV && 64BIT) until the implicit 64-bit dependency can be worked
out.

Somewhat related, we also assume a little-endian host. Technically ARM64
can also be big-endian, you just don't encounter that in the wild too
often so it's never been a "real" issue. I do wonder if swapping out
(ARM64 || RISCV) for (64BIT && CPU_LITTLE_ENDIAN) entirely would be a
reasonable change, perhaps for another day though...

The other [2] is slightly more subtle. To keep things straightforward,
we currently map CPU pages to GPU pages 1:1, meaning we use the CPU page
size to define the GPU page size. That GPU page size is configurable,
but does not support every possible size the CPU could support on any
architecture. The failing test there was sparc64 with an 8K page size
causing no GPU page size to be defined. See the #if/#elif ladder at the
top of pvr_mmu.c for the supported sizes and the doc comment above
PVR_DEVICE_PAGE_SIZE in pvr_mmu.h for the acknowledgement of the page
size restrictions.

The "proper" fix here would be for us to make these two sizes
independent, but that's not a trivial change. The "quick" fix I suppose
would be to depend on one of the supported page sizes, so maybe
(PAGE_SIZE_4KB || PAGE_SIZE_16KB || PAGE_SIZE_64KB || PAGE_SIZE_256KB)
since the larger page sizes appear unsupported (probably for good
reason).

>  	depends on DRM
>  	depends on PM
> +	depends on MMU

Nit: can you keep this alphabetical?

Cheers,
Matt

[1]: https://lore.kernel.org/r/202506191323.zD1fszQb-lkp@intel.com/
[2]: https://lore.kernel.org/r/202506201103.GX6DA9Gx-lkp@intel.com/

>  	select DRM_EXEC
>  	select DRM_GEM_SHMEM_HELPER
>  	select DRM_SCHED
> 


-- 
Matt Coster
E: matt.coster@...tec.com


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ