[PATCH] drm/amd: Fix renoir/green sardine MP0 IP version detection

[Mario Limonciello]

The existing codebase never had a case for detecting MP0 version on
Renoir and instead relied upon hardcoded chip name.  This was missed as
part of the changes to migrate all IP blocks to build filenames from
`amdgpu_ucode.c`.

Consequently, Renoir tries to fetch a binary with 11_0_3 in the filename
and since it's supposed to have "renoir" in the filename fails to probe.
The fbdev still works though so the series worked.

Add a case for Renoir into the legacy table to ensure the right ASD and
TA firmware load again.

Reported-by: Ekene Akuneme 
Reported-by: Nicholas Choi 
Cc: Alex Hung 
Fixes: 994a97447e38 ("drm/amd: Parse both v1 and v2 TA microcode headers using 
same function")
Fixes: 54a3e032340e ("drm/amd: Add a legacy mapping to 
"amdgpu_ucode_ip_version_decode")
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 47549d659d9b0..c03824d0311bd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -1087,6 +1087,8 @@ static const char *amdgpu_ucode_legacy_naming(struct 
amdgpu_device *adev, int bl
return "navi10";
case IP_VERSION(11, 0, 2):
return "vega20";
+   case IP_VERSION(11, 0, 3):
+   return "renoir";
case IP_VERSION(11, 0, 4):
return "arcturus";
case IP_VERSION(11, 0, 5):
@@ -1104,12 +1106,7 @@ static const char *amdgpu_ucode_legacy_naming(struct 
amdgpu_device *adev, int bl
case IP_VERSION(11, 5, 0):
return "vangogh";
case IP_VERSION(12, 0, 1):
-   if (adev->asic_type == CHIP_RENOIR) {
-   if (adev->apu_flags & AMD_APU_IS_RENOIR)
-   return "renoir";
-   return "green_sardine";
-   }
-   break;
+   return "green_sardine";
case IP_VERSION(13, 0, 2):
return "aldebaran";
case IP_VERSION(13, 0, 1):
-- 
2.34.1

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

[Marek Olšák]

Valve would like this in kernel 6.2, but if put it there, we also need to
backport INFO ioctl changes for DRM driver version 3.50.0.

Marek

On Fri, Jan 13, 2023 at 6:33 PM Marek Olšák  wrote:

> There is no hole on 32-bit unfortunately. It looks like the hole on 64-bit
> is now ABI.
>
> I moved the field to replace _pad1. The patch is attached (with your Rb).
>
> Marek
>
> On Fri, Jan 13, 2023 at 4:20 PM Alex Deucher 
> wrote:
>
>> On Fri, Jan 13, 2023 at 4:02 PM Marek Olšák  wrote:
>> >
>> > i've added the comments and indeed pahole shows the hole as expected.
>>
>> What about on 32-bit?
>>
>> Alex
>>
>> >
>> > Marek
>> >
>> > On Thu, Jan 12, 2023 at 11:44 AM Alex Deucher 
>> wrote:
>> >>
>> >> On Thu, Jan 12, 2023 at 6:50 AM Christian König
>> >>  wrote:
>> >> >
>> >> > Am 11.01.23 um 21:48 schrieb Alex Deucher:
>> >> > > On Wed, Jan 4, 2023 at 3:17 PM Marek Olšák 
>> wrote:
>> >> > >> Yes, it's meant to be like a spec sheet. We are not interested in
>> the current bandwidth utilization.
>> >> > > After chatting with Marek on IRC and thinking about this more, I
>> think
>> >> > > this patch is fine.  It's not really meant for bandwidth per se,
>> but
>> >> > > rather as a limit to determine what the driver should do in certain
>> >> > > cases (i.e., when does it make sense to copy to vram vs not).  It's
>> >> > > not straightforward for userspace to parse the full topology to
>> >> > > determine what links may be slow.  I guess one potential pitfall
>> would
>> >> > > be that if you pass the device into a VM, the driver may report the
>> >> > > wrong values.  Generally in a VM the VM doesn't get the full view
>> up
>> >> > > to the root port.  I don't know if the hypervisors report properly
>> for
>> >> > > pcie_bandwidth_available() in a VM or if it just shows the info
>> about
>> >> > > the endpoint in the VM.
>> >> >
>> >> > So this basically doesn't return the gen and lanes of the device, but
>> >> > rather what was negotiated between the device and the upstream root
>> port?
>> >>
>> >> Correct. It exposes the max gen and lanes of the slowest link between
>> >> the device and the root port.
>> >>
>> >> >
>> >> > If I got that correctly then we should probably document that cause
>> >> > otherwise somebody will try to "fix" it at some time.
>> >>
>> >> Good point.
>> >>
>> >> Alex
>> >>
>> >> >
>> >> > Christian.
>> >> >
>> >> > >
>> >> > > Reviewed-by: Alex Deucher 
>> >> > >
>> >> > > Alex
>> >> > >
>> >> > >> Marek
>> >> > >>
>> >> > >> On Wed, Jan 4, 2023 at 10:33 AM Lazar, Lijo 
>> wrote:
>> >> > >>> [AMD Official Use Only - General]
>> >> > >>>
>> >> > >>>
>> >> > >>> To clarify, with DPM in place, the current bandwidth will be
>> changing based on the load.
>> >> > >>>
>> >> > >>> If apps/umd already has a way to know the current bandwidth
>> utilisation, then possible maximum also could be part of the same API.
>> Otherwise, this only looks like duplicate information. We have the same
>> information in sysfs DPM nodes.
>> >> > >>>
>> >> > >>> BTW, I don't know to what extent app/umd really makes use of
>> this. Take that memory frequency as an example (I'm reading it as 16GHz).
>> It only looks like a spec sheet.
>> >> > >>>
>> >> > >>> Thanks,
>> >> > >>> Lijo
>> >> > >>> 
>> >> > >>> From: Marek Olšák 
>> >> > >>> Sent: Wednesday, January 4, 2023 8:40:00 PM
>> >> > >>> To: Lazar, Lijo 
>> >> > >>> Cc: amd-gfx@lists.freedesktop.org > >
>> >> > >>> Subject: Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and
>> lanes from the INFO
>> >> > >>>
>> >> > >>> On Wed, Jan 4, 2023 at 9:19 AM Lazar, Lijo 
>> wrote:
>> >> > >>>
>> >> > >>>
>> >> > >>>
>> >> > >>> On 1/4/2023 7:43 PM, Marek Olšák wrote:
>> >> >  On Wed, Jan 4, 2023 at 6:50 AM Lazar, Lijo > >> >  > wrote:
>> >> > 
>> >> > 
>> >> > 
>> >> >   On 1/4/2023 4:11 AM, Marek Olšák wrote:
>> >> >    > I see. Well, those sysfs files are not usable, and I
>> don't think it
>> >> >    > would be important even if they were usable, but for
>> completeness:
>> >> >    >
>> >> >    > The ioctl returns:
>> >> >    >  pcie_gen = 1
>> >> >    >  pcie_num_lanes = 16
>> >> >    >
>> >> >    > Theoretical bandwidth from those values: 4.0 GB/s
>> >> >    > My DMA test shows this write bandwidth: 3.5 GB/s
>> >> >    > It matches the expectation.
>> >> >    >
>> >> >    > Let's see the devices (there is only 1 GPU Navi21 in
>> the system):
>> >> >    > $ lspci |egrep '(PCI|VGA).*Navi'
>> >> >    > 0a:00.0 PCI bridge: Advanced Micro Devices, Inc.
>> [AMD/ATI] Navi
>> >> >   10 XL
>> >> >    > Upstream Port of PCI Express Switch (rev c3)
>> >> >    > 0b:00.0 PCI bridge: Advanced Micro Devices, Inc.
>> [AMD/ATI] Navi
>> >> >   10 XL
>> >> >    > Downstream Port of PCI Express Switch
>> >> >    > 0c:00.0 VGA 

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

[Marek Olšák]

There is no hole on 32-bit unfortunately. It looks like the hole on 64-bit
is now ABI.

I moved the field to replace _pad1. The patch is attached (with your Rb).

Marek

On Fri, Jan 13, 2023 at 4:20 PM Alex Deucher  wrote:

> On Fri, Jan 13, 2023 at 4:02 PM Marek Olšák  wrote:
> >
> > i've added the comments and indeed pahole shows the hole as expected.
>
> What about on 32-bit?
>
> Alex
>
> >
> > Marek
> >
> > On Thu, Jan 12, 2023 at 11:44 AM Alex Deucher 
> wrote:
> >>
> >> On Thu, Jan 12, 2023 at 6:50 AM Christian König
> >>  wrote:
> >> >
> >> > Am 11.01.23 um 21:48 schrieb Alex Deucher:
> >> > > On Wed, Jan 4, 2023 at 3:17 PM Marek Olšák 
> wrote:
> >> > >> Yes, it's meant to be like a spec sheet. We are not interested in
> the current bandwidth utilization.
> >> > > After chatting with Marek on IRC and thinking about this more, I
> think
> >> > > this patch is fine.  It's not really meant for bandwidth per se, but
> >> > > rather as a limit to determine what the driver should do in certain
> >> > > cases (i.e., when does it make sense to copy to vram vs not).  It's
> >> > > not straightforward for userspace to parse the full topology to
> >> > > determine what links may be slow.  I guess one potential pitfall
> would
> >> > > be that if you pass the device into a VM, the driver may report the
> >> > > wrong values.  Generally in a VM the VM doesn't get the full view up
> >> > > to the root port.  I don't know if the hypervisors report properly
> for
> >> > > pcie_bandwidth_available() in a VM or if it just shows the info
> about
> >> > > the endpoint in the VM.
> >> >
> >> > So this basically doesn't return the gen and lanes of the device, but
> >> > rather what was negotiated between the device and the upstream root
> port?
> >>
> >> Correct. It exposes the max gen and lanes of the slowest link between
> >> the device and the root port.
> >>
> >> >
> >> > If I got that correctly then we should probably document that cause
> >> > otherwise somebody will try to "fix" it at some time.
> >>
> >> Good point.
> >>
> >> Alex
> >>
> >> >
> >> > Christian.
> >> >
> >> > >
> >> > > Reviewed-by: Alex Deucher 
> >> > >
> >> > > Alex
> >> > >
> >> > >> Marek
> >> > >>
> >> > >> On Wed, Jan 4, 2023 at 10:33 AM Lazar, Lijo 
> wrote:
> >> > >>> [AMD Official Use Only - General]
> >> > >>>
> >> > >>>
> >> > >>> To clarify, with DPM in place, the current bandwidth will be
> changing based on the load.
> >> > >>>
> >> > >>> If apps/umd already has a way to know the current bandwidth
> utilisation, then possible maximum also could be part of the same API.
> Otherwise, this only looks like duplicate information. We have the same
> information in sysfs DPM nodes.
> >> > >>>
> >> > >>> BTW, I don't know to what extent app/umd really makes use of
> this. Take that memory frequency as an example (I'm reading it as 16GHz).
> It only looks like a spec sheet.
> >> > >>>
> >> > >>> Thanks,
> >> > >>> Lijo
> >> > >>> 
> >> > >>> From: Marek Olšák 
> >> > >>> Sent: Wednesday, January 4, 2023 8:40:00 PM
> >> > >>> To: Lazar, Lijo 
> >> > >>> Cc: amd-gfx@lists.freedesktop.org 
> >> > >>> Subject: Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and
> lanes from the INFO
> >> > >>>
> >> > >>> On Wed, Jan 4, 2023 at 9:19 AM Lazar, Lijo 
> wrote:
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> On 1/4/2023 7:43 PM, Marek Olšák wrote:
> >> >  On Wed, Jan 4, 2023 at 6:50 AM Lazar, Lijo  >> >  > wrote:
> >> > 
> >> > 
> >> > 
> >> >   On 1/4/2023 4:11 AM, Marek Olšák wrote:
> >> >    > I see. Well, those sysfs files are not usable, and I
> don't think it
> >> >    > would be important even if they were usable, but for
> completeness:
> >> >    >
> >> >    > The ioctl returns:
> >> >    >  pcie_gen = 1
> >> >    >  pcie_num_lanes = 16
> >> >    >
> >> >    > Theoretical bandwidth from those values: 4.0 GB/s
> >> >    > My DMA test shows this write bandwidth: 3.5 GB/s
> >> >    > It matches the expectation.
> >> >    >
> >> >    > Let's see the devices (there is only 1 GPU Navi21 in the
> system):
> >> >    > $ lspci |egrep '(PCI|VGA).*Navi'
> >> >    > 0a:00.0 PCI bridge: Advanced Micro Devices, Inc.
> [AMD/ATI] Navi
> >> >   10 XL
> >> >    > Upstream Port of PCI Express Switch (rev c3)
> >> >    > 0b:00.0 PCI bridge: Advanced Micro Devices, Inc.
> [AMD/ATI] Navi
> >> >   10 XL
> >> >    > Downstream Port of PCI Express Switch
> >> >    > 0c:00.0 VGA compatible controller: Advanced Micro
> Devices, Inc.
> >> >    > [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT]
> (rev c3)
> >> >    >
> >> >    > Let's read sysfs:
> >> >    >
> >> >    > $ cat
> /sys/bus/pci/devices/:0a:00.0/current_link_width
> >> >    > 16
> >> >    > $ cat
> 

Re: [PATCH 1/6] drm/amdgpu: Generalize KFD dmabuf import

[Felix Kuehling]

On 2023-01-13 18:00, Chen, Xiaogang wrote:


On 1/13/2023 4:26 PM, Felix Kuehling wrote:

On 2023-01-12 17:41, Chen, Xiaogang wrote:


On 1/11/2023 7:31 PM, Felix Kuehling wrote:

Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.

Signed-off-by: Felix Kuehling 
---
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 38 
++-

  1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c

index 6f236ded5f12..e13c3493b786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2209,30 +2209,27 @@ int 
amdgpu_amdkfd_gpuvm_import_dmabuf(struct amdgpu_device *adev,

  struct amdgpu_bo *bo;
  int ret;
  -    if (dma_buf->ops != _dmabuf_ops)
-    /* Can't handle non-graphics buffers */
-    return -EINVAL;
-
-    obj = dma_buf->priv;
-    if (drm_to_adev(obj->dev) != adev)
-    /* Can't handle buffers from other devices */
-    return -EINVAL;
+    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 */
-    return -EINVAL;
+    ret = -EINVAL;
+    goto err_put_obj;
+    }
    *mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
-    if (!*mem)
-    return -ENOMEM;
+    if (!*mem) {
+    ret = -ENOMEM;
+    goto err_put_obj;
+    }
    ret = drm_vma_node_allow(>vma_node, drm_priv);
-    if (ret) {
-    kfree(*mem);
-    return ret;
-    }
+    if (ret)
+    goto err_free_mem;
    if (size)
  *size = amdgpu_bo_size(bo);


Hi Felix:

I have a question when using amdgpu_gem_prime_import. It will allow 
importing a dmabuf to different gpus, then can we still call 
amdgpu_bo_mmap_offset on the generated bo if 
amdgpu_amdkfd_gpuvm_import_dmabuf also ask mmap_offset?


The mmap  offset comes from drm_vma_node_offset_addr. The DRM VMA 
address is allocated when ttm_bo_init_reserved calls 
drm_vma_offset_add, so there should be no problem querying the 
mmap_offset. Whether mmapping of an imported BO is actually supported 
is a different question. As far as I can see, it should be possible. 
That said, currently ROCm (libhsakmt) uses only original BOs for CPU 
mappings, not imported BOs.


Regards,
  Felix


The mmap_offset is actually not returned to user space. I just wonder 
if here we should get mmap_offset of imported vram buffer if allow bo 
be imported to difference gpus. If a vram buffer is imported to same 
gpu device amdgpu_bo_mmap_offset is ok, otherwise I think 
amdgpu_bo_mmap_offset would not give correct mmap_offset for the 
device that the buffer is  imported to.


When the BO is imported into the same GPU, you get a reference to the 
same BO, so the imported BO has the same mmap_offset as the original BO.


When the BO is imported into a different GPU, it is a new BO with a new 
mmap_offset. I don't think this is incorrect. mmapping the memory with 
that new offset should still work. The imported BO is created with 
ttm_bo_type_sg, and AFAICT ttm_bo_vm.c supports mapping of SG BOs.


Regards,
  Felix




Maybe we should remove mmap_offset parameter of 
amdgpu_amdkfd_gpuvm_import_dmabuf since we do not return it to user 
space anyway. With that:


Reviewed-by: Xiaogang Chen 

Regards

Xiaogang







@@ -2249,7 +2246,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  | KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE
  | KFD_IOC_ALLOC_MEM_FLAGS_EXECUTABLE;
  -    drm_gem_object_get(>tbo.base);
+    get_dma_buf(dma_buf);
+    (*mem)->dmabuf = dma_buf;
  (*mem)->bo = bo;
  (*mem)->va = va;
  (*mem)->domain = (bo->preferred_domains & 
AMDGPU_GEM_DOMAIN_VRAM) ?
@@ -2261,6 +2259,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  (*mem)->is_imported = true;
    return 0;
+
+err_free_mem:
+    kfree(*mem);
+err_put_obj:
+    drm_gem_object_put(obj);
+    return ret;
  }
    /* Evict a userptr BO by stopping the queues if necessary

Re: [PATCH 1/6] drm/amdgpu: Generalize KFD dmabuf import

[Chen, Xiaogang]

On 1/13/2023 4:26 PM, Felix Kuehling wrote:

On 2023-01-12 17:41, Chen, Xiaogang wrote:


On 1/11/2023 7:31 PM, Felix Kuehling wrote:

Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.

Signed-off-by: Felix Kuehling 
---
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 38 
++-

  1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c

index 6f236ded5f12..e13c3493b786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2209,30 +2209,27 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  struct amdgpu_bo *bo;
  int ret;
  -    if (dma_buf->ops != _dmabuf_ops)
-    /* Can't handle non-graphics buffers */
-    return -EINVAL;
-
-    obj = dma_buf->priv;
-    if (drm_to_adev(obj->dev) != adev)
-    /* Can't handle buffers from other devices */
-    return -EINVAL;
+    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 */
-    return -EINVAL;
+    ret = -EINVAL;
+    goto err_put_obj;
+    }
    *mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
-    if (!*mem)
-    return -ENOMEM;
+    if (!*mem) {
+    ret = -ENOMEM;
+    goto err_put_obj;
+    }
    ret = drm_vma_node_allow(>vma_node, drm_priv);
-    if (ret) {
-    kfree(*mem);
-    return ret;
-    }
+    if (ret)
+    goto err_free_mem;
    if (size)
  *size = amdgpu_bo_size(bo);


Hi Felix:

I have a question when using amdgpu_gem_prime_import. It will allow 
importing a dmabuf to different gpus, then can we still call 
amdgpu_bo_mmap_offset on the generated bo if 
amdgpu_amdkfd_gpuvm_import_dmabuf also ask mmap_offset?


The mmap  offset comes from drm_vma_node_offset_addr. The DRM VMA 
address is allocated when ttm_bo_init_reserved calls 
drm_vma_offset_add, so there should be no problem querying the 
mmap_offset. Whether mmapping of an imported BO is actually supported 
is a different question. As far as I can see, it should be possible. 
That said, currently ROCm (libhsakmt) uses only original BOs for CPU 
mappings, not imported BOs.


Regards,
  Felix


The mmap_offset is actually not returned to user space. I just wonder if 
here we should get mmap_offset of imported vram buffer if allow bo be 
imported to difference gpus. If a vram buffer is imported to same gpu 
device amdgpu_bo_mmap_offset is ok, otherwise I think 
amdgpu_bo_mmap_offset would not give correct mmap_offset for the device 
that the buffer is  imported to.


Maybe we should remove mmap_offset parameter of 
amdgpu_amdkfd_gpuvm_import_dmabuf since we do not return it to user 
space anyway. With that:


Reviewed-by: Xiaogang Chen 

Regards

Xiaogang







@@ -2249,7 +2246,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  | KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE
  | KFD_IOC_ALLOC_MEM_FLAGS_EXECUTABLE;
  -    drm_gem_object_get(>tbo.base);
+    get_dma_buf(dma_buf);
+    (*mem)->dmabuf = dma_buf;
  (*mem)->bo = bo;
  (*mem)->va = va;
  (*mem)->domain = (bo->preferred_domains & 
AMDGPU_GEM_DOMAIN_VRAM) ?
@@ -2261,6 +2259,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  (*mem)->is_imported = true;
    return 0;
+
+err_free_mem:
+    kfree(*mem);
+err_put_obj:
+    drm_gem_object_put(obj);
+    return ret;
  }
    /* Evict a userptr BO by stopping the queues if necessary

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

[Alex Deucher]

Hi Dave, Daniel,

More new stuff for 6.3.

The following changes since commit f6e856e72ce51df1e0fe67aecb5f256fbd4190a6:

  drm/amdgpu: update ta_secureDisplay_if.h to v27.00.00.08 (2023-01-05 11:43:46 
-0500)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-next-6.3-2023-01-13

for you to fetch changes up to 0c2dece8fb541ab07b68c3312a1065fa9c927a81:

  drm/amdkfd: Page aligned memory reserve size (2023-01-11 16:41:03 -0500)


amd-drm-next-6.3-2023-01-13:

amdgpu:
- Fix possible segfault in failure case
- Rework FW requests to happen in early_init for all IPs so
  that we don't lose the sbios console if FW is missing
- PSR fixes
- Misc cleanups
- Unload fix
- SMU13 fixes

amdkfd:
- Fix for cleared VRAM BOs
- Fix cleanup if GPUVM creation fails
- Memory accounting fix
- Use resource_size rather than open codeing it
- GC11 mGPU fix

radeon:
- Fix memory leak on shutdown


Deepak R Varma (2):
  drm/amdkfd: Use resource_size() helper function
  drm/amd/display: No need for Null pointer check before kfree

Eric Huang (2):
  drm/amdkfd: Add sync after creating vram bo
  drm/amdkfd: Fix NULL pointer error for GC 11.0.1 on mGPU

Guchun Chen (1):
  drm/amd/pm/smu13: BACO is supported when it's in BACO state

Hamza Mahfooz (1):
  drm/amd/display: fix PSR-SU/DSC interoperability support

Liwei Song (1):
  drm/radeon: free iio for atombios when driver shutdown

Luben Tuikov (1):
  drm/amdgpu: Fix potential NULL dereference

Mario Limonciello (45):
  drm/amd: Delay removal of the firmware framebuffer
  drm/amd: Add a legacy mapping to "amdgpu_ucode_ip_version_decode"
  drm/amd: Convert SMUv11 microcode to use `amdgpu_ucode_ip_version_decode`
  drm/amd: Convert SMUv13 microcode to use `amdgpu_ucode_ip_version_decode`
  drm/amd: Add a new helper for loading/validating microcode
  drm/amd: Use `amdgpu_ucode_request` helper for SDMA
  drm/amd: Convert SDMA to use `amdgpu_ucode_ip_version_decode`
  drm/amd: Make SDMA firmware load failures less noisy.
  drm/amd: Use `amdgpu_ucode_*` helpers for VCN
  drm/amd: Load VCN microcode during early_init
  drm/amd: Load MES microcode during early_init
  drm/amd: Use `amdgpu_ucode_*` helpers for MES
  drm/amd: Remove superfluous assignment for `adev->mes.adev`
  drm/amd: Use `amdgpu_ucode_*` helpers for GFX9
  drm/amd: Load GFX9 microcode during early_init
  drm/amd: Use `amdgpu_ucode_*` helpers for GFX10
  drm/amd: Load GFX10 microcode during early_init
  drm/amd: Use `amdgpu_ucode_*` helpers for GFX11
  drm/amd: Load GFX11 microcode during early_init
  drm/amd: Parse both v1 and v2 TA microcode headers using same function
  drm/amd: Avoid BUG() for case of SRIOV missing IP version
  drm/amd: Load PSP microcode during early_init
  drm/amd: Use `amdgpu_ucode_*` helpers for PSP
  drm/amd/display: Load DMUB microcode during early_init
  drm/amd: Use `amdgpu_ucode_release` helper for DMUB
  drm/amd: Use `amdgpu_ucode_*` helpers for SMU
  drm/amd: Load SMU microcode during early_init
  drm/amd: Optimize SRIOV switch/case for PSP microcode load
  drm/amd: Use `amdgpu_ucode_*` helpers for GFX6
  drm/amd: Use `amdgpu_ucode_*` helpers for GFX7
  drm/amd: Use `amdgpu_ucode_*` helpers for GFX8
  drm/amd: Use `amdgpu_ucode_*` helpers for GMC6
  drm/amd: Use `amdgpu_ucode_*` helpers for GMC7
  drm/amd: Use `amdgpu_ucode_*` helpers for GMC8
  drm/amd: Use `amdgpu_ucode_*` helpers for SDMA2.4
  drm/amd: Use `amdgpu_ucode_*` helpers for SDMA3.0
  drm/amd: Use `amdgpu_ucode_*` helpers for SDMA on CIK
  drm/amd: Use `amdgpu_ucode_*` helpers for UVD
  drm/amd: Use `amdgpu_ucode_*` helpers for VCE
  drm/amd: Use `amdgpu_ucode_*` helpers for CGS
  drm/amd: Use `amdgpu_ucode_*` helpers for GPU info bin
  drm/amd: Use `amdgpu_ucode_*` helpers for DMCU
  drm/amd: Use `amdgpu_ucode_release` helper for powerplay
  drm/amd: Use `amdgpu_ucode_release` helper for si
  drm/amd: make amdgpu_ucode_validate static

Philip Yang (2):
  drm/amdkfd: Cleanup vm process info if init vm failed
  drm/amdkfd: Page aligned memory reserve size

Yang Li (2):
  drm/amd/display: Remove unneeded semicolon
  drm/amdgpu: clean up some inconsistent indentings

Yi Yang (1):
  drm/amd/display: Remove redundant assignment to variable dc

YiPeng Chai (1):
  drm/amdgpu: Fixed bug on error when unloading amdgpu

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c   |  32 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  11 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  22 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   6 -
 

Re: [PATCH 6/6] drm/amdgpu: Do bo_va ref counting for KFD BOs

[Chen, Xiaogang]

Reviewed-by: Xiaogang Chen 

Regards

Xiaogang

On 1/11/2023 7:31 PM, Felix Kuehling wrote:

This is needed to correctly handle BOs imported into the GEM API, which
would otherwise get added twice to the same VM.

Signed-off-by: Felix Kuehling 
---
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 28 +++
  1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index df08e84f01d7..8b5ba2e04a79 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -370,9 +370,17 @@ static int amdgpu_amdkfd_bo_validate_and_fence(struct 
amdgpu_bo *bo,
return ret;
  
  	ret = amdgpu_amdkfd_bo_validate(bo, domain, true);

-   if (!ret)
-   dma_resv_add_fence(bo->tbo.base.resv, fence,
-  DMA_RESV_USAGE_BOOKKEEP);
+   if (ret)
+   goto unreserve_out;
+
+   ret = dma_resv_reserve_fences(bo->tbo.base.resv, 1);
+   if (ret)
+   goto unreserve_out;
+
+   dma_resv_add_fence(bo->tbo.base.resv, fence,
+  DMA_RESV_USAGE_BOOKKEEP);
+
+unreserve_out:
amdgpu_bo_unreserve(bo);
  
  	return ret;

@@ -785,6 +793,7 @@ static int kfd_mem_attach(struct amdgpu_device *adev, 
struct kgd_mem *mem,
uint64_t va = mem->va;
struct kfd_mem_attachment *attachment[2] = {NULL, NULL};
struct amdgpu_bo *bo[2] = {NULL, NULL};
+   struct amdgpu_bo_va *bo_va;
bool same_hive = false;
int i, ret;
  
@@ -871,7 +880,12 @@ static int kfd_mem_attach(struct amdgpu_device *adev, struct kgd_mem *mem,

pr_debug("Unable to reserve BO during memory attach");
goto unwind;
}
-   attachment[i]->bo_va = amdgpu_vm_bo_add(adev, vm, bo[i]);
+   bo_va = amdgpu_vm_bo_find(vm, bo[i]);
+   if (!bo_va)
+   bo_va = amdgpu_vm_bo_add(adev, vm, bo[i]);
+   else
+   ++bo_va->ref_count;
+   attachment[i]->bo_va = bo_va;
amdgpu_bo_unreserve(bo[i]);
if (unlikely(!attachment[i]->bo_va)) {
ret = -ENOMEM;
@@ -895,7 +909,8 @@ static int kfd_mem_attach(struct amdgpu_device *adev, 
struct kgd_mem *mem,
continue;
if (attachment[i]->bo_va) {
amdgpu_bo_reserve(bo[i], true);
-   amdgpu_vm_bo_del(adev, attachment[i]->bo_va);
+   if (--attachment[i]->bo_va->ref_count == 0)
+   amdgpu_vm_bo_del(adev, attachment[i]->bo_va);
amdgpu_bo_unreserve(bo[i]);
list_del([i]->list);
}
@@ -912,7 +927,8 @@ static void kfd_mem_detach(struct kfd_mem_attachment 
*attachment)
  
  	pr_debug("\t remove VA 0x%llx in entry %p\n",

attachment->va, attachment);
-   amdgpu_vm_bo_del(attachment->adev, attachment->bo_va);
+   if (--attachment->bo_va->ref_count == 0)
+   amdgpu_vm_bo_del(attachment->adev, attachment->bo_va);
drm_gem_object_put(>tbo.base);
list_del(>list);
kfree(attachment);

Re: [PATCH 1/6] drm/amdgpu: Generalize KFD dmabuf import

[Felix Kuehling]

On 2023-01-12 17:41, Chen, Xiaogang wrote:


On 1/11/2023 7:31 PM, Felix Kuehling wrote:

Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.

Signed-off-by: Felix Kuehling 
---
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 38 ++-
  1 file changed, 21 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c

index 6f236ded5f12..e13c3493b786 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2209,30 +2209,27 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  struct amdgpu_bo *bo;
  int ret;
  -    if (dma_buf->ops != _dmabuf_ops)
-    /* Can't handle non-graphics buffers */
-    return -EINVAL;
-
-    obj = dma_buf->priv;
-    if (drm_to_adev(obj->dev) != adev)
-    /* Can't handle buffers from other devices */
-    return -EINVAL;
+    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 */
-    return -EINVAL;
+    ret = -EINVAL;
+    goto err_put_obj;
+    }
    *mem = kzalloc(sizeof(struct kgd_mem), GFP_KERNEL);
-    if (!*mem)
-    return -ENOMEM;
+    if (!*mem) {
+    ret = -ENOMEM;
+    goto err_put_obj;
+    }
    ret = drm_vma_node_allow(>vma_node, drm_priv);
-    if (ret) {
-    kfree(*mem);
-    return ret;
-    }
+    if (ret)
+    goto err_free_mem;
    if (size)
  *size = amdgpu_bo_size(bo);


Hi Felix:

I have a question when using amdgpu_gem_prime_import. It will allow 
importing a dmabuf to different gpus, then can we still call 
amdgpu_bo_mmap_offset on the generated bo if 
amdgpu_amdkfd_gpuvm_import_dmabuf also ask mmap_offset?


The mmap  offset comes from drm_vma_node_offset_addr. The DRM VMA 
address is allocated when ttm_bo_init_reserved calls drm_vma_offset_add, 
so there should be no problem querying the mmap_offset. Whether mmapping 
of an imported BO is actually supported is a different question. As far 
as I can see, it should be possible. That said, currently ROCm 
(libhsakmt) uses only original BOs for CPU mappings, not imported BOs.


Regards,
  Felix




@@ -2249,7 +2246,8 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  | KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE
  | KFD_IOC_ALLOC_MEM_FLAGS_EXECUTABLE;
  -    drm_gem_object_get(>tbo.base);
+    get_dma_buf(dma_buf);
+    (*mem)->dmabuf = dma_buf;
  (*mem)->bo = bo;
  (*mem)->va = va;
  (*mem)->domain = (bo->preferred_domains & 
AMDGPU_GEM_DOMAIN_VRAM) ?
@@ -2261,6 +2259,12 @@ int amdgpu_amdkfd_gpuvm_import_dmabuf(struct 
amdgpu_device *adev,

  (*mem)->is_imported = true;
    return 0;
+
+err_free_mem:
+    kfree(*mem);
+err_put_obj:
+    drm_gem_object_put(obj);
+    return ret;
  }
    /* Evict a userptr BO by stopping the queues if necessary

Re: [PATCH] drm/amdkfd: Support process XNACK mode dynamic change

[Felix Kuehling]

On 2023-01-12 16:18, Philip Yang wrote:

Update queue qpd is done for the first queue creation of the process,
if the device support XNACK mode per process, update qpd setup
sh_mem_config based on the process XNACK mode, to support the process
destory all queues, change XNACK mode, and then create queues.

Add helper macro KFD_SUPPORT_XNACK_PER_PROCESS to remove duplicate code
and add new ASICs support in future.

Signed-off-by: Philip Yang 


Reviewed-by: Felix Kuehling 



---
  .../amd/amdkfd/kfd_device_queue_manager_v9.c  | 27 +--
  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  2 ++
  drivers/gpu/drm/amd/amdkfd/kfd_process.c  |  2 +-
  3 files changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c
index d119070956fb..8b2dd2670ab7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager_v9.c
@@ -59,30 +59,27 @@ static int update_qpd_v9(struct device_queue_manager *dqm,
  
  	/* check if sh_mem_config register already configured */

if (qpd->sh_mem_config == 0) {
-   qpd->sh_mem_config =
-   SH_MEM_ALIGNMENT_MODE_UNALIGNED <<
+   qpd->sh_mem_config = SH_MEM_ALIGNMENT_MODE_UNALIGNED <<
SH_MEM_CONFIG__ALIGNMENT_MODE__SHIFT;
  
-		if (KFD_GC_VERSION(dqm->dev) == IP_VERSION(9, 4, 2)) {

-   /* Aldebaran can safely support different XNACK modes
-* per process
-*/
-   if (!pdd->process->xnack_enabled)
-   qpd->sh_mem_config |=
-   1 << 
SH_MEM_CONFIG__RETRY_DISABLE__SHIFT;
-   } else if (dqm->dev->noretry &&
-  !dqm->dev->use_iommu_v2) {
-   qpd->sh_mem_config |=
-   1 << SH_MEM_CONFIG__RETRY_DISABLE__SHIFT;
-   }
+   if (dqm->dev->noretry && !dqm->dev->use_iommu_v2)
+   qpd->sh_mem_config |= 1 << 
SH_MEM_CONFIG__RETRY_DISABLE__SHIFT;
  
  		qpd->sh_mem_ape1_limit = 0;

qpd->sh_mem_ape1_base = 0;
}
  
+	if (KFD_SUPPORT_XNACK_PER_PROCESS(dqm->dev)) {

+   if (!pdd->process->xnack_enabled)
+   qpd->sh_mem_config |= 1 << 
SH_MEM_CONFIG__RETRY_DISABLE__SHIFT;
+   else
+   qpd->sh_mem_config &= ~(1 << 
SH_MEM_CONFIG__RETRY_DISABLE__SHIFT);
+   }
+
qpd->sh_mem_bases = compute_sh_mem_bases_64bit(pdd);
  
-	pr_debug("sh_mem_bases 0x%X\n", qpd->sh_mem_bases);

+   pr_debug("sh_mem_bases 0x%X sh_mem_config 0x%X\n", qpd->sh_mem_bases,
+qpd->sh_mem_config);
  
  	return 0;

  }
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 552c3ac85a13..bfa30d12406b 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -206,6 +206,8 @@ enum cache_policy {
  
  #define KFD_GC_VERSION(dev) ((dev)->adev->ip_versions[GC_HWIP][0])

  #define KFD_IS_SOC15(dev)   ((KFD_GC_VERSION(dev)) >= (IP_VERSION(9, 0, 1)))
+#define KFD_SUPPORT_XNACK_PER_PROCESS(dev)\
+   (KFD_GC_VERSION(dev) == IP_VERSION(9, 4, 2))
  
  struct kfd_event_interrupt_class {

bool (*interrupt_isr)(struct kfd_dev *dev,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 71db24fefe05..72df6286e240 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -1330,7 +1330,7 @@ bool kfd_process_xnack_mode(struct kfd_process *p, bool 
supported)
 * per-process XNACK mode selection. But let the dev->noretry
 * setting still influence the default XNACK mode.
 */
-   if (supported && KFD_GC_VERSION(dev) == IP_VERSION(9, 4, 2))
+   if (supported && KFD_SUPPORT_XNACK_PER_PROCESS(dev))
continue;
  
  		/* GFXv10 and later GPUs do not support shader preemption

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

[Alex Deucher]

On Fri, Jan 13, 2023 at 4:02 PM Marek Olšák  wrote:
>
> i've added the comments and indeed pahole shows the hole as expected.

What about on 32-bit?

Alex

>
> Marek
>
> On Thu, Jan 12, 2023 at 11:44 AM Alex Deucher  wrote:
>>
>> On Thu, Jan 12, 2023 at 6:50 AM Christian König
>>  wrote:
>> >
>> > Am 11.01.23 um 21:48 schrieb Alex Deucher:
>> > > On Wed, Jan 4, 2023 at 3:17 PM Marek Olšák  wrote:
>> > >> Yes, it's meant to be like a spec sheet. We are not interested in the 
>> > >> current bandwidth utilization.
>> > > After chatting with Marek on IRC and thinking about this more, I think
>> > > this patch is fine.  It's not really meant for bandwidth per se, but
>> > > rather as a limit to determine what the driver should do in certain
>> > > cases (i.e., when does it make sense to copy to vram vs not).  It's
>> > > not straightforward for userspace to parse the full topology to
>> > > determine what links may be slow.  I guess one potential pitfall would
>> > > be that if you pass the device into a VM, the driver may report the
>> > > wrong values.  Generally in a VM the VM doesn't get the full view up
>> > > to the root port.  I don't know if the hypervisors report properly for
>> > > pcie_bandwidth_available() in a VM or if it just shows the info about
>> > > the endpoint in the VM.
>> >
>> > So this basically doesn't return the gen and lanes of the device, but
>> > rather what was negotiated between the device and the upstream root port?
>>
>> Correct. It exposes the max gen and lanes of the slowest link between
>> the device and the root port.
>>
>> >
>> > If I got that correctly then we should probably document that cause
>> > otherwise somebody will try to "fix" it at some time.
>>
>> Good point.
>>
>> Alex
>>
>> >
>> > Christian.
>> >
>> > >
>> > > Reviewed-by: Alex Deucher 
>> > >
>> > > Alex
>> > >
>> > >> Marek
>> > >>
>> > >> On Wed, Jan 4, 2023 at 10:33 AM Lazar, Lijo  wrote:
>> > >>> [AMD Official Use Only - General]
>> > >>>
>> > >>>
>> > >>> To clarify, with DPM in place, the current bandwidth will be changing 
>> > >>> based on the load.
>> > >>>
>> > >>> If apps/umd already has a way to know the current bandwidth 
>> > >>> utilisation, then possible maximum also could be part of the same API. 
>> > >>> Otherwise, this only looks like duplicate information. We have the 
>> > >>> same information in sysfs DPM nodes.
>> > >>>
>> > >>> BTW, I don't know to what extent app/umd really makes use of this. 
>> > >>> Take that memory frequency as an example (I'm reading it as 16GHz). It 
>> > >>> only looks like a spec sheet.
>> > >>>
>> > >>> Thanks,
>> > >>> Lijo
>> > >>> 
>> > >>> From: Marek Olšák 
>> > >>> Sent: Wednesday, January 4, 2023 8:40:00 PM
>> > >>> To: Lazar, Lijo 
>> > >>> Cc: amd-gfx@lists.freedesktop.org 
>> > >>> Subject: Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes 
>> > >>> from the INFO
>> > >>>
>> > >>> On Wed, Jan 4, 2023 at 9:19 AM Lazar, Lijo  wrote:
>> > >>>
>> > >>>
>> > >>>
>> > >>> On 1/4/2023 7:43 PM, Marek Olšák wrote:
>> >  On Wed, Jan 4, 2023 at 6:50 AM Lazar, Lijo > >  > wrote:
>> > 
>> > 
>> > 
>> >   On 1/4/2023 4:11 AM, Marek Olšák wrote:
>> >    > I see. Well, those sysfs files are not usable, and I don't 
>> >  think it
>> >    > would be important even if they were usable, but for 
>> >  completeness:
>> >    >
>> >    > The ioctl returns:
>> >    >  pcie_gen = 1
>> >    >  pcie_num_lanes = 16
>> >    >
>> >    > Theoretical bandwidth from those values: 4.0 GB/s
>> >    > My DMA test shows this write bandwidth: 3.5 GB/s
>> >    > It matches the expectation.
>> >    >
>> >    > Let's see the devices (there is only 1 GPU Navi21 in the 
>> >  system):
>> >    > $ lspci |egrep '(PCI|VGA).*Navi'
>> >    > 0a:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] 
>> >  Navi
>> >   10 XL
>> >    > Upstream Port of PCI Express Switch (rev c3)
>> >    > 0b:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] 
>> >  Navi
>> >   10 XL
>> >    > Downstream Port of PCI Express Switch
>> >    > 0c:00.0 VGA compatible controller: Advanced Micro Devices, 
>> >  Inc.
>> >    > [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] (rev c3)
>> >    >
>> >    > Let's read sysfs:
>> >    >
>> >    > $ cat /sys/bus/pci/devices/:0a:00.0/current_link_width
>> >    > 16
>> >    > $ cat /sys/bus/pci/devices/:0b:00.0/current_link_width
>> >    > 16
>> >    > $ cat /sys/bus/pci/devices/:0c:00.0/current_link_width
>> >    > 16
>> >    > $ cat /sys/bus/pci/devices/:0a:00.0/current_link_speed
>> >    > 2.5 GT/s PCIe
>> >    > $ cat 

Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes from the INFO

[Marek Olšák]

i've added the comments and indeed pahole shows the hole as expected.

Marek

On Thu, Jan 12, 2023 at 11:44 AM Alex Deucher  wrote:

> On Thu, Jan 12, 2023 at 6:50 AM Christian König
>  wrote:
> >
> > Am 11.01.23 um 21:48 schrieb Alex Deucher:
> > > On Wed, Jan 4, 2023 at 3:17 PM Marek Olšák  wrote:
> > >> Yes, it's meant to be like a spec sheet. We are not interested in the
> current bandwidth utilization.
> > > After chatting with Marek on IRC and thinking about this more, I think
> > > this patch is fine.  It's not really meant for bandwidth per se, but
> > > rather as a limit to determine what the driver should do in certain
> > > cases (i.e., when does it make sense to copy to vram vs not).  It's
> > > not straightforward for userspace to parse the full topology to
> > > determine what links may be slow.  I guess one potential pitfall would
> > > be that if you pass the device into a VM, the driver may report the
> > > wrong values.  Generally in a VM the VM doesn't get the full view up
> > > to the root port.  I don't know if the hypervisors report properly for
> > > pcie_bandwidth_available() in a VM or if it just shows the info about
> > > the endpoint in the VM.
> >
> > So this basically doesn't return the gen and lanes of the device, but
> > rather what was negotiated between the device and the upstream root port?
>
> Correct. It exposes the max gen and lanes of the slowest link between
> the device and the root port.
>
> >
> > If I got that correctly then we should probably document that cause
> > otherwise somebody will try to "fix" it at some time.
>
> Good point.
>
> Alex
>
> >
> > Christian.
> >
> > >
> > > Reviewed-by: Alex Deucher 
> > >
> > > Alex
> > >
> > >> Marek
> > >>
> > >> On Wed, Jan 4, 2023 at 10:33 AM Lazar, Lijo 
> wrote:
> > >>> [AMD Official Use Only - General]
> > >>>
> > >>>
> > >>> To clarify, with DPM in place, the current bandwidth will be
> changing based on the load.
> > >>>
> > >>> If apps/umd already has a way to know the current bandwidth
> utilisation, then possible maximum also could be part of the same API.
> Otherwise, this only looks like duplicate information. We have the same
> information in sysfs DPM nodes.
> > >>>
> > >>> BTW, I don't know to what extent app/umd really makes use of this.
> Take that memory frequency as an example (I'm reading it as 16GHz). It only
> looks like a spec sheet.
> > >>>
> > >>> Thanks,
> > >>> Lijo
> > >>> 
> > >>> From: Marek Olšák 
> > >>> Sent: Wednesday, January 4, 2023 8:40:00 PM
> > >>> To: Lazar, Lijo 
> > >>> Cc: amd-gfx@lists.freedesktop.org 
> > >>> Subject: Re: [PATCH 1/2] drm/amdgpu: return the PCIe gen and lanes
> from the INFO
> > >>>
> > >>> On Wed, Jan 4, 2023 at 9:19 AM Lazar, Lijo 
> wrote:
> > >>>
> > >>>
> > >>>
> > >>> On 1/4/2023 7:43 PM, Marek Olšák wrote:
> >  On Wed, Jan 4, 2023 at 6:50 AM Lazar, Lijo  >  > wrote:
> > 
> > 
> > 
> >   On 1/4/2023 4:11 AM, Marek Olšák wrote:
> >    > I see. Well, those sysfs files are not usable, and I don't
> think it
> >    > would be important even if they were usable, but for
> completeness:
> >    >
> >    > The ioctl returns:
> >    >  pcie_gen = 1
> >    >  pcie_num_lanes = 16
> >    >
> >    > Theoretical bandwidth from those values: 4.0 GB/s
> >    > My DMA test shows this write bandwidth: 3.5 GB/s
> >    > It matches the expectation.
> >    >
> >    > Let's see the devices (there is only 1 GPU Navi21 in the
> system):
> >    > $ lspci |egrep '(PCI|VGA).*Navi'
> >    > 0a:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI]
> Navi
> >   10 XL
> >    > Upstream Port of PCI Express Switch (rev c3)
> >    > 0b:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI]
> Navi
> >   10 XL
> >    > Downstream Port of PCI Express Switch
> >    > 0c:00.0 VGA compatible controller: Advanced Micro Devices,
> Inc.
> >    > [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] (rev
> c3)
> >    >
> >    > Let's read sysfs:
> >    >
> >    > $ cat /sys/bus/pci/devices/:0a:00.0/current_link_width
> >    > 16
> >    > $ cat /sys/bus/pci/devices/:0b:00.0/current_link_width
> >    > 16
> >    > $ cat /sys/bus/pci/devices/:0c:00.0/current_link_width
> >    > 16
> >    > $ cat /sys/bus/pci/devices/:0a:00.0/current_link_speed
> >    > 2.5 GT/s PCIe
> >    > $ cat /sys/bus/pci/devices/:0b:00.0/current_link_speed
> >    > 16.0 GT/s PCIe
> >    > $ cat /sys/bus/pci/devices/:0c:00.0/current_link_speed
> >    > 16.0 GT/s PCIe
> >    >
> >    > Problem 1: None of the speed numbers match 4 GB/s.
> > 
> >   US bridge = 2.5GT/s means operating at PCIe Gen 1 speed. 

Re: [PATCH 5/6] drm/amdgpu: update mappings not managed by KFD

[Chen, Xiaogang]

Reviewed-by: Xiaogang Chen 

Regards

Xiaogang

On 1/11/2023 7:31 PM, Felix Kuehling wrote:

When restoring after an eviction, use amdgpu_vm_handle_moved to update
BO VA mappings in KFD VMs that are not managed through the KFD API. This
should allow using the render node API to create more flexible memory
mappings in KFD VMs.

v2: Sync with pd fence after all page table updates
v3: Update comments, remove TODOs that are no longer applicable

Signed-off-by: Felix Kuehling 
---
  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 28 +++
  1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 79213f476493..df08e84f01d7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2728,12 +2728,6 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info, 
struct dma_fence **ef)
if (ret)
goto validate_map_fail;
  
-	ret = process_sync_pds_resv(process_info, _obj);

-   if (ret) {
-   pr_debug("Memory eviction: Failed to sync to PD BO moving fence. Try 
again\n");
-   goto validate_map_fail;
-   }
-
/* Validate BOs and map them to GPUVM (update VM page tables). */
list_for_each_entry(mem, _info->kfd_bo_list,
validate_list.head) {
@@ -2781,6 +2775,19 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info, 
struct dma_fence **ef)
if (failed_size)
pr_debug("0x%lx/0x%lx in system\n", failed_size, total_size);
  
+	/* Update mappings not managed by KFD */

+   list_for_each_entry(peer_vm, _info->vm_list_head,
+   vm_list_node) {
+   struct amdgpu_device *adev = amdgpu_ttm_adev(
+   peer_vm->root.bo->tbo.bdev);
+
+   ret = amdgpu_vm_handle_moved(adev, peer_vm, );
+   if (ret) {
+   pr_debug("Memory eviction: handle moved failed. Try 
again\n");
+   goto validate_map_fail;
+   }
+   }
+
/* Update page directories */
ret = process_update_pds(process_info, _obj);
if (ret) {
@@ -2788,6 +2795,15 @@ int amdgpu_amdkfd_gpuvm_restore_process_bos(void *info, 
struct dma_fence **ef)
goto validate_map_fail;
}
  
+	/* Sync with fences on all the page tables. They implicitly depend on any

+* move fences from amdgpu_vm_handle_moved above.
+*/
+   ret = process_sync_pds_resv(process_info, _obj);
+   if (ret) {
+   pr_debug("Memory eviction: Failed to sync to PD BO moving fence. Try 
again\n");
+   goto validate_map_fail;
+   }
+
/* Wait for validate and PT updates to finish */
amdgpu_sync_wait(_obj, false);
  

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Limonciello, Mario]

On 1/13/2023 13:28, Lyude Paul wrote:

On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:

On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:


Cc: intel-gfx, drm maintainers

Please have the courtesy of Cc'ing us for changes impacting us, and
maybe try to involve us earlier instead of surprising us like
this. Looks like this has been debugged for at least three months, and
the huge revert at this point is going to set us back with what's been
developed on top of it for i915 DP MST and DSC.


tbf I assumed this wont land when I've seen it fly by. It feels a bit much
like living under a rock for half a year and then creating a mess for
everyone else who's been building on top of this is not great.

Like yes it's a regression, but apparently not a blantantly obvious one,
and I think if we just ram this in there's considerable community goodwill
down the drain. Someone needs to get that goodwill up the drain again.


It's a regression, I get that, but this is also going to be really nasty
to deal with. It's a 2500-line commit, plus the dependencies, which I
don't think are accounted for here. (What's the baseline for the revert
anyway?) I don't expect all the dependent commits to be easy to revert
or backport to v6.1 or v6.2.

*sad trombone*


Yeah that's the other thing. 2500 patch revert is not cc stable material.
So this isn't even really helping users all that much.

Unless it also comes with full amounts of backports of the reverts on all
affected drivers for all curent stable trees, fully validated.


The silver lining here is that in terms of how many stable trees this is 
broken it's only 6.1.y.


Wayne's revert is against drm-tip.

I found that attempting backporting his revert I run into
conflicts in 6.2-rc3 because of:

831a277ef001 ("Revert "drm/i915: Extract drm_dp_atomic_find_vcpi_slots 
cycle to separate function"")


I worked through them and have the result here:
https://gitlab.freedesktop.org/superm1/linux/-/commit/8e926eb77c41e7f32f3d8943cdf7d140ed319b79

and conflicts in 6.1.y from the lack of:

8c7d980da9ba ("drm/nouveau/disp: move DP MST payload config method")

I worked through those as well and the result is here:

https://gitlab.freedesktop.org/superm1/linux/-/commit/2145b4de3fea9908cda6bef0693a797cc7f4ddfc

Affected people in Gitlab #2171 have tested amdgpu works w/ MST again 
with 6.1.5 with that applied.


To your point, we do need someone with the appropriate hardware to make 
sure we didn't make i915 or nouveau worse by this revert though.




This is bad. I do think we need to have some understanding first of what
"fix this in amdgpu" would look like as plan B. Because plan A does not
look like a happy one at all.


Yeah this whole thing has been a mess, I'm partially to blame here - we should
have reverted earlier, but a lot of this has been me finding out that the
problem here is a lot bigger then I previously imagined - and has not at all
been easy to untangle. I've also dumped so much time into trying to figure it
out that was more or less the only reason I acked this in the first place, I'm
literally just quite tired and exhausted at this point from spinning my wheels
on trying to fix this ;_;.

I am sure there is a real proper fix for this, if anyone wants to help me try
and figure this out I'm happy to setup remote access to the machines I've got
here. I'll also try to push myself to dig further into this next week again.


-Daniel


BR,
Jani.

Re: [PATCH v2 04/21] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

[Simon Ser]

Reviewed-by: Simon Ser 

[PATCH v2 19/20] dyndbg: unwrap __ddebug_add_module inner function NOTYET

[Jim Cromie]

The inner func has a base arg which is unused in the body, so theres
no point in having the inner fn.

Its one-time purpose was to expose a wider interface to the internal
caller: dynamic_debug_init(), to allow communicating each module's
offset in the builtin _ddebug[] table.

That purpose was obsoleted by cited commit, when ddebug_add_module()
was converted to pass a *ddebug_info, which is used as a cursor by the
caller.

TODO: the cited commit gives another reason for base, to provide an
index in support of de-duplicating column data.  Refresh that patchset
to see if its still true.

Fixes: b7b4eebdba7b ("dyndbg: gather __dyndbg[] state into struct _ddebug_info")
Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 19bf66229d45..eb1fb10d7272 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1348,8 +1348,7 @@ static void ddebug_attach_client_module_classes(struct 
ddebug_table *dt, const s
  * Allocate a new ddebug_table for the given module
  * and add it to the global list.
  */
-static int __ddebug_add_module(struct _ddebug_info *di, unsigned int base,
-  const char *modname)
+int ddebug_add_module(struct _ddebug_info *di, const char *modname)
 {
struct ddebug_table *dt;
 
@@ -1391,11 +1390,6 @@ static int __ddebug_add_module(struct _ddebug_info *di, 
unsigned int base,
return 0;
 }
 
-int ddebug_add_module(struct _ddebug_info *di, const char *modname)
-{
-   return __ddebug_add_module(di, 0, modname);
-}
-
 /* helper for ddebug_dyndbg_(boot|module)_param_cb */
 static int ddebug_dyndbg_param_cb(char *param, char *val,
const char *modname, int on_err)
@@ -1538,7 +1532,7 @@ static int __init dynamic_debug_init(void)
mod_ct++;
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-   ret = __ddebug_add_module(, i - mod_sites, modname);
+   ret = ddebug_add_module(, modname);
if (ret)
goto out_err;
 
@@ -1549,7 +1543,7 @@ static int __init dynamic_debug_init(void)
}
di.num_descs = mod_sites;
di.descs = iter_mod_start;
-   ret = __ddebug_add_module(, i - mod_sites, modname);
+   ret = ddebug_add_module(, modname);
if (ret)
goto out_err;
 
-- 
2.39.0

[PATCH v2 16/20] test-dyndbg: rename DD_SYS_WRAP to DYNDBG_CLASSMAP_PARAM

[Jim Cromie]

Original name was a punt; but the macro is maybe general enough to put
in the API later.  Rename and improve the macro towards that end.

Also tweak internal name constructed in the macro, to add a '_'
between the name components.  This changes the .i file only.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 39d4f63cade1..45e123b29a9b 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -44,14 +44,15 @@ module_param_cb(do_prints, _ops_do_prints, NULL, 
0600);
  * Additionally, here:
  * - tie together sysname, mapname, bitsname, flagsname
  */
-#define DD_SYS_WRAP(_model, _flags)\
+#define DYNDBG_CLASSMAP_PARAM(_model, _flags)  
\
static unsigned long bits_##_model; \
-   static struct ddebug_class_param _flags##_model = { \
+   static struct ddebug_class_param _flags##_##_model = {  \
.bits = _##_model, \
.flags = #_flags,   \
.map = _##_model,   \
};  \
-   module_param_cb(_flags##_##_model, _ops_dyndbg_classes, 
&_flags##_model, 0600)
+   module_param_cb(_flags##_##_model, _ops_dyndbg_classes,   \
+   &_flags##_##_model, 0600)
 
 /*
  * dynamic-debug imitates drm.debug model's use of enums (DRM_UT_CORE
@@ -112,23 +113,23 @@ DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits, 
DD_CLASS_TYPE_DISJOINT_BITS,
   D2_LEASE,
   D2_DP,
   D2_DRMRES);
-DD_SYS_WRAP(disjoint_bits, p);
-DD_SYS_WRAP(disjoint_bits, T);
+DYNDBG_CLASSMAP_PARAM(disjoint_bits, p);
+DYNDBG_CLASSMAP_PARAM(disjoint_bits, T);
 
 DYNDBG_CLASSMAP_DEFINE(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES,
   LOW, MID, HI);
-DD_SYS_WRAP(disjoint_names, p);
-DD_SYS_WRAP(disjoint_names, T);
+DYNDBG_CLASSMAP_PARAM(disjoint_names, p);
+DYNDBG_CLASSMAP_PARAM(disjoint_names, T);
 
 DYNDBG_CLASSMAP_DEFINE(map_level_num, DD_CLASS_TYPE_LEVEL_NUM,
   V0, V1, V2, V3, V4, V5, V6, V7);
-DD_SYS_WRAP(level_num, p);
-DD_SYS_WRAP(level_num, T);
+DYNDBG_CLASSMAP_PARAM(level_num, p);
+DYNDBG_CLASSMAP_PARAM(level_num, T);
 
 DYNDBG_CLASSMAP_DEFINE(map_level_names, DD_CLASS_TYPE_LEVEL_NAMES,
   L0, L1, L2, L3, L4, L5, L6, L7);
-DD_SYS_WRAP(level_names, p);
-DD_SYS_WRAP(level_names, T);
+DYNDBG_CLASSMAP_PARAM(level_names, p);
+DYNDBG_CLASSMAP_PARAM(level_names, T);
 
 #endif /* TEST_DYNAMIC_DEBUG_SUBMOD */
 
-- 
2.39.0

[PATCH v2 17/20] test-dyndbg: disable WIP dyndbg-trace params

[Jim Cromie]

The dyndbg-to-trace feature is WIP, and not in mainline, so the
presence of the interface to use/test it is unhelpful/confusing.

So define DYNDBG_CLASSMAP_PARAM_T() as DYNDBG_CLASSMAP_PARAM() or
blank, depending upon ifdef DYDBG_TRACE, and update 4 params
controlling the T-flag to use it.

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 45e123b29a9b..9e66c5a7e138 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -54,6 +54,14 @@ module_param_cb(do_prints, _ops_do_prints, NULL, 0600);
module_param_cb(_flags##_##_model, _ops_dyndbg_classes,   \
&_flags##_##_model, 0600)
 
+/* TBD */
+#ifdef DYNDBG_TRACE
+#define DYNDBG_CLASSMAP_PARAM_T(_model, _flags)\
+   DYNDBG_CLASSMAP_PARAM(_model, _flags)
+#else
+#define DYNDBG_CLASSMAP_PARAM_T(_model, _flags)
+#endif
+
 /*
  * dynamic-debug imitates drm.debug model's use of enums (DRM_UT_CORE
  * etc) to define it's classes/categories.  dyndbg allows class-id's
@@ -114,22 +122,22 @@ DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits, 
DD_CLASS_TYPE_DISJOINT_BITS,
   D2_DP,
   D2_DRMRES);
 DYNDBG_CLASSMAP_PARAM(disjoint_bits, p);
-DYNDBG_CLASSMAP_PARAM(disjoint_bits, T);
+DYNDBG_CLASSMAP_PARAM_T(disjoint_bits, T);
 
 DYNDBG_CLASSMAP_DEFINE(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES,
   LOW, MID, HI);
 DYNDBG_CLASSMAP_PARAM(disjoint_names, p);
-DYNDBG_CLASSMAP_PARAM(disjoint_names, T);
+DYNDBG_CLASSMAP_PARAM_T(disjoint_names, T);
 
 DYNDBG_CLASSMAP_DEFINE(map_level_num, DD_CLASS_TYPE_LEVEL_NUM,
   V0, V1, V2, V3, V4, V5, V6, V7);
 DYNDBG_CLASSMAP_PARAM(level_num, p);
-DYNDBG_CLASSMAP_PARAM(level_num, T);
+DYNDBG_CLASSMAP_PARAM_T(level_num, T);
 
 DYNDBG_CLASSMAP_DEFINE(map_level_names, DD_CLASS_TYPE_LEVEL_NAMES,
   L0, L1, L2, L3, L4, L5, L6, L7);
 DYNDBG_CLASSMAP_PARAM(level_names, p);
-DYNDBG_CLASSMAP_PARAM(level_names, T);
+DYNDBG_CLASSMAP_PARAM_T(level_names, T);
 
 #endif /* TEST_DYNAMIC_DEBUG_SUBMOD */
 
-- 
2.39.0

[PATCH v2 15/20] test-dyndbg: build test_dynamic_debug_submod

[Jim Cromie]

CONFIG_DRM_USE_DYNAMIC_DEBUG=y has a regression; drm subsystem
modules, which depend upon drm.ko and use the drm.debug API, do not
get enabled when __drm_debug is set by `modprobe drm debug=0x1f`.

With =N, __drm_debug is checked before logging the msg, so the
end-of-modprobe debug=$init affected all later checks.  But with =y,
each run-time check is replaced by a static-key that is set at
end-of-modprobe.

This creates a chicken-egg dependency; i915 must be modprobed before
its drm.debugs are enabled, but drm.ko (and __drm_debug=$init) must be
done before modprobe i915, so its callsites arent there yet to be
enabled.

The WIP-fix is to split DECLARE_DYNDBG_CLASSMAP to:

DYNDBG_CLASSMAP_DEFINE - invoked in 'parent'
DYNDBG_CLASSMAP_USE - invoked in dependent, to USE the exported definition

To prove the fix w/o involving DRM, we need 2 modules, one dependent
on the other.  Add test_dynamic_debug_submod.ko, which _USEs the
classmaps _exported by test_dynamic_debug.ko

To keep code to a minimum, test_dynamic_debug.c ifdefs on
TEST_DYNAMIC_DEBUG_SUBMOD to build either parent or dependent, with
either DYNDBG_CLASSMAP_DEFINE or DYNDBG_CLASSMAP_USE blocks.

So test_dynamic_debug_submod.c is just 2 lines: include parent after
defining SUBMOD.  This also gives the 2 modules identical logging
behavior as a baseline.

Signed-off-by: Jim Cromie 
---
 lib/Makefile|  3 +-
 lib/test_dynamic_debug.c| 50 -
 lib/test_dynamic_debug_submod.c | 10 +++
 3 files changed, 55 insertions(+), 8 deletions(-)
 create mode 100644 lib/test_dynamic_debug_submod.c

diff --git a/lib/Makefile b/lib/Makefile
index 59bd7c2f793a..0f04c59bdc8e 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -78,7 +78,7 @@ obj-$(CONFIG_TEST_SORT) += test_sort.o
 obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
 obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
 obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
-obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o
+obj-$(CONFIG_TEST_DYNAMIC_DEBUG) += test_dynamic_debug.o 
test_dynamic_debug_submod.o
 obj-$(CONFIG_TEST_PRINTF) += test_printf.o
 obj-$(CONFIG_TEST_SCANF) += test_scanf.o
 obj-$(CONFIG_TEST_BITMAP) += test_bitmap.o
@@ -100,6 +100,7 @@ obj-$(CONFIG_KPROBES_SANITY_TEST) += test_kprobes.o
 obj-$(CONFIG_TEST_REF_TRACKER) += test_ref_tracker.o
 CFLAGS_test_fprobe.o += $(CC_FLAGS_FTRACE)
 obj-$(CONFIG_FPROBE_SANITY_TEST) += test_fprobe.o
+
 #
 # CFLAGS for compiling floating point code inside the kernel. x86/Makefile 
turns
 # off the generation of FPU/SSE* instructions for kernel proper but FPU_FLAGS
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index e678884066bf..39d4f63cade1 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -6,7 +6,11 @@
  *  Jim Cromie 
  */
 
-#define pr_fmt(fmt) "test_dd: " fmt
+#if defined(TEST_DYNAMIC_DEBUG_SUBMOD)
+  #define pr_fmt(fmt) "test_dd_submod: " fmt
+#else
+  #define pr_fmt(fmt) "test_dd: " fmt
+#endif
 
 #define DEBUG /* enable all prdbgs (plain & class'd) at compiletime */
 
@@ -49,6 +53,13 @@ module_param_cb(do_prints, _ops_do_prints, NULL, 0600);
};  \
module_param_cb(_flags##_##_model, _ops_dyndbg_classes, 
&_flags##_model, 0600)
 
+/*
+ * dynamic-debug imitates drm.debug model's use of enums (DRM_UT_CORE
+ * etc) to define it's classes/categories.  dyndbg allows class-id's
+ * 0..62, reserving 63 for plain old (non-class'd) prdbgs.  A module
+ * can define multiple classmaps, as long as they share the range.
+ */
+
 /* numeric input, independent bits */
 enum cat_disjoint_bits {
D2_CORE = 0,
@@ -61,7 +72,36 @@ enum cat_disjoint_bits {
D2_LEASE,
D2_DP,
D2_DRMRES };
+
+/* symbolic input, independent bits */
+enum cat_disjoint_names { LOW = 10, MID, HI };
+
+/* numeric verbosity, V2 > V1 related */
+enum cat_level_num { V0 = 14, V1, V2, V3, V4, V5, V6, V7 };
+
+/* symbolic verbosity */
+enum cat_level_names { L0 = 22, L1, L2, L3, L4, L5, L6, L7 };
+
+#if defined(TEST_DYNAMIC_DEBUG_SUBMOD)
+
+/* use the classmaps defined in 'parent' module below */
+DYNDBG_CLASSMAP_USE(map_disjoint_bits);
+DYNDBG_CLASSMAP_USE(map_disjoint_names);
+DYNDBG_CLASSMAP_USE(map_level_num);
+DYNDBG_CLASSMAP_USE(map_level_names);
+
+#else
+
+/*
+ * parent module, define a classmap of each of 4 types.
+ * enum values are class-ids
+ * enum symbols are stringified, used as classnames
+ * param bits are mapped in order: 0..N
+ * (a straight, obvious, linear map is encouraged)
+ */
+
 DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits, DD_CLASS_TYPE_DISJOINT_BITS,
+  /* bits 0..N of param are mapped to these class-ids */
   D2_CORE,
   D2_DRIVER,
   D2_KMS,
@@ -75,27 +115,23 @@ DYNDBG_CLASSMAP_DEFINE(map_disjoint_bits, 
DD_CLASS_TYPE_DISJOINT_BITS,
 DD_SYS_WRAP(disjoint_bits, p);
 

[PATCH v2 20/20] jump_label: RFC - tolerate toggled state

[Jim Cromie]

__jump_label_patch currently will "crash the box" if it finds a
jump_entry not as expected.  ISTM this overly harsh; it doesn't
distinguish between "alternate/opposite" state, and truly
"insane/corrupted".

The "opposite" (but well-formed) state is a milder mis-initialization
problem, and some less severe mitigation seems practical.  ATM this
just warns about it; a range/enum of outcomes: warn, crash, silence,
ok, fixup-continue, etc, are possible on a case-by-case basis.

Ive managed to create this mis-initialization condition with
test_dynamic_debug.ko & _submod.ko.  These replicate DRM's regression
on DRM_USE_DYNAMIC_DEBUG=y; drm.debug callsites in drivers/helpers
(dependent modules) are not enabled along with those in drm.ko itself.

Heres that "opposite" state, occurring:

:#> echo 1 > /sys/module/test_dynamic_debug/parameters/p_disjoint_bits
[  235.258452] dyndbg: bits:0x1 > *.p_disjoint_bits
[  235.258908] dyndbg: apply bitmap: 0x1 to: 0x4f for '*'
[  235.259351] dyndbg: query 0: "class D2_DRIVER -p" mod:*
[  235.259799] dyndbg: split into words: "class" "D2_DRIVER" "-p"
[  235.260290] dyndbg: op='-' flags=0x0 maskp=0xfffe
[  235.260720] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=D2_DRIVER
[  235.261418] dyndbg: good-class: test_dynamic_debug.D2_DRIVER module: 
test_dynamic_debug nd: 32 nc: 4 nu: 0
[  235.262276] dyndbg: class-ref: test_dynamic_debug_submod.D2_DRIVER module: 
test_dynamic_debug_submod nd: 32 nc: 0 nu: 4
[  235.263178] jump_label: found alternate op at do_cats+0x16/0x180 
[test_dynamic_debug_submod] [ba944cc2] (0f 1f 44 00 00 != e9 e1 00 00 
00)) size:5 type:0
[  235.264431] dyndbg: processed 1 queries, with 2 matches, 0 errs
[  235.264951] dyndbg: bit_1: 2 matches on class: D2_DRIVER -> 0x1
[  235.265444] dyndbg: query 0: "class D2_KMS -p" mod:*
[  235.265869] dyndbg: split into words: "class" "D2_KMS" "-p"
[  235.266337] dyndbg: op='-' flags=0x0 maskp=0xfffe
[  235.266767] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=D2_KMS
[  235.267432] dyndbg: good-class: test_dynamic_debug.D2_KMS module: 
test_dynamic_debug nd: 32 nc: 4 nu: 0
[  235.268264] dyndbg: class-ref: test_dynamic_debug_submod.D2_KMS module: 
test_dynamic_debug_submod nd: 32 nc: 0 nu: 4
[  235.269142] jump_label: found alternate op at do_cats+0x1b/0x180 
[test_dynamic_debug_submod] [e8d6c160] (0f 1f 44 00 00 != e9 c4 00 00 
00)) size:5 type:0
[  235.270384] dyndbg: processed 1 queries, with 2 matches, 0 errs

RFC:

Ive hit this case a few times, but havent been able to isolate the
when and why.

warn-only is something of a punt, and I'm still left with remaining
bugs which are likely related; I'm able to toggle the p-flag on
callsites in the submod, but their enablement still doesn't yield
logging activity.

CC: Jason Baron 
CC: Peter Zijlstra 
Signed-off-by: Jim Cromie 
---

heres the Fatal kernel bug: (its on a -dirty kernel)

[ 2831.639643] dyndbg: good-class: test_dynamic_debug.D2_CORE module: 
test_dynamic_debug nd: 32 nc: 4 nu: 0
[ 2831.641316] dyndbg: class-ref: test_dynamic_debug_submod.D2_CORE module: 
test_dynamic_debug_submod nd: 32 nc: 0 nu: 4
[ 2831.642048] jump_label: Fatal kernel bug, unexpected op at 
do_cats+0x11/0x180 [test_dynamic_debug_submod] [fa724232] (0f 1f 44 00 
00 != e9 fe 00 00 00)) size:5 type:0
[ 2831.643077] [ cut here ]
[ 2831.643537] kernel BUG at arch/x86/kernel/jump_label.c:73!
[ 2831.643902] invalid opcode:  [#1] PREEMPT SMP KASAN
[ 2831.644248] CPU: 1 PID: 425 Comm: bash Tainted: GE  
6.1.0-tf2-00021-gbe37efe8728f-dirty #696
[ 2831.644862] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.16.1-2.fc37 04/01/2014
[ 2831.645431] RIP: 0010:__jump_label_patch.cold+0x24/0x26
[ 2831.645773] Code: 83 e9 ef 00 ac fe 48 c7 c3 20 4c 5c 85 41 56 45 89 f9 49 
89 d8 4c 89 e9 4c 89 ea 4c 89 ee 48 c7 c7 00 70 c5 82 e8 d7 1a 01 00 <0f> 0b 41 
54 45 31 e4 55 48 89 fd 53 bb 00 00 00 80 48 81 c3 00 20
[ 2831.646896] RSP: 0018:c9000101f738 EFLAGS: 00010282
[ 2831.647242] RAX: 00a2 RBX: 855c4c20 RCX: 
[ 2831.647702] RDX: 00a2 RSI: 81294fc4 RDI: f52000203ede
[ 2831.648155] RBP: c9000101f778 R08: 0003 R09: c9000101f4ff
[ 2831.648626] R10: f52000203e9f R11: 78656e75202c756a R12: 855c4c20
[ 2831.649096] R13: c0250011 R14:  R15: 0005
[ 2831.649498] FS:  7fe4014aa740() GS:88805ae0() 
knlGS:
[ 2831.649894] CS:  0010 DS:  ES:  CR0: 80050033
[ 2831.650175] CR2: 7f9c326e6c08 CR3: 0ff59000 CR4: 00750ee0
[ 2831.650520] PKRU: 5554
[ 2831.650667] Call Trace:
[ 2831.650793]  
[ 2831.650903]  ? do_cats+0x11/0x180 [test_dynamic_debug_submod]
[ 2831.651195]  arch_jump_label_transform_queue+0x43/0xa0
[ 2831.651450]  __jump_label_update+0x9b/0x1b0
[ 2831.651670]  

[PATCH v2 18/20] test-dyndbg: tune sub-module behavior

[Jim Cromie]

lib/test_dynamic_debug.c is used to build 2 modules:
test_dynamic_debug.ko and test_dynamic_debug_submod.ko

Define DEBUG only in the main module, not in the submod.  Its purpose
is to insure that prdbgs are enabled by default, so that a modprobe
without params actually logs something, showing that compile-time
enablement works.  This doesn't need to be repeated in the submodule.

Rather, the submodule's purpose is to prove that classmaps defined and
exported from a parent module are propagated to submodules, setting
their class'd debugs accordingly.

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 9e66c5a7e138..94fe3b3438d0 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -6,13 +6,13 @@
  *  Jim Cromie 
  */
 
-#if defined(TEST_DYNAMIC_DEBUG_SUBMOD)
-  #define pr_fmt(fmt) "test_dd_submod: " fmt
-#else
+#if !defined(TEST_DYNAMIC_DEBUG_SUBMOD)
   #define pr_fmt(fmt) "test_dd: " fmt
+  #define DEBUG/* enable all prdbgs (plain & class'd) at compiletime */
+#else
+  #define pr_fmt(fmt) "test_dd_submod: " fmt
 #endif
 
-#define DEBUG /* enable all prdbgs (plain & class'd) at compiletime */
 
 #include 
 
-- 
2.39.0

[PATCH v2 13/20] dyndbg-API: DYNDBG_CLASSMAP_DEFINE() improvements

[Jim Cromie]

patch 1 in this series fixed a CLASSMAP usage error, this improves the
api so that misuse is less likely.

changes here:

0- Add William Swanson's public domain map macro:
   https://github.com/swansontec/map-macro/blob/master/map.h
   this makes 1 possible.

1- classnames were formerly specified as strings: "DRM_UT_CORE"
   now they are the actual enum const symbols: DRM_UT_CORE
   direct use of symbols is tighter, more comprehensible by tools, grep

2- drop _base arg.
   _base was the value of the 1st classname
   that is now available due to 1, no need to require it 2x

So take _base out of the API/kdoc.  Note that the macro impl keeps the
_base arg so that it can be used to set classmap.base, but reuses it
in the MAP-stringify _base, __VA_ARGS__ expression.

Also cleanup the API usage comment in test_dynamic_debug.c, and since
comments in test-code might not be noticed, restate that here.

Using the CLASSMAP api:

  - class-specifications are enum consts/symbols,
like DRM_UT_CORE, DRM_UT_KMS, etc.
their values define bits in the sysfs-node (like drm.debug)

  - they are stringified and accepted at >control
echo class DRM_UT_CORE +p >control

  - multiple class-maps must share the per-module: 0-62 class_id space
(by setting initial enum values to non-overlapping subranges)

todo: fixup the 'i' prefix, a quick/dirty avoidance of MAP.

NOTE: test_dynamic_debug.c also has this helper macro to wire a
classmap to a drm.debug style parameter; its easier to just use it as
a model/template as needed, rather than try to make it general enough
to be an official API helper.

 define DD_SYS_WRAP(_model, _flags) \
static unsigned long bits_##_model; \
static struct ddebug_class_param _flags##_model = { \
.bits = _##_model, \
.flags = #_flags,   \
.map = _##_model,   \
};  \
module_param_cb(_flags##_##_model, _ops_dyndbg_classes, 
&_flags##_model, 0600)

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/drm_print.c   | 22 +++---
 include/drm/drm_print.h   |  1 +
 include/linux/dynamic_debug.h | 17 ++-
 include/linux/map.h   | 54 +++
 lib/test_dynamic_debug.c  | 43 ++--
 5 files changed, 95 insertions(+), 42 deletions(-)
 create mode 100644 include/linux/map.h

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 4b697e18238d..07c25241e8cc 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,17 +56,17 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each 
bit enables a debug cat
 module_param_named(debug, __drm_debug, ulong, 0600);
 #else
 /* classnames must match vals of enum drm_debug_category */
-DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_DEFINE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS,
+  DRM_UT_CORE,
+  DRM_UT_DRIVER,
+  DRM_UT_KMS,
+  DRM_UT_PRIME,
+  DRM_UT_ATOMIC,
+  DRM_UT_VBL,
+  DRM_UT_STATE,
+  DRM_UT_LEASE,
+  DRM_UT_DP,
+  DRM_UT_DRMRES);
 
 static struct ddebug_class_param drm_debug_bitmap = {
.bits = &__drm_debug,
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index a44fb7ef257f..6a27e8f26770 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -333,6 +333,7 @@ static inline bool drm_debug_enabled_raw(enum 
drm_debug_category category)
})
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+//extern struct ddebug_class_map drm_debug_classes[];
 /*
  * the drm.debug API uses dyndbg, so each drm_*dbg macro/callsite gets
  * a descriptor, and only enabled callsites are reachable.  They use
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 91015d1a04e0..7cdfc4b533ae 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -7,6 +7,7 @@
 #endif
 
 #include 
+#include 
 
 /*
  * An instance of this structure is created in a special
@@ -90,18 +91,16 @@ struct ddebug_class_map {
 };
 
 /**
- * DYNDBG_CLASSMAP_DEFINE - define debug-classes used by a module.
- * @_var:   name of the classmap, exported for 

[PATCH v2 14/20] drm_print: fix stale macro-name in comment

[Jim Cromie]

Cited commit uses stale macro name, fix this, and explain better.

When DRM_USE_DYNAMIC_DEBUG=y, DYNDBG_CLASSMAP_DEFINE() maps DRM_UT_*
onto BITs in drm.debug.  This still uses enum drm_debug_category, but
it is somewhat indirect, with the ordered set of DRM_UT_* enum-vals.
This requires that the macro args: DRM_UT_* list must be kept in sync
and in order.

Fixes: f158936b60a7 ("drm: POC drm on dyndbg - use in core, 2 helpers, 3 
drivers.")
Signed-off-by: Jim Cromie 
---
. emphasize ABI non-change despite enum val change - Jani Nikula
. reorder to back of patchset to follow API name changes.
---
 include/drm/drm_print.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 6a27e8f26770..7695ba31b3a4 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -276,7 +276,10 @@ static inline struct drm_printer drm_err_printer(const 
char *prefix)
  *
  */
 enum drm_debug_category {
-   /* These names must match those in DYNAMIC_DEBUG_CLASSBITS */
+   /*
+* Keep DYNDBG_CLASSMAP_DEFINE args in sync with changes here,
+* the enum-values define BIT()s in drm.debug, so are ABI.
+*/
/**
 * @DRM_UT_CORE: Used in the generic drm code: drm_ioctl.c, drm_mm.c,
 * drm_memory.c, ...
-- 
2.39.0

[PATCH v2 12/20] dyndbg-API: DYNDBG_CLASSMAP_USE drop extra args

[Jim Cromie]

Drop macro args after _var.  Since DYNDBG_CLASSMAP_USE no longer
forwards to DYNDBG_CLASSMAP_DEFINE, it doesn't need those args to
forward.  Keep only the _var arg, which is the extern'd struct
classmap with all the class info.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +-
 drivers/gpu/drm/display/drm_dp_helper.c | 12 +-
 drivers/gpu/drm/drm_crtc_helper.c   | 12 +-
 drivers/gpu/drm/i915/i915_params.c  | 12 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 12 +-
 include/linux/dynamic_debug.h   | 30 ++---
 6 files changed, 22 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 0075184b5d93..7bcc22ef5d49 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -189,17 +189,7 @@ int amdgpu_vcnfw_log;
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 struct amdgpu_mgpu_info mgpu_info = {
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 8fa7a88299e7..3bc188cb1116 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -42,17 +42,7 @@
 #include "drm_dp_helper_internal.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 struct dp_aux_backlight {
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 2f747c9c8f60..5fb83336b015 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -52,17 +52,7 @@
 #include "drm_crtc_helper_internal.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b5b2542ae364..e959d0384ead 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -30,17 +30,7 @@
 #include "i915_drv.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");
+DYNDBG_CLASSMAP_USE(drm_debug_classes);
 #endif
 
 #define i915_param_named(name, T, perm, desc) \
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 2963cf5b0807..609edeb2a117 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -72,17 +72,7 @@
 #include "nouveau_dmem.h"
 
 #if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
-DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
-   "DRM_UT_CORE",
-   "DRM_UT_DRIVER",
-   "DRM_UT_KMS",
-   "DRM_UT_PRIME",
-   "DRM_UT_ATOMIC",
-   "DRM_UT_VBL",
-   "DRM_UT_STATE",
-   "DRM_UT_LEASE",
-   "DRM_UT_DP",
-   "DRM_UT_DRMRES");

[PATCH v2 03/20] dyndbg: replace classmap list with a vector

[Jim Cromie]

Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.

This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.

So this changes:

struct ddebug_class_map drops list-head link.

struct ddebug_table drops the list-head maps, and gets: classes &
num_classes for the start-addy and num_classes, placed to improve
struct packing.

The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.

The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.

Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.

This isn't technically a bugfix, but IMO simplifies later fixes for
the chicken-egg post-init enablement regression.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h |  1 -
 lib/dynamic_debug.c   | 61 ++-
 2 files changed, 32 insertions(+), 30 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 41682278d2e8..bf47bcfad8e6 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -81,7 +81,6 @@ enum class_map_type {
 };
 
 struct ddebug_class_map {
-   struct list_head link;
struct module *mod;
const char *mod_name;   /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 009f2ead09c1..823190094350 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
 extern struct ddebug_class_map __stop___dyndbg_classes[];
 
 struct ddebug_table {
-   struct list_head link, maps;
+   struct list_head link;
const char *mod_name;
-   unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+   struct ddebug_class_map *classes;
+   unsigned int num_ddebugs, num_classes;
 };
 
 struct ddebug_query {
@@ -146,13 +147,15 @@ static void vpr_info_dq(const struct ddebug_query *query, 
const char *msg)
  query->first_lineno, query->last_lineno, query->class_string);
 }
 
+#define __outvar /* filled by callee */
 static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table 
const *dt,
- const char 
*class_string, int *class_id)
+   const char 
*class_string,
+   __outvar int *class_id)
 {
struct ddebug_class_map *map;
-   int idx;
+   int i, idx;
 
-   list_for_each_entry(map, >maps, link) {
+   for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -163,7 +166,6 @@ static struct ddebug_class_map 
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
 }
 
-#define __outvar /* filled by callee */
 /*
  * Search the tables for _ddebug's which match the given `query' and
  * apply the `flags' and `mask' to them.  Returns number of matching
@@ -1107,9 +1109,10 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 
 static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map;
+   struct ddebug_class_map *map = iter->table->classes;
+   int i, nc = iter->table->num_classes;
 
-   list_for_each_entry(map, >table->maps, link)
+   for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1193,30 +1196,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
 };
 
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct 
_ddebug_info *di)
 {
struct ddebug_class_map *cm;
-   int i, j, ct = 0;
+   int i, nc = 0;
 
-   for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+   /*
+* Find this module's classmaps in a subrange/wholerange of
+* the 

[PATCH v2 10/20] dyndbg-API: split DECLARE_(DYNDBG_CLASSMAP) to $1(_DEFINE|_USE)

[Jim Cromie]

DECLARE_DYNDBG_CLASSMAP's job was to allow modules to declare the debug
classes/categories they want dyndbg to >control on their behalf.  Its
args give the class-names, their mapping to class_ids, and the sysfs
interface style (usually a class-bitmap).  Modules wanting a drm.debug
style knob need to create the kparam, and call module_param_cb() to
wire the sysfs node to the classmap.  DRM does this is in drm_print.c

In DRM, multiple modules declare identical DRM_UT_* classmaps, so that
the class'd prdbgs are modified across those modules in a coordinated
way across the subsystem, by either explicit class DRM_UT_* queries to
>control, or by writes to /sys/module/drm/parameters/debug (drm.debug)

This coordination-by-identical-declarations is weird, so this patch
splits the macro into _DEFINE and _USE flavors.  This distinction
follows the definition vs declaration that K gave us, improving the
api; _DEFINE is used once to specify the classmap, and multiple users
_USE the single definition explicitly.

Currently the latter just reuses the former, and still needs all the
same args, but that can be tuned later; the _DEFINE can initialize an
(extern/global) struct classmap, and _USE can, well use/reference
that struct.

Also wrap DYNDBG_CLASSMAP_USEs with ifdef DRM_USE_DYNAMIC_DEBUG to
balance with the one around drm_print's use of DYNDBG_CLASSMAP_DEFINE.

Signed-off-by: Jim Cromie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  4 +++-
 drivers/gpu/drm/display/drm_dp_helper.c |  4 +++-
 drivers/gpu/drm/drm_crtc_helper.c   |  4 +++-
 drivers/gpu/drm/drm_print.c |  2 +-
 drivers/gpu/drm/i915/i915_params.c  |  4 +++-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  4 +++-
 include/linux/dynamic_debug.h   | 20 
 lib/test_dynamic_debug.c| 32 -
 8 files changed, 48 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index bf2d50c8c92a..0075184b5d93 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -188,7 +188,8 @@ int amdgpu_vcnfw_log;
 
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -199,6 +200,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 struct amdgpu_mgpu_info mgpu_info = {
.mutex = __MUTEX_INITIALIZER(mgpu_info.mutex),
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c 
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6..8fa7a88299e7 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -41,7 +41,8 @@
 
 #include "drm_dp_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -52,6 +53,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 struct dp_aux_backlight {
struct backlight_device *base;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 7d86020b5244..2f747c9c8f60 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -51,7 +51,8 @@
 
 #include "drm_crtc_helper_internal.h"
 
-DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
+#if defined(CONFIG_DRM_USE_DYNAMIC_DEBUG)
+DYNDBG_CLASSMAP_USE(drm_debug_classes, DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_CORE",
"DRM_UT_DRIVER",
"DRM_UT_KMS",
@@ -62,6 +63,7 @@ DECLARE_DYNDBG_CLASSMAP(drm_debug_classes, 
DD_CLASS_TYPE_DISJOINT_BITS, 0,
"DRM_UT_LEASE",
"DRM_UT_DP",
"DRM_UT_DRMRES");
+#endif
 
 /**
  * DOC: overview
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 5b93c11895bb..4b697e18238d 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -56,7 +56,7 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit 
enables a debug cat
 module_param_named(debug, __drm_debug, ulong, 0600);
 #else
 /* classnames must match vals of enum drm_debug_category */

[PATCH v2 09/20] dyndbg: constify ddebug_apply_class_bitmap args

[Jim Cromie]

ddebug_apply_class_bitmap() does not alter its 2 bitmap args, make
this guarantee in the interface.

NOTE: the bitmap is also available in the dcp arg, but the 2 vars
serve a 2nd purpose; the CLASS_TYPE callers use them to translate
levels into their underlying disjoint representation.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 10c29bc19901..b51f4bde6198 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -592,7 +592,7 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new bitmap to the sys-knob's current bit-state */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits,
+const unsigned long *new_bits, const 
unsigned long *old_bits,
 const char *query_modname)
 {
 #define QUERY_SIZE 128
-- 
2.39.0

[PATCH v2 11/20] dyndbg-API: specialize DYNDBG_CLASSMAP_(DEFINE|USE)

[Jim Cromie]

Now that the DECLARE_DYNDBG_CLASSMAP macro has been split into
DYNDBG_CLASSMAP_DEFINE and DYNDBG_CLASSMAP_USE, lets differentiate
them according to their separate jobs.

Dyndbg's existing __dyndbg_classes[] section does:

. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.

This patch adds __dyndbg_class_refs[] section:

. catalogs references/uses of the above classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. maps the client module to classmap definitions
  drm-drivers and helpers are clients.
  this allows dyndbg to apply drm.debug to the client module, when added.

The distinction of the 2 roles yields 2 gains:

It follows the define-once-declare-elsewhere pattern that K gave us,
dumping the weird coordinated-changes-by-identical-classmaps API.

It should help solve the chicken-egg problem that DRM_USE_DYNAMIC_DEBUG
has; the _USEr module must propagate the drm.debug setting once the
using module has loaded.

The new DYNDBG_CLASSMAP_* macros add records to the sections:

DYNDBG_CLASSMAP_DEFINE:
  invoked just once per sub-system.
  for drm, its drm_print, where drm.debug is exposed.
  defines the classmap, names "DRM_UT_*", maps to class_id's
  authorizes dyndbg to exert >control
  populates __dyndbg_classes[] "section", __used.
  exports the classmap.

DYNDBG_CLASSMAP_USE:
  invoked by modules using classmaps defined & exported elsewhere
  populates __dyndbg_class_refs[] "section", __used.
  maps client-module name to the extern'd classmap.
  has client-name, so dyndbg can recognize loading client modules.

also:

struct ddebug_info gets 2 new fields to encapsulate the new section:
  class_refs, num_class_refs.
  set by dynamic_debug_init() for builtins.
  or by kernel/module/main:load_info() for loadable modules.

. struct ddebug_class_user
  contains: user-module-name, ref to classmap-defn
  dyndbg finds drm-driver's use of a classmap, gets/applies its settings

. vmlinux.lds.h additions: linker symbols, KEEP for new section

dynamic_debug.c: 2 sets of changes;
  those "under" ddebug_add_module(), immediately below
  those "under" ddebug_change(), further below

ddebug_attach_module_classes():
  as before:
  called from ddebug_add_module
  finds classmaps whose .mod_name matches module being added.
  attaches them to the module's ddebug_table.

ddebug_attach_client_module_classes():
  new:
  called from ddebug_add_module, after list-add to ddebug-tables.
  like above, but works class-refs, not classes.
  foreach __dyndbg_class_refs: ddebug_param_load_dependent_class(classmap*)

s/ddebug_find_kparams/ddebug_apply_parents_params/.

ddebug_find_kparam(classmap*):

scans module's/builtin kernel-params, calls ddebug_match_attach_kparam
for each to find the params/sysfs-nodes using a classmap.

ddebug_match_apply_kparam():

1st, it tests the kernel-param.ops is dyndbg's; this guarantees that
the attached arg is a struct ddebug_class_param, which has a ref to
the param's state.

Then compare the modname being loaded to the classmap.mod_name; if it
matches, save the debug_class_param into the classmap.dc_parm.  This
lets users of the classmap (in particular a client) access the state.

ddebug_param_load_dependent_class():

Called from ddebug_attach_client_module_classes() on each class_refs[]
entry.  Each user refs a classmap which has already been seen by
ddebug_find_kparam(), and whose .dc_parm has the state.

So this fn just copies the state to a local var, then calls
ddebug_apply_class_bitmap() to apply it to the dependent module.
ddebug_apply_class_bitmap() tests for bit changes before sending
messages without making changes.

ddebug_find_valid_class():

This helps ddebug_change(), doing the search over classmaps, looking
for the class given to >control.  So now it searches over
__dyndbg_class_refs[] after __dyndbg_classes[].

Thats the theory anyway.  things are still broken (differently) for
both builtins and loadables.  For loadables, the >control is applied,
but doesnt alter any callsites.  For builtins, things break earlier.

[*] consider swapping struct ddebug_class_param's dc_parm for kparam.
This gives access to kparam->name, helpful for current debugging.
Attaching that kp via macro would simplify attach-*module-classes too.

Signed-off-by: Jim Cromie 

Signed-off-by: Jim Cromie 

dyndbg: rework ddebug_(|client_)_module_attach_classes

move ddebug_attach_module_classes() up.

name-refinements++:

s/ddebug_param_load_dependent_class/ddebug_apply_parents_params/

Signed-off-by: Jim Cromie 
---
 include/asm-generic/vmlinux.lds.h |   3 +
 include/linux/dynamic_debug.h |  39 ---
 kernel/module/main.c  |   2 +
 lib/dynamic_debug.c   | 166 ++
 4 files changed, 176 insertions(+), 34 deletions(-)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 3dc5824141cd..7100701fb68c 100644

[PATCH v2 08/20] dyndbg: tighten ddebug_class_name() 1st arg

[Jim Cromie]

Change function's 1st arg-type, by derefing in the caller.
The fn doesnt need any other fields in the old type.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 2d4640479e5b..10c29bc19901 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1110,12 +1110,12 @@ static void *ddebug_proc_next(struct seq_file *m, void 
*p, loff_t *pos)
 #define class_in_range(class_id, map)  \
(class_id >= map->base && class_id < map->base + map->length)
 
-static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug 
*dp)
+static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug 
*dp)
 {
-   struct ddebug_class_map *map = iter->table->classes;
-   int i, nc = iter->table->num_classes;
+   struct ddebug_class_map *map = dt->classes;
+   int i;
 
-   for (i = 0; i < nc; i++, map++)
+   for (i = 0; i < dt->num_classes; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
 
@@ -1149,7 +1149,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
seq_puts(m, "\"");
 
if (dp->class_id != _DPRINTK_CLASS_DFLT) {
-   class = ddebug_class_name(iter, dp);
+   class = ddebug_class_name(iter->table, dp);
if (class)
seq_printf(m, " class:%s", class);
else
-- 
2.39.0

[PATCH v2 07/20] dyndbg: reduce verbose/debug clutter

[Jim Cromie]

currently, for verbose=3, this is logged:

 dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
 dyndbg: split into words: "class" "DRM_UT_CORE" "+p"

 dyndbg: op='+'
 dyndbg: flags=0x1
 dyndbg: *flagsp=0x1 *maskp=0x

 dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=DRM_UT_CORE
 dyndbg: no matches for query
 dyndbg: no-match: func="" file="" module="" format="" lineno=0-0 
class=DRM_UT_CORE
 dyndbg: processed 1 queries, with 0 matches, 0 errs

This patch:

shrinks 3 lines of 2nd stanza to single line

drops 2 middle lines of 3rd stanza
 3 differs from 1 only by status
 2 is just status, retold in 4, with more info.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 0a5efc735b36..2d4640479e5b 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -265,9 +265,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
 
-   if (!nfound && verbose)
-   pr_info("no matches for query\n");
-
return nfound;
 }
 
@@ -496,7 +493,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
pr_err("bad flag-op %c, at start of %s\n", *str, str);
return -EINVAL;
}
-   v3pr_info("op='%c'\n", op);
 
for (; *str ; ++str) {
for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) {
@@ -510,7 +506,6 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
return -EINVAL;
}
}
-   v3pr_info("flags=0x%x\n", modifiers->flags);
 
/* calculate final flags, mask based upon op */
switch (op) {
@@ -526,7 +521,7 @@ static int ddebug_parse_flags(const char *str, struct 
flag_settings *modifiers)
modifiers->flags = 0;
break;
}
-   v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags, 
modifiers->mask);
+   v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags, 
modifiers->mask);
 
return 0;
 }
@@ -536,7 +531,7 @@ static int ddebug_exec_query(char *query_string, const char 
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
 #define MAXWORDS 9
-   int nwords, nfound;
+   int nwords;
char *words[MAXWORDS];
 
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -554,10 +549,7 @@ static int ddebug_exec_query(char *query_string, const 
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
-   nfound = ddebug_change(, );
-   vpr_info_dq(, nfound ? "applied" : "no-match");
-
-   return nfound;
+   return ddebug_change(, );
 }
 
 /* handle multiple queries in query string, continue on error, return
-- 
2.39.0

[PATCH v2 05/20] dyndbg: split param_set_dyndbg_classes to inner/outer

[Jim Cromie]

Split param_set_dyndbg_classes() to interface-preserving wrapper &
inner function with an additional param: mod_name, which is passed
into ddebug_apply_class_bitmap() to allow adjusting a single module's
prdbgs.  Wrapper passes NULL, preserving current behavior for now.

no functional change.

Signed-off-by: Jim Cromie 
---
 lib/dynamic_debug.c | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 943e0597ecd4..0a5efc735b36 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -707,18 +707,9 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
return 0;
 }
 
-/**
- * param_set_dyndbg_classes - class FOO >control
- * @instr: string echo>d to sysfs, input depends on map_type
- * @kp:kp->arg has state: bits/lvl, map, map_type
- *
- * Enable/disable prdbgs by their class, as given in the arguments to
- * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
- * levels by bitpos.
- *
- * Returns: 0 or <0 if error.
- */
-int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+static int param_set_dyndbg_module_classes(const char *instr,
+  const struct kernel_param *kp,
+  const char *modnm)
 {
const struct ddebug_class_param *dcp = kp->arg;
const struct ddebug_class_map *map = dcp->map;
@@ -755,8 +746,8 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
KP_NAME(kp), inrep, 
CLASSMAP_BITMASK(map->length));
inrep &= CLASSMAP_BITMASK(map->length);
}
-   v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
+   v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*", 
KP_NAME(kp));
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -769,7 +760,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits, 
KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
NULL);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, _bits, 
modnm);
*dcp->lvl = inrep;
break;
default:
@@ -778,6 +769,21 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct);
return 0;
 }
+/**
+ * param_set_dyndbg_classes - class FOO >control
+ * @instr: string echo>d to sysfs, input depends on map_type
+ * @kp:kp->arg has state: bits/lvl, map, map_type
+ *
+ * Enable/disable prdbgs by their class, as given in the arguments to
+ * DECLARE_DYNDBG_CLASSMAP.  For LEVEL map-types, enforce relative
+ * levels by bitpos.
+ *
+ * Returns: 0 or <0 if error.
+ */
+int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+{
+   return param_set_dyndbg_module_classes(instr, kp, NULL);
+}
 EXPORT_SYMBOL(param_set_dyndbg_classes);
 
 /**
-- 
2.39.0

[PATCH v2 06/20] dyndbg: drop NUM_TYPE_ARRAY

[Jim Cromie]

ARRAY_SIZE works here, since array decl is complete.

Signed-off-by: Jim Cromie 
---
 include/linux/dynamic_debug.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index bf47bcfad8e6..81b643ab7f6e 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -104,11 +104,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base,  \
.map_type = _maptype,   \
-   .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+   .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames,   \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
 
 /* encapsulate linker provided built-in (or module) dyndbg data */
 struct _ddebug_info {
-- 
2.39.0

[PATCH v2 02/20] test-dyndbg: show that DEBUG enables prdbgs at compiletime

[Jim Cromie]

Dyndbg is required to enable prdbgs at compile-time if DEBUG is
defined.  Show this works; add the defn to test_dynamic_debug.c,
and manually inspect/verify its effect at module load:

[   15.292810] dyndbg: module:test_dynamic_debug attached 4 classes
[   15.293189] dyndbg:  32 debug prints in module test_dynamic_debug
[   15.293715] test_dd: init start
[   15.293716] test_dd: doing categories
[   15.293716] test_dd: LOW msg
...
[   15.293733] test_dd: L6 msg
[   15.293733] test_dd: L7 msg
[   15.293733] test_dd: init done

NOTES:

As is observable above, define DEBUG enables all prdbgs, including
those in mod_init-fn, and more notably, the class'd ones (callsites
with non-default class_ids).

This differs from the >control interface, which in order to properly
protect a client's class'd prdbgs, requires a "class FOO" in queries
to change them.  If this sounds wrong, note that the DEBUG is in the
module source file, and is thus privileged.

This yields an occaisional surprise; the following disables all the
compile-time enabled plain prdbgs, but leaves the class'd ones
enabled.

 :#> modprobe test_dynamic_debug dyndbg==_

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index a01f0193a419..89dd7f285e31 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -8,6 +8,8 @@
 
 #define pr_fmt(fmt) "test_dd: " fmt
 
+#define DEBUG /* enable all prdbgs (plain & class'd) at compiletime */
+
 #include 
 
 /* run tests by reading or writing sysfs node: do_prints */
-- 
2.39.0

[PATCH v2 04/20] dyndbg: make ddebug_apply_class_bitmap more selective

[Jim Cromie]

ddebug_apply_class_bitmap() currently applies the class settings to
all modules, by calling ddebug_exec_queries(query, NULL), where NULL
is wildcard ("*" does the same).  Make it more selective, by adding
query_module param, and passing it into ddebug_exec_queries, instead
of the NULL.

This allows its more selective use later; for propagating drm.debug
settings to dependent modules when/just-after they load.  Doing this
propagation with "*" is fine, but would match with all previously
loaded modules, creating more dynamic_debug.verbose=3 logging
activity, and obscuring the actual changes.

No functional change.

Signed-off-by: Jim Cromie 
---

after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.

bash-5.2# lsmod
Module  Size  Used by
i915 3133440  0
drm_buddy  20480  1 i915
ttm90112  1 i915
i2c_algo_bit   16384  1 i915
video  61440  1 i915
wmi32768  1 video
drm_display_helper200704  1 i915
drm_kms_helper208896  2 drm_display_helper,i915
drm   606208  5 
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344  2 drm_display_helper,i915
---
 lib/dynamic_debug.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 823190094350..943e0597ecd4 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -600,7 +600,8 @@ static int ddebug_exec_queries(char *query, const char 
*modname)
 
 /* apply a new bitmap to the sys-knob's current bit-state */
 static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long 
*old_bits)
+unsigned long *new_bits, unsigned long 
*old_bits,
+const char *query_modname)
 {
 #define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -608,7 +609,8 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
 
-   v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
+   v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
 
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -617,12 +619,15 @@ static int ddebug_apply_class_bitmap(const struct 
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s", 
map->class_names[bi],
 test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
 
-   ct = ddebug_exec_queries(query, NULL);
+   ct = ddebug_exec_queries(query, query_modname);
matches += ct;
 
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
  ct, map->class_names[bi], *new_bits);
}
+   v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits, 
*old_bits,
+ query_modname ?: "");
+
return matches;
 }
 
@@ -678,7 +683,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp), 
cls_id,
  map->class_names[cls_id]);
@@ -688,7 +693,7 @@ static int param_set_dyndbg_classnames(const char *instr, 
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0 
));
 
-   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits);
+   totct += ddebug_apply_class_bitmap(dcp, _bits, 
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n", 
KP_NAME(kp), cls_id,
  map->class_names[cls_id], old_bits, 
curr_bits);
@@ -751,7 +756,7 @@ int param_set_dyndbg_classes(const char *instr, const 
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
-   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+   totct += ddebug_apply_class_bitmap(dcp, , dcp->bits, 
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -764,7 +769,7 @@ int param_set_dyndbg_classes(const char *instr, 

[PATCH v2 01/20] test-dyndbg: fixup CLASSMAP usage error

[Jim Cromie]

more careful reading of test output reveals:

lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing 
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" 
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class 
unknown, _id:13

That last line is wrong, the HI class is declared.

But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP param).  So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report.  Basically, I coded in an error, and
forgot to verify it and remove it.

RFC:

This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP([1]), showing that
it is too error-prone.  As noted in test-dynamic-debug.c comments:

 * Using the CLASSMAP api:
 * - classmaps must have corresponding enum
 * - enum symbols must match/correlate with class-name strings in the map.
 * - base must equal enum's 1st value
 * - multiple maps must set their base to share the 0-62 class_id space !!
 *   (build-bug-on tips welcome)

Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist) used in DEFINE_DYNAMIC_DEBUG_CLASSMAP(), on
__VA_ARGS__ a 2nd time.  Then, DRM would pass DRM_UT_* ; all the
categories, in order, and not their stringifications, which created
all the usage complications above.

[1] name changed later to DYNDBG_CLASSMAP_DEFINE

Signed-off-by: Jim Cromie 
---
 lib/test_dynamic_debug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
 DD_SYS_WRAP(disjoint_bits, T);
 
 /* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
 DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
 DD_SYS_WRAP(disjoint_names, p);
-- 
2.39.0

[PATCH v2 00/20] DRM_USE_DYNAMIC_DEBUG regression

[Jim Cromie]

Hi everyone,

DRM_USE_DYNAMIC_DEBUG=y has a regression enabling drm.debug in drivers

It is due to a chicken-egg problem loading modules; on `modprobe
i915`, drm is loaded 1st, and drm/parameters/debug is set.  When
drm_debug_enabled() tested it at runtime, things just worked.

But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a
post-insmod enablement of drm_dbg/dyndbg callsites, via dyndbg's
callback on __drm_debug.  So with drm.ko loaded before the dependent
modules, their debug callsites arent present to be enabled.

OVERVIEW

As Jani Nikula noted rather more gently, DECLARE_DYNDBG_CLASSMAP is
error-prone enough to call broken: it relied upon identical classmap
definitions in all modules using DRM_UT_*.  IOW, it muddled the K
distinction between a (single) definition, and multiple references.

So 4 patches here split it into:

DYNDBG_CLASSMAP_DEFINE  used once per subsystem to define each classmap.
DYNDBG_CLASSMAP_USE declare dependence on a DEFINEd classmap.

This makes the weird coordinated-changes-by-identical-classmaps
"feature" unnecessary.

DYNDBG_CLASSMAP_DEFINE initializes the classmap, stores it into the
(existing) __dyndbg_classes section, and exports the struct var
(unlike DECLARE_DYNDBG_CLASSMAP).

DYNDBG_CLASSMAP_USE initializes a class-ref struct, containing the
user-module-name, and a ref to the exported classmap var.

The distinction allows separate treatment of classmaps and
classmap-refs, the latter getting additional behavior to propagate
class'd prdbg settings to modules being loaded.

Consider i915.ko, a DYNDBG_CLASSMAP_USEr: due to dependencies,
`modprobe drm debug=$val` is done 1st.  For DRM_USE_DYNAMIC_DEBUG=y,
drm.debug=$val invokes dyndbg's kparam callback, which applies "class
DRM_UT_*" >controls as given by the bits.  But i915.ko isn't modprobed
yet, so misses those >controls.  These must be 're-delivered' when
i915 is modprobed.

Recapitulating ddebug_attach_module_classes(1) for (existing) classes;
ddebug_attach_client_module_classes(2) does this for (new) class-refs,
as they are found when modprobing drm-drivers.

2 calls ddebug_apply_parents_params(3) on each referred classmap defn.

3 scans kernel-params owned by the module DEFINEing the classmap,
either builtin or loadable, calls ddebug_match_apply_kparam(4) on each.

4 finds those kparams wired to dyndbg's param-ops, which are therefore
castable to struct ddebug_class_param, and have a ref to the classmap
that they "control".  So 4 finds classmap definitions whose owner
matches the user-module being loaded, and applies the kparam's state
(__drm_debug in this case) by calling ddebug_apply_class_bitmap().

test_dynamic_debug is extended to recreate DRM's multi-module
regression, it builds both test_dynamic_debug.ko and _submod.ko, with
an ifdef to _DEFINE in the main module, and _USE in the submod.  This
gives both modules identical set of prdbgs, which is helpful for
humans comparing results.

STATUS

here it is, "working":

doing class DRM_UT_CORE -p
[ 9904.961750] dyndbg: read 21 bytes from userspace
[ 9904.962286] dyndbg: query 0: "class DRM_UT_CORE -p" mod:*
[ 9904.962848] dyndbg: split into words: "class" "DRM_UT_CORE" "-p"
[ 9904.963444] dyndbg: op='-' flags=0x0 maskp=0xfffe
[ 9904.963945] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=DRM_UT_CORE
[ 9904.964781] dyndbg: good-class: drm.DRM_UT_CORE  module:drm nd:302 nc:1 nu:0
[ 9904.966411] dyndbg: class-ref: drm_kms_helper.DRM_UT_CORE  
module:drm_kms_helper nd:95 nc:0 nu:1
[ 9904.967265] dyndbg: class-ref: drm_display_helper.DRM_UT_CORE  
module:drm_display_helper nd:150 nc:0 nu:1
[ 9904.968349] dyndbg: class-ref: i915.DRM_UT_CORE  module:i915 nd:1659 nc:0 
nu:1
[ 9904.969801] dyndbg: class-ref: amdgpu.DRM_UT_CORE  module:amdgpu nd:4425 
nc:0 nu:1
[ 9904.977079] dyndbg: class-ref: nouveau.DRM_UT_CORE  module:nouveau nd:103 
nc:0 nu:1
[ 9904.977830] dyndbg: processed 1 queries, with 507 matches, 0 errs
doing class DRM_UT_DRIVER +p
[ 9906.151761] dyndbg: read 23 bytes from userspace
[ 9906.152241] dyndbg: query 0: "class DRM_UT_DRIVER +p" mod:*
[ 9906.152793] dyndbg: split into words: "class" "DRM_UT_DRIVER" "+p"
[ 9906.153388] dyndbg: op='+' flags=0x1 maskp=0x
[ 9906.153896] dyndbg: parsed: func="" file="" module="" format="" lineno=0-0 
class=DRM_UT_DRIVER
[ 9906.154746] dyndbg: good-class: drm.DRM_UT_DRIVER  module:drm nd:302 nc:1 
nu:0
[ 9906.155433] dyndbg: class-ref: drm_kms_helper.DRM_UT_DRIVER  
module:drm_kms_helper nd:95 nc:0 nu:1
[ 9906.156267] dyndbg: class-ref: drm_display_helper.DRM_UT_DRIVER  
module:drm_display_helper nd:150 nc:0 nu:1
[ 9906.157365] dyndbg: class-ref: i915.DRM_UT_DRIVER  module:i915 nd:1659 nc:0 
nu:1
[ 9906.163848] dyndbg: class-ref: amdgpu.DRM_UT_DRIVER  module:amdgpu nd:4425 
nc:0 nu:1
[ 9906.178963] dyndbg: class-ref: nouveau.DRM_UT_DRIVER  module:nouveau nd:103 
nc:0 nu:1
[ 9906.179934] dyndbg: processed 1 queries, with 1286 matches, 0 errs

It is still WIP, but Daniel 

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Lyude Paul]

On Fri, 2023-01-13 at 11:25 +0100, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
> > 
> > Cc: intel-gfx, drm maintainers
> > 
> > Please have the courtesy of Cc'ing us for changes impacting us, and
> > maybe try to involve us earlier instead of surprising us like
> > this. Looks like this has been debugged for at least three months, and
> > the huge revert at this point is going to set us back with what's been
> > developed on top of it for i915 DP MST and DSC.
> 
> tbf I assumed this wont land when I've seen it fly by. It feels a bit much
> like living under a rock for half a year and then creating a mess for
> everyone else who's been building on top of this is not great.
> 
> Like yes it's a regression, but apparently not a blantantly obvious one,
> and I think if we just ram this in there's considerable community goodwill
> down the drain. Someone needs to get that goodwill up the drain again.
> 
> > It's a regression, I get that, but this is also going to be really nasty
> > to deal with. It's a 2500-line commit, plus the dependencies, which I
> > don't think are accounted for here. (What's the baseline for the revert
> > anyway?) I don't expect all the dependent commits to be easy to revert
> > or backport to v6.1 or v6.2.
> > 
> > *sad trombone*
> 
> Yeah that's the other thing. 2500 patch revert is not cc stable material.
> So this isn't even really helping users all that much.
> 
> Unless it also comes with full amounts of backports of the reverts on all
> affected drivers for all curent stable trees, fully validated.
> 
> This is bad. I do think we need to have some understanding first of what
> "fix this in amdgpu" would look like as plan B. Because plan A does not
> look like a happy one at all.

Yeah this whole thing has been a mess, I'm partially to blame here - we should
have reverted earlier, but a lot of this has been me finding out that the
problem here is a lot bigger then I previously imagined - and has not at all
been easy to untangle. I've also dumped so much time into trying to figure it
out that was more or less the only reason I acked this in the first place, I'm
literally just quite tired and exhausted at this point from spinning my wheels
on trying to fix this ;_;.

I am sure there is a real proper fix for this, if anyone wants to help me try
and figure this out I'm happy to setup remote access to the machines I've got
here. I'll also try to push myself to dig further into this next week again.

> -Daniel
> 
> > BR,
> > Jani.
> > 
> > 
> > On Thu, 12 Jan 2023, Wayne Lin  wrote:
> > > This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
> > > 
> > > [Why]
> > > Changes cause regression on amdgpu mst.
> > > E.g.
> > > In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove 
> > > payload
> > > one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
> > > maintained payload table. But previous change tries to go through all the
> > > payloads in mst_state and update amdpug hw maintained table in once 
> > > everytime
> > > driver only tries to add/remove a specific payload stream only. The newly
> > > design idea conflicts with the implementation in amdgpu nowadays.
> > > 
> > > [How]
> > > Revert this patch first. After addressing all regression problems caused 
> > > by
> > > this previous patch, will add it back and adjust it.
> > > 
> > > Signed-off-by: Wayne Lin 
> > > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
> > > Cc: sta...@vger.kernel.org # 6.1
> > > Cc: Lyude Paul 
> > > Cc: Harry Wentland 
> > > Cc: Mario Limonciello 
> > > Cc: Ville Syrjälä 
> > > Cc: Ben Skeggs 
> > > Cc: Stanislav Lisovskiy 
> > > Cc: Fangzhi Zuo 
> > > ---
> > >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  53 +-
> > >  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 106 ++-
> > >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  87 ++-
> > >  .../amd/display/include/link_service_types.h  |   3 -
> > >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 724 --
> > >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  67 +-
> > >  drivers/gpu/drm/i915/display/intel_hdcp.c |  24 +-
> > >  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 167 ++--
> > >  include/drm/display/drm_dp_mst_helper.h   | 177 +++--
> > >  9 files changed, 878 insertions(+), 530 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > index 77277d90b6e2..674f5dc1102b 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > @@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct 
> > > drm_encoder *encoder,
> > >   const struct drm_display_mode *adjusted_mode = 
> > > _state->adjusted_mode;
> > >   struct drm_dp_mst_topology_mgr *mst_mgr;
> > >   struct drm_dp_mst_port *mst_port;
> > > - struct drm_dp_mst_topology_state 

Re: [PATCH 2/2] drm/amdgpu/pm: update hwmon power documentation

[Alex Deucher]

Can someone review this patch (2/2)?  1/2 is superseded by Jesse's
patch, but this one still makes sense.

Thanks

On Thu, Jan 12, 2023 at 11:25 AM Alex Deucher  wrote:
>
> Power reporting is socket power.  On APUs this includes
> the CPU.  Update the documentation to clarify this.
>
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c 
> b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> index 236657eece47..76b9ec64ca50 100644
> --- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
> @@ -3059,7 +3059,7 @@ static ssize_t amdgpu_hwmon_show_mclk_label(struct 
> device *dev,
>   *
>   * hwmon interfaces for GPU power:
>   *
> - * - power1_average: average power used by the GPU in microWatts
> + * - power1_average: average power used by the SoC in microWatts.  On APUs 
> this includes the CPU.
>   *
>   * - power1_cap_min: minimum cap supported in microWatts
>   *
> --
> 2.39.0
>

Re: [PATCH] drm/amdgpu: Add a missing tab

[Alex Deucher]

Applied.  Thanks!

Alex

On Fri, Jan 13, 2023 at 9:46 AM Dan Carpenter  wrote:
>
> This tab was deleted accidentally and triggers a Smatch warning:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1006 gfx_v8_0_init_microcode()
> warn: inconsistent indenting
>
> Add it back.
>
> Fixes: 0aaafb7359d2 ("drm/amd: Use `amdgpu_ucode_*` helpers for GFX8")
> Signed-off-by: Dan Carpenter 
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 4fb577d047fd..b1f2684d854a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -1003,7 +1003,7 @@ static int gfx_v8_0_init_microcode(struct amdgpu_device 
> *adev)
> err = amdgpu_ucode_request(adev, >gfx.me_fw, fw_name);
> if (err == -ENODEV) {
> snprintf(fw_name, sizeof(fw_name), 
> "amdgpu/%s_me.bin", chip_name);
> -   err = amdgpu_ucode_request(adev, >gfx.me_fw, fw_name);
> +   err = amdgpu_ucode_request(adev, >gfx.me_fw, 
> fw_name);
> }
> } else {
> snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", 
> chip_name);
> --
> 2.35.1

Re: [RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression

[Daniel Vetter]

On Fri, Jan 13, 2023 at 11:29:57AM -0700, jim.cro...@gmail.com wrote:
> On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter  wrote:
> >
> > On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > > Hi everyone,
> > >
> > > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> > >
> > > Regression is due to a chicken-egg problem loading modules; on
> > > `modprobe i915`, drm is loaded 1st, and drm.debug is set.  When
> > > drm_debug_enabled() tested __drm_debug at runtime, that just worked.
> > >
> > > But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a
> > > post-load enablement of drm_dbg/dyndbg callsites (static-keys), via
> > > dyndbg's callback on __drm_debug.  Since all drm-drivers need drm.ko,
> > > it is loaded 1st, then drm.debug=X is applied, then drivers load, but
> > > too late for drm_dbgs to be enabled.
> > >
> > > STATUS
> > >
> > > For all-loadable drm,i915,amdgpu configs, it almost works, but
> > > propagating drm.debug to dependent modules doesnt actually apply,
> > > though the motions are there.  This is not the problem I want to chase
> > > here.
> > >
> > > The more basic trouble is:
> > >
> > > For builtin drm + helpers, things are broken pretty early; at the
> > > beginning of dynamic_debug_init().  As the ddebug_sanity() commit-msg
> > > describes in some detail, the records added by _USE fail to reference
> > > the struct ddebug_class_map created and exported by _DEFINE, but get
> > > separate addresses to "other" data that segv's when used as the
> > > expected pointer. FWIW, the pointer val starts with "revi".
> >
> > So I honestly have no idea here, linker stuff is way beyond where I have
> > clue. So what's the way forward here?
> >
> 
> Ive fixed this aspect.
> Unsurprisingly, it wasnt the linker :-}

Awesome!

> > The DEFINE/USE split does like the right thing to do at least from the
> > "how it's used in drivers" pov. But if we're just running circles not
> > quite getting there I dunno :-/
> > -Daniel
> >
> 
> Sending new rev next.
> I think its getting close.

Thanks a lot for keeping on pushing this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [RFC PATCH 00/17] DRM_USE_DYNAMIC_DEBUG regression

[jim . cromie]

On Wed, Jan 11, 2023 at 4:09 PM Daniel Vetter  wrote:
>
> On Mon, Dec 05, 2022 at 05:34:07PM -0700, Jim Cromie wrote:
> > Hi everyone,
> >
> > DRM_USE_DYNAMIC_DEBUG=y has a regression on rc-*
> >
> > Regression is due to a chicken-egg problem loading modules; on
> > `modprobe i915`, drm is loaded 1st, and drm.debug is set.  When
> > drm_debug_enabled() tested __drm_debug at runtime, that just worked.
> >
> > But with DRM_USE_DYNAMIC_DEBUG=y, the runtime test is replaced with a
> > post-load enablement of drm_dbg/dyndbg callsites (static-keys), via
> > dyndbg's callback on __drm_debug.  Since all drm-drivers need drm.ko,
> > it is loaded 1st, then drm.debug=X is applied, then drivers load, but
> > too late for drm_dbgs to be enabled.
> >
> > STATUS
> >
> > For all-loadable drm,i915,amdgpu configs, it almost works, but
> > propagating drm.debug to dependent modules doesnt actually apply,
> > though the motions are there.  This is not the problem I want to chase
> > here.
> >
> > The more basic trouble is:
> >
> > For builtin drm + helpers, things are broken pretty early; at the
> > beginning of dynamic_debug_init().  As the ddebug_sanity() commit-msg
> > describes in some detail, the records added by _USE fail to reference
> > the struct ddebug_class_map created and exported by _DEFINE, but get
> > separate addresses to "other" data that segv's when used as the
> > expected pointer. FWIW, the pointer val starts with "revi".
>
> So I honestly have no idea here, linker stuff is way beyond where I have
> clue. So what's the way forward here?
>

Ive fixed this aspect.
Unsurprisingly, it wasnt the linker :-}

> The DEFINE/USE split does like the right thing to do at least from the
> "how it's used in drivers" pov. But if we're just running circles not
> quite getting there I dunno :-/
> -Daniel
>

Sending new rev next.
I think its getting close.

Re: [PATCH v3 2/3] drm/amdgpu: Remove redundant framebuffer format check

[Maíra Canal]

On 1/13/23 14:06, Simon Ser wrote:

Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.

I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check in framebuffer_init()? (Not sure!)


Considering that we could then remove the check from i915 and amdgpu if
we move the check to framebuffer_init(), I believe that this would be a
good reason to perform the check there. I'll send a v4 including the check
on framebuffer_init() and removing the check from i915.

Thanks for the feedback!

Best Regards,
- Maíra Canal

Re: [PATCH v3 1/3] drm/framebuffer: Check for valid formats

[Simon Ser]

On Friday, January 13th, 2023 at 17:59, Maíra Canal  wrote:

> + /* Verify that the modifier is supported. */
> + if (r->modifier[0] && drm_drv_uses_atomic_modeset(dev) &&
> + !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
> + drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 
> 0x%llx\n",
> + >pixel_format, r->modifier[0]);
> + return -EINVAL;
> + }

User-space indicates whether there is a modifier in the IOCTL data by supplying
the DRM_MODE_FB_MODIFIERS flag. I believe we need to check that flag instead of
r->modifier[0]: the zero modifier is a valid modifier (LINEAR).

Re: [PATCH v3 2/3] drm/amdgpu: Remove redundant framebuffer format check

[Simon Ser]

Hm, unfortunately I think we need to keep the check in amdgpu for the
same reason as i915: amdgpu will pick a modifier if user-space didn't
supply one on GFX9+.

I wonder if that also applies to vmwgfx? Maybe that would be a reason
to have the check in framebuffer_init()? (Not sure!)

[PATCH v3 3/3] drm/vmwgfx: Remove redundant framebuffer format check

[Maíra Canal]

Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on vmwgfx's inside
helpers.

Therefore, remove the redundant framebuffer format check from the
vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_bo()
functions, letting framebuffer_check() perform the framebuffer
validation.

Reviewed-by: Zack Rusin 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 257f090071f1..05b8d8f912bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1317,15 +1317,6 @@ static int vmw_kms_new_framebuffer_surface(struct 
vmw_private *dev_priv,
 * Sanity checks.
 */
 
-   if (!drm_any_plane_has_format(_priv->drm,
- mode_cmd->pixel_format,
- mode_cmd->modifier[0])) {
-   drm_dbg(_priv->drm,
-   "unsupported pixel format %p4cc / modifier 0x%llx\n",
-   _cmd->pixel_format, mode_cmd->modifier[0]);
-   return -EINVAL;
-   }
-
/* Surface must be marked as a scanout. */
if (unlikely(!surface->metadata.scanout))
return -EINVAL;
@@ -1648,15 +1639,6 @@ static int vmw_kms_new_framebuffer_bo(struct vmw_private 
*dev_priv,
return -EINVAL;
}
 
-   if (!drm_any_plane_has_format(_priv->drm,
- mode_cmd->pixel_format,
- mode_cmd->modifier[0])) {
-   drm_dbg(_priv->drm,
-   "unsupported pixel format %p4cc / modifier 0x%llx\n",
-   _cmd->pixel_format, mode_cmd->modifier[0]);
-   return -EINVAL;
-   }
-
vfbd = kzalloc(sizeof(*vfbd), GFP_KERNEL);
if (!vfbd) {
ret = -ENOMEM;
-- 
2.39.0

[PATCH v3 0/3] Check for valid framebuffer's format

[Maíra Canal]

This series is a follow-up of the [1] in which I introduced a check for valid
formats on drm_gem_fb_create(). During the discussion, I realized that would be
a better idea to put the check inside framebuffer_check() so that it wouldn't be
needed to hit any driver-specific code path when the check fails.

Therefore, add the valid format check inside framebuffer_check() and remove the
same check from the drivers, except from i915, because this doesn't work for the
legacy tiling->modifier path. Adding the check to framebuffer_check() will
guarantee that the igt@kms_addfb_basic@addfb25-bad-modifier IGT test passes,
showing the correct behavior of the check.

This patchset was tested on amdgpu and vc4 with the IGT tests.

[1] 
https://lore.kernel.org/dri-devel/20230103125322.855089-1-mca...@igalia.com/T/

---

v1 -> v2: 
https://lore.kernel.org/dri-devel/20230109105807.18172-1-mca...@igalia.com/T/

- Don't remove check from i915 driver (Ville Syrjälä).
- Don't unexport drm_any_plane_has_format().

v2 -> v3: 
https://lore.kernel.org/dri-devel/20230113112743.188486-1-mca...@igalia.com/T/

- Check if r->modifier[0] != 0 (Ville Syrjälä).

---

Best Regards,
- Maíra Canal

Maíra Canal (3):
  drm/framebuffer: Check for valid formats
  drm/amdgpu: Remove redundant framebuffer format check
  drm/vmwgfx: Remove redundant framebuffer format check

 Documentation/gpu/todo.rst  |  9 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 10 --
 drivers/gpu/drm/drm_framebuffer.c   |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
 4 files changed, 12 insertions(+), 33 deletions(-)

-- 
2.39.0

[PATCH v3 2/3] drm/amdgpu: Remove redundant framebuffer format check

[Maíra Canal]

Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on amdgpu's inside
helpers.

Therefore, remove the redundant framebuffer format check from the
amdgpu_display_gem_fb_verify_and_init() function, letting
framebuffer_check() perform the framebuffer validation.

Reviewed-by: Simon Ser 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index b22471b3bd63..611b7a4b086c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1120,16 +1120,6 @@ static int amdgpu_display_gem_fb_verify_and_init(struct 
drm_device *dev,
 
rfb->base.obj[0] = obj;
drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
-   /* Verify that the modifier is supported. */
-   if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
- mode_cmd->modifier[0])) {
-   drm_dbg_kms(dev,
-   "unsupported pixel format %p4cc / modifier 
0x%llx\n",
-   _cmd->pixel_format, mode_cmd->modifier[0]);
-
-   ret = -EINVAL;
-   goto err;
-   }
 
ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
if (ret)
-- 
2.39.0

[PATCH v3 1/3] drm/framebuffer: Check for valid formats

[Maíra Canal]

Currently, framebuffer_check() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
calls with invalid formats.

Moreover, note that this check is only valid for atomic drivers,
because, for non-atomic drivers, checking drm_any_plane_has_format() is
not possible since the format list for the primary plane is fake, and
we'd therefore reject valid formats.

Reviewed-by: Daniel Vetter 
Signed-off-by: Maíra Canal 
---
 Documentation/gpu/todo.rst| 9 -
 drivers/gpu/drm/drm_framebuffer.c | 8 
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 1f8a5ebe188e..3a79c26c5cc7 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -276,11 +276,10 @@ Various hold-ups:
 - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
   setup code can't be deleted.
 
-- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
-  atomic drivers we could check for valid formats by calling
-  drm_plane_check_pixel_format() against all planes, and pass if any plane
-  supports the format. For non-atomic that's not possible since like the format
-  list for the primary plane is fake and we'd therefor reject valid formats.
+- Need to switch to drm_gem_fb_create(), as now framebuffer_check() checks for
+  valid formats for atomic drivers.
+
+- Add an addfb format validation for non-atomic drivers.
 
 - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
   version of the varios drm_gem_fb_create functions. Maybe called
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index aff3746dedfb..0afc9e39188a 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -280,6 +280,14 @@ static int framebuffer_check(struct drm_device *dev,
}
}
 
+   /* Verify that the modifier is supported. */
+   if (r->modifier[0] && drm_drv_uses_atomic_modeset(dev) &&
+   !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
+   drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 
0x%llx\n",
+   >pixel_format, r->modifier[0]);
+   return -EINVAL;
+   }
+
return 0;
 }
 
-- 
2.39.0

Re: [PATCH] drm/amdgpu: fix cleaning up reserved VMID on release

[Alex Deucher]

On Fri, Jan 13, 2023 at 11:35 AM Christian König
 wrote:
>
> We need to reset this or otherwise run into list corruption later on./

Drop the / above.
Reviewed-by: Alex Deucher 

>
> Fixes: 16be3e9f6f03 ("drm/amdgpu: rework reserved VMID handling")
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> index 6481b43ffe25..a0545d51b6bd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
> @@ -499,6 +499,7 @@ void amdgpu_vmid_free_reserved(struct amdgpu_device *adev,
> !--id_mgr->reserved_use_count) {
> /* give the reserved ID back to normal round robin */
> list_add(_mgr->reserved->list, _mgr->ids_lru);
> +   id_mgr->reserved = NULL;
> }
> vm->reserved_vmid[vmhub] = false;
> mutex_unlock(_mgr->lock);
> --
> 2.34.1
>

[PATCH] drm/amdgpu: fix cleaning up reserved VMID on release

[Christian König]

We need to reset this or otherwise run into list corruption later on./

Fixes: 16be3e9f6f03 ("drm/amdgpu: rework reserved VMID handling")
Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index 6481b43ffe25..a0545d51b6bd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
@@ -499,6 +499,7 @@ void amdgpu_vmid_free_reserved(struct amdgpu_device *adev,
!--id_mgr->reserved_use_count) {
/* give the reserved ID back to normal round robin */
list_add(_mgr->reserved->list, _mgr->ids_lru);
+   id_mgr->reserved = NULL;
}
vm->reserved_vmid[vmhub] = false;
mutex_unlock(_mgr->lock);
-- 
2.34.1

[PATCH v2 18/21] drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not RGB

[Harry Wentland]

From: Joshua Ashton 

Userspace might not aware whether we're sending RGB or YCbCr
data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is
requested but the output encoding is YCbCr we should
send COLOR_SPACE_2020_YCBCR.

Signed-off-by: Joshua Ashton 
Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f74b125af31f..16940ea61b59 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5184,7 +5184,10 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing,
color_space = COLOR_SPACE_ADOBERGB;
break;
case DRM_MODE_COLORIMETRY_BT2020_RGB:
-   color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+   if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB)
+   color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+   else
+   color_space = COLOR_SPACE_2020_YCBCR;
break;
case DRM_MODE_COLORIMETRY_BT2020_YCC:
color_space = COLOR_SPACE_2020_YCBCR;
-- 
2.39.0

[PATCH v2 19/21] drm/amd/display: Refactor avi_info_frame colorimetry determination

[Harry Wentland]

From: Joshua Ashton 

Replace the messy two if-else chains here that were
on the same value with a switch on the enum.

Signed-off-by: Joshua Ashton 
Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland 
---
 .../gpu/drm/amd/display/dc/core/dc_resource.c | 28 +++
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
index 06b5f49e0954..151981217c5f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c
@@ -3010,23 +3010,29 @@ static void set_avi_info_frame(
hdmi_info.bits.S0_S1 = scan_type;
 
/* C0, C1 : Colorimetry */
-   if (color_space == COLOR_SPACE_YCBCR709 ||
-   color_space == COLOR_SPACE_YCBCR709_LIMITED)
+   switch (color_space) {
+   case COLOR_SPACE_YCBCR709:
+   case COLOR_SPACE_YCBCR709_LIMITED:
hdmi_info.bits.C0_C1 = COLORIMETRY_ITU709;
-   else if (color_space == COLOR_SPACE_YCBCR601 ||
-   color_space == COLOR_SPACE_YCBCR601_LIMITED)
+   break;
+   case COLOR_SPACE_YCBCR601:
+   case COLOR_SPACE_YCBCR601_LIMITED:
hdmi_info.bits.C0_C1 = COLORIMETRY_ITU601;
-   else {
-   hdmi_info.bits.C0_C1 = COLORIMETRY_NO_DATA;
-   }
-   if (color_space == COLOR_SPACE_2020_RGB_FULLRANGE ||
-   color_space == COLOR_SPACE_2020_RGB_LIMITEDRANGE ||
-   color_space == COLOR_SPACE_2020_YCBCR) {
+   break;
+   case COLOR_SPACE_2020_RGB_FULLRANGE:
+   case COLOR_SPACE_2020_RGB_LIMITEDRANGE:
+   case COLOR_SPACE_2020_YCBCR:
hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_BT2020RGBYCBCR;
hdmi_info.bits.C0_C1   = COLORIMETRY_EXTENDED;
-   } else if (color_space == COLOR_SPACE_ADOBERGB) {
+   break;
+   case COLOR_SPACE_ADOBERGB:
hdmi_info.bits.EC0_EC2 = COLORIMETRYEX_ADOBERGB;
hdmi_info.bits.C0_C1   = COLORIMETRY_EXTENDED;
+   break;
+   case COLOR_SPACE_SRGB:
+   default:
+   hdmi_info.bits.C0_C1 = COLORIMETRY_NO_DATA;
+   break;
}
 
if (pixel_encoding && color_space == COLOR_SPACE_2020_YCBCR &&
-- 
2.39.0

[PATCH v2 21/21] drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix

[Harry Wentland]

From: Joshua Ashton 

Signed-off-by: Joshua Ashton 
Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
index a70f045fc5c1..2acbf692193f 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
@@ -98,9 +98,9 @@ static const struct out_csc_color_matrix_type 
output_csc_matrix[] = {
  0x6CE, 0x16E3, 0x24F,  0x200,
  0xFCCB, 0xF535, 0xE00, 0x1000} },
{ COLOR_SPACE_YCBCR2020_TYPE,
-   { 0x1000, 0xF149, 0xFEB7, 0x,
- 0x0868, 0x15B2, 0x01E6, 0x,
- 0xFB88, 0xF478, 0x1000, 0x} },
+   { 0x1000, 0xF149, 0xFEB7, 0x1004,
+ 0x0868, 0x15B2, 0x01E6, 0x201,
+ 0xFB88, 0xF478, 0x1000, 0x1004} },
{ COLOR_SPACE_YCBCR709_BLACK_TYPE,
{ 0x, 0x, 0x, 0x1000,
  0x, 0x, 0x, 0x0200,
-- 
2.39.0

[PATCH v2 14/21] drm/amd/display: Add debugfs for testing output colorspace

[Harry Wentland]

In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.

This might also come in handy when debugging display
issues.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 57 +++
 1 file changed, 57 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index a29952cd8f22..5473f022d9ed 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -935,6 +935,61 @@ static int amdgpu_current_bpc_show(struct seq_file *m, 
void *data)
 }
 DEFINE_SHOW_ATTRIBUTE(amdgpu_current_bpc);
 
+/*
+ * Returns the current bpc for the crtc.
+ * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/amdgpu_current_colorspace
+ */
+static int amdgpu_current_colorspace_show(struct seq_file *m, void *data)
+{
+   struct drm_crtc *crtc = m->private;
+   struct drm_device *dev = crtc->dev;
+   struct dm_crtc_state *dm_crtc_state = NULL;
+   int res = -ENODEV;
+
+   mutex_lock(>mode_config.mutex);
+   drm_modeset_lock(>mutex, NULL);
+   if (crtc->state == NULL)
+   goto unlock;
+
+   dm_crtc_state = to_dm_crtc_state(crtc->state);
+   if (dm_crtc_state->stream == NULL)
+   goto unlock;
+
+   switch (dm_crtc_state->stream->output_color_space) {
+   case COLOR_SPACE_SRGB:
+   seq_printf(m, "RGB");
+   break;
+   case COLOR_SPACE_YCBCR601:
+   case COLOR_SPACE_YCBCR601_LIMITED:
+   seq_printf(m, "BT601_YCC");
+   break;
+   case COLOR_SPACE_YCBCR709:
+   case COLOR_SPACE_YCBCR709_LIMITED:
+   seq_printf(m, "BT709_YCC");
+   break;
+   case COLOR_SPACE_ADOBERGB:
+   seq_printf(m, "opRGB");
+   break;
+   case COLOR_SPACE_2020_RGB_FULLRANGE:
+   seq_printf(m, "BT2020_RGB");
+   break;
+   case COLOR_SPACE_2020_YCBCR:
+   seq_printf(m, "BT2020_YCC");
+   break;
+   default:
+   goto unlock;
+   }
+   res = 0;
+
+unlock:
+   drm_modeset_unlock(>mutex);
+   mutex_unlock(>mode_config.mutex);
+
+   return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);
+
+
 /*
  * Example usage:
  * Disable dsc passthrough, i.e.,: have dsc decoding at converver, not 
external RX
@@ -3304,6 +3359,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
 #endif
debugfs_create_file("amdgpu_current_bpc", 0644, crtc->debugfs_entry,
crtc, _current_bpc_fops);
+   debugfs_create_file("amdgpu_current_colorspace", 0644, 
crtc->debugfs_entry,
+   crtc, _current_colorspace_fops);
 }
 
 /*
-- 
2.39.0

[PATCH v2 03/21] drm/connector: Drop COLORIMETRY_NO_DATA

[Harry Wentland]

The value is the same as DEFAULT. The HDMI_COLORIMETRY_NO_DATA
makes sense for the infopacket but it's meaningless for the
connector colorspace. or, in otherwise, just means to go with
driver default.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/display/drm_hdmi_helper.c | 2 +-
 include/drm/drm_connector.h   | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c 
b/drivers/gpu/drm/display/drm_hdmi_helper.c
index faf5e9efa7d3..c1e6851b2606 100644
--- a/drivers/gpu/drm/display/drm_hdmi_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
@@ -103,7 +103,7 @@ EXPORT_SYMBOL(drm_hdmi_infoframe_set_hdr_metadata);
 #define HDMI_COLORIMETRY_DCI_P3_RGB_THEATER(C(3) | EC(7) | ACE(1))
 
 static const u32 hdmi_colorimetry_val[] = {
-   [DRM_MODE_COLORIMETRY_NO_DATA] = HDMI_COLORIMETRY_NO_DATA,
+   [DRM_MODE_COLORIMETRY_DEFAULT] = HDMI_COLORIMETRY_NO_DATA,
[DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = HDMI_COLORIMETRY_SMPTE_170M_YCC,
[DRM_MODE_COLORIMETRY_BT709_YCC] = HDMI_COLORIMETRY_BT709_YCC,
[DRM_MODE_COLORIMETRY_XVYCC_601] = HDMI_COLORIMETRY_XVYCC_601,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4d830fc55a3d..62c814241828 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -375,7 +375,6 @@ enum drm_privacy_screen_status {
 /* For Default case, driver will set the colorspace */
 #define DRM_MODE_COLORIMETRY_DEFAULT   0
 /* CEA 861 Normal Colorimetry options */
-#define DRM_MODE_COLORIMETRY_NO_DATA   0
 #define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC1
 #define DRM_MODE_COLORIMETRY_BT709_YCC 2
 /* CEA 861 Extended Colorimetry Options */
-- 
2.39.0

[PATCH v2 12/21] drm/amd/display: Always set crtcinfo from create_stream_for_sink

[Harry Wentland]

From: Joshua Ashton 

Given that we always pass dm_state into here now, this won't ever
trigger anymore.

This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.

Signed-off-by: Joshua Ashton 
Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index a31f71f2feca..fc94f4872397 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5870,7 +5870,7 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
 
if (recalculate_timing)
drm_mode_set_crtcinfo(_mode, 0);
-   else if (!dm_state)
+   else
drm_mode_set_crtcinfo(, 0);
 
/*
-- 
2.39.0

[PATCH v2 09/21] drm/amd/display: Register Colorspace property for DP and HDMI

[Harry Wentland]

We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index bc10ac5e772d..c311135f1e6f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7035,6 +7035,12 @@ static int amdgpu_dm_connector_get_modes(struct 
drm_connector *connector)
return amdgpu_dm_connector->num_modes;
 }
 
+static const u32 supported_colorspaces =
+   BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+   BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+   BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
+   BIT(DRM_MODE_COLORIMETRY_BT2020_YCC);
+
 void amdgpu_dm_connector_init_helper(struct amdgpu_display_manager *dm,
 struct amdgpu_dm_connector *aconnector,
 int connector_type,
@@ -7112,6 +7118,15 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
adev->mode_info.abm_level_property, 0);
}
 
+   if (connector_type == DRM_MODE_CONNECTOR_HDMIA) {
+   if 
(!drm_mode_create_hdmi_colorspace_property(>base, 
supported_colorspaces))
+   
drm_connector_attach_colorspace_property(>base);
+   } else if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
+  connector_type == DRM_MODE_CONNECTOR_eDP) {
+   if (!drm_mode_create_dp_colorspace_property(>base, 
supported_colorspaces))
+   
drm_connector_attach_colorspace_property(>base);
+   }
+
if (connector_type == DRM_MODE_CONNECTOR_HDMIA ||
connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
-- 
2.39.0

[PATCH v2 06/21] drm/connector: Allow drivers to pass list of supported colorspaces

[Harry Wentland]

Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.

Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.

v2:
 - Use 0 to indicate support for all colorspaces (Jani)
 - Print drm_dbg_kms message when drivers pass 0
   to signal that drivers should specify supported
   colorspaecs explicity (Jani)

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/drm_connector.c   | 148 ++
 .../gpu/drm/i915/display/intel_connector.c|   4 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c|   2 +-
 include/drm/drm_connector.h   |   8 +-
 4 files changed, 91 insertions(+), 71 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index ddba0b9fcc17..8e81105fb2ab 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1012,64 +1012,57 @@ static const struct drm_prop_enum_list 
drm_dp_subconnector_enum_list[] = {
 DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
 drm_dp_subconnector_enum_list)
 
-static const struct drm_prop_enum_list hdmi_colorspaces[] = {
-   /* For Default case, driver will set the colorspace */
-   { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
-   /* Standard Definition Colorimetry based on CEA 861 */
-   { DRM_MODE_COLORIMETRY_SMPTE_170M_YCC, "SMPTE_170M_YCC" },
-   { DRM_MODE_COLORIMETRY_BT709_YCC, "BT709_YCC" },
-   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
-   { DRM_MODE_COLORIMETRY_XVYCC_601, "XVYCC_601" },
-   /* High Definition Colorimetry based on IEC 61966-2-4 */
-   { DRM_MODE_COLORIMETRY_XVYCC_709, "XVYCC_709" },
-   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
-   { DRM_MODE_COLORIMETRY_SYCC_601, "SYCC_601" },
-   /* Colorimetry based on IEC 61966-2-5 [33] */
-   { DRM_MODE_COLORIMETRY_OPYCC_601, "opYCC_601" },
-   /* Colorimetry based on IEC 61966-2-5 */
-   { DRM_MODE_COLORIMETRY_OPRGB, "opRGB" },
-   /* Colorimetry based on ITU-R BT.2020 */
-   { DRM_MODE_COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
-   /* Colorimetry based on ITU-R BT.2020 */
-   { DRM_MODE_COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
-   /* Colorimetry based on ITU-R BT.2020 */
-   { DRM_MODE_COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
-   /* Added as part of Additional Colorimetry Extension in 861.G */
-   { DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65, "DCI-P3_RGB_D65" },
-   { DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER, "DCI-P3_RGB_Theater" },
+static const char * const colorspace_names[] = {
+   [DRM_MODE_COLORIMETRY_DEFAULT] = "Default",
+   [DRM_MODE_COLORIMETRY_SMPTE_170M_YCC] = "SMPTE_170M_YCC",
+   [DRM_MODE_COLORIMETRY_BT709_YCC] = "BT709_YCC",
+   [DRM_MODE_COLORIMETRY_XVYCC_601] = "XVYCC_601",
+   [DRM_MODE_COLORIMETRY_XVYCC_709] = "XVYCC_709",
+   [DRM_MODE_COLORIMETRY_SYCC_601] = "SYCC_601",
+   [DRM_MODE_COLORIMETRY_OPYCC_601] = "opYCC_601",
+   [DRM_MODE_COLORIMETRY_OPRGB] = "opRGB",
+   [DRM_MODE_COLORIMETRY_BT2020_CYCC] = "BT2020_CYCC",
+   [DRM_MODE_COLORIMETRY_BT2020_RGB] = "BT2020_RGB",
+   [DRM_MODE_COLORIMETRY_BT2020_YCC] = "BT2020_YCC",
+   [DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65] = "P3_RGB_D65",
+   [DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER] = "P3_RGB_Theater",
+   [DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED] = "RGB_WIDE_FIXED",
+   [DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT] = "RGB_WIDE_FLOAT",
+   [DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
 };
 
+static const u32 hdmi_colorspaces =
+   BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
+   BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
+   BIT(DRM_MODE_COLORIMETRY_XVYCC_601) |
+   BIT(DRM_MODE_COLORIMETRY_XVYCC_709) |
+   BIT(DRM_MODE_COLORIMETRY_SYCC_601) |
+   BIT(DRM_MODE_COLORIMETRY_OPYCC_601) |
+   BIT(DRM_MODE_COLORIMETRY_OPRGB) |
+   BIT(DRM_MODE_COLORIMETRY_BT2020_CYCC) |
+   BIT(DRM_MODE_COLORIMETRY_BT2020_RGB) |
+   BIT(DRM_MODE_COLORIMETRY_BT2020_YCC) |
+   BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65) |
+   BIT(DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER);
+
 /*
  * As per DP 1.4a spec, 2.2.5.7.5 VSC SDP Payload for Pixel 
Encoding/Colorimetry
  * Format Table 2-120
  */
-static const struct drm_prop_enum_list dp_colorspaces[] = {
-   /* For Default case, driver will set the colorspace */
-   { DRM_MODE_COLORIMETRY_DEFAULT, "Default" },
-   { DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED, "RGB_Wide_Gamut_Fixed_Point" },
-   /* Colorimetry based on scRGB (IEC 61966-2-2) */
-   { DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT, 

[PATCH v2 08/21] drm/amd/display: Always pass connector_state to stream validation

[Harry Wentland]

We need the connector_state for colorspace and scaling information
and can get it from connector->state.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b8638f0508b0..bc10ac5e772d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5776,15 +5776,14 @@ create_stream_for_sink(struct amdgpu_dm_connector 
*aconnector,
 {
struct drm_display_mode *preferred_mode = NULL;
struct drm_connector *drm_connector;
-   const struct drm_connector_state *con_state =
-   dm_state ? _state->base : NULL;
+   const struct drm_connector_state *con_state = _state->base;
struct dc_stream_state *stream = NULL;
struct drm_display_mode mode;
struct drm_display_mode saved_mode;
struct drm_display_mode *freesync_mode = NULL;
bool native_mode_found = false;
bool recalculate_timing = false;
-   bool scale = dm_state ? (dm_state->scaling != RMX_OFF) : false;
+   bool scale = dm_state->scaling != RMX_OFF;
int mode_refresh;
int preferred_refresh = 0;
enum color_transfer_func tf = TRANSFER_FUNC_UNKNOWN;
@@ -6397,7 +6396,9 @@ enum drm_mode_status 
amdgpu_dm_connector_mode_valid(struct drm_connector *connec
goto fail;
}
 
-   stream = create_validate_stream_for_sink(aconnector, mode, NULL, NULL);
+   stream = create_validate_stream_for_sink(aconnector, mode,
+
to_dm_connector_state(connector->state),
+NULL);
if (stream) {
dc_stream_release(stream);
result = MODE_OK;
-- 
2.39.0

[PATCH v2 07/21] drm/connector: Print connector colorspace in state debugfs

[Harry Wentland]

v3: Fix kerneldocs (kernel test robot)

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/drm_atomic.c|  1 +
 drivers/gpu/drm/drm_connector.c | 15 +++
 include/drm/drm_connector.h |  1 +
 3 files changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0dc5858a723..d6d04c4ccfc0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1071,6 +1071,7 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
"(null)");
drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware);
drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
+   drm_printf(p, "\tcolorspace=%s\n", 
drm_get_colorspace_name(state->colorspace));
 
if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
if (state->writeback_job && state->writeback_job->fb)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8e81105fb2ab..913e50a8bb38 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1031,6 +1031,21 @@ static const char * const colorspace_names[] = {
[DRM_MODE_COLORIMETRY_BT601_YCC] = "BT601_YCC",
 };
 
+/**
+ * drm_get_colorspace_name - return a string for color encoding
+ * @colorspace: color space to compute name of
+ *
+ * In contrast to the other drm_get_*_name functions this one here returns a
+ * const pointer and hence is threadsafe.
+ */
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace)
+{
+   if (WARN_ON(colorspace >= ARRAY_SIZE(colorspace_names)))
+   return "unknown";
+
+   return colorspace_names[colorspace];
+}
+
 static const u32 hdmi_colorspaces =
BIT(DRM_MODE_COLORIMETRY_SMPTE_170M_YCC) |
BIT(DRM_MODE_COLORIMETRY_BT709_YCC) |
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5825c6ab969b..545eb6eb456a 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1906,6 +1906,7 @@ void drm_connector_list_iter_end(struct 
drm_connector_list_iter *iter);
 
 bool drm_connector_has_possible_encoder(struct drm_connector *connector,
struct drm_encoder *encoder);
+const char *drm_get_colorspace_name(enum drm_colorspace colorspace);
 
 /**
  * drm_for_each_connector_iter - connector_list iterator macro
-- 
2.39.0

[PATCH v2 04/21] drm/connector: Convert DRM_MODE_COLORIMETRY to enum

[Harry Wentland]

This allows us to use strongly typed arguments.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 include/drm/display/drm_dp.h |  2 +-
 include/drm/drm_connector.h  | 47 ++--
 2 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index ed10e6b6f99d..28899a03245c 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -1623,7 +1623,7 @@ enum dp_pixelformat {
  *
  * This enum is used to indicate DP VSC SDP Colorimetry formats.
  * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
- * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
+ * DB18] and a name of enum member follows  drm_colorimetry definition.
  *
  * @DP_COLORIMETRY_DEFAULT: sRGB (IEC 61966-2-1) or
  *  ITU-R BT.601 colorimetry format
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 62c814241828..edef65388c29 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -371,28 +371,29 @@ enum drm_privacy_screen_status {
  * a colorspace property which will be created and exposed to
  * userspace.
  */
-
-/* For Default case, driver will set the colorspace */
-#define DRM_MODE_COLORIMETRY_DEFAULT   0
-/* CEA 861 Normal Colorimetry options */
-#define DRM_MODE_COLORIMETRY_SMPTE_170M_YCC1
-#define DRM_MODE_COLORIMETRY_BT709_YCC 2
-/* CEA 861 Extended Colorimetry Options */
-#define DRM_MODE_COLORIMETRY_XVYCC_601 3
-#define DRM_MODE_COLORIMETRY_XVYCC_709 4
-#define DRM_MODE_COLORIMETRY_SYCC_601  5
-#define DRM_MODE_COLORIMETRY_OPYCC_601 6
-#define DRM_MODE_COLORIMETRY_OPRGB 7
-#define DRM_MODE_COLORIMETRY_BT2020_CYCC   8
-#define DRM_MODE_COLORIMETRY_BT2020_RGB9
-#define DRM_MODE_COLORIMETRY_BT2020_YCC10
-/* Additional Colorimetry extension added as part of CTA 861.G */
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_D6511
-#define DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER12
-/* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry Format */
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED13
-#define DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT14
-#define DRM_MODE_COLORIMETRY_BT601_YCC 15
+enum drm_colorspace {
+   /* For Default case, driver will set the colorspace */
+   DRM_MODE_COLORIMETRY_DEFAULT,
+   /* CEA 861 Normal Colorimetry options */
+   DRM_MODE_COLORIMETRY_SMPTE_170M_YCC,
+   DRM_MODE_COLORIMETRY_BT709_YCC,
+   /* CEA 861 Extended Colorimetry Options */
+   DRM_MODE_COLORIMETRY_XVYCC_601,
+   DRM_MODE_COLORIMETRY_XVYCC_709,
+   DRM_MODE_COLORIMETRY_SYCC_601,
+   DRM_MODE_COLORIMETRY_OPYCC_601,
+   DRM_MODE_COLORIMETRY_OPRGB,
+   DRM_MODE_COLORIMETRY_BT2020_CYCC,
+   DRM_MODE_COLORIMETRY_BT2020_RGB,
+   DRM_MODE_COLORIMETRY_BT2020_YCC,
+   /* Additional Colorimetry extension added as part of CTA 861.G */
+   DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65,
+   DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER,
+   /* Additional Colorimetry Options added for DP 1.4a VSC Colorimetry 
Format */
+   DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED,
+   DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT,
+   DRM_MODE_COLORIMETRY_BT601_YCC,
+};
 
 /**
  * enum drm_bus_flags - bus_flags info for _display_info
@@ -825,7 +826,7 @@ struct drm_connector_state {
 * colorspace change on Sink. This is most commonly used to switch
 * to wider color gamuts like BT2020.
 */
-   u32 colorspace;
+   enum drm_colorspace colorspace;
 
/**
 * @writeback_job: Writeback job for writeback connectors
-- 
2.39.0

[PATCH v2 05/21] drm/connector: Pull out common create_colorspace_property code

[Harry Wentland]

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/drm_connector.c | 54 -
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 61c29ce74b03..ddba0b9fcc17 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1971,33 +1971,44 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
  * drm_mode_create_dp_colorspace_property() is used for DP connector.
  */
 
-/**
- * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
- * @connector: connector to create the Colorspace property on.
- *
- * Called by a driver the first time it's needed, must be attached to desired
- * HDMI connectors.
- *
- * Returns:
- * Zero on success, negative errno on failure.
- */
-int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+static int drm_mode_create_colorspace_property(struct drm_connector *connector,
+   const struct drm_prop_enum_list 
*colorspaces,
+   int size)
 {
struct drm_device *dev = connector->dev;
 
if (connector->colorspace_property)
return 0;
 
+   if (!colorspaces)
+   return 0;
+
connector->colorspace_property =
drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-hdmi_colorspaces,
-ARRAY_SIZE(hdmi_colorspaces));
+   colorspaces,
+   size);
 
if (!connector->colorspace_property)
return -ENOMEM;
 
return 0;
 }
+/**
+ * drm_mode_create_hdmi_colorspace_property - create hdmi colorspace property
+ * @connector: connector to create the Colorspace property on.
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * HDMI connectors.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
+{
+   return drm_mode_create_colorspace_property(connector,
+  hdmi_colorspaces,
+  
ARRAY_SIZE(hdmi_colorspaces));
+}
 EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
 
 /**
@@ -2012,20 +2023,9 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
  */
 int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
 {
-   struct drm_device *dev = connector->dev;
-
-   if (connector->colorspace_property)
-   return 0;
-
-   connector->colorspace_property =
-   drm_property_create_enum(dev, DRM_MODE_PROP_ENUM, "Colorspace",
-dp_colorspaces,
-ARRAY_SIZE(dp_colorspaces));
-
-   if (!connector->colorspace_property)
-   return -ENOMEM;
-
-   return 0;
+   return drm_mode_create_colorspace_property(connector,
+  dp_colorspaces,
+  ARRAY_SIZE(dp_colorspaces));
 }
 EXPORT_SYMBOL(drm_mode_create_dp_colorspace_property);
 
-- 
2.39.0

[PATCH v2 17/21] drm/amd/display: Format input and output CSC matrix

[Harry Wentland]

Format the input and output CSC matrix so they
look like 3x4 matrixes. This will make parsing them
much easier and allows us to quickly spot potential
mistakes.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
---
 .../drm/amd/display/dc/core/dc_hw_sequencer.c | 38 -
 drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h   | 54 +++
 2 files changed, 56 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
index 471078fc3900..a70f045fc5c1 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c
@@ -73,28 +73,38 @@ struct out_csc_color_matrix_type {
 
 static const struct out_csc_color_matrix_type output_csc_matrix[] = {
{ COLOR_SPACE_RGB_TYPE,
-   { 0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
+   { 0x2000, 0,  0,  0,
+ 0,  0x2000, 0,  0,
+ 0,  0,  0x2000, 0} },
{ COLOR_SPACE_RGB_LIMITED_TYPE,
-   { 0x1B67, 0, 0, 0x201, 0, 0x1B67, 0, 0x201, 0, 0, 0x1B67, 
0x201} },
+   { 0x1B67, 0,  0,  0x201,
+ 0,  0x1B67, 0,  0x201,
+ 0,  0,  0x1B67, 0x201} },
{ COLOR_SPACE_YCBCR601_TYPE,
-   { 0xE04, 0xF444, 0xFDB9, 0x1004, 0x831, 0x1016, 0x320, 0x201, 
0xFB45,
-   0xF6B7, 0xE04, 0x1004} },
+   { 0xE04,  0xF444, 0xFDB9, 0x1004,
+ 0x831,  0x1016, 0x320,  0x201,
+ 0xFB45, 0xF6B7, 0xE04,  0x1004} },
{ COLOR_SPACE_YCBCR709_TYPE,
-   { 0xE04, 0xF345, 0xFEB7, 0x1004, 0x5D3, 0x1399, 0x1FA,
-   0x201, 0xFCCA, 0xF533, 0xE04, 0x1004} },
+   { 0xE04,  0xF345, 0xFEB7, 0x1004,
+ 0x5D3,  0x1399, 0x1FA,  0x201,
+ 0xFCCA, 0xF533, 0xE04,  0x1004} },
/* TODO: correct values below */
{ COLOR_SPACE_YCBCR601_LIMITED_TYPE,
-   { 0xE00, 0xF447, 0xFDB9, 0x1000, 0x991,
-   0x12C9, 0x3A6, 0x200, 0xFB47, 0xF6B9, 0xE00, 
0x1000} },
+   { 0xE00,  0xF447, 0xFDB9, 0x1000,
+ 0x991,  0x12C9, 0x3A6,  0x200,
+ 0xFB47, 0xF6B9, 0xE00,  0x1000} },
{ COLOR_SPACE_YCBCR709_LIMITED_TYPE,
-   { 0xE00, 0xF349, 0xFEB7, 0x1000, 0x6CE, 0x16E3,
-   0x24F, 0x200, 0xFCCB, 0xF535, 0xE00, 0x1000} },
+   { 0xE00, 0xF349, 0xFEB7, 0x1000,
+ 0x6CE, 0x16E3, 0x24F,  0x200,
+ 0xFCCB, 0xF535, 0xE00, 0x1000} },
{ COLOR_SPACE_YCBCR2020_TYPE,
-   { 0x1000, 0xF149, 0xFEB7, 0x, 0x0868, 0x15B2,
-   0x01E6, 0x, 0xFB88, 0xF478, 0x1000, 0x} 
},
+   { 0x1000, 0xF149, 0xFEB7, 0x,
+ 0x0868, 0x15B2, 0x01E6, 0x,
+ 0xFB88, 0xF478, 0x1000, 0x} },
{ COLOR_SPACE_YCBCR709_BLACK_TYPE,
-   { 0x, 0x, 0x, 0x1000, 0x, 0x,
-   0x, 0x0200, 0x, 0x, 0x, 0x1000} 
},
+   { 0x, 0x, 0x, 0x1000,
+ 0x, 0x, 0x, 0x0200,
+ 0x, 0x, 0x, 0x1000} },
 };
 
 static bool is_rgb_type(
diff --git a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h 
b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
index 131fcfa28bca..f4aa76e02518 100644
--- a/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
+++ b/drivers/gpu/drm/amd/display/dc/inc/hw/dpp.h
@@ -70,28 +70,38 @@ struct dpp_input_csc_matrix {
 };
 
 static const struct dpp_input_csc_matrix __maybe_unused dpp_input_csc_matrix[] 
= {
-   {COLOR_SPACE_SRGB,
-   {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
-   {COLOR_SPACE_SRGB_LIMITED,
-   {0x2000, 0, 0, 0, 0, 0x2000, 0, 0, 0, 0, 0x2000, 0} },
-   {COLOR_SPACE_YCBCR601,
-   {0x2cdd, 0x2000, 0, 0xe991, 0xe926, 0x2000, 0xf4fd, 0x10ef,
-   0, 0x2000, 0x38b4, 0xe3a6} },
-   {COLOR_SPACE_YCBCR601_LIMITED,
-   {0x3353, 0x2568, 0, 0xe400, 0xe5dc, 0x2568, 0xf367, 0x1108,
-   0, 0x2568, 0x40de, 0xdd3a} },
-   {COLOR_SPACE_YCBCR709,
-   {0x3265, 0x2000, 0, 0xe6ce, 0xf105, 0x2000, 0xfa01, 0xa7d, 0,
-   0x2000, 0x3b61, 0xe24f} },
-   {COLOR_SPACE_YCBCR709_LIMITED,
-   {0x39a6, 0x2568, 0, 0xe0d6, 0xeedd, 0x2568, 0xf925, 0x9a8, 0,
-   0x2568, 0x43ee, 0xdbb2} },
-   {COLOR_SPACE_2020_YCBCR,
-   {0x2F30, 0x2000, 0, 

[PATCH v2 16/21] drm/amd/display: Don't restrict bpc to 8 bpc

[Harry Wentland]

This will let us pass the kms_hdr.bpc_switch IGT
test.

The reason the bpc restriction was required is
historical. At one point in time we were not falling
back to a lower bpc when we didn't have enough
bandwidth for the maximum bpc reported by a display.
This meant that we couldn't enable some high refresh
modes unless we limitted the bpc.

Starting with this patch the issue is fixed:
cbd14ae7ea93 ("drm/amd/display: Fix incorrectly pruned modes with deep color")

This patch implemented a fallback mechanism if mode
validation failed at the max bpc. This means users
now automatically get all modes that can be supported
by at least 6 bpc. The driver will enable the mode
with the highest possible bpc that is supported by
the display.

v2:
 - explain why this is no longer needed (Michel)
 - refer to commit that fixed bpc fallback (Michel)

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: Michel Dänzer 
Reviewed-By: Joshua Ashton 
Reviewed-by: Michel Dänzer 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 73a98e6e1867..f74b125af31f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7130,7 +7130,7 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
drm_connector_attach_max_bpc_property(>base, 8, 16);
 
/* This defaults to the max in the range, but we want 8bpc for non-edp. 
*/
-   aconnector->base.state->max_bpc = (connector_type == 
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
+   aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.state->max_bpc;
 
if (connector_type == DRM_MODE_CONNECTOR_eDP &&
-- 
2.39.0

[PATCH v2 20/21] drm/amd/display: Calculate output_color_space after pixel encoding adjustment

[Harry Wentland]

From: Joshua Ashton 

Code in get_output_color_space depends on knowing the pixel encoding to
determine whether to pick between eg. COLOR_SPACE_SRGB or
COLOR_SPACE_YCBCR709 for transparent RGB -> YCbCr 4:4:4 in the driver.

Signed-off-by: Joshua Ashton 
Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 16940ea61b59..eb188487f0a7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5341,8 +5341,6 @@ static void fill_stream_properties_from_drm_display_mode(
 
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
 
-   stream->output_color_space = get_output_color_space(timing_out, 
connector_state);
-
stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) {
@@ -5353,6 +5351,8 @@ static void fill_stream_properties_from_drm_display_mode(
adjust_colour_depth_from_display_info(timing_out, info);
}
}
+
+   stream->output_color_space = get_output_color_space(timing_out, 
connector_state);
 }
 
 static void fill_audio_info(struct audio_info *audio_info,
-- 
2.39.0

[PATCH v2 15/21] drm/amd/display: Add default case for output_color_space switch

[Harry Wentland]

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
 1 file changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index d2921d2179cc..73a98e6e1867 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5168,7 +5168,29 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing,
enum dc_color_space color_space = COLOR_SPACE_SRGB;
 
switch (connector_state->colorspace) {
+   case DRM_MODE_COLORIMETRY_BT601_YCC:
+   if (dc_crtc_timing->flags.Y_ONLY)
+   color_space = COLOR_SPACE_YCBCR601_LIMITED;
+   else
+   color_space = COLOR_SPACE_YCBCR601;
+   break;
+   case DRM_MODE_COLORIMETRY_BT709_YCC:
+   if (dc_crtc_timing->flags.Y_ONLY)
+   color_space = COLOR_SPACE_YCBCR709_LIMITED;
+   else
+   color_space = COLOR_SPACE_YCBCR709;
+   break;
+   case DRM_MODE_COLORIMETRY_OPRGB:
+   color_space = COLOR_SPACE_ADOBERGB;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_RGB:
+   color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_YCC:
+   color_space = COLOR_SPACE_2020_YCBCR;
+   break;
case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
+   default:
if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
color_space = COLOR_SPACE_SRGB;
/*
@@ -5190,27 +5212,6 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing,
color_space = COLOR_SPACE_YCBCR601;
}
break;
-   case DRM_MODE_COLORIMETRY_BT601_YCC:
-   if (dc_crtc_timing->flags.Y_ONLY)
-   color_space = COLOR_SPACE_YCBCR601_LIMITED;
-   else
-   color_space = COLOR_SPACE_YCBCR601;
-   break;
-   case DRM_MODE_COLORIMETRY_BT709_YCC:
-   if (dc_crtc_timing->flags.Y_ONLY)
-   color_space = COLOR_SPACE_YCBCR709_LIMITED;
-   else
-   color_space = COLOR_SPACE_YCBCR709;
-   break;
-   case DRM_MODE_COLORIMETRY_OPRGB:
-   color_space = COLOR_SPACE_ADOBERGB;
-   break;
-   case DRM_MODE_COLORIMETRY_BT2020_RGB:
-   color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
-   break;
-   case DRM_MODE_COLORIMETRY_BT2020_YCC:
-   color_space = COLOR_SPACE_2020_YCBCR;
-   break;
}
 
return color_space;
-- 
2.39.0

[PATCH v2 13/21] drm/amd/display: Add support for explicit BT601_YCC

[Harry Wentland]

We use this by default but if userspace passes this explicitly
we should respect it.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index fc94f4872397..d2921d2179cc 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5190,6 +5190,12 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing,
color_space = COLOR_SPACE_YCBCR601;
}
break;
+   case DRM_MODE_COLORIMETRY_BT601_YCC:
+   if (dc_crtc_timing->flags.Y_ONLY)
+   color_space = COLOR_SPACE_YCBCR601_LIMITED;
+   else
+   color_space = COLOR_SPACE_YCBCR601;
+   break;
case DRM_MODE_COLORIMETRY_BT709_YCC:
if (dc_crtc_timing->flags.Y_ONLY)
color_space = COLOR_SPACE_YCBCR709_LIMITED;
-- 
2.39.0

[PATCH v2 11/21] drm/amd/display: Send correct DP colorspace infopacket

[Harry Wentland]

Look at connector->colorimetry to determine output colorspace.

We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 38 +++
 1 file changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f74462c282a6..a31f71f2feca 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -5162,21 +5162,21 @@ get_aspect_ratio(const struct drm_display_mode *mode_in)
 }
 
 static enum dc_color_space
-get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing)
+get_output_color_space(const struct dc_crtc_timing *dc_crtc_timing,
+  const struct drm_connector_state *connector_state)
 {
enum dc_color_space color_space = COLOR_SPACE_SRGB;
 
-   switch (dc_crtc_timing->pixel_encoding) {
-   case PIXEL_ENCODING_YCBCR422:
-   case PIXEL_ENCODING_YCBCR444:
-   case PIXEL_ENCODING_YCBCR420:
-   {
+   switch (connector_state->colorspace) {
+   case DRM_MODE_COLORIMETRY_DEFAULT: // ITU601
+   if (dc_crtc_timing->pixel_encoding == PIXEL_ENCODING_RGB) {
+   color_space = COLOR_SPACE_SRGB;
/*
 * 27030khz is the separation point between HDTV and SDTV
 * according to HDMI spec, we use YCbCr709 and YCbCr601
 * respectively
 */
-   if (dc_crtc_timing->pix_clk_100hz > 270300) {
+   } else if (dc_crtc_timing->pix_clk_100hz > 270300) {
if (dc_crtc_timing->flags.Y_ONLY)
color_space =
COLOR_SPACE_YCBCR709_LIMITED;
@@ -5189,15 +5189,21 @@ get_output_color_space(const struct dc_crtc_timing 
*dc_crtc_timing)
else
color_space = COLOR_SPACE_YCBCR601;
}
-
-   }
-   break;
-   case PIXEL_ENCODING_RGB:
-   color_space = COLOR_SPACE_SRGB;
break;
-
-   default:
-   WARN_ON(1);
+   case DRM_MODE_COLORIMETRY_BT709_YCC:
+   if (dc_crtc_timing->flags.Y_ONLY)
+   color_space = COLOR_SPACE_YCBCR709_LIMITED;
+   else
+   color_space = COLOR_SPACE_YCBCR709;
+   break;
+   case DRM_MODE_COLORIMETRY_OPRGB:
+   color_space = COLOR_SPACE_ADOBERGB;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_RGB:
+   color_space = COLOR_SPACE_2020_RGB_FULLRANGE;
+   break;
+   case DRM_MODE_COLORIMETRY_BT2020_YCC:
+   color_space = COLOR_SPACE_2020_YCBCR;
break;
}
 
@@ -5325,7 +5331,7 @@ static void fill_stream_properties_from_drm_display_mode(
 
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
 
-   stream->output_color_space = get_output_color_space(timing_out);
+   stream->output_color_space = get_output_color_space(timing_out, 
connector_state);
 
stream->out_transfer_func->type = TF_TYPE_PREDEFINED;
stream->out_transfer_func->tf = TRANSFER_FUNCTION_SRGB;
-- 
2.39.0

[PATCH v2 10/21] drm/amd/display: Signal mode_changed if colorspace changed

[Harry Wentland]

We need to signal mode_changed to make sure we update the output
colorspace.

v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c311135f1e6f..f74462c282a6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6492,6 +6492,14 @@ amdgpu_dm_connector_atomic_check(struct drm_connector 
*conn,
if (!crtc)
return 0;
 
+   if (new_con_state->colorspace != old_con_state->colorspace) {
+   new_crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(new_crtc_state))
+   return PTR_ERR(new_crtc_state);
+
+   new_crtc_state->mode_changed = true;
+   }
+
if (!drm_connector_atomic_hdr_metadata_equal(old_con_state, 
new_con_state)) {
struct dc_info_packet hdr_infopacket;
 
@@ -6514,7 +6522,7 @@ amdgpu_dm_connector_atomic_check(struct drm_connector 
*conn,
 * set is permissible, however. So only force a
 * modeset if we're entering or exiting HDR.
 */
-   new_crtc_state->mode_changed =
+   new_crtc_state->mode_changed = new_crtc_state->mode_changed ||
!old_con_state->hdr_output_metadata ||
!new_con_state->hdr_output_metadata;
}
-- 
2.39.0

[PATCH v2 02/21] drm/connector: print max_requested_bpc in state debugfs

[Harry Wentland]

This is useful to understand the bpc defaults and
support of a driver.

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/drm_atomic.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index f197f59f6d99..c0dc5858a723 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1070,6 +1070,7 @@ static void drm_atomic_connector_print_state(struct 
drm_printer *p,
drm_printf(p, "connector[%u]: %s\n", connector->base.id, 
connector->name);
drm_printf(p, "\tcrtc=%s\n", state->crtc ? state->crtc->name : 
"(null)");
drm_printf(p, "\tself_refresh_aware=%d\n", state->self_refresh_aware);
+   drm_printf(p, "\tmax_requested_bpc=%d\n", state->max_requested_bpc);
 
if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
if (state->writeback_job && state->writeback_job->fb)
-- 
2.39.0

[PATCH v2 01/21] drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF

[Harry Wentland]

The EDID of an HDR display defines EOTFs that are supported
by the display and can be set in the HDR metadata infoframe.
Userspace is expected to read the EDID and set an appropriate
HDR_OUTPUT_METADATA.

In drm_parse_hdr_metadata_block the kernel reads the supported
EOTFs from the EDID and stores them in the
drm_connector->hdr_sink_metadata. While doing so it also
filters the EOTFs to the EOTFs the kernel knows about.
When an HDR_OUTPUT_METADATA is set it then checks to
make sure the EOTF is a supported EOTF. In cases where
the kernel doesn't know about a new EOTF this check will
fail, even if the EDID advertises support.

Since it is expected that userspace reads the EDID to understand
what the display supports it doesn't make sense for DRM to block
an HDR_OUTPUT_METADATA if it contains an EOTF the kernel doesn't
understand.

This comes with the added benefit of future-proofing metadata
support. If the spec defines a new EOTF there is no need to
update DRM and an compositor can immediately make use of it.

Fixes: https://gitlab.freedesktop.org/wayland/weston/-/issues/609

v2: Distinguish EOTFs defind in kernel and ones defined
in EDID in the commit description (Pekka)

v3: Rebase; drm_hdmi_infoframe_set_hdr_metadata moved
to drm_hdmi_helper.c

Signed-off-by: Harry Wentland 
Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Acked-by: Pekka Paalanen 
Reviewed-By: Joshua Ashton 
---
 drivers/gpu/drm/display/drm_hdmi_helper.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_hdmi_helper.c 
b/drivers/gpu/drm/display/drm_hdmi_helper.c
index 0264abe55278..faf5e9efa7d3 100644
--- a/drivers/gpu/drm/display/drm_hdmi_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_helper.c
@@ -44,10 +44,8 @@ int drm_hdmi_infoframe_set_hdr_metadata(struct 
hdmi_drm_infoframe *frame,
 
/* Sink EOTF is Bit map while infoframe is absolute values */
if (!is_eotf_supported(hdr_metadata->hdmi_metadata_type1.eotf,
-   connector->hdr_sink_metadata.hdmi_type1.eotf)) {
-   DRM_DEBUG_KMS("EOTF Not Supported\n");
-   return -EINVAL;
-   }
+   connector->hdr_sink_metadata.hdmi_type1.eotf))
+   DRM_DEBUG_KMS("Unknown EOTF %d\n", 
hdr_metadata->hdmi_metadata_type1.eotf);
 
err = hdmi_drm_infoframe_init(frame);
if (err < 0)
-- 
2.39.0

[PATCH v2 00/21] Enable Colorspace connector property in amdgpu

[Harry Wentland]

This patchset enables the DP and HDMI infoframe properties
in amdgpu.

The first two patches are not completely related to the rest. The
first patch allows for HDR_OUTPUT_METADATA with EOTFs that are
unknown in the kernel.

The second one prints a connector's max_bpc as part of the atomic
state debugfs print.

The following patches rework the connector colorspace code to
1) allow for easy printing of the colorspace in the drm_atomic
   state debugfs, and
2) allow drivers to specify the supported colorspaces on a
   connector.

The rest of the patches deal with the Colorspace enablement
in amdgpu.

Why do drivers need to specify supported colorspaces? The amdgpu
driver needs support for RGB-to-YCbCr conversion when we drive
the display in YCbCr. This is currently not implemented for all
colorspaces.

Since the Colorspace property didn't have an IGT test I added
one to kms_hdr. The relevant patchset can be found on the IGT
mailing list or on
https://gitlab.freedesktop.org/hwentland/igt-gpu-tools/-/tree/hdr-colorimetry

We tested v1 of the patchset and confirmed that the infoframes
are as expected for both DP and HDMI when running the IGT
colorimetry tests.

Open Items
--

A couple comments from Pekka about colorspace documentation are
left unaddressed. I hope they won't block merging this set but
should still be addressed separately.

Pekka's questions really got me thinking of how this colorspace
property should be used and working with it more closely with
Joshua who is enabling HDR in gamescope made me wonder even more.

Uma, is there a (canonical, upstream) userspace that uses this
property that I can look at to understand more?

One of the key challenges that is currently not addressed is that
userspace is expected to pick a colorspace format straight from the
list of definitions out of the DP or HDMI spec. But the kernel
driver are the ones deciding on the output encoding (RGB, YCBCR444,
YCBCR420, etc.). So there is no way for userspace to decide correctly
between, for example, BT2020_RGB, BT2020_CYCC, BT2020_YCC.

So we end up in a scenario where gamescope sets BT2020_RGB but we
output YCBCR444 so have to correct the colorspace value to
BT2020_YCC. This in turn breaks the colorspace IGT tests I
wrote. I don't think "fixing" the IGT tests to accept this is
the right thing to do.

The way it stands this patchset allows us to specify the output
colorspace on amdgpu and we try to do the right thing, but I don't
thing the way the colorspace property is defined is right. We're trying
to expose things to userspace that should be under driver control. A
much better approach would be to give userspace options for colorspace
that are not tied to DP or HDMI specs, i.e., sRGB, BT709, BT2020, etc.,
and have the driver do the right thing to fill the infoframe, e.g., by
picking BT2020_YCC if the requested colorspace is BT2020 and the
is YCBCR444.

If no upstream userspace currently makes use of this property I
can make that change, i.e., no longer tie the colorspace property
directly to the infoframe and reduce the options to sRGB, BT709,
BT601, and BT2020 (and possibly opRGB).

v2:
- Tested with DP and HDMI analyzers
- Confirmed driver will fallback to lower bpc when needed
- Dropped hunk to set HDMI AVI infoframe as it was a no-op
- Fixed BT.2020 YCbCr colorimetry (JoshuaAshton)
- Simplify initialization of supported colorspaces (Jani)
- Fix kerneldoc (kernel test robot)

Cc: Pekka Paalanen 
Cc: Sebastian Wick 
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar 
Cc: Ville Syrjälä 
Cc: Joshua Ashton 
Cc: Jani Nikula 
Cc: Michel Dänzer 
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org

Harry Wentland (16):
  drm/display: Don't block HDR_OUTPUT_METADATA on unknown EOTF
  drm/connector: print max_requested_bpc in state debugfs
  drm/connector: Drop COLORIMETRY_NO_DATA
  drm/connector: Convert DRM_MODE_COLORIMETRY to enum
  drm/connector: Pull out common create_colorspace_property code
  drm/connector: Allow drivers to pass list of supported colorspaces
  drm/connector: Print connector colorspace in state debugfs
  drm/amd/display: Always pass connector_state to stream validation
  drm/amd/display: Register Colorspace property for DP and HDMI
  drm/amd/display: Signal mode_changed if colorspace changed
  drm/amd/display: Send correct DP colorspace infopacket
  drm/amd/display: Add support for explicit BT601_YCC
  drm/amd/display: Add debugfs for testing output colorspace
  drm/amd/display: Add default case for output_color_space switch
  drm/amd/display: Don't restrict bpc to 8 bpc
  drm/amd/display: Format input and output CSC matrix

Joshua Ashton (5):
  drm/amd/display: Always set crtcinfo from create_stream_for_sink
  drm/amd/display: Fallback to 2020_YCBCR if the pixel encoding is not
RGB
  drm/amd/display: Refactor avi_info_frame colorimetry determination
  drm/amd/display: Calculate output_color_space after pixel encoding
adjustment
  drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE 

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Harry Wentland]

On 1/13/23 05:25, Daniel Vetter wrote:
> On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
>>
>> Cc: intel-gfx, drm maintainers
>>
>> Please have the courtesy of Cc'ing us for changes impacting us, and
>> maybe try to involve us earlier instead of surprising us like
>> this. Looks like this has been debugged for at least three months, and
>> the huge revert at this point is going to set us back with what's been
>> developed on top of it for i915 DP MST and DSC.
> 
> tbf I assumed this wont land when I've seen it fly by. It feels a bit much
> like living under a rock for half a year and then creating a mess for
> everyone else who's been building on top of this is not great.
> 
> Like yes it's a regression, but apparently not a blantantly obvious one,
> and I think if we just ram this in there's considerable community goodwill
> down the drain. Someone needs to get that goodwill up the drain again.
> 
>> It's a regression, I get that, but this is also going to be really nasty
>> to deal with. It's a 2500-line commit, plus the dependencies, which I
>> don't think are accounted for here. (What's the baseline for the revert
>> anyway?) I don't expect all the dependent commits to be easy to revert
>> or backport to v6.1 or v6.2.
>>
>> *sad trombone*
> 
> Yeah that's the other thing. 2500 patch revert is not cc stable material.
> So this isn't even really helping users all that much.
> 
> Unless it also comes with full amounts of backports of the reverts on all
> affected drivers for all curent stable trees, fully validated.
> 
> This is bad. I do think we need to have some understanding first of what
> "fix this in amdgpu" would look like as plan B. Because plan A does not
> look like a happy one at all.

Agree with your sentiments and apologies for not making this visible to
you sooner. This has been on the corner of my radar but I should've given
it a higher priority and more visibility sooner.

Has anyone looked at the dependencies? I assume there are a number of
dependent commits that would be hard/impossible to untangle but haven't had
a chance to look for those myself. Could you highlight a couple?

Harry

> -Daniel
> 
>> BR,
>> Jani.
>>
>>
>> On Thu, 12 Jan 2023, Wayne Lin  wrote:
>>> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
>>>
>>> [Why]
>>> Changes cause regression on amdgpu mst.
>>> E.g.
>>> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove 
>>> payload
>>> one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
>>> maintained payload table. But previous change tries to go through all the
>>> payloads in mst_state and update amdpug hw maintained table in once 
>>> everytime
>>> driver only tries to add/remove a specific payload stream only. The newly
>>> design idea conflicts with the implementation in amdgpu nowadays.
>>>
>>> [How]
>>> Revert this patch first. After addressing all regression problems caused by
>>> this previous patch, will add it back and adjust it.
>>>
>>> Signed-off-by: Wayne Lin 
>>> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
>>> Cc: sta...@vger.kernel.org # 6.1
>>> Cc: Lyude Paul 
>>> Cc: Harry Wentland 
>>> Cc: Mario Limonciello 
>>> Cc: Ville Syrjälä 
>>> Cc: Ben Skeggs 
>>> Cc: Stanislav Lisovskiy 
>>> Cc: Fangzhi Zuo 
>>> ---
>>>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  53 +-
>>>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 106 ++-
>>>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  87 ++-
>>>  .../amd/display/include/link_service_types.h  |   3 -
>>>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 724 --
>>>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  67 +-
>>>  drivers/gpu/drm/i915/display/intel_hdcp.c |  24 +-
>>>  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 167 ++--
>>>  include/drm/display/drm_dp_mst_helper.h   | 177 +++--
>>>  9 files changed, 878 insertions(+), 530 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> index 77277d90b6e2..674f5dc1102b 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct 
>>> drm_encoder *encoder,
>>> const struct drm_display_mode *adjusted_mode = 
>>> _state->adjusted_mode;
>>> struct drm_dp_mst_topology_mgr *mst_mgr;
>>> struct drm_dp_mst_port *mst_port;
>>> -   struct drm_dp_mst_topology_state *mst_state;
>>> enum dc_color_depth color_depth;
>>> int clock, bpp = 0;
>>> bool is_y420 = false;
>>> @@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct 
>>> drm_encoder *encoder,
>>> if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
>>> return 0;
>>>  
>>> -   mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
>>> -   if (IS_ERR(mst_state))
>>> -   return PTR_ERR(mst_state);

Re: [PATCH v2 02/10] drm: Include where needed

[Ville Syrjälä]

On Fri, Jan 13, 2023 at 04:11:48PM +0100, Sam Ravnborg wrote:
> Hi Ville,
> On Wed, Jan 11, 2023 at 06:08:42PM +0200, Ville Syrjälä wrote:
> > On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote:
> > > Include  in source files that need it. Some of DRM's
> > > source code gets OF header via drm_crtc_helper.h and ,
> > > which can leed to unnecessary recompilation.
> > > 
> > > In drm_modes.c, add a comment on the reason for still including
> > > . The header file is required to get KHZ2PICOS(). The
> > > macro is part of the UAPI headers, so it cannot be moved to a less
> > > prominent location.
> > 
> > I never liked that KHZ2PICOS() thing in there. Maybe we should
> > just nuke it and see if anyone notices?
> https://github.com/search?q=KHZ2PICOS=code

No idea what relevance any of those have.

> 
> tells me that it will be noticed.
> So it is part of the UAPI

The only thing it does it potentially mistake some modes for being
equal when they are not. So basically just second guessing what the
driver/hardware is actually capable of doing.

-- 
Ville Syrjälä
Intel

Re: [PATCH v2 01/10] drm: Include where needed

[Thomas Zimmermann]

Hi

Am 13.01.23 um 16:09 schrieb Sam Ravnborg:

Hi Thomas,
On Wed, Jan 11, 2023 at 02:01:57PM +0100, Thomas Zimmermann wrote:

Include  in source files that need it. Some of
DRM's source code gets the backlight header via drm_crtc_helper.h
and , which can leed to unnecessary recompilation. If
possible, do not include drm_crtc_helper.h any longer.

Are you planning a clean-up of drm_crtc_helper.h later?



With a handful of forward it could losse all includes.


Indeed, looks like it. And a quick grep shows that many source files 
include this header. I keep it in mind to try to improve that.






Signed-off-by: Thomas Zimmermann 
Acked-by: Christian König  # amd

Reviewed-by: Sam Ravnborg 


I've already merged the series. Maxime gave an a-b via IRC. Still thanks 
for reviewing.


Best regards
Thomas


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  | 2 +-
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
  drivers/gpu/drm/gma500/backlight.c| 2 ++
  drivers/gpu/drm/radeon/radeon_acpi.c  | 2 +-
  4 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 57b5e11446c6..f29c1d0ad4c1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -24,6 +24,7 @@
  
  #include 

  #include 
+#include 
  #include 
  #include 
  #include 
@@ -31,7 +32,6 @@
  #include 
  #include 
  
-#include 

  #include "amdgpu.h"
  #include "amdgpu_pm.h"
  #include "amdgpu_display.h"
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1b7f20a9d4ae..55a845eb0c6d 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -67,6 +67,7 @@
  #include "ivsrcid/ivsrcid_vislands30.h"
  
  #include "i2caux_interface.h"

+#include 
  #include 
  #include 
  #include 
diff --git a/drivers/gpu/drm/gma500/backlight.c 
b/drivers/gpu/drm/gma500/backlight.c
index 577a4987b193..8711a7a5b8da 100644
--- a/drivers/gpu/drm/gma500/backlight.c
+++ b/drivers/gpu/drm/gma500/backlight.c
@@ -7,6 +7,8 @@
   * Authors: Eric Knopp
   */
  
+#include 

+
  #include 
  
  #include "psb_drv.h"

diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c 
b/drivers/gpu/drm/radeon/radeon_acpi.c
index b603c0b77075..5771d1fcb073 100644
--- a/drivers/gpu/drm/radeon/radeon_acpi.c
+++ b/drivers/gpu/drm/radeon/radeon_acpi.c
@@ -22,6 +22,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  #include 
@@ -30,7 +31,6 @@
  #include 
  #include 
  
-#include 

  #include 
  
  #include "atom.h"

--
2.39.0


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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v2 05/10] drm/panel: Do not include

[Sam Ravnborg]

On Wed, Jan 11, 2023 at 02:02:01PM +0100, Thomas Zimmermann wrote:
> Remove unnecessary include statements for . No functional
> changes. Include  where the driver got the header file via
> .
> 
> Signed-off-by: Thomas Zimmermann 
Reviewed-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 1 -
>  drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 -
>  drivers/gpu/drm/panel/panel-ronbo-rb070d30.c  | 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
> b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> index cbb68caa36f2..1ec696adf9de 100644
> --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
> @@ -7,7 +7,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c 
> b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> index 79f852465a84..35d568da342f 100644
> --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
> @@ -43,7 +43,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c 
> b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> index 866d1bf5530e..2ef5ea5eaeeb 100644
> --- a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> +++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.39.0

Re: [PATCH v2 02/10] drm: Include where needed

[Sam Ravnborg]

Hi Ville,
On Wed, Jan 11, 2023 at 06:08:42PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote:
> > Include  in source files that need it. Some of DRM's
> > source code gets OF header via drm_crtc_helper.h and ,
> > which can leed to unnecessary recompilation.
> > 
> > In drm_modes.c, add a comment on the reason for still including
> > . The header file is required to get KHZ2PICOS(). The
> > macro is part of the UAPI headers, so it cannot be moved to a less
> > prominent location.
> 
> I never liked that KHZ2PICOS() thing in there. Maybe we should
> just nuke it and see if anyone notices?
https://github.com/search?q=KHZ2PICOS=code

tells me that it will be noticed.
So it is part of the UAPI

Sam

Re: [PATCH v2 01/10] drm: Include where needed

[Sam Ravnborg]

Hi Thomas,
On Wed, Jan 11, 2023 at 02:01:57PM +0100, Thomas Zimmermann wrote:
> Include  in source files that need it. Some of
> DRM's source code gets the backlight header via drm_crtc_helper.h
> and , which can leed to unnecessary recompilation. If
> possible, do not include drm_crtc_helper.h any longer.
Are you planning a clean-up of drm_crtc_helper.h later?
With a handful of forward it could losse all includes.

> 
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Christian König  # amd
Reviewed-by: Sam Ravnborg 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c  | 2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
>  drivers/gpu/drm/gma500/backlight.c| 2 ++
>  drivers/gpu/drm/radeon/radeon_acpi.c  | 2 +-
>  4 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> index 57b5e11446c6..f29c1d0ad4c1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> @@ -24,6 +24,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,7 +32,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include "amdgpu.h"
>  #include "amdgpu_pm.h"
>  #include "amdgpu_display.h"
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1b7f20a9d4ae..55a845eb0c6d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -67,6 +67,7 @@
>  #include "ivsrcid/ivsrcid_vislands30.h"
>  
>  #include "i2caux_interface.h"
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/gma500/backlight.c 
> b/drivers/gpu/drm/gma500/backlight.c
> index 577a4987b193..8711a7a5b8da 100644
> --- a/drivers/gpu/drm/gma500/backlight.c
> +++ b/drivers/gpu/drm/gma500/backlight.c
> @@ -7,6 +7,8 @@
>   * Authors: Eric Knopp
>   */
>  
> +#include 
> +
>  #include 
>  
>  #include "psb_drv.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_acpi.c 
> b/drivers/gpu/drm/radeon/radeon_acpi.c
> index b603c0b77075..5771d1fcb073 100644
> --- a/drivers/gpu/drm/radeon/radeon_acpi.c
> +++ b/drivers/gpu/drm/radeon/radeon_acpi.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,7 +31,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  
>  #include "atom.h"
> -- 
> 2.39.0

Re: Is "perfectly equal monitors" really required to reclock MCLK

[Christian König]

Am 13.01.23 um 16:09 schrieb Alex Deucher:

On Fri, Jan 13, 2023 at 10:05 AM Braiam  wrote:

AMD RX 590. Forgot to include it. How do I know the blanking period?

OK polaris falls into the first bucket.  Look at the full modelines.
E.g., xrandr --verbose.


Would variable refresh rate mess up with that?

Probably.


Totally, as far as I know VRR is currently a complete show stopper for 
reclocking the MCLK.


But on the other hand VRR could potentially be used to artificially 
create some overlapping VBLANK period to do the actually reclocking. 
Interesting idea.


We might want to ping Harry or somebody else form the DC team if they 
have thought about that yet.


Christian.



Alex


On Fri, Jan 13, 2023 at 10:57 AM Alex Deucher  wrote:

On Fri, Jan 13, 2023 at 9:47 AM Braiam  wrote:

Hi,

I have two monitors with the current following configuration:

Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
right x axis y axis) 597mm x 336mm
2560x1440164.83 +  59.95 + 120.05*   96.0172.0160.01
143.97   120.0074.97
[snip]
DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x
axis y axis) 597mm x 336mm
2560x1440165.00 +  59.95 + 120.06*   96.0472.0160.01
50.0148.01   144.00   119.9999.99
[snip]
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-1 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)

The pp_profile_mode:

NUMMODE_NAME SCLK_UP_HYST   SCLK_DOWN_HYST
SCLK_ACTIVE_LEVEL MCLK_UP_HYST   MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
   0   BOOTUP_DEFAULT:---
  ---
   1 3D_FULL_SCREEN *:0  100   30
 10   60   25
   2 POWER_SAVING:   100   30
  ---
   3VIDEO:---
 10   16   31
   4   VR:0   11   50
  0  100   10
   5  COMPUTE:05   30
  ---
   6   CUSTOM:---
  ---

I have set their refresh rate to 72.01 which is a mode equal for both,
and the MCLK wasn't downclocked either. They are branded HP and
Scepter. Using a vtty doesn't help either.

Is having the exact same monitor really required? If not, how can I
check what is causing
the memory clock to be pegged that high?

It depends what GPU you have.  Older ones can only reclock memory
during the vertical blanking period assuming it's long enough as the
whole reclocking process takes a certain amount of time.  If it
doesn't happen during the blanking period you will get visible
glitches on the screen when the reclock happens.  If the vertical
blanking period is not long enough or if the vblank periods are not
aligned when using multiple monitors, the driver doesn't reclock.  The
mode lines (not just the refresh rate) have to be the exact same for
the vblanks to line up when using multiple monitors.  Your best bet is
to take the mode line you want to use from one monitor and apply it to
the other monitor.  Newer GPUs have more flexibility and can reclock
memory in more situations, but there are still some monitors where the
timing may not work out.

What GPU do you have?

Alex



--
Braiam

Re: [PATCH v2 00/10] drm: Do not include unnecessarily

[Sam Ravnborg]

Hi Thomas.
On Wed, Jan 11, 2023 at 02:01:56PM +0100, Thomas Zimmermann wrote:
> Remove unnecessary include statements for . I recently
> changed this header and had to rebuild a good part of DRM. So avoid
> this by removing the dependency.
> 
> Several files include  via drm_fb_helper.h. So in v2 I
> added additional patches that remove some of those include statements
> as well.
> 
> Some source files require the OF or backlight headers. Include those
> instead.
> 
> v2:
>   * add more patches to handle drm_fb_helper.h includes
>   * fix komeda build (kernel test robot)

Whole series are:
Acked-by: Sam Ravnborg 

Except for the patches where I added an explicit r-b.

Sam

Re: Is "perfectly equal monitors" really required to reclock MCLK

[Braiam]

AMD RX 590. Forgot to include it. How do I know the blanking period?
Would variable refresh rate mess up with that?

On Fri, Jan 13, 2023 at 10:57 AM Alex Deucher  wrote:
>
> On Fri, Jan 13, 2023 at 9:47 AM Braiam  wrote:
> >
> > Hi,
> >
> > I have two monitors with the current following configuration:
> >
> > Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
> > DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
> > right x axis y axis) 597mm x 336mm
> >2560x1440164.83 +  59.95 + 120.05*   96.0172.0160.01
> > 143.97   120.0074.97
> > [snip]
> > DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x
> > axis y axis) 597mm x 336mm
> >2560x1440165.00 +  59.95 + 120.06*   96.0472.0160.01
> > 50.0148.01   144.00   119.9999.99
> > [snip]
> > HDMI-A-0 disconnected (normal left inverted right x axis y axis)
> > HDMI-A-1 disconnected (normal left inverted right x axis y axis)
> > DVI-D-0 disconnected (normal left inverted right x axis y axis)
> >
> > The pp_profile_mode:
> >
> > NUMMODE_NAME SCLK_UP_HYST   SCLK_DOWN_HYST
> > SCLK_ACTIVE_LEVEL MCLK_UP_HYST   MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
> >   0   BOOTUP_DEFAULT:---
> >  ---
> >   1 3D_FULL_SCREEN *:0  100   30
> > 10   60   25
> >   2 POWER_SAVING:   100   30
> >  ---
> >   3VIDEO:---
> > 10   16   31
> >   4   VR:0   11   50
> >  0  100   10
> >   5  COMPUTE:05   30
> >  ---
> >   6   CUSTOM:---
> >  ---
> >
> > I have set their refresh rate to 72.01 which is a mode equal for both,
> > and the MCLK wasn't downclocked either. They are branded HP and
> > Scepter. Using a vtty doesn't help either.
> >
> > Is having the exact same monitor really required? If not, how can I
> > check what is causing
> > the memory clock to be pegged that high?
>
> It depends what GPU you have.  Older ones can only reclock memory
> during the vertical blanking period assuming it's long enough as the
> whole reclocking process takes a certain amount of time.  If it
> doesn't happen during the blanking period you will get visible
> glitches on the screen when the reclock happens.  If the vertical
> blanking period is not long enough or if the vblank periods are not
> aligned when using multiple monitors, the driver doesn't reclock.  The
> mode lines (not just the refresh rate) have to be the exact same for
> the vblanks to line up when using multiple monitors.  Your best bet is
> to take the mode line you want to use from one monitor and apply it to
> the other monitor.  Newer GPUs have more flexibility and can reclock
> memory in more situations, but there are still some monitors where the
> timing may not work out.
>
> What GPU do you have?
>
> Alex



-- 
Braiam

Re: Is "perfectly equal monitors" really required to reclock MCLK

[Alex Deucher]

On Fri, Jan 13, 2023 at 10:05 AM Braiam  wrote:
>
> AMD RX 590. Forgot to include it. How do I know the blanking period?

OK polaris falls into the first bucket.  Look at the full modelines.
E.g., xrandr --verbose.

> Would variable refresh rate mess up with that?

Probably.

Alex

>
> On Fri, Jan 13, 2023 at 10:57 AM Alex Deucher  wrote:
> >
> > On Fri, Jan 13, 2023 at 9:47 AM Braiam  wrote:
> > >
> > > Hi,
> > >
> > > I have two monitors with the current following configuration:
> > >
> > > Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
> > > DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
> > > right x axis y axis) 597mm x 336mm
> > >2560x1440164.83 +  59.95 + 120.05*   96.0172.0160.01
> > > 143.97   120.0074.97
> > > [snip]
> > > DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x
> > > axis y axis) 597mm x 336mm
> > >2560x1440165.00 +  59.95 + 120.06*   96.0472.0160.01
> > > 50.0148.01   144.00   119.9999.99
> > > [snip]
> > > HDMI-A-0 disconnected (normal left inverted right x axis y axis)
> > > HDMI-A-1 disconnected (normal left inverted right x axis y axis)
> > > DVI-D-0 disconnected (normal left inverted right x axis y axis)
> > >
> > > The pp_profile_mode:
> > >
> > > NUMMODE_NAME SCLK_UP_HYST   SCLK_DOWN_HYST
> > > SCLK_ACTIVE_LEVEL MCLK_UP_HYST   MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
> > >   0   BOOTUP_DEFAULT:---
> > >  ---
> > >   1 3D_FULL_SCREEN *:0  100   30
> > > 10   60   25
> > >   2 POWER_SAVING:   100   30
> > >  ---
> > >   3VIDEO:---
> > > 10   16   31
> > >   4   VR:0   11   50
> > >  0  100   10
> > >   5  COMPUTE:05   30
> > >  ---
> > >   6   CUSTOM:---
> > >  ---
> > >
> > > I have set their refresh rate to 72.01 which is a mode equal for both,
> > > and the MCLK wasn't downclocked either. They are branded HP and
> > > Scepter. Using a vtty doesn't help either.
> > >
> > > Is having the exact same monitor really required? If not, how can I
> > > check what is causing
> > > the memory clock to be pegged that high?
> >
> > It depends what GPU you have.  Older ones can only reclock memory
> > during the vertical blanking period assuming it's long enough as the
> > whole reclocking process takes a certain amount of time.  If it
> > doesn't happen during the blanking period you will get visible
> > glitches on the screen when the reclock happens.  If the vertical
> > blanking period is not long enough or if the vblank periods are not
> > aligned when using multiple monitors, the driver doesn't reclock.  The
> > mode lines (not just the refresh rate) have to be the exact same for
> > the vblanks to line up when using multiple monitors.  Your best bet is
> > to take the mode line you want to use from one monitor and apply it to
> > the other monitor.  Newer GPUs have more flexibility and can reclock
> > memory in more situations, but there are still some monitors where the
> > timing may not work out.
> >
> > What GPU do you have?
> >
> > Alex
>
>
>
> --
> Braiam

Re: [PATCH] drm/amdgpu: revert part of a commit fac53471d0ea9

[Alex Deucher]

On Fri, Jan 13, 2023 at 4:44 AM  wrote:
>
> From: Vitaly Prosyak 
>
> Revert the following change: move drm_dev_unplug call after
> amdgpu_driver_unload_kms in amdgpu_pci_remove.
> The reason is following: amdgpu_pci_remove calls drm_dev_unregister
> and it should be called first to ensure userspace can't access the
> device instance anymore. If we call drm_dev_unplug after
> amdgpu_driver_unload_kms then we observe IGT PCI software unplug
> test failure (kernel hung) for all ASIC's. This is how this
> regression was found.

Maybe just revert the entire patch rather than a partial revert?  That
said, reverting the change will break
driver unload because we need to send certain messages to the PSP to
clean things up.  I'm not sure
what the best way around that is.

Alex

