<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-next.git/drivers/gpu/nova-core/fb/hal, branch master</title>
<subtitle>Linux kernel latest source</subtitle>
<id>http://mirrors.hust.edu.cn/git/linux-next.git/atom?h=master</id>
<link rel='self' href='http://mirrors.hust.edu.cn/git/linux-next.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/'/>
<updated>2026-08-05T05:20:37+00:00</updated>
<entry>
<title>gpu: nova-core: return non-WPR heap size as u64 from HALs</title>
<updated>2026-08-05T05:20:37+00:00</updated>
<author>
<name>Eliot Courtney</name>
<email>ecourtney@nvidia.com</email>
</author>
<published>2026-08-04T05:41:14+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=744e168d62fc50b362a4835f77feafd417b965a1'/>
<id>urn:sha1:744e168d62fc50b362a4835f77feafd417b965a1</id>
<content type='text'>
This is always immediately widened to u64, so just return it as a u64
from the beginning.

Signed-off-by: Eliot Courtney &lt;ecourtney@nvidia.com&gt;
Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-3-ac858b6a1935@nvidia.com
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: correct FRTS vidmem offset calculation</title>
<updated>2026-08-05T05:20:36+00:00</updated>
<author>
<name>Eliot Courtney</name>
<email>ecourtney@nvidia.com</email>
</author>
<published>2026-08-04T05:41:12+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=5c9deba5578db5a3ea05be8a3e4a59ecb08ee76f'/>
<id>urn:sha1:5c9deba5578db5a3ea05be8a3e4a59ecb08ee76f</id>
<content type='text'>
Currently, the frts vidmem offset is calculated based on the non-wpr
heap size and pmu reservation size, but this is not right. The layout
actually looks like this:

| non-wpr heap | WPR2 .. FRTS | PMU reserved | ... | VGA workspace |

It's just by coincidence + generous alignment that the values happened
to match. Instead, define a per-architecture reserved size at the end of
the framebuffer and use this plus the PMU reserved size to calculate the
frts vidmem offset.

Fixes: d317e4585fa3 ("gpu: nova-core: Hopper/Blackwell: add FSP Chain of Trust boot")
Signed-off-by: Eliot Courtney &lt;ecourtney@nvidia.com&gt;
Link: https://patch.msgid.link/20260804-blackwell-fixes-v4-1-ac858b6a1935@nvidia.com
[acourbot: add comment clarifying reason for testing pmu_reserved_size.]
[acourbot: make fb_end_reserved_size() return u64.]
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: Move PFB registers definitions</title>
<updated>2026-07-30T04:01:13+00:00</updated>
<author>
<name>Antonin Malzieu Ridolfi</name>
<email>dev@nanonej.com</email>
</author>
<published>2026-07-27T15:51:52+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=81aa6f190aa0e9ff752fcd0a9eda676458e23133'/>
<id>urn:sha1:81aa6f190aa0e9ff752fcd0a9eda676458e23133</id>
<content type='text'>
Move PFB registers definitions into fb module and update registers
visibility.

Suggested-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
Suggested-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
Signed-off-by: Antonin Malzieu Ridolfi &lt;dev@nanonej.com&gt;
Link: https://patch.msgid.link/20260727-nova-core-regs-split-v2-2-21b5e6e32ea5@nanonej.com
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: fb: fix Blackwell flush address composition</title>
<updated>2026-06-17T07:17:27+00:00</updated>
<author>
<name>John Hubbard</name>
<email>jhubbard@nvidia.com</email>
</author>
<published>2026-06-11T01:19:01+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=746e0e1cc93d15925a4141779c8ee789ff5ea392'/>
<id>urn:sha1:746e0e1cc93d15925a4141779c8ee789ff5ea392</id>
<content type='text'>
The Blackwell sysmem flush read helper composed the 64-bit address as
lo | (hi &lt;&lt; 32). Write it as (hi &lt;&lt; 32) | lo, the order humans expect
to read, matching the bit layout and the new Hopper helper.

Signed-off-by: John Hubbard &lt;jhubbard@nvidia.com&gt;
Link: https://patch.msgid.link/20260611011901.84517-4-jhubbard@nvidia.com
[acourbot: separate unrelated changes into their own patch.]
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: Hopper: use correct sysmem flush registers</title>
<updated>2026-06-17T07:17:21+00:00</updated>
<author>
<name>John Hubbard</name>
<email>jhubbard@nvidia.com</email>
</author>
<published>2026-06-11T01:19:00+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=84d58754370fc7bb8ff7af5213bb9aa967a38be2'/>
<id>urn:sha1:84d58754370fc7bb8ff7af5213bb9aa967a38be2</id>
<content type='text'>
Hopper has its own FBHUB sysmem flush page registers, but the Hopper
framebuffer HAL delegates to the Ampere NISO path, which encodes the
address with an 8-bit right-shift. That programs the wrong value into
the wrong registers, so the GPU's sysmembar flush targets the wrong
system memory address.

Add Hopper's FBHUB flush registers and program them directly from the
Hopper HAL.

This has not yet been tested on real Hopper hardware (that's true for
nova-core in general).

Signed-off-by: John Hubbard &lt;jhubbard@nvidia.com&gt;
Link: https://patch.msgid.link/20260611011901.84517-3-jhubbard@nvidia.com
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: Blackwell: use absolute FBHUB0 flush registers</title>
<updated>2026-06-17T06:56:17+00:00</updated>
<author>
<name>John Hubbard</name>
<email>jhubbard@nvidia.com</email>
</author>
<published>2026-06-11T01:18:59+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=21baef62022fbcca539fca2171e2d3ff15fcb9d3'/>
<id>urn:sha1:21baef62022fbcca539fca2171e2d3ff15fcb9d3</id>
<content type='text'>
The GB20x sysmem flush registers were defined relative to an Fbhub0Base
register window, but there is exactly one FBHUB0 base, so expressing them
as base-plus-offset only adds indirection.

