Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!"

2021-06-29 Thread Alex Deucher
On Wed, Jun 30, 2021 at 12:45 AM Ketsui  wrote:
>
> >I think the 3200G may be a raven or raven2 variant rather than
> picasso.
>
> Are you sure? Examining vbios_version yields this on my system:
>
> $ cat /sys/class/drm/card0/device/vbios_version
> 113-PICASSO-114
>

I could be wrong.  I can't remember what marketing names map to what
asics.  I can tell if you can get your dmesg output.

Alex

>
> >Can you try the latest firmware from upstream:
> >https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdgpu
>
> Sure.
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!"

2021-06-29 Thread Ketsui
>I think the 3200G may be a raven or raven2 variant rather than
picasso.

Are you sure? Examining vbios_version yields this on my system:

$ cat /sys/class/drm/card0/device/vbios_version
113-PICASSO-114


>Can you try the latest firmware from 
>upstream:>https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdgpu
> 
>

Sure.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amdgpu: Conditionally reset SDMA RAS error counts

2021-06-29 Thread Mukul Joshi
Reset SDMA RAS error counts during init only if persistent
EDC harvesting is not supported.

Signed-off-by: Mukul Joshi 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index f6881d99609b..8931000dcd41 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1896,8 +1896,11 @@ static int sdma_v4_0_late_init(void *handle)
 
sdma_v4_0_setup_ulv(adev);
 
-   if (adev->sdma.funcs && adev->sdma.funcs->reset_ras_error_count)
-   adev->sdma.funcs->reset_ras_error_count(adev);
+   if (!amdgpu_persistent_edc_harvesting_supported(adev)) {
+   if (adev->sdma.funcs &&
+   adev->sdma.funcs->reset_ras_error_count)
+   adev->sdma.funcs->reset_ras_error_count(adev);
+   }
 
if (adev->sdma.funcs && adev->sdma.funcs->ras_late_init)
return adev->sdma.funcs->ras_late_init(adev, _info);
-- 
2.17.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdkfd: inc counter on child ranges with xnack off

2021-06-29 Thread Felix Kuehling
Am 2021-06-29 um 5:48 p.m. schrieb Alex Sierra:
> During GPU page table invalidation with xnack off, new ranges
> split may occur concurrently in the same prange. Creating a new
> child per split. Each child should also increment its
> invalid counter, to assure GPU page table updates in these
> ranges.
>
> Signed-off-by: Alex Sierra 

One formatting nit-pick inline. With that fixed, the patch is

Reviewed-by: Felix Kuehling 


> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> index 00b46846a5e0..e3b4f684393e 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> @@ -1590,6 +1590,7 @@ svm_range_evict(struct svm_range *prange, struct 
> mm_struct *mm,
>   unsigned long start, unsigned long last)
>  {
>   struct svm_range_list *svms = prange->svms;
> + struct svm_range *pchild;
>   struct kfd_process *p;
>   int r = 0;
>  
> @@ -1601,7 +1602,19 @@ svm_range_evict(struct svm_range *prange, struct 
> mm_struct *mm,
>   if (!p->xnack_enabled) {
>   int evicted_ranges;
>  
> - atomic_inc(>invalid);
> + list_for_each_entry(pchild, >child_list, child_list) {
> + mutex_lock_nested(>lock, 1);
> + if (pchild->start <= last && pchild->last >= start) {
> + pr_debug("increment pchild invalid [0x%lx 
> 0x%lx]\n",
> + pchild->start, pchild->last);

Indent this line one more TAB.

Regards,
  Felix


> + atomic_inc(>invalid);
> + }
> + mutex_unlock(>lock);
> + }
> +
> + if (prange->start <= last && prange->last >= start)
> + atomic_inc(>invalid);
> +
>   evicted_ranges = atomic_inc_return(>evicted_ranges);
>   if (evicted_ranges != 1)
>   return r;
> @@ -1618,7 +1631,6 @@ svm_range_evict(struct svm_range *prange, struct 
> mm_struct *mm,
>   schedule_delayed_work(>restore_work,
>   msecs_to_jiffies(AMDGPU_SVM_RANGE_RESTORE_DELAY_MS));
>   } else {
> - struct svm_range *pchild;
>   unsigned long s, l;
>  
>   pr_debug("invalidate unmap svms 0x%p [0x%lx 0x%lx] from GPUs\n",
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amdkfd: inc counter on child ranges with xnack off

2021-06-29 Thread Alex Sierra
During GPU page table invalidation with xnack off, new ranges
split may occur concurrently in the same prange. Creating a new
child per split. Each child should also increment its
invalid counter, to assure GPU page table updates in these
ranges.

Signed-off-by: Alex Sierra 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 00b46846a5e0..e3b4f684393e 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1590,6 +1590,7 @@ svm_range_evict(struct svm_range *prange, struct 
mm_struct *mm,
unsigned long start, unsigned long last)
 {
struct svm_range_list *svms = prange->svms;
+   struct svm_range *pchild;
struct kfd_process *p;
int r = 0;
 
@@ -1601,7 +1602,19 @@ svm_range_evict(struct svm_range *prange, struct 
mm_struct *mm,
if (!p->xnack_enabled) {
int evicted_ranges;
 
-   atomic_inc(>invalid);
+   list_for_each_entry(pchild, >child_list, child_list) {
+   mutex_lock_nested(>lock, 1);
+   if (pchild->start <= last && pchild->last >= start) {
+   pr_debug("increment pchild invalid [0x%lx 
0x%lx]\n",
+   pchild->start, pchild->last);
+   atomic_inc(>invalid);
+   }
+   mutex_unlock(>lock);
+   }
+
+   if (prange->start <= last && prange->last >= start)
+   atomic_inc(>invalid);
+
evicted_ranges = atomic_inc_return(>evicted_ranges);
if (evicted_ranges != 1)
return r;
@@ -1618,7 +1631,6 @@ svm_range_evict(struct svm_range *prange, struct 
mm_struct *mm,
schedule_delayed_work(>restore_work,
msecs_to_jiffies(AMDGPU_SVM_RANGE_RESTORE_DELAY_MS));
} else {
-   struct svm_range *pchild;
unsigned long s, l;
 
pr_debug("invalidate unmap svms 0x%p [0x%lx 0x%lx] from GPUs\n",
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu/display: drop unused variable

2021-06-29 Thread Harry Wentland
On 2021-06-29 5:02 p.m., Alex Deucher wrote:
> Remove unused variable.
> 
> Fixes: 00858131205f69 ("Revert "drm/amd/display: Fix overlay validation by 
> considering cursors"")
> Signed-off-by: Alex Deucher 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index f14b5468b7ee..e034017daa1a 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -10221,7 +10221,7 @@ static int validate_overlay(struct drm_atomic_state 
> *state)
>  {
>   int i;
>   struct drm_plane *plane;
> - struct drm_plane_state *old_plane_state, *new_plane_state;
> + struct drm_plane_state *new_plane_state;
>   struct drm_plane_state *primary_state, *overlay_state = NULL;
>  
>   /* Check if primary plane is contained inside overlay */
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amdgpu/display: drop unused variable

2021-06-29 Thread Alex Deucher
Remove unused variable.

Fixes: 00858131205f69 ("Revert "drm/amd/display: Fix overlay validation by 
considering cursors"")
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f14b5468b7ee..e034017daa1a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10221,7 +10221,7 @@ static int validate_overlay(struct drm_atomic_state 
*state)
 {
int i;
struct drm_plane *plane;
-   struct drm_plane_state *old_plane_state, *new_plane_state;
+   struct drm_plane_state *new_plane_state;
struct drm_plane_state *primary_state, *overlay_state = NULL;
 
/* Check if primary plane is contained inside overlay */
-- 
2.31.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v3 2/8] mm: remove extra ZONE_DEVICE struct page refcount

2021-06-29 Thread Ralph Campbell

On 6/28/21 9:46 AM, Felix Kuehling wrote:

Am 2021-06-17 um 3:16 p.m. schrieb Ralph Campbell:

On 6/17/21 8:16 AM, Alex Sierra wrote:

From: Ralph Campbell 

ZONE_DEVICE struct pages have an extra reference count that
complicates the
code for put_page() and several places in the kernel that need to
check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference count doesn't
need to
be treated specially for ZONE_DEVICE.

v2:
AS: merged this patch in linux 5.11 version

Signed-off-by: Ralph Campbell 
Signed-off-by: Alex Sierra 
---
   arch/powerpc/kvm/book3s_hv_uvmem.c |  2 +-
   drivers/gpu/drm/nouveau/nouveau_dmem.c |  2 +-
   fs/dax.c   |  4 +-
   include/linux/dax.h    |  2 +-
   include/linux/memremap.h   |  7 +--
   include/linux/mm.h | 44 -
   lib/test_hmm.c |  2 +-
   mm/internal.h  |  8 +++
   mm/memremap.c  | 68 +++---
   mm/migrate.c   |  5 --
   mm/page_alloc.c    |  3 ++
   mm/swap.c  | 45 ++---
   12 files changed, 45 insertions(+), 147 deletions(-)


I think it is great that you are picking this up and trying to revive it.

However, I have a number of concerns about how it affects existing
ZONE_DEVICE
MEMORY_DEVICE_GENERIC and MEMORY_DEVICE_FS_DAX users and I don't see this
addressing them. For example, dev_dax_probe() allocates
MEMORY_DEVICE_GENERIC
struct pages and then:
   dev_dax_fault()
     dev_dax_huge_fault()
   __dev_dax_pte_fault()
     vmf_insert_mixed()
which just inserts the PFN into the CPU page tables without increasing
the page
refcount so it is zero (whereas it was one before). But using
get_page() will
trigger VM_BUG_ON_PAGE() if it is enabled. There isn't any current
notion of
free verses allocated for these struct pages. I suppose init_page_count()
could be called on all the struct pages in dev_dax_probe() to fix that
though.

Hi Ralph,

For DEVICE_GENERIC pages free_zone_device_page doesn't do anything. So
I'm not sure what the reference counting is good for in this case.

Alex is going to add free_zone_device_page support for DEVICE_GENERIC
pages (patch 8 of this series). However, even then, it only does
anything if there is an actual call to put_page. Where would that call
come from in the dev_dax driver case?


Correct, the drivers/dax/device.c driver allocates MEMORY_DEVICE_GENERIC
struct pages and doesn't seem to allocate/free the page nor increment/decrement
the reference count but it does call vmf_insert_mixed() if the /dev/file
is mmap()'ed into a user process' address space. If devm_memremap_pages()
returns the array of ZONE_DEVICE struct pages initialized with a reference
count of zero, then the CPU page tables will have a PTE/PFN that points to
a struct page with a zero reference count. This goes against the normal
expectation in the rest of the mm code that assumes a page mapped by a CPU
has a non-zero reference count.
So yes, nothing "bad" happens because put_page() isn't called but the
reference count will differ from other drivers that call vmf_insert_mixed()
or vm_insert_page() where the page was allocated with alloc_pages() or
similar.


I'm even less clear about how to fix MEMORY_DEVICE_FS_DAX. File
systems have clear
allocate and free states for backing storage but there are the
complications with
the page cache references, etc. to consider. The >1 to 1 reference
count seems to
be used to tell when a page is idle (no I/O, reclaim scanners) rather
than free
(not allocated to any file) but I'm not 100% sure about that since I
don't really
understand all the issues around why a file system needs to have a DAX
mount option
besides knowing that the storage block size has to be a multiple of
the page size.

The only thing that happens in free_zone_device_page for FS_DAX pages is
wake_up_var(>_refcount). I guess, whoever is waiting for this
wake-up will need to be prepared to see a refcount 0 instead of 1 now. I
see these callers that would need to be updated:

./fs/ext4/inode.c:        error = ___wait_var_event(>_refcount,
./fs/ext4/inode.c-                atomic_read(>_refcount) == 1,
./fs/ext4/inode.c-                TASK_INTERRUPTIBLE, 0, 0,
./fs/ext4/inode.c-                ext4_wait_dax_page(ei));
--
./fs/fuse/dax.c:    return ___wait_var_event(>_refcount,
./fs/fuse/dax.c-            atomic_read(>_refcount) == 1,
TASK_INTERRUPTIBLE,
./fs/fuse/dax.c-            0, 0, fuse_wait_dax_page(inode));
--
./fs/xfs/xfs_file.c:    return ___wait_var_event(>_refcount,
./fs/xfs/xfs_file.c-            atomic_read(>_refcount) == 1,
TASK_INTERRUPTIBLE,
./fs/xfs/xfs_file.c-            0, 0, xfs_wait_dax_page(inode));

Regarding your page-cache comment, doesn't DAX mean that those file
pages are not in the page cache?


[PATCH] drm/amdgpu: add new dimgrey cavefish DID

2021-06-29 Thread Alex Deucher
Add new PCI device id.

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1a110b06cb6e..6419d75f1f18 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1198,6 +1198,7 @@ static const struct pci_device_id pciidlist[] = {
{0x1002, 0x73E0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH},
{0x1002, 0x73E1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH},
{0x1002, 0x73E2, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH},
+   {0x1002, 0x73E3, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH},
{0x1002, 0x73FF, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_DIMGREY_CAVEFISH},
 
/* Aldebaran */
-- 
2.31.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 11/11] drm/amdkfd: inc counter on child ranges with xnack off

2021-06-29 Thread Felix Kuehling

Am 2021-06-29 um 2:02 p.m. schrieb Alex Sierra:
> During GPU page table invalidation with xnack off, new ranges
> split may occur concurrently in the same prange. Creating a new
> child per split. Each child should also increment its
> invalid counter, to assure GPU page table updates in these
> ranges.
>
> Signed-off-by: Alex Sierra 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> index 294c9480a184..67605e4bc3c6 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> @@ -1622,6 +1622,7 @@ svm_range_evict(struct svm_range *prange, struct 
> mm_struct *mm,
>   unsigned long start, unsigned long last)
>  {
>   struct svm_range_list *svms = prange->svms;
> + struct svm_range *pchild;
>   struct kfd_process *p;
>   int r = 0;
>  
> @@ -1633,6 +1634,12 @@ svm_range_evict(struct svm_range *prange, struct 
> mm_struct *mm,
>   if (!p->xnack_enabled) {
>   int evicted_ranges;
>  
> + list_for_each_entry(pchild, >child_list, child_list) {
> + mutex_lock_nested(>lock, 1);

You should check the address range of the child range and only increment
pchild->invalid if it intersects with start..last.


> + atomic_inc(>invalid);
> + mutex_unlock(>lock);
> + }
> +
>   atomic_inc(>invalid);

Also add an address range check for the parent range.

Please make this the first patch in the series, or review/submit it
separately from the series. The series is about the reorganization of
VRAM management. This patch is an unrelated bug-fix.

Regards,
  Felix


>   evicted_ranges = atomic_inc_return(>evicted_ranges);
>   if (evicted_ranges != 1)
> @@ -1650,7 +1657,6 @@ svm_range_evict(struct svm_range *prange, struct 
> mm_struct *mm,
>   schedule_delayed_work(>restore_work,
>   msecs_to_jiffies(AMDGPU_SVM_RANGE_RESTORE_DELAY_MS));
>   } else {
> - struct svm_range *pchild;
>   unsigned long s, l;
>  
>   pr_debug("invalidate unmap svms 0x%p [0x%lx 0x%lx] from GPUs\n",
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 08/11] drm/amdkfd: skip migration for pages already in VRAM

2021-06-29 Thread Alex Sierra
Migration skipped for pages that are already in VRAM
domain. These could be the result of previous partial
migrations to SYS RAM, and prefetch back to VRAM.
Ex. Coherent pages in VRAM that were not written/invalidated after
a copy-on-write.

Signed-off-by: Alex Sierra 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 7b31c8596786..ae360d94c06f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -329,15 +329,13 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, 
struct svm_range *prange,
for (i = j = 0; i < npages; i++) {
struct page *spage;
 
-   dst[i] = vram_addr + (j << PAGE_SHIFT);
-   migrate->dst[i] = svm_migrate_addr_to_pfn(adev, dst[i]);
-   svm_migrate_get_vram_page(prange, migrate->dst[i]);
-
-   migrate->dst[i] = migrate_pfn(migrate->dst[i]);
-   migrate->dst[i] |= MIGRATE_PFN_LOCKED;
-
-   if (migrate->src[i] & MIGRATE_PFN_VALID) {
-   spage = migrate_pfn_to_page(migrate->src[i]);
+   spage = migrate_pfn_to_page(migrate->src[i]);
+   if (spage && !is_zone_device_page(spage)) {
+   dst[i] = vram_addr + (j << PAGE_SHIFT);
+   migrate->dst[i] = svm_migrate_addr_to_pfn(adev, dst[i]);
+   svm_migrate_get_vram_page(prange, migrate->dst[i]);
+   migrate->dst[i] = migrate_pfn(migrate->dst[i]);
+   migrate->dst[i] |= MIGRATE_PFN_LOCKED;
src[i] = dma_map_page(dev, spage, 0, PAGE_SIZE,
  DMA_TO_DEVICE);
r = dma_mapping_error(dev, src[i]);
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 03/11] drm/amdkfd: set owner ref to svm range prefault

2021-06-29 Thread Alex Sierra
svm_range_prefault is called right before migrations to VRAM,
to make sure pages are resident in system memory before the migration.
With partial migrations, this reference is used by hmm range get pages
to avoid migrating pages that are already in the same VRAM domain.

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 5 +++--
 drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 3 ++-
 3 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 8ce71c8142aa..33d4a118d05f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -519,7 +519,7 @@ svm_migrate_ram_to_vram(struct svm_range *prange, uint32_t 
best_loc,
 prange->start, prange->last, best_loc);
 
/* FIXME: workaround for page locking bug with invalid pages */
-   svm_range_prefault(prange, mm);
+   svm_range_prefault(prange, mm, SVM_ADEV_PGMAP_OWNER(adev));
 
start = prange->start << PAGE_SHIFT;
end = (prange->last + 1) << PAGE_SHIFT;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 125099a91e18..61db2a4db917 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -2705,7 +2705,8 @@ svm_range_best_prefetch_location(struct svm_range *prange)
 /* FIXME: This is a workaround for page locking bug when some pages are
  * invalid during migration to VRAM
  */
-void svm_range_prefault(struct svm_range *prange, struct mm_struct *mm)
+void svm_range_prefault(struct svm_range *prange, struct mm_struct *mm,
+   void *owner)
 {
struct hmm_range *hmm_range;
int r;
@@ -2716,7 +2717,7 @@ void svm_range_prefault(struct svm_range *prange, struct 
mm_struct *mm)
r = amdgpu_hmm_range_get_pages(>notifier, mm, NULL,
   prange->start << PAGE_SHIFT,
   prange->npages, _range,
-  false, true, NULL);
+  false, true, owner);
if (!r) {
amdgpu_hmm_range_get_pages_done(hmm_range);
prange->validated_once = true;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
index 1f88bdfdbcc2..9a7744a12dab 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
@@ -176,7 +176,8 @@ void schedule_deferred_list_work(struct svm_range_list 
*svms);
 void svm_range_dma_unmap(struct device *dev, dma_addr_t *dma_addr,
 unsigned long offset, unsigned long npages);
 void svm_range_free_dma_mappings(struct svm_range *prange);
-void svm_range_prefault(struct svm_range *prange, struct mm_struct *mm);
+void svm_range_prefault(struct svm_range *prange, struct mm_struct *mm,
+   void *owner);
 struct kfd_process_device *
 svm_range_get_pdd_by_adev(struct svm_range *prange, struct amdgpu_device 
*adev);
 
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 11/11] drm/amdkfd: inc counter on child ranges with xnack off

2021-06-29 Thread Alex Sierra
During GPU page table invalidation with xnack off, new ranges
split may occur concurrently in the same prange. Creating a new
child per split. Each child should also increment its
invalid counter, to assure GPU page table updates in these
ranges.

Signed-off-by: Alex Sierra 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 294c9480a184..67605e4bc3c6 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1622,6 +1622,7 @@ svm_range_evict(struct svm_range *prange, struct 
mm_struct *mm,
unsigned long start, unsigned long last)
 {
struct svm_range_list *svms = prange->svms;
+   struct svm_range *pchild;
struct kfd_process *p;
int r = 0;
 
@@ -1633,6 +1634,12 @@ svm_range_evict(struct svm_range *prange, struct 
mm_struct *mm,
if (!p->xnack_enabled) {
int evicted_ranges;
 
+   list_for_each_entry(pchild, >child_list, child_list) {
+   mutex_lock_nested(>lock, 1);
+   atomic_inc(>invalid);
+   mutex_unlock(>lock);
+   }
+
atomic_inc(>invalid);
evicted_ranges = atomic_inc_return(>evicted_ranges);
if (evicted_ranges != 1)
@@ -1650,7 +1657,6 @@ svm_range_evict(struct svm_range *prange, struct 
mm_struct *mm,
schedule_delayed_work(>restore_work,
msecs_to_jiffies(AMDGPU_SVM_RANGE_RESTORE_DELAY_MS));
} else {
-   struct svm_range *pchild;
unsigned long s, l;
 
pr_debug("invalidate unmap svms 0x%p [0x%lx 0x%lx] from GPUs\n",
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 07/11] drm/amdkfd: skip invalid pages during migrations

2021-06-29 Thread Alex Sierra
Invalid pages can be the result of pages that have been migrated
already due to copy-on-write procedure or pages that were never
migrated to VRAM in first place. This is not an issue anymore,
as pranges now support mixed memory domains (CPU/GPU).

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 38 +++-
 1 file changed, 18 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 33d4a118d05f..7b31c8596786 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -420,7 +420,6 @@ svm_migrate_vma_to_vram(struct amdgpu_device *adev, struct 
svm_range *prange,
size_t size;
void *buf;
int r = -ENOMEM;
-   int retry = 0;
 
memset(, 0, sizeof(migrate));
migrate.vma = vma;
@@ -439,7 +438,6 @@ svm_migrate_vma_to_vram(struct amdgpu_device *adev, struct 
svm_range *prange,
migrate.dst = migrate.src + npages;
scratch = (dma_addr_t *)(migrate.dst + npages);
 
-retry:
r = migrate_vma_setup();
if (r) {
pr_debug("failed %d prepare migrate svms 0x%p [0x%lx 0x%lx]\n",
@@ -447,17 +445,9 @@ svm_migrate_vma_to_vram(struct amdgpu_device *adev, struct 
svm_range *prange,
goto out_free;
}
if (migrate.cpages != npages) {
-   pr_debug("collect 0x%lx/0x%llx pages, retry\n", migrate.cpages,
+   pr_debug("Partial migration. 0x%lx/0x%llx pages can be 
migrated\n",
+migrate.cpages,
 npages);
-   migrate_vma_finalize();
-   if (retry++ >= 3) {
-   r = -ENOMEM;
-   pr_debug("failed %d migrate svms 0x%p [0x%lx 0x%lx]\n",
-r, prange->svms, prange->start, prange->last);
-   goto out_free;
-   }
-
-   goto retry;
}
 
if (migrate.cpages) {
@@ -554,9 +544,8 @@ static void svm_migrate_page_free(struct page *page)
 static int
 svm_migrate_copy_to_ram(struct amdgpu_device *adev, struct svm_range *prange,
struct migrate_vma *migrate, struct dma_fence **mfence,
-   dma_addr_t *scratch)
+   dma_addr_t *scratch, uint64_t npages)
 {
-   uint64_t npages = migrate->cpages;
struct device *dev = adev->dev;
uint64_t *src;
dma_addr_t *dst;
@@ -573,15 +562,23 @@ svm_migrate_copy_to_ram(struct amdgpu_device *adev, 
struct svm_range *prange,
src = (uint64_t *)(scratch + npages);
dst = scratch;
 
-   for (i = 0, j = 0; i < npages; i++, j++, addr += PAGE_SIZE) {
+   for (i = 0, j = 0; i < npages; i++, addr += PAGE_SIZE) {
struct page *spage;
 
spage = migrate_pfn_to_page(migrate->src[i]);
-   if (!spage) {
-   pr_debug("failed get spage svms 0x%p [0x%lx 0x%lx]\n",
+   if (!spage || !is_zone_device_page(spage)) {
+   pr_debug("invalid page. Could be in CPU already svms 
0x%p [0x%lx 0x%lx]\n",
 prange->svms, prange->start, prange->last);
-   r = -ENOMEM;
-   goto out_oom;
+   if (j) {
+   r = svm_migrate_copy_memory_gart(adev, dst + i 
- j,
+src + i - j, j,
+
FROM_VRAM_TO_RAM,
+mfence);
+   if (r)
+   goto out_oom;
+   j = 0;
+   }
+   continue;
}
src[i] = svm_migrate_addr(adev, spage);
if (i > 0 && src[i] != src[i - 1] + PAGE_SIZE) {
@@ -614,6 +611,7 @@ svm_migrate_copy_to_ram(struct amdgpu_device *adev, struct 
svm_range *prange,
 
migrate->dst[i] = migrate_pfn(page_to_pfn(dpage));
migrate->dst[i] |= MIGRATE_PFN_LOCKED;
+   j++;
}
 
r = svm_migrate_copy_memory_gart(adev, dst + i - j, src + i - j, j,
@@ -672,7 +670,7 @@ svm_migrate_vma_to_ram(struct amdgpu_device *adev, struct 
svm_range *prange,
 
if (migrate.cpages) {
r = svm_migrate_copy_to_ram(adev, prange, , ,
-   scratch);
+   scratch, npages);
migrate_vma_pages();
svm_migrate_copy_done(adev, mfence);
migrate_vma_finalize();
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

[PATCH 02/11] drm/amdkfd: add owner ref param to get hmm pages

2021-06-29 Thread Alex Sierra
The parameter is used in the dev_private_owner to decide if device
pages in the range require to be migrated back to system memory, based
if they are or not in the same memory domain.
In this case, this reference could come from the same memory domain
with devices connected to the same hive.

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c  | 3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h  | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c| 4 ++--
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
index 2741c28ff1b5..378c238c2099 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c
@@ -160,7 +160,7 @@ int amdgpu_hmm_range_get_pages(struct mmu_interval_notifier 
*notifier,
   struct mm_struct *mm, struct page **pages,
   uint64_t start, uint64_t npages,
   struct hmm_range **phmm_range, bool readonly,
-  bool mmap_locked)
+  bool mmap_locked, void *owner)
 {
struct hmm_range *hmm_range;
unsigned long timeout;
@@ -185,6 +185,7 @@ int amdgpu_hmm_range_get_pages(struct mmu_interval_notifier 
*notifier,
hmm_range->hmm_pfns = pfns;
hmm_range->start = start;
hmm_range->end = start + npages * PAGE_SIZE;
+   hmm_range->dev_private_owner = owner;
 
/* Assuming 512MB takes maxmium 1 second to fault page address */
timeout = max(npages >> 17, 1ULL) * HMM_RANGE_DEFAULT_TIMEOUT;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
index 7f7d37a457c3..14a3c1864085 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mn.h
@@ -34,7 +34,7 @@ int amdgpu_hmm_range_get_pages(struct mmu_interval_notifier 
*notifier,
   struct mm_struct *mm, struct page **pages,
   uint64_t start, uint64_t npages,
   struct hmm_range **phmm_range, bool readonly,
-  bool mmap_locked);
+  bool mmap_locked, void *owner);
 int amdgpu_hmm_range_get_pages_done(struct hmm_range *hmm_range);
 
 #if defined(CONFIG_HMM_MIRROR)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6297363ab740..89bd19e816f9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -712,7 +712,7 @@ int amdgpu_ttm_tt_get_user_pages(struct amdgpu_bo *bo, 
struct page **pages)
readonly = amdgpu_ttm_tt_is_readonly(ttm);
r = amdgpu_hmm_range_get_pages(>notifier, mm, pages, start,
   ttm->num_pages, >range, readonly,
-  false);
+  false, NULL);
 out_putmm:
mmput(mm);
 
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 00b46846a5e0..125099a91e18 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1416,7 +1416,7 @@ static int svm_range_validate_and_map(struct mm_struct 
*mm,
r = amdgpu_hmm_range_get_pages(>notifier, mm, NULL,
   prange->start << PAGE_SHIFT,
   prange->npages, _range,
-  false, true);
+  false, true, NULL);
if (r) {
pr_debug("failed %d to get svm range pages\n", r);
goto unreserve_out;
@@ -2716,7 +2716,7 @@ void svm_range_prefault(struct svm_range *prange, struct 
mm_struct *mm)
r = amdgpu_hmm_range_get_pages(>notifier, mm, NULL,
   prange->start << PAGE_SHIFT,
   prange->npages, _range,
-  false, true);
+  false, true, NULL);
if (!r) {
amdgpu_hmm_range_get_pages_done(hmm_range);
prange->validated_once = true;
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 04/11] drm/amdgpu: get owner ref in validate and map

2021-06-29 Thread Alex Sierra
Get the proper owner reference for amdgpu_hmm_range_get_pages function.
This is useful for partial migrations. To avoid migrating back to
system memory, VRAM pages, that are accessible by all devices in the
same memory domain.
Ex. multiple devices in the same hive.

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 61db2a4db917..fafc11cd274d 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1337,6 +1337,17 @@ static void svm_range_unreserve_bos(struct 
svm_validate_context *ctx)
ttm_eu_backoff_reservation(>ticket, >validate_list);
 }
 
+static void *kfd_svm_page_owner(struct kfd_process *p, int32_t gpuidx)
+{
+   struct kfd_process_device *pdd;
+   struct amdgpu_device *adev;
+
+   pdd = kfd_process_device_from_gpuidx(p, gpuidx);
+   adev = (struct amdgpu_device *)pdd->dev->kgd;
+
+   return SVM_ADEV_PGMAP_OWNER(adev);
+}
+
 /*
  * Validation+GPU mapping with concurrent invalidation (MMU notifiers)
  *
@@ -1367,6 +1378,9 @@ static int svm_range_validate_and_map(struct mm_struct 
*mm,
 {
struct svm_validate_context ctx;
struct hmm_range *hmm_range;
+   struct kfd_process *p;
+   void *owner;
+   int32_t idx;
int r = 0;
 
ctx.process = container_of(prange->svms, struct kfd_process, svms);
@@ -1413,10 +1427,19 @@ static int svm_range_validate_and_map(struct mm_struct 
*mm,
svm_range_reserve_bos();
 
if (!prange->actual_loc) {
+   p = container_of(prange->svms, struct kfd_process, svms);
+   owner = kfd_svm_page_owner(p, find_first_bit(ctx.bitmap,
+   MAX_GPU_INSTANCE));
+   for_each_set_bit(idx, ctx.bitmap, MAX_GPU_INSTANCE) {
+   if (kfd_svm_page_owner(p, idx) != owner) {
+   owner = NULL;
+   break;
+   }
+   }
r = amdgpu_hmm_range_get_pages(>notifier, mm, NULL,
   prange->start << PAGE_SHIFT,
   prange->npages, _range,
-  false, true, NULL);
+  false, true, owner);
if (r) {
pr_debug("failed %d to get svm range pages\n", r);
goto unreserve_out;
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 05/11] drm/amdkfd: use hmm range fault to get both domain pfns

2021-06-29 Thread Alex Sierra
Now that prange could have mixed domains (VRAM or SYSRAM),
actual_loc nor svm_bo can not be used to check its current
domain and eventually get its pfns to map them in GPU.
Instead, pfns from both domains, are now obtained from
hmm_range_fault through amdgpu_hmm_range_get_pages
call. This is done everytime a GPU map occur.

Signed-off-by: Alex Sierra 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 68 +++-
 1 file changed, 27 insertions(+), 41 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index fafc11cd274d..bd0cc438c429 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1426,42 +1426,38 @@ static int svm_range_validate_and_map(struct mm_struct 
*mm,
 
svm_range_reserve_bos();
 
-   if (!prange->actual_loc) {
-   p = container_of(prange->svms, struct kfd_process, svms);
-   owner = kfd_svm_page_owner(p, find_first_bit(ctx.bitmap,
-   MAX_GPU_INSTANCE));
-   for_each_set_bit(idx, ctx.bitmap, MAX_GPU_INSTANCE) {
-   if (kfd_svm_page_owner(p, idx) != owner) {
-   owner = NULL;
-   break;
-   }
-   }
-   r = amdgpu_hmm_range_get_pages(>notifier, mm, NULL,
-  prange->start << PAGE_SHIFT,
-  prange->npages, _range,
-  false, true, owner);
-   if (r) {
-   pr_debug("failed %d to get svm range pages\n", r);
-   goto unreserve_out;
-   }
-
-   r = svm_range_dma_map(prange, ctx.bitmap,
- hmm_range->hmm_pfns);
-   if (r) {
-   pr_debug("failed %d to dma map range\n", r);
-   goto unreserve_out;
+   p = container_of(prange->svms, struct kfd_process, svms);
+   owner = kfd_svm_page_owner(p, find_first_bit(ctx.bitmap,
+   MAX_GPU_INSTANCE));
+   for_each_set_bit(idx, ctx.bitmap, MAX_GPU_INSTANCE) {
+   if (kfd_svm_page_owner(p, idx) != owner) {
+   owner = NULL;
+   break;
}
+   }
+   r = amdgpu_hmm_range_get_pages(>notifier, mm, NULL,
+  prange->start << PAGE_SHIFT,
+  prange->npages, _range,
+  false, true, owner);
+   if (r) {
+   pr_debug("failed %d to get svm range pages\n", r);
+   goto unreserve_out;
+   }
 
-   prange->validated_once = true;
+   r = svm_range_dma_map(prange, ctx.bitmap,
+ hmm_range->hmm_pfns);
+   if (r) {
+   pr_debug("failed %d to dma map range\n", r);
+   goto unreserve_out;
}
 
+   prange->validated_once = true;
+
svm_range_lock(prange);
-   if (!prange->actual_loc) {
-   if (amdgpu_hmm_range_get_pages_done(hmm_range)) {
-   pr_debug("hmm update the range, need validate again\n");
-   r = -EAGAIN;
-   goto unlock_out;
-   }
+   if (amdgpu_hmm_range_get_pages_done(hmm_range)) {
+   pr_debug("hmm update the range, need validate again\n");
+   r = -EAGAIN;
+   goto unlock_out;
}
if (!list_empty(>child_list)) {
pr_debug("range split by unmap in parallel, validate again\n");
@@ -2785,16 +2781,6 @@ svm_range_trigger_migration(struct mm_struct *mm, struct 
svm_range *prange,
best_loc == prange->actual_loc)
return 0;
 
-   /*
-* Prefetch to GPU without host access flag, set actual_loc to gpu, then
-* validate on gpu and map to gpus will be handled afterwards.
-*/
-   if (best_loc && !prange->actual_loc &&
-   !(prange->flags & KFD_IOCTL_SVM_FLAG_HOST_ACCESS)) {
-   prange->actual_loc = best_loc;
-   return 0;
-   }
-
if (!best_loc) {
r = svm_migrate_vram_to_ram(prange, mm);
*migrated = !r;
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 06/11] drm/amdkfd: classify and map mixed svm range pages in GPU

2021-06-29 Thread Alex Sierra
[Why]
svm ranges can have mixed pages from device or system memory.
A good example is, after a prange has been allocated in VRAM and a
copy-on-write is triggered by a fork. This invalidates some pages
inside the prange. Endding up in mixed pages.

[How]
By classifying each page inside a prange, based on its type. Device or
system memory, during dma mapping call. If page corresponds
to VRAM domain, a flag is set to its dma_addr entry for each GPU.
Then, at the GPU page table mapping. All group of contiguous pages within
the same type are mapped with their proper pte flags.

v2:
Instead of using ttm_res to calculate vram pfns in the svm_range. It is now
done by setting the vram real physical address into drm_addr array.
This makes more flexible VRAM management, plus removes the need to have
a BO reference in the svm_range.

v3:
Remove mapping member from svm_range

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 87 +---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.h |  2 +-
 2 files changed, 55 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index bd0cc438c429..6572dea2f115 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -119,28 +119,40 @@ static void svm_range_remove_notifier(struct svm_range 
*prange)
 }
 
 static int
-svm_range_dma_map_dev(struct device *dev, dma_addr_t **dma_addr,
- unsigned long *hmm_pfns, uint64_t npages)
+svm_range_dma_map_dev(struct amdgpu_device *adev, struct svm_range *prange,
+ unsigned long *hmm_pfns, uint32_t gpuidx)
 {
enum dma_data_direction dir = DMA_BIDIRECTIONAL;
-   dma_addr_t *addr = *dma_addr;
+   dma_addr_t *addr = prange->dma_addr[gpuidx];
+   struct device *dev = adev->dev;
struct page *page;
int i, r;
 
if (!addr) {
-   addr = kvmalloc_array(npages, sizeof(*addr),
+   addr = kvmalloc_array(prange->npages, sizeof(*addr),
  GFP_KERNEL | __GFP_ZERO);
if (!addr)
return -ENOMEM;
-   *dma_addr = addr;
+   prange->dma_addr[gpuidx] = addr;
}
 
-   for (i = 0; i < npages; i++) {
+   for (i = 0; i < prange->npages; i++) {
if (WARN_ONCE(addr[i] && !dma_mapping_error(dev, addr[i]),
  "leaking dma mapping\n"))
dma_unmap_page(dev, addr[i], PAGE_SIZE, dir);
 
page = hmm_pfn_to_page(hmm_pfns[i]);
+   if (is_zone_device_page(page)) {
+   struct amdgpu_device *bo_adev =
+   
amdgpu_ttm_adev(prange->svm_bo->bo->tbo.bdev);
+
+   addr[i] = (hmm_pfns[i] << PAGE_SHIFT) +
+  bo_adev->vm_manager.vram_base_offset -
+  bo_adev->kfd.dev->pgmap.range.start;
+   addr[i] |= SVM_RANGE_VRAM_DOMAIN;
+   pr_debug("vram address detected: 0x%llx\n", addr[i]);
+   continue;
+   }
addr[i] = dma_map_page(dev, page, 0, PAGE_SIZE, dir);
r = dma_mapping_error(dev, addr[i]);
if (r) {
@@ -175,8 +187,7 @@ svm_range_dma_map(struct svm_range *prange, unsigned long 
*bitmap,
}
adev = (struct amdgpu_device *)pdd->dev->kgd;
 
-   r = svm_range_dma_map_dev(adev->dev, >dma_addr[gpuidx],
- hmm_pfns, prange->npages);
+   r = svm_range_dma_map_dev(adev, prange, hmm_pfns, gpuidx);
if (r)
break;
}
@@ -1020,21 +1031,22 @@ svm_range_split_by_granularity(struct kfd_process *p, 
struct mm_struct *mm,
 }
 
 static uint64_t
-svm_range_get_pte_flags(struct amdgpu_device *adev, struct svm_range *prange)
+svm_range_get_pte_flags(struct amdgpu_device *adev, struct svm_range *prange,
+   int domain)
 {
struct amdgpu_device *bo_adev;
uint32_t flags = prange->flags;
uint32_t mapping_flags = 0;
uint64_t pte_flags;
-   bool snoop = !prange->ttm_res;
+   bool snoop = (domain != SVM_RANGE_VRAM_DOMAIN);
bool coherent = flags & KFD_IOCTL_SVM_FLAG_COHERENT;
 
-   if (prange->svm_bo && prange->ttm_res)
+   if (domain == SVM_RANGE_VRAM_DOMAIN)
bo_adev = amdgpu_ttm_adev(prange->svm_bo->bo->tbo.bdev);
 
switch (adev->asic_type) {
case CHIP_ARCTURUS:
-   if (prange->svm_bo && prange->ttm_res) {
+   if (domain == SVM_RANGE_VRAM_DOMAIN) {
if (bo_adev == adev) {
mapping_flags |= coherent ?
AMDGPU_VM_MTYPE_CC : AMDGPU_VM_MTYPE_RW;

[PATCH 10/11] drm/amdkfd: Maintain svm_bo reference in page->zone_device_data

2021-06-29 Thread Alex Sierra
Each zone-device page holds a reference to the SVM BO that manages its
backing storage. This is necessary to correctly hold on to the BO in
case zone_device pages are shared with a child-process.

Signed-off-by: Alex Sierra 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 10 --
 drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 10 +-
 drivers/gpu/drm/amd/amdkfd/kfd_svm.h |  9 +
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index e9490236c7fa..21b86c35a4f2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -245,7 +245,8 @@ svm_migrate_get_vram_page(struct svm_range *prange, 
unsigned long pfn)
struct page *page;
 
page = pfn_to_page(pfn);
-   page->zone_device_data = prange;
+   svm_range_bo_ref(prange->svm_bo);
+   page->zone_device_data = prange->svm_bo;
get_page(page);
lock_page(page);
 }
@@ -550,7 +551,12 @@ svm_migrate_ram_to_vram(struct svm_range *prange, uint32_t 
best_loc,
 
 static void svm_migrate_page_free(struct page *page)
 {
-   /* Keep this function to avoid warning */
+   struct svm_range_bo *svm_bo = page->zone_device_data;
+
+   if (svm_bo) {
+   pr_debug("svm_bo ref left: %d\n", kref_read(_bo->kref));
+   svm_range_bo_unref(svm_bo);
+   }
 }
 
 static int
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
index 6572dea2f115..294c9480a184 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -312,14 +312,6 @@ static bool svm_bo_ref_unless_zero(struct svm_range_bo 
*svm_bo)
return true;
 }
 
-static struct svm_range_bo *svm_range_bo_ref(struct svm_range_bo *svm_bo)
-{
-   if (svm_bo)
-   kref_get(_bo->kref);
-
-   return svm_bo;
-}
-
 static void svm_range_bo_release(struct kref *kref)
 {
struct svm_range_bo *svm_bo;
@@ -358,7 +350,7 @@ static void svm_range_bo_release(struct kref *kref)
kfree(svm_bo);
 }
 
-static void svm_range_bo_unref(struct svm_range_bo *svm_bo)
+void svm_range_bo_unref(struct svm_range_bo *svm_bo)
 {
if (!svm_bo)
return;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
index 41115a220c2b..3fc1fd8b4fbc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
@@ -150,6 +150,14 @@ static inline void svm_range_unlock(struct svm_range 
*prange)
mutex_unlock(>lock);
 }
 
+static inline struct svm_range_bo *svm_range_bo_ref(struct svm_range_bo 
*svm_bo)
+{
+   if (svm_bo)
+   kref_get(_bo->kref);
+
+   return svm_bo;
+}
+
 int svm_range_list_init(struct kfd_process *p);
 void svm_range_list_fini(struct kfd_process *p);
 int svm_ioctl(struct kfd_process *p, enum kfd_ioctl_svm_op op, uint64_t start,
@@ -186,6 +194,7 @@ svm_range_get_pdd_by_adev(struct svm_range *prange, struct 
amdgpu_device *adev);
  */
 #define KFD_IS_SVM_API_SUPPORTED(dev) ((dev)->pgmap.type != 0)
 
+void svm_range_bo_unref(struct svm_range_bo *svm_bo);
 #else
 
 struct kfd_process;
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 01/11] drm/amdkfd: device pgmap owner at the svm migrate init

2021-06-29 Thread Alex Sierra
pgmap owner member at the svm migrate init could be referenced
to either adev or hive, depending on device topology.

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
 drivers/gpu/drm/amd/amdkfd/kfd_svm.h | 3 +++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 45b5349283af..8ce71c8142aa 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -427,7 +427,7 @@ svm_migrate_vma_to_vram(struct amdgpu_device *adev, struct 
svm_range *prange,
migrate.start = start;
migrate.end = end;
migrate.flags = MIGRATE_VMA_SELECT_SYSTEM;
-   migrate.pgmap_owner = adev;
+   migrate.pgmap_owner = SVM_ADEV_PGMAP_OWNER(adev);
 
size = 2 * sizeof(*migrate.src) + sizeof(uint64_t) + sizeof(dma_addr_t);
size *= npages;
@@ -649,7 +649,7 @@ svm_migrate_vma_to_ram(struct amdgpu_device *adev, struct 
svm_range *prange,
migrate.start = start;
migrate.end = end;
migrate.flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
-   migrate.pgmap_owner = adev;
+   migrate.pgmap_owner = SVM_ADEV_PGMAP_OWNER(adev);
 
size = 2 * sizeof(*migrate.src) + sizeof(uint64_t) + sizeof(dma_addr_t);
size *= npages;
@@ -921,7 +921,7 @@ int svm_migrate_init(struct amdgpu_device *adev)
pgmap->range.start = res->start;
pgmap->range.end = res->end;
pgmap->ops = _migrate_pgmap_ops;
-   pgmap->owner = adev;
+   pgmap->owner = SVM_ADEV_PGMAP_OWNER(adev);
pgmap->flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE;
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
index a9af03994d1a..1f88bdfdbcc2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.h
@@ -35,6 +35,9 @@
 #include "amdgpu.h"
 #include "kfd_priv.h"
 
+#define SVM_ADEV_PGMAP_OWNER(adev)\
+   ((adev)->hive ? (void *)(adev)->hive : (void *)(adev))
+
 struct svm_range_bo {
struct amdgpu_bo*bo;
struct kref kref;
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 09/11] drm/amdkfd: add invalid pages debug at vram migration

2021-06-29 Thread Alex Sierra
This is for debug purposes only.
It conditionally generates partial migrations to test mixed
CPU/GPU memory domain pages in a prange easily.

Signed-off-by: Alex Sierra 
Reviewed-by: Felix Kuehling 
---
 drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index ae360d94c06f..e9490236c7fa 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -401,6 +401,20 @@ svm_migrate_copy_to_vram(struct amdgpu_device *adev, 
struct svm_range *prange,
}
}
 
+#ifdef DEBUG_FORCE_MIXED_DOMAINS
+   for (i = 0, j = 0; i < npages; i += 4, j++) {
+   if (j & 1)
+   continue;
+   svm_migrate_put_vram_page(adev, dst[i]);
+   migrate->dst[i] = 0;
+   svm_migrate_put_vram_page(adev, dst[i + 1]);
+   migrate->dst[i + 1] = 0;
+   svm_migrate_put_vram_page(adev, dst[i + 2]);
+   migrate->dst[i + 2] = 0;
+   svm_migrate_put_vram_page(adev, dst[i + 3]);
+   migrate->dst[i + 3] = 0;
+   }
+#endif
 out:
return r;
 }
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/2] drm/amdgpu: use xarray for storing pasid in vm

2021-06-29 Thread Christian König




Am 29.06.21 um 17:19 schrieb Nirmoy Das:

Replace idr with xarray as we actually need hash functionality.
Cleanup code related to vm pasid by adding helper function.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 149 -
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   6 +-
  2 files changed, 73 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 63975bda8e76..fd92ff27931a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -87,6 +87,46 @@ struct amdgpu_prt_cb {
struct dma_fence_cb cb;
  };
  
+/**

+ * amdgpu_vm_set_pasid - manage pasid and vm ptr mapping
+ *
+ * @adev: amdgpu_device pointer
+ * @vm: amdgpu_vm pointer
+ * @pasid: requested pasid


Better write "the pasid the VM is using on this GPU".


+ *
+ * Each pasid associats with a vm pointer.


That is misleading. KFD most likely want to associate the same pasid 
with multiple VMs on different GPUs.


Better write "Set the pasid this VM is using on this GPU, can also be 
used to remove the pasid by passing in zero.".



  This function can be use to
+ * create a new pasid,vm association or to remove an existing one. To remove an
+ * existing pasid,vm association, pass 0 as @pasid.
+ */
+int amdgpu_vm_set_pasid(struct amdgpu_device *adev, struct amdgpu_vm *vm,
+   unsigned long pasid)


"unsigned long pasid"? The pasid is either 16 or 20 bits IIRC.

Regards,
Christian.


+{
+   int r;
+
+   if (vm->pasid == pasid)
+   return 0;
+
+   if (vm->pasid) {
+   r = xa_err(xa_erase_irq(>vm_manager.pasids, vm->pasid));
+   if (r < 0)
+   return r;
+
+   vm->pasid = 0;
+   }
+
+   if (pasid) {
+   r = xa_err(xa_store_irq(>vm_manager.pasids, pasid, vm,
+   GFP_KERNEL));
+   if (r < 0)
+   return r;
+
+   vm->pasid = pasid;
+   }
+
+
+   return 0;
+}
+
  /*
   * vm eviction_lock can be taken in MMU notifiers. Make sure no reclaim-FS
   * happens while holding this lock anywhere to prevent deadlocks when
@@ -2940,18 +2980,9 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm, u32 pasid)
  
  	amdgpu_bo_unreserve(vm->root.bo);
  
-	if (pasid) {

-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-   if (r < 0)
-   goto error_free_root;
-
-   vm->pasid = pasid;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto error_free_root;
  
  	INIT_KFIFO(vm->faults);
  
@@ -3039,18 +3070,15 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, struct amdgpu_vm *vm,

if (r)
goto unreserve_bo;
  
-	if (pasid) {

-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (vm->pasid)
+   amdgpu_pasid_free(vm->pasid);
  
-		if (r == -ENOSPC)

-   goto unreserve_bo;
-   r = 0;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto unreserve_bo;
  
  	/* Check if PD needs to be reinitialized and do it before

 * changing any other state, in case it fails.
@@ -3061,7 +3089,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
   to_amdgpu_bo_vm(vm->root.bo),
   false);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
}
  
  	/* Update VM state */

@@ -3078,7 +3106,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
r = amdgpu_bo_sync_wait(vm->root.bo,
AMDGPU_FENCE_OWNER_UNDEFINED, true);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
  
  		vm->update_funcs = _vm_cpu_funcs;

} else {
@@ -3088,36 +3116,13 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
vm->last_update = NULL;
vm->is_compute_context = true;
  
-	if (vm->pasid) {

-   unsigned long flags;
-
-   

Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!"

2021-06-29 Thread Alex Deucher
On Tue, Jun 29, 2021 at 3:57 PM Ketsui  wrote:
>
> I have the 3200G I'm still getting this error with that version.

I think the 3200G may be a raven or raven2 variant rather than
picasso.  Can you try the latest firmware from upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdgpu

Alex

>
> [ +23.754701] amdgpu :08:00.0: amdgpu: [gfxhub0] retry page fault 
> (src_id:0 ring:0 vmid:2 pasid:32773, for process mpv pid 5016 thread mpv:cs0 
> pid 5064)
> [  +0.17] amdgpu :08:00.0: amdgpu:   in page starting at address 
> 0x80010009e000 from client 27
> [  +0.07] amdgpu :08:00.0: amdgpu: 
> VM_L2_PROTECTION_FAULT_STATUS:0x00240C51
> [  +0.03] amdgpu :08:00.0: amdgpu:   Faulty UTCL2 client ID: CPG 
> (0x6)
> [  +0.03] amdgpu :08:00.0: amdgpu:   MORE_FAULTS: 0x1
> [  +0.02] amdgpu :08:00.0: amdgpu:   WALKER_ERROR: 0x0
> [  +0.02] amdgpu :08:00.0: amdgpu:   PERMISSION_FAULTS: 0x5
> [  +0.02] amdgpu :08:00.0: amdgpu:   MAPPING_ERROR: 0x0
> [  +0.01] amdgpu :08:00.0: amdgpu:   RW: 0x1
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!"

2021-06-29 Thread Ketsui
I have the 3200G I'm still getting this error with that version.

[ +23.754701] amdgpu :08:00.0: amdgpu: [gfxhub0] retry page fault
(src_id:0 ring:0 vmid:2 pasid:32773, for process mpv pid 5016 thread
mpv:cs0 pid 5064)
[  +0.17] amdgpu :08:00.0: amdgpu:   in page starting at address
0x80010009e000 from client 27
[  +0.07] amdgpu :08:00.0: amdgpu:
VM_L2_PROTECTION_FAULT_STATUS:0x00240C51
[  +0.03] amdgpu :08:00.0: amdgpu:   Faulty UTCL2 client ID:
CPG (0x6)
[  +0.03] amdgpu :08:00.0: amdgpu:   MORE_FAULTS: 0x1
[  +0.02] amdgpu :08:00.0: amdgpu:   WALKER_ERROR: 0x0
[  +0.02] amdgpu :08:00.0: amdgpu:   PERMISSION_FAULTS: 0x5
[  +0.02] amdgpu :08:00.0: amdgpu:   MAPPING_ERROR: 0x0
[  +0.01] amdgpu :08:00.0: amdgpu:   RW: 0x1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 06/12] Revert "drm/amd/display: Always write repeater mode regardless of LTTPR"

2021-06-29 Thread Rodrigo Siqueira
From: Wesley Chalmers 

This reverts commit 06a2bd7ae7238cf31faeb2216c0e8a3d9b1bedfb

Some displays are not lighting up when put in LTTPR Transparent Mode

Signed-off-by: Wesley Chalmers 
Reviewed-by: Jun Lei 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 5c3f78b2f1de..410543797275 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -1608,11 +1608,12 @@ enum dc_status dpcd_configure_lttpr_mode(struct dc_link 
*link, struct link_train
 {
enum dc_status status = DC_OK;
 
-   if (lt_settings->lttpr_mode == LTTPR_MODE_NON_TRANSPARENT)
-   status = configure_lttpr_mode_non_transparent(link, 
lt_settings);
-   else
+   if (lt_settings->lttpr_mode == LTTPR_MODE_TRANSPARENT)
status = configure_lttpr_mode_transparent(link);
 
+   else if (lt_settings->lttpr_mode == LTTPR_MODE_NON_TRANSPARENT)
+   status = configure_lttpr_mode_non_transparent(link, 
lt_settings);
+
return status;
 }
 
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 11/12] drm/amd/display: Round KHz up when calculating clock requests

2021-06-29 Thread Rodrigo Siqueira
From: Aric Cyr 

[Why]
When requesting clocks from SMU which takes MHz inputs, DC will round
down KHz when converting to MHz, thus potentially requesting too low a
clock value.

[How]
Round up (ceil) when converting KHz to MHz for clock requests to SMU.

Signed-off-by: Aric Cyr 
Reviewed-by: Dmytro Laktyushkin 
Acked-by: Rodrigo Siqueira 
---
 .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c| 12 -
 .../dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c  |  4 +--
 .../display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c  | 12 -
 .../dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c   | 16 ++--
 .../display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c  | 25 +++
 .../display/dc/clk_mgr/dcn301/dcn301_smu.c| 10 
 .../amd/display/dc/clk_mgr/dcn31/dcn31_smu.c  | 10 
 .../amd/display/dc/inc/hw/clk_mgr_internal.h  |  5 
 8 files changed, 52 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
index e133edc587d3..76ec8ec92efd 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr.c
@@ -264,9 +264,9 @@ static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
if (pp_smu->set_hard_min_fclk_by_freq &&
pp_smu->set_hard_min_dcfclk_by_freq &&
pp_smu->set_min_deep_sleep_dcfclk) {
-   pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu, 
new_clocks->fclk_khz / 1000);
-   pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu, 
new_clocks->dcfclk_khz / 1000);
-   pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu, 
(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
+   pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu, 
khz_to_mhz_ceil(new_clocks->fclk_khz));
+   pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu, 
khz_to_mhz_ceil(new_clocks->dcfclk_khz));
+   pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu, 
khz_to_mhz_ceil(new_clocks->dcfclk_deep_sleep_khz));
}
}
 
@@ -284,9 +284,9 @@ static void rv1_update_clocks(struct clk_mgr *clk_mgr_base,
if (pp_smu->set_hard_min_fclk_by_freq &&
pp_smu->set_hard_min_dcfclk_by_freq &&
pp_smu->set_min_deep_sleep_dcfclk) {
-   pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu, 
new_clocks->fclk_khz / 1000);
-   pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu, 
new_clocks->dcfclk_khz / 1000);
-   pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu, 
(new_clocks->dcfclk_deep_sleep_khz + 999) / 1000);
+   pp_smu->set_hard_min_fclk_by_freq(_smu->pp_smu, 
khz_to_mhz_ceil(new_clocks->fclk_khz));
+   pp_smu->set_hard_min_dcfclk_by_freq(_smu->pp_smu, 
khz_to_mhz_ceil(new_clocks->dcfclk_khz));
+   pp_smu->set_min_deep_sleep_dcfclk(_smu->pp_smu, 
khz_to_mhz_ceil(new_clocks->dcfclk_deep_sleep_khz));
}
}
 }
diff --git 
a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c
index dbc7cde00433..fe18bb9e19aa 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c
@@ -130,7 +130,7 @@ int rv1_vbios_smu_set_dispclk(struct clk_mgr_internal 
*clk_mgr, int requested_di
actual_dispclk_set_mhz = rv1_vbios_smu_send_msg_with_param(
clk_mgr,
VBIOSSMC_MSG_SetDispclkFreq,
-   requested_dispclk_khz / 1000);
+   khz_to_mhz_ceil(requested_dispclk_khz));
 
if (!IS_FPGA_MAXIMUS_DC(dc->ctx->dce_environment)) {
if (dmcu && dmcu->funcs->is_dmcu_initialized(dmcu)) {
@@ -150,7 +150,7 @@ int rv1_vbios_smu_set_dprefclk(struct clk_mgr_internal 
*clk_mgr)
actual_dprefclk_set_mhz = rv1_vbios_smu_send_msg_with_param(
clk_mgr,
VBIOSSMC_MSG_SetDprefclkFreq,
-   clk_mgr->base.dprefclk_khz / 1000);
+   khz_to_mhz_ceil(clk_mgr->base.dprefclk_khz));
 
/* TODO: add code for programing DP DTO, currently this is down by 
command table */
 
diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c 
b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
index 6e0c5c664fdc..eee406d11b1e 100644
--- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
+++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
@@ -253,20 +253,20 @@ void dcn2_update_clocks(struct clk_mgr *clk_mgr_base,
if (should_set_clock(safe_to_lower, new_clocks->dcfclk_khz, 

[PATCH 02/12] drm/amd/display: DMUB Outbound Interrupt Process-X86

2021-06-29 Thread Rodrigo Siqueira
From: Chun-Liang Chang 

[Why]
dmub would notify x86 response time violation by GPINT_DATAOUT

[How]
1. Use GPINT_DATAOUT to trigger x86 interrupt
2. Register GPINT_DATAOUT interrupt handler.
3. Trigger ACR while GPINT_DATAOUT occurred.

Signed-off-by: Chun-Liang Chang 
Reviewed-by: Jun Lei 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dc/core/dc_stat.c | 24 +++
 drivers/gpu/drm/amd/display/dc/dc_stat.h  |  1 +
 drivers/gpu/drm/amd/display/dc/irq_types.h|  2 +-
 drivers/gpu/drm/amd/display/dmub/dmub_srv.h   | 18 ++
 .../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 15 
 .../gpu/drm/amd/display/dmub/src/dmub_dcn31.h | 13 --
 .../gpu/drm/amd/display/dmub/src/dmub_srv.c   | 17 +
 .../include/asic_reg/dcn/dcn_3_1_2_sh_mask.h  |  4 
 8 files changed, 91 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stat.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
index 31761f3595a6..28ef9760fa34 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stat.c
@@ -62,3 +62,27 @@ void dc_stat_get_dmub_notification(const struct dc *dc, 
struct dmub_notification
status = dmub_srv_stat_get_notification(dmub, notify);
ASSERT(status == DMUB_STATUS_OK);
 }
+
+/**
+ *
+ *  Function: dc_stat_get_dmub_dataout
+ *
+ *  @brief
+ * Calls dmub layer to retrieve dmub gpint dataout
+ *
+ *  @param
+ * [in] dc: dc structure
+ * [in] dataout: dmub gpint dataout
+ *
+ *  @return
+ * None
+ *
+ */
+void dc_stat_get_dmub_dataout(const struct dc *dc, uint32_t *dataout)
+{
+   struct dmub_srv *dmub = dc->ctx->dmub_srv->dmub;
+   enum dmub_status status;
+
+   status = dmub_srv_get_gpint_dataout(dmub, dataout);
+   ASSERT(status == DMUB_STATUS_OK);
+}
diff --git a/drivers/gpu/drm/amd/display/dc/dc_stat.h 
b/drivers/gpu/drm/amd/display/dc/dc_stat.h
index 2a000ba54ddb..aacbfd786c6c 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_stat.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_stat.h
@@ -38,5 +38,6 @@
 #include "dmub/dmub_srv.h"
 
 void dc_stat_get_dmub_notification(const struct dc *dc, struct 
dmub_notification *notify);
+void dc_stat_get_dmub_dataout(const struct dc *dc, uint32_t *dataout);
 
 #endif /* _DC_STAT_H_ */
diff --git a/drivers/gpu/drm/amd/display/dc/irq_types.h 
b/drivers/gpu/drm/amd/display/dc/irq_types.h
index 5f9346622301..b3edd7e618a6 100644
--- a/drivers/gpu/drm/amd/display/dc/irq_types.h
+++ b/drivers/gpu/drm/amd/display/dc/irq_types.h
@@ -152,7 +152,7 @@ enum dc_irq_source {
DC_IRQ_SOURCE_DC6_VLINE1,
DC_IRQ_SOURCE_DMCUB_OUTBOX,
DC_IRQ_SOURCE_DMCUB_OUTBOX0,
-
+   DC_IRQ_SOURCE_DMCUB_GENERAL_DATAOUT,
DAL_IRQ_SOURCES_NUMBER
 };
 
diff --git a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h 
b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
index abbf7ae584c9..caf961bb633f 100644
--- a/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
+++ b/drivers/gpu/drm/amd/display/dmub/dmub_srv.h
@@ -352,6 +352,8 @@ struct dmub_srv_hw_funcs {
 
uint32_t (*get_gpint_response)(struct dmub_srv *dmub);
 
+   uint32_t (*get_gpint_dataout)(struct dmub_srv *dmub);
+
void (*send_inbox0_cmd)(struct dmub_srv *dmub, union 
dmub_inbox0_data_register data);
uint32_t (*get_current_time)(struct dmub_srv *dmub);
 
@@ -676,6 +678,22 @@ dmub_srv_send_gpint_command(struct dmub_srv *dmub,
 enum dmub_status dmub_srv_get_gpint_response(struct dmub_srv *dmub,
 uint32_t *response);
 
+/**
+ * dmub_srv_get_gpint_dataout() - Queries the GPINT DATAOUT.
+ * @dmub: the dmub service
+ * @dataout: the data for the GPINT DATAOUT
+ *
+ * Returns the response code for the last GPINT DATAOUT interrupt.
+ *
+ * Can be called after software initialization.
+ *
+ * Return:
+ *   DMUB_STATUS_OK - success
+ *   DMUB_STATUS_INVALID - unspecified error
+ */
+enum dmub_status dmub_srv_get_gpint_dataout(struct dmub_srv *dmub,
+uint32_t *dataout);
+
 /**
  * dmub_flush_buffer_mem() - Read back entire frame buffer region.
  * This ensures that the write from x86 has been flushed and will not
diff --git a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c 
b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
index 8c886ece71f6..4fb9423fd880 100644
--- a/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
+++ b/drivers/gpu/drm/amd/display/dmub/src/dmub_dcn31.c
@@ -305,6 +305,21 @@ uint32_t dmub_dcn31_get_gpint_response(struct dmub_srv 
*dmub)
return REG_READ(DMCUB_SCRATCH7);
 }
 
+uint32_t dmub_dcn31_get_gpint_dataout(struct dmub_srv *dmub)
+{
+   uint32_t dataout = REG_READ(DMCUB_GPINT_DATAOUT);
+
+   REG_UPDATE(DMCUB_INTERRUPT_ENABLE, DMCUB_GPINT_IH_INT_EN, 

[PATCH 03/12] drm/amd/display: Add null checks

2021-06-29 Thread Rodrigo Siqueira
From: Wang 

Added NULL checks before two problematic statements

Signed-off-by: Wang 
Reviewed-by: Martin Leung 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
index 45931ee14a6e..327fd1909c51 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
@@ -221,6 +221,9 @@ struct dc_stream_status *dc_stream_get_status_from_state(
 {
uint8_t i;
 
+   if (state == NULL)
+   return NULL;
+
for (i = 0; i < state->stream_count; i++) {
if (stream == state->streams[i])
return >stream_status[i];
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 05/12] drm/amd/display: Fix updating infoframe for DCN3.1 eDP

2021-06-29 Thread Rodrigo Siqueira
From: Nicholas Kazlauskas 

[Why]
We're only treating TMDS as a valid target for infoframe updates which
results in PSR being unable to transition from state 4 to state 5.

[How]
Also allow infoframe updates for DCN3.1 - following how we handle
this path for earlier ASIC as well.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Eric Yang 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c 
b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
index fc1fc1a4bf8b..836864a5a5dc 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_hwseq.c
@@ -390,7 +390,7 @@ void dcn31_update_info_frame(struct pipe_ctx *pipe_ctx)
is_hdmi_tmds = dc_is_hdmi_tmds_signal(pipe_ctx->stream->signal);
is_dp = dc_is_dp_signal(pipe_ctx->stream->signal);
 
-   if (!is_hdmi_tmds)
+   if (!is_hdmi_tmds && !is_dp)
return;
 
if (is_hdmi_tmds)
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 00/12] DC Patches June 29, 2021

2021-06-29 Thread Rodrigo Siqueira
DC version 3.2.142 brings improvements in multiple areas. In summary, we
highlight:

- Freesync improvements
- Remove unnecessary assert
- Firmware release 0.0.72
- Improve the EDID manipulation and DML calculations

Alvin Lee (1):
  drm/amd/display: Adjust types and formatting for future development

Anthony Koo (1):
  drm/amd/display: [FW Promotion] Release 0.0.72

Aric Cyr (3):
  drm/amd/display: 3.2.142
  drm/amd/display: Round KHz up when calculating clock requests
  drm/amd/display: increase max EDID size to 2k

Chun-Liang Chang (1):
  drm/amd/display: DMUB Outbound Interrupt Process-X86

Dmytro Laktyushkin (1):
  drm/amd/display: remove faulty assert

Nicholas Kazlauskas (1):
  drm/amd/display: Fix updating infoframe for DCN3.1 eDP

Stylon Wang (1):
  drm/amd/display: Add Freesync HDMI support to DM with DMUB

Wang (1):
  drm/amd/display: Add null checks

Wenjing Liu (1):
  drm/amd/display: isolate link training setting override to its own
function

Wesley Chalmers (1):
  Revert "drm/amd/display: Always write repeater mode regardless of
LTTPR"

 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  95 +-
 .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c|  12 +-
 .../dc/clk_mgr/dcn10/rv1_clk_mgr_vbios_smu.c  |   4 +-
 .../display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c  |  12 +-
 .../dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c   |  16 +--
 .../display/dc/clk_mgr/dcn30/dcn30_clk_mgr.c  |  25 ++--
 .../display/dc/clk_mgr/dcn301/dcn301_smu.c|  10 +-
 .../amd/display/dc/clk_mgr/dcn31/dcn31_smu.c  |  10 +-
 .../gpu/drm/amd/display/dc/core/dc_link_dp.c  | 121 +-
 drivers/gpu/drm/amd/display/dc/core/dc_stat.c |  24 
 .../gpu/drm/amd/display/dc/core/dc_stream.c   |   3 +
 drivers/gpu/drm/amd/display/dc/dc.h   |   2 +-
 drivers/gpu/drm/amd/display/dc/dc_stat.h  |   1 +
 drivers/gpu/drm/amd/display/dc/dc_types.h |   2 +-
 .../drm/amd/display/dc/dcn31/dcn31_hwseq.c|   2 +-
 .../dc/dml/dcn21/display_mode_vba_21.c|  11 +-
 .../dc/dml/dcn30/display_mode_vba_30.c|  18 +--
 .../dc/dml/dcn31/display_mode_vba_31.c|  15 ++-
 .../amd/display/dc/dml/display_mode_enums.h   |   4 +-
 .../drm/amd/display/dc/dml/display_mode_vba.c |  12 +-
 .../drm/amd/display/dc/dml/display_mode_vba.h |   4 +-
 .../gpu/drm/amd/display/dc/inc/dc_link_dp.h   |   1 -
 .../amd/display/dc/inc/hw/clk_mgr_internal.h  |   5 +
 drivers/gpu/drm/amd/display/dc/irq_types.h|   2 +-
 drivers/gpu/drm/amd/display/dmub/dmub_srv.h   |  18 +++
 .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h   |  11 +-
 .../gpu/drm/amd/display/dmub/src/dmub_dcn31.c |  15 +++
 .../gpu/drm/amd/display/dmub/src/dmub_dcn31.h |  13 +-
 .../gpu/drm/amd/display/dmub/src/dmub_srv.c   |  17 +++
 .../include/asic_reg/dcn/dcn_3_1_2_sh_mask.h  |   4 +
 30 files changed, 338 insertions(+), 151 deletions(-)

-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 10/12] drm/amd/display: 3.2.142

2021-06-29 Thread Rodrigo Siqueira
From: Aric Cyr 

DC version 3.2.142 brings improvements in multiple areas. In summary, we
highlight:

- Freesync improvements
- Remove unnecessary assert
- Firmware release 0.0.72
- Improve the EDID manipulation and DML calculations

Signed-off-by: Aric Cyr 
Reviewed-by: Aric Cyr 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc.h 
b/drivers/gpu/drm/amd/display/dc/dc.h
index 45640f1c26c4..b62d21131af2 100644
--- a/drivers/gpu/drm/amd/display/dc/dc.h
+++ b/drivers/gpu/drm/amd/display/dc/dc.h
@@ -45,7 +45,7 @@
 /* forward declaration */
 struct aux_payload;
 
-#define DC_VER "3.2.141"
+#define DC_VER "3.2.142"
 
 #define MAX_SURFACES 3
 #define MAX_PLANES 6
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 04/12] drm/amd/display: Add Freesync HDMI support to DM with DMUB

2021-06-29 Thread Rodrigo Siqueira
From: Stylon Wang 

[Why]
Changes in DM needed to support Freesync HDMI on DMUB.

[How]
Change implementation to parse CEA blocks in case of DMUB-enabled ASICs.

Signed-off-by: Stylon Wang 
Reviewed-by: Nicholas Kazlauskas 
Acked-by: Rodrigo Siqueira 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 95 +--
 1 file changed, 89 insertions(+), 6 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 cb41a646b3b1..1210426f2021 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10657,13 +10657,68 @@ static bool is_dp_capable_without_timing_msa(struct 
dc *dc,
return capable;
 }
 
-static bool parse_edid_cea(struct amdgpu_dm_connector *aconnector,
+static bool dm_edid_parser_send_cea(struct amdgpu_display_manager *dm,
+   unsigned int offset,
+   unsigned int total_length,
+   uint8_t *data,
+   unsigned int length,
+   struct amdgpu_hdmi_vsdb_info *vsdb)
+{
+   bool res;
+   union dmub_rb_cmd cmd;
+   struct dmub_cmd_send_edid_cea *input;
+   struct dmub_cmd_edid_cea_output *output;
+
+   if (length > DMUB_EDID_CEA_DATA_CHUNK_BYTES)
+   return false;
+
+   memset(, 0, sizeof(cmd));
+
+   input = _cea.data.input;
+
+   cmd.edid_cea.header.type = DMUB_CMD__EDID_CEA;
+   cmd.edid_cea.header.sub_type = 0;
+   cmd.edid_cea.header.payload_bytes =
+   sizeof(cmd.edid_cea) - sizeof(cmd.edid_cea.header);
+   input->offset = offset;
+   input->length = length;
+   input->total_length = total_length;
+   memcpy(input->payload, data, length);
+
+   res = dc_dmub_srv_cmd_with_reply_data(dm->dc->ctx->dmub_srv, );
+   if (!res) {
+   DRM_ERROR("EDID CEA parser failed\n");
+   return false;
+   }
+
+   output = _cea.data.output;
+
+   if (output->type == DMUB_CMD__EDID_CEA_ACK) {
+   if (!output->ack.success) {
+   DRM_ERROR("EDID CEA ack failed at offset %d\n",
+   output->ack.offset);
+   }
+   } else if (output->type == DMUB_CMD__EDID_CEA_AMD_VSDB) {
+   if (!output->amd_vsdb.vsdb_found)
+   return false;
+
+   vsdb->freesync_supported = output->amd_vsdb.freesync_supported;
+   vsdb->amd_vsdb_version = output->amd_vsdb.amd_vsdb_version;
+   vsdb->min_refresh_rate_hz = output->amd_vsdb.min_frame_rate;
+   vsdb->max_refresh_rate_hz = output->amd_vsdb.max_frame_rate;
+   } else {
+   DRM_ERROR("Unknown EDID CEA parser results\n");
+   return false;
+   }
+
+   return true;
+}
+
+static bool parse_edid_cea_dmcu(struct amdgpu_display_manager *dm,
uint8_t *edid_ext, int len,
struct amdgpu_hdmi_vsdb_info *vsdb_info)
 {
int i;
-   struct amdgpu_device *adev = drm_to_adev(aconnector->base.dev);
-   struct dc *dc = adev->dm.dc;
 
/* send extension block to DMCU for parsing */
for (i = 0; i < len; i += 8) {
@@ -10671,14 +10726,14 @@ static bool parse_edid_cea(struct amdgpu_dm_connector 
*aconnector,
int offset;
 
/* send 8 bytes a time */
-   if (!dc_edid_parser_send_cea(dc, i, len, _ext[i], 8))
+   if (!dc_edid_parser_send_cea(dm->dc, i, len, _ext[i], 8))
return false;
 
if (i+8 == len) {
/* EDID block sent completed, expect result */
int version, min_rate, max_rate;
 
-   res = dc_edid_parser_recv_amd_vsdb(dc, , 
_rate, _rate);
+   res = dc_edid_parser_recv_amd_vsdb(dm->dc, , 
_rate, _rate);
if (res) {
/* amd vsdb found */
vsdb_info->freesync_supported = 1;
@@ -10692,7 +10747,7 @@ static bool parse_edid_cea(struct amdgpu_dm_connector 
*aconnector,
}
 
/* check for ack*/
-   res = dc_edid_parser_recv_cea_ack(dc, );
+   res = dc_edid_parser_recv_cea_ack(dm->dc, );
if (!res)
return false;
}
@@ -10700,6 +10755,34 @@ static bool parse_edid_cea(struct amdgpu_dm_connector 
*aconnector,
return false;
 }
 
+static bool parse_edid_cea_dmub(struct amdgpu_display_manager *dm,
+   uint8_t *edid_ext, int len,
+   struct amdgpu_hdmi_vsdb_info *vsdb_info)
+{
+   int i;
+
+   /* send extension block to DMCU for parsing */
+   for (i = 0; i < len; i += 8) {
+   /* send 8 bytes a time */
+   if (!dm_edid_parser_send_cea(dm, i, len, _ext[i], 8, 
vsdb_info))
+   return false;
+

[PATCH 09/12] drm/amd/display: [FW Promotion] Release 0.0.72

2021-06-29 Thread Rodrigo Siqueira
From: Anthony Koo 

- Updated SCR definition for FW boot options for Separate DCN init
  for DMUB FW loaded in VBL

Signed-off-by: Anthony Koo 
Reviewed-by: Anthony Koo 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h 
b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
index 7c4734f905d9..98bda0e3a6c3 100644
--- a/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
+++ b/drivers/gpu/drm/amd/display/dmub/inc/dmub_cmd.h
@@ -47,10 +47,10 @@
 
 /* Firmware versioning. */
 #ifdef DMUB_EXPOSE_VERSION
-#define DMUB_FW_VERSION_GIT_HASH 0xf3da2b656
+#define DMUB_FW_VERSION_GIT_HASH 0x2fe298ec9
 #define DMUB_FW_VERSION_MAJOR 0
 #define DMUB_FW_VERSION_MINOR 0
-#define DMUB_FW_VERSION_REVISION 71
+#define DMUB_FW_VERSION_REVISION 72
 #define DMUB_FW_VERSION_TEST 0
 #define DMUB_FW_VERSION_VBIOS 0
 #define DMUB_FW_VERSION_HOTFIX 0
@@ -334,6 +334,7 @@ enum dmub_fw_boot_status_bit {
DMUB_FW_BOOT_STATUS_BIT_MAILBOX_READY = (1 << 1), /**< 1 if mailbox 
ready */
DMUB_FW_BOOT_STATUS_BIT_OPTIMIZED_INIT_DONE = (1 << 2), /**< 1 if init 
done */
DMUB_FW_BOOT_STATUS_BIT_RESTORE_REQUIRED = (1 << 3), /**< 1 if driver 
should call restore */
+   DMUB_FW_BOOT_STATUS_BIT_DEFERRED_LOADED = (1 << 4), /**< 1 if VBIOS 
data is deferred programmed */
 };
 
 /* Register bit definition for SCRATCH5 */
@@ -352,7 +353,7 @@ enum dmub_lvtma_status_bit {
 };
 
 /**
- * union dmub_fw_boot_options - Boot option definitions for SCRATCH15
+ * union dmub_fw_boot_options - Boot option definitions for SCRATCH14
  */
 union dmub_fw_boot_options {
struct {
@@ -363,7 +364,9 @@ union dmub_fw_boot_options {
uint32_t disable_clk_gate: 1; /**< 1 if clock gating should be 
disabled */
uint32_t skip_phy_init_panel_sequence: 1; /**< 1 to skip panel 
init seq */
uint32_t z10_disable: 1; /**< 1 to disable z10 */
-   uint32_t reserved : 25; /**< reserved */
+   uint32_t reserved2: 1; /**< reserved for an unreleased feature 
*/
+   uint32_t invalid_vbios_data: 1; /**< 1 if VBIOS data table is 
invalid */
+   uint32_t reserved : 23; /**< reserved */
} bits; /**< boot bits */
uint32_t all; /**< 32-bit access to bits */
 };
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 08/12] drm/amd/display: Adjust types and formatting for future development

2021-06-29 Thread Rodrigo Siqueira
From: Alvin Lee 

Type adjustments and formatting fixes.

Signed-off-by: Alvin Lee 
Reviewed-by: Dmytro Laktyushkin 
Acked-by: Rodrigo Siqueira 
---
 .../display/dc/dml/dcn21/display_mode_vba_21.c | 11 ++-
 .../display/dc/dml/dcn30/display_mode_vba_30.c | 18 ++
 .../display/dc/dml/dcn31/display_mode_vba_31.c | 15 ---
 .../amd/display/dc/dml/display_mode_enums.h|  4 +++-
 .../drm/amd/display/dc/dml/display_mode_vba.c  | 12 +++-
 .../drm/amd/display/dc/dml/display_mode_vba.h  |  4 ++--
 6 files changed, 36 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
index c26e742e8137..20a8cd4eb8b9 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c
@@ -2267,7 +2267,7 @@ static void 
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
>UrgentBurstFactorLumaPre[k],
>UrgentBurstFactorChroma[k],
>UrgentBurstFactorChromaPre[k],
-   >NotEnoughUrgentLatencyHiding,
+   
>NotEnoughUrgentLatencyHiding[0][0],

>NotEnoughUrgentLatencyHidingPre);
 
if (mode_lib->vba.UseUrgentBurstBandwidth == false) {
@@ -2300,7 +2300,8 @@ static void 
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
}
mode_lib->vba.FractionOfUrgentBandwidth = 
MaxTotalRDBandwidthNoUrgentBurst / mode_lib->vba.ReturnBW;
 
-   if (MaxTotalRDBandwidth <= mode_lib->vba.ReturnBW && 
locals->NotEnoughUrgentLatencyHiding == 0 && 
locals->NotEnoughUrgentLatencyHidingPre == 0 && !VRatioPrefetchMoreThan4
+   if (MaxTotalRDBandwidth <= mode_lib->vba.ReturnBW && 
locals->NotEnoughUrgentLatencyHiding[0][0] == 0 &&
+   locals->NotEnoughUrgentLatencyHidingPre == 0 && 
!VRatioPrefetchMoreThan4
&& !DestinationLineTimesForPrefetchLessThan2)
mode_lib->vba.PrefetchModeSupported = true;
else {
@@ -4821,7 +4822,7 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct 
display_mode_lib *mode_l

>UrgentBurstFactorLumaPre[k],

>UrgentBurstFactorChroma[k],

>UrgentBurstFactorChromaPre[k],
-   
>NotEnoughUrgentLatencyHiding,
+   
>NotEnoughUrgentLatencyHiding[0][0],

>NotEnoughUrgentLatencyHidingPre);
 
if 
(mode_lib->vba.UseUrgentBurstBandwidth == false) {
@@ -4848,13 +4849,13 @@ void dml21_ModeSupportAndSystemConfigurationFull(struct 
display_mode_lib *mode_l
}
locals->BandwidthWithoutPrefetchSupported[i][0] 
= true;
if 
(mode_lib->vba.MaximumReadBandwidthWithoutPrefetch > 
locals->ReturnBWPerState[i][0]
-   || 
locals->NotEnoughUrgentLatencyHiding == 1) {
+   || 
locals->NotEnoughUrgentLatencyHiding[0][0] == 1) {

locals->BandwidthWithoutPrefetchSupported[i][0] = false;
}
 
locals->PrefetchSupported[i][j] = true;
if 
(mode_lib->vba.MaximumReadBandwidthWithPrefetch > locals->ReturnBWPerState[i][0]
-   || 
locals->NotEnoughUrgentLatencyHiding == 1
+   || 
locals->NotEnoughUrgentLatencyHiding[0][0] == 1
|| 
locals->NotEnoughUrgentLatencyHidingPre == 1) {
locals->PrefetchSupported[i][j] = false;
}
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
index 9d2016d8fafe..e1a961a62add 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c
@@ -2596,7 +2596,7 @@ static void 
DISPCLKDPPCLKDCFCLKDeepSleepPrefetchParametersWatermarksAndPerforman
}
}
 
-   v->NotEnoughUrgentLatencyHiding = false;
+   v->NotEnoughUrgentLatencyHiding[0][0] = false;

[PATCH 12/12] drm/amd/display: increase max EDID size to 2k

2021-06-29 Thread Rodrigo Siqueira
From: Aric Cyr 

[Why]
EDID CTS requires at least 2k (16 blocks) to be readable.

[How]
Increase EDID buffer size to 2k

Signed-off-by: Aric Cyr 
Reviewed-by: Anthony Koo 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dc/dc_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dc_types.h 
b/drivers/gpu/drm/amd/display/dc/dc_types.h
index 8016e22114ce..d8e80107b7cc 100644
--- a/drivers/gpu/drm/amd/display/dc/dc_types.h
+++ b/drivers/gpu/drm/amd/display/dc/dc_types.h
@@ -123,7 +123,7 @@ struct dc_context {
 };
 
 
-#define DC_MAX_EDID_BUFFER_SIZE 1280
+#define DC_MAX_EDID_BUFFER_SIZE 2048
 #define DC_EDID_BLOCK_SIZE 128
 #define MAX_SURFACE_NUM 4
 #define NUM_PIXEL_FORMATS 10
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 01/12] drm/amd/display: isolate link training setting override to its own function

2021-06-29 Thread Rodrigo Siqueira
From: Wenjing Liu 

There is a difference between our default behavior and override
behavior. For default behavior we need to decide link training settings
within specs' limitation and mandates.
For override behavior we do not need to follow all these requirements.
We are isolating override decision to its own function to maintain the
integrity of our specs compliant default behavior.

Signed-off-by: Wenjing Liu 
Reviewed-by: George Shen 
Acked-by: Rodrigo Siqueira 
---
 .../gpu/drm/amd/display/dc/core/dc_link_dp.c  | 113 --
 .../gpu/drm/amd/display/dc/inc/dc_link_dp.h   |   1 -
 2 files changed, 53 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index b8832bdde2bc..5c3f78b2f1de 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -1241,29 +1241,15 @@ enum link_training_result dp_check_link_loss_status(
 static inline void decide_8b_10b_training_settings(
 struct dc_link *link,
const struct dc_link_settings *link_setting,
-   const struct dc_link_training_overrides *overrides,
struct link_training_settings *lt_settings)
 {
-   uint32_t lane;
-
memset(lt_settings, '\0', sizeof(struct link_training_settings));
 
/* Initialize link settings */
lt_settings->link_settings.use_link_rate_set = 
link_setting->use_link_rate_set;
lt_settings->link_settings.link_rate_set = link_setting->link_rate_set;
-
-   if (link->preferred_link_setting.link_rate != LINK_RATE_UNKNOWN)
-   lt_settings->link_settings.link_rate = 
link->preferred_link_setting.link_rate;
-   else
-   lt_settings->link_settings.link_rate = link_setting->link_rate;
-
-   if (link->preferred_link_setting.lane_count != LANE_COUNT_UNKNOWN)
-   lt_settings->link_settings.lane_count = 
link->preferred_link_setting.lane_count;
-   else
-   lt_settings->link_settings.lane_count = 
link_setting->lane_count;
-
-   /*@todo[vdevulap] move SS to LS, should not be handled by displaypath*/
-
+   lt_settings->link_settings.link_rate = link_setting->link_rate;
+   lt_settings->link_settings.lane_count = link_setting->lane_count;
/* TODO hard coded to SS for now
 * lt_settings.link_settings.link_spread =
 * dal_display_path_is_ss_supported(
@@ -1271,30 +1257,52 @@ static inline void decide_8b_10b_training_settings(
 * LINK_SPREAD_05_DOWNSPREAD_30KHZ :
 * LINK_SPREAD_DISABLED;
 */
-   /* Initialize link spread */
-   if (link->dp_ss_off)
-   lt_settings->link_settings.link_spread = LINK_SPREAD_DISABLED;
-   else if (overrides->downspread != NULL)
-   lt_settings->link_settings.link_spread
-   = *overrides->downspread
-   ? LINK_SPREAD_05_DOWNSPREAD_30KHZ
-   : LINK_SPREAD_DISABLED;
-   else
-   lt_settings->link_settings.link_spread = 
LINK_SPREAD_05_DOWNSPREAD_30KHZ;
-
+   lt_settings->link_settings.link_spread = link->dp_ss_off ?
+   LINK_SPREAD_DISABLED : LINK_SPREAD_05_DOWNSPREAD_30KHZ;
lt_settings->lttpr_mode = link->lttpr_mode;
+   lt_settings->cr_pattern_time = get_cr_training_aux_rd_interval(link, 
link_setting);
+   lt_settings->eq_pattern_time = get_eq_training_aux_rd_interval(link, 
link_setting);
+   lt_settings->pattern_for_cr = decide_cr_training_pattern(link_setting);
+   lt_settings->pattern_for_eq = decide_eq_training_pattern(link, 
link_setting);
+   lt_settings->enhanced_framing = 1;
+   lt_settings->should_set_fec_ready = true;
+}
 
-   /* Initialize lane settings overrides */
+void dp_decide_training_settings(
+   struct dc_link *link,
+   const struct dc_link_settings *link_settings,
+   struct link_training_settings *lt_settings)
+{
+   if (dp_get_link_encoding_format(link_settings) == DP_8b_10b_ENCODING)
+   decide_8b_10b_training_settings(link, link_settings, 
lt_settings);
+}
+
+static void override_training_settings(
+   struct dc_link *link,
+   const struct dc_link_training_overrides *overrides,
+   struct link_training_settings *lt_settings)
+{
+   uint32_t lane;
+
+   /* Override link settings */
+   if (link->preferred_link_setting.link_rate != LINK_RATE_UNKNOWN)
+   lt_settings->link_settings.link_rate = 
link->preferred_link_setting.link_rate;
+   if (link->preferred_link_setting.lane_count != LANE_COUNT_UNKNOWN)
+   lt_settings->link_settings.lane_count = 
link->preferred_link_setting.lane_count;
+
+   /* Override link spread */
+   if (!link->dp_ss_off && overrides->downspread != NULL)
+   lt_settings->link_settings.link_spread = *overrides->downspread 
?
+   

[PATCH 07/12] drm/amd/display: remove faulty assert

2021-06-29 Thread Rodrigo Siqueira
From: Dmytro Laktyushkin 

Signed-off-by: Dmytro Laktyushkin 
Reviewed-by: Wenjing Liu 
Acked-by: Rodrigo Siqueira 
---
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c 
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 410543797275..335018f0f0c3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -1776,7 +1776,6 @@ bool perform_link_training_with_retries(
link_enc = stream->link_enc;
else
link_enc = link->link_enc;
-   ASSERT(link_enc);
 
/* We need to do this before the link training to ensure the idle 
pattern in SST
 * mode will be sent right after the link training
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/aperture: Pass DRM driver structure instead of driver name

2021-06-29 Thread Das, Nirmoy

LGTM

Acked-by: Nirmoy Das 

On 6/29/2021 3:58 PM, Thomas Zimmermann wrote:

Print the name of the DRM driver when taking over fbdev devices. Makes
the output to dmesg more consistent. Note that the driver name is only
used for printing a string to the kernel log. No UAPI is affected by this
change.

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  2 +-
  drivers/gpu/drm/armada/armada_drv.c   |  2 +-
  drivers/gpu/drm/ast/ast_drv.c |  2 +-
  drivers/gpu/drm/bochs/bochs_drv.c |  2 +-
  drivers/gpu/drm/drm_aperture.c| 19 ---
  .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  2 +-
  drivers/gpu/drm/hyperv/hyperv_drm_drv.c   |  4 ++--
  drivers/gpu/drm/i915/i915_drv.c   |  2 +-
  drivers/gpu/drm/meson/meson_drv.c |  2 +-
  drivers/gpu/drm/mgag200/mgag200_drv.c |  2 +-
  drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
  drivers/gpu/drm/nouveau/nouveau_drm.c |  2 +-
  drivers/gpu/drm/qxl/qxl_drv.c |  2 +-
  drivers/gpu/drm/radeon/radeon_drv.c   |  2 +-
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  2 +-
  drivers/gpu/drm/sun4i/sun4i_drv.c |  2 +-
  drivers/gpu/drm/tegra/drm.c   |  2 +-
  drivers/gpu/drm/tiny/cirrus.c |  2 +-
  drivers/gpu/drm/vboxvideo/vbox_drv.c  |  2 +-
  drivers/gpu/drm/vc4/vc4_drv.c |  2 +-
  drivers/gpu/drm/virtio/virtgpu_drv.c  |  2 +-
  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |  2 +-
  include/drm/drm_aperture.h| 14 +-
  23 files changed, 43 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f30c525caac..accf9c1b967a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1278,7 +1278,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
  #endif
  
  	/* Get rid of things like offb */

-   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
"amdgpudrmfb");
+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_kms_driver);
if (ret)
return ret;
  
diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c

index dab0a1f0983b..31925ae3ab72 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -95,7 +95,7 @@ static int armada_drm_bind(struct device *dev)
}
  
  	/* Remove early framebuffers */

-   ret = drm_aperture_remove_framebuffers(false, "armada-drm-fb");
+   ret = drm_aperture_remove_framebuffers(false, _drm_driver);
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5aa452b4efe6..86d5cd7b6318 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -100,7 +100,7 @@ static int ast_remove_conflicting_framebuffers(struct 
pci_dev *pdev)
primary = pdev->resource[PCI_ROM_RESOURCE].flags & 
IORESOURCE_ROM_SHADOW;
  #endif
  
-	return drm_aperture_remove_conflicting_framebuffers(base, size, primary, "astdrmfb");

+   return drm_aperture_remove_conflicting_framebuffers(base, size, primary, 
_driver);
  }
  
  static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)

diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index c828cadbabff..0d232b44ecd7 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -110,7 +110,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
  
-	ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "bochsdrmfb");

+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_driver);
if (ret)
return ret;
  
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c

index 9335d9d6cf9a..9ac39cf11694 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -33,6 +33,10 @@
   *
   * .. code-block:: c
   *
+ * static const struct drm_driver example_driver = {
+ * ...
+ * };
+ *
   *static int remove_conflicting_framebuffers(struct pci_dev *pdev)
   *{
   *bool primary = false;
@@ -46,7 +50,7 @@
   *#endif
   *
   *return drm_aperture_remove_conflicting_framebuffers(base, size, 
primary,
- * "example 
driver");
+ * 
_driver);
   *}
   *
   *static int probe(struct pci_dev *pdev)
@@ -274,7 +278,7 @@ static void drm_aperture_detach_drivers(resource_size_t 
base, resource_size_t si
   * @base: the 

[PATCH 2/2] drm/amdgpu: separate out vm pasid assignment

2021-06-29 Thread Nirmoy Das
Use new helper function amdgpu_vm_set_pasid() to
assign vm pasid value. This also ensures that we don't free
a pasid from vm code as pasids are allocated somewhere else.

Signed-off-by: Nirmoy Das 
---
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 13 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 10 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 28 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h|  4 +--
 4 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index f96598279593..3a2ac7f66bbd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1287,11 +1287,22 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct 
kgd_dev *kgd,
if (avm->process_info)
return -EINVAL;
 
+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (avm->pasid) {
+   amdgpu_pasid_free(avm->pasid);
+   amdgpu_vm_set_pasid(adev, avm, 0);
+   }
+
/* Convert VM into a compute VM */
-   ret = amdgpu_vm_make_compute(adev, avm, pasid);
+   ret = amdgpu_vm_make_compute(adev, avm);
if (ret)
return ret;
 
+   ret = amdgpu_vm_set_pasid(adev, avm, pasid);
+   if (ret)
+   return ret;
/* Initialize KFD part of the VM and process info */
ret = init_kfd_vm(avm, process_info, ef);
if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index cbb932f97355..66bf8b0c56bb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -1178,10 +1178,14 @@ int amdgpu_driver_open_kms(struct drm_device *dev, 
struct drm_file *file_priv)
pasid = 0;
}
 
-   r = amdgpu_vm_init(adev, >vm, pasid);
+   r = amdgpu_vm_init(adev, >vm);
if (r)
goto error_pasid;
 
+   r = amdgpu_vm_set_pasid(adev, >vm, pasid);
+   if (r)
+   goto error_vm;
+
fpriv->prt_va = amdgpu_vm_bo_add(adev, >vm, NULL);
if (!fpriv->prt_va) {
r = -ENOMEM;
@@ -1209,8 +1213,10 @@ int amdgpu_driver_open_kms(struct drm_device *dev, 
struct drm_file *file_priv)
amdgpu_vm_fini(adev, >vm);
 
 error_pasid:
-   if (pasid)
+   if (pasid) {
amdgpu_pasid_free(pasid);
+   amdgpu_vm_set_pasid(adev, >vm, 0);
+   }
 
kfree(fpriv);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index fd92ff27931a..1dccede6387e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2899,14 +2899,13 @@ long amdgpu_vm_wait_idle(struct amdgpu_vm *vm, long 
timeout)
  *
  * @adev: amdgpu_device pointer
  * @vm: requested vm
- * @pasid: Process address space identifier
  *
  * Init @vm fields.
  *
  * Returns:
  * 0 for success, error for failure.
  */
-int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm, u32 pasid)
+int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm)
 {
struct amdgpu_bo *root_bo;
struct amdgpu_bo_vm *root;
@@ -2980,10 +2979,6 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm, u32 pasid)
 
amdgpu_bo_unreserve(vm->root.bo);
 
-   r = amdgpu_vm_set_pasid(adev, vm, pasid);
-   if (r)
-   goto error_free_root;
-
INIT_KFIFO(vm->faults);
 
return 0;
@@ -3039,7 +3034,6 @@ static int amdgpu_vm_check_clean_reserved(struct 
amdgpu_device *adev,
  *
  * @adev: amdgpu_device pointer
  * @vm: requested vm
- * @pasid: pasid to use
  *
  * This only works on GFX VMs that don't have any BOs added and no
  * page tables allocated yet.
@@ -3047,7 +3041,6 @@ static int amdgpu_vm_check_clean_reserved(struct 
amdgpu_device *adev,
  * Changes the following VM parameters:
  * - use_cpu_for_update
  * - pte_supports_ats
- * - pasid (old PASID is released, because compute manages its own PASIDs)
  *
  * Reinitializes the page directory to reflect the changed ATS
  * setting.
@@ -3055,8 +3048,7 @@ static int amdgpu_vm_check_clean_reserved(struct 
amdgpu_device *adev,
  * Returns:
  * 0 for success, -errno for errors.
  */
-int amdgpu_vm_make_compute(struct amdgpu_device *adev, struct amdgpu_vm *vm,
-  u32 pasid)
+int amdgpu_vm_make_compute(struct amdgpu_device *adev, struct amdgpu_vm *vm)
 {
bool pte_support_ats = (adev->asic_type == CHIP_RAVEN);
int r;
@@ -3070,16 +3062,6 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
if (r)
goto unreserve_bo;
 
-   /* Free the original amdgpu allocated pasid,
-* will be replaced with kfd allocated pasid.
-*/
-  

[PATCH 1/2] drm/amdgpu: use xarray for storing pasid in vm

2021-06-29 Thread Nirmoy Das
Replace idr with xarray as we actually need hash functionality.
Cleanup code related to vm pasid by adding helper function.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 149 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   6 +-
 2 files changed, 73 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 63975bda8e76..fd92ff27931a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -87,6 +87,46 @@ struct amdgpu_prt_cb {
struct dma_fence_cb cb;
 };
 
+/**
+ * amdgpu_vm_set_pasid - manage pasid and vm ptr mapping
+ *
+ * @adev: amdgpu_device pointer
+ * @vm: amdgpu_vm pointer
+ * @pasid: requested pasid
+ *
+ * Each pasid associats with a vm pointer. This function can be use to
+ * create a new pasid,vm association or to remove an existing one. To remove an
+ * existing pasid,vm association, pass 0 as @pasid.
+ */
+int amdgpu_vm_set_pasid(struct amdgpu_device *adev, struct amdgpu_vm *vm,
+   unsigned long pasid)
+{
+   int r;
+
+   if (vm->pasid == pasid)
+   return 0;
+
+   if (vm->pasid) {
+   r = xa_err(xa_erase_irq(>vm_manager.pasids, vm->pasid));
+   if (r < 0)
+   return r;
+
+   vm->pasid = 0;
+   }
+
+   if (pasid) {
+   r = xa_err(xa_store_irq(>vm_manager.pasids, pasid, vm,
+   GFP_KERNEL));
+   if (r < 0)
+   return r;
+
+   vm->pasid = pasid;
+   }
+
+
+   return 0;
+}
+
 /*
  * vm eviction_lock can be taken in MMU notifiers. Make sure no reclaim-FS
  * happens while holding this lock anywhere to prevent deadlocks when
@@ -2940,18 +2980,9 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm, u32 pasid)
 
amdgpu_bo_unreserve(vm->root.bo);
 
-   if (pasid) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-   if (r < 0)
-   goto error_free_root;
-
-   vm->pasid = pasid;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto error_free_root;
 
INIT_KFIFO(vm->faults);
 
@@ -3039,18 +3070,15 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
if (r)
goto unreserve_bo;
 
-   if (pasid) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (vm->pasid)
+   amdgpu_pasid_free(vm->pasid);
 
-   if (r == -ENOSPC)
-   goto unreserve_bo;
-   r = 0;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto unreserve_bo;
 
/* Check if PD needs to be reinitialized and do it before
 * changing any other state, in case it fails.
@@ -3061,7 +3089,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
   to_amdgpu_bo_vm(vm->root.bo),
   false);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
}
 
/* Update VM state */
@@ -3078,7 +3106,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
r = amdgpu_bo_sync_wait(vm->root.bo,
AMDGPU_FENCE_OWNER_UNDEFINED, true);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
 
vm->update_funcs = _vm_cpu_funcs;
} else {
@@ -3088,36 +3116,13 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
vm->last_update = NULL;
vm->is_compute_context = true;
 
-   if (vm->pasid) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   idr_remove(>vm_manager.pasid_idr, vm->pasid);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-
-   /* Free the original amdgpu allocated pasid
-* Will be replaced with kfd allocated pasid
-*/
-   amdgpu_pasid_free(vm->pasid);
-   vm->pasid = 0;
-   }

Re: [PATCH] drm/amd/display: Respect CONFIG_FRAME_WARN=0 in dml Makefile

2021-06-29 Thread Harry Wentland
On 2021-06-28 9:27 p.m., Reka Norman wrote:
> Setting CONFIG_FRAME_WARN=0 should disable 'stack frame larger than'
> warnings. This is useful for example in KASAN builds. Make the dml
> Makefile respect this config.
> 
> Fixes the following build warnings with CONFIG_KASAN=y and
> CONFIG_FRAME_WARN=0:
> 
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3642:6:
> warning: stack frame size of 2216 bytes in function
> 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]
> drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3957:6:
> warning: stack frame size of 2568 bytes in function
> 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]
> 
> Signed-off-by: Reka Norman 

Reviewed-by: Harry Wentland 

Harry

> ---
> 
>  drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
> b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> index d34024fd798a..45862167e6ce 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> @@ -50,6 +50,10 @@ dml_ccflags += -msse2
>  endif
>  endif
>  
> +ifneq ($(CONFIG_FRAME_WARN),0)
> +frame_warn_flag := -Wframe-larger-than=2048
> +endif
> +
>  CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
>  
>  ifdef CONFIG_DRM_AMD_DC_DCN
> @@ -60,9 +64,9 @@ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o 
> := $(dml_ccflags)
>  CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := 
> $(dml_ccflags)
>  CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
>  CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
> -CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) 
> -Wframe-larger-than=2048
> +CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) 
> $(frame_warn_flag)
>  CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_rq_dlg_calc_30.o := $(dml_ccflags)
> -CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) 
> -Wframe-larger-than=2048
> +CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) 
> $(frame_warn_flag)
>  CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_rq_dlg_calc_31.o := $(dml_ccflags)
>  CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
>  CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_rcflags)
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: add license to umc_8_7_0_sh_mask.h

2021-06-29 Thread Harry Wentland
On 2021-06-29 10:14 a.m., Alex Deucher wrote:
> Was missing. Add it.
> 
> Fixes: 6b36fa6143f6ca ("drm/amdgpu: add umc v8_7_0 IP headers")
> Signed-off-by: Alex Deucher 

Reviewed-by: Harry Wentland 

Harry

> ---
>  .../include/asic_reg/umc/umc_8_7_0_sh_mask.h  | 21 +++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h 
> b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
> index d5ef91d3c391..20329da53b0a 100644
> --- a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
> +++ b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
> @@ -1,3 +1,24 @@
> +/*
> + * Copyright (C) 2020  Advanced Micro Devices, Inc.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included
> + * in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
> + * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
> LIABILITY, WHETHER IN
> + * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
>  #ifndef _umc_8_7_0_SH_MASK_HEADER
>  #define _umc_8_7_0_SH_MASK_HEADER
>  
> 

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amdgpu: add license to umc_8_7_0_sh_mask.h

2021-06-29 Thread Alex Deucher
Was missing. Add it.

Fixes: 6b36fa6143f6ca ("drm/amdgpu: add umc v8_7_0 IP headers")
Signed-off-by: Alex Deucher 
---
 .../include/asic_reg/umc/umc_8_7_0_sh_mask.h  | 21 +++
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
index d5ef91d3c391..20329da53b0a 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
@@ -1,3 +1,24 @@
+/*
+ * Copyright (C) 2020  Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
LIABILITY, WHETHER IN
+ * AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
 #ifndef _umc_8_7_0_SH_MASK_HEADER
 #define _umc_8_7_0_SH_MASK_HEADER
 
-- 
2.31.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/2] drm/amd/pm: update the gpu metrics data retrieving for Sienna Cichlid

2021-06-29 Thread Lazar, Lijo




On 6/25/2021 1:42 PM, Evan Quan wrote:

Due to the structure layout change: "uint32_t ThrottlerStatus" -> "
uint8_t  ThrottlingPercentage[THROTTLER_COUNT]".

Change-Id: Id5c148b0584d972ae73fb9d7347a312944cec13d
Signed-off-by: Evan Quan 
---
  .../pm/inc/smu11_driver_if_sienna_cichlid.h   |  63 -
  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 234 --
  2 files changed, 222 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h 
b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
index 61c87c39be80..0b916a1933df 100644
--- a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
+++ b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
@@ -211,6 +211,7 @@ typedef enum {
  #define THROTTLER_FIT_BIT  17
  #define THROTTLER_PPM_BIT  18
  #define THROTTLER_APCC_BIT 19
+#define THROTTLER_COUNT20
  
  // FW DState Features Control Bits

  // FW DState Features Control Bits
@@ -1406,7 +1407,67 @@ typedef struct {
  } SmuMetrics_t;
  
  typedef struct {

-  SmuMetrics_t SmuMetrics;
+  uint32_t CurrClock[PPCLK_COUNT];
+
+  uint16_t AverageGfxclkFrequencyPreDs;
+  uint16_t AverageGfxclkFrequencyPostDs;
+  uint16_t AverageFclkFrequencyPreDs;
+  uint16_t AverageFclkFrequencyPostDs;
+  uint16_t AverageUclkFrequencyPreDs  ;
+  uint16_t AverageUclkFrequencyPostDs  ;
+
+
+  uint16_t AverageGfxActivity;
+  uint16_t AverageUclkActivity   ;
+  uint8_t  CurrSocVoltageOffset  ;
+  uint8_t  CurrGfxVoltageOffset  ;
+  uint8_t  CurrMemVidOffset  ;
+  uint8_t  Padding8;
+  uint16_t AverageSocketPower;
+  uint16_t TemperatureEdge   ;
+  uint16_t TemperatureHotspot;
+  uint16_t TemperatureMem;
+  uint16_t TemperatureVrGfx  ;
+  uint16_t TemperatureVrMem0 ;
+  uint16_t TemperatureVrMem1 ;
+  uint16_t TemperatureVrSoc  ;
+  uint16_t TemperatureLiquid0;
+  uint16_t TemperatureLiquid1;
+  uint16_t TemperaturePlx;
+  uint16_t Padding16 ;
+  uint32_t AccCnt;
+  uint8_t  ThrottlingPercentage[THROTTLER_COUNT];
+
+
+  uint8_t  LinkDpmLevel;
+  uint8_t  CurrFanPwm;
+  uint16_t CurrFanSpeed;
+
+  //BACO metrics, PMFW-1721
+  //metrics for D3hot entry/exit and driver ARM msgs
+  uint8_t D3HotEntryCountPerMode[D3HOT_SEQUENCE_COUNT];
+  uint8_t D3HotExitCountPerMode[D3HOT_SEQUENCE_COUNT];
+  uint8_t ArmMsgReceivedCountPerMode[D3HOT_SEQUENCE_COUNT];
+
+  //PMFW-4362
+  uint32_t EnergyAccumulator;
+  uint16_t AverageVclk0Frequency  ;
+  uint16_t AverageDclk0Frequency  ;
+  uint16_t AverageVclk1Frequency  ;
+  uint16_t AverageDclk1Frequency  ;
+  uint16_t VcnActivityPercentage  ; //place holder, David N. to provide full 
sequence
+  uint8_t  PcieRate   ;
+  uint8_t  PcieWidth  ;
+  uint16_t AverageGfxclkFrequencyTarget;
+  uint16_t Padding16_2;
+
+} SmuMetrics_V2_t;
+
+typedef struct {
+  union {
+SmuMetrics_t SmuMetrics;
+SmuMetrics_V2_t SmuMetrics_V2;
+  };
uint32_t Spare[1];
  
// Padding - ignore

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
index 0c3407025eb2..f882c6756bf0 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
@@ -80,6 +80,13 @@
(*member) = (smu->smu_table.driver_pptable + 
offsetof(PPTable_t, field));\
  } while(0)
  
+#define GET_METRICS_MEMBER(field, member) do { \

+   if ((smu->adev->asic_type == CHIP_SIENNA_CICHLID) && (smu->smc_fw_version 
>= 0x3A4300)) \
+   (*member) = ((void *)(&(((SmuMetricsExternal_t 
*)(smu->smu_table.metrics_table))->SmuMetrics_V2)) + offsetof(SmuMetrics_V2_t, 
field)); \
+   else \
+   (*member) = ((void *)(&(((SmuMetricsExternal_t 
*)(smu->smu_table.metrics_table))->SmuMetrics)) + offsetof(SmuMetrics_t, field)); \
+} while(0)
+
  static int get_table_size(struct smu_context *smu)
  {
if (smu->adev->asic_type == CHIP_BEIGE_GOBY)
@@ -489,13 +496,33 @@ static int sienna_cichlid_tables_init(struct smu_context 
*smu)
return -ENOMEM;
  }
  
+static uint32_t sienna_cichlid_get_throttler_status_locked(struct smu_context *smu)

+{
+   struct smu_table_context *smu_table= >smu_table;
+   SmuMetricsExternal_t *metrics_ext =
+   (SmuMetricsExternal_t *)(smu_table->metrics_table);
+   uint32_t throttler_status = 0;
+   int i;
+
+   if ((smu->adev->asic_type == CHIP_SIENNA_CICHLID) &&
+(smu->smc_fw_version >= 0x3A4300)) {
+   for (i = 0; i < THROTTLER_COUNT; i++) {
+   if (metrics_ext->SmuMetrics_V2.ThrottlingPercentage[i])
+   throttler_status |= 1U << i;
+   }
+   } else {
+   throttler_status = metrics_ext->SmuMetrics.ThrottlerStatus;
+   }
+
+   return throttler_status;
+}
+
  static 

Re: [PATCH] drm/aperture: Pass DRM driver structure instead of driver name

2021-06-29 Thread Neil Armstrong
Hi,

On 29/06/2021 15:58, Thomas Zimmermann wrote:
> Print the name of the DRM driver when taking over fbdev devices. Makes
> the output to dmesg more consistent. Note that the driver name is only
> used for printing a string to the kernel log. No UAPI is affected by this
> change.
> 
> Signed-off-by: Thomas Zimmermann 
> ---

...

>  drivers/gpu/drm/meson/meson_drv.c |  2 +-

Acked-by: Neil Armstrong 

...

>  
> diff --git a/drivers/gpu/drm/meson/meson_drv.c 
> b/drivers/gpu/drm/meson/meson_drv.c
> index a7388bf7c838..3d0ccc7eef1b 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -285,7 +285,7 @@ static int meson_drv_bind_master(struct device *dev, bool 
> has_components)
>* Remove early framebuffers (ie. simplefb). The framebuffer can be
>* located anywhere in RAM
>*/
> - ret = drm_aperture_remove_framebuffers(false, "meson-drm-fb");
> + ret = drm_aperture_remove_framebuffers(false, _driver);
>   if (ret)
>   goto free_drm;
>  

...
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amd/display: Respect CONFIG_FRAME_WARN=0 in dml Makefile

2021-06-29 Thread Alex Deucher
Applied.  Thanks!

Alex

On Tue, Jun 29, 2021 at 11:10 AM Harry Wentland  wrote:
>
> On 2021-06-28 9:27 p.m., Reka Norman wrote:
> > Setting CONFIG_FRAME_WARN=0 should disable 'stack frame larger than'
> > warnings. This is useful for example in KASAN builds. Make the dml
> > Makefile respect this config.
> >
> > Fixes the following build warnings with CONFIG_KASAN=y and
> > CONFIG_FRAME_WARN=0:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3642:6:
> > warning: stack frame size of 2216 bytes in function
> > 'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3957:6:
> > warning: stack frame size of 2568 bytes in function
> > 'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]
> >
> > Signed-off-by: Reka Norman 
>
> Reviewed-by: Harry Wentland 
>
> Harry
>
> > ---
> >
> >  drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > index d34024fd798a..45862167e6ce 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
> > @@ -50,6 +50,10 @@ dml_ccflags += -msse2
> >  endif
> >  endif
> >
> > +ifneq ($(CONFIG_FRAME_WARN),0)
> > +frame_warn_flag := -Wframe-larger-than=2048
> > +endif
> > +
> >  CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
> >
> >  ifdef CONFIG_DRM_AMD_DC_DCN
> > @@ -60,9 +64,9 @@ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o 
> > := $(dml_ccflags)
> >  CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := 
> > $(dml_ccflags)
> >  CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
> >  CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := 
> > $(dml_ccflags)
> > -CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) 
> > -Wframe-larger-than=2048
> > +CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) 
> > $(frame_warn_flag)
> >  CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_rq_dlg_calc_30.o := 
> > $(dml_ccflags)
> > -CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) 
> > -Wframe-larger-than=2048
> > +CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) 
> > $(frame_warn_flag)
> >  CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_rq_dlg_calc_31.o := 
> > $(dml_ccflags)
> >  CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
> >  CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_rcflags)
> >
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/aperture: Pass DRM driver structure instead of driver name

2021-06-29 Thread Chen-Yu Tsai
On Tue, Jun 29, 2021 at 9:58 PM Thomas Zimmermann  wrote:
>
> Print the name of the DRM driver when taking over fbdev devices. Makes
> the output to dmesg more consistent. Note that the driver name is only
> used for printing a string to the kernel log. No UAPI is affected by this
> change.
>
> Signed-off-by: Thomas Zimmermann 
> ---

>  drivers/gpu/drm/sun4i/sun4i_drv.c |  2 +-

Acked-by: Chen-Yu Tsai 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v3 1/1] drm/amdgpu: return early for non-TTM_PL_TT type BOs

2021-06-29 Thread Das, Nirmoy

Hi Christian,


Could you please pick  this up for drm-misc-next or fixes ?


Regards,

Nirmoy

On 6/29/2021 1:44 PM, Nirmoy Das wrote:

Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.

v3: remove extra braces.
v2: merge if-conditions.

Signed-off-by: Nirmoy Das 
Reviewed-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b46726e47bce..7a82e7b9e18e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -926,7 +926,8 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
bo_mem->mem_type == AMDGPU_PL_OA)
return -EINVAL;

-   if (!amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
+   if (bo_mem->mem_type != TTM_PL_TT ||
+   !amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
gtt->offset = AMDGPU_BO_INVALID_OFFSET;
return 0;
}
--
2.32.0


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH v3 1/1] drm/amdgpu: return early for non-TTM_PL_TT type BOs

2021-06-29 Thread Nirmoy Das
Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.

v3: remove extra braces.
v2: merge if-conditions.

Signed-off-by: Nirmoy Das 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b46726e47bce..7a82e7b9e18e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -926,7 +926,8 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
bo_mem->mem_type == AMDGPU_PL_OA)
return -EINVAL;

-   if (!amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
+   if (bo_mem->mem_type != TTM_PL_TT ||
+   !amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
gtt->offset = AMDGPU_BO_INVALID_OFFSET;
return 0;
}
--
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 2/2] drm/amdgpu: raise error on incorrect mem_type

2021-06-29 Thread Das, Nirmoy


On 6/29/2021 1:06 PM, Christian König wrote:



Am 29.06.21 um 09:36 schrieb Nirmoy Das:

Be more defensive and raise error on wrong mem_type
argument in amdgpu_gtt_mgr_has_gart_addr().

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

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

index 543000304a1c..0b0fa87b115c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -107,8 +107,12 @@ const struct attribute_group 
amdgpu_gtt_mgr_attr_group = {

   */
  bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_resource *res)
  {
-    struct amdgpu_gtt_node *node = to_amdgpu_gtt_node(res);
+    struct amdgpu_gtt_node *node;
+
+    if (WARN_ON(res->mem_type != TTM_PL_TT))
+    return false;


I'm not sure that is a good idea. The GTT manager itself shouldn't 
have to deal with incorrect usage of it's component.



This is in-case we accidentally use amdgpu_gtt_mgr_has_gart_addr() for 
PREEMPT bo in future. I will drop it as the previous patch should give 
us enough hint.



Regards,

Nirmoy




Christian.


  +    node = to_amdgpu_gtt_node(res);
  return drm_mm_node_allocated(>base.mm_nodes[0]);
  }



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH -next] drm/radeon: Add the missed drm_gem_object_put() in radeon_user_framebuffer_create()

2021-06-29 Thread Christian König

Am 29.06.21 um 13:44 schrieb Jing Xiangfeng:

radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
an error path. Add the missed function call to fix it.

Signed-off-by: Jing Xiangfeng 


I'm pretty sure that I already reviewed the same patch a few weeks ago, 
but it looks like it never went upstream.


Reviewed-by: Christian König 

Maybe add CC: stable as well?

Regards,
Christian.


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

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 652af7a134bd..1d03ec763604 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1325,6 +1325,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
/* Handle is imported dma-buf, so cannot be migrated to VRAM for 
scanout */
if (obj->import_attach) {
DRM_DEBUG_KMS("Cannot create framebuffer from imported 
dma_buf\n");
+   drm_gem_object_put(obj);
return ERR_PTR(-EINVAL);
}
  


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: Set ttm caching flags during bo allocation

2021-06-29 Thread Das, Nirmoy

Thanks for the detailed commit message :)

Acked-by: Nirmoy Das 

On 6/29/2021 1:15 AM, Oak Zeng wrote:

The ttm caching flags (ttm_cached, ttm_write_combined etc) are
used to determine a buffer object's mapping attributes in both
CPU page table and GPU page table (when that buffer is also
accessed by GPU). Currently the ttm caching flags are set in
function amdgpu_ttm_io_mem_reserve which is called during
DRM_AMDGPU_GEM_MMAP ioctl. This has a problem since the GPU
mapping of the buffer object (ioctl DRM_AMDGPU_GEM_VA) can
happen earlier than the mmap time, thus the GPU page table
update code can't pick up the right ttm caching flags to
decide the right GPU page table attributes.

This patch moves the ttm caching flags setting to function
amdgpu_vram_mgr_new - this function is called during the
first step of a buffer object create (eg, DRM_AMDGPU_GEM_CREATE)
so the later both CPU and GPU mapping function calls will
pick up this flag for CPU/GPU page table set up.

Signed-off-by: Oak Zeng 
Suggested-by: Christian Koenig 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 4 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 +
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6297363..93acf6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -607,10 +607,6 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_device 
*bdev,
  
  		mem->bus.offset += adev->gmc.aper_base;

mem->bus.is_iomem = true;
-   if (adev->gmc.xgmi.connected_to_cpu)
-   mem->bus.caching = ttm_cached;
-   else
-   mem->bus.caching = ttm_write_combined;
break;
default:
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index a52e17e..6cb66eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -454,6 +454,11 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager 
*man,
if (i == 1)
mem->placement |= TTM_PL_FLAG_CONTIGUOUS;
  
+	if (adev->gmc.xgmi.connected_to_cpu)

+   mem->bus.caching = ttm_cached;
+   else
+   mem->bus.caching = ttm_write_combined;
+
atomic64_add(vis_usage, >vis_usage);
mem->mm_node = nodes;
return 0;

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v2 2/2] drm/amdgpu: free pasid early before converting a vm

2021-06-29 Thread Das, Nirmoy


On 6/29/2021 1:12 PM, Christian König wrote:

Am 29.06.21 um 09:55 schrieb Nirmoy Das:

VM code should not be responsible for freeing pasid as pasid
gets allocated outside of VM code, before initializing a vm.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 6 --
  2 files changed, 8 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 f96598279593..5a9006aabec7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1287,6 +1287,14 @@ int 
amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,

  if (avm->process_info)
  return -EINVAL;

+    /* Free the original amdgpu allocated pasid,
+ * will be replaced with kfd allocated pasid.
+ */
+    if (avm->pasid) {
+    amdgpu_pasid_free(avm->pasid);
+    amdgpu_vm_set_pasid(adev, avm, 0);
+    }
+
  /* Convert VM into a compute VM */
  ret = amdgpu_vm_make_compute(adev, avm, pasid);


I'm really wondering if amdgpu_vm_make_compute() and amdgpu_vm_init() 
now need the pasid as parameter anymore.



We could use the exported amdgpu_vm_set_pasid() and remove that pasid 
from both functions.



Regards,

Nirmoy




Christian.


  if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 9b0e8a9d7f86..0bd9575b0872 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3057,12 +3057,6 @@ int amdgpu_vm_make_compute(struct 
amdgpu_device *adev, struct amdgpu_vm *vm,

  if (r)
  goto unreserve_bo;

-    /* Free the original amdgpu allocated pasid,
- * will be replaced with kfd allocated pasid.
- */
-    if (vm->pasid)
-    amdgpu_pasid_free(vm->pasid);
-
  r = amdgpu_vm_set_pasid(adev, vm, pasid);
  if (r)
  goto unreserve_bo;
--
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Cnirmoy.das%40amd.com%7C2a379081693b490c09fd08d93aeed4b3%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637605619715690644%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=6ztVdZYy8nsS6OekDFAjDc2toJYYnl9RUZEyl5Kn6c0%3Dreserved=0 




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/1] drm/amdgpu: Read clock counter via MMIO to reduce delay

2021-06-29 Thread Christian König

Am 29.06.21 um 11:47 schrieb YuBiao Wang:

[Why]
GPU timing counters are read via KIQ under sriov, which will introduce
a delay.

[How]
It could be directly read by MMIO.

v2: Add additional check to prevent carryover issue.

Signed-off-by: YuBiao Wang 
---
  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 +++--
  1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index ff7e9f49040e..191b9e3ee3ea 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -7610,6 +7610,7 @@ static int gfx_v10_0_soft_reset(void *handle)
  static uint64_t gfx_v10_0_get_gpu_clock_counter(struct amdgpu_device *adev)
  {
uint64_t clock;
+   uint64_t clock_lo, clock_hi, hi_check;
  
  	amdgpu_gfx_off_ctrl(adev, false);

mutex_lock(>gfx.gpu_clock_mutex);
@@ -7620,8 +7621,16 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)
((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Vangogh) << 32ULL);
break;
default:
-   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
-   ((uint64_t)RREG32_SOC15(SMUIO, 0, mmGOLDEN_TSC_COUNT_UPPER) 
<< 32ULL);
+   clock_hi = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   // If carry happens, continuously read until no carry happens
+   while (hi_check != clock_hi) {
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   clock_hi = hi_check;
+   hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   }


This could be refined into:

do {
    clock_hi =READ_...
    clock_lo = READ_
} while (unlikely(clock_hi != READ_))

Apart from that looks like a good idea to me.

Regards,
Christian.


+   clock = (uint64_t)clock_lo | ((uint64_t)clock_hi << 32ULL);
break;
}
mutex_unlock(>gfx.gpu_clock_mutex);


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/2] drm/amdgpu: use xarray for storing pasid in vm

2021-06-29 Thread Das, Nirmoy


On 6/29/2021 1:10 PM, Christian König wrote:



Am 29.06.21 um 09:49 schrieb Nirmoy Das:

Replace idr with xarray as we actually need hash functionality.
Cleanup code related to vm pasid by adding helper function.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 136 ++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   6 +-
  2 files changed, 60 insertions(+), 82 deletions(-)

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

index 63975bda8e76..9b0e8a9d7f86 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -87,6 +87,33 @@ struct amdgpu_prt_cb {
  struct dma_fence_cb cb;
  };
  +int amdgpu_vm_set_pasid(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,

+    unsigned long pasid)


Proper kerneldoc please when the function is now exported.



I had one, missed it this revision :/





+{
+    unsigned long flags;
+    int r;
+
+    if (vm->pasid == pasid)
+    return 0;
+
+    if (vm->pasid) {
+    r = xa_err(xa_erase_irq(>vm_manager.pasids, vm->pasid));
+    if (r < 0)
+    return r;


I think we should have a "vm->pasid = 0;" here so that we have a 
consistent state when inserting the new pasid below failed.




+    }
+
+    if (pasid) {
+    r = xa_err(xa_store_irq(>vm_manager.pasids, pasid, vm,
+    GFP_KERNEL));
+    if (r < 0)
+    return r;
+    }
+
+    vm->pasid = pasid;


This assignment can then be moved into the "if" as well.

Apart from that looks like a really nice cleanup to me.



Thanks, I will resend.



Regards,
Christian.


+
+    return 0;
+}
+
  /*
   * vm eviction_lock can be taken in MMU notifiers. Make sure no 
reclaim-FS

   * happens while holding this lock anywhere to prevent deadlocks when
@@ -2940,18 +2967,9 @@ int amdgpu_vm_init(struct amdgpu_device *adev, 
struct amdgpu_vm *vm, u32 pasid)

    amdgpu_bo_unreserve(vm->root.bo);
  -    if (pasid) {
-    unsigned long flags;
-
-    spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-    r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid 
+ 1,

-  GFP_ATOMIC);
- spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-    if (r < 0)
-    goto error_free_root;
-
-    vm->pasid = pasid;
-    }
+    r = amdgpu_vm_set_pasid(adev, vm, pasid);
+    if (r)
+    goto error_free_root;
    INIT_KFIFO(vm->faults);
  @@ -3039,18 +3057,15 @@ int amdgpu_vm_make_compute(struct 
amdgpu_device *adev, struct amdgpu_vm *vm,

  if (r)
  goto unreserve_bo;
  -    if (pasid) {
-    unsigned long flags;
-
-    spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-    r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid 
+ 1,

-  GFP_ATOMIC);
- spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
+    /* Free the original amdgpu allocated pasid,
+ * will be replaced with kfd allocated pasid.
+ */
+    if (vm->pasid)
+    amdgpu_pasid_free(vm->pasid);
  -    if (r == -ENOSPC)
-    goto unreserve_bo;
-    r = 0;
-    }
+    r = amdgpu_vm_set_pasid(adev, vm, pasid);
+    if (r)
+    goto unreserve_bo;
    /* Check if PD needs to be reinitialized and do it before
   * changing any other state, in case it fails.
@@ -3061,7 +3076,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device 
*adev, struct amdgpu_vm *vm,

 to_amdgpu_bo_vm(vm->root.bo),
 false);
  if (r)
-    goto free_idr;
+    goto free_pasid_entry;
  }
    /* Update VM state */
@@ -3078,7 +3093,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device 
*adev, struct amdgpu_vm *vm,

  r = amdgpu_bo_sync_wait(vm->root.bo,
  AMDGPU_FENCE_OWNER_UNDEFINED, true);
  if (r)
-    goto free_idr;
+    goto free_pasid_entry;
    vm->update_funcs = _vm_cpu_funcs;
  } else {
@@ -3088,36 +3103,13 @@ int amdgpu_vm_make_compute(struct 
amdgpu_device *adev, struct amdgpu_vm *vm,

  vm->last_update = NULL;
  vm->is_compute_context = true;
  -    if (vm->pasid) {
-    unsigned long flags;
-
-    spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-    idr_remove(>vm_manager.pasid_idr, vm->pasid);
- spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-
-    /* Free the original amdgpu allocated pasid
- * Will be replaced with kfd allocated pasid
- */
-    amdgpu_pasid_free(vm->pasid);
-    vm->pasid = 0;
-    }
-
  /* Free the shadow bo for compute VM */
amdgpu_bo_unref(_amdgpu_bo_vm(vm->root.bo)->shadow);
  -    if (pasid)
-    vm->pasid = pasid;
-
  goto unreserve_bo;
  -free_idr:
-    if (pasid) {
-    unsigned long flags;
-
-    spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-    idr_remove(>vm_manager.pasid_idr, pasid);
- spin_unlock_irqrestore(>vm_manager.pasid_lock, 

Re: [PATCH 1/2] drm/amdgpu: use xarray for storing pasid in vm

2021-06-29 Thread Christian König




Am 29.06.21 um 09:49 schrieb Nirmoy Das:

Replace idr with xarray as we actually need hash functionality.
Cleanup code related to vm pasid by adding helper function.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 136 ++---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   6 +-
  2 files changed, 60 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 63975bda8e76..9b0e8a9d7f86 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -87,6 +87,33 @@ struct amdgpu_prt_cb {
struct dma_fence_cb cb;
  };
  
+int amdgpu_vm_set_pasid(struct amdgpu_device *adev, struct amdgpu_vm *vm,

+   unsigned long pasid)


Proper kerneldoc please when the function is now exported.


+{
+   unsigned long flags;
+   int r;
+
+   if (vm->pasid == pasid)
+   return 0;
+
+   if (vm->pasid) {
+   r = xa_err(xa_erase_irq(>vm_manager.pasids, vm->pasid));
+   if (r < 0)
+   return r;


I think we should have a "vm->pasid = 0;" here so that we have a 
consistent state when inserting the new pasid below failed.




+   }
+
+   if (pasid) {
+   r = xa_err(xa_store_irq(>vm_manager.pasids, pasid, vm,
+   GFP_KERNEL));
+   if (r < 0)
+   return r;
+   }
+
+   vm->pasid = pasid;


This assignment can then be moved into the "if" as well.

Apart from that looks like a really nice cleanup to me.

Regards,
Christian.


+
+   return 0;
+}
+
  /*
   * vm eviction_lock can be taken in MMU notifiers. Make sure no reclaim-FS
   * happens while holding this lock anywhere to prevent deadlocks when
@@ -2940,18 +2967,9 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm, u32 pasid)
  
  	amdgpu_bo_unreserve(vm->root.bo);
  
-	if (pasid) {

-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-   if (r < 0)
-   goto error_free_root;
-
-   vm->pasid = pasid;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto error_free_root;
  
  	INIT_KFIFO(vm->faults);
  
@@ -3039,18 +3057,15 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, struct amdgpu_vm *vm,

if (r)
goto unreserve_bo;
  
-	if (pasid) {

-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (vm->pasid)
+   amdgpu_pasid_free(vm->pasid);
  
-		if (r == -ENOSPC)

-   goto unreserve_bo;
-   r = 0;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto unreserve_bo;
  
  	/* Check if PD needs to be reinitialized and do it before

 * changing any other state, in case it fails.
@@ -3061,7 +3076,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
   to_amdgpu_bo_vm(vm->root.bo),
   false);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
}
  
  	/* Update VM state */

@@ -3078,7 +3093,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
r = amdgpu_bo_sync_wait(vm->root.bo,
AMDGPU_FENCE_OWNER_UNDEFINED, true);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
  
  		vm->update_funcs = _vm_cpu_funcs;

} else {
@@ -3088,36 +3103,13 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
vm->last_update = NULL;
vm->is_compute_context = true;
  
-	if (vm->pasid) {

-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   idr_remove(>vm_manager.pasid_idr, vm->pasid);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-
-   /* Free the original amdgpu allocated pasid
-* Will be replaced with kfd allocated pasid
-*/
-   amdgpu_pasid_free(vm->pasid);
-   vm->pasid = 0;
-   }
-
/* Free the shadow bo for 

Re: [PATCH v2 1/2] drm/amdgpu: return early for non-TTM_PL_TT type BOs

2021-06-29 Thread Das, Nirmoy


On 6/29/2021 1:05 PM, Christian König wrote:

Am 29.06.21 um 09:36 schrieb Nirmoy Das:

Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.

v2: merge if-conditions

Signed-off-by: Nirmoy Das 



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

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

index b46726e47bce..208bc3ec1aff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -926,7 +926,8 @@ static int amdgpu_ttm_backend_bind(struct 
ttm_device *bdev,

  bo_mem->mem_type == AMDGPU_PL_OA)
  return -EINVAL;

-    if (!amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
+    if ((bo_mem->mem_type != TTM_PL_TT) ||


Please drop the extra (), apart from that the patch is Reviewed-by: 
Christian König 



Thanks, I will send a next revision.


Nirmoy





+ !amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
  gtt->offset = AMDGPU_BO_INVALID_OFFSET;
  return 0;
  }
--
2.32.0




___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 2/2] drm/amdgpu: raise error on incorrect mem_type

2021-06-29 Thread Christian König




Am 29.06.21 um 09:36 schrieb Nirmoy Das:

Be more defensive and raise error on wrong mem_type
argument in amdgpu_gtt_mgr_has_gart_addr().

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 543000304a1c..0b0fa87b115c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -107,8 +107,12 @@ const struct attribute_group amdgpu_gtt_mgr_attr_group = {
   */
  bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_resource *res)
  {
-   struct amdgpu_gtt_node *node = to_amdgpu_gtt_node(res);
+   struct amdgpu_gtt_node *node;
+
+   if (WARN_ON(res->mem_type != TTM_PL_TT))
+   return false;


I'm not sure that is a good idea. The GTT manager itself shouldn't have 
to deal with incorrect usage of it's component.


Christian.

  
+	node = to_amdgpu_gtt_node(res);

return drm_mm_node_allocated(>base.mm_nodes[0]);
  }
  


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v2 1/2] drm/amdgpu: return early for non-TTM_PL_TT type BOs

2021-06-29 Thread Christian König

Am 29.06.21 um 09:36 schrieb Nirmoy Das:

Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.

v2: merge if-conditions

Signed-off-by: Nirmoy Das 



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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b46726e47bce..208bc3ec1aff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -926,7 +926,8 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
bo_mem->mem_type == AMDGPU_PL_OA)
return -EINVAL;

-   if (!amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
+   if ((bo_mem->mem_type != TTM_PL_TT) ||


Please drop the extra (), apart from that the patch is Reviewed-by: 
Christian König 



+   !amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
gtt->offset = AMDGPU_BO_INVALID_OFFSET;
return 0;
}
--
2.32.0



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 1/1] drm/amdgpu: Read clock counter via MMIO to reduce delay

2021-06-29 Thread Liu, Monk
[AMD Official Use Only]

Please do not use "//" in linux kernel patch , use "/*   */" instead

After this part fixed the patch is : Reviewed-by: Monk Liu 

Thanks 

--
Monk Liu | Cloud-GPU Core team
--

-Original Message-
From: YuBiao Wang  
Sent: Tuesday, June 29, 2021 6:01 PM
To: amd-gfx@lists.freedesktop.org
Cc: Grodzovsky, Andrey ; Quan, Evan 
; Chen, Horace ; Tuikov, Luben 
; Koenig, Christian ; Deucher, 
Alexander ; Xiao, Jack ; Zhang, 
Hawking ; Liu, Monk ; Xu, Feifei 
; Wang, Kevin(Yang) ; Wang, YuBiao 

Subject: [PATCH 1/1] drm/amdgpu: Read clock counter via MMIO to reduce delay

[Why]
GPU timing counters are read via KIQ under sriov, which will introduce a delay.

[How]
It could be directly read by MMIO.

v2: Add additional check to prevent carryover issue.
v3: Only check for carryover for once to prevent performance issue.

Signed-off-by: YuBiao Wang 
Acked-by: Horace Chen 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index ff7e9f49040e..82a5b7ab8dc5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -7610,6 +7610,7 @@ static int gfx_v10_0_soft_reset(void *handle)  static 
uint64_t gfx_v10_0_get_gpu_clock_counter(struct amdgpu_device *adev)  {
uint64_t clock;
+   uint64_t clock_lo, clock_hi, hi_check;
 
amdgpu_gfx_off_ctrl(adev, false);
mutex_lock(>gfx.gpu_clock_mutex);
@@ -7620,8 +7621,15 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)
((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Vangogh) << 32ULL);
break;
default:
-   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
-   ((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER) << 32ULL);
+   clock_hi = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   // If carryover happens, update lower count again.
+   if (hi_check != clock_hi) {
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   clock_hi = hi_check;
+   }
+   clock = (uint64_t)clock_lo | ((uint64_t)clock_hi << 32ULL);
break;
}
mutex_unlock(>gfx.gpu_clock_mutex);
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH v3] drm/amdgpu: Restore msix after FLR

2021-06-29 Thread Zhou, Peng Ju
[AMD Official Use Only]

Ping


-- 
BW
Pengju Zhou



> -Original Message-
> From: Peng Ju Zhou 
> Sent: Friday, June 25, 2021 2:44 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deng, Emily ; Zhou, Peng Ju
> 
> Subject: [PATCH v3] drm/amdgpu: Restore msix after FLR
> 
> From: "Emily.Deng" 
> 
> After FLR, the msix will be cleared, so need to re-enable it.
> 
> Signed-off-by: Emily.Deng 
> Signed-off-by: Peng Ju Zhou 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> index 90f50561b43a..26e63cb5d8d5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> @@ -277,6 +277,16 @@ static bool amdgpu_msi_ok(struct amdgpu_device
> *adev)
>   return true;
>  }
> 
> +void amdgpu_restore_msix(struct amdgpu_device *adev) {
> + u16 ctrl;
> +
> + pci_read_config_word(adev->pdev, adev->pdev->msix_cap +
> PCI_MSIX_FLAGS, );
> + ctrl &= ~PCI_MSIX_FLAGS_ENABLE;
> + pci_write_config_word(adev->pdev, adev->pdev->msix_cap +
> PCI_MSIX_FLAGS, ctrl);
> + ctrl |= PCI_MSIX_FLAGS_ENABLE;
> + pci_write_config_word(adev->pdev, adev->pdev->msix_cap +
> +PCI_MSIX_FLAGS, ctrl); }
>  /**
>   * amdgpu_irq_init - initialize interrupt handling
>   *
> @@ -558,6 +568,7 @@ void amdgpu_irq_gpu_reset_resume_helper(struct
> amdgpu_device *adev)  {
>   int i, j, k;
> 
> + amdgpu_restore_msix(adev);
>   for (i = 0; i < AMDGPU_IRQ_CLIENTID_MAX; ++i) {
>   if (!adev->irq.client[i].sources)
>   continue;
> --
> 2.17.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amd/display: Remove assignments in if clauses.

2021-06-29 Thread Alex Deucher
Applied.  Thanks!

Alex

On Fri, Jun 25, 2021 at 3:28 AM Mark Yacoub  wrote:
>
> Fixes Commit a46b6bd5 (drm/amd/display: Verify Gamma & Degamma LUT sizes
> in amdgpu_dm_atomic_check)
>
> Tested on Zork: IGT:kms_color
>
> Signed-off-by: Mark Yacoub 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c   | 3 ++-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c | 3 ++-
>  2 files changed, 4 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 91e13ae388b7f..c0cc4ca5fdf60 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -7792,7 +7792,8 @@ static int amdgpu_dm_atomic_check(struct drm_device 
> *dev,
> old_crtc_state->vrr_enabled == 
> new_crtc_state->vrr_enabled)
> continue;
>
> -   if ((ret = amdgpu_dm_verify_lut_sizes(new_crtc_state)))
> +   ret = amdgpu_dm_verify_lut_sizes(new_crtc_state);
> +   if (ret)
> goto fail;
>
> if (!new_crtc_state->enable)
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> index 9543b10e7e0bf..6acc460a3e982 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
> @@ -342,7 +342,8 @@ int amdgpu_dm_update_crtc_color_mgmt(struct dm_crtc_state 
> *crtc)
> bool is_legacy;
> int r;
>
> -   if ((r = amdgpu_dm_verify_lut_sizes(>base)))
> +   r = amdgpu_dm_verify_lut_sizes(>base);
> +   if (r)
> return r;
>
> degamma_lut = __extract_blob_lut(crtc->base.degamma_lut, 
> _size);
> --
> 2.32.0.93.g670b81a890-goog
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v3] drm/amdgpu: Restore msix after FLR

2021-06-29 Thread Alex Deucher
On Fri, Jun 25, 2021 at 2:44 AM Peng Ju Zhou  wrote:
>
> From: "Emily.Deng" 
>
> After FLR, the msix will be cleared, so need to re-enable it.

Do we need to store whether we enabled msix in the first place and
then decide whether to enable it again in this case?

Alex

>
> Signed-off-by: Emily.Deng 
> Signed-off-by: Peng Ju Zhou 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> index 90f50561b43a..26e63cb5d8d5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c
> @@ -277,6 +277,16 @@ static bool amdgpu_msi_ok(struct amdgpu_device *adev)
> return true;
>  }
>
> +void amdgpu_restore_msix(struct amdgpu_device *adev)
> +{
> +   u16 ctrl;
> +
> +   pci_read_config_word(adev->pdev, adev->pdev->msix_cap + 
> PCI_MSIX_FLAGS, );
> +   ctrl &= ~PCI_MSIX_FLAGS_ENABLE;
> +   pci_write_config_word(adev->pdev, adev->pdev->msix_cap + 
> PCI_MSIX_FLAGS, ctrl);
> +   ctrl |= PCI_MSIX_FLAGS_ENABLE;
> +   pci_write_config_word(adev->pdev, adev->pdev->msix_cap + 
> PCI_MSIX_FLAGS, ctrl);
> +}
>  /**
>   * amdgpu_irq_init - initialize interrupt handling
>   *
> @@ -558,6 +568,7 @@ void amdgpu_irq_gpu_reset_resume_helper(struct 
> amdgpu_device *adev)
>  {
> int i, j, k;
>
> +   amdgpu_restore_msix(adev);
> for (i = 0; i < AMDGPU_IRQ_CLIENTID_MAX; ++i) {
> if (!adev->irq.client[i].sources)
> continue;
> --
> 2.17.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH -next] drm/radeon: Add the missed drm_gem_object_put() in radeon_user_framebuffer_create()

2021-06-29 Thread Alex Deucher
Applied.  Thanks!

Alex

On Tue, Jun 29, 2021 at 7:42 AM Christian König
 wrote:
>
> Am 29.06.21 um 13:44 schrieb Jing Xiangfeng:
> > radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
> > an error path. Add the missed function call to fix it.
> >
> > Signed-off-by: Jing Xiangfeng 
>
> I'm pretty sure that I already reviewed the same patch a few weeks ago,
> but it looks like it never went upstream.
>
> Reviewed-by: Christian König 
>
> Maybe add CC: stable as well?
>
> Regards,
> Christian.
>
> > ---
> >   drivers/gpu/drm/radeon/radeon_display.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
> > b/drivers/gpu/drm/radeon/radeon_display.c
> > index 652af7a134bd..1d03ec763604 100644
> > --- a/drivers/gpu/drm/radeon/radeon_display.c
> > +++ b/drivers/gpu/drm/radeon/radeon_display.c
> > @@ -1325,6 +1325,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
> >   /* Handle is imported dma-buf, so cannot be migrated to VRAM for 
> > scanout */
> >   if (obj->import_attach) {
> >   DRM_DEBUG_KMS("Cannot create framebuffer from imported 
> > dma_buf\n");
> > + drm_gem_object_put(obj);
> >   return ERR_PTR(-EINVAL);
> >   }
> >
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 1/1] drm/amdgpu: Read clock counter via MMIO to reduce delay

2021-06-29 Thread Chen, Horace
[AMD Official Use Only]

Acked-by: Horace Chen 

-Original Message-
From: YuBiao Wang  
Sent: Tuesday, June 29, 2021 6:01 PM
To: amd-gfx@lists.freedesktop.org
Cc: Grodzovsky, Andrey ; Quan, Evan 
; Chen, Horace ; Tuikov, Luben 
; Koenig, Christian ; Deucher, 
Alexander ; Xiao, Jack ; Zhang, 
Hawking ; Liu, Monk ; Xu, Feifei 
; Wang, Kevin(Yang) ; Wang, YuBiao 

Subject: [PATCH 1/1] drm/amdgpu: Read clock counter via MMIO to reduce delay

[Why]
GPU timing counters are read via KIQ under sriov, which will introduce a delay.

[How]
It could be directly read by MMIO.

v2: Add additional check to prevent carryover issue.
v3: Only check for carryover for once to prevent performance issue.

Signed-off-by: YuBiao Wang 
Acked-by: Horace Chen 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index ff7e9f49040e..82a5b7ab8dc5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -7610,6 +7610,7 @@ static int gfx_v10_0_soft_reset(void *handle)  static 
uint64_t gfx_v10_0_get_gpu_clock_counter(struct amdgpu_device *adev)  {
uint64_t clock;
+   uint64_t clock_lo, clock_hi, hi_check;
 
amdgpu_gfx_off_ctrl(adev, false);
mutex_lock(>gfx.gpu_clock_mutex);
@@ -7620,8 +7621,15 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)
((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Vangogh) << 32ULL);
break;
default:
-   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
-   ((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER) << 32ULL);
+   clock_hi = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   // If carryover happens, update lower count again.
+   if (hi_check != clock_hi) {
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   clock_hi = hi_check;
+   }
+   clock = (uint64_t)clock_lo | ((uint64_t)clock_hi << 32ULL);
break;
}
mutex_unlock(>gfx.gpu_clock_mutex);
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: rectify line endings in umc v8_7_0 IP headers

2021-06-29 Thread Alex Deucher
Applied.  Thanks.

Alex

On Mon, Jun 28, 2021 at 6:53 AM Lukas Bulwahn  wrote:
>
> Commit 6b36fa6143f6 ("drm/amdgpu: add umc v8_7_0 IP headers") adds the new
> file ./drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h with
> DOS line endings, which is very uncommon for the kernel repository.
>
> Rectify the line endings in this file with dos2unix.
>
> Identified by a checkpatch evaluation on the whole kernel repository and
> spot-checking for really unexpected checkpatch rule violations.
>
> Reported-by: Dwaipayan Ray 
> Signed-off-by: Lukas Bulwahn 
> ---
>  .../include/asic_reg/umc/umc_8_7_0_sh_mask.h  | 158 +-
>  1 file changed, 79 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h 
> b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
> index 4c5097fa0c09..d5ef91d3c391 100644
> --- a/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
> +++ b/drivers/gpu/drm/amd/include/asic_reg/umc/umc_8_7_0_sh_mask.h
> @@ -1,79 +1,79 @@
> -#ifndef _umc_8_7_0_SH_MASK_HEADER
> -#define _umc_8_7_0_SH_MASK_HEADER
> -
> -//UMCCH0_0_GeccErrCntSel
> -#define UMCCH0_0_GeccErrCntSel__GeccErrCntCsSel__SHIFT   
>  0x0
> -#define UMCCH0_0_GeccErrCntSel__GeccErrInt__SHIFT
>  0xc
> -#define UMCCH0_0_GeccErrCntSel__GeccErrCntEn__SHIFT  
>  0xf
> -#define UMCCH0_0_GeccErrCntSel__PoisonCntEn__SHIFT   
>  0x10
> -#define UMCCH0_0_GeccErrCntSel__GeccErrCntCsSel_MASK 
>  0x000FL
> -#define UMCCH0_0_GeccErrCntSel__GeccErrInt_MASK  
>  0x3000L
> -#define UMCCH0_0_GeccErrCntSel__GeccErrCntEn_MASK
>  0x8000L
> -#define UMCCH0_0_GeccErrCntSel__PoisonCntEn_MASK 
>  0x0003L
> -//UMCCH0_0_GeccErrCnt
> -#define UMCCH0_0_GeccErrCnt__GeccErrCnt__SHIFT   
>  0x0
> -#define UMCCH0_0_GeccErrCnt__GeccUnCorrErrCnt__SHIFT 
>  0x10
> -#define UMCCH0_0_GeccErrCnt__GeccErrCnt_MASK 
>  0xL
> -#define UMCCH0_0_GeccErrCnt__GeccUnCorrErrCnt_MASK   
>  0xL
> -//MCA_UMC_UMC0_MCUMC_STATUST0
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__ErrorCode__SHIFT
>  0x0
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__ErrorCodeExt__SHIFT 
>  0x10
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__RESERV22__SHIFT 
>  0x16
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__AddrLsb__SHIFT  
>  0x18
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__RESERV30__SHIFT 
>  0x1e
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__ErrCoreId__SHIFT
>  0x20
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__RESERV38__SHIFT 
>  0x26
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__Scrub__SHIFT
>  0x28
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__RESERV41__SHIFT 
>  0x29
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__Poison__SHIFT   
>  0x2b
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__Deferred__SHIFT 
>  0x2c
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__UECC__SHIFT 
>  0x2d
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__CECC__SHIFT 
>  0x2e
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__RESERV47__SHIFT 
>  0x2f
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__Transparent__SHIFT  
>  0x34
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__SyndV__SHIFT
>  0x35
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__RESERV54__SHIFT 
>  0x36
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__TCC__SHIFT  
>  0x37
> -#define MCA_UMC_UMC0_MCUMC_STATUST0__ErrCoreIdVal__SHIFT 
>  0x38
> 

[PATCH 1/1] drm/amdgpu: Read clock counter via MMIO to reduce delay

2021-06-29 Thread YuBiao Wang
[Why]
GPU timing counters are read via KIQ under sriov, which will introduce
a delay.

[How]
It could be directly read by MMIO.

v2: Add additional check to prevent carryover issue.
v3: Only check for carryover for once to prevent performance issue.

Signed-off-by: YuBiao Wang 
Acked-by: Horace Chen 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index ff7e9f49040e..82a5b7ab8dc5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -7610,6 +7610,7 @@ static int gfx_v10_0_soft_reset(void *handle)
 static uint64_t gfx_v10_0_get_gpu_clock_counter(struct amdgpu_device *adev)
 {
uint64_t clock;
+   uint64_t clock_lo, clock_hi, hi_check;
 
amdgpu_gfx_off_ctrl(adev, false);
mutex_lock(>gfx.gpu_clock_mutex);
@@ -7620,8 +7621,15 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)
((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Vangogh) << 32ULL);
break;
default:
-   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
-   ((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER) << 32ULL);
+   clock_hi = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   // If carryover happens, update lower count again.
+   if (hi_check != clock_hi) {
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   clock_hi = hi_check;
+   }
+   clock = (uint64_t)clock_lo | ((uint64_t)clock_hi << 32ULL);
break;
}
mutex_unlock(>gfx.gpu_clock_mutex);
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/aperture: Pass DRM driver structure instead of driver name

2021-06-29 Thread Thomas Zimmermann
Print the name of the DRM driver when taking over fbdev devices. Makes
the output to dmesg more consistent. Note that the driver name is only
used for printing a string to the kernel log. No UAPI is affected by this
change.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |  2 +-
 drivers/gpu/drm/armada/armada_drv.c   |  2 +-
 drivers/gpu/drm/ast/ast_drv.c |  2 +-
 drivers/gpu/drm/bochs/bochs_drv.c |  2 +-
 drivers/gpu/drm/drm_aperture.c| 19 ---
 .../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c   |  2 +-
 drivers/gpu/drm/hyperv/hyperv_drm_drv.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.c   |  2 +-
 drivers/gpu/drm/meson/meson_drv.c |  2 +-
 drivers/gpu/drm/mgag200/mgag200_drv.c |  2 +-
 drivers/gpu/drm/msm/msm_fbdev.c   |  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c |  2 +-
 drivers/gpu/drm/qxl/qxl_drv.c |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.c   |  2 +-
 drivers/gpu/drm/sun4i/sun4i_drv.c |  2 +-
 drivers/gpu/drm/tegra/drm.c   |  2 +-
 drivers/gpu/drm/tiny/cirrus.c |  2 +-
 drivers/gpu/drm/vboxvideo/vbox_drv.c  |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_drv.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |  2 +-
 include/drm/drm_aperture.h| 14 +-
 23 files changed, 43 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f30c525caac..accf9c1b967a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1278,7 +1278,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
 #endif
 
/* Get rid of things like offb */
-   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
"amdgpudrmfb");
+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_kms_driver);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/armada/armada_drv.c 
b/drivers/gpu/drm/armada/armada_drv.c
index dab0a1f0983b..31925ae3ab72 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -95,7 +95,7 @@ static int armada_drm_bind(struct device *dev)
}
 
/* Remove early framebuffers */
-   ret = drm_aperture_remove_framebuffers(false, "armada-drm-fb");
+   ret = drm_aperture_remove_framebuffers(false, _drm_driver);
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5aa452b4efe6..86d5cd7b6318 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -100,7 +100,7 @@ static int ast_remove_conflicting_framebuffers(struct 
pci_dev *pdev)
primary = pdev->resource[PCI_ROM_RESOURCE].flags & 
IORESOURCE_ROM_SHADOW;
 #endif
 
-   return drm_aperture_remove_conflicting_framebuffers(base, size, 
primary, "astdrmfb");
+   return drm_aperture_remove_conflicting_framebuffers(base, size, 
primary, _driver);
 }
 
 static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c 
b/drivers/gpu/drm/bochs/bochs_drv.c
index c828cadbabff..0d232b44ecd7 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -110,7 +110,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
 
-   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
"bochsdrmfb");
+   ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, 
_driver);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 9335d9d6cf9a..9ac39cf11694 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -33,6 +33,10 @@
  *
  * .. code-block:: c
  *
+ * static const struct drm_driver example_driver = {
+ * ...
+ * };
+ *
  * static int remove_conflicting_framebuffers(struct pci_dev *pdev)
  * {
  * bool primary = false;
@@ -46,7 +50,7 @@
  * #endif
  *
  * return drm_aperture_remove_conflicting_framebuffers(base, size, 
primary,
- * "example 
driver");
+ * 
_driver);
  * }
  *
  * static int probe(struct pci_dev *pdev)
@@ -274,7 +278,7 @@ static void drm_aperture_detach_drivers(resource_size_t 
base, resource_size_t si
  * @base: the aperture's base address in physical memory
  * @size: aperture size in bytes
  * @primary: also kick vga16fb 

[PATCH 1/1] drm/amdgpu: Read clock counter via MMIO to reduce delay

2021-06-29 Thread YuBiao Wang
[Why]
GPU timing counters are read via KIQ under sriov, which will introduce
a delay.

[How]
It could be directly read by MMIO.

v2: Add additional check to prevent carryover issue.

Signed-off-by: YuBiao Wang 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index ff7e9f49040e..191b9e3ee3ea 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -7610,6 +7610,7 @@ static int gfx_v10_0_soft_reset(void *handle)
 static uint64_t gfx_v10_0_get_gpu_clock_counter(struct amdgpu_device *adev)
 {
uint64_t clock;
+   uint64_t clock_lo, clock_hi, hi_check;
 
amdgpu_gfx_off_ctrl(adev, false);
mutex_lock(>gfx.gpu_clock_mutex);
@@ -7620,8 +7621,16 @@ static uint64_t gfx_v10_0_get_gpu_clock_counter(struct 
amdgpu_device *adev)
((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER_Vangogh) << 32ULL);
break;
default:
-   clock = (uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER) |
-   ((uint64_t)RREG32_SOC15(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER) << 32ULL);
+   clock_hi = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   // If carry happens, continuously read until no carry happens
+   while (hi_check != clock_hi) {
+   clock_lo = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_LOWER);
+   clock_hi = hi_check;
+   hi_check = RREG32_SOC15_NO_KIQ(SMUIO, 0, 
mmGOLDEN_TSC_COUNT_UPPER);
+   }
+   clock = (uint64_t)clock_lo | ((uint64_t)clock_hi << 32ULL);
break;
}
mutex_unlock(>gfx.gpu_clock_mutex);
-- 
2.25.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amdgpu: Set ttm caching flags during bo allocation

2021-06-29 Thread Xu, Feifei
[AMD Official Use Only]

Reviewed-by: Feifei Xu 

-Original Message-
From: amd-gfx  On Behalf Of Oak Zeng
Sent: Tuesday, June 29, 2021 7:16 AM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Zhu, James ; 
Koenig, Christian ; Zeng, Oak 
Subject: [PATCH] drm/amdgpu: Set ttm caching flags during bo allocation

The ttm caching flags (ttm_cached, ttm_write_combined etc) are used to 
determine a buffer object's mapping attributes in both CPU page table and GPU 
page table (when that buffer is also accessed by GPU). Currently the ttm 
caching flags are set in function amdgpu_ttm_io_mem_reserve which is called 
during DRM_AMDGPU_GEM_MMAP ioctl. This has a problem since the GPU mapping of 
the buffer object (ioctl DRM_AMDGPU_GEM_VA) can happen earlier than the mmap 
time, thus the GPU page table update code can't pick up the right ttm caching 
flags to decide the right GPU page table attributes.

This patch moves the ttm caching flags setting to function amdgpu_vram_mgr_new 
- this function is called during the first step of a buffer object create (eg, 
DRM_AMDGPU_GEM_CREATE) so the later both CPU and GPU mapping function calls 
will pick up this flag for CPU/GPU page table set up.

Signed-off-by: Oak Zeng 
Suggested-by: Christian Koenig 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 4 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 +
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6297363..93acf6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -607,10 +607,6 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_device 
*bdev,

mem->bus.offset += adev->gmc.aper_base;
mem->bus.is_iomem = true;
-   if (adev->gmc.xgmi.connected_to_cpu)
-   mem->bus.caching = ttm_cached;
-   else
-   mem->bus.caching = ttm_write_combined;
break;
default:
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index a52e17e..6cb66eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -454,6 +454,11 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager 
*man,
if (i == 1)
mem->placement |= TTM_PL_FLAG_CONTIGUOUS;

+   if (adev->gmc.xgmi.connected_to_cpu)
+   mem->bus.caching = ttm_cached;
+   else
+   mem->bus.caching = ttm_write_combined;
+
atomic64_add(vis_usage, >vis_usage);
mem->mm_node = nodes;
return 0;
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7CFeifei.Xu%40amd.com%7Caef2cb54c9a4489626e808d93a8aab8c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637605189533617890%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Pzl%2FSSuBHjSUjBFQVffr3UneV8hzrVb2cmN8cSnifaA%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 2/2] drm/amd/pm: bump DRIVER_IF_VERSION for Sienna Cichlid

2021-06-29 Thread Chen, Guchun
[Public]

Acked-by: Guchun Chen 

Regards,
Guchun

-Original Message-
From: amd-gfx  On Behalf Of Quan, Evan
Sent: Tuesday, June 29, 2021 3:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander 
Subject: RE: [PATCH 2/2] drm/amd/pm: bump DRIVER_IF_VERSION for Sienna Cichlid

[AMD Official Use Only]

Ping..

> -Original Message-
> From: Quan, Evan 
> Sent: Friday, June 25, 2021 4:13 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan 
> 
> Subject: [PATCH 2/2] drm/amd/pm: bump DRIVER_IF_VERSION for Sienna 
> Cichlid
> 
> To suppress the annoying warning about version mismatch.
> 
> Change-Id: I7dae1ef90ea3b09e1b378f96136b6ae61cc90696
> Signed-off-by: Evan Quan 
> ---
>  drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h | 2 +-
>  drivers/gpu/drm/amd/pm/inc/smu_v11_0.h  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git 
> a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> index 0b916a1933df..63b8701fd466 100644
> --- a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> +++ b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> @@ -131,7 +131,7 @@
>  #define FEATURE_GFX_EDC_BIT 49
>  #define FEATURE_GFX_PER_PART_VMIN_BIT   50
>  #define FEATURE_SMART_SHIFT_BIT 51
> -#define FEATURE_SPARE_52_BIT52
> +#define FEATURE_APT_BIT 52
>  #define FEATURE_SPARE_53_BIT53
>  #define FEATURE_SPARE_54_BIT54
>  #define FEATURE_SPARE_55_BIT55
> diff --git a/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> b/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> index 1962a5877191..b89e7dca8906 100644
> --- a/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> +++ b/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> @@ -30,7 +30,7 @@
>  #define SMU11_DRIVER_IF_VERSION_NV10 0x37  #define
> SMU11_DRIVER_IF_VERSION_NV12 0x38  #define
> SMU11_DRIVER_IF_VERSION_NV14 0x38 -#define 
> SMU11_DRIVER_IF_VERSION_Sienna_Cichlid 0x3D
> +#define SMU11_DRIVER_IF_VERSION_Sienna_Cichlid 0x40
>  #define SMU11_DRIVER_IF_VERSION_Navy_Flounder 0xE  #define 
> SMU11_DRIVER_IF_VERSION_VANGOGH 0x03  #define 
> SMU11_DRIVER_IF_VERSION_Dimgrey_Cavefish 0xF
> --
> 2.29.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfxdata=04%7C01%7Cguchun.chen%40amd.com%7C33f80d6d546b4906776508d93ad1b51f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637605494641978023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=0tpSQem2mcNJc9yJc772R5AVlXRvD9qUKribzqIyqbc%3Dreserved=0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH -next] drm/radeon: Add the missed drm_gem_object_put() in radeon_user_framebuffer_create()

2021-06-29 Thread Jing Xiangfeng
radeon_user_framebuffer_create() misses to call drm_gem_object_put() in
an error path. Add the missed function call to fix it.

Signed-off-by: Jing Xiangfeng 
---
 drivers/gpu/drm/radeon/radeon_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/radeon/radeon_display.c 
b/drivers/gpu/drm/radeon/radeon_display.c
index 652af7a134bd..1d03ec763604 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -1325,6 +1325,7 @@ radeon_user_framebuffer_create(struct drm_device *dev,
/* Handle is imported dma-buf, so cannot be migrated to VRAM for 
scanout */
if (obj->import_attach) {
DRM_DEBUG_KMS("Cannot create framebuffer from imported 
dma_buf\n");
+   drm_gem_object_put(obj);
return ERR_PTR(-EINVAL);
}
 
-- 
2.26.0.106.g9fadedd

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH v2 2/2] drm/amdgpu: free pasid early before converting a vm

2021-06-29 Thread Nirmoy Das
VM code should not be responsible for freeing pasid as pasid
gets allocated outside of VM code, before initializing a vm.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 6 --
 2 files changed, 8 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 f96598279593..5a9006aabec7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1287,6 +1287,14 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct 
kgd_dev *kgd,
if (avm->process_info)
return -EINVAL;

+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (avm->pasid) {
+   amdgpu_pasid_free(avm->pasid);
+   amdgpu_vm_set_pasid(adev, avm, 0);
+   }
+
/* Convert VM into a compute VM */
ret = amdgpu_vm_make_compute(adev, avm, pasid);
if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9b0e8a9d7f86..0bd9575b0872 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3057,12 +3057,6 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
if (r)
goto unreserve_bo;

-   /* Free the original amdgpu allocated pasid,
-* will be replaced with kfd allocated pasid.
-*/
-   if (vm->pasid)
-   amdgpu_pasid_free(vm->pasid);
-
r = amdgpu_vm_set_pasid(adev, vm, pasid);
if (r)
goto unreserve_bo;
--
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 1/2] drm/amdgpu: use xarray for storing pasid in vm

2021-06-29 Thread Nirmoy Das
Replace idr with xarray as we actually need hash functionality.
Cleanup code related to vm pasid by adding helper function.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 136 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |   6 +-
 2 files changed, 60 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 63975bda8e76..9b0e8a9d7f86 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -87,6 +87,33 @@ struct amdgpu_prt_cb {
struct dma_fence_cb cb;
 };
 
+int amdgpu_vm_set_pasid(struct amdgpu_device *adev, struct amdgpu_vm *vm,
+   unsigned long pasid)
+{
+   unsigned long flags;
+   int r;
+
+   if (vm->pasid == pasid)
+   return 0;
+
+   if (vm->pasid) {
+   r = xa_err(xa_erase_irq(>vm_manager.pasids, vm->pasid));
+   if (r < 0)
+   return r;
+   }
+
+   if (pasid) {
+   r = xa_err(xa_store_irq(>vm_manager.pasids, pasid, vm,
+   GFP_KERNEL));
+   if (r < 0)
+   return r;
+   }
+
+   vm->pasid = pasid;
+
+   return 0;
+}
+
 /*
  * vm eviction_lock can be taken in MMU notifiers. Make sure no reclaim-FS
  * happens while holding this lock anywhere to prevent deadlocks when
@@ -2940,18 +2967,9 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm, u32 pasid)
 
amdgpu_bo_unreserve(vm->root.bo);
 
-   if (pasid) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-   if (r < 0)
-   goto error_free_root;
-
-   vm->pasid = pasid;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto error_free_root;
 
INIT_KFIFO(vm->faults);
 
@@ -3039,18 +3057,15 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
if (r)
goto unreserve_bo;
 
-   if (pasid) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   r = idr_alloc(>vm_manager.pasid_idr, vm, pasid, pasid + 1,
- GFP_ATOMIC);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (vm->pasid)
+   amdgpu_pasid_free(vm->pasid);
 
-   if (r == -ENOSPC)
-   goto unreserve_bo;
-   r = 0;
-   }
+   r = amdgpu_vm_set_pasid(adev, vm, pasid);
+   if (r)
+   goto unreserve_bo;
 
/* Check if PD needs to be reinitialized and do it before
 * changing any other state, in case it fails.
@@ -3061,7 +3076,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
   to_amdgpu_bo_vm(vm->root.bo),
   false);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
}
 
/* Update VM state */
@@ -3078,7 +3093,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
r = amdgpu_bo_sync_wait(vm->root.bo,
AMDGPU_FENCE_OWNER_UNDEFINED, true);
if (r)
-   goto free_idr;
+   goto free_pasid_entry;
 
vm->update_funcs = _vm_cpu_funcs;
} else {
@@ -3088,36 +3103,13 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
vm->last_update = NULL;
vm->is_compute_context = true;
 
-   if (vm->pasid) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   idr_remove(>vm_manager.pasid_idr, vm->pasid);
-   spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-
-   /* Free the original amdgpu allocated pasid
-* Will be replaced with kfd allocated pasid
-*/
-   amdgpu_pasid_free(vm->pasid);
-   vm->pasid = 0;
-   }
-
/* Free the shadow bo for compute VM */
amdgpu_bo_unref(_amdgpu_bo_vm(vm->root.bo)->shadow);
 
-   if (pasid)
-   vm->pasid = pasid;
-
goto unreserve_bo;
 
-free_idr:
-   if (pasid) {
-   unsigned long flags;
-
-   spin_lock_irqsave(>vm_manager.pasid_lock, flags);
-   

[PATCH 2/2] drm/amdgpu: free pasid early before converting a vm

2021-06-29 Thread Nirmoy Das
VM code should not be responsible for freeing pasid as pasid
gets allocated outside of VM code, before initializing a vm.

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index f96598279593..5a9006aabec7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1287,6 +1287,14 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct 
kgd_dev *kgd,
if (avm->process_info)
return -EINVAL;
 
+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (avm->pasid) {
+   amdgpu_pasid_free(avm->pasid);
+   amdgpu_vm_set_pasid(adev, avm, 0);
+   }
+
/* Convert VM into a compute VM */
ret = amdgpu_vm_make_compute(adev, avm, pasid);
if (ret)
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/2] drm/amdgpu: free pasid early before converting a vm

2021-06-29 Thread Das, Nirmoy


On 6/23/2021 9:05 PM, Felix Kuehling wrote:

On 2021-06-23 8:25 a.m., Nirmoy Das wrote:

VM code should not be responsible for freeing pasid as pasid
gets allocated outside of VM code, before initializing a vm.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 5 -
  2 files changed, 6 insertions(+), 5 deletions(-)

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

index f96598279593..42e22b1fdfee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1287,6 +1287,12 @@ int 
amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,

  if (avm->process_info)
  return -EINVAL;
  +    /* Free the original amdgpu allocated pasid,
+ * will be replaced with kfd allocated pasid
+ */
+    if (avm->pasid)
+    amdgpu_pasid_free(avm->pasid);
+


If amdgpu_vm_make_compute fails, amdgpu_driver_postclose_kms will try 
to free the PASID a second time because vm->pasid still points to it. 
You could fix that by moving the amdgpu_pasid_free after a successful 
amdgpu_vm_make_compute call. But that still means you're making an 
assumption about the side effect of amdgpu_vm_make_compute on 
vm->pasid. IMHO, splitting the amdgpu_pasid_free and the vm->pasid = 0 
into two different functions is a mistake.



Makes sense, I think I can export amdgpu_vm_set_pasid() and then keep 
amdgpu_pasid_free and the vm->pasid = 0 together.



Regards,

Nirmoy



Regards,
  Felix



  /* Convert VM into a compute VM */
  ret = amdgpu_vm_make_compute(adev, avm, pasid);
  if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index 63975bda8e76..be841d62a1d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3094,11 +3094,6 @@ int amdgpu_vm_make_compute(struct 
amdgpu_device *adev, struct amdgpu_vm *vm,

  spin_lock_irqsave(>vm_manager.pasid_lock, flags);
  idr_remove(>vm_manager.pasid_idr, vm->pasid);
spin_unlock_irqrestore(>vm_manager.pasid_lock, flags);
-
-    /* Free the original amdgpu allocated pasid
- * Will be replaced with kfd allocated pasid
- */
-    amdgpu_pasid_free(vm->pasid);
  vm->pasid = 0;
  }

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH 1/2] drm/amd/pm: update the gpu metrics data retrieving for Sienna Cichlid

