Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

2023-06-29 Thread Sui Jingfeng

Hi,

On 2023/6/30 01:44, Limonciello, Mario wrote:

I think what you can do is pick up all the tags in your next version.  Once the
whole series has tags we can discuss how it merges.


Yes, you are right.

I will prepare the next version.

But I think, I should only gather the reverent part together.

I means that I probably should divide the 8 patches in V7 into 4 + 4.

The first four patch form a group, and the last four patch form another 
group.



Certainly, I will pick up the precious tags I got in the next version.

Thanks you!



Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

2023-06-29 Thread suijingfeng

Hi,

On 2023/6/30 01:44, Limonciello, Mario wrote:

[Public]


-Original Message-
From: 15330273...@189.cn <15330273...@189.cn>
Sent: Thursday, June 29, 2023 12:00 PM
To: Bjorn Helgaas ; Sui Jingfeng

Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org;
Cornelia Huck ; Karol Herbst ;
nouv...@lists.freedesktop.org; Joonas Lahtinen
; dri-de...@lists.freedesktop.org; Chai,
Thomas ; Limonciello, Mario
; Gao, Likun ; David
Airlie ; Ville Syrjala ; Yi 
Liu
; k...@vger.kernel.org; amd-gfx@lists.freedesktop.org;
Jason Gunthorpe ; Ben Skeggs ; linux-
p...@vger.kernel.org; Kevin Tian ; Lazar, Lijo
; Thomas Zimmermann ;
Zhang, Bokun ; intel-...@lists.freedesktop.org;
Maarten Lankhorst ; Jani Nikula
; Alex Williamson
; Abhishek Sahu ;
Maxime Ripard ; Rodrigo Vivi ;
Tvrtko Ursulin ; Yishai Hadas
; Pan, Xinhui ; linux-
ker...@vger.kernel.org; Daniel Vetter ; Deucher, Alexander
; Koenig, Christian
; Zhang, Hawking 
Subject: Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function
callback to vga_client_register

Hi,

On 2023/6/29 23:54, Bjorn Helgaas wrote:

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:

Hi,


A nouveau developer(Lyude) from redhat send me a R-B,

Thanks for the developers of nouveau project.


Please allow me add a link[1] here.


[1]

https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca
m...@redhat.com/

1) Thanks for this.  If you post another version of this series,
 please pick up Lyude's Reviewed-by and include it in the relevant
 patches (as long as you haven't made significant changes to the
 code Lyude reviewed).

Yes, no significant changes. Just fix typo.

I also would like to add support for other DRM drivers.

But I think this deserve another patch.


   Whoever applies this should automatically
 pick up Reviewed-by/Ack/etc that are replies to the version being
 applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
 apply this on v6.4-rc1, but it doesn't apply cleanly.

Since I'm a graphic driver developer, I'm using drm-tip.

I just have already pulled, it still apply cleanly on drm-tip.


3) Thanks for including cover letters in your postings.  Please
 include a little changelog in the cover letter so we know what
 changed between v6 and v7, etc.

No change between v6 and v7,

it seems that it is because the mailbox don't allow me to sending too
many mails a day.

so some of the patch is failed to delivery because out of quota.



4) Right now we're in the middle of the v6.5 merge window, so new
 content, e.g., this series, is too late for v6.5.  Most
 maintainers, including me, wait to merge new content until the
 merge window closes and a new -rc1 is tagged.  This merge window
 should close on July 9, and people will start merging content for
 v6.6, typically based on v6.5-rc1.

I'm wondering

Would you will merge all of the patches in this series (e.g. including
the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?

Or just part of them?

Emm, I don't know because my patch seems across different subsystem of
Linux kernel.

There is also a developer for AMDGPU (Mario) give me a R-B for the
patch-0002 of this series.

So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-
0006
are already OK(got reviewed by).

Those 5 patch are already qualified to be merged, I think.

I think what you can do is pick up all the tags in your next version.  Once the
whole series has tags we can discuss how it merges.


Thanks a lot, Mario.


Is it possible to merge the PCI/VGA part as fast as possible, especially the

PATCH-0006 PCI/VGA: Introduce is_boot_device function callback to 
vga_client_register

As this patch is fundamental, it introduce no functional change, as long as the 
drm

driver side don't introduce a callback.

I'm not hurry, but drm driver-side's patch have a dependency on this patch,

I think it is better the PCI/VGA-side's patch got merge first.

At least for get the first four cleanup(0001 ~ 0004) patch merged first,

so that I don't have to send so much on the next version on one series.

Being exposed so far, there no obvious objection.

It saying that other people also want it got merged.

Bjorn, is this OK ?




I means that if you could merge those 5 patch first, then there no need
to send another version again.

I will refine the rest patch with more details and description.

I'm fear of making too much noise.


Bjorn




[PATCH] drm/amd/amdgpu: Add cu_occupancy sysfs file to GFX9.4.3

2023-06-29 Thread Sreekant Somasekharan
Include kgd_gfx_v9_get_cu_occupancy call inside kfd2kgd_calls for
GFX9.4.3 to expose cu_occupancy sysfs file.

Signed-off-by: Sreekant Somasekharan 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c
index 5b4b7f8b92a5..0ac5377a2fe7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gc_9_4_3.c
@@ -379,6 +379,7 @@ const struct kfd2kgd_calls gc_9_4_3_kfd2kgd = {
kgd_gfx_v9_get_atc_vmid_pasid_mapping_info,
.set_vm_context_page_table_base =
kgd_gfx_v9_set_vm_context_page_table_base,
+   .get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
.program_trap_handler_settings =
kgd_gfx_v9_program_trap_handler_settings
 };
-- 
2.25.1



Re: [PATCH] drm/amdkfd: Skip handle mapping SVM range with no GPU access

2023-06-29 Thread Sierra Guiza, Alejandro (Alex)

On 6/29/2023 5:29 PM, Philip Yang wrote:

If the SVM range has no GPU access or access-in-place attribute,

Just a nit-pick. Shouldn't be no GPU access nor access-in-place?

validate and map to GPU should skip the range.

Add NULL pointer check if find_first_bit(ctx->bitmap, MAX_GPU_INSTANCE)
returns MAX_GPU_INSTANCE as gpuidx if ctx->bitmap is empty.

Signed-off-by: Philip Yang 

Reviewed-by: Alex Sierra 

---
  drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 5ff1a5a89d96..479c4f66afa7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1522,6 +1522,8 @@ static void *kfd_svm_page_owner(struct kfd_process *p, 
int32_t gpuidx)
struct kfd_process_device *pdd;
  
  	pdd = kfd_process_device_from_gpuidx(p, gpuidx);

+   if (!pdd)
+   return NULL;
  
  	return SVM_ADEV_PGMAP_OWNER(pdd->dev->adev);

  }
