Skip to contentSkip to conversation

gpu: nova-core: gsp: Move gsp register definition into gsp module

PATCH Applied Antonin Malzieu Ridolfi 3 participants 7 messages Jun 7 – Jun 13 1 message not in the archive

Subsystems (4)
DRM drivers DRM Rust nova-core (Rust) nova-drm (Rust)
lore
Share & tools
lore

Antonin Malzieu Ridolfi

author
#0 lore raw

PATCH v2 1/1 gpu: nova-core: gsp: Move gsp register definition into gsp module

Split the gsp register definitions grouped in nova root register file to the gsp module which actually use them.

Suggested-by Alexandre Courbot <[email protected]>
Suggested-by Danilo Krummrich <[email protected]>
Signed-off-by Antonin Malzieu Ridolfi <[email protected]>
---
 drivers/gpu/nova-core/gsp.rs      |  1 +
 drivers/gpu/nova-core/gsp/cmdq.rs |  3 ++-
 drivers/gpu/nova-core/gsp/regs.rs | 11 +++++++++++
 drivers/gpu/nova-core/regs.rs     |  8 --------
 4 files changed, 14 insertions(+), 9 deletions(-)
 create mode 100644 drivers/gpu/nova-core/gsp/regs.rs
drivers/gpu/nova-core/gsp.rs +1 -0
index 69175ca3315c..385b4c09582b 100644
@@ -22,6 +22,7 @@
 pub(crate) mod cmdq;
 pub(crate) mod commands;
 mod fw;
+mod regs;
 mod sequencer;
 
 pub(crate) use fw::{
drivers/gpu/nova-core/gsp/cmdq.rs +0 -0
index 0bc5a

95a9cd7..495d07d65c39 100644

drivers/gpu/nova-core/gsp/cmdq.rs +2 -1
@@ -51,10 +51,11 @@
         GSP_PAGE_SIZE, //
     },
     num,
-    regs,
     sbuffer::SBufferIter, //
 };
 
+use super::regs;
+
 /// Marker type representing the absence of a reply for a command. Commands using this as their
 /// reply type are sent using [`Cmdq::send_command_no_wait`].
 pub(crate) struct NoReply;
drivers/gpu/nova-core/gsp/regs.rs new file +11 -0
new file mode 100644
index 000000000000..a76dea3c3ab0
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+
+use kernel::io::register;
+
+// PGSP
+
+register! {
+    pub(super) NV_PGSP_QUEUE_HEAD(u32) @ 0x00110c00 {
+        31:0    address;
+    }
+}
drivers/gpu/nova-core/regs.rs +0 -0
index 0f49c1ab83ad..73339a0cff99 100644

--- a/drivers/gpu/nova-core/reg
s.rs
+++ b/drivers/gpu/nova-core/regs.rs

@@ -227,14 +227,6 @@ pub(crate) fn is_wpr2_set(self) -> bool {
     }

}

-// PGSP
-
-register! {
- pub(crate) NV_PGSP_QUEUE_HEAD(u32) @ 0x00110c00 {
- 31:0 address;
- }
-}
-
// PGC6 register space.
//
// GC6 is a GPU low-power state where VRAM is in self-refresh and the GPU is powered down (except
--
2.54.0

maintainer
#1 lore raw
Quoted 6 lines · Antonin Malzieu Ridolfi

Split the gsp register definitions grouped in nova root register file to the gsp module which actually use them.

Suggested-by Alexandre Courbot <[email protected]>
Suggested-by Danilo Krummrich <[email protected]>
Signed-off-by Antonin Malzieu Ridolfi <[email protected]>

Thanks for the patch, the contents are fine.

However, the patch is mangled after fetching it with b4 (probably caused by multipart/signed with nested multipart/mixed); please prefer plain text (see also [1]).

No need to resend AFAIC; I can also fix it up on my end for this one.

Thanks,
Danilo

[1] https://docs.kernel.org/process/email-clients.html#general-preferences

author Reviewed-by Alexandre Courbot
#3 lore raw

Oh! Didn't think to add this extra tag since your review, sorry!

Can we add it now? Should I do a V3 to add it? Or not that much of a big deal this time, but should think about it for the next time?

Anyway let me know and thanks for the feedback!

Also, I check for Proton Mail, as I understand they don't support format=flowed so except using there "uservoice" service to ask them to implement it, I had probably nothing else to do. But I found a git-protonmail service dedicated to use proton mail with git send-email, so maybe it will work? I have to try as I don't know the email protocol well enough to understand on which layer the patch get mangled and if this tool can proxy around the Proton implementation.

Antonin.

-------- Original Message --------
On Wednesday, 06/10/26 at 15:31 Alexandre Courbot <[email protected]> wrote:

Quoted 6 lines · Antonin Malzieu Ridolfi

Split the gsp register definitions grouped in nova root register file to the gsp module which actually use them.

Suggested-by Alexandre Courbot <[email protected]>
Suggested-by Danilo Krummrich <[email protected]>
Signed-off-by Antonin Malzieu Ridolfi <[email protected]>
Reviewed-by Alexandre Courbot <[email protected]>
maintainer
#4 lore raw
Quoted 3 lines · Nanonej Dev

Oh! Didn't think to add this extra tag since your review, sorry!