2021-06-29 Thread Quan, Evan
[AMD Official Use Only]

Ping..

> -Original Message-
> From: Quan, Evan 
> Sent: Friday, June 25, 2021 4:12 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> 
> Subject: [PATCH 1/2] drm/amd/pm: update the gpu metrics data retrieving
> for Sienna Cichlid
> 
> Due to the structure layout change: "uint32_t ThrottlerStatus" -> "
> uint8_t  ThrottlingPercentage[THROTTLER_COUNT]".
> 
> Change-Id: Id5c148b0584d972ae73fb9d7347a312944cec13d
> Signed-off-by: Evan Quan 
> ---
>  .../pm/inc/smu11_driver_if_sienna_cichlid.h   |  63 -
>  .../amd/pm/swsmu/smu11/sienna_cichlid_ppt.c   | 234 --
>  2 files changed, 222 insertions(+), 75 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> index 61c87c39be80..0b916a1933df 100644
> --- a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> +++ b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> @@ -211,6 +211,7 @@ typedef enum {
>  #define THROTTLER_FIT_BIT  17
>  #define THROTTLER_PPM_BIT  18
>  #define THROTTLER_APCC_BIT 19
> +#define THROTTLER_COUNT20
> 
>  // FW DState Features Control Bits
>  // FW DState Features Control Bits
> @@ -1406,7 +1407,67 @@ typedef struct {
>  } SmuMetrics_t;
> 
>  typedef struct {
> -  SmuMetrics_t SmuMetrics;
> +  uint32_t CurrClock[PPCLK_COUNT];
> +
> +  uint16_t AverageGfxclkFrequencyPreDs;  uint16_t
> + AverageGfxclkFrequencyPostDs;  uint16_t AverageFclkFrequencyPreDs;
> + uint16_t AverageFclkFrequencyPostDs;  uint16_t
> + AverageUclkFrequencyPreDs  ;  uint16_t AverageUclkFrequencyPostDs  ;
> +
> +
> +  uint16_t AverageGfxActivity;
> +  uint16_t AverageUclkActivity   ;
> +  uint8_t  CurrSocVoltageOffset  ;
> +  uint8_t  CurrGfxVoltageOffset  ;
> +  uint8_t  CurrMemVidOffset  ;
> +  uint8_t  Padding8;
> +  uint16_t AverageSocketPower;
> +  uint16_t TemperatureEdge   ;
> +  uint16_t TemperatureHotspot;
> +  uint16_t TemperatureMem;
> +  uint16_t TemperatureVrGfx  ;
> +  uint16_t TemperatureVrMem0 ;
> +  uint16_t TemperatureVrMem1 ;
> +  uint16_t TemperatureVrSoc  ;
> +  uint16_t TemperatureLiquid0;
> +  uint16_t TemperatureLiquid1;
> +  uint16_t TemperaturePlx;
> +  uint16_t Padding16 ;
> +  uint32_t AccCnt;
> +  uint8_t  ThrottlingPercentage[THROTTLER_COUNT];
> +
> +
> +  uint8_t  LinkDpmLevel;
> +  uint8_t  CurrFanPwm;
> +  uint16_t CurrFanSpeed;
> +
> +  //BACO metrics, PMFW-1721
> +  //metrics for D3hot entry/exit and driver ARM msgs  uint8_t
> + D3HotEntryCountPerMode[D3HOT_SEQUENCE_COUNT];
> +  uint8_t D3HotExitCountPerMode[D3HOT_SEQUENCE_COUNT];
> +  uint8_t ArmMsgReceivedCountPerMode[D3HOT_SEQUENCE_COUNT];
> +
> +  //PMFW-4362
> +  uint32_t EnergyAccumulator;
> +  uint16_t AverageVclk0Frequency  ;
> +  uint16_t AverageDclk0Frequency  ;
> +  uint16_t AverageVclk1Frequency  ;
> +  uint16_t AverageDclk1Frequency  ;
> +  uint16_t VcnActivityPercentage  ; //place holder, David N. to provide full
> sequence
> +  uint8_t  PcieRate   ;
> +  uint8_t  PcieWidth  ;
> +  uint16_t AverageGfxclkFrequencyTarget;  uint16_t Padding16_2;
> +
> +} SmuMetrics_V2_t;
> +
> +typedef struct {
> +  union {
> +SmuMetrics_t SmuMetrics;
> +SmuMetrics_V2_t SmuMetrics_V2;
> +  };
>uint32_t Spare[1];
> 
>// Padding - ignore
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> index 0c3407025eb2..f882c6756bf0 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/smu11/sienna_cichlid_ppt.c
> @@ -80,6 +80,13 @@
>   (*member) = (smu->smu_table.driver_pptable +
> offsetof(PPTable_t, field));\  } while(0)
> 
> +#define GET_METRICS_MEMBER(field, member) do { \
> + if ((smu->adev->asic_type == CHIP_SIENNA_CICHLID) && (smu-
> >smc_fw_version >= 0x3A4300)) \
> + (*member) = ((void *)(&(((SmuMetricsExternal_t *)(smu-
> >smu_table.metrics_table))->SmuMetrics_V2)) + offsetof(SmuMetrics_V2_t,
> field)); \
> + else \
> + (*member) = ((void *)(&(((SmuMetricsExternal_t
> +*)(smu->smu_table.metrics_table))->SmuMetrics)) +
> +offsetof(SmuMetrics_t, field)); \ } while(0)
> +
>  static int get_table_size(struct smu_context *smu)  {
>   if (smu->adev->asic_type == CHIP_BEIGE_GOBY) @@ -489,13
> +496,33 @@ static int sienna_cichlid_tables_init(struct smu_context *smu)
>   return -ENOMEM;
>  }
> 
> +static uint32_t sienna_cichlid_get_throttler_status_locked(struct
> +smu_context *smu) {
> + struct smu_table_context *smu_table= >smu_table;
> + SmuMetricsExternal_t *metrics_ext =
> + (SmuMetricsExternal_t *)(smu_table->metrics_table);
> + uint32_t throttler_status = 0;
> + int i;
> +
> + if ((smu->adev->asic_type == 

RE: [PATCH 2/2] drm/amd/pm: bump DRIVER_IF_VERSION for Sienna Cichlid

2021-06-29 Thread Quan, Evan
[AMD Official Use Only]

Ping..

> -Original Message-
> From: Quan, Evan 
> Sent: Friday, June 25, 2021 4:13 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Quan, Evan
> 
> Subject: [PATCH 2/2] drm/amd/pm: bump DRIVER_IF_VERSION for Sienna
> Cichlid
> 
> To suppress the annoying warning about version mismatch.
> 
> Change-Id: I7dae1ef90ea3b09e1b378f96136b6ae61cc90696
> Signed-off-by: Evan Quan 
> ---
>  drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h | 2 +-
>  drivers/gpu/drm/amd/pm/inc/smu_v11_0.h  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> index 0b916a1933df..63b8701fd466 100644
> --- a/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> +++ b/drivers/gpu/drm/amd/pm/inc/smu11_driver_if_sienna_cichlid.h
> @@ -131,7 +131,7 @@
>  #define FEATURE_GFX_EDC_BIT 49
>  #define FEATURE_GFX_PER_PART_VMIN_BIT   50
>  #define FEATURE_SMART_SHIFT_BIT 51
> -#define FEATURE_SPARE_52_BIT52
> +#define FEATURE_APT_BIT 52
>  #define FEATURE_SPARE_53_BIT53
>  #define FEATURE_SPARE_54_BIT54
>  #define FEATURE_SPARE_55_BIT55
> diff --git a/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> b/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> index 1962a5877191..b89e7dca8906 100644
> --- a/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> +++ b/drivers/gpu/drm/amd/pm/inc/smu_v11_0.h
> @@ -30,7 +30,7 @@
>  #define SMU11_DRIVER_IF_VERSION_NV10 0x37  #define
> SMU11_DRIVER_IF_VERSION_NV12 0x38  #define
> SMU11_DRIVER_IF_VERSION_NV14 0x38 -#define
> SMU11_DRIVER_IF_VERSION_Sienna_Cichlid 0x3D
> +#define SMU11_DRIVER_IF_VERSION_Sienna_Cichlid 0x40
>  #define SMU11_DRIVER_IF_VERSION_Navy_Flounder 0xE  #define
> SMU11_DRIVER_IF_VERSION_VANGOGH 0x03  #define
> SMU11_DRIVER_IF_VERSION_Dimgrey_Cavefish 0xF
> --
> 2.29.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-29 Thread Werner Sembach


Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 08:12:54 +
> Simon Ser  wrote:
>
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
>> wrote:
>>
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
>>> Using a pair of properties, preference and active, to ask for something
>>> and then check what actually worked is good for reducing the
>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>> test different KMS configurations. Userspace has a better chance of
>>> finding a configuration that is possible.
>>>
>>> OTOH, this has the problem than in UI one cannot tell the user in
>>> advance which options are truly possible. Given that KMS properties are
>>> rarely completely independent, and in this case known to depend on
>>> several other KMS properties, I think it is good enough to know after
>>> the fact.
>>>
>>> If a driver does not use what userspace prefers, there is no way to
>>> understand why, or what else to change to make it happen. That problem
>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>> but only a yes/no.  
>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>> property at a time), user-space can discover which property makes the atomic
>> commit fail.
> That works if the properties are independent of each other. Color
> range, color format, bpc and more may all be interconnected,
> allowing only certain combinations to work.
>
> If all these properties have "auto" setting too, then it would be
> possible to probe each property individually, but that still does not
> tell which combinations are valid.
>
> If you probe towards a certain configuration by setting the properties
> one by one, then depending on the order you pick the properties, you
> may come to a different conclusion on which property breaks the
> configuration.

My mind crossed another point that must be considered: When plugin in a Monitor 
a list of possible Resolutions+Framerate
combinations is created for xrandr and other userspace (I guess by atomic 
checks? but I don't know). During this drm
properties are already considered, which is no problem atm because as far as i 
can tell there is currently no drm
property that would make a certain Resolutions+Framerate combination 
unreachable that would be possible with everything
on default.

However for example forcing YCbCr420 encoding would limit the available 
resolutions (my screen for example only supports
YCbCr420 on 4k@60 and @50Hz and on no other resolution or frequency (native is 
2560x1440@144Hz).

So would a "force color format" that does not get resetted on 
repluging/reenabling a monitor break the output, for
example, of an not updated xrandr, unaware of this new property?

>> I'm not a fan of this "preference" property approach. The only way to find 
>> out
>> whether it's possible to change the color format is to perform a user-visible
>> change (with a regular atomic commit) and check whether it worked
>> after-the-fact. This is unlike all other existing KMS properties.
> I agree. FWIW, "max bpc" exists already.
>
>> I'd much rather see a more general approach to fix this combinatorial 
>> explosion
>> than to add special-cases like this.
> What would you suggest?
>
> Maybe all properties should have an "auto" value in addition to the
> explicit no-negotiation values where at all possible?
>
> That might help probing each property individually with TEST_ONLY
> commits, but it says nothing about combinations.
>
> A feedback list perhaps? TEST_ONLY commit somehow returning a list of
> property/value tuples indicating what value the "auto" valued
> properties actually get?
>
> What should a kernel driver optimize for when determining "auto" values?
>
>
> Thanks,
> pq
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-29 Thread Werner Sembach

Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue, 29 Jun 2021 08:12:54 +
> Simon Ser  wrote:
>
>> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
>> wrote:
>>
>>> yes, I think this makes sense, even if it is a property that one can't
>>> tell for sure what it does before hand.
>>>
>>> Using a pair of properties, preference and active, to ask for something
>>> and then check what actually worked is good for reducing the
>>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
>>> test different KMS configurations. Userspace has a better chance of
>>> finding a configuration that is possible.
>>>
>>> OTOH, this has the problem than in UI one cannot tell the user in
>>> advance which options are truly possible. Given that KMS properties are
>>> rarely completely independent, and in this case known to depend on
>>> several other KMS properties, I think it is good enough to know after
>>> the fact.
>>>
>>> If a driver does not use what userspace prefers, there is no way to
>>> understand why, or what else to change to make it happen. That problem
>>> exists anyway, because TEST_ONLY commits do not give useful feedback
>>> but only a yes/no.  
>> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
>> property at a time), user-space can discover which property makes the atomic
>> commit fail.
> That works if the properties are independent of each other. Color
> range, color format, bpc and more may all be interconnected,
> allowing only certain combinations to work.
>
> If all these properties have "auto" setting too, then it would be
> possible to probe each property individually, but that still does not
> tell which combinations are valid.
>
> If you probe towards a certain configuration by setting the properties
> one by one, then depending on the order you pick the properties, you
> may come to a different conclusion on which property breaks the
> configuration.

My mind crossed another point that must be considered: When plugin in a Monitor 
a list of possible Resolutions+Framerate
combinations is created for xrandr and other userspace (I guess by atomic 
checks? but I don't know). During this drm
properties are already considered, which is no problem atm because as far as i 
can tell there is currently no drm
property that would make a certain Resolutions+Framerate combination 
unreachable that would be possible with everything
on default.

However for example forcing YCbCr420 encoding would limit the available 
resolutions (my screen for example only supports
YCbCr420 on 4k@60 and @50Hz and on no other resolution or frequency (native is 
2560x1440@144Hz).

So would a "force color format" that does not get resetted on 
repluging/reenabling a monitor break the output, for
example, of an not updated xrandr, unaware of this new property?

>
>> I'm not a fan of this "preference" property approach. The only way to find 
>> out
>> whether it's possible to change the color format is to perform a user-visible
>> change (with a regular atomic commit) and check whether it worked
>> after-the-fact. This is unlike all other existing KMS properties.
> I agree. FWIW, "max bpc" exists already.
>
>> I'd much rather see a more general approach to fix this combinatorial 
>> explosion
>> than to add special-cases like this.
> What would you suggest?
>
> Maybe all properties should have an "auto" value in addition to the
> explicit no-negotiation values where at all possible?
>
> That might help probing each property individually with TEST_ONLY
> commits, but it says nothing about combinations.
>
> A feedback list perhaps? TEST_ONLY commit somehow returning a list of
> property/value tuples indicating what value the "auto" valued
> properties actually get?
>
> What should a kernel driver optimize for when determining "auto" values?
>
>
> Thanks,
> pq
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH v2 1/2] drm/amdgpu: return early for non-TTM_PL_TT type BOs

2021-06-29 Thread Nirmoy Das
Return early for non-TTM_PL_TT BOs so that we don't pass
wrong pointer to amdgpu_gtt_mgr_has_gart_addr() which assumes
ttm_resource argument to be TTM_PL_TT type BO's.

v2: merge if-conditions

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

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index b46726e47bce..208bc3ec1aff 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -926,7 +926,8 @@ static int amdgpu_ttm_backend_bind(struct ttm_device *bdev,
bo_mem->mem_type == AMDGPU_PL_OA)
return -EINVAL;

-   if (!amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
+   if ((bo_mem->mem_type != TTM_PL_TT) ||
+   !amdgpu_gtt_mgr_has_gart_addr(bo_mem)) {
gtt->offset = AMDGPU_BO_INVALID_OFFSET;
return 0;
}
--
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH 2/2] drm/amdgpu: raise error on incorrect mem_type

2021-06-29 Thread Nirmoy Das
Be more defensive and raise error on wrong mem_type
argument in amdgpu_gtt_mgr_has_gart_addr().

Signed-off-by: Nirmoy Das 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 543000304a1c..0b0fa87b115c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -107,8 +107,12 @@ const struct attribute_group amdgpu_gtt_mgr_attr_group = {
  */
 bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_resource *res)
 {
-   struct amdgpu_gtt_node *node = to_amdgpu_gtt_node(res);
+   struct amdgpu_gtt_node *node;
+
+   if (WARN_ON(res->mem_type != TTM_PL_TT))
+   return false;
 
+   node = to_amdgpu_gtt_node(res);
return drm_mm_node_allocated(>base.mm_nodes[0]);
 }
 
-- 
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-29 Thread Pekka Paalanen
On Tue, 29 Jun 2021 08:12:54 +
Simon Ser  wrote:

> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
> wrote:
> 
> > yes, I think this makes sense, even if it is a property that one can't
> > tell for sure what it does before hand.
> >
> > Using a pair of properties, preference and active, to ask for something
> > and then check what actually worked is good for reducing the
> > combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> > test different KMS configurations. Userspace has a better chance of
> > finding a configuration that is possible.
> >
> > OTOH, this has the problem than in UI one cannot tell the user in
> > advance which options are truly possible. Given that KMS properties are
> > rarely completely independent, and in this case known to depend on
> > several other KMS properties, I think it is good enough to know after
> > the fact.
> >
> > If a driver does not use what userspace prefers, there is no way to
> > understand why, or what else to change to make it happen. That problem
> > exists anyway, because TEST_ONLY commits do not give useful feedback
> > but only a yes/no.  
> 
> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
> property at a time), user-space can discover which property makes the atomic
> commit fail.

That works if the properties are independent of each other. Color
range, color format, bpc and more may all be interconnected,
allowing only certain combinations to work.

If all these properties have "auto" setting too, then it would be
possible to probe each property individually, but that still does not
tell which combinations are valid.

If you probe towards a certain configuration by setting the properties
one by one, then depending on the order you pick the properties, you
may come to a different conclusion on which property breaks the
configuration.

> I'm not a fan of this "preference" property approach. The only way to find out
> whether it's possible to change the color format is to perform a user-visible
> change (with a regular atomic commit) and check whether it worked
> after-the-fact. This is unlike all other existing KMS properties.

I agree. FWIW, "max bpc" exists already.

> I'd much rather see a more general approach to fix this combinatorial 
> explosion
> than to add special-cases like this.

What would you suggest?

Maybe all properties should have an "auto" value in addition to the
explicit no-negotiation values where at all possible?

That might help probing each property individually with TEST_ONLY
commits, but it says nothing about combinations.

A feedback list perhaps? TEST_ONLY commit somehow returning a list of
property/value tuples indicating what value the "auto" valued
properties actually get?

What should a kernel driver optimize for when determining "auto" values?


Thanks,
pq


pgp3xzdO2fQ5o.pgp
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v2 2/2] drm/amdgpu: free pasid early before converting a vm

2021-06-29 Thread Christian König

Am 29.06.21 um 09:55 schrieb Nirmoy Das:

VM code should not be responsible for freeing pasid as pasid
gets allocated outside of VM code, before initializing a vm.

Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c   | 6 --
  2 files changed, 8 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 f96598279593..5a9006aabec7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -1287,6 +1287,14 @@ int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct 
kgd_dev *kgd,
if (avm->process_info)
return -EINVAL;

+   /* Free the original amdgpu allocated pasid,
+* will be replaced with kfd allocated pasid.
+*/
+   if (avm->pasid) {
+   amdgpu_pasid_free(avm->pasid);
+   amdgpu_vm_set_pasid(adev, avm, 0);
+   }
+
/* Convert VM into a compute VM */
ret = amdgpu_vm_make_compute(adev, avm, pasid);


I'm really wondering if amdgpu_vm_make_compute() and amdgpu_vm_init() 
now need the pasid as parameter anymore.


Christian.


if (ret)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 9b0e8a9d7f86..0bd9575b0872 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3057,12 +3057,6 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm,
if (r)
goto unreserve_bo;

-   /* Free the original amdgpu allocated pasid,
-* will be replaced with kfd allocated pasid.
-*/
-   if (vm->pasid)
-   amdgpu_pasid_free(vm->pasid);
-
r = amdgpu_vm_set_pasid(adev, vm, pasid);
if (r)
goto unreserve_bo;
--
2.32.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

2021-06-29 Thread Werner Sembach
Am 28.06.21 um 19:03 schrieb Werner Sembach:
> Am 18.06.21 um 11:11 schrieb Werner Sembach:
>> Add a new general drm property "active bpc" which can be used by graphic
>> drivers to report the applied bit depth per pixel back to userspace.
>>
>> While "max bpc" can be used to change the color depth, there was no way to
>> check which one actually got used. While in theory the driver chooses the
>> best/highest color depth within the max bpc setting a user might not be
>> fully aware what his hardware is or isn't capable off. This is meant as a
>> quick way to double check the setup.
>>
>> In the future, automatic color calibration for screens might also depend on
>> this information being available.
>>
>> Signed-off-by: Werner Sembach 
>> ---
>>  drivers/gpu/drm/drm_connector.c | 51 +
>>  include/drm/drm_connector.h |  8 ++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c 
>> b/drivers/gpu/drm/drm_connector.c
>> index da39e7ff6965..943f6b61053b 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list 
>> dp_colorspaces[] = {
>>   *  drm_connector_attach_max_bpc_property() to create and attach the
>>   *  property to the connector during initialization.
>>   *
>> + * active bpc:
>> + *  This read-only range property tells userspace the pixel color bit depth
>> + *  actually used by the hardware display engine on "the cable" on a
>> + *  connector. The chosen value depends on hardware capabilities, both
>> + *  display engine and connected monitor, and the "max bpc" property.
>> + *  Drivers shall use drm_connector_attach_active_bpc_property() to install
>> + *  this property.
>> + *
> Regarding "on the cable" and dithering: As far as I can tell, what the 
> dithering option does, is setting a hardware
> register here:
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>
> So dithering seems to be calculated by fixed purpose hardware/firmware 
> outside of the driver?
>
> The Intel driver does not seem to set a target bpc/bpp for this hardware so I 
> guess it defaults to 6 or 8 bpc?

Never mind it does. This switch-case does affect the dithering output:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537

As found in this documentation p.548:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf

So max bpc and active bpc are affecting/affected by the bpc after dithering.

>
> Similar things happen on amd. Here the output dither depth seems to be 
> written to a fixed value however:
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828
>
> - 
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769
>
> Does anyone know about a resource where I can read up on the used registers 
> and what this hardware actually does?
Searching now for a similar register reference for AMD GPUs.
>
> My proposal for now: "max bpc" affects what happens before dither, so I would 
> keep "active bpc" the same and add another
> drm property "dither active: true/false". No additional property to control 
> dither, as amdgpu does have one already
> (which isn't always active?) and Intel driver does only seem prepared for 
> dithering at 6bpc (albeit I don't know why to
> dither at 6bpc and what depth to dither to?).
>
>>   * Connectors also have one standardized atomic property:
>>   *
>>   * CRTC_ID:
>> @@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct 
>> drm_connector *connector,
>>  }
>>  EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>>  
>> +/**
>> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
>> + * @connector: connector to attach active bpc property on.
>> + * @min: The minimum bit depth supported by the connector.
>> + * @max: The maximum bit depth supported by the connector.
>> + *
>> + * This is used to check the applied bit depth on a connector.
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_connector_attach_active_bpc_property(struct drm_connector 
>> *connector, int min, int max)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_property *prop;
>> +
>> +if (!connector->active_bpc_property) {
>> +prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE, 
>> "active bpc",
>> + min, max);
>> +if (!prop)
>> +return -ENOMEM;
>> +
>> +connector->active_bpc_property = prop;
>> +drm_object_attach_property(>base, prop, 0);
>> +}
>> +
>> + 

Re: [PATCH] drm/amdgpu: Set ttm caching flags during bo allocation

2021-06-29 Thread Christian König

Am 29.06.21 um 01:15 schrieb Oak Zeng:

The ttm caching flags (ttm_cached, ttm_write_combined etc) are
used to determine a buffer object's mapping attributes in both
CPU page table and GPU page table (when that buffer is also
accessed by GPU). Currently the ttm caching flags are set in
function amdgpu_ttm_io_mem_reserve which is called during
DRM_AMDGPU_GEM_MMAP ioctl. This has a problem since the GPU
mapping of the buffer object (ioctl DRM_AMDGPU_GEM_VA) can
happen earlier than the mmap time, thus the GPU page table
update code can't pick up the right ttm caching flags to
decide the right GPU page table attributes.

This patch moves the ttm caching flags setting to function
amdgpu_vram_mgr_new - this function is called during the
first step of a buffer object create (eg, DRM_AMDGPU_GEM_CREATE)
so the later both CPU and GPU mapping function calls will
pick up this flag for CPU/GPU page table set up.

Signed-off-by: Oak Zeng 
Suggested-by: Christian Koenig 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c  | 4 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 +
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 6297363..93acf6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -607,10 +607,6 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_device 
*bdev,
  
  		mem->bus.offset += adev->gmc.aper_base;

mem->bus.is_iomem = true;
-   if (adev->gmc.xgmi.connected_to_cpu)
-   mem->bus.caching = ttm_cached;
-   else
-   mem->bus.caching = ttm_write_combined;
break;
default:
return -EINVAL;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index a52e17e..6cb66eb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -454,6 +454,11 @@ static int amdgpu_vram_mgr_new(struct ttm_resource_manager 
*man,
if (i == 1)
mem->placement |= TTM_PL_FLAG_CONTIGUOUS;
  
+	if (adev->gmc.xgmi.connected_to_cpu)

+   mem->bus.caching = ttm_cached;
+   else
+   mem->bus.caching = ttm_write_combined;
+
atomic64_add(vis_usage, >vis_usage);
mem->mm_node = nodes;
return 0;


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] drm/amd/display: Respect CONFIG_FRAME_WARN=0 in dml Makefile

2021-06-29 Thread Reka Norman
Setting CONFIG_FRAME_WARN=0 should disable 'stack frame larger than'
warnings. This is useful for example in KASAN builds. Make the dml
Makefile respect this config.

Fixes the following build warnings with CONFIG_KASAN=y and
CONFIG_FRAME_WARN=0:

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_mode_vba_30.c:3642:6:
warning: stack frame size of 2216 bytes in function
'dml30_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3957:6:
warning: stack frame size of 2568 bytes in function
'dml31_ModeSupportAndSystemConfigurationFull' [-Wframe-larger-than=]

Signed-off-by: Reka Norman 
---

 drivers/gpu/drm/amd/display/dc/dml/Makefile | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/dc/dml/Makefile 
b/drivers/gpu/drm/amd/display/dc/dml/Makefile
index d34024fd798a..45862167e6ce 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dml/Makefile
@@ -50,6 +50,10 @@ dml_ccflags += -msse2
 endif
 endif
 
+ifneq ($(CONFIG_FRAME_WARN),0)
+frame_warn_flag := -Wframe-larger-than=2048
+endif
+
 CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
 
 ifdef CONFIG_DRM_AMD_DC_DCN
@@ -60,9 +64,9 @@ CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_mode_vba_20v2.o := 
$(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn20/display_rq_dlg_calc_20v2.o := $(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_mode_vba_21.o := $(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn21/display_rq_dlg_calc_21.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) 
-Wframe-larger-than=2048
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_mode_vba_30.o := $(dml_ccflags) 
$(frame_warn_flag)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn30/display_rq_dlg_calc_30.o := $(dml_ccflags)
-CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) 
-Wframe-larger-than=2048
+CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_mode_vba_31.o := $(dml_ccflags) 
$(frame_warn_flag)
 CFLAGS_$(AMDDALPATH)/dc/dml/dcn31/display_rq_dlg_calc_31.o := $(dml_ccflags)
 CFLAGS_$(AMDDALPATH)/dc/dml/display_mode_lib.o := $(dml_ccflags)
 CFLAGS_REMOVE_$(AMDDALPATH)/dc/dml/display_mode_vba.o := $(dml_rcflags)
-- 
2.32.0.93.g670b81a890-goog

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: AMDGPU error: "[drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for fences timed out!"

2021-06-29 Thread Michel Dänzer
On 2021-06-28 7:16 p.m., Deucher, Alexander wrote:
> 
> Thanks for narrowing this down.  There is new PCO SDMA firmware available 
> (attached).  Can you try it?

Sure, I'll try it, thanks.


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v4 19/27] drm/stm: Don't set struct drm_device.irq_enabled

2021-06-29 Thread yannick Fertre

Hello Thomas,
thanks for the patch.

Tested-by: Yannick Fertre 

Best regards


On 6/25/21 10:22 AM, Thomas Zimmermann wrote:

The field drm_device.irq_enabled is only used by legacy drivers
with userspace modesetting. Don't set it in stm.

Signed-off-by: Thomas Zimmermann 
Reviewed-by: Laurent Pinchart 
Acked-by: Daniel Vetter 
---
  drivers/gpu/drm/stm/ltdc.c | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 08b71248044d..e9c5a52f041a 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -1339,9 +1339,6 @@ int ltdc_load(struct drm_device *ddev)
goto err;
}
  
-	/* Allow usage of vblank without having to call drm_irq_install */

-   ddev->irq_enabled = 1;
-
clk_disable_unprepare(ldev->pixel_clk);
  
  	pinctrl_pm_select_sleep_state(ddev->dev);



___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


RE: [PATCH] drm/amdgpu: enable sdma0 tmz for Raven/Renoir(V2)

2021-06-29 Thread Huang, Ray
[AMD Official Use Only]

Reviewed-by: Huang Rui 

-Original Message-
From: Liu, Aaron  
Sent: Monday, June 28, 2021 10:55 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, Ray 
; Tuikov, Luben ; Koenig, Christian 
; Liu, Aaron 
Subject: [PATCH] drm/amdgpu: enable sdma0 tmz for Raven/Renoir(V2)

Without driver loaded, SDMA0_UTCL1_PAGE.TMZ_ENABLE is set to 1 by default for 
all asic. On Raven/Renoir, the sdma goldsetting changes 
SDMA0_UTCL1_PAGE.TMZ_ENABLE to 0.
This patch restores SDMA0_UTCL1_PAGE.TMZ_ENABLE to 1.

Signed-off-by: Aaron Liu 
Acked-by: Luben Tuikov 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index ae5464e2535a..f6881d99609b 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -144,7 +144,7 @@ static const struct soc15_reg_golden 
golden_settings_sdma_4_1[] = {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC0_RB_WPTR_POLL_CNTL, 
0xfff7, 0x00403000),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_IB_CNTL, 0x800f0111, 
0x0100),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL, 
0xfff7, 0x00403000),
-   SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x03ff, 
0x03c0),
+   SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x03ff, 
+0x03e0),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc00, 
0x)  };
 