@@ -1596,12 +1598,12 @@ static int svm_range_validate_and_map(struct mm_struct 
*mm,
}
  
  	if (bitmap_empty(ctx->bitmap, MAX_GPU_INSTANCE)) {

-   if (!prange->mapped_to_gpu) {
+   bitmap_copy(ctx->bitmap, prange->bitmap_access, 
MAX_GPU_INSTANCE);
+   if (!prange->mapped_to_gpu ||
+   bitmap_empty(ctx->bitmap, MAX_GPU_INSTANCE)) {
r = 0;
goto free_ctx;
}
-
-   bitmap_copy(ctx->bitmap, prange->bitmap_access, 
MAX_GPU_INSTANCE);
}
  
  	if (prange->actual_loc && !prange->ttm_res) {


[PATCH] drm/amdkfd: Skip handle mapping SVM range with no GPU access

2023-06-29 Thread Philip Yang
If the SVM range has no GPU access or access-in-place attribute,
validate and map to GPU should skip the range.

Add NULL pointer check if find_first_bit(ctx->bitmap, MAX_GPU_INSTANCE)
returns MAX_GPU_INSTANCE as gpuidx if ctx->bitmap is empty.

Signed-off-by: Philip Yang 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 5ff1a5a89d96..479c4f66afa7 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1522,6 +1522,8 @@ static void *kfd_svm_page_owner(struct kfd_process *p, 
int32_t gpuidx)
struct kfd_process_device *pdd;
 
pdd = kfd_process_device_from_gpuidx(p, gpuidx);
+   if (!pdd)
+   return NULL;
 
return SVM_ADEV_PGMAP_OWNER(pdd->dev->adev);
 }
@@ -1596,12 +1598,12 @@ static int svm_range_validate_and_map(struct mm_struct 
*mm,
}
 
if (bitmap_empty(ctx->bitmap, MAX_GPU_INSTANCE)) {
-   if (!prange->mapped_to_gpu) {
+   bitmap_copy(ctx->bitmap, prange->bitmap_access, 
MAX_GPU_INSTANCE);
+   if (!prange->mapped_to_gpu ||
+   bitmap_empty(ctx->bitmap, MAX_GPU_INSTANCE)) {
r = 0;
goto free_ctx;
}
-
-   bitmap_copy(ctx->bitmap, prange->bitmap_access, 
MAX_GPU_INSTANCE);
}
 
if (prange->actual_loc && !prange->ttm_res) {
-- 
2.35.1



RE: [PATCHv2] drm/amdkfd: Use KIQ to unmap HIQ

2023-06-29 Thread Kasiviswanathan, Harish
[AMD Official Use Only - General]

Reviewed-by: Harish Kasiviswanathan 

-Original Message-
From: amd-gfx  On Behalf Of Mukul Joshi
Sent: Thursday, June 29, 2023 12:35 PM
To: amd-gfx@lists.freedesktop.org
Cc: Lin, Amber ; Joshi, Mukul ; 
Kuehling, Felix 
Subject: [PATCHv2] drm/amdkfd: Use KIQ to unmap HIQ

Currently, we unmap HIQ by directly writing to HQD
registers. This doesn't work for GFX9.4.3. Instead,
use KIQ to unmap HIQ, similar to how we use KIQ to
map HIQ. Using KIQ to unmap HIQ works for all GFX
series post GFXv9.

Signed-off-by: Mukul Joshi 
---
v1->v2:
- Use kiq_unmap_queues function instead of duplicating
  code (Felix).

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 36 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  2 ++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c  | 22 +++-
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c  | 22 +++-
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c   | 36 +++
 5 files changed, 109 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index b4fcad0e62f7..0040c63e2356 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -830,3 +830,39 @@ u64 amdgpu_amdkfd_xcp_memory_size(struct amdgpu_device 
*adev, int xcp_id)
return adev->gmc.real_vram_size;
}
 }
+
+int amdgpu_amdkfd_unmap_hiq(struct amdgpu_device *adev, u32 doorbell_off,
+   u32 inst)
+{
+   struct amdgpu_kiq *kiq = >gfx.kiq[inst];
+   struct amdgpu_ring *kiq_ring = >ring;
+   struct amdgpu_ring_funcs ring_funcs;
+   struct amdgpu_ring ring;
+   int r = 0;
+
+   if (!kiq->pmf || !kiq->pmf->kiq_unmap_queues)
+   return -EINVAL;
+
+   memset(, 0x0, sizeof(struct amdgpu_ring));
+   memset(_funcs, 0x0, sizeof(struct amdgpu_ring_funcs));
+
+   ring_funcs.type = AMDGPU_RING_TYPE_COMPUTE;
+   ring.doorbell_index = doorbell_off;
+   ring.funcs = _funcs;
+
+   spin_lock(>ring_lock);
+
+   if (amdgpu_ring_alloc(kiq_ring, kiq->pmf->unmap_queues_size)) {
+   spin_unlock(>ring_lock);
+   return -ENOMEM;
+   }
+
+   kiq->pmf->kiq_unmap_queues(kiq_ring, , RESET_QUEUES, 0, 0);
+
+   if (kiq_ring->sched.ready && !adev->job_hang)
+   r = amdgpu_ring_test_helper(kiq_ring);
+
+   spin_unlock(>ring_lock);
+
+   return r;
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 2d0406bff84e..b34418e3e006 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -252,6 +252,8 @@ int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct 
amdgpu_device *dst,
 int amdgpu_amdkfd_get_pcie_bandwidth_mbytes(struct amdgpu_device *adev, bool 
is_min);
 int amdgpu_amdkfd_send_close_event_drain_irq(struct amdgpu_device *adev,
uint32_t *payload);
+int amdgpu_amdkfd_unmap_hiq(struct amdgpu_device *adev, u32 doorbell_off,
+   u32 inst);

 /* Read user wptr from a specified user address space with page fault
  * disabled. The memory must be pinned and mapped to the hardware when
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
index 94c0fc2e57b7..83699392c808 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
@@ -318,6 +318,26 @@ static void init_mqd_hiq(struct mqd_manager *mm, void 
**mqd,
1 << CP_HQD_PQ_CONTROL__KMD_QUEUE__SHIFT;
 }

+static int destroy_hiq_mqd(struct mqd_manager *mm, void *mqd,
+   enum kfd_preempt_type type, unsigned int timeout,
+   uint32_t pipe_id, uint32_t queue_id)
+{
+   int err;
+   struct v10_compute_mqd *m;
+   u32 doorbell_off;
+
+   m = get_mqd(mqd);
+
+   doorbell_off = m->cp_hqd_pq_doorbell_control >>
+   CP_HQD_PQ_DOORBELL_CONTROL__DOORBELL_OFFSET__SHIFT;
+
+   err = amdgpu_amdkfd_unmap_hiq(mm->dev->adev, doorbell_off, 0);
+   if (err)
+   pr_debug("Destroy HIQ MQD failed: %d\n", err);
+
+   return err;
+}
+
 static void init_mqd_sdma(struct mqd_manager *mm, void **mqd,
struct kfd_mem_obj *mqd_mem_obj, uint64_t *gart_addr,
struct queue_properties *q)
@@ -460,7 +480,7 @@ struct mqd_manager *mqd_manager_init_v10(enum KFD_MQD_TYPE 
type,
mqd->free_mqd = free_mqd_hiq_sdma;
mqd->load_mqd = kfd_hiq_load_mqd_kiq;
mqd->update_mqd = update_mqd;
-   mqd->destroy_mqd = kfd_destroy_mqd_cp;
+   mqd->destroy_mqd = destroy_hiq_mqd;
mqd->is_occupied = kfd_is_occupied_cp;
mqd->mqd_size = sizeof(struct v10_compute_mqd);
   

RE: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

2023-06-29 Thread Limonciello, Mario
[Public]

> -Original Message-
> From: 15330273...@189.cn <15330273...@189.cn>
> Sent: Thursday, June 29, 2023 12:00 PM
> To: Bjorn Helgaas ; Sui Jingfeng
> 
> Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org;
> Cornelia Huck ; Karol Herbst ;
> nouv...@lists.freedesktop.org; Joonas Lahtinen
> ; dri-de...@lists.freedesktop.org; Chai,
> Thomas ; Limonciello, Mario
> ; Gao, Likun ; David
> Airlie ; Ville Syrjala ; Yi 
> Liu
> ; k...@vger.kernel.org; amd-gfx@lists.freedesktop.org;
> Jason Gunthorpe ; Ben Skeggs ; linux-
> p...@vger.kernel.org; Kevin Tian ; Lazar, Lijo
> ; Thomas Zimmermann ;
> Zhang, Bokun ; intel-...@lists.freedesktop.org;
> Maarten Lankhorst ; Jani Nikula
> ; Alex Williamson
> ; Abhishek Sahu ;
> Maxime Ripard ; Rodrigo Vivi ;
> Tvrtko Ursulin ; Yishai Hadas
> ; Pan, Xinhui ; linux-
> ker...@vger.kernel.org; Daniel Vetter ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhang, Hawking 
> Subject: Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function
> callback to vga_client_register
>
> Hi,
>
> On 2023/6/29 23:54, Bjorn Helgaas wrote:
> > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> >> Hi,
> >>
> >>
> >> A nouveau developer(Lyude) from redhat send me a R-B,
> >>
> >> Thanks for the developers of nouveau project.
> >>
> >>
> >> Please allow me add a link[1] here.
> >>
> >>
> >> [1]
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca
> m...@redhat.com/
> > 1) Thanks for this.  If you post another version of this series,
> > please pick up Lyude's Reviewed-by and include it in the relevant
> > patches (as long as you haven't made significant changes to the
> > code Lyude reviewed).
>
> Yes, no significant changes. Just fix typo.
>
> I also would like to add support for other DRM drivers.
>
> But I think this deserve another patch.
>
> >   Whoever applies this should automatically
> > pick up Reviewed-by/Ack/etc that are replies to the version being
> > applied, but they won't go through previous revisions to find them.
> >
> > 2) Please mention the commit to which the series applies.  I tried to
> > apply this on v6.4-rc1, but it doesn't apply cleanly.
>
> Since I'm a graphic driver developer, I'm using drm-tip.
>
> I just have already pulled, it still apply cleanly on drm-tip.
>
> > 3) Thanks for including cover letters in your postings.  Please
> > include a little changelog in the cover letter so we know what
> > changed between v6 and v7, etc.
>
> No change between v6 and v7,
>
> it seems that it is because the mailbox don't allow me to sending too
> many mails a day.
>
> so some of the patch is failed to delivery because out of quota.
>
>
> > 4) Right now we're in the middle of the v6.5 merge window, so new
> > content, e.g., this series, is too late for v6.5.  Most
> > maintainers, including me, wait to merge new content until the
> > merge window closes and a new -rc1 is tagged.  This merge window
> > should close on July 9, and people will start merging content for
> > v6.6, typically based on v6.5-rc1.
>
> I'm wondering
>
> Would you will merge all of the patches in this series (e.g. including
> the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?
>
> Or just part of them?
>
> Emm, I don't know because my patch seems across different subsystem of
> Linux kernel.
>
> There is also a developer for AMDGPU (Mario) give me a R-B for the
> patch-0002 of this series.
>
> So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-
> 0006
> are already OK(got reviewed by).
>
> Those 5 patch are already qualified to be merged, I think.

I think what you can do is pick up all the tags in your next version.  Once the
whole series has tags we can discuss how it merges.

>
> I means that if you could merge those 5 patch first, then there no need
> to send another version again.
>
> I will refine the rest patch with more details and description.
>
> I'm fear of making too much noise.
>
> > Bjorn


Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

2023-06-29 Thread Sui Jingfeng

Hi,

On 2023/6/29 23:54, Bjorn Helgaas wrote:

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:

Hi,


A nouveau developer(Lyude) from redhat send me a R-B,

Thanks for the developers of nouveau project.


Please allow me add a link[1] here.


[1] 
https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/

1) Thanks for this.  If you post another version of this series,
please pick up Lyude's Reviewed-by and include it in the relevant
patches (as long as you haven't made significant changes to the
code Lyude reviewed).


Yes, no significant changes. Just fix typo.

I also would like to add support for other DRM drivers.

But I think this deserve another patch.


  Whoever applies this should automatically
pick up Reviewed-by/Ack/etc that are replies to the version being
applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
apply this on v6.4-rc1, but it doesn't apply cleanly.


Since I'm a graphic driver developer, I'm using drm-tip.

I just have already pulled, it still apply cleanly on drm-tip.


3) Thanks for including cover letters in your postings.  Please
include a little changelog in the cover letter so we know what
changed between v6 and v7, etc.


No change between v6 and v7,

it seems that it is because the mailbox don't allow me to sending too 
many mails a day.


so some of the patch is failed to delivery because out of quota.



4) Right now we're in the middle of the v6.5 merge window, so new
content, e.g., this series, is too late for v6.5.  Most
maintainers, including me, wait to merge new content until the
merge window closes and a new -rc1 is tagged.  This merge window
should close on July 9, and people will start merging content for
v6.6, typically based on v6.5-rc1.


I'm wondering

Would you will merge all of the patches in this series (e.g. including 
the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?


Or just part of them?

Emm, I don't know because my patch seems across different subsystem of 
Linux kernel.


There is also a developer for AMDGPU (Mario) give me a R-B for the 
patch-0002 of this series.


So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-0006 
are already OK(got reviewed by).


Those 5 patch are already qualified to be merged, I think.

I means that if you could merge those 5 patch first, then there no need 
to send another version again.


I will refine the rest patch with more details and description.

I'm fear of making too much noise.


Bjorn


[PATCHv2] drm/amdkfd: Use KIQ to unmap HIQ

2023-06-29 Thread Mukul Joshi
Currently, we unmap HIQ by directly writing to HQD
registers. This doesn't work for GFX9.4.3. Instead,
use KIQ to unmap HIQ, similar to how we use KIQ to
map HIQ. Using KIQ to unmap HIQ works for all GFX
series post GFXv9.

Signed-off-by: Mukul Joshi 
---
v1->v2:
- Use kiq_unmap_queues function instead of duplicating
  code (Felix).

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 36 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  2 ++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c  | 22 +++-
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c  | 22 +++-
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c   | 36 +++
 5 files changed, 109 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index b4fcad0e62f7..0040c63e2356 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -830,3 +830,39 @@ u64 amdgpu_amdkfd_xcp_memory_size(struct amdgpu_device 
*adev, int xcp_id)
return adev->gmc.real_vram_size;
}
 }
+
+int amdgpu_amdkfd_unmap_hiq(struct amdgpu_device *adev, u32 doorbell_off,
+   u32 inst)
+{
+   struct amdgpu_kiq *kiq = >gfx.kiq[inst];
+   struct amdgpu_ring *kiq_ring = >ring;
+   struct amdgpu_ring_funcs ring_funcs;
+   struct amdgpu_ring ring;
+   int r = 0;
+
+   if (!kiq->pmf || !kiq->pmf->kiq_unmap_queues)
+   return -EINVAL;
+
+   memset(, 0x0, sizeof(struct amdgpu_ring));
+   memset(_funcs, 0x0, sizeof(struct amdgpu_ring_funcs));
+
+   ring_funcs.type = AMDGPU_RING_TYPE_COMPUTE;
+   ring.doorbell_index = doorbell_off;
+   ring.funcs = _funcs;
+
+   spin_lock(>ring_lock);
+
+   if (amdgpu_ring_alloc(kiq_ring, kiq->pmf->unmap_queues_size)) {
+   spin_unlock(>ring_lock);
+   return -ENOMEM;
+   }
+
+   kiq->pmf->kiq_unmap_queues(kiq_ring, , RESET_QUEUES, 0, 0);
+
+   if (kiq_ring->sched.ready && !adev->job_hang)
+   r = amdgpu_ring_test_helper(kiq_ring);
+
+   spin_unlock(>ring_lock);
+
+   return r;
+}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 2d0406bff84e..b34418e3e006 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -252,6 +252,8 @@ int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct 
amdgpu_device *dst,
 int amdgpu_amdkfd_get_pcie_bandwidth_mbytes(struct amdgpu_device *adev, bool 
is_min);
 int amdgpu_amdkfd_send_close_event_drain_irq(struct amdgpu_device *adev,
uint32_t *payload);
+int amdgpu_amdkfd_unmap_hiq(struct amdgpu_device *adev, u32 doorbell_off,
+   u32 inst);
 
 /* Read user wptr from a specified user address space with page fault
  * disabled. The memory must be pinned and mapped to the hardware when
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
index 94c0fc2e57b7..83699392c808 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c
@@ -318,6 +318,26 @@ static void init_mqd_hiq(struct mqd_manager *mm, void 
**mqd,
1 << CP_HQD_PQ_CONTROL__KMD_QUEUE__SHIFT;
 }
 
+static int destroy_hiq_mqd(struct mqd_manager *mm, void *mqd,
+   enum kfd_preempt_type type, unsigned int timeout,
+   uint32_t pipe_id, uint32_t queue_id)
+{
+   int err;
+   struct v10_compute_mqd *m;
+   u32 doorbell_off;
+
+   m = get_mqd(mqd);
+
+   doorbell_off = m->cp_hqd_pq_doorbell_control >>
+   CP_HQD_PQ_DOORBELL_CONTROL__DOORBELL_OFFSET__SHIFT;
+
+   err = amdgpu_amdkfd_unmap_hiq(mm->dev->adev, doorbell_off, 0);
+   if (err)
+   pr_debug("Destroy HIQ MQD failed: %d\n", err);
+
+   return err;
+}
+
 static void init_mqd_sdma(struct mqd_manager *mm, void **mqd,
struct kfd_mem_obj *mqd_mem_obj, uint64_t *gart_addr,
struct queue_properties *q)
@@ -460,7 +480,7 @@ struct mqd_manager *mqd_manager_init_v10(enum KFD_MQD_TYPE 
type,
mqd->free_mqd = free_mqd_hiq_sdma;
mqd->load_mqd = kfd_hiq_load_mqd_kiq;
mqd->update_mqd = update_mqd;
-   mqd->destroy_mqd = kfd_destroy_mqd_cp;
+   mqd->destroy_mqd = destroy_hiq_mqd;
mqd->is_occupied = kfd_is_occupied_cp;
mqd->mqd_size = sizeof(struct v10_compute_mqd);
mqd->mqd_stride = kfd_mqd_stride;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c
index 31fec5e70d13..2319467d2d95 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_v11.c
@@ 

[PATCH] drm/amdgpu: have bos for PDs/PTS cpu accessible when kfd uses cpu to update vm

2023-06-29 Thread Xiaogang . Chen
From: Xiaogang Chen 

When kfd uses cpu to update vm iterates all current PDs/PTs bos, adds
AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag and kmap them to kernel virtual
address space before kfd updates the vm that was created by gfx.

Signed-off-by: Xiaogang Chen 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 11 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h|  2 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 28 +++
 3 files changed, 34 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 291977b93b1d..dedf1bf44dc6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2278,17 +2278,14 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm)
if (r)
goto unreserve_bo;
 
+   r = amdgpu_vm_pt_cpu_access_root(adev, vm);
+   if (r)
+   goto unreserve_bo;
+
vm->update_funcs = _vm_cpu_funcs;
} else {
vm->update_funcs = _vm_sdma_funcs;
}
-   /*
-* Make sure root PD gets mapped. As vm_update_mode could be changed
-* when turning a GFX VM into a compute VM.
-*/
-   r = vm->update_funcs->map_table(to_amdgpu_bo_vm(vm->root.bo));
-   if (r)
-   goto unreserve_bo;
 
dma_fence_put(vm->last_update);
vm->last_update = dma_fence_get_stub();
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 9c85d494f2a2..9b3e75de7c5c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -491,6 +491,8 @@ void amdgpu_vm_pt_free_work(struct work_struct *work);
 void amdgpu_debugfs_vm_bo_info(struct amdgpu_vm *vm, struct seq_file *m);
 #endif
 
+int amdgpu_vm_pt_cpu_access_root(struct amdgpu_device *adev, struct amdgpu_vm 
*vm);
+
 /**
  * amdgpu_vm_tlb_seq - return tlb flush sequence number
  * @vm: the amdgpu_vm structure to query
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
index dea1a64be44d..a08742191b7d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
@@ -1044,3 +1044,31 @@ int amdgpu_vm_ptes_update(struct amdgpu_vm_update_params 
*params,
 
return 0;
 }
+
+/**
+ * amdgpu_vm_pt_cpu_access_root - have bo of root PD cpu accessible
+ * @adev: amdgpu device structure
+ * @vm: amdgpu vm structure
+ *
+ * make root page directory and everything below it cpu accessible.
+ */
+int amdgpu_vm_pt_cpu_access_root(struct amdgpu_device *adev, struct amdgpu_vm 
*vm)
+{
+   struct amdgpu_vm_pt_cursor cursor;
+   struct amdgpu_vm_bo_base *entry;
+   int r;
+   struct amdgpu_bo_vm *bo;
+
+   for_each_amdgpu_vm_pt_dfs_safe(adev, vm, NULL, cursor, entry) {
+
+   if (entry->bo) {
+   bo = to_amdgpu_bo_vm(entry->bo);
+   entry->bo->flags |= 
AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
+   r = amdgpu_vm_cpu_funcs.map_table(bo);
+   if (r)
+   return r;
+   }
+   }
+
+   return 0;
+}
-- 
2.25.1



Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

2023-06-29 Thread Bjorn Helgaas
On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> Hi,
> 
> 
> A nouveau developer(Lyude) from redhat send me a R-B,
> 
> Thanks for the developers of nouveau project.
> 
> 
> Please allow me add a link[1] here.
> 
> 
> [1] 
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/

1) Thanks for this.  If you post another version of this series,
   please pick up Lyude's Reviewed-by and include it in the relevant
   patches (as long as you haven't made significant changes to the
   code Lyude reviewed).  Whoever applies this should automatically
   pick up Reviewed-by/Ack/etc that are replies to the version being
   applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
   apply this on v6.4-rc1, but it doesn't apply cleanly.

3) Thanks for including cover letters in your postings.  Please
   include a little changelog in the cover letter so we know what
   changed between v6 and v7, etc.

