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

2023-01-16 Thread 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..7d711861b90e 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 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-16 Thread Limonciello, Mario

On 1/16/2023 18:47, Guilherme G. Piccoli wrote:

On 16/01/2023 20:00, Alex Deucher wrote:

[...]

It's not clear to me when this would be used.  We only disable it
briefly during new asic bring up, after that we never touch it again.
No end user on production hardware should ever have to change it and
doing so would break VCN on their system.

Alex


[+ Pierre-Loup]

Steam Deck is facing a pretty weird scenario then heheh

Commit 82132ecc543 ("drm/amdgpu: enable Vangogh VCN indirect sram mode")
corrected a long-term issue in which the indirect SRAM mode wasn't
enabled for Vangogh - and Deck GPU architecture is Vangogh, so it was
working perfectly with that disabled.

Happens that a bad FW candidate seems to have broken something - it was
a bit convoluted to debug, but we proved that disabling indirect SRAM is
a good workaround so far, it "restored the behavior" pre-82132ecc543.

Hence my proposal - this parameter would've made life so much easier,
and we're start using it "downstream" now. While I understand that of
course the FW should be fixed, meanwhile this is a cheap solution to
allow further debug and real use of the system.



For debugging these type of problems, I think an effective debugging 
tactic would have been to mask the IP block (amdgpu.ip_block_mask).




RE: [PATCH 2/2] drm/amdgpu: correct MEC number for gfx11 APUs

2023-01-16 Thread Liu, Aaron
[AMD Official Use Only - General]

The series is
Reviewed-by: Aaron Liu 

> -Original Message-
> From: amd-gfx  On Behalf Of Lang Yu
> Sent: Monday, January 16, 2023 4:20 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Yifan ; Yu, Lang ;
> Koenig, Christian ; Du, Xiaojian
> 
> Subject: [PATCH 2/2] drm/amdgpu: correct MEC number for gfx11 APUs
>
> There is only one MEC on these APUs.
>
> Signed-off-by: Lang Yu 
> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> index 985fe704203e..dd4e0f337f46 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> @@ -1251,10 +1251,8 @@ static int gfx_v11_0_sw_init(void *handle)
>
>   switch (adev->ip_versions[GC_HWIP][0]) {
>   case IP_VERSION(11, 0, 0):
> - case IP_VERSION(11, 0, 1):
>   case IP_VERSION(11, 0, 2):
>   case IP_VERSION(11, 0, 3):
> - case IP_VERSION(11, 0, 4):
>   adev->gfx.me.num_me = 1;
>   adev->gfx.me.num_pipe_per_me = 1;
>   adev->gfx.me.num_queue_per_pipe = 1;
> @@ -1262,6 +1260,15 @@ static int gfx_v11_0_sw_init(void *handle)
>   adev->gfx.mec.num_pipe_per_mec = 4;
>   adev->gfx.mec.num_queue_per_pipe = 4;
>   break;
> + case IP_VERSION(11, 0, 1):
> + case IP_VERSION(11, 0, 4):
> + adev->gfx.me.num_me = 1;
> + adev->gfx.me.num_pipe_per_me = 1;
> + adev->gfx.me.num_queue_per_pipe = 1;
> + adev->gfx.mec.num_mec = 1;
> + adev->gfx.mec.num_pipe_per_mec = 4;
> + adev->gfx.mec.num_queue_per_pipe = 4;
> + break;
>   default:
>   adev->gfx.me.num_me = 1;
>   adev->gfx.me.num_pipe_per_me = 1;
> --
> 2.25.1



Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 5:34 PM Guilherme G. Piccoli
 wrote:
>
> On 16/01/2023 19:27, Liu, Leo wrote:
> > Secure part requires PSP load VCN boot sequence which is with indirect
> > sram mode.
> >
> > Regards,
> > Leo
>
> With that said, and with the plans of just setting the indirect sram
> mode nevertheless (with no switch/cases anymore - I'll submit the V2
> tomorrow if everybody agrees), does anybody oppose to have this
> parameter for debug reasons?

It's not clear to me when this would be used.  We only disable it
briefly during new asic bring up, after that we never touch it again.
No end user on production hardware should ever have to change it and
doing so would break VCN on their system.

Alex

>
> I first considered doing through debugfs, but obviously was a (very) bad
> idea, since this should be an early boot tuning heheh
>
> Cheers,
>
>
> Guilherme


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

2023-01-16 Thread Felix Kuehling

On 2023-01-16 17:12, Errabolu, Ramesh wrote:

[AMD Official Use Only - General]

Comment inline.

Regards,
Ramesh

-Original Message-
From: amd-gfx  On Behalf Of Chen, 
Xiaogang
Sent: Saturday, January 14, 2023 4:28 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org; 
dri-de...@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: Re: [PATCH 6/6] drm/amdgpu: Do bo_va ref counting for KFD BOs

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


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);

Ramesh: Could this stmt to reserve space for fence be applied in patch 4.


Done. Thanks for pointing this out.

Regards,
  Felix





+ 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 4/6] drm/amdgpu: Attach eviction fence on alloc

2023-01-16 Thread Felix Kuehling

On 2023-01-16 17:11, Errabolu, Ramesh wrote:

[AMD Official Use Only - General]

Comment inline.

Regards,
Ramesh

-Original Message-
From: amd-gfx  On Behalf Of Felix 
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Chen, Xiaogang ; Koenig, Christian 

Subject: [PATCH 4/6] drm/amdgpu: Attach eviction fence on alloc

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


Instead of attaching the eviction fence when a KFD BO is first mapped, attach 
it when it is allocated or imported. This in preparation to allow KFD BOs to be 
mapped using the render node API.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 5645103beed0..79213f476493 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -360,6 +360,24 @@ static int amdgpu_amdkfd_bo_validate(struct amdgpu_bo *bo, 
uint32_t domain,
 return ret;
  }

+static int amdgpu_amdkfd_bo_validate_and_fence(struct amdgpu_bo *bo,
+  uint32_t domain,
+  struct dma_fence *fence)
+{
+   int ret = amdgpu_bo_reserve(bo, false);
+
+   if (ret)
+   return ret;
+
+   ret = amdgpu_amdkfd_bo_validate(bo, domain, true);
+   if (!ret)
Ramesh: Should space for fences be reserved before adding one.


Yes, I probably should. I think I fixed this in the later patch because 
I didn't see the problem until I fixed those other issues.





+   dma_resv_add_fence(bo->tbo.base.resv, fence,
+  DMA_RESV_USAGE_BOOKKEEP);
+   amdgpu_bo_unreserve(bo);
+
+   return ret;
+}
+
  static int amdgpu_amdkfd_validate_vm_bo(void *_unused, struct amdgpu_bo *bo)  
{
 return amdgpu_amdkfd_bo_validate(bo, bo->allowed_domains, false);
@@ -1720,6 +1738,11 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
 }
 bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
 bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
+   } else {
+   ret = amdgpu_amdkfd_bo_validate_and_fence(bo, domain,
+   >process_info->eviction_fence->base);
+   if (ret)
+   goto err_validate_bo;
 }

 if (offset)
@@ -1729,6 +1752,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(

  allocate_init_user_pages_failed:
  err_pin_bo:
+err_validate_bo:
 remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
 drm_vma_node_revoke(>vma_node, drm_priv);
  err_node_allow:
@@ -1804,10 +1828,6 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
 if (unlikely(ret))
 return ret;

-   /* The eviction fence should be removed by the last unmap.
-* TODO: Log an error condition if the bo still has the eviction fence
-* attached
-*/
 amdgpu_amdkfd_remove_eviction_fence(mem->bo,
 process_info->eviction_fence);
Ramesh: Is it correct to call remove_eviction() unconditionally? This procedure 
applies to GTT and VRAM BO's only. Furthermore, the fence on these BO's has 
already been removed in the unmap_memory() call.


This patch removes the amdgpu_amdkfd_remove_eviction_fence from 
amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu. So we definitely need to do 
this here.


amdgpu_amdkfd_remove_eviction_fence uses dma_resv_replace_fences. If the 
specified fence is not found in the BO's reservation object, it is a 
no-op. So calling this unconditionally is safe.


Regards,
  Felix




 pr_debug("Release VA 0x%llx - 0x%llx\n", mem->va,
@@ -1931,19 +1951,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
 if (unlikely(ret))
 goto out_unreserve;

-   if (mem->mapped_to_gpu_memory == 0 &&
-   !amdgpu_ttm_tt_get_usermm(bo->tbo.ttm)) {
-   /* Validate BO only once. The eviction fence gets added to BO
-* the first time it is mapped. Validate will wait for all
-* background evictions to complete.
-*/
-   ret = amdgpu_amdkfd_bo_validate(bo, domain, true);
-   if (ret) {
-   pr_debug("Validate failed\n");
-   goto out_unreserve;
-   }
-   }
-
 list_for_each_entry(entry, >attachments, list) {
 if (entry->bo_va->base.vm != avm || entry->is_mapped)
 continue;
@@ -1970,10 +1977,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
  mem->mapped_to_gpu_memory);
 }

-   

Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-16 Thread Guilherme G. Piccoli
On 16/01/2023 19:27, Liu, Leo wrote:
> Secure part requires PSP load VCN boot sequence which is with indirect
> sram mode.
> 
> Regards,
> Leo

With that said, and with the plans of just setting the indirect sram
mode nevertheless (with no switch/cases anymore - I'll submit the V2
tomorrow if everybody agrees), does anybody oppose to have this
parameter for debug reasons?

I first considered doing through debugfs, but obviously was a (very) bad
idea, since this should be an early boot tuning heheh

Cheers,


Guilherme


Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-16 Thread Liu, Leo
Secure part requires PSP load VCN boot sequence which is with indirect sram 
mode.

Regards,
Leo


From: Alex Deucher 
Sent: January 16, 2023 4:50 PM
To: Guilherme G. Piccoli 
Cc: amd-gfx@lists.freedesktop.org ; Jiang, Sonny 
; ker...@gpiccoli.net ; Pan, Xinhui 
; dri-de...@lists.freedesktop.org 
; Lazar, Lijo ; 
Limonciello, Mario ; kernel-...@igalia.com 
; Deucher, Alexander ; Zhu, 
James ; Liu, Leo ; Koenig, Christian 

Subject: Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling 
indirect SRAM mode

On Mon, Jan 16, 2023 at 4:21 PM Guilherme G. Piccoli
 wrote:
>
> Currently the FW loading path perform some checks based on IP model
> and in case it is advertised as supported, the VCN indirect SRAM
> mode is used.
>
> Happens that in case there's any issue on FW and this mode ends-up
> not being properly supported, the driver probe fails [0]. Debugging
> this requires driver rebuilding, so to allow fast debug and experiments,
> add a parameter to force setting indirect SRAM mode to true/false from
> the kernel command-line; parameter default is -1, which doesn't change
> the current driver's behavior.

Probably a question for Leo or James, but I was under the impression
non-indirect mode didn't work on production silicon for most chips,
but maybe I'm mis-remembering that.

Alex


>
> [0] Example of this issue, observed on Steam Deck:
>
> [drm] kiq ring mec 2 pipe 1 q 0
> [drm] failed to load ucode VCN0_RAM(0x3A)
> [drm] psp gfx command LOAD_IP_FW(0x6) failed and response status is 
> (0x)
> amdgpu :04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring 
> vcn_dec_0 test failed (-110)
> [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* hw_init of IP block  
> failed -110
> amdgpu :04:00.0: amdgpu: amdgpu_device_ip_init failed
> amdgpu :04:00.0: amdgpu: Fatal error during GPU init
>
> Cc: James Zhu 
> Cc: Lazar Lijo 
> Cc: Leo Liu 
> Cc: Mario Limonciello 
> Cc: Sonny Jiang 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>
>
> This work is based on agd5f/amd-staging-drm-next branch.
> Thanks in advance for reviews/comments!
> Cheers,
>
> Guilherme
>
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++
>  3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 872450a3a164..5d3c92c94f18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -215,6 +215,7 @@ extern int amdgpu_noretry;
>  extern int amdgpu_force_asic_type;
>  extern int amdgpu_smartshift_bias;
>  extern int amdgpu_use_xgmi_p2p;
> +extern int amdgpu_indirect_sram;
>  #ifdef CONFIG_HSA_AMD
>  extern int sched_policy;
>  extern bool debug_evictions;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 06aba201d4db..c7182c0bc841 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -187,6 +187,7 @@ int amdgpu_num_kcq = -1;
>  int amdgpu_smartshift_bias;
>  int amdgpu_use_xgmi_p2p = 1;
>  int amdgpu_vcnfw_log;
> +int amdgpu_indirect_sram = -1;
>
>  static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
>
> @@ -941,6 +942,14 @@ MODULE_PARM_DESC(smu_pptable_id,
> "specify pptable id to be used (-1 = auto(default) value, 0 = use 
> pptable from vbios, > 0 = soft pptable id)");
>  module_param_named(smu_pptable_id, amdgpu_smu_pptable_id, int, 0444);
>
> +/**
> + * DOC: indirect_sram (int)
> + * Allow users to force using (or not) the VCN indirect SRAM mode in the fw 
> load
> + * code. Default is -1, meaning auto (aka, don't mess with driver's 
> behavior).
> + */
> +MODULE_PARM_DESC(indirect_sram, "Force VCN indirect SRAM (-1 = auto 
> (default), 0 = disabled, 1 = enabled)");
> +module_param_named(indirect_sram, amdgpu_indirect_sram, int, 0444);
> +
>  /* These devices are not supported by amdgpu.
>   * They are supported by the mach64, r128, radeon drivers
>   */
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index 1f880e162d9d..a2290087e01c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -137,6 +137,9 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
> return -EINVAL;
> }
>
> +   if (amdgpu_indirect_sram >= 0)
> +   adev->vcn.indirect_sram = (bool)amdgpu_indirect_sram;
> +
> hdr = (const struct common_firmware_header *)adev->vcn.fw->data;
> adev->vcn.fw_version = le32_to_cpu(hdr->ucode_version);
>
> --
> 2.39.0
>


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

2023-01-16 Thread Felix Kuehling

On 2023-01-16 17:04, Errabolu, Ramesh wrote:

[AMD Official Use Only - General]

A minor comment, unrelated to the patch. The comments are inline.

Regards,
Ramesh

-Original Message-
From: amd-gfx  On Behalf Of Felix 
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Chen, Xiaogang ; Koenig, Christian 

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

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


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); @@ -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;
Ramesh: Is it correct to assign WRITE & EXECUTABLE permissions to alloc_flags 
variable.


These flags affect GPUVM mappings of the BO. If we didn't set these 
flags, the imported BO would be read-only. The existing graphics-interop 
API (struct kfd_ioctl_import_dmabuf_args) doesn't have a way for user 
mode to provide these flags. Changing this would break the API.


Regards,
  Felix




-   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
--
2.34.1


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

2023-01-16 Thread Errabolu, Ramesh
[AMD Official Use Only - General]

Comment inline.

Regards,
Ramesh

-Original Message-
From: amd-gfx  On Behalf Of Chen, 
Xiaogang
Sent: Saturday, January 14, 2023 4:28 AM
To: Kuehling, Felix ; amd-gfx@lists.freedesktop.org; 
dri-de...@lists.freedesktop.org
Cc: Koenig, Christian 
Subject: Re: [PATCH 6/6] drm/amdgpu: Do bo_va ref counting for KFD BOs

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


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);
Ramesh: Could this stmt to reserve space for fence be applied in patch 4.

> + 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 4/6] drm/amdgpu: Attach eviction fence on alloc

2023-01-16 Thread Errabolu, Ramesh
[AMD Official Use Only - General]

Comment inline.

Regards,
Ramesh

-Original Message-
From: amd-gfx  On Behalf Of Felix 
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Chen, Xiaogang ; Koenig, Christian 

Subject: [PATCH 4/6] drm/amdgpu: Attach eviction fence on alloc

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


Instead of attaching the eviction fence when a KFD BO is first mapped, attach 
it when it is allocated or imported. This in preparation to allow KFD BOs to be 
mapped using the render node API.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 5645103beed0..79213f476493 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -360,6 +360,24 @@ static int amdgpu_amdkfd_bo_validate(struct amdgpu_bo *bo, 
uint32_t domain,
return ret;
 }

+static int amdgpu_amdkfd_bo_validate_and_fence(struct amdgpu_bo *bo,
+  uint32_t domain,
+  struct dma_fence *fence) 
+{
+   int ret = amdgpu_bo_reserve(bo, false);
+
+   if (ret)
+   return ret;
+
+   ret = amdgpu_amdkfd_bo_validate(bo, domain, true);
+   if (!ret)
Ramesh: Should space for fences be reserved before adding one.

+   dma_resv_add_fence(bo->tbo.base.resv, fence,
+  DMA_RESV_USAGE_BOOKKEEP);
+   amdgpu_bo_unreserve(bo);
+
+   return ret;
+}
+
 static int amdgpu_amdkfd_validate_vm_bo(void *_unused, struct amdgpu_bo *bo)  {
return amdgpu_amdkfd_bo_validate(bo, bo->allowed_domains, false); @@ 
-1720,6 +1738,11 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
}
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
+   } else {
+   ret = amdgpu_amdkfd_bo_validate_and_fence(bo, domain,
+   >process_info->eviction_fence->base);
+   if (ret)
+   goto err_validate_bo;
}

if (offset)
@@ -1729,6 +1752,7 @@ int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(

 allocate_init_user_pages_failed:
 err_pin_bo:
+err_validate_bo:
remove_kgd_mem_from_kfd_bo_list(*mem, avm->process_info);
drm_vma_node_revoke(>vma_node, drm_priv);
 err_node_allow:
@@ -1804,10 +1828,6 @@ int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
if (unlikely(ret))
return ret;

-   /* The eviction fence should be removed by the last unmap.
-* TODO: Log an error condition if the bo still has the eviction fence
-* attached
-*/
amdgpu_amdkfd_remove_eviction_fence(mem->bo,
process_info->eviction_fence);
Ramesh: Is it correct to call remove_eviction() unconditionally? This procedure 
applies to GTT and VRAM BO's only. Furthermore, the fence on these BO's has 
already been removed in the unmap_memory() call.

pr_debug("Release VA 0x%llx - 0x%llx\n", mem->va, @@ -1931,19 +1951,6 
@@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
if (unlikely(ret))
goto out_unreserve;

-   if (mem->mapped_to_gpu_memory == 0 &&
-   !amdgpu_ttm_tt_get_usermm(bo->tbo.ttm)) {
-   /* Validate BO only once. The eviction fence gets added to BO
-* the first time it is mapped. Validate will wait for all
-* background evictions to complete.
-*/
-   ret = amdgpu_amdkfd_bo_validate(bo, domain, true);
-   if (ret) {
-   pr_debug("Validate failed\n");
-   goto out_unreserve;
-   }
-   }
-
list_for_each_entry(entry, >attachments, list) {
if (entry->bo_va->base.vm != avm || entry->is_mapped)
continue;
@@ -1970,10 +1977,6 @@ int amdgpu_amdkfd_gpuvm_map_memory_to_gpu(
 mem->mapped_to_gpu_memory);
}

-   if (!amdgpu_ttm_tt_get_usermm(bo->tbo.ttm) && !bo->tbo.pin_count)
-   dma_resv_add_fence(bo->tbo.base.resv,
-  >process_info->eviction_fence->base,
-  DMA_RESV_USAGE_BOOKKEEP);
ret = unreserve_bo_and_vms(, false, false);

goto out;
@@ -1990,7 +1993,6 @@ int amdgpu_amdkfd_gpuvm_unmap_memory_from_gpu(
struct amdgpu_device *adev, struct kgd_mem *mem, void 
*drm_priv)  {
struct amdgpu_vm *avm = drm_priv_to_vm(drm_priv);
-   struct amdkfd_process_info 

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

2023-01-16 Thread Errabolu, Ramesh
[AMD Official Use Only - General]

A minor comment, unrelated to the patch. The comments are inline.

Regards,
Ramesh

-Original Message-
From: amd-gfx  On Behalf Of Felix 
Kuehling
Sent: Thursday, January 12, 2023 7:02 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Chen, Xiaogang ; Koenig, Christian 

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

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.


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); @@ -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;
Ramesh: Is it correct to assign WRITE & EXECUTABLE permissions to alloc_flags 
variable.

-   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
--
2.34.1


RE: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Limonciello, Mario
[Public]



> -Original Message-
> From: Alex Deucher 
> Sent: Monday, January 16, 2023 15:54
> To: Limonciello, Mario 
> Cc: Guilherme G. Piccoli ; amd-
> g...@lists.freedesktop.org; Jiang, Sonny ;
> ker...@gpiccoli.net; Pan, Xinhui ; dri-
> de...@lists.freedesktop.org; Lazar, Lijo ; kernel-
> d...@igalia.com; Deucher, Alexander ; Zhu,
> James ; Liu, Leo ; Koenig,
> Christian 
> Subject: Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM
> checking code
> 
> On Mon, Jan 16, 2023 at 4:49 PM Limonciello, Mario
>  wrote:
> >
> > [Public]
> >
> >
> >
> > > -Original Message-
> > > From: Alex Deucher 
> > > Sent: Monday, January 16, 2023 15:42
> > > To: Guilherme G. Piccoli 
> > > Cc: amd-gfx@lists.freedesktop.org; Jiang, Sonny
> ;
> > > ker...@gpiccoli.net; Pan, Xinhui ; dri-
> > > de...@lists.freedesktop.org; Lazar, Lijo ;
> Limonciello,
> > > Mario ; kernel-...@igalia.com; Deucher,
> > > Alexander ; Zhu, James
> > > ; Liu, Leo ; Koenig, Christian
> > > 
> > > Subject: Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM
> > > checking code
> > >
> > > On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
> > >  wrote:
> > > >
> > > > Currently both conditionals checked to enable indirect SRAM are
> > > > repeated for all HW/IP models. Let's just simplify it a bit so
> > > > code is more compact and readable.
> > > >
> > > > While at it, add the legacy names as a comment per case block, to
> > > > help whoever is reading the code and doesn't have much experience
> > > > with the name/number mapping.
> > > >
> > > > Cc: James Zhu 
> > > > Cc: Lazar Lijo 
> > > > Cc: Leo Liu 
> > > > Cc: Mario Limonciello 
> > > > Cc: Sonny Jiang 
> > > > Signed-off-by: Guilherme G. Piccoli 
> > > > ---
> > > >
> > > >
> > > > Hi folks, first of all thanks in advance for reviews/comments!
> > > >
> > > > This work is based on agd5f/amd-staging-drm-next branch - there is this
> > > > patch from Mario that refactored the amdgpu_vcn.c, and since it
> dropped
> > > > the legacy names from the switch cases, I've decided to also include
> them
> > > > here as comments.
> > > >
> > > > I'm not sure if that's a good idea, feels good for somebody not so
> > > > used to the code read the codenames instead of purely numbers, but
> > > > if you wanna move away from the legacy names for good, lemme know
> > > > and I can rework without these comments.
> > > >
> > > > Cheers,
> > > >
> > > >
> > > > Guilherme
> > > >
> > > >
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 84 +---
> -
> > > >  1 file changed, 16 insertions(+), 68 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > > > index 1b1a3c9e1863..1f880e162d9d 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > > > @@ -111,78 +111,26 @@ int amdgpu_vcn_sw_init(struct
> amdgpu_device
> > > *adev)
> > > > atomic_set(>vcn.inst[i].dpg_enc_submission_cnt, 
> > > > 0);
> > > >
> > > > switch (adev->ip_versions[UVD_HWIP][0]) {
> > > > -   case IP_VERSION(1, 0, 0):
> > > > -   case IP_VERSION(1, 0, 1):
> > > > -   case IP_VERSION(2, 5, 0):
> > > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)
> &&
> > > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > > -   adev->vcn.indirect_sram = true;
> > > > -   break;
> > > > -   case IP_VERSION(2, 2, 0):
> > > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)
> &&
> > > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > > -   adev->vcn.indirect_sram = true;
> > > > -   break;
> > > > -   case IP_VERSION(2, 6, 0):
> > > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)
> &&
> > > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > > -   adev->vcn.indirect_sram = true;
> > > > -   break;
> > > > -   case IP_VERSION(2, 0, 0):
> > > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)
> &&
> > > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > > -   adev->vcn.indirect_sram = true;
> > > > -   break;
> > > > -   case IP_VERSION(2, 0, 2):
> > > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)
> &&
> > > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > > -   adev->vcn.indirect_sram = true;
> > > > -   break;
> > > > -   case IP_VERSION(3, 0, 0):
> > > > -   case IP_VERSION(3, 0, 64):
> > > > -   case IP_VERSION(3, 0, 192):
> > > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP)
> &&
> > > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > > -   adev->vcn.indirect_sram = true;
> 

Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Guilherme G. Piccoli
On 16/01/2023 18:41, Alex Deucher wrote:
> [...]
>> +   case IP_VERSION(4, 0, 0):   /* Vega10 */
> 
> This comment is incorrect.  Vega10 does not have VCN (it has UVD and VCE).
> 
> Alex

