Re: [PATCH v2 36/37] arm64: dts: zynqmp: Add ports for the DisplayPort subsystem

2022-10-19 Thread Michal Simek

Hi Laurent,

On 10/19/22 17:59, Laurent Pinchart wrote:

Hi Michal,

I plan to send a pull request for the series soon. Patches 01/37 to
35/37 will go through the DRM tree. How would you like to handle this
patch and the next ? They depend on the DT binding changes in 01/37.


No problem for me if you want to take them via DRM tree (which is the easiest 
way for me).

In that case feel free to add my

Acked-by: Michal Simek 

to both of that patches.

If you want me to queue it via my tree I will cherry pick that two patches.

Thanks,
Michal


Re: [PATCH] Make xilinxfb_release() return void

2022-10-19 Thread Helge Deller

On 10/19/22 15:24, Uwe Kleine-König wrote:

The function xilinxfb_release() returns zero unconditionally. Make it
return void. There is no semantic change, the only effect is that it
becomes obvious that the driver's .remove() callback always returns zero.

This is a preparation for making platform remove callbacks return void.
> Signed-off-by: Uwe Kleine-König 


applied, with the subject adjusted.

Thanks,
Helge



---
  drivers/video/fbdev/xilinxfb.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c
index 438e2c78142f..1ac83900a21c 100644
--- a/drivers/video/fbdev/xilinxfb.c
+++ b/drivers/video/fbdev/xilinxfb.c
@@ -376,7 +376,7 @@ static int xilinxfb_assign(struct platform_device *pdev,
return rc;
  }

-static int xilinxfb_release(struct device *dev)
+static void xilinxfb_release(struct device *dev)
  {
struct xilinxfb_drvdata *drvdata = dev_get_drvdata(dev);

@@ -402,8 +402,6 @@ static int xilinxfb_release(struct device *dev)
if (!(drvdata->flags & BUS_ACCESS_FLAG))
dcr_unmap(drvdata->dcr_host, drvdata->dcr_len);
  #endif
-
-   return 0;
  }

  /* -
@@ -480,7 +478,9 @@ static int xilinxfb_of_probe(struct platform_device *pdev)

  static int xilinxfb_of_remove(struct platform_device *op)
  {
-   return xilinxfb_release(&op->dev);
+   xilinxfb_release(&op->dev);
+
+   return 0;
  }

  /* Match table for of_platform binding */

base-commit: 9abf2313adc1ca1b6180c508c25f22f9395cc780




Re: [PATCH] video: fix repeated words in comments

2022-10-19 Thread Helge Deller

On 10/19/22 14:57, Jilin Yuan wrote:

Delete the redundant word 'the'.

Signed-off-by: Jilin Yuan 


applied.
Thanks!

Helge



---
  drivers/video/fbdev/sis/sis_accel.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/sis/sis_accel.c 
b/drivers/video/fbdev/sis/sis_accel.c
index 1914ab5a5a91..5850e4325f07 100644
--- a/drivers/video/fbdev/sis/sis_accel.c
+++ b/drivers/video/fbdev/sis/sis_accel.c
@@ -202,7 +202,7 @@ SiS310SubsequentScreenToScreenCopy(struct sis_video_info 
*ivideo, int src_x, int
 * and destination blitting areas overlap and
 * adapt the bitmap addresses synchronously
 * if the coordinates exceed the valid range.
-* The the areas do not overlap, we do our
+* The areas do not overlap, we do our
 * normal check.
 */
if((mymax - mymin) < height) {




Re: [PATCH AUTOSEL 5.19 07/16] drm/amdgpu: use dirty framebuffer helper

2022-10-19 Thread Eric Biggers
On Wed, Sep 21, 2022 at 11:53:23AM -0400, Sasha Levin wrote:
> From: Hamza Mahfooz 
> 
> [ Upstream commit 66f99628eb24409cb8feb5061f78283c8b65f820 ]
> 
> Currently, we aren't handling DRM_IOCTL_MODE_DIRTYFB. So, use
> drm_atomic_helper_dirtyfb() as the dirty callback in the amdgpu_fb_funcs
> struct.
> 
> Signed-off-by: Hamza Mahfooz 
> Acked-by: Alex Deucher 
> Signed-off-by: Alex Deucher 
> Signed-off-by: Sasha Levin 

I just spent a long time bisecting a hard-to-reproduce regression to this
commit, only to find that a revert was just queued this week.

Why was this commit backported to stable in the first place?  It didn't have Cc
stable, and it didn't claim to be fixing anything.

- Eric


[PATCH v2 01/16] drm/vmwgfx: Write the driver id registers

2022-10-19 Thread Zack Rusin
From: Zack Rusin 

Driver id registers are a new mechanism in the svga device to hint to the
device which driver is running. This should not change device behavior
in any way, but might be convenient to work-around specific bugs
in guest drivers.

Signed-off-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 43 +++--
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index d7bd5eb1d3ac..45028e25d490 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -25,10 +25,13 @@
  *
  **/
 
-#include 
-#include 
-#include 
-#include 
+
+#include "vmwgfx_drv.h"
+
+#include "vmwgfx_devcaps.h"
+#include "vmwgfx_mksstat.h"
+#include "vmwgfx_binding.h"
+#include "ttm_object.h"
 
 #include 
 #include 
@@ -41,11 +44,11 @@
 #include 
 #include 
 
-#include "ttm_object.h"
-#include "vmwgfx_binding.h"
-#include "vmwgfx_devcaps.h"
-#include "vmwgfx_drv.h"
-#include "vmwgfx_mksstat.h"
+#include 
+#include 
+#include 
+#include 
+#include 
 
 #define VMWGFX_DRIVER_DESC "Linux drm driver for VMware graphics devices"
 
@@ -806,6 +809,27 @@ static int vmw_detect_version(struct vmw_private *dev)
return 0;
 }
 
+static void vmw_write_driver_id(struct vmw_private *dev)
+{
+   if ((dev->capabilities2 & SVGA_CAP2_DX2) != 0) {
+   vmw_write(dev,  SVGA_REG_GUEST_DRIVER_ID,
+ SVGA_REG_GUEST_DRIVER_ID_LINUX);
+
+   vmw_write(dev, SVGA_REG_GUEST_DRIVER_VERSION1,
+ LINUX_VERSION_MAJOR << 24 |
+ LINUX_VERSION_PATCHLEVEL << 16 |
+ LINUX_VERSION_SUBLEVEL);
+   vmw_write(dev, SVGA_REG_GUEST_DRIVER_VERSION2,
+ VMWGFX_DRIVER_MAJOR << 24 |
+ VMWGFX_DRIVER_MINOR << 16 |
+ VMWGFX_DRIVER_PATCHLEVEL);
+   vmw_write(dev, SVGA_REG_GUEST_DRIVER_VERSION3, 0);
+
+   vmw_write(dev, SVGA_REG_GUEST_DRIVER_ID,
+ SVGA_REG_GUEST_DRIVER_ID_SUBMIT);
+   }
+}
+
 static int vmw_driver_load(struct vmw_private *dev_priv, u32 pci_id)
 {
int ret;
@@ -1091,6 +1115,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv, 
u32 pci_id)
vmw_host_printf("vmwgfx: Module Version: %d.%d.%d (kernel: %s)",
VMWGFX_DRIVER_MAJOR, VMWGFX_DRIVER_MINOR,
VMWGFX_DRIVER_PATCHLEVEL, UTS_RELEASE);
+   vmw_write_driver_id(dev_priv);
 
if (dev_priv->enable_fb) {
vmw_fifo_resource_inc(dev_priv);
-- 
2.34.1



[PATCH v2 11/16] drm/vmwgfx: Remove vmwgfx_hashtab

2022-10-19 Thread Zack Rusin
From: Maaz Mombasawala 

The vmwgfx driver has migrated from using the hashtable in vmwgfx_hashtab
to the linux/hashtable implementation. Remove the vmwgfx_hashtab from the
driver.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Reviewed-by: Zack Rusin 
Signed-off-by: Zack Rusin 
---
 Documentation/gpu/todo.rst |  11 --
 drivers/gpu/drm/vmwgfx/Makefile|   2 +-
 drivers/gpu/drm/vmwgfx/ttm_object.c|   8 +-
 drivers/gpu/drm/vmwgfx/ttm_object.h|   2 -
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|   6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.c| 199 -
 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.h|  83 -
 8 files changed, 12 insertions(+), 303 deletions(-)
 delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.c
 delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.h

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 393d218e4a0c..b2c6aaf1edf2 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -651,17 +651,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks.
 
 Contact: Harry Wentland, Alex Deucher
 
-vmwgfx: Replace hashtable with Linux' implementation
-
-
-The vmwgfx driver uses its own hashtable implementation. Replace the
-code with Linux' implementation and update the callers. It's mostly a
-refactoring task, but the interfaces are different.
-
-Contact: Zack Rusin, Thomas Zimmermann 
-
-Level: Intermediate
-
 Bootsplash
 ==
 
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index eee73b9aa404..68e350f410ad 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,5 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
-vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_hashtab.o vmwgfx_kms.o 
vmwgfx_drv.o \
+vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c 
b/drivers/gpu/drm/vmwgfx/ttm_object.c
index c07b81fbc495..932b125ebf3d 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.c
@@ -284,7 +284,7 @@ ttm_base_object_noref_lookup(struct ttm_object_file *tfile, 
uint64_t key)
}
 
__release(RCU);
-   return drm_hash_entry(hash, struct ttm_ref_object, hash)->obj;
+   return hlist_entry(hash, struct ttm_ref_object, hash)->obj;
 }
 EXPORT_SYMBOL(ttm_base_object_noref_lookup);
 
@@ -299,7 +299,7 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
ret = ttm_tfile_find_ref_rcu(tfile, key, &hash);
 
if (likely(ret == 0)) {
-   base = drm_hash_entry(hash, struct ttm_ref_object, hash)->obj;
+   base = hlist_entry(hash, struct ttm_ref_object, hash)->obj;
if (!kref_get_unless_zero(&base->refcount))
base = NULL;
}
@@ -343,7 +343,7 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
ret = ttm_tfile_find_ref_rcu(tfile, base->handle, &hash);
 