4) Right now we're in the middle of the v6.5 merge window, so new
   content, e.g., this series, is too late for v6.5.  Most
   maintainers, including me, wait to merge new content until the
   merge window closes and a new -rc1 is tagged.  This merge window
   should close on July 9, and people will start merging content for
   v6.6, typically based on v6.5-rc1.

Bjorn


Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

2023-06-29 Thread Sui Jingfeng

Hi,


Humble ping !


Please share some bandwidth to help reviewing this series, OK ?


As this series is useful for all architecture, I have tested on my X86, 
mips and LoongArch computer.


Questions and comments is also welcome.

If no one response within three days,

I'm going to send a updated version with another trivial improvement, OK?

On 2023/6/13 11:01, Sui Jingfeng wrote:

From: Sui Jingfeng 

The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change accordingly. In short, it should take the
re-allocation of the PCI BAR into consideration.

With the observation that device drivers or video aperture helpers may
have better knowledge about which PCI bar contains the firmware fb,
which could avoid the need to iterate all of the PCI BARs. But as a PCI
function at pci/vgaarb.c, vga_is_firmware_default() is not suitable to
make such an optimization since it is loaded too early.

There are PCI display controllers that don't have a dedicated VRAM bar,
this function will lose its effectiveness in such a case. Luckily, the
device driver can provide an accurate workaround.

