From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 50435CCA470 for ; Tue, 7 Oct 2025 22:09:09 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DA60110E064; Tue, 7 Oct 2025 22:09:08 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="Qffl5CaE"; dkim-atps=neutral Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2B56610E064; Tue, 7 Oct 2025 22:09:08 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 288DC60234; Tue, 7 Oct 2025 22:09:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B73DC4CEF1; Tue, 7 Oct 2025 22:09:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1759874946; bh=XS6kxUgIxY0xi7QvlRdjUhp7HYIxFJBZ7ARKYvS767s=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=Qffl5CaEBIWcdvdFCYM3iPL9e1NOQQ6uvu7t/vI+JjgNFgD6rO5+4n+RpNc4qYNLw pIpHvO0kVy5e5ZB2pF9g97kX69Yu48257XCzH5CMLPGweSZQUJaNM8WHtbL8KfFmXp /O+jOOvNp1P2GYjFr7UFN3x+AprxLXI+xkL4HzyYbSfkuDkcLXOdBgLYjigEhTkCr9 F54zHAgEDvBABH//A+T3l4g27HNf5sg7WxuRSyOrjh77ahYSyzrfQjqc56SNV2NmDm Y+v7bc91HxA95pT/mURPwchCu+MJQEcLGFP1FiVUZbx1CB7zy270q9ySpC3qcr+7YT UIRyTreQndmcg== Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 08 Oct 2025 00:08:59 +0200 Message-Id: Subject: Re: [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/ Cc: "Alexandre Courbot" , "Yury Norov" , , , , "Alistair Popple" , "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "David Airlie" , "Simona Vetter" , "Maarten Lankhorst" , "Maxime Ripard" , "Thomas Zimmermann" , "John Hubbard" , "Timur Tabi" , , "Elle Rhumsaa" , "Daniel Almeida" , "Andrea Righi" , To: "Joel Fernandes" From: "Danilo Krummrich" References: <20251003154748.1687160-1-joelagnelf@nvidia.com> In-Reply-To: X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" On Tue Oct 7, 2025 at 11:08 PM CEST, Joel Fernandes wrote: > Danilo, Yuri, Miguel, John, all, > > On 10/7/2025 9:16 AM, Danilo Krummrich wrote: >> On Tue Oct 7, 2025 at 12:36 PM CEST, Alexandre Courbot wrote: >>> Because letting it fully mature within nova-core also has the drawback >>> that we might miss the perspective of other potential users, which may >>> make us draw ourselves into a corner that will make the macro less >>> useful generally speaking. We are at a stage where we can still make >>> design changes if needed, but we need to hear from other users, and >>> these won't come as long as the macro is in nova-core. >>=20 >> There are two different things here that are getting mixed up a bit. >>=20 >> (1) Moving the register!() code out of nova-core to make it accessible= for >> other drivers. >>=20 >> (2) Generalize the bitfield implementation that so far is baked into t= he >> register!() code. >>=20 >> Both of those make sense, but they don't have to happen at the same time >> necessarily. >>=20 >> Now, I'm not saying that we necessarily have to change the approach here= . The >> current merge window isn't even closed, so we have plently of time left,= i.e. >> there's no rush with with patch series. >>=20 >> However, if it helps, I'm perfectly fine to take the register!() impleme= ntation >> into the I/O entry in a first step and in a second step generalize the b= itfield >> implementation and move it out of the register!() code. >>=20 >> Again, there's no rush as far as I'm concerned, yet the latter approach = might >> add a bit more structure and hence run a bit smoother. > > In my view it is better to move both bitfield and register macros togethe= r > because if we only moved register, it means we would have no bitfield sup= port > for the page table / mm use case I just posted a patch for (which is why = I > started looking into Bitfield support initially) unless we create a copy = of just > the bitfield code within nova which we definitely shouldn't I think. So I= think > it is best to move both. Again, fine for me either way, but I wanted to open the possibility. Typically, things run more smoothly when focusing on one thing at a time. Especially when one thing is done to unblock something else, while the othe= r things needs some more discussion and might require a more slow-paced appro= ach.) (Slightly off-topic: Regarding the bitfields for page table management: Are= we sure that we can use raw bitfields for this? I.e. will we always be able to configure the GPU to match CPU endianness?) > For the IO (register macro) change, I can add add an entry to the existin= g IO > record. I don't think any changes are needed, it should be covered by just moving i= t to rust/kernel/io/register.rs. Thanks, Danilo