Message-ID: <3db15f74-2f48-4a43-9a2f-27b54c22dbf1@foss.arm.com>
Date: Thu, 25 Jul 2024 12:45:07 +0100
From: Carsten Haitzler <carsten.haitzler@...s.arm.com>
To: Boris Brezillon <boris.brezillon@...labora.com>,
 Steven Price <steven.price@....com>
Cc: Daniel Almeida <daniel.almeida@...labora.com>,
 Wedson Almeida Filho <wedsonaf@...il.com>, ojeda@...nel.org,
 Danilo Krummrich <dakr@...hat.com>, lyude@...hat.com, robh@...nel.org,
 lina@...hilina.net, mcanal@...lia.com, airlied@...il.com,
 rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] drm: panthor: add dev_coredumpv support



On 7/23/24 5:06 PM, Boris Brezillon wrote:
> Hi Steve,
> 
> On Mon, 15 Jul 2024 10:12:16 +0100
> Steven Price <steven.price@....com> wrote:
> 
>> I note it also shows that the "panthor_regs.rs" would ideally be shared.
>> For arm64 we have been moving to generating system register descriptions
>> from a text source (see arch/arm64/tools/sysreg) - I'm wondering whether
>> something similar is needed for Panthor to generate both C and Rust
>> headers? Although perhaps that's overkill, sysregs are certainly
>> somewhat more complex.
> 
> Just had a long discussion with Daniel regarding this panthor_regs.rs
> auto-generation, and, while I agree this is something we'd rather do if
> we intend to maintain the C and rust code base forever, I'm not
> entirely convinced this is super useful here because:
> 
> 1. the C code base is meant to be entirely replaced by a rust driver.
> Of course, that's not going to happen overnight, so maybe it'd be worth
> having this autogen script but...
> 
> 2. the set of register and register fields seems to be pretty stable.
> We might have a few things to update to support v11, v12, etc, but it
> doesn't look like the layout will suddenly become completely different.
> 
> 3. the number of registers and fields is somewhat reasonable, which
> means we should be able to catch mistakes during review. And in case
> one slip through, it's not the end of the world either because this
> stays internal to the kernel driver. We'll either figure it out when
> rust-ifying panthor components, or that simply means the register is
> not used and the mistake is harmless until the register starts being
> used
> 
> 4. we're still unclear on how GPU registers should be exposed in rust,
> so any script we develop is likely to require heavy changes every time
> we change our mind

You have a good point. A script sounds nice, but given the restricted 
domain size, it maybe better to be manually maintained. Given that I 
also think the right way to access registers is to do it as safely as 
possible.

So a gpu_write() or gpu_read() are "unsafe" in that you can write 
invalid values to a just about anything in C. If we're trying to harden 
drivers like panthor and make it "impossible" to do the wrong thing, 
then IMHO for example MCU_CONTROL should be abstracted so I can ONLY 
write MCU_CONTROL_* values that are for that register and nothing else 
in Rust. This should fail at compile time if I ever write something 
invalid to a register, and I can't write to anything but a known/exposed 
register.

Interestingly the C code could also abstract the same way and at least 
produce warnings too and become safer. It may be useful to mimic the 
design pattern there to keep panthor.rs and panthor.c in sync more easily?

So my opinion would be to try get the maximum value from Rust and have 
things like proper register abstractions that are definitely safe.

> For all these reasons, I think I'd prefer to have Daniel focus on a
> proper rust abstraction to expose GPU registers and fields the rust-way,
> rather than have him spend days/weeks on a script that is likely to be
> used a couple times (if not less) before the driver is entirely
> rewritten in rust. I guess the only interesting aspect remaining after
> the conversion is done is conciseness of register definitions if we
> were using some sort of descriptive format that gets converted to rust
> code, but it comes at the cost of maintaining this script. I'd probably
> have a completely different opinion if the Mali register layout was a
> moving target, but it doesn't seem to be the case.
> 
> FYI, Daniel has a python script parsing panthor_regs.h and generating
> panthor_regs.rs out of it which he can share if you're interested.
> 
> Regards,
> 
> Boris

Powered by blists - more mailing lists