Thanks Alex! I'll resubmit V2 with this comment removed.

I've stolen it from
https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c#L1147
, but obviously I misunderstood the mapping here heheh

Cheers,


Guilherme


Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Guilherme G. Piccoli
On 16/01/2023 18:49, Limonciello, Mario wrote:
> [...] 
> 
> The problem with adding a comment about which platform it's in is that
> this will probably go stale.  Some IP blocks are re-used in multiple ASICs.
> 
> VCN 3, 1, 1 is a great example.  This is used in both Yellow Carp (Rembrandt) 
> as well
> as Mendocino.   I would think a better approach would be to have a single 
> point
> of documentation somewhere in the source tree that we can update after new
> ASICs launch that could act as a decoder ring.
> 
> It's effort to remember to update it, but it's at least a single point of 
> failure.
> 

Hi Mario, thanks - it makes a lot of sense! I can remove the comments in
the V2, I'll wait a bit more for (potential) extra feedback but I agree
with you, so I'm inclined to remove them.

Cheers,


Guilherme


Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 4:51 PM Guilherme G. Piccoli
 wrote:
>
> On 16/01/2023 18:41, Alex Deucher wrote:
> > [...]
> >> +   case IP_VERSION(4, 0, 0):   /* Vega10 */
> >
> > This comment is incorrect.  Vega10 does not have VCN (it has UVD and VCE).
> >
> > Alex
>
> Thanks Alex! I'll resubmit V2 with this comment removed.
>
> I've stolen it from
> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c#L1147

That is for a different IP (SDMA).

Alex

> , but obviously I misunderstood the mapping here heheh
>
> Cheers,
>
>
> Guilherme


Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 4:49 PM Limonciello, Mario
 wrote:
>
> [Public]
>
>
>
> > -Original Message-
> > From: Alex Deucher 
> > Sent: Monday, January 16, 2023 15:42
> > To: Guilherme G. Piccoli 
> > Cc: amd-gfx@lists.freedesktop.org; Jiang, Sonny ;
> > ker...@gpiccoli.net; Pan, Xinhui ; dri-
> > de...@lists.freedesktop.org; Lazar, Lijo ; Limonciello,
> > Mario ; kernel-...@igalia.com; Deucher,
> > Alexander ; Zhu, James
> > ; Liu, Leo ; Koenig, Christian
> > 
> > Subject: Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM
> > checking code
> >
> > On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
> >  wrote:
> > >
> > > Currently both conditionals checked to enable indirect SRAM are
> > > repeated for all HW/IP models. Let's just simplify it a bit so
> > > code is more compact and readable.
> > >
> > > While at it, add the legacy names as a comment per case block, to
> > > help whoever is reading the code and doesn't have much experience
> > > with the name/number mapping.
> > >
> > > Cc: James Zhu 
> > > Cc: Lazar Lijo 
> > > Cc: Leo Liu 
> > > Cc: Mario Limonciello 
> > > Cc: Sonny Jiang 
> > > Signed-off-by: Guilherme G. Piccoli 
> > > ---
> > >
> > >
> > > Hi folks, first of all thanks in advance for reviews/comments!
> > >
> > > This work is based on agd5f/amd-staging-drm-next branch - there is this
> > > patch from Mario that refactored the amdgpu_vcn.c, and since it dropped
> > > the legacy names from the switch cases, I've decided to also include them
> > > here as comments.
> > >
> > > I'm not sure if that's a good idea, feels good for somebody not so
> > > used to the code read the codenames instead of purely numbers, but
> > > if you wanna move away from the legacy names for good, lemme know
> > > and I can rework without these comments.
> > >
> > > Cheers,
> > >
> > >
> > > Guilherme
> > >
> > >
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 84 +
> > >  1 file changed, 16 insertions(+), 68 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > > index 1b1a3c9e1863..1f880e162d9d 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > > @@ -111,78 +111,26 @@ int amdgpu_vcn_sw_init(struct amdgpu_device
> > *adev)
> > > atomic_set(>vcn.inst[i].dpg_enc_submission_cnt, 0);
> > >
> > > switch (adev->ip_versions[UVD_HWIP][0]) {
> > > -   case IP_VERSION(1, 0, 0):
> > > -   case IP_VERSION(1, 0, 1):
> > > -   case IP_VERSION(2, 5, 0):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(2, 2, 0):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(2, 6, 0):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(2, 0, 0):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(2, 0, 2):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(3, 0, 0):
> > > -   case IP_VERSION(3, 0, 64):
> > > -   case IP_VERSION(3, 0, 192):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(3, 0, 2):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(3, 0, 16):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > > -   adev->vcn.indirect_sram = true;
> > > -   break;
> > > -   case IP_VERSION(3, 0, 33):
> > > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > > -

Re: [PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 4:21 PM Guilherme G. Piccoli
 wrote:
>
> Currently the FW loading path perform some checks based on IP model
> and in case it is advertised as supported, the VCN indirect SRAM
> mode is used.
>
> Happens that in case there's any issue on FW and this mode ends-up
> not being properly supported, the driver probe fails [0]. Debugging
> this requires driver rebuilding, so to allow fast debug and experiments,
> add a parameter to force setting indirect SRAM mode to true/false from
> the kernel command-line; parameter default is -1, which doesn't change
> the current driver's behavior.

Probably a question for Leo or James, but I was under the impression
non-indirect mode didn't work on production silicon for most chips,
but maybe I'm mis-remembering that.

Alex


>
> [0] Example of this issue, observed on Steam Deck:
>
> [drm] kiq ring mec 2 pipe 1 q 0
> [drm] failed to load ucode VCN0_RAM(0x3A)
> [drm] psp gfx command LOAD_IP_FW(0x6) failed and response status is 
> (0x)
> amdgpu :04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring 
> vcn_dec_0 test failed (-110)
> [drm:amdgpu_device_init.cold [amdgpu]] *ERROR* hw_init of IP block  
> failed -110
> amdgpu :04:00.0: amdgpu: amdgpu_device_ip_init failed
> amdgpu :04:00.0: amdgpu: Fatal error during GPU init
>
> Cc: James Zhu 
> Cc: Lazar Lijo 
> Cc: Leo Liu 
> Cc: Mario Limonciello 
> Cc: Sonny Jiang 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>
>
> This work is based on agd5f/amd-staging-drm-next branch.
> Thanks in advance for reviews/comments!
> Cheers,
>
> Guilherme
>
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++
>  3 files changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 872450a3a164..5d3c92c94f18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -215,6 +215,7 @@ extern int amdgpu_noretry;
>  extern int amdgpu_force_asic_type;
>  extern int amdgpu_smartshift_bias;
>  extern int amdgpu_use_xgmi_p2p;
> +extern int amdgpu_indirect_sram;
>  #ifdef CONFIG_HSA_AMD
>  extern int sched_policy;
>  extern bool debug_evictions;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 06aba201d4db..c7182c0bc841 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -187,6 +187,7 @@ int amdgpu_num_kcq = -1;
>  int amdgpu_smartshift_bias;
>  int amdgpu_use_xgmi_p2p = 1;
>  int amdgpu_vcnfw_log;
> +int amdgpu_indirect_sram = -1;
>
>  static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
>
> @@ -941,6 +942,14 @@ MODULE_PARM_DESC(smu_pptable_id,
> "specify pptable id to be used (-1 = auto(default) value, 0 = use 
> pptable from vbios, > 0 = soft pptable id)");
>  module_param_named(smu_pptable_id, amdgpu_smu_pptable_id, int, 0444);
>
> +/**
> + * DOC: indirect_sram (int)
> + * Allow users to force using (or not) the VCN indirect SRAM mode in the fw 
> load
> + * code. Default is -1, meaning auto (aka, don't mess with driver's 
> behavior).
> + */
> +MODULE_PARM_DESC(indirect_sram, "Force VCN indirect SRAM (-1 = auto 
> (default), 0 = disabled, 1 = enabled)");
> +module_param_named(indirect_sram, amdgpu_indirect_sram, int, 0444);
> +
>  /* These devices are not supported by amdgpu.
>   * They are supported by the mach64, r128, radeon drivers
>   */
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index 1f880e162d9d..a2290087e01c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -137,6 +137,9 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
> return -EINVAL;
> }
>
> +   if (amdgpu_indirect_sram >= 0)
> +   adev->vcn.indirect_sram = (bool)amdgpu_indirect_sram;
> +
> hdr = (const struct common_firmware_header *)adev->vcn.fw->data;
> adev->vcn.fw_version = le32_to_cpu(hdr->ucode_version);
>
> --
> 2.39.0
>


RE: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Limonciello, Mario
[Public]



> -Original Message-
> From: Alex Deucher 
> Sent: Monday, January 16, 2023 15:42
> To: Guilherme G. Piccoli 
> Cc: amd-gfx@lists.freedesktop.org; Jiang, Sonny ;
> ker...@gpiccoli.net; Pan, Xinhui ; dri-
> de...@lists.freedesktop.org; Lazar, Lijo ; Limonciello,
> Mario ; kernel-...@igalia.com; Deucher,
> Alexander ; Zhu, James
> ; Liu, Leo ; Koenig, Christian
> 
> Subject: Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM
> checking code
> 
> On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
>  wrote:
> >
> > Currently both conditionals checked to enable indirect SRAM are
> > repeated for all HW/IP models. Let's just simplify it a bit so
> > code is more compact and readable.
> >
> > While at it, add the legacy names as a comment per case block, to
> > help whoever is reading the code and doesn't have much experience
> > with the name/number mapping.
> >
> > Cc: James Zhu 
> > Cc: Lazar Lijo 
> > Cc: Leo Liu 
> > Cc: Mario Limonciello 
> > Cc: Sonny Jiang 
> > Signed-off-by: Guilherme G. Piccoli 
> > ---
> >
> >
> > Hi folks, first of all thanks in advance for reviews/comments!
> >
> > This work is based on agd5f/amd-staging-drm-next branch - there is this
> > patch from Mario that refactored the amdgpu_vcn.c, and since it dropped
> > the legacy names from the switch cases, I've decided to also include them
> > here as comments.
> >
> > I'm not sure if that's a good idea, feels good for somebody not so
> > used to the code read the codenames instead of purely numbers, but
> > if you wanna move away from the legacy names for good, lemme know
> > and I can rework without these comments.
> >
> > Cheers,
> >
> >
> > Guilherme
> >
> >
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 84 +
> >  1 file changed, 16 insertions(+), 68 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > index 1b1a3c9e1863..1f880e162d9d 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> > @@ -111,78 +111,26 @@ int amdgpu_vcn_sw_init(struct amdgpu_device
> *adev)
> > atomic_set(>vcn.inst[i].dpg_enc_submission_cnt, 0);
> >
> > switch (adev->ip_versions[UVD_HWIP][0]) {
> > -   case IP_VERSION(1, 0, 0):
> > -   case IP_VERSION(1, 0, 1):
> > -   case IP_VERSION(2, 5, 0):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(2, 2, 0):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(2, 6, 0):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(2, 0, 0):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(2, 0, 2):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(3, 0, 0):
> > -   case IP_VERSION(3, 0, 64):
> > -   case IP_VERSION(3, 0, 192):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(3, 0, 2):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(3, 0, 16):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(3, 0, 33):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> > -   adev->vcn.indirect_sram = true;
> > -   break;
> > -   case IP_VERSION(3, 1, 1):
> > -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> > -   

Re: [PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
 wrote:
>
> Currently both conditionals checked to enable indirect SRAM are
> repeated for all HW/IP models. Let's just simplify it a bit so
> code is more compact and readable.
>
> While at it, add the legacy names as a comment per case block, to
> help whoever is reading the code and doesn't have much experience
> with the name/number mapping.
>
> Cc: James Zhu 
> Cc: Lazar Lijo 
> Cc: Leo Liu 
> Cc: Mario Limonciello 
> Cc: Sonny Jiang 
> Signed-off-by: Guilherme G. Piccoli 
> ---
>
>
> Hi folks, first of all thanks in advance for reviews/comments!
>
> This work is based on agd5f/amd-staging-drm-next branch - there is this
> patch from Mario that refactored the amdgpu_vcn.c, and since it dropped
> the legacy names from the switch cases, I've decided to also include them
> here as comments.
>
> I'm not sure if that's a good idea, feels good for somebody not so
> used to the code read the codenames instead of purely numbers, but
> if you wanna move away from the legacy names for good, lemme know
> and I can rework without these comments.
>
> Cheers,
>
>
> Guilherme
>
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 84 +
>  1 file changed, 16 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index 1b1a3c9e1863..1f880e162d9d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -111,78 +111,26 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
> atomic_set(>vcn.inst[i].dpg_enc_submission_cnt, 0);
>
> switch (adev->ip_versions[UVD_HWIP][0]) {
> -   case IP_VERSION(1, 0, 0):
> -   case IP_VERSION(1, 0, 1):
> -   case IP_VERSION(2, 5, 0):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(2, 2, 0):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(2, 6, 0):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(2, 0, 0):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(2, 0, 2):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(3, 0, 0):
> -   case IP_VERSION(3, 0, 64):
> -   case IP_VERSION(3, 0, 192):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(3, 0, 2):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(3, 0, 16):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(3, 0, 33):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> -   case IP_VERSION(3, 1, 1):
> -   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
> -   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
> -   adev->vcn.indirect_sram = true;
> -   break;
> +   case IP_VERSION(1, 0, 0):   /* Raven (1/2) / Picasso */
> +   case IP_VERSION(1, 0, 1):   /* Raven (1/2) / Picasso */
> +   case IP_VERSION(2, 0, 0):   /* Navi10 */
> +   case IP_VERSION(2, 0, 2):   /* Navi12 / Navi14 */
> +   case IP_VERSION(2, 2, 0):   /* Renoir / Green Sardine */
> +   case IP_VERSION(2, 5, 0):   /* Arcturus */
> +   case IP_VERSION(2, 6, 0):   /* Aldebaran */
> +   case IP_VERSION(3, 0, 0):   /* Sienna Cichlid / Navy Flounder */
> +   case IP_VERSION(3, 0, 2): 

Re: [PATCH 1/3] drm/amdgpu/vcn: Adjust firmware names indentation

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 4:20 PM Guilherme G. Piccoli
 wrote:
>
> This is an incredibly trivial fix, just for the sake of
> "aesthetical" organization of the defines. Some were space based,
> most were tab based and there was a lack of "alignment", now it's
> all the same and aligned.
>
> Cc: James Zhu 
> Cc: Lazar Lijo 
> Cc: Leo Liu 
> Cc: Mario Limonciello 
> Cc: Sonny Jiang 
> Signed-off-by: Guilherme G. Piccoli 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 38 -
>  1 file changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index f8397d993f23..1b1a3c9e1863 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -36,26 +36,26 @@
>  #include "soc15d.h"
>
>  /* Firmware Names */
> -#define FIRMWARE_RAVEN "amdgpu/raven_vcn.bin"
> -#define FIRMWARE_PICASSO   "amdgpu/picasso_vcn.bin"
> -#define FIRMWARE_RAVEN2"amdgpu/raven2_vcn.bin"
> -#define FIRMWARE_ARCTURUS  "amdgpu/arcturus_vcn.bin"
> -#define FIRMWARE_RENOIR"amdgpu/renoir_vcn.bin"
> -#define FIRMWARE_GREEN_SARDINE "amdgpu/green_sardine_vcn.bin"
> -#define FIRMWARE_NAVI10"amdgpu/navi10_vcn.bin"
> -#define FIRMWARE_NAVI14"amdgpu/navi14_vcn.bin"
> -#define FIRMWARE_NAVI12"amdgpu/navi12_vcn.bin"
> -#define FIRMWARE_SIENNA_CICHLID"amdgpu/sienna_cichlid_vcn.bin"
> -#define FIRMWARE_NAVY_FLOUNDER "amdgpu/navy_flounder_vcn.bin"
> -#define FIRMWARE_VANGOGH   "amdgpu/vangogh_vcn.bin"
> +#define FIRMWARE_RAVEN "amdgpu/raven_vcn.bin"
> +#define FIRMWARE_PICASSO   "amdgpu/picasso_vcn.bin"
> +#define FIRMWARE_RAVEN2"amdgpu/raven2_vcn.bin"
> +#define FIRMWARE_ARCTURUS  "amdgpu/arcturus_vcn.bin"
> +#define FIRMWARE_RENOIR"amdgpu/renoir_vcn.bin"
> +#define FIRMWARE_GREEN_SARDINE "amdgpu/green_sardine_vcn.bin"
> +#define FIRMWARE_NAVI10"amdgpu/navi10_vcn.bin"
> +#define FIRMWARE_NAVI14"amdgpu/navi14_vcn.bin"
> +#define FIRMWARE_NAVI12"amdgpu/navi12_vcn.bin"
> +#define FIRMWARE_SIENNA_CICHLID
> "amdgpu/sienna_cichlid_vcn.bin"
> +#define FIRMWARE_NAVY_FLOUNDER "amdgpu/navy_flounder_vcn.bin"
> +#define FIRMWARE_VANGOGH   "amdgpu/vangogh_vcn.bin"
>  #define FIRMWARE_DIMGREY_CAVEFISH  "amdgpu/dimgrey_cavefish_vcn.bin"
> -#define FIRMWARE_ALDEBARAN "amdgpu/aldebaran_vcn.bin"
> -#define FIRMWARE_BEIGE_GOBY"amdgpu/beige_goby_vcn.bin"
> -#define FIRMWARE_YELLOW_CARP   "amdgpu/yellow_carp_vcn.bin"
> -#define FIRMWARE_VCN_3_1_2 "amdgpu/vcn_3_1_2.bin"
> -#define FIRMWARE_VCN4_0_0  "amdgpu/vcn_4_0_0.bin"
> -#define FIRMWARE_VCN4_0_2  "amdgpu/vcn_4_0_2.bin"
> -#define FIRMWARE_VCN4_0_4  "amdgpu/vcn_4_0_4.bin"
> +#define FIRMWARE_ALDEBARAN "amdgpu/aldebaran_vcn.bin"
> +#define FIRMWARE_BEIGE_GOBY"amdgpu/beige_goby_vcn.bin"
> +#define FIRMWARE_YELLOW_CARP   "amdgpu/yellow_carp_vcn.bin"
> +#define FIRMWARE_VCN_3_1_2 "amdgpu/vcn_3_1_2.bin"
> +#define FIRMWARE_VCN4_0_0  "amdgpu/vcn_4_0_0.bin"
> +#define FIRMWARE_VCN4_0_2  "amdgpu/vcn_4_0_2.bin"
> +#define FIRMWARE_VCN4_0_4  "amdgpu/vcn_4_0_4.bin"
>
>  MODULE_FIRMWARE(FIRMWARE_RAVEN);
>  MODULE_FIRMWARE(FIRMWARE_PICASSO);
> --
> 2.39.0
>


[PATCH 2/3] drm/amdgpu/vcn: Deduplicate indirect SRAM checking code

2023-01-16 Thread Guilherme G. Piccoli
Currently both conditionals checked to enable indirect SRAM are
repeated for all HW/IP models. Let's just simplify it a bit so
code is more compact and readable.

While at it, add the legacy names as a comment per case block, to
help whoever is reading the code and doesn't have much experience
with the name/number mapping.

Cc: James Zhu 
Cc: Lazar Lijo 
Cc: Leo Liu 
Cc: Mario Limonciello 
Cc: Sonny Jiang 
Signed-off-by: Guilherme G. Piccoli 
---


Hi folks, first of all thanks in advance for reviews/comments!

This work is based on agd5f/amd-staging-drm-next branch - there is this
patch from Mario that refactored the amdgpu_vcn.c, and since it dropped
the legacy names from the switch cases, I've decided to also include them
here as comments.

I'm not sure if that's a good idea, feels good for somebody not so
used to the code read the codenames instead of purely numbers, but
if you wanna move away from the legacy names for good, lemme know
and I can rework without these comments.

Cheers,


Guilherme


 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 84 +
 1 file changed, 16 insertions(+), 68 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 1b1a3c9e1863..1f880e162d9d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -111,78 +111,26 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
atomic_set(>vcn.inst[i].dpg_enc_submission_cnt, 0);
 
switch (adev->ip_versions[UVD_HWIP][0]) {
-   case IP_VERSION(1, 0, 0):
-   case IP_VERSION(1, 0, 1):
-   case IP_VERSION(2, 5, 0):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(2, 2, 0):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(2, 6, 0):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(2, 0, 0):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(2, 0, 2):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(3, 0, 0):
-   case IP_VERSION(3, 0, 64):
-   case IP_VERSION(3, 0, 192):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(3, 0, 2):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(3, 0, 16):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(3, 0, 33):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
-   case IP_VERSION(3, 1, 1):
-   if ((adev->firmware.load_type == AMDGPU_FW_LOAD_PSP) &&
-   (adev->pg_flags & AMD_PG_SUPPORT_VCN_DPG))
-   adev->vcn.indirect_sram = true;
-   break;
+   case IP_VERSION(1, 0, 0):   /* Raven (1/2) / Picasso */
+   case IP_VERSION(1, 0, 1):   /* Raven (1/2) / Picasso */
+   case IP_VERSION(2, 0, 0):   /* Navi10 */
+   case IP_VERSION(2, 0, 2):   /* Navi12 / Navi14 */
+   case IP_VERSION(2, 2, 0):   /* Renoir / Green Sardine */
+   case IP_VERSION(2, 5, 0):   /* Arcturus */
+   case IP_VERSION(2, 6, 0):   /* Aldebaran */
+   case IP_VERSION(3, 0, 0):   /* Sienna Cichlid / Navy Flounder */
+   case IP_VERSION(3, 0, 2):   /* Vangogh */
+   case IP_VERSION(3, 0, 64):  /* Sienna Cichlid / Navy Flounder */
+   case IP_VERSION(3, 0, 16):  /* Dimgray Cavefish */
+   case IP_VERSION(3, 0, 33):  /* Beige Goby */
+   case IP_VERSION(3, 0, 192): /* Sienna 

[PATCH 1/3] drm/amdgpu/vcn: Adjust firmware names indentation

2023-01-16 Thread Guilherme G. Piccoli
This is an incredibly trivial fix, just for the sake of
"aesthetical" organization of the defines. Some were space based,
most were tab based and there was a lack of "alignment", now it's
all the same and aligned.

Cc: James Zhu 
Cc: Lazar Lijo 
Cc: Leo Liu 
Cc: Mario Limonciello 
Cc: Sonny Jiang 
Signed-off-by: Guilherme G. Piccoli 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 38 -
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index f8397d993f23..1b1a3c9e1863 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -36,26 +36,26 @@
 #include "soc15d.h"
 
 /* Firmware Names */
-#define FIRMWARE_RAVEN "amdgpu/raven_vcn.bin"
-#define FIRMWARE_PICASSO   "amdgpu/picasso_vcn.bin"
-#define FIRMWARE_RAVEN2"amdgpu/raven2_vcn.bin"
-#define FIRMWARE_ARCTURUS  "amdgpu/arcturus_vcn.bin"
-#define FIRMWARE_RENOIR"amdgpu/renoir_vcn.bin"
-#define FIRMWARE_GREEN_SARDINE "amdgpu/green_sardine_vcn.bin"
-#define FIRMWARE_NAVI10"amdgpu/navi10_vcn.bin"
-#define FIRMWARE_NAVI14"amdgpu/navi14_vcn.bin"
-#define FIRMWARE_NAVI12"amdgpu/navi12_vcn.bin"
-#define FIRMWARE_SIENNA_CICHLID"amdgpu/sienna_cichlid_vcn.bin"
-#define FIRMWARE_NAVY_FLOUNDER "amdgpu/navy_flounder_vcn.bin"
-#define FIRMWARE_VANGOGH   "amdgpu/vangogh_vcn.bin"
+#define FIRMWARE_RAVEN "amdgpu/raven_vcn.bin"
+#define FIRMWARE_PICASSO   "amdgpu/picasso_vcn.bin"
+#define FIRMWARE_RAVEN2"amdgpu/raven2_vcn.bin"
+#define FIRMWARE_ARCTURUS  "amdgpu/arcturus_vcn.bin"
+#define FIRMWARE_RENOIR"amdgpu/renoir_vcn.bin"
+#define FIRMWARE_GREEN_SARDINE "amdgpu/green_sardine_vcn.bin"
+#define FIRMWARE_NAVI10"amdgpu/navi10_vcn.bin"
+#define FIRMWARE_NAVI14"amdgpu/navi14_vcn.bin"
+#define FIRMWARE_NAVI12"amdgpu/navi12_vcn.bin"
+#define FIRMWARE_SIENNA_CICHLID"amdgpu/sienna_cichlid_vcn.bin"
+#define FIRMWARE_NAVY_FLOUNDER "amdgpu/navy_flounder_vcn.bin"
+#define FIRMWARE_VANGOGH   "amdgpu/vangogh_vcn.bin"
 #define FIRMWARE_DIMGREY_CAVEFISH  "amdgpu/dimgrey_cavefish_vcn.bin"
-#define FIRMWARE_ALDEBARAN "amdgpu/aldebaran_vcn.bin"
-#define FIRMWARE_BEIGE_GOBY"amdgpu/beige_goby_vcn.bin"
-#define FIRMWARE_YELLOW_CARP   "amdgpu/yellow_carp_vcn.bin"
-#define FIRMWARE_VCN_3_1_2 "amdgpu/vcn_3_1_2.bin"
-#define FIRMWARE_VCN4_0_0  "amdgpu/vcn_4_0_0.bin"
-#define FIRMWARE_VCN4_0_2  "amdgpu/vcn_4_0_2.bin"
-#define FIRMWARE_VCN4_0_4  "amdgpu/vcn_4_0_4.bin"
+#define FIRMWARE_ALDEBARAN "amdgpu/aldebaran_vcn.bin"
+#define FIRMWARE_BEIGE_GOBY"amdgpu/beige_goby_vcn.bin"
+#define FIRMWARE_YELLOW_CARP   "amdgpu/yellow_carp_vcn.bin"
+#define FIRMWARE_VCN_3_1_2 "amdgpu/vcn_3_1_2.bin"
+#define FIRMWARE_VCN4_0_0  "amdgpu/vcn_4_0_0.bin"
+#define FIRMWARE_VCN4_0_2  "amdgpu/vcn_4_0_2.bin"
+#define FIRMWARE_VCN4_0_4  "amdgpu/vcn_4_0_4.bin"
 
 MODULE_FIRMWARE(FIRMWARE_RAVEN);
 MODULE_FIRMWARE(FIRMWARE_PICASSO);
-- 
2.39.0



[PATCH 3/3] drm/amdgpu/vcn: Add parameter to force (en/dis)abling indirect SRAM mode

2023-01-16 Thread Guilherme G. Piccoli
Currently the FW loading path perform some checks based on IP model
and in case it is advertised as supported, the VCN indirect SRAM
mode is used.

Happens that in case there's any issue on FW and this mode ends-up
not being properly supported, the driver probe fails [0]. Debugging
this requires driver rebuilding, so to allow fast debug and experiments,
add a parameter to force setting indirect SRAM mode to true/false from
the kernel command-line; parameter default is -1, which doesn't change
the current driver's behavior.

[0] Example of this issue, observed on Steam Deck:

[drm] kiq ring mec 2 pipe 1 q 0
[drm] failed to load ucode VCN0_RAM(0x3A)
[drm] psp gfx command LOAD_IP_FW(0x6) failed and response status is (0x)
amdgpu :04:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring 
vcn_dec_0 test failed (-110)
[drm:amdgpu_device_init.cold [amdgpu]] *ERROR* hw_init of IP block  
failed -110
amdgpu :04:00.0: amdgpu: amdgpu_device_ip_init failed
amdgpu :04:00.0: amdgpu: Fatal error during GPU init

Cc: James Zhu 
Cc: Lazar Lijo 
Cc: Leo Liu 
Cc: Mario Limonciello 
Cc: Sonny Jiang 
Signed-off-by: Guilherme G. Piccoli 
---


This work is based on agd5f/amd-staging-drm-next branch.
Thanks in advance for reviews/comments!
Cheers,

Guilherme


 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 3 +++
 3 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 872450a3a164..5d3c92c94f18 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -215,6 +215,7 @@ extern int amdgpu_noretry;
 extern int amdgpu_force_asic_type;
 extern int amdgpu_smartshift_bias;
 extern int amdgpu_use_xgmi_p2p;
+extern int amdgpu_indirect_sram;
 #ifdef CONFIG_HSA_AMD
 extern int sched_policy;
 extern bool debug_evictions;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 06aba201d4db..c7182c0bc841 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -187,6 +187,7 @@ int amdgpu_num_kcq = -1;
 int amdgpu_smartshift_bias;
 int amdgpu_use_xgmi_p2p = 1;
 int amdgpu_vcnfw_log;
+int amdgpu_indirect_sram = -1;
 
 static void amdgpu_drv_delayed_reset_work_handler(struct work_struct *work);
 
@@ -941,6 +942,14 @@ MODULE_PARM_DESC(smu_pptable_id,
"specify pptable id to be used (-1 = auto(default) value, 0 = use 
pptable from vbios, > 0 = soft pptable id)");
 module_param_named(smu_pptable_id, amdgpu_smu_pptable_id, int, 0444);
 
+/**
+ * DOC: indirect_sram (int)
+ * Allow users to force using (or not) the VCN indirect SRAM mode in the fw 
load
+ * code. Default is -1, meaning auto (aka, don't mess with driver's behavior).
+ */
+MODULE_PARM_DESC(indirect_sram, "Force VCN indirect SRAM (-1 = auto (default), 
0 = disabled, 1 = enabled)");
+module_param_named(indirect_sram, amdgpu_indirect_sram, int, 0444);
+
 /* These devices are not supported by amdgpu.
  * They are supported by the mach64, r128, radeon drivers
  */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index 1f880e162d9d..a2290087e01c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
@@ -137,6 +137,9 @@ int amdgpu_vcn_sw_init(struct amdgpu_device *adev)
return -EINVAL;
}
 
+   if (amdgpu_indirect_sram >= 0)
+   adev->vcn.indirect_sram = (bool)amdgpu_indirect_sram;
+
hdr = (const struct common_firmware_header *)adev->vcn.fw->data;
adev->vcn.fw_version = le32_to_cpu(hdr->ucode_version);
 
-- 
2.39.0



Re: [PATCH 00/22] drm: Remove includes for drm_crtc_helper.h

2023-01-16 Thread Sam Ravnborg
Hi Thomas.

On Mon, Jan 16, 2023 at 02:12:13PM +0100, Thomas Zimmermann wrote:
> A lot of source files include drm_crtc_helper.h for its contained
> include statements. This leads to excessive compile-time dependencies.
> 
> Where possible, remove the include statements for drm_crtc_helper.h
> and include the required source files directly. Also remove the
> include statements from drm_crtc_helper.h itself, which doesn't need
> most of them.
With this patchset drm_crtc_helper usage is reduced from 85 places to 35
places. And the 35 places is only .c files.
This is a very nice reduction of bloat! I hope this has a measureable
effect on building times.

I was working on something similar, but that approach only added missing
includes, and did not kill all the unnessesary includes - which I think
is the biggest win here.

All patches are:
Reviewed-by: Sam Ravnborg 

For a few of them the r-b is conditional, see the specific comments
posted.


I did a build check here with the archs and config I verifies with.
This covers "alpha arm arm64 sparc64 i386 x86 powerpc s390 riscv sh"
and everything was fine. I have a few specific configs to pull in
drivers that need a bit extra to be built.
So I consider build coverage OK for applying, but it would be nice to
wait a few days for the bots to verify too.

My own work on slimming drm_atomic_helper.h and drm_print.h will be
rebased on top of your work before I continue it.
I need to look into removing unused includes too.

Sam

> 
> I built this patchset on x86-64, aarch64 and arm. Hopefully I found
> all include dependencies.
> 
> Thanks to Sam Ravnborg for bringing this to my attention.
> 
> Thomas Zimmermann (22):
>   drm/amdgpu: Fix coding style
>   drm: Remove unnecessary include statements for drm_crtc_helper.h
>   drm/amdgpu: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/arm/komeda: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/aspeed: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/ast: Remove unnecessary include statements for drm_crtc_helper.h
>   drm/bridge: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/gma500: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/i2c/ch7006: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/ingenic: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/kmb: Remove unnecessary include statements for drm_crtc_helper.h
>   drm/logicvc: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/nouveau: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/radeon: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/rockchip: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/shmobile: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/sprd: Remove unnecessary include statements for drm_crtc_helper.h
>   drm/sun4i: Remove unnecessary include statements for drm_crtc_helper.h
>   drm/tidss: Remove unnecessary include statements for drm_crtc_helper.h
>   drm/udl: Remove unnecessary include statements for drm_crtc_helper.h
>   drm/vboxvideo: Remove unnecessary include statements for
> drm_crtc_helper.h
>   drm/crtc-helper: Remove most include statements from drm_crtc_helper.h
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  5 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c   |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |  1 -
>  drivers/gpu/drm/amd/amdgpu/atombios_crtc.c |  1 -
>  drivers/gpu/drm/amd/amdgpu/atombios_encoders.c |  1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |  2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  2 ++
>  drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   |  1 -
>  drivers/gpu/drm/arm/display/komeda/komeda_kms.h|  1 -
>  drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c   |  1 -
>  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c|  1 -
>  drivers/gpu/drm/aspeed/aspeed_gfx_out.c|  1 -
>  drivers/gpu/drm/ast/ast_drv.c  |  1 -
>  drivers/gpu/drm/ast/ast_main.c |  1 -
>  drivers/gpu/drm/ast/ast_mode.c |  1 -
>  drivers/gpu/drm/bridge/analogix/analogix-anx6345.c |  1 -
>  drivers/gpu/drm/bridge/analogix/anx7625.c  |  1 -
>  .../gpu/drm/bridge/cadence/cdns-mhdp8546-core.c|  1 -
>  drivers/gpu/drm/bridge/ite-it6505.c|  1 -
>  drivers/gpu/drm/bridge/ite-it66121.c   |  1 -
>  drivers/gpu/drm/bridge/tc358768.c  |  1 -
>  

Re: [PATCH 18/22] drm/sun4i: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Sam Ravnborg
On Mon, Jan 16, 2023 at 02:12:31PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
> 
> Directly include required headers and drop drm_crtc_helper.h where
> possible.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
> b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> index 477cb6985b4d..37dc66332bbd 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
> @@ -8,8 +8,8 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
> +#include 

Move one up to maintain sorting.
With that fixed:
Reviewed-by: Sam Ravnborg 

>  #include 
>  
>  #include "sun8i_dw_hdmi.h"
> -- 
> 2.39.0


Re: [PATCH 05/22] drm/aspeed: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Sam Ravnborg
On Mon, Jan 16, 2023 at 02:12:18PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
> 
> Directly include required headers and drop drm_crtc_helper.h where
> possible.

Nitpicking... The above is the standard text you use.
But in many cases, like this case, the patch just drop the wrong use of
the header and do not include any required headers.

If you want to rephrase for future changelog diggers or leave it as is,
is up to you.

Sam

> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 -
>  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c  | 1 -
>  drivers/gpu/drm/aspeed/aspeed_gfx_out.c  | 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c 
> b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> index 55a3444a51d8..7877a57b8e26 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> @@ -5,7 +5,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 
> b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> index 718119e168a6..ecfb060d2557 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> @@ -14,7 +14,6 @@
>  #include 
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c 
> b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
> index 4f2187025a21..78775e0c853f 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
> @@ -3,7 +3,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> -- 
> 2.39.0


Re: [PATCH 1/2] drm/amdgpu: fix amdgpu_job_free_resources v2

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 3:15 PM Alex Deucher  wrote:
>
> On Mon, Jan 16, 2023 at 3:12 PM Christian König
>  wrote:
> >
> > It can be that neither fence were initialized when we run out of UVD
> > streams for example.
> >
> > v2: fix typo breaking compile
> >
> > Signed-off-by: Christian König 
>
> Reviewed-by: Alex Deucher 

Also add:
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2324

Alex

>
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > index f4a3122352de..6b73c074aa25 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > @@ -154,8 +154,14 @@ void amdgpu_job_free_resources(struct amdgpu_job *job)
> > struct dma_fence *f;
> > unsigned i;
> >
> > -   /* use sched fence if available */
> > -   f = job->base.s_fence ? >base.s_fence->finished :  
> > >hw_fence;
> > +   /* Check if any fences where initialized */
> > +   if (job->base.s_fence && job->base.s_fence->finished.ops)
> > +   f = >base.s_fence->finished;
> > +   else if (job->hw_fence.ops)
> > +   f = >hw_fence;
> > +   else
> > +   f = NULL;
> > +
> > for (i = 0; i < job->num_ibs; ++i)
> > amdgpu_ib_free(ring->adev, >ibs[i], f);
> >  }
> > --
> > 2.34.1
> >


Re: [PATCH 03/22] drm/amdgpu: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Sam Ravnborg
On Mon, Jan 16, 2023 at 02:12:16PM +0100, Thomas Zimmermann wrote:
> Several source files include drm_crtc_helper.h without needing it or
> only to get its transitive include statements; leading to unnecessary
> compile-time dependencies.
> 
> Directly include required headers and drop drm_crtc_helper.h where
> possible.
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c   | 1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   | 1 -
>  drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 1 -
>  drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 1 -
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 2 ++
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 2 ++
>  12 files changed, 12 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 2ebbc6382a06..3c962d0214cc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -25,7 +25,9 @@
>   */
>  
>  #include 
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "amdgpu.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 0993ee91fe18..63122482208d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
Move it one line up to keep the sorting.

With this fixed:
Reviewed-by: Sam Ravnborg 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> index b22471b3bd63..c5b98e9a69e9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
> @@ -42,6 +42,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c
> index c96e458ed088..27a782a9dc72 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c
> @@ -24,7 +24,6 @@
>   *  Alex Deucher
>   */
>  
> -#include 
>  #include 
>  #include "amdgpu.h"
>  #include "amdgpu_connectors.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> index a6aef488a822..d0a1cc88832c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> @@ -45,7 +45,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> index 8a39300b1a84..cf4b6e8d7d1e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> index afad094f84c2..10098fdd33fc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
> @@ -24,7 +24,6 @@
>   *  Alex Deucher
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include "amdgpu.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index 18ae9433e463..d95b2dc78063 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -28,7 +28,6 @@
>  
>  #include 
>  
> -#include 
>  #include 
>  #include "amdgpu.h"
>  #include "amdgpu_connectors.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index a2452fc304c5..01d1e2a631be 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -22,6 +22,8 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include "amdgpu.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index 6ac680c4c6e2..973abe989ebe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -22,6 +22,8 @@
>   */
>  
>  #include 
> +#include 
> +#include 
>  #include 
>  
>  #include "amdgpu.h"
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
> b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
> index 354ae09cc9a2..86e95b1c9d0e 100644
> --- 

Re: [PATCH 2/2] drm/amdgpu: simplify and cleanup amdgpu_uvd_send_msg

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 3:12 PM Christian König
 wrote:
>
> We only need one offset and not an array of it.
>
> We have a wait in the amdgpu_bo_kmap() code for quite a while now, so
> waiting here isn't needed any more.

This should probably be two patches, one to clean up the offsets and
one to remove the syncs.

Alex

>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 38 +++--
>  1 file changed, 10 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> index b67a5fb2ff3e..229419c0c031 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
> @@ -1118,30 +1118,26 @@ static int amdgpu_uvd_send_msg(struct amdgpu_ring 
> *ring, struct amdgpu_bo *bo,
>  {
> struct amdgpu_device *adev = ring->adev;
> struct dma_fence *f = NULL;
> +   uint32_t offset, data[4];
> struct amdgpu_job *job;
> struct amdgpu_ib *ib;
> -   uint32_t data[4];
> uint64_t addr;
> -   long r;
> -   int i;
> -   unsigned offset_idx = 0;
> -   unsigned offset[3] = { UVD_BASE_SI, 0, 0 };
> +   int i, r;
>
> r = amdgpu_job_alloc_with_ib(adev, 64, direct ? AMDGPU_IB_POOL_DIRECT 
> :
>  AMDGPU_IB_POOL_DELAYED, );
> if (r)
> return r;
>
> -   if (adev->asic_type >= CHIP_VEGA10) {
> -   offset_idx = 1 + ring->me;
> -   offset[1] = adev->reg_offset[UVD_HWIP][0][1];
> -   offset[2] = adev->reg_offset[UVD_HWIP][1][1];
> -   }
> +   if (adev->asic_type >= CHIP_VEGA10)
> +   offset = adev->reg_offset[UVD_HWIP][ring->me][1];
> +   else
> +   offset = UVD_BASE_SI;
>
> -   data[0] = PACKET0(offset[offset_idx] + UVD_GPCOM_VCPU_DATA0, 0);
> -   data[1] = PACKET0(offset[offset_idx] + UVD_GPCOM_VCPU_DATA1, 0);
> -   data[2] = PACKET0(offset[offset_idx] + UVD_GPCOM_VCPU_CMD, 0);
> -   data[3] = PACKET0(offset[offset_idx] + UVD_NO_OP, 0);
> +   data[0] = PACKET0(offset + UVD_GPCOM_VCPU_DATA0, 0);
> +   data[1] = PACKET0(offset + UVD_GPCOM_VCPU_DATA1, 0);
> +   data[2] = PACKET0(offset + UVD_GPCOM_VCPU_CMD, 0);
> +   data[3] = PACKET0(offset + UVD_NO_OP, 0);
>
> ib = >ibs[0];
> addr = amdgpu_bo_gpu_offset(bo);
> @@ -1158,24 +1154,10 @@ static int amdgpu_uvd_send_msg(struct amdgpu_ring 
> *ring, struct amdgpu_bo *bo,
> ib->length_dw = 16;
>
> if (direct) {
> -   r = dma_resv_wait_timeout(bo->tbo.base.resv,
> - DMA_RESV_USAGE_KERNEL, false,
> - msecs_to_jiffies(10));
> -   if (r == 0)
> -   r = -ETIMEDOUT;
> -   if (r < 0)
> -   goto err_free;
> -
> r = amdgpu_job_submit_direct(job, ring, );
> if (r)
> goto err_free;
> } else {
> -   r = amdgpu_sync_resv(adev, >sync, bo->tbo.base.resv,
> -AMDGPU_SYNC_ALWAYS,
> -AMDGPU_FENCE_OWNER_UNDEFINED);
> -   if (r)
> -   goto err_free;
> -
> r = amdgpu_job_submit(job, >uvd.entity,
>   AMDGPU_FENCE_OWNER_UNDEFINED, );
> if (r)
> --
> 2.34.1
>


Re: [PATCH 02/22] drm: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Sam Ravnborg
Hi Thomas.

On Mon, Jan 16, 2023 at 02:12:15PM +0100, Thomas Zimmermann wrote:
> Several DRM core and helper source files include drm_crtc_helper.h
> without needing it or only to get its transitive include statements;
> leading to unnecessary compile-time dependencies.
> 
> Directly include required headers and drop drm_crtc_helper.h where
> possible. The header file, drm_fixed.h, includes 
> for lower_32_bits().
> 
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/drm_crtc_helper.c  | 1 -
>  drivers/gpu/drm/drm_lease.c| 2 +-
>  drivers/gpu/drm/drm_plane_helper.c | 1 -
>  include/drm/drm_fixed.h| 1 +
>  4 files changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
> b/drivers/gpu/drm/drm_crtc_helper.c
> index a209659a996c..e7a23e18140c 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -39,7 +39,6 @@
>  #include 
>  #include 
>  #include 
> -#include 

drm_crtc_helper.c may not require drm/drm_crtc_helper.h, but it should
include it so we get a warning in case there is a mismatch between the
header file and the implementation.
I think sparse would also complain that the function is not declared
or something like that.

With this fixed:
Reviewed-by: Sam Ravnborg 

>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index 08ab75303a00..150fe1555068 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -6,7 +6,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index ba6a9136a065..c91e454eba09 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
> index 553210c02ee0..255645c1f9a8 100644
> --- a/include/drm/drm_fixed.h
> +++ b/include/drm/drm_fixed.h
> @@ -25,6 +25,7 @@
>  #ifndef DRM_FIXED_H
>  #define DRM_FIXED_H
>  
> +#include 
>  #include 
>  
>  typedef union dfixed {
> -- 
> 2.39.0


Re: [PATCH 1/2] drm/amdgpu: fix amdgpu_job_free_resources v2

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 3:12 PM Christian König
 wrote:
>
> It can be that neither fence were initialized when we run out of UVD
> streams for example.
>
> v2: fix typo breaking compile
>
> Signed-off-by: Christian König 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index f4a3122352de..6b73c074aa25 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@ -154,8 +154,14 @@ void amdgpu_job_free_resources(struct amdgpu_job *job)
> struct dma_fence *f;
> unsigned i;
>
> -   /* use sched fence if available */
> -   f = job->base.s_fence ? >base.s_fence->finished :  
> >hw_fence;
> +   /* Check if any fences where initialized */
> +   if (job->base.s_fence && job->base.s_fence->finished.ops)
> +   f = >base.s_fence->finished;
> +   else if (job->hw_fence.ops)
> +   f = >hw_fence;
> +   else
> +   f = NULL;
> +
> for (i = 0; i < job->num_ibs; ++i)
> amdgpu_ib_free(ring->adev, >ibs[i], f);
>  }
> --
> 2.34.1
>


[PATCH 2/2] drm/amdgpu: simplify and cleanup amdgpu_uvd_send_msg

2023-01-16 Thread Christian König
We only need one offset and not an array of it.

We have a wait in the amdgpu_bo_kmap() code for quite a while now, so
waiting here isn't needed any more.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 38 +++--
 1 file changed, 10 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index b67a5fb2ff3e..229419c0c031 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -1118,30 +1118,26 @@ static int amdgpu_uvd_send_msg(struct amdgpu_ring 
*ring, struct amdgpu_bo *bo,
 {
struct amdgpu_device *adev = ring->adev;
struct dma_fence *f = NULL;
+   uint32_t offset, data[4];
struct amdgpu_job *job;
struct amdgpu_ib *ib;
-   uint32_t data[4];
uint64_t addr;
-   long r;
-   int i;
-   unsigned offset_idx = 0;
-   unsigned offset[3] = { UVD_BASE_SI, 0, 0 };
+   int i, r;
 
r = amdgpu_job_alloc_with_ib(adev, 64, direct ? AMDGPU_IB_POOL_DIRECT :
 AMDGPU_IB_POOL_DELAYED, );
if (r)
return r;
 
-   if (adev->asic_type >= CHIP_VEGA10) {
-   offset_idx = 1 + ring->me;
-   offset[1] = adev->reg_offset[UVD_HWIP][0][1];
-   offset[2] = adev->reg_offset[UVD_HWIP][1][1];
-   }
+   if (adev->asic_type >= CHIP_VEGA10)
+   offset = adev->reg_offset[UVD_HWIP][ring->me][1];
+   else
+   offset = UVD_BASE_SI;
 
-   data[0] = PACKET0(offset[offset_idx] + UVD_GPCOM_VCPU_DATA0, 0);
-   data[1] = PACKET0(offset[offset_idx] + UVD_GPCOM_VCPU_DATA1, 0);
-   data[2] = PACKET0(offset[offset_idx] + UVD_GPCOM_VCPU_CMD, 0);
-   data[3] = PACKET0(offset[offset_idx] + UVD_NO_OP, 0);
+   data[0] = PACKET0(offset + UVD_GPCOM_VCPU_DATA0, 0);
+   data[1] = PACKET0(offset + UVD_GPCOM_VCPU_DATA1, 0);
+   data[2] = PACKET0(offset + UVD_GPCOM_VCPU_CMD, 0);
+   data[3] = PACKET0(offset + UVD_NO_OP, 0);
 
ib = >ibs[0];
addr = amdgpu_bo_gpu_offset(bo);
@@ -1158,24 +1154,10 @@ static int amdgpu_uvd_send_msg(struct amdgpu_ring 
*ring, struct amdgpu_bo *bo,
ib->length_dw = 16;
 
if (direct) {
-   r = dma_resv_wait_timeout(bo->tbo.base.resv,
- DMA_RESV_USAGE_KERNEL, false,
- msecs_to_jiffies(10));
-   if (r == 0)
-   r = -ETIMEDOUT;
-   if (r < 0)
-   goto err_free;
-
r = amdgpu_job_submit_direct(job, ring, );
if (r)
goto err_free;
} else {
-   r = amdgpu_sync_resv(adev, >sync, bo->tbo.base.resv,
-AMDGPU_SYNC_ALWAYS,
-AMDGPU_FENCE_OWNER_UNDEFINED);
-   if (r)
-   goto err_free;
-
r = amdgpu_job_submit(job, >uvd.entity,
  AMDGPU_FENCE_OWNER_UNDEFINED, );
if (r)
-- 
2.34.1



[PATCH 1/2] drm/amdgpu: fix amdgpu_job_free_resources v2

2023-01-16 Thread Christian König
It can be that neither fence were initialized when we run out of UVD
streams for example.

v2: fix typo breaking compile

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index f4a3122352de..6b73c074aa25 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@ -154,8 +154,14 @@ void amdgpu_job_free_resources(struct amdgpu_job *job)
struct dma_fence *f;
unsigned i;
 
-   /* use sched fence if available */
-   f = job->base.s_fence ? >base.s_fence->finished :  >hw_fence;
+   /* Check if any fences where initialized */
+   if (job->base.s_fence && job->base.s_fence->finished.ops)
+   f = >base.s_fence->finished;
+   else if (job->hw_fence.ops)
+   f = >hw_fence;
+   else
+   f = NULL;
+
for (i = 0; i < job->num_ibs; ++i)
amdgpu_ib_free(ring->adev, >ibs[i], f);
 }
-- 
2.34.1



Re: [PATCH v3 0/3] drm/{amdgpu, i915, nouveau, radeon}: Fix fbdev and vga-switcheroo

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 6:54 AM Thomas Zimmermann  wrote:
>
> (was: drm: Generic fbdev and vga-switcheroo)
>
> This patchset fixes how fbdev helpers interact with vga-switcheroo. The
> first two patches are bug fixes for the existing code. The third patch
> cleans up the drivers.
>
> Patch 1 fixes i915 to do the correct thing if the device has not been
> initialized yet. Switching to the device is only possible after the
> initialization, but switching away is always possible.
>
> Patch 2 is the original patch without the amdgpu changes. Installs
> the fbdev framebuffer in vga-switcheroo for the PCI device. Does
> nothing for drivers without vga-switcheroo.
>
> Patch 3 cleans up vga_switcheroo_process_delayed_switch() in amdgpu
> and the other related drivers (i.e., i915, nouveau and radeon). The
> call is now located at the end of drm_lastclose() and drivers do not
> need their own lastclose helpers any longer.
>
> I kept the r-bs from v1, but patch 1 is entirely new and patch 3 has
> significantly grown in size.

Series is:
Reviewed-by: Alex Deucher 

>
> v3:
> * include drm_fb_helper.h in radeon_drv.c
> v2:
> * expand to patch series
> * fix i915, nouveau and radeon
>
> Thomas Zimmermann (3):
>   drm/i915: Allow switching away via vga-switcheroo if uninitialized
>   drm/fb-helper: Set framebuffer for vga-switcheroo clients
>   drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 13 -
>  drivers/gpu/drm/drm_fb_helper.c |  8 
>  drivers/gpu/drm/drm_file.c  |  3 +++
>  drivers/gpu/drm/i915/i915_driver.c  | 26 ++---
>  drivers/gpu/drm/i915/i915_switcheroo.c  |  6 +-
>  drivers/gpu/drm/nouveau/nouveau_drm.c   |  1 -
>  drivers/gpu/drm/nouveau/nouveau_vga.c   |  7 ---
>  drivers/gpu/drm/nouveau/nouveau_vga.h   |  1 -
>  drivers/gpu/drm/radeon/radeon_drv.c |  3 ++-
>  drivers/gpu/drm/radeon/radeon_drv.h |  1 -
>  drivers/gpu/drm/radeon/radeon_kms.c | 18 -
>  drivers/gpu/vga/vga_switcheroo.c|  4 ++--
>  14 files changed, 22 insertions(+), 72 deletions(-)
>
>
> base-commit: 68d139b609a97a83e7c231189d4864aba4e1679b
> prerequisite-patch-id: 0aa359f6144c4015c140c8a6750be19099c676fb
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6
> --
> 2.39.0
>


Re: [PATCH 00/22] drm: Remove includes for drm_crtc_helper.h

2023-01-16 Thread Alex Deucher
On Mon, Jan 16, 2023 at 11:20 AM Jani Nikula
 wrote:
>
> On Mon, 16 Jan 2023, Thomas Zimmermann  wrote:
> > A lot of source files include drm_crtc_helper.h for its contained
> > include statements. This leads to excessive compile-time dependencies.
> >
> > Where possible, remove the include statements for drm_crtc_helper.h
> > and include the required source files directly. Also remove the
> > include statements from drm_crtc_helper.h itself, which doesn't need
> > most of them.
> >
> > I built this patchset on x86-64, aarch64 and arm. Hopefully I found
> > all include dependencies.
>
> I think this is the right direction and I support this. Personally I
> think it's enough to build test and fix any fallout afterwards.
>
> To that end, I did build test this myself with my config, and it was
> fine, though that probably doesn't add much coverage.
>
> FWIW,
>
> Acked-by: Jani Nikula 

Agreed.  I applied 1/22 since it was an unrelated cleanup, but the
rest of the series is:
Acked-by: Alex Deucher 

>
>
> --
> Jani Nikula, Intel Open Source Graphics Center


Re: [PATCH 01/22] drm/amdgpu: Fix coding style

2023-01-16 Thread Alex Deucher
Applied.  Thanks!
On Mon, Jan 16, 2023 at 8:13 AM Thomas Zimmermann  wrote:
>
> Align a closing brace and remove trailing whitespaces. No functional
> changes.
>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index e47058c2c294..0993ee91fe18 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -5871,8 +5871,8 @@ void amdgpu_device_invalidate_hdp(struct amdgpu_device 
> *adev,
>  int amdgpu_in_reset(struct amdgpu_device *adev)
>  {
> return atomic_read(>reset_domain->in_gpu_reset);
> -   }
> -
> +}
> +
>  /**
>   * amdgpu_device_halt() - bring hardware to some kind of halt state
>   *
> --
> 2.39.0
>


Re: [PATCH] drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix

2023-01-16 Thread Alex Deucher
Applied with the fixes tag.

Thanks,

Alex

On Mon, Jan 16, 2023 at 9:50 AM Melissa Wen  wrote:
>
> On 01/10, Joshua Ashton wrote:
> > The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is
> > missing the values for the fourth column of the matrix.
> >
> > The fourth column of the matrix is essentially just a value that is
> > added given that the color is 3 components in size.
> > These values are needed to bias the chroma from the [-1, 1] -> [0, 1]
> > range.
> >
> > This fixes color being very green when using Gamescope HDR on HDMI
> > output which prefers YCC 4:4:4.
> >
> > Signed-off-by: Joshua Ashton 
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 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..652270a0b498 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
> > @@ -90,8 +90,8 @@ static const struct out_csc_color_matrix_type 
> > output_csc_matrix[] = {
> >   { 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, 0x1004, 0x0868, 0x15B2,
> > + 0x01E6, 0x201, 0xFB88, 0xF478, 0x1000, 
> > 0x1004} },
>
> LGTM.
>
> I'd also add a fixes tag here to:
>
> Fixes: 40df2f809e8f ("drm/amd/display: color space ycbcr709 support")
>
> Thanks,
>
> Reviewed-by: Melissa Wen 
>
> >   { COLOR_SPACE_YCBCR709_BLACK_TYPE,
> >   { 0x, 0x, 0x, 0x1000, 0x, 0x,
> >   0x, 0x0200, 0x, 0x, 0x, 
> > 0x1000} },
> > --
> > 2.39.0
> >
>


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

2023-01-16 Thread Alex Deucher
Applied with the fixes tag.  Thanks!

Alex

On Mon, Jan 16, 2023 at 9:41 AM Melissa Wen  wrote:
>
> On 01/16, Melissa Wen wrote:
> > On 01/10, Joshua Ashton wrote:
> > > 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.
> > >
> > > v2: Fixed patch being accidentally based on a personal feature branch, 
> > > oops!
> > >
> > > Signed-off-by: Joshua Ashton 
> > > ---
> > >  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 b4d60eedbcbf..9da71ee8fcc4 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);
> > > -
> > > 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);
> >
> > LGTM.
> >
> > I see that we were ignoring the updated value of pixel_encoding in the
> > previous point. Nice catch!
> >
> > Reviewed-by: Melissa Wen 
>
> BTW, I think it deserves a fixes tag to:
>
> Fixes: ea117312ea9f ("drm/amd/display: Reduce HDMI pixel encoding if max 
> clock is exceeded")
>
> >
> > >  }
> > >
> > >  static void fill_audio_info(struct audio_info *audio_info,
> > > --
> > > 2.39.0
> > >
>
>


Re: [PATCH] drm/amd/display: avoid variable reinitialization

2023-01-16 Thread Alex Deucher
This is already fixed.

Thanks,

Alex

On Sun, Jan 15, 2023 at 4:32 AM Deepak R Varma  wrote:
>
> The member variable set_odm_combine is already initialized and hence the
> reinitialization instruction can be removed. Issue identified using the
> dubleinit.cocci Coccinelle semantic patch script.
>
> Signed-off-by: Deepak R Varma 
> ---
>  drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c 
> b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
> index 41edbd64ea21..777d8efee977 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn314/dcn314_optc.c
> @@ -254,7 +254,6 @@ static struct timing_generator_funcs dcn314_tg_funcs = {
> .get_hw_timing = optc1_get_hw_timing,
> .init_odm = optc3_init_odm,
> .set_odm_bypass = optc314_set_odm_bypass,
> -   .set_odm_combine = optc314_set_odm_combine,
> .set_h_timing_div_manual_mode = 
> optc314_set_h_timing_div_manual_mode,
>  };
>
> --
> 2.34.1
>
>
>


Re: [PATCH] drm/amd/display: use swap() helper macro in bios_parser

2023-01-16 Thread Alex Deucher
Applied.  Thanks!

On Sun, Jan 15, 2023 at 4:26 AM Deepak R Varma  wrote:
>
> Use swap() helper macro instead of open coded swap instructions. The
> change also facilitates code cleanup and realignment for improved
> readability.  Issue identified using swap.cocci Coccinelle semantic
> patch script.
>
> Signed-off-by: Deepak R Varma 
> ---
>  drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index 074e70a5c458..7b5894adbf51 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -2929,7 +2929,6 @@ static enum bp_result construct_integrated_info(
> struct atom_common_table_header *header;
> struct atom_data_revision revision;
>
> -   struct clock_voltage_caps temp = {0, 0};
> uint32_t i;
> uint32_t j;
>
> @@ -3032,14 +3031,8 @@ static enum bp_result construct_integrated_info(
> for (i = 1; i < NUMBER_OF_DISP_CLK_VOLTAGE; ++i) {
> for (j = i; j > 0; --j) {
> if (info->disp_clk_voltage[j].max_supported_clk <
> -   info->disp_clk_voltage[j-1].max_supported_clk
> -   ) {
> -   /* swap j and j - 1*/
> -   temp = info->disp_clk_voltage[j-1];
> -   info->disp_clk_voltage[j-1] =
> -   info->disp_clk_voltage[j];
> -   info->disp_clk_voltage[j] = temp;
> -   }
> +   info->disp_clk_voltage[j-1].max_supported_clk)
> +   swap(info->disp_clk_voltage[j-1], 
> info->disp_clk_voltage[j]);
> }
> }
>
> --
> 2.34.1
>
>
>


Re: [PATCH 0/3] drm/amd/pm/powerplay: use bitwise or for bitmasks addition

2023-01-16 Thread Alex Deucher
Applied.  Thanks!

Alex

On Sun, Jan 15, 2023 at 9:27 PM Quan, Evan  wrote:
>
> [AMD Official Use Only - General]
>
> Series is reviewed-by: Evan Quan 
>
> > -Original Message-
> > From: Deepak R Varma 
> > Sent: Sunday, January 15, 2023 3:16 PM
> > To: Quan, Evan ; Deucher, Alexander
> > ; Koenig, Christian
> > ; Pan, Xinhui ; David
> > Airlie ; Daniel Vetter ; amd-
> > g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; linux-
> > ker...@vger.kernel.org
> > Cc: Saurabh Singh Sengar ; Praveen Kumar
> > 
> > Subject: [PATCH 0/3] drm/amd/pm/powerplay: use bitwise or for bitmasks
> > addition
> >
> > The patch series proposes usage of bitwise or "|" operator for addition of
> > bitmasks instead of using numerial additions. The former is quicker and
> > cleaner.
> >
> > The proposed change is compile tested.
> >
> > Deepak R Varma (3):
> >   drm/amd/pm/powerplay/smumgr: use bitwise or for addition
> >   drm/amd/pm/powerplay/hwmgr: use bitwise or for bitmasks addition
> >   drm/amd/pm/powerplay/smumgr/ci: use bitwise or for bitmasks addition
> >
> >  drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_hwmgr.c  | 8 ---
> > -
> >  drivers/gpu/drm/amd/pm/powerplay/smumgr/ci_smumgr.c  | 2 +-
> >  drivers/gpu/drm/amd/pm/powerplay/smumgr/iceland_smumgr.c | 2 +-
> >  drivers/gpu/drm/amd/pm/powerplay/smumgr/tonga_smumgr.c   | 2 +-
> >  4 files changed, 7 insertions(+), 7 deletions(-)
> >
> > --
> > 2.34.1
> >
> >


Re: Barco MXRT-5600 branded W5100 with PCI ID 664d

2023-01-16 Thread Alex Deucher
On Sun, Jan 15, 2023 at 11:49 AM Matthias Reichl  wrote:
>
> I noticed some of the used HP Z240 workstations I recently bought had a
> Barco MXRT-5600 branded FirePro W5100 card installed - some others came with
> an unbranded W5100 (with the standard 6449 PCI ID).
>
> Except for a large Barco sticker on the top and Barco being mentioned on
> the barcode label on the back they look completely identical.
>
> lspci knows about the 644d PCI ID but neither the radeon nor amdgpu kernel
> drivers do nor does drm/mesa/xorg userspace.
>
> I had a go at it, added the pci id to kernel drivers, libdrm, mesa, 
> xf86-video-ati
> and xserver and got the card working fine on Debian Bullseye with kernel 
> 6.2-rc3.
> I also gave it a quick try with LibreELEC (where we build bleeding edge 
> versions
> from scratch) and that worked fine, too.
>
> Do you happen to know more about that card and why the PCI ID is missing in
> linux drivers/userspace?

I don't see that DID in either the Linux driver or our windows driver.
Presumably it was a special card supported with a special driver for a
specific customer.  I'm not really sure off hand whether it needs some
special handling.

Alex


>
> I'm just attaching my current kernel and userspace patches as a reference
> for now but I'm very unsure in which sequence they should be applied without
> risking breakage - I already found out the hard way that patched xorg server
> and driver with old libdrm is a bad idea as that results in "Failed to 
> initialize
> surface manager" instead of starting with framebuffer driver.
>
> If you prefer I can send proper patches or I can just you let handle it.
>
> For reference here's the lspci outout (with patched kernel and cik support
> enabled in amdgpu):
>
> root@camel3:~# lspci -vn -s 01:00.0
> 01:00.0 0300: 1002:664d (prog-if 00 [VGA controller])
> Subsystem: 13cc:3d2a
> Flags: bus master, fast devsel, latency 0, IRQ 137
> Memory at 1c (64-bit, prefetchable) [size=4G]
> Memory at 1d (64-bit, prefetchable) [size=8M]
> I/O ports at 3000 [size=256]
> Memory at d0f0 (32-bit, non-prefetchable) [size=256K]
> Expansion ROM at d0f4 [disabled] [size=128K]
> Capabilities: [48] Vendor Specific Information: Len=08 
> Capabilities: [50] Power Management version 3
> Capabilities: [58] Express Legacy Endpoint, MSI 00
> Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
> Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 
> Len=010 
> Capabilities: [150] Advanced Error Reporting
> Capabilities: [200] Physical Resizable BAR
> Capabilities: [270] Secondary PCI Express
> Capabilities: [2b0] Address Translation Service (ATS)
> Capabilities: [2c0] Page Request Interface (PRI)
> Capabilities: [2d0] Process Address Space ID (PASID)
> Kernel driver in use: amdgpu
> Kernel modules: radeon, amdgpu
>
> so long,
>
> Hias


Re: [PATCH] drm/amdgpu: Use the sched from entity for amdgpu_cs trace

2023-01-16 Thread Christian König

Am 16.01.23 um 17:16 schrieb Leo Liu:

The problem is that base sched hasn't been assigned yet at this moment, causing something 
like "ring=0"
all the time from trace.
  mpv:cs0-3473[002] .   129.047431: amdgpu_cs: 
bo_list=92ffb3070400, ring=0, dw=48, fences=0
  mpv:cs0-3473[002] .   129.089125: amdgpu_cs: 
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
  mpv:cs0-3473[002] .   129.130987: amdgpu_cs: 
bo_list=92ff84831c00, ring=0, dw=48, fences=0
  mpv:cs0-3473[002] .   129.172478: amdgpu_cs: 
bo_list=92ffa4b84c00, ring=0, dw=48, fences=0
  mpv:cs0-3473[003] .   129.214000: amdgpu_cs: 
bo_list=92ffb405b400, ring=0, dw=48, fences=0
  mpv:cs0-3473[003] .   129.255763: amdgpu_cs: 
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
  mpv:cs0-3473[003] .   129.297316: amdgpu_cs: 
bo_list=92ffa4b84c00, ring=0, dw=48, fences=0
  mpv:cs0-3473[003] .   129.338978: amdgpu_cs: 
bo_list=92ff84831c00, ring=0, dw=48, fences=0
  mpv:cs0-3473[003] .   129.380685: amdgpu_cs: 
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
  mpv:cs0-3473[003] .   129.421993: amdgpu_cs: 
bo_list=92ffdb4c3400, ring=0, dw=48, fences=0

Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6")
Signed-off-by: Leo Liu 


Reviewed-by: Christian König 


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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 5e6ddc7e101c..6cd6ea765d37 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -153,10 +153,10 @@ TRACE_EVENT(amdgpu_cs,
  
  	TP_fast_assign(

   __entry->bo_list = p->bo_list;
-  __entry->ring = to_amdgpu_ring(job->base.sched)->idx;
+  __entry->ring = 
to_amdgpu_ring(job->base.entity->rq->sched)->idx;
   __entry->dw = ib->length_dw;
   __entry->fences = amdgpu_fence_count_emitted(
-   to_amdgpu_ring(job->base.sched));
+   to_amdgpu_ring(job->base.entity->rq->sched));
   ),
TP_printk("bo_list=%p, ring=%u, dw=%u, fences=%u",
  __entry->bo_list, __entry->ring, __entry->dw,




Re: [PATCH 00/22] drm: Remove includes for drm_crtc_helper.h

2023-01-16 Thread Jani Nikula
On Mon, 16 Jan 2023, Thomas Zimmermann  wrote:
> A lot of source files include drm_crtc_helper.h for its contained
> include statements. This leads to excessive compile-time dependencies.
>
> Where possible, remove the include statements for drm_crtc_helper.h
> and include the required source files directly. Also remove the
> include statements from drm_crtc_helper.h itself, which doesn't need
> most of them.
>
> I built this patchset on x86-64, aarch64 and arm. Hopefully I found
> all include dependencies.

I think this is the right direction and I support this. Personally I
think it's enough to build test and fix any fallout afterwards.

To that end, I did build test this myself with my config, and it was
fine, though that probably doesn't add much coverage.

FWIW,

Acked-by: Jani Nikula 


-- 
Jani Nikula, Intel Open Source Graphics Center


[PATCH] drm/amdgpu: Use the sched from entity for amdgpu_cs trace

2023-01-16 Thread Leo Liu
The problem is that base sched hasn't been assigned yet at this moment, causing 
something like "ring=0"
all the time from trace.
 mpv:cs0-3473[002] .   129.047431: amdgpu_cs: 
bo_list=92ffb3070400, ring=0, dw=48, fences=0
 mpv:cs0-3473[002] .   129.089125: amdgpu_cs: 
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
 mpv:cs0-3473[002] .   129.130987: amdgpu_cs: 
bo_list=92ff84831c00, ring=0, dw=48, fences=0
 mpv:cs0-3473[002] .   129.172478: amdgpu_cs: 
bo_list=92ffa4b84c00, ring=0, dw=48, fences=0
 mpv:cs0-3473[003] .   129.214000: amdgpu_cs: 
bo_list=92ffb405b400, ring=0, dw=48, fences=0
 mpv:cs0-3473[003] .   129.255763: amdgpu_cs: 
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
 mpv:cs0-3473[003] .   129.297316: amdgpu_cs: 
bo_list=92ffa4b84c00, ring=0, dw=48, fences=0
 mpv:cs0-3473[003] .   129.338978: amdgpu_cs: 
bo_list=92ff84831c00, ring=0, dw=48, fences=0
 mpv:cs0-3473[003] .   129.380685: amdgpu_cs: 
bo_list=92ffba4b7000, ring=0, dw=48, fences=0
 mpv:cs0-3473[003] .   129.421993: amdgpu_cs: 
bo_list=92ffdb4c3400, ring=0, dw=48, fences=0

Fixes: 4624459c84d7 ("drm/amdgpu: add gang submit frontend v6")
Signed-off-by: Leo Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
index 5e6ddc7e101c..6cd6ea765d37 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h
@@ -153,10 +153,10 @@ TRACE_EVENT(amdgpu_cs,
 
TP_fast_assign(
   __entry->bo_list = p->bo_list;
-  __entry->ring = to_amdgpu_ring(job->base.sched)->idx;
+  __entry->ring = 
to_amdgpu_ring(job->base.entity->rq->sched)->idx;
   __entry->dw = ib->length_dw;
   __entry->fences = amdgpu_fence_count_emitted(
-   to_amdgpu_ring(job->base.sched));
+   to_amdgpu_ring(job->base.entity->rq->sched));
   ),
TP_printk("bo_list=%p, ring=%u, dw=%u, fences=%u",
  __entry->bo_list, __entry->ring, __entry->dw,
-- 
2.25.1



[PATCH 6.1 138/183] drm/amdgpu: Fix potential NULL dereference

2023-01-16 Thread Greg Kroah-Hartman
From: Luben Tuikov 

[ Upstream commit 0be7ed8e7eb15282b5d0f6fdfea884db594ea9bf ]

Fix potential NULL dereference, in the case when "man", the resource manager
might be NULL, when/if we print debug information.

Cc: Alex Deucher 
Cc: Christian König 
Cc: AMD Graphics 
Cc: Dan Carpenter 
Cc: kernel test robot 
Fixes: 7554886daa31ea ("drm/amdgpu: Fix size validation for non-exclusive 
domains (v4)")
Signed-off-by: Luben Tuikov 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 3be3cba3a16d..cfd78c4a45ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -468,8 +468,9 @@ static bool amdgpu_bo_validate_size(struct amdgpu_device 
*adev,
return true;
 
 fail:
-   DRM_DEBUG("BO size %lu > total memory in domain: %llu\n", size,
- man->size);
+   if (man)
+   DRM_DEBUG("BO size %lu > total memory in domain: %llu\n", size,
+ man->size);
return false;
 }
 
-- 
2.35.1





RE: [PATCH 00/37] DC Patches Jan 10, 2023

2023-01-16 Thread Wheeler, Daniel
[Public]

Hi all,
 
This week this patchset was tested on the following systems:
 
Lenovo Thinkpad T14s Gen2, with AMD Ryzen 5 5650U 
Lenovo Thinkpad T13s Gen4 with AMD Ryzen 5 6600U
Reference AMD RX6800
 
These systems were tested on the following display types: 
eDP, (1080p 60hz [4500U, 5650U]) (1920x1200 60hz [6600U]) (2560x1600 
120hz[6600U])
VGA and DVI (1680x1050 60HZ [DP to VGA/DVI, USB-C to DVI/VGA])
DP/HDMI/USB-C (1440p 170hz, 4k 60hz, 4k 144hz [Includes USB-C to DP/HDMI 
adapters])
 
MST tested with Startech MST14DP123DP and 2x 4k 60Hz displays
DSC tested with Cable Matters 101075 (DP to 3x DP), and 201375 (USB-C to 3x DP) 
with 3x 4k60 displays
HP Hook G2 with 1 and 2 4k60 Displays
 
The testing is a mix of automated and manual tests. Manual testing includes 
(but is not limited to):
Changing display configurations and settings
Benchmark testing
Feature testing (Freesync, etc.)
 
Automated testing includes (but is not limited to):
Script testing (scripts to automate some of the manual checks)
IGT testing
 
The patchset consists of the amd-staging-drm-next branch (Head commit - 
004cf26320ba drm/amd/display: 3.2.217) with new patches added on top of it. 
This branch is used for both Ubuntu and Chrome OS testing (ChromeOS on a 
bi-weekly basis).

 
Tested on Ubuntu 22.04.1 and Chrome OS
 
Tested-by: Daniel Wheeler 
 
 
Thank you,
 
Dan Wheeler
Sr. Technologist | AMD
SW Display
--
1 Commerce Valley Dr E, Thornhill, ON L3T 7X6
amd.com


-Original Message-
From: Siqueira, Rodrigo  
Sent: January 10, 2023 11:55 AM
To: amd-gfx@lists.freedesktop.org
Cc: Wentland, Harry ; Li, Sun peng (Leo) 
; Lakha, Bhawanpreet ; Siqueira, 
Rodrigo ; Pillai, Aurabindo 
; Zhuo, Qingqing (Lillian) ; 
Li, Roman ; Lin, Wayne ; Wang, Chao-kai 
(Stylon) ; Chiu, Solomon ; Kotarac, 
Pavle ; Gutierrez, Agustin ; 
Zuo, Jerry ; Mahfooz, Hamza ; 
Wheeler, Daniel 
Subject: [PATCH 00/37] DC Patches Jan 10, 2023

This DC patchset brings improvements in multiple areas. In summary, we 
highlight the following areas:

- Revert patches that caused regressions associated with audio and an
  old change that checks the DCN version.
- Refactor DDC and HDP.
- Move DPIA and DPCD logic to new files.
- Updates to DMUB.
- Optimization and bug fixes for SUBVP/DRR.
- Drop legacy code.

Cc: Daniel Wheeler 

Thanks
Siqueira

Alvin Lee (2):
  drm/amd/display: Request min clocks after disabling pipes on init
  drm/amd/display: Allow subvp on vactive pipes that are 2560x1440@60

Aric Cyr (1):
  drm/amd/display: 3.2.218

Aurabindo Pillai (2):
  Revert "drm/amd/display: Demote Error Level When ODM Transition
Supported"
  drm/amd/display: fix an error check condition for synced pipes

Bhawanpreet Lakha (1):
  drm/amd/display: Change i2c speed for hdcp

Brandon Syu (1):
  drm/amd/display: fix mapping to non-allocated address

Charlene Liu (2):
  drm/amd/display: add hubbub_init related
  drm/amd/display: contional remove disable dig_fifo when blank

Cruise Hung (1):
  drm/amd/display: Fix DPIA link encoder assignment issue

Dillon Varone (9):
  drm/amd/display: Implement FIFO enable sequence on DCN32
  drm/amd/display: Optimize subvp and drr validation
  drm/amd/display: Account for DCC Meta pitch in DML MALL surface
calculations
  drm/amd/display: Account for Subvp Phantoms in DML MALL surface
calculations
  drm/amd/display: Use DML for MALL SS and Subvp allocation calculations
  drm/amd/display: cleanup function args in dml
  drm/amd/display: set active bit for desktop with VSDBv3
  drm/amd/display: Remove DISPCLK dentist programming for dcn32
  drm/amd/display: Account for MPO planes in dcn32 mall alloc
calculations

Dmytro Laktyushkin (1):
  drm/amd/display: fix multi edp panel instancing

Martin Leung (1):
  Revert "drm/amd/display: Speed up DML fast_validate path"

Mustapha Ghaddar (2):
  drm/amd/display: Update BW alloc after new DMUB logic
  drm/amd/display: Update dmub header to match DMUB

Rodrigo Siqueira (1):
  drm/amd/display: Remove unused code

Saaem Rizvi (2):
  drm/amd/display: Remove SubVp support if src/dst rect does not equal
stream timing
  drm/amd/display: Add extra mblk for DCC

Tony Tascioglu (2):
  drm/amd/display: Optimize link power-down when link powered externally
  drm/amd/display: Skip backlight control delay on external powered
links

Wenjing Liu (7):
  drm/amd/display: refactor hpd logic from dc_link to link_hpd
  drm/amd/display: refactor ddc logic from dc_link_ddc to link_ddc
  drm/amd/display: move dpcd logic from dc_link_dpcd to link_dpcd
  drm/amd/display: move dc_link_dpia logic to link_dp_dpia
  drm/amd/display: move dp link training logic to link_dp_training
  drm/amd/display: move dp phy related logic to link_dp_phy
  drm/amd/display: move dp capability related logic to
link_dp_capability

hersen wu (2):
  drm/amd/display: phase2 enable mst hdcp multiple displays
  

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

2023-01-16 Thread Christian König

Am 16.01.23 um 15:52 schrieb Felix Kuehling:

Am 2023-01-16 um 06:42 schrieb Christian König:

[SNIP]
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.


That won't work.


I don't think this is incorrect.


No, this is completely incorrect. It mixes up the reverse tracking 
of mappings and might crash the system.


I don't understand that. The imported BO is a different BO with a 
different mmap offset in a different device file. I don't see how 
that messes with the tracking of mappings.


The tracking keeps note which piece of information is accessible 
through which address space object and offset. I you suddenly have 
two address spaces and offsets pointing to the same piece of 
information that won't work any more.


How do you identify a "piece of information". I don't think it's the 
physical page. VRAM doesn't even have struct pages. I think it's the 
BO that's being tracked.


Both struct page as well as pfn. Essentially everything you can give 
vm_insert_pfn() or vm_insert_page() as parameter.


With a dmabuf import you have a second BO aliasing the same physical 
pages as the original BO.


No, exactly that's wrong. You have a BO which contains a bunch of dma 
addresses. The pages or whatever lies behind those as backing store are 
intentionally hidden from the importer.


Daniel even started mangling the page pointer to prevent people from 
using them: 
https://elixir.bootlin.com/linux/latest/source/drivers/dma-buf/dma-buf.c#L769


Then those two BOs are seen as two distinct "pieces of information" 
that can each have their own mapping.


Well I need to correct myself: Creating a "fake" offset for the BO is 
ok, but we should just never ever mmap() through two different address 
spaces.







This is the reason why we can't mmap() imported BOs.


I don't see anything preventing that. For userptr BOs, there is this 
code in amdgpu_gem_object_mmap:


    if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
    return -EPERM;

I don't see anything like this preventing mmapping of imported 
dmabuf BOs. What am I missing?




At some point I really need to make a big presentation about all this 
stuff, we had the same discussion multiple times now :)


It's the same reason why you can't mmap() VRAM through the kfd node: 
Each file can have only one address space object associated with it.


I remember that. We haven't used KFD to mmap BOs for a long time for 
that reason.





See dma_buf_mmap() and vma_set_file() how this is worked around in 
DMA-buf.


These are for mmapping memory through the dmabuf fd. I'm not sure 
that's a good example. drm_gem_prime_mmap creates a temporary struct 
file and struct drm_file that are destroyed immediately after calling 
obj->dev->driver->fops->mmap. I think that would break any reverse 
mapping.


I was hoping we have removed that code by now. Today obj->funcs->mmap 
should be used and not the hack with temporary creating an file/fpriv 
any more.




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.


Actually it shouldn't. This can go boom really easily.


OK. I don't think we're doing this, but after Xiaogang raised the 
question I went looking through the code whether it's theoretically 
possible. I didn't find anything in the code that says that mmapping 
imported dmabufs would be prohibited or even dangerous. On the 
contrary, I found that ttm_bo_vm explicitly supports mmapping SG BOs.





When you have imported a BO the only correct way of to mmap() it is 
to do so on the original exporter.


That seems sensible, and this is what we do today. That said, if 
mmapping an imported BO is dangerous, I'm missing a mechanism to 
protect against this. It could be as simple as setting 
AMDGPU_GEM_CREATE_NO_CPU_ACCESS in amdgpu_dma_buf_create_obj.


At least for the GEM mmap() handler this is double checked very early 
by looking at obj->import_attach and then either rejecting it or 
redirecting the request to the DMA-buf file instead.


Can you point me at where this check is? I see a check for 
obj->import_attach in drm_gem_dumb_map_offset. But I can't see how 
this function is called in amdgpu. I don't think it is used at all.


Uff, good question! @Thomas and @Dmitry: I clearly remember that one of 
you guys was involved in the DRM/GEM mmap cleanup and DMA-buf with 
workarounds for the KFD and DMA-buf.


What was the final solution to this? I can't find it of hand any more.



We probably need something similar when stuff is mapped through the 
KFD node. But I think we don't do that any more for "normal" BOs 
anyway, don't we?


Correct, we don't map BOs through the KFD device file. The only 
mappings we still use it for are:


 * Doorbells on APUs
 * Events 

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

2023-01-16 Thread Felix Kuehling

Am 2023-01-16 um 06:42 schrieb Christian König:

[SNIP]
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.


That won't work.


I don't think this is incorrect.


No, this is completely incorrect. It mixes up the reverse tracking 
of mappings and might crash the system.


I don't understand that. The imported BO is a different BO with a 
different mmap offset in a different device file. I don't see how 
that messes with the tracking of mappings.


The tracking keeps note which piece of information is accessible 
through which address space object and offset. I you suddenly have two 
address spaces and offsets pointing to the same piece of information 
that won't work any more.


How do you identify a "piece of information". I don't think it's the 
physical page. VRAM doesn't even have struct pages. I think it's the BO 
that's being tracked. With a dmabuf import you have a second BO aliasing 
the same physical pages as the original BO. Then those two BOs are seen 
as two distinct "pieces of information" that can each have their own 
mapping.








This is the reason why we can't mmap() imported BOs.


I don't see anything preventing that. For userptr BOs, there is this 
code in amdgpu_gem_object_mmap:


    if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
    return -EPERM;

I don't see anything like this preventing mmapping of imported dmabuf 
BOs. What am I missing?




At some point I really need to make a big presentation about all this 
stuff, we had the same discussion multiple times now :)


It's the same reason why you can't mmap() VRAM through the kfd node: 
Each file can have only one address space object associated with it.


I remember that. We haven't used KFD to mmap BOs for a long time for 
that reason.





See dma_buf_mmap() and vma_set_file() how this is worked around in 
DMA-buf.


These are for mmapping memory through the dmabuf fd. I'm not sure that's 
a good example. drm_gem_prime_mmap creates a temporary struct file and 
struct drm_file that are destroyed immediately after calling 
obj->dev->driver->fops->mmap. I think that would break any reverse mapping.







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.


Actually it shouldn't. This can go boom really easily.


OK. I don't think we're doing this, but after Xiaogang raised the 
question I went looking through the code whether it's theoretically 
possible. I didn't find anything in the code that says that mmapping 
imported dmabufs would be prohibited or even dangerous. On the 
contrary, I found that ttm_bo_vm explicitly supports mmapping SG BOs.





When you have imported a BO the only correct way of to mmap() it is 
to do so on the original exporter.


That seems sensible, and this is what we do today. That said, if 
mmapping an imported BO is dangerous, I'm missing a mechanism to 
protect against this. It could be as simple as setting 
AMDGPU_GEM_CREATE_NO_CPU_ACCESS in amdgpu_dma_buf_create_obj.


At least for the GEM mmap() handler this is double checked very early 
by looking at obj->import_attach and then either rejecting it or 
redirecting the request to the DMA-buf file instead.


Can you point me at where this check is? I see a check for 
obj->import_attach in drm_gem_dumb_map_offset. But I can't see how this 
function is called in amdgpu. I don't think it is used at all.





We probably need something similar when stuff is mapped through the 
KFD node. But I think we don't do that any more for "normal" BOs 
anyway, don't we?


Correct, we don't map BOs through the KFD device file. The only mappings 
we still use it for are:


 * Doorbells on APUs
 * Events page on APUs
 * MMIO page for HDP flushing

The code for mmapping regular BOs through /dev/kfd was never upstream.

Regards,
  Felix




Regards,
Christian.



Regards,
  Felix




Re: [PATCH] drm/amd/display: Fix COLOR_SPACE_YCBCR2020_TYPE matrix

2023-01-16 Thread Melissa Wen

On 01/10, Joshua Ashton wrote:

The YCC conversion matrix for RGB -> COLOR_SPACE_YCBCR2020_TYPE is
missing the values for the fourth column of the matrix.

The fourth column of the matrix is essentially just a value that is
added given that the color is 3 components in size.
These values are needed to bias the chroma from the [-1, 1] -> [0, 1]
range.

This fixes color being very green when using Gamescope HDR on HDMI
output which prefers YCC 4:4:4.

Signed-off-by: Joshua Ashton 
---
 drivers/gpu/drm/amd/display/dc/core/dc_hw_sequencer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 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..652270a0b498 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
@@ -90,8 +90,8 @@ static const struct out_csc_color_matrix_type 
output_csc_matrix[] = {
{ 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, 0x1004, 0x0868, 0x15B2,
+   0x01E6, 0x201, 0xFB88, 0xF478, 0x1000, 0x1004} 
},


LGTM.

I'd also add a fixes tag here to:

Fixes: 40df2f809e8f ("drm/amd/display: color space ycbcr709 support")

Thanks,

Reviewed-by: Melissa Wen 


{ COLOR_SPACE_YCBCR709_BLACK_TYPE,
{ 0x, 0x, 0x, 0x1000, 0x, 0x,
0x, 0x0200, 0x, 0x, 0x, 0x1000} 
},
--
2.39.0





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

2023-01-16 Thread Melissa Wen
On 01/16, Melissa Wen wrote:
> On 01/10, Joshua Ashton wrote:
> > 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.
> > 
> > v2: Fixed patch being accidentally based on a personal feature branch, oops!
> > 
> > Signed-off-by: Joshua Ashton 
> > ---
> >  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 b4d60eedbcbf..9da71ee8fcc4 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);
> > -
> > 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);
> 
> LGTM.
> 
> I see that we were ignoring the updated value of pixel_encoding in the
> previous point. Nice catch!
> 
> Reviewed-by: Melissa Wen 

BTW, I think it deserves a fixes tag to:

Fixes: ea117312ea9f ("drm/amd/display: Reduce HDMI pixel encoding if max clock 
is exceeded")

> 
> >  }
> >  
> >  static void fill_audio_info(struct audio_info *audio_info,
> > -- 
> > 2.39.0
> > 




signature.asc
Description: PGP signature


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

2023-01-16 Thread Melissa Wen
On 01/10, Joshua Ashton wrote:
> 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.
> 
> v2: Fixed patch being accidentally based on a personal feature branch, oops!
> 
> Signed-off-by: Joshua Ashton 
> ---
>  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 b4d60eedbcbf..9da71ee8fcc4 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);
> -
>   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);

LGTM.

I see that we were ignoring the updated value of pixel_encoding in the
previous point. Nice catch!

Reviewed-by: Melissa Wen 

>  }
>  
>  static void fill_audio_info(struct audio_info *audio_info,
> -- 
> 2.39.0
> 


signature.asc
Description: PGP signature


RE: [PATCH 1/3] drm/amd: Adjust legacy IP discovery for Picasso/Raven/Raven2

2023-01-16 Thread Limonciello, Mario
[Public]



> -Original Message-
> From: Alex Deucher 
> Sent: Monday, January 16, 2023 07:51
> To: Limonciello, Mario 
> Cc: amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 1/3] drm/amd: Adjust legacy IP discovery for
> Picasso/Raven/Raven2
> 
> On Sun, Jan 15, 2023 at 2:22 PM Mario Limonciello
>  wrote:
> >
> > The switch/case statement currently combines 10.0.0 and 10.0.1, but
> > 10.0.1 is only used for Raven 2.  So split the two cases up to
> > make this clearer.
> 
> Keep the logic as is.  We don't know the revision id which is used to
> differentiate the raven variants until after IP discovery so we can't
> assign the proper IP versions for each raven variant and raven asics
> don't have an IP discovery table (it's hardcoded in
> amdgpu_discovery.c).
> 

Got it thanks, will drop this patch.

> Alex
> 
> >
> > Signed-off-by: Mario Limonciello 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > index c03824d0311bd..0d950ae14b27c 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> > @@ -1074,15 +1074,11 @@ static const char
> *amdgpu_ucode_legacy_naming(struct amdgpu_device *adev, int bl
> > }
> > break;
> > case IP_VERSION(10, 0, 0):
> > +   if (adev->apu_flags & AMD_APU_IS_PICASSO)
> > +   return "picasso";
> > +   return "raven";
> > case IP_VERSION(10, 0, 1):
> > -   if (adev->asic_type == CHIP_RAVEN) {
> > -   if (adev->apu_flags & AMD_APU_IS_RAVEN2)
> > -   return "raven2";
> > -   else if (adev->apu_flags & 
> > AMD_APU_IS_PICASSO)
> > -   return "picasso";
> > -   return "raven";
> > -   }
> > -   break;
> > +   return "raven2";
> > case IP_VERSION(11, 0, 0):
> > return "navi10";
> > case IP_VERSION(11, 0, 2):
> > --
> > 2.25.1
> >


[PATCH AUTOSEL 6.1 36/53] drm/amdkfd: Fix NULL pointer error for GC 11.0.1 on mGPU

2023-01-16 Thread Sasha Levin
From: Eric Huang 

[ Upstream commit a6941f89d7c6a6ba49316bbd7da2fb2f719119a7 ]

The point bo->kfd_bo is NULL for queue's write pointer BO
when creating queue on mGPU. To avoid using the pointer
fixes the error.

Signed-off-by: Eric Huang 
Reviewed-by: Felix Kuehling 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index 29f045079a3e..404c839683b1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -2130,7 +2130,7 @@ int amdgpu_amdkfd_map_gtt_bo_to_gart(struct amdgpu_device 
*adev, struct amdgpu_b
}
 
amdgpu_amdkfd_remove_eviction_fence(
-   bo, bo->kfd_bo->process_info->eviction_fence);
+   bo, bo->vm_bo->vm->process_info->eviction_fence);
 
amdgpu_bo_unreserve(bo);
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index ecb4c3abc629..c06ada0844ba 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -200,7 +200,7 @@ static int add_queue_mes(struct device_queue_manager *dqm, 
struct queue *q,
queue_input.wptr_addr = (uint64_t)q->properties.write_ptr;
 
if (q->wptr_bo) {
-   wptr_addr_off = (uint64_t)q->properties.write_ptr - 
(uint64_t)q->wptr_bo->kfd_bo->va;
+   wptr_addr_off = (uint64_t)q->properties.write_ptr & (PAGE_SIZE 
- 1);
queue_input.wptr_mc_addr = 
((uint64_t)q->wptr_bo->tbo.resource->start << PAGE_SHIFT) + wptr_addr_off;
}
 
-- 
2.35.1



[PATCH AUTOSEL 6.1 35/53] drm/amdkfd: Add sync after creating vram bo

2023-01-16 Thread Sasha Levin
From: Eric Huang 

[ Upstream commit ba029e9991d9be90a28b6a0ceb25e9a6fb348829 ]

There will be data corruption on vram allocated by svm
if the initialization is not complete and application is
writting on the memory. Adding sync to wait for the
initialization completion is to resolve this issue.

Signed-off-by: Eric Huang 
Reviewed-by: Felix Kuehling 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 64fdf63093a0..63feea08904c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -570,6 +570,15 @@ svm_range_vram_node_new(struct amdgpu_device *adev, struct 
svm_range *prange,
goto reserve_bo_failed;
}
 
+   if (clear) {
+   r = amdgpu_bo_sync_wait(bo, AMDGPU_FENCE_OWNER_KFD, false);
+   if (r) {
+   pr_debug("failed %d to sync bo\n", r);
+   amdgpu_bo_unreserve(bo);
+   goto reserve_bo_failed;
+   }
+   }
+
r = dma_resv_reserve_fences(bo->tbo.base.resv, 1);
if (r) {
pr_debug("failed %d to reserve bo\n", r);
-- 
2.35.1



Re: [PATCH 1/3] drm/amd: Adjust legacy IP discovery for Picasso/Raven/Raven2

2023-01-16 Thread Alex Deucher
On Sun, Jan 15, 2023 at 2:22 PM Mario Limonciello
 wrote:
>
> The switch/case statement currently combines 10.0.0 and 10.0.1, but
> 10.0.1 is only used for Raven 2.  So split the two cases up to
> make this clearer.

Keep the logic as is.  We don't know the revision id which is used to
differentiate the raven variants until after IP discovery so we can't
assign the proper IP versions for each raven variant and raven asics
don't have an IP discovery table (it's hardcoded in
amdgpu_discovery.c).

Alex

>
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> index c03824d0311bd..0d950ae14b27c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
> @@ -1074,15 +1074,11 @@ static const char *amdgpu_ucode_legacy_naming(struct 
> amdgpu_device *adev, int bl
> }
> break;
> case IP_VERSION(10, 0, 0):
> +   if (adev->apu_flags & AMD_APU_IS_PICASSO)
> +   return "picasso";
> +   return "raven";
> case IP_VERSION(10, 0, 1):
> -   if (adev->asic_type == CHIP_RAVEN) {
> -   if (adev->apu_flags & AMD_APU_IS_RAVEN2)
> -   return "raven2";
> -   else if (adev->apu_flags & AMD_APU_IS_PICASSO)
> -   return "picasso";
> -   return "raven";
> -   }
> -   break;
> +   return "raven2";
> case IP_VERSION(11, 0, 0):
> return "navi10";
> case IP_VERSION(11, 0, 2):
> --
> 2.25.1
>


Re: [PATCH] drm/amd/display: Simplify same effect if/else blocks

2023-01-16 Thread Joe Perches
On Sun, 2023-01-15 at 15:30 +0530, Deepak R Varma wrote:
> The if / else block code has same effect irrespective of the logical
> evaluation.  Hence, simply the implementation by removing the unnecessary
> conditional evaluation. While at it, also fix the long line checkpatch
> complaint. Issue identified using cond_no_effect.cocci Coccinelle
> semantic patch script.
> 
> Signed-off-by: Deepak R Varma 
> ---
> Please note: The proposed change is compile tested only. If there are any
> inbuilt test cases that I should run for further verification, I will 
> appreciate
> guidance about it. Thank you.

Preface: I do not know the code.

Perhaps Rodrigo Siqueira made a copy/paste error submitting the code for
commit 9114b55fabae ("drm/amd/display: Fix SubVP control flow in the MPO 
context")
as the code prior to this change is identical.

Perhaps one of the false uses should be true or dependent on the
interdependent_update_lock state.

> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
[]
> @@ -3470,14 +3470,9 @@ static void commit_planes_for_stream(struct dc *dc,
>   /* Since phantom pipe programming is moved to 
> post_unlock_program_front_end,
>* move the SubVP lock to after the phantom pipes have been 
> setup
>*/
> - if (should_lock_all_pipes && 
> dc->hwss.interdependent_update_lock) {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context, 
> false, should_lock_all_pipes, NULL, subvp_prev_use);
> - } else {
> - if (dc->hwss.subvp_pipe_control_lock)
> - dc->hwss.subvp_pipe_control_lock(dc, context, 
> false, should_lock_all_pipes, NULL, subvp_prev_use);
> - }
> -

Perhaps something like:

if (dc->hwss.subvp_pipe_control_lock)
dc->hwss.subvp_pipe_control_lock(dc, context,
 should_lock_all_pipes 
&&
 
dc->hwss.interdependent_update_lock,
 should_lock_all_pipes, 
NULL, subvp_prev_use);

> + if (dc->hwss.subvp_pipe_control_lock)
> + dc->hwss.subvp_pipe_control_lock(dc, context, false, 
> should_lock_all_pipes,
> +  NULL, subvp_prev_use);
>   return;
>   }
>  



[PATCH 18/22] drm/sun4i: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c 
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
index 477cb6985b4d..37dc66332bbd 100644
--- a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -8,8 +8,8 @@
 #include 
 #include 
 
-#include 
 #include 
+#include 
 #include 
 
 #include "sun8i_dw_hdmi.h"
-- 
2.39.0



[PATCH 16/22] drm/shmobile: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/shmobile/shmob_drm_crtc.c  | 2 ++
 drivers/gpu/drm/shmobile/shmob_drm_drv.c   | 1 -
 drivers/gpu/drm/shmobile/shmob_drm_plane.c | 1 -
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c 
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index 4624c0aff51f..d354ab3077ce 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c 
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 337040fa6438..faacfee24763 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_plane.c 
b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
index 6c5f0cbe7d95..604ae23825da 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_plane.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_plane.c
@@ -8,7 +8,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 15/22] drm/rockchip: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 8cecf81a5ae0..ba3b81789509 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -25,7 +25,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 10/22] drm/ingenic: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c 
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 3d5af44bf92d..5ec75e9ba499 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 19/22] drm/tidss: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tidss/tidss_crtc.c| 1 -
 drivers/gpu/drm/tidss/tidss_drv.c | 1 -
 drivers/gpu/drm/tidss/tidss_encoder.c | 2 +-
 drivers/gpu/drm/tidss/tidss_kms.c | 1 -
 drivers/gpu/drm/tidss/tidss_plane.c   | 1 -
 5 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c 
