ction of the documentation also.
>
> drivers/gpu/drm/drm_pci.c:1: warning: no structured comments found
>
> Fixes: 2504c7ec728b ("drm: Remove source code for non-KMS drivers")
> Signed-off-by: Randy Dunlap
> Cc: Thomas Zimmermann
> Cc: David Airlie
> Cc: Daniel
On Fri, Jan 12, 2024 at 10:41:14AM +0100, Daniel Vetter wrote:
> On Fri, Jan 12, 2024 at 05:20:11PM +0800, Yong Wu wrote:
> > Add the dma_ops for this restricted heap. For restricted buffer,
> > cache_ops/mmap are not allowed, thus return EPERM for them.
> >
>
= restricted_heap_free,
> +};
> +
> static struct dma_buf *
> restricted_heap_allocate(struct dma_heap *heap, unsigned long size,
>unsigned long fd_flags, unsigned long heap_flags)
> @@ -66,6 +168,7 @@ restricted_heap_allocate(struct dma_heap *heap, unsigned
> long size,
> if (ret)
> goto err_free_buf;
> exp_info.exp_name = dma_heap_get_name(heap);
> + exp_info.ops = &restricted_heap_buf_ops;
> exp_info.size = restricted_buf->size;
> exp_info.flags = fd_flags;
> exp_info.priv = restricted_buf;
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
TCURSOR ioctl"
- maybe there's a unique setup sequence that only the xorg driver uses?
Like a sequence of ioctl/ioctl parameters that's unique to the old xorg
driver.
It's still brittle, but since no one's working on the legacy driver
anymore you only need to chase
On Wed, Jan 10, 2024 at 06:54:53AM -0800, Rob Clark wrote:
> On Wed, Jan 10, 2024 at 2:50 AM Daniel Vetter wrote:
> >
> > On Tue, Jan 09, 2024 at 10:22:17AM -0800, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > This reverts commi
On Wed, 10 Jan 2024 at 13:53, Andri Yngvason wrote:
>
> mið., 10. jan. 2024 kl. 11:10 skrifaði Daniel Vetter :
> >
> > On Tue, Jan 09, 2024 at 06:11:00PM +, Andri Yngvason wrote:
> > > + /* Extract information from crtc to communicate it to userspace as
connector->max_bpc_property)
> drm_connector_attach_max_bpc_property(connector, 8, 16);
>
> + connector->active_color_format_property =
> master->base.active_color_format_property;
> + if (connector->active_color_format_property)
> +
> drm_connector_attach_active_color_format_property(&aconnector->base);
> +
> connector->vrr_capable_property = master->base.vrr_capable_property;
> if (connector->vrr_capable_property)
> drm_connector_attach_vrr_capable_property(connector);
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Jan 10, 2024 at 11:46:35AM +0100, Christian König wrote:
> Am 10.01.24 um 11:22 schrieb Daniel Vetter:
> > On Wed, Jan 10, 2024 at 11:19:37AM +0100, Christian König wrote:
> > > Am 10.01.24 um 10:56 schrieb Julia Zhang:
> > > >
drm_probe_helper.c
> index 3f479483d7d8..b9f07d5f999f 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -877,6 +877,9 @@ EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
> */
> void drm_kms_helper_poll_disable(struct drm_device *dev)
> {
> + if (!dev->mode_config.poll_enabled)
> + return;
> +
> if (dev->mode_config.poll_running)
> drm_kms_helper_disable_hpd(dev);
>
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ruct dma_fence *msm_job_run(struct drm_sched_job
> *job)
>
> mutex_unlock(&priv->lru.lock);
>
> + /* TODO move submit path over to using a per-ring lock.. */
> + mutex_lock(&gpu->lock);
> +
> msm_gpu_submit(gpu, submit);
>
> + mutex_unlock(&gpu->lock);
> +
> return dma_fence_get(submit->hw_fence);
> }
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> --- a/include/uapi/linux/virtio_gpu.h
> +++ b/include/uapi/linux/virtio_gpu.h
> @@ -65,6 +65,11 @@
> */
> #define VIRTIO_GPU_F_CONTEXT_INIT4
>
> +/*
> + * VIRTIO_GPU_CMD_RESOURCE_QUERY_LAYOUT
> + */
> +#define VIRTIO_GPU_F_RESOURCE_QUERY_LAYOUT 5
> +
> enum virtio_gpu_ctrl_type {
> VIRTIO_GPU_UNDEFINED = 0,
>
> @@ -95,6 +100,7 @@ enum virtio_gpu_ctrl_type {
> VIRTIO_GPU_CMD_SUBMIT_3D,
> VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB,
> VIRTIO_GPU_CMD_RESOURCE_UNMAP_BLOB,
> + VIRTIO_GPU_CMD_RESOURCE_QUERY_LAYOUT,
>
> /* cursor commands */
> VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
> @@ -108,6 +114,7 @@ enum virtio_gpu_ctrl_type {
> VIRTIO_GPU_RESP_OK_EDID,
> VIRTIO_GPU_RESP_OK_RESOURCE_UUID,
> VIRTIO_GPU_RESP_OK_MAP_INFO,
> + VIRTIO_GPU_RESP_OK_RESOURCE_LAYOUT,
>
> /* error responses */
> VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
> @@ -453,4 +460,27 @@ struct virtio_gpu_resource_unmap_blob {
> __le32 padding;
> };
>
> +/* VIRTIO_GPU_CMD_RESOURCE_QUERY_LAYOUT */
> +struct virtio_gpu_resource_query_layout {
> + struct virtio_gpu_ctrl_hdr hdr;
> + __le32 resource_id;
> + __le32 width;
> + __le32 height;
> + __le32 format;
> + __le32 bind;
> +};
> +
> +
> +/* VIRTIO_GPU_RESP_OK_RESOURCE_LAYOUT */
> +#define VIRTIO_GPU_RES_MAX_PLANES 4
> +struct virtio_gpu_resp_resource_layout {
> + struct virtio_gpu_ctrl_hdr hdr;
> + __le64 modifier;
> + __le32 num_planes;
> + struct virtio_gpu_resource_plane {
> + __le64 offset;
> + __le32 stride;
> + } planes[VIRTIO_GPU_RES_MAX_PLANES];
> +};
> +
> #endif
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ntee that the value is updated
right after the kms ioctl returns (and not somewhen later for non-blocking
commits).
You probably need a bit of work to be able to handle immutable properties
with the atomic state infrastructure, but I think otherwise this should
fit all rather neatly.
Cheers, Sima
&
On Wed, Jan 10, 2024 at 10:54:42AM +0100, Jacek Lawrynowicz wrote:
> On 09.01.2024 14:14, Daniel Vetter wrote:
> > On Tue, Jan 09, 2024 at 11:43:05AM +0100, Jacek Lawrynowicz wrote:
> >> `shmem->map_wc was` set to `false` but the comment suggested WC was
> >>
+
> > static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops = {
> > .ops = {
> > .cache_sgt_mapping = true,
> > @@ -83,7 +95,7 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops
> > = {
> > .vmap = drm_gem_dmabuf_vmap,
> > .vunmap = drm_gem_dmabuf_vunmap,
> > },
> > - .device_attach = drm_gem_map_attach,
> > + .device_attach = virtgpu_gem_device_attach,
> > .get_uuid = virtgpu_virtio_get_uuid,
> > };
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
83,7 +95,7 @@ static const struct virtio_dma_buf_ops virtgpu_dmabuf_ops =
> {
> .vmap = drm_gem_dmabuf_vmap,
> .vunmap = drm_gem_dmabuf_vunmap,
> },
> - .device_attach = drm_gem_map_attach,
> + .device_attach = virtgpu_gem_device_attach,
> .get_uuid = virtgpu_virtio_get_uuid,
> };
>
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, 9 Jan 2024 at 16:29, Randy Dunlap wrote:
>
>
>
> On 1/9/24 07:25, Daniel Vetter wrote:
> > On Tue, 9 Jan 2024 at 16:23, Randy Dunlap wrote:
> >>
> >>
> >>
> >> On 1/9/24 05:42, Daniel Vetter wrote:
> >>> On Tue, 9 Jan
On Tue, 9 Jan 2024 at 16:23, Randy Dunlap wrote:
>
>
>
> On 1/9/24 05:42, Daniel Vetter wrote:
> > On Tue, 9 Jan 2024 at 13:59, Daniel Vetter wrote:
> >>
> >> On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
> >>> Hi Thomas,
>
On Tue, 9 Jan 2024 at 14:25, Tvrtko Ursulin
wrote:
>
>
> On 09/01/2024 12:54, Daniel Vetter wrote:
> > On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:
> >>
> >> On 09/01/2024 07:56, Christian König wrote:
> >>> Am 07.12.23 um 19:02
since I didn't know it was possible.
Fix this asap by documenting the two possible kernel-doc flavours for
preprocessor definitions.
References:
https://lore.kernel.org/dri-devel/dd917333-9ae8-4e76-991d-39b6229ba...@infradead.org/
Cc: Randy Dunlap
Cc: Thomas Zimmermann
Cc: Maxime Ripa
On Tue, Jan 09, 2024 at 02:48:42PM +0100, Javier Martinez Canillas wrote:
> Daniel Vetter writes:
>
> Hello Sima,
>
> Thanks for your feedback.
>
> > On Tue, Jan 09, 2024 at 01:05:59PM +0100, Javier Martinez Canillas wrote:
> >> The device is initialized in t
.
> So, always do the synchronous cancel if not in reset. And add an extra
> synchronous cancel to the end of the reset flow to account for when a
> reset is occurring at driver shutdown and the cancel is no longer
> synchronous but could lead to unallocated memory accesses if the
&g
On Tue, 9 Jan 2024 at 13:59, Daniel Vetter wrote:
>
> On Mon, Jan 08, 2024 at 01:10:12PM -0800, Randy Dunlap wrote:
> > Hi Thomas,
> >
> > On 1/8/24 00:57, Thomas Zimmermann wrote:
> > > Hi,
> > >
> > > thanks for the fix.
> > >
> &
*/
> + if (err == -ENOENT)
> + err = -EPROBE_DEFER;
> +
> + dev_err_probe(drm_dev->dev, err, "failed to load firmware %s
> (err=%d)\n",
> + filename, err);
> +
> goto err_free_filename;
> }
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
the map_wc == true paths are even reachable anymore for private
objects ...
Cheers, Sima
> } else {
> ret = drm_gem_object_init(dev, obj, size);
> }
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Jan 09, 2024 at 12:06:58PM +0100, Paul Cercueil wrote:
> Hi Daniel / Sima,
>
> Le lundi 08 janvier 2024 à 20:19 +0100, Daniel Vetter a écrit :
> > On Mon, Jan 08, 2024 at 05:27:33PM +0100, Paul Cercueil wrote:
> > > Le lundi 08 janvier 2024 à 16:29 +010
nitial short description on
> >> line:
> >> * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
> >> drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs'
> >> description in 'drm_vram_mm'
> >>
> >> Signed-off-by: Randy Dunlap
> > break;
> > > }
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > index d28e21baef16..0503af75dc26 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> > > @@ -138,12 +138,18 @@ struct amdgpu_bo_vm {
> > > struct amdgpu_mem_stats {
> > > /* current VRAM usage, includes visible VRAM */
> > > uint64_t vram;
> > > + /* current shared VRAM usage, includes visible VRAM */
> > > + uint64_t vram_shared;
> > > /* current visible VRAM usage */
> > > uint64_t visible_vram;
> > > /* current GTT usage */
> > > uint64_t gtt;
> > > + /* current shared GTT usage */
> > > + uint64_t gtt_shared;
> > > /* current system memory usage */
> > > uint64_t cpu;
> > > + /* current shared system memory usage */
> > > + uint64_t cpu_shared;
> > > /* sum of evicted buffers, includes visible VRAM */
> > > uint64_t evicted_vram;
> > > /* sum of evicted buffers due to CPU access */
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
. :)
> >
> > acked-by : Inki Dae
>
> Who is going to pick this up? Who has access to the drm-misc tree?
Inki has, so I'm assuming since he acked he'll also merge.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jan 08, 2024 at 05:27:33PM +0100, Paul Cercueil wrote:
> Le lundi 08 janvier 2024 à 16:29 +0100, Daniel Vetter a écrit :
> > On Mon, Jan 08, 2024 at 03:21:21PM +0100, Paul Cercueil wrote:
> > > Hi Daniel (Sima?),
> > >
> > > Le lundi 08 janvier 2024
On Mon, Jan 08, 2024 at 03:21:21PM +0100, Paul Cercueil wrote:
> Hi Daniel (Sima?),
>
> Le lundi 08 janvier 2024 à 13:39 +0100, Daniel Vetter a écrit :
> > On Mon, Jan 08, 2024 at 01:00:55PM +0100, Paul Cercueil wrote:
> > > This patch introduces three new ioctls. T
asing noncoherent dma count, as what's done in VFIO, for
> >Intel GPU passthrough, for all guest memory.
>
> And where does all this fixup the coherency problem?
>
> > This page migration issue should not be the case for virtio GPU, as both
> > host
> > and gue
; + void (*detach_dmabuf)(struct iio_buffer *buffer,
> + struct iio_dma_buffer_block *block);
> + int (*enqueue_dmabuf)(struct iio_buffer *buffer,
> + struct iio_dma_buffer_block *block,
> + struct sg_table *sgt, size_t size, bool cyclic);
> +
> unsigned int modes;
> unsigned int flags;
> };
> @@ -136,6 +154,9 @@ struct iio_buffer {
>
> /* @ref: Reference count of the buffer. */
> struct kref ref;
> +
> + /* @dmabufs: List of DMABUF attachments */
> + struct list_head dmabufs;
> };
>
> /**
> @@ -156,9 +177,14 @@ int iio_update_buffers(struct iio_dev *indio_dev,
> **/
> void iio_buffer_init(struct iio_buffer *buffer);
>
> +void iio_buffer_dmabuf_get(struct dma_buf_attachment *attach);
> +void iio_buffer_dmabuf_put(struct dma_buf_attachment *attach);
> +
> struct iio_buffer *iio_buffer_get(struct iio_buffer *buffer);
> void iio_buffer_put(struct iio_buffer *buffer);
>
> +void iio_buffer_signal_dmabuf_done(struct dma_buf_attachment *attach, int
> ret);
> +
> #else /* CONFIG_IIO_BUFFER */
>
> static inline void iio_buffer_get(struct iio_buffer *buffer) {}
> diff --git a/include/uapi/linux/iio/buffer.h b/include/uapi/linux/iio/buffer.h
> index 13939032b3f6..c666aa95e532 100644
> --- a/include/uapi/linux/iio/buffer.h
> +++ b/include/uapi/linux/iio/buffer.h
> @@ -5,6 +5,28 @@
> #ifndef _UAPI_IIO_BUFFER_H_
> #define _UAPI_IIO_BUFFER_H_
>
> +#include
> +
> +/* Flags for iio_dmabuf.flags */
> +#define IIO_BUFFER_DMABUF_CYCLIC (1 << 0)
> +#define IIO_BUFFER_DMABUF_SUPPORTED_FLAGS0x0001
> +
> +/**
> + * struct iio_dmabuf - Descriptor for a single IIO DMABUF object
> + * @fd: file descriptor of the DMABUF object
> + * @flags: one or more IIO_BUFFER_DMABUF_* flags
> + * @bytes_used: number of bytes used in this DMABUF for the data
> transfer.
> + * Should generally be set to the DMABUF's size.
> + */
> +struct iio_dmabuf {
> + __u32 fd;
> + __u32 flags;
> + __u64 bytes_used;
> +};
> +
> #define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int)
> +#define IIO_BUFFER_DMABUF_ATTACH_IOCTL _IOW('i', 0x92, int)
> +#define IIO_BUFFER_DMABUF_DETACH_IOCTL _IOW('i', 0x93, int)
> +#define IIO_BUFFER_DMABUF_ENQUEUE_IOCTL _IOW('i', 0x94, struct
> iio_dmabuf)
>
> #endif /* _UAPI_IIO_BUFFER_H_ */
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
a5 100644
> --- a/drivers/gpu/drm/tve200/Kconfig
> +++ b/drivers/gpu/drm/tve200/Kconfig
> @@ -9,7 +9,6 @@ config DRM_TVE200
> select DRM_PANEL_BRIDGE
> select DRM_KMS_HELPER
> select DRM_GEM_DMA_HELPER
> - select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
&
> } __attribute__((packed));
>
> +/* Flags for usb_ffs_dmabuf_transfer_req->flags (none for now) */
> +#define USB_FFS_DMABUF_TRANSFER_MASK 0x0
> +
> +/**
> + * struct usb_ffs_dmabuf_transfer_req - Transfer request for a DMABUF object
> + * @fd: file descriptor of the DMABUF object
> + * @flags: one or more USB_FFS_DMABUF_TRANSFER_* flags
> + * @length: number of bytes used in this DMABUF for the data transfer.
> + * Should generally be set to the DMABUF's size.
> + */
> +struct usb_ffs_dmabuf_transfer_req {
> + int fd;
> + __u32 flags;
> + __u64 length;
> +} __attribute__((packed));
> +
> #ifndef __KERNEL__
>
> /*
> @@ -290,6 +306,31 @@ struct usb_functionfs_event {
> #define FUNCTIONFS_ENDPOINT_DESC_IOR('g', 130, \
>struct usb_endpoint_descriptor)
>
> +/*
> + * Attach the DMABUF object, identified by its file descriptor, to the
> + * data endpoint. Returns zero on success, and a negative errno value
> + * on error.
> + */
> +#define FUNCTIONFS_DMABUF_ATTACH _IOW('g', 131, int)
> +
>
> +/*
> + * Detach the given DMABUF object, identified by its file descriptor,
> + * from the data endpoint. Returns zero on success, and a negative
> + * errno value on error. Note that closing the endpoint's file
> + * descriptor will automatically detach all attached DMABUFs.
> + */
> +#define FUNCTIONFS_DMABUF_DETACH _IOW('g', 132, int)
> +
> +/*
> + * Enqueue the previously attached DMABUF to the transfer queue.
> + * The argument is a structure that packs the DMABUF's file descriptor,
> + * the size in bytes to transfer (which should generally correspond to
> + * the size of the DMABUF), and a 'flags' field which is unused
> + * for now. Returns zero on success, and a negative errno value on
> + * error.
> + */
> +#define FUNCTIONFS_DMABUF_TRANSFER _IOW('g', 133, \
> + struct usb_ffs_dmabuf_transfer_req)
>
> #endif /* _UAPI__LINUX_FUNCTIONFS_H__ */
Only things I've found are (I think at least) bugs in the usb gadget
logic, not directly in how dma-buf/fence is used. The only thing I've
noticed is the lack of actual dma_fence seqno (which I think Christian
already pointed out in an already review, looking at archives at least).
With that addressed:
Acked-by: Daniel Vetter
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
+
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index b62c7fa0c2bc..fe95aea89d67 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -120,6 +120,24 @@ Contact: Daniel Vetter, respecti
s will not be part of that update, unless they have been
> + * explicitly added by either the framework or the driver.
Since you remove the global in the header summary I wouldn't reintroduce
it here. Seems to just add to the confusion again instead of clarifying.
If you want maybe clarify tha
3aa6c0d4 ("drm: Consolidate crtc
arrays in drm_atomic_state") and b8b5342b699b ("drm: Consolidate plane
arrays in drm_atomic_state"). With that added to the commit message:
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Maxime Ripard
> ---
> include/drm/drm_atomic.h
r arrays in drm_atomic_state"). With the commit
message suitably updated.
Reviewed-by: Daniel Vetter
>
> Signed-off-by: Maxime Ripard
> ---
> include/drm/drm_atomic.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_atomic.h b/include/
fields to an inline documentation.
>
> Signed-off-by: Maxime Ripard
Acked-by: Daniel Vetter
> ---
> include/drm/drm_atomic.h | 50
> 1 file changed, 40 insertions(+), 10 deletions(-)
>
> diff --git a/include/drm/drm_at
rivers/gpu/drm/drm_atomic_state_helper.c | 1 +
> > drivers/gpu/drm/drm_atomic_uapi.c | 43 +-
> > drivers/gpu/drm/drm_property.c | 49 ++
> > include/drm/drm_mode_object.h | 2 +-
> > include/drm/drm_plane.h | 7 +
> > include/drm/drm_property.h| 6 +
> > include/uapi/drm/drm_mode.h | 8 +
> > 16 files changed, 1377 insertions(+), 109 deletions(-)
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
te mode 100644 drivers/gpu/drm/imagination/pvr_rogue_fwif_stream.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_rogue_heap_config.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_rogue_meta.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_rogue_mips.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_rogue_mips_check.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_rogue_mmu_defs.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream_defs.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_stream_defs.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_sync.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_sync.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm.h
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm_mips.c
> create mode 100644 drivers/gpu/drm/imagination/pvr_vm_mips.h
> create mode 100644 include/uapi/drm/pvr_drm.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gpu/drm/i915/i915_gpu_error.h | 2 +
> drivers/gpu/drm/i915/i915_params.c | 89 ---
> drivers/gpu/drm/i915/i915_params.h | 22 -
> drivers/gpu/drm/i915/i915_reg.h| 2 -
> drivers/gpu/drm/i915/i915_utils.h | 2 +-
> drivers/gpu/drm/i915/intel_runtime_pm.h| 2 -
> drivers/gpu/drm/i915/selftests/intel_uncore.c | 2 +
> drivers/gpu/drm/i915/soc/intel_gmch.c | 27 +-
> drivers/gpu/drm/i915/vlv_sideband.c| 29 +-
> drivers/gpu/drm/i915/vlv_sideband.h| 9 +-
> drivers/gpu/drm/nouveau/dispnv50/disp.c| 9 +-
> drivers/gpu/drm/tests/drm_dp_mst_helper_test.c | 166 +-
> include/drm/display/drm_dp.h | 25 +
> include/drm/display/drm_dp_helper.h| 32 +
> include/drm/display/drm_dp_mst_helper.h| 16 +-
> include/drm/drm_color_mgmt.h | 19 +-
> 118 files changed, 4425 insertions(+), 1969 deletions(-)
> create mode 100644
> drivers/gpu/drm/i915/display/intel_display_debugfs_params.c
> create mode 100644
> drivers/gpu/drm/i915/display/intel_display_debugfs_params.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_params.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_params.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_dpt_common.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_dpt_common.h
> create mode 100644 drivers/gpu/drm/i915/display/intel_dsb_buffer.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_dsb_buffer.h
>
> --
> Jani Nikula, Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rs/video/fbdev/simplefb.c | 128 +-
> include/drm/drm_edid.h | 148 --
> include/drm/drm_eld.h | 164 ++
> include/drm/drm_flip_work.h| 20 +-
> include/drm/drm_format_helper.h
0001 x4 : 93c54440 x3 : 0e968000
> > x2 : 80008077883c x1 : 9ce37498 x0 : 00010001
> > Call trace:
> > drm_gem_fb_vunmap+0x18/0x74
> > drm_gem_end_shadow_fb_access+0x1c/0x2c
> > drm_atomic_helper_cleanup_planes+0x58/0xd8
> > drm_atomic_helper_commit_tail+0x90/0xa0
> > commit_tail+0x15c/0x188
> > commit_work+0x14/0x20
> > process_one_work+0x1e0/0x344
> > worker_thread+0x68/0x424
> > kthread+0xf4/0x100
> > ret_from_fork+0x10/0x20
> > Code: 910003fd a90153f3 f90013f5 aa0003f5 (f9402400)
> > ---[ end trace ]---
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
u/gsp/r535: uninitialized variable in r535_gsp_acpi_mux_id()
nouveau/gsp/r535: Fix a NULL vs error pointer bug
Daniel Vetter (2):
Merge tag 'drm-misc-fixes-2023-11-16' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Merge tag 'amd-drm-fixes-6.7-2023-1
| 6 +--
> drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 3 ++
> drivers/gpu/drm/amd/display/dc/dc_dmub_srv.c | 10 ++---
> drivers/gpu/drm/amd/display/dc/dc_types.h | 1 +
> .../display/dc/dcn35/dcn35_dio_stream_encoder.c| 10 ++---
> .../gpu/drm/amd/display/dc/lin
clude/nvkm/core/event.h | 4 ++--
> drivers/gpu/drm/nouveau/nouveau_display.c | 5 +
> drivers/gpu/drm/nouveau/nvkm/core/event.c | 12 ++--
> drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c| 6 +++---
> 6 files changed, 22 insertions(+), 14 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
sn't matter overall.
Well the new-ish begin/end_fb_access helpers would be even better I
guess for the atomic flow, but break the panic handler use-case I
think.
Oh and a bikeshed, _copy() feels a bit like a funny postfix for
something that does a state duplication, everywhere else in atomi
drm-misc.html#merge-criteria
"Any non-linear actions (backmerges, merging topic branches and sending
out pull requests) are only done by the official drm-misc maintainers (see
MAINTAINERS, or ask #dri-devel), and not by committers. See the examples
section in dim for more info"
Minor screw-ups like this gives us a great opportunity to improve the
tooling&docs, let's use it.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
use existing functions which accept a single pointer, but which
> > may not be of type void*. While this is probably dodgy enough to be on
> > the wrong side of the C standard, it's been often used for similar
> >
> > [ ... ]
>
> Reviewed-by: Maxime Ripard
Acked-
> +void ivpu_job_done_thread_enable(struct ivpu_device *vdev)
> +{
> + kthread_unpark(vdev->job_done_thread);
> }
> diff --git a/drivers/accel/ivpu/ivpu_job.h b/drivers/accel/ivpu/ivpu_job.h
> index aa1f0b9479b0..a8e914e5affc 100644
> --- a/drivers/accel/ivpu/ivpu_job
isable domain22 force power on
drm/amd/display: Enable RCO options for dcn35
drm/amd/display: Enable physymclk RCO
Daniel Vetter (3):
Merge tag 'drm-intel-next-fixes-2023-11-08' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next
Merge
splay.c| 3 +++
> drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c| 2 +-
> drivers/gpu/drm/vc4/tests/vc4_mock_output.c | 2 +-
> 10 files changed, 28 insertions(+), 21 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/drm/amd/display/dc/hwss/dce/dce_hwseq.h| 18 +-
> .../drm/amd/display/dc/hwss/dcn32/dcn32_hwseq.c| 17 +-
> .../drm/amd/display/dc/hwss/dcn35/dcn35_hwseq.c| 34 ++-
> drivers/gpu/drm/amd/display/dc/inc/hw/dccg.h | 5 +
> drivers/gpu/drm/amd/display/dc/inc/hw/dsc.h| 2 +
> drivers/gpu/drm/amd/display/dc/inc/hw/optc.h | 219 ++
> drivers/gpu/drm/amd/display/dc/inc/hw/pg_cntl.h| 2 +
> .../amd/display/dc/link/accessories/link_dp_cts.c | 17 +-
> .../dc/link/protocols/link_dp_irq_handler.c| 15 +-
> drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h| 25 +-
> drivers/gpu/drm/amd/pm/amdgpu_dpm.c| 12 +-
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 29 +-
> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 5 +-
> .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 315
> +
> 85 files changed, 1688 insertions(+), 773 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/display/dc/inc/hw/optc.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
vers/gpu/drm/i915/display/intel_dp.c | 2 +-
> drivers/gpu/drm/i915/display/intel_tc.c | 11 ++---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 +
> drivers/gpu/drm/i915/gt/intel_ggtt.c| 35
> -
> drivers/gpu/drm/i915/gt/intel_rc6.c | 16 +
sched codebase for ringbuffer scheduling which is extended to fw
scheduling in also very tricky ways, with not entirely clear impacts
on semantics of all the drm/sched things. And as a result we just pile
up enormous amounts of threads where I think the only thing assured is
that people talk past eac
all that, but this
sounds like a very good idea too me.
Acked-by: Daniel Vetter
Cheers, Sima
> ---
> Documentation/gpu/automated_testing.rst | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/gpu/automated_testing.rst
> b/Documentation/gpu/a
| 5 +-
> drivers/gpu/drm/scheduler/sched_entity.c | 85 ++-
> drivers/gpu/drm/scheduler/sched_fence.c | 2 +-
> drivers/gpu/drm/scheduler/sched_main.c| 507 --
> drivers/gpu/drm/v3d/v3d_sched.c | 25 +-
> include/drm/gpu_scheduler.h | 48 +-
> 14 files changed, 498 insertions(+), 234 deletions(-)
>
>
> base-commit: 201c8a7bd1f3f415920a2df4b8a8817e973f42fe
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
nd drm_flip_work_queue can be called
> - * in atomic context.
> + * bo's, etc until after vblank. The APIs are all thread-safe. Moreover,
> + * drm_flip_work_queue can be called in atomic context.
Since you edit this anyway, add () so it becomes a hyperlink? Also looking
at the code
On Fri, Oct 13, 2023 at 10:04:02AM -0400, Ray Strode wrote:
> Hi
>
> On Fri, Oct 13, 2023 at 5:41 AM Daniel Vetter wrote:
> > > I mean we're not talking about scientific computing, or code
> > > compilation, or seti@home. We're talking about nearly the e
On Fri, Oct 13, 2023 at 12:22:52PM +0200, Michel Dänzer wrote:
> On 10/13/23 11:41, Daniel Vetter wrote:
> > On Thu, Oct 12, 2023 at 02:19:41PM -0400, Ray Strode wrote:
> >> On Mon, Oct 09, 2023 at 02:36:17PM +0200, Christian König wrote:
> >>>>>> To be clear
> > /*
> > >* Note that as an uncached mmio write, this will flush the
> > >* WCB of the writes into the GGTT before it triggers the
> > > invalidate.
> > > + *
> > > + * Only perform this when GGTT is mapped
that then block on a fence fd, right? I
> guess we'd need to block on a fence fd from the prior non-blocking
> commit first before starting the blocking commit (or something)
Yeah there's a bunch of issues around the current nonblocking modeset uapi
semantics that make it not so useful. There was a long irc discussion last
few days about all the various aspects, it's quite tricky.
Maybe as a bit more useful outcome of this entire discussion: Could you
sign up to write a documentation patch for the atomic ioctl that adds a
paragraph stating extremely clearly that this ioctl does not make hard
real time guarantees, but only best effort soft realtime, and even then
priority of the effort is focused entirely on the !ALLOW_MODESET case,
because that is the one users care about the most.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Oct 12, 2023 at 01:39:44PM +0300, Pekka Paalanen wrote:
> On Thu, 12 Oct 2023 11:53:52 +0200
> Daniel Vetter wrote:
>
> > On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote:
> > > On Wed, 11 Oct 2023 11:42:24 +0200
> > > Daniel Vetter wrote
es are the first to go, followed right after by a long
list of more fixed function hardware blocks that outright can't cope with
page faults.
There's so many corner cases where it breaks down that I feel like device
driver allocated memory of one flavor or another will stick around for a
very long time.
This isn't even counting the software challenges.
-Sima
> > I'm also not into looking at use-cases that used to be important but
> > might not as important going forward.
>
> Well multimedia applications and OpenGL are still around, but it's not the
> main focus any more.
>
> Christian.
>
> >
> > Dave.
> >
> >
> > > Christian.
> > >
> > > > Dave.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
.probe = drm_aux_bridge_probe,
> +};
> +module_auxiliary_driver(drm_aux_bridge_drv);
> +
> +MODULE_AUTHOR("Dmitry Baryshkov ");
> +MODULE_DESCRIPTION("DRM transparent bridge");
> +MODULE_LICENSE("GPL");
> diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
> new file mode 100644
> index ..441ab3f0e920
> --- /dev/null
> +++ b/include/drm/bridge/aux-bridge.h
> @@ -0,0 +1,19 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2023 Linaro Ltd.
> + *
> + * Author: Dmitry Baryshkov
> + */
> +#ifndef DRM_AUX_BRIDGE_H
> +#define DRM_AUX_BRIDGE_H
> +
> +#if IS_ENABLED(CONFIG_DRM_AUX_BRIDGE)
> +int drm_aux_bridge_register(struct device *parent);
> +#else
> +static inline int drm_aux_bridge_register(struct device *parent)
> +{
> + return 0;
> +}
> +#endif
> +
> +#endif
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Oct 12, 2023 at 11:55:48AM +0300, Pekka Paalanen wrote:
> On Wed, 11 Oct 2023 11:42:24 +0200
> Daniel Vetter wrote:
>
> > On Wed, Oct 11, 2023 at 11:48:16AM +0300, Pekka Paalanen wrote:
> > > On Tue, 10 Oct 2023 10:06:02 -0600
> > > jim.cro...@gmail.co
.h
> @@ -117,6 +117,12 @@ enum vc4_hdmi_output_format {
> VC4_HDMI_OUTPUT_YUV420,
> };
>
> +enum vc4_hdmi_broadcast_rgb {
> + VC4_HDMI_BROADCAST_RGB_AUTO,
> + VC4_HDMI_BROADCAST_RGB_FULL,
> + VC4_HDMI_BROADCAST_RGB_LIMITED,
> +};
> +
> /* General HDMI hardware state. */
> struct vc4_hdmi {
> struct vc4_hdmi_audio audio;
> @@ -129,6 +135,8 @@ struct vc4_hdmi {
>
> struct delayed_work scrambling_work;
>
> + struct drm_property *broadcast_rgb_property;
> +
> struct i2c_adapter *ddc;
> void __iomem *hdmicore_regs;
> void __iomem *hd_regs;
> @@ -238,6 +246,7 @@ struct vc4_hdmi_connector_state {
> unsigned long long tmds_char_rate;
> unsigned intoutput_bpc;
> enum vc4_hdmi_output_format output_format;
> + enum vc4_hdmi_broadcast_rgb broadcast_rgb;
> };
>
> #define conn_state_to_vc4_hdmi_conn_state(_state) \
>
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
oblem. Sessions could register what
kind of info they need for their session, and something like journald can
figure out how to record it all.
If you want the kernel to keep separate flight recorders I guess we could
add that, but I don't think it currently exists for the dyndbg stuff at
least
le about intel's bigjoiner mode.
Also cc everyone involved in the msm irc discussion, more people
joined after I sent out v1.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Rob Clark
Cc:
; > @@@ -457,23 -264,12 +264,14 @@@ static int msm_drm_init(struct device *
> > if (ret)
> > goto err_deinit_vram;
> >
> > - /* the fw fb could be anywhere in memory */
> > - ret = drm_aperture_remove_framebuffers(drv);
> > - if (ret)
> > - goto err_msm_uninit;
> > -
> > - msm_gem_shrinker_init(ddev);
> > + ret = msm_gem_shrinker_init(ddev);
> > + if (ret)
> > + goto err_msm_uninit;
> >
> > if (priv->kms_init) {
> > - ret = priv->kms_init(ddev);
> > - if (ret) {
> > - DRM_DEV_ERROR(dev, "failed to load kms\n");
> > - priv->kms = NULL;
> > + ret = msm_drm_kms_init(dev, drv);
> > + if (ret)
> > goto err_msm_uninit;
> > - }
> > - kms = priv->kms;
> > } else {
> > /* valid only for the dummy headless case, where
> > of_node=NULL */
> > WARN_ON(dev->of_node);
> > @@@ -1277,37 -971,21 +973,19 @@@ int msm_drv_probe(struct device *master
> >
> > static int msm_pdev_probe(struct platform_device *pdev)
> > {
> > - return msm_drv_probe(&pdev->dev, NULL);
> > + return msm_drv_probe(&pdev->dev, NULL, NULL);
> > }
> >
> > -static int msm_pdev_remove(struct platform_device *pdev)
> > +static void msm_pdev_remove(struct platform_device *pdev)
> > {
> > component_master_del(&pdev->dev, &msm_drm_ops);
> > -
> > - return 0;
> > }
> >
> > - void msm_drv_shutdown(struct platform_device *pdev)
> > - {
> > - struct msm_drm_private *priv = platform_get_drvdata(pdev);
> > - struct drm_device *drm = priv ? priv->dev : NULL;
> > -
> > - /*
> > -* Shutdown the hw if we're far enough along where things might be
> > on.
> > -* If we run this too early, we'll end up panicking in any variety
> > of
> > -* places. Since we don't register the drm device until late in
> > -* msm_drm_init, drm_dev->registered is used as an indicator that
> > the
> > -* shutdown will be successful.
> > -*/
> > - if (drm && drm->registered && priv->kms)
> > - drm_atomic_helper_shutdown(drm);
> > - }
> > -
> > static struct platform_driver msm_platform_driver = {
> > .probe = msm_pdev_probe,
> > - .remove = msm_pdev_remove,
> > + .remove_new = msm_pdev_remove,
> > - .shutdown = msm_drv_shutdown,
> > .driver = {
> > .name = "msm",
> > - .pm = &msm_pm_ops,
> > },
> > };
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
f the ctm change itself would not result in flicker,
this can hide modesets for other reasons. Which again breaks the
uapi
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Rob Clark
Cc: Simon
do an s/void */uinptr_t/ over my
interface proposal, or maybe an even more opaque cookie since really the
only thing you can do is get the void * that ->panic_vmap returns and pass
it into ->panic_draw_xy.
I thought (but I didn't dig through details) that the panic fb struct is
essentially meant to serve this purpose in the current series?
> > This will even work for the AMD debug interface.
> > In the linear CPU accessible buffer case, we can provide a helper for
> > that, maybe we can do helpers for other common cases as well.
>
> Yeah, their idea of a panic_draw would work great for that.
>
> > Adding to that we would need a panic_setup/enter and panic_teardown/exit
> > callback.
>
> What for?
So panic teardown would be for testing in CI, to make it non-destructive
and clean up anything panic_vmap (or _enter or whatever you call it) has
done. I thought John Oggness was also looking into how the new panic
handlers/consoles could be made testable in the panic paths, including
lock stealing and getting called from nmi.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
v_fb.c | 8 +--
> drivers/video/fbdev/vga16fb.c | 9 +--
> include/linux/console.h | 7 ++
> 42 files changed, 183 insertions(+), 252 deletions(-)
> delete mode 100644 arch/hexagon/kernel/screen_info.c
>
> --
> 2.39.2
>
> Cc
ce(dev);
> > > err_enable_device:
> > > framebuffer_release(info);
> > > return rc;
> > > @@ -1085,7 +1085,7 @@ static void ark_pci_remove(struct pci_dev *dev)
> > >
> > > pci_iounmap(dev, info->screen_base);
> > > pci_release_regions(dev);
> > > -/* pci_disable_device(dev); */
> > > + pci_disable_device(dev);
> > >
> > > framebuffer_release(info);
> > > }
> >
> >
>
>
>
> --
> Ondrej Zary
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e we don't. Also we already do fail with inheriting the
priority properly, so another nail in the "kms is best effort".
> The key point here is that the patch puts the work into the background just
> to avoid that it is accounted to the thread issuing it, and that in turn is
> not valid as far as I can see.
Yeah it's that aspect I'm really worried about, because we essentially
start to support some gurantees that a) most drivers can't uphold without
a huge amount of work, some of the DC state recomputations are _really_
expensive b) without actually making the semantics clear, it's just
duct-tape.
Yes compositors want to run kms in real-time, and yes that results in fun
if you try to strictly account for cpu time spent. Especially if your
policy is to just nuke the real time thread instead of demoting it to
SCHED_NORMAL for a time.
I think if we want more than hacks here we need to answer two questions:
- which parts of the kms api are real time
- what exactly do we guarantee with that
And that answer probably needs to include things like the real time thread
workers for cursor and other nonblocking commits.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Oct 05, 2023 at 01:16:27PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 05, 2023 at 11:57:41AM +0200, Daniel Vetter wrote:
> > On Tue, Sep 26, 2023 at 01:05:49PM -0400, Ray Strode wrote:
> > > From: Ray Strode
> > >
> > > A drm atomic commit can be quit
ommit() internally:
> *
> * 1. Run drm_atomic_helper_prepare_planes(). Since this can fail and we
> * need to propagate out of memory/VRAM errors to userspace, it must be
> called
> * synchronously.
> *
> * 2. Synchronize with any outstanding nonblocking commit worke
primitives", so semaphore here doesn't look any
better. The vkms_set_composer() function was originally for crc
generation, where it's userspace's job to make sure they wait for all the
crc they need to be generated before they shut it down again. But for
writeback the kernel mus
e thing gets
> deleted a year from now as "this didn't go anywhere", it doesn't look
> like it should cause a ton of problems either.
>
> Anyway, it's in my tree now, let's see where it goes.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_test_mm_lowest),
> KUNIT_CASE(drm_test_mm_highest),
> KUNIT_CASE(drm_test_mm_color),
> - KUNIT_CASE(drm_test_mm_color_evict),
> - KUNIT_CASE(drm_test_mm_color_evict_range),
> + KUNIT_CASE_SLOW(drm_test_mm_color_evict),
> + KUNIT_CASE_SLOW(drm_test_mm_color_evict_range),
> {}
> };
>
>
> --
> 2.41.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
th lockdep priming, testing in CI isn't
good enough for anything remotely complex), then you have a _really_ big
problem. Yes CI is good at catching accidental changes in locking design,
but if you use it for anything more than that you're in deep trouble.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Aug 28, 2023 at 04:01:38PM -0700, John Harrison wrote:
> On 8/23/2023 10:37, John Harrison wrote:
> > On 8/23/2023 09:00, Daniel Vetter wrote:
> > > On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
> > > > On 8/11/2023 11:20, Zhanjun Dong wro
all that just because it's part of a hardware
enabling series.
Cheers, Sima
> Alex
>
>
> > >
> > >
> > > BR,
> > > Jani.
> > >
> > >
> > >>
> > >> With the patch. both following git grep commands return nothing in
> > >> amd-staging-drm-next.
> > >>
> > >> $ git grep drm_edid_override_connector_update -- drivers/gpu/drm/amd
> > >> $ git grep edid_override -- drivers/gpu/drm/amd
> > >>
> > >> Best regards,
> > >> Alex Hung
> > >>
> > >>>>>
> > >>>>> What is the goal of the reverts? I don't disagree that we may be
> > >>>>> using the interfaces wrong, but reverting them will regess
> > >>>>> functionality in the driver.
> > >>>>
> > >>>> The commits are in v6.5-rc1, but not yet in a release. No user depends
> > >>>> on them yet. I'd strongly prefer them not reaching v6.5 final and
> > >>>> users.
> > >>>
> > >>> Sorry for confusion here, that's obviously come and gone already. :(
> > >>>
> > >>>> The firmware EDID, override EDID, connector forcing, the EDID property,
> > >>>> etc. have been and somewhat still are a hairy mess that we must keep
> > >>>> untangling, and this isn't helping.
> > >>>>
> > >>>> I've put in crazy amounts of work on this, and I've added kernel-doc
> > >>>> comments about stuff that should and should not be done, but they go
> > >>>> unread and ignored.
> > >>>>
> > >>>> I really don't want to end up having to clean this up myself before I
> > >>>> can embark on further cleanups and refactoring.
> > >>>>
> > >>>> And again, if the functionality in the driver depends on conflating two
> > >>>> things that should be separate, it's probably not such a hot idea to
> > >>>> let
> > >>>> it reach users either. Even if it's just debugfs.
> > >>>>
> > >>>>
> > >>>> BR,
> > >>>> Jani.
> > >>>
> > >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
23 08:37, Maxime Ripard wrote:
> >>> On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
> >>>> On Wed, 30 Aug 2023, Maxime Ripard wrote:
> >>>>> On Tue, Aug 22, 2023 at 04:26:06PM +0200, Daniel Vetter wrote:
> >>>>>> On
e/linux/fb.h
> > > +++ b/include/linux/fb.h
> > > @@ -592,7 +592,7 @@ extern ssize_t fb_sys_write(struct fb_info *info,
> > > const char __user *buf,
> > > __FB_DEFAULT_SYS_OPS_DRAW, \
> > > __FB_DEFAULT_SYS_OPS_MMAP
> > >
>
.com
> Signed-off-by: Rodrigo Vivi
On the series:
Acked-by: Daniel Vetter
But also, I really don't want to be the gatekeeper for "is xe ready for
merging", so at least for the last two patches I think an ack from Danilo
that there's indeed a rough consensus/plan is much more
t the agx people added to make sure X doesn't
accidentally open the wrong driver.
-Sima
>
> Cheers,
> Mikko
>
> >
> > Best regards
> > Thomas
> >
> >> +err = drm_aperture_remove_framebuffers(&tegra_drm_driver);
> >> +if (err < 0)
> >> +goto hub;
> >> +}
> >> err = drm_dev_register(drm, 0);
> >> if (err < 0)
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/ci/xfails/msm-sc7180-flakes.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-skips.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-fails.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-flakes.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-fails.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-skips.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-fails.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-skips.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-fails.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
> create mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-skips.txt
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 30, 2023 at 10:29:46AM +0300, Jani Nikula wrote:
> Upstream code should be reviewed in public.
Yup
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
to be run on all drivers (unless mentioned in a driver's
> *-skips.txt
> +IGT tests to be run on all drivers (unless mentioned in a driver's
> \*-skips.txt
> file, see below).
>
> drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-fails.txt
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rogress.
> >
> > Signed-off-by: Zhanjun Dong
> > Cc: John Harrison
> > Cc: Andi Shyti
> > Cc: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 ++-
> > 1 file changed, 10 insertions(+), 1 deletion(-)
> &
On Tue, Aug 22, 2023 at 05:51:39PM +0300, Jani Nikula wrote:
> On Tue, 22 Aug 2023, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, Aug 22, 2023 at 04:16:08PM +0200, Daniel Vetter wrote:
> >> On Mon, Aug 14, 2023 at 03:56:12PM +0200, Maxime Ripard wrote:
> &g
On Tue, Aug 22, 2023 at 04:35:55PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Tue, Aug 22, 2023 at 04:16:08PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 14, 2023 at 03:56:12PM +0200, Maxime Ripard wrote:
> > > Here's a series that creates a subclass of drm_connector s
On Tue, Aug 22, 2023 at 02:14:28PM +, Dong, Zhanjun wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: August 22, 2023 9:51 AM
> > To: Dong, Zhanjun
> > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
&
t; ++
> drivers/gpu/drm/vc4/vc4_hdmi.c | 720 --
> drivers/gpu/drm/vc4/vc4_hdmi.h | 37 +-
> drivers/gpu/drm/vc4/vc4_hdmi_phy.c |4 +-
> include/drm/drm_connector.h | 256
> 6 files changed
iewed-by: Muchun Song
On the 5 drm patches (I counted 2 ttm and 3 drivers) for merging through
some other tree (since I'm assuming that's how this will land):
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 15 +++
> include/linux/shrinker
quire a lock,
> which might trigger the possible cirular locking dependency warning.
> When intel_gt_reset called, reset_in_progress flag will be set, add code
> to check the flag, call async verion if reset is in progress.
>
> Signed-off-by: Zhanjun Dong
> Cc: John Harrison
> Cc
;
> This ties up all of dma-buf, formats and modifiers, and their usage.
>
> Signed-off-by: Daniel Stone
On both patches Acked-by: Daniel Vetter with the
minor nits on this one here address while applying or something like that.
> ---
> Documentation/driver-api/dma-buf.rst
fails/mediatek-mt8183-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-skips.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sc7180-skips.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/msm-sdm845-skips.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-skips.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3399-skips.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-fails.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt
> >>> create mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-skips.txt
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
401 - 500 of 6215 matches
Mail list logo