Can we add it now? Should I do a V3 to add it? Or not that much of a big deal this time, but should think about it for the next time?

Don't worry, you did nothing wrong.

This is just the (rudimentary) process by which we state that we have processed a patch in some way: just reply with the tags carrying our name/email that we want to stick to the patch [1]. In this case, I've reviewed it, so I signaled that by giving my Reviewed-by.

Since I hadn't given it by the time you sent this patch, there was no way for you to add it.

The common practice is to collect the tags you received on vN and carry them onto vN+1 (unless the patch has significantly changed), but in this case this wasn't necessary since Danilo applied the patch and added the tags [2].

All this to say that this was a perfectly normal kernel patch review and there was nothing more for you to do.

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
[2] https://gitlab.freedesktop.org/drm/rust/kernel/-/commit/3e4bac7b8ca7688fb3aa9c0bf005a5a4256ad578

Quoted 4 lines

Anyway let me know and thanks for the feedback!

Also, I check for Proton Mail, as I understand they don't support format=flowed so except using there "uservoice" service to ask them to implement it, I had probably nothing else to do. But I found a git-protonmail service dedicated to use proton mail with git send-email, so maybe it will work? I have to try as I don't know the email protocol well enough to understand on which layer the patch get mangled and if this tool can proxy around the Proton implementation.

Normally git send-email or b4 should do the right thing, but after a quick search there seems to be recurring server-side mangling issues with Protonmail, so you might need to use another service to send patches. B4's web endpoint might be an option [3].

[3] https://b4.docs.kernel.org/en/latest/contributor/send.html

A message that is not in the archive (sent off-list or not yet received): vvjHdIL6_yt_mjEDbQzZ5naOIbjsntZJ6xoeR495GAgkIFE5m2UJyexmYhPCH9e7Nafptn9rgYNLHZhYPiX4G6l4X75A1MVlg4UzCpjUwLY=@nanonej.com

author
#6 lore raw

Hey!

Just a quick heads up, to tell you that I spend some more time looking to fix this mangled patch issue and, indeed, B4's web endpoint seems to be the best solution if I want to keep using Proton mail for communication.

So thanks a lot for taking time looking for it and suggesting it to solve my issue, I'll try it on my next patch.

Take care,

Antonin Malzieu Ridolfi.

Quoted 62 lines · Nanonej Dev
Quoted 5 lines

Don't worry, you did nothing wrong.

This is just the (rudimentary) process by which we state that we have processed a patch in some way: just reply with the tags carrying our name/email that we want to stick to the patch [1].

Oh! I must have forgot this part then, my bad, thanks for the info.

Quoted 6 lines

Normally git send-email or b4 should do the right thing, but after a quick search there seems to be recurring server-side mangling issues with Protonmail, so you might need to use another service to send patches. B4's web endpoint might be an option [3].

[3] https://b4.docs.kernel.org/en/latest/contributor/send.html

Oh, thanks! I didn't know about b4 service. I'm gonna check that then!

Quoted 38 lines · Alexandre Courbot
Quoted 3 lines · Nanonej Dev

Oh! Didn't think to add this extra tag since your review, sorry!

Can we add it now? Should I do a V3 to add it? Or not that much of a big deal this time, but should think about it for the next time?

Don't worry, you did nothing wrong.

This is just the (rudimentary) process by which we state that we have processed a patch in some way: just reply with the tags carrying our name/email that we want to stick to the patch [1]. In this case, I've reviewed it, so I signaled that by giving my Reviewed-by.

Since I hadn't given it by the time you sent this patch, there was no way for you to add it.

The common practice is to collect the tags you received on vN and carry them onto vN+1 (unless the patch has significantly changed), but in this case this wasn't necessary since Danilo applied the patch and added the tags [2].

All this to say that this was a perfectly normal kernel patch review and there was nothing more for you to do.

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
[2] https://gitlab.freedesktop.org/drm/rust/kernel/-/commit/3e4bac7b8ca7688fb3aa9c0bf005a5a4256ad578

Quoted 4 lines

Anyway let me know and thanks for the feedback!

Also, I check for Proton Mail, as I understand they don't support format=flowed so except using there "uservoice" service to ask them to implement it, I had probably nothing else to do. But I found a git-protonmail service dedicated to use proton mail with git send-email, so maybe it will work? I have to try as I don't know the email protocol well enough to understand on which layer the patch get mangled and if this tool can proxy around the Proton implementation.

Normally git send-email or b4 should do the right thing, but after a quick search there seems to be recurring server-side mangling issues with Protonmail, so you might need to use another service to send patches. B4's web endpoint might be an option [3].

[3] https://b4.docs.kernel.org/en/latest/contributor/send.html

maintainer Applied
#7 lore raw
In reply to Antonin Malzieu Ridolfi
Quoted 1 line · Antonin Malzieu Ridolfi

[PATCH v2] gpu: nova-core: gsp: Move gsp register definition into gsp module

Applied, thanks!

Branch: drm-rust-next
Tree: https://gitlab.freedesktop.org/drm/rust/kernel.git

[1/1] gpu: nova-core: gsp: Move gsp register definition into gsp module

      commit: 3e4bac7b8ca7

The patch will appear in the next linux-next integration (typically within 24 hours on weekdays).

The patch is queued up for the upcoming merge window for the next major kernel release.