@@ -288,7 +288,7 @@ static const struct soc15_reg_golden 
golden_settings_sdma_4_3[] = {
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_POWER_CNTL, 0x003fff07, 
0x4051),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC0_RB_WPTR_POLL_CNTL, 
0xfff7, 0x00403000),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_RLC1_RB_WPTR_POLL_CNTL, 
0xfff7, 0x00403000),
-   SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x03ff, 
0x03c0),
+   SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_PAGE, 0x03ff, 
+0x03e0),
SOC15_REG_GOLDEN_VALUE(SDMA0, 0, mmSDMA0_UTCL1_WATERMK, 0xfc00, 
0x03fbe1fe)  };
 
--
2.25.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

2021-06-29 Thread Simon Ser
On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen  
wrote:

> yes, I think this makes sense, even if it is a property that one can't
> tell for sure what it does before hand.
>
> Using a pair of properties, preference and active, to ask for something
> and then check what actually worked is good for reducing the
> combinatorial explosion caused by needing to "atomic TEST_ONLY commit"
> test different KMS configurations. Userspace has a better chance of
> finding a configuration that is possible.
>
> OTOH, this has the problem than in UI one cannot tell the user in
> advance which options are truly possible. Given that KMS properties are
> rarely completely independent, and in this case known to depend on
> several other KMS properties, I think it is good enough to know after
> the fact.
>
> If a driver does not use what userspace prefers, there is no way to
> understand why, or what else to change to make it happen. That problem
> exists anyway, because TEST_ONLY commits do not give useful feedback
> but only a yes/no.

