Re: [Intel-gfx] [RFC PATCH v3 10/17] drm/i915/vm_bind: Implement I915_GEM_EXECBUFFER3 ioctl

2022-09-01 Thread Niranjana Vishwanathapura

On Thu, Sep 01, 2022 at 08:58:57AM +0100, Tvrtko Ursulin wrote:



On 01/09/2022 06:09, Niranjana Vishwanathapura wrote:

On Wed, Aug 31, 2022 at 08:38:48AM +0100, Tvrtko Ursulin wrote:


On 27/08/2022 20:43, Andi Shyti wrote:

From: Niranjana Vishwanathapura 

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.

And the legacy support like relocations etc are removed.

Signed-off-by: Niranjana Vishwanathapura 


Signed-off-by: Ramalingam C 
Signed-off-by: Andi Shyti 
---


[snip]


+static void signal_fence_array(const struct i915_execbuffer *eb,
+   struct dma_fence * const fence)
+{
+    unsigned int n;
+
+    for (n = 0; n < eb->num_fences; n++) {
+    struct drm_syncobj *syncobj;
+    unsigned int flags;
+
+    syncobj = ptr_unpack_bits(eb->fences[n].syncobj, , 2);
+    if (!(flags & I915_TIMELINE_FENCE_SIGNAL))
+    continue;
+
+    if (eb->fences[n].chain_fence) {
+    drm_syncobj_add_point(syncobj,
+  eb->fences[n].chain_fence,
+  fence,
+  eb->fences[n].value);
+    /*
+ * The chain's ownership is transferred to the
+ * timeline.
+ */
+    eb->fences[n].chain_fence = NULL;
+    } else {
+    drm_syncobj_replace_fence(syncobj, fence);
+    }
+    }
+}
Semi-random place to ask - how many of the code here is direct 
copy of existing functions from i915_gem_execbuffer.c? There seems 
to be some 100% copies at least. And then some more with small 
tweaks. Spend some time and try to figure out some code sharing?




During VM_BIND design review, maintainers expressed thought on keeping
execbuf3 completely separate and not touch the legacy execbuf path.


Got a link so this maintainer can see what exactly was said? Just to 
make sure there isn't any misunderstanding on what "completely 
separate" means to different people.


Here is one (search for copypaste/copy-paste)
https://patchwork.freedesktop.org/patch/486608/?series=93447=3
It is hard to search for old discussion threads. May be maintainers
can provide feedback here directly. Dave, Daniel? :)




I also think, execbuf3 should be fully separate. We can do some code
sharing where is a close 100% copy (there is a TODO in cover letter).
There are some changes like the timeline fence array handling here
which looks similar, but the uapi is not exactly the same. Probably,
we should keep them separate and not try to force code sharing at
least at this point.


Okay did not spot that TODO in the cover. But fair since it is RFC to 
be unfinished.


I do however think it should be improved before considering the merge. 
Because looking at the patch, 100% copies are:


for_each_batch_create_order
for_each_batch_add_order
eb_throttle
eb_pin_timeline
eb_pin_engine
eb_put_engine
__free_fence_array
put_fence_array
await_fence_array
signal_fence_array
retire_requests
eb_request_add
eb_requests_get
eb_requests_put
eb_find_context

Quite a lot.

Then there is a bunch of almost same functions which could be shared 
if there weren't two incompatible local struct i915_execbuffer's. 
Especially given when the out fence TODO item gets handled a chunk 
more will also become a 100% copy.




There are difinitely a few which is 100% copies hence should have a
shared code.
But some are not. Like, fence_array stuff though looks very similar,
the uapi structures are different between execbuf3 and legacy execbuf.
The internal flags are also different (eg., __EXEC3_ENGINE_PINNED vs
__EXEC_ENGINE_PINNED) which causes minor differences hence not a
100% copy.

So, I am not convinced if it is worth carrying legacy stuff into
execbuf3 code. I think we need to look at these on a case by case
basis and see if abstracting common functionality to a separate
shared code makes sense or it is better to keep the code separate.

This could be done by having a common struct i915_execbuffer and then 
eb2 and eb3 specific parts which inherit from it. After that is done 
it should be easier to see if it makes sense to do something more and 
how.


I am not a big fan of it. I think we should not try to load the execbuf3
code with the legacy stuff.

Niranjana



Regards,

Tvrtko


[PATCH 1/2] video: fbdev: gbefb: Convert to use dev_groups

2022-09-01 Thread Jiasheng Jiang
The driver core supports the ability to handle the creation and removal
of device-specific sysfs files in a race-free manner. Moreover, it can
guarantee the success of creation. Therefore, it should be better to
convert to use dev_groups.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jiasheng Jiang 
---
 drivers/video/fbdev/gbefb.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 6b4d5a7f3e15..1582c718329c 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -1072,17 +1072,12 @@ static ssize_t gbefb_show_rev(struct device *device, 
struct device_attribute *at
 
 static DEVICE_ATTR(revision, S_IRUGO, gbefb_show_rev, NULL);
 
-static void gbefb_remove_sysfs(struct device *dev)
-{
-   device_remove_file(dev, _attr_size);
-   device_remove_file(dev, _attr_revision);
-}
-
-static void gbefb_create_sysfs(struct device *dev)
-{
-   device_create_file(dev, _attr_size);
-   device_create_file(dev, _attr_revision);
-}
+static struct attribute *gbefb_attrs[] = {
+   _attr_size.attr,
+   _attr_revision.attr,
+   NULL,
+};
+ATTRIBUTE_GROUPS(gbefb);
 
 /*
  * Initialization
@@ -1221,7 +1216,6 @@ static int gbefb_probe(struct platform_device *p_dev)
}
 
platform_set_drvdata(p_dev, info);
-   gbefb_create_sysfs(_dev->dev);
 
fb_info(info, "%s rev %d @ 0x%08x using %dkB memory\n",
info->fix.id, gbe_revision, (unsigned)GBE_BASE,
@@ -1248,7 +1242,6 @@ static int gbefb_remove(struct platform_device* p_dev)
gbe_turn_off();
arch_phys_wc_del(par->wc_cookie);
release_mem_region(GBE_BASE, sizeof(struct sgi_gbe));
-   gbefb_remove_sysfs(_dev->dev);
framebuffer_release(info);
 
return 0;
@@ -1259,6 +1252,7 @@ static struct platform_driver gbefb_driver = {
.remove = gbefb_remove,
.driver = {
.name = "gbefb",
+   .dev_groups = gbefb_groups,
},
 };
 
-- 
2.25.1



[PATCH 2/2] video: fbdev: gbefb: Remove unproper information

2022-09-01 Thread Jiasheng Jiang
When drivers are working properly, they are quiet.
Therefore, the fb_info() should be removed.

Signed-off-by: Jiasheng Jiang 
---
 drivers/video/fbdev/gbefb.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
index 1582c718329c..7e39ab939691 100644
--- a/drivers/video/fbdev/gbefb.c
+++ b/drivers/video/fbdev/gbefb.c
@@ -1217,10 +1217,6 @@ static int gbefb_probe(struct platform_device *p_dev)
 
platform_set_drvdata(p_dev, info);
 
-   fb_info(info, "%s rev %d @ 0x%08x using %dkB memory\n",
-   info->fix.id, gbe_revision, (unsigned)GBE_BASE,
-   gbe_mem_size >> 10);
-
return 0;
 
 out_gbe_unmap:
-- 
2.25.1



[git pull] drm fixes for 6.0-rc4

2022-09-01 Thread Dave Airlie
Hi Linus,

Regular fixes pull. One core dma-buf fix, then two weeks of i915
fixes, a lot of amdgpu fixes mostly for new IP, and a bunch of msm
fixes, mostly modesetting ones.

Nothing seems too bad at this point.

Dave.

drm-fixes-2022-09-02:
drm fixes for 6.0-rc4

dma-buf/dma-resv:
- Fence-handling fix

i915:
- GVT fixes including fix for a CometLake regression in mmio table
  and misc doc and typo fixes
- Fix CCS handling
- Fix for guc requests after reset
- Display DSI related fixes
- Display backlight related fixes
- Fix for a null pointer dereference
- HDMI related quirk for ECS Liva Q2 with GLK graphics
- Skip wm/ddb readout for disabled pipes

amdgpu:
- FRU error message fix
- MES 11 updates
- DCN 3.2.x fixes
- DCN 3.1.4 fixes
- Fix possible use after free in CS IOCTL
- SMU 13.0.x fixes
- Fix iolink reporting on devices with direct connections to CPU
- GFX10 tap delay firmware fixes

msm:
- Fix for inconsistent indenting in function msm_dsi_dphy_timing_calc_v3.
- Fix to make eDP the first connector in the connected list.
- Fix to populate intf_cfg correctly before calling reset_intf_cfg().
- Specify the correct number of DSI regulators for SDM660.
- Specify the correct number of DSI regulators for MSM8996.
- Fix for removing DP_RECOVERED_CLOCK_OUT_EN bit for tps4 link training
- Fix probe-deferral crash in gpu devfreq
- Fix gpu debugfs deadlock
The following changes since commit b90cb1053190353cc30f0fef0ef1f378ccc063c5:

  Linux 6.0-rc3 (2022-08-28 15:05:29 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-02

for you to fetch changes up to bfe632f6d0a1371784dd9a11fa5a9aa2dbf53bf1:

  Merge tag 'drm-intel-fixes-2022-09-01' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2022-09-02
11:26:50 +1000)


drm fixes for 6.0-rc3

dma-buf/dma-resv:
- Fence-handling fix

i915:
- GVT fixes including fix for a CommetLake regression in mmio table
  and misc doc and typo fixes
- Fix CCS handling
- Fix for guc requests after reset
- Display DSI related fixes
- Display backlight related fixes
- Fix for a null pointer dereference
- HDMI related quirk for ECS Liva Q2 with GLK graphics
- Skip wm/ddb readout for disabled pipes

amdgpu:
- FRU error message fix
- MES 11 updates
- DCN 3.2.x fixes
- DCN 3.1.4 fixes
- Fix possible use after free in CS IOCTL
- SMU 13.0.x fixes
- Fix iolink reporting on devices with direct connections to CPU
- GFX10 tap delay firmware fixes

msm:
- Fix for inconsistent indenting in function msm_dsi_dphy_timing_calc_v3.
- Fix to make eDP the first connector in the connected list.
- Fix to populate intf_cfg correctly before calling reset_intf_cfg().
- Specify the correct number of DSI regulators for SDM660.
- Specify the correct number of DSI regulators for MSM8996.
- Fix for removing DP_RECOVERED_CLOCK_OUT_EN bit for tps4 link training
- Fix probe-deferral crash in gpu devfreq
- Fix gpu debugfs deadlock


Abhinav Kumar (1):
  drm/msm/dpu: populate wb or intf before reset_intf_cfg

Alex Sierra (1):
  drm/amdgpu: ensure no PCIe peer access for CPU XGMI iolinks

Alex Williamson (1):
  drm/i915/gvt: Fix Comet Lake

Arun R Murthy (2):
  drm/i915/display: avoid warnings when registering dual panel backlight
  drm/i915/display: avoid warnings when registering dual panel backlight

Aurabindo Pillai (4):
  drm/amd/display: Fix CAB cursor size allocation for DCN32/321
  drm/amd/display: disable display fresh from MALL on an edge case
for DCN321
  drm/amd/display: use actual cursor size instead of max for CAB allocation
  drm/amd/display: Use correct plane for CAB cursor size allocation

Bjorn Andersson (1):
  drm/msm/gpu: Drop qos request if devm_devfreq_add_device() fails

Charlene Liu (1):
  drm/amd/display: fix wrong register access

Chengming Gui (1):
  drm/amd/amdgpu: skip ucode loading if ucode_size == 0

Christian König (1):
  dma-buf/dma-resv: check if the new fence is really later

Colin Ian King (1):
  drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

Daniele Ceraolo Spurio (2):
  drm/i915/guc: clear stalled request after a reset
  drm/i915/guc: clear stalled request after a reset

Dave Airlie (5):
  Merge tag 'drm-intel-fixes-2022-08-26' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
  Merge tag 'drm-misc-fixes-2022-08-31' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge tag 'amd-drm-fixes-6.0-2022-08-31' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
  Merge tag 'drm-msm-fixes-2022-08-27' of
https://gitlab.freedesktop.org/drm/msm into drm-fixes
  Merge tag 'drm-intel-fixes-2022-09-01' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Diego Santa Cruz (1):
  drm/i915/glk: ECS Liva Q2 needs GLK HDMI port timing quirk

Douglas 

[PATCH v3] drm/ast: add dmabuf/prime buffer sharing support

2022-09-01 Thread oushixiong

This patch adds ast specific codes for DRM prime feature, this is to
allow for offloading of rending in one direction and outputs in other.

This patch is designed to solve the problem that the AST is not displayed
when the server plug in a discrete graphics card at the same time.
We call the dirty callback function to copy the rendering results of the
discrete graphics card to the ast side by dma-buf.

v1->v2:
  - Fix the comment.
v2->v3:
  - we remove the gem_prime_import_sg_table callback and use the
gem_prime_import callback, because it just map and access the buffer
with the CPU. and do not to pin the buffer.

Signed-off-by: oushixiong 
Acked-by: Christian König 
---
 drivers/gpu/drm/ast/ast_drv.c  |  27 +++
 drivers/gpu/drm/ast/ast_mode.c | 125 -
 2 files changed, 151 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 7465c4f0156a..fd3c4bad2eb4 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -28,6 +28,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -50,6 +51,29 @@ module_param_named(modeset, ast_modeset, int, 0400);
 
 DEFINE_DRM_GEM_FOPS(ast_fops);
 
+static struct drm_gem_object *ast_gem_prime_import(struct drm_device *dev,
+   struct dma_buf *dma_buf)
+{
+   struct drm_gem_vram_object *gbo;
+
+   gbo = drm_gem_vram_of_gem(dma_buf->priv);
+   if (gbo->bo.base.dev == dev) {
+   /*
+* Importing dmabuf exported from out own gem increases
+* refcount on gem itself instead of f_count of dmabuf.
+*/
+   drm_gem_object_get(>bo.base);
+   return >bo.base;
+   }
+
+   gbo = drm_gem_vram_create(dev, dma_buf->size, 0);
+   if (IS_ERR(gbo))
+   return NULL;
+
+   get_dma_buf(dma_buf);
+   return >bo.base;
+}
+
 static const struct drm_driver ast_driver = {
.driver_features = DRIVER_ATOMIC |
   DRIVER_GEM |
@@ -63,6 +87,9 @@ static const struct drm_driver ast_driver = {
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
 
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
+   .gem_prime_import = ast_gem_prime_import,
+
DRM_GEM_VRAM_DRIVER
 };
 
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 45b56b39ad47..65a4342c5622 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -48,6 +48,8 @@
 #include "ast_drv.h"
 #include "ast_tables.h"
 
+MODULE_IMPORT_NS(DMA_BUF);
+
 static inline void ast_load_palette_index(struct ast_private *ast,
 u8 index, u8 red, u8 green,
 u8 blue)
@@ -1535,8 +1537,129 @@ static const struct drm_mode_config_helper_funcs 
ast_mode_config_helper_funcs =
.atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
 };
 
+static int ast_handle_damage(struct drm_framebuffer *fb, int x, int y,
+   int width, int height)
+{
+   struct drm_gem_vram_object *dst_bo = NULL;
+   void *dst = NULL;
+   int ret = 0, i;
+   unsigned long offset = 0;
+   bool unmap = false;
+   unsigned int bytesPerPixel;
+   struct iosys_map map;
+   struct iosys_map dmabuf_map;
+
+   bytesPerPixel = fb->format->cpp[0];
+
+   if (!fb->obj[0]->dma_buf)
+   return -EINVAL;
+
+   if (!fb->obj[0]->dma_buf->vmap_ptr.vaddr) {
+   ret = dma_buf_vmap(fb->obj[0]->dma_buf, _map);
+   if (ret)
+   return ret;
+   } else
+   dmabuf_map.vaddr = fb->obj[0]->dma_buf->vmap_ptr.vaddr;
+
+   dst_bo = drm_gem_vram_of_gem(fb->obj[0]);
+
+   ret = drm_gem_vram_pin(dst_bo, 0);
+   if (ret) {
+   DRM_ERROR("ast_bo_pin failed\n");
+   return ret;
+   }
+
+   if (!dst_bo->map.vaddr) {
+   ret = drm_gem_vram_vmap(dst_bo, );
+   if (ret) {
+   drm_gem_vram_unpin(dst_bo);
+   DRM_ERROR("failed to vmap fbcon\n");
+   return ret;
+   }
+   unmap = true;
+   }
+   dst = dst_bo->map.vaddr;
+
+   for (i = y; i < y + height; i++) {
+   offset = i * fb->pitches[0] + (x * bytesPerPixel);
+   memcpy_toio(dst + offset, dmabuf_map.vaddr + offset,
+   width * bytesPerPixel);
+   }
+
+   if (unmap)
+   drm_gem_vram_vunmap(dst_bo, );
+
+   drm_gem_vram_unpin(dst_bo);
+
+   return 0;
+}
+
+
+static int ast_user_framebuffer_dirty(struct drm_framebuffer *fb,
+   struct drm_file *file,
+   unsigned int flags,
+   unsigned int color,
+   struct 

Re: [PATCH v1 4/4] drm/msm/mdp5: move resource allocation to the _probe function

2022-09-01 Thread Abhinav Kumar




On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:

To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback.


Seems to be the common typo in all the patches of this series

allocattion -> allocation

Apart from that, this one LGTM,

Reviewed-by: Abhinav Kumar 


Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 97 +++-
  1 file changed, 45 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index daf5b5ca7233..015388f262f4 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -556,17 +556,18 @@ static int mdp5_kms_init(struct drm_device *dev)
struct mdp5_cfg *config;
struct msm_kms *kms;
struct msm_gem_address_space *aspace;
-   int irq, i, ret;
+   int i, ret;
struct device *iommu_dev;
  
-	ret = mdp5_init(to_platform_device(dev->dev), dev);

-
/* priv->kms would have been populated by the MDP5 driver */
kms = priv->kms;
if (!kms)
return -ENOMEM;
  
  	mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));

+
+   ret = mdp5_init(to_platform_device(dev->dev), dev);
+
pdev = mdp5_kms->pdev;
  
  	ret = mdp_kms_init(_kms->base, _funcs);

@@ -575,15 +576,6 @@ static int mdp5_kms_init(struct drm_device *dev)
goto fail;
}
  
-	irq = irq_of_parse_and_map(pdev->dev.of_node, 0);

-   if (!irq) {
-   ret = -EINVAL;
-   DRM_DEV_ERROR(>dev, "failed to get irq\n");
-   goto fail;
-   }
-
-   kms->irq = irq;
-
config = mdp5_cfg_get_config(mdp5_kms->cfg);
  
  	/* make sure things are off before attaching iommu (bootloader could

@@ -804,51 +796,17 @@ static int interface_init(struct mdp5_kms *mdp5_kms)
  static int mdp5_init(struct platform_device *pdev, struct drm_device *dev)
  {
struct msm_drm_private *priv = dev->dev_private;
-   struct mdp5_kms *mdp5_kms;
+   struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(priv->kms));
struct mdp5_cfg *config;
u32 major, minor;
int ret;
  
-	mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);

-   if (!mdp5_kms) {
-   ret = -ENOMEM;
-   goto fail;
-   }
-
-   spin_lock_init(_kms->resource_lock);
-
mdp5_kms->dev = dev;
-   mdp5_kms->pdev = pdev;
  
  	ret = mdp5_global_obj_init(mdp5_kms);

if (ret)
goto fail;
  
-	mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys");

-   if (IS_ERR(mdp5_kms->mmio)) {
-   ret = PTR_ERR(mdp5_kms->mmio);
-   goto fail;
-   }
-
-   /* mandatory clocks: */
-   ret = get_clk(pdev, _kms->axi_clk, "bus", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, _kms->ahb_clk, "iface", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, _kms->core_clk, "core", true);
-   if (ret)
-   goto fail;
-   ret = get_clk(pdev, _kms->vsync_clk, "vsync", true);
-   if (ret)
-   goto fail;
-
-   /* optional clocks: */
-   get_clk(pdev, _kms->lut_clk, "lut", false);
-   get_clk(pdev, _kms->tbu_clk, "tbu", false);
-   get_clk(pdev, _kms->tbu_rt_clk, "tbu_rt", false);
-
/* we need to set a default rate before enabling.  Set a safe
 * rate first, then figure out hw revision, and then set a
 * more optimal rate:
@@ -906,9 +864,6 @@ static int mdp5_init(struct platform_device *pdev, struct 
drm_device *dev)
if (ret)
goto fail;
  
-	/* set uninit-ed kms */

-   priv->kms = _kms->base.base;
-
return 0;
  fail:
if (mdp5_kms)
@@ -951,15 +906,53 @@ static int mdp5_setup_interconnect(struct platform_device 
*pdev)
  
  static int mdp5_dev_probe(struct platform_device *pdev)

  {
-   int ret;
+   struct mdp5_kms *mdp5_kms;
+   int ret, irq;
  
  	DBG("");
  
+	mdp5_kms = devm_kzalloc(>dev, sizeof(*mdp5_kms), GFP_KERNEL);

+   if (!mdp5_kms)
+   return -ENOMEM;
+
ret = mdp5_setup_interconnect(pdev);
if (ret)
return ret;
  
-	return msm_drv_probe(>dev, mdp5_kms_init, NULL);

+   mdp5_kms->pdev = pdev;
+
+   spin_lock_init(_kms->resource_lock);
+
+   mdp5_kms->mmio = msm_ioremap(pdev, "mdp_phys");
+   if (IS_ERR(mdp5_kms->mmio))
+   return PTR_ERR(mdp5_kms->mmio);
+
+   /* mandatory clocks: */
+   ret = get_clk(pdev, _kms->axi_clk, "bus", true);
+   if (ret)
+   return ret;
+   ret = get_clk(pdev, _kms->ahb_clk, "iface", true);
+   if (ret)
+   return ret;
+   ret = get_clk(pdev, _kms->core_clk, "core", true);
+   if (ret)
+   return ret;
+   ret = get_clk(pdev, _kms->vsync_clk, "vsync", 

[PATCH 3/7] drm/i915/gt: Drop a few unused register definitions

2022-09-01 Thread Matt Roper
Let's drop a few register definitions that are unused anywhere in the
driver today.  Since the referenced offsets are part of what is now
considered a multicast register region, the current definitions would
not be correct for use on any future platform.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 17 -
 1 file changed, 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 6d4d15964b58..bf5f21d334f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -447,13 +447,6 @@
 #define   GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC   REG_BIT(11)
 #define   GEN12_DISABLE_CPS_AWARE_COLOR_PIPE   REG_BIT(9)
 
-/* GEN9 chicken */
-#define SLICE_ECO_CHICKEN0 _MMIO(0x7308)
-#define   PIXEL_MASK_CAMMING_DISABLE   (1 << 14)
-
-#define GEN9_SLICE_COMMON_ECO_CHICKEN0 _MMIO(0x7308)
-#define   DISABLE_PIXEL_MASK_CAMMING   (1 << 14)
-
 #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
 #define XEHP_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
 #define   MSC_MSAA_REODER_BUF_BYPASS_DISABLE   REG_BIT(14)
@@ -958,11 +951,6 @@
 #define GEN7_L3LOG(slice, i)   _MMIO(0xb070 + (slice) * 0x200 
+ (i) * 4)
 #define   GEN7_L3LOG_SIZE  0x80
 
-#define GEN10_SCRATCH_LNCF2_MMIO(0xb0a0)
-#define   PMFLUSHDONE_LNICRSDROP   (1 << 20)
-#define   PMFLUSH_GAPL3UNBLOCK (1 << 21)
-#define   PMFLUSHDONE_LNEBLK   (1 << 22)
-
 #define XEHP_L3NODEARBCFG  _MMIO(0xb0b4)
 #define   XEHP_LNESPAREREG_BIT(19)
 
@@ -977,9 +965,6 @@
 #define   L3_HIGH_PRIO_CREDITS(x)  (((x) >> 1) << 14)
 #define   L3_PRIO_CREDITS_MASK ((0x1f << 19) | (0x1f << 14))
 
-#define GEN10_L3_CHICKEN_MODE_REGISTER _MMIO(0xb114)
-#define   GEN11_I2M_WRITE_DISABLE  (1 << 28)
-
 #define GEN8_L3SQCREG4 _MMIO(0xb118)
 #define   GEN11_LQSC_CLEAN_EVICT_DISABLE   (1 << 6)
 #define   GEN8_LQSC_RO_PERF_DIS(1 << 27)
@@ -1174,8 +1159,6 @@
 #define SARB_CHICKEN1  _MMIO(0xe90c)
 #define   COMP_CKN_IN  REG_GENMASK(30, 29)
 
-#define GEN7_HALF_SLICE_CHICKEN1_GT2   _MMIO(0xf100)
-
 #define GEN7_ROW_CHICKEN2_GT2  _MMIO(0xf4f4)
 #define   DOP_CLOCK_GATING_DISABLE (1 << 0)
 #define   PUSH_CONSTANT_DEREF_DISABLE  (1 << 8)
-- 
2.37.2



[PATCH 5/7] drm/i915: Define MCR registers explicitly

2022-09-01 Thread Matt Roper
Rather than using the same _MMIO() macro to define MCR registers as
singleton registers, let's use a new MCR_REG() macro to make it clear
that these registers are special and should be handled accordingly.  For
now MCR_REG() will still generate an i915_reg_t with the given offset,
but we'll change that in future patches.

Bspec: 66673, 66696, 66534, 67609
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 118 
 1 file changed, 60 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 94a1f964eaba..736fc01fa74f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -8,6 +8,8 @@
 
 #include "i915_reg_defs.h"
 
+#define MCR_REG(offset)_MMIO(offset)
+
 /* RPM unit config (Gen8+) */
 #define RPM_CONFIG0_MMIO(0xd00)
 #define   GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT3
@@ -326,12 +328,12 @@
 #define GEN7_TLB_RD_ADDR   _MMIO(0x4700)
 
 #define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
-#define XEHP_PAT_INDEX(index)  _MMIO(0x4800 + (index) * 4)
+#define XEHP_PAT_INDEX(index)  MCR_REG(0x4800 + (index) * 4)
 
-#define XEHP_TILE0_ADDR_RANGE  _MMIO(0x4900)
+#define XEHP_TILE0_ADDR_RANGE  MCR_REG(0x4900)
 #define   XEHP_TILE_LMEM_RANGE_SHIFT   8
 
-#define XEHP_FLAT_CCS_BASE_ADDR_MMIO(0x4910)
+#define XEHP_FLAT_CCS_BASE_ADDRMCR_REG(0x4910)
 #define   XEHP_CCS_BASE_SHIFT  8
 
 #define GAMTARBMODE_MMIO(0x4a08)
@@ -381,18 +383,18 @@
 #define CHICKEN_RASTER_2   _MMIO(0x6208)
 #define   TBIMR_FAST_CLIP  REG_BIT(5)
 
-#define VFLSKPD_MMIO(0x62a8)
+#define VFLSKPDMCR_REG(0x62a8)
 #define   DIS_OVER_FETCH_CACHE REG_BIT(1)
 #define   DIS_MULT_MISS_RD_SQUASH  REG_BIT(0)
 
 #define GEN12_FF_MODE2 _MMIO(0x6604)
-#define XEHP_FF_MODE2  _MMIO(0x6604)
+#define XEHP_FF_MODE2  MCR_REG(0x6604)
 #define   FF_MODE2_GS_TIMER_MASK   REG_GENMASK(31, 24)
 #define   FF_MODE2_GS_TIMER_224
REG_FIELD_PREP(FF_MODE2_GS_TIMER_MASK, 224)
 #define   FF_MODE2_TDS_TIMER_MASK  REG_GENMASK(23, 16)
 #define   FF_MODE2_TDS_TIMER_128   
REG_FIELD_PREP(FF_MODE2_TDS_TIMER_MASK, 4)
 
-#define XEHPG_INSTDONE_GEOM_SVG_MMIO(0x666c)
+#define XEHPG_INSTDONE_GEOM_SVGMCR_REG(0x666c)
 
 #define CACHE_MODE_0_GEN7  _MMIO(0x7000) /* IVB+ */
 #define   RC_OP_FLUSH_ENABLE   (1 << 0)
@@ -441,14 +443,14 @@
 #define GEN8_HDC_CHICKEN1  _MMIO(0x7304)
 
 #define GEN11_COMMON_SLICE_CHICKEN3_MMIO(0x7304)
-#define XEHP_COMMON_SLICE_CHICKEN3 _MMIO(0x7304)
+#define XEHP_COMMON_SLICE_CHICKEN3 MCR_REG(0x7304)
 #define   DG1_FLOAT_POINT_BLEND_OPT_STRICT_MODE_EN REG_BIT(12)
 #define   XEHP_DUAL_SIMD8_SEQ_MERGE_DISABLEREG_BIT(12)
 #define   GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC   REG_BIT(11)
 #define   GEN12_DISABLE_CPS_AWARE_COLOR_PIPE   REG_BIT(9)
 
 #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
-#define XEHP_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
+#define XEHP_SLICE_COMMON_ECO_CHICKEN1 MCR_REG(0x731c)
 #define   MSC_MSAA_REODER_BUF_BYPASS_DISABLE   REG_BIT(14)
 #define   GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
 
@@ -479,7 +481,7 @@
 
 #define GEN8_RC6_CTX_INFO  _MMIO(0x8504)
 
-#define XEHP_SQCM  _MMIO(0x8724)
+#define XEHP_SQCM  MCR_REG(0x8724)
 #define   EN_32B_ACCESSREG_BIT(30)
 
 #define HSW_IDICR  _MMIO(0x9008)
@@ -640,7 +642,7 @@
 #define GEN7_MISCCPCTL _MMIO(0x9424)
 #define   GEN7_DOP_CLOCK_GATE_ENABLE   (1 << 0)
 
-#define GEN8_MISCCPCTL _MMIO(0x9424)
+#define GEN8_MISCCPCTL MCR_REG(0x9424)
 #define   GEN8_DOP_CLOCK_GATE_ENABLE   REG_BIT(0)
 #define   GEN12_DOP_CLOCK_GATE_RENDER_ENABLE   REG_BIT(1)
 #define   GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2)
@@ -696,7 +698,7 @@
 #define   LTCDD_CLKGATE_DISREG_BIT(10)
 
 #define GEN11_SLICE_UNIT_LEVEL_CLKGATE _MMIO(0x94d4)
-#define XEHP_SLICE_UNIT_LEVEL_CLKGATE  _MMIO(0x94d4)
+#define XEHP_SLICE_UNIT_LEVEL_CLKGATE  MCR_REG(0x94d4)
 #define   SARBUNIT_CLKGATE_DIS (1 << 5)
 #define   RCCUNIT_CLKGATE_DIS  (1 << 7)
 #define   MSCUNIT_CLKGATE_DIS  (1 << 10)

[PATCH 4/7] drm/i915/gt: Correct prefix on a few registers

2022-09-01 Thread Matt Roper
We have a few registers that have existed for several hardware
generations, but are only used by the driver on Xe_HP and beyond.  In
cases where the Xe_HP version of the register is now replicated and uses
multicast behavior, but earlier generations were singleton, let's change
the register prefix to "XEHP_" to help clarify that we're using the
newer multicast form of the register.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  8 
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index bf5f21d334f3..94a1f964eaba 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -479,7 +479,7 @@
 
 #define GEN8_RC6_CTX_INFO  _MMIO(0x8504)
 
-#define GEN12_SQCM _MMIO(0x8724)
+#define XEHP_SQCM  _MMIO(0x8724)
 #define   EN_32B_ACCESSREG_BIT(30)
 
 #define HSW_IDICR  _MMIO(0x9008)
@@ -980,7 +980,7 @@
 #define GEN11_SCRATCH2 _MMIO(0xb140)
 #define   GEN11_COHERENT_PARTIAL_WRITE_MERGE_ENABLE(1 << 19)
 
-#define GEN11_L3SQCREG5_MMIO(0xb158)
+#define XEHP_L3SQCREG5 _MMIO(0xb158)
 #define   L3_PWM_TIMER_INIT_VAL_MASK   REG_GENMASK(9, 0)
 
 #define MLTICTXCTL _MMIO(0xb170)
@@ -1036,7 +1036,7 @@
 #define GEN12_BLT_TLB_INV_CR   _MMIO(0xcee4)
 #define GEN12_COMPCTX_TLB_INV_CR   _MMIO(0xcf04)
 
-#define GEN12_MERT_MOD_CTRL_MMIO(0xcf28)
+#define XEHP_MERT_MOD_CTRL _MMIO(0xcf28)
 #define RENDER_MOD_CTRL_MMIO(0xcf2c)
 #define COMP_MOD_CTRL  _MMIO(0xcf30)
 #define VDBX_MOD_CTRL  _MMIO(0xcf34)
@@ -1138,7 +1138,7 @@
 #define EU_PERF_CNTL1  _MMIO(0xe558)
 #define EU_PERF_CNTL5  _MMIO(0xe55c)
 
-#define GEN12_HDC_CHICKEN0 _MMIO(0xe5f0)
+#define XEHP_HDC_CHICKEN0  _MMIO(0xe5f0)
 #define   LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK   REG_GENMASK(13, 
11)
 #define ICL_HDC_MODE   _MMIO(0xe5f4)
 
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index eff5f4f85374..3d48189021ad 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -569,7 +569,7 @@ static void dg2_ctx_gt_tuning_init(struct intel_engine_cs 
*engine,
   struct i915_wa_list *wal)
 {
wa_masked_en(wal, CHICKEN_RASTER_2, TBIMR_FAST_CLIP);
-   wa_write_clr_set(wal, GEN11_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
+   wa_write_clr_set(wal, XEHP_L3SQCREG5, L3_PWM_TIMER_INIT_VAL_MASK,
 REG_FIELD_PREP(L3_PWM_TIMER_INIT_VAL_MASK, 0x7f));
wa_add(wal,
   XEHP_FF_MODE2,
@@ -1504,7 +1504,7 @@ dg2_gt_workarounds_init(struct intel_gt *gt, struct 
i915_wa_list *wal)
 * recommended tuning settings documented in the bspec's
 * performance guide section.
 */
-   wa_write_or(wal, GEN12_SQCM, EN_32B_ACCESS);
+   wa_write_or(wal, XEHP_SQCM, EN_32B_ACCESS);
 
/* Wa_14015795083 */
wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE);
@@ -2163,7 +2163,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
 * Wa_22010960976:dg2
 * Wa_14013347512:dg2
 */
-   wa_masked_dis(wal, GEN12_HDC_CHICKEN0,
+   wa_masked_dis(wal, XEHP_HDC_CHICKEN0,
  LSC_L1_FLUSH_CTL_3D_DATAPORT_FLUSH_EVENTS_MASK);
}
 
@@ -2216,7 +2216,7 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct 
i915_wa_list *wal)
if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_A0, STEP_B0) ||
IS_DG2_GRAPHICS_STEP(engine->i915, G11, STEP_A0, STEP_B0)) {
/* Wa_14012362059:dg2 */
-   wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
+   wa_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
}
 
if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_B0, STEP_FOREVER) ||
@@ -2757,7 +2757,7 @@ general_render_compute_wa_init(struct intel_engine_cs 
*engine, struct i915_wa_li
}
 
/* Wa_14012362059:xehpsdv */
-   wa_write_or(wal, GEN12_MERT_MOD_CTRL, FORCE_MISS_FTLB);
+   wa_write_or(wal, XEHP_MERT_MOD_CTRL, FORCE_MISS_FTLB);
 
/* Wa_14014368820:xehpsdv */
wa_write_or(wal, GEN12_GAMCNTRL_CTRL, 
INVALIDATION_BROADCAST_MODE_DIS |
-- 
2.37.2



[PATCH 6/7] drm/i915/gt: Always use MCR functions on multicast registers

2022-09-01 Thread Matt Roper
Rather than relying on the implicit behavior of intel_uncore_*()
functions, let's always use the intel_gt_mcr_*() functions to operate on
multicast/replicated registers.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  4 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   | 49 ---
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  2 +-
 drivers/gpu/drm/i915/gt/intel_mocs.c  | 13 +++---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 12 --
 drivers/gpu/drm/i915/intel_pm.c   | 20 +
 6 files changed, 55 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 30cf5c3369d9..e2620f41d8b2 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -986,7 +986,7 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 
ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
 
-   setup_private_pat(ggtt->vm.gt->uncore);
+   setup_private_pat(ggtt->vm.gt);
 
return ggtt_probe_common(ggtt, size);
 }
@@ -1302,7 +1302,7 @@ void i915_ggtt_resume(struct i915_ggtt *ggtt)
wbinvd_on_all_cpus();
 
if (GRAPHICS_VER(ggtt->vm.i915) >= 8)
-   setup_private_pat(ggtt->vm.gt->uncore);
+   setup_private_pat(ggtt->vm.gt);
 
intel_ggtt_restore_fences(ggtt);
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 601d89b4feb1..6f61c8da0b61 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -15,6 +15,7 @@
 #include "i915_trace.h"
 #include "i915_utils.h"
 #include "intel_gt.h"
+#include "intel_gt_mcr.h"
 #include "intel_gt_regs.h"
 #include "intel_gtt.h"
 
@@ -477,27 +478,27 @@ void gtt_write_workarounds(struct intel_gt *gt)
}
 }
 
