date:20220714

From: allen chen 

Use i2c bus to read/write when it6505 power off will occur i2c error.
Add this check will prevent i2c error when it6505 power off.

Signed-off-by: Pin-Yen Lin 
Signed-off-by: Allen Chen 
Reviewed-by: Robert Foss 
---
 drivers/gpu/drm/bridge/ite-it6505.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index aa5e0aa1af85..cfd2c3275dc5 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -518,6 +518,9 @@ static int it6505_read(struct it6505 *it6505, unsigned int 
reg_addr)
int err;
struct device *dev = >client->dev;
 
+   if (!it6505->powered)
+   return -ENODEV;
+
err = regmap_read(it6505->regmap, reg_addr, );
if (err < 0) {
dev_err(dev, "read failed reg[0x%x] err: %d", reg_addr, err);
@@ -533,6 +536,9 @@ static int it6505_write(struct it6505 *it6505, unsigned int 
reg_addr,
int err;
struct device *dev = >client->dev;
 
+   if (!it6505->powered)
+   return -ENODEV;
+
err = regmap_write(it6505->regmap, reg_addr, reg_val);
 
if (err < 0) {
@@ -550,6 +556,9 @@ static int it6505_set_bits(struct it6505 *it6505, unsigned 
int reg,
int err;
struct device *dev = >client->dev;
 
+   if (!it6505->powered)
+   return -ENODEV;
+
err = regmap_update_bits(it6505->regmap, reg, mask, value);
if (err < 0) {
dev_err(dev, "write reg[0x%x] = 0x%x mask = 0x%x failed err %d",
@@ -2553,13 +2562,12 @@ static int it6505_poweron(struct it6505 *it6505)
usleep_range(1, 2);
}
 
+   it6505->powered = true;
it6505_reset_logic(it6505);
it6505_int_mask_enable(it6505);
it6505_init(it6505);
it6505_lane_off(it6505);
 
-   it6505->powered = true;
-
return 0;
 }
 
-- 
2.25.1

[PATCH v2 3/3] drm/bridge: it6505: Modified video clock calculation and video debug message

From: allen chen 

Speed up video clock calculation and remove redundant video debug message.

Signed-off-by: Pin-Yen Lin 
Signed-off-by: Allen Chen 
Reviewed-by: Robert Foss 
---
 drivers/gpu/drm/bridge/ite-it6505.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index cfd2c3275dc5..11a34ddb60a1 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -703,7 +703,7 @@ static void it6505_calc_video_info(struct it6505 *it6505)
DRM_DEV_DEBUG_DRIVER(dev, "hactive_start:%d, vactive_start:%d",
 hdes, vdes);
 
-   for (i = 0; i < 10; i++) {
+   for (i = 0; i < 3; i++) {
it6505_set_bits(it6505, REG_DATA_CTRL0, ENABLE_PCLK_COUNTER,
ENABLE_PCLK_COUNTER);
usleep_range(1, 15000);
@@ -720,7 +720,7 @@ static void it6505_calc_video_info(struct it6505 *it6505)
return;
}
 
-   sum /= 10;
+   sum /= 3;
pclk = 13500 * 2048 / sum;
it6505->video_info.clock = pclk;
it6505->video_info.hdisplay = hdew;
@@ -2344,8 +2344,6 @@ static void it6505_irq_hpd(struct it6505 *it6505)
 
if (!it6505_get_video_status(it6505))
it6505_video_reset(it6505);
-
-   it6505_calc_video_info(it6505);
} else {
memset(it6505->dpcd, 0, sizeof(it6505->dpcd));
 
-- 
2.25.1

[PATCH v2 1/3] drm/bridge: it6505: Modified power sequence

From: allen chen 

Change power sequence to meet it6505 data sheet requirement when boot on.

Signed-off-by: Pin-Yen Lin 
Signed-off-by: Allen Chen 
Reviewed-by: Robert Foss 
---
 drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index 2d119e3016b3..aa5e0aa1af85 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -3029,7 +3029,7 @@ static int it6505_init_pdata(struct it6505 *it6505)
return PTR_ERR(pdata->ovdd);
}
 
-   pdata->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+   pdata->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(pdata->gpiod_reset)) {
dev_err(dev, "gpiod_reset gpio not found");
return PTR_ERR(pdata->gpiod_reset);
-- 
2.25.1

[PATCH v2 0/3] drm/bridge: it6505: Fixes bugs

From: allen chen 

This series fixes some it6505 driver bugs and improve computing time.

Changes in v2:
  -  Change committe message occure to occur.

allen chen (3):
  drm/bridge: it6505: Modified power sequence
  drm/bridge: it6505: Add i2c api power on check
  drm/bridge: it6505: Modified video clock calculation and video debug
message

 drivers/gpu/drm/bridge/ite-it6505.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

-- 
2.25.1

[PATCH] mm/gup: migrate device coherent pages when pinning instead of failing

2022-07-14 Thread Alistair Popple

Currently any attempts to pin a device coherent page will fail. This is
because device coherent pages need to be managed by a device driver, and
pinning them would prevent a driver from migrating them off the device.

However this is no reason to fail pinning of these pages. These are
coherent and accessible from the CPU so can be migrated just like
pinning ZONE_MOVABLE pages. So instead of failing all attempts to pin
them first try migrating them out of ZONE_DEVICE.

[hch: rebased to the split device memory checks,
  moved migrate_device_page to migrate_device.c]

Signed-off-by: Alistair Popple 
Acked-by: Felix Kuehling 
Signed-off-by: Christoph Hellwig 
---

This patch hopefully addresses all of David's comments. It replaces both my "mm:
remove the vma check in migrate_vma_setup()" and "mm/gup: migrate device
coherent pages when pinning instead of failing" patches. I'm not sure what the
best way of including this is, perhaps Alex can respin the series with this
patch instead?

 - Alistair

 mm/gup.c| 50 +--
 mm/internal.h   |  1 +
 mm/migrate_device.c | 52 +
 3 files changed, 96 insertions(+), 7 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index b65fe8bf5af4..22b97ab61cd9 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1881,7 +1881,7 @@ static long check_and_migrate_movable_pages(unsigned long 
nr_pages,
unsigned long isolation_error_count = 0, i;
struct folio *prev_folio = NULL;
LIST_HEAD(movable_page_list);
-   bool drain_allow = true;
+   bool drain_allow = true, coherent_pages = false;
int ret = 0;
 
for (i = 0; i < nr_pages; i++) {
@@ -1891,9 +1891,38 @@ static long check_and_migrate_movable_pages(unsigned 
long nr_pages,
continue;
prev_folio = folio;
 
-   if (folio_is_longterm_pinnable(folio))
+   /*
+* Device coherent pages are managed by a driver and should not
+* be pinned indefinitely as it prevents the driver moving the
+* page. So when trying to pin with FOLL_LONGTERM instead try
+* to migrate the page out of device memory.
+*/
+   if (folio_is_device_coherent(folio)) {
+   /*
+* We always want a new GUP lookup with device coherent
+* pages.
+*/
+   pages[i] = 0;
+   coherent_pages = true;
+
+   /*
+* Migration will fail if the page is pinned, so convert
+* the pin on the source page to a normal reference.
+*/
+   if (gup_flags & FOLL_PIN) {
+   get_page(>page);
+   unpin_user_page(>page);
+   }
+
+   ret = migrate_device_coherent_page(>page);
+   if (ret)
+   goto unpin_pages;
+
continue;
+   }
 
+   if (folio_is_longterm_pinnable(folio))
+   continue;
/*
 * Try to move out any movable page before pinning the range.
 */
@@ -1919,7 +1948,8 @@ static long check_and_migrate_movable_pages(unsigned long 
nr_pages,
folio_nr_pages(folio));
}
 
-   if (!list_empty(_page_list) || isolation_error_count)
+   if (!list_empty(_page_list) || isolation_error_count
+   || coherent_pages)
goto unpin_pages;
 
/*
@@ -1929,10 +1959,16 @@ static long check_and_migrate_movable_pages(unsigned 
long nr_pages,
return nr_pages;
 
 unpin_pages:
-   if (gup_flags & FOLL_PIN) {
-   unpin_user_pages(pages, nr_pages);
-   } else {
-   for (i = 0; i < nr_pages; i++)
+   /*
+* pages[i] might be NULL if any device coherent pages were found.
+*/
+   for (i = 0; i < nr_pages; i++) {
+   if (!pages[i])
+   continue;
+
+   if (gup_flags & FOLL_PIN)
+   unpin_user_page(pages[i]);
+   else
put_page(pages[i]);
}
 
diff --git a/mm/internal.h b/mm/internal.h
index c0f8fbe0445b..899dab512c5a 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -853,6 +853,7 @@ int numa_migrate_prep(struct page *page, struct 
vm_area_struct *vma,
  unsigned long addr, int page_nid, int *flags);
 
 void free_zone_device_page(struct page *page);
+int migrate_device_coherent_page(struct page *page);
 
 /*
  * mm/gup.c
diff --git a/mm/migrate_device.c b/mm/migrate_device.c
index 18bc6483f63a..7feeb447e3b9 100644
--- a/mm/migrate_device.c
+++ b/mm/migrate_device.c
@@ -686,6 +686,12 @@ void

Re: [PATCH] drm/i915/guc: Don't use pr_err when not necessary

2022-07-14 Thread John Harrison


On 7/14/2022 17:40, john.c.harri...@intel.com wrote:

From: John Harrison 

A bunch of code was copy/pasted using pr_err as the default way to
report errors. However, drm_err is significantly more useful in
identifying where the error came from. So update the code to use that
instead.

Signed-off-by: John Harrison 
PS: Forgot to include the r-b tag from the previous post of this patch. 
Only change to this one is fix the last minute drm_debug to be drm_dbg 
and word the the commit message a bit better.




On 6/7/2022 15:25, Dixit, Ashutosh wrote:

On Tue, 07 Jun 2022 15:23:17 -0700, John Harrison wrote:

On 6/7/2022 15:07, Dixit, Ashutosh wrote:

On Tue, 07 Jun 2022 14:51:03 -0700, john.c.harri...@intel.com wrote:

From: John Harrison 

Don't use pr_err in places where we have access to a struct_drm.

Seem to be many more pr_err's in selftests. Is there a reason why drm_err's
cannot be used in selftests (especially those using an i915 device)?
Thanks.

I figured I'd start small and just do the gt/uc ones to being with as those
are the ones that affect me.

It sounds like the only reason to use pr_err is in the mock selftests where
there is no easy access to a DRM structure. For everything else, there is
no reason that I am aware of.

Fair enough:

Reviewed-by: Ashutosh Dixit 





---
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 10 ++---
  drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 37 +--
  .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   | 10 ++---
  3 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 27363091e1afa..19fde6bda8f9c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -195,11 +195,11 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
fw_blobs[i].rev < fw_blobs[i - 1].rev)
continue;
  
-			pr_err("invalid FW blob order: %s r%u comes before %s r%u\n",

-  intel_platform_name(fw_blobs[i - 1].p),
-  fw_blobs[i - 1].rev,
-  intel_platform_name(fw_blobs[i].p),
-  fw_blobs[i].rev);
+   drm_err(>drm, "Invalid FW blob order: %s r%u comes 
before %s r%u\n",
+   intel_platform_name(fw_blobs[i - 1].p),
+   fw_blobs[i - 1].rev,
+   intel_platform_name(fw_blobs[i].p),
+   fw_blobs[i].rev);
  
  			uc_fw->path = NULL;

}
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c 
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index 1df71d0796aec..20e0c39259fba 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -62,7 +62,7 @@ static int intel_guc_scrub_ctbs(void *arg)
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
ret = PTR_ERR(ce);
-   pr_err("Failed to create context, %d: %d\n", i, ret);
+   drm_err(>i915->drm, "Failed to create context, %d: 
%d\n", i, ret);
goto err;
}
  
@@ -83,7 +83,7 @@ static int intel_guc_scrub_ctbs(void *arg)
  
  		if (IS_ERR(rq)) {

ret = PTR_ERR(rq);
-   pr_err("Failed to create request, %d: %d\n", i, ret);
+   drm_err(>i915->drm, "Failed to create request, %d: 
%d\n", i, ret);
goto err;
}
  
@@ -93,7 +93,7 @@ static int intel_guc_scrub_ctbs(void *arg)

for (i = 0; i < 3; ++i) {
ret = i915_request_wait(last[i], 0, HZ);
if (ret < 0) {
-   pr_err("Last request failed to complete: %d\n", ret);
+   drm_err(>i915->drm, "Last request failed to complete: 
%d\n", ret);
goto err;
}
i915_request_put(last[i]);
@@ -110,7 +110,7 @@ static int intel_guc_scrub_ctbs(void *arg)
/* GT will not idle if G2H are lost */
ret = intel_gt_wait_for_idle(gt, HZ);
if (ret < 0) {
-   pr_err("GT failed to idle: %d\n", ret);
+   drm_err(>i915->drm, "GT failed to idle: %d\n", ret);
goto err;
}
  
@@ -150,7 +150,7 @@ static int intel_guc_steal_guc_ids(void *arg)
  
  	ce = kcalloc(GUC_MAX_CONTEXT_ID, sizeof(*ce), GFP_KERNEL);

if (!ce) {
-   pr_err("Context array allocation failed\n");
+   drm_err(>i915->drm, "Context array allocation failed\n");
return -ENOMEM;
}
  
@@ -164,24 +164,24 @@ static int intel_guc_steal_guc_ids(void *arg)

if (IS_ERR(ce[context_index])) {
ret = PTR_ERR(ce[context_index]);

[PATCH v1 2/6] drm/gem: Take reservation lock for vmap/vunmap operations

The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked functions for the case where DRM core now holds
the lock. This patch prepares DRM core and drivers to transition to the
common dma-buf locking convention where vmapping of exported GEMs will
be done under the held reservation lock.

Signed-off-by: Dmitry Osipenko 
---
 drivers/gpu/drm/drm_client.c |  4 +--
 drivers/gpu/drm/drm_gem.c| 28 
 drivers/gpu/drm/drm_gem_framebuffer_helper.c |  6 ++---
 drivers/gpu/drm/drm_prime.c  |  4 +--
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   |  2 +-
 drivers/gpu/drm/qxl/qxl_object.c | 17 ++--
 drivers/gpu/drm/qxl/qxl_prime.c  |  4 +--
 include/drm/drm_gem.h|  3 +++
 8 files changed, 50 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 2b230b4d6942..fbcb1e995384 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -323,7 +323,7 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer,
 * fd_install step out of the driver backend hooks, to make that
 * final step optional for internal users.
 */
-   ret = drm_gem_vmap(buffer->gem, map);
+   ret = drm_gem_vmap_unlocked(buffer->gem, map);
if (ret)
return ret;
 
@@ -345,7 +345,7 @@ void drm_client_buffer_vunmap(struct drm_client_buffer 
*buffer)
 {
struct iosys_map *map = >map;
 
-   drm_gem_vunmap(buffer->gem, map);
+   drm_gem_vunmap_unlocked(buffer->gem, map);
 }
 EXPORT_SYMBOL(drm_client_buffer_vunmap);
 
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index eb0c2d041f13..9769c33cad99 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1155,6 +1155,8 @@ void drm_gem_print_info(struct drm_printer *p, unsigned 
int indent,
 
 int drm_gem_pin(struct drm_gem_object *obj)
 {
+   dma_resv_assert_held(obj->resv);
+
if (obj->funcs->pin)
return obj->funcs->pin(obj);
else
@@ -1163,6 +1165,8 @@ int drm_gem_pin(struct drm_gem_object *obj)
 
 void drm_gem_unpin(struct drm_gem_object *obj)
 {
+   dma_resv_assert_held(obj->resv);
+
if (obj->funcs->unpin)
obj->funcs->unpin(obj);
 }
@@ -1171,6 +1175,8 @@ int drm_gem_vmap(struct drm_gem_object *obj, struct 
iosys_map *map)
 {
int ret;
 
+   dma_resv_assert_held(obj->resv);
+
if (!obj->funcs->vmap)
return -EOPNOTSUPP;
 
@@ -1186,6 +1192,8 @@ EXPORT_SYMBOL(drm_gem_vmap);
 
 void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
 {
+   dma_resv_assert_held(obj->resv);
+
if (iosys_map_is_null(map))
return;
 
@@ -1197,6 +1205,26 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct 
iosys_map *map)
 }
 EXPORT_SYMBOL(drm_gem_vunmap);
 
+int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+   int ret;
+
+   dma_resv_lock(obj->resv, NULL);
+   ret = drm_gem_vmap(obj, map);
+   dma_resv_unlock(obj->resv);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_gem_vmap_unlocked);
+
+void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+   dma_resv_lock(obj->resv, NULL);
+   drm_gem_vunmap(obj, map);
+   dma_resv_unlock(obj->resv);
+}
+EXPORT_SYMBOL(drm_gem_vunmap_unlocked);
+
 /**
  * drm_gem_lock_reservations - Sets up the ww context and acquires
  * the lock on an array of GEM objects.
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 880a4975507f..e35e224e6303 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -354,7 +354,7 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb, struct 
iosys_map *map,
ret = -EINVAL;
goto err_drm_gem_vunmap;
}
-   ret = drm_gem_vmap(obj, [i]);
+   ret = drm_gem_vmap_unlocked(obj, [i]);
if (ret)
goto err_drm_gem_vunmap;
}
@@ -376,7 +376,7 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb, struct 
iosys_map *map,
obj = drm_gem_fb_get_obj(fb, i);
if (!obj)
continue;
-   drm_gem_vunmap(obj, [i]);
+   drm_gem_vunmap_unlocked(obj, [i]);
}
return ret;
 }
@@ -403,7 +403,7 @@ void drm_gem_fb_vunmap(struct drm_framebuffer *fb, struct 
iosys_map *map)
continue;
if (iosys_map_is_null([i]))
continue;
-   drm_gem_vunmap(obj, [i]);
+   drm_gem_vunmap_unlocked(obj,

[PATCH v1 6/6] dma-buf: Remove internal lock

The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.

Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/dma-buf.c | 5 -
 include/linux/dma-buf.h   | 9 -
 2 files changed, 14 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 37545ecb845a..4cc739537ebd 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -656,7 +656,6 @@ struct dma_buf *dma_buf_export(const struct 
dma_buf_export_info *exp_info)
 
dmabuf->file = file;
 
-   mutex_init(>lock);
INIT_LIST_HEAD(>attachments);
 
mutex_lock(_list.lock);
@@ -1459,7 +1458,6 @@ int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct 
iosys_map *map)
return -EINVAL;
 
dma_resv_lock(dmabuf->resv, NULL);
-   mutex_lock(>lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(>vmap_ptr));
@@ -1479,7 +1477,6 @@ int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct 
iosys_map *map)
*map = dmabuf->vmap_ptr;
 
 out_unlock:
-   mutex_unlock(>lock);
dma_resv_unlock(dmabuf->resv);
return ret;
 }
@@ -1500,13 +1497,11 @@ void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf, 
struct iosys_map *map)
BUG_ON(!iosys_map_is_equal(>vmap_ptr, map));
 
dma_resv_lock(dmabuf->resv, NULL);
-   mutex_lock(>lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(>vmap_ptr);
}
-   mutex_unlock(>lock);
dma_resv_unlock(dmabuf->resv);
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, DMA_BUF);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index da924a56d58f..abdd99042c77 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
 
-   /**
-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
-   struct mutex lock;
-
/**
 * @vmapping_counter:
 *
-- 
2.36.1

[PATCH v1 1/6] dma-buf: Add _unlocked postfix to function names

Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later on we will make the "unlocked"
functions to take the reservation lock.

Suggested-by: Christian König 
Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/dma-buf.c | 76 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |  4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  4 +-
 drivers/gpu/drm/armada/armada_gem.c   | 14 ++--
 drivers/gpu/drm/drm_gem_cma_helper.c  |  6 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c|  6 +-
 drivers/gpu/drm/drm_prime.c   | 12 +--
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c   |  6 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 12 +--
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 20 ++---
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  8 +-
 drivers/gpu/drm/tegra/gem.c   | 27 +++
 drivers/infiniband/core/umem_dmabuf.c | 11 +--
 .../common/videobuf2/videobuf2-dma-contig.c   | 15 ++--
 .../media/common/videobuf2/videobuf2-dma-sg.c | 12 +--
 .../common/videobuf2/videobuf2-vmalloc.c  |  6 +-
 .../platform/nvidia/tegra-vde/dmabuf-cache.c  | 12 +--
 drivers/misc/fastrpc.c| 12 +--
 drivers/xen/gntdev-dmabuf.c   | 14 ++--
 include/linux/dma-buf.h   | 34 +
 21 files changed, 161 insertions(+), 152 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 44574fbe7482..d16237a6ffaa 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -795,7 +795,7 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
 }
 
 /**
- * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list
+ * dma_buf_dynamic_attach_unlocked - Add the device to dma_buf's attachments 
list
  * @dmabuf:[in]buffer to attach device to.
  * @dev:   [in]device to be attached.
  * @importer_ops:  [in]importer operations for the attachment
@@ -817,9 +817,9 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
  * indicated with the error code -EBUSY.
  */
 struct dma_buf_attachment *
-dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
-  const struct dma_buf_attach_ops *importer_ops,
-  void *importer_priv)
+dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, struct device *dev,
+   const struct dma_buf_attach_ops *importer_ops,
+   void *importer_priv)
 {
struct dma_buf_attachment *attach;
int ret;
@@ -892,25 +892,25 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct 
device *dev,
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
 
-   dma_buf_detach(dmabuf, attach);
+   dma_buf_detach_unlocked(dmabuf, attach);
return ERR_PTR(ret);
 }
-EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
+EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach_unlocked, DMA_BUF);
 
 /**
- * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
+ * dma_buf_attach_unlocked - Wrapper for dma_buf_dynamic_attach
  * @dmabuf:[in]buffer to attach device to.
  * @dev:   [in]device to be attached.
  *
- * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a 
static
- * mapping.
+ * Wrapper to call dma_buf_dynamic_attach_unlocked() for drivers which still
+ * use a static mapping.
  */
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *dma_buf_attach_unlocked(struct dma_buf *dmabuf,
+  struct device *dev)
 {
-   return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
+   return dma_buf_dynamic_attach_unlocked(dmabuf, dev, NULL, NULL);
 }
-EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
+EXPORT_SYMBOL_NS_GPL(dma_buf_attach_unlocked, DMA_BUF);
 
 static void __unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sg_table,
@@ -923,7 +923,7 @@ static void __unmap_dma_buf(struct dma_buf_attachment 
*attach,
 }
 
 /**
- * dma_buf_detach - Remove the given attachment from dmabuf's attachments list
+ * dma_buf_detach_unlocked - Remove the given attachment from dmabuf's 
attachments list
  * @dmabuf:[in]buffer to detach from.
  * @attach:[in]attachment to be detached; is free'd after this call.
  *
@@ -931,7 +931,8 @@ static void __unmap_dma_buf(struct dma_buf_attachment 
*attach,
  *
  * Optionally this calls _buf_ops.detach for device-specific detach.
  */
-void dma_buf_detach(struct

[PATCH v1 4/6] dma-buf: Acquire wait-wound context on attachment

Intel i915 GPU driver uses wait-wound mutex to lock multiple GEMs on the
attachment to the i915 dma-buf. In order to let all drivers utilize shared
wait-wound context during attachment in a general way, make dma-buf core to
acquire the ww context internally for the attachment operation and update
i915 driver to use the importer's ww context instead of the internal one.

>From now on all dma-buf exporters shall use the importer's ww context for
the attachment operation.

Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/dma-buf.c |  8 +-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  2 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  2 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  6 ++---
 drivers/gpu/drm/i915/i915_gem_evict.c |  2 +-
 drivers/gpu/drm/i915/i915_gem_ww.c| 26 +++
 drivers/gpu/drm/i915/i915_gem_ww.h| 15 +--
 7 files changed, 47 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 0ee588276534..37545ecb845a 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -807,6 +807,8 @@ static struct sg_table * __map_dma_buf(struct 
dma_buf_attachment *attach,
  * Optionally this calls _buf_ops.attach to allow device-specific attach
  * functionality.
  *
+ * Exporters shall use ww_ctx acquired by this function.
+ *
  * Returns:
  *
  * A pointer to newly created _buf_attachment on success, or a negative
@@ -822,6 +824,7 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, 
struct device *dev,
void *importer_priv)
 {
struct dma_buf_attachment *attach;
+   struct ww_acquire_ctx ww_ctx;
int ret;
 
if (WARN_ON(!dmabuf || !dev))
@@ -841,7 +844,8 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, 
struct device *dev,
attach->importer_ops = importer_ops;
attach->importer_priv = importer_priv;
 
-   dma_resv_lock(dmabuf->resv, NULL);
+   ww_acquire_init(_ctx, _ww_class);
+   dma_resv_lock(dmabuf->resv, _ctx);
 
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, attach);
@@ -876,11 +880,13 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, 
struct device *dev,
}
 
dma_resv_unlock(dmabuf->resv);
+   ww_acquire_fini(_ctx);
 
return attach;
 
 err_attach:
dma_resv_unlock(attach->dmabuf->resv);
+   ww_acquire_fini(_ctx);
kfree(attach);
return ERR_PTR(ret);
 
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index c199bf71c373..9173f0232b16 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -173,7 +173,7 @@ static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
if (!i915_gem_object_can_migrate(obj, INTEL_REGION_SMEM))
return -EOPNOTSUPP;
 
-   for_i915_gem_ww(, err, true) {
+   for_i915_dmabuf_ww(, dmabuf, err, true) {
err = i915_gem_object_migrate(obj, , INTEL_REGION_SMEM);
if (err)
continue;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 30fe847c6664..ad7d602fc43a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -3409,7 +3409,7 @@ i915_gem_do_execbuffer(struct drm_device *dev,
goto err_vma;
}
 
-   ww_acquire_done();
+   ww_acquire_done(eb.ww.ctx);
eb_capture_stage();
 
out_fence = eb_requests_create(, in_fence, out_fence_fd);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index e11d82a9f7c3..5ae38f94a5c7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -178,9 +178,9 @@ static inline int __i915_gem_object_lock(struct 
drm_i915_gem_object *obj,
int ret;
 
if (intr)
-   ret = dma_resv_lock_interruptible(obj->base.resv, ww ? >ctx 
: NULL);
+   ret = dma_resv_lock_interruptible(obj->base.resv, ww ? ww->ctx 
: NULL);
else
-   ret = dma_resv_lock(obj->base.resv, ww ? >ctx : NULL);
+   ret = dma_resv_lock(obj->base.resv, ww ? ww->ctx : NULL);
 
if (!ret && ww) {
i915_gem_object_get(obj);
@@ -216,7 +216,7 @@ static inline bool i915_gem_object_trylock(struct 
drm_i915_gem_object *obj,
if (!ww)
return dma_resv_trylock(obj->base.resv);
else
-   return ww_mutex_trylock(>base.resv->lock, >ctx);
+   return ww_mutex_trylock(>base.resv->lock, ww->ctx);
 }
 
 static inline void i915_gem_object_unlock(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index

[PATCH v1 3/6] dma-buf: Move all dma-bufs to dynamic locking specification

This patch moves the non-dynamic dma-buf users over to the dynamic
locking specification. From now on all dma-buf importers are responsible
for holding dma-buf's reservation lock around operations performed over
dma-bufs. This strict locking convention prevents dead lock situation for
dma-buf importers and exporters.

Previously the "unlocked" versions of the dma-buf API functions weren't
taking the reservation lock and this patch makes them to take the lock.

Intel and AMD GPU drivers already were mapping imported dma-bufs under
the held lock, hence the "locked" variant of the functions are added
for them and the drivers are updated to use the "locked" versions.

Intel driver is also updated to not lock the exported buffer on
attachment since lock is now held by importer. We also need to move
the ww context acquirement from exporters (i915 driver) to importers,
otherwise lockdep won't be happy. This will be done in the next patch
since i915 is the only driver that uses ww context on attachment today
and it's not critical to make this change separately for i915 driver.

Signed-off-by: Dmitry Osipenko 
---
 drivers/dma-buf/dma-buf.c  | 125 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|   4 +-
 drivers/gpu/drm/drm_prime.c|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c |  12 +-
 include/linux/dma-buf.h|   6 +
 5 files changed, 104 insertions(+), 47 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d16237a6ffaa..0ee588276534 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -841,14 +841,14 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, 
struct device *dev,
attach->importer_ops = importer_ops;
attach->importer_priv = importer_priv;
 
+   dma_resv_lock(dmabuf->resv, NULL);
+
if (dmabuf->ops->attach) {
ret = dmabuf->ops->attach(dmabuf, attach);
if (ret)
goto err_attach;
}
-   dma_resv_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
-   dma_resv_unlock(dmabuf->resv);
 
/* When either the importer or the exporter can't handle dynamic
 * mappings we cache the mapping here to avoid issues with the
@@ -859,7 +859,6 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, 
struct device *dev,
struct sg_table *sgt;
 
if (dma_buf_is_dynamic(attach->dmabuf)) {
-   dma_resv_lock(attach->dmabuf->resv, NULL);
ret = dmabuf->ops->pin(attach);
if (ret)
goto err_unlock;
@@ -872,15 +871,16 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, 
struct device *dev,
ret = PTR_ERR(sgt);
goto err_unpin;
}
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_unlock(attach->dmabuf->resv);
attach->sgt = sgt;
attach->dir = DMA_BIDIRECTIONAL;
}
 
+   dma_resv_unlock(dmabuf->resv);
+
return attach;
 
 err_attach:
+   dma_resv_unlock(attach->dmabuf->resv);
kfree(attach);
return ERR_PTR(ret);
 
@@ -889,8 +889,7 @@ dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, 
struct device *dev,
dmabuf->ops->unpin(attach);
 
 err_unlock:
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_unlock(attach->dmabuf->resv);
+   dma_resv_unlock(dmabuf->resv);
 
dma_buf_detach_unlocked(dmabuf, attach);
return ERR_PTR(ret);
@@ -937,24 +936,23 @@ void dma_buf_detach_unlocked(struct dma_buf *dmabuf,
if (WARN_ON(!dmabuf || !attach))
return;
 
-   if (attach->sgt) {
-   if (dma_buf_is_dynamic(attach->dmabuf))
-   dma_resv_lock(attach->dmabuf->resv, NULL);
+   if (WARN_ON(dmabuf != attach->dmabuf))
+   return;
 
+   dma_resv_lock(dmabuf->resv, NULL);
+
+   if (attach->sgt) {
__unmap_dma_buf(attach, attach->sgt, attach->dir);
 
-   if (dma_buf_is_dynamic(attach->dmabuf)) {
+   if (dma_buf_is_dynamic(attach->dmabuf))
dmabuf->ops->unpin(attach);
-   dma_resv_unlock(attach->dmabuf->resv);
-   }
}
-
-   dma_resv_lock(dmabuf->resv, NULL);
list_del(>node);
-   dma_resv_unlock(dmabuf->resv);
+
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
 
+   dma_resv_unlock(dmabuf->resv);
kfree(attach);
 }
 EXPORT_SYMBOL_NS_GPL(dma_buf_detach_unlocked, DMA_BUF);
@@ -1030,10 +1028,11 @@ EXPORT_SYMBOL_NS_GPL(dma_buf_unpin, DMA_BUF);
  *
  * Important: Dynamic importers must wait for the exclusive fence of the struct
  * dma_resv attached to the DMA-BUF first.
+ *
+ * Importer is responsible for

[PATCH v1 5/6] media: videobuf2: Stop using internal dma-buf lock

All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.

Signed-off-by: Dmitry Osipenko 
---
 drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
 drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +--
 drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +--
 3 files changed, 3 insertions(+), 30 deletions(-)

diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c 
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index de762dbdaf78..2c69bf0470e7 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -382,18 +382,12 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
 {
struct vb2_dc_attachment *attach = db_attach->priv;
-   /* stealing dmabuf mutex to serialize map/unmap operations */
-   struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
 
-   mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
-   if (attach->dma_dir == dma_dir) {
-   mutex_unlock(lock);
+   if (attach->dma_dir == dma_dir)
return sgt;
-   }
 
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -409,14 +403,11 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
DMA_ATTR_SKIP_CPU_SYNC)) {
pr_err("failed to map scatterlist\n");
-   mutex_unlock(lock);
return ERR_PTR(-EIO);
}
 
attach->dma_dir = dma_dir;
 
-   mutex_unlock(lock);
-
return sgt;
 }
 
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c 
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 39e11600304a..e63e718c0bf7 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -424,18 +424,12 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
 {
struct vb2_dma_sg_attachment *attach = db_attach->priv;
-   /* stealing dmabuf mutex to serialize map/unmap operations */
-   struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
 
-   mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
-   if (attach->dma_dir == dma_dir) {
-   mutex_unlock(lock);
+   if (attach->dma_dir == dma_dir)
return sgt;
-   }
 
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -446,14 +440,11 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
-   mutex_unlock(lock);
return ERR_PTR(-EIO);
}
 
attach->dma_dir = dma_dir;
 
-   mutex_unlock(lock);
-
return sgt;
 }
 
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c 
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 7831bf545874..41db707e43a4 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -267,18 +267,12 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
 {
struct vb2_vmalloc_attachment *attach = db_attach->priv;
-   /* stealing dmabuf mutex to serialize map/unmap operations */
-   struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
 
-   mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
-   if (attach->dma_dir == dma_dir) {
-   mutex_unlock(lock);
+   if (attach->dma_dir == dma_dir)
return sgt;
-   }
 
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -289,14 +283,11 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
-   mutex_unlock(lock);
return ERR_PTR(-EIO);
}
 
attach->dma_dir = dma_dir;
 
-   mutex_unlock(lock);
-
return sgt;
 }
 
-- 
2.36.1

[PATCH v1 0/6] Move all drivers to a common dma-buf locking convention

Hello,

This series moves all drivers to a dynamic dma-buf locking specification.
>From now on all dma-buf importers are made responsible for holding
dma-buf's reservation lock around all operations performed over dma-bufs.
This common locking convention allows us to utilize reservation lock more
broadly around kernel without fearing of potential dead locks.

This patchset passes all i915 selftests. It was also tested using VirtIO,
Panfrost, Lima and Tegra drivers. I tested cases of display+GPU,
display+V4L and GPU+V4L dma-buf sharing, which covers majority of kernel
drivers since rest of the drivers share same or similar code paths.

This is a continuation of [1] where Christian König asked to factor out
the dma-buf locking changes into separate series.

[1] 
https://lore.kernel.org/dri-devel/20220526235040.678984-1-dmitry.osipe...@collabora.com/

Dmitry Osipenko (6):
  dma-buf: Add _unlocked postfix to function names
  drm/gem: Take reservation lock for vmap/vunmap operations
  dma-buf: Move all dma-bufs to dynamic locking specification
  dma-buf: Acquire wait-wound context on attachment
  media: videobuf2: Stop using internal dma-buf lock
  dma-buf: Remove internal lock

 drivers/dma-buf/dma-buf.c | 198 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c   |   4 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |   4 +-
 drivers/gpu/drm/armada/armada_gem.c   |  14 +-
 drivers/gpu/drm/drm_client.c  |   4 +-
 drivers/gpu/drm/drm_gem.c |  28 +++
 drivers/gpu/drm/drm_gem_cma_helper.c  |   6 +-
 drivers/gpu/drm/drm_gem_framebuffer_helper.c  |   6 +-
 drivers/gpu/drm/drm_gem_shmem_helper.c|   6 +-
 drivers/gpu/drm/drm_prime.c   |  12 +-
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c   |   6 +-
 drivers/gpu/drm/exynos/exynos_drm_gem.c   |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c|  20 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   6 +-
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  |  20 +-
 drivers/gpu/drm/i915/i915_gem_evict.c |   2 +-
 drivers/gpu/drm/i915/i915_gem_ww.c|  26 ++-
 drivers/gpu/drm/i915/i915_gem_ww.h|  15 +-
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |   8 +-
 drivers/gpu/drm/qxl/qxl_object.c  |  17 +-
 drivers/gpu/drm/qxl/qxl_prime.c   |   4 +-
 drivers/gpu/drm/tegra/gem.c   |  27 +--
 drivers/infiniband/core/umem_dmabuf.c |  11 +-
 .../common/videobuf2/videobuf2-dma-contig.c   |  26 +--
 .../media/common/videobuf2/videobuf2-dma-sg.c |  23 +-
 .../common/videobuf2/videobuf2-vmalloc.c  |  17 +-
 .../platform/nvidia/tegra-vde/dmabuf-cache.c  |  12 +-
 drivers/misc/fastrpc.c|  12 +-
 drivers/xen/gntdev-dmabuf.c   |  14 +-
 include/drm/drm_gem.h |   3 +
 include/linux/dma-buf.h   |  49 ++---
 32 files changed, 347 insertions(+), 257 deletions(-)

-- 
2.36.1

[PATCH] drm/i915/guc: Don't use pr_err when not necessary

2022-07-14 Thread John . C . Harrison

From: John Harrison 

A bunch of code was copy/pasted using pr_err as the default way to
report errors. However, drm_err is significantly more useful in
identifying where the error came from. So update the code to use that
instead.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 10 ++---
 drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 37 +--
 .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   | 10 ++---
 3 files changed, 28 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 27363091e1afa..19fde6bda8f9c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -195,11 +195,11 @@ __uc_fw_auto_select(struct drm_i915_private *i915, struct 
intel_uc_fw *uc_fw)
fw_blobs[i].rev < fw_blobs[i - 1].rev)
continue;
 
-   pr_err("invalid FW blob order: %s r%u comes before %s 
r%u\n",
-  intel_platform_name(fw_blobs[i - 1].p),
-  fw_blobs[i - 1].rev,
-  intel_platform_name(fw_blobs[i].p),
-  fw_blobs[i].rev);
+   drm_err(>drm, "Invalid FW blob order: %s r%u 
comes before %s r%u\n",
+   intel_platform_name(fw_blobs[i - 1].p),
+   fw_blobs[i - 1].rev,
+   intel_platform_name(fw_blobs[i].p),
+   fw_blobs[i].rev);
 
uc_fw->path = NULL;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c 
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index 1df71d0796aec..20e0c39259fba 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -62,7 +62,7 @@ static int intel_guc_scrub_ctbs(void *arg)
ce = intel_context_create(engine);
if (IS_ERR(ce)) {
ret = PTR_ERR(ce);
-   pr_err("Failed to create context, %d: %d\n", i, ret);
+   drm_err(>i915->drm, "Failed to create context, %d: 
%d\n", i, ret);
goto err;
}
 
@@ -83,7 +83,7 @@ static int intel_guc_scrub_ctbs(void *arg)
 
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
-   pr_err("Failed to create request, %d: %d\n", i, ret);
+   drm_err(>i915->drm, "Failed to create request, %d: 
%d\n", i, ret);
goto err;
}
 
@@ -93,7 +93,7 @@ static int intel_guc_scrub_ctbs(void *arg)
for (i = 0; i < 3; ++i) {
ret = i915_request_wait(last[i], 0, HZ);
if (ret < 0) {
-   pr_err("Last request failed to complete: %d\n", ret);
+   drm_err(>i915->drm, "Last request failed to 
complete: %d\n", ret);
goto err;
}
i915_request_put(last[i]);
@@ -110,7 +110,7 @@ static int intel_guc_scrub_ctbs(void *arg)
/* GT will not idle if G2H are lost */
ret = intel_gt_wait_for_idle(gt, HZ);
if (ret < 0) {
-   pr_err("GT failed to idle: %d\n", ret);
+   drm_err(>i915->drm, "GT failed to idle: %d\n", ret);
goto err;
}
 
@@ -150,7 +150,7 @@ static int intel_guc_steal_guc_ids(void *arg)
 
ce = kcalloc(GUC_MAX_CONTEXT_ID, sizeof(*ce), GFP_KERNEL);
if (!ce) {
-   pr_err("Context array allocation failed\n");
+   drm_err(>i915->drm, "Context array allocation failed\n");
return -ENOMEM;
}
 
@@ -164,24 +164,24 @@ static int intel_guc_steal_guc_ids(void *arg)
if (IS_ERR(ce[context_index])) {
ret = PTR_ERR(ce[context_index]);
ce[context_index] = NULL;
-   pr_err("Failed to create context: %d\n", ret);
+   drm_err(>i915->drm, "Failed to create context: %d\n", ret);
goto err_wakeref;
}
ret = igt_spinner_init(, engine->gt);
if (ret) {
-   pr_err("Failed to create spinner: %d\n", ret);
+   drm_err(>i915->drm, "Failed to create spinner: %d\n", ret);
goto err_contexts;
}
spin_rq = igt_spinner_create_request(, ce[context_index],
 MI_ARB_CHECK);
if (IS_ERR(spin_rq)) {
ret = PTR_ERR(spin_rq);
-   pr_err("Failed to create spinner request: %d\n", ret);
+   drm_err(>i915->drm, "Failed to create spinner request: 
%d\n", ret);
goto err_contexts;
}
ret = request_add_spin(spin_rq, );
if (ret) {
-   pr_err("Failed to add Spinner request: %d\n", ret);
+

Re: [PATCH v5 4/9] drm: selftest: convert drm_format selftest to KUnit

On Thu, Jul 14, 2022 at 04:51:40PM -0700, Guenter Roeck wrote:
> On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
> > Considering the current adoption of the KUnit framework, convert the
> > DRM format selftest to the KUnit API.
> > 
> > Tested-by: David Gow 
> > Acked-by: Daniel Latypov 
> > Reviewed-by: Javier Martinez Canillas 
> > Signed-off-by: Maíra Canal 
> 
> This patch results in:
> 
> Building powerpc:allmodconfig ... failed
> --
> Error log:
> drivers/gpu/drm/tests/drm_format_test.c: In function 
> 'igt_check_drm_format_min_pitch':
> drivers/gpu/drm/tests/drm_format_test.c:271:1: error: the frame size of 3712 
> bytes is larger than 2048 bytes
> 

Also seen with i386:allyesconfig:

drivers/gpu/drm/tests/drm_format_test.c: In function 
'igt_check_drm_format_min_pitch':
drivers/gpu/drm/tests/drm_format_test.c:271:1: error: the frame size of 2572 
bytes is larger than 2048 bytes

Guenter

Re: [PATCH v5 4/9] drm: selftest: convert drm_format selftest to KUnit

On Fri, Jul 08, 2022 at 05:30:47PM -0300, Maíra Canal wrote:
> Considering the current adoption of the KUnit framework, convert the
> DRM format selftest to the KUnit API.
> 
> Tested-by: David Gow 
> Acked-by: Daniel Latypov 
> Reviewed-by: Javier Martinez Canillas 
> Signed-off-by: Maíra Canal 

This patch results in:

Building powerpc:allmodconfig ... failed
--
Error log:
drivers/gpu/drm/tests/drm_format_test.c: In function 
'igt_check_drm_format_min_pitch':
drivers/gpu/drm/tests/drm_format_test.c:271:1: error: the frame size of 3712 
bytes is larger than 2048 bytes

presumably due to function nesting.

Guenter

Re: [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

I assume you're probably good on review for the non-nouveau stuff, but if you
end up needing any help with that feel free to poke me!

On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> Hi All,
> 
> As mentioned in my RFC titled "drm/kms: control display brightness through
> drm_connector properties":
> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
> 
> The first step towards this is to deal with some existing technical debt
> in backlight handling on x86/ACPI boards, specifically we need to stop
> registering multiple /sys/class/backlight devs for a single display.
> 
> This series implements my RFC describing my plan for these cleanups:
> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/
> 
> This new version addresses the few small remarks made on version 1 (mainly
> changing patch 1/29) and more importantly this finishes the refactoring by
> else addressing all the bits from the "Other issues" section of
> the refactor RFC (resulting in patches 15-29 which are new in v2).
> 
> Please review and test! I hope to be able to make an immutable branch
> based on 5.20-rc1 + this series available for merging into the various
> touched subsystems once 5.20-rc2 is out.
> 
> Regards,
> 
> Hans
> 
> 
> Hans de Goede (29):
>   ACPI: video: Add acpi_video_backlight_use_native() helper
>   drm/i915: Don't register backlight when another backlight should be
>     used
>   drm/amdgpu: Don't register backlight when another backlight should be
>     used
>   drm/radeon: Don't register backlight when another backlight should be
>     used
>   drm/nouveau: Don't register backlight when another backlight should be
>     used
>   ACPI: video: Drop backlight_device_get_by_type() call from
>     acpi_video_get_backlight_type()
>   ACPI: video: Remove acpi_video_bus from list before tearing it down
>   ACPI: video: Simplify acpi_video_unregister_backlight()
>   ACPI: video: Make backlight class device registration a separate step
>   ACPI: video: Remove code to unregister acpi_video backlight when a
>     native backlight registers
>   drm/i915: Call acpi_video_register_backlight() (v2)
>   drm/nouveau: Register ACPI video backlight when nv_backlight
>     registration fails
>   drm/amdgpu: Register ACPI video backlight when skipping amdgpu
>     backlight registration
>   drm/radeon: Register ACPI video backlight when skipping radeon
>     backlight registration
>   ACPI: video: Refactor acpi_video_get_backlight_type() a bit
>   ACPI: video: Add Nvidia WMI EC brightness control detection
>   ACPI: video: Add Apple GMUX brightness control detection
>   platform/x86: apple-gmux: Stop calling acpi/video.h functions
>   platform/x86: toshiba_acpi: Stop using
>     acpi_video_set_dmi_backlight_type()
>   platform/x86: acer-wmi: Move backlight DMI quirks to
>     acpi/video_detect.c
>   platform/x86: asus-wmi: Drop DMI chassis-type check from backlight
>     handling
>   platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI
>     video_detect.c
>   platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI
>     video_detect.c
>   platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native]
>     quirks to ACPI video_detect.c
>   ACPI: video: Remove acpi_video_set_dmi_backlight_type()
>   ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
>   ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native
>     quirks
>   ACPI: video: Fix indentation of video_detect_dmi_table[] entries
>   drm/todo: Add entry about dealing with brightness control on devices
>     with > 1 panel
> 
>  Documentation/gpu/todo.rst    |  68 +++
>  drivers/acpi/Kconfig  |   1 +
>  drivers/acpi/acpi_video.c |  59 ++-
>  drivers/acpi/video_detect.c   | 415 +++---
>  drivers/gpu/drm/Kconfig   |  12 +
>  .../gpu/drm/amd/amdgpu/atombios_encoders.c    |  14 +-
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   9 +
>  drivers/gpu/drm/gma500/Kconfig    |   2 +
>  drivers/gpu/drm/i915/Kconfig  |   2 +
>  .../gpu/drm/i915/display/intel_backlight.c    |   7 +
>  drivers/gpu/drm/i915/display/intel_display.c  |   8 +
>  drivers/gpu/drm/i915/display/intel_panel.c    |   3 +
>  drivers/gpu/drm/i915/i915_drv.h   |   2 +
>  drivers/gpu/drm/nouveau/nouveau_backlight.c   |  14 +
>  drivers/gpu/drm/radeon/atombios_encoders.c    |   7 +
>  drivers/gpu/drm/radeon/radeon_encoders.c  |  11 +-
>  .../gpu/drm/radeon/radeon_legacy_encoders.c   |   7 +
>  drivers/platform/x86/acer-wmi.c   |  66 ---
>  drivers/platform/x86/apple-gmux.c |   3 -
>  drivers/platform/x86/asus-nb-wmi.c    |  21 -
>  drivers/platform/x86/asus-wmi.c   |  13 -
>  drivers/platform/x86/asus-wmi.h   |   2 -
>  drivers/platform/x86/eeepc-wmi.c  |  25 +-
>

Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Update to GuC version 70.1.1

2022-07-14 Thread Dave Airlie

On Fri, 15 Apr 2022 at 10:15, Matt Roper  wrote:
>
> On Tue, Apr 12, 2022 at 03:59:55PM -0700, john.c.harri...@intel.com wrote:
> > From: John Harrison 
> >
> > The latest GuC firmware drops the context descriptor pool in favour of
> > passing all creation data in the create H2G. It also greatly simplifies
> > the work queue and removes the process descriptor used for multi-LRC
> > submission. So, remove all mention of LRC and process descriptors and
> > update the registration code accordingly.
> >
> > Unfortunately, the new API also removes the ability to set default
> > values for the scheduling policies at context registration time.
> > Instead, a follow up H2G must be sent. The individual scheduling
> > policy update H2G commands are also dropped in favour of a single KLV
> > based H2G. So, change the update wrappers accordingly and call this
> > during context registration..
> >
> > Of course, this second H2G per registration might fail due to being
> > backed up. The registration code has a complicated state machine to
> > cope with the actual registration call failing. However, if that works
> > then there is no support for unwinding if a further call should fail.
> > Unwinding would require sending a H2G to de-register - but that can't
> > be done because the CTB is already backed up.
> >
> > So instead, add a new flag to say whether the context has a pending
> > policy update. This is set if the policy H2G fails at registration
> > time. The submission code checks for this flag and retries the policy
> > update if set. If that call fails, the submission path early exists
> > with a retry error. This is something that is already supported for
> > other reasons.
> >
> > Signed-off-by: John Harrison 
> > Reviewed-by: Daniele Ceraolo Spurio 
>
> Applied to drm-intel-gt-next.  Thanks for the patch and review.
>

(cc'ing Linus and danvet, as a headsup, there is also a phoronix
article where this was discovered).

Okay WTF.

This is in no way acceptable. This needs to be fixed in 5.19-rc ASAP.

Once hardware is released and we remove the gate flag by default, you
cannot just bump firmware versions blindly.

The kernel needs to retain compatibility with all released firmwares
since a device was declared supported.

This needs to be reverted, and then 70 should be introduced with a
fallback to 69 versions.

Very disappointing, I expect this to get dealt with v.quickly.

Dave.

Re: [PATCH v2 05/29] drm/nouveau: Don't register backlight when another backlight should be used

Reviewed-by: Lyude Paul 

You also have permission to push this to drm-misc-whatever

On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> Before this commit when we want userspace to use the acpi_video backlight
> device we register both the GPU's native backlight device and acpi_video's
> firmware acpi_video# backlight device. This relies on userspace preferring
> firmware type backlight devices over native ones.
> 
> Registering 2 backlight devices for a single display really is
> undesirable, don't register the GPU's native backlight device when
> another backlight device should be used.
> 
> Reviewed-by: Lyude Paul 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index a2141d3d9b1d..91c504c7b82c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -34,6 +34,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #include "nouveau_drv.h"
>  #include "nouveau_reg.h"
>  #include "nouveau_encoder.h"
> @@ -405,6 +407,11 @@ nouveau_backlight_init(struct drm_connector *connector)
> goto fail_alloc;
> }
>  
> +   if (!acpi_video_backlight_use_native()) {
> +   NV_INFO(drm, "Skipping nv_backlight registration\n");
> +   goto fail_alloc;
> +   }
> +
> if (!nouveau_get_backlight_name(backlight_name, bl)) {
> NV_ERROR(drm, "Failed to retrieve a unique name for the
> backlight interface\n");
> goto fail_alloc;

-- 
Cheers,
 Lyude Paul (she/her)
 Software Engineer at Red Hat

[PATCH RESEND v6] backlight: lp855x: Switch to atomic PWM API

2022-07-14 Thread Maíra Canal

Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
replace it for the atomic PWM API.

Reviewed-by: Uwe Kleine-König 
Reviewed-by: Daniel Thompson 
Signed-off-by: Maíra Canal 
---
V1 -> V2: Initialize variable and simplify conditional loop
V2 -> V3: Fix assignment of NULL variable
V3 -> V4: Replace division for pwm_set_relative_duty_cycle
V4 -> V5: Fix overwrite of state.period
V5 -> V6: Fix duty cycle rounding and set period outside conditional loop
---
 drivers/video/backlight/lp855x_bl.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/video/backlight/lp855x_bl.c 
b/drivers/video/backlight/lp855x_bl.c
index 2b9e203e..fc02c5c16055 100644
--- a/drivers/video/backlight/lp855x_bl.c
+++ b/drivers/video/backlight/lp855x_bl.c
@@ -218,9 +218,8 @@ static int lp855x_configure(struct lp855x *lp)
 
 static void lp855x_pwm_ctrl(struct lp855x *lp, int br, int max_br)
 {
-   unsigned int period = lp->pdata->period_ns;
-   unsigned int duty = br * period / max_br;
struct pwm_device *pwm;
+   struct pwm_state state;
 
/* request pwm device with the consumer name */
if (!lp->pwm) {
@@ -230,18 +229,16 @@ static void lp855x_pwm_ctrl(struct lp855x *lp, int br, 
int max_br)
 
lp->pwm = pwm;
 
-   /*
-* FIXME: pwm_apply_args() should be removed when switching to
-* the atomic PWM API.
-*/
-   pwm_apply_args(pwm);
+   pwm_init_state(lp->pwm, );
+   } else {
+   pwm_get_state(lp->pwm, );
}
 
-   pwm_config(lp->pwm, duty, period);
-   if (duty)
-   pwm_enable(lp->pwm);
-   else
-   pwm_disable(lp->pwm);
+   state.period = lp->pdata->period_ns;
+   state.duty_cycle = div_u64(br * state.period, max_br);
+   state.enabled = state.duty_cycle;
+
+   pwm_apply_state(lp->pwm, );
 }
 
 static int lp855x_bl_update_status(struct backlight_device *bl)
-- 
2.36.1

Re: [Freedreno] [PATCH v2.5] drm/msm/dsi: switch to DRM_PANEL_BRIDGE

2022-07-14 Thread Abhinav Kumar





On 7/12/2022 6:22 AM, Dmitry Baryshkov wrote:

Currently the DSI driver has two separate paths: one if the next device
in a chain is a bridge and another one if the panel is connected
directly to the DSI host. Simplify the code path by using panel-bridge
driver (already selected in Kconfig) and dropping support for
handling the panel directly.

Signed-off-by: Dmitry Baryshkov 
---

I'm not sending this as a separate patchset (I'd like to sort out mdp5
first), but more of a preview of changes related to
msm_dsi_manager_ext_bridge_init().

---
  drivers/gpu/drm/msm/dsi/dsi.c |  35 +---
  drivers/gpu/drm/msm/dsi/dsi.h |  16 +-
  drivers/gpu/drm/msm/dsi/dsi_host.c|  25 ---
  drivers/gpu/drm/msm/dsi/dsi_manager.c | 283 +++---
  4 files changed, 36 insertions(+), 323 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index 1625328fa430..4edb9167e600 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -6,14 +6,6 @@
  #include "dsi.h"
  #include "dsi_cfg.h"
  
-struct drm_encoder *msm_dsi_get_encoder(struct msm_dsi *msm_dsi)

-{
-   if (!msm_dsi || !msm_dsi_device_connected(msm_dsi))
-   return NULL;
-
-   return msm_dsi->encoder;
-}
-
  bool msm_dsi_is_cmd_mode(struct msm_dsi *msm_dsi)
  {
unsigned long host_flags = msm_dsi_host_get_mode_flags(msm_dsi->host);
@@ -220,7 +212,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
 struct drm_encoder *encoder)
  {
struct msm_drm_private *priv;
-   struct drm_bridge *ext_bridge;
int ret;
  
  	if (WARN_ON(!encoder) || WARN_ON(!msm_dsi) || WARN_ON(!dev))

@@ -254,26 +245,10 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}
  
-	/*

-* check if the dsi encoder output is connected to a panel or an
-* external bridge. We create a connector only if we're connected to a
-* drm_panel device. When we're connected to an external bridge, we
-* assume that the drm_bridge driver will create the connector itself.
-*/
-   ext_bridge = msm_dsi_host_get_bridge(msm_dsi->host);
-
-   if (ext_bridge)
-   msm_dsi->connector =
-   msm_dsi_manager_ext_bridge_init(msm_dsi->id);
-   else
-   msm_dsi->connector =
-   msm_dsi_manager_connector_init(msm_dsi->id);
-
-   if (IS_ERR(msm_dsi->connector)) {
-   ret = PTR_ERR(msm_dsi->connector);
+   ret = msm_dsi_manager_ext_bridge_init(msm_dsi->id);
+   if (ret) {
DRM_DEV_ERROR(dev->dev,
"failed to create dsi connector: %d\n", ret);
-   msm_dsi->connector = NULL;
goto fail;
}
  
@@ -287,12 +262,6 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct drm_device *dev,

msm_dsi->bridge = NULL;
}
  
-	/* don't destroy connector if we didn't make it */

-   if (msm_dsi->connector && !msm_dsi->external_bridge)
-   msm_dsi->connector->funcs->destroy(msm_dsi->connector);
-
-   msm_dsi->connector = NULL;


From what i can see all the usages of msm_dsi->connector are removed 
after this change. So can we drop that?



-
return ret;
  }
  
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h

index 580a1e6358bf..703e4c88d7fb 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -12,7 +12,6 @@
  #include 
  #include 
  #include 
-#include 
  
  #include "msm_drv.h"

  #include "disp/msm_disp_snapshot.h"
@@ -49,8 +48,6 @@ struct msm_dsi {
struct drm_device *dev;
struct platform_device *pdev;
  
-	/* connector managed by us when we're connected to a drm_panel */

-   struct drm_connector *connector;
/* internal dsi bridge attached to MDP interface */
struct drm_bridge *bridge;
  
@@ -58,10 +55,8 @@ struct msm_dsi {

struct msm_dsi_phy *phy;
  
  	/*

-* panel/external_bridge connected to dsi bridge output, only one of the
-* two can be valid at a time
+* external_bridge connected to dsi bridge output
 */
-   struct drm_panel *panel;
struct drm_bridge *external_bridge;
  
  	struct device *phy_dev;

@@ -76,8 +71,7 @@ struct msm_dsi {
  /* dsi manager */
  struct drm_bridge *msm_dsi_manager_bridge_init(u8 id);
  void msm_dsi_manager_bridge_destroy(struct drm_bridge *bridge);
-struct drm_connector *msm_dsi_manager_connector_init(u8 id);
-struct drm_connector *msm_dsi_manager_ext_bridge_init(u8 id);
+int msm_dsi_manager_ext_bridge_init(u8 id);
  int msm_dsi_manager_cmd_xfer(int id, const struct mipi_dsi_msg *msg);
  bool msm_dsi_manager_cmd_xfer_trigger(int id, u32 dma_base, u32 len);
  int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
@@ -87,11 +81,9 @@ void

[pull] amdgpu, amdkfd, radeon drm-next-5.20

Hi Dave, Daniel,

A few more new things for 5.20.

The following changes since commit c5da61cf5bab30059f22ea368702c445ee87171a:

  drm/amdgpu/display: add missing FP_START/END checks dcn32_clk_mgr.c 
(2022-06-30 19:35:21 -0400)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-next-5.20-2022-07-14

for you to fetch changes up to b7be3ae759160aa3355ebeb0583f67fb9bda4dae:

  drm/amd/display: remove duplicate dcn314 includes (2022-07-13 20:57:05 -0400)


amd-drm-next-5.20-2022-07-14:

amdgpu:
- DCN3.2 updates
- DC SubVP support
- DP MST fixes
- Audio fixes
- DC code cleanup
- SMU13 updates
- Adjust GART size on newer APUs for S/G display
- Soft reset for GFX 11
- Soft reset for SDMA 6
- Add gfxoff status query for vangogh
- Improve BO domain pinning
- Fix timestamps for cursor only commits
- MES fixes
- DCN 3.1.4 support
- Misc fixes
- Misc code cleanup

amdkfd:
- Simplify GPUVM validation
- Unified memory for CWSR save/restore area
- fix possible list corruption on queue failure

radeon:
- Fix bogus power of two warning

UAPI:
- Unified memory for CWSR save/restore area for KFD
  Proposed userspace: 
https://lists.freedesktop.org/archives/amd-gfx/2022-June/080952.html


Alan Liu (1):
  drm/amd/display: Program ACP related register

Alex Deucher (11):
  drm/amdgpu: keep fbdev buffers pinned during suspend
  drm/amdgpu/display: disable prefer_shadow for generic fb helpers
  drm/amd/display: remove set but unused variable
  drm/amd/display: make get_refresh_rate() static
  drm/amd/display: fix non-x86/PPC64 compilation
  drm/amd/display: fix 32 bit compilation errors in dc_dmub_srv.c
  drm/amdgpu/gmc10: adjust gart size for parts that support S/G display
  drm/amdgpu: fix file permissions on some files
  drm/amd/display: make some dc_dmub_srv functions static
  drm/amd/display: attempt to fix the logic in commit_planes_for_stream()
  drm/amd/display: remove duplicate dcn314 includes

Alvin Lee (6):
  drm/amd/display: Add SubVP required code
  drm/amd/display: Change DET policy for MPO cases
  drm/amd/display: Make OPTC3 function accessible to other DCN
  drm/amd/display: Don't set dram clock change requirement for SubVP
  drm/amd/display: Maintain old audio programming sequence
  drm/amd/display: Exit SubVP if MPO in use

André Almeida (2):
  drm/amdpgu/debugfs: Simplify some exit paths
  drm/amd/pm: Implement get GFXOFF status for vangogh

Aric Cyr (3):
  drm/amd/display: 3.2.192
  drm/amd/display: 3.2.193
  drm/amd/display: 3.2.194

Aurabindo Pillai (5):
  drm/amd: Add debug mask for subviewport mclk switch
  drm/amd/display: remove stale debug setting
  drm/amd/display: Add callback to set dig mode
  drm/amd/display: Enable ODM combine default policy
  drm/amd/display: Add NBIO reg offsets to DC

Charlene Liu (1):
  drm/amd/display: add system info table log

Chris Park (4):
  drm/amd/display: Switch to correct DTO on HDMI
  drm/amd/display: Indicate stream change on ODM change
  drm/amd/display: OVT Update on InfoFrame and Mode Management
  drm/amd/display: Reduce SCDC Status Flags Definition

Dmytro Laktyushkin (2):
  drm/amd/display: disable timing sync b/w odm halves
  drm/amd/display: disable otg toggle w/a on boot

Duncan Ma (1):
  drm/amd/display: Add flag to modify MST delay

Eric Bernstein (3):
  drm/amd/display: Add function to set pixels per cycle
  drm/amd/display: Update gpuvm_max_page_table_levels IP param
  drm/amd/display: Fix null timing generator resource

Eric Huang (4):
  drm/amdkfd: add new flag for svm
  drm/amdkfd: change svm range evict
  drm/amdkfd: optimize svm range evict
  drm/amdkfd: bump KFD version for unified ctx save/restore memory

Ethan Wellenreiter (1):
  drm/amd/display: Re-implementing ARGB16161616 pixel format as 22

Evan Quan (2):
  drm/amd/pm: update SMU 13.0.0 driver_if header
  drm/amd/display: correct idle_power_optimizations disablement return value

Evgenii Krasnikov (1):
  drm/amd/display: add an option to skip wait for HPD when powering on eDP 
panel

Fangzhi Zuo (2):
  drm/amd/display: Fix dmub soft hang for PSR 1
  drm/amd/display: Ignore First MST Sideband Message Return Error

Guo Zhengkui (1):
  drm/amd/display: remove repeated includes

Hamza Mahfooz (2):
  drm/amd/display: enable PCON SST support for newer ASICs
  drm/amd/display: rename hdmi_frl_pcon_support

Harry Wentland (2):
  drm/amd/display: Move all linux includes into OS types
  drm/amd/display: Add DCN reg offsets to DC

Ilya Bakoulin (1):
  drm/amd/display: Fix black screen when disabling Freesync in OSD

Jack Xiao (7):
  drm/amdgpu/mes11: fix to unmap legacy queue
  drm/amdgpu/mes: fix

Re: [PATCH v1] drm/scheduler: Don't kill jobs in interrupt context

On Thu, Jul 14, 2022 at 1:58 PM Andrey Grodzovsky
 wrote:
>
> On 2022-07-14 12:22, Alex Deucher wrote:
>
> > On Thu, Jul 14, 2022 at 10:14 AM Andrey Grodzovsky
> >  wrote:
> >>
> >> On 2022-07-14 05:57, Dmitry Osipenko wrote:
> >>> On 7/12/22 11:56, Dmitry Osipenko wrote:
>  On 7/6/22 18:46, Alex Deucher wrote:
> > On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
> >  wrote:
> >> On 2022-07-06 03:07, Dmitry Osipenko wrote:
> >>
> >>> Hello Andrey,
> >>>
> >>> On 5/17/22 17:48, Dmitry Osipenko wrote:
>  On 5/17/22 17:13, Andrey Grodzovsky wrote:
> > Done.
> >
> > Andrey
>  Awesome, thank you!
> 
> >>> Given that this drm-scheduler issue needs to be fixed in the 5.19-RC 
> >>> and
> >>> earlier, shouldn't it be in the drm-fixes and not in drm-next?
> >> I pushed it into drm-misc from where it got into drm-next. I don't have
> >> permission for drm-fixes.
> > The -fixes branch of drm-misc.
>  Now I don't see the scheduler bugfix neither in the -fixes branch nor in
>  the -next and today Dave sent out 5.19-rc7 pull request without the
>  scheduler fix. Could anyone please check what is going on with the DRM
>  patches? Thanks!
> 
>  https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffreedesktop%2Fdrm-misc%2Fcommits%2Fdrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7Cd62c2e6d3ec748cd639608da65b52548%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637934125954377887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=WPmMC%2B%2Fy83cUctuF%2FLNo9VhWnB%2FkpUVQotMh74VshB8%3Dreserved=0
>  https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Flog%2F%3Fh%3Ddrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7Cd62c2e6d3ec748cd639608da65b52548%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637934125954377887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=RzCMLUYLmUjSmvDm4E%2FJr%2B5rp7E8UvjFt1tmwBoBiVc%3Dreserved=0
> >>> The patch is in the drm-misc-next-fixes, so it wasn't moved to the
> >>> drm-misc-fixes.
> >>>
> >>> Andrey, don't you have access to drm-misc-fixes? Or you meant
> >>> drm-fixes=drm-misc-fixes?
> >>
> >> I have only accesses to drm-misc-next to which I pushed this patch.
> > anyone with drm-misc rights can commit to any of the branches in the
> > drm-misc tree.  You just need to check out and push the appropriate
> > branch.  then push the changes.  E.g.,
> > dim push-branch drm-misc-next
> > vs
> > dim push-branch drm-misc-next-fixes
> > etc.
> >
> > Alex
>
>
> I see, but what  is the reason then that Dave sent out 5.19-rc7 pull
> request without the
> scheduler fix if the patch was merged into drm-misc-next long ago ? All
> the changes from
> there are usually picked up for pull requests, no ?

drm-misc-next is for new stuff for the next kernel (e.g., 5.20).
drm-misc-fixes is for fixes for the current kernel cycle (e.g., 5.19).
See:
https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html

Alex

>
> Andrey
>
>
> >
> >
> >> Andrey
> >>
> >>

Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds


On 7/14/22 11:49, Melissa Wen wrote:

O 07/13, Alex Deucher wrote:

On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck  wrote:


On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:


The problem is not the FPU operations, but the fact that soft-float
and hard-float compiled code is linked together. The soft-float and
hard-float ABIs on powerpc are not compatible, so one ends up with
an object file which is partially soft-float and partially hard-float
compiled and thus uses different ABIs. That can only create chaos,
so the linker complains about it.


I get that, I just don't see why only DCN 3.1.x files have this
problem.  The DCN 2.x files should as well.



Seen in drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile:

# prevent build errors regarding soft-float vs hard-float FP ABI tags
# this code is currently unused on ppc64, as it applies to Renoir APUs only
ifdef CONFIG_PPC64
CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call 
cc-option,-mno-gnu-attribute)
endif

Does that explain it ?


I would expect to see it in dcn20_resource.c and dcn30_clk_mgr.c for
example.  They follow the same pattern as the dcn 3.1.x files.  They
call functions that use FP, but maybe there is some FP code still in
those functions that we missed somehow.


Hi,

I'm a little late here, but I'm not able to reproduce the issue yet.
I have this setup:
- gcc 11.3.0
- binutils 2.38.50
- mainline kernel (torvalds) version: 5.19.0-rc6 (cross-compiling)
   -> make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- allmodconfig
 => DRM_AMD_DC [=y] && HAS_IOMEM [=y] && DRM [=m] && DRM_AMDGPU [=m] && (X86 || 
PPC64 [=y]) && (!KCOV_INSTRUMENT_ALL [=n] || !KCOV_ENABLE_COMPARISONS [=n])
   -> make -j16 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-

Am I missing something?

So, as Alex mentioned the possibility of some non-isolated FPU code in
3.1, I reviewed dcn31 code and my best bet so far is that the issue
is here:

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c#L1721

Although dcn31_update_soc_for_wm_a() is only called inside
dml/dcn31/dcn31_fpu:
- dc->res_pool->funcs->update_soc_for_wm_a(dc, context);

it's declared in dcn31_resource and has FPU code. So, we should move it
to dml/dcn31/dcn31_fpu.

However, as I can't reproduce the issue, I don't know if it addresses
the problem reported here and also if everything will be clean after
moving it.



I don't think that would solve anything. As I have tried to point out,
the problem is that code compiled with hard-float is linked together
with code compiled with soft-float. An alternate fix might be something
like the one attached below, but I don't know if that would be correct
and/or complete.


Guenter,

Can you provide more info about your setup: cross-compile or not, any
flags, branch, etc?



Nothing special. Same compile options as the ones you use, and it is a
cross-compile environment. I tried gcc 11.2.0 with binutils 2.36.1
and gcc 11.3.0 with binutils 2.38.

Guenter

---
diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
index ec041e3cda30..44ff6f196860 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
@@ -10,6 +10,8 @@
 #
 # Makefile for dcn31.

+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := $(call 
cc-option,-mno-gnu-attribute)
+
 DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o dcn31_init.o 
dcn31_hubp.o \
dcn31_dccg.o dcn31_optc.o dcn31_dio_link_encoder.o dcn31_panel_cntl.o \
dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o \
diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
index 59381d24800b..55fcae2d2aae 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
@@ -25,6 +25,8 @@

 DCN315 = dcn315_resource.o

+CFLAGS_$(AMDDALPATH)/dc/dcn315/$(DCN315) := $(call 
cc-option,-mno-gnu-attribute)
+
 AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))

 AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
index 819d44a9439b..7251ef9c1afb 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
@@ -25,6 +25,8 @@

 DCN316 = dcn316_resource.o

+CFLAGS_$(AMDDALPATH)/dc/dcn316/$(DCN316) := $(call 
cc-option,-mno-gnu-attribute)
+
 AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))

 AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)

Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks

2022-07-14 Thread Hans de Goede

Hi,

On 7/13/22 19:21, Limonciello, Mario wrote:
> [Public]
> 
> 
> 
>> -Original Message-
>> From: Werner Sembach 
>> Sent: Wednesday, July 13, 2022 12:08
>> To: Hans de Goede ; Ben Skeggs
>> ; Karol Herbst ; Lyude
>> ; Daniel Dadap ; Maarten
>> Lankhorst ; Maxime Ripard
>> ; Thomas Zimmermann ;
>> Jani Nikula ; Joonas Lahtinen
>> ; Rodrigo Vivi ;
>> Tvrtko Ursulin ; Deucher, Alexander
>> ; Koenig, Christian
>> ; p...@vger.kernel.org; Pan, Xinhui
>> ; Rafael J . Wysocki ; Mika
>> Westerberg ; Lukas Wunner
>> ; Mark Gross ; Andy
>> Shevchenko 
>> Cc: nouv...@lists.freedesktop.org; Daniel Vetter ; David
>> Airlie ; intel-gfx ; dri-
>> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Len Brown
>> ; linux-a...@vger.kernel.org; platform-driver-
>> x...@vger.kernel.org
>> Subject: Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and
>> NL5xNU acpi_backlight=native quirks
>>
>> Hi,
>>
>> On 7/12/22 21:39, Hans de Goede wrote:
>>> acpi_backlight=native is the default for these, but as the comment
>>> explains the quirk was still necessary because even briefly registering
>>> the acpi_video0 backlight; and then unregistering it once the native
>>> driver showed up, was leading to issues.
>>>
>>> After the "ACPI: video: Make backlight class device registration
>>> a separate step" patch from earlier in this patch-series, we no
>>> longer briefly register the acpi_video0 backlight on systems where
>>> the native driver should be used.
>>>
>>> So this is no longer an issue an the quirks are no longer needed.
>>>
>>> Cc: Werner Sembach 
>>> Signed-off-by: Hans de Goede 
>>
>> Tested and can confirm: The quirks are no longer needed with this Patchset.
>>
>> Tested-by: Werner Sembach 
> 
> Probably should include this link tag in this commit too then as it fixes
> the Tong Fang systems too.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683

Good point, I've added this to the version in my personal tree.

Regards,

Hans




> 
>>
>> Kind Regards,
>>
>> Werner Sembach
>>
>>> ---
>>>   drivers/acpi/video_detect.c | 75 -
>>>   1 file changed, 75 deletions(-)
>>>
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index 2a4d376a703e..4b9395d1bda7 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -599,81 +599,6 @@ static const struct dmi_system_id
>> video_detect_dmi_table[] = {
>>> DMI_MATCH(DMI_BOARD_NAME, "N250P"),
>>> },
>>> },
>>> -   /*
>>> -* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have
>> both a
>>> -* working native and video interface. However the default detection
>>> -* mechanism first registers the video interface before unregistering
>>> -* it again and switching to the native interface during boot. This
>>> -* results in a dangling SBIOS request for backlight change for some
>>> -* reason, causing the backlight to switch to ~2% once per boot on
>> the
>>> -* first power cord connect or disconnect event. Setting the native
>>> -* interface explicitly circumvents this buggy behaviour, by avoiding
>>> -* the unregistering process.
>>> -*/
>>> -   {
>>> -   .callback = video_detect_force_native,
>>> -   .ident = "Clevo NL5xRU",
>>> -   .matches = {
>>> -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
>>> -   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
>>> -   },
>>> -   },
>>> -   {
>>> -   .callback = video_detect_force_native,
>>> -   .ident = "Clevo NL5xRU",
>>> -   .matches = {
>>> -   DMI_MATCH(DMI_SYS_VENDOR,
>> "SchenkerTechnologiesGmbH"),
>>> -   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
>>> -   },
>>> -   },
>>> -   {
>>> -   .callback = video_detect_force_native,
>>> -   .ident = "Clevo NL5xRU",
>>> -   .matches = {
>>> -   DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
>>> -   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
>>> -   },
>>> -   },
>>> -   {
>>> -   .callback = video_detect_force_native,
>>> -   .ident = "Clevo NL5xRU",
>>> -   .matches = {
>>> -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
>>> -   DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
>>> -   },
>>> -   },
>>> -   {
>>> -   .callback = video_detect_force_native,
>>> -   .ident = "Clevo NL5xRU",
>>> -   .matches = {
>>> -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
>>> -   DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
>>> -   },
>>> -   },
>>> -   {
>>> -   .callback = video_detect_force_native,
>>> -   .ident = "Clevo NL5xNU",
>>> -   .matches = {
>>> -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
>>> -   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
>>> -   },
>>> -   },
>>> -   {
>>> -   .callback = video_detect_force_native,
>>> -   .ident = "Clevo NL5xNU",
>>> -   .matches = {
>>> -   DMI_MATCH(DMI_SYS_VENDOR,
>> "SchenkerTechnologiesGmbH"),
>>> -   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
>>> -   },
>>> -   },
>>> -

[PATCH v2 2/2] Documentation/gpu: Add GFXOFF section

Add a GFXOFF section at "GPU Power Controls" file, explaining what it is
and how userspace can interact with it.

Signed-off-by: André Almeida 
---
Changes from v1: file created

 Documentation/gpu/amdgpu/thermal.rst | 41 
 1 file changed, 41 insertions(+)

diff --git a/Documentation/gpu/amdgpu/thermal.rst 
b/Documentation/gpu/amdgpu/thermal.rst
index 8aeb0186c9ef..14c0fb874cf6 100644
--- a/Documentation/gpu/amdgpu/thermal.rst
+++ b/Documentation/gpu/amdgpu/thermal.rst
@@ -63,3 +63,44 @@ gpu_metrics
 
 .. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c
:doc: gpu_metrics
+
+GFXOFF
+==
+
+GFXOFF is a feature found in some mobile GPUs that saves power consumption. The
+card's firmware uses RLC (RunList Controller) to power off the gfx engine
+dynamically when there is no workload on gfx pipe and puts gfx into "idle"
+state. GFXOFF is on by default on supported GPUs.
+
+Userspace can interact with GFXOFF through a debugfs interface:
+
+``amdgpu_gfxoff``
+-
+
+Use it to enable/disable GFXOFF, and to check if it's current 
enabled/disabled::
+
+  $ xxd -l1 -p /sys/kernel/debug/dri/0/amdgpu_gfxoff
+  01
+
+- Write 0 to disable it, and 1 to enable it.
+- Read 0 means it's disabled, 1 it's enabled.
+
+If it's enabled, that means that the GPU is free to enter into GFXOFF mode as
+needed. Disabled means that it will never enter GFXOFF mode.
+
+``amdgpu_gfxoff_status``
+
+
+Read it to check current GFXOFF's status of a GPU::
+
+  $ xxd -l1 -p /sys/kernel/debug/dri/0/amdgpu_gfxoff_status
+  02
+
+- 0: GPU is in GFXOFF state, the gfx engine is powered down.
+- 1: Transition out of GFXOFF state
+- 2: Not in GFXOFF state
+- 3: Transition into GFXOFF state
+
+If GFXOFF is enabled, the value will be transitioning around [0, 3], always
+getting into 0 when possible. When it's disabled, it's always at 2. Returns
+``-EINVAL`` if it's not supported.
-- 
2.37.0

[PATCH v2 1/2] drm/amd/debugfs: Expose GFXOFF state to userspace

GFXOFF has two different "state" values: one to define if the GPU is
allowed/disallowed to enter GFXOFF, usually called state; and another
one to define if currently GFXOFF is being used, usually called status.
Even when GFXOFF is allowed, GPU firmware can decide to not used it
accordingly to the GPU load.

Userspace can allow/disallow GPUs to enter into GFXOFF via debugfs. The
kernel maintains a counter of requests for GFXOFF (gfx_off_req_count)
that should be decreased to allow GFXOFF and increased to disallow.

The issue with this interface is that userspace can't be sure if GFXOFF
is currently allowed. Even by checking amdgpu_gfxoff file, one might get
an ambiguous 2, that means that GPU is currently out of GFXOFF, but that
can be either because it's currently disallowed or because it's allowed
but given the current GPU load it's enabled. Then, userspace needs to
rely on the fact that GFXOFF is enabled by default on boot and to track
this information.

To make userspace life easier and GFXOFF more reliable, return the
current state of GFXOFF to userspace when reading amdgpu_gfxoff with the
same semantics of writing: 0 means not allowed, not 0 means allowed.

Expose the current status of GFXOFF through a new file,
amdgpu_gfxoff_status.

Signed-off-by: André Almeida 
---
Changes from v1: none

 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 49 -
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f3b3c688e4e7..e2eec985adb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1117,13 +1117,50 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct file 
*f, char __user *buf,
}
 
while (size) {
-   uint32_t value;
+   u32 value = adev->gfx.gfx_off_state;
+
+   r = put_user(value, (u32 *)buf);
+   if (r)
+   goto out;
+
+   result += 4;
+   buf += 4;
+   *pos += 4;
+   size -= 4;
+   }
+
+   r = result;
+out:
+   pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
+   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+
+   return r;
+}
+
+static ssize_t amdgpu_debugfs_gfxoff_status_read(struct file *f, char __user 
*buf,
+size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   ssize_t result = 0;
+   int r;
+
+   if (size & 0x3 || *pos & 0x3)
+   return -EINVAL;
+
+   r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
+   if (r < 0) {
+   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+   return r;
+   }
+
+   while (size) {
+   u32 value;
 
r = amdgpu_get_gfx_off_status(adev, );
if (r)
goto out;
 
-   r = put_user(value, (uint32_t *)buf);
+   r = put_user(value, (u32 *)buf);
if (r)
goto out;
 
@@ -1206,6 +1243,12 @@ static const struct file_operations 
amdgpu_debugfs_gfxoff_fops = {
.llseek = default_llseek
 };
 
+static const struct file_operations amdgpu_debugfs_gfxoff_status_fops = {
+   .owner = THIS_MODULE,
+   .read = amdgpu_debugfs_gfxoff_status_read,
+   .llseek = default_llseek
+};
+
 static const struct file_operations *debugfs_regs[] = {
_debugfs_regs_fops,
_debugfs_regs2_fops,
@@ -1217,6 +1260,7 @@ static const struct file_operations *debugfs_regs[] = {
_debugfs_wave_fops,
_debugfs_gpr_fops,
_debugfs_gfxoff_fops,
+   _debugfs_gfxoff_status_fops,
 };
 
 static const char *debugfs_regs_names[] = {
@@ -1230,6 +1274,7 @@ static const char *debugfs_regs_names[] = {
"amdgpu_wave",
"amdgpu_gpr",
"amdgpu_gfxoff",
+   "amdgpu_gfxoff_status",
 };
 
 /**
-- 
2.37.0

Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

2022-07-14 Thread Melissa Wen

O 07/13, Alex Deucher wrote:
> On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck  wrote:
> >
> > On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:
> > > >
> > > > The problem is not the FPU operations, but the fact that soft-float
> > > > and hard-float compiled code is linked together. The soft-float and
> > > > hard-float ABIs on powerpc are not compatible, so one ends up with
> > > > an object file which is partially soft-float and partially hard-float
> > > > compiled and thus uses different ABIs. That can only create chaos,
> > > > so the linker complains about it.
> > >
> > > I get that, I just don't see why only DCN 3.1.x files have this
> > > problem.  The DCN 2.x files should as well.
> > >
> >
> > Seen in drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile:
> >
> > # prevent build errors regarding soft-float vs hard-float FP ABI tags
> > # this code is currently unused on ppc64, as it applies to Renoir APUs only
> > ifdef CONFIG_PPC64
> > CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call 
> > cc-option,-mno-gnu-attribute)
> > endif
> >
> > Does that explain it ?
> 
> I would expect to see it in dcn20_resource.c and dcn30_clk_mgr.c for
> example.  They follow the same pattern as the dcn 3.1.x files.  They
> call functions that use FP, but maybe there is some FP code still in
> those functions that we missed somehow.

Hi,

I'm a little late here, but I'm not able to reproduce the issue yet.
I have this setup:
- gcc 11.3.0
- binutils 2.38.50
- mainline kernel (torvalds) version: 5.19.0-rc6 (cross-compiling)
  -> make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- allmodconfig
=> DRM_AMD_DC [=y] && HAS_IOMEM [=y] && DRM [=m] && DRM_AMDGPU [=m] && (X86 
|| PPC64 [=y]) && (!KCOV_INSTRUMENT_ALL [=n] || !KCOV_ENABLE_COMPARISONS [=n])
  -> make -j16 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-

Am I missing something?

So, as Alex mentioned the possibility of some non-isolated FPU code in
3.1, I reviewed dcn31 code and my best bet so far is that the issue
is here:

https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c#L1721

Although dcn31_update_soc_for_wm_a() is only called inside
dml/dcn31/dcn31_fpu:
- dc->res_pool->funcs->update_soc_for_wm_a(dc, context);

it's declared in dcn31_resource and has FPU code. So, we should move it
to dml/dcn31/dcn31_fpu.

However, as I can't reproduce the issue, I don't know if it addresses
the problem reported here and also if everything will be clean after
moving it. 

Guenter,

Can you provide more info about your setup: cross-compile or not, any
flags, branch, etc?

Best Regards,

Melissa

> 
> Alex


signature.asc
Description: PGP signature

Re: [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

2022-07-14 Thread Rafael J. Wysocki

On Tue, Jul 12, 2022 at 9:39 PM Hans de Goede  wrote:
>
> Hi All,
>
> As mentioned in my RFC titled "drm/kms: control display brightness through
> drm_connector properties":
> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/
>
> The first step towards this is to deal with some existing technical debt
> in backlight handling on x86/ACPI boards, specifically we need to stop
> registering multiple /sys/class/backlight devs for a single display.
>
> This series implements my RFC describing my plan for these cleanups:
> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343...@redhat.com/
>
> This new version addresses the few small remarks made on version 1 (mainly
> changing patch 1/29) and more importantly this finishes the refactoring by
> else addressing all the bits from the "Other issues" section of
> the refactor RFC (resulting in patches 15-29 which are new in v2).
>
> Please review and test! I hope to be able to make an immutable branch
> based on 5.20-rc1 + this series available for merging into the various
> touched subsystems once 5.20-rc2 is out.

Please feel free to add

Acked-by: Rafael J. Wysocki 

to all of the ACPI video patches in this series.

Thanks!

> Hans de Goede (29):
>   ACPI: video: Add acpi_video_backlight_use_native() helper
>   drm/i915: Don't register backlight when another backlight should be
> used
>   drm/amdgpu: Don't register backlight when another backlight should be
> used
>   drm/radeon: Don't register backlight when another backlight should be
> used
>   drm/nouveau: Don't register backlight when another backlight should be
> used
>   ACPI: video: Drop backlight_device_get_by_type() call from
> acpi_video_get_backlight_type()
>   ACPI: video: Remove acpi_video_bus from list before tearing it down
>   ACPI: video: Simplify acpi_video_unregister_backlight()
>   ACPI: video: Make backlight class device registration a separate step
>   ACPI: video: Remove code to unregister acpi_video backlight when a
> native backlight registers
>   drm/i915: Call acpi_video_register_backlight() (v2)
>   drm/nouveau: Register ACPI video backlight when nv_backlight
> registration fails
>   drm/amdgpu: Register ACPI video backlight when skipping amdgpu
> backlight registration
>   drm/radeon: Register ACPI video backlight when skipping radeon
> backlight registration
>   ACPI: video: Refactor acpi_video_get_backlight_type() a bit
>   ACPI: video: Add Nvidia WMI EC brightness control detection
>   ACPI: video: Add Apple GMUX brightness control detection
>   platform/x86: apple-gmux: Stop calling acpi/video.h functions
>   platform/x86: toshiba_acpi: Stop using
> acpi_video_set_dmi_backlight_type()
>   platform/x86: acer-wmi: Move backlight DMI quirks to
> acpi/video_detect.c
>   platform/x86: asus-wmi: Drop DMI chassis-type check from backlight
> handling
>   platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI
> video_detect.c
>   platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI
> video_detect.c
>   platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native]
> quirks to ACPI video_detect.c
>   ACPI: video: Remove acpi_video_set_dmi_backlight_type()
>   ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
>   ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native
> quirks
>   ACPI: video: Fix indentation of video_detect_dmi_table[] entries
>   drm/todo: Add entry about dealing with brightness control on devices
> with > 1 panel
>
>  Documentation/gpu/todo.rst|  68 +++
>  drivers/acpi/Kconfig  |   1 +
>  drivers/acpi/acpi_video.c |  59 ++-
>  drivers/acpi/video_detect.c   | 415 +++---
>  drivers/gpu/drm/Kconfig   |  12 +
>  .../gpu/drm/amd/amdgpu/atombios_encoders.c|  14 +-
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |   9 +
>  drivers/gpu/drm/gma500/Kconfig|   2 +
>  drivers/gpu/drm/i915/Kconfig  |   2 +
>  .../gpu/drm/i915/display/intel_backlight.c|   7 +
>  drivers/gpu/drm/i915/display/intel_display.c  |   8 +
>  drivers/gpu/drm/i915/display/intel_panel.c|   3 +
>  drivers/gpu/drm/i915/i915_drv.h   |   2 +
>  drivers/gpu/drm/nouveau/nouveau_backlight.c   |  14 +
>  drivers/gpu/drm/radeon/atombios_encoders.c|   7 +
>  drivers/gpu/drm/radeon/radeon_encoders.c  |  11 +-
>  .../gpu/drm/radeon/radeon_legacy_encoders.c   |   7 +
>  drivers/platform/x86/acer-wmi.c   |  66 ---
>  drivers/platform/x86/apple-gmux.c |   3 -
>  drivers/platform/x86/asus-nb-wmi.c|  21 -
>  drivers/platform/x86/asus-wmi.c   |  13 -
>  drivers/platform/x86/asus-wmi.h   |   2 -
>  drivers/platform/x86/eeepc-wmi.c  |  25 +-
>  drivers/platform/x86/samsung-laptop.c |  87 
>

Re: [PATCH 01/10] drm/sched: move calling drm_sched_entity_select_rq

2022-07-14 Thread Andrey Grodzovsky


Found the new use case from the 5/10 of reordering CS ioctl.

Reviewed-by: Andrey Grodzovsky 

Andrey

On 2022-07-14 12:26, Christian König wrote:

We need this for limiting codecs like AV1 to the first instance for VCN3.

Essentially the idea is that we first initialize the job with entity, 
id etc... and before we submit it we select a new rq for the entity. 
In the meantime the VCN3 inline parse will have modified the available 
rqs for the entity.


See the patch "revert "fix limiting AV1 to the first instance on 
VCN3"" as well.


Christian.

Am 14.07.22 um 17:43 schrieb Andrey Grodzovsky:
Can you please remind me of the use case that requires this ? I 
browsed through
related mails in the past but haven't found when is that needed. For 
amdgpu

drm_sched_job_init and drm_sched_job_arm are called together and amdgpu
is the only one who supports modifying entity priority on the fly as 
far as i see.


Andrey

On 2022-07-14 06:38, Christian König wrote:
We already discussed that the call to drm_sched_entity_select_rq() 
needs

to move to drm_sched_job_arm() to be able to set a new scheduler list
between _init() and _arm(). This was just not applied for some reason.

Signed-off-by: Christian König 
CC: Andrey Grodzovsky 
CC: dri-devel@lists.freedesktop.org
---
  drivers/gpu/drm/scheduler/sched_main.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c

index 68317d3a7a27..e0ab14e0fb6b 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -592,7 +592,6 @@ int drm_sched_job_init(struct drm_sched_job *job,
 struct drm_sched_entity *entity,
 void *owner)
  {
-    drm_sched_entity_select_rq(entity);
  if (!entity->rq)
  return -ENOENT;
  @@ -628,7 +627,7 @@ void drm_sched_job_arm(struct drm_sched_job *job)
  struct drm_sched_entity *entity = job->entity;
    BUG_ON(!entity);
-
+    drm_sched_entity_select_rq(entity);
  sched = entity->rq->sched;
    job->sched = sched;

Re: [PATCH v1] drm/scheduler: Don't kill jobs in interrupt context

2022-07-14 Thread Andrey Grodzovsky

On 2022-07-14 12:22, Alex Deucher wrote:

On Thu, Jul 14, 2022 at 10:14 AM Andrey Grodzovsky
wrote:

On 2022-07-14 05:57, Dmitry Osipenko wrote:

On 7/12/22 11:56, Dmitry Osipenko wrote:

On 7/6/22 18:46, Alex Deucher wrote:

On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
wrote:

On 2022-07-06 03:07, Dmitry Osipenko wrote:

Hello Andrey,

On 5/17/22 17:48, Dmitry Osipenko wrote:

On 5/17/22 17:13, Andrey Grodzovsky wrote:

Done.

Andrey

Awesome, thank you!

Given that this drm-scheduler issue needs to be fixed in the 5.19-RC and
earlier, shouldn't it be in the drm-fixes and not in drm-next?

I pushed it into drm-misc from where it got into drm-next. I don't have
permission for drm-fixes.

The -fixes branch of drm-misc.

Now I don't see the scheduler bugfix neither in the -fixes branch nor in
the -next and today Dave sent out 5.19-rc7 pull request without the
scheduler fix. Could anyone please check what is going on with the DRM
patches? Thanks!

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffreedesktop%2Fdrm-misc%2Fcommits%2Fdrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7Cd62c2e6d3ec748cd639608da65b52548%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637934125954377887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=WPmMC%2B%2Fy83cUctuF%2FLNo9VhWnB%2FkpUVQotMh74VshB8%3Dreserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Flog%2F%3Fh%3Ddrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7Cd62c2e6d3ec748cd639608da65b52548%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637934125954377887%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=RzCMLUYLmUjSmvDm4E%2FJr%2B5rp7E8UvjFt1tmwBoBiVc%3Dreserved=0

The patch is in the drm-misc-next-fixes, so it wasn't moved to the
drm-misc-fixes.

Andrey, don't you have access to drm-misc-fixes? Or you meant
drm-fixes=drm-misc-fixes?

I have only accesses to drm-misc-next to which I pushed this patch.

anyone with drm-misc rights can commit to any of the branches in the
drm-misc tree. You just need to check out and push the appropriate
branch. then push the changes. E.g.,
dim push-branch drm-misc-next
vs
dim push-branch drm-misc-next-fixes
etc.

Alex

I see, but what is the reason then that Dave sent out 5.19-rc7 pull
request without the
scheduler fix if the patch was merged into drm-misc-next long ago ? All
the changes from

there are usually picked up for pull requests, no ?

Andrey

[Bug 216120] [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu

2022-07-14 Thread bugzilla-daemon

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

--- Comment #6 from mat2003...@gmail.com ---
not quite there yet, after some hours of working with latest
linus+0001-drm-amdgpu-Fix-for-drm-buddy-memory-corruption.patch (latest commit
"vf/remap: return the amount of bytes actually deduplicated") display stopped
working, keyboard was working so I could reboot blindly. Part of journal
attached in comment 5. Maybe different bug.

I could perhaps bisect adding the patch to relevant steps but now I have had
too many gin and seem to be talking to myself anyway.

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

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

[PATCH v2 0/2] Miscellaneous runtime PM fixes for Nouveau

Noticed these minor issues while trying to investigate

https://bugzilla.redhat.com/show_bug.cgi?id=2086470

While unfortunately I've been unable to confirm whether these patches
fix the specific problem in question, they're likely fixes we want to
pull in regardless.

Lyude Paul (2):
  drm/nouveau/acpi: Don't print error when we get -EINPROGRESS from
pm_runtime
  drm/nouveau: Don't pm_runtime_put_sync(), only
pm_runtime_put_autosuspend()

 drivers/gpu/drm/nouveau/nouveau_display.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

-- 
2.35.3

[PATCH v2 2/2] drm/nouveau: Don't pm_runtime_put_sync(), only pm_runtime_put_autosuspend()

While trying to fix another issue, it occurred to me that I don't actually
think there is any situation where we want pm_runtime_put() in nouveau to
be synchronous. In fact, this kind of just seems like it would cause
issues where we may unexpectedly block a thread we don't expect to be
blocked.

So, let's only use pm_runtime_put_autosuspend().

Changes since v1:
* Use pm_runtime_put_autosuspend(), not pm_runtime_put()

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_fbcon.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 9f5a45f24e5be..a2f5df568ca54 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -515,7 +515,7 @@ nouveau_display_hpd_work(struct work_struct *work)
 
pm_runtime_mark_last_busy(drm->dev->dev);
 noop:
-   pm_runtime_put_sync(drm->dev->dev);
+   pm_runtime_put_autosuspend(dev->dev);
 }
 
 #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 5226323e55d34..3c7e0c9d6baf1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -467,7 +467,7 @@ nouveau_fbcon_set_suspend_work(struct work_struct *work)
if (state == FBINFO_STATE_RUNNING) {
nouveau_fbcon_hotplug_resume(drm->fbcon);
pm_runtime_mark_last_busy(drm->dev->dev);
-   pm_runtime_put_sync(drm->dev->dev);
+   pm_runtime_put_autosuspend(drm->dev->dev);
}
 }
 
-- 
2.35.3

[PATCH v2 1/2] drm/nouveau/acpi: Don't print error when we get -EINPROGRESS from pm_runtime

Since this isn't actually a failure.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index 2cd0932b3d687..9f5a45f24e5be 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -537,7 +537,7 @@ nouveau_display_acpi_ntfy(struct notifier_block *nb, 
unsigned long val,
 * it's own hotplug events.
 */
pm_runtime_put_autosuspend(drm->dev->dev);
-   } else if (ret == 0) {
+   } else if (ret == 0 || ret == -EINPROGRESS) {
/* We've started resuming the GPU already, so
 * it will handle scheduling a full reprobe
 * itself
-- 
2.35.3

[Bug 216120] [BISECTED][REGRESSION] drm/amdgpu: add drm buddy support to amdgpu

2022-07-14 Thread bugzilla-daemon

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

--- Comment #5 from mat2003...@gmail.com ---
Created attachment 301427
  --> https://bugzilla.kernel.org/attachment.cgi?id=301427=edit
journal 2022-07-14

-- 
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] drm/amd/display: Enable building new display engine with KCOV enabled


On 7/14/22 09:29, Alex Deucher wrote:

Applied.  Thanks!

On Wed, Jul 13, 2022 at 4:03 PM Harry Wentland  wrote:


On 2022-07-12 18:42, Guenter Roeck wrote:

The new display engine uses floating point math, which is not supported
by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
is enabled") tried to work around the problem by disabling
CONFIG_DRM_AMD_DC_DCN if KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS
are enabled. The result is that KCOV can not be enabled on systems which
require this display engine. A much simpler and less invasive solution is
to disable KCOV selectively when compiling the display enagine while


"enagine". Outch.

Anyway, thanks for applying.

Guenter


keeping it enabled for the rest of the kernel.

Fixes: 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov is enabled")
Cc: Arnd Bergmann 
Cc: Leo Li 
Signed-off-by: Guenter Roeck 


Reviewed-by: Harry Wentland 

Harry


---
  drivers/gpu/drm/amd/display/Kconfig | 2 +-
  drivers/gpu/drm/amd/display/dc/Makefile | 3 +++
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig 
b/drivers/gpu/drm/amd/display/Kconfig
index b4029c0d5d8c..96cbc87f7b6b 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -6,7 +6,7 @@ config DRM_AMD_DC
   bool "AMD DC - Enable new display engine"
   default y
   select SND_HDA_COMPONENT if SND_HDA_CORE
- select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && 
KCOV_ENABLE_COMPARISONS)
+ select DRM_AMD_DC_DCN if (X86 || PPC64)
   help
 Choose this option if you want to use the new display engine
 support for AMDGPU. This adds required support for Vega and
diff --git a/drivers/gpu/drm/amd/display/dc/Makefile 
b/drivers/gpu/drm/amd/display/dc/Makefile
index b4eca0236435..b801973749d2 100644
--- a/drivers/gpu/drm/amd/display/dc/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/Makefile
@@ -26,6 +26,9 @@
  DC_LIBS = basics bios dml clk_mgr dce gpio irq link virtual

  ifdef CONFIG_DRM_AMD_DC_DCN
+
+KCOV_INSTRUMENT := n
+
  DC_LIBS += dcn20
  DC_LIBS += dsc
  DC_LIBS += dcn10

Re: [PATCH] drm/amd/debugfs: Expose GFXOFF state to userspace

On Thu, Jul 14, 2022 at 12:45 PM André Almeida  wrote:
>
>
>
> Às 13:42 de 14/07/22, Alex Deucher escreveu:
> > On Wed, Jul 13, 2022 at 11:15 AM André Almeida  
> > wrote:
> >>
> >> GFXOFF has two different "state" values: one to define if the GPU is
> >> allowed/disallowed to enter GFXOFF, usually called state; and another
> >> one to define if currently GFXOFF is being used, usually called status.
> >> Even when GFXOFF is allowed, GPU firmware can decide to not used it
> >> accordingly to the GPU load.
> >>
> >> Userspace can allow/disallow GPUs to enter into GFXOFF via debugfs. The
> >> kernel maintains a counter of requests for GFXOFF (gfx_off_req_count)
> >> that should be decreased to allow GFXOFF and increased to disallow.
> >>
> >> The issue with this interface is that userspace can't be sure if GFXOFF
> >> is currently allowed. Even by checking amdgpu_gfxoff file, one might get
> >> an ambiguous 2, that means that GPU is currently out of GFXOFF, but that
> >> can be either because it's currently disallowed or because it's allowed
> >> but given the current GPU load it's enabled. Then, userspace needs to
> >> rely on the fact that GFXOFF is enabled by default on boot and to track
> >> this information.
> >>
> >> To make userspace life easier and GFXOFF more reliable, return the
> >> current state of GFXOFF to userspace when reading amdgpu_gfxoff with the
> >> same semantics of writing: 0 means not allowed, not 0 means allowed.
> >>
> >
> > This looks good. Can you document this in the amdgpu kerneldoc?
> >
>
> Sure, let me send a v2 with that

While you are at it, if we are missing docs for the other gfxoff file
can you add that as well?

Thanks!

Alex

>
> > Alex
> >
> >> Expose the current status of GFXOFF through a new file,
> >> amdgpu_gfxoff_status.
> >>
> >> Signed-off-by: André Almeida 
> >> ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 49 -
> >>  1 file changed, 47 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >> index f3b3c688e4e7..e2eec985adb3 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> >> @@ -1117,13 +1117,50 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct 
> >> file *f, char __user *buf,
> >> }
> >>
> >> while (size) {
> >> -   uint32_t value;
> >> +   u32 value = adev->gfx.gfx_off_state;
> >> +
> >> +   r = put_user(value, (u32 *)buf);
> >> +   if (r)
> >> +   goto out;
> >> +
> >> +   result += 4;
> >> +   buf += 4;
> >> +   *pos += 4;
> >> +   size -= 4;
> >> +   }
> >> +
> >> +   r = result;
> >> +out:
> >> +   pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
> >> +   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> >> +
> >> +   return r;
> >> +}
> >> +
> >> +static ssize_t amdgpu_debugfs_gfxoff_status_read(struct file *f, char 
> >> __user *buf,
> >> +size_t size, loff_t *pos)
> >> +{
> >> +   struct amdgpu_device *adev = file_inode(f)->i_private;
> >> +   ssize_t result = 0;
> >> +   int r;
> >> +
> >> +   if (size & 0x3 || *pos & 0x3)
> >> +   return -EINVAL;
> >> +
> >> +   r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
> >> +   if (r < 0) {
> >> +   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> >> +   return r;
> >> +   }
> >> +
> >> +   while (size) {
> >> +   u32 value;
> >>
> >> r = amdgpu_get_gfx_off_status(adev, );
> >> if (r)
> >> goto out;
> >>
> >> -   r = put_user(value, (uint32_t *)buf);
> >> +   r = put_user(value, (u32 *)buf);
> >> if (r)
> >> goto out;
> >>
> >> @@ -1206,6 +1243,12 @@ static const struct file_operations 
> >> amdgpu_debugfs_gfxoff_fops = {
> >> .llseek = default_llseek
> >>  };
> >>
> >> +static const struct file_operations amdgpu_debugfs_gfxoff_status_fops = {
> >> +   .owner = THIS_MODULE,
> >> +   .read = amdgpu_debugfs_gfxoff_status_read,
> >> +   .llseek = default_llseek
> >> +};
> >> +
> >>  static const struct file_operations *debugfs_regs[] = {
> >> _debugfs_regs_fops,
> >> _debugfs_regs2_fops,
> >> @@ -1217,6 +1260,7 @@ static const struct file_operations *debugfs_regs[] 
> >> = {
> >> _debugfs_wave_fops,
> >> _debugfs_gpr_fops,
> >> _debugfs_gfxoff_fops,
> >> +   _debugfs_gfxoff_status_fops,
> >>  };
> >>
> >>  static const char *debugfs_regs_names[] = {
> >> @@ -1230,6 +1274,7 @@ static const char *debugfs_regs_names[] = {
> >> "amdgpu_wave",
> >> "amdgpu_gpr",
> >> "amdgpu_gfxoff",
> >> +   "amdgpu_gfxoff_status",
> >>  };
>

Re: [PATCH] drm/amd/debugfs: Expose GFXOFF state to userspace




Às 13:42 de 14/07/22, Alex Deucher escreveu:
> On Wed, Jul 13, 2022 at 11:15 AM André Almeida  wrote:
>>
>> GFXOFF has two different "state" values: one to define if the GPU is
>> allowed/disallowed to enter GFXOFF, usually called state; and another
>> one to define if currently GFXOFF is being used, usually called status.
>> Even when GFXOFF is allowed, GPU firmware can decide to not used it
>> accordingly to the GPU load.
>>
>> Userspace can allow/disallow GPUs to enter into GFXOFF via debugfs. The
>> kernel maintains a counter of requests for GFXOFF (gfx_off_req_count)
>> that should be decreased to allow GFXOFF and increased to disallow.
>>
>> The issue with this interface is that userspace can't be sure if GFXOFF
>> is currently allowed. Even by checking amdgpu_gfxoff file, one might get
>> an ambiguous 2, that means that GPU is currently out of GFXOFF, but that
>> can be either because it's currently disallowed or because it's allowed
>> but given the current GPU load it's enabled. Then, userspace needs to
>> rely on the fact that GFXOFF is enabled by default on boot and to track
>> this information.
>>
>> To make userspace life easier and GFXOFF more reliable, return the
>> current state of GFXOFF to userspace when reading amdgpu_gfxoff with the
>> same semantics of writing: 0 means not allowed, not 0 means allowed.
>>
> 
> This looks good. Can you document this in the amdgpu kerneldoc?
> 

Sure, let me send a v2 with that

> Alex
> 
>> Expose the current status of GFXOFF through a new file,
>> amdgpu_gfxoff_status.
>>
>> Signed-off-by: André Almeida 
>> ---
>>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 49 -
>>  1 file changed, 47 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> index f3b3c688e4e7..e2eec985adb3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
>> @@ -1117,13 +1117,50 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct 
>> file *f, char __user *buf,
>> }
>>
>> while (size) {
>> -   uint32_t value;
>> +   u32 value = adev->gfx.gfx_off_state;
>> +
>> +   r = put_user(value, (u32 *)buf);
>> +   if (r)
>> +   goto out;
>> +
>> +   result += 4;
>> +   buf += 4;
>> +   *pos += 4;
>> +   size -= 4;
>> +   }
>> +
>> +   r = result;
>> +out:
>> +   pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
>> +   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
>> +
>> +   return r;
>> +}
>> +
>> +static ssize_t amdgpu_debugfs_gfxoff_status_read(struct file *f, char 
>> __user *buf,
>> +size_t size, loff_t *pos)
>> +{
>> +   struct amdgpu_device *adev = file_inode(f)->i_private;
>> +   ssize_t result = 0;
>> +   int r;
>> +
>> +   if (size & 0x3 || *pos & 0x3)
>> +   return -EINVAL;
>> +
>> +   r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
>> +   if (r < 0) {
>> +   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
>> +   return r;
>> +   }
>> +
>> +   while (size) {
>> +   u32 value;
>>
>> r = amdgpu_get_gfx_off_status(adev, );
>> if (r)
>> goto out;
>>
>> -   r = put_user(value, (uint32_t *)buf);
>> +   r = put_user(value, (u32 *)buf);
>> if (r)
>> goto out;
>>
>> @@ -1206,6 +1243,12 @@ static const struct file_operations 
>> amdgpu_debugfs_gfxoff_fops = {
>> .llseek = default_llseek
>>  };
>>
>> +static const struct file_operations amdgpu_debugfs_gfxoff_status_fops = {
>> +   .owner = THIS_MODULE,
>> +   .read = amdgpu_debugfs_gfxoff_status_read,
>> +   .llseek = default_llseek
>> +};
>> +
>>  static const struct file_operations *debugfs_regs[] = {
>> _debugfs_regs_fops,
>> _debugfs_regs2_fops,
>> @@ -1217,6 +1260,7 @@ static const struct file_operations *debugfs_regs[] = {
>> _debugfs_wave_fops,
>> _debugfs_gpr_fops,
>> _debugfs_gfxoff_fops,
>> +   _debugfs_gfxoff_status_fops,
>>  };
>>
>>  static const char *debugfs_regs_names[] = {
>> @@ -1230,6 +1274,7 @@ static const char *debugfs_regs_names[] = {
>> "amdgpu_wave",
>> "amdgpu_gpr",
>> "amdgpu_gfxoff",
>> +   "amdgpu_gfxoff_status",
>>  };
>>
>>  /**
>> --
>> 2.37.0
>>

Re: [PATCH] drm/amd/debugfs: Expose GFXOFF state to userspace

On Wed, Jul 13, 2022 at 11:15 AM André Almeida  wrote:
>
> GFXOFF has two different "state" values: one to define if the GPU is
> allowed/disallowed to enter GFXOFF, usually called state; and another
> one to define if currently GFXOFF is being used, usually called status.
> Even when GFXOFF is allowed, GPU firmware can decide to not used it
> accordingly to the GPU load.
>
> Userspace can allow/disallow GPUs to enter into GFXOFF via debugfs. The
> kernel maintains a counter of requests for GFXOFF (gfx_off_req_count)
> that should be decreased to allow GFXOFF and increased to disallow.
>
> The issue with this interface is that userspace can't be sure if GFXOFF
> is currently allowed. Even by checking amdgpu_gfxoff file, one might get
> an ambiguous 2, that means that GPU is currently out of GFXOFF, but that
> can be either because it's currently disallowed or because it's allowed
> but given the current GPU load it's enabled. Then, userspace needs to
> rely on the fact that GFXOFF is enabled by default on boot and to track
> this information.
>
> To make userspace life easier and GFXOFF more reliable, return the
> current state of GFXOFF to userspace when reading amdgpu_gfxoff with the
> same semantics of writing: 0 means not allowed, not 0 means allowed.
>

This looks good. Can you document this in the amdgpu kerneldoc?

Alex

> Expose the current status of GFXOFF through a new file,
> amdgpu_gfxoff_status.
>
> Signed-off-by: André Almeida 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 49 -
>  1 file changed, 47 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> index f3b3c688e4e7..e2eec985adb3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
> @@ -1117,13 +1117,50 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct file 
> *f, char __user *buf,
> }
>
> while (size) {
> -   uint32_t value;
> +   u32 value = adev->gfx.gfx_off_state;
> +
> +   r = put_user(value, (u32 *)buf);
> +   if (r)
> +   goto out;
> +
> +   result += 4;
> +   buf += 4;
> +   *pos += 4;
> +   size -= 4;
> +   }
> +
> +   r = result;
> +out:
> +   pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
> +   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> +
> +   return r;
> +}
> +
> +static ssize_t amdgpu_debugfs_gfxoff_status_read(struct file *f, char __user 
> *buf,
> +size_t size, loff_t *pos)
> +{
> +   struct amdgpu_device *adev = file_inode(f)->i_private;
> +   ssize_t result = 0;
> +   int r;
> +
> +   if (size & 0x3 || *pos & 0x3)
> +   return -EINVAL;
> +
> +   r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
> +   if (r < 0) {
> +   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
> +   return r;
> +   }
> +
> +   while (size) {
> +   u32 value;
>
> r = amdgpu_get_gfx_off_status(adev, );
> if (r)
> goto out;
>
> -   r = put_user(value, (uint32_t *)buf);
> +   r = put_user(value, (u32 *)buf);
> if (r)
> goto out;
>
> @@ -1206,6 +1243,12 @@ static const struct file_operations 
> amdgpu_debugfs_gfxoff_fops = {
> .llseek = default_llseek
>  };
>
> +static const struct file_operations amdgpu_debugfs_gfxoff_status_fops = {
> +   .owner = THIS_MODULE,
> +   .read = amdgpu_debugfs_gfxoff_status_read,
> +   .llseek = default_llseek
> +};
> +
>  static const struct file_operations *debugfs_regs[] = {
> _debugfs_regs_fops,
> _debugfs_regs2_fops,
> @@ -1217,6 +1260,7 @@ static const struct file_operations *debugfs_regs[] = {
> _debugfs_wave_fops,
> _debugfs_gpr_fops,
> _debugfs_gfxoff_fops,
> +   _debugfs_gfxoff_status_fops,
>  };
>
>  static const char *debugfs_regs_names[] = {
> @@ -1230,6 +1274,7 @@ static const char *debugfs_regs_names[] = {
> "amdgpu_wave",
> "amdgpu_gpr",
> "amdgpu_gfxoff",
> +   "amdgpu_gfxoff_status",
>  };
>
>  /**
> --
> 2.37.0
>

Re: [PATCH] drm/amdgpu: Clarify asics naming in Kconfig options

Applied.  Thanks!

On Thu, Jul 14, 2022 at 9:50 AM André Almeida  wrote:
>
> Clarify which architecture those asics acronyms refers to.
>
> Signed-off-by: André Almeida 
> ---
>  drivers/gpu/drm/amd/amdgpu/Kconfig | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig 
> b/drivers/gpu/drm/amd/amdgpu/Kconfig
> index 74a8105fd2c0..d55275de 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Kconfig
> +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig
> @@ -4,7 +4,7 @@ config DRM_AMDGPU_SI
> depends on DRM_AMDGPU
> help
>   Choose this option if you want to enable experimental support
> - for SI asics.
> + for SI (Southern Islands) asics.
>
>   SI is already supported in radeon. Experimental support for SI
>   in amdgpu will be disabled by default and is still provided by
> @@ -16,7 +16,8 @@ config DRM_AMDGPU_CIK
> bool "Enable amdgpu support for CIK parts"
> depends on DRM_AMDGPU
> help
> - Choose this option if you want to enable support for CIK asics.
> + Choose this option if you want to enable support for CIK (Sea
> + Islands) asics.
>
>   CIK is already supported in radeon. Support for CIK in amdgpu
>   will be disabled by default and is still provided by radeon.
> --
> 2.37.0
>

Re: [PATCH][next] drm/amd/display: Fix spelling mistake "supporing" -> "supporting"

Applied.  Thanks!

Alex

On Thu, Jul 14, 2022 at 6:34 AM Colin Ian King  wrote:
>
> There is a spelling mistake in a dml_print message. Fix it.
>
> Signed-off-by: Colin Ian King 
> ---
>  .../gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c| 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c 
> b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
> index 6101c962ab0a..fc4d7474c111 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_mode_vba_314.c
> @@ -2994,7 +2994,7 @@ static void 
> DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
> for (k = 0; k < v->NumberOfActivePlanes; ++k) {
> if (v->ImmediateFlipSupportedForPipe[k] == 
> false) {
>  #ifdef __DML_VBA_DEBUG__
> -   dml_print("DML::%s: Pipe %0d not 
> supporing iflip\n", __func__, k);
> +   dml_print("DML::%s: Pipe %0d not 
> supporting iflip\n", __func__, k);
>  #endif
> v->ImmediateFlipSupported = false;
> }
> --
> 2.35.3
>

Re: [PATCH] drm/amd/display: Enable building new display engine with KCOV enabled

Applied.  Thanks!

On Wed, Jul 13, 2022 at 4:03 PM Harry Wentland  wrote:
>
> On 2022-07-12 18:42, Guenter Roeck wrote:
> > The new display engine uses floating point math, which is not supported
> > by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
> > is enabled") tried to work around the problem by disabling
> > CONFIG_DRM_AMD_DC_DCN if KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS
> > are enabled. The result is that KCOV can not be enabled on systems which
> > require this display engine. A much simpler and less invasive solution is
> > to disable KCOV selectively when compiling the display enagine while
> > keeping it enabled for the rest of the kernel.
> >
> > Fixes: 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov is 
> > enabled")
> > Cc: Arnd Bergmann 
> > Cc: Leo Li 
> > Signed-off-by: Guenter Roeck 
>
> Reviewed-by: Harry Wentland 
>
> Harry
>
> > ---
> >  drivers/gpu/drm/amd/display/Kconfig | 2 +-
> >  drivers/gpu/drm/amd/display/dc/Makefile | 3 +++
> >  2 files changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/Kconfig 
> > b/drivers/gpu/drm/amd/display/Kconfig
> > index b4029c0d5d8c..96cbc87f7b6b 100644
> > --- a/drivers/gpu/drm/amd/display/Kconfig
> > +++ b/drivers/gpu/drm/amd/display/Kconfig
> > @@ -6,7 +6,7 @@ config DRM_AMD_DC
> >   bool "AMD DC - Enable new display engine"
> >   default y
> >   select SND_HDA_COMPONENT if SND_HDA_CORE
> > - select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && 
> > KCOV_ENABLE_COMPARISONS)
> > + select DRM_AMD_DC_DCN if (X86 || PPC64)
> >   help
> > Choose this option if you want to use the new display engine
> > support for AMDGPU. This adds required support for Vega and
> > diff --git a/drivers/gpu/drm/amd/display/dc/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/Makefile
> > index b4eca0236435..b801973749d2 100644
> > --- a/drivers/gpu/drm/amd/display/dc/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/Makefile
> > @@ -26,6 +26,9 @@
> >  DC_LIBS = basics bios dml clk_mgr dce gpio irq link virtual
> >
> >  ifdef CONFIG_DRM_AMD_DC_DCN
> > +
> > +KCOV_INSTRUMENT := n
> > +
> >  DC_LIBS += dcn20
> >  DC_LIBS += dsc
> >  DC_LIBS += dcn10
>

Re: [PATCH 01/10] drm/sched: move calling drm_sched_entity_select_rq

2022-07-14 Thread Christian König


We need this for limiting codecs like AV1 to the first instance for VCN3.

Essentially the idea is that we first initialize the job with entity, id 
etc... and before we submit it we select a new rq for the entity. In the 
meantime the VCN3 inline parse will have modified the available rqs for 
the entity.


See the patch "revert "fix limiting AV1 to the first instance on VCN3"" 
as well.


Christian.

Am 14.07.22 um 17:43 schrieb Andrey Grodzovsky:
Can you please remind me of the use case that requires this ? I 
browsed through
related mails in the past but haven't found when is that needed. For 
amdgpu

drm_sched_job_init and drm_sched_job_arm are called together and amdgpu
is the only one who supports modifying entity priority on the fly as 
far as i see.


Andrey

On 2022-07-14 06:38, Christian König wrote:

We already discussed that the call to drm_sched_entity_select_rq() needs
to move to drm_sched_job_arm() to be able to set a new scheduler list
between _init() and _arm(). This was just not applied for some reason.

Signed-off-by: Christian König 
CC: Andrey Grodzovsky 
CC: dri-devel@lists.freedesktop.org
---
  drivers/gpu/drm/scheduler/sched_main.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c

index 68317d3a7a27..e0ab14e0fb6b 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -592,7 +592,6 @@ int drm_sched_job_init(struct drm_sched_job *job,
 struct drm_sched_entity *entity,
 void *owner)
  {
-    drm_sched_entity_select_rq(entity);
  if (!entity->rq)
  return -ENOENT;
  @@ -628,7 +627,7 @@ void drm_sched_job_arm(struct drm_sched_job *job)
  struct drm_sched_entity *entity = job->entity;
    BUG_ON(!entity);
-
+    drm_sched_entity_select_rq(entity);
  sched = entity->rq->sched;
    job->sched = sched;

Re: [PATCH v1] drm/scheduler: Don't kill jobs in interrupt context

On Thu, Jul 14, 2022 at 10:14 AM Andrey Grodzovsky
 wrote:
>
>
> On 2022-07-14 05:57, Dmitry Osipenko wrote:
> > On 7/12/22 11:56, Dmitry Osipenko wrote:
> >> On 7/6/22 18:46, Alex Deucher wrote:
> >>> On Wed, Jul 6, 2022 at 9:49 AM Andrey Grodzovsky
> >>>  wrote:
>  On 2022-07-06 03:07, Dmitry Osipenko wrote:
> 
> > Hello Andrey,
> >
> > On 5/17/22 17:48, Dmitry Osipenko wrote:
> >> On 5/17/22 17:13, Andrey Grodzovsky wrote:
> >>> Done.
> >>>
> >>> Andrey
> >> Awesome, thank you!
> >>
> > Given that this drm-scheduler issue needs to be fixed in the 5.19-RC and
> > earlier, shouldn't it be in the drm-fixes and not in drm-next?
> 
>  I pushed it into drm-misc from where it got into drm-next. I don't have
>  permission for drm-fixes.
> >>> The -fixes branch of drm-misc.
> >> Now I don't see the scheduler bugfix neither in the -fixes branch nor in
> >> the -next and today Dave sent out 5.19-rc7 pull request without the
> >> scheduler fix. Could anyone please check what is going on with the DRM
> >> patches? Thanks!
> >>
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ffreedesktop%2Fdrm-misc%2Fcommits%2Fdrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7C68b627b8482a4fd28a5608da657f4375%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637933894551324163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=CDdLG%2F7SqCudEnjhBSsXqq15mfhlHlS3xAdAfB%2Bh%2F1s%3Dreserved=0
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Flog%2F%3Fh%3Ddrm-misc-fixesdata=05%7C01%7Candrey.grodzovsky%40amd.com%7C68b627b8482a4fd28a5608da657f4375%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637933894551324163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=4Vz40j6F%2FzHYckXEyPEunj9DRSoTXikhNxZDXeocTss%3Dreserved=0
> > The patch is in the drm-misc-next-fixes, so it wasn't moved to the
> > drm-misc-fixes.
> >
> > Andrey, don't you have access to drm-misc-fixes? Or you meant
> > drm-fixes=drm-misc-fixes?
>
>
> I have only accesses to drm-misc-next to which I pushed this patch.

anyone with drm-misc rights can commit to any of the branches in the
drm-misc tree.  You just need to check out and push the appropriate
branch.  then push the changes.  E.g.,
dim push-branch drm-misc-next
vs
dim push-branch drm-misc-next-fixes
etc.

Alex


>
> Andrey
>
>
> >

[PATCH] mm: move page zone helpers from mm.h to mmzone.h

2022-07-14 Thread Alex Sierra

[WHY]
It makes more sense to have these helpers in zone specific header
file, rather than the generic mm.h

Signed-off-by: Alex Sierra 
---
 include/linux/memremap.h |  2 +-
 include/linux/mm.h   | 78 ---
 include/linux/mmzone.h   | 80 
 3 files changed, 81 insertions(+), 79 deletions(-)

diff --git a/include/linux/memremap.h b/include/linux/memremap.h
index 8af304f6b504..77229165c914 100644
--- a/include/linux/memremap.h
+++ b/include/linux/memremap.h
@@ -2,7 +2,7 @@
 #ifndef _LINUX_MEMREMAP_H_
 #define _LINUX_MEMREMAP_H_
 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3b31b33bd5be..2df8c2b98d36 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1049,84 +1049,6 @@ vm_fault_t finish_mkwrite_fault(struct vm_fault *vmf);
  *   back into memory.
  */
 
-/*
- * The zone field is never updated after free_area_init_core()
- * sets it, so none of the operations on it need to be atomic.
- */
-
-/* Page flags: | [SECTION] | [NODE] | ZONE | [LAST_CPUPID] | ... | FLAGS | */
-#define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - SECTIONS_WIDTH)
-#define NODES_PGOFF(SECTIONS_PGOFF - NODES_WIDTH)
-#define ZONES_PGOFF(NODES_PGOFF - ZONES_WIDTH)
-#define LAST_CPUPID_PGOFF  (ZONES_PGOFF - LAST_CPUPID_WIDTH)
-#define KASAN_TAG_PGOFF(LAST_CPUPID_PGOFF - KASAN_TAG_WIDTH)
-
-/*
- * Define the bit shifts to access each section.  For non-existent
- * sections we define the shift as 0; that plus a 0 mask ensures
- * the compiler will optimise away reference to them.
- */
-#define SECTIONS_PGSHIFT   (SECTIONS_PGOFF * (SECTIONS_WIDTH != 0))
-#define NODES_PGSHIFT  (NODES_PGOFF * (NODES_WIDTH != 0))
-#define ZONES_PGSHIFT  (ZONES_PGOFF * (ZONES_WIDTH != 0))
-#define LAST_CPUPID_PGSHIFT(LAST_CPUPID_PGOFF * (LAST_CPUPID_WIDTH != 0))
-#define KASAN_TAG_PGSHIFT  (KASAN_TAG_PGOFF * (KASAN_TAG_WIDTH != 0))
-
-/* NODE:ZONE or SECTION:ZONE is used to ID a zone for the buddy allocator */
-#ifdef NODE_NOT_IN_PAGE_FLAGS
-#define ZONEID_SHIFT   (SECTIONS_SHIFT + ZONES_SHIFT)
-#define ZONEID_PGOFF   ((SECTIONS_PGOFF < ZONES_PGOFF)? \
-   SECTIONS_PGOFF : ZONES_PGOFF)
-#else
-#define ZONEID_SHIFT   (NODES_SHIFT + ZONES_SHIFT)
-#define ZONEID_PGOFF   ((NODES_PGOFF < ZONES_PGOFF)? \
-   NODES_PGOFF : ZONES_PGOFF)
-#endif
-
-#define ZONEID_PGSHIFT (ZONEID_PGOFF * (ZONEID_SHIFT != 0))
-
-#define ZONES_MASK ((1UL << ZONES_WIDTH) - 1)
-#define NODES_MASK ((1UL << NODES_WIDTH) - 1)
-#define SECTIONS_MASK  ((1UL << SECTIONS_WIDTH) - 1)
-#define LAST_CPUPID_MASK   ((1UL << LAST_CPUPID_SHIFT) - 1)
-#define KASAN_TAG_MASK ((1UL << KASAN_TAG_WIDTH) - 1)
-#define ZONEID_MASK((1UL << ZONEID_SHIFT) - 1)
-
-static inline enum zone_type page_zonenum(const struct page *page)
-{
-   ASSERT_EXCLUSIVE_BITS(page->flags, ZONES_MASK << ZONES_PGSHIFT);
-   return (page->flags >> ZONES_PGSHIFT) & ZONES_MASK;
-}
-
-static inline enum zone_type folio_zonenum(const struct folio *folio)
-{
-   return page_zonenum(>page);
-}
-
-#ifdef CONFIG_ZONE_DEVICE
-static inline bool is_zone_device_page(const struct page *page)
-{
-   return page_zonenum(page) == ZONE_DEVICE;
-}
-extern void memmap_init_zone_device(struct zone *, unsigned long,
-   unsigned long, struct dev_pagemap *);
-#else
-static inline bool is_zone_device_page(const struct page *page)
-{
-   return false;
-}
-#endif
-
-static inline bool folio_is_zone_device(const struct folio *folio)
-{
-   return is_zone_device_page(>page);
-}
-
-static inline bool is_zone_movable_page(const struct page *page)
-{
-   return page_zonenum(page) == ZONE_MOVABLE;
-}
-
 #if defined(CONFIG_ZONE_DEVICE) && defined(CONFIG_FS_DAX)
 DECLARE_STATIC_KEY_FALSE(devmap_managed_key);
 
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index aab70355d64f..47fc41f43c48 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -730,6 +730,86 @@ static inline bool zone_is_empty(struct zone *zone)
return zone->spanned_pages == 0;
 }
 
+#ifndef BUILD_VDSO32_64
+/*
+ * The zone field is never updated after free_area_init_core()
+ * sets it, so none of the operations on it need to be atomic.
+ */
+
+/* Page flags: | [SECTION] | [NODE] | ZONE | [LAST_CPUPID] | ... | FLAGS | */
+#define SECTIONS_PGOFF ((sizeof(unsigned long)*8) - SECTIONS_WIDTH)
+#define NODES_PGOFF(SECTIONS_PGOFF - NODES_WIDTH)
+#define ZONES_PGOFF(NODES_PGOFF - ZONES_WIDTH)
+#define LAST_CPUPID_PGOFF  (ZONES_PGOFF - LAST_CPUPID_WIDTH)
+#define KASAN_TAG_PGOFF(LAST_CPUPID_PGOFF - KASAN_TAG_WIDTH)
+
+/*
+ * Define the bit shifts to access

Re: [PATCH -next] drm/amdgpu: double free error and freeing uninitialized null pointer