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.hans...@linaro.org> > Reviewed-by: Bartosz Golaszewski <bartosz.golaszew...@linaro.org> > Signed-off-by: Michal Wilczynski <m.wilczyn...@samsung.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-...@intel.com/ [2]: https://lore.kernel.org/r/202506201103.gx6da9gx-...@intel.com/ > select DRM_EXEC > select DRM_GEM_SHMEM_HELPER > select DRM_SCHED > -- Matt Coster E: matt.cos...@imgtec.com
OpenPGP_signature.asc
Description: OpenPGP digital signature