-static void tgl_setup_private_ppat(struct intel_uncore *uncore)
+static void tgl_setup_private_ppat(struct intel_gt *gt)
 {
-   if (GRAPHICS_VER_FULL(uncore->i915) >= IP_VER(12, 50)) {
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(0), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(1), GEN8_PPAT_WC);
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(2), GEN8_PPAT_WT);
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(3), GEN8_PPAT_UC);
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(4), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(5), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(6), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, XEHP_PAT_INDEX(7), GEN8_PPAT_WB);
+   if (GRAPHICS_VER_FULL(gt->i915) >= IP_VER(12, 50)) {
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(0), 
GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(1), 
GEN8_PPAT_WC);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(2), 
GEN8_PPAT_WT);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(3), 
GEN8_PPAT_UC);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(4), 
GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(5), 
GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(6), 
GEN8_PPAT_WB);
+   intel_gt_mcr_multicast_write(gt, XEHP_PAT_INDEX(7), 
GEN8_PPAT_WB);
} else {
/* TGL doesn't support LLC or AGE settings */
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(0), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(1), GEN8_PPAT_WC);
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(2), GEN8_PPAT_WT);
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(3), GEN8_PPAT_UC);
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(4), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(5), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(6), GEN8_PPAT_WB);
-   intel_uncore_write(uncore, GEN12_PAT_INDEX(7), GEN8_PPAT_WB);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(0), 
GEN8_PPAT_WB);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(1), 
GEN8_PPAT_WC);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(2), 
GEN8_PPAT_WT);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(3), 
GEN8_PPAT_UC);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(4), 
GEN8_PPAT_WB);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(5), 
GEN8_PPAT_WB);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(6), 
GEN8_PPAT_WB);
+   intel_uncore_write(gt->uncore, GEN12_PAT_INDEX(7), 
GEN8_PPAT_WB);
}
 }
 
@@ -593,20 +594,20 @@ static void chv_setup_private_ppat(struct intel_uncore 
*uncore)
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_HI, upper_32_bits(pat));
 }
 
-void setup_private_pat(struct intel_uncore *uncore)

[PATCH 7/7] drm/i915/gt: Add MCR-specific workaround initializers

2022-09-01 Thread Matt Roper
Let's be more explicit about which of our workarounds are updating MCR
registers.  This will also allow us to record whether a workaround
register has MCR behavior or not so that we'll only need to do a
steering lookup for the registers that truly need it.

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 414 +++---
 .../gpu/drm/i915/gt/intel_workarounds_types.h |   4 +-
 2 files changed, 252 insertions(+), 166 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 3d48189021ad..c13abac19b06 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -166,12 +166,33 @@ static void wa_add(struct i915_wa_list *wal, i915_reg_t 
reg,
_wa_add(wal, );
 }
 
+static void wa_mcr_add(struct i915_wa_list *wal, i915_reg_t reg,
+  u32 clear, u32 set, u32 read_mask, bool masked_reg)
+{
+   struct i915_wa wa = {
+   .reg  = reg,
+   .clr  = clear,
+   .set  = set,
+   .read = read_mask,
+   .masked_reg = masked_reg,
+   .is_mcr = 1,
+   };
+
+   _wa_add(wal, );
+}
+
 static void
 wa_write_clr_set(struct i915_wa_list *wal, i915_reg_t reg, u32 clear, u32 set)
 {
wa_add(wal, reg, clear, set, clear, false);
 }
 
+static void
+wa_mcr_write_clr_set(struct i915_wa_list *wal, i915_reg_t reg, u32 clear, u32 
set)
+{
+   wa_mcr_add(wal, reg, clear, set, clear, false);
+}
+
 static void
 wa_write(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
 {
@@ -184,12 +205,24 @@ wa_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 
set)
wa_write_clr_set(wal, reg, set, set);
 }
 
+static void
+wa_mcr_write_or(struct i915_wa_list *wal, i915_reg_t reg, u32 set)
+{
+   wa_mcr_write_clr_set(wal, reg, set, set);
+}
+
 static void
 wa_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
 {
wa_write_clr_set(wal, reg, clr, 0);
 }
 
+static void
+wa_mcr_write_clr(struct i915_wa_list *wal, i915_reg_t reg, u32 clr)
+{
+   wa_mcr_write_clr_set(wal, reg, clr, 0);
+}
+
 /*
  * WA operations on "masked register". A masked register has the upper 16 bits
  * documented as "masked" in b-spec. Its purpose is to allow writing to just a
@@ -207,12 +240,24 @@ wa_masked_en(struct i915_wa_list *wal, i915_reg_t reg, 
u32 val)
wa_add(wal, reg, 0, _MASKED_BIT_ENABLE(val), val, true);
 }
 
+static void
+wa_mcr_masked_en(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
+{
+   wa_mcr_add(wal, reg, 0, _MASKED_BIT_ENABLE(val), val, true);
+}
+
 static void
 wa_masked_dis(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
 {
wa_add(wal, reg, 0, _MASKED_BIT_DISABLE(val), val, true);
 }
 
+static void
+wa_mcr_masked_dis(struct i915_wa_list *wal, i915_reg_t reg, u32 val)
+{
+   wa_mcr_add(wal, reg, 0, _MASKED_BIT_DISABLE(val), val, true);
+}
+
 static void
 wa_masked_field_set(struct i915_wa_list *wal, i915_reg_t reg,
u32 mask, u32 val)
@@ -220,6 +265,13 @@ wa_masked_field_set(struct i915_wa_list *wal, i915_reg_t 
reg,
wa_add(wal, reg, 0, _MASKED_FIELD(mask, val), mask, true);
 }
 
+static void
+wa_mcr_masked_field_set(struct i915_wa_list *wal, i915_reg_t reg,
+   u32 mask, u32 val)
+{
+   wa_mcr_add(wal, reg, 0, _MASKED_FIELD(mask, val), mask, true);
+}
+
 static void gen6_ctx_workarounds_init(struct intel_engine_cs *engine,
  struct i915_wa_list *wal)
 {
@@ -241,7 +293,7 @@ static void gen8_ctx_workarounds_init(struct 
intel_engine_cs *engine,
wa_masked_en(wal, RING_MI_MODE(RENDER_RING_BASE), 
ASYNC_FLIP_PERF_DISABLE);
 
/* WaDisablePartialInstShootdown:bdw,chv */
-   wa_masked_en(wal, GEN8_ROW_CHICKEN,
+   wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN,
 PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE);
 
/* Use Force Non-Coherent whenever executing a 3D context. This is a
@@ -288,18 +340,18 @@ static void bdw_ctx_workarounds_init(struct 
intel_engine_cs *engine,
gen8_ctx_workarounds_init(engine, wal);
 
/* WaDisableThreadStallDopClockGating:bdw (pre-production) */
-   wa_masked_en(wal, GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
+   wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN, STALL_DOP_GATING_DISABLE);
 
/* WaDisableDopClockGating:bdw
 *
 * Also see the related UCGTCL1 write in bdw_init_clock_gating()
 * to disable EUTC clock gating.
 */
-   wa_masked_en(wal, GEN8_ROW_CHICKEN2,
-DOP_CLOCK_GATING_DISABLE);
+   wa_mcr_masked_en(wal, GEN8_ROW_CHICKEN2,
+DOP_CLOCK_GATING_DISABLE);
 
-   wa_masked_en(wal, GEN8_HALF_SLICE_CHICKEN3,
-GEN8_SAMPLER_POWER_BYPASS_DIS);
+   wa_mcr_masked_en(wal, GEN8_HALF_SLICE_CHICKEN3,
+GEN8_SAMPLER_POWER_BYPASS_DIS);
 

[PATCH 2/7] drm/i915/xehp: Create separate reg definitions for new MCR registers

2022-09-01 Thread Matt Roper
Starting in Xe_HP, several registers our driver works with have been
converted from singleton registers into replicated registers with
multicast behavior.  Although the registers are still located at the
same MMIO offsets as on previous platforms, let's duplicate the register
definitions in preparation for upcoming patches that will handle
multicast registers in a special manner.

The registers that are now replicated on Xe_HP are:
 * PAT_INDEX (mslice replication)
 * FF_MODE2 (gslice replication)
 * COMMON_SLICE_CHICKEN3 (gslice replication)
 * SLICE_COMMON_ECO_CHICKEN1 (gslice replication)
 * SLICE_UNIT_LEVEL_CLKGATE (gslice replication)
 * LNCFCMOCS (lncf replication)

The *_TLB_INV_CR registers are also replicated (mslice replication), but
I'm skipping those for now because I think that code might need more
work in general for multicast behavior (e.g., do we need to wait for
the invalidation to report as completed on every mslice?).

Bspec: 66534
Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_gt_regs.h | 18 -
 drivers/gpu/drm/i915/gt/intel_gtt.c | 29 ++---
 drivers/gpu/drm/i915/gt/intel_mocs.c|  5 +++-
 drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c  |  7 +++--
 5 files changed, 52 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index ad8e2b52ff64..6d4d15964b58 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -326,6 +326,7 @@
 #define GEN7_TLB_RD_ADDR   _MMIO(0x4700)
 
 #define GEN12_PAT_INDEX(index) _MMIO(0x4800 + (index) * 4)
+#define XEHP_PAT_INDEX(index)  _MMIO(0x4800 + (index) * 4)
 
 #define XEHP_TILE0_ADDR_RANGE  _MMIO(0x4900)
 #define   XEHP_TILE_LMEM_RANGE_SHIFT   8
@@ -384,7 +385,8 @@
 #define   DIS_OVER_FETCH_CACHE REG_BIT(1)
 #define   DIS_MULT_MISS_RD_SQUASH  REG_BIT(0)
 
-#define FF_MODE2   _MMIO(0x6604)
+#define GEN12_FF_MODE2 _MMIO(0x6604)
+#define XEHP_FF_MODE2  _MMIO(0x6604)
 #define   FF_MODE2_GS_TIMER_MASK   REG_GENMASK(31, 24)
 #define   FF_MODE2_GS_TIMER_224
REG_FIELD_PREP(FF_MODE2_GS_TIMER_MASK, 224)
 #define   FF_MODE2_TDS_TIMER_MASK  REG_GENMASK(23, 16)
@@ -439,6 +441,7 @@
 #define GEN8_HDC_CHICKEN1  _MMIO(0x7304)
 
 #define GEN11_COMMON_SLICE_CHICKEN3_MMIO(0x7304)
+#define XEHP_COMMON_SLICE_CHICKEN3 _MMIO(0x7304)
 #define   DG1_FLOAT_POINT_BLEND_OPT_STRICT_MODE_EN REG_BIT(12)
 #define   XEHP_DUAL_SIMD8_SEQ_MERGE_DISABLEREG_BIT(12)
 #define   GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC   REG_BIT(11)
@@ -452,10 +455,9 @@
 #define   DISABLE_PIXEL_MASK_CAMMING   (1 << 14)
 
 #define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
-#define   GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
-
-#define SLICE_COMMON_ECO_CHICKEN1  _MMIO(0x731c)
+#define XEHP_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
 #define   MSC_MSAA_REODER_BUF_BYPASS_DISABLE   REG_BIT(14)
+#define   GEN11_STATE_CACHE_REDIRECT_TO_CS (1 << 11)
 
 #define GEN9_SLICE_PGCTL_ACK(slice)_MMIO(0x804c + (slice) * 0x4)
 #define GEN10_SLICE_PGCTL_ACK(slice)   _MMIO(0x804c + ((slice) / 3) * 
0x34 + \
@@ -700,7 +702,8 @@
 #define   GAMTLBVEBOX0_CLKGATE_DIS REG_BIT(16)
 #define   LTCDD_CLKGATE_DISREG_BIT(10)
 
-#define SLICE_UNIT_LEVEL_CLKGATE   _MMIO(0x94d4)
+#define GEN11_SLICE_UNIT_LEVEL_CLKGATE _MMIO(0x94d4)
+#define XEHP_SLICE_UNIT_LEVEL_CLKGATE  _MMIO(0x94d4)
 #define   SARBUNIT_CLKGATE_DIS (1 << 5)
 #define   RCCUNIT_CLKGATE_DIS  (1 << 7)
 #define   MSCUNIT_CLKGATE_DIS  (1 << 10)
@@ -715,7 +718,7 @@
 #define   VSUNIT_CLKGATE_DIS_TGL   REG_BIT(19)
 #define   PSDUNIT_CLKGATE_DIS  REG_BIT(5)
 
-#define SUBSLICE_UNIT_LEVEL_CLKGATE_MMIO(0x9524)
+#define GEN11_SUBSLICE_UNIT_LEVEL_CLKGATE  _MMIO(0x9524)
 #define   DSS_ROUTER_CLKGATE_DIS   REG_BIT(28)
 #define   GWUNIT_CLKGATE_DIS   REG_BIT(16)
 
@@ -938,7 +941,8 @@
 
 /* MOCS (Memory Object Control State) registers */
 #define GEN9_LNCFCMOCS(i)  _MMIO(0xb020 + (i) * 4) /* L3 
Cache Control */
-#define GEN9_LNCFCMOCS_REG_COUNT   32
+#define XEHP_LNCFCMOCS(i)  _MMIO(0xb020 + (i) * 4) /* L3 
Cache Control */
+#define LNCFCMOCS_REG_COUNT32
 
 #define GEN7_L3CNTLREG3_MMIO(0xb024)
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c 
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index b67831833c9a..601d89b4feb1 100644
--- 

[PATCH 1/7] drm/i915/gen8: Create separate reg definitions for new MCR registers

2022-09-01 Thread Matt Roper
Gen8 was the first time our hardware had multicast registers (or at
least the first time the multicast nature was exposed and MMIO accesses
could be steered).  There are some registers that transitioned from
singleton behavior to multicast during the gen7 -> gen8 transition;
let's duplicate the register definitions for those registers in
preparation for upcoming patches that will handle MCR registers in a
special manner.

The registers adjusted are:
 * MISCCPCTL
 * SAMPLER_INSTDONE
 * ROW_INSTDONE
 * ROW_CHICKEN2
 * HALF_SLICE_CHICKEN1
 * HALF_SLICE_CHICKEN3

Signed-off-by: Matt Roper 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |  4 ++--
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 11 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 22 +--
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c|  4 ++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c   |  2 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c   |  2 +-
 drivers/gpu/drm/i915/intel_gvt_mmio_table.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c   | 10 -
 9 files changed, 34 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 275ad72940c1..29980bff9c10 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1544,11 +1544,11 @@ void intel_engine_get_instdone(const struct 
intel_engine_cs *engine,
for_each_ss_steering(iter, engine->gt, slice, subslice) {
instdone->sampler[slice][subslice] =
intel_gt_mcr_read(engine->gt,
- GEN7_SAMPLER_INSTDONE,
+ GEN8_SAMPLER_INSTDONE,
  slice, subslice);
instdone->row[slice][subslice] =
intel_gt_mcr_read(engine->gt,
- GEN7_ROW_INSTDONE,
+ GEN8_ROW_INSTDONE,
  slice, subslice);
}
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index d414785003cc..ad8e2b52ff64 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -644,6 +644,9 @@
 
 #define GEN7_MISCCPCTL _MMIO(0x9424)
 #define   GEN7_DOP_CLOCK_GATE_ENABLE   (1 << 0)
+
+#define GEN8_MISCCPCTL _MMIO(0x9424)
+#define   GEN8_DOP_CLOCK_GATE_ENABLE   REG_BIT(0)
 #define   GEN12_DOP_CLOCK_GATE_RENDER_ENABLE   REG_BIT(1)
 #define   GEN8_DOP_CLOCK_GATE_CFCLK_ENABLE (1 << 2)
 #define   GEN8_DOP_CLOCK_GATE_GUC_ENABLE   (1 << 4)
@@ -1063,18 +1066,22 @@
 #define GEN12_GAM_DONE _MMIO(0xcf68)
 
 #define GEN7_HALF_SLICE_CHICKEN1   _MMIO(0xe100) /* IVB GT1 + VLV 
*/
+#define GEN8_HALF_SLICE_CHICKEN1   _MMIO(0xe100)
 #define   GEN7_MAX_PS_THREAD_DEP   (8 << 12)
 #define   GEN7_SINGLE_SUBSCAN_DISPATCH_ENABLE  (1 << 10)
 #define   GEN7_SBE_SS_CACHE_DISPATCH_PORT_SHARING_DISABLE  (1 << 4)
 #define   GEN7_PSD_SINGLE_PORT_DISPATCH_ENABLE (1 << 3)
 
 #define GEN7_SAMPLER_INSTDONE  _MMIO(0xe160)
+#define GEN8_SAMPLER_INSTDONE  _MMIO(0xe160)
 #define GEN7_ROW_INSTDONE  _MMIO(0xe164)
+#define GEN8_ROW_INSTDONE  _MMIO(0xe164)
 
 #define HALF_SLICE_CHICKEN2_MMIO(0xe180)
 #define   GEN8_ST_PO_DISABLE   (1 << 13)
 
-#define HALF_SLICE_CHICKEN3_MMIO(0xe184)
+#define HSW_HALF_SLICE_CHICKEN3_MMIO(0xe184)
+#define GEN8_HALF_SLICE_CHICKEN3   _MMIO(0xe184)
 #define   HSW_SAMPLE_C_PERFORMANCE (1 << 9)
 #define   GEN8_CENTROID_PIXEL_OPT_DIS  (1 << 8)
 #define   GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC  (1 << 5)
@@ -1127,6 +1134,8 @@
 #define   DISABLE_EARLY_EOTREG_BIT(1)
 
 #define GEN7_ROW_CHICKEN2  _MMIO(0xe4f4)
+
+#define GEN8_ROW_CHICKEN2  _MMIO(0xe4f4)
 #define   GEN12_DISABLE_READ_SUPPRESSION   REG_BIT(15)
 #define   GEN12_DISABLE_EARLY_READ REG_BIT(14)
 #define   GEN12_ENABLE_LARGE_GRF_MODE  REG_BIT(12)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c 
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 6d2003d598e6..e382cb4c6971 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -295,10 +295,10 @@ static void bdw_ctx_workarounds_init(struct 
intel_engine_cs *engine,
 * Also see the related UCGTCL1 write in bdw_init_clock_gating()
 * to disable EUTC clock gating.
 

[PATCH 0/7] i915: Prep work for explicit MCR handling

2022-09-01 Thread Matt Roper
Steering of multicast/replicated registers becomes a bit more
complicated on Meteor Lake.  Whereas previously the control register we
used to manage the steering was only used by our driver[*], software's
control of steering has now been consolidated with the controls for
various other hardware/firmware agents into a single register.  We can
no longer utilize pre-programmed implicit steering since other firmware
agents may change the steering target and not restore it afterward;
we'll need to explicitly steer all types of MCR registers (including the
GSLICE/COMPUTE/DSS ranges that have been handled implicitly in the
past).  Furthermore, since multiple agents will now be sharing a single
steering control register, races are possible.  To address this, the
hardware adds a new MCR semaphore register which is supposed to be used
to temporarily lock the steering while performing MCR operations.

It's going to become important for us to handle accesses of multicast
registers very explicitly going forward.  This series provides some prep
work for that by updating our register definitions to clearly define
registers as either MCR or non-MCR and ensure that we're using the
intel_gt_mcr_*() functions rather than intel_uncore_*() when operating
on MCR registers.  In a future series we plan to change the MCR_REG()
register definitions to actually declare MCR registers as a new C type
(i.e., not an i915_reg_t) so that the compiler will be able to help us
find any mistakes where non-MCR functions are used on MCR registers and
vice-versa.  Introduction of the MTL steering tables and introduction of
the steering semaphore support will also arrive in future patch series.


[*] This is a bit of an oversimplification; there are some hardware and
software debug tools that use the same MCR_SELECTOR register that i915
does and which could potentially re-steer MCR accesses behind our back.
E.g., simply using IGT's "intel_reg" tool to write the MCR_SELECTOR
register at the wrong time could interfere with driver operation.  But
given that these debug facilities require root privileges to run and are
only used by people intentionally debugging the driver or hardware, we
can ignore such races for real-world usage.


Matt Roper (7):
  drm/i915/gen8: Create separate reg definitions for new MCR registers
  drm/i915/xehp: Create separate reg definitions for new MCR registers
  drm/i915/gt: Drop a few unused register definitions
  drm/i915/gt: Correct prefix on a few registers
  drm/i915: Define MCR registers explicitly
  drm/i915/gt: Always use MCR functions on multicast registers
  drm/i915/gt: Add MCR-specific workaround initializers

 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   | 138 +++---
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  44 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   2 +-
 drivers/gpu/drm/i915/gt/intel_mocs.c  |  12 +-
 drivers/gpu/drm/i915/gt/intel_workarounds.c   | 426 +++---
 .../gpu/drm/i915/gt/intel_workarounds_types.h |   4 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|   7 +-
 .../gpu/drm/i915/gt/uc/intel_guc_capture.c|   4 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |  12 +-
 drivers/gpu/drm/i915/gvt/handlers.c   |   2 +-
 drivers/gpu/drm/i915/gvt/mmio_context.c   |   2 +-
 drivers/gpu/drm/i915/intel_gvt_mmio_table.c   |   2 +-
 drivers/gpu/drm/i915/intel_pm.c   |  20 +-
 15 files changed, 397 insertions(+), 286 deletions(-)

-- 
2.37.2



Re: [PATCH v1 3/4] drm/msm/mdp4: move resource allocation to the _probe function

2022-09-01 Thread Abhinav Kumar




On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:

To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the
probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().

Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 107 +++
  1 file changed, 51 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 41dc60784847..6499713eccf6 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -139,8 +139,6 @@ static void mdp4_destroy(struct msm_kms *kms)
pm_runtime_disable(dev);
  
  	mdp_kms_destroy(_kms->base);

-
-   kfree(mdp4_kms);
  }
  
  static const struct mdp_kms_funcs kms_funcs = {

@@ -383,57 +381,27 @@ static int mdp4_kms_init(struct drm_device *dev)
  {
struct platform_device *pdev = to_platform_device(dev->dev);
struct msm_drm_private *priv = dev->dev_private;
-   struct mdp4_kms *mdp4_kms;
+   struct mdp4_kms *mdp4_kms = to_mdp4_kms(to_mdp_kms(priv->kms));
struct msm_kms *kms = NULL;
struct iommu_domain *iommu;
struct msm_gem_address_space *aspace;
-   int irq, ret;
+   int ret;
u32 major, minor;
unsigned long max_clk;
  
  	/* TODO: Chips that aren't apq8064 have a 200 Mhz max_clk */

max_clk = 27000;
  
-	mdp4_kms = kzalloc(sizeof(*mdp4_kms), GFP_KERNEL);

-   if (!mdp4_kms) {
-   DRM_DEV_ERROR(dev->dev, "failed to allocate kms\n");
-   return -ENOMEM;
-   }
-
ret = mdp_kms_init(_kms->base, _funcs);
if (ret) {
DRM_DEV_ERROR(dev->dev, "failed to init kms\n");
goto fail;
}
  
-	priv->kms = _kms->base.base;

kms = priv->kms;
  
  	mdp4_kms->dev = dev;
  
-	mdp4_kms->mmio = msm_ioremap(pdev, NULL);

-   if (IS_ERR(mdp4_kms->mmio)) {
-   ret = PTR_ERR(mdp4_kms->mmio);
-   goto fail;
-   }
-
-   irq = platform_get_irq(pdev, 0);
-   if (irq < 0) {
-   ret = irq;
-   DRM_DEV_ERROR(dev->dev, "failed to get irq: %d\n", ret);
-   goto fail;
-   }
-
-   kms->irq = irq;
-
-   /* NOTE: driver for this regulator still missing upstream.. use
-* _get_exclusive() and ignore the error if it does not exist
-* (and hope that the bootloader left it on for us)
-*/
-   mdp4_kms->vdd = devm_regulator_get_exclusive(>dev, "vdd");
-   if (IS_ERR(mdp4_kms->vdd))
-   mdp4_kms->vdd = NULL;
-
if (mdp4_kms->vdd) {
ret = regulator_enable(mdp4_kms->vdd);
if (ret) {
@@ -442,24 +410,6 @@ static int mdp4_kms_init(struct drm_device *dev)
}
}
  
-	mdp4_kms->clk = devm_clk_get(>dev, "core_clk");

-   if (IS_ERR(mdp4_kms->clk)) {
-   DRM_DEV_ERROR(dev->dev, "failed to get core_clk\n");
-   ret = PTR_ERR(mdp4_kms->clk);
-   goto fail;
-   }
-
-   mdp4_kms->pclk = devm_clk_get(>dev, "iface_clk");
-   if (IS_ERR(mdp4_kms->pclk))
-   mdp4_kms->pclk = NULL;
-
-   mdp4_kms->axi_clk = devm_clk_get(>dev, "bus_clk");
-   if (IS_ERR(mdp4_kms->axi_clk)) {
-   DRM_DEV_ERROR(dev->dev, "failed to get axi_clk\n");
-   ret = PTR_ERR(mdp4_kms->axi_clk);
-   goto fail;
-   }
-
clk_set_rate(mdp4_kms->clk, max_clk);
  
  	read_mdp_hw_revision(mdp4_kms, , );

@@ -474,10 +424,9 @@ static int mdp4_kms_init(struct drm_device *dev)
mdp4_kms->rev = minor;
  
  	if (mdp4_kms->rev >= 2) {

-   mdp4_kms->lut_clk = devm_clk_get(>dev, "lut_clk");
-   if (IS_ERR(mdp4_kms->lut_clk)) {
+   if (!mdp4_kms->lut_clk) {
DRM_DEV_ERROR(dev->dev, "failed to get lut_clk\n");
-   ret = PTR_ERR(mdp4_kms->lut_clk);
+   ret = -ENODEV;
goto fail;
}
clk_set_rate(mdp4_kms->lut_clk, max_clk);
@@ -560,7 +509,53 @@ static const struct dev_pm_ops mdp4_pm_ops = {
  
  static int mdp4_probe(struct platform_device *pdev)

  {
-   return msm_drv_probe(>dev, mdp4_kms_init, NULL);
+   struct device *dev = >dev;
+   struct mdp4_kms *mdp4_kms;
+   int irq;
+
+   mdp4_kms = devm_kzalloc(dev, sizeof(*mdp4_kms), GFP_KERNEL);
+   if (!mdp4_kms)
+   return dev_err_probe(dev, -ENOMEM, "failed to allocate kms\n");
+
+   mdp4_kms->mmio = msm_ioremap(pdev, NULL);
+   if (IS_ERR(mdp4_kms->mmio))
+   return PTR_ERR(mdp4_kms->mmio);
+
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   return dev_err_probe(dev, irq, "failed to get irq\n");
+
+   mdp4_kms->base.base.irq = irq;

Re: [PATCH 8/8] drm/i915/mtl: Hook up interrupts for standalone media

2022-09-01 Thread Ceraolo Spurio, Daniele




On 8/29/2022 10:02 AM, Matt Roper wrote:

Top-level handling of standalone media interrupts will be processed as
part of the primary GT's interrupt handler (since primary and media GTs
share an MMIO space, unlike remote tile setups).  When we get down to
the point of handling engine interrupts, we need to take care to lookup
VCS and VECS engines in the media GT rather than the primary.

There are also a couple of additional "other" instance bits that
correspond to the media GT's GuC and media GT's power management
interrupts; we need to direct those to the media GT instance as well.

Bspec: 45605
Cc: Anusha Srivatsa 
Signed-off-by: Matt Roper 


Reviewed-by: Daniele Ceraolo Spurio 

Daniele


---
  drivers/gpu/drm/i915/gt/intel_gt_irq.c   | 19 +++
  drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  2 ++
  drivers/gpu/drm/i915/gt/intel_sa_media.c |  7 +++
  drivers/gpu/drm/i915/i915_drv.h  |  3 +++
  4 files changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 0dfd0c42d00d..f26882fdc24c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -59,11 +59,17 @@ static void
  gen11_other_irq_handler(struct intel_gt *gt, const u8 instance,
const u16 iir)
  {
+   struct intel_gt *media_gt = gt->i915->media_gt;
+
if (instance == OTHER_GUC_INSTANCE)
return guc_irq_handler(>uc.guc, iir);
+   if (instance == OTHER_MEDIA_GUC_INSTANCE && media_gt)
+   return guc_irq_handler(_gt->uc.guc, iir);
  
  	if (instance == OTHER_GTPM_INSTANCE)

return gen11_rps_irq_handler(>rps, iir);
+   if (instance == OTHER_MEDIA_GTPM_INSTANCE && media_gt)
+   return gen11_rps_irq_handler(_gt->rps, iir);
  
  	if (instance == OTHER_KCR_INSTANCE)

return intel_pxp_irq_handler(>pxp, iir);
@@ -81,6 +87,18 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
  {
struct intel_engine_cs *engine;
  
+	/*

+* Platforms with standalone media have their media engines in another
+* GT.
+*/
+   if (MEDIA_VER(gt->i915) >= 13 &&
+   (class == VIDEO_DECODE_CLASS || class == VIDEO_ENHANCEMENT_CLASS)) {
+   if (!gt->i915->media_gt)
+   goto err;
+
+   gt = gt->i915->media_gt;
+   }
+
if (instance <= MAX_ENGINE_INSTANCE)
engine = gt->engine_class[class][instance];
else
@@ -89,6 +107,7 @@ gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
if (likely(engine))
return intel_engine_cs_irq(engine, iir);
  
+err:

WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
  class, instance);
  }
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 05a40ef33258..21c7a225157f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1552,6 +1552,8 @@
  #define   OTHER_GTPM_INSTANCE 1
  #define   OTHER_KCR_INSTANCE  4
  #define   OTHER_GSC_INSTANCE  6
+#define   OTHER_MEDIA_GUC_INSTANCE 16
+#define   OTHER_MEDIA_GTPM_INSTANCE17
  
  #define GEN11_IIR_REG_SELECTOR(x)		_MMIO(0x190070 + ((x) * 4))
  
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c b/drivers/gpu/drm/i915/gt/intel_sa_media.c

index cf3053710bbf..41c270f103cf 100644
--- a/drivers/gpu/drm/i915/gt/intel_sa_media.c
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -36,5 +36,12 @@ int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t 
phys_addr,
gt->uncore = uncore;
gt->phys_addr = phys_addr;
  
+	/*

+* For current platforms we can assume there's only a single
+* media GT and cache it for quick lookup.
+*/
+   drm_WARN_ON(>drm, i915->media_gt);
+   i915->media_gt = gt;
+
return 0;
  }
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d45dca70bfa6..917958d42805 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -497,6 +497,9 @@ struct drm_i915_private {
  
  	struct kobject *sysfs_gt;
  
+	/* Quick lookup of media GT (current platforms only have one) */

+   struct intel_gt *media_gt;
+
struct {
struct i915_gem_contexts {
spinlock_t lock; /* locks list */




Re: [PATCH 7/8] drm/i915/mtl: Use primary GT's irq lock for media GT

2022-09-01 Thread Ceraolo Spurio, Daniele




On 8/29/2022 10:02 AM, Matt Roper wrote:

When we hook up interrupts (in the next patch), interrupts for the media
GT are still processed as part of the primary GT's interrupt flow.  As
such, we should share the same IRQ lock with the primary GT.  Let's
convert gt->irq_lock into a pointer and just point the media GT's
instance at the same lock the primary GT is using.

Cc: Daniele Ceraolo Spurio 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/gt/intel_engine_cs.c |  8 +++---
  drivers/gpu/drm/i915/gt/intel_gt.c| 15 +--
  drivers/gpu/drm/i915/gt/intel_gt.h|  2 +-
  drivers/gpu/drm/i915/gt/intel_gt_irq.c| 16 ++--
  drivers/gpu/drm/i915/gt/intel_gt_pm_irq.c |  8 +++---
  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  2 +-
  drivers/gpu/drm/i915/gt/intel_rps.c   | 26 +--
  drivers/gpu/drm/i915/gt/intel_sa_media.c  |  1 +
  drivers/gpu/drm/i915/gt/uc/intel_guc.c| 24 -
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  4 +--
  drivers/gpu/drm/i915/gt/uc/intel_uc.c |  4 +--
  drivers/gpu/drm/i915/i915_driver.c|  4 ++-
  drivers/gpu/drm/i915/i915_irq.c   |  4 +--
  drivers/gpu/drm/i915/pxp/intel_pxp.c  |  4 +--
  drivers/gpu/drm/i915/pxp/intel_pxp_irq.c  | 14 +-
  drivers/gpu/drm/i915/pxp/intel_pxp_session.c  |  4 +--
  16 files changed, 77 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 41acc285e8bf..6e0122b3dca2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1688,9 +1688,9 @@ bool intel_engine_irq_enable(struct intel_engine_cs 
*engine)
return false;
  
  	/* Caller disables interrupts */

-   spin_lock(>gt->irq_lock);
+   spin_lock(engine->gt->irq_lock);
engine->irq_enable(engine);
-   spin_unlock(>gt->irq_lock);
+   spin_unlock(engine->gt->irq_lock);
  
  	return true;

  }
@@ -1701,9 +1701,9 @@ void intel_engine_irq_disable(struct intel_engine_cs 
*engine)
return;
  
  	/* Caller disables interrupts */

-   spin_lock(>gt->irq_lock);
+   spin_lock(engine->gt->irq_lock);
engine->irq_disable(engine);
-   spin_unlock(>gt->irq_lock);
+   spin_unlock(engine->gt->irq_lock);
  }
  
  void intel_engines_reset_default_submission(struct intel_gt *gt)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2a29502289cb..b974a6d23281 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -37,7 +37,7 @@
  
  void intel_gt_common_init_early(struct intel_gt *gt)

  {
-   spin_lock_init(>irq_lock);
+   spin_lock_init(gt->irq_lock);
  
  	INIT_LIST_HEAD(>closed_vma);

spin_lock_init(>closed_lock);
@@ -58,14 +58,19 @@ void intel_gt_common_init_early(struct intel_gt *gt)
  }
  
  /* Preliminary initialization of Tile 0 */

-void intel_root_gt_init_early(struct drm_i915_private *i915)
+int intel_root_gt_init_early(struct drm_i915_private *i915)
  {
struct intel_gt *gt = to_gt(i915);
  
  	gt->i915 = i915;

gt->uncore = >uncore;
+   gt->irq_lock = drmm_kzalloc(>drm, sizeof(*gt->irq_lock), 
GFP_KERNEL);
+   if (!gt->irq_lock)
+   return -ENOMEM;
  
  	intel_gt_common_init_early(gt);

+
+   return 0;
  }
  
  static int intel_gt_probe_lmem(struct intel_gt *gt)

@@ -787,12 +792,18 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
  
  	if (!gt_is_root(gt)) {

struct intel_uncore *uncore;
+   spinlock_t *irq_lock;
  
  		uncore = drmm_kzalloc(>i915->drm, sizeof(*uncore), GFP_KERNEL);

if (!uncore)
return -ENOMEM;
  
+		irq_lock = drmm_kzalloc(>i915->drm, sizeof(*irq_lock), GFP_KERNEL);

+   if (!irq_lock)
+   return -ENOMEM;
+
gt->uncore = uncore;
+   gt->irq_lock = irq_lock;
  
  		intel_gt_common_init_early(gt);

}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index c9a359f35d0f..2ee582e287c8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -45,7 +45,7 @@ static inline struct intel_gt *gsc_to_gt(struct intel_gsc 
*gsc)
  }
  
  void intel_gt_common_init_early(struct intel_gt *gt);

-void intel_root_gt_init_early(struct drm_i915_private *i915);
+int intel_root_gt_init_early(struct drm_i915_private *i915);
  int intel_gt_assign_ggtt(struct intel_gt *gt);
  int intel_gt_init_mmio(struct intel_gt *gt);
  int __must_check intel_gt_init_hw(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c 
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 3a72d4fd0214..0dfd0c42d00d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -29,7 +29,7 

Re: [Intel-gfx] [PATCH 6/8] drm/i915/xelpmp: Expose media as another GT

2022-09-01 Thread Ceraolo Spurio, Daniele




On 8/29/2022 10:02 AM, Matt Roper wrote:

Xe_LPM+ platforms have "standalone media."  I.e., the media unit is
designed as an additional GT with its own engine list, GuC, forcewake,
etc.  Let's allow platforms to include media GTs in their device info.

Cc: Aravind Iddamsetty 
Signed-off-by: Matt Roper 
---
  drivers/gpu/drm/i915/Makefile|  1 +
  drivers/gpu/drm/i915/gt/intel_gt.c   | 12 ++--
  drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  8 +
  drivers/gpu/drm/i915/gt/intel_sa_media.c | 39 
  drivers/gpu/drm/i915/gt/intel_sa_media.h | 15 +
  drivers/gpu/drm/i915/i915_pci.c  | 15 +
  drivers/gpu/drm/i915/intel_device_info.h |  5 ++-
  drivers/gpu/drm/i915/intel_uncore.c  | 16 --
  drivers/gpu/drm/i915/intel_uncore.h  | 20 ++--
  9 files changed, 123 insertions(+), 8 deletions(-)
  create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.c
  create mode 100644 drivers/gpu/drm/i915/gt/intel_sa_media.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..e83e4cd46968 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -123,6 +123,7 @@ gt-y += \
gt/intel_ring.o \
gt/intel_ring_submission.o \
gt/intel_rps.o \
+   gt/intel_sa_media.o \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index d21ec11346a5..2a29502289cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -776,10 +776,15 @@ void intel_gt_driver_late_release_all(struct 
drm_i915_private *i915)
}
  }
  
-static int intel_gt_tile_setup(struct intel_gt *gt, phys_addr_t phys_addr)

+static int intel_gt_tile_setup(struct intel_gt *gt,
+  phys_addr_t phys_addr,
+  u32 gsi_offset)


This is only called from intel_gt_probe_all with gsi_offset = 0, so the 
extra param isn't really used at this point. I'm guessing the intent 
here is to keep the function params the same as intel_sa_mediagt_setup, 
so we can assign this to gtdef->setup() for "normal" extra tiles on 
xehpsdv and pvc. Maybe add a comment about it above here, so no one 
accidentally optimizes this out?



  {
int ret;
  
+	/* GSI offset is only applicable for media GTs */

+   drm_WARN_ON(>i915->drm, gsi_offset);
+
if (!gt_is_root(gt)) {
struct intel_uncore *uncore;
  
@@ -832,7 +837,7 @@ int intel_gt_probe_all(struct drm_i915_private *i915)

gt->info.engine_mask = RUNTIME_INFO(i915)->platform_engine_mask;
  
  	drm_dbg(>drm, "Setting up %s\n", gt->name);

-   ret = intel_gt_tile_setup(gt, phys_addr);
+   ret = intel_gt_tile_setup(gt, phys_addr, 0);
if (ret)
return ret;
  
@@ -862,7 +867,8 @@ int intel_gt_probe_all(struct drm_i915_private *i915)

goto err;
}
  
-		ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base);

+   ret = gtdef->setup(gt, phys_addr + gtdef->mapping_base,
+  gtdef->gsi_offset);
if (ret)
goto err;
  
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h

index 94f9ddcfb3a5..05a40ef33258 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1576,4 +1576,12 @@
  
  #define GEN12_SFC_DONE(n)			_MMIO(0x1cc000 + (n) * 0x1000)
  
+/*

+ * Standalone Media's non-engine GT registers are located at their regular GT
+ * offsets plus 0x38.  This extra offset is stored inside the intel_uncore
+ * structure so that the existing code can be used for both GTs without
+ * modification.
+ */
+#define MTL_MEDIA_GSI_BASE 0x38
+
  #endif /* __INTEL_GT_REGS__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_sa_media.c 
b/drivers/gpu/drm/i915/gt/intel_sa_media.c
new file mode 100644
index ..8c5c519457cc
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_sa_media.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "gt/intel_gt.h"
+#include "gt/intel_sa_media.h"
+
+int intel_sa_mediagt_setup(struct intel_gt *gt, phys_addr_t phys_addr,
+  u32 gsi_offset)
+{
+   struct drm_i915_private *i915 = gt->i915;
+   struct intel_uncore *uncore;
+
+   uncore = drmm_kzalloc(>drm, sizeof(*uncore), GFP_KERNEL);
+   if (!uncore)
+   return -ENOMEM;
+
+   uncore->gsi_offset = gsi_offset;
+
+   intel_gt_common_init_early(gt);
+   intel_uncore_init_early(uncore, gt);


Where is the initialization of this uncore completed (i.e. call to 
intel_uncore_init_mmio) ? Can't find it in follow up patches and without 
it the 

[RESEND PATCH libdrm v3 0/2] Add Writeback Support for Modetest

2022-09-01 Thread Jessica Zhang
Resending to correct typo in email list and adding "Signed-off-by" to
Patch [1/2] ("tests/modetest: Allocate drmModeAtomicReq before setting
properties"

---

Add writeback support to modetest with the below options:

- Passing in -c will now also show the writeback connector

- Test a built-in mode on writeback connector

- Test a custom mode from user input on writeback connector
  Usage: "./modetest -M msm -x :
-a -P @:+0+0@RG24."
  Refer to --help for exact syntax

- Dump the writeback output buffer to bitstream
  Usage: "./modetest -M msm -s :
  -a -o 
  -P @:+0+0@RG24"

This currently supports a singular writeback connector.
This patch also fixes a bug for running modetest with the atomic flag.

Changes made in V2:
- Added helper method that checks if user pipe has writeback connector
- Added error message for dump flag if no writeback connector is found
- Polls on the writeback fence fd until writeback is complete

Changes made in V3:
- Resolved compiler warnings
- Defined ETIME to ETIMEDOUT in cases where ETIME is undefined

Rohith Iyer (2):
  tests/modetest: Allocate drmModeAtomicReq before setting properties
  tests/modetest: Add support for writeback connector

 tests/modetest/buffers.c  |  19 
 tests/modetest/buffers.h  |   1 +
 tests/modetest/modetest.c | 187 ++
 3 files changed, 187 insertions(+), 20 deletions(-)

-- 
2.31.0



[RESEND PATCH libdrm v3 1/2] tests/modetest: Allocate drmModeAtomicReq before setting properties

2022-09-01 Thread Jessica Zhang
From: Rohith Iyer 

Fix null pointer deference caused by drmModeAtomicReq being
allocated before set_property was called when modetest was run
with the atomic flag.

Reviewed-by: Rob Clark 
Signed-off-by: Rohith Iyer 
Signed-off-by: Jessica Zhang 
---
 tests/modetest/modetest.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 42e2d1f4..2c31c4fc 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -2186,11 +2186,13 @@ int main(int argc, char **argv)
dump_resource(, planes);
dump_resource(, framebuffers);
 
+   if (dev.use_atomic)
+   dev.req = drmModeAtomicAlloc();
+
for (i = 0; i < prop_count; ++i)
set_property(, _args[i]);
 
if (dev.use_atomic) {
-   dev.req = drmModeAtomicAlloc();
 
if (set_preferred || (count && plane_count)) {
uint64_t cap = 0;
-- 
2.31.0



[RESEND PATCH libdrm v3 2/2] tests/modetest: Add support for writeback connector

2022-09-01 Thread Jessica Zhang
From: Rohith Iyer 

Add writeback support to modetest with the below options:

- Passing in -c will now also show the writeback connector

- Test a built-in mode on writeback connector

- Test a custom mode from user input on writeback connector
  Usage: "./modetest -M msm -x :
-a -P @:+0+0@RG24."
  Refer to --help for exact syntax

- Dump the writeback output buffer to bitstream
  Usage: "./modetest -M msm -s :
  -a -o 
  -P @:+0+0@RG24"

This currently supports a singular writeback connector.

Changes made in V2:
- Added helper method that checks if user pipe has writeback connector
- Added error message for dump flag if no writeback connector is found
- Polls on the writeback fence fd until writeback is complete

Changes made in V3:
- Resolved compiler warnings
- Defined ETIME to ETIMEDOUT in cases where ETIME is undefined

Co-developed-by: Rohith Iyer 
Signed-off-by: Jessica Zhang 
---
 tests/modetest/buffers.c  |  19 
 tests/modetest/buffers.h  |   1 +
 tests/modetest/modetest.c | 183 ++
 3 files changed, 184 insertions(+), 19 deletions(-)

diff --git a/tests/modetest/buffers.c b/tests/modetest/buffers.c
index 8a8d9e01..279d7b28 100644
--- a/tests/modetest/buffers.c
+++ b/tests/modetest/buffers.c
@@ -353,3 +353,22 @@ void bo_destroy(struct bo *bo)
 
free(bo);
 }
+
+void bo_dump(struct bo *bo, const char *filename)
+{
+   FILE *fp;
+
+   if (!bo || !filename)
+   return;
+
+   fp = fopen(filename, "wb");
+   if (fp) {
+   void *addr;
+
+   bo_map(bo, );
+   printf("Dumping buffer %p to file %s.\n", bo->ptr, filename);
+   fwrite(bo->ptr, 1, bo->size, fp);
+   bo_unmap(bo);
+   fclose(fp);
+   }
+}
diff --git a/tests/modetest/buffers.h b/tests/modetest/buffers.h
index 7f95396b..cbd54e9e 100644
--- a/tests/modetest/buffers.h
+++ b/tests/modetest/buffers.h
@@ -36,5 +36,6 @@ struct bo *bo_create(int fd, unsigned int format,
   unsigned int handles[4], unsigned int pitches[4],
   unsigned int offsets[4], enum util_fill_pattern pattern);
 void bo_destroy(struct bo *bo);
+void bo_dump(struct bo *bo, const char *filename);
 
 #endif
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 2c31c4fc..8073d143 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -68,8 +68,13 @@
 #include "buffers.h"
 #include "cursor.h"
 
+#ifndef ETIME
+#define ETIME ETIMEDOUT
+#endif
+
 static enum util_fill_pattern primary_fill = UTIL_PATTERN_SMPTE;
 static enum util_fill_pattern secondary_fill = UTIL_PATTERN_TILES;
+static enum util_fill_pattern plain_fill = UTIL_PATTERN_PLAIN;
 
 struct crtc {
drmModeCrtc *crtc;
@@ -128,6 +133,7 @@ struct device {
 
int use_atomic;
drmModeAtomicReq *req;
+   int32_t writeback_fence_fd;
 };
 
 static inline int64_t U642I64(uint64_t val)
@@ -135,6 +141,11 @@ static inline int64_t U642I64(uint64_t val)
return (int64_t)*((int64_t *));
 }
 
+static inline uint64_t to_user_pointer(const void *ptr)
+{
+   return (uintptr_t)ptr;
+}
+
 static float mode_vrefresh(drmModeModeInfo *mode)
 {
return  mode->clock * 1000.00
@@ -811,6 +822,10 @@ struct pipe_arg {
struct crtc *crtc;
unsigned int fb_id[2], current_fb_id;
struct timeval start;
+   unsigned int out_fb_id;
+   struct bo *out_bo;
+   bool custom;
+   bool dump;
 
int swap_count;
 };
@@ -917,27 +932,43 @@ static struct crtc *pipe_find_crtc(struct device *dev, 
struct pipe_arg *pipe)
return >resources->crtcs[crtc_idx - 1];
 }
 
+static int parse_mode_string(char *mode_string, drmModeModeInfo *user_mode)
+{
+   return sscanf(mode_string, 
"%u,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%hu,%u,%s",
+   _mode->clock, _mode->hdisplay, 
_mode->hsync_start,
+   _mode->hsync_end, _mode->htotal, 
_mode->hskew,
+   _mode->vdisplay, _mode->vsync_start, 
_mode->vsync_end,
+   _mode->vtotal, _mode->vscan, 
_mode->vrefresh,
+   user_mode->name);
+}
+
 static int pipe_find_crtc_and_mode(struct device *dev, struct pipe_arg *pipe)
 {
drmModeModeInfo *mode = NULL;
int i;
+   static drmModeModeInfo user_mode;
 
-   pipe->mode = NULL;
-
-   for (i = 0; i < (int)pipe->num_cons; i++) {
-   mode = connector_find_mode(dev, pipe->con_ids[i],
-  pipe->mode_str, pipe->vrefresh);
-   if (mode == NULL) {
-   if (pipe->vrefresh)
-   fprintf(stderr,
-   "failed to find mode "
-   "\"%s-%.2fHz\" for connector %s\n",
-   pipe->mode_str, pipe->vrefresh, pipe->cons[i]);
-   else
-   

Re: [PATCH v2 20/41] drm/modes: Properly generate a drm_display_mode from a named mode

2022-09-01 Thread Mateusz Kwiatkowski
Hi Maxime,

> +        if (!named_mode->tv_mode)
> +            continue;

As mentioned in the previous email replying to 19/41, this makes it impossible
to specify DRM_MODE_TV_MODE_NTSC_443 as currently defined in the named mode
successfully.

Best regards,
Mateusz Kwiatkowski


Re: [PATCH v2 19/41] drm/modes: Introduce the tv_mode property as a command-line option

2022-09-01 Thread Mateusz Kwiatkowski
Hi Maxime,

> @@ -2212,20 +2239,22 @@ struct drm_named_mode {
>      unsigned int xres;
>      unsigned int yres;
>      unsigned int flags;
> +    unsigned int tv_mode;
>  };

Are _all_ named modes supposed to be about analog TV?

If so, then probably this structure should be renamed drm_named_analog_tv_mode
or something.

If not, then including tv_mode in all of them sounds almost dangrous. 0 is a
valid value for enum drm_connector_tv_mode, corresponding to
DRM_MODE_TV_MODE_NTSC_443. This is a very weird default (maybe it shouldn't be
the one that has a numeric value of 0?) and if there ever is a named mode that
is not related to analog TV, it looks that it will refer to NTSC-443.

Not sure where could that actually propagate, and maybe what I'm saying can't
happen, but I'm imagining weird scenarios where a GPU that has both a
VGA/HDMI/whatever output, and a composite output, switches to NTSC-443 on the
composite output by default because a named mode for the modern output is
selected.

Maybe something like DRM_MODE_TV_MODE_NONE = 0 would make sense?

Maybe not. This is not an actual suggestion, just "thinking out loud".

Best regards,
Mateusz Kwiatkowski


Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"

2022-09-01 Thread Maíra Canal
Hi Maxime,

On 9/1/22 09:55, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
>> With the introduction of KUnit, IGT is no longer the only option to run
>> the DRM unit tests, as the tests can be run through kunit-tool or on
>> real hardware with CONFIG_KUNIT.
>>
>> Therefore, remove the "igt_" prefix from the tests and replace it with
>> the "test_drm_" prefix, making the tests' names independent from the tool
>> used.
>>
>> Signed-off-by: Maíra Canal 
>>
>> ---
>> v1 -> v2: 
>> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/
>> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing 
>> (Jani Nikula).
> 
> I appreciate it's a bit of a bikeshed but I disagree with this. The
> majority of the kunit tests already out there start with the framework
> name, including *all* the examples in the kunit doc. Plus, it's fairly
> obvious that it's a test, kunit is only about running tests in the first
> place.

Would it be better to keep it as "drm_"?

Currently, I don't think it is appropriate to hold the "igt_" prefix, as
the tests are not IGT exclusive, but I don't have a strong opinion on
using the "drm_" or the "test_drm" prefixes.

Best Regards,
- Maíra Canal

> 
> Maxime
> 


RE: [Intel-gfx] [PATCH v3 02/11] drm/i915: Read graphics/media/display arch version from hw

2022-09-01 Thread Sripada, Radhakrishna
Hi Jani,

> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, September 1, 2022 12:58 AM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v3 02/11] drm/i915: Read 
> graphics/media/display
> arch version from hw
> 
> On Wed, 31 Aug 2022, Radhakrishna Sripada 
> wrote:
> > From: Matt Roper 
> >
> > Going forward, the hardware teams no longer consider new platforms to
> > have a "generation" in the way we've defined it for past platforms.
> > Instead, each IP block (graphics, media, display) will have their own
> > architecture major.minor versions and stepping ID's which should be read
> > directly from a register in the MMIO space.  New hardware programming
> > styles, features, and workarounds should be conditional solely on the
> > architecture version, and should no longer be derived from the PCI
> > device ID, revision ID, or platform-specific feature flags.
> >
> > Bspec: 63361, 64111
> >
> > v2:
> >   - Move the IP version readout to intel_device_info.c
> >   - Convert the macro into a function
> >
> > Signed-off-by: Matt Roper 
> > Signed-off-by: Rodrigo Vivi 
> > Signed-off-by: Radhakrishna Sripada 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_gt_regs.h  |  2 +
> >  drivers/gpu/drm/i915/i915_driver.c   |  2 +
> >  drivers/gpu/drm/i915/i915_drv.h  |  2 +
> >  drivers/gpu/drm/i915/i915_pci.c  |  1 +
> >  drivers/gpu/drm/i915/i915_reg.h  |  6 ++
> >  drivers/gpu/drm/i915/intel_device_info.c | 73 
> >  drivers/gpu/drm/i915/intel_device_info.h |  3 +
> >  7 files changed, 89 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > index d414785003cc..579da62158c4 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > @@ -39,6 +39,8 @@
> >  #define FORCEWAKE_ACK_RENDER_GEN9  _MMIO(0xd84)
> >  #define FORCEWAKE_ACK_MEDIA_GEN9   _MMIO(0xd88)
> >
> > +#define GMD_ID_GRAPHICS_MMIO(0xd8c)
> > +
> >  #define MCFG_MCR_SELECTOR  _MMIO(0xfd0)
> >  #define SF_MCR_SELECTOR_MMIO(0xfd8)
> >  #define GEN8_MCR_SELECTOR  _MMIO(0xfdc)
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> > index 3aedc33ded57..5826c70d6fa5 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -323,6 +323,8 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> > if (i915_inject_probe_failure(dev_priv))
> > return -ENODEV;
> >
> > +   intel_device_info_runtime_init_early(dev_priv);
> > +
> > intel_device_info_subplatform_init(dev_priv);
> 
> Hmm, so why not move the subplatform init call to runtime init early?
Will move in next rev.

> 
> > intel_step_init(dev_priv);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> > index bf60593a4ce5..935ff3486fef 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -936,6 +936,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> *i915,
> >
> >  #define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
> >
> > +#define HAS_GMD_ID(i915)   INTEL_INFO(i915)->has_gmd_id
> > +
> >  #define HAS_LSPCON(dev_priv) (IS_DISPLAY_VER(dev_priv, 9, 10))
> >
> >  #define HAS_L3_CCS_READ(i915) (INTEL_INFO(i915)->has_l3_ccs_read)
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> b/drivers/gpu/drm/i915/i915_pci.c
> > index 72577e327c71..9772c315185d 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -1129,6 +1129,7 @@ static const struct intel_device_info mtl_info = {
> > PLATFORM(INTEL_METEORLAKE),
> > .display.has_modular_fia = 1,
> > .has_flat_ccs = 0,
> > +   .has_gmd_id = 1,
> > .has_snoop = 1,
> > .__runtime.memory_regions = REGION_SMEM |
> REGION_STOLEN_LMEM,
> > .__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> > index 5e6239864c35..f52ed6d00030 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5798,6 +5798,11 @@
> >  #define ICL_DSSM_CDCLK_PLL_REFCLK_19_2MHz  (1 << 29)
> >  #define ICL_DSSM_CDCLK_PLL_REFCLK_38_4MHz  (2 << 29)
> >
> > +#define GMD_ID_DISPLAY _MMIO(0x510a0)
> > +#define   GMD_ID_ARCH_MASK REG_GENMASK(31, 22)
> > +#define   GMD_ID_RELEASE_MASK  REG_GENMASK(21, 14)
> > +#define   GMD_ID_STEP  REG_GENMASK(5, 0)
> > +
> >  /*GEN11 chicken */
> >  #define _PIPEA_CHICKEN 0x70038
> >  #define _PIPEB_CHICKEN 0x71038
> > @@ -8298,4 +8303,5 

Re: [PATCH v2 09/41] drm/connector: Add TV standard property

2022-09-01 Thread Mateusz Kwiatkowski
Hi Maxime,

W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
> The TV mode property has been around for a while now to select and get the
> current TV mode output on an analog TV connector.
>
> Despite that property name being generic, its content isn't and has been
> driver-specific which makes it hard to build any generic behaviour on top
> of it, both in kernel and user-space.
>
> Let's create a new bitmask tv norm property, that can contain any of the
> analog TV standards currently supported by kernel drivers. Each driver can
> then pass in a bitmask of the modes it supports.

This is not a bitmask property anymore, you've just changed it to an enum.
The commit message is now misleading.

> +static const struct drm_prop_enum_list drm_tv_mode_enum_list[] = {
> +    { DRM_MODE_TV_MODE_NTSC_443, "NTSC-443" },
> +    { DRM_MODE_TV_MODE_NTSC_J, "NTSC-J" },
> +    { DRM_MODE_TV_MODE_NTSC_M, "NTSC-M" },
> +    { DRM_MODE_TV_MODE_PAL_60, "PAL-60" },
> +    { DRM_MODE_TV_MODE_PAL_B, "PAL-B" },
> +    { DRM_MODE_TV_MODE_PAL_D, "PAL-D" },
> +    { DRM_MODE_TV_MODE_PAL_G, "PAL-G" },
> +    { DRM_MODE_TV_MODE_PAL_H, "PAL-H" },
> +    { DRM_MODE_TV_MODE_PAL_I, "PAL-I" },
> +    { DRM_MODE_TV_MODE_PAL_M, "PAL-M" },
> +    { DRM_MODE_TV_MODE_PAL_N, "PAL-N" },
> +    { DRM_MODE_TV_MODE_PAL_NC, "PAL-Nc" },
> +    { DRM_MODE_TV_MODE_SECAM_60, "SECAM-60" },
> +    { DRM_MODE_TV_MODE_SECAM_B, "SECAM-B" },
> +    { DRM_MODE_TV_MODE_SECAM_D, "SECAM-D" },
> +    { DRM_MODE_TV_MODE_SECAM_G, "SECAM-G" },
> +    { DRM_MODE_TV_MODE_SECAM_K, "SECAM-K" },
> +    { DRM_MODE_TV_MODE_SECAM_K1, "SECAM-K1" },
> +    { DRM_MODE_TV_MODE_SECAM_L, "SECAM-L" },
> +};

I did not comment on it the last time, but this list looks a little bit random.

Compared to the standards defined by V4L2, you also define SECAM-60 (a good
thing to define, because why not), but don't define PAL-B1, PAL-D1, PAL-K,
SECAM-H, SECAM-LC (whatever that is - probably just another name for SECAM-L,
see my comment about PAL-Nc below), or NTSC-M-KR (a Korean variant of NTSC).

Like I mentioned previously, I'm personally not a fan of including all those
CCIR/ITU system variants, as they don't mean any difference to the output unless
there is an RF modulator involved. But I get it that they have already been used
and regressing probably wouldn't be a very good idea. But in that case keeping
it consistent with the set of values used by V4L2 would be wise, I think.

> +/**
> + * drm_mode_create_tv_properties - create TV specific connector properties
> + * @dev: DRM device
> + * @supported_tv_modes: Bitmask of TV modes supported (See 
> DRM_MODE_TV_MODE_*)
> +
> + * Called by a driver's TV initialization routine, this function creates
> + * the TV specific connector properties for a given device.  Caller is
> + * responsible for allocating a list of format names and passing them to
> + * this routine.
> + *
> + * Returns:
> + * 0 on success or a negative error code on failure.
> + */
> +int drm_mode_create_tv_properties(struct drm_device *dev,
> +                  unsigned int supported_tv_modes)

supported_tv_modes is supposed to be a bitmask of BIT(DRM_MODE_TV_MODE_*)
(or (1< +    /**
> +     * @DRM_MODE_TV_MODE_PAL_NC: Seems equivalent to
> +     * @DRM_MODE_TV_MODE_PAL_N.
> +     */
> +    DRM_MODE_TV_MODE_PAL_NC,

AFAIK, the entire reason that "PAL-Nc" is ever mentioned as something separate
from PAL-N is a result of a misunderstanding or misreading of the CCIR/ITU
documents. See also the posting signed as Alchaemist here:
https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc

That being said, we probably want to keep it if we want to remaing compatible
with the loads of software and drivers which enumerate those as separate
systems. But from a technical standpoint, PAL-N and PAL-Nc (and N/PAL, PAL-CN
etc.) are just different "spellings" referring to exactly the same system.

> +    /**
> +     * @DRM_MODE_TV_MODE_SECAM_K: CCIR System G together with the
> +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G but
> +     * with different channels.
> +     */
> +    DRM_MODE_TV_MODE_SECAM_K,
> +
> +    /**
> +     * @DRM_MODE_TV_MODE_SECAM_K1: CCIR System G together with the
> +     * SECAM color system. Similar to @DRM_MODE_TV_MODE_SECAM_G and
> +     * @DRM_MODE_TV_MODE_SECAM_K but with different channels.
> +     */
> +    DRM_MODE_TV_MODE_SECAM_K1,

Typos: you meant CCIR Systems K and K1, not System G.

Best regards,
Mateusz Kwiatkowski


Re: [PATCH v1 2/4] drm/msm/dpu: move resource allocation to the _probe function

2022-09-01 Thread Abhinav Kumar




On 6/20/2022 2:30 PM, Dmitry Baryshkov wrote:

To let the probe function bail early if any of the resources is
unavailable, move resource allocattion from kms_init directly to the

 allocation

probe callback. While we are at it, replace irq_of_parse_and_map() with
platform_get_irq().

Any specific reason to replace this?


Signed-off-by: Dmitry Baryshkov 


With those two addressed,

Reviewed-by: Abhinav Kumar 

---
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 62 +
  1 file changed, 32 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index ae13a3a5d8a5..756be04d804b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1206,31 +1206,13 @@ static int dpu_kms_init(struct drm_device *ddev)
struct device *dev = ddev->dev;
struct platform_device *pdev = to_platform_device(dev);
struct dpu_kms *dpu_kms;
-   int irq;
struct dev_pm_opp *opp;
int ret = 0;
unsigned long max_freq = ULONG_MAX;
  
-	dpu_kms = devm_kzalloc(>dev, sizeof(*dpu_kms), GFP_KERNEL);

+   dpu_kms = to_dpu_kms(priv->kms);
if (!dpu_kms)
-   return -ENOMEM;
-
-   ret = devm_pm_opp_set_clkname(dev, "core");
-   if (ret)
-   return ret;
-   /* OPP table is optional */
-   ret = devm_pm_opp_of_add_table(dev);
-   if (ret && ret != -ENODEV) {
-   dev_err(dev, "invalid OPP table in device tree\n");
-   return ret;
-   }
-
-   ret = devm_clk_bulk_get_all(>dev, _kms->clocks);
-   if (ret < 0) {
-   DPU_ERROR("failed to parse clocks, ret=%d\n", ret);
-   return ret;
-   }
-   dpu_kms->num_clocks = ret;
+   return -EINVAL;
  
  	opp = dev_pm_opp_find_freq_floor(dev, _freq);

if (!IS_ERR(opp))
@@ -1249,21 +1231,41 @@ static int dpu_kms_init(struct drm_device *ddev)
pm_runtime_enable(>dev);
dpu_kms->rpm_enabled = true;
  
-	priv->kms = _kms->base;

-
-   irq = irq_of_parse_and_map(dpu_kms->pdev->dev.of_node, 0);
-   if (!irq) {
-   DPU_ERROR("failed to get irq\n");
-   return -EINVAL;
-   }
-   dpu_kms->base.irq = irq;
-
return 0;
  }
  
  static int dpu_dev_probe(struct platform_device *pdev)

  {
-   return msm_drv_probe(>dev, dpu_kms_init, NULL);
+   struct device *dev = >dev;
+   struct dpu_kms *dpu_kms;
+   int irq;
+   int ret = 0;
+
+   dpu_kms = devm_kzalloc(dev, sizeof(*dpu_kms), GFP_KERNEL);
+   if (!dpu_kms)
+   return -ENOMEM;
+
+   ret = devm_pm_opp_set_clkname(dev, "core");
+   if (ret)
+   return ret;
+   /* OPP table is optional */
+   ret = devm_pm_opp_of_add_table(dev);
+   if (ret && ret != -ENODEV)
+   return dev_err_probe(dev, ret, "invalid OPP table in device 
tree\n");
+
+   ret = devm_clk_bulk_get_all(>dev, _kms->clocks);
+   if (ret < 0)
+   return dev_err_probe(dev, ret, "failed to parse clocks\n");
+
+   dpu_kms->num_clocks = ret;
+
+   irq = platform_get_irq(pdev, 0);
+   if (irq < 0)
+   return dev_err_probe(dev, irq, "failed to get irq\n");
+
+   dpu_kms->base.irq = irq;
+
+   return msm_drv_probe(>dev, dpu_kms_init, _kms->base);
  }
  
  static int dpu_dev_remove(struct platform_device *pdev)


[linux-next:master] BUILD REGRESSION e47eb90a0a9ae20b82635b9b99a8d0979b757ad8

2022-09-01 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: e47eb90a0a9ae20b82635b9b99a8d0979b757ad8  Add linux-next specific 
files for 20220901

Error/Warning reports:

https://lore.kernel.org/linux-media/202209020437.exeodmfe-...@intel.com
https://lore.kernel.org/llvm/202208312208.hjwleien-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

drivers/base/regmap/regmap-mmio.c:221:17: error: implicit declaration of 
function 'writesb'; did you mean 'writeb'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:224:17: error: implicit declaration of 
function 'writesw'; did you mean 'writew'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:227:17: error: implicit declaration of 
function 'writesl'; did you mean 'writel'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:231:17: error: implicit declaration of 
function 'writesq'; did you mean 'writeq'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:231:17: error: implicit declaration of 
function 'writesq'; did you mean 'writesl'? 
[-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:358:17: error: implicit declaration of 
function 'readsb'; did you mean 'readb'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:361:17: error: implicit declaration of 
function 'readsw'; did you mean 'readw'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:364:17: error: implicit declaration of 
function 'readsl'; did you mean 'readl'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:368:17: error: implicit declaration of 
function 'readsq'; did you mean 'readq'? [-Werror=implicit-function-declaration]
drivers/base/regmap/regmap-mmio.c:368:17: error: implicit declaration of 
function 'readsq'; did you mean 'readsl'? 
[-Werror=implicit-function-declaration]
drivers/clk/clk.c:1193:6: error: redefinition of 'clk_is_enabled_when_prepared'
drivers/clk/clk.c:866:6: error: redefinition of 'clk_unprepare'
drivers/clk/clk.c:947:5: error: redefinition of 'clk_prepare'
drivers/gpu/drm/amd/amdgpu/imu_v11_0_3.c:139:6: warning: no previous prototype 
for 'imu_v11_0_3_program_rlc_ram' [-Wmissing-prototypes]
drivers/platform/mellanox/mlxreg-lc.c:866 mlxreg_lc_probe() warn: passing zero 
to 'PTR_ERR'
net/ieee802154/nl802154.c:2503:26: error: 'NL802154_CMD_DEL_SEC_LEVEL' 
undeclared here (not in a function); did you mean 
'NL802154_CMD_SET_CCA_ED_LEVEL'?

Error/Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allyesconfig
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsw
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesw
|   `-- 
drivers-gpu-drm-amd-amdgpu-imu_v11_0_3.c:warning:no-previous-prototype-for-imu_v11_0_3_program_rlc_ram
|-- alpha-buildonly-randconfig-r003-20220901
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsw
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesq
|   `-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesw
|-- alpha-randconfig-r021-20220901
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsq
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-readsw
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesb
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesl
|   |-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesq
|   `-- 
drivers-base-regmap-regmap-mmio.c:error:implicit-declaration-of-function-writesw

[PATCH 2/2] drm/msm/dpu: Add support for P010 format

2022-09-01 Thread Jessica Zhang
Add support for P010 color format. This adds support for both linear and
compressed formats.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c| 17 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |  1 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  |  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 57971c08f57c..d95540309d4d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -434,6 +434,12 @@ static const struct dpu_format dpu_format_map[] = {
DPU_CHROMA_H2V1, DPU_FORMAT_FLAG_YUV,
DPU_FETCH_LINEAR, 2),
 
+   PSEUDO_YUV_FMT_LOOSE(P010,
+   0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+   C1_B_Cb, C2_R_Cr,
+   DPU_CHROMA_420, DPU_FORMAT_FLAG_DX | DPU_FORMAT_FLAG_YUV,
+   DPU_FETCH_LINEAR, 2),
+
INTERLEAVED_YUV_FMT(VYUY,
0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C2_R_Cr, C0_G_Y, C1_B_Cb, C0_G_Y,
@@ -536,6 +542,14 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
DPU_CHROMA_420, DPU_FORMAT_FLAG_YUV |
DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 4, DPU_TILE_HEIGHT_NV12),
+
+   PSEUDO_YUV_FMT_TILED(P010,
+   0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+   C1_B_Cb, C2_R_Cr,
+   DPU_CHROMA_420, DPU_FORMAT_FLAG_DX |
+   DPU_FORMAT_FLAG_YUV |
+   DPU_FORMAT_FLAG_COMPRESSED,
+   DPU_FETCH_UBWC, 4, DPU_TILE_HEIGHT_UBWC),
 };
 
 /* _dpu_get_v_h_subsample_rate - Get subsample rates for all formats we support
@@ -584,7 +598,8 @@ static int _dpu_format_get_media_color_ubwc(const struct 
dpu_format *fmt)
int color_fmt = -1;
int i;
 
-   if (fmt->base.pixel_format == DRM_FORMAT_NV12) {
+   if (fmt->base.pixel_format == DRM_FORMAT_NV12 ||
+   fmt->base.pixel_format == DRM_FORMAT_P010) {
if (DPU_FORMAT_IS_DX(fmt)) {
if (fmt->unpack_tight)
color_fmt = COLOR_FMT_NV12_BPP10_UBWC;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 53b6edb2f563..199a2f755db4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -210,6 +210,7 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_RGBX,
DRM_FORMAT_BGRX,
 
+   DRM_FORMAT_P010,
DRM_FORMAT_NV12,
DRM_FORMAT_NV21,
DRM_FORMAT_NV16,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 60ea834dc8d6..f130bf783081 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -73,6 +73,7 @@ static const uint32_t qcom_compressed_supported_formats[] = {
DRM_FORMAT_BGR565,
 
DRM_FORMAT_NV12,
+   DRM_FORMAT_P010,
 };
 
 /**
-- 
2.35.1



[PATCH 1/2] drm/msm/dpu: Add support for XR30 format

2022-09-01 Thread Jessica Zhang
Add support for XR30 color format. This supports both linear and
compressed formats.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c| 7 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 1 +
 3 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index f436a1f3419d..57971c08f57c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -524,6 +524,12 @@ static const struct dpu_format dpu_format_map_ubwc[] = {
true, 4, DPU_FORMAT_FLAG_DX | DPU_FORMAT_FLAG_COMPRESSED,
DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
 
+   INTERLEAVED_RGB_FMT_TILED(XRGB2101010,
+   COLOR_8BIT, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
+   C2_R_Cr, C0_G_Y, C1_B_Cb, C3_ALPHA, 4,
+   true, 4, DPU_FORMAT_FLAG_DX | DPU_FORMAT_FLAG_COMPRESSED,
+   DPU_FETCH_UBWC, 2, DPU_TILE_HEIGHT_UBWC),
+
PSEUDO_YUV_FMT_TILED(NV12,
0, COLOR_8BIT, COLOR_8BIT, COLOR_8BIT,
C1_B_Cb, C2_R_Cr,
@@ -571,6 +577,7 @@ static int _dpu_format_get_media_color_ubwc(const struct 
dpu_format *fmt)
{DRM_FORMAT_XBGR, COLOR_FMT_RGBA_UBWC},
{DRM_FORMAT_XRGB, COLOR_FMT_RGBA_UBWC},
{DRM_FORMAT_ABGR2101010, COLOR_FMT_RGBA1010102_UBWC},
+   {DRM_FORMAT_XRGB2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_XBGR2101010, COLOR_FMT_RGBA1010102_UBWC},
{DRM_FORMAT_BGR565, COLOR_FMT_RGB565_UBWC},
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 0239a811d5ec..53b6edb2f563 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -156,6 +156,7 @@ static const uint32_t plane_formats[] = {
DRM_FORMAT_RGBX,
DRM_FORMAT_BGRX,
DRM_FORMAT_XBGR,
+   DRM_FORMAT_XRGB2101010,
DRM_FORMAT_RGB888,
DRM_FORMAT_BGR888,
DRM_FORMAT_RGB565,
@@ -184,6 +185,7 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_RGBA,
DRM_FORMAT_BGRX,
DRM_FORMAT_BGRA,
+   DRM_FORMAT_XRGB2101010,
DRM_FORMAT_XRGB,
DRM_FORMAT_XBGR,
DRM_FORMAT_RGBX,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index a617a3d8b1bc..60ea834dc8d6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -69,6 +69,7 @@ static const uint32_t qcom_compressed_supported_formats[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
DRM_FORMAT_XRGB,
+   DRM_FORMAT_XRGB2101010,
DRM_FORMAT_BGR565,
 
DRM_FORMAT_NV12,
-- 
2.35.1



[PATCH 0/2] Add support for HDR color formats

2022-09-01 Thread Jessica Zhang
Add support for HDR color formats.

XR30 linear/compressed format has been validated with null_platform_test
on SC7180, and P010 linear has been validated with plane_test (also on
SC7180).

Jessica Zhang (2):
  drm/msm/dpu: Add support for XR30 format
  drm/msm/dpu: Add support for P010 format

 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c   | 24 ++-
 .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c|  3 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  2 ++
 3 files changed, 28 insertions(+), 1 deletion(-)

--
2.35.1



Re: [PATCH v6 3/6] clk: qcom: gdsc: Add a reset op to poll gdsc collapse

2022-09-01 Thread Akhil P Oommen

On 9/1/2022 3:58 PM, Philipp Zabel wrote:

On Wed, Aug 31, 2022 at 10:48:24AM +0530, Akhil P Oommen wrote:

Add a reset op compatible function to poll for gdsc collapse.

Signed-off-by: Akhil P Oommen 
Reviewed-by: Dmitry Baryshkov 
---

(no changes since v2)

Changes in v2:
- Minor update to function prototype

  drivers/clk/qcom/gdsc.c | 23 +++
  drivers/clk/qcom/gdsc.h |  7 +++
  2 files changed, 26 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index 44520ef..2d0f1d1 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include "gdsc.h"
+#include "reset.h"
  
  #define PWR_ON_MASK		BIT(31)

  #define EN_REST_WAIT_MASK GENMASK_ULL(23, 20)
@@ -116,7 +117,8 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK, val);
  }
  
-static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status)

+static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status,
+   s64 timeout_us, unsigned int interval_ms)
  {
ktime_t start;
  
@@ -124,7 +126,9 @@ static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status)

do {
if (gdsc_check_status(sc, status))
return 0;
-   } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
+   if (interval_ms)
+   msleep(interval_ms);
+   } while (ktime_us_delta(ktime_get(), start) < timeout_us);

Could this loop be implemented with read_poll_timeout()?
I felt it is not worth the code churn. Currently, we hit this path only 
during GPU recovery which is a rare event.



if (gdsc_check_status(sc, status))
return 0;
@@ -172,7 +176,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum 
gdsc_status status)
udelay(1);
}
  
-	ret = gdsc_poll_status(sc, status);

+   ret = gdsc_poll_status(sc, status, TIMEOUT_US, 0);
WARN(ret, "%s status stuck at 'o%s'", sc->pd.name, status ? "ff" : "n");
  
  	if (!ret && status == GDSC_OFF && sc->rsupply) {

@@ -343,7 +347,7 @@ static int _gdsc_disable(struct gdsc *sc)
 */
udelay(1);
  
-		ret = gdsc_poll_status(sc, GDSC_ON);

+   ret = gdsc_poll_status(sc, GDSC_ON, TIMEOUT_US, 0);
if (ret)
return ret;
}
@@ -565,3 +569,14 @@ int gdsc_gx_do_nothing_enable(struct generic_pm_domain 
*domain)
return 0;
  }
  EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
+
+int gdsc_wait_for_collapse(void *priv)
+{
+   struct gdsc *sc = priv;
+   int ret;
+
+   ret = gdsc_poll_status(sc, GDSC_OFF, 50, 5);
+   WARN(ret, "%s status stuck at 'on'", sc->pd.name);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(gdsc_wait_for_collapse);

Superficially, using this as a reset op seems like abuse of the reset
controller API. Calling reset_control_reset() on this in the GPU driver
will not trigger a reset signal on the GPU's "cx_collapse" reset input.

So at the very least, this patchset should contain an explanation why
this is a good idea regardless, and how this is almost a reset control.

I have read the linked discussion, and I'm not sure I understand all
of it, so please correct me if I'm wrong: There is some other way to
force the GDSC into a state that will eventually cause a GPU reset, and
this is just the remaining part to make sure that the workaround dance
is finished?

If so, it should be explained that this depends on something else to
actually indirectly trigger the reset, and where this happens.


Let me clarify a bit. In Qcom gpu subsystem, power collapse is the only 
way to properly reset the cx domain. Power collapse is a bit complex 
here because multiple subsystems/drivers can keep a vote on the 
regulator which blocks power collapse. So we remove the vote from gpu 
driver and poll (with a reasonable timeout obviously) until everyone 
removes their vote and gdsc collapses.


I suppose generally a reset implementation would look like this:

reset {
        Step 1: Trigger a reset pulse
        Step 2: Wait/poll for reset to complete
}

We skip step1 because we don't have a way to force it during gpu reset. 
Instead of that, we just remove the gdsc vote from the gpu driver. So 
all that is left to do here is step 2.


Like you suggested, I think it would be better if we document this in 
patch 4.


Thanks for the review. Please let me know if you have any feedback.

-Akhil.


regards
Philipp




Re: [PATCH 2/9] drm/nouveau: convert to using is_hdmi and has_audio from display info

2022-09-01 Thread Lyude Paul
Reviewed-by: Lyude Paul 

Also, went ahead and tested this for you on one of my machines:

Tested-by: Lyude Paul 

On Thu, 2022-09-01 at 15:47 +0300, Jani Nikula wrote:
> Prefer the parsed results for is_hdmi and has_audio in display info over
> calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
> respectively.
> 
> Cc: Ben Skeggs 
> Cc: Karol Herbst 
> Cc: Lyude Paul 
> Cc: nouv...@lists.freedesktop.org
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 
>  drivers/gpu/drm/nouveau/dispnv50/head.c | 8 +---
>  drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
>  3 files changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 33c97d510999..d0d9494b729c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -769,7 +769,7 @@ nv50_audio_enable(struct drm_encoder *encoder, struct 
> nouveau_crtc *nv_crtc,
>(0x0100 << nv_crtc->index),
>   };
>  
> - if (!drm_detect_monitor_audio(nv_connector->edid))
> + if (!nv_connector->base.display_info.has_audio)
>   return;
>  
>   mutex_lock(>audio.lock);
> @@ -839,7 +839,7 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct 
> nouveau_crtc *nv_crtc,
>   int ret;
>   int size;
>  
> - if (!drm_detect_hdmi_monitor(nv_connector->edid))
> + if (!nv_connector->base.display_info.is_hdmi)
>   return;
>  
>   hdmi = _connector->base.display_info.hdmi;
> @@ -1705,7 +1705,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
> struct drm_atomic_state *sta
>  
>   if ((disp->disp->object.oclass == GT214_DISP ||
>disp->disp->object.oclass >= GF110_DISP) &&
> - drm_detect_monitor_audio(nv_connector->edid))
> + nv_connector->base.display_info.has_audio)
>   hda = true;
>   nv50_outp_acquire(nv_encoder, hda);
>  
> @@ -1721,7 +1721,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
> struct drm_atomic_state *sta
>*/
>   if (mode->clock >= 165000 &&
>   nv_encoder->dcb->duallink_possible &&
> - !drm_detect_hdmi_monitor(nv_connector->edid))
> + !nv_connector->base.display_info.is_hdmi)
>   proto = 
> NV507D_SOR_SET_CONTROL_PROTOCOL_DUAL_TMDS;
>   } else {
>   proto = NV507D_SOR_SET_CONTROL_PROTOCOL_SINGLE_TMDS_B;
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
> b/drivers/gpu/drm/nouveau/dispnv50/head.c
> index c3c57be54e1c..8b5bc834f1b3 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/head.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
> @@ -127,14 +127,8 @@ nv50_head_atomic_check_view(struct nv50_head_atom *armh,
>   struct drm_display_mode *omode = >state.adjusted_mode;
>   struct drm_display_mode *umode = >state.mode;
>   int mode = asyc->scaler.mode;
> - struct edid *edid;
>   int umode_vdisplay, omode_hdisplay, omode_vdisplay;
>  
> - if (connector->edid_blob_ptr)
> - edid = (struct edid *)connector->edid_blob_ptr->data;
> - else
> - edid = NULL;
> -
>   if (!asyc->scaler.full) {
>   if (mode == DRM_MODE_SCALE_NONE)
>   omode = umode;
> @@ -162,7 +156,7 @@ nv50_head_atomic_check_view(struct nv50_head_atom *armh,
>*/
>   if ((asyc->scaler.underscan.mode == UNDERSCAN_ON ||
>   (asyc->scaler.underscan.mode == UNDERSCAN_AUTO &&
> -  drm_detect_hdmi_monitor(edid {
> +  connector->display_info.is_hdmi))) {
>   u32 bX = asyc->scaler.underscan.hborder;
>   u32 bY = asyc->scaler.underscan.vborder;
>   u32 r = (asyh->view.oH << 19) / asyh->view.oW;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index 1991bbb1d05c..2ef5fb8df4ed 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -1012,7 +1012,7 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
>   unsigned duallink_scale =
>   nouveau_duallink && nv_encoder->dcb->duallink_possible ? 2 : 1;
>  
> - if (drm_detect_hdmi_monitor(nv_connector->edid)) {
> + if (nv_connector->base.display_info.is_hdmi) {
>   info = _connector->base.display_info;
>   duallink_scale = 1;
>   }

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



Re: [RFC PATCH v3 04/17] drm/i915: Implement bind and unbind of object

2022-09-01 Thread Niranjana Vishwanathapura

On Thu, Sep 01, 2022 at 03:31:13PM +1000, Dave Airlie wrote:

On Sun, 28 Aug 2022 at 05:45, Andi Shyti  wrote:


From: Niranjana Vishwanathapura 

Implement the bind and unbind of an object at the specified GPU virtual
addresses.

Signed-off-by: Niranjana Vishwanathapura 
Signed-off-by: Prathap Kumar Valsan 
Signed-off-by: Ramalingam C 
Signed-off-by: Andi Shyti 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h   |  21 ++
 .../drm/i915/gem/i915_gem_vm_bind_object.c| 322 ++
 drivers/gpu/drm/i915/gt/intel_gtt.c   |  10 +
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   9 +
 drivers/gpu/drm/i915/i915_driver.c|   1 +
 drivers/gpu/drm/i915/i915_vma.c   |   3 +-
 drivers/gpu/drm/i915/i915_vma.h   |   2 -
 drivers/gpu/drm/i915/i915_vma_types.h |  14 +
 include/uapi/drm/i915_drm.h   | 163 +
 10 files changed, 543 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind.h
 create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_vm_bind_object.c






diff --git a/drivers/gpu/drm/i915/i915_vma_types.h 
b/drivers/gpu/drm/i915/i915_vma_types.h
index be6e028c3b57d..f746fecae85ed 100644
--- a/drivers/gpu/drm/i915/i915_vma_types.h
+++ b/drivers/gpu/drm/i915/i915_vma_types.h
@@ -289,6 +289,20 @@ struct i915_vma {
/** This object's place on the active/inactive lists */
struct list_head vm_link;

+   /** @vm_bind_link: node for the vm_bind related lists of vm */
+   struct list_head vm_bind_link;
+
+   /** Interval tree structures for persistent vma */
+
+   /** @rb: node for the interval tree of vm for persistent vmas */
+   struct rb_node rb;
+   /** @start: start endpoint of the rb node */
+   u64 start;
+   /** @last: Last endpoint of the rb node */
+   u64 last;
+   /** @__subtree_last: last in subtree */
+   u64 __subtree_last;


Was a drm_mm node considered for this or was it overkill?



We already have a drm_mm node (i915_vma.node). But currently in i915
driver, VA managment and binding of vmas are tightly coupled.
Ideally we want to decouple it and then use the same drm_mm node for
persistent vma lookup as well, instead of this new interval tree.
But decouple it is not trivial I think it needs to be carefully
done in a separate patch series to not cause any regression.

The new interval/rb tree here is an optimization for fast lookup of
persistent vma (instead of list walk) whether it is bound or not.
Eventually though, with above cleanup we should be able to use the
i915_vma.node for vma lookup (even when it is not bound).

I was briefly discussed in earlier version of this series (though topic
was different there).
https://lists.freedesktop.org/archives/intel-gfx/2022-July/301159.html

Niranjana


Dave.


Re: [Freedreno] [PATCH v6 2/6] clk: qcom: Allow custom reset ops

2022-09-01 Thread Akhil P Oommen

On 9/1/2022 3:47 PM, Philipp Zabel wrote:

Hi Akhil,

On Wed, Aug 31, 2022 at 10:48:23AM +0530, Akhil P Oommen wrote:

Allow soc specific clk drivers to specify a custom reset operation. We
will use this in an upcoming patch to allow gpucc driver to specify a
differet reset operation for cx_gdsc.

Signed-off-by: Akhil P Oommen 
Reviewed-by: Dmitry Baryshkov 
---

(no changes since v3)

Changes in v3:
- Use pointer to const for "struct qcom_reset_ops" in qcom_reset_map (Krzysztof)

Changes in v2:
- Return error when a particular custom reset op is not implemented. (Dmitry)

  drivers/clk/qcom/reset.c | 27 +++
  drivers/clk/qcom/reset.h |  8 
  2 files changed, 35 insertions(+)

diff --git a/drivers/clk/qcom/reset.c b/drivers/clk/qcom/reset.c
index 819d194..b7ae4a3 100644
--- a/drivers/clk/qcom/reset.c
+++ b/drivers/clk/qcom/reset.c
@@ -13,6 +13,21 @@
  
  static int qcom_reset(struct reset_controller_dev *rcdev, unsigned long id)

  {
+   struct qcom_reset_controller *rst;
+   const struct qcom_reset_map *map;
+
+   rst = to_qcom_reset_controller(rcdev);
+   map = >reset_map[id];
+
+   if (map->ops && map->ops->reset)
+   return map->ops->reset(map->priv);
+   /*
+* If custom ops is implemented but just not this callback, return
+* error
+*/
+   else if (map->ops)
+   return -EOPNOTSUPP;
+

It doesn't seem necessary to stack reset_ops -> qcom_reset_ops for what
you need here.
Just add an optional const struct reset_ops * to qcom_cc_desc and feed
that into qcom_cc_really_probe to replace _reset_ops.

[...]

+struct qcom_reset_ops {
+   int (*reset)(void *priv);
+   int (*assert)(void *priv);
+   int (*deassert)(void *priv);

Why add assert and deassert ops? There doesn't seem to be any user.
I had a more minimal implementation in v1. But this makes it more 
complete and make it less prone to trip up ourselves in future.



+};
+
  struct qcom_reset_map {
unsigned int reg;
u8 bit;
+   const struct qcom_reset_ops *ops;
+   void *priv;

Adding per-reset ops + priv counters seems excessive to me.

Are you expecting different reset controls in the same reset controller
to have completely different ops at some point? If so, I would wonder
whether it wouldn't be better to split the reset controller in that
case. Either way, for the GDSC collapse workaround this does not seem
to be required at all.
Yes, like I responded in patch 4, we need different ops for the same 
reset controller in some gpucc implementations.
For eg: 
https://elixir.bootlin.com/linux/v6.0-rc3/source/drivers/clk/qcom/gpucc-sdm660.c


-Akhil


regards
Philipp




Re: [Freedreno] [PATCH v6 4/6] clk: qcom: gpucc-sc7280: Add cx collapse reset support

2022-09-01 Thread Akhil P Oommen

On 9/1/2022 4:16 PM, Dmitry Baryshkov wrote:

On 01/09/2022 13:34, Philipp Zabel wrote:

On Wed, Aug 31, 2022 at 10:48:25AM +0530, Akhil P Oommen wrote:

Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.

Signed-off-by: Akhil P Oommen 
Reviewed-by: Dmitry Baryshkov 
---

(no changes since v3)

Changes in v3:
- Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' 
(Krzysztof)


Changes in v2:
- Minor update to use the updated custom reset ops implementation

  drivers/clk/qcom/gpucc-sc7280.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/clk/qcom/gpucc-sc7280.c 
b/drivers/clk/qcom/gpucc-sc7280.c

index 9a832f2..fece3f4 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -433,12 +433,22 @@ static const struct regmap_config 
gpu_cc_sc7280_regmap_config = {

  .fast_io = true,
  };
  +static const struct qcom_reset_ops cx_gdsc_reset = {
+    .reset = gdsc_wait_for_collapse,


This should be accompanied by a comment explaining the not-quite-reset
nature of this workaround, i.e. what is the prerequisite for this to
actually work as expected?


+};
+
+static const struct qcom_reset_map gpucc_sc7280_resets[] = {
+    [GPU_CX_COLLAPSE] = { .ops = _gdsc_reset, .priv = _gdsc },
+};
+
  static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
  .config = _cc_sc7280_regmap_config,
  .clks = gpu_cc_sc7280_clocks,
  .num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
  .gdscs = gpu_cc_sc7180_gdscs,
  .num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
+    .resets = gpucc_sc7280_resets,
+    .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),


See my comment on patch 2. I think instead of adding a const struct
qcom_reset_ops * to gpucc_sc7280_resets, this should just add a const
struct reset_control * to gpu_cc_sc7280_desc.


While this will work for the sc7280, the platform that Akhil was 
developing, this will not work for other platforms (like sm8250), 
where the dispcc also provides traditional BCR resets.


Like Dimtry mentioned, we should eventually implement this feature on 
all gpucc drivers and some of them already use the existing reset ops. 
The current implementation creates the least code churn and duplication's.


-Akhil


Re: [PATCH v2 00/41] drm: Analog TV Improvements

2022-09-01 Thread Noralf Trønnes



Den 29.08.2022 15.11, skrev Maxime Ripard:
> Hi,
> 
> 
> 
> Here's a series aiming at improving the command line named modes support,
> 
> and more importantly how we deal with all the analog TV variants.
> 
> 
> 
> The named modes support were initially introduced to allow to specify the
> 
> analog TV mode to be used.
> 
> 
> 
> However, this was causing multiple issues:
> 
> 
> 
>   * The mode name parsed on the command line was passed directly to the
> 
> driver, which had to figure out which mode it was suppose to match;
> 
> 
> 
>   * Figuring that out wasn't really easy, since the video= argument or what
> 
> the userspace might not even have a name in the first place, but
> 
> instead could have passed a mode with the same timings;
> 
> 
> 
>   * The fallback to matching on the timings was mostly working as long as
> 
> we were supporting one 525 lines (most likely NSTC) and one 625 lines
> 
> (PAL), but couldn't differentiate between two modes with the same
> 
> timings (NTSC vs PAL-M vs NSTC-J for example);
> 
> 
> 
>   * There was also some overlap with the tv mode property registered by
> 
> drm_mode_create_tv_properties(), but named modes weren't interacting
> 
> with that property at all.
> 
> 
> 
>   * Even though that property was generic, its possible values were
> 
> specific to each drivers, which made some generic support difficult.
> 
> 
> 
> Thus, I chose to tackle in multiple steps:
> 
> 
> 
>   * A new TV norm property was introduced, with generic values, each driver
> 
> reporting through a bitmask what standard it supports to the userspace;
> 
> 
> 
>   * This option was added to the command line parsing code to be able to
> 
> specify it on the kernel command line, and new atomic_check and reset
> 
> helpers were created to integrate properly into atomic KMS;
> 
> 
> 
>   * The named mode parsing code is now creating a proper display mode for
> 
> the given named mode, and the TV standard will thus be part of the
> 
> connector state;
> 
> 
> 
>   * Two drivers were converted and tested for now (vc4 and sun4i), with
> 
> some backward compatibility code to translate the old TV mode to the
> 
> new TV mode;
> 
> 
> 
> Unit tests were created along the way.
> 
> 
> 
> One can switch from NTSC to PAL now using (on vc4)
> 
> 
> 
> modetest -M vc4  -s 53:720x480i -w 53:'tv norm':0
> 
> 
> 
> modetest -M vc4 -s 53:720x480i -w 53:'tv norm':4
> 

The property name has changed, this gives me PAL:

$ modetest -M vc4 -s 45:720x576i -w 45:'TV mode':4


I have finally found a workaround for my kernel hangs.

Dom had a look at my kernel and found that the VideoCore was fine, and
he said this:

> That suggests cause of lockup was on arm side rather than VC side.
>
> But it's hard to diagnose further. Once you've had a peripheral not
> respond, the AXI bus locks up and no further operations are possible.
> Usual causes of this are required clocks being stopped or domains
> disabled and then trying to access the hardware.
>

So when I got this on my 64-bit build:

[  166.702171] SError Interrupt on CPU1, code 0xbf02 -- SError
[  166.702187] CPU: 1 PID: 8 Comm: kworker/u8:0 Tainted: GW
5.19.0-rc6-00096-gba7973977976-dirty #1
[  166.702200] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)
[  166.702206] Workqueue: events_freezable_power_ thermal_zone_device_check
[  166.702231] pstate: 20c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[  166.702242] pc : regmap_mmio_read32le+0x10/0x28
[  166.702261] lr : regmap_mmio_read+0x44/0x70
...
[  166.702606]  bcm2711_get_temp+0x58/0xb0 [bcm2711_thermal]

I wondered if that reg read was stalled due to a clock being stopped.

Lo and behold, disabling runtime pm and keeping the vec clock running
all the time fixed it[1].

I don't know what the problem is, but at least I can now test this patchset.

[1] https://gist.github.com/notro/23b984e7fa05cfbda2db50a421cac065

Noralf.


Re: [PATCH] kernel/panic: Drop unblank_screen call

2022-09-01 Thread Daniel Vetter
On Thu, 1 Sept 2022 at 13:35, Petr Mladek  wrote:
>
> On Tue 2022-08-30 16:50:04, Daniel Vetter wrote:
> > console_unblank() does this too (called in both places right after),
> > and with a lot more confidence inspiring approach to locking.
> >
> > Reconstructing this story is very strange:
> >
> > In b61312d353da ("oops handling: ensure that any oops is flushed to
> > the mtdoops console") it is claimed that a printk(" "); flushed out
> > the console buffer, which was removed in e3e8a75d2acf ("[PATCH]
> > Extract and use wake_up_klogd()"). In todays kernels this is done way
> > earlier in console_flush_on_panic with some really nasty tricks. I
> > didn't bother to fully reconstruct this all, least because the call to
> > bust_spinlock(0); gets moved every few years, depending upon how the
> > wind blows (or well, who screamed loudest about the various issue each
> > call site caused).
> >
> > Before that commit the only calls to console_unblank() where in s390
> > arch code.
> >
> > The other side here is the console->unblank callback, which was
> > introduced in 2.1.31 for the vt driver. Which predates the
> > console_unblank() function by a lot, which was added (without users)
> > in 2.4.14.3. So pretty much impossible to guess at any motivation
> > here. Also afaict the vt driver is the only (and always was the only)
> > console driver implementing the unblank callback, so no idea why a
> > call to console_unblank() was added for the mtdooops driver - the
> > action actually flushing out the console buffers is done from
> > console_unlock() only.
>
> My understanding is that mtdoops is not a real console. The commit
> 4b23aff083649eafa141 ("[MTD] oops and panic message logging to MTD
> device") suggests that it was just (mis)using the console
> infrastructure.
>
> The commit 2e386e4bac90554887e73d ("mtd: mtdoops: refactor as a
> kmsg_dumper") converted it to use the new kmsg_dumper API that
> was created for this use case.
>
> So, I would consider all the mtdoops-related changes as a misuse
> of the console API.

Ah, that's a good piece of information that I didn't figure out.

Greg, if you haven't baked in the patch yet, can you perhaps add the
above information from Petr to the commit message?

Thanks, Daniel

>
>
> > Note that as prep for the s390 users the locking was adjusted in
> > 2.5.22 (I couldn't figure out how to properly reference the BK commit
> > from the historical git trees) from a normal semaphore to a trylock.
> >
> > Note that a copy of the direct unblank_screen() call was added to
> > panic() in c7c3f05e341a ("panic: avoid deadlocks in re-entrant console
> > drivers"), which partially inlined the bust_spinlocks(0); call.
> >
> > Long story short, I have no idea why the direct call to unblank_screen
> > survived for so long (the infrastructure to do it properly existed for
> > years), nor why it wasn't removed when the console_unblank() call was
> > finally added. But it makes a ton more sense to finally do that than
> > not - it's just better encapsulation to go through the console
> > functions instead of doing a direct call, so let's dare. Plus it
> > really does not make much sense to call the only unblank
> > implementation there is twice, once without, and once with appropriate
> > locking.
> >
> > Signed-off-by: Daniel Vetter 
>
> Nice analyze. The change makes perfect sense from my POV:
>
> Reviewed-by: Petr Mladek 
>
> Best Regards,
> Petr



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


Re: [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes

2022-09-01 Thread Noralf Trønnes



Den 29.08.2022 15.11, skrev Maxime Ripard:
> Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
> 
> 625-lines modes in their drivers.
> 
> 
> 
> Since those modes are fairly standard, and that we'll need to use them
> 
> in more places in the future, it makes sense to move their definition
> 
> into the core framework.
> 
> 
> 
> However, analog display usually have fairly loose timings requirements,
> 
> the only discrete parameters being the total number of lines and pixel
> 
> clock frequency. Thus, we created a function that will create a display
> 
> mode from the standard, the pixel frequency and the active area.
> 
> 
> 
> Signed-off-by: Maxime Ripard 
> 

On a 32-bit build I'm getting bogus modes:

[  249.57] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:45:Composite-1]
[  249.600198] [drm:drm_mode_debug_printmodeline] Modeline "720x480i":
17143 13500 720 308 372 3 480 499 505 525 0x40 0x1a
[  249.600292] [drm:drm_mode_prune_invalid] Not using 720x480i mode:
H_ILLEGAL
[  249.600317] [drm:drm_mode_debug_printmodeline] Modeline "720x576i": 0
13500 720 302 366 0 576 597 603 625 0x40 0x1a
[  249.600349] [drm:drm_mode_prune_invalid] Not using 720x576i mode:
H_ILLEGAL
[  249.600374] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:45:Composite-1] probed modes :
[  249.600453] [drm:drm_mode_debug_printmodeline] Modeline "720x240i":
60 27800 720 736 808 896 240 241 244 516 0x20 0x6

It's fine on 64-bit.

Noralf.

> 
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> 
> index 304004fb80aa..ee581ee17171 100644
> 
> --- a/drivers/gpu/drm/drm_modes.c
> 
> +++ b/drivers/gpu/drm/drm_modes.c
> 
> @@ -116,6 +116,459 @@ void drm_mode_probed_add(struct drm_connector 
> *connector,
> 
>  }
> 
>  EXPORT_SYMBOL(drm_mode_probed_add);
> 
>  
> 
> +enum drm_mode_analog {
> 
> + DRM_MODE_ANALOG_NTSC,
> 
> + DRM_MODE_ANALOG_PAL,
> 
> +};
> 
> +
> 
> +/*
> 
> + * The timings come from:
> 
> + * - 
> https://web.archive.org/web/20220406232708/http://www.kolumbus.fi/pami1/video/pal_ntsc.html
> 
> + * - 
> https://web.archive.org/web/20220406124914/http://martin.hinner.info/vga/pal.html
> 
> + * - 
> https://web.archive.org/web/20220609202433/http://www.batsocks.co.uk/readme/video_timing.htm
> 
> + */
> 
> +#define NTSC_LINE_DURATION_NS63556U
> 
> +#define NTSC_LINES_NUMBER525
> 
> +
> 
> +#define NTSC_HBLK_DURATION_TYP_NS10900U
> 
> +#define NTSC_HBLK_DURATION_MIN_NS(NTSC_HBLK_DURATION_TYP_NS - 200)
> 
> +#define NTSC_HBLK_DURATION_MAX_NS(NTSC_HBLK_DURATION_TYP_NS + 200)
> 
> +
> 
> +#define NTSC_HACT_DURATION_TYP_NS(NTSC_LINE_DURATION_NS - 
> NTSC_HBLK_DURATION_TYP_NS)
> 
> +#define NTSC_HACT_DURATION_MIN_NS(NTSC_LINE_DURATION_NS - 
> NTSC_HBLK_DURATION_MAX_NS)
> 
> +#define NTSC_HACT_DURATION_MAX_NS(NTSC_LINE_DURATION_NS - 
> NTSC_HBLK_DURATION_MIN_NS)
> 
> +
> 
> +#define NTSC_HFP_DURATION_TYP_NS 1500
> 
> +#define NTSC_HFP_DURATION_MIN_NS 1270
> 
> +#define NTSC_HFP_DURATION_MAX_NS 2220
> 
> +
> 
> +#define NTSC_HSLEN_DURATION_TYP_NS   4700
> 
> +#define NTSC_HSLEN_DURATION_MIN_NS   (NTSC_HSLEN_DURATION_TYP_NS - 100)
> 
> +#define NTSC_HSLEN_DURATION_MAX_NS   (NTSC_HSLEN_DURATION_TYP_NS + 100)
> 
> +
> 
> +#define NTSC_HBP_DURATION_TYP_NS 4700
> 
> +
> 
> +/*
> 
> + * I couldn't find the actual tolerance for the back porch, so let's
> 
> + * just reuse the sync length ones.
> 
> + */
> 
> +#define NTSC_HBP_DURATION_MIN_NS (NTSC_HBP_DURATION_TYP_NS - 100)
> 
> +#define NTSC_HBP_DURATION_MAX_NS (NTSC_HBP_DURATION_TYP_NS + 100)
> 
> +
> 
> +#define PAL_LINE_DURATION_NS 64000U
> 
> +#define PAL_LINES_NUMBER 625
> 
> +
> 
> +#define PAL_HACT_DURATION_TYP_NS 51950U
> 
> +#define PAL_HACT_DURATION_MIN_NS (PAL_HACT_DURATION_TYP_NS - 100)
> 
> +#define PAL_HACT_DURATION_MAX_NS (PAL_HACT_DURATION_TYP_NS + 400)
> 
> +
> 
> +#define PAL_HBLK_DURATION_TYP_NS (PAL_LINE_DURATION_NS - 
> PAL_HACT_DURATION_TYP_NS)
> 
> +#define PAL_HBLK_DURATION_MIN_NS (PAL_LINE_DURATION_NS - 
> PAL_HACT_DURATION_MAX_NS)
> 
> +#define PAL_HBLK_DURATION_MAX_NS (PAL_LINE_DURATION_NS - 
> PAL_HACT_DURATION_MIN_NS)
> 
> +
> 
> +#define PAL_HFP_DURATION_TYP_NS  1650
> 
> +#define PAL_HFP_DURATION_MIN_NS  (PAL_HFP_DURATION_TYP_NS - 100)
> 
> +#define PAL_HFP_DURATION_MAX_NS  (PAL_HFP_DURATION_TYP_NS + 400)
> 
> +
> 
> +#define PAL_HSLEN_DURATION_TYP_NS4700
> 
> +#define PAL_HSLEN_DURATION_MIN_NS(PAL_HSLEN_DURATION_TYP_NS - 200)
> 
> +#define PAL_HSLEN_DURATION_MAX_NS(PAL_HSLEN_DURATION_TYP_NS + 200)
> 
> +
> 
> +#define PAL_HBP_DURATION_TYP_NS  5700
> 
> +#define PAL_HBP_DURATION_MIN_NS  (PAL_HBP_DURATION_TYP_NS - 200)
> 
> +#define PAL_HBP_DURATION_MAX_NS  (PAL_HBP_DURATION_TYP_NS + 200)
> 
> +
> 
> +#define PAL_VFP_INTERLACE_LINES  5
> 
> +#define 

[PATCH] drm/i915: Rename ggtt_view as gtt_view

2022-09-01 Thread Niranjana Vishwanathapura
So far, different views (normal, partial, rotated and remapped)
into the same object are only supported for GGTT mappings.
But with the upcoming VM_BIND feature, PPGTT will also use the
partial view mapping. Hence rename ggtt_view to more generic
gtt_view.

Signed-off-by: Niranjana Vishwanathapura 
---
 drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
 drivers/gpu/drm/i915/display/intel_display.h  |  2 +-
 .../drm/i915/display/intel_display_types.h|  2 +-
 drivers/gpu/drm/i915/display/intel_fb.c   | 18 ++---
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |  4 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.h   |  4 +-
 drivers/gpu/drm/i915/display/intel_fbdev.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c|  4 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  | 16 ++---
 drivers/gpu/drm/i915/gem/i915_gem_object.h|  2 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  4 +-
 drivers/gpu/drm/i915/gt/intel_reset.c |  2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   | 56 +++
 drivers/gpu/drm/i915/i915_drv.h   |  4 +-
 drivers/gpu/drm/i915/i915_gem.c   |  6 +-
 drivers/gpu/drm/i915/i915_vma.c   | 40 +--
 drivers/gpu/drm/i915/i915_vma.h   | 18 ++---
 drivers/gpu/drm/i915/i915_vma_types.h | 42 ++--
 drivers/gpu/drm/i915/selftests/i915_vma.c | 68 +--
 19 files changed, 149 insertions(+), 149 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index be7cff722196..8251f87064f6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -670,7 +670,7 @@ bool intel_plane_uses_fence(const struct intel_plane_state 
*plane_state)
 
return DISPLAY_VER(dev_priv) < 4 ||
(plane->fbc &&
-plane_state->view.gtt.type == I915_GGTT_VIEW_NORMAL);
+plane_state->view.gtt.type == I915_GTT_VIEW_NORMAL);
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index e895277c4cd9..e322011877bb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -45,7 +45,7 @@ struct drm_modeset_acquire_ctx;
 struct drm_plane;
 struct drm_plane_state;
 struct i915_address_space;
-struct i915_ggtt_view;
+struct i915_gtt_view;
 struct intel_atomic_state;
 struct intel_crtc;
 struct intel_crtc_state;
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..01977cd237eb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -105,7 +105,7 @@ struct intel_fb_view {
 * In the normal view the FB object's backing store sg list is used
 * directly and hence the remap information here is not used.
 */
-   struct i915_ggtt_view gtt;
+   struct i915_gtt_view gtt;
 
/*
 * The GTT view (gtt.type) specific information for each FB color
diff --git a/drivers/gpu/drm/i915/display/intel_fb.c 
b/drivers/gpu/drm/i915/display/intel_fb.c
index b191915ab351..eefa33c555ac 100644
--- a/drivers/gpu/drm/i915/display/intel_fb.c
+++ b/drivers/gpu/drm/i915/display/intel_fb.c
@@ -1395,7 +1395,7 @@ static u32 calc_plane_remap_info(const struct 
intel_framebuffer *fb, int color_p
   plane_view_height_tiles(fb, color_plane, dims, 
y));
}
 
-   if (view->gtt.type == I915_GGTT_VIEW_ROTATED) {
+   if (view->gtt.type == I915_GTT_VIEW_ROTATED) {
drm_WARN_ON(>drm, remap_info->linear);
check_array_bounds(i915, view->gtt.rotated.plane, color_plane);
 
@@ -1420,7 +1420,7 @@ static u32 calc_plane_remap_info(const struct 
intel_framebuffer *fb, int color_p
/* rotate the tile dimensions to match the GTT view */
swap(tile_width, tile_height);
} else {
-   drm_WARN_ON(>drm, view->gtt.type != 
I915_GGTT_VIEW_REMAPPED);
+   drm_WARN_ON(>drm, view->gtt.type != 
I915_GTT_VIEW_REMAPPED);
 
check_array_bounds(i915, view->gtt.remapped.plane, color_plane);
 
@@ -1503,12 +1503,12 @@ calc_plane_normal_size(const struct intel_framebuffer 
*fb, int color_plane,
 }
 
 static void intel_fb_view_init(struct drm_i915_private *i915, struct 
intel_fb_view *view,
-  enum i915_ggtt_view_type view_type)
+  enum i915_gtt_view_type view_type)
 {
memset(view, 0, sizeof(*view));
view->gtt.type = view_type;
 
-   if (view_type == I915_GGTT_VIEW_REMAPPED && IS_ALDERLAKE_P(i915))
+   if (view_type == I915_GTT_VIEW_REMAPPED && IS_ALDERLAKE_P(i915))
view->gtt.remapped.plane_alignment = SZ_2M / PAGE_SIZE;
 }
 
@@ -1530,16 +1530,16 @@ int intel_fill_fb_info(struct 

Re: [PATCH 1/3] drm/i915: audit bo->resource usage

2022-09-01 Thread Thomas Hellström
On Wed, 2022-08-31 at 15:34 +0200, Christian König wrote:
> Am 31.08.22 um 14:50 schrieb Matthew Auld:
> > On 31/08/2022 13:35, Christian König wrote:
> > > Am 31.08.22 um 14:06 schrieb Matthew Auld:
> > > > On 31/08/2022 12:03, Christian König wrote:
> > > > > Am 31.08.22 um 12:37 schrieb Matthew Auld:
> > > > > > [SNIP]
> > > > > > > > 
> > > > > > > > That hopefully just leaves i915_ttm_shrink(), which is
> > > > > > > > swapping 
> > > > > > > > out shmem ttm_tt and is calling ttm_bo_validate() with
> > > > > > > > empty 
> > > > > > > > placements to force the pipeline-gutting path, which
> > > > > > > > importantly 
> > > > > > > > unpopulates the ttm_tt for us (since ttm_tt_unpopulate
> > > > > > > > is not 
> > > > > > > > exported it seems). But AFAICT it looks like that will
> > > > > > > > now also 
> > > > > > > > nuke the bo->resource, instead of just leaving it in
> > > > > > > > system 
> > > > > > > > memory. My assumption is that when later calling 
> > > > > > > > ttm_bo_validate(), it will just do the bo_move_null()
> > > > > > > > in 
> > > > > > > > i915_ttm_move(), instead of re-populating the ttm_tt
> > > > > > > > and then 
> > > > > > > > potentially copying it back to local-memory?
> > > > > > > 
> > > > > > > Well you do ttm_bo_validate() with something like GTT
> > > > > > > domain, 
> > > > > > > don't you? This should result in re-populating the tt
> > > > > > > object, but 
> > > > > > > I'm not 100% sure if that really works as expected.
> > > > > > 
> > > > > > AFAIK for domains we either have system memory (which uses
> > > > > > ttm_tt 
> > > > > > and might be shmem underneath) or local-memory. But perhaps
> > > > > > i915 
> > > > > > is doing something wrong here, or abusing TTM in some way.
> > > > > > I'm not 
> > > > > > sure tbh.
> > > > > > 
> > > > > > Anyway, I think we have two cases here:
> > > > > > 
> > > > > > - We have some system memory only object. After doing 
> > > > > > i915_ttm_shrink(), bo->resource is now NULL. We then call 
> > > > > > ttm_bo_validate() at some later point, but here we don't
> > > > > > need to 
> > > > > > copy anything, but it also looks like
> > > > > > ttm_bo_handle_move_mem() 
> > > > > > won't populate the ttm_tt or us either, since mem_type == 
> > > > > > TTM_PL_SYSTEM. It looks like i915_ttm_move() was taking
> > > > > > care of 
> > > > > > this, but now we just call ttm_bo_move_null().
> > > > > > 
> > > > > > - We have a local-memory only object, which was evicted to
> > > > > > shmem, 
> > > > > > and then swapped out by the shrinker like above. The bo-
> > > > > > >resource 
> > > > > > is NULL. However this time when calling ttm_bo_validate()
> > > > > > we need 
> > > > > > to actually do a copy in i915_ttm_move(), as well as re-
> > > > > > populate 
> > > > > > the ttm_tt. i915_ttm_move() was taking care of this, but
> > > > > > now we 
> > > > > > just call ttm_bo_move_null().
> > > > > > 
> > > > > > Perhaps i915 is doing something wrong in the above two
> > > > > > cases?
> > > > > 
> > > > > Mhm, as far as I can see that should still work.
> > > > > 
> > > > > See previously you should got a transition from SYSTEM->GTT
> > > > > in 
> > > > > i915_ttm_move() to re-create your backing store. Not you get 
> > > > > NULL->SYSTEM which is handled by ttm_bo_move_null() and then 
> > > > > SYSTEM->GTT.
> > > > 
> > > > What is GTT here in TTM world? Also I'm not seeing where there
> > > > is 
> > > > this SYSTEM->GTT transition? Maybe I'm blind. Just to be clear,
> > > > i915 
> > > > is only calling ttm_bo_validate() once when acquiring the
> > > > pages, and 
> > > > we don't call it again, unless it was evicted (and potentially 
> > > > swapped out).
> > > 
> > > Well GTT means TTM_PL_TT.
> > > 
> > > And calling it only once is perfectly fine, TTM will internally
> > > see 
> > > that we need two hops to reach TTM_PL_TT and so does the NULL-
> > > >SYSTEM 
> > > transition and then SYSTEM->TT.
> > 
> > Ah interesting, so that's what the multi-hop thing does. But AFAICT
> > i915 is not using either TTM_PL_TT or -EMULTIHOP.
> 
> Mhm, it could be that we then have a problem and the i915 driver only
> sees NULL->TT directly. But I really don't know the i915 driver code 
> good enough to judge that.
> 
> Can you take a look at this and test it maybe?
> 
> > 
> > Also what is the difference between TTM_PL_TT and TM_PL_SYSTEM?
> > When 
> > should you use one over the other?
> 
> TTM_PL_SYSTEM means the device is not accessing the buffer and TTM
> has 
> the control over the backing store and can swapout/swapin as it wants
> it.
> 
> TTM_PL_TT means that the device is accessing the data (TT stands for 
> translation table) and so TTM can't swap the backing store in/out.
> 
> TTM_PL_VRAM well that one is obvious.
> 
> Thanks,
> Christian.

We've had a previous long discussions on this listing pros and cons,
and IIRC concluded that either binding to the device from system needed
some TTM fixes and documentation to be 

Re: [Intel-gfx] [PATCH] drm/i915/ttm: Abort suspend on i915_ttm_backup failure

2022-09-01 Thread Das, Nirmoy



On 9/1/2022 5:57 PM, Andrzej Hajda wrote:

On 31.08.2022 18:18, Nirmoy Das wrote:

On system suspend when system memory is low then i915_gem_obj_copy_ttm()
could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough,
suspend shouldn't continue if i915_ttm_backup() throws an error.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6529
Reviewed-by: Matthew Auld 
Suggested-by: Chris P Wilson 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c

index 9aad84059d56..6f5d5c0909b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -79,7 +79,12 @@ static int i915_ttm_backup(struct 
i915_gem_apply_to_region *apply,

  goto out_no_populate;
    err = i915_gem_obj_copy_ttm(backup, obj, pm_apply->allow_gpu, 
false);

-    GEM_WARN_ON(err);
+    if (err) {
+    drm_err(>drm,
+    "Unable to copy from device to system memory, err:%d\n",
+    err);


I wonder if %pe wouldn't be better here, up to you.



More readable err should be useful, resend with %pe.



Reviewed-by: Andrzej Hajda 



Thanks,

Nirmoy



Regards
Andrzej



+    goto out_no_populate;
+    }
  ttm_bo_wait_ctx(backup_bo, );
    obj->ttm.backup = backup;




[PATCH v3] drm/i915/ttm: Abort suspend on i915_ttm_backup failure

2022-09-01 Thread Nirmoy Das
On system suspend when system memory is low then i915_gem_obj_copy_ttm()
could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough,
suspend shouldn't continue if i915_ttm_backup() throws an error.

v2: Keep the fdo issue till we have a igt test(Matt).
v3: Use %pe(Andrzej)

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6529
Reviewed-by: Matthew Auld 
Reviewed-by: Andrzej Hajda 
Suggested-by: Chris P Wilson 
Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index 9aad84059d56..07e49f22f2de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -79,7 +79,12 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region 
*apply,
goto out_no_populate;
 
err = i915_gem_obj_copy_ttm(backup, obj, pm_apply->allow_gpu, false);
-   GEM_WARN_ON(err);
+   if (err) {
+   drm_err(>drm,
+   "Unable to copy from device to system memory, 
err:%pe\n",
+   ERR_PTR(err));
+   goto out_no_populate;
+   }
ttm_bo_wait_ctx(backup_bo, );
 
obj->ttm.backup = backup;
-- 
2.35.1



Re: [Intel-gfx] [PATCH] drm/i915: prevent integer overflow in query_engine_info()

2022-09-01 Thread Andrzej Hajda

On 01.09.2022 17:38, Dan Carpenter wrote:

This code uses struct_size() but it stores the result in an int so the
integer overflow checks are not effective.  Record the types as size_t
to prevent the size from being truncated.

Fixes: bf3c50837506 ("drm/i915/query: Use struct_size() helper")
Signed-off-by: Dan Carpenter 


Reviewed-by: Andrzej Hajda 

Regards
Andrzej

---
I do not know if the integer overflow can happen.  This is a hardenning
patch just like the conversion to struct_size().

  drivers/gpu/drm/i915/i915_query.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 6ec9c9fb7b0d..43a499fbdc8d 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -13,7 +13,7 @@
  #include 
  
  static int copy_query_item(void *query_hdr, size_t query_sz,

-  u32 total_length,
+  size_t total_length,
   struct drm_i915_query_item *query_item)
  {
if (query_item->length == 0)
@@ -135,7 +135,8 @@ query_engine_info(struct drm_i915_private *i915,
struct drm_i915_engine_info info = { };
unsigned int num_uabi_engines = 0;
struct intel_engine_cs *engine;
-   int len, ret;
+   size_t len;
+   int ret;
  
  	if (query_item->flags)

return -EINVAL;




Re: [Intel-gfx] [PATCH] drm/i915/ttm: Abort suspend on i915_ttm_backup failure

2022-09-01 Thread Andrzej Hajda

On 31.08.2022 18:18, Nirmoy Das wrote:

On system suspend when system memory is low then i915_gem_obj_copy_ttm()
could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough,
suspend shouldn't continue if i915_ttm_backup() throws an error.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/6529
Reviewed-by: Matthew Auld 
Suggested-by: Chris P Wilson 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
index 9aad84059d56..6f5d5c0909b4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c
@@ -79,7 +79,12 @@ static int i915_ttm_backup(struct i915_gem_apply_to_region 
*apply,
goto out_no_populate;
  
  	err = i915_gem_obj_copy_ttm(backup, obj, pm_apply->allow_gpu, false);

-   GEM_WARN_ON(err);
+   if (err) {
+   drm_err(>drm,
+   "Unable to copy from device to system memory, err:%d\n",
+   err);


I wonder if %pe wouldn't be better here, up to you.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej



+   goto out_no_populate;
+   }
ttm_bo_wait_ctx(backup_bo, );
  
  	obj->ttm.backup = backup;




Re: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()

2022-09-01 Thread Rodrigo Siqueira Jordao




On 2022-09-01 10:15, Hamza Mahfooz wrote:

Address the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ 
clause does not guard... [-Wmisleading-indentation]
  3508 | if (update_type != UPDATE_TYPE_FAST)
   | ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
‘if’
  3510 | if (update_type != UPDATE_TYPE_FAST)
   | ^~

Signed-off-by: Hamza Mahfooz 
---
v2: implement feedback from Alvin
---
  drivers/gpu/drm/amd/display/dc/core/dc.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..9860bf38c547 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc,
  
  	if (update_type != UPDATE_TYPE_FAST)

dc->hwss.post_unlock_program_front_end(dc, context);
-   if (update_type != UPDATE_TYPE_FAST)
-   if (dc->hwss.commit_subvp_config)
-   dc->hwss.commit_subvp_config(dc, context);
+
+   if (update_type != UPDATE_TYPE_FAST)
+   if (dc->hwss.commit_subvp_config)
+   dc->hwss.commit_subvp_config(dc, context);
  
  	/* Since phantom pipe programming is moved to post_unlock_program_front_end,

 * move the SubVP lock to after the phantom pipes have been setup


Reviewed-by: Rodrigo Siqueira 
and applied to amd-staging-drm-next.

Thanks
Siqueira


[PATCH] drm/i915: prevent integer overflow in query_engine_info()

2022-09-01 Thread Dan Carpenter
This code uses struct_size() but it stores the result in an int so the
integer overflow checks are not effective.  Record the types as size_t
to prevent the size from being truncated.

Fixes: bf3c50837506 ("drm/i915/query: Use struct_size() helper")
Signed-off-by: Dan Carpenter 
---
I do not know if the integer overflow can happen.  This is a hardenning
patch just like the conversion to struct_size().

 drivers/gpu/drm/i915/i915_query.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index 6ec9c9fb7b0d..43a499fbdc8d 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -13,7 +13,7 @@
 #include 
 
 static int copy_query_item(void *query_hdr, size_t query_sz,
-  u32 total_length,
+  size_t total_length,
   struct drm_i915_query_item *query_item)
 {
if (query_item->length == 0)
@@ -135,7 +135,8 @@ query_engine_info(struct drm_i915_private *i915,
struct drm_i915_engine_info info = { };
unsigned int num_uabi_engines = 0;
struct intel_engine_cs *engine;
-   int len, ret;
+   size_t len;
+   int ret;
 
if (query_item->flags)
return -EINVAL;
-- 
2.35.1



Re: [PATCH v3 02/15] mei: add support to GSC extended header

2022-09-01 Thread Greg Kroah-Hartman
On Fri, Aug 19, 2022 at 03:53:22PM -0700, Daniele Ceraolo Spurio wrote:
> --- a/drivers/misc/mei/hw-me.c
> +++ b/drivers/misc/mei/hw-me.c
> @@ -590,7 +590,10 @@ static int mei_me_hbuf_write(struct mei_device *dev,
>   u32 dw_cnt;
>   int empty_slots;
>  
> - if (WARN_ON(!hdr || !data || hdr_len & 0x3))
> + if (WARN_ON(!hdr || hdr_len & 0x3))
> + return -EINVAL;
> +
> + if (WARN_ON(!data && data_len))

Do not add more WARN_ON() calls, please just handle this properly and do
not reboot people's machines for a coding error :(

thanks,

greg k-h


Re: [PATCH] drm: Simplify testing on UML with kunit.py

2022-09-01 Thread Maxime Ripard
On Thu, Sep 01, 2022 at 04:49:09PM +0200, Michał Winiarski wrote:
> On Thu, Sep 01, 2022 at 04:02:53PM +0200, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Sep 01, 2022 at 03:36:21PM +0200, Michał Winiarski wrote:
> > > DRM depends on IOMEM and DMA, introduce an additional Kconfig to pull in
> > > IOMEM and DMA emulation on UML.
> > > Since --kconfig_add usage is no longer needed, remove it from
> > > documentation.
> > > 
> > > Signed-off-by: Michał Winiarski 
> > > ---
> > >  Documentation/gpu/drm-internals.rst | 7 +--
> > >  drivers/video/Kconfig   | 4 
> > >  2 files changed, 5 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/Documentation/gpu/drm-internals.rst 
> > > b/Documentation/gpu/drm-internals.rst
> > > index 5fd20a306718..c264a9587d21 100644
> > > --- a/Documentation/gpu/drm-internals.rst
> > > +++ b/Documentation/gpu/drm-internals.rst
> > > @@ -228,16 +228,11 @@ follows:
> > >  
> > >  .. code-block:: bash
> > >  
> > > - $ ./tools/testing/kunit/kunit.py run 
> > > --kunitconfig=drivers/gpu/drm/tests \
> > > - --kconfig_add CONFIG_VIRTIO_UML=y \
> > > - --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
> > > + $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests
> > >  
> > >  .. note::
> > >   The configuration included in ``.kunitconfig`` should be as generic as
> > >   possible.
> > > - ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not
> > > - included in it because they are only required for User Mode Linux.
> > > -
> > 
> > I'm all for removing that part of the documentation, but because
> > 6fc3a8636a7b, in 6.0 should address this entirely? Why would we need
> > that other symbol?
> 
> We don't. I wasn't aware that 6fc3a8636a7b exists and had this one in my tree
> prior to 6.0.
> (well... technically we do need those other symbols and don't need VIRTIO, but
> since CONFIG_UML_PCI_OVER_VIRTIO pull in those two, it also works).
> Since docs were not updated, I didn't see any conflicts when rebasing.
> 
> Sorry for the noise, please ignore this patch.

I mean, the doc still isn't up to date, so please send that part of the
patch :)

Maxime


signature.asc
Description: PGP signature


Re: [PATCH] drm: Simplify testing on UML with kunit.py

2022-09-01 Thread Michał Winiarski
On Thu, Sep 01, 2022 at 04:02:53PM +0200, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Sep 01, 2022 at 03:36:21PM +0200, Michał Winiarski wrote:
> > DRM depends on IOMEM and DMA, introduce an additional Kconfig to pull in
> > IOMEM and DMA emulation on UML.
> > Since --kconfig_add usage is no longer needed, remove it from
> > documentation.
> > 
> > Signed-off-by: Michał Winiarski 
> > ---
> >  Documentation/gpu/drm-internals.rst | 7 +--
> >  drivers/video/Kconfig   | 4 
> >  2 files changed, 5 insertions(+), 6 deletions(-)
> > 
> > diff --git a/Documentation/gpu/drm-internals.rst 
> > b/Documentation/gpu/drm-internals.rst
> > index 5fd20a306718..c264a9587d21 100644
> > --- a/Documentation/gpu/drm-internals.rst
> > +++ b/Documentation/gpu/drm-internals.rst
> > @@ -228,16 +228,11 @@ follows:
> >  
> >  .. code-block:: bash
> >  
> > -   $ ./tools/testing/kunit/kunit.py run 
> > --kunitconfig=drivers/gpu/drm/tests \
> > -   --kconfig_add CONFIG_VIRTIO_UML=y \
> > -   --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
> > +   $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests
> >  
> >  .. note::
> > The configuration included in ``.kunitconfig`` should be as generic as
> > possible.
> > -   ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not
> > -   included in it because they are only required for User Mode Linux.
> > -
> 
> I'm all for removing that part of the documentation, but because
> 6fc3a8636a7b, in 6.0 should address this entirely? Why would we need
> that other symbol?

We don't. I wasn't aware that 6fc3a8636a7b exists and had this one in my tree
prior to 6.0.
(well... technically we do need those other symbols and don't need VIRTIO, but
since CONFIG_UML_PCI_OVER_VIRTIO pull in those two, it also works).
Since docs were not updated, I didn't see any conflicts when rebasing.

Sorry for the noise, please ignore this patch.

-Michał

> 
> Maxime




Re: [PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()

2022-09-01 Thread Deucher, Alexander
[Public]

Acked-by: Alex Deucher 

From: Mahfooz, Hamza 
Sent: Thursday, September 1, 2022 10:15 AM
To: linux-ker...@vger.kernel.org 
Cc: Mahfooz, Hamza ; Wentland, Harry 
; Li, Sun peng (Leo) ; Siqueira, 
Rodrigo ; Deucher, Alexander 
; Koenig, Christian ; Pan, 
Xinhui ; David Airlie ; Daniel Vetter 
; Kazlauskas, Nicholas ; Lei, Jun 
; Somasundaram, Meenakshikumar 
; Lee, Alvin ; Leung, 
Martin ; Tam, Samson ; Hung, Alex 
; Liu, Wenjing ; Aberback, Joshua 
; amd-...@lists.freedesktop.org 
; dri-devel@lists.freedesktop.org 

Subject: [PATCH v2] drm/amd/display: fix indentation in 
commit_planes_for_stream()

Address the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ 
clause does not guard... [-Wmisleading-indentation]
 3508 | if (update_type != UPDATE_TYPE_FAST)
  | ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
‘if’
 3510 | if (update_type != UPDATE_TYPE_FAST)
  | ^~

Signed-off-by: Hamza Mahfooz 
---
v2: implement feedback from Alvin
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..9860bf38c547 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc,

 if (update_type != UPDATE_TYPE_FAST)
 dc->hwss.post_unlock_program_front_end(dc, context);
-   if (update_type != UPDATE_TYPE_FAST)
-   if (dc->hwss.commit_subvp_config)
-   dc->hwss.commit_subvp_config(dc, context);
+
+   if (update_type != UPDATE_TYPE_FAST)
+   if (dc->hwss.commit_subvp_config)
+   dc->hwss.commit_subvp_config(dc, context);

 /* Since phantom pipe programming is moved to 
post_unlock_program_front_end,
  * move the SubVP lock to after the phantom pipes have been setup
--
2.37.2



[PATCH 0/4] RDMA/mlx5: Support DMABUF in umems and enable ATS

2022-09-01 Thread Jason Gunthorpe
This series adds support for DMABUF when creating a devx umem. devx umems
are quite similar to MR's execpt they cannot be revoked, so this uses the
dmabuf pinned memory flow. Several mlx5dv flows require umem and cannot
work with MR.

The intended use case is primarily for P2P transfers using dmabuf as a
handle to the underlying PCI BAR memory from the exporter. When a PCI
switch is present the P2P transfers can bypass the host bridge completely
and go directly through the switch. ATS allows this bypass to function in
more cases as translated TLPs issued after an ATS query allows the request
redirect setting to be bypassed in the switch.

Have mlx5 automatically use ATS in places where it makes sense.

Jason Gunthorpe (4):
  net/mlx5: Add IFC bits for mkey ATS
  RDMA/core: Add UVERBS_ATTR_RAW_FD
  RDMA/mlx5: Add support for dmabuf to devx umem
  RDMA/mlx5: Enable ATS support for MRs and umems

 drivers/infiniband/core/uverbs_ioctl.c   |  8 
 drivers/infiniband/hw/mlx5/devx.c| 55 +---
 drivers/infiniband/hw/mlx5/mlx5_ib.h | 36 
 drivers/infiniband/hw/mlx5/mr.c  |  5 ++-
 include/linux/mlx5/mlx5_ifc.h| 11 +++--
 include/rdma/uverbs_ioctl.h  | 13 ++
 include/uapi/rdma/mlx5_user_ioctl_cmds.h |  1 +
 7 files changed, 109 insertions(+), 20 deletions(-)


base-commit: b90cb1053190353cc30f0fef0ef1f378ccc063c5
-- 
2.37.2



[PATCH 1/4] net/mlx5: Add IFC bits for mkey ATS

2022-09-01 Thread Jason Gunthorpe
Allows telling a mkey to use PCI ATS for DMA that flows through it.

Signed-off-by: Jason Gunthorpe 
---
 include/linux/mlx5/mlx5_ifc.h | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index 4acd5610e96bc0..92602e33a82c42 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -1707,7 +1707,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 steering_format_version[0x4];
u8 create_qp_start_hint[0x18];
 
-   u8 reserved_at_460[0x3];
+   u8 reserved_at_460[0x1];
+   u8 ats[0x1];
+   u8 reserved_at_462[0x1];
u8 log_max_uctx[0x5];
u8 reserved_at_468[0x2];
u8 ipsec_offload[0x1];
@@ -3873,7 +3875,9 @@ struct mlx5_ifc_mkc_bits {
u8 lw[0x1];
u8 lr[0x1];
u8 access_mode_1_0[0x2];
-   u8 reserved_at_18[0x8];
+   u8 reserved_at_18[0x2];
+   u8 ma_translation_mode[0x2];
+   u8 reserved_at_1c[0x4];
 
u8 qpn[0x18];
u8 mkey_7_0[0x8];
@@ -11134,7 +11138,8 @@ struct mlx5_ifc_dealloc_memic_out_bits {
 struct mlx5_ifc_umem_bits {
u8 reserved_at_0[0x80];
 
-   u8 reserved_at_80[0x1b];
+   u8 ats[0x1];
+   u8 reserved_at_81[0x1a];
u8 log_page_size[0x5];
 
u8 page_offset[0x20];
-- 
2.37.2



[PATCH 4/4] RDMA/mlx5: Enable ATS support for MRs and umems

2022-09-01 Thread Jason Gunthorpe
For mlx5 if ATS is enabled in the PCI config then the device will use ATS
requests for only certain DMA operations. This has to be opted in by the
SW side based on the mkey or umem settings.

ATS slows down the PCI performance, so it should only be set in cases when
it is needed. All of these cases revolve around optimizing PCI P2P
transfers and avoiding bad cases where the bus just doesn't work.

Signed-off-by: Jason Gunthorpe 
---
 drivers/infiniband/hw/mlx5/devx.c| 37 
 drivers/infiniband/hw/mlx5/mlx5_ib.h | 36 +++
 drivers/infiniband/hw/mlx5/mr.c  |  5 +++-
 3 files changed, 61 insertions(+), 17 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/devx.c 
b/drivers/infiniband/hw/mlx5/devx.c
index 291e73d7928276..c900977e6ccdb7 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -2158,26 +2158,17 @@ static int 
UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_SUBSCRIBE_EVENT)(
 
 static int devx_umem_get(struct mlx5_ib_dev *dev, struct ib_ucontext *ucontext,
 struct uverbs_attr_bundle *attrs,
-struct devx_umem *obj)
+struct devx_umem *obj, u32 access_flags)
 {
u64 addr;
size_t size;
-   u32 access;
int err;
 
if (uverbs_copy_from(, attrs, MLX5_IB_ATTR_DEVX_UMEM_REG_ADDR) ||
uverbs_copy_from(, attrs, MLX5_IB_ATTR_DEVX_UMEM_REG_LEN))
return -EFAULT;
 
-   err = uverbs_get_flags32(, attrs,
-MLX5_IB_ATTR_DEVX_UMEM_REG_ACCESS,
-IB_ACCESS_LOCAL_WRITE |
-IB_ACCESS_REMOTE_WRITE |
-IB_ACCESS_REMOTE_READ);
-   if (err)
-   return err;
-
-   err = ib_check_mr_access(>ib_dev, access);
+   err = ib_check_mr_access(>ib_dev, access_flags);
if (err)
return err;
 
@@ -2191,12 +2182,12 @@ static int devx_umem_get(struct mlx5_ib_dev *dev, 
struct ib_ucontext *ucontext,
return -EFAULT;
 
umem_dmabuf = ib_umem_dmabuf_get_pinned(
-   >ib_dev, addr, size, dmabuf_fd, access);
+   >ib_dev, addr, size, dmabuf_fd, access_flags);
if (IS_ERR(umem_dmabuf))
return PTR_ERR(umem_dmabuf);
obj->umem = _dmabuf->umem;
} else {
-   obj->umem = ib_umem_get(>ib_dev, addr, size, access);
+   obj->umem = ib_umem_get(>ib_dev, addr, size, access_flags);
if (IS_ERR(obj->umem))
return PTR_ERR(obj->umem);
}
@@ -2238,7 +2229,8 @@ static unsigned int devx_umem_find_best_pgsize(struct 
ib_umem *umem,
 static int devx_umem_reg_cmd_alloc(struct mlx5_ib_dev *dev,
   struct uverbs_attr_bundle *attrs,
   struct devx_umem *obj,
-  struct devx_umem_reg_cmd *cmd)
+  struct devx_umem_reg_cmd *cmd,
+  int access)
 {
unsigned long pgsz_bitmap;
unsigned int page_size;
@@ -2287,6 +2279,9 @@ static int devx_umem_reg_cmd_alloc(struct mlx5_ib_dev 
*dev,
MLX5_SET(umem, umem, page_offset,
 ib_umem_dma_offset(obj->umem, page_size));
 
+   if (mlx5_umem_needs_ats(dev, obj->umem, access))
+   MLX5_SET(umem, umem, ats, 1);
+
mlx5_ib_populate_pas(obj->umem, page_size, mtt,
 (obj->umem->writable ? MLX5_IB_MTT_WRITE : 0) |
 MLX5_IB_MTT_READ);
@@ -2304,20 +2299,30 @@ static int UVERBS_HANDLER(MLX5_IB_METHOD_DEVX_UMEM_REG)(
struct mlx5_ib_ucontext *c = rdma_udata_to_drv_context(
>driver_udata, struct mlx5_ib_ucontext, ibucontext);
struct mlx5_ib_dev *dev = to_mdev(c->ibucontext.device);
+   int access_flags;
int err;
 
if (!c->devx_uid)
return -EINVAL;
 
+   err = uverbs_get_flags32(_flags, attrs,
+MLX5_IB_ATTR_DEVX_UMEM_REG_ACCESS,
+IB_ACCESS_LOCAL_WRITE |
+IB_ACCESS_REMOTE_WRITE |
+IB_ACCESS_REMOTE_READ |
+IB_ACCESS_RELAXED_ORDERING);
+   if (err)
+   return err;
+
obj = kzalloc(sizeof(struct devx_umem), GFP_KERNEL);
if (!obj)
return -ENOMEM;
 
-   err = devx_umem_get(dev, >ibucontext, attrs, obj);
+   err = devx_umem_get(dev, >ibucontext, attrs, obj, access_flags);
if (err)
goto err_obj_free;
 
-   err = devx_umem_reg_cmd_alloc(dev, attrs, obj, );
+   err = devx_umem_reg_cmd_alloc(dev, attrs, obj, , access_flags);
if (err)
goto err_umem_release;
 

[PATCH 3/4] RDMA/mlx5: Add support for dmabuf to devx umem

2022-09-01 Thread Jason Gunthorpe
This is modeled after the similar EFA enablement in commit
66f4817b5712 ("RDMA/efa: Add support for dmabuf memory regions").

Like EFA there is no support for revocation so we simply call the
ib_umem_dmabuf_get_pinned() to obtain a umem instead of the normal
ib_umem_get().  Everything else stays the same.

Signed-off-by: Jason Gunthorpe 
---
 drivers/infiniband/hw/mlx5/devx.c| 24 +---
 include/uapi/rdma/mlx5_user_ioctl_cmds.h |  1 +
 2 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/devx.c 
b/drivers/infiniband/hw/mlx5/devx.c
index 2a2a9e9afc9dad..291e73d7928276 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -2181,9 +2181,25 @@ static int devx_umem_get(struct mlx5_ib_dev *dev, struct 
ib_ucontext *ucontext,
if (err)
return err;
 
-   obj->umem = ib_umem_get(>ib_dev, addr, size, access);
-   if (IS_ERR(obj->umem))
-   return PTR_ERR(obj->umem);
+   if (uverbs_attr_is_valid(attrs, MLX5_IB_ATTR_DEVX_UMEM_REG_DMABUF_FD)) {
+   struct ib_umem_dmabuf *umem_dmabuf;
+   int dmabuf_fd;
+
+   err = uverbs_get_raw_fd(_fd, attrs,
+   MLX5_IB_ATTR_DEVX_UMEM_REG_DMABUF_FD);
+   if (err)
+   return -EFAULT;
+
+   umem_dmabuf = ib_umem_dmabuf_get_pinned(
+   >ib_dev, addr, size, dmabuf_fd, access);
+   if (IS_ERR(umem_dmabuf))
+   return PTR_ERR(umem_dmabuf);
+   obj->umem = _dmabuf->umem;
+   } else {
+   obj->umem = ib_umem_get(>ib_dev, addr, size, access);
+   if (IS_ERR(obj->umem))
+   return PTR_ERR(obj->umem);
+   }
return 0;
 }
 
@@ -2833,6 +2849,8 @@ DECLARE_UVERBS_NAMED_METHOD(
UVERBS_ATTR_PTR_IN(MLX5_IB_ATTR_DEVX_UMEM_REG_LEN,
   UVERBS_ATTR_TYPE(u64),
   UA_MANDATORY),
+   UVERBS_ATTR_RAW_FD(MLX5_IB_ATTR_DEVX_UMEM_REG_DMABUF_FD,
+  UA_OPTIONAL),
UVERBS_ATTR_FLAGS_IN(MLX5_IB_ATTR_DEVX_UMEM_REG_ACCESS,
 enum ib_access_flags),
UVERBS_ATTR_CONST_IN(MLX5_IB_ATTR_DEVX_UMEM_REG_PGSZ_BITMAP,
diff --git a/include/uapi/rdma/mlx5_user_ioctl_cmds.h 
b/include/uapi/rdma/mlx5_user_ioctl_cmds.h
index 3bee490eb5857f..595edad03dfe54 100644
--- a/include/uapi/rdma/mlx5_user_ioctl_cmds.h
+++ b/include/uapi/rdma/mlx5_user_ioctl_cmds.h
@@ -174,6 +174,7 @@ enum mlx5_ib_devx_umem_reg_attrs {
MLX5_IB_ATTR_DEVX_UMEM_REG_ACCESS,
MLX5_IB_ATTR_DEVX_UMEM_REG_OUT_ID,
MLX5_IB_ATTR_DEVX_UMEM_REG_PGSZ_BITMAP,
+   MLX5_IB_ATTR_DEVX_UMEM_REG_DMABUF_FD,
 };
 
 enum mlx5_ib_devx_umem_dereg_attrs {
-- 
2.37.2



[PATCH 2/4] RDMA/core: Add UVERBS_ATTR_RAW_FD

2022-09-01 Thread Jason Gunthorpe
This uses the same passing protocol as UVERBS_ATTR_FD (eg len = 0 data_s64
= fd), except that the FD is not required to be a uverbs object and the
core code does not covert the FD to an object handle automatically.

Access to the int fd is provided by uverbs_get_raw_fd().

Signed-off-by: Jason Gunthorpe 
---
 drivers/infiniband/core/uverbs_ioctl.c |  8 
 include/rdma/uverbs_ioctl.h| 13 +
 2 files changed, 21 insertions(+)

diff --git a/drivers/infiniband/core/uverbs_ioctl.c 
b/drivers/infiniband/core/uverbs_ioctl.c
index 990f0724acc6b6..d9799706c58e99 100644
--- a/drivers/infiniband/core/uverbs_ioctl.c
+++ b/drivers/infiniband/core/uverbs_ioctl.c
@@ -337,6 +337,14 @@ static int uverbs_process_attr(struct bundle_priv *pbundle,
 
break;
 
+   case UVERBS_ATTR_TYPE_RAW_FD:
+   if (uattr->attr_data.reserved || uattr->len != 0 ||
+   uattr->data_s64 < INT_MIN || uattr->data_s64 > INT_MAX)
+   return -EINVAL;
+   /* _uverbs_get_const_signed() is the accessor */
+   e->ptr_attr.data = uattr->data_s64;
+   break;
+
case UVERBS_ATTR_TYPE_IDRS_ARRAY:
return uverbs_process_idrs_array(pbundle, attr_uapi,
 >objs_arr_attr, uattr,
diff --git a/include/rdma/uverbs_ioctl.h b/include/rdma/uverbs_ioctl.h
index 23bb404aba12c0..9d45a5b203169e 100644
--- a/include/rdma/uverbs_ioctl.h
+++ b/include/rdma/uverbs_ioctl.h
@@ -24,6 +24,7 @@ enum uverbs_attr_type {
UVERBS_ATTR_TYPE_PTR_OUT,
UVERBS_ATTR_TYPE_IDR,
UVERBS_ATTR_TYPE_FD,
+   UVERBS_ATTR_TYPE_RAW_FD,
UVERBS_ATTR_TYPE_ENUM_IN,
UVERBS_ATTR_TYPE_IDRS_ARRAY,
 };
@@ -521,6 +522,11 @@ struct uapi_definition {
  .u.obj.access = _access, \
  __VA_ARGS__ } })
 
+#define UVERBS_ATTR_RAW_FD(_attr_id, ...)  
\
+   (&(const struct uverbs_attr_def){  \
+   .id = (_attr_id),  \
+   .attr = { .type = UVERBS_ATTR_TYPE_RAW_FD, __VA_ARGS__ } })
+
 #define UVERBS_ATTR_PTR_IN(_attr_id, _type, ...)   
\
(&(const struct uverbs_attr_def){  \
.id = _attr_id,\
@@ -999,4 +1005,11 @@ _uverbs_get_const_unsigned(u64 *to,
 uverbs_get_const_default_unsigned(_to, _attrs_bundle, _idx,   \
_default))
 
+static inline int
+uverbs_get_raw_fd(int *to, const struct uverbs_attr_bundle *attrs_bundle,
+ size_t idx)
+{
+   return uverbs_get_const_signed(to, attrs_bundle, idx);
+}
+
 #endif
-- 
2.37.2



[PATCH v2] drm/amd/display: fix indentation in commit_planes_for_stream()

2022-09-01 Thread Hamza Mahfooz
Address the following warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3508:9: warning: this ‘if’ 
clause does not guard... [-Wmisleading-indentation]
 3508 | if (update_type != UPDATE_TYPE_FAST)
  | ^~
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:3510:17: note: ...this 
statement, but the latter is misleadingly indented as if it were guarded by the 
‘if’
 3510 | if (update_type != UPDATE_TYPE_FAST)
  | ^~

Signed-off-by: Hamza Mahfooz 
---
v2: implement feedback from Alvin
---
 drivers/gpu/drm/amd/display/dc/core/dc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index b49237390cce..9860bf38c547 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -3507,9 +3507,10 @@ static void commit_planes_for_stream(struct dc *dc,
 
if (update_type != UPDATE_TYPE_FAST)
dc->hwss.post_unlock_program_front_end(dc, context);
-   if (update_type != UPDATE_TYPE_FAST)
-   if (dc->hwss.commit_subvp_config)
-   dc->hwss.commit_subvp_config(dc, context);
+
+   if (update_type != UPDATE_TYPE_FAST)
+   if (dc->hwss.commit_subvp_config)
+   dc->hwss.commit_subvp_config(dc, context);
 
/* Since phantom pipe programming is moved to 
post_unlock_program_front_end,
 * move the SubVP lock to after the phantom pipes have been setup
-- 
2.37.2



RE: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

2022-09-01 Thread Ruhl, Michael J
>-Original Message-
>From: Dmitry Osipenko 
>Sent: Wednesday, August 31, 2022 11:38 AM
>To: David Airlie ; Gerd Hoffmann ;
>Gurchetan Singh ; Chia-I Wu
>; Daniel Vetter ; Daniel Almeida
>; Gert Wollny ;
>Gustavo Padovan ; Daniel Stone
>; Tomeu Vizoso ;
>Maarten Lankhorst ; Maxime Ripard
>; Thomas Zimmermann ;
>Rob Clark ; Sumit Semwal
>; Christian König ;
>Pan, Xinhui ; Thierry Reding
>; Tomasz Figa ; Marek
>Szyprowski ; Mauro Carvalho Chehab
>; Alex Deucher ; Jani
>Nikula ; Joonas Lahtinen
>; Vivi, Rodrigo ;
>Tvrtko Ursulin ; Thomas Hellström
>; Qiang Yu ; Srinivas
>Kandagatla ; Amol Maheshwari
>; Jason Gunthorpe ; Leon
>Romanovsky ; Gross, Jurgen ; Stefano
>Stabellini ; Oleksandr Tyshchenko
>; Tomi Valkeinen ;
>Russell King ; Lucas Stach ;
>Christian Gmeiner 
>Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org; Dmitry
>Osipenko ; linux-me...@vger.kernel.org; linaro-mm-
>s...@lists.linaro.org; amd-...@lists.freedesktop.org; intel-
>g...@lists.freedesktop.org; ker...@collabora.com; virtualization@lists.linux-
>foundation.org; linux-r...@vger.kernel.org; linux-arm-
>m...@vger.kernel.org
>Subject: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking
>specification
>
>Prepare i915 driver to the common dynamic dma-buf locking convention
>by starting to use the unlocked versions of dma-buf API functions
>and handling cases where importer now holds the reservation lock.
>
>Signed-off-by: Dmitry Osipenko 
>---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   |  2 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.c   | 12 
> .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16 
> 3 files changed, 21 insertions(+), 9 deletions(-)
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>index f5062d0c6333..07eee1c09aaf 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>@@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>*dma_buf,
>   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>   void *vaddr;
>
>-  vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>+  vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
>   if (IS_ERR(vaddr))
>   return PTR_ERR(vaddr);
>
>diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>index 389e9f157ca5..7e2a9b02526c 100644
>--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>@@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>drm_i915_private *i915,
>   continue;
>   }
>
>+  /*
>+   * dma_buf_unmap_attachment() requires reservation to be
>+   * locked. The imported GEM shouldn't share reservation lock,
>+   * so it's safe to take the lock.
>+   */
>+  if (obj->base.import_attach)
>+  i915_gem_object_lock(obj, NULL);

There is a lot of stuff going here.  Taking the lock may be premature...

>   __i915_gem_object_pages_fini(obj);

The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where
unmap_attachment is actually called, would it make more sense to make
do the locking there?

Mike


>+
>+  if (obj->base.import_attach)
>+  i915_gem_object_unlock(obj);
>+
>   __i915_gem_free_object(obj);
>
>   /* But keep the pointer alive for RCU-protected lookups */
>diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>index 62c61af77a42..9e3ed634aa0e 100644
>--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>@@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
>   goto out_import;
>   }
>
>-  st = dma_buf_map_attachment(import_attach,
>DMA_BIDIRECTIONAL);
>+  st = dma_buf_map_attachment_unlocked(import_attach,
>DMA_BIDIRECTIONAL);
>   if (IS_ERR(st)) {
>   err = PTR_ERR(st);
>   goto out_detach;
>@@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>drm_i915_private *i915,
>   timeout = -ETIME;
>   }
>   err = timeout > 0 ? 0 : timeout;
>-  dma_buf_unmap_attachment(import_attach, st,
>DMA_BIDIRECTIONAL);
>+  dma_buf_unmap_attachment_unlocked(import_attach, st,
>DMA_BIDIRECTIONAL);
> out_detach:
>   dma_buf_detach(dmabuf, import_attach);
> out_import:
>@@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
>   goto out_obj;
>   }
>
>-  err = dma_buf_vmap(dmabuf, );
>+  err = dma_buf_vmap_unlocked(dmabuf, );
>   dma_map = err ? NULL : map.vaddr;
>   if (!dma_map) {
>   pr_err("dma_buf_vmap failed\n");
>@@ -337,7 +337,7 @@ static int 

Re: [PATCH] drm: Simplify testing on UML with kunit.py

2022-09-01 Thread Maxime Ripard
Hi,

On Thu, Sep 01, 2022 at 03:36:21PM +0200, Michał Winiarski wrote:
> DRM depends on IOMEM and DMA, introduce an additional Kconfig to pull in
> IOMEM and DMA emulation on UML.
> Since --kconfig_add usage is no longer needed, remove it from
> documentation.
> 
> Signed-off-by: Michał Winiarski 
> ---
>  Documentation/gpu/drm-internals.rst | 7 +--
>  drivers/video/Kconfig   | 4 
>  2 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-internals.rst 
> b/Documentation/gpu/drm-internals.rst
> index 5fd20a306718..c264a9587d21 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -228,16 +228,11 @@ follows:
>  
>  .. code-block:: bash
>  
> - $ ./tools/testing/kunit/kunit.py run 
> --kunitconfig=drivers/gpu/drm/tests \
> - --kconfig_add CONFIG_VIRTIO_UML=y \
> - --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
> + $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests
>  
>  .. note::
>   The configuration included in ``.kunitconfig`` should be as generic as
>   possible.
> - ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not
> - included in it because they are only required for User Mode Linux.
> -

I'm all for removing that part of the documentation, but because
6fc3a8636a7b, in 6.0 should address this entirely? Why would we need
that other symbol?

Maxime


signature.asc
Description: PGP signature


[PULL] drm-intel-fixes

2022-09-01 Thread Rodrigo Vivi
Hi Dave and Daniel,

Here goes drm-intel-fixes-2022-09-01:

- GVT fixes including fix for a CommetLake regression in mmio table
  and misc doc and typo fixes (Julia, Jiapeng, Colin, Alex)
- Fix CCS handling (Matt)
- Fix for guc requests after reset (Daniele)
- Display DSI related fixes (Jani)
- Display backlight related fixes (Arun, Jouni)
- Fix for a null pointer dereference (Lukasz)
- HDMI related quirk for ECS Liva Q2 with GLK graphics (Diego)
- Skip wm/ddb readout for disabled pipes (Ville)

Thanks,
Rodrigo.

The following changes since commit 1c23f9e627a7b412978b4e852793c5e3c3efc555:

  Linux 6.0-rc2 (2022-08-21 17:32:54 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-09-01

for you to fetch changes up to 0211c2a0ea600e25db3044daaeff4fe41c3ed6d9:

  drm/i915: Skip wm/ddb readout for disabled pipes (2022-08-29 10:00:54 -0400)


- GVT fixes including fix for a CommetLake regression in mmio table
  and misc doc and typo fixes (Julia, Jiapeng, Colin, Alex)
- Fix CCS handling (Matt)
- Fix for guc requests after reset (Daniele)
- Display DSI related fixes (Jani)
- Display backlight related fixes (Arun, Jouni)
- Fix for a null pointer dereference (Lukasz)
- HDMI related quirk for ECS Liva Q2 with GLK graphics (Diego)
- Skip wm/ddb readout for disabled pipes (Ville)


Alex Williamson (1):
  drm/i915/gvt: Fix Comet Lake

Arun R Murthy (1):
  drm/i915/display: avoid warnings when registering dual panel backlight

Colin Ian King (1):
  drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"

Daniele Ceraolo Spurio (1):
  drm/i915/guc: clear stalled request after a reset

Diego Santa Cruz (1):
  drm/i915/glk: ECS Liva Q2 needs GLK HDMI port timing quirk

Jani Nikula (2):
  drm/i915/dsi: filter invalid backlight and CABC ports
  drm/i915/dsi: fix dual-link DSI backlight and CABC ports for display 11+

Jiapeng Chong (3):
  drm/i915/gvt: Fix kernel-doc
  drm/i915/gvt: Fix kernel-doc
  drm/i915/gvt: Fix kernel-doc

Jouni Högander (1):
  drm/i915/backlight: Disable pps power hook for aux based backlight

Julia Lawall (1):
  drm/i915/gvt: fix typo in comment

Matthew Auld (1):
  drm/i915/ttm: fix CCS handling

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2022-08-22' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Ville Syrjälä (1):
  drm/i915: Skip wm/ddb readout for disabled pipes

Łukasz Bartosik (1):
  drm/i915: fix null pointer dereference

 drivers/gpu/drm/i915/display/icl_dsi.c|  7 
 drivers/gpu/drm/i915/display/intel_backlight.c| 37 ++-
 drivers/gpu/drm/i915/display/intel_bios.c | 10 +++---
 drivers/gpu/drm/i915/display/intel_bw.c   | 16 +
 drivers/gpu/drm/i915/display/intel_dp.c   |  2 --
 drivers/gpu/drm/i915/display/intel_quirks.c   |  3 ++
 drivers/gpu/drm/i915/display/vlv_dsi.c|  7 
 drivers/gpu/drm/i915/gt/intel_migrate.c   | 44 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |  7 
 drivers/gpu/drm/i915/gvt/aperture_gm.c|  4 +--
 drivers/gpu/drm/i915/gvt/gtt.c|  2 +-
 drivers/gpu/drm/i915/gvt/handlers.c   |  4 +--
 drivers/gpu/drm/i915/gvt/mmio_context.c   |  2 +-
 drivers/gpu/drm/i915/intel_gvt_mmio_table.c   |  3 +-
 drivers/gpu/drm/i915/intel_pm.c   |  8 -
 15 files changed, 95 insertions(+), 61 deletions(-)


[PATCH] drm: Simplify testing on UML with kunit.py

2022-09-01 Thread Michał Winiarski
DRM depends on IOMEM and DMA, introduce an additional Kconfig to pull in
IOMEM and DMA emulation on UML.
Since --kconfig_add usage is no longer needed, remove it from
documentation.

Signed-off-by: Michał Winiarski 
---
 Documentation/gpu/drm-internals.rst | 7 +--
 drivers/video/Kconfig   | 4 
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 5fd20a306718..c264a9587d21 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -228,16 +228,11 @@ follows:
 
 .. code-block:: bash
 
-   $ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/tests \
-   --kconfig_add CONFIG_VIRTIO_UML=y \
-   --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y
+   $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests
 
 .. note::
The configuration included in ``.kunitconfig`` should be as generic as
possible.
-   ``CONFIG_VIRTIO_UML`` and ``CONFIG_UML_PCI_OVER_VIRTIO`` are not
-   included in it because they are only required for User Mode Linux.
-
 
 Legacy Support Code
 ===
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 0587e21abad9..f3266c9fa8a6 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -52,5 +52,9 @@ if FB || SGI_NEWPORT_CONSOLE
 
 endif
 
+config DRM_UML_IO_EMULATION
+   def_bool y if UML && KUNIT
+   select UML_DMA_EMULATION
+   select UML_IOMEM_EMULATION
 
 endmenu
-- 
2.37.3



[PATCH] drm/bridge: tc358775: Do not soft reset i2c-slave controller

2022-09-01 Thread Teresa Remmet
Soft reset during tc_bridge_enable() is triggered by setting all available
reset control bits in the SYSRST register.
But as noted in the data sheet resetting the i2c-slave controller should
be only done over DSI and is only useful for chip debugging.
So do not set RSTI2CS (bit0).

Signed-off-by: Teresa Remmet 
---
 drivers/gpu/drm/bridge/tc358775.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358775.c 
b/drivers/gpu/drm/bridge/tc358775.c
index f1c6e62b0e1d..a5f5eae1e80f 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -408,7 +408,7 @@ static void tc_bridge_enable(struct drm_bridge *bridge)
 (val >> 8) & 0xFF, val & 0xFF);
 
d2l_write(tc->i2c, SYSRST, SYS_RST_REG | SYS_RST_DSIRX | SYS_RST_BM |
- SYS_RST_LCD | SYS_RST_I2CM | SYS_RST_I2CS);
+ SYS_RST_LCD | SYS_RST_I2CM);
usleep_range(3, 4);
 
d2l_write(tc->i2c, PPI_TX_RX_TA, TTA_GET | TTA_SURE);
-- 
2.25.1



Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"

2022-09-01 Thread Javier Martinez Canillas
On 9/1/22 14:55, Maxime Ripard wrote:
> Hi,
> 
> On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
>> With the introduction of KUnit, IGT is no longer the only option to run
>> the DRM unit tests, as the tests can be run through kunit-tool or on
>> real hardware with CONFIG_KUNIT.
>>
>> Therefore, remove the "igt_" prefix from the tests and replace it with
>> the "test_drm_" prefix, making the tests' names independent from the tool
>> used.
>>
>> Signed-off-by: Maíra Canal 
>>
>> ---
>> v1 -> v2: 
>> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/
>> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing 
>> (Jani Nikula).
> 
> I appreciate it's a bit of a bikeshed but I disagree with this. The
> majority of the kunit tests already out there start with the framework
> name, including *all* the examples in the kunit doc. Plus, it's fairly
> obvious that it's a test, kunit is only about running tests in the first
> place.
>

Agree with Maxime on this.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat



Re: [PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"

2022-09-01 Thread Maxime Ripard
Hi,

On Thu, Sep 01, 2022 at 09:42:10AM -0300, Maíra Canal wrote:
> With the introduction of KUnit, IGT is no longer the only option to run
> the DRM unit tests, as the tests can be run through kunit-tool or on
> real hardware with CONFIG_KUNIT.
> 
> Therefore, remove the "igt_" prefix from the tests and replace it with
> the "test_drm_" prefix, making the tests' names independent from the tool
> used.
> 
> Signed-off-by: Maíra Canal 
>
> ---
> v1 -> v2: 
> https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/
> - Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing (Jani 
> Nikula).

I appreciate it's a bit of a bikeshed but I disagree with this. The
majority of the kunit tests already out there start with the framework
name, including *all* the examples in the kunit doc. Plus, it's fairly
obvious that it's a test, kunit is only about running tests in the first
place.

Maxime


Re: [PATCH 1/3] drm/i915: audit bo->resource usage

2022-09-01 Thread Matthew Auld

On 01/09/2022 09:00, Christian König wrote:

Am 31.08.22 um 18:32 schrieb Matthew Auld:

On 31/08/2022 15:53, Matthew Auld wrote:

On 31/08/2022 14:34, Christian König wrote:

Am 31.08.22 um 14:50 schrieb Matthew Auld:

On 31/08/2022 13:35, Christian König wrote:

Am 31.08.22 um 14:06 schrieb Matthew Auld:

On 31/08/2022 12:03, Christian König wrote:

Am 31.08.22 um 12:37 schrieb Matthew Auld:

[SNIP]


That hopefully just leaves i915_ttm_shrink(), which is 
swapping out shmem ttm_tt and is calling ttm_bo_validate() 
with empty placements to force the pipeline-gutting path, 
which importantly unpopulates the ttm_tt for us (since 
ttm_tt_unpopulate is not exported it seems). But AFAICT it 
looks like that will now also nuke the bo->resource, instead 
of just leaving it in system memory. My assumption is that 
when later calling ttm_bo_validate(), it will just do the 
bo_move_null() in i915_ttm_move(), instead of re-populating 
the ttm_tt and then potentially copying it back to local-memory?


Well you do ttm_bo_validate() with something like GTT domain, 
don't you? This should result in re-populating the tt object, 
but I'm not 100% sure if that really works as expected.


AFAIK for domains we either have system memory (which uses 
ttm_tt and might be shmem underneath) or local-memory. But 
perhaps i915 is doing something wrong here, or abusing TTM in 
some way. I'm not sure tbh.


Anyway, I think we have two cases here:

- We have some system memory only object. After doing 
i915_ttm_shrink(), bo->resource is now NULL. We then call 
ttm_bo_validate() at some later point, but here we don't need 
to copy anything, but it also looks like 
ttm_bo_handle_move_mem() won't populate the ttm_tt or us 
either, since mem_type == TTM_PL_SYSTEM. It looks like 
i915_ttm_move() was taking care of this, but now we just call 
ttm_bo_move_null().


- We have a local-memory only object, which was evicted to 
shmem, and then swapped out by the shrinker like above. The 
bo->resource is NULL. However this time when calling 
ttm_bo_validate() we need to actually do a copy in 
i915_ttm_move(), as well as re-populate the ttm_tt. 
i915_ttm_move() was taking care of this, but now we just call 
ttm_bo_move_null().


Perhaps i915 is doing something wrong in the above two cases?


Mhm, as far as I can see that should still work.

See previously you should got a transition from SYSTEM->GTT in 
i915_ttm_move() to re-create your backing store. Not you get 
NULL->SYSTEM which is handled by ttm_bo_move_null() and then 
SYSTEM->GTT.


What is GTT here in TTM world? Also I'm not seeing where there is 
this SYSTEM->GTT transition? Maybe I'm blind. Just to be clear, 
i915 is only calling ttm_bo_validate() once when acquiring the 
pages, and we don't call it again, unless it was evicted (and 
potentially swapped out).


Well GTT means TTM_PL_TT.

And calling it only once is perfectly fine, TTM will internally 
see that we need two hops to reach TTM_PL_TT and so does the 
NULL->SYSTEM transition and then SYSTEM->TT.


Ah interesting, so that's what the multi-hop thing does. But AFAICT 
i915 is not using either TTM_PL_TT or -EMULTIHOP.


Mhm, it could be that we then have a problem and the i915 driver 
only sees NULL->TT directly. But I really don't know the i915 driver 
code good enough to judge that.


Can you take a look at this and test it maybe?


I'll grab a machine and try to see what is going on here.


Well at least the issue with the firmware not loading looks to be 
fixed now.


So running some eviction + oom tests it looks it now does:

/* eviction kicks in */
i915_ttm_move(bo):  LMEM -> PL_SYSTEM

/* shrinker/oom kicks in at some point */
i915_ttm_shrink(bo):
    bo->resource = NULL, /* pipeline_gutting */
    shmem ttm_tt is unpopulated and pages are correctly swapped out

/* user touches the same object later */
i915_ttm_move(bo):  NULL -> LMEM, bo_move_null()

So seems to incorrectly skip swapping it back in and then copy over to 
lmem. It just allocates directly in lmem.


And previously the last two steps would have been:

i915_ttm_shrink(bo):
    bo->resource = PL_SYSTEM, /* pipeline_gutting */
    shmem ttm_tt is unpopulated and pages are correctly swapped out

i915_ttm_move(bo):
    PL_SYSTEM -> LMEM,
    ttm_tt is repopulated and pages are copied over to lmem


Mhm, crap. That indeed looks like it won't work.

How about changing the code like this:

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c

index c420d1ab605b..1ee7d81ddcbc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -560,7 +560,17 @@ int i915_ttm_move(struct ttm_buffer_object *bo, 
bool evict,

     bool clear;
     int ret;

-   if (GEM_WARN_ON(!obj) || !bo->resource) {
+   if (GEM_WARN_ON(!obj)) {
+   ttm_bo_move_null(bo, dst_mem);
+   return 0;
+   }
+
+   if (!bo->resource) {
+   

[PATCH v2 1/2] drm/tests: Split drm_framebuffer_create_test into parameterized tests

2022-09-01 Thread Maíra Canal
The igt_check_drm_framebuffer_create is based on a loop that executes
tests for all createbuffer_tests test cases. This could be better
represented by parameterized tests, provided by KUnit.

So, convert the igt_check_drm_framebuffer_create into parameterized tests.

Signed-off-by: Maíra Canal 
Reviewed-by: Michał Winiarski 
---
v1 -> v2: 
https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/
- Use .init for mock_drm_device instead of a global variable. (Michał Winiarski)
---
 drivers/gpu/drm/tests/drm_framebuffer_test.c | 45 
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/tests/drm_framebuffer_test.c 
b/drivers/gpu/drm/tests/drm_framebuffer_test.c
index ec7a08ba4056..564794917784 100644
--- a/drivers/gpu/drm/tests/drm_framebuffer_test.c
+++ b/drivers/gpu/drm/tests/drm_framebuffer_test.c
@@ -25,7 +25,7 @@ struct drm_framebuffer_test {
const char *name;
 };
 
-static struct drm_framebuffer_test createbuffer_tests[] = {
+static const struct drm_framebuffer_test drm_framebuffer_create_cases[] = {
 { .buffer_created = 1, .name = "ABGR normal sizes",
.cmd = { .width = 600, .height = 600, .pixel_format = 
DRM_FORMAT_ABGR,
 .handles = { 1, 0, 0 }, .pitches = { 4 * 600, 0, 0 },
@@ -330,43 +330,52 @@ static struct drm_mode_config_funcs mock_config_funcs = {
.fb_create = fb_create_mock,
 };
 
-static struct drm_device mock_drm_device = {
-   .mode_config = {
+static int drm_framebuffer_test_init(struct kunit *test)
+{
+   struct drm_device *mock;
+
+   mock = kunit_kzalloc(test, sizeof(*mock), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, mock);
+
+   mock->mode_config = (struct drm_mode_config) {
.min_width = MIN_WIDTH,
.max_width = MAX_WIDTH,
.min_height = MIN_HEIGHT,
.max_height = MAX_HEIGHT,
.funcs = _config_funcs,
-   },
-};
+   };
 
-static int execute_drm_mode_fb_cmd2(struct drm_mode_fb_cmd2 *r)
+   test->priv = mock;
+   return 0;
+}
+
+static void test_drm_framebuffer_create(struct kunit *test)
 {
+   const struct drm_framebuffer_test *params = test->param_value;
+   struct drm_device *mock = test->priv;
int buffer_created = 0;
 
-   mock_drm_device.dev_private = _created;
-   drm_internal_framebuffer_create(_drm_device, r, NULL);
-   return buffer_created;
+   mock->dev_private = _created;
+   drm_internal_framebuffer_create(mock, >cmd, NULL);
+   KUNIT_EXPECT_EQ(test, params->buffer_created, buffer_created);
 }
 
-static void igt_check_drm_framebuffer_create(struct kunit *test)
+static void drm_framebuffer_test_to_desc(const struct drm_framebuffer_test *t, 
char *desc)
 {
-   int i = 0;
-
-   for (i = 0; i < ARRAY_SIZE(createbuffer_tests); i++) {
-   KUNIT_EXPECT_EQ_MSG(test, createbuffer_tests[i].buffer_created,
-   
execute_drm_mode_fb_cmd2(_tests[i].cmd),
-"Test %d: \"%s\" failed\n", i, createbuffer_tests[i].name);
-   }
+   strcpy(desc, t->name);
 }
 
+KUNIT_ARRAY_PARAM(drm_framebuffer_create, drm_framebuffer_create_cases,
+ drm_framebuffer_test_to_desc);
+
 static struct kunit_case drm_framebuffer_tests[] = {
-   KUNIT_CASE(igt_check_drm_framebuffer_create),
+   KUNIT_CASE_PARAM(test_drm_framebuffer_create, 
drm_framebuffer_create_gen_params),
{ }
 };
 
 static struct kunit_suite drm_framebuffer_test_suite = {
.name = "drm_framebuffer",
+   .init = drm_framebuffer_test_init,
.test_cases = drm_framebuffer_tests,
 };
 
-- 
2.37.2



[PATCH v2 2/2] drm/tests: Change "igt_" prefix to "test_drm_"

2022-09-01 Thread Maíra Canal
With the introduction of KUnit, IGT is no longer the only option to run
the DRM unit tests, as the tests can be run through kunit-tool or on
real hardware with CONFIG_KUNIT.

Therefore, remove the "igt_" prefix from the tests and replace it with
the "test_drm_" prefix, making the tests' names independent from the tool
used.

Signed-off-by: Maíra Canal 
---
v1 -> v2: 
https://lore.kernel.org/dri-devel/20220830211603.191734-1-mairaca...@riseup.net/
- Change "drm_" prefix to "test_drm_", as "drm_" can be a bit confusing (Jani 
Nikula).
---
 drivers/gpu/drm/tests/drm_buddy_test.c|  84 +-
 .../gpu/drm/tests/drm_cmdline_parser_test.c   | 156 +-
 .../gpu/drm/tests/drm_damage_helper_test.c|  84 +-
 .../gpu/drm/tests/drm_dp_mst_helper_test.c|   8 +-
 .../gpu/drm/tests/drm_format_helper_test.c|   8 +-
 drivers/gpu/drm/tests/drm_format_test.c   |  20 +--
 drivers/gpu/drm/tests/drm_mm_test.c   | 155 -
 drivers/gpu/drm/tests/drm_plane_helper_test.c |   4 +-
 drivers/gpu/drm/tests/drm_rect_test.c |  16 +-
 9 files changed, 268 insertions(+), 267 deletions(-)

diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c 
b/drivers/gpu/drm/tests/drm_buddy_test.c
index d76f83833e75..ac0d18c60d72 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -13,7 +13,7 @@
 
 #include "../lib/drm_random.h"
 
-#define IGT_TIMEOUT(name__)
\
+#define TIMEOUT(name__)
\
unsigned long name__ = jiffies + MAX_SCHEDULE_TIMEOUT
 
 static unsigned int random_seed;
@@ -24,7 +24,7 @@ static inline u64 get_size(int order, u64 chunk_size)
 }
 
 __printf(2, 3)
-static bool __igt_timeout(unsigned long timeout, const char *fmt, ...)
+static bool __timeout(unsigned long timeout, const char *fmt, ...)
 {
va_list va;
 
@@ -43,8 +43,8 @@ static bool __igt_timeout(unsigned long timeout, const char 
*fmt, ...)
return true;
 }
 
-static void __igt_dump_block(struct kunit *test, struct drm_buddy *mm,
-struct drm_buddy_block *block, bool buddy)
+static void __dump_block(struct kunit *test, struct drm_buddy *mm,
+struct drm_buddy_block *block, bool buddy)
 {
kunit_err(test, "block info: header=%llx, state=%u, order=%d, 
offset=%llx size=%llx root=%d buddy=%d\n",
  block->header, drm_buddy_block_state(block),
@@ -52,20 +52,20 @@ static void __igt_dump_block(struct kunit *test, struct 
drm_buddy *mm,
  drm_buddy_block_size(mm, block), !block->parent, 
buddy);
 }
 
-static void igt_dump_block(struct kunit *test, struct drm_buddy *mm,
-  struct drm_buddy_block *block)
+static void dump_block(struct kunit *test, struct drm_buddy *mm,
+  struct drm_buddy_block *block)
 {
struct drm_buddy_block *buddy;
 
-   __igt_dump_block(test, mm, block, false);
+   __dump_block(test, mm, block, false);
 
buddy = drm_get_buddy(block);
if (buddy)
-   __igt_dump_block(test, mm, buddy, true);
+   __dump_block(test, mm, buddy, true);
 }
 
-static int igt_check_block(struct kunit *test, struct drm_buddy *mm,
-  struct drm_buddy_block *block)
+static int check_block(struct kunit *test, struct drm_buddy *mm,
+  struct drm_buddy_block *block)
 {
struct drm_buddy_block *buddy;
unsigned int block_state;
@@ -137,8 +137,8 @@ static int igt_check_block(struct kunit *test, struct 
drm_buddy *mm,
return err;
 }
 
-static int igt_check_blocks(struct kunit *test, struct drm_buddy *mm,
-   struct list_head *blocks, u64 expected_size, bool 
is_contiguous)
+static int check_blocks(struct kunit *test, struct drm_buddy *mm,
+   struct list_head *blocks, u64 expected_size, bool 
is_contiguous)
 {
struct drm_buddy_block *block;
struct drm_buddy_block *prev;
@@ -150,7 +150,7 @@ static int igt_check_blocks(struct kunit *test, struct 
drm_buddy *mm,
total = 0;
 
list_for_each_entry(block, blocks, link) {
-   err = igt_check_block(test, mm, block);
+   err = check_block(test, mm, block);
 
if (!drm_buddy_block_is_allocated(block)) {
kunit_err(test, "block not allocated\n");
@@ -190,16 +190,16 @@ static int igt_check_blocks(struct kunit *test, struct 
drm_buddy *mm,
 
if (prev) {
kunit_err(test, "prev block, dump:\n");
-   igt_dump_block(test, mm, prev);
+   dump_block(test, mm, prev);
}
 
kunit_err(test, "bad block, dump:\n");
-   igt_dump_block(test, mm, block);
+   dump_block(test, mm, block);
 
return err;
 }
 
-static int igt_check_mm(struct kunit *test, struct 

[PATCH 9/9] drm/rockchip: convert to using has_audio from display_info

2022-09-01 Thread Jani Nikula
Prefer the parsed results for has_audio in display info over calling
drm_detect_monitor_audio().

Cc: Sandy Huang 
Cc: Heiko Stübner 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 ++--
 drivers/gpu/drm/rockchip/inno_hdmi.c   | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index f77bdf5f5168..50af9861553b 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -272,10 +272,10 @@ static int cdn_dp_connector_get_modes(struct 
drm_connector *connector)
DRM_DEV_DEBUG_KMS(dp->dev, "got edid: width[%d] x height[%d]\n",
  edid->width_cm, edid->height_cm);
 
-   dp->sink_has_audio = drm_detect_monitor_audio(edid);
-
drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
+
+   dp->sink_has_audio = connector->display_info.has_audio;
}
mutex_unlock(>lock);
 
diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c 
b/drivers/gpu/drm/rockchip/inno_hdmi.c
index 87b2243ea23e..fadaa795fb3d 100644
--- a/drivers/gpu/drm/rockchip/inno_hdmi.c
+++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
@@ -564,10 +564,11 @@ static int inno_hdmi_connector_get_modes(struct 
drm_connector *connector)
 
edid = drm_get_edid(connector, hdmi->ddc);
if (edid) {
-   hdmi->hdmi_data.sink_has_audio = drm_detect_monitor_audio(edid);
drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
kfree(edid);
+
+   hdmi->hdmi_data.sink_has_audio = 
connector->display_info.has_audio;
}
 
return ret;
-- 
2.34.1



[PATCH 8/9] drm/rockchip: cdn-dp: call drm_connector_update_edid_property() unconditionally

2022-09-01 Thread Jani Nikula
Calling drm_connector_update_edid_property() should be done
unconditionally instead of depending on the number of modes added. Also
match the call order in inno_hdmi and rk3066_hdmi.

Cc: Sandy Huang 
Cc: Heiko Stübner 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/rockchip/cdn-dp-core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
index c204e9b95c1f..f77bdf5f5168 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
@@ -273,10 +273,9 @@ static int cdn_dp_connector_get_modes(struct drm_connector 
*connector)
  edid->width_cm, edid->height_cm);
 
dp->sink_has_audio = drm_detect_monitor_audio(edid);
+
+   drm_connector_update_edid_property(connector, edid);
ret = drm_add_edid_modes(connector, edid);
-   if (ret)
-   drm_connector_update_edid_property(connector,
-   edid);
}
mutex_unlock(>lock);
 
-- 
2.34.1



[PATCH 7/9] drm/sti/sti_hdmi: convert to using is_hdmi from display info

2022-09-01 Thread Jani Nikula
Prefer the parsed results for is_hdmi in display info over calling
drm_detect_hdmi_monitor(). Remove the now redundant hdmi_monitor member
from struct sti_hdmi.

Cc: Alain Volmat 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/sti/sti_hdmi.c | 11 ++-
 drivers/gpu/drm/sti/sti_hdmi.h |  2 --
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index cb82622877d2..7e6d47c1c43b 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -266,6 +266,7 @@ static void hdmi_active_area(struct sti_hdmi *hdmi)
  */
 static void hdmi_config(struct sti_hdmi *hdmi)
 {
+   struct drm_connector *connector = hdmi->drm_connector;
u32 conf;
 
DRM_DEBUG_DRIVER("\n");
@@ -275,7 +276,7 @@ static void hdmi_config(struct sti_hdmi *hdmi)
 
/* Select encryption type and the framing mode */
conf |= HDMI_CFG_ESS_NOT_OESS;
-   if (hdmi->hdmi_monitor)
+   if (connector->display_info.is_hdmi)
conf |= HDMI_CFG_HDMI_NOT_DVI;
 
/* Set Hsync polarity */
@@ -985,15 +986,15 @@ static int sti_hdmi_connector_get_modes(struct 
drm_connector *connector)
if (!edid)
goto fail;
 
-   hdmi->hdmi_monitor = drm_detect_hdmi_monitor(edid);
-   DRM_DEBUG_KMS("%s : %dx%d cm\n",
- (hdmi->hdmi_monitor ? "hdmi monitor" : "dvi monitor"),
- edid->width_cm, edid->height_cm);
cec_notifier_set_phys_addr_from_edid(hdmi->notifier, edid);
 
count = drm_add_edid_modes(connector, edid);
drm_connector_update_edid_property(connector, edid);
 
+   DRM_DEBUG_KMS("%s : %dx%d cm\n",
+ (connector->display_info.is_hdmi ? "hdmi monitor" : "dvi 
monitor"),
+ edid->width_cm, edid->height_cm);
+
kfree(edid);
return count;
 
diff --git a/drivers/gpu/drm/sti/sti_hdmi.h b/drivers/gpu/drm/sti/sti_hdmi.h
index 05b2f3d0d48d..6d4c3f57bc46 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.h
+++ b/drivers/gpu/drm/sti/sti_hdmi.h
@@ -57,7 +57,6 @@ struct hdmi_audio_params {
  * @reset: reset control of the hdmi phy
  * @ddc_adapt: i2c ddc adapter
  * @colorspace: current colorspace selected
- * @hdmi_monitor: true if HDMI monitor detected else DVI monitor assumed
  * @audio_pdev: ASoC hdmi-codec platform device
  * @audio: hdmi audio parameters.
  * @drm_connector: hdmi connector
@@ -83,7 +82,6 @@ struct sti_hdmi {
struct reset_control *reset;
struct i2c_adapter *ddc_adapt;
enum hdmi_colorspace colorspace;
-   bool hdmi_monitor;
struct platform_device *audio_pdev;
struct hdmi_audio_params audio;
struct drm_connector *drm_connector;
-- 
2.34.1



[PATCH 6/9] drm/i2c/tda998x: convert to using has_audio from display_info

2022-09-01 Thread Jani Nikula
Prefer the parsed results for has_audio in display info over calling
drm_detect_monitor_audio().

Cc: Russell King 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index f8eb6f69be05..71b6bacf399c 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1310,7 +1310,7 @@ static int tda998x_connector_get_modes(struct 
drm_connector *connector)
 
mutex_lock(>audio_mutex);
n = drm_add_edid_modes(connector, edid);
-   priv->sink_has_audio = drm_detect_monitor_audio(edid);
+   priv->sink_has_audio = connector->display_info.has_audio;
mutex_unlock(>audio_mutex);
 
kfree(edid);
-- 
2.34.1



[PATCH 5/9] drm/exynos: convert to using is_hdmi from display info

2022-09-01 Thread Jani Nikula
Prefer the parsed results for is_hdmi in display info over calling
drm_detect_hdmi_monitor().

Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 10b0036f8a2e..ce99d23f5398 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -893,12 +893,13 @@ static int hdmi_get_modes(struct drm_connector *connector)
if (!edid)
return -ENODEV;
 
-   hdata->dvi_mode = !drm_detect_hdmi_monitor(edid);
+   drm_connector_update_edid_property(connector, edid);
+
+   hdata->dvi_mode = !connector->display_info.is_hdmi;
DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n",
  (hdata->dvi_mode ? "dvi monitor" : "hdmi monitor"),
  edid->width_cm, edid->height_cm);
 
-   drm_connector_update_edid_property(connector, edid);
cec_notifier_set_phys_addr_from_edid(hdata->notifier, edid);
 
ret = drm_add_edid_modes(connector, edid);
-- 
2.34.1



[PATCH 4/9] drm/tegra: convert to using is_hdmi from display info

2022-09-01 Thread Jani Nikula
Prefer the parsed results for is_hdmi in display info over calling
drm_detect_hdmi_monitor().

Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/tegra/hdmi.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index bf240767dad9..40ec3e6cf204 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -867,14 +867,7 @@ static int tegra_hdmi_reconfigure_audio(struct tegra_hdmi 
*hdmi)
 
 static bool tegra_output_is_hdmi(struct tegra_output *output)
 {
-   struct edid *edid;
-
-   if (!output->connector.edid_blob_ptr)
-   return false;
-
-   edid = (struct edid *)output->connector.edid_blob_ptr->data;
-
-   return drm_detect_hdmi_monitor(edid);
+   return output->connector.display_info.is_hdmi;
 }
 
 static enum drm_connector_status
-- 
2.34.1



[PATCH 3/9] drm/radeon: convert to using is_hdmi and has_audio from display info

2022-09-01 Thread Jani Nikula
Prefer the parsed results for is_hdmi and has_audio in display info over
calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
respectively.

Cc: Alex Deucher 
Cc: Christian König 
Cc: "Pan, Xinhui" 
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/radeon/atombios_encoders.c | 10 +-
 drivers/gpu/drm/radeon/evergreen_hdmi.c|  5 ++---
 drivers/gpu/drm/radeon/radeon_audio.c  |  6 +++---
 drivers/gpu/drm/radeon/radeon_connectors.c | 12 ++--
 drivers/gpu/drm/radeon/radeon_display.c|  2 +-
 drivers/gpu/drm/radeon/radeon_encoders.c   |  4 ++--
 6 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index 0eae05dfb385..4f9a0b8327fe 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -692,7 +692,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if (radeon_connector->use_digital &&
(radeon_connector->audio == RADEON_AUDIO_ENABLE))
return ATOM_ENCODER_MODE_HDMI;
-   else if 
(drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
+   else if (connector->display_info.is_hdmi &&
 (radeon_connector->audio == RADEON_AUDIO_AUTO))
return ATOM_ENCODER_MODE_HDMI;
else if (radeon_connector->use_digital)
@@ -711,7 +711,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if (radeon_audio != 0) {
if (radeon_connector->audio == RADEON_AUDIO_ENABLE)
return ATOM_ENCODER_MODE_HDMI;
-   else if 
(drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
+   else if (connector->display_info.is_hdmi &&
 (radeon_connector->audio == RADEON_AUDIO_AUTO))
return ATOM_ENCODER_MODE_HDMI;
else
@@ -728,14 +728,14 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
if ((dig_connector->dp_sink_type == 
CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
(dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_eDP)) {
if (radeon_audio != 0 &&
-   
drm_detect_monitor_audio(radeon_connector_edid(connector)) &&
+   connector->display_info.has_audio &&
ASIC_IS_DCE4(rdev) && !ASIC_IS_DCE5(rdev))
return ATOM_ENCODER_MODE_DP_AUDIO;
return ATOM_ENCODER_MODE_DP;
} else if (radeon_audio != 0) {
if (radeon_connector->audio == RADEON_AUDIO_ENABLE)
return ATOM_ENCODER_MODE_HDMI;
-   else if 
(drm_detect_hdmi_monitor(radeon_connector_edid(connector)) &&
+   else if (connector->display_info.is_hdmi &&
 (radeon_connector->audio == RADEON_AUDIO_AUTO))
return ATOM_ENCODER_MODE_HDMI;
else
@@ -746,7 +746,7 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
break;
case DRM_MODE_CONNECTOR_eDP:
if (radeon_audio != 0 &&
-   drm_detect_monitor_audio(radeon_connector_edid(connector)) 
&&
+   connector->display_info.has_audio &&
ASIC_IS_DCE4(rdev) && !ASIC_IS_DCE5(rdev))
return ATOM_ENCODER_MODE_DP_AUDIO;
return ATOM_ENCODER_MODE_DP;
diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c 
b/drivers/gpu/drm/radeon/evergreen_hdmi.c
index 5f3078f8ab95..134780283274 100644
--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c
+++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c
@@ -411,7 +411,7 @@ void evergreen_hdmi_enable(struct drm_encoder *encoder, 
bool enable)
if (enable) {
struct drm_connector *connector = 
radeon_get_connector_for_encoder(encoder);
 
-   if (connector && 
drm_detect_monitor_audio(radeon_connector_edid(connector))) {
+   if (connector && connector->display_info.has_audio) {
WREG32(HDMI_INFOFRAME_CONTROL0 + dig->afmt->offset,
   HDMI_AVI_INFO_SEND | /* enable AVI info frames */
   HDMI_AVI_INFO_CONT | /* required for audio info 
values to be updated */
@@ -449,8 +449,7 @@ void evergreen_dp_enable(struct drm_encoder *encoder, bool 
enable)
if (!dig || !dig->afmt)
return;
 
-   if (enable && connector &&
-   drm_detect_monitor_audio(radeon_connector_edid(connector))) {
+   if (enable && connector && connector->display_info.has_audio) {

[PATCH 2/9] drm/nouveau: convert to using is_hdmi and has_audio from display info

2022-09-01 Thread Jani Nikula
Prefer the parsed results for is_hdmi and has_audio in display info over
calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(),
respectively.

Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 8 
 drivers/gpu/drm/nouveau/dispnv50/head.c | 8 +---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
 3 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 33c97d510999..d0d9494b729c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -769,7 +769,7 @@ nv50_audio_enable(struct drm_encoder *encoder, struct 
nouveau_crtc *nv_crtc,
 (0x0100 << nv_crtc->index),
};
 
-   if (!drm_detect_monitor_audio(nv_connector->edid))
+   if (!nv_connector->base.display_info.has_audio)
return;
 
mutex_lock(>audio.lock);
@@ -839,7 +839,7 @@ nv50_hdmi_enable(struct drm_encoder *encoder, struct 
nouveau_crtc *nv_crtc,
int ret;
int size;
 
-   if (!drm_detect_hdmi_monitor(nv_connector->edid))
+   if (!nv_connector->base.display_info.is_hdmi)
return;
 
hdmi = _connector->base.display_info.hdmi;
@@ -1705,7 +1705,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
struct drm_atomic_state *sta
 
if ((disp->disp->object.oclass == GT214_DISP ||
 disp->disp->object.oclass >= GF110_DISP) &&
-   drm_detect_monitor_audio(nv_connector->edid))
+   nv_connector->base.display_info.has_audio)
hda = true;
nv50_outp_acquire(nv_encoder, hda);
 
@@ -1721,7 +1721,7 @@ nv50_sor_atomic_enable(struct drm_encoder *encoder, 
struct drm_atomic_state *sta
 */
if (mode->clock >= 165000 &&
nv_encoder->dcb->duallink_possible &&
-   !drm_detect_hdmi_monitor(nv_connector->edid))
+   !nv_connector->base.display_info.is_hdmi)
proto = 
NV507D_SOR_SET_CONTROL_PROTOCOL_DUAL_TMDS;
} else {
proto = NV507D_SOR_SET_CONTROL_PROTOCOL_SINGLE_TMDS_B;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index c3c57be54e1c..8b5bc834f1b3 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -127,14 +127,8 @@ nv50_head_atomic_check_view(struct nv50_head_atom *armh,
struct drm_display_mode *omode = >state.adjusted_mode;
struct drm_display_mode *umode = >state.mode;
int mode = asyc->scaler.mode;
-   struct edid *edid;
int umode_vdisplay, omode_hdisplay, omode_vdisplay;
 
-   if (connector->edid_blob_ptr)
-   edid = (struct edid *)connector->edid_blob_ptr->data;
-   else
-   edid = NULL;
-
if (!asyc->scaler.full) {
if (mode == DRM_MODE_SCALE_NONE)
omode = umode;
@@ -162,7 +156,7 @@ nv50_head_atomic_check_view(struct nv50_head_atom *armh,
 */
if ((asyc->scaler.underscan.mode == UNDERSCAN_ON ||
(asyc->scaler.underscan.mode == UNDERSCAN_AUTO &&
-drm_detect_hdmi_monitor(edid {
+connector->display_info.is_hdmi))) {
u32 bX = asyc->scaler.underscan.hborder;
u32 bY = asyc->scaler.underscan.vborder;
u32 r = (asyh->view.oH << 19) / asyh->view.oW;
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 1991bbb1d05c..2ef5fb8df4ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1012,7 +1012,7 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
unsigned duallink_scale =
nouveau_duallink && nv_encoder->dcb->duallink_possible ? 2 : 1;
 
-   if (drm_detect_hdmi_monitor(nv_connector->edid)) {
+   if (nv_connector->base.display_info.is_hdmi) {
info = _connector->base.display_info;
duallink_scale = 1;
}
-- 
2.34.1



[PATCH 1/9] drm/edid: parse display info has_audio similar to is_hdmi

2022-09-01 Thread Jani Nikula
Since we already iterate everything that's needed for determining audio,
reduce the need to call drm_detect_monitor_audio() by storing has_audio
to connector info.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c  | 6 ++
 include/drm/drm_connector.h | 8 
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 90a5e26eafa8..fe34ff98e5e9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -5994,6 +5994,9 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
info->color_formats |= DRM_COLOR_FORMAT_YCBCR444;
if (edid_ext[3] & EDID_CEA_YCRCB422)
info->color_formats |= DRM_COLOR_FORMAT_YCBCR422;
+   if (edid_ext[3] & EDID_BASIC_AUDIO)
+   info->has_audio = true;
+
}
drm_edid_iter_end(_iter);
 
@@ -6015,6 +6018,8 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
drm_parse_vcdb(connector, data);
else if (cea_db_is_hdmi_hdr_metadata_block(db))
drm_parse_hdr_metadata_block(connector, data);
+   else if (cea_db_tag(db) == CTA_DB_AUDIO)
+   info->has_audio = true;
}
cea_db_iter_end();
 }
@@ -6141,6 +6146,7 @@ static void drm_reset_display_info(struct drm_connector 
*connector)
info->max_tmds_clock = 0;
info->dvi_dual = false;
info->is_hdmi = false;
+   info->has_audio = false;
info->has_hdmi_infoframe = false;
info->rgb_quant_range_selectable = false;
memset(>hdmi, 0, sizeof(info->hdmi));
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 248206bbd975..a9f714612b44 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -597,6 +597,14 @@ struct drm_display_info {
 */
bool is_hdmi;
 
+   /**
+* @has_audio: True if the sink supports audio.
+*
+* This field shall be used instead of calling
+* drm_detect_monitor_audio() when possible.
+*/
+   bool has_audio;
+
/**
 * @has_hdmi_infoframe: Does the sink support the HDMI infoframe?
 */
-- 
2.34.1



[PATCH 0/9] drm: convert to using is_hdmi and has_audio from display info

2022-09-01 Thread Jani Nikula
The low-hanging fruit of the drm todo item "Replace
drm_detect_hdmi_monitor() with drm_display_info.is_hdmi", with has_audio
changes on top.

I'm afraid not all of these have been even build tested, let alone
actually tested.


BR,
Jani.


Cc: Laurent Pinchart  
Cc: Sandy Huang 
Cc: Heiko Stübner 
Cc: Sandy Huang 
Cc: Heiko Stübner 
Cc: Alain Volmat 
Cc: Russell King 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Thierry Reding 
Cc: linux-te...@vger.kernel.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: "Pan, Xinhui" 
Cc: amd-...@lists.freedesktop.org
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: nouv...@lists.freedesktop.org

Jani Nikula (9):
  drm/edid: parse display info has_audio similar to is_hdmi
  drm/nouveau: convert to using is_hdmi and has_audio from display info
  drm/radeon: convert to using is_hdmi and has_audio from display info
  drm/tegra: convert to using is_hdmi from display info
  drm/exynos: convert to using is_hdmi from display info
  drm/i2c/tda998x: convert to using has_audio from display_info
  drm/sti/sti_hdmi: convert to using is_hdmi from display info
  drm/rockchip: cdn-dp: call drm_connector_update_edid_property()
unconditionally
  drm/rockchip: convert to using has_audio from display_info

 drivers/gpu/drm/drm_edid.c  |  6 ++
 drivers/gpu/drm/exynos/exynos_hdmi.c|  5 +++--
 drivers/gpu/drm/i2c/tda998x_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  8 
 drivers/gpu/drm/nouveau/dispnv50/head.c |  8 +---
 drivers/gpu/drm/nouveau/nouveau_connector.c |  2 +-
 drivers/gpu/drm/radeon/atombios_encoders.c  | 10 +-
 drivers/gpu/drm/radeon/evergreen_hdmi.c |  5 ++---
 drivers/gpu/drm/radeon/radeon_audio.c   |  6 +++---
 drivers/gpu/drm/radeon/radeon_connectors.c  | 12 ++--
 drivers/gpu/drm/radeon/radeon_display.c |  2 +-
 drivers/gpu/drm/radeon/radeon_encoders.c|  4 ++--
 drivers/gpu/drm/rockchip/cdn-dp-core.c  |  7 +++
 drivers/gpu/drm/rockchip/inno_hdmi.c|  3 ++-
 drivers/gpu/drm/sti/sti_hdmi.c  | 11 ++-
 drivers/gpu/drm/sti/sti_hdmi.h  |  2 --
 drivers/gpu/drm/tegra/hdmi.c|  9 +
 include/drm/drm_connector.h |  8 
 18 files changed, 55 insertions(+), 55 deletions(-)

-- 
2.34.1



Re: [PATCH v2 2/2] drm/plane_helper: Split into parameterized test cases

2022-09-01 Thread Maíra Canal
Hi Michał

On 8/31/22 17:45, Michał Winiarski wrote:
> The test was constructed as a single function (test case) which checks
> multiple conditions, calling the function that is tested multiple times
> with different arguments.
> This usually means that it can be easily converted into multiple test
> cases.
> Split igt_check_plane_state into two parameterized test cases,
> drm_check_plane_state and drm_check_invalid_plane_state.
> 
> Passing output:
> 
> == drm_plane_helper (2 subtests) ===
> == drm_check_plane_state ===
> [PASSED] clipping_simple
> [PASSED] clipping_rotate_reflect
> [PASSED] positioning_simple
> [PASSED] upscaling
> [PASSED] downscaling
> [PASSED] rounding1
> [PASSED] rounding2
> [PASSED] rounding3
> [PASSED] rounding4
> == [PASSED] drm_check_plane_state ==
> == drm_check_invalid_plane_state ===
> [PASSED] positioning_invalid
> [PASSED] upscaling_invalid
> [PASSED] downscaling_invalid
> == [PASSED] drm_check_invalid_plane_state ==
>  [PASSED] drm_plane_helper =
> 
> Testing complete. Ran 12 tests: passed: 12
> 
> v2: Add missing EXPECT/ASSERT (Maíra)
> 
> Signed-off-by: Michał Winiarski 
> ---
>  drivers/gpu/drm/tests/drm_plane_helper_test.c | 456 ++
>  1 file changed, 267 insertions(+), 189 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tests/drm_plane_helper_test.c 
> b/drivers/gpu/drm/tests/drm_plane_helper_test.c
> index 0bbd42d2d37b..505173b019d7 100644
> --- a/drivers/gpu/drm/tests/drm_plane_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_plane_helper_test.c
> @@ -12,59 +12,97 @@
>  #include 
>  #include 
>  
> -static void set_src(struct drm_plane_state *plane_state,
> - unsigned int src_x, unsigned int src_y,
> - unsigned int src_w, unsigned int src_h)
> +static const struct drm_crtc_state crtc_state = {
> + .crtc = ZERO_SIZE_PTR,
> + .enable = true,
> + .active = true,
> + .mode = {
> + DRM_MODE("1024x768", 0, 65000, 1024, 1048,
> +  1184, 1344, 0, 768, 771, 777, 806, 0,
> +  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC)
> + },
> +};
> +
> +struct drm_check_plane_state_test {
> + const char *name;
> + const char *msg;
> + struct {
> + unsigned int x;
> + unsigned int y;
> + unsigned int w;
> + unsigned int h;
> + } src, src_expected;
> + struct {
> + int x;
> + int y;
> + unsigned int w;
> + unsigned int h;
> + } crtc, crtc_expected;
> + unsigned int rotation;
> + int min_scale;
> + int max_scale;
> + bool can_position;
> +};
> +
> +static int drm_plane_helper_init(struct kunit *test)
>  {
> - plane_state->src_x = src_x;
> - plane_state->src_y = src_y;
> - plane_state->src_w = src_w;
> - plane_state->src_h = src_h;
> + const struct drm_check_plane_state_test *params = test->param_value;
> + struct drm_plane *plane;
> + struct drm_framebuffer *fb;
> + struct drm_plane_state *mock;
> +
> + plane = kunit_kzalloc(test, sizeof(*plane), GFP_KERNEL);
> + KUNIT_ASSERT_NOT_NULL(test, plane);
> +
> + fb = kunit_kzalloc(test, sizeof(*fb), GFP_KERNEL);
> + KUNIT_ASSERT_NOT_NULL(test, fb);
> + fb->width = 2048;
> + fb->height = 2048;
> +
> + mock = kunit_kzalloc(test, sizeof(*mock), GFP_KERNEL);
> + KUNIT_ASSERT_NOT_NULL(test, mock);
> + mock->plane = plane;
> + mock->crtc = ZERO_SIZE_PTR;
> + mock->fb = fb;
> + mock->rotation = params->rotation;
> + mock->src_x = params->src.x;
> + mock->src_y = params->src.y;
> + mock->src_w = params->src.w;
> + mock->src_h = params->src.h;
> + mock->crtc_x = params->crtc.x;
> + mock->crtc_y = params->crtc.y;
> + mock->crtc_w = params->crtc.w;
> + mock->crtc_h = params->crtc.h;
> +
> + test->priv = mock;
> +
> + return 0;
>  }
>  
> -static bool check_src_eq(struct kunit *test, struct drm_plane_state 
> *plane_state,
> +static void check_src_eq(struct kunit *test, struct drm_plane_state 
> *plane_state,
>unsigned int src_x, unsigned int src_y,
>unsigned int src_w, unsigned int src_h)
>  {
>   struct drm_rect expected = DRM_RECT_INIT(src_x, src_y, src_w, src_h);
>  
> - if (plane_state->src.x1 < 0) {
> - kunit_err(test,
> -   "src x coordinate %x should never be below 0, src: " 
> DRM_RECT_FP_FMT,
> -   plane_state->src.x1, 
> DRM_RECT_FP_ARG(_state->src));
> - return false;
> - }
> - if (plane_state->src.y1 < 0) {
> - kunit_err(test,
> -   "src y coordinate %x 

Re: [PATCH v6 0/3] drm/bridge: ti-sn65dsi86: Basic DP support

2022-09-01 Thread Robert Foss
On Wed, 31 Aug 2022 at 10:27, Tomi Valkeinen
 wrote:
>
> Hi,
>
> v5 of the series can be found from:
>
> https://lore.kernel.org/all/20220824130034.196041-1-tomi.valkei...@ideasonboard.com/
>
> Changes to v5:
> - Drop the broken "check AUX errors better" patch
> - Fix sync pulse widths in "Reject modes with too large blanking"
> - Drop the text about eDP, detect and get_edid from the desc of
>   "Implement bridge connector operations"
>
>  Tomi
>
> Laurent Pinchart (2):
>   drm/bridge: ti-sn65dsi86: Support DisplayPort (non-eDP) mode
>   drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP
>
> Tomi Valkeinen (1):
>   drm/bridge: ti-sn65dsi86: Reject modes with too large blanking
>
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 72 +--
>  1 file changed, 69 insertions(+), 3 deletions(-)
>
> --
> 2.34.1
>

Applied to drm-misc-next.


Re: [PATCH v2 1/2] drm/cmdline-parser: Merge negative tests

2022-09-01 Thread Maíra Canal
Hi Michał

Applied both patches to drm-misc-next.

Best Regards,
- Maíra Canal

On 8/17/22 18:12, Michał Winiarski wrote:
> Negative tests can be expressed as a single parameterized test case,
> which highlights that we're following the same test logic (passing
> invalid cmdline and expecting drm_mode_parse_command_line_for_connector
> to fail), which improves readability.
> 
> v2: s/negative/invalid to be consistent with other testcases in DRM
> 
> Signed-off-by: Michał Winiarski 
> Tested-by: Maíra Canal 
> ---
>  .../gpu/drm/tests/drm_cmdline_parser_test.c   | 293 ++
>  1 file changed, 103 insertions(+), 190 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c 
> b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> index 59b29cdfdd35..3a46c7d6f2aa 100644
> --- a/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> +++ b/drivers/gpu/drm/tests/drm_cmdline_parser_test.c
> @@ -109,24 +109,6 @@ static void drm_cmdline_test_force_d_only(struct kunit 
> *test)
>   KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
>  }
>  
> -static void drm_cmdline_test_margin_only(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "m";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_interlace_only(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "i";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
>  static void drm_cmdline_test_res(struct kunit *test)
>  {
>   struct drm_cmdline_mode mode = { };
> @@ -149,42 +131,6 @@ static void drm_cmdline_test_res(struct kunit *test)
>   KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
>  }
>  
> -static void drm_cmdline_test_res_missing_x(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "x480";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_res_missing_y(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "1024x";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_res_bad_y(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "1024xtest";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
> -static void drm_cmdline_test_res_missing_y_bpp(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "1024x-24";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
>  static void drm_cmdline_test_res_vesa(struct kunit *test)
>  {
>   struct drm_cmdline_mode mode = { };
> @@ -274,15 +220,6 @@ static void drm_cmdline_test_res_bpp(struct kunit *test)
>   KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
>  }
>  
> -static void drm_cmdline_test_res_bad_bpp(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "720x480-test";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
>  static void drm_cmdline_test_res_refresh(struct kunit *test)
>  {
>   struct drm_cmdline_mode mode = { };
> @@ -306,15 +243,6 @@ static void drm_cmdline_test_res_refresh(struct kunit 
> *test)
>   KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_UNSPECIFIED);
>  }
>  
> -static void drm_cmdline_test_res_bad_refresh(struct kunit *test)
> -{
> - struct drm_cmdline_mode mode = { };
> - const char *cmdline = "720x480@refresh";
> -
> - KUNIT_EXPECT_FALSE(test, 
> drm_mode_parse_command_line_for_connector(cmdline,
> -
> _connector, ));
> -}
> -
>  static void drm_cmdline_test_res_bpp_refresh(struct kunit *test)
>  {
>   struct drm_cmdline_mode mode = { };
> @@ -411,15 +339,6 @@ static void 
> drm_cmdline_test_res_bpp_refresh_force_off(struct kunit *test)
>   KUNIT_EXPECT_EQ(test, mode.force, DRM_FORCE_OFF);
>  }
>  
> -static void 

Re: [PATCH v6 1/3] drm/bridge: ti-sn65dsi86: Reject modes with too large blanking

2022-09-01 Thread Robert Foss
On Wed, 31 Aug 2022 at 10:27, Tomi Valkeinen
 wrote:
>
> From: Tomi Valkeinen 
>
> The front and back porch registers are 8 bits, and pulse width registers
> are 15 bits, so reject any modes with larger periods.
>
> Signed-off-by: Tomi Valkeinen 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index 90bbabde1595..09d3c65fa2ba 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -747,6 +747,29 @@ ti_sn_bridge_mode_valid(struct drm_bridge *bridge,
> if (mode->clock > 594000)
> return MODE_CLOCK_HIGH;
>
> +   /*
> +* The front and back porch registers are 8 bits, and pulse width
> +* registers are 15 bits, so reject any modes with larger periods.
> +*/
> +
> +   if ((mode->hsync_start - mode->hdisplay) > 0xff)
> +   return MODE_HBLANK_WIDE;
> +
> +   if ((mode->vsync_start - mode->vdisplay) > 0xff)
> +   return MODE_VBLANK_WIDE;
> +
> +   if ((mode->hsync_end - mode->hsync_start) > 0x7fff)
> +   return MODE_HSYNC_WIDE;
> +
> +   if ((mode->vsync_end - mode->vsync_start) > 0x7fff)
> +   return MODE_VSYNC_WIDE;
> +
> +   if ((mode->htotal - mode->hsync_end) > 0xff)
> +   return MODE_HBLANK_WIDE;
> +
> +   if ((mode->vtotal - mode->vsync_end) > 0xff)
> +   return MODE_VBLANK_WIDE;
> +
> return MODE_OK;
>  }
>
> --
> 2.34.1
>


Reviewed-by: Robert Foss 


Re: [PATCH] drm/ttm: update bulk move object of ghost BO

2022-09-01 Thread Christian König

Am 01.09.22 um 13:11 schrieb Christian König:

Am 01.09.22 um 11:29 schrieb ZhenGuo Yin:

[Why]
Ghost BO is released with non-empty bulk move object. There is a
warning trace:
WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 
ttm_bo_release+0x2e1/0x2f0 [amdttm]

Call Trace:
   amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
   amdttm_bo_put+0x28/0x30 [amdttm]
   amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
   amdgpu_bo_move+0x1a8/0x770 [amdgpu]
   ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
   amdttm_bo_validate+0xbf/0x100 [amdttm]

[How]
The resource of ghost BO should be moved to LRU directly, instead of
using bulk move. The bulk move object of ghost BO should set to NULL
before function ttm_bo_move_to_lru_tail_unlocked.

Fixed:·5b951e487fd6bf5f·("drm/ttm:·fix·bulk·move·handling·v2")
Signed-off-by: ZhenGuo Yin 


Good catch, but the fix is not 100% correct. Please rather just NULL 
the member while initializing the BO structure.


E.g. something like this:

 
 fbo->base.pin_count = 0;
+fbo->base.bulk_move= NULL;
 if (bo->type != ttm_bo_type_sg)
 


On the other hand thinking about it that won't work either.

You need to set bulk_move to NULL manually in an else clauses or 
something like this.


Regards,
Christian.



Thanks,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c

index 1cbfb00c1d65..a90bbbd91910 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -238,6 +238,7 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,

    if (fbo->base.resource) {
  ttm_resource_set_bo(fbo->base.resource, >base);
+    ttm_bo_set_bulk_move(>base, NULL);
  bo->resource = NULL;
  }






Re: [PATCH] drm/ttm: update bulk move object of ghost BO

2022-09-01 Thread Christian König

Am 01.09.22 um 11:29 schrieb ZhenGuo Yin:

[Why]
Ghost BO is released with non-empty bulk move object. There is a
warning trace:
WARNING: CPU: 19 PID: 1582 at ttm/ttm_bo.c:366 ttm_bo_release+0x2e1/0x2f0 
[amdttm]
Call Trace:
   amddma_resv_reserve_fences+0x10d/0x1f0 [amdkcl]
   amdttm_bo_put+0x28/0x30 [amdttm]
   amdttm_bo_move_accel_cleanup+0x126/0x200 [amdttm]
   amdgpu_bo_move+0x1a8/0x770 [amdgpu]
   ttm_bo_handle_move_mem+0xb0/0x140 [amdttm]
   amdttm_bo_validate+0xbf/0x100 [amdttm]

[How]
The resource of ghost BO should be moved to LRU directly, instead of
using bulk move. The bulk move object of ghost BO should set to NULL
before function ttm_bo_move_to_lru_tail_unlocked.

Fixed:·5b951e487fd6bf5f·("drm/ttm:·fix·bulk·move·handling·v2")
Signed-off-by: ZhenGuo Yin 


Good catch, but the fix is not 100% correct. Please rather just NULL the 
member while initializing the BO structure.


E.g. something like this:

 
 fbo->base.pin_count = 0;
+fbo->base.bulk_move= NULL;
 if (bo->type != ttm_bo_type_sg)
 

Thanks,
Christian.


---
  drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1cbfb00c1d65..a90bbbd91910 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -238,6 +238,7 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
  
  	if (fbo->base.resource) {

ttm_resource_set_bo(fbo->base.resource, >base);
+   ttm_bo_set_bulk_move(>base, NULL);
bo->resource = NULL;
}
  




Re: [PATCH v17 00/10] Add MT8195 DisplayPort driver

2022-09-01 Thread AngeloGioacchino Del Regno

Il 01/09/22 06:41, Bo-Chen Chen ha scritto:

This patch is separated from v10 which is including dp driver, phy driver
and dpintf driver. This series is only contained the DisplayPort driver.


For the entire series:

Tested-by: AngeloGioacchino Del Regno 
Reviewed-by: AngeloGioacchino Del Regno 


Thanks!
Angelo



Bo-Chen Chen (4):
   drm/mediatek: dp: Add multiple bridge types support
   drm/mediatek: dp: Add multiple smc commands support
   drm/mediatek: dp: Add multiple calibration data formats support
   drm/mediatek: dp: Determine device of next_bridge

Guillaume Ranquet (2):
   drm/mediatek: dp: Add MT8195 External DisplayPort support
   drm/mediatek: dp: Audio support for MT8195

Jitao Shi (1):
   drm/mediatek: dp: Add hpd debounce

Markus Schneider-Pargmann (3):
   dt-bindings: mediatek,dp: Add Display Port binding
   video/hdmi: Add audio_infoframe packing for DP
   drm/mediatek: Add MT8195 Embedded DisplayPort driver

  .../display/mediatek/mediatek,dp.yaml |  116 +
  drivers/gpu/drm/mediatek/Kconfig  |9 +
  drivers/gpu/drm/mediatek/Makefile |2 +
  drivers/gpu/drm/mediatek/mtk_dp.c | 2661 +
  drivers/gpu/drm/mediatek/mtk_dp_reg.h |  356 +++
  drivers/video/hdmi.c  |   82 +-
  include/drm/display/drm_dp.h  |2 +
  include/linux/hdmi.h  |7 +-
  8 files changed, 3215 insertions(+), 20 deletions(-)
  create mode 100644 
Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
  create mode 100644 drivers/gpu/drm/mediatek/mtk_dp.c
  create mode 100644 drivers/gpu/drm/mediatek/mtk_dp_reg.h







Re: [PATCH v4 00/21] Move all drivers to a common dma-buf locking convention

2022-09-01 Thread Dmitry Osipenko
Hello Christian,

On 9/1/22 10:49, Christian König wrote:
> Hi Dmitry,
> 
> I've gone over this multiple times now and while it is still possible
> that we missed something I think that this should land now.

Thank you very much for the review!

> The whole topic is just to complicated that we can 100% sure guarantee
> that there isn't anything wrong with the locking, but lockdep and driver
> testing should allow us to quickly find remaining issues.

At least the most popular drivers should be okay. If anyone will find
issue introduced by this series, then indeed shouldn't be a problem to
fix it later on.

> Do you have commit rights to drm-misc-next or should I push it?

I got the drm-misc commit right two weeks ago, haven't pushed anything
there yet. Please let me try to do the push. I'll let you know if any
kind of help will be needed from you.

I'll wait for more acks/r-bs and then do the push.

-- 
Best regards,
Dmitry


Re: [PATCH v6 4/6] clk: qcom: gpucc-sc7280: Add cx collapse reset support

2022-09-01 Thread Dmitry Baryshkov

On 01/09/2022 13:34, Philipp Zabel wrote:

On Wed, Aug 31, 2022 at 10:48:25AM +0530, Akhil P Oommen wrote:

Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.

Signed-off-by: Akhil P Oommen 
Reviewed-by: Dmitry Baryshkov 
---

(no changes since v3)

Changes in v3:
- Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' (Krzysztof)

Changes in v2:
- Minor update to use the updated custom reset ops implementation

  drivers/clk/qcom/gpucc-sc7280.c | 10 ++
  1 file changed, 10 insertions(+)

diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/qcom/gpucc-sc7280.c
index 9a832f2..fece3f4 100644
--- a/drivers/clk/qcom/gpucc-sc7280.c
+++ b/drivers/clk/qcom/gpucc-sc7280.c
@@ -433,12 +433,22 @@ static const struct regmap_config 
gpu_cc_sc7280_regmap_config = {
.fast_io = true,
  };
  
+static const struct qcom_reset_ops cx_gdsc_reset = {

+   .reset = gdsc_wait_for_collapse,


This should be accompanied by a comment explaining the not-quite-reset
nature of this workaround, i.e. what is the prerequisite for this to
actually work as expected?


+};
+
+static const struct qcom_reset_map gpucc_sc7280_resets[] = {
+   [GPU_CX_COLLAPSE] = { .ops = _gdsc_reset, .priv = _gdsc },
+};
+
  static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
.config = _cc_sc7280_regmap_config,
.clks = gpu_cc_sc7280_clocks,
.num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
.gdscs = gpu_cc_sc7180_gdscs,
.num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
+   .resets = gpucc_sc7280_resets,
+   .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),


See my comment on patch 2. I think instead of adding a const struct
qcom_reset_ops * to gpucc_sc7280_resets, this should just add a const
struct reset_control * to gpu_cc_sc7280_desc.


While this will work for the sc7280, the platform that Akhil was 
developing, this will not work for other platforms (like sm8250), where 
the dispcc also provides traditional BCR resets.


--
With best wishes
Dmitry



Re: [PATCH v4 06/21] drm/i915: Prepare to dynamic dma-buf locking specification

2022-09-01 Thread Dmitry Osipenko
On 9/1/22 09:45, Christian König wrote:
> Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
>> Prepare i915 driver to the common dynamic dma-buf locking convention
>> by starting to use the unlocked versions of dma-buf API functions
>> and handling cases where importer now holds the reservation lock.
>>
>> Signed-off-by: Dmitry Osipenko 
> 
> Acked-by: Christian König , but it's probably
> best if somebody from the Intel guys take a look as well.

+ Chris Wilson, who touched locks of __i915_gem_free_objects() recently

>> ---
>>   drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c   |  2 +-
>>   drivers/gpu/drm/i915/gem/i915_gem_object.c   | 12 
>>   .../gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c | 16 
>>   3 files changed, 21 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> index f5062d0c6333..07eee1c09aaf 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>> @@ -72,7 +72,7 @@ static int i915_gem_dmabuf_vmap(struct dma_buf
>> *dma_buf,
>>   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
>>   void *vaddr;
>>   -    vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>> +    vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
>>   if (IS_ERR(vaddr))
>>   return PTR_ERR(vaddr);
>>   diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> index 389e9f157ca5..7e2a9b02526c 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct
>> drm_i915_private *i915,
>>   continue;
>>   }
>>   +    /*
>> + * dma_buf_unmap_attachment() requires reservation to be
>> + * locked. The imported GEM shouldn't share reservation lock,
>> + * so it's safe to take the lock.
>> + */
>> +    if (obj->base.import_attach)
>> +    i915_gem_object_lock(obj, NULL);
>> +
>>   __i915_gem_object_pages_fini(obj);
>> +
>> +    if (obj->base.import_attach)
>> +    i915_gem_object_unlock(obj);
>> +
>>   __i915_gem_free_object(obj);
>>     /* But keep the pointer alive for RCU-protected lookups */
>> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> index 62c61af77a42..9e3ed634aa0e 100644
>> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
>> @@ -213,7 +213,7 @@ static int igt_dmabuf_import_same_driver(struct
>> drm_i915_private *i915,
>>   goto out_import;
>>   }
>>   -    st = dma_buf_map_attachment(import_attach, DMA_BIDIRECTIONAL);
>> +    st = dma_buf_map_attachment_unlocked(import_attach,
>> DMA_BIDIRECTIONAL);
>>   if (IS_ERR(st)) {
>>   err = PTR_ERR(st);
>>   goto out_detach;
>> @@ -226,7 +226,7 @@ static int igt_dmabuf_import_same_driver(struct
>> drm_i915_private *i915,
>>   timeout = -ETIME;
>>   }
>>   err = timeout > 0 ? 0 : timeout;
>> -    dma_buf_unmap_attachment(import_attach, st, DMA_BIDIRECTIONAL);
>> +    dma_buf_unmap_attachment_unlocked(import_attach, st,
>> DMA_BIDIRECTIONAL);
>>   out_detach:
>>   dma_buf_detach(dmabuf, import_attach);
>>   out_import:
>> @@ -296,7 +296,7 @@ static int igt_dmabuf_import(void *arg)
>>   goto out_obj;
>>   }
>>   -    err = dma_buf_vmap(dmabuf, );
>> +    err = dma_buf_vmap_unlocked(dmabuf, );
>>   dma_map = err ? NULL : map.vaddr;
>>   if (!dma_map) {
>>   pr_err("dma_buf_vmap failed\n");
>> @@ -337,7 +337,7 @@ static int igt_dmabuf_import(void *arg)
>>     err = 0;
>>   out_dma_map:
>> -    dma_buf_vunmap(dmabuf, );
>> +    dma_buf_vunmap_unlocked(dmabuf, );
>>   out_obj:
>>   i915_gem_object_put(obj);
>>   out_dmabuf:
>> @@ -358,7 +358,7 @@ static int igt_dmabuf_import_ownership(void *arg)
>>   if (IS_ERR(dmabuf))
>>   return PTR_ERR(dmabuf);
>>   -    err = dma_buf_vmap(dmabuf, );
>> +    err = dma_buf_vmap_unlocked(dmabuf, );
>>   ptr = err ? NULL : map.vaddr;
>>   if (!ptr) {
>>   pr_err("dma_buf_vmap failed\n");
>> @@ -367,7 +367,7 @@ static int igt_dmabuf_import_ownership(void *arg)
>>   }
>>     memset(ptr, 0xc5, PAGE_SIZE);
>> -    dma_buf_vunmap(dmabuf, );
>> +    dma_buf_vunmap_unlocked(dmabuf, );
>>     obj = to_intel_bo(i915_gem_prime_import(>drm, dmabuf));
>>   if (IS_ERR(obj)) {
>> @@ -418,7 +418,7 @@ static int igt_dmabuf_export_vmap(void *arg)
>>   }
>>   i915_gem_object_put(obj);
>>   -    err = dma_buf_vmap(dmabuf, );
>> +    err = dma_buf_vmap_unlocked(dmabuf, );
>>   ptr = err ? NULL : map.vaddr;
>>   if (!ptr) {
>>   pr_err("dma_buf_vmap failed\n");
>> @@ -435,7 +435,7 @@ static int 

Re: [PATCH v4 09/21] drm/etnaviv: Prepare to dynamic dma-buf locking specification

2022-09-01 Thread Dmitry Osipenko
On 9/1/22 09:50, Christian König wrote:
> Am 31.08.22 um 17:37 schrieb Dmitry Osipenko:
>> Prepare Etnaviv driver to the common dynamic dma-buf locking convention
>> by starting to use the unlocked versions of dma-buf API functions.
>>
>> Signed-off-by: Dmitry Osipenko 
> 
> Interesting, where is the matching vmap()?
> 
> Anyway, this patch is Acked-by: Christian König 

Etnaviv maps GEM only once and then unmaps it when GEM is destroyed. The
dma-buf vmapping should happen under the reservation lock, hence only
the release function needs to be changed to the unlocked variant.

Lucas/Christian(Gmeiner), could you please check that I haven't missed
anything?

>> ---
>>   drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> index 3fa2da149639..7031db145a77 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c
>> @@ -65,7 +65,7 @@ static void etnaviv_gem_prime_release(struct
>> etnaviv_gem_object *etnaviv_obj)
>>   struct iosys_map map = IOSYS_MAP_INIT_VADDR(etnaviv_obj->vaddr);
>>     if (etnaviv_obj->vaddr)
>> -    dma_buf_vunmap(etnaviv_obj->base.import_attach->dmabuf, );
>> +   
>> dma_buf_vunmap_unlocked(etnaviv_obj->base.import_attach->dmabuf, );
>>     /* Don't drop the pages for imported dmabuf, as they are not
>>    * ours, just free the array we allocated:
> 


-- 
Best regards,
Dmitry


Re: [PATCH v6 4/6] clk: qcom: gpucc-sc7280: Add cx collapse reset support

2022-09-01 Thread Philipp Zabel
On Wed, Aug 31, 2022 at 10:48:25AM +0530, Akhil P Oommen wrote:
> Allow a consumer driver to poll for cx gdsc collapse through Reset
> framework.
> 
> Signed-off-by: Akhil P Oommen 
> Reviewed-by: Dmitry Baryshkov 
> ---
> 
> (no changes since v3)
> 
> Changes in v3:
> - Convert 'struct qcom_reset_ops cx_gdsc_reset' to 'static const' (Krzysztof)
> 
> Changes in v2:
> - Minor update to use the updated custom reset ops implementation
> 
>  drivers/clk/qcom/gpucc-sc7280.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/qcom/gpucc-sc7280.c
> index 9a832f2..fece3f4 100644
> --- a/drivers/clk/qcom/gpucc-sc7280.c
> +++ b/drivers/clk/qcom/gpucc-sc7280.c
> @@ -433,12 +433,22 @@ static const struct regmap_config 
> gpu_cc_sc7280_regmap_config = {
>   .fast_io = true,
>  };
>  
> +static const struct qcom_reset_ops cx_gdsc_reset = {
> + .reset = gdsc_wait_for_collapse,

This should be accompanied by a comment explaining the not-quite-reset
nature of this workaround, i.e. what is the prerequisite for this to
actually work as expected?

> +};
> +
> +static const struct qcom_reset_map gpucc_sc7280_resets[] = {
> + [GPU_CX_COLLAPSE] = { .ops = _gdsc_reset, .priv = _gdsc },
> +};
> +
>  static const struct qcom_cc_desc gpu_cc_sc7280_desc = {
>   .config = _cc_sc7280_regmap_config,
>   .clks = gpu_cc_sc7280_clocks,
>   .num_clks = ARRAY_SIZE(gpu_cc_sc7280_clocks),
>   .gdscs = gpu_cc_sc7180_gdscs,
>   .num_gdscs = ARRAY_SIZE(gpu_cc_sc7180_gdscs),
> + .resets = gpucc_sc7280_resets,
> + .num_resets = ARRAY_SIZE(gpucc_sc7280_resets),

See my comment on patch 2. I think instead of adding a const struct
qcom_reset_ops * to gpucc_sc7280_resets, this should just add a const
struct reset_control * to gpu_cc_sc7280_desc.

regards
Philipp


Re: [PATCH v6 3/6] clk: qcom: gdsc: Add a reset op to poll gdsc collapse

2022-09-01 Thread Philipp Zabel
On Wed, Aug 31, 2022 at 10:48:24AM +0530, Akhil P Oommen wrote:
> Add a reset op compatible function to poll for gdsc collapse.
> 
> Signed-off-by: Akhil P Oommen 
> Reviewed-by: Dmitry Baryshkov 
> ---
> 
> (no changes since v2)
> 
> Changes in v2:
> - Minor update to function prototype
> 
>  drivers/clk/qcom/gdsc.c | 23 +++
>  drivers/clk/qcom/gdsc.h |  7 +++
>  2 files changed, 26 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
> index 44520ef..2d0f1d1 100644
> --- a/drivers/clk/qcom/gdsc.c
> +++ b/drivers/clk/qcom/gdsc.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include "gdsc.h"
> +#include "reset.h"
>  
>  #define PWR_ON_MASK  BIT(31)
>  #define EN_REST_WAIT_MASKGENMASK_ULL(23, 20)
> @@ -116,7 +117,8 @@ static int gdsc_hwctrl(struct gdsc *sc, bool en)
>   return regmap_update_bits(sc->regmap, sc->gdscr, HW_CONTROL_MASK, val);
>  }
>  
> -static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status)
> +static int gdsc_poll_status(struct gdsc *sc, enum gdsc_status status,
> + s64 timeout_us, unsigned int interval_ms)
>  {
>   ktime_t start;
>  
> @@ -124,7 +126,9 @@ static int gdsc_poll_status(struct gdsc *sc, enum 
> gdsc_status status)
>   do {
>   if (gdsc_check_status(sc, status))
>   return 0;
> - } while (ktime_us_delta(ktime_get(), start) < TIMEOUT_US);
> + if (interval_ms)
> + msleep(interval_ms);
> + } while (ktime_us_delta(ktime_get(), start) < timeout_us);

Could this loop be implemented with read_poll_timeout()?

>   if (gdsc_check_status(sc, status))
>   return 0;
> @@ -172,7 +176,7 @@ static int gdsc_toggle_logic(struct gdsc *sc, enum 
> gdsc_status status)
>   udelay(1);
>   }
>  
> - ret = gdsc_poll_status(sc, status);
> + ret = gdsc_poll_status(sc, status, TIMEOUT_US, 0);
>   WARN(ret, "%s status stuck at 'o%s'", sc->pd.name, status ? "ff" : "n");
>  
>   if (!ret && status == GDSC_OFF && sc->rsupply) {
> @@ -343,7 +347,7 @@ static int _gdsc_disable(struct gdsc *sc)
>*/
>   udelay(1);
>  
> - ret = gdsc_poll_status(sc, GDSC_ON);
> + ret = gdsc_poll_status(sc, GDSC_ON, TIMEOUT_US, 0);
>   if (ret)
>   return ret;
>   }
> @@ -565,3 +569,14 @@ int gdsc_gx_do_nothing_enable(struct generic_pm_domain 
> *domain)
>   return 0;
>  }
>  EXPORT_SYMBOL_GPL(gdsc_gx_do_nothing_enable);
> +
> +int gdsc_wait_for_collapse(void *priv)
> +{
> + struct gdsc *sc = priv;
> + int ret;
> +
> + ret = gdsc_poll_status(sc, GDSC_OFF, 50, 5);
> + WARN(ret, "%s status stuck at 'on'", sc->pd.name);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(gdsc_wait_for_collapse);

Superficially, using this as a reset op seems like abuse of the reset
controller API. Calling reset_control_reset() on this in the GPU driver
will not trigger a reset signal on the GPU's "cx_collapse" reset input.

So at the very least, this patchset should contain an explanation why
this is a good idea regardless, and how this is almost a reset control.

I have read the linked discussion, and I'm not sure I understand all
of it, so please correct me if I'm wrong: There is some other way to
force the GDSC into a state that will eventually cause a GPU reset, and
this is just the remaining part to make sure that the workaround dance
is finished?

If so, it should be explained that this depends on something else to
actually indirectly trigger the reset, and where this happens.

regards
Philipp


[PATCH v6 09/12] dt-bindings: display/msm: split dpu-msm8998 into DPU and MDSS parts

2022-09-01 Thread Dmitry Baryshkov
In order to make the schema more readable, split dpu-msm8998 into the DPU
and MDSS parts, each one describing just a single device binding.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-msm8998.yaml | 161 ++
 .../bindings/display/msm/mdss-msm8998.yaml|  76 +
 2 files changed, 129 insertions(+), 108 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/mdss-msm8998.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
index 1e6b7e15f1c5..a71c49ba289a 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
@@ -9,143 +9,88 @@ title: Qualcomm Display DPU dt properties for MSM8998 target
 maintainers:
   - AngeloGioacchino Del Regno 
 
-description: |
-  Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
-  sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
tree
-  bindings of MDSS and DPU are mentioned for MSM8998 target.
+description: Device tree bindings for the MSM8998 DPU display controller.
 
 allOf:
-  - $ref: /schemas/display/msm/mdss-common.yaml#
+  - $ref: /schemas/display/msm/dpu-common.yaml#
 
 properties:
   compatible:
 items:
-  - const: qcom,msm8998-mdss
+  - const: qcom,msm8998-dpu
+
+  reg:
+items:
+  - description: Address offset and size for mdp register set
+  - description: Address offset and size for regdma register set
+  - description: Address offset and size for vbif register set
+  - description: Address offset and size for non-realtime vbif register set
+
+  reg-names:
+items:
+  - const: mdp
+  - const: regdma
+  - const: vbif
+  - const: vbif_nrt
 
   clocks:
 items:
-  - description: Display AHB clock
-  - description: Display AXI clock
+  - description: Display ahb clock
+  - description: Display axi clock
+  - description: Display mem-noc clock
   - description: Display core clock
+  - description: Display vsync clock
 
   clock-names:
 items:
   - const: iface
   - const: bus
+  - const: mnoc
   - const: core
-
-  iommus:
-maxItems: 1
-
-patternProperties:
-  "^display-controller@[0-9a-f]+$":
-type: object
-description: Node containing the properties of DPU.
-unevaluatedProperties: false
-
-allOf:
-  - $ref: /schemas/display/msm/dpu-common.yaml#
-
-properties:
-  compatible:
-items:
-  - const: qcom,msm8998-dpu
-
-  reg:
-items:
-  - description: Address offset and size for mdp register set
-  - description: Address offset and size for regdma register set
-  - description: Address offset and size for vbif register set
-  - description: Address offset and size for non-realtime vbif 
register set
-
-  reg-names:
-items:
-  - const: mdp
-  - const: regdma
-  - const: vbif
-  - const: vbif_nrt
-
-  clocks:
-items:
-  - description: Display ahb clock
-  - description: Display axi clock
-  - description: Display mem-noc clock
-  - description: Display core clock
-  - description: Display vsync clock
-
-  clock-names:
-items:
-  - const: iface
-  - const: bus
-  - const: mnoc
-  - const: core
-  - const: vsync
+  - const: vsync
 
 unevaluatedProperties: false
 
 examples:
   - |
 #include 
-#include 
 #include 
 
-mdss: display-subsystem@c90 {
-compatible = "qcom,msm8998-mdss";
-reg = <0x0c90 0x1000>;
-reg-names = "mdss";
+display-controller@c901000 {
+compatible = "qcom,msm8998-dpu";
+reg = <0x0c901000 0x8f000>,
+  <0x0c9a8e00 0xf0>,
+  <0x0c9b 0x2008>,
+  <0x0c9b8000 0x1040>;
+reg-names = "mdp", "regdma", "vbif", "vbif_nrt";
 
 clocks = < MDSS_AHB_CLK>,
  < MDSS_AXI_CLK>,
- < MDSS_MDP_CLK>;
-clock-names = "iface", "bus", "core";
-
-#address-cells = <1>;
-#interrupt-cells = <1>;
-#size-cells = <1>;
-
-interrupts = ;
-interrupt-controller;
-iommus = <_smmu 0>;
-
-power-domains = < MDSS_GDSC>;
-ranges;
-
-display-controller@c901000 {
-compatible = "qcom,msm8998-dpu";
-reg = <0x0c901000 0x8f000>,
-  <0x0c9a8e00 0xf0>,
-  <0x0c9b 0x2008>,
-  <0x0c9b8000 0x1040>;
-reg-names = "mdp", "regdma", "vbif", "vbif_nrt";
-
-clocks = < MDSS_AHB_CLK>,
- < MDSS_AXI_CLK>,
- < MNOC_AHB_CLK>,
- < MDSS_MDP_CLK>,
- < MDSS_VSYNC_CLK>;
-

[PATCH v6 12/12] dt-bindings: display/msm: add support for the display on SM8250

2022-09-01 Thread Dmitry Baryshkov
Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
SM8250 platform.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-sm8250.yaml  |  96 
 .../bindings/display/msm/mdss-common.yaml |   4 +-
 .../bindings/display/msm/mdss-sm8250.yaml | 106 ++
 3 files changed, 204 insertions(+), 2 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dpu-sm8250.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/msm/mdss-sm8250.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sm8250.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-sm8250.yaml
new file mode 100644
index ..9bc2ee4a6589
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sm8250.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-sm8250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU dt properties for SM8250
+
+maintainers:
+  - Dmitry Baryshkov 
+
+description: |
+  Device tree bindings for the DPU display controller for SM8250 target.
+
+allOf:
+  - $ref: /schemas/display/msm/dpu-common.yaml#
+
+properties:
+  compatible:
+const: qcom,sm8250-dpu
+
+  reg:
+items:
+  - description: Address offset and size for mdp register set
+  - description: Address offset and size for vbif register set
+
+  reg-names:
+items:
+  - const: mdp
+  - const: vbif
+
+  clocks:
+items:
+  - description: Display ahb clock
+  - description: Display hf axi clock
+  - description: Display core clock
+  - description: Display vsync clock
+
+  clock-names:
+items:
+  - const: iface
+  - const: bus
+  - const: core
+  - const: vsync
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+#include 
+#include 
+
+display-controller@ae01000 {
+  compatible = "qcom,sm8250-dpu";
+  reg = <0x0ae01000 0x8f000>,
+<0x0aeb 0x2008>;
+  reg-names = "mdp", "vbif";
+
+  clocks = < DISP_CC_MDSS_AHB_CLK>,
+   < GCC_DISP_HF_AXI_CLK>,
+   < DISP_CC_MDSS_MDP_CLK>,
+   < DISP_CC_MDSS_VSYNC_CLK>;
+  clock-names = "iface", "bus", "core", "vsync";
+
+  assigned-clocks = < DISP_CC_MDSS_VSYNC_CLK>;
+  assigned-clock-rates = <1920>;
+
+  operating-points-v2 = <_opp_table>;
+  power-domains = < SM8250_MMCX>;
+
+  interrupt-parent = <>;
+  interrupts = <0>;
+
+  ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+  reg = <0>;
+  endpoint {
+remote-endpoint = <_in>;
+  };
+};
+
+port@1 {
+  reg = <1>;
+  endpoint {
+remote-endpoint = <_in>;
+  };
+};
+  };
+};
+...
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml 
b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
index 053c1e889552..a0a54cd63100 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-common.yaml
@@ -27,11 +27,11 @@ properties:
 
   clocks:
 minItems: 2
-maxItems: 3
+maxItems: 4
 
   clock-names:
 minItems: 2
-maxItems: 3
+maxItems: 4
 
   interrupts:
 maxItems: 1
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-sm8250.yaml 
b/Documentation/devicetree/bindings/display/msm/mdss-sm8250.yaml
new file mode 100644
index ..d581d10fea2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/mdss-sm8250.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/mdss-sm8250.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display MDSS dt properties for SM8250 target
+
+maintainers:
+  - Krishna Manikandan 
+
+description: |
+  Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
+  sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
tree
+  bindings of MDSS are mentioned for SM8250 target.
+
+allOf:
+  - $ref: /schemas/display/msm/mdss-common.yaml#
+
+properties:
+  compatible:
+items:
+  - const: qcom,sm8250-mdss
+
+  clocks:
+items:
+  - description: Display AHB clock from gcc
+  - description: Display hf axi clock
+  - description: Display sf axi clock
+  - description: Display core clock
+
+  clock-names:
+items:
+  - const: iface
+  - const: bus
+  - const: nrt_bus
+  - const: core
+
+  iommus:
+maxItems: 1
+
+  interconnects:
+maxItems: 2
+
+  interconnect-names:
+maxItems: 2
+
+patternProperties:
+  "^display-controller@[0-9a-f]+$":
+type: object
+properties:
+

[PATCH v6 11/12] dt-bindings: display/msm: add missing device nodes to mdss-* schemas

2022-09-01 Thread Dmitry Baryshkov
Add missing device nodes (DSI, PHYs, DP/eDP) to the existing MDSS
schemas.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/mdss-msm8998.yaml| 12 +
 .../bindings/display/msm/mdss-qcm2290.yaml|  6 +
 .../bindings/display/msm/mdss-sc7180.yaml | 18 +
 .../bindings/display/msm/mdss-sc7280.yaml | 26 +++
 .../bindings/display/msm/mdss-sdm845.yaml | 12 +
 5 files changed, 74 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/mdss-msm8998.yaml 
b/Documentation/devicetree/bindings/display/msm/mdss-msm8998.yaml
index 3482468fb2d4..f00a48a24521 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-msm8998.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-msm8998.yaml
@@ -44,6 +44,18 @@ patternProperties:
   compatible:
 const: qcom,msm8998-dpu
 
+  "^dsi@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,mdss-dsi-ctrl
+
+  "^phy@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,dsi-phy-10nm-8998
+
 unevaluatedProperties: false
 
 examples:
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-qcm2290.yaml 
b/Documentation/devicetree/bindings/display/msm/mdss-qcm2290.yaml
index 7a6c3178f02c..1160c5435236 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-qcm2290.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-qcm2290.yaml
@@ -50,6 +50,12 @@ patternProperties:
   compatible:
 const: qcom,qcm2290-dpu
 
+  "^dsi@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,dsi-ctrl-6g-qcm2290
+
 unevaluatedProperties: false
 
 examples:
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-sc7180.yaml 
b/Documentation/devicetree/bindings/display/msm/mdss-sc7180.yaml
index 27d944f0e471..38e474ae90a3 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-sc7180.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-sc7180.yaml
@@ -50,6 +50,24 @@ patternProperties:
   compatible:
 const: qcom,sc7180-dpu
 
+  "^displayport-controller@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,sc7180-dp
+
+  "^dsi@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,mdss-dsi-ctrl
+
+  "^dsi-phy@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,dsi-phy-10nm
+
 unevaluatedProperties: false
 
 examples:
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-sc7280.yaml 
b/Documentation/devicetree/bindings/display/msm/mdss-sc7280.yaml
index db843412abf9..fcacbc5c5e2c 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-sc7280.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-sc7280.yaml
@@ -49,6 +49,32 @@ patternProperties:
   compatible:
 const: qcom,sc7280-dpu
 
+  "^displayport-controller@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,sc7280-dp
+
+  "^dsi@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,mdss-dsi-ctrl
+
+  "^edp@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,sc7280-edp
+
+  "^phy@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+enum:
+  - qcom,sc7280-dsi-phy-7nm
+  - qcom,sc7280-edp-phy
+
 unevaluatedProperties: false
 
 examples:
diff --git a/Documentation/devicetree/bindings/display/msm/mdss-sdm845.yaml 
b/Documentation/devicetree/bindings/display/msm/mdss-sdm845.yaml
index 0bc148f7fbd9..09a8aa9837ea 100644
--- a/Documentation/devicetree/bindings/display/msm/mdss-sdm845.yaml
+++ b/Documentation/devicetree/bindings/display/msm/mdss-sdm845.yaml
@@ -48,6 +48,18 @@ patternProperties:
   compatible:
 const: qcom,sdm845-dpu
 
+  "^dsi@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,mdss-dsi-ctrl
+
+  "^dsi-phy@[0-9a-f]+$":
+type: object
+properties:
+  compatible:
+const: qcom,dsi-phy-10nm
+
 unevaluatedProperties: false
 
 examples:
-- 
2.35.1



[PATCH v6 06/12] dt-bindings: display/msm: split dpu-sc7180 into DPU and MDSS parts

2022-09-01 Thread Dmitry Baryshkov
In order to make the schema more readable, split dpu-sc7180 into the DPU
and MDSS parts, each one describing just a single device binding.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-sc7180.yaml  | 185 ++
 .../bindings/display/msm/mdss-sc7180.yaml |  85 
 2 files changed, 146 insertions(+), 124 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/mdss-sc7180.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
index 47e74f78e939..0ed64fe065c2 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
@@ -9,81 +9,43 @@ title: Qualcomm Display DPU dt properties for SC7180 target
 maintainers:
   - Krishna Manikandan 
 
-description: |
-  Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
-  sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
tree
-  bindings of MDSS and DPU are mentioned for SC7180 target.
+description: Device tree bindings for the SC7180 DPU display controller.
 
 allOf:
-  - $ref: /schemas/display/msm/mdss-common.yaml#
+  - $ref: /schemas/display/msm/dpu-common.yaml#
 
 properties:
   compatible:
 items:
-  - const: qcom,sc7180-mdss
+  - const: qcom,sc7180-dpu
+
+  reg:
+items:
+  - description: Address offset and size for mdp register set
+  - description: Address offset and size for vbif register set
+
+  reg-names:
+items:
+  - const: mdp
+  - const: vbif
 
   clocks:
 items:
-  - description: Display AHB clock from gcc
-  - description: Display AHB clock from dispcc
+  - description: Display hf axi clock
+  - description: Display ahb clock
+  - description: Display rotator clock
+  - description: Display lut clock
   - description: Display core clock
+  - description: Display vsync clock
 
   clock-names:
 items:
+  - const: bus
   - const: iface
-  - const: ahb
+  - const: rot
+  - const: lut
   - const: core
-
-  iommus:
-maxItems: 1
-
-  interconnects:
-maxItems: 1
-
-  interconnect-names:
-maxItems: 1
-
-patternProperties:
-  "^display-controller@[0-9a-f]+$":
-type: object
-description: Node containing the properties of DPU.
-unevaluatedProperties: false
-
-allOf:
-  - $ref: /schemas/display/msm/dpu-common.yaml#
-
-properties:
-  compatible:
-items:
-  - const: qcom,sc7180-dpu
-
-  reg:
-items:
-  - description: Address offset and size for mdp register set
-  - description: Address offset and size for vbif register set
-
-  reg-names:
-items:
-  - const: mdp
-  - const: vbif
-
-  clocks:
-items:
-  - description: Display hf axi clock
-  - description: Display ahb clock
-  - description: Display rotator clock
-  - description: Display lut clock
-  - description: Display core clock
-  - description: Display vsync clock
-
-  clock-names:
-items:
-  - const: bus
-  - const: iface
-  - const: rot
-  - const: lut
-  - const: core
-  - const: vsync
+  - const: vsync
 
 unevaluatedProperties: false
 
@@ -91,71 +53,46 @@ examples:
   - |
 #include 
 #include 
-#include 
-#include 
 #include 
 
-display-subsystem@ae0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "qcom,sc7180-mdss";
- reg = <0xae0 0x1000>;
- reg-names = "mdss";
- power-domains = < MDSS_GDSC>;
- clocks = < GCC_DISP_AHB_CLK>,
-  < DISP_CC_MDSS_AHB_CLK>,
-  < DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface", "ahb", "core";
-
- interrupts = ;
- interrupt-controller;
- #interrupt-cells = <1>;
-
- interconnects = <_noc MASTER_MDP0 _virt SLAVE_EBI1>;
- interconnect-names = "mdp0-mem";
-
- iommus = <_smmu 0x800 0x2>;
- ranges;
-
- display-controller@ae01000 {
-   compatible = "qcom,sc7180-dpu";
-   reg = <0x0ae01000 0x8f000>,
- <0x0aeb 0x2008>;
-
-   reg-names = "mdp", "vbif";
-
-   clocks = < GCC_DISP_HF_AXI_CLK>,
-< DISP_CC_MDSS_AHB_CLK>,
-< DISP_CC_MDSS_ROT_CLK>,
-< DISP_CC_MDSS_MDP_LUT_CLK>,
-< DISP_CC_MDSS_MDP_CLK>,
-< DISP_CC_MDSS_VSYNC_CLK>;
-   clock-names = "bus", "iface", "rot", "lut", "core",
- "vsync";
-
-   interrupt-parent = <>;
-   interrupts = <0>;
-   

[PATCH v6 05/12] dt-bindings: display/msm: move common MDSS properties to mdss-common.yaml

2022-09-01 Thread Dmitry Baryshkov
Move properties common to all MDSS DT nodes to the mdss-common.yaml.

This extends qcom,msm8998-mdss schema to allow interconnect nodes, which
will be added later, once msm8998 gains interconnect support.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-msm8998.yaml | 42 ++
 .../bindings/display/msm/dpu-qcm2290.yaml | 52 ++--
 .../bindings/display/msm/dpu-sc7180.yaml  | 51 ++--
 .../bindings/display/msm/dpu-sc7280.yaml  | 51 ++--
 .../bindings/display/msm/dpu-sdm845.yaml  | 55 ++--
 .../bindings/display/msm/mdss-common.yaml | 83 +++
 6 files changed, 116 insertions(+), 218 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/mdss-common.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
index 0d6743eabd27..1e6b7e15f1c5 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
@@ -14,20 +14,14 @@ description: |
   sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
tree
   bindings of MDSS and DPU are mentioned for MSM8998 target.
 
+allOf:
+  - $ref: /schemas/display/msm/mdss-common.yaml#
+
 properties:
   compatible:
 items:
   - const: qcom,msm8998-mdss
 
-  reg:
-maxItems: 1
-
-  reg-names:
-const: mdss
-
-  power-domains:
-maxItems: 1
-
   clocks:
 items:
   - description: Display AHB clock
@@ -40,23 +34,8 @@ properties:
   - const: bus
   - const: core
 
-  interrupts:
-maxItems: 1
-
-  interrupt-controller: true
-
-  "#address-cells": true
-
-  "#size-cells": true
-
-  "#interrupt-cells":
-const: 1
-
   iommus:
-items:
-  - description: Phandle to apps_smmu node with SID mask for Hard-Fail 
port0
-
-  ranges: true
+maxItems: 1
 
 patternProperties:
   "^display-controller@[0-9a-f]+$":
@@ -102,18 +81,7 @@ patternProperties:
   - const: core
   - const: vsync
 
-required:
-  - compatible
-  - reg
-  - reg-names
-  - power-domains
-  - clocks
-  - interrupts
-  - interrupt-controller
-  - iommus
-  - ranges
-
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
index bec3c131c0dc..1c6dd7969a61 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
@@ -14,20 +14,14 @@ description: |
   sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
   and DPU are mentioned for QCM2290 target.
 
+allOf:
+  - $ref: /schemas/display/msm/mdss-common.yaml#
+
 properties:
   compatible:
 items:
   - const: qcom,qcm2290-mdss
 
-  reg:
-maxItems: 1
-
-  reg-names:
-const: mdss
-
-  power-domains:
-maxItems: 1
-
   clocks:
 items:
   - description: Display AHB clock from gcc
@@ -40,35 +34,14 @@ properties:
   - const: bus
   - const: core
 
-  interrupts:
-maxItems: 1
-
-  interrupt-controller: true
-
-  "#address-cells": true
-
-  "#size-cells": true
-
-  "#interrupt-cells":
-const: 1
-
   iommus:
-items:
-  - description: Phandle to apps_smmu node with SID mask for Hard-Fail 
port0
-  - description: Phandle to apps_smmu node with SID mask for Hard-Fail 
port1
-
-  ranges: true
+maxItems: 2
 
   interconnects:
-items:
-  - description: Interconnect path specifying the port ids for data bus
+maxItems: 1
 
   interconnect-names:
-const: mdp0-mem
-
-  resets:
-items:
-  - description: MDSS_CORE reset
+maxItems: 1
 
 patternProperties:
   "^display-controller@[0-9a-f]+$":
@@ -110,18 +83,7 @@ patternProperties:
   - const: lut
   - const: vsync
 
-required:
-  - compatible
-  - reg
-  - reg-names
-  - power-domains
-  - clocks
-  - interrupts
-  - interrupt-controller
-  - iommus
-  - ranges
-
-additionalProperties: false
+unevaluatedProperties: false
 
 examples:
   - |
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
index 732b9d8f968a..47e74f78e939 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml
@@ -14,20 +14,14 @@ description: |
   sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
tree
   bindings of MDSS and DPU are mentioned for SC7180 target.
 
+allOf:
+  - $ref: /schemas/display/msm/mdss-common.yaml#
+
 properties:
   compatible:
 items:
   - const: qcom,sc7180-mdss
 
-  reg:
-maxItems: 1
-
-  reg-names:
-const: mdss
-
-  power-domains:
-maxItems: 1
-
   clocks:
 items:
   - description: Display AHB clock 

[PATCH v6 07/12] dt-bindings: display/msm: split dpu-sc7280 into DPU and MDSS parts

2022-09-01 Thread Dmitry Baryshkov
In order to make the schema more readable, split dpu-sc7280 into the DPU
and MDSS parts, each one describing just a single device binding.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-sc7280.yaml  | 194 ++
 .../bindings/display/msm/mdss-sc7280.yaml |  86 
 2 files changed, 151 insertions(+), 129 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/mdss-sc7280.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
index 7dc624a26e2e..ba15f1ade556 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7280.yaml
@@ -9,79 +9,42 @@ title: Qualcomm Display DPU dt properties for SC7280
 maintainers:
   - Krishna Manikandan 
 
-description: |
-  Device tree bindings for MSM Mobile Display Subsystem (MDSS) that 
encapsulates
-  sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
tree
-  bindings of MDSS and DPU are mentioned for SC7280.
+description: Device tree bindings for the SC7280 DPU display controller.
 
 allOf:
-  - $ref: /schemas/display/msm/mdss-common.yaml#
+  - $ref: /schemas/display/msm/dpu-common.yaml#
 
 properties:
   compatible:
-const: qcom,sc7280-mdss
+const: qcom,sc7280-dpu
+
+  reg:
+items:
+  - description: Address offset and size for mdp register set
+  - description: Address offset and size for vbif register set
+
+  reg-names:
+items:
+  - const: mdp
+  - const: vbif
 
   clocks:
 items:
-  - description: Display AHB clock from gcc
-  - description: Display AHB clock from dispcc
+  - description: Display hf axi clock
+  - description: Display sf axi clock
+  - description: Display ahb clock
+  - description: Display lut clock
   - description: Display core clock
+  - description: Display vsync clock
 
   clock-names:
 items:
+  - const: bus
+  - const: nrt_bus
   - const: iface
-  - const: ahb
+  - const: lut
   - const: core
-
-  iommus:
-maxItems: 1
-
-  interconnects:
-maxItems: 1
-
-  interconnect-names:
-maxItems: 1
-
-patternProperties:
-  "^display-controller@[0-9a-f]+$":
-type: object
-description: Node containing the properties of DPU.
-unevaluatedProperties: false
-
-allOf:
-  - $ref: /schemas/display/msm/dpu-common.yaml#
-
-properties:
-  compatible:
-const: qcom,sc7280-dpu
-
-  reg:
-items:
-  - description: Address offset and size for mdp register set
-  - description: Address offset and size for vbif register set
-
-  reg-names:
-items:
-  - const: mdp
-  - const: vbif
-
-  clocks:
-items:
-  - description: Display hf axi clock
-  - description: Display sf axi clock
-  - description: Display ahb clock
-  - description: Display lut clock
-  - description: Display core clock
-  - description: Display vsync clock
-
-  clock-names:
-items:
-  - const: bus
-  - const: nrt_bus
-  - const: iface
-  - const: lut
-  - const: core
-  - const: vsync
+  - const: vsync
 
 unevaluatedProperties: false
 
@@ -89,77 +52,50 @@ examples:
   - |
 #include 
 #include 
-#include 
-#include 
 #include 
 
-display-subsystem@ae0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "qcom,sc7280-mdss";
- reg = <0xae0 0x1000>;
- reg-names = "mdss";
- power-domains = < DISP_CC_MDSS_CORE_GDSC>;
- clocks = < GCC_DISP_AHB_CLK>,
-  < DISP_CC_MDSS_AHB_CLK>,
-  < DISP_CC_MDSS_MDP_CLK>;
- clock-names = "iface",
-   "ahb",
-   "core";
-
- interrupts = ;
- interrupt-controller;
- #interrupt-cells = <1>;
-
- interconnects = <_noc MASTER_MDP0 _virt SLAVE_EBI1>;
- interconnect-names = "mdp0-mem";
-
- iommus = <_smmu 0x900 0x402>;
- ranges;
-
- display-controller@ae01000 {
-   compatible = "qcom,sc7280-dpu";
-   reg = <0x0ae01000 0x8f000>,
- <0x0aeb 0x2008>;
-
-   reg-names = "mdp", "vbif";
-
-   clocks = < GCC_DISP_HF_AXI_CLK>,
-< GCC_DISP_SF_AXI_CLK>,
-< DISP_CC_MDSS_AHB_CLK>,
-< DISP_CC_MDSS_MDP_LUT_CLK>,
-< DISP_CC_MDSS_MDP_CLK>,
-< DISP_CC_MDSS_VSYNC_CLK>;
-   clock-names = "bus",
- "nrt_bus",
- "iface",
- "lut",
- 

[PATCH v6 10/12] dt-bindings: display/msm: split dpu-qcm2290 into DPU and MDSS parts

2022-09-01 Thread Dmitry Baryshkov
In order to make the schema more readable, split dpu-qcm2290 into the DPU
and MDSS parts, each one describing just a single device binding.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-qcm2290.yaml | 166 ++
 .../bindings/display/msm/mdss-qcm2290.yaml|  86 +
 2 files changed, 137 insertions(+), 115 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/mdss-qcm2290.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
index 1c6dd7969a61..93b4318e8fe3 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
@@ -9,79 +9,41 @@ title: Qualcomm Display DPU dt properties for QCM2290 target
 maintainers:
   - Loic Poulain 
 
-description: |
-  Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
-  sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS
-  and DPU are mentioned for QCM2290 target.
+description: Device tree bindings for the QCM2290 DPU display controller.
 
 allOf:
-  - $ref: /schemas/display/msm/mdss-common.yaml#
+  - $ref: /schemas/display/msm/dpu-common.yaml#
 
 properties:
   compatible:
 items:
-  - const: qcom,qcm2290-mdss
+  - const: qcom,qcm2290-dpu
+
+  reg:
+items:
+  - description: Address offset and size for mdp register set
+  - description: Address offset and size for vbif register set
+
+  reg-names:
+items:
+  - const: mdp
+  - const: vbif
 
   clocks:
 items:
-  - description: Display AHB clock from gcc
-  - description: Display AXI clock
-  - description: Display core clock
+  - description: Display AXI clock from gcc
+  - description: Display AHB clock from dispcc
+  - description: Display core clock from dispcc
+  - description: Display lut clock from dispcc
+  - description: Display vsync clock from dispcc
 
   clock-names:
 items:
-  - const: iface
   - const: bus
+  - const: iface
   - const: core
-
-  iommus:
-maxItems: 2
-
-  interconnects:
-maxItems: 1
-
-  interconnect-names:
-maxItems: 1
-
-patternProperties:
-  "^display-controller@[0-9a-f]+$":
-type: object
-description: Node containing the properties of DPU.
-unevaluatedProperties: false
-
-allOf:
-  - $ref: /schemas/display/msm/dpu-common.yaml#
-
-properties:
-  compatible:
-items:
-  - const: qcom,qcm2290-dpu
-
-  reg:
-items:
-  - description: Address offset and size for mdp register set
-  - description: Address offset and size for vbif register set
-
-  reg-names:
-items:
-  - const: mdp
-  - const: vbif
-
-  clocks:
-items:
-  - description: Display AXI clock from gcc
-  - description: Display AHB clock from dispcc
-  - description: Display core clock from dispcc
-  - description: Display lut clock from dispcc
-  - description: Display vsync clock from dispcc
-
-  clock-names:
-items:
-  - const: bus
-  - const: iface
-  - const: core
-  - const: lut
-  - const: vsync
+  - const: lut
+  - const: vsync
 
 unevaluatedProperties: false
 
@@ -89,63 +51,37 @@ examples:
   - |
 #include 
 #include 
-#include 
-#include 
 #include 
 
-mdss: mdss@5e0 {
-#address-cells = <1>;
-#size-cells = <1>;
-compatible = "qcom,qcm2290-mdss";
-reg = <0x05e0 0x1000>;
-reg-names = "mdss";
-power-domains = < MDSS_GDSC>;
-clocks = < GCC_DISP_AHB_CLK>,
- < GCC_DISP_HF_AXI_CLK>,
- < DISP_CC_MDSS_MDP_CLK>;
-clock-names = "iface", "bus", "core";
-
-interrupts = ;
-interrupt-controller;
-#interrupt-cells = <1>;
-
-interconnects = <_virt MASTER_MDP0  SLAVE_EBI1>;
-interconnect-names = "mdp0-mem";
-
-iommus = <_smmu 0x420 0x2>,
- <_smmu 0x421 0x0>;
-ranges;
-
-mdss_mdp: display-controller@5e01000 {
-compatible = "qcom,qcm2290-dpu";
-reg = <0x05e01000 0x8f000>,
-  <0x05eb 0x2008>;
-reg-names = "mdp", "vbif";
-
-clocks = < GCC_DISP_HF_AXI_CLK>,
- < DISP_CC_MDSS_AHB_CLK>,
- < DISP_CC_MDSS_MDP_CLK>,
- < DISP_CC_MDSS_MDP_LUT_CLK>,
- < DISP_CC_MDSS_VSYNC_CLK>;
-clock-names = "bus", "iface", "core", "lut", "vsync";
-
-operating-points-v2 = <_opp_table>;
-power-domains = < QCM2290_VDDCX>;
-
-interrupt-parent = <>;
-interrupts = <0>;
-
-ports {
- 

[PATCH v6 04/12] dt-bindings: display/msm: move common DPU properties to dpu-common.yaml

2022-09-01 Thread Dmitry Baryshkov
Move properties common to all DPU DT nodes to the dpu-common.yaml.

Note, this removes description of individual DPU port@ nodes. However
such definitions add no additional value. The reg values do not
correspond to hardware INTF indices. The driver discovers and binds
these ports not paying any care for the order of these items. Thus just
leave the reference to graph.yaml#/properties/ports and the description.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-common.yaml  | 44 ++
 .../bindings/display/msm/dpu-msm8998.yaml | 46 ++-
 .../bindings/display/msm/dpu-qcm2290.yaml | 41 ++---
 .../bindings/display/msm/dpu-sc7180.yaml  | 45 ++
 .../bindings/display/msm/dpu-sc7280.yaml  | 45 ++
 .../bindings/display/msm/dpu-sdm845.yaml  | 46 ++-
 6 files changed, 64 insertions(+), 203 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/dpu-common.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-common.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
new file mode 100644
index ..bf5764e9932b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/msm/dpu-common.yaml
@@ -0,0 +1,44 @@
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/msm/dpu-common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Display DPU dt properties (common properties)
+
+maintainers:
+  - Krishna Manikandan 
+  - Dmitry Baryshkov 
+  - Rob Clark 
+
+description: |
+  Common properties for QCom DPU display controller.
+
+properties:
+  interrupts:
+maxItems: 1
+
+  power-domains:
+maxItems: 1
+
+  operating-points-v2: true
+  opp-table:
+type: object
+
+  ports:
+$ref: /schemas/graph.yaml#/properties/ports
+description: |
+  Contains the list of output ports from DPU device. These ports
+  connect to interfaces that are external to the DPU hardware,
+  such as DSI, DP etc.
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - clocks
+  - interrupts
+  - power-domains
+  - operating-points-v2
+  - ports
+
+additionalProperties: true
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
index 253665c693e6..0d6743eabd27 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml
@@ -62,7 +62,10 @@ patternProperties:
   "^display-controller@[0-9a-f]+$":
 type: object
 description: Node containing the properties of DPU.
-additionalProperties: false
+unevaluatedProperties: false
+
+allOf:
+  - $ref: /schemas/display/msm/dpu-common.yaml#
 
 properties:
   compatible:
@@ -99,47 +102,6 @@ patternProperties:
   - const: core
   - const: vsync
 
-  interrupts:
-maxItems: 1
-
-  power-domains:
-maxItems: 1
-
-  operating-points-v2: true
-  opp-table:
-type: object
-
-  ports:
-$ref: /schemas/graph.yaml#/properties/ports
-description: |
-  Contains the list of output ports from DPU device. These ports
-  connect to interfaces that are external to the DPU hardware,
-  such as DSI, DP etc. Each output port contains an endpoint that
-  describes how it is connected to an external interface.
-
-properties:
-  port@0:
-$ref: /schemas/graph.yaml#/properties/port
-description: DPU_INTF1 (DSI1)
-
-  port@1:
-$ref: /schemas/graph.yaml#/properties/port
-description: DPU_INTF2 (DSI2)
-
-required:
-  - port@0
-  - port@1
-
-required:
-  - compatible
-  - reg
-  - reg-names
-  - clocks
-  - interrupts
-  - power-domains
-  - operating-points-v2
-  - ports
-
 required:
   - compatible
   - reg
diff --git a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
index c5824e1d2382..bec3c131c0dc 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml
@@ -74,7 +74,10 @@ patternProperties:
   "^display-controller@[0-9a-f]+$":
 type: object
 description: Node containing the properties of DPU.
-additionalProperties: false
+unevaluatedProperties: false
+
+allOf:
+  - $ref: /schemas/display/msm/dpu-common.yaml#
 
 properties:
   compatible:
@@ -107,42 +110,6 @@ patternProperties:
   - const: lut
   - const: vsync
 
-  interrupts:
-maxItems: 1
-
-  power-domains:
-maxItems: 1
-
-  operating-points-v2: true
-  opp-table:
-type: object
-
-  ports:
-$ref: /schemas/graph.yaml#/properties/ports
-

[PATCH v6 08/12] dt-bindings: display/msm: split dpu-sdm845 into DPU and MDSS parts

2022-09-01 Thread Dmitry Baryshkov
In order to make the schema more readable, split dpu-sdm845 into the DPU
and MDSS parts, each one describing just a single device binding.

Signed-off-by: Dmitry Baryshkov 
---
 .../bindings/display/msm/dpu-sdm845.yaml  | 170 ++
 .../bindings/display/msm/mdss-sdm845.yaml |  80 +
 2 files changed, 136 insertions(+), 114 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/msm/mdss-sdm845.yaml

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
index 7e9d7c7f3538..4440f1987ddd 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
@@ -9,77 +9,41 @@ title: Qualcomm Display DPU dt properties for SDM845 target
 maintainers:
   - Krishna Manikandan 
 
-description: |
-  Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates
-  sub-blocks like DPU display controller, DSI and DP interfaces etc. Device 
tree
-  bindings of MDSS and DPU are mentioned for SDM845 target.
+description: Device tree bindings for the SDM845 DPU display controller.
 
 allOf:
-  - $ref: /schemas/display/msm/mdss-common.yaml#
+  - $ref: /schemas/display/msm/dpu-common.yaml#
 
 properties:
   compatible:
 items:
-  - const: qcom,sdm845-mdss
+  - const: qcom,sdm845-dpu
+
+  reg:
+items:
+  - description: Address offset and size for mdp register set
+  - description: Address offset and size for vbif register set
+
+  reg-names:
+items:
+  - const: mdp
+  - const: vbif
 
   clocks:
 items:
-  - description: Display AHB clock from gcc
+  - description: Display GCC bus clock
+  - description: Display ahb clock
+  - description: Display axi clock
   - description: Display core clock
+  - description: Display vsync clock
 
   clock-names:
 items:
+  - const: gcc-bus
   - const: iface
+  - const: bus
   - const: core
-
-  iommus:
-maxItems: 2
-
-  interconnects:
-maxItems: 2
-
-  interconnect-names:
-maxItems: 2
-
-patternProperties:
-  "^display-controller@[0-9a-f]+$":
-type: object
-description: Node containing the properties of DPU.
-unevaluatedProperties: false
-
-allOf:
-  - $ref: /schemas/display/msm/dpu-common.yaml#
-
-properties:
-  compatible:
-items:
-  - const: qcom,sdm845-dpu
-
-  reg:
-items:
-  - description: Address offset and size for mdp register set
-  - description: Address offset and size for vbif register set
-
-  reg-names:
-items:
-  - const: mdp
-  - const: vbif
-
-  clocks:
-items:
-  - description: Display GCC bus clock
-  - description: Display ahb clock
-  - description: Display axi clock
-  - description: Display core clock
-  - description: Display vsync clock
-
-  clock-names:
-items:
-  - const: gcc-bus
-  - const: iface
-  - const: bus
-  - const: core
-  - const: vsync
+  - const: vsync
 
 unevaluatedProperties: false
 
@@ -87,65 +51,43 @@ examples:
   - |
 #include 
 #include 
-#include 
 #include 
 
-display-subsystem@ae0 {
-  #address-cells = <1>;
-  #size-cells = <1>;
-  compatible = "qcom,sdm845-mdss";
-  reg = <0x0ae0 0x1000>;
-  reg-names = "mdss";
-  power-domains = < MDSS_GDSC>;
-
-  clocks = < GCC_DISP_AHB_CLK>,
-   < DISP_CC_MDSS_MDP_CLK>;
-  clock-names = "iface", "core";
-
-  interrupts = ;
-  interrupt-controller;
-  #interrupt-cells = <1>;
-
-  iommus = <_smmu 0x880 0x8>,
-   <_smmu 0xc80 0x8>;
-  ranges;
-
-  display-controller@ae01000 {
-compatible = "qcom,sdm845-dpu";
-reg = <0x0ae01000 0x8f000>,
-  <0x0aeb 0x2008>;
-reg-names = "mdp", "vbif";
-
-clocks = < GCC_DISP_AXI_CLK>,
- < DISP_CC_MDSS_AHB_CLK>,
- < DISP_CC_MDSS_AXI_CLK>,
- < DISP_CC_MDSS_MDP_CLK>,
- < DISP_CC_MDSS_VSYNC_CLK>;
-clock-names = "gcc-bus", "iface", "bus", "core", "vsync";
-
-interrupt-parent = <>;
-interrupts = <0>;
-power-domains = < SDM845_CX>;
-operating-points-v2 = <_opp_table>;
-
-ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   port@0 {
-   reg = <0>;
-   dpu_intf1_out: endpoint {
- 

[PATCH v6 03/12] dt-bindings: display/msm: add interconnects property to qcom, mdss-smd845

2022-09-01 Thread Dmitry Baryshkov
Add interconnects required for the SDM845 MDSS device tree node. This
change was made in the commit c8c61c09e38b ("arm64: dts: qcom: sdm845:
Add interconnects property for display"), but was not reflected in the
schema.

Signed-off-by: Dmitry Baryshkov 
---
 .../devicetree/bindings/display/msm/dpu-sdm845.yaml| 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml 
b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
index 3cb2ae336996..ff19555d04e2 100644
--- a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml
@@ -57,6 +57,16 @@ properties:
 
   ranges: true
 
+  interconnects:
+items:
+  - description: Interconnect path specifying the port ids for data bus
+  - description: Interconnect path specifying the port ids for data bus
+
+  interconnect-names:
+items:
+  - const: mdp0-mem
+  - const: mdp1-mem
+
   resets:
 items:
   - description: MDSS_CORE reset
-- 
2.35.1



  1   2   >