if (ret == 0) {
-   ref = drm_hash_entry(hash, struct ttm_ref_object, hash);
+   ref = hlist_entry(hash, struct ttm_ref_object, hash);
if (kref_get_unless_zero(&ref->kref)) {
rcu_read_unlock();
break;
@@ -407,7 +407,7 @@ int ttm_ref_object_base_unref(struct ttm_object_file *tfile,
spin_unlock(&tfile->lock);
return -EINVAL;
}
-   ref = drm_hash_entry(hash, struct ttm_ref_object, hash);
+   ref = hlist_entry(hash, struct ttm_ref_object, hash);
kref_put(&ref->kref, ttm_ref_object_release);
spin_unlock(&tfile->lock);
return 0;
diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.h 
b/drivers/gpu/drm/vmwgfx/ttm_object.h
index 67f30d589e27..f0ebbe340ad6 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.h
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.h
@@ -42,8 +42,6 @@
 #include 
 #include 
 
-#include "vmwgfx_hashtab.h"
-
 /**
  * enum ttm_object_type
  *
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 142aef686fcd..47bc0b411055 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -88,7 +88,7 @@ vmw_cmdbuf_res_lookup(struct vmw_cmdbuf_res_manager *man,
 
hash_for_each_possible_rcu(man->resources, hash, head, key) {
if (hash->key == key)
-   return drm_hash_entry(hash, struct vmw_cmdbuf_res, 
hash)->res;
+   return hlist_entry(hash, struct vmw_cmdb

[PATCH v2 06/16] drm/vmwgfx: Clean up cursor mobs

2022-10-19 Thread Zack Rusin
From: Michael Banack 

Clean up the cursor mob path by moving ownership of the mobs into the
plane_state, and just leaving a cache of unused mobs in the plane
itself.

Signed-off-by: Michael Banack 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 441 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |  19 +-
 2 files changed, 267 insertions(+), 193 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 214829c32ed8..07d55d610e4c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -53,33 +53,33 @@ void vmw_du_cleanup(struct vmw_display_unit *du)
  */
 
 static void vmw_cursor_update_mob(struct vmw_private *dev_priv,
- struct ttm_buffer_object *bo,
- struct ttm_bo_kmap_obj *map,
+ struct vmw_plane_state *vps,
  u32 *image, u32 width, u32 height,
  u32 hotspotX, u32 hotspotY);
+static int vmw_du_cursor_plane_unmap_cm(struct vmw_plane_state *vps);
 
 struct vmw_svga_fifo_cmd_define_cursor {
u32 cmd;
SVGAFifoCmdDefineAlphaCursor cursor;
 };
 
-static void vmw_cursor_update_image(struct vmw_private *dev_priv,
-   struct ttm_buffer_object *cm_bo,
-   struct ttm_bo_kmap_obj *cm_map,
-   u32 *image, u32 width, u32 height,
-   u32 hotspotX, u32 hotspotY)
+/**
+ * vmw_send_define_cursor_cmd - queue a define cursor command
+ * @dev_priv: the private driver struct
+ * @image: buffer which holds the cursor image
+ * @width: width of the mouse cursor image
+ * @height: height of the mouse cursor image
+ * @hotspotX: the horizontal position of mouse hotspot
+ * @hotspotY: the vertical position of mouse hotspot
+ */
+static void vmw_send_define_cursor_cmd(struct vmw_private *dev_priv,
+  u32 *image, u32 width, u32 height,
+  u32 hotspotX, u32 hotspotY)
 {
struct vmw_svga_fifo_cmd_define_cursor *cmd;
const u32 image_size = width * height * sizeof(*image);
const u32 cmd_size = sizeof(*cmd) + image_size;
 
-   if (cm_bo != NULL) {
-   vmw_cursor_update_mob(dev_priv, cm_bo, cm_map, image,
- width, height,
- hotspotX, hotspotY);
-   return;
-   }
-
/* Try to reserve fifocmd space and swallow any failures;
   such reservations cannot be left unconsumed for long
   under the risk of clogging other fifocmd users, so
@@ -104,12 +104,39 @@ static void vmw_cursor_update_image(struct vmw_private 
*dev_priv,
vmw_cmd_commit_flush(dev_priv, cmd_size);
 }
 
+/**
+ * vmw_cursor_update_image - update the cursor image on the provided plane
+ * @dev_priv: the private driver struct
+ * @vps: the plane state of the cursor plane
+ * @image: buffer which holds the cursor image
+ * @width: width of the mouse cursor image
+ * @height: height of the mouse cursor image
+ * @hotspotX: the horizontal position of mouse hotspot
+ * @hotspotY: the vertical position of mouse hotspot
+ */
+static void vmw_cursor_update_image(struct vmw_private *dev_priv,
+   struct vmw_plane_state *vps,
+   u32 *image, u32 width, u32 height,
+   u32 hotspotX, u32 hotspotY)
+{
+   if (vps->cursor.bo != NULL)
+   vmw_cursor_update_mob(dev_priv, vps, image,
+ width, height,
+ hotspotX, hotspotY);
+   else
+   vmw_send_define_cursor_cmd(dev_priv, image, width, height,
+  hotspotX, hotspotY);
+}
+
+
 /**
  * vmw_cursor_update_mob - Update cursor vis CursorMob mechanism
  *
+ * Called from inside vmw_du_cursor_plane_atomic_update to actually
+ * make the cursor-image live.
+ *
  * @dev_priv: device to work with
- * @bo: BO for the MOB
- * @map: kmap obj for the BO
+ * @vps: the plane state of the cursor plane
  * @image: cursor source data to fill the MOB with
  * @width: source data width
  * @height: source data height
@@ -117,8 +144,7 @@ static void vmw_cursor_update_image(struct vmw_private 
*dev_priv,
  * @hotspotY: cursor hotspot Y
  */
 static void vmw_cursor_update_mob(struct vmw_private *dev_priv,
- struct ttm_buffer_object *bo,
- struct ttm_bo_kmap_obj *map,
+ struct vmw_plane_state *vps,
  u32 *image, u32 width, u32 height,
  u32 hotspotX, u32 hotspotY)
 {
@@ -127,11 +153,11 @@ static void vmw_cursor_update_mob(struct vm

[PATCH v2 13/16] drm/vmwgfx: Port the framebuffer code to drm fb helpers

2022-10-19 Thread Zack Rusin
From: Zack Rusin 

Instead of using vmwgfx specific framebuffer implementation use the drm
fb helpers. There's no change in functionality, the only difference
is a reduction in the amount of code inside the vmwgfx module.

drm fb helpers do not deal correctly with changes in crtc preferred mode
at runtime, but the old fb code wasn't dealing with it either.
Same situation applies to high-res fb consoles - the old code was
limited to 1176x885 because it was checking for legacy/deprecated
memory limites, the drm fb helpers are limited to the initial resolution
set on fb due to first problem (drm fb helpers being unable to handle
hotplug crtc preferred mode changes).

This also removes the kernel config for disabling fb support which hasn't
been used or supported in a very long time.

Signed-off-by: Zack Rusin 
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
---
 drivers/gpu/drm/vmwgfx/Kconfig  |   7 -
 drivers/gpu/drm/vmwgfx/Makefile |   2 -
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  58 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  35 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  | 831 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  77 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   7 -
 7 files changed, 26 insertions(+), 991 deletions(-)
 delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c

diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
index a4fabe208d9f..faddae3d6ac2 100644
--- a/drivers/gpu/drm/vmwgfx/Kconfig
+++ b/drivers/gpu/drm/vmwgfx/Kconfig
@@ -16,13 +16,6 @@ config DRM_VMWGFX
  virtual hardware.
  The compiled module will be called "vmwgfx.ko".
 
-config DRM_VMWGFX_FBCON
-   depends on DRM_VMWGFX && DRM_FBDEV_EMULATION
-   bool "Enable framebuffer console under vmwgfx by default"
-   help
-  Choose this option if you are shipping a new vmwgfx
-  userspace driver that supports using the kernel driver.
-
 config DRM_VMWGFX_MKSSTATS
bool "Enable mksGuestStats instrumentation of vmwgfx by default"
depends on DRM_VMWGFX
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 68e350f410ad..2a644f035597 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -12,6 +12,4 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o 
vmwgfx_drv.o \
vmwgfx_devcaps.o ttm_object.o vmwgfx_system_manager.o \
vmwgfx_gem.o
 
-vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
-
 obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index b909a3ce9af3..df7496b74da5 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,9 +53,6 @@
 
 #define VMWGFX_DRIVER_DESC "Linux drm driver for VMware graphics devices"
 
-#define VMW_MIN_INITIAL_WIDTH 800
-#define VMW_MIN_INITIAL_HEIGHT 600
-
 /*
  * Fully encoded drm commands. Might move to vmw_drm.h
  */
@@ -265,7 +263,6 @@ static const struct pci_device_id vmw_pci_id_list[] = {
 };
 MODULE_DEVICE_TABLE(pci, vmw_pci_id_list);
 
-static int enable_fbdev = IS_ENABLED(CONFIG_DRM_VMWGFX_FBCON);
 static int vmw_restrict_iommu;
 static int vmw_force_coherent;
 static int vmw_restrict_dma_mask;
@@ -275,8 +272,6 @@ static int vmw_probe(struct pci_dev *, const struct 
pci_device_id *);
 static int vmwgfx_pm_notifier(struct notifier_block *nb, unsigned long val,
  void *ptr);
 
-MODULE_PARM_DESC(enable_fbdev, "Enable vmwgfx fbdev");
-module_param_named(enable_fbdev, enable_fbdev, int, 0600);
 MODULE_PARM_DESC(restrict_iommu, "Try to limit IOMMU usage for TTM pages");
 module_param_named(restrict_iommu, vmw_restrict_iommu, int, 0600);
 MODULE_PARM_DESC(force_coherent, "Force coherent TTM pages");
@@ -626,8 +621,8 @@ static void vmw_get_initial_size(struct vmw_private 
*dev_priv)
width = vmw_read(dev_priv, SVGA_REG_WIDTH);
height = vmw_read(dev_priv, SVGA_REG_HEIGHT);
 
-   width = max_t(uint32_t, width, VMW_MIN_INITIAL_WIDTH);
-   height = max_t(uint32_t, height, VMW_MIN_INITIAL_HEIGHT);
+   width = max_t(uint32_t, width, VMWGFX_MIN_INITIAL_WIDTH);
+   height = max_t(uint32_t, height, VMWGFX_MIN_INITIAL_HEIGHT);
 
if (width > dev_priv->fb_max_width ||
height > dev_priv->fb_max_height) {
@@ -636,8 +631,8 @@ static void vmw_get_initial_size(struct vmw_private 
*dev_priv)
 * This is a host error and shouldn't occur.
 */
 
-   width = VMW_MIN_INITIAL_WIDTH;
-   height = VMW_MIN_INITIAL_HEIGHT;
+   width  = VMWGFX_MIN_INITIAL_WIDTH;
+   height = VMWGFX_MIN_INITIAL_HEIGHT;
}
 
dev_priv->initial_width = width;
@@ -886,9 +881,6 @@ static int vmw_driver_load(struct vmw_private *dev_priv, 
u32 pci_id)
 
dev_priv->assume_16bpp =

[PATCH v2 04/16] drm/vmwgfx: Remove ttm object hashtable

2022-10-19 Thread Zack Rusin
From: Maaz Mombasawala 

The object_hash hashtable for ttm objects is not being used.
Remove it and perform refactoring in ttm_object init function.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/ttm_object.c | 24 ++--
 drivers/gpu/drm/vmwgfx/ttm_object.h |  6 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  2 +-
 3 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c 
b/drivers/gpu/drm/vmwgfx/ttm_object.c
index 26a55fef1ab5..9546b121bc22 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.c
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 OR MIT */
 /**
  *
- * Copyright (c) 2009-2013 VMware, Inc., Palo Alto, CA., USA
+ * Copyright (c) 2009-2022 VMware, Inc., Palo Alto, CA., USA
  * All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -44,13 +44,14 @@
 
 #define pr_fmt(fmt) "[TTM] " fmt
 
+#include "ttm_object.h"
+#include "vmwgfx_drv.h"
+
 #include 
 #include 
 #include 
 #include 
 #include 
-#include "ttm_object.h"
-#include "vmwgfx_drv.h"
 
 MODULE_IMPORT_NS(DMA_BUF);
 
@@ -81,9 +82,7 @@ struct ttm_object_file {
 /*
  * struct ttm_object_device
  *
- * @object_lock: lock that protects the object_hash hash table.
- *
- * @object_hash: hash table for fast lookup of object global names.
+ * @object_lock: lock that protects idr.
  *
  * @object_count: Per device object count.
  *
@@ -92,7 +91,6 @@ struct ttm_object_file {
 
 struct ttm_object_device {
spinlock_t object_lock;
-   struct vmwgfx_open_hash object_hash;
atomic_t object_count;
struct dma_buf_ops ops;
void (*dmabuf_release)(struct dma_buf *dma_buf);
@@ -449,20 +447,15 @@ struct ttm_object_file *ttm_object_file_init(struct 
ttm_object_device *tdev,
 }
 
 struct ttm_object_device *
-ttm_object_device_init(unsigned int hash_order,
-  const struct dma_buf_ops *ops)
+ttm_object_device_init(const struct dma_buf_ops *ops)
 {
struct ttm_object_device *tdev = kmalloc(sizeof(*tdev), GFP_KERNEL);
-   int ret;
 
if (unlikely(tdev == NULL))
return NULL;
 
spin_lock_init(&tdev->object_lock);
atomic_set(&tdev->object_count, 0);
-   ret = vmwgfx_ht_create(&tdev->object_hash, hash_order);
-   if (ret != 0)
-   goto out_no_object_hash;
 
/*
 * Our base is at VMWGFX_NUM_MOB + 1 because we want to create
@@ -477,10 +470,6 @@ ttm_object_device_init(unsigned int hash_order,
tdev->dmabuf_release = tdev->ops.release;
tdev->ops.release = ttm_prime_dmabuf_release;
return tdev;
-
-out_no_object_hash:
-   kfree(tdev);
-   return NULL;
 }
 
 void ttm_object_device_release(struct ttm_object_device **p_tdev)
@@ -491,7 +480,6 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)
 
WARN_ON_ONCE(!idr_is_empty(&tdev->idr));
idr_destroy(&tdev->idr);
-   vmwgfx_ht_remove(&tdev->object_hash);
 
kfree(tdev);
 }
diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.h 
b/drivers/gpu/drm/vmwgfx/ttm_object.h
index 1a2fa0f83f5f..6870f951b677 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.h
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.h
@@ -1,6 +1,6 @@
 /**
  *
- * Copyright (c) 2006-2009 VMware, Inc., Palo Alto, CA., USA
+ * Copyright (c) 2006-2022 VMware, Inc., Palo Alto, CA., USA
  * All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -262,7 +262,6 @@ extern void ttm_object_file_release(struct ttm_object_file 
**p_tfile);
 /**
  * ttm_object device init - initialize a struct ttm_object_device
  *
- * @hash_order: Order of hash table used to hash the base objects.
  * @ops: DMA buf ops for prime objects of this device.
  *
  * This function is typically called on device initialization to prepare
@@ -270,8 +269,7 @@ extern void ttm_object_file_release(struct ttm_object_file 
**p_tfile);
  */
 
 extern struct ttm_object_device *
-ttm_object_device_init(unsigned int hash_order,
-  const struct dma_buf_ops *ops);
+ttm_object_device_init(const struct dma_buf_ops *ops);
 
 /**
  * ttm_object_device_release - release data held by a ttm_object_device
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 45028e25d490..13b90273eb77 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -994,7 +994,7 @@ static int vmw_driver_load(struct vmw_private *dev_priv, 
u32 pci_id)
goto out_err0;
}
 
-   dev_priv->tdev = ttm_object_device_init(12, &vmw_prime_dmabuf_ops);
+   dev_priv->tdev = ttm_object_device_init(&vmw_prime_dmabuf_ops);

[PATCH v2 02/16] drm/vmwgfx: Fix frame-size warning in vmw_mksstat_add_ioctl

2022-10-19 Thread Zack Rusin
From: Martin Krastev 

Function vmw_mksstat_add_ioctl allocates three big arrays on stack.
That triggers frame-size [-Wframe-larger-than=] warning. Refactor
that function to use kmalloc_array instead.

Signed-off-by: Martin Krastev 
Reviewed-by: Zack Rusin 
Reviewed-by: Maaz Mombasawala 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 39 -
 1 file changed, 27 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 089046fa21be..a6cea35eaa01 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -1023,10 +1023,11 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void 
*data,
long nr_pinned_stat;
long nr_pinned_info;
long nr_pinned_strs;
-   struct page *pages_stat[ARRAY_SIZE(pdesc->statPPNs)];
-   struct page *pages_info[ARRAY_SIZE(pdesc->infoPPNs)];
-   struct page *pages_strs[ARRAY_SIZE(pdesc->strsPPNs)];
+   struct page **pages_stat = NULL;
+   struct page **pages_info = NULL;
+   struct page **pages_strs = NULL;
size_t i, slot;
+   int ret_err = -ENOMEM;
 
arg->id = -1;
 
@@ -1054,13 +1055,23 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void 
*data,
 
BUG_ON(dev_priv->mksstat_user_pages[slot]);
 
+   /* Allocate statically-sized temp arrays for pages -- too big to keep 
in frame */
+   pages_stat = (struct page **)kmalloc_array(
+   ARRAY_SIZE(pdesc->statPPNs) +
+   ARRAY_SIZE(pdesc->infoPPNs) +
+   ARRAY_SIZE(pdesc->strsPPNs), sizeof(*pages_stat), GFP_KERNEL);
+
+   if (!pages_stat)
+   goto err_nomem;
+
+   pages_info = pages_stat + ARRAY_SIZE(pdesc->statPPNs);
+   pages_strs = pages_info + ARRAY_SIZE(pdesc->infoPPNs);
+
/* Allocate a page for the instance descriptor */
page = alloc_page(GFP_KERNEL | __GFP_ZERO);
 
-   if (!page) {
-   atomic_set(&dev_priv->mksstat_user_pids[slot], 0);
-   return -ENOMEM;
-   }
+   if (!page)
+   goto err_nomem;
 
/* Set up the instance descriptor */
pdesc = page_address(page);
@@ -1075,9 +1086,8 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void 
*data,
ARRAY_SIZE(pdesc->description) - 1);
 
if (desc_len < 0) {
-   atomic_set(&dev_priv->mksstat_user_pids[slot], 0);
-   __free_page(page);
-   return -EFAULT;
+   ret_err = -EFAULT;
+   goto err_nomem;
}
 
reset_ppn_array(pdesc->statPPNs, ARRAY_SIZE(pdesc->statPPNs));
@@ -1118,6 +1128,7 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void 
*data,
 
DRM_DEV_INFO(dev->dev, "pid=%d arg.description='%.*s' id=%zu\n", 
current->pid, (int)desc_len, pdesc->description, slot);
 
+   kfree(pages_stat);
return 0;
 
 err_pin_strs:
@@ -1132,9 +1143,13 @@ int vmw_mksstat_add_ioctl(struct drm_device *dev, void 
*data,
if (nr_pinned_stat > 0)
unpin_user_pages(pages_stat, nr_pinned_stat);
 
+err_nomem:
atomic_set(&dev_priv->mksstat_user_pids[slot], 0);
-   __free_page(page);
-   return -ENOMEM;
+   if (page)
+   __free_page(page);
+   kfree(pages_stat);
+
+   return ret_err;
 }
 
 /**
-- 
2.34.1



[PATCH v2 12/16] drm/vmwgfx: Do not allow invalid bpp's for dumb buffers

2022-10-19 Thread Zack Rusin
From: Zack Rusin 

Dumb buffers allow a very limited set of formats. Basically everything
apart from 1, 2 and 4 is expected to return an error. Make vmwgfx
follow those guidelines.

This fixes igt's dumb_buffer invalid_bpp test on vmwgfx.

Signed-off-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 822251aaab0a..d218b15953e0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -807,9 +807,23 @@ int vmw_dumb_create(struct drm_file *file_priv,
 {
struct vmw_private *dev_priv = vmw_priv(dev);
struct vmw_buffer_object *vbo;
+   int cpp = DIV_ROUND_UP(args->bpp, 8);
int ret;
 
-   args->pitch = args->width * ((args->bpp + 7) / 8);
+   switch (cpp) {
+   case 1: /* DRM_FORMAT_C8 */
+   case 2: /* DRM_FORMAT_RGB565 */
+   case 4: /* DRM_FORMAT_XRGB */
+   break;
+   default:
+   /*
+* Dumb buffers don't allow anything else.
+* This is tested via IGT's dumb_buffers
+*/
+   return -EINVAL;
+   }
+
+   args->pitch = args->width * cpp;
args->size = ALIGN(args->pitch * args->height, PAGE_SIZE);
 
ret = vmw_gem_object_create_with_handle(dev_priv, file_priv,
-- 
2.34.1



[PATCH v2 16/16] drm/vmwgfx: Optimize initial sizes of cotables

2022-10-19 Thread Zack Rusin
From: Zack Rusin 

It's important to get the initial size of cotables right because
otherwise every app needs to start with a synchronous cotable resize.

This has an measurable impact on system wide performance but is not
relevant for long running single full screen apps for which the cotable
resizes will happen early in the lifecycle and will continue running
just fine.

To eliminate the initial cotable resizes match the initial sizes to what
the userspace expects. The actual result of the patch is simply setting
the initial size of two of the cotables to a size that will align them
to two pages instead of one.

For a piglit run, before:
name   |  total |  per frame | per sec
vmw_cotable_resize |   1405 |   0.12 |1.58
vmw_execbuf_ioctl  | 290805 |  25.43 |  326.05

After:
name   |  total |  per frame | per sec
vmw_cotable_resize |  4 |   0.00 |0.00
vmw_execbuf_ioctl  | 281673 |  25.10 |  274.68

Signed-off-by: Zack Rusin 
Reviewed-by: Michael Banack 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index a4c30f950d7c..0422b6b89cc1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -73,12 +73,24 @@ struct vmw_cotable_info {
bool);
 };
 
+
+/*
+ * Getting the initial size right is difficult because it all depends
+ * on what the userspace is doing. The sizes will be aligned up to
+ * a PAGE_SIZE so we just want to make sure that for majority of apps
+ * the initial number of entries doesn't require an immediate resize.
+ * For all cotables except SVGACOTableDXElementLayoutEntry and
+ * SVGACOTableDXBlendStateEntry the initial number of entries fits
+ * within the PAGE_SIZE. For SVGACOTableDXElementLayoutEntry and
+ * SVGACOTableDXBlendStateEntry we want to reserve two pages,
+ * because that's what all apps will require initially.
+ */
 static const struct vmw_cotable_info co_info[] = {
{1, sizeof(SVGACOTableDXRTViewEntry), &vmw_view_cotable_list_destroy},
{1, sizeof(SVGACOTableDXDSViewEntry), &vmw_view_cotable_list_destroy},
{1, sizeof(SVGACOTableDXSRViewEntry), &vmw_view_cotable_list_destroy},
-   {1, sizeof(SVGACOTableDXElementLayoutEntry), NULL},
-   {1, sizeof(SVGACOTableDXBlendStateEntry), NULL},
+   {PAGE_SIZE/sizeof(SVGACOTableDXElementLayoutEntry) + 1, 
sizeof(SVGACOTableDXElementLayoutEntry), NULL},
+   {PAGE_SIZE/sizeof(SVGACOTableDXBlendStateEntry) + 1, 
sizeof(SVGACOTableDXBlendStateEntry), NULL},
{1, sizeof(SVGACOTableDXDepthStencilEntry), NULL},
{1, sizeof(SVGACOTableDXRasterizerStateEntry), NULL},
{1, sizeof(SVGACOTableDXSamplerEntry), NULL},
-- 
2.34.1



[PATCH v2 08/16] drm/vmwgfx: Support cursor surfaces with mob cursor

2022-10-19 Thread Zack Rusin
From: Michael Banack 

Add support for cursor surfaces when using mob cursors.

Signed-off-by: Michael Banack 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 78 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |  1 +
 2 files changed, 50 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 464d7c8cd1d6..6c41c5b5a913 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -85,7 +85,7 @@ static void vmw_send_define_cursor_cmd(struct vmw_private 
*dev_priv,
   other fallible KMS-atomic resources at prepare_fb */
cmd = VMW_CMD_RESERVE(dev_priv, cmd_size);
 
-   if (unlikely(cmd == NULL))
+   if (unlikely(!cmd))
return;
 
memset(cmd, 0, sizeof(*cmd));
@@ -117,7 +117,7 @@ static void vmw_cursor_update_image(struct vmw_private 
*dev_priv,
u32 *image, u32 width, u32 height,
u32 hotspotX, u32 hotspotY)
 {
-   if (vps->cursor.bo != NULL)
+   if (vps->cursor.bo)
vmw_cursor_write_mobid(dev_priv, vps);
else
vmw_send_define_cursor_cmd(dev_priv, image, width, height,
@@ -197,7 +197,7 @@ static bool vmw_du_cursor_plane_mob_has_changed(struct 
vmw_plane_state *old_vps,
u32 size;
 
// If either of them aren't using CursorMobs, assume changed.
-   if (old_vps->cursor.bo == NULL || new_vps->cursor.bo == NULL)
+   if (!old_vps->cursor.bo || !new_vps->cursor.bo)
return true;
 
// If either of them failed to map, assume changed.
@@ -222,7 +222,7 @@ static bool vmw_du_cursor_plane_mob_has_changed(struct 
vmw_plane_state *old_vps,
 
 static void vmw_du_destroy_cursor_mob(struct ttm_buffer_object **bo)
 {
-   if (*bo == NULL)
+   if (!(*bo))
return;
 
ttm_bo_unpin(*bo);
@@ -236,14 +236,14 @@ static void vmw_du_put_cursor_mob(struct vmw_cursor_plane 
*vcp,
 {
u32 i;
 
-   if (vps->cursor.bo == NULL)
+   if (!vps->cursor.bo)
return;
 
vmw_du_cursor_plane_unmap_cm(vps);
 
/* Look for a free slot to return this mob to the cache. */
for (i = 0; i < ARRAY_SIZE(vcp->cursor_mobs); i++) {
-   if (vcp->cursor_mobs[i] == NULL) {
+   if (!vcp->cursor_mobs[i]) {
vcp->cursor_mobs[i] = vps->cursor.bo;
vps->cursor.bo = NULL;
return;
@@ -285,7 +285,7 @@ static int vmw_du_get_cursor_mob(struct vmw_cursor_plane 
*vcp,
vps->base.crtc_h > cursor_max_dim)
return -EINVAL;
 
-   if (vps->cursor.bo != NULL) {
+   if (vps->cursor.bo) {
if (vps->cursor.bo->base.size >= size)
return 0;
vmw_du_put_cursor_mob(vcp, vps);
@@ -293,7 +293,7 @@ static int vmw_du_get_cursor_mob(struct vmw_cursor_plane 
*vcp,
 
/* Look for an unused mob in the cache. */
for (i = 0; i < ARRAY_SIZE(vcp->cursor_mobs); i++) {
-   if (vcp->cursor_mobs[i] != NULL &&
+   if (vcp->cursor_mobs[i] &&
vcp->cursor_mobs[i]->base.size >= size) {
vps->cursor.bo = vcp->cursor_mobs[i];
vcp->cursor_mobs[i] = NULL;
@@ -371,7 +371,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
 
cmd = container_of(header, struct vmw_dma_cmd, header);
 
-   /* No snooper installed */
+   /* No snooper installed, nothing to copy */
if (!srf->snooper.image)
return;
 
@@ -471,7 +471,8 @@ void vmw_kms_cursor_post_execbuf(struct vmw_private 
*dev_priv)
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
du = vmw_crtc_to_du(crtc);
if (!du->cursor_surface ||
-   du->cursor_age == du->cursor_surface->snooper.age)
+   du->cursor_age == du->cursor_surface->snooper.age ||
+   !du->cursor_surface->snooper.image)
continue;
 
du->cursor_age = du->cursor_surface->snooper.age;
@@ -567,7 +568,7 @@ vmw_du_cursor_plane_map_cm(struct vmw_plane_state *vps)
u32 size = vmw_du_cursor_mob_size(vps->base.crtc_w, vps->base.crtc_h);
struct ttm_buffer_object *bo = vps->cursor.bo;
 
-   if (bo == NULL)
+   if (!bo)
return -EINVAL;
 
if (bo->base.size < size)
@@ -619,7 +620,7 @@ vmw_du_cursor_plane_unmap_cm(struct vmw_plane_state *vps)
if (!vps->cursor.mapped)
return 0;
 
-   if (bo == NULL)
+   if (!bo)
return 0;
 
ret = ttm_bo_reserve(bo, true, false, NULL);
@@ -651,7 +652,12 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
bool dummy;
 

[PATCH v2 05/16] drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.

2022-10-19 Thread Zack Rusin
From: Maaz Mombasawala 

Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce maintenence burden.
As part of this effort, refactor the res_ht hashtable used for resource
validation during execbuf execution to use linux/hashtable implementation.
This also refactors vmw_validation_context to use vmw_sw_context as the
container for the hashtable, whereas before it used a vmwgfx_open_hash
directly. This makes vmw_validation_context less generic, but there is
no functional change since res_ht is the only instance where validation
context used a hashtable in vmwgfx driver.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Thomas Hellström 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 24 --
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 14 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 55 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_validation.h | 26 +++---
 5 files changed, 58 insertions(+), 66 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 13b90273eb77..8d77e79bd904 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -830,6 +830,22 @@ static void vmw_write_driver_id(struct vmw_private *dev)
}
 }
 
+static void vmw_sw_context_init(struct vmw_private *dev_priv)
+{
+   struct vmw_sw_context *sw_context = &dev_priv->ctx;
+
+   hash_init(sw_context->res_ht);
+}
+
+static void vmw_sw_context_fini(struct vmw_private *dev_priv)
+{
+   struct vmw_sw_context *sw_context = &dev_priv->ctx;
+
+   vfree(sw_context->cmd_bounce);
+   if (sw_context->staged_bindings)
+   vmw_binding_state_free(sw_context->staged_bindings);
+}
+
 static int vmw_driver_load(struct vmw_private *dev_priv, u32 pci_id)
 {
int ret;
@@ -839,6 +855,8 @@ static int vmw_driver_load(struct vmw_private *dev_priv, 
u32 pci_id)
 
dev_priv->drm.dev_private = dev_priv;
 
+   vmw_sw_context_init(dev_priv);
+
mutex_init(&dev_priv->cmdbuf_mutex);
mutex_init(&dev_priv->binding_mutex);
spin_lock_init(&dev_priv->resource_lock);
@@ -1168,9 +1186,7 @@ static void vmw_driver_unload(struct drm_device *dev)
 
unregister_pm_notifier(&dev_priv->pm_nb);
 
-   if (dev_priv->ctx.res_ht_initialized)
-   vmwgfx_ht_remove(&dev_priv->ctx.res_ht);
-   vfree(dev_priv->ctx.cmd_bounce);
+   vmw_sw_context_fini(dev_priv);
if (dev_priv->enable_fb) {
vmw_fb_off(dev_priv);
vmw_fb_close(dev_priv);
@@ -1198,8 +1214,6 @@ static void vmw_driver_unload(struct drm_device *dev)
vmw_irq_uninstall(&dev_priv->drm);
 
ttm_object_device_release(&dev_priv->tdev);
-   if (dev_priv->ctx.staged_bindings)
-   vmw_binding_state_free(dev_priv->ctx.staged_bindings);
 
for (i = vmw_res_context; i < vmw_res_max; ++i)
idr_destroy(&dev_priv->res_idr[i]);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 09e2d738aa87..d87aeedb78d0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -30,6 +30,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -93,6 +94,7 @@
 #define VMW_RES_STREAM ttm_driver_type2
 #define VMW_RES_FENCE ttm_driver_type3
 #define VMW_RES_SHADER ttm_driver_type4
+#define VMW_RES_HT_ORDER 12
 
 #define MKSSTAT_CAPACITY_LOG2 5U
 #define MKSSTAT_CAPACITY (1U << MKSSTAT_CAPACITY_LOG2)
@@ -425,8 +427,7 @@ struct vmw_ctx_validation_info;
  * @ctx: The validation context
  */
 struct vmw_sw_context{
-   struct vmwgfx_open_hash res_ht;
-   bool res_ht_initialized;
+   DECLARE_HASHTABLE(res_ht, VMW_RES_HT_ORDER);
bool kernel;
struct vmw_fpriv *fp;
struct drm_file *filp;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index f085dbd4736d..c943ab801ca7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0 OR MIT
 /**
  *
- * Copyright 2009 - 2015 VMware, Inc., Palo Alto, CA., USA
+ * Copyright 2009 - 2022 VMware, Inc., Palo Alto, CA., USA
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the
@@ -25,6 +25,7 @@
  *
  **/
 #include 
+#include 
 
 #include "vmwgfx_drv.h"
 #include "vmwgfx_reg.h"
@@ -34,7 +35,6 @@
 #include "vmwgfx_binding.h"
 #include "vmwgfx_mksstat.h"
 
-#define VMW_RES_HT_ORDER 12
 
 /*
  * Helper macro to get dx_ctx_node if available otherwise print an error
@@ -4101,7 +4101,7 @@ int vmw_execbuf_process(struct drm_file *file_priv,
 

[PATCH v2 07/16] drm/vmwgfx: Start diffing new mob cursors against old ones

2022-10-19 Thread Zack Rusin
From: Michael Banack 

Avoid making the SVGA device do extra work if the new cursor image
matches the old one.

Signed-off-by: Michael Banack 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 95 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 12 ++--
 2 files changed, 81 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 07d55d610e4c..464d7c8cd1d6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -52,11 +52,9 @@ void vmw_du_cleanup(struct vmw_display_unit *du)
  * Display Unit Cursor functions
  */
 
-static void vmw_cursor_update_mob(struct vmw_private *dev_priv,
- struct vmw_plane_state *vps,
- u32 *image, u32 width, u32 height,
- u32 hotspotX, u32 hotspotY);
 static int vmw_du_cursor_plane_unmap_cm(struct vmw_plane_state *vps);
+static void vmw_cursor_write_mobid(struct vmw_private *dev_priv,
+  struct vmw_plane_state *vps);
 
 struct vmw_svga_fifo_cmd_define_cursor {
u32 cmd;
@@ -120,9 +118,7 @@ static void vmw_cursor_update_image(struct vmw_private 
*dev_priv,
u32 hotspotX, u32 hotspotY)
 {
if (vps->cursor.bo != NULL)
-   vmw_cursor_update_mob(dev_priv, vps, image,
- width, height,
- hotspotX, hotspotY);
+   vmw_cursor_write_mobid(dev_priv, vps);
else
vmw_send_define_cursor_cmd(dev_priv, image, width, height,
   hotspotX, hotspotY);
@@ -167,6 +163,21 @@ static void vmw_cursor_update_mob(struct vmw_private 
*dev_priv,
alpha_header->height = height;
 
memcpy(header + 1, image, image_size);
+}
+
+
+/**
+ * vmw_cursor_write_mobid - Update cursor via CursorMob mechanism
+ *
+ * Called from inside vmw_du_cursor_plane_atomic_update to actually
+ * make the cursor-image live.
+ *
+ * @dev_priv: device to work with
+ * @vps: DRM plane_state
+ */
+static void vmw_cursor_write_mobid(struct vmw_private *dev_priv,
+  struct vmw_plane_state *vps)
+{
vmw_write(dev_priv, SVGA_REG_CURSOR_MOBID,
  vps->cursor.bo->resource->start);
 }
@@ -176,6 +187,39 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
return w * h * sizeof(u32) + sizeof(SVGAGBCursorHeader);
 }
 
+
+static bool vmw_du_cursor_plane_mob_has_changed(struct vmw_plane_state 
*old_vps,
+   struct vmw_plane_state *new_vps)
+{
+   void *old_mob;
+   void *new_mob;
+   bool dummy;
+   u32 size;
+
+   // If either of them aren't using CursorMobs, assume changed.
+   if (old_vps->cursor.bo == NULL || new_vps->cursor.bo == NULL)
+   return true;
+
+   // If either of them failed to map, assume changed.
+   if (!old_vps->cursor.mapped || !new_vps->cursor.mapped)
+   return true;
+
+   if (old_vps->base.crtc_w != new_vps->base.crtc_w ||
+   old_vps->base.crtc_h != new_vps->base.crtc_h)
+   return true;
+
+   size = vmw_du_cursor_mob_size(new_vps->base.crtc_w,
+ new_vps->base.crtc_h);
+
+   old_mob = ttm_kmap_obj_virtual(&old_vps->cursor.map, &dummy);
+   new_mob = ttm_kmap_obj_virtual(&new_vps->cursor.map, &dummy);
+
+   if (memcmp(old_mob, new_mob, size) != 0)
+   return true;
+
+   return false;
+}
+
 static void vmw_du_destroy_cursor_mob(struct ttm_buffer_object **bo)
 {
if (*bo == NULL)
@@ -716,9 +760,10 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane *plane,
struct vmw_private *dev_priv = vmw_priv(crtc->dev);
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
struct vmw_plane_state *vps = vmw_plane_state_to_vps(new_state);
+   struct vmw_plane_state *old_vps = vmw_plane_state_to_vps(old_state);
s32 hotspot_x, hotspot_y;
-   void *virtual;
bool dummy;
+   void *image;
 
hotspot_x = du->hotspot_x;
hotspot_y = du->hotspot_y;
@@ -738,23 +783,32 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane *plane,
 
if (vps->surf != NULL) {
du->cursor_age = du->cursor_surface->snooper.age;
+   image = vps->surf->snooper.image;
+   } else
+   image = ttm_kmap_obj_virtual(&vps->bo->map, &dummy);
 
-   vmw_cursor_update_image(dev_priv, vps,
-   vps->surf->snooper.image,
+   if (vps->cursor.bo != NULL)
+   vmw_cursor_update_mob(dev_priv, vps, image,
+ new_state->crtc_w,
+ new_state->crtc_h,
+ hotspot_x, hotspot_y);
+
+ 

[PATCH v2 14/16] drm/vmwgfx: Remove explicit and broken vblank handling

2022-10-19 Thread Zack Rusin
From: Zack Rusin 

The explicit vblank handling was never finished. The driver never had
the full implementation of vblank and what was there is emulated
by DRM when the driver doesn't pretend to be implementing it itself.

Let DRM handle the vblank emulation and stop pretending the driver is
doing anything special with vblank. In the future it would make sense
to implement helpers for full vblank handling because vkms and
amdgpu_vkms already have that code. Exporting it to common helpers and
having all three drivers share it would make sense (that would be largely
just to allow more of igt to run).

Signed-off-by: Zack Rusin 
Reviewed-by: Maaz Mombasawala 
Reviewed-by: Martin Krastev 
Reviewed-by: Michael Banack 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  3 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 34 
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |  8 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 31 +
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 26 -
 5 files changed, 1 insertion(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index ad470e54d586..4eb7339dd121 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1208,9 +1208,6 @@ int vmw_kms_write_svga(struct vmw_private *vmw_priv,
 bool vmw_kms_validate_mode_vram(struct vmw_private *dev_priv,
uint32_t pitch,
uint32_t height);
-u32 vmw_get_vblank_counter(struct drm_crtc *crtc);
-int vmw_enable_vblank(struct drm_crtc *crtc);
-void vmw_disable_vblank(struct drm_crtc *crtc);
 int vmw_kms_present(struct vmw_private *dev_priv,
struct drm_file *file_priv,
struct vmw_framebuffer *vfb,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3153e3b4c8fc..36c98ba3c87e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "vmwgfx_kms.h"
 
@@ -981,15 +980,6 @@ void vmw_du_crtc_atomic_begin(struct drm_crtc *crtc,
 void vmw_du_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_atomic_state *state)
 {
-   struct drm_pending_vblank_event *event = crtc->state->event;
-
-   if (event) {
-   crtc->state->event = NULL;
-
-   spin_lock_irq(&crtc->dev->event_lock);
-   drm_crtc_send_vblank_event(crtc, event);
-   spin_unlock_irq(&crtc->dev->event_lock);
-   }
 }
 
 
@@ -2305,30 +2295,6 @@ bool vmw_kms_validate_mode_vram(struct vmw_private 
*dev_priv,
 dev_priv->max_primary_mem : dev_priv->vram_size);
 }
 
-
-/*
- * Function called by DRM code called with vbl_lock held.
- */
-u32 vmw_get_vblank_counter(struct drm_crtc *crtc)
-{
-   return 0;
-}
-
-/*
- * Function called by DRM code called with vbl_lock held.
- */
-int vmw_enable_vblank(struct drm_crtc *crtc)
-{
-   return -EINVAL;
-}
-
-/*
- * Function called by DRM code called with vbl_lock held.
- */
-void vmw_disable_vblank(struct drm_crtc *crtc)
-{
-}
-
 /**
  * vmw_du_update_layout - Update the display unit with topology from resolution
  * plugin and generate DRM uevent
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index b8761f16dd78..a56e5d0ca3c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "vmwgfx_kms.h"
 
@@ -235,9 +234,6 @@ static const struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
.atomic_duplicate_state = vmw_du_crtc_duplicate_state,
.atomic_destroy_state = vmw_du_crtc_destroy_state,
.set_config = drm_atomic_helper_set_config,
-   .get_vblank_counter = vmw_get_vblank_counter,
-   .enable_vblank = vmw_enable_vblank,
-   .disable_vblank = vmw_disable_vblank,
 };
 
 
@@ -507,10 +503,6 @@ int vmw_kms_ldu_init_display(struct vmw_private *dev_priv)
dev_priv->ldu_priv->last_num_active = 0;
dev_priv->ldu_priv->fb = NULL;
 
-   ret = drm_vblank_init(dev, num_display_units);
-   if (ret != 0)
-   goto err_free;
-
vmw_kms_create_implicit_placement_property(dev_priv);
 
for (i = 0; i < num_display_units; ++i) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index ecd3c2fc978b..8db61c541a80 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "vmwgfx_kms.h"
 
@@ -320,9 +319,6 @@ static const struct drm_crtc_funcs 
vmw_screen_object_crtc_funcs = {
.atomic_destroy_state = vmw_du_crtc_destroy_state,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_f

[PATCH v2 09/16] drm/vmwgfx: Diff cursors when using cmds

2022-10-19 Thread Zack Rusin
From: Michael Banack 

Extend the cursor diffing support to support the command-path.

Signed-off-by: Michael Banack 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 120 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   2 +
 2 files changed, 62 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 6c41c5b5a913..ff79668ad334 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -53,8 +53,10 @@ void vmw_du_cleanup(struct vmw_display_unit *du)
  */
 
 static int vmw_du_cursor_plane_unmap_cm(struct vmw_plane_state *vps);
-static void vmw_cursor_write_mobid(struct vmw_private *dev_priv,
-  struct vmw_plane_state *vps);
+static void vmw_cursor_update_mob(struct vmw_private *dev_priv,
+ struct vmw_plane_state *vps,
+ u32 *image, u32 width, u32 height,
+ u32 hotspotX, u32 hotspotY);
 
 struct vmw_svga_fifo_cmd_define_cursor {
u32 cmd;
@@ -118,7 +120,10 @@ static void vmw_cursor_update_image(struct vmw_private 
*dev_priv,
u32 hotspotX, u32 hotspotY)
 {
if (vps->cursor.bo)
-   vmw_cursor_write_mobid(dev_priv, vps);
+   vmw_cursor_update_mob(dev_priv, vps, image,
+ vps->base.crtc_w, vps->base.crtc_h,
+ hotspotX, hotspotY);
+
else
vmw_send_define_cursor_cmd(dev_priv, image, width, height,
   hotspotX, hotspotY);
@@ -163,61 +168,58 @@ static void vmw_cursor_update_mob(struct vmw_private 
*dev_priv,
alpha_header->height = height;
 
memcpy(header + 1, image, image_size);
-}
-
-
-/**
- * vmw_cursor_write_mobid - Update cursor via CursorMob mechanism
- *
- * Called from inside vmw_du_cursor_plane_atomic_update to actually
- * make the cursor-image live.
- *
- * @dev_priv: device to work with
- * @vps: DRM plane_state
- */
-static void vmw_cursor_write_mobid(struct vmw_private *dev_priv,
-  struct vmw_plane_state *vps)
-{
vmw_write(dev_priv, SVGA_REG_CURSOR_MOBID,
  vps->cursor.bo->resource->start);
 }
 
+
 static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
 {
return w * h * sizeof(u32) + sizeof(SVGAGBCursorHeader);
 }
 
-
-static bool vmw_du_cursor_plane_mob_has_changed(struct vmw_plane_state 
*old_vps,
-   struct vmw_plane_state *new_vps)
+/**
+ * vmw_du_cursor_plane_acquire_image -- Acquire the image data
+ * @vps: cursor plane state
+ */
+static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
 {
-   void *old_mob;
-   void *new_mob;
bool dummy;
-   u32 size;
-
-   // If either of them aren't using CursorMobs, assume changed.
-   if (!old_vps->cursor.bo || !new_vps->cursor.bo)
-   return true;
+   if (vps->surf) {
+   if (vps->surf_mapped)
+   return vmw_bo_map_and_cache(vps->surf->res.backup);
+   return vps->surf->snooper.image;
+   } else if (vps->bo)
+   return ttm_kmap_obj_virtual(&vps->bo->map, &dummy);
+   return NULL;
+}
 
-   // If either of them failed to map, assume changed.
-   if (!old_vps->cursor.mapped || !new_vps->cursor.mapped)
-   return true;
+static bool vmw_du_cursor_plane_has_changed(struct vmw_plane_state *old_vps,
+   struct vmw_plane_state *new_vps)
+{
+   void *old_image;
+   void *new_image;
+   u32 size;
+   bool changed;
 
if (old_vps->base.crtc_w != new_vps->base.crtc_w ||
old_vps->base.crtc_h != new_vps->base.crtc_h)
return true;
 
-   size = vmw_du_cursor_mob_size(new_vps->base.crtc_w,
- new_vps->base.crtc_h);
+   if (old_vps->cursor.hotspot_x != new_vps->cursor.hotspot_x ||
+   old_vps->cursor.hotspot_y != new_vps->cursor.hotspot_y)
+   return true;
 
-   old_mob = ttm_kmap_obj_virtual(&old_vps->cursor.map, &dummy);
-   new_mob = ttm_kmap_obj_virtual(&new_vps->cursor.map, &dummy);
+   size = new_vps->base.crtc_w * new_vps->base.crtc_h * sizeof(u32);
 
-   if (memcmp(old_mob, new_mob, size) != 0)
-   return true;
+   old_image = vmw_du_cursor_plane_acquire_image(old_vps);
+   new_image = vmw_du_cursor_plane_acquire_image(new_vps);
 
-   return false;
+   changed = false;
+   if (old_image && new_image)
+   changed = memcmp(old_image, new_image, size) != 0;
+
+   return changed;
 }
 
 static void vmw_du_destroy_cursor_mob(struct ttm_buffer_object **bo)
@@ -745,6 +747,7 @@ vmw_du_cursor_plane_prepare_fb(struct drm_plane *plane,
   

[PATCH v2 10/16] drm/vmwgfx: Refactor ttm reference object hashtable to use linux/hashtable.

2022-10-19 Thread Zack Rusin
From: Maaz Mombasawala 

This is part of an effort to move from the vmwgfx_open_hash hashtable to
linux/hashtable implementation.
Refactor the ref_hash hashtable, used for fast lookup of reference objects
associated with a ttm file.
This also exposed a problem related to inconsistently using 32-bit and
64-bit keys with this hashtable. The hash function used changes depending
on the size of the type, and results are not consistent across numbers,
for example, hash_32(329) = 329, but hash_long(329) = 328. This would
cause the lookup to fail for objects already in the hashtable, since keys
of different sizes were being passed during adding and lookup. This was
not an issue before because vmwgfx_open_hash always used hash_long.
Fix this by always using 64-bit keys for this hashtable, which means that
hash_long is always used.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Zack Rusin 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/ttm_object.c | 91 -
 drivers/gpu/drm/vmwgfx/ttm_object.h | 12 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  2 +-
 3 files changed, 56 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/ttm_object.c 
b/drivers/gpu/drm/vmwgfx/ttm_object.c
index 9546b121bc22..c07b81fbc495 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_object.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_object.c
@@ -52,9 +52,12 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_IMPORT_NS(DMA_BUF);
 
+#define VMW_TTM_OBJECT_REF_HT_ORDER 10
+
 /**
  * struct ttm_object_file
  *
@@ -75,7 +78,7 @@ struct ttm_object_file {
struct ttm_object_device *tdev;
spinlock_t lock;
struct list_head ref_list;
-   struct vmwgfx_open_hash ref_hash;
+   DECLARE_HASHTABLE(ref_hash, VMW_TTM_OBJECT_REF_HT_ORDER);
struct kref refcount;
 };
 
@@ -136,6 +139,36 @@ ttm_object_file_ref(struct ttm_object_file *tfile)
return tfile;
 }
 
+static int ttm_tfile_find_ref_rcu(struct ttm_object_file *tfile,
+ uint64_t key,
+ struct vmwgfx_hash_item **p_hash)
+{
+   struct vmwgfx_hash_item *hash;
+
+   hash_for_each_possible_rcu(tfile->ref_hash, hash, head, key) {
+   if (hash->key == key) {
+   *p_hash = hash;
+   return 0;
+   }
+   }
+   return -EINVAL;
+}
+
+static int ttm_tfile_find_ref(struct ttm_object_file *tfile,
+ uint64_t key,
+ struct vmwgfx_hash_item **p_hash)
+{
+   struct vmwgfx_hash_item *hash;
+
+   hash_for_each_possible(tfile->ref_hash, hash, head, key) {
+   if (hash->key == key) {
+   *p_hash = hash;
+   return 0;
+   }
+   }
+   return -EINVAL;
+}
+
 static void ttm_object_file_destroy(struct kref *kref)
 {
struct ttm_object_file *tfile =
@@ -238,14 +271,13 @@ void ttm_base_object_unref(struct ttm_base_object 
**p_base)
  * Return: A pointer to the object if successful or NULL otherwise.
  */
 struct ttm_base_object *
-ttm_base_object_noref_lookup(struct ttm_object_file *tfile, uint32_t key)
+ttm_base_object_noref_lookup(struct ttm_object_file *tfile, uint64_t key)
 {
struct vmwgfx_hash_item *hash;
-   struct vmwgfx_open_hash *ht = &tfile->ref_hash;
int ret;
 
rcu_read_lock();
-   ret = vmwgfx_ht_find_item_rcu(ht, key, &hash);
+   ret = ttm_tfile_find_ref_rcu(tfile, key, &hash);
if (ret) {
rcu_read_unlock();
return NULL;
@@ -257,15 +289,14 @@ ttm_base_object_noref_lookup(struct ttm_object_file 
*tfile, uint32_t key)
 EXPORT_SYMBOL(ttm_base_object_noref_lookup);
 
 struct ttm_base_object *ttm_base_object_lookup(struct ttm_object_file *tfile,
-  uint32_t key)
+  uint64_t key)
 {
struct ttm_base_object *base = NULL;
struct vmwgfx_hash_item *hash;
-   struct vmwgfx_open_hash *ht = &tfile->ref_hash;
int ret;
 
rcu_read_lock();
-   ret = vmwgfx_ht_find_item_rcu(ht, key, &hash);
+   ret = ttm_tfile_find_ref_rcu(tfile, key, &hash);
 
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_ref_object, hash)->obj;
@@ -278,7 +309,7 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
 }
 
 struct ttm_base_object *
-ttm_base_object_lookup_for_ref(struct ttm_object_device *tdev, uint32_t key)
+ttm_base_object_lookup_for_ref(struct ttm_object_device *tdev, uint64_t key)
 {
struct ttm_base_object *base;
 
@@ -297,7 +328,6 @@ int ttm_ref_object_add(struct ttm_object_file *tfile,
   bool *existed,
   bool require_existed)
 {
-   struct vmwgfx_open_hash *ht = &tfile->ref_hash;
struct ttm_ref_object *ref;
struct vmwgfx_hash_item *hash;
int ret = -E

[PATCH v2 03/16] drm/vmwgfx: Refactor resource manager's hashtable to use linux/hashtable implementation.

2022-10-19 Thread Zack Rusin
From: Maaz Mombasawala 

Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce maintenance burden.
Refactor cmdbuf resource manager to use linux/hashtable.h implementation
as part of this effort.

Signed-off-by: Maaz Mombasawala 
Reviewed-by: Zack Rusin 
Reviewed-by: Martin Krastev 
Signed-off-by: Zack Rusin 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c | 62 +-
 1 file changed, 26 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
index 82ef58ccdd42..142aef686fcd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c
@@ -1,7 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0 OR MIT
 /**
  *
- * Copyright 2014-2015 VMware, Inc., Palo Alto, CA., USA
+ * Copyright 2014-2022 VMware, Inc., Palo Alto, CA., USA
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the
@@ -28,6 +28,8 @@
 #include "vmwgfx_drv.h"
 #include "vmwgfx_resource_priv.h"
 
+#include 
+
 #define VMW_CMDBUF_RES_MAN_HT_ORDER 12
 
 /**
@@ -59,7 +61,7 @@ struct vmw_cmdbuf_res {
  * @resources and @list are protected by the cmdbuf mutex for now.
  */
 struct vmw_cmdbuf_res_manager {
-   struct vmwgfx_open_hash resources;
+   DECLARE_HASHTABLE(resources, VMW_CMDBUF_RES_MAN_HT_ORDER);
struct list_head list;
struct vmw_private *dev_priv;
 };
@@ -82,14 +84,13 @@ vmw_cmdbuf_res_lookup(struct vmw_cmdbuf_res_manager *man,
  u32 user_key)
 {
struct vmwgfx_hash_item *hash;
-   int ret;
unsigned long key = user_key | (res_type << 24);
 
-   ret = vmwgfx_ht_find_item(&man->resources, key, &hash);
-   if (unlikely(ret != 0))
-   return ERR_PTR(ret);
-
-   return drm_hash_entry(hash, struct vmw_cmdbuf_res, hash)->res;
+   hash_for_each_possible_rcu(man->resources, hash, head, key) {
+   if (hash->key == key)
+   return drm_hash_entry(hash, struct vmw_cmdbuf_res, 
hash)->res;
+   }
+   return ERR_PTR(-EINVAL);
 }
 
 /**
@@ -105,7 +106,7 @@ static void vmw_cmdbuf_res_free(struct 
vmw_cmdbuf_res_manager *man,
struct vmw_cmdbuf_res *entry)
 {
list_del(&entry->head);
-   WARN_ON(vmwgfx_ht_remove_item(&man->resources, &entry->hash));
+   hash_del_rcu(&entry->hash.head);
vmw_resource_unreference(&entry->res);
kfree(entry);
 }
@@ -159,7 +160,6 @@ void vmw_cmdbuf_res_commit(struct list_head *list)
 void vmw_cmdbuf_res_revert(struct list_head *list)
 {
struct vmw_cmdbuf_res *entry, *next;
-   int ret;
 
list_for_each_entry_safe(entry, next, list, head) {
switch (entry->state) {
@@ -167,8 +167,8 @@ void vmw_cmdbuf_res_revert(struct list_head *list)
vmw_cmdbuf_res_free(entry->man, entry);
break;
case VMW_CMDBUF_RES_DEL:
-   ret = vmwgfx_ht_insert_item(&entry->man->resources, 
&entry->hash);
-   BUG_ON(ret);
+   hash_add_rcu(entry->man->resources, &entry->hash.head,
+   entry->hash.key);
list_move_tail(&entry->head, &entry->man->list);
entry->state = VMW_CMDBUF_RES_COMMITTED;
break;
@@ -199,26 +199,20 @@ int vmw_cmdbuf_res_add(struct vmw_cmdbuf_res_manager *man,
   struct list_head *list)
 {
struct vmw_cmdbuf_res *cres;
-   int ret;
 
cres = kzalloc(sizeof(*cres), GFP_KERNEL);
if (unlikely(!cres))
return -ENOMEM;
 
cres->hash.key = user_key | (res_type << 24);
-   ret = vmwgfx_ht_insert_item(&man->resources, &cres->hash);
-   if (unlikely(ret != 0)) {
-   kfree(cres);
-   goto out_invalid_key;
-   }
+   hash_add_rcu(man->resources, &cres->hash.head, cres->hash.key);
 
cres->state = VMW_CMDBUF_RES_ADD;
cres->res = vmw_resource_reference(res);
cres->man = man;
list_add_tail(&cres->head, list);
 
-out_invalid_key:
-   return ret;
+   return 0;
 }
 
 /**
@@ -243,24 +237,26 @@ int vmw_cmdbuf_res_remove(struct vmw_cmdbuf_res_manager 
*man,
  struct list_head *list,
  struct vmw_resource **res_p)
 {
-   struct vmw_cmdbuf_res *entry;
+   struct vmw_cmdbuf_res *entry = NULL;
struct vmwgfx_hash_item *hash;
-   int ret;
+   unsigned long key = user_key | (res_type << 24);
 
-   ret = vmwgfx_ht_find_item(&man->resources, user_key | (res_type << 24),
-  &hash);
-   if (likely(ret != 0))
+   hash_for_each_possible_rcu(man->resour

[PATCH v2 15/16] drm/vmwgfx: Add a mksstat counter for cotable resizes

2022-10-19 Thread Zack Rusin
From: Zack Rusin 

There's been a lot of cotable resizes on startup which we can track
by adding a mks stat to measure both the invocation count and
time spent doing cotable resizes.

This is only used if kernel is configured with CONFIG_DRM_VMWGFX_MKSSTATS
The stats are collected on the host size inside the vmware-stats.log
file.

Signed-off-by: Zack Rusin 
Reviewed-by: Michael Banack 
Reviewed-by: Martin Krastev 
Reviewed-by: Maaz Mombasawala 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 13 +++--
 drivers/gpu/drm/vmwgfx/vmwgfx_mksstat.h |  2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 16 +---
 3 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index 79b30dc9d825..a4c30f950d7c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -33,6 +33,7 @@
 #include 
 
 #include "vmwgfx_drv.h"
+#include "vmwgfx_mksstat.h"
 #include "vmwgfx_resource_priv.h"
 #include "vmwgfx_so.h"
 
@@ -395,9 +396,12 @@ static int vmw_cotable_resize(struct vmw_resource *res, 
size_t new_size)
int ret;
size_t i;
 
+   MKS_STAT_TIME_DECL(MKSSTAT_KERN_COTABLE_RESIZE);
+   MKS_STAT_TIME_PUSH(MKSSTAT_KERN_COTABLE_RESIZE);
+
ret = vmw_cotable_readback(res);
if (ret)
-   return ret;
+   goto out_done;
 
cur_size_read_back = vcotbl->size_read_back;
vcotbl->size_read_back = old_size_read_back;
@@ -411,7 +415,7 @@ static int vmw_cotable_resize(struct vmw_resource *res, 
size_t new_size)
true, true, vmw_bo_bo_free, &buf);
if (ret) {
DRM_ERROR("Failed initializing new cotable MOB.\n");
-   return ret;
+   goto out_done;
}
 
bo = &buf->base;
@@ -485,6 +489,8 @@ static int vmw_cotable_resize(struct vmw_resource *res, 
size_t new_size)
/* Release the pin acquired in vmw_bo_init */
ttm_bo_unpin(bo);
 
+   MKS_STAT_TIME_POP(MKSSTAT_KERN_COTABLE_RESIZE);
+
return 0;
 
 out_map_new:
@@ -494,6 +500,9 @@ static int vmw_cotable_resize(struct vmw_resource *res, 
size_t new_size)
ttm_bo_unreserve(bo);
vmw_bo_unreference(&buf);
 
+out_done:
+   MKS_STAT_TIME_POP(MKSSTAT_KERN_COTABLE_RESIZE);
+
return ret;
 }
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_mksstat.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_mksstat.h
index 0509f55f07b4..ede74c7fdbbf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_mksstat.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_mksstat.h
@@ -29,6 +29,7 @@
 #define _VMWGFX_MKSSTAT_H_
 
 #include 
+#include 
 
 /* Reservation marker for mksstat pid's */
 #define MKSSTAT_PID_RESERVED -1
@@ -41,6 +42,7 @@
 
 typedef enum {
MKSSTAT_KERN_EXECBUF, /* vmw_execbuf_ioctl */
+   MKSSTAT_KERN_COTABLE_RESIZE,
 
MKSSTAT_KERN_COUNT /* Reserved entry; always last */
 } mksstat_kern_stats_t;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index a6cea35eaa01..8700d038d74d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -85,7 +85,14 @@ struct rpc_channel {
u32 cookie_low;
 };
 
-
+#if IS_ENABLED(CONFIG_DRM_VMWGFX_MKSSTATS)
+/* Kernel mksGuestStats counter names and desciptions; same order as enum 
mksstat_kern_stats_t */
+static const char* const mksstat_kern_name_desc[MKSSTAT_KERN_COUNT][2] =
+{
+   { "vmw_execbuf_ioctl", "vmw_execbuf_ioctl" },
+   { "vmw_cotable_resize", "vmw_cotable_resize" },
+};
+#endif
 
 /**
  * vmw_open_channel
@@ -695,12 +702,6 @@ static inline void hypervisor_ppn_remove(PPN64 pfn)
 /* Header to the text description of mksGuestStat instance descriptor */
 #define MKSSTAT_KERNEL_DESCRIPTION "vmwgfx"
 
-/* Kernel mksGuestStats counter names and desciptions; same order as enum 
mksstat_kern_stats_t */
-static const char* const mksstat_kern_name_desc[MKSSTAT_KERN_COUNT][2] =
-{
-   { "vmw_execbuf_ioctl", "vmw_execbuf_ioctl" },
-};
-
 /**
  * mksstat_init_record: Initializes an MKSGuestStatCounter-based record
  * for the respective mksGuestStat index.
@@ -786,6 +787,7 @@ static int mksstat_init_kern_id(struct page **ppage)
/* Set up all kernel-internal counters and corresponding structures */
pstrs_acc = pstrs;
pstrs_acc = mksstat_init_record_time(MKSSTAT_KERN_EXECBUF, pstat, 
pinfo, pstrs_acc);
+   pstrs_acc = mksstat_init_record_time(MKSSTAT_KERN_COTABLE_RESIZE, 
pstat, pinfo, pstrs_acc);
 
/* Add new counters above, in their order of appearance in 
mksstat_kern_stats_t */
 
-- 
2.34.1



[PATCH v2 00/16] drm/vmwgfx: fb, cursors and hashtable refactor

2022-10-19 Thread Zack Rusin
From: Zack Rusin 

v2: Fix LKP and sparse reported issues

This is a bit larger series than usual but these are all connected in
various ways. The most important changes around everything is centered
include:
- finally getting rid of vmwgfx_hashtab and porting the driver to 
  linux/hashtable
- cleaning up the cursor mob handling, which fixes a bunch of cursor
  issues on kde configs
- removing vmwgfx fb code and porting it to drm fb helpers
- removing vmwgfx faked vblank handling

The rest is largely support code to make the transition easier (with some
igt fixes to get more of it running for regression testing). The result
is removal of over 1000loc with no loss in functionality.

Maaz Mombasawala (5):
  drm/vmwgfx: Refactor resource manager's hashtable to use
linux/hashtable implementation.
  drm/vmwgfx: Remove ttm object hashtable
  drm/vmwgfx: Refactor resource validation hashtable to use
linux/hashtable implementation.
  drm/vmwgfx: Refactor ttm reference object hashtable to use
linux/hashtable.
  drm/vmwgfx : Remove vmwgfx_hashtab

Martin Krastev (1):
  drm/vmwgfx: Fix frame-size warning in vmw_mksstat_add_ioctl

Michael Banack (4):
  drm/vmwgfx: Clean up cursor mobs
  drm/vmwgfx: Start diffing new mob cursors against old ones
  drm/vmwgfx: Support cursor surfaces with mob cursor
  drm/vmwgfx: Diff cursors when using cmds

Zack Rusin (6):
  drm/vmwgfx: Write the driver id registers
  drm/vmwgfx: Do not allow invalid bpp's for dumb buffers
  drm/vmwgfx: Port the framebuffer code to drm fb helpers
  drm/vmwgfx: Remove explicit and broken vblank handling
  drm/vmwgfx: Add a mksstat counter for cotable resizes
  drm/vmwgfx: Optimize initial sizes of cotables

 Documentation/gpu/todo.rst |  11 -
 drivers/gpu/drm/vmwgfx/Kconfig |   7 -
 drivers/gpu/drm/vmwgfx/Makefile|   4 +-
 drivers/gpu/drm/vmwgfx/ttm_object.c| 123 ++-
 drivers/gpu/drm/vmwgfx/ttm_object.h|  20 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c |  16 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c |  62 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c|  29 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 129 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  49 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c|  14 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 831 -
 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.c| 199 -
 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.h|  83 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 639 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h|  31 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c|   8 -
 drivers/gpu/drm/vmwgfx/vmwgfx_mksstat.h|   2 +
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c|  55 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c   |  31 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   |  26 -
 drivers/gpu/drm/vmwgfx/vmwgfx_validation.c |  55 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_validation.h |  26 +-
 23 files changed, 650 insertions(+), 1800 deletions(-)
 delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
 delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.c
 delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_hashtab.h

-- 
2.34.1



Re: [drm/gem] 79e2cf2e7a: WARNING:at_drivers/gpu/drm/drm_gem.c:#drm_gem_vunmap

2022-10-19 Thread Dmitry Osipenko
On 10/20/22 06:23, kernel test robot wrote:
> Greeting,
> 
> FYI, we noticed WARNING:at_drivers/gpu/drm/drm_gem.c:#drm_gem_vunmap due to 
> commit (built with clang-14):
> 
> commit: 79e2cf2e7a193473dfb0da3b9b869682b43dc60f ("drm/gem: Take reservation 
> lock for vmap/vunmap operations")
> git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> 
> in testcase: boot
> 
> on test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):
> 
> 
> [5.483437][T1] [ cut here ]
> [5.484265][T1] WARNING: CPU: 1 PID: 1 at 
> drivers/gpu/drm/drm_gem.c:1191 drm_gem_vunmap+0x50/0xa0
> [5.485640][T1] Modules linked in:
> [5.486298][T1] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
> 6.0.0-rc2-00895-g79e2cf2e7a19 #1 d064e7e3c98977ac595341fa8e33617722110e67
> [5.488083][T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
> BIOS 1.16.0-debian-1.16.0-4 04/01/2014
> [5.489590][T1] EIP: drm_gem_vunmap+0x50/0xa0
> [5.490359][T1] Code: ff ff e8 f3 29 97 00 85 c0 0f 94 c3 eb 02 31 db 
> 0f b6 fb b8 90 74 8e c3 89 fa 31 c9 6a 00 e8 77 ca 7b ff 83 c4 04 84 db 74 02 
> <0f> 0b b8 a8 74 8e c3 89 fa 31 c9 6a 00 e8 5e ca 7b ff 83 c4 04 83
> [5.493049][T1] EAX: c38e74a0 EBX: ff01 ECX:  EDX: 0001
> [5.494179][T1] ESI: c6d8b870 EDI: 0001 EBP: c46d7d34 ESP: c46d7d24
> [5.495296][T1] DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068 EFLAGS: 
> 00010202
> [5.496530][T1] CR0: 80050033 CR2:  CR3: 03aa CR4: 000406d0
> [5.497647][T1] DR0:  DR1:  DR2:  DR3: 
> [5.498759][T1] DR6: fffe0ff0 DR7: 0400
> [5.499486][T1] Call Trace:
> [5.500104][T1]  drm_client_buffer_delete+0x1d/0x90
> [5.500877][T1]  drm_client_framebuffer_delete+0x37/0x60
> [5.501805][T1]  drm_fbdev_cleanup+0x80/0x90
> [5.502653][T1]  drm_fbdev_client_hotplug+0x1b6/0x210
> [5.503585][T1]  drm_fbdev_generic_setup+0x143/0x1a0
> [5.504571][T1]  vkms_init+0x23f/0x244
> [5.505338][T1]  ? vgem_init+0x133/0x133
> [5.506130][T1]  do_one_initcall+0x10e/0x210
> [5.506976][T1]  ? vgem_init+0x133/0x133
> [5.507775][T1]  do_initcall_level+0x80/0x92
> [5.508630][T1]  do_initcalls+0x41/0x6f
> [5.509386][T1]  do_basic_setup+0x17/0x19
> [5.510106][T1]  kernel_init_freeable+0xb4/0xe5
> [5.510970][T1]  ? rest_init+0x180/0x180
> [5.511745][T1]  kernel_init+0x17/0x180
> [5.512522][T1]  ret_from_fork+0x19/0x24
> [5.51][T1] irq event stamp: 118087
> [5.514101][T1] hardirqs last  enabled at (118097): [] 
> __up_console_sem+0x64/0xb0
> [5.515620][T1] hardirqs last disabled at (118110): [] 
> __up_console_sem+0x4b/0xb0
> [5.517061][T1] softirqs last  enabled at (117834): [] 
> __do_softirq+0x2c6/0x329
> [5.518391][T1] softirqs last disabled at (117825): [] 
> do_softirq_own_stack+0x22/0x30
> [5.519760][T1] ---[ end trace  ]---

That's a good catch, I missed to touch drm_client.c. At a quick glance
will be fine to switch it to the unlocked drm_gem_vun/map functions.

-- 
Best regards,
Dmitry



[PATCH v3] drm/i915/slpc: Optmize waitboost for SLPC

2022-10-19 Thread Vinay Belgaumkar
Waitboost (when SLPC is enabled) results in a H2G message. This can result
in thousands of messages during a stress test and fill up an already full
CTB. There is no need to request for RP0 if GuC is already requesting the
same.

v2: Add the tracing back, and check requested freq
in the worker thread (Tvrtko)
v3: Check requested freq in dec_waiters as well

Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/intel_rps.c |  3 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 14 +++---
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fc23c562d9b2..18b75cf08d1b 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1016,6 +1016,9 @@ void intel_rps_boost(struct i915_request *rq)
if (rps_uses_slpc(rps)) {
slpc = rps_to_slpc(rps);
 
+   GT_TRACE(rps_to_gt(rps), "boost fence:%llx:%llx\n",
+rq->fence.context, rq->fence.seqno);
+
/* Return if old value is non zero */
if (!atomic_fetch_inc(&slpc->num_waiters))
schedule_work(&slpc->boost_work);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index b7cdeec44bd3..9dbdbab1515a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -227,14 +227,19 @@ static int slpc_force_min_freq(struct intel_guc_slpc 
*slpc, u32 freq)
 static void slpc_boost_work(struct work_struct *work)
 {
struct intel_guc_slpc *slpc = container_of(work, typeof(*slpc), 
boost_work);
+   struct intel_rps *rps = &slpc_to_gt(slpc)->rps;
int err;
 
/*
 * Raise min freq to boost. It's possible that
 * this is greater than current max. But it will
 * certainly be limited by RP0. An error setting
-* the min param is not fatal.
+* the min param is not fatal. No need to boost
+* if we are already requesting it.
 */
+   if (intel_rps_get_requested_frequency(rps) == slpc->boost_freq)
+   return;
+
mutex_lock(&slpc->lock);
if (atomic_read(&slpc->num_waiters)) {
err = slpc_force_min_freq(slpc, slpc->boost_freq);
@@ -728,6 +733,7 @@ int intel_guc_slpc_set_boost_freq(struct intel_guc_slpc 
*slpc, u32 val)
 
 void intel_guc_slpc_dec_waiters(struct intel_guc_slpc *slpc)
 {
+   struct intel_rps *rps = &slpc_to_gt(slpc)->rps;
/*
 * Return min back to the softlimit.
 * This is called during request retire,
@@ -735,8 +741,10 @@ void intel_guc_slpc_dec_waiters(struct intel_guc_slpc 
*slpc)
 * set_param fails.
 */
mutex_lock(&slpc->lock);
-   if (atomic_dec_and_test(&slpc->num_waiters))
-   slpc_force_min_freq(slpc, slpc->min_freq_softlimit);
+   if (atomic_dec_and_test(&slpc->num_waiters)) {
+   if (intel_rps_get_requested_frequency(rps) != 
slpc->min_freq_softlimit)
+   slpc_force_min_freq(slpc, slpc->min_freq_softlimit);
+   }
mutex_unlock(&slpc->lock);
 }
 
-- 
2.35.1



Re: [PATCH v2] drm/i915/slpc: Optmize waitboost for SLPC

2022-10-19 Thread Belgaumkar, Vinay



On 10/19/2022 4:05 PM, Vinay Belgaumkar wrote:

Waitboost (when SLPC is enabled) results in a H2G message. This can result
in thousands of messages during a stress test and fill up an already full
CTB. There is no need to request for RP0 if GuC is already requesting the
same.

v2: Add the tracing back, and check requested freq
in the worker thread (Tvrtko)

Signed-off-by: Vinay Belgaumkar 
---
  drivers/gpu/drm/i915/gt/intel_rps.c | 3 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 7 ++-
  2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fc23c562d9b2..18b75cf08d1b 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1016,6 +1016,9 @@ void intel_rps_boost(struct i915_request *rq)
if (rps_uses_slpc(rps)) {
slpc = rps_to_slpc(rps);
  
+			GT_TRACE(rps_to_gt(rps), "boost fence:%llx:%llx\n",

+rq->fence.context, rq->fence.seqno);
+
/* Return if old value is non zero */
if (!atomic_fetch_inc(&slpc->num_waiters))


The issue when we move the req freq check into the slpc_work is that we 
are incrementing num_waiters. That will trigger a de-boost and result in 
a H2G. Need to check the req frequency there as well.


Thanks,

Vinay.


schedule_work(&slpc->boost_work);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index b7cdeec44bd3..7ab96221be7e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -227,14 +227,19 @@ static int slpc_force_min_freq(struct intel_guc_slpc 
*slpc, u32 freq)
  static void slpc_boost_work(struct work_struct *work)
  {
struct intel_guc_slpc *slpc = container_of(work, typeof(*slpc), 
boost_work);
+   struct intel_rps *rps = &slpc_to_gt(slpc)->rps;
int err;
  
  	/*

 * Raise min freq to boost. It's possible that
 * this is greater than current max. But it will
 * certainly be limited by RP0. An error setting
-* the min param is not fatal.
+* the min param is not fatal. No need to boost
+* if we are already requesting it.
 */
+   if (intel_rps_get_requested_frequency(rps) == slpc->boost_freq)
+   return;
+
mutex_lock(&slpc->lock);
if (atomic_read(&slpc->num_waiters)) {
err = slpc_force_min_freq(slpc, slpc->boost_freq);


[PATCH 2/2] drm/rockchip: dsi: Force synchronous probe

2022-10-19 Thread Brian Norris
We can't safely probe a dual-DSI display asynchronously
(driver_async_probe='*' or driver_async_probe='dw-mipi-dsi-rockchip'
cmdline), because dw_mipi_dsi_rockchip_find_second() pokes one DSI
device's drvdata from the other device without any locking.

Request synchronous probe, at least until this driver learns some
appropriate locking for dual-DSI initialization.

Cc: 
Signed-off-by: Brian Norris 
---

 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index d222c6811207..528ddce144e5 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1689,5 +1689,11 @@ struct platform_driver dw_mipi_dsi_rockchip_driver = {
.of_match_table = dw_mipi_dsi_rockchip_dt_ids,
.pm = &dw_mipi_dsi_rockchip_pm_ops,
.name   = "dw-mipi-dsi-rockchip",
+   /*
+* For dual-DSI display, one DSI pokes at the other DSI's
+* drvdata in dw_mipi_dsi_rockchip_find_second(). This is not
+* safe for asynchronous probe.
+*/
+   .probe_type = PROBE_FORCE_SYNCHRONOUS,
},
 };
-- 
2.38.0.413.g74048e4d9e-goog



[PATCH 1/2] drm/rockchip: dsi: Clean up 'usage_mode' when failing to attach

2022-10-19 Thread Brian Norris
If we fail to attach the first time (especially: EPROBE_DEFER), we fail
to clean up 'usage_mode', and thus will fail to attach on any subsequent
attempts, with "dsi controller already in use".

Re-set to DW_DSI_USAGE_IDLE on attach failure.

This is especially common to hit when enabling asynchronous probe on a
duel-DSI system (such as RK3399 Gru/Scarlet), such that we're more
likely to fail dw_mipi_dsi_rockchip_find_second() the first time.

Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead 
of full dsi")
Cc: 
Signed-off-by: Brian Norris 
---

 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
index bf6948125b84..d222c6811207 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
@@ -1051,23 +1051,31 @@ static int dw_mipi_dsi_rockchip_host_attach(void 
*priv_data,
if (ret) {
DRM_DEV_ERROR(dsi->dev, "Failed to register component: %d\n",
ret);
-   return ret;
+   goto out;
}
 
second = dw_mipi_dsi_rockchip_find_second(dsi);
-   if (IS_ERR(second))
-   return PTR_ERR(second);
+   if (IS_ERR(second)) {
+   ret = PTR_ERR(second);
+   goto out;
+   }
if (second) {
ret = component_add(second, &dw_mipi_dsi_rockchip_ops);
if (ret) {
DRM_DEV_ERROR(second,
  "Failed to register component: %d\n",
  ret);
-   return ret;
+   goto out;
}
}
 
return 0;
+
+out:
+   mutex_lock(&dsi->usage_mutex);
+   dsi->usage_mode = DW_DSI_USAGE_IDLE;
+   mutex_unlock(&dsi->usage_mutex);
+   return ret;
 }
 
 static int dw_mipi_dsi_rockchip_host_detach(void *priv_data,
-- 
2.38.0.413.g74048e4d9e-goog



Re: [PATCH 2/4] drm/i915/mtl: Modify CAGF functions for MTL

2022-10-19 Thread Dixit, Ashutosh
On Wed, 19 Oct 2022 07:58:13 -0700, Rodrigo Vivi wrote:
>
> On Tue, Oct 18, 2022 at 10:20:41PM -0700, Ashutosh Dixit wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
> > b/drivers/gpu/drm/i915/gt/intel_rps.c
> > index df21258976d86..5a743ae4dd11e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rps.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_rps.c
> > @@ -2093,7 +2093,9 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 
> > rpstat)
> > struct drm_i915_private *i915 = rps_to_i915(rps);
> > u32 cagf;
> >
> > -   if (GRAPHICS_VER(i915) >= 12)
> > +   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
> > +   cagf = rpstat & MTL_CAGF_MASK;
>
> I believe we should advocate more the use of the REG_FIELD_GET
>
>   cagf = REG_FIELD_GET(MTL_CAGF_MASK, rpstat);
>
> > +   else if (GRAPHICS_VER(i915) >= 12)
> > cagf = (rpstat & GEN12_CAGF_MASK) >> GEN12_CAGF_SHIFT;
>
> cagf = REG_FIELD_GET(GEN12_CAGF_MASK, rpstat);
> // witht the proper REG_GENAMSK usage on the gen12_cagf_mask...
>
> > else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> > cagf = (rpstat >> 8) & 0xff;
>
>  #define RPE_MASK REG_GENMASK(15, 8)
>  cagf = REG_FIELD_GET(RPE_MASK, rpstat)

All these are now converted to REG_FIELD_GET in series version v8.

> > @@ -2116,7 +2118,13 @@ static u32 read_cagf(struct intel_rps *rps)
> > struct intel_uncore *uncore = rps_to_uncore(rps);
> ^
>
> > u32 freq;
> >
> > -   if (GRAPHICS_VER(i915) >= 12) {
> > +   /*
> > +* For Gen12+ reading freq from HW does not need a forcewake and
> > +* registers will return 0 freq when GT is in RC6
> > +*/
> > +   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
> > +   freq = intel_uncore_read(rps_to_gt(rps)->uncore, 
> > MTL_MIRROR_TARGET_WP1);
>
> here we should use directly the local uncore already declared above with
> the same helper...  and consistent with the following elses...

Fixed.

>
> > +   } else if (GRAPHICS_VER(i915) >= 12) {
> > freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
> > } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
> > vlv_punit_get(i915);
> > --
> > 2.38.0
> >

Thanks.
--
Ashutosh


Re: [PATCH 1/4] drm/i915: Use GEN12_RPSTAT register for GT freq

2022-10-19 Thread Dixit, Ashutosh
On Wed, 19 Oct 2022 08:06:26 -0700, Rodrigo Vivi wrote:
>

Hi Rodrigo,

> On Tue, Oct 18, 2022 at 10:20:40PM -0700, Ashutosh Dixit wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
> > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index 36d95b79022c0..a7a0129d0e3fc 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -1543,6 +1543,8 @@
> >
> >  #define GEN12_RPSTAT1  _MMIO(0x1381b4)
> >  #define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
> > +#define   GEN12_CAGF_SHIFT 11
>
> we don't need to define the shift if we use the REG_FIELD_GET

Yes I was also suggesting this but then went ahead with the mask/shift
based code to match previous style in the function.

In any case based on your suggestions I have added a new patch is series
version v8 which converts all previous branches in intel_rps_get_cagf to
REG_FIELD_GET so that the new code can also consistently use REG_FIELD_GET.

>
> > +#define   GEN12_CAGF_MASK  REG_GENMASK(19, 11)
>
> ah, cool, this is already right and in place
> (ignore my comment about this in the other patch)

> >  u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
> >  {
> > struct drm_i915_private *i915 = rps_to_i915(rps);
> > u32 cagf;
> >
> > -   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> > +   if (GRAPHICS_VER(i915) >= 12)
> > +   cagf = (rpstat & GEN12_CAGF_MASK) >> GEN12_CAGF_SHIFT;
>
>   cagf = REG_FIELD_GET(GEN12_CAGF_MASK, rpstat);
>
> > +   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
> > cagf = (rpstat >> 8) & 0xff;
> > else if (GRAPHICS_VER(i915) >= 9)
> > cagf = (rpstat & GEN9_CAGF_MASK) >> GEN9_CAGF_SHIFT;

Thanks.
--
Ashutosh


Re: [PATCH 3/3] drm/i915/mtl: C6 residency and C state type for MTL SAMedia

2022-10-19 Thread Dixit, Ashutosh
On Mon, 17 Oct 2022 13:12:33 -0700, Dixit, Ashutosh wrote:
>
> On Fri, 14 Oct 2022 20:26:18 -0700, Ashutosh Dixit wrote:
> >
> > From: Badal Nilawar 
>
> Hi Badal,
>
> One question below.
>
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > index 1fb053cbf52db..3a9bb4387248e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> > @@ -256,6 +256,61 @@ static int ilk_drpc(struct seq_file *m)
> > return 0;
> >  }
> >
> > +static int mtl_drpc(struct seq_file *m)
> > +{
>
> Here we have:
>
> > +   global_forcewake = intel_uncore_read(uncore, FORCEWAKE_GT_GEN9);
> and
> > +   seq_printf(m, "Global Forcewake Requests: 0x%x\n", global_forcewake);
>
> In gen6_drpc we have:
>
>   mt_fwake_req = intel_uncore_read_fw(uncore, FORCEWAKE_MT);
> and
>   seq_printf(m, "Multi-threaded Forcewake Request: 0x%x\n", mt_fwake_req);
>
> Also:
>   #define FORCEWAKE_MT_MMIO(0xa188)
>   #define FORCEWAKE_GT_GEN9   _MMIO(0xa188)
>
> So they are both the same register. So what is the reason for this
> difference, which one should we use?
>
> Also let's have the prints in the same order as gen6_drpc (move fw request
> before rc6 residency).

This has been made identical to gen6_drpc in series v8.

Thanks.
--
Ashutosh


Re: [PATCH 3/4] drm/i915/gt: Use RC6 residency types as arguments to residency functions

2022-10-19 Thread Dixit, Ashutosh
On Wed, 19 Oct 2022 00:51:45 -0700, Jani Nikula wrote:
>
> On Tue, 18 Oct 2022, Ashutosh Dixit  wrote:
> > diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h 
> > b/drivers/gpu/drm/i915/gt/intel_rc6.h
> > index b6fea71afc223..3105bc72c096b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_rc6.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_rc6.h
> > @@ -6,7 +6,7 @@
> >  #ifndef INTEL_RC6_H
> >  #define INTEL_RC6_H
> >
> > -#include "i915_reg_defs.h"
> > +#include "intel_rc6_types.h"
> >
> >  struct intel_engine_cs;
> >  struct intel_rc6;
> > @@ -21,7 +21,9 @@ void intel_rc6_sanitize(struct intel_rc6 *rc6);
> >  void intel_rc6_enable(struct intel_rc6 *rc6);
> >  void intel_rc6_disable(struct intel_rc6 *rc6);
> >
> > -u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, i915_reg_t reg);
> > -u64 intel_rc6_residency_us(struct intel_rc6 *rc6, i915_reg_t reg);
> > +u64 intel_rc6_residency_ns(struct intel_rc6 *rc6, enum intel_rc6_res_type 
> > id);
> > +u64 intel_rc6_residency_us(struct intel_rc6 *rc6, enum intel_rc6_res_type 
> > id);
> > +void intel_rc6_print_residency(struct seq_file *m, const char *title,
> > +  enum intel_rc6_res_type id);
> >
> >  #endif /* INTEL_RC6_H */
>
> Please apply this on top to avoid includes from includes.
>
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h 
> b/drivers/gpu/drm/i915/gt/intel_rc6.h
> index 3105bc72c096..456fa668a276 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rc6.h
> +++ b/drivers/gpu/drm/i915/gt/intel_rc6.h
> @@ -6,10 +6,11 @@
>  #ifndef INTEL_RC6_H
>  #define INTEL_RC6_H
>
> -#include "intel_rc6_types.h"
> +#include 
>
> -struct intel_engine_cs;
> +enum intel_rc6_res_type;
>  struct intel_rc6;
> +struct seq_file;
>
>  void intel_rc6_init(struct intel_rc6 *rc6);
>  void intel_rc6_fini(struct intel_rc6 *rc6);

Thanks, done in series version v8.

Ashutosh


[PATCH 1/5] drm/i915/rps: Prefer REG_FIELD_GET in intel_rps_get_cagf

2022-10-19 Thread Ashutosh Dixit
Instead of masks/shifts settle on REG_FIELD_GET as the standard way to
extract reg fields. This allows future patches touching this code to also
consistently use REG_FIELD_GET and friends.

Suggested-by: Rodrigo Vivi 
Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 12 
 drivers/gpu/drm/i915/gt/intel_rps.c   | 11 +--
 3 files changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 40d0a3be42acf..979e602946549 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -307,7 +307,7 @@ void intel_gt_pm_frequency_dump(struct intel_gt *gt, struct 
drm_printer *p)
drm_printf(p, "Current VID: %d\n", (rgvstat & MEMSTAT_VID_MASK) 
>>
   MEMSTAT_VID_SHIFT);
drm_printf(p, "Current P-state: %d\n",
-  (rgvstat & MEMSTAT_PSTATE_MASK) >> 
MEMSTAT_PSTATE_SHIFT);
+  REG_FIELD_GET(MEMSTAT_PSTATE_MASK, rgvstat));
} else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
u32 rpmodectl, freq_sts;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 36d95b79022c0..35c039573294c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -794,12 +794,9 @@
 #define GEN6_RP_DOWN_TIMEOUT   _MMIO(0xa010)
 #define GEN6_RP_INTERRUPT_LIMITS   _MMIO(0xa014)
 #define GEN6_RPSTAT1   _MMIO(0xa01c)
-#define   GEN6_CAGF_SHIFT  8
-#define   HSW_CAGF_SHIFT   7
-#define   GEN9_CAGF_SHIFT  23
-#define   GEN6_CAGF_MASK   (0x7f << GEN6_CAGF_SHIFT)
-#define   HSW_CAGF_MASK(0x7f << HSW_CAGF_SHIFT)
-#define   GEN9_CAGF_MASK   (0x1ff << GEN9_CAGF_SHIFT)
+#define   GEN6_CAGF_MASK   REG_GENMASK(14, 8)
+#define   HSW_CAGF_MASKREG_GENMASK(13, 7)
+#define   GEN9_CAGF_MASK   REG_GENMASK(31, 23)
 #define GEN6_RP_CONTROL_MMIO(0xa024)
 #define   GEN6_RP_MEDIA_TURBO  (1 << 11)
 #define   GEN6_RP_MEDIA_MODE_MASK  (3 << 9)
@@ -1370,8 +1367,7 @@
 #define MEMSTAT_ILK_MMIO(0x111f8)
 #define   MEMSTAT_VID_MASK 0x7f00
 #define   MEMSTAT_VID_SHIFT8
-#define   MEMSTAT_PSTATE_MASK  0x00f8
-#define   MEMSTAT_PSTATE_SHIFT 3
+#define   MEMSTAT_PSTATE_MASK  REG_GENMASK(7, 3)
 #define   MEMSTAT_MON_ACTV (1 << 2)
 #define   MEMSTAT_SRC_CTL_MASK 0x0003
 #define   MEMSTAT_SRC_CTL_CORE 0
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fc23c562d9b2a..5bd6671554a6e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2074,16 +2074,15 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 
rpstat)
u32 cagf;
 
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
-   cagf = (rpstat >> 8) & 0xff;
+   cagf = REG_FIELD_GET(RPE_MASK, rpstat);
else if (GRAPHICS_VER(i915) >= 9)
-   cagf = (rpstat & GEN9_CAGF_MASK) >> GEN9_CAGF_SHIFT;
+   cagf = REG_FIELD_GET(GEN9_CAGF_MASK, rpstat);
else if (IS_HASWELL(i915) || IS_BROADWELL(i915))
-   cagf = (rpstat & HSW_CAGF_MASK) >> HSW_CAGF_SHIFT;
+   cagf = REG_FIELD_GET(HSW_CAGF_MASK, rpstat);
else if (GRAPHICS_VER(i915) >= 6)
-   cagf = (rpstat & GEN6_CAGF_MASK) >> GEN6_CAGF_SHIFT;
+   cagf = REG_FIELD_GET(GEN6_CAGF_MASK, rpstat);
else
-   cagf = gen5_invert_freq(rps, (rpstat & MEMSTAT_PSTATE_MASK) >>
-   MEMSTAT_PSTATE_SHIFT);
+   cagf = gen5_invert_freq(rps, REG_FIELD_GET(MEMSTAT_PSTATE_MASK, 
rpstat));
 
return cagf;
 }
-- 
2.38.0



[PATCH 5/5] drm/i915/mtl: C6 residency and C state type for MTL SAMedia

2022-10-19 Thread Ashutosh Dixit
From: Badal Nilawar 

Add support for C6 residency and C state type for MTL SAMedia. Also add
mtl_drpc.

v2: Fixed review comments (Ashutosh)
v3: Sort registers and fix whitespace errors in intel_gt_regs.h (Matt R)
Remove MTL_CC_SHIFT (Ashutosh)
Adapt to RC6 residency register code refactor (Jani N)
v4: Move MTL branch to top in drpc_show
v5: Use FORCEWAKE_MT identical to gen6_drpc (Ashutosh)

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 58 ++-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  5 ++
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 17 --
 3 files changed, 75 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 5d6b346831393..f15a7486a9866 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -256,6 +256,60 @@ static int ilk_drpc(struct seq_file *m)
return 0;
 }
 
+static int mtl_drpc(struct seq_file *m)
+{
+   struct intel_gt *gt = m->private;
+   struct intel_uncore *uncore = gt->uncore;
+   u32 gt_core_status, rcctl1, mt_fwake_req;
+   u32 mtl_powergate_enable = 0, mtl_powergate_status = 0;
+
+   mt_fwake_req = intel_uncore_read_fw(uncore, FORCEWAKE_MT);
+   gt_core_status = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
+
+   rcctl1 = intel_uncore_read(uncore, GEN6_RC_CONTROL);
+   mtl_powergate_enable = intel_uncore_read(uncore, GEN9_PG_ENABLE);
+   mtl_powergate_status = intel_uncore_read(uncore,
+GEN9_PWRGT_DOMAIN_STATUS);
+
+   seq_printf(m, "RC6 Enabled: %s\n",
+  str_yes_no(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
+   if (gt->type == GT_MEDIA) {
+   seq_printf(m, "Media Well Gating Enabled: %s\n",
+  str_yes_no(mtl_powergate_enable & 
GEN9_MEDIA_PG_ENABLE));
+   } else {
+   seq_printf(m, "Render Well Gating Enabled: %s\n",
+  str_yes_no(mtl_powergate_enable & 
GEN9_RENDER_PG_ENABLE));
+   }
+
+   seq_puts(m, "Current RC state: ");
+   switch (REG_FIELD_GET(MTL_CC_MASK, gt_core_status)) {
+   case MTL_CC0:
+   seq_puts(m, "on\n");
+   break;
+   case MTL_CC6:
+   seq_puts(m, "RC6\n");
+   break;
+   default:
+   seq_puts(m, "Unknown\n");
+   break;
+   }
+
+   seq_printf(m, "Multi-threaded Forcewake Request: 0x%x\n", mt_fwake_req);
+   if (gt->type == GT_MEDIA)
+   seq_printf(m, "Media Power Well: %s\n",
+  (mtl_powergate_status &
+   GEN9_PWRGT_MEDIA_STATUS_MASK) ? "Up" : "Down");
+   else
+   seq_printf(m, "Render Power Well: %s\n",
+  (mtl_powergate_status &
+   GEN9_PWRGT_RENDER_STATUS_MASK) ? "Up" : "Down");
+
+   /* Works for both render and media gt's */
+   intel_rc6_print_residency(m, "RC6 residency since boot:", 
INTEL_RC6_RES_RC6);
+
+   return fw_domains_show(m, NULL);
+}
+
 static int drpc_show(struct seq_file *m, void *unused)
 {
struct intel_gt *gt = m->private;
@@ -264,7 +318,9 @@ static int drpc_show(struct seq_file *m, void *unused)
int err = -ENODEV;
 
with_intel_runtime_pm(gt->uncore->rpm, wakeref) {
-   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   err = mtl_drpc(m);
+   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
err = vlv_drpc(m);
else if (GRAPHICS_VER(i915) >= 6)
err = gen6_drpc(m);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index d8dbd0ac3b064..a0ddaf243593c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -24,6 +24,9 @@
 /* MTL workpoint reg to get core C state and actual freq of 3D, SAMedia */
 #define MTL_MIRROR_TARGET_WP1  _MMIO(0xc60)
 #define   MTL_CAGF_MASKREG_GENMASK(8, 0)
+#define   MTL_CC0  0x0
+#define   MTL_CC6  0x3
+#define   MTL_CC_MASK  REG_GENMASK(12, 9)
 
 /* RPM unit config (Gen8+) */
 #define RPM_CONFIG0_MMIO(0xd00)
@@ -1512,6 +1515,8 @@
 #define FORCEWAKE_MEDIA_VLV_MMIO(0x1300b8)
 #define FORCEWAKE_ACK_MEDIA_VLV_MMIO(0x1300bc)
 
+#define MTL_MEDIA_MC6  _MMIO(0x138048)
+
 #define GEN6_GT_THREAD_STATUS_REG  _MMIO(0x13805c)
 #define   GEN6_GT_THREAD_STATUS_CORE_MASK  0x7
 
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c 
b/dri

[PATCH 4/5] drm/i915/gt: Use RC6 residency types as arguments to residency functions

2022-10-19 Thread Ashutosh Dixit
Previously RC6 residency functions directly accepted RC6 residency register
MMIO offsets (there are four RC6 residency registers). This worked but
required an assumption on the residency register layout so was not future
proof.

Therefore change RC6 residency functions to accept RC6 residency types
instead of register MMIO offsets. The knowledge of register offsets as well
as ID to offset mapping is now maintained solely in intel_rc6 and can be
tailored for different platforms and different register layouts as need
arises.

v2: Address review comments by Jani N
- Change residency functions to accept RC6 residency types instead of
  register ID's
- s/intel_rc6_print_rc5_res/intel_rc6_print_residency/
- Remove "const enum" in function arguments
- Naming: intel_rc6_* for enum
- Use INTEL_RC6_RES_MAX and other minor changes
v3: Don't include intel_rc6_types.h in intel_rc6.h (Jani)

Suggested-by: Rodrigo Vivi 
Suggested-by: Jani Nikula 
Reported-by: Jani Nikula 
Signed-off-by: Ashutosh Dixit 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 27 +++--
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 12 ++--
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 55 +++
 drivers/gpu/drm/i915/gt/intel_rc6.h   | 11 ++--
 drivers/gpu/drm/i915/gt/intel_rc6_types.h | 15 -
 drivers/gpu/drm/i915/gt/selftest_rc6.c|  6 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  6 +-
 7 files changed, 72 insertions(+), 60 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 979e602946549..5d6b346831393 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -83,19 +83,6 @@ static int fw_domains_show(struct seq_file *m, void *data)
 }
 DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(fw_domains);
 
-static void print_rc6_res(struct seq_file *m,
- const char *title,
- const i915_reg_t reg)
-{
-   struct intel_gt *gt = m->private;
-   intel_wakeref_t wakeref;
-
-   with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-   seq_printf(m, "%s %u (%llu us)\n", title,
-  intel_uncore_read(gt->uncore, reg),
-  intel_rc6_residency_us(>->rc6, reg));
-}
-
 static int vlv_drpc(struct seq_file *m)
 {
struct intel_gt *gt = m->private;
@@ -115,8 +102,8 @@ static int vlv_drpc(struct seq_file *m)
seq_printf(m, "Media Power Well: %s\n",
   (pw_status & VLV_GTLC_PW_MEDIA_STATUS_MASK) ? "Up" : "Down");
 
-   print_rc6_res(m, "Render RC6 residency since boot:", GEN6_GT_GFX_RC6);
-   print_rc6_res(m, "Media RC6 residency since boot:", VLV_GT_MEDIA_RC6);
+   intel_rc6_print_residency(m, "Render RC6 residency since boot:", 
INTEL_RC6_RES_RC6);
+   intel_rc6_print_residency(m, "Media RC6 residency since boot:", 
INTEL_RC6_RES_VLV_MEDIA);
 
return fw_domains_show(m, NULL);
 }
@@ -192,11 +179,11 @@ static int gen6_drpc(struct seq_file *m)
}
 
/* Not exactly sure what this is */
-   print_rc6_res(m, "RC6 \"Locked to RPn\" residency since boot:",
- GEN6_GT_GFX_RC6_LOCKED);
-   print_rc6_res(m, "RC6 residency since boot:", GEN6_GT_GFX_RC6);
-   print_rc6_res(m, "RC6+ residency since boot:", GEN6_GT_GFX_RC6p);
-   print_rc6_res(m, "RC6++ residency since boot:", GEN6_GT_GFX_RC6pp);
+   intel_rc6_print_residency(m, "RC6 \"Locked to RPn\" residency since 
boot:",
+ INTEL_RC6_RES_RC6_LOCKED);
+   intel_rc6_print_residency(m, "RC6 residency since boot:", 
INTEL_RC6_RES_RC6);
+   intel_rc6_print_residency(m, "RC6+ residency since boot:", 
INTEL_RC6_RES_RC6p);
+   intel_rc6_print_residency(m, "RC6++ residency since boot:", 
INTEL_RC6_RES_RC6pp);
 
if (GRAPHICS_VER(i915) <= 7) {
seq_printf(m, "RC6   voltage: %dmV\n",
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 9041609523697..19a6e052c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -93,13 +93,13 @@ sysfs_gt_attribute_r_func(struct device *dev, struct 
device_attribute *attr,
sysfs_gt_attribute_r_func(d, a, f, INTEL_GT_SYSFS_MAX)
 
 #ifdef CONFIG_PM
-static u32 get_residency(struct intel_gt *gt, i915_reg_t reg)
+static u32 get_residency(struct intel_gt *gt, enum intel_rc6_res_type id)
 {
intel_wakeref_t wakeref;
u64 res = 0;
 
with_intel_runtime_pm(gt->uncore->rpm, wakeref)
-   res = intel_rc6_residency_us(>->rc6, reg);
+   res = intel_rc6_residency_us(>->rc6, id);
 
return DIV_ROUND_CLOSEST_ULL(res, 1000);
 }
@@ -123,7 +123,7 @@ static ssize_t rc6_enable_show(struct device *dev,
 
 static u32 __rc6_residency_ms_show(struct intel_gt *gt)
 {
-   retu

[PATCH 2/5] drm/i915: Use GEN12_RPSTAT register for GT freq

2022-10-19 Thread Ashutosh Dixit
From: Don Hiatt 

On GEN12+ use GEN12_RPSTAT register to get actual resolved GT
freq. GEN12_RPSTAT does not require a forcewake and will return 0 freq if
GT is in RC6.

v2:
  - Fixed review comments(Ashutosh)
  - Added function intel_rps_read_rpstat_fw to read RPSTAT without
forcewake, required especially for GEN6_RPSTAT1 (Ashutosh, Tvrtko)
v3:
  - Updated commit title and message for more clarity (Ashutosh)
  - Replaced intel_rps_read_rpstat with direct read to GEN12_RPSTAT1 in
read_cagf (Ashutosh)
v4: Remove GEN12_CAGF_SHIFT and use REG_FIELD_GET (Rodrigo)

Cc: Don Hiatt 
Cc: Andi Shyti 
Signed-off-by: Don Hiatt 
Signed-off-by: Badal Nilawar 
Signed-off-by: Ashutosh Dixit 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  1 +
 drivers/gpu/drm/i915/gt/intel_rps.c | 32 +
 drivers/gpu/drm/i915/gt/intel_rps.h |  2 ++
 drivers/gpu/drm/i915/i915_pmu.c |  3 +--
 4 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 35c039573294c..f8c4f758ac0b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1539,6 +1539,7 @@
 
 #define GEN12_RPSTAT1  _MMIO(0x1381b4)
 #define   GEN12_VOLTAGE_MASK   REG_GENMASK(10, 0)
+#define   GEN12_CAGF_MASK  REG_GENMASK(19, 11)
 
 #define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
 #define   GEN11_CSME   (31)
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 5bd6671554a6e..da6b969f554b6 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2068,12 +2068,34 @@ void intel_rps_sanitize(struct intel_rps *rps)
rps_disable_interrupts(rps);
 }
 
+u32 intel_rps_read_rpstat_fw(struct intel_rps *rps)
+{
+   struct drm_i915_private *i915 = rps_to_i915(rps);
+   i915_reg_t rpstat;
+
+   rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
+
+   return intel_uncore_read_fw(rps_to_gt(rps)->uncore, rpstat);
+}
+
+u32 intel_rps_read_rpstat(struct intel_rps *rps)
+{
+   struct drm_i915_private *i915 = rps_to_i915(rps);
+   i915_reg_t rpstat;
+
+   rpstat = (GRAPHICS_VER(i915) >= 12) ? GEN12_RPSTAT1 : GEN6_RPSTAT1;
+
+   return intel_uncore_read(rps_to_gt(rps)->uncore, rpstat);
+}
+
 u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
 {
struct drm_i915_private *i915 = rps_to_i915(rps);
u32 cagf;
 
-   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
+   if (GRAPHICS_VER(i915) >= 12)
+   cagf = REG_FIELD_GET(GEN12_CAGF_MASK, rpstat);
+   else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
cagf = REG_FIELD_GET(RPE_MASK, rpstat);
else if (GRAPHICS_VER(i915) >= 9)
cagf = REG_FIELD_GET(GEN9_CAGF_MASK, rpstat);
@@ -2093,7 +2115,9 @@ static u32 read_cagf(struct intel_rps *rps)
struct intel_uncore *uncore = rps_to_uncore(rps);
u32 freq;
 
-   if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
+   if (GRAPHICS_VER(i915) >= 12) {
+   freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
+   } else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
vlv_punit_get(i915);
freq = vlv_punit_read(i915, PUNIT_REG_GPU_FREQ_STS);
vlv_punit_put(i915);
@@ -2259,7 +2283,7 @@ static void rps_frequency_dump(struct intel_rps *rps, 
struct drm_printer *p)
rpinclimit = intel_uncore_read(uncore, GEN6_RP_UP_THRESHOLD);
rpdeclimit = intel_uncore_read(uncore, GEN6_RP_DOWN_THRESHOLD);
 
-   rpstat = intel_uncore_read(uncore, GEN6_RPSTAT1);
+   rpstat = intel_rps_read_rpstat(rps);
rpcurupei = intel_uncore_read(uncore, GEN6_RP_CUR_UP_EI) & 
GEN6_CURICONT_MASK;
rpcurup = intel_uncore_read(uncore, GEN6_RP_CUR_UP) & 
GEN6_CURBSYTAVG_MASK;
rpprevup = intel_uncore_read(uncore, GEN6_RP_PREV_UP) & 
GEN6_CURBSYTAVG_MASK;
@@ -2394,7 +2418,7 @@ static void slpc_frequency_dump(struct intel_rps *rps, 
struct drm_printer *p)
drm_printf(p, "PM MASK=0x%08x\n", pm_mask);
drm_printf(p, "pm_intrmsk_mbz: 0x%08x\n",
   rps->pm_intrmsk_mbz);
-   drm_printf(p, "RPSTAT1: 0x%08x\n", intel_uncore_read(uncore, 
GEN6_RPSTAT1));
+   drm_printf(p, "RPSTAT1: 0x%08x\n", intel_rps_read_rpstat(rps));
drm_printf(p, "RPNSWREQ: %dMHz\n", 
intel_rps_get_requested_frequency(rps));
drm_printf(p, "Lowest (RPN) frequency: %dMHz\n",
   intel_gpu_freq(rps, caps.min_freq));
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.h 
b/drivers/gpu/drm/i915/gt/intel_rps.h
index 110300dfd4383..9e1cad9ba0e9c 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.h
+++ b/drivers/gpu/drm/i915/gt/intel_rps.h
@@ -48,6 +48,8 @@ u32 intel_rps_get_rp1_frequency(

[PATCH 3/5] drm/i915/mtl: Modify CAGF functions for MTL

2022-10-19 Thread Ashutosh Dixit
From: Badal Nilawar 

Update CAGF functions for MTL to get actual resolved frequency of 3D and
SAMedia.

v2: Update MTL_MIRROR_TARGET_WP1 position/formatting (MattR)
Move MTL branches in cagf functions to top (MattR)
Fix commit message (Andi)
v3: Added comment about registers not needing forcewake for Gen12+ and
returning 0 freq in RC6
v4: Use REG_FIELD_GET and uncore (Rodrigo)

Bspec: 66300

Signed-off-by: Ashutosh Dixit 
Signed-off-by: Badal Nilawar 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  4 
 drivers/gpu/drm/i915/gt/intel_rps.c | 12 ++--
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index f8c4f758ac0b1..d8dbd0ac3b064 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -21,6 +21,10 @@
  */
 #define PERF_REG(offset)   _MMIO(offset)
 
+/* MTL workpoint reg to get core C state and actual freq of 3D, SAMedia */
+#define MTL_MIRROR_TARGET_WP1  _MMIO(0xc60)
+#define   MTL_CAGF_MASKREG_GENMASK(8, 0)
+
 /* RPM unit config (Gen8+) */
 #define RPM_CONFIG0_MMIO(0xd00)
 #define   GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT3
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index da6b969f554b6..63cc7c538401e 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -2093,7 +2093,9 @@ u32 intel_rps_get_cagf(struct intel_rps *rps, u32 rpstat)
struct drm_i915_private *i915 = rps_to_i915(rps);
u32 cagf;
 
-   if (GRAPHICS_VER(i915) >= 12)
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   cagf = REG_FIELD_GET(MTL_CAGF_MASK, rpstat);
+   else if (GRAPHICS_VER(i915) >= 12)
cagf = REG_FIELD_GET(GEN12_CAGF_MASK, rpstat);
else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915))
cagf = REG_FIELD_GET(RPE_MASK, rpstat);
@@ -2115,7 +2117,13 @@ static u32 read_cagf(struct intel_rps *rps)
struct intel_uncore *uncore = rps_to_uncore(rps);
u32 freq;
 
-   if (GRAPHICS_VER(i915) >= 12) {
+   /*
+* For Gen12+ reading freq from HW does not need a forcewake and
+* registers will return 0 freq when GT is in RC6
+*/
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) {
+   freq = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
+   } else if (GRAPHICS_VER(i915) >= 12) {
freq = intel_uncore_read(uncore, GEN12_RPSTAT1);
} else if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
vlv_punit_get(i915);
-- 
2.38.0



[PATCH 0/5] i915: CAGF and RC6 changes for MTL

2022-10-19 Thread Ashutosh Dixit
This series includes the code changes to get CAGF, RC State and C6
Residency of MTL.

v3: Included "Use GEN12 RPSTAT register" patch

v4:
  - Rebased
  - Dropped "Use GEN12 RPSTAT register" patch from this series
going to send separate series for it

v5:
  - Included "drm/i915/gt: Change RC6 residency functions to accept register
ID's" based on code review feedback

v6:
  - Addressed Jani N's review comments on "drm/i915/gt: Change RC6 residency
functions to accept register ID's"
  - Re-add "drm/i915: Use GEN12_RPSTAT register for GT freq" to this series

v7: Rebuild, identical to v6

v8:
  - Add "drm/i915/rps: Prefer REG_FIELD_GET in intel_rps_get_cagf" to the series
(based on Rodrigo's review) to consistently use REG_FIELD_GET
  - Minor changes to other patches, please see individual patches for changelogs

Ashutosh Dixit (2):
  drm/i915/rps: Prefer REG_FIELD_GET in intel_rps_get_cagf
  drm/i915/gt: Use RC6 residency types as arguments to residency
functions

Badal Nilawar (2):
  drm/i915/mtl: Modify CAGF functions for MTL
  drm/i915/mtl: C6 residency and C state type for MTL SAMedia

Don Hiatt (1):
  drm/i915: Use GEN12_RPSTAT register for GT freq

 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 87 ++-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 22 +++--
 drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c   | 12 +--
 drivers/gpu/drm/i915/gt/intel_rc6.c   | 64 +-
 drivers/gpu/drm/i915/gt/intel_rc6.h   | 11 ++-
 drivers/gpu/drm/i915/gt/intel_rc6_types.h | 15 +++-
 drivers/gpu/drm/i915/gt/intel_rps.c   | 51 ---
 drivers/gpu/drm/i915/gt/intel_rps.h   |  2 +
 drivers/gpu/drm/i915/gt/selftest_rc6.c|  6 +-
 drivers/gpu/drm/i915/i915_pmu.c   |  9 +-
 10 files changed, 197 insertions(+), 82 deletions(-)

-- 
2.38.0



[PATCH v2] drm/i915/slpc: Optmize waitboost for SLPC

2022-10-19 Thread Vinay Belgaumkar
Waitboost (when SLPC is enabled) results in a H2G message. This can result
in thousands of messages during a stress test and fill up an already full
CTB. There is no need to request for RP0 if GuC is already requesting the
same.

v2: Add the tracing back, and check requested freq
in the worker thread (Tvrtko)

Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/intel_rps.c | 3 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 7 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c
index fc23c562d9b2..18b75cf08d1b 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1016,6 +1016,9 @@ void intel_rps_boost(struct i915_request *rq)
if (rps_uses_slpc(rps)) {
slpc = rps_to_slpc(rps);
 
+   GT_TRACE(rps_to_gt(rps), "boost fence:%llx:%llx\n",
+rq->fence.context, rq->fence.seqno);
+
/* Return if old value is non zero */
if (!atomic_fetch_inc(&slpc->num_waiters))
schedule_work(&slpc->boost_work);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index b7cdeec44bd3..7ab96221be7e 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -227,14 +227,19 @@ static int slpc_force_min_freq(struct intel_guc_slpc 
*slpc, u32 freq)
 static void slpc_boost_work(struct work_struct *work)
 {
struct intel_guc_slpc *slpc = container_of(work, typeof(*slpc), 
boost_work);
+   struct intel_rps *rps = &slpc_to_gt(slpc)->rps;
int err;
 
/*
 * Raise min freq to boost. It's possible that
 * this is greater than current max. But it will
 * certainly be limited by RP0. An error setting
-* the min param is not fatal.
+* the min param is not fatal. No need to boost
+* if we are already requesting it.
 */
+   if (intel_rps_get_requested_frequency(rps) == slpc->boost_freq)
+   return;
+
mutex_lock(&slpc->lock);
if (atomic_read(&slpc->num_waiters)) {
err = slpc_force_min_freq(slpc, slpc->boost_freq);
-- 
2.35.1



Re: [Intel-gfx] [PATCH] drm/i915/slpc: Optmize waitboost for SLPC

2022-10-19 Thread Belgaumkar, Vinay



On 10/19/2022 2:12 PM, Belgaumkar, Vinay wrote:


On 10/19/2022 12:40 AM, Tvrtko Ursulin wrote:


On 18/10/2022 23:15, Vinay Belgaumkar wrote:
Waitboost (when SLPC is enabled) results in a H2G message. This can 
result
in thousands of messages during a stress test and fill up an already 
full
CTB. There is no need to request for RP0 if GuC is already 
requesting the

same.

Signed-off-by: Vinay Belgaumkar 
---
  drivers/gpu/drm/i915/gt/intel_rps.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c

index fc23c562d9b2..a20ae4fceac8 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1005,13 +1005,20 @@ void intel_rps_dec_waiters(struct intel_rps 
*rps)

  void intel_rps_boost(struct i915_request *rq)
  {
  struct intel_guc_slpc *slpc;
+    struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
    if (i915_request_signaled(rq) || 
i915_request_has_waitboost(rq))

  return;
  +    /* If GuC is already requesting RP0, skip */
+    if (rps_uses_slpc(rps)) {
+    slpc = rps_to_slpc(rps);
+    if (intel_rps_get_requested_frequency(rps) == slpc->rp0_freq)

One correction here is this should be slpc->boost_freq.

+    return;
+    }
+


Feels a little bit like a layering violation. Wait boost reference 
counts and request markings will changed based on asynchronous state 
- a mmio read.


Also, a little below we have this:

"""
/* Serializes with i915_request_retire() */
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
    struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;

    if (rps_uses_slpc(rps)) {
    slpc = rps_to_slpc(rps);

    /* Return if old value is non zero */
    if (!atomic_fetch_inc(&slpc->num_waiters))

*** Wouldn't it skip doing anything here already? ***
It will skip only if boost is already happening. This patch is trying 
to prevent even that first one if possible.


    schedule_work(&slpc->boost_work);

    return;
    }

    if (atomic_fetch_inc(&rps->num_waiters))
    return;
"""

But I wonder if this is not a layering violation already. Looks like 
one for me at the moment. And as it happens there is an ongoing debug 
of clvk slowness where I was a bit puzzled by the lack of "boost 
fence" in trace_printk logs - but now I see how that happens. Does 
not feel right to me that we lose that tracing with SLPC.
Agreed. Will add the trace to the SLPC case as well.  However, the 
question is what does that trace indicate? Even in the host case, we 
log the trace, but may skip the actual boost as the req is already 
matching boost freq. IMO, we should log the trace only when we 
actually decide to boost.
On second thoughts, that trace only tracks the boost fence, which is set 
in this case. So, might be ok to have it regardless. We count the 
num_boosts anyways if we ever wanted to know how many of those actually 
went on to boost the freq.


So in general - why the correct approach wouldn't be to solve this in 
the worker - which perhaps should fork to slpc specific branch and do 
the consolidations/skips based on mmio reads in there?


sure, I can move the mmio read to the SLPC worker thread.

Thanks,

Vinay.



Regards,

Tvrtko


  /* Serializes with i915_request_retire() */
  if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
-    struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
    if (rps_uses_slpc(rps)) {
  slpc = rps_to_slpc(rps);


[PATCH] drm/i915/xelpg: Fix write to MTL_MCR_SELECTOR

2022-10-19 Thread Matt Roper
A misplaced closing parenthesis caused the groupid/instanceid values to
be considered part of the ternary operator's condition instead of being
OR'd into the resulting value.

Fixes: f32898c94a10 ("drm/i915/xelpg: Add multicast steering")
Reported-by: kernel test robot 
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index 0d2811724b00..46cf2f3d1e8e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -249,7 +249,7 @@ static u32 rw_with_mcr_steering_fw(struct intel_uncore 
*uncore,
intel_uncore_write_fw(uncore, MTL_MCR_SELECTOR,
  REG_FIELD_PREP(MTL_MCR_GROUPID, group) |
  REG_FIELD_PREP(MTL_MCR_INSTANCEID, 
instance) |
- (rw_flag == FW_REG_READ) ? 
GEN11_MCR_MULTICAST : 0);
+ (rw_flag == FW_REG_READ ? 
GEN11_MCR_MULTICAST : 0));
} else if (GRAPHICS_VER(uncore->i915) >= 11) {
mcr_mask = GEN11_MCR_SLICE_MASK | GEN11_MCR_SUBSLICE_MASK;
mcr_ss = GEN11_MCR_SLICE(group) | GEN11_MCR_SUBSLICE(instance);
-- 
2.37.3



[PATCH v1] drm: rockchip: remove rockchip_drm_framebuffer_init() function

2022-10-19 Thread Johan Jonker
The function rockchip_drm_framebuffer_init() was in use
in the rockchip_drm_fbdev.c file, but that is now replaced
by a generic fbdev setup. Reduce the image size by
removing the rockchip_drm_framebuffer_init() and sub function
rockchip_fb_alloc() and cleanup the rockchip_drm_fb.h header file.

Signed-off-by: Johan Jonker 
---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 43 --
 drivers/gpu/drm/rockchip/rockchip_drm_fb.h |  6 ---
 2 files changed, 49 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 092bf863110b..409eaa1bf092 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -25,35 +25,6 @@ static const struct drm_framebuffer_funcs 
rockchip_drm_fb_funcs = {
.dirty = drm_atomic_helper_dirtyfb,
 };
 
-static struct drm_framebuffer *
-rockchip_fb_alloc(struct drm_device *dev, const struct drm_mode_fb_cmd2 
*mode_cmd,
- struct drm_gem_object **obj, unsigned int num_planes)
-{
-   struct drm_framebuffer *fb;
-   int ret;
-   int i;
-
-   fb = kzalloc(sizeof(*fb), GFP_KERNEL);
-   if (!fb)
-   return ERR_PTR(-ENOMEM);
-
-   drm_helper_mode_fill_fb_struct(dev, fb, mode_cmd);
-
-   for (i = 0; i < num_planes; i++)
-   fb->obj[i] = obj[i];
-
-   ret = drm_framebuffer_init(dev, fb, &rockchip_drm_fb_funcs);
-   if (ret) {
-   DRM_DEV_ERROR(dev->dev,
- "Failed to initialize framebuffer: %d\n",
- ret);
-   kfree(fb);
-   return ERR_PTR(ret);
-   }
-
-   return fb;
-}
-
 static const struct drm_mode_config_helper_funcs rockchip_mode_config_helpers 
= {
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
 };
@@ -106,20 +77,6 @@ static const struct drm_mode_config_funcs 
rockchip_drm_mode_config_funcs = {
.atomic_commit = drm_atomic_helper_commit,
 };
 
-struct drm_framebuffer *
-rockchip_drm_framebuffer_init(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object *obj)
-{
-   struct drm_framebuffer *fb;
-
-   fb = rockchip_fb_alloc(dev, mode_cmd, &obj, 1);
-   if (IS_ERR(fb))
-   return ERR_CAST(fb);
-
-   return fb;
-}
-
 void rockchip_drm_mode_config_init(struct drm_device *dev)
 {
dev->mode_config.min_width = 0;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
index 1a696521096d..bae4e079dfb1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.h
@@ -7,11 +7,5 @@
 #ifndef _ROCKCHIP_DRM_FB_H
 #define _ROCKCHIP_DRM_FB_H
 
-struct drm_framebuffer *
-rockchip_drm_framebuffer_init(struct drm_device *dev,
- const struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_gem_object *obj);
-void rockchip_drm_framebuffer_fini(struct drm_framebuffer *fb);
-
 void rockchip_drm_mode_config_init(struct drm_device *dev);
 #endif /* _ROCKCHIP_DRM_FB_H */
-- 
2.20.1



Re: [PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of drm_dp_add_payload_part2()

2022-10-19 Thread Lyude Paul
Gotcha, I'll take another look at this tomorrow

On Mon, 2022-10-17 at 03:09 +, Lin, Wayne wrote:
> [Public]
> 
> 
> 
> > -Original Message-
> > From: Lyude Paul 
> > Sent: Thursday, October 6, 2022 3:37 AM
> > To: Siqueira, Rodrigo ; dri-
> > de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
> > Cc: Wentland, Harry ; Li, Sun peng (Leo)
> > ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter ; Zuo, Jerry
> > ; Lin, Wayne ; Chen, Ian
> > ; Mikita Lipski ; Mahfooz,
> > Hamza ; Claudio Suarez ; Colin
> > Ian King ; Jani Nikula ; open
> > list 
> > Subject: Re: [PATCH] drm/amdgpu/dm/mst: Fix incorrect usage of
> > drm_dp_add_payload_part2()
> > 
> > On Tue, 2022-10-04 at 16:46 -0400, Rodrigo Siqueira Jordao wrote:
> > > 
> > > On 2022-10-04 16:24, Lyude Paul wrote:
> > > > Yikes, it appears somehow I totally made a mistake here. We're
> > > > currently checking to see if drm_dp_add_payload_part2() returns a
> > > > non-zero value to indicate success. That's totally wrong though, as
> > > > this function only returns a zero value on success - not the other way
> > around.
> > > > 
> > > > So, fix that.
> > > > 
> > > > Signed-off-by: Lyude Paul 
> > > > Issue:
> > > > 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > > tlab.freedesktop.org%2Fdrm%2Famd%2F-
> > %2Fissues%2F2171&data=05%7C0
> > > > 
> > 1%7Cwayne.lin%40amd.com%7Ccd5a63120e064f4bb6aa08daa7090baf%7C3d
> > d8961
> > > > 
> > fe4884e608e11a82d994e183d%7C0%7C0%7C638005954559719396%7CUnkno
> > wn%7CT
> > > > 
> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
> > JXV
> > > > 
> > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=nMIGnUKS6EDrdKJ0rR%2BAh
> > FRa4ST0%2
> > > > BYr9bILmXv40yv0%3D&reserved=0
> > > > Fixes: 4d07b0bc4034 ("drm/display/dp_mst: Move all payload info into
> > > > the atomic state")
> > > > ---
> > > >   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2
> > +-
> > > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git
> > > > a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > index b8077fcd4651..00598def5b39 100644
> > > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > +++
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> > > > @@ -297,7 +297,7 @@ bool
> > dm_helpers_dp_mst_send_payload_allocation(
> > > > clr_flag = MST_ALLOCATE_NEW_PAYLOAD;
> > > > }
> > > > 
> > > > -   if (enable && drm_dp_add_payload_part2(mst_mgr, mst_state-
> > > base.state, payload)) {
> > > > +   if (enable && drm_dp_add_payload_part2(mst_mgr,
> > > > +mst_state->base.state, payload) == 0) {
> 
> Hi Lyude,
> 
> This line changes the original logic a bit. The 'if' case was trying to catch 
> failure 
> while sending ALLOCATE_PAYLOAD. If the msg fails, set the set_flag to false.
> If succeed, set the set_flag to true and clear the clr_flag. 
> 
> Sorry if the code wording misleading. Thanks!
> 
> > > > amdgpu_dm_set_mst_status(&aconnector->mst_status,
> > > > set_flag, false);
> > > > } else {
> > > 
> > > Hi Lyude,
> > > 
> > > Maybe I'm missing something, but I can't find the
> > > drm_dp_add_payload_part2() function on amd-staging-drm-next. Which
> > > repo are you using?
> > 
> > If it's not on amd-staging-drm-next then it likely hasn't gotten backported 
> > to
> > amd's branch yet and is in drm-misc-next
> > 
> > > 
> > > Thanks
> > > Siqueira
> > > 
> > 
> > --
> > Cheers,
> >  Lyude Paul (she/her)
> >  Software Engineer at Red Hat
> --
> Regards,
> Wayne Lin
> 

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



Re: [Intel-gfx] [PATCH] drm/i915/slpc: Optmize waitboost for SLPC

2022-10-19 Thread Belgaumkar, Vinay



On 10/19/2022 12:40 AM, Tvrtko Ursulin wrote:


On 18/10/2022 23:15, Vinay Belgaumkar wrote:
Waitboost (when SLPC is enabled) results in a H2G message. This can 
result
in thousands of messages during a stress test and fill up an already 
full
CTB. There is no need to request for RP0 if GuC is already requesting 
the

same.

Signed-off-by: Vinay Belgaumkar 
---
  drivers/gpu/drm/i915/gt/intel_rps.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c 
b/drivers/gpu/drm/i915/gt/intel_rps.c

index fc23c562d9b2..a20ae4fceac8 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1005,13 +1005,20 @@ void intel_rps_dec_waiters(struct intel_rps 
*rps)

  void intel_rps_boost(struct i915_request *rq)
  {
  struct intel_guc_slpc *slpc;
+    struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
    if (i915_request_signaled(rq) || i915_request_has_waitboost(rq))
  return;
  +    /* If GuC is already requesting RP0, skip */
+    if (rps_uses_slpc(rps)) {
+    slpc = rps_to_slpc(rps);
+    if (intel_rps_get_requested_frequency(rps) == slpc->rp0_freq)

One correction here is this should be slpc->boost_freq.

+    return;
+    }
+


Feels a little bit like a layering violation. Wait boost reference 
counts and request markings will changed based on asynchronous state - 
a mmio read.


Also, a little below we have this:

"""
/* Serializes with i915_request_retire() */
if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
    struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;

    if (rps_uses_slpc(rps)) {
    slpc = rps_to_slpc(rps);

    /* Return if old value is non zero */
    if (!atomic_fetch_inc(&slpc->num_waiters))

*** Wouldn't it skip doing anything here already? ***
It will skip only if boost is already happening. This patch is trying to 
prevent even that first one if possible.


    schedule_work(&slpc->boost_work);

    return;
    }

    if (atomic_fetch_inc(&rps->num_waiters))
    return;
"""

But I wonder if this is not a layering violation already. Looks like 
one for me at the moment. And as it happens there is an ongoing debug 
of clvk slowness where I was a bit puzzled by the lack of "boost 
fence" in trace_printk logs - but now I see how that happens. Does not 
feel right to me that we lose that tracing with SLPC.
Agreed. Will add the trace to the SLPC case as well.  However, the 
question is what does that trace indicate? Even in the host case, we log 
the trace, but may skip the actual boost as the req is already matching 
boost freq. IMO, we should log the trace only when we actually decide to 
boost.


So in general - why the correct approach wouldn't be to solve this in 
the worker - which perhaps should fork to slpc specific branch and do 
the consolidations/skips based on mmio reads in there?


sure, I can move the mmio read to the SLPC worker thread.

Thanks,

Vinay.



Regards,

Tvrtko


  /* Serializes with i915_request_retire() */
  if (!test_and_set_bit(I915_FENCE_FLAG_BOOST, &rq->fence.flags)) {
-    struct intel_rps *rps = &READ_ONCE(rq->engine)->gt->rps;
    if (rps_uses_slpc(rps)) {
  slpc = rps_to_slpc(rps);


Re: [PATCH] Make xilinxfb_release() return void

2022-10-19 Thread Uwe Kleine-König
Hello,

I failed to add a proper subject prefix. "fbdev: xilinxfb: " would have
been a good choice. I can resend, but I wouldn't say no if you are
willing to fixup while applying this patch :-)

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Re: [PATCH 15/15] drm/edid: convert to device specific logging

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:49PM +0300, Jani Nikula wrote:
> Convert to drm_kms_dbg/drm_err where possible, and unify the rest of the
> debugs to DRM_DEBUG_KMS.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 105 ++---
>  1 file changed, 50 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 935bdf4e6269..09b0b8337382 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1979,7 +1979,7 @@ bool drm_edid_block_valid(u8 *_block, int block_num, 
> bool print_bad_edid,
>  
>   status = edid_block_check(block, is_base_block);
>   if (status == EDID_BLOCK_HEADER_REPAIR) {
> - DRM_DEBUG("Fixing EDID header, your hardware may be failing\n");
> + DRM_DEBUG_KMS("Fixing EDID header, your hardware may be 
> failing\n");
>   edid_header_fix(block);
>  
>   /* Retry with fixed header, update status if that worked. */
> @@ -2281,8 +2281,9 @@ int drm_edid_override_connector_update(struct 
> drm_connector *connector)
>  
>   drm_edid_free(override);
>  
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] adding %d modes via fallback 
> override/firmware EDID\n",
> -   connector->base.id, connector->name, num_modes);
> + drm_dbg_kms(connector->dev,
> + "[CONNECTOR:%d:%s] adding %d modes via fallback 
> override/firmware EDID\n",
> + connector->base.id, connector->name, num_modes);
>   }
>  
>   return num_modes;
> @@ -3389,17 +3390,16 @@ static struct drm_display_mode 
> *drm_mode_detailed(struct drm_device *dev,
>   return NULL;
>  
>   if (pt->misc & DRM_EDID_PT_STEREO) {
> - DRM_DEBUG_KMS("stereo mode not supported\n");
> + drm_dbg_kms(dev, "Stereo mode not supported\n");
>   return NULL;
>   }
>   if (!(pt->misc & DRM_EDID_PT_SEPARATE_SYNC)) {
> - DRM_DEBUG_KMS("composite sync not supported\n");
> + drm_dbg_kms(dev, "Composite sync not supported\n");
>   }
>  
>   /* it is incorrect if hsync/vsync width is zero */
>   if (!hsync_pulse_width || !vsync_pulse_width) {
> - DRM_DEBUG_KMS("Incorrect Detailed timing. "
> - "Wrong Hsync/Vsync pulse width\n");
> + drm_dbg_kms(dev, "Incorrect Detailed timing. Wrong Hsync/Vsync 
> pulse width\n");
>   return NULL;
>   }
>  
> @@ -4643,7 +4643,7 @@ static int add_hdmi_mode(struct drm_connector 
> *connector, u8 vic)
>   struct drm_display_mode *newmode;
>  
>   if (!drm_valid_hdmi_vic(vic)) {
> - DRM_ERROR("Unknown HDMI VIC: %d\n", vic);
> + drm_err(connector->dev, "Unknown HDMI VIC: %d\n", vic);

Quit a lot of these could also do the full [CONNECTOR:...] 
thing it seems.

-- 
Ville Syrjälä
Intel


Re: [PATCH 14/15] drm/edid/firmware: convert to drm device specific logging

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:48PM +0300, Jani Nikula wrote:
> Conform to device specific logging.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid_load.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 882caaa6e663..dd472c66cb3c 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -177,16 +177,18 @@ static const struct drm_edid *edid_load(struct 
> drm_connector *connector, const c
>  
>   pdev = platform_device_register_simple(connector->name, -1, 
> NULL, 0);
>   if (IS_ERR(pdev)) {
> - DRM_ERROR("Failed to register EDID firmware platform 
> device "
> -   "for connector \"%s\"\n", connector->name);
> + drm_err(connector->dev,
> + "Failed to register EDID firmware platform 
> device for connector \"%s\"\n",
> + connector->name);

Can go for the full [CONNECTOR:...] thing?

>   return ERR_CAST(pdev);
>   }
>  
>   err = request_firmware(&fw, name, &pdev->dev);
>   platform_device_unregister(pdev);
>   if (err) {
> - DRM_ERROR("Requesting EDID firmware \"%s\" failed 
> (err=%d)\n",
> -   name, err);
> + drm_err(connector->dev,
> + "Requesting EDID firmware \"%s\" failed 
> (err=%d)\n",
> + name, err);
>   return ERR_PTR(err);
>   }
>  
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 13/15] drm/edid: move edid load declarations to internal header

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:47PM +0300, Jani Nikula wrote:
> The EDID loader is internal to drm, not for drivers.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_crtc_internal.h | 11 +++
>  drivers/gpu/drm/drm_edid_load.c |  5 +++--
>  include/drm/drm_edid.h  |  7 ---
>  3 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index fb8a68d90940..501a10edd0e1 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -290,3 +290,14 @@ void drm_mode_fixup_1366x768(struct drm_display_mode 
> *mode);
>  int drm_edid_override_show(struct drm_connector *connector, struct seq_file 
> *m);
>  int drm_edid_override_set(struct drm_connector *connector, const void *edid, 
> size_t size);
>  int drm_edid_override_reset(struct drm_connector *connector);
> +
> +/* drm_edid_load.c */
> +#ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> +const struct drm_edid *drm_edid_load_firmware(struct drm_connector 
> *connector);
> +#else
> +static inline const struct drm_edid *
> +drm_edid_load_firmware(struct drm_connector *connector)
> +{
> + return ERR_PTR(-ENOENT);
> +}
> +#endif
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 248f0685c33e..882caaa6e663 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -11,12 +11,13 @@
>  #include 
>  #include 
>  
> -#include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
>  
> +#include "drm_crtc_internal.h"
> +
>  static char edid_firmware[PATH_MAX];
>  module_param_string(edid_firmware, edid_firmware, sizeof(edid_firmware), 
> 0644);
>  MODULE_PARM_DESC(edid_firmware, "Do not probe monitor, use specified EDID 
> blob "
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 8138613f4e4e..372963600f1d 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -388,15 +388,8 @@ int drm_av_sync_delay(struct drm_connector *connector,
> const struct drm_display_mode *mode);
>  
>  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> -const struct drm_edid *drm_edid_load_firmware(struct drm_connector 
> *connector);
>  int __drm_set_edid_firmware_path(const char *path);
>  int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
> -#else
> -static inline const struct drm_edid *
> -drm_edid_load_firmware(struct drm_connector *connector)
> -{
> - return ERR_PTR(-ENOENT);
> -}
>  #endif
>  
>  bool drm_edid_are_equal(const struct edid *edid1, const struct edid *edid2);
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 11/15] drm/edid/firmware: rename drm_load_edid_firmware() to drm_edid_load_firmware()

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:45PM +0300, Jani Nikula wrote:
> Follow the usual naming convention by file name.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c  | 10 +-
>  drivers/gpu/drm/drm_edid_load.c |  2 +-
>  include/drm/drm_edid.h  |  4 ++--
>  3 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0f2898badd51..2c66a901474d 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2211,7 +2211,7 @@ static struct edid *drm_get_override_edid(struct 
> drm_connector *connector,
>   override = drm_edid_duplicate(connector->edid_override->edid);
>  
>   if (!override)
> - override = drm_load_edid_firmware(connector);
> + override = drm_edid_load_firmware(connector);
>  
>   /* FIXME: Get alloc size from deeper down the stack */
>   if (!IS_ERR_OR_NULL(override) && alloc_size)
> @@ -2443,7 +2443,7 @@ static struct edid *_drm_do_get_edid(struct 
> drm_connector *connector,
>   * adapter and use drm_get_edid() instead of abusing this function.
>   *
>   * The EDID may be overridden using debugfs override_edid or firmware EDID
> - * (drm_load_edid_firmware() and drm.edid_firmware parameter), in this 
> priority
> + * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this 
> priority
>   * order. Having either of them bypasses actual EDID reads.
>   *
>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> @@ -2621,7 +2621,7 @@ EXPORT_SYMBOL(drm_get_edid);
>   * this function.
>   *
>   * The EDID may be overridden using debugfs override_edid or firmware EDID
> - * (drm_load_edid_firmware() and drm.edid_firmware parameter), in this 
> priority
> + * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this 
> priority
>   * order. Having either of them bypasses actual EDID reads.
>   *
>   * The returned pointer must be freed using drm_edid_free().
> @@ -2659,7 +2659,7 @@ EXPORT_SYMBOL(drm_edid_read_custom);
>   * Read EDID using the given I2C adapter.
>   *
>   * The EDID may be overridden using debugfs override_edid or firmware EDID
> - * (drm_load_edid_firmware() and drm.edid_firmware parameter), in this 
> priority
> + * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this 
> priority
>   * order. Having either of them bypasses actual EDID reads.
>   *
>   * Prefer initializing connector->ddc with drm_connector_init_with_ddc() and
> @@ -2695,7 +2695,7 @@ EXPORT_SYMBOL(drm_edid_read_ddc);
>   * Read EDID using the connector's I2C adapter.
>   *
>   * The EDID may be overridden using debugfs override_edid or firmware EDID
> - * (drm_load_edid_firmware() and drm.edid_firmware parameter), in this 
> priority
> + * (drm_edid_load_firmware() and drm.edid_firmware parameter), in this 
> priority
>   * order. Having either of them bypasses actual EDID reads.
>   *
>   * The returned pointer must be freed using drm_edid_free().
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 13cdbfb991eb..bc6b96abd1b3 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -262,7 +262,7 @@ static void *edid_load(struct drm_connector *connector, 
> const char *name)
>   return edid;
>  }
>  
> -struct edid *drm_load_edid_firmware(struct drm_connector *connector)
> +struct edid *drm_edid_load_firmware(struct drm_connector *connector)
>  {
>   char *edidname, *last, *colon, *fwstr, *edidstr, *fallback = NULL;
>   struct edid *edid;
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index a2e25e7e6ee5..dc7467d25cd8 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -388,12 +388,12 @@ int drm_av_sync_delay(struct drm_connector *connector,
> const struct drm_display_mode *mode);
>  
>  #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
> -struct edid *drm_load_edid_firmware(struct drm_connector *connector);
> +struct edid *drm_edid_load_firmware(struct drm_connector *connector);
>  int __drm_set_edid_firmware_path(const char *path);
>  int __drm_get_edid_firmware_path(char *buf, size_t bufsize);
>  #else
>  static inline struct edid *
> -drm_load_edid_firmware(struct drm_connector *connector)
> +drm_edid_load_firmware(struct drm_connector *connector)
>  {
>   return ERR_PTR(-ENOENT);
>  }
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 09/15] drm/edid: detach debugfs EDID override from EDID property update

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:43PM +0300, Jani Nikula wrote:
> Having the EDID override debugfs directly update the EDID property is
> problematic. The update is partial only. The driver has no way of
> knowing it's been updated. Mode list is not updated. It's an
> inconsistent state.
> 
> Detach debugfs EDID override from the property update completely. Only
> set and reset a separate override EDID copy from debugfs, and have it
> take effect only at detect (via EDID read). The copy is at
> connector->edid_override.
> 
> This also brings override EDID closer to firmware EDID in behaviour.
> 
> Add validation of the override EDID which we completely lacked.
> 
> Note that IGT already forces a detect whenever tests update the override
> EDID.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c  | 56 -
>  include/drm/drm_connector.h | 11 +---
>  2 files changed, 25 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index c3cf942186b7..0f2898badd51 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2207,8 +2207,8 @@ static struct edid *drm_get_override_edid(struct 
> drm_connector *connector,
>  {
>   struct edid *override = NULL;
>  
> - if (connector->override_edid)
> - override = drm_edid_duplicate(connector->edid_blob_ptr->data);
> + if (connector->edid_override)
> + override = drm_edid_duplicate(connector->edid_override->edid);
>  
>   if (!override)
>   override = drm_load_edid_firmware(connector);
> @@ -2223,10 +2223,10 @@ static struct edid *drm_get_override_edid(struct 
> drm_connector *connector,
>  /* For debugfs edid_override implementation */
>  int drm_edid_override_show(struct drm_connector *connector, struct seq_file 
> *m)
>  {
> - struct drm_property_blob *edid = connector->edid_blob_ptr;
> + const struct drm_edid *drm_edid = connector->edid_override;
>  
> - if (connector->override_edid && edid)
> - seq_write(m, edid->data, edid->length);
> + if (drm_edid)
> + seq_write(m, drm_edid->edid, drm_edid->size);
>  
>   return 0;
>  }
> @@ -2235,32 +2235,33 @@ int drm_edid_override_show(struct drm_connector 
> *connector, struct seq_file *m)
>  int drm_edid_override_set(struct drm_connector *connector, const void *edid,
> size_t size)
>  {
> - int ret;
> + drm_edid_free(connector->edid_override);
>  
> - if (size < EDID_LENGTH || edid_size(edid) > size)
> + connector->edid_override = drm_edid_alloc(edid, size);
> + if (!drm_edid_valid(connector->edid_override)) {
> + drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] EDID override 
> invalid\n",
> + connector->base.id, connector->name);
> + drm_edid_free(connector->edid_override);
> + connector->edid_override = NULL;
>   return -EINVAL;

Hmm. Should we perhaps invest in some locking around these parts?

> -
> - connector->override_edid = false;
> + }
>  
>   drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] EDID override set\n",
>   connector->base.id, connector->name);
>  
> - ret = drm_connector_update_edid_property(connector, edid);
> - if (!ret)
> - connector->override_edid = true;
> -
> - return ret;
> + return 0;
>  }
>  
>  /* For debugfs edid_override implementation */
>  int drm_edid_override_reset(struct drm_connector *connector)
>  {
> - connector->override_edid = false;
> -
>   drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] EDID override reset\n",
>   connector->base.id, connector->name);
>  
> - return drm_connector_update_edid_property(connector, NULL);
> + drm_edid_free(connector->edid_override);
> + connector->edid_override = NULL;
> +
> + return 0;
>  }
>  
>  /**
> @@ -6634,23 +6635,6 @@ int drm_edid_connector_update(struct drm_connector 
> *connector,
>  {
>   int count;
>  
> - /*
> -  * FIXME: Reconcile the differences in override_edid handling between
> -  * this and drm_connector_update_edid_property().
> -  *
> -  * If override_edid is set, and the EDID passed in here originates from
> -  * drm_edid_read() and friends, it will be the override EDID, and there
> -  * are no issues. drm_connector_update_edid_property() ignoring requests
> -  * to set the EDID dates back to a time when override EDID was not
> -  * handled at the low level EDID read.
> -  *
> -  * The only way the EDID passed in here can be different from the
> -  * override EDID is when a driver passes in an EDID that does *not*
> -  * originate from drm_edid_read() and friends, or passes in a stale
> -  * cached version. This, in turn, is a question of when an override EDID
> -  * set via debugfs should take effect.
> -  */
> -
>   count = _drm_edid_co

Re: [PATCH 06/15] drm/edid: rename drm_add_override_edid_modes() to drm_edid_override_connector_update()

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:40PM +0300, Jani Nikula wrote:
> Follow the naming of both EDID override functions as well as
> drm_edid_connector_update(). This also matches better what the function
> does; a combination of EDID property update and add modes. Indeed it
> should later be converted to call drm_edid_connector_update().

All the function names around that stuff still make my head spin,
but hopefully it'll clear up eventually when all the cruft has
disappeared.

Reviewed-by: Ville Syrjälä 

> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 6 +++---
>  drivers/gpu/drm/drm_probe_helper.c | 2 +-
>  include/drm/drm_edid.h | 2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 1ada36e0d826..8baa46dc2537 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2227,7 +2227,7 @@ int drm_edid_override_reset(struct drm_connector 
> *connector)
>  }
>  
>  /**
> - * drm_add_override_edid_modes - add modes from override/firmware EDID
> + * drm_edid_override_connector_update - add modes from override/firmware EDID
>   * @connector: connector we're probing
>   *
>   * Add modes from the override/firmware EDID, if available. Only to be used 
> from
> @@ -2237,7 +2237,7 @@ int drm_edid_override_reset(struct drm_connector 
> *connector)
>   *
>   * Return: The number of modes added or 0 if we couldn't find any.
>   */
> -int drm_add_override_edid_modes(struct drm_connector *connector)
> +int drm_edid_override_connector_update(struct drm_connector *connector)
>  {
>   struct edid *override;
>   int num_modes = 0;
> @@ -2254,7 +2254,7 @@ int drm_add_override_edid_modes(struct drm_connector 
> *connector)
>  
>   return num_modes;
>  }
> -EXPORT_SYMBOL(drm_add_override_edid_modes);
> +EXPORT_SYMBOL(drm_edid_override_connector_update);
>  
>  typedef int read_block_fn(void *context, u8 *buf, unsigned int block, size_t 
> len);
>  
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 69b0b2b9cc1c..2fc21df709bc 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -367,7 +367,7 @@ static int drm_helper_probe_get_modes(struct 
> drm_connector *connector)
>* override/firmware EDID.
>*/
>   if (count == 0 && connector->status == connector_status_connected)
> - count = drm_add_override_edid_modes(connector);
> + count = drm_edid_override_connector_update(connector);
>  
>   return count;
>  }
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 429735b91f63..05380681a4fb 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -577,7 +577,7 @@ struct edid *drm_get_edid_switcheroo(struct drm_connector 
> *connector,
>struct i2c_adapter *adapter);
>  struct edid *drm_edid_duplicate(const struct edid *edid);
>  int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid);
> -int drm_add_override_edid_modes(struct drm_connector *connector);
> +int drm_edid_override_connector_update(struct drm_connector *connector);
>  
>  u8 drm_match_cea_mode(const struct drm_display_mode *to_match);
>  bool drm_detect_hdmi_monitor(const struct edid *edid);
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 12/15] drm/edid: use struct drm_edid for override/firmware EDID

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:46PM +0300, Jani Nikula wrote:
> There's a lot going on here, but the main thing is switching the
> firmware EDID loader to use struct drm_edid. Unfortunately, it's
> difficult to reasonably split to smaller pieces.
> 
> Convert the EDID loader to struct drm_edid. There's a functional change
> in validation; it no longer tries to fix errors or filter invalid
> blocks. It's stricter in this sense. Hopefully this will not be an
> issue.
> 
> As a by-product, this change also allows HF-EEODB extended EDIDs to be
> passed via override/firmware EDID.

Was pondering about that reading the earlier patch. Figured I'd keep
on reading, and voila here it is.

> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c  | 32 ++--
>  drivers/gpu/drm/drm_edid_load.c | 86 +++--
>  include/drm/drm_edid.h  |  4 +-
>  3 files changed, 36 insertions(+), 86 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 2c66a901474d..935bdf4e6269 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2202,21 +2202,16 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>  }
>  
>  /* Get override or firmware EDID */
> -static struct edid *drm_get_override_edid(struct drm_connector *connector,
> -   size_t *alloc_size)
> +static const struct drm_edid *drm_edid_override_get(struct drm_connector 
> *connector)
>  {
> - struct edid *override = NULL;
> + const struct drm_edid *override = NULL;
>  
>   if (connector->edid_override)
> - override = drm_edid_duplicate(connector->edid_override->edid);
> + override = drm_edid_dup(connector->edid_override);
>  
>   if (!override)
>   override = drm_edid_load_firmware(connector);
>  
> - /* FIXME: Get alloc size from deeper down the stack */
> - if (!IS_ERR_OR_NULL(override) && alloc_size)
> - *alloc_size = edid_size(override);
> -
>   return IS_ERR(override) ? NULL : override;
>  }
>  
> @@ -2277,14 +2272,14 @@ int drm_edid_override_reset(struct drm_connector 
> *connector)
>   */
>  int drm_edid_override_connector_update(struct drm_connector *connector)
>  {
> - struct edid *override;
> + const struct drm_edid *override;
>   int num_modes = 0;
>  
> - override = drm_get_override_edid(connector, NULL);
> + override = drm_edid_override_get(connector);
>   if (override) {
> - drm_connector_update_edid_property(connector, override);
> - num_modes = drm_add_edid_modes(connector, override);
> - kfree(override);
> + num_modes = drm_edid_connector_update(connector, override);
> +
> + drm_edid_free(override);
>  
>   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] adding %d modes via fallback 
> override/firmware EDID\n",
> connector->base.id, connector->name, num_modes);
> @@ -2335,12 +2330,19 @@ static struct edid *_drm_do_get_edid(struct 
> drm_connector *connector,
>  {
>   enum edid_block_status status;
>   int i, num_blocks, invalid_blocks = 0;
> + const struct drm_edid *override;
>   struct edid *edid, *new;
>   size_t alloc_size = EDID_LENGTH;
>  
> - edid = drm_get_override_edid(connector, &alloc_size);
> - if (edid)
> + override = drm_edid_override_get(connector);
> + if (override) {
> + alloc_size = override->size;
> + edid = kmemdup(override->edid, alloc_size, GFP_KERNEL);
> + drm_edid_free(override);
> + if (!edid)
> + return NULL;
>   goto ok;
> + }
>  
>   edid = kmalloc(alloc_size, GFP_KERNEL);
>   if (!edid)
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index bc6b96abd1b3..248f0685c33e 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -159,22 +159,12 @@ static const u8 generic_edid[GENERIC_EDIDS][128] = {
>   },
>  };
>  
> -static int edid_size(const u8 *edid, int data_size)
> -{
> - if (data_size < EDID_LENGTH)
> - return 0;
> -
> - return (edid[0x7e] + 1) * EDID_LENGTH;
> -}
> -
> -static void *edid_load(struct drm_connector *connector, const char *name)
> +static const struct drm_edid *edid_load(struct drm_connector *connector, 
> const char *name)
>  {
>   const struct firmware *fw = NULL;
>   const u8 *fwdata;
> - u8 *edid;
> + const struct drm_edid *drm_edid;
>   int fwsize, builtin;
> - int i, valid_extensions = 0;
> - bool print_bad_edid = !connector->bad_edid_counter || 
> drm_debug_enabled(DRM_UT_KMS);
>  
>   builtin = match_string(generic_edid_name, GENERIC_EDIDS, name);
>   if (builtin >= 0) {
> @@ -203,69 +193,26 @@ static void *edid_load(struct drm_connector *connector, 
> const char *name)
>   fwsize = fw->size;

Re: [PATCH 10/15] drm/edid/firmware: drop redundant connector_name variable/parameter

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:44PM +0300, Jani Nikula wrote:
> Stop passing around something that's readily available in
> connector->name.
> 
> Signed-off-by: Jani Nikula 

Weird. Did we not have a connector in there at some point or something?
Shrug.

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid_load.c | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
> index 37d8ba3ddb46..13cdbfb991eb 100644
> --- a/drivers/gpu/drm/drm_edid_load.c
> +++ b/drivers/gpu/drm/drm_edid_load.c
> @@ -167,8 +167,7 @@ static int edid_size(const u8 *edid, int data_size)
>   return (edid[0x7e] + 1) * EDID_LENGTH;
>  }
>  
> -static void *edid_load(struct drm_connector *connector, const char *name,
> - const char *connector_name)
> +static void *edid_load(struct drm_connector *connector, const char *name)
>  {
>   const struct firmware *fw = NULL;
>   const u8 *fwdata;
> @@ -185,10 +184,10 @@ static void *edid_load(struct drm_connector *connector, 
> const char *name,
>   struct platform_device *pdev;
>   int err;
>  
> - pdev = platform_device_register_simple(connector_name, -1, 
> NULL, 0);
> + pdev = platform_device_register_simple(connector->name, -1, 
> NULL, 0);
>   if (IS_ERR(pdev)) {
>   DRM_ERROR("Failed to register EDID firmware platform 
> device "
> -   "for connector \"%s\"\n", connector_name);
> +   "for connector \"%s\"\n", connector->name);
>   return ERR_CAST(pdev);
>   }
>  
> @@ -244,7 +243,7 @@ static void *edid_load(struct drm_connector *connector, 
> const char *name,
>   edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
>   DRM_INFO("Found %d valid extensions instead of %d in EDID data "
>   "\"%s\" for connector \"%s\"\n", valid_extensions,
> - edid[0x7e], name, connector_name);
> + edid[0x7e], name, connector->name);
>   edid[0x7e] = valid_extensions;
>  
>   new_edid = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH,
> @@ -256,7 +255,7 @@ static void *edid_load(struct drm_connector *connector, 
> const char *name,
>   DRM_INFO("Got %s EDID base block and %d extension%s from "
>   "\"%s\" for connector \"%s\"\n", (builtin >= 0) ? "built-in" :
>   "external", valid_extensions, valid_extensions == 1 ? "" : "s",
> - name, connector_name);
> + name, connector->name);
>  
>  out:
>   release_firmware(fw);
> @@ -265,7 +264,6 @@ static void *edid_load(struct drm_connector *connector, 
> const char *name,
>  
>  struct edid *drm_load_edid_firmware(struct drm_connector *connector)
>  {
> - const char *connector_name = connector->name;
>   char *edidname, *last, *colon, *fwstr, *edidstr, *fallback = NULL;
>   struct edid *edid;
>  
> @@ -288,7 +286,7 @@ struct edid *drm_load_edid_firmware(struct drm_connector 
> *connector)
>   while ((edidname = strsep(&edidstr, ","))) {
>   colon = strchr(edidname, ':');
>   if (colon != NULL) {
> - if (strncmp(connector_name, edidname, colon - edidname))
> + if (strncmp(connector->name, edidname, colon - 
> edidname))
>   continue;
>   edidname = colon + 1;
>   break;
> @@ -310,7 +308,7 @@ struct edid *drm_load_edid_firmware(struct drm_connector 
> *connector)
>   if (*last == '\n')
>   *last = '\0';
>  
> - edid = edid_load(connector, edidname, connector_name);
> + edid = edid_load(connector, edidname);
>   kfree(fwstr);
>  
>   return edid;
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 08/15] drm/edid: add function for checking drm_edid validity

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:42PM +0300, Jani Nikula wrote:
> We've lacked a function for immutable validity check on drm_edid. Add
> one.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 30 ++
>  include/drm/drm_edid.h |  1 +
>  2 files changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 616c1cdc7507..c3cf942186b7 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2040,6 +2040,36 @@ bool drm_edid_is_valid(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_edid_is_valid);
>  
> +/**
> + * drm_edid_valid - sanity check EDID data
> + * @drm_edid: EDID data
> + *
> + * Sanity check an EDID. Cross check block count against allocated size and
> + * checksum the blocks.
> + *
> + * Return: True if the EDID data is valid, false otherwise.
> + */
> +bool drm_edid_valid(const struct drm_edid *drm_edid)
> +{
> + int i;
> +
> + if (!drm_edid)
> + return false;
> +
> + if (edid_size_by_blocks(__drm_edid_block_count(drm_edid)) != 
> drm_edid->size)
> + return false;

I Was consfued about the HF-EEODB crap for a bit but 
__drm_edid_block_count() does include that.

So looks sane
Reviewed-by: Ville Syrjälä 

> +
> + for (i = 0; i < drm_edid_block_count(drm_edid); i++) {
> + const void *block = drm_edid_block_data(drm_edid, i);
> +
> + if (!edid_block_valid(block, i == 0))
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(drm_edid_valid);
> +
>  static struct edid *edid_filter_invalid_blocks(struct edid *edid,
>  size_t *alloc_size)
>  {
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 05380681a4fb..a2e25e7e6ee5 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -606,6 +606,7 @@ drm_display_mode_from_cea_vic(struct drm_device *dev,
>  const struct drm_edid *drm_edid_alloc(const void *edid, size_t size);
>  const struct drm_edid *drm_edid_dup(const struct drm_edid *drm_edid);
>  void drm_edid_free(const struct drm_edid *drm_edid);
> +bool drm_edid_valid(const struct drm_edid *drm_edid);
>  const struct edid *drm_edid_raw(const struct drm_edid *drm_edid);
>  const struct drm_edid *drm_edid_read(struct drm_connector *connector);
>  const struct drm_edid *drm_edid_read_ddc(struct drm_connector *connector,
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 07/15] drm/edid: split drm_edid block count helper

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:41PM +0300, Jani Nikula wrote:
> Split the drm_edid block count helper to a base version that reports the
> block count indicated by EDID contents, and another on top that limits
> the block count based on size allocated for the EDID.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 8baa46dc2537..616c1cdc7507 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1613,7 +1613,8 @@ static const void *edid_extension_block_data(const 
> struct edid *edid, int index)
>   return edid_block_data(edid, index + 1);
>  }
>  
> -static int drm_edid_block_count(const struct drm_edid *drm_edid)
> +/* EDID block count indicated in EDID, may exceed allocated size */
> +static int __drm_edid_block_count(const struct drm_edid *drm_edid)
>  {
>   int num_blocks;
>  
> @@ -1633,12 +1634,18 @@ static int drm_edid_block_count(const struct drm_edid 
> *drm_edid)
>   num_blocks = eeodb;
>   }
>  
> - /* Limit by allocated size */
> - num_blocks = min(num_blocks, (int)drm_edid->size / EDID_LENGTH);
> -
>   return num_blocks;
>  }
>  
> +/* EDID block count, limited by allocated size */
> +static int drm_edid_block_count(const struct drm_edid *drm_edid)
> +{
> + /* Limit by allocated size */
> + return min(__drm_edid_block_count(drm_edid),
> +(int)drm_edid->size / EDID_LENGTH);
> +}
> +
> +/* EDID extension block count, limited by allocated size */
>  static int drm_edid_extension_block_count(const struct drm_edid *drm_edid)
>  {
>   return drm_edid_block_count(drm_edid) - 1;
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 05/15] drm/edid: abstract debugfs override EDID show better

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:39PM +0300, Jani Nikula wrote:
> Add a function to dump the override EDID in debugfs. This hides the
> override EDID management better in drm_edid.c.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_crtc_internal.h |  4 +++-
>  drivers/gpu/drm/drm_debugfs.c   |  8 +---
>  drivers/gpu/drm/drm_edid.c  | 11 +++
>  3 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 56041b604881..fb8a68d90940 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -56,9 +56,10 @@ struct drm_plane;
>  struct drm_plane_state;
>  struct drm_property;
>  struct edid;
> +struct fwnode_handle;
>  struct kref;
> +struct seq_file;
>  struct work_struct;
> -struct fwnode_handle;
>  
>  /* drm_crtc.c */
>  int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
> @@ -286,5 +287,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>  
>  /* drm_edid.c */
>  void drm_mode_fixup_1366x768(struct drm_display_mode *mode);
> +int drm_edid_override_show(struct drm_connector *connector, struct seq_file 
> *m);
>  int drm_edid_override_set(struct drm_connector *connector, const void *edid, 
> size_t size);
>  int drm_edid_override_reset(struct drm_connector *connector);
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 01ee3febb813..ee445f4605ba 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -328,13 +328,7 @@ static ssize_t connector_write(struct file *file, const 
> char __user *ubuf,
>  
>  static int edid_show(struct seq_file *m, void *data)
>  {
> - struct drm_connector *connector = m->private;
> - struct drm_property_blob *edid = connector->edid_blob_ptr;
> -
> - if (connector->override_edid && edid)
> - seq_write(m, edid->data, edid->length);
> -
> - return 0;
> + return drm_edid_override_show(m->private, m);
>  }
>  
>  static int edid_open(struct inode *inode, struct file *file)
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index a863cffa2dc5..1ada36e0d826 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2183,6 +2183,17 @@ static struct edid *drm_get_override_edid(struct 
> drm_connector *connector,
>   return IS_ERR(override) ? NULL : override;
>  }
>  
> +/* For debugfs edid_override implementation */
> +int drm_edid_override_show(struct drm_connector *connector, struct seq_file 
> *m)
> +{
> + struct drm_property_blob *edid = connector->edid_blob_ptr;
> +
> + if (connector->override_edid && edid)
> + seq_write(m, edid->data, edid->length);
> +
> + return 0;
> +}
> +
>  /* For debugfs edid_override implementation */
>  int drm_edid_override_set(struct drm_connector *connector, const void *edid,
> size_t size)
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 04/15] drm/edid: debug log EDID override set/reset

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:38PM +0300, Jani Nikula wrote:
> It's useful debugging information to know if and when an override EDID
> was set or reset.
> 
> Signed-off-by: Jani Nikula 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/drm_edid.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 47465b9765f1..a863cffa2dc5 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -2194,6 +2194,9 @@ int drm_edid_override_set(struct drm_connector 
> *connector, const void *edid,
>  
>   connector->override_edid = false;
>  
> + drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] EDID override set\n",
> + connector->base.id, connector->name);
> +
>   ret = drm_connector_update_edid_property(connector, edid);
>   if (!ret)
>   connector->override_edid = true;
> @@ -2206,6 +2209,9 @@ int drm_edid_override_reset(struct drm_connector 
> *connector)
>  {
>   connector->override_edid = false;
>  
> + drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] EDID override reset\n",
> + connector->base.id, connector->name);
> +
>   return drm_connector_update_edid_property(connector, NULL);
>  }
>  
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH 02/15] drm/i915/hdmi: stop using connector->override_edid

2022-10-19 Thread Ville Syrjälä
On Tue, Oct 11, 2022 at 04:49:36PM +0300, Jani Nikula wrote:
> The connector->override_edid flag is strictly for EDID override debugfs
> management, and drivers have no business using it.
> 
> The check for override_edid was added in commit 301906290553 ("drm/i915:
> Ignore TMDS clock limit for DP++ when EDID override is set") to
> facilitate mode list cross-checking against modes in override EDID when
> the connector in question isn't even connected. The dual mode detect
> fallback would do VBT based limiting in this case.
> 
> Instead of override EDID, check for connector forcing in the fallback.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index a332eaac86cd..878a65c887f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2374,10 +2374,8 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector 
> *connector)
>* if the port is a dual mode capable DP port.
>*/
>   if (type == DRM_DP_DUAL_MODE_UNKNOWN) {
> - /* An overridden EDID imply that we want this port for testing.
> -  * Make sure not to set limits for that port.
> -  */
> - if (!connector->override_edid &&
> + if (connector->force != DRM_FORCE_ON &&
> + connector->force != DRM_FORCE_ON_DIGITAL &&

I don't think we can get here with force==OFF, so could simply to just
if (!connector->force && ...

which might even be less confusing either way. At least I'm getting
confused thinking we'd want to assume the presence of the adaptor
with force==OFF.

>   intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
>   drm_dbg_kms(&dev_priv->drm,
>   "Assuming DP dual mode adaptor presence 
> based on VBT\n");
> -- 
> 2.34.1

-- 
Ville Syrjälä
Intel


Re: [PATCH] drm/amdkfd: Fix memory leak in kfd_mem_dmamap_userptr()

2022-10-19 Thread Felix Kuehling

On 2022-10-17 21:27, Rafael Mendonca wrote:

If the number of pages from the userptr BO differs from the SG BO then the
allocated memory for the SG table doesn't get freed before returning
-EINVAL, which may lead to a memory leak in some error paths. Fix this by
checking the number of pages before allocating memory for the SG table.

Fixes: 264fb4d332f5 ("drm/amdgpu: Add multi-GPU DMA mapping helpers")
Signed-off-by: Rafael Mendonca 


Thank you for catching this. The patch is

Reviewed-by: Felix Kuehling 

I submitted it to our amd-staging-drm-next branch.

Regards,
  Felix



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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 978d3970b5cc..84f44f7e4111 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -510,13 +510,13 @@ kfd_mem_dmamap_userptr(struct kgd_mem *mem,
struct ttm_tt *ttm = bo->tbo.ttm;
int ret;
  
+	if (WARN_ON(ttm->num_pages != src_ttm->num_pages))

+   return -EINVAL;
+
ttm->sg = kmalloc(sizeof(*ttm->sg), GFP_KERNEL);
if (unlikely(!ttm->sg))
return -ENOMEM;
  
-	if (WARN_ON(ttm->num_pages != src_ttm->num_pages))

-   return -EINVAL;
-
/* Same sequence as in amdgpu_ttm_tt_pin_userptr */
ret = sg_alloc_table_from_pages(ttm->sg, src_ttm->pages,
ttm->num_pages, 0,


Re: [Intel-gfx] [PATCH 01/15] drm/i915/hdmi: do dual mode detect only if connected

2022-10-19 Thread Ville Syrjälä
On Thu, Oct 13, 2022 at 10:24:54PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> > > For normal connector detect, there's really no point in trying dual mode
> > > detect if the connector is disconnected. We can simplify the detect
> > > sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only
> > > called when EDID is present, we can drop the has_edid parameter.
> > > 
> > > The functional effect is speeding up disconnected connector detection
> > > ever so slightly, and, combined with firmware EDID, also stop logging
> > > about assuming dual mode adaptor.
> > > 
> > > It's a bit subtle, but this will also skip dual mode detect if the
> > > connector is force connected and a) there's no EDID of any kind, normal
> > > or override/firmare or b) there's EDID but it does not indicate
> > > digital. These are corner cases no matter what, and arguably forcing
> > > should not be limited by dual mode detect.
> > > 
> > > Cc: Ville Syrjälä 
> > > Signed-off-by: Jani Nikula 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +++--
> > >  1 file changed, 7 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> > > b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > index 93519fb23d9d..a332eaac86cd 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> > > @@ -2355,7 +2355,7 @@ intel_hdmi_unset_edid(struct drm_connector 
> > > *connector)
> > >  }
> > >  
> > >  static void
> > > -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool 
> > > has_edid)
> > > +intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
> > >  {
> > >   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > >   struct intel_hdmi *hdmi = 
> > > intel_attached_hdmi(to_intel_connector(connector));
> > > @@ -2371,16 +2371,13 @@ intel_hdmi_dp_dual_mode_detect(struct 
> > > drm_connector *connector, bool has_edid)
> > >* CONFIG1 pin, but no such luck on our hardware.
> > >*
> > >* The only method left to us is to check the VBT to see
> > > -  * if the port is a dual mode capable DP port. But let's
> > > -  * only do that when we sucesfully read the EDID, to avoid
> > > -  * confusing log messages about DP dual mode adaptors when
> > > -  * there's nothing connected to the port.
> > > +  * if the port is a dual mode capable DP port.
> > >*/
> > >   if (type == DRM_DP_DUAL_MODE_UNKNOWN) {
> > >   /* An overridden EDID imply that we want this port for testing.
> > >* Make sure not to set limits for that port.
> > >*/
> > > - if (has_edid && !connector->override_edid &&
> > > + if (!connector->override_edid &&
> > >   intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
> > >   drm_dbg_kms(&dev_priv->drm,
> > >   "Assuming DP dual mode adaptor presence 
> > > based on VBT\n");
> > > @@ -2435,18 +2432,18 @@ intel_hdmi_set_edid(struct drm_connector 
> > > *connector)
> > >   intel_gmbus_force_bit(i2c, false);
> > >   }
> > >  
> > > - intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
> > > -
> > > - intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref);
> > > -
> > >   to_intel_connector(connector)->detect_edid = edid;
> > >   if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
> > 
> > We didn't have this digital input thing before. What happens with
> > HDMI->VGA dongles for example?
> > 
> > Hmm. This whole thing might already be broken on those. I suspect
> > I've only used my HDMI->VGA dongle on LSPCON machines, so never
> > noticed this. Need to go plug that thing into a native HDMI port...
> 
> Except I must have left it elsewhere since I can't find it here.
> So can't test right now unfortunately.
> 
> I first thought this digital check thing might be due to
> the DVI-I shenanigans in intel_crt_detect_ddc(), but that
> was added for am unspecified gen2 machine in commit f5afcd3dd0dc
> ("drm/i915/crt: Check for a analog monitor in case of DVI-I")
> so not even relevant here. And I don't think I've ever seen
> a g4x+ machine with an actual DVI-I port.

Good news everyone, I found such a board: Intel DG43GT.
Well, I didn't physically find one but I found the manual
online. And some coreboot repo even had the vbt handily
available. And yes, it does show the same DDC pins being
used for the DVI-D port and CRT port. So I guess given
that these digital checks do make some sense.

-- 
Ville Syrjälä
Intel


[pull] amdgpu drm-fixes-6.1

2022-10-19 Thread Alex Deucher
Hi Dave, Daniel,

Fixes for 6.1.  Mostly fixes for new IPs or features added in 6.1.

The following changes since commit 9abf2313adc1ca1b6180c508c25f22f9395cc780:

  Linux 6.1-rc1 (2022-10-16 15:36:24 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-fixes-6.1-2022-10-19

for you to fetch changes up to 8273b4048664fff356fd10059033f0e2f5a422a1:

  drm/amdgpu: Fix for BO move issue (2022-10-18 22:14:07 -0400)


amd-drm-fixes-6.1-2022-10-19:

amdgpu:
- Mode2 reset fixes for Sienna Cichlid
- Revert broken fan speed sensor fix
- SMU 13.x fixes
- GC 11.x fixes
- RAS fixes
- SR-IOV fixes
- Fix BO move breakage on SI
- Misc compiler fixes


Arunpravin Paneer Selvam (1):
  drm/amdgpu: Fix for BO move issue

Asher Song (1):
  drm/amdgpu: Revert "drm/amdgpu: getting fan speed pwm for vega10 properly"

Danijel Slivka (1):
  drm/amdgpu: set vm_update_mode=0 as default for Sienna Cichlid in SRIOV 
case

Evan Quan (3):
  drm/amd/pm: fulfill SMU13.0.0 cstate control interface
  drm/amd/pm: fulfill SMU13.0.7 cstate control interface
  drm/amd/pm: disable cstate feature for gpu reset scenario

Guenter Roeck (1):
  drm/amd/display: Increase frame size limit for display_mode_vba_util_32.o

Kenneth Feng (5):
  drm/amd/pm: temporarily disable thermal alert on smu_v13_0_10
  drm/amd/pm: remove the pptable id override on smu_v13_0_10
  drm/amd/amdgpu: enable gfx clock gating features on smu_v13_0_10
  drm/amd/pm: skip loading pptable from driver on secure board for 
smu_v13_0_10
  drm/amd/pm: enable thermal alert on smu_v13_0_10

Likun Gao (1):
  drm/amdgpu: skip mes self test for gc 11.0.3

Nathan Chancellor (1):
  drm/amdkfd: Fix type of reset_type parameter in hqd_destroy() callback

Tim Huang (2):
  drm/amd/pm: update SMU IP v13.0.4 driver interface version
  drm/amd/pm: add SMU IP v13.0.4 IF version define to V7

Victor Zhao (3):
  Revert "drm/amdgpu: add debugfs amdgpu_reset_level"
  Revert "drm/amdgpu: let mode2 reset fallback to default when failure"
  drm/amdgpu: Refactor mode2 reset logic for v11.0.7

YiPeng Chai (3):
  drm/amdgpu: Enable gmc soft reset on gmc_v11_0_3
  drm/amdgpu: Enable ras support for mp0 v13_0_0 and v13_0_10
  drm/amdgpu: Add sriov vf ras support in amdgpu_ras_asic_supported

Yifan Zha (1):
  drm/amdgpu: Program GC registers through RLCG interface in gfx_v11/gmc_v11

YuBiao Wang (1):
  drm/amdgpu: dequeue mes scheduler during fini

ZhenGuo Yin (1):
  drm/amd/pm: Init pm_attr_list when dpm is disabled

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  4 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v11.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c|  2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 15 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c|  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 25 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c  | 14 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_reset.h  |  3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  3 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  3 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   |  6 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h   |  4 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  6 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c |  3 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 18 +
 drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 45 --
 drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c  |  1 -
 drivers/gpu/drm/amd/amdgpu/mxgpu_nv.c  |  1 -
 drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c  |  1 -
 drivers/gpu/drm/amd/amdgpu/sienna_cichlid.c| 25 
 drivers/gpu/drm/amd/amdgpu/soc21.c |  7 +++-
 drivers/gpu/drm/amd/display/dc/dml/Makefile|  2 +-
 drivers/gpu/drm/amd/include/kgd_kfd_interface.h|  5 ++-
 drivers/gpu/drm/amd/pm/amdgpu_pm.c |  4 +-
 .../drm/amd/pm/powerplay/hwmgr/vega10_thermal.c| 25 ++--
 drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c  |  4 +-
 .../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h | 17 +++-
 drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h   |  2 +-
 drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c  |  8 
 drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c |  9 +
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c |  6 +--
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c   | 11 ++
 .../gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c   | 12 ++
 34 files changed, 204 insertions(+), 91 deletions(-)


Re: [PATCH v4 12/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

2022-10-19 Thread Niranjana Vishwanathapura

On Wed, Oct 19, 2022 at 04:20:49PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.

The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects binding would have been requested by the
userspace before submitting the execbuf3.

Legacy features like relocations etc are not supported by execbuf3.

v2: Add more input validity checks.
v3: batch_address is a VA (not an array) if num_batches=1,
minor cleanup
v4: replace vm->vm_bind_mode check with i915_gem_vm_is_vm_bind_mode()

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_execbuffer3.c   | 580 ++
 drivers/gpu/drm/i915/gem/i915_gem_ioctls.h|   2 +
 drivers/gpu/drm/i915/i915_driver.c|   1 +
 include/uapi/drm/i915_drm.h   |  61 ++
 5 files changed, 645 insertions(+)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 8d76bb888dc3..6a801684d569 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -150,6 +150,7 @@ gem-y += \
gem/i915_gem_domain.o \
gem/i915_gem_execbuffer_common.o \
gem/i915_gem_execbuffer.o \
+   gem/i915_gem_execbuffer3.o \
gem/i915_gem_internal.o \
gem/i915_gem_object.o \
gem/i915_gem_lmem.o \
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
new file mode 100644
index ..a9b4cc44bf66
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer3.c
@@ -0,0 +1,580 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+#include 
+
+#include 
+
+#include "gt/intel_context.h"
+#include "gt/intel_gpu_commands.h"
+#include "gt/intel_gt.h"
+
+#include "i915_drv.h"
+#include "i915_gem_context.h"
+#include "i915_gem_execbuffer_common.h"
+#include "i915_gem_ioctls.h"
+#include "i915_gem_vm_bind.h"
+#include "i915_trace.h"
+
+#define __EXEC3_ENGINE_PINNED  BIT_ULL(32)
+#define __EXEC3_INTERNAL_FLAGS (~0ull << 32)
+
+/* Catch emission of unexpected errors for CI! */
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+#undef EINVAL
+#define EINVAL ({ \
+   DRM_DEBUG_DRIVER("EINVAL at %s:%d\n", __func__, __LINE__); \
+   22; \
+})
+#endif
+
+/**
+ * DOC: User command execution with execbuf3 ioctl
+ *
+ * A VM in VM_BIND mode will not support older execbuf mode of binding.
+ * The execbuf ioctl handling in VM_BIND mode differs significantly from the
+ * older execbuf2 ioctl (See struct drm_i915_gem_execbuffer2).
+ * Hence, a new execbuf3 ioctl has been added to support VM_BIND mode. (See
+ * struct drm_i915_gem_execbuffer3). The execbuf3 ioctl will not accept any
+ * execlist. Hence, no support for implicit sync.
+ *
+ * The new execbuf3 ioctl only works in VM_BIND mode and the VM_BIND mode only
+ * works with execbuf3 ioctl for submission.
+ *
+ * The execbuf3 ioctl directly specifies the batch addresses instead of as
+ * object handles as in execbuf2 ioctl. The execbuf3 ioctl will also not
+ * support many of the older features like in/out/submit fences, fence array,
+ * default gem context etc. (See struct drm_i915_gem_execbuffer3).
+ *
+ * In VM_BIND mode, VA allocation is completely managed by the user instead of
+ * the i915 driver. Hence all VA assignment, eviction are not applicable in
+ * VM_BIND mode. Also, for determining object activeness, VM_BIND mode will not
+ * be using the i915_vma active reference tracking. It will instead check the
+ * dma-resv object's fence list for that.
+ *
+ * So, a lot of code supporting execbuf2 ioctl, like relocations, VA evictions,
+ * vma lookup table, implicit sync, vma active reference tracking etc., are not
+ * applicable for execbuf3 ioctl.
+ */
+
+/**
+ * struct i915_execbuffer - execbuf struct for execbuf3
+ * @i915: reference to the i915 instance we run on
+ * @file: drm file reference
+ * args: execbuf3 ioctl structure
+ * @gt: reference to the gt instance ioctl submitted for
+ * @context: logical state for the request
+ * @gem_context: callers context
+ * @requests: requests to be build
+ * @composite_fence: used for excl fence in dma_resv objects when > 1 BB 
submitted
+ * @ww: i915_gem_ww_ctx instance
+ * @num_batches: number of batches submitted
+ * @batch_addresses: addresses corresponds to the submitted batches
+ * @batches: references to the i915_vmas corresponding to the batches
+ */


Are we building/including the docs for this somewhere? Looks like we 
are missing some stuff like @fences/@num_fences in the kernel-doc.


Looks like we are not. Will include it in Documentation/gpu/i915.rst
and also include vm_bind+ex

Re: [PATCH 01/15] drm/i915/hdmi: do dual mode detect only if connected

2022-10-19 Thread Ville Syrjälä
On Fri, Oct 14, 2022 at 11:14:43AM +0300, Jani Nikula wrote:
> On Thu, 13 Oct 2022, Ville Syrjälä  wrote:
> > On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
> >> On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> >> > For normal connector detect, there's really no point in trying dual mode
> >> > detect if the connector is disconnected. We can simplify the detect
> >> > sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only
> >> > called when EDID is present, we can drop the has_edid parameter.
> >> > 
> >> > The functional effect is speeding up disconnected connector detection
> >> > ever so slightly, and, combined with firmware EDID, also stop logging
> >> > about assuming dual mode adaptor.
> >> > 
> >> > It's a bit subtle, but this will also skip dual mode detect if the
> >> > connector is force connected and a) there's no EDID of any kind, normal
> >> > or override/firmare or b) there's EDID but it does not indicate
> >> > digital. These are corner cases no matter what, and arguably forcing
> >> > should not be limited by dual mode detect.
> >> > 
> >> > Cc: Ville Syrjälä 
> >> > Signed-off-by: Jani Nikula 
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_hdmi.c | 17 +++--
> >> >  1 file changed, 7 insertions(+), 10 deletions(-)
> >> > 
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> >> > b/drivers/gpu/drm/i915/display/intel_hdmi.c
> >> > index 93519fb23d9d..a332eaac86cd 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> >> > @@ -2355,7 +2355,7 @@ intel_hdmi_unset_edid(struct drm_connector 
> >> > *connector)
> >> >  }
> >> >  
> >> >  static void
> >> > -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool 
> >> > has_edid)
> >> > +intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
> >> >  {
> >> >  struct drm_i915_private *dev_priv = to_i915(connector->dev);
> >> >  struct intel_hdmi *hdmi = 
> >> > intel_attached_hdmi(to_intel_connector(connector));
> >> > @@ -2371,16 +2371,13 @@ intel_hdmi_dp_dual_mode_detect(struct 
> >> > drm_connector *connector, bool has_edid)
> >> >   * CONFIG1 pin, but no such luck on our hardware.
> >> >   *
> >> >   * The only method left to us is to check the VBT to see
> >> > - * if the port is a dual mode capable DP port. But let's
> >> > - * only do that when we sucesfully read the EDID, to avoid
> >> > - * confusing log messages about DP dual mode adaptors when
> >> > - * there's nothing connected to the port.
> >> > + * if the port is a dual mode capable DP port.
> >> >   */
> >> >  if (type == DRM_DP_DUAL_MODE_UNKNOWN) {
> >> >  /* An overridden EDID imply that we want this port for 
> >> > testing.
> >> >   * Make sure not to set limits for that port.
> >> >   */
> >> > -if (has_edid && !connector->override_edid &&
> >> > +if (!connector->override_edid &&
> >> >  intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
> >> >  drm_dbg_kms(&dev_priv->drm,
> >> >  "Assuming DP dual mode adaptor 
> >> > presence based on VBT\n");
> >> > @@ -2435,18 +2432,18 @@ intel_hdmi_set_edid(struct drm_connector 
> >> > *connector)
> >> >  intel_gmbus_force_bit(i2c, false);
> >> >  }
> >> >  
> >> > -intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
> >> > -
> >> > -intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS, wakeref);
> >> > -
> >> >  to_intel_connector(connector)->detect_edid = edid;
> >> >  if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
> >> 
> >> We didn't have this digital input thing before. What happens with
> >> HDMI->VGA dongles for example?
> >> 
> >> Hmm. This whole thing might already be broken on those. I suspect
> >> I've only used my HDMI->VGA dongle on LSPCON machines, so never
> >> noticed this. Need to go plug that thing into a native HDMI port...
> >
> > Except I must have left it elsewhere since I can't find it here.
> > So can't test right now unfortunately.
> >
> > I first thought this digital check thing might be due to
> > the DVI-I shenanigans in intel_crt_detect_ddc(), but that
> > was added for am unspecified gen2 machine in commit f5afcd3dd0dc
> > ("drm/i915/crt: Check for a analog monitor in case of DVI-I")
> > so not even relevant here. And I don't think I've ever seen
> > a g4x+ machine with an actual DVI-I port.
> >
> > commit aa93d632c496 ("drm/i915: Require digital monitor
> > on HDMI ports for detect") is where this check was added,
> > but there is no actual justification for checking the
> > digital thing vs. just making sure the edid read succeeded.
> >
> > So looks to me like this check can just be removed. And
> > if we do come across some real D

Re: [PATCH v4 13/17] drm/i915/vm_bind: Update i915_vma_verify_bind_complete()

2022-10-19 Thread Niranjana Vishwanathapura

On Wed, Oct 19, 2022 at 05:07:31PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
and move it out of CONFIG_DRM_I915_DEBUG_GEM.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/i915_vma.c | 16 +++-
 drivers/gpu/drm/i915/i915_vma.h |  1 +
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index eaa13e9ba966..4975fc662c86 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -439,12 +439,21 @@ int i915_vma_sync(struct i915_vma *vma)
return i915_vm_sync(vma->vm);
 }
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
-static int i915_vma_verify_bind_complete(struct i915_vma *vma)
+/**
+ * i915_vma_verify_bind_complete() - Check for the bind completion of the vma
+ * @vma: vma to check for bind completion


Maybe mention the locking since this is now more than just DEBUG_GEM 
stuff. I assume we need the object lock or otherwise some guarantee 
that the vma is pinned?


Reviewed-by: Matthew Auld 



I think they are not needed. The fence reference is obtained under rcu
lock anyhow (will add this to documentation). Only thing required is
that vma is not released, but that caller must ensure for all i915_vma
apis anyhow.

Thanks,
Niranjana


+ *
+ * Returns: 0 if the vma bind is completed. Error code otherwise.
+ */
+int i915_vma_verify_bind_complete(struct i915_vma *vma)
 {
struct dma_fence *fence = i915_active_fence_get(&vma->active.excl);
int err;
+   /* Ensure vma bind is initiated */
+   if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
+   return -EINVAL;
+
if (!fence)
return 0;
@@ -457,9 +466,6 @@ static int i915_vma_verify_bind_complete(struct i915_vma 
*vma)
return err;
 }
-#else
-#define i915_vma_verify_bind_complete(_vma) 0
-#endif
 I915_SELFTEST_EXPORT void
 i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res,
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 1cadbf8fdedf..04770f8ba815 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -440,6 +440,7 @@ void i915_vma_make_purgeable(struct i915_vma *vma);
 int i915_vma_wait_for_bind(struct i915_vma *vma);
 int i915_vma_sync(struct i915_vma *vma);
+int i915_vma_verify_bind_complete(struct i915_vma *vma);
 /**
  * i915_vma_get_current_resource - Get the current resource of the vma


Re: [PATCH] drm/bridge: ps8640: Add back the 50 ms mystery delay after HPD

2022-10-19 Thread Doug Anderson
Hi,

On Wed, Oct 19, 2022 at 11:18 AM Stephen Boyd  wrote:
>
> Quoting Douglas Anderson (2022-10-17 12:18:51)
> > Back in commit 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable
> > runtime power management") we removed a mysterious 50 ms delay because
> > "Parade's support [couldn't] explain what the delay [was] for".
> >
> > While I'm always a fan of removing mysterious delays, I suspect that
> > we need this mysterious delay to avoid some problems.
> >
> > Specifically, what I found recently is that on sc7180-trogdor-homestar
> > sometimes the AUX backlight wasn't initializing properly. Some
> > debugging showed that the drm_dp_dpcd_read() function that the AUX
> > backlight driver was calling was returning bogus data about 1% of the
> > time when I booted up. This confused
> > drm_panel_dp_aux_backlight(). From continued debugging:
> > - If I retried the read then the read worked just fine.
> > - If I added a loop to perform the same read that
> >   drm_panel_dp_aux_backlight() was doing 30 times at bootup I could
> >   see that some percentage of the time the first read would give bogus
> >   data but all 29 additional reads would always be fine.
> > - If I added a large delay _after_ powering on the panel but before
> >   powering on PS8640 I could still reproduce the problem.
> > - If I added a delay after PS8640 powered on then I couldn't reproduce
> >   the problem.
> > - I couldn't reproduce the problem on a board with the same panel but
> >   the ti-sn65dsi86 bridge chip.
> >
> > To me, the above indicated that there was a problem with PS8640 and
> > not the panel.
> >
> > I don't really have any insight into what's going on in the MCU, but
> > my best guess is that when the MCU itself sees the HPD go high that it
> > does some AUX transfers itself and this is confusing things.
> >
> > Let's go back and add back in the mysterious 50 ms delay. We only want
> > to do this the first time we see HPD go high after booting the MCU,
> > not every time we double-check HPD.
> >
> > With this, the backlight initializes reliably on homestar.
> >
> > Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power 
> > management")
> > Signed-off-by: Douglas Anderson 
> > ---
>
> Reviewed-by: Stephen Boyd 

I'm not expecting any other reviews of this patch, though I'm happy to
be proven wrong. As a heads up, I'll plan to land this on Friday
(roughly 2 days from now) in "drm-misc-fixes" barring anything else.
If anyone else plans to offer any opinions about this patch or just
wants more time to review, please shout.

-Doug


Re: [PATCH] drm/bridge: ps8640: Add back the 50 ms mystery delay after HPD

2022-10-19 Thread Stephen Boyd
Quoting Douglas Anderson (2022-10-17 12:18:51)
> Back in commit 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable
> runtime power management") we removed a mysterious 50 ms delay because
> "Parade's support [couldn't] explain what the delay [was] for".
>
> While I'm always a fan of removing mysterious delays, I suspect that
> we need this mysterious delay to avoid some problems.
>
> Specifically, what I found recently is that on sc7180-trogdor-homestar
> sometimes the AUX backlight wasn't initializing properly. Some
> debugging showed that the drm_dp_dpcd_read() function that the AUX
> backlight driver was calling was returning bogus data about 1% of the
> time when I booted up. This confused
> drm_panel_dp_aux_backlight(). From continued debugging:
> - If I retried the read then the read worked just fine.
> - If I added a loop to perform the same read that
>   drm_panel_dp_aux_backlight() was doing 30 times at bootup I could
>   see that some percentage of the time the first read would give bogus
>   data but all 29 additional reads would always be fine.
> - If I added a large delay _after_ powering on the panel but before
>   powering on PS8640 I could still reproduce the problem.
> - If I added a delay after PS8640 powered on then I couldn't reproduce
>   the problem.
> - I couldn't reproduce the problem on a board with the same panel but
>   the ti-sn65dsi86 bridge chip.
>
> To me, the above indicated that there was a problem with PS8640 and
> not the panel.
>
> I don't really have any insight into what's going on in the MCU, but
> my best guess is that when the MCU itself sees the HPD go high that it
> does some AUX transfers itself and this is confusing things.
>
> Let's go back and add back in the mysterious 50 ms delay. We only want
> to do this the first time we see HPD go high after booting the MCU,
> not every time we double-check HPD.
>
> With this, the backlight initializes reliably on homestar.
>
> Fixes: 826cff3f7ebb ("drm/bridge: parade-ps8640: Enable runtime power 
> management")
> Signed-off-by: Douglas Anderson 
> ---

Reviewed-by: Stephen Boyd 


Re: [PATCH v4 14/17] drm/i915/vm_bind: Expose i915_request_await_bind()

2022-10-19 Thread Niranjana Vishwanathapura

On Wed, Oct 19, 2022 at 05:09:32PM +0100, Matthew Auld wrote:

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Rename __i915_request_await_bind() as i915_request_await_bind()
and make it non-static as it will be used in execbuf3 ioctl path.

Reviewed-by: Andi Shyti 
Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/i915_vma.c | 8 +---
 drivers/gpu/drm/i915/i915_vma.h | 6 ++
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4975fc662c86..ab89e907f2eb 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1884,18 +1884,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(&vma->obj->userfault_link);
 }
-static int
-__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
-{
-   return __i915_request_await_exclusive(rq, &vma->active);
-}
-
 static int __i915_vma_move_to_active(struct i915_vma *vma, struct i915_request 
*rq)
 {
int err;
/* Wait for the vma to be bound before we start! */
-   err = __i915_request_await_bind(rq, vma);
+   err = i915_request_await_bind(rq, vma);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 04770f8ba815..19e57e12b956 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -54,6 +54,12 @@ void i915_vma_unpin_and_release(struct i915_vma **p_vma, 
unsigned int flags);
 /* do not reserve memory to prevent deadlocks */
 #define __EXEC_OBJECT_NO_RESERVE BIT(31)
+static inline int
+i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)


Some kernel doc might be good?

Reviewed-by: Matthew Auld 



Ok, will add.

Thanks,
Niranjana


+{
+   return __i915_request_await_exclusive(rq, &vma->active);
+}
+
 int __must_check _i915_vma_move_to_active(struct i915_vma *vma,
  struct i915_request *rq,
  struct dma_fence *fence,


Re: [PATCH v1 6/7] vfio/ccw: replace vfio_init_device with _alloc_

2022-10-19 Thread Eric Farman
On Wed, 2022-10-19 at 14:15 -0300, Jason Gunthorpe wrote:
> On Wed, Oct 19, 2022 at 06:21:34PM +0200, Eric Farman wrote:
> 
> >  /*
> >   * Initialize a vfio_device so it can be registered to vfio core.
> > - *
> > - * Only vfio-ccw driver should call this interface.
> >   */
> >  int vfio_init_device(struct vfio_device *device, struct device
> > *dev,
> >  const struct vfio_device_ops *ops)
> > @@ -422,7 +420,6 @@ int vfio_init_device(struct vfio_device
> > *device, struct device *dev,
> > ida_free(&vfio.device_ida, device->index);
> > return ret;
> >  }
> > -EXPORT_SYMBOL_GPL(vfio_init_device);
> 
> Should be made static as well

Agreed. Only reason I didn't was there's a prototype in
include/linux/vfio.h to satisfy the call to vfio_init_device from
_vfio_alloc_device, and I didn't want to get into moving things around
if I didn't need to. I can do that on top, if you'd like.

Eric


Re: [PATCH 14/17] ARM: omap1: remove dead code

2022-10-19 Thread Aaro Koskinen
Hi,

On Wed, Oct 19, 2022 at 05:03:36PM +0200, Arnd Bergmann wrote:
>  drivers/usb/phy/phy-isp1301-omap.c | 91 +-

This driver and config option ISP1301_OMAP can be deleted altogether as
there are no users after H2/H3 boards are gone.

A.


Re: [PATCH] ACPI: PCI: Fix device reference counting in acpi_get_pci_dev()

2022-10-19 Thread Ville Syrjälä
On Wed, Oct 19, 2022 at 11:53:26AM -0500, Bjorn Helgaas wrote:
> On Wed, Oct 19, 2022 at 11:54:42AM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 18, 2022 at 07:34:03PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki 
> > > 
> > > Commit 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()") failed
> > > to reference count the device returned by acpi_get_pci_dev() as
> > > expected by its callers which in some cases may cause device objects
> > > to be dropped prematurely.
> > > 
> > > Add the missing get_device() to acpi_get_pci_dev().
> > > 
> > > Fixes: 63f534b8bad9 ("ACPI: PCI: Rework acpi_get_pci_dev()")
> > 
> > FYI this (and the rtc-cmos regression discussed in
> > https://lore.kernel.org/linux-acpi/5887691.lOV4Wx5bFT@kreacher/)
> > took down the entire Intel gfx CI.
> 
> >From 1000 miles away and zero background with the gfx CI, this sounds
> like "our CI system, whose purpose is to find bugs, found one", which
> is a good thing.

Mostly. It's certainly better than it going entirely undetected.

Sadly we found it after rc1 because no one was really looking at
linux-next results. Something we need to improve.

But ideally it would have been found by some other CI system
whose primary job is to prevent bugs in those subsystems, rather
than the one whose primary job is to prevent bugs in gfx drivers.
Also ideally it wouldn't have been me bisecting this :P

The biggest downside of bugs reaching our CI via rc1/etc. is that
it pretty much stops everyone from getting premerge results for
their graphics driver patches since the CI keeps tripping over
the already existing bugs. But I guess you can call this one a
somewhat self inflicted wound and we should just try harder to
keep new code out of our tree until it's known to be healthy.

-- 
Ville Syrjälä
Intel


Re: [PATCH] drm: tests: Fix a buffer overflow in format_helper_test

2022-10-19 Thread José Expósito
On Wed, Oct 19, 2022 at 03:32:40PM +0800, David Gow wrote:
> The xrgb2101010 format conversion test (unlike for other formats) does
> an endianness conversion on the results. However, it always converts
> TEST_BUF_SIZE 32-bit integers, which results in reading from (and
> writing to) more memory than in present in the result buffer. Instead,
> use the buffer size, divided by sizeof(u32).
> 
> The issue could be reproduced with KASAN:
> ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
>   --kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
>   --kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
>   drm_format_helper_test.*xrgb2101010
> 
> Reported-by: Linux Kernel Functional Testing 
> Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for 
> drm_fb_xrgb_to_xrgb2101010()")
> Signed-off-by: David Gow 
> ---
> 
> This is a fix for the issue reported here:
> https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=k8p...@mail.gmail.com/
> 
> Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
> https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairaca...@riseup.net/
> 
> Cheers,
> -- David
> 
> ---
>  drivers/gpu/drm/tests/drm_format_helper_test.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tests/drm_format_helper_test.c 
> b/drivers/gpu/drm/tests/drm_format_helper_test.c
> index 8d86c250c2ec..2191e57f2297 100644
> --- a/drivers/gpu/drm/tests/drm_format_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_format_helper_test.c
> @@ -438,7 +438,7 @@ static void drm_test_fb_xrgb_to_xrgb2101010(struct 
> kunit *test)
>   iosys_map_set_vaddr(&src, xrgb);
>  
>   drm_fb_xrgb_to_xrgb2101010(&dst, &result->dst_pitch, &src, &fb, 
> ¶ms->clip);
> - buf = le32buf_to_cpu(test, buf, TEST_BUF_SIZE);
> + buf = le32buf_to_cpu(test, buf, dst_size / sizeof(u32));
>   KUNIT_EXPECT_EQ(test, memcmp(buf, result->expected, dst_size), 0);
>  }

Thanks a lot for fixing this bug David, I just tested it and
worked as expected.

Do you think that we should update the other calls to
le32buf_to_cpu() to follow a similar approach?

Regardless of a possible follow up patch:
Reviewed-by: José Expósito 

Jose

>  
> -- 
> 2.38.0.413.g74048e4d9e-goog
> 


[PATCH] gpu: host1x: Avoid trying to use GART on Tegra20

2022-10-19 Thread Robin Murphy
Since commit c7e3ca515e78 ("iommu/tegra: gart: Do not register with
bus") quite some time ago, the GART driver has effectively disabled
itself to avoid issues with the GPU driver expecting it to work in ways
that it doesn't. As of commit 57365a04c921 ("iommu: Move bus setup to
IOMMU device registration") that bodge no longer works, but really the
GPU driver should be responsible for its own behaviour anyway. Make the
workaround explicit.

Reported-by: Jon Hunter 
Suggested-by: Dmitry Osipenko 
Signed-off-by: Robin Murphy 
---
 drivers/gpu/host1x/dev.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index a13fd9441edc..1cae8eea92cf 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -352,6 +352,10 @@ static struct iommu_domain *host1x_iommu_attach(struct 
host1x *host)
if (!host1x_wants_iommu(host) || domain)
return domain;
 
+   /* Our IOMMU usage policy doesn't currently play well with GART */
+   if (of_machine_is_compatible("nvidia,tegra20"))
+   return NULL;
+
host->group = iommu_group_get(host->dev);
if (host->group) {
struct iommu_domain_geometry *geometry;
-- 
2.36.1.dirty



Re: [PATCH v1 0/7] vfio-ccw parent rework

2022-10-19 Thread Jason Gunthorpe
On Wed, Oct 19, 2022 at 06:21:28PM +0200, Eric Farman wrote:

> This series attempts to address the oddities/shortcomings of vfio-ccw, such
> that vfio-ccw can use the same helpers as everyone else, and the tricks that
> were implemented by the other drivers can be removed. It is built on 6.1-rc1,
> and thus includes the various changes [3][4] that have occurred in and around
> these parts.

It looks good to me if you are happy with the ccw part

Thanks,
Jason


Re: [PATCH v1 7/7] vfio: Remove vfio_free_device

2022-10-19 Thread Jason Gunthorpe
On Wed, Oct 19, 2022 at 06:21:35PM +0200, Eric Farman wrote:
> With the "mess" sorted out, we should be able to inline the
> vfio_free_device call introduced by commit cb9ff3f3b84c
> ("vfio: Add helpers for unifying vfio_device life cycle")
> and remove them from driver release callbacks.
> 
> Signed-off-by: Eric Farman 

Reviewed-by: Jason Gunthorpe 

Jason


Re: [PATCH v1 6/7] vfio/ccw: replace vfio_init_device with _alloc_

2022-10-19 Thread Jason Gunthorpe
On Wed, Oct 19, 2022 at 06:21:34PM +0200, Eric Farman wrote:

>  /*
>   * Initialize a vfio_device so it can be registered to vfio core.
> - *
> - * Only vfio-ccw driver should call this interface.
>   */
>  int vfio_init_device(struct vfio_device *device, struct device *dev,
>const struct vfio_device_ops *ops)
> @@ -422,7 +420,6 @@ int vfio_init_device(struct vfio_device *device, struct 
> device *dev,
>   ida_free(&vfio.device_ida, device->index);
>   return ret;
>  }
> -EXPORT_SYMBOL_GPL(vfio_init_device);

Should be made static as well

Jason


Re: [RFC PATCH v5 5/6] drm/tidss: Add IO CTRL and Power support for OLDI TX in am625

2022-10-19 Thread Aradhya Bhatia

Hi Tomi

On 12-Oct-22 17:59, Tomi Valkeinen wrote:

On 28/09/2022 20:52, Aradhya Bhatia wrote:

The ctrl mmr module of the AM625 is different from the AM65X SoC. Thus
the ctrl mmr registers that supported the OLDI TX power have become
different in AM625 SoC.

Add IO CTRL support and control the OLDI TX power for AM625.

Signed-off-by: Aradhya Bhatia 
---
  drivers/gpu/drm/tidss/tidss_dispc.c  | 55 ++--
  drivers/gpu/drm/tidss/tidss_dispc_regs.h |  6 +++
  2 files changed, 49 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c 
b/drivers/gpu/drm/tidss/tidss_dispc.c

index 88008ad39b55..68444e0cd8d7 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -921,21 +921,52 @@ int dispc_vp_bus_check(struct dispc_device 
*dispc, u32 hw_videoport,

  static void dispc_oldi_tx_power(struct dispc_device *dispc, bool power)
  {
-    u32 val = power ? 0 : OLDI_PWRDN_TX;
+    u32 val;
  if (WARN_ON(!dispc->oldi_io_ctrl))
  return;
-    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT0_IO_CTRL,
-   OLDI_PWRDN_TX, val);
-    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT1_IO_CTRL,
-   OLDI_PWRDN_TX, val);
-    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT2_IO_CTRL,
-   OLDI_PWRDN_TX, val);
-    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT3_IO_CTRL,
-   OLDI_PWRDN_TX, val);
-    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_CLK_IO_CTRL,
-   OLDI_PWRDN_TX, val);
+    if (dispc->feat->subrev == DISPC_AM65X) {
+    val = power ? 0 : OLDI_PWRDN_TX;
+
+    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT0_IO_CTRL,
+   OLDI_PWRDN_TX, val);
+    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT1_IO_CTRL,
+   OLDI_PWRDN_TX, val);
+    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT2_IO_CTRL,
+   OLDI_PWRDN_TX, val);
+    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_DAT3_IO_CTRL,
+   OLDI_PWRDN_TX, val);
+    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_CLK_IO_CTRL,
+   OLDI_PWRDN_TX, val);
+
+    } else if (dispc->feat->subrev == DISPC_AM625) {
+    if (power) {
+    switch (dispc->oldi_mode) {
+    case OLDI_SINGLE_LINK_SINGLE_MODE:
+    /* Power down OLDI TX 1 */
+    val = OLDI1_PWRDN_TX;
+    break;
+
+    case OLDI_SINGLE_LINK_CLONE_MODE:
+    case OLDI_DUAL_LINK_MODE:
+    /* No Power down */
+    val = 0;
+    break;
+
+    default:
+    /* Power down both the OLDI TXes */
+    val = OLDI0_PWRDN_TX | OLDI1_PWRDN_TX;
+    break;
+    }
+    } else {
+    /* Power down both the OLDI TXes */
+    val = OLDI0_PWRDN_TX | OLDI1_PWRDN_TX;
+    }


Ugh, I hate power-down bits. So you "enable" it to disable it =). What's 
the default value or the register here? Or will this always be called? 
I.e. if we only use DPI, do we power down the OLDIs somewhere (or does 
it matter)?




The power bits are defaulted to keep the OLDI TXes powered off, and they
have to be turned ON.

This function is also called to power off the OLDI TXes, from
dispc_vp_unprepare. And that happens with "power" variable as false. So
the else condition above is indeed required.

You are right about the other scenario though. If DPI is only used, the
mode will be set to OLDI_MODE_OFF and in that case, the dispc_vp_prepare
function will NOT be called for the OLDI VP thereby rendering the
"default" clause of the switch statement, for powering down the OLDIs,
essentially useless. I just put it there because of convention.


+
+    regmap_update_bits(dispc->oldi_io_ctrl, OLDI_PD_CTRL,
+   OLDI0_PWRDN_TX | OLDI1_PWRDN_TX, val);
+    }
  }
  static void dispc_set_num_datalines(struct dispc_device *dispc,
@@ -2831,7 +2862,7 @@ int dispc_init(struct tidss_device *tidss)
  dispc->vp_data[i].gamma_table = gamma_table;
  }
-    if (feat->subrev == DISPC_AM65X) {
+    if (feat->subrev == DISPC_AM65X || feat->subrev == DISPC_AM625) {
  r = dispc_init_am65x_oldi_io_ctrl(dev, dispc);
  if (r)
  return r;
diff --git a/drivers/gpu/drm/tidss/tidss_dispc_regs.h 
b/drivers/gpu/drm/tidss/tidss_dispc_regs.h

index 13feedfe5d6d..510bee70b3b8 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc_regs.h
+++ b/drivers/gpu/drm/tidss/tidss_dispc_regs.h
@@ -238,6 +238,12 @@ enum dispc_common_regs {
  #define OLDI_DAT3_IO_CTRL    0x0C
  #define OLDI_CLK_IO_CTRL    0x10
+/* Only for AM625 OLDI TX */
+#define OLDI_PD_CTRL    0x100
+#define OLDI_LB_CTRL    0x104
+
  #define OLDI_PWRDN_TX    BIT(8)
+#define OLDI0_PWRDN_TX    BIT(0)
+#define OLDI1_PWRDN_TX    BIT(1)


Maybe these (the new and old ones) should be platfo

Re: [PATCH 5/6] drm/radeon: fix’s on ttm_resource rework to use size_t type

2022-10-19 Thread Christian König




Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:

Fix the ttm_resource from num_pages to size_t size.

Signed-off-by: Somalapuram Amaranath 
---
  drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
  drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
  drivers/gpu/drm/radeon/radeon_trace.h  | 2 +-
  drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
  4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 446f7bae54c4..4c930f0cf132 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -400,8 +400,8 @@ static int cmp_size_smaller_first(void *priv, const struct 
list_head *a,
struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list, 
tv.head);
  
  	/* Sort A before B if A is smaller. */

-   return (int)la->robj->tbo.resource->num_pages -
-   (int)lb->robj->tbo.resource->num_pages;
+   return (int)PFN_UP(la->robj->tbo.resource->size) -
+   (int)PFN_UP(lb->robj->tbo.resource->size);


I think you can drop the conversion and PFN_UP. What we need here is a 
compare result. Something like this:


if (la->robj->tbo.resource->size > lb->robj->tbo.resource->size)
    return 1;
if (la->robj->tbo.resource->size < lb->robj->tbo.resource->size)
    return -1;
return 0;

And I think it makes more sense to use tbo.base.size here as well 
instead of the resource size.


Regards,
Christian.


  }
  
  /**

diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 00c33b24d5d3..710d04fcbea6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -232,7 +232,7 @@ int radeon_bo_kmap(struct radeon_bo *bo, void **ptr)
}
return 0;
}
-   r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+   r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.resource->size), &bo->kmap);
if (r) {
return r;
}
@@ -737,7 +737,7 @@ vm_fault_t radeon_bo_fault_reserve_notify(struct 
ttm_buffer_object *bo)
if (bo->resource->mem_type != TTM_PL_VRAM)
return 0;
  
-	size = bo->resource->num_pages << PAGE_SHIFT;

+   size = bo->resource->size;
offset = bo->resource->start << PAGE_SHIFT;
if ((offset + size) <= rdev->mc.visible_vram_size)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h 
b/drivers/gpu/drm/radeon/radeon_trace.h
index c9fed5f2b870..22676617e1a5 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -22,7 +22,7 @@ TRACE_EVENT(radeon_bo_create,
  
  	TP_fast_assign(

   __entry->bo = bo;
-  __entry->pages = bo->tbo.resource->num_pages;
+  __entry->pages = PFN_UP(bo->tbo.resource->size);
   ),
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
  );
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d33fec488713..fff48306c05f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -181,7 +181,7 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
  
  	BUILD_BUG_ON((PAGE_SIZE % RADEON_GPU_PAGE_SIZE) != 0);
  
-	num_pages = new_mem->num_pages * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);

+   num_pages = PFN_UP(new_mem->size) * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
fence = radeon_copy(rdev, old_start, new_start, num_pages, 
bo->base.resv);
if (IS_ERR(fence))
return PTR_ERR(fence);
@@ -268,7 +268,7 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
  static int radeon_ttm_io_mem_reserve(struct ttm_device *bdev, struct 
ttm_resource *mem)
  {
struct radeon_device *rdev = radeon_get_rdev(bdev);
-   size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+   size_t bus_size = (size_t)mem->size;
  
  	switch (mem->mem_type) {

case TTM_PL_SYSTEM:




Re: [PATCH 4/6] drm/nouveau: fix’s on ttm_resource rework to use size_t type

2022-10-19 Thread Christian König

Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:

Fix the ttm_resource from num_pages to size_t size.

Signed-off-by: Somalapuram Amaranath 


I'm not an expert for nouveau so it might be possible that we better use 
bo->base.size instead of bo->resource->size at some places. But that can 
be cleaned up later if anybody really cares.


Acked-by: Christian König 


---
  drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
  drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
  drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
  drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
  drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
  drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
  drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
  drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
  drivers/gpu/drm/nouveau/nouveau_gem.c| 5 ++---
  drivers/gpu/drm/nouveau/nouveau_mem.c| 4 ++--
  drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
  11 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 126b3c6e12f9..16ca4a141866 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -532,7 +532,7 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
if (ret)
return ret;
  
-	ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.resource->num_pages, &nvbo->kmap);

+   ret = ttm_bo_kmap(&nvbo->bo, 0, PFN_UP(nvbo->bo.resource->size), 
&nvbo->kmap);
  
  	ttm_bo_unreserve(&nvbo->bo);

return ret;
@@ -1236,7 +1236,7 @@ vm_fault_t nouveau_ttm_fault_reserve_notify(struct 
ttm_buffer_object *bo)
} else {
/* make sure bo is in mappable vram */
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
-   bo->resource->start + bo->resource->num_pages < mappable)
+   bo->resource->start + PFN_UP(bo->resource->size) < mappable)
return 0;
  
  		for (i = 0; i < nvbo->placement.num_placement; ++i) {

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo0039.c 
b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
index 7390132129fe..e2ce44adaa5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo0039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
@@ -52,7 +52,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
u32 src_offset = old_reg->start << PAGE_SHIFT;
u32 dst_ctxdma = nouveau_bo_mem_ctxdma(bo, chan, new_reg);
u32 dst_offset = new_reg->start << PAGE_SHIFT;
-   u32 page_count = new_reg->num_pages;
+   u32 page_count = PFN_UP(new_reg->size);
int ret;
  
  	ret = PUSH_WAIT(push, 3);

@@ -62,7 +62,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
PUSH_MTHD(push, NV039, SET_CONTEXT_DMA_BUFFER_IN, src_ctxdma,
   SET_CONTEXT_DMA_BUFFER_OUT, dst_ctxdma);
  
-	page_count = new_reg->num_pages;

+   page_count = PFN_UP(new_reg->size);
while (page_count) {
int line_count = (page_count > 2047) ? 2047 : page_count;
  
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo5039.c b/drivers/gpu/drm/nouveau/nouveau_bo5039.c

index 4c75c7b3804c..c6cf3629a9f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo5039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo5039.c
@@ -41,7 +41,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
  {
struct nouveau_mem *mem = nouveau_mem(old_reg);
struct nvif_push *push = chan->chan.push;
-   u64 length = (new_reg->num_pages << PAGE_SHIFT);
+   u64 length = new_reg->size;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
int src_tiled = !!mem->kind;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c 
b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
index ed6c09d67840..9b7ba31fae13 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
@@ -44,7 +44,7 @@ nv84_bo_move_exec(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
if (ret)
return ret;
  
-	PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->num_pages << PAGE_SHIFT,

+   PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->size,
0x0308, upper_32_bits(mem->vma[0].addr),
0x030c, lower_32_bits(mem->vma[0].addr),
0x0310, upper_32_bits(mem->vma[1].addr),
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c 
b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
index dec29b2d8bb2..a15a38a87a95 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
@@ -44,10 +44,10 @@ nva3_bo_move_copy(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
struct nvif_push *push = chan->chan.push;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
-   u32 page_count = new_reg-

Re: [PATCH 3/6] drm/i915: fix’s on ttm_resource rework to use size_t type

2022-10-19 Thread Christian König

Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:

Fix the ttm_resource from num_pages to size_t size.

Signed-off-by: Somalapuram Amaranath 


Acked-by: Christian König 


---
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  2 +-
  drivers/gpu/drm/i915/i915_scatterlist.c   |  4 ++--
  drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
  drivers/gpu/drm/i915/intel_region_ttm.c   |  2 +-
  4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4f861782c3e8..7a1e92c11946 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -649,7 +649,7 @@ bool i915_ttm_resource_mappable(struct ttm_resource *res)
if (!i915_ttm_cpu_maps_iomem(res))
return true;
  
-	return bman_res->used_visible_size == bman_res->base.num_pages;

+   return bman_res->used_visible_size == PFN_UP(bman_res->base.size);
  }
  
  static int i915_ttm_io_mem_reserve(struct ttm_device *bdev, struct ttm_resource *mem)

diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c 
b/drivers/gpu/drm/i915/i915_scatterlist.c
index dcc081874ec8..114e5e39aa72 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -158,7 +158,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct 
ttm_resource *res,
 u32 page_alignment)
  {
struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
-   const u64 size = res->num_pages << PAGE_SHIFT;
+   const u64 size = res->size;
const u32 max_segment = round_down(UINT_MAX, page_alignment);
struct drm_buddy *mm = bman_res->mm;
struct list_head *blocks = &bman_res->blocks;
@@ -177,7 +177,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct 
ttm_resource *res,
  
  	i915_refct_sgt_init(rsgt, size);

st = &rsgt->table;
-   if (sg_alloc_table(st, res->num_pages, GFP_KERNEL)) {
+   if (sg_alloc_table(st, PFN_UP(res->size), GFP_KERNEL)) {
i915_refct_sgt_put(rsgt);
return ERR_PTR(-ENOMEM);
}
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c 
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index e19452f0e100..7e611476c7a4 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -62,8 +62,8 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
if (place->fpfn || lpfn != man->size)
bman_res->flags |= DRM_BUDDY_RANGE_ALLOCATION;
  
-	GEM_BUG_ON(!bman_res->base.num_pages);

-   size = bman_res->base.num_pages << PAGE_SHIFT;
+   GEM_BUG_ON(!bman_res->base.size);
+   size = bman_res->base.size;
  
  	min_page_size = bman->default_page_size;

if (bo->page_alignment)
@@ -72,7 +72,7 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
GEM_BUG_ON(min_page_size < mm->chunk_size);
GEM_BUG_ON(!IS_ALIGNED(size, min_page_size));
  
-	if (place->fpfn + bman_res->base.num_pages != place->lpfn &&

+   if (place->fpfn + PFN_UP(bman_res->base.size) != place->lpfn &&
place->flags & TTM_PL_FLAG_CONTIGUOUS) {
unsigned long pages;
  
@@ -108,7 +108,7 @@ static int i915_ttm_buddy_man_alloc(struct ttm_resource_manager *man,

goto err_free_blocks;
  
  	if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {

-   u64 original_size = (u64)bman_res->base.num_pages << PAGE_SHIFT;
+   u64 original_size = (u64)bman_res->base.size;
  
  		drm_buddy_block_trim(mm,

 original_size,
@@ -116,7 +116,7 @@ static int i915_ttm_buddy_man_alloc(struct 
ttm_resource_manager *man,
}
  
  	if (lpfn <= bman->visible_size) {

-   bman_res->used_visible_size = bman_res->base.num_pages;
+   bman_res->used_visible_size = PFN_UP(bman_res->base.size);
} else {
struct drm_buddy_block *block;
  
@@ -228,7 +228,7 @@ static bool i915_ttm_buddy_man_compatible(struct ttm_resource_manager *man,
  
  	if (!place->fpfn &&

place->lpfn == i915_ttm_buddy_man_visible_size(man))
-   return bman_res->used_visible_size == res->num_pages;
+   return bman_res->used_visible_size == PFN_UP(res->size);
  
  	/* Check each drm buddy block individually */

list_for_each_entry(block, &bman_res->blocks, link) {
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 575d67bc6ffe..cf89d0c2a2d9 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -244,7 +244,7 @@ void intel_region_ttm_resource_free(struct 
intel_memory_region *mem,
struct ttm_resource_manager *man = mem->region_private;
struct ttm_buffer_object mock_bo = {};
  
-

Re: [PATCH 2/6] drm/amd: fix’s on ttm_resource rework to use size_t type

2022-10-19 Thread Christian König

Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:

Fix the ttm_resource from num_pages to size_t size.

Signed-off-by: Somalapuram Amaranath 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
  drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
  drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h  | 2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c   | 8 
  6 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager 
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
-   node->mm_nodes[0].size = node->base.num_pages;
+   node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

index 2e8f6cd7a729..e51f80bb1d07 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
  
-	r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);

+   r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.resource->size), &bo->kmap);


Here bo->tbo.base.size would make more sense, but apart from that the 
patch looks good to me.


Regards,
Christian.


if (r)
return r;
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h

index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
goto fallback;
  
-	BUG_ON(start + size > res->num_pages << PAGE_SHIFT);

+   BUG_ON(start + size > res->size);
  
  	cur->mem_type = res->mem_type;
  
@@ -110,7 +110,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,

cur->size = size;
cur->remaining = size;
cur->node = NULL;
-   WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+   WARN_ON(res && start + size > res->size);
return;
  }
  
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h

index 5e6ddc7e101c..677ad2016976 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -127,7 +127,7 @@ TRACE_EVENT(amdgpu_bo_create,
  
  	TP_fast_assign(

   __entry->bo = bo;
-  __entry->pages = bo->tbo.resource->num_pages;
+  __entry->pages = PFN_UP(bo->tbo.resource->size);
   __entry->type = bo->tbo.resource->mem_type;
   __entry->prefer = bo->preferred_domains;
   __entry->allow = bo->allowed_domains;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index dc262d2c2925..36066965346f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -381,7 +381,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
dst.offset = 0;
  
  	r = amdgpu_ttm_copy_mem_to_mem(adev, &src, &dst,

-  new_mem->num_pages << PAGE_SHIFT,
+  new_mem->size,
   amdgpu_bo_encrypted(abo),
   bo->base.resv, &fence);
if (r)
@@ -424,7 +424,7 @@ static int amdgpu_move_blit(struct ttm_buffer_object *bo,
  static bool amdgpu_mem_visible(struct amdgpu_device *adev,
   struct ttm_resource *mem)
  {
-   u64 mem_size = (u64)mem->num_pages << PAGE_SHIFT;
+   u64 mem_size = (u64)mem->size;
struct amdgpu_res_cursor cursor;
u64 end;
  
@@ -568,7 +568,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_device *bdev,

 struct ttm_resource *mem)
  {
struct amd

Re: [PATCH 1/6] drm/ttm: rework on ttm_resource to use size_t type

2022-10-19 Thread Christian König

Am 19.10.22 um 17:27 schrieb Somalapuram Amaranath:

Change ttm_resource structure from num_pages to size_t size in bytes.


When you remove the num_pages field (instead of adding the size 
additionally) you need to change all drivers in one patch.


Otherwise the build would break in between patches and that's not 
something we can do.




Signed-off-by: Somalapuram Amaranath 
---
  drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
  drivers/gpu/drm/ttm/ttm_bo_util.c   | 6 +++---
  drivers/gpu/drm/ttm/ttm_bo_vm.c | 4 ++--
  drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
  drivers/gpu/drm/ttm/ttm_resource.c  | 8 
  include/drm/ttm/ttm_resource.h  | 2 +-
  6 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7c8e8be774f1..394ccb13eaed 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -51,8 +51,8 @@ static void ttm_bo_mem_space_debug(struct ttm_buffer_object 
*bo,
struct ttm_resource_manager *man;
int i, mem_type;
  
-	drm_printf(&p, "No space for %p (%lu pages, %zuK, %zuM)\n",

-  bo, bo->resource->num_pages, bo->base.size >> 10,
+   drm_printf(&p, "No space for %p (%lu size, %zuK, %zuM)\n",
+  bo, bo->resource->size, bo->base.size >> 10,


Please just remove printing the resource size completely here.


   bo->base.size >> 20);
for (i = 0; i < placement->num_placement; i++) {
mem_type = placement->placement[i].mem_type;
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fa04e62202c1..da5493f789df 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -173,7 +173,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
  
  	clear = src_iter->ops->maps_tt && (!ttm || !ttm_tt_is_populated(ttm));

if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)))
-   ttm_move_memcpy(clear, dst_mem->num_pages, dst_iter, src_iter);
+   ttm_move_memcpy(clear, PFN_UP(dst_mem->size), dst_iter, 
src_iter);


Please use ttm->num_pages here (IIRC).

  
  	if (!src_iter->ops->maps_tt)

ttm_kmap_iter_linear_io_fini(&_src_iter.io, bdev, src_mem);
@@ -357,9 +357,9 @@ int ttm_bo_kmap(struct ttm_buffer_object *bo,
  
  	map->virtual = NULL;

map->bo = bo;
-   if (num_pages > bo->resource->num_pages)
+   if (num_pages > PFN_UP(bo->resource->size))
return -EINVAL;
-   if ((start_page + num_pages) > bo->resource->num_pages)
+   if ((start_page + num_pages) > PFN_UP(bo->resource->size))
return -EINVAL;
  
  	ret = ttm_mem_io_reserve(bo->bdev, bo->resource);

diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 38119311284d..876e7d07273c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -217,7 +217,7 @@ vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,
page_last = vma_pages(vma) + vma->vm_pgoff -
drm_vma_node_start(&bo->base.vma_node);
  
-	if (unlikely(page_offset >= bo->resource->num_pages))

+   if (unlikely(page_offset >= PFN_UP(bo->resource->size)))


Please use bo->base.size here. The resource size can actually be larger 
than the BO size, but the extra space shouldn't be CPU map-able.



return VM_FAULT_SIGBUS;
  
  	prot = ttm_io_prot(bo, bo->resource, prot);

@@ -412,7 +412,7 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned 
long addr,
 << PAGE_SHIFT);
int ret;
  
-	if (len < 1 || (offset + len) >> PAGE_SHIFT > bo->resource->num_pages)

+   if (len < 1 || (offset + len) > bo->resource->size)


Same here, please use bo->base.size.


return -EIO;
  
  	ret = ttm_bo_reserve(bo, true, false, NULL);

diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index f7c16c46cfbc..0a8bc0b7f380 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -83,7 +83,7 @@ static int ttm_range_man_alloc(struct ttm_resource_manager 
*man,
  
  	spin_lock(&rman->lock);

ret = drm_mm_insert_node_in_range(mm, &node->mm_nodes[0],
- node->base.num_pages,
+ PFN_UP(node->base.size),
  bo->page_alignment, 0,
  place->fpfn, lpfn, mode);
spin_unlock(&rman->lock);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index a729c32a1e48..f9cce0727d40 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -177,7 +177,7 @@ void ttm_resource_init(struct ttm_buffer_object *bo,
struct ttm_resource_manager *man;
  
  	res->start = 0;

-   res->n

Re: [PATCH 05/16] drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.

2022-10-19 Thread Intel

Hi, Zack,

On 10/19/22 18:32, Zack Rusin wrote:

On Wed, 2022-10-19 at 12:21 +0200, Thomas Hellström (Intel) wrote:

⚠ External Email

On 10/17/22 21:54, Zack Rusin wrote:

From: Maaz Mombasawala 

Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
to reduce maintenence burden.
As part of this effort, refactor the res_ht hashtable used for resource
validation during execbuf execution to use linux/hashtable implementation.
This also refactors vmw_validation_context to use vmw_sw_context as the
container for the hashtable, whereas before it used a vmwgfx_open_hash
directly. This makes vmw_validation_context less generic, but there is
no functional change since res_ht is the only instance where validation
context used a hashtable in vmwgfx driver.

Why is a pointer to the vmw_sw_context added to the validation context,
rather than a pointer to the new hash table type itself? Seems like an
unnecessary indirection which adds a dependency on the sw context to the
validation context?

Hi, Thomas. Thanks for taking a look at this! That's because the entire public
interface of hashtable depends on it being a struct on which sizeof works rather
than a pointer, i.e. almost the entire interface of hasthbale.h is defined and 
they
all require that HASH_SIZE(hashtable) which is defined as
#define HASH_SIZE(hashtable) (ARRAY_SIZE(hashtable))
works on the hashtable. So the interface of hashtable.h can't operate on 
pointers,
but rather needs the full struct.

So the only two options are either rewriting the functions from 
linux/hashtable.h to
take explicit HASH_SIZE(hashtable) or make sure that in the functions where you 
will
use hashtable.h you pass the parent struct so that sizeof on the hashtable works
correctly. I've seen both approaches in the kernel, but in this case we thought 
the
latter made more sense.


Ah, Ok, yes, tricky one. Lots of options, none of them perfect.

Reviewed-by: Thomas Hellström 




Re: [PATCH 05/16] drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.

2022-10-19 Thread Zack Rusin
On Wed, 2022-10-19 at 12:21 +0200, Thomas Hellström (Intel) wrote:
> ⚠ External Email
> 
> On 10/17/22 21:54, Zack Rusin wrote:
> > From: Maaz Mombasawala 
> > 
> > Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable
> > to reduce maintenence burden.
> > As part of this effort, refactor the res_ht hashtable used for resource
> > validation during execbuf execution to use linux/hashtable implementation.
> > This also refactors vmw_validation_context to use vmw_sw_context as the
> > container for the hashtable, whereas before it used a vmwgfx_open_hash
> > directly. This makes vmw_validation_context less generic, but there is
> > no functional change since res_ht is the only instance where validation
> > context used a hashtable in vmwgfx driver.
> 
> Why is a pointer to the vmw_sw_context added to the validation context,
> rather than a pointer to the new hash table type itself? Seems like an
> unnecessary indirection which adds a dependency on the sw context to the
> validation context?

Hi, Thomas. Thanks for taking a look at this! That's because the entire public
interface of hashtable depends on it being a struct on which sizeof works rather
than a pointer, i.e. almost the entire interface of hasthbale.h is defined and 
they
all require that HASH_SIZE(hashtable) which is defined as
#define HASH_SIZE(hashtable) (ARRAY_SIZE(hashtable))
works on the hashtable. So the interface of hashtable.h can't operate on 
pointers,
but rather needs the full struct.

So the only two options are either rewriting the functions from 
linux/hashtable.h to
take explicit HASH_SIZE(hashtable) or make sure that in the functions where you 
will
use hashtable.h you pass the parent struct so that sizeof on the hashtable works
correctly. I've seen both approaches in the kernel, but in this case we thought 
the
latter made more sense.


> > + if (ctx->sw_context) {
> >   struct vmwgfx_hash_item *hash;
> > + unsigned long key = (unsigned long) vbo;
> > 
> > - if (!vmwgfx_ht_find_item(ctx->ht, (unsigned long) vbo, &hash))
> > - bo_node = container_of(hash, typeof(*bo_node), hash);
> > + hash_for_each_possible_rcu(ctx->sw_context->res_ht, hash, 
> > head, key) {
> 
> This open-coded loop seems to be used throughout the conversion, and
> also in other patches. Perhaps a small helper in place?

Yes, that's a good idea. We'll see if we can abstract that. The tricky bit of
abstracting code that's using hash_* functions is that, as mentioned above, 
these
are all macros that depend on hashtable not being a pointer, so if you can't fit
your helper in another define then you have the same choice as above (i.e. 
rewrite
whatever hash_* function you were using to allow for explicit hash size, or make
your helper take the parent of the hash as argument).


> Otherwise LGTM.

Thanks! 

z


[PATCH v1 0/7] vfio-ccw parent rework

2022-10-19 Thread Eric Farman
Hi all,

There have been discussions and attempts [1][2] to rework the vfio-ccw device
lifecycle to better align with the needs/expectations of vfio and mdev.
While those languished, commit cb9ff3f3b84c ("vfio: Add helpers for unifying
vfio_device life cycle") implemented a couple of tricks that help vfio and the
drivers that interact with it, while keeping vfio-ccw as-is. A handful of
commits titled "vfio/xxx: Use the new device life cycle helpers" implemented
those tricks for each of the drivers.

This series attempts to address the oddities/shortcomings of vfio-ccw, such
that vfio-ccw can use the same helpers as everyone else, and the tricks that
were implemented by the other drivers can be removed. It is built on 6.1-rc1,
and thus includes the various changes [3][4] that have occurred in and around
these parts.

Patches 1-5 rework the behavior of the vfio-ccw driver's private struct.
In summary, the mdev pieces are split out of vfio_ccw_private and into a
new vfio_ccw_parent struct that will continue to follow today's lifecycle.
The remainder (bulk) of the private struct moves to follow the mdev
probe/remove pair. There's opportunity for further separation of the
things in the private struct, which would simplify some of the vfio-ccw
code, but it got too hairy as I started that. Once vfio-ccw is no longer
considered unique, those cleanups can happen at our leisure. 

Patch 6 removes the trickery where vfio-ccw uses vfio_init_device instead of
vfio_alloc_device, and thus removes vfio_init_device from the outside world.

Patch 7 removes vfio_free_device from vfio-ccw and the other drivers (hello,
CC list!), letting it be handled by vfio_device_release directly.

Looking forward to the feedback.

Thanks,
Eric

[1] https://lore.kernel.org/kvm/0-v3-57c1502c62fd+2190-ccw_mdev_...@nvidia.com/
[2] https://lore.kernel.org/kvm/20220602171948.2790690-1-far...@linux.ibm.com/
[3] https://lore.kernel.org/kvm/20220923092652.100656-1-...@lst.de/
[4] https://lore.kernel.org/kvm/20220921104401.38898-1-kevin.t...@intel.com/

Eric Farman (7):
  vfio/ccw: create a parent struct
  vfio/ccw: remove private->sch
  vfio/ccw: move private initialization to callback
  vfio/ccw: move private to mdev lifecycle
  vfio/ccw: remove release completion
  vfio/ccw: replace vfio_init_device with _alloc_
  vfio: Remove vfio_free_device

 drivers/gpu/drm/i915/gvt/kvmgt.c  |   1 -
 drivers/s390/cio/vfio_ccw_chp.c   |   5 +-
 drivers/s390/cio/vfio_ccw_drv.c   | 182 ++
 drivers/s390/cio/vfio_ccw_fsm.c   |  27 ++--
 drivers/s390/cio/vfio_ccw_ops.c   | 108 ++-
 drivers/s390/cio/vfio_ccw_parent.h|  28 
 drivers/s390/cio/vfio_ccw_private.h   |  22 ++--
 drivers/s390/crypto/vfio_ap_ops.c |   6 -
 drivers/vfio/fsl-mc/vfio_fsl_mc.c |   1 -
 drivers/vfio/pci/vfio_pci_core.c  |   1 -
 drivers/vfio/platform/vfio_amba.c |   1 -
 drivers/vfio/platform/vfio_platform.c |   1 -
 drivers/vfio/vfio_main.c  |  25 +---
 include/linux/vfio.h  |   1 -
 samples/vfio-mdev/mbochs.c|   1 -
 samples/vfio-mdev/mdpy.c  |   1 -
 samples/vfio-mdev/mtty.c  |   1 -
 17 files changed, 204 insertions(+), 208 deletions(-)
 create mode 100644 drivers/s390/cio/vfio_ccw_parent.h

-- 
2.34.1



[PATCH v1 5/7] vfio/ccw: remove release completion

2022-10-19 Thread Eric Farman
There's enough separation between the parent and private structs now,
that it is fine to remove the release completion hack.

Signed-off-by: Eric Farman 
---
 drivers/s390/cio/vfio_ccw_ops.c | 14 +-
 drivers/s390/cio/vfio_ccw_private.h |  3 ---
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 3e627b236241..261cb8150abb 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -55,7 +55,6 @@ static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
INIT_LIST_HEAD(&private->crw);
INIT_WORK(&private->io_work, vfio_ccw_sch_io_todo);
INIT_WORK(&private->crw_work, vfio_ccw_crw_todo);
-   init_completion(&private->release_comp);
 
private->cp.guest_cp = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1),
   GFP_KERNEL);
@@ -138,7 +137,7 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device 
*vdev)
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
 
-   complete(&private->release_comp);
+   vfio_ccw_free_private(private);
 }
 
 static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
@@ -156,17 +155,6 @@ static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
 
dev_set_drvdata(&parent->dev, NULL);
vfio_put_device(&private->vdev);
-   /*
-* Wait for all active references on mdev are released so it
-* is safe to defer kfree() to a later point.
-*
-* TODO: the clean fix is to split parent/mdev info from ccw
-* private structure so each can be managed in its own life
-* cycle.
-*/
-   wait_for_completion(&private->release_comp);
-
-   vfio_ccw_free_private(private);
 }
 
 static int vfio_ccw_mdev_open_device(struct vfio_device *vdev)
diff --git a/drivers/s390/cio/vfio_ccw_private.h 
b/drivers/s390/cio/vfio_ccw_private.h
index c1959b8bfe86..ddaf6846022d 100644
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -87,7 +87,6 @@ struct vfio_ccw_crw {
  * @req_trigger: eventfd ctx for signaling userspace to return device
  * @io_work: work for deferral process of I/O handling
  * @crw_work: work for deferral process of CRW handling
- * @release_comp: synchronization helper for vfio device release
  */
 struct vfio_ccw_private {
struct vfio_device vdev;
@@ -111,8 +110,6 @@ struct vfio_ccw_private {
struct eventfd_ctx  *req_trigger;
struct work_struct  io_work;
struct work_struct  crw_work;
-
-   struct completion   release_comp;
 } __aligned(8);
 
 int vfio_ccw_sch_quiesce(struct subchannel *sch);
-- 
2.34.1



[PATCH v1 3/7] vfio/ccw: move private initialization to callback

2022-10-19 Thread Eric Farman
There's already a device initialization callback that is
used to initialize the release completion workaround.

Move the other elements of the vfio_ccw_private struct that
require distinct initialization over to that routine.

Signed-off-by: Eric Farman 
---
 drivers/s390/cio/vfio_ccw_drv.c | 57 +++--
 drivers/s390/cio/vfio_ccw_ops.c | 43 ++
 drivers/s390/cio/vfio_ccw_private.h |  7 +++-
 3 files changed, 55 insertions(+), 52 deletions(-)

diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 4ee953c8ae39..cc9ed2fd970f 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -24,10 +24,10 @@
 #include "vfio_ccw_private.h"
 
 struct workqueue_struct *vfio_ccw_work_q;
-static struct kmem_cache *vfio_ccw_io_region;
-static struct kmem_cache *vfio_ccw_cmd_region;
-static struct kmem_cache *vfio_ccw_schib_region;
-static struct kmem_cache *vfio_ccw_crw_region;
+struct kmem_cache *vfio_ccw_io_region;
+struct kmem_cache *vfio_ccw_cmd_region;
+struct kmem_cache *vfio_ccw_schib_region;
+struct kmem_cache *vfio_ccw_crw_region;
 
 debug_info_t *vfio_ccw_debug_msg_id;
 debug_info_t *vfio_ccw_debug_trace_id;
@@ -74,7 +74,7 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
return ret;
 }
 
-static void vfio_ccw_sch_io_todo(struct work_struct *work)
+void vfio_ccw_sch_io_todo(struct work_struct *work)
 {
struct vfio_ccw_private *private;
struct irb *irb;
@@ -110,7 +110,7 @@ static void vfio_ccw_sch_io_todo(struct work_struct *work)
eventfd_signal(private->io_trigger, 1);
 }
 
-static void vfio_ccw_crw_todo(struct work_struct *work)
+void vfio_ccw_crw_todo(struct work_struct *work)
 {
struct vfio_ccw_private *private;
 
@@ -154,52 +154,7 @@ static struct vfio_ccw_private 
*vfio_ccw_alloc_private(struct subchannel *sch)
if (!private)
return ERR_PTR(-ENOMEM);
 
-   mutex_init(&private->io_mutex);
-   private->state = VFIO_CCW_STATE_STANDBY;
-   INIT_LIST_HEAD(&private->crw);
-   INIT_WORK(&private->io_work, vfio_ccw_sch_io_todo);
-   INIT_WORK(&private->crw_work, vfio_ccw_crw_todo);
-
-   private->cp.guest_cp = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1),
-  GFP_KERNEL);
-   if (!private->cp.guest_cp)
-   goto out_free_private;
-
-   private->io_region = kmem_cache_zalloc(vfio_ccw_io_region,
-  GFP_KERNEL | GFP_DMA);
-   if (!private->io_region)
-   goto out_free_cp;
-
-   private->cmd_region = kmem_cache_zalloc(vfio_ccw_cmd_region,
-   GFP_KERNEL | GFP_DMA);
-   if (!private->cmd_region)
-   goto out_free_io;
-
-   private->schib_region = kmem_cache_zalloc(vfio_ccw_schib_region,
- GFP_KERNEL | GFP_DMA);
-
-   if (!private->schib_region)
-   goto out_free_cmd;
-
-   private->crw_region = kmem_cache_zalloc(vfio_ccw_crw_region,
-   GFP_KERNEL | GFP_DMA);
-
-   if (!private->crw_region)
-   goto out_free_schib;
return private;
-
-out_free_schib:
-   kmem_cache_free(vfio_ccw_schib_region, private->schib_region);
-out_free_cmd:
-   kmem_cache_free(vfio_ccw_cmd_region, private->cmd_region);
-out_free_io:
-   kmem_cache_free(vfio_ccw_io_region, private->io_region);
-out_free_cp:
-   kfree(private->cp.guest_cp);
-out_free_private:
-   mutex_destroy(&private->io_mutex);
-   kfree(private);
-   return ERR_PTR(-ENOMEM);
 }
 
 static void vfio_ccw_free_private(struct vfio_ccw_private *private)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index cf383c729d53..626b8eb3507b 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -50,8 +50,51 @@ static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
 
+   mutex_init(&private->io_mutex);
+   private->state = VFIO_CCW_STATE_STANDBY;
+   INIT_LIST_HEAD(&private->crw);
+   INIT_WORK(&private->io_work, vfio_ccw_sch_io_todo);
+   INIT_WORK(&private->crw_work, vfio_ccw_crw_todo);
init_completion(&private->release_comp);
+
+   private->cp.guest_cp = kcalloc(CCWCHAIN_LEN_MAX, sizeof(struct ccw1),
+  GFP_KERNEL);
+   if (!private->cp.guest_cp)
+   goto out_free_private;
+
+   private->io_region = kmem_cache_zalloc(vfio_ccw_io_region,
+  GFP_KERNEL | GFP_DMA);
+   if (!private->io_region)
+   goto out_free_cp;
+
+   private->cmd_region = kmem_cache_zalloc(vfio_ccw_cmd_region,
+   GFP_

[PATCH v1 7/7] vfio: Remove vfio_free_device

2022-10-19 Thread Eric Farman
With the "mess" sorted out, we should be able to inline the
vfio_free_device call introduced by commit cb9ff3f3b84c
("vfio: Add helpers for unifying vfio_device life cycle")
and remove them from driver release callbacks.

Signed-off-by: Eric Farman 
---
 drivers/gpu/drm/i915/gvt/kvmgt.c  |  1 -
 drivers/s390/cio/vfio_ccw_ops.c   |  2 --
 drivers/s390/crypto/vfio_ap_ops.c |  6 --
 drivers/vfio/fsl-mc/vfio_fsl_mc.c |  1 -
 drivers/vfio/pci/vfio_pci_core.c  |  1 -
 drivers/vfio/platform/vfio_amba.c |  1 -
 drivers/vfio/platform/vfio_platform.c |  1 -
 drivers/vfio/vfio_main.c  | 22 --
 include/linux/vfio.h  |  1 -
 samples/vfio-mdev/mbochs.c|  1 -
 samples/vfio-mdev/mdpy.c  |  1 -
 samples/vfio-mdev/mtty.c  |  1 -
 12 files changed, 4 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 7a45e5360caf..eee6805e67de 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1461,7 +1461,6 @@ static void intel_vgpu_release_dev(struct vfio_device 
*vfio_dev)
struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
 
intel_gvt_destroy_vgpu(vgpu);
-   vfio_free_device(vfio_dev);
 }
 
 static const struct vfio_device_ops intel_vgpu_dev_ops = {
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 9619dc35080f..cfb2e5c8e717 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -144,8 +144,6 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device 
*vdev)
kmem_cache_free(vfio_ccw_io_region, private->io_region);
kfree(private->cp.guest_cp);
mutex_destroy(&private->io_mutex);
-
-   vfio_free_device(vdev);
 }
 
 static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c 
b/drivers/s390/crypto/vfio_ap_ops.c
index 0b4cc8c597ae..f108c0f14712 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -765,11 +765,6 @@ static void vfio_ap_mdev_unlink_fr_queues(struct 
ap_matrix_mdev *matrix_mdev)
}
 }
 
-static void vfio_ap_mdev_release_dev(struct vfio_device *vdev)
-{
-   vfio_free_device(vdev);
-}
-
 static void vfio_ap_mdev_remove(struct mdev_device *mdev)
 {
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(&mdev->dev);
@@ -1784,7 +1779,6 @@ static const struct attribute_group vfio_queue_attr_group 
= {
 
 static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {
.init = vfio_ap_mdev_init_dev,
-   .release = vfio_ap_mdev_release_dev,
.open_device = vfio_ap_mdev_open_device,
.close_device = vfio_ap_mdev_close_device,
.ioctl = vfio_ap_mdev_ioctl,
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c 
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index b16874e913e4..7b8889f55007 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -568,7 +568,6 @@ static void vfio_fsl_mc_release_dev(struct vfio_device 
*core_vdev)
 
vfio_fsl_uninit_device(vdev);
mutex_destroy(&vdev->igate);
-   vfio_free_device(core_vdev);
 }
 
 static int vfio_fsl_mc_remove(struct fsl_mc_device *mc_dev)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index badc9d828cac..9be2d5be5d95 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -2109,7 +2109,6 @@ void vfio_pci_core_release_dev(struct vfio_device 
*core_vdev)
mutex_destroy(&vdev->vma_lock);
kfree(vdev->region);
kfree(vdev->pm_save);
-   vfio_free_device(core_vdev);
 }
 EXPORT_SYMBOL_GPL(vfio_pci_core_release_dev);
 
diff --git a/drivers/vfio/platform/vfio_amba.c 
b/drivers/vfio/platform/vfio_amba.c
index eaea63e5294c..18faf2678b99 100644
--- a/drivers/vfio/platform/vfio_amba.c
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -95,7 +95,6 @@ static void vfio_amba_release_dev(struct vfio_device 
*core_vdev)
 
vfio_platform_release_common(vdev);
kfree(vdev->name);
-   vfio_free_device(core_vdev);
 }
 
 static void vfio_amba_remove(struct amba_device *adev)
diff --git a/drivers/vfio/platform/vfio_platform.c 
b/drivers/vfio/platform/vfio_platform.c
index 82cedcebfd90..9910451dc341 100644
--- a/drivers/vfio/platform/vfio_platform.c
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -83,7 +83,6 @@ static void vfio_platform_release_dev(struct vfio_device 
*core_vdev)
container_of(core_vdev, struct vfio_platform_device, vdev);
 
vfio_platform_release_common(vdev);
-   vfio_free_device(core_vdev);
 }
 
 static int vfio_platform_remove(struct platform_device *pdev)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 28f36c6d9d3f..8a1d83cbb05a 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -339,13 +339,10 @@ static void vfio_device_release(struct de

[PATCH v1 4/7] vfio/ccw: move private to mdev lifecycle

2022-10-19 Thread Eric Farman
Now that the mdev parent data is split out into its own struct,
it is safe to move the remaining private data to follow the
mdev probe/remove lifecycle. The mdev parent data will remain
where it is, and follow the subchannel and the css driver
interfaces.

Signed-off-by: Eric Farman 
---
 drivers/s390/cio/vfio_ccw_drv.c | 17 ++---
 drivers/s390/cio/vfio_ccw_ops.c | 26 +-
 drivers/s390/cio/vfio_ccw_private.h |  3 +++
 3 files changed, 18 insertions(+), 28 deletions(-)

diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index cc9ed2fd970f..686a9b9f6731 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -146,7 +146,7 @@ static void vfio_ccw_sch_irq(struct subchannel *sch)
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
 }
 
-static struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch)
+struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch)
 {
struct vfio_ccw_private *private;
 
@@ -157,7 +157,7 @@ static struct vfio_ccw_private 
*vfio_ccw_alloc_private(struct subchannel *sch)
return private;
 }
 
-static void vfio_ccw_free_private(struct vfio_ccw_private *private)
+void vfio_ccw_free_private(struct vfio_ccw_private *private)
 {
struct vfio_ccw_crw *crw, *temp;
 
@@ -185,7 +185,6 @@ static void vfio_ccw_free_parent(struct device *dev)
 static int vfio_ccw_sch_probe(struct subchannel *sch)
 {
struct pmcw *pmcw = &sch->schib.pmcw;
-   struct vfio_ccw_private *private;
struct vfio_ccw_parent *parent;
int ret = -ENOMEM;
 
@@ -202,14 +201,7 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
parent->dev.release = &vfio_ccw_free_parent;
device_initialize(&parent->dev);
 
-   private = vfio_ccw_alloc_private(sch);
-   if (IS_ERR(private)) {
-   put_device(&parent->dev);
-   return PTR_ERR(private);
-   }
-
dev_set_drvdata(&sch->dev, parent);
-   dev_set_drvdata(&parent->dev, private);
 
parent->mdev_type.sysfs_name = "io";
parent->mdev_type.pretty_name = "I/O subchannel (Non-QDIO)";
@@ -226,9 +218,7 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
return 0;
 
 out_free:
-   dev_set_drvdata(&parent->dev, NULL);
dev_set_drvdata(&sch->dev, NULL);
-   vfio_ccw_free_private(private);
put_device(&parent->dev);
return ret;
 }
@@ -236,13 +226,10 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
 static void vfio_ccw_sch_remove(struct subchannel *sch)
 {
struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
-   struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
 
mdev_unregister_parent(&parent->parent);
 
dev_set_drvdata(&sch->dev, NULL);
-
-   vfio_ccw_free_private(private);
put_device(&parent->dev);
 
VFIO_CCW_MSG_EVENT(4, "unbound from subchannel %x.%x.%04x\n",
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 626b8eb3507b..3e627b236241 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -101,15 +101,20 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
 {
struct subchannel *sch = to_subchannel(mdev->dev.parent);
struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
-   struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
+   struct vfio_ccw_private *private;
int ret;
 
-   if (private->state == VFIO_CCW_STATE_NOT_OPER)
-   return -ENODEV;
+   private = vfio_ccw_alloc_private(sch);
+   if (!private)
+   return -ENOMEM;
 
ret = vfio_init_device(&private->vdev, &mdev->dev, &vfio_ccw_dev_ops);
-   if (ret)
+   if (ret) {
+   kfree(private);
return ret;
+   }
+
+   dev_set_drvdata(&parent->dev, private);
 
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: create\n",
   sch->schid.cssid,
@@ -123,6 +128,7 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
return 0;
 
 err_put_vdev:
+   dev_set_drvdata(&parent->dev, NULL);
vfio_put_device(&private->vdev);
return ret;
 }
@@ -132,15 +138,6 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device 
*vdev)
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
 
-   /*
-* We cannot free vfio_ccw_private here because it includes
-* parent info which must be free'ed by css driver.
-*
-* Use a workaround by memset'ing the core device part and
-* then notifying the remove path that all active references
-* to this device have been released.
-*/
-   memset(vdev, 0, sizeof(*vdev));
complete(&private->release_comp);
 }
 
@@ -157,6 +154,7 @@ static void vfio_ccw_mdev_remove(struct md

[PATCH v1 6/7] vfio/ccw: replace vfio_init_device with _alloc_

2022-10-19 Thread Eric Farman
Now that we have a reasonable separation of structs that follow
the subchannel and mdev lifecycles, there's no reason we can't
call the official vfio_alloc_device routine for our private data,
and behave like everyone else.

Signed-off-by: Eric Farman 
---
 drivers/s390/cio/vfio_ccw_drv.c | 29 -
 drivers/s390/cio/vfio_ccw_ops.c | 28 ++--
 drivers/s390/cio/vfio_ccw_private.h |  3 ---
 drivers/vfio/vfio_main.c|  3 ---
 4 files changed, 18 insertions(+), 45 deletions(-)

diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 686a9b9f6731..9bbf41315aca 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -146,35 +146,6 @@ static void vfio_ccw_sch_irq(struct subchannel *sch)
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
 }
 
-struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch)
-{
-   struct vfio_ccw_private *private;
-
-   private = kzalloc(sizeof(*private), GFP_KERNEL);
-   if (!private)
-   return ERR_PTR(-ENOMEM);
-
-   return private;
-}
-
-void vfio_ccw_free_private(struct vfio_ccw_private *private)
-{
-   struct vfio_ccw_crw *crw, *temp;
-
-   list_for_each_entry_safe(crw, temp, &private->crw, next) {
-   list_del(&crw->next);
-   kfree(crw);
-   }
-
-   kmem_cache_free(vfio_ccw_crw_region, private->crw_region);
-   kmem_cache_free(vfio_ccw_schib_region, private->schib_region);
-   kmem_cache_free(vfio_ccw_cmd_region, private->cmd_region);
-   kmem_cache_free(vfio_ccw_io_region, private->io_region);
-   kfree(private->cp.guest_cp);
-   mutex_destroy(&private->io_mutex);
-   kfree(private);
-}
-
 static void vfio_ccw_free_parent(struct device *dev)
 {
struct vfio_ccw_parent *parent = container_of(dev, struct 
vfio_ccw_parent, dev);
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 261cb8150abb..9619dc35080f 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -103,15 +103,10 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
struct vfio_ccw_private *private;
int ret;
 
-   private = vfio_ccw_alloc_private(sch);
-   if (!private)
-   return -ENOMEM;
-
-   ret = vfio_init_device(&private->vdev, &mdev->dev, &vfio_ccw_dev_ops);
-   if (ret) {
-   kfree(private);
-   return ret;
-   }
+   private = vfio_alloc_device(vfio_ccw_private, vdev, &mdev->dev,
+   &vfio_ccw_dev_ops);
+   if (IS_ERR(private))
+   return PTR_ERR(private);
 
dev_set_drvdata(&parent->dev, private);
 
@@ -136,8 +131,21 @@ static void vfio_ccw_mdev_release_dev(struct vfio_device 
*vdev)
 {
struct vfio_ccw_private *private =
container_of(vdev, struct vfio_ccw_private, vdev);
+   struct vfio_ccw_crw *crw, *temp;
+
+   list_for_each_entry_safe(crw, temp, &private->crw, next) {
+   list_del(&crw->next);
+   kfree(crw);
+   }
+
+   kmem_cache_free(vfio_ccw_crw_region, private->crw_region);
+   kmem_cache_free(vfio_ccw_schib_region, private->schib_region);
+   kmem_cache_free(vfio_ccw_cmd_region, private->cmd_region);
+   kmem_cache_free(vfio_ccw_io_region, private->io_region);
+   kfree(private->cp.guest_cp);
+   mutex_destroy(&private->io_mutex);
 
-   vfio_ccw_free_private(private);
+   vfio_free_device(vdev);
 }
 
 static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
diff --git a/drivers/s390/cio/vfio_ccw_private.h 
b/drivers/s390/cio/vfio_ccw_private.h
index ddaf6846022d..2ca408881659 100644
--- a/drivers/s390/cio/vfio_ccw_private.h
+++ b/drivers/s390/cio/vfio_ccw_private.h
@@ -116,9 +116,6 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch);
 void vfio_ccw_sch_io_todo(struct work_struct *work);
 void vfio_ccw_crw_todo(struct work_struct *work);
 
-struct vfio_ccw_private *vfio_ccw_alloc_private(struct subchannel *sch);
-void vfio_ccw_free_private(struct vfio_ccw_private *private);
-
 extern struct mdev_driver vfio_ccw_mdev_driver;
 
 /*
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 2d168793d4e1..28f36c6d9d3f 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -386,8 +386,6 @@ EXPORT_SYMBOL_GPL(_vfio_alloc_device);
 
 /*
  * Initialize a vfio_device so it can be registered to vfio core.
- *
- * Only vfio-ccw driver should call this interface.
  */
 int vfio_init_device(struct vfio_device *device, struct device *dev,
 const struct vfio_device_ops *ops)
@@ -422,7 +420,6 @@ int vfio_init_device(struct vfio_device *device, struct 
device *dev,
ida_free(&vfio.device_ida, device->index);
return ret;
 }
-EXPORT_SYMBOL_GPL(vfio_init_device);
 
 /*
  * The helper called by driver @release callback to free

[PATCH v1 1/7] vfio/ccw: create a parent struct

2022-10-19 Thread Eric Farman
Move the stuff associated with the mdev parent (and thus the
subchannel struct) into its own struct, and leave the rest in
the existing private structure.

The subchannel will point to the parent, and the parent will point
to the private, for the areas where one or both are needed. Further
separation of these structs will follow.

Signed-off-by: Eric Farman 
---
 drivers/s390/cio/vfio_ccw_drv.c | 104 
 drivers/s390/cio/vfio_ccw_ops.c |   9 ++-
 drivers/s390/cio/vfio_ccw_parent.h  |  28 
 drivers/s390/cio/vfio_ccw_private.h |   5 --
 4 files changed, 112 insertions(+), 34 deletions(-)
 create mode 100644 drivers/s390/cio/vfio_ccw_parent.h

diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 7f5402fe857a..634760ca0dea 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -20,6 +20,7 @@
 #include "chp.h"
 #include "ioasm.h"
 #include "css.h"
+#include "vfio_ccw_parent.h"
 #include "vfio_ccw_private.h"
 
 struct workqueue_struct *vfio_ccw_work_q;
@@ -36,7 +37,8 @@ debug_info_t *vfio_ccw_debug_trace_id;
  */
 int vfio_ccw_sch_quiesce(struct subchannel *sch)
 {
-   struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
+   struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
+   struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
DECLARE_COMPLETION_ONSTACK(completion);
int iretry, ret = 0;
 
@@ -51,19 +53,21 @@ int vfio_ccw_sch_quiesce(struct subchannel *sch)
break;
}
 
-   /*
-* Flush all I/O and wait for
-* cancel/halt/clear completion.
-*/
-   private->completion = &completion;
-   spin_unlock_irq(sch->lock);
+   if (private) {
+   /*
+* Flush all I/O and wait for
+* cancel/halt/clear completion.
+*/
+   private->completion = &completion;
+   spin_unlock_irq(sch->lock);
 
-   if (ret == -EBUSY)
-   wait_for_completion_timeout(&completion, 3*HZ);
+   if (ret == -EBUSY)
+   wait_for_completion_timeout(&completion, 3*HZ);
 
-   private->completion = NULL;
-   flush_workqueue(vfio_ccw_work_q);
-   spin_lock_irq(sch->lock);
+   private->completion = NULL;
+   flush_workqueue(vfio_ccw_work_q);
+   spin_lock_irq(sch->lock);
+   }
ret = cio_disable_subchannel(sch);
} while (ret == -EBUSY);
 
@@ -121,7 +125,22 @@ static void vfio_ccw_crw_todo(struct work_struct *work)
  */
 static void vfio_ccw_sch_irq(struct subchannel *sch)
 {
-   struct vfio_ccw_private *private = dev_get_drvdata(&sch->dev);
+   struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
+   struct vfio_ccw_private *private = dev_get_drvdata(&parent->dev);
+
+   /*
+* The subchannel should still be disabled at this point,
+* so an interrupt would be quite surprising. As with an
+* interrupt while the FSM is closed, let's attempt to
+* disable the subchannel again.
+*/
+   if (!private) {
+   VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: unexpected interrupt\n",
+   sch->schid.cssid, sch->schid.ssid, sch->schid.sch_no);
+
+   cio_disable_subchannel(sch);
+   return;
+   }
 
inc_irq_stat(IRQIO_CIO);
vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_INTERRUPT);
@@ -201,10 +220,19 @@ static void vfio_ccw_free_private(struct vfio_ccw_private 
*private)
mutex_destroy(&private->io_mutex);
kfree(private);
 }
+
+static void vfio_ccw_free_parent(struct device *dev)
+{
+   struct vfio_ccw_parent *parent = container_of(dev, struct 
vfio_ccw_parent, dev);
+
+   kfree(parent);
+}
+
 static int vfio_ccw_sch_probe(struct subchannel *sch)
 {
struct pmcw *pmcw = &sch->schib.pmcw;
struct vfio_ccw_private *private;
+   struct vfio_ccw_parent *parent;
int ret = -ENOMEM;
 
if (pmcw->qf) {
@@ -213,18 +241,28 @@ static int vfio_ccw_sch_probe(struct subchannel *sch)
return -ENODEV;
}
 
+   parent = kzalloc(sizeof(*parent), GFP_KERNEL);
+   if (IS_ERR(parent))
+   return PTR_ERR(parent);
+
+   parent->dev.release = &vfio_ccw_free_parent;
+   device_initialize(&parent->dev);
+
private = vfio_ccw_alloc_private(sch);
-   if (IS_ERR(private))
+   if (IS_ERR(private)) {
+   put_device(&parent->dev);
return PTR_ERR(private);
+   }
 
-   dev_set_drvdata(&sch->dev, private);
+   dev_set_drvdata(&sch->dev, parent);
+   dev_set_drvdata(&parent->dev, private);

[PATCH v1 2/7] vfio/ccw: remove private->sch

2022-10-19 Thread Eric Farman
These places all rely on the ability to jump from a private
struct back to the subchannel struct. Rather than keeping a
copy in our back pocket, let's use the relationship provided
by the vfio_device embedded within the private.

Signed-off-by: Eric Farman 
---
 drivers/s390/cio/vfio_ccw_chp.c |  5 +++--
 drivers/s390/cio/vfio_ccw_drv.c |  3 +--
 drivers/s390/cio/vfio_ccw_fsm.c | 27 ---
 drivers/s390/cio/vfio_ccw_ops.c | 12 ++--
 drivers/s390/cio/vfio_ccw_private.h |  7 ---
 5 files changed, 26 insertions(+), 28 deletions(-)

diff --git a/drivers/s390/cio/vfio_ccw_chp.c b/drivers/s390/cio/vfio_ccw_chp.c
index 13b26a1c7988..d3f3a611f95b 100644
--- a/drivers/s390/cio/vfio_ccw_chp.c
+++ b/drivers/s390/cio/vfio_ccw_chp.c
@@ -16,6 +16,7 @@ static ssize_t vfio_ccw_schib_region_read(struct 
vfio_ccw_private *private,
  char __user *buf, size_t count,
  loff_t *ppos)
 {
+   struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
unsigned int i = VFIO_CCW_OFFSET_TO_INDEX(*ppos) - VFIO_CCW_NUM_REGIONS;
loff_t pos = *ppos & VFIO_CCW_OFFSET_MASK;
struct ccw_schib_region *region;
@@ -27,12 +28,12 @@ static ssize_t vfio_ccw_schib_region_read(struct 
vfio_ccw_private *private,
mutex_lock(&private->io_mutex);
region = private->region[i].data;
 
-   if (cio_update_schib(private->sch)) {
+   if (cio_update_schib(sch)) {
ret = -ENODEV;
goto out;
}
 
-   memcpy(region, &private->sch->schib, sizeof(*region));
+   memcpy(region, &sch->schib, sizeof(*region));
 
if (copy_to_user(buf, (void *)region + pos, count)) {
ret = -EFAULT;
diff --git a/drivers/s390/cio/vfio_ccw_drv.c b/drivers/s390/cio/vfio_ccw_drv.c
index 634760ca0dea..4ee953c8ae39 100644
--- a/drivers/s390/cio/vfio_ccw_drv.c
+++ b/drivers/s390/cio/vfio_ccw_drv.c
@@ -154,7 +154,6 @@ static struct vfio_ccw_private 
*vfio_ccw_alloc_private(struct subchannel *sch)
if (!private)
return ERR_PTR(-ENOMEM);
 
-   private->sch = sch;
mutex_init(&private->io_mutex);
private->state = VFIO_CCW_STATE_STANDBY;
INIT_LIST_HEAD(&private->crw);
@@ -383,7 +382,7 @@ static int vfio_ccw_chp_event(struct subchannel *sch,
if (!private || !mask)
return 0;
 
-   trace_vfio_ccw_chp_event(private->sch->schid, mask, event);
+   trace_vfio_ccw_chp_event(sch->schid, mask, event);
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: mask=0x%x event=%d\n",
   sch->schid.cssid,
   sch->schid.ssid, sch->schid.sch_no,
diff --git a/drivers/s390/cio/vfio_ccw_fsm.c b/drivers/s390/cio/vfio_ccw_fsm.c
index a59c758869f8..e67fad897af3 100644
--- a/drivers/s390/cio/vfio_ccw_fsm.c
+++ b/drivers/s390/cio/vfio_ccw_fsm.c
@@ -18,15 +18,13 @@
 
 static int fsm_io_helper(struct vfio_ccw_private *private)
 {
-   struct subchannel *sch;
+   struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
union orb *orb;
int ccode;
__u8 lpm;
unsigned long flags;
int ret;
 
-   sch = private->sch;
-
spin_lock_irqsave(sch->lock, flags);
 
orb = cp_get_orb(&private->cp, (u32)(addr_t)sch, sch->lpm);
@@ -80,13 +78,11 @@ static int fsm_io_helper(struct vfio_ccw_private *private)
 
 static int fsm_do_halt(struct vfio_ccw_private *private)
 {
-   struct subchannel *sch;
+   struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
unsigned long flags;
int ccode;
int ret;
 
-   sch = private->sch;
-
spin_lock_irqsave(sch->lock, flags);
 
VFIO_CCW_TRACE_EVENT(2, "haltIO");
@@ -121,13 +117,11 @@ static int fsm_do_halt(struct vfio_ccw_private *private)
 
 static int fsm_do_clear(struct vfio_ccw_private *private)
 {
-   struct subchannel *sch;
+   struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
unsigned long flags;
int ccode;
int ret;
 
-   sch = private->sch;
-
spin_lock_irqsave(sch->lock, flags);
 
VFIO_CCW_TRACE_EVENT(2, "clearIO");
@@ -160,7 +154,7 @@ static int fsm_do_clear(struct vfio_ccw_private *private)
 static void fsm_notoper(struct vfio_ccw_private *private,
enum vfio_ccw_event event)
 {
-   struct subchannel *sch = private->sch;
+   struct subchannel *sch = to_subchannel(private->vdev.dev->parent);
 
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: notoper event %x state %x\n",
   sch->schid.cssid,
@@ -228,7 +222,7 @@ static void fsm_async_retry(struct vfio_ccw_private 
*private,
 static void fsm_disabled_irq(struct vfio_ccw_private *private,
 enum vfio_ccw_event event)
 {
-   struct subchannel *sch = private->sch;
+   struct subchannel *sch = to_subc

dri-devel@lists.freedesktop.org

2022-10-19 Thread Arnd Bergmann
From: Arnd Bergmann 

Most of the legacy PXA board files were marked as unused in linux-5.19 and
can get removed in linux-6.2. There is support for pxa250/pxa270/pxa300
using devicetree already, which supports a number of boards, but progress
on converting the remaining ones has stalled over the past few years.

The two boards that are left in the tree for now are the three 'sharpsl'
variants (spitz/akita/borzoi) and the 'gumstix' family of machines.
Both of these are supported by qemu, which can be helpful for completing
the DT conversion.

Only PXA25x and PXA27x are left with full boardfile support, so PXA300
can get a lot simpler while still working with DT, and PXA310/320/93x
can be removed entirely.

A good number of drivers become impossible to select after this, so
each of these also get dropped. I'm including the driver patches in the
series here and can either merge them through the soc tree, or they
can get picked up by the individual subsystem maintainers. Since both
the platform and the drivers get removed, the order should not matter.

Note that the patches here are generated with 'git format-patch -D'
and don't contain the contents of removed files because of the
significant size (the first patch is close to a megabyte).

Arnd Bergmann (30):
  ARM: pxa: remove unused board files
  ARM: pxa: remove irda leftover
  ARM: pxa: remove unused pxa3xx-ulpi
  ARM: pxa: drop pxa310/pxa320/pxa93x support
  ARM: pxa: prune unused device support
  power: remove z2_battery driver
  power: remove tosa_battery driver
  ata: remove palmld pata driver
  backlight: remove pxa tosa support
  input: remove pxa930_trkball driver
  input: remove pxa930_rotary keyboard driver
  input: remove zylonite touchscreen driver
  pcmcia: remove unused pxa/sa1100 drivers
  ASoC: pxa: remove unused board support
  ALSA: remove ac97 bus support
  mfd: remove wm97xx driver
  input: remove wm97xx support
  parport: remove ax88796 driver
  power: remove pda_power supply driver
  rtc: remove v3020 driver
  mfd: remove toshiba tmio drivers
  mfd: remove ucb1400 support
  mtd: remove tmio_nand driver
  mmc: remove tmio_mmc driver
  fbdev: remove tmiofb driver
  fbdev: remove w100fb driver
  leds: remove asic3 driver
  usb: remove ohci-tmio driver
  w1: remove ds1wm driver
  mfd: remove htc-pasic3 driver

Cc: st...@rowland.harvard.edu
Cc: alexandre.bell...@bootlin.com
Cc: b...@bgdev.pl
Cc: damien.lem...@opensource.wdc.com
Cc: dan...@zonque.org
Cc: dmitry.torok...@gmail.com
Cc: li...@dominikbrodowski.net
Cc: ba...@kernel.org
Cc: gre...@linuxfoundation.org
Cc: haojian.zhu...@gmail.com
Cc: del...@gmx.de
Cc: pe...@perex.cz
Cc: jingooh...@gmail.com
Cc: l...@kernel.org
Cc: ker...@wantstofly.org
Cc: lgirdw...@gmail.com
Cc: linus.wall...@linaro.org
Cc: marek.va...@gmail.com
Cc: broo...@kernel.org
Cc: mkpe...@internode.on.net
Cc: miquel.ray...@bootlin.com
Cc: lost.dista...@yahoo.com
Cc: philipp.za...@gmail.com
Cc: robert.jarz...@free.fr
Cc: li...@armlinux.org.uk
Cc: s...@kernel.org
Cc: sla...@ossfans.org
Cc: s.shtyl...@omp.ru
Cc: sudipm.mukher...@gmail.com
Cc: ti...@suse.com
Cc: ulf.hans...@linaro.org
Cc: vigne...@ti.com
Cc: viresh.ku...@linaro.org
Cc: wsa+rene...@sang-engineering.com
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: patc...@opensource.cirrus.com
Cc: linux-l...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: alsa-de...@alsa-project.org

 Documentation/power/power_supply_class.rst|4 +-
 MAINTAINERS   |  100 +-
 arch/arm/Kconfig  |1 -
 arch/arm/configs/cm_x300_defconfig|  163 --
 arch/arm/configs/colibri_pxa270_defconfig |  157 --
 arch/arm/configs/colibri_pxa300_defconfig |   60 -
 arch/arm/configs/corgi_defconfig  |  247 ---
 arch/arm/configs/eseries_pxa_defconfig|   97 -
 arch/arm/configs/ezx_defconfig|  389 
 arch/arm/configs/h5000_defconfig  |   74 -
 arch/arm/configs/lpd270_defconfig |   58 -
 arch/arm/configs/lubbock_defconfig|   53 -
 arch/arm/configs/magician_defconfig   |  151 --
 arch/arm/configs/mainstone_defconfig  |   51 -
 arch/arm/configs/palmz72_defconfig|   75 -
 arch/arm/configs/pcm027_defconfig |   90 -
 arch/arm/configs/pxa255-idp_defconfig |   55 -
 arch/arm/configs/pxa_defconfig|3 -
 arch/arm/configs/trizeps4_defconfig   |  207 ---
 arch/arm/configs/viper_defconfig  |  160 --
 arch/arm/configs/xcep_defconfig   |   89 -
 arch/arm/configs/zeus_defconfig   |  173 --
 arch/arm/mach-pxa/Kcon

Re: [PATCH v4 13/17] drm/i915/vm_bind: Update i915_vma_verify_bind_complete()

2022-10-19 Thread Matthew Auld

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Ensure i915_vma_verify_bind_complete() handles case where bind
is not initiated. Also make it non static, add documentation
and move it out of CONFIG_DRM_I915_DEBUG_GEM.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Andi Shyti 
---
  drivers/gpu/drm/i915/i915_vma.c | 16 +++-
  drivers/gpu/drm/i915/i915_vma.h |  1 +
  2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index eaa13e9ba966..4975fc662c86 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -439,12 +439,21 @@ int i915_vma_sync(struct i915_vma *vma)
return i915_vm_sync(vma->vm);
  }
  
-#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)

-static int i915_vma_verify_bind_complete(struct i915_vma *vma)
+/**
+ * i915_vma_verify_bind_complete() - Check for the bind completion of the vma
+ * @vma: vma to check for bind completion


Maybe mention the locking since this is now more than just DEBUG_GEM 
stuff. I assume we need the object lock or otherwise some guarantee that 
the vma is pinned?


Reviewed-by: Matthew Auld 


+ *
+ * Returns: 0 if the vma bind is completed. Error code otherwise.
+ */
+int i915_vma_verify_bind_complete(struct i915_vma *vma)
  {
struct dma_fence *fence = i915_active_fence_get(&vma->active.excl);
int err;
  
+	/* Ensure vma bind is initiated */

+   if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK))
+   return -EINVAL;
+
if (!fence)
return 0;
  
@@ -457,9 +466,6 @@ static int i915_vma_verify_bind_complete(struct i915_vma *vma)
  
  	return err;

  }
-#else
-#define i915_vma_verify_bind_complete(_vma) 0
-#endif
  
  I915_SELFTEST_EXPORT void

  i915_vma_resource_init_from_vma(struct i915_vma_resource *vma_res,
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 1cadbf8fdedf..04770f8ba815 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -440,6 +440,7 @@ void i915_vma_make_purgeable(struct i915_vma *vma);
  
  int i915_vma_wait_for_bind(struct i915_vma *vma);

  int i915_vma_sync(struct i915_vma *vma);
+int i915_vma_verify_bind_complete(struct i915_vma *vma);
  
  /**

   * i915_vma_get_current_resource - Get the current resource of the vma


Re: [PATCH v4 14/17] drm/i915/vm_bind: Expose i915_request_await_bind()

2022-10-19 Thread Matthew Auld

On 18/10/2022 08:16, Niranjana Vishwanathapura wrote:

Rename __i915_request_await_bind() as i915_request_await_bind()
and make it non-static as it will be used in execbuf3 ioctl path.

Reviewed-by: Andi Shyti 
Signed-off-by: Niranjana Vishwanathapura 
---
  drivers/gpu/drm/i915/i915_vma.c | 8 +---
  drivers/gpu/drm/i915/i915_vma.h | 6 ++
  2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4975fc662c86..ab89e907f2eb 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1884,18 +1884,12 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
list_del(&vma->obj->userfault_link);
  }
  
-static int

-__i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)
-{
-   return __i915_request_await_exclusive(rq, &vma->active);
-}
-
  static int __i915_vma_move_to_active(struct i915_vma *vma, struct 
i915_request *rq)
  {
int err;
  
  	/* Wait for the vma to be bound before we start! */

-   err = __i915_request_await_bind(rq, vma);
+   err = i915_request_await_bind(rq, vma);
if (err)
return err;
  
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h

index 04770f8ba815..19e57e12b956 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -54,6 +54,12 @@ void i915_vma_unpin_and_release(struct i915_vma **p_vma, 
unsigned int flags);
  /* do not reserve memory to prevent deadlocks */
  #define __EXEC_OBJECT_NO_RESERVE BIT(31)
  
+static inline int

+i915_request_await_bind(struct i915_request *rq, struct i915_vma *vma)


Some kernel doc might be good?

Reviewed-by: Matthew Auld 


+{
+   return __i915_request_await_exclusive(rq, &vma->active);
+}
+
  int __must_check _i915_vma_move_to_active(struct i915_vma *vma,
  struct i915_request *rq,
  struct dma_fence *fence,


Re: [PATCH] drm: tests: Fix a buffer overflow in format_helper_test

2022-10-19 Thread Javier Martinez Canillas
On 10/19/22 13:36, Maíra Canal wrote:
> [cc Javier]
> 
> Hi David,
> 
> On 10/19/22 04:32, David Gow wrote:
>> The xrgb2101010 format conversion test (unlike for other formats) does
>> an endianness conversion on the results. However, it always converts
>> TEST_BUF_SIZE 32-bit integers, which results in reading from (and
>> writing to) more memory than in present in the result buffer. Instead,
>> use the buffer size, divided by sizeof(u32).
>>
>> The issue could be reproduced with KASAN:
>> ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/tests \
>>  --kconfig_add CONFIG_KASAN=y --kconfig_add CONFIG_KASAN_VMALLOC=y \
>>  --kconfig_add CONFIG_KASAN_KUNIT_TEST=y \
>>  drm_format_helper_test.*xrgb2101010
>>
>> Reported-by: Linux Kernel Functional Testing 
>> Fixes: 453114319699 ("drm/format-helper: Add KUnit tests for 
>> drm_fb_xrgb_to_xrgb2101010()")
>> Signed-off-by: David Gow 
> 
> Reviewed-by: Maíra Canal 
>

The fix makes sense to me as well,

Reviewed-by: Javier Martinez Canillas 

>> ---
>>
>> This is a fix for the issue reported here:
>> https://lore.kernel.org/dri-devel/CA+G9fYsuc9G+RO81E=vHMqxYStsmLURLdOB0NF26kJ1=k8p...@mail.gmail.com/
>>
>> Note that it may conflict with the KUNIT_EXPECT_MEMEQ() series here:
>> https://lore.kernel.org/linux-kselftest/20221018190541.189780-1-mairaca...@riseup.net/
> 
> I believe this patch will go to the drm-misc-fixes tree, so I can rebase
> the series (and address the format issues) as this patch hits mainline.
> 

Awesome. I assume you are pushing to drm-misc-fixes then?

Thanks a lot David and Maíra for taking care of this!

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat



Re: [PATCH v2 36/37] arm64: dts: zynqmp: Add ports for the DisplayPort subsystem

2022-10-19 Thread Laurent Pinchart
Hi Michal,

I plan to send a pull request for the series soon. Patches 01/37 to
35/37 will go through the DRM tree. How would you like to handle this
patch and the next ? They depend on the DT binding changes in 01/37.

On Thu, Sep 29, 2022 at 01:47:18AM +0300, Laurent Pinchart wrote:
> The DPSUB DT bindings now specify ports to model the connections with
> the programmable logic and the DisplayPort output. Add them to the
> device tree.
> 
> Signed-off-by: Laurent Pinchart 
> ---
>  arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi 
> b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> index a549265e55f6..307c76cd8544 100644
> --- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> +++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
> @@ -930,6 +930,30 @@ zynqmp_dpsub: display@fd4a {
>  <&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO1>,
>  <&zynqmp_dpdma ZYNQMP_DPDMA_VIDEO2>,
>  <&zynqmp_dpdma ZYNQMP_DPDMA_GRAPHICS>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + };
> + port@1 {
> + reg = <1>;
> + };
> + port@2 {
> + reg = <2>;
> + };
> + port@3 {
> + reg = <3>;
> + };
> + port@4 {
> + reg = <4>;
> + };
> + port@5 {
> + reg = <5>;
> + };
> + };
>   };
>   };
>  };

-- 
Regards,

Laurent Pinchart


dri-devel@lists.freedesktop.org

2022-10-19 Thread Arnd Bergmann
From: Arnd Bergmann 

Most of the legacy PXA board files were marked as unused in linux-5.19 and
can get removed in linux-6.2. There is support for pxa250/pxa270/pxa300
using devicetree already, which supports a number of boards, but progress
on converting the remaining ones has stalled over the past few years.

The two boards that are left in the tree for now are the three 'sharpsl'
variants (spitz/akita/borzoi) and the 'gumstix' family of machines.
Both of these are supported by qemu, which can be helpful for completing
the DT conversion.

Only PXA25x and PXA27x are left with full boardfile support, so PXA300
can get a lot simpler while still working with DT, and PXA310/320/93x
can be removed entirely.

A good number of drivers become impossible to select after this, so
each of these also get dropped. I'm including the driver patches in the
series here and can either merge them through the soc tree, or they
can get picked up by the individual subsystem maintainers. Since both
the platform and the drivers get removed, the order should not matter.

Note that the patches here are generated with 'git format-patch -D'
and don't contain the contents of removed files because of the
significant size (the first patch is close to a megabyte).

Arnd Bergmann (30):
  ARM: pxa: remove unused board files
  ARM: pxa: remove irda leftover
  ARM: pxa: remove unused pxa3xx-ulpi
  ARM: pxa: drop pxa310/pxa320/pxa93x support
  ARM: pxa: prune unused device support
  power: remove z2_battery driver
  power: remove tosa_battery driver
  ata: remove palmld pata driver
  backlight: remove pxa tosa support
  input: remove pxa930_trkball driver
  input: remove pxa930_rotary keyboard driver
  input: remove zylonite touchscreen driver
  pcmcia: remove unused pxa/sa1100 drivers
  ASoC: pxa: remove unused board support
  ALSA: remove ac97 bus support
  mfd: remove wm97xx driver
  input: remove wm97xx support
  parport: remove ax88796 driver
  power: remove pda_power supply driver
  rtc: remove v3020 driver
  mfd: remove toshiba tmio drivers
  mfd: remove ucb1400 support
  mtd: remove tmio_nand driver
  mmc: remove tmio_mmc driver
  fbdev: remove tmiofb driver
  fbdev: remove w100fb driver
  leds: remove asic3 driver
  usb: remove ohci-tmio driver
  w1: remove ds1wm driver
  mfd: remove htc-pasic3 driver

Cc: Alan Stern 
Cc: Alexandre Belloni 
Cc: Bartosz Golaszewski 
Cc: Damien Le Moal 
Cc: Daniel Mack 
Cc: Dmitry Torokhov 
Cc: Dominik Brodowski 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: Haojian Zhuang 
Cc: Helge Deller 
Cc: Jaroslav Kysela 
Cc: Jingoo Han 
Cc: Lee Jones 
Cc: Lennert Buytenhek 
Cc: Liam Girdwood 
Cc: Linus Walleij 
Cc: Marek Vasut 
Cc: Mark Brown 
Cc: Michael Petchkovsky 
Cc: Miquel Raynal 
Cc: Paul Parsons 
Cc: Philipp Zabel 
Cc: Robert Jarzmik 
Cc: Russell King 
Cc: Sebastian Reichel 
Cc: Sergey Lapin 
Cc: Sergey Shtylyov 
Cc: Sudip Mukherjee 
Cc: Takashi Iwai 
Cc: Ulf Hansson 
Cc: Vignesh Raghavendra 
Cc: Viresh Kumar 
Cc: Wolfram Sang 
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: patc...@opensource.cirrus.com
Cc: linux-l...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-renesas-...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Cc: alsa-de...@alsa-project.org

 Documentation/power/power_supply_class.rst|4 +-
 MAINTAINERS   |  100 +-
 arch/arm/Kconfig  |1 -
 arch/arm/configs/cm_x300_defconfig|  163 --
 arch/arm/configs/colibri_pxa270_defconfig |  157 --
 arch/arm/configs/colibri_pxa300_defconfig |   60 -
 arch/arm/configs/corgi_defconfig  |  247 ---
 arch/arm/configs/eseries_pxa_defconfig|   97 -
 arch/arm/configs/ezx_defconfig|  389 
 arch/arm/configs/h5000_defconfig  |   74 -
 arch/arm/configs/lpd270_defconfig |   58 -
 arch/arm/configs/lubbock_defconfig|   53 -
 arch/arm/configs/magician_defconfig   |  151 --
 arch/arm/configs/mainstone_defconfig  |   51 -
 arch/arm/configs/palmz72_defconfig|   75 -
 arch/arm/configs/pcm027_defconfig |   90 -
 arch/arm/configs/pxa255-idp_defconfig |   55 -
 arch/arm/configs/pxa_defconfig|3 -
 arch/arm/configs/trizeps4_defconfig   |  207 ---
 arch/arm/configs/viper_defconfig  |  160 --
 arch/arm/configs/xcep_defconfig   |   89 -
 arch/arm/configs/zeus_defconfig   |  173 --
 arch/arm/mach-pxa/Kconfig |  583 +-
 arch/arm/mach-pxa/Makefile|   60 +-
 arch/arm/mach-pxa/balloon3-pcmcia.c   |  137 --
 arch/arm/mach-pxa/balloon3.c  |  821 
 arc

Re: [PATCH] drm/connector: Set DDC pointer in drmm_connector_init

2022-10-19 Thread Thomas Zimmermann



Am 19.10.22 um 16:34 schrieb Maxime Ripard:

Commit 35a3b82f1bdd ("drm/connector: Introduce drmm_connector_init")
introduced the function drmm_connector_init() with a parameter for an
optional ddc pointer to the i2c controller used to access the DDC bus.

However, the underlying call to __drm_connector_init() was always
setting it to NULL instead of passing the ddc argument around.

This resulted in unexpected null pointer dereference on platforms
expecting to get a DDC controller.

Fixes: 35a3b82f1bdd ("drm/connector: Introduce drmm_connector_init")
Signed-off-by: Maxime Ripard 


Reviewed-by: Thomas Zimmermann 


---
  drivers/gpu/drm/drm_connector.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index e3142c8142b3..61c29ce74b03 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -435,7 +435,7 @@ int drmm_connector_init(struct drm_device *dev,
if (drm_WARN_ON(dev, funcs && funcs->destroy))
return -EINVAL;
  
-	ret = __drm_connector_init(dev, connector, funcs, connector_type, NULL);

+   ret = __drm_connector_init(dev, connector, funcs, connector_type, ddc);
if (ret)
return ret;
  


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH v3 2/4] dt-bindings: display: add new bus-format property for panel-dpi

2022-10-19 Thread Dave Stevenson
Hi Laurent

On Sun, 16 Oct 2022 at 02:33, Laurent Pinchart
 wrote:
>
> Hello,
>
> On Fri, Oct 14, 2022 at 03:08:49PM +0100, Dave Stevenson wrote:
> > On Thu, 13 Oct 2022 at 13:58, Francesco Dolcini wrote:
> > > On Tue, Jun 28, 2022 at 08:18:36PM +0200, Max Krummenacher wrote:
> > > > From: Max Krummenacher 
> > > >
> > > > The property is used to set the enum bus_format and infer the bpc
> > > > for a panel defined by 'panel-dpi'.
> > > > This specifies how the panel is connected to the display interface.
> > > >
> > > > Signed-off-by: Max Krummenacher 
> > > >
> > >
> > > 
> > >
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml 
> > > > b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> > > > index dae0676b5c6e..52f5db03b6a8 100644
> > > > --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> > > > +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.yaml
> > > > @@ -26,7 +26,28 @@ properties:
> > > >height-mm: true
> > > >label: true
> > > >panel-timing: true
> > > > -  port: true
> > > > +
> > > > +  port:
> > > > +$ref: /schemas/graph.yaml#/$defs/port-base
> > > > +description:
> > > > +  Input port node, receives the panel data.
> > > > +
> > > > +properties:
> > > > +  endpoint:
> > > > +$ref: /schemas/graph.yaml#/$defs/endpoint-base
> > > > +
> > > > +properties:
> > > > +  bus-format:
> > > > +$ref: /schemas/types.yaml#/definitions/uint32
> > > > +minimum: 0x1001
> > > > +maximum: 0x1fff
> > > > +description: |
> > > > +  Describes how the display panel is connected to the 
> > > > display interface.
> > > > +  Valid values are defined in 
> > > > .
> > > > +  The mapping between the color/significance of the panel 
> > > > lines to the
> > > > +  parallel data lines are defined in:
> > > > +  
> > > > https://www.kernel.org/doc/html/v5.17/userspace-api/media/v4l/subdev-formats.html#packed-rgb-formats
> > > > +
> > >
> > > Last month I had the chance to talk in person about this topic with
> > > Dave, Marek and Max in Dublin.
> > >
> > > My understanding is that this change is addressing a general need, Dave
> > > confirmed me they have a downstream patch for raspberrypi [1].
> > >
> > > From what I could tell the only concern is about the actual encoding of
> > > this `bus-format` property.
> > >
> > > I am personally convinced that a simple enum is the way to go, I think
> > > that Marek proposal is adding complexity and not flexibility (from my
> > > understanding Dave is on the same page, just correct me if I
> > > misunderstood you).
> >
> > Yes I agree with you here.
> >
> > This binding is for the panel, and currently the only path to pass the
> > panel mode to the DPI transmitter is one or more MEDIA_BUS_FMT_* enums
> > in struct drm_display_info *bus_formats.
> >
> > Looking at Marek's comment over DSI and data-lanes, yes both source
> > and sink could advertise a data-lanes property to cover the condition
> > where they aren't wired up in a 1:1 fashion. Reality is that most
> > drivers don't support reordering the lanes - looking at the bindings,
> > only one (msm) documents the use of data-lanes on the host side.
> > rcar_mipi_dsi looks at the number of lanes specified only, and then
> > checks that the number requested by the device is <= the number
> > configured.
> >
> > As I see it, the comparison here is that this "bus-format" property is
> > the equivalent of the data-lanes on the sink, and is the desired
> > number of lanes value passed from sink to source (one integer, not a
> > mapping).
> > If the source can reorder the lanes, then that is a property of the
> > source. This binding is for the sink, and so isn't a reasonable
> > comparison. It also doesn't have to be called "bus-format" on the
> > source, and can take a totally different form.
> > I'll admit that I know data-lane configuration more from CSI2, but
> > within V4L2 it is the node that can support reordering that should
> > have the lanes in a non-incrementing order, and that is normally the
> > SoC rather than the sensor. The same would seem to apply here - it's
> > the SoC that can remap the signals, not the panel.
> >
> > It could be argued that for DPI the panel should only advertise the
> > panel's bit depth for each channel, not the padding. The panel is
> > generic and could handle any wiring/padding options, and it isn't
> > necessarily a simple 16/18/24/32 bit bus representation, just a
> > collection of N wires.
> > Padding and wiring is a function of the DPI transmitter / SoC, or
> > potentially an interconnect node between the two.
>
> Sooo... I'm not sure where to start :-)
>
> I think the trouble when describing the connection between a source and
> a sink in DT is that none of the source or sink is an ideal place to
> describe properties of the connection

[PATCH 6/6] drm/vmwgfx: fix’s on ttm_resource rework to use size_t type

2022-10-19 Thread Somalapuram Amaranath
Fix the ttm_resource from num_pages to size_t size.

Signed-off-by: Somalapuram Amaranath 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_blit.c  | 4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 6 +++---
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
index 09fe20e918f9..c52c7bf1485b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_blit.c
@@ -483,8 +483,8 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
d.src_addr = NULL;
d.dst_pages = dst->ttm->pages;
d.src_pages = src->ttm->pages;
-   d.dst_num_pages = dst->resource->num_pages;
-   d.src_num_pages = src->resource->num_pages;
+   d.dst_num_pages = PFN_UP(dst->resource->size);
+   d.src_num_pages = PFN_UP(src->resource->size);
d.dst_prot = ttm_io_prot(dst, dst->resource, PAGE_KERNEL);
d.src_prot = ttm_io_prot(src, src->resource, PAGE_KERNEL);
d.diff = diff;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 822251aaab0a..134a13a50861 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -194,7 +194,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private 
*dev_priv,
int ret = 0;
 
place = vmw_vram_placement.placement[0];
-   place.lpfn = bo->resource->num_pages;
+   place.lpfn = PFN_UP(bo->resource->size);
placement.num_placement = 1;
placement.placement = &place;
placement.num_busy_placement = 1;
@@ -211,7 +211,7 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private 
*dev_priv,
 * that situation.
 */
if (bo->resource->mem_type == TTM_PL_VRAM &&
-   bo->resource->start < bo->resource->num_pages &&
+   bo->resource->start < PFN_UP(bo->resource->size) &&
bo->resource->start > 0 &&
buf->base.pin_count == 0) {
ctx.interruptible = false;
@@ -352,7 +352,7 @@ void *vmw_bo_map_and_cache(struct vmw_buffer_object *vbo)
if (virtual)
return virtual;
 
-   ret = ttm_bo_kmap(bo, 0, bo->resource->num_pages, &vbo->map);
+   ret = ttm_bo_kmap(bo, 0, PFN_UP(bo->resource->size), &vbo->map);
if (ret)
DRM_ERROR("Buffer object map failed: %d.\n", ret);
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
index 79b30dc9d825..c5ed49241f9d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c
@@ -427,7 +427,7 @@ static int vmw_cotable_resize(struct vmw_resource *res, 
size_t new_size)
 * Do a page by page copy of COTables. This eliminates slow vmap()s.
 * This should really be a TTM utility.
 */
-   for (i = 0; i < old_bo->resource->num_pages; ++i) {
+   for (i = 0; i < PFN_UP(old_bo->resource->size); ++i) {
bool dummy;
 
ret = ttm_bo_kmap(old_bo, i, 1, &old_map);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index f085dbd4736d..2fb53aa57a56 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -1047,7 +1047,7 @@ static int vmw_query_bo_switch_prepare(struct vmw_private 
*dev_priv,
 
if (unlikely(new_query_bo != sw_context->cur_query_bo)) {
 
-   if (unlikely(new_query_bo->base.resource->num_pages > 4)) {
+   if (unlikely(PFN_UP(new_query_bo->base.resource->size) > 4)) {
VMW_DEBUG_USER("Query buffer too large.\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index 60e3cc537f36..abd5e3323ebf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -71,7 +71,7 @@ static int vmw_gmrid_man_get_node(struct ttm_resource_manager 
*man,
spin_lock(&gman->lock);
 
if (gman->max_gmr_pages > 0) {
-   gman->used_gmr_pages += (*res)->num_pages;
+   gman->used_gmr_pages += PFN_UP((*res)->size);
/*
 * Because the graphics memory is a soft limit we can try to
 * expand it instead of letting the userspace apps crash.
@@ -114,7 +114,7 @@ static int vmw_gmrid_man_get_node(struct 
ttm_resource_manager *man,
return 0;
 
 nospace:
-   gman->used_gmr_pages -= (*res)->num_pages;
+   gman->used_gmr_pages -= PFN_UP((*res)->size);
spin_unlock(&gman->lock);
ida_free(&gman->gmr_ida, 

[PATCH 5/6] drm/radeon: fix’s on ttm_resource rework to use size_t type

2022-10-19 Thread Somalapuram Amaranath
Fix the ttm_resource from num_pages to size_t size.

Signed-off-by: Somalapuram Amaranath 
---
 drivers/gpu/drm/radeon/radeon_cs.c | 4 ++--
 drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
 drivers/gpu/drm/radeon/radeon_trace.h  | 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index 446f7bae54c4..4c930f0cf132 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -400,8 +400,8 @@ static int cmp_size_smaller_first(void *priv, const struct 
list_head *a,
struct radeon_bo_list *lb = list_entry(b, struct radeon_bo_list, 
tv.head);
 
/* Sort A before B if A is smaller. */
-   return (int)la->robj->tbo.resource->num_pages -
-   (int)lb->robj->tbo.resource->num_pages;
+   return (int)PFN_UP(la->robj->tbo.resource->size) -
+   (int)PFN_UP(lb->robj->tbo.resource->size);
 }
 
 /**
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 00c33b24d5d3..710d04fcbea6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -232,7 +232,7 @@ int radeon_bo_kmap(struct radeon_bo *bo, void **ptr)
}
return 0;
}
-   r = ttm_bo_kmap(&bo->tbo, 0, bo->tbo.resource->num_pages, &bo->kmap);
+   r = ttm_bo_kmap(&bo->tbo, 0, PFN_UP(bo->tbo.resource->size), &bo->kmap);
if (r) {
return r;
}
@@ -737,7 +737,7 @@ vm_fault_t radeon_bo_fault_reserve_notify(struct 
ttm_buffer_object *bo)
if (bo->resource->mem_type != TTM_PL_VRAM)
return 0;
 
-   size = bo->resource->num_pages << PAGE_SHIFT;
+   size = bo->resource->size;
offset = bo->resource->start << PAGE_SHIFT;
if ((offset + size) <= rdev->mc.visible_vram_size)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_trace.h 
b/drivers/gpu/drm/radeon/radeon_trace.h
index c9fed5f2b870..22676617e1a5 100644
--- a/drivers/gpu/drm/radeon/radeon_trace.h
+++ b/drivers/gpu/drm/radeon/radeon_trace.h
@@ -22,7 +22,7 @@ TRACE_EVENT(radeon_bo_create,
 
TP_fast_assign(
   __entry->bo = bo;
-  __entry->pages = bo->tbo.resource->num_pages;
+  __entry->pages = PFN_UP(bo->tbo.resource->size);
   ),
TP_printk("bo=%p, pages=%u", __entry->bo, __entry->pages)
 );
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index d33fec488713..fff48306c05f 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -181,7 +181,7 @@ static int radeon_move_blit(struct ttm_buffer_object *bo,
 
BUILD_BUG_ON((PAGE_SIZE % RADEON_GPU_PAGE_SIZE) != 0);
 
-   num_pages = new_mem->num_pages * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
+   num_pages = PFN_UP(new_mem->size) * (PAGE_SIZE / RADEON_GPU_PAGE_SIZE);
fence = radeon_copy(rdev, old_start, new_start, num_pages, 
bo->base.resv);
if (IS_ERR(fence))
return PTR_ERR(fence);
@@ -268,7 +268,7 @@ static int radeon_bo_move(struct ttm_buffer_object *bo, 
bool evict,
 static int radeon_ttm_io_mem_reserve(struct ttm_device *bdev, struct 
ttm_resource *mem)
 {
struct radeon_device *rdev = radeon_get_rdev(bdev);
-   size_t bus_size = (size_t)mem->num_pages << PAGE_SHIFT;
+   size_t bus_size = (size_t)mem->size;
 
switch (mem->mem_type) {
case TTM_PL_SYSTEM:
-- 
2.32.0



[PATCH 4/6] drm/nouveau: fix’s on ttm_resource rework to use size_t type

2022-10-19 Thread Somalapuram Amaranath
Fix the ttm_resource from num_pages to size_t size.

Signed-off-by: Somalapuram Amaranath 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c| 5 ++---
 drivers/gpu/drm/nouveau/nouveau_mem.c| 4 ++--
 drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
 11 files changed, 18 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 126b3c6e12f9..16ca4a141866 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -532,7 +532,7 @@ nouveau_bo_map(struct nouveau_bo *nvbo)
if (ret)
return ret;
 
-   ret = ttm_bo_kmap(&nvbo->bo, 0, nvbo->bo.resource->num_pages, 
&nvbo->kmap);
+   ret = ttm_bo_kmap(&nvbo->bo, 0, PFN_UP(nvbo->bo.resource->size), 
&nvbo->kmap);
 
ttm_bo_unreserve(&nvbo->bo);
return ret;
@@ -1236,7 +1236,7 @@ vm_fault_t nouveau_ttm_fault_reserve_notify(struct 
ttm_buffer_object *bo)
} else {
/* make sure bo is in mappable vram */
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA ||
-   bo->resource->start + bo->resource->num_pages < mappable)
+   bo->resource->start + PFN_UP(bo->resource->size) < mappable)
return 0;
 
for (i = 0; i < nvbo->placement.num_placement; ++i) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo0039.c 
b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
index 7390132129fe..e2ce44adaa5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo0039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo0039.c
@@ -52,7 +52,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
u32 src_offset = old_reg->start << PAGE_SHIFT;
u32 dst_ctxdma = nouveau_bo_mem_ctxdma(bo, chan, new_reg);
u32 dst_offset = new_reg->start << PAGE_SHIFT;
-   u32 page_count = new_reg->num_pages;
+   u32 page_count = PFN_UP(new_reg->size);
int ret;
 
ret = PUSH_WAIT(push, 3);
@@ -62,7 +62,7 @@ nv04_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
PUSH_MTHD(push, NV039, SET_CONTEXT_DMA_BUFFER_IN, src_ctxdma,
   SET_CONTEXT_DMA_BUFFER_OUT, dst_ctxdma);
 
-   page_count = new_reg->num_pages;
+   page_count = PFN_UP(new_reg->size);
while (page_count) {
int line_count = (page_count > 2047) ? 2047 : page_count;
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo5039.c 
b/drivers/gpu/drm/nouveau/nouveau_bo5039.c
index 4c75c7b3804c..c6cf3629a9f9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo5039.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo5039.c
@@ -41,7 +41,7 @@ nv50_bo_move_m2mf(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
 {
struct nouveau_mem *mem = nouveau_mem(old_reg);
struct nvif_push *push = chan->chan.push;
-   u64 length = (new_reg->num_pages << PAGE_SHIFT);
+   u64 length = new_reg->size;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
int src_tiled = !!mem->kind;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c 
b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
index ed6c09d67840..9b7ba31fae13 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo74c1.c
@@ -44,7 +44,7 @@ nv84_bo_move_exec(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
if (ret)
return ret;
 
-   PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->num_pages << PAGE_SHIFT,
+   PUSH_NVSQ(push, NV74C1, 0x0304, new_reg->size,
0x0308, upper_32_bits(mem->vma[0].addr),
0x030c, lower_32_bits(mem->vma[0].addr),
0x0310, upper_32_bits(mem->vma[1].addr),
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c 
b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
index dec29b2d8bb2..a15a38a87a95 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo85b5.c
@@ -44,10 +44,10 @@ nva3_bo_move_copy(struct nouveau_channel *chan, struct 
ttm_buffer_object *bo,
struct nvif_push *push = chan->chan.push;
u64 src_offset = mem->vma[0].addr;
u64 dst_offset = mem->vma[1].addr;
-   u32 page_count = new_reg->num_pages;
+   u32 page_count = PFN_UP(new_reg->size);
int ret;
 
-   page_count = new_reg->num_pages;
+   page_count = PFN_UP(new_reg->size);
while (page_count) {
int line_count = (page_count > 8191) ? 8191 : page_count

  1   2   >