fd)
> version.name = name;
>
> ret = ioctl(fd, DRM_IOCTL_VERSION, &version);
> - if (ret)
> + if (ret || version.name_len != 4)
> return 0;
>
> + name[4] = '\0';
> +
> return !strcmp(name, "vgem");
> }
>
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
or (q = 0; q < V3D_MAX_QUEUES; q++) {
> - drm_sched_start(&v3d->queue[q].sched);
> + drm_sched_start(&v3d->queue[q].sched, 0);
> }
>
> mutex_unlock(&v3d->reset_lock);
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index fe8edb917360..a8d19b10f9b8 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -579,7 +579,7 @@ bool drm_sched_wqueue_ready(struct drm_gpu_scheduler
> *sched);
> void drm_sched_wqueue_stop(struct drm_gpu_scheduler *sched);
> void drm_sched_wqueue_start(struct drm_gpu_scheduler *sched);
> void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job
> *bad);
> -void drm_sched_start(struct drm_gpu_scheduler *sched);
> +void drm_sched_start(struct drm_gpu_scheduler *sched, int errno);
> void drm_sched_resubmit_jobs(struct drm_gpu_scheduler *sched);
> void drm_sched_increase_karma(struct drm_sched_job *bad);
> void drm_sched_reset_karma(struct drm_sched_job *bad);
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
u_dm_atomic_commit_tail(struct
> drm_atomic_state *state)
>drm_atomic_crtc_needs_modeset(new_crtc_state))) {
> dc_stream_retain(dm_new_crtc_state->stream);
> acrtc->dm_irq_params.stream = dm_new_crtc_state->strea
like drm_crtc_vblank_on(), but it allows drivers to specify the
> vblank CRTC configuration before enabling vblanking support for a given
> CRTC.
>
> Signed-off-by: Hamza Mahfooz
Yeah looks reasonable, bunch of details below. With those addressed:
Acked-by: Danie
On Thu, Jul 25, 2024 at 03:35:18PM -0400, Lyude Paul wrote:
> On Tue, 2024-07-16 at 11:25 +0200, Daniel Vetter wrote:
> > On Mon, Jul 15, 2024 at 02:05:49PM -0300, Daniel Almeida wrote:
> > > Hi Sima!
> > >
> > >
> > > >
> > > > Y
drm_gem_shmem_free,
> + struct drm_gem_shmem_object *);
>
> /*
> * Test creating a shmem GEM object backed by shmem buffer. The test
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 23, 2024 at 02:17:48PM +0200, Christian König wrote:
> This reverts commit 24dc64c1ba5c3ef0463d59fef6df09336754188d.
>
> Shouldn't be needed by drivers any more.
>
> Signed-off-by: Christian König
> Reviewed-by: Matthew Brost
On the last 3 patches:
Rev
th of which are refcounted, so we're good.
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Christian König
> Cc: Zack Rusin
> Cc: Broadcom internal kernel review list
>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 5 +++--
> 1 file changed, 3
es->guest_memory_bo = vmw_user_bo_ref(byte_code);
> + res->guest_memory_bo = vmw_bo_reference(byte_code);
> res->guest_memory_offset = offset;
> }
> shader->size = size;
> @@ -809,7 +809,7 @@ static int vmw_shader_define(struct drm_device *dev,
> struct drm_file *file_priv,
> shader_type, num_input_sig,
> num_output_sig, tfile, shader_handle);
> out_bad_arg:
> - vmw_user_bo_unref(&buffer);
> + vmw_bo_unreference(&buffer);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> index e7a744dfcecf..c275bb074a60 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
> @@ -1505,7 +1505,7 @@ vmw_gb_surface_define_internal(struct drm_device *dev,
> if (ret == 0) {
> if (res->guest_memory_bo->tbo.base.size <
> res->guest_memory_size) {
> VMW_DEBUG_USER("Surface backup buffer too
> small.\n");
> - vmw_user_bo_unref(&res->guest_memory_bo);
> + vmw_bo_unreference(&res->guest_memory_bo);
> ret = -EINVAL;
> goto out_unlock;
> } else {
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 23, 2024 at 02:17:45PM +0200, Christian König wrote:
> Instead of a TTM reference grab a GEM reference whenever necessary.
>
> Signed-off-by: Christian König
> Cc: Sui Jingfeng
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/loongson/lsdc_ttm.c | 8 ++--
On Tue, Jul 23, 2024 at 02:17:44PM +0200, Christian König wrote:
> Instead of a TTM reference grab a GEM reference whenever necessary.
>
> Signed-off-by: Christian König
> Cc: Alex Deucher
> Cc: amd-...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
> ---
> d
he refcounting for the mmu_interval_notifier
that this patch does could result in a use-after-free, but the mmu
notifier code already does the required amount of mmgrab/mmdrop, so we're
good.
Reviewed-by: Daniel Vetter
Cheers, Sima
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> https://lore.kernel.org/oe-kbuild-all/202407210203.2isiic9m-...@intel.com/
> Signed-off-by: Jocelyn Falempe
Yeah it's not great but gets the job done.
Reviewed-by: Daniel Vetter
Cheers, Sima
> ---
> drivers/video/fbdev/core/fbcon.c | 9 +
> 1 file changed, 9 ins
On Thu, Jul 18, 2024 at 11:30:05AM +0200, Jocelyn Falempe wrote:
>
>
> On 18/07/2024 09:04, Jocelyn Falempe wrote:
> >
> >
> > On 17/07/2024 17:08, Daniel Vetter wrote:
> > > On Wed, Jul 17, 2024 at 10:48:39AM +0200, Jocelyn Falempe wrote:
> > > &g
On Tue, Jul 16, 2024 at 02:07:20PM +0200, Christian König wrote:
> Am 16.07.24 um 11:31 schrieb Daniel Vetter:
> > On Tue, Jul 16, 2024 at 10:48:40AM +0800, Huan Yang wrote:
> > > I just research the udmabuf, Please correct me if I'm wrong.
> > >
> > &
On Tue, Jul 16, 2024 at 06:14:48PM +0800, Huan Yang wrote:
>
> 在 2024/7/16 17:31, Daniel Vetter 写道:
> > [你通常不会收到来自 daniel.vet...@ffwll.ch 的电子邮件。请访问
> > https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
> >
> > On Tue, Jul 16, 2024 at 10:48:40AM +0800,
ld work, I did check the history of fbcon_is_active and
we've used that to force/disable panic output for fbcon in the past. So I
think it's the right tool.
> Reviewed-by: Javier Martinez Canillas
Reviewed-by: Daniel Vetter
Cheers, Sima
>
> --
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
git a/include/drm/drm_panic.h b/include/drm/drm_panic.h
> index 73bb3f3d9ed9..c3a358dc3e27 100644
> --- a/include/drm/drm_panic.h
> +++ b/include/drm/drm_panic.h
> @@ -148,11 +148,13 @@ struct drm_scanout_buffer {
>
> #ifdef CONFIG_DRM_PANIC
>
> +bool drm_panic_is_enabled(struct
return info;
>
> err_release:
Bit a bikeshed, but I'd split this patch out since it's for drm's fbdev
emulation, not the fbcon core code. With that:
Reviewed-by: Daniel Vetter
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 3
> besides status */
> u64 epoch_counter;
>
> + u32 prioritized_connectors;
> +
> /**
>* @possible_encoders: Bit mask of encoders that can drive this
>* connector, drm_encoder_index() determines the index into the bitfield
> diff --git a/include/drm/drm_probe_helper.h b/include/drm/drm_probe_helper.h
> index d6ce7b218b77..05e23485550d 100644
> --- a/include/drm/drm_probe_helper.h
> +++ b/include/drm/drm_probe_helper.h
> @@ -17,6 +17,8 @@ int drm_helper_probe_detect(struct drm_connector *connector,
> struct drm_modeset_acquire_ctx *ctx,
> bool force);
>
> +void drm_probe_helper_prioritize_connectors(struct drm_device *dev, u32
> connector_mask);
> +
> int drmm_kms_helper_poll_init(struct drm_device *dev);
> void drm_kms_helper_poll_init(struct drm_device *dev);
> void drm_kms_helper_poll_fini(struct drm_device *dev);
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
the
fix looks correct, and isn't just papering over noise.
> If the errors are really just noise (form the specific platforms), and this
> patch is covering
> for that, then:
>
> Reviewed-by: Michael J. Ruhl
Acked-by: Daniel Vetter
Cheers, Sima
>
> Thanks,
>
>
On Tue, Jul 16, 2024 at 10:48:40AM +0800, Huan Yang wrote:
> I just research the udmabuf, Please correct me if I'm wrong.
>
> 在 2024/7/15 20:32, Christian König 写道:
> > Am 15.07.24 um 11:11 schrieb Daniel Vetter:
> > > On Thu, Jul 11, 2024 at 11:00:02AM +0200, Chri
ually you need to do the big jump and switch
over the main driver/device to rust, but you can start out with little
pieces here&there. And that existing driver rust code should not need any
change when you do the big switch.
And on the safety side we also don't make any compromises, pure rust
drivers still can use all the type constraints that make sense to enforce
api rules. And mixed drivers wont accidentally call into rust code that
doesn't cope with the mixed world.
Mixed drivers still rely on "trust me, these types match" internally, but
there's really nothing we can do about that. Unless you do a full
conversion, in which case the rust abstractions provide that guarantee.
And with the Deref it also should not make the pure rust driver
abstraction more verbose or have any other impact on them.
Entirely untested, so might be complete nonsense :-)
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 10, 2024 at 02:40:04PM +0200, Christian König wrote:
> Am 10.07.24 um 13:58 schrieb Daniel Vetter:
> > On Wed, 10 Jul 2024 at 13:39, Christian König
> > wrote:
> > > Am 10.07.24 um 11:31 schrieb Daniel Vetter:
> > > > We already teac
gt; @@ -25,6 +30,11 @@ struct dma_heap_ops {
> > unsigned long len,
> > u32 fd_flags,
> > u64 heap_flags);
> > +
> > + struct dma_buf *(*allocate_read_file)(struct dma_heap *heap,
> > + struct dma_heap_file *heap_file,
> > + u32 fd_flags,
> > + u64 heap_flags);
> > };
> > /**
> > @@ -65,4 +75,49 @@ const char *dma_heap_get_name(struct dma_heap *heap);
> >*/
> > struct dma_heap *dma_heap_add(const struct dma_heap_export_info
> > *exp_info);
> > +/**
> > + * dma_heap_destroy_file_read - waits for a file read to complete then
> > destroy it
> > + * Returns: true if the file read failed, false otherwise
> > + */
> > +bool dma_heap_destroy_file_read(struct dma_heap_file_task *heap_ftask);
> > +
> > +/**
> > + * dma_heap_wait_for_file_read - waits for a file read to complete
> > + * Returns: true if the file read failed, false otherwise
> > + */
> > +bool dma_heap_wait_for_file_read(struct dma_heap_file_task *heap_ftask);
> > +
> > +/**
> > + * dma_heap_alloc_file_read - Declare a task to read file when allocate
> > pages.
> > + * @heap_file: target file to read
> > + *
> > + * Return NULL if failed, otherwise return a struct pointer.
> > + */
> > +struct dma_heap_file_task *
> > +dma_heap_declare_file_read(struct dma_heap_file *heap_file);
> > +
> > +/**
> > + * dma_heap_prepare_file_read - cache each allocated page until we meet
> > this batch.
> > + * @heap_ftask:prepared and need to commit's work.
> > + * @page: current allocated page. don't care which order.
> > + *
> > + * Returns true if reach to batch, false so go on prepare.
> > + */
> > +bool dma_heap_prepare_file_read(struct dma_heap_file_task *heap_ftask,
> > + struct page *page);
> > +
> > +/**
> > + * dma_heap_commit_file_read - prepare collect enough memory, going to
> > trigger IO
> > + * @heap_ftask:info that current IO needs
> > + *
> > + * This commit will also check if reach to tail read.
> > + * For direct I/O submissions, it is necessary to pay attention to file
> > reads
> > + * that are not page-aligned. For the unaligned portion of the read,
> > buffer IO
> > + * needs to be triggered.
> > + * Returns:
> > + * 0 if all right, -errno if something wrong
> > + */
> > +int dma_heap_submit_file_read(struct dma_heap_file_task *heap_ftask);
> > +size_t dma_heap_file_size(struct dma_heap_file *heap_file);
> > +
> > #endif /* _DMA_HEAPS_H */
> > diff --git a/include/uapi/linux/dma-heap.h b/include/uapi/linux/dma-heap.h
> > index a4cf716a49fa..8c20e8b74eed 100644
> > --- a/include/uapi/linux/dma-heap.h
> > +++ b/include/uapi/linux/dma-heap.h
> > @@ -39,6 +39,27 @@ struct dma_heap_allocation_data {
> > __u64 heap_flags;
> > };
> > +/**
> > + * struct dma_heap_allocation_file_data - metadata passed from userspace
> > for
> > + * allocations and read file
> > + * @fd:will be populated with a fd which provides the
> > + * handle to the allocated dma-buf
> > + * @file_fd: file descriptor to read from(suggested to use
> > O_DIRECT open file)
> > + * @batch: how many memory alloced then file read(bytes), default
> > 128MB
> > + * will auto aligned to PAGE_SIZE
> > + * @fd_flags: file descriptor flags used when allocating
> > + * @heap_flags:flags passed to heap
> > + *
> > + * Provided by userspace as an argument to the ioctl
> > + */
> > +struct dma_heap_allocation_file_data {
> > + __u32 fd;
> > + __u32 file_fd;
> > + __u32 batch;
> > + __u32 fd_flags;
> > + __u64 heap_flags;
> > +};
> > +
> > #define DMA_HEAP_IOC_MAGIC'H'
> > /**
> > @@ -50,4 +71,15 @@ struct dma_heap_allocation_data {
> > #define DMA_HEAP_IOCTL_ALLOC _IOWR(DMA_HEAP_IOC_MAGIC, 0x0,\
> > struct dma_heap_allocation_data)
> > +/**
> > + * DOC: DMA_HEAP_IOCTL_ALLOC_AND_READ - allocate memory from pool and both
> > + * read file when allocate memory.
> > + *
> > + * Takes a dma_heap_allocation_file_data struct and returns it with the fd
> > field
> > + * populated with the dmabuf handle of the allocation. When return, the
> > dma-buf
> > + * content is read from file.
> > + */
> > +#define DMA_HEAP_IOCTL_ALLOC_AND_READ \
> > + _IOWR(DMA_HEAP_IOC_MAGIC, 0x1, struct dma_heap_allocation_file_data)
> > +
> > #endif /* _UAPI_LINUX_DMABUF_POOL_H */
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ate) const GPU_COHERENCY_FEATURES: GpuRegister = GpuRegister(0x300);
> > +pub(crate) const GPU_COHERENCY_PROTOCOL: GpuRegister = GpuRegister(0x304);
> > +pub(crate) const GPU_COHERENCY_ACE: GpuRegister = GpuRegister(0);
> > +pub(crate) const GPU_COHERENCY_ACE_LITE: GpuRegister = GpuRegister(1);
> > +pub(crate) const GPU_COHERENCY_NONE: GpuRegister = GpuRegister(31);
> > +pub(crate) const MCU_CONTROL: GpuRegister = GpuRegister(0x700);
> > +pub(crate) const MCU_CONTROL_ENABLE: GpuRegister = GpuRegister(1);
> > +pub(crate) const MCU_CONTROL_AUTO: GpuRegister = GpuRegister(2);
> > +pub(crate) const MCU_CONTROL_DISABLE: GpuRegister = GpuRegister(0);
> > +pub(crate) const MCU_STATUS: GpuRegister = GpuRegister(0x704);
> > +pub(crate) const MCU_STATUS_DISABLED: GpuRegister = GpuRegister(0);
> > +pub(crate) const MCU_STATUS_ENABLED: GpuRegister = GpuRegister(1);
> > +pub(crate) const MCU_STATUS_HALT: GpuRegister = GpuRegister(2);
> > +pub(crate) const MCU_STATUS_FATAL: GpuRegister = GpuRegister(3);
> > +pub(crate) const JOB_INT_RAWSTAT: GpuRegister = GpuRegister(0x1000);
> > +pub(crate) const JOB_INT_CLEAR: GpuRegister = GpuRegister(0x1004);
> > +pub(crate) const JOB_INT_MASK: GpuRegister = GpuRegister(0x1008);
> > +pub(crate) const JOB_INT_STAT: GpuRegister = GpuRegister(0x100c);
> > +pub(crate) const JOB_INT_GLOBAL_IF: GpuRegister = GpuRegister(bit(31));
> > +pub(crate) const fn job_int_csg_if(x: u64) -> GpuRegister {
> > +GpuRegister(bit(x))
> > +}
> > +pub(crate) const MMU_INT_RAWSTAT: GpuRegister = GpuRegister(0x2000);
> > +pub(crate) const MMU_INT_CLEAR: GpuRegister = GpuRegister(0x2004);
> > +pub(crate) const MMU_INT_MASK: GpuRegister = GpuRegister(0x2008);
> > +pub(crate) const MMU_INT_STAT: GpuRegister = GpuRegister(0x200c);
> > +pub(crate) const MMU_BASE: GpuRegister = GpuRegister(0x2400);
> > +pub(crate) const MMU_AS_SHIFT: GpuRegister = GpuRegister(6);
> > +const fn mmu_as(as_: u64) -> u64 {
> > +MMU_BASE.0 + ((as_) << MMU_AS_SHIFT.0)
> > +}
> > +pub(crate) const fn as_transtab_lo(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x0)
> > +}
> > +pub(crate) const fn as_transtab_hi(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x4)
> > +}
> > +pub(crate) const fn as_memattr_lo(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x8)
> > +}
> > +pub(crate) const fn as_memattr_hi(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0xC)
> > +}
> > +pub(crate) const fn as_memattr_aarch64_inner_alloc_expl(w: u64, r: u64) ->
> > GpuRegister {
> > +GpuRegister((3 << 2) | (if w > 0 { bit(0) } else { 0 } | (if r > 0 {
> > bit(1) } else { 0 })))
> > +}
> > +pub(crate) const fn as_lockaddr_lo(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x10)
> > +}
> > +pub(crate) const fn as_lockaddr_hi(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x14)
> > +}
> > +pub(crate) const fn as_command(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x18)
> > +}
> > +pub(crate) const AS_COMMAND_NOP: GpuRegister = GpuRegister(0);
> > +pub(crate) const AS_COMMAND_UPDATE: GpuRegister = GpuRegister(1);
> > +pub(crate) const AS_COMMAND_LOCK: GpuRegister = GpuRegister(2);
> > +pub(crate) const AS_COMMAND_UNLOCK: GpuRegister = GpuRegister(3);
> > +pub(crate) const AS_COMMAND_FLUSH_PT: GpuRegister = GpuRegister(4);
> > +pub(crate) const AS_COMMAND_FLUSH_MEM: GpuRegister = GpuRegister(5);
> > +pub(crate) const fn as_faultstatus(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x1C)
> > +}
> > +pub(crate) const fn as_faultaddress_lo(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x20)
> > +}
> > +pub(crate) const fn as_faultaddress_hi(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x24)
> > +}
> > +pub(crate) const fn as_status(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x28)
> > +}
> > +pub(crate) const AS_STATUS_AS_ACTIVE: GpuRegister = GpuRegister(bit(0));
> > +pub(crate) const fn as_transcfg_lo(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x30)
> > +}
> > +pub(crate) const fn as_transcfg_hi(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x34)
> > +}
> > +pub(crate) const fn as_transcfg_ina_bits(x: u64) -> GpuRegister {
> > +GpuRegister((x) << 6)
> > +}
> > +pub(crate) const fn as_transcfg_outa_bits(x: u64) -> GpuRegister {
> > +GpuRegister((x) << 14)
> > +}
> > +pub(crate) const AS_TRANSCFG_SL_CONCAT: GpuRegister = GpuRegister(bit(22));
> > +pub(crate) const AS_TRANSCFG_PTW_RA: GpuRegister = GpuRegister(bit(30));
> > +pub(crate) const AS_TRANSCFG_DISABLE_HIER_AP: GpuRegister =
> > GpuRegister(bit(33));
> > +pub(crate) const AS_TRANSCFG_DISABLE_AF_FAULT: GpuRegister =
> > GpuRegister(bit(34));
> > +pub(crate) const AS_TRANSCFG_WXN: GpuRegister = GpuRegister(bit(35));
> > +pub(crate) const AS_TRANSCFG_XREADABLE: GpuRegister = GpuRegister(bit(36));
> > +pub(crate) const fn as_faultextra_lo(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x38)
> > +}
> > +pub(crate) const fn as_faultextra_hi(as_: u64) -> GpuRegister {
> > +GpuRegister(mmu_as(as_) + 0x3C)
> > +}
> > +pub(crate) const CSF_GPU_LATEST_FLUSH_ID: GpuRegister =
> > GpuRegister(0x1);
> > +pub(crate) const fn csf_doorbell(i: u64) -> GpuRegister {
> > +GpuRegister(0x8 + ((i) * 0x1))
> > +}
> > +pub(crate) const CSF_GLB_DOORBELL_ID: GpuRegister = GpuRegister(0);
> > diff --git a/rust/bindings/bindings_helper.h
> > b/rust/bindings/bindings_helper.h
> > index b245db8d5a87..4ee4b97e7930 100644
> > --- a/rust/bindings/bindings_helper.h
> > +++ b/rust/bindings/bindings_helper.h
> > @@ -12,15 +12,18 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
So might be worth it to re-audit this all.
I think all other dma-buf exporters/allocators do only create VM_SPECIAL
vmas.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 10, 2024 at 04:19:53PM +0206, John Ogness wrote:
> On 2024-07-10, Daniel Vetter wrote:
> > console_lock is the outermost subsystem lock for a lot of subsystems,
> > which means get/put_user must nest within. Which means it cannot be
> > acquired somewhere deeply
.bin" },
> > };
> >
> > +/* Production fw_names from the table above */
> > +MODULE_FIRMWARE("intel/vpu/vpu_37xx_v0.0.bin");
> > +MODULE_FIRMWARE("intel/vpu/vpu_40xx_v0.0.bin");
> > +
> > static int ivpu_fw_request(struct ivpu_device *vdev)
> > {
> > int ret = -ENOENT;
> >
> > ---
> > base-commit: 22a40d14b572deb80c0648557f4bd502d7e83826
> > change-id: 20240704-fix-ivpu-firmware-metadata-3d02bd60768d
> >
> > Best regards,
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jul 10, 2024 at 05:13:18PM -0400, Hamza Mahfooz wrote:
> On 7/10/24 04:43, Daniel Vetter wrote:
> > On Tue, Jul 09, 2024 at 10:02:08AM -0400, Hamza Mahfooz wrote:
> > > On 7/9/24 06:09, Daniel Vetter wrote:
> > > > On Tue, Jul 09, 2024 at 11:32:11AM +0200, Dan
xt so I can remove it from my tracking spreadsheet :)
> >
> > I still don't see this in linux-next.
> > Adding Greg KH since he's picked up many of these fixes.
> > Hope to have all of these warnings fixed tree-wide in 6.11.
>
> Reviewed-by: Jeffrey Hugo
>
> Dave, this seems like a trivial fix that is stuck, but normally routed
> through DRM. I hope I'm not over stepping, but I think I'll drop this in
> drm-misc-next on the 19th if there isn't any other activity.
Committers applying patches is very much welcome and encouraged.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
61cd0d...@google.com/
Signed-off-by: Daniel Vetter
Fixes: a8f354284304 ("bcachefs: bch2_print_string_as_lines()")
Cc: # v6.7+
Cc: Kent Overstreet
Cc: Brian Foster
Cc: linux-bcach...@vger.kernel.org
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: John Ogness
Cc: Sergey Senozhatsky
Signed-off-
On Wed, 10 Jul 2024 at 13:39, Christian König wrote:
>
> Am 10.07.24 um 11:31 schrieb Daniel Vetter:
> > We already teach lockdep that dma_resv nests within drm_modeset_lock,
> > but there's a lot more: All drm kms ioctl rely on being able to
> > put/get_user while
best we can do here.
Including printk folks since even trylock feels realyl iffy here to
me.
Reported-by: syzbot+6cebc1af246fe020a...@syzkaller.appspotmail.com
References:
https://lore.kernel.org/dri-devel/26c1ff061cd0d...@google.com/
Signed-off-by: Daniel Vetter
Fixes: a8f354284304
devel/73db8b061cd43...@google.com/
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/gpu/drm/drm_mode_config.c | 2 ++
1
; __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893
> __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline]
> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48
> el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:131
> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:150
> el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712
> el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73
> 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7f7141231048 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 7f7140503f60 RCX: 7f7140375bd9
> RDX: 22c0 RSI: c02064b9 RDI: 0003
> RBP: 7f71403e4aa1 R08: R09:
> R10: R11: 0246 R12:
> R13: 000b R14: 7f7140503f60 R15: 7ffdba322618
>
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
>
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
>
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
>
> If you want to undo deduplication, reply with:
> #syz undup
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 09, 2024 at 10:02:08AM -0400, Hamza Mahfooz wrote:
> On 7/9/24 06:09, Daniel Vetter wrote:
> > On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
> > > On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> > > > Hook up drm_crtc_set_
| 3 -
> > drivers/gpu/drm/i915/display/intel_fb_pin.c| 39 +++--
> > drivers/gpu/drm/i915/display/intel_fb_pin.h| 3 +-
> > drivers/gpu/drm/i915/display/intel_fbdev.c | 5 +-
> > drivers/gpu/drm/i915/display/intel_psr.c | 166
> > +
> > drivers/gpu/drm/i915/display/intel_sprite.c| 26
> > drivers/gpu/drm/i915/display/intel_vblank.c| 10 ++
> > drivers/gpu/drm/i915/display/intel_vblank.h| 1 +
> > drivers/gpu/drm/i915/display/intel_vrr.c | 2 +-
> > drivers/gpu/drm/i915/display/skl_universal_plane.c | 85 ++-
> > drivers/gpu/drm/i915/i915_driver.c | 51 +--
> > drivers/gpu/drm/i915/i915_reg.h| 80 +-
> > drivers/gpu/drm/xe/display/xe_display.c| 18 +--
> > drivers/gpu/drm/xe/display/xe_fb_pin.c | 3 +-
> > drivers/gpu/drm/xe/display/xe_plane_initial.c | 4 +-
> > include/drm/drm_plane.h| 2 +
> > include/drm/drm_vblank_work.h | 2 +
> > 48 files changed, 873 insertions(+), 391 deletions(-)
> >
> > --
> > Jani Nikula, Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jul 09, 2024 at 11:32:11AM +0200, Daniel Vetter wrote:
> On Mon, Jul 08, 2024 at 04:29:07PM -0400, Hamza Mahfooz wrote:
> > Hook up drm_crtc_set_vblank_offdelay() in amdgpu_dm, so that we can
> > enable PSR more quickly for displays that support it.
> >
> > S
_state))) {
> dc_stream_retain(dm_new_crtc_state->stream);
> acrtc->dm_irq_params.stream = dm_new_crtc_state->stream;
> - manage_dm_interrupts(adev, acrtc, true);
> + manage_dm_interrupts(adev, acrtc,
> +
t; + /**
> + * @offdelay_ms: Vblank off delay in ms, used to determine how long
> + * @disable_timer waits before disabling.
> + */
> + int offdelay_ms;
> +
> /**
>* @hwmode:
>*
> @@ -255,6 +261,7 @@ void drm_calc_timestamping_constants(struct drm_crtc
> *crtc,
> wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc *crtc);
> void drm_crtc_set_max_vblank_count(struct drm_crtc *crtc,
> u32 max_vblank_count);
> +void drm_crtc_set_vblank_offdelay(struct drm_crtc *crtc, int offdelay);
>
> /*
> * Helpers for struct drm_crtc_funcs
> --
> 2.45.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
places where we
want the vmap only for the duration of the dma_resv locked section, so
really can't do that. And your patch removes the unlocked vmap
implementation, which would be the only place really.
Reviewed-by: Daniel Vetter
>
> Best regards
> Thomas
>
> Am 02.07.24
On Fri, Jul 05, 2024 at 12:31:36PM -0700, Rob Clark wrote:
> On Fri, Jul 5, 2024 at 3:36 AM Daniel Vetter wrote:
> >
> > On Thu, Jul 04, 2024 at 08:40:26AM -0700, Rob Clark wrote:
> > > On Thu, Jul 4, 2024 at 7:08 AM Daniel Vetter
> > > wrote:
> > > &g
On Sat, 6 Jul 2024 at 18:36, Alex Deucher wrote:
>
> On Fri, Jul 5, 2024 at 7:15 AM Daniel Vetter wrote:
> >
> > On Wed, Jul 03, 2024 at 02:47:23PM -0400, Alex Deucher wrote:
> > > Hi Dave, Sima,
> > >
> > > Fixes for 6.10.
&
03:08:46PM GMT, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Fri, Jun 28, 2024 at 01:29:17PM GMT, Thierry Reding wrote:
> > > > > On Tue, May 21, 2024 at 02:06:19PM GMT, Daniel Vetter wrote:
> > > > > > On Thu, May 16, 2024
; CmaTotal: 131072 kB
> CmaFree:5644 kB
>
> So my question: is this noticable CMA increase expected by this change?
>
No, it shouldn't change anything. All it does is change the type we use to
iterate over objects from the subclass to the base class in the co
DML1 mode support
Boris Brezillon (2):
drm/panthor: Don't check the array stride on empty uobj arrays
drm/panthor: Fix sync-only jobs
Daniel Vetter (4):
Merge tag 'drm-intel-fixes-2024-07-02' of
https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes
Mer
On Fri, Jul 05, 2024 at 01:33:38PM +0200, Krzysztof Kozlowski wrote:
> On 05/07/2024 13:22, Maxime Ripard wrote:
> > On Fri, Jul 05, 2024 at 01:19:50PM GMT, Daniel Vetter wrote:
> >> On Fri, Jul 05, 2024 at 12:03:56PM +0200, Krzysztof Kozlowski wrote:
> >>> Patches t
Maintained
> +S: Odd Fixes
> T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
> F: Documentation/devicetree/bindings/display/st,stih4xx.txt
> F: drivers/gpu/drm/sti
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+-
> .../amd/display/dc/dml/dcn32/display_mode_vba_32.c | 3 ++
> .../amd/display/dc/dml2/dml2_translation_helper.c | 1 +
> drivers/gpu/drm/amd/display/dc/dml2/dml2_utils.c | 2 +-
> drivers/gpu/drm/amd/include/atomfirmware.h | 2 +-
> drivers/gpu/drm/radeon/radeon_gem.c| 2 +-
> 6 files changed, 59 insertions(+), 4 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 23 +
> include/linux/soc/qcom/smem.h |1 +
> include/linux/soc/qcom/socinfo.h | 34 +
> include/uapi/drm/msm_drm.h |1 +
> 71 files changed, 4011 insertions(+), 2470 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm7150-dpu.yaml
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,sm7150-mdss.yaml
> create mode 100644 drivers/gpu/drm/msm/adreno/a2xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a3xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a4xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a5xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> create mode 100644 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_2_sm7150.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 1226
>
> drivers/gpu/drm/tests/drm_cmdline_parser_test.c| 11 +
> drivers/gpu/drm/tests/drm_connector_test.c |1 +
> drivers/gpu/drm/tests/drm_modes_test.c | 31 +
> include/drm/display/drm_dsc_helper.h |3 +
> include/drm/drm_fixed.h| 23 +
> 26 files changed, 2605 insertions(+), 560 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/st,stm32mp25-lvds.yaml
> create mode 100644 drivers/gpu/drm/stm/lvds.c
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 04, 2024 at 08:40:26AM -0700, Rob Clark wrote:
> On Thu, Jul 4, 2024 at 7:08 AM Daniel Vetter wrote:
> >
> > On Tue, Jul 02, 2024 at 05:32:39AM -0700, Rob Clark wrote:
> > > On Fri, Jun 28, 2024 at 10:44 AM Daniel Vetter wrote:
> > > >
> > &g
gt; drm/i915/gem: Suppress oom warning in favour of ENOMEM to userspace
>
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 8 +--
> drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 1 +
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4
> drivers/gpu
%)
> rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn10/dcn10_stream_encoder.h
> (100%)
> rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_link_encoder.c
> (100%)
> rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_link_encoder.h
> (100%)
> rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_stream_encoder.c
> (100%)
> rename drivers/gpu/drm/amd/display/dc/{ => dio}/dcn20/dcn20_stream_encoder.h
> (100%)
> rename drivers/gpu/drm/amd/display/dc/{ =>
> dio}/dcn30/dcn30_dio_link_encoder.c (100%)
> rename drivers/gpu/drm/amd/display/dc/{ =>
> dio}/dcn30/dcn30_dio_link_encoder.h (100%)
> rename drivers/gpu/drm/amd/display/dc/{ =>
> dio}/dcn30/dcn30_dio_stream_encoder.c (100%)
> rename drivers/gpu/drm/amd/display/dc/{ =>
> dio}/dcn30/dcn30_dio_stream_encoder.h (100%)
> rename drivers/gpu/drm/amd/display/dc/{ =>
> dio}/dcn31/dcn31_dio_link_encoder.c (100%)
> rename drivers/gpu/drm/amd/display/dc/{ =>
> dio}/dcn31/dcn31_dio_link_encoder.h (100%)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 2 +
> drivers/gpu/drm/amd/display/include/dpcd_defs.h | 5 +
> .../drm/amd/display/modules/hdcp/hdcp1_execution.c | 24 +-
> .../gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c| 12 +-
> .../gpu/drm/amd/display/modules/hdcp/hdcp_psp.c| 3 -
> drivers/gpu/drm/amd/include/amd_shared.h | 2 +
> .../amd/include/asic_reg/dcn/dcn_4_1_0_offset.h| 18 ++
> .../amd/include/asic_reg/dcn/dcn_4_1_0_sh_mask.h | 110
> .../drm/amd/include/ivsrcid/isp/irqsrcs_isp_4_1.h | 62 +
> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 3 +-
> .../gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_2_ppt.c | 30 +--
> 138 files changed, 2467 insertions(+), 749 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_isp.h
> create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_0.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_0.h
> create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_1.c
> create mode 100644 drivers/gpu/drm/amd/amdgpu/isp_v4_1_1.h
> create mode 100644 drivers/gpu/drm/amd/include/ivsrcid/isp/irqsrcs_isp_4_1.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+-
> drivers/gpu/drm/mediatek/mtk_ethdr.c | 46 ---
> drivers/gpu/drm/mediatek/mtk_hdmi.c| 42 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc.c| 21 ++--
> drivers/gpu/drm/mediatek/mtk_mdp_rdma.c| 18 ++-
> drivers/gpu/drm/mediatek/mtk_padding.c | 25 ++--
> drivers/gpu/drm/mediatek/mtk_plane.c | 4 +-
> 31 files changed, 373 insertions(+), 280 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 8
> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 9 ++---
> drivers/gpu/drm/etnaviv/state.xml.h | 103
> ++----
> drivers/gpu/drm/etnaviv/state_blt.xml.h | 22 +--
> drivers/gpu/drm/etnaviv/state_hi.xml.h | 30 +--
> 10 files changed, 238 insertions(+), 92 deletions(-)
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
vers/gpu/drm/exynos/exynos_drm_vidi.c | 83
> ++--
> drivers/gpu/drm/exynos/exynos_hdmi.c | 7 ++-
> 3 files changed, 42 insertions(+), 49 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
oa.c | 2 +
> drivers/gpu/drm/xe/xe_pci.c | 4 --
> drivers/gpu/drm/xe/xe_pci_sriov.c | 13 +
> drivers/gpu/drm/xe/xe_pci_sriov.h | 7 +++
> drivers/gpu/drm/xe/xe_rtp.c | 2 +-
> drivers/gpu/drm/xe/xe_wa_oob.rules | 1 +
> 24 files changed, 290 insertions(+), 121 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
d.c | 44
> +++---
> drivers/gpu/drm/ttm/ttm_bo.c | 1 +
> include/uapi/drm/panthor_drm.h | 5 +++
> 8 files changed, 63 insertions(+), 20 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
r handling in xe_migrate_update_pgtables
>
> drivers/gpu/drm/xe/xe_gt_mcr.c | 6 +++---
> drivers/gpu/drm/xe/xe_migrate.c | 8
> 2 files changed, 7 insertions(+), 7 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index fb97b51b38f15..dd5caa8030aa3 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -3017,7 +3017,7 @@ int drm_atomic_helper_swap_state(struct
> drm_atomic_st
m/i915 fixes for v6.10-rc7:
> - Skip unnecessary MG programming, avoiding warnings (Imre)
>
>
> Imre Deak (1):
> drm/i915/display: For MTL+ platforms skip mg dp programming
>
> drivers/gpu/drm/i915/display/int
On Tue, Jul 02, 2024 at 05:32:39AM -0700, Rob Clark wrote:
> On Fri, Jun 28, 2024 at 10:44 AM Daniel Vetter wrote:
> >
> > On Thu, Jun 27, 2024 at 11:51:37AM -0700, Rob Clark wrote:
> > > On Wed, Jun 26, 2024 at 10:47 AM Daniel Vetter wrote:
> > > >
> &
> > [22982.117174] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > [22982.117176] RIP: 0033:0x7f943d267169
> > [22982.117192] Code: Unable to access opcode bytes at 0x7f943d26713f.
> > [22982.117193] RSP: 002b:7f9430bffc80 EFLAGS: 0246 ORIG_RAX:
> > 00ca
inux-next like logic to use older branches until the conflicts
> get fixed.
Yeah if the gitlab side just pushes without rebuilding drm-tip this isn't
going to work well and we'll need to go back. I was thinking that we
should be able to run dim rebuild-tip from gitlab CI flows, at least for
the cases where everything builds. If you need to fix things up you still
need to do a local run.
Even better would be if this runs pre-merge so that the MR fails to land
if there's new conflicts, but that's a bit more tricky.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jun 27, 2024 at 02:18:44PM +0200, Thomas Hellström wrote:
> On Thu, 2024-06-27 at 10:04 +0200, Daniel Vetter wrote:
> > On Wed, Jun 26, 2024 at 05:58:02PM +0200, Thomas Hellström wrote:
> > > Hi!
> > >
> > > I'm seeing the below lockdep splat 1
On Thu, Jun 27, 2024 at 09:18:15AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 26.06.24 um 19:59 schrieb Daniel Vetter:
> > On Wed, Jun 26, 2024 at 11:01:11AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 26.06.24 um 06:34 schrieb Dmitry Barysh
pd, the screen
goes black (or encrypted garbage) when trying to display encrypted/secure
buffers.
> > Or is there any info inside the DMA-buf for this? In other words would you
> > also need to know if a buffer is then allocated from this special carveout?
>
> I don't think so. It's possible to scan out an unprotected buffer with
> HDCP enabled. It may also be possible to scan out a protected buffer
> even if HDCP wasn't enabled, though you would obviously want to prevent
> that somehow. Not sure if there's a common way to do this, but I guess
> in end-user devices you'd need a fully trusted boot chain to do that in
> a compliant way.
Where I know how it works it's hardware making that guarantee.
> It's been a long time since I looked at this, but I seem to recall that
> at the time all software that could do DRM-protected playback on Linux
> was proprietary for reasons like these.
Yeah it's still not much better unfortunately :-/
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jun 26, 2024 at 08:26:04PM +0100, Daniel Stone wrote:
> On Wed, 26 Jun 2024 at 18:52, Daniel Vetter wrote:
> > On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> > > On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> > > > So we are kind of stuc
On Thu, Jun 27, 2024 at 11:51:37AM -0700, Rob Clark wrote:
> On Wed, Jun 26, 2024 at 10:47 AM Daniel Vetter wrote:
> >
> > On Wed, Jun 26, 2024 at 11:38:30AM +0300, Dmitry Baryshkov wrote:
> > > On Wed, Jun 26, 2024 at 09:32:44AM GMT, Daniel Vetter wrote:
> > >
6 ORIG_RAX:
> 000000ca
> [ 99.137354] RAX: fe00 RBX: RCX:
> 7fda70ee6169
> [ 99.137356] RDX: RSI: 0189 RDI:
> 564a96f45b30
> [ 99.137358] RBP: 7fda5fdffcb0 R08: R09:
>
> [ 99.137359] R10: R11: 0246 R12:
>
> [ 99.137360] R13: R14: R15:
> 564a96f45b30
> [ 99.137365]
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jun 27, 2024 at 02:54:57AM +0530, Akhil P Oommen wrote:
> On Wed, Jun 26, 2024 at 09:59:39AM +0200, Daniel Vetter wrote:
> > On Tue, Jun 25, 2024 at 08:54:41PM +0200, Konrad Dybcio wrote:
> > > Memory barriers help ensure instruction ordering, NOT time and order
>
On Wed, Jun 26, 2024 at 07:59:52PM +0200, Daniel Vetter wrote:
> On Wed, Jun 26, 2024 at 11:01:11AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 26.06.24 um 06:34 schrieb Dmitry Baryshkov:
> > > On Tue, Jun 25, 2024 at 03:18:09PM GMT, Thomas Zimmerma
an-up order if the encoder was added dynamically. The
> hardware for ast is entirely static and ast uses drmm_mode_config_init() for
> auto-cleaning up the modesetting pipeline. Using drmm_encoder_init() seems
> like a bit of wasted resources for no gain.
The idea of drmm_ is that you use them all. That the managed version of
drm_mode_config_init also happens to still work with the unmanaged
encoder/connector/crtc/plane cleanup is just to facilitate gradual
conversions.
And see my other reply, for drmm_encoder_init supporting the NULL funcs
case actually makes full sense.
Also, any driver can be hotunbound through sysfs, no hotunplug of the hw
needed at all.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
obably need something like this, as much
as it sucks. I see it somewhat similar to handling pcip2pdma limitations
in the kernel too.
Not sure where/how it should be handled though, and maybe I've missed
something around protocols, in which case I guess we should add some
secure buffer flags to the ADDFB2 ioctl.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rm driver uapi name, I think that's what
mesa filters?) for anything new (including the NN-only ones).
I would still try to avoid that, but just in case someone screams about
regressions.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jun 26, 2024 at 11:42:24AM +0300, Dmitry Baryshkov wrote:
> On Wed, Jun 26, 2024 at 09:26:40AM GMT, Daniel Vetter wrote:
> > On Thu, May 09, 2024 at 05:41:18PM +0300, Oded Gabbay wrote:
> > > On Thu, May 09, 2024 at 03:53:01PM +0200, Tomeu Vizoso wrote:
On Wed, Jun 26, 2024 at 11:38:30AM +0300, Dmitry Baryshkov wrote:
> On Wed, Jun 26, 2024 at 09:32:44AM GMT, Daniel Vetter wrote:
> > On Mon, Jun 24, 2024 at 10:25:25AM -0300, Helen Koike wrote:
> > >
> > >
> > > On 24/06/2024 02:34, Vignesh Raman wrote:
>
uot;how much userspace do you want" up to netdev folks too. But the dma_buf
side looks fine, so for that:
Acked-by: Daniel Vetter
Cheers, Sima
>
> ---
>
> v13:
> - Fixed a couple of places that still listed DMA_BIDIRECTIONAL (Pavel).
> - Added reviewed-by from Pavel.
27;s make extra sure that the GPU can access the memory.. */
> - mb();
> + gpu_read(gpu, REG_A6XX_RBBM_GBIF_HALT);
> }
>
> /* Some GPUs are stubborn and take their sweet time to unhalt GBIF! */
>
> --
> 2.45.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
worth the dependency.
For drmm_encoder_init/alloc this is doable, because it makes sure that
there really is only one correct encoder cleanup hook for simple encoders.
Without drmm_ there's the entire "who calls kfree() and how buggy is it"
mess :-/
So I'd very much welcome this kind of handling in drmm_encoder_alloc/init,
but in the unmanaged drm_encoder_init I agree it sounds like a mistake.
Cheers,
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> > > - if (ret < 0)
> > > > > - goto out;
> > > > > +
> > > > > + /* Some ioctl can opt-out of powermanagement handling
> > > > > + * if they don't require the device to be resumed.
> > > > > + */
> > > > > + switch (cmd) {
> > > > > + default:
> > > > > + needs_device = true;
> > > > > + }
> > > > > +
> > > > > + if (needs_device) {
> > > > > + ret = pm_runtime_get_sync(dev->dev);
> > > > > + if (ret < 0)
> > > > > + goto out;
> > > > > + }
> > > > > ret = drm_ioctl(filp, cmd, arg);
> > > > > - pm_runtime_mark_last_busy(dev->dev);
> > > > > out:
> > > > > - pm_runtime_put_autosuspend(dev->dev);
> > > > > + if (needs_device) {
> > > > > + pm_runtime_mark_last_busy(dev->dev);
> > > > > + pm_runtime_put_autosuspend(dev->dev);
> > > > > + }
> > > > > +
> > > > > return ret;
> > > > > }
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
(!hdmi->bridge_is_on)
> >>>> -dw_hdmi_poweron(hdmi);
> >>>> -}
> >>>>}
> >>>>
> >>>>/*
> >>>> @@ -2546,7 +2519,6 @@ static void dw_hdmi_connector_force(struct
> >>>
ry pick only this commit to fix this issue.
> > So it would be beneficial to have a drm-ci-next branch.
> >
> > Regards,
> > Vignesh
>
>
> I don't mind using a drm-ci-next branch if it is created.
What exactly is the issue in backmerging drm-misc-next (well through
drm-next really)?
Also if there is an issue, generally we do ad-hoc topic branches.
I'm very very skeptical of boutique trees with tiny focus, we've had that
before drm-misc, it's a mess. Definitely no enthusiasm for getting back
to that kind of world.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
>
> > > So from that PoV I don't think it's really that harmful. The only
> > > complication is in Mesa, where it would see an etnaviv/amdgpu/...
> > > render node and potentially try to use it as a device. As long as Mesa
> > > can correctly skip, there should be no userspace API implications.
> > >
> > > That being said, I'm not entirely sure what the _benefit_ would be of
> > > exposing a render node for a device which can't be used by any
> > > 'traditional' DRM consumers, i.e. GL/Vulkan/winsys.
> >
> > What I don't understand yet from Lucas proposal is how this isn't
> > going to break existing userspace.
> >
> > I mean, even if we find a good way of having userspace skip
> > non-rendering render nodes, what about existing userspace that isn't
> > able to do that? Any updates to newer kernels are going to break them.
> >
> > Regards,
> >
> > Tomeu
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
uxiliary bus we could in theory solve the code
> > > organization problem mentioned above, I'm not quite seeing how to do
> > > this in a clean way. The driver in /drivers/gpu/drm would have to be a
> > > DRM driver that doesn't register a DRM device, but registers a device
> > > in the auxiliary bus for the driver in /drivers/accel to bind to? Or
> > > are you seeing some possibility that would fit better in the current
> > > DRM framework?
> > >
> > > > I think this is the first case we've had of a combo DRM/Accel usecase,
> > > > and so there isn't an existing example to refer you to on how to
> > > > structure things. I think you are going to be the first example where
> > > > we figure all of this out.
> > >
> > > Yep, I will be grateful for any ideas on how to structure this.
> > >
> > > > On a more implementation note, ioctls for Accel devices should not be
> > > > marked DRM_RENDER_ALLOW. Seems like your attempt to reuse as much of
> > > > the code as possible trips over this.
> > >
> > > Indeed, thanks.
> > >
> > > Cheers,
> > >
> > > Tomeu
> > >
> > > > -Jeff
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
lable.
I think for drivers which do cpu upload and are vblank driven there's
maybe a case for kernel implemented cursors due to latency reduction if
the blending happens as late as possible. But udl just goes right ahead
and uploads, so this doesn't help I think. damage tracking should, but w
e, vdev.dev_set_list);
>
> diff --git a/drivers/vfio/pci/vfio_pci_priv.h
> b/drivers/vfio/pci/vfio_pci_priv.h
> index 5e4fa69aee16..09d3c300918c 100644
> --- a/drivers/vfio/pci/vfio_pci_priv.h
> +++ b/drivers/vfio/pci/vfio_pci_priv.h
> @@ -101,4 +101,27 @@ static inline bool vfio_pci_is_vga(struct pci_dev *pdev)
> return (pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA;
> }
>
> +#ifdef CONFIG_DMA_SHARED_BUFFER
> +int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32
> flags,
> + struct vfio_device_feature_dma_buf __user
> *arg,
> + size_t argsz);
> +void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device *vdev);
> +void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked);
> +#else
> +static int
> +vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
> + struct vfio_device_feature_dma_buf __user *arg,
> + size_t argsz)
> +{
> + return -ENOTTY;
> +}
> +static inline void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device
> *vdev)
> +{
> +}
> +static inline void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev,
> + bool revoked)
> +{
> +}
> +#endif
> +
> #endif
> diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
> index f87067438ed4..3756e0904de2 100644
> --- a/include/linux/vfio_pci_core.h
> +++ b/include/linux/vfio_pci_core.h
> @@ -94,6 +94,7 @@ struct vfio_pci_core_device {
> struct vfio_pci_core_device *sriov_pf_core_dev;
> struct notifier_block nb;
> struct rw_semaphore memory_lock;
> + struct list_headdmabufs;
> };
>
> /* Will be exported for vfio pci drivers usage */
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 2b68e6cdf190..6f283dadacb7 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -1458,6 +1458,31 @@ struct vfio_device_feature_bus_master {
> };
> #define VFIO_DEVICE_FEATURE_BUS_MASTER 10
>
> +/**
> + * Upon VFIO_DEVICE_FEATURE_GET create a dma_buf fd for the
> + * regions selected.
> + *
> + * open_flags are the typical flags passed to open(2), eg O_RDWR, O_CLOEXEC,
> + * etc. offset/length specify a slice of the region to create the dmabuf
> from.
> + * nr_ranges is the total number of (P2P DMA) ranges that comprise the
> dmabuf.
> + *
> + * Return: The fd number on success, -1 and errno is set on failure.
> + */
> +#define VFIO_DEVICE_FEATURE_DMA_BUF 11
> +
> +struct vfio_region_dma_range {
> + __u32 region_index;
> + __u32 __pad;
> + __u64 offset;
> + __u64 length;
> +};
> +
> +struct vfio_device_feature_dma_buf {
> + __u32 open_flags;
> + __u32 nr_ranges;
> + struct vfio_region_dma_range dma_ranges[];
> +};
> +
> /* API for Type1 VFIO IOMMU */
>
> /**
> --
> 2.45.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Sun, Jun 23, 2024 at 03:19:17PM -0500, Bjorn Andersson wrote:
> On Fri, Jun 21, 2024 at 05:52:32PM GMT, Daniel Vetter wrote:
> > On Fri, Jun 21, 2024 at 09:40:09AM -0600, Jeffrey Hugo wrote:
> > > On 6/21/2024 5:19 AM, Dmitry Baryshkov wrote:
> > > > On Fr
On Fri, Jun 21, 2024 at 10:48:27PM +0300, Dmitry Baryshkov wrote:
> On Fri, 21 Jun 2024 at 18:52, Daniel Vetter wrote:
> >
> > On Fri, Jun 21, 2024 at 09:40:09AM -0600, Jeffrey Hugo wrote:
> > > On 6/21/2024 5:19 AM, Dmitry Baryshkov wrote:
> > > > On Fri, 2
return PTR_ERR(output->panel);
> }
>
> - output->edid = of_get_property(output->of_node, "nvidia,edid", &size);
> -
I think you can/should also delete tegra_output.edid completely, since not
doing that freaked me out a bit until I
or_add_modes(connector);
>
> DRM_DEBUG_KMS("%s : %dx%d cm\n",
> - (connector->display_info.is_hdmi ? "hdmi monitor" : "dvi
> monitor"),
> - edid->width_cm, edid->height_cm);
> + info
>
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Andy Yan
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-rockc...@lists.infradead.org
Reviewed-by: Daniel Vetter
> ---
> d
On Tue, Jun 18, 2024 at 12:48:13PM +0300, Dmitry Baryshkov wrote:
> On Tue, 18 Jun 2024 at 12:33, Daniel Vetter wrote:
> >
> > On Mon, Jun 17, 2024 at 10:52:27PM +0300, Dmitry Baryshkov wrote:
> > > On Mon, Jun 17, 2024 at 11:28:35AM GMT, Abhinav Kumar wrote:
> >
-off-by: Yafang Shao
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel Vetter
I guess the entire series will go in through a dedicated pull or some
other tree, so
Acked-by: Daniel Vetter
for merging through whatever non-drm
.disable_locking field [0]).
>
> Since this regmap is not shared with other drivers and so any concurrent
> access should already be prevented by the DRM core locking scheme.
>
> Is my understanding correct?
Quick irc discussion summary: Since these are panels that sit on i2c/spi
buses
On Tue, Jun 18, 2024 at 07:10:58PM -0700, Abhinav Kumar wrote:
>
>
> On 6/18/2024 2:33 AM, Daniel Vetter wrote:
> > On Mon, Jun 17, 2024 at 10:52:27PM +0300, Dmitry Baryshkov wrote:
> > > On Mon, Jun 17, 2024 at 11:28:35AM GMT, Abhinav Kumar wrote:
> > > > H
101 - 200 of 3504 matches
Mail list logo