Therefore, this patch introduces a callback that allows the device driver
to tell the VGAARB if the device is the default boot device. This patch
only intends to introduce the mechanism, while the implementation is left
to the device driver authors. Also honor the comment: "Clients have two
callback mechanisms they can use"

Cc: Alex Deucher 
Cc: Christian Konig 
Cc: Pan Xinhui 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Bjorn Helgaas 
Cc: Alex Williamson 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Hawking Zhang 
Cc: Mario Limonciello 
Cc: Lijo Lazar 
Cc: YiPeng Chai 
Cc: Bokun Zhang 
Cc: Likun Gao 
Cc: Ville Syrjala 
Cc: Jason Gunthorpe 
CC: Kevin Tian 
Cc: Cornelia Huck 
Cc: Yishai Hadas 
Cc: Abhishek Sahu 
Cc: Yi Liu 
Signed-off-by: Sui Jingfeng 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
  drivers/gpu/drm/i915/display/intel_vga.c   |  3 +--
  drivers/gpu/drm/nouveau/nouveau_vga.c  |  2 +-
  drivers/gpu/drm/radeon/radeon_device.c |  2 +-
  drivers/pci/vgaarb.c   | 21 -
  drivers/vfio/pci/vfio_pci_core.c   |  2 +-
  include/linux/vgaarb.h |  8 +---
  7 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5c7d40873ee2..7a096f2d5c16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3960,7 +3960,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* this will fail for cards that aren't VGA class devices, just
 * ignore it */
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
-   vga_client_register(adev->pdev, amdgpu_device_vga_set_decode);
+   vga_client_register(adev->pdev, amdgpu_device_vga_set_decode, 
NULL);
  
  	px = amdgpu_device_supports_px(ddev);
  
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c

index 286a0bdd28c6..98d7d4dffe9f 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -115,7 +115,6 @@ intel_vga_set_decode(struct pci_dev *pdev, bool 
enable_decode)
  
  int intel_vga_register(struct drm_i915_private *i915)

  {
-
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
int ret;
  
@@ -127,7 +126,7 @@ int intel_vga_register(struct drm_i915_private *i915)

 * then we do not take part in VGA arbitration and the
 * vga_client_register() fails with -ENODEV.
 */
-   ret = vga_client_register(pdev, intel_vga_set_decode);
+   ret = vga_client_register(pdev, intel_vga_set_decode, NULL);
if (ret && ret != -ENODEV)
return ret;
  
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c b/drivers/gpu/drm/nouveau/nouveau_vga.c

index f8bf0ec26844..162b4f4676c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -92,7 +92,7 @@ nouveau_vga_init(struct nouveau_drm *drm)
return;
pdev = to_pci_dev(dev->dev);
  
-	vga_client_register(pdev, nouveau_vga_set_decode);

+   vga_client_register(pdev, nouveau_vga_set_decode, NULL);
  
  	/* don't register Thunderbolt eGPU with vga_switcheroo */

if (pci_is_thunderbolt_attached(pdev))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index afbb3a80c0c6..71f2ff39d6a1 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ 

Re: [PATCHv4] drm/amdgpu: Update invalid PTE flag setting

2023-06-29 Thread Christian König

Am 19.06.23 um 19:38 schrieb Mukul Joshi:

Update the invalid PTE flag setting with TF enabled.
This is to ensure, in addition to transitioning the
retry fault to a no-retry fault, it also causes the
wavefront to enter the trap handler. With the current
setting, the fault only transitions to a no-retry fault.
Additionally, have 2 sets of invalid PTE settings, one for
TF enabled, the other for TF disabled. The setting with
TF disabled, doesn't work with TF enabled.

Signed-off-by: Mukul Joshi 


Acked-by: Christian König 


---
v1->v2:
- Update handling according to Christian's feedback.

v2->v3:
- Remove ASIC specific callback (Felix).

v3->v4:
- Add noretry flag to amdgpu->gmc. This allows to set
   ASIC specific flags.

  drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h   |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  2 +-
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h|  6 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 31 +++
  drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c|  1 +
  drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c|  1 +
  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c |  1 +
  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c |  1 +
  drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c |  1 +
  9 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
index 56d73fade568..fdc25cd559b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h
@@ -331,6 +331,8 @@ struct amdgpu_gmc {
u64 VM_CONTEXT_PAGE_TABLE_END_ADDR_LO32[16];
u64 VM_CONTEXT_PAGE_TABLE_END_ADDR_HI32[16];
u64 MC_VM_MX_L1_TLB_CNTL;
+
+   u64 noretry_flags;
  };
  
  #define amdgpu_gmc_flush_gpu_tlb(adev, vmid, vmhub, type) ((adev)->gmc.gmc_funcs->flush_gpu_tlb((adev), (vmid), (vmhub), (type)))

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index eff73c428b12..8c7861a4d75d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2604,7 +2604,7 @@ bool amdgpu_vm_handle_fault(struct amdgpu_device *adev, 
u32 pasid,
/* Intentionally setting invalid PTE flag
 * combination to force a no-retry-fault
 */
-   flags = AMDGPU_PTE_SNOOPED | AMDGPU_PTE_PRT;
+   flags = AMDGPU_VM_NORETRY_FLAGS;
value = 0;
} else if (amdgpu_vm_fault_stop == AMDGPU_VM_FAULT_STOP_NEVER) {
/* Redirect the access to the dummy page */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 9c85d494f2a2..b81fcb962d8f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
@@ -84,7 +84,13 @@ struct amdgpu_mem_stats;
  /* PDE Block Fragment Size for VEGA10 */
  #define AMDGPU_PDE_BFS(a) ((uint64_t)a << 59)
  
+/* Flag combination to set no-retry with TF disabled */

+#define AMDGPU_VM_NORETRY_FLAGS(AMDGPU_PTE_EXECUTABLE | AMDGPU_PDE_PTE 
| \
+   AMDGPU_PTE_TF)
  
+/* Flag combination to set no-retry with TF enabled */

+#define AMDGPU_VM_NORETRY_FLAGS_TF (AMDGPU_PTE_VALID | AMDGPU_PTE_SYSTEM | \
+  AMDGPU_PTE_PRT)
  /* For GFX9 */
  #define AMDGPU_PTE_MTYPE_VG10(a)  ((uint64_t)(a) << 57)
  #define AMDGPU_PTE_MTYPE_VG10_MASKAMDGPU_PTE_MTYPE_VG10(3ULL)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