>
> Signed-off-by: Vitaly Prosyak 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 06aba201d4db..8a1047224000 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -2226,6 +2226,8 @@ amdgpu_pci_remove(struct pci_dev *pdev)
> struct drm_device *dev = pci_get_drvdata(pdev);
> struct amdgpu_device *adev = drm_to_adev(dev);
>
> +   drm_dev_unplug(dev);
> +
> if (adev->pm.rpm_mode != AMDGPU_RUNPM_NONE) {
> pm_runtime_get_sync(dev->dev);
> pm_runtime_forbid(dev->dev);
> @@ -2265,7 +2267,7 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>
> amdgpu_driver_unload_kms(dev);
>
> -   drm_dev_unplug(dev);
> +
>
> /*
>  * Flush any in flight DMA operations from device.
> --
> 2.25.1
>

Re: Is "perfectly equal monitors" really required to reclock MCLK

[Christian König]

Am 13.01.23 um 11:35 schrieb Braiam:

Hi,

I have two monitors with the current following configuration:

Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
right x axis y axis) 597mm x 336mm
2560x1440164.83 +  59.95 + 120.05*   96.0172.0160.01
143.97   120.0074.97
[snip]
DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x
axis y axis) 597mm x 336mm
2560x1440165.00 +  59.95 + 120.06*   96.0472.0160.01
50.0148.01   144.00   119.9999.99
[snip]
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-1 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)

The pp_profile_mode:

NUMMODE_NAME SCLK_UP_HYST   SCLK_DOWN_HYST
SCLK_ACTIVE_LEVEL MCLK_UP_HYST   MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
   0   BOOTUP_DEFAULT:---
  ---
   1 3D_FULL_SCREEN *:0  100   30
 10   60   25
   2 POWER_SAVING:   100   30
  ---
   3VIDEO:---
 10   16   31
   4   VR:0   11   50
  0  100   10
   5  COMPUTE:05   30
  ---
   6   CUSTOM:---
  ---

I have set their refresh rate to 72.01 which is a mode equal for both,
and the MCLK wasn't downclocked either. They are branded HP and
Scepter. Using a vtty doesn't help either.

Is having the exact same monitor really required? If not, how can I
check what is causing
the memory clock to be pegged that high?


First of all you need a minimum MCLK to support scanout for two 
monitors, so even if you have two identical monitors your minimum MCLK 
is higher.


Then for MCLK switching in the VBLANK period the two monitors must run 
in sync with each other, e.g. using the same PLL source and having the 
VBLANK at the same time.


For this not only the refresh rate, resolution and pixel clock needs to 
be the same, but also all the other timing parameters must match exactly.


Could be that you can run both monitors with the same mode, but that 
they have that by coincident is rather unlikely if they are not identical.


Regards,
Christian.



I'm using 6.0.0-6-amd64 from Debian testing.

Re: Is "perfectly equal monitors" really required to reclock MCLK

[Alex Deucher]

On Fri, Jan 13, 2023 at 9:47 AM Braiam  wrote:
>
> Hi,
>
> I have two monitors with the current following configuration:
>
> Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
> DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
> right x axis y axis) 597mm x 336mm
>2560x1440164.83 +  59.95 + 120.05*   96.0172.0160.01
> 143.97   120.0074.97
> [snip]
> DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x
> axis y axis) 597mm x 336mm
>2560x1440165.00 +  59.95 + 120.06*   96.0472.0160.01
> 50.0148.01   144.00   119.9999.99
> [snip]
> HDMI-A-0 disconnected (normal left inverted right x axis y axis)
> HDMI-A-1 disconnected (normal left inverted right x axis y axis)
> DVI-D-0 disconnected (normal left inverted right x axis y axis)
>
> The pp_profile_mode:
>
> NUMMODE_NAME SCLK_UP_HYST   SCLK_DOWN_HYST
> SCLK_ACTIVE_LEVEL MCLK_UP_HYST   MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
>   0   BOOTUP_DEFAULT:---
>  ---
>   1 3D_FULL_SCREEN *:0  100   30
> 10   60   25
>   2 POWER_SAVING:   100   30
>  ---
>   3VIDEO:---
> 10   16   31
>   4   VR:0   11   50
>  0  100   10
>   5  COMPUTE:05   30
>  ---
>   6   CUSTOM:---
>  ---
>
> I have set their refresh rate to 72.01 which is a mode equal for both,
> and the MCLK wasn't downclocked either. They are branded HP and
> Scepter. Using a vtty doesn't help either.
>
> Is having the exact same monitor really required? If not, how can I
> check what is causing
> the memory clock to be pegged that high?

It depends what GPU you have.  Older ones can only reclock memory
during the vertical blanking period assuming it's long enough as the
whole reclocking process takes a certain amount of time.  If it
doesn't happen during the blanking period you will get visible
glitches on the screen when the reclock happens.  If the vertical
blanking period is not long enough or if the vblank periods are not
aligned when using multiple monitors, the driver doesn't reclock.  The
mode lines (not just the refresh rate) have to be the exact same for
the vblanks to line up when using multiple monitors.  Your best bet is
to take the mode line you want to use from one monitor and apply it to
the other monitor.  Newer GPUs have more flexibility and can reclock
memory in more situations, but there are still some monitors where the
timing may not work out.

What GPU do you have?

Alex

Is "perfectly equal monitors" really required to reclock MCLK

[Braiam]

Hi,

I have two monitors with the current following configuration:

Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384
DisplayPort-0 connected primary 2560x1440+0+0 (normal left inverted
right x axis y axis) 597mm x 336mm
   2560x1440164.83 +  59.95 + 120.05*   96.0172.0160.01
143.97   120.0074.97
[snip]
DisplayPort-1 connected 2560x1440+2560+0 (normal left inverted right x
axis y axis) 597mm x 336mm
   2560x1440165.00 +  59.95 + 120.06*   96.0472.0160.01
50.0148.01   144.00   119.9999.99
[snip]
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-1 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)

The pp_profile_mode:

NUMMODE_NAME SCLK_UP_HYST   SCLK_DOWN_HYST
SCLK_ACTIVE_LEVEL MCLK_UP_HYST   MCLK_DOWN_HYST MCLK_ACTIVE_LEVEL
  0   BOOTUP_DEFAULT:---
 ---
  1 3D_FULL_SCREEN *:0  100   30
10   60   25
  2 POWER_SAVING:   100   30
 ---
  3VIDEO:---
10   16   31
  4   VR:0   11   50
 0  100   10
  5  COMPUTE:05   30
 ---
  6   CUSTOM:---
 ---

I have set their refresh rate to 72.01 which is a mode equal for both,
and the MCLK wasn't downclocked either. They are branded HP and
Scepter. Using a vtty doesn't help either.

Is having the exact same monitor really required? If not, how can I
check what is causing
the memory clock to be pegged that high?

I'm using 6.0.0-6-amd64 from Debian testing.

-- 
Braiam

Re: [PATCH 0/5] drm: Do not include unnecessarily

[Maxime Ripard]

On Mon, Jan 09, 2023 at 11:12:38AM +0100, Thomas Zimmermann wrote:
> Remove unnecessary include statements for . I recently
> changed this header and had to rebuild a good part of DRM. So avoid
> this by removing the dependency.
> 
> Some source files require the OF or backlight headers. Include those
> instead.

For the series:
Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature

[PATCH] drm/amdgpu: Add a missing tab

[Dan Carpenter]

This tab was deleted accidentally and triggers a Smatch warning:

drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:1006 gfx_v8_0_init_microcode()
warn: inconsistent indenting

Add it back.

Fixes: 0aaafb7359d2 ("drm/amd: Use `amdgpu_ucode_*` helpers for GFX8")
Signed-off-by: Dan Carpenter 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 4fb577d047fd..b1f2684d854a 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
@@ -1003,7 +1003,7 @@ static int gfx_v8_0_init_microcode(struct amdgpu_device 
*adev)
err = amdgpu_ucode_request(adev, >gfx.me_fw, fw_name);
if (err == -ENODEV) {
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", 
chip_name);
-   err = amdgpu_ucode_request(adev, >gfx.me_fw, fw_name);
+   err = amdgpu_ucode_request(adev, >gfx.me_fw, 
fw_name);
}
} else {
snprintf(fw_name, sizeof(fw_name), "amdgpu/%s_me.bin", 
chip_name);
--
2.35.1

Re: [PATCH] drm/amdgpu: Renoir/Cezanne GPU power reporting issue

[Alex Deucher]

Reviewed-by: Alex Deucher 

On Thu, Jan 12, 2023 at 9:11 PM Liu, Aaron  wrote:
>
> Reviewed-by: Aaron Liu aaron@amd.com
>
>
>
> From: amd-gfx  On Behalf Of Zhang, 
> Jesse(Jie)
> Sent: Friday, January 13, 2023 10:07 AM
> To: Deucher, Alexander 
> Cc: amd-gfx@lists.freedesktop.org
> Subject: [PATCH] drm/amdgpu: Renoir/Cezanne GPU power reporting issue
>
>
>
> [AMD Official Use Only - General]
>
>
>
>
>
> drm/amdgpu: Correct the power calcultion for Renior/Cezanne.
>
> From smu firmware,the value of power is transferred  in units of watts.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2321
>
> Fixes: 137aac26a2ed ("drm/amdgpu/smu12: fix power reporting on renoir")
>
>
>
> Acked-by: Alex Deucher alexander.deuc...@amd.com
>
> Signed-off-by: Jesse Zhang jesse.zh...@amd.com
>
>
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c 
> b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
>
> index 85e22210963f..96a49a3b3ad9 100644
>
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
>
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c
>
> @@ -1171,6 +1171,7 @@ static int renoir_get_smu_metrics_data(struct 
> smu_context *smu,
>
> int ret = 0;
>
> uint32_t apu_percent = 0;
>
> uint32_t dgpu_percent = 0;
>
> +   struct amdgpu_device *adev = smu->adev;
>
>
>
>
>
> ret = smu_cmn_get_metrics_table(smu,
>
> @@ -1196,7 +1197,11 @@ static int renoir_get_smu_metrics_data(struct 
> smu_context *smu,
>
> *value = metrics->AverageUvdActivity / 100;
>
> break;
>
> case METRICS_AVERAGE_SOCKETPOWER:
>
> -   *value = (metrics->CurrentSocketPower << 8) / 1000;
>
> +   if (((adev->ip_versions[MP1_HWIP][0] == IP_VERSION(12, 0, 1)) 
> && (adev->pm.fw_version >= 0x4f))
>
> +   || ((adev->ip_versions[MP1_HWIP][0] == IP_VERSION(12, 
> 0, 0)) && (adev->pm.fw_version >= 0x373200)))
>
> +   *value = metrics->CurrentSocketPower << 8;
>
> +   else
>
> +   *value = (metrics->CurrentSocketPower << 8) / 1000;
>
> break;
>
> case METRICS_TEMPERATURE_EDGE:
>
> *value = (metrics->GfxTemperature / 100) *

Re: [PATCH] drm/amdgpu/smu: skip pptable init under sriov

[Alex Deucher]

On Fri, Jan 13, 2023 at 5:56 AM Jane Jian  wrote:
>
> sriov does not need to init pptable from amdgpu driver
> we finish it from PF
>
> Signed-off-by: Jane Jian 
> ---
>  drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c 
> b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> index d0cdc578344d..d07b0cfe23b4 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
> @@ -407,6 +407,9 @@ static int smu_v13_0_0_setup_pptable(struct smu_context 
> *smu)
> struct amdgpu_device *adev = smu->adev;
> int ret = 0;
>
> +   if(amdgpu_sriov_vf(smu->adev))

Space between if and (.

> +   return 0;
> +
> ret = smu_v13_0_0_get_pptable_from_pmfw(smu,
> _table->power_play_table,
> 
> _table->power_play_table_size);
> @@ -1257,6 +1260,9 @@ static int 
> smu_v13_0_0_get_thermal_temperature_range(struct smu_context *smu,
> table_context->power_play_table;
> PPTable_t *pptable = smu->smu_table.driver_pptable;
>
> +   if(amdgpu_sriov_vf(smu->adev))

Space between if and (.

with those fixed:
Reviewed-by: Alex Deucher 

> +   return 0;
> +
> if (!range)
> return -EINVAL;
>
> --
> 2.17.1
>

Re: Wrong revert commit in stable channel

[Alex Deucher]

Looks like Sasha picked it up again for some reason.  I'll revert that on 6.1.x.

Alex

On Fri, Jan 13, 2023 at 1:02 AM Yury Zhuravlev  wrote:
>
> Yes, this is right in 6.2-rc3
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/amd/pm/powerplay/hwmgr?h=v6.2-rc3=f936f535fa70f35ce3369b1418ebae0e657cda6a
>
>
> But somebody reverted it again for the stable stream:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.1.4=9ccd11718d76b95c69aa773f2abedef560776037
>
>
> On Wed, Jan 11, 2023 at 5:35 PM Chen, Guchun  wrote:
>>
>> Hi Yury,
>>
>>
>>
>> My understanding is though that’s a revert of your original patch, we did a 
>> revert again on top of the reverted patch later on. Can you please sync to 
>> below commit to check again? Or do I understand wrong?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/amd/pm/powerplay/hwmgr?h=v6.2-rc3=f936f535fa70f35ce3369b1418ebae0e657cda6a
>>
>>
>>
>> Regards,
>>
>> Guchun
>>
>>
>>
>> From: amd-gfx  On Behalf Of Yury 
>> Zhuravlev
>> Sent: Wednesday, January 11, 2023 4:26 PM
>> To: amd-gfx@lists.freedesktop.org
>> Subject: Wrong revert commit in stable channel
>>
>>
>>
>> Hello,
>>
>>
>>
>> Something went wrong, and we commited what we diced not commit.
>>
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.2-rc3=e5b781c56d46c44c52caa915f1b65064f2f7c1ba
>>
>>
>>
>> and
>>
>>
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.2-rc3=4545ae2ed3f2f7c3f615a53399c9c8460ee5bca7
>>
>>
>>
>> It's wrong reverts because, initially was an issue with a test case, not a 
>> patch itself.
>>
>> My GPU is not working correctly again after such "stable" patch.

Re: [PATCH v2 1/3] drm/framebuffer: Check for valid formats

[Ville Syrjälä]

On Fri, Jan 13, 2023 at 08:27:42AM -0300, Maíra Canal wrote:
> Currently, framebuffer_check() doesn't check if the pixel format is
> supported, which can lead to the acceptance of invalid pixel formats
> e.g. the acceptance of invalid modifiers. Therefore, add a check for
> valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
> calls with invalid formats.
> 
> Moreover, note that this check is only valid for atomic drivers,
> because, for non-atomic drivers, checking drm_any_plane_has_format() is
> not possible since the format list for the primary plane is fake, and
> we'd therefore reject valid formats.
> 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Maíra Canal 
> ---
>  Documentation/gpu/todo.rst| 9 -
>  drivers/gpu/drm/drm_framebuffer.c | 8 
>  2 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 1f8a5ebe188e..3a79c26c5cc7 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -276,11 +276,10 @@ Various hold-ups:
>  - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom 
> fb
>setup code can't be deleted.
>  
> -- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
> -  atomic drivers we could check for valid formats by calling
> -  drm_plane_check_pixel_format() against all planes, and pass if any plane
> -  supports the format. For non-atomic that's not possible since like the 
> format
> -  list for the primary plane is fake and we'd therefor reject valid formats.
> +- Need to switch to drm_gem_fb_create(), as now framebuffer_check() checks 
> for
> +  valid formats for atomic drivers.
> +
> +- Add an addfb format validation for non-atomic drivers.
>  
>  - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
>version of the varios drm_gem_fb_create functions. Maybe called
> diff --git a/drivers/gpu/drm/drm_framebuffer.c 
> b/drivers/gpu/drm/drm_framebuffer.c
> index aff3746dedfb..605642bf3650 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -280,6 +280,14 @@ static int framebuffer_check(struct drm_device *dev,
>   }
>   }
>  
> + /* Verify that the modifier is supported. */
> + if (drm_drv_uses_atomic_modeset(dev) &&
> + !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
> + drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 
> 0x%llx\n",
> + >pixel_format, r->modifier[0]);
> + return -EINVAL;
> + }

Like I said this is still wrong for the !modifiers case.

> +
>   return 0;
>  }
>  
> -- 
> 2.39.0

-- 
Ville Syrjälä
Intel

Re: [PATCH 0/5] drm: Do not include unnecessarily

[Thomas Zimmermann]

Am 13.01.23 um 11:36 schrieb Maxime Ripard:

On Mon, Jan 09, 2023 at 11:12:38AM +0100, Thomas Zimmermann wrote:

Remove unnecessary include statements for . I recently
changed this header and had to rebuild a good part of DRM. So avoid
this by removing the dependency.

Some source files require the OF or backlight headers. Include those
instead.


For the series:
Acked-by: Maxime Ripard 


per irc discussion, acked for all of v2 as well



Maxime


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


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] drm/amdgpu: print bo inode number instead of ptr

[Christian König]

Am 12.01.23 um 17:59 schrieb Pierre-Eric Pelloux-Prayer:

This allows to correlate the infos printed by
/sys/kernel/debug/dri/n/amdgpu_gem_info to the ones found
in /proc/.../fdinfo and /sys/kernel/debug/dma_buf/bufinfo.

Signed-off-by: Pierre-Eric Pelloux-Prayer 


Reviewed-by: Christian König 


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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 90eb07106609..2b076ed46e78 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -1572,9 +1572,9 @@ u64 amdgpu_bo_print_info(int id, struct amdgpu_bo *bo, 
struct seq_file *m)
attachment = READ_ONCE(bo->tbo.base.import_attach);
  
  	if (attachment)

-   seq_printf(m, " imported from %p", dma_buf);
+   seq_printf(m, " imported from ino:%lu", 
file_inode(dma_buf->file)->i_ino);
else if (dma_buf)
-   seq_printf(m, " exported as %p", dma_buf);
+   seq_printf(m, " exported as ino:%lu", 
file_inode(dma_buf->file)->i_ino);
  
  	amdgpu_bo_print_flag(m, bo, CPU_ACCESS_REQUIRED);

amdgpu_bo_print_flag(m, bo, NO_CPU_ACCESS);

[PATCH v2 3/3] drm/vmwgfx: Remove redundant framebuffer format check

[Maíra Canal]

Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on vmwgfx's inside
helpers.

Therefore, remove the redundant framebuffer format check from the
vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_bo()
functions, letting framebuffer_check() perform the framebuffer
validation.

Reviewed-by: Zack Rusin 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 257f090071f1..05b8d8f912bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1317,15 +1317,6 @@ static int vmw_kms_new_framebuffer_surface(struct 
vmw_private *dev_priv,
 * Sanity checks.
 */

-   if (!drm_any_plane_has_format(_priv->drm,
- mode_cmd->pixel_format,
- mode_cmd->modifier[0])) {
-   drm_dbg(_priv->drm,
-   "unsupported pixel format %p4cc / modifier 0x%llx\n",
-   _cmd->pixel_format, mode_cmd->modifier[0]);
-   return -EINVAL;
-   }
-
/* Surface must be marked as a scanout. */
if (unlikely(!surface->metadata.scanout))
return -EINVAL;
@@ -1648,15 +1639,6 @@ static int vmw_kms_new_framebuffer_bo(struct vmw_private 
*dev_priv,
return -EINVAL;
}

-   if (!drm_any_plane_has_format(_priv->drm,
- mode_cmd->pixel_format,
- mode_cmd->modifier[0])) {
-   drm_dbg(_priv->drm,
-   "unsupported pixel format %p4cc / modifier 0x%llx\n",
-   _cmd->pixel_format, mode_cmd->modifier[0]);
-   return -EINVAL;
-   }
-
vfbd = kzalloc(sizeof(*vfbd), GFP_KERNEL);
if (!vfbd) {
ret = -ENOMEM;
--
2.39.0

[PATCH v2 2/3] drm/amdgpu: Remove redundant framebuffer format check

[Maíra Canal]

Now that framebuffer_check() verifies that the format is properly
supported, there is no need to check it again on amdgpu's inside
helpers.

Therefore, remove the redundant framebuffer format check from the
amdgpu_display_gem_fb_verify_and_init() function, letting
framebuffer_check() perform the framebuffer validation.

Reviewed-by: Simon Ser 
Signed-off-by: Maíra Canal 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index b22471b3bd63..611b7a4b086c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1120,16 +1120,6 @@ static int amdgpu_display_gem_fb_verify_and_init(struct 
drm_device *dev,
 
rfb->base.obj[0] = obj;
drm_helper_mode_fill_fb_struct(dev, >base, mode_cmd);
-   /* Verify that the modifier is supported. */
-   if (!drm_any_plane_has_format(dev, mode_cmd->pixel_format,
- mode_cmd->modifier[0])) {
-   drm_dbg_kms(dev,
-   "unsupported pixel format %p4cc / modifier 
0x%llx\n",
-   _cmd->pixel_format, mode_cmd->modifier[0]);
-
-   ret = -EINVAL;
-   goto err;
-   }
 
ret = amdgpu_display_framebuffer_init(dev, rfb, mode_cmd, obj);
if (ret)
-- 
2.39.0

[PATCH v2 1/3] drm/framebuffer: Check for valid formats

[Maíra Canal]

Currently, framebuffer_check() doesn't check if the pixel format is
supported, which can lead to the acceptance of invalid pixel formats
e.g. the acceptance of invalid modifiers. Therefore, add a check for
valid formats on framebuffer_check(), so that the ADDFB2 IOCTL rejects
calls with invalid formats.

Moreover, note that this check is only valid for atomic drivers,
because, for non-atomic drivers, checking drm_any_plane_has_format() is
not possible since the format list for the primary plane is fake, and
we'd therefore reject valid formats.

Reviewed-by: Daniel Vetter 
Signed-off-by: Maíra Canal 
---
 Documentation/gpu/todo.rst| 9 -
 drivers/gpu/drm/drm_framebuffer.c | 8 
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 1f8a5ebe188e..3a79c26c5cc7 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -276,11 +276,10 @@ Various hold-ups:
 - Need to switch to drm_fbdev_generic_setup(), otherwise a lot of the custom fb
   setup code can't be deleted.
 
-- Many drivers wrap drm_gem_fb_create() only to check for valid formats. For
-  atomic drivers we could check for valid formats by calling
-  drm_plane_check_pixel_format() against all planes, and pass if any plane
-  supports the format. For non-atomic that's not possible since like the format
-  list for the primary plane is fake and we'd therefor reject valid formats.
+- Need to switch to drm_gem_fb_create(), as now framebuffer_check() checks for
+  valid formats for atomic drivers.
+
+- Add an addfb format validation for non-atomic drivers.
 
 - Many drivers subclass drm_framebuffer, we'd need a embedding compatible
   version of the varios drm_gem_fb_create functions. Maybe called
diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index aff3746dedfb..605642bf3650 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -280,6 +280,14 @@ static int framebuffer_check(struct drm_device *dev,
}
}
 
+   /* Verify that the modifier is supported. */
+   if (drm_drv_uses_atomic_modeset(dev) &&
+   !drm_any_plane_has_format(dev, r->pixel_format, r->modifier[0])) {
+   drm_dbg_kms(dev, "Unsupported pixel format %p4cc / modifier 
0x%llx\n",
+   >pixel_format, r->modifier[0]);
+   return -EINVAL;
+   }
+
return 0;
 }
 
-- 
2.39.0

[PATCH v2 0/3] Check for valid framebuffer's format

[Maíra Canal]

This series is a follow-up of the [1] in which I introduced a check for valid
formats on drm_gem_fb_create(). During the discussion, I realized that would be
a better idea to put the check inside framebuffer_check() so that it wouldn't be
needed to hit any driver-specific code path when the check fails.

Therefore, add the valid format check inside framebuffer_check() and remove the
same check from the drivers, except from i915, because this doesn't work for the
legacy tiling->modifier path. Adding the check to framebuffer_check() will
guarantee that the igt@kms_addfb_basic@addfb25-bad-modifier IGT test passes,
showing the correct behavior of the check.

This patchset was tested on amdgpu and vc4 with the IGT tests.

[1] 
https://lore.kernel.org/dri-devel/20230103125322.855089-1-mca...@igalia.com/T/

---

v1 -> v2: 
https://lore.kernel.org/dri-devel/20230109105807.18172-1-mca...@igalia.com/T/

- Don't remove check from i915 driver (Ville Syrjälä)
- Don't unexport drm_any_plane_has_format().

---

Best Regards,
- Maíra Canal

Maíra Canal (3):
  drm/framebuffer: Check for valid formats
  drm/amdgpu: Remove redundant framebuffer format check
  drm/vmwgfx: Remove redundant framebuffer format check

 Documentation/gpu/todo.rst  |  9 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 10 --
 drivers/gpu/drm/drm_framebuffer.c   |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 18 --
 4 files changed, 12 insertions(+), 33 deletions(-)

--
2.39.0

[PATCH] drm/amdgpu/smu: skip pptable init under sriov

[Jane Jian]

sriov does not need to init pptable from amdgpu driver
we finish it from PF

Signed-off-by: Jane Jian 
---
 drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
index d0cdc578344d..d07b0cfe23b4 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_0_ppt.c
@@ -407,6 +407,9 @@ static int smu_v13_0_0_setup_pptable(struct smu_context 
*smu)
struct amdgpu_device *adev = smu->adev;
int ret = 0;
 
+   if(amdgpu_sriov_vf(smu->adev))
+   return 0;
+
ret = smu_v13_0_0_get_pptable_from_pmfw(smu,
_table->power_play_table,

_table->power_play_table_size);
@@ -1257,6 +1260,9 @@ static int 
smu_v13_0_0_get_thermal_temperature_range(struct smu_context *smu,
table_context->power_play_table;
PPTable_t *pptable = smu->smu_table.driver_pptable;
 
+   if(amdgpu_sriov_vf(smu->adev))
+   return 0;
+
if (!range)
return -EINVAL;
 
-- 
2.17.1

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Daniel Vetter]

On Fri, Jan 13, 2023 at 12:16:57PM +0200, Jani Nikula wrote:
> 
> Cc: intel-gfx, drm maintainers
> 
> Please have the courtesy of Cc'ing us for changes impacting us, and
> maybe try to involve us earlier instead of surprising us like
> this. Looks like this has been debugged for at least three months, and
> the huge revert at this point is going to set us back with what's been
> developed on top of it for i915 DP MST and DSC.

tbf I assumed this wont land when I've seen it fly by. It feels a bit much
like living under a rock for half a year and then creating a mess for
everyone else who's been building on top of this is not great.

Like yes it's a regression, but apparently not a blantantly obvious one,
and I think if we just ram this in there's considerable community goodwill
down the drain. Someone needs to get that goodwill up the drain again.

> It's a regression, I get that, but this is also going to be really nasty
> to deal with. It's a 2500-line commit, plus the dependencies, which I
> don't think are accounted for here. (What's the baseline for the revert
> anyway?) I don't expect all the dependent commits to be easy to revert
> or backport to v6.1 or v6.2.
> 
> *sad trombone*

Yeah that's the other thing. 2500 patch revert is not cc stable material.
So this isn't even really helping users all that much.

Unless it also comes with full amounts of backports of the reverts on all
affected drivers for all curent stable trees, fully validated.

This is bad. I do think we need to have some understanding first of what
"fix this in amdgpu" would look like as plan B. Because plan A does not
look like a happy one at all.
-Daniel

> BR,
> Jani.
> 
> 
> On Thu, 12 Jan 2023, Wayne Lin  wrote:
> > This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
> >
> > [Why]
> > Changes cause regression on amdgpu mst.
> > E.g.
> > In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove 
> > payload
> > one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
> > maintained payload table. But previous change tries to go through all the
> > payloads in mst_state and update amdpug hw maintained table in once 
> > everytime
> > driver only tries to add/remove a specific payload stream only. The newly
> > design idea conflicts with the implementation in amdgpu nowadays.
> >
> > [How]
> > Revert this patch first. After addressing all regression problems caused by
> > this previous patch, will add it back and adjust it.
> >
> > Signed-off-by: Wayne Lin 
> > Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
> > Cc: sta...@vger.kernel.org # 6.1
> > Cc: Lyude Paul 
> > Cc: Harry Wentland 
> > Cc: Mario Limonciello 
> > Cc: Ville Syrjälä 
> > Cc: Ben Skeggs 
> > Cc: Stanislav Lisovskiy 
> > Cc: Fangzhi Zuo 
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  53 +-
> >  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 106 ++-
> >  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  87 ++-
> >  .../amd/display/include/link_service_types.h  |   3 -
> >  drivers/gpu/drm/display/drm_dp_mst_topology.c | 724 --
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  67 +-
> >  drivers/gpu/drm/i915/display/intel_hdcp.c |  24 +-
> >  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 167 ++--
> >  include/drm/display/drm_dp_mst_helper.h   | 177 +++--
> >  9 files changed, 878 insertions(+), 530 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 77277d90b6e2..674f5dc1102b 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct 
> > drm_encoder *encoder,
> > const struct drm_display_mode *adjusted_mode = 
> > _state->adjusted_mode;
> > struct drm_dp_mst_topology_mgr *mst_mgr;
> > struct drm_dp_mst_port *mst_port;
> > -   struct drm_dp_mst_topology_state *mst_state;
> > enum dc_color_depth color_depth;
> > int clock, bpp = 0;
> > bool is_y420 = false;
> > @@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct 
> > drm_encoder *encoder,
> > if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
> > return 0;
> >  
> > -   mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
> > -   if (IS_ERR(mst_state))
> > -   return PTR_ERR(mst_state);
> > -
> > -   if (!mst_state->pbn_div)
> > -   mst_state->pbn_div = 
> > dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
> > -
> > if (!state->duplicated) {
> > int max_bpc = conn_state->max_requested_bpc;
> > is_y420 = drm_mode_is_420_also(>display_info, 
> > adjusted_mode) &&
> > @@ -6580,10 +6572,11 @@ static int dm_encoder_helper_atomic_check(struct 
> > drm_encoder *encoder,
> > clock = adjusted_mode->clock;
> > dm_new_connector_state->pbn = 

Re: [PATCH] Revert "drm/display/dp_mst: Move all payload info into the atomic state"

[Jani Nikula]

Cc: intel-gfx, drm maintainers

Please have the courtesy of Cc'ing us for changes impacting us, and
maybe try to involve us earlier instead of surprising us like
this. Looks like this has been debugged for at least three months, and
the huge revert at this point is going to set us back with what's been
developed on top of it for i915 DP MST and DSC.

It's a regression, I get that, but this is also going to be really nasty
to deal with. It's a 2500-line commit, plus the dependencies, which I
don't think are accounted for here. (What's the baseline for the revert
anyway?) I don't expect all the dependent commits to be easy to revert
or backport to v6.1 or v6.2.

*sad trombone*


BR,
Jani.


On Thu, 12 Jan 2023, Wayne Lin  wrote:
> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
>
> [Why]
> Changes cause regression on amdgpu mst.
> E.g.
> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload
> one by one and call fill_dc_mst_payload_table_from_drm() to update the HW
> maintained payload table. But previous change tries to go through all the
> payloads in mst_state and update amdpug hw maintained table in once everytime
> driver only tries to add/remove a specific payload stream only. The newly
> design idea conflicts with the implementation in amdgpu nowadays.
>
> [How]
> Revert this patch first. After addressing all regression problems caused by
> this previous patch, will add it back and adjust it.
>
> Signed-off-by: Wayne Lin 
> Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2171
> Cc: sta...@vger.kernel.org # 6.1
> Cc: Lyude Paul 
> Cc: Harry Wentland 
> Cc: Mario Limonciello 
> Cc: Ville Syrjälä 
> Cc: Ben Skeggs 
> Cc: Stanislav Lisovskiy 
> Cc: Fangzhi Zuo 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  53 +-
>  .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 106 ++-
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  87 ++-
>  .../amd/display/include/link_service_types.h  |   3 -
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 724 --
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  67 +-
>  drivers/gpu/drm/i915/display/intel_hdcp.c |  24 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 167 ++--
>  include/drm/display/drm_dp_mst_helper.h   | 177 +++--
>  9 files changed, 878 insertions(+), 530 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 77277d90b6e2..674f5dc1102b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6548,7 +6548,6 @@ static int dm_encoder_helper_atomic_check(struct 
> drm_encoder *encoder,
>   const struct drm_display_mode *adjusted_mode = 
> _state->adjusted_mode;
>   struct drm_dp_mst_topology_mgr *mst_mgr;
>   struct drm_dp_mst_port *mst_port;
> - struct drm_dp_mst_topology_state *mst_state;
>   enum dc_color_depth color_depth;
>   int clock, bpp = 0;
>   bool is_y420 = false;
> @@ -6562,13 +6561,6 @@ static int dm_encoder_helper_atomic_check(struct 
> drm_encoder *encoder,
>   if (!crtc_state->connectors_changed && !crtc_state->mode_changed)
>   return 0;
>  
> - mst_state = drm_atomic_get_mst_topology_state(state, mst_mgr);
> - if (IS_ERR(mst_state))
> - return PTR_ERR(mst_state);
> -
> - if (!mst_state->pbn_div)
> - mst_state->pbn_div = 
> dm_mst_get_pbn_divider(aconnector->mst_port->dc_link);
> -
>   if (!state->duplicated) {
>   int max_bpc = conn_state->max_requested_bpc;
>   is_y420 = drm_mode_is_420_also(>display_info, 
> adjusted_mode) &&
> @@ -6580,10 +6572,11 @@ static int dm_encoder_helper_atomic_check(struct 
> drm_encoder *encoder,
>   clock = adjusted_mode->clock;
>   dm_new_connector_state->pbn = drm_dp_calc_pbn_mode(clock, bpp, 
> false);
>   }
> -
> - dm_new_connector_state->vcpi_slots =
> - drm_dp_atomic_find_time_slots(state, mst_mgr, mst_port,
> -   dm_new_connector_state->pbn);
> + dm_new_connector_state->vcpi_slots = 
> drm_dp_atomic_find_time_slots(state,
> +
> mst_mgr,
> +
> mst_port,
> +
> dm_new_connector_state->pbn,
> +
> dm_mst_get_pbn_divider(aconnector->dc_link));
>   if (dm_new_connector_state->vcpi_slots < 0) {
>   DRM_DEBUG_ATOMIC("failed finding vcpi slots: %d\n", 
> (int)dm_new_connector_state->vcpi_slots);
>   return dm_new_connector_state->vcpi_slots;
> @@ -6654,14 +6647,17 @@ static int dm_update_mst_vcpi_slots_for_dsc(struct 
> drm_atomic_state *state,
>