* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Helge Deller @ 2026-03-12 19:47 UTC (permalink / raw)
To: Thomas Zimmermann, Hardik Phalet, Ferenc Bakonyi
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <afd8b00d-42fa-4eb7-b18e-302d3f7cadf7@suse.de>
On 3/12/26 16:10, Thomas Zimmermann wrote:
> Am 12.03.26 um 16:04 schrieb Hardik Phalet:
>> On Tue Mar 10, 2026 at 6:38 PM IST, Thomas Zimmermann wrote:
>>> Hi,
>>>
>>> thanks for the patch. Let's hope there are no conflicts with other
>>> hardware. IDK if anyone still uses this driver.
>> Hi Thomas,
>>
>> Thanks for reviewing this.
>>
>> Since I currently do not have access to the hardware needed to test the
>> change properly, I will drop this patch for now. I may revisit it once I
>> can validate the behavior on real hardware.
>
> Good luck. That's the Hercules framebuffer driver. Finding such
> ancient hardware that can run modern Linux is nigh impossible.
>
> But we can merge the patch. If it breaks anyone's setup, they will send a bug report.
>
> Helge will pick up the fix if he's ok with it.
No, I don't want to merge such patches any longer without any testing
on real hardware. There is no actual problem (else someone would have reported),
as such I don't see a benefit to apply it. Applying it just brings the risk
that we break it for someone.
So, NAK.
I believe I wrote about my opinion already in another patch?
I think we should rephrase that specific TODO item (which mentions the memory
region allocation) that only patches which have been tested are accepted.
Helge
^ permalink raw reply
* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Miguel Ojeda @ 2026-03-12 19:20 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, nouveau, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260306203648.1136554-2-joelagnelf@nvidia.com>
On Fri, Mar 6, 2026 at 9:37 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> +//! // Create typed [`CList`] from sentinel head.
> +//! // SAFETY: head is valid and initialized, items are `SampleItemC` with
> +//! // embedded `link` field, and `Item` is `#[repr(transparent)]` over `SampleItemC`.
> +//! let list = clist_create!(unsafe { head, Item, SampleItemC, link });
Was the patch tested with Clippy? It has several issues.
The worst news is that it seems the "supposed to be `unsafe` block"
does not count as one for Clippy, i.e.:
let list = clist_create!(unsafe { head, Item, SampleItemC, link });
So we get:
error: statement has unnecessary safety comment
--> rust/doctests_kernel_generated.rs:7416:1
|
7416 | let list = clist_create!(unsafe { head, Item, SampleItemC, link });
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: consider removing the safety comment
--> rust/doctests_kernel_generated.rs:7414:4
|
7414 | // SAFETY: head is valid and initialized, items are
`SampleItemC` with
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= help: for further information visit
https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#unnecessary_safety_comment
= note: `-D clippy::unnecessary-safety-comment` implied by
`-D warnings`
= help: to override `-D warnings` add
`#[allow(clippy::unnecessary_safety_comment)]`
For this, we could write them as a `// SAFETY*: ` comment or similar,
to make progress for now, but it would best to request upstream Clippy
to detect this or to rework the macro to force the `unsafe` block
outside.
In addition:
error: unsafe block missing a safety comment
--> rust/kernel/interop/list.rs:357:17
|
112 | let _list = clist_create!(unsafe { head, Item,
SampleItemC, link });
|
--------------------------------------------------------- in this
macro invocation
...
357 | |p| unsafe { &raw const (*p).$($field).+ };
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: consider adding a safety comment on the preceding line
= help: for further information visit
https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#undocumented_unsafe_blocks
= note: `-D clippy::undocumented-unsafe-blocks` implied by `-D warnings`
= help: to override `-D warnings` add
`#[allow(clippy::undocumented_unsafe_blocks)]`
= note: this error originates in the macro `clist_create` (in
Nightly builds, run with -Z macro-backtrace for more info)
So this needs a `// SAFETY:` comment on top of the closure.
error: this macro expands metavariables in an unsafe block
--> rust/kernel/interop/list.rs:362:9
|
362 | unsafe { $crate::interop::list::CList::<$rust_type,
OFFSET>::from_raw($head) }
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this allows the user of the macro to write unsafe code
outside of an unsafe block
= help: consider expanding any metavariables outside of this
block, e.g. by storing them in a variable
= help: ... or also expand referenced metavariables in a safe
context to require an unsafe block at callsite
= help: for further information visit
https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#macro_metavars_in_unsafe
= note: `-D clippy::macro-metavars-in-unsafe` implied by `-D warnings`
= help: to override `-D warnings` add
`#[allow(clippy::macro_metavars_in_unsafe)]`
For this one, to begin with, do we expect to have actual expressions
for `$head`, or could we constrain it for now to an identifier for
instance?
With an identifier there is no issue then -- the example currently has
just an identifier anyway.
I hope that helps.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Miguel Ojeda @ 2026-03-12 19:16 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Danilo Krummrich, Dave Airlie,
David Airlie, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, nouveau, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <20260306203648.1136554-2-joelagnelf@nvidia.com>
On Fri, Mar 6, 2026 at 9:37 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Acked-by: Miguel Ojeda <ojeda@kernel.org>
> +//! # // SAFETY: head and all the items are test objects allocated in this scope.
`head`
> +//! // Rust wrapper for the C struct.
Empty newline comment between these:
//! //
Actually, should this be `//! ///`?
> +//! // The list item struct in this example is defined in C code as:
> +//! // struct SampleItemC {
> +//! // int value;
> +//! // struct list_head link;
> +//! // };
> +//! //
Let's try to use the usual style, i.e. no empty newline at the end of
docs for an item.
And the example should be in a proper code block with a C tag, so all
together something like:
//! /// Rust wrapper for the C struct.
//! ///
//! /// The list item struct in this example is defined in C code as:
//! ///
//! /// ```c
//! /// struct SampleItemC {
//! /// int value;
//! /// struct list_head link;
//! /// };
//! /// ```
> +//! // SAFETY: [`Item`] has same layout as [`SampleItemC`].
No need for intra-doc links in comments (for now at least).
> +//! // Create typed [`CList`] from sentinel head.
Empty newline comment.
> +//! // SAFETY: head is valid and initialized, items are `SampleItemC` with
`head`
However, this is giving me a Clippy issue (please see the other email).
> +/// `next`/`prev` pointers are valid and non-NULL.
We started using `NULL` recently as a convention for the null pointer.
> + // - [`CListHead`] has same layout as `list_head`.
Intra-doc link not needed.
> + // - `ptr` is valid and unmodified for 'a per caller guarantees.
`'a`
> + // SAFETY: self.as_raw() is valid per type invariants.
`self.as_raw()`
> +/// perform conversion of returned [`CListHead`] to an item (using `container_of` macro or similar).
Intra-doc link to `container_of`?
> + // - [`CList`] has same layout as [`CListHead`] due to repr(transparent).
Intra-doc link not needed.
> + // Convert to item using OFFSET.
`OFFSET`
Newline comment after this one.
> +/// Create a C doubly-circular linked list interface `CList` from a raw `list_head` pointer.
[`CList`]
> +/// pointing to a list that is not concurrently modified for the lifetime of the `CList`.
[`CList`]
> +/// Refer to the examples in this module's documentation.
Perhaps we could have an intra-doc link here to the module.
> + // Compile-time check that field path is a list_head.
`list_head`
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Miguel Ojeda @ 2026-03-12 19:15 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Joel Fernandes, Miguel Ojeda, linux-kernel, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Alex Gaynor, Dave Airlie, David Airlie,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Simona Vetter, Daniel Almeida, Koen Koning, Nikola Djukic,
Alexandre Courbot, Philipp Stanner, Elle Rhumsaa, Jonathan Corbet,
Alex Deucher, Christian König, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Huang Rui, Matthew Auld,
Matthew Brost, Lucas De Marchi, Thomas Hellström,
Helge Deller, John Hubbard, Alistair Popple, Timur Tabi,
Edwin Peer, Andrea Righi, Andy Ritger, Zhi Wang, Balbir Singh,
alexeyi, Eliot Courtney, dri-devel, nouveau, rust-for-linux,
linux-doc, amd-gfx, intel-gfx, intel-xe, linux-fbdev
In-Reply-To: <DH0ZMJKN6OE6.243UPT928HIIX@kernel.org>
On Thu, Mar 12, 2026 at 6:42 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> Was this given off-list? I can't find a corresponding reply from Miguel.
Thanks for double-checking that -- it is fine.
I am sending some nits and Clippy issues independently though.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH v12.1 1/1] rust: gpu: Add GPU buddy allocator bindings
From: Danilo Krummrich @ 2026-03-12 17:45 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Dave Airlie, Daniel Almeida, Koen Koning, dri-devel,
nouveau, rust-for-linux, Nikola Djukic, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, Alex Gaynor, Boqun Feng,
John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev
In-Reply-To: <20260309135338.3919996-2-joelagnelf@nvidia.com>
On Mon Mar 9, 2026 at 2:53 PM CET, Joel Fernandes wrote:
> Add safe Rust abstractions over the Linux kernel's GPU buddy
> allocator for physical memory management. The GPU buddy allocator
> implements a binary buddy system useful for GPU physical memory
> allocation. nova-core will use it for physical memory allocation.
>
> Christian Koenig mentioned he'd like to step down from reviewer role for
> GPU buddy so updated accordingly. Arun/Matthew agree on the modified entry.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
> MAINTAINERS | 6 +-
> rust/bindings/bindings_helper.h | 11 +
> rust/helpers/gpu.c | 23 ++
> rust/helpers/helpers.c | 1 +
> rust/kernel/gpu/buddy.rs | 611 ++++++++++++++++++++++++++++++++
> rust/kernel/gpu/mod.rs | 5 +
> rust/kernel/lib.rs | 2 +
> 7 files changed, 658 insertions(+), 1 deletion(-)
> create mode 100644 rust/helpers/gpu.c
> create mode 100644 rust/kernel/gpu/buddy.rs
> create mode 100644 rust/kernel/gpu/mod.rs
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4c66f8261ff2..b2600dd05fc2 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8513,7 +8513,9 @@ T: git https://gitlab.freedesktop.org/drm/rust/kernel.git
> F: drivers/gpu/drm/nova/
> F: drivers/gpu/drm/tyr/
> F: drivers/gpu/nova-core/
> +F: rust/helpers/gpu.c
> F: rust/kernel/drm/
> +F: rust/kernel/gpu/
>
> DRM DRIVERS FOR ALLWINNER A10
> M: Chen-Yu Tsai <wens@kernel.org>
> @@ -8926,7 +8928,7 @@ F: include/drm/ttm/
> GPU BUDDY ALLOCATOR
> M: Matthew Auld <matthew.auld@intel.com>
> M: Arun Pravin <arunpravin.paneerselvam@amd.com>
> -R: Christian Koenig <christian.koenig@amd.com>
This should really be a separate patch as it is unrelated to the addition of the
Rust GPU buddy code.
> +R: Joel Fernandes <joelagnelf@nvidia.com>
> L: dri-devel@lists.freedesktop.org
> S: Maintained
> T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> @@ -8935,6 +8937,8 @@ F: drivers/gpu/buddy.c
> F: drivers/gpu/tests/gpu_buddy_test.c
> F: include/linux/gpu_buddy.h
> F: include/drm/drm_buddy.h
> +F: rust/helpers/gpu.c
> +F: rust/kernel/gpu/
^ permalink raw reply
* Re: [PATCH v12 1/1] rust: interop: Add list module for C linked list interface
From: Danilo Krummrich @ 2026-03-12 17:42 UTC (permalink / raw)
To: Joel Fernandes, Miguel Ojeda
Cc: linux-kernel, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Alex Gaynor, Dave Airlie, David Airlie, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Simona Vetter, Daniel Almeida,
Koen Koning, Nikola Djukic, Alexandre Courbot, Philipp Stanner,
Elle Rhumsaa, Jonathan Corbet, Alex Deucher, Christian König,
Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin,
Huang Rui, Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, alexeyi, Eliot Courtney,
dri-devel, nouveau, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev, Miguel Ojeda
In-Reply-To: <20260306203648.1136554-2-joelagnelf@nvidia.com>
On Fri Mar 6, 2026 at 9:36 PM CET, Joel Fernandes wrote:
> Add a new module `kernel::interop::list` for working with C's doubly
> circular linked lists. Provide low-level iteration over list nodes.
>
> Typed iteration over actual items is provided with a `clist_create`
> macro to assist in creation of the `CList` type.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Alexandre Courbot <acourbot@nvidia.com>
> Acked-by: Gary Guo <gary@garyguo.net>
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Was this given off-list? I can't find a corresponding reply from Miguel.
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
I'm asking since I'm looking forward to pick this up as a dependency for
GPU buddy.
Thanks,
Danilo
^ permalink raw reply
* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Thomas Zimmermann @ 2026-03-12 15:10 UTC (permalink / raw)
To: Hardik Phalet, Ferenc Bakonyi, Helge Deller
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <DH0W99FBZJEX.30MPSPJVGV4ZF@pm.me>
Hi
Am 12.03.26 um 16:04 schrieb Hardik Phalet:
> On Tue Mar 10, 2026 at 6:38 PM IST, Thomas Zimmermann wrote:
>> Hi,
>>
>> thanks for the patch. Let's hope there are no conflicts with other
>> hardware. IDK if anyone still uses this driver.
> Hi Thomas,
>
> Thanks for reviewing this.
>
> Since I currently do not have access to the hardware needed to test the
> change properly, I will drop this patch for now. I may revisit it once I
> can validate the behavior on real hardware.
Good luck. That's the Hercules framebuffer driver. Finding such ancient
hardware that can run modern Linux is nigh impossible.
But we can merge the patch. If it breaks anyone's setup, they will send
a bug report.
Helge will pick up the fix if he's ok with it.
Best regards
Thomas
>
> Thanks again for your feedback.
>
> Best regards,
> Hardik
>> Am 10.03.26 um 13:30 schrieb Hardik Phalet:
>>> The driver calls ioremap() on the HGA video memory at 0xb0000 without
>>> first reserving the physical address range. This leaves the kernel
>>> resource tree incomplete and can cause silent conflicts with other
>>> drivers claiming the same range.
>>>
>>> Add a devm_request_mem_region() call before ioremap() in
>>> hga_card_detect() to reserve the memory region.
>>>
>>> Signed-off-by: Hardik Phalet <hardik.phalet@pm.me>
>> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>>
>> Best regards
>> Thomas
>>
>>> ---
>>> Changes in v3:
>>> - Used dev_err() to log memory region request, based on another review
>>> comment by Thomas [2].
>>> Changes in v2:
>>> - Used devm_request_mem_region instead of request_mem_region, based on a
>>> review comment by Thomas [1].
>>>
>>> v1: https://lore.kernel.org/all/20260310064124.602848-1-hardik.phalet@pm.me/
>>> v2: https://lore.kernel.org/all/20260310113810.789575-1-hardik.phalet@pm.me/
>>> [1]: https://lore.kernel.org/all/5f9749ba-18a8-4b6b-a6e7-a011a3871bfb@suse.de/
>>> [2]: https://lore.kernel.org/all/ec635591-c861-4aa8-a259-718690ddaa4e@suse.de/
>>>
>>> drivers/video/fbdev/hgafb.c | 9 +++++++--
>>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
>>> index 14418aa3791a..d32fd1c5217c 100644
>>> --- a/drivers/video/fbdev/hgafb.c
>>> +++ b/drivers/video/fbdev/hgafb.c
>>> @@ -276,7 +276,7 @@ static void hga_blank(int blank_mode)
>>> spin_unlock_irqrestore(&hga_reg_lock, flags);
>>> }
>>>
>>> -static int hga_card_detect(void)
>>> +static int hga_card_detect(struct platform_device *pdev)
>>> {
>>> int count = 0;
>>> void __iomem *p, *q;
>>> @@ -284,6 +284,11 @@ static int hga_card_detect(void)
>>>
>>> hga_vram_len = 0x08000;
>>>
>>> + if (!devm_request_mem_region(&pdev->dev, 0xb0000, hga_vram_len, "hgafb")) {
>>> + dev_err(&pdev->dev, "cannot reserve video memory at 0xb0000\n");
>>> + return -EBUSY;
>>> + }
>>> +
>>> hga_vram = ioremap(0xb0000, hga_vram_len);
>>> if (!hga_vram)
>>> return -ENOMEM;
>>> @@ -568,7 +573,7 @@ static int hgafb_probe(struct platform_device *pdev)
>>> struct fb_info *info;
>>> int ret;
>>>
>>> - ret = hga_card_detect();
>>> + ret = hga_card_detect(pdev);
>>> if (ret)
>>> return ret;
>>>
>> --
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
>> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v3] fbdev/hga: Request memory region before ioremap
From: Hardik Phalet @ 2026-03-12 15:04 UTC (permalink / raw)
To: Thomas Zimmermann, Hardik Phalet, Ferenc Bakonyi, Helge Deller
Cc: Shuah Khan, Brigham Campbell, linux-nvidia, linux-fbdev,
dri-devel, linux-kernel
In-Reply-To: <3d58e520-0308-44c7-a43a-e438548e9c40@suse.de>
On Tue Mar 10, 2026 at 6:38 PM IST, Thomas Zimmermann wrote:
> Hi,
>
> thanks for the patch. Let's hope there are no conflicts with other
> hardware. IDK if anyone still uses this driver.
Hi Thomas,
Thanks for reviewing this.
Since I currently do not have access to the hardware needed to test the
change properly, I will drop this patch for now. I may revisit it once I
can validate the behavior on real hardware.
Thanks again for your feedback.
Best regards,
Hardik
>
> Am 10.03.26 um 13:30 schrieb Hardik Phalet:
>> The driver calls ioremap() on the HGA video memory at 0xb0000 without
>> first reserving the physical address range. This leaves the kernel
>> resource tree incomplete and can cause silent conflicts with other
>> drivers claiming the same range.
>>
>> Add a devm_request_mem_region() call before ioremap() in
>> hga_card_detect() to reserve the memory region.
>>
>> Signed-off-by: Hardik Phalet <hardik.phalet@pm.me>
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
>
> Best regards
> Thomas
>
>> ---
>> Changes in v3:
>> - Used dev_err() to log memory region request, based on another review
>> comment by Thomas [2].
>> Changes in v2:
>> - Used devm_request_mem_region instead of request_mem_region, based on a
>> review comment by Thomas [1].
>>
>> v1: https://lore.kernel.org/all/20260310064124.602848-1-hardik.phalet@pm.me/
>> v2: https://lore.kernel.org/all/20260310113810.789575-1-hardik.phalet@pm.me/
>> [1]: https://lore.kernel.org/all/5f9749ba-18a8-4b6b-a6e7-a011a3871bfb@suse.de/
>> [2]: https://lore.kernel.org/all/ec635591-c861-4aa8-a259-718690ddaa4e@suse.de/
>>
>> drivers/video/fbdev/hgafb.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
>> index 14418aa3791a..d32fd1c5217c 100644
>> --- a/drivers/video/fbdev/hgafb.c
>> +++ b/drivers/video/fbdev/hgafb.c
>> @@ -276,7 +276,7 @@ static void hga_blank(int blank_mode)
>> spin_unlock_irqrestore(&hga_reg_lock, flags);
>> }
>>
>> -static int hga_card_detect(void)
>> +static int hga_card_detect(struct platform_device *pdev)
>> {
>> int count = 0;
>> void __iomem *p, *q;
>> @@ -284,6 +284,11 @@ static int hga_card_detect(void)
>>
>> hga_vram_len = 0x08000;
>>
>> + if (!devm_request_mem_region(&pdev->dev, 0xb0000, hga_vram_len, "hgafb")) {
>> + dev_err(&pdev->dev, "cannot reserve video memory at 0xb0000\n");
>> + return -EBUSY;
>> + }
>> +
>> hga_vram = ioremap(0xb0000, hga_vram_len);
>> if (!hga_vram)
>> return -ENOMEM;
>> @@ -568,7 +573,7 @@ static int hgafb_probe(struct platform_device *pdev)
>> struct fb_info *info;
>> int ret;
>>
>> - ret = hga_card_detect();
>> + ret = hga_card_detect(pdev);
>> if (ret)
>> return ret;
>>
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] staging: fbtft: avoid empty macro argument in define_fbtft_write_reg
From: Dan Carpenter @ 2026-03-12 13:56 UTC (permalink / raw)
To: Zile Xiong
Cc: andy, gregkh, deller, abdun.nihaal, chintanlike, niejianglei2021,
dri-devel, linux-fbdev, linux-staging, linux-kernel
In-Reply-To: <20260312111807.96789-1-xiongzile99@gmail.com>
On Thu, Mar 12, 2026 at 07:18:07PM +0800, Zile Xiong wrote:
> Replace the empty modifier argument with a simple identity macro.
> This fixes the error reported by scripts/checkpatch.pl while keeping
> the original semantics unchanged.
>
> The generated code is equivalent and builds successfully.
>
> Signed-off-by: Zile Xiong <xiongzile99@gmail.com>
> ---
> drivers/staging/fbtft/fbtft-bus.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
> index 30e436ff19e4..380dd374a566 100644
> --- a/drivers/staging/fbtft/fbtft-bus.c
> +++ b/drivers/staging/fbtft/fbtft-bus.c
> @@ -61,10 +61,10 @@ out: \
> va_end(args); \
> } \
> EXPORT_SYMBOL(func);
> -
> -define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
> +#define fbtft_identity(x) (x)
Someone sent this exact same patch before. Same name and everything.
https://lore.kernel.org/all/aYECoy7Apjwgzr9r@stanley.mountain/
A better sollution is to learn to just ignore checkpatch when it is
wrong. My previous email was longer.
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: fbtft: avoid empty macro argument in define_fbtft_write_reg
From: Zile Xiong @ 2026-03-12 11:18 UTC (permalink / raw)
To: andy, gregkh
Cc: deller, abdun.nihaal, dan.carpenter, chintanlike, niejianglei2021,
dri-devel, linux-fbdev, linux-staging, linux-kernel, Zile Xiong
Replace the empty modifier argument with a simple identity macro.
This fixes the error reported by scripts/checkpatch.pl while keeping
the original semantics unchanged.
The generated code is equivalent and builds successfully.
Signed-off-by: Zile Xiong <xiongzile99@gmail.com>
---
drivers/staging/fbtft/fbtft-bus.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-bus.c b/drivers/staging/fbtft/fbtft-bus.c
index 30e436ff19e4..380dd374a566 100644
--- a/drivers/staging/fbtft/fbtft-bus.c
+++ b/drivers/staging/fbtft/fbtft-bus.c
@@ -61,10 +61,10 @@ out: \
va_end(args); \
} \
EXPORT_SYMBOL(func);
-
-define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, )
+#define fbtft_identity(x) (x)
+define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8, fbtft_identity)
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
-define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, )
+define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16, fbtft_identity)
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
{
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v9 03/23] gpu: nova-core: gsp: Return GspStaticInfo from boot()
From: Eliot Courtney @ 2026-03-12 6:37 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, dri-devel
In-Reply-To: <20260311004008.2208806-4-joelagnelf@nvidia.com>
On Wed Mar 11, 2026 at 9:39 AM JST, Joel Fernandes wrote:
> Refactor the GSP boot function to return only the GspStaticInfo,
> removing the FbLayout from the return tuple.
I think the commit message may need updating - `boot` doesn't return
FbLayout. And it returns `GetGspStaticInfoReply`, not `GspStaticInfo`.
Other than that,
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
>
> @@ -126,7 +129,8 @@ fn run_fwsec_frts(
> /// user-space, patching them with signatures, and building firmware-specific intricate data
> /// structures that the GSP will use at runtime.
> ///
> - /// Upon return, the GSP is up and running, and its runtime object given as return value.
> + /// Upon return, the GSP is up and running, and static GPU information is returned.
> + ///
> pub(crate) fn boot(
> mut self: Pin<&mut Self>,
> pdev: &pci::Device<device::Bound>,
> @@ -134,7 +138,7 @@ pub(crate) fn boot(
> chipset: Chipset,
> gsp_falcon: &Falcon<Gsp>,
> sec2_falcon: &Falcon<Sec2>,
> - ) -> Result {
> + ) -> Result<GetGspStaticInfoReply> {
> let dev = pdev.as_ref();
>
> let bios = Vbios::new(dev, bar)?;
> @@ -225,6 +229,6 @@ pub(crate) fn boot(
> Err(e) => dev_warn!(pdev, "GPU name unavailable: {:?}\n", e),
> }
>
> - Ok(())
> + Ok(info)
> }
> }
^ permalink raw reply
* Re: [PATCH v9 02/23] gpu: nova-core: Kconfig: Sort select statements alphabetically
From: Eliot Courtney @ 2026-03-12 6:35 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, dri-devel
In-Reply-To: <20260311004008.2208806-3-joelagnelf@nvidia.com>
On Wed Mar 11, 2026 at 9:39 AM JST, Joel Fernandes wrote:
> Reorder the select statements in NOVA_CORE Kconfig to be in
> alphabetical order.
>
> Suggested-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply
* Re: [PATCH v9 01/23] gpu: nova-core: Select GPU_BUDDY for VRAM allocation
From: Eliot Courtney @ 2026-03-12 6:34 UTC (permalink / raw)
To: Joel Fernandes, linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, dri-devel
In-Reply-To: <20260311004008.2208806-2-joelagnelf@nvidia.com>
On Wed Mar 11, 2026 at 9:39 AM JST, Joel Fernandes wrote:
> nova-core will use the GPU buddy allocator for physical VRAM management.
> Enable it in Kconfig.
>
> Cc: Nikola Djukic <ndjukic@nvidia.com>
> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
> ---
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with usleep_range()
From: Andy Shevchenko @ 2026-03-11 16:01 UTC (permalink / raw)
To: Anas Iqbal
Cc: andy, gregkh, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311142407.35403-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 02:24:07PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for a 250 microsecond delay
> as recommended by checkpatch.pl. usleep_range() avoids busy
> waiting and allows the scheduler to schedule other tasks.
Now, read README here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/staging/fbtft/README
and act accordingly.
If you have been mentored on this, show the above link to your mentors.
...
> write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
> - 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> + 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
Use the common sense here. This change won't be accepted.
...
> - udelay(250);
> + usleep_range(250, 500);
No.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_ra8875: replace udelay() with usleep_range()
From: Andy Shevchenko @ 2026-03-11 15:57 UTC (permalink / raw)
To: Anas Iqbal
Cc: andy, gregkh, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311135245.32730-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 01:52:45PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for 100 microsecond delays as
> recommended by checkpatch.pl. usleep_range() avoids busy waiting and
> allows the scheduler to run other tasks.
fsleep().
Now, read README here:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/staging/fbtft/README
and act accordingly.
If you have been mentored on this, show the above link to your mentors.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with usleep_range()
From: Greg KH @ 2026-03-11 14:56 UTC (permalink / raw)
To: Anas Iqbal; +Cc: andy, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311142407.35403-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 02:24:07PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for a 250 microsecond delay
> as recommended by checkpatch.pl. usleep_range() avoids busy
> waiting and allows the scheduler to schedule other tasks.
>
> Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
> ---
> drivers/staging/fbtft/fb_tinylcd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
> index 9469248f2c50..51e6493b050f 100644
> --- a/drivers/staging/fbtft/fb_tinylcd.c
> +++ b/drivers/staging/fbtft/fb_tinylcd.c
> @@ -38,10 +38,10 @@ static int init_display(struct fbtft_par *par)
> write_reg(par, 0xE5, 0x00);
> write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
> write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
> - 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> + 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
Don't you think the original formatting makes more sense? And you did
not describe this change in the changelog :(
> write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> - udelay(250);
> + usleep_range(250, 500);
This is a totally different change than above. And also one that keeps
getting rejected, please see the mailing list archives for details.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with usleep_range()
From: Dan Carpenter @ 2026-03-11 14:48 UTC (permalink / raw)
To: Anas Iqbal
Cc: andy, gregkh, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311142407.35403-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 02:24:07PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for a 250 microsecond delay
> as recommended by checkpatch.pl. usleep_range() avoids busy
> waiting and allows the scheduler to schedule other tasks.
>
> Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
> ---
> drivers/staging/fbtft/fb_tinylcd.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
> index 9469248f2c50..51e6493b050f 100644
> --- a/drivers/staging/fbtft/fb_tinylcd.c
> +++ b/drivers/staging/fbtft/fb_tinylcd.c
> @@ -38,10 +38,10 @@ static int init_display(struct fbtft_par *par)
> write_reg(par, 0xE5, 0x00);
> write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
> write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
> - 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
> + 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
Don't do this.
1) It's unrelated.
2) The previous alignment was done deliberate to make it easier to read.
Checkpatch is not perfect so don't always do what it says.
> write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
> write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
> - udelay(250);
> + usleep_range(250, 500);
Do a search for init_display on lore
https://lore.kernel.org/all/?q=init_display
regards,
dan carpenter
^ permalink raw reply
* [PATCH] staging: fbtft: fb_tinylcd: replace udelay() with usleep_range()
From: Anas Iqbal @ 2026-03-11 14:24 UTC (permalink / raw)
To: andy, gregkh
Cc: linux-staging, dri-devel, linux-fbdev, linux-kernel, Anas Iqbal
Replace udelay() with usleep_range() for a 250 microsecond delay
as recommended by checkpatch.pl. usleep_range() avoids busy
waiting and allows the scheduler to schedule other tasks.
Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
---
drivers/staging/fbtft/fb_tinylcd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fb_tinylcd.c b/drivers/staging/fbtft/fb_tinylcd.c
index 9469248f2c50..51e6493b050f 100644
--- a/drivers/staging/fbtft/fb_tinylcd.c
+++ b/drivers/staging/fbtft/fb_tinylcd.c
@@ -38,10 +38,10 @@ static int init_display(struct fbtft_par *par)
write_reg(par, 0xE5, 0x00);
write_reg(par, 0xF0, 0x36, 0xA5, 0x53);
write_reg(par, 0xE0, 0x00, 0x35, 0x33, 0x00, 0x00, 0x00,
- 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
+ 0x00, 0x35, 0x33, 0x00, 0x00, 0x00);
write_reg(par, MIPI_DCS_SET_PIXEL_FORMAT, 0x55);
write_reg(par, MIPI_DCS_EXIT_SLEEP_MODE);
- udelay(250);
+ usleep_range(250, 500);
write_reg(par, MIPI_DCS_SET_DISPLAY_ON);
return 0;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] staging: fbtft: fb_ra8875: replace udelay() with usleep_range()
From: Greg KH @ 2026-03-11 14:23 UTC (permalink / raw)
To: Anas Iqbal; +Cc: andy, linux-staging, dri-devel, linux-fbdev, linux-kernel
In-Reply-To: <20260311135245.32730-1-mohd.abd.6602@gmail.com>
On Wed, Mar 11, 2026 at 01:52:45PM +0000, Anas Iqbal wrote:
> Replace udelay() with usleep_range() for 100 microsecond delays as
> recommended by checkpatch.pl. usleep_range() avoids busy waiting and
> allows the scheduler to run other tasks.
>
> Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
> ---
> drivers/staging/fbtft/fb_ra8875.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
> index 0ab1de6647d0..d2400bb44f1c 100644
> --- a/drivers/staging/fbtft/fb_ra8875.c
> +++ b/drivers/staging/fbtft/fb_ra8875.c
> @@ -210,7 +210,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
> }
> len--;
>
> - udelay(100);
> + usleep_range(100, 200);
>
> if (len) {
> buf = (u8 *)par->buf;
> @@ -231,7 +231,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
>
> /* restore user spi-speed */
> par->fbtftops.write = fbtft_write_spi;
> - udelay(100);
> + usleep_range(100, 200);
> }
>
> static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
> --
> 2.43.0
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You sent a patch that has been sent multiple times in the past few
days, and is identical to ones that has been recently rejected.
Please always look at the mailing list traffic to determine if you are
duplicating other people's work.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* [PATCH] staging: fbtft: fb_ra8875: replace udelay() with usleep_range()
From: Anas Iqbal @ 2026-03-11 13:52 UTC (permalink / raw)
To: andy, gregkh
Cc: linux-staging, dri-devel, linux-fbdev, linux-kernel, Anas Iqbal
Replace udelay() with usleep_range() for 100 microsecond delays as
recommended by checkpatch.pl. usleep_range() avoids busy waiting and
allows the scheduler to run other tasks.
Signed-off-by: Anas Iqbal <mohd.abd.6602@gmail.com>
---
drivers/staging/fbtft/fb_ra8875.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/fbtft/fb_ra8875.c b/drivers/staging/fbtft/fb_ra8875.c
index 0ab1de6647d0..d2400bb44f1c 100644
--- a/drivers/staging/fbtft/fb_ra8875.c
+++ b/drivers/staging/fbtft/fb_ra8875.c
@@ -210,7 +210,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
}
len--;
- udelay(100);
+ usleep_range(100, 200);
if (len) {
buf = (u8 *)par->buf;
@@ -231,7 +231,7 @@ static void write_reg8_bus8(struct fbtft_par *par, int len, ...)
/* restore user spi-speed */
par->fbtftops.write = fbtft_write_spi;
- udelay(100);
+ usleep_range(100, 200);
}
static int write_vmem16_bus8(struct fbtft_par *par, size_t offset, size_t len)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5] Fonts: Adding all Terminus fronts from 12 to 32 in bold, and normal versions
From: Thomas Zimmermann @ 2026-03-11 7:53 UTC (permalink / raw)
To: Helge Deller, Pavel Nikulin, linux-fbdev, dri-devel
Cc: Helge Deller, linux-kernel
In-Reply-To: <aaIFr-GKG1qiJYwg@p100>
Hi
Am 27.02.26 um 21:59 schrieb Helge Deller:
> Hi Pavel,
>
> please include the graphics mailing lists (fbdev, dri-devel).
>
> * Pavel Nikulin <pavel@noa-labs.com>:
>> This patch adds an option to compile-in all terminus fonts, and removed the old bold only terminus version
>>
>> These fonts were converted from Terminus psf files with the help of psftools and a script.
>>
>> This patch is non-intrusive, no options are enabled by default so most users won't notice a thing.
> Sure, but you add a whole lot of fonts.
> Why are both bold and non-bold fonts needed?
> Why do we need all in-kernel?
> They may be loaded after bootup via userspace too.
>
> What does other people think?
I'm strongly against adding more fonts to the kernel. Fonts can (and
should) be loaded from user space.
AFAICT this patch is just about someone trying to get their favorite
font merged. Doing that is not going to work out long term.
Best regards
Thomas
>
> Helge
>
>
>> I am placing my changes under the GPL 2.0 just as source Terminus font.
>>
>> Signed-off-by: Pavel Nikulin <pavel@noa-labs.com>
>> ---
>> V4 -> V5: Added changed font.h to the patch
>>
>> include/linux/font.h | 42 +-
>> lib/fonts/Kconfig | 142 +-
>> lib/fonts/Makefile | 15 +
>> lib/fonts/font_ter10x18.c | 6412 ++++++++----------------------------
>> lib/fonts/font_ter10x18b.c | 1305 ++++++++
>> lib/fonts/font_ter10x20.c | 1305 ++++++++
>> lib/fonts/font_ter10x20b.c | 1305 ++++++++
>> lib/fonts/font_ter11x22.c | 1561 +++++++++
>> lib/fonts/font_ter11x22b.c | 1561 +++++++++
>> lib/fonts/font_ter12x24.c | 1561 +++++++++
>> lib/fonts/font_ter12x24b.c | 1561 +++++++++
>> lib/fonts/font_ter14x28.c | 1817 ++++++++++
>> lib/fonts/font_ter14x28b.c | 1817 ++++++++++
>> lib/fonts/font_ter16x32.c | 4107 +++++++++++------------
>> lib/fonts/font_ter16x32b.c | 2073 ++++++++++++
>> lib/fonts/font_ter6x12.c | 537 +++
>> lib/fonts/font_ter8x14.c | 537 +++
>> lib/fonts/font_ter8x14b.c | 537 +++
>> lib/fonts/font_ter8x16.c | 537 +++
>> lib/fonts/font_ter8x16b.c | 537 +++
>> lib/fonts/fonts.c | 45 +
>> 21 files changed, 22124 insertions(+), 7190 deletions(-)
>> create mode 100644 lib/fonts/font_ter10x18b.c
>> create mode 100644 lib/fonts/font_ter10x20.c
>> create mode 100644 lib/fonts/font_ter10x20b.c
>> create mode 100644 lib/fonts/font_ter11x22.c
>> create mode 100644 lib/fonts/font_ter11x22b.c
>> create mode 100644 lib/fonts/font_ter12x24.c
>> create mode 100644 lib/fonts/font_ter12x24b.c
>> create mode 100644 lib/fonts/font_ter14x28.c
>> create mode 100644 lib/fonts/font_ter14x28b.c
>> create mode 100644 lib/fonts/font_ter16x32b.c
>> create mode 100644 lib/fonts/font_ter6x12.c
>> create mode 100644 lib/fonts/font_ter8x14.c
>> create mode 100644 lib/fonts/font_ter8x14b.c
>> create mode 100644 lib/fonts/font_ter8x16.c
>> create mode 100644 lib/fonts/font_ter8x16b.c
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* [PATCH v9 23/23] gpu: nova-core: Use runtime BAR1 size instead of hardcoded 256MB
From: Joel Fernandes @ 2026-03-11 0:40 UTC (permalink / raw)
To: linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, Joel Fernandes
In-Reply-To: <20260311004008.2208806-1-joelagnelf@nvidia.com>
From: Zhi Wang <zhiw@nvidia.com>
Remove the hardcoded BAR1_SIZE = SZ_256M constant. On GPUs like L40 the
BAR1 aperture is larger than 256MB; using a hardcoded size prevents large
BAR1 from working and mapping it would fail.
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
---
drivers/gpu/nova-core/driver.rs | 8 ++------
drivers/gpu/nova-core/gpu.rs | 7 +------
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index b1aafaff0cee..6f95f8672158 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -13,10 +13,7 @@
Vendor, //
},
prelude::*,
- sizes::{
- SZ_16M,
- SZ_256M, //
- },
+ sizes::SZ_16M,
sync::{
atomic::{
Atomic,
@@ -40,7 +37,6 @@ pub(crate) struct NovaCore {
}
const BAR0_SIZE: usize = SZ_16M;
-pub(crate) const BAR1_SIZE: usize = SZ_256M;
// For now we only support Ampere which can use up to 47-bit DMA addresses.
//
@@ -51,7 +47,7 @@ pub(crate) struct NovaCore {
const GPU_DMA_BITS: u32 = 47;
pub(crate) type Bar0 = pci::Bar<BAR0_SIZE>;
-pub(crate) type Bar1 = pci::Bar<BAR1_SIZE>;
+pub(crate) type Bar1 = pci::Bar;
kernel::pci_device_table!(
PCI_TABLE,
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 5f4199e41d16..4d4040d56aba 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -361,18 +361,13 @@ pub(crate) fn run_selftests(
#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
fn run_mm_selftests(self: Pin<&mut Self>, pdev: &pci::Device<device::Bound>) -> Result {
- use crate::driver::BAR1_SIZE;
-
let mmu_version = MmuVersion::from(self.spec.chipset.arch());
// PRAMIN aperture self-tests.
crate::mm::pramin::run_self_test(pdev.as_ref(), self.mm.pramin(), self.spec.chipset)?;
// BAR1 self-tests.
- let bar1 = Arc::pin_init(
- pdev.iomap_region_sized::<BAR1_SIZE>(1, c"nova-core/bar1"),
- GFP_KERNEL,
- )?;
+ let bar1 = Arc::pin_init(pdev.iomap_region(1, c"nova-core/bar1"), GFP_KERNEL)?;
let bar1_access = bar1.access(pdev.as_ref())?;
crate::mm::bar_user::run_self_test(
--
2.34.1
^ permalink raw reply related
* [PATCH v9 21/23] gpu: nova-core: mm: Add BAR1 memory management self-tests
From: Joel Fernandes @ 2026-03-11 0:40 UTC (permalink / raw)
To: linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, Joel Fernandes
In-Reply-To: <20260311004008.2208806-1-joelagnelf@nvidia.com>
Add self-tests for BAR1 access during driver probe when
CONFIG_NOVA_MM_SELFTESTS is enabled (default disabled). This results in
testing the Vmm, GPU buddy allocator and BAR1 region all of which should
function correctly for the tests to pass.
Cc: Nikola Djukic <ndjukic@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
---
drivers/gpu/nova-core/Kconfig | 10 ++
drivers/gpu/nova-core/driver.rs | 2 +
drivers/gpu/nova-core/gpu.rs | 38 ++++
drivers/gpu/nova-core/mm/bar_user.rs | 256 +++++++++++++++++++++++++++
4 files changed, 306 insertions(+)
diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/nova-core/Kconfig
index 6513007bf66f..35de55aabcfc 100644
--- a/drivers/gpu/nova-core/Kconfig
+++ b/drivers/gpu/nova-core/Kconfig
@@ -15,3 +15,13 @@ config NOVA_CORE
This driver is work in progress and may not be functional.
If M is selected, the module will be called nova_core.
+
+config NOVA_MM_SELFTESTS
+ bool "Memory management self-tests"
+ depends on NOVA_CORE
+ help
+ Enable self-tests for the memory management subsystem. When enabled,
+ tests are run during GPU probe to verify PRAMIN aperture access,
+ page table walking, and BAR1 virtual memory mapping functionality.
+
+ This is a testing option and is default-disabled.
diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 3bc264a099de..b1aafaff0cee 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -101,6 +101,8 @@ fn probe(pdev: &pci::Device<Core>, _info: &Self::IdInfo) -> impl PinInit<Self, E
Ok(try_pin_init!(Self {
gpu <- Gpu::new(pdev, bar.clone(), bar.access(pdev.as_ref())?),
+ // Run optional GPU selftests.
+ _: { gpu.run_selftests(pdev)? },
_reg <- auxiliary::Registration::new(
pdev.as_ref(),
c"nova-drm",
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index efff76313b89..022b156de0da 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -349,4 +349,42 @@ pub(crate) fn unbind(&self, dev: &device::Device<device::Core>) {
.inspect(|bar| self.sysmem_flush.unregister(bar))
.is_err());
}
+
+ /// Run selftests on the constructed [`Gpu`].
+ pub(crate) fn run_selftests(
+ mut self: Pin<&mut Self>,
+ pdev: &pci::Device<device::Bound>,
+ ) -> Result {
+ self.as_mut().run_mm_selftests(pdev)?;
+ Ok(())
+ }
+
+ #[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+ fn run_mm_selftests(self: Pin<&mut Self>, pdev: &pci::Device<device::Bound>) -> Result {
+ use crate::driver::BAR1_SIZE;
+
+ let mmu_version = MmuVersion::from(self.spec.chipset.arch());
+
+ // BAR1 self-tests.
+ let bar1 = Arc::pin_init(
+ pdev.iomap_region_sized::<BAR1_SIZE>(1, c"nova-core/bar1"),
+ GFP_KERNEL,
+ )?;
+ let bar1_access = bar1.access(pdev.as_ref())?;
+
+ crate::mm::bar_user::run_self_test(
+ pdev.as_ref(),
+ &self.mm,
+ bar1_access,
+ self.gsp_static_info.bar1_pde_base,
+ mmu_version,
+ )?;
+
+ Ok(())
+ }
+
+ #[cfg(not(CONFIG_NOVA_MM_SELFTESTS))]
+ fn run_mm_selftests(self: Pin<&mut Self>, _pdev: &pci::Device<device::Bound>) -> Result {
+ Ok(())
+ }
}
diff --git a/drivers/gpu/nova-core/mm/bar_user.rs b/drivers/gpu/nova-core/mm/bar_user.rs
index 0d083f3e72c2..d2a2e0ad097a 100644
--- a/drivers/gpu/nova-core/mm/bar_user.rs
+++ b/drivers/gpu/nova-core/mm/bar_user.rs
@@ -154,3 +154,259 @@ fn drop(&mut self) {
}
}
}
+
+/// Check if the PDB has valid, VRAM-backed page tables.
+///
+/// Returns `Err(ENOENT)` if page tables are missing or not in VRAM.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+fn check_valid_page_tables(mm: &GpuMm, pdb_addr: VramAddress) -> Result {
+ use crate::mm::pagetable::{
+ ver2::Pde,
+ AperturePde, //
+ };
+
+ let mut window = mm.pramin().window()?;
+ let pdb_entry_raw = window.try_read64(pdb_addr.raw())?;
+ let pdb_entry = Pde::new(pdb_entry_raw);
+
+ if !pdb_entry.is_valid() {
+ return Err(ENOENT);
+ }
+
+ if pdb_entry.aperture() != AperturePde::VideoMemory {
+ return Err(ENOENT);
+ }
+
+ Ok(())
+}
+
+/// Run MM subsystem self-tests during probe.
+///
+/// Tests page table infrastructure and `BAR1` MMIO access using the `BAR1`
+/// address space. Uses the `GpuMm`'s buddy allocator to allocate page tables
+/// and test pages as needed.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+pub(crate) fn run_self_test(
+ dev: &kernel::device::Device,
+ mm: &GpuMm,
+ bar1: &crate::driver::Bar1,
+ bar1_pdb: u64,
+ mmu_version: MmuVersion,
+) -> Result {
+ use crate::mm::{
+ vmm::Vmm,
+ PAGE_SIZE, //
+ };
+ use kernel::gpu::buddy::{GpuBuddyAllocFlags, GpuBuddyAllocMode};
+ use kernel::ptr::Alignment;
+ use kernel::sizes::{
+ SZ_16K,
+ SZ_32K,
+ SZ_4K,
+ SZ_64K, //
+ };
+
+ // Self-tests only support MMU v2 for now.
+ if mmu_version != MmuVersion::V2 {
+ dev_info!(
+ dev,
+ "MM: Skipping self-tests for MMU {:?} (only V2 supported)\n",
+ mmu_version
+ );
+ return Ok(());
+ }
+
+ // Test patterns.
+ const PATTERN_PRAMIN: u32 = 0xDEAD_BEEF;
+ const PATTERN_BAR1: u32 = 0xCAFE_BABE;
+
+ dev_info!(dev, "MM: Starting self-test...\n");
+
+ let pdb_addr = VramAddress::new(bar1_pdb);
+
+ // Check if initial page tables are in VRAM.
+ if check_valid_page_tables(mm, pdb_addr).is_err() {
+ dev_info!(dev, "MM: Self-test SKIPPED - no valid VRAM page tables\n");
+ return Ok(());
+ }
+
+ // Set up a test page from the buddy allocator.
+ let test_page_blocks = KBox::pin_init(
+ mm.buddy().alloc_blocks(
+ GpuBuddyAllocMode::Simple,
+ SZ_4K,
+ Alignment::new::<SZ_4K>(),
+ GpuBuddyAllocFlags::default(),
+ ),
+ GFP_KERNEL,
+ )?;
+ let test_vram_offset = test_page_blocks.iter().next().ok_or(ENOMEM)?.offset();
+ let test_vram = VramAddress::new(test_vram_offset);
+ let test_pfn = Pfn::from(test_vram);
+
+ // Create a VMM of size 64K to track virtual memory mappings.
+ let mut vmm = Vmm::new(pdb_addr, MmuVersion::V2, SZ_64K.into_safe_cast())?;
+
+ // Create a test mapping.
+ let mapped = vmm.map_pages(mm, &[test_pfn], None, true)?;
+ let test_vfn = mapped.vfn_start;
+
+ // Pre-compute test addresses for the PRAMIN to BAR1 read test.
+ let vfn_offset: usize = test_vfn.raw().into_safe_cast();
+ let bar1_base_offset = vfn_offset.checked_mul(PAGE_SIZE).ok_or(EOVERFLOW)?;
+ let bar1_read_offset: usize = bar1_base_offset + 0x100;
+ let vram_read_addr: usize = test_vram.raw() + 0x100;
+
+ // Test 1: Write via PRAMIN, read via BAR1.
+ {
+ let mut window = mm.pramin().window()?;
+ window.try_write32(vram_read_addr, PATTERN_PRAMIN)?;
+ }
+
+ // Read back via BAR1 aperture.
+ let bar1_value = bar1.try_read32(bar1_read_offset)?;
+
+ let test1_passed = if bar1_value == PATTERN_PRAMIN {
+ true
+ } else {
+ dev_err!(
+ dev,
+ "MM: Test 1 FAILED - Expected {:#010x}, got {:#010x}\n",
+ PATTERN_PRAMIN,
+ bar1_value
+ );
+ false
+ };
+
+ // Cleanup - invalidate PTE.
+ vmm.unmap_pages(mm, mapped)?;
+
+ // Test 2: Two-phase prepare/execute API.
+ let prepared = vmm.prepare_map(mm, 1, None)?;
+ let mapped2 = vmm.execute_map(mm, prepared, &[test_pfn], true)?;
+ let readback = vmm.read_mapping(mm, mapped2.vfn_start)?;
+ let test2_passed = if readback == Some(test_pfn) {
+ true
+ } else {
+ dev_err!(dev, "MM: Test 2 FAILED - Two-phase map readback mismatch\n");
+ false
+ };
+ vmm.unmap_pages(mm, mapped2)?;
+
+ // Test 3: Range-constrained allocation with a hole — exercises block.size()-driven
+ // BAR1 mapping. A 4K hole is punched at base+16K, then a single 32K allocation
+ // is requested within [base, base+36K). The buddy allocator must split around the
+ // hole, returning multiple blocks (expected: {16K, 4K, 8K, 4K} = 32K total).
+ // Each block is mapped into BAR1 and verified via PRAMIN read-back.
+ //
+ // Address layout (base = 0x10000):
+ // [ 16K ] [HOLE 4K] [4K] [ 8K ] [4K]
+ // 0x10000 0x14000 0x15000 0x16000 0x18000 0x19000
+ let range_base: u64 = SZ_64K.into_safe_cast();
+ let sz_4k: u64 = SZ_4K.into_safe_cast();
+ let sz_16k: u64 = SZ_16K.into_safe_cast();
+ let sz_32k_4k: u64 = (SZ_32K + SZ_4K).into_safe_cast();
+
+ // Punch a 4K hole at base+16K so the subsequent 32K allocation must split.
+ let _hole = KBox::pin_init(
+ mm.buddy().alloc_blocks(
+ GpuBuddyAllocMode::Range {
+ start: range_base + sz_16k,
+ end: range_base + sz_16k + sz_4k,
+ },
+ SZ_4K,
+ Alignment::new::<SZ_4K>(),
+ GpuBuddyAllocFlags::default(),
+ ),
+ GFP_KERNEL,
+ )?;
+
+ // Allocate 32K within [base, base+36K). The hole forces the allocator to return
+ // split blocks whose sizes are determined by buddy alignment.
+ let blocks = KBox::pin_init(
+ mm.buddy().alloc_blocks(
+ GpuBuddyAllocMode::Range {
+ start: range_base,
+ end: range_base + sz_32k_4k,
+ },
+ SZ_32K,
+ Alignment::new::<SZ_4K>(),
+ GpuBuddyAllocFlags::default(),
+ ),
+ GFP_KERNEL,
+ )?;
+
+ let mut test3_passed = true;
+ let mut total_size = 0usize;
+
+ for block in blocks.iter() {
+ total_size += block.size();
+
+ // Map all pages of this block.
+ let page_size: u64 = PAGE_SIZE.into_safe_cast();
+ let num_pages = block.size() / PAGE_SIZE;
+
+ let mut pfns = KVec::new();
+ for j in 0..num_pages {
+ let j_u64: u64 = j.into_safe_cast();
+ pfns.push(
+ Pfn::from(VramAddress::new(
+ block.offset() + j_u64.checked_mul(page_size).ok_or(EOVERFLOW)?,
+ )),
+ GFP_KERNEL,
+ )?;
+ }
+
+ let mapped = vmm.map_pages(mm, &pfns, None, true)?;
+ let bar1_base_vfn: usize = mapped.vfn_start.raw().into_safe_cast();
+ let bar1_base = bar1_base_vfn.checked_mul(PAGE_SIZE).ok_or(EOVERFLOW)?;
+
+ for j in 0..num_pages {
+ let page_bar1_off = bar1_base + j * PAGE_SIZE;
+ let j_u64: u64 = j.into_safe_cast();
+ let page_phys = block.offset()
+ + j_u64
+ .checked_mul(PAGE_SIZE.into_safe_cast())
+ .ok_or(EOVERFLOW)?;
+
+ bar1.try_write32(PATTERN_BAR1, page_bar1_off)?;
+
+ let pramin_val = {
+ let mut window = mm.pramin().window()?;
+ window.try_read32(page_phys.into_safe_cast())?
+ };
+
+ if pramin_val != PATTERN_BAR1 {
+ dev_err!(
+ dev,
+ "MM: Test 3 FAILED block offset {:#x} page {} (val={:#x})\n",
+ block.offset(),
+ j,
+ pramin_val
+ );
+ test3_passed = false;
+ }
+ }
+
+ vmm.unmap_pages(mm, mapped)?;
+ }
+
+ // Verify aggregate: all returned block sizes must sum to allocation size.
+ if total_size != SZ_32K {
+ dev_err!(
+ dev,
+ "MM: Test 3 FAILED - total size {} != expected {}\n",
+ total_size,
+ SZ_32K
+ );
+ test3_passed = false;
+ }
+
+ if test1_passed && test2_passed && test3_passed {
+ dev_info!(dev, "MM: All self-tests PASSED\n");
+ Ok(())
+ } else {
+ dev_err!(dev, "MM: Self-tests FAILED\n");
+ Err(EIO)
+ }
+}
--
2.34.1
^ permalink raw reply related
* [PATCH v9 22/23] gpu: nova-core: mm: Add PRAMIN aperture self-tests
From: Joel Fernandes @ 2026-03-11 0:40 UTC (permalink / raw)
To: linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, Joel Fernandes
In-Reply-To: <20260311004008.2208806-1-joelagnelf@nvidia.com>
Add self-tests for the PRAMIN aperture mechanism to verify correct
operation during GPU probe. The tests validate various alignment
requirements and corner cases.
The tests are default disabled and behind CONFIG_NOVA_MM_SELFTESTS.
When enabled, tests run after GSP boot during probe.
Cc: Nikola Djukic <ndjukic@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
---
drivers/gpu/nova-core/gpu.rs | 3 +
drivers/gpu/nova-core/mm/pramin.rs | 209 +++++++++++++++++++++++++++++
2 files changed, 212 insertions(+)
diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 022b156de0da..5f4199e41d16 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -365,6 +365,9 @@ fn run_mm_selftests(self: Pin<&mut Self>, pdev: &pci::Device<device::Bound>) ->
let mmu_version = MmuVersion::from(self.spec.chipset.arch());
+ // PRAMIN aperture self-tests.
+ crate::mm::pramin::run_self_test(pdev.as_ref(), self.mm.pramin(), self.spec.chipset)?;
+
// BAR1 self-tests.
let bar1 = Arc::pin_init(
pdev.iomap_region_sized::<BAR1_SIZE>(1, c"nova-core/bar1"),
diff --git a/drivers/gpu/nova-core/mm/pramin.rs b/drivers/gpu/nova-core/mm/pramin.rs
index 707794f49add..bf87eb84805f 100644
--- a/drivers/gpu/nova-core/mm/pramin.rs
+++ b/drivers/gpu/nova-core/mm/pramin.rs
@@ -195,6 +195,11 @@ pub(crate) fn new(
}))
}
+ /// Returns the valid VRAM region for this PRAMIN instance.
+ pub(crate) fn vram_region(&self) -> &Range<u64> {
+ &self.vram_region
+ }
+
/// Acquire exclusive PRAMIN access.
///
/// Returns a [`PraminWindow`] guard that provides VRAM read/write accessors.
@@ -291,3 +296,207 @@ fn compute_window(
define_pramin_write!(try_write32, u32);
define_pramin_write!(try_write64, u64);
}
+
+/// Offset within the VRAM region to use as the self-test area.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+const SELFTEST_REGION_OFFSET: usize = 0x1000;
+
+/// Test read/write at byte-aligned locations.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+fn test_byte_readwrite(
+ dev: &kernel::device::Device,
+ win: &mut PraminWindow<'_>,
+ base: usize,
+) -> Result {
+ for i in 0u8..4 {
+ let offset = base + 1 + usize::from(i);
+ let val = 0xA0 + i;
+ win.try_write8(offset, val)?;
+ let read_val = win.try_read8(offset)?;
+ if read_val != val {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - offset {:#x}: wrote {:#x}, read {:#x}\n",
+ offset,
+ val,
+ read_val
+ );
+ return Err(EIO);
+ }
+ }
+ Ok(())
+}
+
+/// Test writing a `u32` and reading back as individual `u8`s.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+fn test_u32_as_bytes(
+ dev: &kernel::device::Device,
+ win: &mut PraminWindow<'_>,
+ base: usize,
+) -> Result {
+ let offset = base + 0x10;
+ let val: u32 = 0xDEADBEEF;
+ win.try_write32(offset, val)?;
+
+ // Read back as individual bytes (little-endian: EF BE AD DE).
+ let expected_bytes: [u8; 4] = [0xEF, 0xBE, 0xAD, 0xDE];
+ for (i, &expected) in expected_bytes.iter().enumerate() {
+ let read_val = win.try_read8(offset + i)?;
+ if read_val != expected {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - offset {:#x}: expected {:#x}, read {:#x}\n",
+ offset + i,
+ expected,
+ read_val
+ );
+ return Err(EIO);
+ }
+ }
+ Ok(())
+}
+
+/// Test window repositioning across 1MB boundaries.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+fn test_window_reposition(
+ dev: &kernel::device::Device,
+ win: &mut PraminWindow<'_>,
+ base: usize,
+) -> Result {
+ let offset_a: usize = base;
+ let offset_b: usize = base + 0x200000; // base + 2MB (different 1MB region).
+ let val_a: u32 = 0x11111111;
+ let val_b: u32 = 0x22222222;
+
+ win.try_write32(offset_a, val_a)?;
+ win.try_write32(offset_b, val_b)?;
+
+ let read_b = win.try_read32(offset_b)?;
+ if read_b != val_b {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - offset {:#x}: expected {:#x}, read {:#x}\n",
+ offset_b,
+ val_b,
+ read_b
+ );
+ return Err(EIO);
+ }
+
+ let read_a = win.try_read32(offset_a)?;
+ if read_a != val_a {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - offset {:#x}: expected {:#x}, read {:#x}\n",
+ offset_a,
+ val_a,
+ read_a
+ );
+ return Err(EIO);
+ }
+ Ok(())
+}
+
+/// Test that offsets outside the VRAM region are rejected.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+fn test_invalid_offset(
+ dev: &kernel::device::Device,
+ win: &mut PraminWindow<'_>,
+ vram_end: u64,
+) -> Result {
+ let invalid_offset: usize = vram_end.into_safe_cast();
+ let result = win.try_read32(invalid_offset);
+ if result.is_ok() {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - read at invalid offset {:#x} should have failed\n",
+ invalid_offset
+ );
+ return Err(EIO);
+ }
+ Ok(())
+}
+
+/// Test that misaligned multi-byte accesses are rejected.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+fn test_misaligned_access(
+ dev: &kernel::device::Device,
+ win: &mut PraminWindow<'_>,
+ base: usize,
+) -> Result {
+ // `u16` at odd offset (not 2-byte aligned).
+ let offset_u16 = base + 0x21;
+ if win.try_write16(offset_u16, 0xABCD).is_ok() {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - misaligned u16 write at {:#x} should have failed\n",
+ offset_u16
+ );
+ return Err(EIO);
+ }
+
+ // `u32` at 2-byte-aligned (not 4-byte-aligned) offset.
+ let offset_u32 = base + 0x32;
+ if win.try_write32(offset_u32, 0x12345678).is_ok() {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - misaligned u32 write at {:#x} should have failed\n",
+ offset_u32
+ );
+ return Err(EIO);
+ }
+
+ // `u64` read at 4-byte-aligned (not 8-byte-aligned) offset.
+ let offset_u64 = base + 0x44;
+ if win.try_read64(offset_u64).is_ok() {
+ dev_err!(
+ dev,
+ "PRAMIN: FAIL - misaligned u64 read at {:#x} should have failed\n",
+ offset_u64
+ );
+ return Err(EIO);
+ }
+ Ok(())
+}
+
+/// Run PRAMIN self-tests during boot if self-tests are enabled.
+#[cfg(CONFIG_NOVA_MM_SELFTESTS)]
+pub(crate) fn run_self_test(
+ dev: &kernel::device::Device,
+ pramin: &Pramin,
+ chipset: crate::gpu::Chipset,
+) -> Result {
+ use crate::gpu::Architecture;
+
+ // PRAMIN uses NV_PBUS_BAR0_WINDOW which is only available on pre-Hopper GPUs.
+ // Hopper+ uses NV_XAL_EP_BAR0_WINDOW instead, requiring a separate HAL that
+ // has not been implemented yet.
+ if !matches!(
+ chipset.arch(),
+ Architecture::Turing | Architecture::Ampere | Architecture::Ada
+ ) {
+ dev_info!(
+ dev,
+ "PRAMIN: Skipping self-tests for {:?} (only pre-Hopper supported)\n",
+ chipset
+ );
+ return Ok(());
+ }
+
+ dev_info!(dev, "PRAMIN: Starting self-test...\n");
+
+ let vram_region = pramin.vram_region();
+ let base: usize = vram_region.start.into_safe_cast();
+ let base = base + SELFTEST_REGION_OFFSET;
+ let vram_end = vram_region.end;
+ let mut win = pramin.window()?;
+
+ test_byte_readwrite(dev, &mut win, base)?;
+ test_u32_as_bytes(dev, &mut win, base)?;
+ test_window_reposition(dev, &mut win, base)?;
+ test_invalid_offset(dev, &mut win, vram_end)?;
+ test_misaligned_access(dev, &mut win, base)?;
+
+ dev_info!(dev, "PRAMIN: All self-tests PASSED\n");
+ Ok(())
+}
--
2.34.1
^ permalink raw reply related
* [PATCH v9 19/23] gpu: nova-core: Add BAR1 aperture type and size constant
From: Joel Fernandes @ 2026-03-11 0:40 UTC (permalink / raw)
To: linux-kernel
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Dave Airlie, Daniel Almeida, Koen Koning,
dri-devel, nouveau, rust-for-linux, Nikola Djukic,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Alex Deucher,
Christian König, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Huang Rui, Matthew Auld, Matthew Brost,
Lucas De Marchi, Thomas Hellström, Helge Deller, Alex Gaynor,
Boqun Feng, John Hubbard, Alistair Popple, Timur Tabi, Edwin Peer,
Alexandre Courbot, Andrea Righi, Andy Ritger, Zhi Wang,
Balbir Singh, Philipp Stanner, Elle Rhumsaa, alexeyi,
Eliot Courtney, joel, linux-doc, amd-gfx, intel-gfx, intel-xe,
linux-fbdev, Joel Fernandes
In-Reply-To: <20260311004008.2208806-1-joelagnelf@nvidia.com>
Add BAR1_SIZE constant and Bar1 type alias for the 256MB BAR1 aperture.
These are prerequisites for BAR1 memory access functionality.
Cc: Nikola Djukic <ndjukic@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
---
drivers/gpu/nova-core/driver.rs | 8 +++++++-
drivers/gpu/nova-core/gsp/commands.rs | 4 ++++
drivers/gpu/nova-core/gsp/fw/commands.rs | 8 ++++++++
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 84b0e1703150..b4311adf4cef 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -13,7 +13,10 @@
Vendor, //
},
prelude::*,
- sizes::SZ_16M,
+ sizes::{
+ SZ_16M,
+ SZ_256M, //
+ },
sync::{
atomic::{
Atomic,
@@ -37,6 +40,7 @@ pub(crate) struct NovaCore {
}
const BAR0_SIZE: usize = SZ_16M;
+pub(crate) const BAR1_SIZE: usize = SZ_256M;
// For now we only support Ampere which can use up to 47-bit DMA addresses.
//
@@ -47,6 +51,8 @@ pub(crate) struct NovaCore {
const GPU_DMA_BITS: u32 = 47;
pub(crate) type Bar0 = pci::Bar<BAR0_SIZE>;
+#[expect(dead_code)]
+pub(crate) type Bar1 = pci::Bar<BAR1_SIZE>;
kernel::pci_device_table!(
PCI_TABLE,
diff --git a/drivers/gpu/nova-core/gsp/commands.rs b/drivers/gpu/nova-core/gsp/commands.rs
index 18dd86a38d46..1901c8928ab8 100644
--- a/drivers/gpu/nova-core/gsp/commands.rs
+++ b/drivers/gpu/nova-core/gsp/commands.rs
@@ -190,6 +190,9 @@ fn init(&self) -> impl Init<Self::Command, Self::InitError> {
/// The reply from the GSP to the [`GetGspStaticInfo`] command.
pub(crate) struct GetGspStaticInfoReply {
gpu_name: [u8; 64],
+ /// BAR1 Page Directory Entry base address.
+ #[expect(dead_code)]
+ pub(crate) bar1_pde_base: u64,
/// Usable FB (VRAM) region for driver memory allocation.
pub(crate) usable_fb_region: Range<u64>,
/// End of VRAM.
@@ -211,6 +214,7 @@ fn read(
Ok(GetGspStaticInfoReply {
gpu_name: msg.gpu_name_str(),
+ bar1_pde_base: msg.bar1_pde_base(),
usable_fb_region: base..base.saturating_add(size),
total_fb_end,
})
diff --git a/drivers/gpu/nova-core/gsp/fw/commands.rs b/drivers/gpu/nova-core/gsp/fw/commands.rs
index acaf92cd6735..75a3d602e6ce 100644
--- a/drivers/gpu/nova-core/gsp/fw/commands.rs
+++ b/drivers/gpu/nova-core/gsp/fw/commands.rs
@@ -117,6 +117,14 @@ impl GspStaticConfigInfo {
self.0.gpuNameString
}
+ /// Returns the BAR1 Page Directory Entry base address.
+ ///
+ /// This is the root page table address for BAR1 virtual memory,
+ /// set up by GSP-RM firmware.
+ pub(crate) fn bar1_pde_base(&self) -> u64 {
+ self.0.bar1PdeBase
+ }
+
/// Extract the first usable FB region from GSP firmware data.
///
/// Returns the first region suitable for driver memory allocation as a `(base, size)` tuple.
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox