Re: [PATCH 09/32] auxdisplay/ht16k33: Set FBINFO_VIRTFB flag

[Robin van der Gracht]

On 2023-11-15 11:19, Thomas Zimmermann wrote:

The ht16k33 driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.

Signed-off-by: Thomas Zimmermann 
Cc: Miguel Ojeda 
Cc: Robin van der Gracht 
---
 drivers/auxdisplay/ht16k33.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/auxdisplay/ht16k33.c 
b/drivers/auxdisplay/ht16k33.c

index 3a2d883872249..f1716e3ce6a92 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -640,6 +640,7 @@ static int ht16k33_fbdev_probe(struct device *dev,
struct ht16k33_priv *priv,

INIT_DELAYED_WORK(>work, ht16k33_fb_update);
fbdev->info->fbops = _fb_ops;
+   fbdev->info->flags |= FBINFO_VIRTFB;
fbdev->info->screen_buffer = fbdev->buffer;
fbdev->info->screen_size = HT16K33_FB_SIZE;
fbdev->info->fix = ht16k33_fb_fix;


Acked-by: Robin van der Gracht 

Re: [PATCH v5] Documentation/gpu: VM_BIND locking document

[Thomas Hellström]

On 11/21/23 14:56, Boris Brezillon wrote:

On Tue, 21 Nov 2023 11:40:46 +0100
Thomas Hellström  wrote:


Add the first version of the VM_BIND locking document which is
intended to be part of the xe driver upstreaming agreement.

The document describes and discuss the locking used during exec-
functions, evicton and for userptr gpu-vmas. Intention is to be using the
same nomenclature as the drm-vm-bind-async.rst.

v2:
- s/gvm/gpu_vm/g (Rodrigo Vivi)
- Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c
   (Rodrigo Vivi)
- Adjust commit message accordingly.
- Add SPDX license header.

v3:
- Large update to align with the drm_gpuvm manager locking
- Add "Efficient userptr gpu_vma exec function iteration" section
- Add "Locking at bind- and unbind time" section.

v4:
- Fix tabs vs space errors by untabifying (Rodrigo Vivi)
- Minor style fixes and typos (Rodrigo Vivi)
- Clarify situations where stale GPU mappings are occurring and how
   access through these mappings are blocked. (Rodrigo Vivi)
- Insert into the toctree in implementation_guidelines.rst

v5:
- Add a section about recoverable page-faults.
- Use local references to other documentation where possible
   (Bagas Sanjaya)
- General documentation fixes and typos (Danilo Krummrich and
   Boris Brezillon)
- Improve the documentation around locks that need to be grabbed from the
   dm-fence critical section (Boris Brezillon)
- Add more references to the DRM GPUVM helpers (Danilo Krummrich and
   Boriz Brezillon)
- Update the rfc/xe.rst document.

Cc: Rodrigo Vivi 
Signed-off-by: Thomas Hellström 

Still have a few comments (see below), and in general, I find some
sentences very long, which has the tendency of confusing me (always
trying to figure out what was the main point, what the pronouns are
referring to, etc). Anyway, I think it's better to have something
imperfect than nothing at all, so here is my

Reviewed-by: Boris Brezillon 

Feel free to add it even if you decide to ignore my comments.


Thanks for reviewing, Boris!

I'll make a final version incorporating much of the comments and 
suggestions, much appreciated.


I still think, though, that in principle the referral between gpuvm and 
this document should be the other way around, or it should all sit in 
gpuvm. In any case this is an initial version and as more comments and 
suggestions land, we can certainly update.


Thanks,

Thomas





---
  Documentation/core-api/pin_user_pages.rst |   2 +
  Documentation/gpu/drm-mm.rst  |   4 +
  Documentation/gpu/drm-vm-bind-locking.rst | 579 ++
  .../gpu/implementation_guidelines.rst |   1 +
  Documentation/gpu/rfc/xe.rst  |   5 +
  5 files changed, 591 insertions(+)
  create mode 100644 Documentation/gpu/drm-vm-bind-locking.rst

diff --git a/Documentation/core-api/pin_user_pages.rst 
b/Documentation/core-api/pin_user_pages.rst
index d3c1f6d8c0e0..6b5f7e6e7155 100644
--- a/Documentation/core-api/pin_user_pages.rst
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -153,6 +153,8 @@ NOTE: Some pages, such as DAX pages, cannot be pinned with 
longterm pins. That's
  because DAX pages do not have a separate page cache, and so "pinning" implies
  locking down file system blocks, which is not (yet) supported in that way.
  
+.. _mmu-notifier-registration-case:

+
  CASE 3: MMU notifier registration, with or without page faulting hardware
  -
  Device drivers can pin pages via get_user_pages*(), and register for mmu
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index acc5901ac840..d55751cad67c 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -466,6 +466,8 @@ DRM MM Range Allocator Function References
  .. kernel-doc:: drivers/gpu/drm/drm_mm.c
 :export:
  
+.. _drm_gpuvm:

+
  DRM GPUVM
  =
  
@@ -481,6 +483,8 @@ Split and Merge

  .. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
 :doc: Split and Merge
  
+.. _drm_gpuvm_locking:

+
  Locking
  ---
  
diff --git a/Documentation/gpu/drm-vm-bind-locking.rst b/Documentation/gpu/drm-vm-bind-locking.rst

new file mode 100644
index ..a7d08eccd50e
--- /dev/null
+++ b/Documentation/gpu/drm-vm-bind-locking.rst
@@ -0,0 +1,579 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+===
+VM_BIND locking
+===
+
+This document attempts to describe what's needed to get VM_BIND locking right,
+including the userptr mmu_notifier locking and it also discusses some

Could we split this long sentence like this?

including the userptr mmu_notifier locking. It also discusses ...


+optimizations to get rid of the looping through of all userptr mappings and
+external / shared object mappings that is needed in the simplest
+implementation. In addition there is a section describing the VM_BIND locking
+required for implementing recoverable pagefaults.
+
+The DRM GPUVM set of 

Re: [PATCH v3 05/11] drm/mediatek: Set DRM mode configs accordingly

[胡俊光]

[RFC 2/2] fpga: versal: Use the scatterlist interface

[Nava kishore Manne]

Allows drivers to request the Configuration image
be loaded from dma-able continuous buffer to avoid
needless memory pressure and delays due to multiple
copies.

Signed-off-by: Nava kishore Manne 
---
 drivers/fpga/versal-fpga.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/fpga/versal-fpga.c b/drivers/fpga/versal-fpga.c
index 3710e8f01be2..bf4fb4426417 100644
--- a/drivers/fpga/versal-fpga.c
+++ b/drivers/fpga/versal-fpga.c
@@ -19,6 +19,18 @@ static int versal_fpga_ops_write_init(struct fpga_manager 
*mgr,
return 0;
 }
 
+static int versal_fpga_ops_write_sg(struct fpga_manager *mgr,
+   struct sg_table *sgt)
+{
+   dma_addr_t dma_addr;
+   int ret;
+
+   dma_addr = sg_dma_address(sgt->sgl);
+   ret = zynqmp_pm_load_pdi(PDI_SRC_DDR, dma_addr);
+
+   return ret;
+}
+
 static int versal_fpga_ops_write(struct fpga_manager *mgr,
 const char *buf, size_t size)
 {
@@ -40,6 +52,7 @@ static int versal_fpga_ops_write(struct fpga_manager *mgr,
 static const struct fpga_manager_ops versal_fpga_ops = {
.write_init = versal_fpga_ops_write_init,
.write = versal_fpga_ops_write,
+   .write_sg = versal_fpga_ops_write_sg,
 };
 
 static int versal_fpga_probe(struct platform_device *pdev)
-- 
2.25.1

[RFC 1/2] fpga: support loading from a pre-allocated buffer

[Nava kishore Manne]

Some systems are memory constrained but they need to load very
large Configuration files. The FPGA subsystem allows drivers to
request this Configuration image be loaded from the filesystem,
but this requires that the entire configuration data be loaded
into kernel memory first before it's provided to the driver.
This can lead to a situation where we map the configuration
data twice, once to load the configuration data into kernel
memory and once to copy the configuration data into the final
resting place which is nothing but a dma-able continuous buffer.

This creates needless memory pressure and delays due to multiple
copies. Let's add a dmabuf handling support to the fpga manager
framework that allows drivers to load the Configuration data
directly from a pre-allocated buffer. This skips the intermediate
step of allocating a buffer in kernel memory to hold the
Configuration data.

Signed-off-by: Nava kishore Manne 
---
 drivers/fpga/fpga-mgr.c   | 113 ++
 include/linux/fpga/fpga-mgr.h |  10 +++
 2 files changed, 123 insertions(+)

diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index 06651389c592..23d2b4d45827 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -8,6 +8,8 @@
  * With code from the mailing list:
  * Copyright (C) 2013 Xilinx, Inc.
  */
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -519,6 +521,39 @@ static int fpga_mgr_buf_load(struct fpga_manager *mgr,
return rc;
 }
 
+static int fpga_dmabuf_load(struct fpga_manager *mgr,
+   struct fpga_image_info *info)
+{
+   struct dma_buf_attachment *attach;
+   struct sg_table *sgt;
+   int ret;
+
+   /* create attachment for dmabuf with the user device */
+   attach = dma_buf_attach(mgr->dmabuf, >dev);
+   if (IS_ERR(attach)) {
+   pr_err("failed to attach dmabuf\n");
+   ret = PTR_ERR(attach);
+   goto fail_put;
+   }
+
+   sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
+   if (IS_ERR(sgt)) {
+   ret = PTR_ERR(sgt);
+   goto fail_detach;
+   }
+
+   info->sgt = sgt;
+   ret = fpga_mgr_buf_load_sg(mgr, info, info->sgt);
+   dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
+
+fail_detach:
+   dma_buf_detach(mgr->dmabuf, attach);
+fail_put:
+   dma_buf_put(mgr->dmabuf);
+
+   return ret;
+}
+
 /**
  * fpga_mgr_firmware_load - request firmware and load to fpga
  * @mgr:   fpga manager
@@ -573,6 +608,8 @@ int fpga_mgr_load(struct fpga_manager *mgr, struct 
fpga_image_info *info)
 {
info->header_size = mgr->mops->initial_header_size;
 
+   if (mgr->flags & FPGA_MGR_CONFIG_DMA_BUF)
+   return fpga_dmabuf_load(mgr, info);
if (info->sgt)
return fpga_mgr_buf_load_sg(mgr, info, info->sgt);
if (info->buf && info->count)
@@ -732,6 +769,64 @@ void fpga_mgr_put(struct fpga_manager *mgr)
 }
 EXPORT_SYMBOL_GPL(fpga_mgr_put);
 
+static int fpga_dmabuf_fd_get(struct file *file, char __user *argp)
+{
+   struct fpga_manager *mgr =  (struct fpga_manager *)(file->private_data);
+   int buffd;
+
+   if (copy_from_user(, argp, sizeof(buffd)))
+   return -EFAULT;
+
+   mgr->dmabuf = dma_buf_get(buffd);
+   if (IS_ERR_OR_NULL(mgr->dmabuf))
+   return -EINVAL;
+
+   mgr->flags = FPGA_MGR_CONFIG_DMA_BUF;
+
+   return 0;
+}
+
+static int fpga_device_open(struct inode *inode, struct file *file)
+{
+   struct miscdevice *miscdev = file->private_data;
+   struct fpga_manager *mgr = container_of(miscdev,
+   struct fpga_manager, miscdev);
+
+   file->private_data = mgr;
+
+   return 0;
+}
+
+static int fpga_device_release(struct inode *inode, struct file *file)
+{
+   return 0;
+}
+
+static long fpga_device_ioctl(struct file *file, unsigned int cmd,
+ unsigned long arg)
+{
+   char __user *argp = (char __user *)arg;
+   int err;
+
+   switch (cmd) {
+   case FPGA_IOCTL_LOAD_DMA_BUFF:
+   err = fpga_dmabuf_fd_get(file, argp);
+   break;
+   default:
+   err = -ENOTTY;
+   }
+
+   return err;
+}
+
+static const struct file_operations fpga_fops = {
+   .owner  = THIS_MODULE,
+   .open   = fpga_device_open,
+   .release= fpga_device_release,
+   .unlocked_ioctl = fpga_device_ioctl,
+   .compat_ioctl   = fpga_device_ioctl,
+};
+
 /**
  * fpga_mgr_lock - Lock FPGA manager for exclusive use
  * @mgr:   fpga manager
@@ -815,10 +910,28 @@ fpga_mgr_register_full(struct device *parent, const 
struct fpga_manager_info *in
mgr->dev.of_node = parent->of_node;
mgr->dev.id = id;
 
+   /* Make device dma capable by inheriting from parent's */
+   set_dma_ops(>dev, get_dma_ops(parent));
+   ret = 

[RFC 0/2]fpga: Add fpga configuration support from a pre-allocated dma-able buffer

[Nava kishore Manne]

Lots of embedded systems have memory constraints but they need to load
very large configuration files.The FPGA subsystem allows drivers to
request this configuration image be loaded from the filesystem,but this
requires that the entire configuration data be loaded into kernel memory
first before it's provided to the driver.This can lead to a situation where
we map the configuration data twice, once to load the configuration data
into kernel memory and once to copy the configuration data into the final
resting place which is nothing but a dma-able continuous buffer.

This creates needless memory pressure and delays due to multiple copies.
Let's add a dmabuf handling support to the fpga manager framework that
allows drivers to load the Configuration data directly from a pre-allocated
buffer. This skips the intermediate step of allocating a buffer in kernel
memory to hold the Configuration data.

This implementation allows the lower-level drivers to request the FPGA
Configuration image be loaded from pre-allocated dma-able continuous
buffer and also it avoid needless memory pressure and delays due to
multiple copies.

Please take a look at the changes and let us know if any improvements
are required.

Nava kishore Manne (2):
  fpga: support loading from a pre-allocated buffer
  fpga: versal: Use the scatterlist interface

 drivers/fpga/fpga-mgr.c   | 113 ++
 drivers/fpga/versal-fpga.c|  13 
 include/linux/fpga/fpga-mgr.h |  10 +++
 3 files changed, 136 insertions(+)

-- 
2.25.1

[PATCH v2 RESEND] drm/panel: starry-2081101qfh032011-53g: Fine tune the panel power sequence

[xiazhengqiao]

For the "starry, 2081101qfh032011-53g" panel, it is stipulated in the
panel spec that MIPI needs to keep the LP11 state before the
lcm_reset pin is pulled high.

Fixes: 6069b66cd962 ("drm/panel: support for STARRY 2081101QFH032011-53G 
MIPI-DSI panel")
Signed-off-by: xiazhengqiao 
Reviewed-by: Jessica Zhang 
---
 drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c 
b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
index 4f370bc6dca8..4ed8c2e28d37 100644
--- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
+++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
@@ -1765,6 +1765,7 @@ static const struct panel_desc starry_qfh032011_53g_desc 
= {
.mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
  MIPI_DSI_MODE_LPM,
.init_cmds = starry_qfh032011_53g_init_cmd,
+   .lp11_before_reset = true,
 };
 
 static const struct drm_display_mode starry_himax83102_j02_default_mode = {
-- 
2.17.1

Re: [PATCH drm-misc-next 2/2] drm/nouveau: enable dynamic job-flow control

[Dave Airlie]

On Tue, 14 Nov 2023 at 10:27, Danilo Krummrich  wrote:
>
> Make use of the scheduler's credit limit and scheduler job's credit
> count to account for the actual size of a job, such that we fill up the
> ring efficiently.

For the two:

Reviewed-by: Dave Airlie 

>
> Signed-off-by: Danilo Krummrich 
> ---
>  drivers/gpu/drm/nouveau/nouveau_abi16.c | 3 ++-
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_exec.c  | 4 +++-
>  drivers/gpu/drm/nouveau/nouveau_sched.c | 9 -
>  drivers/gpu/drm/nouveau/nouveau_sched.h | 3 ++-
>  drivers/gpu/drm/nouveau/nouveau_uvmm.c  | 4 +++-
>  6 files changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
> b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> index f8e59cfb1d34..207945700c94 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
> @@ -316,7 +316,8 @@ nouveau_abi16_ioctl_channel_alloc(ABI16_IOCTL_ARGS)
> if (ret)
> goto done;
>
> -   ret = nouveau_sched_init(>sched, drm, drm->sched_wq);
> +   ret = nouveau_sched_init(>sched, drm, drm->sched_wq,
> +chan->chan->dma.ib_max);
> if (ret)
> goto done;
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index 7e5f19153829..6f6c31a9937b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -320,7 +320,7 @@ nouveau_cli_init(struct nouveau_drm *drm, const char 
> *sname,
>  * locks which indirectly or directly are held for allocations
>  * elsewhere.
>  */
> -   ret = nouveau_sched_init(>sched, drm, NULL);
> +   ret = nouveau_sched_init(>sched, drm, NULL, 1);
> if (ret)
> goto done;
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_exec.c 
> b/drivers/gpu/drm/nouveau/nouveau_exec.c
> index 388831c53551..63c344f4f78e 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_exec.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_exec.c
> @@ -258,10 +258,12 @@ nouveau_exec_job_init(struct nouveau_exec_job **pjob,
> }
> }
>
> +   args.file_priv = __args->file_priv;
> job->chan = __args->chan;
>
> args.sched = __args->sched;
> -   args.file_priv = __args->file_priv;
> +   /* Plus one to account for the HW fence. */
> +   args.credits = job->push.count + 1;
>
> args.in_sync.count = __args->in_sync.count;
> args.in_sync.s = __args->in_sync.s;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c 
> b/drivers/gpu/drm/nouveau/nouveau_sched.c
> index faabd662b165..6406d6659361 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_sched.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_sched.c
> @@ -12,7 +12,6 @@
>  #include "nouveau_abi16.h"
>  #include "nouveau_sched.h"
>
> -#define NOUVEAU_SCHED_HW_SUBMISSIONS   1
>  #define NOUVEAU_SCHED_JOB_TIMEOUT_MS   1
>
>  /* Starts at 0, since the DRM scheduler interprets those parameters as 
> (initial)
> @@ -85,10 +84,10 @@ nouveau_job_init(struct nouveau_job *job,
> ret = -ENOMEM;
> goto err_free_objs;
> }
> -
> }
>
> -   ret = drm_sched_job_init(>base, >entity, 1, NULL);
> +   ret = drm_sched_job_init(>base, >entity,
> +args->credits, NULL);
> if (ret)
> goto err_free_chains;
>
> @@ -396,7 +395,7 @@ static const struct drm_sched_backend_ops 
> nouveau_sched_ops = {
>
>  int
>  nouveau_sched_init(struct nouveau_sched *sched, struct nouveau_drm *drm,
> -  struct workqueue_struct *wq)
> +  struct workqueue_struct *wq, u32 credit_limit)
>  {
> struct drm_gpu_scheduler *drm_sched = >base;
> struct drm_sched_entity *entity = >entity;
> @@ -414,7 +413,7 @@ nouveau_sched_init(struct nouveau_sched *sched, struct 
> nouveau_drm *drm,
>
> ret = drm_sched_init(drm_sched, _sched_ops, wq,
>  NOUVEAU_SCHED_PRIORITY_COUNT,
> -NOUVEAU_SCHED_HW_SUBMISSIONS, 0, job_hang_limit,
> +credit_limit, 0, job_hang_limit,
>  NULL, NULL, "nouveau_sched", drm->dev->dev);
> if (ret)
> goto fail_wq;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.h 
> b/drivers/gpu/drm/nouveau/nouveau_sched.h
> index 026f33d9b70c..7ba8ffec135a 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_sched.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_sched.h
> @@ -27,6 +27,7 @@ enum nouveau_job_state {
>  struct nouveau_job_args {
> struct drm_file *file_priv;
> struct nouveau_sched *sched;
> +   u32 credits;
>
> enum dma_resv_usage resv_usage;
> bool sync;
> @@ -112,7 +113,7 @@ struct nouveau_sched {
>  };
>
>  int nouveau_sched_init(struct nouveau_sched *sched, 

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

[Stephen Rothwell]

Hi all,

On Wed, 22 Nov 2023 11:51:37 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
> 
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> 
> between commit:
> 
>   9031e0013f81 ("drm/amd/display: Fix mst hub unplug warning")
> 
> from Linus' tree and commit:
> 
>   191dc43935d1 ("drm/dp_mst: Store the MST PBN divider value in fixed point 
> format")
> 
> from the drm-intel tree.
> 
> I fixed it up (I just used the former) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Actually, the resolution I used is below.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index c7a29bb737e2,53e323b71d26..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@@ -209,11 -210,11 +210,11 @@@ static void dm_helpers_construct_old_pa
struct drm_dp_mst_atomic_payload *new_payload,
struct drm_dp_mst_atomic_payload *old_payload)
  {
 -  struct link_mst_stream_allocation_table current_link_table =
 -  
link->mst_stream_alloc_table;
 -  struct link_mst_stream_allocation *dc_alloc;
 -  int pbn_per_slot = dfixed_trunc(pbn_per_slot_fp);
 -  int i;
 +  struct drm_dp_mst_atomic_payload *pos;
-   int pbn_per_slot = mst_state->pbn_div;
++  int pbn_per_slot = dfixed_trunc(mst_state->pbn_div);
 +  u8 next_payload_vc_start = mgr->next_start_slot;
 +  u8 payload_vc_start = new_payload->vc_start_slot;
 +  u8 allocated_time_slots;
  
*old_payload = *new_payload;
  


pgpVoSOeah8YD.pgp
Description: OpenPGP digital signature

Re: [PATCH drm-misc-next] drm/nouveau: use GPUVM common infrastructure

[Dave Airlie]

On Tue, 14 Nov 2023 at 08:12, Danilo Krummrich  wrote:
>
> GPUVM provides common infrastructure to track external and evicted GEM
> objects as well as locking and validation helpers.
>
> Especially external and evicted object tracking is a huge improvement
> compared to the current brute force approach of iterating all mappings
> in order to lock and validate the GPUVM's GEM objects. Hence, make us of
> it.
>
> Signed-off-by: Danilo Krummrich 

Reviewed-by: Dave Airlie 

> ---
> Originally, this patch was part of [1]. However, while applying the series,
> I noticed that this patch needs another iteration, hence I held it back to
> rework it and send it separately.
>
> Changes since detached from [1]:
> 
> - Don't use drm_gpuvm_exec_lock() since it would, unnecessarily, lock all the
>   backing buffer's dma-resv locks. Instead, lock only the GEMs affected by the
>   requested mapping operations, directly or indirectly through map, remap or
>   unmap.
> - Validate backing buffers in drm_exec loop directly.
>
> [1] 
> https://lore.kernel.org/dri-devel/20231108001259.15123-1-d...@redhat.com/T/#u
> ---
>  drivers/gpu/drm/nouveau/nouveau_bo.c|   4 +-
>  drivers/gpu/drm/nouveau/nouveau_exec.c  |  57 +++---
>  drivers/gpu/drm/nouveau/nouveau_exec.h  |   4 -
>  drivers/gpu/drm/nouveau/nouveau_sched.c |   9 +-
>  drivers/gpu/drm/nouveau/nouveau_sched.h |   7 +-
>  drivers/gpu/drm/nouveau/nouveau_uvmm.c  | 134 +---
>  6 files changed, 100 insertions(+), 115 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index 7afad86da64b..b7dda486a7ea 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1061,17 +1061,18 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
> evict,
>  {
> struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
> struct nouveau_bo *nvbo = nouveau_bo(bo);
> +   struct drm_gem_object *obj = >base;
> struct ttm_resource *old_reg = bo->resource;
> struct nouveau_drm_tile *new_tile = NULL;
> int ret = 0;
>
> -
> if (new_reg->mem_type == TTM_PL_TT) {
> ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, new_reg);
> if (ret)
> return ret;
> }
>
> +   drm_gpuvm_bo_gem_evict(obj, evict);
> nouveau_bo_move_ntfy(bo, new_reg);
> ret = ttm_bo_wait_ctx(bo, ctx);
> if (ret)
> @@ -1136,6 +1137,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
> evict,
>  out_ntfy:
> if (ret) {
> nouveau_bo_move_ntfy(bo, bo->resource);
> +   drm_gpuvm_bo_gem_evict(obj, !evict);
> }
> return ret;
>  }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_exec.c 
> b/drivers/gpu/drm/nouveau/nouveau_exec.c
> index bf6c12f4342a..9d9835fb5970 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_exec.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_exec.c
> @@ -1,7 +1,5 @@
>  // SPDX-License-Identifier: MIT
>
> -#include 
> -
>  #include "nouveau_drv.h"
>  #include "nouveau_gem.h"
>  #include "nouveau_mem.h"
> @@ -86,14 +84,12 @@
>   */
>
>  static int
> -nouveau_exec_job_submit(struct nouveau_job *job)
> +nouveau_exec_job_submit(struct nouveau_job *job,
> +   struct drm_gpuvm_exec *vme)
>  {
> struct nouveau_exec_job *exec_job = to_nouveau_exec_job(job);
> struct nouveau_cli *cli = job->cli;
> struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(cli);
> -   struct drm_exec *exec = >exec;
> -   struct drm_gem_object *obj;
> -   unsigned long index;
> int ret;
>
> /* Create a new fence, but do not emit yet. */
> @@ -102,52 +98,29 @@ nouveau_exec_job_submit(struct nouveau_job *job)
> return ret;
>
> nouveau_uvmm_lock(uvmm);
> -   drm_exec_init(exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
> -   DRM_EXEC_IGNORE_DUPLICATES);
> -   drm_exec_until_all_locked(exec) {
> -   struct drm_gpuva *va;
> -
> -   drm_gpuvm_for_each_va(va, >base) {
> -   if (unlikely(va == >base.kernel_alloc_node))
> -   continue;
> -
> -   ret = drm_exec_prepare_obj(exec, va->gem.obj, 1);
> -   drm_exec_retry_on_contention(exec);
> -   if (ret)
> -   goto err_uvmm_unlock;
> -   }
> +   ret = drm_gpuvm_exec_lock(vme);
> +   if (ret) {
> +   nouveau_uvmm_unlock(uvmm);
> +   return ret;
> }
> nouveau_uvmm_unlock(uvmm);
>
> -   drm_exec_for_each_locked_object(exec, index, obj) {
> -   struct nouveau_bo *nvbo = nouveau_gem_object(obj);
> -
> -   ret = nouveau_bo_validate(nvbo, true, false);
> -   if (ret)
> -   goto err_exec_fini;
> +   ret = 

Re: [PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement

[Abhinav Kumar]

On 11/21/2023 4:27 PM, Rob Clark wrote:

On Tue, Nov 21, 2023 at 4:41 PM Abhinav Kumar  wrote:




On 10/24/2023 12:01 PM, Abhinav Kumar wrote:



On 10/23/2023 4:03 PM, Dmitry Baryshkov wrote:

On Tue, 24 Oct 2023 at 01:36, Rob Clark  wrote:


On Mon, Oct 23, 2023 at 3:30 PM Dmitry Baryshkov
 wrote:


On Tue, 24 Oct 2023 at 01:12, Rob Clark  wrote:


From: Rob Clark 

Seems like we need to pick INPUT_SEL=1 when CTM is enabled.  But not
otherwise.

Suggested-by: Dmitry Baryshkov 
Signed-off-by: Rob Clark 
---


I cannot find anything in the docs which suggest this solution is correct.

Different blocks in the DPU pipeline have their own CRC (MISR) registers
like LM, intf etc.

We dont need to change INPUT_SEL to tell DPU from which pipeline to take
the CRC from as each of them have their own registers.

INPUT_SEL is controlling whether the CRC needs to be calculated over the
entire display timings or only the active pixels. I am unable to tell at
the moment why this is making a difference in this use-case.

Since I am unable to find any documentation proving this solution is
correct so far, unfortunately I would hold this back till then.

We will investigate this issue and report our findings on this thread on
how to proceed.



Alright, we debugged and also found some more answers.

The correct solution is indeed to set INPUT_SEL = 1 but let me explain
why and what should be the correct way.

INPUT_SEL was indeed telling whether to compute CRC over active pixels
or active pixels + timings like I wrote before but this behavior changed
since some chipsets.

Now, INPUT_SEL = 0 means compute CRC *only* over timings and not the
active area (and not display + timings like before) and like mentioned
before this has nothing to do with what is the input to the CRC. Not
covering the active area will not change the CRC at all as Rob reported
but its not specific to CTM.

Which means we should have been setting INPUT_SEL=1 whenever we use INTF
CRC irrespective of whether CTM is used or not.

What this also means is INTF CRC was not working correctly at all so far
irrespecive of CTM or not because it was always computing CRC only on
the timings (non-active area).

This was not caught so far because it looks like IGT's
kms_pipe_crc_basic test which was used to validate this only compares
CRC between two frames of the same content to match if they were equal
and not changing contents and comparing like kms_plane does. It will
pass as CRC would not have changed.

Now coming to the fix, the reset value of this register INTF_MISR_CTRL
already sets the INPUT_SEL bit (or unsets it) correctly based on
whichever DPU version is used so we should just change the
dpu_hw_setup_misr() to a read on the register followed by ORing the
required bits without touching INPUT_SEL and write.

That will address this issue and also cover version control since the
expected value of this bit has changed across DPU revisions.


Ok, thanks for following up on this.  Mind posting a patch to
supersede this one?

BR,
-R



Yup, we will.

Thanks

Abhinav

   drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++-
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 ++--
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +-
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   | 2 +-
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 5 -
   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 3 ++-
   8 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 2b83a13b3aa9..d93a92ffd5df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -134,7 +134,7 @@ static void dpu_crtc_setup_encoder_misr(struct
drm_crtc *crtc)
  struct drm_encoder *drm_enc;

  drm_for_each_encoder_mask(drm_enc, crtc->dev,
crtc->state->encoder_mask)
-   dpu_encoder_setup_misr(drm_enc);
+   dpu_encoder_setup_misr(drm_enc, !!crtc->state->ctm);
   }

   static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const
char *src_name)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b0a7908418ed..12ee7acb5ea6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -241,7 +241,7 @@ int dpu_encoder_get_crc_values_cnt(const struct
drm_encoder *drm_enc)
  return num_intf;
   }

-void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc)
+void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc,
bool has_ctm)
   {
  struct dpu_encoder_virt *dpu_enc;

@@ -255,7 +255,7 @@ void dpu_encoder_setup_misr(const struct
drm_encoder *drm_enc)
  if (!phys->hw_intf || !phys->hw_intf->ops.setup_misr)
  continue;

-   

[PATCH] fbdev/simplefb: Suppress error on missing power domains

[Richard Acayan]

When the power domains are missing, the call to of_count_phandle_with_args
fails with -ENOENT. The power domains are not required and there are
some device trees that do not specify them. Suppress this error to fix
devices without power domains attached to simplefb.

Fixes: 92a511a568e4 ("fbdev/simplefb: Add support for generic power-domains")
Closes: https://lore.kernel.org/linux-fbdev/ZVwFNfkqjrvhFHM0@radian
Signed-off-by: Richard Acayan 
---
 drivers/video/fbdev/simplefb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index fe682af63827..6f58ee276ad1 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -466,6 +466,10 @@ static int simplefb_attach_genpds(struct simplefb_par *par,
err = of_count_phandle_with_args(dev->of_node, "power-domains",
 "#power-domain-cells");
if (err < 0) {
+   /* Nothing wrong if optional PDs are missing */
+   if (err == -ENOENT)
+   return 0;
+
dev_info(dev, "failed to parse power-domains: %d\n", err);
return err;
}
-- 
2.43.0

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

[Stephen Rothwell]

Hi all,

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

  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c

between commit:

  9031e0013f81 ("drm/amd/display: Fix mst hub unplug warning")

from Linus' tree and commit:

  191dc43935d1 ("drm/dp_mst: Store the MST PBN divider value in fixed point 
format")

from the drm-intel tree.

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

-- 
Cheers,
Stephen Rothwell


pgpaNTeId0dzL.pgp
Description: OpenPGP digital signature

[PATCH -next] drm/nouveau/fifo: Remove duplicated include in chan.c

[Yang Li]

./drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c: chid.h is included more than 
once.

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7603
Signed-off-by: Yang Li 
---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c | 1 -
 1 file changed, 1 deletion(-)

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

linux-next: manual merge of the drm tree with the drm-misc-fixes tree

[Stephen Rothwell]

Hi all,

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

  drivers/accel/ivpu/ivpu_hw_37xx.c

between commit:

  3f7c0634926d ("accel/ivpu/37xx: Fix hangs related to MMIO reset")

from the drm-misc-fixes tree and commits:

  3de6d9597892 ("accel/ivpu: Pass D0i3 residency time to the VPU firmware")
  cc19fedab8bd ("accel/ivpu/37xx: Print warning when VPUIP is not idle during 
power down")

from the drm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/accel/ivpu/ivpu_hw_37xx.c
index 4ccf1994b97a,4ab1f14cf360..
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@@ -720,14 -731,19 +733,14 @@@ static int ivpu_hw_37xx_power_down(stru
  {
int ret = 0;
  
-   if (!ivpu_hw_37xx_is_idle(vdev))
-   ivpu_warn(vdev, "VPU not idle during power down\n");
+   ivpu_hw_37xx_save_d0i3_entry_timestamp(vdev);
  
-   if (ivpu_hw_37xx_reset(vdev)) {
-   ivpu_err(vdev, "Failed to reset VPU\n");
-   ret = -EIO;
+   if (!ivpu_hw_37xx_is_idle(vdev)) {
+   ivpu_warn(vdev, "VPU not idle during power down\n");
+   if (ivpu_hw_37xx_reset(vdev))
+   ivpu_warn(vdev, "Failed to reset the VPU\n");
}
  
 -  if (ivpu_pll_disable(vdev)) {
 -  ivpu_err(vdev, "Failed to disable PLL\n");
 -  ret = -EIO;
 -  }
 -
if (ivpu_hw_37xx_d0i3_enable(vdev)) {
ivpu_err(vdev, "Failed to enter D0I3\n");
ret = -EIO;


pgpV9WtXbqKht.pgp
Description: OpenPGP digital signature

[PATCH v3 000/108] pwm: Fix lifetime issues for pwm_chips

[Uwe Kleine-König]

Hello,

this is v3 of the series improving life-time tracking for PWM chips. The
urgency is gone as device links now work as expected and so all
in-kernel users are fine since commit 2e84dc379200 ("driver core:
Release all resources during unbind before updating device links").

However proper lifetime tracking is a precondition to have robust
character device support, as we cannot kill a userspace process if the
used pwm driver goes away.

Changes since v2:

 - Cc: the relevant maintainers for wider testing/review audience
 - Rebase to v6.7-rc1 + 
https://lore.kernel.org/linux-pwm/20231121112029.gyv3gqirlycys...@pengutronix.de
 - Improvements for things pointed out during review and my own
   findings here and there.
 - Implementation for a few more ioctls in the WIP commit that adds
   character support

To go forward I'd like to get in patches up to #103 (i.e. adding
pwmchip_parent() (#2), devm_pwmchip_alloc() (#37) and the conversions of
the drivers to make use of these additions).

The few commits that touch drivers not living in drivers/pwm (i.e. #36,
#100-#103) can go in either via the pwm tree with the rest, or later
---when the used functions are in---via their trees.

After all in-tree drivers are prepared with the patches up to #103, we
can think about when and how we go on with the remaining bits.

Note that patch #104 breaks all drivers that don't use
devm_pwmchip_alloc(), so this is the commit that needs coordination with the
maintainers of

 drivers/gpio/gpio-mvebu.c
 drivers/gpu/drm/bridge/ti-sn65dsi86.c
 drivers/leds/rgb/leds-qcom-lpg.c
 drivers/staging/greybus/pwm.c

The motivation for this series is the last patch. It allows to control a
pwm device via ioctl. Compared to the sysfs API this already now has
some advantages:

- It changes all parameters in a single call.
  This simplifies things similar to the introduction of
  pwm_apply_state(). With sysfs it can happen that you want to
  switch polarity but that's refused because 

pwm_get_state(mypwm, );
state.polarity = new_value;

  sometimes yield an invalid state, e.g. because state.period is
  in some cases 0 after bootup. Theoretically it can even happen that you have
  to change two parameters before reaching an applicable state, then you're
  stuck with sysfs.

- It's faster than sysfs. In my measurements with stm32 about a factor
  4.

A userspace lib to make use of this can be found at
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/libpwm.git/ .
It makes use of the character devices if available and falls back to
sysfs. So it's somewhat useful already now.

Best regards
Uwe

Uwe Kleine-König (108):
  pwm: cros-ec: Change prototype of helper to prepare further changes
  pwm: Provide a macro to get the parent device of a given chip
  pwm: ab8500: Make use of pwmchip_parent() macro
  pwm: atmel: Make use of pwmchip_parent() macro
  pwm: atmel-tcb: Make use of pwmchip_parent() macro
  pwm: bcm-kona: Make use of pwmchip_parent() macro
  pwm: crc: Make use of pwmchip_parent() macro
  pwm: cros-ec: Make use of pwmchip_parent() macro
  pwm: dwc: Make use of pwmchip_parent() macro
  pwm: ep93xx: Make use of pwmchip_parent() macro
  pwm: fsl-ftm: Make use of pwmchip_parent() macro
  pwm: img: Make use of parent device pointer in driver data
  pwm: imx27: Make use of pwmchip_parent() macro
  pwm: jz4740: Make use of pwmchip_parent() macro
  pwm: lpc18xx-sct: Make use of parent device pointer in driver data
  pwm: lpss: Make use of pwmchip_parent() macro
  pwm: mediatek: Make use of pwmchip_parent() macro
  pwm: meson: Make use of pwmchip_parent() macro
  pwm: mtk-disp: Make use of pwmchip_parent() macro
  pwm: omap: Make use of pwmchip_parent() macro
  pwm: pca9685: Store parent device in driver data
  pwm: raspberrypi-poe: Make use of pwmchip_parent() macro
  pwm: rcar: Make use of pwmchip_parent() macro
  pwm: rz-mtu3: Make use of pwmchip_parent() macro
  pwm: samsung: Make use of pwmchip_parent() macro
  pwm: sifive: Make use of pwmchip_parent() macro
  pwm: stm32-lp: Make use of pwmchip_parent() macro
  pwm: stm32: Make use of pwmchip_parent() macro
  pwm: stmpe: Make use of pwmchip_parent() macro
  pwm: sun4i: Make use of pwmchip_parent() macro
  pwm: tiecap: Make use of pwmchip_parent() macro
  pwm: tiehrpwm: Make use of pwmchip_parent() macro
  pwm: twl-led: Make use of pwmchip_parent() macro
  pwm: twl: Make use of pwmchip_parent() macro
  pwm: vt8500: Make use of pwmchip_parent() macro
  staging: greybus: pwm: Make use of pwmchip_parent() macro
  pwm: Provide devm_pwmchip_alloc() function
  pwm: ab8500: Make use of devm_pwmchip_alloc() function
  pwm: apple: Make use of devm_pwmchip_alloc() function
  pwm: atmel-hlcdc: Make use of devm_pwmchip_alloc() function
  pwm: atmel: Make use of devm_pwmchip_alloc() function
  pwm: atmel-tcb: Make use of devm_pwmchip_alloc() function
  pwm: bcm2835: Make use of devm_pwmchip_alloc() function
  pwm: bcm-iproc: Make use of devm_pwmchip_alloc() function
  pwm: 

Re: [PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement

[Rob Clark]

On Tue, Nov 21, 2023 at 4:41 PM Abhinav Kumar  wrote:
>
>
>
> On 10/24/2023 12:01 PM, Abhinav Kumar wrote:
> >
> >
> > On 10/23/2023 4:03 PM, Dmitry Baryshkov wrote:
> >> On Tue, 24 Oct 2023 at 01:36, Rob Clark  wrote:
> >>>
> >>> On Mon, Oct 23, 2023 at 3:30 PM Dmitry Baryshkov
> >>>  wrote:
> 
>  On Tue, 24 Oct 2023 at 01:12, Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > Seems like we need to pick INPUT_SEL=1 when CTM is enabled.  But not
> > otherwise.
> >
> > Suggested-by: Dmitry Baryshkov 
> > Signed-off-by: Rob Clark 
> > ---
> >
> > I cannot find anything in the docs which suggest this solution is correct.
> >
> > Different blocks in the DPU pipeline have their own CRC (MISR) registers
> > like LM, intf etc.
> >
> > We dont need to change INPUT_SEL to tell DPU from which pipeline to take
> > the CRC from as each of them have their own registers.
> >
> > INPUT_SEL is controlling whether the CRC needs to be calculated over the
> > entire display timings or only the active pixels. I am unable to tell at
> > the moment why this is making a difference in this use-case.
> >
> > Since I am unable to find any documentation proving this solution is
> > correct so far, unfortunately I would hold this back till then.
> >
> > We will investigate this issue and report our findings on this thread on
> > how to proceed.
> >
>
> Alright, we debugged and also found some more answers.
>
> The correct solution is indeed to set INPUT_SEL = 1 but let me explain
> why and what should be the correct way.
>
> INPUT_SEL was indeed telling whether to compute CRC over active pixels
> or active pixels + timings like I wrote before but this behavior changed
> since some chipsets.
>
> Now, INPUT_SEL = 0 means compute CRC *only* over timings and not the
> active area (and not display + timings like before) and like mentioned
> before this has nothing to do with what is the input to the CRC. Not
> covering the active area will not change the CRC at all as Rob reported
> but its not specific to CTM.
>
> Which means we should have been setting INPUT_SEL=1 whenever we use INTF
> CRC irrespective of whether CTM is used or not.
>
> What this also means is INTF CRC was not working correctly at all so far
> irrespecive of CTM or not because it was always computing CRC only on
> the timings (non-active area).
>
> This was not caught so far because it looks like IGT's
> kms_pipe_crc_basic test which was used to validate this only compares
> CRC between two frames of the same content to match if they were equal
> and not changing contents and comparing like kms_plane does. It will
> pass as CRC would not have changed.
>
> Now coming to the fix, the reset value of this register INTF_MISR_CTRL
> already sets the INPUT_SEL bit (or unsets it) correctly based on
> whichever DPU version is used so we should just change the
> dpu_hw_setup_misr() to a read on the register followed by ORing the
> required bits without touching INPUT_SEL and write.
>
> That will address this issue and also cover version control since the
> expected value of this bit has changed across DPU revisions.

Ok, thanks for following up on this.  Mind posting a patch to
supersede this one?

BR,
-R

> >   drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++-
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 ++--
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +-
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   | 2 +-
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 5 -
> >   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 3 ++-
> >   8 files changed, 15 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > index 2b83a13b3aa9..d93a92ffd5df 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > @@ -134,7 +134,7 @@ static void dpu_crtc_setup_encoder_misr(struct
> > drm_crtc *crtc)
> >  struct drm_encoder *drm_enc;
> >
> >  drm_for_each_encoder_mask(drm_enc, crtc->dev,
> > crtc->state->encoder_mask)
> > -   dpu_encoder_setup_misr(drm_enc);
> > +   dpu_encoder_setup_misr(drm_enc, !!crtc->state->ctm);
> >   }
> >
> >   static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const
> > char *src_name)
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index b0a7908418ed..12ee7acb5ea6 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -241,7 +241,7 @@ int dpu_encoder_get_crc_values_cnt(const struct
> > drm_encoder *drm_enc)
> >  return num_intf;

Re: [PATCH 1/1] drm/i915/pxp: Add missing tag for Wa_14019159160

[John Harrison]

On 11/21/2023 10:55, Alan Previn wrote:

Add missing tag for "Wa_14019159160 - Case 2" (for existing
PXP code that ensures run alone mode bit is set to allow
PxP-decryption.

Signed-off-by: Alan Previn 
---
  drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7c367ba8d9dc..c758fe4906a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -863,8 +863,10 @@ static bool ctx_needs_runalone(const struct intel_context 
*ce)
bool ctx_is_protected = false;
  
  	/*

+* Wa_140191591606 - Case 2: mtl

Too many sixes.


 * On MTL and newer platforms, protected contexts require setting
Probably better to say 'On some platforms'. The current wording implies 
this is an intentional hardware change that will be carried forward 
rather than a bug requiring a workaround which will (hopefully) be fixed 
on some future platform.



-* the LRC run-alone bit or else the encryption will not happen.
+* the LRC run-alone bit or else the encryption/decryption will not 
happen.
+* NOTE: Case 2 only applies to PXP use-case of said workaround.
 */
if (GRAPHICS_VER_FULL(ce->engine->i915) >= IP_VER(12, 70) &&
Likewise, this should only test for the explicit platforms listed in the 
w/a definition rather than assume all future platforms.


John.


(ce->engine->class == COMPUTE_CLASS || ce->engine->class == 
RENDER_CLASS)) {

base-commit: dbdb47c227dc21b7bf98ada039bf42aac4b58b8b

Fwd: Kernel 6.6.1 hangs on "loading initial ramdisk"

[Bagas Sanjaya]

Hi,

I notice a regression report on Bugzilla [1]. Quoting from it:

> After upgrading from 6.5.9 to 6.6.1 on my Dell Latitude E6420 (Intel 
> i5-2520M) with EndeavourOS, the boot process would hang at "loading initial 
> ramdisk". The issue is present on the 6.6.1 release of both Linux and 
> Linux-zen, but not the 6.5.9 release, which makes me think this is somehow 
> upstream in the kernel, rather than to do with packaging. My current 
> workaround is using the Linux LTS kernel.
> 
> I have been unable to consistently reproduce this bug. Between 50 and 30 
> percent of the time, the "loading initial ramdisk" will display, the disk 
> activity indicator will turn off briefly and then resume blinking, and then 
> the kernel boots as expected. The other 50 to 70 percent of the time, the 
> boot stops at "loading initial ramdisk" and the disk activity indicator turns 
> off, and does not resume blinking. The disk activity light is constantly 
> flashing during normal system operation, so I know it's not secretly booting 
> but not updating the display. I haven't been able to replicate this issue in 
> QEMU. I have seen similar bugs that have been solved by disabling IOMMU, but 
> this has not had any effect. Neither has disabling graphics drivers and 
> modesetting. I have been able to reproduce it while using Nouveau, so I don't 
> believe it has to do with Nvidia's proprietary drivers.
> 
> Examining dmesg and journalctl, there doesn't appear to be ANY logs from the 
> failed boots. I don't believe the kernel even is started on these failed 
> boots. Enabling GRUB debug messages 
> (linux,loader,init,fs,device,disk,partition) shows that the hang occurs after 
> GRUB attempts to start the loaded image- it's able to load the image into 
> memory, but the boot stalls after "Starting image" with a hex address 
> (presumably the start addr of the kernel).  
> 
> I've been trying to compile the kernel myself to see if I can solve the 
> issue, or at least aid in reproduceability, but this is not easy or fast to 
> do on a 2012 i5 processor. I'll update if I can successfully recompile the 
> kernel and if it yields any information.  
> 
> Please let me know if I should provide any additional information. This is my 
> first time filing a bug here.

See Bugzilla for the full thread and attached grub output.

Anyway, I'm adding this regression to regzbot:

#regzbot introduced: v6.5..v6.6 
https://bugzilla.kernel.org/show_bug.cgi?id=218173
#regzbot title: initramfs loading hang on nouveau system (Dell Latitude E6420)

Thanks.

[1]: https://bugzilla.kernel.org/show_bug.cgi?id=218173

-- 
An old man doll... just what I always wanted! - Clara

Re: [PATCH v2 2/2] fbdev/simplefb: Add support for generic power-domains

[Richard Acayan]

On Tue, Nov 21, 2023 at 10:01:18AM +0100, Hans de Goede wrote:
> Hi,
>
> On 11/21/23 02:17, Richard Acayan wrote:
>> Hello,
>> 
>> On Wed, Nov 01, 2023 at 06:20:17PM +0100, Thierry Reding wrote:
>>> From: Thierry Reding 
>>>
>>> The simple-framebuffer device tree bindings document the power-domains
>>> property, so make sure that simplefb supports it. This ensures that the
>>> power domains remain enabled as long as simplefb is active.
>>>
>>> v2: - remove unnecessary call to simplefb_detach_genpds() since that's
>>>   already done automatically by devres
>>> - fix crash if power-domains property is missing in DT
>>>
>>> Signed-off-by: Thierry Reding 
>>> ---
>>>  drivers/video/fbdev/simplefb.c | 93 ++
>>>  1 file changed, 93 insertions(+)
>>>
>>> diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
>>> index 18025f34fde7..fe682af63827 100644
>>> --- a/drivers/video/fbdev/simplefb.c
>>> +++ b/drivers/video/fbdev/simplefb.c
>>> @@ -25,6 +25,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  static const struct fb_fix_screeninfo simplefb_fix = {
>>> @@ -78,6 +79,11 @@ struct simplefb_par {
>>> unsigned int clk_count;
>>> struct clk **clks;
>>>  #endif
>>> +#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
>>> +   unsigned int num_genpds;
>> 
>> This is the cause of the crash that occurred on the older patch series.
>> The field is unsigned, a deviation from v6.6:drivers/remoteproc/imx_rproc.c.
>> 
>> Instead of making it signed, this version emits an error whenever the
>> count is negative.
>
> I'm not sure what you are trying to say here ?

In v1 of the patch, there was no error propagation from 
of_count_phandle_with_args
and this field was directly assigned to the return value. This was a
problem (the "crash" as mentioned in this patch's changelog) when the
return value is negative, since unsigned integers cannot hold negative
values. On mainstream architectures, the driver would believe that there
is an absurd amount of power domains.

I compared the versions of this patch and figured that the fix to the
crash was more error handling.

Basically, if "unsigned" was removed, the error handling for the call to
of_count_phandle_with_args could be dropped with few consequences.

>>> +   struct device **genpds;
>>> +   struct device_link **genpd_links;
>>> +#endif
>>>  #if defined CONFIG_OF && defined CONFIG_REGULATOR
>>> bool regulators_enabled;
>>> u32 regulator_count;
>>> @@ -432,6 +438,89 @@ static void simplefb_regulators_enable(struct 
>>> simplefb_par *par,
>>>  static void simplefb_regulators_destroy(struct simplefb_par *par) { }
>>>  #endif
>>>  
>>> +#if defined CONFIG_OF && defined CONFIG_PM_GENERIC_DOMAINS
>>> +static void simplefb_detach_genpds(void *res)
>>> +{
>>> +   struct simplefb_par *par = res;
>>> +   unsigned int i = par->num_genpds;
>>> +
>>> +   if (par->num_genpds <= 1)
>>> +   return;
>>> +
>>> +   while (i--) {
>>> +   if (par->genpd_links[i])
>>> +   device_link_del(par->genpd_links[i]);
>>> +
>>> +   if (!IS_ERR_OR_NULL(par->genpds[i]))
>>> +   dev_pm_domain_detach(par->genpds[i], true);
>>> +   }
>>> +}
>>> +
>>> +static int simplefb_attach_genpds(struct simplefb_par *par,
>>> + struct platform_device *pdev)
>>> +{
>>> +   struct device *dev = >dev;
>>> +   unsigned int i;
>>> +   int err;
>>> +
>>> +   err = of_count_phandle_with_args(dev->of_node, "power-domains",
>>> +"#power-domain-cells");
>>> +   if (err < 0) {
>>> +   dev_info(dev, "failed to parse power-domains: %d\n", err);
>>> +   return err;
>> 
>> This error path is taken when there is no power-domains property in the
>> device tree with err = -ENOENT.
>> 
>> Strangely, this does not suppress the error like the next if statement,
>> even though it is possible that nothing is wrong.
>> 
>>> +   }
>>> +
>>> +   par->num_genpds = err;
>>> +
>>> +   /*
>>> +* Single power-domain devices are handled by the driver core, so
>>> +* nothing to do here.
>>> +*/
>>> +   if (par->num_genpds <= 1)
>>> +   return 0;
>>> +
>>> +   par->genpds = devm_kcalloc(dev, par->num_genpds, sizeof(*par->genpds),
>>> +  GFP_KERNEL);
>> 
>>> @@ -518,6 +607,10 @@ static int simplefb_probe(struct platform_device *pdev)
>>> if (ret < 0)
>>> goto error_clocks;
>>>  
>>> +   ret = simplefb_attach_genpds(par, pdev);
>>> +   if (ret < 0)
>>> +   goto error_regulators;
>> 
>> With the error case specified above, not specifying power-domains (which
>> is valid according to dtschema) causes the entire driver to fail
>> whenever there are no power domains in the device tree.
>> 
>> On google-sargo, this causes a bug where the framebuffer fails to probe:
>> 
>> [0.409290] simple-framebuffer 9c00.framebuffer: failed 

Re: [PATCH 09/32] auxdisplay/ht16k33: Set FBINFO_VIRTFB flag

[Miguel Ojeda]

On Wed, Nov 15, 2023 at 11:30 AM Thomas Zimmermann  wrote:
>
> +   fbdev->info->flags |= FBINFO_VIRTFB;

Is the `|=` (instead of just `=`) used in case someone adds something
to the flags before (e.g. `fb_bl_default_curve`) or due to some other
reason? (One of the other patches uses `=`).

In any case, if that is intended:

Acked-by: Miguel Ojeda 

Cheers,
Miguel

Re: [PATCH 10/32] auxdisplay/ht16k33: Initialize fb_ops with fbdev macros

[Miguel Ojeda]

On Wed, Nov 15, 2023 at 11:30 AM Thomas Zimmermann  wrote:
>
> Initialize the instance of struct fb_ops with fbdev initializer
> macros for framebuffers in virtual address space. Set the read/write,
> draw and mmap callbacks to the correct implementation and avoid
> implicit defaults. Also select the necessary helpers in Kconfig.
>
> Fbdev drivers sometimes rely on the callbacks being NULL for a
> default I/O-memory-based implementation to be invoked; hence
> requiring the I/O helpers to be built in any case. Setting all
> callbacks in all drivers explicitly will allow to make the I/O
> helpers optional. This benefits systems that do not use these
> functions.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Miguel Ojeda 
> Cc: Robin van der Gracht 

Acked-by: Miguel Ojeda 

Cheers,
Miguel

Re: [PATCH 08/32] auxdisplay/cfag12864bfb: Initialize fb_ops with fbdev macros

[Miguel Ojeda]

On Wed, Nov 15, 2023 at 11:30 AM Thomas Zimmermann  wrote:
>
> Initialize the instance of struct fb_ops with fbdev initializer
> macros for framebuffers in virtual address space. Set the read/write,
> draw and mmap callbacks to the correct implementation and avoid
> implicit defaults. Also select the necessary helpers in Kconfig.
>
> Fbdev drivers sometimes rely on the callbacks being NULL for a
> default I/O-memory-based implementation to be invoked; hence
> requiring the I/O helpers to be built in any case. Setting all
> callbacks in all drivers explicitly will allow to make the I/O
> helpers optional. This benefits systems that do not use these
> functions.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Miguel Ojeda 

Acked-by: Miguel Ojeda 

Cheers,
Miguel

Re: [PATCH 07/32] auxdisplay/cfag12864bfb: Set FBINFO_VIRTFB flag

[Miguel Ojeda]

On Wed, Nov 15, 2023 at 11:30 AM Thomas Zimmermann  wrote:
>
> The cfag12864bfb driver operates on system memory. Mark the framebuffer
> accordingly. Helpers operating on the framebuffer memory will test for
> the presence of this flag.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Miguel Ojeda 

Acked-by: Miguel Ojeda 

Cheers,
Miguel

Re: [PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement

[Abhinav Kumar]

On 10/24/2023 12:01 PM, Abhinav Kumar wrote:



On 10/23/2023 4:03 PM, Dmitry Baryshkov wrote:

On Tue, 24 Oct 2023 at 01:36, Rob Clark  wrote:


On Mon, Oct 23, 2023 at 3:30 PM Dmitry Baryshkov
 wrote:


On Tue, 24 Oct 2023 at 01:12, Rob Clark  wrote:


From: Rob Clark 

Seems like we need to pick INPUT_SEL=1 when CTM is enabled.  But not
otherwise.

Suggested-by: Dmitry Baryshkov 
Signed-off-by: Rob Clark 
---


I cannot find anything in the docs which suggest this solution is correct.

Different blocks in the DPU pipeline have their own CRC (MISR) registers 
like LM, intf etc.


We dont need to change INPUT_SEL to tell DPU from which pipeline to take 
the CRC from as each of them have their own registers.


INPUT_SEL is controlling whether the CRC needs to be calculated over the 
entire display timings or only the active pixels. I am unable to tell at 
the moment why this is making a difference in this use-case.


Since I am unable to find any documentation proving this solution is 
correct so far, unfortunately I would hold this back till then.


We will investigate this issue and report our findings on this thread on 
how to proceed.




Alright, we debugged and also found some more answers.

The correct solution is indeed to set INPUT_SEL = 1 but let me explain 
why and what should be the correct way.


INPUT_SEL was indeed telling whether to compute CRC over active pixels 
or active pixels + timings like I wrote before but this behavior changed 
since some chipsets.


Now, INPUT_SEL = 0 means compute CRC *only* over timings and not the 
active area (and not display + timings like before) and like mentioned 
before this has nothing to do with what is the input to the CRC. Not 
covering the active area will not change the CRC at all as Rob reported 
but its not specific to CTM.


Which means we should have been setting INPUT_SEL=1 whenever we use INTF 
CRC irrespective of whether CTM is used or not.


What this also means is INTF CRC was not working correctly at all so far 
irrespecive of CTM or not because it was always computing CRC only on 
the timings (non-active area).


This was not caught so far because it looks like IGT's 
kms_pipe_crc_basic test which was used to validate this only compares 
CRC between two frames of the same content to match if they were equal 
and not changing contents and comparing like kms_plane does. It will 
pass as CRC would not have changed.


Now coming to the fix, the reset value of this register INTF_MISR_CTRL 
already sets the INPUT_SEL bit (or unsets it) correctly based on 
whichever DPU version is used so we should just change the 
dpu_hw_setup_misr() to a read on the register followed by ORing the 
required bits without touching INPUT_SEL and write.


That will address this issue and also cover version control since the 
expected value of this bit has changed across DPU revisions.



  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c    | 2 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 ++--
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   | 2 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 5 -
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 3 ++-
  8 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c

index 2b83a13b3aa9..d93a92ffd5df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -134,7 +134,7 @@ static void dpu_crtc_setup_encoder_misr(struct 
drm_crtc *crtc)

 struct drm_encoder *drm_enc;

 drm_for_each_encoder_mask(drm_enc, crtc->dev, 
crtc->state->encoder_mask)

-   dpu_encoder_setup_misr(drm_enc);
+   dpu_encoder_setup_misr(drm_enc, !!crtc->state->ctm);
  }

  static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const 
char *src_name)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c

index b0a7908418ed..12ee7acb5ea6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -241,7 +241,7 @@ int dpu_encoder_get_crc_values_cnt(const struct 
drm_encoder *drm_enc)

 return num_intf;
  }

-void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc)
+void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc, 
bool has_ctm)

  {
 struct dpu_encoder_virt *dpu_enc;

@@ -255,7 +255,7 @@ void dpu_encoder_setup_misr(const struct 
drm_encoder *drm_enc)

 if (!phys->hw_intf || !phys->hw_intf->ops.setup_misr)
 continue;

-   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1);
+   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 
1, has_ctm);

 }
  }

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 

[PATCH v2 4/4] drm/amdkfd: Import DMABufs for interop through DRM

[Felix Kuehling]

Use drm_gem_prime_fd_to_handle to import DMABufs for interop. This
ensures that a GEM handle is created on import and that obj->dma_buf
will be set and remain set as long as the object is imported into KFD.

Signed-off-by: Felix Kuehling 
Reviewed-by: Ramesh Errabolu 
Reviewed-by: Xiaogang.Chen 
Acked-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  9 ++-
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 64 +--
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  | 15 ++---
 3 files changed, 52 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index c1195eb67057..8da42e0dddcb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -319,11 +319,10 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void 
*process_info,
struct dma_fence **ef);
 int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct amdgpu_device *adev,
  struct kfd_vm_fault_info *info);
-int amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,
- struct dma_buf *dmabuf,
- uint64_t va, void *drm_priv,
- struct kgd_mem **mem, uint64_t *size,
- uint64_t *mmap_offset);
+int amdgpu_amdkfd_gpuvm_import_dmabuf_fd(struct amdgpu_device *adev, int fd,
+uint64_t va, void *drm_priv,
+struct kgd_mem **mem, uint64_t *size,
+uint64_t *mmap_offset);
 int amdgpu_amdkfd_gpuvm_export_dmabuf(struct kgd_mem *mem,
  struct dma_buf **dmabuf);
 void amdgpu_amdkfd_debug_mem_fence(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index e96e1595791f..652657c863ff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1953,8 +1953,7 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
 
/* Free the BO*/
drm_vma_node_revoke(>bo->tbo.base.vma_node, drm_priv);
-   if (!mem->is_imported)
-   drm_gem_handle_delete(adev->kfd.client.file, mem->gem_handle);
+   drm_gem_handle_delete(adev->kfd.client.file, mem->gem_handle);
if (mem->dmabuf) {
dma_buf_put(mem->dmabuf);
mem->dmabuf = NULL;
@@ -2310,34 +2309,26 @@ int amdgpu_amdkfd_gpuvm_get_vm_fault_info(struct 
amdgpu_device *adev,
return 0;
 }
 
-int amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,
- struct dma_buf *dma_buf,
- uint64_t va, void *drm_priv,
- struct kgd_mem **mem, uint64_t *size,
- uint64_t *mmap_offset)
+static int import_obj_create(struct amdgpu_device *adev,
+struct dma_buf *dma_buf,
+struct drm_gem_object *obj,
+uint64_t va, void *drm_priv,
+struct kgd_mem **mem, uint64_t *size,
+uint64_t *mmap_offset)
 {
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
-   struct drm_gem_object *obj;
struct amdgpu_bo *bo;
int ret;
 
-   obj = amdgpu_gem_prime_import(adev_to_drm(adev), dma_buf);
-   if (IS_ERR(obj))
-   return PTR_ERR(obj);
-
bo = gem_to_amdgpu_bo(obj);
if (!(bo->preferred_domains & (AMDGPU_GEM_DOMAIN_VRAM |
-   AMDGPU_GEM_DOMAIN_GTT))) {
+   AMDGPU_GEM_DOMAIN_GTT)))
/* Only VRAM and GTT BOs are supported */
-   ret = -EINVAL;
-   goto err_put_obj;
-   }
+   return -EINVAL;
 
*mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
-   if (!*mem) {
-   ret = -ENOMEM;
-   goto err_put_obj;
-   }
+   if (!*mem)
+   return -ENOMEM;
 
ret = drm_vma_node_allow(>vma_node, drm_priv);
if (ret)
@@ -2387,8 +2378,41 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,
drm_vma_node_revoke(>vma_node, drm_priv);
 err_free_mem:
kfree(*mem);
+   return ret;
+}
+
+int amdgpu_amdkfd_gpuvm_import_dmabuf_fd(struct amdgpu_device *adev, int fd,
+uint64_t va, void *drm_priv,
+struct kgd_mem **mem, uint64_t *size,
+uint64_t *mmap_offset)
+{
+   struct drm_gem_object *obj;
+   uint32_t handle;
+   int ret;
+
+   ret = 

[PATCH v2 1/4] Revert "drm/prime: Unexport helpers for fd/handle conversion"

[Felix Kuehling]

This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.

These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated with
GEM objects while ensuring that move notifier callbacks are working as
intended.

CC: Christian König 
CC: Thomas Zimmermann 
Signed-off-by: Felix Kuehling 
---
 drivers/gpu/drm/drm_prime.c | 33 ++---
 include/drm/drm_prime.h |  7 +++
 2 files changed, 25 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 63b709a67471..834a5e28abbe 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -278,7 +278,7 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 }
 EXPORT_SYMBOL(drm_gem_dmabuf_release);
 
-/*
+/**
  * drm_gem_prime_fd_to_handle - PRIME import function for GEM drivers
  * @dev: drm_device to import into
  * @file_priv: drm file-private structure
@@ -292,9 +292,9 @@ EXPORT_SYMBOL(drm_gem_dmabuf_release);
  *
  * Returns 0 on success or a negative error code on failure.
  */
-static int drm_gem_prime_fd_to_handle(struct drm_device *dev,
- struct drm_file *file_priv, int prime_fd,
- uint32_t *handle)
+int drm_gem_prime_fd_to_handle(struct drm_device *dev,
+  struct drm_file *file_priv, int prime_fd,
+  uint32_t *handle)
 {
struct dma_buf *dma_buf;
struct drm_gem_object *obj;
@@ -360,6 +360,7 @@ static int drm_gem_prime_fd_to_handle(struct drm_device 
*dev,
dma_buf_put(dma_buf);
return ret;
 }
+EXPORT_SYMBOL(drm_gem_prime_fd_to_handle);
 
 int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
@@ -408,7 +409,7 @@ static struct dma_buf *export_and_register_object(struct 
drm_device *dev,
return dmabuf;
 }
 
-/*
+/**
  * drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
  * @dev: dev to export the buffer from
  * @file_priv: drm file-private structure
@@ -421,10 +422,10 @@ static struct dma_buf *export_and_register_object(struct 
drm_device *dev,
  * The actual exporting from GEM object to a dma-buf is done through the
  * _gem_object_funcs.export callback.
  */
-static int drm_gem_prime_handle_to_fd(struct drm_device *dev,
- struct drm_file *file_priv, uint32_t 
handle,
- uint32_t flags,
- int *prime_fd)
+int drm_gem_prime_handle_to_fd(struct drm_device *dev,
+  struct drm_file *file_priv, uint32_t handle,
+  uint32_t flags,
+  int *prime_fd)
 {
struct drm_gem_object *obj;
int ret = 0;
@@ -506,6 +507,7 @@ static int drm_gem_prime_handle_to_fd(struct drm_device 
*dev,
 
return ret;
 }
+EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
 
 int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
@@ -864,9 +866,9 @@ EXPORT_SYMBOL(drm_prime_get_contiguous_size);
  * @obj: GEM object to export
  * @flags: flags like DRM_CLOEXEC and DRM_RDWR
  *
- * This is the implementation of the _gem_object_funcs.export functions
- * for GEM drivers using the PRIME helpers. It is used as the default for
- * drivers that do not set their own.
+ * This is the implementation of the _gem_object_funcs.export functions 
for GEM drivers
+ * using the PRIME helpers. It is used as the default in
+ * drm_gem_prime_handle_to_fd().
  */
 struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj,
 int flags)
@@ -962,9 +964,10 @@ EXPORT_SYMBOL(drm_gem_prime_import_dev);
  * @dev: drm_device to import into
  * @dma_buf: dma-buf object to import
  *
- * This is the implementation of the gem_prime_import functions for GEM
- * drivers using the PRIME helpers. It is the default for drivers that do
- * not set their own _driver.gem_prime_import.
+ * This is the implementation of the gem_prime_import functions for GEM drivers
+ * using the PRIME helpers. Drivers can use this as their
+ * _driver.gem_prime_import implementation. It is used as the default
+ * implementation in drm_gem_prime_fd_to_handle().
  *
  * Drivers must arrange to call drm_prime_gem_destroy() from their
  * _gem_object_funcs.free hook when using this function.
diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h
index a7abf9f3e697..2a1d01e5b56b 100644
--- a/include/drm/drm_prime.h
+++ b/include/drm/drm_prime.h
@@ -60,12 +60,19 @@ enum dma_data_direction;
 
 struct drm_device;
 struct drm_gem_object;
+struct drm_file;
 
 /* core prime functions */
 struct dma_buf *drm_gem_dmabuf_export(struct drm_device *dev,
  struct 

[PATCH v2 3/4] drm/amdkfd: Export DMABufs from KFD using GEM handles

[Felix Kuehling]

Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.

Signed-off-by: Felix Kuehling 
Reviewed-by: Ramesh Errabolu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 11 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  5 
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 29 ++-
 3 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index b8412202a1b0..aa8b24079070 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -142,6 +142,7 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
 {
int i;
int last_valid_bit;
+   int ret;
 
amdgpu_amdkfd_gpuvm_init_mem_limits();
 
@@ -160,6 +161,12 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
.enable_mes = adev->enable_mes,
};
 
+   ret = drm_client_init(>ddev, >kfd.client, "kfd", 
NULL);
+   if (ret) {
+   dev_err(adev->dev, "Failed to init DRM client: %d\n", 
ret);
+   return;
+   }
+
/* this is going to have a few of the MSBs set that we need to
 * clear
 */
@@ -198,6 +205,10 @@ void amdgpu_amdkfd_device_init(struct amdgpu_device *adev)
 
adev->kfd.init_complete = kgd2kfd_device_init(adev->kfd.dev,
_resources);
+   if (adev->kfd.init_complete)
+   drm_client_register(>kfd.client);
+   else
+   drm_client_release(>kfd.client);
 
amdgpu_amdkfd_total_mem_size += adev->gmc.real_vram_size;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index dac983da961d..c1195eb67057 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu_sync.h"
 #include "amdgpu_vm.h"
 #include "amdgpu_xcp.h"
@@ -83,6 +84,7 @@ struct kgd_mem {
 
struct amdgpu_sync sync;
 
+   uint32_t gem_handle;
bool aql_queue;
bool is_imported;
 };
@@ -105,6 +107,9 @@ struct amdgpu_kfd_dev {
 
/* HMM page migration MEMORY_DEVICE_PRIVATE mapping */
struct dev_pagemap pgmap;
+
+   /* Client for KFD BO GEM handle allocations */
+   struct drm_client_dev client;
 };
 
 enum kgd_engine_type {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 41fbc4fd0fac..e96e1595791f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -806,13 +807,18 @@ kfd_mem_dmaunmap_attachment(struct kgd_mem *mem,
 static int kfd_mem_export_dmabuf(struct kgd_mem *mem)
 {
if (!mem->dmabuf) {
-   struct dma_buf *ret = amdgpu_gem_prime_export(
-   >bo->tbo.base,
+   struct amdgpu_device *bo_adev;
+   struct dma_buf *dmabuf;
+
+   bo_adev = amdgpu_ttm_adev(mem->bo->tbo.bdev);
+   dmabuf = drm_gem_prime_handle_to_dmabuf(_adev->ddev,
+   
bo_adev->kfd.client.file,
+   mem->gem_handle,
mem->alloc_flags & KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ?
-   DRM_RDWR : 0);
-   if (IS_ERR(ret))
-   return PTR_ERR(ret);
-   mem->dmabuf = ret;
+   DRM_RDWR : 0);
+   if (IS_ERR(dmabuf))
+   return PTR_ERR(dmabuf);
+   mem->dmabuf = dmabuf;
}
 
return 0;
@@ -1779,6 +1785,9 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
pr_debug("Failed to allow vma node access. ret %d\n", ret);
goto err_node_allow;
}
+   ret = drm_gem_handle_create(adev->kfd.client.file, gobj, 
&(*mem)->gem_handle);
+   if (ret)
+   goto err_gem_handle_create;
bo = gem_to_amdgpu_bo(gobj);
if (bo_type == ttm_bo_type_sg) {
bo->tbo.sg = sg;
@@ -1830,6 +1839,8 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
 err_pin_bo:
 err_validate_bo:
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
+   drm_gem_handle_delete(adev->kfd.client.file, (*mem)->gem_handle);
+err_gem_handle_create:
drm_vma_node_revoke(>vma_node, drm_priv);
 err_node_allow:
/* Don't unreserve system mem 

[PATCH v2 2/4] drm/prime: Helper to export dmabuf without fd

[Felix Kuehling]

Change drm_gem_prime_handle_to_fd to drm_gem_prime_handle_to_dmabuf to
export a dmabuf without creating an FD as a user mode handle. This is
more useful for users in kernel mode.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Felix Kuehling 
---
 drivers/gpu/drm/drm_prime.c | 63 ++---
 include/drm/drm_prime.h |  6 ++--
 2 files changed, 33 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 834a5e28abbe..d491b5f73eea 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -410,26 +410,25 @@ static struct dma_buf *export_and_register_object(struct 
drm_device *dev,
 }
 
 /**
- * drm_gem_prime_handle_to_fd - PRIME export function for GEM drivers
+ * drm_gem_prime_handle_to_dmabuf - PRIME export function for GEM drivers
  * @dev: dev to export the buffer from
  * @file_priv: drm file-private structure
  * @handle: buffer handle to export
  * @flags: flags like DRM_CLOEXEC
- * @prime_fd: pointer to storage for the fd id of the create dma-buf
+ * @dma_buf: pointer to storage for the dma-buf reference
  *
  * This is the PRIME export function which must be used mandatorily by GEM
  * drivers to ensure correct lifetime management of the underlying GEM object.
  * The actual exporting from GEM object to a dma-buf is done through the
  * _gem_object_funcs.export callback.
  */
-int drm_gem_prime_handle_to_fd(struct drm_device *dev,
-  struct drm_file *file_priv, uint32_t handle,
-  uint32_t flags,
-  int *prime_fd)
+struct dma_buf *drm_gem_prime_handle_to_dmabuf(struct drm_device *dev,
+  struct drm_file *file_priv,
+  uint32_t handle, uint32_t flags)
 {
struct drm_gem_object *obj;
int ret = 0;
-   struct dma_buf *dmabuf;
+   struct dma_buf *dmabuf = NULL;
 
mutex_lock(_priv->prime.lock);
obj = drm_gem_object_lookup(file_priv, handle);
@@ -441,7 +440,7 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
dmabuf = drm_prime_lookup_buf_by_handle(_priv->prime, handle);
if (dmabuf) {
get_dma_buf(dmabuf);
-   goto out_have_handle;
+   goto out;
}
 
mutex_lock(>object_name_lock);
@@ -479,40 +478,22 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
   dmabuf, handle);
mutex_unlock(>object_name_lock);
if (ret)
-   goto fail_put_dmabuf;
-
-out_have_handle:
-   ret = dma_buf_fd(dmabuf, flags);
-   /*
-* We must _not_ remove the buffer from the handle cache since the newly
-* created dma buf is already linked in the global obj->dma_buf pointer,
-* and that is invariant as long as a userspace gem handle exists.
-* Closing the handle will clean out the cache anyway, so we don't leak.
-*/
-   if (ret < 0) {
-   goto fail_put_dmabuf;
-   } else {
-   *prime_fd = ret;
-   ret = 0;
-   }
-
-   goto out;
-
-fail_put_dmabuf:
-   dma_buf_put(dmabuf);
+   dma_buf_put(dmabuf);
 out:
drm_gem_object_put(obj);
 out_unlock:
mutex_unlock(_priv->prime.lock);
 
-   return ret;
+   return ret ? ERR_PTR(ret) : dmabuf;
 }
-EXPORT_SYMBOL(drm_gem_prime_handle_to_fd);
+EXPORT_SYMBOL(drm_gem_prime_handle_to_dmabuf);
 
 int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv)
 {
struct drm_prime_handle *args = data;
+   struct dma_buf *dmabuf;
+   int ret;
 
/* check flags are valid */
if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
@@ -523,8 +504,24 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   args->handle, 
args->flags,
   >fd);
}
-   return drm_gem_prime_handle_to_fd(dev, file_priv, args->handle,
- args->flags, >fd);
+   dmabuf = drm_gem_prime_handle_to_dmabuf(dev, file_priv, args->handle,
+   args->flags);
+   if (IS_ERR(dmabuf))
+   return PTR_ERR(dmabuf);
+   ret = dma_buf_fd(dmabuf, args->flags);
+   /*
+* We must _not_ remove the buffer from the handle cache since the newly
+* created dma buf is already linked in the global obj->dma_buf pointer,
+* and that is invariant as long as a userspace gem handle exists.
+* Closing the handle will clean out the cache anyway, so we don't leak.
+*/
+   if (ret < 0) {
+   dma_buf_put(dmabuf);
+   } else {
+   args->fd = ret;
+   ret = 0;
+   }
+   return 

[PATCH 01/14] tools headers UAPI: Update tools's copy of drm headers

[Namhyung Kim]

tldr; Just FYI, I'm carrying this on the perf tools tree.

Full explanation:

There used to be no copies, with tools/ code using kernel headers
directly. From time to time tools/perf/ broke due to legitimate kernel
hacking. At some point Linus complained about such direct usage. Then we
adopted the current model.

The way these headers are used in perf are not restricted to just
including them to compile something.

There are sometimes used in scripts that convert defines into string
tables, etc, so some change may break one of these scripts, or new MSRs
may use some different #define pattern, etc.

E.g.:

  $ ls -1 tools/perf/trace/beauty/*.sh | head -5
  tools/perf/trace/beauty/arch_errno_names.sh
  tools/perf/trace/beauty/drm_ioctl.sh
  tools/perf/trace/beauty/fadvise.sh
  tools/perf/trace/beauty/fsconfig.sh
  tools/perf/trace/beauty/fsmount.sh
  $
  $ tools/perf/trace/beauty/fadvise.sh
  static const char *fadvise_advices[] = {
[0] = "NORMAL",
[1] = "RANDOM",
[2] = "SEQUENTIAL",
[3] = "WILLNEED",
[4] = "DONTNEED",
[5] = "NOREUSE",
  };
  $

The tools/perf/check-headers.sh script, part of the tools/ build
process, points out changes in the original files.

So its important not to touch the copies in tools/ when doing changes in
the original kernel headers, that will be done later, when
check-headers.sh inform about the change to the perf tools hackers.

Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Namhyung Kim 
---
 tools/include/uapi/drm/drm.h  | 20 
 tools/include/uapi/drm/i915_drm.h |  8 
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/tools/include/uapi/drm/drm.h b/tools/include/uapi/drm/drm.h
index 794c1d857677..de723566c5ae 100644
--- a/tools/include/uapi/drm/drm.h
+++ b/tools/include/uapi/drm/drm.h
@@ -1134,6 +1134,26 @@ extern "C" {
 #define DRM_IOCTL_MODE_PAGE_FLIP   DRM_IOWR(0xB0, struct 
drm_mode_crtc_page_flip)
 #define DRM_IOCTL_MODE_DIRTYFB DRM_IOWR(0xB1, struct 
drm_mode_fb_dirty_cmd)
 
+/**
+ * DRM_IOCTL_MODE_CREATE_DUMB - Create a new dumb buffer object.
+ *
+ * KMS dumb buffers provide a very primitive way to allocate a buffer object
+ * suitable for scanout and map it for software rendering. KMS dumb buffers are
+ * not suitable for hardware-accelerated rendering nor video decoding. KMS dumb
+ * buffers are not suitable to be displayed on any other device than the KMS
+ * device where they were allocated from. Also see
+ * :ref:`kms_dumb_buffer_objects`.
+ *
+ * The IOCTL argument is a struct drm_mode_create_dumb.
+ *
+ * User-space is expected to create a KMS dumb buffer via this IOCTL, then add
+ * it as a KMS framebuffer via _IOCTL_MODE_ADDFB and map it via
+ * _IOCTL_MODE_MAP_DUMB.
+ *
+ * _CAP_DUMB_BUFFER indicates whether this IOCTL is supported.
+ * _CAP_DUMB_PREFERRED_DEPTH and _CAP_DUMB_PREFER_SHADOW indicate
+ * driver preferences for dumb buffers.
+ */
 #define DRM_IOCTL_MODE_CREATE_DUMB DRM_IOWR(0xB2, struct drm_mode_create_dumb)
 #define DRM_IOCTL_MODE_MAP_DUMBDRM_IOWR(0xB3, struct drm_mode_map_dumb)
 #define DRM_IOCTL_MODE_DESTROY_DUMBDRM_IOWR(0xB4, struct 
drm_mode_destroy_dumb)
diff --git a/tools/include/uapi/drm/i915_drm.h 
b/tools/include/uapi/drm/i915_drm.h
index 7000e5910a1d..218edb0a96f8 100644
--- a/tools/include/uapi/drm/i915_drm.h
+++ b/tools/include/uapi/drm/i915_drm.h
@@ -38,13 +38,13 @@ extern "C" {
  */
 
 /**
- * DOC: uevents generated by i915 on it's device node
+ * DOC: uevents generated by i915 on its device node
  *
  * I915_L3_PARITY_UEVENT - Generated when the driver receives a parity mismatch
- * event from the gpu l3 cache. Additional information supplied is ROW,
+ * event from the GPU L3 cache. Additional information supplied is ROW,
  * BANK, SUBBANK, SLICE of the affected cacheline. Userspace should keep
- * track of these events and if a specific cache-line seems to have a
- * persistent error remap it with the l3 remapping tool supplied in
+ * track of these events, and if a specific cache-line seems to have a
+ * persistent error, remap it with the L3 remapping tool supplied in
  * intel-gpu-tools.  The value supplied with the event is always 1.
  *
  * I915_ERROR_UEVENT - Generated upon error detection, currently only via
-- 
2.43.0.rc1.413.gea7ed67945-goog

Re: [PATCH] nouveau/gsp: fix getting max channel id for GSP

[Dave Airlie]

Self NAK, this isn't sufficient to fix events.

On Mon, 20 Nov 2023 at 12:07, Dave Airlie  wrote:
>
> From: Dave Airlie 
>
> The fence code uses the total number of channel ids to allocate a
> bunch of memory for fencing. This is probably not the best way to
> do this, but it's hard to fix right now.
>
> The GSP code realises it can fit 8 channels into a USERD
> page, so it claims it can support 256 channels max, but it then
> allocates channel ids sparsely (0, 8, 16 etc).
>
> This just exposes the multiplier to userspace so the fence code
> gets things right, however I think this might all need more thought.
>
> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/274
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c | 7 ++-
>  drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h | 2 ++
>  drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c | 7 +++
>  3 files changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c
> index 22443fe4a39f..8e36cdd0e5fb 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c
> @@ -178,7 +178,12 @@ nvkm_fifo_info(struct nvkm_engine *engine, u64 mthd, u64 
> *data)
> return ret;
>
> switch (mthd) {
> -   case NV_DEVICE_HOST_CHANNELS: *data = fifo->chid ? fifo->chid->nr : 
> 0; return 0;
> +   case NV_DEVICE_HOST_CHANNELS:
> +   if (fifo->func->chid_total)
> +   *data = fifo->func->chid_total(fifo);
> +   else
> +   *data = fifo->chid ? fifo->chid->nr : 0;
> +   return 0;
> case NV_DEVICE_HOST_RUNLISTS:
> *data = 0;
> nvkm_runl_foreach(runl, fifo)
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h 
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h
> index a0f3277605a5..c21e982b03a5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/priv.h
> @@ -17,6 +17,8 @@ struct nvkm_fifo_func {
>
> int (*chid_nr)(struct nvkm_fifo *);
> int (*chid_ctor)(struct nvkm_fifo *, int nr);
> +
> +   int (*chid_total)(struct nvkm_fifo *);
> int (*runq_nr)(struct nvkm_fifo *);
> int (*runl_ctor)(struct nvkm_fifo *);
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
> index b374d72fd1c1..1e9c0b113cb5 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
> @@ -641,6 +641,12 @@ r535_fifo_dtor(struct nvkm_fifo *fifo)
> kfree(fifo->func);
>  }
>
> +static int
> +r535_fifo_chid_total(struct nvkm_fifo *fifo)
> +{
> +   return fifo->chid->nr * CHID_PER_USERD;
> +}
> +
>  int
>  r535_fifo_new(const struct nvkm_fifo_func *hw, struct nvkm_device *device,
>   enum nvkm_subdev_type type, int inst, struct nvkm_fifo **pfifo)
> @@ -652,6 +658,7 @@ r535_fifo_new(const struct nvkm_fifo_func *hw, struct 
> nvkm_device *device,
>
> rm->dtor = r535_fifo_dtor;
> rm->runl_ctor = r535_fifo_runl_ctor;
> +   rm->chid_total = r535_fifo_chid_total;
> rm->runl = _runl;
> rm->cgrp = hw->cgrp;
> rm->cgrp.func = _cgrp;
> --
> 2.42.0
>

Re: ✓ Fi.CI.BAT: success for drm/i915: Fix UHBR data, link M/N/TU and PBN values (rev6)

[Imre Deak]

On Tue, Nov 21, 2023 at 02:37:33AM +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Fix UHBR data, link M/N/TU and PBN values (rev6)
> URL   : https://patchwork.freedesktop.org/series/126526/
> State : success

Thanks for the reviews and acks, the patchset is pushed to drm-intel-next.

I had to rebase patch 1 on drm-intel-next as described in
https://lore.kernel.org/all/zvy2rgfvp2cxa...@ideak-desk.fi.intel.com/

and then resolve the corresponding conflict merging drm-intel-next and
drm-misc-next (resulting in the original change in patch 1):

diff --cc drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index c7a29bb737e2,53e323b71d26..
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@@ -209,11 -210,11 +210,11 @@@ static void dm_helpers_construct_old_pa
struct drm_dp_mst_atomic_payload *new_payload,
struct drm_dp_mst_atomic_payload *old_payload)
  {
 -  struct link_mst_stream_allocation_table current_link_table =
 -  
link->mst_stream_alloc_table;
 -  struct link_mst_stream_allocation *dc_alloc;
 -  int pbn_per_slot = dfixed_trunc(pbn_per_slot_fp);
 -  int i;
 +  struct drm_dp_mst_atomic_payload *pos;
-   int pbn_per_slot = mst_state->pbn_div;
++  int pbn_per_slot = dfixed_trunc(mst_state->pbn_div);
 +  u8 next_payload_vc_start = mgr->next_start_slot;
 +  u8 payload_vc_start = new_payload->vc_start_slot;
 +  u8 allocated_time_slots;

*old_payload = *new_payload;

The IGT full test results using CI_DRM_13898_full as base (thanks to
Jani for the help with this) with one unrelated failure commented on
inline:

*  CI Bug Log - changes from CI_DRM_13898_full -> Patchwork_126526v6_full
*  Summary
*  FAILURE
*  
*  Serious unknown changes coming with Patchwork_126526v6_full absolutely need 
to be
*  verified manually.
*  
*  If you think the reported changes have nothing to do with the changes
*  introduced in Patchwork_126526v6_full, please notify your bug team 
(lgci.bug.fil...@intel.com) to allow them
*  to document this new failure mode, which will reduce false positives in CI.
*  
*  External URL: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126526v6/index.html
*  
*  Participating hosts (10 -> 11)
*  Additional (1): shard-mtlp0
*  
*  Possible new issues
*  Here are the unknown changes that may have been introduced in 
Patchwork_126526v6_full:
*  
*  IGT changes
*  Possible regressions
*  igt@i915_selftest@live@requests:
*  shard-mtlp: NOTRUN -> DMESG-FAIL +1 other test dmesg-fail

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_126526v6/shard-mtlp-8/igt@i915_selftest@l...@requests.html

<6> [411.388436] i915: Running i915_request_live_selftests/live_cancel_request
<3> [411.398207] i915 :00:02.0: [drm] *ERROR* GT1: 
live_cancel_request(rcs0): engine 'other0' was reset -1 times!
<3> [411.423402] i915/i915_request_live_selftests: live_cancel_request failed 
with error -5


The platform doesn't have any external monitors attached, so can't see how the 
changes
in the patchset would be related. The closest issue (without a ticket filed for 
it) looks
to be:

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13906/bat-mtlp-6/igt@i915_selftest@l...@requests.html#dmesg-warnings741

<7> [266.125209] i915 :00:02.0: [drm:i915_gem_open [i915]] 
<6> [267.264820] Completed 281 waits for 8482 fences across 6 engines and 4 cpus
<3> [267.265605] i915 :00:02.0: [drm] *ERROR* GT1: 
live_breadcrumbs_smoketest(): engine 'other0' was reset -1 times!
<3> [267.276018] i915/i915_request_live_selftests: live_breadcrumbs_smoketest 
failed with error -5


*  New tests
*  New tests have been introduced between CI_DRM_13898_full and 
Patchwork_126526v6_full:
*  
*  New IGT tests (15)
*  igt@kms_cursor_crc@cursor-offscreen-128x128@pipe-a-dp-4:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_cursor_crc@cursor-onscreen-256x256@pipe-a-dp-4:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_cursor_crc@cursor-random-128x128@pipe-a-dp-4:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_cursor_crc@cursor-rapid-movement-256x256@pipe-a-dp-4:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_cursor_crc@cursor-sliding-128x128@pipe-a-dp-4:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_plane_alpha_blend@coverage-vs-premult-vs-constant@pipe-a-dp-4:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_plane_cursor@overlay@pipe-a-dp-4-size-128:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_plane_cursor@overlay@pipe-a-dp-4-size-256:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_plane_cursor@overlay@pipe-a-dp-4-size-64:
*  
*  Statuses : 1 pass(s)
*  Exec time: [0.0] s
*  igt@kms_plane_cursor@viewport@pipe-a-dp-4-size-128:
*  
*  Statuses : 1 pass(s)
*  

Re: [REGRESSION]: nouveau: Asynchronous wait on fence

[Owen T. Heisler]

On 11/21/23 09:16, Linux regression tracking (Thorsten Leemhuis) wrote:

On 15.11.23 07:19, Owen T. Heisler wrote:

On 10/31/23 04:18, Linux regression tracking (Thorsten Leemhuis) wrote:

On 28.10.23 04:46, Owen T. Heisler wrote:

#regzbot introduced: d386a4b54607cf6f76e23815c2c9a3abc1d66882
#regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/180

## Problem

1. Connect external display to DVI port on dock and run X with both
     displays in use.
2. Wait hours or days.
3. Suddenly the secondary Nvidia-connected display turns off and X stops
     responding to keyboard/mouse input. In *some* cases it is
possible to
     switch to a virtual TTY with Ctrl+Alt+Fn and log in there.



Here is a decoded kernel log from an
untainted kernel:

https://gitlab.freedesktop.org/drm/nouveau/uploads/c120faf09da46f9c74006df9f1d14442/async-wait-on-fence-180.log



Maybe one of the nouveau developer can take a quick look at
d386a4b54607cf and suggest a simple way to revert it in latest mainline.
Maybe just removing the main chunk of code that is added is all that it
takes.


I was able to resolve the revert conflict; it was indeed trivial though 
I did not realize it initially. I am currently testing v6.6 with the 
culprit commit reverted. I need to test for at least a full week (ending 
11-23) before I can assume it fixes the problem.


After that I can try the latest v6.7-rc as you suggested.

I have updated the bug description at
.

Thanks again,
Owen

--
Owen T. Heisler

[PATCH] nouveau/gsp: allocate enough space for all channel ids.

[Dave Airlie]

From: Dave Airlie 

This probably isn't the ideal fix, but we ended up using chids
sparsely, and lots of things rely on indexing into the full range,
so just allocate the full range up front.

The GSP code fixes 8 channels into a userd page, but we end up using
a single userd page per channel so end up sparsely using the range.

Fixes a few crashes seen with multiple channels.

Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/277
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
index 3adbb05ff587..d088e636edc3 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/r535.c
@@ -539,7 +539,7 @@ r535_fifo_runl_ctor(struct nvkm_fifo *fifo)
struct nvkm_runl *runl;
struct nvkm_engn *engn;
u32 cgids = 2048;
-   u32 chids = 2048 / CHID_PER_USERD;
+   u32 chids = 2048;
int ret;
NV2080_CTRL_FIFO_GET_DEVICE_INFO_TABLE_PARAMS *ctrl;
 
-- 
2.42.0

Re: [PATCH v2 2/2] drm/msm/dp: attach the DP subconnector property

[Linux regression tracking (Thorsten Leemhuis)]

On 21.11.23 19:50, Abhinav Kumar wrote:
> On 11/21/2023 9:57 AM, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 15.11.23 19:06, Abhinav Kumar wrote:
>>> On 11/15/2023 12:06 AM, Johan Hovold wrote:
 On Wed, Oct 25, 2023 at 12:23:10PM +0300, Dmitry Baryshkov wrote:
> While developing and testing the commit bfcc3d8f94f4 ("drm/msm/dp:
> support setting the DP subconnector type") I had the patch [1] in my
> tree. I haven't noticed that it was a dependency for the commit in
> question. Mea culpa.

 This also broke boot on the Lenovo ThinkPad X13s.

 Would be nice to get this fixed ASAP so that further people don't have
 to debug this known regression.
>>>
>>> I will queue this patch for -fixes rightaway.
>>
>> Thx. I noticed that this fix is still not in -next. I then investigated
>> and I found it was applied on Thursday last week here:
>> https://gitlab.freedesktop.org/drm/msm/-/commits/msm-fixes?ref_type=heads
>>
>> Makes me wonder: when will that patch go to a branch that is included in
>> -next? And when will it move on towards mainline?
> 
> This has been included in a pull request for 6.7-rc3 to the DRM tree and
> shall make it to -next from there.

Ahh, great, thx, I was slowly getting worried.

Ciao, Thorsten

> Since the patch has not landed yet (and even was not reviewed)
> and since one of the bridges erroneously uses USB connector type
> instead
> of DP, attach the property directly from the MSM DP driver.
>
> This fixes the following oops on DP HPD event:
>
>    drm_object_property_set_value
> (drivers/gpu/drm/drm_mode_object.c:288)
>    dp_display_process_hpd_high
> (drivers/gpu/drm/msm/dp/dp_display.c:402)
>    dp_hpd_plug_handle.isra.0 (drivers/gpu/drm/msm/dp/dp_display.c:604)
>    hpd_event_thread (drivers/gpu/drm/msm/dp/dp_display.c:1110)
>    kthread (kernel/kthread.c:388)
>    ret_from_fork (arch/arm64/kernel/entry.S:858)

 This only says where the oops happened, it doesn't necessarily in
 itself
 indicate an oops at all or that in this case it's a NULL pointer
 dereference.

 On the X13s I'm seeing the NULL deref in a different path during boot,
 and when this happens after a deferred probe (due to the panel lookup
 mess) it hangs the machine, which makes it a bit of a pain to debug:

  Unable to handle kernel NULL pointer dereference at virtual
 address 0060
  ...
  CPU: 4 PID: 57 Comm: kworker/u16:1 Not tainted 6.7.0-rc1 #4
  Hardware name: Qualcomm QRD, BIOS
 6.0.220110.BOOT.MXF.1.1-00470-MAKENA-1 01/10/2022
  ...
  Call trace:
   drm_object_property_set_value+0x0/0x88 [drm]
   dp_display_process_hpd_high+0xa0/0x14c [msm]
   dp_hpd_plug_handle.constprop.0.isra.0+0x90/0x110 [msm]
   dp_bridge_atomic_enable+0x184/0x21c [msm]
   edp_bridge_atomic_enable+0x60/0x94 [msm]
   drm_atomic_bridge_chain_enable+0x54/0xc8 [drm]
   drm_atomic_helper_commit_modeset_enables+0x194/0x26c
 [drm_kms_helper]
   msm_atomic_commit_tail+0x204/0x804 [msm]
   commit_tail+0xa4/0x18c [drm_kms_helper]
   drm_atomic_helper_commit+0x19c/0x1b0 [drm_kms_helper]
   drm_atomic_commit+0xa4/0x104 [drm]
   drm_client_modeset_commit_atomic+0x22c/0x298 [drm]
   drm_client_modeset_commit_locked+0x60/0x1c0 [drm]
   drm_client_modeset_commit+0x30/0x58 [drm]
   __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xfc
 [drm_kms_helper]
   drm_fb_helper_set_par+0x30/0x4c [drm_kms_helper]
   fbcon_init+0x224/0x49c
   visual_init+0xb0/0x108
   do_bind_con_driver.isra.0+0x19c/0x38c
   do_take_over_console+0x140/0x1ec
   do_fbcon_takeover+0x6c/0xe4
   fbcon_fb_registered+0x180/0x1f0
   register_framebuffer+0x19c/0x228
   __drm_fb_helper_initial_config_and_unlock+0x2e8/0x4e8
 [drm_kms_helper]
   drm_fb_helper_initial_config+0x3c/0x4c [drm_kms_helper]
   msm_fbdev_client_hotplug+0x84/0xcc [msm]
   drm_client_register+0x5c/0xa0 [drm]
   msm_fbdev_setup+0x94/0x148 [msm]
   msm_drm_bind+0x3d0/0x42c [msm]
   try_to_bring_up_aggregate_device+0x1ec/0x2f4
   __component_add+0xa8/0x194
   component_add+0x14/0x20
   dp_display_probe+0x278/0x41c [msm]

> [1] https://patchwork.freedesktop.org/patch/30/
>
> Fixes: bfcc3d8f94f4 ("drm/msm/dp: support setting the DP subconnector
> type")
> Reviewed-by: Abhinav Kumar 
> Signed-off-by: Dmitry Baryshkov 

 Reviewed-by: Johan Hovold 
 Tested-by: Johan Hovold 

>>>
>>> Thanks !
>>>
 Johan
> 
> 

[PATCH 1/1] drm/i915/pxp: Add missing tag for Wa_14019159160

[Alan Previn]

Add missing tag for "Wa_14019159160 - Case 2" (for existing
PXP code that ensures run alone mode bit is set to allow
PxP-decryption.

Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c 
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 7c367ba8d9dc..c758fe4906a5 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -863,8 +863,10 @@ static bool ctx_needs_runalone(const struct intel_context 
*ce)
bool ctx_is_protected = false;
 
/*
+* Wa_140191591606 - Case 2: mtl
 * On MTL and newer platforms, protected contexts require setting
-* the LRC run-alone bit or else the encryption will not happen.
+* the LRC run-alone bit or else the encryption/decryption will not 
happen.
+* NOTE: Case 2 only applies to PXP use-case of said workaround.
 */
if (GRAPHICS_VER_FULL(ce->engine->i915) >= IP_VER(12, 70) &&
(ce->engine->class == COMPUTE_CLASS || ce->engine->class == 
RENDER_CLASS)) {

base-commit: dbdb47c227dc21b7bf98ada039bf42aac4b58b8b
-- 
2.39.0

Re: [PATCH] gpu: display: remove unnecessary braces to fix coding style

[Alex Deucher]

On Tue, Nov 21, 2023 at 4:27 AM Christian König
 wrote:
>
> Am 21.11.23 um 05:36 schrieb RutingZhang:
> > checkpatch complains that:
> >
> > WARNING: braces {} are not necessary for single statement blocks
> > +if (pool->base.irqs != NULL) {
> > +dal_irq_service_destroy(>base.irqs);
> > +}
> >
> > Fixed it by removing unnecessary braces to fix the coding style issue.
> >
> > Signed-off-by: RutingZhang 
> > Reviewed-by: Dongliang Mu 
>
> Subject line prefix should be "drm/amdgpu".
>
> Apart from this nit it looks good to me, but might be already fixed
> internally.

Applied.  Thanks!

Alex

>
> Regards,
> Christian.
>
> > ---
> >   drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c 
> > b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > index 447de8492594..6835dbb733a2 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > @@ -713,9 +713,8 @@ static void dcn21_resource_destruct(struct 
> > dcn21_resource_pool *pool)
> >   pool->base.hubps[i] = NULL;
> >   }
> >
> > - if (pool->base.irqs != NULL) {
> > + if (pool->base.irqs != NULL)
> >   dal_irq_service_destroy(>base.irqs);
> > - }
> >   }
> >
> >   for (i = 0; i < pool->base.res_cap->num_ddc; i++) {
>

Re: [PATCH v2 2/2] drm/msm/dp: attach the DP subconnector property

[Abhinav Kumar]

On 11/21/2023 9:57 AM, Linux regression tracking (Thorsten Leemhuis) wrote:

On 15.11.23 19:06, Abhinav Kumar wrote:

On 11/15/2023 12:06 AM, Johan Hovold wrote:

On Wed, Oct 25, 2023 at 12:23:10PM +0300, Dmitry Baryshkov wrote:

While developing and testing the commit bfcc3d8f94f4 ("drm/msm/dp:
support setting the DP subconnector type") I had the patch [1] in my
tree. I haven't noticed that it was a dependency for the commit in
question. Mea culpa.


This also broke boot on the Lenovo ThinkPad X13s.

Would be nice to get this fixed ASAP so that further people don't have
to debug this known regression.


I will queue this patch for -fixes rightaway.


Thx. I noticed that this fix is still not in -next. I then investigated
and I found it was applied on Thursday last week here:
https://gitlab.freedesktop.org/drm/msm/-/commits/msm-fixes?ref_type=heads

Makes me wonder: when will that patch go to a branch that is included in
-next? And when will it move on towards mainline?



This has been included in a pull request for 6.7-rc3 to the DRM tree and 
shall make it to -next from there.



Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.


Since the patch has not landed yet (and even was not reviewed)
and since one of the bridges erroneously uses USB connector type instead
of DP, attach the property directly from the MSM DP driver.

This fixes the following oops on DP HPD event:

   drm_object_property_set_value (drivers/gpu/drm/drm_mode_object.c:288)
   dp_display_process_hpd_high (drivers/gpu/drm/msm/dp/dp_display.c:402)
   dp_hpd_plug_handle.isra.0 (drivers/gpu/drm/msm/dp/dp_display.c:604)
   hpd_event_thread (drivers/gpu/drm/msm/dp/dp_display.c:1110)
   kthread (kernel/kthread.c:388)
   ret_from_fork (arch/arm64/kernel/entry.S:858)


This only says where the oops happened, it doesn't necessarily in itself
indicate an oops at all or that in this case it's a NULL pointer
dereference.

On the X13s I'm seeing the NULL deref in a different path during boot,
and when this happens after a deferred probe (due to the panel lookup
mess) it hangs the machine, which makes it a bit of a pain to debug:

     Unable to handle kernel NULL pointer dereference at virtual
address 0060
     ...
     CPU: 4 PID: 57 Comm: kworker/u16:1 Not tainted 6.7.0-rc1 #4
     Hardware name: Qualcomm QRD, BIOS
6.0.220110.BOOT.MXF.1.1-00470-MAKENA-1 01/10/2022
     ...
     Call trace:
  drm_object_property_set_value+0x0/0x88 [drm]
  dp_display_process_hpd_high+0xa0/0x14c [msm]
  dp_hpd_plug_handle.constprop.0.isra.0+0x90/0x110 [msm]
  dp_bridge_atomic_enable+0x184/0x21c [msm]
  edp_bridge_atomic_enable+0x60/0x94 [msm]
  drm_atomic_bridge_chain_enable+0x54/0xc8 [drm]
  drm_atomic_helper_commit_modeset_enables+0x194/0x26c
[drm_kms_helper]
  msm_atomic_commit_tail+0x204/0x804 [msm]
  commit_tail+0xa4/0x18c [drm_kms_helper]
  drm_atomic_helper_commit+0x19c/0x1b0 [drm_kms_helper]
  drm_atomic_commit+0xa4/0x104 [drm]
  drm_client_modeset_commit_atomic+0x22c/0x298 [drm]
  drm_client_modeset_commit_locked+0x60/0x1c0 [drm]
  drm_client_modeset_commit+0x30/0x58 [drm]
  __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xfc
[drm_kms_helper]
  drm_fb_helper_set_par+0x30/0x4c [drm_kms_helper]
  fbcon_init+0x224/0x49c
  visual_init+0xb0/0x108
  do_bind_con_driver.isra.0+0x19c/0x38c
  do_take_over_console+0x140/0x1ec
  do_fbcon_takeover+0x6c/0xe4
  fbcon_fb_registered+0x180/0x1f0
  register_framebuffer+0x19c/0x228
  __drm_fb_helper_initial_config_and_unlock+0x2e8/0x4e8
[drm_kms_helper]
  drm_fb_helper_initial_config+0x3c/0x4c [drm_kms_helper]
  msm_fbdev_client_hotplug+0x84/0xcc [msm]
  drm_client_register+0x5c/0xa0 [drm]
  msm_fbdev_setup+0x94/0x148 [msm]
  msm_drm_bind+0x3d0/0x42c [msm]
  try_to_bring_up_aggregate_device+0x1ec/0x2f4
  __component_add+0xa8/0x194
  component_add+0x14/0x20
  dp_display_probe+0x278/0x41c [msm]


[1] https://patchwork.freedesktop.org/patch/30/

Fixes: bfcc3d8f94f4 ("drm/msm/dp: support setting the DP subconnector
type")
Reviewed-by: Abhinav Kumar 
Signed-off-by: Dmitry Baryshkov 


Reviewed-by: Johan Hovold 
Tested-by: Johan Hovold 



Thanks !


Johan

Re: [PATCH v2] drm/msm: remove unnecessary NULL check

[Abhinav Kumar]

On Fri, 13 Oct 2023 11:25:15 +0300, Dan Carpenter wrote:
> This NULL check was required when it was added, but we shuffled the code
> around and now it's not.  The inconsistent NULL checking triggers a
> Smatch warning:
> 
> drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c:847 mdp5_init() warn:
> variable dereferenced before check 'mdp5_kms' (see line 782)
> 
> [...]

Applied, thanks!

[1/1] drm/msm: remove unnecessary NULL check
  https://gitlab.freedesktop.org/drm/msm/-/commit/56466f653cb5

Best regards,
-- 
Abhinav Kumar 

Re: [PATCH v2 0/2] drm/msm/dp: fix DP subconnector handling

[Abhinav Kumar]

On Wed, 25 Oct 2023 12:23:08 +0300, Dmitry Baryshkov wrote:
> Fix two failovers in the DP subconnector's patch. I didn't notice that I
> had another patch adding the property in my tree and later Abel pointed
> out that we shouldn't use subconnector type for eDP panels.
> 
> Fixes since v1:
>  - Add Abel's patch.
> 
> [...]

Applied, thanks!

[1/2] drm/msm/dp: don't touch DP subconnector property in eDP case
  https://gitlab.freedesktop.org/drm/msm/-/commit/ebfa85c504cb
[2/2] drm/msm/dp: attach the DP subconnector property
  https://gitlab.freedesktop.org/drm/msm/-/commit/21133266ca12

Best regards,
-- 
Abhinav Kumar 

Re: [PATCH] drm/msm/dpu: Add missing safe_lut_tbl in sc8280xp catalog

[Abhinav Kumar]

On Mon, 30 Oct 2023 16:23:20 -0700, Bjorn Andersson wrote:
> During USB transfers on the SC8280XP __arm_smmu_tlb_sync() is seen to
> typically take 1-2ms to complete. As expected this results in poor
> performance, something that has been mitigated by proposing running the
> iommu in non-strict mode (boot with iommu.strict=0).
> 
> This turns out to be related to the SAFE logic, and programming the QOS
> SAFE values in the DPU (per suggestion from Rob and Doug) reduces the
> TLB sync time to below 10us, which means significant less time spent
> with interrupts disabled and a significant boost in throughput.
> 
> [...]

Applied, thanks!

[1/1] drm/msm/dpu: Add missing safe_lut_tbl in sc8280xp catalog
  https://gitlab.freedesktop.org/drm/msm/-/commit/a33b2431d11b

Best regards,
-- 
Abhinav Kumar 

Re: [PATCH] drm/msm: remove exra drm_kms_helper_poll_init() call

[Abhinav Kumar]

On Tue, 07 Nov 2023 13:14:13 +0200, Dmitry Baryshkov wrote:
> It seems during rebases I have left a call to drm_kms_helper_poll_init()
> which is not guarded by the (priv->kms_init) check. This leads to the
> crash for the boards which don't have KMS output. Drop this call, as
> there is a correctly guarded one next to the one being removed.
> 
> 

Applied, thanks!

[1/1] drm/msm: remove exra drm_kms_helper_poll_init() call
  https://gitlab.freedesktop.org/drm/msm/-/commit/3944e343e54b

Best regards,
-- 
Abhinav Kumar 

Re: [PATCH v2] drm/msm/dsi: use the correct VREG_CTRL_1 value for 4nm cphy

[Abhinav Kumar]

On Thu, 09 Nov 2023 19:02:14 -0500, Jonathan Marek wrote:
> Use the same value as the downstream driver. This change is needed for CPHY
> mode to work correctly.
> 
> 

Applied, thanks!

[1/1] drm/msm/dsi: use the correct VREG_CTRL_1 value for 4nm cphy
  https://gitlab.freedesktop.org/drm/msm/-/commit/b3e0f94d1570

Best regards,
-- 
Abhinav Kumar 

Re: [PATCH V3] drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBP

[Doug Anderson]

Hi,

On Mon, Nov 20, 2023 at 10:05 AM Doug Anderson  wrote:
>
> Hi,
>
> On Sun, Nov 19, 2023 at 6:01 PM Cong Yang
>  wrote:
> >
> > The refresh reported by modetest is 60.46Hz, and the actual measurement
> > is 60.01Hz, which is outside the expected tolerance. Adjust hporch and
> > pixel clock to fix it. After repair, modetest and actual measurement were
> > all 60.01Hz.
> >
> > Modetest refresh = Pixel CLK/ htotal* vtotal, but measurement frame rate
> > is HS->LP cycle time(Vblanking). Measured frame rate is not only affecte
> > by Htotal/Vtotal/pixel clock, also affected by Lane-num/PixelBit/LineTime
> > /DSI CLK. Assume that the DSI controller could not make the mode that we
> > requested(presumably it's PLL couldn't generate the exact pixel clock?).
> > If you use a different DSI controller, you may need to readjust these
> > parameters. Now this panel looks like it's only used by me on the MTK
> > platform, so let's change this set of parameters.
> >
> > Fixes: 1bc2ef065f13 ("drm/panel: Support for Starry-himax83102-j02 TDDI 
> > MIPI-DSI panel")
> > Signed-off-by: Cong Yang 
> > Reviewed-by: Douglas Anderson 
> > ---
> > Chage since V2:
> >
> > - Update commit message.
> >
> > V2: 
> > https://lore.kernel.org/all/20231117032500.2923624-1-yangco...@huaqin.corp-partner.google.com
> >
> > Chage since V1:
> >
> > - Update commit message.
> >
> > V1: 
> > https://lore.kernel.org/all/20231110094553.2361842-1-yangco...@huaqin.corp-partner.google.com
> > ---
> >  drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
>
> As per previous discussions, this seems OK to me. I'll give it one
> more day for anyone to speak up and then plan to land it.

Pushed to drm-misc-fixes:

cea7008190ad drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02
panel HFP and HBP

Re: [PATCH v2 2/2] drm/msm/dp: attach the DP subconnector property

[Linux regression tracking (Thorsten Leemhuis)]

On 15.11.23 19:06, Abhinav Kumar wrote:
> On 11/15/2023 12:06 AM, Johan Hovold wrote:
>> On Wed, Oct 25, 2023 at 12:23:10PM +0300, Dmitry Baryshkov wrote:
>>> While developing and testing the commit bfcc3d8f94f4 ("drm/msm/dp:
>>> support setting the DP subconnector type") I had the patch [1] in my
>>> tree. I haven't noticed that it was a dependency for the commit in
>>> question. Mea culpa.
>>
>> This also broke boot on the Lenovo ThinkPad X13s.
>>
>> Would be nice to get this fixed ASAP so that further people don't have
>> to debug this known regression.
> 
> I will queue this patch for -fixes rightaway.

Thx. I noticed that this fix is still not in -next. I then investigated
and I found it was applied on Thursday last week here:
https://gitlab.freedesktop.org/drm/msm/-/commits/msm-fixes?ref_type=heads

Makes me wonder: when will that patch go to a branch that is included in
-next? And when will it move on towards mainline?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

>>> Since the patch has not landed yet (and even was not reviewed)
>>> and since one of the bridges erroneously uses USB connector type instead
>>> of DP, attach the property directly from the MSM DP driver.
>>>
>>> This fixes the following oops on DP HPD event:
>>>
>>>   drm_object_property_set_value (drivers/gpu/drm/drm_mode_object.c:288)
>>>   dp_display_process_hpd_high (drivers/gpu/drm/msm/dp/dp_display.c:402)
>>>   dp_hpd_plug_handle.isra.0 (drivers/gpu/drm/msm/dp/dp_display.c:604)
>>>   hpd_event_thread (drivers/gpu/drm/msm/dp/dp_display.c:1110)
>>>   kthread (kernel/kthread.c:388)
>>>   ret_from_fork (arch/arm64/kernel/entry.S:858)
>>
>> This only says where the oops happened, it doesn't necessarily in itself
>> indicate an oops at all or that in this case it's a NULL pointer
>> dereference.
>>
>> On the X13s I'm seeing the NULL deref in a different path during boot,
>> and when this happens after a deferred probe (due to the panel lookup
>> mess) it hangs the machine, which makes it a bit of a pain to debug:
>>
>>     Unable to handle kernel NULL pointer dereference at virtual
>> address 0060
>>     ...
>>     CPU: 4 PID: 57 Comm: kworker/u16:1 Not tainted 6.7.0-rc1 #4
>>     Hardware name: Qualcomm QRD, BIOS
>> 6.0.220110.BOOT.MXF.1.1-00470-MAKENA-1 01/10/2022
>>     ...
>>     Call trace:
>>  drm_object_property_set_value+0x0/0x88 [drm]
>>  dp_display_process_hpd_high+0xa0/0x14c [msm]
>>  dp_hpd_plug_handle.constprop.0.isra.0+0x90/0x110 [msm]
>>  dp_bridge_atomic_enable+0x184/0x21c [msm]
>>  edp_bridge_atomic_enable+0x60/0x94 [msm]
>>  drm_atomic_bridge_chain_enable+0x54/0xc8 [drm]
>>  drm_atomic_helper_commit_modeset_enables+0x194/0x26c
>> [drm_kms_helper]
>>  msm_atomic_commit_tail+0x204/0x804 [msm]
>>  commit_tail+0xa4/0x18c [drm_kms_helper]
>>  drm_atomic_helper_commit+0x19c/0x1b0 [drm_kms_helper]
>>  drm_atomic_commit+0xa4/0x104 [drm]
>>  drm_client_modeset_commit_atomic+0x22c/0x298 [drm]
>>  drm_client_modeset_commit_locked+0x60/0x1c0 [drm]
>>  drm_client_modeset_commit+0x30/0x58 [drm]
>>  __drm_fb_helper_restore_fbdev_mode_unlocked+0xbc/0xfc
>> [drm_kms_helper]
>>  drm_fb_helper_set_par+0x30/0x4c [drm_kms_helper]
>>  fbcon_init+0x224/0x49c
>>  visual_init+0xb0/0x108
>>  do_bind_con_driver.isra.0+0x19c/0x38c
>>  do_take_over_console+0x140/0x1ec
>>  do_fbcon_takeover+0x6c/0xe4
>>  fbcon_fb_registered+0x180/0x1f0
>>  register_framebuffer+0x19c/0x228
>>  __drm_fb_helper_initial_config_and_unlock+0x2e8/0x4e8
>> [drm_kms_helper]
>>  drm_fb_helper_initial_config+0x3c/0x4c [drm_kms_helper]
>>  msm_fbdev_client_hotplug+0x84/0xcc [msm]
>>  drm_client_register+0x5c/0xa0 [drm]
>>  msm_fbdev_setup+0x94/0x148 [msm]
>>  msm_drm_bind+0x3d0/0x42c [msm]
>>  try_to_bring_up_aggregate_device+0x1ec/0x2f4
>>  __component_add+0xa8/0x194
>>  component_add+0x14/0x20
>>  dp_display_probe+0x278/0x41c [msm]
>>
>>> [1] https://patchwork.freedesktop.org/patch/30/
>>>
>>> Fixes: bfcc3d8f94f4 ("drm/msm/dp: support setting the DP subconnector
>>> type")
>>> Reviewed-by: Abhinav Kumar 
>>> Signed-off-by: Dmitry Baryshkov 
>>
>> Reviewed-by: Johan Hovold 
>> Tested-by: Johan Hovold 
>>
> 
> Thanks !
> 
>> Johan

Re: [PATCH 16/17] arm64: dts: exynos850: add specific compatibles to several blocks

[Sam Protsenko]

On Wed, Nov 8, 2023 at 4:44 AM Krzysztof Kozlowski
 wrote:
>
> Exynos850 reuses several devices from older designs, thus historically
> we kept the old (block's) compatible only.  This works fine and there is
> no bug here, however guidelines expressed in
> Documentation/devicetree/bindings/writing-bindings.rst state that:
> 1. Compatibles should be specific.
> 2. We should add new compatibles in case of bugs or features.
>
> Add compatibles specific to Exynos850 in front of all old-SoC-like
> compatibles.  This will also help reviews of new code using existing
> DTS as template.  No functional impact on Linux drivers behavior.
>
> Signed-off-by: Krzysztof Kozlowski 
> ---

Reviewed-by: Sam Protsenko 

>  arch/arm64/boot/dts/exynos/exynos850.dtsi | 34 +--
>  1 file changed, 20 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi 
> b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> index 53104e65b9c6..df5ea43ebcad 100644
> --- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> @@ -396,7 +396,7 @@ pinctrl_aud: pinctrl@14a6 {
> };
>
> rtc: rtc@11a3 {
> -   compatible = "samsung,s3c6410-rtc";
> +   compatible = "samsung,exynos850-rtc", 
> "samsung,s3c6410-rtc";
> reg = <0x11a3 0x100>;
> interrupts = ,
>  ;
> @@ -406,7 +406,8 @@ rtc: rtc@11a3 {
> };
>
> mmc_0: mmc@1210 {
> -   compatible = "samsung,exynos7-dw-mshc-smu";
> +   compatible = "samsung,exynos850-dw-mshc-smu",
> +"samsung,exynos7-dw-mshc-smu";
> reg = <0x1210 0x2000>;
> interrupts = ;
> #address-cells = <1>;
> @@ -419,7 +420,7 @@ mmc_0: mmc@1210 {
> };
>
> i2c_0: i2c@1383 {
> -   compatible = "samsung,s3c2440-i2c";
> +   compatible = "samsung,exynos850-i2c", 
> "samsung,s3c2440-i2c";
> reg = <0x1383 0x100>;
> interrupts = ;
> #address-cells = <1>;
> @@ -432,7 +433,7 @@ i2c_0: i2c@1383 {
> };
>
> i2c_1: i2c@1384 {
> -   compatible = "samsung,s3c2440-i2c";
> +   compatible = "samsung,exynos850-i2c", 
> "samsung,s3c2440-i2c";
> reg = <0x1384 0x100>;
> interrupts = ;
> #address-cells = <1>;
> @@ -445,7 +446,7 @@ i2c_1: i2c@1384 {
> };
>
> i2c_2: i2c@1385 {
> -   compatible = "samsung,s3c2440-i2c";
> +   compatible = "samsung,exynos850-i2c", 
> "samsung,s3c2440-i2c";
> reg = <0x1385 0x100>;
> interrupts = ;
> #address-cells = <1>;
> @@ -458,7 +459,7 @@ i2c_2: i2c@1385 {
> };
>
> i2c_3: i2c@1386 {
> -   compatible = "samsung,s3c2440-i2c";
> +   compatible = "samsung,exynos850-i2c", 
> "samsung,s3c2440-i2c";
> reg = <0x1386 0x100>;
> interrupts = ;
> #address-cells = <1>;
> @@ -471,7 +472,7 @@ i2c_3: i2c@1386 {
> };
>
> i2c_4: i2c@1387 {
> -   compatible = "samsung,s3c2440-i2c";
> +   compatible = "samsung,exynos850-i2c", 
> "samsung,s3c2440-i2c";
> reg = <0x1387 0x100>;
> interrupts = ;
> #address-cells = <1>;
> @@ -485,7 +486,7 @@ i2c_4: i2c@1387 {
>
> /* I2C_5 (also called CAM_PMIC_I2C in TRM) */
> i2c_5: i2c@1388 {
> -   compatible = "samsung,s3c2440-i2c";
> +   compatible = "samsung,exynos850-i2c", 
> "samsung,s3c2440-i2c";
> reg = <0x1388 0x100>;
> interrupts = ;
> #address-cells = <1>;
> @@ -499,7 +500,7 @@ i2c_5: i2c@1388 {
>
> /* I2C_6 (also called MOTOR_I2C in TRM) */
> i2c_6: i2c@1389 {
> -   compatible = "samsung,s3c2440-i2c";
> +   compatible = "samsung,exynos850-i2c", 
> "samsung,s3c2440-i2c";
> reg = <0x1389 0x100>;
> interrupts = ;
> #address-cells = <1>;
> @@ -640,7 +641,8 @@ usi_hsi2c_0: usi@138a00c0 {
> status = "disabled";
>
> hsi2c_0: i2c@138a {
> - 

[pull] drm/msm: drm-msm-fixes-2023-11-21 for v6.7-rc3

[Rob Clark]

Hi Dave,

A few fixes for v6.7, description below

The following changes since commit b08d26dac1a1075c874f40ee02ec8ddc39e20146:

  drm/msm/a7xx: actually use a7xx state registers (2023-10-16 09:38:56 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git tags/drm-msm-fixes-2023-11-21

for you to fetch changes up to 56466f653cb59a8f46e991ad1e285f43afdca7d4:

  drm/msm: remove unnecessary NULL check (2023-11-17 15:32:49 -0800)


Fixes for v6.7-rc3:

- Fix the VREG_CTRL_1 for 4nm CPHY to match downstream
- Remove duplicate call to drm_kms_helper_poll_init() in msm_drm_init()
- Fix the safe_lut_tbl[] for sc8280xp to match downstream
- Don't attach the drm_dp_set_subconnector_property() for eDP
- Fix to attach drm_dp_set_subconnector_property() for DP. Otherwise
  there is a bootup crash on multiple targets
- Remove unnecessary NULL check left behind during cleanup


Abel Vesa (1):
  drm/msm/dp: don't touch DP subconnector property in eDP case

Bjorn Andersson (1):
  drm/msm/dpu: Add missing safe_lut_tbl in sc8280xp catalog

Dan Carpenter (1):
  drm/msm: remove unnecessary NULL check

Dmitry Baryshkov (2):
  drm/msm: remove exra drm_kms_helper_poll_init() call
  drm/msm/dp: attach the DP subconnector property

Jonathan Marek (1):
  drm/msm/dsi: use the correct VREG_CTRL_1 value for 4nm cphy

 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h |  1 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c |  3 +--
 drivers/gpu/drm/msm/dp/dp_display.c  | 15 ++-
 drivers/gpu/drm/msm/dp/dp_drm.c  |  3 +++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c|  2 +-
 drivers/gpu/drm/msm/msm_drv.c|  2 --
 6 files changed, 16 insertions(+), 10 deletions(-)

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Krzysztof Kozlowski]

On 21/11/2023 17:55, Boris Brezillon wrote:
> On Tue, 21 Nov 2023 17:11:42 +0100
> AngeloGioacchino Del Regno 
> wrote:
> 
>> Il 21/11/23 16:34, Krzysztof Kozlowski ha scritto:
>>> On 08/11/2023 14:20, Steven Price wrote:  
>>>> On 02/11/2023 14:15, AngeloGioacchino Del Regno wrote:  
>>>>> The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request
>>>>> powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones:
>>>>> this means that in order to request poweroff of cores, we are supposed
>>>>> to write a bitmask of cores that should be powered off!
>>>>> This means that the panfrost_gpu_power_off() function has always been
>>>>> doing nothing.
>>>>>
>>>>> Fix powering off the GPU by writing a bitmask of the cores to poweroff
>>>>> to the relevant PWROFF_LO registers and then check that the transition
>>>>> (from ON to OFF) has finished by polling the relevant PWRTRANS_LO
>>>>> registers.
>>>>>
>>>>> While at it, in order to avoid code duplication, move the core mask
>>>>> logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask()
>>>>> function, used in both poweron and poweroff.
>>>>>
>>>>> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
>>>>> Signed-off-by: AngeloGioacchino Del Regno 
>>>>>   
>>>
>>>
>>> Hi,
>>>
>>> This commit was added to next recently but it causes "external abort on
>>> non-linefetch" during boot of my Odroid HC1 board.
>>>
>>> At least bisect points to it.
>>>
>>> If fixed, please add:
>>>
>>> Reported-by: Krzysztof Kozlowski 
>>>
>>> [4.861683] 8<--- cut here ---
>>> [4.863429] Unhandled fault: external abort on non-linefetch (0x1008) at 
>>> 0xf0c8802c
>>> [4.871018] [f0c8802c] *pgd=433ed811, *pte=11800653, *ppte=11800453
>>> ...
>>> [5.164010]  panfrost_gpu_irq_handler from 
>>> __handle_irq_event_percpu+0xcc/0x31c
>>> [5.171276]  __handle_irq_event_percpu from handle_irq_event+0x38/0x80
>>> [5.177765]  handle_irq_event from handle_fasteoi_irq+0x9c/0x250
>>> [5.183743]  handle_fasteoi_irq from generic_handle_domain_irq+0x28/0x38
>>> [5.190417]  generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
>>> [5.196741]  gic_handle_irq from generic_handle_arch_irq+0x34/0x44
>>> [5.202893]  generic_handle_arch_irq from __irq_svc+0x8c/0xd0
>>>
>>> Full log:
>>> https://krzk.eu/#/builders/21/builds/4392/steps/11/logs/serial0
>>>   
>>
>> Hey Krzysztof,
>>
>> This is interesting. It might be about the cores that are missing from the 
>> partial
>> core_mask raising interrupts, but an external abort on non-linefetch is 
>> strange to
>> see here.
> 
> I've seen such external aborts in the past, and the fault type has
> often been misleading. It's unlikely to have anything to do with a

Yeah, often accessing device with power or clocks gated.

> non-linefetch access, but it might be caused by a register access after
> the clock or power domain driving the register bank has been disabled.
> The following diff might help validate this theory. If that works, we
> probably want to make sure we synchronize IRQs before disabling in the
> suspend path.
> 
> --->8---
> diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h 
> b/drivers/gpu/drm/panfrost/panfrost_regs.h
> index 55ec807550b3..98df66e5cc9b 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_regs.h
> +++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
> @@ -34,8 +34,6 @@
>   (GPU_IRQ_FAULT|\
>GPU_IRQ_MULTIPLE_FAULT   |\
>GPU_IRQ_RESET_COMPLETED  |\
> -  GPU_IRQ_POWER_CHANGED|\
> -  GPU_IRQ_POWER_CHANGED_ALL|\

This helped, at least for this issue (next-20231121). Much later in
user-space boot I have lockups:
watchdog: BUG: soft lockup - CPU#4 stuck for 26s! [kworker/4:1:61]

[   56.329224]  smp_call_function_single from
__sync_rcu_exp_select_node_cpus+0x29c/0x78c
[   56.337111]  __sync_rcu_exp_select_node_cpus from
sync_rcu_exp_select_cpus+0x334/0x878
[   56.344995]  sync_rcu_exp_select_cpus from wait_rcu_exp_gp+0xc/0x18
[   56.351231]  wait_rcu_exp_gp from process_one_work+0x20c/0x620
[   56.357038]  process_one_work from worker_thread+0x1d0/0x488
[   56.362668]  worker_thread from kthread+0x104/0x138
[   56.367521]  kthread from ret_from_fork+0x14/0x28

But anyway the external abort does not appear.

Best regards,
Krzysztof

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Boris Brezillon]

On Tue, 21 Nov 2023 17:11:42 +0100
AngeloGioacchino Del Regno 
wrote:

> Il 21/11/23 16:34, Krzysztof Kozlowski ha scritto:
> > On 08/11/2023 14:20, Steven Price wrote:  
> >> On 02/11/2023 14:15, AngeloGioacchino Del Regno wrote:  
> >>> The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request
> >>> powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones:
> >>> this means that in order to request poweroff of cores, we are supposed
> >>> to write a bitmask of cores that should be powered off!
> >>> This means that the panfrost_gpu_power_off() function has always been
> >>> doing nothing.
> >>>
> >>> Fix powering off the GPU by writing a bitmask of the cores to poweroff
> >>> to the relevant PWROFF_LO registers and then check that the transition
> >>> (from ON to OFF) has finished by polling the relevant PWRTRANS_LO
> >>> registers.
> >>>
> >>> While at it, in order to avoid code duplication, move the core mask
> >>> logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask()
> >>> function, used in both poweron and poweroff.
> >>>
> >>> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> >>> Signed-off-by: AngeloGioacchino Del Regno 
> >>>   
> > 
> > 
> > Hi,
> > 
> > This commit was added to next recently but it causes "external abort on
> > non-linefetch" during boot of my Odroid HC1 board.
> > 
> > At least bisect points to it.
> > 
> > If fixed, please add:
> > 
> > Reported-by: Krzysztof Kozlowski 
> > 
> > [4.861683] 8<--- cut here ---
> > [4.863429] Unhandled fault: external abort on non-linefetch (0x1008) at 
> > 0xf0c8802c
> > [4.871018] [f0c8802c] *pgd=433ed811, *pte=11800653, *ppte=11800453
> > ...
> > [5.164010]  panfrost_gpu_irq_handler from 
> > __handle_irq_event_percpu+0xcc/0x31c
> > [5.171276]  __handle_irq_event_percpu from handle_irq_event+0x38/0x80
> > [5.177765]  handle_irq_event from handle_fasteoi_irq+0x9c/0x250
> > [5.183743]  handle_fasteoi_irq from generic_handle_domain_irq+0x28/0x38
> > [5.190417]  generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
> > [5.196741]  gic_handle_irq from generic_handle_arch_irq+0x34/0x44
> > [5.202893]  generic_handle_arch_irq from __irq_svc+0x8c/0xd0
> > 
> > Full log:
> > https://krzk.eu/#/builders/21/builds/4392/steps/11/logs/serial0
> >   
> 
> Hey Krzysztof,
> 
> This is interesting. It might be about the cores that are missing from the 
> partial
> core_mask raising interrupts, but an external abort on non-linefetch is 
> strange to
> see here.

I've seen such external aborts in the past, and the fault type has
often been misleading. It's unlikely to have anything to do with a
non-linefetch access, but it might be caused by a register access after
the clock or power domain driving the register bank has been disabled.
The following diff might help validate this theory. If that works, we
probably want to make sure we synchronize IRQs before disabling in the
suspend path.

--->8---
diff --git a/drivers/gpu/drm/panfrost/panfrost_regs.h 
b/drivers/gpu/drm/panfrost/panfrost_regs.h
index 55ec807550b3..98df66e5cc9b 100644
--- a/drivers/gpu/drm/panfrost/panfrost_regs.h
+++ b/drivers/gpu/drm/panfrost/panfrost_regs.h
@@ -34,8 +34,6 @@
  (GPU_IRQ_FAULT|\
   GPU_IRQ_MULTIPLE_FAULT   |\
   GPU_IRQ_RESET_COMPLETED  |\
-  GPU_IRQ_POWER_CHANGED|\
-  GPU_IRQ_POWER_CHANGED_ALL|\
   GPU_IRQ_PERFCNT_SAMPLE_COMPLETED |\
   GPU_IRQ_CLEAN_CACHES_COMPLETED)
 #define GPU_IRQ_MASK_ERROR \

Re: WARNING in allocate_mst_payload

[Jeff Layton]

The monitors are individually connected to the same card. The Dell 34"
is connected via displayport, and the Sceptre monitor is connected via
HDMI.

Thanks,
Jeff


On Tue, 2023-11-21 at 14:13 +0100, Christian König wrote:
> Hi Jeff,
> 
> first of all adding Harry from our display team.
> 
>  From a quick look the obvious missing information is how are your 
> monitors wired up? Are those individually DP or HDMI connected to the PC 
> or are they daisy chained through MST?
> 
> If it's daisy chained please double check that you don't have a faulty 
> connection and maybe individually connect them for a test if possible.
> 
> Regards,
> Christian.
> 
> Am 21.11.23 um 14:01 schrieb Jeff Layton:
> > I have a recurring problem where my workstation tries to put the monitor
> > to sleep, which triggers a warning down in the depths of the video card
> > driver. When I return to the machine the monitor is black, but not in
> > powersave mode and all of the windows on my desktop have been shuffled
> > off to the second monitor.
> > 
> > I've seen this since at least v6.3 or so (though the problem may predate
> > that). The kernel is stock Fedora kernel. It's occurs fairly reliably,
> > and I'm happy to help test patches.
> > 
> > I took a quick look at the sources and the reported line corresponds
> > with this assertion in  allocate_mst_payload:
> > 
> >  ASSERT(proposed_table.stream_count > 0);
> > 
> > I've attached the output from wayland-info, and the stack traces follow.
> > Let me know if any other info would be helpful.
> > 
> > 
> > [ 4655.946669] [ cut here ]
> > [ 4655.946677] WARNING: CPU: 12 PID: 3979 at 
> > drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:1484 
> > link_set_dpms_on+0xbe5/0xca0 [amdgpu]
> > [ 4655.947689] Modules linked in: uinput xt_mark rfcomm snd_seq_dummy 
> > snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core tun xt_CHECKSUM 
> > xt_MASQUERADE xt_conntrack ipt_REJECT nf_nat_tftp nf_conntrack_tftp 
> > nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 
> > nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 
> > nft_reject nft_ct nft_chain_nat ip6table_nat ip6table_mangle ip6table_raw 
> > ip6table_security iptable_nat nf_nat bridge nf_conntrack stp llc 
> > nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security 
> > ip_set nf_tables nfnetlink ip6table_filter iptable_filter qrtr bnep 
> > binfmt_misc xfs vfat fat ppdev snd_hda_codec_realtek snd_hda_codec_generic 
> > intel_rapl_msr snd_hda_codec_hdmi ledtrig_audio snd_hda_intel 
> > intel_rapl_common snd_intel_dspcfg edac_mce_amd snd_intel_sdw_acpi 
> > snd_usb_audio snd_hda_codec uvcvideo kvm_amd btusb snd_usbmidi_lib 
> > snd_hda_core btrtl snd_ump btbcm snd_rawmidi btintel snd_hwdep uvc btmtk 
> > kvm videobuf2_vmalloc videobuf2_memops bluetooth snd_seq
> > [ 4655.947889]  snd_seq_device irqbypass videobuf2_v4l2 rapl xpad 
> > videobuf2_common snd_pcm ff_memless wmi_bmof mxm_wmi pcspkr acpi_cpufreq 
> > videodev k10temp rfkill i2c_piix4 snd_timer snd mc soundcore parport_pc 
> > parport gpio_amdpt gpio_generic joydev nfsd auth_rpcgss nfs_acl lockd grace 
> > sunrpc loop zram amdgpu i2c_algo_bit drm_ttm_helper ttm video 
> > drm_suballoc_helper uas amdxcp iommu_v2 crct10dif_pclmul crc32_pclmul 
> > drm_buddy crc32c_intel gpu_sched polyval_clmulni usb_storage r8169 
> > polyval_generic drm_display_helper nvme ghash_clmulni_intel nvme_core ccp 
> > sha512_ssse3 cec sp5100_tco nvme_common wmi scsi_dh_rdac scsi_dh_emc 
> > scsi_dh_alua ip6_tables ip_tables dm_multipath fuse
> > [ 4655.948051] CPU: 12 PID: 3979 Comm: KMS thread Kdump: loaded Not tainted 
> > 6.5.11-300.fc39.x86_64 #1
> > [ 4655.948058] Hardware name: Micro-Star International Co., Ltd. 
> > MS-7A33/X370 SLI PLUS (MS-7A33), BIOS 3.JR 11/29/2019
> > [ 4655.948062] RIP: 0010:link_set_dpms_on+0xbe5/0xca0 [amdgpu]
> > [ 4655.949058] Code: e9 3f fc ff ff 48 c7 c7 98 c7 20 c1 e8 d4 33 e8 e4 e9 
> > c0 fe ff ff 48 8b bb d0 01 00 00 48 89 de e8 40 d0 ed ff e9 25 ff ff ff 
> > <0f> 0b e9 88 fd ff ff 41 c6 85 50 04 00 00 00 e9 d1 f8 ff ff 49 8b
> > [ 4655.949064] RSP: 0018:be344ac2b430 EFLAGS: 00010246
> > [ 4655.949071] RAX:  RBX: 953f0bfab000 RCX: 
> > 0005
> > [ 4655.949076] RDX: c120c6a8 RSI: 0002 RDI: 
> > 
> > [ 4655.949080] RBP: 953f0bfab000 R08:  R09: 
> > 0005
> > [ 4655.949084] R10: 953ece152800 R11: 953ed0eb9960 R12: 
> > 95401e4c0b38
> > [ 4655.949088] R13: 0006 R14: 953ed99c R15: 
> > 95401e4c0df0
> > [ 4655.949093] FS:  7fba5b8856c0() GS:954d9ed0() 
> > knlGS:
> > [ 4655.949099] CS:  0010 DS:  ES:  CR0: 80050033
> > [ 4655.949104] CR2: 1eca52061810 CR3: 0001ad4ac000 CR4: 
> > 003506e0
> > [ 4655.949109] Call Trace:
> > [ 4655.949114]  
> > [ 4655.949118]  ? 

[Bug 218168] amdgpu: kfd_topology.c warning: the frame size of 1408 bytes is larger than 1024 bytes

[bugzilla-daemon]

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

--- Comment #5 from Felix Kuehling (felix.kuehl...@amd.com) ---
There are two patches that didn't make it into Linux 6.6 that reduce the 
stack size in kfd_topology_add_device. Can you check if those fix the 
problem?

commit aa5a9b2ccda2fa834fddb4bd30a2ab831598f551
Author: Alex Deucher 
Date:   Tue Sep 26 12:00:23 2023 -0400

 drm/amdkfd: drop struct kfd_cu_info

 I think this was an abstraction back from when
 kfd supported both radeon and amdgpu.  Since we just
 support amdgpu now, there is no more need for this and
 we can use the amdgpu structures directly.

 This also avoids having the kfd_cu_info structures on
 the stack when inlining which can blow up the stack.

 Cc: Arnd Bergmann 
 Acked-by: Arnd Bergmann 
 Reviewed-by: Felix Kuehling 
 Acked-by: Christian König 
 Signed-off-by: Alex Deucher 

commit 1f3b515578a1d73926993629a06a7f3b60535b59
Author: Alex Deucher 
Date:   Thu Sep 21 10:32:09 2023 -0400

 drm/amdkfd: reduce stack size in kfd_topology_add_device()

 kfd_topology.c:2082:1: warning: the frame size of 1440 bytes is larger
than 1024 bytes

 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2866
 Cc: Arnd Bergmann 
 Acked-by: Arnd Bergmann 
 Acked-by: Christian König 
 Reviewed-by: Felix Kuehling 
 Signed-off-by: Alex Deucher 

Regards,
   Felix


On 2023-11-20 10:36, Hamza Mahfooz wrote:
> + amd-gfx
> + Felix
>
> On 11/20/23 10:16, bugzilla-dae...@kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=218168
>>
>>  Bug ID: 218168
>>     Summary: amdgpu: kfd_topology.c warning: the frame size 
>> of 1408
>>  bytes is larger than 1024 bytes
>>     Product: Drivers
>>     Version: 2.5
>>    Hardware: All
>>  OS: Linux
>>  Status: NEW
>>    Severity: normal
>>    Priority: P3
>>   Component: Video(DRI - non Intel)
>>    Assignee: drivers_video-...@kernel-bugs.osdl.org
>>    Reporter: bluesun...@gmail.com
>>  Regression: No
>>
>> Trying to compile Linux 6.6.2 with GCC 13.2.1 and CONFIG_WERROR=y:
>>
>> [...]
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: In function
>> 'kfd_topology_add_device':
>> drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:2082:1: error: 
>> the frame
>> size of 1408 bytes is larger than 1024 bytes 
>> [-Werror=frame-larger-than=]
>>   2082 | }
>>    | ^
>> cc1: all warnings being treated as errors
>> [...]
>>

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

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

Re: [Bug 218168] New: amdgpu: kfd_topology.c warning: the frame size of 1408 bytes is larger than 1024 bytes

[Felix Kuehling]

There are two patches that didn't make it into Linux 6.6 that reduce the 
stack size in kfd_topology_add_device. Can you check if those fix the 
problem?


commit aa5a9b2ccda2fa834fddb4bd30a2ab831598f551
Author: Alex Deucher 
Date:   Tue Sep 26 12:00:23 2023 -0400

drm/amdkfd: drop struct kfd_cu_info

I think this was an abstraction back from when

kfd supported both radeon and amdgpu.  Since we just
support amdgpu now, there is no more need for this and
we can use the amdgpu structures directly.

This also avoids having the kfd_cu_info structures on

the stack when inlining which can blow up the stack.

Cc: Arnd Bergmann 

Acked-by: Arnd Bergmann 
Reviewed-by: Felix Kuehling 
Acked-by: Christian König 
Signed-off-by: Alex Deucher 

commit 1f3b515578a1d73926993629a06a7f3b60535b59
Author: Alex Deucher 
Date:   Thu Sep 21 10:32:09 2023 -0400

drm/amdkfd: reduce stack size in kfd_topology_add_device()

kfd_topology.c:2082:1: warning: the frame size of 1440 bytes is larger than 1024 bytes

Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2866

Cc: Arnd Bergmann 
Acked-by: Arnd Bergmann 
Acked-by: Christian König 
Reviewed-by: Felix Kuehling 
Signed-off-by: Alex Deucher 

Regards,
  Felix


On 2023-11-20 10:36, Hamza Mahfooz wrote:

+ amd-gfx
+ Felix

On 11/20/23 10:16, bugzilla-dae...@kernel.org wrote:

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

 Bug ID: 218168
    Summary: amdgpu: kfd_topology.c warning: the frame size 
of 1408

 bytes is larger than 1024 bytes
    Product: Drivers
    Version: 2.5
   Hardware: All
 OS: Linux
 Status: NEW
   Severity: normal
   Priority: P3
  Component: Video(DRI - non Intel)
   Assignee: drivers_video-...@kernel-bugs.osdl.org
   Reporter: bluesun...@gmail.com
 Regression: No

Trying to compile Linux 6.6.2 with GCC 13.2.1 and CONFIG_WERROR=y:

[...]
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c: In function
'kfd_topology_add_device':
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:2082:1: error: 
the frame
size of 1408 bytes is larger than 1024 bytes 
[-Werror=frame-larger-than=]

  2082 | }
   | ^
cc1: all warnings being treated as errors
[...]

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Krzysztof Kozlowski]

On 21/11/2023 17:11, AngeloGioacchino Del Regno wrote:
> Il 21/11/23 16:34, Krzysztof Kozlowski ha scritto:
>> On 08/11/2023 14:20, Steven Price wrote:
>>> On 02/11/2023 14:15, AngeloGioacchino Del Regno wrote:
 The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request
 powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones:
 this means that in order to request poweroff of cores, we are supposed
 to write a bitmask of cores that should be powered off!
 This means that the panfrost_gpu_power_off() function has always been
 doing nothing.

 Fix powering off the GPU by writing a bitmask of the cores to poweroff
 to the relevant PWROFF_LO registers and then check that the transition
 (from ON to OFF) has finished by polling the relevant PWRTRANS_LO
 registers.

 While at it, in order to avoid code duplication, move the core mask
 logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask()
 function, used in both poweron and poweroff.

 Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
 Signed-off-by: AngeloGioacchino Del Regno 
 
>>
>>
>> Hi,
>>
>> This commit was added to next recently but it causes "external abort on
>> non-linefetch" during boot of my Odroid HC1 board.
>>
>> At least bisect points to it.
>>
>> If fixed, please add:
>>
>> Reported-by: Krzysztof Kozlowski 
>>
>> [4.861683] 8<--- cut here ---
>> [4.863429] Unhandled fault: external abort on non-linefetch (0x1008) at 
>> 0xf0c8802c
>> [4.871018] [f0c8802c] *pgd=433ed811, *pte=11800653, *ppte=11800453
>> ...
>> [5.164010]  panfrost_gpu_irq_handler from 
>> __handle_irq_event_percpu+0xcc/0x31c
>> [5.171276]  __handle_irq_event_percpu from handle_irq_event+0x38/0x80
>> [5.177765]  handle_irq_event from handle_fasteoi_irq+0x9c/0x250
>> [5.183743]  handle_fasteoi_irq from generic_handle_domain_irq+0x28/0x38
>> [5.190417]  generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
>> [5.196741]  gic_handle_irq from generic_handle_arch_irq+0x34/0x44
>> [5.202893]  generic_handle_arch_irq from __irq_svc+0x8c/0xd0
>>
>> Full log:
>> https://krzk.eu/#/builders/21/builds/4392/steps/11/logs/serial0
>>
> 
> Hey Krzysztof,
> 
> This is interesting. It might be about the cores that are missing from the 
> partial
> core_mask raising interrupts, but an external abort on non-linefetch is 
> strange to
> see here.
> 
> Would you be available for some tests?
> 
> I'm thinking to call power_off on all cores (all shaders, all tilers, all 
> l2s),
> regardless of what panfrost_get_core_mask() says, as it could be that your GPU
> powers on the cores that are unused by Panfrost by default, and that then we 
> never
> turn them off, escalating to this issue.
> 
> If you can please please please test:
> 
> void panfrost_gpu_power_off(struct panfrost_device *pfdev)
> {
>   u64 core_mask = panfrost_get_core_mask(pfdev);
>   int ret;
>   u32 val;
> 
>   gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present);
>   gpu_write(pfdev, SHADER_PWROFF_HI, pfdev->features.shader_present >> 
> 32);
>   ret = readl_relaxed_poll_timeout(pfdev->iomem + SHADER_PWRTRANS_LO,
>val, !val, 1, 1000);
>   if (ret)
>   dev_err(pfdev->dev, "shader power transition timeout");
> 
>   gpu_write(pfdev, TILER_PWROFF_LO, pfdev->features.tiler_present);
>   gpu_write(pfdev, TILER_PWROFF_HI, pfdev->features.tiler_present >> 32);
>   ret = readl_relaxed_poll_timeout(pfdev->iomem + TILER_PWRTRANS_LO,
>val, !val, 1, 1000);
>   if (ret)
>   dev_err(pfdev->dev, "tiler power transition timeout");
> 
>   gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present);
>   ret = readl_poll_timeout(pfdev->iomem + L2_PWRTRANS_LO,
>val, !val, 0, 1000);
>   if (ret)
>   dev_err(pfdev->dev, "l2 power transition timeout");
> 
>   gpu_write(pfdev, L2_PWROFF_HI, pfdev->features.l2_present >> 32);
>   ret = readl_poll_timeout(pfdev->iomem + L2_PWRTRANS_HI,
>val, !val, 0, 1000);
>   if (ret)
>   dev_err(pfdev->dev, "l2 power transition timeout");
> }
> 

Send a diff please - against next or some other commit sha from next.

Best regards,
Krzysztof

[PATCH] drm/msm/a690: Fix reg values for a690

[Rob Clark]

From: Danylo Piliaiev 

KGSL doesn't support a690 so all reg values were the same as
on a660. Now we know the values and they are different from the
windows driver.

This fixes hangs on D3D12 games and some CTS tests.

Signed-off-by: Danylo Piliaiev 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 8176ea8da7a7..75e1ea0404d3 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1326,6 +1326,7 @@ static void a6xx_set_ubwc_config(struct msm_gpu *gpu)
amsbc = 1;
rgb565_predicator = 1;
uavflagprd_inv = 2;
+   ubwc_mode = 2;
}
 
if (adreno_is_7c3(adreno_gpu)) {
@@ -1741,7 +1742,9 @@ static int hw_init(struct msm_gpu *gpu)
/* Setting the primFifo thresholds default values,
 * and vccCacheSkipDis=1 bit (0x200) for A640 and newer
*/
-   if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu) || 
adreno_is_a690(adreno_gpu))
+   if (adreno_is_a690(adreno_gpu))
+   gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00800200);
+   else if (adreno_is_a650(adreno_gpu) || adreno_is_a660(adreno_gpu))
gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00300200);
else if (adreno_is_a640_family(adreno_gpu) || adreno_is_7c3(adreno_gpu))
gpu_write(gpu, REG_A6XX_PC_DBG_ECO_CNTL, 0x00200200);
@@ -1775,6 +1778,8 @@ static int hw_init(struct msm_gpu *gpu)
if (adreno_is_a730(adreno_gpu) ||
adreno_is_a740_family(adreno_gpu))
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) 
| 0xcf);
+   else if (adreno_is_a690(adreno_gpu))
+   gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) 
| 0x4f);
else if (adreno_is_a619(adreno_gpu))
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) 
| 0x3f);
else if (adreno_is_a610(adreno_gpu))
@@ -1782,7 +1787,10 @@ static int hw_init(struct msm_gpu *gpu)
else
gpu_write(gpu, REG_A6XX_RBBM_INTERFACE_HANG_INT_CNTL, (1 << 30) 
| 0x1f);
 
-   gpu_write(gpu, REG_A6XX_UCHE_CLIENT_PF, 1);
+   if (adreno_is_a690(adreno_gpu))
+   gpu_write(gpu, REG_A6XX_UCHE_CLIENT_PF, 0x81);
+   else
+   gpu_write(gpu, REG_A6XX_UCHE_CLIENT_PF, 1);
 
/* Set weights for bicubic filtering */
if (adreno_is_a650_family(adreno_gpu)) {
@@ -1808,12 +1816,17 @@ static int hw_init(struct msm_gpu *gpu)
a6xx_set_cp_protect(gpu);
 
if (adreno_is_a660_family(adreno_gpu)) {
-   gpu_write(gpu, REG_A6XX_CP_CHICKEN_DBG, 0x1);
+   if (adreno_is_a690(adreno_gpu))
+   gpu_write(gpu, REG_A6XX_CP_CHICKEN_DBG, 0x00028801);
+   else
+   gpu_write(gpu, REG_A6XX_CP_CHICKEN_DBG, 0x1);
gpu_write(gpu, REG_A6XX_RBBM_GBIF_CLIENT_QOS_CNTL, 0x0);
}
 
+   if (adreno_is_a690(adreno_gpu))
+   gpu_write(gpu, REG_A6XX_UCHE_CMDQ_CONFIG, 0x90);
/* Set dualQ + disable afull for A660 GPU */
-   if (adreno_is_a660(adreno_gpu))
+   else if (adreno_is_a660(adreno_gpu))
gpu_write(gpu, REG_A6XX_UCHE_CMDQ_CONFIG, 0x66906);
else if (adreno_is_a7xx(adreno_gpu))
gpu_write(gpu, REG_A6XX_UCHE_CMDQ_CONFIG,
-- 
2.42.0

Re: [PATCH v3 101/108] drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function

[Doug Anderson]

Hi,

On Tue, Nov 21, 2023 at 8:05 AM Uwe Kleine-König
 wrote:
>
> Hello Doug,
>
> On Tue, Nov 21, 2023 at 07:15:51AM -0800, Doug Anderson wrote:
> > > @@ -1585,22 +1586,28 @@ static const struct pwm_ops ti_sn_pwm_ops = {
> > >  static int ti_sn_pwm_probe(struct auxiliary_device *adev,
> > >const struct auxiliary_device_id *id)
> > >  {
> > > +   struct pwm_chip *chip;
> > > struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
> > >
> > > -   pdata->pchip.dev = pdata->dev;
> > > -   pdata->pchip.ops = _sn_pwm_ops;
> > > -   pdata->pchip.npwm = 1;
> > > -   pdata->pchip.of_xlate = of_pwm_single_xlate;
> > > -   pdata->pchip.of_pwm_n_cells = 1;
> > > +   /* XXX: should this better use adev->dev instead of pdata->dev? */
> > > +   pdata->pchip = chip = devm_pwmchip_alloc(pdata->dev, 1, 
> > > sizeof());
> >
> > Yes, it should be "adev->dev". See recent commits like commit
> > 7b821db95140 ("drm/bridge: ti-sn65dsi86: Associate DSI device lifetime
> > with auxiliary device").
>
> I'd do that in a separate commit and not change that hidden in patch
> like this one. Agree? Then I'd keep that as is and not address this in
> this series. Maybe it will take another cycle until this patch goes in
> anyhow ...

You could do it in a commit _before_ this one, but not a commit after
this one. Specifically before "${SUBJECT}" commit I think it was
benign to set pdata->pchip.dev to pdata->dev. Now you're starting to
use it for devm and the incorrect lifetime is worse, I think. Do you
agree?

NOTE: I don't actually have any hardware that uses the PWM here, so
you probably want to CC someone like Bjorn (who wrote the PWM code
here) so that he can test it and make sure it didn't break anything.


> > I also think the size you're passing is technically wrong. The private
> > data you're storing is a pointer to a "struct ti_sn65dsi86". The size
> > of that is "sizeof(pdata)", not "sizeof()".
>
> sizeof(*pdata)?

No, that's also wrong. You're not storing a copy of the "struct
ti_sn65dsi86", you're storing a pointer to "struct ti_sn65dsi86".
That's "sizeof(pdata)".

Essentially I'm thinking of it like this. If you were storing 1 byte
of data then you'd pass 1 here. Then allocate and write you'd do:

u8 my_byte;
chip = devm_pwmchip_alloc(dev, 1, sizeof(my_byte));
*(u8 *)pwmchip_priv(chip) = my_byte;

Here you're storing a pointer instead of a byte, but the idea is the same.

void *my_ptr;
chip = devm_pwmchip_alloc(dev, 1, sizeof(my_ptr));
*(void **)pwmchip_priv(chip) = my_ptr;

-Doug

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[AngeloGioacchino Del Regno]

Il 21/11/23 16:34, Krzysztof Kozlowski ha scritto:

On 08/11/2023 14:20, Steven Price wrote:

On 02/11/2023 14:15, AngeloGioacchino Del Regno wrote:

The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request
powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones:
this means that in order to request poweroff of cores, we are supposed
to write a bitmask of cores that should be powered off!
This means that the panfrost_gpu_power_off() function has always been
doing nothing.

Fix powering off the GPU by writing a bitmask of the cores to poweroff
to the relevant PWROFF_LO registers and then check that the transition
(from ON to OFF) has finished by polling the relevant PWRTRANS_LO
registers.

While at it, in order to avoid code duplication, move the core mask
logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask()
function, used in both poweron and poweroff.

Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
Signed-off-by: AngeloGioacchino Del Regno 




Hi,

This commit was added to next recently but it causes "external abort on
non-linefetch" during boot of my Odroid HC1 board.

At least bisect points to it.

If fixed, please add:

Reported-by: Krzysztof Kozlowski 

[4.861683] 8<--- cut here ---
[4.863429] Unhandled fault: external abort on non-linefetch (0x1008) at 
0xf0c8802c
[4.871018] [f0c8802c] *pgd=433ed811, *pte=11800653, *ppte=11800453
...
[5.164010]  panfrost_gpu_irq_handler from 
__handle_irq_event_percpu+0xcc/0x31c
[5.171276]  __handle_irq_event_percpu from handle_irq_event+0x38/0x80
[5.177765]  handle_irq_event from handle_fasteoi_irq+0x9c/0x250
[5.183743]  handle_fasteoi_irq from generic_handle_domain_irq+0x28/0x38
[5.190417]  generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
[5.196741]  gic_handle_irq from generic_handle_arch_irq+0x34/0x44
[5.202893]  generic_handle_arch_irq from __irq_svc+0x8c/0xd0

Full log:
https://krzk.eu/#/builders/21/builds/4392/steps/11/logs/serial0



Hey Krzysztof,

This is interesting. It might be about the cores that are missing from the 
partial
core_mask raising interrupts, but an external abort on non-linefetch is strange 
to
see here.

Would you be available for some tests?

I'm thinking to call power_off on all cores (all shaders, all tilers, all l2s),
regardless of what panfrost_get_core_mask() says, as it could be that your GPU
powers on the cores that are unused by Panfrost by default, and that then we 
never
turn them off, escalating to this issue.

If you can please please please test:

void panfrost_gpu_power_off(struct panfrost_device *pfdev)
{
u64 core_mask = panfrost_get_core_mask(pfdev);
int ret;
u32 val;

gpu_write(pfdev, SHADER_PWROFF_LO, pfdev->features.shader_present);
gpu_write(pfdev, SHADER_PWROFF_HI, pfdev->features.shader_present >> 
32);
ret = readl_relaxed_poll_timeout(pfdev->iomem + SHADER_PWRTRANS_LO,
 val, !val, 1, 1000);
if (ret)
dev_err(pfdev->dev, "shader power transition timeout");

gpu_write(pfdev, TILER_PWROFF_LO, pfdev->features.tiler_present);
gpu_write(pfdev, TILER_PWROFF_HI, pfdev->features.tiler_present >> 32);
ret = readl_relaxed_poll_timeout(pfdev->iomem + TILER_PWRTRANS_LO,
 val, !val, 1, 1000);
if (ret)
dev_err(pfdev->dev, "tiler power transition timeout");

gpu_write(pfdev, L2_PWROFF_LO, pfdev->features.l2_present);
ret = readl_poll_timeout(pfdev->iomem + L2_PWRTRANS_LO,
 val, !val, 0, 1000);
if (ret)
dev_err(pfdev->dev, "l2 power transition timeout");

gpu_write(pfdev, L2_PWROFF_HI, pfdev->features.l2_present >> 32);
ret = readl_poll_timeout(pfdev->iomem + L2_PWRTRANS_HI,
 val, !val, 0, 1000);
if (ret)
dev_err(pfdev->dev, "l2 power transition timeout");
}


This is a quick hack that might work. If this does actually work, the real fix
will be to PWROFF the extra cores only once, at panfrost_gpu_init() time, before
calling panfrost_gpu_power_on(), and to leave them disabled forever (until 
Panfrost
actually gets to support those extra cores for real).

Thanks,
Angelo


1. exynos_defconfig
2. HW: Odroid HC1
ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC
arm,mali-t628

Bisect log:


git bisect start
# bad: [07b677953b9dca02928be323e2db853511305fa9] Add linux-next specific files 
for 20231121
git bisect bad 07b677953b9dca02928be323e2db853511305fa9
# good: [98b1cc82c4affc16f5598d4fa14b1858671b2263] Linux 6.7-rc2
git bisect good 98b1cc82c4affc16f5598d4fa14b1858671b2263
# good: [13e2401d5bdc7f5a30f2651c9

Re: [PATCH v3 101/108] drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function

[Uwe Kleine-König]

Hello Doug,

On Tue, Nov 21, 2023 at 07:15:51AM -0800, Doug Anderson wrote:
> > @@ -1585,22 +1586,28 @@ static const struct pwm_ops ti_sn_pwm_ops = {
> >  static int ti_sn_pwm_probe(struct auxiliary_device *adev,
> >const struct auxiliary_device_id *id)
> >  {
> > +   struct pwm_chip *chip;
> > struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
> >
> > -   pdata->pchip.dev = pdata->dev;
> > -   pdata->pchip.ops = _sn_pwm_ops;
> > -   pdata->pchip.npwm = 1;
> > -   pdata->pchip.of_xlate = of_pwm_single_xlate;
> > -   pdata->pchip.of_pwm_n_cells = 1;
> > +   /* XXX: should this better use adev->dev instead of pdata->dev? */
> > +   pdata->pchip = chip = devm_pwmchip_alloc(pdata->dev, 1, 
> > sizeof());
> 
> Yes, it should be "adev->dev". See recent commits like commit
> 7b821db95140 ("drm/bridge: ti-sn65dsi86: Associate DSI device lifetime
> with auxiliary device").

I'd do that in a separate commit and not change that hidden in patch
like this one. Agree? Then I'd keep that as is and not address this in
this series. Maybe it will take another cycle until this patch goes in
anyhow ...

> I also think the size you're passing is technically wrong. The private
> data you're storing is a pointer to a "struct ti_sn65dsi86". The size
> of that is "sizeof(pdata)", not "sizeof()".

sizeof(*pdata)?

> Other than the above, this looks OK to me. Once the dependencies are
> in I'd be happy to apply this to drm-misc. I could also "Ack" it for
> landing in other trees and I _think_ that would be OK (the driver
> isn't changing much and it's unlikely to cause conflicts), though
> technically the Ack would be more legit from one of the drm-misc
> maintainers [1].
> 
> [1] 
> https://drm.pages.freedesktop.org/maintainer-tools/repositories.html?highlight=maxime#the-drm-misc-repository

*nod*

Best regards
Uwe

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


signature.asc
Description: PGP signature

Re: [PATCH v7 6/8] drm/ttm/tests: Test simple BO creation and validation

[Christian König]

Am 17.11.23 um 09:49 schrieb Karolina Stolarek:

Add tests for ttm_bo_init_reserved() and ttm_bo_validate() that use
sys manager. Define a simple move function in ttm_device_funcs. Expose
destroy callback of the buffer object to make testing of
ttm_bo_init_reserved() behaviour easier.

Signed-off-by: Karolina Stolarek 


Quite a bit hacky, but I think you got that correct.

Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/tests/Makefile|   1 +
  .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 211 ++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  14 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   1 +
  4 files changed, 226 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index 468535f7eed2..2e5ed63fb414 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
  ttm_resource_test.o \
  ttm_tt_test.o \
  ttm_bo_test.o \
+ttm_bo_validate_test.o \
  ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
new file mode 100644
index ..1d50e4ba9775
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
@@ -0,0 +1,211 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define BO_SIZESZ_4K
+
+struct ttm_bo_validate_test_case {
+   const char *description;
+   enum ttm_bo_type bo_type;
+   bool with_ttm;
+};
+
+static struct ttm_placement *ttm_placement_kunit_init(struct kunit *test,
+ struct ttm_place *places,
+ unsigned int num_places,
+ struct ttm_place 
*busy_places,
+ unsigned int 
num_busy_places)
+{
+   struct ttm_placement *placement;
+
+   placement = kunit_kzalloc(test, sizeof(*placement), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, placement);
+
+   placement->num_placement = num_places;
+   placement->placement = places;
+   placement->num_busy_placement = num_busy_places;
+   placement->busy_placement = busy_places;
+
+   return placement;
+}
+
+static void ttm_bo_validate_case_desc(const struct ttm_bo_validate_test_case 
*t,
+ char *desc)
+{
+   strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+static const struct ttm_bo_validate_test_case ttm_bo_type_cases[] = {
+   {
+   .description = "Buffer object for userspace",
+   .bo_type = ttm_bo_type_device,
+   },
+   {
+   .description = "Kernel buffer object",
+   .bo_type = ttm_bo_type_kernel,
+   },
+   {
+   .description = "Shared buffer object",
+   .bo_type = ttm_bo_type_sg,
+   },
+};
+
+KUNIT_ARRAY_PARAM(ttm_bo_types, ttm_bo_type_cases,
+ ttm_bo_validate_case_desc);
+
+static void ttm_bo_init_reserved_sys_man(struct kunit *test)
+{
+   const struct ttm_bo_validate_test_case *params = test->param_value;
+   struct ttm_test_devices *priv = test->priv;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+   struct ttm_placement *placement;
+   enum ttm_bo_type bo_type = params->bo_type;
+   struct ttm_operation_ctx ctx = { };
+   uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
+   int err;
+
+   bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bo);
+
+   place = ttm_place_kunit_init(test, TTM_PL_SYSTEM, 0);
+   placement = ttm_placement_kunit_init(test, place, 1, NULL, 0);
+
+   drm_gem_private_object_init(priv->drm, >base, size);
+
+   err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type, placement,
+  PAGE_SIZE, , NULL, NULL,
+  _ttm_bo_destroy);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_EXPECT_EQ(test, err, 0);
+   KUNIT_EXPECT_EQ(test, kref_read(>kref), 1);
+   KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
+   KUNIT_EXPECT_EQ(test, bo->type, bo_type);
+   KUNIT_EXPECT_EQ(test, bo->page_alignment, PAGE_SIZE);
+   KUNIT_EXPECT_PTR_EQ(test, bo->destroy, _ttm_bo_destroy);
+   KUNIT_EXPECT_EQ(test, bo->pin_count, 0);
+   KUNIT_EXPECT_NULL(test, bo->bulk_move);
+   KUNIT_EXPECT_NOT_NULL(test, bo->ttm);
+   KUNIT_EXPECT_FALSE(test, ttm_tt_is_populated(bo->ttm));
+   KUNIT_EXPECT_NOT_NULL(test, (void *)bo->base.resv->fences);
+   KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
+
+   

Re: [PATCH] drm/panfrost: Really power off GPU cores in panfrost_gpu_power_off()

[Krzysztof Kozlowski]

On 08/11/2023 14:20, Steven Price wrote:
> On 02/11/2023 14:15, AngeloGioacchino Del Regno wrote:
>> The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request
>> powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones:
>> this means that in order to request poweroff of cores, we are supposed
>> to write a bitmask of cores that should be powered off!
>> This means that the panfrost_gpu_power_off() function has always been
>> doing nothing.
>>
>> Fix powering off the GPU by writing a bitmask of the cores to poweroff
>> to the relevant PWROFF_LO registers and then check that the transition
>> (from ON to OFF) has finished by polling the relevant PWRTRANS_LO
>> registers.
>>
>> While at it, in order to avoid code duplication, move the core mask
>> logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask()
>> function, used in both poweron and poweroff.
>>
>> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
>> Signed-off-by: AngeloGioacchino Del Regno 
>> 


Hi,

This commit was added to next recently but it causes "external abort on
non-linefetch" during boot of my Odroid HC1 board.

At least bisect points to it.

If fixed, please add:

Reported-by: Krzysztof Kozlowski 

[4.861683] 8<--- cut here ---
[4.863429] Unhandled fault: external abort on non-linefetch (0x1008) at 
0xf0c8802c
[4.871018] [f0c8802c] *pgd=433ed811, *pte=11800653, *ppte=11800453
...
[5.164010]  panfrost_gpu_irq_handler from 
__handle_irq_event_percpu+0xcc/0x31c
[5.171276]  __handle_irq_event_percpu from handle_irq_event+0x38/0x80
[5.177765]  handle_irq_event from handle_fasteoi_irq+0x9c/0x250
[5.183743]  handle_fasteoi_irq from generic_handle_domain_irq+0x28/0x38
[5.190417]  generic_handle_domain_irq from gic_handle_irq+0x88/0xa8
[5.196741]  gic_handle_irq from generic_handle_arch_irq+0x34/0x44
[5.202893]  generic_handle_arch_irq from __irq_svc+0x8c/0xd0

Full log:
https://krzk.eu/#/builders/21/builds/4392/steps/11/logs/serial0

1. exynos_defconfig
2. HW: Odroid HC1
   ARMv7, octa-core (Cortex-A7+A15), Exynos5422 SoC
   arm,mali-t628
   
Bisect log:

git bisect start
# bad: [07b677953b9dca02928be323e2db853511305fa9] Add linux-next specific files 
for 20231121
git bisect bad 07b677953b9dca02928be323e2db853511305fa9
# good: [98b1cc82c4affc16f5598d4fa14b1858671b2263] Linux 6.7-rc2
git bisect good 98b1cc82c4affc16f5598d4fa14b1858671b2263
# good: [13e2401d5bdc7f5a30f2651c99f0e3374cdda815] Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
git bisect good 13e2401d5bdc7f5a30f2651c99f0e3374cdda815
# bad: [3b586cd6d8e51c428675312e7c3f634eb96337e9] Merge branch 'for-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git
git bisect bad 3b586cd6d8e51c428675312e7c3f634eb96337e9
# bad: [9d63fd5f05248c78d9a66ce5dbc9cf5649054848] Merge branch 'drm-next' of 
https://gitlab.freedesktop.org/agd5f/linux
git bisect bad 9d63fd5f05248c78d9a66ce5dbc9cf5649054848
# bad: [5dea0c3fedee65413271a5700e653eff633e9a7f] drm/panel-elida-kd35t133: 
Drop shutdown logic
git bisect bad 5dea0c3fedee65413271a5700e653eff633e9a7f
# good: [48d45fac3940347becd290b96b2fc6d5ad8171f7] accel/ivpu: Remove support 
for uncached buffers
git bisect good 48d45fac3940347becd290b96b2fc6d5ad8171f7
# bad: [809ef191ee600e8bcbe2f8a769e00d2d54c16094] drm/gpuvm: add 
drm_gpuvm_flags to drm_gpuvm
git bisect bad 809ef191ee600e8bcbe2f8a769e00d2d54c16094
# good: [a78422e9dff366b3a46ae44caf6ec8ded9c9fc2f] drm/sched: implement dynamic 
job-flow control
git bisect good a78422e9dff366b3a46ae44caf6ec8ded9c9fc2f
# bad: [e4178256094a76cc36d9b9aabe7482615959b26f] drm/virtio: use uint64_t more 
in virtio_gpu_context_init_ioctl
git bisect bad e4178256094a76cc36d9b9aabe7482615959b26f
# bad: [56e76c0179185568049913257c18069293f8bde9] drm/panfrost: Implement 
ability to turn on/off GPU clocks in suspend
git bisect bad 56e76c0179185568049913257c18069293f8bde9
# bad: [57d4e26717b030fd794df3534e6b2e806eb761e4] drm/panfrost: Perform hard 
reset to recover GPU if soft reset fails
git bisect bad 57d4e26717b030fd794df3534e6b2e806eb761e4
# bad: [22aa1a209018dc2eca78745f7666db63637cd5dc] drm/panfrost: Really power 
off GPU cores in panfrost_gpu_power_off()
git bisect bad 22aa1a209018dc2eca78745f7666db63637cd5dc
# first bad commit: [22aa1a209018dc2eca78745f7666db63637cd5dc] drm/panfrost: 
Really power off GPU cores in panfrost_gpu_power_off()
  

Best regards,
Krzysztof

Powered off Philips TV sends corrupt EDID causing flickering

[Paul Menzel]

Dear Linux folks,


Connecting a USB Type-C port replicator [1] to the only USB Type-C port 
of the Dell XPS 13 9360 with Debian sid/unstable and Debian’s Linux 
kernel 6.10.5, and then connecting a Philips 40PFL5206H/12 TV device, 
that is powered off or in standby, to the HDMI port, Linux logs:


```
[0.00] Linux version 6.5.0-4-amd64 
(debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-6) 13.2.0, GNU 
ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 
6.5.10-1 (2023-11-03)

[…]
[0.00] DMI: Dell Inc. XPS 13 9360/0596KF, BIOS 2.21.0 06/02/2022
[…]
[  160.004836] EDID has corrupt header
[  160.004866]  [00] BAD  00 00 00 00 00 00 00 00 00 7f ff ff ff ff ff ff
[  160.004875]  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  160.004881]  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  160.004886]  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  160.004905]  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  160.004911]  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  160.004917]  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  160.004921]  [00] BAD  ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  160.013662] Registered IR keymap rc-cec
[  160.014001] rc rc0: DP-1 as /devices/pci:00/:00:02.0/rc/rc0
[  160.014305] input: DP-1 as 
/devices/pci:00/:00:02.0/rc/rc0/input33

[  160.228342] EDID has corrupt header
[  160.408917] EDID has corrupt header
```

The internal display of the laptop also switches off shortly, but comes 
back after two or three seconds. This is very likely due to me 
configuring the internal display to turn off once an external display is 
used.


No idea, why the TV is able to transmit anything at all, when it is 
turned/powered off. To avoid the flickering, would it be possible to 
ignore events from displays sending such incorrect EDID?



Kind regards,

Paul

Re: [REGRESSION]: nouveau: Asynchronous wait on fence

[Linux regression tracking (Thorsten Leemhuis)]

On 15.11.23 07:19, Owen T. Heisler wrote:
> On 10/31/23 04:18, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 28.10.23 04:46, Owen T. Heisler wrote:
>>> #regzbot introduced: d386a4b54607cf6f76e23815c2c9a3abc1d66882
>>> #regzbot link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/180
>>>
>>> ## Problem
>>>
>>> 1. Connect external display to DVI port on dock and run X with both
>>>     displays in use.
>>> 2. Wait hours or days.
>>> 3. Suddenly the secondary Nvidia-connected display turns off and X stops
>>>     responding to keyboard/mouse input. In *some* cases it is
>>> possible to
>>>     switch to a virtual TTY with Ctrl+Alt+Fn and log in there.
> 
>> You thus might want to check if the problem occurs with 6.6 -- and
>> ideally also check if reverting the culprit there fixes things for you.
> 
> The problem also occurs with v6.6.

You meanwhile might want to give 6.7-rc as well on the off chance that
it improves things, even if that is unlikely.

> Here is a decoded kernel log from an
> untainted kernel:
> 
> https://gitlab.freedesktop.org/drm/nouveau/uploads/c120faf09da46f9c74006df9f1d14442/async-wait-on-fence-180.log
> 
> The culprit commit does not revert cleanly on v6.6. I have not yet
> attempted to resolve the conflicts.
> 
> I have also updated the bug description at
> .

Maybe one of the nouveau developer can take a quick look at
d386a4b54607cf and suggest a simple way to revert it in latest mainline.
Maybe just removing the main chunk of code that is added is all that it
takes.

Ciao, Thorsten

Re: [PATCH v3 101/108] drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function

[Doug Anderson]

Hi,

On Tue, Nov 21, 2023 at 5:52 AM Uwe Kleine-König
 wrote:
>
> This prepares the pwm driver of the ti-sn65dsi86 to further changes of
> the pwm core outlined in the commit introducing devm_pwmchip_alloc().
> There is no intended semantical change and the driver should behave as
> before.
>
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi86.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> index c45c07840f64..cd40530ffd71 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
> @@ -197,7 +197,7 @@ struct ti_sn65dsi86 {
> DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
>  #endif
>  #if defined(CONFIG_PWM)
> -   struct pwm_chip pchip;
> +   struct pwm_chip *pchip;
> boolpwm_enabled;
> atomic_tpwm_pin_busy;
>  #endif
> @@ -1372,7 +1372,8 @@ static void ti_sn_pwm_pin_release(struct ti_sn65dsi86 
> *pdata)
>
>  static struct ti_sn65dsi86 *pwm_chip_to_ti_sn_bridge(struct pwm_chip *chip)
>  {
> -   return container_of(chip, struct ti_sn65dsi86, pchip);
> +   struct ti_sn65dsi86 **pdata = pwmchip_priv(chip);
> +   return *pdata;
>  }
>
>  static int ti_sn_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
> @@ -1585,22 +1586,28 @@ static const struct pwm_ops ti_sn_pwm_ops = {
>  static int ti_sn_pwm_probe(struct auxiliary_device *adev,
>const struct auxiliary_device_id *id)
>  {
> +   struct pwm_chip *chip;
> struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
>
> -   pdata->pchip.dev = pdata->dev;
> -   pdata->pchip.ops = _sn_pwm_ops;
> -   pdata->pchip.npwm = 1;
> -   pdata->pchip.of_xlate = of_pwm_single_xlate;
> -   pdata->pchip.of_pwm_n_cells = 1;
> +   /* XXX: should this better use adev->dev instead of pdata->dev? */
> +   pdata->pchip = chip = devm_pwmchip_alloc(pdata->dev, 1, 
> sizeof());

Yes, it should be "adev->dev". See recent commits like commit
7b821db95140 ("drm/bridge: ti-sn65dsi86: Associate DSI device lifetime
with auxiliary device").

I also think the size you're passing is technically wrong. The private
data you're storing is a pointer to a "struct ti_sn65dsi86". The size
of that is "sizeof(pdata)", not "sizeof()".

Other than the above, this looks OK to me. Once the dependencies are
in I'd be happy to apply this to drm-misc. I could also "Ack" it for
landing in other trees and I _think_ that would be OK (the driver
isn't changing much and it's unlikely to cause conflicts), though
technically the Ack would be more legit from one of the drm-misc
maintainers [1].

[1] 
https://drm.pages.freedesktop.org/maintainer-tools/repositories.html?highlight=maxime#the-drm-misc-repository

Re: [PATCH v7 4/8] drm/ttm/tests: Fix argument in ttm_tt_kunit_init()

[Christian König]

Am 17.11.23 um 09:49 schrieb Karolina Stolarek:

Remove a leftover definition of page order and pass an empty flag value
in ttm_pool_pre_populated().

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 


Acked-by: Christian König 


---
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
index 2d9cae8cd984..b97f7b6daf5b 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -78,10 +78,9 @@ static struct ttm_pool *ttm_pool_pre_populated(struct kunit 
*test,
struct ttm_test_devices *devs = priv->devs;
struct ttm_pool *pool;
struct ttm_tt *tt;
-   unsigned long order = __fls(size / PAGE_SIZE);
int err;
  
-	tt = ttm_tt_kunit_init(test, order, caching, size);

+   tt = ttm_tt_kunit_init(test, 0, caching, size);
KUNIT_ASSERT_NOT_NULL(test, tt);
  
  	pool = kunit_kzalloc(test, sizeof(*pool), GFP_KERNEL);

Re: [PATCH v3 1/1] backlight: pwm_bl: Use dev_err_probe

[Daniel Thompson]

On Fri, Nov 17, 2023 at 01:06:25PM +0100, Alexander Stein wrote:
> Use dev_err_probe to simplify error paths. Also let dev_err_probe handle
> the -EPROBE_DEFER case and add an entry to
> /sys/kernel/debug/devices_deferred when deferred.
>
> Signed-off-by: Alexander Stein 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 20/22] usb: fsl-mph-dr-of: mark fsl_usb2_mpc5121_init() static

[Greg Kroah-Hartman]

On Wed, Nov 08, 2023 at 01:58:41PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> This function is only called locally and should always have been static:
> 
> drivers/usb/host/fsl-mph-dr-of.c:291:5: error: no previous prototype for 
> 'fsl_usb2_mpc5121_init' [-Werror=missing-prototypes]
> 
> Fixes: 230f7ede6c2f ("USB: add USB EHCI support for MPC5121 SoC")
> Signed-off-by: Arnd Bergmann 

Acked-by: Greg Kroah-Hartman 

Re: [PATCH v4 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation

[Michael Walle]

Hi,


mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
always have the CRTC with id 0, the ext id 1 and the third id 2. This
is only true if the paths are all available. But paths are optional 
(see

also comment in mtk_drm_kms_init()), e.g. the main path might not be
enabled or available at all. Then the CRTC IDs will shift one up, e.g.
ext will be 0 and the third path will be 1.

To fix that, dynamically calculate the IDs by the presence of the 
paths.


While at it, make the return code a signed one and return -ENOENT if no
path is found and handle the error in the callers.

Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting 
possible_crtc way")

Suggested-by: Nícolas F. R. A. Prado 
Signed-off-by: Michael Walle 
Reviewed-by: Nícolas F. R. A. Prado 
Tested-by: Nícolas F. R. A. Prado 


Is there anything wrong with these two patches? They are now lingering
around for more than two months.

Unfortunately, patch 2/2 won't apply anymore because of commit
01389b324c97 ("drm/mediatek: Add connector dynamic selection
capability). And I'm a bit puzzled for what the crtc_id is used
there because I guess it will have the same problem this patch
fixes.

-michael


---
v4:
 - return -ENOENT if mtk_drm_find_possible_crtc_by_comp() doesn't find
   any path
v3:
 - use data instead of priv_n->data
 - fixed typos
 - collected Rb and Tb tags
v2:
 - iterate over all_drm_private[] to get any vdosys
 - new check if a path is available
---
 drivers/gpu/drm/mediatek/mtk_dpi.c  |  5 +-
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 75 -
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  3 +-
 drivers/gpu/drm/mediatek/mtk_dsi.c  |  5 +-
 4 files changed, 68 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c

index 2f931e4e2b60..f9250f7ee706 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -796,7 +796,10 @@ static int mtk_dpi_bind(struct device *dev, struct 
device *master, void *data)

return ret;
}

-	dpi->encoder.possible_crtcs = 
mtk_drm_find_possible_crtc_by_comp(drm_dev, dpi->dev);

+   ret = mtk_drm_find_possible_crtc_by_comp(drm_dev, dpi->dev);
+   if (ret < 0)
+   goto err_cleanup;
+   dpi->encoder.possible_crtcs = ret;

ret = drm_bridge_attach(>encoder, >bridge, NULL,
DRM_BRIDGE_ATTACH_NO_CONNECTOR);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c

index 771f4e173353..83ae75ecd858 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -507,6 +507,27 @@ static bool mtk_drm_find_comp_in_ddp(struct device 
*dev,

return false;
 }

+static bool mtk_ddp_path_available(const unsigned int *path,
+  unsigned int path_len,
+  struct device_node **comp_node)
+{
+   unsigned int i;
+
+   if (!path)
+   return false;
+
+   for (i = 0U; i < path_len; i++) {
+   /* OVL_ADAPTOR doesn't have a device node */
+   if (path[i] == DDP_COMPONENT_DRM_OVL_ADAPTOR)
+   continue;
+
+   if (!comp_node[path[i]])
+   return false;
+   }
+
+   return true;
+}
+
 int mtk_ddp_comp_get_id(struct device_node *node,
enum mtk_ddp_comp_type comp_type)
 {
@@ -522,25 +543,47 @@ int mtk_ddp_comp_get_id(struct device_node *node,
return -EINVAL;
 }

-unsigned int mtk_drm_find_possible_crtc_by_comp(struct drm_device 
*drm,

-   struct device *dev)
+int mtk_drm_find_possible_crtc_by_comp(struct drm_device *drm, struct 
device *dev)

 {
struct mtk_drm_private *private = drm->dev_private;
-   unsigned int ret = 0;
-
-	if (mtk_drm_find_comp_in_ddp(dev, private->data->main_path, 
private->data->main_len,

-private->ddp_comp))
-   ret = BIT(0);
-   else if (mtk_drm_find_comp_in_ddp(dev, private->data->ext_path,
- private->data->ext_len, 
private->ddp_comp))
-   ret = BIT(1);
-   else if (mtk_drm_find_comp_in_ddp(dev, private->data->third_path,
- private->data->third_len, 
private->ddp_comp))
-   ret = BIT(2);
-   else
-   DRM_INFO("Failed to find comp in ddp table\n");
+   const struct mtk_mmsys_driver_data *data;
+   struct mtk_drm_private *priv_n;
+   int i = 0, j;
+
+   for (j = 0; j < private->data->mmsys_dev_num; j++) {
+   priv_n = private->all_drm_private[j];
+   data = priv_n->data;
+
+   if (mtk_ddp_path_available(data->main_path, data->main_len,
+  

Re: [PATCH v2] drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency

[Guillaume Ranquet]

On Tue, 21 Nov 2023 15:29, "Nícolas F. R. A. Prado"
 wrote:
>The mtk_dp driver registers a phy device which is handled by the
>phy_mtk_dp driver and assumes that the phy probe will complete
>synchronously, proceeding to make use of functionality exposed by that
>driver right away. This assumption however is false when the phy driver
>is built as a module, causing the mtk_dp driver to fail probe in this
>case.
>
>Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to
>ensure the phy module has been loaded before the dp, so that the phy
>probe happens synchrounously and the mtk_dp driver can probe
>successfully even with the phy driver built as a module.
>
>Suggested-by: AngeloGioacchino Del Regno 
>
>Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
>Signed-off-by: Nícolas F. R. A. Prado 
>Reviewed-by: AngeloGioacchino Del Regno 
>
>
>---

Reviewed-by: Guillaume Ranquet 
>
>Changes in v2:
>- Added missing Suggested-by tag
>
> drivers/gpu/drm/mediatek/mtk_dp.c | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
>b/drivers/gpu/drm/mediatek/mtk_dp.c
>index e4c16ba9902d..2136a596efa1 100644
>--- a/drivers/gpu/drm/mediatek/mtk_dp.c
>+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
>@@ -2818,3 +2818,4 @@ MODULE_AUTHOR("Markus Schneider-Pargmann 
>");
> MODULE_AUTHOR("Bo-Chen Chen ");
> MODULE_DESCRIPTION("MediaTek DisplayPort Driver");
> MODULE_LICENSE("GPL");
>+MODULE_SOFTDEP("pre: phy_mtk_dp");
>--
>2.42.1
>

[PATCH v2] drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency

[Nícolas F . R . A . Prado]

The mtk_dp driver registers a phy device which is handled by the
phy_mtk_dp driver and assumes that the phy probe will complete
synchronously, proceeding to make use of functionality exposed by that
driver right away. This assumption however is false when the phy driver
is built as a module, causing the mtk_dp driver to fail probe in this
case.

Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to
ensure the phy module has been loaded before the dp, so that the phy
probe happens synchrounously and the mtk_dp driver can probe
successfully even with the phy driver built as a module.

Suggested-by: AngeloGioacchino Del Regno 

Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Signed-off-by: Nícolas F. R. A. Prado 
Reviewed-by: AngeloGioacchino Del Regno 


---

Changes in v2:
- Added missing Suggested-by tag

 drivers/gpu/drm/mediatek/mtk_dp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index e4c16ba9902d..2136a596efa1 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2818,3 +2818,4 @@ MODULE_AUTHOR("Markus Schneider-Pargmann 
");
 MODULE_AUTHOR("Bo-Chen Chen ");
 MODULE_DESCRIPTION("MediaTek DisplayPort Driver");
 MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: phy_mtk_dp");
-- 
2.42.1

Re: [PATCH v7 3/8] drm/ttm/tests: Add tests for ttm_bo functions

[Christian König]

Am 17.11.23 um 09:49 schrieb Karolina Stolarek:

Test reservation and release of TTM buffer objects. Add tests to check
pin and unpin operations.

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 


From the TTM side it looks good, but I can't judge if the lockdep hack 
in the deadlock test is valid or not.


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

Regards,
Christian.


---
  drivers/gpu/drm/ttm/tests/Makefile|   1 +
  drivers/gpu/drm/ttm/tests/ttm_bo_test.c   | 619 ++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |   6 +
  3 files changed, 626 insertions(+)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_bo_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index f570530bbb60..468535f7eed2 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
  ttm_pool_test.o \
  ttm_resource_test.o \
  ttm_tt_test.o \
+ttm_bo_test.o \
  ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
new file mode 100644
index ..71bca47205ed
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_bo_test.c
@@ -0,0 +1,619 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define BO_SIZESZ_8K
+
+struct ttm_bo_test_case {
+   const char *description;
+   bool interruptible;
+   bool no_wait;
+};
+
+static const struct ttm_bo_test_case ttm_bo_reserved_cases[] = {
+   {
+   .description = "Cannot be interrupted and sleeps",
+   .interruptible = false,
+   .no_wait = false,
+   },
+   {
+   .description = "Cannot be interrupted, locks straight away",
+   .interruptible = false,
+   .no_wait = true,
+   },
+   {
+   .description = "Can be interrupted, sleeps",
+   .interruptible = true,
+   .no_wait = false,
+   },
+};
+
+static void ttm_bo_init_case_desc(const struct ttm_bo_test_case *t,
+ char *desc)
+{
+   strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(ttm_bo_reserve, ttm_bo_reserved_cases, 
ttm_bo_init_case_desc);
+
+static void ttm_bo_reserve_optimistic_no_ticket(struct kunit *test)
+{
+   const struct ttm_bo_test_case *params = test->param_value;
+   struct ttm_buffer_object *bo;
+   int err;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   err = ttm_bo_reserve(bo, params->interruptible, params->no_wait, NULL);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   dma_resv_unlock(bo->base.resv);
+}
+
+static void ttm_bo_reserve_locked_no_sleep(struct kunit *test)
+{
+   struct ttm_buffer_object *bo;
+   bool interruptible = false;
+   bool no_wait = true;
+   int err;
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   /* Let's lock it beforehand */
+   dma_resv_lock(bo->base.resv, NULL);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, NULL);
+   dma_resv_unlock(bo->base.resv);
+
+   KUNIT_ASSERT_EQ(test, err, -EBUSY);
+}
+
+static void ttm_bo_reserve_no_wait_ticket(struct kunit *test)
+{
+   struct ttm_buffer_object *bo;
+   struct ww_acquire_ctx ctx;
+   bool interruptible = false;
+   bool no_wait = true;
+   int err;
+
+   ww_acquire_init(, _ww_class);
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, );
+   KUNIT_ASSERT_EQ(test, err, -EBUSY);
+
+   ww_acquire_fini();
+}
+
+static void ttm_bo_reserve_double_resv(struct kunit *test)
+{
+   struct ttm_buffer_object *bo;
+   struct ww_acquire_ctx ctx;
+   bool interruptible = false;
+   bool no_wait = false;
+   int err;
+
+   ww_acquire_init(, _ww_class);
+
+   bo = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, );
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   err = ttm_bo_reserve(bo, interruptible, no_wait, );
+
+   dma_resv_unlock(bo->base.resv);
+   ww_acquire_fini();
+
+   KUNIT_ASSERT_EQ(test, err, -EALREADY);
+}
+
+/*
+ * A test case heavily inspired by ww_test_edeadlk_normal(). Checks
+ * if -EDEADLK is properly propagated by ttm_bo_reserve()
+ */
+static void ttm_bo_reserve_deadlock(struct kunit *test)
+{
+   struct ttm_buffer_object *bo1, *bo2;
+   struct ww_acquire_ctx ctx1, ctx2;
+   bool interruptible = false;
+   bool no_wait = false;
+   int err;
+
+   bo1 = ttm_bo_kunit_init(test, test->priv, BO_SIZE);
+   bo2 = ttm_bo_kunit_init(test, 

Re: [PATCH 1/2] drm/logicvc: Avoid possible overflow in layer buffer setup variables

[Paul Kocialkowski]

Hi folks,

On Wed 25 Oct 23, 15:09, Paul Kocialkowski wrote:
> The buffer_sel, voffset and hoffset values are calculated from u32
> values and might overflow under certain conditions.
> 
> Move them to u32 definitions instead of u8/u16 to avoid the issue.

Any chance to get a quick review on this simple fixup (and the next one)?
I can certainly push them myself after that.

Thanks,

Paul

> Signed-off-by: Paul Kocialkowski 
> Reported-by: Dan Carpenter 
> Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller")
> ---
>  drivers/gpu/drm/logicvc/logicvc_layer.c | 6 +++---
>  drivers/gpu/drm/logicvc/logicvc_layer.h | 6 +++---
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/logicvc/logicvc_layer.c 
> b/drivers/gpu/drm/logicvc/logicvc_layer.c
> index 464000aea765..eea22379d042 100644
> --- a/drivers/gpu/drm/logicvc/logicvc_layer.c
> +++ b/drivers/gpu/drm/logicvc/logicvc_layer.c
> @@ -268,9 +268,9 @@ int logicvc_layer_buffer_find_setup(struct logicvc_drm 
> *logicvc,
>   u32 layer_stride = layer_bytespp * logicvc->config.row_stride;
>   u32 base_offset = layer->config.base_offset * layer_stride;
>   u32 buffer_offset = layer->config.buffer_offset * layer_stride;
> - u8 buffer_sel = 0;
> - u16 voffset = 0;
> - u16 hoffset = 0;
> + u32 buffer_sel = 0;
> + u32 voffset = 0;
> + u32 hoffset = 0;
>   phys_addr_t fb_addr;
>   u32 fb_offset;
>   u32 gap;
> diff --git a/drivers/gpu/drm/logicvc/logicvc_layer.h 
> b/drivers/gpu/drm/logicvc/logicvc_layer.h
> index 4a4b02e9b819..a06feeda3abf 100644
> --- a/drivers/gpu/drm/logicvc/logicvc_layer.h
> +++ b/drivers/gpu/drm/logicvc/logicvc_layer.h
> @@ -18,9 +18,9 @@
>  #define LOGICVC_LAYER_ALPHA_PIXEL1
>  
>  struct logicvc_layer_buffer_setup {
> - u8 buffer_sel;
> - u16 voffset;
> - u16 hoffset;
> + u32 buffer_sel;
> + u32 voffset;
> + u32 hoffset;
>  };
>  
>  struct logicvc_layer_config {
> -- 
> 2.42.0
> 

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH] drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency

[Nícolas F . R . A . Prado]

On Tue, Nov 21, 2023 at 11:59:14AM +0100, AngeloGioacchino Del Regno wrote:
> Il 20/11/23 21:28, Nícolas F. R. A. Prado ha scritto:
> > The mtk_dp driver registers a phy device which is handled by the
> > phy_mtk_dp driver and assumes that the phy probe will complete
> > synchronously, proceeding to make use of functionality exposed by that
> > driver right away. This assumption however is false when the phy driver
> > is built as a module, causing the mtk_dp driver to fail probe in this
> > case.
> > 
> > Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to
> > ensure the phy module has been loaded before the dp, so that the phy
> > probe happens synchrounously and the mtk_dp driver can probe
> > successfully even with the phy driver built as a module.
> > 
> 
> You forgot a Suggested-by here :-P

Oops, sorry, I forgot that tag existed. Will send a v2 with it added :).

> 
> > Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
> > Signed-off-by: Nícolas F. R. A. Prado 
> 
> It's fine anyway; being the best solution that we can use:
> 
> Reviewed-by: AngeloGioacchino Del Regno 
> 
> 
> > 
> > ---
> > 
> >   drivers/gpu/drm/mediatek/mtk_dp.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
> > b/drivers/gpu/drm/mediatek/mtk_dp.c
> > index e4c16ba9902d..2136a596efa1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_dp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_dp.c
> > @@ -2818,3 +2818,4 @@ MODULE_AUTHOR("Markus Schneider-Pargmann 
> > ");
> >   MODULE_AUTHOR("Bo-Chen Chen ");
> >   MODULE_DESCRIPTION("MediaTek DisplayPort Driver");
> >   MODULE_LICENSE("GPL");
> > +MODULE_SOFTDEP("pre: phy_mtk_dp");
> 

Re: Radeon regression in 6.6 kernel

[Alex Deucher]

On Mon, Nov 20, 2023 at 5:40 PM Phillip Susi  wrote:
>
> Alex Deucher  writes:
>
> > Yes.  Those changes went into 6.7 though, not 6.6 AFAIK.  Maybe I'm
> > misunderstanding what the original report was actually testing.  If it
> > was 6.7, then try reverting:
> > 56e449603f0ac580700621a356d35d5716a62ce5
> > b70438004a14f4d0f9890b3297cd66248728546c
>
> I had been running v6.6-rc5 before pulling.  It looks like that got me
> somewhere between v6.6 and v6.7-rc1.  Reverting those two commits fixes
> it.

Does reverting 56e449603f0ac580700621a356d35d5716a62ce5 alone fix it?
Can you also attach your full dmesg log for the failed suspend?

Alex

Re: [PATCH v5] Documentation/gpu: VM_BIND locking document

[Boris Brezillon]

On Tue, 21 Nov 2023 11:40:46 +0100
Thomas Hellström  wrote:

> Add the first version of the VM_BIND locking document which is
> intended to be part of the xe driver upstreaming agreement.
> 
> The document describes and discuss the locking used during exec-
> functions, evicton and for userptr gpu-vmas. Intention is to be using the
> same nomenclature as the drm-vm-bind-async.rst.
> 
> v2:
> - s/gvm/gpu_vm/g (Rodrigo Vivi)
> - Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c
>   (Rodrigo Vivi)
> - Adjust commit message accordingly.
> - Add SPDX license header.
> 
> v3:
> - Large update to align with the drm_gpuvm manager locking
> - Add "Efficient userptr gpu_vma exec function iteration" section
> - Add "Locking at bind- and unbind time" section.
> 
> v4:
> - Fix tabs vs space errors by untabifying (Rodrigo Vivi)
> - Minor style fixes and typos (Rodrigo Vivi)
> - Clarify situations where stale GPU mappings are occurring and how
>   access through these mappings are blocked. (Rodrigo Vivi)
> - Insert into the toctree in implementation_guidelines.rst
> 
> v5:
> - Add a section about recoverable page-faults.
> - Use local references to other documentation where possible
>   (Bagas Sanjaya)
> - General documentation fixes and typos (Danilo Krummrich and
>   Boris Brezillon)
> - Improve the documentation around locks that need to be grabbed from the
>   dm-fence critical section (Boris Brezillon)
> - Add more references to the DRM GPUVM helpers (Danilo Krummrich and
>   Boriz Brezillon)
> - Update the rfc/xe.rst document.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Thomas Hellström 

Still have a few comments (see below), and in general, I find some
sentences very long, which has the tendency of confusing me (always
trying to figure out what was the main point, what the pronouns are
referring to, etc). Anyway, I think it's better to have something
imperfect than nothing at all, so here is my

Reviewed-by: Boris Brezillon 

Feel free to add it even if you decide to ignore my comments.

> ---
>  Documentation/core-api/pin_user_pages.rst |   2 +
>  Documentation/gpu/drm-mm.rst  |   4 +
>  Documentation/gpu/drm-vm-bind-locking.rst | 579 ++
>  .../gpu/implementation_guidelines.rst |   1 +
>  Documentation/gpu/rfc/xe.rst  |   5 +
>  5 files changed, 591 insertions(+)
>  create mode 100644 Documentation/gpu/drm-vm-bind-locking.rst
> 
> diff --git a/Documentation/core-api/pin_user_pages.rst 
> b/Documentation/core-api/pin_user_pages.rst
> index d3c1f6d8c0e0..6b5f7e6e7155 100644
> --- a/Documentation/core-api/pin_user_pages.rst
> +++ b/Documentation/core-api/pin_user_pages.rst
> @@ -153,6 +153,8 @@ NOTE: Some pages, such as DAX pages, cannot be pinned 
> with longterm pins. That's
>  because DAX pages do not have a separate page cache, and so "pinning" implies
>  locking down file system blocks, which is not (yet) supported in that way.
>  
> +.. _mmu-notifier-registration-case:
> +
>  CASE 3: MMU notifier registration, with or without page faulting hardware
>  -
>  Device drivers can pin pages via get_user_pages*(), and register for mmu
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index acc5901ac840..d55751cad67c 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -466,6 +466,8 @@ DRM MM Range Allocator Function References
>  .. kernel-doc:: drivers/gpu/drm/drm_mm.c
> :export:
>  
> +.. _drm_gpuvm:
> +
>  DRM GPUVM
>  =
>  
> @@ -481,6 +483,8 @@ Split and Merge
>  .. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
> :doc: Split and Merge
>  
> +.. _drm_gpuvm_locking:
> +
>  Locking
>  ---
>  
> diff --git a/Documentation/gpu/drm-vm-bind-locking.rst 
> b/Documentation/gpu/drm-vm-bind-locking.rst
> new file mode 100644
> index ..a7d08eccd50e
> --- /dev/null
> +++ b/Documentation/gpu/drm-vm-bind-locking.rst
> @@ -0,0 +1,579 @@
> +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +===
> +VM_BIND locking
> +===
> +
> +This document attempts to describe what's needed to get VM_BIND locking 
> right,
> +including the userptr mmu_notifier locking and it also discusses some

Could we split this long sentence like this?

   including the userptr mmu_notifier locking. It also discusses ...

> +optimizations to get rid of the looping through of all userptr mappings and
> +external / shared object mappings that is needed in the simplest
> +implementation. In addition there is a section describing the VM_BIND locking
> +required for implementing recoverable pagefaults.
> +
> +The DRM GPUVM set of helpers
> +
> +
> +There is a set of helpers for drivers implementing VM_BIND, and this

Nit: I'm not sure drm_gpuvm qualifies as a set of helpers, it's more an
abstraction layer for GPU VM manipulation that's meant to automate some
of the logic drivers 

Re: [PATCH v2 01/11] drm/dp_mst: Store the MST PBN divider value in fixed point format

[Imre Deak]

On Thu, Nov 16, 2023 at 03:18:31PM +0200, Imre Deak wrote:
[...]
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index ed784cf27d396..63024393b516e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -31,6 +31,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "dm_services.h"
>  #include "amdgpu.h"
> @@ -210,7 +211,7 @@ static void dm_helpers_construct_old_payload(
>   struct drm_dp_mst_atomic_payload *old_payload)
>  {
>   struct drm_dp_mst_atomic_payload *pos;
> - int pbn_per_slot = mst_state->pbn_div;
> + int pbn_per_slot = dfixed_trunc(mst_state->pbn_div);
>   u8 next_payload_vc_start = mgr->next_start_slot;
>   u8 payload_vc_start = new_payload->vc_start_slot;
>   u8 allocated_time_slots;

I'm planning to merge this patchset today via drm-intel-next and for
that I'll need to rebase the above change to:

@@ -205,13 +206,14 @@ void dm_helpers_dp_update_branch_info(

 static void dm_helpers_construct_old_payload(
struct dc_link *link,
-   int pbn_per_slot,
+   fixed20_12 pbn_per_slot_fp,
struct drm_dp_mst_atomic_payload *new_payload,
struct drm_dp_mst_atomic_payload *old_payload)
 {
struct link_mst_stream_allocation_table current_link_table =

link->mst_stream_alloc_table;
struct link_mst_stream_allocation *dc_alloc;
+   int pbn_per_slot = dfixed_trunc(pbn_per_slot_fp);
int i;

*old_payload = *new_payload;

and then apply the original changes in the patch above while merging
drm-intel-next to drm-tip. This is required due to

commit 9031e0013f819c ("drm/amd/display: Fix mst hub unplug warning")

being only in drm-misc-next, but not yet in drm-intel-next.

Let me know if you have a concern with this.

--Imre

[PATCH v3 101/108] drm/bridge: ti-sn65dsi86: Make use of devm_pwmchip_alloc() function

[Uwe Kleine-König]

This prepares the pwm driver of the ti-sn65dsi86 to further changes of
the pwm core outlined in the commit introducing devm_pwmchip_alloc().
There is no intended semantical change and the driver should behave as
before.

Signed-off-by: Uwe Kleine-König 
---
 drivers/gpu/drm/bridge/ti-sn65dsi86.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c 
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index c45c07840f64..cd40530ffd71 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
@@ -197,7 +197,7 @@ struct ti_sn65dsi86 {
DECLARE_BITMAP(gchip_output, SN_NUM_GPIOS);
 #endif
 #if defined(CONFIG_PWM)
-   struct pwm_chip pchip;
+   struct pwm_chip *pchip;
boolpwm_enabled;
atomic_tpwm_pin_busy;
 #endif
@@ -1372,7 +1372,8 @@ static void ti_sn_pwm_pin_release(struct ti_sn65dsi86 
*pdata)
 
 static struct ti_sn65dsi86 *pwm_chip_to_ti_sn_bridge(struct pwm_chip *chip)
 {
-   return container_of(chip, struct ti_sn65dsi86, pchip);
+   struct ti_sn65dsi86 **pdata = pwmchip_priv(chip);
+   return *pdata;
 }
 
 static int ti_sn_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
@@ -1585,22 +1586,28 @@ static const struct pwm_ops ti_sn_pwm_ops = {
 static int ti_sn_pwm_probe(struct auxiliary_device *adev,
   const struct auxiliary_device_id *id)
 {
+   struct pwm_chip *chip;
struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
 
-   pdata->pchip.dev = pdata->dev;
-   pdata->pchip.ops = _sn_pwm_ops;
-   pdata->pchip.npwm = 1;
-   pdata->pchip.of_xlate = of_pwm_single_xlate;
-   pdata->pchip.of_pwm_n_cells = 1;
+   /* XXX: should this better use adev->dev instead of pdata->dev? */
+   pdata->pchip = chip = devm_pwmchip_alloc(pdata->dev, 1, sizeof());
+   if (IS_ERR(chip))
+   return PTR_ERR(chip);
 
-   return pwmchip_add(>pchip);
+   *(struct ti_sn65dsi86 **)pwmchip_priv(chip) = pdata;
+
+   chip->ops = _sn_pwm_ops;
+   chip->of_xlate = of_pwm_single_xlate;
+   chip->of_pwm_n_cells = 1;
+
+   return pwmchip_add(chip);
 }
 
 static void ti_sn_pwm_remove(struct auxiliary_device *adev)
 {
struct ti_sn65dsi86 *pdata = dev_get_drvdata(adev->dev.parent);
 
-   pwmchip_remove(>pchip);
+   pwmchip_remove(pdata->pchip);
 
if (pdata->pwm_enabled)
pm_runtime_put_sync(pdata->dev);
-- 
2.42.0

[Bug 218168] amdgpu: kfd_topology.c warning: the frame size of 1408 bytes is larger than 1024 bytes

[bugzilla-daemon]

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

Artem S. Tashkinov (a...@gmx.com) changed:

   What|Removed |Added

URL||https://gitlab.freedesktop.
   ||org/drm/amd/-/issues/2866

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

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

[Bug 218168] amdgpu: kfd_topology.c warning: the frame size of 1408 bytes is larger than 1024 bytes

[bugzilla-daemon]

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

--- Comment #4 from Artem S. Tashkinov (a...@gmx.com) ---
Fixed by 

https://gitlab.freedesktop.org/drm/amd/uploads/26580b07cb9c763a0b840b9d705e0338/0001-drm-amdkfd-reduce-stack-size-in-kfd_topology_add_dev.patch

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

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

Re: [Intel-gfx] [PATCH v3 02/11] drm/dp_mst: Fix PBN divider calculation for UHBR rates

[Maarten Lankhorst]

On 2023-11-17 20:40, Rodrigo Vivi wrote:

On Fri, Nov 17, 2023 at 06:21:07PM +0200, Ville Syrjälä wrote:

On Fri, Nov 17, 2023 at 05:09:27PM +0200, Imre Deak wrote:

The current way of calculating the pbn_div value, the link BW per each
MTP slot, worked only for DP 1.4 link rates. Fix things up for UHBR
rates calculating with the correct channel coding efficiency based on
the link rate.

v2:
- Return the fractional pbn_div value from drm_dp_get_vc_payload_bw().
v3:
- Fix rounding up quotient while calculating req_slots. (Ville)

Cc: Ville Syrjälä 
Cc: Lyude Paul 
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak 


Reviewed-by: Ville Syrjälä 


Dave, Sima, it looks like this whole series is ready for getting merged:

https://patchwork.freedesktop.org/series/126526/

But it has these 3 drm/dp_mst here.
Ack to merge them through drm-intel?

Well, as drm-misc maintainer:

Acked-by: Maarten Lankhorst 






---
  drivers/gpu/drm/display/drm_dp_mst_topology.c | 10 +++---
  include/drm/display/drm_dp_helper.h   | 13 +
  2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 000d05e80352a..8ca01a6bf645d 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3585,14 +3585,18 @@ static int drm_dp_send_up_ack_reply(struct 
drm_dp_mst_topology_mgr *mgr,
  fixed20_12 drm_dp_get_vc_payload_bw(const struct drm_dp_mst_topology_mgr *mgr,
int link_rate, int link_lane_count)
  {
+   int ch_coding_efficiency =
+   
drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(link_rate));
fixed20_12 ret;
  
  	if (link_rate == 0 || link_lane_count == 0)

drm_dbg_kms(mgr->dev, "invalid link rate/lane count: (%d / 
%d)\n",
link_rate, link_lane_count);
  
-	/* See DP v2.0 2.6.4.2, VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */

-   ret.full = dfixed_const(link_rate * link_lane_count / 54000);
+   /* See DP v2.0 2.6.4.2, 2.7.6.3 
VCPayload_Bandwidth_for_OneTimeSlotPer_MTP_Allocation */
+   ret.full = DIV_ROUND_DOWN_ULL(mul_u32_u32(link_rate * link_lane_count,
+ ch_coding_efficiency),
+ (100ULL * 8 * 5400) >> 12);
  
  	return ret;

  }
@@ -4342,7 +4346,7 @@ int drm_dp_atomic_find_time_slots(struct drm_atomic_state 
*state,
}
}
  
-	req_slots = DIV_ROUND_UP(pbn, dfixed_trunc(topology_state->pbn_div));

+   req_slots = DIV_ROUND_UP(dfixed_const(pbn), 
topology_state->pbn_div.full);
  
  	drm_dbg_atomic(mgr->dev, "[CONNECTOR:%d:%s] [MST PORT:%p] TU %d -> %d\n",

   port->connector->base.id, port->connector->name,
diff --git a/include/drm/display/drm_dp_helper.h 
b/include/drm/display/drm_dp_helper.h
index c5f1079acb3b1..863b2e7add29e 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -252,6 +252,19 @@ drm_edp_backlight_supported(const u8 
edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
return !!(edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP);
  }
  
+/**

+ * drm_dp_is_uhbr_rate - Determine if a link rate is UHBR
+ * @link_rate: link rate in 10kbits/s units
+ *
+ * Determine if the provided link rate is an UHBR rate.
+ *
+ * Returns: %True if @link_rate is an UHBR rate.
+ */
+static inline bool drm_dp_is_uhbr_rate(int link_rate)
+{
+   return link_rate >= 100;
+}
+
  /*
   * DisplayPort AUX channel
   */
--
2.39.2


--
Ville Syrjälä
Intel

Re: Implement per-key keyboard backlight as auxdisplay?

[Werner Sembach]

Am 21.11.23 um 13:20 schrieb Hans de Goede:

Hi Werner,

On 11/21/23 12:33, Werner Sembach wrote:

Hi,

Am 20.11.23 um 21:52 schrieb Pavel Machek:

Hi!


So... a bit of rationale. The keyboard does not really fit into the
LED subsystem; LEDs are expected to be independent ("hdd led") and not
a matrix of them.

Makes sense.


We do see various strange displays these days -- they commonly have
rounded corners and holes in them. I'm not sure how that's currently
supported, but I believe it is reasonable to view keyboard as a
display with slightly weird placing of pixels.

Plus, I'd really like to play tetris on one of those :-).

So, would presenting them as auxdisplay be acceptable? Or are there
better options?

It sounds like a fair use case -- auxdisplay are typically simple
character-based or small graphical displays, e.g. 128x64, that may not
be a "main" / usual screen as typically understood, but the concept is
a bit fuzzy and we are a bit of a catch-all.

And "keyboard backlight display with a pixel/color per-key" does not
sound like a "main" screen, and having some cute effects displayed
there are the kind of thing that one could do in the usual small
graphical ones too. :)

But if somebody prefers to create new categories (or subcategories
within auxdisplay) to hold these, that could be nice too (in the
latter case, I would perhaps suggest reorganizing all of the existing
ones while at it).

One could also reasonably make the argument that controlling the
individual keyboard key backlights should be part of the input
subsystem. It's not a display per se. (Unless you actually have small
displays on the keycaps, and I think that's a thing too.)

While it would not be completely crazy to do that... I believe the
backlight is more of a display and less of a keyboard. Plus input
subystem is very far away from supporting this, and we had no input
from input people here.

I don't think LED subsystem is right place for this, and I believe
auxdisplay makes slightly more sense than input.

Unless someone steps up, I'd suggest Werner tries to implement this as
an auxdisplay. [And yes, this will not be simple task. RGB on LED is
different from RGB on display. But there are other LED displays, so
auxdisplay should handle this. Plus pixels are really funnily
shaped. But displays with missing pixels -- aka holes for camera --
are common in phones, and I believe we'll get variable pixel densities
-- less dense over camera -- too. So displays will have to deal with
these in the end.]

Another idea I want to throw in the mix:

Maybe the kernel is not the right place to implement this at all. RGB stuff is 
not at all standardized and every vendor is doing completely different 
interfaces, which does not fit the kernel userpsace apis desire to be uniformal 
and fixed. e.g. Auxdisplay might fit static setting of RGB values, but it does 
not fit the snake-effect mode, or the raindrops mode, or the 
4-different-colors-in-the-edges-breathing-and-color-cycling mode.

So my current idea: Implement these keyboards as a single zone RGB 
kbd_backlight in the leds interface to have something functional out of the 
box, but make it runtime disable-able if something like 
https://gitlab.com/CalcProgrammer1/OpenRGB wants to take over more fine 
granular control from userspace via hidraw.

That sounds like a good approach to me. We are seeing the same with game 
controllers where steam and wine/proton also sometimes use hidraw mode to get 
access to all the crazy^W interesting features.

That would mean that all we need to standardize and the kernel <-> userspace 
API level is adding a standard way to disable the single zone RGB kbd_backlight 
support in the kernel.


I would suggest a simple "enable" entry. Default is 1. When set to 0 the kernel 
driver no longer does anything.


Questions:

- Should the driver try to reset the settings to boot default? Or just leave the 
device in the current state? With the former I could see issues that they 
keyboard is flashing when changing from kernelspace control to userspace 
control. With the later the burden on bringing the device to a know state lies 
with the userspace driver.


- Should this be a optional entry that only shows up on drivers supporting it, 
or could this implemented in a generic way affecting all current led entries?


- I guess UPower integration for the userspace driver could be archived with 
https://www.kernel.org/doc/html/latest/leds/uleds.html however this limited to 
brightness atm, so when accent colors actually come to UPower this would also 
need some expansion to be able to pass a preferred color to the userspace driver 
(regardless of what that driver is then doing with that information).


On a different note: This approach does currently not cover the older EC 
controlled 3 zone keyboards from clevo. Here only the kernel has access access 
to the device so the kernel driver has to expose all functionality somehow. 
Should this be done by an arbitrarily 

Re: [Intel-gfx] [PATCH v4 00/20] remove I2C_CLASS_DDC support

[Heiner Kallweit]

On 21.11.2023 09:58, Jani Nikula wrote:
> On Mon, 20 Nov 2023, Heiner Kallweit  wrote:
>> v4:
>> - more ack and review tags
> 
> Please do not send new versions just to record the acks and
> reviews. They should be added while applying the patches.
> 
Right, typically also patchwork interprets and shows A-b and R-b when
sent as a reply to a patch of the series. I sent a new version because
an A-b covered multiple patches and was sent as reply to the cover letter.

> Thanks,
> Jani.
> 
Heiner

Re: [PATCH v2] Remove custom dumb_map_offset implementation in msm driver

[Dmitry Baryshkov]

On Tue, 21 Nov 2023 at 04:26, Rob Clark  wrote:
>
> On Wed, Nov 15, 2023 at 11:33 AM Dmitry Baryshkov
>  wrote:
> >
> > On Wed, 15 Nov 2023 at 20:46, Dipam Turkar  wrote:
> > >
> > > They are not outdated, my bad. I went through the locks' code and saw 
> > > that they have been updated. But they are probably not necessary here as 
> > > most of the drivers do not use any form of locking in their 
> > > implementations. The generic implementations drm_gem_dumb_map_offset() 
> > > and drm_gem_ttm_dumb_map_offset() do not have any locking mechanisms 
> > > either.
> >
> > Excuse me, but this doesn't sound right to me. There are different
> > drivers with different implementations. So either we'd need a good
> > explanation of why it is not necessary, or this patch is NAKed.
>
> Digging a bit thru history, it looks like commit 0de23977cfeb
> ("drm/gem: convert to new unified vma manager") made external locking
> unnecessary, since the vma mgr already had it's own internal locking.

So, should we drop our own locking system?

>
> BR,
> -R
>
> > >
> > > Thanks and regards
> > > Dipam Turkar
> > >
> > > On Wed, Nov 15, 2023 at 8:37 PM Dmitry Baryshkov 
> > >  wrote:
> > >>
> > >> On Wed, 15 Nov 2023 at 16:30, Dipam Turkar  wrote:
> > >> >
> > >> > Make msm use drm_gem_create_map_offset() instead of its custom
> > >> > implementation for associating GEM object with a fake offset. Since,
> > >> > we already have this generic implementation, we don't need the custom
> > >> > implementation and it is better to standardize the code for GEM based
> > >> > drivers. This also removes the outdated locking leftovers.
> > >>
> > >> Why are they outdated?
> > >>
> > >> >
> > >> > Signed-off-by: Dipam Turkar 
> > >> > ---
> > >> >  drivers/gpu/drm/msm/msm_drv.c |  2 +-
> > >> >  drivers/gpu/drm/msm/msm_gem.c | 21 -
> > >> >  drivers/gpu/drm/msm/msm_gem.h |  2 --
> > >> >  3 files changed, 1 insertion(+), 24 deletions(-)
> > >> >
> > >> > Changes in v2:
> > >> > Modify commit message to include the absence of internal locking 
> > >> > leftovers
> > >> > around allocating a fake offset in msm_gem_mmap_offset() in the generic
> > >> > implementation drm_gem_create_map_offset().
> > >> >
> > >> > diff --git a/drivers/gpu/drm/msm/msm_drv.c 
> > >> > b/drivers/gpu/drm/msm/msm_drv.c
> > >> > index a428951ee539..86a15992c717 100644
> > >> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > >> > +++ b/drivers/gpu/drm/msm/msm_drv.c
> > >> > @@ -1085,7 +1085,7 @@ static const struct drm_driver msm_driver = {
> > >> > .open   = msm_open,
> > >> > .postclose  = msm_postclose,
> > >> > .dumb_create= msm_gem_dumb_create,
> > >> > -   .dumb_map_offset= msm_gem_dumb_map_offset,
> > >> > +   .dumb_map_offset= drm_gem_dumb_map_offset,
> > >> > .gem_prime_import_sg_table = msm_gem_prime_import_sg_table,
> > >> >  #ifdef CONFIG_DEBUG_FS
> > >> > .debugfs_init   = msm_debugfs_init,
> > >> > diff --git a/drivers/gpu/drm/msm/msm_gem.c 
> > >> > b/drivers/gpu/drm/msm/msm_gem.c
> > >> > index db1e748daa75..489694ef79cb 100644
> > >> > --- a/drivers/gpu/drm/msm/msm_gem.c
> > >> > +++ b/drivers/gpu/drm/msm/msm_gem.c
> > >> > @@ -671,27 +671,6 @@ int msm_gem_dumb_create(struct drm_file *file, 
> > >> > struct drm_device *dev,
> > >> > MSM_BO_SCANOUT | MSM_BO_WC, >handle, 
> > >> > "dumb");
> > >> >  }
> > >> >
> > >> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device 
> > >> > *dev,
> > >> > -   uint32_t handle, uint64_t *offset)
> > >> > -{
> > >> > -   struct drm_gem_object *obj;
> > >> > -   int ret = 0;
> > >> > -
> > >> > -   /* GEM does all our handle to object mapping */
> > >> > -   obj = drm_gem_object_lookup(file, handle);
> > >> > -   if (obj == NULL) {
> > >> > -   ret = -ENOENT;
> > >> > -   goto fail;
> > >> > -   }
> > >> > -
> > >> > -   *offset = msm_gem_mmap_offset(obj);
> > >> > -
> > >> > -   drm_gem_object_put(obj);
> > >> > -
> > >> > -fail:
> > >> > -   return ret;
> > >> > -}
> > >> > -
> > >> >  static void *get_vaddr(struct drm_gem_object *obj, unsigned madv)
> > >> >  {
> > >> > struct msm_gem_object *msm_obj = to_msm_bo(obj);
> > >> > diff --git a/drivers/gpu/drm/msm/msm_gem.h 
> > >> > b/drivers/gpu/drm/msm/msm_gem.h
> > >> > index 8ddef5443140..dc74a0ef865d 100644
> > >> > --- a/drivers/gpu/drm/msm/msm_gem.h
> > >> > +++ b/drivers/gpu/drm/msm/msm_gem.h
> > >> > @@ -139,8 +139,6 @@ struct page **msm_gem_pin_pages(struct 
> > >> > drm_gem_object *obj);
> > >> >  void msm_gem_unpin_pages(struct drm_gem_object *obj);
> > >> >  int msm_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
> > >> > struct drm_mode_create_dumb *args);
> > >> > -int msm_gem_dumb_map_offset(struct drm_file *file, struct drm_device 
> > >> > *dev,
> > >> > -   uint32_t handle, uint64_t 

Re: [PATCH v5] Documentation/gpu: VM_BIND locking document

[Bagas Sanjaya]

On Tue, Nov 21, 2023 at 11:40:46AM +0100, Thomas Hellström wrote:
> diff --git a/Documentation/gpu/drm-vm-bind-locking.rst 
> b/Documentation/gpu/drm-vm-bind-locking.rst
> new file mode 100644
> index ..a7d08eccd50e
> --- /dev/null
> +++ b/Documentation/gpu/drm-vm-bind-locking.rst
> @@ -0,0 +1,579 @@
> +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +===
> +VM_BIND locking
> +===
> +
> +This document attempts to describe what's needed to get VM_BIND locking 
> right,
> +including the userptr mmu_notifier locking and it also discusses some
> +optimizations to get rid of the looping through of all userptr mappings and
> +external / shared object mappings that is needed in the simplest
> +implementation. In addition there is a section describing the VM_BIND locking
> +required for implementing recoverable pagefaults.
> +
> +The DRM GPUVM set of helpers
> +
> +
> +There is a set of helpers for drivers implementing VM_BIND, and this
> +set of helpers implements much, but not all of the locking described
> +in this document. In particular it is currently lacking a userptr
> +implementation. Please refer to the :ref:`DRM GPUVM documentation
> +`. This document does not intend to describe the DRM GPUVM
> +implementation in detail, but in some places uses it as an
> +implementation example. It is highly recommended for any driver
> +implementing VM_BIND to use the DRM GPUVM helpers and to extend it if
> +common functionality is missing.

"... This document does not intend to describe the DRM GPUVM implementation
in detail; such treatment is covered in :ref:`its own document `."

> +
> +Nomenclature
> +
> +
> +* ``Context``: GPU execution context.
> +* ``gpu_vm``: Abstraction of a virtual GPU address space with
> +  meta-data. Typically one per client (DRM file-private), or one per
> +  context.
> +* ``gpu_vma``: Abstraction of a GPU address range within a gpu_vm with
> +  associated meta-data. The backing storage of a gpu_vma can either be
> +  a GEM object or anonymous pages mapped also into the CPU
> +  address space for the process.
> +* ``gpu_vm_bo``: Abstracts the association of a GEM object and
> +  a VM. The GEM object maintains a list of gpu_vm_bos, and a gpu_vm_bo
> +  maintains a list of gpu_vmas.
> +* ``userptr gpu_vma or just userptr``: A gpu_vma, whose backing store
> +  is anonymous pages as described above.
> +* ``revalidating``: Revalidating a gpu_vma means making the latest version
> +  of the backing store resident and making sure the gpu_vma's
> +  page-table entries point to that backing store.
> +* ``dma_fence``: A struct dma_fence that is similar to a struct completion
> +  and which tracks GPU activity. When the GPU activity is finished,
> +  the dma_fence signals. Please refer to the ``DMA Fences`` section of
> +  the :doc:`dma-buf doc `.
> +* ``dma_resv``: A struct dma_resv (a.k.a reservation object) that is used
> +  to track GPU activity in the form of multiple dma_fences on a
> +  gpu_vm or a GEM object. The dma_resv contains an array / list
> +  of dma_fences and a lock that needs to be held when adding
> +  additional dma_fences to the dma_resv. The lock is of a type that
> +  allows deadlock-safe locking of multiple dma_resvs in arbitrary
> +  order. Please refer to the ``Reservation Objects`` section of the
> +  :doc:`dma-buf doc `.
> +* ``exec function``: An exec function is a function that revalidates all
> +  affected gpu_vmas, submits a GPU command batch and registers the
> +  dma_fence representing the GPU command's activity with all affected
> +  dma_resvs. For completeness, although not covered by this document,
> +  it's worth mentioning that an exec function may also be the
> +  revalidation worker that is used by some drivers in compute /
> +  long-running mode.
> +* ``local object``: A GEM object which is only mapped within a
> +  single VM. Local GEM objects share the gpu_vm's dma_resv.
> +* ``external object``: a.k.a shared object: A GEM object which may be shared
> +  by multiple gpu_vms and whose backing storage may be shared with
> +  other drivers.
> +
> +Locks and locking order
> +===
> +
> +One of the benefits of VM_BIND is that local GEM objects share the gpu_vm's
> +dma_resv object and hence the dma_resv lock. So even with a huge
> +number of local GEM objects, only one lock is needed to make the exec
> +sequence atomic.
> +
> +The following locks and locking orders are used:
> +
> +* The ``gpu_vm->lock`` (optionally an rwsem). Protects the gpu_vm's
> +  data structure keeping track of gpu_vmas. It can also protect the
> +  gpu_vm's list of userptr gpu_vmas. With a CPU mm analogy this would
> +  correspond to the mmap_lock.
> +* The ``userptr_seqlock``. This lock is taken in read mode for each
> +  userptr gpu_vma on the gpu_vm's userptr list, and in write mode during mmu
> +  notifier invalidation. This is not a real seqlock but described in
> +  

Re: WARNING in allocate_mst_payload

[Christian König]

Hi Jeff,

first of all adding Harry from our display team.

From a quick look the obvious missing information is how are your 
monitors wired up? Are those individually DP or HDMI connected to the PC 
or are they daisy chained through MST?


If it's daisy chained please double check that you don't have a faulty 
connection and maybe individually connect them for a test if possible.


Regards,
Christian.

Am 21.11.23 um 14:01 schrieb Jeff Layton:

I have a recurring problem where my workstation tries to put the monitor
to sleep, which triggers a warning down in the depths of the video card
driver. When I return to the machine the monitor is black, but not in
powersave mode and all of the windows on my desktop have been shuffled
off to the second monitor.

I've seen this since at least v6.3 or so (though the problem may predate
that). The kernel is stock Fedora kernel. It's occurs fairly reliably,
and I'm happy to help test patches.

I took a quick look at the sources and the reported line corresponds
with this assertion in  allocate_mst_payload:

 ASSERT(proposed_table.stream_count > 0);

I've attached the output from wayland-info, and the stack traces follow.
Let me know if any other info would be helpful.


[ 4655.946669] [ cut here ]
[ 4655.946677] WARNING: CPU: 12 PID: 3979 at 
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:1484 
link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.947689] Modules linked in: uinput xt_mark rfcomm snd_seq_dummy 
snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core tun xt_CHECKSUM xt_MASQUERADE 
xt_conntrack ipt_REJECT nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns 
nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat 
ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat 
bridge nf_conntrack stp llc nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle 
iptable_raw iptable_security ip_set nf_tables nfnetlink ip6table_filter 
iptable_filter qrtr bnep binfmt_misc xfs vfat fat ppdev snd_hda_codec_realtek 
snd_hda_codec_generic intel_rapl_msr snd_hda_codec_hdmi ledtrig_audio 
snd_hda_intel intel_rapl_common snd_intel_dspcfg edac_mce_amd 
snd_intel_sdw_acpi snd_usb_audio snd_hda_codec uvcvideo kvm_amd btusb 
snd_usbmidi_lib snd_hda_core btrtl snd_ump btbcm snd_rawmidi btintel snd_hwdep 
uvc btmtk kvm videobuf2_vmalloc videobuf2_memops bluetooth snd_seq
[ 4655.947889]  snd_seq_device irqbypass videobuf2_v4l2 rapl xpad 
videobuf2_common snd_pcm ff_memless wmi_bmof mxm_wmi pcspkr acpi_cpufreq 
videodev k10temp rfkill i2c_piix4 snd_timer snd mc soundcore parport_pc parport 
gpio_amdpt gpio_generic joydev nfsd auth_rpcgss nfs_acl lockd grace sunrpc loop 
zram amdgpu i2c_algo_bit drm_ttm_helper ttm video drm_suballoc_helper uas 
amdxcp iommu_v2 crct10dif_pclmul crc32_pclmul drm_buddy crc32c_intel gpu_sched 
polyval_clmulni usb_storage r8169 polyval_generic drm_display_helper nvme 
ghash_clmulni_intel nvme_core ccp sha512_ssse3 cec sp5100_tco nvme_common wmi 
scsi_dh_rdac scsi_dh_emc scsi_dh_alua ip6_tables ip_tables dm_multipath fuse
[ 4655.948051] CPU: 12 PID: 3979 Comm: KMS thread Kdump: loaded Not tainted 
6.5.11-300.fc39.x86_64 #1
[ 4655.948058] Hardware name: Micro-Star International Co., Ltd. MS-7A33/X370 
SLI PLUS (MS-7A33), BIOS 3.JR 11/29/2019
[ 4655.948062] RIP: 0010:link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.949058] Code: e9 3f fc ff ff 48 c7 c7 98 c7 20 c1 e8 d4 33 e8 e4 e9 c0 fe ff 
ff 48 8b bb d0 01 00 00 48 89 de e8 40 d0 ed ff e9 25 ff ff ff <0f> 0b e9 88 fd 
ff ff 41 c6 85 50 04 00 00 00 e9 d1 f8 ff ff 49 8b
[ 4655.949064] RSP: 0018:be344ac2b430 EFLAGS: 00010246
[ 4655.949071] RAX:  RBX: 953f0bfab000 RCX: 0005
[ 4655.949076] RDX: c120c6a8 RSI: 0002 RDI: 
[ 4655.949080] RBP: 953f0bfab000 R08:  R09: 0005
[ 4655.949084] R10: 953ece152800 R11: 953ed0eb9960 R12: 95401e4c0b38
[ 4655.949088] R13: 0006 R14: 953ed99c R15: 95401e4c0df0
[ 4655.949093] FS:  7fba5b8856c0() GS:954d9ed0() 
knlGS:
[ 4655.949099] CS:  0010 DS:  ES:  CR0: 80050033
[ 4655.949104] CR2: 1eca52061810 CR3: 0001ad4ac000 CR4: 003506e0
[ 4655.949109] Call Trace:
[ 4655.949114]  
[ 4655.949118]  ? link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.950106]  ? __warn+0x81/0x130
[ 4655.950118]  ? link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.951130]  ? report_bug+0x171/0x1a0
[ 4655.951144]  ? handle_bug+0x3c/0x80
[ 4655.951153]  ? exc_invalid_op+0x17/0x70
[ 4655.951160]  ? asm_exc_invalid_op+0x1a/0x20
[ 4655.951178]  ? link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.952193]  dce110_apply_ctx_to_hw+0x535/0x700 [amdgpu]
[ 4655.953141]  dc_commit_state_no_check+0x3cd/0xef0 [amdgpu]
[ 4655.954083]  dc_commit_streams+0x29b/0x400 [amdgpu]
[ 4655.955032]  

WARNING in allocate_mst_payload

[Jeff Layton]

I have a recurring problem where my workstation tries to put the monitor
to sleep, which triggers a warning down in the depths of the video card
driver. When I return to the machine the monitor is black, but not in
powersave mode and all of the windows on my desktop have been shuffled
off to the second monitor.

I've seen this since at least v6.3 or so (though the problem may predate
that). The kernel is stock Fedora kernel. It's occurs fairly reliably,
and I'm happy to help test patches.

I took a quick look at the sources and the reported line corresponds
with this assertion in  allocate_mst_payload:

ASSERT(proposed_table.stream_count > 0);   

I've attached the output from wayland-info, and the stack traces follow.
Let me know if any other info would be helpful.


[ 4655.946669] [ cut here ]
[ 4655.946677] WARNING: CPU: 12 PID: 3979 at 
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:1484 
link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.947689] Modules linked in: uinput xt_mark rfcomm snd_seq_dummy 
snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core tun xt_CHECKSUM xt_MASQUERADE 
xt_conntrack ipt_REJECT nf_nat_tftp nf_conntrack_tftp nf_conntrack_netbios_ns 
nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat 
ip6table_nat ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_nat 
bridge nf_conntrack stp llc nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle 
iptable_raw iptable_security ip_set nf_tables nfnetlink ip6table_filter 
iptable_filter qrtr bnep binfmt_misc xfs vfat fat ppdev snd_hda_codec_realtek 
snd_hda_codec_generic intel_rapl_msr snd_hda_codec_hdmi ledtrig_audio 
snd_hda_intel intel_rapl_common snd_intel_dspcfg edac_mce_amd 
snd_intel_sdw_acpi snd_usb_audio snd_hda_codec uvcvideo kvm_amd btusb 
snd_usbmidi_lib snd_hda_core btrtl snd_ump btbcm snd_rawmidi btintel snd_hwdep 
uvc btmtk kvm videobuf2_vmalloc videobuf2_memops bluetooth snd_seq
[ 4655.947889]  snd_seq_device irqbypass videobuf2_v4l2 rapl xpad 
videobuf2_common snd_pcm ff_memless wmi_bmof mxm_wmi pcspkr acpi_cpufreq 
videodev k10temp rfkill i2c_piix4 snd_timer snd mc soundcore parport_pc parport 
gpio_amdpt gpio_generic joydev nfsd auth_rpcgss nfs_acl lockd grace sunrpc loop 
zram amdgpu i2c_algo_bit drm_ttm_helper ttm video drm_suballoc_helper uas 
amdxcp iommu_v2 crct10dif_pclmul crc32_pclmul drm_buddy crc32c_intel gpu_sched 
polyval_clmulni usb_storage r8169 polyval_generic drm_display_helper nvme 
ghash_clmulni_intel nvme_core ccp sha512_ssse3 cec sp5100_tco nvme_common wmi 
scsi_dh_rdac scsi_dh_emc scsi_dh_alua ip6_tables ip_tables dm_multipath fuse
[ 4655.948051] CPU: 12 PID: 3979 Comm: KMS thread Kdump: loaded Not tainted 
6.5.11-300.fc39.x86_64 #1
[ 4655.948058] Hardware name: Micro-Star International Co., Ltd. MS-7A33/X370 
SLI PLUS (MS-7A33), BIOS 3.JR 11/29/2019
[ 4655.948062] RIP: 0010:link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.949058] Code: e9 3f fc ff ff 48 c7 c7 98 c7 20 c1 e8 d4 33 e8 e4 e9 c0 
fe ff ff 48 8b bb d0 01 00 00 48 89 de e8 40 d0 ed ff e9 25 ff ff ff <0f> 0b e9 
88 fd ff ff 41 c6 85 50 04 00 00 00 e9 d1 f8 ff ff 49 8b
[ 4655.949064] RSP: 0018:be344ac2b430 EFLAGS: 00010246
[ 4655.949071] RAX:  RBX: 953f0bfab000 RCX: 0005
[ 4655.949076] RDX: c120c6a8 RSI: 0002 RDI: 
[ 4655.949080] RBP: 953f0bfab000 R08:  R09: 0005
[ 4655.949084] R10: 953ece152800 R11: 953ed0eb9960 R12: 95401e4c0b38
[ 4655.949088] R13: 0006 R14: 953ed99c R15: 95401e4c0df0
[ 4655.949093] FS:  7fba5b8856c0() GS:954d9ed0() 
knlGS:
[ 4655.949099] CS:  0010 DS:  ES:  CR0: 80050033
[ 4655.949104] CR2: 1eca52061810 CR3: 0001ad4ac000 CR4: 003506e0
[ 4655.949109] Call Trace:
[ 4655.949114]  
[ 4655.949118]  ? link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.950106]  ? __warn+0x81/0x130
[ 4655.950118]  ? link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.951130]  ? report_bug+0x171/0x1a0
[ 4655.951144]  ? handle_bug+0x3c/0x80
[ 4655.951153]  ? exc_invalid_op+0x17/0x70
[ 4655.951160]  ? asm_exc_invalid_op+0x1a/0x20
[ 4655.951178]  ? link_set_dpms_on+0xbe5/0xca0 [amdgpu]
[ 4655.952193]  dce110_apply_ctx_to_hw+0x535/0x700 [amdgpu]
[ 4655.953141]  dc_commit_state_no_check+0x3cd/0xef0 [amdgpu]
[ 4655.954083]  dc_commit_streams+0x29b/0x400 [amdgpu]
[ 4655.955032]  amdgpu_dm_atomic_commit_tail+0x5e8/0x3b10 [amdgpu]
[ 4655.956023]  ? dcn30_populate_dml_writeback_from_context+0x35/0x50 [amdgpu]
[ 4655.956963]  ? srso_return_thunk+0x5/0x10
[ 4655.956972]  ? dcn30_populate_dml_writeback_from_context+0x35/0x50 [amdgpu]
[ 4655.957912]  ? srso_return_thunk+0x5/0x10
[ 4655.957926]  ? srso_return_thunk+0x5/0x10
[ 4655.957934]  ? srso_return_thunk+0x5/0x10
[ 4655.957940]  ? dcn30_internal_validate_bw+0x992/0x9d0 

Re: [v3 3/3] drm/bridge: it6505: Add audio support

[AngeloGioacchino Del Regno]

Il 30/07/23 20:08, Jiaxin Yu ha scritto:

Add audio support for it6505

1. Bridge to hdmi-codec to support audio feature. At the same time,
the function of automatically detecting audio is removed.
2. It is observed that some DP-to-HDMI dongles will get into bad
states if sending InfoFrame without audio data. Defer to enable
it6505's audio feature when PCM triggers START or RESUME.

Signed-off-by: Jiaxin Yu 


Hello Jiaxin,
this patch doesn't apply anymore (and it won't build anymore) upstream.


---
  drivers/gpu/drm/bridge/ite-it6505.c | 81 ++---
  1 file changed, 75 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index 504d51c42f79..1cfcb0731288 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -2162,7 +2162,6 @@ static void it6505_stop_link_train(struct it6505 *it6505)
  
  static void it6505_link_train_ok(struct it6505 *it6505)

  {
-   struct device *dev = >client->dev;


This is because this changed to `struct device *dev = it6505->dev;`

  
  	it6505->link_state = LINK_OK;

/* disalbe mute enable avi info frame */
@@ -2170,11 +2169,6 @@ static void it6505_link_train_ok(struct it6505 *it6505)
it6505_set_bits(it6505, REG_INFOFRAME_CTRL,
EN_VID_CTRL_PKT, EN_VID_CTRL_PKT);
  
-	if (it6505_audio_input(it6505)) {

-   DRM_DEV_DEBUG_DRIVER(dev, "Enable audio!");
-   it6505_enable_audio(it6505);
-   }
-
if (it6505->hdcp_desired)
it6505_start_hdcp(it6505);
  }
@@ -2846,6 +2840,45 @@ static void __maybe_unused it6505_audio_shutdown(struct 
device *dev, void *data)
it6505_disable_audio(it6505);
  }
  
+static int it6505_audio_hw_params(struct device *dev, void *data,

+ struct hdmi_codec_daifmt *daifmt,
+ struct hdmi_codec_params *params)
+{
+   struct it6505 *it6505 = dev_get_drvdata(dev);
+
+   return it6505_audio_setup_hw_params(it6505, params);
+}
+
+static int it6505_audio_setup_trigger(struct it6505 *it6505, int cmd)
+{
+   struct device *dev = >client->dev;


...and because you'll have to change this one, and other occurrences of that
as well.

Can you please respin this series?

Thanks,
Angelo

Re: Implement per-key keyboard backlight as auxdisplay?

[Hans de Goede]

Hi Werner,

On 11/21/23 12:33, Werner Sembach wrote:
> Hi,
> 
> Am 20.11.23 um 21:52 schrieb Pavel Machek:
>> Hi!
>>
> So... a bit of rationale. The keyboard does not really fit into the
> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> a matrix of them.
 Makes sense.

> We do see various strange displays these days -- they commonly have
> rounded corners and holes in them. I'm not sure how that's currently
> supported, but I believe it is reasonable to view keyboard as a
> display with slightly weird placing of pixels.
>
> Plus, I'd really like to play tetris on one of those :-).
>
> So, would presenting them as auxdisplay be acceptable? Or are there
> better options?
 It sounds like a fair use case -- auxdisplay are typically simple
 character-based or small graphical displays, e.g. 128x64, that may not
 be a "main" / usual screen as typically understood, but the concept is
 a bit fuzzy and we are a bit of a catch-all.

 And "keyboard backlight display with a pixel/color per-key" does not
 sound like a "main" screen, and having some cute effects displayed
 there are the kind of thing that one could do in the usual small
 graphical ones too. :)

 But if somebody prefers to create new categories (or subcategories
 within auxdisplay) to hold these, that could be nice too (in the
 latter case, I would perhaps suggest reorganizing all of the existing
 ones while at it).
>>> One could also reasonably make the argument that controlling the
>>> individual keyboard key backlights should be part of the input
>>> subsystem. It's not a display per se. (Unless you actually have small
>>> displays on the keycaps, and I think that's a thing too.)
>> While it would not be completely crazy to do that... I believe the
>> backlight is more of a display and less of a keyboard. Plus input
>> subystem is very far away from supporting this, and we had no input
>> from input people here.
>>
>> I don't think LED subsystem is right place for this, and I believe
>> auxdisplay makes slightly more sense than input.
>>
>> Unless someone steps up, I'd suggest Werner tries to implement this as
>> an auxdisplay. [And yes, this will not be simple task. RGB on LED is
>> different from RGB on display. But there are other LED displays, so
>> auxdisplay should handle this. Plus pixels are really funnily
>> shaped. But displays with missing pixels -- aka holes for camera --
>> are common in phones, and I believe we'll get variable pixel densities
>> -- less dense over camera -- too. So displays will have to deal with
>> these in the end.]
> 
> Another idea I want to throw in the mix:
> 
> Maybe the kernel is not the right place to implement this at all. RGB stuff 
> is not at all standardized and every vendor is doing completely different 
> interfaces, which does not fit the kernel userpsace apis desire to be 
> uniformal and fixed. e.g. Auxdisplay might fit static setting of RGB values, 
> but it does not fit the snake-effect mode, or the raindrops mode, or the 
> 4-different-colors-in-the-edges-breathing-and-color-cycling mode.
> 
> So my current idea: Implement these keyboards as a single zone RGB 
> kbd_backlight in the leds interface to have something functional out of the 
> box, but make it runtime disable-able if something like 
> https://gitlab.com/CalcProgrammer1/OpenRGB wants to take over more fine 
> granular control from userspace via hidraw.

That sounds like a good approach to me. We are seeing the same with game 
controllers where steam and wine/proton also sometimes use hidraw mode to get 
access to all the crazy^W interesting features.

That would mean that all we need to standardize and the kernel <-> userspace 
API level is adding a standard way to disable the single zone RGB kbd_backlight 
support in the kernel.

Regards,

Hans

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix phys_base to be relative not absolute

[Andrzej Hajda]

On 18.11.2023 00:01, Paz Zcharya wrote:

On Tue, Nov 14, 2023 at 10:13:59PM -0500, Rodrigo Vivi wrote:

On Sun, Nov 05, 2023 at 05:27:03PM +, Paz Zcharya wrote:

Fix the value of variable `phys_base` to be the relative offset in
stolen memory, and not the absolute offset of the GSM.


to me it looks like the other way around. phys_base is the physical
base address for the frame_buffer. Setting it to zero doesn't seem
to make that relative. And also doesn't look right.



Currently, the value of `phys_base` is set to "Surface Base Address,"
which in the case of Meter Lake is 0xfc00_.


I don't believe this is a fixed value. IIRC this comes from the register
set by video bios, where the idea is to reuse the fb that was used so
far.

With this in mind I don't understand how that could overflow. Maybe
the size of the stolen is not right? maybe the size? maybe different
memory region?



Hi Rodrigo, thanks for the great comments.

Apologies for using a wrong/confusing terminology. I think 'phys_base'
is supposed to be the offset in the GEM BO, where base (or
"Surface Base Address") is supposed to be the GTT offset.


Since base is taken from PLANE_SURF register it should be resolvable via 
GGTT to physical address pointing to actual framebuffer.

I couldn't find anything in the specs.
The simplest approach would be then do the same as in case of DGFX:
gen8_pte_t __iomem *gte = to_gt(i915)->ggtt->gsm;
gen8_pte_t pte;

gte += base / I915_GTT_PAGE_SIZE;

pte = ioread64(gte);
phys_base = pte & I915_GTT_PAGE_MASK;

Regards
Andrzej




Other than what I wrote before, I noticed that the function 'i915_vma_pin'
which calls to 'i915_gem_gtt_reserve' is the one that binds the right
address space in the GTT for that stolen region.

I see that in the function 'i915_vma_insert' (full call stack below),
where if (flags & PIN_OFFSET_FIXED), then when calling 'i915_gem_gtt_reserve'
we add an offset.

Specifically in MeteorLake, and specifically when using GOP driver, this
offset is equal to 0xfc00_. But as you mentioned, this is not strict.

The if statement always renders true because in the function
'initial_plane_vma' we always set
pinctl = PIN_GLOBAL | PIN_OFFSET_FIXED | base;
where pinctl == flags (see file 'intel_plane_initial.c' line 145).

Call stack:
drm_mm_reserve_node
i915_gem_gtt_reserve
i915_vma_insert
i915_vma_pin_ww
i915_vma_pin
initial_plane_vma
intel_alloc_initial_plane_obj
intel_find_initial_plane_obj

Therefore, I believe the variable 'phys_base' in the
function 'initial_plane_vma,' should be the the offset in the GEM BO
and not the GTT offset, and because the base is added later on
in the function 'i915_gem_gtt_reserve', this value should not be
equal to base and be 0.

Hope it makes more sense.


This causes the
function `i915_gem_object_create_region_at` to fail in line 128, when
it attempts to verify that the range does not overflow:

if (range_overflows(offset, size, resource_size(>region)))
   return ERR_PTR(-EINVAL);

where:
   offset = 0xfc00
   size = 0x8ca000
   mem->region.end + 1 = 0x440
   mem->region.start = 0x80
   resource_size(>region) = 0x3c0

call stack:
   i915_gem_object_create_region_at
   initial_plane_vma
   intel_alloc_initial_plane_obj
   intel_find_initial_plane_obj
   intel_crtc_initial_plane_config

Looking at the flow coming next, we see that `phys_base` is only used
once, in function `_i915_gem_object_stolen_init`, in the context of
the offset *in* the stolen memory. Combining that with an
examinination of the history of the file seems to indicate the
current value set is invalid.

call stack (functions using `phys_base`)
   _i915_gem_object_stolen_init
   __i915_gem_object_create_region
   i915_gem_object_create_region_at
   initial_plane_vma
   intel_alloc_initial_plane_obj
   intel_find_initial_plane_obj
   intel_crtc_initial_plane_config

[drm:_i915_gem_object_stolen_init] creating preallocated stolen
object: stolen_offset=0x, size=0x008ca000

Signed-off-by: Paz Zcharya 
---

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

diff --git a/drivers/gpu/drm/i915/display/intel_plane_initial.c 
b/drivers/gpu/drm/i915/display/intel_plane_initial.c
index a55c09cbd0e4..e696cb13756a 100644
--- a/drivers/gpu/drm/i915/display/intel_plane_initial.c
+++ b/drivers/gpu/drm/i915/display/intel_plane_initial.c
@@ -90,7 +90,7 @@ initial_plane_vma(struct drm_i915_private *i915,
"Using phys_base=%pa, based on initial plane 
programming\n",
_base);
} else {
-   phys_base = base;
+   phys_base = 0;
mem = i915->mm.stolen_region;
}
  
--

2.42.0.869.gea05f2083d-goog

Re: Implement per-key keyboard backlight as auxdisplay?

[Werner Sembach]

Hi,

Am 20.11.23 um 21:52 schrieb Pavel Machek:

Hi!


So... a bit of rationale. The keyboard does not really fit into the
LED subsystem; LEDs are expected to be independent ("hdd led") and not
a matrix of them.

Makes sense.


We do see various strange displays these days -- they commonly have
rounded corners and holes in them. I'm not sure how that's currently
supported, but I believe it is reasonable to view keyboard as a
display with slightly weird placing of pixels.

Plus, I'd really like to play tetris on one of those :-).

So, would presenting them as auxdisplay be acceptable? Or are there
better options?

It sounds like a fair use case -- auxdisplay are typically simple
character-based or small graphical displays, e.g. 128x64, that may not
be a "main" / usual screen as typically understood, but the concept is
a bit fuzzy and we are a bit of a catch-all.

And "keyboard backlight display with a pixel/color per-key" does not
sound like a "main" screen, and having some cute effects displayed
there are the kind of thing that one could do in the usual small
graphical ones too. :)

But if somebody prefers to create new categories (or subcategories
within auxdisplay) to hold these, that could be nice too (in the
latter case, I would perhaps suggest reorganizing all of the existing
ones while at it).

One could also reasonably make the argument that controlling the
individual keyboard key backlights should be part of the input
subsystem. It's not a display per se. (Unless you actually have small
displays on the keycaps, and I think that's a thing too.)

While it would not be completely crazy to do that... I believe the
backlight is more of a display and less of a keyboard. Plus input
subystem is very far away from supporting this, and we had no input
from input people here.

I don't think LED subsystem is right place for this, and I believe
auxdisplay makes slightly more sense than input.

Unless someone steps up, I'd suggest Werner tries to implement this as
an auxdisplay. [And yes, this will not be simple task. RGB on LED is
different from RGB on display. But there are other LED displays, so
auxdisplay should handle this. Plus pixels are really funnily
shaped. But displays with missing pixels -- aka holes for camera --
are common in phones, and I believe we'll get variable pixel densities
-- less dense over camera -- too. So displays will have to deal with
these in the end.]


Another idea I want to throw in the mix:

Maybe the kernel is not the right place to implement this at all. RGB stuff is 
not at all standardized and every vendor is doing completely different 
interfaces, which does not fit the kernel userpsace apis desire to be uniformal 
and fixed. e.g. Auxdisplay might fit static setting of RGB values, but it does 
not fit the snake-effect mode, or the raindrops mode, or the 
4-different-colors-in-the-edges-breathing-and-color-cycling mode.


So my current idea: Implement these keyboards as a single zone RGB kbd_backlight 
in the leds interface to have something functional out of the box, but make it 
runtime disable-able if something like 
https://gitlab.com/CalcProgrammer1/OpenRGB wants to take over more fine granular 
control from userspace via hidraw.


Kind regards,

Werner



Best regards,
Pavel

Re: [PATCH v6 6/6] usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE

[Dmitry Baryshkov]

On Tue, 21 Nov 2023 at 12:46, Bryan O'Donoghue
 wrote:
>
> On 03/11/2023 23:03, Dmitry Baryshkov wrote:
> > Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the
> > same functionality for the DRM bridge chain termination.
> >
> > Signed-off-by: Dmitry Baryshkov 
>
> > + bridge_dev = drm_dp_hpd_bridge_register(tcpm->dev, 
> > to_of_node(tcpm->tcpc.fwnode));
> > + if (IS_ERR(bridge_dev))
> > + return PTR_ERR(bridge_dev);
> > +
>
> What is the effect if we never attach any bridged devices ?
>
> We make an aux device that just hangs around and eventually get cleaned
> up on release ? That's the way I read this code anyway.

Yes. That's the point, to untangle the USB code and the DRM bridge.

> Acked-by: Bryan O'Donoghue 


-- 
With best wishes
Dmitry

Re: [PATCH] drm/mediatek: dp: Add phy_mtk_dp module as pre-dependency

[AngeloGioacchino Del Regno]

Il 20/11/23 21:28, Nícolas F. R. A. Prado ha scritto:

The mtk_dp driver registers a phy device which is handled by the
phy_mtk_dp driver and assumes that the phy probe will complete
synchronously, proceeding to make use of functionality exposed by that
driver right away. This assumption however is false when the phy driver
is built as a module, causing the mtk_dp driver to fail probe in this
case.

Add the phy_mtk_dp module as a pre-dependency to the mtk_dp module to
ensure the phy module has been loaded before the dp, so that the phy
probe happens synchrounously and the mtk_dp driver can probe
successfully even with the phy driver built as a module.



You forgot a Suggested-by here :-P


Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Signed-off-by: Nícolas F. R. A. Prado 


It's fine anyway; being the best solution that we can use:

Reviewed-by: AngeloGioacchino Del Regno 




---

  drivers/gpu/drm/mediatek/mtk_dp.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c 
b/drivers/gpu/drm/mediatek/mtk_dp.c
index e4c16ba9902d..2136a596efa1 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -2818,3 +2818,4 @@ MODULE_AUTHOR("Markus Schneider-Pargmann 
");
  MODULE_AUTHOR("Bo-Chen Chen ");
  MODULE_DESCRIPTION("MediaTek DisplayPort Driver");
  MODULE_LICENSE("GPL");
+MODULE_SOFTDEP("pre: phy_mtk_dp");

Re: [PATCH] drm/bridge: imx93-mipi-dsi: Fix a couple of building warnings

[Maxime Ripard]

On Tue, Nov 21, 2023 at 04:56:44PM +0800, Liu Ying wrote:
> Fix a couple of building warnings on used uninitialized 'best_m' and
> 'best_n' local variables by initializing them to zero.  This makes compiler
> happy only.  No functional change.
> 
> Fixes: ce62f8ea7e3f ("drm/bridge: imx: Add i.MX93 MIPI DSI support")
> Reported-by: kernel test robot 
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202311151746.f7u7dzbz-...@intel.com/
> Signed-off-by: Liu Ying 
> ---
>  drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
> index 3ff30ce80c5b..7b3b4f985098 100644
> --- a/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/imx/imx93-mipi-dsi.c
> @@ -226,8 +226,8 @@ dphy_pll_get_configure_from_opts(struct imx93_dsi *dsi,
>   unsigned long fout;
>   unsigned long best_fout = 0;
>   unsigned int fvco_div;
> - unsigned int min_n, max_n, n, best_n;
> - unsigned long m, best_m;
> + unsigned int min_n, max_n, n, best_n = 0;
> + unsigned long m, best_m = 0;
>   unsigned long min_delta = ULONG_MAX;
>   unsigned long delta;
>   u64 tmp;

N is a divider, so it would probably be better to initialize it to
UINT_MAX to avoid any divide-by-0 error.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 0/4] drm/i915: Fix LUT rounding

[Maxime Ripard]

On Mon, Nov 20, 2023 at 04:30:53PM +0200, Ville Syrjälä wrote:
> On Fri, Oct 13, 2023 at 04:13:58PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > The current LUT rounding is generating weird results. Adjust
> > it to follow the OpenGL int<->float conversion rules.
> > 
> > Ville Syrjälä (4):
> >   drm: Fix color LUT rounding
> ^
> I'd like to merge this via drm-intel-next as needs to match
> the rounding done in the readout path in i915.
> 
> Maarten,Maxime,Thomas can I get an ack for that?

Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v6 6/6] usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE

[Bryan O'Donoghue]

On 03/11/2023 23:03, Dmitry Baryshkov wrote:

Use the freshly defined DRM_AUX_HPD_BRIDGE instead of open-coding the
same functionality for the DRM bridge chain termination.

Signed-off-by: Dmitry Baryshkov 



+   bridge_dev = drm_dp_hpd_bridge_register(tcpm->dev, 
to_of_node(tcpm->tcpc.fwnode));
+   if (IS_ERR(bridge_dev))
+   return PTR_ERR(bridge_dev);
+


What is the effect if we never attach any bridged devices ?

We make an aux device that just hangs around and eventually get cleaned 
up on release ? That's the way I read this code anyway.


Acked-by: Bryan O'Donoghue 

[PATCH v5] Documentation/gpu: VM_BIND locking document

[Thomas Hellström]

Add the first version of the VM_BIND locking document which is
intended to be part of the xe driver upstreaming agreement.

The document describes and discuss the locking used during exec-
functions, evicton and for userptr gpu-vmas. Intention is to be using the
same nomenclature as the drm-vm-bind-async.rst.

v2:
- s/gvm/gpu_vm/g (Rodrigo Vivi)
- Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c
  (Rodrigo Vivi)
- Adjust commit message accordingly.
- Add SPDX license header.

v3:
- Large update to align with the drm_gpuvm manager locking
- Add "Efficient userptr gpu_vma exec function iteration" section
- Add "Locking at bind- and unbind time" section.

v4:
- Fix tabs vs space errors by untabifying (Rodrigo Vivi)
- Minor style fixes and typos (Rodrigo Vivi)
- Clarify situations where stale GPU mappings are occurring and how
  access through these mappings are blocked. (Rodrigo Vivi)
- Insert into the toctree in implementation_guidelines.rst

v5:
- Add a section about recoverable page-faults.
- Use local references to other documentation where possible
  (Bagas Sanjaya)
- General documentation fixes and typos (Danilo Krummrich and
  Boris Brezillon)
- Improve the documentation around locks that need to be grabbed from the
  dm-fence critical section (Boris Brezillon)
- Add more references to the DRM GPUVM helpers (Danilo Krummrich and
  Boriz Brezillon)
- Update the rfc/xe.rst document.

Cc: Rodrigo Vivi 
Signed-off-by: Thomas Hellström 
---
 Documentation/core-api/pin_user_pages.rst |   2 +
 Documentation/gpu/drm-mm.rst  |   4 +
 Documentation/gpu/drm-vm-bind-locking.rst | 579 ++
 .../gpu/implementation_guidelines.rst |   1 +
 Documentation/gpu/rfc/xe.rst  |   5 +
 5 files changed, 591 insertions(+)
 create mode 100644 Documentation/gpu/drm-vm-bind-locking.rst

diff --git a/Documentation/core-api/pin_user_pages.rst 
b/Documentation/core-api/pin_user_pages.rst
index d3c1f6d8c0e0..6b5f7e6e7155 100644
--- a/Documentation/core-api/pin_user_pages.rst
+++ b/Documentation/core-api/pin_user_pages.rst
@@ -153,6 +153,8 @@ NOTE: Some pages, such as DAX pages, cannot be pinned with 
longterm pins. That's
 because DAX pages do not have a separate page cache, and so "pinning" implies
 locking down file system blocks, which is not (yet) supported in that way.
 
+.. _mmu-notifier-registration-case:
+
 CASE 3: MMU notifier registration, with or without page faulting hardware
 -
 Device drivers can pin pages via get_user_pages*(), and register for mmu
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index acc5901ac840..d55751cad67c 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -466,6 +466,8 @@ DRM MM Range Allocator Function References
 .. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
 
+.. _drm_gpuvm:
+
 DRM GPUVM
 =
 
@@ -481,6 +483,8 @@ Split and Merge
 .. kernel-doc:: drivers/gpu/drm/drm_gpuvm.c
:doc: Split and Merge
 
+.. _drm_gpuvm_locking:
+
 Locking
 ---
 
diff --git a/Documentation/gpu/drm-vm-bind-locking.rst 
b/Documentation/gpu/drm-vm-bind-locking.rst
new file mode 100644
index ..a7d08eccd50e
--- /dev/null
+++ b/Documentation/gpu/drm-vm-bind-locking.rst
@@ -0,0 +1,579 @@
+.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+===
+VM_BIND locking
+===
+
+This document attempts to describe what's needed to get VM_BIND locking right,
+including the userptr mmu_notifier locking and it also discusses some
+optimizations to get rid of the looping through of all userptr mappings and
+external / shared object mappings that is needed in the simplest
+implementation. In addition there is a section describing the VM_BIND locking
+required for implementing recoverable pagefaults.
+
+The DRM GPUVM set of helpers
+
+
+There is a set of helpers for drivers implementing VM_BIND, and this
+set of helpers implements much, but not all of the locking described
+in this document. In particular it is currently lacking a userptr
+implementation. Please refer to the :ref:`DRM GPUVM documentation
+`. This document does not intend to describe the DRM GPUVM
+implementation in detail, but in some places uses it as an
+implementation example. It is highly recommended for any driver
+implementing VM_BIND to use the DRM GPUVM helpers and to extend it if
+common functionality is missing.
+
+Nomenclature
+
+
+* ``Context``: GPU execution context.
+* ``gpu_vm``: Abstraction of a virtual GPU address space with
+  meta-data. Typically one per client (DRM file-private), or one per
+  context.
+* ``gpu_vma``: Abstraction of a GPU address range within a gpu_vm with
+  associated meta-data. The backing storage of a gpu_vma can either be
+  a GEM object or anonymous pages mapped also into the CPU
+  address space for the process.
+* ``gpu_vm_bo``: Abstracts 

Re: [rft, PATCH v4 00/16] drm/i915/dsi: 4th attempt to get rid of IOSF GPIO

[Jani Nikula]

On Fri, 17 Nov 2023, Andy Shevchenko  wrote:
> On Thu, Nov 16, 2023 at 12:15:03PM +0200, Jani Nikula wrote:
>> On Thu, 16 Nov 2023, Hans de Goede  wrote:
>> > Ok, this now has been testen on both a BYT and a CHT device which
>> > actually use GPIO controls in their MIPI sequences so this
>> > series is:
>> >
>> > Tested-by: Hans de Goede 
>> >
>> > And the code of the entire series also looks good to me:
>> >
>> > Reviewed-by: Hans de Goede 
>> >
>> > for the series.
>> 
>> Thanks Andy & Hans!
>> 
>> I'll merge this once the test results are in. The BAT results have been
>> a bit flaky recently, so needed to do a rerun.
>> 
>> That said, I'm not sure if we have any hardware in CI that would
>> actually exercise the modifications, so in that sense I trust Hans'
>> testing much more.
>
> Thank you!
> Should I fix checkpatch warnings CI reported about?

Nah, they're benign.

BR,
Jani.

-- 
Jani Nikula, Intel

Re: drm scheduler redesign causes deadlocks [extended repost]

[Bert Karwatzki]

Am Dienstag, dem 21.11.2023 um 11:22 +0200 schrieb Jani Nikula:
> On Tue, 21 Nov 2023, Bert Karwatzki  wrote:
> > As this simple patch fixes the problem
>
> Please use git send-email to send patches. Evolution botched up the
> whitespace here.
>
> BR,
> Jani.
>
>

Noted (actually not the first time evolution has done this). But I'm not
resending the patches here because they are not meant as actual fixes, they only
serve to illustrate the problem, the cause of which is not known, yet.

Bert Karwatzki

Re: [PATCH v7 1/8] drm/ttm/tests: Add tests for ttm_resource and ttm_sys_man

[Christian König]

Am 17.11.23 um 09:49 schrieb Karolina Stolarek:

Test initialization of ttm_resource using different memory domains.
Add tests for a system memory manager and functions that can be
tested without a fully-featured resource manager. Update
ttm_bo_kunit_init() to initialize BO's kref and a genuine GEM drm
object. Export ttm_resource_alloc for test purposes only.

Signed-off-by: Karolina Stolarek 
Tested-by: Amaranath Somalapuram 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/ttm/tests/Makefile|   1 +
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  22 +-
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   3 +
  drivers/gpu/drm/ttm/tests/ttm_resource_test.c | 335 ++
  drivers/gpu/drm/ttm/ttm_resource.c|   3 +
  5 files changed, 363 insertions(+), 1 deletion(-)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_resource_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index ec87c4fc1ad5..c92fe2052ef6 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -3,4 +3,5 @@
  obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
  ttm_device_test.o \
  ttm_pool_test.o \
+ttm_resource_test.o \
  ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index 81661d8827aa..779fbc038f17 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -29,19 +29,39 @@ struct ttm_buffer_object *ttm_bo_kunit_init(struct kunit 
*test,
struct ttm_test_devices *devs,
size_t size)
  {
-   struct drm_gem_object gem_obj = { .size = size };
+   struct drm_gem_object gem_obj = { };
struct ttm_buffer_object *bo;
+   int err;
  
  	bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);

KUNIT_ASSERT_NOT_NULL(test, bo);
  
  	bo->base = gem_obj;

+   err = drm_gem_object_init(devs->drm, >base, size);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
bo->bdev = devs->ttm_dev;
+   kref_init(>kref);
  
  	return bo;

  }
  EXPORT_SYMBOL_GPL(ttm_bo_kunit_init);
  
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,

+  uint32_t mem_type, uint32_t flags)
+{
+   struct ttm_place *place;
+
+   place = kunit_kzalloc(test, sizeof(*place), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, place);
+
+   place->mem_type = mem_type;
+   place->flags = flags;
+
+   return place;
+}
+EXPORT_SYMBOL_GPL(ttm_place_kunit_init);
+
  struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test)
  {
struct ttm_test_devices *devs;
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index e261e3660d0b..2f51c833a536 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -8,6 +8,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include 

  #include 
@@ -28,6 +29,8 @@ int ttm_device_kunit_init(struct ttm_test_devices *priv,
  struct ttm_buffer_object *ttm_bo_kunit_init(struct kunit *test,
struct ttm_test_devices *devs,
size_t size);
+struct ttm_place *ttm_place_kunit_init(struct kunit *test,
+  uint32_t mem_type, uint32_t flags);
  
  struct ttm_test_devices *ttm_test_devices_basic(struct kunit *test);

  struct ttm_test_devices *ttm_test_devices_all(struct kunit *test);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_resource_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
new file mode 100644
index ..029e1f094bb0
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_resource_test.c
@@ -0,0 +1,335 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+#define RES_SIZE   SZ_4K
+#define TTM_PRIV_DUMMY_REG (TTM_NUM_MEM_TYPES - 1)
+
+struct ttm_resource_test_case {
+   const char *description;
+   uint32_t mem_type;
+   uint32_t flags;
+};
+
+struct ttm_resource_test_priv {
+   struct ttm_test_devices *devs;
+   struct ttm_buffer_object *bo;
+   struct ttm_place *place;
+};
+
+static const struct ttm_resource_manager_func ttm_resource_manager_mock_funcs 
= { };
+
+static int ttm_resource_test_init(struct kunit *test)
+{
+   struct ttm_resource_test_priv *priv;
+
+   priv = kunit_kzalloc(test, sizeof(*priv), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, priv);
+
+   priv->devs = ttm_test_devices_all(test);
+   KUNIT_ASSERT_NOT_NULL(test, priv->devs);
+
+   test->priv = priv;
+
+   return 0;
+}
+
+static void ttm_resource_test_fini(struct kunit *test)
+{
+   struct ttm_resource_test_priv *priv = 

Re: [PATCH v6] drm/mediatek: add dma buffer control for drm plane disable

[胡俊光]

Re: drm scheduler redesign causes deadlocks [extended repost]

[Jani Nikula]

On Tue, 21 Nov 2023, Bert Karwatzki  wrote:
> As this simple patch fixes the problem

Please use git send-email to send patches. Evolution botched up the
whitespace here.

BR,
Jani.


-- 
Jani Nikula, Intel

Re: [PATCH V2] drm/modes: Fix divide error in drm_mode_debug_printmodeline

[Jani Nikula]

On Mon, 20 Nov 2023, Ville Syrjälä  wrote:
> On Mon, Nov 20, 2023 at 10:41:18PM +0800, Edward Adam Davis wrote:
>> [Syz Log]
>> divide error:  [#1] PREEMPT SMP KASAN
>> CPU: 0 PID: 5068 Comm: syz-executor357 Not tainted 
>> 6.6.0-syzkaller-16039-gac347a0655db #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
>> Google 10/09/2023
>> RIP: 0010:drm_mode_vrefresh drivers/gpu/drm/drm_modes.c:1303 [inline]
>> RIP: 0010:drm_mode_debug_printmodeline+0x118/0x4e0 
>> drivers/gpu/drm/drm_modes.c:60
>> Code: 00 41 0f b7 07 66 83 f8 02 b9 01 00 00 00 0f 43 c8 0f b7 c1 0f af e8 
>> 44 89 f0 48 69 c8 e8 03 00 00 89 e8 d1 e8 48 01 c8 31 d2 <48> f7 f5 49 89 c6 
>> eb 0c e8 fb 07 66 fc eb 05 e8 f4 07 66 fc 48 89
>> RSP: 0018:c9000391f8d0 EFLAGS: 00010246
>> RAX: 0001f400 RBX: 888025045000 RCX: 0001f400
>> RDX:  RSI: 8000 RDI: 888025045018
>> RBP:  R08: 8528b9af R09: 
>> R10: c9000391f8a0 R11: f52000723f17 R12: 0080
>> R13: dc00 R14: 0080 R15: 888025045016
>> FS:  56932380() GS:8880b980() knlGS:
>> CS:  0010 DS:  ES:  CR0: 80050033
>> CR2: 005fdeb8 CR3: 7fcff000 CR4: 003506f0
>> DR0:  DR1:  DR2: 
>> DR3:  DR6: fffe0ff0 DR7: 0400
>> Call Trace:
>>  
>>  drm_mode_setcrtc+0x83b/0x1880 drivers/gpu/drm/drm_crtc.c:794
>>  drm_ioctl_kernel+0x362/0x500 drivers/gpu/drm/drm_ioctl.c:792
>>  drm_ioctl+0x636/0xb00 drivers/gpu/drm/drm_ioctl.c:895
>>  vfs_ioctl fs/ioctl.c:51 [inline]
>>  __do_sys_ioctl fs/ioctl.c:871 [inline]
>>  __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:857
>>  do_syscall_x64 arch/x86/entry/common.c:51 [inline]
>>  do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
>>  entry_SYSCALL_64_after_hwframe+0x63/0x6b
>> 
>> [Analysis]
>> When calculating den in drm_mode_vrefresh(), if the vscan value is too 
>> large, 
>> there is a probability of unsigned integer overflow.
>> 
>> [Fix]
>> Before multiplying by vscan, first check if their product will overflow. 
>> If overflow occurs, return 0 and exit the subsequent process.
>> 
>> Reported-and-tested-by: syzbot+2e93e6fb36e6fdc56...@syzkaller.appspotmail.com
>> Fixes: ea40d7857d52 ("drm/vkms: fbdev emulation support")
>> Signed-off-by: Edward Adam Davis 
>> ---
>>  drivers/gpu/drm/drm_modes.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index ac9a406250c5..60739d861da2 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -36,6 +36,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  #include 
>> @@ -1297,8 +1298,10 @@ int drm_mode_vrefresh(const struct drm_display_mode 
>> *mode)
>>  num *= 2;
>>  if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
>>  den *= 2;
>> -if (mode->vscan > 1)
>> -den *= mode->vscan;
>> +if (mode->vscan > 1) {
>> +if (unlikely(check_mul_overflow(den, mode->vscan, )))
>> +return 0;
>> +}
>
> I can't see any driver that actually supports vscan>1. Only
> nouveau has some code for it, but doesn't look like it does
> anything sensible. All other drivers for sure should be
> rejecting vscan>1 outright. Which driver is this?
>
> Is there an actual usecase where nouveau needs this (and does
> it even work?) or could we just rip out the whole thing and
> reject vscan>1 globally?

I thought the whole thing seemed familiar [1].

BR,
Jani.



[1] https://lore.kernel.org/r/20230802174746.2256-1-astraj...@yahoo.com


>
>>  
>>  return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
>>  }
>> -- 
>> 2.25.1

-- 
Jani Nikula, Intel