By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one
property at a time), user-space can discover which property makes the atomic
commit fail.

I'm not a fan of this "preference" property approach. The only way to find out
whether it's possible to change the color format is to perform a user-visible
change (with a regular atomic commit) and check whether it worked
after-the-fact. This is unlike all other existing KMS properties.

I'd much rather see a more general approach to fix this combinatorial explosion
than to add special-cases like this.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu: add non-aligned address supported in amdgpu_device_vram_access()

2021-06-29 Thread Wang, Kevin(Yang)
[AMD Official Use Only]

Hi Chris,



the primary use of amdgpu_device_vram_access() is to gate direct kernel access 
to VRAM using the MM_INDEX/MM_DATA registers or aperture. It should by design 
never deal with data sizes != 4 bytes.
[kevin]:
NOT​​ size aligned, it is offset (address) aligned, e.g.: RW 0x0023 5bytes. ( 
it is not supported without this patch)

The amdgpu_ttm_access_memory() is for debug access to the backing store of BOs 
and needs to handle per byte access.
[kevin]:
yes, this function support per byte access, but it will use MM_INDEX/DATA to 
handle un-aligned address whether it is in visible memory or not. with mmio 
protect feature is enabled, the MM_INDEX/DATA is not working well, but in fact, 
the driver can access this vram memory when offset is in visible range.

