From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: gpu: nova-core: mm: Add support to use PRAMIN windows to write to VRAM Date: Tue, 28 Apr 2026 15:31:59 +1000 Message-ID: In-Reply-To: <20260425211454.174696-5-joelagnelf@nvidia.com> References: <20260425211454.174696-1-joelagnelf@nvidia.com> <20260425211454.174696-5-joelagnelf@nvidia.com> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Patch Review Introduces the PRAMIN aperture subsystem =E2=80=94 a 1MB sliding window int= o VRAM via BAR0. Well-documented with a clear two-level API (`Pramin` + `Pr= aminWindow`). **Issue =E2=80=94 missing register read-back after window reposition:** ```rust fn write_window_base(bar: &Bar0, base: u64) -> Result { let window_base =3D (base >> 16) as u32; bar.write_reg( regs::NV_PBUS_BAR0_WINDOW::zeroed() .with_target(Bar0WindowTarget::Vram) .try_with_window_base(window_base)?, ); Ok(()) } ``` After writing `NV_PBUS_BAR0_WINDOW`, there is no read-back to flush the wri= te through the PCIe posting buffer. The upstream nouveau driver reads back = the register after writing it. Without this, a subsequent MMIO access throu= gh the new window position could race with the register write still in the = PCIe write-posting queue, potentially reading stale data from the old windo= w position. Consider adding `let _ =3D bar.read(regs::NV_PBUS_BAR0_WINDOW);= ` after the write. **Issue =E2=80=94 doc examples don't match API:** The doc examples at lines 33-34 show: ```rust pramin::Pramin::new(devres_bar, dev, chipset, vram_region)? ``` But the actual signature (line 192) is: ```rust pub(crate) fn new(bar: Arc>, dev: &device::Device, vram_region: Range) -> Result> ``` The examples pass a `chipset` parameter that doesn't exist. These doc examp= les would fail to compile. --- Generated by Claude Code Patch Reviewer