Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Christian König]

Am 07.12.23 um 19:02 schrieb Alex Deucher:

Add shared stats.  Useful for seeing shared memory.

v2: take dma-buf into account as well

Signed-off-by: Alex Deucher 
Cc: Rob Clark 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
  3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
index 5706b282a0c7..c7df7fa3459f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
@@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p, struct 
drm_file *file)
   stats.requested_visible_vram/1024UL);
drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
   stats.requested_gtt/1024UL);
+   drm_printf(p, "drm-shared-vram:\t%llu KiB\n", stats.vram_shared/1024UL);
+   drm_printf(p, "drm-shared-gtt:\t%llu KiB\n", stats.gtt_shared/1024UL);
+   drm_printf(p, "drm-shared-cpu:\t%llu KiB\n", stats.cpu_shared/1024UL);
+
for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
if (!usage[hw_ip])
continue;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index d79b4ca1ecfc..1b37d95475b8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
  struct amdgpu_mem_stats *stats)
  {
uint64_t size = amdgpu_bo_size(bo);
+   struct drm_gem_object *obj;
unsigned int domain;
+   bool shared;
  
  	/* Abort if the BO doesn't currently have a backing store */

if (!bo->tbo.resource)
return;
  
+	obj = >tbo.base;

+   shared = (obj->handle_count > 1) || obj->dma_buf;


I still think that looking at handle_count is the completely wrong 
approach, we should really only look at obj->dma_buf.


Regards,
Christian.


+
domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
switch (domain) {
case AMDGPU_GEM_DOMAIN_VRAM:
stats->vram += size;
if (amdgpu_bo_in_cpu_visible_vram(bo))
stats->visible_vram += size;
+   if (shared)
+   stats->vram_shared += size;
break;
case AMDGPU_GEM_DOMAIN_GTT:
stats->gtt += size;
+   if (shared)
+   stats->gtt_shared += size;
break;
case AMDGPU_GEM_DOMAIN_CPU:
default:
stats->cpu += size;
+   if (shared)
+   stats->cpu_shared += size;
break;
}
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h

index d28e21baef16..0503af75dc26 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -138,12 +138,18 @@ struct amdgpu_bo_vm {
  struct amdgpu_mem_stats {
/* current VRAM usage, includes visible VRAM */
uint64_t vram;
+   /* current shared VRAM usage, includes visible VRAM */
+   uint64_t vram_shared;
/* current visible VRAM usage */
uint64_t visible_vram;
/* current GTT usage */
uint64_t gtt;
+   /* current shared GTT usage */
+   uint64_t gtt_shared;
/* current system memory usage */
uint64_t cpu;
+   /* current shared system memory usage */
+   uint64_t cpu_shared;
/* sum of evicted buffers, includes visible VRAM */
uint64_t evicted_vram;
/* sum of evicted buffers due to CPU access */

[PATCH 4/5] drm/ttm: improve idle/busy handling v2

[Christian König]

Previously we would never try to move a BO into the preferred placements
when it ever landed in a busy placement since those were considered
compatible.

Rework the whole handling and finally unify the idle and busy handling.
ttm_bo_validate() is now responsible to try idle placement first and then
use the busy placement if that didn't worked.

Drawback is that we now always try the idle placement first for each
validation which might cause some additional CPU overhead on overcommit.

v2: fix kerneldoc warning and coding style

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   | 131 -
 drivers/gpu/drm/ttm/ttm_resource.c |  15 ++-
 include/drm/ttm/ttm_bo.h   |   3 +-
 include/drm/ttm/ttm_resource.h |   3 +-
 6 files changed, 65 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index aa0dd6dad068..f110dfdc4feb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -404,7 +404,7 @@ int amdgpu_bo_create_kernel_at(struct amdgpu_device *adev,
(*bo_ptr)->placements[i].lpfn = (offset + size) >> PAGE_SHIFT;
}
r = ttm_bo_mem_space(&(*bo_ptr)->tbo, &(*bo_ptr)->placement,
-&(*bo_ptr)->tbo.resource, );
+&(*bo_ptr)->tbo.resource, , false);
if (r)
goto error;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 9a6a00b1af40..00da9a81cf6c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -967,7 +967,7 @@ int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo)
placements.mem_type = TTM_PL_TT;
placements.flags = bo->resource->placement;
 
-   r = ttm_bo_mem_space(bo, , , );
+   r = ttm_bo_mem_space(bo, , , , true);
if (unlikely(r))
return r;
 
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index aa12bd5cfd17..17bfc252f76d 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -414,7 +414,7 @@ static int ttm_bo_bounce_temp_buffer(struct 
ttm_buffer_object *bo,
hop_placement.placement = hop;
 
/* find space in the bounce domain */
-   ret = ttm_bo_mem_space(bo, _placement, _mem, ctx);
+   ret = ttm_bo_mem_space(bo, _placement, _mem, ctx, true);
if (ret)
return ret;
/* move to the bounce domain */
@@ -454,7 +454,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
return ttm_bo_pipeline_gutting(bo);
}
 
-   ret = ttm_bo_mem_space(bo, , _mem, ctx);
+   ret = ttm_bo_mem_space(bo, , _mem, ctx, true);
if (ret) {
if (ret != -ERESTARTSYS) {
pr_err("Failed to find memory space for buffer 0x%p 
eviction\n",
@@ -724,37 +724,6 @@ static int ttm_bo_add_move_fence(struct ttm_buffer_object 
*bo,
return ret;
 }
 
-/*
- * Repeatedly evict memory from the LRU for @mem_type until we create enough
- * space, or we've evicted everything and there isn't enough space.
- */
-static int ttm_bo_mem_force_space(struct ttm_buffer_object *bo,
- const struct ttm_place *place,
- struct ttm_resource **mem,
- struct ttm_operation_ctx *ctx)
-{
-   struct ttm_device *bdev = bo->bdev;
-   struct ttm_resource_manager *man;
-   struct ww_acquire_ctx *ticket;
-   int ret;
-
-   man = ttm_manager_type(bdev, place->mem_type);
-   ticket = dma_resv_locking_ctx(bo->base.resv);
-   do {
-   ret = ttm_resource_alloc(bo, place, mem);
-   if (likely(!ret))
-   break;
-   if (unlikely(ret != -ENOSPC))
-   return ret;
-   ret = ttm_mem_evict_first(bdev, man, place, ctx,
- ticket);
-   if (unlikely(ret != 0))
-   return ret;
-   } while (1);
-
-   return ttm_bo_add_move_fence(bo, man, *mem, ctx->no_wait_gpu);
-}
-
 /**
  * ttm_bo_mem_space
  *
@@ -763,6 +732,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
  * @placement: Proposed new placement for the buffer object.
  * @mem: A struct ttm_resource.
  * @ctx: if and how to sleep, lock buffers and alloc memory
+ * @force_space: If we should evict buffers to force space
  *
  * Allocate memory space for the buffer object pointed to by @bo, using
  * the placement flags in @placement, potentially evicting other idle buffer 
objects.
@@ -776,12 +746,14 @@ static int ttm_bo_mem_force_space(struct 
ttm_buffer_object *bo,
 int 

[PATCH 3/5] drm/ttm: replace busy placement with flags v5

[Christian König]

From: Somalapuram Amaranath 

Instead of a list of separate busy placement add flags which indicate
that a placement should only be used when there is room or if we need to
evict.

v2: add missing TTM_PL_FLAG_IDLE for i915
v3: fix auto build test ERROR on drm-tip/drm-tip
v4: fix some typos pointed out by checkpatch
v5: cleanup some rebase problems with VMWGFX

Signed-off-by: Christian König 
Signed-off-by: Somalapuram Amaranath 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 11 +---
 drivers/gpu/drm/drm_gem_vram_helper.c  |  2 -
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 37 +--
 drivers/gpu/drm/loongson/lsdc_ttm.c|  2 -
 drivers/gpu/drm/nouveau/nouveau_bo.c   | 59 +++--
 drivers/gpu/drm/nouveau/nouveau_bo.h   |  1 -
 drivers/gpu/drm/qxl/qxl_object.c   |  2 -
 drivers/gpu/drm/qxl/qxl_ttm.c  |  2 -
 drivers/gpu/drm/radeon/radeon_object.c |  2 -
 drivers/gpu/drm/radeon/radeon_ttm.c|  8 +--
 drivers/gpu/drm/radeon/radeon_uvd.c|  1 -
 drivers/gpu/drm/ttm/ttm_bo.c   | 21 ---
 drivers/gpu/drm/ttm/ttm_resource.c | 73 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c |  2 -
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c |  4 --
 include/drm/ttm/ttm_placement.h| 10 +--
 include/drm/ttm/ttm_resource.h |  8 +--
 18 files changed, 79 insertions(+), 172 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index cef920a93924..aa0dd6dad068 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -220,9 +220,6 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo, 
u32 domain)
 
placement->num_placement = c;
placement->placement = places;
-
-   placement->num_busy_placement = c;
-   placement->busy_placement = places;
 }
 
 /**
@@ -1406,8 +1403,7 @@ vm_fault_t amdgpu_bo_fault_reserve_notify(struct 
ttm_buffer_object *bo)
AMDGPU_GEM_DOMAIN_GTT);
 
/* Avoid costly evictions; only set GTT as a busy placement */
-   abo->placement.num_busy_placement = 1;
-   abo->placement.busy_placement = >placements[1];
+   abo->placements[0].flags |= TTM_PL_FLAG_IDLE;
 
r = ttm_bo_validate(bo, >placement, );
if (unlikely(r == -EBUSY || r == -ERESTARTSYS))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 05991c5c8ddb..9a6a00b1af40 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -102,23 +102,19 @@ static void amdgpu_evict_flags(struct ttm_buffer_object 
*bo,
/* Don't handle scatter gather BOs */
if (bo->type == ttm_bo_type_sg) {
placement->num_placement = 0;
-   placement->num_busy_placement = 0;
return;
}
 
/* Object isn't an AMDGPU object so ignore */
if (!amdgpu_bo_is_amdgpu_bo(bo)) {
placement->placement = 
-   placement->busy_placement = 
placement->num_placement = 1;
-   placement->num_busy_placement = 1;
return;
}
 
abo = ttm_to_amdgpu_bo(bo);
if (abo->flags & AMDGPU_GEM_CREATE_DISCARDABLE) {
placement->num_placement = 0;
-   placement->num_busy_placement = 0;
return;
}
 
@@ -128,13 +124,13 @@ static void amdgpu_evict_flags(struct ttm_buffer_object 
*bo,
case AMDGPU_PL_OA:
case AMDGPU_PL_DOORBELL:
placement->num_placement = 0;
-   placement->num_busy_placement = 0;
return;
 
case TTM_PL_VRAM:
if (!adev->mman.buffer_funcs_enabled) {
/* Move to system memory */
amdgpu_bo_placement_from_domain(abo, 
AMDGPU_GEM_DOMAIN_CPU);
+
} else if (!amdgpu_gmc_vram_full_visible(>gmc) &&
   !(abo->flags & 
AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED) &&
   amdgpu_bo_in_cpu_visible_vram(abo)) {
@@ -149,8 +145,7 @@ static void amdgpu_evict_flags(struct ttm_buffer_object *bo,
AMDGPU_GEM_DOMAIN_CPU);
abo->placements[0].fpfn = adev->gmc.visible_vram_size 
>> PAGE_SHIFT;
abo->placements[0].lpfn = 0;
-   abo->placement.busy_placement = >placements[1];
-   abo->placement.num_busy_placement = 1;
+   abo->placements[0].flags |= TTM_PL_FLAG_IDLE;
} else {
/* Move to GTT memory */
amdgpu_bo_placement_from_domain(abo, 
AMDGPU_GEM_DOMAIN_GTT |
@@ -967,8 +962,6 @@ int amdgpu_ttm_alloc_gart(struct 

[PATCH 5/5] drm/amdgpu: use GTT only as fallback for VRAM|GTT

[Christian König]

Try to fill up VRAM as well by setting the busy flag on GTT allocations.

This fixes the issue that when VRAM was evacuated for suspend it's never
filled up again unless the application is restarted.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index f110dfdc4feb..979cecf18f17 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -173,6 +173,12 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo 
*abo, u32 domain)
abo->flags & AMDGPU_GEM_CREATE_PREEMPTIBLE ?
AMDGPU_PL_PREEMPT : TTM_PL_TT;
places[c].flags = 0;
+   /*
+* When GTT is just an alternative to VRAM make sure that we
+* only use it as fallback and still try to fill up VRAM first.
+*/
+   if (domain & abo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM)
+   places[c].flags |= TTM_PL_FLAG_BUSY;
c++;
}
 
-- 
2.34.1

[PATCH 2/5] drm/ttm: return ENOSPC from ttm_bo_mem_space

[Christian König]

Only convert it to ENOMEM in ttm_bo_validate.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index edf10618fe2b..8c1eaa74fa21 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -830,7 +830,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
goto error;
}
 
-   ret = -ENOMEM;
+   ret = -ENOSPC;
if (!type_found) {
pr_err(TTM_PFX "No compatible memory type found\n");
ret = -EINVAL;
@@ -916,6 +916,9 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
return -EINVAL;
 
ret = ttm_bo_move_buffer(bo, placement, ctx);
+   /* For backward compatibility with userspace */
+   if (ret == -ENOSPC)
+   return -ENOMEM;
if (ret)
return ret;
 
-- 
2.34.1

[PATCH 1/5] drm/vmwgfx: remove vmw_vram_gmr_placement

[Christian König]

Seems to be unused.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  1 -
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 28 --
 2 files changed, 29 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 3cd5090dedfc..12efecc17df6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -942,7 +942,6 @@ vmw_is_cursor_bypass3_enabled(const struct vmw_private 
*dev_priv)
 
 extern const size_t vmw_tt_size;
 extern struct ttm_placement vmw_vram_placement;
-extern struct ttm_placement vmw_vram_gmr_placement;
 extern struct ttm_placement vmw_sys_placement;
 extern struct ttm_device_funcs vmw_bo_driver;
 extern const struct vmw_sg_table *
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index af8562c95cc3..a84fffcef8e1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
@@ -43,13 +43,6 @@ static const struct ttm_place sys_placement_flags = {
.flags = 0
 };
 
-static const struct ttm_place gmr_placement_flags = {
-   .fpfn = 0,
-   .lpfn = 0,
-   .mem_type = VMW_PL_GMR,
-   .flags = 0
-};
-
 struct ttm_placement vmw_vram_placement = {
.num_placement = 1,
.placement = _placement_flags,
@@ -57,27 +50,6 @@ struct ttm_placement vmw_vram_placement = {
.busy_placement = _placement_flags
 };
 
-static const struct ttm_place vram_gmr_placement_flags[] = {
-   {
-   .fpfn = 0,
-   .lpfn = 0,
-   .mem_type = TTM_PL_VRAM,
-   .flags = 0
-   }, {
-   .fpfn = 0,
-   .lpfn = 0,
-   .mem_type = VMW_PL_GMR,
-   .flags = 0
-   }
-};
-
-struct ttm_placement vmw_vram_gmr_placement = {
-   .num_placement = 2,
-   .placement = vram_gmr_placement_flags,
-   .num_busy_placement = 1,
-   .busy_placement = _placement_flags
-};
-
 struct ttm_placement vmw_sys_placement = {
.num_placement = 1,
.placement = _placement_flags,
-- 
2.34.1

Rework TTMs busy handling

[Christian König]

Hi guys,

I'm trying to make this functionality a bit more useful for years now
since we multiple reports that behavior of drivers can be suboptimal
when multiple placements be given.

So basically instead of hacking around the TTM behavior in the driver
once more I've gone ahead and changed the idle/busy placement list
into idle/busy placement flags. This not only saves a bunch of code,
but also allows setting some placements as fallback which are used if
allocating from the preferred ones didn't worked.

Zack pointed out that some removed VMWGFX code was brought back because
of rebasing, fixed in this version.

Intel CI seems to be happy with those patches, so any more comments?

Regards,
Christian.

[PATCH v2 2/2] gpu: drm: panel: panel-simple: add new display mode for waveshare 7inch touchscreen panel

[Shengyang Chen]

The waveshare 7" 800x480 panel is a clone of Raspberry Pi 7" 800x480 panel
It also uses a Toshiba TC358762 DSI to DPI bridge chip but it needs different
timing from Raspberry Pi panel. Add new timing for it.

Signed-off-by: Keith Zhao 
Signed-off-by: Shengyang Chen 
---
 drivers/gpu/drm/panel/panel-simple.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9367a4572dcf..e0896873ea33 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -4110,6 +4110,31 @@ static const struct panel_desc vl050_8048nt_c01 = {
.bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
 };
 
+static const struct drm_display_mode waveshare_7inch_mode = {
+   .clock = 2970 / 1000,
+   .hdisplay = 800,
+   .hsync_start = 800 + 90,
+   .hsync_end = 800 + 90 + 5,
+   .htotal = 800 + 90 + 5 + 5,
+   .vdisplay = 480,
+   .vsync_start = 480 + 60,
+   .vsync_end = 480 + 60 + 5,
+   .vtotal = 480 + 60 + 5 + 5,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc waveshare_7inch = {
+   .modes = _7inch_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .connector_type = DRM_MODE_CONNECTOR_DSI,
+};
+
 static const struct drm_display_mode winstar_wf35ltiacd_mode = {
.clock = 6410,
.hdisplay = 320,
@@ -4592,6 +4617,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "vxt,vl050-8048nt-c01",
.data = _8048nt_c01,
+   }, {
+   .compatible = "waveshare,7inch-touchscreen",
+   .data = _7inch,
}, {
.compatible = "winstar,wf35ltiacd",
.data = _wf35ltiacd,
-- 
2.17.1

[PATCH v2 2/2] gpu: drm: bridge: cadence: Add a driver and platform ops for StarFive JH7110 SoC

[Shengyang Chen]

From: Keith Zhao 

In order to fit CDNS DSI module in StarFive JH7110 SoC,
The mainly modification is followed:

1.Add driver for StarFive JH7110 SoC to drive its CDNS DSI module.
2.Add platform ops in cdns-dsi.c for StarFive JH7110 SoC probing.

Signed-off-by: Keith Zhao 
---
 MAINTAINERS   |   8 +
 drivers/gpu/drm/bridge/cadence/Kconfig|   7 +
 drivers/gpu/drm/bridge/cadence/Makefile   |   1 +
 .../gpu/drm/bridge/cadence/cdns-dsi-core.c|  29 ++-
 .../gpu/drm/bridge/cadence/cdns-dsi-core.h|  21 ++
 .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.c  | 193 ++
 .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.h  |  16 ++
 7 files changed, 274 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.c
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.h

diff --git a/MAINTAINERS b/MAINTAINERS
index d32920dd943f..a220ea04f5c4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6847,6 +6847,14 @@ F:   
Documentation/devicetree/bindings/display/solomon,ssd-common.yaml
 F: Documentation/devicetree/bindings/display/solomon,ssd13*.yaml
 F: drivers/gpu/drm/solomon/ssd130x*
 
+DRM DRIVERS FOR STARFIVE
+M: Keith Zhao 
+M: Shengyang Chen 
+L: dri-devel@lists.freedesktop.org
+S: Maintained
+T: git git://anongit.freedesktop.org/drm/drm-misc
+F: drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110*
+
 DRM DRIVER FOR ST-ERICSSON MCDE
 M: Linus Walleij 
 S: Maintained
diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig 
b/drivers/gpu/drm/bridge/cadence/Kconfig
index cced81633ddc..ad9f572f4720 100644
--- a/drivers/gpu/drm/bridge/cadence/Kconfig
+++ b/drivers/gpu/drm/bridge/cadence/Kconfig
@@ -19,6 +19,13 @@ config DRM_CDNS_DSI_J721E
help
  Support J721E Cadence DSI wrapper. The wrapper manages
  the routing of the DSS DPI signal to the Cadence DSI.
+
+config DRM_CDNS_DSI_JH7110
+   bool "JH7110 SOC Cadence DSI support"
+   default n
+   help
+ Cadence DPI to DSI bridge which is embedded in the
+ StarFive JH7110 SoC.
 endif
 
 config DRM_CDNS_MHDP8546
diff --git a/drivers/gpu/drm/bridge/cadence/Makefile 
b/drivers/gpu/drm/bridge/cadence/Makefile
index c95fd5b81d13..87f603a9f4ad 100644
--- a/drivers/gpu/drm/bridge/cadence/Makefile
+++ b/drivers/gpu/drm/bridge/cadence/Makefile
@@ -2,6 +2,7 @@
 obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 cdns-dsi-y := cdns-dsi-core.o
 cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
+cdns-dsi-$(CONFIG_DRM_CDNS_DSI_JH7110) += cdns-dsi-jh7110.o
 obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
 cdns-mhdp8546-y := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
 cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) += cdns-mhdp8546-j721e.o
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
index 7457d38622b0..a8f976f9eeed 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
@@ -27,6 +27,10 @@
 #include "cdns-dsi-j721e.h"
 #endif
 
+#ifdef CONFIG_DRM_CDNS_DSI_JH7110
+#include "cdns-dsi-jh7110.h"
+#endif
+
 #define IP_CONF0x0
 #define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
 #define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
@@ -552,6 +556,10 @@ static int cdns_dsi_adjust_phy_config(struct cdns_dsi *dsi,
/* data rate was in bytes/sec, convert to bits/sec. */
phy_cfg->hs_clk_rate = dlane_bps * 8;
 
+   if (dsi->platform_ops && dsi->platform_ops->update)
+   adj_dsi_htotal = dsi->platform_ops->update(dsi, dsi_cfg, 
phy_cfg,
+  dpi_hz, dpi_htotal, 
dsi_htotal);
+
dsi_hfp_ext = adj_dsi_htotal - dsi_htotal;
dsi_cfg->hfp += dsi_hfp_ext;
dsi_cfg->htotal = dsi_htotal + dsi_hfp_ext;
@@ -683,7 +691,7 @@ static void cdns_dsi_bridge_post_disable(struct drm_bridge 
*bridge)
pm_runtime_put(dsi->base.dev);
 }
 
-static void cdns_dsi_hs_init(struct cdns_dsi *dsi)
+void cdns_dsi_hs_init(struct cdns_dsi *dsi)
 {
struct cdns_dsi_output *output = >output;
u32 status;
@@ -1026,6 +1034,14 @@ static ssize_t cdns_dsi_transfer(struct mipi_dsi_host 
*host,
 
cdns_dsi_init_link(dsi);
 
+   /*
+* on JH7110 SoC , when transfer dsi command ,
+* cdns_dsi_hs_init is needed.
+* or the final ret will be error value.
+*/
+   if (dsi->platform_ops && dsi->platform_ops->transfer)
+   dsi->platform_ops->transfer(dsi);
+
ret = mipi_dsi_create_packet(, msg);
if (ret)
goto out;
@@ -1142,6 +1158,9 @@ static int __maybe_unused cdns_dsi_resume(struct device 
*dev)
clk_prepare_enable(dsi->dsi_p_clk);
clk_prepare_enable(dsi->dsi_sys_clk);
 
+   if (dsi->platform_ops && dsi->platform_ops->resume)
+   

[PATCH v2 1/2] dt-bindings: display: bridge: cdns: Add properties to support StarFive JH7110 SoC

[Shengyang Chen]

From: Keith Zhao 

Add properties in CDNS DSI yaml file to match with
CDNS DSI module in StarFive JH7110 SoC.

Signed-off-by: Keith Zhao 
---
 .../bindings/display/bridge/cdns,dsi.yaml | 44 ++-
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
index 23060324d16e..da091e105794 100644
--- a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.yaml
@@ -16,6 +16,7 @@ properties:
   compatible:
 enum:
   - cdns,dsi
+  - starfve,jh7110-dsi
   - ti,j721e-dsi
 
   reg:
@@ -27,14 +28,20 @@ properties:
   Register block for wrapper settings registers in case of TI J7 SoCs.
 
   clocks:
+minItems: 2
 items:
   - description: PSM clock, used by the IP
   - description: sys clock, used by the IP
+  - description: apb clock, used by the IP
+  - description: txesc clock, used by the IP
 
   clock-names:
+minItems: 2
 items:
   - const: dsi_p_clk
   - const: dsi_sys_clk
+  - const: apb
+  - const: txesc
 
   phys:
 maxItems: 1
@@ -46,10 +53,21 @@ properties:
 maxItems: 1
 
   resets:
-maxItems: 1
+minItems: 1
+items:
+  - description: dsi sys reset line
+  - description: dsi dpi reset line
+  - description: dsi apb reset line
+  - description: dsi txesc reset line
+  - description: dsi txbytehs reset line
 
   reset-names:
-const: dsi_p_rst
+items:
+  - const: dsi_p_rst
+  - const: dpi
+  - const: apb
+  - const: txesc
+  - const: txbytehs
 
   ports:
 $ref: /schemas/graph.yaml#/properties/ports
@@ -90,6 +108,28 @@ allOf:
 reg:
   maxItems: 1
 
+  - if:
+  properties:
+compatible:
+  contains:
+const: starfive,jh7110-dsi
+then:
+  properties:
+clocks:
+  minItems: 4
+  maxItems: 4
+resets:
+  minItems: 5
+  maxItems: 5
+  required:
+- reset-names
+else:
+  properties:
+clocks:
+  maxItems: 2
+resets:
+  maxItems: 1
+
 required:
   - compatible
   - reg
-- 
2.17.1

[PATCH v2 0/2] Add StarFive JH7110 SoC DSI support

[Shengyang Chen]

This series is the series that attempts to support
the CDNS DSI driver used to converts DPI to DSI.
CDNS DSI is embedded in StarFive JH7110 SoC.
The series has been tested on the VisionFive 2 board.


changes since v1:
- Rebased on tag v6.7.

patch 1:
- Changed the 'starfive,cdns-dsi' to 'starfve,jh7110-dsi'.
- Changed the compatible enum alphabetical order.
- Restrict other variants.
- Drop 'dsi_' prefix.

patch 2:
- Optimize the calculation process.
- Drop useless definition.

v1: 
https://patchwork.kernel.org/project/dri-devel/cover/20231127113436.57361-1-shengyang.c...@starfivetech.com/

Keith Zhao (2):
  dt-bindings: display: bridge: cdns: Add properties to support StarFive
JH7110 SoC
  gpu: drm: bridge: cadence: Add a driver and platform ops for StarFive
JH7110 SoC

 .../bindings/display/bridge/cdns,dsi.yaml |  44 +++-
 MAINTAINERS   |   8 +
 drivers/gpu/drm/bridge/cadence/Kconfig|   7 +
 drivers/gpu/drm/bridge/cadence/Makefile   |   1 +
 .../gpu/drm/bridge/cadence/cdns-dsi-core.c|  29 ++-
 .../gpu/drm/bridge/cadence/cdns-dsi-core.h|  21 ++
 .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.c  | 193 ++
 .../gpu/drm/bridge/cadence/cdns-dsi-jh7110.h  |  16 ++
 8 files changed, 316 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.c
 create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-dsi-jh7110.h

-- 
2.17.1

[PATCH v2 0/2] Add waveshare 7inch touchscreen panel support

[Shengyang Chen]

This patchset adds waveshare 7inch touchscreen panel support
for the StarFive JH7110 SoC.


changes since v1:
- Rebased on tag v6.7.

patch 1:
- Gave up original changing.
- Changed the commit message.
- Add compatible in panel-simple.yaml

patch 2:
- Gave up original changing.
- Changed the commit message.
- Add new mode for the panel in panel-simple.c

v1: 
https://patchwork.kernel.org/project/dri-devel/cover/20231124104451.44271-1-shengyang.c...@starfivetech.com/

Shengyang Chen (2):
  dt-bindings: display: panel: panel-simple: Add compatible property for
waveshare 7inch touchscreen panel
  gpu: drm: panel: panel-simple: add new display mode for waveshare
7inch touchscreen panel

 .../bindings/display/panel/panel-simple.yaml  |  2 ++
 drivers/gpu/drm/panel/panel-simple.c  | 28 +++
 2 files changed, 30 insertions(+)

-- 
2.17.1

[PATCH v2 1/2] dt-bindings: display: panel: panel-simple: Add compatible property for waveshare 7inch touchscreen panel

[Shengyang Chen]

The waveshare 7" 800x480 panel is a clone of Raspberry Pi 7" 800x480 panel
It can be drived by Raspberry Pi panel's process but it needs different
timing from Raspberry Pi panel. Add compatible property for it.

Signed-off-by: Keith Zhao 
Signed-off-by: Shengyang Chen 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 11422af3477e..02f6b1b2ddc9 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -335,6 +335,8 @@ properties:
   - vivax,tpc9150-panel
 # VXT 800x480 color TFT LCD panel
   - vxt,vl050-8048nt-c01
+# Waveshare 7" (800x480) touchscreen LCD panel
+  - waveshare,7inch-touchscreen
 # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel
   - winstar,wf35ltiacd
 # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel
-- 
2.17.1

Re: 回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2

[Christian König]

Am 09.01.24 um 02:50 schrieb 李真能:


When the priority value is passed to the kernel, the kernel compares 
it with the following values:


#define AMDGPU_CTX_PRIORITY_VERY_LOW    -1023
#define AMDGPU_CTX_PRIORITY_LOW -512
#define AMDGPU_CTX_PRIORITY_NORMAL  0
#define AMDGPU_CTX_PRIORITY_HIGH    512
#define AMDGPU_CTX_PRIORITY_VERY_HIGH   1023

If priority is uint32_t, we can't set LOW and VERY_LOW value to kernel 
context priority,




Well that's nonsense.

How the kernel handles the values and how userspace handles them are two 
separate things. You just need to make sure that it's always 32 bits.


In other words if you have signed or unsigned data type in userspace is 
irrelevant for the kernel.


You can refer to the kernel function amdgpu_ctx_priority_permit, if 
priority is greater


than 0, and this process has not  CAP_SYS_NICE capibility or 
DRM_MASTER permission,


this process will be exited.



Correct, that's intentional.

Regards,
Christian.












*主　题：*Re: [PATCH libdrm 1/2] amdgpu: fix parameter of 
amdgpu_cs_ctx_create2

*日　期：*2024-01-09 00:28
*发件人：*Christian König
*收件人：*李真能;Marek Olsak;Pierre-Eric Pelloux-Prayer;dri-devel;amd-gfx;

Am 08.01.24 um 10:40 schrieb Zhenneng Li:
> In order to pass the correct priority parameter to the kernel,
> we must change priority type from uint32_t to int32_t.

Hui what? Why should it matter if the parameter is signed or not?

That doesn't seem to make sense.

Regards,
Christian.

>
> Signed-off-by: Zhenneng Li
> ---
> amdgpu/amdgpu.h | 2 +-
> amdgpu/amdgpu_cs.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
> index 9bdbf366..f46753f3 100644
> --- a/amdgpu/amdgpu.h
> +++ b/amdgpu/amdgpu.h
> @@ -896,7 +896,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle 
handle,

> *
> */
> int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
> - uint32_t priority,
> + int32_t priority,
> amdgpu_context_handle *context);
> /**
> * Create GPU execution Context
> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
> index 49fc16c3..eb72c638 100644
> --- a/amdgpu/amdgpu_cs.c
> +++ b/amdgpu/amdgpu_cs.c
> @@ -49,7 +49,7 @@ static int 
amdgpu_cs_reset_sem(amdgpu_semaphore_handle sem);

> * \return 0 on success otherwise POSIX Error code
> */
> drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
> - uint32_t priority,
> + int32_t priority,
> amdgpu_context_handle *context)
> {
> struct amdgpu_context *gpu_context;

[PATCH linux-next v2] drm/nouveau/disp: switch to use kmemdup() helper

[yang.guang5]

From: Chen Haonan 

Use kmemdup() helper instead of open-coding to
simplify the code.

Signed-off-by: Chen Haonan 
Reviewed-by: Yang Guang 
---
 drivers/gpu/drm/nouveau/nvif/outp.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvif/outp.c 
b/drivers/gpu/drm/nouveau/nvif/outp.c
index 5d3190c05250..6daeb7f0b09b 100644
--- a/drivers/gpu/drm/nouveau/nvif/outp.c
+++ b/drivers/gpu/drm/nouveau/nvif/outp.c
@@ -452,13 +452,12 @@ nvif_outp_edid_get(struct nvif_outp *outp, u8 **pedid)
if (ret)
goto done;

-   *pedid = kmalloc(args->size, GFP_KERNEL);
+   *pedid = kmemdup(args->data, args->size, GFP_KERNEL);
if (!*pedid) {
ret = -ENOMEM;
goto done;
}

-   memcpy(*pedid, args->data, args->size);
ret = args->size;
 done:
kfree(args);
-- 
2.25.1

[PATCH v5 7/7] x86/vmware: Add TDX hypercall support

[Alexey Makhalov]

VMware hypercalls use I/O port, VMCALL or VMMCALL instructions.
Add __tdx_hypercall path to support TDX guests.

No change in high bandwidth hypercalls, as only low bandwidth
ones are supported for TDX guests.

Co-developed-by: Tim Merrifield 
Signed-off-by: Tim Merrifield 
Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
---
 arch/x86/include/asm/vmware.h | 79 +++
 arch/x86/kernel/cpu/vmware.c  | 25 +++
 2 files changed, 104 insertions(+)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 84a31f579a30..3bd593c6591d 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -18,6 +18,12 @@
  * arg2 - Hypercall command
  * arg3 bits [15:0] - Port number, LB and direction flags
  *
+ * - Low bandwidth TDX hypercalls (x86_64 only) are similar to LB
+ * hypercalls. They also have up to 6 input and 6 output on registers
+ * arguments, with different argument to register mapping:
+ * %r12 (arg0), %rbx (arg1), %r13 (arg2), %rdx (arg3),
+ * %rsi (arg4), %rdi (arg5).
+ *
  * - High bandwidth (HB) hypercalls are I/O port based only. They have
  * up to 7 input and 7 output arguments passed and returned using
  * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
@@ -54,12 +60,61 @@
 #define VMWARE_CMD_GETHZ   45
 #define VMWARE_CMD_GETVCPU_INFO68
 #define VMWARE_CMD_STEALCLOCK  91
+/*
+ * Hypercall command mask:
+ *   bits [6:0] command, range [0, 127]
+ *   bits [19:16] sub-command, range [0, 15]
+ */
+#define VMWARE_CMD_MASK0xf007fU
 
 #define CPUID_VMWARE_FEATURES_ECX_VMMCALL  BIT(0)
 #define CPUID_VMWARE_FEATURES_ECX_VMCALL   BIT(1)
 
 extern u8 vmware_hypercall_mode;
 
+#define VMWARE_TDX_VENDOR_LEAF 0x1af7e4909ULL
+#define VMWARE_TDX_HCALL_FUNC  1
+
+extern unsigned long vmware_tdx_hypercall(unsigned long cmd,
+ struct tdx_module_args *args);
+
+/*
+ * TDCALL[TDG.VP.VMCALL] uses %rax (arg0) and %rcx (arg2). Therefore,
+ * we remap those registers to %r12 and %r13, respectively.
+ */
+static inline
+unsigned long vmware_tdx_hypercall_args(unsigned long cmd, unsigned long in1,
+   unsigned long in3, unsigned long in4,
+   unsigned long in5,
+   uint32_t *out1, uint32_t *out2,
+   uint32_t *out3, uint32_t *out4,
+   uint32_t *out5)
+{
+   unsigned long ret;
+
+   struct tdx_module_args args = {
+   .rbx = in1,
+   .rdx = in3,
+   .rsi = in4,
+   .rdi = in5,
+   };
+
+   ret = vmware_tdx_hypercall(cmd, );
+
+   if (out1)
+   *out1 = args.rbx;
+   if (out2)
+   *out2 = args.r13;
+   if (out3)
+   *out3 = args.rdx;
+   if (out4)
+   *out4 = args.rsi;
+   if (out5)
+   *out5 = args.rdi;
+
+   return ret;
+}
+
 /*
  * The low bandwidth call. The low word of %edx is presumed to have OUT bit
  * set. The high word of %edx may contain input data from the caller.
@@ -87,6 +142,10 @@ unsigned long vmware_hypercall1(unsigned long cmd, unsigned 
long in1)
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0,
+NULL, NULL, NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -105,6 +164,10 @@ unsigned long vmware_hypercall3(unsigned long cmd, 
unsigned long in1,
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0,
+out1, out2, NULL, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=b" (*out1), "=c" (*out2)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -124,6 +187,10 @@ unsigned long vmware_hypercall4(unsigned long cmd, 
unsigned long in1,
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, 0, 0, 0,
+out1, out2, out3, NULL, NULL);
+
asm_inline volatile (VMWARE_HYPERCALL
: "=a" (out0), "=b" (*out1), "=c" (*out2), "=d" (*out3)
: [port] "i" (VMWARE_HYPERVISOR_PORT),
@@ -143,6 +210,10 @@ unsigned long vmware_hypercall5(unsigned long cmd, 
unsigned long in1,
 {
unsigned long out0;
 
+   if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
+   return vmware_tdx_hypercall_args(cmd, in1, in3, in4, in5,
+  

[PATCH v5 6/7] x86/vmware: Undefine VMWARE_HYPERCALL

[Alexey Makhalov]

No more direct use of VMWARE_HYPERCALL macro should be allowed.

Signed-off-by: Alexey Makhalov 
---
 arch/x86/include/asm/vmware.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index 2ac87068184a..84a31f579a30 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -273,5 +273,6 @@ unsigned long vmware_hypercall_hb_in(unsigned long cmd, 
unsigned long in2,
 }
 #undef VMW_BP_REG
 #undef VMW_BP_CONSTRAINT
+#undef VMWARE_HYPERCALL
 
 #endif
-- 
2.39.0

[PATCH v5 5/7] drm/vmwgfx: Use VMware hypercall API

[Alexey Makhalov]

Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code.

drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h: implement arm64 variant
of vmware_hypercall. And keep it here until introduction of ARM64
VMWare hypervisor interface.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c   | 173 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h | 197 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_x86.h   | 187 
 3 files changed, 197 insertions(+), 360 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 2651fe0ef518..1f15990d3934 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -48,8 +48,6 @@
 
 #define RETRIES 3
 
-#define VMW_HYPERVISOR_MAGIC0x564D5868
-
 #define VMW_PORT_CMD_MSG30
 #define VMW_PORT_CMD_HB_MSG 0
 #define VMW_PORT_CMD_OPEN_CHANNEL  (MSG_TYPE_OPEN << 16 | VMW_PORT_CMD_MSG)
@@ -104,20 +102,18 @@ static const char* const 
mksstat_kern_name_desc[MKSSTAT_KERN_COUNT][2] =
  */
 static int vmw_open_channel(struct rpc_channel *channel, unsigned int protocol)
 {
-   unsigned long eax, ebx, ecx, edx, si = 0, di = 0;
+   u32 ecx, edx, esi, edi;
 
-   VMW_PORT(VMW_PORT_CMD_OPEN_CHANNEL,
-   (protocol | GUESTMSG_FLAG_COOKIE), si, di,
-   0,
-   VMW_HYPERVISOR_MAGIC,
-   eax, ebx, ecx, edx, si, di);
+   vmware_hypercall6(VMW_PORT_CMD_OPEN_CHANNEL,
+ (protocol | GUESTMSG_FLAG_COOKIE), 0,
+ , , , );
 
if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0)
return -EINVAL;
 
channel->channel_id  = HIGH_WORD(edx);
-   channel->cookie_high = si;
-   channel->cookie_low  = di;
+   channel->cookie_high = esi;
+   channel->cookie_low  = edi;
 
return 0;
 }
@@ -133,17 +129,13 @@ static int vmw_open_channel(struct rpc_channel *channel, 
unsigned int protocol)
  */
 static int vmw_close_channel(struct rpc_channel *channel)
 {
-   unsigned long eax, ebx, ecx, edx, si, di;
-
-   /* Set up additional parameters */
-   si  = channel->cookie_high;
-   di  = channel->cookie_low;
+   u32 ecx;
 
-   VMW_PORT(VMW_PORT_CMD_CLOSE_CHANNEL,
-   0, si, di,
-   channel->channel_id << 16,
-   VMW_HYPERVISOR_MAGIC,
-   eax, ebx, ecx, edx, si, di);
+   vmware_hypercall5(VMW_PORT_CMD_CLOSE_CHANNEL,
+ 0, channel->channel_id << 16,
+ channel->cookie_high,
+ channel->cookie_low,
+ );
 
if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0)
return -EINVAL;
@@ -163,24 +155,18 @@ static int vmw_close_channel(struct rpc_channel *channel)
 static unsigned long vmw_port_hb_out(struct rpc_channel *channel,
 const char *msg, bool hb)
 {
-   unsigned long si, di, eax, ebx, ecx, edx;
+   u32 ebx, ecx;
unsigned long msg_len = strlen(msg);
 
/* HB port can't access encrypted memory. */
if (hb && !cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
-   unsigned long bp = channel->cookie_high;
-   u32 channel_id = (channel->channel_id << 16);
-
-   si = (uintptr_t) msg;
-   di = channel->cookie_low;
-
-   VMW_PORT_HB_OUT(
+   vmware_hypercall_hb_out(
(MESSAGE_STATUS_SUCCESS << 16) | VMW_PORT_CMD_HB_MSG,
-   msg_len, si, di,
-   VMWARE_HYPERVISOR_HB | channel_id |
-   VMWARE_HYPERVISOR_OUT,
-   VMW_HYPERVISOR_MAGIC, bp,
-   eax, ebx, ecx, edx, si, di);
+   msg_len,
+   channel->channel_id << 16,
+   (uintptr_t) msg, channel->cookie_low,
+   channel->cookie_high,
+   );
 
return ebx;
}
@@ -194,14 +180,13 @@ static unsigned long vmw_port_hb_out(struct rpc_channel 
*channel,
memcpy(, msg, bytes);
msg_len -= bytes;
msg += bytes;
-   si = channel->cookie_high;
-   di = channel->cookie_low;
-
-   VMW_PORT(VMW_PORT_CMD_MSG | (MSG_TYPE_SENDPAYLOAD << 16),
-word, si, di,
-channel->channel_id << 16,
-VMW_HYPERVISOR_MAGIC,
-eax, ebx, ecx, edx, si, di);
+
+   vmware_hypercall5(VMW_PORT_CMD_MSG |
+ (MSG_TYPE_SENDPAYLOAD << 16),
+ word, channel->channel_id << 16,
+ channel->cookie_high,
+   

[PATCH v5 4/7] input/vmmouse: Use VMware hypercall API

[Alexey Makhalov]

Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Zack Rusin 
Acked-by: Dmitry Torokhov 
---
 drivers/input/mouse/vmmouse.c | 78 ++-
 1 file changed, 22 insertions(+), 56 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index ad94c835ee66..fb1d986a6895 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -21,19 +21,16 @@
 #include "psmouse.h"
 #include "vmmouse.h"
 
-#define VMMOUSE_PROTO_MAGIC0x564D5868U
-
 /*
  * Main commands supported by the vmmouse hypervisor port.
  */
-#define VMMOUSE_PROTO_CMD_GETVERSION   10
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_DATA  39
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_STATUS40
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_COMMAND   41
-#define VMMOUSE_PROTO_CMD_ABSPOINTER_RESTRICT   86
+#define VMWARE_CMD_ABSPOINTER_DATA 39
+#define VMWARE_CMD_ABSPOINTER_STATUS   40
+#define VMWARE_CMD_ABSPOINTER_COMMAND  41
+#define VMWARE_CMD_ABSPOINTER_RESTRICT 86
 
 /*
- * Subcommands for VMMOUSE_PROTO_CMD_ABSPOINTER_COMMAND
+ * Subcommands for VMWARE_CMD_ABSPOINTER_COMMAND
  */
 #define VMMOUSE_CMD_ENABLE 0x45414552U
 #define VMMOUSE_CMD_DISABLE0x00f5U
@@ -76,30 +73,6 @@ struct vmmouse_data {
char dev_name[128];
 };
 
-/*
- * Hypervisor-specific bi-directional communication channel
- * implementing the vmmouse protocol. Should never execute on
- * bare metal hardware.
- */
-#define VMMOUSE_CMD(cmd, in1, out1, out2, out3, out4)  \
-({ \
-   unsigned long __dummy1, __dummy2;   \
-   __asm__ __volatile__ (VMWARE_HYPERCALL :\
-   "=a"(out1), \
-   "=b"(out2), \
-   "=c"(out3), \
-   "=d"(out4), \
-   "=S"(__dummy1), \
-   "=D"(__dummy2) :\
- [port] "i" (VMWARE_HYPERVISOR_PORT),  \
- [mode] "m" (vmware_hypercall_mode),   \
-   "a"(VMMOUSE_PROTO_MAGIC),   \
-   "b"(in1),   \
-   "c"(VMMOUSE_PROTO_CMD_##cmd),   \
-   "d"(0) :\
-   "memory");  \
-})
-
 /**
  * vmmouse_report_button - report button state on the correct input device
  *
@@ -147,14 +120,12 @@ static psmouse_ret_t vmmouse_report_events(struct psmouse 
*psmouse)
struct input_dev *abs_dev = priv->abs_dev;
struct input_dev *pref_dev;
u32 status, x, y, z;
-   u32 dummy1, dummy2, dummy3;
unsigned int queue_length;
unsigned int count = 255;
 
while (count--) {
/* See if we have motion data. */
-   VMMOUSE_CMD(ABSPOINTER_STATUS, 0,
-   status, dummy1, dummy2, dummy3);
+   status = vmware_hypercall1(VMWARE_CMD_ABSPOINTER_STATUS, 0);
if ((status & VMMOUSE_ERROR) == VMMOUSE_ERROR) {
psmouse_err(psmouse, "failed to fetch status data\n");
/*
@@ -174,7 +145,8 @@ static psmouse_ret_t vmmouse_report_events(struct psmouse 
*psmouse)
}
 
/* Now get it */
-   VMMOUSE_CMD(ABSPOINTER_DATA, 4, status, x, y, z);
+   status = vmware_hypercall4(VMWARE_CMD_ABSPOINTER_DATA, 4,
+  , , );
 
/*
 * And report what we've got. Prefer to report button
@@ -249,14 +221,10 @@ static psmouse_ret_t vmmouse_process_byte(struct psmouse 
*psmouse)
 static void vmmouse_disable(struct psmouse *psmouse)
 {
u32 status;
-   u32 dummy1, dummy2, dummy3, dummy4;
-
-   VMMOUSE_CMD(ABSPOINTER_COMMAND, VMMOUSE_CMD_DISABLE,
-   dummy1, dummy2, dummy3, dummy4);
 
-   VMMOUSE_CMD(ABSPOINTER_STATUS, 0,
-   status, dummy1, dummy2, dummy3);
+   vmware_hypercall1(VMWARE_CMD_ABSPOINTER_COMMAND, VMMOUSE_CMD_DISABLE);
 
+   status = vmware_hypercall1(VMWARE_CMD_ABSPOINTER_STATUS, 0);
if ((status & VMMOUSE_ERROR) != VMMOUSE_ERROR)
psmouse_warn(psmouse, "failed to disable vmmouse device\n");
 }
@@ -273,26 +241,24 @@ static void vmmouse_disable(struct psmouse *psmouse)
 static int vmmouse_enable(struct psmouse *psmouse)
 {
u32 status, version;
-   u32 dummy1, dummy2, dummy3, dummy4;
 
/*
 * Try enabling the device. If successful, we should be able to
 * read valid version ID back from it.
 */
-   VMMOUSE_CMD(ABSPOINTER_COMMAND, 

[PATCH v5 3/7] ptp/vmware: Use VMware hypercall API

[Alexey Makhalov]

Switch from VMWARE_HYPERCALL macro to vmware_hypercall API.
Eliminate arch specific code. No functional changes intended.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Jeff Sipek 
---
 drivers/ptp/ptp_vmw.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/ptp/ptp_vmw.c b/drivers/ptp/ptp_vmw.c
index 279d191d2df9..e5bb521b9b82 100644
--- a/drivers/ptp/ptp_vmw.c
+++ b/drivers/ptp/ptp_vmw.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 
-#define VMWARE_MAGIC 0x564D5868
 #define VMWARE_CMD_PCLK(nr) ((nr << 16) | 97)
 #define VMWARE_CMD_PCLK_GETTIME VMWARE_CMD_PCLK(0)
 
@@ -24,17 +23,10 @@ static struct ptp_clock *ptp_vmw_clock;
 
 static int ptp_vmw_pclk_read(u64 *ns)
 {
-   u32 ret, nsec_hi, nsec_lo, unused1, unused2, unused3;
-
-   asm volatile (VMWARE_HYPERCALL :
-   "=a"(ret), "=b"(nsec_hi), "=c"(nsec_lo), "=d"(unused1),
-   "=S"(unused2), "=D"(unused3) :
-   [port] "i" (VMWARE_HYPERVISOR_PORT),
-   [mode] "m" (vmware_hypercall_mode),
-   "a"(VMWARE_MAGIC), "b"(0),
-   "c"(VMWARE_CMD_PCLK_GETTIME), "d"(0) :
-   "memory");
+   u32 ret, nsec_hi, nsec_lo;
 
+   ret = vmware_hypercall3(VMWARE_CMD_PCLK_GETTIME, 0,
+   _hi, _lo);
if (ret == 0)
*ns = ((u64)nsec_hi << 32) | nsec_lo;
return ret;
-- 
2.39.0

[PATCH v5 2/7] x86/vmware: Introduce VMware hypercall API

[Alexey Makhalov]

Introduce vmware_hypercall family of functions. It is a common
implementation to be used by the VMware guest code and virtual
device drivers in architecture independent manner.

The API consists of vmware_hypercallX and vmware_hypercall_hb_{out,in}
set of functions by analogy with KVM hypercall API. Architecture
specific implementation is hidden inside.

It will simplify future enhancements in VMware hypercalls such
as SEV-ES and TDX related changes without needs to modify a
caller in device drivers code.

Current implementation extends an idea from commit bac7b4e84323
("x86/vmware: Update platform detection code for VMCALL/VMMCALL
hypercalls") to have a slow, but safe path in VMWARE_HYPERCALL
earlier during the boot when alternatives are not yet applied.
This logic was inherited from VMWARE_CMD from the commit mentioned
above. Default alternative code was optimized by size to reduce
excessive nop alignment once alternatives are applied. Total
default code size is 26 bytes, in worse case (3 bytes alternative)
remaining 23 bytes will be aligned by only 3 long NOP instructions.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
Reviewed-by: Jeff Sipek 
---
 arch/x86/include/asm/vmware.h   | 288 +++-
 arch/x86/kernel/cpu/vmware.c|  35 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_x86.h |   6 +-
 drivers/input/mouse/vmmouse.c   |   2 +
 drivers/ptp/ptp_vmw.c   |   2 +
 5 files changed, 252 insertions(+), 81 deletions(-)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index de257611..2ac87068184a 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -7,14 +7,37 @@
 #include 
 
 /*
- * The hypercall definitions differ in the low word of the %edx argument
+ * VMware hypercall ABI.
+ *
+ * - Low bandwidth (LB) hypercalls (I/O port based, vmcall and vmmcall)
+ * have up to 6 input and 6 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg2 - Hypercall command
+ * arg3 bits [15:0] - Port number, LB and direction flags
+ *
+ * - High bandwidth (HB) hypercalls are I/O port based only. They have
+ * up to 7 input and 7 output arguments passed and returned using
+ * registers: %eax (arg0), %ebx (arg1), %ecx (arg2), %edx (arg3),
+ * %esi (arg4), %edi (arg5), %ebp (arg6).
+ * The following input arguments must be initialized by the caller:
+ * arg0 - VMWARE_HYPERVISOR_MAGIC
+ * arg1 - Hypercall command
+ * arg3 bits [15:0] - Port number, HB and direction flags
+ *
+ * For compatibility purposes, x86_64 systems use only lower 32 bits
+ * for input and output arguments.
+ *
+ * The hypercall definitions differ in the low word of the %edx (arg3)
  * in the following way: the old I/O port based interface uses the port
  * number to distinguish between high- and low bandwidth versions, and
  * uses IN/OUT instructions to define transfer direction.
  *
  * The new vmcall interface instead uses a set of flags to select
  * bandwidth mode and transfer direction. The flags should be loaded
- * into %dx by any user and are automatically replaced by the port
+ * into arg3 by any user and are automatically replaced by the port
  * number if the I/O port method is used.
  */
 
@@ -37,69 +60,218 @@
 
 extern u8 vmware_hypercall_mode;
 
-/* The low bandwidth call. The low word of edx is presumed clear. */
-#define VMWARE_HYPERCALL   \
-   ALTERNATIVE_2("movw $" __stringify(VMWARE_HYPERVISOR_PORT) ", %%dx; " \
- "inl (%%dx), %%eax",  \
- "vmcall", X86_FEATURE_VMCALL, \
- "vmmcall", X86_FEATURE_VMW_VMMCALL)
-
 /*
- * The high bandwidth out call. The low word of edx is presumed to have the
- * HB and OUT bits set.
+ * The low bandwidth call. The low word of %edx is presumed to have OUT bit
+ * set. The high word of %edx may contain input data from the caller.
  */
-#define VMWARE_HYPERCALL_HB_OUT
\
-   ALTERNATIVE_2("movw $" __stringify(VMWARE_HYPERVISOR_PORT_HB) ", %%dx; 
" \
- "rep outsb",  \
+#define VMWARE_HYPERCALL   \
+   ALTERNATIVE_3("cmpb $"  \
+   __stringify(CPUID_VMWARE_FEATURES_ECX_VMMCALL)  \
+   ", %[mode]\n\t" \
+ "jg 2f\n\t"   \
+ "je 1f\n\t"   \
+ "movw %[port], %%dx\n\t"  \
+ "inl (%%dx), %%eax\n\t" 

[PATCH v5 1/7] x86/vmware: Move common macros to vmware.h

[Alexey Makhalov]

Move VMware hypercall macros to vmware.h. This is a prerequisite for
the introduction of vmware_hypercall API. No functional changes besides
exporting vmware_hypercall_mode symbol.

Signed-off-by: Alexey Makhalov 
Reviewed-by: Nadav Amit 
---
 arch/x86/include/asm/vmware.h | 72 +--
 arch/x86/kernel/cpu/vmware.c  | 57 +++
 2 files changed, 66 insertions(+), 63 deletions(-)

diff --git a/arch/x86/include/asm/vmware.h b/arch/x86/include/asm/vmware.h
index ac9fc51e2b18..de257611 100644
--- a/arch/x86/include/asm/vmware.h
+++ b/arch/x86/include/asm/vmware.h
@@ -8,25 +8,34 @@
 
 /*
  * The hypercall definitions differ in the low word of the %edx argument
- * in the following way: the old port base interface uses the port
- * number to distinguish between high- and low bandwidth versions.
+ * in the following way: the old I/O port based interface uses the port
+ * number to distinguish between high- and low bandwidth versions, and
+ * uses IN/OUT instructions to define transfer direction.
  *
  * The new vmcall interface instead uses a set of flags to select
  * bandwidth mode and transfer direction. The flags should be loaded
  * into %dx by any user and are automatically replaced by the port
- * number if the VMWARE_HYPERVISOR_PORT method is used.
- *
- * In short, new driver code should strictly use the new definition of
- * %dx content.
+ * number if the I/O port method is used.
  */
 
-/* Old port-based version */
-#define VMWARE_HYPERVISOR_PORT0x5658
-#define VMWARE_HYPERVISOR_PORT_HB 0x5659
+#define VMWARE_HYPERVISOR_HB   BIT(0)
+#define VMWARE_HYPERVISOR_OUT  BIT(1)
+
+#define VMWARE_HYPERVISOR_PORT 0x5658
+#define VMWARE_HYPERVISOR_PORT_HB  (VMWARE_HYPERVISOR_PORT | \
+VMWARE_HYPERVISOR_HB)
+
+#define VMWARE_HYPERVISOR_MAGIC0x564d5868U
+
+#define VMWARE_CMD_GETVERSION  10
+#define VMWARE_CMD_GETHZ   45
+#define VMWARE_CMD_GETVCPU_INFO68
+#define VMWARE_CMD_STEALCLOCK  91
+
+#define CPUID_VMWARE_FEATURES_ECX_VMMCALL  BIT(0)
+#define CPUID_VMWARE_FEATURES_ECX_VMCALL   BIT(1)
 
-/* Current vmcall / vmmcall version */
-#define VMWARE_HYPERVISOR_HB   BIT(0)
-#define VMWARE_HYPERVISOR_OUT  BIT(1)
+extern u8 vmware_hypercall_mode;
 
 /* The low bandwidth call. The low word of edx is presumed clear. */
 #define VMWARE_HYPERCALL   \
@@ -54,4 +63,43 @@
  "rep insb",   \
  "vmcall", X86_FEATURE_VMCALL, \
  "vmmcall", X86_FEATURE_VMW_VMMCALL)
+
+#define VMWARE_PORT(cmd, eax, ebx, ecx, edx)   \
+   __asm__("inl (%%dx), %%eax" :   \
+   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
+   "a"(VMWARE_HYPERVISOR_MAGIC),   \
+   "c"(VMWARE_CMD_##cmd),  \
+   "d"(VMWARE_HYPERVISOR_PORT), "b"(UINT_MAX) :\
+   "memory")
+
+#define VMWARE_VMCALL(cmd, eax, ebx, ecx, edx) \
+   __asm__("vmcall" :  \
+   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
+   "a"(VMWARE_HYPERVISOR_MAGIC),   \
+   "c"(VMWARE_CMD_##cmd),  \
+   "d"(0), "b"(UINT_MAX) : \
+   "memory")
+
+#define VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx)
\
+   __asm__("vmmcall" : \
+   "=a"(eax), "=c"(ecx), "=d"(edx), "=b"(ebx) :\
+   "a"(VMWARE_HYPERVISOR_MAGIC),   \
+   "c"(VMWARE_CMD_##cmd),  \
+   "d"(0), "b"(UINT_MAX) : \
+   "memory")
+
+#define VMWARE_CMD(cmd, eax, ebx, ecx, edx) do {   \
+   switch (vmware_hypercall_mode) {\
+   case CPUID_VMWARE_FEATURES_ECX_VMCALL:  \
+   VMWARE_VMCALL(cmd, eax, ebx, ecx, edx); \
+   break;  \
+   case CPUID_VMWARE_FEATURES_ECX_VMMCALL: \
+   VMWARE_VMMCALL(cmd, eax, ebx, ecx, edx);\
+   break;  \
+   default:\
+   VMWARE_PORT(cmd, eax, ebx, ecx, edx);   \
+   break;  \
+   }   \
+   } while (0)
+
 #endif
diff --git 

[PATCH v5 0/7] VMware hypercalls enhancements

[Alexey Makhalov]

VMware hypercalls invocations were all spread out across the kernel
implementing same ABI as in-place asm-inline. With encrypted memory
and confidential computing it became harder to maintain every changes
in these hypercall implementations.

Intention of this patchset is to introduce arch independent VMware
hypercall API layer other subsystems such as device drivers can call
to, while hiding architecture specific implementation behind.

Second patch introduces the vmware_hypercall low and high bandwidth
families of functions, with little enhancements there.
Sixth patch adds tdx hypercall support

arm64 implementation of vmware_hypercalls is in drivers/gpu/drm/
vmwgfx/vmwgfx_msg_arm64.h and going to be moved to arch/arm64 with
a separate patchset with the introduction of VMware Linux guest
support for arm64.

No functional changes in drivers/input/mouse/vmmouse.c and
drivers/ptp/ptp_vmw.c

v4->v5 changes:
  [patch 2]:
- Fixed the problem reported by Simon Horman where build fails after
  patch 2 application. Do not undefine VMWARE_HYPERCALL for now, and
  update vmwgfx, vmmouse and ptp_vmw code for new VMWARE_HYPERCALL macro.
- Introduce new patch 6 to undefine VMWARE_HYPERCALL, which is safe to do
  after patches 3 to 5.
- [patch 7 (former patch 6)]: Add missing r15 (CPL) initialization.

v3->v4 changes: (no functional changes in patches 1-5)
  [patch 2]:
- Added the comment with VMware hypercall ABI description.
  [patch 6]:
- vmware_tdx_hypercall_args remove in6/out6 arguments as excessive.
- vmware_tdx_hypercall return ULONG_MAX on error to mimic bad hypercall
  command error from the hypervisor.
- Replaced pr_warn by pr_warn_once as pointed by Kirill Shutemov.
- Fixed the warning reported by Intel's kernel test robot.
- Added the comment describing VMware TDX hypercall ABI.

v2->v3 changes: (no functional changes in patches 1-5)
- Improved commit message in patches 1, 2 and 5 as was suggested by
  Borislav Petkov.
- To address Dave Hansen's concern, patch 6 was reorganized to avoid
  exporting bare __tdx_hypercall and to make exported vmware_tdx_hypercall
  VMWare guest specific.

v1->v2 changes (no functional changes):
- Improved commit message in patches 2 and 5.
- Added Reviewed-by for all patches.
- Added Ack from Dmitry Torokhov in patch 4. No fixes regarding reported
  by Simon Horman gcc error in this patch.

Alexey Makhalov (7):
  x86/vmware: Move common macros to vmware.h
  x86/vmware: Introduce VMware hypercall API
  ptp/vmware: Use VMware hypercall API
  input/vmmouse: Use VMware hypercall API
  drm/vmwgfx: Use VMware hypercall API
  x86/vmware: Undefine VMWARE_HYPERCALL
  x86/vmware: Add TDX hypercall support

 arch/x86/include/asm/vmware.h | 364 --
 arch/x86/kernel/cpu/vmware.c  | 117 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c   | 173 --
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_arm64.h | 197 
 drivers/gpu/drm/vmwgfx/vmwgfx_msg_x86.h   | 185 ---
 drivers/input/mouse/vmmouse.c |  76 ++---
 drivers/ptp/ptp_vmw.c |  12 +-
 7 files changed, 599 insertions(+), 525 deletions(-)

-- 
2.39.0

Re: [PATCH v3 0/7] dma-buf: heaps: Add secure heap

[吴勇]

On Fri, 2024-01-05 at 10:35 +0100, Christian König wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Am 04.01.24 um 20:50 schrieb Jeffrey Kardatzke:
> > Any feedback from maintainers on what their preference is?  I'm
> fine
> > with 'restricted' as well, but the main reason we chose secure was
> > because of its use in ARM nomenclature and this is more for ARM
> usage
> > than x86.
> 
> Well AMD calls this "trusted", but I think that's just slightly
> better 
> than "secure".
> 
> +1 for using "restricted" cause that seems to match the technical 
> consequences.

Thanks you all for the discussion and the conclusion. I will send v4 in
this week with "restricted".

> 
> Regards,
> Christian.
> 
> >
> > The main difference with similar buffers on AMD/Intel is that with
> > AMD/Intel the buffers are mappable and readable by the CPU in the
> > kernel. The problem is their contents are encrypted so you get junk
> > back if you do that. On ARM, the buffers are completely
> inaccessible
> > by the kernel and the memory controller prevents access to them
> > completely from the kernel.
> >
> > There are also other use cases for this where the hypervisor is
> what
> > is controlling access (second stage in the MMU is providing
> > isolation)and in that case I do agree that 'secure' would not
> be
> > the right terminology for those types of buffers.   So I do agree
> > something other than 'secure' is probably a better option overall.
> >
> >
> > On Fri, Dec 22, 2023 at 1:40 AM Simon Ser 
> wrote:
> >> On Wednesday, December 13th, 2023 at 15:16, Pekka Paalanen <
> ppaala...@gmail.com> wrote:
> >>
> > It is protected/shielded/fortified from all the kernel and
> userspace,
> > but a more familiar word to describe that is inaccessible.
> > "Inaccessible buffer" per se OTOH sounds like a useless
> concept.
> >
> > It is not secure, because it does not involve security in any
> way. In
> > fact, given it's so fragile, I'd classify it as mildly opposite
> of
> > secure, as e.g. clients of a Wayland compositor can potentially
> DoS the
> > compositor with it by simply sending such a dmabuf. Or DoS the
> whole
> > system.
>  I hear what you are saying and DoS is a known problem and attack
> vector,
>  but regardless, we have use cases where we don't want to expose
>  information in the clear and where we also would like to have
> some
>  guarantees about correctness. That is where various secure
> elements and
>  more generally security is needed.
> 
>  So, it sounds like we have two things here, the first is the
> naming and
>  the meaning behind it. I'm pretty sure the people following and
>  contributing to this thread can agree on a name that makes
> sense. Would
>  you personally be OK with "restricted" as the name? It sounds
> like that.
> >>> I would. I'm also just a by-stander, not a maintainer of kernel
> >>> anything. I have no power to accept nor reject anything here.
> >> I'd also personally be OK with "restricted", I think it's a lot
> better
> >> than "secure".
> >>
> >> In general I agree with everything Pekka said.
> 

Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices

[Yan Zhao]

On Mon, Jan 08, 2024 at 08:22:20PM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 09, 2024 at 07:36:22AM +0800, Yan Zhao wrote:
> > On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > > > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > > > On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > > > > > This series allow user space to notify KVM of noncoherent DMA 
> > > > > > status so as
> > > > > > to let KVM honor guest memory types in specified memory slot ranges.
> > > > > > 
> > > > > > Motivation
> > > > > > ===
> > > > > > A virtio GPU device may want to configure GPU hardware to work in
> > > > > > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
> > > > > 
> > > > > Does this mean some DMA reads do not snoop the caches or does it
> > > > > include DMA writes not synchronizing the caches too?
> > > > Both DMA reads and writes are not snooped.
> > > 
> > > Oh that sounds really dangerous.
> > >
> > But the IOMMU for Intel GPU does not do force-snoop, no matter KVM
> > honors guest memory type or not.
> 
> Yes, I know. Sounds dangerous!
> 
> > > Not just migration. Any point where KVM revokes the page from the
> > > VM. Ie just tearing down the VM still has to make the cache coherent
> > > with physical or there may be problems.
> > Not sure what's the mentioned problem during KVM revoking.
> > In host,
> > - If the memory type is WB, as the case in intel GPU passthrough,
> >   the mismatch can only happen when guest memory type is UC/WC/WT/WP, all
> >   stronger than WB.
> >   So, even after KVM revoking the page, the host will not get delayed
> >   data from cache.
> > - If the memory type is WC, as the case in virtio GPU, after KVM revoking
> >   the page, the page is still hold in the virtio host side.
> >   Even though a incooperative guest can cause wrong data in the page,
> >   the guest can achieve the purpose in a more straight-forward way, i.e.
> >   writing a wrong data directly to the page.
> >   So, I don't see the problem in this case too.
> 
> You can't let cache incoherent memory leak back into the hypervisor
> for other uses or who knows what can happen. In many cases something
> will zero the page and you can probably reliably argue that will make
> the cache coherent, but there are still all sorts of cases where pages
> are write protected and then used in the hypervisor context. Eg page
> out or something where the incoherence is a big problem.
> 
> eg RAID parity and mirror calculations become at-rist of
> malfunction. Storage CRCs stop working reliably, etc, etc.
> 
> It is certainly a big enough problem that a generic KVM switch to
> allow incoherence should be trated with alot of skepticism. You can't
> argue that the only use of the generic switch will be with GPUs that
> exclude all the troublesome cases!
>
You are right. It's more safe with only one view of memory.
But even something will zero the page, if it happens before returning
the page to host, looks the impact is constrained in VM scope? e.g.
for the write protected page, hypervisor cannot rely on the page content
is correct or expected.

For virtio GPU's use case, do you think a better way for KVM is to pull
the memory type from host page table in the specified memslot?

But for noncoherent DMA device passthrough, we can't pull host memory
type, because we rely on guest device driver to do cache flush
properly, and if the guest device driver thinks a memory is uncached
while it's effectively cached, the device cannot work properly.

> > > > In this case, will this security attack impact other guests?
> > > 
> > > It impacts the hypervisor potentially. It depends..
> > Could you elaborate more on how it will impact hypervisor?
> > We can try to fix it if it's really a case.
> 
> Well, for instance, when you install pages into the KVM the hypervisor
> will have taken kernel memory, then zero'd it with cachable writes,
> however the VM can read it incoherently with DMA and access the
> pre-zero'd data since the zero'd writes potentially hasn't left the
> cache. That is an information leakage exploit.
This makes sense.
How about KVM doing cache flush before installing/revoking the
page if guest memory type is honored?

> Who knows what else you can get up to if you are creative. The whole
> security model assumes there is only one view of memory, not two.
> 

Re: [PATCH] drm/ci: Add msm tests

[Rob Clark]

On Mon, Jan 8, 2024 at 2:58 PM Abhinav Kumar  wrote:
>
>
>
> On 1/8/2024 11:50 AM, Rob Clark wrote:
> > From: Rob Clark 
> >
> > The msm tests should skip on non-msm hw, so I think it should be safe to
> > enable everywhere.
> >
> > Signed-off-by: Rob Clark 
> > ---
> >   drivers/gpu/drm/ci/testlist.txt | 49 +
> >   1 file changed, 49 insertions(+)
> >
>
> I do see that all these tests use igt_msm_dev_open() to make sure it
> opens only the MSM card.
>
> But if igt_msm_dev_open() fails, I dont see a igt_require() on some of
> the tests to skip them. So how will it safely skip on non-msm HW?
>
> Unless i am missing something here 

hmm, at the time I added the initial msm tests, and
igt_msm_dev_open(), I verified that they skipped on intel.. but since
then I'd switched from intel to sc8280xp device for primary dev
device, so I'd need to re-test to remember how it works.  If these
aren't skipping on !msm, it is a bug

BR,
-R

> > diff --git a/drivers/gpu/drm/ci/testlist.txt 
> > b/drivers/gpu/drm/ci/testlist.txt
> > index f82cd90372f4..eaeb751bb0ad 100644
> > --- a/drivers/gpu/drm/ci/testlist.txt
> > +++ b/drivers/gpu/drm/ci/testlist.txt
> > @@ -2910,3 +2910,52 @@ kms_writeback@writeback-invalid-parameters
> >   kms_writeback@writeback-fb-id
> >   kms_writeback@writeback-check-output
> >   prime_mmap_kms@buffer-sharing
> > +msm_shrink@copy-gpu-sanitycheck-8
> > +msm_shrink@copy-gpu-sanitycheck-32
> > +msm_shrink@copy-gpu-8
> > +msm_shrink@copy-gpu-32
> > +msm_shrink@copy-gpu-madvise-8
> > +msm_shrink@copy-gpu-madvise-32
> > +msm_shrink@copy-gpu-oom-8
> > +msm_shrink@copy-gpu-oom-32
> > +msm_shrink@copy-mmap-sanitycheck-8
> > +msm_shrink@copy-mmap-sanitycheck-32
> > +msm_shrink@copy-mmap-8
> > +msm_shrink@copy-mmap-32
> > +msm_shrink@copy-mmap-madvise-8
> > +msm_shrink@copy-mmap-madvise-32
> > +msm_shrink@copy-mmap-oom-8
> > +msm_shrink@copy-mmap-oom-32
> > +msm_shrink@copy-mmap-dmabuf-sanitycheck-8
> > +msm_shrink@copy-mmap-dmabuf-sanitycheck-32
> > +msm_shrink@copy-mmap-dmabuf-8
> > +msm_shrink@copy-mmap-dmabuf-32
> > +msm_shrink@copy-mmap-dmabuf-madvise-8
> > +msm_shrink@copy-mmap-dmabuf-madvise-32
> > +msm_shrink@copy-mmap-dmabuf-oom-8
> > +msm_shrink@copy-mmap-dmabuf-oom-32
> > +msm_mapping@ring
> > +msm_mapping@sqefw
> > +msm_mapping@shadow
> > +msm_submitoverhead@submitbench-10-bos
> > +msm_submitoverhead@submitbench-10-bos-no-implicit-sync
> > +msm_submitoverhead@submitbench-100-bos
> > +msm_submitoverhead@submitbench-100-bos-no-implicit-sync
> > +msm_submitoverhead@submitbench-250-bos
> > +msm_submitoverhead@submitbench-250-bos-no-implicit-sync
> > +msm_submitoverhead@submitbench-500-bos
> > +msm_submitoverhead@submitbench-500-bos-no-implicit-sync
> > +msm_submitoverhead@submitbench-1000-bos
> > +msm_submitoverhead@submitbench-1000-bos-no-implicit-sync
> > +msm_recovery@hangcheck
> > +msm_recovery@gpu-fault
> > +msm_recovery@gpu-fault-parallel
> > +msm_recovery@iova-fault
> > +msm_submit@empty-submit
> > +msm_submit@invalid-queue-submit
> > +msm_submit@invalid-flags-submit
> > +msm_submit@invalid-in-fence-submit
> > +msm_submit@invalid-duplicate-bo-submit
> > +msm_submit@invalid-cmd-idx-submit
> > +msm_submit@invalid-cmd-type-submit
> > +msm_submit@valid-submit

回复: Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2

[李真能]

When the priority value is passed to the kernel, the kernel compares it with the following values:
#define AMDGPU_CTX_PRIORITY_VERY_LOW    -1023#define AMDGPU_CTX_PRIORITY_LOW -512#define AMDGPU_CTX_PRIORITY_NORMAL  0#define AMDGPU_CTX_PRIORITY_HIGH    512#define AMDGPU_CTX_PRIORITY_VERY_HIGH   1023
If priority is uint32_t, we can't set LOW and VERY_LOW value to kernel context priority,
You can refer to the kernel function amdgpu_ctx_priority_permit, if priority is greater
than 0, and this process has not  CAP_SYS_NICE capibility or DRM_MASTER permission,
this process will be exited.

 

主　题：Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2 日　期：2024-01-09 00:28 发件人：Christian König 收件人：李真能;Marek Olsak;Pierre-Eric Pelloux-Prayer;dri-devel;amd-gfx;



Am 08.01.24 um 10:40 schrieb Zhenneng Li:> In order to pass the correct priority parameter to the kernel,> we must change priority type from uint32_t to int32_t.Hui what? Why should it matter if the parameter is signed or not?That doesn't seem to make sense.Regards,Christian.>> Signed-off-by: Zhenneng Li > ---> amdgpu/amdgpu.h | 2 +-> amdgpu/amdgpu_cs.c | 2 +-> 2 files changed, 2 insertions(+), 2 deletions(-)>> diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h> index 9bdbf366..f46753f3 100644> --- a/amdgpu/amdgpu.h> +++ b/amdgpu/amdgpu.h> @@ -896,7 +896,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle handle,> *> */> int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,> - uint32_t priority,> + int32_t priority,> amdgpu_context_handle *context);> /**> * Create GPU execution Context> diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c> index 49fc16c3..eb72c638 100644> --- a/amdgpu/amdgpu_cs.c> +++ b/amdgpu/amdgpu_cs.c> @@ -49,7 +49,7 @@ static int amdgpu_cs_reset_sem(amdgpu_semaphore_handle sem);> * \return 0 on success otherwise POSIX Error code> */> drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,> - uint32_t priority,> + int32_t priority,> amdgpu_context_handle *context)> {> struct amdgpu_context *gpu_context;

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/display/intel_dp.c

between commit:

  fc93835bb0d7 ("drm: Add HPD state to drm_connector_oob_hotplug_event()")

from Linus' tree and commit:

  cd572b3bb27e ("drm/i915: Disable hotplug detection works during driver 
init/shutdown")

from the drm-intel tree.

I fixed it up (maybe, see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/display/intel_dp.c
index 7d2b8ce48fda,93f9985ef75c..
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@@ -6040,21 -6062,11 +6059,21 @@@ static void intel_dp_oob_hotplug_event(
  {
struct intel_encoder *encoder = 
intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(connector->dev);
 +  bool hpd_high = hpd_state == connector_status_connected;
 +  unsigned int hpd_pin = encoder->hpd_pin;
 +  bool need_work = false;
  
spin_lock_irq(>irq_lock);
 -  i915->display.hotplug.event_bits |= BIT(encoder->hpd_pin);
 +  if (hpd_high != test_bit(hpd_pin, 
>display.hotplug.oob_hotplug_last_state)) {
 +  i915->display.hotplug.event_bits |= BIT(hpd_pin);
 +
 +  __assign_bit(hpd_pin, 
>display.hotplug.oob_hotplug_last_state, hpd_high);
 +  need_work = true;
 +  }
spin_unlock_irq(>irq_lock);
 -  intel_hpd_schedule_detection(i915);
 +
 +  if (need_work)
-   queue_delayed_work(i915->unordered_wq, 
>display.hotplug.hotplug_work, 0);
++  intel_hpd_schedule_detection(i915);
  }
  
  static const struct drm_connector_funcs intel_dp_connector_funcs = {


pgp5Nm6jPc4dK.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices

[Jason Gunthorpe]

On Tue, Jan 09, 2024 at 07:36:22AM +0800, Yan Zhao wrote:
> On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > > On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > > > > This series allow user space to notify KVM of noncoherent DMA status 
> > > > > so as
> > > > > to let KVM honor guest memory types in specified memory slot ranges.
> > > > > 
> > > > > Motivation
> > > > > ===
> > > > > A virtio GPU device may want to configure GPU hardware to work in
> > > > > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
> > > > 
> > > > Does this mean some DMA reads do not snoop the caches or does it
> > > > include DMA writes not synchronizing the caches too?
> > > Both DMA reads and writes are not snooped.
> > 
> > Oh that sounds really dangerous.
> >
> But the IOMMU for Intel GPU does not do force-snoop, no matter KVM
> honors guest memory type or not.

Yes, I know. Sounds dangerous!

> > Not just migration. Any point where KVM revokes the page from the
> > VM. Ie just tearing down the VM still has to make the cache coherent
> > with physical or there may be problems.
> Not sure what's the mentioned problem during KVM revoking.
> In host,
> - If the memory type is WB, as the case in intel GPU passthrough,
>   the mismatch can only happen when guest memory type is UC/WC/WT/WP, all
>   stronger than WB.
>   So, even after KVM revoking the page, the host will not get delayed
>   data from cache.
> - If the memory type is WC, as the case in virtio GPU, after KVM revoking
>   the page, the page is still hold in the virtio host side.
>   Even though a incooperative guest can cause wrong data in the page,
>   the guest can achieve the purpose in a more straight-forward way, i.e.
>   writing a wrong data directly to the page.
>   So, I don't see the problem in this case too.

You can't let cache incoherent memory leak back into the hypervisor
for other uses or who knows what can happen. In many cases something
will zero the page and you can probably reliably argue that will make
the cache coherent, but there are still all sorts of cases where pages
are write protected and then used in the hypervisor context. Eg page
out or something where the incoherence is a big problem.

eg RAID parity and mirror calculations become at-rist of
malfunction. Storage CRCs stop working reliably, etc, etc.

It is certainly a big enough problem that a generic KVM switch to
allow incoherence should be trated with alot of skepticism. You can't
argue that the only use of the generic switch will be with GPUs that
exclude all the troublesome cases!

> > > In this case, will this security attack impact other guests?
> > 
> > It impacts the hypervisor potentially. It depends..
> Could you elaborate more on how it will impact hypervisor?
> We can try to fix it if it's really a case.

Well, for instance, when you install pages into the KVM the hypervisor
will have taken kernel memory, then zero'd it with cachable writes,
however the VM can read it incoherently with DMA and access the
pre-zero'd data since the zero'd writes potentially hasn't left the
cache. That is an information leakage exploit.

Who knows what else you can get up to if you are creative. The whole
security model assumes there is only one view of memory, not two.

Jason

Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices

[Yan Zhao]

On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > > > This series allow user space to notify KVM of noncoherent DMA status so 
> > > > as
> > > > to let KVM honor guest memory types in specified memory slot ranges.
> > > > 
> > > > Motivation
> > > > ===
> > > > A virtio GPU device may want to configure GPU hardware to work in
> > > > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
> > > 
> > > Does this mean some DMA reads do not snoop the caches or does it
> > > include DMA writes not synchronizing the caches too?
> > Both DMA reads and writes are not snooped.
> 
> Oh that sounds really dangerous.
>
But the IOMMU for Intel GPU does not do force-snoop, no matter KVM
honors guest memory type or not.

> > > > This is generally for performance consideration.
> > > > In certain platform, GFX performance can improve 20+% with DMAs going to
> > > > noncoherent path.
> > > > 
> > > > This noncoherent DMA mode works in below sequence:
> > > > 1. Host backend driver programs hardware not to snoop memory of target
> > > >DMA buffer.
> > > > 2. Host backend driver indicates guest frontend driver to program guest 
> > > > PAT
> > > >to WC for target DMA buffer.
> > > > 3. Guest frontend driver writes to the DMA buffer without clflush 
> > > > stuffs.
> > > > 4. Hardware does noncoherent DMA to the target buffer.
> > > > 
> > > > In this noncoherent DMA mode, both guest and hardware regard a DMA 
> > > > buffer
> > > > as not cached. So, if KVM forces the effective memory type of this DMA
> > > > buffer to be WB, hardware DMA may read incorrect data and cause misc
> > > > failures.
> > > 
> > > I don't know all the details, but a big concern would be that the
> > > caches remain fully coherent with the underlying memory at any point
> > > where kvm decides to revoke the page from the VM.
> > Ah, you mean, for page migration, the content of the page may not be copied
> > correctly, right?
> 
> Not just migration. Any point where KVM revokes the page from the
> VM. Ie just tearing down the VM still has to make the cache coherent
> with physical or there may be problems.
Not sure what's the mentioned problem during KVM revoking.
In host,
- If the memory type is WB, as the case in intel GPU passthrough,
  the mismatch can only happen when guest memory type is UC/WC/WT/WP, all
  stronger than WB.
  So, even after KVM revoking the page, the host will not get delayed
  data from cache.
- If the memory type is WC, as the case in virtio GPU, after KVM revoking
  the page, the page is still hold in the virtio host side.
  Even though a incooperative guest can cause wrong data in the page,
  the guest can achieve the purpose in a more straight-forward way, i.e.
  writing a wrong data directly to the page.
  So, I don't see the problem in this case too.

>  
> > Currently in x86, we have 2 ways to let KVM honor guest memory types:
> > 1. through KVM memslot flag introduced in this series, for virtio GPUs, in
> >memslot granularity.
> > 2. through increasing noncoherent dma count, as what's done in VFIO, for
> >Intel GPU passthrough, for all guest memory.
> 
> And where does all this fixup the coherency problem?
> 
> > This page migration issue should not be the case for virtio GPU, as both 
> > host
> > and guest are synced to use the same memory type and actually the pages
> > are not anonymous pages.
> 
> The guest isn't required to do this so it can force the cache to
> become incoherent.
> 
> > > If you allow an incoherence of cache != physical then it opens a
> > > security attack where the observed content of memory can change when
> > > it should not.
> > 
> > In this case, will this security attack impact other guests?
> 
> It impacts the hypervisor potentially. It depends..
Could you elaborate more on how it will impact hypervisor?
We can try to fix it if it's really a case.

Re: [PATCH] drm/ci: Add msm tests

[Abhinav Kumar]

On 1/8/2024 11:50 AM, Rob Clark wrote:

From: Rob Clark 

The msm tests should skip on non-msm hw, so I think it should be safe to
enable everywhere.

Signed-off-by: Rob Clark 
---
  drivers/gpu/drm/ci/testlist.txt | 49 +
  1 file changed, 49 insertions(+)



I do see that all these tests use igt_msm_dev_open() to make sure it 
opens only the MSM card.


But if igt_msm_dev_open() fails, I dont see a igt_require() on some of 
the tests to skip them. So how will it safely skip on non-msm HW?


Unless i am missing something here 


diff --git a/drivers/gpu/drm/ci/testlist.txt b/drivers/gpu/drm/ci/testlist.txt
index f82cd90372f4..eaeb751bb0ad 100644
--- a/drivers/gpu/drm/ci/testlist.txt
+++ b/drivers/gpu/drm/ci/testlist.txt
@@ -2910,3 +2910,52 @@ kms_writeback@writeback-invalid-parameters
  kms_writeback@writeback-fb-id
  kms_writeback@writeback-check-output
  prime_mmap_kms@buffer-sharing
+msm_shrink@copy-gpu-sanitycheck-8
+msm_shrink@copy-gpu-sanitycheck-32
+msm_shrink@copy-gpu-8
+msm_shrink@copy-gpu-32
+msm_shrink@copy-gpu-madvise-8
+msm_shrink@copy-gpu-madvise-32
+msm_shrink@copy-gpu-oom-8
+msm_shrink@copy-gpu-oom-32
+msm_shrink@copy-mmap-sanitycheck-8
+msm_shrink@copy-mmap-sanitycheck-32
+msm_shrink@copy-mmap-8
+msm_shrink@copy-mmap-32
+msm_shrink@copy-mmap-madvise-8
+msm_shrink@copy-mmap-madvise-32
+msm_shrink@copy-mmap-oom-8
+msm_shrink@copy-mmap-oom-32
+msm_shrink@copy-mmap-dmabuf-sanitycheck-8
+msm_shrink@copy-mmap-dmabuf-sanitycheck-32
+msm_shrink@copy-mmap-dmabuf-8
+msm_shrink@copy-mmap-dmabuf-32
+msm_shrink@copy-mmap-dmabuf-madvise-8
+msm_shrink@copy-mmap-dmabuf-madvise-32
+msm_shrink@copy-mmap-dmabuf-oom-8
+msm_shrink@copy-mmap-dmabuf-oom-32
+msm_mapping@ring
+msm_mapping@sqefw
+msm_mapping@shadow
+msm_submitoverhead@submitbench-10-bos
+msm_submitoverhead@submitbench-10-bos-no-implicit-sync
+msm_submitoverhead@submitbench-100-bos
+msm_submitoverhead@submitbench-100-bos-no-implicit-sync
+msm_submitoverhead@submitbench-250-bos
+msm_submitoverhead@submitbench-250-bos-no-implicit-sync
+msm_submitoverhead@submitbench-500-bos
+msm_submitoverhead@submitbench-500-bos-no-implicit-sync
+msm_submitoverhead@submitbench-1000-bos
+msm_submitoverhead@submitbench-1000-bos-no-implicit-sync
+msm_recovery@hangcheck
+msm_recovery@gpu-fault
+msm_recovery@gpu-fault-parallel
+msm_recovery@iova-fault
+msm_submit@empty-submit
+msm_submit@invalid-queue-submit
+msm_submit@invalid-flags-submit
+msm_submit@invalid-in-fence-submit
+msm_submit@invalid-duplicate-bo-submit
+msm_submit@invalid-cmd-idx-submit
+msm_submit@invalid-cmd-type-submit
+msm_submit@valid-submit

Re: [PATCH] drm/bridge: parade-ps8640: Ensure bridge is suspended in .post_disable()

[Doug Anderson]

Hi,

On Wed, Dec 27, 2023 at 2:43 AM Pin-yen Lin  wrote:
>
> Disable the autosuspend of runtime PM and use completion to make sure
> ps8640_suspend() is called in ps8640_atomic_post_disable().
>
> The ps8640 bridge seems to expect everything to be power cycled at the
> disable process, but sometimes ps8640_aux_transfer() holds the runtime
> PM reference and prevents the bridge from suspend.
>
> Instead of force powering off the bridge and taking the risk of breaking
> the AUX communication, disable the autosuspend and wait for
> ps8640_suspend() being called here, and re-enable the autosuspend
> afterwards.  With this approach, the bridge should be suspended after
> the current ps8640_aux_transfer() completes.
>
> Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power 
> management")
> Signed-off-by: Pin-yen Lin 
> ---
>
>  drivers/gpu/drm/bridge/parade-ps8640.c | 33 +-
>  1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> b/drivers/gpu/drm/bridge/parade-ps8640.c
> index 8161b1a1a4b1..f8ea486a76fd 100644
> --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> @@ -107,6 +107,7 @@ struct ps8640 {
> struct device_link *link;
> bool pre_enabled;
> bool need_post_hpd_delay;
> +   struct completion suspend_completion;
>  };
>
>  static const struct regmap_config ps8640_regmap_config[] = {
> @@ -417,6 +418,8 @@ static int __maybe_unused ps8640_suspend(struct device 
> *dev)
> if (ret < 0)
> dev_err(dev, "cannot disable regulators %d\n", ret);
>
> +   complete_all(_bridge->suspend_completion);
> +
> return ret;
>  }
>
> @@ -465,11 +468,37 @@ static void ps8640_atomic_post_disable(struct 
> drm_bridge *bridge,
>struct drm_bridge_state 
> *old_bridge_state)
>  {
> struct ps8640 *ps_bridge = bridge_to_ps8640(bridge);
> +   struct device *dev = _bridge->page[PAGE0_DP_CNTL]->dev;
>
> ps_bridge->pre_enabled = false;
>
> ps8640_bridge_vdo_control(ps_bridge, DISABLE);
> -   pm_runtime_put_sync_suspend(_bridge->page[PAGE0_DP_CNTL]->dev);
> +
> +   /*
> +* The ps8640 bridge seems to expect everything to be power cycled at
> +* the disable process, but sometimes ps8640_aux_transfer() holds the
> +* runtime PM reference and prevents the bridge from suspend.
> +* Instead of force powering off the bridge and taking the risk of
> +* breaking the AUX communication, disable the autosuspend and wait 
> for
> +* ps8640_suspend() being called here, and re-enable the autosuspend
> +* afterwards.  With this approach, the bridge should be suspended 
> after
> +* the current ps8640_aux_transfer() completes.
> +*/
> +   reinit_completion(_bridge->suspend_completion);
> +   pm_runtime_dont_use_autosuspend(dev);
> +   pm_runtime_put_sync_suspend(dev);
> +
> +   /*
> +* Mostly the suspend completes under 10 ms, but sometimes it could
> +* take 708 ms to complete.  Set the timeout to 2000 ms here to be
> +* extra safe.
> +*/
> +   if (!wait_for_completion_timeout(_bridge->suspend_completion,
> +msecs_to_jiffies(2000))) {
> +   dev_warn(dev, "Failed to wait for the suspend completion\n");
> +   }
> +
> +   pm_runtime_use_autosuspend(dev);

Thanks for tracking this down! I agree with your analysis and it seems
like we've got to do something about it.

I spent a little time trying to think about a cleaner way. What do you
think about adding a "aux_transfer" mutex? You'd grab this mutex for
the entire duration of ps8640_aux_transfer() and
ps8640_atomic_post_disable(). That way you don't need the weird
completion / timeout and don't need to hackily turn off/on
autosuspend. You shouldn't need the mutex in
ps8640_wait_hpd_asserted() because that will never be called at the
same time as ps8640_atomic_post_disable().

-Doug

Re: [PATCH v3 4/5] drm/msm/dpu: move writeback's atomic_check to dpu_writeback.c

[Dmitry Baryshkov]

On Mon, 8 Jan 2024 at 23:39, Abhinav Kumar  wrote:
>
>
>
> On 12/25/2023 5:08 AM, Dmitry Baryshkov wrote:
> > dpu_encoder_phys_wb is the only user of encoder's atomic_check callback.
> > Move corresponding checks to drm_writeback_connector's implementation
> > and drop the dpu_encoder_phys_wb_atomic_check() function.
> >
> > Signed-off-by: Dmitry Baryshkov 
> > ---
> >   .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   | 54 --
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  9 ++-
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 57 ++-
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h |  3 +-
> >   4 files changed, 64 insertions(+), 59 deletions(-)
> >
>
> I am fine with this change with respect to how the code is today.
>
> Hence,
>
> Reviewed-by: Abhinav Kumar 
>
> But if we start noticing a pattern like below in dpu_encoder.c's
> atomic_check,
>
> if (INTF_WB)
> .
> else if (INTF_DP || INTF_DSI)
> .
>
> then, it will demand bringing back a phys specific callback.

The problem is that INTF_DP || INTF_DSI does not have the
phys-specific implementation. So while I agree about the INTF_WB part,
INTF_DP || INTF_DSI either should go as is, or it should be refactored
into output-specific handlers.

-- 
With best wishes
Dmitry

Re: [PATCH] nightly.conf: Add the xe repo to drm-tip

[Lucas De Marchi]

On Mon, Jan 08, 2024 at 05:13:51PM -0500, Rodrigo Vivi wrote:

On Wed, Jan 03, 2024 at 11:59:16PM -0600, Lucas De Marchi wrote:

On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote:
> On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote:
> > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote:
> > > Add the xe repo to drm-tip and the dim tools.
> > > For now use the sha1 of the first drm-xe-next pull request for drm-
> > > tip,
> > > since that branch tip is currently adapted for our CI testing.
> > >
> > > Cc: Rodrigo Vivi 
> > > Cc: Lucas De Marchi 
> > > Cc: Oded Gabbay 
> > > Cc: daniel.vet...@ffwll.ch
> > > Cc: Maarten Lankhorst 
> > > Cc: dim-to...@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: intel-...@lists.freedesktop.org
> > > Signed-off-by: Thomas Hellström 
> > > ---
> > >  nightly.conf | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/nightly.conf b/nightly.conf
> > > index 24126b61b797..accd3ff2cc39 100644
> > > --- a/nightly.conf
> > > +++ b/nightly.conf
> > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip
> > >  https://anongit.freedesktop.org/git/drm/drm-tip
> > >  https://anongit.freedesktop.org/git/drm/drm-tip.git
> > >  "
> > > +drm_tip_repos[drm-xe]="
> > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git
> > > +https://gitlab.freedesktop.org/drm/xe/kernel.git
> > > +"
> > >  drm_tip_repos[drm-intel]="
> > >  ssh://git.freedesktop.org/git/drm/drm-intel
> > >  ssh://git.freedesktop.org/git/drm-intel
> > > @@ -65,14 +69,17 @@ drm_tip_config=(
> > >  "drm   drm-fixes"
> > >  "drm-misc  drm-misc-fixes"
> > >  "drm-intel drm-intel-fixes"
> > > +"drm-xedrm-xe-fixes"
> > >  
> > >  "drm   drm-next"
> > >  "drm-misc  drm-misc-next-fixes"
> > >  "drm-intel drm-intel-next-fixes"
> > > +"drm-xedrm-xe-next-fixes"
> > >  
> > >  "drm-misc  drm-misc-next"
> > >  "drm-intel drm-intel-next"
> > >  "drm-intel drm-intel-gt-next"
> > > +"drm-xedrm-xe-next b6e1b7081768"
> >
> > yeap, up to this commit nothing else should change, but
> > then we will need an extra rebase of the rest on top of drm/drm-next.
> >
> > But then we need to decide where these following patches will live:
> > 880277f31cc69 drm/xe/guc: define LNL FW
> > 2cfc5ae1b8267 drm/xe/guc: define PVC FW
> > 52383b58eb8cf mei/hdcp: Also enable for XE
> > bea27d7369855 mei: gsc: add support for auxiliary device created by
> > Xe driver
> > fcb3410197f05 fault-inject: Include linux/types.h by default.
> > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs
> >
> >
> > Will it be the topic/core-for-CI?
> > or topic/xe-extras?
> > or what?
>
> This sounds to me like topic/core-for-CI? Or is there any drawback with
> that?

I think some of them are not really a "for CI". It's more like the
workflow we are adopting e.g. with guc/huc, not sending it to linux-firmware
until we are confident on what version we will start officially
supporting.


yeap, I kind of agree here, but at the same time it is our way to run
our CI with the firmware blobs that we need while not final, and also
this was already used for i915's MTL firmware.


ok





This one can't go to topic/core-for-CI neither:
fcb3410197f05 fault-inject: Include linux/types.h by default.

what it would do would be that we would not see the build error anymore,
but everyone else would (and it's not a CI-only configuration).
Unless it's merged to another branch, we shouldn't merge it.


yeap. it is sad that we were ignored there. let's just drop this then.
our driver is workarounding this bug anyway already.


agreed, let's drop it.






"52383b58eb8cf mei/hdcp: Also enable for XE" could be material for
topic/core-for-CI and  "8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs"
could either be on that branch or another xe-specific one.


yeap. For the MEI we probably need to ping Greg on the original
submission and ask his ack so we can put that in the final drm-xe-next
for good and not even include in a topic branch.

for the PVC IDs, the topic branch could be okay as well. But if we
end up with an exclusive branch for xe, then it is better there.


fair enough... I'm ok starting with topic/core-for-CI and if it ever
becomes a problem, to create a xe-specific topic branch.

thanks
Lucas De Marchi





>
> >
> > Anyway, for the inclusion like this, after our CI is ready:
>
> Could we merge this patch already at this point, considering it will,
> at least for now, only update drm-tip with our fixes?

ack

Lucas De Marchi

>
> Thanks,
>
> /Thomas
>
>
> >
> > Acked-by: Rodrigo Vivi 
> >
> > >  
> > >  "drm-intel topic/core-for-CI"
> > >  "drm-misc  topic/i915-ttm"
> > > --
> > > 2.42.0
> > >
>

Re: [PATCH] nightly.conf: Add the xe repo to drm-tip

[Rodrigo Vivi]

On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote:
> On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote:
> > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote:
> > > Add the xe repo to drm-tip and the dim tools.
> > > For now use the sha1 of the first drm-xe-next pull request for drm-
> > > tip,
> > > since that branch tip is currently adapted for our CI testing.
> > > 
> > > Cc: Rodrigo Vivi 
> > > Cc: Lucas De Marchi 
> > > Cc: Oded Gabbay 
> > > Cc: daniel.vet...@ffwll.ch
> > > Cc: Maarten Lankhorst 
> > > Cc: dim-to...@lists.freedesktop.org
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: intel-...@lists.freedesktop.org
> > > Signed-off-by: Thomas Hellström 
> > > ---
> > >  nightly.conf | 7 +++
> > >  1 file changed, 7 insertions(+)
> > > 
> > > diff --git a/nightly.conf b/nightly.conf
> > > index 24126b61b797..accd3ff2cc39 100644
> > > --- a/nightly.conf
> > > +++ b/nightly.conf
> > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip
> > >  https://anongit.freedesktop.org/git/drm/drm-tip
> > >  https://anongit.freedesktop.org/git/drm/drm-tip.git
> > >  "
> > > +drm_tip_repos[drm-xe]="
> > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git
> > > +https://gitlab.freedesktop.org/drm/xe/kernel.git
> > > +"
> > >  drm_tip_repos[drm-intel]="
> > >  ssh://git.freedesktop.org/git/drm/drm-intel
> > >  ssh://git.freedesktop.org/git/drm-intel
> > > @@ -65,14 +69,17 @@ drm_tip_config=(
> > >   "drmdrm-fixes"
> > >   "drm-misc   drm-misc-fixes"
> > >   "drm-intel  drm-intel-fixes"
> > > + "drm-xe drm-xe-fixes"
> > >  
> > >   "drmdrm-next"
> > >   "drm-misc   drm-misc-next-fixes"
> > >   "drm-intel  drm-intel-next-fixes"
> > > + "drm-xe drm-xe-next-fixes"
> > >  
> > >   "drm-misc   drm-misc-next"
> > >   "drm-intel  drm-intel-next"
> > >   "drm-intel  drm-intel-gt-next"
> > > + "drm-xe drm-xe-next b6e1b7081768"
> > 
> > yeap, up to this commit nothing else should change, but
> > then we will need an extra rebase of the rest on top of drm/drm-next.
> > 
> > But then we need to decide where these following patches will live:
> > 880277f31cc69 drm/xe/guc: define LNL FW
> > 2cfc5ae1b8267 drm/xe/guc: define PVC FW
> > 52383b58eb8cf mei/hdcp: Also enable for XE
> > bea27d7369855 mei: gsc: add support for auxiliary device created by
> > Xe driver
> > fcb3410197f05 fault-inject: Include linux/types.h by default.
> > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs
> > 
> > 
> > Will it be the topic/core-for-CI?
> > or topic/xe-extras?
> > or what?
> 
> This sounds to me like topic/core-for-CI? Or is there any drawback with
> that?
> 
> > 
> > Anyway, for the inclusion like this, after our CI is ready:
> 
> Could we merge this patch already at this point, considering it will,
> at least for now, only update drm-tip with our fixes?

yeap, likely a good idea.
Acked-by: Rodrigo Vivi 

But we just move the final drm-xe-next after figuring out the topic
branches and the final rebases fixing the tags and the commiter's s-o-b
and the fixes tags.

> 
> Thanks,
> 
> /Thomas
> 
> 
> > 
> > Acked-by: Rodrigo Vivi 
> > 
> > >  
> > >   "drm-intel  topic/core-for-CI"
> > >   "drm-misc   topic/i915-ttm"
> > > -- 
> > > 2.42.0
> > > 
> 

Re: [PATCH] nightly.conf: Add the xe repo to drm-tip

[Rodrigo Vivi]

On Wed, Jan 03, 2024 at 11:59:16PM -0600, Lucas De Marchi wrote:
> On Wed, Jan 03, 2024 at 02:50:57PM +0100, Thomas Hellström wrote:
> > On Tue, 2023-12-26 at 13:30 -0500, Rodrigo Vivi wrote:
> > > On Fri, Dec 22, 2023 at 12:36:39PM +0100, Thomas Hellström wrote:
> > > > Add the xe repo to drm-tip and the dim tools.
> > > > For now use the sha1 of the first drm-xe-next pull request for drm-
> > > > tip,
> > > > since that branch tip is currently adapted for our CI testing.
> > > >
> > > > Cc: Rodrigo Vivi 
> > > > Cc: Lucas De Marchi 
> > > > Cc: Oded Gabbay 
> > > > Cc: daniel.vet...@ffwll.ch
> > > > Cc: Maarten Lankhorst 
> > > > Cc: dim-to...@lists.freedesktop.org
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: intel-...@lists.freedesktop.org
> > > > Signed-off-by: Thomas Hellström 
> > > > ---
> > > >  nightly.conf | 7 +++
> > > >  1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/nightly.conf b/nightly.conf
> > > > index 24126b61b797..accd3ff2cc39 100644
> > > > --- a/nightly.conf
> > > > +++ b/nightly.conf
> > > > @@ -24,6 +24,10 @@ git://anongit.freedesktop.org/drm-tip
> > > >  https://anongit.freedesktop.org/git/drm/drm-tip
> > > >  https://anongit.freedesktop.org/git/drm/drm-tip.git
> > > >  "
> > > > +drm_tip_repos[drm-xe]="
> > > > +ssh://g...@gitlab.freedesktop.org/drm/xe/kernel.git
> > > > +https://gitlab.freedesktop.org/drm/xe/kernel.git
> > > > +"
> > > >  drm_tip_repos[drm-intel]="
> > > >  ssh://git.freedesktop.org/git/drm/drm-intel
> > > >  ssh://git.freedesktop.org/git/drm-intel
> > > > @@ -65,14 +69,17 @@ drm_tip_config=(
> > > >     "drmdrm-fixes"
> > > >     "drm-misc   drm-misc-fixes"
> > > >     "drm-intel  drm-intel-fixes"
> > > > +   "drm-xe drm-xe-fixes"
> > > >  
> > > >     "drmdrm-next"
> > > >     "drm-misc   drm-misc-next-fixes"
> > > >     "drm-intel  drm-intel-next-fixes"
> > > > +   "drm-xe drm-xe-next-fixes"
> > > >  
> > > >     "drm-misc   drm-misc-next"
> > > >     "drm-intel  drm-intel-next"
> > > >     "drm-intel  drm-intel-gt-next"
> > > > +   "drm-xe drm-xe-next b6e1b7081768"
> > > 
> > > yeap, up to this commit nothing else should change, but
> > > then we will need an extra rebase of the rest on top of drm/drm-next.
> > > 
> > > But then we need to decide where these following patches will live:
> > > 880277f31cc69 drm/xe/guc: define LNL FW
> > > 2cfc5ae1b8267 drm/xe/guc: define PVC FW
> > > 52383b58eb8cf mei/hdcp: Also enable for XE
> > > bea27d7369855 mei: gsc: add support for auxiliary device created by
> > > Xe driver
> > > fcb3410197f05 fault-inject: Include linux/types.h by default.
> > > 8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs
> > > 
> > > 
> > > Will it be the topic/core-for-CI?
> > > or topic/xe-extras?
> > > or what?
> > 
> > This sounds to me like topic/core-for-CI? Or is there any drawback with
> > that?
> 
> I think some of them are not really a "for CI". It's more like the
> workflow we are adopting e.g. with guc/huc, not sending it to linux-firmware
> until we are confident on what version we will start officially
> supporting.

yeap, I kind of agree here, but at the same time it is our way to run
our CI with the firmware blobs that we need while not final, and also
this was already used for i915's MTL firmware.

> 
> This one can't go to topic/core-for-CI neither:
>   fcb3410197f05 fault-inject: Include linux/types.h by default.
> 
> what it would do would be that we would not see the build error anymore,
> but everyone else would (and it's not a CI-only configuration).
> Unless it's merged to another branch, we shouldn't merge it.

yeap. it is sad that we were ignored there. let's just drop this then.
our driver is workarounding this bug anyway already.


> 
> "52383b58eb8cf mei/hdcp: Also enable for XE" could be material for
> topic/core-for-CI and  "8ebd9cd71f8ac drm/xe: Add PVC's PCI device IDs"
> could either be on that branch or another xe-specific one.

yeap. For the MEI we probably need to ping Greg on the original
submission and ask his ack so we can put that in the final drm-xe-next
for good and not even include in a topic branch.

for the PVC IDs, the topic branch could be okay as well. But if we
end up with an exclusive branch for xe, then it is better there.

> 
> > 
> > > 
> > > Anyway, for the inclusion like this, after our CI is ready:
> > 
> > Could we merge this patch already at this point, considering it will,
> > at least for now, only update drm-tip with our fixes?
> 
> ack
> 
> Lucas De Marchi
> 
> > 
> > Thanks,
> > 
> > /Thomas
> > 
> > 
> > > 
> > > Acked-by: Rodrigo Vivi 
> > > 
> > > >  
> > > >     "drm-intel  topic/core-for-CI"
> > > >     "drm-misc   topic/i915-ttm"
> > > > --
> > > > 2.42.0
> > > >
> > 

[PATCH] drm/vmwgfx: Add SVGA_3D_CMD_DEFINE_GB_SURFACE_V4 to command array.

[Ian Forbes]

Without this definition device errors will display the command name
as (null) when debug logging is enabled.

Signed-off-by: Ian Forbes 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 36987ef3fc30..472c4821528f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -3603,6 +3603,8 @@ static const struct vmw_cmd_entry 
vmw_cmd_entries[SVGA_3D_CMD_MAX] = {
_cmd_dx_bind_streamoutput, true, false, true),
VMW_CMD_DEF(SVGA_3D_CMD_DX_DEFINE_RASTERIZER_STATE_V2,
_cmd_dx_so_define, true, false, true),
+   VMW_CMD_DEF(SVGA_3D_CMD_DEFINE_GB_SURFACE_V4,
+   _cmd_invalid, false, false, true),
 };
 
 bool vmw_cmd_describe(const void *buf, u32 *size, char const **cmd)
-- 
2.34.1

Re: [PATCH] drm/bridge: parade-ps8640: Wait for HPD when doing an AUX transfer

[Doug Anderson]

Hi,

On Mon, Dec 25, 2023 at 1:08 AM Pin-yen Lin  wrote:
>
> Hi,
>
> On Fri, Dec 22, 2023 at 11:34 PM Doug Anderson  wrote:
> >
> > Hi,
> >
> > On Fri, Dec 22, 2023 at 2:29 AM Pin-yen Lin  wrote:
> > >
> > > Hi Douglas,
> > >
> > > On Fri, Dec 22, 2023 at 5:56 AM Douglas Anderson  
> > > wrote:
> > > >
> > > > Unlike what is claimed in commit f5aa7d46b0ee ("drm/bridge:
> > > > parade-ps8640: Provide wait_hpd_asserted() in struct drm_dp_aux"), if
> > > > someone manually tries to do an AUX transfer (like via `i2cdump ${bus}
> > > > 0x50 i`) while the panel is off we don't just get a simple transfer
> > > > error. Instead, the whole ps8640 gets thrown for a loop and goes into
> > > > a bad state.
> > > >
> > > > Let's put the function to wait for the HPD (and the magical 50 ms
> > > > after first reset) back in when we're doing an AUX transfer. This
> > > > shouldn't actually make things much slower (assuming the panel is on)
> > > > because we should immediately poll and see the HPD high. Mostly this
> > > > is just an extra i2c transfer to the bridge.
> > > >
> > > > Fixes: f5aa7d46b0ee ("drm/bridge: parade-ps8640: Provide 
> > > > wait_hpd_asserted() in struct drm_dp_aux")
> > > > Signed-off-by: Douglas Anderson 
> > > > ---
> > > >
> > > >  drivers/gpu/drm/bridge/parade-ps8640.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> > > > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > > > index 541e4f5afc4c..fb5e9ae9ad81 100644
> > > > --- a/drivers/gpu/drm/bridge/parade-ps8640.c
> > > > +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> > > > @@ -346,6 +346,11 @@ static ssize_t ps8640_aux_transfer(struct 
> > > > drm_dp_aux *aux,
> > > > int ret;
> > > >
> > > > pm_runtime_get_sync(dev);
> > > > +   ret = _ps8640_wait_hpd_asserted(ps_bridge, 200 * 1000);
> > > > +   if (ret) {
> > > > +   pm_runtime_put_sync_suspend(dev);
> > > > +   return ret;
> > > > +   }
> > > > ret = ps8640_aux_transfer_msg(aux, msg);
> > > > pm_runtime_mark_last_busy(dev);
> > > > pm_runtime_put_autosuspend(dev);
> > > > --
> > > > 2.43.0.472.g3155946c3a-goog
> > > >
> > >
> > > I think commit 9294914dd550 ("drm/bridge: parade-ps8640: Link device
> > > to ensure suspend/resume order")  is trying to address the same
> > > problem, but we see this issue here because the device link is missing
> > > DL_FLAG_PM_RUNTIME. I prefer to add DL_FLAG_PM_RUNTIME here so we
> > > don't need to add a _ps8640_wait_hpd_asserted() after every
> > > pm_runtime_get_*() call.
> >
> > I disagree. We've had several discussions on the lists about this
> > topic before, though since I'm technically on vacation right now I'm
> > not going to go look them up. In general "pm_runtime" is not
> > sufficient for powering up DRM components. While DRM components can
> > use pm_runtime themselves (as we are doing here), powering up another
> > DRM component by grabbing a pm_runtime reference isn't right. There is
> > a reason for the complexity of the DRM prepare/enable and all the
> > current debates about the right order to call components in prepare()
> > just demonstrates further that a simple pm_runtime reference isn't
> > enough.
> >
> > It can be noted that, with ${SUBJECT} patch we _aren't_ powering up
> > the panel. I actually tested two cases on sc7180-lazor. In one case I
> > just closed the lid, which powered off the panel, but the touchscreen
> > kept the panel power rail on. In this case with my patch I could still
> > read the panel EDID. I then hacked the touchscreen off. Now when I
> > closed the lid I'd get a timeout. This is different than if we tried
> > to get a pm_runtime reference to the panel.
> >
> Okay, thanks for the detailed explanation. Then, let's go with the
> approach in this patch. So,
>
> Tested-by: Pin-yen Lin 
> Reviewed-by: Pin-yen Lin 

Thanks for the tags. I've pushed this to drm-misc-fixes:

024b32db43a3 drm/bridge: parade-ps8640: Wait for HPD when doing an AUX transfer

[Bug 218347] Crash. amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=218347

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Rik from comment #3)
> Are you sure? Because in the help I read:

Yes, per:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n18009

RADEON and AMDGPU DRM DRIVERS
M:  Alex Deucher 
M:  Christian König 
M:  Pan, Xinhui 
L:  amd-...@lists.freedesktop.org
S:  Supported
B:  https://gitlab.freedesktop.org/drm/amd/-/issues
C:  irc://irc.oftc.net/radeon
T:  git https://gitlab.freedesktop.org/agd5f/linux.git
F:  Documentation/gpu/amdgpu/
F:  drivers/gpu/drm/amd/
F:  drivers/gpu/drm/ci/xfails/amd*
F:  drivers/gpu/drm/radeon/
F:  include/uapi/drm/amdgpu_drm.h
F:  include/uapi/drm/radeon_drm.h

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH v3 0/5] drm/msm/dpu: remove dpu_encoder_phys_ops::atomic_mode_set callback

[Abhinav Kumar]

On 12/25/2023 5:08 AM, Dmitry Baryshkov wrote:

The dpu_encoder_phys_ops::atomic_mode_set() callback is mostly
redundant. Implementations only set the IRQ indices there. Move
statically allocated IRQs to dpu_encoder_phys_*_init() and set
dynamically allocated IRQs in the irq_enable() callback.

The writeback backend of the dpu_encoder is the only user of the
dpu_encoder_phys_ops::atomic_check() callback. Move corresponding code
to the DPU's drm_writeback_connector implementation (dpu_writeback.c)
and drop corresponding callback code.

Changes since v2:
- Rebase on top of linux-next
- Also incorporate the dpu_encoder_phys::atomic_check series

Changes since v1:
- Split trace events into enable/disable pairs (Abhinav).



We will provide a Tested-by for this series soon after re-validating WB 
and CDM with WB with this.

Re: [PATCH v3 5/5] drm/msm/dpu: drop dpu_encoder_phys_ops::atomic_check()

[Abhinav Kumar]

On 12/25/2023 5:08 AM, Dmitry Baryshkov wrote:

Writeback was the last user of dpu_encoder_phys_ops's atomic_check()
callback. As the code was moved to the dpu_writeback.c, the callback
becomes unused. Drop it now.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c  | 15 ---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h |  4 
  2 files changed, 19 deletions(-)



Same comment as prev change but otherwise

Reviewed-by: Abhinav Kumar 

Re: [PATCH v3 4/5] drm/msm/dpu: move writeback's atomic_check to dpu_writeback.c

[Abhinav Kumar]

On 12/25/2023 5:08 AM, Dmitry Baryshkov wrote:

dpu_encoder_phys_wb is the only user of encoder's atomic_check callback.
Move corresponding checks to drm_writeback_connector's implementation
and drop the dpu_encoder_phys_wb_atomic_check() function.

Signed-off-by: Dmitry Baryshkov 
---
  .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   | 54 --
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  9 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 57 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h |  3 +-
  4 files changed, 64 insertions(+), 59 deletions(-)



I am fine with this change with respect to how the code is today.

Hence,

Reviewed-by: Abhinav Kumar 

But if we start noticing a pattern like below in dpu_encoder.c's 
atomic_check,


if (INTF_WB)
.
else if (INTF_DP || INTF_DSI)
.

then, it will demand bringing back a phys specific callback.

Re: [PATCH] drm/panel-edp: use put_sync in unprepare

[Doug Anderson]

Hi,

On Wed, Dec 20, 2023 at 2:43 PM Doug Anderson  wrote:
>
> Hi,
>
> On Wed, Dec 20, 2023 at 2:14 PM Hsin-Yi Wang  wrote:
> >
> > Some edp panel requires T10 (Delay from end of valid video data transmitted
> > by the Source device to power-off) less than 500ms. Using autosuspend with
> > delay set as 1000 violates this requirement.
> >
> > Use put_sync_suspend in unprepare to meet the spec. For other cases (such
> > as getting EDID), it still uses autosuspend.
> >
> > Suggested-by: Douglas Anderson 
> > Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple")
>
> Probably instead:
>
> Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid
> excessive unprepare / prepare")
>
> ...you could send a new version or I could just fix it up when I apply it.
>
>
> > Signed-off-by: Hsin-Yi Wang 
> > ---
> >  drivers/gpu/drm/panel/panel-edp.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
>
> Yeah, it's really unfortunate but I think we have to do this. It will
> add big delays any time we need to turn the panel off and quickly back
> on again, but I don't think we can reliably meet T10 without it. Even
> turning down the autosuspend delay won't really help since someone
> could do something like read the EDID while the delay was happening to
> reset the delay. At least we can still use "autosuspend" to avoid
> powering off between reading the EDID and powering up the panel since
> the EDID grabs runtime_pm itself and still uses autosuspend.
>
> I don't remember this particular problem before and nobody has yelled
> about it in the past. ...and the requirement seems crazy, but it
> certainly is in the spec sheets so we should be good citizens and
> honor it. On the plus side, this means that we will always fully power
> cycle the panel whenever we turn video off and that means that if any
> other panels out there have weird issues like "samsung-atna33xc20"
> this will also fix them since this is the same fix I had to do in that
> driver.
>
> In any case:
>
> Reviewed-by: Douglas Anderson 
>
> I'm about to go on vacation, so I won't apply this until January.
> Other drm-misc maintainers are free to apply sooner than that if
> they're comfortable with it.

Things were silent and I'm back from vacation, so I've gone ahead and
pushed this to drm-misc-next.

Technically I could have pushed it to drm-misc-fixes, but from my
understanding of the issue it was not causing any actual problems
other than making someone upset who was staring at oscilloscope traces
and comparing them to a spec sheet. Given that this changes timings,
I'd rather have the extra bake time of going through drm-misc-next.

49ddab089611 drm/panel-edp: use put_sync in unprepare


-Doug

Re: [PATCH v3 2/5] drm/msm/dpu: split _dpu_encoder_resource_control_helper()

[Abhinav Kumar]

On 12/25/2023 5:08 AM, Dmitry Baryshkov wrote:

Follow the _dpu_encoder_irq_control() change and split the
_dpu_encoder_resource_control_helper() into enable and disable parts.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h   | 12 --
  2 files changed, 37 insertions(+), 20 deletions(-)



Reviewed-by: Abhinav Kumar 

Re: [PATCH 2/2] drm/amdgpu: add shared fdinfo stats

[Alex Deucher]

Ping?

Alex

On Thu, Dec 7, 2023 at 1:03 PM Alex Deucher  wrote:
>
> Add shared stats.  Useful for seeing shared memory.
>
> v2: take dma-buf into account as well
>
> Signed-off-by: Alex Deucher 
> Cc: Rob Clark 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c |  4 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 11 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  6 ++
>  3 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> index 5706b282a0c7..c7df7fa3459f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c
> @@ -97,6 +97,10 @@ void amdgpu_show_fdinfo(struct drm_printer *p, struct 
> drm_file *file)
>stats.requested_visible_vram/1024UL);
> drm_printf(p, "amd-requested-gtt:\t%llu KiB\n",
>stats.requested_gtt/1024UL);
> +   drm_printf(p, "drm-shared-vram:\t%llu KiB\n", 
> stats.vram_shared/1024UL);
> +   drm_printf(p, "drm-shared-gtt:\t%llu KiB\n", stats.gtt_shared/1024UL);
> +   drm_printf(p, "drm-shared-cpu:\t%llu KiB\n", stats.cpu_shared/1024UL);
> +
> for (hw_ip = 0; hw_ip < AMDGPU_HW_IP_NUM; ++hw_ip) {
> if (!usage[hw_ip])
> continue;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> index d79b4ca1ecfc..1b37d95475b8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> @@ -1287,25 +1287,36 @@ void amdgpu_bo_get_memory(struct amdgpu_bo *bo,
>   struct amdgpu_mem_stats *stats)
>  {
> uint64_t size = amdgpu_bo_size(bo);
> +   struct drm_gem_object *obj;
> unsigned int domain;
> +   bool shared;
>
> /* Abort if the BO doesn't currently have a backing store */
> if (!bo->tbo.resource)
> return;
>
> +   obj = >tbo.base;
> +   shared = (obj->handle_count > 1) || obj->dma_buf;
> +
> domain = amdgpu_mem_type_to_domain(bo->tbo.resource->mem_type);
> switch (domain) {
> case AMDGPU_GEM_DOMAIN_VRAM:
> stats->vram += size;
> if (amdgpu_bo_in_cpu_visible_vram(bo))
> stats->visible_vram += size;
> +   if (shared)
> +   stats->vram_shared += size;
> break;
> case AMDGPU_GEM_DOMAIN_GTT:
> stats->gtt += size;
> +   if (shared)
> +   stats->gtt_shared += size;
> break;
> case AMDGPU_GEM_DOMAIN_CPU:
> default:
> stats->cpu += size;
> +   if (shared)
> +   stats->cpu_shared += size;
> break;
> }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> index d28e21baef16..0503af75dc26 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
> @@ -138,12 +138,18 @@ struct amdgpu_bo_vm {
>  struct amdgpu_mem_stats {
> /* current VRAM usage, includes visible VRAM */
> uint64_t vram;
> +   /* current shared VRAM usage, includes visible VRAM */
> +   uint64_t vram_shared;
> /* current visible VRAM usage */
> uint64_t visible_vram;
> /* current GTT usage */
> uint64_t gtt;
> +   /* current shared GTT usage */
> +   uint64_t gtt_shared;
> /* current system memory usage */
> uint64_t cpu;
> +   /* current shared system memory usage */
> +   uint64_t cpu_shared;
> /* sum of evicted buffers, includes visible VRAM */
> uint64_t evicted_vram;
> /* sum of evicted buffers due to CPU access */
> --
> 2.42.0
>

Re: [PATCH v3 1/5] drm/msm/dpu: split irq_control into irq_enable and _disable

[Abhinav Kumar]

On 12/25/2023 5:08 AM, Dmitry Baryshkov wrote:

The single helper for both enable and disable cases is too complicated,
especially if we start adding more code to these helpers. Split it into
irq_enable and irq_disable cases.

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 36 +++---
  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h  |  6 +-
  .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c  | 65 ++-
  .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  | 46 +++--
  .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c   | 29 ++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 62 ++
  6 files changed, 158 insertions(+), 86 deletions(-)



Reviewed-by: Abhinav Kumar 

Re: [PATCH] drm/xe: clean up type of GUC_HXG_MSG_0_ORIGIN

[Lucas De Marchi]

On Mon, Jan 08, 2024 at 09:46:47PM +0100, Michal Wajdeczko wrote:



On 08.01.2024 15:07, Lucas De Marchi wrote:

On Mon, Jan 08, 2024 at 12:05:57PM +0300, Dan Carpenter wrote:

The GUC_HXG_MSG_0_ORIGIN definition should be unsigned.  Currently it is
defined as INT_MIN.  This doesn't cause a problem currently but it's
still worth cleaning up.

Signed-off-by: Dan Carpenter 


it seems there are a few more places to change to follow what was done
in commit 962bd34bb457 ("drm/i915/uc: Fix undefined behavior due to
shift overflowing the constant").

+Michal

Could we eventually share these abi includes with i915 so we don't
keep fixing the same thing in 2 places?


it should be possible and I guess we should plan for that while
discussing all this new xe driver...

anyway, what about creating new intel/ folder under drm/ ?


include/drm/intel/?



- drm/intel/include/abi
   guc_actions_abi.h
   guc_klvs_abi.h
   ...

the only question would be what prefix should be used for macros:
just GUC_ or INTEL_GUC_ or XE_GUC_ ?


if using a intel/ dir, probably better with INTEL_ prefix



then we can also think of creating library with common helpers for GuC
(for encoding/decoding HXG messages, preparing ADS, reading logs, etc)


with the other differences we have, I don't see much benefit,
particularly as it won't change for i915 wrt supported platforms.



btw, we can also consider sharing register definitions:

- drm/intel/include/regs
   xe_engine_regs.h
   xe_gt_regs.h
   xe_regs_defs.h


same as above, I don't think it's worth it as xe will keep adding to it
and it doesn't care for all the previous platforms. For those files we
may eventually autogen them like done by mesa.

Lucas De Marchi



Michal



Lucas De Marchi


---
drivers/gpu/drm/xe/abi/guc_messages_abi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/abi/guc_messages_abi.h
b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
index 3d199016cf88..c04606872e48 100644
--- a/drivers/gpu/drm/xe/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
@@ -40,7 +40,7 @@
 */

#define GUC_HXG_MSG_MIN_LEN    1u
-#define GUC_HXG_MSG_0_ORIGIN    (0x1 << 31)
+#define GUC_HXG_MSG_0_ORIGIN    (0x1U << 31)
#define   GUC_HXG_ORIGIN_HOST    0u
#define   GUC_HXG_ORIGIN_GUC    1u
#define GUC_HXG_MSG_0_TYPE    (0x7 << 28)
-- 
2.42.0

Re: [PATCH v5 0/8] iio: new DMABUF based API, v5

[Andrew Davis]

On 12/19/23 11:50 AM, Paul Cercueil wrote:

[V4 was: "iio: Add buffer write() support"][1]

Hi Jonathan,

This is a respin of the V3 of my patchset that introduced a new
interface based on DMABUF objects [2].

The V4 was a split of the patchset, to attempt to upstream buffer
write() support first. But since there is no current user upstream, it
was not merged. This V5 is about doing the opposite, and contains the
new DMABUF interface, without adding the buffer write() support. It can
already be used with the upstream adi-axi-adc driver.

In user-space, Libiio uses it to transfer back and forth blocks of
samples between the hardware and the applications, without having to
copy the data.

On a ZCU102 with a FMComms3 daughter board, running Libiio from the
pcercuei/dev-new-dmabuf-api branch [3], compiled with
WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
   sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
   Throughput: 116 MiB/s

Same hardware, with the DMABUF API (WITH_LOCAL_DMABUF_API=ON):
   sudo utils/iio_rwdev -b 4096 -B cf-ad9361-lpc
   Throughput: 475 MiB/s

This benchmark only measures the speed at which the data can be fetched
to iio_rwdev's internal buffers, and does not actually try to read the
data (e.g. to pipe it to stdout). It shows that fetching the data is
more than 4x faster using the new interface.

When actually reading the data, the performance difference isn't that
impressive (maybe because in case of DMABUF the data is not in cache):

WITH_LOCAL_DMABUF_API=OFF (so that it uses fileio):
   sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress
   2446422528 bytes (2.4 GB, 2.3 GiB) copied, 22 s, 111 MB/s

WITH_LOCAL_DMABUF_API=ON:
   sudo utils/iio_rwdev -b 4096 cf-ad9361-lpc | dd of=/dev/zero status=progress
   2334388736 bytes (2.3 GB, 2.2 GiB) copied, 21 s, 114 MB/s

One interesting thing to note is that fileio is (currently) actually
faster than the DMABUF interface if you increase a lot the buffer size.
My explanation is that the cache invalidation routine takes more and
more time the bigger the DMABUF gets. This is because the DMABUF is
backed by small-size pages, so a (e.g.) 64 MiB DMABUF is backed by up
to 16 thousands pages, that have to be invalidated one by one. This can
be addressed by using huge pages, but the udmabuf driver does not (yet)
support creating DMABUFs backed by huge pages.



Have you tried DMABUFs created using the DMABUF System heap exporter?
(drivers/dma-buf/heaps/system_heap.c) It should be able to handle
larger allocation better here, and if you don't have any active
mmaps or vmaps then it can skip CPU-side coherency maintenance
(useful for device to device transfers).

Allocating DMABUFs out of user pages has a bunch of other issues you
might run into also. I'd argue udmabuf is now completely superseded
by DMABUF system heaps. Try it out :)

Andrew


Anyway, the real benefits happen when the DMABUFs are either shared
between IIO devices, or between the IIO subsystem and another
filesystem. In that case, the DMABUFs are simply passed around drivers,
without the data being copied at any moment.

We use that feature to transfer samples from our transceivers to USB,
using a DMABUF interface to FunctionFS [4].

This drastically increases the throughput, to about 274 MiB/s over a
USB3 link, vs. 127 MiB/s using IIO's fileio interface + write() to the
FunctionFS endpoints, for a lower CPU usage (0.85 vs. 0.65 load avg.).

Based on linux-next/next-20231219.

Cheers,
-Paul

[1] https://lore.kernel.org/all/20230807112113.47157-1-p...@crapouillou.net/
[2] https://lore.kernel.org/all/20230403154800.215924-1-p...@crapouillou.net/
[3] https://github.com/analogdevicesinc/libiio/tree/pcercuei/dev-new-dmabuf-api
[4] https://lore.kernel.org/all/20230322092118.9213-1-p...@crapouillou.net/

---
Changelog:
- [3/8]: Replace V3's dmaengine_prep_slave_dma_array() with a new
   dmaengine_prep_slave_dma_vec(), which uses a new 'dma_vec' struct.
   Note that at some point we will need to support cyclic transfers
   using dmaengine_prep_slave_dma_vec(). Maybe with a new "flags"
   parameter to the function?

- [4/8]: Implement .device_prep_slave_dma_vec() instead of V3's
   .device_prep_slave_dma_array().

   @Vinod: this patch will cause a small conflict with my other
   patchset adding scatter-gather support to the axi-dmac driver.
   This patch adds a call to axi_dmac_alloc_desc(num_sgs), but the
   prototype of this function changed in my other patchset - it would
   have to be passed the "chan" variable. I don't know how you prefer it
   to be resolved. Worst case scenario (and if @Jonathan is okay with
   that) this one patch can be re-sent later, but it would make this
   patchset less "atomic".

- [5/8]:
   - Use dev_err() instead of pr_err()
   - Inline to_iio_dma_fence()
   - Add comment to explain why we unref twice when detaching dmabuf
   - Remove TODO comment. It is actually safe to free the file's
 private data even when transfers are 

Re: [PATCH v2] drm/vram-helper: fix kernel-doc warnings

[Randy Dunlap]

Hi Thomas,

On 1/8/24 00:57, Thomas Zimmermann wrote:
> Hi,
> 
> thanks for the fix.
> 
> Am 06.01.24 um 04:29 schrieb Randy Dunlap:
>> Remove the @funcs entry from struct drm_vram_mm to quieten the kernel-doc
>> warning.
>>
>> Use the "define" kernel-doc keyword and an '\' line continuation
>> to fix another kernel-doc warning.
>>
>> drm_gem_vram_helper.h:129: warning: missing initial short description on 
>> line:
>>   * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
>> drm_gem_vram_helper.h:185: warning: Excess struct member 'funcs' description 
>> in 'drm_vram_mm'
>>
>> Signed-off-by: Randy Dunlap 
>> Cc: David Airlie 
>> Cc: Daniel Vetter 
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: Maarten Lankhorst 
>> Cc: Maxime Ripard 
>> Cc: Thomas Zimmermann 
>> ---
>> v2: Add commit description
>>
>> base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
>>
>>   include/drm/drm_gem_vram_helper.h |    3 +--
>>   1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff -- a/include/drm/drm_gem_vram_helper.h 
>> b/include/drm/drm_gem_vram_helper.h
>> --- a/include/drm/drm_gem_vram_helper.h
>> +++ b/include/drm/drm_gem_vram_helper.h
>> @@ -126,7 +126,7 @@ drm_gem_vram_plane_helper_cleanup_fb(str
>>    struct drm_plane_state *old_state);
>>     /**
>> - * DRM_GEM_VRAM_PLANE_HELPER_FUNCS -
>> + * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
> 
> Did something change wrt. doc syntax? I think this used to work without 
> warnings. About this 'define': we don't use is in another docs. Can we leave 
> it out here or is this the new syntax?
> 

There are no doc syntax changes that I know of. This is not
new syntax. It has been around since 2014:
  cbb4d3e6510b ("scripts/kernel-doc: handle object-like macros")


"define OBJ_LIKE_MACRO" is used 2 other times in include/drm/:

drm_fb_helper.h:

/**
 * define DRM_FB_HELPER_DEFAULT_OPS - helper define for drm drivers
 *
 * Helper define to register default implementations of drm_fb_helper
 * functions. To be used in struct fb_ops of drm drivers.
 */

drm_gem_vram_helper.h: (the file being patched here)

/**
 * define DRM_GEM_VRAM_DRIVER - default callback functions for \
 drm_driver
 *
 * Drivers that use VRAM MM and GEM VRAM can use this macro to initialize
 *  drm_driver with default functions.
 */


> 
>>    *    Initializes struct drm_plane_helper_funcs for VRAM handling
>>    *
>>    * Drivers may use GEM BOs as VRAM helpers for the framebuffer memory. This
>> @@ -170,7 +170,6 @@ void drm_gem_vram_simple_display_pipe_cl
>>    * @vram_base:    Base address of the managed video memory
>>    * @vram_size:    Size of the managed video memory in bytes
>>    * @bdev:    The TTM BO device.
>> - * @funcs:    TTM BO functions
>>    *
>>    * The fields  drm_vram_mm.vram_base and
>>    *  drm_vram_mm.vrm_size are managed by VRAM MM, but are
> 

-- 
#Randy

Re: [PATCH AUTOSEL 6.1 5/5] nouveau: fix disp disabling with GSP

[David Airlie]

NAK for backporting this to anything, it is just a fix for 6.7


On Mon, Jan 8, 2024 at 10:28 PM Sasha Levin  wrote:
>
> From: Dave Airlie 
>
> [ Upstream commit 7854ea0e408d7f2e8faaada1773f3ddf9cb538f5 ]
>
> This func ptr here is normally static allocation, but gsp r535
> uses a dynamic pointer, so we need to handle that better.
>
> This fixes a crash with GSP when you use config=disp=0 to avoid
> disp problems.
>
> Signed-off-by: Dave Airlie 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/20231222043308.3090089-4-airl...@gmail.com
> Signed-off-by: Sasha Levin 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
> index 65c99d948b686..ae47eabd5d0bd 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/base.c
> @@ -359,7 +359,7 @@ nvkm_disp_oneinit(struct nvkm_engine *engine)
> if (ret)
> return ret;
>
> -   if (disp->func->oneinit) {
> +   if (disp->func && disp->func->oneinit) {
> ret = disp->func->oneinit(disp);
> if (ret)
> return ret;
> @@ -461,8 +461,10 @@ nvkm_disp_new_(const struct nvkm_disp_func *func, struct 
> nvkm_device *device,
> spin_lock_init(>client.lock);
>
> ret = nvkm_engine_ctor(_disp, device, type, inst, true, 
> >engine);
> -   if (ret)
> +   if (ret) {
> +   disp->func = NULL;
> return ret;
> +   }
>
> if (func->super) {
> disp->super.wq = create_singlethread_workqueue("nvkm-disp");
> --
> 2.43.0
>

Re: [PATCH] drm/xe: clean up type of GUC_HXG_MSG_0_ORIGIN

[Michal Wajdeczko]

On 08.01.2024 15:07, Lucas De Marchi wrote:
> On Mon, Jan 08, 2024 at 12:05:57PM +0300, Dan Carpenter wrote:
>> The GUC_HXG_MSG_0_ORIGIN definition should be unsigned.  Currently it is
>> defined as INT_MIN.  This doesn't cause a problem currently but it's
>> still worth cleaning up.
>>
>> Signed-off-by: Dan Carpenter 
> 
> it seems there are a few more places to change to follow what was done
> in commit 962bd34bb457 ("drm/i915/uc: Fix undefined behavior due to
> shift overflowing the constant").
> 
> +Michal
> 
> Could we eventually share these abi includes with i915 so we don't
> keep fixing the same thing in 2 places?

it should be possible and I guess we should plan for that while
discussing all this new xe driver...

anyway, what about creating new intel/ folder under drm/ ?

 - drm/intel/include/abi
guc_actions_abi.h
guc_klvs_abi.h
...

the only question would be what prefix should be used for macros:
just GUC_ or INTEL_GUC_ or XE_GUC_ ?

then we can also think of creating library with common helpers for GuC
(for encoding/decoding HXG messages, preparing ADS, reading logs, etc)

btw, we can also consider sharing register definitions:

 - drm/intel/include/regs
xe_engine_regs.h
xe_gt_regs.h
xe_regs_defs.h

Michal

> 
> Lucas De Marchi
> 
>> ---
>> drivers/gpu/drm/xe/abi/guc_messages_abi.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/xe/abi/guc_messages_abi.h
>> b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
>> index 3d199016cf88..c04606872e48 100644
>> --- a/drivers/gpu/drm/xe/abi/guc_messages_abi.h
>> +++ b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
>> @@ -40,7 +40,7 @@
>>  */
>>
>> #define GUC_HXG_MSG_MIN_LEN    1u
>> -#define GUC_HXG_MSG_0_ORIGIN    (0x1 << 31)
>> +#define GUC_HXG_MSG_0_ORIGIN    (0x1U << 31)
>> #define   GUC_HXG_ORIGIN_HOST    0u
>> #define   GUC_HXG_ORIGIN_GUC    1u
>> #define GUC_HXG_MSG_0_TYPE    (0x7 << 28)
>> -- 
>> 2.42.0
>>

[PATCH v5 8/8] drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK

[Dario Binacchi]

The initialization commands are taken from the STMicroelectronics driver
found at [1].
To ensure backward compatibility, flags have been added to enable gamma
correction setting and display control. In other cases, registers have
been set to their default values according to the specifications found
in the datasheet.

[1] 
https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/Components/nt35510/
Signed-off-by: Dario Binacchi 

---

Changes in v5:
- Replace GPIOD_ASIS with GPIOD_OUT_HIGH in the call to 
devm_gpiod_get_optional().

Changes in v2:
- Re-write the patch [8/8] "drm/panel: nt35510: support FRIDA 
FRD400B25025-A-CTK"
  in the same style as the original driver.

 drivers/gpu/drm/panel/panel-novatek-nt35510.c | 284 --
 1 file changed, 252 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c 
b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index fc16cf3a6d9d..7c634579634d 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -36,6 +36,9 @@
 #include 
 #include 
 
+#define NT35510_CMD_CORRECT_GAMMA BIT(0)
+#define NT35510_CMD_CONTROL_DISPLAY BIT(1)
+
 #define MCS_CMD_MAUCCTR0xF0 /* Manufacturer command enable */
 #define MCS_CMD_READ_ID1   0xDA
 #define MCS_CMD_READ_ID2   0xDB
@@ -112,18 +115,33 @@
 /* AVDD and AVEE setting 3 bytes */
 #define NT35510_P1_AVDD_LEN 3
 #define NT35510_P1_AVEE_LEN 3
+#define NT35510_P1_VCL_LEN 3
 #define NT35510_P1_VGH_LEN 3
 #define NT35510_P1_VGL_LEN 3
 #define NT35510_P1_VGP_LEN 3
 #define NT35510_P1_VGN_LEN 3
+#define NT35510_P1_VCMOFF_LEN 2
 /* BT1CTR thru BT5CTR setting 3 bytes */
 #define NT35510_P1_BT1CTR_LEN 3
 #define NT35510_P1_BT2CTR_LEN 3
+#define NT35510_P1_BT3CTR_LEN 3
 #define NT35510_P1_BT4CTR_LEN 3
 #define NT35510_P1_BT5CTR_LEN 3
 /* 52 gamma parameters times two per color: positive and negative */
 #define NT35510_P1_GAMMA_LEN 52
 
+#define NT35510_WRCTRLD_BCTRL BIT(5)
+#define NT35510_WRCTRLD_A BIT(4)
+#define NT35510_WRCTRLD_DD BIT(3)
+#define NT35510_WRCTRLD_BL BIT(2)
+#define NT35510_WRCTRLD_DB BIT(1)
+#define NT35510_WRCTRLD_G BIT(0)
+
+#define NT35510_WRCABC_OFF 0
+#define NT35510_WRCABC_UI_MODE 1
+#define NT35510_WRCABC_STILL_MODE 2
+#define NT35510_WRCABC_MOVING_MODE 3
+
 /**
  * struct nt35510_config - the display-specific NT35510 configuration
  *
@@ -175,6 +193,10 @@ struct nt35510_config {
 * @mode_flags: DSI operation mode related flags
 */
unsigned long mode_flags;
+   /**
+* @cmds: enable DSI commands
+*/
+   u32 cmds;
/**
 * @avdd: setting for AVDD ranging from 0x00 = 6.5V to 0x14 = 4.5V
 * in 0.1V steps the default is 0x05 which means 6.0V
@@ -224,6 +246,25 @@ struct nt35510_config {
 * The defaults are 4 and 3 yielding 0x34
 */
u8 bt2ctr[NT35510_P1_BT2CTR_LEN];
+   /**
+* @vcl: setting for VCL ranging from 0x00 = -2.5V to 0x11 = -4.0V
+* in 1V steps, the default is 0x00 which means -2.5V
+*/
+   u8 vcl[NT35510_P1_VCL_LEN];
+   /**
+* @bt3ctr: setting for boost power control for the VCL step-up
+* circuit (3)
+* bits 0..2 in the lower nibble controls CLCK, the booster clock
+* frequency, the values are the same as for PCK in @bt1ctr.
+* bits 4..5 in the upper nibble controls BTCL, the boosting
+* amplification for the step-up circuit.
+* 0 = Disable
+* 1 = -0.5 x VDDB
+* 2 = -1 x VDDB
+* 3 = -2 x VDDB
+* The defaults are 4 and 2 yielding 0x24
+*/
+   u8 bt3ctr[NT35510_P1_BT3CTR_LEN];
/**
 * @vgh: setting for VGH ranging from 0x00 = 7.0V to 0x0B = 18.0V
 * in 1V steps, the default is 0x08 which means 15V
@@ -277,6 +318,19 @@ struct nt35510_config {
 * same layout of bytes as @vgp.
 */
u8 vgn[NT35510_P1_VGN_LEN];
+   /**
+* @vcmoff: setting the DC VCOM offset voltage
+* The first byte contains bit 8 of VCM in bit 0 and VCMOFFSEL in bit 4.
+* The second byte contains bits 0..7 of VCM.
+* VCMOFFSEL the common voltage offset mode.
+* VCMOFFSEL 0x00 = VCOM .. 0x01 Gamma.
+* The default is 0x00.
+* VCM the VCOM output voltage (VCMOFFSEL = 0) or the internal register
+* offset for gamma voltage (VCMOFFSEL = 1).
+* VCM 0x00 = 0V/0 .. 0x118 = 3.5V/280 in steps of 12.5mV/1step
+* The default is 0x00 = 0V/0.
+*/
+   u8 vcmoff[NT35510_P1_VCMOFF_LEN];
/**
 * @dopctr: setting optional control for display
 * ERR bits 0..1 in the first byte is the ERR pin output signal setting.
@@ -441,6 +495,43 @@ struct nt35510_config {
 * @gamma_corr_neg_b: Blue gamma correction parameters, negative
 */
u8 gamma_corr_neg_b[NT35510_P1_GAMMA_LEN];
+   /**
+* @wrdisbv: write display 

[PATCH v5 7/8] drm/panel: nt35510: move hardwired parameters to configuration

[Dario Binacchi]

This patch, preparatory for future developments, move the hardwired
parameters to configuration data to allow the addition of new
NT35510-based panels.

Signed-off-by: Dario Binacchi 
Reviewed-by: Linus Walleij 
Tested-by: Linus Walleij 

---

Changes in v5:
- Replace NT35510_ROTATE_180_SETTING with NT35510_ROTATE_0_SETTING
- Add Reviewed-by tag of Linus Walleij
- Tested-by tag of Linus Walleij

Changes in v2:
- Re-write the patch [7/8] "drm/panel: nt35510: refactor panel initialization"
  in the same style as the original driver in order to maintain the same
  structure.

 drivers/gpu/drm/panel/panel-novatek-nt35510.c | 140 ++
 1 file changed, 115 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c 
b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index d6dceb858008..fc16cf3a6d9d 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -171,6 +171,10 @@ struct nt35510_config {
 * timing in the display controller.
 */
const struct drm_display_mode mode;
+   /**
+* @mode_flags: DSI operation mode related flags
+*/
+   unsigned long mode_flags;
/**
 * @avdd: setting for AVDD ranging from 0x00 = 6.5V to 0x14 = 4.5V
 * in 0.1V steps the default is 0x05 which means 6.0V
@@ -273,6 +277,100 @@ struct nt35510_config {
 * same layout of bytes as @vgp.
 */
u8 vgn[NT35510_P1_VGN_LEN];
+   /**
+* @dopctr: setting optional control for display
+* ERR bits 0..1 in the first byte is the ERR pin output signal setting.
+* 0 = Disable, ERR pin output low
+* 1 = ERR pin output CRC error only
+* 2 = ERR pin output ECC error only
+* 3 = ERR pin output CRC and ECC error
+* The default is 0.
+* N565 bit 2 in the first byte is the 16-bit/pixel format selection.
+* 0 = R[4:0] + G[5:3] & G[2:0] + B[4:0]
+* 1 = G[2:0] + R[4:0] & B[4:0] + G[5:3]
+* The default is 0.
+* DIS_EoTP_HS bit 3 in the first byte is "DSI protocol violation" error
+* reporting.
+* 0 = reporting when error
+* 1 = not reporting when error
+* DSIM bit 4 in the first byte is the video mode data type enable
+* 0 = Video mode data type disable
+* 1 = Video mode data type enable
+* The default is 0.
+* DSIG bit 5 int the first byte is the generic r/w data type enable
+* 0 = Generic r/w disable
+* 1 = Generic r/w enable
+* The default is 0.
+* DSITE bit 6 in the first byte is TE line enable
+* 0 = TE line is disabled
+* 1 = TE line is enabled
+* The default is 0.
+* RAMKP bit 7 in the first byte is the frame memory keep/loss in
+* sleep-in mode
+* 0 = contents loss in sleep-in
+* 1 = contents keep in sleep-in
+* The default is 0.
+* CRL bit 1 in the second byte is the source driver data shift
+* direction selection. This bit is XOR operation with bit RSMX
+* of 3600h command.
+* 0 (RMSX = 0) = S1 -> S1440
+* 0 (RMSX = 1) = S1440 -> S1
+* 1 (RMSX = 0) = S1440 -> S1
+* 1 (RMSX = 1) = S1 -> S1440
+* The default is 0.
+* CTB bit 2 in the second byte is the vertical scanning direction
+* selection for gate control signals. This bit is XOR operation
+* with bit ML of 3600h command.
+* 0 (ML = 0) = Forward (top -> bottom)
+* 0 (ML = 1) = Reverse (bottom -> top)
+* 1 (ML = 0) = Reverse (bottom -> top)
+* 1 (ML = 1) = Forward (top -> bottom)
+* The default is 0.
+* CRGB bit 3 in the second byte is RGB-BGR order selection. This
+* bit is XOR operation with bit RGB of 3600h command.
+* 0 (RGB = 0) = RGB/Normal
+* 0 (RGB = 1) = BGR/RB swap
+* 1 (RGB = 0) = BGR/RB swap
+* 1 (RGB = 1) = RGB/Normal
+* The default is 0.
+* TE_PWR_SEL bit 4 in the second byte is the TE output voltage
+* level selection (only valid when DSTB_SEL = 0 or DSTB_SEL = 1,
+* VSEL = High and VDDI = 1.665~3.3V).
+* 0 = TE output voltage level is VDDI
+* 1 = TE output voltage level is VDDA
+* The default is 0.
+*/
+   u8 dopctr[NT35510_P0_DOPCTR_LEN];
+   /**
+* @madctl: Memory data access control
+* RSMY bit 0 is flip vertical. Flips the display image top to down.
+* RSMX bit 1 is flip horizontal. Flips the display image left to right.
+* MH bit 2 is the horizontal refresh order.
+* RGB bit 3 is the RGB-BGR order.
+* 0 = RGB color sequence
+* 1 = BGR color sequence
+* ML bit 4 is the vertical refresh order.
+* MV bit 5 is the row/column exchange.
+* MX bit 6 is the column address order.
+* MY bit 7 is the row address 

[PATCH v5 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

[Dario Binacchi]

The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the
Novatek NT35510-based panel family.

Signed-off-by: Dario Binacchi 
Acked-by: Krzysztof Kozlowski 
Reviewed-by: Linus Walleij 

---

Changes in v5:
- Add Acked-by tag of Krzysztof Kozlowski
- Add Reviewed-by tag of Linus Walleij

Changes in v4:
- Put the "enum" list in alphabetical order

Changes in v3:
- Use "enum" to have less code changed

Changes in v2:
- Add a dash in front of each "items:"

 .../devicetree/bindings/display/panel/novatek,nt35510.yaml| 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml 
b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
index bc92928c805b..a4afaff483b7 100644
--- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
+++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
@@ -15,7 +15,9 @@ allOf:
 properties:
   compatible:
 items:
-  - const: hydis,hva40wv1
+  - enum:
+  - frida,frd400b25025
+  - hydis,hva40wv1
   - const: novatek,nt35510
 description: This indicates the panel manufacturer of the panel
   that is in turn using the NT35510 panel driver. The compatible
-- 
2.43.0

[PATCH v5 0/8] Add display support for stm32f769-disco board

[Dario Binacchi]

The series adds display support for the stm32f769-disco board. It has been
tested on hardware revisions MB1225-B03 and MB1166-A09. This required
modifications to the nt35510 driver. As I do not have the Hydis HVA40WV1
display, it would be better if someone tested the driver in that
configuration.

Changes in v5:
- Add Acked-by tag of Krzysztof Kozlowski
- Add Reviewed-by tag of Linus Walleij
- Replace NT35510_ROTATE_180_SETTING with NT35510_ROTATE_0_SETTING
- Add Reviewed-by tag of Linus Walleij
- Tested-by tag of Linus Walleij
- Replace GPIOD_ASIS with GPIOD_OUT_HIGH in the call to 
devm_gpiod_get_optional().

Changes in v4:
- Put the "enum" list in alphabetical order

Changes in v3:
- Use "enum" to have less code changed

Changes in v2:
- Add Acked-by tag of Conor Dooley
- Add a dash in front of each "items:"
- Change the status of panel_backlight node to "disabled"
- Delete backlight property from panel0 node.
- Re-write the patch [7/8] "drm/panel: nt35510: refactor panel initialization"
  in the same style as the original driver in order to maintain the same
  structure.
- Re-write the patch [8/8] "drm/panel: nt35510: support FRIDA 
FRD400B25025-A-CTK"
  in the same style as the original driver.

Dario Binacchi (8):
  dt-bindings: mfd: stm32f7: Add binding definition for DSI
  ARM: dts: stm32: add DSI support on stm32f769
  ARM: dts: stm32: rename mmc_vcard to vcc-3v3 on stm32f769-disco
  ARM: dts: stm32: add display support on stm32f769-disco
  dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK
  ARM: dts: add stm32f769-disco-mb1225-revb03-mb1166-reva09
  drm/panel: nt35510: move hardwired parameters to configuration
  drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK

 .../display/panel/novatek,nt35510.yaml|   4 +-
 arch/arm/boot/dts/st/Makefile |   1 +
 ...f769-disco-mb1225-revb03-mb1166-reva09.dts |  18 +
 arch/arm/boot/dts/st/stm32f769-disco.dts  |  78 +++-
 arch/arm/boot/dts/st/stm32f769.dtsi   |  21 +
 drivers/gpu/drm/panel/panel-novatek-nt35510.c | 424 +++---
 include/dt-bindings/mfd/stm32f7-rcc.h |   1 +
 7 files changed, 485 insertions(+), 62 deletions(-)
 create mode 100644 
arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
 create mode 100644 arch/arm/boot/dts/st/stm32f769.dtsi

-- 
2.43.0

Re: [PATCH v4 8/8] drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK

[Dario Binacchi]

On Sun, Jan 7, 2024 at 9:02 PM Linus Walleij  wrote:
>
> On Sat, Jan 6, 2024 at 12:07 PM Dario Binacchi
>  wrote:
>
> > After submitting v4, I tested the driver under different conditions,
> > i. e. without enabling display support in
> > U-Boot (I also implemented a version for U-Boot, which I will send
> > only after this series is merged into
> > the Linux kernel). In that condition I encountered an issue with the reset 
> > pin.
> >
> > The minimal fix, would be this:
> >
> > diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> > b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> > index c85dd0d0829d..89ba99763468 100644
> > --- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> > +++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> > @@ -1133,7 +1133,7 @@ static int nt35510_probe(struct mipi_dsi_device *dsi)
> > if (ret)
> > return ret;
> >
> > -   nt->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
> > +   nt->reset_gpio = devm_gpiod_get_optional(dev, "reset", 
> > GPIOD_OUT_HIGH);
>
>
> This is fine, because we later on toggle reset in nt35510_power_on(),
> this just asserts the reset signal already in probe.
>
> I don't see why this would make a difference though?
>
> Is it to make the reset delete artifacts from the screen?
>
> Just explain it in the commit message.
>
> It is a bit confusing when I look at your DTS patch:
>
> https://lore.kernel.org/linux-arm-kernel/20240104084206.721824-7-dario.binac...@amarulasolutions.com/
>
> this doesn't even contain a reset GPIO, so nothing will happen
> at all?
+++ b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2023 Dario Binacchi 
+ */
+
+#include "stm32f769-disco.dts"
+

The GPIO is contained in the stm32f769-disco.dts:

panel0: panel-dsi@0 {
compatible = "orisetech,otm8009a";
reg = <0>; /* dsi virtual channel (0..3) */
reset-gpios = < 15 GPIO_ACTIVE_LOW>;
power-supply = <_3v3>;
backlight = <_backlight>;
   status = "okay";
...
};

>
> > I then tried modifying the device tree instead of the nt35510 driver.
> > In the end, I arrived
> > at this patch that leaves me with some doubts, especially regarding
> > the strict option.
> >
> > diff --git 
> > a/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
> > b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-m>
> > index 014cac192375..32ed420a6cbf 100644
> > --- a/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
> > +++ b/arch/arm/boot/dts/st/stm32f769-disco-mb1225-revb03-mb1166-reva09.dts
> > @@ -13,6 +13,17 @@  {
> > compatible = "frida,frd400b25025", "novatek,nt35510";
> > vddi-supply = <_3v3>;
> > vdd-supply = <_3v3>;
> > +   pinctrl-0 = <_reset>;
> > +   pinctrl-names = "default";
> > /delete-property/backlight;
> > /delete-property/power-supply;
> >  };
> > +
> > + {
> > +   panel_reset: panel-reset {
> > +   pins1 {
> > +   pinmux = ;
> > +   output-high;
>
> But this achieves the *opposite* of what you do in the
> other patch. This sets the reset line de-asserted since it is
> active low.
>
> Did you add the reset line to your device tree and forgot to
> set it as GPIO_ACTIVE_LOW perhaps?

panel0: panel-dsi@0 {
compatible = "orisetech,otm8009a";
reg = <0>; /* dsi virtual channel (0..3) */
reset-gpios = < 15 GPIO_ACTIVE_LOW>;

>
> > --- a/drivers/pinctrl/stm32/pinctrl-stm32.c
> > +++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
> > @@ -895,7 +895,6 @@ static const struct pinmux_ops stm32_pmx_ops = {
> > .set_mux= stm32_pmx_set_mux,
> > .gpio_set_direction = stm32_pmx_gpio_set_direction,
> > .request= stm32_pmx_request,
> > -   .strict = true,
>
> To be honest this is what I use a lot of the time, with non-strict
> pin control you can set up default GPIO values using the pin control
> device tree, and it's really simple and easy to read like that since e.g.
> in this case you set it from the panel device node which is what
> is also consuming the GPIO, so very logical. So I
> would certainly remove this .strict setting, but maybe Alexandre
> et al have a strong opinion about it.

I will send a separate RFC PATCH.

Thanks and regards,
Dario Binacchi

>
> > Another option to fix my use case without introducing regressions
> > could be to add a
> > new property to the device tree that suggests whether to call
> > devm_gpiod_get_optional()
> > with the GPIOD_ASIS or GPIOD_OUT_HIGH parameter.
> >
> > What is your opinion?
>
> It's fine either way, but just use GPIOD_OUT_HIGH and I can test
> it on my system as well, I think it's fine.
>
> Yours,
> Linus Walleij



-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binac...@amarulasolutions.com

Re: [PATCH -next] drm/nouveau: uapi: fix kerneldoc warnings

[Danilo Krummrich]

On 12/25/23 07:51, Vegard Nossum wrote:

As of commit b77fdd6a48e6 ("scripts/kernel-doc: restore warning for
Excess struct/union"), we see the following warnings when running 'make
htmldocs':

   ./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 
'DRM_NOUVEAU_VM_BIND_OP_MAP' description in 'drm_nouveau_vm_bind_op'
   ./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 
'DRM_NOUVEAU_VM_BIND_OP_UNMAP' description in 'drm_nouveau_vm_bind_op'
   ./include/uapi/drm/nouveau_drm.h:292: warning: Excess struct member 
'DRM_NOUVEAU_VM_BIND_SPARSE' description in 'drm_nouveau_vm_bind_op'
   ./include/uapi/drm/nouveau_drm.h:336: warning: Excess struct member 
'DRM_NOUVEAU_VM_BIND_RUN_ASYNC' description in 'drm_nouveau_vm_bind'

The problem is that these values are #define constants, but had kerneldoc
comments attached to them as if they were actual struct members.

There are a number of ways we could fix this, but I chose to draw
inspiration from include/uapi/drm/i915_drm.h, which pulls them into the
corresponding kerneldoc comment for the struct member that they are
intended to be used with.

To keep the diff readable, there are a number of things I _didn't_ do in
this patch, but which we should also consider:

- This is pretty good documentation, but it ends up in gpu/driver-uapi,
   which is part of subsystem-apis/ when it really ought to display under
   userspace-api/ (the "Linux kernel user-space API guide" book of the
   documentation).


I agree, it indeed looks like this would make sense, same goes for
gpu/drm-uapi.rst.

@Jani, Sima: Was this intentional? Or can we change it?



- More generally, we might want a warning if include/uapi/ files are
   kerneldoc'd outside userspace-api/.

- I'd consider it cleaner if the #defines appeared between the kerneldoc
   for the member and the member itself (which is something other DRM-
   related UAPI docs do).

- The %IDENTIFIER kerneldoc syntax is intended for "constants", and is
   more appropriate in this context than ``IDENTIFIER`` or 
   The DRM docs aren't very consistent on this.

Cc: Randy Dunlap 
Cc: Jonathan Corbet 
Signed-off-by: Vegard Nossum 


Applied to drm-misc-next, thanks!


---
  include/uapi/drm/nouveau_drm.h | 56 --
  1 file changed, 27 insertions(+), 29 deletions(-)

diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 0bade1592f34..c95ef8a4d94a 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -238,34 +238,32 @@ struct drm_nouveau_vm_init {
  struct drm_nouveau_vm_bind_op {
/**
 * @op: the operation type
+*
+* Supported values:
+*
+* %DRM_NOUVEAU_VM_BIND_OP_MAP - Map a GEM object to the GPU's VA
+* space. Optionally, the _NOUVEAU_VM_BIND_SPARSE flag can be
+* passed to instruct the kernel to create sparse mappings for the
+* given range.
+*
+* %DRM_NOUVEAU_VM_BIND_OP_UNMAP - Unmap an existing mapping in the
+* GPU's VA space. If the region the mapping is located in is a
+* sparse region, new sparse mappings are created where the unmapped
+* (memory backed) mapping was mapped previously. To remove a sparse
+* region the _NOUVEAU_VM_BIND_SPARSE must be set.
 */
__u32 op;
-/**
- * @DRM_NOUVEAU_VM_BIND_OP_MAP:
- *
- * Map a GEM object to the GPU's VA space. Optionally, the
- * _NOUVEAU_VM_BIND_SPARSE flag can be passed to instruct the kernel to
- * create sparse mappings for the given range.
- */
  #define DRM_NOUVEAU_VM_BIND_OP_MAP 0x0
-/**
- * @DRM_NOUVEAU_VM_BIND_OP_UNMAP:
- *
- * Unmap an existing mapping in the GPU's VA space. If the region the mapping
- * is located in is a sparse region, new sparse mappings are created where the
- * unmapped (memory backed) mapping was mapped previously. To remove a sparse
- * region the _NOUVEAU_VM_BIND_SPARSE must be set.
- */
  #define DRM_NOUVEAU_VM_BIND_OP_UNMAP 0x1
/**
 * @flags: the flags for a _nouveau_vm_bind_op
+*
+* Supported values:
+*
+* %DRM_NOUVEAU_VM_BIND_SPARSE - Indicates that an allocated VA
+* space region should be sparse.
 */
__u32 flags;
-/**
- * @DRM_NOUVEAU_VM_BIND_SPARSE:
- *
- * Indicates that an allocated VA space region should be sparse.
- */
  #define DRM_NOUVEAU_VM_BIND_SPARSE (1 << 8)
/**
 * @handle: the handle of the DRM GEM object to map
@@ -301,17 +299,17 @@ struct drm_nouveau_vm_bind {
__u32 op_count;
/**
 * @flags: the flags for a _nouveau_vm_bind ioctl
+*
+* Supported values:
+*
+* %DRM_NOUVEAU_VM_BIND_RUN_ASYNC - Indicates that the given VM_BIND
+* operation should be executed asynchronously by the kernel.
+*
+* If this flag is not supplied the kernel executes the associated
+* operations synchronously and doesn't accept any 

[PATCH] drm/ci: Add msm tests

[Rob Clark]

From: Rob Clark 

The msm tests should skip on non-msm hw, so I think it should be safe to
enable everywhere.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/ci/testlist.txt | 49 +
 1 file changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/ci/testlist.txt b/drivers/gpu/drm/ci/testlist.txt
index f82cd90372f4..eaeb751bb0ad 100644
--- a/drivers/gpu/drm/ci/testlist.txt
+++ b/drivers/gpu/drm/ci/testlist.txt
@@ -2910,3 +2910,52 @@ kms_writeback@writeback-invalid-parameters
 kms_writeback@writeback-fb-id
 kms_writeback@writeback-check-output
 prime_mmap_kms@buffer-sharing
+msm_shrink@copy-gpu-sanitycheck-8
+msm_shrink@copy-gpu-sanitycheck-32
+msm_shrink@copy-gpu-8
+msm_shrink@copy-gpu-32
+msm_shrink@copy-gpu-madvise-8
+msm_shrink@copy-gpu-madvise-32
+msm_shrink@copy-gpu-oom-8
+msm_shrink@copy-gpu-oom-32
+msm_shrink@copy-mmap-sanitycheck-8
+msm_shrink@copy-mmap-sanitycheck-32
+msm_shrink@copy-mmap-8
+msm_shrink@copy-mmap-32
+msm_shrink@copy-mmap-madvise-8
+msm_shrink@copy-mmap-madvise-32
+msm_shrink@copy-mmap-oom-8
+msm_shrink@copy-mmap-oom-32
+msm_shrink@copy-mmap-dmabuf-sanitycheck-8
+msm_shrink@copy-mmap-dmabuf-sanitycheck-32
+msm_shrink@copy-mmap-dmabuf-8
+msm_shrink@copy-mmap-dmabuf-32
+msm_shrink@copy-mmap-dmabuf-madvise-8
+msm_shrink@copy-mmap-dmabuf-madvise-32
+msm_shrink@copy-mmap-dmabuf-oom-8
+msm_shrink@copy-mmap-dmabuf-oom-32
+msm_mapping@ring
+msm_mapping@sqefw
+msm_mapping@shadow
+msm_submitoverhead@submitbench-10-bos
+msm_submitoverhead@submitbench-10-bos-no-implicit-sync
+msm_submitoverhead@submitbench-100-bos
+msm_submitoverhead@submitbench-100-bos-no-implicit-sync
+msm_submitoverhead@submitbench-250-bos
+msm_submitoverhead@submitbench-250-bos-no-implicit-sync
+msm_submitoverhead@submitbench-500-bos
+msm_submitoverhead@submitbench-500-bos-no-implicit-sync
+msm_submitoverhead@submitbench-1000-bos
+msm_submitoverhead@submitbench-1000-bos-no-implicit-sync
+msm_recovery@hangcheck
+msm_recovery@gpu-fault
+msm_recovery@gpu-fault-parallel
+msm_recovery@iova-fault
+msm_submit@empty-submit
+msm_submit@invalid-queue-submit
+msm_submit@invalid-flags-submit
+msm_submit@invalid-in-fence-submit
+msm_submit@invalid-duplicate-bo-submit
+msm_submit@invalid-cmd-idx-submit
+msm_submit@invalid-cmd-type-submit
+msm_submit@valid-submit
-- 
2.43.0

Re: [PATCH v3 3/4] usb: gadget: functionfs: Add DMABUF import interface

[Daniel Vetter]

On Mon, Jan 08, 2024 at 05:27:33PM +0100, Paul Cercueil wrote:
> Le lundi 08 janvier 2024 à 16:29 +0100, Daniel Vetter a écrit :
> > On Mon, Jan 08, 2024 at 03:21:21PM +0100, Paul Cercueil wrote:
> > > Hi Daniel (Sima?),
> > > 
> > > Le lundi 08 janvier 2024 à 13:39 +0100, Daniel Vetter a écrit :
> > > > On Mon, Jan 08, 2024 at 01:00:55PM +0100, Paul Cercueil wrote:
> > > > > +static void ffs_dmabuf_signal_done(struct ffs_dma_fence
> > > > > *dma_fence, int ret)
> > > > > +{
> > > > > + struct ffs_dmabuf_priv *priv = dma_fence->priv;
> > > > > + struct dma_fence *fence = _fence->base;
> > > > > +
> > > > > + dma_fence_get(fence);
> > > > > + fence->error = ret;
> > > > > + dma_fence_signal(fence);
> > > > > +
> > > > > + dma_buf_unmap_attachment(priv->attach, dma_fence->sgt,
> > > > > dma_fence->dir);
> > > > > + dma_fence_put(fence);
> > > > > + ffs_dmabuf_put(priv->attach);
> > > > 
> > > > So this can in theory take the dma_resv lock, and if the usb
> > > > completion
> > > > isn't an unlimited worker this could hold up completion of future
> > > > dma_fence, resulting in a deadlock.
> > > > 
> > > > Needs to be checked how usb works, and if stalling indefinitely
> > > > in
> > > > the
> > > > io_complete callback can hold up the usb stack you need to:
> > > > 
> > > > - drop a dma_fence_begin/end_signalling annotations in here
> > > > - pull out the unref stuff into a separate preallocated worker
> > > > (or at
> > > >   least the final unrefs for ffs_dma_buf).
> > > 
> > > Only ffs_dmabuf_put() can attempt to take the dma_resv and would
> > > have
> > > to be in a worker, right? Everything else would be inside the
> > > dma_fence_begin/end_signalling() annotations?
> > 
> > Yup. Also I noticed that unlike the iio patches you don't have the
> > dma_buf_unmap here in the completion path (or I'm blind?), which
> > helps a
> > lot with avoiding trouble.
> 
> They both call dma_buf_unmap_attachment() in the "signal done"
> callback, the only difference I see is that it is called after the
> dma_fence_put() in the iio patches, while it's called before
> dma_fence_put() here.

I was indeed blind ...

So the trouble is this wont work because:
- dma_buf_unmap_attachment() requires dma_resv_lock. This is a somewhat
  recent-ish change from 47e982d5195d ("dma-buf: Move
  dma_buf_map_attachment() to dynamic locking specification"), so maybe
  old kernel or you don't have full lockdep enabled to get the right
  splat.

- dma_fence critical section forbids dma_resv_lock

Which means you need to move this out, but then there's the potential
cache management issue. Which current gpu drivers just kinda ignore
because it doesn't matter for current use-case, they all cache the mapping
for about as long as the attachment exists. You might want to do the same,
unless that somehow breaks a use-case you have, I have no idea about that.
If something breaks with unmap_attachment moved out of the fence handling
then I guess it's high time to add separate cache-management only to
dma_buf (and that's probably going to be quite some wiring up, not sure
even how easy that would be to do nor what exactly the interface should
look like).

Cheers, Sima
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 7/7] drm/vkms: Create KUnit tests for YUV conversions

[Arthur Grillo]

On 08/01/24 07:15, Maxime Ripard wrote:
> Hi Arthur,
> 
> On Fri, Jan 05, 2024 at 01:35:08PM -0300, Arthur Grillo wrote:
>> diff --git a/drivers/gpu/drm/vkms/vkms_formats.c 
>> b/drivers/gpu/drm/vkms/vkms_formats.c
>> index b654b6661a20..11df990a0fa9 100644
>> --- a/drivers/gpu/drm/vkms/vkms_formats.c
>> +++ b/drivers/gpu/drm/vkms/vkms_formats.c
>> @@ -440,3 +440,7 @@ void *get_pixel_write_function(u32 format)
>>  return NULL;
>>  }
>>  }
>> +
>> +#ifdef CONFIG_DRM_VKMS_KUNIT_TESTS
>> +#include "tests/vkms_format_test.c"
>> +#endif
> 
> I assume this is due to testing a static function?

Yeah, you're right.

> 
> If so, the preferred way nowadays is to use EXPORT_SYMBOL_IF_KUNIT or
> EXPORT_SYMBOL_FOR_TESTS_ONLY if it's DRM/KMS only.

Oh, I didn't know about that. I think I will use EXPORT_SYMBOL_IF_KUNIT
as you can use VISIBLE_IF_KUNIT to maintain the function static if the
test is not used.

~Arthur Grillo
> 
> Maxime

Re: [PATCH v3 3/4] drm/msm: add a kernel param to select between MDP5 and DPU drivers

[Dmitry Baryshkov]

On Mon, 8 Jan 2024 at 19:57, Carl Vanderlip  wrote:
>
>
>
> On 1/5/2024 4:38 PM, Dmitry Baryshkov wrote:
> > On Sat, 6 Jan 2024 at 02:04, Carl Vanderlip  wrote:
> >>
> >>
> >> On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:
> >>> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> >>> index 50b65ffc24b1..ef57586fbeca 100644
> >>> --- a/drivers/gpu/drm/msm/msm_drv.c
> >>> +++ b/drivers/gpu/drm/msm/msm_drv.c
> >>> @@ -969,6 +969,37 @@ static int add_components_mdp(struct device 
> >>> *master_dev,
> >>>return 0;
> >>>}
> >>>
> >>> +#if !IS_REACHABLE(CONFIG_DRM_MSM_MDP5) || 
> >>> !IS_REACHABLE(CONFIG_DRM_MSM_DPU)
> >>> +bool msm_disp_drv_should_bind(struct device *dev, bool mdp5_driver)
> >>> +{
> >>> + /* If just a single driver is enabled, use it no matter what */
> >>> + return true;
> >>> +}
> >>
> >> This will cause both MDP/DPU probes to return -ENODEV, rather than
> >> select the enabled one.
> >
> > No. The code (e.g. for DPU) is:
> >
> > if (!msm_disp_drv_should_bind(>dev, true))
> >  return -ENODEV;
> >
> > So the driver returns -ENODEV if msm_disp_drv_should_bind() returns
> > false. Which is logical from the function name point of view.
> >
>
> but msm_disp_drv_should_bind() is returning true in the #if !REACHABLE()
> case?
>
> at minimum the comment is incorrect since returning true causes the
> driver to NOT be used.

No. Returning _false_ causes the driver to not be used.

-- 
With best wishes
Dmitry

[PATCH RFC v2 03/11] ARM: dts: omap3: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entries to base OMAP3 dtsi files.

Signed-off-by: Andrew Davis 
---
 arch/arm/boot/dts/ti/omap/am3517.dtsi   | 11 ++-
 arch/arm/boot/dts/ti/omap/omap34xx.dtsi | 11 ++-
 arch/arm/boot/dts/ti/omap/omap36xx.dtsi |  9 +
 3 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/am3517.dtsi 
b/arch/arm/boot/dts/ti/omap/am3517.dtsi
index 77e58e686fb17..19aad715dff70 100644
--- a/arch/arm/boot/dts/ti/omap/am3517.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am3517.dtsi
@@ -162,12 +162,13 @@ sgx_module: target-module@5000 {
clock-names = "fck", "ick";
#address-cells = <1>;
#size-cells = <1>;
-   ranges = <0 0x5000 0x4000>;
+   ranges = <0 0x5000 0x1>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu@0 {
+   compatible = "ti,omap3430-gpu", 
"img,powervr-sgx530";
+   reg = <0x0 0x1>; /* 64kB */
+   interrupts = <21>;
+   };
};
};
 };
diff --git a/arch/arm/boot/dts/ti/omap/omap34xx.dtsi 
b/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
index fc7233ac183a8..acdd0ee34421d 100644
--- a/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap34xx.dtsi
@@ -164,12 +164,13 @@ sgx_module: target-module@5000 {
clock-names = "fck", "ick";
#address-cells = <1>;
#size-cells = <1>;
-   ranges = <0 0x5000 0x4000>;
+   ranges = <0 0x5000 0x1>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu@0 {
+   compatible = "ti,omap3430-gpu", 
"img,powervr-sgx530";
+   reg = <0x0 0x1>; /* 64kB */
+   interrupts = <21>;
+   };
};
};
 
diff --git a/arch/arm/boot/dts/ti/omap/omap36xx.dtsi 
b/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
index e6d8070c1bf88..c3d79ecd56e39 100644
--- a/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap36xx.dtsi
@@ -211,10 +211,11 @@ sgx_module: target-module@5000 {
#size-cells = <1>;
ranges = <0 0x5000 0x200>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu@0 {
+   compatible = "ti,omap3630-gpu", 
"img,powervr-sgx530";
+   reg = <0x0 0x200>; /* 32MB */
+   interrupts = <21>;
+   };
};
};
 
-- 
2.39.2

[PATCH RFC v2 00/11] Device tree support for Imagination Series5 GPU

[Andrew Davis]

Hello all,

I know this has been tried before[0], but given the recent upstreaming of
the Series6+ GPU bindings I figured it might be time to give the Series5
bindings another try.

While there is currently no mainline driver for these binding, there is an
open source out-of-tree kernel-side driver available[1]. Having a stable
and upstream binding for these devices allows us to describe this hardware
in device tree.

This is my vision for how these bindings should look, along with some
example uses in several SoC DT files. The compatible names have been
updated to match what was decided on for Series6+, but otherwise most
is the same as we have been using in our vendor tree for many years.

Thanks,
Andrew

Based on next-20240108.

[0]: https://lkml.org/lkml/2020/4/24/1222
[1]: https://github.com/openpvrsgx-devgroup

Changes for RFC v2:
 - Added patch to rename Rogue+ binding to img,powervr-rogue.yaml
 - Locked all property item counts
 - Removed nodename pattern check

Andrew Davis (11):
  dt-bindings: gpu: Rename img,powervr to img,powervr-rogue
  dt-bindings: gpu: Add PowerVR Series5 SGX GPUs
  ARM: dts: omap3: Add device tree entry for SGX GPU
  ARM: dts: omap4: Add device tree entry for SGX GPU
  ARM: dts: omap5: Add device tree entry for SGX GPU
  ARM: dts: AM33xx: Add device tree entry for SGX GPU
  ARM: dts: AM437x: Add device tree entry for SGX GPU
  ARM: dts: DRA7xx: Add device tree entry for SGX GPU
  arm64: dts: ti: k3-am654-main: Add device tree entry for SGX GPU
  ARM: dts: sun6i: Add device tree entry for SGX GPU
  MIPS: DTS: jz4780: Add device tree entry for SGX GPU

 ...mg,powervr.yaml => img,powervr-rogue.yaml} |   4 +-
 .../bindings/gpu/img,powervr-sgx.yaml | 124 ++
 MAINTAINERS   |   3 +-
 arch/arm/boot/dts/allwinner/sun6i-a31.dtsi|   9 ++
 arch/arm/boot/dts/ti/omap/am33xx.dtsi |   9 +-
 arch/arm/boot/dts/ti/omap/am3517.dtsi |  11 +-
 arch/arm/boot/dts/ti/omap/am4372.dtsi |   6 +
 arch/arm/boot/dts/ti/omap/dra7.dtsi   |   9 +-
 arch/arm/boot/dts/ti/omap/omap34xx.dtsi   |  11 +-
 arch/arm/boot/dts/ti/omap/omap36xx.dtsi   |   9 +-
 arch/arm/boot/dts/ti/omap/omap4.dtsi  |   9 +-
 arch/arm/boot/dts/ti/omap/omap5.dtsi  |   9 +-
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi  |   7 +
 arch/mips/boot/dts/ingenic/jz4780.dtsi|  11 ++
 14 files changed, 201 insertions(+), 30 deletions(-)
 rename Documentation/devicetree/bindings/gpu/{img,powervr.yaml => 
img,powervr-rogue.yaml} (91%)
 create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml

-- 
2.39.2

[PATCH RFC v2 04/11] ARM: dts: omap4: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base OMAP4 dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/arm/boot/dts/ti/omap/omap4.dtsi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/omap4.dtsi 
b/arch/arm/boot/dts/ti/omap/omap4.dtsi
index 2bbff9032be3e..559b2bfe4ca7c 100644
--- a/arch/arm/boot/dts/ti/omap/omap4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4.dtsi
@@ -501,10 +501,11 @@ sgx_module: target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu@0 {
+   compatible = "ti,omap4430-gpu", 
"img,powervr-sgx540";
+   reg = <0x0 0x200>; /* 32MB */
+   interrupts = ;
+   };
};
 
/*
-- 
2.39.2

[PATCH RFC v2 11/11] MIPS: DTS: jz4780: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base jz4780 dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 18a85ce38..5ea6833f5e872 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -460,6 +460,17 @@ hdmi: hdmi@1018 {
status = "disabled";
};
 
+   gpu: gpu@1304 {
+   compatible = "ingenic,jz4780-gpu", "img,powervr-sgx540";
+   reg = <0x1304 0x4000>;
+
+   clocks = < JZ4780_CLK_GPU>;
+   clock-names = "core";
+
+   interrupt-parent = <>;
+   interrupts = <63>;
+   };
+
lcdc0: lcdc0@1305 {
compatible = "ingenic,jz4780-lcd";
reg = <0x1305 0x1800>;
-- 
2.39.2

[PATCH RFC v2 08/11] ARM: dts: DRA7xx: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base DRA7x dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/arm/boot/dts/ti/omap/dra7.dtsi | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/ti/omap/dra7.dtsi 
b/arch/arm/boot/dts/ti/omap/dra7.dtsi
index 6509c742fb58c..8527643cb69a8 100644
--- a/arch/arm/boot/dts/ti/omap/dra7.dtsi
+++ b/arch/arm/boot/dts/ti/omap/dra7.dtsi
@@ -850,12 +850,19 @@ target-module@5600 {
;
ti,sysc-sidle = ,
,
-   ;
+   ,
+   ;
clocks = <_clkctrl DRA7_GPU_CLKCTRL 0>;
clock-names = "fck";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
+
+   gpu@0 {
+   compatible = "ti,am5728-gpu", 
"img,powervr-sgx544";
+   reg = <0x0 0x1>; /* 64kB */
+   interrupts = ;
+   };
};
 
crossbar_mpu: crossbar@4a002a48 {
-- 
2.39.2

[PATCH RFC v2 06/11] ARM: dts: AM33xx: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base AM33xx dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/arm/boot/dts/ti/omap/am33xx.dtsi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi 
b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index 5b9e01a8aa5d5..989d5a6edeed9 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
@@ -640,10 +640,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x100>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu@0 {
+   compatible = "ti,omap3630-gpu", 
"img,powervr-sgx530";
+   reg = <0x0 0x1>; /* 64kB */
+   interrupts = <37>;
+   };
};
};
 };
-- 
2.39.2

[PATCH RFC v2 09/11] arm64: dts: ti: k3-am654-main: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base AM654 dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi 
b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index fcea544656360..64b52c8dafc6c 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -1050,6 +1050,13 @@ dss_ports: ports {
};
};
 
+   gpu: gpu@700 {
+   compatible = "ti,am6548-gpu", "img,powervr-sgx544";
+   reg = <0x0 0x700 0x0 0x1>;
+   interrupts = ;
+   power-domains = <_pds 65 TI_SCI_PD_EXCLUSIVE>;
+   };
+
ehrpwm0: pwm@300 {
compatible = "ti,am654-ehrpwm", "ti,am3352-ehrpwm";
#pwm-cells = <3>;
-- 
2.39.2

[PATCH RFC v2 10/11] ARM: dts: sun6i: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base sun6i-a31 dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/arm/boot/dts/allwinner/sun6i-a31.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi 
b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
index 5cce4918f84c9..e6998783b89aa 100644
--- a/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun6i-a31.dtsi
@@ -962,6 +962,15 @@ mdio: mdio {
};
};
 
+   gpu: gpu@1c4 {
+   compatible = "allwinner,sun6i-a31-gpu", 
"img,powervr-sgx544";
+   reg = <0x01c4 0x1>;
+   interrupts = ;
+   clocks = < CLK_GPU_CORE>, < CLK_GPU_MEMORY>;
+   clock-names = "core", "mem";
+   status = "disabled";
+   };
+
crypto: crypto-engine@1c15000 {
compatible = "allwinner,sun6i-a31-crypto",
 "allwinner,sun4i-a10-crypto";
-- 
2.39.2

[PATCH RFC v2 01/11] dt-bindings: gpu: Rename img, powervr to img, powervr-rogue

[Andrew Davis]

Signed-off-by: Andrew Davis 
---
 .../bindings/gpu/{img,powervr.yaml => img,powervr-rogue.yaml} | 4 ++--
 MAINTAINERS   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename Documentation/devicetree/bindings/gpu/{img,powervr.yaml => 
img,powervr-rogue.yaml} (91%)

diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml 
b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
similarity index 91%
rename from Documentation/devicetree/bindings/gpu/img,powervr.yaml
rename to Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
index a13298f1a1827..03a8308b41ae7 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -2,10 +2,10 @@
 # Copyright (c) 2023 Imagination Technologies Ltd.
 %YAML 1.2
 ---
-$id: http://devicetree.org/schemas/gpu/img,powervr.yaml#
+$id: http://devicetree.org/schemas/gpu/img,powervr-rogue.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Imagination Technologies PowerVR and IMG GPU
+title: Imagination Technologies PowerVR Rogue and IMG GPUs
 
 maintainers:
   - Frank Binns 
diff --git a/MAINTAINERS b/MAINTAINERS
index fa67e2624723f..5b205795da04e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10461,7 +10461,7 @@ M:  Donald Robson 
 M: Matt Coster 
 S: Supported
 T: git git://anongit.freedesktop.org/drm/drm-misc
-F: Documentation/devicetree/bindings/gpu/img,powervr.yaml
+F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
 F: Documentation/gpu/imagination/
 F: drivers/gpu/drm/imagination/
 F: include/uapi/drm/pvr_drm.h
-- 
2.39.2

[PATCH RFC v2 02/11] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Andrew Davis]

The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
multiple vendors. Describe how the SGX GPU is integrated in these SoC,
including register space and interrupts. Clocks, reset, and power domain
information is SoC specific.

Signed-off-by: Andrew Davis 
---
 .../bindings/gpu/img,powervr-sgx.yaml | 124 ++
 MAINTAINERS   |   1 +
 2 files changed, 125 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml

diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml 
b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
new file mode 100644
index 0..bb821e1184de9
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (c) 2023 Imagination Technologies Ltd.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpu/img,powervr-sgx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Imagination Technologies PowerVR SGX GPUs
+
+maintainers:
+  - Frank Binns 
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - enum:
+  - ti,omap3430-gpu # Rev 121
+  - ti,omap3630-gpu # Rev 125
+  - const: img,powervr-sgx530
+  - items:
+  - enum:
+  - ingenic,jz4780-gpu # Rev 130
+  - ti,omap4430-gpu # Rev 120
+  - const: img,powervr-sgx540
+  - items:
+  - enum:
+  - allwinner,sun6i-a31-gpu # MP2 Rev 115
+  - ti,omap4470-gpu # MP1 Rev 112
+  - ti,omap5432-gpu # MP2 Rev 105
+  - ti,am5728-gpu # MP2 Rev 116
+  - ti,am6548-gpu # MP1 Rev 117
+  - const: img,powervr-sgx544
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks: true
+
+  clock-names:
+minItems: 1
+items:
+  - const: core
+  - const: mem
+  - const: sys
+
+  power-domains:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+
+additionalProperties: false
+
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: ti,am6548-gpu
+then:
+  required:
+- power-domains
+else:
+  properties:
+power-domains: false
+  - if:
+  properties:
+compatible:
+  contains:
+enum:
+  - allwinner,sun6i-a31-gpu
+  - ingenic,jz4780-gpu
+then:
+  allOf:
+- if:
+properties:
+  compatible:
+contains:
+  const: allwinner,sun6i-a31-gpu
+  then:
+properties:
+  clocks:
+minItems: 2
+maxItems: 2
+  clock-names:
+minItems: 2
+maxItems: 2
+- if:
+properties:
+  compatible:
+contains:
+  const: ingenic,jz4780-gpu
+  then:
+properties:
+  clocks:
+maxItems: 1
+  clock-names:
+maxItems: 1
+  required:
+- clocks
+- clock-names
+else:
+  properties:
+clocks: false
+clock-names: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+gpu@700 {
+compatible = "ti,am6548-gpu", "img,powervr-sgx544";
+reg = <0x700 0x1>;
+interrupts = ;
+power-domains = <_pds 65 TI_SCI_PD_EXCLUSIVE>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b205795da04e..00ba13e019fa6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10462,6 +10462,7 @@ M:  Matt Coster 
 S: Supported
 T: git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
+F: Documentation/devicetree/bindings/gpu/img,powervr-sgx.yaml
 F: Documentation/gpu/imagination/
 F: drivers/gpu/drm/imagination/
 F: include/uapi/drm/pvr_drm.h
-- 
2.39.2

[PATCH RFC v2 05/11] ARM: dts: omap5: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base OMAP5 dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/arm/boot/dts/ti/omap/omap5.dtsi | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/ti/omap/omap5.dtsi 
b/arch/arm/boot/dts/ti/omap/omap5.dtsi
index bac6fa8387936..6a66214ad0e2f 100644
--- a/arch/arm/boot/dts/ti/omap/omap5.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap5.dtsi
@@ -453,10 +453,11 @@ target-module@5600 {
#size-cells = <1>;
ranges = <0 0x5600 0x200>;
 
-   /*
-* Closed source PowerVR driver, no child device
-* binding or driver in mainline
-*/
+   gpu@0 {
+   compatible = "ti,omap5432-gpu", 
"img,powervr-sgx544";
+   reg = <0x0 0x200>; /* 32MB */
+   interrupts = ;
+   };
};
 
target-module@5800 {
-- 
2.39.2

[PATCH RFC v2 07/11] ARM: dts: AM437x: Add device tree entry for SGX GPU

[Andrew Davis]

Add SGX GPU device entry to base AM437x dtsi file.

Signed-off-by: Andrew Davis 
---
 arch/arm/boot/dts/ti/omap/am4372.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/ti/omap/am4372.dtsi 
b/arch/arm/boot/dts/ti/omap/am4372.dtsi
index 9d2c064534f7d..5fd1b380ece62 100644
--- a/arch/arm/boot/dts/ti/omap/am4372.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am4372.dtsi
@@ -719,6 +719,12 @@ target-module@5600 {
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x5600 0x100>;
+
+   gpu@0 {
+   compatible = "ti,omap3630-gpu", 
"img,powervr-sgx530";
+   reg = <0x0 0x1>; /* 64kB */
+   interrupts = ;
+   };
};
};
 };
-- 
2.39.2

Re: [PATCH v3 2/4] drm/panel: Add driver for BOE TH101MB31IG002-28A panel

[Jessica Zhang]

On 1/2/2024 8:15 AM, Manuel Traut wrote:

From: Alexander Warnecke 

The BOE TH101MB31IG002-28A panel is a WXGA panel.
It is used in Pine64 PineTab2 and PineTab-V.

Signed-off-by: Alexander Warnecke 
Signed-off-by: Manuel Traut 
---
  drivers/gpu/drm/panel/Kconfig  |  11 +
  drivers/gpu/drm/panel/Makefile |   1 +
  .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 322 +
  3 files changed, 334 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..927ddd10e688 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
  24 bit RGB per pixel. It provides a MIPI DSI interface to
  the host and has a built-in LED backlight.
  
+config DRM_PANEL_BOE_TH101MB31UIG002_28A

+   tristate "Boe TH101MB31UIG002-28A panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Boe
+ TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
+ resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
+ interface to the host and has a built-in LED backlight.
+
  config DRM_PANEL_BOE_TV101WUM_NL6
tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..dd6e1ac9d0a2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += 
panel-asus-z00t-tm5p5-n35596.
  obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
  obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
  obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) += 
panel-boe-th101mb31ig002-28a.o
  obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
  obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
  obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c 
b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
new file mode 100644
index ..763e9f8342d3
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Alexander Warnecke 
+ * Copyright (c) 2023 Manuel Traut 
+ * Copyright (c) 2023 Dang Huynh 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+struct boe_th101mb31ig002 {
+   struct drm_panel panel;
+
+   struct mipi_dsi_device *dsi;
+
+   struct regulator *power;
+   struct gpio_desc *enable;
+   struct gpio_desc *reset;
+
+   enum drm_panel_orientation orientation;
+};
+
+static void boe_th101mb31ig002_reset(struct boe_th101mb31ig002 *ctx)
+{
+   gpiod_direction_output(ctx->reset, 0);
+   usleep_range(10, 100);
+   gpiod_direction_output(ctx->reset, 1);
+   usleep_range(10, 100);
+   gpiod_direction_output(ctx->reset, 0);
+   usleep_range(5000, 6000);
+}
+
+static int boe_th101mb31ig002_enable(struct drm_panel *panel)
+{
+   struct boe_th101mb31ig002 *ctx = container_of(panel,
+ struct boe_th101mb31ig002,
+ panel);
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   struct device *dev = >dev;
+   int ret;
+
+   mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
+   mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
+   mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
+   mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14);
+   mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x56, 0x53, 0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xB4, 0x33, 0x30, 0x04);
+   mipi_dsi_dcs_write_seq(dsi, 0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10,
+   0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xB8, 0x05, 0x12, 0x29, 0x49, 0x48, 0x00,
+   0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xB9, 0x7C, 0x65, 0x55, 0x49, 0x46, 0x36,
+   0x3B, 0x24, 0x3D, 0x3C, 0x3D, 0x5C, 0x4C,
+   0x55, 0x47, 0x46, 0x39, 0x26, 0x06, 0x7C,
+   0x65, 0x55, 0x49, 0x46, 0x36, 0x3B, 0x24,
+   0x3D, 0x3C, 0x3D, 0x5C, 0x4C, 0x55, 0x47,
+   0x46, 0x39, 0x26, 0x06);
+   mipi_dsi_dcs_write_seq(dsi, 0x00, 0xFF, 0x87, 0x12, 0x34, 0x44, 0x44,
+   0x44, 0x44, 0x98, 0x04, 0x98, 0x04, 0x0F,
+   0x00, 0x00, 0xC1);


Hi Manuel,

(I'm assuming the 

Re: [PATCH 1/3] drm/nouveau: include drm/drm_edid.h only where needed

[Danilo Krummrich]

On 1/4/24 21:16, Jani Nikula wrote:

Including drm_edid.h from nouveau_connector.h causes the rebuild of 15
files when drm_edid.h is modified, while there are only a few files that
actually need to include drm_edid.h.

Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Danilo Krummrich 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jani Nikula 


Reviewed-by: Danilo Krummrich 


---
  drivers/gpu/drm/nouveau/dispnv50/head.c | 1 +
  drivers/gpu/drm/nouveau/nouveau_connector.h | 2 +-
  2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 5f490fbf1877..83355dbc15ee 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -32,6 +32,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include "nouveau_connector.h"
  
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h b/drivers/gpu/drm/nouveau/nouveau_connector.h

index a2df4918340c..0608cabed058 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.h
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.h
@@ -35,7 +35,6 @@
  
  #include 

  #include 
-#include 
  #include 
  #include 
  
@@ -44,6 +43,7 @@
  
  struct nvkm_i2c_port;

  struct dcb_output;
+struct edid;
  
  #ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT

  struct nouveau_backlight {

Re: [PATCH v3 3/4] drm/msm: add a kernel param to select between MDP5 and DPU drivers

[Carl Vanderlip]

On 1/5/2024 4:38 PM, Dmitry Baryshkov wrote:

On Sat, 6 Jan 2024 at 02:04, Carl Vanderlip  wrote:



On 1/5/2024 3:34 PM, Dmitry Baryshkov wrote:

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 50b65ffc24b1..ef57586fbeca 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -969,6 +969,37 @@ static int add_components_mdp(struct device *master_dev,
   return 0;
   }

+#if !IS_REACHABLE(CONFIG_DRM_MSM_MDP5) || !IS_REACHABLE(CONFIG_DRM_MSM_DPU)
+bool msm_disp_drv_should_bind(struct device *dev, bool mdp5_driver)
+{
+ /* If just a single driver is enabled, use it no matter what */
+ return true;
+}


This will cause both MDP/DPU probes to return -ENODEV, rather than
select the enabled one.


No. The code (e.g. for DPU) is:

if (!msm_disp_drv_should_bind(>dev, true))
 return -ENODEV;

So the driver returns -ENODEV if msm_disp_drv_should_bind() returns
false. Which is logical from the function name point of view.



but msm_disp_drv_should_bind() is returning true in the #if !REACHABLE() 
case?


at minimum the comment is incorrect since returning true causes the
driver to NOT be used.

-Carl V.

Re: [PATCH v2] drm/amdkfd: fixes for HMM mem allocation

[Felix Kuehling]

On 2024-01-07 08:07, Dafna Hirschfeld wrote:

Fix err return value and reset pgmap->type after checking it.

Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling 
Signed-off-by: Dafna Hirschfeld 
---
v2: remove unrelated DOC fix and add 'Fixes' tag.


Thank you. I'm going to apply this patch to amd-staging-drm-next.

Regards,
  Felix




  drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 6c25dab051d5..b8680e0753ca 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -1021,7 +1021,7 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
} else {
res = devm_request_free_mem_region(adev->dev, _resource, 
size);
if (IS_ERR(res))
-   return -ENOMEM;
+   return PTR_ERR(res);
pgmap->range.start = res->start;
pgmap->range.end = res->end;
pgmap->type = MEMORY_DEVICE_PRIVATE;
@@ -1037,10 +1037,10 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
-   /* Disable SVM support capability */
-   pgmap->type = 0;
if (pgmap->type == MEMORY_DEVICE_PRIVATE)
devm_release_mem_region(adev->dev, res->start, 
resource_size(res));
+   /* Disable SVM support capability */
+   pgmap->type = 0;
return PTR_ERR(r);
}
  

Re: [PATCH 1/4] drm/nouveau/disp: don't misuse kernel-doc comments

[Danilo Krummrich]

On 1/1/24 00:36, Randy Dunlap wrote:

Change kernel-doc "/**" comments to common "/*" comments to prevent
kernel-doc warnings:

crtc.c:453: warning: This comment starts with '/**', but isn't a kernel-doc 
comment. Refer Documentation/doc-guide/kernel-doc.rst
  * Sets up registers for the given mode/adjusted_mode pair.
crtc.c:453: warning: missing initial short description on line:
  * Sets up registers for the given mode/adjusted_mode pair.
crtc.c:629: warning: This comment starts with '/**', but isn't a kernel-doc 
comment. Refer Documentation/doc-guide/kernel-doc.rst
  * Sets up registers for the given mode/adjusted_mode pair.
crtc.c:629: warning: missing initial short description on line:
  * Sets up registers for the given mode/adjusted_mode pair.

Signed-off-by: Randy Dunlap 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Danilo Krummrich 
Cc: nouv...@lists.freedesktop.org
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 


Series applied to drm-misc-next, thanks!


---
  drivers/gpu/drm/nouveau/dispnv04/crtc.c |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff -- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -449,7 +449,7 @@ nv_crtc_mode_set_vga(struct drm_crtc *cr
regp->Attribute[NV_CIO_AR_CSEL_INDEX] = 0x00;
  }
  
-/**

+/*
   * Sets up registers for the given mode/adjusted_mode pair.
   *
   * The clocks, CRTCs and outputs attached to this CRTC must be off.
@@ -625,7 +625,7 @@ nv_crtc_swap_fbs(struct drm_crtc *crtc,
return ret;
  }
  
-/**

+/*
   * Sets up registers for the given mode/adjusted_mode pair.
   *
   * The clocks, CRTCs and outputs attached to this CRTC must be off.

Re: [PATCH] drm/amd/display: cleanup inconsistent indenting in amdgpu_dm_color

[Rodrigo Siqueira Jordao]

On 1/5/24 15:02, Melissa Wen wrote:

smatch warnings:
amdgpu_dm_update_plane_color_mgmt() warn: inconsistent indenting

Reported-by: kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202401051643.ppdbmg1u-...@intel.com/
Signed-off-by: Melissa Wen 
---
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
index 9b527bffe11a..c87b64e464ed 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
@@ -1239,7 +1239,7 @@ int amdgpu_dm_update_plane_color_mgmt(struct 
dm_crtc_state *crtc,
if (has_crtc_cm_degamma && ret != -EINVAL) {
drm_dbg_kms(crtc->base.crtc->dev,
"doesn't support plane and CRTC degamma at the same 
time\n");
-   return -EINVAL;
+   return -EINVAL;
}
  
  	/* If we are here, it means we don't have plane degamma settings, check


Reviewed-by: Rodrigo Siqueira 

Change also applied to asdn.

Thanks
Siqueira

Re: [PATCH] drm/nouveau/bios/init: drop kernel-doc notation

[Danilo Krummrich]

On 12/16/23 21:11, Randy Dunlap wrote:

The "/**" comments in this file are not kernel-doc comments. They are
used on static functions which can have kernel-doc comments, but that
is not the primary focus of kernel-doc comments.
Since these comments are incomplete for kernel-doc notation, remove
the kernel-doc "/**" markers and make them common comments.

This prevents scripts/kernel-doc from issuing 68 warnings:

init.c:584: warning: Function parameter or member 'init' not described in 
'init_reserved'

and 67 warnings like this one:
init.c:611: warning: expecting prototype for INIT_DONE(). Prototype was for 
init_done() instead

Signed-off-by: Randy Dunlap 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Danilo Krummrich 
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 


Applied to drm-misc-next, thanks!


---
  drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c |  136 +++---
  1 file changed, 68 insertions(+), 68 deletions(-)

diff -- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -575,7 +575,7 @@ init_tmds_reg(struct nvbios_init *init,
   * init opcode handlers
   
*/
  
-/**

+/*
   * init_reserved - stub for various unknown/unused single-byte opcodes
   *
   */
@@ -602,7 +602,7 @@ init_reserved(struct nvbios_init *init)
init->offset += length;
  }
  
-/**

+/*
   * INIT_DONE - opcode 0x71
   *
   */
@@ -613,7 +613,7 @@ init_done(struct nvbios_init *init)
init->offset = 0x;
  }
  
-/**

+/*
   * INIT_IO_RESTRICT_PROG - opcode 0x32
   *
   */
@@ -650,7 +650,7 @@ init_io_restrict_prog(struct nvbios_init
trace("}]\n");
  }
  
-/**

+/*
   * INIT_REPEAT - opcode 0x33
   *
   */
@@ -676,7 +676,7 @@ init_repeat(struct nvbios_init *init)
init->repeat = repeat;
  }
  
-/**

+/*
   * INIT_IO_RESTRICT_PLL - opcode 0x34
   *
   */
@@ -716,7 +716,7 @@ init_io_restrict_pll(struct nvbios_init
trace("}]\n");
  }
  
-/**

+/*
   * INIT_END_REPEAT - opcode 0x36
   *
   */
@@ -732,7 +732,7 @@ init_end_repeat(struct nvbios_init *init
}
  }
  
-/**

+/*
   * INIT_COPY - opcode 0x37
   *
   */
@@ -759,7 +759,7 @@ init_copy(struct nvbios_init *init)
init_wrvgai(init, port, index, data);
  }
  
-/**

+/*
   * INIT_NOT - opcode 0x38
   *
   */
@@ -771,7 +771,7 @@ init_not(struct nvbios_init *init)
init_exec_inv(init);
  }
  
-/**

+/*
   * INIT_IO_FLAG_CONDITION - opcode 0x39
   *
   */
@@ -788,7 +788,7 @@ init_io_flag_condition(struct nvbios_ini
init_exec_set(init, false);
  }
  
-/**

+/*
   * INIT_GENERIC_CONDITION - opcode 0x3a
   *
   */
@@ -840,7 +840,7 @@ init_generic_condition(struct nvbios_ini
}
  }
  
-/**

+/*
   * INIT_IO_MASK_OR - opcode 0x3b
   *
   */
@@ -859,7 +859,7 @@ init_io_mask_or(struct nvbios_init *init
init_wrvgai(init, 0x03d4, index, data &= ~(1 << or));
  }
  
-/**

+/*
   * INIT_IO_OR - opcode 0x3c
   *
   */
@@ -878,7 +878,7 @@ init_io_or(struct nvbios_init *init)
init_wrvgai(init, 0x03d4, index, data | (1 << or));
  }
  
-/**

+/*
   * INIT_ANDN_REG - opcode 0x47
   *
   */
@@ -895,7 +895,7 @@ init_andn_reg(struct nvbios_init *init)
init_mask(init, reg, mask, 0);
  }
  
-/**

+/*
   * INIT_OR_REG - opcode 0x48
   *
   */
@@ -912,7 +912,7 @@ init_or_reg(struct nvbios_init *init)
init_mask(init, reg, 0, mask);
  }
  
-/**

+/*
   * INIT_INDEX_ADDRESS_LATCHED - opcode 0x49
   *
   */
@@ -942,7 +942,7 @@ init_idx_addr_latched(struct nvbios_init
}
  }
  
-/**

+/*
   * INIT_IO_RESTRICT_PLL2 - opcode 0x4a
   *
   */
@@ -977,7 +977,7 @@ init_io_restrict_pll2(struct nvbios_init
trace("}]\n");
  }
  
-/**

+/*
   * INIT_PLL2 - opcode 0x4b
   *
   */
@@ -994,7 +994,7 @@ init_pll2(struct nvbios_init *init)
init_prog_pll(init, reg, freq);
  }
  
-/**

+/*
   * INIT_I2C_BYTE - opcode 0x4c
   *
   */
@@ -1025,7 +1025,7 @@ init_i2c_byte(struct nvbios_init *init)
}
  }
  
-/**

+/*
   * INIT_ZM_I2C_BYTE - opcode 0x4d
   *
   */
@@ -1051,7 +1051,7 @@ init_zm_i2c_byte(struct nvbios_init *ini
}
  }
  
-/**

+/*
   * INIT_ZM_I2C - opcode 0x4e
   *
   */
@@ -1085,7 +1085,7 @@ init_zm_i2c(struct nvbios_init *init)
}
  }
  
-/**

+/*
   * INIT_TMDS - opcode 0x4f
   *
   */
@@ -,7 +,7 @@ init_tmds(struct nvbios_init *init)
init_wr32(init, reg + 0, addr);
  }
  
-/**

+/*
   * INIT_ZM_TMDS_GROUP - opcode 0x50
   *
   */
@@ -1138,7 +1138,7 @@ init_zm_tmds_group(struct nvbios_init *i
}
  }
  
-/**

+/*
   * INIT_CR_INDEX_ADDRESS_LATCHED - opcode 0x51
   *
   */
@@ -1168,7 +1168,7 @@ init_cr_idx_adr_latch(struct nvbios_init
init_wrvgai(init, 0x03d4, addr0, save0);
  }
 

Re: [PATCH 1/2] drm: update drm_show_memory_stats() for dma-bufs

[Rob Clark]

On Thu, Dec 7, 2023 at 10:02 AM Alex Deucher  wrote:
>
> Show buffers as shared if they are shared via dma-buf as well
> (e.g., shared with v4l or some other subsystem).
>
> Signed-off-by: Alex Deucher 
> Cc: Rob Clark 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/drm_file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 5ddaffd32586..5d5f93b9c263 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -973,7 +973,7 @@ void drm_show_memory_stats(struct drm_printer *p, struct 
> drm_file *file)
> DRM_GEM_OBJECT_PURGEABLE;
> }
>
> -   if (obj->handle_count > 1) {
> +   if ((obj->handle_count > 1) || obj->dma_buf) {
> status.shared += obj->size;
> } else {
> status.private += obj->size;
> --
> 2.42.0
>

Re: [PATCH] drm/nouveau/fifo: remove duplicated including

[Danilo Krummrich]

Hi Wang,

there is another patch [1] to fix this, which already made it upstream.

- Danilo

[1] 
https://patchwork.freedesktop.org/patch/msgid/20231122004926.84933-1-yang@linux.alibaba.com

On 12/15/23 11:02, Wang Jinchao wrote:

rm second including of chid.h

Signed-off-by: Wang Jinchao 
---
  drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c
index 87a62d4ff4bd..7d4716dcd512 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c
@@ -24,7 +24,6 @@
  #include "chan.h"
  #include "chid.h"
  #include "cgrp.h"
-#include "chid.h"
  #include "runl.h"
  #include "priv.h"
  

Re: [PATCH linux-next] drm/nouveau/disp: switch to use kmemdup() helper

[Danilo Krummrich]

Hi Yang,

On 12/14/23 13:03, yang.gua...@zte.com.cn wrote:

From: Yang Guang 

Use kmemdup() helper instead of open-coding to
simplify the code.

Signed-off-by: Chen Haonan 


Please add your "Signed-off-by" tag to this patch. If the above is intended to 
indicate
that Chan was involved in creating this patch (e.g. as co-author, reporter, 
etc.) please
use the corresponding tag instead. See also [1].

Once this is fixed, I'll apply the patch.

- Danilo

[1] 
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin


---
  drivers/gpu/drm/nouveau/nvif/outp.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvif/outp.c 
b/drivers/gpu/drm/nouveau/nvif/outp.c
index 5d3190c05250..6daeb7f0b09b 100644
--- a/drivers/gpu/drm/nouveau/nvif/outp.c
+++ b/drivers/gpu/drm/nouveau/nvif/outp.c
@@ -452,13 +452,12 @@ nvif_outp_edid_get(struct nvif_outp *outp, u8 **pedid)
if (ret)
goto done;

-   *pedid = kmalloc(args->size, GFP_KERNEL);
+   *pedid = kmemdup(args->data, args->size, GFP_KERNEL);
if (!*pedid) {
ret = -ENOMEM;
goto done;
}

-   memcpy(*pedid, args->data, args->size);
ret = args->size;
  done:
kfree(args);

Re: (subset) linux-next: build failure after merge of the pwm tree

[Lee Jones]

On Fri, 05 Jan 2024, Stephen Rothwell wrote:

> Hi all,
> 
> On Thu, 4 Jan 2024 12:50:28 + Sean Young  wrote:
> >
> > On Thu, Jan 04, 2024 at 05:02:41PM +0700, Bagas Sanjaya wrote:
> > > [also add Jingoo (additional backlight maintainer) and Linus]
> > > 
> > > On Thu, Dec 21, 2023 at 07:34:57PM +0100, Thierry Reding wrote:  
> > > > On Thu, Dec 21, 2023 at 12:58:01PM +, Lee Jones wrote:  
> > > > > On Thu, 21 Dec 2023, Lee Jones wrote:
> > > > >   
> > > > > > On Thu, 21 Dec 2023 16:58:05 +1100, Stephen Rothwell wrote:  
> > > > > > > After merging the backlight tree, today's linux-next build (x86_64
> > > > > > > allmodconfig) failed like this:
> > > > > > > 
> > > > > > > drivers/video/backlight/mp3309c.c: In function 
> > > > > > > 'mp3309c_bl_update_status':
> > > > > > > drivers/video/backlight/mp3309c.c:134:23: error: implicit 
> > > > > > > declaration of function 'pwm_apply_state'; did you mean 
> > > > > > > 'pwm_apply_args'? [-Werror=implicit-function-declaration]
> > > > > > >   134 | ret = pwm_apply_state(chip->pwmd, 
> > > > > > > );
> > > > > > >   |   ^~~
> > > > > > >   |   pwm_apply_args
> > > > > > > 
> > > > > > > [...]  
> > > > > > 
> > > > > > Applied, thanks!
> > > > > > 
> > > > > > [1/1] linux-next: build failure after merge of the pwm tree
> > > > > >   commit: f7baa9ccef93ba1c36a8ecf58c2f4e86fb3181b9  
> > > > > 
> > > > > Actually it's:
> > > > > 
> > > > >   f7baa9ccef93b ("backlight: mp3309c: Rename  pwm_apply_state() to 
> > > > > pwm_apply_might_sleep()")
> > > > > 
> > > > > But don't bank on the commit ID staying the same.  
> > > > 
> > > > This is likely going to break the build on your branch because
> > > > pwm_apply_might_sleep() is only available in the PWM tree right now. In
> > > > any case, I've now pushed a commit that adds pwm_apply_state() back as a
> > > > compatibility stub, so it should be okay for you to drop this if you
> > > > run into problems. It's always possible that somebody else wants to add
> > > > a new caller of pwm_apply_state() and in retrospect we should've
> > > > probably done this from the start, at least as a transitional measure
> > > > for one or two cycles.
> > > >   
> > > 
> > > Hi Lee and Thierry,
> > > 
> > > I know that we're still on New Year vibes, so some things are not up to 
> > > full
> > > steam for now; but since we're close to v6.7 release and v6.8 merge 
> > > window,
> > > hence allow me to ask:
> > > 
> > > Stephen Rothwell is still complaining about backlight tree build failure
> > > due to f7baa9ccef93b, yet it has not been fixed so far. Has the culprit
> > > been dropped/reverted as he requested? The worst case is the culprit slips
> > > through and become part of backlight PR and Linus will likely not happy
> > > with the build regression (maybe he had to fix by himself).  
> > 
> > This should be fixed by 9a216587a03df, and on current linux-next I can't 
> > reproduce the problem any more (x86_64 allmodconfig).
> 
> Of course linux-next is fine, because I have fixed it up in there.
> 
> Here is the problem:  the backlight tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git#for-backlight-next)
> is broken when built in its own because of the above patch (which is
> commit f7baa9ccef93).  In linux-next, I have been merging the previous
> working version of the backlight tree (with head commit 7d84a63a39b7).
> The patch (commit f7baa9ccef93) can only be applied to the merge of the
> backlight tree and the pwm tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next)
> which is merged much later in the linux-next process.  If the backlight
> tree was merged by Linus before the pwm tree, it would break his build
> (and he would not be happy).  But the patch on the head of the
> backlight tree was made unnecessary by commit 9a216587a03d in the pwm
> tree.  So, please either revert commit f7baa9ccef93 in the backlight
> tree (or simply to a "git reset --hard HEAD^" there).  The patch of
> commit f7baa9ccef93 can be applied some time later (after Linus has
> merged both trees.

Works for me.

It is done!

-- 
Lee Jones [李琼斯]

Re: [PATCH 1/1] drm: bridge: dw_hdmi: Set DRM bridge type

[Neil Armstrong]

On 08/01/2024 16:25, Alexander Stein wrote:

The bridge type was set to default (Unknown). Set proper bridge type.
With this fixed, debugfs output imx8mp looks proper.
$ cat /sys/kernel/debug/dri/1/encoder-0/bridges
bridge[0]: imx_hdmi_pvi_bridge_funcs [imx8mp_hdmi_pvi]
 type: [0] Unknown
 OF: /soc@0/bus@32c0/display-bridge@32fc4000:fsl,imx8mp-hdmi-pvi
 ops: [0x0]
bridge[1]: dw_hdmi_bridge_funcs [dw_hdmi]
 type: [11] HDMI-A
 OF: /soc@0/bus@32c0/hdmi@32fd8000:fsl,imx8mp-hdmi
 ops: [0x7] detect edid hpd

Signed-off-by: Alexander Stein 
---
For the record, the output before is:
$ cat /sys/kernel/debug/dri/1/encoder-0/bridges
bridge[0]: imx_hdmi_pvi_bridge_funcs [imx8mp_hdmi_pvi]
 type: [0] Unknown
 OF: /soc@0/bus@32c0/display-bridge@32fc4000:fsl,imx8mp-hdmi-pvi
 ops: [0x0]
bridge[1]: dw_hdmi_bridge_funcs [dw_hdmi]
 type: [0] Unknown
 OF: /soc@0/bus@32c0/hdmi@32fd8000:fsl,imx8mp-hdmi
 ops: [0x7] detect edid hpd

  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index aca5bb0866f88..455bc15d90cc1 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3541,6 +3541,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device 
*pdev,
hdmi->bridge.interlace_allowed = true;
hdmi->bridge.ddc = hdmi->ddc;
hdmi->bridge.of_node = pdev->dev.of_node;
+   hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
  
  	memset(, 0, sizeof(pdevinfo));

pdevinfo.parent = dev;


Reviewed-by: Neil Armstrong 

Re: [PATCH][next] drm/xe: Fix spelling mistake "gueue" -> "queue"

[Lucas De Marchi]

On Tue, 02 Jan 2024 09:20:14 +, Colin Ian King wrote:
> There is a spelling mistake in a drm_info message. Fix it.
> 
> 

Applied to drm-xe-next branch, thanks!

[1/1] drm/xe: Fix spelling mistake "gueue" -> "queue"
  commit: a3e6b7b90ce1ff725d7585cbd2c9279e6e39b914

Best regards,
-- 
Lucas De Marchi 

Re: [PATCH libdrm 1/2] amdgpu: fix parameter of amdgpu_cs_ctx_create2

[Christian König]

Am 08.01.24 um 10:40 schrieb Zhenneng Li:

In order to pass the correct priority parameter to the kernel,
we must change priority type from uint32_t to int32_t.


Hui what? Why should it matter if the parameter is signed or not?

That doesn't seem to make sense.

Regards,
Christian.



Signed-off-by: Zhenneng Li 
---
  amdgpu/amdgpu.h| 2 +-
  amdgpu/amdgpu_cs.c | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 9bdbf366..f46753f3 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -896,7 +896,7 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle handle,
   *
  */
  int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
-uint32_t priority,
+int32_t priority,
 amdgpu_context_handle *context);
  /**
   * Create GPU execution Context
diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 49fc16c3..eb72c638 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -49,7 +49,7 @@ static int amdgpu_cs_reset_sem(amdgpu_semaphore_handle sem);
   * \return  0 on success otherwise POSIX Error code
  */
  drm_public int amdgpu_cs_ctx_create2(amdgpu_device_handle dev,
-uint32_t priority,
+int32_t priority,
 amdgpu_context_handle *context)
  {
struct amdgpu_context *gpu_context;

Re: [PATCH v3 3/4] usb: gadget: functionfs: Add DMABUF import interface

[Paul Cercueil]

Le lundi 08 janvier 2024 à 16:29 +0100, Daniel Vetter a écrit :
> On Mon, Jan 08, 2024 at 03:21:21PM +0100, Paul Cercueil wrote:
> > Hi Daniel (Sima?),
> > 
> > Le lundi 08 janvier 2024 à 13:39 +0100, Daniel Vetter a écrit :
> > > On Mon, Jan 08, 2024 at 01:00:55PM +0100, Paul Cercueil wrote:
> > > > This patch introduces three new ioctls. They all should be
> > > > called
> > > > on a
> > > > data endpoint (ie. not ep0). They are:
> > > > 
> > > > - FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of
> > > > a
> > > > DMABUF
> > > >   object to attach to the endpoint.
> > > > 
> > > > - FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of
> > > > the
> > > >   DMABUF to detach from the endpoint. Note that closing the
> > > > endpoint's
> > > >   file descriptor will automatically detach all attached
> > > > DMABUFs.
> > > > 
> > > > - FUNCTIONFS_DMABUF_TRANSFER, which requests a data transfer
> > > > from /
> > > > to
> > > >   the given DMABUF. Its argument is a structure that packs the
> > > > DMABUF's
> > > >   file descriptor, the size in bytes to transfer (which should
> > > > generally
> > > >   be set to the size of the DMABUF), and a 'flags' field which
> > > > is
> > > > unused
> > > >   for now.
> > > >   Before this ioctl can be used, the related DMABUF must be
> > > > attached
> > > >   with FUNCTIONFS_DMABUF_ATTACH.
> > > > 
> > > > These three ioctls enable the FunctionFS code to transfer data
> > > > between
> > > > the USB stack and a DMABUF object, which can be provided by a
> > > > driver
> > > > from a completely different subsystem, in a zero-copy fashion.
> > > > 
> > > > Signed-off-by: Paul Cercueil 
> > > > 
> > > > ---
> > > > v2:
> > > > - Make ffs_dma_resv_lock() static
> > > > - Add MODULE_IMPORT_NS(DMA_BUF);
> > > > - The attach/detach functions are now performed without locking
> > > > the
> > > >   eps_lock spinlock. The transfer function starts with the
> > > > spinlock
> > > >   unlocked, then locks it before allocating and queueing the
> > > > USB
> > > >   transfer.
> > > > 
> > > > v3:
> > > > - Inline to_ffs_dma_fence() which was called only once.
> > > > - Simplify ffs_dma_resv_lock()
> > > > - Add comment explaining why we unref twice in
> > > > ffs_dmabuf_detach()
> > > > - Document uapi struct usb_ffs_dmabuf_transfer_req and IOCTLs
> > > > ---
> > > >  drivers/usb/gadget/function/f_fs.c  | 417
> > > > 
> > > >  include/uapi/linux/usb/functionfs.h |  41 +++
> > > >  2 files changed, 458 insertions(+)
> > > > 
> > > > diff --git a/drivers/usb/gadget/function/f_fs.c
> > > > b/drivers/usb/gadget/function/f_fs.c
> > > > index ed2a6d5fcef7..9df1f5abb0d4 100644
> > > > --- a/drivers/usb/gadget/function/f_fs.c
> > > > +++ b/drivers/usb/gadget/function/f_fs.c
> > > > @@ -15,6 +15,9 @@
> > > >  /* #define VERBOSE_DEBUG */
> > > >  
> > > >  #include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -43,6 +46,8 @@
> > > >  
> > > >  #define FUNCTIONFS_MAGIC   0xa647361 /* Chosen by a
> > > > honest
> > > > dice roll ;) */
> > > >  
> > > > +MODULE_IMPORT_NS(DMA_BUF);
> > > > +
> > > >  /* Reference counter handling */
> > > >  static void ffs_data_get(struct ffs_data *ffs);
> > > >  static void ffs_data_put(struct ffs_data *ffs);
> > > > @@ -124,6 +129,21 @@ struct ffs_ep {
> > > >     u8  num;
> > > >  };
> > > >  
> > > > +struct ffs_dmabuf_priv {
> > > > +   struct list_head entry;
> > > > +   struct kref ref;
> > > > +   struct dma_buf_attachment *attach;
> > > > +   spinlock_t lock;
> > > > +   u64 context;
> > > > +};
> > > > +
> > > > +struct ffs_dma_fence {
> > > > +   struct dma_fence base;
> > > > +   struct ffs_dmabuf_priv *priv;
> > > > +   struct sg_table *sgt;
> > > > +   enum dma_data_direction dir;
> > > > +};
> > > > +
> > > >  struct ffs_epfile {
> > > >     /* Protects ep->ep and ep->req. */
> > > >     struct mutexmutex;
> > > > @@ -197,6 +217,8 @@ struct ffs_epfile {
> > > >     unsigned char   isoc;   /* P: ffs-
> > > > > eps_lock */
> > > >  
> > > >     unsigned char   _pad;
> > > > +
> > > > +   struct list_headdmabufs;
> > > >  };
> > > >  
> > > >  struct ffs_buffer {
> > > > @@ -1271,10 +1293,44 @@ static ssize_t
> > > > ffs_epfile_read_iter(struct
> > > > kiocb *kiocb, struct iov_iter *to)
> > > >     return res;
> > > >  }
> > > >  
> > > > +static void ffs_dmabuf_release(struct kref *ref)
> > > > +{
> > > > +   struct ffs_dmabuf_priv *priv = container_of(ref,
> > > > struct
> > > > ffs_dmabuf_priv, ref);
> > > > +   struct dma_buf_attachment *attach = priv->attach;
> > > > +   struct dma_buf *dmabuf = attach->dmabuf;
> > > > +
> > > > +   pr_debug("FFS DMABUF release\n");
> > > > +   dma_buf_detach(attach->dmabuf, attach);
> > > > +   

Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices

[Jason Gunthorpe]

On Mon, Jan 08, 2024 at 04:25:02PM +0100, Daniel Vetter wrote:
> On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > > On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > > > > This series allow user space to notify KVM of noncoherent DMA status 
> > > > > so as
> > > > > to let KVM honor guest memory types in specified memory slot ranges.
> > > > > 
> > > > > Motivation
> > > > > ===
> > > > > A virtio GPU device may want to configure GPU hardware to work in
> > > > > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
> > > > 
> > > > Does this mean some DMA reads do not snoop the caches or does it
> > > > include DMA writes not synchronizing the caches too?
> > > Both DMA reads and writes are not snooped.
> > 
> > Oh that sounds really dangerous.
> 
> So if this is an issue then we might already have a problem, because with
> many devices it's entirely up to the device programming whether the i/o is
> snooping or not. So the moment you pass such a device to a guest, whether
> there's explicit support for non-coherent or not, you have a
> problem.

No, the iommus (except Intel and only for Intel integrated GPU, IIRC)
prohibit the use of non-coherent DMA entirely from a VM.

Eg AMD systems 100% block non-coherent DMA in VMs at the iommu level.

> _If_ there is a fundamental problem. I'm not sure of that, because my
> assumption was that at most the guest shoots itself and the data
> corruption doesn't go any further the moment the hypervisor does the
> dma/iommu unmapping.

Who fixes the cache on the unmapping? I didn't see anything..

Jason

Re: [PATCH v3 3/4] usb: gadget: functionfs: Add DMABUF import interface

[Daniel Vetter]

On Mon, Jan 08, 2024 at 03:21:21PM +0100, Paul Cercueil wrote:
> Hi Daniel (Sima?),
> 
> Le lundi 08 janvier 2024 à 13:39 +0100, Daniel Vetter a écrit :
> > On Mon, Jan 08, 2024 at 01:00:55PM +0100, Paul Cercueil wrote:
> > > This patch introduces three new ioctls. They all should be called
> > > on a
> > > data endpoint (ie. not ep0). They are:
> > > 
> > > - FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a
> > > DMABUF
> > >   object to attach to the endpoint.
> > > 
> > > - FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of the
> > >   DMABUF to detach from the endpoint. Note that closing the
> > > endpoint's
> > >   file descriptor will automatically detach all attached DMABUFs.
> > > 
> > > - FUNCTIONFS_DMABUF_TRANSFER, which requests a data transfer from /
> > > to
> > >   the given DMABUF. Its argument is a structure that packs the
> > > DMABUF's
> > >   file descriptor, the size in bytes to transfer (which should
> > > generally
> > >   be set to the size of the DMABUF), and a 'flags' field which is
> > > unused
> > >   for now.
> > >   Before this ioctl can be used, the related DMABUF must be
> > > attached
> > >   with FUNCTIONFS_DMABUF_ATTACH.
> > > 
> > > These three ioctls enable the FunctionFS code to transfer data
> > > between
> > > the USB stack and a DMABUF object, which can be provided by a
> > > driver
> > > from a completely different subsystem, in a zero-copy fashion.
> > > 
> > > Signed-off-by: Paul Cercueil 
> > > 
> > > ---
> > > v2:
> > > - Make ffs_dma_resv_lock() static
> > > - Add MODULE_IMPORT_NS(DMA_BUF);
> > > - The attach/detach functions are now performed without locking the
> > >   eps_lock spinlock. The transfer function starts with the spinlock
> > >   unlocked, then locks it before allocating and queueing the USB
> > >   transfer.
> > > 
> > > v3:
> > > - Inline to_ffs_dma_fence() which was called only once.
> > > - Simplify ffs_dma_resv_lock()
> > > - Add comment explaining why we unref twice in ffs_dmabuf_detach()
> > > - Document uapi struct usb_ffs_dmabuf_transfer_req and IOCTLs
> > > ---
> > >  drivers/usb/gadget/function/f_fs.c  | 417
> > > 
> > >  include/uapi/linux/usb/functionfs.h |  41 +++
> > >  2 files changed, 458 insertions(+)
> > > 
> > > diff --git a/drivers/usb/gadget/function/f_fs.c
> > > b/drivers/usb/gadget/function/f_fs.c
> > > index ed2a6d5fcef7..9df1f5abb0d4 100644
> > > --- a/drivers/usb/gadget/function/f_fs.c
> > > +++ b/drivers/usb/gadget/function/f_fs.c
> > > @@ -15,6 +15,9 @@
> > >  /* #define VERBOSE_DEBUG */
> > >  
> > >  #include 
> > > +#include 
> > > +#include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -43,6 +46,8 @@
> > >  
> > >  #define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest
> > > dice roll ;) */
> > >  
> > > +MODULE_IMPORT_NS(DMA_BUF);
> > > +
> > >  /* Reference counter handling */
> > >  static void ffs_data_get(struct ffs_data *ffs);
> > >  static void ffs_data_put(struct ffs_data *ffs);
> > > @@ -124,6 +129,21 @@ struct ffs_ep {
> > >   u8  num;
> > >  };
> > >  
> > > +struct ffs_dmabuf_priv {
> > > + struct list_head entry;
> > > + struct kref ref;
> > > + struct dma_buf_attachment *attach;
> > > + spinlock_t lock;
> > > + u64 context;
> > > +};
> > > +
> > > +struct ffs_dma_fence {
> > > + struct dma_fence base;
> > > + struct ffs_dmabuf_priv *priv;
> > > + struct sg_table *sgt;
> > > + enum dma_data_direction dir;
> > > +};
> > > +
> > >  struct ffs_epfile {
> > >   /* Protects ep->ep and ep->req. */
> > >   struct mutexmutex;
> > > @@ -197,6 +217,8 @@ struct ffs_epfile {
> > >   unsigned char   isoc;   /* P: ffs-
> > > >eps_lock */
> > >  
> > >   unsigned char   _pad;
> > > +
> > > + struct list_headdmabufs;
> > >  };
> > >  
> > >  struct ffs_buffer {
> > > @@ -1271,10 +1293,44 @@ static ssize_t ffs_epfile_read_iter(struct
> > > kiocb *kiocb, struct iov_iter *to)
> > >   return res;
> > >  }
> > >  
> > > +static void ffs_dmabuf_release(struct kref *ref)
> > > +{
> > > + struct ffs_dmabuf_priv *priv = container_of(ref, struct
> > > ffs_dmabuf_priv, ref);
> > > + struct dma_buf_attachment *attach = priv->attach;
> > > + struct dma_buf *dmabuf = attach->dmabuf;
> > > +
> > > + pr_debug("FFS DMABUF release\n");
> > > + dma_buf_detach(attach->dmabuf, attach);
> > > + dma_buf_put(dmabuf);
> > > +
> > > + list_del(>entry);
> > 
> > I didn't find any locking for this list here.
> 
> Yeah. I'll add some.
> 
> > > + kfree(priv);
> > > +}
> > > +
> > > +static void ffs_dmabuf_get(struct dma_buf_attachment *attach)
> > > +{
> > > + struct ffs_dmabuf_priv *priv = attach->importer_priv;
> > > +
> > > + kref_get(>ref);
> > > +}
> > > +
> > > +static void ffs_dmabuf_put(struct dma_buf_attachment *attach)
> > > +{
> > > + struct ffs_dmabuf_priv *priv = attach->importer_priv;
> > > +
> > > + kref_put(>ref, ffs_dmabuf_release);
> > > +}
> > > +
> 

[PATCH 1/1] drm: bridge: dw_hdmi: Set DRM bridge type

[Alexander Stein]

The bridge type was set to default (Unknown). Set proper bridge type.
With this fixed, debugfs output imx8mp looks proper.
$ cat /sys/kernel/debug/dri/1/encoder-0/bridges
bridge[0]: imx_hdmi_pvi_bridge_funcs [imx8mp_hdmi_pvi]
type: [0] Unknown
OF: /soc@0/bus@32c0/display-bridge@32fc4000:fsl,imx8mp-hdmi-pvi
ops: [0x0]
bridge[1]: dw_hdmi_bridge_funcs [dw_hdmi]
type: [11] HDMI-A
OF: /soc@0/bus@32c0/hdmi@32fd8000:fsl,imx8mp-hdmi
ops: [0x7] detect edid hpd

Signed-off-by: Alexander Stein 
---
For the record, the output before is:
$ cat /sys/kernel/debug/dri/1/encoder-0/bridges 
bridge[0]: imx_hdmi_pvi_bridge_funcs [imx8mp_hdmi_pvi]
type: [0] Unknown
OF: /soc@0/bus@32c0/display-bridge@32fc4000:fsl,imx8mp-hdmi-pvi
ops: [0x0]
bridge[1]: dw_hdmi_bridge_funcs [dw_hdmi]
type: [0] Unknown
OF: /soc@0/bus@32c0/hdmi@32fd8000:fsl,imx8mp-hdmi
ops: [0x7] detect edid hpd

 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index aca5bb0866f88..455bc15d90cc1 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -3541,6 +3541,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device 
*pdev,
hdmi->bridge.interlace_allowed = true;
hdmi->bridge.ddc = hdmi->ddc;
hdmi->bridge.of_node = pdev->dev.of_node;
+   hdmi->bridge.type = DRM_MODE_CONNECTOR_HDMIA;
 
memset(, 0, sizeof(pdevinfo));
pdevinfo.parent = dev;
-- 
2.34.1

Re: [PATCH 0/4] KVM: Honor guest memory types for virtio GPU devices

[Daniel Vetter]

On Mon, Jan 08, 2024 at 10:02:50AM -0400, Jason Gunthorpe wrote:
> On Mon, Jan 08, 2024 at 02:02:57PM +0800, Yan Zhao wrote:
> > On Fri, Jan 05, 2024 at 03:55:51PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Jan 05, 2024 at 05:12:37PM +0800, Yan Zhao wrote:
> > > > This series allow user space to notify KVM of noncoherent DMA status so 
> > > > as
> > > > to let KVM honor guest memory types in specified memory slot ranges.
> > > > 
> > > > Motivation
> > > > ===
> > > > A virtio GPU device may want to configure GPU hardware to work in
> > > > noncoherent mode, i.e. some of its DMAs do not snoop CPU caches.
> > > 
> > > Does this mean some DMA reads do not snoop the caches or does it
> > > include DMA writes not synchronizing the caches too?
> > Both DMA reads and writes are not snooped.
> 
> Oh that sounds really dangerous.

So if this is an issue then we might already have a problem, because with
many devices it's entirely up to the device programming whether the i/o is
snooping or not. So the moment you pass such a device to a guest, whether
there's explicit support for non-coherent or not, you have a problem.

_If_ there is a fundamental problem. I'm not sure of that, because my
assumption was that at most the guest shoots itself and the data
corruption doesn't go any further the moment the hypervisor does the
dma/iommu unmapping.

Also, there's a pile of x86 devices where this very much applies, x86
being dma-coherent is not really the true ground story.

Cheers, Sima

> > > > This is generally for performance consideration.
> > > > In certain platform, GFX performance can improve 20+% with DMAs going to
> > > > noncoherent path.
> > > > 
> > > > This noncoherent DMA mode works in below sequence:
> > > > 1. Host backend driver programs hardware not to snoop memory of target
> > > >DMA buffer.
> > > > 2. Host backend driver indicates guest frontend driver to program guest 
> > > > PAT
> > > >to WC for target DMA buffer.
> > > > 3. Guest frontend driver writes to the DMA buffer without clflush 
> > > > stuffs.
> > > > 4. Hardware does noncoherent DMA to the target buffer.
> > > > 
> > > > In this noncoherent DMA mode, both guest and hardware regard a DMA 
> > > > buffer
> > > > as not cached. So, if KVM forces the effective memory type of this DMA
> > > > buffer to be WB, hardware DMA may read incorrect data and cause misc
> > > > failures.
> > > 
> > > I don't know all the details, but a big concern would be that the
> > > caches remain fully coherent with the underlying memory at any point
> > > where kvm decides to revoke the page from the VM.
> > Ah, you mean, for page migration, the content of the page may not be copied
> > correctly, right?
> 
> Not just migration. Any point where KVM revokes the page from the
> VM. Ie just tearing down the VM still has to make the cache coherent
> with physical or there may be problems.
>  
> > Currently in x86, we have 2 ways to let KVM honor guest memory types:
> > 1. through KVM memslot flag introduced in this series, for virtio GPUs, in
> >memslot granularity.
> > 2. through increasing noncoherent dma count, as what's done in VFIO, for
> >Intel GPU passthrough, for all guest memory.
> 
> And where does all this fixup the coherency problem?
> 
> > This page migration issue should not be the case for virtio GPU, as both 
> > host
> > and guest are synced to use the same memory type and actually the pages
> > are not anonymous pages.
> 
> The guest isn't required to do this so it can force the cache to
> become incoherent.
> 
> > > If you allow an incoherence of cache != physical then it opens a
> > > security attack where the observed content of memory can change when
> > > it should not.
> > 
> > In this case, will this security attack impact other guests?
> 
> It impacts the hypervisor potentially. It depends..
> 
> Jason

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 1/3] drm/i915/gt: Support fixed CCS mode

[Joonas Lahtinen]

Quoting Tvrtko Ursulin (2024-01-05 12:39:31)
> 
> On 04/01/2024 21:23, Andi Shyti wrote:



> >>> +void intel_gt_apply_ccs_mode(struct intel_gt *gt)
> >>> +{
> >>> +   mutex_lock(>ccs.mutex);
> >>> +   __intel_gt_apply_ccs_mode(gt);
> >>> +   mutex_unlock(>ccs.mutex);
> >>> +}
> >>> +
> >>> +void intel_gt_init_ccs_mode(struct intel_gt *gt)
> >>> +{
> >>> +   mutex_init(>ccs.mutex);
> >>> +   gt->ccs.mode = 1;
> >>
> >> What is '1'? And this question carries over to the sysfs interface in the
> >> following patch - who will use it and where it is documented how to use it?
> > 
> > The value '1' is explained in the comment above[1] and in the
> 
> Do you mean this is mode '1':
> 
>   * With 1 engine (ccs0):
>   *   slice 0, 1, 2, 3: ccs0
> 
> ?
> 
> But I don't see where it says what do different modes mean on different 
> SKU configurations.
> 
> It also does not say what should the num_slices sysfs file be used for.
> 
> Does "mode N" mean "assign each command streamer N compute slices"? Or 
> "assign each compute slice N command streamers"?
> 
> I wonder if we should add something user friendly into 
> Documentation/ABI/*/sysfs-... Joonas your thoughts?

We definitely should always properly document all sysfs additions, just
seems like we less frequently remember to do so. So yeah, this should be
documented just like other uAPI.

I also like the idea of not exposing the the file at all if the value
can't be modified.

The ccs_mode is just supposed to allow user to select how many CCS
engines they want to expose, and always make an even split of slices
between them, nothing more nothing less.

Regards, Joonas

Re: [PATCH V7 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

[Alexander Stein]

Hi Adam,

thanks for pushing this forward.

Am Samstag, 6. Januar 2024, 22:51:45 CET schrieb Adam Ford:
> From: Lucas Stach 
> 
> This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a
> full timing generator and can switch between different video sources. On
> the i.MX8MP however the only supported source is the LCDIF. The block
> just needs to be powered up and told about the polarity of the video
> sync signals to act in bypass mode.
> 
> Signed-off-by: Lucas Stach 
> Reviewed-by: Luca Ceresoli  (v2)
> Tested-by: Marek Vasut  (v1)
> Tested-by: Luca Ceresoli  (v2)
> Tested-by: Richard Leitner  (v2)
> Tested-by: Frieder Schrempf  (v2)
> Reviewed-by: Laurent Pinchart  (v3)
> Reviewed-by: Luca Ceresoli 
> Tested-by: Luca Ceresoli 
> Tested-by: Fabio Estevam 
> Signed-off-by: Adam Ford 

Tested on TQMa8MPQL/MBa8MPxL + Full-HD HDMI monitor.

Tested-by: Alexander Stein 

> 
> ---
> V7:  Re-do some includes to address build issues after rebasing from
>  Linux-next
> 
> V6:  No change.
> 
> V5:  I (Adam) tried to help move this along, so I took Lucas' patch and
>  attempted to apply fixes based on feedback.  I don't have
>  all the history, so apologies for that.
>  No changes from V4 to V5
> 
> diff --git a/drivers/gpu/drm/bridge/imx/Kconfig
> b/drivers/gpu/drm/bridge/imx/Kconfig index 5a4f3d58501e..a4d13331e320
> 100644
> --- a/drivers/gpu/drm/bridge/imx/Kconfig
> +++ b/drivers/gpu/drm/bridge/imx/Kconfig
> @@ -3,6 +3,13 @@ if ARCH_MXC || COMPILE_TEST
>  config DRM_IMX_LDB_HELPER
>   tristate
> 
> +config DRM_IMX8MP_HDMI_PVI
> + tristate "Freescale i.MX8MP HDMI PVI bridge support"
> + depends on OF
> + help
> +   Choose this to enable support for the internal HDMI TX Parallel
> +   Video Interface found on the Freescale i.MX8MP SoC.
> +
>  config DRM_IMX8QM_LDB
>   tristate "Freescale i.MX8QM LVDS display bridge"
>   depends on OF
> diff --git a/drivers/gpu/drm/bridge/imx/Makefile
> b/drivers/gpu/drm/bridge/imx/Makefile index 2b0c2e44aa1b..e2c2106509fa
> 100644
> --- a/drivers/gpu/drm/bridge/imx/Makefile
> +++ b/drivers/gpu/drm/bridge/imx/Makefile
> @@ -1,4 +1,5 @@
>  obj-$(CONFIG_DRM_IMX_LDB_HELPER) += imx-ldb-helper.o
> +obj-$(CONFIG_DRM_IMX8MP_HDMI_PVI) += imx8mp-hdmi-pvi.o
>  obj-$(CONFIG_DRM_IMX8QM_LDB) += imx8qm-ldb.o
>  obj-$(CONFIG_DRM_IMX8QXP_LDB) += imx8qxp-ldb.o
>  obj-$(CONFIG_DRM_IMX8QXP_PIXEL_COMBINER) += imx8qxp-pixel-combiner.o
> diff --git a/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c new file mode 100644
> index ..a76b7669fe8a
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/imx/imx8mp-hdmi-pvi.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/*
> + * Copyright (C) 2022 Pengutronix, Lucas Stach 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define HTX_PVI_CTRL 0x0
> +#define  PVI_CTRL_OP_VSYNC_POL   BIT(18)
> +#define  PVI_CTRL_OP_HSYNC_POL   BIT(17)
> +#define  PVI_CTRL_OP_DE_POL  BIT(16)
> +#define  PVI_CTRL_INP_VSYNC_POL  BIT(14)
> +#define  PVI_CTRL_INP_HSYNC_POL  BIT(13)
> +#define  PVI_CTRL_INP_DE_POL BIT(12)
> +#define  PVI_CTRL_MODE_MASK  GENMASK(2, 1)
> +#define  PVI_CTRL_MODE_LCDIF 2
> +#define  PVI_CTRL_EN BIT(0)
> +
> +struct imx8mp_hdmi_pvi {
> + struct drm_bridge   bridge;
> + struct device   *dev;
> + struct drm_bridge   *next_bridge;
> + void __iomem*regs;
> +};
> +
> +static inline struct imx8mp_hdmi_pvi *
> +to_imx8mp_hdmi_pvi(struct drm_bridge *bridge)
> +{
> + return container_of(bridge, struct imx8mp_hdmi_pvi, bridge);
> +}
> +
> +static int imx8mp_hdmi_pvi_bridge_attach(struct drm_bridge *bridge,
> +  enum 
drm_bridge_attach_flags flags)
> +{
> + struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> +
> + return drm_bridge_attach(bridge->encoder, pvi->next_bridge,
> +  bridge, flags);
> +}
> +
> +static void imx8mp_hdmi_pvi_bridge_enable(struct drm_bridge *bridge,
> +   struct drm_bridge_state 
*bridge_state)
> +{
> + struct drm_atomic_state *state = bridge_state->base.state;
> + struct imx8mp_hdmi_pvi *pvi = to_imx8mp_hdmi_pvi(bridge);
> + struct drm_connector_state *conn_state;
> + const struct drm_display_mode *mode;
> + struct drm_crtc_state *crtc_state;
> + struct drm_connector *connector;
> + u32 bus_flags, val;
> +
> + connector = drm_atomic_get_new_connector_for_encoder(state,
> bridge->encoder); +   conn_state = 
drm_atomic_get_new_connector_state(state,
> connector); + crtc_state = drm_atomic_get_new_crtc_state(state,
> conn_state->crtc); +
> + if (WARN_ON(pm_runtime_resume_and_get(pvi->dev)))
> + 

Re: [PATCH V2 2/2] phy: freescale: add Samsung HDMI PHY

[Alexander Stein]

Hi Adam,

thanks for pushing this forward.

Am Samstag, 6. Januar 2024, 23:19:05 CET schrieb Adam Ford:
> From: Lucas Stach 
> 
> This adds the driver for the Samsung HDMI PHY found on the
> i.MX8MP SoC.
> 
> Signed-off-by: Lucas Stach 
> Signed-off-by: Adam Ford 
> ---
> V2:  Fixed some whitespace found from checkpatch
>  Change error handling when enabling apbclk to use dev_err_probe
>  Rebase on Linux-Next
> 
>  I (Adam) tried to help move this along, so I took Lucas' patch and
>  attempted to apply fixes based on feedback.  I don't have
>  all the history, so apologies for that.
> 
> diff --git a/drivers/phy/freescale/Kconfig b/drivers/phy/freescale/Kconfig
> index 853958fb2c06..5c2b73042dfc 100644
> --- a/drivers/phy/freescale/Kconfig
> +++ b/drivers/phy/freescale/Kconfig
> @@ -35,6 +35,12 @@ config PHY_FSL_IMX8M_PCIE
> Enable this to add support for the PCIE PHY as found on
> i.MX8M family of SOCs.
> 
> +config PHY_FSL_SAMSUNG_HDMI_PHY
> + tristate "Samsung HDMI PHY support"
> + depends on OF && HAS_IOMEM
> + help
> +   Enable this to add support for the Samsung HDMI PHY in i.MX8MP.
> +
>  endif
> 
>  config PHY_FSL_LYNX_28G
> diff --git a/drivers/phy/freescale/Makefile b/drivers/phy/freescale/Makefile
> index cedb328bc4d2..dbcafdcc8751 100644
> --- a/drivers/phy/freescale/Makefile
> +++ b/drivers/phy/freescale/Makefile
> @@ -3,4 +3,5 @@ obj-$(CONFIG_PHY_FSL_IMX8MQ_USB)  += phy-fsl-imx8mq-usb.o
>  obj-$(CONFIG_PHY_MIXEL_LVDS_PHY) += phy-fsl-imx8qm-lvds-phy.o
>  obj-$(CONFIG_PHY_MIXEL_MIPI_DPHY)+= phy-fsl-imx8-mipi-dphy.o
>  obj-$(CONFIG_PHY_FSL_IMX8M_PCIE) += phy-fsl-imx8m-pcie.o
> +obj-$(CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY)  += phy-fsl-samsung-hdmi.o
>  obj-$(CONFIG_PHY_FSL_LYNX_28G)   += phy-fsl-lynx-28g.o

I don't know if there was different feedback already. But I would have added 
the entry sorted alphabetically, thus after CONFIG_PHY_FSL_LYNX_28G. Same goes 
for Kconfig as well.

> diff --git a/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c new file mode 100644
> index ..54e93ea898f7
> --- /dev/null
> +++ b/drivers/phy/freescale/phy-fsl-samsung-hdmi.c
> @@ -0,0 +1,1078 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2020 NXP
> + * Copyright 2022 Pengutronix, Lucas Stach 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define HDMI_TX_CONTROL0 0x200
> +#define  HDMI_TX_CONTROL_PHY_PWRDWN  BIT(3)

These defines are unused here.

> +
> +#define PHY_REG_33   0x84
> +#define  REG33_MODE_SET_DONE BIT(7)
> +#define  REG33_FIX_DABIT(1)
> +
> +#define PHY_REG_34   0x88
> +#define  REG34_PHY_READY BIT(7)
> +#define  REG34_PLL_LOCK  BIT(6)
> +#define  REG34_PHY_CLK_READY BIT(5)
> +
> +
> +#define PHY_PLL_REGS_NUM 48
> +
> +struct phy_config {
> + u32 clk_rate;
> + u8 regs[PHY_PLL_REGS_NUM];

Shouldn't reg be aligned along clk_rate?

Despite that. Tested on TQMa8MPQL/MBa8MPxL + Full-HD HDMI monitor.

Tested-by: Alexander Stein 

Best regards,
Alexander

> +};
> +
> +const struct phy_config phy_pll_cfg[] = {
> + {   2225, {
> + 0x00, 0xD1, 0x4B, 0xF1, 0x89, 0x88, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x15, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + }, {
> + 2375, {
> + 0x00, 0xD1, 0x50, 0xF1, 0x86, 0x85, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x03, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + }, {
> + 2400, {
> + 0x00, 0xD1, 0x50, 0xF0, 0x00, 0x00, 0x80, 0x00,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x01, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 0x32,
> + 0x60, 0x8F, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x00, 0x80, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0xE0, 0x83, 0x0F, 0x3E, 0xF8, 0x00, 0x00,
> + },
> + }, {
> + 24024000, {
> + 0x00, 0xD1, 0x50, 0xF1, 0x99, 0x02, 0x80, 0x40,
> + 0x4F, 0x30, 0x33, 0x65, 0x00, 0x00, 0x25, 0x80,
> + 0x6C, 0xF2, 0x67, 0x00, 0x10, 0x8F, 0x30, 

Re: Automatically update drm CI dependencies?

[Helen Koike]

On 20/12/2023 08:11, Bagas Sanjaya wrote:

On 12/19/23 23:43, Helen Koike wrote:

Hi,

On 14/12/2023 06:38, Bagas Sanjaya wrote:

Hi all,

I'm referring to dependabot PR on torvalds.git GitHub mirror [1]. I know
that PRs submitted there are not accepted (the repo is essentially read-only
mirror), hence this mail question.

In summary, dependabot submitted automated PR that bumps package versions
in `drivers/gpu/drm/ci/xfails/requirements.txt`. In this case, pip was
upgraded to 23.3.

  From my experience, such automated PRs can pollute commit history (in
some GitHub projects these PR kind can contribute up to half of total
commits since the beginning of project). And in some projects, dependabot
PRs are automatically merged without any maintainer intervention.

Does such PRs (when submitted to LKML these will be patches) make sense
for DRM subsystem?

Thanks.

[1]: https://github.com/torvalds/linux/pull/807



imho I rather not having this automated patches, but I would like to hear the 
opinions from others.



But why? Did you mean that making the CI always depends on latest version
of dependencies create another maintenance variable (and may constantly
broke CI)?

Confused...


Sorry I didn't reply earlier.

I'm ok with that if it doesn't produce much noise, I also think that we 
need an automated test to see if the tool is still working as expected 
before merging the patch.

The pip there is just used for a helper tool, it is nothing critical.

Regards,
Helen

Re: [PATCH v3 3/4] usb: gadget: functionfs: Add DMABUF import interface

[Paul Cercueil]

Hi Daniel (Sima?),

Le lundi 08 janvier 2024 à 13:39 +0100, Daniel Vetter a écrit :
> On Mon, Jan 08, 2024 at 01:00:55PM +0100, Paul Cercueil wrote:
> > This patch introduces three new ioctls. They all should be called
> > on a
> > data endpoint (ie. not ep0). They are:
> > 
> > - FUNCTIONFS_DMABUF_ATTACH, which takes the file descriptor of a
> > DMABUF
> >   object to attach to the endpoint.
> > 
> > - FUNCTIONFS_DMABUF_DETACH, which takes the file descriptor of the
> >   DMABUF to detach from the endpoint. Note that closing the
> > endpoint's
> >   file descriptor will automatically detach all attached DMABUFs.
> > 
> > - FUNCTIONFS_DMABUF_TRANSFER, which requests a data transfer from /
> > to
> >   the given DMABUF. Its argument is a structure that packs the
> > DMABUF's
> >   file descriptor, the size in bytes to transfer (which should
> > generally
> >   be set to the size of the DMABUF), and a 'flags' field which is
> > unused
> >   for now.
> >   Before this ioctl can be used, the related DMABUF must be
> > attached
> >   with FUNCTIONFS_DMABUF_ATTACH.
> > 
> > These three ioctls enable the FunctionFS code to transfer data
> > between
> > the USB stack and a DMABUF object, which can be provided by a
> > driver
> > from a completely different subsystem, in a zero-copy fashion.
> > 
> > Signed-off-by: Paul Cercueil 
> > 
> > ---
> > v2:
> > - Make ffs_dma_resv_lock() static
> > - Add MODULE_IMPORT_NS(DMA_BUF);
> > - The attach/detach functions are now performed without locking the
> >   eps_lock spinlock. The transfer function starts with the spinlock
> >   unlocked, then locks it before allocating and queueing the USB
> >   transfer.
> > 
> > v3:
> > - Inline to_ffs_dma_fence() which was called only once.
> > - Simplify ffs_dma_resv_lock()
> > - Add comment explaining why we unref twice in ffs_dmabuf_detach()
> > - Document uapi struct usb_ffs_dmabuf_transfer_req and IOCTLs
> > ---
> >  drivers/usb/gadget/function/f_fs.c  | 417
> > 
> >  include/uapi/linux/usb/functionfs.h |  41 +++
> >  2 files changed, 458 insertions(+)
> > 
> > diff --git a/drivers/usb/gadget/function/f_fs.c
> > b/drivers/usb/gadget/function/f_fs.c
> > index ed2a6d5fcef7..9df1f5abb0d4 100644
> > --- a/drivers/usb/gadget/function/f_fs.c
> > +++ b/drivers/usb/gadget/function/f_fs.c
> > @@ -15,6 +15,9 @@
> >  /* #define VERBOSE_DEBUG */
> >  
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -43,6 +46,8 @@
> >  
> >  #define FUNCTIONFS_MAGIC   0xa647361 /* Chosen by a honest
> > dice roll ;) */
> >  
> > +MODULE_IMPORT_NS(DMA_BUF);
> > +
> >  /* Reference counter handling */
> >  static void ffs_data_get(struct ffs_data *ffs);
> >  static void ffs_data_put(struct ffs_data *ffs);
> > @@ -124,6 +129,21 @@ struct ffs_ep {
> >     u8  num;
> >  };
> >  
> > +struct ffs_dmabuf_priv {
> > +   struct list_head entry;
> > +   struct kref ref;
> > +   struct dma_buf_attachment *attach;
> > +   spinlock_t lock;
> > +   u64 context;
> > +};
> > +
> > +struct ffs_dma_fence {
> > +   struct dma_fence base;
> > +   struct ffs_dmabuf_priv *priv;
> > +   struct sg_table *sgt;
> > +   enum dma_data_direction dir;
> > +};
> > +
> >  struct ffs_epfile {
> >     /* Protects ep->ep and ep->req. */
> >     struct mutexmutex;
> > @@ -197,6 +217,8 @@ struct ffs_epfile {
> >     unsigned char   isoc;   /* P: ffs-
> > >eps_lock */
> >  
> >     unsigned char   _pad;
> > +
> > +   struct list_headdmabufs;
> >  };
> >  
> >  struct ffs_buffer {
> > @@ -1271,10 +1293,44 @@ static ssize_t ffs_epfile_read_iter(struct
> > kiocb *kiocb, struct iov_iter *to)
> >     return res;
> >  }
> >  
> > +static void ffs_dmabuf_release(struct kref *ref)
> > +{
> > +   struct ffs_dmabuf_priv *priv = container_of(ref, struct
> > ffs_dmabuf_priv, ref);
> > +   struct dma_buf_attachment *attach = priv->attach;
> > +   struct dma_buf *dmabuf = attach->dmabuf;
> > +
> > +   pr_debug("FFS DMABUF release\n");
> > +   dma_buf_detach(attach->dmabuf, attach);
> > +   dma_buf_put(dmabuf);
> > +
> > +   list_del(>entry);
> 
> I didn't find any locking for this list here.

Yeah. I'll add some.

> > +   kfree(priv);
> > +}
> > +
> > +static void ffs_dmabuf_get(struct dma_buf_attachment *attach)
> > +{
> > +   struct ffs_dmabuf_priv *priv = attach->importer_priv;
> > +
> > +   kref_get(>ref);
> > +}
> > +
> > +static void ffs_dmabuf_put(struct dma_buf_attachment *attach)
> > +{
> > +   struct ffs_dmabuf_priv *priv = attach->importer_priv;
> > +
> > +   kref_put(>ref, ffs_dmabuf_release);
> > +}
> > +
> >  static int
> >  ffs_epfile_release(struct inode *inode, struct file *file)
> >  {
> >     struct ffs_epfile *epfile = inode->i_private;
> > +   struct ffs_dmabuf_priv *priv, *tmp;
> > +
> > +   /* Close all attached DMABUFs */
> > +   list_for_each_entry_safe(priv, tmp, >dmabufs,
> > entry) {
> > +   

Re: [PATCH] vt: remove superfluous CONFIG_HW_CONSOLE

[Javier Martinez Canillas]

Lukas Bulwahn  writes:

Hello Lukas,

> The config HW_CONSOLE is always identical to the config VT and is not
> visible in the kernel's build menuconfig. So, CONFIG_HW_CONSOLE is
> redundant.
>
> Replace all references to CONFIG_HW_CONSOLE with CONFIG_VT and remove
> CONFIG_HW_CONSOLE.
>
> Signed-off-by: Lukas Bulwahn 
> ---

Makes sense to me.

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH] vt: remove superfluous CONFIG_HW_CONSOLE

[Geert Uytterhoeven]

On Mon, Jan 8, 2024 at 2:41 PM Lukas Bulwahn  wrote:
> The config HW_CONSOLE is always identical to the config VT and is not
> visible in the kernel's build menuconfig. So, CONFIG_HW_CONSOLE is
> redundant.
>
> Replace all references to CONFIG_HW_CONSOLE with CONFIG_VT and remove
> CONFIG_HW_CONSOLE.
>
> Signed-off-by: Lukas Bulwahn 

Reviewed-by: Geert Uytterhoeven 

>  arch/m68k/amiga/config.c| 2 +-

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] drm/xe: clean up type of GUC_HXG_MSG_0_ORIGIN

[Lucas De Marchi]

On Mon, Jan 08, 2024 at 12:05:57PM +0300, Dan Carpenter wrote:

The GUC_HXG_MSG_0_ORIGIN definition should be unsigned.  Currently it is
defined as INT_MIN.  This doesn't cause a problem currently but it's
still worth cleaning up.

Signed-off-by: Dan Carpenter 


it seems there are a few more places to change to follow what was done
in commit 962bd34bb457 ("drm/i915/uc: Fix undefined behavior due to shift 
overflowing the constant").

+Michal

Could we eventually share these abi includes with i915 so we don't
keep fixing the same thing in 2 places?

Lucas De Marchi


---
drivers/gpu/drm/xe/abi/guc_messages_abi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/abi/guc_messages_abi.h 
b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
index 3d199016cf88..c04606872e48 100644
--- a/drivers/gpu/drm/xe/abi/guc_messages_abi.h
+++ b/drivers/gpu/drm/xe/abi/guc_messages_abi.h
@@ -40,7 +40,7 @@
 */

#define GUC_HXG_MSG_MIN_LEN 1u
-#define GUC_HXG_MSG_0_ORIGIN   (0x1 << 31)
+#define GUC_HXG_MSG_0_ORIGIN   (0x1U << 31)
#define   GUC_HXG_ORIGIN_HOST   0u
#define   GUC_HXG_ORIGIN_GUC1u
#define GUC_HXG_MSG_0_TYPE  (0x7 << 28)
--
2.42.0