On 10/2/25 2:05 PM, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
(I think this was a conflict between the DRM tree and the MM tree already
before.)
The resolution looks good to me, thanks!
- Danilo
On Wed Oct 1, 2025 at 6:06 AM CEST, Dave Airlie wrote:
> The other big thing here is rust stuff. There is a pin-init rework
> which may also be merged in other trees (I can't remember).
I have taken the pin-init PR through the drm-rust tree for this cycle -- no
other tree involved.
- Danilo
On Tue Sep 30, 2025 at 4:45 PM CEST, Joel Fernandes wrote:
> MAINTAINERS | 7 +
> drivers/gpu/nova-core/falcon.rs | 2 +-
> drivers/gpu/nova-core/falcon/gsp.rs | 4 +-
> drivers/gpu/nova-core/falcon/sec2.rs | 2 +-
> driver
On 9/30/25 3:16 PM, Alistair Popple wrote:
> +impl GspRpcHeader {
> +pub(crate) fn new(cmd_size: u32, function: u32) -> Self {
> +Self(bindings::rpc_message_header_v {
> +// TODO: magic number
> +header_version: 0x0300,
> +signature: bindings::NV_
On 9/30/25 3:16 PM, Alistair Popple wrote:
> +// SAFETY: No DMA allocations have been made yet
> +unsafe { pdev.dma_set_mask_and_coherent(DmaMask::new::<47>())? };
I think you forgot to derive the value from the relevant sources, i.e. physical
bus, DMA controller and MMU capabiliti
On 9/30/25 3:16 PM, Alistair Popple wrote:
> Changes since v2:
>
> The main change since v2 has been to make all firmware bindings
> completely opaque. It has been made clear this is a pre-requisite for
> this series to progress upstream as it should make supporting
> different firmware versions e
On Tue Sep 30, 2025 at 11:00 AM CEST, Philipp Stanner wrote:
> +Cc Sima, Dave
>
> On Mon, 2025-09-29 at 16:07 +0200, Danilo Krummrich wrote:
>> On Wed Sep 3, 2025 at 5:23 PM CEST, Tvrtko Ursulin wrote:
>> > This is another respin of this old work^1 which since v7 is a
On Mon Sep 29, 2025 at 9:39 AM CEST, Alistair Popple wrote:
> On 2025-09-29 at 17:06 +1000, Danilo Krummrich wrote...
>> On Mon Sep 29, 2025 at 2:19 AM CEST, Alistair Popple wrote:
>> > On 2025-09-26 at 22:00 +1000, Danilo Krummrich wrote...
>> >> On Tue Sep 23,
On Fri Sep 26, 2025 at 6:10 PM CEST, Boqun Feng wrote:
> I missed this part, and I don't think kernel::sync is where dma_fence
> should be, as kernel::sync is mostly for the basic synchronization
> between threads/irqs. dma_fence is probably better to be grouped with
> dma-buf and other dma related
Don't use unwrap() to extract an Option, instead handle the
error condition gracefully.
Fixes: a841614e607c ("gpu: nova-core: firmware: process and prepare the GSP
firmware")
Signed-off-by: Danilo Krummrich
---
drivers/gpu/nova-core/firmware/gsp.rs | 7 ---
1 file change
On Tue Sep 23, 2025 at 6:29 AM CEST, Alistair Popple wrote:
> On 2025-09-23 at 12:16 +1000, John Hubbard wrote...
>> On 9/22/25 9:08 AM, Danilo Krummrich wrote:
>> > On 9/22/25 1:30 PM, Alistair Popple wrote:
>> >> +// SAFETY: No DMA allocations have bee
On 9/25/25 3:54 PM, Tamir Duberstein wrote:
> C-String literals were added in Rust 1.77. Replace instances of
> `kernel::c_str!` with C-String literals where possible.
>
> Signed-off-by: Tamir Duberstein
Acked-by: Danilo Krummrich
On Wed Sep 24, 2025 at 4:38 PM CEST, Yury Norov wrote:
> I didn't ask explicitly, and maybe it's a good time to ask now: Joel,
> Danilo and everyone, have you considered adopting this project in
> kernel?
>
> The bitfield_struct builds everything into the structure:
>
> use bitfield_struct:
On Wed Sep 24, 2025 at 12:52 PM CEST, Greg KH wrote:
> Ok, great, but right now it's not doing that from what I am seeing when
> reading the code. Shouldn't IoMem::new() take that as an argument?
That's correct, neither IoMem nor pci::Bar do consider it yet; it's on the list
of things that still
On 9/22/25 1:30 PM, Alistair Popple wrote:
> +// SAFETY: No DMA allocations have been made yet
It's not really about DMA allocations that have been made previously, there is
no unsafe behavior in that.
It's about the method must not be called concurrently with any DMA allocation or
mappin
On Sun Sep 21, 2025 at 11:36 AM CEST, Greg KH wrote:
> Your example code using this is nice, and it shows how to set up, and
> query these bits, but that's not anything anyone actually does in the
> kernel, what they want to do is read/write from hardware with this.
>
> So, how does that work? Whe
On Sun Sep 21, 2025 at 2:45 PM CEST, Greg KH wrote:
> Again, regmap handles this all just fine, why not just make bindings to
> that api here instead?
The idea is to use this for the register!() macro, e.g.
register!(NV_PMC_BOOT_0 @ 0x, "Basic revision information about
the GPU"
On 9/9/25 1:24 PM, Alice Ryhl wrote:
> On Tue, Sep 9, 2025 at 1:11 PM Thomas Hellström
> wrote:
>>
>> On Tue, 2025-09-09 at 12:47 +0200, Danilo Krummrich wrote:
>>> On 9/9/25 12:39 PM, Thomas Hellström wrote:
>>>> On 9/8/25 14:20, Danilo Krummrich wrote:
&
On Wed Sep 10, 2025 at 6:48 AM CEST, Alexandre Courbot wrote:
> On Tue Sep 9, 2025 at 11:43 PM JST, Danilo Krummrich wrote:
>> impl Gpu {
>> pub(crate) fn new<'a>(
>> dev: &'a Device,
>> bar: &'a Bar0
On Fri Sep 19, 2025 at 10:56 PM CEST, Gary Guo wrote:
> Turbofish is cumbersome to write with just magic numbers, and the
> fact `{}` is needed to pass in constant expressions made this much
> worse. If the drivers try hard to avoid magic numbers, you would
> effective require all code to be `::<{
On 9/11/25 1:04 PM, Alexandre Courbot wrote:
> +/// Attempt to start the GSP.
> +///
> +/// This is a GPU-dependent and complex procedure that involves loading
> firmware files from
> +/// user-space, patching them with signatures, and building
> firmware-specific intricate data
>
On Thu Sep 18, 2025 at 8:13 PM CEST, Joel Fernandes wrote:
> On Thu, Sep 18, 2025 at 03:02:11PM +, Alice Ryhl wrote:
>> Using build_assert! to assert that offsets are in bounds is really
>> fragile and likely to result in spurious and hard-to-debug build
>> failures. Therefore, build_assert! sh
On 9/11/25 1:04 PM, Alexandre Courbot wrote:
> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> index
> 06a7ee8f4195759fb55ad483852724bb1ab46793..8505ee81c43e7628d1f099aff285244f8908c633
> 100644
> --- a/drivers/gpu/nova-core/gpu.rs
> +++ b/drivers/gpu/nova-core/gpu.rs
>
f-by: Dave Airlie
Acked-by: Danilo Krummrich
On 9/11/25 2:17 PM, Alexandre Courbot wrote:
> On Thu Sep 11, 2025 at 8:22 PM JST, Danilo Krummrich wrote:
>> On 9/11/25 1:04 PM, Alexandre Courbot wrote:
>>> +/// Attempt to start the GSP.
>>> +///
>>> +/// This is a GPU-dependent and complex
On 9/12/25 3:06 PM, Bagas Sanjaya wrote:
> Commit 6cc44e9618f03f ("drm: Add directive to format code in comment")
> fixes original Sphinx indentation warning as introduced in
> 471920ce25d50b ("drm/gpuvm: Add locking helpers"), by means of using
> code-block:: directive. It semantically conflicts w
On Thu Sep 4, 2025 at 4:16 AM CEST, Dave Airlie wrote:
> From: Dave Airlie
>
> While discussing cgroups we noticed a problem where you could export
> a BO to a dma-buf without having it ever being backed or accounted for.
>
> This meant in low memory situations or eventually with cgroups, a
> lowe
On 9/10/25 3:51 PM, Daniel Almeida wrote:
> diff --git a/drivers/gpu/drm/tyr/Kconfig b/drivers/gpu/drm/tyr/Kconfig
> new file mode 100644
> index
> ..de910b2cba3a48e0b238eb0f66279758c02dfb6f
> --- /dev/null
> +++ b/drivers/gpu/drm/tyr/Kconfig
> @@ -0,0 +1,17
On Wed Sep 10, 2025 at 9:02 PM CEST, Joel Fernandes wrote:
> On Wed, Sep 10, 2025 at 02:09:55PM -0400, Joel Fernandes wrote:
> [...]
>> > > +/// Allocate IRQ vectors for this PCI device.
>> > > +///
>> > > +/// Allocates between `min_vecs` and `max_vecs` interrupt vectors
>> > > for t
On Mon Sep 8, 2025 at 12:20 PM CEST, Boris Brezillon wrote:
> I'm not following. Yes there's going to be a
> drm_gpuva_unlink_defer_put() that skips the
>
> va->vm_bo = NULL;
> drm_gpuvm_bo_put(vm_bo);
>
> and adds the gpuva to a list for deferred destruction. But I'm not
> seeing w
viously initialized fields
Christian S. Lima (1):
rust: transmute: Add methods for FromBytes trait
Daniel Almeida (1):
rust: drm: Introduce the Tyr driver for Arm Mali GPUs
Danilo Krummrich (15):
rust: page: implement BorrowedPage
rust: alloc: vmalloc: implement Vmalloc:
viously initialized fields
Christian S. Lima (1):
rust: transmute: Add methods for FromBytes trait
Daniel Almeida (1):
rust: drm: Introduce the Tyr driver for Arm Mali GPUs
Danilo Krummrich (15):
rust: page: implement BorrowedPage
rust: alloc: vmalloc: implement Vmalloc:
API that is evolving when really necessary,
than squeezing new features into an existing API (e.g. by adding confusing
extentions) that just isn't a good fit anymore at some point.
> Signed-off-by: Alistair Popple
> Reviewed-by: John Hubbard
> [acour...@nvidia.com: adapt the bindin
On Sat Sep 13, 2025 at 7:13 PM CEST, Joel Fernandes wrote:
> On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote:
>> On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote:
>> > Any chance we can initialize the locks later? We don't need locking until
>>
On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote:
> Any chance we can initialize the locks later? We don't need locking until
> after the boot process is completed, and if there's a way we can dynamically
> "pin", where we hypothetically pin after the boot process completed, that
> might a
arnings not being fixed.
>
> Revert 6cc44e9618f03f to keep things rolling without these warnings.
>
> Fixes: 6cc44e9618f0 ("drm: Add directive to format code in comment")
> Fixes: 471920ce25d5 ("drm/gpuvm: Add locking helpers")
> Signed-off-by: Bagas Sanjaya
Need me to pick this one up? Otherwise,
Acked-by: Danilo Krummrich
On 9/11/25 2:29 PM, Alexandre Courbot wrote:
> On Thu Sep 11, 2025 at 8:27 PM JST, Danilo Krummrich wrote:
>> On 9/11/25 1:04 PM, Alexandre Courbot wrote:
>>> diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
>>> index
>>> 06a7
On Tue Sep 9, 2025 at 4:11 PM CEST, Alexandre Courbot wrote:
> On Wed Sep 3, 2025 at 5:27 PM JST, Danilo Krummrich wrote:
>> On Wed Sep 3, 2025 at 9:10 AM CEST, Alexandre Courbot wrote:
>>> On Wed Sep 3, 2025 at 8:12 AM JST, Danilo Krummrich wrote:
>>>> On 9/2/25 4:
On 9/11/25 1:04 PM, Alexandre Courbot wrote:
> +/// Requests the GPU firmware `name` suitable for `chipset`, with version
> `ver`.
> +fn request_nv_firmware(
I think just request_firmware() is fine.
On 9/11/25 1:04 PM, Alexandre Courbot wrote:
> This series makes more progress on the GSP boot process for Ampere GPUs.
With the changes mentioned on the individual patches, the series is:
Acked-by: Danilo Krummrich
On Wed Sep 10, 2025 at 1:18 PM CEST, Alexandre Courbot wrote:
> On Wed Sep 10, 2025 at 5:01 PM JST, Danilo Krummrich wrote:
>> On Wed Sep 10, 2025 at 6:48 AM CEST, Alexandre Courbot wrote:
>>> On Tue Sep 9, 2025 at 11:43 PM JST, Danilo Krummrich wrote:
>>>>impl G
On 9/10/25 4:43 PM, Daniel Almeida wrote:
> Fair enough, perhaps a quick v4 then?
In case this remains to be the only change you could also fix it up on apply.
On 9/2/25 9:02 PM, Danilo Krummrich wrote:
> Nouveau patches usually flow through the drm-misc tree, while nova (and
> nova-core) are maintained through a dedicated driver tree and soon
> through drm-rust.
>
> Hence, fix up the corresponding X: entries to list nova inste
On Wed Sep 10, 2025 at 5:54 AM CEST, Joel Fernandes wrote:
> impl Device {
The Bound context is not enough for some of the methods below, some of them
require the Core context, more below.
> +/// Free all allocated IRQ vectors for this device.
> +///
> +/// This should be called to r
On 9/9/25 1:43 PM, Maxime Ripard wrote:
> We should probably amend the nouveau entry to point to the drm-misc repo
> if it's the de-facto tree these days?
This already happened with a preceding patch before this one has been sent. :)
On 9/9/25 12:39 PM, Thomas Hellström wrote:
> On 9/8/25 14:20, Danilo Krummrich wrote:
>> On 9/8/25 2:11 PM, Boris Brezillon wrote:
>>> On Mon, 08 Sep 2025 13:11:32 +0200
>>> "Danilo Krummrich" wrote:
>>>> I'm saying exac
;
> Leaving us with a simpler trait hierarchy that now looks like this:
>
> * Drivers implement: BaseDriverObject
> * Crate implements:
> * IntoGEMObject for Object where T: DriverObject
> * BaseObject for T where T: IntoGEMObject
>
> Which makes the code a lot easier to understand and build on :).
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Almeida
Acked-by: Danilo Krummrich
On 9/8/25 8:46 PM, Lyude Paul wrote:
> Just to reduce the clutter with the File<…> types in gem.rs.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Daniel Almeida
Acked-by: Danilo Krummrich
On 9/8/25 2:11 PM, Boris Brezillon wrote:
> On Mon, 08 Sep 2025 13:11:32 +0200
> "Danilo Krummrich" wrote:
>> I'm saying exactly what you say: "has to be a special unlink function" ->
>> drm_gpuva_unlink_defer_put(). :)
>
> I
On Mon Sep 8, 2025 at 10:26 AM CEST, Alice Ryhl wrote:
> On Mon, Sep 08, 2025 at 09:11:40AM +0200, Boris Brezillon wrote:
>> Hi Alice,
>>
>> On Sun, 7 Sep 2025 11:39:41 +
>> Alice Ryhl wrote:
>>
>> > Yeah I guess we could have unlink remove the gpuva, but then allow the
>> > end-user to atta
On Sun Sep 7, 2025 at 1:39 PM CEST, Alice Ryhl wrote:
> On Sun, Sep 07, 2025 at 01:28:05PM +0200, Danilo Krummrich wrote:
>> On Sun Sep 7, 2025 at 1:15 PM CEST, Alice Ryhl wrote:
>> > On Sat, Sep 06, 2025 at 12:47:36AM +0200, Danilo Krummrich wrote:
>> >> On Fri Sep
On Sun Sep 7, 2025 at 1:15 PM CEST, Alice Ryhl wrote:
> On Sat, Sep 06, 2025 at 12:47:36AM +0200, Danilo Krummrich wrote:
>> On Fri Sep 5, 2025 at 8:18 PM CEST, Alice Ryhl wrote:
>> > On Fri, Sep 5, 2025 at 3:25 PM Boris Brezillon
>> > wrote:
>> >> On Fri,
On Fri Sep 5, 2025 at 8:18 PM CEST, Alice Ryhl wrote:
> On Fri, Sep 5, 2025 at 3:25 PM Boris Brezillon
> wrote:
>> On Fri, 05 Sep 2025 12:11:28 +
>> Alice Ryhl wrote:
>> > +static bool
>> > +drm_gpuvm_bo_is_dead(struct drm_gpuvm_bo *vm_bo)
>> > +{
>> > + return !kref_read(&vm_bo->kref);
>
As suggested by Maxime, add the drm-misc maintainers as reviewers to the
drm-rust entry.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Suggested-by: Maxime Ripard
Signed-off-by: Danilo Krummrich
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a
(Cc: Jani)
On 9/4/25 12:40 PM, Alice Ryhl wrote:
On Mon, Sep 01, 2025 at 10:26:39PM +0200, Danilo Krummrich wrote:
+DRM DRIVERS AND COMMON INFRASTRUCTURE [RUST]
+M: Danilo Krummrich
+M: Alice Ryhl
+S: Supported
+W: https://drm.pages.freedesktop.org/maintainer-tools/drm
On Thu Sep 4, 2025 at 1:09 PM CEST, Danilo Krummrich wrote:
> I think we should get the same redirect, so the links in MAINTAINERS are
> consistent with each other.
https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/89
On Thu Sep 4, 2025 at 5:16 AM CEST, Alexandre Courbot wrote:
> On Thu Sep 4, 2025 at 12:15 AM JST, Joel Fernandes wrote:
>
+use kernel::prelude::*;
+
+/// Macro for defining bitfield-packed structures in Rust.
+/// The size of the underlying storage type is specified with
r teardown can race with each
> other.
>
> Revert all patches related to the waitqueue removal.
>
> Fixes: bead88002227 ("drm/nouveau: Remove waitque for sched teardown")
> Suggested-by: Danilo Krummrich
> Signed-off-by: Philipp Stanner
Applied to drm-misc-fixes, thanks!
On Wed Sep 3, 2025 at 2:29 PM CEST, Alexandre Courbot wrote:
> To be honest I am not completely sure about the best layout yet and will
> need more visibility to understand whether this is optimal. But
> considering that we want to run the GSP boot process over a built `Gpu`
> instance, we cannot s
On Wed Sep 3, 2025 at 12:44 PM CEST, Alexandre Courbot wrote:
> On Wed Sep 3, 2025 at 5:26 PM JST, Danilo Krummrich wrote:
>> On Wed Sep 3, 2025 at 9:08 AM CEST, Alexandre Courbot wrote:
>>> On Wed Sep 3, 2025 at 4:53 AM JST, Danilo Krummrich wrote:
>>>> On T
/dri-devel/enuksb2qk5wyrilz3l2vnog45lghgmplrav5to6pd5k5owi36h@pxdq6y5dpgpt/
Signed-off-by: Danilo Krummrich
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6dcfbd11efef..84e07eb11da3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
On Wed Sep 3, 2025 at 9:10 AM CEST, Alexandre Courbot wrote:
> On Wed Sep 3, 2025 at 8:12 AM JST, Danilo Krummrich wrote:
>> On 9/2/25 4:31 PM, Alexandre Courbot wrote:
>>> pub(crate) fn new(
>>> pdev: &pci::Device,
>>> devres_bar
On Wed Sep 3, 2025 at 9:08 AM CEST, Alexandre Courbot wrote:
> On Wed Sep 3, 2025 at 4:53 AM JST, Danilo Krummrich wrote:
>> On Tue Sep 2, 2025 at 4:31 PM CEST, Alexandre Courbot wrote:
>>> diff --git a/drivers/gpu/nova-core/driver.rs
>>> b/drivers/gpu/no
On Tue Sep 2, 2025 at 4:31 PM CEST, Alexandre Courbot wrote:
> diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
> index
> 274989ea1fb4a5e3e6678a08920ddc76d2809ab2..1062014c0a488e959379f009c2e8029ffaa1e2f8
> 100644
> --- a/drivers/gpu/nova-core/driver.rs
> +++ b/drive
On 9/2/25 4:31 PM, Alexandre Courbot wrote:
pub(crate) fn new(
pdev: &pci::Device,
devres_bar: Arc>,
The diff is hiding it, but with this patch we should also make sure that this
returns impl PinInit rather than Result.
I think this should be possible now.
@@ -293
On Mon Sep 1, 2025 at 3:13 PM CEST, Alexandre Courbot wrote:
> On Mon Sep 1, 2025 at 7:41 PM JST, Danilo Krummrich wrote:
>> On Sun Aug 31, 2025 at 3:50 PM CEST, Alexandre Courbot wrote:
>>>> +pub(crate) fn unbind(&self, pdev: &pci::Device) {
>>>> +
: David Airlie
Cc: Simona Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Alexandre Courbot
Cc: Daniel Almeida
Signed-off-by: Danilo Krummrich
---
MAINTAINERS | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
On Tue Sep 2, 2025 at 7:57 PM CEST, Maxime Ripard wrote:
> On Tue, Sep 02, 2025 at 07:49:56PM +0200, Danilo Krummrich wrote:
>> On Tue Sep 2, 2025 at 7:40 PM CEST, Maxime Ripard wrote:
>> > Would it make sense to add the drm-misc maintainers as reviewers for the
>> > bin
On Tue Sep 2, 2025 at 7:40 PM CEST, Maxime Ripard wrote:
> On Mon, Sep 01, 2025 at 10:26:39PM +0200, Danilo Krummrich wrote:
>> Multiple DRM Rust drivers (e.g. nova-core, nova-drm, Tyr, rvkms) are in
>> development, with at least Nova and (soon) Tyr already upstream. Having a
>
On Tue Aug 26, 2025 at 9:57 PM CEST, James Jones wrote:
> The gitlab repository previously associated with
> the nouveau module has fallen out of use. The
> drm-misc tree here:
>
> https://gitlab.freedesktop.org/drm/misc/kernel.git
>
> Is now where most nouveau-related patches are
> applied. This c
On 8/12/25 12:00 AM, James Jones wrote:
The layout of bits within the individual tiles
(referred to as sectors in the
DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D() macro)
changed for 8 and 16-bit surfaces starting in
Blackwell 2 GPUs (With the exception of GB10).
To denote the difference, extend the se
Now that we have pci::Device::unbind() we can unregister the sysmem
flush page with a direct access the I/O resource, i.e. without RCU read
side critical section.
Signed-off-by: Danilo Krummrich
---
Changes in v2:
- Use Device.
- Add doc-comment.
---
drivers/gpu/nova-core/driver.rs | 4
On Sun Aug 31, 2025 at 3:50 PM CEST, Alexandre Courbot wrote:
>> +pub(crate) fn unbind(&self, pdev: &pci::Device) {
>> +// Unregister the sysmem flush page before we release it.
>> +kernel::warn_on!(self.bar.access(pdev.as_ref()).map_or(true, |bar| {
>> +self.sysmem_
into structures that require logging
instead of having all their methods take an extra `dev` argument.
Removing this argument streamlines the code a bit.
Signed-off-by: Alexandre Courbot
Acked-by: Danilo Krummrich
On Fri Aug 29, 2025 at 12:39 AM CEST, Danilo Krummrich wrote:
> If built on architectures with CONFIG_ARCH_DMA_ADDR_T_64BIT=y nova-core
> produces that following build failures:
>
> error[E0308]: mismatched types
> --> drivers/gpu/nova-core/fb.rs:49:59
>|
&
On 8/29/25 1:16 PM, Alexandre Courbot wrote:
On Thu Aug 28, 2025 at 8:27 PM JST, Danilo Krummrich wrote:
On 8/26/25 6:07 AM, Alexandre Courbot wrote:
/// Structure encapsulating the firmware blobs required for the GPU to
operate.
#[expect(dead_code)]
pub(crate) struct Firmware
On 8/30/25 3:32 PM, Danilo Krummrich wrote:
+pub(crate) fn unbind(&self, pdev: &pci::Device) {
+// Unregister the sysmem flush page before we release it.
+kernel::warn_on!(self.bar.access(pdev.as_ref()).map_or(true, |bar| {
+self.sysmem_flush.unregi
Now that we have pci::Device::unbind() we can unregister the sysmem
flush page with a direct access the I/O resource, i.e. without RCU read
side critical section.
Signed-off-by: Danilo Krummrich
---
drivers/gpu/nova-core/driver.rs | 4
drivers/gpu/nova-core/gpu.rs| 20
On 8/29/25 8:30 PM, Philipp Stanner wrote:
This reverts:
Thanks for sending the revert!
commit bead88002227 ("drm/nouveau: Remove waitque for sched teardown")
commit 5f46f5c7af8c ("drm/nouveau: Add new callback for scheduler teardown")
commit 89b2675198ab ("drm/nouveau: Make fence container h
On 8/29/25 4:16 AM, Dave Airlie wrote:
From: Faith Ekstrand
This ensures that the memory write and the interrupt are properly
ordered and we won't wake up the kernel before the semaphore write has
hit memory.
Fixes: b1ca384772b6 ("drm/nouveau/gv100-: switch to volta semaphore methods")
Cc: sta
On 8/29/25 4:16 AM, Dave Airlie wrote:
From: Dave Airlie
Nouveau has code that when it gets an IRQ with no allowed handler
it disables it to avoid storms.
However with nonstall interrupts, we often disable them from
the drm driver, but still request their emission via the push submission.
Jus
On Fri Aug 29, 2025 at 9:55 AM CEST, Danilo Krummrich wrote:
> Since commit e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva")
> it is possible for test_prepare_array() to exceed a stack frame size of
> 2048 bytes depending on the exact configuration of the kernel.
&g
On Fri Aug 29, 2025 at 9:55 AM CEST, Danilo Krummrich wrote:
> diff --git a/drivers/gpu/drm/tests/drm_exec_test.c
> b/drivers/gpu/drm/tests/drm_exec_test.c
> index d6c4dd1194a0..d59ec3baae1d 100644
> --- a/drivers/gpu/drm/tests/drm_exec_test.c
> +++ b/drivers/gpu/drm/tests/
On Fri Aug 29, 2025 at 4:23 AM CEST, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/tests/drm_exec_test.c: In function 'test_prepare_array':
> drivers/gpu/drm/tests/drm_exec_test.c:171:1:
1
make[6]: *** Waiting for unfinished jobs
In order to fix this, allocate the GEM objects in test_prepare_array()
with kzalloc(), rather than placing them on the stack.
Cc: Alice Ryhl
Cc: Christian König
Fixes: e7fa80e2932c ("drm_gem: add mutex to drm_gem_object.gpuva")
Signed-off-
On 8/29/25 5:03 AM, Alexandre Courbot wrote:
On Thu Aug 28, 2025 at 5:37 PM JST, Miguel Ojeda wrote:
On Wed, 27 Aug 2025 18:19:57 +1000 Alistair Popple wrote:
This series builds on top of Alex's series[1] to continue initialising the GSP
into a state where it becomes active and it starts comm
re: register sysmem flush page")
Fixes: 69f5cd67ce41 ("gpu: nova-core: add falcon register definitions and base
code")
Signed-off-by: Danilo Krummrich
---
drivers/gpu/nova-core/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/nova-core/Kconfig b/drivers/gpu/no
On 8/28/25 11:45 PM, John Hubbard wrote:
So Nova should definitely depend upon 64-bit configs.
Yeah, I fully agree.
But I think it would have been good to have a consumer for the generic APIs that
has to deal with it, which I think was also Miguel's point.
I will send a patch for Nova to depe
On Thu Aug 28, 2025 at 9:58 PM CEST, Danilo Krummrich wrote:
> On Thu Aug 28, 2025 at 9:36 PM CEST, Miguel Ojeda wrote:
>> On Thu, Aug 28, 2025 at 9:31 PM Miguel Ojeda
>> wrote:
>>>
>>> and a `DmaAddress`
>>> newtype, not just a typedef, could perha
On Thu Aug 28, 2025 at 9:36 PM CEST, Miguel Ojeda wrote:
> On Thu, Aug 28, 2025 at 9:31 PM Miguel Ojeda
> wrote:
>>
>> and a `DmaAddress`
>> newtype, not just a typedef, could perhaps be nice anyway?
>
> The one from your linked patch is not a newtype though, so I guess
> there is a reason for tha
On Thu Aug 28, 2025 at 9:31 PM CEST, Miguel Ojeda wrote:
> On Thu, Aug 28, 2025 at 9:24 PM Danilo Krummrich wrote:
>>
>> Maybe I spoke too soon, it's actually pretty painful to keep 32-bit
>> compatibility, even though it would be nice for testing purposes.
>>
On Thu Aug 28, 2025 at 7:54 PM CEST, Danilo Krummrich wrote:
> On 8/28/25 6:02 PM, Miguel Ojeda wrote:
>> Similar to another one I sent, I hope it helps -- it may be useful to make it
>> build in 32-bit as a test for those kinds of platforms.
>
> Agreed.
Maybe I spoke to
Hi Miguel,
Thanks for reporting!
On 8/28/25 6:02 PM, Miguel Ojeda wrote:
Hi Danilo et al.,
In Linus' tree and -next, for an arm32 LLVM defconfig plus Rust build, I see:
error[E0308]: mismatched types
--> drivers/gpu/nova-core/fb.rs:49:59
|
49 | hal::fb_hal(chi
On 8/26/25 6:07 AM, Alexandre Courbot wrote:
/// Structure encapsulating the firmware blobs required for the GPU to
operate.
#[expect(dead_code)]
pub(crate) struct Firmware {
@@ -36,7 +123,10 @@ pub(crate) struct Firmware {
booter_unloader: BooterFirmware,
/// GSP bootloader, v
On 8/27/25 3:38 PM, Alice Ryhl wrote:
Alice Ryhl (3):
Applied to drm-misc-next, thanks!
drm_gem: add mutex to drm_gem_object.gpuva
panthor: use drm_gem_object.gpuva.lock instead of gpuva_list_lock
gpuvm: remove gem.gpuva.lock_dep_map
[ Use lockdep_is_held() instead
On Wed Aug 27, 2025 at 3:38 PM CEST, Alice Ryhl wrote:
> #ifdef CONFIG_LOCKDEP
> -/**
> - * drm_gem_gpuva_set_lock() - Set the lock protecting accesses to the gpuva
> list.
> - * @obj: the &drm_gem_object
> - * @lock: the lock used to protect the gpuva list. The locking primitive
> - * must conta
On 8/25/25 11:22 AM, Alice Ryhl wrote:
After working with this code for a while, I came across several typos.
This patch fixes them.
Signed-off-by: Alice Ryhl
Applied to drm-misc-fixes, thanks!
On 8/24/25 3:59 PM, Joel Fernandes wrote:
Add a minimal bitfield library for defining in Rust structures (called
bitstruct), similar in concept to bit fields in C structs. This will be used
for defining page table entries and other structures in nova-core.
Signed-off-by: Joel Fernandes
---
dr
On Tue Aug 12, 2025 at 12:00 AM CEST, James Jones wrote:
> On some chipsets, which block-linear modifiers are
> supported is format-specific. However, linear
> modifiers are always be supported. The prior
> modifier filtering logic was not accounting for
> the linear case.
>
> Fixes: c586f30bf74c (
On Fri Aug 22, 2025 at 11:11 PM CEST, James Jones wrote:
> On 8/22/25 13:55, Danilo Krummrich wrote:
>> On Tue Aug 12, 2025 at 12:00 AM CEST, James Jones wrote:
>>> On some chipsets, which block-linear modifiers are
>>> supported is format-specific. However, linear
1 - 100 of 1396 matches
Mail list logo
