On Thu, Jan 05, 2023 at 11:10:23PM +0900, Yi Xie wrote:
> On Thu, Jan 5, 2023 at 10:48 PM Daniel Vetter wrote:
> >
> > On Thu, Jan 05, 2023 at 09:52:26PM +0900, Yi Xie wrote:
> > > > This doesn't sound like a good idea to me. Devices without render
> &g
On Thu, Jan 05, 2023 at 01:34:33PM +, David Laight wrote:
> From: Jani Nikula
> > Sent: 05 January 2023 13:28
> >
> > On Thu, 05 Jan 2023, Daniel Vetter wrote:
> > > On Mon, Dec 12, 2022 at 09:38:12AM +, David Laight wrote:
> > >> From: Andrzej
96
> We can do the same for vkms to force software rendering.
Yeah that is the old kmsro mesa issue, for every combination of kms and
gem device you need one to make this work.
> On Thu, Jan 5, 2023 at 8:36 PM Daniel Vetter wrote:
> >
> > On Thu, Jan 05, 2023 at 02:23:25PM +0900,
On Thu, Jan 05, 2023 at 02:39:21PM +0200, Jani Nikula wrote:
> On Wed, 04 Jan 2023, Daniel Vetter wrote:
> > The documentation for struct drm_minor already states this, but that's
> > not always that easy to find.
> >
> > Also due to historical reasons we st
On Thu, Jan 05, 2023 at 10:17:24PM +0900, Tetsuo Handa wrote:
> On 2023/01/05 20:54, Daniel Vetter wrote:
> >>> . Plain memset() in arch/x86/include/asm/string_64.h is redirected to
> >>> __msan_memset()
> >>> but memsetXX() are not redirecte
kanti
> Signed-off-by: Vinod Polimera
I think this is all a nice integration of the sr helpers and bridge stuff
and makes sense to me. For the 2 bridge patches and the drm core atomic
patch:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu
aced by open-coded
versions.
Not moved into shared headers where even more people can play funny games
with it.
I think swap() is a standard idiom in C, this one here just isn't.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Dec 13, 2022 at 07:17:41PM +0100, Christian König wrote:
> Am 13.12.22 um 18:09 schrieb Daniel Vetter:
> > On Sat, Dec 10, 2022 at 08:43:47AM +0530, Sumit Semwal wrote:
> > > Hi Christian,
> > >
> > > On Fri, 9 Dec 2022 at 12:45, Christian König
>
On Thu, Dec 08, 2022 at 12:07:27PM +0100, Jacek Lawrynowicz wrote:
> +static const struct drm_driver driver = {
> + .driver_features = DRIVER_GEM | DRIVER_COMPUTE_ACCEL,
So I was wondering whether this is a bright idea, and whether we shouldn't
just go ahead and infuse more meaning into accel
BMIT_BO_NO_IMPLICIT 0x0008
>
> #define MSM_SUBMIT_BO_FLAGS(MSM_SUBMIT_BO_READ | \
> MSM_SUBMIT_BO_WRITE | \
> - MSM_SUBMIT_BO_DUMP)
> + MSM_SUBMIT_BO_DUMP | \
> + MSM_SUBMIT_BO_NO_IMPLICIT)
>
> struct drm_msm_gem_submit_bo {
> __u32 flags; /* in, mask of MSM_SUBMIT_BO_x */
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
SSMAP_DEFINE args in sync with changes here,
> + * the enum-values define BIT()s in drm.debug, so are ABI.
> + */
> /**
> * @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
>* drm_memory.c, ...
> --
> 2.38.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
v.c
> > delete mode 100644 drivers/gpu/drm/sis/sis_drv.h
> > delete mode 100644 drivers/gpu/drm/sis/sis_mm.c
> > delete mode 100644 drivers/gpu/drm/tdfx/Makefile
> > delete mode 100644 drivers/gpu/drm/tdfx/tdfx_drv.c
> > delete mode 100644 drivers/gpu/drm/tdfx/tdfx_drv.h
> > delete mode 100644 drivers/gpu/drm/via/Makefile
> > delete mode 100644 drivers/gpu/drm/via/via_3d_reg.h
> > delete mode 100644 drivers/gpu/drm/via/via_dri1.c
> > delete mode 100644 include/uapi/drm/i810_drm.h
> > delete mode 100644 include/uapi/drm/mga_drm.h
> > delete mode 100644 include/uapi/drm/r128_drm.h
> > delete mode 100644 include/uapi/drm/savage_drm.h
> > delete mode 100644 include/uapi/drm/sis_drm.h
> > delete mode 100644 include/uapi/drm/via_drm.h
> >
> > --
> > 2.25.1
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
x27;s going on with dependencies and so on for getting
> the patches merged.
+1 on including the cover letter for any recipient. If b4 can do this
right by default, that would be a really good reason for me to look into
it and switch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Dec 02, 2022 at 10:01:01AM +0100, Christian König wrote:
> Am 01.12.22 um 12:09 schrieb Tvrtko Ursulin:
> >
> > On 30/11/2022 14:18, Daniel Vetter wrote:
> > > On Wed, Nov 30, 2022 at 01:34:07PM +, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursuli
On Thu, 8 Dec 2022 at 05:54, Alex Deucher wrote:
>
> On Wed, Nov 30, 2022 at 6:11 AM Daniel Vetter wrote:
> >
> > On Fri, Nov 25, 2022 at 02:52:01PM -0300, André Almeida wrote:
> > > This patchset adds a udev event for DRM device's resets.
> > >
>
> On Thu, Dec 1, 2022 at 4:22 AM Daniel Vetter wrote:
> >>
> >> On Thu, 1 Dec 2022 at 11:07, Daniel Vetter wrote:
> >> >
> >> > On Wed, Nov 23, 2022 at 08:24:37PM +0100, Daniel Vetter wrote:
> >> > > It's a bit a FAQ, and we reall
re? Can someone please send me a revert or patch
to apply. I don't think I should do this, since I already tossed my credit
for not looking at stuff carefully enough into the wind :-)
-Daniel
>
> #define __HAVE_ARCH_MEMMOVE
> #if defined(__SANITIZE_MEMORY__) && defined(__N
t actually
> > > sits behind the CPU cache and thus dirties it on writes, not the
> > > driver doing that. (I haven't personally encountered such a system,
> > > though.)
> > >
> > > >
> > > > We could say that all device drivers must always look at the coherency
> > > > of the devices which want to access their buffers. But that would
> > > > horrible complicate things for maintaining the drivers because then
> > > > drivers would need to take into account requirements from other drivers
> > > > while allocating their internal buffers.
> > >
> > > I think it's partially why we have the allocation part of the DMA
> > > mapping API, but currently it's only handling requirements of one
> > > device. And we don't have any information from the userspace what
> > > other devices the buffer would be used with...
> > >
> > > Actually, do we even have such information in the userspace today?
> > > Let's say I do a video call in a web browser on a typical Linux
> > > system. I have a V4L2 camera, VAAPI video encoder and X11 display. The
> > > V4L2 camera fills in buffers with video frames and both encoder and
> > > display consume them. Do we have a central place which would know that
> > > a buffer needs to be allocated that works with the producer and all
> > > consumers?
> >
> > I have a vague belief that many, many years ago, in the early days of
> > dmabuf development, there was the idea of the sequence:
> > - create a dmabuf handle
> > - share the handle with all devices that would need access
> > - *then* do the allocation with kernel-internal negotiation to fill all
> > devices' needs, if at all possible
> >
> > Obviously that didn't happen. I think today's dmabuf Wayland protocol
> > would support this though.
> >
> > Anyway, Wayland can tell the app which DRM devices a buffer
> > needs to work with as a GPU texture and potentially on same/another
> > DRM device as a KMS framebuffer, so theoretically the app could know.
> >
> >
> > Thanks,
> > pq
> ___
> Linaro-mm-sig mailing list -- linaro-mm-...@lists.linaro.org
> To unsubscribe send an email to linaro-mm-sig-le...@lists.linaro.org
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Dec 02, 2022 at 04:27:08PM +0100, Christian König wrote:
> Am 30.11.22 um 11:30 schrieb Daniel Vetter:
> > On Fri, Nov 25, 2022 at 11:40:04AM -0500, Nicolas Dufresne wrote:
> > > Le mercredi 23 novembre 2022 à 17:33 +0100, Daniel Vetter a écrit :
> > > > On W
| 27
> ++
> drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++
> .../dc/dml/dcn32/display_mode_vba_util_32.c| 6 ++---
> 5 files changed, 39 insertions(+), 9 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
MODESET | DRIVER_ATOMIC | DRIVER_GEM |
> DRIVER_RENDER,
> .release= vkms_release,
> .fops = &vkms_driver_fops,
> DRM_GEM_SHMEM_DRIVER_OPS,
> --
> 2.39.0.314.g84b9a713c41-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_blend.c | 17 +++
> drivers/gpu/drm/drm_plane.c | 8 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 +-
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 65 +++
> include/drm/drm_atomic_helper.h | 5 +-
> include/drm/drm_blend.h |
On Thu, 5 Jan 2023 at 11:31, Helge Deller wrote:
>
> On 1/5/23 11:22, Daniel Vetter wrote:
> > On Thu, 5 Jan 2023 at 09:14, Helge Deller wrote:
> >>
> >> Hi Linus,
> >>
> >> please pull the fbdev driver updates for 6.2-rc3, to receive
On Thu, 5 Jan 2023 at 11:21, Daniel Vetter wrote:
>
> Hi Helge
>
> On Mon, 2 Jan 2023 at 16:28, Helge Deller wrote:
> >
> > On 12/30/22 07:35, Hang Zhang wrote:
> > > In do_fb_ioctl(), user specified "fb_info" can be freed in the callee
> >
| 2 ++
> drivers/video/fbdev/matrox/matroxfb_base.c | 4 ++--
> drivers/video/fbdev/omap/omapfb_main.c | 5 ++---
> drivers/video/fbdev/omap2/omapfb/dss/dsi.c | 28 ++--
> 6 files changed, 27 insertions(+), 19 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
reak;
> > default:
> > + console_lock();
> > lock_fb_info(info);
> > fb = info->fbops;
> > if (fb->fb_ioctl)
> > @@ -1189,6 +1190,7 @@ static long do_fb_ioctl(struct fb_info *info,
> > unsigned int cmd,
> > else
> > ret = -ENOTTY;
> > unlock_fb_info(info);
> > + console_unlock();
> > }
> > return ret;
> > }
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
anfrost/panfrost_gem.h | 5 +-
> drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
> drivers/gpu/drm/scheduler/sched_main.c | 4 +-
> drivers/gpu/drm/virtio/virtgpu_object.c | 6 ++-
> include/drm/drm_plane_helper.h | 1 +
> 12 files changed, 80 insertions(+), 93 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ld be done
ideally.
Motvated by some discussion with Rodrigo on irc about how drm/xe
should lay out its sysfs interfaces.
Cc: Rodrigo Vivi
Cc: Wambui Karuga
Cc: Maíra Canal
Cc: Maxime Ripard
Cc: Melissa Wen
Signed-off-by: Daniel Vetter
---
include/drm/drm_device.h | 17 +++--
1
| 303 ------
> include/drm/ttm/ttm_device.h |7 +-
> include/drm/ttm/ttm_execbuf_util.h |4 +-
> include/linux/dma-buf.h|4 +-
> include/linux/fb.h |3 +-
> include/linux/i2c.h|1 +
> include/uapi/linux/media-bus-format.h |5 +-
> 267 files changed, 7001 insertions(+), 2561 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/focaltech,gpt3.yaml
> create mode 100644 drivers/gpu/drm/imx/ipuv3/Kconfig
> create mode 100644 drivers/gpu/drm/imx/ipuv3/Makefile
> rename drivers/gpu/drm/imx/{ => ipuv3}/dw_hdmi-imx.c (100%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/imx-drm-core.c (100%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/imx-drm.h (100%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/imx-ldb.c (100%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/imx-tve.c (100%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-crtc.c (100%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-plane.c (98%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/ipuv3-plane.h (100%)
> rename drivers/gpu/drm/imx/{ => ipuv3}/parallel-display.c (100%)
> create mode 100644 drivers/gpu/drm/panel/panel-orisetech-ota5601a.c
> create mode 100644 drivers/gpu/drm/tests/drm_connector_test.c
> delete mode 100644 drivers/gpu/drm/tests/drm_kunit_helpers.h
> create mode 100644 drivers/gpu/drm/tests/drm_managed_test.c
> create mode 100644 drivers/gpu/drm/tests/drm_modes_test.c
> create mode 100644 drivers/gpu/drm/tests/drm_probe_helper_test.c
> create mode 100644 drivers/gpu/drm/vc4/tests/.kunitconfig
> create mode 100644 drivers/gpu/drm/vc4/tests/vc4_mock.c
> create mode 100644 drivers/gpu/drm/vc4/tests/vc4_mock.h
> create mode 100644 drivers/gpu/drm/vc4/tests/vc4_mock_crtc.c
> create mode 100644 drivers/gpu/drm/vc4/tests/vc4_mock_output.c
> create mode 100644 drivers/gpu/drm/vc4/tests/vc4_mock_plane.c
> create mode 100644 drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c
> create mode 100644 include/drm/drm_kunit_helpers.h
> rename include/drm/ttm/{ttm_bo_api.h => ttm_bo.h} (66%)
> delete mode 100644 include/drm/ttm/ttm_bo_driver.h
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> drivers/gpu/drm/scheduler/sched_main.c | 4 ++--
> drivers/gpu/drm/tests/Makefile | 2 ++
> drivers/gpu/drm/tests/drm_mm_test.c | 6 +++---
> 4 files changed, 8 insertions(+), 6 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
%llx\n",
> > > > + &mode_cmd->pixel_format, mode_cmd->modifier[0]);
> > > > + return ERR_PTR(-EINVAL);
> > > > + }
> > > > +
> > > > return drm_gem_fb_create(dev, file_priv, mode_cmd);
> > > > }
> > > >
> > > > @@ -1033,7 +1054,7 @@ static const struct drm_mode_config_funcs
> > > > vc4_mode_funcs = {
> > > > static const struct drm_mode_config_funcs vc5_mode_funcs = {
> > > > .atomic_check = vc4_atomic_check,
> > > > .atomic_commit = drm_atomic_helper_commit,
> > > > - .fb_create = drm_gem_fb_create,
> > > > + .fb_create = vc5_fb_create,
> > > > };
> > > >
> > > > int vc4_kms_load(struct drm_device *dev)
> > > > --
> > > > 2.38.1
> > > >
> > >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
idation for Gen12.50 video and compute engines
Daniel Vetter (1):
Merge tag 'drm-intel-fixes-2022-12-30' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Jani Nikula (2):
drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence
drm/i915/dsi: fix MIPI_BKL
m/i915/i915_gem_evict.h | 4 +-
> drivers/gpu/drm/i915/i915_irq.c | 3 +
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/i915_vma.c | 2 +-
> drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 4 +-
> 12 files changed, 212 insertions(+), 45 deletions(-)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
late_register approach.
I think as a stop-gap (really need to get this stuff landed so people can
start to use it) this is ok, but long term I think the right fix is to
roll out the same pre-register infrastructure for connector and crtc too.
That way drivers don't need to split thei
void *filter_context;
> };
>
> void drm_connector_list_iter_begin(struct drm_device *dev,
> struct drm_connector_list_iter *iter);
> +void drm_connector_list_iter_filter_begin(struct drm_device *dev,
> + struct drm_connector_list_iter *iter,
> + drm_connector_list_iter_filter_fn
> filter,
> + void *filter_context);
> struct drm_connector *
> drm_connector_list_iter_next(struct drm_connector_list_iter *iter);
> void drm_connector_list_iter_end(struct drm_connector_list_iter *iter);
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
= dma_buf_getfile(dmabuf, exp_info->flags);
> > - if (IS_ERR(file)) {
> > - ret = PTR_ERR(file);
> > + ret = dma_buf_stats_setup(dmabuf, file);
> > + if (ret)
> > goto err_dmabuf;
> > - }
> >
> > + file->private_data = dmabuf;
> > + file->f_path.dentry->d_fsdata = dmabuf;
> > dmabuf->file = file;
> >
> > - mutex_init(&dmabuf->lock);
> > - INIT_LIST_HEAD(&dmabuf->attachments);
> > -
> > mutex_lock(&db_list.lock);
> > list_add(&dmabuf->list_node, &db_list.head);
> > mutex_unlock(&db_list.lock);
> >
> > - ret = dma_buf_stats_setup(dmabuf);
> > - if (ret)
> > - goto err_sysfs;
> > -
> > return dmabuf;
> >
> > -err_sysfs:
> > - /*
> > -* Set file->f_path.dentry->d_fsdata to NULL so that when
> > -* dma_buf_release() gets invoked by dentry_ops, it exits
> > -* early before calling the release() dma_buf op.
> > -*/
> > - file->f_path.dentry->d_fsdata = NULL;
> > - fput(file);
> > err_dmabuf:
> > + if (!resv)
> > + dma_resv_fini(dmabuf->resv);
> > kfree(dmabuf);
> > +err_file:
> > + fput(file);
> > err_module:
> > module_put(exp_info->owner);
> > return ERR_PTR(ret);
> > --
> > 2.34.1
> >
>
>
> --
> Thanks and regards,
>
> Sumit Semwal (he / him)
> Tech Lead - LCG, Vertical Technologies
> Linaro.org │ Open source software for ARM SoCs
> ___
> Linaro-mm-sig mailing list -- linaro-mm-...@lists.linaro.org
> To unsubscribe send an email to linaro-mm-sig-le...@lists.linaro.org
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 1 Dec 2022 at 11:07, Daniel Vetter wrote:
>
> On Wed, Nov 23, 2022 at 08:24:37PM +0100, Daniel Vetter wrote:
> > It's a bit a FAQ, and we really can't claim to be the authoritative
> > source for allocating these numbers used in many standard extensions
>
On Wed, Nov 23, 2022 at 08:24:37PM +0100, Daniel Vetter wrote:
> It's a bit a FAQ, and we really can't claim to be the authoritative
> source for allocating these numbers used in many standard extensions
> if we tell closed source or vendor stacks in general to go away.
>
&
On Thu, Dec 01, 2022 at 12:49:16AM +0800, Randy Li wrote:
>
>
> Sent from my iPad
>
> > On Nov 30, 2022, at 7:30 PM, Daniel Vetter wrote:
> >
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the
+++ b/include/drm/drm_file.h
> @@ -255,8 +255,15 @@ struct drm_file {
> /** @master_lookup_lock: Serializes @master. */
> spinlock_t master_lookup_lock;
>
> - /** @pid: Process that opened this file. */
> - struct pid *pid;
> + /**
> + * @pid: Process that is using this file.
> + *
> + * Must only be dereferenced under a rcu_read_lock or equivalent.
> + *
> + * Updates are guarded with dev->filelist_mutex and reference must be
> + * dropped after a RCU grace period to accommodate lockless readers.
> + */
> + struct pid __rcu *pid;
>
> /** @magic: Authentication magic, see @authenticated. */
> drm_magic_t magic;
> @@ -415,6 +422,8 @@ static inline bool drm_is_accel_client(const struct
> drm_file *file_priv)
> return file_priv->minor->type == DRM_MINOR_ACCEL;
> }
>
> +void drm_file_update_pid(struct drm_file *);
> +
> int drm_open(struct inode *inode, struct file *filp);
> int drm_open_helper(struct file *filp, struct drm_minor *minor);
> ssize_t drm_read(struct file *filp, char __user *buffer,
> --
> 2.34.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e can't feed the thing into
dim for processing, and have to do that also manually :-)
-Daniel
>
> Maxime
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> > same story for the ttm backend, except slightly more complicated in
> > that there might be no currently bound VMA, and yet the GPU could
> > still be accessing the pages due to async unbinds, kernel moves etc,
> > which the wait here (and in i915_ttm_shrink) is meant to prot
the only issue is the mutex_lock_interruptible,
and the only way we've found to hit this is if you send a signal to the
original process in a fork() at _just_ the right time.
With that: Reviewed-by: Daniel Vetter
>
> Fixes: 2194a63a818d ("drm: Add library for shmem
, 1, 6, 2, 1)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H3P8_64L4_COMPRESSED \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1, 6, 2, 1)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H1_128L128_COMPRESSED \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 1, 7, 7, 1)
> +
> +#define DRM_FORMAT_MOD_SYNA_V4H3P8_128L128_COMPRESSED \
> + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 3, 8, 1, 7, 7, 1)
> +
> #if defined(__cplusplus)
> }
> #endif
> --
> 2.37.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
se_count);
> > > +
> > > + shmem->pages_use_count++;
> > > + mutex_unlock(&shmem->pages_lock);
> >
> > The previous code, in that situation, would not increment pages_use_count,
> > and it would not set not set shmem->pages. Hopefully,
lark
With Guenter's nits addressed:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> i
rs.
- igt for this stuff. Probably needs some work to generalize the i915
infra for endless batchbuffers so that you can make very controlled gpu
hangs.
Cheers, Daniel
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 4 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 30 +++
ing
needs to be fixed either way.
-Daniel
>
> for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> ret = mtk_drm_crtc_init_comp_planes(drm_dev, mtk_crtc, i,
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Nov 25, 2022 at 11:40:04AM -0500, Nicolas Dufresne wrote:
> Le mercredi 23 novembre 2022 à 17:33 +0100, Daniel Vetter a écrit :
> > On Wed, Nov 23, 2022 at 10:33:38AM +0200, Pekka Paalanen wrote:
> > > On Tue, 22 Nov 2022 18:33:59 +0100
> > > Christian Köni
On Thu, Nov 24, 2022 at 11:11:21AM +, Robin Murphy wrote:
> On 2022-11-23 17:28, Daniel Vetter wrote:
> > This code was added in b65e64f7ccd4 ("drm/cma: Use
> > dma_mmap_writecombine() to mmap buffer"), but does not explain why
> > it's needed.
> &
const char *name;
> > - /** @name_lock: Spinlock to protect name acces for read access. */
> > + /** @name_lock: Spinlock to protect name access for read access. */
> > spinlock_t name_lock;
> > /**
> > @@ -402,7 +402,7 @@ struct dma_buf {
> > * anything the userspace API considers write access.
> > *
> > * - Drivers may just always add a write fence, since that only
> > -* causes unecessarily synchronization, but no correctness issues.
> > +* causes unnecessary synchronization, but no correctness issues.
> > *
> > * - Some drivers only expose a synchronous userspace API with no
> > * pipelining across drivers. These do not set any fences for their
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
like the host endian hacks in the addfb compat code.
-Daniel
>
> [2] [PATCH 1/3] drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats
> https://lore.kernel.org/all/0744671ac096a12f0d538906bd324efa71b11400.1657300532.git.ge...@linux-m68k.org
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
d that anywhere anymore. At least not in a public link.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Alex Deucher
Cc: Daniel Stone
Cc: Bas Nieuwenhuizen
Cc: Jason Ekstrand
Cc: Neil Trevett
Signed-off-by: Daniel Vetter
---
include/uapi/d
n König"
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_dma_helper.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_dma_helper.c
b/drivers/gpu/drm/drm_gem_dma_helper.c
index 1e658c448366..637a5cc62457 100644
--- a/drivers/gpu
On Thu, Nov 24, 2022 at 01:14:48AM +0800, Randy Li wrote:
>
> > On Nov 24, 2022, at 12:42 AM, Daniel Vetter wrote:
> >
> > On Wed, Nov 23, 2022 at 10:58:11PM +0800, Jisheng Zhang wrote:
> >>> On Wed, Nov 23, 2022 at 05:19:57PM +0800, Hsia-Jun Li wrote
On Wed, 23 Nov 2022 at 18:05, Geert Uytterhoeven wrote:
>
> Hi Daniel,
>
> On Wed, Nov 23, 2022 at 5:57 PM Daniel Vetter wrote:
> > On Wed, Nov 23, 2022 at 05:43:10PM +0100, Geert Uytterhoeven wrote:
> > > As of commit eae06120f1974e1a ("drm: refuse ADDFB2
24,
> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
> { .format = DRM_FORMAT_XRGB,.depth = 24,
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
((__u64)((v) & 0xf) << 28) | \
> > +((__u64)((c) & 0x1) << 36)))
> > +
> > +#define DRM_FORMAT_MOD_SYNA_V4H1 \
> > + DRM_FORMAT_MOD_SYNA_MTR_LINEAR_2D(1, 1, 0, 0, 0, 0, 0)
> > +
> > +#define DRM_FOR
ted from Daniel Stone that seems to have been
> forgotten:
> https://lore.kernel.org/dri-devel/20210905122742.86029-1-dani...@collabora.com/
>
> It aimed mostly at userspace, but sounds to me like the coherency stuff
> could use a section of its own there?
Hm yeah it would be great to
On Wed, 23 Nov 2022 at 16:15, Christian König wrote:
>
> Am 23.11.22 um 16:08 schrieb Jason Gunthorpe:
> > On Wed, Nov 23, 2022 at 03:34:54PM +0100, Daniel Vetter wrote:
> >>> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> >>> index 1376a47fedeedb..41
On Wed, 23 Nov 2022 at 16:04, Jason Gunthorpe wrote:
>
> On Wed, Nov 23, 2022 at 03:28:27PM +0100, Daniel Vetter wrote:
>
> > > This patch is known to be broken in so many ways. It also has a major
> > > security hole that it ignores the PTE flags making the page
>
um 13:46 schrieb Jason Gunthorpe:
> > > > > On Wed, Nov 23, 2022 at 11:06:55AM +0100, Daniel Vetter wrote:
> > > > >
> > > > > > > Maybe a GFP flag to set the page reference count to zero or
> > > > > > > something
um 13:46 schrieb Jason Gunthorpe:
> > > > > On Wed, Nov 23, 2022 at 11:06:55AM +0100, Daniel Vetter wrote:
> > > > >
> > > > > > > Maybe a GFP flag to set the page reference count to zero or
> > > > > > > something
On Wed, 23 Nov 2022 at 10:39, Christian König
wrote:
>
> Am 23.11.22 um 10:30 schrieb Daniel Vetter:
> > On Wed, 23 Nov 2022 at 10:06, Christian König
> > wrote:
> >> Am 22.11.22 um 20:50 schrieb Daniel Vetter:
> >>> On Tue, 22 Nov 2022 at 20:34, Jason
On Wed, 23 Nov 2022 at 09:07, Thomas Zimmermann wrote:
>
> Hi
>
> Am 22.11.22 um 18:08 schrieb Daniel Vetter:
> > tldr; DMA buffers aren't normal memory, expecting that you can use
> > them like that (like calling get_user_pages works, or that they're
> >
On Wed, 23 Nov 2022 at 10:06, Christian König wrote:
> Am 22.11.22 um 20:50 schrieb Daniel Vetter:
> > On Tue, 22 Nov 2022 at 20:34, Jason Gunthorpe wrote:
> >> On Tue, Nov 22, 2022 at 08:29:05PM +0100, Daniel Vetter wrote:
> >>> You nuke all the ptes. Drivers that
On Tue, 22 Nov 2022 at 20:34, Jason Gunthorpe wrote:
> On Tue, Nov 22, 2022 at 08:29:05PM +0100, Daniel Vetter wrote:
> > You nuke all the ptes. Drivers that move have slightly more than a
> > bare struct file, they also have a struct address_space so that
> > invalidate_
broken irq restoration")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, 22 Nov 2022 at 19:50, Jason Gunthorpe wrote:
>
> On Tue, Nov 22, 2022 at 07:08:25PM +0100, Daniel Vetter wrote:
> > On Tue, 22 Nov 2022 at 19:04, Jason Gunthorpe wrote:
> > >
> > > On Tue, Nov 22, 2022 at 06:08:00PM +0100, Daniel Vetter wrote:
> >
On Tue, 22 Nov 2022 at 18:34, Christian König wrote:
> Am 22.11.22 um 15:36 schrieb Daniel Vetter:
> > On Fri, Nov 18, 2022 at 11:32:19AM -0800, Rob Clark wrote:
> >> On Thu, Nov 17, 2022 at 7:38 AM Nicolas Dufresne
> >> wrote:
> >>> Le jeudi 17 novembr
On Tue, 22 Nov 2022 at 19:04, Jason Gunthorpe wrote:
>
> On Tue, Nov 22, 2022 at 06:08:00PM +0100, Daniel Vetter wrote:
> > tldr; DMA buffers aren't normal memory, expecting that you can use
> > them like that (like calling get_user_pages works, or that they're
&
rnel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/
Acked-by: Christian König
Acked-by: Thomas Zimmermann
Cc: Thomas Zimmermann
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Ch
gt;
> 3. Require gitlab issues for new commits added. Improve tracking for
>removing the commits.
>
> Also use the stronger "must" for commit message requiring the
> justification for the commit being in topic/core-for-CI.
>
> Cc: Joonas Lahtinen
> Cc: Rodrigo
in the kernel driver and adjusting userspace to
find the right chardev, there should be zero changes need for an existing
drm based driver stack that gets ported to drivers/accel.
And of course if we realize there's issues as we add drivers, we can fix
things up. This is just to kick things off, not something that's going to
be cast in stone for all eternity.
Sonal, with that clarification/explanation, is this entire thing
reasonable in principal and you can drop an Ack onto the series?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
0f 05 <48> 3d 01 f0 ff ff 73
> 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:7ffd52951818 EFLAGS: 0246 ORIG_RAX:
> RAX: ffda RBX: 000f4240 RCX: 7f7cb1bbb049
> RDX: 2020 RSI: 20002200 RDI: 0003
> RBP: R08: 0001 R09: 0001
> R10: 7ffd52951290 R11: 0246 R12: e32c
> R13: 7ffd5295182c R14: 7ffd52951840 R15: 7ffd52951830
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Nov 18, 2022 at 03:51:37PM -0800, Randy Dunlap wrote:
> Correct grammar and make the use of the igt-tests more readable.
>
> Signed-off-by: Randy Dunlap
> Cc: Gabriela Bittencourt
> Cc: Rodrigo Siqueira
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Maarten
ick to infer format preferences ...
Anyway on the series, since it pushes in a direction I wanted to fix years
ago but gave up because too ambitious :-)
Acked-by: Daniel Vetter
>*/
> - if (!preferred_bpp)
> - preferred_bpp = dev->mode_config.preferred_depth;
>
/compute expects is still a model that
dma-buf needs to support on top, but that's a special case and pretty much
needs hw that supports such concurrent access without explicit handover
and fencing.
Aside from some historical accidents and still a few warts, I do think
dma-buf does support both of these models. Of course in the case of
gpu/drm drivers, userspace must know whats possible and act accordingly,
otherwise you just get to keep all the pieces.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ith my utter lack of understanding for TV
things (I never even had one in my entire life, that's how much I don't
care). But it seems to check all the design boxes around solving annoying
uapi/kms-config issues properly, so
Acked-in-principle-or-something-like-that-by: Daniel Vetter
Chee
mann (3):
> Revert "drm/fb-helper: Remove damage worker"
> Revert "drm/fb-helper: Schedule deferred-I/O worker after writing to
> framebuffer"
> Revert "drm/fb-helper: Perform damage handling in deferred-I/O helper"
On the series: Acked-by: Dan
> 1:
> https://elixir.bootlin.com/linux/latest/source/drivers/video/aperture.c#L199
> 2: https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L793
> 3: https://elixir.bootlin.com/linux/latest/source/drivers/base/platform.c#L751
> 4: https://elixir.bootlin.com/l
if (scr_readw(r) != vc->vc_video_erase_char)
> break;
> if (r != q && new_rows >= rows + logo_lines) {
> - save = kmalloc(array3_size(logo_lines, new_cols, 2),
> + save = kzalloc(array3_size(logo_lines, new_cols, 2),
> GFP_KERNEL);
> if (save) {
> int i = min(cols, new_cols);
> --
> 2.34.1
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ion to "enabled", interpret
> it as "desired".
>
> [1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3794
>
> Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
I think a doc patch which documents the guarantees we're trying to make
to be a legacy leftover. Let's just remove
> it.
>
> Cc: Inki Dae
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Krzysztof Kozlowski
> Signed-off-by: David Hildenbrand
Reviewed-by: Daniel Vetter
Plus ack for mergin
uffer issue has been resolved, FOLL_WRITE could
> again be set depending on the DMA direction.
>
> Cc: Hans Verkuil
> Cc: Marek Szyprowski
> Cc: Tomasz Figa
> Cc: Marek Szyprowski
> Cc: Mauro Carvalho Chehab
> Signed-off-by: David Hildenbrand
Also code I looked at w
LL_FORCE | FOLL_WRITE | FOLL_LONGTERM is no longer required
> for reliable R/O long-term pinning: FOLL_LONGTERM is sufficient. So stop
> using FOLL_FORCE, which is really only for ptrace access.
>
> Cc: Daniel Vetter
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
&
for ptrace access.
>
> Cc: Mauro Carvalho Chehab
> Signed-off-by: David Hildenbrand
I looked at this a while ago when going through some of the follow_pfn
stuff, so
Reviewed-by: Daniel Vetter
> ---
> drivers/media/v4l2-core/videobuf-dma-sg.c | 14 +-
> 1 file chang
r
> way" issue") which got merged into some enterprise distros, and there were
> not any such complaints. So most probably, we're fine.
>
> Signed-off-by: David Hildenbrand
I don't think my ack is any good for the implementation, but for the
driver side semantics t
of userspace processes starting with X that access
> this specific piece of the drm modesetting API. I suppose we might and
> if we have complaints about that I'd say let's try to fix it better.
>
> Sometimes engineering is hard, It was a big enough problem that a big
On Tue, Nov 15, 2022 at 10:30:01AM +0100, Andrzej Hajda wrote:
> On 13.07.2021 15:59, Daniel Vetter wrote:
> > Some vague evidences suggests this can go wrong. Try to prevent it by
> > holding the right mutex and clearing ->deferred_setup to make sure we
> > later on don&
led like normal pages.
> >
> > Be consistent with what other drivers do and use raw PFN based
> > mappings.
>
> Anyone up for reviewing this? Basically it moves etnaviv closer to what
> all the other DRM drivers are doing.
Reviewed-by: Daniel Vetter
Note that since you&#
On Tue, Nov 15, 2022 at 11:05:02AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.11.22 um 10:28 schrieb Daniel Vetter:
> > On Thu, Nov 10, 2022 at 02:55:18PM +0100, Thomas Zimmermann wrote:
> > > Schedule the deferred-I/O worker instead of the damage worker after
&g
On Thu, Nov 10, 2022 at 11:33:11AM -0800, Won Chung wrote:
> Hi Daniel,
>
> Thank you very much for a review.
>
> On Wed, Nov 9, 2022 at 3:54 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 08, 2022 at 06:50:04PM +, Won Chung wrote:
> > > Create a symlink
On Wed, Nov 09, 2022 at 05:44:37PM -0800, Jessica Zhang wrote:
>
>
> On 11/9/2022 5:59 AM, Daniel Vetter wrote:
> > On Wed, Nov 09, 2022 at 04:53:45PM +0300, Dmitry Baryshkov wrote:
> > > On 09/11/2022 16:52, Daniel Vetter wrote:
> > > > On Tue, Nov 08, 2022
st that
change. But split out is fine too.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 9 -
> include/drm/drm_fb_helper.h | 2 --
> 2 files changed, 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_f
deo/fbdev/core/fb_defio.c
> +++ b/drivers/video/fbdev/core/fb_defio.c
> @@ -332,3 +332,19 @@ void fb_deferred_io_cleanup(struct fb_info *info)
> mutex_destroy(&fbdefio->lock);
> }
> EXPORT_SYMBOL_GPL(fb_deferred_io_cleanup);
> +
> +void fb_deferred_io_flush(
t;drm/fb_helper: Minimize damage-helper
overhead"), which hasn't pulled the ->fb_dirty check all the way out
fully. It confused me quite a bit until I stitched the story together.
I think splitting this out would be best, but minimally explain this in
the commit message. Either way
R
rk_struct *work)
> +{
> + struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
> damage_work);
> +
> + drm_fb_helper_fb_dirty(helper);
Was pondering a bit the naming, but it fits the ->fb_dirty callback, so
at least consistent with wha
t;
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_fb_helper.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index e0
void fb_deferred_io_flush(struct fb_info *info)
> +{
> + struct fb_deferred_io *fbdefio = info->fbdefio;
> +
> + if (WARN_ON_ONCE(!fbdefio))
> + return; /* bug in driver logic */
> +
> + /*
> + * There's no requirement to perform the flush immediately. So
> + * schedule the worker with a delay and let a few more writes
> + * pile up.
> + */
> + schedule_delayed_work(&info->deferred_work, fbdefio->delay);
> +}
> +EXPORT_SYMBOL_GPL(fb_deferred_io_flush);
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index bcb8658f5b64d..54b3b3e13522f 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -663,6 +663,7 @@ extern void fb_deferred_io_open(struct fb_info *info,
> struct inode *inode,
> struct file *file);
> extern void fb_deferred_io_cleanup(struct fb_info *info);
> +extern void fb_deferred_io_flush(struct fb_info *info);
> extern int fb_deferred_io_fsync(struct file *file, loff_t start,
> loff_t end, int datasync);
>
> --
> 2.38.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
901 - 1000 of 8060 matches
Mail list logo