Best Regards,
Kevin

From: Christian König 
Sent: Monday, June 28, 2021 11:34 PM
To: Wang, Kevin(Yang) ; amd-gfx@lists.freedesktop.org 

Cc: Deucher, Alexander ; Koenig, Christian 
; Zhang, Hawking ; Min, Frank 
; Lazar, Lijo 
Subject: Re: [PATCH] drm/amdgpu: add non-aligned address supported in 
amdgpu_device_vram_access()

Hi Kevin,

the primary use of amdgpu_device_vram_access() is to gate direct kernel access 
to VRAM using the MM_INDEX/MM_DATA registers or aperture. It should by design 
never deal with data sizes != 4 bytes.

The amdgpu_ttm_access_memory() is for debug access to the backing store of BOs 
and also needs to handle per byte access.

What we can do is to also use amdgpu_device_vram_access() in 
amdgpu_device_vram_access() for the masked access, which would also solve a hot 
plug bug as far as I can see here.

But moving the byte access logic into amdgpu_device_vram_access() makes no 
sense at all.

Regards,
Christian.

Am 28.06.21 um 16:43 schrieb Wang, Kevin(Yang):

[AMD Official Use Only]

Hi Chris,

amdgpu_ttm_access_memory(struct ttm_buffer_object *bo, unsigned long offset, 
void *buf, int len,  int write)

