Hi Miguel,
> On 28 Jun 2025, at 06:44, Miguel Ojeda
> wrote:
>
> Hi Daniel,
>
> Some procedural notes and general comments, and please note that some
> may apply several times.
>
> On Sat, Jun 28, 2025 at 12:35 AM Daniel Almeida
> wrote:
>>
>> Sig
Hi Danilo, thank you an Boqun for having a look at this,
> On 27 Jun 2025, at 20:12, Danilo Krummrich wrote:
>
> On Fri, Jun 27, 2025 at 07:34:04PM -0300, Daniel Almeida wrote:
>> +#[pin_data]
>> +pub(crate) struct TyrData {
>> +pub(crate) pdev: ARef,
>&
I’ll fix the missing “rust: drm:” tags on a v2.
— Daniel
Signed-off-by: Alice Ryhl
Co-developed-by: Beata Michalska
Signed-off-by: Beata Michalska
Co-developed-by: Carsten Haitzler
Signed-off-by: Carsten Haitzler
Co-developed-by: Rob Herring
Signed-off-by: Rob Herring
Signed-off-by: Daniel Almeida
---
The development of Tyr itself started in
.: something failed somewhere else and the
allocator is dirty.
— Daniel
Hi Miguel
> On 25 Jun 2025, at 09:47, Miguel Ojeda
> wrote:
>
> On Tue, Jun 24, 2025 at 12:13 AM Daniel Almeida
> wrote:
>>
>> Signed-off-by: Asahi Lina
>
> Patches from others also need to be signed off by you as carrier.
Thanks for catching that. This w
0d6b..f369da5b12fb876f23eda8ea7665990919f3960c
100644
--- a/rust/kernel/drm/mod.rs
+++ b/rust/kernel/drm/mod.rs
@@ -7,6 +7,7 @@
pub mod file;
pub mod gem;
pub mod ioctl;
+pub mod mm;
pub use self::device::Device;
pub use self::driver::Driver;
---
base-commit: dc35ddcf97e99b18559d0855071030e664aae44d
change-id: 20250623-topics-tyr-drm_mm-d1d43d436311
Best regards,
--
Daniel Almeida
eemed both somewhat sufficient
and required for upcoming drivers.
Note that all operations provided were tested on a real driver and on a
real device. Specifically, all operations so far are required.
Signed-off-by: Asahi Lina
Co-developed-by: Daniel Almeida
Signed-off-by: Daniel Almeida
---
Hi
he ffi call.
Unless I missed something?
— Daniel
Hi Boris,
> On 19 Jun 2025, at 08:57, Boris Brezillon
> wrote:
>
> Hi,
>
> On Fri, 13 Jun 2025 13:42:59 -0300
> Daniel Almeida wrote:
>
>> Danilo,
>>
>>
>>>
>>>
>>>>>> +// SAFETY: DRM GpuVmBo objects are alw
is discussion is that we agree that this Opaque is not
needed, then we definitely need this patch, because using Opaque complicates
all ioctls implementations by making it harder to get to the inner T in the
first place. We would have to needlessly add a lot of unsafe blocks for drivers
that wouldn't otherwise be there.
-- Daniel
> On 19 Jun 2025, at 09:26, Daniel Almeida wrote:
>
> Hi Benno,
>
>> On 19 Jun 2025, at 08:01, Benno Lossin wrote:
>>
>> On Thu Jun 19, 2025 at 12:55 PM CEST, Danilo Krummrich wrote:
>>> On Thu, Jun 19, 2025 at 12:21:02PM +0200, Beata Michalska w
mut
> $crate::uapi::$struct)
> };
> // SAFETY: This is just the DRM file structure
> let file = unsafe {
> $crate::drm::File::as_ref(raw_file) };
> --
> 2.25.1
>
>
— Daniel
t; > > Modify the VGA arbiter code and matching sysfs file entries to
> > > > > > examine all
> > > > > > PCI display class devices. The existing logic stays the same.
> > > > > >
> > > > > > This will cause all GPUs to gain
> On Jun 17, 2025, at 16:50, Alex Williamson wrote:
>
> On Tue, 17 Jun 2025 15:56:26 -0500
> Daniel Dadap wrote:
>
>>> On Tue, Jun 17, 2025 at 03:15:35PM -0500, Mario Limonciello wrote:
>>>
>>>
>>> On 6/17/25 2:20 PM, Daniel Dadap wro
On Tue, Jun 17, 2025 at 03:15:35PM -0500, Mario Limonciello wrote:
>
>
> On 6/17/25 2:20 PM, Daniel Dadap wrote:
> > On Tue, Jun 17, 2025 at 12:59:10PM -0500, Mario Limonciello wrote:
> > > From: Mario Limonciello
> > >
> > > On a mobile system with a
PU in this case) will now show `1` and the incorrect device shows `0`.
> Userspace then picks the right device as well.
>
> Link:
> https://github.com/robherring/libpciaccess/commit/b2838fb61c3542f107014b285cbda097acae1e12
> [1]
> Suggested-by: Daniel Dadap
> Acked-by: Thomas
e would be
aware of this new lock so we could safely lock it in dec_ref(). We would also
be transparently managing the locking on behalf of drivers in all the other
calls where the VA list is accessed, which is another plus as I said above.
I understand that most C drivers do not need an extra lock, but it's getting
hard to emulate this behavior in Rust.
Also, the fact that they don't need an extra lock does not invalidate the fact
that it would be simply safer to have this extra lock anyways. In other words,
it is still completely possible to use GPUVM without locking anything and IMHO
we shouldn't bring this over if we can help it.
— Daniel
; +self.0.gem.offset
>> +}
>> +
>> +/// Returns the GEM object to map.
>> +#[inline]
>> +pub fn object(&self) -> &::Object {
>
> You can use drm::Driver instead, which reads much better.
Can you expand a bit on this?
— Daniel
aid Guard for the interval tree
itself,
b) This will appear in all functions where the lock should be taken, which
pollutes the API quite a bit.
c) Having "either a custom lock or the resv lock" sounds a bit confusing.
Handling this transparently in Rust makes the API easier to use (and harder to
misuse)
— Daniel
Ok, I did just that and it's working great in my testing:
>
> I create a domain when the client opens the DRM connection and map all
> its BOs to it. Then when a job is about to start, I detach whatever
> domain was attached to the core's group and attach that client's
> domain.
>
> Will send a v7 with it in a couple of days.
Awesome, thanks so much for that Tomeu!
Cheers,
Daniel
ng the kernel's range allocator either, and it saves userspace a
roundtrip to discover the VA for a BO it just created/mapped?
Cheers,
Daniel
ocation and inform
userspace of them?
I'm really sorry this has come so late in the game.
Cheers,
Daniel
Signed-off-by: Konstantin Shabanov
> Reported-by: Dan Callaghan
> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7968
Acked-by: Daniel Stone
Cheers,
Daniel
ask them to learn a enough KUnit so that they write _basic_ sanity
tests for it and add it to their patch series.
Maybe it's annoying to cover all edge cases properly and very
difficult to try and test concurrent read/writes, but those are
inherently harder problems.
Cheers,
Daniel
On Mon, 26 May 2025 at 08:16, Boris Brezillon
wrote:
> On Sat, 24 May 2025 16:03:37 +0100
> Daniel Stone wrote:
> > Unfortunately I have to revoke my T-b as we're seeing a pile of
> > failures in a CI stress test with this, e.g.
> > https://gitlab.freedesktop.org
Hi,
On Sun, 25 May 2025 at 11:51, Krzysztof Kozlowski wrote:
> On 25/05/2025 12:48, Daniel Stone wrote:
> > On Sun, 25 May 2025 at 06:16, Krzysztof Kozlowski
> > wrote:
> >> ---
> >> a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.ya
On Sun, 25 May 2025 at 06:16, Krzysztof Kozlowski
wrote:
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
> @@ -45,9 +45,8 @@ properties:
>- description: OVL-2L Clock
>
>iommu
is not scheduled, we suspend the
> timeout again which undoes what drm_sched_job_begin() did when calling
> drm_sched_start_timeout(). So the timeout does not reset when a job
> is finished.
>
> Co-developed-by: Boris Brezillon
> Signed-off-by: Boris Brezillon
> Tested-by: Daniel
nce. This may happen
dynamically during runtime, e.g. when a video is playing and a user
moves their cursor over the plane to make the UI controls visible.
I think this should be handled through the atomic_commit() handler,
with asynchronous tracking of the state, instead of the hard block
here.
Cheers,
Daniel
s sure that those GEM
> objects can't be released while working with them.
>
> Regtards,
> Christian.
>
I guess Danilo is the right person to ask, but IIRC the plan was to expose the
exec logic as part of the GPUVM abstraction, which is currently work in
progress.
— Daniel
lures due to timeouts when fetching the full repository.
>
> The current s3cp stopped working after the migration. Update to the
> latest mesa and ci-templates to get s3cp working again and adapt to
> recent changes in mesa-ci.
I thought I already did this, sorry; the series is:
Acked-b
Hi,
On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> On 2025-05-15 13:19, Daniel Stone wrote:
> > Yeah, the Weston patches are marching on. We've still been doing a
> > little bit of cleanup and prep work in the background to land them,
> > but we also can't l
t_gem_debugfs_bo_add() call instead needs to be
in the panfrost_gem_create_object() callback rather than only
panfrost_gem_create() which is called through the ioctl?
Cheers,
Daniel
PI though: as said previously, the uAPI looks
completely solid and it's something we can definitely beneficially use
in Weston. (Even if we do need the obvious follow-ons for
post-blending as well ...)
Cheers,
Daniel
a struct drm_gpuvm_bo, struct drm_gpuva
> or struct drm_gpuvm, since they all carry GEM object pointers.
>
> For reference, you can look for "_held" in drivers/gpu/drm/drm_gpuvm.c.
>
Looking at Lyude’s (excellent) KMS series, one thing that comes to mind is
using Lock::from_
TY: This is safe via `DriverConnector`s type invariants.
> +let connector = unsafe { Connectorfrom_raw(connector) };
> +
> +// SAFETY: This FFI callback is only called while `mode_config.lock` is
> held
> +// We use ManuallyDrop here to prevent the lock from being released
> after the callback
> +// completes, as that should be handled by DRM.
> +let guard = ManuallyDrop::new(unsafe {
> ModeConfigGuard::new(connector.drm_dev()) });
> +
> +T::get_modes(connector.guard(&guard), &guard)
> +}
> +
> +/// A privileged [`Connector`] obtained while holding a [`ModeConfigGuard`].
> +///
> +/// This provides access to various methods for [`Connector`] that must
> happen under lock, such as
> +/// setting resolution preferences and adding display modes.
> +///
> +/// # Invariants
> +///
> +/// Shares the invariants of [`ModeConfigGuard`].
> +#[derive(Copy, Clone)]
> +pub struct ConnectorGuard<'a, T: DriverConnector>(&'a Connector);
> +
> +impl Deref for ConnectorGuard<'_, T> {
> +type Target = Connector;
> +
> +fn deref(&self) -> &Self::Target {
> +self.0
> +}
> +}
> +
> // SAFETY: DRM expects this struct to be zero-initialized
> unsafe impl Zeroable for bindings::drm_connector_state {}
>
> --
> 2.48.1
>
>
— Daniel
num Type {
> +/// Overlay planes represent all non-primary, non-cursor planes. Some
> drivers refer to these
> +/// types of planes as "sprites" internally.
> +Overlay = bindings::drm_plane_type_DRM_PLANE_TYPE_OVERLAY,
> +
> +/// A primary plane attached to a CRTC that is the most likely to be
> able to light up the CRTC
> +/// when no scaling/cropping is used, and the plane covers the whole
> CRTC.
> +Primary = bindings::drm_plane_type_DRM_PLANE_TYPE_PRIMARY,
> +
> +/// A cursor plane attached to a CRTC that is more likely to be enabled
> when no scaling/cropping
> +/// is used, and the framebuffer has the size indicated by
> [`ModeConfigInfo::max_cursor`].
> +///
> +/// [`ModeConfigInfo::max_cursor`]: crate::drm::kms::ModeConfigInfo
> +Cursor = bindings::drm_plane_type_DRM_PLANE_TYPE_CURSOR,
> +}
> +
>
— Daniel
> On 5 Mar 2025, at 19:59, Lyude Paul wrote:
>
> We start off by introducing wrappers for the first important type of mode
> object: a DRM display connector. This introduces Connector DriverConnector> and ConnectorState. Both
> DriverConnector and DriverConnectorState must be implemented by KM
e
> decoders are likely much more common than hardware ones for the foreseeable
> future. Note that these formats already have Vulkan equivalents:
> - VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM
> - VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM
> - VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM
Thanks a lot for these - series is:
Reviewed-by: Daniel Stone
Cheers,
Daniel
Signed-off-by: Lyude Paul
>
> ---
>
> V3:
> * Get rid of Kms, long live KmsDriver
> After Daniel pointed out that we should just make KmsDriver a supertrait
> of Driver, it immediately occurred to me that there's no actual need for
> Kms to be a separate trait at
Hi Lyude,
> On 5 Mar 2025, at 19:59, Lyude Paul wrote:
>
> This adds some very basic rust bindings for fourcc. We only have a single
> format code added for the moment, but this is enough to get a driver
> registered.
>
> Signed-off-by: Lyude Paul
>
> ---
> V3:
> * Drop FormatList and Modifie
ments are valid per the type invariant.
> Ok(unsafe {
> -bindings::drm_vma_node_offset_addr(ptr::addr_of_mut!(
> -(*self.into_gem_obj().get()).vma_node
> -))
> +
> bindings::drm_vma_node_offset_addr(ptr::addr_of_mut!((*self.as_gem_obj()).vma_node))
Hmm, I thought we were on a quest to remove addr_of_mut!() in favor of &raw mut?
Anyways, this is again orthogonal to your patch.
> })
> }
> }
> --
> 2.48.1
>
>
This looks good.
Reviewed-by: Daniel Almeida
get(self.as_raw()) };
> -}
> -
> -unsafe fn dec_ref(obj: NonNull) {
> -// SAFETY: `obj` is a valid pointer to an `Object`.
> -let obj = unsafe { obj.as_ref() };
> -
> -// SAFETY: The safety requirements guarantee that the refcount is
> non-zero.
> -unsafe { bindings::drm_gem_object_put(obj.as_raw()) }
> -}
> -}
> -
> impl super::private::Sealed for Object {}
>
> impl Deref for Object {
> --
> 2.48.1
>
>
Reviewed-by: Daniel Almeida
er is null befoe calling as_ref(),
> ensuring that `ptr` is a
> +// valid pointer to an initialized `Self`.
> +// XXX: The expect lint here is to workaround
> +// https://github.com/rust-lang/rust-clippy/issues/13024
> +#[expect(clippy::undocumented_unsafe_blocks)]
> +let obj = (!ptr.is_null())
> +.then(|| unsafe { Self::as_ref(ptr) })
> +.ok_or(ENOENT)?;
> +
> +// SAFETY:
> +// - We take ownership of the reference of `drm_gem_object_lookup()`.
> +// - Our `NonNull` comes from an immutable reference, thus ensuring
> it is a valid pointer to
> +// `Self`.
> +Ok(unsafe { ARef::from_raw(obj.into()) })
> }
>
> /// Creates an mmap offset to map the object from userspace.
> --
> 2.48.1
>
>
With the extra safety requirement,
Reviewed-by: Daniel Almeida
will live as long as
> // the GEM object lives, hence the pointer must be valid.
> -unsafe { &*self.dev }
> +unsafe { self.dev.as_ref() }
> }
>
> fn as_raw(&self) -> *mut bindings::drm_gem_object {
> --
> 2.48.1
>
>
Reviewed-by: Daniel Almeida
Hi Andy,
On Thu, 8 May 2025 at 11:49, Andy Yan wrote:
> Let the user know what went wrong in drm_gem_fb_afbc_init
> failure paths.
Thanks for this, and thanks also for using drm_dbg_kms() to make sure
that userspace can't flood the log with errors.
Reviewed-by: Daniel Stone
Cheers,
Daniel
rite whatever
to it'. I think you might want to write this out as 'Z:Y' or something
instead of 'x:Y'. But honestly I'd expect people to still get this
wrong and fill it with all sorts of fun values.
Otherwise this looks good to me though; thanks for typing it up. A
VKMS implementation would be really nice for this if you've got the
time.
Cheers,
Daniel
Hi Danilo,
FYI, most of this patch still retains the original code from the Asahi project,
> On 22 Apr 2025, at 18:16, Danilo Krummrich wrote:
>
> (Not a full review, but some things that took my attention from a brief look.)
>
> On Tue, Apr 22, 2025 at 01:41:53PM -0300, Danie
From: Asahi Lina
This is just for basic usage in the DRM shmem abstractions for implied
locking, not intended as a full DMA Reservation abstraction yet.
Signed-off-by: Asahi Lina
---
rust/bindings/bindings_helper.h | 1 +
rust/helpers/dma-resv.c | 13 +
rust/helpers/helper
rs.c | 2 +
rust/kernel/drm/gpuvm.rs| 807
rust/kernel/drm/mod.rs | 2 +
6 files changed, 855 insertions(+)
---
base-commit: e7de41cc4b01dd5500a0c2533c64bdb3f5360567
change-id: 20250320-gpuvm-29d3e0726f34
Best regards,
--
Daniel Almeida
GpuVm::lock(), which is a similar approach as the one
taken by CondVar.
It is up to drivers to make sure that the guard indeed provides the
required locking. Any operations that modifies the interval tree is only
available after the VM has been locked as per above.
Signed-off-by: Asahi Lina
Co-dev
that the buffer can _never_ work, because the failure may be
transient or due to a combination of things.
Returning the more localised error saves userspace a lot of work and
enables a more optimal system.
Cheers,
Daniel
(even on older GPUs it's still in
> theory possible to break up the work and do incremental rendering). But
> that ship sailed long ago so this would be a regression.
Yeah. Vulkan clients are a little better in this regard, but GL
clients are pretty useless at dealing with device loss across the
board.
Cheers,
Daniel
Hi,
On Fri, 11 Apr 2025 at 16:05, Adrián Larumbe
wrote:
> +#define PANTHOR_BO_LABEL_MAXLENPAGE_SIZE
PAGE_SIZE can change between kernel builds with a config setting.
If the thinking here is '4KiB is big enough' (which I agree with),
then just define it to 4096.
Cheers,
Daniel
ID in the completion event with atomic userspace is in this
thread, apart from Maarten.
Cheers,
Daniel
#define PWM_HYST 0x5
>
> #define CURRENT_SINKS_MASK GENMASK(5, 0)
> +#define LOWER_BYTE GENMASK(2, 0)
I like using masks and FIELD_GET() but this is not a byte. These are
the least significant bits.
Daniel.
specific hacks for every backlight controller that
appears in a primary/secondary configuration.
Also, the kernel seeks to avoid adding new instances of master/slave
terminology. See the coding style doc for suggested alternatives:
https://www.kernel.org/doc/html/latest/process/coding-style.html#naming
Daniel.
Hi Harry,
On Tue, 8 Apr 2025 at 18:30, Harry Wentland wrote:
> On 2025-04-08 12:40, Daniel Stone wrote:
> > OK, Harry's reply cleared that up perfectly - the flexibility that's
> > there at the moment is about being able to reuse colorops for CRTCs in
> > post
Hi there,
On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> wrote:
> > 'plane' seems really incongruous here. The colorop can be created for
> > any number of planes, but we're setting it to always be bound t
Support AFBC function co-operation with GPU
> * support 2560x1600 UI
You could even fail the framebuffer creation, so userspace knows early
it can never work, as opposed to -EINVAL from atomic_check which could
mean ~anything.
Cheers,
Daniel
/*
> + * Enable all 6 current sinks if the number of current
> + * sinks isn't specified and the bootloader didn't set
> + * the value.
> + */
> + ktz8866_read(ktz, BL_EN, &val);
> + if (!(val && CURRENT_SINKS_MASK))
This is the wrong form of AND.
> + ktz8866_write(ktz, BL_EN, CURRENT_SINKS_MASK);
> + }
Daniel.
.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Thompson (RISCstar)
Daniel.
ay. Removing fbdev internals makes backlight
> drivers easier to integrate into other display drivers, such as DRM.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Thompson (RISCstar)
Daniel.
e requested period
to match h/ware capability but then neglected to scale the requested
duty cycle accordingly. That means the qcomm PWM driver programming a
fractional value into the hardware that was not being anywhere close
to duty_cycle / period.
So the recommendation was to fix the PWM driver rather than have
pwm_bl.c work around it?
Daniel.
-8bb647b66b1c
Best regards,
--
Daniel Almeida
It's up to you but
I'd recommend keeping the original v3 wording and label it something
like:
V3 -> V4: No functional changes, just correcting the version number
Daniel.
>
> Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of
> device_node.name"
/or igt.)
Either way, I suspect that clorop->plane is the wrong thing to do, and
that it maybe wants to be a list of planes in the drm_colorop_state?
Cheers,
Daniel
olve the issue.
I'm afraid this patch got swamped in my mailbox and I missed it.
Worse, we've just been discussing and reviewing a patch for the same
issue from another developer:
https://lore.kernel.org/all/20250401091647.22784-1-bsdhenrymar...@gmail.com/
So, I just wanted to acknowlege the mistake. Sorry.
Daniel.
vent this issue.
>
> Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of
> device_node.name")
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Henry Martin
Reviewed-by: Daniel Thompson (RISCstar)
Daniel.
NEL, "%pOFn",
> dev->of_node);
> + if (!wled->name) {
> + dev_err(dev, "Failed to allocate memory for wled
> name\n");
> + return -ENOMEM;
> + }
> + }
> +
No objections to the check but I don't think it needs a dev_err(). It
is a waste of .text to store a string that is likely never to be
printed.
Daniel.
ges. Also replace broken s3cp command with a curl wrapper call in
> drm-ci.
Thanks a lot for fixing this. Sorry the fallout has been so bad.
You can also upgrade ci-templates to get an s3cp which works again.
Cheers,
Daniel
is pretty brutal. Is there a way to unshallow only back
to the merge base?
Cheers,
Daniel
the series is:
Acked-by: Daniel Stone
Cheers,
Daniel
Hi Miguel, thanks for having a look at this:
> On 24 Mar 2025, at 14:36, Miguel Ojeda
> wrote:
>
> Hi Daniel,
>
> A few quick notes for future versions on style/docs to try to keep
> things consistent upstream -- not an actual review.
>
> On Mon, Mar 24, 202
GpuVm::lock(), which is a similar approach as the one
taken by CondVar.
It is up to drivers to make sure that the guard indeed provides the
required locking. Any operations that modifies the interval tree is only
available after the VM has been locked as per above.
Signed-off-by: Asahi Lina
Co-dev
From: Asahi Lina
This is just for basic usage in the DRM shmem abstractions for implied
locking, not intended as a full DMA Reservation abstraction yet.
Signed-off-by: Asahi Lina
---
rust/bindings/bindings_helper.h | 4 +++-
rust/helpers/dma-resv.c | 13 +
rust/helpers/hel
01dd5500a0c2533c64bdb3f5360567
change-id: 20250320-gpuvm-29d3e0726f34
Best regards,
--
Daniel Almeida
"Alexandre Courbot" writes:
> Hi Boqun,
>
> On Fri Mar 21, 2025 at 3:17 AM JST, Boqun Feng wrote:
>> Also an Instant type has been proposed and reviewed for a while:
>>
>>
>> https://lore.kernel.org/rust-for-linux/20250220070611.214262-5-fujita.tomon...@gmail.com/
>>
>> we should use that t
ed to help reduce
> overhead when emulating sparse with scratch/zero pages, which is still
> very new functionality in hk).
>
> Accelerating this properly involves GPUVM patches - although even without
> that, moving the loop into the kernel so it's only a single ioctl
> (user-kernel roundtrip) seems worth keeping the flag for.
FYI: I will be posting a patch for the GPUVM abstraction soon.
— Daniel
ACHABLE() in source file
> - use lock guards
> - initialize lcd list and list mutex
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Simona Vetter
Reviewed-by: Daniel Thompson (RISCstar)
Daniel.
test robot)
I was convinced by the replies to other things in v4. Thanks!
> v3:
> - declare empty fb_bl_notify_blank() as static inline (kernel test robot)
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Simona Vetter
Reviewed-by: Daniel Thompson (RISCstar)
Daniel.
Alexandre Courbot writes:
> +impl Add for Timestamp {
> +type Output = Self;
> +
> +fn add(mut self, rhs: Duration) -> Self::Output {
> +let mut nanos = rhs.as_nanos();
> +while nanos > u64::MAX as u128 {
> +self.0 = self.0.wrapping_add(nanos as u64);
> +
From: Asahi Lina
Allow a GEM object to share another object's DMA reservation, for use
with drm_gpuvm. To keep memory safety, we hold a reference to the GEM
object owning the resv, and drop it when the child object is freed.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
From: Asahi Lina
This is just for basic usage in the DRM shmem abstractions for implied
locking, not intended as a full DMA Reservation abstraction yet.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
rust/bindings/bindings_helper.h | 1 +
rust/helpers/dma-resv.c | 13
From: Asahi Lina
There doesn't seem to be a way for the Rust bindings to get a
compile-time constant reference to drm_gem_shmem_vm_ops, so we need to
duplicate that structure in Rust... this isn't nice...
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
drive
Asahi Lina
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index
5ab351409312b5a0de542df2b63627
From: Asahi Lina
This allows drivers to control whether a given GEM object is allowed to
be exported via PRIME to other drivers.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
rust/kernel/drm/gem/mod.rs | 13 +
rust/kernel/drm/gem/shmem.rs | 4
2 files
drm_gem_private_object_init.
Signed-off-by: Asahi Lina
Signed-off-by: Daniel Almeida
---
drivers/gpu/drm/drm_gem.c | 1 +
drivers/gpu/drm/drm_prime.c | 5 +
include/drm/drm_gem.h | 8
3 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
: Daniel Almeida
---
rust/bindings/bindings_helper.h | 3 +
rust/helpers/drm.c | 46 +
rust/helpers/helpers.c | 1 +
rust/helpers/scatterlist.c | 13 ++
rust/kernel/drm/gem/mod.rs | 2 +
rust/kernel/drm/gem/shmem.rs| 422
ges, but have the same EXPORT_SYMBOL_GPL()
questions I did with the backlight code.
Daniel.
(struct backlight_device *bd)
> -{
> - return 0;
> + list_for_each_entry(bd, &backlight_dev_list, entry)
> + backlight_notify_blank(bd, display_dev, fb_on, prev_fb_on);
> }
> -
> -static inline void backlight_unregister_fb(struct backlight_device *bd)
> -{
> -}
> -#endif /* CONFIG_FB_CORE */
> +EXPORT_SYMBOL(backlight_notify_blank_all);
Same here.
Daniel.
gt; manual locking with a guard.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Thompson (RISCstar)
Daniel.
+--
> > > include/linux/lcd.h | 21 -
> > > include/linux/leds.h | 6 ++
> > > 11 files changed, 205 insertions(+), 208 deletions(-)
> > No immediately obvious issues from the LEDs side.
> >
> > Still needs reviews from Backlight and fbdev.
>
> I'm confused. Are you not the backlight maintainer?
Lee is, yes, but this kind of comment is usually a hint that I've
been delinquent in my backlight reviews and records that he hasn't
looked at the backlight code yet ;-).
I'll get on it tomorrow!
Daniel.
Rahul Rameshbabu writes:
> Rust has the Drop trait[2]. If my understanding is correct, contained
> data that also implement the Drop trait cannot be enforced in terms of
> the order they are dropped/provide any kind of dependency management
> here. It's worth exploring. My concern is some very tr
missing history
and unshallow the history a bit more?
Cheers,
Daniel
cally for marge-bot and scheduled
> pipelines, but in all other cases run manually. Also
> remove CI_PROJECT_NAMESPACE checks specific to mesa.
Thanks Vignesh, this is:
Reviewed-by: Daniel Stone
nd refactors software-driver stage jobs.
>
> Test run with this series,
> https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1366054
Series is:
Reviewed-by: Daniel Stone
Please merge at will.
Cheers,
Daniel
to build the kernel in
> > > macOS. Is this the only thing missing and you'd want it to go through
> > > drm?
Yes, this is the only one missing.
> >
> > I believe the other patches have been applied or dropped. When I last
> > tested building allmodconfig
On Wed, Feb 26, 2025 at 4:23 PM Maud Spierings via B4 Relay
wrote:
>
> From: Maud Spierings
>
> Currently to configure each IOMUXC_SW_PAD_CTL_PAD the raw value of this
> register is written in the dts, these values are not obvious. Add defines
> which describe the fields of this register which ca
1 - 100 of 3323 matches
Mail list logo