index dea1a64be44d..24ddf6a0512a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
@@ -778,6 +778,27 @@ int amdgpu_vm_pde_update(struct amdgpu_vm_update_params 
*params,
1, 0, flags);
  }
  
+/**

+ * amdgpu_vm_pte_update_noretry_flags - Update PTE no-retry flags
+ *
+ * @adev - amdgpu_device pointer
+ * @flags: pointer to PTE flags
+ *
+ * Update PTE no-retry flags when TF is enabled.
+ */
+static void amdgpu_vm_pte_update_noretry_flags(struct amdgpu_device *adev,
+   uint64_t *flags)
+{
+   /*
+* Update no-retry flags with the corresponding TF
+* no-retry combination.
+*/
+   if ((*flags & AMDGPU_VM_NORETRY_FLAGS) == AMDGPU_VM_NORETRY_FLAGS) {
+   *flags &= ~AMDGPU_VM_NORETRY_FLAGS;
+   *flags |= adev->gmc.noretry_flags;
+   }
+}
+
  /*
   * amdgpu_vm_pte_update_flags - figure out flags for PTE updates
   *
@@ -804,6 +825,16 @@ static void amdgpu_vm_pte_update_flags(struct 
amdgpu_vm_update_params *params,
flags |= AMDGPU_PTE_EXECUTABLE;
}
  
+	/*

+* Update no-retry flags to use the no-retry flag combination
+* with TF enabled. The AMDGPU_VM_NORETRY_FLAGS flag combination
+* does not work when TF is enabled. So, replace them with
+* AMDGPU_VM_NORETRY_FLAGS_TF 

Re: [PATCH] drm/amdgpu: return an error of query_video_caps is not set

2023-06-29 Thread Christian König

Am 29.06.23 um 15:22 schrieb Alex Deucher:

Should only be an issue for bring up when the function
pointer is not set, but check it anyway to be safe.

Signed-off-by: Alex Deucher 


Reviewed-by: Christian König 


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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index cca5a495611f3..85a0d5f419c87 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1102,6 +1102,9 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
struct drm_amdgpu_info_video_caps *caps;
int r;
  
+		if (!adev->asic_funcs->query_video_codecs)

+   return -EINVAL;
+
switch (info->video_cap.type) {
case AMDGPU_INFO_VIDEO_CAPS_DECODE:
r = amdgpu_asic_query_video_codecs(adev, false, 
);




Re: [PATCH 4/6] drm/amd/display: Fix warning about msleep in amdgpu_dm_helpers.c

2023-06-29 Thread Harry Wentland



On 6/29/23 09:53, Alex Deucher wrote:
> On Thu, Jun 29, 2023 at 12:47 AM Srinivasan Shanmugam
>  wrote:
>>
>> Fixes the following category of checkpatch warning:
>>
>> WARNING: msleep < 20ms can sleep for up to 20ms; see 
>> Documentation/timers/timers-howto.rst
>> +   msleep(10);
>>
>> Cc: Rodrigo Siqueira 
>> Cc: Aurabindo Pillai 
>> Signed-off-by: Srinivasan Shanmugam 
>> ---
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
>> index c13b70629be6..a6be04ad387f 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
>> @@ -643,7 +643,7 @@ static bool execute_synaptics_rc_command(struct 
>> drm_dp_aux *aux,
>> if (rc_cmd == cmd)
>> // active is 0
>> break;
>> -   msleep(10);
>> +   msleep(20);
> 
> This doesn't seem like the right fix.  The warning seems somewhat
> bogus to begin with.  If the length really matters, I guess we should
> use usleep_range(), but if not, I don't see any reason not to leave it
> as is.  Sure, it might sleep longer, but it might not.  Better to have
> the code stay as is since 10 was presumably the intended sleep time.
> 

I agree.

Harry

> Alex
> 
> 
>> }
>>
>> // read rc result
>> --
>> 2.25.1
>>



Re: [PATCH 5/6] drm/amd/display: Clean up warnings in amdgpu_dm _mst_types, _plane, _psr.c

2023-06-29 Thread Alex Deucher
Reviewed-by: Alex Deucher 

On Thu, Jun 29, 2023 at 12:47 AM Srinivasan Shanmugam
 wrote:
>
> Fix the following warnings reported by checkpatch:
>
> WARNING: Missing a blank line after declarations
> WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
>
> Cc: Rodrigo Siqueira 
> Cc: Aurabindo Pillai 
> Signed-off-by: Srinivasan Shanmugam 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 4 ++--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c   | 1 +
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 46d0a8f57e55..95eefa6b4f2f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -296,6 +296,7 @@ static int dm_dp_mst_get_modes(struct drm_connector 
> *connector)
>
> if (!aconnector->edid) {
> struct edid *edid;
> +
> edid = drm_dp_mst_get_edid(connector, 
> >mst_root->mst_mgr, aconnector->mst_output_port);
>
> if (!edid) {
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> index 322668973747..de1c7026ffcd 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
> @@ -164,7 +164,7 @@ static bool modifier_has_dcc(uint64_t modifier)
> return IS_AMD_FMT_MOD(modifier) && AMD_FMT_MOD_GET(DCC, modifier);
>  }
>
> -static unsigned modifier_gfx9_swizzle_mode(uint64_t modifier)
> +static unsigned int modifier_gfx9_swizzle_mode(uint64_t modifier)
>  {
> if (modifier == DRM_FORMAT_MOD_LINEAR)
> return 0;
> @@ -581,7 +581,7 @@ static void add_gfx11_modifiers(struct amdgpu_device 
> *adev,
> int pkrs = 0;
> u32 gb_addr_config;
> u8 i = 0;
> -   unsigned swizzle_r_x;
> +   unsigned int swizzle_r_x;
> uint64_t modifier_r_x;
> uint64_t modifier_dcc_best;
> uint64_t modifier_dcc_4k;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> index 4f61d4f257cd..08ce3bb8f640 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c
> @@ -166,6 +166,7 @@ bool amdgpu_dm_psr_enable(struct dc_stream_state *stream)
>  */
> if (vsync_rate_hz != 0) {
> unsigned int frame_time_microsec = 100 / vsync_rate_hz;
> +
> num_frames_static = (3 / frame_time_microsec) + 1;
> }
>
> --
> 2.25.1
>


Re: [PATCH 3/6] drm/amd/display: Clean up warnings in amdgpu_dm_pp_smu.c

2023-06-29 Thread Alex Deucher
Reviewed-by: Alex Deucher 

On Thu, Jun 29, 2023 at 12:47 AM Srinivasan Shanmugam
 wrote:
