From: Faith Ekstrand <faith.ekstrand@collabora.com> To: "Asahi Lina" <lina@asahilina.net>, "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>, "Maxime Ripard" <mripard@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "David Airlie" <airlied@gmail.com>, "Daniel Vetter" <daniel@ffwll.ch>, "Miguel Ojeda" <ojeda@kernel.org>, "Alex Gaynor" <alex.gaynor@gmail.com>, "Wedson Almeida Filho" <wedsonaf@gmail.com>, "Boqun Feng" <boqun.feng@gmail.com>, "Gary Guo" <gary@garyguo.net>, "Björn Roy Baron" <bjorn3_gh@protonmail.com>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Christian König" <christian.koenig@amd.com>, "Luben Tuikov" <luben.tuikov@amd.com>, "Jarkko Sakkinen" <jarkko@kernel.org>, "Dave Hansen" <dave.hansen@linux.intel.com> Cc: Alyssa Rosenzweig <alyssa@rosenzweig.io>, Karol Herbst <kherbst@redhat.com>, Ella Stanforth <ella@iglunix.org>, Mary <mary@mary.zone>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-sgx@vger.kernel.org, asahi@lists.linux.dev Subject: Re: [PATCH RFC 03/18] rust: drm: file: Add File abstraction Date: Mon, 13 Mar 2023 12:49:57 -0500 [thread overview] Message-ID: <5a0db63c043adc47b289b3f1d22935a0a63c926e.camel@collabora.com> (raw) In-Reply-To: <28fa3f97-4c7c-212e-2be2-fb1c05f7f576@asahilina.net> On Fri, 2023-03-10 at 07:16 +0900, Asahi Lina wrote: > On 10/03/2023 06.16, Faith Ekstrand wrote: > > On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote: > > > A DRM File is the DRM counterpart to a kernel file structure, > > > representing an open DRM file descriptor. Add a Rust abstraction > > > to > > > allow drivers to implement their own File types that implement > > > the > > > DriverFile trait. > > > > > > Signed-off-by: Asahi Lina <lina@asahilina.net> > > > --- > > > rust/bindings/bindings_helper.h | 1 + > > > rust/kernel/drm/drv.rs | 7 ++- > > > rust/kernel/drm/file.rs | 113 > > > ++++++++++++++++++++++++++++++++++++++++ > > > rust/kernel/drm/mod.rs | 1 + > > > 4 files changed, 120 insertions(+), 2 deletions(-) > > > > > > diff --git a/rust/bindings/bindings_helper.h > > > b/rust/bindings/bindings_helper.h > > > index 2a999138c4ae..7d7828faf89c 100644 > > > --- a/rust/bindings/bindings_helper.h > > > +++ b/rust/bindings/bindings_helper.h > > > @@ -8,6 +8,7 @@ > > > > > > #include <drm/drm_device.h> > > > #include <drm/drm_drv.h> > > > +#include <drm/drm_file.h> > > > #include <drm/drm_ioctl.h> > > > #include <linux/delay.h> > > > #include <linux/device.h> > > > diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs > > > index 29a465515dc9..1dcb651e1417 100644 > > > --- a/rust/kernel/drm/drv.rs > > > +++ b/rust/kernel/drm/drv.rs > > > @@ -144,6 +144,9 @@ pub trait Driver { > > > /// Should be either `drm::gem::Object<T>` or > > > `drm::gem::shmem::Object<T>`. > > > type Object: AllocImpl; > > > > > > + /// The type used to represent a DRM File (client) > > > + type File: drm::file::DriverFile; > > > + > > > /// Driver metadata > > > const INFO: DriverInfo; > > > > > > @@ -213,8 +216,8 @@ macro_rules! drm_device_register { > > > impl<T: Driver> Registration<T> { > > > const VTABLE: bindings::drm_driver = drm_legacy_fields! { > > > load: None, > > > - open: None, // TODO: File abstraction > > > - postclose: None, // TODO: File abstraction > > > + open: Some(drm::file::open_callback::<T::File>), > > > + postclose: > > > Some(drm::file::postclose_callback::<T::File>), > > > lastclose: None, > > > unload: None, > > > release: None, > > > diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs > > > new file mode 100644 > > > index 000000000000..48751e93c38a > > > --- /dev/null > > > +++ b/rust/kernel/drm/file.rs > > > @@ -0,0 +1,113 @@ > > > +// SPDX-License-Identifier: GPL-2.0 OR MIT > > > + > > > +//! DRM File objects. > > > +//! > > > +//! C header: > > > [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/dr > > > m_fi > > > le.h) > > > + > > > +use crate::{bindings, drm, error::Result}; > > > +use alloc::boxed::Box; > > > +use core::marker::PhantomData; > > > +use core::ops::Deref; > > > + > > > +/// Trait that must be implemented by DRM drivers to represent a > > > DRM > > > File (a client instance). > > > +pub trait DriverFile { > > > + /// The parent `Driver` implementation for this > > > `DriverFile`. > > > + type Driver: drm::drv::Driver; > > > + > > > + /// Open a new file (called when a client opens the DRM > > > device). > > > + fn open(device: &drm::device::Device<Self::Driver>) -> > > > Result<Box<Self>>; > > > +} > > > + > > > +/// An open DRM File. > > > +/// > > > +/// # Invariants > > > +/// `raw` is a valid pointer to a `drm_file` struct. > > > +#[repr(transparent)] > > > +pub struct File<T: DriverFile> { > > > + raw: *mut bindings::drm_file, > > > + _p: PhantomData<T>, > > > +} > > > + > > > +pub(super) unsafe extern "C" fn open_callback<T: DriverFile>( > > > + raw_dev: *mut bindings::drm_device, > > > + raw_file: *mut bindings::drm_file, > > > +) -> core::ffi::c_int { > > > + let drm = core::mem::ManuallyDrop::new(unsafe { > > > drm::device::Device::from_raw(raw_dev) }); > > > > Maybe you can help educate me a bit here... This feels like a > > really > > sketchy pattern. We're creating a Device from a pointer, an > > operation > > which inherently consumes a reference but then marking it > > ManuallyDrop > > so drm_device_put() never gets called. It took me a while but I > > think > > I figured out what you're trying to do: Make it so all the Rust > > stuff > > works with Device, not drm_device but it still feels really wrong. > > It > > works, it just feels like there's a lot of unsafe abstraction > > juggling > > happening here and I expect this operation is going to be pretty > > common > > in the Rust abstraction layer. > > So I think this is going to be a pretty common pattern in this kind > of > abstraction. The problem is that, of course, in C there is no > distinction between an owned reference and a borrowed one. Here we > have > a borrowed reference to a struct drm_device, and we need to turn it > into > a &Device (which is the Rust equivalent type). But for &Device to > exist > we need a Device to exist in the first place, and Device normally > implies ownership of the underlying drm_device. Thanks! Putting it in terms of borrow really helps clear up the difference. > We could just acquire a reference here, but then we're needlessly > grabbing a ref only to drop it at the end of the function, which is > pointless when the caller is holding another reference for us while > the > callback runs. And of course Rust likes to claim to offer zero-cost > abstractions, so it would be kind of sad to have to do that... ^^ Yeah, I agree we don't want to take extra references. > Just doing drm::device::Device::from_raw(raw_dev) is a ticking time > bomb, because we haven't acquired a reference (which would normally > be > required). If that Device ever gets dropped, we've messed up the > refcounting and stolen the caller's reference. We could try to ensure > it > gets passed to core::mem::forget in all paths out, but that gets > error-prone very quickly when trying to cover error paths. So > instead, > we put it into a ManuallyDrop. That takes care of neutering the ref > drop, so we don't have to worry about messing that up. Then the only > remaining safety requirement is that that the ManuallyDrop<Device> > never > escape the callback function, and that's easy to ensure: we only pass > a > &ref to the user (which via auto-deref ends up being a &Device), and > then nothing bad can happen. If the user wants an owned reference to > the > device to keep around, they can call .clone() on it and that's when > the > incref happens. > > Basically, ManuallyDrop<T> where T is a reference counted type > represents a borrowed reference to a T coming from the C side. You > can > see another use of this pattern in gem::Object, which contains a > ManuallyDrop<Device> that represents a borrowed reference to the > device > that owns that object. The DRM core (as far as I know!) guarantees > that > DRM devices outlive all of their GEM objects, so we can materialize a > borrowed reference and as long as it never leaves the GEM object, it > will be sound. Then we can take &Device references from it whenever > we > want, and the usual Rust borrow checker rules ensure we can't do > something illegal. Ok, that all matches my understanding of what I thought was going on. I do wonder if it would be good to wrap this up in a struct DeviceBorrow { dev: ManuallyDrop<Device> } impl DeviceBorrow { pub unsafe fn from_raw(*mut bindings::drm_device) -> DeviceBorrow; } impl Deref<Device> for DeviceBorrow { ... } with documentation, etc. Seeing a ManuallyDrop which is never dropped sets my rust senses tingling. Maybe that's too much typing for each object? I don't want to add a bunch of extra work but this seems like a pretty common pattern we're going to hit everywhere. ~Faith
WARNING: multiple messages have this Message-ID (diff)
From: Faith Ekstrand <faith.ekstrand@collabora.com> To: "Asahi Lina" <lina@asahilina.net>, "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>, "Maxime Ripard" <mripard@kernel.org>, "Thomas Zimmermann" <tzimmermann@suse.de>, "David Airlie" <airlied@gmail.com>, "Daniel Vetter" <daniel@ffwll.ch>, "Miguel Ojeda" <ojeda@kernel.org>, "Alex Gaynor" <alex.gaynor@gmail.com>, "Wedson Almeida Filho" <wedsonaf@gmail.com>, "Boqun Feng" <boqun.feng@gmail.com>, "Gary Guo" <gary@garyguo.net>, "Björn Roy Baron" <bjorn3_gh@protonmail.com>, "Sumit Semwal" <sumit.semwal@linaro.org>, "Christian König" <christian.koenig@amd.com>, "Luben Tuikov" <luben.tuikov@amd.com>, "Jarkko Sakkinen" <jarkko@kernel.org>, "Dave Hansen" <dave.hansen@linux.intel.com> Cc: linaro-mm-sig@lists.linaro.org, rust-for-linux@vger.kernel.org, Karol Herbst <kherbst@redhat.com>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Mary <mary@mary.zone>, asahi@lists.linux.dev, linux-sgx@vger.kernel.org, Ella Stanforth <ella@iglunix.org>, Alyssa Rosenzweig <alyssa@rosenzweig.io>, linux-media@vger.kernel.org Subject: Re: [PATCH RFC 03/18] rust: drm: file: Add File abstraction Date: Mon, 13 Mar 2023 12:49:57 -0500 [thread overview] Message-ID: <5a0db63c043adc47b289b3f1d22935a0a63c926e.camel@collabora.com> (raw) In-Reply-To: <28fa3f97-4c7c-212e-2be2-fb1c05f7f576@asahilina.net> On Fri, 2023-03-10 at 07:16 +0900, Asahi Lina wrote: > On 10/03/2023 06.16, Faith Ekstrand wrote: > > On Tue, 2023-03-07 at 23:25 +0900, Asahi Lina wrote: > > > A DRM File is the DRM counterpart to a kernel file structure, > > > representing an open DRM file descriptor. Add a Rust abstraction > > > to > > > allow drivers to implement their own File types that implement > > > the > > > DriverFile trait. > > > > > > Signed-off-by: Asahi Lina <lina@asahilina.net> > > > --- > > > rust/bindings/bindings_helper.h | 1 + > > > rust/kernel/drm/drv.rs | 7 ++- > > > rust/kernel/drm/file.rs | 113 > > > ++++++++++++++++++++++++++++++++++++++++ > > > rust/kernel/drm/mod.rs | 1 + > > > 4 files changed, 120 insertions(+), 2 deletions(-) > > > > > > diff --git a/rust/bindings/bindings_helper.h > > > b/rust/bindings/bindings_helper.h > > > index 2a999138c4ae..7d7828faf89c 100644 > > > --- a/rust/bindings/bindings_helper.h > > > +++ b/rust/bindings/bindings_helper.h > > > @@ -8,6 +8,7 @@ > > > > > > #include <drm/drm_device.h> > > > #include <drm/drm_drv.h> > > > +#include <drm/drm_file.h> > > > #include <drm/drm_ioctl.h> > > > #include <linux/delay.h> > > > #include <linux/device.h> > > > diff --git a/rust/kernel/drm/drv.rs b/rust/kernel/drm/drv.rs > > > index 29a465515dc9..1dcb651e1417 100644 > > > --- a/rust/kernel/drm/drv.rs > > > +++ b/rust/kernel/drm/drv.rs > > > @@ -144,6 +144,9 @@ pub trait Driver { > > > /// Should be either `drm::gem::Object<T>` or > > > `drm::gem::shmem::Object<T>`. > > > type Object: AllocImpl; > > > > > > + /// The type used to represent a DRM File (client) > > > + type File: drm::file::DriverFile; > > > + > > > /// Driver metadata > > > const INFO: DriverInfo; > > > > > > @@ -213,8 +216,8 @@ macro_rules! drm_device_register { > > > impl<T: Driver> Registration<T> { > > > const VTABLE: bindings::drm_driver = drm_legacy_fields! { > > > load: None, > > > - open: None, // TODO: File abstraction > > > - postclose: None, // TODO: File abstraction > > > + open: Some(drm::file::open_callback::<T::File>), > > > + postclose: > > > Some(drm::file::postclose_callback::<T::File>), > > > lastclose: None, > > > unload: None, > > > release: None, > > > diff --git a/rust/kernel/drm/file.rs b/rust/kernel/drm/file.rs > > > new file mode 100644 > > > index 000000000000..48751e93c38a > > > --- /dev/null > > > +++ b/rust/kernel/drm/file.rs > > > @@ -0,0 +1,113 @@ > > > +// SPDX-License-Identifier: GPL-2.0 OR MIT > > > + > > > +//! DRM File objects. > > > +//! > > > +//! C header: > > > [`include/linux/drm/drm_file.h`](../../../../include/linux/drm/dr > > > m_fi > > > le.h) > > > + > > > +use crate::{bindings, drm, error::Result}; > > > +use alloc::boxed::Box; > > > +use core::marker::PhantomData; > > > +use core::ops::Deref; > > > + > > > +/// Trait that must be implemented by DRM drivers to represent a > > > DRM > > > File (a client instance). > > > +pub trait DriverFile { > > > + /// The parent `Driver` implementation for this > > > `DriverFile`. > > > + type Driver: drm::drv::Driver; > > > + > > > + /// Open a new file (called when a client opens the DRM > > > device). > > > + fn open(device: &drm::device::Device<Self::Driver>) -> > > > Result<Box<Self>>; > > > +} > > > + > > > +/// An open DRM File. > > > +/// > > > +/// # Invariants > > > +/// `raw` is a valid pointer to a `drm_file` struct. > > > +#[repr(transparent)] > > > +pub struct File<T: DriverFile> { > > > + raw: *mut bindings::drm_file, > > > + _p: PhantomData<T>, > > > +} > > > + > > > +pub(super) unsafe extern "C" fn open_callback<T: DriverFile>( > > > + raw_dev: *mut bindings::drm_device, > > > + raw_file: *mut bindings::drm_file, > > > +) -> core::ffi::c_int { > > > + let drm = core::mem::ManuallyDrop::new(unsafe { > > > drm::device::Device::from_raw(raw_dev) }); > > > > Maybe you can help educate me a bit here... This feels like a > > really > > sketchy pattern. We're creating a Device from a pointer, an > > operation > > which inherently consumes a reference but then marking it > > ManuallyDrop > > so drm_device_put() never gets called. It took me a while but I > > think > > I figured out what you're trying to do: Make it so all the Rust > > stuff > > works with Device, not drm_device but it still feels really wrong. > > It > > works, it just feels like there's a lot of unsafe abstraction > > juggling > > happening here and I expect this operation is going to be pretty > > common > > in the Rust abstraction layer. > > So I think this is going to be a pretty common pattern in this kind > of > abstraction. The problem is that, of course, in C there is no > distinction between an owned reference and a borrowed one. Here we > have > a borrowed reference to a struct drm_device, and we need to turn it > into > a &Device (which is the Rust equivalent type). But for &Device to > exist > we need a Device to exist in the first place, and Device normally > implies ownership of the underlying drm_device. Thanks! Putting it in terms of borrow really helps clear up the difference. > We could just acquire a reference here, but then we're needlessly > grabbing a ref only to drop it at the end of the function, which is > pointless when the caller is holding another reference for us while > the > callback runs. And of course Rust likes to claim to offer zero-cost > abstractions, so it would be kind of sad to have to do that... ^^ Yeah, I agree we don't want to take extra references. > Just doing drm::device::Device::from_raw(raw_dev) is a ticking time > bomb, because we haven't acquired a reference (which would normally > be > required). If that Device ever gets dropped, we've messed up the > refcounting and stolen the caller's reference. We could try to ensure > it > gets passed to core::mem::forget in all paths out, but that gets > error-prone very quickly when trying to cover error paths. So > instead, > we put it into a ManuallyDrop. That takes care of neutering the ref > drop, so we don't have to worry about messing that up. Then the only > remaining safety requirement is that that the ManuallyDrop<Device> > never > escape the callback function, and that's easy to ensure: we only pass > a > &ref to the user (which via auto-deref ends up being a &Device), and > then nothing bad can happen. If the user wants an owned reference to > the > device to keep around, they can call .clone() on it and that's when > the > incref happens. > > Basically, ManuallyDrop<T> where T is a reference counted type > represents a borrowed reference to a T coming from the C side. You > can > see another use of this pattern in gem::Object, which contains a > ManuallyDrop<Device> that represents a borrowed reference to the > device > that owns that object. The DRM core (as far as I know!) guarantees > that > DRM devices outlive all of their GEM objects, so we can materialize a > borrowed reference and as long as it never leaves the GEM object, it > will be sound. Then we can take &Device references from it whenever > we > want, and the usual Rust borrow checker rules ensure we can't do > something illegal. Ok, that all matches my understanding of what I thought was going on. I do wonder if it would be good to wrap this up in a struct DeviceBorrow { dev: ManuallyDrop<Device> } impl DeviceBorrow { pub unsafe fn from_raw(*mut bindings::drm_device) -> DeviceBorrow; } impl Deref<Device> for DeviceBorrow { ... } with documentation, etc. Seeing a ManuallyDrop which is never dropped sets my rust senses tingling. Maybe that's too much typing for each object? I don't want to add a bunch of extra work but this seems like a pretty common pattern we're going to hit everywhere. ~Faith
next prev parent reply other threads:[~2023-03-13 17:50 UTC|newest] Thread overview: 242+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-07 14:25 [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 14:48 ` Karol Herbst 2023-03-07 14:48 ` Karol Herbst 2023-03-07 14:51 ` Karol Herbst 2023-03-07 14:51 ` Karol Herbst 2023-03-07 15:32 ` Maíra Canal 2023-03-07 15:32 ` Maíra Canal 2023-03-09 5:32 ` Asahi Lina 2023-03-09 5:32 ` Asahi Lina 2023-03-09 6:15 ` Dave Airlie 2023-03-09 6:15 ` Dave Airlie 2023-03-09 12:09 ` Maíra Canal 2023-03-07 17:34 ` Björn Roy Baron 2023-03-07 17:34 ` Björn Roy Baron 2023-03-09 6:04 ` Asahi Lina 2023-03-09 6:04 ` Asahi Lina 2023-03-09 20:24 ` Faith Ekstrand 2023-03-09 20:24 ` Faith Ekstrand 2023-03-09 20:39 ` Karol Herbst 2023-03-09 20:39 ` Karol Herbst 2023-03-10 6:21 ` Asahi Lina 2023-03-10 6:21 ` Asahi Lina 2023-04-13 9:23 ` Daniel Vetter 2023-04-13 9:23 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 02/18] rust: drm: Add Device and Driver abstractions Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 18:19 ` Björn Roy Baron 2023-03-07 18:19 ` Björn Roy Baron 2023-03-09 6:10 ` Asahi Lina 2023-03-09 6:10 ` Asahi Lina 2023-03-10 18:56 ` Boqun Feng 2023-03-10 18:56 ` Boqun Feng 2023-03-11 5:41 ` Boqun Feng 2023-03-11 5:41 ` Boqun Feng 2023-04-05 17:10 ` Daniel Vetter 2023-04-05 17:10 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 03/18] rust: drm: file: Add File abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-09 21:16 ` Faith Ekstrand 2023-03-09 21:16 ` Faith Ekstrand 2023-03-09 22:16 ` Asahi Lina 2023-03-09 22:16 ` Asahi Lina 2023-03-13 17:49 ` Faith Ekstrand [this message] 2023-03-13 17:49 ` Faith Ekstrand 2023-03-14 2:07 ` Boqun Feng 2023-03-14 2:07 ` Boqun Feng 2023-04-05 11:25 ` Daniel Vetter 2023-04-05 11:25 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 04/18] rust: drm: gem: Add GEM object abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-04-05 11:08 ` Daniel Vetter 2023-04-05 11:08 ` Daniel Vetter 2023-04-05 11:19 ` Miguel Ojeda 2023-04-05 11:19 ` Miguel Ojeda 2023-04-05 11:22 ` Daniel Vetter 2023-04-05 11:22 ` Daniel Vetter 2023-04-05 12:32 ` Miguel Ojeda 2023-04-05 12:32 ` Miguel Ojeda 2023-04-05 12:36 ` Daniel Vetter 2023-04-05 12:36 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 05/18] drm/gem-shmem: Export VM ops functions Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 06/18] rust: drm: gem: shmem: Add DRM shmem helper abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-08 13:38 ` Maíra Canal 2023-03-08 13:38 ` Maíra Canal 2023-03-09 5:25 ` Asahi Lina 2023-03-09 5:25 ` Asahi Lina 2023-03-09 11:47 ` Maíra Canal 2023-03-09 11:47 ` Maíra Canal 2023-03-09 14:16 ` Asahi Lina 2023-03-09 14:16 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 07/18] rust: drm: mm: Add DRM MM Range Allocator abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-04-06 14:15 ` Daniel Vetter 2023-04-06 14:15 ` Daniel Vetter 2023-04-06 15:28 ` Miguel Ojeda 2023-04-06 15:28 ` Miguel Ojeda 2023-04-06 15:45 ` Daniel Vetter 2023-04-06 15:45 ` Daniel Vetter 2023-04-06 17:19 ` Miguel Ojeda 2023-04-06 17:19 ` Miguel Ojeda 2023-04-06 15:53 ` Asahi Lina 2023-04-06 16:13 ` [Linaro-mm-sig] " Daniel Vetter 2023-04-06 16:13 ` Daniel Vetter 2023-04-06 16:39 ` Asahi Lina 2023-04-06 16:39 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 08/18] rust: dma_fence: Add DMA Fence abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-04-05 11:10 ` Daniel Vetter 2023-04-05 11:10 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 09/18] rust: drm: syncobj: Add DRM Sync Object abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-04-05 12:33 ` Daniel Vetter 2023-04-05 12:33 ` Daniel Vetter 2023-04-06 16:04 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 10/18] drm/scheduler: Add can_run_job callback Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-08 8:46 ` Christian König 2023-03-08 8:46 ` Christian König 2023-03-08 9:41 ` Asahi Lina 2023-03-08 9:41 ` Asahi Lina 2023-03-08 10:00 ` Christian König 2023-03-08 10:00 ` Christian König 2023-03-08 14:53 ` Asahi Lina 2023-03-08 14:53 ` Asahi Lina 2023-03-08 15:30 ` Christian König 2023-03-08 15:30 ` Christian König 2023-03-08 16:44 ` Asahi Lina 2023-03-08 16:44 ` Asahi Lina 2023-03-08 17:57 ` Christian König 2023-03-08 17:57 ` Christian König 2023-03-08 19:05 ` Asahi Lina 2023-03-08 19:05 ` Asahi Lina 2023-03-08 19:12 ` Christian König 2023-03-08 19:12 ` Christian König 2023-03-08 19:45 ` Asahi Lina 2023-03-08 19:45 ` Asahi Lina 2023-03-08 20:14 ` Christian König 2023-03-08 20:14 ` Christian König 2023-03-09 6:30 ` Asahi Lina 2023-03-09 6:30 ` Asahi Lina 2023-03-09 8:05 ` Christian König 2023-03-09 8:05 ` Christian König 2023-03-09 9:14 ` Asahi Lina 2023-03-09 9:14 ` Asahi Lina 2023-03-09 18:50 ` Faith Ekstrand 2023-03-09 18:50 ` Faith Ekstrand 2023-03-10 9:16 ` Asahi Lina 2023-03-10 9:16 ` Asahi Lina 2023-03-08 12:39 ` Karol Herbst 2023-03-08 12:39 ` Karol Herbst 2023-03-08 13:47 ` Christian König 2023-03-08 13:47 ` Christian König 2023-03-08 14:43 ` Karol Herbst 2023-03-08 14:43 ` Karol Herbst 2023-03-08 15:02 ` Christian König 2023-03-08 15:02 ` Christian König 2023-03-08 15:19 ` Karol Herbst 2023-03-08 15:19 ` Karol Herbst 2023-03-16 13:40 ` Daniel Vetter 2023-03-16 13:40 ` Daniel Vetter 2023-04-05 13:40 ` Daniel Vetter 2023-04-05 13:40 ` Daniel Vetter 2023-04-05 14:14 ` Christian König 2023-04-05 14:21 ` Daniel Vetter 2023-04-05 14:21 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 11/18] drm/scheduler: Clean up jobs when the scheduler is torn down Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-08 9:57 ` Maarten Lankhorst 2023-03-08 9:57 ` Maarten Lankhorst 2023-03-08 10:03 ` Christian König 2023-03-08 10:03 ` Christian König 2023-03-08 15:18 ` Asahi Lina 2023-03-08 15:18 ` Asahi Lina 2023-03-08 15:42 ` Christian König 2023-03-08 15:42 ` Christian König 2023-03-08 17:32 ` Asahi Lina 2023-03-08 17:32 ` Asahi Lina 2023-03-08 18:12 ` Christian König 2023-03-08 18:12 ` Christian König 2023-03-08 19:37 ` Asahi Lina 2023-03-08 19:37 ` Asahi Lina 2023-03-09 8:42 ` Christian König 2023-03-09 8:42 ` Christian König 2023-03-09 9:43 ` Asahi Lina 2023-03-09 9:43 ` Asahi Lina 2023-03-09 11:47 ` Christian König 2023-03-09 11:47 ` Christian König 2023-03-09 13:48 ` Asahi Lina 2023-03-09 13:48 ` Asahi Lina 2023-03-09 19:59 ` Faith Ekstrand 2023-03-09 19:59 ` Faith Ekstrand 2023-03-10 9:58 ` Asahi Lina 2023-03-10 9:58 ` Asahi Lina 2023-03-13 20:11 ` Faith Ekstrand 2023-03-13 20:11 ` Faith Ekstrand 2023-03-08 17:39 ` alyssa 2023-03-08 17:39 ` alyssa 2023-03-08 17:44 ` Asahi Lina 2023-03-08 17:44 ` Asahi Lina 2023-03-08 18:13 ` Christian König 2023-03-08 18:13 ` Christian König 2023-04-05 13:52 ` Daniel Vetter 2023-04-05 13:52 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 12/18] rust: drm: sched: Add GPU scheduler abstraction Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-04-05 15:43 ` Daniel Vetter 2023-04-05 15:43 ` Daniel Vetter 2023-04-05 19:29 ` Daniel Vetter 2023-04-18 8:45 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 13/18] drm/gem: Add a flag to control whether objects can be exported Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-04-05 14:55 ` Daniel Vetter 2023-04-05 14:55 ` Daniel Vetter 2023-03-07 14:25 ` [PATCH RFC 14/18] rust: drm: gem: Add set_exportable() method Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 15/18] drm/asahi: Add the Asahi driver UAPI [DO NOT MERGE] Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 15:28 ` Karol Herbst 2023-03-07 15:28 ` Karol Herbst 2023-03-07 14:25 ` [PATCH RFC 16/18] rust: bindings: Bind the Asahi DRM UAPI Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 17/18] rust: macros: Add versions macro Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-03-07 14:25 ` [PATCH RFC 18/18] drm/asahi: Add the Asahi driver for Apple AGX GPUs Asahi Lina 2023-03-07 14:25 ` Asahi Lina 2023-04-05 14:37 ` Daniel Vetter 2023-04-05 14:37 ` Daniel Vetter 2023-04-06 4:44 ` Asahi Lina 2023-04-06 4:44 ` Asahi Lina 2023-04-06 5:09 ` Asahi Lina 2023-04-06 5:09 ` Asahi Lina 2023-04-06 11:26 ` Daniel Vetter 2023-04-06 11:26 ` Daniel Vetter 2023-04-06 10:42 ` [Linaro-mm-sig] " Daniel Vetter 2023-04-06 10:42 ` Daniel Vetter 2023-04-06 11:55 ` Daniel Vetter 2023-04-06 11:55 ` Daniel Vetter 2023-04-06 13:15 ` Asahi Lina 2023-04-06 13:15 ` Asahi Lina 2023-04-06 13:48 ` Daniel Vetter 2023-04-06 13:48 ` Daniel Vetter 2023-04-06 15:19 ` Asahi Lina 2023-04-06 15:19 ` Asahi Lina 2023-04-05 14:44 ` Daniel Vetter 2023-04-05 14:44 ` Daniel Vetter 2023-04-06 5:02 ` Asahi Lina 2023-04-06 5:02 ` Asahi Lina 2023-04-06 5:09 ` Asahi Lina 2023-04-06 5:09 ` Asahi Lina 2023-04-06 11:25 ` [Linaro-mm-sig] " Daniel Vetter 2023-04-06 11:25 ` Daniel Vetter 2023-04-06 13:32 ` Asahi Lina 2023-04-06 13:32 ` Asahi Lina 2023-04-06 13:54 ` Daniel Vetter 2023-04-06 13:54 ` Daniel Vetter 2023-03-07 16:17 ` [PATCH RFC 00/18] Rust DRM subsystem abstractions (& preview AGX driver) Asahi Lina 2023-03-07 16:17 ` Asahi Lina
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=5a0db63c043adc47b289b3f1d22935a0a63c926e.camel@collabora.com \ --to=faith.ekstrand@collabora.com \ --cc=airlied@gmail.com \ --cc=alex.gaynor@gmail.com \ --cc=alyssa@rosenzweig.io \ --cc=asahi@lists.linux.dev \ --cc=bjorn3_gh@protonmail.com \ --cc=boqun.feng@gmail.com \ --cc=christian.koenig@amd.com \ --cc=daniel@ffwll.ch \ --cc=dave.hansen@linux.intel.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=ella@iglunix.org \ --cc=gary@garyguo.net \ --cc=jarkko@kernel.org \ --cc=kherbst@redhat.com \ --cc=lina@asahilina.net \ --cc=linaro-mm-sig@lists.linaro.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-media@vger.kernel.org \ --cc=linux-sgx@vger.kernel.org \ --cc=luben.tuikov@amd.com \ --cc=maarten.lankhorst@linux.intel.com \ --cc=mary@mary.zone \ --cc=mripard@kernel.org \ --cc=ojeda@kernel.org \ --cc=rust-for-linux@vger.kernel.org \ --cc=sumit.semwal@linaro.org \ --cc=tzimmermann@suse.de \ --cc=wedsonaf@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.