the above function will be called from kernel side (likes 'get_user_pages' code 
path),  and the function should accept non-aligned addresses.
without this patch, this function will be using MM_INDEX/DATA to handle aligned 
address whether in visible memory or not.
for this kind of case , I think the driver should check whether VRAM aperture 
works first, then using MM_INDEX/DATA as a backup option.

for this patch, I only extend amdgpu_device_vram_access() function to support 
un-aligned case, and the new function is fully compatible with the old code 
logic.
I can't understand why you give a NAK about this patch, I think it's a good 
optimization, how do you think?
thanks.

Best Regards,
Kevin

From: Christian König 

Sent: Monday, June 28, 2021 10:10 PM
To: Wang, Kevin(Yang) ; 
amd-gfx@lists.freedesktop.org 

Cc: Deucher, Alexander 
; Koenig, 
Christian 
Subject: Re: [PATCH] drm/amdgpu: add non-aligned address supported in 
amdgpu_device_vram_access()

Am 25.06.21 um 05:24 schrieb Kevin Wang:
> 1. add non-aligned address support in amdgpu_device_vram_access()
> 2. reduce duplicate code in amdgpu_ttm_access_memory()
>
> because the MM_INDEX{HI}/DATA are protected register, it is not working
> in sriov environment when mmio protect feature is enabled (in some asics),
> and the old function amdgpu_ttm_access_memory() will force using MM_INDEX/DATA
> to handle non-aligned address by default, it will cause the register(MM_DATA)
> is always return 0.
>
> with the patch, the memory will be accessed in the aper way first.
> (in visible memory or enable pcie large-bar feature), then using
> MM_INDEX{HI}/MM_DATA to access rest vram memroy.

Well NAK to the whole approach.

The amdgpu_device_vram_access() are intentionally *NOT* using the VRAM
aperture nor providing byte wise access.

And yes that this doesn't work under SRIOV is completely intentional as
well.

What we could do is to use the aperture in amdgpu_ttm_access_memory()
for unaligned access if that is indeed a problem.

Regards,
Christian.


>
> Signed-off-by: Kevin Wang 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h|  2 +-
>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 69 --
>   drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 42 ++---
>   3 files changed, 58 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index d14b4968a026..8095d9a9c857 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1103,7 +1103,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev);
>   int amdgpu_gpu_wait_for_idle(struct amdgpu_device *adev);
>
>   void amdgpu_device_vram_access(struct amdgpu_device *adev,