>
> Fixes the following category of checkpatch warning:
>
> WARNING: Block comments use a trailing */ on a separate line
> +* non-boosted one. */
>
> WARNING: suspect code indent for conditional statements (8, 24)
> +   if ((adev->asic_type >= CHIP_POLARIS10) &&
> [...]
> +   return true;
>
> Cc: Rodrigo Siqueira 
> Cc: Aurabindo Pillai 
> Signed-off-by: Srinivasan Shanmugam 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c  | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> index 75284e2cec74..848c5b4bb301 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c
> @@ -334,7 +334,8 @@ bool dm_pp_get_clock_levels_by_type(
> if (dc_clks->clocks_in_khz[i] > 
> validation_clks.engine_max_clock) {
> /* This clock is higher the validation clock.
>  * Than means the previous one is the highest
> -* non-boosted one. */
> +* non-boosted one.
> +*/
> DRM_INFO("DM_PPLIB: reducing engine clock 
> level from %d to %d\n",
> dc_clks->num_levels, i);
> dc_clks->num_levels = i > 0 ? i : 1;
> @@ -406,10 +407,10 @@ bool dm_pp_notify_wm_clock_changes(
>  * TODO: expand this to other ASICs
>  */
> if ((adev->asic_type >= CHIP_POLARIS10) &&
> -(adev->asic_type <= CHIP_VEGAM) &&
> -!amdgpu_dpm_set_watermarks_for_clocks_ranges(adev,
> -   (void *)wm_with_clock_ranges))
> -   return true;
> +   (adev->asic_type <= CHIP_VEGAM) &&
> +   !amdgpu_dpm_set_watermarks_for_clocks_ranges(adev,
> +(void 
> *)wm_with_clock_ranges))
> +   return true;
>
> return false;
>  }
> --
> 2.25.1
>


Re: [PATCH 1/6] drm/amd/display: Remove unnecessary casts in amdgpu_dm_helpers.c

2023-06-29 Thread Alex Deucher
Reviewed-by: Alex Deucher 

On Thu, Jun 29, 2023 at 12:47 AM Srinivasan Shanmugam
 wrote:
>
> Fixes the following category of checkpatch complaints:
>
> WARNING: unnecessary cast may hide bugs, see 
> http://c-faq.com/malloc/mallocnocast.html
> +   char *buf = (char *)kvcalloc(total, sizeof(char), GFP_KERNEL);
>
> Cc: Rodrigo Siqueira 
> Cc: Aurabindo Pillai 
> Signed-off-by: Srinivasan Shanmugam 
> Reviewed-by: Christian König 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index d9a482908380..c13b70629be6 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -426,7 +426,7 @@ void dm_dtn_log_append_v(struct dc_context *ctx,
> total = log_ctx->pos + n + 1;
>
> if (total > log_ctx->size) {
> -   char *buf = (char *)kvcalloc(total, sizeof(char), GFP_KERNEL);
> +   char *buf = kvcalloc(total, sizeof(char), GFP_KERNEL);
>
> if (buf) {
> memcpy(buf, log_ctx->buf, log_ctx->pos);
> --
> 2.25.1
>


Re: [PATCH 6/6] drm/amdgpu: use the new drm_exec object for CS v2

2023-06-29 Thread Christian König




Am 29.06.23 um 10:20 schrieb Tatsuyuki Ishi:

On 6/28/23 19:44, Christian König wrote:
@@ -958,18 +904,57 @@ static int amdgpu_cs_parser_bos(struct 
amdgpu_cs_parser *p,

  e->user_invalidated = userpage_invalidated;
  }
  -    r = ttm_eu_reserve_buffers(>ticket, >validated, true,
-   );
-    if (unlikely(r != 0)) {
-    if (r != -ERESTARTSYS)
-    DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
-    goto out_free_user_pages;
+    drm_exec_until_all_locked(>exec) {
+    r = amdgpu_vm_lock_pd(>vm, >exec, 1 + p->gang_size);
+    drm_exec_retry_on_contention(>exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+
+    amdgpu_bo_list_for_each_entry(e, p->bo_list) {
+    /* One fence for TTM and one for each CS job */
+    r = drm_exec_prepare_obj(>exec, >bo->tbo.base,
+ 1 + p->gang_size);
+    drm_exec_retry_on_contention(>exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+
+    e->bo_va = amdgpu_vm_bo_find(vm, e->bo);
+    e->range = NULL;

Still leaking.


Scratching my head, I though I fixed this.

Thanks for pointing this out,
Christian.


+    }
+
+    if (p->uf_bo) {
+    r = drm_exec_prepare_obj(>exec, >uf_bo->tbo.base,
+ 1 + p->gang_size);
+    drm_exec_retry_on_contention(>exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+    }
  }






Re: [PATCH 4/6] drm/amd/display: Fix warning about msleep in amdgpu_dm_helpers.c

2023-06-29 Thread Alex Deucher
On Thu, Jun 29, 2023 at 12:47 AM Srinivasan Shanmugam
 wrote:
>
> Fixes the following category of checkpatch warning:
>
> WARNING: msleep < 20ms can sleep for up to 20ms; see 
> Documentation/timers/timers-howto.rst
> +   msleep(10);
>
> Cc: Rodrigo Siqueira 
> Cc: Aurabindo Pillai 
> Signed-off-by: Srinivasan Shanmugam 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index c13b70629be6..a6be04ad387f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -643,7 +643,7 @@ static bool execute_synaptics_rc_command(struct 
> drm_dp_aux *aux,
> if (rc_cmd == cmd)
> // active is 0
> break;
> -   msleep(10);
> +   msleep(20);

This doesn't seem like the right fix.  The warning seems somewhat
bogus to begin with.  If the length really matters, I guess we should
use usleep_range(), but if not, I don't see any reason not to leave it
as is.  Sure, it might sleep longer, but it might not.  Better to have
the code stay as is since 10 was presumably the intended sleep time.

Alex


> }
>
> // read rc result
> --
> 2.25.1
>


Re: [patch V2] drm/amdkfd: Access gpuvm_export_dmabuf() api

2023-06-29 Thread David Francis




Does this read well.

drm/amdkfd: Access gpuvm_export_dmabuf() API to get Dmabuf

Directly invoking the function amdgpu_gem_prime_export() from within

KFD is not correct. By utilizing the KFD API to obtain Dmabuf, the

implementation can prevent the creation of multiple instances of

struct dma_buf.

Regards,

Ramesh


Looks good.

With the new commit message, patch is

Reviewed-by: David Francis


On 2023-06-22 17:10, Ramesh Errabolu wrote:

Call KFD api to get Dmabuf instead of calling GEM Prime API

Would appreciate a more detailed commit message to explain why the
KFD API is preferred over the GEM API.
With or without that change, this is
Reviewed-by: David Francis  


Signed-off-by: Ramesh Errabolu  


---

  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 11 +--

  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

index cf1db0ab3471..40ac093b5035 100644

--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c

@@ -1852,15 +1852,14 @@ static uint32_t get_process_num_bos(struct 
kfd_process *p)

     return num_of_bos;

  }

-static int criu_get_prime_handle(struct drm_gem_object *gobj, int flags,

+static int criu_get_prime_handle(struct kgd_mem *mem, int flags,

   u32 *shared_fd)

  {

     struct dma_buf *dmabuf;

     int ret;

-   dmabuf = amdgpu_gem_prime_export(gobj, flags);

-   if (IS_ERR(dmabuf)) {

-   ret = PTR_ERR(dmabuf);

+   ret = amdgpu_amdkfd_gpuvm_export_dmabuf(mem, );

+   if (ret) {

     pr_err("dmabuf export failed for the BO\n");

     return ret;

     }

@@ -1940,7 +1939,7 @@ static int criu_checkpoint_bos(struct kfd_process *p,

     }

     if (bo_bucket->alloc_flags

     & (KFD_IOC_ALLOC_MEM_FLAGS_VRAM | 
KFD_IOC_ALLOC_MEM_FLAGS_GTT)) {

-   ret = 
criu_get_prime_handle(_bo->tbo.base,

+   ret = criu_get_prime_handle(kgd_mem,

     bo_bucket->alloc_flags &

     
KFD_IOC_ALLOC_MEM_FLAGS_WRITABLE ? DRM_RDWR : 0,

     _bucket->dmabuf_fd);

@@ -2402,7 +2401,7 @@ static int criu_restore_bo(struct kfd_process *p,

     /* create the dmabuf object and export the bo */

     if (bo_bucket->alloc_flags

     & (KFD_IOC_ALLOC_MEM_FLAGS_VRAM | 
KFD_IOC_ALLOC_MEM_FLAGS_GTT)) {

-   ret = criu_get_prime_handle(_mem->bo->tbo.base, 
DRM_RDWR,

+   ret = criu_get_prime_handle(kgd_mem, DRM_RDWR,

     _bucket->dmabuf_fd);

     if (ret)

     return ret;

--

2.25.1


[PATCH] drm/amdgpu: return an error of query_video_caps is not set

2023-06-29 Thread Alex Deucher
Should only be an issue for bring up when the function
pointer is not set, but check it anyway to be safe.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index cca5a495611f3..85a0d5f419c87 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1102,6 +1102,9 @@ int amdgpu_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
struct drm_amdgpu_info_video_caps *caps;
int r;
 
+   if (!adev->asic_funcs->query_video_codecs)
+   return -EINVAL;
+
switch (info->video_cap.type) {
case AMDGPU_INFO_VIDEO_CAPS_DECODE:
r = amdgpu_asic_query_video_codecs(adev, false, 
);
-- 
2.41.0



Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

2023-06-29 Thread André Almeida




Em 27/06/2023 18:17, André Almeida escreveu:

Em 27/06/2023 14:47, Christian König escreveu:

Am 27.06.23 um 15:23 schrieb André Almeida:

Create a section that specifies how to deal with DRM device resets for
kernel and userspace drivers.

Acked-by: Pekka Paalanen 
Signed-off-by: André Almeida 
---

v4: 
https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@igalia.com/


Changes:
  - Grammar fixes (Randy)

  Documentation/gpu/drm-uapi.rst | 68 ++
  1 file changed, 68 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst 
b/Documentation/gpu/drm-uapi.rst

index 65fb3036a580..3cbffa25ed93 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -285,6 +285,74 @@ for GPU1 and GPU2 from different vendors, and a 
third handler for

  mmapped regular files. Threads cause additional pain with signal
  handling as well.
+Device reset
+
+
+The GPU stack is really complex and is prone to errors, from 
hardware bugs,
+faulty applications and everything in between the many layers. Some 
errors
+require resetting the device in order to make the device usable 
again. This

+sections describes the expectations for DRM and usermode drivers when a
+device resets and how to propagate the reset status.
+
+Kernel Mode Driver
+--
+
+The KMD is responsible for checking if the device needs a reset, and 
to perform
+it as needed. Usually a hang is detected when a job gets stuck 
executing. KMD
+should keep track of resets, because userspace can query any time 
about the

+reset stats for an specific context.


Maybe drop the part "for a specific context". Essentially the reset 
query could use global counters instead and we won't need the context 
any more here.




Right, I wrote like this to reflect how it's currently implemented.

If follow correctly what you meant, KMD could always notify the global 
count for UMD, and we would move to the UMD the responsibility to manage 
the reset counters, right? This would also simplify my 
DRM_IOCTL_GET_RESET proposal. I'll apply your suggestion to the next doc 
version.




Actually, if we drop the context identifier we would lose the ability to 
track which is the guilty context. Vulkan API doesn't seem to care about 
this, but OpenGL does.



Apart from that this sounds good to me, feel free to add my rb.

Regards,
Christian.




RE: [PATCH] drm/amdgpu: skip address adjustment for GFX RAS injection

2023-06-29 Thread Li, Candice
[AMD Official Use Only - General]

Reviewed-by: Candice Li 



Thanks,
Candice

-Original Message-
From: amd-gfx  On Behalf Of Tao Zhou
Sent: Thursday, June 29, 2023 6:01 PM
To: amd-gfx@lists.freedesktop.org; Li, Candice ; Zhang, 
Hawking ; Yang, Stanley ; Chai, 
Thomas 
Cc: Zhou1, Tao 
Subject: [PATCH] drm/amdgpu: skip address adjustment for GFX RAS injection

The address parameter of GFX RAS injection isn't related to XGMI node
number, keep it unchanged.

Signed-off-by: Tao Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 046659bd4f9e..5371fbd3fe17 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1163,7 +1163,8 @@ int amdgpu_ras_error_inject(struct amdgpu_device *adev,
}

/* Calculate XGMI relative offset */
-   if (adev->gmc.xgmi.num_physical_nodes > 1) {
+   if (adev->gmc.xgmi.num_physical_nodes > 1 &&
+   info->head.block != AMDGPU_RAS_BLOCK__GFX) {
block_info.address =
amdgpu_xgmi_get_relative_phy_addr(adev,
  block_info.address);
--
2.35.1



[PATCH] drm/amdgpu: skip address adjustment for GFX RAS injection

2023-06-29 Thread Tao Zhou
The address parameter of GFX RAS injection isn't related to XGMI node
number, keep it unchanged.

Signed-off-by: Tao Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
index 046659bd4f9e..5371fbd3fe17 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c
@@ -1163,7 +1163,8 @@ int amdgpu_ras_error_inject(struct amdgpu_device *adev,
}
 
/* Calculate XGMI relative offset */
-   if (adev->gmc.xgmi.num_physical_nodes > 1) {
+   if (adev->gmc.xgmi.num_physical_nodes > 1 &&
+   info->head.block != AMDGPU_RAS_BLOCK__GFX) {
block_info.address =
amdgpu_xgmi_get_relative_phy_addr(adev,
  block_info.address);
-- 
2.35.1



[PATCH] drm/amdgpu: Fix the mmio remap failure issue

2023-06-29 Thread Ma Jun
Initialize the rmmio_remap to fix the mmio remap issue when start the
kfdtest. The error message is as follows.
"Failed to map remapped mmio page on gpu_mem 0"

Signed-off-by: Ma Jun 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 6a8494f98d3e..979f5223877f 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1458,8 +1458,14 @@ static const struct amdgpu_asic_funcs vi_asic_funcs =
 
 static int vi_common_early_init(void *handle)
 {
+#define MMIO_REG_HOLE_OFFSET (0x8 - PAGE_SIZE)
struct amdgpu_device *adev = (struct amdgpu_device *)handle;
 
+   if (!amdgpu_sriov_vf(adev)) {
+   adev->rmmio_remap.reg_offset = MMIO_REG_HOLE_OFFSET;
+   adev->rmmio_remap.bus_addr = adev->rmmio_base + 
MMIO_REG_HOLE_OFFSET;
+   }
+
if (adev->flags & AMD_IS_APU) {
adev->smc_rreg = _smc_rreg;
adev->smc_wreg = _smc_wreg;
-- 
2.34.1



Re: [PATCH 4/6] drm/amdgpu: use drm_exec for GEM and CSA handling

2023-06-29 Thread Tatsuyuki Ishi

On 6/28/23 19:44, Christian König wrote:


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 74055cba3dc9..6811fc866494 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -728,36 +723,37 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void 
*data,
return -EINVAL;
}
  
-	INIT_LIST_HEAD();

-   INIT_LIST_HEAD();
if ((args->operation != AMDGPU_VA_OP_CLEAR) &&
!(args->flags & AMDGPU_VM_PAGE_PRT)) {
gobj = drm_gem_object_lookup(filp, args->handle);
if (gobj == NULL)
return -ENOENT;
abo = gem_to_amdgpu_bo(gobj);
-   tv.bo = >tbo;
-   if (abo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
-   tv.num_shared = 1;
-   else
-   tv.num_shared = 0;
-   list_add(, );
} else {
gobj = NULL;
abo = NULL;
}
  
-	amdgpu_vm_get_pd_bo(>vm, , _pd);

+   drm_exec_init(, DRM_EXEC_INTERRUPTIBLE_WAIT);


Sorry, I missed this last time, but this needs to allow duplicates as well or 
mapping
always_valid BOs doesn't work.


+   drm_exec_until_all_locked() {
+   if (gobj) {
+   r = drm_exec_lock_obj(, gobj);
+   drm_exec_retry_on_contention();
+   if (unlikely(r))
+   goto error;
+   }
  
-	r = ttm_eu_reserve_buffers(, , true, );

-   if (r)
-   goto error_unref;
+   r = amdgpu_vm_lock_pd(>vm, , 2);
+   drm_exec_retry_on_contention();
+   if (unlikely(r))
+   goto error;
+   }
  
  	if (abo) {

bo_va = amdgpu_vm_bo_find(>vm, abo);
if (!bo_va) {
r = -ENOENT;
-   goto error_backoff;
+   goto error;
}
} else if (args->operation != AMDGPU_VA_OP_CLEAR) {
bo_va = fpriv->prt_va;
@@ -794,10 +790,8 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
amdgpu_gem_va_update_vm(adev, >vm, bo_va,
args->operation);
  
-error_backoff:

-   ttm_eu_backoff_reservation(, );
-
-error_unref:
+error:
+   drm_exec_fini();
drm_gem_object_put(gobj);
return r;
  }


Re: [PATCH 6/6] drm/amdgpu: use the new drm_exec object for CS v2

2023-06-29 Thread Tatsuyuki Ishi

On 6/28/23 19:44, Christian König wrote:

@@ -958,18 +904,57 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser 
*p,
e->user_invalidated = userpage_invalidated;
}
  
-	r = ttm_eu_reserve_buffers(>ticket, >validated, true,

-  );
-   if (unlikely(r != 0)) {
-   if (r != -ERESTARTSYS)
-   DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
-   goto out_free_user_pages;
+   drm_exec_until_all_locked(>exec) {
+   r = amdgpu_vm_lock_pd(>vm, >exec, 1 + p->gang_size);
+   drm_exec_retry_on_contention(>exec);
+   if (unlikely(r))
+   goto out_free_user_pages;
+
+   amdgpu_bo_list_for_each_entry(e, p->bo_list) {
+   /* One fence for TTM and one for each CS job */
+   r = drm_exec_prepare_obj(>exec, >bo->tbo.base,
+1 + p->gang_size);
+   drm_exec_retry_on_contention(>exec);
+   if (unlikely(r))
+   goto out_free_user_pages;
+
+   e->bo_va = amdgpu_vm_bo_find(vm, e->bo);
+   e->range = NULL;

Still leaking.

+   }
+
+   if (p->uf_bo) {
+   r = drm_exec_prepare_obj(>exec, >uf_bo->tbo.base,
+1 + p->gang_size);
+   drm_exec_retry_on_contention(>exec);
+   if (unlikely(r))
+   goto out_free_user_pages;
+   }
}




Re: [PATCH 2/2] drm/amdgpu: use psp_execute_load_ip_fw_cmd_buf instead

2023-06-29 Thread Lang Yu
Ping.

On 06/27/ , Lang Yu wrote:
> Replace the old ones with psp_execute_load_ip_fw_cmd_buf.
> 
> Signed-off-by: Lang Yu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 31 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h |  2 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c |  9 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h |  2 ++
>  drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c   |  4 +---
>  drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c   |  4 +---
>  drivers/gpu/drm/amd/amdgpu/vcn_v3_0.c   |  4 +---
>  drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c   |  4 +---
>  drivers/gpu/drm/amd/amdgpu/vcn_v4_0_3.c |  4 +---
>  9 files changed, 20 insertions(+), 44 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index a1cb541f315f..b61963112118 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -2474,21 +2474,11 @@ int psp_execute_load_ip_fw_cmd_buf(struct 
> amdgpu_device *adev,
>   return ret;
>  }
>  
> -static int psp_execute_non_psp_fw_load(struct psp_context *psp,
> -   struct amdgpu_firmware_info *ucode)
> +static inline
> +int psp_execute_non_psp_fw_load(struct psp_context *psp,
> + struct amdgpu_firmware_info *ucode)
>  {
> - int ret = 0;
> - struct psp_gfx_cmd_resp *cmd = acquire_psp_cmd_buf(psp);
> -
> - ret = psp_prep_load_ip_fw_cmd_buf(ucode, cmd);
> - if (!ret) {
> - ret = psp_cmd_submit_buf(psp, ucode, cmd,
> -  psp->fence_buf_mc_addr);
> - }
> -
> - release_psp_cmd_buf(psp);
> -
> - return ret;
> + return psp_execute_load_ip_fw_cmd_buf(psp->adev, ucode, 0, 0, 0);
>  }
>  
>  static int psp_load_smu_fw(struct psp_context *psp)
> @@ -2946,19 +2936,6 @@ int psp_rlc_autoload_start(struct psp_context *psp)
>   return ret;
>  }
>  
> -int psp_update_vcn_sram(struct amdgpu_device *adev, int inst_idx,
> - uint64_t cmd_gpu_addr, int cmd_size)
> -{
> - struct amdgpu_firmware_info ucode = {0};
> -
> - ucode.ucode_id = inst_idx ? AMDGPU_UCODE_ID_VCN1_RAM :
> - AMDGPU_UCODE_ID_VCN0_RAM;
> - ucode.mc_addr = cmd_gpu_addr;
> - ucode.ucode_size = cmd_size;
> -
> - return psp_execute_non_psp_fw_load(>psp, );
> -}
> -
>  int psp_ring_cmd_submit(struct psp_context *psp,
>   uint64_t cmd_buf_mc_addr,
>   uint64_t fence_mc_addr,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> index bd324fed6237..e49984a9d570 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> @@ -459,8 +459,6 @@ extern int psp_wait_for_spirom_update(struct psp_context 
> *psp, uint32_t reg_inde
>   uint32_t field_val, uint32_t mask, uint32_t 
> msec_timeout);
>  
>  int psp_gpu_reset(struct amdgpu_device *adev);
> -int psp_update_vcn_sram(struct amdgpu_device *adev, int inst_idx,
> - uint64_t cmd_gpu_addr, int cmd_size);
>  
>  int psp_execute_load_ip_fw_cmd_buf(struct amdgpu_device *adev,
>  struct amdgpu_firmware_info *ucode,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> index d37ebd4402ef..1805cd042d34 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
> @@ -1257,3 +1257,12 @@ int amdgpu_vcn_ras_sw_init(struct amdgpu_device *adev)
>  
>   return 0;
>  }
> +
> +int amdgpu_vcn_psp_update_sram(struct amdgpu_device *adev, int inst_idx)
> +{
> + return psp_execute_load_ip_fw_cmd_buf(adev, NULL,
> + inst_idx ? AMDGPU_UCODE_ID_VCN1_RAM : AMDGPU_UCODE_ID_VCN0_RAM,
> + adev->vcn.inst[inst_idx].dpg_sram_gpu_addr,
> + 
> (uint32_t)((uintptr_t)adev->vcn.inst[inst_idx].dpg_sram_curr_addr -
> +
> (uintptr_t)adev->vcn.inst[inst_idx].dpg_sram_cpu_addr));
> +}
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> index 92d5534df5f4..3ac5ad91ed08 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.h
> @@ -414,4 +414,6 @@ int amdgpu_vcn_ras_late_init(struct amdgpu_device *adev,
>   struct ras_common_if *ras_block);
>  int amdgpu_vcn_ras_sw_init(struct amdgpu_device *adev);
>  
> +int amdgpu_vcn_psp_update_sram(struct amdgpu_device *adev, int inst_idx);
> +
>  #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c 
> b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
> index c975aed2f6c7..74cd1522067c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c
> @@ -881,9 +881,7 @@ static int vcn_v2_0_start_dpg_mode(struct amdgpu_device 
> *adev, bool indirect)
>   UVD_MASTINT_EN__VCPU_EN_MASK, 0, 

Re: [PATCH 1/2] drm/amdgpu: extract a PSP function to execute IP FW loading commands

2023-06-29 Thread Lang Yu
Ping.

On 06/27/ , Lang Yu wrote:
> This function is more general and easy to use by more clients.
> 
> Signed-off-by: Lang Yu 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 29 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h |  6 +
>  2 files changed, 35 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> index a33c155dddcf..a1cb541f315f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
> @@ -2445,6 +2445,35 @@ static int psp_prep_load_ip_fw_cmd_buf(struct 
> amdgpu_firmware_info *ucode,
>   return ret;
>  }
>  
> +int psp_execute_load_ip_fw_cmd_buf(struct amdgpu_device *adev,
> +struct amdgpu_firmware_info *ucode,
> +uint32_t ucode_id,
> +uint64_t cmd_buf_gpu_addr,
> +int cmd_buf_size)
> +{
> + struct amdgpu_firmware_info fw_info = {
> + .ucode_id = ucode_id,
> + .mc_addr = cmd_buf_gpu_addr,
> + .ucode_size = cmd_buf_size,
> + };
> + struct psp_context *psp = >psp;
> + struct psp_gfx_cmd_resp *cmd =
> + acquire_psp_cmd_buf(psp);
> + int ret;
> +
> + if (!ucode)
> + ucode = _info;
> +
> + ret = psp_prep_load_ip_fw_cmd_buf(ucode, cmd);
> + if (!ret)
> + ret = psp_cmd_submit_buf(psp, ucode, cmd,
> +  psp->fence_buf_mc_addr);
> +
> + release_psp_cmd_buf(psp);
> +
> + return ret;
> +}
> +
>  static int psp_execute_non_psp_fw_load(struct psp_context *psp,
> struct amdgpu_firmware_info *ucode)
>  {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> index 4847aacdf9dc..bd324fed6237 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.h
> @@ -462,6 +462,12 @@ int psp_gpu_reset(struct amdgpu_device *adev);
>  int psp_update_vcn_sram(struct amdgpu_device *adev, int inst_idx,
>   uint64_t cmd_gpu_addr, int cmd_size);
>  
> +int psp_execute_load_ip_fw_cmd_buf(struct amdgpu_device *adev,
> +struct amdgpu_firmware_info *ucode,
> +uint32_t ucode_id,
> +uint64_t cmd_buf_gpu_addr,
> +int cmd_buf_size);
> +
>  int psp_ta_init_shared_buf(struct psp_context *psp,
> struct ta_mem_context *mem_ctx);
>  void psp_ta_free_shared_buf(struct ta_mem_context *mem_ctx);
> -- 
> 2.25.1
>