raction
> here:
>
> similar to
> https://lore.kernel.org/rust-for-linux/ZA9l0EHCRRr%2Fmyoq@boqun-archlinux
>
> * Define Device as tranparent represention of struct drm_device:
>
> #[repr(transparent)]
> struct Device(Opaque);
>
> * impl `AlwaysRefCounted`[1] for `Device`, therefore we can use
> `ARef`[2] as a smart pointer to `drm_device`.
>
> * drm_device related methods are still implemented in `impl Device`
>
> * In `open_callback`, we can just get a `` from `*mut
> bindings::drm_device` unsafely, and that's all. Or introduce a helper
> function if we want:
>
> pub unsafe fn with_device(ptr: *mut drm_device, f: F) -> Result
> where
> F: FnOnce() -> Result
> {
> let d = unsafe { &*ptr };
> f(d)
> }
>
> The main difference is that we now treat a pointer to drm_device as a
> reference to the device, not the owner.
>
> It seems we need to also change our driver/device framework to use this
> approach, but it looks better to me.
So I really don't have enough rust clue to have any useful opinion on how
the glue should look like, but semantically the struct drm_file should
only ever be borrowed as a parameter to a driver hook, so that rust can
guarantee that the driver doesn't do anything funny and uses it beyond the
end of that function. This holds for all the callbacks like open/close or
also all the ioctl.
The other semantic thing is that that the ioctls should be able to rely on
open having fully constructed the thing. I think the trait and dependent
type stuff ensure that?
What I've missed (but maybe just looked in the wrong place) is that the
ioctl support (and really anything else where the driver gets a struct
drm_file on the C side, but I don't think there is anything else) should
also make sure you get the right driver-specific type and not something
else.
I did notice the FIXME in the first patch, I guess if it makes
landing all this easier we could also keep this as a todo item to improve
once things landed. That btw holds for a lot of the big "how to map
semantics correctly to rust" questions I'm throwing up here. Maybe a
Documentation/gpu/rust.rst file would be good to include, with these todo
items noted instead of just FIXME sprinkled in patches? At least for
things that will take more effort to polish.
-Daniel
>
> Regards,
> Boqun
>
> [1]: https://rust-for-linux.github.io/docs/kernel/trait.AlwaysRefCounted.html
> [2]: https://rust-for-linux.github.io/docs/kernel/struct.ARef.html
>
> > ~Faith
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Apr 05, 2023 at 01:19:47PM +0200, Miguel Ojeda wrote:
> On Wed, Apr 5, 2023 at 1:08 PM Daniel Vetter wrote:
> >
> > Uh all the rust helper wrappers for all the kernel in a single file does
> > not sound good. Can we not split these up into each subsystem, and t
dd(1,
> Ordering::Relaxed);
> +
> +// SAFETY: The pointer is valid, so pointers to members are too.
> +// After this, all fields are initialized.
> +unsafe {
> +addr_of_mut!((*p).inner).write(inner);
> +bindings::__spin_lock_init(
> +addr_of_mut!((*p).lock) as *mut _,
> +self.lock_name.as_char_ptr(),
> +self.lock_key.get(),
> +);
> +bindings::dma_fence_init(
> +addr_of_mut!((*p).fence),
> +VTABLE,
> +addr_of_mut!((*p).lock) as *mut _,
> +self.start + context as u64,
> +seqno,
> +);
> +};
> +
> +Ok(UniqueFence(p))
> +}
> +}
> +
> +/// A DMA Fence Chain Object
> +///
> +/// # Invariants
> +/// ptr is a valid pointer to a dma_fence_chain which we own.
> +pub struct FenceChain {
> +ptr: *mut bindings::dma_fence_chain,
> +}
> +
> +impl FenceChain {
> +/// Create a new DmaFenceChain object.
> +pub fn new() -> Result {
> +// SAFETY: This function is safe to call and takes no arguments.
> +let ptr = unsafe { bindings::dma_fence_chain_alloc() };
> +
> +if ptr.is_null() {
> +Err(ENOMEM)
> +} else {
> +Ok(FenceChain { ptr })
> +}
> +}
> +
> +/// Convert the DmaFenceChain into the underlying raw pointer.
> +///
> +/// This assumes the caller will take ownership of the object.
> +pub(crate) fn into_raw(self) -> *mut bindings::dma_fence_chain {
> +let ptr = self.ptr;
> +core::mem::forget(self);
> +ptr
> +}
> +}
> +
> +impl Drop for FenceChain {
> +fn drop( self) {
> +// SAFETY: We own this dma_fence_chain.
> +unsafe { bindings::dma_fence_chain_free(self.ptr) };
> +}
> +}
> diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
> index cb23d24c6718..31866069e0bc 100644
> --- a/rust/kernel/lib.rs
> +++ b/rust/kernel/lib.rs
> @@ -36,6 +36,8 @@ mod allocator;
> mod build_assert;
> pub mod delay;
> pub mod device;
> +#[cfg(CONFIG_DMA_SHARED_BUFFER)]
> +pub mod dma_fence;
> pub mod driver;
> #[cfg(CONFIG_RUST_DRM)]
> pub mod drm;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
as *const _;
> +core::mem::forget(self);
> +
> +ObjectRef { ptr }
> +}
> +}
> +
> +impl Drop for UniqueObjectRef {
> +fn drop( self) {
> +// SAFETY: Having a UniqueObjectRef implies holding a GEM
> +// reference. The free callback will take care of deallocation.
> +unsafe {
> +bindings::drm_gem_object_put((*self.ptr).gem_obj());
> +}
> +}
> +}
> +
> +impl Deref for UniqueObjectRef {
> +type Target = T;
> +
> +fn deref() -> ::Target {
> +// SAFETY: The pointer is valid per the invariant
> +unsafe { &*self.ptr }
> +}
> +}
> +
> +impl DerefMut for UniqueObjectRef {
> +fn deref_mut( self) -> Self::Target {
> +// SAFETY: The pointer is valid per the invariant
> +unsafe { *self.ptr }
> +}
> +}
> +
> +pub(super) fn create_fops() -> bindings::file_operations {
> +bindings::file_operations {
> +owner: core::ptr::null_mut(),
> +open: Some(bindings::drm_open),
> +release: Some(bindings::drm_release),
> +unlocked_ioctl: Some(bindings::drm_ioctl),
> +#[cfg(CONFIG_COMPAT)]
> +compat_ioctl: Some(bindings::drm_compat_ioctl),
> +#[cfg(not(CONFIG_COMPAT))]
> +compat_ioctl: None,
> +poll: Some(bindings::drm_poll),
> +read: Some(bindings::drm_read),
> +llseek: Some(bindings::noop_llseek),
> +mmap: Some(bindings::drm_gem_mmap),
> +..Default::default()
> +}
> +}
> diff --git a/rust/kernel/drm/mod.rs b/rust/kernel/drm/mod.rs
> index a767942d0b52..c44760a1332f 100644
> --- a/rust/kernel/drm/mod.rs
> +++ b/rust/kernel/drm/mod.rs
> @@ -5,4 +5,5 @@
> pub mod device;
> pub mod drv;
> pub mod file;
> +pub mod gem;
> pub mod ioctl;
>
> --
> 2.35.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, 5 Apr 2023 at 11:57, Christian König wrote:
>
> Am 05.04.23 um 11:07 schrieb Daniel Vetter:
> > [SNIP]
> >> I would approach it from the complete other side. This component here is a
> >> tool to decide what job should run next.
> >>
> &
++
> drivers/gpu/drm/i915/gt/uc/intel_huc.h | 7 +--
> drivers/gpu/drm/i915/i915_perf.c | 6 +++---
> 6 files changed, 25 insertions(+), 14 deletions(-)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Apr 05, 2023 at 11:26:51AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.23 um 10:59 schrieb Daniel Vetter:
> > On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 05.04.23 um 09:49 schrieb Thomas
On Wed, 5 Apr 2023 at 11:11, Tvrtko Ursulin
wrote:
>
>
> On 05/04/2023 09:28, Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 12:45, Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> Hi,
> >>
> >> On 03/04/2023 20:40, Joshua Ashton wro
On Wed, Apr 05, 2023 at 10:19:55AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > This one nukes all framebuffers, which is a bit much. In reality
> > gma500 is igpu and never shipped with anything discrete, so there should
>
On Wed, Apr 05, 2023 at 10:53:26AM +0200, Christian König wrote:
> Am 05.04.23 um 10:34 schrieb Daniel Vetter:
> > On Wed, Apr 05, 2023 at 09:41:23AM +0200, Christian König wrote:
> > > Am 04.04.23 um 15:37 schrieb Matthew Brost:
> > > > On Tue, Apr 04, 2023 at 11:
On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > > This one nukes all framebuffers, which is a bit much. In reality
&g
On Tue, Apr 04, 2023 at 01:59:33PM -0700, Aaron Plattner wrote:
> On 4/4/23 1:18 PM, Daniel Vetter wrote:
> > Instead of calling aperture_remove_conflicting_devices() to remove the
> > conflicting devices, just call to aperture_detach_devices() to detach
> > the device that
; Regards,
> Qiang
>
> On Wed, Apr 5, 2023 at 3:28 AM Daniel Vetter wrote:
> >
> > On Tue, Apr 04, 2023 at 04:17:33PM +0100, Emil Velikov wrote:
> > > On Tue, 4 Apr 2023 at 08:13, wrote:
> > > >
> > > > From: Qiang Yu
> > > >
> > &g
ce
> > > >drm/sched: Start run wq before TDR in drm_sched_start
> > > >drm/sched: Submit job before starting TDR
> > > >drm/sched: Add helper to set TDR timeout
> > > >drm/syncobj: Warn on long running dma-fences
> > > >
> > > > Thomas Hellström (2):
> > > >dma-buf/dma-fence: Introduce long-running completion fences
> > > >drm/sched: Support long-running sched entities
> > > >
> > > > drivers/dma-buf/dma-fence.c | 142 +++---
> > > > drivers/dma-buf/dma-resv.c | 5 +
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 14 +-
> > > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +-
> > > > drivers/gpu/drm/drm_syncobj.c | 5 +-
> > > > drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 +-
> > > > drivers/gpu/drm/lima/lima_sched.c | 5 +-
> > > > drivers/gpu/drm/msm/adreno/adreno_device.c | 6 +-
> > > > drivers/gpu/drm/msm/msm_ringbuffer.c| 5 +-
> > > > drivers/gpu/drm/panfrost/panfrost_job.c | 5 +-
> > > > drivers/gpu/drm/scheduler/sched_entity.c| 127 +++--
> > > > drivers/gpu/drm/scheduler/sched_fence.c | 6 +-
> > > > drivers/gpu/drm/scheduler/sched_main.c | 278 +++-
> > > > drivers/gpu/drm/v3d/v3d_sched.c | 25 +-
> > > > include/drm/gpu_scheduler.h | 130 +++--
> > > > include/linux/dma-fence.h | 60 -
> > > > 16 files changed, 649 insertions(+), 184 deletions(-)
> > > >
> > > > --
> > > > 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> > > > drm/sched: Add helper to set TDR timeout
> > > > drm/syncobj: Warn on long running dma-fences
> > > >
> > > > Thomas Hellström (2):
> > > > dma-buf/dma-fence: Introduce long-running completion fences
> > > > drm/sched: Support long-running sched entities
> > > >
> > > >drivers/dma-buf/dma-fence.c | 142 +++---
> > > >drivers/dma-buf/dma-resv.c | 5 +
> > > >drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 14 +-
> > > >drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +-
> > > >drivers/gpu/drm/drm_syncobj.c | 5 +-
> > > >drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 +-
> > > >drivers/gpu/drm/lima/lima_sched.c | 5 +-
> > > >drivers/gpu/drm/msm/adreno/adreno_device.c | 6 +-
> > > >drivers/gpu/drm/msm/msm_ringbuffer.c| 5 +-
> > > >drivers/gpu/drm/panfrost/panfrost_job.c | 5 +-
> > > >drivers/gpu/drm/scheduler/sched_entity.c| 127 +++--
> > > >drivers/gpu/drm/scheduler/sched_fence.c | 6 +-
> > > >drivers/gpu/drm/scheduler/sched_main.c | 278
> > > > +++-
> > > >drivers/gpu/drm/v3d/v3d_sched.c | 25 +-
> > > >include/drm/gpu_scheduler.h | 130 +++--
> > > >include/linux/dma-fence.h | 60 -
> > > >16 files changed, 649 insertions(+), 184 deletions(-)
> > > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
n't thought out well enough.
Adding at least some of the people who probably should be cc'ed on
this. Please add more.
Cheers, Daniel
>
> Regards,
>
> Tvrtko
>
> [1]
> https://lore.kernel.org/dri-devel/20220407152806.3387898-1-tvrtko.ursu...@linux.intel.com/T/
> [2]
> https://lore.kernel.org/lkml/20221019173254.3361334-4-tvrtko.ursu...@linux.intel.com/T/#u
> [3]
> https://lore.kernel.org/lkml/20230314141904.1210824-1-tvrtko.ursu...@linux.intel.com/
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
tomic-helper: Set fence deadline for vblank")
Cc: Rob Clark
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Reported-by: Dmitry Baryshkov
Tested-by: Dmitry Baryshkov # test patch only
Cc: Dmitry Baryshkov
Signed-off-by: Daniel Vetter
---
drive
On Wed, Apr 05, 2023 at 12:00:23AM +0300, Ville Syrjälä wrote:
> On Tue, Apr 04, 2023 at 10:46:00PM +0200, Daniel Vetter wrote:
> > On Mon, Apr 03, 2023 at 09:07:35AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > What does vblank have to do with nu
return -EINVAL;
> >
>
> Rob already posted more or less the same fix:
>
> https://lore.kernel.org/lkml/caf6aegsdt95-uakcv2+hdmlkd2xwfpen+fmudtrmc-ps7wb...@mail.gmail.com/T/
Yeah I pushed it to drm-misc-next yesterday, please check that works. Also
note that we still (in some cases at least where) need another fix to
handle the crtc on/off state transitions (but only for drivers which do
have vblank), I'll send that out asap.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Apr 05, 2023 at 12:53:29AM +0300, Dmitry Baryshkov wrote:
> On 04/04/2023 22:16, Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
> > > On 08/03/2023 17:53, Rob Clark wrote:
> > > > From: Rob Clark
> > > &
gt; bool drm_dev_has_vblank(const struct drm_device *dev)
> {
> - return dev->num_crtcs != 0;
> + return !!dev->vblank;
> }
> EXPORT_SYMBOL(drm_dev_has_vblank);
>
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > > index 299fa2a19a90..877e2067534f 100644
> > > --- a/drivers/gpu/drm/drm_vblank.c
> > > +++ b/drivers/gpu/drm/drm_vblank.c
> > > @@ -996,10 +996,16 @@ EXPORT_SYMBOL(drm_crtc_vblank_count_and_time);
> > > int drm_crtc_next_vblank_start(struct drm_crtc *crtc, ktime_t
> > > *vblanktime)
> > > {
> > > unsigned int pipe = drm_crtc_index(crtc);
> > > - struct drm_vblank_crtc *vblank = >dev->vblank[pipe];
> > > - struct drm_display_mode *mode = >hwmode;
> > > + struct drm_vblank_crtc *vblank;
> > > + struct drm_display_mode *mode;
> > > u64 vblank_start;
> > >
> > > + if (!drm_dev_has_vblank(crtc->dev))
> > > + return -EINVAL;
> > > +
> > > + vblank = >dev->vblank[pipe];
> > > + mode = >hwmode;
> > > +
> > > if (!vblank->framedur_ns || !vblank->linedur_ns)
> > > return -EINVAL;
> > >
> > > --
> > > 2.39.2
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 04, 2023 at 08:19:37PM +, Matthew Brost wrote:
> On Tue, Apr 04, 2023 at 10:11:59PM +0200, Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 22:04, Matthew Brost wrote:
> > >
> > > On Tue, Apr 04, 2023 at 09:00:59PM +0200, Daniel Vetter wrote:
> >
16303#c28
Signed-off-by: Daniel Vetter
Cc: Aaron Plattner
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Helge Deller
Cc: Sam Ravnborg
Cc: Alex Deucher
Cc: # v5.19+ (if someone else does the backport)
---
drivers/video/aperture.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Helge Deller
Cc: Daniel Vetter
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: Dave Hansen
Cc: x...@kernel.org
Cc: "H. Peter Anvin"
---
arch/x86/video/fbdev.c | 13 +
in an actual driver
left to touch.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: "K. Y. Srinivasan"
Cc: Haiyang Zhang
Cc: Wei Liu
Cc: Dexuan Cui
Cc:
function, and the other in the generic one.
v2: Rebase.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
drivers/video/aperture.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git
a special case for
kicking out the vgacon driver only (Thomas)
References: https://bugzilla.kernel.org/show_bug.cgi?id=216303
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
---
drivers/video/aperture.c | 16
end commit message trying to summarize various discussions.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Helge Deller
Cc: linux-fb...@vger.kernel.org
Cc: Bjorn Helgaas
Cc: linux-...@vger.kernel.org
---
drivers/video/aperture.c | 6 ++
1 file changed, 2
:
- Reorder to avoid compile fail (Thomas)
- Include gma500, which retained it's called to the non-pci version.
Signed-off-by: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Javier Martinez Canillas
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Deepak Rawat
Cc: Neil Armstrong
Cc: Kevin Hilman
Cc: Jerome
only use non-pci helper, then we don't get the vga handling, and
subsequent refactoring to untangle these special cases won't work.
It's not pretty, but the simplest fix (since gma500 really is the only
quirky pci driver like this we have) is to just have both calls.
Signed-off-by: Daniel Vetter
On Tue, 4 Apr 2023 at 22:04, Matthew Brost wrote:
>
> On Tue, Apr 04, 2023 at 09:00:59PM +0200, Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 15:10, Christian König
> > wrote:
> > >
> > > Am 04.04.23 um 14:54 schrieb Thomas Hellström:
> > > >
The fb_check_var hook is supposed to validate all this stuff. Any
errors from fb_set_par are considered driver/hw issues and resulting
in dmesg warnings.
Luckily we do fix up the pixclock already, so this is all fine.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc
com/bug?id=c5faf983bfa4a607de530cd3bb00bf06cefc
Cc: sta...@vger.kernel.org # v5.4+
Cc: Daniel Vetter
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drive
. Therefore fixing all this just for drm fbdev emulation is
good enough.
Note that var->active is not set or validated. This is just control
flow for fbmem.c and needs to be validated in there as needed.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmerm
.
Signed-off-by: Daniel Vetter
Fixes: dc5bdb68b5b3 ("drm/fb-helper: Fix vt restore")
Cc: Alex Deucher
Cc: shl...@fastmail.com
Cc: Michel Dänzer
Cc: Noralf Trønnes
Cc: Thomas Zimmermann
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: David Airlie
Cc: Danie
t; -
> - seq_printf(m, "drm-engine-%s:\t%llu ns\n", sched->name,
> usage[i]);
> - }
> -}
> -
> -static const struct file_operations lima_drm_driver_fops = {
> - .owner = THIS_MODULE,
> - DRM_GEM_FOPS,
> - .show_fdinfo = lima_drm_driver_show_fdinfo,
> -};
> +DEFINE_DRM_GEM_FOPS(lima_drm_driver_fops);
>
> /*
> * Changelog:
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e build clean
> or Linus will go bananas ^_^
>
> Fwiw for the series:
> Acked-by: Emil Velikov
Can you (eitehr of you really) please push asap and make sure this doesn't
miss the last drm-misc-next pull (-rc6 is this w/e)? Otherwise we'll have
a bit a mess.
-Daniel
>
> HTH
> -Emil
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> >
> > > Then the work function could submit the work and wait for the result.
> > >
> > > The work item would then pretty much represent what you want, you can
> > > wait for it to finish and pass it along as long running dependency.
> > >
> > > Maybe give it a funky name and wrap it up in a structure, but that's
> > > basically it.
> > >
> > This very much sounds like a i915_sw_fence for the dependency tracking and
> > dma_fence_work for the actual work although it's completion fence is a
> > dma_fence.
> >
>
> Agree this does sound to i915ish as stated below one of mandates in Xe
> was to use the DRM scheduler. Beyond that as someone who a submission
> backend in the i915 and Xe, I love how the DRM scheduler works (single
> entry point), it makes everything so much easier.
>
> Matt
>
> > Although that goes against the whole idea of a condition for merging the xe
> > driver would be that we implement some sort of minimal scaffolding for
> > long-running workloads in the drm scheduler, and the thinking behind that is
> > to avoid implementing intel-specific solutions like those...
> >
> > Thanks,
> >
> > Thomas
> >
> >
> >
> > > Regards,
> > > Christian.
> > >
> > > >
> > > > Thanks,
> > > >
> > > > Thomas
> > > >
> > > >
> > > >
> > > >
> > > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
dline.
> >
> > v2: Comment typo fix (danvet)
> > v3: If there are multiple CRTCs, consider the time of the soonest vblank
> >
> > Signed-off-by: Rob Clark
> > Reviewed-by: Daniel Vetter
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/dr
> >>>
> >>> Thomas Hellström (2):
> >>> dma-buf/dma-fence: Introduce long-running completion fences
> >>> drm/sched: Support long-running sched entities
> >>>
> >>>drivers/dma-buf/dma-fence.c | 142 +++---
> >>>drivers/dma-buf/dma-resv.c | 5 +
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 14 +-
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +-
> >>>drivers/gpu/drm/drm_syncobj.c | 5 +-
> >>>drivers/gpu/drm/etnaviv/etnaviv_sched.c | 5 +-
> >>>drivers/gpu/drm/lima/lima_sched.c | 5 +-
> >>>drivers/gpu/drm/msm/adreno/adreno_device.c | 6 +-
> >>>drivers/gpu/drm/msm/msm_ringbuffer.c| 5 +-
> >>>drivers/gpu/drm/panfrost/panfrost_job.c | 5 +-
> >>>drivers/gpu/drm/scheduler/sched_entity.c| 127 +++--
> >>>drivers/gpu/drm/scheduler/sched_fence.c | 6 +-
> >>>drivers/gpu/drm/scheduler/sched_main.c | 278 +++-
> >>>drivers/gpu/drm/v3d/v3d_sched.c | 25 +-
> >>>include/drm/gpu_scheduler.h | 130 +++--
> >>>include/linux/dma-fence.h | 60 -
> >>>16 files changed, 649 insertions(+), 184 deletions(-)
> >>>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-slices these contexts on its own),
and we just need a few minimal changes:
- allowing the scheduler to ignore the completion fence and just
immediately push the next "job" in if its dependencies are ready
- maybe minimal amounts of scaffolding to handle the preemption
dma_fence beca
On Tue, 4 Apr 2023 at 19:04, Geert Uytterhoeven wrote:
>
> Hi Daniel,
>
> On Tue, Apr 4, 2023 at 5:55 PM Daniel Vetter wrote:
> > On Tue, 4 Apr 2023 at 16:51, Geert Uytterhoeven
> > wrote:
> > > On Tue, Apr 4, 2023 at 4:19 PM Daniel Vetter wrote:
> >
On Tue, 4 Apr 2023 at 16:51, Geert Uytterhoeven wrote:
>
> CC linux-fbdev
>
> On Tue, Apr 4, 2023 at 4:19 PM Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven w
On Tue, Apr 04, 2023 at 03:59:12PM +0200, Daniel Vetter wrote:
> On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
> > Hi Daniel,
> >
> > CC vkmsdrm maintainer
> >
> > Thanks for your patch!
> >
> > On Tue, Apr 4, 2023 at 2:36
On Tue, Apr 04, 2023 at 03:53:09PM +0200, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> CC vkmsdrm maintainer
>
> Thanks for your patch!
>
> On Tue, Apr 4, 2023 at 2:36 PM Daniel Vetter wrote:
> > There's a few reasons the kernel should not spam dmesg on ba
bus_probe,
> + .remove = hyperv_vmbus_remove,
> + .suspend = hyperv_vmbus_suspend,
> + .resume = hyperv_vmbus_resume,
> + .driver = {
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> + },
> +};
> +
> +/* -- */
> +/* module init/exit */
> +
> +static int __init hyperv_init(void)
> +{
> + int ret;
> +
> + ret = pci_register_driver(_pci_driver);
> + if (ret != 0)
> + return ret;
> +
> + return vmbus_driver_register(_hv_driver);
> +}
> +
> +static void __exit hyperv_exit(void)
> +{
> + vmbus_driver_unregister(_hv_driver);
> + pci_unregister_driver(_pci_driver);
> +}
> +
> +module_init(hyperv_init);
> +module_exit(hyperv_exit);
> +
> +MODULE_DEVICE_TABLE(pci, hyperv_pci_tbl);
> +MODULE_DEVICE_TABLE(vmbus, hyperv_vmbus_tbl);
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Deepak Rawat ");
> +MODULE_DESCRIPTION("DRM driver for hyperv synthetic video device");
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
xes: 6c11df58fd1a ("fbmem: Check virtual screen sizes in fb_set_var()")
Cc: Helge Deller
Cc: Geert Uytterhoeven
Cc: sta...@vger.kernel.org # v5.4+
Cc: Daniel Vetter
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Signed-off-by: Daniel Vetter
---
drivers/video/fbdev/core/fbmem.c | 4
20 +-
> 134 files changed, 119288 insertions(+), 930 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_2.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/gfxhub_v1_2.h
> create mode 100644 drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/mmhub_v1_8.h
> create mode 100644 drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/nbio_v7_9.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/athub/athub_1_8_0_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/athub/athub_1_8_0_sh_mask.h
> create mode 100644 drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_3_offset.h
> create mode 100644 drivers/gpu/drm/amd/include/asic_reg/gc/gc_9_4_3_sh_mask.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/mmhub/mmhub_1_8_0_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/mmhub/mmhub_1_8_0_sh_mask.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_sh_mask.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/oss/osssys_4_4_2_offset.h
> create mode 100644
> drivers/gpu/drm/amd/include/asic_reg/oss/osssys_4_4_2_sh_mask.h
> delete mode 100644 drivers/gpu/drm/radeon/radeon_fb.c
> create mode 100644 drivers/gpu/drm/radeon/radeon_fbdev.c
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+-
> drivers/gpu/drm/panfrost/panfrost_drv.c| 37 +
> drivers/gpu/drm/panfrost/panfrost_gpu.c| 8 ++
> drivers/gpu/drm/scheduler/sched_main.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
> drivers/gpu/drm/sun4i/sun8i_mixer.c| 2 +-
> drivers/gpu/drm/tiny/ofdrm.c | 8 +-
> drivers/gpu/drm/tiny/simpledrm.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> 54 files changed, 356 insertions(+), 179 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/display/panel/innolux,p120zdg-bf1.yaml
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
: Flush lmem contents after construction
drm/i915/perf: Drop wakeref on GuC RC error
Daniel Vetter (5):
Merge tag 'drm-intel-fixes-2023-03-30' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Merge tag 'amd-drm-fixes-6.3-2023-03-29' of
https://gitlab.freedesktop.org
--
> drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 10 +-
> drivers/gpu/drm/scheduler/sched_main.c | 6 --
> include/drm/gpu_scheduler.h | 7 ---
> 4 files changed, 10 insertions(+), 56 deletions(-)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;
>
> Tim Huang (1):
> drm/amdgpu: allow more APUs to do mode2 reset when go to S4
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ivers/gpu/drm/drm_buddy.c | 4 +-
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +-
> drivers/gpu/drm/tests/drm_buddy_test.c | 3 +-
> 10 files changed, 90 insertions(+), 93 deletions(-)
>
> --
> Thomas Zimmermann
> Graphics Driver Develop
Add DSC Support for Synaptics Cascaded MST Hub
> drm/amd/display: Take FEC Overhead into Timeslot Calculation
>
> .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 51
> ++
> .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.h| 15 +++
> 2 files cha
drivers/gpu/drm/i915/i915_perf.c | 14 ++--
> drivers/gpu/drm/i915/i915_perf_types.h | 6 ++
> drivers/gpu/drm/i915/i915_pmu.c | 10 +--
> 13 files changed, 177 insertions(+), 42 deletions(-)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; include/drm/gpu_scheduler.h | 17 ++
> include/linux/dma-fence.h | 22
> include/linux/dma-resv.h| 2 ++
> include/uapi/linux/sync_file.h | 37 +
> 14 files changed, 303 insertions(+), 34 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1813 +---------
> include/drm/bridge/samsung-dsim.h | 115 ++
> 8 files changed, 2191 insertions(+), 1729 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
> create mode 100644 include/drm/bridge/samsung-dsim.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
include/drm/gpu_scheduler.h | 17 +++
> include/linux/dma-fence.h | 22 +
> include/linux/dma-resv.h| 2 +
> include/uapi/drm/drm.h | 17 +++
> include/uapi/linux/sync_file.h | 59 +++-
> 19 files changed, 496 insertions(+), 47 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drivers/gpu/drm/rcar-du/rcar_lvds.c | 176
> +-
> drivers/gpu/drm/rcar-du/rcar_lvds.h | 12 +-
> 7 files changed, 163 insertions(+), 111 deletions(-)
>
> --
> Regards,
>
> Laurent Pinchart
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t;drm/i915/hwmon: Enable PL1 power limit"
Badal Nilawar (1):
drm/i915/mtl: Disable MC6 for MTL A step
Daniel Vetter (3):
Merge tag 'drm-misc-fixes-2023-03-23' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Merge tag 'drm-intel-fixes-2023-03-2
gt; include/drm/display/drm_dp.h | 3 +
> include/drm/i915_hdcp_interface.h | 539 +
> include/drm/i915_mei_hdcp_interface.h | 184 -
> 58 files changed, 3322 insertions(+), 1467 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_sprite_uapi.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_sprite_uapi.h
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
> create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
> create mode 100644 include/drm/i915_hdcp_interface.h
> delete mode 100644 include/drm/i915_mei_hdcp_interface.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
s/gpu/drm/lima/lima_gem.c| 12 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 1 +
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 11 +-
> drivers/gpu/drm/tests/drm_format_helper_test.c | 141 ++---
> drivers/gpu/drm/tiny/bochs.c | 1 -
> drivers/gpu/drm/ttm/ttm_bo.c | 3 +-
> drivers/gpu/drm/vgem/vgem_drv.h| 11 -
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 1 -
> include/drm/drm_drv.h | 2 -
> include/drm/drm_fb_helper.h| 14 +-
> include/drm/drm_mode_config.h | 7 -
> 44 files changed, 664 insertions(+), 799 deletions(-)
> create mode 100644 drivers/gpu/drm/gma500/fbdev.c
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, 24 Mar 2023 at 11:38, Thierry Reding wrote:
>
> On Fri, Mar 24, 2023 at 10:59:23AM +0100, Daniel Vetter wrote:
> > On Fri, 24 Mar 2023 at 10:46, Daniel Vetter wrote:
> > >
> > > On Wed, Mar 08, 2023 at 05:28:06PM +, Jon Hunter wrote:
> > >
On Fri, 24 Mar 2023 at 10:46, Daniel Vetter wrote:
>
> On Wed, Mar 08, 2023 at 05:28:06PM +, Jon Hunter wrote:
> >
> >
> > On 08/03/2023 16:56, Nathan Chancellor wrote:
> > > Ping? This warning is now in 6.3-rc1.
> >
> > Thierry is away at t
9 +
> drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 14
> drivers/gpu/drm/amd/amdgpu/nv.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/vi.c| 17 +
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> drivers/gpu/d
; > progress but mainline is now broken because this change got separated
> > > from the change it is fixing:
> > >
> > > https://github.com/ClangBuiltLinux/continuous-integration2/actions/runs/4249931209/jobs/7391912774
> > > https://storage.tuxsuite.com/public/clangbuiltlinux/continuous-integration2/builds/2M7y9HpiXB13qiC2mkHMyeZOcLW/build.log
> > >
> > > I see this change sitting in the drm-tegra tree [1], which is getting
> > > merged into -next, so it is fixed there, which is why we did not notice
> > > any issues until the drm-next tree was merged into mainline. Can this be
> > > fast tracked to Linus to unbreak clang builds with -Werror?
> > >
> > > [1]:
> > > https://gitlab.freedesktop.org/drm/tegra/-/commit/b9930311641cf2ed905a84aabe27e8f3868aee4a
>
> --
> nvpublic
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
idia.com/
>
> If that does not come to you through other means before -rc4, could you
> just apply it directly so that I can stop applying it to our CI? :)
I'll include it in the next drm-fixes pull.
-Daniel
>
> Cheers,
> Nathan
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/intel_guc_rc.c | 13 +
> drivers/gpu/drm/i915/i915_active.c | 3 +--
> drivers/gpu/drm/i915/i915_hwmon.c | 5 -
> drivers/gpu/drm/i915/i915_reg.h| 17 +---
> 13 files changed, 88 insertions(+), 72 deletions(-)
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rfectly fine, but I'm using it
> as a very real example of how "Closes:" ends up being very naturally
> to mis-use).
>
> End result: I don't hate our current "Closes:" uses. But I'm very wary of it.
>
> I'm not at all convinced that it really adds a lot o
t;>>>> + continue;
> > >>>>> + }
> > >>>>> + if (!sched->ops->can_run_job(sched_job))
> > >>>>> + continue;
> > >>>>> + }
> > >>>>> +
> > >>>>> sched_job = drm_sched_entity_pop_job(entity);
> > >>>>>
> > >>>>> if (!sched_job) {
> > >>>>> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> > >>>>> index 9db9e5e504ee..bd89ea9507b9 100644
> > >>>>> --- a/include/drm/gpu_scheduler.h
> > >>>>> +++ b/include/drm/gpu_scheduler.h
> > >>>>> @@ -396,6 +396,14 @@ struct drm_sched_backend_ops {
> > >>>>> struct dma_fence *(*prepare_job)(struct drm_sched_job
> > >>>>> *sched_job,
> > >>>>> struct drm_sched_entity
> > >>>>> *s_entity);
> > >>>>>
> > >>>>> + /**
> > >>>>> + * @can_run_job: Called before job execution to check whether
> > >>>>> the
> > >>>>> + * hardware is free enough to run the job. This can be used to
> > >>>>> + * implement more complex hardware resource policies than the
> > >>>>> + * hw_submission limit.
> > >>>>> + */
> > >>>>> + bool (*can_run_job)(struct drm_sched_job *sched_job);
> > >>>>> +
> > >>>>> /**
> > >>>>> * @run_job: Called to execute the job once all of the
> > >>>>> dependencies
> > >>>>> * have been resolved. This may be called multiple
> > >>>>> times, if
> > >>>>>
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 2 Mar 2023 at 00:00, Rodrigo Vivi wrote:
> On Fri, Feb 17, 2023 at 09:51:37PM +0100, Daniel Vetter wrote:
> > Hi all,
> >
> > [I thought I've sent this out earlier this week, but alas got stuck, kinda
> > bad timing now since I'm out next week but oh wel
0 +249,12 @@ int virtio_gpu_init(struct virtio_device *vdev, struct
> drm_device *dev)
> virtio_gpu_get_capsets(vgdev, num_capsets);
> if (vgdev->has_edid)
> virtio_gpu_cmd_get_edids(vgdev);
> - virtio_gpu_cmd_get_display_info(vgdev);
> - virtio_gpu_notify(vgdev);
> - wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending,
> -5 * HZ);
> + if (IS_ENABLED(CONFIG_DRM_VIRTIO_GPU_KMS)) {
> + virtio_gpu_cmd_get_display_info(vgdev);
> + virtio_gpu_notify(vgdev);
> + wait_event_timeout(vgdev->resp_wq, !vgdev->display_info_pending,
> +5 * HZ);
> + }
> return 0;
>
> err_scanouts:
> --
> 2.39.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
include/drm/drm_suballoc.h | 112 ++
> include/drm/gpu_scheduler.h | 41 ++-
> sound/hda/hdac_i915.c | 17 +-
> sound/pci/hda/hda_intel.c | 56 +--
> sound/soc/intel/avs/core.c| 13 +-
> sound/soc/sof/intel/hda.c | 7 +-
> 98 files changed, 2076 insertions(+), 1325 deletions(-)
> create mode 100644 drivers/gpu/drm/drm_pt_walk.c
> create mode 100644 drivers/gpu/drm/drm_suballoc.c
> create mode 100644 include/drm/drm_pt_walk.h
> create mode 100644 include/drm/drm_suballoc.h
>
> --
> 2.37.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Feb 17, 2023 at 04:22:04PM +, Simon Ser wrote:
> v2: mention caps, note that the IOCTLs might fail, document that
> user-space needs a data structure to keep track of the
> handles (Daniel V.)
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalane
On Fri, Feb 17, 2023 at 09:18:54AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 16.02.23 um 21:11 schrieb Daniel Vetter:
> > On Thu, Feb 16, 2023 at 03:06:20PM +0100, Thomas Zimmermann wrote:
> > > Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
> >
lly butchered, and CI complained
about lockdep splats. So limit the critical section again and just add
a few notes what the proper fix is.
References:
https://intel-gfx-ci.01.org/tree/linux-next/next-20201215/fi-byt-j1900/igt@i915_pm_...@module-reload.html
Signed-off-by: Daniel Vetter
Cc: Vi
t one who argued this is a good thing to have.
kernfs/kobj/sysfs people spend endless amounts of engineer on trying to
build something that's impossible to get wrong, or at least get as close
to that as feasible.
I mean the entire rust endeavour flies under that flag too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Feb 17, 2023 at 11:01:18AM +0100, Stanislaw Gruszka wrote:
> On Fri, Feb 17, 2023 at 10:22:25AM +0100, Christian König wrote:
> > Am 16.02.23 um 20:54 schrieb Daniel Vetter:
> > > On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
> > > > On Thu
On Fri, 17 Feb 2023 at 13:06, Christian König
wrote:
>
> Am 16.02.23 um 15:34 schrieb Daniel Vetter:
> > On Thu, Jan 26, 2023 at 03:30:31PM +0100, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 26.01.23 um 11:28 schrieb Christian König:
> >>> We
On Thu, Feb 16, 2023 at 09:37:51PM +0100, Sam Ravnborg wrote:
> On Thu, Feb 16, 2023 at 01:49:23PM +0100, Daniel Vetter wrote:
> > On Thu, 16 Feb 2023 at 13:47, Neil Armstrong
> > wrote:
> > >
> > > On 16/02/2023 13:32, Daniel Vetter wrote:
> > > >
On Thu, Feb 16, 2023 at 11:43:38PM +0300, Dmitry Osipenko wrote:
> On 2/16/23 15:15, Daniel Vetter wrote:
> > On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote:
> >> On 1/27/23 11:13, Gerd Hoffmann wrote:
> >>> On Thu, Jan 26, 2023 at 01:55:09A
drivers/gpu/drm/drm_pt_walk.c
> create mode 100644 include/drm/drm_pt_walk.h
>
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_helper_unprepare()")
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
>
> Signed-off-by: Thomas Zimmermann
This reminds me of a
On Thu, Feb 16, 2023 at 05:31:50PM +0100, Christian König wrote:
>
>
> Am 16.02.23 um 12:34 schrieb Daniel Vetter:
> > On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote:
> > > Am 09.02.23 um 14:06 schrieb Maíra Canal:
> > > > On 2/9/23 09:13,
On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2023, Stanislaw Gruszka
> wrote:
> > On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> >> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> >> > T
On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2023, Christian König wrote:
> > Am 16.02.23 um 17:46 schrieb Jani Nikula:
> >> On Thu, 16 Feb 2023, Christian König wrote:
> >>> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
> >&g
;
> [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> ---
> include/uapi/drm/drm.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a
On Thu, Feb 16, 2023 at 01:09:41PM +, Simon Ser wrote:
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> Cc: Daniel Stone
> ---
> include/uapi/drm/drm.h | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/include/ua
lding references to the GEM object to prevent its destruction.
> > +*/
> > + drm_mode_destroy_dumb(client->dev, handle, client->file);
> > +
> > if (ret) {
> > drm_client_buffer_delete(buffer);
> > return ERR_PTR(ret);
> > diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
> > index 39482527a775..b5acdab73766 100644
> > --- a/include/drm/drm_client.h
> > +++ b/include/drm/drm_client.h
> > @@ -134,11 +134,6 @@ struct drm_client_buffer {
> > */
> > struct drm_client_dev *client;
> > - /**
> > -* @handle: Buffer handle
> > -*/
> > - u32 handle;
> > -
> > /**
> > * @pitch: Buffer pitch
> > */
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 16 Feb 2023 at 13:47, Neil Armstrong wrote:
>
> On 16/02/2023 13:32, Daniel Vetter wrote:
> > On Thu, 16 Feb 2023 at 12:59, Konrad Dybcio
> > wrote:
> >>
> >>
> >>
> >> On 19.01.2023 17:32, Konrad Dybcio wrote:
> >>> Fr
positor supposed to do transition animation
> > from an old FB to its own thing? I guess mmap + glTexImage2D equivalent
> > to make a copy of the old FB so one can use it as a texture?
>
> I think the compositor can export the handle as DMA-BUF, then close the
> handle imm
err_probe(dev, ret, "Failed to get regulators\n");
> > +
> > + ctx->panel_reset_gpio = devm_gpiod_get(dev, "panel-reset",
> > GPIOD_ASIS);
> > + if (IS_ERR(ctx->panel_reset_gpio))
> > + return dev_err_probe(dev, PTR_ERR(ctx->panel_reset_gpio),
> > + "Failed to get panel-reset-gpios\n");
> > +
> > + ctx->touch_reset_gpio = devm_gpiod_get(dev, "touch-reset",
> > GPIOD_ASIS);
> > + if (IS_ERR(ctx->touch_reset_gpio))
> > + return dev_err_probe(dev, PTR_ERR(ctx->touch_reset_gpio),
> > + "Failed to get touch-reset-gpios\n");
> > +
> > + ctx->dsi = dsi;
> > + mipi_dsi_set_drvdata(dsi, ctx);
> > +
> > + dsi->lanes = 4;
> > + dsi->format = MIPI_DSI_FMT_RGB888;
> > + dsi->mode_flags = MIPI_DSI_CLOCK_NON_CONTINUOUS;
> > +
> > + drm_panel_init(>panel, dev, _td4353_jdi_panel_funcs,
> > +DRM_MODE_CONNECTOR_DSI);
> > +
> > + ret = drm_panel_of_backlight(>panel);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "Failed to get backlight\n");
> > +
> > + drm_panel_add(>panel);
> > +
> > + ret = mipi_dsi_attach(dsi);
> > + if (ret < 0) {
> > + dev_err(dev, "Failed to attach to DSI host: %d\n", ret);
> > + drm_panel_remove(>panel);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void sony_td4353_jdi_remove(struct mipi_dsi_device *dsi)
> > +{
> > + struct sony_td4353_jdi *ctx = mipi_dsi_get_drvdata(dsi);
> > + int ret;
> > +
> > + ret = mipi_dsi_detach(dsi);
> > + if (ret < 0)
> > + dev_err(>dev, "Failed to detach from DSI host: %d\n",
> > ret);
> > +
> > + drm_panel_remove(>panel);
> > +}
> > +
> > +static const struct of_device_id sony_td4353_jdi_of_match[] = {
> > + { .compatible = "sony,td4353-jdi-tama", .data = (void
> > *)TYPE_TAMA_60HZ },
> > + { /* sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, sony_td4353_jdi_of_match);
> > +
> > +static struct mipi_dsi_driver sony_td4353_jdi_driver = {
> > + .probe = sony_td4353_jdi_probe,
> > + .remove = sony_td4353_jdi_remove,
> > + .driver = {
> > + .name = "panel-sony-td4353-jdi",
> > + .of_match_table = sony_td4353_jdi_of_match,
> > + },
> > +};
> > +module_mipi_dsi_driver(sony_td4353_jdi_driver);
> > +
> > +MODULE_AUTHOR("Konrad Dybcio ");
> > +MODULE_DESCRIPTION("DRM panel driver for SONY Xperia XZ2/XZ2c JDI panel");
> > +MODULE_LICENSE("GPL");
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
that it should be a problem for drivers and not for DRM core.
>
> I was going to re-send the [1], but other things were getting priority.
> It's good that you reminded me about it :) I may re-send it sometime
> soon if there are no new objections.
>
> [1] https://patchwork.freedesktop.org/patch/487481/
>
> [2]
> https://lore.kernel.org/all/20220701090240.1896131-1-dmitry.osipe...@collabora.com/
Hm I still don't like allowing this in general, because in general it just
doesn't work.
I think more like a per-driver opt-in or something might be needed, so
that drivers which "know" that it's ok to just mmap without coherency can
allow that. Allowing this in general essentially gives up on the entire
idea of dma-buf cache flushing completely.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
DRM core changes. I expect he'll ack them.
>
> Thank you for reviewing the virtio patches!
I think best-case would be an ack from msm people that this looks good
(even better a conversion for msm to start using this).
Otherwise I think the locking looks reasonable, I think the tricky bits
ha
On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > The mutex was completely pointless in the first place since any
> > parallel adding of files to this list would result in random
> > be
; for vc4 and vkms.
> > >
> > > Thanks for the feedback and yes that's exactly what I meant with
> > > that I haven't looked into all code paths.
> > >
> > > Could it be that v3d registers it's debugfs files from the
> > > debugfs_init callback?
> >
> > Although this is true, I'm not sure if this is the reason why the files
> > are
> > being registered twice, as this doesn't happen to vc4, and it also uses
> > the
> > debugfs_init callback. I believe it is somewhat related to the fact that
> > v3d is the primary node and the render node.
>
> I see. Thanks for the hint.
>
> >
> > Best Regards,
> > - Maíra Canal
> >
> > >
> > > One alternative would be to just completely nuke support for
> > > separate render node debugfs files and only add a symlink to the
> > > primary node. Opinions?
>
> What do you think of this approach? I can't come up with any reason why we
> should have separate debugfs files for render nodes and I think it is pretty
> much the same reason you came up with the patch for per device debugfs files
> instead of per minor.
Yeah I think best is to symlink around a bit for compat. I thought we
where doing that already, and you can't actually create debugfs files on
render nodes? Or did I only dream about this?
-Daniel
>
> Regards,
> Christian.
>
> > >
> > > Regards,
> > > Christian.
> > >
> > > >
> > > > Otherwise, the patchset looks good to me, but maybe Daniel has
> > > > some other
> > > > thoughts about it.
> > > >
> > > > Best Regards,
> > > > - Maíra Canal
> > > >
> > > > >
> > > > > Please comment/discuss.
> > > > >
> > > > > Cheers,
> > > > > Christian.
> > > > >
> > > > >
> > >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
; @@ -311,21 +311,6 @@ struct drm_device {
>*/
> struct drm_fb_helper *fb_helper;
>
> - /**
> - * @debugfs_mutex:
> - *
> - * Protects _list access.
> - */
> - struct mutex debugfs_mutex;
> -
> - /**
> - * @debugfs_list:
> - *
> - * List of debugfs files to be created by the DRM device. The files
> - * must be added during drm_dev_register().
> - */
> - struct list_head debugfs_list;
> -
> /* Everything below here is for legacy driver, never use! */
> /* private: */
> #if IS_ENABLED(CONFIG_DRM_LEGACY)
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
intel_breadcrumbs.c | 22
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 -
> drivers/gpu/drm/i915/i915_active.c | 2 +-
> drivers/gpu/drm/i915/i915_active.h | 2 +-
> drivers/gpu/drm/i915/i915_request.c | 13 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
501 - 600 of 23162 matches
Mail list logo
