On 1/23/26 11:28 AM, Matt Coster wrote:
On 05/01/2026 16:34, Marek Vasut wrote:
On 1/5/26 2:09 PM, Matt Coster wrote:
On 06/11/2025 23:24, Marek Vasut wrote:
Fix support for build on 32bit systems. Include linux/io-64-nonatomic-hi-lo.h
to provide non-atomic readq()/writeq()/ioread64()/iowrite64() accessors, and
use __ffs64() instead of plain ffs() on 64bit number SZ_1T.

This allows this driver to bind on Renesas R-Car H2 which contains
Rogue G6400 BVNC 1.39.4.1 .

Signed-off-by: Marek Vasut <[email protected]>

Hi Marek,

Hello Matt,

My apologies, this one appears to have slipped through the cracks on our
end.

No worries.

+++ b/drivers/gpu/drm/imagination/Kconfig
@@ -3,7 +3,7 @@
     config DRM_POWERVR
       tristate "Imagination Technologies PowerVR (Series 6 and later) & IMG 
Graphics"
-    depends on (ARM64 || RISCV && 64BIT)
+    depends on ARM || ARM64 || RISCV

This seems fine to me. Do you know any reason why the single change
below might *not* be sufficient to support non-64-bit riscv? I can't
think of any, I just wanted to double check this had been considered.
I do not have any 32bit RV to test this on, I only have 32bit ARM (R-Car H2).

I appreciate that you'd like to work on getting these older cores
supported in the driver, but as it stands there's no real way to test
this change beyond ensuring that it compiles.

I'm sure imgtec can produce a firmware, just like they did for the other cores, and then it can be tested ?

I've asked around internally and the consensus is that communicating
with the GPU on a 32-bit platform requires more consideration than just
using the shims provided by io-64-nonatomic-hi-lo.h to avoid introducing
races and other potential security holes.

My suggestion is that this patch be shelved for now and used as part of
a larger series later which adds basic support for a core on a 32-bit
platform.
What exactly is missing ?

Reply via email to