Rename these to FBHUB0 and give them their fixed absolute addresses,
dropping the base struct and its RegisterBase impl.

No functional changes.

Signed-off-by: John Hubbard &lt;jhubbard@nvidia.com&gt;
Link: https://patch.msgid.link/20260611011901.84517-2-jhubbard@nvidia.com
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: move lifetime to `Bar0`</title>
<updated>2026-06-03T20:10:51+00:00</updated>
<author>
<name>Gary Guo</name>
<email>gary@garyguo.net</email>
</author>
<published>2026-06-02T17:04:07+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=99676aed1fec109d62822e21a06760eb098dc5f4'/>
<id>urn:sha1:99676aed1fec109d62822e21a06760eb098dc5f4</id>
<content type='text'>
Currently Nova code uses `&amp;'a Bar0` a lot. This is `&amp;'a Mmio`, where `Mmio`
represents an owned MMIO region; this type only exists as a target for
`Deref` so `Bar` and `IoMem` can share code and should be avoided to be
named directly. The upcoming I/O projection series would make `Io` trait
much simpler to implement, and thus the owned MMIO type would be removed
in favour of direct `Io` implementation on `Bar` and `IoMem`.

Add lifetime parameter to `Bar0&lt;'a&gt;` and change it to be alias of `&amp;'a
pci::Bar&lt;'a, ..&gt;`. This also prepares Nova core so that when I/O projection
series land, this could be changed to using a MMIO view type directly which
avoids double indirection.

Signed-off-by: Gary Guo &lt;gary@garyguo.net&gt;
Acked-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
Reviewed-by: Eliot Courtney &lt;ecourtney@nvidia.com&gt;
Link: https://patch.msgid.link/20260602170416.2268531-1-gary@kernel.org
[ Rebase onto latest drm-rust-next (Blackwell enablement). - Danilo ]
Signed-off-by: Danilo Krummrich &lt;dakr@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: Blackwell: use correct sysmem flush registers</title>
<updated>2026-06-02T13:33:15+00:00</updated>
<author>
<name>John Hubbard</name>
<email>jhubbard@nvidia.com</email>
</author>
<published>2026-06-02T03:20:54+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=a5bf742bc28a4e064059c8d137970e56669a21a0'/>
<id>urn:sha1:a5bf742bc28a4e064059c8d137970e56669a21a0</id>
<content type='text'>
Blackwell GPUs moved the sysmem flush page registers away from the
Ampere/Ada location. GB10x routes the flush through a pair of HSHUB0
register sets (primary and egress) that must both be programmed to
the same address. GB20x routes it through FBHUB0.

Define these registers relative to their HSHUB0 and FBHUB0 bases, as
Open RM does, and implement the flush paths in the GB10x and GB20x
framebuffer HALs.

Signed-off-by: John Hubbard &lt;jhubbard@nvidia.com&gt;
Reviewed-by: Eliot Courtney &lt;ecourtney@nvidia.com&gt;
Link: https://patch.msgid.link/20260602032111.224790-7-jhubbard@nvidia.com
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: Hopper/Blackwell: larger non-WPR heap</title>
<updated>2026-06-02T13:33:15+00:00</updated>
<author>
<name>John Hubbard</name>
<email>jhubbard@nvidia.com</email>
</author>
<published>2026-06-02T03:20:52+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=fcdd74aa8ca6ca7f4922d92da932891996734d15'/>
<id>urn:sha1:fcdd74aa8ca6ca7f4922d92da932891996734d15</id>
<content type='text'>
Hopper and Blackwell need a larger non-WPR heap than the 1 MiB that
earlier architectures use. Hopper and Blackwell GB10x need 2 MiB, while
Blackwell GB20x needs 2 MiB + 128 KiB. These sizes diverge by family,
so give Hopper and each Blackwell family its own framebuffer HAL and
select the non-WPR heap size per chipset family.

Signed-off-by: John Hubbard &lt;jhubbard@nvidia.com&gt;
Reviewed-by: Eliot Courtney &lt;ecourtney@nvidia.com&gt;
Link: https://patch.msgid.link/20260602032111.224790-5-jhubbard@nvidia.com
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
<entry>
<title>gpu: nova-core: Blackwell: compute PMU-reserved framebuffer size</title>
<updated>2026-06-02T13:33:15+00:00</updated>
<author>
<name>John Hubbard</name>
<email>jhubbard@nvidia.com</email>
</author>
<published>2026-06-02T03:20:51+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/linux-next.git/commit/?id=206bb143689e493a7ebb0f2259e462c35125a89a'/>
<id>urn:sha1:206bb143689e493a7ebb0f2259e462c35125a89a</id>
<content type='text'>
GSP boot needs to know how much framebuffer memory is reserved for
the PMU. Compute it per architecture: Blackwell dGPUs reserve a
non-zero amount, earlier architectures leave it at zero, matching
Open RM behavior.

Signed-off-by: John Hubbard &lt;jhubbard@nvidia.com&gt;
Reviewed-by: Eliot Courtney &lt;ecourtney@nvidia.com&gt;
Link: https://patch.msgid.link/20260602032111.224790-4-jhubbard@nvidia.com
Co-developed-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
Signed-off-by: Alexandre Courbot &lt;acourbot@nvidia.com&gt;
</content>
</entry>
</feed>
