date:20250319

From: Rob Clark 

For VM_BIND, in the first step, we just want to get the backing pages,
but defer creating the vma until the map/unmap/ops are evaluated.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem_submit.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 998cedb24941..c65f3a6a5256 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -292,12 +292,16 @@ static int submit_fence_sync(struct msm_gem_submit 
*submit)
return ret;
 }
 
-static int submit_pin_objects(struct msm_gem_submit *submit)
+static int submit_pin_vmas(struct msm_gem_submit *submit)
 {
-   struct msm_drm_private *priv = submit->dev->dev_private;
-   int i, ret = 0;
+   int ret = 0;
 
-   for (i = 0; i < submit->nr_bos; i++) {
+   /*
+* First loop, before holding the LRU lock, avoids holding the
+* LRU lock while calling msm_gem_pin_vma_locked (which could
+* trigger get_pages())
+*/
+   for (int i = 0; i < submit->nr_bos; i++) {
struct drm_gem_object *obj = submit->bos[i].obj;
struct drm_gpuva *vma;
 
@@ -315,6 +319,13 @@ static int submit_pin_objects(struct msm_gem_submit 
*submit)
submit->bos[i].iova = vma->va.addr;
}
 
+   return ret;
+}
+
+static void submit_pin_objects(struct msm_gem_submit *submit)
+{
+   struct msm_drm_private *priv = submit->dev->dev_private;
+
/*
 * A second loop while holding the LRU lock (a) avoids 
acquiring/dropping
 * the LRU lock for each individual bo, while (b) avoiding holding the
@@ -323,14 +334,12 @@ static int submit_pin_objects(struct msm_gem_submit 
*submit)
 * could trigger deadlock with the shrinker).
 */
mutex_lock(&priv->lru.lock);
-   for (i = 0; i < submit->nr_bos; i++) {
+   for (int i = 0; i < submit->nr_bos; i++) {
msm_gem_pin_obj_locked(submit->bos[i].obj);
}
mutex_unlock(&priv->lru.lock);
 
submit->bos_pinned = true;
-
-   return ret;
 }
 
 static void submit_unpin_objects(struct msm_gem_submit *submit)
@@ -760,10 +769,12 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
*data,
goto out;
}
 
-   ret = submit_pin_objects(submit);
+   ret = submit_pin_vmas(submit);
if (ret)
goto out;
 
+   submit_pin_objects(submit);
+
for (i = 0; i < args->nr_cmds; i++) {
struct drm_gem_object *obj;
uint64_t iova;
-- 
2.48.1

[PATCH v2 03/34] drm/gpuvm: Allow VAs to hold soft reference to BOs

From: Rob Clark 

Eases migration for drivers where VAs don't hold hard references to
their associated BO, avoiding reference loops.

In particular, msm uses soft references to optimistically keep around
mappings until the BO is distroyed.  Which obviously won't work if the
VA (the mapping) is holding a reference to the BO.

By making this a per-VM flag, we can use normal hard-references for
mappings in a "VM_BIND" managed VM, but soft references in other cases,
such as kernel-internal VMs (for display scanout, etc).

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_gpuvm.c |  8 ++--
 include/drm/drm_gpuvm.h | 12 ++--
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index c9bf18119a86..681dc58e9160 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1482,7 +1482,9 @@ drm_gpuvm_bo_create(struct drm_gpuvm *gpuvm,
 
vm_bo->vm = drm_gpuvm_get(gpuvm);
vm_bo->obj = obj;
-   drm_gem_object_get(obj);
+
+   if (!(gpuvm->flags & DRM_GPUVM_VA_WEAK_REF))
+   drm_gem_object_get(obj);
 
kref_init(&vm_bo->kref);
INIT_LIST_HEAD(&vm_bo->list.gpuva);
@@ -1504,6 +1506,7 @@ drm_gpuvm_bo_destroy(struct kref *kref)
const struct drm_gpuvm_ops *ops = gpuvm->ops;
struct drm_gem_object *obj = vm_bo->obj;
bool lock = !drm_gpuvm_resv_protected(gpuvm);
+   bool unref = !(gpuvm->flags & DRM_GPUVM_VA_WEAK_REF);
 
drm_gpuvm_bo_list_del(vm_bo, extobj, lock);
drm_gpuvm_bo_list_del(vm_bo, evict, lock);
@@ -1519,7 +1522,8 @@ drm_gpuvm_bo_destroy(struct kref *kref)
kfree(vm_bo);
 
drm_gpuvm_put(gpuvm);
-   drm_gem_object_put(obj);
+   if (unref)
+   drm_gem_object_put(obj);
 }
 
 /**
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index 00d4e43b76b6..13ab087a45fa 100644
--- a/include/drm/drm_gpuvm.h
+++ b/include/drm/drm_gpuvm.h
@@ -205,10 +205,18 @@ enum drm_gpuvm_flags {
 */
DRM_GPUVM_RESV_PROTECTED = BIT(0),
 
+   /**
+* @DRM_GPUVM_VA_WEAK_REF:
+*
+* Flag indicating that the &drm_gpuva (or more correctly, the
+* &drm_gpuvm_bo) only holds a weak reference to the &drm_gem_object.
+*/
+   DRM_GPUVM_VA_WEAK_REF = BIT(1),
+
/**
 * @DRM_GPUVM_USERBITS: user defined bits
 */
-   DRM_GPUVM_USERBITS = BIT(1),
+   DRM_GPUVM_USERBITS = BIT(2),
 };
 
 /**
@@ -651,7 +659,7 @@ struct drm_gpuvm_bo {
 
/**
 * @obj: The &drm_gem_object being mapped in @vm. This is a reference
-* counted pointer.
+* counted pointer, unless the &DRM_GPUVM_VA_WEAK_REF flag is set.
 */
struct drm_gem_object *obj;
 
-- 
2.48.1

Re: [PATCH v2 2/3] rust: alloc: add Vec::resize method

2025-03-19 Thread Miguel Ojeda

On Wed, Mar 19, 2025 at 5:13 PM Tamir Duberstein  wrote:
>
> No, I meant avoiding the check. The existing code already explicitly
> checks `new_len > self.len()` before evaluating `new_len -
> self.len()`. This means the check occurs twice. `checked_sub` reduces
> the number of checks by 1. Perhaps my wording could have been clearer
> ("avoid *an* underflow check").

Ah, you mean in the function you suggested, I see.

I think it they all may compile down to the same thing, whether
overflows checks are enabled or not, and whether the version in the
patch or `checked_sub` is used or not. At least in a quick Compiler
Explorer test it seems so, but I didn't check in an actual kernel
build.

The implicit check is gated behind the other one, so that one can be
removed, even if values are unknown -- we always have optimizations
enabled, even under "debug" builds (assuming "debug" means overflow
checking enabled).

Cheers,
Miguel

Re: [PATCH v2 4/4] drm/panthor: Display heap chunk entries in DebugFS GEMS file

2025-03-19 Thread Boris Brezillon

On Wed, 19 Mar 2025 15:03:19 +
Adrián Larumbe  wrote:

> Expand the driver's DebugFS GEMS file to display entries for the heap
> chunks' GEM objects, both those allocated at heap creation time through an
> ioctl(), or in response to a tiler OOM event.
> 
> Signed-off-by: Adrián Larumbe 
> ---
>  drivers/gpu/drm/panthor/panthor_gem.c  | 22 +++---
>  drivers/gpu/drm/panthor/panthor_gem.h  |  2 ++
>  drivers/gpu/drm/panthor/panthor_heap.c |  3 +++
>  3 files changed, 16 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c 
> b/drivers/gpu/drm/panthor/panthor_gem.c
> index f7eb413d88e7..252979473fdf 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.c
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -22,16 +22,6 @@ static void panthor_gem_debugfs_bo_init(struct 
> panthor_gem_object *bo)
>   get_task_comm(bo->gems.creator.process_name, current->group_leader);
>  }
>  
> -static void panthor_gem_debugfs_bo_add(struct panthor_gem_object *bo)
> -{
> - struct panthor_device *ptdev =  container_of(bo->base.base.dev,
> -  struct panthor_device, 
> base);
> -
> - mutex_lock(&ptdev->gems.lock);
> - list_add_tail(&bo->gems.node, &ptdev->gems.node);
> - mutex_unlock(&ptdev->gems.lock);
> -}
> -
>  static void panthor_gem_debugfs_bo_rm(struct panthor_gem_object *bo)
>  {
>   struct panthor_device *ptdev = container_of(bo->base.base.dev,
> @@ -44,10 +34,20 @@ static void panthor_gem_debugfs_bo_rm(struct 
> panthor_gem_object *bo)
>   list_del_init(&bo->gems.node);
>   mutex_unlock(&ptdev->gems.lock);
>  }
> +
> +void panthor_gem_debugfs_bo_add(struct panthor_gem_object *bo)
> +{
> + struct panthor_device *ptdev =  container_of(bo->base.base.dev,
> +  struct panthor_device, 
> base);
> +
> + mutex_lock(&ptdev->gems.lock);
> + list_add_tail(&bo->gems.node, &ptdev->gems.node);
> + mutex_unlock(&ptdev->gems.lock);
> +}
>  #else
>  static void panthor_gem_debugfs_bo_init(struct panthor_gem_object *bo) {}
> -static void panthor_gem_debugfs_bo_add(struct panthor_gem_object *bo) {}
>  static void panthor_gem_debugfs_bo_rm(struct panthor_gem_object *bo) {}
> +void panthor_gem_debugfs_bo_add(struct panthor_gem_object *bo) {}

Let's just define all these helpers as inline functions in
panthor_gem.h in patch 3.

>  #endif
>  
>  static void panthor_gem_free_object(struct drm_gem_object *obj)
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.h 
> b/drivers/gpu/drm/panthor/panthor_gem.h
> index 7c896ec35801..e132f14bbef8 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.h
> +++ b/drivers/gpu/drm/panthor/panthor_gem.h
> @@ -132,6 +132,8 @@ panthor_gem_create_with_handle(struct drm_file *file,
>  void panthor_gem_bo_set_label(struct drm_gem_object *obj, const char *label);
>  void panthor_gem_kernel_bo_set_label(struct panthor_kernel_bo *bo, const 
> char *label);
>  
> +void panthor_gem_debugfs_bo_add(struct panthor_gem_object *bo);
> +
>  static inline u64
>  panthor_kernel_bo_gpuva(struct panthor_kernel_bo *bo)
>  {
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c 
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index db0285ce5812..73cf43eb4a7b 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -180,6 +180,9 @@ static int panthor_alloc_heap_chunk(struct panthor_device 
> *ptdev,
>   heap->chunk_count++;
>   mutex_unlock(&heap->lock);
>  
> + panthor_gem_kernel_bo_set_label(chunk->bo, "\"Tiler heap chunk\"");
> + panthor_gem_debugfs_bo_add(to_panthor_bo(chunk->bo->obj));

I'd be tempted to label all the kernel BOs, not just the heap chunks,
and if we do that, we're probably better off changing the
kernel_bo_create() prototype to pass a label.

> +
>   return 0;
>  
>  err_destroy_bo:

Re: [PATCH] drm/panel/sharp-ls043t1le01: Use _multi variants

2025-03-19 Thread Anusha Srivatsa

On Tue, 18 Mar 2025 at 12:00 PM, Dmitry Baryshkov <
dmitry.barysh...@oss.qualcomm.com> wrote:

> On Tue, 18 Mar 2025 at 18:55, Anusha Srivatsa  wrote:
> >
> > On Sun, Mar 16, 2025 at 7:32 PM Dmitry Baryshkov <
> dmitry.barysh...@oss.qualcomm.com> wrote:
> >>
> >> On Sun, Mar 16, 2025 at 02:58:22PM -0400, Anusha Srivatsa wrote:
>
> >> > ---
> >> >  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 36
> ++---
> >> >  1 file changed, 14 insertions(+), 22 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> >> > index
> 729cbb0d8403ff7c0c4b9d21774909cc298904a2..9803eaf18e95d70742ece88e82932751476fdda8
> 100644
> >> > --- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> >> > +++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
> >> > @@ -36,15 +36,14 @@ static inline struct sharp_nt_panel
> *to_sharp_nt_panel(struct drm_panel *panel)
> >> >  static int sharp_nt_panel_init(struct sharp_nt_panel *sharp_nt)
> >> >  {
> >> >   struct mipi_dsi_device *dsi = sharp_nt->dsi;
> >> > + struct mipi_dsi_multi_context dsi_ctx = { .dsi = dsi };
> >> >   int ret;
> >> >
> >> >   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> >> >
> >> > - ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
> >> > - if (ret < 0)
> >> > - return ret;
> >> > + mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
> >> >
> >> > - msleep(120);
> >> > + mipi_dsi_msleep(&dsi_ctx, 120);
> >> >
> >> >   /* Novatek two-lane operation */
> >> >   ret = mipi_dsi_dcs_write(dsi, 0xae, (u8[]){ 0x03 }, 1);
> >>
> >> Anusha. Please. Start reviewing your patches before you send them. This
> >> is a MIPI DSI call. And it wasn't switched to _multi / context. You
> >> should have cought this. I don't know why you didn't. Please review and
> >> check your code before sending it upstream.
> >
> >
> > Actually , mipi_dsi_dcs_write() doesnt have a _multi() variant. There
> are _multi() variants for other writes: mipi_dsi_dcs_write_buffer() has
> mipi_dsi_dcs_write_buffer_multi(), mipi_dsi_generic_write() has
> mipi_dsi_generic_write_multi() but not the one used above.
>
> That doesn't mean that it can be left unconverted. You can use
> mipi_dsi_dcs_write_buffer_multi().
>

Ah got it . Makes sense.

>
> P.S. Please wrap your replies ont some useful boundary (72-75 chars is
> the recommended value).
>

Sure.

Anusha

>
> --
> With best wishes
> Dmitry
>
>

Re: [PATCH v2 2/4] drm/panthor: Add driver IOCTL for setting BO labels

2025-03-19 Thread Boris Brezillon

On Wed, 19 Mar 2025 15:03:17 +
Adrián Larumbe  wrote:

> Allow UM to label a BO for which it possesses a DRM handle.
> 
> Signed-off-by: Adrián Larumbe 
> ---
>  drivers/gpu/drm/panthor/panthor_drv.c | 37 +++
>  include/uapi/drm/panthor_drm.h| 19 ++
>  2 files changed, 56 insertions(+)
> 
> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c 
> b/drivers/gpu/drm/panthor/panthor_drv.c
> index 310bb44abe1a..e91acf132e06 100644
> --- a/drivers/gpu/drm/panthor/panthor_drv.c
> +++ b/drivers/gpu/drm/panthor/panthor_drv.c
> @@ -1330,6 +1330,41 @@ static int panthor_ioctl_vm_get_state(struct 
> drm_device *ddev, void *data,
>   return 0;
>  }
>  
> +static int panthor_ioctl_bo_set_label(struct drm_device *ddev, void *data,
> +   struct drm_file *file)
> +{
> + struct drm_panthor_bo_set_label *args = data;
> + struct drm_gem_object *obj;
> + const char *label;
> + unsigned long len;
> + int ret = 0;
> +
> + obj = drm_gem_object_lookup(file, args->handle);
> + if (!obj)
> + return -ENOENT;
> +
> + if (args->size && args->label) {
> + len = (args->size < PAGE_SIZE) ? args->size : PAGE_SIZE;

Let's return -E2BIG or -EINVAL if args->size is bigger exceeds our limit
instead of pretending the label was stored.

> + label = strndup_user(u64_to_user_ptr(args->label), len);
> + if (IS_ERR(label)) {
> + ret = PTR_ERR(label);
> + goto err_label;
> + }
> + } else if (args->size && !args->label) {
> + ret = -EINVAL;
> + goto err_label;
> + } else {
> + label = NULL;
> + }
> +
> + panthor_gem_bo_set_label(obj, label);
> +
> +err_label:
> + drm_gem_object_put(obj);
> +
> + return ret;
> +}
> +
>  static int
>  panthor_open(struct drm_device *ddev, struct drm_file *file)
>  {
> @@ -1399,6 +1434,7 @@ static const struct drm_ioctl_desc 
> panthor_drm_driver_ioctls[] = {
>   PANTHOR_IOCTL(TILER_HEAP_CREATE, tiler_heap_create, DRM_RENDER_ALLOW),
>   PANTHOR_IOCTL(TILER_HEAP_DESTROY, tiler_heap_destroy, DRM_RENDER_ALLOW),
>   PANTHOR_IOCTL(GROUP_SUBMIT, group_submit, DRM_RENDER_ALLOW),
> + PANTHOR_IOCTL(BO_SET_LABEL, bo_set_label, DRM_RENDER_ALLOW),
>  };
>  
>  static int panthor_mmap(struct file *filp, struct vm_area_struct *vma)
> @@ -1508,6 +1544,7 @@ static void panthor_debugfs_init(struct drm_minor 
> *minor)
>   * - 1.2 - adds DEV_QUERY_GROUP_PRIORITIES_INFO query
>   *   - adds PANTHOR_GROUP_PRIORITY_REALTIME priority
>   * - 1.3 - adds DRM_PANTHOR_GROUP_STATE_INNOCENT flag
> + * - 1.4 - adds DRM_IOCTL_PANTHOR_BO_SET_LABEL ioctl
>   */
>  static const struct drm_driver panthor_drm_driver = {
>   .driver_features = DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ |
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index 97e2c4510e69..26b52f147360 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -127,6 +127,9 @@ enum drm_panthor_ioctl_id {
>  
>   /** @DRM_PANTHOR_TILER_HEAP_DESTROY: Destroy a tiler heap. */
>   DRM_PANTHOR_TILER_HEAP_DESTROY,
> +
> + /** @DRM_PANTHOR_BO_SET_LABEL: Label a BO. */
> + DRM_PANTHOR_BO_SET_LABEL,
>  };
>  
>  /**
> @@ -977,6 +980,20 @@ struct drm_panthor_tiler_heap_destroy {
>   __u32 pad;
>  };
>  
> +/**
> + * struct drm_panthor_bo_set_label - Arguments passed to 
> DRM_IOCTL_PANTHOR_BO_SET_LABEL
> + */
> +struct drm_panthor_bo_set_label {
> + /** @handle: Handle of the buffer object to label. */
> + __u32 handle;
> +
> + /** @size: Length of the label, including the NULL terminator. */
> + __u32 size;
> +
> + /** @label: User pointer to a NULL-terminated string */
> + __u64 label;
> +};
> +
>  /**
>   * DRM_IOCTL_PANTHOR() - Build a Panthor IOCTL number
>   * @__access: Access type. Must be R, W or RW.
> @@ -1019,6 +1036,8 @@ enum {
>   DRM_IOCTL_PANTHOR(WR, TILER_HEAP_CREATE, tiler_heap_create),
>   DRM_IOCTL_PANTHOR_TILER_HEAP_DESTROY =
>   DRM_IOCTL_PANTHOR(WR, TILER_HEAP_DESTROY, tiler_heap_destroy),
> + DRM_IOCTL_PANTHOR_BO_SET_LABEL =
> + DRM_IOCTL_PANTHOR(WR, BO_SET_LABEL, bo_set_label),
>  };
>  
>  #if defined(__cplusplus)

Re: imx8mp: HDMI display blank/black problems

2025-03-19 Thread Frieder Schrempf

Am 30.10.24 um 9:20 PM schrieb Saravana Kannan:
> On Wed, Oct 30, 2024 at 10:28 AM Adam Ford  wrote:
>>
>> On Wed, Oct 30, 2024 at 4:01 AM Frieder Schrempf
>>  wrote:
>>>
>>> Hi Johannes,
>>>
>>> On 25.10.24 10:05 AM, mailingli...@johanneskirchmair.de wrote:
 [Sie erhalten nicht häufig E-Mails von mailingli...@johanneskirchmair.de. 
 Weitere Informationen, warum dies wichtig ist, finden Sie unter 
 https://aka.ms/LearnAboutSenderIdentification ]

 Hey,
 We had some problems with the hdmi on the imx8mp and wanted to leave, what 
 we found out about it, somewhere for others to find it.

 The problem was that our hdmi display sometimes stayed blank after hot 
 plugging and sometimes at startup. On older kernel versions 6.6 we did not 
 have the problem with the not mainlined hdmi patches.
 We tracked the commit down that introduced the problem for us. It was the 
 following “driver core: Enable fw_devlink=rpm by default”  
 https://lore.kernel.org/lkml/20231113220948.80089-1-sarava...@google.com/
 So we switched back to FW_DEVLINK_FLAGS_ON via kernel parameter. Don’t 
 really understand what the problem with RPM is.

 So, this information is just for reference. Maybe someone has an idea what 
 is going on here. And how to fix the problem in a more proper way.
>>>
>>> Thanks for investigating and sharing your results!
>>>
>>> I'm seeing the same symptoms and previously found out that this is
>>> related to LCDIF underrun errors. See [1] for more information.
>>>
>>> Adam has also started this thread: [2].
>>>
>>> Anyway, knowing that this is related to fw_devlink=rpm is really
>>> helpful. I just tried with fw_devlink=on and wasn't able to see any
>>> issues anymore. So this confirms your findings.
>>
>> I was off in the weeds thinking there was something wrong in timing
>> and/or a race condition around the PLL or something.  This is good
>> news.
>> Please forgive my ignorance, what does fw_devlink do?  Is there
>> something we can do in the driver itself to force its behavior?
> 
> fw_devlink figures out supplier/consumer dependencies between devices
> and creates device links between them. This ensures proper
> probe/suspend/resume/shutdown/runtime PM ordering.
> 
> fw_devlink=rpm vs on means "enforce all of these" vs "enforce all of
> these except runtime PM".
> 
>> adam
>>>
>>> I hope that some of the driver framework and runtime PM experts can help
>>> to find out what is actually wrong and how the correct fix might look like.
>>>
>>> I'm also CC-ing Saravana who authored the change from fw_devlink=on to
>>> fw_devlink=rpm to see if they have anything to add.
> 
> When fw_devlink=rpm, you'll have device links created between
> consumers and suppliers with the DL_FLAG_PM_RUNTIME flag set. So
> before your device is runtime resumed, it'll make sure all your
> suppliers are resumed first.
> 
> My guess is that there is some issue in the runtime PM handling in
> these drivers. I don't have enough context to provide further insight.

I bet you are right. I tried to have a closer look but unfortunately I
didn't make any progress.

The drivers involved are lcdif_drv.c, imx8mp-hdmi-tx.c and
phy-fsl-samsung-hdmi.c.

As we see a "LCDIF Underrun Error" with fw_devlink=rpm my first guess
would be that the suppliers of LCDIF are maybe turned on in the wrong order.

Lucas, Marek: As the main authors of these drivers, do you think you
could help a little with further debugging? Any ideas?

Thanks!

Re: [PATCH 2/7] drm/gem-shmem: Export VM ops functions

Am 18.03.25 um 20:22 schrieb Daniel Almeida:
> From: Asahi Lina 
>
> There doesn't seem to be a way for the Rust bindings to get a
> compile-time constant reference to drm_gem_shmem_vm_ops, so we need to
> duplicate that structure in Rust... this isn't nice...

Well "isn't nice" is an understatement. We can have that as a short term hack, 
but I don't think that this is a doable long term solution.

For this particular case here it most likely doesn't matter, but operation 
pointer structures are often used to identify a certain class of object.

So exporting the functions and then re-creating the constant operation pointer 
structure in Rust doesn't work in some cases.

Regards,
Christian.

>
> Signed-off-by: Asahi Lina 
> Signed-off-by: Daniel Almeida 
> ---
>  drivers/gpu/drm/drm_gem_shmem_helper.c | 9 ++---
>  include/drm/drm_gem_shmem_helper.h | 3 +++
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 
> ec89e9499f5f02a2a35713669bf649dd2abb9938..be310db5863871604f3502ad1f419937d4c20a84
>  100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -535,7 +535,7 @@ int drm_gem_shmem_dumb_create(struct drm_file *file, 
> struct drm_device *dev,
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_shmem_dumb_create);
>  
> -static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
> +vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
>  {
>   struct vm_area_struct *vma = vmf->vma;
>   struct drm_gem_object *obj = vma->vm_private_data;
> @@ -564,8 +564,9 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault 
> *vmf)
>  
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_fault);
>  
> -static void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
> +void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
>  {
>   struct drm_gem_object *obj = vma->vm_private_data;
>   struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> @@ -586,8 +587,9 @@ static void drm_gem_shmem_vm_open(struct vm_area_struct 
> *vma)
>  
>   drm_gem_vm_open(vma);
>  }
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_open);
>  
> -static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
> +void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>  {
>   struct drm_gem_object *obj = vma->vm_private_data;
>   struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> @@ -598,6 +600,7 @@ static void drm_gem_shmem_vm_close(struct vm_area_struct 
> *vma)
>  
>   drm_gem_vm_close(vma);
>  }
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_close);
>  
>  const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>   .fault = drm_gem_shmem_fault,
> diff --git a/include/drm/drm_gem_shmem_helper.h 
> b/include/drm/drm_gem_shmem_helper.h
> index 
> d22e3fb53631ab655748d7f6c628ffdb402f6324..b70d3cc35bd194e7cd718bee220408b5dda568bf
>  100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -132,6 +132,9 @@ void drm_gem_shmem_print_info(const struct 
> drm_gem_shmem_object *shmem,
> struct drm_printer *p, unsigned int indent);
>  
>  extern const struct vm_operations_struct drm_gem_shmem_vm_ops;
> +vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf);
> +void drm_gem_shmem_vm_open(struct vm_area_struct *vma);
> +void drm_gem_shmem_vm_close(struct vm_area_struct *vma);
>  
>  /*
>   * GEM object functions
>

Re:Re: [PATCH v5 04/16] drm/atomic: Introduce helper to lookup connector by encoder

2025-03-19 Thread Andy Yan

Hello，

At 2025-03-19 03:00:29, "Dmitry Baryshkov"  
wrote:
>On Tue, Mar 18, 2025 at 04:51:19PM +0100, Maxime Ripard wrote:
>> On Fri, Mar 14, 2025 at 08:28:22PM +0200, Dmitry Baryshkov wrote:
>> > On Fri, Mar 14, 2025 at 06:40:24PM +0100, Maxime Ripard wrote:
>> > > On Fri, Mar 14, 2025 at 09:59:36AM +0200, Dmitry Baryshkov wrote:
>> > > > On Fri, Mar 14, 2025 at 08:45:17AM +0100, Maxime Ripard wrote:
>> > > > > On Fri, Mar 14, 2025 at 07:52:35AM +0200, Dmitry Baryshkov wrote:
>> > > > > > On Fri, Mar 14, 2025 at 08:50:29AM +0800, Andy Yan wrote:
>> > > > > > > At 2025-03-13 19:55:33, "Maxime Ripard"  
>> > > > > > > wrote:
>> > > > > > > >Hi,
>> > > > > > > >
>> > > > > > > >On Thu, Mar 13, 2025 at 04:09:54PM +0800, Andy Yan wrote:
>> > > > > > > >> At 2025-03-05 19:55:19, "Andy Yan"  wrote:
>> > > > > > > >> >At 2025-03-04 19:10:47, "Maxime Ripard"  
>> > > > > > > >> >wrote:
>> > > > > > > >> >>With the bridges switching over to drm_bridge_connector, 
>> > > > > > > >> >>the direct
>> > > > > > > >> >>association between a bridge driver and its connector was 
>> > > > > > > >> >>lost.
>> > > > > > > >> >>
>> > > > > > > >> >>This is mitigated for atomic bridge drivers by the fact you 
>> > > > > > > >> >>can access
>> > > > > > > >> >>the encoder, and then call 
>> > > > > > > >> >>drm_atomic_get_old_connector_for_encoder() or
>> > > > > > > >> >>drm_atomic_get_new_connector_for_encoder() with 
>> > > > > > > >> >>drm_atomic_state.
>> > > > > > > >> >>
>> > > > > > > >> >>This was also made easier by providing drm_atomic_state 
>> > > > > > > >> >>directly to all
>> > > > > > > >> >>atomic hooks bridges can implement.
>> > > > > > > >> >>
>> > > > > > > >> >>However, bridge drivers don't have a way to access 
>> > > > > > > >> >>drm_atomic_state
>> > > > > > > >> >>outside of the modeset path, like from the hotplug 
>> > > > > > > >> >>interrupt path or any
>> > > > > > > >> >>interrupt handler.
>> > > > > > > >> >>
>> > > > > > > >> >>Let's introduce a function to retrieve the connector 
>> > > > > > > >> >>currently assigned
>> > > > > > > >> >>to an encoder, without using drm_atomic_state, to make 
>> > > > > > > >> >>these drivers'
>> > > > > > > >> >>life easier.
>> > > > > > > >> >>
>> > > > > > > >> >>Reviewed-by: Dmitry Baryshkov 
>> > > > > > > >> >>Co-developed-by: Simona Vetter 
>> > > > > > > >> >>Signed-off-by: Maxime Ripard 
>> > > > > > > >> >>---
>> > > > > > > >> >> drivers/gpu/drm/drm_atomic.c | 45 
>> > > > > > > >> >> 
>> > > > > > > >> >> include/drm/drm_atomic.h |  3 +++
>> > > > > > > >> >> 2 files changed, 48 insertions(+)
>> > > > > > > >> >>
>> > > > > > > >> >>diff --git a/drivers/gpu/drm/drm_atomic.c 
>> > > > > > > >> >>b/drivers/gpu/drm/drm_atomic.c
>> > > > > > > >> >>index 
>> > > > > > > >> >>9ea2611770f43ce7ccba410406d5f2c528aab022..b926b132590e78f8d41d48eb4da4bccf170ee236
>> > > > > > > >> >> 100644
>> > > > > > > >> >>--- a/drivers/gpu/drm/drm_atomic.c
>> > > > > > > >> >>+++ b/drivers/gpu/drm/drm_atomic.c
>> > > > > > > >> >>@@ -985,10 +985,55 @@ 
>> > > > > > > >> >>drm_atomic_get_new_connector_for_encoder(const struct 
>> > > > > > > >> >>drm_atomic_state *state,
>> > > > > > > >> >> 
>> > > > > > > >> >>return NULL;
>> > > > > > > >> >> }
>> > > > > > > >> >> EXPORT_SYMBOL(drm_atomic_get_new_connector_for_encoder);
>> > > > > > > >> >> 
>> > > > > > > >> >>+/**
>> > > > > > > >> >>+ * drm_atomic_get_connector_for_encoder - Get connector 
>> > > > > > > >> >>currently assigned to an encoder
>> > > > > > > >> >>+ * @encoder: The encoder to find the connector of
>> > > > > > > >> >>+ * @ctx: Modeset locking context
>> > > > > > > >> >>+ *
>> > > > > > > >> >>+ * This function finds and returns the connector currently 
>> > > > > > > >> >>assigned to
>> > > > > > > >> >>+ * an @encoder.
>> > > > > > > >> >>+ *
>> > > > > > > >> >>+ * Returns:
>> > > > > > > >> >>+ * The connector connected to @encoder, or an error 
>> > > > > > > >> >>pointer otherwise.
>> > > > > > > >> >>+ * When the error is EDEADLK, a deadlock has been detected 
>> > > > > > > >> >>and the
>> > > > > > > >> >>+ * sequence must be restarted.
>> > > > > > > >> >>+ */
>> > > > > > > >> >>+struct drm_connector *
>> > > > > > > >> >>+drm_atomic_get_connector_for_encoder(const struct 
>> > > > > > > >> >>drm_encoder *encoder,
>> > > > > > > >> >>+struct 
>> > > > > > > >> >>drm_modeset_acquire_ctx *ctx)
>> > > > > > > >> >>+{
>> > > > > > > >> >>+   struct drm_connector_list_iter conn_iter;
>> > > > > > > >> >>+   struct drm_connector *out_connector = ERR_PTR(-EINVAL);
>> > > > > > > >> >>+   struct drm_connector *connector;
>> > > > > > > >> >>+   struct drm_device *dev = encoder->dev;
>> > > > > > > >> >>+   int ret;
>> > > > > > > >> >>+
>> > > > > > > >> >>+   ret = 
>> > > > > > > >> >>drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
>> > > > > > > >> >>+   if (ret)
>> > > > > > > >> >>+   return

Re: [PATCH v4 0/6] TEE subsystem for restricted dma-buf allocations

2025-03-19 Thread Jens Wiklander

Hi,

On Tue, Mar 18, 2025 at 7:38 PM Nicolas Dufresne  wrote:
>
> Le mardi 04 mars 2025 à 13:15 +0530, Sumit Garg a écrit :
> > On Tue, Mar 04, 2025 at 08:17:23AM +0100, Jens Wiklander wrote:
> > > Hi Daniel,
> > >
> > > On Fri, Feb 21, 2025 at 3:12 PM Daniel Stone  wrote:
> > > >
> > > > Hi Sumit,
> > > >
> > > > On Fri, 21 Feb 2025 at 11:24, Sumit Garg  wrote:
> > > > > On Tue, 18 Feb 2025 at 21:52, Daniel Stone  
> > > > > wrote:
> > > > > > dma-heaps was created to solve the problem of having too many
> > > > > > 'allocate $n bytes from $specialplace' uAPIs. The proliferation was
> > > > > > painful and making it difficult for userspace to do what it needed 
> > > > > > to
> > > > > > do. Userspace doesn't _yet_ make full use of it, but the solution is
> > > > > > to make userspace make full use of it, not to go create entirely
> > > > > > separate allocation paths for unclear reasons.
> > > > > >
> > > > > > Besides, I'm writing this from a platform that implements SVP not 
> > > > > > via
> > > > > > TEE. I've worked on platforms which implement SVP without any TEE,
> > > > > > where the TEE implementation would be at best a no-op stub, and at
> > > > > > worst flat-out impossible.
> > > > >
> > > > > Can you elaborate the non-TEE use-case for Secure Video Path (SVP) a
> > > > > bit more? As to how the protected/encrypted media content pipeline
> > > > > works? Which architecture support does your use-case require? Is there
> > > > > any higher privileged level firmware interaction required to perform
> > > > > media content decryption into restricted memory? Do you plan to
> > > > > upstream corresponding support in near future?
> > > >
> > > > You can see the MTK SVP patches on list which use the MTK SMC to 
> > > > mediate it.
> > > >
> > > > There are TI Jacinto platforms which implement a 'secure' area
> > > > configured statically by (IIRC) BL2, with static permissions defined
> > > > for each AXI endpoint, e.g. CPU write + codec RW + dispc read. I've
> > > > heard of another SoC vendor doing the same, but I don't think I can
> > > > share those details. There is no TEE interaction.
> > > >
> > > > I'm writing this message from an AMD laptop which implements
> > > > restricted content paths outside of TEE. I don't have the full picture
> > > > of how SVP is implemented on AMD systems, but I do know that I don't
> > > > have any TEE devices exposed.
> > > >
> > > > > Let me try to elaborate on the Secure Video Path (SVP) flow requiring
> > > > > a TEE implementation (in general terms a higher privileged firmware
> > > > > managing the pipeline as the kernel/user-space has no access
> > > > > permissions to the plain text media content):
> > > > >
> > > > > - [...]
> > > >
> > > > Yeah, I totally understand the TEE usecase. I think that TEE is a good
> > > > design to implement this. I think that TEE should be used for SVP
> > > > where it makes sense.
> > > >
> > > > Please understand that I am _not_ arguing that no-one should use TEE 
> > > > for SVP!
> > > >
> > > > > > So, again, let's
> > > > > > please turn this around: _why_ TEE? Who benefits from exposing this 
> > > > > > as
> > > > > > completely separate to the more generic uAPI that we specifically
> > > > > > designed to handle things like this?
> > > > >
> > > > > The bridging between DMA heaps and TEE would still require user-space
> > > > > to perform an IOCTL into TEE to register the DMA-bufs as you can see
> > > > > here [1]. Then it will rather be two handles for user-space to manage.
> > > >
> > > > Yes, the decoder would need to do this. That's common though: if you
> > > > want to share a buffer between V4L2 and DRM, you have three handles:
> > > > the V4L2 buffer handle, the DRM GEM handle, and the dmabuf you use to
> > > > bridge the two.
> > > >
> > > > > Similarly during restricted memory allocation/free we need another
> > > > > glue layer under DMA heaps to TEE subsystem.
> > > >
> > > > Yep.
> > > >
> > > > > The reason is simply which has been iterated over many times in the
> > > > > past threads that:
> > > > >
> > > > > "If user-space has to interact with a TEE device for SVP use-case
> > > > > then why it's not better to ask TEE to allocate restricted DMA-bufs
> > > > > too"
> > > >
> > > > The first word in your proposition is load-bearing.
> > > >
> > > > Build out the usecase a little more here. You have a DRMed video
> > > > stream coming in, which you need to decode (involving TEE for this
> > > > usecase). You get a dmabuf handle to the decoded frame. You need to
> > > > pass the dmabuf across to the Wayland compositor. The compositor needs
> > > > to pass it to EGL/Vulkan to import and do composition, which in turn
> > > > passes it to the GPU DRM driver. The output of the composition is in
> > > > turn shared between the GPU DRM driver and the separate KMS DRM
> > > > driver, with the involvement of GBM.
> > > >
> > > > For the platforms I'm interested in, the GPU DRM driver needs to
> > > > switch in

Re: [PATCH v4 07/14] arm64: Add support for suppressing warning backtraces

2025-03-19 Thread Dan Carpenter

On Wed, Mar 19, 2025 at 09:05:27AM +0100, Christophe Leroy wrote:
> 
> Doesn't sparse and/or checkpatch complain about 0 being used in lieu of NULL
> ?

Sparse does have a "Using plain integer as NULL pointer" warning, yes.

I can't apply this patchset and I haven't been following the conversation
closely (plus I'm pretty stupid as well) so I'm not sure if it will
trigger here...

regards,
dan carpenter

Re: [PATCH v2 16/34] drm/msm: Mark VM as unusable on faults

On Wed, Mar 19, 2025 at 9:15 AM Connor Abbott  wrote:
>
> On Wed, Mar 19, 2025 at 10:55 AM Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > If userspace has opted-in to VM_BIND, then GPU faults and VM_BIND errors
> > will mark the VM as unusable.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/msm_gem.h| 17 +
> >  drivers/gpu/drm/msm/msm_gem_submit.c |  3 +++
> >  drivers/gpu/drm/msm/msm_gpu.c| 16 ++--
> >  3 files changed, 34 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> > index acb976722580..7cb720137548 100644
> > --- a/drivers/gpu/drm/msm/msm_gem.h
> > +++ b/drivers/gpu/drm/msm/msm_gem.h
> > @@ -82,6 +82,23 @@ struct msm_gem_vm {
> >
> > /** @managed: is this a kernel managed VM? */
> > bool managed;
> > +
> > +   /**
> > +* @unusable: True if the VM has turned unusable because something
> > +* bad happened during an asynchronous request.
> > +*
> > +* We don't try to recover from such failures, because this implies
> > +* informing userspace about the specific operation that failed, and
> > +* hoping the userspace driver can replay things from there. This 
> > all
> > +* sounds very complicated for little gain.
> > +*
> > +* Instead, we should just flag the VM as unusable, and fail any
> > +* further request targeting this VM.
> > +*
> > +* As an analogy, this would be mapped to a VK_ERROR_DEVICE_LOST
> > +* situation, where the logical device needs to be re-created.
> > +*/
> > +   bool unusable;
> >  };
> >  #define to_msm_vm(x) container_of(x, struct msm_gem_vm, base)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index 9731ad7993cf..9cef308a0ad1 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -668,6 +668,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
> > *data,
> > if (args->pad)
> > return -EINVAL;
> >
> > +   if (to_msm_vm(ctx->vm)->unusable)
> > +   return UERR(EPIPE, dev, "context is unusable");
> > +
> > /* for now, we just have 3d pipe.. eventually this would need to
> >  * be more clever to dispatch to appropriate gpu module:
> >  */
> > diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> > index 503e4dcc5a6f..4831f4e42fd9 100644
> > --- a/drivers/gpu/drm/msm/msm_gpu.c
> > +++ b/drivers/gpu/drm/msm/msm_gpu.c
> > @@ -386,8 +386,20 @@ static void recover_worker(struct kthread_work *work)
> >
> > /* Increment the fault counts */
> > submit->queue->faults++;
> > -   if (submit->vm)
> > -   to_msm_vm(submit->vm)->faults++;
> > +   if (submit->vm) {
> > +   struct msm_gem_vm *vm = to_msm_vm(submit->vm);
> > +
> > +   vm->faults++;
> > +
> > +   /*
> > +* If userspace has opted-in to VM_BIND (and therefore 
> > userspace
> > +* management of the VM), faults mark the VM as unusuable.  
> > This
> > +* matches vulkan expectations (vulkan is the main target 
> > for
> > +* VM_BIND)
>
> The bit about this matching Vulkan expectations isn't exactly true.
> Some Vulkan implementations do do this, but many will also just ignore
> the fault and try to continue going, and the spec allows either. It's
> a choice that we're making.

As mentioned on IRC, this is actually about GPU hangs rather then smmu
faults.   I guess the $subject is a bit misleading.

BR,
-R

> Connor
>
> > +*/
> > +   if (!vm->managed)
> > +   vm->unusable = true;
> > +   }
> >
> > get_comm_cmdline(submit, &comm, &cmd);
> >
> > --
> > 2.48.1
> >

RE: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property

2025-03-19 Thread Cavitt, Jonathan

-Original Message-
From: Zhang, Jianxun  
Sent: Wednesday, March 19, 2025 2:02 PM
To: Cavitt, Jonathan ; intel...@lists.freedesktop.org
Cc: Gupta, saurabhg ; Zuo, Alex ; 
joonas.lahti...@linux.intel.com; Brost, Matthew ; Lin, 
Shuicheng ; dri-devel@lists.freedesktop.org; 
Wajdeczko, Michal ; Mrozek, Michal 

Subject: Re: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property
> 
> 
> From: Cavitt, Jonathan 
> Sent: Wednesday, March 19, 2025 1:13 PM
> To: Zhang, Jianxun; intel...@lists.freedesktop.org
> Cc: Gupta, saurabhg; Zuo, Alex; joonas.lahti...@linux.intel.com; Brost, 
> Matthew; Lin, Shuicheng; dri-devel@lists.freedesktop.org; Wajdeczko, Michal; 
> Mrozek, Michal; Cavitt, Jonathan
> Subject: RE: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property
> 
> -Original Message-
> From: Zhang, Jianxun 
> Sent: Wednesday, March 19, 2025 12:59 PM
> To: Cavitt, Jonathan ; 
> intel...@lists.freedesktop.org
> Cc: Gupta, saurabhg ; Zuo, Alex 
> ; joonas.lahti...@linux.intel.com; Brost, Matthew 
> ; Lin, Shuicheng ; 
> dri-devel@lists.freedesktop.org; Wajdeczko, Michal 
> ; Mrozek, Michal 
> Subject: Re: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property
> >
> > On 3/18/25 10:11, Jonathan Cavitt wrote:
> > > Add initial declarations for the drm_xe_vm_get_property ioctl.
> > >
> > > v2:
> > > - Expand kernel docs for drm_xe_vm_get_property (Jianxun)
> > >
> > > Signed-off-by: Jonathan Cavitt 
> > > Cc: Zhang Jianxun 
> > > ---
> > >   include/uapi/drm/xe_drm.h | 80 +++
> > >   1 file changed, 80 insertions(+)
> > >
> > > diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
> > > index 616916985e3f..ef335471653e 100644
> > > --- a/include/uapi/drm/xe_drm.h
> > > +++ b/include/uapi/drm/xe_drm.h
> > > @@ -81,6 +81,7 @@ extern "C" {
> > >*  - &DRM_IOCTL_XE_EXEC
> > >*  - &DRM_IOCTL_XE_WAIT_USER_FENCE
> > >*  - &DRM_IOCTL_XE_OBSERVATION
> > > + *  - &DRM_IOCTL_XE_VM_GET_PROPERTY
> > >*/
> > >
> > >   /*
> > > @@ -102,6 +103,7 @@ extern "C" {
> > >   #define DRM_XE_EXEC   0x09
> > >   #define DRM_XE_WAIT_USER_FENCE0x0a
> > >   #define DRM_XE_OBSERVATION0x0b
> > > +#define DRM_XE_VM_GET_PROPERTY 0x0c
> > >
> > >   /* Must be kept compact -- no holes */
> > >
> > > @@ -117,6 +119,7 @@ extern "C" {
> > >   #define DRM_IOCTL_XE_EXEC DRM_IOW(DRM_COMMAND_BASE + 
> > > DRM_XE_EXEC, struct drm_xe_exec)
> > >   #define DRM_IOCTL_XE_WAIT_USER_FENCE  
> > > DRM_IOWR(DRM_COMMAND_BASE + DRM_XE_WAIT_USER_FENCE, struct 
> > > drm_xe_wait_user_fence)
> > >   #define DRM_IOCTL_XE_OBSERVATION  DRM_IOW(DRM_COMMAND_BASE + 
> > > DRM_XE_OBSERVATION, struct drm_xe_observation_param)
> > > +#define DRM_IOCTL_XE_VM_GET_PROPERTY   DRM_IOWR(DRM_COMMAND_BASE + 
> > > DRM_XE_VM_GET_PROPERTY, struct drm_xe_vm_get_property)
> > >
> > >   /**
> > >* DOC: Xe IOCTL Extensions
> > > @@ -1189,6 +1192,83 @@ struct drm_xe_vm_bind {
> > > __u64 reserved[2];
> > >   };
> > >
> > > +/** struct xe_vm_fault - Describes faults for 
> > > %DRM_XE_VM_GET_PROPERTY_FAULTS */
> > > +struct xe_vm_fault {
> > > +   /** @address: Address of the fault */
> > > +   __u64 address;
> > > +#define DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT 0
> 
> > Just a question, VK_DEVICE_FAULT_ADDRESS_TYPE_NONE_EXT in Vulkan spec
> > specifies the address of the fault does not describe a page fault, or an
> > instruction address. Does this NONE type in KMD mean the same thing?
> 
> I think it means that the page that was attempted to be accessed did not 
> exist.
> Read, by comparison, means that the page existed, but that permission was
> not granted to read the contents.  Write means the same thing for write
> permissions.
> 
> At least, that was my understanding.
> 
> -Jonathan Cavitt
> 
> But no matter if the page existing or not, the type of access, read, write or 
> exec is always present. Make sense?

Yeah, that makes sense.  Though I don't think that's what the address type 
field is being used for?

Here's the itemized list of places where these address types are used:

DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT:
Used during pagefault handling, if no associated VM was found.  It's also 
technically the default address type
(as the pagefault structure is initialized to all zeroes).

DRM_XE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT:
Currently unused

DRM_XE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT:
Reported if we attempt to perform a non-read operation on a read-only VMA.

Should we expand this list before creating the next revision?  Or perhaps 
rename address_type to
something else?

-Jonathan Cavitt

> 
> > > +#define DRM_XE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT 1
> > > +#define DRM_XE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT2
> > > +   /** @address_type: Type of address access that resulted in fault */
> > > +   __u32 address_type;
> > > +   /** @address_

Re: [PATCH v2 00/57] irqdomain: Cleanups and Documentation

2025-03-19 Thread Jiri Slaby


On 19. 03. 25, 11:21, Andy Shevchenko wrote:

I am all to support the idea, but in some cases I would think of a bit
more work to be done to get rid of the of_fwnode_handle(np) in favour
of dev_fwnode(dev). Note, this is based on a brief look, I haven't any
example at hand right now.


Aah, that's the helper I was looking for!

I was about to use dev->fwnode directly (see the commit log for the 
Switch to irq_domain_create_*()), but that is not guaranteed to be 
always properly set.


Will use this instead in v3.

thanks,
--
js
suse labs

Re: [PATCH v2 5/7] drm/tests: hdmi: Add macros to simplify EDID setup

2025-03-19 Thread Cristian Ciocaltea

On 3/19/25 5:32 PM, Maxime Ripard wrote:
> On Wed, Mar 12, 2025 at 12:44:26AM +0200, Cristian Ciocaltea wrote:
>> On 3/11/25 6:12 PM, Maxime Ripard wrote:
>>> On Tue, Mar 11, 2025 at 12:57:37PM +0200, Cristian Ciocaltea wrote:
 Introduce a few macros to facilitate setting custom (i.e. non-default)
 EDID data during connector initialization.

 This helps reducing boilerplate code while also drops some redundant
 calls to set_connector_edid().

 Signed-off-by: Cristian Ciocaltea 
 ---
  drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 245 
 -
  1 file changed, 93 insertions(+), 152 deletions(-)

 diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c 
 b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
 index 
 e97efd3af9ed18e6cf8ee66b4923dfc805b34e19..a3f7f3ce31c73335c2c2643bdc5395b6ceb6f071
  100644
 --- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
 +++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
 @@ -183,10 +183,12 @@ static const struct drm_connector_funcs 
 dummy_connector_funcs = {
  
  static
  struct drm_atomic_helper_connector_hdmi_priv *
 -drm_kunit_helper_connector_hdmi_init_funcs(struct kunit *test,
 - unsigned int formats,
 - unsigned int max_bpc,
 - const struct 
 drm_connector_hdmi_funcs *hdmi_funcs)
 +connector_hdmi_init_funcs_set_edid(struct kunit *test,
 + unsigned int formats,
 + unsigned int max_bpc,
 + const struct drm_connector_hdmi_funcs 
 *hdmi_funcs,
 + const char *edid_data,
 + size_t edid_len)
  {
struct drm_atomic_helper_connector_hdmi_priv *priv;
struct drm_connector *conn;
 @@ -240,30 +242,27 @@ drm_kunit_helper_connector_hdmi_init_funcs(struct 
 kunit *test,
  
drm_mode_config_reset(drm);
  
 +  if (edid_data && edid_len) {
 +  ret = set_connector_edid(test, &priv->connector, edid_data, 
 edid_len);
 +  KUNIT_ASSERT_GT(test, ret, 0);
 +  }
 +
return priv;
  }
  
 -static
 -struct drm_atomic_helper_connector_hdmi_priv *
 -drm_kunit_helper_connector_hdmi_init(struct kunit *test,
 -   unsigned int formats,
 -   unsigned int max_bpc)
 -{
 -  struct drm_atomic_helper_connector_hdmi_priv *priv;
 -  int ret;
 +#define drm_kunit_helper_connector_hdmi_init_funcs_set_edid(test, 
 formats, max_bpc, funcs, edid) \
 +  connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, funcs, edid, 
 ARRAY_SIZE(edid))
  
 -  priv = drm_kunit_helper_connector_hdmi_init_funcs(test,
 -formats, max_bpc,
 -
 &dummy_connector_hdmi_funcs);
 -  KUNIT_ASSERT_NOT_ERR_OR_NULL(test, priv);
 +#define drm_kunit_helper_connector_hdmi_init_funcs(test, formats, 
 max_bpc, funcs) \
 +  connector_hdmi_init_funcs_set_edid(test, formats, max_bpc, funcs, NULL, 
 0)
  
 -  ret = set_connector_edid(test, &priv->connector,
 -   test_edid_hdmi_1080p_rgb_max_200mhz,
 -   
 ARRAY_SIZE(test_edid_hdmi_1080p_rgb_max_200mhz));
 -  KUNIT_ASSERT_GT(test, ret, 0);
 +#define drm_kunit_helper_connector_hdmi_init_set_edid(test, formats, 
 max_bpc, edid)   \
 +  drm_kunit_helper_connector_hdmi_init_funcs_set_edid(test, formats, 
 max_bpc, \
 +  
 &dummy_connector_hdmi_funcs, edid)
  
 -  return priv;
 -}
 +#define drm_kunit_helper_connector_hdmi_init(test, formats, max_bpc)  
 \
 +  drm_kunit_helper_connector_hdmi_init_set_edid(test, formats, max_bpc,   
 \
 +
 test_edid_hdmi_1080p_rgb_max_200mhz)
>>>
>>> I'd really prefer to have functions to macros here. They are easier to
>>> read, extend, and don't have any particular drawbacks.
>>
>> Yeah, the main reason I opted for macros was to allow dropping
>> ARRAY_SIZE(edid) from the caller side, hence making the API as simple as
>> possible.
>>
>>> I also don't think we need that many, looking at the tests:
>>>
>>>   - We need drm_kunit_helper_connector_hdmi_init() to setup a connector
>>> with test_edid_hdmi_1080p_rgb_max_200mhz and
>>> dummy_connector_hdmi_funcs()
>>
>> Correct.
>>
>>>   - We need to create a
>>> drm_kunit_helper_connector_hdmi_init_with_edid_funcs() to pass both
>>> the funcs a

Re: [PATCH v8 6/6] drm/xe/xe_vm: Implement xe_vm_get_property_ioctl

2025-03-19 Thread Jianxun Zhang





On 3/13/25 11:34, Jonathan Cavitt wrote:

Add support for userspace to request a list of observed faults
from a specified VM.

v2:
- Only allow querying of failed pagefaults (Matt Brost)

v3:
- Remove unnecessary size parameter from helper function, as it
   is a property of the arguments. (jcavitt)
- Remove unnecessary copy_from_user (Jainxun)
- Set address_precision to 1 (Jainxun)
- Report max size instead of dynamic size for memory allocation
   purposes.  Total memory usage is reported separately.

v4:
- Return int from xe_vm_get_property_size (Shuicheng)
- Fix memory leak (Shuicheng)
- Remove unnecessary size variable (jcavitt)

v5:
- Rename ioctl to xe_vm_get_faults_ioctl (jcavitt)
- Update fill_property_pfs to eliminate need for kzalloc (Jianxun)

v6:
- Repair and move fill_faults break condition (Dan Carpenter)
- Free vm after use (jcavitt)
- Combine assertions (jcavitt)
- Expand size check in xe_vm_get_faults_ioctl (jcavitt)
- Remove return mask from fill_faults, as return is already -EFAULT or 0
   (jcavitt)

v7:
- Revert back to using xe_vm_get_property_ioctl
- Apply better copy_to_user logic (jcavitt)

Signed-off-by: Jonathan Cavitt 
Suggested-by: Matthew Brost 
Cc: Jainxun Zhang 
Cc: Shuicheng Lin 
---
  drivers/gpu/drm/xe/xe_device.c |   3 +
  drivers/gpu/drm/xe/xe_vm.c | 134 +
  drivers/gpu/drm/xe/xe_vm.h |   2 +
  3 files changed, 139 insertions(+)

diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
index b2f656b2a563..74e510cb0e47 100644
--- a/drivers/gpu/drm/xe/xe_device.c
+++ b/drivers/gpu/drm/xe/xe_device.c
@@ -194,6 +194,9 @@ static const struct drm_ioctl_desc xe_ioctls[] = {
DRM_IOCTL_DEF_DRV(XE_WAIT_USER_FENCE, xe_wait_user_fence_ioctl,
  DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(XE_OBSERVATION, xe_observation_ioctl, 
DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(XE_VM_GET_PROPERTY, xe_vm_get_property_ioctl,
+ DRM_RENDER_ALLOW),
+
  };
  
  static long xe_drm_ioctl(struct file *file, unsigned int cmd, unsigned long arg)

diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index 067a9cedcad9..521f0032d9e2 100644
--- a/drivers/gpu/drm/xe/xe_vm.c
+++ b/drivers/gpu/drm/xe/xe_vm.c
@@ -42,6 +42,14 @@
  #include "xe_wa.h"
  #include "xe_hmm.h"
  
+static const u16 xe_to_user_engine_class[] = {

+   [XE_ENGINE_CLASS_RENDER] = DRM_XE_ENGINE_CLASS_RENDER,
+   [XE_ENGINE_CLASS_COPY] = DRM_XE_ENGINE_CLASS_COPY,
+   [XE_ENGINE_CLASS_VIDEO_DECODE] = DRM_XE_ENGINE_CLASS_VIDEO_DECODE,
+   [XE_ENGINE_CLASS_VIDEO_ENHANCE] = DRM_XE_ENGINE_CLASS_VIDEO_ENHANCE,
+   [XE_ENGINE_CLASS_COMPUTE] = DRM_XE_ENGINE_CLASS_COMPUTE,
Not sure if this will be used to interpret engine_class that will be 
reported to UMD, so just a heads up. In bspec 77412 the compute engine 
class id is 5, instead of 4 as this macro defined.


There are other values so perhaps you can just report raw value of 
engine class and let UMD deals with it according to the bspec.

+};
+
  static struct drm_gem_object *xe_vm_obj(struct xe_vm *vm)
  {
return vm->gpuvm.r_obj;
@@ -3551,6 +3559,132 @@ int xe_vm_bind_ioctl(struct drm_device *dev, void 
*data, struct drm_file *file)
return err;
  }
  
+static int xe_vm_get_property_size(struct xe_vm *vm, u32 property)

+{
+   int size = -EINVAL;
+
+   switch (property) {
+   case DRM_XE_VM_GET_PROPERTY_FAULTS:
+   spin_lock(&vm->faults.lock);
+   size = vm->faults.len * sizeof(struct xe_vm_fault);
+   spin_unlock(&vm->faults.lock);
+   break;
+   default:
+   break;
+   }
+   return size;
+}
+
+static int xe_vm_get_property_verify_size(struct xe_vm *vm, u32 property,
+ int expected, int actual)
+{
+   switch (property) {
+   case DRM_XE_VM_GET_PROPERTY_FAULTS:
+   /*
+* Number of faults may increase between calls to
+* xe_vm_get_property_ioctl, so just report the
+* number of faults the user requests if it's less
+* than or equal to the number of faults in the VM
+* fault array.
+*/
+   if (actual < expected)
+   return -EINVAL;
+   break;
+   default:
+   if (actual != expected)
+   return -EINVAL;
+   break;
+   }
+   return 0;
+}
+
+static int fill_faults(struct xe_vm *vm,
+  struct drm_xe_vm_get_property *args)
+{
+   struct xe_vm_fault __user *usr_ptr = u64_to_user_ptr(args->data);
+   struct xe_vm_fault store = { 0 };
+   struct xe_vm_fault_entry *entry;
+   int ret = 0, i = 0, count;
+
+   count = args->size / sizeof(struct xe_vm_fault);
+
+   spin_lock(&vm->faults.lock);
+   list_for_each_entry(entry, &vm->faults.list, list) {
+

Re: [PATCH] video: fbdev: sm501fb: Add some geometry checks.

2025-03-19 Thread Helge Deller


On 3/19/25 02:30, Danila Chernetsov wrote:

Added checks for xoffset, yoffset settings.
Incorrect settings of these parameters can lead to errors
in sm501fb_pan_ functions.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 5fc404e47bdf ("[PATCH] fb: SM501 framebuffer driver")
Signed-off-by: Danila Chernetsov 
---
  drivers/video/fbdev/sm501fb.c | 7 +++
  1 file changed, 7 insertions(+)


applied.

Thanks!
Helge

Re: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property

2025-03-19 Thread Jianxun Zhang

On 3/19/25 14:13, Cavitt, Jonathan wrote:

-Original Message-
From: Zhang, Jianxun 
Sent: Wednesday, March 19, 2025 2:02 PM
To: Cavitt, Jonathan ; intel...@lists.freedesktop.org
Cc: Gupta, saurabhg ; Zuo, Alex ; 
joonas.lahti...@linux.intel.com; Brost, Matthew ; Lin, Shuicheng 
; dri-devel@lists.freedesktop.org; Wajdeczko, Michal 
; Mrozek, Michal 
Subject: Re: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property

From: Cavitt, Jonathan 
Sent: Wednesday, March 19, 2025 1:13 PM
To: Zhang, Jianxun; intel...@lists.freedesktop.org
Cc: Gupta, saurabhg; Zuo, Alex; joonas.lahti...@linux.intel.com; Brost, 
Matthew; Lin, Shuicheng; dri-devel@lists.freedesktop.org; Wajdeczko, Michal; 
Mrozek, Michal; Cavitt, Jonathan
Subject: RE: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property

-Original Message-
From: Zhang, Jianxun 
Sent: Wednesday, March 19, 2025 12:59 PM
To: Cavitt, Jonathan ; intel...@lists.freedesktop.org
Cc: Gupta, saurabhg ; Zuo, Alex ; 
joonas.lahti...@linux.intel.com; Brost, Matthew ; Lin, Shuicheng 
; dri-devel@lists.freedesktop.org; Wajdeczko, Michal 
; Mrozek, Michal 
Subject: Re: [PATCH v9 3/6] drm/xe/uapi: Define drm_xe_vm_get_property

On 3/18/25 10:11, Jonathan Cavitt wrote:

Add initial declarations for the drm_xe_vm_get_property ioctl.

v2:
- Expand kernel docs for drm_xe_vm_get_property (Jianxun)

Signed-off-by: Jonathan Cavitt 
Cc: Zhang Jianxun 
---
   include/uapi/drm/xe_drm.h | 80 +++
   1 file changed, 80 insertions(+)

diff --git a/include/uapi/drm/xe_drm.h b/include/uapi/drm/xe_drm.h
index 616916985e3f..ef335471653e 100644
--- a/include/uapi/drm/xe_drm.h
+++ b/include/uapi/drm/xe_drm.h
@@ -81,6 +81,7 @@ extern "C" {
*  - &DRM_IOCTL_XE_EXEC
*  - &DRM_IOCTL_XE_WAIT_USER_FENCE
*  - &DRM_IOCTL_XE_OBSERVATION
+ *  - &DRM_IOCTL_XE_VM_GET_PROPERTY
*/

   /*
@@ -102,6 +103,7 @@ extern "C" {
   #define DRM_XE_EXEC   0x09
   #define DRM_XE_WAIT_USER_FENCE0x0a
   #define DRM_XE_OBSERVATION0x0b
+#define DRM_XE_VM_GET_PROPERTY 0x0c

   /* Must be kept compact -- no holes */

@@ -117,6 +119,7 @@ extern "C" {
   #define DRM_IOCTL_XE_EXEC DRM_IOW(DRM_COMMAND_BASE + 
DRM_XE_EXEC, struct drm_xe_exec)
   #define DRM_IOCTL_XE_WAIT_USER_FENCE  DRM_IOWR(DRM_COMMAND_BASE 
+ DRM_XE_WAIT_USER_FENCE, struct drm_xe_wait_user_fence)
   #define DRM_IOCTL_XE_OBSERVATION  DRM_IOW(DRM_COMMAND_BASE + 
DRM_XE_OBSERVATION, struct drm_xe_observation_param)
+#define DRM_IOCTL_XE_VM_GET_PROPERTY   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_XE_VM_GET_PROPERTY, struct drm_xe_vm_get_property)

   /**
* DOC: Xe IOCTL Extensions
@@ -1189,6 +1192,83 @@ struct drm_xe_vm_bind {
 __u64 reserved[2];
   };

+/** struct xe_vm_fault - Describes faults for %DRM_XE_VM_GET_PROPERTY_FAULTS */
+struct xe_vm_fault {
+   /** @address: Address of the fault */
+   __u64 address;
+#define DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT 0

Just a question, VK_DEVICE_FAULT_ADDRESS_TYPE_NONE_EXT in Vulkan spec
specifies the address of the fault does not describe a page fault, or an
instruction address. Does this NONE type in KMD mean the same thing?

I think it means that the page that was attempted to be accessed did not exist.
Read, by comparison, means that the page existed, but that permission was
not granted to read the contents.  Write means the same thing for write
permissions.

At least, that was my understanding.

-Jonathan Cavitt

But no matter if the page existing or not, the type of access, read, write or 
exec is always present. Make sense?

Yeah, that makes sense.  Though I don't think that's what the address type 
field is being used for?

Here's the itemized list of places where these address types are used:

DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT:
Used during pagefault handling, if no associated VM was found.  It's also 
technically the default address type
(as the pagefault structure is initialized to all zeroes).

DRM_XE_FAULT_ADDRESS_TYPE_READ_INVALID_EXT:
Currently unused

DRM_XE_FAULT_ADDRESS_TYPE_WRITE_INVALID_EXT:
Reported if we attempt to perform a non-read operation on a read-only VMA.

Should we expand this list before creating the next revision?  Or perhaps 
rename address_type to
something else?

-Jonathan Cavitt
There are two groups of definitions of access or address types in KMD, 
DRM_XE_* macros here and enum xe_gt_pagefault_access_type that could be 
derived from bspec 77412. The DRM_XE_FAULT_ADDRESS_TYPE_NONE_EXT is an 
addition but it is in neither bspec nor Vulkan spec.

Assuming Bspec 77412 is the right place of what KMD gets from lower 
level, I think we should align both KMD and UMD in the interface around 
it. What I can imagine is:

If KMD needs to parse or interpret fields of PF descriptor struct 
internally, say, printk out page fault in a pretty way, you can just 
report all of these fie

Re: [PATCH v2 00/57] irqdomain: Cleanups and Documentation

2025-03-19 Thread Andy Shevchenko

On Wed, Mar 19, 2025 at 11:30 AM Jiri Slaby (SUSE)  wrote:
>
> Hi,
>
> tl;dr if patches are agreed upon, I ask subsys maintainers to take the
> respective ones via their trees (as they are split per subsys), so that
> the IRQ tree can take only the rest. That would minimize churn/conflicts
> during merges.
>
> ===
>
> While I was reading through the irqdomain code and headers, I found some
> naming and documentation hard to follow or incomplete. Especially the
> naming of _add/_create/_instantiate functions.
>
> I tried to come up with a better state with this patchset:
> * only irq _domain_ (not host),
> * only irq_domain_create*() functions, all taking fwnode uniformly,
>
> Finally, all the irqdomain stuff is now plugged (and generated) into
> Documentation. So that everyone can walk through it at
> https://www.kernel.org/doc/ (once applied, of course).

I am all to support the idea, but in some cases I would think of a bit
more work to be done to get rid of the of_fwnode_handle(np) in favour
of dev_fwnode(dev). Note, this is based on a brief look, I haven't any
example at hand right now.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2] fbcon: Use static attribute groups for sysfs entries

2025-03-19 Thread Helge Deller


On 3/14/25 09:16, Thomas Zimmermann wrote:

Am 14.03.25 um 07:09 schrieb oushixiong1...@163.com:

From: Shixiong Ou 

Using device_create_with_groups() to simplify creation and removal.
Same as commit 1083a7be4504 ("tty: Use static attribute groups for
sysfs entries").

Signed-off-by: Shixiong Ou 


Acked-by: Thomas Zimmermann 

with minor comments below


---
  drivers/video/fbdev/core/fbcon.c | 69 +---
  1 file changed, 19 insertions(+), 50 deletions(-)


series applied with changes as suggested by Thomas.

Thanks!
Helge

RE: [PATCH] drm/amdgpu: Higher log level for missing PCIe atomics caps

2025-03-19 Thread Daisuke Matsuda (Fujitsu)

On Tue, Mar 18, 2025 5:35 AM Felix Kuehling wrote:
> On 2025-03-17 15:07, Deucher, Alexander wrote:
> > [Public]
> >
> >> -Original Message-
> >> From: Daisuke Matsuda 
> >> Sent: Thursday, March 13, 2025 9:18 PM
> >> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
> >> Deucher,
> >> Alexander ; Koenig, Christian
> >> 
> >> Cc: airl...@gmail.com; sim...@ffwll.ch; Daisuke Matsuda  >> dais...@fujitsu.com>
> >> Subject: [PATCH] drm/amdgpu: Higher log level for missing PCIe atomics caps
> >>
> >> Currently, ROCm requires CPUs that support PCIe atomics. The message is 
> >> more
> >> urgent for GPGPU users, meaning basic functionalities of ROCm are not 
> >> available
> >> on the node.
> >>
> > + Felix
> >
> > My understanding is that PCIe atomics are not strictly required, but there 
> > are some features that are not available
> without them.  Warning seems a bit overkill and potentially confusing to 
> users that have an existing system that
> otherwise works fine.
> 
> I could see either argument. The GPU is capable of PCIe atomics, but the 
> system configuration (chipset, PCIe switch, etc.)
> is preventing them from working, which has an impact on some 
> application-visible functionality. A naive application that
> depends on atomics and is not carefully written to provide fallbacks or fail 
> gracefully in case atomics are unavailable,
> would fail silently or produce incorrect results. So maybe that justifies a 
> warning message.

The Linux kernel commonly uses "warn level" messages to alert users when an 
incompatibility restricts functionality, and this approach aligns with that 
practice.
To address the concern about the message being too general, how about making it 
more specific like this:
  dev_warn(adev->dev, "PCIe atomic ops are not supported.  ROCm performance and 
functionality may be limited.\n");
This is more direct and focused on the impact to ROCm users.

Regards,
Daisuke

> 
> Regards,
>   Felix
> 
> 
> >
> > Alex
> >
> >
> >> Signed-off-by: Daisuke Matsuda 
> >> ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c  | 4 ++--
> >> drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h | 2 +-
> >>  2 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> index 018dfccd771b..faeef136e272 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> @@ -4374,7 +4374,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> >>   return r;
> >>   }
> >>
> >> - /* enable PCIE atomic ops */
> >> + /* enable PCIe atomic ops */
> >>   if (amdgpu_sriov_vf(adev)) {
> >>   if (adev->virt.fw_reserve.p_pf2vf)
> >>   adev->have_atomics_support = ((struct
> >> amd_sriov_msg_pf2vf_info *) @@ -4395,7 +4395,7 @@ int
> >> amdgpu_device_init(struct amdgpu_device *adev,
> >>   }
> >>
> >>   if (!adev->have_atomics_support)
> >> - dev_info(adev->dev, "PCIE atomic ops is not supported\n");
> >> + dev_warn(adev->dev, "PCIe atomic ops are not supported\n");
> >>
> >>   /* doorbell bar mapping and doorbell index init*/
> >>   amdgpu_doorbell_init(adev);
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
> >> b/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
> >> index b4f9c2f4e92c..c52605a07597 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h
> >> @@ -240,7 +240,7 @@ struct amd_sriov_msg_pf2vf_info {
> >>   } mm_bw_management[AMD_SRIOV_MSG_RESERVE_VCN_INST];
> >>   /* UUID info */
> >>   struct amd_sriov_msg_uuid_info uuid_info;
> >> - /* PCIE atomic ops support flag */
> >> + /* PCIe atomic ops support flag */
> >>   uint32_t pcie_atomic_ops_support_flags;
> >>   /* Portion of GPU memory occupied by VF.  MAX value is 65535, but 
> >> set to
> >> uint32_t to maintain alignment with reserved size */
> >>   uint32_t gpu_capacity;
> >> --
> >> 2.39.1

[PATCH 2/2] misc: fastrpc: add support for gpdsp remoteproc

2025-03-19 Thread Ling Xu

The fastrpc driver has support for 5 types of remoteprocs. There are
some products which support GPDSP remoteprocs. Add changes to support
GPDSP remoteprocs.

Signed-off-by: Ling Xu 
---
 drivers/misc/fastrpc.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 7b7a22c91fe4..80aa554b3042 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -28,7 +28,9 @@
 #define SDSP_DOMAIN_ID (2)
 #define CDSP_DOMAIN_ID (3)
 #define CDSP1_DOMAIN_ID (4)
-#define FASTRPC_DEV_MAX5 /* adsp, mdsp, slpi, cdsp, cdsp1 */
+#define GDSP0_DOMAIN_ID (5)
+#define GDSP1_DOMAIN_ID (6)
+#define FASTRPC_DEV_MAX7 /* adsp, mdsp, slpi, cdsp, cdsp1, 
gdsp0, gdsp1 */
 #define FASTRPC_MAX_SESSIONS   14
 #define FASTRPC_MAX_VMIDS  16
 #define FASTRPC_ALIGN  128
@@ -107,7 +109,9 @@
 #define miscdev_to_fdevice(d) container_of(d, struct fastrpc_device, miscdev)
 
 static const char *domains[FASTRPC_DEV_MAX] = { "adsp", "mdsp",
-   "sdsp", "cdsp", "cdsp1" };
+   "sdsp", "cdsp",
+   "cdsp1", "gdsp0",
+   "gdsp1" };
 struct fastrpc_phy_page {
u64 addr;   /* physical address */
u64 size;   /* size of contiguous region */
@@ -2338,6 +2342,8 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
break;
case CDSP_DOMAIN_ID:
case CDSP1_DOMAIN_ID:
+   case GDSP0_DOMAIN_ID:
+   case GDSP1_DOMAIN_ID:
data->unsigned_support = true;
/* Create both device nodes so that we can allow both Signed 
and Unsigned PD */
err = fastrpc_device_register(rdev, data, true, 
domains[domain_id]);
-- 
2.34.1

[PATCH 0/2] Add support for gpdsp remoteproc on sa8775p

2025-03-19 Thread Ling Xu

The fastrpc driver has support for 5 types of remoteprocs. There are
some products which support GPDSP remoteprocs. GPDSPs are General
Purpose DSPs where tasks can be offloaded. Add changes to support GPDSP
remoteprocs and also add GPDSP fastrpc nodes.

Ling Xu (2):
  arm64: dts: qcom: sa8775p: add GPDSP fastrpc-compute-cb nodes
  misc: fastrpc: add support for gpdsp remoteproc

 arch/arm64/boot/dts/qcom/sa8775p.dtsi | 58 +++
 drivers/misc/fastrpc.c| 10 -
 2 files changed, 66 insertions(+), 2 deletions(-)

-- 
2.34.1

Re: [PATCH 1/2] drm/amd/display: Protect dml2_create()/dml2_copy()/dml2_create_copy()

2025-03-19 Thread Huacai Chen

Hi, Alex,

On Thu, Mar 20, 2025 at 10:16 AM Alex Hung  wrote:
>
>
>
> On 3/18/25 05:17, Huacai Chen wrote:
> > Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context
> > start") removes the FP context protection of dml2_create(), and it said
> > "All the DC_FP_START/END should be used before call anything from DML2".
> >
> > However, dml2_create()/dml2_copy()/dml2_create_copy() are not protected
> > from their callers, causing such errors:
> >
> >   do_fpu invoked from kernel context![#1]:
> >   CPU: 0 UID: 0 PID: 239 Comm: kworker/0:5 Not tainted 6.14.0-rc6+ #1
> >   Workqueue: events work_for_cpu_fn
> >   pc 8319de80 ra 8319de5c tp 90010575c000 sp 
> > 90010575f840
> >   a0  a1 90012f210130 a2 90012f00 a3 
> > 8357e268
> >   a4 8357e260 a5 90012ea52cf0 a6 00040004 a7 
> > 012c1388
> >   t0 190015e0 t1 8379d000 t2 10624dd3 t3 
> > 00640014
> >   t4 03e8 t5 00500018 t6 0020 t7 
> > 000f0064
> >   t8 002f u0 5f5e9200f8901912 s9 90012d380010 s0 
> > 90012ea51fd8
> >   s1 90012f00 s2 900109296000 s3 0001 s4 
> > 1fd8
> >   s5 0001 s6 83415000 s7 90012d39 s8 
> > 83211f80
> >  ra: 8319de5c dml21_apply_soc_bb_overrides+0x3c/0x960 [amdgpu]
> > ERA: 8319de80 dml21_apply_soc_bb_overrides+0x60/0x960 [amdgpu]
> >CRMD: 00b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
> >PRMD: 0004 (PPLV0 +PIE -PWE)
> >EUEN:  (-FPE -SXE -ASXE -BTE)
> >ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
> >   ESTAT: 000f [FPD] (IS= ECode=15 EsubCode=0)
> >PRID: 0014d010 (Loongson-64bit, Loongson-3C6000/S)
> >   Process kworker/0:5 (pid: 239, threadinfo=927eadc6, 
> > task=8fd31682)
> >   Stack : 00040dc03164 0001 90012f210130 
> > 90012eabeeb8
> >   90012f00 8319fe48 90012f21 
> > 90012f210130
> >   90012f00 90012eabeeb8 0001 
> > 831a0064
> >   90010575f9f0 90012f210130 90012eac 
> > 90012ea8
> >   90012f00 831cefc4 90010575f9f0 
> > 835859c0
> >   83414000 90010575fa78 90012f00 
> > 831b4c50
> >    900101c9d700 900109c4 
> > 5f5e9200f8901912
> >   90012d3c4bd0 90012d3c5000 834aed18 
> > 90012d380010
> >   90012d3c4bd0 83414000 90012d38 
> > 82ea49dc
> >   0001 90012d3c6000 e423 
> > 0001
> >   ...
> >   Call Trace:
> >   [] dml21_apply_soc_bb_overrides+0x60/0x960 [amdgpu]
> >   [] dml21_init+0xa4/0x280 [amdgpu]
> >   [] dml21_create+0x40/0x80 [amdgpu]
> >   [] dc_state_create+0x100/0x160 [amdgpu]
> >   [] dc_create+0x44c/0x640 [amdgpu]
> >   [] amdgpu_dm_init+0x3f8/0x2060 [amdgpu]
> >   [] dm_hw_init+0x18/0x60 [amdgpu]
> >   [] amdgpu_device_init+0x1938/0x27e0 [amdgpu]
> >   [] amdgpu_driver_load_kms+0x20/0xa0 [amdgpu]
> >   [] amdgpu_pci_probe+0x1b0/0x580 [amdgpu]
> >   [<9448eae4>] local_pci_probe+0x44/0xc0
> >   [<93b02b18>] work_for_cpu_fn+0x18/0x40
> >   [<93b05da0>] process_one_work+0x160/0x300
> >   [<93b06718>] worker_thread+0x318/0x440
> >   [<93b11b8c>] kthread+0x12c/0x220
> >   [<93ac1484>] ret_from_kernel_thread+0x8/0xa4
> >
> > So protect dml2_create()/dml2_copy()/dml2_create_copy() with DC_FP_START
> > and DC_FP_END.
>
> Hi Huacai,
>
> Can you try to put DC_FP_START DC_FP_END in the
> dml2_create()/dml2_copy()/dml2_create_copy()/dml2_validate() instead?
> The code will be cleaner and less error-prone to future changes.
At first I want to add them in
dml2_create()/dml2_copy()/dml2_create_copy()/dml2_validate(), but
commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context
start")  said
that "All the DC_FP_START/END should be used before call anything from DML2".

Huacai

>
> Thanks.
>
>
> >
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Huacai Chen 
> > ---
> >   drivers/gpu/drm/amd/display/dc/core/dc_state.c | 16 
> >   1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_state.c 
> > b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
> > index 1b2cce127981..6e2cac08002d 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc_state.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
> > @@ -210,17 +210,23 @@ struct dc_state *dc_state_create(struct dc *dc, 
> > struct dc_state_create_params *p
> >
> >   #ifdef CONFIG_DRM_AMD_DC_FP
> >   if (dc->debug.using_dml2) {
> > + DC_FP_START();
> > +
> >   dml2_opt->use_clock_dc_limits = false;
> >   if (!dml2_create(dc, dml2_opt, &state->bw_c

Re: [PATCH 1/2] drm/amd/display: Protect dml2_create()/dml2_copy()/dml2_create_copy()

2025-03-19 Thread Alex Hung





On 3/18/25 05:17, Huacai Chen wrote:

Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context
start") removes the FP context protection of dml2_create(), and it said
"All the DC_FP_START/END should be used before call anything from DML2".

However, dml2_create()/dml2_copy()/dml2_create_copy() are not protected
from their callers, causing such errors:

  do_fpu invoked from kernel context![#1]:
  CPU: 0 UID: 0 PID: 239 Comm: kworker/0:5 Not tainted 6.14.0-rc6+ #1
  Workqueue: events work_for_cpu_fn
  pc 8319de80 ra 8319de5c tp 90010575c000 sp 
90010575f840
  a0  a1 90012f210130 a2 90012f00 a3 
8357e268
  a4 8357e260 a5 90012ea52cf0 a6 00040004 a7 
012c1388
  t0 190015e0 t1 8379d000 t2 10624dd3 t3 
00640014
  t4 03e8 t5 00500018 t6 0020 t7 
000f0064
  t8 002f u0 5f5e9200f8901912 s9 90012d380010 s0 
90012ea51fd8
  s1 90012f00 s2 900109296000 s3 0001 s4 
1fd8
  s5 0001 s6 83415000 s7 90012d39 s8 
83211f80
 ra: 8319de5c dml21_apply_soc_bb_overrides+0x3c/0x960 [amdgpu]
ERA: 8319de80 dml21_apply_soc_bb_overrides+0x60/0x960 [amdgpu]
   CRMD: 00b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
   PRMD: 0004 (PPLV0 +PIE -PWE)
   EUEN:  (-FPE -SXE -ASXE -BTE)
   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
  ESTAT: 000f [FPD] (IS= ECode=15 EsubCode=0)
   PRID: 0014d010 (Loongson-64bit, Loongson-3C6000/S)
  Process kworker/0:5 (pid: 239, threadinfo=927eadc6, 
task=8fd31682)
  Stack : 00040dc03164 0001 90012f210130 90012eabeeb8
  90012f00 8319fe48 90012f21 90012f210130
  90012f00 90012eabeeb8 0001 831a0064
  90010575f9f0 90012f210130 90012eac 90012ea8
  90012f00 831cefc4 90010575f9f0 835859c0
  83414000 90010575fa78 90012f00 831b4c50
   900101c9d700 900109c4 5f5e9200f8901912
  90012d3c4bd0 90012d3c5000 834aed18 90012d380010
  90012d3c4bd0 83414000 90012d38 82ea49dc
  0001 90012d3c6000 e423 0001
  ...
  Call Trace:
  [] dml21_apply_soc_bb_overrides+0x60/0x960 [amdgpu]
  [] dml21_init+0xa4/0x280 [amdgpu]
  [] dml21_create+0x40/0x80 [amdgpu]
  [] dc_state_create+0x100/0x160 [amdgpu]
  [] dc_create+0x44c/0x640 [amdgpu]
  [] amdgpu_dm_init+0x3f8/0x2060 [amdgpu]
  [] dm_hw_init+0x18/0x60 [amdgpu]
  [] amdgpu_device_init+0x1938/0x27e0 [amdgpu]
  [] amdgpu_driver_load_kms+0x20/0xa0 [amdgpu]
  [] amdgpu_pci_probe+0x1b0/0x580 [amdgpu]
  [<9448eae4>] local_pci_probe+0x44/0xc0
  [<93b02b18>] work_for_cpu_fn+0x18/0x40
  [<93b05da0>] process_one_work+0x160/0x300
  [<93b06718>] worker_thread+0x318/0x440
  [<93b11b8c>] kthread+0x12c/0x220
  [<93ac1484>] ret_from_kernel_thread+0x8/0xa4

So protect dml2_create()/dml2_copy()/dml2_create_copy() with DC_FP_START
and DC_FP_END.


Hi Huacai,

Can you try to put DC_FP_START DC_FP_END in the 
dml2_create()/dml2_copy()/dml2_create_copy()/dml2_validate() instead? 
The code will be cleaner and less error-prone to future changes.


Thanks.




Cc: sta...@vger.kernel.org
Signed-off-by: Huacai Chen 
---
  drivers/gpu/drm/amd/display/dc/core/dc_state.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_state.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
index 1b2cce127981..6e2cac08002d 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_state.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_state.c
@@ -210,17 +210,23 @@ struct dc_state *dc_state_create(struct dc *dc, struct 
dc_state_create_params *p
  
  #ifdef CONFIG_DRM_AMD_DC_FP

if (dc->debug.using_dml2) {
+   DC_FP_START();
+
dml2_opt->use_clock_dc_limits = false;
if (!dml2_create(dc, dml2_opt, &state->bw_ctx.dml2)) {
+   DC_FP_END();
dc_state_release(state);
return NULL;
}
  
  		dml2_opt->use_clock_dc_limits = true;

if (!dml2_create(dc, dml2_opt, 
&state->bw_ctx.dml2_dc_power_source)) {
+   DC_FP_END();
dc_state_release(state);
return NULL;
}
+
+   DC_FP_END();
}
  #endif
  
@@ -240,6 +246,8 @@ void dc_state_copy(struct dc_state *dst_state, struct dc_state *src_state)

dc_state_copy_internal(dst_state, src_state);
  
  #ifdef CONFIG_DRM_AMD_DC_FP

+   DC_FP_START();
+
dst_state->bw_ctx.dml2 = dst_dm

Re: [PATCH v7 drm-dp 0/9] Add HPD, getting EDID, colorbar features in DP function

2025-03-19 Thread Yongbang Shi


On Wed, Mar 19, 2025 at 11:24:26AM +0800, Yongbang Shi wrote:

From: Baihan Li 

To support DP HPD, edid printing, and colorbar display features based on
the Hisislcon DP devices.
---
ChangeLog:
v6 -> v7:
   - add if statement about drm aux in hibmc_dp_connector_get_modes(), 
suggested by Jani Nikula

Where was that suggestion? Also, would you please implement his feedback
regarding drm_edid_read()?


Hi Dmitry,
Thanks for yuor mentioned, I misunderstood his suggestion. I will change to 
drm_edid_read().
Thanks, Baihan.



   v6: 
https://lore.kernel.org/all/20250310040138.2025715-1-shiyongb...@huawei.com/
v5 -> v6:
   - fix the DP_SERDES_VOL2_PRE0 value after electrical test.
   - move the detect_ctx() to the patch 7/9.
   - add detect_ctx with 200ms delay, suggested by Dmitry Baryshkov.
   v5: 
https://lore.kernel.org/all/20250307101640.4003229-1-shiyongb...@huawei.com/
v4 -> v5:
   - add commit log about hibmc_kms_init(), suggested by Dmitry Baryshkov.
   - fix the format of block comments, suggested by Dmitry Baryshkov.
   - add hibmc_dp_get_serdes_rate_cfg() to correct transferring serdes cfg.
   - separate the vga part commit, suggested by Dmitry Baryshkov.
   - remove pci_disable_msi() in hibmc_unload()
   v4: 
https://lore.kernel.org/all/20250305112647.2344438-1-shiyongb...@huawei.com/
v3 -> v4:
   - fix the serdes cfg in hibmc_dp_serdes_set_tx_cfg(), suggested by Dmitry 
Baryshkov.
   - move the dp serdes registers to dp_reg.h, suggested by Dmitry Baryshkov.
   - add comments for if-statement of dp_init(), suggested by Dmitry Baryshkov.
   - fix the comment log to imperative sentence, suggested by Dmitry Baryshkov.
   - add comments in hibmc_control_write(), suggested by Dmitry Baryshkov.
   - add link reset of rates and lanes in pre link training process, suggested 
by Dmitry Baryshkov.
   - add vdac detect and connected/disconnected status to enable HPD process, 
suggested by Dmitry Baryshkov.
   - remove a drm_client, suggested by Dmitry Baryshkov.
   - fix build errors reported by kernel test robot 
 Closes: 
https://lore.kernel.org/oe-kbuild-all/202502231304.bczv4y8d-...@intel.com/
   v3: 
https://lore.kernel.org/all/20250222025102.1519798-1-shiyongb...@huawei.com/
v2 -> v3:
   - restructuring the header p_reg.h, suggested by Dmitry Baryshkov.
   - add commit log about dp serdes, suggested by Dmitry Baryshkov.
   - return value in hibmc_dp_serdes_init(), suggested by Dmitry Baryshkov.
   - add static const in the array of serdes_tx_cfg[], suggested by Dmitry 
Baryshkov.
   - change drm_warn to drm_dbg_dp, suggested by Dmitry Baryshkov.
   - add explanations about dp serdes macros, suggested by Dmitry Baryshkov.
   - change commit to an imperative sentence, suggested by Dmitry Baryshkov.
   - put HIBMC_DP_HOST_SERDES_CTRL in dp_serdes.h, suggested by Dmitry 
Baryshkov.
   - split the patch into two parts, suggested by Dmitry Baryshkov.
   - Capitalized EDID and AUX, suggested by Dmitry Baryshkov.
   - rewrite the commit log, suggested by Dmitry Baryshkov.
   - move colorbar debugfs entry to this patch, suggested by Dmitry Baryshkov.
   - change binary format to integer format, suggested by Dmitry Baryshkov.
   - remove mdelay(100) hpd function in ISR, suggested by Dmitry Baryshkov.
   - remove enble_display in ISR, suggested by Dmitry Baryshkov.
   - change drm_kms_helper_connector_hotplug_event() to
 drm_connector_helper_hpd_irq_event(), suggested by Dmitry Baryshkov.
   - move macros to dp_reg.h, suggested by Dmitry Baryshkov.
   - remove struct irqs, suggested by Dmitry Baryshkov.
   - split this patch into two parts, suggested by Dmitry Baryshkov.
   v2: 
https://lore.kernel.org/all/20250210144959.100551-1-shiyongb...@huawei.com/
v1 -> v2:
   - splittting the patch and add more detailed the changes in the commit 
message, suggested by Dmitry Baryshkov.
   - changing all names of dp phy to dp serdes.
   - deleting type conversion, suggested by Dmitry Baryshkov.
   - deleting hibmc_dp_connector_get_modes() and using 
drm_connector_helper_get_modes(), suggested by Dmitry Baryshkov.
   - add colorbar introduction in commit, suggested by Dmitry Baryshkov.
   - deleting edid decoder and its debugfs, suggested by Dmitry Baryshkov.
   - using debugfs_init() callback, suggested by Dmitry Baryshkov.
   - splittting colorbar and debugfs in different patches, suggested by Dmitry 
Baryshkov.
   - optimizing the description in commit message, suggested by Dmitry 
Baryshkov.
   - add mdelay(100) comments, suggested by Dmitry Baryshkov.
   - deleting display enable in hpd event, suggested by Dmitry Baryshkov.
   v1: 
https://lore.kernel.org/all/20250127032024.1542219-1-shiyongb...@huawei.com/
---

Baihan Li (9):
   drm/hisilicon/hibmc: Restructuring the header dp_reg.h
   drm/hisilicon/hibmc: Add dp serdes cfg to adjust serdes rate, voltage
 and pre-emphasis
   drm/hisilicon/hibmc: Add dp serdes cfg in dp process
   drm/hisilicon/hibmc: Refactor the member of drm_aux in struct hibmc_dp
   drm

Re: [PATCH v2 18/57] irqdomain: gpu: Switch to irq_domain_create_linear()

2025-03-19 Thread Jiri Slaby


On 19. 03. 25, 14:31, Alex Deucher wrote:

On Wed, Mar 19, 2025 at 5:44 AM Jiri Slaby (SUSE)  wrote:


irq_domain_add_linear() is going away as being obsolete now. Switch to
the preferred irq_domain_create_linear(). That differs in the first
parameter: It takes more generic struct fwnode_handle instead of struct
device_node. Therefore, of_fwnode_handle() is added around the
parameter.

Note some of the users can likely use dev->fwnode directly instead of
indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not
guaranteed to be set for all, so this has to be investigated on case to
case basis (by people who can actually test with the HW).

Signed-off-by: Jiri Slaby (SUSE) 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Simona Vetter 
Cc: Rob Clark 
Cc: Abhinav Kumar 
Cc: Dmitry Baryshkov 
Cc: Sean Paul 
Cc: Marijn Suijten 
Cc: Philipp Zabel 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 4 ++--
  drivers/gpu/drm/msm/msm_mdss.c  | 2 +-
  drivers/gpu/ipu-v3/ipu-common.c | 4 ++--


I would suggest splitting this by driver.


Done for v3.

thanks,
--
js
suse labs

[PATCH v2] drm/nouveau: prime: fix ttm_bo_delayed_delete oops

2025-03-19 Thread Chris Bainbridge

Fix an oops in ttm_bo_delayed_delete which results from dererencing a
dangling pointer:

Oops: general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b7b:  [#1] PREEMPT SMP
CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 
6.14.0-rc4-00267-g505460b44513-dirty #216
Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024
Workqueue: ttm ttm_bo_delayed_delete [ttm]
RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290
Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 
e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 
01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b
RSP: 0018:bf9383473d60 EFLAGS: 00010202
RAX: 0001 RBX: bf9383473d88 RCX: 
RDX:  RSI:  RDI: 
RBP: bf9383473d78 R08:  R09: 
R10:  R11:  R12: 6b6b6b6b6b6b6b6b
R13: a003bbf78580 R14: a003a6728040 R15: 000383cc
FS:  () GS:a00991c0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 758348024dd0 CR3: 00012c259000 CR4: 00f50ef0
PKRU: 5554
Call Trace:
 
 ? __die_body.cold+0x19/0x26
 ? die_addr+0x3d/0x70
 ? exc_general_protection+0x159/0x460
 ? asm_exc_general_protection+0x27/0x30
 ? dma_resv_iter_first_unlocked+0x55/0x290
 dma_resv_wait_timeout+0x56/0x100
 ttm_bo_delayed_delete+0x69/0xb0 [ttm]
 process_one_work+0x217/0x5c0
 worker_thread+0x1c8/0x3d0
 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0
 kthread+0x10b/0x240
 ? kthreads_online_cpu+0x140/0x140
 ret_from_fork+0x40/0x70
 ? kthreads_online_cpu+0x140/0x140
 ret_from_fork_asm+0x11/0x20
 

The cause of this is:

- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the
  reference to the shared dma_buf. The reference count is 0, so the
  dma_buf is destroyed, which in turn decrements the corresponding
  amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed -
  calling drm_gem_object_release then dma_resv_fini (which destroys the
  reservation object), then finally freeing the amdgpu_bo.

- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory
  formerly allocated to the amdgpu_bo.

- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls
  ttm_bo_release, which schedules ttm_bo_delayed_delete.

- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer,
  resulting in a general protection fault.

Fix this by moving the drm_prime_gem_destroy call from
nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will
be run after ttm_bo_delayed_delete.

Signed-off-by: Chris Bainbridge 
Co-Developed-by: Christian König 
Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/3937
---
 drivers/gpu/drm/drm_prime.c   | 8 ++--
 drivers/gpu/drm/nouveau/nouveau_bo.c  | 3 +++
 drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ---
 3 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 32a8781cfd67..452d5c7cd292 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -929,7 +929,9 @@ EXPORT_SYMBOL(drm_gem_prime_export);
  * &drm_driver.gem_prime_import_sg_table internally.
  *
  * Drivers must arrange to call drm_prime_gem_destroy() from their
- * &drm_gem_object_funcs.free hook when using this function.
+ * &drm_gem_object_funcs.free hook or &ttm_buffer_object.destroy
+ * hook when using this function, to avoid the dma_buf being freed while the
+ * ttm_buffer_object can still dereference it.
  */
 struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev,
struct dma_buf *dma_buf,
@@ -999,7 +1001,9 @@ EXPORT_SYMBOL(drm_gem_prime_import_dev);
  * implementation in drm_gem_prime_fd_to_handle().
  *
  * Drivers must arrange to call drm_prime_gem_destroy() from their
- * &drm_gem_object_funcs.free hook when using this function.
+ * &drm_gem_object_funcs.free hook or &ttm_buffer_object.destroy
+ * hook when using this function, to avoid the dma_buf being freed while the
+ * ttm_buffer_object can still dereference it.
  */
 struct drm_gem_object *drm_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index db961eade225..2016c1e7242f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -144,6 +144,9 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
nouveau_bo_del_io_reserve_lru(bo);
nv10_bo_put_tile_region(dev, nvbo->tile, NULL);
 
+   if (bo->base.import_attach)
+   drm_prime_gem_destroy(&bo->base, bo->sg);
+
/*
 * If nouveau_bo_new() allocated this buffer, the GEM object was never
 * initialized, so don't attempt to release it.
diff --gi

Re: [PATCH 2/2] drm/amd/display: Protect dml2_validate() from its callers

2025-03-19 Thread Alex Hung


Please see comments for patch 1.

On 3/18/25 05:17, Huacai Chen wrote:

Similar to dml2_create()/dml2_copy()/dml2_create_copy(), dml2_validate()
should also be protected from its callers because "All the DC_FP_START/END
should be used before call anything from DML2".

So protect dml2_validate() with DC_FP_START() and DC_FP_END(), otherwise
it causes such errors:

  do_fpu invoked from kernel context![#1]:
  CPU: 10 UID: 0 PID: 331 Comm: kworker/10:1H Not tainted 6.14.0-rc6+ #4
  Workqueue: events_highpri dm_irq_work_func [amdgpu]
  pc 83191eb0 ra 83191e60 tp 900107a94000 sp 
900107a975b0
  a0 900140ce4910 a1  a2 900140ce49b0 a3 
900140ce49a8
  a4 900140ce49a8 a5 0001 a6 0001 a7 
900107a97660
  t0 8379 t1 900140ce5000 t2 0001 t3 

  t4 0004 t5  t6  t7 

  t8 0001 u0 831a3b9c s9 900130bc s0 
90013240
  s1 900140ec s2 90013240 s3 900140ce s4 
957f8b88
  s5 900140ec s6 900140ce4910 s7 0001 s8 
900130d45010
  ra: 83191e60 dml21_map_dc_state_into_dml_display_cfg+0x40/0x1140 
[amdgpu]
ERA: 83191eb0 dml21_map_dc_state_into_dml_display_cfg+0x90/0x1140 
[amdgpu]
   CRMD: 00b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
   PRMD: 0004 (PPLV0 +PIE -PWE)
   EUEN:  (-FPE -SXE -ASXE -BTE)
   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
  ESTAT: 000f [FPD] (IS= ECode=15 EsubCode=0)
   PRID: 0014d010 (Loongson-64bit, Loongson-3C6000/S)
  Process kworker/10:1H (pid: 331, threadinfo=7bf9ddb0, 
task=cc4ab9f3)
  Stack : 0001 04380780 00010001 00010001
   0780 0438 0780
  0438 0780 0438 0001
  0001 0001 0001 0001
  0001 900140ec 90013240 90013240
  83408000 83408000 90013240 900140ce
  900140ce 83193850 0001 900140ec
  90013240 900140ec0860 900140ec0738 0001
  9001405e8000 900130bc 900140ec02a8 831b5db8
   04380780 0003 831b79cc
  ...
  Call Trace:
  [] dml21_map_dc_state_into_dml_display_cfg+0x90/0x1140 
[amdgpu]
  [] dml21_validate+0xcc/0x520 [amdgpu]
  [] dc_validate_global_state+0x2e8/0x460 [amdgpu]
  [] create_validate_stream_for_sink+0x3d4/0x420 [amdgpu]
  [] amdgpu_dm_connector_mode_valid+0x64/0x240 [amdgpu]
  [<9441d6b8>] drm_connector_mode_valid+0x38/0x80
  [<9441d824>] __drm_helper_update_and_validate+0x124/0x3e0
  [<9441ddc0>] drm_helper_probe_single_connector_modes+0x2e0/0x620
  [<944050dc>] drm_client_modeset_probe+0x23c/0x1780
  [<94420384>] __drm_fb_helper_initial_config_and_unlock+0x44/0x5a0
  [<94403acc>] drm_client_dev_hotplug+0xcc/0x140
  [] handle_hpd_irq_helper+0x1b0/0x1e0 [amdgpu]
  [<938f5da0>] process_one_work+0x160/0x300
  [<938f6718>] worker_thread+0x318/0x440
  [<93901b8c>] kthread+0x12c/0x220
  [<938b1484>] ret_from_kernel_thread+0x8/0xa4

Cc: sta...@vger.kernel.org
Signed-off-by: Huacai Chen 
---
  .../gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c   | 5 -
  .../gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c   | 2 ++
  .../gpu/drm/amd/display/dc/resource/dcn351/dcn351_resource.c | 2 ++
  .../gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c | 5 -
  4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c 
b/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
index 664302876019..63ef8629d7ed 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn32/dcn32_resource.c
@@ -1811,10 +1811,13 @@ bool dcn32_validate_bandwidth(struct dc *dc,
  {
bool out = false;
  
-	if (dc->debug.using_dml2)

+   if (dc->debug.using_dml2) {
+   DC_FP_START();
out = dml2_validate(dc, context,
context->power_source == DC_POWER_SOURCE_DC ? 
context->bw_ctx.dml2_dc_power_source : context->bw_ctx.dml2,
fast_validate);
+   DC_FP_END();
+   }
else
out = dml1_validate(dc, context, fast_validate);
return out;
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c 
b/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resource.c
index 8ee3d99ea2aa..0495c8dbcf1e 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn35/dcn35_resou

Re: [PATCH v6 drm-dp 5/9] drm/hisilicon/hibmc: Getting connector info and EDID by using AUX channel

2025-03-19 Thread Yongbang Shi





On Mon, 10 Mar 2025, Yongbang Shi  wrote:

@@ -15,11 +15,17 @@
  
  static int hibmc_dp_connector_get_modes(struct drm_connector *connector)

  {
+   struct hibmc_dp *dp = to_hibmc_dp(connector);
+   const struct drm_edid *drm_edid;
int count;
  
-	count = drm_add_modes_noedid(connector, connector->dev->mode_config.max_width,

-connector->dev->mode_config.max_height);
-   drm_set_preferred_mode(connector, 1024, 768); // temporary 
implementation
+   drm_edid = drm_edid_read_ddc(connector, &dp->aux.ddc);

drm_edid_read() should cover this if connector->ddc is set properly...


Thanks, I got it. I will change it to drm_edid_read() in next patch. I 
misunderstood what you meant before.



@@ -103,8 +125,8 @@ int hibmc_dp_init(struct hibmc_drm_private *priv)
  
  	drm_encoder_helper_add(encoder, &hibmc_dp_encoder_helper_funcs);
  
-	ret = drm_connector_init(dev, connector, &hibmc_dp_conn_funcs,

-DRM_MODE_CONNECTOR_DisplayPort);
+   ret = drm_connector_init_with_ddc(dev, connector, &hibmc_dp_conn_funcs,
+ DRM_MODE_CONNECTOR_DisplayPort, 
&dp->aux.ddc);

...which you seem to do here.

BR,
Jani.

[PATCH 1/2] arm64: dts: qcom: sa8775p: add GPDSP fastrpc-compute-cb nodes

2025-03-19 Thread Ling Xu

Add GPDSP0 and GPDSP1 fastrpc compute-cb nodes for sa8775p SoC.

Signed-off-by: Ling Xu 
---
 arch/arm64/boot/dts/qcom/sa8775p.dtsi | 58 +++
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi 
b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
index 581dac8556ec..28025c76c96a 100644
--- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi
+++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi
@@ -4850,6 +4850,35 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
 
label = "gpdsp0";
qcom,remote-pid = <17>;
+
+   fastrpc {
+   compatible = "qcom,fastrpc";
+   qcom,glink-channels = 
"fastrpcglink-apps-dsp";
+   label = "gdsp0";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   compute-cb@1 {
+   compatible = 
"qcom,fastrpc-compute-cb";
+   reg = <1>;
+   iommus = <&apps_smmu 0x38a1 
0x0>;
+   dma-coherent;
+   };
+
+   compute-cb@2 {
+   compatible = 
"qcom,fastrpc-compute-cb";
+   reg = <2>;
+   iommus = <&apps_smmu 0x38a2 
0x0>;
+   dma-coherent;
+   };
+
+   compute-cb@3 {
+   compatible = 
"qcom,fastrpc-compute-cb";
+   reg = <3>;
+   iommus = <&apps_smmu 0x38a3 
0x0>;
+   dma-coherent;
+   };
+   };
};
};
 
@@ -4893,6 +4922,35 @@ IPCC_MPROC_SIGNAL_GLINK_QMP
 
label = "gpdsp1";
qcom,remote-pid = <18>;
+
+   fastrpc {
+   compatible = "qcom,fastrpc";
+   qcom,glink-channels = 
"fastrpcglink-apps-dsp";
+   label = "gdsp1";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   compute-cb@1 {
+   compatible = 
"qcom,fastrpc-compute-cb";
+   reg = <1>;
+   iommus = <&apps_smmu 0x38c1 
0x0>;
+   dma-coherent;
+   };
+
+   compute-cb@2 {
+   compatible = 
"qcom,fastrpc-compute-cb";
+   reg = <2>;
+   iommus = <&apps_smmu 0x38c2 
0x0>;
+   dma-coherent;
+   };
+
+   compute-cb@3 {
+   compatible = 
"qcom,fastrpc-compute-cb";
+   reg = <3>;
+   iommus = <&apps_smmu 0x38c3 
0x0>;
+   dma-coherent;
+   };
+   };
};
};
 
-- 
2.34.1

Re: linux-next: build failure after merge of the driver-core tree

2025-03-19 Thread Stephen Rothwell

Hi Danilo,

On Wed, 19 Mar 2025 12:16:39 +0100 Danilo Krummrich  wrote:
>
> The following diff should fix the below conflict.
> 
> diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
> index 63c19f140fbd..a08fb6599267 100644
> --- a/drivers/gpu/nova-core/driver.rs
> +++ b/drivers/gpu/nova-core/driver.rs
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  
> -use kernel::{bindings, c_str, pci, prelude::*};
> +use kernel::{bindings, c_str, device::Core, pci, prelude::*};
>  
>  use crate::gpu::Gpu;
>  
> @@ -27,7 +27,7 @@ impl pci::Driver for NovaCore {
>  type IdInfo = ();
>  const ID_TABLE: pci::IdTable = &PCI_TABLE;
>  
> -fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> 
> Result>> {
> +fn probe(pdev: &pci::Device, _info: &Self::IdInfo) -> 
> Result>> {
>  dev_dbg!(pdev.as_ref(), "Probe Nova Core GPU driver.\n");
>  
>  pdev.enable_device_mem()?;
> 

I have added that to the merge resolution for the merge of the
driver-core tree today and it works for me.  Thanks.

-- 
Cheers,
Stephen Rothwell


pgpG8XLxGFQOu.pgp
Description: OpenPGP digital signature

[PATCH v2 18/57] irqdomain: gpu: Switch to irq_domain_create_linear()

2025-03-19 Thread Jiri Slaby (SUSE)

irq_domain_add_linear() is going away as being obsolete now. Switch to
the preferred irq_domain_create_linear(). That differs in the first
parameter: It takes more generic struct fwnode_handle instead of struct
device_node. Therefore, of_fwnode_handle() is added around the
parameter.

Note some of the users can likely use dev->fwnode directly instead of
indirect of_fwnode_handle(dev->of_node). But dev->fwnode is not
guaranteed to be set for all, so this has to be investigated on case to
case basis (by people who can actually test with the HW).

Signed-off-by: Jiri Slaby (SUSE) 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Simona Vetter 
Cc: Rob Clark 
Cc: Abhinav Kumar 
Cc: Dmitry Baryshkov 
Cc: Sean Paul 
Cc: Marijn Suijten 
Cc: Philipp Zabel 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 4 ++--
 drivers/gpu/drm/msm/msm_mdss.c  | 2 +-
 drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index 19ce4da285e8..38e7043016e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -725,8 +725,8 @@ static const struct irq_domain_ops amdgpu_hw_irqdomain_ops 
= {
  */
 int amdgpu_irq_add_domain(struct amdgpu_device *adev)
 {
-   adev->irq.domain = irq_domain_add_linear(NULL, AMDGPU_MAX_IRQ_SRC_ID,
-&amdgpu_hw_irqdomain_ops, 
adev);
+   adev->irq.domain = irq_domain_create_linear(NULL, AMDGPU_MAX_IRQ_SRC_ID,
+   &amdgpu_hw_irqdomain_ops, 
adev);
if (!adev->irq.domain) {
DRM_ERROR("GPU irq add domain failed\n");
return -ENODEV;
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index dcb49fd30402..9d006ee88a8a 100644
--- a/drivers/gpu/drm/msm/msm_mdss.c
+++ b/drivers/gpu/drm/msm/msm_mdss.c
@@ -150,7 +150,7 @@ static int _msm_mdss_irq_domain_add(struct msm_mdss 
*msm_mdss)
 
dev = msm_mdss->dev;
 
-   domain = irq_domain_add_linear(dev->of_node, 32,
+   domain = irq_domain_create_linear(of_fwnode_handle(dev->of_node), 32,
&msm_mdss_irqdomain_ops, msm_mdss);
if (!domain) {
dev_err(dev, "failed to add irq_domain\n");
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index fa77e4e64f12..223e6d563a6b 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1169,8 +1169,8 @@ static int ipu_irq_init(struct ipu_soc *ipu)
};
int ret, i;
 
-   ipu->domain = irq_domain_add_linear(ipu->dev->of_node, IPU_NUM_IRQS,
-   &irq_generic_chip_ops, ipu);
+   ipu->domain = 
irq_domain_create_linear(of_fwnode_handle(ipu->dev->of_node), IPU_NUM_IRQS,
+  &irq_generic_chip_ops, ipu);
if (!ipu->domain) {
dev_err(ipu->dev, "failed to add irq domain\n");
return -ENODEV;
-- 
2.49.0

[PATCH 05/18] drm/sysfb: Add struct drm_sysfb_device

Add struct drm_sysfb_device that stores the system display's hardware
settings. Further helpers for the mode-setting pipeline will use these
fields. Convert ofdrm and simpledrm by embedding the sysfb device in
their device structs.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/Kconfig|  6 ++
 drivers/gpu/drm/sysfb/Makefile   |  2 +
 drivers/gpu/drm/sysfb/drm_sysfb_helper.c |  8 +++
 drivers/gpu/drm/sysfb/drm_sysfb_helper.h | 35 +
 drivers/gpu/drm/sysfb/ofdrm.c| 78 ++--
 drivers/gpu/drm/sysfb/simpledrm.c| 90 
 6 files changed, 135 insertions(+), 84 deletions(-)
 create mode 100644 drivers/gpu/drm/sysfb/drm_sysfb_helper.c
 create mode 100644 drivers/gpu/drm/sysfb/drm_sysfb_helper.h

diff --git a/drivers/gpu/drm/sysfb/Kconfig b/drivers/gpu/drm/sysfb/Kconfig
index 9eafc06b7192..87094da417f6 100644
--- a/drivers/gpu/drm/sysfb/Kconfig
+++ b/drivers/gpu/drm/sysfb/Kconfig
@@ -3,6 +3,10 @@
 menu "Drivers for system framebuffers"
depends on DRM
 
+config DRM_SYSFB_HELPER
+   tristate
+   depends on DRM
+
 config DRM_OFDRM
tristate "Open Firmware display driver"
depends on DRM && MMU && OF && (PPC || COMPILE_TEST)
@@ -10,6 +14,7 @@ config DRM_OFDRM
select DRM_CLIENT_SELECTION
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
+   select DRM_SYSFB_HELPER
help
  DRM driver for Open Firmware framebuffers.
 
@@ -24,6 +29,7 @@ config DRM_SIMPLEDRM
select DRM_CLIENT_SELECTION
select DRM_GEM_SHMEM_HELPER
select DRM_KMS_HELPER
+   select DRM_SYSFB_HELPER
help
  DRM driver for simple platform-provided framebuffers.
 
diff --git a/drivers/gpu/drm/sysfb/Makefile b/drivers/gpu/drm/sysfb/Makefile
index f6c03629accb..f1e8700c3e35 100644
--- a/drivers/gpu/drm/sysfb/Makefile
+++ b/drivers/gpu/drm/sysfb/Makefile
@@ -1,4 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0-only
 
+obj-$(CONFIG_DRM_SYSFB_HELPER) += drm_sysfb_helper.o
+
 obj-$(CONFIG_DRM_OFDRM)+= ofdrm.o
 obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
new file mode 100644
index ..c083d21fd9ca
--- /dev/null
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+
+#include "drm_sysfb_helper.h"
+
+MODULE_DESCRIPTION("Helpers for DRM sysfb drivers");
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
new file mode 100644
index ..8f05eee7f49e
--- /dev/null
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
@@ -0,0 +1,35 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+#ifndef DRM_SYSFB_HELPER_H
+#define DRM_SYSFB_HELPER_H
+
+#include 
+#include 
+
+#include 
+#include 
+
+struct drm_format_info;
+
+/*
+ * Device
+ */
+
+struct drm_sysfb_device {
+   struct drm_device dev;
+
+   /* hardware settings */
+   struct drm_display_mode fb_mode;
+   const struct drm_format_info *fb_format;
+   unsigned int fb_pitch;
+
+   /* hardware-framebuffer kernel address */
+   struct iosys_map fb_addr;
+};
+
+static inline struct drm_sysfb_device *to_drm_sysfb_device(struct drm_device 
*dev)
+{
+   return container_of(dev, struct drm_sysfb_device, dev);
+}
+
+#endif
diff --git a/drivers/gpu/drm/sysfb/ofdrm.c b/drivers/gpu/drm/sysfb/ofdrm.c
index 7d5beaf6a42c..d42704facb45 100644
--- a/drivers/gpu/drm/sysfb/ofdrm.c
+++ b/drivers/gpu/drm/sysfb/ofdrm.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 
+#include "drm_sysfb_helper.h"
+
 #define DRIVER_NAME"ofdrm"
 #define DRIVER_DESC"DRM driver for OF platform devices"
 #define DRIVER_MAJOR   1
@@ -289,16 +291,10 @@ struct ofdrm_device_funcs {
 };
 
 struct ofdrm_device {
-   struct drm_device dev;
+   struct drm_sysfb_device sysfb;
 
const struct ofdrm_device_funcs *funcs;
 
-   /* firmware-buffer settings */
-   struct iosys_map screen_base;
-   struct drm_display_mode mode;
-   const struct drm_format_info *format;
-   unsigned int pitch;
-
/* colormap */
void __iomem *cmap_base;
 
@@ -312,7 +308,7 @@ struct ofdrm_device {
 
 static struct ofdrm_device *ofdrm_device_of_dev(struct drm_device *dev)
 {
-   return container_of(dev, struct ofdrm_device, dev);
+   return container_of(to_drm_sysfb_device(dev), struct ofdrm_device, 
sysfb);
 }
 
 /*
@@ -352,7 +348,7 @@ static void ofdrm_pci_release(void *data)
 
 static int ofdrm_device_init_pci(struct ofdrm_device *odev)
 {
-   struct drm_device *dev = &odev->dev;
+   struct drm_device *dev = &odev->sysfb.dev;
struct platform_device *pdev = to_platform_device(dev->dev);
struct device_node *of_node = pdev->dev.of_node;
struct pci_dev *pcidev;
@@ -395,7 +391,7 @@ static int ofdrm_device_init_pci(struct ofdr

[PATCH 06/18] drm/sysfb: Provide single mode-init helper

Merge the mode-init functions of ofdrm and simpledrm to the new helper
drm_sysfb_mode(). Also implement the DPI defaults there. Replace the
code in each driver with the shared helper.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/drm_sysfb_helper.c | 24 
 drivers/gpu/drm/sysfb/drm_sysfb_helper.h |  5 +
 drivers/gpu/drm/sysfb/ofdrm.c| 17 +
 drivers/gpu/drm/sysfb/simpledrm.c| 23 +--
 4 files changed, 31 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
index c083d21fd9ca..6deeac81a41d 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
@@ -6,3 +6,27 @@
 
 MODULE_DESCRIPTION("Helpers for DRM sysfb drivers");
 MODULE_LICENSE("GPL");
+
+struct drm_display_mode drm_sysfb_mode(unsigned int width,
+  unsigned int height,
+  unsigned int width_mm,
+  unsigned int height_mm)
+{
+   /*
+* Assume a monitor resolution of 96 dpi to
+* get a somewhat reasonable screen size.
+*/
+   if (!width_mm)
+   width_mm = DRM_MODE_RES_MM(width, 96ul);
+   if (!height_mm)
+   height_mm = DRM_MODE_RES_MM(height, 96ul);
+
+   {
+   const struct drm_display_mode mode = {
+   DRM_MODE_INIT(60, width, height, width_mm, height_mm)
+   };
+
+   return mode;
+   }
+}
+EXPORT_SYMBOL(drm_sysfb_mode);
diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
index 8f05eee7f49e..8b4cc4af702b 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
@@ -11,6 +11,11 @@
 
 struct drm_format_info;
 
+struct drm_display_mode drm_sysfb_mode(unsigned int width,
+  unsigned int height,
+  unsigned int width_mm,
+  unsigned int height_mm);
+
 /*
  * Device
  */
diff --git a/drivers/gpu/drm/sysfb/ofdrm.c b/drivers/gpu/drm/sysfb/ofdrm.c
index d42704facb45..7df6901157fb 100644
--- a/drivers/gpu/drm/sysfb/ofdrm.c
+++ b/drivers/gpu/drm/sysfb/ofdrm.c
@@ -1070,21 +1070,6 @@ static const struct ofdrm_device_funcs 
ofdrm_qemu_device_funcs = {
.cmap_write = ofdrm_qemu_cmap_write,
 };
 
-static struct drm_display_mode ofdrm_mode(unsigned int width, unsigned int 
height)
-{
-   /*
-* Assume a monitor resolution of 96 dpi to
-* get a somewhat reasonable screen size.
-*/
-   const struct drm_display_mode mode = {
-   DRM_MODE_INIT(60, width, height,
- DRM_MODE_RES_MM(width, 96ul),
- DRM_MODE_RES_MM(height, 96ul))
-   };
-
-   return mode;
-}
-
 static struct ofdrm_device *ofdrm_device_create(struct drm_driver *drv,
struct platform_device *pdev)
 {
@@ -1251,7 +1236,7 @@ static struct ofdrm_device *ofdrm_device_create(struct 
drm_driver *drv,
 */
 
iosys_map_set_vaddr_iomem(&sysfb->fb_addr, screen_base);
-   sysfb->fb_mode = ofdrm_mode(width, height);
+   sysfb->fb_mode = drm_sysfb_mode(width, height, 0, 0);
sysfb->fb_format = format;
sysfb->fb_pitch = linebytes;
 
diff --git a/drivers/gpu/drm/sysfb/simpledrm.c 
b/drivers/gpu/drm/sysfb/simpledrm.c
index f258d8cdb6b6..149df6941b6c 100644
--- a/drivers/gpu/drm/sysfb/simpledrm.c
+++ b/drivers/gpu/drm/sysfb/simpledrm.c
@@ -756,18 +756,6 @@ static const struct drm_mode_config_funcs 
simpledrm_mode_config_funcs = {
  * Init / Cleanup
  */
 
-static struct drm_display_mode simpledrm_mode(unsigned int width,
- unsigned int height,
- unsigned int width_mm,
- unsigned int height_mm)
-{
-   const struct drm_display_mode mode = {
-   DRM_MODE_INIT(60, width, height, width_mm, height_mm)
-   };
-
-   return mode;
-}
-
 static struct simpledrm_device *simpledrm_device_create(struct drm_driver *drv,
struct platform_device 
*pdev)
 {
@@ -855,16 +843,7 @@ static struct simpledrm_device 
*simpledrm_device_create(struct drm_driver *drv,
return ERR_PTR(-EINVAL);
}
 
-   /*
-* Assume a monitor resolution of 96 dpi if physical dimensions
-* are not specified to get a somewhat reasonable screen size.
-*/
-   if (!width_mm)
-   width_mm = DRM_MODE_RES_MM(width, 96ul);
-   if (!height_mm)
-   height_mm = DRM_MODE_RES_MM(height, 96ul);
-
-   sysfb->fb_mode = simpledrm_mode(width, height, width_mm, heigh

Re: [PATCH 1/2] drm/sched: add drm_sched_prealloc_dependency_slots

Am 18.03.25 um 13:39 schrieb Danilo Krummrich:
> On Tue, Mar 18, 2025 at 01:03:12PM +0100, Christian König wrote:
>>  /**
>>   * drm_sched_job_add_dependency - adds the fence as a job dependency
>>   * @job: scheduler job to add the dependencies to
>> @@ -878,10 +910,12 @@ int drm_sched_job_add_dependency(struct drm_sched_job 
>> *job,
>>   * engines involved, rather than the number of BOs.
>>   */
>>  xa_for_each(&job->dependencies, index, entry) {
>> -if (entry->context != fence->context)
>> +bool signaled = dma_fence_is_signaled(entry);
>> +
>> +if (!signaled && entry->context != fence->context)
>>  continue;
>>  
>> -if (dma_fence_is_later(fence, entry)) {
>> +if (signaled || dma_fence_is_later(fence, entry)) {
>>  dma_fence_put(entry);
>>  xa_store(&job->dependencies, index, fence, GFP_KERNEL);
>>  } else {
>> @@ -890,7 +924,8 @@ int drm_sched_job_add_dependency(struct drm_sched_job 
>> *job,
>>  return 0;
>>  }
>>  
>> -ret = xa_alloc(&job->dependencies, &id, fence, xa_limit_32b, 
>> GFP_KERNEL);
>> +ret = xa_alloc(&job->dependencies, &id, fence, xa_limit_32b,
>> +   GFP_KERNEL);
>>  if (ret != 0)
>>  dma_fence_put(fence);
> Those changes seem unrelated, aren't they?

Ah, yes that was just a leftover from a previous try to fix this.

Thanks,
Christian.

[PATCH v9 3/3] drm/i915/display: Add i915 hook for format_mod_supported_async

2025-03-19 Thread Arun R Murthy

Hook up the newly added plane function pointer
format_mod_supported_async to populate the modifiers/formats supported
by asynchronous flips.

v5: Correct the if condition for modifier support check (Chaitanya)
v6: Replace uint32_t/uint64_t with u32/u64 (Jani)
v7: Move plannar check from intel_async_flip_check_hw() to
intel_plane_format_mod_supported_async() (Ville)
v8: In case of error print format/modifier (Chaitanya)
v9: Exclude C8 format as its not supported by hardware

Signed-off-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/i9xx_plane.c  |  6 ++--
 drivers/gpu/drm/i915/display/intel_atomic_plane.c  | 32 +-
 drivers/gpu/drm/i915/display/intel_atomic_plane.h  |  6 +++-
 drivers/gpu/drm/i915/display/intel_display.c   | 14 +++---
 drivers/gpu/drm/i915/display/skl_universal_plane.c |  5 +++-
 5 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/i9xx_plane.c 
b/drivers/gpu/drm/i915/display/i9xx_plane.c
index 
013295f66d56ec5e919b3a0c904034bf7985986a..6bd09adb8a30ba002ef334261d7638f398587a3e
 100644
--- a/drivers/gpu/drm/i915/display/i9xx_plane.c
+++ b/drivers/gpu/drm/i915/display/i9xx_plane.c
@@ -820,7 +820,7 @@ unsigned int vlv_plane_min_alignment(struct intel_plane 
*plane,
 {
struct intel_display *display = to_intel_display(plane);
 
-   if (intel_plane_can_async_flip(plane, fb->modifier))
+   if (intel_plane_can_async_flip(plane, fb->format->format, fb->modifier))
return 256 * 1024;
 
/* FIXME undocumented so not sure what's actually needed */
@@ -844,7 +844,7 @@ static unsigned int g4x_primary_min_alignment(struct 
intel_plane *plane,
 {
struct intel_display *display = to_intel_display(plane);
 
-   if (intel_plane_can_async_flip(plane, fb->modifier))
+   if (intel_plane_can_async_flip(plane, fb->format->format, fb->modifier))
return 256 * 1024;
 
if (intel_scanout_needs_vtd_wa(display))
@@ -889,6 +889,7 @@ static const struct drm_plane_funcs i965_plane_funcs = {
.atomic_duplicate_state = intel_plane_duplicate_state,
.atomic_destroy_state = intel_plane_destroy_state,
.format_mod_supported = i965_plane_format_mod_supported,
+   .format_mod_supported_async = intel_plane_format_mod_supported_async,
 };
 
 static const struct drm_plane_funcs i8xx_plane_funcs = {
@@ -898,6 +899,7 @@ static const struct drm_plane_funcs i8xx_plane_funcs = {
.atomic_duplicate_state = intel_plane_duplicate_state,
.atomic_destroy_state = intel_plane_destroy_state,
.format_mod_supported = i8xx_plane_format_mod_supported,
+   .format_mod_supported_async = intel_plane_format_mod_supported_async,
 };
 
 struct intel_plane *
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c 
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 
7276179df878658b7053fe6d8dc37b69f19625e3..ce6bf6fe8f241a9517e8f74fb002b835c3f0853a
 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -174,11 +174,41 @@ bool intel_plane_needs_physical(struct intel_plane *plane)
DISPLAY_INFO(display)->cursor_needs_physical;
 }
 
-bool intel_plane_can_async_flip(struct intel_plane *plane, u64 modifier)
+bool intel_plane_can_async_flip(struct intel_plane *plane, u32 format,
+   u64 modifier)
 {
+   struct intel_display *display = to_intel_display(plane);
+
+   if ((DISPLAY_VER(display) <= 14 ?
+   drm_format_info(format)->is_yuv :
+   intel_format_info_is_yuv_semiplanar(drm_format_info(format),
+   modifier)) ||
+   format == DRM_FORMAT_C8) {
+   drm_dbg_kms(plane->base.dev,
+   "[PLANE:%d:%s] Planar formats do not support async 
flips\n",
+   plane->base.base.id, plane->base.name);
+   return false;
+   }
+
return plane->can_async_flip && plane->can_async_flip(modifier);
 }
 
+bool intel_plane_format_mod_supported_async(struct drm_plane *plane,
+   u32 format,
+   u64 modifier)
+{
+   if (plane->funcs->format_mod_supported &&
+   !plane->funcs->format_mod_supported(plane, format, modifier)) {
+   drm_dbg_kms(plane->dev,
+   "[PLANE:%d:%s](format %p4cc) modifier 0x%llx not in 
universal list\n",
+   plane->base.id, plane->name, &format, modifier);
+   return false;
+   }
+
+   return intel_plane_can_async_flip(to_intel_plane(plane),
+   format, modifier);
+}
+
 unsigned int intel_adjusted_rate(const struct drm_rect *src,
 const struct drm_rect *dst,
 unsigned int rate)
diff --git a/drivers/gpu/drm/i915/disp

[PATCH v9 2/3] drm/plane: modify create_in_formats to accommodate async

2025-03-19 Thread Arun R Murthy

create_in_formats creates the list of supported format/modifiers for
synchronous flips, modify the same function so as to take the
format_mod_supported as argument and create list of format/modifier for
async as well.

v5: create_in_formats can return -ve value in failure case, correct the
if condition to check the creation of blob 
Dont add the modifier for which none of the formats is not supported.
v6: Remove the code for masking the unsupported modifiers as UMD can
leave with it. (Naveen/Chaitanya)
v7: Retain the unsupported modifiers, userspace should have no
impact, return pointer to blob instead of blob_id(Ville)

Signed-off-by: Arun R Murthy 
Reviewed-by: Chaitanya Kumar Borah 
Tested-by: Naveen Kumar 
---
 drivers/gpu/drm/drm_plane.c | 44 +++-
 1 file changed, 31 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 
fe181c1002171acc68d3054c2d178f9b9f501fe2..5cd3956caf414fa72432f9d23fa289ec266408ce
 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -193,9 +193,13 @@ modifiers_ptr(struct drm_format_modifier_blob *blob)
return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
 }
 
-static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane)
+static struct drm_property_blob *create_in_format_blob(struct drm_device *dev,
+  struct drm_plane *plane,
+  bool 
(*format_mod_supported)
+  (struct drm_plane *plane,
+   u32 format,
+   u64 modifier))
 {
-   const struct drm_mode_config *config = &dev->mode_config;
struct drm_property_blob *blob;
struct drm_format_modifier *mod;
size_t blob_size, formats_size, modifiers_size;
@@ -221,7 +225,7 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
 
blob = drm_property_create_blob(dev, blob_size, NULL);
if (IS_ERR(blob))
-   return -1;
+   return PTR_ERR(blob);
 
blob_data = blob->data;
blob_data->version = FORMAT_BLOB_CURRENT;
@@ -237,10 +241,10 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
mod = modifiers_ptr(blob_data);
for (i = 0; i < plane->modifier_count; i++) {
for (j = 0; j < plane->format_count; j++) {
-   if (!plane->funcs->format_mod_supported ||
-   plane->funcs->format_mod_supported(plane,
-  
plane->format_types[j],
-  
plane->modifiers[i])) {
+   if (!format_mod_supported ||
+   format_mod_supported(plane,
+plane->format_types[j],
+plane->modifiers[i])) {
mod->formats |= 1ULL << j;
}
}
@@ -251,10 +255,7 @@ static int create_in_format_blob(struct drm_device *dev, 
struct drm_plane *plane
mod++;
}
 
-   drm_object_attach_property(&plane->base, config->modifiers_property,
-  blob->base.id);
-
-   return 0;
+   return blob;
 }
 
 /**
@@ -366,6 +367,7 @@ static int __drm_universal_plane_init(struct drm_device 
*dev,
  const char *name, va_list ap)
 {
struct drm_mode_config *config = &dev->mode_config;
+   struct drm_property_blob *blob;
static const uint64_t default_modifiers[] = {
DRM_FORMAT_MOD_LINEAR,
};
@@ -477,8 +479,24 @@ static int __drm_universal_plane_init(struct drm_device 
*dev,
drm_plane_create_hotspot_properties(plane);
}
 
-   if (format_modifier_count)
-   create_in_format_blob(dev, plane);
+   if (format_modifier_count) {
+   blob = create_in_format_blob(dev, plane,
+
plane->funcs->format_mod_supported);
+   if (!IS_ERR(blob))
+   drm_object_attach_property(&plane->base,
+  config->modifiers_property,
+  blob->base.id);
+   }
+
+   if (plane->funcs->format_mod_supported_async) {
+   blob = create_in_format_blob(dev, plane,
+
plane->funcs->format_mod_supported_async);
+   if (!IS_ERR(blob))
+   drm_object_attach_property(&plane->base,
+  
config-

Re: linux-next: build failure after merge of the driver-core tree

2025-03-19 Thread Danilo Krummrich

Hi Stephen,

On Wed, Mar 19, 2025 at 08:07:46PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the driver-core tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

The following diff should fix the below conflict.

diff --git a/drivers/gpu/nova-core/driver.rs b/drivers/gpu/nova-core/driver.rs
index 63c19f140fbd..a08fb6599267 100644
--- a/drivers/gpu/nova-core/driver.rs
+++ b/drivers/gpu/nova-core/driver.rs
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 
-use kernel::{bindings, c_str, pci, prelude::*};
+use kernel::{bindings, c_str, device::Core, pci, prelude::*};
 
 use crate::gpu::Gpu;
 
@@ -27,7 +27,7 @@ impl pci::Driver for NovaCore {
 type IdInfo = ();
 const ID_TABLE: pci::IdTable = &PCI_TABLE;
 
-fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> 
Result>> {
+fn probe(pdev: &pci::Device, _info: &Self::IdInfo) -> 
Result>> {
 dev_dbg!(pdev.as_ref(), "Probe Nova Core GPU driver.\n");
 
 pdev.enable_device_mem()?;

> 
> error[E0053]: method `probe` has an incompatible type for trait
>   --> drivers/gpu/nova-core/driver.rs:30:20
>|
> 30 | fn probe(pdev: &mut pci::Device, _info: &Self::IdInfo) -> 
> Result>> {
>| types differ in mutability
>|
>= note: expected signature `fn(&kernel::pci::Device, &()) -> 
> core::result::Result<_, _>`
>   found signature `fn(&mut 
> kernel::pci::Device, &()) -> core::result::Result<_, 
> _>`
> help: change the parameter type to match the trait
>|
> 30 | fn probe(pdev: &kernel::pci::Device, _info: &Self::IdInfo) -> 
> Result>> {
>|~~
> 
> error[E0599]: no method named `enable_device_mem` found for mutable reference 
> `&mut kernel::pci::Device` in the current scope
>   --> drivers/gpu/nova-core/driver.rs:33:14
>|
> 33 | pdev.enable_device_mem()?;
>|  ^ method not found in `&mut Device`
> 
> error[E0599]: no method named `set_master` found for mutable reference `&mut 
> kernel::pci::Device` in the current scope
>   --> drivers/gpu/nova-core/driver.rs:34:14
>|
> 34 | pdev.set_master();
>|  ^^ method not found in `&mut Device`
> 
> error: aborting due to 3 previous errors
> 
> Some errors have detailed explanations: E0053, E0599.
> For more information about an error, try `rustc --explain E0053`.
> 
> Presumably caused by commit
> 
>   7b948a2af6b5 ("rust: pci: fix unrestricted &mut pci::Device")
> 
> interacting with commit
> 
>   54e6baf123fd ("gpu: nova-core: add initial driver stub")
> 
> from the drm tree.
> 
> I have no idea how to fix this, so I have just used the driver-core tree
> from next-20250318 for today.
> 
> -- 
> Cheers,
> Stephen Rothwell

Re: [PATCH 1/2] drm/sched: add drm_sched_prealloc_dependency_slots

>> + *
>> + * Return:
>> + * 0 on success, or an error on failing to expand the array.
>> + */
>> +int drm_sched_job_prealloc_dependency_slots(struct drm_sched_job
>> *job,
>> +    unsigned int num_deps)
>> +{
>> +struct dma_fence *fence;
>> +u32 id = 0;
>> +int ret;
>> +
>> +while (num_deps--) {
>> +fence = dma_fence_get_stub();
>> +ret = xa_alloc(&job->dependencies, &id, fence,
>> xa_limit_32b,
>> +   GFP_KERNEL);
> So this would fill the xarr with already signaled fences which then
> later will be replaced with unsignaled fences?

Yes, exactly that's the idea.

> Help me out here: would it also work to add NULL instead of that stub-
> fence?

Good question, idk. That's an implementation detail of the xarray.

Tvrtko also correctly pointed out that it is most likely a bad idea to use 
dma_fence_is_signaled() in the critical code path.

I will try to dig through the xarray behavior up and update the patch if 
possible.

Thanks,
Christian.

Re: [PATCH v6 3/5] dt-bindings: gpu: v3d: Add SMS register to BCM2712 compatible

2025-03-19 Thread Stefan Wahren


Hi Maíra,

Am 18.03.25 um 02:01 schrieb Maíra Canal:

V3D 7.1 exposes a new register block, called V3D_SMS. As BCM2712 has a
V3D 7.1 core, add a new register item to its compatible. Similar to the
GCA, which is specific for V3D 3.3, SMS should only be added for V3D 7.1
variants (such as brcm,2712-v3d).

Acked-by: Krzysztof Kozlowski 
Signed-off-by: Maíra Canal 
---
  Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml 
b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
index 
6a1a09031983eda4691a939329ed159b32f77669..dd2cc63c9a51da11691e4e81b225b74fbe86d709
 100644
--- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
+++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml
@@ -77,10 +77,12 @@ allOf:
items:
  - description: hub register
  - description: core0 register
+- description: SMS state manager register

sorry, i still don't get what SMS means. What does the second S stand for?

Regards

  reg-names:
items:
  - const: hub
  - const: core0
+- const: sms
- if:
properties:
  compatible:

Re: [PATCH 2/9] dt-bindings: display/msm: describe SFPB device

2025-03-19 Thread Dmitry Baryshkov

On Tue, Mar 18, 2025 at 08:55:59AM +0100, Krzysztof Kozlowski wrote:
> On Mon, Mar 17, 2025 at 07:44:37PM +0200, Dmitry Baryshkov wrote:
> > Add DT schema for the MultiMedia SubSystem System FPB device, which
> > provides several registers to control interface between multimedia
> > devices (primarily display) and system busses.
> > 
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >  .../devicetree/bindings/display/msm/qcom,sfpb.yaml | 39 
> > ++
> 
> Filename: qcom,apq8064-mmss-sfpb.yaml
> 
> >  1 file changed, 39 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sfpb.yaml 
> > b/Documentation/devicetree/bindings/display/msm/qcom,sfpb.yaml
> > new file mode 100644
> > index 
> > ..7ca105c97edd2f305527c58ae89b9b0cf22d3c8c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/msm/qcom,sfpb.yaml
> > @@ -0,0 +1,39 @@
> > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/msm/qcom,sfpb.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Qualcomm MultiMedia SubSystem System FPB
> > +
> > +maintainers:
> > +  - Dmitry Baryshkov 
> > +  - Rob Clark 
> > +
> > +description:
> > +  The SFPB provides several registers controlling the multimedia 
> > attachment to
> > +  the system busses.
> > +
> > +properties:
> > +  compatible:
> > +items:
> > +  - const: qcom,apq8064-mmss-sfpb
> > +  - const: syscon
> 
> Why this cannot be part of standard syscon bindings file? Looks simple
> enough.

Ack

-- 
With best wishes
Dmitry

Re: [PATCH v4 3/8] bits: introduce fixed-type genmasks

2025-03-19 Thread Anshuman Khandual

On 3/19/25 07:16, Yury Norov wrote:
> + Catalin Marinas, ARM maillist
> 
> Hi Catalin and everyone,

Hello Yury,

> 
> Anshuman Khandual asked me to merge GENMASK_U128() saying it's
> important for ARM to stabilize API. While it's a dead code, I
> accepted his patch as he promised to add users shortly.
> 
> Now it's more than half a year since that. There's no users,
> and no feedback from Anshuman.

My apologies to have missed your email earlier. Please find response
for the earlier email below as well.

> 
> Can you please tell if you still need the macro? I don't want to
> undercut your development, but if you don't need 128-bit genmasks
> there's no reason to have a dead code in the uapi.

The code base specifically using GENMASK_U128() has not been posted
upstream (probably in next couple of months or so) till now, except
the following patch which has been not been merged and still under
review and development.

https://lore.kernel.org/lkml/20240801054436.612024-1-anshuman.khand...@arm.com/

> 
> Thanks,
> Yury
> 
> On Wed, Mar 05, 2025 at 10:22:47AM -0500, Yury Norov wrote:
>> + Anshuman Khandual 
>>
>> Anshuman,
>>
>> I merged your GENMASK_U128() because you said it's important for your
>> projects, and that it will get used in the kernel soon.
>>
>> Now it's in the kernel for more than 6 month, but no users were added.
>> Can you clarify if you still need it, and if so why it's not used?

We would need it but although the code using GENMASK_U128() has not been
posted upstream.

>>
>> As you see, people add another fixed-types GENMASK() macros, and their
>> implementation differ from GENMASK_U128().

I will take a look. Is GENMASK_U128() being problematic for the this new
scheme ?

>>
>> My second concern is that __GENMASK_U128() is declared in uapi, while
>> the general understanding for other fixed-type genmasks is that they
>> are not exported to users. Do you need this macro to be exported to
>> userspace? Can you show how and where it is used there?

No, not atleast right now.

These were moved into uapi subsequently via the following commit.

21a3a3d015aee ("tools headers: Synchronize {uapi/}linux/bits.h with the kernel 
sources")

But in general GENMASK_U128() is needed for generating 128 bit page table
entries, related flags and masks whether in kernel or in user space for
writing kernel test cases etc.

>>
>> Thanks,
>> Yury
>>
>>
>> On Wed, Mar 05, 2025 at 10:00:15PM +0900, Vincent Mailhol via B4 Relay wrote:
>>> From: Yury Norov 
>>>
>>> Add __GENMASK_t() which generalizes __GENMASK() to support different
>>> types, and implement fixed-types versions of GENMASK() based on it.
>>> The fixed-type version allows more strict checks to the min/max values
>>> accepted, which is useful for defining registers like implemented by
>>> i915 and xe drivers with their REG_GENMASK*() macros.
>>>
>>> The strict checks rely on shift-count-overflow compiler check to fail
>>> the build if a number outside of the range allowed is passed.
>>> Example:
>>>
>>> #define FOO_MASK GENMASK_U32(33, 4)
>>>
>>> will generate a warning like:
>>>
>>> ../include/linux/bits.h:41:31: error: left shift count >= width of type 
>>> [-Werror=shift-count-overflow]
>>>41 |  (((t)~0ULL - ((t)(1) << (l)) + 1) & \
>>>   |   ^~
>>>
>>> Signed-off-by: Yury Norov 
>>> Signed-off-by: Lucas De Marchi 
>>> Acked-by: Jani Nikula 
>>> Signed-off-by: Vincent Mailhol 
>>> ---
>>> Changelog:
>>>
>>>   v3 -> v4:
>>>
>>> - The v3 is one year old. Meanwhile people started using
>>>   __GENMASK() directly. So instead of generalizing __GENMASK() to
>>>   support different types, add a new GENMASK_t().
>>>
>>> - replace ~0ULL by ~_ULL(0). Otherwise, __GENMASK_t() would fail
>>>   in asm code.
>>>
>>> - Make GENMASK_U8() and GENMASK_U16() return an unsigned int. In
>>>   v3, due to the integer promotion rules, these were returning a
>>>   signed integer. By casting these to unsigned int, at least the
>>>   signedness is kept.
>>> ---
>>>  include/linux/bitops.h |  1 -
>>>  include/linux/bits.h   | 33 +
>>>  2 files changed, 29 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/include/linux/bitops.h b/include/linux/bitops.h
>>> index 
>>> c1cb53cf2f0f8662ed3e324578f74330e63f935d..9be2d50da09a417966b3d11c84092bb2f4cd0bef
>>>  100644
>>> --- a/include/linux/bitops.h
>>> +++ b/include/linux/bitops.h
>>> @@ -8,7 +8,6 @@
>>>  
>>>  #include 
>>>  
>>> -#define BITS_PER_TYPE(type)(sizeof(type) * BITS_PER_BYTE)
>>>  #define BITS_TO_LONGS(nr)  __KERNEL_DIV_ROUND_UP(nr, BITS_PER_TYPE(long))
>>>  #define BITS_TO_U64(nr)__KERNEL_DIV_ROUND_UP(nr, 
>>> BITS_PER_TYPE(u64))
>>>  #define BITS_TO_U32(nr)__KERNEL_DIV_ROUND_UP(nr, 
>>> BITS_PER_TYPE(u32))
>>> diff --git a/include/linux/bits.h b/include/linux/bits.h
>>> index 
>>> 5f68980a1b98d771426872c74d7b5c0f79e5e802..f202e46d2f4b7899c16d975120f3fa3ae41556a

Re: [PATCH] drm/vmwgfx: Switch to exclusively using GEM references

Am 31.01.25 um 21:03 schrieb Ian Forbes:
> Currently we use a combination of TTM and GEM reference counting which is
> cumbersome. TTM references are used for kernel internal BOs and operations
> like validation. Simply switching the ttm_bo_(get|put) calls to their
> GEM equivalents is insufficient as not all BOs are GEM BOs so we must set
> the GEM vtable for all BOs even if they are not exposed to userspace.
>
> Suggested-by: Christian König 
> Signed-off-by: Ian Forbes 

Oh, yes please! Sorry for not responding earlier, this mail somehow got lost in 
my inbox.

Feel free to add an Acked-by: Christian König  to it.

> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.c |  4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_bo.h |  4 ++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c|  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  4 +---
>  drivers/gpu/drm/vmwgfx/vmwgfx_gem.c| 18 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c|  3 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   |  8 
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c|  4 +---
>  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c |  7 +++
>  10 files changed, 18 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> index 676fd84f35cc..609bf4067b07 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
> @@ -36,8 +36,7 @@ static void vmw_bo_release(struct vmw_bo *vbo)
>  {
>   struct vmw_resource *res;
>  
> - WARN_ON(vbo->tbo.base.funcs &&
> - kref_read(&vbo->tbo.base.refcount) != 0);
> + WARN_ON(kref_read(&vbo->tbo.base.refcount) != 0);
>   vmw_bo_unmap(vbo);
>  
>   xa_destroy(&vbo->detached_resources);
> @@ -469,6 +468,7 @@ int vmw_bo_create(struct vmw_private *vmw,
>   if (unlikely(ret != 0))
>   goto out_error;
>  
> + (*p_bo)->tbo.base.funcs = &vmw_gem_object_funcs;
>   return ret;
>  out_error:
>   *p_bo = NULL;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> index e97cae2365c8..791951fe019c 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.h
> @@ -204,12 +204,12 @@ static inline void vmw_bo_unreference(struct vmw_bo 
> **buf)
>  
>   *buf = NULL;
>   if (tmp_buf)
> - ttm_bo_put(&tmp_buf->tbo);
> + drm_gem_object_put(&tmp_buf->tbo.base);
>  }
>  
>  static inline struct vmw_bo *vmw_bo_reference(struct vmw_bo *buf)
>  {
> - ttm_bo_get(&buf->tbo);
> + drm_gem_object_get(&buf->tbo.base);
>   return buf;
>  }
>  
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> index a7c07692262b..98331c4c0335 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
> @@ -432,7 +432,7 @@ static int vmw_cotable_resize(struct vmw_resource *res, 
> size_t new_size)
>* for the new COTable. Initially pin the buffer object to make sure
>* we can use tryreserve without failure.
>*/
> - ret = vmw_gem_object_create(dev_priv, &bo_params, &buf);
> + ret = vmw_bo_create(dev_priv, &bo_params, &buf);
>   if (ret) {
>   DRM_ERROR("Failed initializing new cotable MOB.\n");
>   goto out_done;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> index 5c1d82a73c32..81382cd58ba2 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -843,9 +843,7 @@ static inline bool vmw_resource_mob_attached(const struct 
> vmw_resource *res)
>   * GEM related functionality - vmwgfx_gem.c
>   */
>  struct vmw_bo_params;
> -int vmw_gem_object_create(struct vmw_private *vmw,
> -   struct vmw_bo_params *params,
> -   struct vmw_bo **p_vbo);
> +extern const struct drm_gem_object_funcs vmw_gem_object_funcs;
>  extern int vmw_gem_object_create_with_handle(struct vmw_private *dev_priv,
>struct drm_file *filp,
>uint32_t size,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> index ed5015ced392..026c9b699604 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
> @@ -140,7 +140,7 @@ static const struct vm_operations_struct vmw_vm_ops = {
>   .close = ttm_bo_vm_close,
>  };
>  
> -static const struct drm_gem_object_funcs vmw_gem_object_funcs = {
> +const struct drm_gem_object_funcs vmw_gem_object_funcs = {
>   .free = vmw_gem_object_free,
>   .open = vmw_gem_object_open,
>   .close = vmw_gem_object_close,
> @@ -154,20 +154,6 @@ static const struct drm_gem_object_funcs 
> vmw_gem_object_funcs = {
>   .vm_ops = &vmw_vm_ops,
>  };
>  
> -int vmw_gem_objec

[PATCH v2 44/57] irqdomain: gpu: Switch to irq_find_mapping()

2025-03-19 Thread Jiri Slaby (SUSE)

irq_linear_revmap() is deprecated, so remove all its uses and supersede
them by an identical call to irq_find_mapping().

Signed-off-by: Jiri Slaby (SUSE) 
Cc: Philipp Zabel 
Cc: David Airlie 
Cc: Simona Vetter 
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/ipu-v3/ipu-common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 223e6d563a6b..333f36e0a715 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1008,7 +1008,7 @@ int ipu_map_irq(struct ipu_soc *ipu, int irq)
 {
int virq;
 
-   virq = irq_linear_revmap(ipu->domain, irq);
+   virq = irq_find_mapping(ipu->domain, irq);
if (!virq)
virq = irq_create_mapping(ipu->domain, irq);
 
@@ -1219,7 +1219,7 @@ static void ipu_irq_exit(struct ipu_soc *ipu)
/* TODO: remove irq_domain_generic_chips */
 
for (i = 0; i < IPU_NUM_IRQS; i++) {
-   irq = irq_linear_revmap(ipu->domain, i);
+   irq = irq_find_mapping(ipu->domain, i);
if (irq)
irq_dispose_mapping(irq);
}
-- 
2.49.0

[PATCH 14/18] drm/sysfb: Add efidrm for EFI displays

Add support for screen_info setups with VIDEO_TYPE_EFI. Provide the
minimum functionality of reading modes, updating and clearing the display.

There is existing support for these displays provided by simpledrm with
CONFIG_SYSFB_SIMPLEFB=y. Using efidrm over simpledrm will allows for the
mapping of video memory with correct caching. Simpledrm always assumes WC
caching, while fully cached memory is possible with efidrm. Efidrm will
also allow for the use of additional functionality provided by EFI, such
as EDID information.

In addition to efidrm, add struct pixel_format plus initializer macros.
The type and macros describe pixel formats in a generic way on order to
find the DRM format from the screen_info settings. Similar existing code
in SIMPLEFB_FORMATS and fbdev is not really what is needed in efidrm,
but SIMPLEFB_FORMATS can later be converted to struct pixel_format.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/Kconfig  |  16 ++
 drivers/gpu/drm/sysfb/Makefile |   1 +
 drivers/gpu/drm/sysfb/efidrm.c | 487 +
 include/video/pixel_format.h   |  41 +++
 4 files changed, 545 insertions(+)
 create mode 100644 drivers/gpu/drm/sysfb/efidrm.c
 create mode 100644 include/video/pixel_format.h

diff --git a/drivers/gpu/drm/sysfb/Kconfig b/drivers/gpu/drm/sysfb/Kconfig
index 87094da417f6..3ffd8da1224c 100644
--- a/drivers/gpu/drm/sysfb/Kconfig
+++ b/drivers/gpu/drm/sysfb/Kconfig
@@ -7,6 +7,22 @@ config DRM_SYSFB_HELPER
tristate
depends on DRM
 
+config DRM_EFIDRM
+   tristate "EFI framebuffer driver"
+   depends on DRM && MMU
+   select APERTURE_HELPERS
+   select DRM_CLIENT_SELECTION
+   select DRM_GEM_SHMEM_HELPER
+   select DRM_KMS_HELPER
+   select DRM_SYSFB_HELPER
+   select SYSFB
+   help
+ DRM driver for EFI framebuffers.
+
+ This driver assumes that the display hardware has been initialized
+ by the firmware or bootloader before the kernel boots. Scanout
+ buffer, size, and display format must be provided via EFI interfaces.
+
 config DRM_OFDRM
tristate "Open Firmware display driver"
depends on DRM && MMU && OF && (PPC || COMPILE_TEST)
diff --git a/drivers/gpu/drm/sysfb/Makefile b/drivers/gpu/drm/sysfb/Makefile
index f1e8700c3e35..2f96f52842e6 100644
--- a/drivers/gpu/drm/sysfb/Makefile
+++ b/drivers/gpu/drm/sysfb/Makefile
@@ -2,5 +2,6 @@
 
 obj-$(CONFIG_DRM_SYSFB_HELPER) += drm_sysfb_helper.o
 
+obj-$(CONFIG_DRM_EFIDRM)   += efidrm.o
 obj-$(CONFIG_DRM_OFDRM)+= ofdrm.o
 obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
diff --git a/drivers/gpu/drm/sysfb/efidrm.c b/drivers/gpu/drm/sysfb/efidrm.c
new file mode 100644
index ..5c1876e34a04
--- /dev/null
+++ b/drivers/gpu/drm/sysfb/efidrm.c
@@ -0,0 +1,487 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "drm_sysfb_helper.h"
+
+#define DRIVER_NAME"efidrm"
+#define DRIVER_DESC"DRM driver for EFI platform devices"
+#define DRIVER_MAJOR   1
+#define DRIVER_MINOR   0
+
+static int efidrm_get_validated_int(struct drm_device *dev, const char *name,
+   u64 value, u32 max)
+{
+   if (max > INT_MAX)
+   max = INT_MAX;
+   if (value > max) {
+   drm_err(dev, "%s of %llu exceeds maximum of %u\n", name, value, 
max);
+   return -EINVAL;
+   }
+   return value;
+}
+
+static int efidrm_get_validated_int0(struct drm_device *dev, const char *name,
+u64 value, u32 max)
+{
+   if (!value) {
+   drm_err(dev, "%s of 0 not allowed\n", name);
+   return -EINVAL;
+   }
+   return efidrm_get_validated_int(dev, name, value, max);
+}
+
+static s64 efidrm_get_validated_size0(struct drm_device *dev, const char *name,
+ u64 value, u64 max)
+{
+   if (!value) {
+   drm_err(dev, "%s of 0 not allowed\n", name);
+   return -EINVAL;
+   } else if (value > max) {
+   drm_err(dev, "%s of %llu exceeds maximum of %llu\n", name, 
value, max);
+   return -EINVAL;
+   }
+   return value;
+}
+
+static int efidrm_get_width_si(struct drm_device *dev, const struct 
screen_info *si)
+{
+   return efidrm_get_validated_int0(dev, "width", si->lfb_width, U16_MAX);
+}
+
+static int efidrm_get_height_si(struct drm_device *dev, const struct 
screen_info *si)
+{
+   return efidrm_get_validated_int0(dev, "height", si->lfb_height, 
U16_MAX);
+}
+
+static struct resource *efidrm_get_memory_si(struct drm_device *dev,
+const struct screen_info *si,
+st

[PATCH 11/18] drm/sysfb: Merge primary-plane functions

Merge the primary plane code of ofdrm and simpledrm. Replace the
plane implementation in each driver with the shared helpers. Set
up driver callbacks and format modifiers with initializer macros.

The plane code in ofdrm and simpledrm is very similar. Ofdrm has a
more sophisticated implementation of atomic_disable, which clears
individual scanlines. The code in simpledrm clears the whole buffer
at once. Take the ofdrm version.

Simpledrm supports get_scanout_buffer. Import it into the shared
helpers, which makes it available in ofdrm.

The supported formats are all native formats plus an optional enulated
XRGB if that's not already a native format. Provide an initializer
macro that computes the size of the formats array.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/drm_sysfb_helper.c | 145 +++
 drivers/gpu/drm/sysfb/drm_sysfb_helper.h |  32 +
 drivers/gpu/drm/sysfb/ofdrm.c| 134 +
 drivers/gpu/drm/sysfb/simpledrm.c| 126 +---
 4 files changed, 187 insertions(+), 250 deletions(-)

diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
index ed9139f56e59..b48e06b25305 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
@@ -7,6 +7,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
@@ -39,6 +46,144 @@ struct drm_display_mode drm_sysfb_mode(unsigned int width,
 }
 EXPORT_SYMBOL(drm_sysfb_mode);
 
+/*
+ * Plane
+ */
+
+int drm_sysfb_plane_helper_atomic_check(struct drm_plane *plane,
+   struct drm_atomic_state *new_state)
+{
+   struct drm_sysfb_device *sysfb = to_drm_sysfb_device(plane->dev);
+   struct drm_plane_state *new_plane_state = 
drm_atomic_get_new_plane_state(new_state, plane);
+   struct drm_shadow_plane_state *new_shadow_plane_state =
+   to_drm_shadow_plane_state(new_plane_state);
+   struct drm_framebuffer *new_fb = new_plane_state->fb;
+   struct drm_crtc *new_crtc = new_plane_state->crtc;
+   struct drm_crtc_state *new_crtc_state = NULL;
+   struct drm_sysfb_crtc_state *new_sysfb_crtc_state;
+   int ret;
+
+   if (new_crtc)
+   new_crtc_state = drm_atomic_get_new_crtc_state(new_state, 
new_plane_state->crtc);
+
+   ret = drm_atomic_helper_check_plane_state(new_plane_state, 
new_crtc_state,
+ DRM_PLANE_NO_SCALING,
+ DRM_PLANE_NO_SCALING,
+ false, false);
+   if (ret)
+   return ret;
+   else if (!new_plane_state->visible)
+   return 0;
+
+   if (new_fb->format != sysfb->fb_format) {
+   void *buf;
+
+   /* format conversion necessary; reserve buffer */
+   buf = 
drm_format_conv_state_reserve(&new_shadow_plane_state->fmtcnv_state,
+   sysfb->fb_pitch, 
GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+   }
+
+   new_crtc_state = drm_atomic_get_new_crtc_state(new_state, 
new_plane_state->crtc);
+
+   new_sysfb_crtc_state = to_drm_sysfb_crtc_state(new_crtc_state);
+   new_sysfb_crtc_state->format = new_fb->format;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_sysfb_plane_helper_atomic_check);
+
+void drm_sysfb_plane_helper_atomic_update(struct drm_plane *plane, struct 
drm_atomic_state *state)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_sysfb_device *sysfb = to_drm_sysfb_device(dev);
+   struct drm_plane_state *plane_state = 
drm_atomic_get_new_plane_state(state, plane);
+   struct drm_plane_state *old_plane_state = 
drm_atomic_get_old_plane_state(state, plane);
+   struct drm_shadow_plane_state *shadow_plane_state = 
to_drm_shadow_plane_state(plane_state);
+   struct drm_framebuffer *fb = plane_state->fb;
+   unsigned int dst_pitch = sysfb->fb_pitch;
+   const struct drm_format_info *dst_format = sysfb->fb_format;
+   struct drm_atomic_helper_damage_iter iter;
+   struct drm_rect damage;
+   int ret, idx;
+
+   ret = drm_gem_fb_begin_cpu_access(fb, DMA_FROM_DEVICE);
+   if (ret)
+   return;
+
+   if (!drm_dev_enter(dev, &idx))
+   goto out_drm_gem_fb_end_cpu_access;
+
+   drm_atomic_helper_damage_iter_init(&iter, old_plane_state, plane_state);
+   drm_atomic_for_each_plane_damage(&iter, &damage) {
+   struct iosys_map dst = sysfb->fb_addr;
+   struct drm_rect dst_clip = plane_state->dst;
+
+   if (!drm_rect_intersect(&dst_clip, &damage))
+   continue;
+
+   iosys_map_incr(&dst, drm_fb_clip_offset(dst_pitch, dst_format, 
&dst_clip));
+   drm_fb_b

[PATCH 04/18] drm: Move sysfb drivers into separate subdirectory

The ofdrm and simpledrm drivers are special as they operate on
externally provided framebuffers. Move them into their own sub-
directory. Will let them share common code.

Signed-off-by: Thomas Zimmermann 
---
 MAINTAINERS |  3 +-
 drivers/gpu/drm/Kconfig |  2 ++
 drivers/gpu/drm/Makefile|  1 +
 drivers/gpu/drm/sysfb/Kconfig   | 38 +
 drivers/gpu/drm/sysfb/Makefile  |  4 +++
 drivers/gpu/drm/{tiny => sysfb}/ofdrm.c |  0
 drivers/gpu/drm/{tiny => sysfb}/simpledrm.c |  0
 drivers/gpu/drm/tiny/Kconfig| 32 -
 drivers/gpu/drm/tiny/Makefile   |  2 --
 9 files changed, 46 insertions(+), 36 deletions(-)
 create mode 100644 drivers/gpu/drm/sysfb/Kconfig
 create mode 100644 drivers/gpu/drm/sysfb/Makefile
 rename drivers/gpu/drm/{tiny => sysfb}/ofdrm.c (100%)
 rename drivers/gpu/drm/{tiny => sysfb}/simpledrm.c (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9df9b25fffc3..588cea0e8630 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7247,8 +7247,7 @@ M:Javier Martinez Canillas 
 L: dri-devel@lists.freedesktop.org
 S: Maintained
 T: git https://gitlab.freedesktop.org/drm/misc/kernel.git
-F: drivers/gpu/drm/tiny/ofdrm.c
-F: drivers/gpu/drm/tiny/simpledrm.c
+F: drivers/gpu/drm/sysfb/
 F: drivers/video/aperture.c
 F: drivers/video/nomodeset.c
 F: include/linux/aperture.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1be14d8634f4..200bfbb9f093 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -335,6 +335,8 @@ config DRM_SCHED
tristate
depends on DRM
 
+source "drivers/gpu/drm/sysfb/Kconfig"
+
 source "drivers/gpu/drm/arm/Kconfig"
 
 source "drivers/gpu/drm/radeon/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index ed54a546bbe2..bf5cb7936a1d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -204,6 +204,7 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
 obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
 obj-y  += hisilicon/
 obj-y  += mxsfb/
+obj-y  += sysfb/
 obj-y  += tiny/
 obj-$(CONFIG_DRM_PL111) += pl111/
 obj-$(CONFIG_DRM_TVE200) += tve200/
diff --git a/drivers/gpu/drm/sysfb/Kconfig b/drivers/gpu/drm/sysfb/Kconfig
new file mode 100644
index ..9eafc06b7192
--- /dev/null
+++ b/drivers/gpu/drm/sysfb/Kconfig
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+menu "Drivers for system framebuffers"
+   depends on DRM
+
+config DRM_OFDRM
+   tristate "Open Firmware display driver"
+   depends on DRM && MMU && OF && (PPC || COMPILE_TEST)
+   select APERTURE_HELPERS
+   select DRM_CLIENT_SELECTION
+   select DRM_GEM_SHMEM_HELPER
+   select DRM_KMS_HELPER
+   help
+ DRM driver for Open Firmware framebuffers.
+
+ This driver assumes that the display hardware has been initialized
+ by the Open Firmware before the kernel boots. Scanout buffer, size,
+ and display format must be provided via device tree.
+
+config DRM_SIMPLEDRM
+   tristate "Simple framebuffer driver"
+   depends on DRM && MMU
+   select APERTURE_HELPERS
+   select DRM_CLIENT_SELECTION
+   select DRM_GEM_SHMEM_HELPER
+   select DRM_KMS_HELPER
+   help
+ DRM driver for simple platform-provided framebuffers.
+
+ This driver assumes that the display hardware has been initialized
+ by the firmware or bootloader before the kernel boots. Scanout
+ buffer, size, and display format must be provided via device tree,
+ UEFI, VESA, etc.
+
+ On x86 BIOS or UEFI systems, you should also select SYSFB_SIMPLEFB
+ to use UEFI and VESA framebuffers.
+
+endmenu
diff --git a/drivers/gpu/drm/sysfb/Makefile b/drivers/gpu/drm/sysfb/Makefile
new file mode 100644
index ..f6c03629accb
--- /dev/null
+++ b/drivers/gpu/drm/sysfb/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+obj-$(CONFIG_DRM_OFDRM)+= ofdrm.o
+obj-$(CONFIG_DRM_SIMPLEDRM)+= simpledrm.o
diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/sysfb/ofdrm.c
similarity index 100%
rename from drivers/gpu/drm/tiny/ofdrm.c
rename to drivers/gpu/drm/sysfb/ofdrm.c
diff --git a/drivers/gpu/drm/tiny/simpledrm.c 
b/drivers/gpu/drm/sysfb/simpledrm.c
similarity index 100%
rename from drivers/gpu/drm/tiny/simpledrm.c
rename to drivers/gpu/drm/sysfb/simpledrm.c
diff --git a/drivers/gpu/drm/tiny/Kconfig b/drivers/gpu/drm/tiny/Kconfig
index 54c84c9801c1..95c1457d7730 100644
--- a/drivers/gpu/drm/tiny/Kconfig
+++ b/drivers/gpu/drm/tiny/Kconfig
@@ -65,20 +65,6 @@ config DRM_GM12U320
 This is a KMS driver for projectors which use the GM12U320 chipset
 for video transfer over USB2/3, such as the Acer C120 mini projector.
 
-config DRM_OFDRM
-   trist

[PATCH 00/18] drm: Provide helpers for system framebuffers and add efidrm/vesadrm

This series simplifies the existing ofdrm and simepldrm drivers,
and adds new drivers for EFI- and VESA-based framebuffers. Existing
drivers for system framebuffers, ofdrm and simpledrm, share much of
their mode-setting pipeline. The major difference between the two
drivers is in how they retrieve the framebuffer from the systems.
Hence, it makes sense to share some of the pipeline implementation.
With the shared helpers in place, we can then add dedicated drivers
for EFI and VESA easily.

Patches 1 to 3 clean up obsolete artifacts from ofdrm and simpledrm.

Patch 4 moves both drivers from tiny/ into their own subdirectory
sysfb/. The name aligns with the naming in drivers/firmware/sysfb.c
to signal the connection. It's the firmware code that creates most
of the system-framebuffer devices that these drivers operate on. The
patch also adds a separate menu in Kconfig.

Patches 5 to 11 unify the mode-setting pipeline between ofdrm and
simpledrm. Either both drivers already use the same implementation
or they can easily do so. There've been previous attempts to unify
some of the drivers' code, but with little success. This time the
helpers will be shared among 4 drivers, so it's already much more
successful than before.

Patch 12 adds EDID support to ofdrm. The EDID data can be found in
some Macintosh's DeviceTree next to the framebuffer configuration.
EDID support will be useful for EFI and VESA as well.

Patch 13 adds another helper for screen_info that will be required
by EFI and VESA drivers.

Patch 14 and 15 add efidrm, a DRM driver that operates on EFI-provided
framebuffers. It uses the shared sysfb helpers. The immediate benefit
over simpledrm is the support for EFI's various types of memory caching
on the framebuffer. Simpledrm only supported WriteCombine caching.
There's also EDID support if the kernel's edid_info has been initialized.
This feature needs to be implemented in the kernel's efistub library.

Patches 16 to 18 add vesadrm, a DRM driver that operates in VESA-
provided framebuffers. It is very much like efidrm, but tailored
towards VESA features. It has EDID support and there's a patch at [1]
for grub to provide the data as part of the kernel's boot parameters.
Vesadrm also supports gamma ramps. Together with EDID, this allows
for gamma correction and night mode. Gnome already does that.

Future directions: Efidrm requires EDID data that has to be provided
by the efistub library. There is an EFI call to do so. Vesadrm currently
requires a discrete color mode. Support for palette modes can be added
later. There's still a bit of code duplication among palette handling.
We have more drivers that use similar code for palette LUTs, such as
ast and mgag200. We should try to provide generic palette helpers for
all these drivers.

This series has been tested on various devices that require the provided
drivers.

[1]
https://build.opensuse.org/projects/home:tdz:branches:Base:System/packages/grub2/files/grub2-provide-edid.patch?expand=1

Thomas Zimmermann (18):
drm/ofdrm: Remove struct ofdrm_device.pdev
drm/ofdrm: Open-code drm_simple_encoder_init()
drm/simpledrm: Remove struct simpledrm_device.nformats
drm: Move sysfb drivers into separate subdirectory
drm/sysfb: Add struct drm_sysfb_device
drm/sysfb: Provide single mode-init helper
drm/sysfb: Merge mode-config functions
drm/sysfb: Merge connector functions
drm/sysfb: Maintain CRTC state in struct drm_sysfb_crtc_state
drm/sysfb: Merge CRTC functions
drm/sysfb: Merge primary-plane functions
drm/sysfb: ofdrm: Add EDID support
firmware: sysfb: Move bpp-depth calculation into screen_info helper
drm/sysfb: Add efidrm for EFI displays
drm/sysfb: efidrm: Add EDID support
drm/sysfb: Add vesadrm for VESA displays
drm/sysfb: vesadrm: Add EDID support
drm/sysfb: vesadrm: Add gamma correction

MAINTAINERS | 3 +-
drivers/firmware/sysfb_simplefb.c | 31 +-
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/sysfb/Kconfig | 76 +++
drivers/gpu/drm/sysfb/Makefile | 8 +
drivers/gpu/drm/sysfb/drm_sysfb_helper.c| 319 ++
drivers/gpu/drm/sysfb/drm_sysfb_helper.h| 136
drivers/gpu/drm/sysfb/efidrm.c | 495 +++
drivers/gpu/drm/{tiny => sysfb}/ofdrm.c | 364 ++-
drivers/gpu/drm/{tiny => sysfb}/simpledrm.c | 237 +--
drivers/gpu/drm/sysfb/vesadrm.c | 660
drivers/gpu/drm/tiny/Kconfig| 32 -
drivers/gpu/drm/tiny/Makefile | 2 -
drivers/video/screen_info_generic.c | 36 ++
include/linux/screen_info.h | 9 +
include/video/pixel_format.h| 41 ++
17 files changed, 1885 insertions(+), 567 deletions(-)
create mode 100644 drivers/gpu/drm/sysfb/Kconfig
create mode 100644 drivers/gpu/drm/sysfb/Makefile
create mode 100644 drivers/g

[PATCH 07/18] drm/sysfb: Merge mode-config functions

Provide initializer to set struct drm_mode_config_funcs. Convert
ofdrm and simpledrm.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/drm_sysfb_helper.h | 9 +
 drivers/gpu/drm/sysfb/ofdrm.c| 4 +---
 drivers/gpu/drm/sysfb/simpledrm.c| 4 +---
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
index 8b4cc4af702b..cf80b291014a 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
@@ -37,4 +37,13 @@ static inline struct drm_sysfb_device 
*to_drm_sysfb_device(struct drm_device *de
return container_of(dev, struct drm_sysfb_device, dev);
 }
 
+/*
+ * Mode config
+ */
+
+#define DRM_SYSFB_MODE_CONFIG_FUNCS \
+   .fb_create = drm_gem_fb_create_with_dirty, \
+   .atomic_check = drm_atomic_helper_check, \
+   .atomic_commit = drm_atomic_helper_commit
+
 #endif
diff --git a/drivers/gpu/drm/sysfb/ofdrm.c b/drivers/gpu/drm/sysfb/ofdrm.c
index 7df6901157fb..470b93f0f791 100644
--- a/drivers/gpu/drm/sysfb/ofdrm.c
+++ b/drivers/gpu/drm/sysfb/ofdrm.c
@@ -1018,9 +1018,7 @@ static const struct drm_connector_funcs 
ofdrm_connector_funcs = {
 };
 
 static const struct drm_mode_config_funcs ofdrm_mode_config_funcs = {
-   .fb_create = drm_gem_fb_create_with_dirty,
-   .atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
+   DRM_SYSFB_MODE_CONFIG_FUNCS,
 };
 
 /*
diff --git a/drivers/gpu/drm/sysfb/simpledrm.c 
b/drivers/gpu/drm/sysfb/simpledrm.c
index 149df6941b6c..0cee8e1b2108 100644
--- a/drivers/gpu/drm/sysfb/simpledrm.c
+++ b/drivers/gpu/drm/sysfb/simpledrm.c
@@ -747,9 +747,7 @@ static const struct drm_connector_funcs 
simpledrm_connector_funcs = {
 };
 
 static const struct drm_mode_config_funcs simpledrm_mode_config_funcs = {
-   .fb_create = drm_gem_fb_create_with_dirty,
-   .atomic_check = drm_atomic_helper_check,
-   .atomic_commit = drm_atomic_helper_commit,
+   DRM_SYSFB_MODE_CONFIG_FUNCS,
 };
 
 /*
-- 
2.48.1

[PATCH 02/18] drm/ofdrm: Open-code drm_simple_encoder_init()

The helper drm_simple_encoder_init() is a trivial helper around
drm_encoder_init() and therefore deprecated. Open-code the function
and remove the dependency.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tiny/ofdrm.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index 7469dd281083..7d5beaf6a42c 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define DRIVER_NAME"ofdrm"
 #define DRIVER_DESC"DRM driver for OF platform devices"
@@ -999,6 +998,10 @@ static const struct drm_crtc_funcs ofdrm_crtc_funcs = {
.atomic_destroy_state = ofdrm_crtc_atomic_destroy_state,
 };
 
+static const struct drm_encoder_funcs ofdrm_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
 static int ofdrm_connector_helper_get_modes(struct drm_connector *connector)
 {
struct ofdrm_device *odev = ofdrm_device_of_dev(connector->dev);
@@ -1309,7 +1312,7 @@ static struct ofdrm_device *ofdrm_device_create(struct 
drm_driver *drv,
/* Encoder */
 
encoder = &odev->encoder;
-   ret = drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_NONE);
+   ret = drm_encoder_init(dev, encoder, &ofdrm_encoder_funcs, 
DRM_MODE_ENCODER_NONE, NULL);
if (ret)
return ERR_PTR(ret);
encoder->possible_crtcs = drm_crtc_mask(crtc);
-- 
2.48.1

[PATCH 01/18] drm/ofdrm: Remove struct ofdrm_device.pdev

The field pdev is unused. Remove it.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tiny/ofdrm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index 13491c0e704a..7469dd281083 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -291,7 +291,6 @@ struct ofdrm_device_funcs {
 
 struct ofdrm_device {
struct drm_device dev;
-   struct platform_device *pdev;
 
const struct ofdrm_device_funcs *funcs;
 
-- 
2.48.1

[PATCH 18/18] drm/sysfb: vesadrm: Add gamma correction

Add palette support and export GAMMA properties via sysfs. User-space
compositors can use this interface for programming gamma ramps or night
mode.

Vesadrm supports palette updates via VGA DAC registers or VESA palette
calls. Up to 256 palette entries are available. Userspace always supplies
gamma ramps of 256 entries. If the native color format does not match
this because pixel component have less then 8 bits, vesadrm interpolates
among the palette entries.

The code uses CamelCase style in a few places to match the VESA manuals.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/vesadrm.c | 204 
 include/linux/screen_info.h |   7 ++
 2 files changed, 211 insertions(+)

diff --git a/drivers/gpu/drm/sysfb/vesadrm.c b/drivers/gpu/drm/sysfb/vesadrm.c
index 07f59880ce0f..20cf867ad500 100644
--- a/drivers/gpu/drm/sysfb/vesadrm.c
+++ b/drivers/gpu/drm/sysfb/vesadrm.c
@@ -25,6 +25,7 @@
 
 #include 
 #include 
+#include 
 
 #include "drm_sysfb_helper.h"
 
@@ -33,6 +34,8 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
+#define VESADRM_GAMMA_LUT_SIZE 256
+
 static int vesadrm_get_validated_int(struct drm_device *dev, const char *name,
 u64 value, u32 max)
 {
@@ -162,6 +165,14 @@ static const struct drm_format_info 
*vesadrm_get_format_si(struct drm_device *de
 struct vesadrm_device {
struct drm_sysfb_device sysfb;
 
+   /* VESA Protected Mode interface */
+   struct {
+   const u8 *PrimaryPalette;
+   } pmi;
+
+   void (*cmap_write)(struct vesadrm_device *vesa, unsigned int index,
+  u16 red, u16 green, u16 blue);
+
/* modesetting */
u32 formats[DRM_SYSFB_PLANE_NFORMATS(1)];
struct drm_plane primary_plane;
@@ -170,6 +181,151 @@ struct vesadrm_device {
struct drm_connector connector;
 };
 
+static struct vesadrm_device *to_vesadrm_device(struct drm_device *dev)
+{
+   return container_of(to_drm_sysfb_device(dev), struct vesadrm_device, 
sysfb);
+}
+
+/*
+ * Palette
+ */
+
+static void vesadrm_vga_cmap_write(struct vesadrm_device *vesa, unsigned int 
index,
+  u16 red, u16 green, u16 blue)
+{
+   u8 i8, r8, g8, b8;
+
+   if (index > 255)
+   return;
+
+   i8 = index;
+   r8 = red >> 8;
+   g8 = green >> 8;
+   b8 = blue >> 8;
+
+   outb_p(i8, VGA_PEL_IW);
+   outb_p(r8, VGA_PEL_D);
+   outb_p(g8, VGA_PEL_D);
+   outb_p(b8, VGA_PEL_D);
+}
+
+#ifdef __i386__
+static void vesadrm_pmi_cmap_write(struct vesadrm_device *vesa, unsigned int 
index,
+  u16 red, u16 green, u16 blue)
+{
+   u32 i32 = index;
+   struct {
+   u8 b8;
+   u8 g8;
+   u8 r8;
+   u8 x8;
+   } PaletteEntry = {
+   blue >> 8,
+   green >> 8,
+   red >> 8,
+   0x00,
+   };
+
+   if (index > 255)
+   return;
+
+   __asm__ __volatile__(
+   "call *(%%esi)"
+   : /* no return value */
+   : "a" (0x4f09),
+ "b" (0),
+ "c" (1),
+ "d" (i32),
+ "D" (&PaletteEntry),
+ "S" (&vesa->pmi.PrimaryPalette));
+}
+#endif
+
+static void vesadrm_set_gamma_linear(struct vesadrm_device *vesa,
+const struct drm_format_info *format)
+{
+   struct drm_device *dev = &vesa->sysfb.dev;
+   size_t i;
+   u16 r16, g16, b16;
+
+   switch (format->format) {
+   case DRM_FORMAT_XRGB1555:
+   for (i = 0; i < 32; ++i) {
+   r16 = i * 8 + i / 4;
+   r16 |= (r16 << 8) | r16;
+   vesa->cmap_write(vesa, i, r16, r16, r16);
+   }
+   break;
+   case DRM_FORMAT_RGB565:
+   for (i = 0; i < 32; ++i) {
+   r16 = i * 8 + i / 4;
+   r16 |= (r16 << 8) | r16;
+   g16 = i * 4 + i / 16;
+   g16 |= (g16 << 8) | g16;
+   b16 = r16;
+   vesa->cmap_write(vesa, i, r16, g16, b16);
+   }
+   for (i = 32; i < 64; ++i) {
+   g16 = i * 4 + i / 16;
+   g16 |= (g16 << 8) | g16;
+   vesa->cmap_write(vesa, i, 0, g16, 0);
+   }
+   break;
+   case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_BGRX:
+   for (i = 0; i < 256; ++i) {
+   r16 = (i << 8) | i;
+   vesa->cmap_write(vesa, i, r16, r16, r16);
+   }
+   break;
+   default:
+   drm_warn_once(dev, "Unsupported format %p4cc for gamma 
correction\n",
+ &format->format);
+

Re: [PATCH v4 07/14] arm64: Add support for suppressing warning backtraces

2025-03-19 Thread Christophe Leroy





Le 18/03/2025 à 16:59, Will Deacon a écrit :

On Thu, Mar 13, 2025 at 05:40:59PM +0100, Alessandro Carminati wrote:

On Thu, Mar 13, 2025 at 1:25 PM Will Deacon  wrote:


On Thu, Mar 13, 2025 at 11:43:22AM +, Alessandro Carminati wrote:

diff --git a/arch/arm64/include/asm/bug.h b/arch/arm64/include/asm/bug.h
index 28be048db3f6..044c5e24a17d 100644
--- a/arch/arm64/include/asm/bug.h
+++ b/arch/arm64/include/asm/bug.h
@@ -11,8 +11,14 @@

  #include 

+#ifdef HAVE_BUG_FUNCTION
+# define __BUG_FUNC  __func__
+#else
+# define __BUG_FUNC  NULL
+#endif
+
  #define __BUG_FLAGS(flags)   \
- asm volatile (__stringify(ASM_BUG_FLAGS(flags)));
+ asm volatile (__stringify(ASM_BUG_FLAGS(flags, %c0)) : : "i" 
(__BUG_FUNC));


Why is 'i' the right asm constraint to use here? It seems a bit odd to
use that for a pointer.


I received this code as legacy from a previous version.
In my review, I considered the case when HAVE_BUG_FUNCTION is defined:
Here, __BUG_FUNC is defined as __func__, which is the name of the
current function as a string literal.
Using the constraint "i" seems appropriate to me in this case.

However, when HAVE_BUG_FUNCTION is not defined:
__BUG_FUNC is defined as NULL. Initially, I considered it literal 0,
but after investigating your concern, I found:

```
$ echo -E "#include \n#include \nint main()
{\nreturn 0;\n}" | aarch64-linux-gnu-gcc -E -dM - | grep NULL
#define NULL ((void *)0)
```

I realized that NULL is actually a pointer that is not a link time
symbol, and using the "i" constraint with NULL may result in undefined
behavior.

Would the following alternative definition for __BUG_FUNC be more convincing?

```
#ifdef HAVE_BUG_FUNCTION
 #define __BUG_FUNC __func__
#else
 #define __BUG_FUNC (uintptr_t)0
#endif
```
Let me know your thoughts.


Thanks for the analysis; I hadn't noticed this specific issue, it just
smelled a bit fishy. Anyway, the diff above looks better, thanks.


That propably deserves a comment.

Doesn't sparse and/or checkpatch complain about 0 being used in lieu of 
NULL ?


By the way I had similar problem in the past with GCC not seeing NULL as 
a __builtin_constant_p(), refer commit 1d8f739b07bd ("powerpc/kuap: Fix 
set direction in allow/prevent_user_access()")


Christophe

[PATCH 09/18] drm/sysfb: Maintain CRTC state in struct drm_sysfb_crtc_state

Move ofdrm's struct ofdrm_crtc_state plus functions to sysfb
helpers and rename everything to drm_sysfb_crtc_state.

The sysfb CRTC state is a regular CRTC state with information on
the primary plane's color format, as required for color management.
Helpers for sysfb planes will later set this up automatically.

In ofdrm and simpledrm, replace existing code with the new helpers.
Ofdrm continues to use the CRTC state for color management. This
has no effect on simpledrm.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/drm_sysfb_helper.c | 59 ++
 drivers/gpu/drm/sysfb/drm_sysfb_helper.h | 29 +
 drivers/gpu/drm/sysfb/ofdrm.c| 76 ++--
 drivers/gpu/drm/sysfb/simpledrm.c|  6 +-
 4 files changed, 95 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
index 355e025c7c62..368061b6f514 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
@@ -1,7 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
+#include 
+#include 
 #include 
 
+#include 
+#include 
 #include 
 
 #include "drm_sysfb_helper.h"
@@ -33,6 +37,61 @@ struct drm_display_mode drm_sysfb_mode(unsigned int width,
 }
 EXPORT_SYMBOL(drm_sysfb_mode);
 
+/*
+ * CRTC
+ */
+
+static void drm_sysfb_crtc_state_destroy(struct drm_sysfb_crtc_state 
*sysfb_crtc_state)
+{
+   __drm_atomic_helper_crtc_destroy_state(&sysfb_crtc_state->base);
+
+   kfree(sysfb_crtc_state);
+}
+
+void drm_sysfb_crtc_reset(struct drm_crtc *crtc)
+{
+   struct drm_sysfb_crtc_state *sysfb_crtc_state;
+
+   if (crtc->state)
+   
drm_sysfb_crtc_state_destroy(to_drm_sysfb_crtc_state(crtc->state));
+
+   sysfb_crtc_state = kzalloc(sizeof(*sysfb_crtc_state), GFP_KERNEL);
+   if (sysfb_crtc_state)
+   __drm_atomic_helper_crtc_reset(crtc, &sysfb_crtc_state->base);
+   else
+   __drm_atomic_helper_crtc_reset(crtc, NULL);
+}
+EXPORT_SYMBOL(drm_sysfb_crtc_reset);
+
+struct drm_crtc_state *drm_sysfb_crtc_atomic_duplicate_state(struct drm_crtc 
*crtc)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_crtc_state *crtc_state = crtc->state;
+   struct drm_sysfb_crtc_state *new_sysfb_crtc_state;
+   struct drm_sysfb_crtc_state *sysfb_crtc_state;
+
+   if (drm_WARN_ON(dev, !crtc_state))
+   return NULL;
+
+   new_sysfb_crtc_state = kzalloc(sizeof(*new_sysfb_crtc_state), 
GFP_KERNEL);
+   if (!new_sysfb_crtc_state)
+   return NULL;
+
+   sysfb_crtc_state = to_drm_sysfb_crtc_state(crtc_state);
+
+   __drm_atomic_helper_crtc_duplicate_state(crtc, 
&new_sysfb_crtc_state->base);
+   new_sysfb_crtc_state->format = sysfb_crtc_state->format;
+
+   return &new_sysfb_crtc_state->base;
+}
+EXPORT_SYMBOL(drm_sysfb_crtc_atomic_duplicate_state);
+
+void drm_sysfb_crtc_atomic_destroy_state(struct drm_crtc *crtc, struct 
drm_crtc_state *crtc_state)
+{
+   drm_sysfb_crtc_state_destroy(to_drm_sysfb_crtc_state(crtc_state));
+}
+EXPORT_SYMBOL(drm_sysfb_crtc_atomic_destroy_state);
+
 /*
  * Connector
  */
diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
index 7e3fe9fa5cff..91da27405a46 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
@@ -6,6 +6,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -37,6 +38,34 @@ static inline struct drm_sysfb_device 
*to_drm_sysfb_device(struct drm_device *de
return container_of(dev, struct drm_sysfb_device, dev);
 }
 
+/*
+ * CRTC
+ */
+
+struct drm_sysfb_crtc_state {
+   struct drm_crtc_state base;
+
+   /* Primary-plane format; required for color mgmt. */
+   const struct drm_format_info *format;
+};
+
+static inline struct drm_sysfb_crtc_state *
+to_drm_sysfb_crtc_state(struct drm_crtc_state *base)
+{
+   return container_of(base, struct drm_sysfb_crtc_state, base);
+}
+
+void drm_sysfb_crtc_reset(struct drm_crtc *crtc);
+struct drm_crtc_state *drm_sysfb_crtc_atomic_duplicate_state(struct drm_crtc 
*crtc);
+void drm_sysfb_crtc_atomic_destroy_state(struct drm_crtc *crtc, struct 
drm_crtc_state *crtc_state);
+
+#define DRM_SYSFB_CRTC_FUNCS \
+   .reset = drm_sysfb_crtc_reset, \
+   .set_config = drm_atomic_helper_set_config, \
+   .page_flip = drm_atomic_helper_page_flip, \
+   .atomic_duplicate_state = drm_sysfb_crtc_atomic_duplicate_state, \
+   .atomic_destroy_state = drm_sysfb_crtc_atomic_destroy_state
+
 /*
  * Connector
  */
diff --git a/drivers/gpu/drm/sysfb/ofdrm.c b/drivers/gpu/drm/sysfb/ofdrm.c
index 85db7441d1bf..faaf35ba17f3 100644
--- a/drivers/gpu/drm/sysfb/ofdrm.c
+++ b/drivers/gpu/drm/sysfb/ofdrm.c
@@ -725,24 +725,6 @@ static void ofdrm_device_set_gamma(struct ofdrm_device 
*odev,
  * Modesetting
  */
 
-struct ofdrm_crtc_state {
-   struct drm_crtc_state base;
-
-   /* Pr

[PATCH 08/18] drm/sysfb: Merge connector functions

Merge the connector functions of ofdrm and simpledrm. Replace the
code in each driver with the shared helpers. Set up callbacks with
initializer macros.

No effective code changes. The sysfb connector only returns the
preconfigured display mode.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/drm_sysfb_helper.c | 14 ++
 drivers/gpu/drm/sysfb/drm_sysfb_helper.h | 15 +++
 drivers/gpu/drm/sysfb/ofdrm.c| 14 ++
 drivers/gpu/drm/sysfb/simpledrm.c| 14 ++
 4 files changed, 33 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
index 6deeac81a41d..355e025c7c62 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.c
@@ -2,6 +2,8 @@
 
 #include 
 
+#include 
+
 #include "drm_sysfb_helper.h"
 
 MODULE_DESCRIPTION("Helpers for DRM sysfb drivers");
@@ -30,3 +32,15 @@ struct drm_display_mode drm_sysfb_mode(unsigned int width,
}
 }
 EXPORT_SYMBOL(drm_sysfb_mode);
+
+/*
+ * Connector
+ */
+
+int drm_sysfb_connector_helper_get_modes(struct drm_connector *connector)
+{
+   struct drm_sysfb_device *sysfb = to_drm_sysfb_device(connector->dev);
+
+   return drm_connector_helper_get_modes_fixed(connector, &sysfb->fb_mode);
+}
+EXPORT_SYMBOL(drm_sysfb_connector_helper_get_modes);
diff --git a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h 
b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
index cf80b291014a..7e3fe9fa5cff 100644
--- a/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
+++ b/drivers/gpu/drm/sysfb/drm_sysfb_helper.h
@@ -37,6 +37,21 @@ static inline struct drm_sysfb_device 
*to_drm_sysfb_device(struct drm_device *de
return container_of(dev, struct drm_sysfb_device, dev);
 }
 
+/*
+ * Connector
+ */
+
+int drm_sysfb_connector_helper_get_modes(struct drm_connector *connector);
+
+#define DRM_SYSFB_CONNECTOR_HELPER_FUNCS \
+   .get_modes = drm_sysfb_connector_helper_get_modes
+
+#define DRM_SYSFB_CONNECTOR_FUNCS \
+   .reset = drm_atomic_helper_connector_reset, \
+   .fill_modes = drm_helper_probe_single_connector_modes, \
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, \
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state
+
 /*
  * Mode config
  */
diff --git a/drivers/gpu/drm/sysfb/ofdrm.c b/drivers/gpu/drm/sysfb/ofdrm.c
index 470b93f0f791..85db7441d1bf 100644
--- a/drivers/gpu/drm/sysfb/ofdrm.c
+++ b/drivers/gpu/drm/sysfb/ofdrm.c
@@ -998,23 +998,13 @@ static const struct drm_encoder_funcs ofdrm_encoder_funcs 
= {
.destroy = drm_encoder_cleanup,
 };
 
-static int ofdrm_connector_helper_get_modes(struct drm_connector *connector)
-{
-   struct drm_sysfb_device *sysfb = to_drm_sysfb_device(connector->dev);
-
-   return drm_connector_helper_get_modes_fixed(connector, &sysfb->fb_mode);
-}
-
 static const struct drm_connector_helper_funcs ofdrm_connector_helper_funcs = {
-   .get_modes = ofdrm_connector_helper_get_modes,
+   DRM_SYSFB_CONNECTOR_HELPER_FUNCS,
 };
 
 static const struct drm_connector_funcs ofdrm_connector_funcs = {
-   .reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   DRM_SYSFB_CONNECTOR_FUNCS,
.destroy = drm_connector_cleanup,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
 static const struct drm_mode_config_funcs ofdrm_mode_config_funcs = {
diff --git a/drivers/gpu/drm/sysfb/simpledrm.c 
b/drivers/gpu/drm/sysfb/simpledrm.c
index 0cee8e1b2108..6d76d125d126 100644
--- a/drivers/gpu/drm/sysfb/simpledrm.c
+++ b/drivers/gpu/drm/sysfb/simpledrm.c
@@ -727,23 +727,13 @@ static const struct drm_encoder_funcs 
simpledrm_encoder_funcs = {
.destroy = drm_encoder_cleanup,
 };
 
-static int simpledrm_connector_helper_get_modes(struct drm_connector 
*connector)
-{
-   struct drm_sysfb_device *sysfb = to_drm_sysfb_device(connector->dev);
-
-   return drm_connector_helper_get_modes_fixed(connector, &sysfb->fb_mode);
-}
-
 static const struct drm_connector_helper_funcs 
simpledrm_connector_helper_funcs = {
-   .get_modes = simpledrm_connector_helper_get_modes,
+   DRM_SYSFB_CONNECTOR_HELPER_FUNCS,
 };
 
 static const struct drm_connector_funcs simpledrm_connector_funcs = {
-   .reset = drm_atomic_helper_connector_reset,
-   .fill_modes = drm_helper_probe_single_connector_modes,
+   DRM_SYSFB_CONNECTOR_FUNCS,
.destroy = drm_connector_cleanup,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };
 
 static const struct drm_mode_config_funcs simpledrm_mode_config_funcs = {
-- 
2.48.1

[PATCH 15/18] drm/sysfb: efidrm: Add EDID support

Enable the connector's EDID property if edid_info contains valid
data. Exports the EDID via sysfs for user-space compositors.

EDID information is not always available. Depending on the system
and kernel configuration, it is either provided by the boot loader
or read by the kernel during early boot stages.

As of now, there's only one EFI display, so that EDID data always
belongs to this output. This might change if there's ever more than
one EFI display in the system.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/efidrm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/sysfb/efidrm.c b/drivers/gpu/drm/sysfb/efidrm.c
index 5c1876e34a04..af90064a4c04 100644
--- a/drivers/gpu/drm/sysfb/efidrm.c
+++ b/drivers/gpu/drm/sysfb/efidrm.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +23,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include "drm_sysfb_helper.h"
@@ -308,6 +310,10 @@ static struct efidrm_device *efidrm_device_create(struct 
drm_driver *drv,
drm_dbg(dev, "framebuffer format=%p4cc, size=%dx%d, stride=%d bytes\n",
&format->format, width, height, stride);
 
+#ifdef CONFIG_X86
+   if (drm_edid_header_is_valid(edid_info.dummy) == 8)
+   sysfb->edid = edid_info.dummy;
+#endif
sysfb->fb_mode = drm_sysfb_mode(width, height, 0, 0);
sysfb->fb_format = format;
sysfb->fb_pitch = stride;
@@ -413,6 +419,8 @@ static struct efidrm_device *efidrm_device_create(struct 
drm_driver *drv,
drm_connector_set_panel_orientation_with_quirk(connector,
   
DRM_MODE_PANEL_ORIENTATION_UNKNOWN,
   width, height);
+   if (sysfb->edid)
+   drm_connector_attach_edid_property(connector);
 
ret = drm_connector_attach_encoder(connector, encoder);
if (ret)
-- 
2.48.1

Re: [PATCH 1/2] dt-bindings: display: simple: Add NLT NL13676BC25-03F panel

2025-03-19 Thread Krzysztof Kozlowski

On Tue, Mar 18, 2025 at 08:58:28AM +0100, Antonin Godard wrote:
> Add NLT NL13676BC25-03F 15.6" LCD-TFT LVDS panel compatible string.
> 
> Signed-off-by: Antonin Godard 
> ---
>  .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[PATCH 03/18] drm/simpledrm: Remove struct simpledrm_device.nformats

The field nformats is unused. Remove it.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tiny/simpledrm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 5d9ab8adf800..d949713f5ff6 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -246,7 +246,6 @@ struct simpledrm_device {
 
/* modesetting */
uint32_t formats[8];
-   size_t nformats;
struct drm_plane primary_plane;
struct drm_crtc crtc;
struct drm_encoder encoder;
-- 
2.48.1

Re: [PATCH 5/7] drm/gem: Add a flag to control whether objects can be exported

Am 18.03.25 um 20:22 schrieb Daniel Almeida:
> From: Asahi Lina 
>
> Drivers may want to support driver-private objects, which cannot be
> shared. This allows them to share a single lock and enables other
> optimizations.
>
> Add an `exportable` field to drm_gem_object, which blocks PRIME export
> if set to false. It is initialized to true in
> drm_gem_private_object_init.

We already have a method for doing that which is used by almost all drivers 
(except for lsdc).

Basically you just create a function which checks the per-requisites if a 
buffer can be exported before calling drm_gem_prime_export() and installs that 
as .export callback into the drm_gem_object_funcs.

See amdgpu_gem_prime_export() for a simpler example.

Regards,
Christian.

>
> Signed-off-by: Asahi Lina 
> Signed-off-by: Daniel Almeida 
> ---
>  drivers/gpu/drm/drm_gem.c   | 1 +
>  drivers/gpu/drm/drm_prime.c | 5 +
>  include/drm/drm_gem.h   | 8 
>  3 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 
> ee811764c3df4b4e9c377a66afd4967512ba2001..8f998fe6beecd285ce3e2d5badfa95eb7d7bd548
>  100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -195,6 +195,7 @@ void drm_gem_private_object_init(struct drm_device *dev,
>  
>   drm_vma_node_reset(&obj->vma_node);
>   INIT_LIST_HEAD(&obj->lru_node);
> + obj->exportable = true;
>  }
>  EXPORT_SYMBOL(drm_gem_private_object_init);
>  
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 
> 32a8781cfd67b82ece7b7b94625715171bb41917..20aa350280abe9a6ed6742e131ff50c65bc9dfa9
>  100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -387,6 +387,11 @@ static struct dma_buf *export_and_register_object(struct 
> drm_device *dev,
>   return dmabuf;
>   }
>  
> + if (!obj->exportable) {
> + dmabuf = ERR_PTR(-EINVAL);
> + return dmabuf;
> + }
> +
>   if (obj->funcs && obj->funcs->export)
>   dmabuf = obj->funcs->export(obj, flags);
>   else
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index 
> fdae947682cd0b7b06db5e35e120f049a0f30179..f700e4996eccb92597cca6b8c3df8e35b864c1e1
>  100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -432,6 +432,14 @@ struct drm_gem_object {
>* The current LRU list that the GEM object is on.
>*/
>   struct drm_gem_lru *lru;
> +
> + /**
> +  * @exportable:
> +  *
> +  * Whether this GEM object can be exported via the 
> drm_gem_object_funcs->export
> +  * callback. Defaults to true.
> +  */
> + bool exportable;
>  };
>  
>  /**
>

Re: [PATCH 2/7] drm/gem-shmem: Export VM ops functions

Am 18.03.25 um 20:22 schrieb Daniel Almeida:
> From: Asahi Lina 
>
> There doesn't seem to be a way for the Rust bindings to get a
> compile-time constant reference to drm_gem_shmem_vm_ops, so we need to
> duplicate that structure in Rust... this isn't nice...

Well "isn't nice" is an understatement. We can have that as a short term hack, 
but I don't think that this is a doable long term solution.

For this particular case here it most likely doesn't matter, but operation 
pointer structures are often used to identify a certain class of object.

So exporting the functions and then re-creating the constant operation pointer 
structure in Rust doesn't work in some cases.

Regards,
Christian.

>
> Signed-off-by: Asahi Lina 
> Signed-off-by: Daniel Almeida 
> ---
>  drivers/gpu/drm/drm_gem_shmem_helper.c | 9 ++---
>  include/drm/drm_gem_shmem_helper.h | 3 +++
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 
> ec89e9499f5f02a2a35713669bf649dd2abb9938..be310db5863871604f3502ad1f419937d4c20a84
>  100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -535,7 +535,7 @@ int drm_gem_shmem_dumb_create(struct drm_file *file, 
> struct drm_device *dev,
>  }
>  EXPORT_SYMBOL_GPL(drm_gem_shmem_dumb_create);
>  
> -static vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
> +vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf)
>  {
>   struct vm_area_struct *vma = vmf->vma;
>   struct drm_gem_object *obj = vma->vm_private_data;
> @@ -564,8 +564,9 @@ static vm_fault_t drm_gem_shmem_fault(struct vm_fault 
> *vmf)
>  
>   return ret;
>  }
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_fault);
>  
> -static void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
> +void drm_gem_shmem_vm_open(struct vm_area_struct *vma)
>  {
>   struct drm_gem_object *obj = vma->vm_private_data;
>   struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> @@ -586,8 +587,9 @@ static void drm_gem_shmem_vm_open(struct vm_area_struct 
> *vma)
>  
>   drm_gem_vm_open(vma);
>  }
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_open);
>  
> -static void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
> +void drm_gem_shmem_vm_close(struct vm_area_struct *vma)
>  {
>   struct drm_gem_object *obj = vma->vm_private_data;
>   struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj);
> @@ -598,6 +600,7 @@ static void drm_gem_shmem_vm_close(struct vm_area_struct 
> *vma)
>  
>   drm_gem_vm_close(vma);
>  }
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_vm_close);
>  
>  const struct vm_operations_struct drm_gem_shmem_vm_ops = {
>   .fault = drm_gem_shmem_fault,
> diff --git a/include/drm/drm_gem_shmem_helper.h 
> b/include/drm/drm_gem_shmem_helper.h
> index 
> d22e3fb53631ab655748d7f6c628ffdb402f6324..b70d3cc35bd194e7cd718bee220408b5dda568bf
>  100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -132,6 +132,9 @@ void drm_gem_shmem_print_info(const struct 
> drm_gem_shmem_object *shmem,
> struct drm_printer *p, unsigned int indent);
>  
>  extern const struct vm_operations_struct drm_gem_shmem_vm_ops;
> +vm_fault_t drm_gem_shmem_fault(struct vm_fault *vmf);
> +void drm_gem_shmem_vm_open(struct vm_area_struct *vma);
> +void drm_gem_shmem_vm_close(struct vm_area_struct *vma);
>  
>  /*
>   * GEM object functions
>

Re: [PATCH v7 drm-dp 0/9] Add HPD, getting EDID, colorbar features in DP function

2025-03-19 Thread Dmitry Baryshkov

On Wed, Mar 19, 2025 at 11:24:26AM +0800, Yongbang Shi wrote:
> From: Baihan Li 
> 
> To support DP HPD, edid printing, and colorbar display features based on
> the Hisislcon DP devices.
> ---
> ChangeLog:
> v6 -> v7:
>   - add if statement about drm aux in hibmc_dp_connector_get_modes(), 
> suggested by Jani Nikula

Where was that suggestion? Also, would you please implement his feedback
regarding drm_edid_read()?

>   v6: 
> https://lore.kernel.org/all/20250310040138.2025715-1-shiyongb...@huawei.com/
> v5 -> v6:
>   - fix the DP_SERDES_VOL2_PRE0 value after electrical test.
>   - move the detect_ctx() to the patch 7/9.
>   - add detect_ctx with 200ms delay, suggested by Dmitry Baryshkov.
>   v5: 
> https://lore.kernel.org/all/20250307101640.4003229-1-shiyongb...@huawei.com/
> v4 -> v5:
>   - add commit log about hibmc_kms_init(), suggested by Dmitry Baryshkov.
>   - fix the format of block comments, suggested by Dmitry Baryshkov.
>   - add hibmc_dp_get_serdes_rate_cfg() to correct transferring serdes cfg.
>   - separate the vga part commit, suggested by Dmitry Baryshkov.
>   - remove pci_disable_msi() in hibmc_unload()
>   v4: 
> https://lore.kernel.org/all/20250305112647.2344438-1-shiyongb...@huawei.com/
> v3 -> v4:
>   - fix the serdes cfg in hibmc_dp_serdes_set_tx_cfg(), suggested by Dmitry 
> Baryshkov.
>   - move the dp serdes registers to dp_reg.h, suggested by Dmitry Baryshkov.
>   - add comments for if-statement of dp_init(), suggested by Dmitry Baryshkov.
>   - fix the comment log to imperative sentence, suggested by Dmitry Baryshkov.
>   - add comments in hibmc_control_write(), suggested by Dmitry Baryshkov.
>   - add link reset of rates and lanes in pre link training process, suggested 
> by Dmitry Baryshkov.
>   - add vdac detect and connected/disconnected status to enable HPD process, 
> suggested by Dmitry Baryshkov.
>   - remove a drm_client, suggested by Dmitry Baryshkov.
>   - fix build errors reported by kernel test robot 
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202502231304.bczv4y8d-...@intel.com/
>   v3: 
> https://lore.kernel.org/all/20250222025102.1519798-1-shiyongb...@huawei.com/
> v2 -> v3:
>   - restructuring the header p_reg.h, suggested by Dmitry Baryshkov.
>   - add commit log about dp serdes, suggested by Dmitry Baryshkov.
>   - return value in hibmc_dp_serdes_init(), suggested by Dmitry Baryshkov.
>   - add static const in the array of serdes_tx_cfg[], suggested by Dmitry 
> Baryshkov.
>   - change drm_warn to drm_dbg_dp, suggested by Dmitry Baryshkov.
>   - add explanations about dp serdes macros, suggested by Dmitry Baryshkov.
>   - change commit to an imperative sentence, suggested by Dmitry Baryshkov.
>   - put HIBMC_DP_HOST_SERDES_CTRL in dp_serdes.h, suggested by Dmitry 
> Baryshkov.
>   - split the patch into two parts, suggested by Dmitry Baryshkov.
>   - Capitalized EDID and AUX, suggested by Dmitry Baryshkov.
>   - rewrite the commit log, suggested by Dmitry Baryshkov.
>   - move colorbar debugfs entry to this patch, suggested by Dmitry Baryshkov.
>   - change binary format to integer format, suggested by Dmitry Baryshkov.
>   - remove mdelay(100) hpd function in ISR, suggested by Dmitry Baryshkov.
>   - remove enble_display in ISR, suggested by Dmitry Baryshkov.
>   - change drm_kms_helper_connector_hotplug_event() to
> drm_connector_helper_hpd_irq_event(), suggested by Dmitry Baryshkov.
>   - move macros to dp_reg.h, suggested by Dmitry Baryshkov.
>   - remove struct irqs, suggested by Dmitry Baryshkov.
>   - split this patch into two parts, suggested by Dmitry Baryshkov.
>   v2: 
> https://lore.kernel.org/all/20250210144959.100551-1-shiyongb...@huawei.com/
> v1 -> v2:
>   - splittting the patch and add more detailed the changes in the commit 
> message, suggested by Dmitry Baryshkov.
>   - changing all names of dp phy to dp serdes.
>   - deleting type conversion, suggested by Dmitry Baryshkov.
>   - deleting hibmc_dp_connector_get_modes() and using 
> drm_connector_helper_get_modes(), suggested by Dmitry Baryshkov.
>   - add colorbar introduction in commit, suggested by Dmitry Baryshkov.
>   - deleting edid decoder and its debugfs, suggested by Dmitry Baryshkov.
>   - using debugfs_init() callback, suggested by Dmitry Baryshkov.
>   - splittting colorbar and debugfs in different patches, suggested by Dmitry 
> Baryshkov.
>   - optimizing the description in commit message, suggested by Dmitry 
> Baryshkov.
>   - add mdelay(100) comments, suggested by Dmitry Baryshkov.
>   - deleting display enable in hpd event, suggested by Dmitry Baryshkov.
>   v1: 
> https://lore.kernel.org/all/20250127032024.1542219-1-shiyongb...@huawei.com/
> ---
> 
> Baihan Li (9):
>   drm/hisilicon/hibmc: Restructuring the header dp_reg.h
>   drm/hisilicon/hibmc: Add dp serdes cfg to adjust serdes rate, voltage
> and pre-emphasis
>   drm/hisilicon/hibmc: Add dp serdes cfg in dp process
>   drm/hisilicon/hibmc: Refactor the member of drm_aux in struct hibmc_dp
>   drm/

[PATCH v9 1/3] drm/plane: Add new plane property IN_FORMATS_ASYNC

2025-03-19 Thread Arun R Murthy

There exists a property IN_FORMATS which exposes the plane supported
modifiers/formats to the user. In some platforms when asynchronous flip
are used all of modifiers/formats mentioned in IN_FORMATS are not
supported. This patch adds a new plane property IN_FORMATS_ASYNC to
expose the async flip supported modifiers/formats so that user can use
this information ahead and do flip with unsupported
formats/modifiers. This will save flip failures.
Add a new function pointer similar to format_mod_supported specifically
for asynchronous flip.

v2: Remove async variable from drm_plane (Ville)
v3: Add new function pointer for async (Ville)
v5: Typo corrected in commit message & some correction in the kernel
documentation. (Chaitanya)
v7: Place IN_FORMATS_ASYNC next to IN_FORMATS (Ville)
v8: replace uint32_t with u32 and uint64_t with u64 (Chaitanya)

Signed-off-by: Arun R Murthy 
Reviewed-by: Chaitanya Kumar Borah 
Tested-by: Naveen Kumar 
---
 drivers/gpu/drm/drm_mode_config.c |  7 +++
 drivers/gpu/drm/drm_plane.c   |  8 
 include/drm/drm_mode_config.h |  6 ++
 include/drm/drm_plane.h   | 17 +
 4 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 
8642a2fb25a90116dab975aa0ab6b51deafb4b96..b4239fd04e9da4d4b5cfccdef1d3dde9556f322d
 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -381,6 +381,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.modifiers_property = prop;
 
+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS_ASYNC", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.async_modifiers_property = prop;
+
prop = drm_property_create(dev,
   DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
   "SIZE_HINTS", 0);
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 
a28b22fdd7a41aca82d097d42237851da9a0a79b..fe181c1002171acc68d3054c2d178f9b9f501fe2
 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -141,6 +141,14 @@
  * various bugs in this area with inconsistencies between the capability
  * flag and per-plane properties.
  *
+ * IN_FORMATS_ASYNC:
+ * Blob property which contains the set of buffer format and modifier
+ * pairs supported by this plane for asynchronous flips. The blob is a 
struct
+ * drm_format_modifier_blob. Userspace cannot change this property. This 
is an
+ * optional property and if not present then user should expect a failure 
in
+ * atomic ioctl when the modifier/format is not supported by that plane 
under
+ * asynchronous flip.
+ *
  * SIZE_HINTS:
  * Blob property which contains the set of recommended plane size
  * which can used for simple "cursor like" use cases (eg. no scaling).
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 
271765e2e9f2da62aaf0d258828ef4196e14822e..0c116d6dfd277262b1a4c0f097fce2d719f43844
 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -936,6 +936,12 @@ struct drm_mode_config {
 */
struct drm_property *modifiers_property;
 
+   /**
+* @async_modifiers_property: Plane property to list support 
modifier/format
+* combination for asynchronous flips.
+*/
+   struct drm_property *async_modifiers_property;
+
/**
 * @size_hints_property: Plane SIZE_HINTS property.
 */
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index 
dd718c62ac31bf16606f3ee9f025a5b171cd1e67..01479dd94e76a8389a0c9e9d6744400aa2291064
 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -549,6 +549,23 @@ struct drm_plane_funcs {
 */
bool (*format_mod_supported)(struct drm_plane *plane, uint32_t format,
 uint64_t modifier);
+   /**
+* @format_mod_supported_async:
+*
+* This optional hook is used for the DRM to determine if for
+* asynchronous flip the given format/modifier combination is valid for
+* the plane. This allows the DRM to generate the correct format
+* bitmask (which formats apply to which modifier), and to validate
+* modifiers at atomic_check time.
+*
+* Returns:
+*
+* True if the given modifier is valid for that format on the plane.
+* False otherwise.
+*/
+   bool (*format_mod_supported_async)(struct drm_plane *plane,
+  u32 format, u64 modifier);
+
 };
 
 /**

-- 
2.25.1

RE: [PATCH v8 01/14] drm: Define histogram structures exposed to user

2025-03-19 Thread Murthy, Arun R

> On Mon, 3 Mar 2025 13:23:42 +0530
> "Murthy, Arun R"  wrote:
> 
> > On 20-02-2025 21:20, Pekka Paalanen wrote:
> > > On Wed, 19 Feb 2025 09:28:51 +0530
> > > "Murthy, Arun R"  wrote:
> > >
> > >> On 18-02-2025 21:48, Pekka Paalanen wrote:
> > >>> On Tue, 18 Feb 2025 11:13:39 +0530 "Murthy, Arun
> > >>> R" wrote:
> > >>>
> >  On 17-02-2025 15:38, Pekka Paalanen wrote:
> > > Hi Arun,
> > >
> > > this whole series seems to be missing all the UAPI docs for the
> > > DRM ReST files, e.g. drm-kms.rst. The UAPI header doc comments
> > > are not a replacement for them, I would assume both are a
> requirement.
> > >
> > > Without the ReST docs it is really difficult to see how this new
> > > UAPI should be used.
> >  Hi Pekka,
> >  I also realized later on this. Will add this in my next patchset.
> > > On Tue, 28 Jan 2025 21:21:07 +0530 Arun R
> > > Murthy wrote:
> > >
> > >> Display Histogram is an array of bins and can be generated in
> > >> many ways referred to as modes.
> > >> Ex: HSV max(RGB), Wighted RGB etc.
> > >>
> > >> Understanding the histogram data format(Ex: HSV max(RGB))
> > >> Histogram is just the pixel count.
> > >> For a maximum resolution of 10k (10240 x 4320 = 44236800)
> > >> 25 bits should be sufficient to represent this along with a
> > >> buffer of 7 bits(future use) u32 is being considered.
> > >> max(RGB) can be 255 i.e 0xFF 8 bit, considering the most
> > >> significant 5 bits, hence 32 bins.
> > >> Below mentioned algorithm illustrates the histogram generation
> > >> in hardware.
> > >>
> > >> hist[32] = {0};
> > >> for (i = 0; i < resolution; i++) {
> > >>  bin = max(RGB[i]);
> > >>  bin = bin >> 3; /* consider the most significant bits */
> > >>  hist[bin]++;
> > >> }
> > >> If the entire image is Red color then max(255,0,0) is 255 so
> > >> the pixel count of each pixels will be placed in the last bin.
> > >> Hence except hist[31] all other bins will have a value zero.
> > >> Generated histogram in this case would be hist[32] =
> > >> {0,0,44236800}
> > >>
> > >> Description of the structures, properties defined are
> > >> documented in the header file include/uapi/drm/drm_mode.h
> > >>
> > >> v8: Added doc for HDR planes, removed reserved variables
> > >> (Dmitry)
> > >>
> > >> Signed-off-by: Arun R Murthy
> > >> ---
> > >> include/uapi/drm/drm_mode.h | 65
> +
> > >> 1 file changed, 65 insertions(+)
> 
> ...
> 
> > > Hi Arun,
> > >
> > > sure, it may be by hardware design, but the UAPI must specify or
> > > communicate exactly what it is. This seems to be the recurring theme
> > > in all the remaining comments, so I trimmed them away.
> > >
> > > A generic UAPI is mandatory, because that's KMS policy AFAIU. A
> > > generic UAPI cannot key anything off of the hardware revision.
> > > Instead, everything must be specified and communicated explicitly.
> > > It's good if AMD has similar functionality, someone from their team
> > > could take a look so you can come up with an UAPI that works for both.
> > >
> > > Dmitry Baryshkov tried to ask for the same thing. Assuming I know
> > > nothing about the hardware, and the only documentation I have is the
> > > KMS UAPI documentation (userland side, not kernel internals), I
> > > should be able to write a program from scratch that correctly
> > > records and analyses the histogram on every piece of hardware where
> > > the kernel driver exposes it. That means explaining exactly what the
> > > driver and the hardware will do when I poke that UAPI.
> >
> > Hi Pekka,
> > Sorry got getting back late on this.
> > I totally agree that the UAPI should not be any hardware specific and
> > have taken care to get rid of such if any.
> > Here we are just exposing the histogram data and what point is the
> > histogram generated is out of the scope.
> 
> It's not out of scope. Understanding exactly at what point the histogram is
> generated in the KMS pixel pipeline is paramount to being able to use the
> results correctly - how it relates to the framebuffers'
> contents and KMS pixel pipeline configuration.
> 

While working around this comment, it looks to be quite challenging to
address this comment and agree that this will have to be addressed and is 
important for the user to know at which point in the pixel pipeline 
configuration
the histogram is generated.
I can think of 2 options on addressing this.

1.  Have this documented in the driver. Since this can vary on each vendor
hardware, can have this documented in the drivers or ReST document.

2. Maybe have a bitmapping like we have it for histogram_mode. Define 
user readable macros for that.
Ex: CC1_DEGAMMA_HIST_CC2
In this case histogram is between the two color conversion hardware block
in the pixel pipeline.
This macro will ha

Re: [PATCH 00/18] drm: Provide helpers for system framebuffers and add efidrm/vesadrm

Am 19.03.25 um 13:50 schrieb nerdopolis:

On Wednesday, March 19, 2025 3:44:59 AM EDT Thomas Zimmermann wrote:

Patches 1 to 3 clean up obsolete artifacts from ofdrm and simpledrm.

Patch 12 adds EDID support to ofdrm. The EDID data can be found in
some Macintosh's DeviceTree next to the framebuffer configuration.
EDID support will be useful for EFI and VESA as well.

Patch 13 adds another helper for screen_info that will be required
by EFI and VESA drivers.

This series has been tested on various devices that require the provided
drivers.

[1]
https://build.opensuse.org/projects/home:tdz:branches:Base:System/packages/grub2/files/grub2-provide-edid.patch?expand=1

Re: [PATCH v1 1/3] drm/ci: uprev mesa

2025-03-19 Thread Vignesh Raman


Hi Helen,

On 19/03/25 00:22, Helen Mae Koike Fornazier wrote:

Em sex., 14 de mar. de 2025 às 05:59, Vignesh Raman
 escreveu:


LAVA was recently patched [1] with a fix on how parameters are parsed in
`lava-test-case`, so we don't need to repeat quotes to send the
arguments properly to it. Uprev mesa to fix this issue.

[1] https://gitlab.com/lava/lava/-/commit/18c9cf79

Signed-off-by: Vignesh Raman 
---
  drivers/gpu/drm/ci/build.sh   | 16 
  drivers/gpu/drm/ci/build.yml  |  8 
  drivers/gpu/drm/ci/container.yml  | 24 +++
  drivers/gpu/drm/ci/gitlab-ci.yml  | 32 ++-
  drivers/gpu/drm/ci/image-tags.yml |  4 +++-
  drivers/gpu/drm/ci/lava-submit.sh |  3 ++-
  drivers/gpu/drm/ci/test.yml   |  2 +-
  7 files changed, 77 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 19fe01257ab9..284873e94d8d 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -98,14 +98,14 @@ done

  make ${KERNEL_IMAGE_NAME}

-mkdir -p /lava-files/
+mkdir -p /kernel/


the folder is not lava specific, correct?


It is not lava specific. Only the directory name where the kernel image 
is copied is changed and the kernel image is uploaded to S3 for lava.


This is based on,
https://gitlab.freedesktop.org/mesa/mesa/-/commit/5b65bbf72ce7024c5df2100ce4b12d59e8f3dd26




  for image in ${KERNEL_IMAGE_NAME}; do
-cp arch/${KERNEL_ARCH}/boot/${image} /lava-files/.
+cp arch/${KERNEL_ARCH}/boot/${image} /kernel/.
  done

  if [[ -n ${DEVICE_TREES} ]]; then
  make dtbs
-cp ${DEVICE_TREES} /lava-files/.
+cp ${DEVICE_TREES} /kernel/.
  fi

  make modules
@@ -121,11 +121,11 @@ if [[ ${DEBIAN_ARCH} = "arm64" ]]; then
  -d arch/arm64/boot/Image.lzma \
  -C lzma\
  -b arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dtb \
-/lava-files/cheza-kernel
+/kernel/cheza-kernel
  KERNEL_IMAGE_NAME+=" cheza-kernel"

  # Make a gzipped copy of the Image for db410c.
-gzip -k /lava-files/Image
+gzip -k /kernel/Image
  KERNEL_IMAGE_NAME+=" Image.gz"
  fi

@@ -139,7 +139,7 @@ cp -rfv drivers/gpu/drm/ci/* install/.
  . .gitlab-ci/container/container_post_build.sh

  if [[ "$UPLOAD_TO_MINIO" = "1" ]]; then
-xz -7 -c -T${FDO_CI_CONCURRENT:-4} vmlinux > /lava-files/vmlinux.xz
+xz -7 -c -T${FDO_CI_CONCURRENT:-4} vmlinux > /kernel/vmlinux.xz
  FILES_TO_UPLOAD="$KERNEL_IMAGE_NAME vmlinux.xz"

  if [[ -n $DEVICE_TREES ]]; then
@@ -148,7 +148,7 @@ if [[ "$UPLOAD_TO_MINIO" = "1" ]]; then

  ls -l "${S3_JWT_FILE}"
  for f in $FILES_TO_UPLOAD; do
-ci-fairy s3cp --token-file "${S3_JWT_FILE}" /lava-files/$f \
+ci-fairy s3cp --token-file "${S3_JWT_FILE}" /kernel/$f \
  https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/$f
  done

@@ -165,7 +165,7 @@ ln -s common artifacts/install/ci-common
  cp .config artifacts/${CI_JOB_NAME}_config

  for image in ${KERNEL_IMAGE_NAME}; do
-cp /lava-files/$image artifacts/install/.
+cp /kernel/$image artifacts/install/.
  done

  tar -C artifacts -cf artifacts/install.tar install
diff --git a/drivers/gpu/drm/ci/build.yml b/drivers/gpu/drm/ci/build.yml
index 6c0dc10b547c..8eb56ebcf4aa 100644
--- a/drivers/gpu/drm/ci/build.yml
+++ b/drivers/gpu/drm/ci/build.yml
@@ -143,6 +143,10 @@ debian-arm64-release:
rules:
  - when: never

+debian-arm64-ubsan:
+  rules:
+- when: never
+
  debian-build-testing:
rules:
  - when: never
@@ -183,6 +187,10 @@ debian-testing-msan:
rules:
  - when: never

+debian-testing-ubsan:
+  rules:
+- when: never
+
  debian-vulkan:
rules:
  - when: never
diff --git a/drivers/gpu/drm/ci/container.yml b/drivers/gpu/drm/ci/container.yml
index 07dc13ff865d..56c95c2f91ae 100644
--- a/drivers/gpu/drm/ci/container.yml
+++ b/drivers/gpu/drm/ci/container.yml
@@ -24,6 +24,18 @@ alpine/x86_64_build:
rules:
  - when: never

+debian/arm32_test-base:
+  rules:
+- when: never
+
+debian/arm32_test-gl:
+  rules:
+- when: never
+
+debian/arm32_test-vk:
+  rules:
+- when: never
+
  debian/arm64_test-gl:
rules:
  - when: never
@@ -32,6 +44,10 @@ debian/arm64_test-vk:
rules:
  - when: never

+debian/baremetal_arm32_test:
+  rules:
+- when: never
+
  debian/ppc64el_build:
rules:
  - when: never
@@ -40,6 +56,14 @@ debian/s390x_build:
rules:
  - when: never

+debian/x86_32_build:
+  rules:
+- when: never
+
+debian/x86_64_test-android:
+  rules:
+- when: never
+
  debian/x86_64_test-vk:
rules:
  - when: never
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index b06b9e7d3d09..55b540c4cf92 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
  variables:
DRM_CI_PROJECT_PATH: &drm-ci-project-path mesa/mesa
-  DRM_CI_COMMIT_SHA: &drm-ci-commit-sha 
7d3062470f3ccc6

[PATCH 17/18] drm/sysfb: vesadrm: Add EDID support

Enable the connector's EDID property if edid_info contains valid
data. Exports the EDID via sysfs for user-space compositors.

EDID information is not always available. Depending on the system
and kernel configuration, it is either provided by the boot loader
or read by the kernel during early boot stages.

There's only one VESA display, so EDID data always belongs to this
output.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sysfb/vesadrm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/sysfb/vesadrm.c b/drivers/gpu/drm/sysfb/vesadrm.c
index 8a963057ffec..07f59880ce0f 100644
--- a/drivers/gpu/drm/sysfb/vesadrm.c
+++ b/drivers/gpu/drm/sysfb/vesadrm.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -22,6 +23,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include "drm_sysfb_helper.h"
@@ -280,6 +282,10 @@ static struct vesadrm_device *vesadrm_device_create(struct 
drm_driver *drv,
drm_dbg(dev, "framebuffer format=%p4cc, size=%dx%d, stride=%d bytes\n",
&format->format, width, height, stride);
 
+#ifdef CONFIG_X86
+   if (drm_edid_header_is_valid(edid_info.dummy) == 8)
+   sysfb->edid = edid_info.dummy;
+#endif
sysfb->fb_mode = drm_sysfb_mode(width, height, 0, 0);
sysfb->fb_format = format;
sysfb->fb_pitch = stride;
@@ -374,6 +380,8 @@ static struct vesadrm_device *vesadrm_device_create(struct 
drm_driver *drv,
drm_connector_set_panel_orientation_with_quirk(connector,
   
DRM_MODE_PANEL_ORIENTATION_UNKNOWN,
   width, height);
+   if (sysfb->edid)
+   drm_connector_attach_edid_property(connector);
 
ret = drm_connector_attach_encoder(connector, encoder);
if (ret)
-- 
2.48.1

Re: [PATCH v2] drm/nouveau: prime: fix ttm_bo_delayed_delete oops

2025-03-19 Thread Danilo Krummrich

Hi Chris,

Thanks for the fix, few comments below.

On Wed, Mar 19, 2025 at 12:54:26PM +, Chris Bainbridge wrote:
> Fix an oops in ttm_bo_delayed_delete which results from dererencing a
> dangling pointer:
> 
> Oops: general protection fault, probably for non-canonical address 
> 0x6b6b6b6b6b6b6b7b:  [#1] PREEMPT SMP
> CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 
> 6.14.0-rc4-00267-g505460b44513-dirty #216
> Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024
> Workqueue: ttm ttm_bo_delayed_delete [ttm]
> RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290
> Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 
> e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 
> 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b
> RSP: 0018:bf9383473d60 EFLAGS: 00010202
> RAX: 0001 RBX: bf9383473d88 RCX: 
> RDX:  RSI:  RDI: 
> RBP: bf9383473d78 R08:  R09: 
> R10:  R11:  R12: 6b6b6b6b6b6b6b6b
> R13: a003bbf78580 R14: a003a6728040 R15: 000383cc
> FS:  () GS:a00991c0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 758348024dd0 CR3: 00012c259000 CR4: 00f50ef0
> PKRU: 5554
> Call Trace:
>  
>  ? __die_body.cold+0x19/0x26
>  ? die_addr+0x3d/0x70
>  ? exc_general_protection+0x159/0x460
>  ? asm_exc_general_protection+0x27/0x30
>  ? dma_resv_iter_first_unlocked+0x55/0x290
>  dma_resv_wait_timeout+0x56/0x100
>  ttm_bo_delayed_delete+0x69/0xb0 [ttm]
>  process_one_work+0x217/0x5c0
>  worker_thread+0x1c8/0x3d0
>  ? apply_wqattrs_cleanup.part.0+0xc0/0xc0
>  kthread+0x10b/0x240
>  ? kthreads_online_cpu+0x140/0x140
>  ret_from_fork+0x40/0x70
>  ? kthreads_online_cpu+0x140/0x140
>  ret_from_fork_asm+0x11/0x20
>  
> 
> The cause of this is:
> 
> - drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the
>   reference to the shared dma_buf. The reference count is 0, so the
>   dma_buf is destroyed, which in turn decrements the corresponding
>   amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed -
>   calling drm_gem_object_release then dma_resv_fini (which destroys the
>   reservation object), then finally freeing the amdgpu_bo.
> 
> - nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory
>   formerly allocated to the amdgpu_bo.
> 
> - nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls
>   ttm_bo_release, which schedules ttm_bo_delayed_delete.
> 
> - ttm_bo_delayed_delete runs and dereferences the dangling resv pointer,
>   resulting in a general protection fault.
> 
> Fix this by moving the drm_prime_gem_destroy call from
> nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will
> be run after ttm_bo_delayed_delete.
> 
> Signed-off-by: Chris Bainbridge 
> Co-Developed-by: Christian König 

Then also Christian's SoB is required.

> Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/3937

This is a bug report from amdgpu, but I understand that the same issue applies
for nouveau.

If at all, this needs to be

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3937

Maybe you can add a brief comment that this report applies for nouveau as well.

Please also add a Fixes: tag that indicates the commit in nouveau that
introduced the problem and Cc stable.

> ---
>  drivers/gpu/drm/drm_prime.c   | 8 ++--
>  drivers/gpu/drm/nouveau/nouveau_bo.c  | 3 +++
>  drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ---
>  3 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 32a8781cfd67..452d5c7cd292 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -929,7 +929,9 @@ EXPORT_SYMBOL(drm_gem_prime_export);
>   * &drm_driver.gem_prime_import_sg_table internally.
>   *
>   * Drivers must arrange to call drm_prime_gem_destroy() from their
> - * &drm_gem_object_funcs.free hook when using this function.
> + * &drm_gem_object_funcs.free hook or &ttm_buffer_object.destroy
> + * hook when using this function, to avoid the dma_buf being freed while the
> + * ttm_buffer_object can still dereference it.
>   */
>  struct drm_gem_object *drm_gem_prime_import_dev(struct drm_device *dev,
>   struct dma_buf *dma_buf,
> @@ -999,7 +1001,9 @@ EXPORT_SYMBOL(drm_gem_prime_import_dev);
>   * implementation in drm_gem_prime_fd_to_handle().
>   *
>   * Drivers must arrange to call drm_prime_gem_destroy() from their
> - * &drm_gem_object_funcs.free hook when using this function.
> + * &drm_gem_object_funcs.free hook or &ttm_buffer_object.destroy
> + * hook when using this function, to avoid the dma_buf being freed while the
> + * ttm_buffer_object can still dereference it.
>   */
>  struct drm_gem_object *drm_gem_prime_

Re: [PATCH v2] drm/nouveau: prime: fix ttm_bo_delayed_delete oops

2025-03-19 Thread Danilo Krummrich

On Wed, Mar 19, 2025 at 03:06:52PM +0100, Christian König wrote:
> Am 19.03.25 um 14:04 schrieb Danilo Krummrich:
> 
> >> Signed-off-by: Chris Bainbridge 
> >> Co-Developed-by: Christian König 
> > Then also Christian's SoB is required.
> 
> I only pointed out which two lines in nouveau need to move to fix this.
> 
> All the credit to figuring out what's wrong go to Chris, but feel free to add 
> my SoB if required.

Then maybe Suggested-by: is the tags that fits best. :)

> 
> >
> >> Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/3937
> > This is a bug report from amdgpu, but I understand that the same issue 
> > applies
> > for nouveau.
> 
> The crash in amdgpu was caused by nouveau incorrectly dropping a DMA-buf 
> reference while it was still needed.

Oh, I see.

> 
> Took us a while to figure that out, we could update the tags in the bug 
> report but I think at this point it's unnecessary.

Agreed.

> 
> >
> > If at all, this needs to be
> >
> > Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3937
> >
> > Maybe you can add a brief comment that this report applies for nouveau as 
> > well.
> >
> > Please also add a Fixes: tag that indicates the commit in nouveau that
> > introduced the problem and Cc stable.
> 
> As far as I can see it was always there and was added >10years ago with the 
> very first DMA-buf support.
> 
> But adding CC stable is a really good idea.

Sounds good.

Re: [PATCH v2 2/3] rust: alloc: add Vec::resize method

2025-03-19 Thread Miguel Ojeda

On Wed, Mar 19, 2025 at 4:59 PM Tamir Duberstein  wrote:
>
> If we're talking about the same thing then I think we're both wrong
> and the correct phrasing would have been: "you can avoid underflow
> checking when CONFIG_RUST_OVERFLOW_CHECKS=y by using `checked_sub`". I
> was referring to the underflow check implicit in `new_len -
> self.len()`.

`checked_sub` always checks (if not optimized away). The config option
is about the implicit one.

Do you mean avoiding panics?

Cheers,
Miguel

[PATCH v2 14/34] drm/msm: Lazily create context VM

From: Rob Clark 

In the next commit, a way for userspace to opt-in to userspace managed
VM is added.  For this to work, we need to defer creation of the VM
until it is needed.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c   |  3 ++-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 14 +++-
 drivers/gpu/drm/msm/msm_drv.c   | 29 -
 drivers/gpu/drm/msm/msm_gem_submit.c|  2 +-
 drivers/gpu/drm/msm/msm_gpu.h   |  9 +++-
 5 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 4811be5a7c29..0b1e2ba3539e 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -112,6 +112,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
 {
bool sysprof = refcount_read(&a6xx_gpu->base.base.sysprof_active) > 1;
struct msm_context *ctx = submit->queue->ctx;
+   struct drm_gpuvm *vm = msm_context_vm(submit->dev, ctx);
struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
phys_addr_t ttbr;
u32 asid;
@@ -120,7 +121,7 @@ static void a6xx_set_pagetable(struct a6xx_gpu *a6xx_gpu,
if (ctx->seqno == ring->cur_ctx_seqno)
return;
 
-   if (msm_iommu_pagetable_params(to_msm_vm(ctx->vm)->mmu, &ttbr, &asid))
+   if (msm_iommu_pagetable_params(to_msm_vm(vm)->mmu, &ttbr, &asid))
return;
 
if (adreno_gpu->info->family >= ADRENO_7XX_GEN1) {
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0f71703f6ec7..e4d895dda051 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -351,6 +351,8 @@ int adreno_get_param(struct msm_gpu *gpu, struct 
msm_context *ctx,
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct drm_device *drm = gpu->dev;
+   /* Note ctx can be NULL when called from rd_open(): */
+   struct drm_gpuvm *vm = ctx ? msm_context_vm(drm, ctx) : NULL;
 
/* No pointer params yet */
if (*len != 0)
@@ -396,8 +398,8 @@ int adreno_get_param(struct msm_gpu *gpu, struct 
msm_context *ctx,
*value = 0;
return 0;
case MSM_PARAM_FAULTS:
-   if (ctx->vm)
-   *value = gpu->global_faults + 
to_msm_vm(ctx->vm)->faults;
+   if (vm)
+   *value = gpu->global_faults + to_msm_vm(vm)->faults;
else
*value = gpu->global_faults;
return 0;
@@ -405,14 +407,14 @@ int adreno_get_param(struct msm_gpu *gpu, struct 
msm_context *ctx,
*value = gpu->suspend_count;
return 0;
case MSM_PARAM_VA_START:
-   if (ctx->vm == gpu->vm)
+   if (vm == gpu->vm)
return UERR(EINVAL, drm, "requires per-process 
pgtables");
-   *value = ctx->vm->mm_start;
+   *value = vm->mm_start;
return 0;
case MSM_PARAM_VA_SIZE:
-   if (ctx->vm == gpu->vm)
+   if (vm == gpu->vm)
return UERR(EINVAL, drm, "requires per-process 
pgtables");
-   *value = ctx->vm->mm_range;
+   *value = vm->mm_range;
return 0;
case MSM_PARAM_HIGHEST_BANK_BIT:
*value = adreno_gpu->ubwc_config.highest_bank_bit;
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 6ef29bc48bb0..6fd981ee6aee 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -214,10 +214,29 @@ static void load_gpu(struct drm_device *dev)
mutex_unlock(&init_lock);
 }
 
+/**
+ * msm_context_vm - lazily create the context's VM
+ *
+ * @dev: the drm device
+ * @ctx: the context
+ *
+ * The VM is lazily created, so that userspace has a chance to opt-in to having
+ * a userspace managed VM before the VM is created.
+ *
+ * Note that this does not return a reference to the VM.  Once the VM is 
created,
+ * it exists for the lifetime of the context.
+ */
+struct drm_gpuvm *msm_context_vm(struct drm_device *dev, struct msm_context 
*ctx)
+{
+   struct msm_drm_private *priv = dev->dev_private;
+   if (!ctx->vm)
+   ctx->vm = msm_gpu_create_private_vm(priv->gpu, current);
+   return ctx->vm;
+}
+
 static int context_init(struct drm_device *dev, struct drm_file *file)
 {
static atomic_t ident = ATOMIC_INIT(0);
-   struct msm_drm_private *priv = dev->dev_private;
struct msm_context *ctx;
 
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
@@ -230,7 +249,6 @@ static int context_init(struct drm_device *dev, struct 
drm_file *file)
kref_init(&ctx->ref);
msm_submitqueue_init(dev, ctx);
 
-   ctx->vm = msm_gpu_create_private_vm(priv->gpu, current);
file->driver_priv = ctx;
 
ctx->seqn

Re: [PATCH v2 2/3] rust: alloc: add Vec::resize method

2025-03-19 Thread Tamir Duberstein

On Wed, Mar 19, 2025 at 12:06 PM Miguel Ojeda
 wrote:
>
> On Wed, Mar 19, 2025 at 4:59 PM Tamir Duberstein  wrote:
> >
> > If we're talking about the same thing then I think we're both wrong
> > and the correct phrasing would have been: "you can avoid underflow
> > checking when CONFIG_RUST_OVERFLOW_CHECKS=y by using `checked_sub`". I
> > was referring to the underflow check implicit in `new_len -
> > self.len()`.
>
> `checked_sub` always checks (if not optimized away). The config option
> is about the implicit one.
>
> Do you mean avoiding panics?

No, I meant avoiding the check. The existing code already explicitly
checks `new_len > self.len()` before evaluating `new_len -
self.len()`. This means the check occurs twice. `checked_sub` reduces
the number of checks by 1. Perhaps my wording could have been clearer
("avoid *an* underflow check").

Tamir

Re: [PATCH v2 16/34] drm/msm: Mark VM as unusable on faults

2025-03-19 Thread Connor Abbott

On Wed, Mar 19, 2025 at 10:55 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> If userspace has opted-in to VM_BIND, then GPU faults and VM_BIND errors
> will mark the VM as unusable.
>
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/msm_gem.h| 17 +
>  drivers/gpu/drm/msm/msm_gem_submit.c |  3 +++
>  drivers/gpu/drm/msm/msm_gpu.c| 16 ++--
>  3 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index acb976722580..7cb720137548 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -82,6 +82,23 @@ struct msm_gem_vm {
>
> /** @managed: is this a kernel managed VM? */
> bool managed;
> +
> +   /**
> +* @unusable: True if the VM has turned unusable because something
> +* bad happened during an asynchronous request.
> +*
> +* We don't try to recover from such failures, because this implies
> +* informing userspace about the specific operation that failed, and
> +* hoping the userspace driver can replay things from there. This all
> +* sounds very complicated for little gain.
> +*
> +* Instead, we should just flag the VM as unusable, and fail any
> +* further request targeting this VM.
> +*
> +* As an analogy, this would be mapped to a VK_ERROR_DEVICE_LOST
> +* situation, where the logical device needs to be re-created.
> +*/
> +   bool unusable;
>  };
>  #define to_msm_vm(x) container_of(x, struct msm_gem_vm, base)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> b/drivers/gpu/drm/msm/msm_gem_submit.c
> index 9731ad7993cf..9cef308a0ad1 100644
> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> @@ -668,6 +668,9 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void 
> *data,
> if (args->pad)
> return -EINVAL;
>
> +   if (to_msm_vm(ctx->vm)->unusable)
> +   return UERR(EPIPE, dev, "context is unusable");
> +
> /* for now, we just have 3d pipe.. eventually this would need to
>  * be more clever to dispatch to appropriate gpu module:
>  */
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 503e4dcc5a6f..4831f4e42fd9 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -386,8 +386,20 @@ static void recover_worker(struct kthread_work *work)
>
> /* Increment the fault counts */
> submit->queue->faults++;
> -   if (submit->vm)
> -   to_msm_vm(submit->vm)->faults++;
> +   if (submit->vm) {
> +   struct msm_gem_vm *vm = to_msm_vm(submit->vm);
> +
> +   vm->faults++;
> +
> +   /*
> +* If userspace has opted-in to VM_BIND (and therefore 
> userspace
> +* management of the VM), faults mark the VM as unusuable.  
> This
> +* matches vulkan expectations (vulkan is the main target for
> +* VM_BIND)

The bit about this matching Vulkan expectations isn't exactly true.
Some Vulkan implementations do do this, but many will also just ignore
the fault and try to continue going, and the spec allows either. It's
a choice that we're making.

Connor

> +*/
> +   if (!vm->managed)
> +   vm->unusable = true;
> +   }
>
> get_comm_cmdline(submit, &comm, &cmd);
>
> --
> 2.48.1
>

Re: [PATCH v7 00/11] drm/bridge: add devm_drm_bridge_alloc() with bridge refcount

2025-03-19 Thread Maxime Ripard

On Mon, Mar 17, 2025 at 03:56:07PM +0100, Luca Ceresoli wrote:
> Hello Maxime,
> 
> On Fri, 14 Mar 2025 19:21:01 +0100
> Maxime Ripard  wrote:
> 
> > Hi,
> > 
> > On Fri, Mar 14, 2025 at 11:31:13AM +0100, Luca Ceresoli wrote:
> > > This series improves the way DRM bridges are allocated and
> > > initialized and makes them reference-counted. The goal of reference
> > > counting is to avoid use-after-free by drivers which got a pointer
> > > to a bridge and keep it stored and used even after the bridge has
> > > been deallocated.
> > > 
> > > The overall goal is supporting Linux devices with a DRM pipeline
> > > whose final components can be hot-plugged and hot-unplugged,
> > > including one or more bridges. For more details see the big picture
> > > [0].
> > > 
> > > DRM bridge drivers will have to be adapted to the new API, which is
> > > pretty simple for most cases. Refcounting will have to be adopted
> > > on the two sides: all functions returning a bridge pointer and all
> > > code obtaining such a pointer. This series has just an overview of
> > > some of those conversions, because for now the main goal is to
> > > agree on the API.
> > > 
> > > Series layout:
> > > 
> > >  1. Add the new API and refcounting:
> > > 
> > > drm/bridge: add devm_drm_bridge_alloc()
> > > drm/bridge: add support for refcounting
> > > 
> > >  2. get/put the reference in basic operations in the bridge core:
> > > 
> > > drm/bridge: get/put the bridge reference in
> > > drm_bridge_add/remove() drm/bridge: get/put the bridge reference in
> > > drm_bridge_attach/detach()
> > > 
> > >  3. as an example of changes for bridge consumers, get a reference
> > > for the bridge returned by drm_bridge_chain_get_first_bridge(),
> > > have it put by all callers (all users will be covered later on
> > > separately):
> > > 
> > > drm/bridge: add a cleanup action for scope-based
> > > drm_bridge_put() invocation drm/bridge: get the bridge returned by
> > > drm_bridge_chain_get_first_bridge() drm/mxsfb: put the bridge
> > > returned by drm_bridge_chain_get_first_bridge() drm/atomic-helper:
> > > put the bridge returned by drm_bridge_chain_get_first_bridge()
> > > drm/probe-helper: put the bridge returned by
> > > drm_bridge_chain_get_first_bridge()
> > > 
> > >  4. convert a few bridge drivers (bridge providers) to the new API:
> > > 
> > > drm/bridge: ti-sn65dsi83: use dynamic lifetime management
> > > drm/bridge: samsung-dsim: use dynamic lifetime management
> > > 
> > > This work was formerly a part of my v6 DRM bridge hotplug
> > > series[0], now split as a standalone series with many improvements,
> > > hence the "v7" version number.  
> > 
> > Except for one patch where I had comments, I think the series is in
> > excellent shape. We're still missing a couple of things to close this
> > topic though:
> > 
> >   - Converting the other bridge iterators/accessors to take / put the
> > references
> 
> I sent a couple in this series as you had asked, to show how conversion
> looks like. But I have a large part of this conversion partially done
> already, and it is the largest part of the refcounting work in terms of
> touched files due to the large number of drivers using the iterators
> and accessors. Here are the functions to convert:
> 
>  A) drm_bridge_chain_get_first_bridge
>  B) drm_bridge_get_prev_bridge
>  C) drm_bridge_get_next_bridge
>  D) drm_for_each_bridge_in_chain
>  E) drm_bridge_connector_init
>  F) of_drm_find_bridge
> 
> A) is present in this series as an example but I don't think it should
> be applied until all bridge drivers are converted to
> drm_bridge_alloc(). Otherwise for not-yet-converted bridge drivers we'd
> have drm_bridge_get/put() operating on an uninitialized kref, and
> __drm_bridge_free() called on non-refcounted bridges, so I think we'd
> see fireworks.
> 
> In the previous iteration I used drm_bridge_is_refcounted() in
> drm_bridge_get/put() to allow a progressive migration, but if we want
> to convert everything in a single run we need to first convert all
> bridges to drm_bridge_alloc() and then convert all accessors.
> 
> The same reasoning applies to patches 3-4 which add get/put to
> drm_bridge_add/remove() and _attach/detach().

Agreed.

> B) to E) are ready in my work branch, about 20 patches in total.
> Indeed item E) is a special case but it is handled there too.
> 
> Item F) is the beast, because of the reverse call graph of
> of_drm_find_bridge() which includes drm_of_find_panel_or_bridge() and
> then *_of_get_bridge(), each having a few dozen callers, and leading
> to the panel_bridge topic. I have converted maybe half of the users of
> accessors in F), it's 35 patches but it's the easy half and I still need
> to tackle to hardest ones.

One thing to keep in mind is that, while it's not correct, if the bridge
has been allocated with devm_drm_bridge_alloc, it's not worse either. If
you're not getting a reference to your pointer, the point is buggy,
sure, but it's just as

Re: [PATCH 2/4] drm/panthor: Add driver IOCTL for setting BO labels

2025-03-19 Thread Boris Brezillon

On Wed, 19 Mar 2025 13:49:02 +
Adrián Larumbe  wrote:

> Hi Boris,
> 
> On 17.03.2025 08:50, Boris Brezillon wrote:
> > On Sun, 16 Mar 2025 21:51:33 +
> > Adrián Larumbe  wrote:
> >  
> > > Allow UM to label a BO for which it possesses a DRM handle.
> > >
> > > Signed-off-by: Adrián Larumbe 
> > > ---
> > >  drivers/gpu/drm/panthor/panthor_drv.c | 31 +++
> > >  include/uapi/drm/panthor_drm.h| 14 
> > >  2 files changed, 45 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/panthor/panthor_drv.c 
> > > b/drivers/gpu/drm/panthor/panthor_drv.c
> > > index 310bb44abe1a..f41b8946258f 100644
> > > --- a/drivers/gpu/drm/panthor/panthor_drv.c
> > > +++ b/drivers/gpu/drm/panthor/panthor_drv.c
> > > @@ -1330,6 +1330,35 @@ static int panthor_ioctl_vm_get_state(struct 
> > > drm_device *ddev, void *data,
> > >   return 0;
> > >  }
> > >
> > > +static int panthor_ioctl_label_bo(struct drm_device *ddev, void *data,
> > > +   struct drm_file *file)
> > > +{
> > > + struct drm_panthor_label_bo *args = data;
> > > + struct drm_gem_object *obj;
> > > + const char *label;
> > > + int ret = 0;
> > > +
> > > + obj = drm_gem_object_lookup(file, args->handle);
> > > + if (!obj)
> > > + return -ENOENT;
> > > +
> > > + if (args->len && args->label) {
> > > + label = strndup_user(u64_to_user_ptr(args->label), args->len + 
> > > 1);
> > > + if (IS_ERR(label)) {
> > > + ret = PTR_ERR(label);
> > > + goto err_label;
> > > + }
> > > + } else
> > > + label = NULL;
> > > +
> > > + panthor_gem_label_bo(obj, label);
> > > +
> > > +err_label:
> > > + drm_gem_object_put(obj);
> > > +
> > > + return ret;
> > > +}
> > > +
> > >  static int
> > >  panthor_open(struct drm_device *ddev, struct drm_file *file)
> > >  {
> > > @@ -1399,6 +1428,7 @@ static const struct drm_ioctl_desc 
> > > panthor_drm_driver_ioctls[] = {
> > >   PANTHOR_IOCTL(TILER_HEAP_CREATE, tiler_heap_create, DRM_RENDER_ALLOW),
> > >   PANTHOR_IOCTL(TILER_HEAP_DESTROY, tiler_heap_destroy, DRM_RENDER_ALLOW),
> > >   PANTHOR_IOCTL(GROUP_SUBMIT, group_submit, DRM_RENDER_ALLOW),
> > > + PANTHOR_IOCTL(LABEL_BO, label_bo, DRM_RENDER_ALLOW),
> > >  };
> > >
> > >  static int panthor_mmap(struct file *filp, struct vm_area_struct *vma)
> > > @@ -1508,6 +1538,7 @@ static void panthor_debugfs_init(struct drm_minor 
> > > *minor)
> > >   * - 1.2 - adds DEV_QUERY_GROUP_PRIORITIES_INFO query
> > >   *   - adds PANTHOR_GROUP_PRIORITY_REALTIME priority
> > >   * - 1.3 - adds DRM_PANTHOR_GROUP_STATE_INNOCENT flag
> > > + * - 1.4 - adds DRM_IOCTL_PANTHOR_LABEL_BO ioctl
> > >   */
> > >  static const struct drm_driver panthor_drm_driver = {
> > >   .driver_features = DRIVER_RENDER | DRIVER_GEM | DRIVER_SYNCOBJ |
> > > diff --git a/include/uapi/drm/panthor_drm.h 
> > > b/include/uapi/drm/panthor_drm.h
> > > index 97e2c4510e69..1a7ed567d36a 100644
> > > --- a/include/uapi/drm/panthor_drm.h
> > > +++ b/include/uapi/drm/panthor_drm.h
> > > @@ -127,6 +127,9 @@ enum drm_panthor_ioctl_id {
> > >
> > >   /** @DRM_PANTHOR_TILER_HEAP_DESTROY: Destroy a tiler heap. */
> > >   DRM_PANTHOR_TILER_HEAP_DESTROY,
> > > +
> > > + /** @DRM_PANTHOR_LABEL_BO: Label a BO. */
> > > + DRM_PANTHOR_LABEL_BO,  
> >
> > DRM_PANTHOR_BO_SET_LABEL to follow the DRM_PANTHOR__
> > naming scheme used in this file.
> >
> > I'd also be tempted to introduce a DRM_PANTHOR_BO_GET_LABEL ioctl while
> > we're at it.  
> 
> I thought of this too, but I was a bit reluctant because at present there are 
> no UM
> driver users who need this functionality.

I guess the labeling done in mesa could be made to use GEM labels if
the feature is supported. And honestly, I hate the idea of having an
half-baked implementation allowing the user to set a label with no way
to retrieve this label back. Can we at least change the name such that
we can later add a GET_LABEL ioctl?

> 
> > >  };
> > >
> > >  /**
> > > @@ -977,6 +980,15 @@ struct drm_panthor_tiler_heap_destroy {
> > >   __u32 pad;
> > >  };
> > >
> > > +/**
> > > + * struct drm_panthor_label_bo - Arguments passed to 
> > > DRM_IOCTL_PANTHOR_LABEL_BO
> > > + */
> > > +struct drm_panthor_label_bo {
> > > + __u32 handle;
> > > + __u32 len;
> > > + __u64 label;  
> >
> > Can you document these fields?
> >  
> > > +};
> > > +
> > >  /**
> > >   * DRM_IOCTL_PANTHOR() - Build a Panthor IOCTL number
> > >   * @__access: Access type. Must be R, W or RW.
> > > @@ -1019,6 +1031,8 @@ enum {
> > >   DRM_IOCTL_PANTHOR(WR, TILER_HEAP_CREATE, tiler_heap_create),
> > >   DRM_IOCTL_PANTHOR_TILER_HEAP_DESTROY =
> > >   DRM_IOCTL_PANTHOR(WR, TILER_HEAP_DESTROY, tiler_heap_destroy),
> > > + DRM_IOCTL_PANTHOR_LABEL_BO =
> > > + DRM_IOCTL_PANTHOR(WR, LABEL_BO, label_bo),
> > >  };
> > >
> > >  #if defined(__cplusplus)  
> 
> 
> Adrian Larumbe

Re: DRM CI

2025-03-19 Thread Helen Koike


Hi Maxime,

On 19/03/2025 11:11, Maxime Ripard wrote:

Hi,

At last Plumbers, we agreed with Dave that a good first step to ramp up
CI for DRM trees would be to enable build and kunit testing in the main
DRM tree.

I played around with it last week and wrote a good first iteration of
the gitlab-ci file.

https://gitlab.freedesktop.org/mripard/gitlab/-/blob/main/.gitlab-ci.yml?ref_type=heads


How about improving and using the current DRM-CI instead of creating a 
new one?


Regards,
Helen



It will compile all drm-misc defconfigs, for arm, arm64 and x86
architectures, and will run kunit for those as well. Now that the gitlab
migration is mostly over, I guess we could start using it after the
merge window if everyone agrees.

It's also easily shareable with drm-misc, if we ever want to use it
there.

I guess it's useful on its own, but I've started to look into making dim
create PR for drm automatically.

Gitlab support push options to create a PR automatically when pushing:
https://docs.gitlab.co.jp/ee/user/project/push_options.html#push-options-for-merge-requests

Unfortunately, it seems to work only for branches, not tags. I guess we
could put the PR description we put in the tag at the moment in the PR
description, but I'm not sure if it's a big deal or not.

Maxime

Re: [PATCH v1 2/3] drm/ci: uprev IGT

2025-03-19 Thread Helen Mae Koike Fornazier

Em sex., 14 de mar. de 2025 às 05:59, Vignesh Raman
 escreveu:
>
> Uprev IGT to the latest version and update expectation files.
>
> Signed-off-by: Vignesh Raman 

It feels that the xfails list is growing more instead of shrinking, well...

Acked-by: Helen Koike 

Thanks
Helen

> ---
>  drivers/gpu/drm/ci/gitlab-ci.yml  |   2 +-
>  .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt |   8 +-
>  .../gpu/drm/ci/xfails/amdgpu-stoney-skips.txt |   1 +
>  drivers/gpu/drm/ci/xfails/i915-amly-fails.txt |  23 +-
>  drivers/gpu/drm/ci/xfails/i915-amly-skips.txt |   1 +
>  drivers/gpu/drm/ci/xfails/i915-apl-fails.txt  |   8 +-
>  drivers/gpu/drm/ci/xfails/i915-apl-skips.txt  |   1 +
>  drivers/gpu/drm/ci/xfails/i915-cml-fails.txt  |  20 +-
>  drivers/gpu/drm/ci/xfails/i915-cml-skips.txt  |   2 +-
>  drivers/gpu/drm/ci/xfails/i915-glk-fails.txt  |  32 +-
>  drivers/gpu/drm/ci/xfails/i915-glk-skips.txt  |   1 +
>  drivers/gpu/drm/ci/xfails/i915-jsl-fails.txt  |  13 +-
>  drivers/gpu/drm/ci/xfails/i915-jsl-skips.txt  |   1 +
>  drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt  |   5 -
>  drivers/gpu/drm/ci/xfails/i915-kbl-skips.txt  |   1 +
>  drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt  |   9 +-
>  drivers/gpu/drm/ci/xfails/i915-tgl-skips.txt  |   1 +
>  drivers/gpu/drm/ci/xfails/i915-whl-fails.txt  |  22 +-
>  drivers/gpu/drm/ci/xfails/i915-whl-skips.txt  |   1 +
>  .../drm/ci/xfails/mediatek-mt8173-fails.txt   |  20 ++
>  .../drm/ci/xfails/mediatek-mt8173-flakes.txt  |   7 +
>  .../drm/ci/xfails/mediatek-mt8173-skips.txt   |   1 +
>  .../drm/ci/xfails/mediatek-mt8183-fails.txt   |  28 +-
>  .../drm/ci/xfails/mediatek-mt8183-flakes.txt  |  21 ++
>  .../drm/ci/xfails/mediatek-mt8183-skips.txt   |   1 +
>  .../gpu/drm/ci/xfails/meson-g12b-skips.txt|   1 +
>  .../gpu/drm/ci/xfails/msm-apq8016-fails.txt   |   4 -
>  .../gpu/drm/ci/xfails/msm-apq8016-skips.txt   |   1 +
>  .../gpu/drm/ci/xfails/msm-apq8096-skips.txt   |   1 +
>  .../msm-sc7180-trogdor-kingoftown-flakes.txt  |   7 +
>  .../msm-sc7180-trogdor-kingoftown-skips.txt   |   4 +
>  ...m-sc7180-trogdor-lazor-limozeen-flakes.txt |   7 +
>  ...sm-sc7180-trogdor-lazor-limozeen-skips.txt |   1 +
>  .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt   |   7 +
>  .../gpu/drm/ci/xfails/msm-sdm845-skips.txt| 313 ++
>  .../drm/ci/xfails/msm-sm8350-hdk-skips.txt|   1 +
>  .../gpu/drm/ci/xfails/panfrost-g12b-skips.txt |   1 +
>  .../drm/ci/xfails/panfrost-mt8183-skips.txt   |   1 +
>  .../drm/ci/xfails/panfrost-rk3288-skips.txt   |   1 +
>  .../drm/ci/xfails/panfrost-rk3399-skips.txt   |   1 +
>  .../drm/ci/xfails/rockchip-rk3288-fails.txt   |   1 -
>  .../drm/ci/xfails/rockchip-rk3288-skips.txt   |   1 +
>  .../drm/ci/xfails/rockchip-rk3399-fails.txt   |   2 +-
>  .../drm/ci/xfails/rockchip-rk3399-flakes.txt  |  30 +-
>  .../drm/ci/xfails/rockchip-rk3399-skips.txt   |   1 +
>  .../drm/ci/xfails/virtio_gpu-none-fails.txt   |   1 +
>  .../drm/ci/xfails/virtio_gpu-none-skips.txt   |   1 +
>  .../gpu/drm/ci/xfails/vkms-none-flakes.txt|  28 ++
>  drivers/gpu/drm/ci/xfails/vkms-none-skips.txt |   2 +
>  49 files changed, 554 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml 
> b/drivers/gpu/drm/ci/gitlab-ci.yml
> index 55b540c4cf92..65adcd97e06b 100644
> --- a/drivers/gpu/drm/ci/gitlab-ci.yml
> +++ b/drivers/gpu/drm/ci/gitlab-ci.yml
> @@ -5,7 +5,7 @@ variables:
>UPSTREAM_REPO: https://gitlab.freedesktop.org/drm/kernel.git
>TARGET_BRANCH: drm-next
>
> -  IGT_VERSION: 33adea9ebafd059ac88a5ccfec60536394f36c7c
> +  IGT_VERSION: 04bedb9238586b81d4d4ca62b02e584f6cfc77af
>
>DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/mesa/deqp-runner.git
>DEQP_RUNNER_GIT_TAG: v0.20.0
> diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt 
> b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt
> index 75374085f40f..f44dbce3151a 100644
> --- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt
> +++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt
> @@ -14,16 +14,10 @@ amdgpu/amd_plane@mpo-scale-nv12,Fail
>  amdgpu/amd_plane@mpo-scale-p010,Fail
>  amdgpu/amd_plane@mpo-scale-rgb,Crash
>  amdgpu/amd_plane@mpo-swizzle-toggle,Fail
> -amdgpu/amd_uvd_dec@amdgpu_uvd_decode,Crash
> +amdgpu/amd_uvd_dec@amdgpu_uvd_decode,Fail
>  kms_addfb_basic@bad-pitch-65536,Fail
>  kms_addfb_basic@bo-too-small,Fail
>  kms_addfb_basic@too-high,Fail
> -kms_async_flips@alternate-sync-async-flip,Fail
> -kms_async_flips@alternate-sync-async-flip-atomic,Fail
> -kms_async_flips@test-cursor,Fail
> -kms_async_flips@test-cursor-atomic,Fail
> -kms_async_flips@test-time-stamp,Fail
> -kms_async_flips@test-time-stamp-atomic,Fail
>  kms_atomic_transition@plane-all-modeset-transition-internal-panels,Fail
>  kms_atomic_transition@plane-all-transition,Fail
>  kms_atomic_transition@plane-all-transition-nonblocking,Fail
> diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt 
> b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-skips.txt
> index 3879c4812a

Re: [PATCH v4 0/3] drm/tidss: Add OLDI bridge support

2025-03-19 Thread Sverdlin, Alexander

Thank you for the patches, Aradhya!

On Sun, 2024-11-24 at 20:06 +0530, Aradhya Bhatia wrote:
> Regardless, I'd appreciate it if somebody can test it, and report back if they
> observe any issues.

I've tried to test the patchset with necessary pre-requisites and DT additions
with a single channel LVDS pannel and while I'm not successful yet, I've also 
noticed
the following warning:

tidss 3020.dss: vp0: Clock rate 24285714 differs over 5% from requested 
3700

even though later the clock seems to be correctly set up:

$ cat /sys/kernel/debug/clk/clk_summary 

 enable  prepare  protect   
 duty  hardwareconnection
   clock  countcountcountrate   
accuracy phase  cycleenable   consumer id
-
 clk:186:6   1   1025000   0
  0 5  Y   3020.dssfck  


   deviceless  no_connection_id 

 clk:186:4   0   000   0
  0 5  Y   deviceless  no_connection_id 

 clk:186:3   0   0017000   0
  0 5  Y   deviceless  no_connection_id 

clk:186:20   0017000   0
  0 5  Y  3020.dssvp2   
   

  deviceless  no_connection_id  
   
 clk:186:0   1   10259090909   0
  0 5  Y   oldi@0  serial   


   deviceless  no_connection_id 

clock-divider-oldi   1   10370129870
  0 5  Y  3020.dssvp1   
   

Looks like "clock-divider-oldi" doesn't propagate clk_set_rate() to the parent,
but the parent is being set later independently?

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

Re: [PATCH v2 2/3] rust: alloc: add Vec::resize method

2025-03-19 Thread Tamir Duberstein

On Wed, Mar 19, 2025 at 12:43 PM Miguel Ojeda
 wrote:
>
> On Wed, Mar 19, 2025 at 5:13 PM Tamir Duberstein  wrote:
> >
> > No, I meant avoiding the check. The existing code already explicitly
> > checks `new_len > self.len()` before evaluating `new_len -
> > self.len()`. This means the check occurs twice. `checked_sub` reduces
> > the number of checks by 1. Perhaps my wording could have been clearer
> > ("avoid *an* underflow check").
>
> Ah, you mean in the function you suggested, I see.
>
> I think it they all may compile down to the same thing, whether
> overflows checks are enabled or not, and whether the version in the
> patch or `checked_sub` is used or not. At least in a quick Compiler
> Explorer test it seems so, but I didn't check in an actual kernel
> build.
>
> The implicit check is gated behind the other one, so that one can be
> removed, even if values are unknown -- we always have optimizations
> enabled, even under "debug" builds (assuming "debug" means overflow
> checking enabled).

Yeah, this elision is what I was trying to allude to in the original
wording. I still think the suggested code is simpler, but gave my RB
either way.

Re: [PATCH RESEND 0/2] Refactoring the fbcon packed pixel drawing routines

2025-03-19 Thread Helge Deller


On 3/9/25 19:47, Zsolt Kajtar wrote:

This is the same patch as before just updated to latest fbdev
master and with better description. And hopefully sent intact this
time.

Zsolt Kajtar (2):
   Refactoring the fbcon packed pixel drawing routines
   Adding contact info for packed pixel drawing


This patch series has now been in fbdev for-next git tree for 10 days
without any major issues reported so far.

I think it's a good and necessary cleanup, although it's of
course quite big (but mostly copy&paste).

I'd like to get some feedback if there are any major
objections that this goes upstream during the next merge window?
(Thomas: I know you were not very enthusiastic about
the previous patch set. I think this one is better.)

Helge


  MAINTAINERS |  16 +
  drivers/video/fbdev/core/Kconfig|  10 +-
  drivers/video/fbdev/core/cfbcopyarea.c  | 428 +---
  drivers/video/fbdev/core/cfbfillrect.c  | 362 +
  drivers/video/fbdev/core/cfbimgblt.c| 357 +
  drivers/video/fbdev/core/cfbmem.h   |  43 ++
  drivers/video/fbdev/core/fb_copyarea.h  | 405 +++
  drivers/video/fbdev/core/fb_draw.h  | 274 ++---
  drivers/video/fbdev/core/fb_fillrect.h  | 280 ++
  drivers/video/fbdev/core/fb_imageblit.h | 495 
  drivers/video/fbdev/core/syscopyarea.c  | 369 +-
  drivers/video/fbdev/core/sysfillrect.c  | 324 +---
  drivers/video/fbdev/core/sysimgblt.c| 333 +---
  drivers/video/fbdev/core/sysmem.h   |  39 ++
  14 files changed, 1480 insertions(+), 2255 deletions(-)
  create mode 100644 drivers/video/fbdev/core/cfbmem.h
  create mode 100644 drivers/video/fbdev/core/fb_copyarea.h
  create mode 100644 drivers/video/fbdev/core/fb_fillrect.h
  create mode 100644 drivers/video/fbdev/core/fb_imageblit.h
  create mode 100644 drivers/video/fbdev/core/sysmem.h

Re: [RFC PATCH 0/3] gpu: nova-core: add basic timer subdevice implementation

2025-03-19 Thread Jason Gunthorpe

On Thu, Mar 13, 2025 at 03:32:14PM +0100, Simona Vetter wrote:

> So I think you can still achieve that building on top of revocable and a
> few more abstractions that are internally unsafe. Or are you thinking of
> different runtime checks?

I'm thinking on the access side of the revocable you don't have a
failure path. Instead you get the access or runtime violation if the
driver is buggy. This eliminates all the objectionable failure paths
and costs on the performance paths of the driver.

And perhaps also on the remove path you have runtime checking if
"driver lifetime bound" objects have all been cleaned up.

The point is to try to behave more like the standard fence pattern and
get some level of checking that can make r4l comfortable without
inventing new kernel lifecycle models.

> Yeah maybe we're not that far really. But I'm still not clear how to do
> an entirely revoke-less world.

Not entirely, you end up revoking big things. Like RDMA revokes the
driver ops callbacks using SRCU. It doesn't revoke individual
resources or DMA maps.

I have the same feeling about this micro-revoke direction, I don't
know how to implement this. The DMA API is very challenging,
especially the performance use of DMA API.

Jason

Re: [PATCH v1 1/3] drm/ci: uprev mesa

2025-03-19 Thread Helen Mae Koike Fornazier

Em qua., 19 de mar. de 2025 às 10:24, Vignesh Raman
 escreveu:
>
> Hi Helen,
>
> On 19/03/25 00:22, Helen Mae Koike Fornazier wrote:
> > Em sex., 14 de mar. de 2025 às 05:59, Vignesh Raman
> >  escreveu:
> >>
> >> LAVA was recently patched [1] with a fix on how parameters are parsed in
> >> `lava-test-case`, so we don't need to repeat quotes to send the
> >> arguments properly to it. Uprev mesa to fix this issue.
> >>
> >> [1] https://gitlab.com/lava/lava/-/commit/18c9cf79
> >>
> >> Signed-off-by: Vignesh Raman 
> >> ---
> >>   drivers/gpu/drm/ci/build.sh   | 16 
> >>   drivers/gpu/drm/ci/build.yml  |  8 
> >>   drivers/gpu/drm/ci/container.yml  | 24 +++
> >>   drivers/gpu/drm/ci/gitlab-ci.yml  | 32 ++-
> >>   drivers/gpu/drm/ci/image-tags.yml |  4 +++-
> >>   drivers/gpu/drm/ci/lava-submit.sh |  3 ++-
> >>   drivers/gpu/drm/ci/test.yml   |  2 +-
> >>   7 files changed, 77 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
> >> index 19fe01257ab9..284873e94d8d 100644
> >> --- a/drivers/gpu/drm/ci/build.sh
> >> +++ b/drivers/gpu/drm/ci/build.sh
> >> @@ -98,14 +98,14 @@ done
> >>
> >>   make ${KERNEL_IMAGE_NAME}
> >>
> >> -mkdir -p /lava-files/
> >> +mkdir -p /kernel/
> >
> > the folder is not lava specific, correct?
>
> It is not lava specific. Only the directory name where the kernel image
> is copied is changed and the kernel image is uploaded to S3 for lava.
>
> This is based on,
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/5b65bbf72ce7024c5df2100ce4b12d59e8f3dd26

thanks for clarifying.

>
> >
> >>   for image in ${KERNEL_IMAGE_NAME}; do
> >> -cp arch/${KERNEL_ARCH}/boot/${image} /lava-files/.
> >> +cp arch/${KERNEL_ARCH}/boot/${image} /kernel/.
> >>   done
> >>
> >>   if [[ -n ${DEVICE_TREES} ]]; then
> >>   make dtbs
> >> -cp ${DEVICE_TREES} /lava-files/.
> >> +cp ${DEVICE_TREES} /kernel/.
> >>   fi
> >>
> >>   make modules
> >> @@ -121,11 +121,11 @@ if [[ ${DEBIAN_ARCH} = "arm64" ]]; then
> >>   -d arch/arm64/boot/Image.lzma \
> >>   -C lzma\
> >>   -b arch/arm64/boot/dts/qcom/sdm845-cheza-r3.dtb \
> >> -/lava-files/cheza-kernel
> >> +/kernel/cheza-kernel
> >>   KERNEL_IMAGE_NAME+=" cheza-kernel"
> >>
> >>   # Make a gzipped copy of the Image for db410c.
> >> -gzip -k /lava-files/Image
> >> +gzip -k /kernel/Image
> >>   KERNEL_IMAGE_NAME+=" Image.gz"
> >>   fi
> >>
> >> @@ -139,7 +139,7 @@ cp -rfv drivers/gpu/drm/ci/* install/.
> >>   . .gitlab-ci/container/container_post_build.sh
> >>
> >>   if [[ "$UPLOAD_TO_MINIO" = "1" ]]; then
> >> -xz -7 -c -T${FDO_CI_CONCURRENT:-4} vmlinux > /lava-files/vmlinux.xz
> >> +xz -7 -c -T${FDO_CI_CONCURRENT:-4} vmlinux > /kernel/vmlinux.xz
> >>   FILES_TO_UPLOAD="$KERNEL_IMAGE_NAME vmlinux.xz"
> >>
> >>   if [[ -n $DEVICE_TREES ]]; then
> >> @@ -148,7 +148,7 @@ if [[ "$UPLOAD_TO_MINIO" = "1" ]]; then
> >>
> >>   ls -l "${S3_JWT_FILE}"
> >>   for f in $FILES_TO_UPLOAD; do
> >> -ci-fairy s3cp --token-file "${S3_JWT_FILE}" /lava-files/$f \
> >> +ci-fairy s3cp --token-file "${S3_JWT_FILE}" /kernel/$f \
> >>   https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/$f
> >>   done
> >>
> >> @@ -165,7 +165,7 @@ ln -s common artifacts/install/ci-common
> >>   cp .config artifacts/${CI_JOB_NAME}_config
> >>
> >>   for image in ${KERNEL_IMAGE_NAME}; do
> >> -cp /lava-files/$image artifacts/install/.
> >> +cp /kernel/$image artifacts/install/.
> >>   done
> >>
> >>   tar -C artifacts -cf artifacts/install.tar install
> >> diff --git a/drivers/gpu/drm/ci/build.yml b/drivers/gpu/drm/ci/build.yml
> >> index 6c0dc10b547c..8eb56ebcf4aa 100644
> >> --- a/drivers/gpu/drm/ci/build.yml
> >> +++ b/drivers/gpu/drm/ci/build.yml
> >> @@ -143,6 +143,10 @@ debian-arm64-release:
> >> rules:
> >>   - when: never
> >>
> >> +debian-arm64-ubsan:
> >> +  rules:
> >> +- when: never
> >> +
> >>   debian-build-testing:
> >> rules:
> >>   - when: never
> >> @@ -183,6 +187,10 @@ debian-testing-msan:
> >> rules:
> >>   - when: never
> >>
> >> +debian-testing-ubsan:
> >> +  rules:
> >> +- when: never
> >> +
> >>   debian-vulkan:
> >> rules:
> >>   - when: never
> >> diff --git a/drivers/gpu/drm/ci/container.yml 
> >> b/drivers/gpu/drm/ci/container.yml
> >> index 07dc13ff865d..56c95c2f91ae 100644
> >> --- a/drivers/gpu/drm/ci/container.yml
> >> +++ b/drivers/gpu/drm/ci/container.yml
> >> @@ -24,6 +24,18 @@ alpine/x86_64_build:
> >> rules:
> >>   - when: never
> >>
> >> +debian/arm32_test-base:
> >> +  rules:
> >> +- when: never
> >> +
> >> +debian/arm32_test-gl:
> >> +  rules:
> >> +- when: never
> >> +
> >> +debian/arm32_test-vk:
> >> +  rules:
> >> +- when: never
> >> +
> >>   debian/arm64_test-gl:
> >> rules:
> >>   - when: never
> >> @@ -32,6 +44,

Re: [PATCH rc] gpu: host1x: Do not assume that a NULL domain means no DMA IOMMU

2025-03-19 Thread Thierry Reding

On Tue, Feb 04, 2025 at 03:18:19PM -0400, Jason Gunthorpe wrote:
> Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain
> could have been left as NULL. The NULL domain is specially recognized by
> host1x_iommu_attach() as meaning it is not the DMA domain and
> should be replaced with the special shared domain.
> 
> This happened prior to the below commit because tegra-smmu was using the
> NULL domain to mean IDENTITY.
> 
> Now that the domain is properly labled the test in DRM doesn't see NULL.
> Check for IDENTITY as well to enable the special domains.
> 
> This is the same issue and basic fix as seen in
> commit fae6e669cdc5 ("drm/tegra: Do not assume that a NULL domain means no
> DMA IOMMU").
> 
> Fixes: c8cc2655cc6c ("iommu/tegra-smmu: Implement an IDENTITY domain")
> Reported-by: Diogo Ivo 
> Closes: 
> https://lore.kernel.org/all/c6a6f114-3acd-4d56-a13b-b88978e92...@tecnico.ulisboa.pt/
> Tested-by: Diogo Ivo 
> Signed-off-by: Jason Gunthorpe 
> ---
>  drivers/gpu/host1x/dev.c | 6 ++
>  1 file changed, 6 insertions(+)

Applied to drm-misc-fixes now. Sorry for the delay.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH rc] gpu: host1x: Do not assume that a NULL domain means no DMA IOMMU

2025-03-19 Thread Thierry Reding

On Mon, Mar 10, 2025 at 12:34:35PM +, Diogo Ivo wrote:
> 
> Hello again,
> 
> On 2/4/25 7:18 PM, Jason Gunthorpe wrote:
> > Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain
> > could have been left as NULL. The NULL domain is specially recognized by
> > host1x_iommu_attach() as meaning it is not the DMA domain and
> > should be replaced with the special shared domain.
> > 
> > This happened prior to the below commit because tegra-smmu was using the
> > NULL domain to mean IDENTITY.
> > 
> > Now that the domain is properly labled the test in DRM doesn't see NULL.
> > Check for IDENTITY as well to enable the special domains.
> > 
> > This is the same issue and basic fix as seen in
> > commit fae6e669cdc5 ("drm/tegra: Do not assume that a NULL domain means no
> > DMA IOMMU").
> > 
> > Fixes: c8cc2655cc6c ("iommu/tegra-smmu: Implement an IDENTITY domain")
> > Reported-by: Diogo Ivo 
> > Closes: 
> > https://lore.kernel.org/all/c6a6f114-3acd-4d56-a13b-b88978e92...@tecnico.ulisboa.pt/
> > Tested-by: Diogo Ivo 
> > Signed-off-by: Jason Gunthorpe 
> 
> Any news on this patch or any other solutions for this regression? It's
> not great if this falls through the cracks, especially when there is a
> solution for the problem.

Looks like I had marked this as applied by mistake. Thanks for the
reminder, it's applied now.

Thierry


signature.asc
Description: PGP signature

Re: [PATCH 4/4] drm/panthor: Display heap chunk entries in DebugFS GEMS file

2025-03-19 Thread Adrián Larumbe

On 17.03.2025 09:31, Boris Brezillon wrote:
> On Sun, 16 Mar 2025 21:51:35 +
> Adrián Larumbe  wrote:
>
> > Expand the driver's DebugFS GEMS file to display entries for the heap
> > chunks' GEM objects, both those allocated at heap creation time through an
> > ioctl(), or in response to a tiler OOM event.
> >
> > Signed-off-by: Adrián Larumbe 
> > ---
> >  drivers/gpu/drm/panthor/panthor_heap.c | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/panthor/panthor_heap.c 
> > b/drivers/gpu/drm/panthor/panthor_heap.c
> > index db0285ce5812..520d1fcf5c36 100644
> > --- a/drivers/gpu/drm/panthor/panthor_heap.c
> > +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> > @@ -139,6 +139,10 @@ static int panthor_alloc_heap_chunk(struct 
> > panthor_device *ptdev,
> > struct panthor_heap_chunk *chunk;
> > struct panthor_heap_chunk_header *hdr;
> > int ret;
> > +#ifdef CONFIG_DEBUG_FS
> > +   struct panthor_gem_object *obj;
> > +   const char *label;
> > +#endif
> >
> > chunk = kmalloc(sizeof(*chunk), GFP_KERNEL);
> > if (!chunk)
> > @@ -180,6 +184,17 @@ static int panthor_alloc_heap_chunk(struct 
> > panthor_device *ptdev,
> > heap->chunk_count++;
> > mutex_unlock(&heap->lock);
> >
> > +#ifdef CONFIG_DEBUG_FS
> > +   obj = to_panthor_bo(chunk->bo->obj);
> > +
> > +   mutex_lock(&ptdev->gems_lock);
> > +   list_add_tail(&obj->gems_node, &ptdev->gems);
> > +   mutex_unlock(&ptdev->gems_lock);
> > +
> > +   label = kstrdup_const("\"Tiler heap chunk\"", GFP_KERNEL);
>
> Do we really need the extra quotes around 'Tiler heap chunk'?

We want them quoted like this so that the BO name can be told apart from the
the extra tagging information (like modifiers) and any suffix sent down from gl

> > +   panthor_gem_label_bo(chunk->bo->obj, label);
> > +#endif
>
> Let's define a helper to assign a label to a kernel BO instead of
> open-coding it here. BTW, I suspect we'll want to assign labels to
> other kernel BOs too (FW buffers).
>
> > +
> > return 0;
> >
> >  err_destroy_bo:


Adrian Larumbe

[PATCH v2 09/34] drm/msm: Collapse vma allocation and initialization

From: Rob Clark 

Now that we've dropped vram carveout support, we can collapse vma
allocation and initialization.  This better matches how things work
with drm_gpuvm.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem.c | 30 +++---
 drivers/gpu/drm/msm/msm_gem.h |  4 ++--
 drivers/gpu/drm/msm/msm_gem_vma.c | 36 +--
 3 files changed, 20 insertions(+), 50 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 621fb4e17a2e..29247911f048 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -337,23 +337,6 @@ uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj)
return offset;
 }
 
-static struct msm_gem_vma *add_vma(struct drm_gem_object *obj,
-   struct msm_gem_vm *vm)
-{
-   struct msm_gem_object *msm_obj = to_msm_bo(obj);
-   struct msm_gem_vma *vma;
-
-   msm_gem_assert_locked(obj);
-
-   vma = msm_gem_vma_new(vm);
-   if (!vma)
-   return ERR_PTR(-ENOMEM);
-
-   list_add_tail(&vma->list, &msm_obj->vmas);
-
-   return vma;
-}
-
 static struct msm_gem_vma *lookup_vma(struct drm_gem_object *obj,
struct msm_gem_vm *vm)
 {
@@ -420,6 +403,7 @@ static struct msm_gem_vma *get_vma_locked(struct 
drm_gem_object *obj,
struct msm_gem_vm *vm,
u64 range_start, u64 range_end)
 {
+   struct msm_gem_object *msm_obj = to_msm_bo(obj);
struct msm_gem_vma *vma;
 
msm_gem_assert_locked(obj);
@@ -427,18 +411,10 @@ static struct msm_gem_vma *get_vma_locked(struct 
drm_gem_object *obj,
vma = lookup_vma(obj, vm);
 
if (!vma) {
-   int ret;
-
-   vma = add_vma(obj, vm);
+   vma = msm_gem_vma_new(vm, obj, range_start, range_end);
if (IS_ERR(vma))
return vma;
-
-   ret = msm_gem_vma_init(vma, obj->size,
-   range_start, range_end);
-   if (ret) {
-   del_vma(vma);
-   return ERR_PTR(ret);
-   }
+   list_add_tail(&vma->list, &msm_obj->vmas);
} else {
GEM_WARN_ON(vma->iova < range_start);
GEM_WARN_ON((vma->iova + obj->size) > range_end);
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index c16b11182831..9bd78642671c 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -66,8 +66,8 @@ struct msm_gem_vma {
bool mapped;
 };
 
-struct msm_gem_vma *msm_gem_vma_new(struct msm_gem_vm *vm);
-int msm_gem_vma_init(struct msm_gem_vma *vma, int size,
+struct msm_gem_vma *
+msm_gem_vma_new(struct msm_gem_vm *vm, struct drm_gem_object *obj,
u64 range_start, u64 range_end);
 void msm_gem_vma_purge(struct msm_gem_vma *vma);
 int msm_gem_vma_map(struct msm_gem_vma *vma, int prot, struct sg_table *sgt, 
int size);
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c 
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 9419692f0cc8..6d18364f321c 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -106,47 +106,41 @@ void msm_gem_vma_close(struct msm_gem_vma *vma)
msm_gem_vm_put(vm);
 }
 
-struct msm_gem_vma *msm_gem_vma_new(struct msm_gem_vm *vm)
+/* Create a new vma and allocate an iova for it */
+struct msm_gem_vma *
+msm_gem_vma_new(struct msm_gem_vm *vm, struct drm_gem_object *obj,
+   u64 range_start, u64 range_end)
 {
struct msm_gem_vma *vma;
+   int ret;
 
vma = kzalloc(sizeof(*vma), GFP_KERNEL);
if (!vma)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
vma->vm = vm;
 
-   return vma;
-}
-
-/* Initialize a new vma and allocate an iova for it */
-int msm_gem_vma_init(struct msm_gem_vma *vma, int size,
-   u64 range_start, u64 range_end)
-{
-   struct msm_gem_vm *vm = vma->vm;
-   int ret;
-
-   if (GEM_WARN_ON(!vm))
-   return -EINVAL;
-
-   if (GEM_WARN_ON(vma->iova))
-   return -EBUSY;
-
spin_lock(&vm->lock);
ret = drm_mm_insert_node_in_range(&vm->mm, &vma->node,
- size, PAGE_SIZE, 0,
+ obj->size, PAGE_SIZE, 0,
  range_start, range_end, 0);
spin_unlock(&vm->lock);
 
if (ret)
-   return ret;
+   goto err_free_vma;
 
vma->iova = vma->node.start;
vma->mapped = false;
 
+   INIT_LIST_HEAD(&vma->list);
+
kref_get(&vm->kref);
 
-   return 0;
+   return vma;
+
+err_free_vma:
+   kfree(vma);
+   return ERR_PTR(ret);
 }
 
 struct msm_gem_vm *
-- 
2.48.1

[PATCH v2 06/34] drm/msm: Improve msm_context comments

From: Rob Clark 

Just some tidying up.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gpu.h | 44 +++
 1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index 957d6fb3469d..c699ce0c557b 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -348,25 +348,39 @@ struct msm_gpu_perfcntr {
 
 /**
  * struct msm_context - per-drm_file context
- *
- * @queuelock:synchronizes access to submitqueues list
- * @submitqueues: list of &msm_gpu_submitqueue created by userspace
- * @queueid:  counter incremented each time a submitqueue is created,
- *used to assign &msm_gpu_submitqueue.id
- * @aspace:   the per-process GPU address-space
- * @ref:  reference count
- * @seqno:unique per process seqno
  */
 struct msm_context {
+   /** @queuelock: synchronizes access to submitqueues list */
rwlock_t queuelock;
+
+   /** @submitqueues: list of &msm_gpu_submitqueue created by userspace */
struct list_head submitqueues;
+
+   /**
+* @queueid:
+*
+* Counter incremented each time a submitqueue is created, used to
+* assign &msm_gpu_submitqueue.id
+*/
int queueid;
+
+   /** @aspace: the per-process GPU address-space */
struct msm_gem_address_space *aspace;
+
+   /** @kref: the reference count */
struct kref ref;
+
+   /**
+* @seqno:
+*
+* A unique per-process sequence number.  Used to detect context
+* switches, without relying on keeping a, potentially dangling,
+* pointer to the previous context.
+*/
int seqno;
 
/**
-* sysprof:
+* @sysprof:
 *
 * The value of MSM_PARAM_SYSPROF set by userspace.  This is
 * intended to be used by system profiling tools like Mesa's
@@ -384,21 +398,21 @@ struct msm_context {
int sysprof;
 
/**
-* comm: Overridden task comm, see MSM_PARAM_COMM
+* @comm: Overridden task comm, see MSM_PARAM_COMM
 *
 * Accessed under msm_gpu::lock
 */
char *comm;
 
/**
-* cmdline: Overridden task cmdline, see MSM_PARAM_CMDLINE
+* @cmdline: Overridden task cmdline, see MSM_PARAM_CMDLINE
 *
 * Accessed under msm_gpu::lock
 */
char *cmdline;
 
/**
-* elapsed:
+* @elapsed:
 *
 * The total (cumulative) elapsed time GPU was busy with rendering
 * from this context in ns.
@@ -406,7 +420,7 @@ struct msm_context {
uint64_t elapsed_ns;
 
/**
-* cycles:
+* @cycles:
 *
 * The total (cumulative) GPU cycles elapsed attributed to this
 * context.
@@ -414,7 +428,7 @@ struct msm_context {
uint64_t cycles;
 
/**
-* entities:
+* @entities:
 *
 * Table of per-priority-level sched entities used by submitqueues
 * associated with this &drm_file.  Because some userspace apps
@@ -427,7 +441,7 @@ struct msm_context {
struct drm_sched_entity *entities[NR_SCHED_PRIORITIES * 
MSM_GPU_MAX_RINGS];
 
/**
-* ctx_mem:
+* @ctx_mem:
 *
 * Total amount of memory of GEM buffers with handles attached for
 * this context.
-- 
2.48.1

[PATCH v2 07/34] drm/msm: Rename msm_gem_address_space -> msm_gem_vm

From: Rob Clark 

Re-aligning naming to better match drm_gpuvm terminology will make
things less confusing at the end of the drm_gpuvm conversion.

This is just rename churn, no functional change.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 18 ++--
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  4 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  4 +-
 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c |  4 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 ++---
 drivers/gpu/drm/msm/adreno/a5xx_power.c   |  2 +-
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 10 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 26 +++---
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 45 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c   |  6 +-
 drivers/gpu/drm/msm/adreno/a6xx_preempt.c | 10 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   | 47 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   | 18 ++--
 .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   | 14 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c   | 18 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h   |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   | 18 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 14 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  4 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |  6 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c  | 24 ++---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c| 12 +--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c |  4 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  | 18 ++--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c| 12 +--
 drivers/gpu/drm/msm/dsi/dsi_host.c| 14 +--
 drivers/gpu/drm/msm/msm_drv.c |  8 +-
 drivers/gpu/drm/msm/msm_drv.h | 10 +-
 drivers/gpu/drm/msm/msm_fb.c  | 10 +-
 drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
 drivers/gpu/drm/msm/msm_gem.c | 74 +++
 drivers/gpu/drm/msm/msm_gem.h | 34 +++
 drivers/gpu/drm/msm/msm_gem_submit.c  |  6 +-
 drivers/gpu/drm/msm/msm_gem_vma.c | 93 +--
 drivers/gpu/drm/msm/msm_gpu.c | 48 +-
 drivers/gpu/drm/msm/msm_gpu.h | 16 ++--
 drivers/gpu/drm/msm/msm_kms.c | 16 ++--
 drivers/gpu/drm/msm/msm_kms.h |  2 +-
 drivers/gpu/drm/msm/msm_ringbuffer.c  |  4 +-
 drivers/gpu/drm/msm/msm_submitqueue.c |  2 +-
 41 files changed, 349 insertions(+), 354 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 379a3d346c30..5eb063ed0b46 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -113,7 +113,7 @@ static int a2xx_hw_init(struct msm_gpu *gpu)
uint32_t *ptr, len;
int i, ret;
 
-   a2xx_gpummu_params(gpu->aspace->mmu, &pt_base, &tran_error);
+   a2xx_gpummu_params(gpu->vm->mmu, &pt_base, &tran_error);
 
DBG("%s", gpu->name);
 
@@ -466,19 +466,19 @@ static struct msm_gpu_state *a2xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
-static struct msm_gem_address_space *
-a2xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev)
+static struct msm_gem_vm *
+a2xx_create_vm(struct msm_gpu *gpu, struct platform_device *pdev)
 {
struct msm_mmu *mmu = a2xx_gpummu_new(&pdev->dev, gpu);
-   struct msm_gem_address_space *aspace;
+   struct msm_gem_vm *vm;
 
-   aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
+   vm = msm_gem_vm_create(mmu, "gpu", SZ_16M,
0xfff * SZ_64K);
 
-   if (IS_ERR(aspace) && !IS_ERR(mmu))
+   if (IS_ERR(vm) && !IS_ERR(mmu))
mmu->funcs->destroy(mmu);
 
-   return aspace;
+   return vm;
 }
 
 static u32 a2xx_get_rptr(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
@@ -504,7 +504,7 @@ static const struct adreno_gpu_funcs funcs = {
 #endif
.gpu_state_get = a2xx_gpu_state_get,
.gpu_state_put = adreno_gpu_state_put,
-   .create_address_space = a2xx_create_address_space,
+   .create_vm = a2xx_create_vm,
.get_rptr = a2xx_get_rptr,
},
 };
@@ -551,7 +551,7 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
else
adreno_gpu->registers = a220_registers;
 
-   if (!gpu->aspace) {
+   if (!gpu->vm) {
dev_err(dev->dev, "No memory protection without MMU\n");
if (!allow_vram_carveout) {
ret = -ENXIO;
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index b6df115bb567..434e6ededf83 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -526,7 +526,7 @@ static const struct adreno_gpu_funcs funcs =

[PATCH v2 08/34] drm/msm: Remove vram carveout support

From: Rob Clark 

It is standing in the way of drm_gpuvm / VM_BIND support.  Not to
mention frequently broken and rarely tested.  And I think only needed
for a 10yr old not quite upstream SoC (msm8974).

Maybe we can add support back in later, but I'm doubtful.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a2xx_gpu.c  |   6 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |  13 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c  |  13 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c |   4 -
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|   1 -
 drivers/gpu/drm/msm/msm_drv.c  | 117 +-
 drivers/gpu/drm/msm/msm_drv.h  |  11 --
 drivers/gpu/drm/msm/msm_gem.c  | 131 ++---
 drivers/gpu/drm/msm/msm_gem.h  |   5 -
 drivers/gpu/drm/msm/msm_gem_submit.c   |   5 -
 10 files changed, 19 insertions(+), 287 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 5eb063ed0b46..db1aa281ce47 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -553,10 +553,8 @@ struct msm_gpu *a2xx_gpu_init(struct drm_device *dev)
 
if (!gpu->vm) {
dev_err(dev->dev, "No memory protection without MMU\n");
-   if (!allow_vram_carveout) {
-   ret = -ENXIO;
-   goto fail;
-   }
+   ret = -ENXIO;
+   goto fail;
}
 
return gpu;
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 434e6ededf83..49ba1ce77144 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -582,18 +582,9 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
}
 
if (!gpu->vm) {
-   /* TODO we think it is possible to configure the GPU to
-* restrict access to VRAM carveout.  But the required
-* registers are unknown.  For now just bail out and
-* limp along with just modesetting.  If it turns out
-* to not be possible to restrict access, then we must
-* implement a cmdstream validator.
-*/
DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
-   if (!allow_vram_carveout) {
-   ret = -ENXIO;
-   goto fail;
-   }
+   ret = -ENXIO;
+   goto fail;
}
 
icc_path = devm_of_icc_get(&pdev->dev, "gfx-mem");
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 2c75debcfd84..4faf8570aec7 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -696,18 +696,9 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
adreno_gpu->uche_trap_base = 0xull;
 
if (!gpu->vm) {
-   /* TODO we think it is possible to configure the GPU to
-* restrict access to VRAM carveout.  But the required
-* registers are unknown.  For now just bail out and
-* limp along with just modesetting.  If it turns out
-* to not be possible to restrict access, then we must
-* implement a cmdstream validator.
-*/
DRM_DEV_ERROR(dev->dev, "No memory protection without IOMMU\n");
-   if (!allow_vram_carveout) {
-   ret = -ENXIO;
-   goto fail;
-   }
+   ret = -ENXIO;
+   goto fail;
}
 
icc_path = devm_of_icc_get(&pdev->dev, "gfx-mem");
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index f4552b8c6767..6b0390c38bff 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -16,10 +16,6 @@ bool snapshot_debugbus = false;
 MODULE_PARM_DESC(snapshot_debugbus, "Include debugbus sections in GPU 
devcoredump (if not fused off)");
 module_param_named(snapshot_debugbus, snapshot_debugbus, bool, 0600);
 
-bool allow_vram_carveout = false;
-MODULE_PARM_DESC(allow_vram_carveout, "Allow using VRAM Carveout, in place of 
IOMMU");
-module_param_named(allow_vram_carveout, allow_vram_carveout, bool, 0600);
-
 int enable_preemption = -1;
 MODULE_PARM_DESC(enable_preemption, "Enable preemption (A7xx only) (1=on , 
0=disable, -1=auto (default))");
 module_param(enable_preemption, int, 0600);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index eaebcb108b5e..7dbe09817edc 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -18,7 +18,6 @@
 #include "adreno_pm4.xml.h"
 
 extern bool snapshot_debugbus;
-extern bool allow_vram_carveout;
 
 enum {
ADRENO

[PATCH v2 10/34] drm/msm: Collapse vma close and delete

From: Rob Clark 

This fits better drm_gpuvm/drm_gpuva.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_gem.c | 16 +++-
 drivers/gpu/drm/msm/msm_gem_vma.c |  2 ++
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 29247911f048..4c10eca404e0 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -353,15 +353,6 @@ static struct msm_gem_vma *lookup_vma(struct 
drm_gem_object *obj,
return NULL;
 }
 
-static void del_vma(struct msm_gem_vma *vma)
-{
-   if (!vma)
-   return;
-
-   list_del(&vma->list);
-   kfree(vma);
-}
-
 /*
  * If close is true, this also closes the VMA (releasing the allocated
  * iova range) in addition to removing the iommu mapping.  In the eviction
@@ -372,11 +363,11 @@ static void
 put_iova_spaces(struct drm_gem_object *obj, bool close)
 {
struct msm_gem_object *msm_obj = to_msm_bo(obj);
-   struct msm_gem_vma *vma;
+   struct msm_gem_vma *vma, *tmp;
 
msm_gem_assert_locked(obj);
 
-   list_for_each_entry(vma, &msm_obj->vmas, list) {
+   list_for_each_entry_safe(vma, tmp, &msm_obj->vmas, list) {
if (vma->vm) {
msm_gem_vma_purge(vma);
if (close)
@@ -395,7 +386,7 @@ put_iova_vmas(struct drm_gem_object *obj)
msm_gem_assert_locked(obj);
 
list_for_each_entry_safe(vma, tmp, &msm_obj->vmas, list) {
-   del_vma(vma);
+   msm_gem_vma_close(vma);
}
 }
 
@@ -564,7 +555,6 @@ static int clear_iova(struct drm_gem_object *obj,
 
msm_gem_vma_purge(vma);
msm_gem_vma_close(vma);
-   del_vma(vma);
 
return 0;
 }
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c 
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 6d18364f321c..ca29e81d79d2 100644
--- a/drivers/gpu/drm/msm/msm_gem_vma.c
+++ b/drivers/gpu/drm/msm/msm_gem_vma.c
@@ -102,8 +102,10 @@ void msm_gem_vma_close(struct msm_gem_vma *vma)
spin_unlock(&vm->lock);
 
vma->iova = 0;
+   list_del(&vma->list);
 
msm_gem_vm_put(vm);
+   kfree(vma);
 }
 
 /* Create a new vma and allocate an iova for it */
-- 
2.48.1

[PATCH v2 12/34] drm/msm: Use drm_gpuvm types more

From: Rob Clark 

Most of the driver code doesn't need to reach in to msm specific fields,
so just use the drm_gpuvm/drm_gpuva types directly.  This should
hopefully improve commonality with other drivers and make the code
easier to understand.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a2xx_gpu.c |  6 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  6 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  6 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 14 ++--
 drivers/gpu/drm/msm/adreno/a6xx_preempt.c |  2 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   | 21 +++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |  4 +-
 .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  4 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c   |  6 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h   |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  6 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  2 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c  | 11 +--
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  | 11 +--
 drivers/gpu/drm/msm/dsi/dsi_host.c|  6 +-
 drivers/gpu/drm/msm/msm_drv.h | 19 ++---
 drivers/gpu/drm/msm/msm_fb.c  | 14 ++--
 drivers/gpu/drm/msm/msm_gem.c | 82 +--
 drivers/gpu/drm/msm/msm_gem.h | 53 ++--
 drivers/gpu/drm/msm/msm_gem_submit.c  |  4 +-
 drivers/gpu/drm/msm/msm_gem_vma.c | 72 +++-
 drivers/gpu/drm/msm/msm_gpu.c | 21 +++--
 drivers/gpu/drm/msm/msm_gpu.h | 10 +--
 drivers/gpu/drm/msm/msm_kms.c |  6 +-
 drivers/gpu/drm/msm/msm_kms.h |  2 +-
 drivers/gpu/drm/msm/msm_submitqueue.c |  2 +-
 27 files changed, 192 insertions(+), 202 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
index 94c49ed057cd..c4c723a0bf1a 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c
@@ -113,7 +113,7 @@ static int a2xx_hw_init(struct msm_gpu *gpu)
uint32_t *ptr, len;
int i, ret;
 
-   a2xx_gpummu_params(gpu->vm->mmu, &pt_base, &tran_error);
+   a2xx_gpummu_params(to_msm_vm(gpu->vm)->mmu, &pt_base, &tran_error);
 
DBG("%s", gpu->name);
 
@@ -466,11 +466,11 @@ static struct msm_gpu_state *a2xx_gpu_state_get(struct 
msm_gpu *gpu)
return state;
 }
 
-static struct msm_gem_vm *
+static struct drm_gpuvm *
 a2xx_create_vm(struct msm_gpu *gpu, struct platform_device *pdev)
 {
struct msm_mmu *mmu = a2xx_gpummu_new(&pdev->dev, gpu);
-   struct msm_gem_vm *vm;
+   struct drm_gpuvm *vm;
 
vm = msm_gem_vm_create(gpu->dev, mmu, "gpu", SZ_16M, 0xfff * SZ_64K, 
true);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index cce95ad3cfb8..9dd7dea84a4a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -1786,8 +1786,10 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
return ERR_PTR(ret);
}
 
-   if (gpu->vm)
-   msm_mmu_set_fault_handler(gpu->vm->mmu, gpu, 
a5xx_fault_handler);
+   if (gpu->vm) {
+   msm_mmu_set_fault_handler(to_msm_vm(gpu->vm)->mmu, gpu,
+ a5xx_fault_handler);
+   }
 
/* Set up the preemption specific bits and pieces for each ringbuffer */
a5xx_preempt_init(gpu);
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index 259a589a827d..32711c4967f7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1259,6 +1259,8 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
 
 static void a6xx_gmu_memory_free(struct a6xx_gmu *gmu)
 {
+   struct msm_mmu *mmu = to_msm_vm(gmu->vm)->mmu;
+
msm_gem_kernel_put(gmu->hfi.obj, gmu->vm);
msm_gem_kernel_put(gmu->debug.obj, gmu->vm);
msm_gem_kernel_put(gmu->icache.obj, gmu->vm);
@@ -1266,8 +1268,8 @@ static void a6xx_gmu_memory_free(struct a6xx_gmu *gmu)
msm_gem_kernel_put(gmu->dummy.obj, gmu->vm);
msm_gem_kernel_put(gmu->log.obj, gmu->vm);
 
-   gmu->vm->mmu->funcs->detach(gmu->vm->mmu);
-   msm_gem_vm_put(gmu->vm);
+   mmu->funcs->detach(mmu);
+   drm_gpuvm_put(gmu->vm);
 }
 
 static int a6xx_gmu_memory_alloc(struct a6xx_gmu *gmu, struct a6xx_gmu_bo *bo,
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index cceda7d9c33a..5da36226b93d 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -62,7 +62,7 @@ struct a6xx_gmu {
/* For serializing communication with the GMU: */
struct mutex lock;
 
-   struct msm_gem_vm *vm;
+   struct drm_gpuvm *vm;
 
void __iomem *mmio;
vo

[PATCH v2 00/34] drm/msm: sparse / "VM_BIND" support

From: Rob Clark 

Conversion to DRM GPU VA Manager[1], and adding support for Vulkan Sparse
Memory[2] in the form of:

1. A new VM_BIND submitqueue type for executing VM MSM_SUBMIT_BO_OP_MAP/
   MAP_NULL/UNMAP commands

2. Extending the SUBMIT ioctl to allow submitting batches of one or more
   MAP/MAP_NULL/UNMAP commands to a VM_BIND submitqueue

The UABI takes a slightly different approach from what other drivers have
done, and what would make sense if starting from a clean sheet, ie separate
VM_BIND and EXEC ioctls.  But since we have to maintain support for the
existing SUBMIT ioctl, and because the fence, syncobj, and BO pinning is
largely the same between legacy "BO-table" style SUBMIT ioctls, and new-
style VM updates submitted to a VM_BIND submitqueue, I chose to go the
route of extending the existing `SUBMIT` ioctl rather than adding a new
ioctl.

I also did not implement support for synchronous VM_BIND commands.  Since
userspace could just immediately wait for the `SUBMIT` to complete, I don't
think we need this extra complexity in the kernel.  Synchronous/immediate
VM_BIND operations could be implemented with a 2nd VM_BIND submitqueue.

The corresponding mesa MR: 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32533

This series can be found in MR form, if you prefer:
https://gitlab.freedesktop.org/drm/msm/-/merge_requests/144

Changes in v2:
- Dropped Bibek Kumar Patro's arm-smmu patches[3], which have since been
  merged.
- Pre-allocate all the things, and drop HACK patch which disabled shrinker.
  This includes ensuring that vm_bo objects are allocated up front, pre-
  allocating VMA objects, and pre-allocating pages used for pgtable updates.
  The latter utilizes io_pgtable_cfg callbacks for pgtable alloc/free, that
  were initially added for panthor. 
- Add back support for BO dumping for devcoredump.
- Link to v1 (RFC): 
https://lore.kernel.org/dri-devel/20241207161651.410556-1-robdcl...@gmail.com/T/#t

[1] https://www.kernel.org/doc/html/next/gpu/drm-mm.html#drm-gpuvm
[2] https://docs.vulkan.org/spec/latest/chapters/sparsemem.html
[3] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=909700

Rob Clark (34):
  drm/gpuvm: Don't require obj lock in destructor path
  drm/gpuvm: Remove bogus lock assert
  drm/gpuvm: Allow VAs to hold soft reference to BOs
  drm/gpuvm: Add drm_gpuvm_sm_unmap_va()
  drm/msm: Rename msm_file_private -> msm_context
  drm/msm: Improve msm_context comments
  drm/msm: Rename msm_gem_address_space -> msm_gem_vm
  drm/msm: Remove vram carveout support
  drm/msm: Collapse vma allocation and initialization
  drm/msm: Collapse vma close and delete
  drm/msm: drm_gpuvm conversion
  drm/msm: Use drm_gpuvm types more
  drm/msm: Split submit_pin_objects()
  drm/msm: Lazily create context VM
  drm/msm: Add opt-in for VM_BIND
  drm/msm: Mark VM as unusable on faults
  drm/msm: Extend SUBMIT ioctl for VM_BIND
  drm/msm: Add VM_BIND submitqueue
  drm/msm: Add _NO_SHARE flag
  drm/msm: Split out helper to get iommu prot flags
  drm/msm: Add mmu support for non-zero offset
  drm/msm: Add PRR support
  drm/msm: Rename msm_gem_vma_purge() -> _unmap()
  drm/msm: Split msm_gem_vma_new()
  drm/msm: Pre-allocate VMAs
  drm/msm: Pre-allocate vm_bo objects
  drm/msm: Pre-allocate pages for pgtable entries
  drm/msm: Wire up gpuvm ops
  drm/msm: Wire up drm_gpuvm debugfs
  drm/msm: Crashdump prep for sparse mappings
  drm/msm: rd dumping prep for sparse mappings
  drm/msm: Crashdec support for sparse
  drm/msm: rd dumping support for sparse
  drm/msm: Bump UAPI version

 drivers/gpu/drm/drm_gpuvm.c   | 141 ++--
 drivers/gpu/drm/msm/Kconfig   |   1 +
 drivers/gpu/drm/msm/adreno/a2xx_gpu.c |  25 +-
 drivers/gpu/drm/msm/adreno/a2xx_gpummu.c  |   5 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  17 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  17 +-
 drivers/gpu/drm/msm/adreno/a5xx_debugfs.c |   4 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c |  24 +-
 drivers/gpu/drm/msm/adreno/a5xx_power.c   |   2 +-
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c |  10 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.c |  32 +-
 drivers/gpu/drm/msm/adreno/a6xx_gmu.h |   2 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c |  51 +-
 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c   |   6 +-
 drivers/gpu/drm/msm/adreno/a6xx_preempt.c |  10 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c|   4 -
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  84 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |  23 +-
 .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   |  14 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c   |  18 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h   |   2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  18 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  14 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |   4 +-
 drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c |   6 +-
 drivers/gpu/drm/msm

[PATCH v2 01/34] drm/gpuvm: Don't require obj lock in destructor path

From: Rob Clark 

See commit a414fe3a2129 ("drm/msm/gem: Drop obj lock in
msm_gem_free_object()") for justification.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_gpuvm.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index f9eb56f24bef..1e89a98caad4 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -1511,7 +1511,9 @@ drm_gpuvm_bo_destroy(struct kref *kref)
drm_gpuvm_bo_list_del(vm_bo, extobj, lock);
drm_gpuvm_bo_list_del(vm_bo, evict, lock);
 
-   drm_gem_gpuva_assert_lock_held(obj);
+   if (kref_read(&obj->refcount) > 0)
+   drm_gem_gpuva_assert_lock_held(obj);
+
list_del(&vm_bo->list.entry.gem);
 
if (ops && ops->vm_bo_free)
@@ -1871,7 +1873,8 @@ drm_gpuva_unlink(struct drm_gpuva *va)
if (unlikely(!obj))
return;
 
-   drm_gem_gpuva_assert_lock_held(obj);
+   if (kref_read(&obj->refcount) > 0)
+   drm_gem_gpuva_assert_lock_held(obj);
list_del_init(&va->gem.entry);
 
va->vm_bo = NULL;
-- 
2.48.1

[PATCH v2 15/34] drm/msm: Add opt-in for VM_BIND