b/drivers/gpu/drm/tidss/tidss_crtc.c
index cd3c43a6c806..5e5e466f35d1 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.c
+++ b/drivers/gpu/drm/tidss/tidss_crtc.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c 
b/drivers/gpu/drm/tidss/tidss_drv.c
index 07d94b1e8089..2dac8727d2f4 100644
--- a/drivers/gpu/drm/tidss/tidss_drv.c
+++ b/drivers/gpu/drm/tidss/tidss_drv.c
@@ -12,7 +12,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/tidss/tidss_encoder.c 
b/drivers/gpu/drm/tidss/tidss_encoder.c
index e278a9c89476..0d4865e9c03d 100644
--- a/drivers/gpu/drm/tidss/tidss_encoder.c
+++ b/drivers/gpu/drm/tidss/tidss_encoder.c
@@ -7,7 +7,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/tidss/tidss_kms.c 
b/drivers/gpu/drm/tidss/tidss_kms.c
index 345bcc3011e4..ad2fa3c3d4a7 100644
--- a/drivers/gpu/drm/tidss/tidss_kms.c
+++ b/drivers/gpu/drm/tidss/tidss_kms.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c 
b/drivers/gpu/drm/tidss/tidss_plane.c
index 42d50ec5526d..fe2c41f0cd4f 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 09/22] drm/i2c/ch7006: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/i2c/ch7006_drv.c  | 2 ++
 drivers/gpu/drm/i2c/ch7006_priv.h | 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index 923389f22020..521bdf656cca 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -26,6 +26,8 @@
 
 #include 
 
+#include 
+
 #include "ch7006_priv.h"
 
 /* DRM encoder functions */
diff --git a/drivers/gpu/drm/i2c/ch7006_priv.h 
b/drivers/gpu/drm/i2c/ch7006_priv.h
index 986b04599906..052bdc48a339 100644
--- a/drivers/gpu/drm/i2c/ch7006_priv.h
+++ b/drivers/gpu/drm/i2c/ch7006_priv.h
@@ -27,7 +27,6 @@
 #ifndef __DRM_I2C_CH7006_PRIV_H__
 #define __DRM_I2C_CH7006_PRIV_H__
 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 22/22] drm/crtc-helper: Remove most include statements from drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Remove most include statements from crm_crtc_helper.h and forward-
declare the contained types in drm_crtc_helper.h. Only keep 
for the definition of 'bool'.

Suggested-by: Sam Ravnborg 
Signed-off-by: Thomas Zimmermann 
---
 include/drm/drm_crtc_helper.h | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 072bc4f90349..8c886fc46ef2 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -33,13 +33,17 @@
 #ifndef __DRM_CRTC_HELPER_H__
 #define __DRM_CRTC_HELPER_H__
 
-#include 
 #include 
-#include 
 
-#include 
-#include 
-#include 
+struct drm_atomic_state;
+struct drm_connector;
+struct drm_crtc;
+struct drm_device;
+struct drm_display_mode;
+struct drm_encoder;
+struct drm_framebuffer;
+struct drm_mode_set;
+struct drm_modeset_acquire_ctx;
 
 void drm_helper_disable_unused_functions(struct drm_device *dev);
 int drm_crtc_helper_set_config(struct drm_mode_set *set,
-- 
2.39.0



[PATCH 12/22] drm/logicvc: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/logicvc/logicvc_interface.c | 1 -
 drivers/gpu/drm/logicvc/logicvc_mode.c  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/logicvc/logicvc_interface.c 
b/drivers/gpu/drm/logicvc/logicvc_interface.c
index 815cebb4c4ca..689049d395c0 100644
--- a/drivers/gpu/drm/logicvc/logicvc_interface.c
+++ b/drivers/gpu/drm/logicvc/logicvc_interface.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/logicvc/logicvc_mode.c 
b/drivers/gpu/drm/logicvc/logicvc_mode.c
index 9971950ebd4e..3cf04b70bd27 100644
--- a/drivers/gpu/drm/logicvc/logicvc_mode.c
+++ b/drivers/gpu/drm/logicvc/logicvc_mode.c
@@ -8,7 +8,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 11/22] drm/kmb: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/kmb/kmb_crtc.c  | 1 -
 drivers/gpu/drm/kmb/kmb_plane.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/kmb/kmb_crtc.c b/drivers/gpu/drm/kmb/kmb_crtc.c
index 06613ffeaaf8..647872f65bff 100644
--- a/drivers/gpu/drm/kmb/kmb_crtc.c
+++ b/drivers/gpu/drm/kmb/kmb_crtc.c
@@ -8,7 +8,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/kmb/kmb_plane.c b/drivers/gpu/drm/kmb/kmb_plane.c
index d172a302f902..9e0562aa2bcb 100644
--- a/drivers/gpu/drm/kmb/kmb_plane.c
+++ b/drivers/gpu/drm/kmb/kmb_plane.c
@@ -7,7 +7,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 20/22] drm/udl: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/udl/udl_drv.c | 2 +-
 drivers/gpu/drm/udl/udl_modeset.c | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index e81352126a0f..1506094a8009 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -5,12 +5,12 @@
 
 #include 
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/udl/udl_modeset.c 
b/drivers/gpu/drm/udl/udl_modeset.c
index 4b79d44752c9..aa02fd2789c3 100644
--- a/drivers/gpu/drm/udl/udl_modeset.c
+++ b/drivers/gpu/drm/udl/udl_modeset.c
@@ -12,7 +12,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 17/22] drm/sprd: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/sprd/sprd_dpu.c | 1 -
 drivers/gpu/drm/sprd/sprd_drm.c | 1 -
 drivers/gpu/drm/sprd/sprd_dsi.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c b/drivers/gpu/drm/sprd/sprd_dpu.c
index db0bcea1d9f4..b96fc6837b0d 100644
--- a/drivers/gpu/drm/sprd/sprd_dpu.c
+++ b/drivers/gpu/drm/sprd/sprd_dpu.c
@@ -18,7 +18,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/sprd/sprd_drm.c b/drivers/gpu/drm/sprd/sprd_drm.c
index 9d42f17a5734..be60c0d546a3 100644
--- a/drivers/gpu/drm/sprd/sprd_drm.c
+++ b/drivers/gpu/drm/sprd/sprd_drm.c
@@ -11,7 +11,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/sprd/sprd_dsi.c b/drivers/gpu/drm/sprd/sprd_dsi.c
index 12b67a5d5923..ab0e5cce7adb 100644
--- a/drivers/gpu/drm/sprd/sprd_dsi.c
+++ b/drivers/gpu/drm/sprd/sprd_dsi.c
@@ -13,7 +13,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
2.39.0



[PATCH 21/22] drm/vboxvideo: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/vboxvideo/vbox_drv.c  | 2 +-
 drivers/gpu/drm/vboxvideo/vbox_main.c | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c 
b/drivers/gpu/drm/vboxvideo/vbox_drv.c
index 12fee99dbfe8..4fee15c97c34 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
@@ -12,12 +12,12 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "vbox_drv.h"
diff --git a/drivers/gpu/drm/vboxvideo/vbox_main.c 
b/drivers/gpu/drm/vboxvideo/vbox_main.c
index 3b83e550f4df..42c2d8a99509 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_main.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_main.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include "vbox_drv.h"
-- 
2.39.0



[PATCH 08/22] drm/gma500: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/gma500/cdv_device.c| 1 +
 drivers/gpu/drm/gma500/cdv_intel_crt.c | 2 ++
 drivers/gpu/drm/gma500/cdv_intel_display.c | 1 +
 drivers/gpu/drm/gma500/cdv_intel_dp.c  | 1 +
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c| 2 ++
 drivers/gpu/drm/gma500/cdv_intel_lvds.c| 2 ++
 drivers/gpu/drm/gma500/framebuffer.c   | 2 ++
 drivers/gpu/drm/gma500/gma_display.c   | 2 ++
 drivers/gpu/drm/gma500/oaktrail_crtc.c | 1 +
 drivers/gpu/drm/gma500/oaktrail_hdmi.c | 2 ++
 drivers/gpu/drm/gma500/oaktrail_lvds.c | 1 +
 drivers/gpu/drm/gma500/psb_device.c| 1 +
 drivers/gpu/drm/gma500/psb_intel_display.c | 3 +++
 drivers/gpu/drm/gma500/psb_intel_drv.h | 1 -
 drivers/gpu/drm/gma500/psb_intel_lvds.c| 2 ++
 drivers/gpu/drm/gma500/psb_intel_sdvo.c| 2 ++
 16 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/cdv_device.c 
b/drivers/gpu/drm/gma500/cdv_device.c
index 3065596257e9..3e83299113e3 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -8,6 +8,7 @@
 #include 
 
 #include 
+#include 
 
 #include "cdv_device.h"
 #include "gma_device.h"
diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 7ff1e5141150..5a0acd914f76 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
 
 #include "cdv_device.h"
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c 
b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 0c3ddcdc29dc..bbd0abdd8382 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -10,6 +10,7 @@
 #include 
 
 #include 
+#include 
 
 #include "cdv_device.h"
 #include "framebuffer.h"
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c 
b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index 53b967282d6a..8992a95076f2 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "gma_display.h"
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c 
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 29ef45f14169..2d95e0471291 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -28,7 +28,9 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include "cdv_device.h"
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c 
b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index be6efcaaa3b3..f08a6803dc18 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -12,6 +12,8 @@
 #include 
 #include 
 
+#include 
+#include 
 #include 
 
 #include "cdv_device.h"
diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 9e892a82e109..52ae3ade9a61 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -19,10 +19,12 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #include "framebuffer.h"
 #include "gem.h"
diff --git a/drivers/gpu/drm/gma500/gma_display.c 
b/drivers/gpu/drm/gma500/gma_display.c
index fe7b8436f87a..f65e90d890f4 100644
--- a/drivers/gpu/drm/gma500/gma_display.c
+++ b/drivers/gpu/drm/gma500/gma_display.c
@@ -11,8 +11,10 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
+#include 
 #include 
 
 #include "framebuffer.h"
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index 64761f46b434..de8ccfe9890f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 #include "framebuffer.h"
 #include "gem.h"
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 95b7cb099e63..ed8626c73541 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -27,7 +27,9 @@
 #include 
 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include "psb_drv.h"
diff --git a/drivers/gpu/drm/gma500/oaktrail_lvds.c 
b/drivers/gpu/drm/gma500/oaktrail_lvds.c
index 75b4eb1c8884..d974d0c60d2a 100644
--- a/drivers/gpu/drm/gma500/oaktrail_lvds.c
+++ b/drivers/gpu/drm/gma500/oaktrail_lvds.c
@@ -14,6 +14,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 #include "intel_bios.h"
diff --git a/drivers/gpu/drm/gma500/psb_device.c 
b/drivers/gpu/drm/gma500/psb_device.c
index 3c294c38bdb4..dcfcd7b89d4a 100644
--- a/drivers/gpu/drm/gma500/psb_device.c
+++ 

[PATCH 13/22] drm/nouveau: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/nouveau/dispnv04/crtc.c| 1 +
 drivers/gpu/drm/nouveau/dispnv04/dac.c | 2 +-
 drivers/gpu/drm/nouveau/dispnv04/dfp.c | 2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.c | 1 -
 drivers/gpu/drm/nouveau/dispnv04/tvnv04.c  | 2 +-
 drivers/gpu/drm/nouveau/dispnv04/tvnv17.c  | 1 +
 drivers/gpu/drm/nouveau/dispnv50/head.c| 1 -
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 1 -
 drivers/gpu/drm/nouveau/nouveau_vga.c  | 1 -
 9 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c 
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index ca6d07d8c2c6..a6f2e681bde9 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -24,6 +24,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c 
b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index 22d10f328559..d6b8e0cce2ac 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -24,7 +24,7 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
-#include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_encoder.h"
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c 
b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index ce3d8c6ef000..d5b129dc623b 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -24,8 +24,8 @@
  * DEALINGS IN THE SOFTWARE.
  */
 
-#include 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_reg.h"
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.c
index 2f6d2b6711ab..a3fedd226854 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvmodesnv17.c
@@ -24,7 +24,6 @@
  *
  */
 
-#include 
 #include "nouveau_drv.h"
 #include "nouveau_encoder.h"
 #include "nouveau_crtc.h"
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
index 3ba7b59580d5..de3ea731d6e6 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
@@ -30,7 +30,7 @@
 #include "nouveau_connector.h"
 #include "nouveau_crtc.h"
 #include "hw.h"
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index e5480dab55e3..670c9739e5e1 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -25,6 +25,7 @@
  */
 
 #include 
+#include 
 #include 
 #include "nouveau_drv.h"
 #include "nouveau_reg.h"
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c 
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index f006e56e1e08..5f490fbf1877 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -32,7 +32,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include "nouveau_connector.h"
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 574a8abf6a1d..cc7c5b4a05fd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -31,7 +31,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index 789393b94291..f8bf0ec26844 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -2,7 +2,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include "nouveau_drv.h"
-- 
2.39.0



[PATCH 04/22] drm/arm/komeda: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 1 -
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 4cc07d6bb9d8..cea3fd5772b5 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -10,7 +10,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 7339339ef6b8..3a872c292091 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 07/22] drm/bridge: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c  | 1 -
 drivers/gpu/drm/bridge/analogix/anx7625.c   | 1 -
 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c | 1 -
 drivers/gpu/drm/bridge/ite-it6505.c | 1 -
 drivers/gpu/drm/bridge/ite-it66121.c| 1 -
 drivers/gpu/drm/bridge/tc358768.c   | 1 -
 drivers/gpu/drm/bridge/tc358775.c   | 1 -
 7 files changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c 
b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
index 339e0f05b260..3577c532abb4 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c 
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index b375887e655d..6846199a2ee1 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c 
b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
index 31442a922502..f6822dfa3805 100644
--- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
+++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
@@ -43,7 +43,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
index 9cda2df21b88..bc451b2a77c2 100644
--- a/drivers/gpu/drm/bridge/ite-it6505.c
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -26,7 +26,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/ite-it66121.c 
b/drivers/gpu/drm/bridge/ite-it66121.c
index b34860871627..a2d723d6a4be 100644
--- a/drivers/gpu/drm/bridge/ite-it66121.c
+++ b/drivers/gpu/drm/bridge/ite-it66121.c
@@ -22,7 +22,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/tc358768.c 
b/drivers/gpu/drm/bridge/tc358768.c
index 839b8832b9b5..7c0cbe84611b 100644
--- a/drivers/gpu/drm/bridge/tc358768.c
+++ b/drivers/gpu/drm/bridge/tc358768.c
@@ -15,7 +15,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/bridge/tc358775.c 
b/drivers/gpu/drm/bridge/tc358775.c
index 91b5e1207c47..19316994ddd1 100644
--- a/drivers/gpu/drm/bridge/tc358775.c
+++ b/drivers/gpu/drm/bridge/tc358775.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 14/22] drm/radeon: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/radeon/atombios_crtc.c  | 2 +-
 drivers/gpu/drm/radeon/atombios_encoders.c  | 1 +
 drivers/gpu/drm/radeon/r300.c   | 1 -
 drivers/gpu/drm/radeon/radeon_asic.c| 1 -
 drivers/gpu/drm/radeon/radeon_connectors.c  | 1 +
 drivers/gpu/drm/radeon/radeon_display.c | 1 +
 drivers/gpu/drm/radeon/radeon_drv.c | 1 -
 drivers/gpu/drm/radeon/radeon_encoders.c| 1 -
 drivers/gpu/drm/radeon/radeon_irq_kms.c | 1 -
 drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 2 +-
 drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 2 +-
 drivers/gpu/drm/radeon/radeon_legacy_tv.c   | 1 -
 drivers/gpu/drm/radeon/radeon_mode.h| 2 +-
 13 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c 
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 6844e080e3be..ade13173921b 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -24,10 +24,10 @@
  *  Alex Deucher
  */
 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index c841c273222e..1471c3a96602 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -30,6 +30,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 621ff174dff3..7b0cfeaddcec 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -31,7 +31,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c 
b/drivers/gpu/drm/radeon/radeon_asic.c
index bfacf8fe5cc1..802b5af19261 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include "atom.h"
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index f44d5a2b5baa..07193cd0c417 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "radeon.h"
diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 9bed1a6cb163..f34a7f63261d 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 0e8148fca8b7..716ab85a376b 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -38,7 +38,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c 
b/drivers/gpu/drm/radeon/radeon_encoders.c
index fbc0a2182318..b3518a8f95a0 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -26,7 +26,6 @@
 
 #include 
 
-#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c 
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index da2173435edd..3377fbc71f65 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c 
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index eef35872a72e..825b351ff53c 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -24,10 +24,10 @@
  *  Alex Deucher
  */
 
-#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 0cd32c65456c..601d35d34eab 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -27,9 +27,9 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c 
b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
index d9df7f311e76..12e180b119ac 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -1,6 +1,5 @@
 // SPDX-License-Identifier: MIT
 
-#include 
 #include 
 
 #include "radeon.h"
diff --git 

[PATCH 05/22] drm/aspeed: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 1 -
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c  | 1 -
 drivers/gpu/drm/aspeed/aspeed_gfx_out.c  | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c 
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index 55a3444a51d8..7877a57b8e26 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -5,7 +5,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 
b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
index 718119e168a6..ecfb060d2557 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
@@ -14,7 +14,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c 
b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
index 4f2187025a21..78775e0c853f 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_out.c
@@ -3,7 +3,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
2.39.0



[PATCH 01/22] drm/amdgpu: Fix coding style

2023-01-16 Thread Thomas Zimmermann
Align a closing brace and remove trailing whitespaces. No functional
changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index e47058c2c294..0993ee91fe18 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -5871,8 +5871,8 @@ void amdgpu_device_invalidate_hdp(struct amdgpu_device 
*adev,
 int amdgpu_in_reset(struct amdgpu_device *adev)
 {
return atomic_read(>reset_domain->in_gpu_reset);
-   }
-   
+}
+
 /**
  * amdgpu_device_halt() - bring hardware to some kind of halt state
  *
-- 
2.39.0



[PATCH 02/22] drm: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several DRM core and helper source files include drm_crtc_helper.h
without needing it or only to get its transitive include statements;
leading to unnecessary compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible. The header file, drm_fixed.h, includes 
for lower_32_bits().

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/drm_crtc_helper.c  | 1 -
 drivers/gpu/drm/drm_lease.c| 2 +-
 drivers/gpu/drm/drm_plane_helper.c | 1 -
 include/drm/drm_fixed.h| 1 +
 4 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index a209659a996c..e7a23e18140c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -39,7 +39,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 08ab75303a00..150fe1555068 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -6,7 +6,7 @@
 #include 
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index ba6a9136a065..c91e454eba09 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h
index 553210c02ee0..255645c1f9a8 100644
--- a/include/drm/drm_fixed.h
+++ b/include/drm/drm_fixed.h
@@ -25,6 +25,7 @@
 #ifndef DRM_FIXED_H
 #define DRM_FIXED_H
 
+#include 
 #include 
 
 typedef union dfixed {
-- 
2.39.0



[PATCH 06/22] drm/ast: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/ast/ast_drv.c  | 1 -
 drivers/gpu/drm/ast/ast_main.c | 1 -
 drivers/gpu/drm/ast/ast_mode.c | 1 -
 3 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 420fc75c240e..d78852c7cf5b 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -31,7 +31,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index bffa310a0431..f83ce77127cb 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -29,7 +29,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index e82e9a8d85e5..dcb8ced4ce75 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.39.0



[PATCH 03/22] drm/amdgpu: Remove unnecessary include statements for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
Several source files include drm_crtc_helper.h without needing it or
only to get its transitive include statements; leading to unnecessary
compile-time dependencies.

Directly include required headers and drop drm_crtc_helper.h where
possible.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c| 1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c   | 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c| 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   | 1 -
 drivers/gpu/drm/amd/amdgpu/atombios_crtc.c | 1 -
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 1 -
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 ++
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 ++
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 2 ++
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  | 2 ++
 12 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 2ebbc6382a06..3c962d0214cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -25,7 +25,9 @@
  */
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 0993ee91fe18..63122482208d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index b22471b3bd63..c5b98e9a69e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c
index c96e458ed088..27a782a9dc72 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c
@@ -24,7 +24,6 @@
  *  Alex Deucher
  */
 
-#include 
 #include 
 #include "amdgpu.h"
 #include "amdgpu_connectors.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
index a6aef488a822..d0a1cc88832c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
@@ -45,7 +45,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 8a39300b1a84..cf4b6e8d7d1e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
index afad094f84c2..10098fdd33fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_crtc.c
@@ -24,7 +24,6 @@
  *  Alex Deucher
  */
 
-#include 
 #include 
 #include 
 #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index 18ae9433e463..d95b2dc78063 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -28,7 +28,6 @@
 
 #include 
 
-#include 
 #include 
 #include "amdgpu.h"
 #include "amdgpu_connectors.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index a2452fc304c5..01d1e2a631be 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -22,6 +22,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 
 #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 6ac680c4c6e2..973abe989ebe 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -22,6 +22,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 
 #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index 354ae09cc9a2..86e95b1c9d0e 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -24,6 +24,8 @@
 #include 
 
 #include 
+#include 
+#include 
 #include 
 
 #include "amdgpu.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 33977b0ba19d..f81f1d5d3e8a 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
@@ -22,6 +22,8 @@
  */
 
 #include 
+#include 
+#include 
 #include 
 
 #include 

[PATCH 00/22] drm: Remove includes for drm_crtc_helper.h

2023-01-16 Thread Thomas Zimmermann
A lot of source files include drm_crtc_helper.h for its contained
include statements. This leads to excessive compile-time dependencies.

Where possible, remove the include statements for drm_crtc_helper.h
and include the required source files directly. Also remove the
include statements from drm_crtc_helper.h itself, which doesn't need
most of them.

I built this patchset on x86-64, aarch64 and arm. Hopefully I found
all include dependencies.

Thanks to Sam Ravnborg for bringing this to my attention.

Thomas Zimmermann (22):
  drm/amdgpu: Fix coding style
  drm: Remove unnecessary include statements for drm_crtc_helper.h
  drm/amdgpu: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/arm/komeda: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/aspeed: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/ast: Remove unnecessary include statements for drm_crtc_helper.h
  drm/bridge: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/gma500: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/i2c/ch7006: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/ingenic: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/kmb: Remove unnecessary include statements for drm_crtc_helper.h
  drm/logicvc: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/nouveau: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/radeon: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/rockchip: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/shmobile: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/sprd: Remove unnecessary include statements for drm_crtc_helper.h
  drm/sun4i: Remove unnecessary include statements for drm_crtc_helper.h
  drm/tidss: Remove unnecessary include statements for drm_crtc_helper.h
  drm/udl: Remove unnecessary include statements for drm_crtc_helper.h
  drm/vboxvideo: Remove unnecessary include statements for
drm_crtc_helper.h
  drm/crtc-helper: Remove most include statements from drm_crtc_helper.h

 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  5 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c|  1 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c   |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c|  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |  1 -
 drivers/gpu/drm/amd/amdgpu/atombios_crtc.c |  1 -
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c |  1 -
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c |  2 ++
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |  2 ++
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  |  2 ++
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c  |  2 ++
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   |  1 -
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h|  1 -
 drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c   |  1 -
 drivers/gpu/drm/aspeed/aspeed_gfx_drv.c|  1 -
 drivers/gpu/drm/aspeed/aspeed_gfx_out.c|  1 -
 drivers/gpu/drm/ast/ast_drv.c  |  1 -
 drivers/gpu/drm/ast/ast_main.c |  1 -
 drivers/gpu/drm/ast/ast_mode.c |  1 -
 drivers/gpu/drm/bridge/analogix/analogix-anx6345.c |  1 -
 drivers/gpu/drm/bridge/analogix/anx7625.c  |  1 -
 .../gpu/drm/bridge/cadence/cdns-mhdp8546-core.c|  1 -
 drivers/gpu/drm/bridge/ite-it6505.c|  1 -
 drivers/gpu/drm/bridge/ite-it66121.c   |  1 -
 drivers/gpu/drm/bridge/tc358768.c  |  1 -
 drivers/gpu/drm/bridge/tc358775.c  |  1 -
 drivers/gpu/drm/drm_crtc_helper.c  |  1 -
 drivers/gpu/drm/drm_lease.c|  2 +-
 drivers/gpu/drm/drm_plane_helper.c |  1 -
 drivers/gpu/drm/gma500/cdv_device.c|  1 +
 drivers/gpu/drm/gma500/cdv_intel_crt.c |  2 ++
 drivers/gpu/drm/gma500/cdv_intel_display.c |  1 +
 drivers/gpu/drm/gma500/cdv_intel_dp.c  |  1 +
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|  2 ++
 drivers/gpu/drm/gma500/cdv_intel_lvds.c|  2 ++
 drivers/gpu/drm/gma500/framebuffer.c   |  2 ++
 drivers/gpu/drm/gma500/gma_display.c   |  2 ++
 drivers/gpu/drm/gma500/oaktrail_crtc.c |  1 +
 drivers/gpu/drm/gma500/oaktrail_hdmi.c |  2 ++
 drivers/gpu/drm/gma500/oaktrail_lvds.c |  1 +
 drivers/gpu/drm/gma500/psb_device.c|  1 +
 drivers/gpu/drm/gma500/psb_intel_display.c |  3 +++
 drivers/gpu/drm/gma500/psb_intel_drv.h |  1 -
 drivers/gpu/drm/gma500/psb_intel_lvds.c|  2 ++
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|  2 ++
 drivers/gpu/drm/i2c/ch7006_drv.c   |  2 ++
 drivers/gpu/drm/i2c/ch7006_priv.h

[PATCH v3 2/3] drm/fb-helper: Set framebuffer for vga-switcheroo clients

2023-01-16 Thread Thomas Zimmermann
Set the framebuffer info for drivers that support VGA switcheroo. Only
affects the amdgpu and nouveau drivers, which use VGA switcheroo and
generic fbdev emulation. For other drivers, this does nothing.

This fixes a potential regression in the console code. Both, amdgpu and
nouveau, invoked vga_switcheroo_client_fb_set() from their internal fbdev
code. But the call got lost when the drivers switched to the generic
emulation.

Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of setting up 
AMD own's.")
Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
Signed-off-by: Thomas Zimmermann 
Reviewed-by: Daniel Vetter 
Reviewed-by: Alex Deucher 
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Thomas Zimmermann 
Cc: Javier Martinez Canillas 
Cc: Laurent Pinchart 
Cc: Jani Nikula 
Cc: Dave Airlie 
Cc: Evan Quan 
Cc: Christian König 
Cc: Alex Deucher 
Cc: Hawking Zhang 
Cc: Likun Gao 
Cc: "Christian König" 
Cc: Stanley Yang 
Cc: "Tianci.Yin" 
Cc: Xiaojian Du 
Cc: Andrey Grodzovsky 
Cc: YiPeng Chai 
Cc: Somalapuram Amaranath 
Cc: Bokun Zhang 
Cc: Guchun Chen 
Cc: Hamza Mahfooz 
Cc: Aurabindo Pillai 
Cc: Mario Limonciello 
Cc: Solomon Chiu 
Cc: Kai-Heng Feng 
Cc: Felix Kuehling 
Cc: Daniel Vetter 
Cc: "Marek Olšák" 
Cc: Sam Ravnborg 
Cc: Hans de Goede 
Cc: "Ville Syrjälä" 
Cc: dri-de...@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Cc:  # v5.17+
---
 drivers/gpu/drm/drm_fb_helper.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 367fb8b2d5fa..c5c13e192b64 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -30,7 +30,9 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1924,6 +1926,7 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
 int preferred_bpp)
 {
struct drm_client_dev *client = _helper->client;
+   struct drm_device *dev = fb_helper->dev;
struct drm_fb_helper_surface_size sizes;
int ret;
 
@@ -1945,6 +1948,11 @@ static int drm_fb_helper_single_fb_probe(struct 
drm_fb_helper *fb_helper,
return ret;
 
strcpy(fb_helper->fb->comm, "[fbcon]");
+
+   /* Set the fb info for vgaswitcheroo clients. Does nothing otherwise. */
+   if (dev_is_pci(dev->dev))
+   vga_switcheroo_client_fb_set(to_pci_dev(dev->dev), 
fb_helper->info);
+
return 0;
 }
 
-- 
2.39.0



[PATCH v3 3/3] drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose

2023-01-16 Thread Thomas Zimmermann
Several lastclose helpers call vga_switcheroo_process_delayed_switch().
It's better to call the helper from drm_lastclose() after the kernel
client's screen has been restored. This way, all drivers can benefit
without having to implement their own lastclose helper. For drivers
without vga-switcheroo, vga_switcheroo_process_delayed_switch() does
nothing.

There was an earlier patchset to do something similar. [1]

v3:
* include drm_fb_helper.h in radeon_drv.c
v2:
* handle vga_switcheroo_client_fb_set() in a separate patch
* also update i915, nouveau and radeon
* remove unnecessary include statements
* update vga-switcheroo docs

Suggested-by: Alexander Deucher 
Signed-off-by: Thomas Zimmermann 
Reviewed-by: Daniel Vetter 
Reviewed-by: Alex Deucher 
Link: 
https://lore.kernel.org/amd-gfx/20221020143603.563929-1-alexander.deuc...@amd.com/
 # 1
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 13 -
 drivers/gpu/drm/drm_file.c  |  3 +++
 drivers/gpu/drm/i915/i915_driver.c  | 25 ++---
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  1 -
 drivers/gpu/drm/nouveau/nouveau_vga.c   |  7 ---
 drivers/gpu/drm/nouveau/nouveau_vga.h   |  1 -
 drivers/gpu/drm/radeon/radeon_drv.c |  3 ++-
 drivers/gpu/drm/radeon/radeon_drv.h |  1 -
 drivers/gpu/drm/radeon/radeon_kms.c | 18 --
 drivers/gpu/vga/vga_switcheroo.c|  4 ++--
 12 files changed, 9 insertions(+), 70 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 63c921c55fb9..7120b9b6e580 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1330,7 +1330,6 @@ extern const int amdgpu_max_kms_ioctl;
 
 int amdgpu_driver_load_kms(struct amdgpu_device *adev, unsigned long flags);
 void amdgpu_driver_unload_kms(struct drm_device *dev);
-void amdgpu_driver_lastclose_kms(struct drm_device *dev);
 int amdgpu_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv);
 void amdgpu_driver_postclose_kms(struct drm_device *dev,
 struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index c39245f737a7..b9b22a355cb0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -2778,7 +2777,6 @@ static const struct drm_driver amdgpu_kms_driver = {
DRIVER_SYNCOBJ_TIMELINE,
.open = amdgpu_driver_open_kms,
.postclose = amdgpu_driver_postclose_kms,
-   .lastclose = amdgpu_driver_lastclose_kms,
.ioctls = amdgpu_ioctls_kms,
.num_ioctls = ARRAY_SIZE(amdgpu_ioctls_kms),
.dumb_create = amdgpu_mode_dumb_create,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 7aa7e52ca784..a37be02fb2fc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -34,7 +34,6 @@
 #include "amdgpu_vce.h"
 #include "atom.h"
 
-#include 
 #include 
 #include 
 #include 
@@ -1104,18 +1103,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file *filp)
 /*
  * Outdated mess for old drm with Xorg being in charge (void function now).
  */
-/**
- * amdgpu_driver_lastclose_kms - drm callback for last close
- *
- * @dev: drm dev pointer
- *
- * Switch vga_switcheroo state after last close (all asics).
- */
-void amdgpu_driver_lastclose_kms(struct drm_device *dev)
-{
-   drm_fb_helper_lastclose(dev);
-   vga_switcheroo_process_delayed_switch();
-}
 
 /**
  * amdgpu_driver_open_kms - drm callback for open
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a51ff8cee049..314c309db9a3 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -460,6 +461,8 @@ void drm_lastclose(struct drm_device * dev)
drm_legacy_dev_reinit(dev);
 
drm_client_dev_restore(dev);
+
+   vga_switcheroo_process_delayed_switch();
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index 33e231b120c1..bf6ad8620970 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include  /* for FBINFO_STATE_ */
 #include 
 #include 
 #include 
@@ -37,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -1057,27 +1057,6 @@ static int i915_driver_open(struct drm_device *dev, 
struct drm_file *file)
return 0;
 }
 
-/**
- * i915_driver_lastclose - clean up after all DRM clients have exited
- * @dev: DRM device
- *
- * Take care of 

[PATCH v3 1/3] drm/i915: Allow switching away via vga-switcheroo if uninitialized

2023-01-16 Thread Thomas Zimmermann
Always allow switching away via vga-switcheroo if the display is
uninitalized. Instead prevent switching to i915 if the device has
not been initialized.

This issue was introduced by commit 5df7bd130818 ("drm/i915: skip
display initialization when there is no display") protected, which
protects code paths from being executed on uninitialized devices.
In the case of vga-switcheroo, we want to allow a switch away from
i915's device. So run vga_switcheroo_process_delayed_switch() and
test in the switcheroo callbacks if the i915 device is available.

Fixes: 5df7bd130818 ("drm/i915: skip display initialization when there is no 
display")
Signed-off-by: Thomas Zimmermann 
Cc: Radhakrishna Sripada 
Cc: Lucas De Marchi 
Cc: José Roberto de Souza 
Cc: Jani Nikula 
Cc: Ville Syrjälä 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: "Ville Syrjälä" 
Cc: Manasi Navare 
Cc: Stanislav Lisovskiy 
Cc: Imre Deak 
Cc: "Jouni Högander" 
Cc: Uma Shankar 
Cc: Ankit Nautiyal 
Cc: "Jason A. Donenfeld" 
Cc: Matt Roper 
Cc: Ramalingam C 
Cc: Thomas Zimmermann 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Cc: "José Roberto de Souza" 
Cc: Julia Lawall 
Cc: intel-...@lists.freedesktop.org
Cc:  # v5.14+
---
 drivers/gpu/drm/i915/i915_driver.c | 3 +--
 drivers/gpu/drm/i915/i915_switcheroo.c | 6 +-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index c1e427ba57ae..33e231b120c1 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1075,8 +1075,7 @@ static void i915_driver_lastclose(struct drm_device *dev)
 
intel_fbdev_restore_mode(dev);
 
-   if (HAS_DISPLAY(i915))
-   vga_switcheroo_process_delayed_switch();
+   vga_switcheroo_process_delayed_switch();
 }
 
 static void i915_driver_postclose(struct drm_device *dev, struct drm_file 
*file)
diff --git a/drivers/gpu/drm/i915/i915_switcheroo.c 
b/drivers/gpu/drm/i915/i915_switcheroo.c
index 23777d500cdf..f45bd6b6cede 100644
--- a/drivers/gpu/drm/i915/i915_switcheroo.c
+++ b/drivers/gpu/drm/i915/i915_switcheroo.c
@@ -19,6 +19,10 @@ static void i915_switcheroo_set_state(struct pci_dev *pdev,
dev_err(>dev, "DRM not initialized, aborting switch.\n");
return;
}
+   if (!HAS_DISPLAY(i915)) {
+   dev_err(>dev, "Device state not initialized, aborting 
switch.\n");
+   return;
+   }
 
if (state == VGA_SWITCHEROO_ON) {
drm_info(>drm, "switched on\n");
@@ -44,7 +48,7 @@ static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
 * locking inversion with the driver load path. And the access here is
 * completely racy anyway. So don't bother with locking for now.
 */
-   return i915 && atomic_read(>drm.open_count) == 0;
+   return i915 && HAS_DISPLAY(i915) && atomic_read(>drm.open_count) 
== 0;
 }
 
 static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
-- 
2.39.0



[PATCH v3 0/3] drm/{amdgpu, i915, nouveau, radeon}: Fix fbdev and vga-switcheroo

2023-01-16 Thread Thomas Zimmermann
(was: drm: Generic fbdev and vga-switcheroo)

This patchset fixes how fbdev helpers interact with vga-switcheroo. The
first two patches are bug fixes for the existing code. The third patch
cleans up the drivers.

Patch 1 fixes i915 to do the correct thing if the device has not been
initialized yet. Switching to the device is only possible after the
initialization, but switching away is always possible.

Patch 2 is the original patch without the amdgpu changes. Installs
the fbdev framebuffer in vga-switcheroo for the PCI device. Does
nothing for drivers without vga-switcheroo.

Patch 3 cleans up vga_switcheroo_process_delayed_switch() in amdgpu
and the other related drivers (i.e., i915, nouveau and radeon). The
call is now located at the end of drm_lastclose() and drivers do not
need their own lastclose helpers any longer.

I kept the r-bs from v1, but patch 1 is entirely new and patch 3 has
significantly grown in size.

v3:
* include drm_fb_helper.h in radeon_drv.c
v2:
* expand to patch series
* fix i915, nouveau and radeon

Thomas Zimmermann (3):
  drm/i915: Allow switching away via vga-switcheroo if uninitialized
  drm/fb-helper: Set framebuffer for vga-switcheroo clients
  drm: Call vga_switcheroo_process_delayed_switch() in drm_lastclose

 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |  2 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 13 -
 drivers/gpu/drm/drm_fb_helper.c |  8 
 drivers/gpu/drm/drm_file.c  |  3 +++
 drivers/gpu/drm/i915/i915_driver.c  | 26 ++---
 drivers/gpu/drm/i915/i915_switcheroo.c  |  6 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  1 -
 drivers/gpu/drm/nouveau/nouveau_vga.c   |  7 ---
 drivers/gpu/drm/nouveau/nouveau_vga.h   |  1 -
 drivers/gpu/drm/radeon/radeon_drv.c |  3 ++-
 drivers/gpu/drm/radeon/radeon_drv.h |  1 -
 drivers/gpu/drm/radeon/radeon_kms.c | 18 -
 drivers/gpu/vga/vga_switcheroo.c|  4 ++--
 14 files changed, 22 insertions(+), 72 deletions(-)


base-commit: 68d139b609a97a83e7c231189d4864aba4e1679b
prerequisite-patch-id: 0aa359f6144c4015c140c8a6750be19099c676fb
prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
prerequisite-patch-id: 3f204510fcbf9530d6540bd8e6128cce598988b6
-- 
2.39.0



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

2023-01-16 Thread Christian König

[SNIP]
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.


That won't work.


I don't think this is incorrect.


No, this is completely incorrect. It mixes up the reverse tracking of 
mappings and might crash the system.


I don't understand that. The imported BO is a different BO with a 
different mmap offset in a different device file. I don't see how that 
messes with the tracking of mappings.


The tracking keeps note which piece of information is accessible through 
which address space object and offset. I you suddenly have two address 
spaces and offsets pointing to the same piece of information that won't 
work any more.





This is the reason why we can't mmap() imported BOs.


I don't see anything preventing that. For userptr BOs, there is this 
code in amdgpu_gem_object_mmap:


    if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
    return -EPERM;

I don't see anything like this preventing mmapping of imported dmabuf 
BOs. What am I missing?




At some point I really need to make a big presentation about all this 
stuff, we had the same discussion multiple times now :)


It's the same reason why you can't mmap() VRAM through the kfd node: 
Each file can have only one address space object associated with it.


See dma_buf_mmap() and vma_set_file() how this is worked around in DMA-buf.



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.


Actually it shouldn't. This can go boom really easily.


OK. I don't think we're doing this, but after Xiaogang raised the 
question I went looking through the code whether it's theoretically 
possible. I didn't find anything in the code that says that mmapping 
imported dmabufs would be prohibited or even dangerous. On the 
contrary, I found that ttm_bo_vm explicitly supports mmapping SG BOs.





When you have imported a BO the only correct way of to mmap() it is 
to do so on the original exporter.


That seems sensible, and this is what we do today. That said, if 
mmapping an imported BO is dangerous, I'm missing a mechanism to 
protect against this. It could be as simple as setting 
AMDGPU_GEM_CREATE_NO_CPU_ACCESS in amdgpu_dma_buf_create_obj.


At least for the GEM mmap() handler this is double checked very early by 
looking at obj->import_attach and then either rejecting it or 
redirecting the request to the DMA-buf file instead.


We probably need something similar when stuff is mapped through the KFD 
node. But I think we don't do that any more for "normal" BOs anyway, 
don't we?


Regards,
Christian.



Regards,
  Felix




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

2023-01-16 Thread Christian König
Mhm, that sucks. Could we have the automated builds check for paddings 
in the UAPi data structure?


Christian.

Am 14.01.23 um 00:33 schrieb 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
   

Re: [PATCH 1/2] drm/ttm: Check ttm_debugfs_root before creating files under it

2023-01-16 Thread Christian König

Am 16.01.23 um 03:44 schrieb Ma, Jun:

On 1/13/2023 5:37 PM, Christian König wrote:

Am 13.01.23 um 06:34 schrieb Ma Jun:

Check the ttm_debugfs_root before creating files under it.
If the ttm_debugfs_root is NULL, all the files created for
ttm/ will be placed in the /sys/kerne/debug/ but not
/sys/kernel/debug/ttm/

Well NAK for upstreaming. Why should ttm_debugfs_root be NULL here?


In my case, when the ttm/ removal fails during amdgpu uninstall and then
we try to modprobe the amdgpu again, the ttm_debugfs_root will be NULL
because the ttm/ already exists.


Yeah, but this is just papering over a previous bug which in turn is not 
a valid argument for a code change.


What should happen instead is that the original bug needs to get fixed.

Regards,
Christian.



Regards,
Ma Jun


Regards,
Christian.


Signed-off-by: Ma Jun 
---
   drivers/gpu/drm/ttm/ttm_device.c |  3 ++-
   drivers/gpu/drm/ttm/ttm_pool.c   | 10 ++
   drivers/gpu/drm/ttm/ttm_tt.c |  5 +++--
   3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index e7147e304637..967bc2244df3 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -105,7 +105,8 @@ static int ttm_global_init(void)
INIT_LIST_HEAD(>device_list);
atomic_set(>bo_count, 0);
   
-	debugfs_create_atomic_t("buffer_objects", 0444, ttm_debugfs_root,

+   if(ttm_debugfs_root)
+   debugfs_create_atomic_t("buffer_objects", 0444, 
ttm_debugfs_root,
>bo_count);
   out:
if (ret && ttm_debugfs_root)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index 21b61631f73a..d95a65f759df 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -713,10 +713,12 @@ int ttm_pool_mgr_init(unsigned long num_pages)
}
   
   #ifdef CONFIG_DEBUG_FS

-   debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
-   _pool_debugfs_globals_fops);
-   debugfs_create_file("page_pool_shrink", 0400, ttm_debugfs_root, NULL,
-   _pool_debugfs_shrink_fops);
+   if(ttm_debugfs_root) {
+   debugfs_create_file("page_pool", 0444, ttm_debugfs_root, NULL,
+   _pool_debugfs_globals_fops);
+   debugfs_create_file("page_pool_shrink", 0400, ttm_debugfs_root, 
NULL,
+   _pool_debugfs_shrink_fops);
+   }
   #endif
   
   	mm_shrinker.count_objects = ttm_pool_shrinker_count;

diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index d505603930a7..fec443494ef0 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -394,8 +394,9 @@ DEFINE_SHOW_ATTRIBUTE(ttm_tt_debugfs_shrink);
   void ttm_tt_mgr_init(unsigned long num_pages, unsigned long num_dma32_pages)
   {
   #ifdef CONFIG_DEBUG_FS
-   debugfs_create_file("tt_shrink", 0400, ttm_debugfs_root, NULL,
-   _tt_debugfs_shrink_fops);
+   if(ttm_debugfs_root)
+   debugfs_create_file("tt_shrink", 0400, ttm_debugfs_root, NULL,
+   _tt_debugfs_shrink_fops);
   #endif
   
   	if (!ttm_pages_limit)




Re: [PATCH 2/2] drm/ttm: Use debugfs_remove_recursive to remove ttm directory

2023-01-16 Thread Christian König

Am 16.01.23 um 03:44 schrieb Ma, Jun:

On 1/13/2023 5:38 PM, Christian König wrote:

Am 13.01.23 um 06:34 schrieb Ma Jun:

Use debugfs_remove_recursive to remove the /sys/kernel/debug/ttm
directory for better compatibility. Becuase debugfs_remove fails
on older kernel.

Again NAK for upstreaming.

The upstream kernel is made for the newest kernel version and should not
contain any compatibility handling for older kernels.


Yes, generally so.

But the debugfs_remove_recursive() and debugfs_remove() are same function now.
The debugfs_remove_recursive is used here so that we don't need to make kcl 
patch
for it.


Well making our internal kcl simpler is not a valid justification for 
upstreaming code.


My educated guess is that either debugfs_remove or 
debugfs_remove_recursive will go away in the near future, so it can 
happen that we will revert this again then.


What you could do is double checking with Greg what his preferences 
regarding debugfs_remove/debugfs_remove_recursive is.


You could then write something like "Replace debugfs_remove with 
debugfs_remove_recursive to better document what actually happens here. 
Also makes our internal KCL code simpler to maintain since 
debugfs_remove might go away in the future.".


Regards,
Christian.



Regards,
Ma Jun


Christian.


Signed-off-by: Ma Jun 
---
   drivers/gpu/drm/ttm/ttm_device.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index 967bc2244df3..590297123bb2 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -55,7 +55,7 @@ static void ttm_global_release(void)
goto out;
   
   	ttm_pool_mgr_fini();

-   debugfs_remove(ttm_debugfs_root);
+   debugfs_remove_recursive(ttm_debugfs_root);
   
   	__free_page(glob->dummy_read_page);

memset(glob, 0, sizeof(*glob));




RE: [PATCH 2/2] drm/amdgpu: correct MEC number for gfx11 APUs

2023-01-16 Thread Zhang, Yifan
[Public]

This series is:

Reviewed-by: Yifan Zhang 

Best Regards,
Yifan

-Original Message-
From: Yu, Lang  
Sent: Monday, January 16, 2023 4:20 PM
To: amd-gfx@lists.freedesktop.org
Cc: Koenig, Christian ; Du, Xiaojian 
; Zhang, Yifan ; Yu, Lang 

Subject: [PATCH 2/2] drm/amdgpu: correct MEC number for gfx11 APUs

There is only one MEC on these APUs.

Signed-off-by: Lang Yu 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 985fe704203e..dd4e0f337f46 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -1251,10 +1251,8 @@ static int gfx_v11_0_sw_init(void *handle)
 
switch (adev->ip_versions[GC_HWIP][0]) {
case IP_VERSION(11, 0, 0):
-   case IP_VERSION(11, 0, 1):
case IP_VERSION(11, 0, 2):
case IP_VERSION(11, 0, 3):
-   case IP_VERSION(11, 0, 4):
adev->gfx.me.num_me = 1;
adev->gfx.me.num_pipe_per_me = 1;
adev->gfx.me.num_queue_per_pipe = 1;
@@ -1262,6 +1260,15 @@ static int gfx_v11_0_sw_init(void *handle)
adev->gfx.mec.num_pipe_per_mec = 4;
adev->gfx.mec.num_queue_per_pipe = 4;
break;
+   case IP_VERSION(11, 0, 1):
+   case IP_VERSION(11, 0, 4):
+   adev->gfx.me.num_me = 1;
+   adev->gfx.me.num_pipe_per_me = 1;
+   adev->gfx.me.num_queue_per_pipe = 1;
+   adev->gfx.mec.num_mec = 1;
+   adev->gfx.mec.num_pipe_per_mec = 4;
+   adev->gfx.mec.num_queue_per_pipe = 4;
+   break;
default:
adev->gfx.me.num_me = 1;
adev->gfx.me.num_pipe_per_me = 1;
-- 
2.25.1


[PATCH 2/2] drm/amdgpu: correct MEC number for gfx11 APUs

2023-01-16 Thread Lang Yu
There is only one MEC on these APUs.

Signed-off-by: Lang Yu 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 985fe704203e..dd4e0f337f46 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -1251,10 +1251,8 @@ static int gfx_v11_0_sw_init(void *handle)
 
switch (adev->ip_versions[GC_HWIP][0]) {
case IP_VERSION(11, 0, 0):
-   case IP_VERSION(11, 0, 1):
case IP_VERSION(11, 0, 2):
case IP_VERSION(11, 0, 3):
-   case IP_VERSION(11, 0, 4):
adev->gfx.me.num_me = 1;
adev->gfx.me.num_pipe_per_me = 1;
adev->gfx.me.num_queue_per_pipe = 1;
@@ -1262,6 +1260,15 @@ static int gfx_v11_0_sw_init(void *handle)
adev->gfx.mec.num_pipe_per_mec = 4;
adev->gfx.mec.num_queue_per_pipe = 4;
break;
+   case IP_VERSION(11, 0, 1):
+   case IP_VERSION(11, 0, 4):
+   adev->gfx.me.num_me = 1;
+   adev->gfx.me.num_pipe_per_me = 1;
+   adev->gfx.me.num_queue_per_pipe = 1;
+   adev->gfx.mec.num_mec = 1;
+   adev->gfx.mec.num_pipe_per_mec = 4;
+   adev->gfx.mec.num_queue_per_pipe = 4;
+   break;
default:
adev->gfx.me.num_me = 1;
adev->gfx.me.num_pipe_per_me = 1;
-- 
2.25.1



[PATCH 1/2] drm/amdgpu: allow multipipe policy on ASICs with one MEC

2023-01-16 Thread Lang Yu
Always enable multipipe policy on ASICs with GC VERSION > 9.0.0
instead of MEC number > 1.

This will allow multipipe policy on ASICs with one MEC,
e.g., gfx11 APUs.

Signed-off-by: Lang Yu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
index 42a939cd2eac..dfd8a0ccbc83 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c
@@ -156,6 +156,9 @@ static bool amdgpu_gfx_is_compute_multipipe_capable(struct 
amdgpu_device *adev)
return amdgpu_compute_multipipe == 1;
}
 
+   if (adev->ip_versions[GC_HWIP][0] > IP_VERSION(9, 0, 0))
+   return true;
+
/* FIXME: spreading the queues across pipes causes perf regressions
 * on POLARIS11 compute workloads */
if (adev->asic_type == CHIP_POLARIS11)
-- 
2.25.1