Re: [PATCH] drm/amdkfd: avoid svm dump when dynamic debug disabled

[Mike Lothian]

On Thu, 3 Aug 2023 at 20:43, Felix Kuehling  wrote:
>
> Is your kernel configured without dynamic debugging? Maybe we need to
> wrap this in some #if defined(CONFIG_DYNAMIC_DEBUG_CORE).
>

Apologies, I thought I'd replied to this, yes I didn't have dynamic
debugging enabled

Re: [PATCH V2 1/5] drm/amdkfd: ignore crat by default

[Mike Lothian]

On Tue, 8 Aug 2023 at 15:59, Christian König
 wrote:
>
> Am 08.08.23 um 00:05 schrieb Alex Deucher:
> > We are dropping the IOMMUv2 path, so no need to enable this.
> > It's often buggy on consumer platforms anyway.
> >
> > Signed-off-by: Alex Deucher 
>
> Bye ATC, it wasn't really nice with you :)
>
> Acked-by: Christian König  for the whole series.
>

Tested-by: Mike Lothian 

Re: [PATCH] drm/amdkfd: avoid svm dump when dynamic debug disabled

[Mike Lothian]

Hi

I'm seeing a compiler failure with Clang 16

  CC  drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.o
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:3568:2: error: call to
undeclared function '_dynamic_func_call_no_desc'; ISO C99 and later do
not support implicit function declarations
[-Wimplicit-function-declaration]
   dynamic_svm_range_dump(svms);
   ^
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:50:2: note: expanded
from macro 'dynamic_svm_range_dump'
   _dynamic_func_call_no_desc("svm_range_dump", svm_range_debug_dump, svms)
   ^
1 error generated.

Cheers

Mike

On Wed, 19 Jul 2023 at 22:27, Felix Kuehling  wrote:
>
> Am 2023-07-19 um 17:22 schrieb Alex Sierra:
> > Set dynamic_svm_range_dump macro to avoid iterating over SVM lists
> > from svm_range_debug_dump when dynamic debug is disabled. Otherwise,
> > it could drop performance, specially with big number of SVM ranges.
> > Make sure both svm_range_set_attr and svm_range_debug_dump functions
> > are dynamically enabled to print svm_range_debug_dump debug traces.
> >
> > Signed-off-by: Alex Sierra 
> > Tested-by: Alex Sierra 
> > Signed-off-by: Philip Yang 
> > Signed-off-by: Felix Kuehling 
>
> I don't think my name on a Signed-off-by is appropriate here. I didn't
> write the patch. And I'm not submitting it. However, the patch is
>
> Reviewed-by: Felix Kuehling 
>
>
> > ---
> >   drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
> > b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> > index 479c4f66afa7..1b50eae051a4 100644
> > --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> > +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> > @@ -46,6 +46,8 @@
> >* page table is updated.
> >*/
> >   #define AMDGPU_SVM_RANGE_RETRY_FAULT_PENDING(2UL * NSEC_PER_MSEC)
> > +#define dynamic_svm_range_dump(svms) \
> > + _dynamic_func_call_no_desc("svm_range_dump", svm_range_debug_dump, 
> > svms)
> >
> >   /* Giant svm range split into smaller ranges based on this, it is decided 
> > using
> >* minimum of all dGPU/APU 1/32 VRAM size, between 2MB to 1GB and 
> > alignment to
> > @@ -3563,7 +3565,7 @@ svm_range_set_attr(struct kfd_process *p, struct 
> > mm_struct *mm,
> >   break;
> >   }
> >
> > - svm_range_debug_dump(svms);
> > + dynamic_svm_range_dump(svms);
> >
> >   mutex_unlock(>lock);
> >   mmap_read_unlock(mm);

Re: [PATCH] Revert "drm/amd/display: fix dpms_off issue when disabling bios mode"

[Mike Lothian]

Thanks

I'm happy to help debug this further

On Mon, 12 Jun 2023 at 15:18, Harry Wentland  wrote:
>
> On 6/12/23 10:00, Alex Deucher wrote:
> > This reverts commit 58e67bb3c131da5ee14e4842b08e53f4888dce0a.
> >
> > This patch was reverted, but came back again as
> > commit 58e67bb3c131 ("drm/amd/display: fix dpms_off issue when disabling 
> > bios mode")
> > Revert it again as it breaks Asus G513QY / 6800M laptops.
> >
> > Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2259
> > Cc: Rodrigo Siqueira 
> > Cc: Zhongwei 
> > Cc: Harry Wentland 
> > Cc: Mike Lothian 
> > Signed-off-by: Alex Deucher 
>
> Reviewed-by: Harry Wentland 
>
> Harry
>
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> > b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > index be72e03cdf92..5d3d61faeb28 100644
> > --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> > +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> > @@ -1296,7 +1296,7 @@ static void disable_vbios_mode_if_required(
> >
> >   if (pix_clk_100hz != 
> > requested_pix_clk_100hz) {
> >   
> > dc->link_srv->set_dpms_off(pipe);
> > - pipe->stream->dpms_off = true;
> > + pipe->stream->dpms_off = 
> > false;
> >   }
> >   }
> >   }
>

Re: [PATCH 61/66] drm/amd/display: fix dpms_off issue when disabling bios mode

[Mike Lothian]

Hi

This gives me a blank screen when booting on my Ryzen 9 5900HX Laptop

03:00.0 Display controller [0380]: Advanced Micro Devices, Inc.
[AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT]
[1002:73df] (rev c3)
08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Cezanne [Radeon Vega Series / Radeon Vega Mobile Series]
[1002:1638] (rev c4)

This is the second time this has been changed - the last time was back
in November, I'll happily help debug why this is breaking on my laptop
but I'd appreciate if this would be reverted and not reattempted until
the underlying issue is fixed

Cheers

Mike

On Fri, 14 Apr 2023 at 16:55, Qingqing Zhuo  wrote:
>
> From: Zhongwei 
>
> [Why]
> disable_vbios_mode_if_required() will set dpms_off to false during boot
> when pixel clk dismatches with driver requires. This will cause extra
> backlight on and off if OS call 2 times setmode.
>
> [How]
> Set dpms_off to true to keep power_off and let OS control backlight by
> display's powerState.
>
> Reviewed-by: Rodrigo Siqueira 
> Signed-off-by: Zhongwei 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 9304eb66a1af..238a13266ad8 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1268,7 +1268,7 @@ static void disable_vbios_mode_if_required(
>
> if (pix_clk_100hz != 
> requested_pix_clk_100hz) {
> 
> dc->link_srv->set_dpms_off(pipe);
> -   pipe->stream->dpms_off = 
> false;
> +   pipe->stream->dpms_off = true;
> }
> }
> }
> --
> 2.34.1
>

Re: [PATCH 06/29] drm/amdgpu: keep amdgpu_ctx_mgr in ctx structure

[Mike Lothian]

On Wed, 10 May 2023 at 22:24, Alex Deucher  wrote:
>
> From: James Zhu 
>
> Keep amdgpu_ctx_mgr in ctx structure to track fpriv.
>
> Signed-off-by: James Zhu 
> Acked-by: Lijo Lazar 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> index e3d047663d61..06d68a08251a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
> @@ -332,6 +332,7 @@ static int amdgpu_ctx_init(struct amdgpu_ctx_mgr *mgr, 
> int32_t priority,
> else
> ctx->stable_pstate = current_stable_pstate;
>
> +   ctx->ctx_mgr = &(fpriv->ctx_mgr);
> return 0;
>  }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
> index 5fd79f94e2d0..85376baaa92f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.h
> @@ -57,6 +57,7 @@ struct amdgpu_ctx {
> unsigned long   ras_counter_ce;
> unsigned long   ras_counter_ue;
> uint32_tstable_pstate;
> +   struct amdgpu_ctx_mgr   *ctx_mgr;
>  };
>
>  struct amdgpu_ctx_mgr {
> --
> 2.40.1
>

Hi

This isn't compiling for me with clang 16

drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c:348:19: error: use of
undeclared identifier 'fpriv'
   ctx->ctx_mgr = &(fpriv->ctx_mgr);
^
1 error generated.

Cheers

Mike

Re: [PATCH 10/13] drm/amdgpu: use scheduler depenencies for CS

[Mike Lothian]

On Wed, 21 Dec 2022 at 15:52, Luben Tuikov  wrote:
>
> On 2022-12-21 10:34, Mike Lothian wrote:
> > On Fri, 14 Oct 2022 at 09:47, Christian König
> >  wrote:
> >>
> >> Entirely remove the sync obj in the job.
> >>
> >> Signed-off-by: Christian König 
> >> ---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 21 ++---
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h  |  2 ++
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  9 +
> >>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.h |  1 -
> >>  4 files changed, 13 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >> index d45b86bcf7fa..0528c2b1db6e 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> >> @@ -426,7 +426,7 @@ static int amdgpu_cs_p2_dependencies(struct 
> >> amdgpu_cs_parser *p,
> >> dma_fence_put(old);
> >> }
> >>
> >> -   r = amdgpu_sync_fence(>gang_leader->sync, fence);
> >> +   r = amdgpu_sync_fence(>sync, fence);
> >> dma_fence_put(fence);
> >> if (r)
> >> return r;
> >> @@ -448,7 +448,7 @@ static int amdgpu_syncobj_lookup_and_add(struct 
> >> amdgpu_cs_parser *p,
> >> return r;
> >> }
> >>
> >> -   r = amdgpu_sync_fence(>gang_leader->sync, fence);
> >> +   r = amdgpu_sync_fence(>sync, fence);
> >> if (r)
> >> goto error;
> >>
> >> @@ -1108,7 +1108,7 @@ static int amdgpu_cs_vm_handling(struct 
> >> amdgpu_cs_parser *p)
> >> if (r)
> >> return r;
> >>
> >> -   r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update);
> >> +   r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update);
> >> if (r)
> >> return r;
> >>
> >> @@ -1119,7 +1119,7 @@ static int amdgpu_cs_vm_handling(struct 
> >> amdgpu_cs_parser *p)
> >> if (r)
> >> return r;
> >>
> >> -   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> >> +   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> >> if (r)
> >> return r;
> >> }
> >> @@ -1138,7 +1138,7 @@ static int amdgpu_cs_vm_handling(struct 
> >> amdgpu_cs_parser *p)
> >> if (r)
> >> return r;
> >>
> >> -   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> >> +   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> >> if (r)
> >> return r;
> >> }
> >> @@ -1151,7 +1151,7 @@ static int amdgpu_cs_vm_handling(struct 
> >> amdgpu_cs_parser *p)
> >> if (r)
> >> return r;
> >>
> >> -   r = amdgpu_sync_fence(>sync, vm->last_update);
> >> +   r = amdgpu_sync_fence(>sync, vm->last_update);
> >> if (r)
> >> return r;
> >>
> >> @@ -1183,7 +1183,6 @@ static int amdgpu_cs_vm_handling(struct 
> >> amdgpu_cs_parser *p)
> >>  static int amdgpu_cs_sync_rings(struct amdgpu_cs_parser *p)
> >>  {
> >> struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> >> -   struct amdgpu_job *leader = p->gang_leader;
> >> struct amdgpu_bo_list_entry *e;
> >> unsigned int i;
> >> int r;
> >> @@ -1195,14 +1194,14 @@ static int amdgpu_cs_sync_rings(struct 
> >> amdgpu_cs_parser *p)
> >>
> >> sync_mode = amdgpu_bo_explicit_sync(bo) ?
> >> AMDGPU_SYNC_EXPLICIT : AMDGPU_SYNC_NE_OWNER;
> >> -   r = amdgpu_sync_resv(p->adev, >sync, resv, 
> >> sync_mode,
> >> +   r = amdgpu_sync_resv(p->adev, >sync, resv, sync_mode,
> >>  >vm);
> >> if (r)
> >> return r;
> >> }
> >>
> >> -   for (i = 0; i < p->gang_size - 1; ++i) {
>

Re: [PATCH 10/13] drm/amdgpu: use scheduler depenencies for CS

[Mike Lothian]

https://gitlab.freedesktop.org/drm/amd/-/issues/2309

On Wed, 21 Dec 2022 at 15:34, Mike Lothian  wrote:
>
> On Fri, 14 Oct 2022 at 09:47, Christian König
>  wrote:
> >
> > Entirely remove the sync obj in the job.
> >
> > Signed-off-by: Christian König 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 21 ++---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h  |  2 ++
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  9 +
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_job.h |  1 -
> >  4 files changed, 13 insertions(+), 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > index d45b86bcf7fa..0528c2b1db6e 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> > @@ -426,7 +426,7 @@ static int amdgpu_cs_p2_dependencies(struct 
> > amdgpu_cs_parser *p,
> > dma_fence_put(old);
> > }
> >
> > -   r = amdgpu_sync_fence(>gang_leader->sync, fence);
> > +   r = amdgpu_sync_fence(>sync, fence);
> > dma_fence_put(fence);
> > if (r)
> > return r;
> > @@ -448,7 +448,7 @@ static int amdgpu_syncobj_lookup_and_add(struct 
> > amdgpu_cs_parser *p,
> > return r;
> > }
> >
> > -   r = amdgpu_sync_fence(>gang_leader->sync, fence);
> > +   r = amdgpu_sync_fence(>sync, fence);
> > if (r)
> > goto error;
> >
> > @@ -1108,7 +1108,7 @@ static int amdgpu_cs_vm_handling(struct 
> > amdgpu_cs_parser *p)
> > if (r)
> > return r;
> >
> > -   r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update);
> > +   r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update);
> > if (r)
> > return r;
> >
> > @@ -1119,7 +1119,7 @@ static int amdgpu_cs_vm_handling(struct 
> > amdgpu_cs_parser *p)
> > if (r)
> > return r;
> >
> > -   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> > +   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> > if (r)
> > return r;
> > }
> > @@ -1138,7 +1138,7 @@ static int amdgpu_cs_vm_handling(struct 
> > amdgpu_cs_parser *p)
> > if (r)
> > return r;
> >
> > -   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> > +   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> > if (r)
> > return r;
> > }
> > @@ -1151,7 +1151,7 @@ static int amdgpu_cs_vm_handling(struct 
> > amdgpu_cs_parser *p)
> > if (r)
> > return r;
> >
> > -   r = amdgpu_sync_fence(>sync, vm->last_update);
> > +   r = amdgpu_sync_fence(>sync, vm->last_update);
> > if (r)
> > return r;
> >
> > @@ -1183,7 +1183,6 @@ static int amdgpu_cs_vm_handling(struct 
> > amdgpu_cs_parser *p)
> >  static int amdgpu_cs_sync_rings(struct amdgpu_cs_parser *p)
> >  {
> > struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> > -   struct amdgpu_job *leader = p->gang_leader;
> > struct amdgpu_bo_list_entry *e;
> > unsigned int i;
> > int r;
> > @@ -1195,14 +1194,14 @@ static int amdgpu_cs_sync_rings(struct 
> > amdgpu_cs_parser *p)
> >
> > sync_mode = amdgpu_bo_explicit_sync(bo) ?
> > AMDGPU_SYNC_EXPLICIT : AMDGPU_SYNC_NE_OWNER;
> > -   r = amdgpu_sync_resv(p->adev, >sync, resv, 
> > sync_mode,
> > +   r = amdgpu_sync_resv(p->adev, >sync, resv, sync_mode,
> >  >vm);
> > if (r)
> > return r;
> > }
> >
> > -   for (i = 0; i < p->gang_size - 1; ++i) {
> > -   r = amdgpu_sync_clone(>sync, >jobs[i]->sync);
> > +   for (i = 0; i < p->gang_size; ++i) {
> > +   r = amdgpu_sync_push_to_job(>sync, p->jobs[i]);
> > if (r)
> > return r;
> > }
> > @@ -1248,7 +1247,7 @@ static int amdgpu_cs_submit(

Re: [PATCH 10/13] drm/amdgpu: use scheduler depenencies for CS

[Mike Lothian]

On Fri, 14 Oct 2022 at 09:47, Christian König
 wrote:
>
> Entirely remove the sync obj in the job.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  | 21 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h  |  2 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  9 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.h |  1 -
>  4 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index d45b86bcf7fa..0528c2b1db6e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -426,7 +426,7 @@ static int amdgpu_cs_p2_dependencies(struct 
> amdgpu_cs_parser *p,
> dma_fence_put(old);
> }
>
> -   r = amdgpu_sync_fence(>gang_leader->sync, fence);
> +   r = amdgpu_sync_fence(>sync, fence);
> dma_fence_put(fence);
> if (r)
> return r;
> @@ -448,7 +448,7 @@ static int amdgpu_syncobj_lookup_and_add(struct 
> amdgpu_cs_parser *p,
> return r;
> }
>
> -   r = amdgpu_sync_fence(>gang_leader->sync, fence);
> +   r = amdgpu_sync_fence(>sync, fence);
> if (r)
> goto error;
>
> @@ -1108,7 +1108,7 @@ static int amdgpu_cs_vm_handling(struct 
> amdgpu_cs_parser *p)
> if (r)
> return r;
>
> -   r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update);
> +   r = amdgpu_sync_fence(>sync, fpriv->prt_va->last_pt_update);
> if (r)
> return r;
>
> @@ -1119,7 +1119,7 @@ static int amdgpu_cs_vm_handling(struct 
> amdgpu_cs_parser *p)
> if (r)
> return r;
>
> -   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> +   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> if (r)
> return r;
> }
> @@ -1138,7 +1138,7 @@ static int amdgpu_cs_vm_handling(struct 
> amdgpu_cs_parser *p)
> if (r)
> return r;
>
> -   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> +   r = amdgpu_sync_fence(>sync, bo_va->last_pt_update);
> if (r)
> return r;
> }
> @@ -1151,7 +1151,7 @@ static int amdgpu_cs_vm_handling(struct 
> amdgpu_cs_parser *p)
> if (r)
> return r;
>
> -   r = amdgpu_sync_fence(>sync, vm->last_update);
> +   r = amdgpu_sync_fence(>sync, vm->last_update);
> if (r)
> return r;
>
> @@ -1183,7 +1183,6 @@ static int amdgpu_cs_vm_handling(struct 
> amdgpu_cs_parser *p)
>  static int amdgpu_cs_sync_rings(struct amdgpu_cs_parser *p)
>  {
> struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> -   struct amdgpu_job *leader = p->gang_leader;
> struct amdgpu_bo_list_entry *e;
> unsigned int i;
> int r;
> @@ -1195,14 +1194,14 @@ static int amdgpu_cs_sync_rings(struct 
> amdgpu_cs_parser *p)
>
> sync_mode = amdgpu_bo_explicit_sync(bo) ?
> AMDGPU_SYNC_EXPLICIT : AMDGPU_SYNC_NE_OWNER;
> -   r = amdgpu_sync_resv(p->adev, >sync, resv, sync_mode,
> +   r = amdgpu_sync_resv(p->adev, >sync, resv, sync_mode,
>  >vm);
> if (r)
> return r;
> }
>
> -   for (i = 0; i < p->gang_size - 1; ++i) {
> -   r = amdgpu_sync_clone(>sync, >jobs[i]->sync);
> +   for (i = 0; i < p->gang_size; ++i) {
> +   r = amdgpu_sync_push_to_job(>sync, p->jobs[i]);
> if (r)
> return r;
> }
> @@ -1248,7 +1247,7 @@ static int amdgpu_cs_submit(struct amdgpu_cs_parser *p,
> struct dma_fence *fence;
>
> fence = >jobs[i]->base.s_fence->scheduled;
> -   r = amdgpu_sync_fence(>sync, fence);
> +   r = drm_sched_job_add_dependency(>base, fence);
> if (r)
> goto error_cleanup;
> }
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h
> index cbaa19b2b8a3..207e801c24ed 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h
> @@ -75,6 +75,8 @@ struct amdgpu_cs_parser {
>
> unsignednum_post_deps;
> struct amdgpu_cs_post_dep   *post_deps;
> +
> +   struct amdgpu_sync  sync;
>  };
>
>  int amdgpu_cs_find_mapping(struct amdgpu_cs_parser *parser,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> index ba98d65835b4..b8494c3b3b8a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> @@ -106,7 +106,6 @@ int 

Re: [PATCH] Revert "drm/amd/display: fix dpms_off issue when disabling bios mode"

[Mike Lothian]

On Thu, 17 Nov 2022 at 14:49, Alex Deucher  wrote:
>
> This reverts commit 5aa663752ff6f844c6bfc97d89231e98884ae769.
>
> This causes a blank screen on boot on an Asus G513QY / 6800M laptop.
>
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2259
> Cc: Aric Cyr 
> Cc: Tom Chung 
> Cc: Zhongwei Zhang 
> Cc: Harry Wentland 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 1c3de3a1671e..049ef31ebf69 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1192,7 +1192,7 @@ static void disable_vbios_mode_if_required(
>
> if (pix_clk_100hz != 
> requested_pix_clk_100hz) {
> 
> core_link_disable_stream(pipe);
> -   pipe->stream->dpms_off = true;
> +   pipe->stream->dpms_off = 
> false;
> }
> }
>     }
> --
> 2.38.1
>

Thanks for the quick turn around. Feel free to add:

Tested-by: Mike Lothian 

Re: [PATCH 04/29] drm/amd/display: fix dpms_off issue when disabling bios mode

[Mike Lothian]

On Wed, 9 Nov 2022 at 06:15, Tom Chung  wrote:
>
> From: Zhongwei Zhang 
>
> [Why]
> disable_vbios_mode_if_required() will set dpms_off to false
> during boot when pixel clk dismatches with driver requires.
> This will cause extra backlight on and off if OS call 2
> times setmode.
>
> [How]
> Set dpms_off to true to keep power_off and
> let OS control BL by display's powerState.
>
> Reviewed-by: Aric Cyr 
> Acked-by: Tom Chung 
> Signed-off-by: Zhongwei Zhang 
> ---
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc.c
> index 9c3704c4d7e4..9f42adc234e3 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
> @@ -1192,7 +1192,7 @@ static void disable_vbios_mode_if_required(
>
> if (pix_clk_100hz != 
> requested_pix_clk_100hz) {
> 
> core_link_disable_stream(pipe);
> -   pipe->stream->dpms_off = 
> false;
> +   pipe->stream->dpms_off = true;
> }
> }
> }
> --
> 2.25.1
>

Hi, this patch gives me a blank screen when booting my Asus G513QY /
6800M. apart from the screen being of I can ssh in just fine

Reverting it puts things back to normal

Cheers

Mike

Re: [PATCH] Revert "drm/amdgpu: add drm buddy support to amdgpu"

[Mike Lothian]

Hi

When is this relanding?

Cheers

Mike

On Mon, 18 Jul 2022 at 21:40, Dixit, Ashutosh  wrote:
>
> On Thu, 14 Jul 2022 08:00:32 -0700, Christian König wrote:
> >
> > Am 14.07.22 um 15:33 schrieb Alex Deucher:
> > > On Thu, Jul 14, 2022 at 9:09 AM Christian König
> > >  wrote:
> > >> Hi Mauro,
> > >>
> > >> well the last time I checked drm-tip was clean.
> > >>
> > >> The revert is necessary because we had some problems with the commit
> > >> which we couldn't fix in the 5.19 cycle.
> > > Would it be worth reverting the revert and applying the actual fix[1]?
> > >   It's a huge revert unfortunately while the actual fix is like 10
> > > lines of code.  I'm concerned there will be subtle fallout from the
> > > revert due to how extensive it is.
> >
> > We have other bug fixes and cleanups around that patch which didn't made it
> > into 5.19 either. I don't want to create an ever greater mess.
> >
> > Real question is why building drm-tip work for me but not for others?
>
> Seeing this on latest drm-tip:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:54:1: error: redefinition of 
> ‘amdgpu_vram_mgr_first_block’
>54 | amdgpu_vram_mgr_first_block(struct list_head *list)
>   | ^~~
> In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h:29,
>  from drivers/gpu/drm/amd/amdgpu/amdgpu.h:73,
>  from drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:28:
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h:57:1: note: previous definition 
> of ‘amdgpu_vram_mgr_first_block’ with type ‘struct drm_buddy_block *(struct 
> list_head *)’
>57 | amdgpu_vram_mgr_first_block(struct list_head *list)
>   | ^~~
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:59:20: error: redefinition of 
> ‘amdgpu_is_vram_mgr_blocks_contiguous’
>59 | static inline bool amdgpu_is_vram_mgr_blocks_contiguous(struct 
> list_head *head)
>   |^~~~
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h:62:20: note: previous definition 
> of ‘amdgpu_is_vram_mgr_blocks_contiguous’ with type ‘bool(struct list_head 
> *)’ {aka ‘_Bool(struct list_head *)’}
>62 | static inline bool amdgpu_is_vram_mgr_blocks_contiguous(struct 
> list_head *head)
>   |^~~~
> make[4]: *** [scripts/Makefile.build:249: 
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o] Error 1
> make[4]: *** Waiting for unfinished jobs
> make[3]: *** [scripts/Makefile.build:466: drivers/gpu/drm/amd/amdgpu] Error 2
> make[2]: *** [scripts/Makefile.build:466: drivers/gpu/drm] Error 2
> make[1]: *** [scripts/Makefile.build:466: drivers/gpu] Error 2

Re: Please consider Open-source OpenCL support in amdgpu/mesa

[Mike Lothian]

I've recently gotten ROCm 5.1.3 working on Gentoo with the open
drivers and using upstream llvm 14.0.6, it's enough to get LuxMark 3
running (well with fast math disabled)

You might want to look for a distro that packages ROCm for you as
Clover is nowhere near ready

On Fri, 29 Jul 2022 at 11:06, Luís Mendes  wrote:
>
> Hi,
>
> I am an Aparapi project developer that has been struggling for two
> years to get an RX 5700 properly running OpenCL applications.
>
> First of all, as an end consumer, I would like to congratulate the
> open-source amdgpu driver for its stability and performance, as well
> as the team behind it! Unfortunately I cannot say the same for the
> closed source, proprietary drivers which have been a nightmare in
> terms of quality and stability and currently the only way to have
> OpenCL... which in reality is not the case, because it does not have
> any stability.
>
> The open-source driver has been superior in terms of OpenGL and Vulkan
> stability and performance, it just misses OpenCL to be complete.
>
> I am not expecting any reply on this, nor that it will make the
> Open-source OpenCL support for AMD graphics cards a reality... I just
> want to share this reality that I am experiencing for two years, with
> many amdgpu-pro driver versions tested and also the new deb based
> amdgpu-install drivers. None of them provided a working solution,
> neither legacy based, nor rocr based ones. The machine starts running
> a few OpenCL jobs, which after a few seconds lead to a black screen,
> followed by GPU reset and machine hanging. The same OpenCL jobs run
> fine on a GT 1030. There is also a big issue when running the RX 5700
> as a secondary GPU, aside with the GT 1030 as the primary card, which
> causes the amdgpu driver to fail to load and renders the RX 5700
> unusable. I just wanted to share my experience with this card and hope
> for a better future.
>
> Please consider Open-source OpenCL support in amdgpu/mesa.
>
> Best regards,
> Luís Mendes

Re: Command "clinfo" causes BUG: kernel NULL pointer dereference, address: 0000000000000008 on driver amdgpu

[Mike Lothian]

I was told that this patch replaces the patch you mentioned
https://patchwork.freedesktop.org/series/106078/ and it the one
that'll hopefully land in Linus's tree

On Tue, 19 Jul 2022 at 03:33, Chen, Guchun  wrote:
>
> Patch https://patchwork.freedesktop.org/series/106024/ should fix this.
>
> Regards,
> Guchun
>
> -Original Message-
> From: amd-gfx  On Behalf Of Mikhail 
> Gavrilov
> Sent: Tuesday, July 19, 2022 7:50 AM
> To: amd-gfx list ; Linux List Kernel Mailing 
> ; Christian König 
> 
> Subject: Command "clinfo" causes BUG: kernel NULL pointer dereference, 
> address: 0008 on driver amdgpu
>
> Hi guys I continue testing 5.19 rc7 and found the bug.
> Command "clinfo" causes BUG: kernel NULL pointer dereference, address:
> 0008 on driver amdgpu.
>
> Here is trace:
> [ 1320.203332] BUG: kernel NULL pointer dereference, address: 
> 0008 [ 1320.203338] #PF: supervisor read access in kernel mode [ 
> 1320.203340] #PF: error_code(0x) - not-present page [ 1320.203341] PGD 0 
> P4D 0 [ 1320.203344] Oops:  [#1] PREEMPT SMP NOPTI [ 1320.203346] CPU: 5 
> PID: 1226 Comm: kworker/5:2 Tainted: G W L
>  --- 5.19.0-0.rc7.53.fc37.x86_64+debug #1 [ 1320.203348] Hardware 
> name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 
> 4403 04/27/2022 [ 1320.203350] Workqueue: events delayed_fput [ 1320.203354] 
> RIP: 0010:dma_resv_add_fence+0x5a/0x2d0
> [ 1320.203358] Code: 85 c0 0f 84 43 02 00 00 8d 50 01 09 c2 0f 88 47
> 02 00 00 8b 15 73 10 99 01 49 8d 45 70 48 89 44 24 10 85 d2 0f 85 05
> 02 00 00 <49> 8b 44 24 08 48 3d 80 93 53 97 0f 84 06 01 00 00 48 3d 20
> 93 53
> [ 1320.203360] RSP: 0018:af4cc1adfc68 EFLAGS: 00010246 [ 1320.203362] 
> RAX: 976660408208 RBX: 975f545f2000 RCX:  [ 
> 1320.203363] RDX:  RSI:  RDI: 
> 976660408198 [ 1320.203364] RBP: 976806f6e800 R08:  
> R09:  [ 1320.203366] R10:  R11: 
> 0001 R12:  [ 1320.203367] R13: 976660408198 
> R14: 975f545f2000 R15: 976660408198 [ 1320.203368] FS: 
> () GS:976de120()
> knlGS:
> [ 1320.203370] CS: 0010 DS:  ES:  CR0: 80050033 [ 
> 1320.203371] CR2: 0008 CR3: 0007fb31c000 CR4: 
> 00350ee0 [ 1320.203372] Call Trace:
> [ 1320.203374] 
> [ 1320.203378] amdgpu_amdkfd_gpuvm_destroy_cb+0x5d/0x1e0 [amdgpu] [ 
> 1320.203516] amdgpu_vm_fini+0x2f/0x4e0 [amdgpu] [ 1320.203625] ? 
> mutex_destroy+0x21/0x50 [ 1320.203629] 
> amdgpu_driver_postclose_kms+0x1da/0x2b0 [amdgpu] [ 1320.203734] 
> drm_file_free.part.0+0x20d/0x260 [ 1320.203738] drm_release+0x6a/0x120 [ 
> 1320.203741] __fput+0xab/0x270 [ 1320.203743] delayed_fput+0x1f/0x30 [ 
> 1320.203745] process_one_work+0x2a0/0x600 [ 1320.203749] 
> worker_thread+0x4f/0x3a0 [ 1320.203751] ? process_one_work+0x600/0x600 [ 
> 1320.203753] kthread+0xf5/0x120 [ 1320.203755] ? 
> kthread_complete_and_exit+0x20/0x20
> [ 1320.203758] ret_from_fork+0x22/0x30
> [ 1320.203764] 
>
> Full kernel log is here:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FEeKh2LErdata=05%7C01%7Cguchun.chen%40amd.com%7C06749e19d65b418748dc08da6918435f%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637937850184140997%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=x1%2FR7m9Vy2XwkXKXsmEOeaAyv44ZKNsU4caZJOOSIvY%3Dreserved=0
>
> And one hour later after a lot of messages "BUG: workqueue lockup" GPU 
> completely hung.
>
> I will be glad to test patches that fix this bug.
>
> --
> Best Regards,
> Mike Gavrilov.

Re: [PATCH] drm/amdgpu: Remove one duplicated ef removal

[Mike Lothian]

With this patch applied on Linus's tree 5.18-rc7 I get the following warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c:1367:20: warning:
unused variable 'pd' [-Wunused-variable]
   struct amdgpu_bo *pd = vm->root.bo;
 ^
1 warning generated.

It does fix the nullpointer though :D


On Fri, 8 Jul 2022 at 02:55, xinhui pan  wrote:
>
> That has been done in BO release notify.
>
> Signed-off-by: xinhui pan 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 -
>  1 file changed, 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 0f9811d02f61..49536fa8d269 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1583,11 +1583,6 @@ void amdgpu_amdkfd_gpuvm_destroy_cb(struct 
> amdgpu_device *adev,
> if (!process_info)
> return;
>
> -   /* Release eviction fence from PD */
> -   amdgpu_bo_reserve(pd, false);
> -   amdgpu_bo_fence(pd, NULL, false);
> -   amdgpu_bo_unreserve(pd);
> -
> /* Update process info */
> mutex_lock(_info->lock);
> process_info->n_vms--;
> --
> 2.34.1
>

Re: [PATCH] drm/amdgpu: Fix a NULL pointer of fence

[Mike Lothian]

Is this likely to land before 5.19 final? It's been nearly 2 weeks
since I said if fixed an issue I was seeing
https://gitlab.freedesktop.org/drm/amd/-/issues/2074

On Fri, 8 Jul 2022 at 10:05, Christian König
 wrote:
>
> Hi guys,
>
> well the practice to remove all fences by adding a NULL exclusive fence
> was pretty much illegal in the first place because this also removes
> kernel internal fences which can lead to freeing up memory which is
> still accessed.
>
> I've just didn't noticed that this was used by the KFD code as well
> otherwise I would have pushed to clean that up much earlier.
>
> Regards,
> Christian.
>
> Am 08.07.22 um 03:08 schrieb Pan, Xinhui:
> > [AMD Official Use Only - General]
> >
> > Felix,
> > Shared fences depend on exclusive fence, so add a new exclusive fence, say 
> > NULL would also remove all shared fences. That works before 5.18 . 
> >  From 5.18, adding a new exclusive fence(the write usage fence) did not 
> > remove any shared fences(the read usage fence). So that is broken.
> >
> > And I also try the debug_evictions parameter. No unexpected eviction shows 
> > anyway.
> > I did a quick check and found amdgpu implement BO release notify and it 
> > will remove kfd ef on pt/pd BO. So we don’t need this duplicated ef 
> > removal. The interesting thing is that is done by patch 
> > f4a3c42b5c52("drm/amdgpu: Remove kfd eviction fence before release bo 
> > (v2)") which is from me  I totally forgot it.
> >
> > So I would make a new patch to remove this duplicated ef removal.
> >
> > -Original Message-
> > From: Kuehling, Felix 
> > Sent: Thursday, July 7, 2022 11:47 PM
> > To: Christian König ; Pan, Xinhui 
> > ; amd-gfx@lists.freedesktop.org
> > Cc: Deucher, Alexander ; Koenig, Christian 
> > 
> > Subject: Re: [PATCH] drm/amdgpu: Fix a NULL pointer of fence
> >
> > Am 2022-07-07 um 05:54 schrieb Christian König:
> >> Am 07.07.22 um 11:50 schrieb xinhui pan:
> >>> Fence is accessed by dma_resv_add_fence() now.
> >>> Use amdgpu_amdkfd_remove_eviction_fence instead.
> >>>
> >>> Signed-off-by: xinhui pan 
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++--
> >>>1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> >>> index 0036c9e405af..1e25c400ce4f 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> >>> @@ -1558,10 +1558,10 @@ void amdgpu_amdkfd_gpuvm_destroy_cb(struct
> >>> amdgpu_device *adev,
> >>>  if (!process_info)
> >>>return;
> >>> -
> >>>/* Release eviction fence from PD */
> >>>amdgpu_bo_reserve(pd, false);
> >>> -amdgpu_bo_fence(pd, NULL, false);
> >>> +amdgpu_amdkfd_remove_eviction_fence(pd,
> >>> +process_info->eviction_fence);
> >> Good catch as well, but Felix needs to take a look at this.
> > This is weird. We used amdgpu_bo_fence(pd, NULL, false) here, which would 
> > have removed an exclusive fence. But as far as I can tell we added the 
> > fence as a shared fence in init_kfd_vm and 
> > amdgpu_amdkfd_gpuvm_restore_process_bos. So this probably never worked as 
> > intended.
> >
> > You could try if this is really needed. Just remove the eviction fence 
> > removal. Then enable eviction debugging with
> >
> >   echo Y > /sys/module/amdgpu/parameters/debug_evictions
> >
> > Run some simple tests and check the kernel log to see if process 
> > termination is causing any unexpected evictions.
> >
> > Regards,
> > Felix
> >
> >
> >> Regards,
> >> Christian.
> >>
> >>>amdgpu_bo_unreserve(pd);
> >>>  /* Update process info */
>

Re: [PATCH] drm/amdgpu: Fix a NULL pointer of fence

[Mike Lothian]

Hi

This appears to fix https://gitlab.freedesktop.org/drm/amd/-/issues/2074

Feel free to add my tested by

Thanks

Mike

On Thu, 7 Jul 2022 at 10:51, xinhui pan  wrote:
>
> Fence is accessed by dma_resv_add_fence() now.
> Use amdgpu_amdkfd_remove_eviction_fence instead.
>
> Signed-off-by: xinhui pan 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index 0036c9e405af..1e25c400ce4f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> @@ -1558,10 +1558,10 @@ void amdgpu_amdkfd_gpuvm_destroy_cb(struct 
> amdgpu_device *adev,
>
> if (!process_info)
> return;
> -
> /* Release eviction fence from PD */
> amdgpu_bo_reserve(pd, false);
> -   amdgpu_bo_fence(pd, NULL, false);
> +   amdgpu_amdkfd_remove_eviction_fence(pd,
> +   process_info->eviction_fence);
> amdgpu_bo_unreserve(pd);
>
> /* Update process info */
> --
> 2.34.1
>

Re: [PATCH 10/20] drm/amd/display: Insert pulling smu busy status before sending another request

[Mike Lothian]

Hi

I'm seeing the following stack trace, I'm guessing due to the assert:

[3.516409] [ cut here ]
[3.516412] WARNING: CPU: 1 PID: 1 at
drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c:98
rn_vbios_smu_send_msg_with_param+0x3e/0xe0
[3.516422] Modules linked in:
[3.516425] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc4-tip+ #3199
[3.516428] Hardware name: ASUSTeK COMPUTER INC. ROG Strix
G513QY_G513QY/G513QY, BIOS G513QY.318 03/29/2022
[3.516432] RIP: 0010:rn_vbios_smu_send_msg_with_param+0x3e/0xe0
[3.516437] Code: f6 48 89 fb 48 8b 3b be 9b 62 01 00 48 c7 c2 02
bd 06 83 e8 44 c6 f0 ff 85 c0 75 12 bf c6 a7 00 00 e8 f6 9a b1 ff ff
c5 75 da <0f> 0b eb 05 83 f8 01 75 f7 48 8b 3b be 9b 62 01 00 48 c7 c1
3
c 86
[3.516442] RSP: 0018:88810026f628 EFLAGS: 00010202
[3.516445] RAX: 00fe RBX: 8881058a3200 RCX: 
[3.516447] RDX:  RSI: 888105adbb80 RDI: 888104f8
[3.516450] RBP: fffcf2bf R08: 888110ca6800 R09: 7fc9117f
[3.516452] R10:  R11: 819bca10 R12: 888110cd
[3.516454] R13: 888100cc2300 R14: 000d R15: 0001
[3.516457] FS:  () GS:888fde44()
knlGS:
[3.516460] CS:  0010 DS:  ES:  CR0: 80050033
[3.516462] CR2:  CR3: b360c000 CR4: 00350ee0
[3.516465] Call Trace:
[3.516468]  
[3.516470]  ? rn_clk_mgr_construct+0x744/0x760
[3.516475]  ? dc_clk_mgr_create+0x1f0/0x4f0
[3.516478]  ? dc_create+0x43a/0x5c0
[3.516481]  ? dm_hw_init+0x29a/0x2380
[3.516485]  ? vprintk_emit+0x106/0x230
[3.516488]  ? asm_sysvec_apic_timer_interrupt+0x1f/0x30
[3.516492]  ? dev_vprintk_emit+0x152/0x179
[3.516496]  ? smu_hw_init+0x255/0x290
[3.516500]  ? amdgpu_device_ip_init+0x32a/0x4a0
[3.516504]  ? amdgpu_device_init+0x1622/0x1bb0
[3.516507]  ? pci_bus_read_config_word+0x35/0x50
[3.516512]  ? amdgpu_driver_load_kms+0x14/0x150
[3.516515]  ? amdgpu_pci_probe+0x1c0/0x3d0
[3.516518]  ? pci_device_probe+0xd3/0x170
[3.516520]  ? really_probe+0x13e/0x320
[3.516523]  ? __driver_probe_device+0x91/0xd0
[3.516525]  ? driver_probe_device+0x1a/0x160
[3.516527]  ? __driver_attach+0xe6/0x1b0
[3.516530]  ? bus_add_driver+0x16e/0x270
[3.516533]  ? driver_register+0x85/0x120
[3.516535]  ?
__initstub__kmod_gpu_sched__180_178_drm_sched_fence_slab_init6+0x3f/0x3f
[3.516540]  ? do_one_initcall+0x100/0x290
[3.516545]  ? do_initcall_level+0x8a/0xe8
[3.516549]  ? do_initcalls+0x44/0x6b
[3.516551]  ? kernel_init_freeable+0xc7/0x10d
[3.516554]  ? rest_init+0xc0/0xc0
[3.516558]  ? kernel_init+0x15/0x140
[3.516561]  ? ret_from_fork+0x22/0x30
[3.516564]  
[3.516565] ---[ end trace  ]---

On Fri, 8 Apr 2022 at 18:27, Pavle Kotarac  wrote:
>
> From: Oliver Logush 
>
> [why]
> Make sure smu is not busy before sending another request, this is to
> prevent stress failures from MS.
>
> [how]
> Check to make sure the SMU fw busy signal is cleared before sending
> another request
>
> Reviewed-by: Charlene Liu 
> Reviewed-by: Nicholas Kazlauskas 
> Acked-by: Pavle Kotarac 
> Signed-off-by: Oliver Logush 
> ---
>  .../drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c| 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git 
> a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c 
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
> index 8161a6ae410d..30c6f9cd717f 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr_vbios_smu.c
> @@ -94,6 +94,9 @@ static int rn_vbios_smu_send_msg_with_param(struct 
> clk_mgr_internal *clk_mgr,
>  {
> uint32_t result;
>
> +   result = rn_smu_wait_for_response(clk_mgr, 10, 20);
> +   ASSERT(result == VBIOSSMC_Result_OK);
> +
> /* First clear response register */
> REG_WRITE(MP1_SMN_C2PMSG_91, VBIOSSMC_Status_BUSY);
>
> --
> 2.32.0
>

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

Hi

The buddy allocator is still causing me issues in 5.19-rc3
(https://gitlab.freedesktop.org/drm/amd/-/issues/2059)

I'm no longer seeing null pointers though, so I think the bulk move
fix did it's bit

Let me know if there's anything I can help with, now there aren't
freezes I can offer remote access to debug if it'll help

Cheers

Mike

Re: [PATCH] drm/amdgpu: Fix GTT size reporting in amdgpu_ioctl

[Mike Lothian]

On Mon, 13 Jun 2022 at 10:11, Michel Dänzer  wrote:
>
> On 2022-06-11 09:19, Christian König wrote:
> > Am 10.06.22 um 15:54 schrieb Michel Dänzer:
> >> From: Michel Dänzer 
> >>
> >> The commit below changed the TTM manager size unit from pages to
> >> bytes, but failed to adjust the corresponding calculations in
> >> amdgpu_ioctl.
> >>
> >> Fixes: dfa714b88eb0 ("drm/amdgpu: remove GTT accounting v2")
> >> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1930
> >> Bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6642
> >> Signed-off-by: Michel Dänzer 
> >
> > Ah, WTF! You won't believe how long I have been searching for this one.
>
> Don't feel too bad, similar things have happened to me before. :) Even after 
> Marek's GitLab comment got me on the right track, it still took a fair amount 
> of trial, error & head scratching to put this one to bed.
>
>
> --
> Earthling Michel Dänzer|  https://redhat.com
> Libre software enthusiast  | Mesa and Xwayland developer

That's indeed fixed the Tomb Raider / vulkan issue

I'm still seeing some strange warnings and errors on Linus's tree so
I've updated https://gitlab.freedesktop.org/drm/amd/-/issues/1992
https://gitlab.freedesktop.org/drm/amd/-/issues/2034, I'm not sure if
that's Buddy allocator, TTM Bulk moves or a whole new issue

If it's not too late feel free to add my tested by

Re: [PATCH 2/2] Revert "Revert "drm/amdgpu: Ensure that the modifier requested is supported by plane.""

[Mike Lothian]

Hi

I'm seeing the following warning when building agd5f's tree with clang 14:

drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:4940:6:
warning: unused variable 'i' [-Wunused-variable]
   int i;
   ^
1 warning generated.

Which points to this revert

On Mon, 10 May 2021 at 18:43, youling 257  wrote:
>
> 05-10 17:18:46.509 0 0 I : [drm] amdgpu kernel
> modesetting enabled.
> 05-10 17:18:46.510 0 0 I amdgpu  : Topology: Add APU node [0x0:0x0]
> 05-10 17:18:46.510 0 0 D : checking generic (e000
> fa) vs hw (e000 1000)
> 05-10 17:18:46.510 0 0 I fb0 : switching to amdgpudrmfb from EFI 
> VGA
> 05-10 17:18:46.510 0 0 I Console : switching to colour dummy
> device 80x25
> 05-10 17:18:46.510 0 0 I amdgpu : 0b:00.0: vgaarb:
> deactivate vga console
> 05-10 17:18:46.510 0 0 I : [drm] initializing kernel
> modesetting (RAVEN 0x1002:0x15D8 0x1002:0x15D8 0xC8).
> 05-10 17:18:46.510 0 0 I amdgpu : 0b:00.0: amdgpu: Trusted
> Memory Zone (TMZ) feature enabled
> 05-10 17:18:46.510 0 0 I : [drm] register mmio base: 
> 0xFC90
> 05-10 17:18:46.510 0 0 I : [drm] register mmio size: 524288
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 0
> 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 1
> 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 2
> 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 3 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 4
> 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 5
> 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 6
> 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 7 
> 05-10 17:18:46.510 0 0 I : [drm] add ip block number 8
> 
> 05-10 17:18:46.533 0 0 I : [drm] BIOS signature incorrect 0 0
> 05-10 17:18:46.533 0 0 I amdgpu : 0b:00.0: amdgpu: Fetched
> VBIOS from ROM BAR
> 05-10 17:18:46.533 0 0 I amdgpu  : ATOM BIOS: 113-PICASSO-115
> 05-10 17:18:46.534 0 0 I : [drm] VCN decode is enabled
> in VM mode
> 05-10 17:18:46.534 0 0 I : [drm] VCN encode is enabled
> in VM mode
> 05-10 17:18:46.534 0 0 I : [drm] JPEG decode is
> enabled in VM mode
> 05-10 17:18:46.534 0 0 I : [drm] vm size is 262144 GB,
> 4 levels, block size is 9-bit, fragment size is 9-bit
> 05-10 17:18:46.534 0 0 I amdgpu : 0b:00.0: amdgpu: VRAM:
> 64M 0x00F4 - 0x00F403FF (64M used)
> 05-10 17:18:46.534 0 0 I amdgpu : 0b:00.0: amdgpu: GART:
> 1024M 0x - 0x3FFF
> 05-10 17:18:46.534 0 0 I amdgpu : 0b:00.0: amdgpu: AGP:
> 267419648M 0x00F8 - 0x
> 05-10 17:18:46.534 0 0 I : [drm] Detected VRAM RAM=64M, 
> BAR=64M
> 05-10 17:18:46.534 0 0 I : [drm] RAM width 64bits DDR4
> 05-10 17:18:46.534 0 0 I [drm] amdgpu: 64M of VRAM memory ready
> 05-10 17:18:46.534 0 0 I [drm] amdgpu: 3072M of GTT memory ready.
> 05-10 17:18:46.534 0 0 I [drm] GART: num cpu pages 262144, num
> gpu pages 262144
> 05-10 17:18:46.534 0 0 I : [drm] PCIE GART of 1024M enabled.
> 05-10 17:18:46.534 0 0 I : [drm] PTB located at
> 0x00F400FA
> 05-10 17:18:46.536 0 0 I amdgpu  : hwmgr_sw_init smu backed is 
> smu10_smu
> 05-10 17:18:46.536 0 0 D [drm:dm_sw_init [amdgpu]] dm: DMCU
> firmware not found
> 05-10 17:18:46.537 0 0 I : [drm] Found VCN firmware
> Version ENC: 1.12 DEC: 2 VEP: 0 Revision: 1
> 05-10 17:18:46.537 0 0 I : [drm] PSP loading VCN firmware
> 05-10 17:18:46.558 0 0 I : [drm] reserve 0x40 from
> 0xf403c0 for PSP TMR
> 05-10 17:18:46.567 0 0 I iwlwifi : 07:00.0: base HW
> address: e0:d4:e8:48:f5:67
> 05-10 17:18:46.615 0 0 I amdgpu : 0b:00.0: amdgpu: RAS:
> optional ras ta ucode is not available
> 05-10 17:18:46.620 0 0 I amdgpu : 0b:00.0: amdgpu: RAP:
> optional rap ta ucode is not available
> 05-10 17:18:46.620 0 0 I amdgpu : 0b:00.0: amdgpu:
> SECUREDISPLAY: securedisplay ta ucode is not available
> 05-10 17:18:46.622 0 0 I : [drm] kiq ring mec 2 pipe 1 q 0
> 05-10 17:18:46.622 0 0 D : [drm:amdgpu_dm_irq_init
> [amdgpu]] DM_IRQ
> 05-10 17:18:46.622 0 0 D :
> [drm:dal_firmware_parser_init_cmd_tbl [amdgpu]] Don't have
> set_crtc_timing for v1
> 05-10 17:18:46.623 0 0 I [drm] DM_PPLIB: values for F clock
> 05-10 17:18:46.623 0 0 I [drm] DM_PPLIB: 40 in kHz, 3099 in mV
> 05-10 17:18:46.623 0 0 I [drm] DM_PPLIB: 933000 in kHz, 3574 in mV
> 05-10 17:18:46.623 0 0 I [drm] DM_PPLIB: 120 

Re: [PATCH] drm/amdgpu: Fix GTT size reporting in amdgpu_ioctl

[Mike Lothian]

Thanks for finding this

I'll have access to my machine on Monday and will close those issues off
once I've tested things

Cheers

Mike

On Sat, 11 Jun 2022, 09:19 Christian König, <
ckoenig.leichtzumer...@gmail.com> wrote:

> Am 10.06.22 um 15:54 schrieb Michel Dänzer:
> > From: Michel Dänzer 
> >
> > The commit below changed the TTM manager size unit from pages to
> > bytes, but failed to adjust the corresponding calculations in
> > amdgpu_ioctl.
> >
> > Fixes: dfa714b88eb0 ("drm/amdgpu: remove GTT accounting v2")
> > Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1930
> > Bug: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6642
> > Signed-off-by: Michel Dänzer 
>
> Ah, WTF! You won't believe how long I have been searching for this one.
>
> Reviewed-by: Christian König 
>
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 --
> >   1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > index 801f6fa692e9..6de63ea6687e 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> > @@ -642,7 +642,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
> >   atomic64_read(>visible_pin_size),
> >   vram_gtt.vram_size);
> >   vram_gtt.gtt_size = ttm_manager_type(>mman.bdev,
> TTM_PL_TT)->size;
> > - vram_gtt.gtt_size *= PAGE_SIZE;
> >   vram_gtt.gtt_size -= atomic64_read(>gart_pin_size);
> >   return copy_to_user(out, _gtt,
> >   min((size_t)size, sizeof(vram_gtt))) ?
> -EFAULT : 0;
> > @@ -675,7 +674,6 @@ int amdgpu_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
> >   mem.cpu_accessible_vram.usable_heap_size * 3 / 4;
> >
> >   mem.gtt.total_heap_size = gtt_man->size;
> > - mem.gtt.total_heap_size *= PAGE_SIZE;
> >   mem.gtt.usable_heap_size = mem.gtt.total_heap_size -
> >   atomic64_read(>gart_pin_size);
> >   mem.gtt.heap_usage = ttm_resource_manager_usage(gtt_man);
>
>

Re: [PATCH] drm/ttm: fix bulk move handling during resource init

[Mike Lothian]

The Null pointer against drm-next:

Jun 02 19:59:50 axion.fireburn.co.uk kernel: BUG: kernel NULL pointer
dereference, address: 00d8
Jun 02 19:59:50 axion.fireburn.co.uk kernel: #PF: supervisor read
access in kernel mode
Jun 02 19:59:50 axion.fireburn.co.uk kernel: #PF: error_code(0x) -
not-present page
Jun 02 19:59:50 axion.fireburn.co.uk kernel: PGD 118700067 P4D
118700067 PUD 11f116067 PMD 0
Jun 02 19:59:50 axion.fireburn.co.uk kernel: Oops:  [#1] PREEMPT SMP NOPTI
Jun 02 19:59:50 axion.fireburn.co.uk kernel: CPU: 4 PID: 1029 Comm:
GravityMark.x64 Tainted: GW 5.18.0-rc5-drm+ #1070
Jun 02 19:59:50 axion.fireburn.co.uk kernel: Hardware name: ASUSTeK
COMPUTER INC. ROG Strix G513QY_G513QY/G513QY, BIOS G513QY.318
03/29/2022
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RIP:
0010:ttm_device_swapout+0x6a/0x3d0
Jun 02 19:59:50 axion.fireburn.co.uk kernel: Code: 85 ed 74 51 80 7d
01 00 74 4b 48 89 e6 48 89 ef e8 7b dd ff ff 48 85 c0 74 3b 48 89 c3
49 89 e6 48 8b 7b 30 4c 89 ee 44 89 e2 <4c> 8b bf d8 00 00 00 e8 fa a5
>
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RSP:
:8881605dfc70 EFLAGS: 00010282
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RAX: 888104f85ac8
RBX: 888104f85ac8 RCX: 
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RDX: 0cc0
RSI: 8881605dfd50 RDI: 
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RBP: 888104f85140
R08: 888101566240 R09: 88814e57b880
Jun 02 19:59:50 axion.fireburn.co.uk kernel: R10: 0063
R11: 818238a0 R12: 0cc0
Jun 02 19:59:50 axion.fireburn.co.uk kernel: R13: 8881605dfd50
R14: 8881605dfc70 R15: 00691000
Jun 02 19:59:50 axion.fireburn.co.uk kernel: FS:
7f4623fb9740() GS:888fde50()
knlGS:
Jun 02 19:59:50 axion.fireburn.co.uk kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Jun 02 19:59:50 axion.fireburn.co.uk kernel: CR2: 00d8
CR3: 000102e3c000 CR4: 00150ee0
Jun 02 19:59:50 axion.fireburn.co.uk kernel: Call Trace:
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? ttm_global_swapout+0xae/0xc0
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? ttm_tt_populate+0x7d/0x130
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ?
ttm_bo_vm_fault_reserved+0x237/0x270
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? amdgpu_gem_fault+0x92/0xd0
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? do_fault+0x28e/0x4b0
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? handle_mm_fault+0x849/0xa80
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? amdgpu_drm_ioctl+0x68/0x80
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? do_user_addr_fault+0x275/0x450
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? asm_exc_page_fault+0x9/0x30
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? exc_page_fault+0x5f/0x150
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  ? asm_exc_page_fault+0x1f/0x30
Jun 02 19:59:50 axion.fireburn.co.uk kernel:  
Jun 02 19:59:50 axion.fireburn.co.uk kernel: Modules linked in:
Jun 02 19:59:50 axion.fireburn.co.uk kernel: CR2: 00d8
Jun 02 19:59:50 axion.fireburn.co.uk kernel: ---[ end trace
 ]---
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RIP:
0010:ttm_device_swapout+0x6a/0x3d0
Jun 02 19:59:50 axion.fireburn.co.uk kernel: Code: 85 ed 74 51 80 7d
01 00 74 4b 48 89 e6 48 89 ef e8 7b dd ff ff 48 85 c0 74 3b 48 89 c3
49 89 e6 48 8b 7b 30 4c 89 ee 44 89 e2 <4c> 8b bf d8 00 00 00 e8 fa a5
>
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RSP:
:8881605dfc70 EFLAGS: 00010282
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RAX: 888104f85ac8
RBX: 888104f85ac8 RCX: 
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RDX: 0cc0
RSI: 8881605dfd50 RDI: 
Jun 02 19:59:50 axion.fireburn.co.uk kernel: RBP: 888104f85140
R08: 888101566240 R09: 88814e57b880
Jun 02 19:59:50 axion.fireburn.co.uk kernel: R10: 0063
R11: 818238a0 R12: 0cc0
Jun 02 19:59:50 axion.fireburn.co.uk kernel: R13: 8881605dfd50
R14: 8881605dfc70 R15: 00691000
Jun 02 19:59:50 axion.fireburn.co.uk kernel: FS:
7f4623fb9740() GS:888fde50()
knlGS:
Jun 02 19:59:50 axion.fireburn.co.uk kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Jun 02 19:59:50 axion.fireburn.co.uk kernel: CR2: 00d8
CR3: 000102e3c000 CR4: 00150ee0
Jun 02 19:59:50 axion.fireburn.co.uk kernel: note:
GravityMark.x64[1029] exited with preempt_count 1

On Thu, 2 Jun 2022 at 19:55, Christian König
 wrote:
>
> That's because drm-misc-next is currently broken and needs a backmerge.
>
> Please try this patch on top of drm-next.
>
> Regards,
> Christian.
>
> Am 02.06.22 um 20:08 schrieb Mike Lothian:
> > Hi
> >
> > I'm still seeing Null pointers against Linus's

Re: [PATCH] drm/ttm: fix bulk move handling during resource init

[Mike Lothian]

Here's the output from drm-misc too:

Jun 02 19:05:32 axion.fireburn.co.uk kernel: BUG: kernel NULL pointer
dereference, address: 00d8
Jun 02 19:05:32 axion.fireburn.co.uk kernel: #PF: supervisor read
access in kernel mode
Jun 02 19:05:32 axion.fireburn.co.uk kernel: #PF: error_code(0x) -
not-present page
Jun 02 19:05:32 axion.fireburn.co.uk kernel: PGD 11dfbb067 P4D
11dfbb067 PUD 170cd7067 PMD 0
Jun 02 19:05:32 axion.fireburn.co.uk kernel: Oops:  [#1] PREEMPT SMP NOPTI
Jun 02 19:05:32 axion.fireburn.co.uk kernel: CPU: 1 PID: 1040 Comm:
GravityMark.x64 Tainted: GW 5.18.0-rc5-misc+ #10
Jun 02 19:05:32 axion.fireburn.co.uk kernel: Hardware name: ASUSTeK
COMPUTER INC. ROG Strix G513QY_G513QY/G513QY, BIOS G513QY.318
03/29/2022
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RIP:
0010:ttm_device_swapout+0x6a/0x3d0
Jun 02 19:05:32 axion.fireburn.co.uk kernel: Code: 85 ed 74 51 80 7d
01 00 74 4b 48 89 e6 48 89 ef e8 7b dd ff ff 48 85 c0 74 3b 48 89 c3
49 89 e6 48 8b 7b 30 4c 89 ee 44 89 e2 <4c> 8b bf d8 00 00 00 e8 fa a5
>
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RSP:
:888125a17c70 EFLAGS: 00010286
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RAX: 888104f45aa0
RBX: 888104f45aa0 RCX: 
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RDX: 0cc0
RSI: 888125a17d50 RDI: 
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RBP: 888104f45118
R08: 88812278da68 R09: 888102eaa680
Jun 02 19:05:32 axion.fireburn.co.uk kernel: R10: 0063
R11: 818212a0 R12: 0cc0
Jun 02 19:05:32 axion.fireburn.co.uk kernel: R13: 888125a17d50
R14: 888125a17c70 R15: 00691000
Jun 02 19:05:32 axion.fireburn.co.uk kernel: FS:
7fd9e0671740() GS:888fde44()
knlGS:
Jun 02 19:05:32 axion.fireburn.co.uk kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Jun 02 19:05:32 axion.fireburn.co.uk kernel: CR2: 00d8
CR3: 000125c5a000 CR4: 00150ee0
Jun 02 19:05:32 axion.fireburn.co.uk kernel: Call Trace:
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? ttm_global_swapout+0xae/0xc0
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? ttm_tt_populate+0x7d/0x130
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ?
ttm_bo_vm_fault_reserved+0x237/0x270
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? amdgpu_gem_fault+0x92/0xd0
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? do_fault+0x28e/0x4b0
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? handle_mm_fault+0x849/0xa80
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? do_user_addr_fault+0x275/0x450
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? asm_exc_page_fault+0x9/0x30
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? exc_page_fault+0x5f/0x150
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  ? asm_exc_page_fault+0x1f/0x30
Jun 02 19:05:32 axion.fireburn.co.uk kernel:  
Jun 02 19:05:32 axion.fireburn.co.uk kernel: Modules linked in:
Jun 02 19:05:32 axion.fireburn.co.uk kernel: CR2: 00d8
Jun 02 19:05:32 axion.fireburn.co.uk kernel: ---[ end trace
 ]---
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RIP:
0010:ttm_device_swapout+0x6a/0x3d0
Jun 02 19:05:32 axion.fireburn.co.uk kernel: Code: 85 ed 74 51 80 7d
01 00 74 4b 48 89 e6 48 89 ef e8 7b dd ff ff 48 85 c0 74 3b 48 89 c3
49 89 e6 48 8b 7b 30 4c 89 ee 44 89 e2 <4c> 8b bf d8 00 00 00 e8 fa a5
>
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RSP:
:888125a17c70 EFLAGS: 00010286
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RAX: 888104f45aa0
RBX: 888104f45aa0 RCX: 
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RDX: 0cc0
RSI: 888125a17d50 RDI: 
Jun 02 19:05:32 axion.fireburn.co.uk kernel: RBP: 888104f45118
R08: 88812278da68 R09: 888102eaa680
Jun 02 19:05:32 axion.fireburn.co.uk kernel: R10: 0063
R11: 818212a0 R12: 0cc0
Jun 02 19:05:32 axion.fireburn.co.uk kernel: R13: 888125a17d50
R14: 888125a17c70 R15: 00691000
Jun 02 19:05:32 axion.fireburn.co.uk kernel: FS:
7fd9e0671740() GS:888fde44()
knlGS:
Jun 02 19:05:32 axion.fireburn.co.uk kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Jun 02 19:05:32 axion.fireburn.co.uk kernel: CR2: 00d8
CR3: 000125c5a000 CR4: 00150ee0
Jun 02 19:05:32 axion.fireburn.co.uk kernel: note:
GravityMark.x64[1040] exited with preempt_count 1

On Thu, 2 Jun 2022 at 19:08, Mike Lothian  wrote:
>
> Hi
>
> I'm still seeing Null pointers against Linus's tree and drm-misc with this 
> patch
>
> Jun 02 19:04:05 axion.fireburn.co.uk kernel: BUG: kernel NULL pointer
> dereference, address: 0008
> Jun 02 19:04:05 axion.fireburn.co.uk kernel: #PF: supervisor write
> access in kernel mode
> Jun 02 19:04:05 axion.fireburn.co.uk kernel: #PF: error_

Re: [PATCH] drm/ttm: fix bulk move handling during resource init

[Mike Lothian]

Hi

I'm still seeing Null pointers against Linus's tree and drm-misc with this patch

Jun 02 19:04:05 axion.fireburn.co.uk kernel: BUG: kernel NULL pointer
dereference, address: 0008
Jun 02 19:04:05 axion.fireburn.co.uk kernel: #PF: supervisor write
access in kernel mode
Jun 02 19:04:05 axion.fireburn.co.uk kernel: #PF: error_code(0x0002) -
not-present page
Jun 02 19:04:05 axion.fireburn.co.uk kernel: PGD 11ee04067 P4D
11ee04067 PUD 15eccb067 PMD 0
Jun 02 19:04:05 axion.fireburn.co.uk kernel: Oops: 0002 [#1] PREEMPT SMP NOPTI
Jun 02 19:04:05 axion.fireburn.co.uk kernel: CPU: 0 PID: 1021 Comm:
GravityMark.x64 Tainted: GW 5.18.0-tip+ #3177
Jun 02 19:04:05 axion.fireburn.co.uk kernel: Hardware name: ASUSTeK
COMPUTER INC. ROG Strix G513QY_G513QY/G513QY, BIOS G513QY.318
03/29/2022
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RIP:
0010:ttm_resource_init+0x108/0x210
Jun 02 19:04:05 axion.fireburn.co.uk kernel: Code: 48 8b 74 0a 08 48
39 de 0f 84 82 00 00 00 48 8b 7b 38 4c 8b 4b 40 4c 8d 44 0a 08 48 8d
56 38 4c 89 4f 08 49 89 39 48 8b 4e 38 <48> 89 41 08 48 89 4b 38 48 89
>
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RSP:
0018:888112e73918 EFLAGS: 00010202
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RAX: 888206b715d8
RBX: 888206b715a0 RCX: 
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RDX: 888206b71cf8
RSI: 888206b71cc0 RDI: 888110605b00
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RBP: 88816c848c08
R08: 88812235c790 R09: 8881306a4bd8
Jun 02 19:04:05 axion.fireburn.co.uk kernel: R10: 
R11: 81851320 R12: 888110605ad0
Jun 02 19:04:05 axion.fireburn.co.uk kernel: R13: 888206b715a0
R14: 88816c848c58 R15: 888110605ad0
Jun 02 19:04:05 axion.fireburn.co.uk kernel: FS:
7f4c257c1740() GS:888fde40()
knlGS:
Jun 02 19:04:05 axion.fireburn.co.uk kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Jun 02 19:04:05 axion.fireburn.co.uk kernel: CR2: 0008
CR3: 0001183fc000 CR4: 00350ef0
Jun 02 19:04:05 axion.fireburn.co.uk kernel: Call Trace:
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? amdgpu_vram_mgr_new+0xbb/0x4b0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? ttm_bo_mem_space+0x89/0x1e0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? ttm_bo_validate+0x80/0x1a0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? amdgpu_cs_bo_validate+0xe9/0x2b0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ?
amdgpu_syncobj_lookup_and_add_to_sync+0xa0/0xa0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ?
amdgpu_vm_validate_pt_bos+0xce/0x1c0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? amdgpu_cs_parser_bos+0x522/0x6e0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? amdgpu_cs_ioctl+0x7fe/0xd00
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ?
amdgpu_cs_report_moved_bytes+0x60/0x60
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? drm_ioctl_kernel+0xcb/0x130
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? drm_ioctl+0x2f5/0x400
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ?
amdgpu_cs_report_moved_bytes+0x60/0x60
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? amdgpu_drm_ioctl+0x42/0x80
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? __x64_sys_ioctl+0x5e/0xa0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ? do_syscall_64+0x6a/0x90
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ?
exit_to_user_mode_prepare+0x19/0x90
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  ?
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Jun 02 19:04:05 axion.fireburn.co.uk kernel:  
Jun 02 19:04:05 axion.fireburn.co.uk kernel: Modules linked in:
Jun 02 19:04:05 axion.fireburn.co.uk kernel: CR2: 0008
Jun 02 19:04:05 axion.fireburn.co.uk kernel: ---[ end trace
 ]---
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RIP:
0010:ttm_resource_init+0x108/0x210
Jun 02 19:04:05 axion.fireburn.co.uk kernel: Code: 48 8b 74 0a 08 48
39 de 0f 84 82 00 00 00 48 8b 7b 38 4c 8b 4b 40 4c 8d 44 0a 08 48 8d
56 38 4c 89 4f 08 49 89 39 48 8b 4e 38 <48> 89 41 08 48 89 4b 38 48 89
>
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RSP:
0018:888112e73918 EFLAGS: 00010202
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RAX: 888206b715d8
RBX: 888206b715a0 RCX: 
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RDX: 888206b71cf8
RSI: 888206b71cc0 RDI: 888110605b00
Jun 02 19:04:05 axion.fireburn.co.uk kernel: RBP: 88816c848c08
R08: 88812235c790 R09: 8881306a4bd8
Jun 02 19:04:05 axion.fireburn.co.uk kernel: R10: 
R11: 81851320 R12: 888110605ad0
Jun 02 19:04:05 axion.fireburn.co.uk kernel: R13: 888206b715a0
R14: 88816c848c58 R15: 888110605ad0
Jun 02 19:04:05 axion.fireburn.co.uk kernel: FS:
7f4c257c1740() GS:888fde40()
knlGS:
Jun 02 19:04:05 axion.fireburn.co.uk kernel: CS:  0010 DS:  ES:
 CR0: 80050033
Jun 02 19:04:05 

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

On Sat, 28 May 2022 at 08:44, Paneer Selvam, Arunpravin
 wrote:
>
> [Public]
>
> Hi,
>
> After investigating quite some time on this issue, found freeze problem is 
> not with the amdgpu part of buddy allocator patch as the patch doesn’t throw 
> any issues when applied separately on top of the stable base of drm-next. 
> After digging more into this issue, the below patch seems to be the cause of 
> this problem,
>
> drm/ttm: rework bulk move handling v5
> https://cgit.freedesktop.org/drm/drm/commit/?id=fee2ede155423b0f7a559050a39750b98fe9db69
>
> when this patch applied on top of the stable (working version) of drm-next 
> without buddy allocator patch, we can see multiple issues listed below, each 
> thrown randomly at every GravityMark run, 1. general protection fault at 
> ttm_lru_bulk_move_tail() 2. NULL pointer deference at 
> ttm_lru_bulk_move_tail() 3. NULL pointer deference at ttm_resource_init().
>
> Regards,
> Arun.

Thanks for tracking it down, fee2ede155423b0f7a559050a39750b98fe9db69
isn't trivial to revert

Hopefully Christian can figure it out

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

Hi

The merge window for 5.19 will probably be opening next week, has
there been any progress with this bug?

Thanks

Mike

On Mon, 2 May 2022 at 17:31, Mike Lothian  wrote:
>
> On Mon, 2 May 2022 at 16:54, Arunpravin Paneer Selvam
>  wrote:
> >
> >
> >
> > On 5/2/2022 8:41 PM, Mike Lothian wrote:
> > > On Wed, 27 Apr 2022 at 12:55, Mike Lothian  wrote:
> > >> On Tue, 26 Apr 2022 at 17:36, Christian König  
> > >> wrote:
> > >>> Hi Mike,
> > >>>
> > >>> sounds like somehow stitching together the SG table for PRIME doesn't
> > >>> work any more with this patch.
> > >>>
> > >>> Can you try with P2P DMA disabled?
> > >> -CONFIG_PCI_P2PDMA=y
> > >> +# CONFIG_PCI_P2PDMA is not set
> > >>
> > >> If that's what you're meaning, then there's no difference, I'll upload
> > >> my dmesg to the gitlab issue
> > >>
> > >>> Apart from that can you take a look Arun?
> > >>>
> > >>> Thanks,
> > >>> Christian.
> > > Hi
> > >
> > > Have you had any success in replicating this?
> > Hi Mike,
> > I couldn't replicate on my Raven APU machine. I see you have 2 cards
> > initialized, one is Renoir
> > and the other is Navy Flounder. Could you give some more details, are
> > you running Gravity Mark
> > on Renoir and what is your system RAM configuration?
> > >
> > > Cheers
> > >
> > > Mike
> >
> Hi
>
> It's a PRIME laptop, it failed on the RENOIR too, it caused a lockup,
> but systemd managed to capture it, I'll attach it to the issue
>
> I've got 64GB RAM, the 6800M has 12GB VRAM
>
> Cheers
>
> Mike

[PATCH v2 0/2] drm/amdgpu: Fix a couple of clang warnings

[Mike Lothian]

The 3rd patch from the previous series was already applied

This reworks the other two based on Alex's comments

Mike Lothian (2):
  drm/amdgpu/gfx10: Avoid uninitialised variable 'index'
  drm/amdgpu/gfx11: Avoid uninitialised variable 'index'

 drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 3 ++-
 drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.35.1

[PATCH 1/2] drm/amdgpu/gfx10: Avoid uninitialised variable 'index'

[Mike Lothian]

This stops clang complaining:

drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3846:6: warning: variable 'index' is 
used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (ring->is_mes_queue) {
^~
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3903:30: note: uninitialized use occurs 
here
amdgpu_device_wb_free(adev, index);
^
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3846:2: note: remove the 'if' if its 
condition is always false
if (ring->is_mes_queue) {
^
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:3839:16: note: initialize the variable 
'index' to silence this warning
unsigned index;
  ^
   = 0

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

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index fc289ee54a47..043f8bc37f21 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
@@ -3900,7 +3900,8 @@ static int gfx_v10_0_ring_test_ib(struct amdgpu_ring 
*ring, long timeout)
amdgpu_ib_free(adev, , NULL);
dma_fence_put(f);
 err1:
-   amdgpu_device_wb_free(adev, index);
+   if (!ring->is_mes_queue)
+   amdgpu_device_wb_free(adev, index);
return r;
 }
 
-- 
2.35.1

[PATCH 2/2] drm/amdgpu/gfx11: Avoid uninitialised variable 'index'

[Mike Lothian]

This stops clang complaining:

drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:376:6: warning: variable 'index' is used 
uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (ring->is_mes_queue) {
^~
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:433:30: note: uninitialized use occurs 
here
amdgpu_device_wb_free(adev, index);
^
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:376:2: note: remove the 'if' if its 
condition is always false
if (ring->is_mes_queue) {
^
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c:364:16: note: initialize the variable 
'index' to silence this warning
unsigned index;
  ^
   = 0

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

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
index 141c64636577..c5655128fd9c 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
@@ -430,7 +430,8 @@ static int gfx_v11_0_ring_test_ib(struct amdgpu_ring *ring, 
long timeout)
amdgpu_ib_free(adev, , NULL);
dma_fence_put(f);
 err1:
-   amdgpu_device_wb_free(adev, index);
+   if (!ring->is_mes_queue)
+   amdgpu_device_wb_free(adev, index);
return r;
 }
 
-- 
2.35.1

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

On Mon, 2 May 2022 at 16:54, Arunpravin Paneer Selvam
 wrote:
>
>
>
> On 5/2/2022 8:41 PM, Mike Lothian wrote:
> > On Wed, 27 Apr 2022 at 12:55, Mike Lothian  wrote:
> >> On Tue, 26 Apr 2022 at 17:36, Christian König  
> >> wrote:
> >>> Hi Mike,
> >>>
> >>> sounds like somehow stitching together the SG table for PRIME doesn't
> >>> work any more with this patch.
> >>>
> >>> Can you try with P2P DMA disabled?
> >> -CONFIG_PCI_P2PDMA=y
> >> +# CONFIG_PCI_P2PDMA is not set
> >>
> >> If that's what you're meaning, then there's no difference, I'll upload
> >> my dmesg to the gitlab issue
> >>
> >>> Apart from that can you take a look Arun?
> >>>
> >>> Thanks,
> >>> Christian.
> > Hi
> >
> > Have you had any success in replicating this?
> Hi Mike,
> I couldn't replicate on my Raven APU machine. I see you have 2 cards
> initialized, one is Renoir
> and the other is Navy Flounder. Could you give some more details, are
> you running Gravity Mark
> on Renoir and what is your system RAM configuration?
> >
> > Cheers
> >
> > Mike
>
Hi

It's a PRIME laptop, it failed on the RENOIR too, it caused a lockup,
but systemd managed to capture it, I'll attach it to the issue

I've got 64GB RAM, the 6800M has 12GB VRAM

Cheers

Mike

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

On Wed, 27 Apr 2022 at 12:55, Mike Lothian  wrote:
>
> On Tue, 26 Apr 2022 at 17:36, Christian König  
> wrote:
> >
> > Hi Mike,
> >
> > sounds like somehow stitching together the SG table for PRIME doesn't
> > work any more with this patch.
> >
> > Can you try with P2P DMA disabled?
>
> -CONFIG_PCI_P2PDMA=y
> +# CONFIG_PCI_P2PDMA is not set
>
> If that's what you're meaning, then there's no difference, I'll upload
> my dmesg to the gitlab issue
>
> >
> > Apart from that can you take a look Arun?
> >
> > Thanks,
> > Christian.

Hi

Have you had any success in replicating this?

Cheers

Mike

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

On Tue, 26 Apr 2022 at 17:36, Christian König  wrote:
>
> Hi Mike,
>
> sounds like somehow stitching together the SG table for PRIME doesn't
> work any more with this patch.
>
> Can you try with P2P DMA disabled?

-CONFIG_PCI_P2PDMA=y
+# CONFIG_PCI_P2PDMA is not set

If that's what you're meaning, then there's no difference, I'll upload
my dmesg to the gitlab issue

>
> Apart from that can you take a look Arun?
>
> Thanks,
> Christian.

Re: [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

[Mike Lothian]

Hi

I'm having issues with this patch on my PRIME system and vulkan workloads

https://gitlab.freedesktop.org/drm/amd/-/issues/1992

Is there any chance you could take a look?

Cheers

Mike

Re: [PATCH v8] drm/amdgpu: handle IH ring1 overflow

[Mike Lothian]

On Thu, 25 Nov 2021 at 20:42, Felix Kuehling  wrote:
>
> OK. Dealing with processed timestamp rather than decoded timestamp fixes
> the race condition where drain would have returned before the last fault
> was processed. But we're still assuming that each interrupt has a unique
> timestamp. We haven't seen evidence of the contrary. But I'd like to add
> a check to be sure, in case that assumption becomes invalid on future
> hardware. Something like this (before updating ih->processed_timestamp):
>
> WARN_ONCE(ih->processed_timestamp == entry.timestamp, "IH timestamps
> are not unique");
>
> With that fixed, the patch is
>
> Reviewed-by: Felix Kuehling 
>

Hi,

I'm seeing this on my machine
https://gitlab.freedesktop.org/drm/amd/-/issues/1818

Cheers

Mike

Re: [PATCH 16/27] drm/amd/display: increase Z9 latency to workaround underflow in Z9

[Mike Lothian]

This patch seems to change z8 - not that I know what z8 or z9 are

On Fri, 15 Oct 2021 at 19:44, Agustin Gutierrez
 wrote:
>
> From: Eric Yang 
>
> [Why]
> Z9 latency is higher than when we originally tuned the watermark
> parameters, causing underflow. Increasing the value until the latency
> issues is resolved.
>
> Reviewed-by: Nicholas Kazlauskas 
> Acked-by: Agustin Gutierrez Sanchez 
> Signed-off-by: Eric Yang 
> ---
>  drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c 
> b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
> index c9d3d691f4c6..12ebd9f8912f 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c
> @@ -222,8 +222,8 @@ struct _vcs_dpi_soc_bounding_box_st dcn3_1_soc = {
> .num_states = 5,
> .sr_exit_time_us = 9.0,
> .sr_enter_plus_exit_time_us = 11.0,
> -   .sr_exit_z8_time_us = 402.0,
> -   .sr_enter_plus_exit_z8_time_us = 520.0,
> +   .sr_exit_z8_time_us = 442.0,
> +   .sr_enter_plus_exit_z8_time_us = 560.0,
> .writeback_latency_us = 12.0,
> .dram_channel_width_bytes = 4,
> .round_trip_ping_latency_dcfclk_cycles = 106,
> --
> 2.25.1
>

Re: [PATCH 28/64] drm/amdgpu: drive all navi asics from the IP discovery table

[Mike Lothian]

I've raised a bug with hopefully everything you need

https://gitlab.freedesktop.org/drm/amd/-/issues/1743

On Mon, 11 Oct 2021 at 18:35, Alex Deucher  wrote:
>
> On Mon, Oct 11, 2021 at 1:20 PM Mike Lothian  wrote:
> >
> > Hi
> >
> > This patch breaks things for me on my Green Sardine & Navy Flounder
> > system (Asus ROG G513QY)
> >
> > It doesn't get past post with amdgpu built in, will try as a module
>
> Can you provide the dmesg output in that case?
>
> Alex
>
>
> >
> > Cheers
> >
> > Mike
> >
> > On Tue, 28 Sept 2021 at 17:44, Alex Deucher  
> > wrote:
> > >
> > > Rather than hardcoding based on asic_type, use the IP
> > > discovery table to configure the driver.
> > >
> > > v2: rebase
> > >
> > > Reviewed-by: Christian König 
> > > Signed-off-by: Alex Deucher 
> > > ---
> > >  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 
> > >  1 file changed, 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > index 5e0956b19d69..9c47cc636429 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -2142,26 +2142,6 @@ static int amdgpu_device_ip_early_init(struct 
> > > amdgpu_device *adev)
> > > if (r)
> > > return r;
> > > break;
> > > -   case  CHIP_NAVI14:
> > > -   case  CHIP_NAVI12:
> > > -   case  CHIP_SIENNA_CICHLID:
> > > -   case  CHIP_NAVY_FLOUNDER:
> > > -   case  CHIP_DIMGREY_CAVEFISH:
> > > -   case  CHIP_BEIGE_GOBY:
> > > -   case CHIP_VANGOGH:
> > > -   case CHIP_YELLOW_CARP:
> > > -   case CHIP_CYAN_SKILLFISH:
> > > -   if (adev->asic_type == CHIP_VANGOGH)
> > > -   adev->family = AMDGPU_FAMILY_VGH;
> > > -   else if (adev->asic_type == CHIP_YELLOW_CARP)
> > > -   adev->family = AMDGPU_FAMILY_YC;
> > > -   else
> > > -   adev->family = AMDGPU_FAMILY_NV;
> > > -
> > > -   r = nv_set_ip_blocks(adev);
> > > -   if (r)
> > > -   return r;
> > > -   break;
> > > default:
> > > r = amdgpu_discovery_set_ip_blocks(adev);
> > > if (r)
> > > --
> > > 2.31.1
> > >

Re: [PATCH 28/64] drm/amdgpu: drive all navi asics from the IP discovery table

[Mike Lothian]

Hi

This patch breaks things for me on my Green Sardine & Navy Flounder
system (Asus ROG G513QY)

It doesn't get past post with amdgpu built in, will try as a module

Cheers

Mike

On Tue, 28 Sept 2021 at 17:44, Alex Deucher  wrote:
>
> Rather than hardcoding based on asic_type, use the IP
> discovery table to configure the driver.
>
> v2: rebase
>
> Reviewed-by: Christian König 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 
>  1 file changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 5e0956b19d69..9c47cc636429 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2142,26 +2142,6 @@ static int amdgpu_device_ip_early_init(struct 
> amdgpu_device *adev)
> if (r)
> return r;
> break;
> -   case  CHIP_NAVI14:
> -   case  CHIP_NAVI12:
> -   case  CHIP_SIENNA_CICHLID:
> -   case  CHIP_NAVY_FLOUNDER:
> -   case  CHIP_DIMGREY_CAVEFISH:
> -   case  CHIP_BEIGE_GOBY:
> -   case CHIP_VANGOGH:
> -   case CHIP_YELLOW_CARP:
> -   case CHIP_CYAN_SKILLFISH:
> -   if (adev->asic_type == CHIP_VANGOGH)
> -   adev->family = AMDGPU_FAMILY_VGH;
> -   else if (adev->asic_type == CHIP_YELLOW_CARP)
> -   adev->family = AMDGPU_FAMILY_YC;
> -   else
> -   adev->family = AMDGPU_FAMILY_NV;
> -
> -   r = nv_set_ip_blocks(adev);
> -   if (r)
> -   return r;
> -   break;
> default:
> r = amdgpu_discovery_set_ip_blocks(adev);
> if (r)
> --
> 2.31.1
>

Re: [PATCH v2 11/23] drm/amd/display: Implement DPIA clock recovery phase

[Mike Lothian]

Hi

This patch is giving me a build error with Werror when building with Clang-13

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:195:2:
error: variable 'ts' is used uninitialized whenever switch default is
taken [-Werror,-Wsometimes-uninitialized]

default:

^~~

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:200:9:
note: uninitialized use occurs here

return ts;

   ^~

drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dpia.c:180:2:
note: variable 'ts' is declared here

enum dpia_set_config_ts ts;

^

1 error generated.

Cheers

Mike


On Tue, 5 Oct 2021 at 08:57, Wayne Lin  wrote:
>
> From: Jimmy Kizito 
>
> [Why]
> Clock recovery is the mandatory first phase of DP link training.
>
> [How]
> - Implement clock recovery phase in DPIA training module.
> - Add helper functions for building SET_CONFIG messages.
>
> Reviewed-by: Jun Lei 
> Acked-by: Wayne Lin 
> Acked-by: Nicholas Kazlauskas 
> Signed-off-by: Jimmy Kizito 
> ---
>  .../drm/amd/display/dc/core/dc_link_dpia.c| 420 +-
>  .../gpu/drm/amd/display/dc/inc/dc_link_dpia.h |  40 ++
>  2 files changed, 453 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dpia.c 
> b/drivers/gpu/drm/amd/display/dc/core/dc_link_dpia.c
> index 5ffaf6ca372b..9608fd345936 100644
> --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dpia.c
> +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dpia.c
> @@ -28,6 +28,9 @@
>  #include "inc/core_status.h"
>  #include "dc_link.h"
>  #include "dc_link_dp.h"
> +#include "dpcd_defs.h"
> +#include "link_hwss.h"
> +#include "inc/link_dpcd.h"
>
>  #define DC_LOGGER \
> link->ctx->logger
> @@ -87,17 +90,385 @@ static enum link_training_result 
> dpia_configure_link(struct dc_link *link,
> return LINK_TRAINING_SUCCESS;
>  }
>
> +static enum dc_status core_link_send_set_config(struct dc_link *link,
> +   uint8_t msg_type, uint8_t msg_data)
> +{
> +   /** @todo Implement */
> +   return DC_OK;
> +}
> +
> +/* Build SET_CONFIG message data payload for specified message type. */
> +static uint8_t dpia_build_set_config_data(enum dpia_set_config_type type,
> +   struct dc_link *link,
> +   struct link_training_settings *lt_settings)
> +{
> +   union dpia_set_config_data data;
> +
> +   data.raw = 0;
> +
> +   switch (type) {
> +   case DPIA_SET_CFG_SET_LINK:
> +   data.set_link.mode = link->lttpr_mode == 
> LTTPR_MODE_NON_TRANSPARENT ? 1 : 0;
> +   break;
> +   case DPIA_SET_CFG_SET_PHY_TEST_MODE:
> +   break;
> +   case DPIA_SET_CFG_SET_VSPE:
> +   /* Assume all lanes have same drive settings. */
> +   data.set_vspe.swing = 
> lt_settings->lane_settings[0].VOLTAGE_SWING;
> +   data.set_vspe.pre_emph = 
> lt_settings->lane_settings[0].PRE_EMPHASIS;
> +   data.set_vspe.max_swing_reached =
> +   lt_settings->lane_settings[0].VOLTAGE_SWING == 
> VOLTAGE_SWING_MAX_LEVEL ? 1 : 0;
> +   data.set_vspe.max_pre_emph_reached =
> +   lt_settings->lane_settings[0].PRE_EMPHASIS == 
> PRE_EMPHASIS_MAX_LEVEL ? 1 : 0;
> +   break;
> +   default:
> +   ASSERT(false); /* Message type not supported by helper 
> function. */
> +   break;
> +   }
> +
> +   return data.raw;
> +}
> +
> +/* Convert DC training pattern to DPIA training stage. */
> +static enum dpia_set_config_ts convert_trng_ptn_to_trng_stg(enum 
> dc_dp_training_pattern tps)
> +{
> +   enum dpia_set_config_ts ts;
> +
> +   switch (tps) {
> +   case DP_TRAINING_PATTERN_SEQUENCE_1:
> +   ts = DPIA_TS_TPS1;
> +   break;
> +   case DP_TRAINING_PATTERN_SEQUENCE_2:
> +   ts = DPIA_TS_TPS2;
> +   break;
> +   case DP_TRAINING_PATTERN_SEQUENCE_3:
> +   ts = DPIA_TS_TPS3;
> +   break;
> +   case DP_TRAINING_PATTERN_SEQUENCE_4:
> +   ts = DPIA_TS_TPS4;
> +   break;
> +   default:
> +   ASSERT(false); /* TPS not supported by helper function. */
> +   break;
> +   }
> +
> +   return ts;
> +}
> +
> +/* Write training pattern to DPCD. */
> +static enum dc_status dpcd_set_lt_pattern(struct dc_link *link,
> +   enum dc_dp_training_pattern pattern,
> +   uint32_t hop)
> +{
> +   union dpcd_training_pattern dpcd_pattern = { {0} };
> +   uint32_t dpcd_tps_offset = DP_TRAINING_PATTERN_SET;
> +   enum dc_status status;
> +
> +   if (hop != DPRX)
> +   dpcd_tps_offset = DP_TRAINING_PATTERN_SET_PHY_REPEATER1 +
> +   ((DP_REPEATER_CONFIGURATION_AND_STATUS_SIZE) * (hop - 
> 1));
> +
> +   /* DpcdAddress_TrainingPatternSet */
> +   dpcd_pattern.v1_4.TRAINING_PATTERN_SET =
> +   

Re: [PATCH] drm/amdkfd: avoid conflicting address mappings

[Mike Lothian]

Hi

This patch is causing a compile failure for me

drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_chardev.c:1254:25: error:
unused variable 'svms' [-Werror,-Wunused-variable]
   struct svm_range_list *svms = >svms;
  ^
1 error generated.

I'll turn off Werror

On Mon, 19 Jul 2021 at 22:19, Alex Sierra  wrote:
>
> [Why]
> Avoid conflict with address ranges mapped by SVM
> mechanism that try to be allocated again through
> ioctl_alloc in the same process. And viceversa.
>
> [How]
> For ioctl_alloc_memory_of_gpu allocations
> Check if the address range passed into ioctl memory
> alloc does not exist already in the kfd_process
> svms->objects interval tree.
>
> For SVM allocations
> Look for the address range into the interval tree VA from
> the VM inside of each pdds used in a kfd_process.
>
> Signed-off-by: Alex Sierra 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 13 
>  drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 79 +++-
>  2 files changed, 75 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index 67541c30327a..f39baaa22a62 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -1251,6 +1251,7 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file 
> *filep,
> struct kfd_process_device *pdd;
> void *mem;
> struct kfd_dev *dev;
> +   struct svm_range_list *svms = >svms;
> int idr_handle;
> long err;
> uint64_t offset = args->mmap_offset;
> @@ -1259,6 +1260,18 @@ static int kfd_ioctl_alloc_memory_of_gpu(struct file 
> *filep,
> if (args->size == 0)
> return -EINVAL;
>
> +#if IS_ENABLED(CONFIG_HSA_AMD_SVM)
> +   mutex_lock(>lock);
> +   if (interval_tree_iter_first(>objects,
> +args->va_addr >> PAGE_SHIFT,
> +(args->va_addr + args->size - 1) >> 
> PAGE_SHIFT)) {
> +   pr_err("Address: 0x%llx already allocated by SVM\n",
> +   args->va_addr);
> +   mutex_unlock(>lock);
> +   return -EADDRINUSE;
> +   }
> +   mutex_unlock(>lock);
> +#endif
> dev = kfd_device_by_id(args->gpu_id);
> if (!dev)
> return -EINVAL;
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> index 31f3f24cef6a..043ee0467916 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> @@ -2581,9 +2581,54 @@ int svm_range_list_init(struct kfd_process *p)
> return 0;
>  }
>
> +/**
> + * svm_range_is_vm_bo_mapped - check if virtual address range mapped already
> + * @p: current kfd_process
> + * @start: range start address, in pages
> + * @last: range last address, in pages
> + *
> + * The purpose is to avoid virtual address ranges already allocated by
> + * kfd_ioctl_alloc_memory_of_gpu ioctl.
> + * It looks for each pdd in the kfd_process.
> + *
> + * Context: Process context
> + *
> + * Return 0 - OK, if the range is not mapped.
> + * Otherwise error code:
> + * -EADDRINUSE - if address is mapped already by 
> kfd_ioctl_alloc_memory_of_gpu
> + * -ERESTARTSYS - A wait for the buffer to become unreserved was interrupted 
> by
> + * a signal. Release all buffer reservations and return to user-space.
> + */
> +static int
> +svm_range_is_vm_bo_mapped(struct kfd_process *p, uint64_t start, uint64_t 
> last)
> +{
> +   uint32_t i;
> +   int r;
> +
> +   for (i = 0; i < p->n_pdds; i++) {
> +   struct amdgpu_vm *vm;
> +
> +   if (!p->pdds[i]->drm_priv)
> +   continue;
> +
> +   vm = drm_priv_to_vm(p->pdds[i]->drm_priv);
> +   r = amdgpu_bo_reserve(vm->root.bo, false);
> +   if (r)
> +   return r;
> +   if (interval_tree_iter_first(>va, start, last)) {
> +   pr_debug("Range [0x%llx 0x%llx] already mapped\n", 
> start, last);
> +   amdgpu_bo_unreserve(vm->root.bo);
> +   return -EADDRINUSE;
> +   }
> +   amdgpu_bo_unreserve(vm->root.bo);
> +   }
> +
> +   return 0;
> +}
> +
>  /**
>   * svm_range_is_valid - check if virtual address range is valid
> - * @mm: current process mm_struct
> + * @mm: current kfd_process
>   * @start: range start address, in pages
>   * @size: range size, in pages
>   *
> @@ -2592,28 +2637,27 @@ int svm_range_list_init(struct kfd_process *p)
>   * Context: Process context
>   *
>   * Return:
> - *  true - valid svm range
> - *  false - invalid svm range
> + *  0 - OK, otherwise error code
>   */
> -static bool
> -svm_range_is_valid(struct mm_struct *mm, uint64_t start, uint64_t size)
> +static int
> +svm_range_is_valid(struct kfd_process *p, uint64_t start, uint64_t size)
>  {
>

Re: [PATCH] drm/amd/display: Add NULL checks for vblank workqueue

[Mike Lothian]

Hi

I've just tested this out against Linus's tree and it seems to fix things

Out of interest does Tonga have GPU reset when things go wrong?

Thanks

Mike

On Tue, 7 Sept 2021 at 15:20, Harry Wentland  wrote:
>
>
>
> On 2021-09-07 10:10 a.m., Nicholas Kazlauskas wrote:
> > [Why]
> > If we're running a headless config with 0 links then the vblank
> > workqueue will be NULL - causing a NULL pointer exception during
> > any commit.
> >
> > [How]
> > Guard access to the workqueue if it's NULL and don't queue or flush
> > work if it is.
> >
> > Cc: Roman Li 
> > Cc: Wayne Lin 
> > Cc: Harry Wentland 
> > Reported-by: Mike Lothian 
> > BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1700
> > Fixes: 91f86d4cce2 ("drm/amd/display: Use vblank control events for PSR 
> > enable/disable")
> > Signed-off-by: Nicholas Kazlauskas 
>
> Reviewed-by: Harry Wentland 
>
> Harry
>
> > ---
> >  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++
> >  1 file changed, 18 insertions(+), 14 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 8837259215d..46e08736f94 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6185,21 +6185,23 @@ static inline int dm_set_vblank(struct drm_crtc 
> > *crtc, bool enable)
> >   return 0;
> >
> >  #if defined(CONFIG_DRM_AMD_DC_DCN)
> > - work = kzalloc(sizeof(*work), GFP_ATOMIC);
> > - if (!work)
> > - return -ENOMEM;
> > + if (dm->vblank_control_workqueue) {
> > + work = kzalloc(sizeof(*work), GFP_ATOMIC);
> > + if (!work)
> > + return -ENOMEM;
> >
> > - INIT_WORK(>work, vblank_control_worker);
> > - work->dm = dm;
> > - work->acrtc = acrtc;
> > - work->enable = enable;
> > + INIT_WORK(>work, vblank_control_worker);
> > + work->dm = dm;
> > + work->acrtc = acrtc;
> > + work->enable = enable;
> >
> > - if (acrtc_state->stream) {
> > - dc_stream_retain(acrtc_state->stream);
> > - work->stream = acrtc_state->stream;
> > - }
> > + if (acrtc_state->stream) {
> > + dc_stream_retain(acrtc_state->stream);
> > + work->stream = acrtc_state->stream;
> > + }
> >
> > - queue_work(dm->vblank_control_workqueue, >work);
> > + queue_work(dm->vblank_control_workqueue, >work);
> > + }
> >  #endif
> >
> >   return 0;
> > @@ -8809,7 +8811,8 @@ static void amdgpu_dm_commit_planes(struct 
> > drm_atomic_state *state,
> >* If PSR or idle optimizations are enabled then flush out
> >* any pending work before hardware programming.
> >*/
> > - flush_workqueue(dm->vblank_control_workqueue);
> > + if (dm->vblank_control_workqueue)
> > + flush_workqueue(dm->vblank_control_workqueue);
> >  #endif
> >
> >   bundle->stream_update.stream = acrtc_state->stream;
> > @@ -9144,7 +9147,8 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> > drm_atomic_state *state)
> >   /* if there mode set or reset, disable eDP PSR */
> >   if (mode_set_reset_required) {
> >  #if defined(CONFIG_DRM_AMD_DC_DCN)
> > - flush_workqueue(dm->vblank_control_workqueue);
> > + if (dm->vblank_control_workqueue)
> > + flush_workqueue(dm->vblank_control_workqueue);
> >  #endif
> >   amdgpu_dm_psr_disable_all(dm);
> >   }
> >
>

Re: [PATCH 3/7] drm/amd/display: Use vblank control events for PSR enable/disable

[Mike Lothian]

Hi

This patch is causing issues on my PRIME system

I've opened https://gitlab.freedesktop.org/drm/amd/-/issues/1700 to track

Cheers

Mike


On Fri, 13 Aug 2021 at 07:35, Wayne Lin  wrote:
>
> From: Nicholas Kazlauskas 
>
> [Why]
> PSR can disable the HUBP along with the OTG when PSR is active.
>
> We'll hit a pageflip timeout when the OTG is disable because we're no
> longer updating the CRTC vblank counter and the pflip high IRQ will
> not fire on the flip.
>
> In order to flip the page flip timeout occur we should modify the
> enter/exit conditions to match DRM requirements.
>
> [How]
> Use our deferred handlers for DRM vblank control to notify DMCU(B)
> when it can enable or disable PSR based on whether vblank is disabled or
> enabled respectively.
>
> We'll need to pass along the stream with the notification now because
> we want to access the CRTC state while the CRTC is locked to get the
> stream state prior to the commit.
>
> Retain a reference to the stream so it remains safe to continue to
> access and release that reference once we're done with it.
>
> Enable/disable logic follows what we were previously doing in
> update_planes.
>
> The workqueue has to be flushed before programming streams or planes
> to ensure that we exit out of idle optimizations and PSR before
> these events occur if necessary.
>
> To keep the skip count logic the same to avoid FBCON PSR enablement
> requires copying the allow condition onto the DM IRQ parameters - a
> field that we can actually access from the worker.
>
> Reviewed-by: Roman Li 
> Acked-by: Wayne Lin 
> Signed-off-by: Nicholas Kazlauskas 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 48 +++
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
>  .../display/amdgpu_dm/amdgpu_dm_irq_params.h  |  1 +
>  3 files changed, 43 insertions(+), 8 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 f88b6c5b83cd..cebd663b6708 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1061,7 +1061,22 @@ static void vblank_control_worker(struct work_struct 
> *work)
>
> DRM_DEBUG_KMS("Allow idle optimizations (MALL): %d\n", 
> dm->active_vblank_irq_count == 0);
>
> +   /* Control PSR based on vblank requirements from OS */
> +   if (vblank_work->stream && vblank_work->stream->link) {
> +   if (vblank_work->enable) {
> +   if 
> (vblank_work->stream->link->psr_settings.psr_allow_active)
> +   amdgpu_dm_psr_disable(vblank_work->stream);
> +   } else if 
> (vblank_work->stream->link->psr_settings.psr_feature_enabled &&
> +  
> !vblank_work->stream->link->psr_settings.psr_allow_active &&
> +  vblank_work->acrtc->dm_irq_params.allow_psr_entry) 
> {
> +   amdgpu_dm_psr_enable(vblank_work->stream);
> +   }
> +   }
> +
> mutex_unlock(>dc_lock);
> +
> +   dc_stream_release(vblank_work->stream);
> +
> kfree(vblank_work);
>  }
>
> @@ -6018,6 +6033,11 @@ static inline int dm_set_vblank(struct drm_crtc *crtc, 
> bool enable)
> work->acrtc = acrtc;
> work->enable = enable;
>
> +   if (acrtc_state->stream) {
> +   dc_stream_retain(acrtc_state->stream);
> +   work->stream = acrtc_state->stream;
> +   }
> +
> queue_work(dm->vblank_control_workqueue, >work);
>  #endif
>
> @@ -8623,6 +8643,12 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
> /* Update the planes if changed or disable if we don't have any. */
> if ((planes_count || acrtc_state->active_planes == 0) &&
> acrtc_state->stream) {
> +   /*
> +* If PSR or idle optimizations are enabled then flush out
> +* any pending work before hardware programming.
> +*/
> +   flush_workqueue(dm->vblank_control_workqueue);
> +
> bundle->stream_update.stream = acrtc_state->stream;
> if (new_pcrtc_state->mode_changed) {
> bundle->stream_update.src = acrtc_state->stream->src;
> @@ -8691,16 +8717,20 @@ static void amdgpu_dm_commit_planes(struct 
> drm_atomic_state *state,
> 
> acrtc_state->stream->link->psr_settings.psr_version != 
> DC_PSR_VERSION_UNSUPPORTED &&
> 
> !acrtc_state->stream->link->psr_settings.psr_feature_enabled)
> amdgpu_dm_link_setup_psr(acrtc_state->stream);
> -   else if ((acrtc_state->update_type == UPDATE_TYPE_FAST) &&
> -   
> acrtc_state->stream->link->psr_settings.psr_feature_enabled &&
> -   
> !acrtc_state->stream->link->psr_settings.psr_allow_active) {

Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)

[Mike Lothian]

Hi

Do I need to open a new bug report for this?

Cheers

Mike

On Wed, 18 Aug 2021 at 06:26, Andrey Grodzovsky 
wrote:

>
> On 2021-08-02 1:16 a.m., Guchun Chen wrote:
> > In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to stop
> > scheduler in s3 test, otherwise, fence related failure will arrive
> > after resume. To fix this and for a better clean up, move drm_sched_fini
> > from fence_hw_fini to fence_sw_fini, as it's part of driver shutdown, and
> > should never be called in hw_fini.
> >
> > v2: rename amdgpu_fence_driver_init to amdgpu_fence_driver_sw_init,
> > to keep sw_init and sw_fini paired.
> >
> > Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
> > Suggested-by: Christian König 
> > Signed-off-by: Guchun Chen 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  5 ++---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 12 +++-
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  4 ++--
> >   3 files changed, 11 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index b1d2dc39e8be..9e53ff851496 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -3646,9 +3646,9 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> >
> >   fence_driver_init:
> >   /* Fence driver */
> > - r = amdgpu_fence_driver_init(adev);
> > + r = amdgpu_fence_driver_sw_init(adev);
> >   if (r) {
> > - dev_err(adev->dev, "amdgpu_fence_driver_init failed\n");
> > + dev_err(adev->dev, "amdgpu_fence_driver_sw_init failed\n");
> >   amdgpu_vf_error_put(adev, AMDGIM_ERROR_VF_FENCE_INIT_FAIL,
> 0, 0);
> >   goto failed;
> >   }
> > @@ -3988,7 +3988,6 @@ int amdgpu_device_resume(struct drm_device *dev,
> bool fbcon)
> >   }
> >   amdgpu_fence_driver_hw_init(adev);
> >
> > -
> >   r = amdgpu_device_ip_late_init(adev);
> >   if (r)
> >   return r;
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > index 49c5c7331c53..7495911516c2 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > @@ -498,7 +498,7 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
> *ring,
> >   }
> >
> >   /**
> > - * amdgpu_fence_driver_init - init the fence driver
> > + * amdgpu_fence_driver_sw_init - init the fence driver
> >* for all possible rings.
> >*
> >* @adev: amdgpu device pointer
> > @@ -509,13 +509,13 @@ int amdgpu_fence_driver_init_ring(struct
> amdgpu_ring *ring,
> >* amdgpu_fence_driver_start_ring().
> >* Returns 0 for success.
> >*/
> > -int amdgpu_fence_driver_init(struct amdgpu_device *adev)
> > +int amdgpu_fence_driver_sw_init(struct amdgpu_device *adev)
> >   {
> >   return 0;
> >   }
> >
> >   /**
> > - * amdgpu_fence_driver_fini - tear down the fence driver
> > + * amdgpu_fence_driver_hw_fini - tear down the fence driver
> >* for all possible rings.
> >*
> >* @adev: amdgpu device pointer
> > @@ -531,8 +531,7 @@ void amdgpu_fence_driver_hw_fini(struct
> amdgpu_device *adev)
> >
> >   if (!ring || !ring->fence_drv.initialized)
> >   continue;
> > - if (!ring->no_scheduler)
> > - drm_sched_fini(>sched);
> > +
> >   /* You can't wait for HW to signal if it's gone */
> >   if (!drm_dev_is_unplugged(>ddev))
> >   r = amdgpu_fence_wait_empty(ring);
>
>
> Sorry for late notice, missed this patch. By moving drm_sched_fini
> past amdgpu_fence_wait_empty a race is created as even after you waited
> for all fences on the ring to signal the sw scheduler will keep submitting
> new jobs on the ring and so the ring won't stay empty.
>
> For hot device removal also we want to prevent any access to HW past PCI
> removal
> in order to not do any MMIO accesses inside the physical MMIO range that
> no longer
> belongs to this device after it's removal by the PCI core. Stopping all
> the schedulers prevents any MMIO
> accesses done during job submissions and that why drm_sched_fini was
> done as part of amdgpu_fence_driver_hw_fini
> and not amdgpu_fence_driver_sw_fini
>
> Andrey
>
> > @@ -560,6 +559,9 @@ void amdgpu_fence_driver_sw_fini(struct
> amdgpu_device *adev)
> >   if (!ring || !ring->fence_drv.initialized)
> >   continue;
> >
> > + if (!ring->no_scheduler)
> > + drm_sched_fini(>sched);
> > +
> >   for (j = 0; j <= ring->fence_drv.num_fences_mask; ++j)
> >   dma_fence_put(ring->fence_drv.fences[j]);
> >   kfree(ring->fence_drv.fences);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> > index 27adffa7658d..9c11ced4312c 

Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)

[Mike Lothian]

Hi

I've just noticed something similar when starting weston, I still see it
with this patch, but not on linus's tree

I'll confirm for sure tomorrow and send the stack trace if I can save it

Cheers

Mike

On Tue, 3 Aug 2021 at 02:56, Chen, Guchun  wrote:

> [Public]
>
> Hi Alex,
>
> I submitted the patch before your message, I will take care of this next
> time.
>
> Regards,
> Guchun
>
> -Original Message-
> From: Alex Deucher 
> Sent: Monday, August 2, 2021 9:35 PM
> To: Chen, Guchun 
> Cc: Christian König ;
> amd-gfx@lists.freedesktop.org; Gao, Likun ; Koenig,
> Christian ; Zhang, Hawking <
> hawking.zh...@amd.com>; Deucher, Alexander 
> Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in
> s3 test (v2)
>
> On Mon, Aug 2, 2021 at 4:23 AM Chen, Guchun  wrote:
> >
> > [Public]
> >
> > Thank you, Christian.
> >
> > Regarding fence_drv.initialized, it looks to a bit redundant, anyway let
> me look into this more.
>
> Does this patch fix this bug?
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1668data=04%7C01%7CGuchun.Chen%40amd.com%7C2bf8bebf5b424751572408d955ba66e8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637635081353279181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FuAo44Ws5SnuCxt45A%2Fqmu%2B3OfEkat1G%2BixO8G9uDVc%3Dreserved=0
>
> If so, please add:
> Bug:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Famd%2F-%2Fissues%2F1668data=04%7C01%7CGuchun.Chen%40amd.com%7C2bf8bebf5b424751572408d955ba66e8%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637635081353279181%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=FuAo44Ws5SnuCxt45A%2Fqmu%2B3OfEkat1G%2BixO8G9uDVc%3Dreserved=0
> to the commit message.
>
> Alex
>
> >
> > Regards,
> > Guchun
> >
> > -Original Message-
> > From: Christian König 
> > Sent: Monday, August 2, 2021 2:56 PM
> > To: Chen, Guchun ; amd-gfx@lists.freedesktop.org;
> > Gao, Likun ; Koenig, Christian
> > ; Zhang, Hawking ;
> > Deucher, Alexander 
> > Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver
> > fini in s3 test (v2)
> >
> > Am 02.08.21 um 07:16 schrieb Guchun Chen:
> > > In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to
> > > stop scheduler in s3 test, otherwise, fence related failure will
> > > arrive after resume. To fix this and for a better clean up, move
> > > drm_sched_fini from fence_hw_fini to fence_sw_fini, as it's part of
> > > driver shutdown, and should never be called in hw_fini.
> > >
> > > v2: rename amdgpu_fence_driver_init to amdgpu_fence_driver_sw_init,
> > > to keep sw_init and sw_fini paired.
> > >
> > > Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
> > > Suggested-by: Christian König 
> > > Signed-off-by: Guchun Chen 
> >
> > It's a bit ambiguous now what fence_drv.initialized means, but I think
> we can live with that for now.
> >
> > Patch is Reviewed-by: Christian König .
> >
> > Regards,
> > Christian.
> >
> > > ---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  5 ++---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 12 +++-
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  4 ++--
> > >   3 files changed, 11 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > index b1d2dc39e8be..9e53ff851496 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -3646,9 +3646,9 @@ int amdgpu_device_init(struct amdgpu_device
> > > *adev,
> > >
> > >   fence_driver_init:
> > >   /* Fence driver */
> > > - r = amdgpu_fence_driver_init(adev);
> > > + r = amdgpu_fence_driver_sw_init(adev);
> > >   if (r) {
> > > - dev_err(adev->dev, "amdgpu_fence_driver_init failed\n");
> > > + dev_err(adev->dev, "amdgpu_fence_driver_sw_init
> > > + failed\n");
> > >   amdgpu_vf_error_put(adev,
> AMDGIM_ERROR_VF_FENCE_INIT_FAIL, 0, 0);
> > >   goto failed;
> > >   }
> > > @@ -3988,7 +3988,6 @@ int amdgpu_device_resume(struct drm_device *dev,
> bool fbcon)
> > >   }
> > >   amdgpu_fence_driver_hw_init(adev);
> > >
> > > -
> > >   r = amdgpu_device_ip_late_init(adev);
> > >   if (r)
> > >   return r;
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > index 49c5c7331c53..7495911516c2 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > @@ -498,7 +498,7 @@ int amdgpu_fence_driver_init_ring(struct
> amdgpu_ring *ring,
> > >   }
> > >
> > >   /**
> > > - * amdgpu_fence_driver_init - init the fence driver
> > > + * amdgpu_fence_driver_sw_init - init the 

Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini in s3 test (v2)

[Mike Lothian]

I've just tested it and it seem to fix my issue

Feel free to add my

Tested-by: Mike Lothian 

On Mon, 2 Aug 2021 at 14:35, Alex Deucher  wrote:

> On Mon, Aug 2, 2021 at 4:23 AM Chen, Guchun  wrote:
> >
> > [Public]
> >
> > Thank you, Christian.
> >
> > Regarding fence_drv.initialized, it looks to a bit redundant, anyway let
> me look into this more.
>
> Does this patch fix this bug?
> https://gitlab.freedesktop.org/drm/amd/-/issues/1668
>
> If so, please add:
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1668
> to the commit message.
>
> Alex
>
> >
> > Regards,
> > Guchun
> >
> > -Original Message-
> > From: Christian König 
> > Sent: Monday, August 2, 2021 2:56 PM
> > To: Chen, Guchun ; amd-gfx@lists.freedesktop.org;
> Gao, Likun ; Koenig, Christian <
> christian.koe...@amd.com>; Zhang, Hawking ;
> Deucher, Alexander 
> > Subject: Re: [PATCH] drm/amdgpu: avoid over-handle of fence driver fini
> in s3 test (v2)
> >
> > Am 02.08.21 um 07:16 schrieb Guchun Chen:
> > > In amdgpu_fence_driver_hw_fini, no need to call drm_sched_fini to stop
> > > scheduler in s3 test, otherwise, fence related failure will arrive
> > > after resume. To fix this and for a better clean up, move
> > > drm_sched_fini from fence_hw_fini to fence_sw_fini, as it's part of
> > > driver shutdown, and should never be called in hw_fini.
> > >
> > > v2: rename amdgpu_fence_driver_init to amdgpu_fence_driver_sw_init, to
> > > keep sw_init and sw_fini paired.
> > >
> > > Fixes: cd87a6dcf6af drm/amdgpu: adjust fence driver enable sequence
> > > Suggested-by: Christian König 
> > > Signed-off-by: Guchun Chen 
> >
> > It's a bit ambiguous now what fence_drv.initialized means, but I think
> we can live with that for now.
> >
> > Patch is Reviewed-by: Christian König .
> >
> > Regards,
> > Christian.
> >
> > > ---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  5 ++---
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 12 +++-
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  4 ++--
> > >   3 files changed, 11 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > index b1d2dc39e8be..9e53ff851496 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -3646,9 +3646,9 @@ int amdgpu_device_init(struct amdgpu_device
> > > *adev,
> > >
> > >   fence_driver_init:
> > >   /* Fence driver */
> > > - r = amdgpu_fence_driver_init(adev);
> > > + r = amdgpu_fence_driver_sw_init(adev);
> > >   if (r) {
> > > - dev_err(adev->dev, "amdgpu_fence_driver_init failed\n");
> > > + dev_err(adev->dev, "amdgpu_fence_driver_sw_init
> failed\n");
> > >   amdgpu_vf_error_put(adev,
> AMDGIM_ERROR_VF_FENCE_INIT_FAIL, 0, 0);
> > >   goto failed;
> > >   }
> > > @@ -3988,7 +3988,6 @@ int amdgpu_device_resume(struct drm_device *dev,
> bool fbcon)
> > >   }
> > >   amdgpu_fence_driver_hw_init(adev);
> > >
> > > -
> > >   r = amdgpu_device_ip_late_init(adev);
> > >   if (r)
> > >   return r;
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > index 49c5c7331c53..7495911516c2 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > > @@ -498,7 +498,7 @@ int amdgpu_fence_driver_init_ring(struct
> amdgpu_ring *ring,
> > >   }
> > >
> > >   /**
> > > - * amdgpu_fence_driver_init - init the fence driver
> > > + * amdgpu_fence_driver_sw_init - init the fence driver
> > >* for all possible rings.
> > >*
> > >* @adev: amdgpu device pointer
> > > @@ -509,13 +509,13 @@ int amdgpu_fence_driver_init_ring(struct
> amdgpu_ring *ring,
> > >* amdgpu_fence_driver_start_ring().
> > >* Returns 0 for success.
> > >*/
> > > -int amdgpu_fence_driver_init(struct amdgpu_device *adev)
> > > +int amdgpu_fence_driver_sw_init(struct amdgpu_device *adev)
> > >   {
> > >   return 0;
> > >   }
> > >
> > &g

Re: [PATCH] drm/amdgpu: adjust fence driver enable sequence

[Mike Lothian]

Hi

This patch is causing me issues on my Skylake/Tonga PRIME laptop, reverting
sorts it

More details here: https://gitlab.freedesktop.org/drm/amd/-/issues/1668

Cheers

Mike

On Wed, 28 Jul 2021 at 05:07, Likun Gao  wrote:

> From: Likun Gao 
>
> Fence driver was enabled per ring when sw init on per IP block before.
> Change to enable all the fence driver at the same time after
> amdgpu_device_ip_init finished.
> Rename some function related to fence to make it reasonable for read.
>
> Signed-off-by: Likun Gao 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  6 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  | 15 ++-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h   |  4 ++--
>  3 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index d3a4299b1f30..77195a4e5c59 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -3675,6 +3675,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> goto release_ras_con;
> }
>
> +   amdgpu_fence_driver_hw_init(adev);
> +
> dev_info(adev->dev,
> "SE %d, SH per SE %d, CU per SH %d, active_cu_number %d\n",
> adev->gfx.config.max_shader_engines,
> @@ -3939,7 +3941,7 @@ int amdgpu_device_suspend(struct drm_device *dev,
> bool fbcon)
> /* evict vram memory */
> amdgpu_bo_evict_vram(adev);
>
> -   amdgpu_fence_driver_suspend(adev);
> +   amdgpu_fence_driver_hw_fini(adev);
>
> amdgpu_device_ip_suspend_phase2(adev);
> /* evict remaining vram memory
> @@ -3984,7 +3986,7 @@ int amdgpu_device_resume(struct drm_device *dev,
> bool fbcon)
> dev_err(adev->dev, "amdgpu_device_ip_resume failed
> (%d).\n", r);
> return r;
> }
> -   amdgpu_fence_driver_resume(adev);
> +   amdgpu_fence_driver_hw_init(adev);
>
>
> r = amdgpu_device_ip_late_init(adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> index 72d9b92b1754..e2f606bca779 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> @@ -417,9 +417,6 @@ int amdgpu_fence_driver_start_ring(struct amdgpu_ring
> *ring,
> }
> amdgpu_fence_write(ring, atomic_read(>fence_drv.last_seq));
>
> -   if (irq_src)
> -   amdgpu_irq_get(adev, irq_src, irq_type);
> -
> ring->fence_drv.irq_src = irq_src;
> ring->fence_drv.irq_type = irq_type;
> ring->fence_drv.initialized = true;
> @@ -572,14 +569,14 @@ void amdgpu_fence_driver_fini_sw(struct
> amdgpu_device *adev)
>  }
>
>  /**
> - * amdgpu_fence_driver_suspend - suspend the fence driver
> + * amdgpu_fence_driver_hw_fini - disable the fence driver
>   * for all possible rings.
>   *
>   * @adev: amdgpu device pointer
>   *
> - * Suspend the fence driver for all possible rings (all asics).
> + * Disable the fence driver for all possible rings (all asics).
>   */
> -void amdgpu_fence_driver_suspend(struct amdgpu_device *adev)
> +void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev)
>  {
> int i, r;
>
> @@ -603,18 +600,18 @@ void amdgpu_fence_driver_suspend(struct
> amdgpu_device *adev)
>  }
>
>  /**
> - * amdgpu_fence_driver_resume - resume the fence driver
> + * amdgpu_fence_driver_hw_init - enable the fence driver
>   * for all possible rings.
>   *
>   * @adev: amdgpu device pointer
>   *
> - * Resume the fence driver for all possible rings (all asics).
> + * Enable the fence driver for all possible rings (all asics).
>   * Not all asics have all rings, so each asic will only
>   * start the fence driver on the rings it has using
>   * amdgpu_fence_driver_start_ring().
>   * Returns 0 for success.
>   */
> -void amdgpu_fence_driver_resume(struct amdgpu_device *adev)
> +void amdgpu_fence_driver_hw_init(struct amdgpu_device *adev)
>  {
> int i;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> index e7d3d0dbdd96..64471018f5e6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h
> @@ -117,8 +117,8 @@ int amdgpu_fence_driver_init_ring(struct amdgpu_ring
> *ring,
>  int amdgpu_fence_driver_start_ring(struct amdgpu_ring *ring,
>struct amdgpu_irq_src *irq_src,
>unsigned irq_type);
> -void amdgpu_fence_driver_suspend(struct amdgpu_device *adev);
> -void amdgpu_fence_driver_resume(struct amdgpu_device *adev);
> +void amdgpu_fence_driver_hw_fini(struct amdgpu_device *adev);
> +void amdgpu_fence_driver_hw_init(struct amdgpu_device *adev);
>  int amdgpu_fence_emit(struct amdgpu_ring *ring, struct dma_fence **fence,
>   unsigned flags);
>  int amdgpu_fence_emit_polling(struct 

Re: amdgpu does not support 3840x2160@30Hz on kaveri apu

[Mike Lothian]

Hi

You're probably best reporting the bug here:

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

Attach the output of dmesg from both Radeon and AMDGPU and the compositor /
Wayland logs (as you're not using X)

Cheers

Mike



On Sun, 3 Jan 2021, 06:32 Davide Corrado,  wrote:

> hello, I'd like to report this issue that I am having since I updated my
> display (samsung U28E590). The amdgpu does not support the native
> resolution of my new monitor, which is 3840x2160*.* Using a HDMI or DVI
> connection (I tried both, same results), the maximum supported refresh is
> 30Hz, so I'm stuck with that (don't have a displayport). The radeon module
> works fine, I'm having this issue just when I use amdgpu (which I'd like
> to, because performance is better).
>
> Some info of my hardware:
>
> cpu: AMD A10-7870K Radeon R7, 12 Compute Cores 4C+8G
> kernel version (I tried different ones and different linux distros, same
> results!): 5.9.16-200.fc33.x86_64 #1 SMP Mon Dec 21 14:08:22 UTC 2020
> x86_64 x86_64 x86_64 GNU/Linux
> Monitor: Samsung U28E590.
>
> description:
> If I boot the system using amdgpu and no video mode selection, the system
> boots but I don't get a screen during boot and in wayland. I can connect
> using ssh, so the system is running fine, just no display; If I force a
> full HD resolution with "video:" in the kernel line, I can see the boot
> process but the screen disappears when wayland starts (because the default
> resolution is 3840x2160@30Hz). Using a full HD monitor results in no
> issues, so it must be related to this very 4k resolution.
>
> As I have already stated, radeon module works with the same
> software/hardware configuration.
> thanks you so much for your time :-)
>
> --
> Davide Corrado
> UNIX Team Leader
>
> Via Abramo Lincoln, 25
> 20129 Milano
>
> Tel +39 3474259950
> ___
> 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 v1 0/5] Enable BACO with KFD

[Mike Lothian]

Is this designed to work with PRIME laptops too?

On Tue, 28 Jan 2020 at 01:29, Rajneesh Bhardwaj
 wrote:
>
> This series aims to enable BACO by default on supported AMD platforms
> and ensures that the AMD Kernel Fusion Driver can co-exist with this
> feature when the GPU devices are runtime suspended and firmware pushes
> the envelop to save more power with BACO entry sequence. Current
> approach makes sure that if KFD is using GPU services for compute, it
> won't let AMDGPU driver suspend and if the AMDGPU driver is already
> runtime suspended with GPUs in deep power saving mode with BACO, the KFD
> driver wakes up the AMDGPU and then starts the compute workload
> execution.
>
> This series has been tested with a single GPU (fiji), Dual GPUs (fiji
> and fiji/tonga) and seems to work fine. I have not seen but expect some
> corner cases where for some reason a KFD client binds a process but is
> unable to complete the task within 60 seconds. Ideally we should put the
> runtime_put and auto_suspend code in some function which is logical
> opposite of bind_process_to_device but during my experiments, it ended
> up with random gpu hang, machine reboot etc so any comments for
> improvement are welcome.
>
> Todo:
>
> rebase on top of https://patchwork.freedesktop.org/patch/338037/
>
> Rajneesh Bhardwaj (5):
>   drm/amdgpu: always enable runtime power management
>   drm/amdgpu: Fix missing error check in suspend
>   drm/amdkfd: Introduce debugfs option to disable baco
>   drm/amdkfd: show warning when kfd is locked
>   drm/amdkfd: refactor runtime pm for baco
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 12 -
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h |  9 ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  7 +++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|  3 +++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|  9 +++
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |  2 ++
>  drivers/gpu/drm/amd/amdkfd/kfd_debugfs.c   | 27 +++
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c| 31 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_iommu.c |  5 +++-
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c   | 19 ++---
>  10 files changed, 91 insertions(+), 33 deletions(-)
>
> --
> 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: [pull] amdgpu, amdkfd, radeon drm-next-5.6

[Mike Lothian]

Hi

Please can amdgpu/raven_ta.bin be published somewhere

Thanks

Mike

On Wed, 11 Dec 2019 at 22:30, Alex Deucher  wrote:
>
> Hi Dave, Daniel,
>
> Kicking off 5.6 with new stuff from AMD.  There is a UAPI addition.  We
> added a new firmware for display, and this just adds the version query
> to our existing firmware query interface.  UMDs like mesa use this interface 
> to
> query things like CP or UVD firmware versions to see what features are
> supported.
>
> The following changes since commit 622b2a0ab647d2755f2c1f1000d3403e86a69763:
>
>   drm/amdgpu/vcn: finish delay work before release resources (2019-11-13 
> 15:29:42 -0500)
>
> are available in the Git repository at:
>
>   git://people.freedesktop.org/~agd5f/linux tags/drm-next-5.6-2019-12-11
>
> for you to fetch changes up to ad808910be68dcf8da5d837d4511d00ad5d3678a:
>
>   drm/amdgpu: fix license on Kconfig and Makefiles (2019-12-11 15:22:08 -0500)
>
> 
> drm-next-5.6-2019-12-11:
>
> amdgpu:
> - Add MST atomic routines
> - Add support for DMCUB (new helper microengine for displays)
> - Add OEM i2c support in DC
> - Use vstartup for vblank events on DCN
> - Simplify Kconfig for DC
> - Renoir fixes for DC
> - Clean up function pointers in DC
> - Initial support for HDCP 2.x
> - Misc code cleanups
> - GFX10 fixes
> - Rework JPEG engine handling for VCN
> - Add clock and power gating support for JPEG
> - BACO support for Arcturus
> - Cleanup PSP ring handling
> - Add framework for using BACO with runtime pm to save power
> - Move core pci state handling out of the driver for pm ops
> - Allow guest power control in 1 VF case with SR-IOV
> - SR-IOV fixes
> - RAS fixes
> - Support for power metrics on renoir
> - Golden settings updates for gfx10
> - Enable gfxoff on supported navi10 skus
> - Update MAINTAINERS
>
> amdkfd:
> - Clean up generational gfx code
> - Fixes for gfx10
> - DIQ fixes
> - Share more code with amdgpu
>
> radeon:
> - PPC DMA fix
> - Register checker fixes for r1xx/r2xx
> - Misc cleanups
>
> 
> Alex Deucher (34):
>   drm/amdgpu/display: fix the build when CONFIG_DRM_AMD_DC_DCN is not set
>   drm/amdgpu/display: fix warning when CONFIG_DRM_AMD_DC_DCN is not set
>   drm/amdgpu/soc15: move struct definition around to align with other 
> soc15 asics
>   drm/amdgpu/nv: add asic func for fetching vbios from rom directly
>   drm/amdgpu/powerplay: properly set PP_GFXOFF_MASK (v2)
>   drm/amdgpu: disable gfxoff when using register read interface
>   drm/amdgpu: remove experimental flag for Navi14
>   drm/amdgpu: disable gfxoff on original raven
>   Revert "drm/amd/display: enable S/G for RAVEN chip"
>   drm/amdgpu: add asic callback for BACO support
>   drm/amdgpu: add supports_baco callback for soc15 asics. (v2)
>   drm/amdgpu: add supports_baco callback for SI asics.
>   drm/amdgpu: add supports_baco callback for CIK asics.
>   drm/amdgpu: add supports_baco callback for VI asics.
>   drm/amdgpu: add supports_baco callback for NV asics.
>   drm/amdgpu: add a amdgpu_device_supports_baco helper
>   drm/amdgpu: rename amdgpu_device_is_px to amdgpu_device_supports_boco 
> (v2)
>   drm/amdgpu: add additional boco checks to runtime suspend/resume (v2)
>   drm/amdgpu: split swSMU baco_reset into enter and exit
>   drm/amdgpu: add helpers for baco entry and exit
>   drm/amdgpu: add baco support to runtime suspend/resume
>   drm/amdgpu: start to disentangle boco from runtime pm
>   drm/amdgpu: disentangle runtime pm and vga_switcheroo
>   drm/amdgpu: enable runtime pm on BACO capable boards if runpm=1
>   drm/amdgpu: simplify runtime suspend
>   drm/amd/display: add default clocks if not able to fetch them
>   MAINTAINERS: Drop Rex Zhu for amdgpu powerplay
>   drm/amdgpu: move pci handling out of pm ops
>   drm/amdgpu: flag vram lost on baco reset for VI/CIK
>   drm/amd/display: re-enable wait in pipelock, but add timeout
>   drm/radeon: fix r1xx/r2xx register checker for POT textures
>   drm/amdgpu: add header line for power profile on Arcturus
>   drm/amdgpu/display: add fallthrough comment
>   drm/amdgpu: fix license on Kconfig and Makefiles
>
> Alex Sierra (2):
>   drm/amdgpu: add flag to indicate amdgpu vm context
>   amd/amdgpu: force to trigger a no-retry-fault after a retry-fault
>
> Alvin Lee (1):
>   drm/amd/display: Changes in dc to allow full update in some cases
>
> Amanda Liu (1):
>   drm/amd/display: Fix screen tearing on vrr tests
>
> Andrey Grodzovsky (1):
>   drm/amdgpu: Fix BACO entry failure in NAVI10.
>
> Anthony Koo (8):
>   drm/amd/display: set MSA MISC1 bit 6 while sending colorimetry in VSC 
> SDP
>   drm/amd/display: Clean up some code with unused registers
>   drm/amd/display: cleanup of construct and destruct funcs
>   

Re: [PATCH] drm/amdgpu/psp: declare PSP TA firmware

[Mike Lothian]

Hi

Any idea where I can find those blobs?

Cheers

Mike

On Wed, 16 Oct 2019 at 03:48, chen gong  wrote:
>
> Add PSP TA firmware declaration for raven raven2 picasso
>
> Signed-off-by: chen gong 
> ---
>  drivers/gpu/drm/amd/amdgpu/psp_v10_0.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c 
> b/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c
> index b96484a..b345e69 100644
> --- a/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/psp_v10_0.c
> @@ -40,6 +40,9 @@
>  MODULE_FIRMWARE("amdgpu/raven_asd.bin");
>  MODULE_FIRMWARE("amdgpu/picasso_asd.bin");
>  MODULE_FIRMWARE("amdgpu/raven2_asd.bin");
> +MODULE_FIRMWARE("amdgpu/picasso_ta.bin");
> +MODULE_FIRMWARE("amdgpu/raven2_ta.bin");
> +MODULE_FIRMWARE("amdgpu/raven_ta.bin");
>
>  static int psp_v10_0_init_microcode(struct psp_context *psp)
>  {
> --
> 2.7.4
>
> ___
> 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 10/49] drm/amd/display: make firmware info only load once during dc_bios create

[Mike Lothian]

On Fri, 9 Aug 2019 at 22:38,  wrote:
>
> From: Dmytro Laktyushkin 
>
> Currently every time DC wants to access firmware info we make a call
> into VBIOS. This makes no sense as there is nothing that can change
> runtime inside fw info and can cause issues when calling unstable
> bios during bringup.
>
> This change eliminate this behavior by only calling bios once for fw
> info and keeping it stored as part of dc_bios.
>
> Signed-off-by: Dmytro Laktyushkin 
> Reviewed-by: Chris Park 
> Acked-by: Leo Li 
> ---
>  .../gpu/drm/amd/display/dc/bios/bios_parser.c |  3 +-
>  .../drm/amd/display/dc/bios/bios_parser2.c|  3 +-
>  .../display/dc/clk_mgr/dce100/dce_clk_mgr.c   | 17 --
>  .../display/dc/clk_mgr/dcn10/rv1_clk_mgr.c|  6 ++--
>  .../gpu/drm/amd/display/dc/core/dc_resource.c |  7 ++--
>  .../gpu/drm/amd/display/dc/dc_bios_types.h|  5 ++-
>  .../drm/amd/display/dc/dce/dce_clock_source.c | 32 +++
>  .../gpu/drm/amd/display/dc/dce/dce_i2c_hw.c   | 13 +---
>  .../amd/display/dc/dce100/dce100_resource.c   |  4 +--
>  .../amd/display/dc/dce110/dce110_resource.c   |  4 +--
>  .../drm/amd/display/dc/dce80/dce80_resource.c | 12 ++-
>  .../drm/amd/display/dc/dcn20/dcn20_hwseq.c|  9 +++---
>  12 files changed, 36 insertions(+), 79 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> index a4c97d32e751..207f6084525c 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> @@ -2794,8 +2794,6 @@ static const struct dc_vbios_funcs vbios_funcs = {
>
> .get_device_tag = bios_parser_get_device_tag,
>
> -   .get_firmware_info = bios_parser_get_firmware_info,
> -
> .get_spread_spectrum_info = bios_parser_get_spread_spectrum_info,
>
> .get_ss_entry_number = bios_parser_get_ss_entry_number,
> @@ -2920,6 +2918,7 @@ static bool bios_parser_construct(
> dal_bios_parser_init_cmd_tbl_helper(>cmd_helper, dce_version);
>
> bp->base.integrated_info = 
> bios_parser_create_integrated_info(>base);
> +   bp->base.fw_info_valid = bios_parser_get_firmware_info(>base, 
> >base.fw_info) == BP_RESULT_OK;
>
> return true;
>  }
> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c 
> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> index 99f40b8a231c..c9f65c4df530 100644
> --- a/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> +++ b/drivers/gpu/drm/amd/display/dc/bios/bios_parser2.c
> @@ -1879,8 +1879,6 @@ static const struct dc_vbios_funcs vbios_funcs = {
>
> .get_device_tag = bios_parser_get_device_tag,
>
> -   .get_firmware_info = bios_parser_get_firmware_info,
> -
> .get_spread_spectrum_info = bios_parser_get_spread_spectrum_info,
>
> .get_ss_entry_number = bios_parser_get_ss_entry_number,
> @@ -1996,6 +1994,7 @@ static bool bios_parser_construct(
> dal_bios_parser_init_cmd_tbl_helper2(>cmd_helper, dce_version);
>
> bp->base.integrated_info = 
> bios_parser_create_integrated_info(>base);
> +   bp->base.fw_info_valid = bios_parser_get_firmware_info(>base, 
> >base.fw_info) == BP_RESULT_OK;
>
> return true;
>  }
> diff --git a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c 
> b/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
> index 814450fefffa..c5c8c4901eed 100644
> --- a/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
> +++ b/drivers/gpu/drm/amd/display/dc/clk_mgr/dce100/dce_clk_mgr.c
> @@ -273,18 +273,12 @@ static void dce_clock_read_integrated_info(struct 
> clk_mgr_internal *clk_mgr_dce)
>  {
> struct dc_debug_options *debug = _mgr_dce->base.ctx->dc->debug;
> struct dc_bios *bp = clk_mgr_dce->base.ctx->dc_bios;
> -   struct integrated_info info = { { { 0 } } };
> -   struct dc_firmware_info fw_info = { { 0 } };
> int i;
>
> if (bp->integrated_info)
> -   info = *bp->integrated_info;
> -
> -   clk_mgr_dce->dentist_vco_freq_khz = info.dentist_vco_freq;
> +   clk_mgr_dce->dentist_vco_freq_khz = 
> bp->integrated_info->dentist_vco_freq;
> if (clk_mgr_dce->dentist_vco_freq_khz == 0) {
> -   bp->funcs->get_firmware_info(bp, _info);
> -   clk_mgr_dce->dentist_vco_freq_khz =
> -   fw_info.smu_gpu_pll_output_freq;
> +   clk_mgr_dce->dentist_vco_freq_khz = 
> bp->fw_info.smu_gpu_pll_output_freq;
> if (clk_mgr_dce->dentist_vco_freq_khz == 0)
> clk_mgr_dce->dentist_vco_freq_khz = 360;
> }
> @@ -317,9 +311,10 @@ static void dce_clock_read_integrated_info(struct 
> clk_mgr_internal *clk_mgr_dce)
>
> /*Do not allow bad VBIOS/SBIOS to override with invalid 
> values,
>  * check for > 100MHz*/
> -   if (info.disp_clk_voltage[i].max_supported_clk >= 10)
> -   

Re: [PATCH] Revert "drm/amd/display: Enable fast plane updates when state->allow_modeset = true"

[Mike Lothian]

Just FYI my system was Raven1 not Raven2

On Thu, 20 Jun 2019 at 13:34, Nicholas Kazlauskas
 wrote:
>
> This reverts commit ebc8c6f18322ad54275997a888ca1731d74b711f.
>
> There are still missing corner cases with cursor interaction and these
> fast plane updates on Picasso and Raven2 leading to endless PSTATE
> warnings for typical desktop usage depending on the userspace.
>
> This change should be reverted until these issues have been resolved.
>
> Cc: David Francis 
> Cc: Harry Wentland 
> Signed-off-by: Nicholas Kazlauskas 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 33dcd4187157..d6acbcfa570c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6471,6 +6471,14 @@ static bool should_reset_plane(struct drm_atomic_state 
> *state,
> struct drm_crtc_state *new_crtc_state;
> int i;
>
> +   /*
> +* TODO: Remove this hack once the checks below are sufficient
> +* enough to determine when we need to reset all the planes on
> +* the stream.
> +*/
> +   if (state->allow_modeset)
> +   return true;
> +
> /* Exit early if we know that we're adding or removing the plane. */
> if (old_plane_state->crtc != new_plane_state->crtc)
> return true;
> --
> 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] drm/amd/display: Enable fast plane updates when state->allow_modeset = true

[Mike Lothian]

Hi

This patch causes warnings for me in a continuous loop

https://bugs.freedesktop.org/show_bug.cgi?id=110949

Let me know if you'd like any more detail

Cheers

Mike

On Fri, 7 Jun 2019 at 16:42, Francis, David  wrote:
>
> Patch is
>
> Reviewed-by: David Francis 
>
> 
> From: amd-gfx  on behalf of Nicholas 
> Kazlauskas 
> Sent: June 7, 2019 11:16:55 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Francis, David; Wentland, Harry; Kazlauskas, Nicholas
> Subject: [PATCH] drm/amd/display: Enable fast plane updates when 
> state->allow_modeset = true
>
> [Why]
> Whenever the a modeset is allowed (but not neccessarily required) we
> currently recreate all the planes in the state. Most IGT tests and
> legacy IOCTLs create atomic commits with this flag set, so the pipes
> are often unnecessarily reprogrammed.
>
> Poor performance and stuttering can occur when many of these commits
> are frequently issued.
>
> This flag was needed when the appropriate conditions for checking
> whether the planes needed a reset were not in place, but
> should_reset_plane should cover everything needed now.
>
> [How]
> Drop the check for state->allow_modeset in should_reset_plane.
>
> All planes on a CRTC should reset in the following conditions:
> - The CRTC needs a modeset
> - The CRTC degamma changes
> - Planes are added or removed to the CRTC
>
> These conditions are all covered in should_reset_plane.
>
> We still can't drop the format change check in should_reset_plane since
> fill_dc_plane_info_and_addr isn't called when validating the state, so
> we can't tell if a FULL update is needed or not.
>
> Cc: David Francis 
> Cc: Harry Wentland 
> Signed-off-by: Nicholas Kazlauskas 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 
>  1 file changed, 8 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 a698c8f272ed..45f0d5b6c468 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6446,14 +6446,6 @@ static bool should_reset_plane(struct drm_atomic_state 
> *state,
>  struct drm_crtc_state *new_crtc_state;
>  int i;
>
> -   /*
> -* TODO: Remove this hack once the checks below are sufficient
> -* enough to determine when we need to reset all the planes on
> -* the stream.
> -*/
> -   if (state->allow_modeset)
> -   return true;
> -
>  /* Exit early if we know that we're adding or removing the plane. */
>  if (old_plane_state->crtc != new_plane_state->crtc)
>  return true;
> --
> 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
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amd/display: Don't load DMCU for Raven 1 (v2)

[Mike Lothian]

I realise you don't want to enable this as it's breaking some people's
systems, but could we add a new boot parameter to force it for working
systems? Or check against a black list maybe?

On Fri, 24 May 2019 at 17:20, Alex Deucher  wrote:
>
> On Fri, May 24, 2019 at 12:09 PM Mike Lothian  wrote:
> >
> > Hi
> >
> > Curious to know what this means for folk that have newer Raven1 boards
> > that didn't have issues loading the firmware
>
> You won't get ABM I think.  ABM is the automatic backlight management.
>
> Alex
>
> >
> > Cheers
> >
> > Mike
> >
> > On Fri, 24 May 2019 at 16:34, Alex Deucher  wrote:
> > >
> > > From: Harry Wentland 
> > >
> > > [WHY]
> > > Some early Raven boards had a bad SBIOS that doesn't play nicely with
> > > the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU
> > > load but that doesn't seem to be the case. We've still seen reports of
> > > users unable to boot their systems at all.
> > >
> > > [HOW]
> > > Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso.
> > >
> > > v2: Fix ifdef (Alex)
> > >
> > > Signed-off-by: Harry Wentland 
> > > Reviewed-by: Nicholas Kazlauskas 
> > > Signed-off-by: Alex Deucher 
> > > Cc: sta...@vger.kernel.org
> > > ---
> > >  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++--
> > >  1 file changed, 10 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 995f9df66142..bcb1a93c0b4c 100644
> > > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > > @@ -29,6 +29,7 @@
> > >  #include "dm_services_types.h"
> > >  #include "dc.h"
> > >  #include "dc/inc/core_types.h"
> > > +#include "dal_asic_id.h"
> > >
> > >  #include "vid.h"
> > >  #include "amdgpu.h"
> > > @@ -640,7 +641,7 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev)
> > >
> > >  static int load_dmcu_fw(struct amdgpu_device *adev)
> > >  {
> > > -   const char *fw_name_dmcu;
> > > +   const char *fw_name_dmcu = NULL;
> > > int r;
> > > const struct dmcu_firmware_header_v1_0 *hdr;
> > >
> > > @@ -663,7 +664,14 @@ static int load_dmcu_fw(struct amdgpu_device *adev)
> > > case CHIP_VEGA20:
> > > return 0;
> > > case CHIP_RAVEN:
> > > -   fw_name_dmcu = FIRMWARE_RAVEN_DMCU;
> > > +#if defined(CONFIG_DRM_AMD_DC_DCN1_01)
> > > +   if (ASICREV_IS_PICASSO(adev->external_rev_id))
> > > +   fw_name_dmcu = FIRMWARE_RAVEN_DMCU;
> > > +   else if (ASICREV_IS_RAVEN2(adev->external_rev_id))
> > > +   fw_name_dmcu = FIRMWARE_RAVEN_DMCU;
> > > +   else
> > > +#endif
> > > +   return 0;
> > > break;
> > > default:
> > > DRM_ERROR("Unsupported ASIC type: 0x%X\n", 
> > > adev->asic_type);
> > > --
> > > 2.20.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] drm/amd/display: Don't load DMCU for Raven 1 (v2)

[Mike Lothian]

Hi

Curious to know what this means for folk that have newer Raven1 boards
that didn't have issues loading the firmware

Cheers

Mike

On Fri, 24 May 2019 at 16:34, Alex Deucher  wrote:
>
> From: Harry Wentland 
>
> [WHY]
> Some early Raven boards had a bad SBIOS that doesn't play nicely with
> the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU
> load but that doesn't seem to be the case. We've still seen reports of
> users unable to boot their systems at all.
>
> [HOW]
> Disable DMCU load on Raven 1. Only load it for Raven 2 and Picasso.
>
> v2: Fix ifdef (Alex)
>
> Signed-off-by: Harry Wentland 
> Reviewed-by: Nicholas Kazlauskas 
> Signed-off-by: Alex Deucher 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++--
>  1 file changed, 10 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 995f9df66142..bcb1a93c0b4c 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -29,6 +29,7 @@
>  #include "dm_services_types.h"
>  #include "dc.h"
>  #include "dc/inc/core_types.h"
> +#include "dal_asic_id.h"
>
>  #include "vid.h"
>  #include "amdgpu.h"
> @@ -640,7 +641,7 @@ static void amdgpu_dm_fini(struct amdgpu_device *adev)
>
>  static int load_dmcu_fw(struct amdgpu_device *adev)
>  {
> -   const char *fw_name_dmcu;
> +   const char *fw_name_dmcu = NULL;
> int r;
> const struct dmcu_firmware_header_v1_0 *hdr;
>
> @@ -663,7 +664,14 @@ static int load_dmcu_fw(struct amdgpu_device *adev)
> case CHIP_VEGA20:
> return 0;
> case CHIP_RAVEN:
> -   fw_name_dmcu = FIRMWARE_RAVEN_DMCU;
> +#if defined(CONFIG_DRM_AMD_DC_DCN1_01)
> +   if (ASICREV_IS_PICASSO(adev->external_rev_id))
> +   fw_name_dmcu = FIRMWARE_RAVEN_DMCU;
> +   else if (ASICREV_IS_RAVEN2(adev->external_rev_id))
> +   fw_name_dmcu = FIRMWARE_RAVEN_DMCU;
> +   else
> +#endif
> +   return 0;
> break;
> default:
> DRM_ERROR("Unsupported ASIC type: 0x%X\n", adev->asic_type);
> --
> 2.20.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: [RFC] drm/amd/display: add SI support to AMD DC

[Mike Lothian]

I thought it just required the existing firmware, with padding / extra info
put around it?

On Mon, 8 Oct 2018 at 12:29 Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:

> UVD/VCE on SI with amdgpu would need new firmware.
>
> And so far we never had time to actually look into releasing that firmware.
>
> Regards,
> Christian.
>
>
> Am 08.10.2018 um 13:22 schrieb Mauro Rossi:
>
> Hi Mike,
> On Mon, Oct 8, 2018 at 1:00 PM Mike Lothian  wrote:
>
>> Hi Mauro
>>
>> Do you know if there are any plans to add in UVD support on SI too?
>>
>> Thanks
>>
>> Mike
>>
>
> At the moment my focus is on getting a conformant, working and stable
> implementation of Atomic Display Framework, with the objective to have it
> upstreamed to amd-gfx branch, then staging (drm-next) and maybe merged in
> linux kernel.
>
> To be honest my attempt is based on code paths inspection and mimicking,
> so in this moment I do not even know the state of UVD and what changes are
> needed,
> but, based on what I saw for DCE6 support addition on top of DCE8,
> covering all compatible HW modules makes a lot of sense and it is an
> opportunity to exploit,
> if feasible.
>
> For this to happen in most complete and reliable way the feedback of staff
> who worked on DAL/DC
> will be essential, because what I did now was to adapt code for DCE8 to
> work for DCE6,
> but it was like an "optimistic monkey with a keyboard" approach, with all
> due respect for monkeys with keyboards,
> :-) I may have missed dozen of changes.
>
> Mauro
>
>
>>
>> On Mon, 8 Oct 2018 at 03:24 Mauro Rossi  wrote:
>>
>>> [PATCH 01/10] drm/amd/display: add asics info for SI parts
>>> [PATCH 02/10] drm/amd/display: dc/dce: add DCE6 support
>>> [PATCH 03/10] drm/amd/display: dc/core: add DCE6 support
>>> [PATCH 04/10] drm/amd/display: dc/bios: add support for DCE6
>>> [PATCH 05/10] drm/amd/display: dc/gpio: add support for DCE6
>>> [PATCH 06/10] drm/amd/display: dc/i2caux: add support for DCE6
>>> [PATCH 07/10] drm/amd/display: dc/irq: add support for DCE6
>>> [PATCH 08/10] drm/amd/display: amdgpu_dm: add SI support
>>> [PATCH 09/10] drm/amdgpu: enable DC support for SI parts
>>> [PATCH 10/10] drm/amd/display: enable SI support in the Kconfig
>>>
>>> The series adds preliminar SI support as a Proof Of Concept,
>>> based on the idea that DCE6 is similar to DCE8, to be reviewed and
>>> refined
>>>
>>> Android-x86 need/motivation lies in the following chain of dependencies:
>>> Vulkan radv requires gbm gralloc prime_fd support,
>>> gbm gralloc requires drm hwcomposer,
>>> drm hwcomposer requires Atomic Display Framework,
>>> Atomic Display Framework requires AMD DC, currently not supporting SI.
>>>
>>> So the goals are:
>>> 1) to get Vulkan radv working on SI parts for android-x86.
>>> 2) to remove the gap in SI (GCN 1st gen) not having atomic support.
>>>
>>> DCE6 specific code was implemented as a replica of existing DCE8 support
>>> and based on how DCE8 specific code was added on top of DCE10,11 support
>>> by adding dce60* sources, functions, macros for each existing in dce80*
>>>
>>> CONFIG_DRM_AMD_DC_SI parameter has been added to control SI support in DC
>>>
>>> During this first iteration of review, there are aspects to verify:
>>> - dce60 code has been added mechanically, so there may be redundancies
>>> and space for refactoring part of the code
>>> - dce60_resources was having too many building errors due to missing
>>> DCE6 macros
>>> in order to temporarily overcome the problem dce_8_0_{d,sh_mask}.h
>>> headers
>>> were used for the PoC
>>> - dc/irq suffered the same problem dce_8_0_{d,sh_mask}.h headers
>>> were used for the PoC
>>> - gfx6 may require some ad hoc initialization, skipped for the moment
>>> - Hainan specific code requires review, as some documentation and code
>>> paths
>>> seem to point that famility may not have DCE6, please confirm
>>> - video decoding blocks code have not been touched
>>> - dc/dce/dce_clock_source.{c,h} may be missing some SI/DCE6 specifics
>>> - dc/dce/dce_dmcu.{c,h} may be missing some SI/DCE6 specifics
>>> - dc/dce/dce_hwseq.h may be missing some SI/DCE6 specifics
>>> - dc/dce/dce_link_encoder.h may be missing some SI/DCE6 specifics
>>> - dc/dce/dce_stream_encoder.h may be missing some SI/DCE6 specifics
>>> - dc/amdgpu_dm/

Re: [RFC] drm/amd/display: add SI support to AMD DC

[Mike Lothian]

Hi Mauro

Do you know if there are any plans to add in UVD support on SI too?

Thanks

Mike

On Mon, 8 Oct 2018 at 03:24 Mauro Rossi  wrote:

> [PATCH 01/10] drm/amd/display: add asics info for SI parts
> [PATCH 02/10] drm/amd/display: dc/dce: add DCE6 support
> [PATCH 03/10] drm/amd/display: dc/core: add DCE6 support
> [PATCH 04/10] drm/amd/display: dc/bios: add support for DCE6
> [PATCH 05/10] drm/amd/display: dc/gpio: add support for DCE6
> [PATCH 06/10] drm/amd/display: dc/i2caux: add support for DCE6
> [PATCH 07/10] drm/amd/display: dc/irq: add support for DCE6
> [PATCH 08/10] drm/amd/display: amdgpu_dm: add SI support
> [PATCH 09/10] drm/amdgpu: enable DC support for SI parts
> [PATCH 10/10] drm/amd/display: enable SI support in the Kconfig
>
> The series adds preliminar SI support as a Proof Of Concept,
> based on the idea that DCE6 is similar to DCE8, to be reviewed and refined
>
> Android-x86 need/motivation lies in the following chain of dependencies:
> Vulkan radv requires gbm gralloc prime_fd support,
> gbm gralloc requires drm hwcomposer,
> drm hwcomposer requires Atomic Display Framework,
> Atomic Display Framework requires AMD DC, currently not supporting SI.
>
> So the goals are:
> 1) to get Vulkan radv working on SI parts for android-x86.
> 2) to remove the gap in SI (GCN 1st gen) not having atomic support.
>
> DCE6 specific code was implemented as a replica of existing DCE8 support
> and based on how DCE8 specific code was added on top of DCE10,11 support
> by adding dce60* sources, functions, macros for each existing in dce80*
>
> CONFIG_DRM_AMD_DC_SI parameter has been added to control SI support in DC
>
> During this first iteration of review, there are aspects to verify:
> - dce60 code has been added mechanically, so there may be redundancies
> and space for refactoring part of the code
> - dce60_resources was having too many building errors due to missing DCE6
> macros
> in order to temporarily overcome the problem dce_8_0_{d,sh_mask}.h headers
> were used for the PoC
> - dc/irq suffered the same problem dce_8_0_{d,sh_mask}.h headers
> were used for the PoC
> - gfx6 may require some ad hoc initialization, skipped for the moment
> - Hainan specific code requires review, as some documentation and code
> paths
> seem to point that famility may not have DCE6, please confirm
> - video decoding blocks code have not been touched
> - dc/dce/dce_clock_source.{c,h} may be missing some SI/DCE6 specifics
> - dc/dce/dce_dmcu.{c,h} may be missing some SI/DCE6 specifics
> - dc/dce/dce_hwseq.h may be missing some SI/DCE6 specifics
> - dc/dce/dce_link_encoder.h may be missing some SI/DCE6 specifics
> - dc/dce/dce_stream_encoder.h may be missing some SI/DCE6 specifics
> - dc/amdgpu_dm/* changes may be incomplete
> - Any other omissis to be reviewed
> - Feedback on best testing strategy required
>
> Review from an expert of the DC impacted modules is recommended
>
> SW Layer
> /===\
> | DCDisplay Timing  ModeAsic|
> | Interface Service Service Manager Capability* |
> |   |
> | Display   TopologyDisplay LinkAdapter |
> | Path  Manager Capability  Service Service |
> |   Service |
> |---|
> | GPIO* IRQ I2cAux  HW  BIOS|
> |   Service**   Manager*Sequencer*  Parser* |
> |   |
> | Connector Encoder Audio   GPU Controller  |
> |   |
> \===/
> HW Layer
>
> Legend:
> *dce60 support was added cleanly with dce_6_0_{d,sh_mask}.h headers
> **dce60 support was added using dce_8_0_{d,sh_mask}.h headers
>
> Android-x86 preliminary tests results:
>
> [Boots with drm gralloc]
> 3DMark Slingshot
> GFXbench OpenGLES benchmarks OK
> V1 GPU benchmark (OpenGLES) OK
> Regression in Google Chrome, Youtube (app does not show up)
> Regression in Olympus Rising,  Chicken Invaders (app does not show up)
>
> [Boots with drm hwcomposer + gbm gralloc]
> Google Chrome, Youtube are OK
> Vulkan radv HAL API becomes available with hwc+gbm gralloc
> V1 GPU benchmark (Vulkan API) OK
> Sacha Willems examples OK
> Some glitch/freeze in 3DMark Slingshot Extreeme and API overhead
>
> Kind regards
>
> Mauro Rossi
> android-x86 team
>
> ___
> 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 v2 0/3] A DRM API for adaptive sync and variable refresh rate support

[Mike Lothian]

Hi

I'm curious to know whether this will/could work over PRIME

If the discrete card is rendering slower than the display's frequency could
the frequency be dropped on integrated display? I think there are laptops
that have freesync now

Cheers

Mike

On Mon, 1 Oct 2018 at 08:15 Daniel Vetter  wrote:

> On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote:
> > These patches are part of a proposed new interface for supporting
> variable refresh rate via DRM properties.
> >
> > === Changes from v1 ===
> >
> > For drm:
> >
> > * The variable_refresh_capable property is now flagged as
> DRM_MODE_PROP_IMMUTABLE
> >
> > For drm/gpu/amd/display:
> >
> > * Patches no longer pull in IOCTL/FreeSync refactoring code
> > * FreeSync enable/disable behavior has been modified to reflect changes
> in userspace behavior from xf86-video-amdgpu and mesa
> >
> > === Adaptive sync and variable refresh rate ===
> >
> > Adaptive sync is part of the DisplayPort spec and allows for graphics
> adapters to drive displays with varying frame timings.
> >
> > Variable refresh rate (VRR) is essentially the same, but defined for
> HDMI.
> >
> > === Use cases for variable refresh rate ===
> >
> > Variable frame (flip) timings don't align well with fixed refresh rate
> displays. This results in stuttering, tearing and/or input lag. By
> adjusting the display refresh rate dynamically these issues can be reduced
> or eliminated.
> >
> > However, not all content is suitable for dynamic refresh adaptation.
> Content that is flipped infrequently or at random intervals tends to fair
> poorly. Multiple clients trying to flip under the same screen can similarly
> interfere with prediction.
> >
> > Userland needs a way to let the driver know when the content on the
> screen is suitable for variable refresh rate and if the user wishes to have
> the feature enabled.
> >
> > === DRM API to support variable refresh rates ===
> >
> > This patch introduces a new API via atomic properties on the DRM
> connector and CRTC.
> >
> > The connector has two new optional properties:
> >
> > * bool variable_refresh_capable - set by the driver if the hardware is
> capable of supporting variable refresh tech
> >
> > * bool variable_refresh_enabled - set by the user to enable variable
> refresh adjustment over the connector
> >
> > The CRTC has one additional default property:
> >
> > * bool variable_refresh - a content hint to the driver specifying that
> the CRTC contents are suitable for variable refresh adjustment
> >
> > == Overview for DRM driver developers ===
> >
> > Driver developers can attach the optional connector properties via
> drm_connector_attach_variable_refresh_properties on connectors that support
> variable refresh (typically DP or HDMI).
> >
> > The variable_refresh_capable property should be managed as the output on
> the connector changes. The property is read only from userspace.
> >
> > The variable_refresh_enabled property is intended to be a property
> controlled by userland as a global on/off switch for variable refresh
> technology. It should be checked before enabling variable refresh rate.
> >
> > === Overview for Userland developers ==
> >
> > The variable_refresh property on the CRTC should be set to true when the
> CRTCs are suitable for variable refresh rate. In practice this is probably
> an application like a game - a single window that covers the whole CRTC
> surface and is the only client issuing flips.
> >
> > To demonstrate the suitability of the API for variable refresh and
> dynamic adaptation there are additional patches using this API that
> implement adaptive variable refresh across kernel and userland projects:
> >
> > * DRM (dri-devel)
> > * amdgpu DRM kernel driver (amd-gfx)
> > * xf86-video-amdgpu (amd-gfx)
> > * mesa (mesa-dev)
> >
> > These patches enable adaptive variable refresh on X for AMD hardware
> provided that the user sets the variable_refresh_enabled property to true
> on supported connectors (ie. using xrandr --set-prop).
> >
> > The patches have been tested as working on upstream userland with the
> GNOME desktop environment under a single monitor setup. They also work on
> KDE in single monitor setup if the compositor is disabled.
> >
> > The patches require that the application window can issue screen flips
> via the Present extension to xf86-video-amdgpu. Due to Present extension
> limitations some desktop environments and multi-monitor setups are
> currently not compatible.
> >
> > Full implementation details for these changes can be reviewed in their
> respective mailing lists.
> >
> > === Previous discussions ===
> >
> > These patches are based upon feedback from patches and feedback from two
> previous threads on the subject which are linked below for reference:
> >
> > https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html
> >
> https://lists.freedesktop.org/archives/dri-devel/2017-October/155207.html
> >
> 

Re: VegaM DP dpms issue

[Mike Lothian]

Hi

I'm pretty sure unless you're offloading using DRI_PRIME=1 then it'll be
your Intel graphics that'll be driving the displays

I'd recommend you raise a bug on https://bugs.freedesktop.org/ under DRI
then DRM/Intel

Make sure you attach your dmesg and Xorg.0.log and hopefully they'll be
able to help

Cheers

Mike

On Sun, 30 Sep 2018 at 17:23 Louis Garcia  wrote:

> I am having an issue with intel NUC8i7HNK with AMD Vega M. I have three
> Dell U2415 monitors connected to one mDP daisychained. When the monitors go
> to sleep (dpms) trying to wake up the monitors after half hour or more
> fails, touching the keyboard and mouse. Only way is a hard reboot. Same
> monitors connected to other systems wake up fine. I seen old bug reports on
> this issue but seems I'm hitting this bug again.
>
> If this is not the proper list please let me kno. --Thanks
> ___
> 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 2/2] drm/ttm: once more fix ttm_bo_bulk_move_lru_tail v2

[Mike Lothian]

Hi

This fixes a boot issue I had on Raven (
https://bugs.freedesktop.org/show_bug.cgi?id=107922)

Feel free to add to both patches:

Tested-by: Mike Lothian 

Cheers

Mike

On Thu, 13 Sep 2018 at 12:22 Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:

> While cutting the lists we sometimes accidentally added a list_head from
> the stack to the LRUs, effectively corrupting the list.
>
> Remove the list cutting and use explicit list manipulation instead.
>
> v2: separate out new list_bulk_move_tail helper
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c | 46
> +++-
>  1 file changed, 20 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 138c98902033..26b889f86670 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -247,47 +247,38 @@ void ttm_bo_move_to_lru_tail(struct
> ttm_buffer_object *bo,
>  }
>  EXPORT_SYMBOL(ttm_bo_move_to_lru_tail);
>
> -static void ttm_bo_bulk_move_helper(struct ttm_lru_bulk_move_pos *pos,
> -   struct list_head *lru, bool is_swap)
> -{
> -   struct list_head *list;
> -   LIST_HEAD(entries);
> -   LIST_HEAD(before);
> -
> -   reservation_object_assert_held(pos->last->resv);
> -   list = is_swap ? >last->swap : >last->lru;
> -   list_cut_position(, lru, list);
> -
> -   reservation_object_assert_held(pos->first->resv);
> -   list = is_swap ? pos->first->swap.prev : pos->first->lru.prev;
> -   list_cut_position(, , list);
> -
> -   list_splice(, lru);
> -   list_splice_tail(, lru);
> -}
> -
>  void ttm_bo_bulk_move_lru_tail(struct ttm_lru_bulk_move *bulk)
>  {
> unsigned i;
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> +   struct ttm_lru_bulk_move_pos *pos = >tt[i];
> struct ttm_mem_type_manager *man;
>
> -   if (!bulk->tt[i].first)
> +   if (!pos->first)
> continue;
>
> -   man = >tt[i].first->bdev->man[TTM_PL_TT];
> -   ttm_bo_bulk_move_helper(>tt[i], >lru[i], false);
> +   reservation_object_assert_held(pos->first->resv);
> +   reservation_object_assert_held(pos->last->resv);
> +
> +   man = >first->bdev->man[TTM_PL_TT];
> +   list_bulk_move_tail(>lru[i], >first->lru,
> +   >last->lru);
> }
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> +   struct ttm_lru_bulk_move_pos *pos = >vram[i];
> struct ttm_mem_type_manager *man;
>
> -   if (!bulk->vram[i].first)
> +   if (!pos->first)
> continue;
>
> -   man = >vram[i].first->bdev->man[TTM_PL_VRAM];
> -   ttm_bo_bulk_move_helper(>vram[i], >lru[i],
> false);
> +   reservation_object_assert_held(pos->first->resv);
> +   reservation_object_assert_held(pos->last->resv);
> +
> +   man = >first->bdev->man[TTM_PL_VRAM];
> +   list_bulk_move_tail(>lru[i], >first->lru,
> +   >last->lru);
> }
>
> for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
> @@ -297,8 +288,11 @@ void ttm_bo_bulk_move_lru_tail(struct
> ttm_lru_bulk_move *bulk)
> if (!pos->first)
> continue;
>
> +   reservation_object_assert_held(pos->first->resv);
> +   reservation_object_assert_held(pos->last->resv);
> +
> lru = >first->bdev->glob->swap_lru[i];
> -   ttm_bo_bulk_move_helper(>swap[i], lru, true);
> +   list_bulk_move_tail(lru, >first->swap,
> >last->swap);
> }
>  }
>  EXPORT_SYMBOL(ttm_bo_bulk_move_lru_tail);
> --
> 2.14.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v5 0/5] drm/ttm, amdgpu: Introduce LRU bulk move functionality

[Mike Lothian]

Hi

Is there an updated series? These no longer apply for me

Thanks

Mike

On Wed, 22 Aug 2018 at 09:42 Huang Rui  wrote:

> On Wed, Aug 22, 2018 at 04:24:02PM +0800, Christian König wrote:
> > Please commit patches #1, #2 and #3, doesn't make much sense to send
> > them out even more often.
> >
> > Jerry's comments on patch #4 sound valid to me as well, but with those
> > minor issues fixes/commented I think we can commit it.
> >
> > Thanks for taking care of this,
> > Christian.
>
> OK. Thanks to your time.
>
> Thanks,
> Ray
>
> >
> > Am 22.08.2018 um 09:52 schrieb Huang Rui:
> > > The idea and proposal is originally from Christian, and I continue to
> work to
> > > deliver it.
> > >
> > > Background:
> > > amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then
> move all of
> > > them on the end of LRU list one by one. Thus, that cause so many BOs
> moved to
> > > the end of the LRU, and impact performance seriously.
> > >
> > > Then Christian provided a workaround to not move PD/PT BOs on LRU with
> below
> > > patch:
> > > Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae ("drm/amdgpu: band aid
> > > validating VM PTs")
> > >
> > > However, the final solution should bulk move all PD/PT and PerVM BOs
> on the LRU
> > > instead of one by one.
> > >
> > > Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which
> need to be
> > > validated we move all BOs together to the end of the LRU without
> dropping the
> > > lock for the LRU.
> > >
> > > While doing so we note the beginning and end of this block in the LRU
> list.
> > >
> > > Now when amdgpu_vm_validate_pt_bos() is called and we don't have
> anything to do,
> > > we don't move every BO one by one, but instead cut the LRU list into
> pieces so
> > > that we bulk move everything to the end in just one operation.
> > >
> > > Test data:
> > >
> +--+-+---+---+
> > > |  |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
>   |
> > > |  |Principle(Vulkan)|   |
>|
> > >
> ++
> > > |  | |   |0.319 ms(1k) 0.314
> ms(2K) 0.308 ms(4K) |
> > > | Original |  147.7 FPS  |  76.86 us |0.307 ms(8K) 0.310
> ms(16K) |
> > >
> ++
> > > | Orignial + WA| |   |0.254 ms(1K) 0.241
> ms(2K)  |
> > > |(don't move   |  162.1 FPS  |  42.15 us |0.230 ms(4K) 0.223
> ms(8K) 0.204 ms(16K)|
> > > |PT BOs on LRU)| |   |
>|
> > >
> ++
> > > | Bulk move|  163.1 FPS  |  40.52 us |0.244 ms(1K) 0.252
> ms(2K) 0.213 ms(4K) |
> > > |  | |   |0.214 ms(8K) 0.225
> ms(16K) |
> > >
> +--+-+---+---+
> > >
> > > After test them with above three benchmarks include vulkan and opencl.
> We can
> > > see the visible improvement than original, and even better than
> original with
> > > workaround.
> > >
> > > Changes from V1 -> V2:
> > > - Fix to missed the BOs in relocated/moved that should be also moved
> to the end
> > >of LRU.
> > >
> > > Changes from V2 -> V3:
> > > - Remove unused parameter and use list_for_each_entry instead of the
> one with
> > >save entry.
> > >
> > > Changes from V3 -> V4:
> > > - Move the amdgpu_vm_move_to_lru_tail after command submission, at
> that time,
> > >all bo will be back on idle list.
> > >
> > > Changes from V4 -> V5:
> > > - Remove amdgpu_vm_move_to_lru_tail_by_list(), use bulk_moveable
> instread of
> > >validated, and move ttm_bo_bulk_move_lru_tail() also into
> > >amdgpu_vm_move_to_lru_tail().
> > >
> > > Thanks,
> > > Ray
> > >
> > > Christian König (2):
> > >drm/ttm: add helper structures for bulk moves on lru list
> > >drm/ttm: revise ttm_bo_move_to_lru_tail to support bulk moves
> > >
> > > Huang Rui (3):
> > >drm/ttm: add bulk move function on LRU
> > >drm/amdgpu: use bulk moves for efficient VM LRU handling (v5)
> > >drm/amdgpu: move PD/PT bos on LRU again
> > >
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 10 +
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 68
> +++--
> > >   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 11 -
> > >   drivers/gpu/drm/ttm/ttm_bo.c   | 78
> +-
> > >   include/drm/ttm/ttm_bo_api.h   | 16 ++-
> > >   include/drm/ttm/ttm_bo_driver.h| 28 
> > >   6 files changed, 186 insertions(+), 25 deletions(-)
> > >
> >
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> 

Re: [PATCH v2 0/5] drm/ttm, amdgpu: Introduce LRU bulk move functionality

[Mike Lothian]

Hi

I've been testing these patches over the weekend on my Tonga and Raven
systems

Tested-by: Mike Lothian 

Cheers

Mike

On Fri, 10 Aug 2018 at 12:56 Huang Rui  wrote:

> The idea and proposal is originally from Christian, and I continue to work
> to
> deliver it.
>
> Background:
> amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move
> all of
> them on the end of LRU list one by one. Thus, that cause so many BOs moved
> to
> the end of the LRU, and impact performance seriously.
>
> Then Christian provided a workaround to not move PD/PT BOs on LRU with
> below
> patch:
> "drm/amdgpu: band aid validating VM PTs"
> Commit 0bbf32026cf5ba41e9922b30e26e1bed1ecd38ae
>
> However, the final solution should bulk move all PD/PT and PerVM BOs on
> the LRU
> instead of one by one.
>
> Whenever amdgpu_vm_validate_pt_bos() is called and we have BOs which need
> to be
> validated we move all BOs together to the end of the LRU without dropping
> the
> lock for the LRU.
>
> While doing so we note the beginning and end of this block in the LRU list.
>
> Now when amdgpu_vm_validate_pt_bos() is called and we don't have anything
> to do,
> we don't move every BO one by one, but instead cut the LRU list into
> pieces so
> that we bulk move everything to the end in just one operation.
>
> Test data:
>
> +--+-+---+---+
> |  |The Talos|Clpeak(OCL)|BusSpeedReadback(OCL)
>   |
> |  |Principle(Vulkan)|   |
>|
>
> ++
> |  | |   |0.319 ms(1k) 0.314 ms(2K)
> 0.308 ms(4K) |
> | Original |  147.7 FPS  |  76.86 us |0.307 ms(8K) 0.310 ms(16K)
>|
>
> ++
> | Orignial + WA| |   |0.254 ms(1K) 0.241 ms(2K)
>   |
> |(don't move   |  162.1 FPS  |  42.15 us |0.230 ms(4K) 0.223 ms(8K)
> 0.204 ms(16K)|
> |PT BOs on LRU)| |   |
>|
>
> ++
> | Bulk move|  163.1 FPS  |  40.52 us |0.244 ms(1K) 0.252 ms(2K)
> 0.213 ms(4K) |
> |  | |   |0.214 ms(8K) 0.225 ms(16K)
>|
>
> +--+-+---+---+
>
> After test them with above three benchmarks include vulkan and opencl. We
> can
> see the visible improvement than original, and even better than original
> with
> workaround.
>
> Changes from V1 -> V2:
> - Fix to missed the BOs in relocated/moved that should be also moved to
> the end
>   of LRU.
>
> Thanks,
> Rui
>
> Christian König (2):
>   drm/ttm: add helper structures for bulk moves on lru list
>   drm/ttm: revise ttm_bo_move_to_lru_tail to support bulk moves
>
> Huang Rui (3):
>   drm/ttm: add bulk move function on LRU
>   drm/amdgpu: use bulk moves for efficient VM LRU handling (v2)
>   drm/amdgpu: move PD/PT bos on LRU again
>
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 77
> +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  4 ++
>  drivers/gpu/drm/ttm/ttm_bo.c   | 78
> +-
>  include/drm/ttm/ttm_bo_api.h   | 16 ++-
>  include/drm/ttm/ttm_bo_driver.h| 28 
>  5 files changed, 184 insertions(+), 19 deletions(-)
>
> --
> 2.7.4
>
> ___
> 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/amdgpu: Don't warn on destroying a pinned BO

[Mike Lothian]

Hi

I was hitting this

Feel free to add my tested by

Tested-by: Mike Lothian 

Cheers

Mike

On Mon, 23 Jul 2018 at 17:50 Michel Dänzer  wrote:

> On 2018-07-19 05:39 PM, Michel Dänzer wrote:
> > From: Michel Dänzer 
> >
> > The warning turned out to be not so useful, as BO destruction tends to
> > be deferred to a workqueue.
> >
> > Also, we should be preventing any damage from this now, so not really
> > important anymore to fix code doing this.
> >
> > Signed-off-by: Michel Dänzer 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > index b12526ce1a9d..3010f0136de9 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> > @@ -89,7 +89,7 @@ static void amdgpu_ttm_bo_destroy(struct
> ttm_buffer_object *tbo)
> >   struct amdgpu_device *adev = amdgpu_ttm_adev(tbo->bdev);
> >   struct amdgpu_bo *bo = ttm_to_amdgpu_bo(tbo);
> >
> > - if (WARN_ON_ONCE(bo->pin_count > 0))
> > + if (bo->pin_count > 0)
> >   amdgpu_bo_subtract_pin_size(bo);
> >
> >   if (bo->kfd_bo)
> >
>
> Any feedback?
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.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
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 0/6] Raven support for KFD

[Mike Lothian]

Hi

I'm happy to test this out, just wondering what userspace I should pair it
with

Cheers

Mike

On Thu, 12 Jul 2018 at 22:25 Felix Kuehling  wrote:

> Raven refers to Ryzen APUs with integrated GFXv9 GPU.
> This patch series completes Raven support for KFD:
>
> * fix up memory banks info from CRAT
> * support different number of SDMA engines
> * workaround IOMMUv2 PPR issues
> * add device info
>
> Yong Zhao (6):
>   drm/amdkfd: Consolidate duplicate memory banks info in topology
>   drm/amdkfd: Make SDMA engine number an ASIC-dependent variable
>   drm/amdkfd: Avoid flooding dmesg on Raven due to IOMMU issues
>   drm/amdkfd: Workaround to accommodate Raven too many PPR issue
>   drm/amdkfd: Optimize out some duplicated code in
> kfd_signal_iommu_event()
>   drm/amdkfd: Enable Raven for KFD
>
>  drivers/gpu/drm/amd/amdkfd/kfd_crat.c  | 57
> +-
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c| 28 +++
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  | 29 +++
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |  6 +--
>  drivers/gpu/drm/amd/amdkfd/kfd_events.c| 47 ++
>  drivers/gpu/drm/amd/amdkfd/kfd_iommu.c |  2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |  1 +
>  .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |  3 +-
>  8 files changed, 126 insertions(+), 47 deletions(-)
>
> --
> 2.7.4
>
> ___
> 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 xf86-video-amdgpu 0/7] Enabling Color Management - Round 3

[Mike Lothian]

It seems messy having to create a whole xorg.conf just for one parameter

On Thu, 7 Jun 2018 at 08:31 Michel Dänzer  wrote:

> On 2018-06-07 09:22 AM, Mike Lothian wrote:
> > Hi
> >
> > Is there a way to set depth using a xorg.conf.d snippet rather than
> > creating an xorg.conf?
>
> Sure (the xorg.conf.d snippets are simply concatenated together with
> xorg.conf, so anything can go in either of them), but it's the wrong way
> to do it. :)
>
> The xorg.conf.d mechanism is for shipping snippets required for a driver
> or other Xorg module to work out of the box. xorg.conf is still the
> place for actual configuration.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.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 xf86-video-amdgpu 0/7] Enabling Color Management - Round 3

[Mike Lothian]

Hi

Is there a way to set depth using a xorg.conf.d snippet rather than
creating an xorg.conf?

Cheers

Mike

On Wed, 6 Jun 2018 at 17:01 Michel Dänzer  wrote:

>
> Hi Leo,
>
>
> On 2018-06-01 06:03 PM, sunpeng...@amd.com wrote:
> > From: "Leo (Sunpeng) Li" 
> >
> > This ended up being different enough from v2 to warrant a new patchset.
> Per
> > Michel's suggestions, there have been various optimizations and cleanups.
> > Here's what's changed:
> >
> > * Cache DRM color management property IDs at pre-init,
> > * instead of querying DRM each time we need to modify color
> properties.
> >
> > * Remove drmmode_update_cm_props().
> > * Update color properties in drmmode_output_get_property() instead.
> > * This also makes old calls to update_cm_props redundant.
> >
> > * Get rid of fake CRTCs.
> > * Previously, we were allocating a fake CRTC to configure color
> props on
> >   outputs that don't have a CRTC.
> > * Instead, rr_configure_and_change_cm_property() can be easily
> modified to
> >   accept NULL CRTCs.
> >
> > * Drop patches to persist color properties across DPMS events.
> > * Kernel driver should be patched instead:
> >
> https://lists.freedesktop.org/archives/amd-gfx/2018-May/022744.html
> > * Color props including legacy gamma now persist across crtc dpms.
> > * Non-legacy props now persist across output dpms and hotplug, as
> long
> >   as the same CRTC remains attached to that output.
> >
> > And some smaller improvements:
> >
> > * Change CTM to be 32-bit format instead of 16-bit.
> > * This requires clients to ensure that each 32-bit element is padded
> to be
> >   long-sized, since libXrandr parses 32-bit format as long-typed.
> >
> > * Optimized color management init during CRTC init.
> > * Query DRM once for the list of properties, instead of twice.
>
> Sounds good. I'll be going through the patches in detail from now on,
> but I don't know yet when I'll be able to finish the review.
>
>
> Meanwhile, heads up on two issues I discovered while smoke-testing the
> series (which are sort of related, but occur even without this series):
>
>
> Running Xorg in depth 30[0] results in completely wrong colours
> (everything has a red tint) with current kernels. I think this is
> because DC now preserves the gamma LUT values, but xf86-video-amdgpu
> never sets them at depth 30, so the hardware is still using values for
> 24-bit RGB.
>
> Can you look into making xf86-video-amdgpu set the LUT values at depth
> 30 as well? Ideally in a way which doesn't require all patches in this
> series, so that it could be backported for a 18.0.2 point release if
> necessary. (Similarly for skipping drmmode_cursor_gamma when the kernel
> supports the new colour management properties, to fix
> https://bugs.freedesktop.org/106578)
>
>
> Trying to run Xorg in depth 16 or 8[0] results in failure to set any mode:
>
> [56.138] (EE) AMDGPU(0): failed to set mode: Invalid argument
> [56.138] (WW) AMDGPU(0): Failed to set mode on CRTC 0
> [56.172] (EE) AMDGPU(0): Failed to enable any CRTC
>
> Works fine with amdgpu.dc=0. This has been broken at least since the
> 4.16 development cycle.
>
>
> [0] You can change Xorg's colour depth either via -depth on its command
> line, or via the xorg.conf screen section:
>
> Section "Screen"
> Identifier "Screen0"
> DefaultDepth 30 # or 16 or 8
> EndSection
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.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
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Raven Ridge Ryzen 2500U hang reproduced

[Mike Lothian]

On Tue, 27 Mar 2018, 00:30 Bráulio Bhavamitra,  wrote:

> Hi all,
>
> Following the random crashes happenning with many users (e.g.
> https://www.phoronix.com/scan.php?page=news_item;
> px=Raven-Ridge-March-Update), not only on Linux but also Windows, I've
> been struggling to reproduce and generate any error log.
>
> After discovering that the error only happenned with KDE and games (at
> least for me, see https://bugs.kde.org/show_bug.cgi?id=392378), I could
> reproduce after a failing suspend.
>
> The crash most of the times allows the mouse to keep moving, but anything
> else works. Except for this time the keyboard worked so I could switch the
> tty and save the dmesg messages. After this I had to force reboot as it got
> stuck trying to kill the lightdm service (gpu hanged?).
>
> The errors are, see attached the full dmesg:
> [ 2899.525650] amdgpu :03:00.0: couldn't schedule ib on ring 
> [ 2899.525769] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs
> (-22)
> [ 2909.125047] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx
> timeout, last signaled seq=174624, last emitted seq=174627
> [ 2909.125060] [drm] IP block:psp is hung!
> [ 2909.125063] [drm] GPU recovery disabled.
> [ 2914.756931] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR*
> amdgpu_cs_list_validate(validated) failed.
> [ 2914.756997] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to process
> the buffer list -16!
> [ 2914.997372] amdgpu :03:00.0: couldn't schedule ib on ring 
> [ 2914.997498] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs
> (-22)
> [ 2930.117275] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR*
> amdgpu_cs_list_validate(validated) failed.
> [ 2930.117405] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to process
> the buffer list -16!
> [ 2930.152015] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear
> memory with ring turned off.
> [ 2930.157940] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear
> memory with ring turned off.
> [ 2930.180535] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear
> memory with ring turned off.
> [ 2933.781692] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
> [ 2945.477205] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR*
> amdgpu_cs_list_validate(validated) failed.
> [ 2945.477348] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to process
> the buffer list -16!
>
> System details:
> HP Envy x360 Ryzen 2500U
> ArchLinux, kernel 4.16rc6 and 4.15.12
>
> Cheers,
> bráulio
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Hi

I think I've seen that issue in KDE too, where the mouse moves but nothing
else works. I found that switching VT's and back again fixes things for me

The weird thing is I'm seeing this on i965 (amdgpu is used for games only
with PRIME)

What version of X, Qt, KDE Frameworks and Plasma are you using?

Cheers

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

Re: [PATCH] drm/amdgpu: fix "mitigate workaround for i915"

[Mike Lothian]

On 21 March 2018 at 13:08, Christian König
<ckoenig.leichtzumer...@gmail.com> wrote:
> Mixed up exporter and importer here. E.g. while mapping the BO we need
> to check the importer not the exporter.
>
> Signed-off-by: Christian König <christian.koe...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index 1c9991738477..4b584cb75bf4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -132,6 +132,7 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
>  {
> struct drm_gem_object *obj = dma_buf->priv;
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> +   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> long r;
>
> r = drm_gem_map_attach(dma_buf, target_dev, attach);
> @@ -143,7 +144,7 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
> goto error_detach;
>
>
> -   if (dma_buf->ops != _dmabuf_ops) {
> +   if (attach->dev->driver != adev->dev->driver) {
> /*
>  * Wait for all shared fences to complete before we switch to 
> future
>  * use of exclusive fence on this prime shared bo.
> @@ -162,7 +163,7 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
> if (r)
> goto error_unreserve;
>
> -   if (dma_buf->ops != _dmabuf_ops)
> +   if (attach->dev->driver != adev->dev->driver)
> bo->prime_shared_count++;
>
>  error_unreserve:
> @@ -179,6 +180,7 @@ static void amdgpu_gem_map_detach(struct dma_buf *dma_buf,
>  {
> struct drm_gem_object *obj = dma_buf->priv;
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> +   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> int ret = 0;
>
> ret = amdgpu_bo_reserve(bo, true);
> @@ -186,7 +188,7 @@ static void amdgpu_gem_map_detach(struct dma_buf *dma_buf,
> goto error;
>
> amdgpu_bo_unpin(bo);
> -   if (dma_buf->ops != _dmabuf_ops && bo->prime_shared_count)
> +   if (attach->dev->driver != adev->dev->driver && 
> bo->prime_shared_count)
> bo->prime_shared_count--;
> amdgpu_bo_unreserve(bo);
>
> --
> 2.14.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

As per the bug report

Tested-by: Mike Lothian <m...@fireburn.co.uk>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: mitigate workaround for i915

[Mike Lothian]

On Mon, 19 Feb 2018 at 13:58 Christian König  wrote:

> To be able to use DRI_PRIME with amdgpu and i915 we add all our fences
> only as exclusive ones.
>
> Disable that behavior when sharing between amdgpu itself cause it
> hinders concurrent execution.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 31
> ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index f6d7f6404a07..8ce74a1d9966 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -30,6 +30,8 @@
>  #include 
>  #include 
>
> +static const struct dma_buf_ops amdgpu_dmabuf_ops;
> +
>  struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object
> *obj)
>  {
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> @@ -129,20 +131,27 @@ static int amdgpu_gem_map_attach(struct dma_buf
> *dma_buf,
> if (unlikely(r != 0))
> goto error_detach;
>
> -   /*
> -* Wait for all shared fences to complete before we switch to
> future
> -* use of exclusive fence on this prime shared bo.
> -*/
> -   r = reservation_object_wait_timeout_rcu(bo->tbo.resv, true, false,
> -   MAX_SCHEDULE_TIMEOUT);
> -   if (unlikely(r < 0)) {
> -   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
> -   goto error_unreserve;
> +
> +   if (dma_buf->ops != _dmabuf_ops) {
> +   /*
> +* Wait for all shared fences to complete before we switch
> to future
> +* use of exclusive fence on this prime shared bo.
> +*/
> +   r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
> +   true, false,
> +
>  MAX_SCHEDULE_TIMEOUT);
> +   if (unlikely(r < 0)) {
> +   DRM_DEBUG_PRIME("Fence wait failed: %li\n", r);
> +   goto error_unreserve;
> +   }
> }
>
> /* pin buffer into GTT */
> r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
> -   if (likely(r == 0))
> +   if (r)
> +   goto error_unreserve;
> +
> +   if (dma_buf->ops != _dmabuf_ops)
> bo->prime_shared_count++;
>
>  error_unreserve:
> @@ -166,7 +175,7 @@ static void amdgpu_gem_map_detach(struct dma_buf
> *dma_buf,
> goto error;
>
> amdgpu_bo_unpin(bo);
> -   if (bo->prime_shared_count)
> +   if (dma_buf->ops != _dmabuf_ops && bo->prime_shared_count)
> bo->prime_shared_count--;
> amdgpu_bo_unreserve(bo);
>
> --
> 2.14.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Hi

This patch causes tearing / stuttering on my i915/amdgpu prime setup

Reverting this patch and some of  "[PATCH 3/3] drm/amdgpu: further mitigate
workaround for i915" to get it to compile, gets things working again

Sorry for not noticing this sooner

Let me know if you'd like me to test any follow up patches

Cheers

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

Re: [PATCH] drm/amd/display: Fix DCN build breakage

[Mike Lothian]

On Tue, 13 Mar 2018 at 19:32 Harry Wentland <harry.wentl...@amd.com> wrote:

> Fixes: 680acc64120c (drm/amd/display: Set disp clk in a safe way to avoid
> over high dpp clk.)
>
> Signed-off-by: Harry Wentland <harry.wentl...@amd.com>
> ---
>  drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> index 76fc903515ba..78e6beb6cf26 100644
> --- a/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> +++ b/drivers/gpu/drm/amd/display/dc/dce/dce_clocks.c
> @@ -623,6 +623,7 @@ static bool dce_apply_clock_voltage_request(
> }
> }
> if (send_request) {
> +#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
> if (clk->ctx->dce_version >= DCN_VERSION_1_0) {
> struct dc *core_dc = clk->ctx->dc;
> /*use dcfclk request voltage*/
> @@ -630,6 +631,7 @@ static bool dce_apply_clock_voltage_request(
> clock_voltage_req.clocks_in_khz =
> dcn_find_dcfclk_suits_all(core_dc,
> >cur_clocks_value);
> }
> +#endif
> dm_pp_apply_clock_for_voltage_request(
> clk->ctx, _voltage_req);
> }
> --
> 2.14.1
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Tested-by: Mike Lothian <m...@fireburn.co.uk>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: LLVM 7.0 + Wayland = broken mouse control

[Mike Lothian]

I think you can set it by:

echo "allow_rgb10_configs=false" >> /etc/environment

On Tue, 30 Jan 2018 at 16:38 mikhail  wrote:

> On Tue, 2018-01-30 at 11:55 +0100, Michel Dänzer wrote:
> >
> > No, it just means there's an error in the way you're trying to set
> > the
> > workaround. Maybe it needs to be "export allow_rgb10_configs=false"?
> >
> > You can also try the method I described in
> > https://bugs.freedesktop.org/show_bug.cgi?id=104808#c2 , I verified
> > that
> > to work.
> >
>
> You right, my mistake I forgot add export.
> Of cource right variant:
> echo "export allow_rgb10_configs=false" > /etc/profile.d/gnome-
> workaround.sh
>
> Mouse click now works again with latest llvm and mesa.
> It is unfortunate I don't know how apply this variable to the login
> screen (gdm).
>
> Anyway, thanks.
> ___
> 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/amdgpu: remove DC special casing for KB/ML

[Mike Lothian]

On 25 January 2018 at 21:57, Alex Deucher <alexdeuc...@gmail.com> wrote:
> It seems to be working now.
>
> Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102372
> Signed-off-by: Alex Deucher <alexander.deuc...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 309977ef5b51..2ad9de42b65b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1704,6 +1704,8 @@ bool amdgpu_device_asic_has_dc_support(enum 
> amd_asic_type asic_type)
> case CHIP_BONAIRE:
> case CHIP_HAWAII:
> case CHIP_KAVERI:
> +   case CHIP_KABINI:
> +   case CHIP_MULLINS:
> case CHIP_CARRIZO:
> case CHIP_STONEY:
> case CHIP_POLARIS11:
> @@ -1714,9 +1716,6 @@ bool amdgpu_device_asic_has_dc_support(enum 
> amd_asic_type asic_type)
>  #if defined(CONFIG_DRM_AMD_DC_PRE_VEGA)
> return amdgpu_dc != 0;
>  #endif
> -   case CHIP_KABINI:
> -   case CHIP_MULLINS:
> -   return amdgpu_dc > 0;
> case CHIP_VEGA10:
>  #if defined(CONFIG_DRM_AMD_DC_DCN1_0)
> case CHIP_RAVEN:
> --
> 2.13.6
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Reviewed-by: Mike Lothian <m...@fireburn.co.uk>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: Initial release of AMD Open Source Driver for Vulkan

[Mike Lothian]

Hi

No I'm not using ICC however that section prevents you using Clang, it
basically says if not GCC then assumes Intel's compiler

Cheers

Mike

On Fri, 22 Dec 2017, 3:04 pm Mao, David, <david@amd.com> wrote:

> Hi Lothian,
> Thanks for testing out out driver!
> Officially we recommend you to stick to GCC5 for now, however, we do have
> a fix for the constexpr issue mentioned below that just didn’t make it to
> this first release.
> According to your diff, are you using ICC?
> Could you let us know the compiler version as well as your distro?
>
> Thanks.
> Best Regards,
> David
>
>
> On Dec 22, 2017, at 9:48 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
>
> Congratulations on getting this out the door
>
> It didn't compile for me without these changes:
>
> In pal:
>
> diff --git a/src/util/math.cpp b/src/util/math.cpp
> index 46e9ede..3af4259 100644
> --- a/src/util/math.cpp
> +++ b/src/util/math.cpp
> @@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
> NBitFloatInfo& info);
>  static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);
>
>  // Initialize the descriptors for various N-bit floating point
> representations:
> -static constexpr NBitFloatInfo Float16Info =
> +static NBitFloatInfo Float16Info =
>  {
>  16,   // numBits
>  10,   //
> numFracBits
> @@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
>  (23 - 10),//
> fracBitsDiff
>  };
>
> -static constexpr NBitFloatInfo Float11Info =
> +static NBitFloatInfo Float11Info =
>  {
>  11,   // numBits
>  6,//
> numFracBits
> @@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
>  23 - 6,   //
> fracBitsDiff
>  };
>
> -static constexpr NBitFloatInfo Float10Info =
> +static NBitFloatInfo Float10Info =
>  {
>  10,   // numBits
>  5,//
> numFracBits
>
> In xgl:
>
> diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
> index 4e4d669..5006184 100644
> --- a/icd/CMakeLists.txt
> +++ b/icd/CMakeLists.txt
> @@ -503,16 +503,16 @@ if (UNIX)
>
>  target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)
>
> -if(NOT ICD_USE_GCC)
> -message(WARNING "Intel ICC untested in CMake.")
> -target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> -endif()
> +#if(NOT ICD_USE_GCC)
> +#message(WARNING "Intel ICC untested in CMake.")
> +#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> +#endif()
>
>  if(CMAKE_BUILD_TYPE_RELEASE)
>  if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
>  execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
>  if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
> VERSION_EQUAL 5.3)
> -target_link_libraries(xgl PRIVATE -flto=4
> -fuse-linker-plugin -Wno-odr)
> +target_link_libraries(xgl PRIVATE -Wno-odr)
>  message(WARNING "LTO enabled for Linking")
>  endif()
>  endif()
> @@ -530,17 +530,17 @@ if (UNIX)
>
>  # CMAKE-TODO: What is whole-archive used for?
>  #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
> -Wl,--no-whole-archive)
> -if(CMAKE_BUILD_TYPE_RELEASE)
> -execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
> -if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
> 5.3)
> -target_link_libraries(xgl PRIVATE -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR

Re: Initial release of AMD Open Source Driver for Vulkan

[Mike Lothian]

Congratulations on getting this out the door

It didn't compile for me without these changes:

In pal:

diff --git a/src/util/math.cpp b/src/util/math.cpp
index 46e9ede..3af4259 100644
--- a/src/util/math.cpp
+++ b/src/util/math.cpp
@@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
NBitFloatInfo& info);
 static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);

 // Initialize the descriptors for various N-bit floating point
representations:
-static constexpr NBitFloatInfo Float16Info =
+static NBitFloatInfo Float16Info =
 {
 16,   // numBits
 10,   //
numFracBits
@@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
 (23 - 10),//
fracBitsDiff
 };

-static constexpr NBitFloatInfo Float11Info =
+static NBitFloatInfo Float11Info =
 {
 11,   // numBits
 6,//
numFracBits
@@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
 23 - 6,   //
fracBitsDiff
 };

-static constexpr NBitFloatInfo Float10Info =
+static NBitFloatInfo Float10Info =
 {
 10,   // numBits
 5,//
numFracBits

In xgl:

diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
index 4e4d669..5006184 100644
--- a/icd/CMakeLists.txt
+++ b/icd/CMakeLists.txt
@@ -503,16 +503,16 @@ if (UNIX)

 target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)

-if(NOT ICD_USE_GCC)
-message(WARNING "Intel ICC untested in CMake.")
-target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
-endif()
+#if(NOT ICD_USE_GCC)
+#message(WARNING "Intel ICC untested in CMake.")
+#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
+#endif()

 if(CMAKE_BUILD_TYPE_RELEASE)
 if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
 execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
 if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
VERSION_EQUAL 5.3)
-target_link_libraries(xgl PRIVATE -flto=4
-fuse-linker-plugin -Wno-odr)
+target_link_libraries(xgl PRIVATE -Wno-odr)
 message(WARNING "LTO enabled for Linking")
 endif()
 endif()
@@ -530,17 +530,17 @@ if (UNIX)

 # CMAKE-TODO: What is whole-archive used for?
 #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
-Wl,--no-whole-archive)
-if(CMAKE_BUILD_TYPE_RELEASE)
-execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
-if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
-target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
-endif()
-endif()
+#if(CMAKE_BUILD_TYPE_RELEASE)
+#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
+#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
+#target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
+#endif()
+#endif()

 #${ICD_TARGET}.so${SO_VERSION_NUMBER} : ${filter-out -Wl%,$(LLLIBS})


diff --git a/icd/api/llpc/util/llpcDebug.cpp

Re: [PATCH] drm/amdgpu: Fix no irq process when evict vram

[Mike Lothian]

I'm hoping this fixes the slow shutdown time of my laptop, which seems to
switch the card back on right before switching off

It's been an issue since the introduction of KIQ (around the same time)

On Wed, 13 Dec 2017 at 12:07 Tao, Yintian <yintian@amd.com> wrote:

> Hi  Lothian
>
>
>
>
>
> First of all, thanks for your review.
>
>
>
> No, it is the patch which achieve the same function for the issue. But it
> is the root cause of fence timeout.
>
> The patch b9141cd3
> <https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.16-wip=b9141cd3930e390f156739829ca9589fda7926e4>
>  is
> the word-around for the issue. And I think the varible “shutdown”
> assignment is better to be located after amdgpu_fini() to ensure no irq
> miss.
>
>
>
> Best Regards
>
> Yintian Tao
>
>
>
>
>
> *From:* Mike Lothian [mailto:m...@fireburn.co.uk]
> *Sent:* Wednesday, December 13, 2017 7:23 PM
> *To:* Tao, Yintian <yintian@amd.com>
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH] drm/amdgpu: Fix no irq process when evict vram
>
>
>
> Is this a follow on to
> https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.16-wip=b9141cd3930e390f156739829ca9589fda7926e4
>
>
>
>
> On Wed, 13 Dec 2017 at 07:11 Yintian Tao <yt...@amd.com> wrote:
>
> When unload amdgpu driver we use sdma to evict vram but there is no
> irq process after sdma completed work which raises that waiting for the
> fence costs 2s which will trigger VFLR under SRIOV and at last make
> unload driver failed.The reason is that the shutdown varible in adev
> is set to true before evict vram, it cause ISR directly return without
> processing.Therefore, we need set the varible after evict vram.
>
> Change-Id: I7bf75481aa0744b99c41672b49670adc70b478bd
> Signed-off-by: Yintian Tao <yt...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a269bbc..80934ee 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2458,7 +2458,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> int r;
>
> DRM_INFO("amdgpu: finishing device.\n");
> -   adev->shutdown = true;
> if (adev->mode_info.mode_config_initialized)
> drm_crtc_force_disable_all(adev->ddev);
>
> @@ -2466,6 +2465,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> amdgpu_fence_driver_fini(adev);
> amdgpu_fbdev_fini(adev);
> r = amdgpu_fini(adev);
> +   adev->shutdown = true;
> if (adev->firmware.gpu_info_fw) {
> release_firmware(adev->firmware.gpu_info_fw);
> adev->firmware.gpu_info_fw = NULL;
> --
> 2.7.4
>
> ___
> 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/amdgpu: Fix no irq process when evict vram

[Mike Lothian]

Is this a follow on to
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.16-wip=b9141cd3930e390f156739829ca9589fda7926e4


On Wed, 13 Dec 2017 at 07:11 Yintian Tao  wrote:

> When unload amdgpu driver we use sdma to evict vram but there is no
> irq process after sdma completed work which raises that waiting for the
> fence costs 2s which will trigger VFLR under SRIOV and at last make
> unload driver failed.The reason is that the shutdown varible in adev
> is set to true before evict vram, it cause ISR directly return without
> processing.Therefore, we need set the varible after evict vram.
>
> Change-Id: I7bf75481aa0744b99c41672b49670adc70b478bd
> Signed-off-by: Yintian Tao 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index a269bbc..80934ee 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2458,7 +2458,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> int r;
>
> DRM_INFO("amdgpu: finishing device.\n");
> -   adev->shutdown = true;
> if (adev->mode_info.mode_config_initialized)
> drm_crtc_force_disable_all(adev->ddev);
>
> @@ -2466,6 +2465,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
> amdgpu_fence_driver_fini(adev);
> amdgpu_fbdev_fini(adev);
> r = amdgpu_fini(adev);
> +   adev->shutdown = true;
> if (adev->firmware.gpu_info_fw) {
> release_firmware(adev->firmware.gpu_info_fw);
> adev->firmware.gpu_info_fw = NULL;
> --
> 2.7.4
>
> ___
> 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

Warnings on amd-staging-drm-next branch

[Mike Lothian]

Hi

I get the following warnings when using GCC 6.3 and the new
amd-staging-drm-next branch

axion agd5f # make -j20
 CHK include/config/kernel.release
 CHK include/generated/uapi/linux/version.h
 CHK include/generated/utsrelease.h
 CHK include/generated/timeconst.h
 CHK include/generated/bounds.h
 CHK include/generated/asm-offsets.h
 CALLscripts/checksyscalls.sh
 CHK include/generated/compile.h
 CHK kernel/config_data.h
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_device.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.o
 CC  drivers/gpu/drm/amd/amdgpu/atombios_crtc.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.o
 CC  drivers/gpu/drm/amd/amdgpu/atom.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_fence.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_object.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_gart.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_display.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_i2c.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_fb.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_gem.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_bios.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_benchmark.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_test.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_pm.o
 CC  drivers/gpu/drm/amd/amdgpu/atombios_dp.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_trace_points.o
 CC  drivers/gpu/drm/amd/amdgpu/atombios_encoders.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_sa.o
 CC  drivers/gpu/drm/amd/amdgpu/atombios_i2c.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_ib.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_pll.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_sync.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.o
 CC  drivers/gpu/drm/amd/amdgpu/vi.o
 CC  drivers/gpu/drm/amd/amdgpu/gmc_v7_0.o
 CC  drivers/gpu/drm/amd/amdgpu/gmc_v8_0.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_irq.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_ih.o
 CC  drivers/gpu/drm/amd/amdgpu/iceland_ih.o
 CC  drivers/gpu/drm/amd/amdgpu/tonga_ih.o
 CC  drivers/gpu/drm/amd/amdgpu/cz_ih.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_dpm.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.o
 CC  drivers/gpu/drm/amd/amdgpu/dce_v10_0.o
 CC  drivers/gpu/drm/amd/amdgpu/dce_v11_0.o
 CC  drivers/gpu/drm/amd/amdgpu/dce_virtual.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.o
 CC  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.o
 CC  drivers/gpu/drm/amd/amdgpu/sdma_v2_4.o
 CC  drivers/gpu/drm/amd/amdgpu/sdma_v3_0.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.o
 CC  drivers/gpu/drm/amd/amdgpu/uvd_v5_0.o
 CC  drivers/gpu/drm/amd/amdgpu/uvd_v6_0.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_vce.o
 CC  drivers/gpu/drm/amd/amdgpu/vce_v3_0.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_job.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_ioc32.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.o
 CC  drivers/gpu/drm/amd/amdgpu/amdgpu_mn.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smumgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/cz_smumgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smumgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smc.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/polaris10_smumgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/iceland_smumgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/polaris10_smc.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/tonga_smc.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/smu7_smumgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/iceland_smc.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/processpptables.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/functiontables.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hardwaremanager.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/pp_acpi.o
 CC  drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.o
 CC
 

Re: [PATCH 02/23] drm/amdgpu: add kiq into compiling

[Mike Lothian]

Ah, I've clicked now - I thought Vega was a star name

AI - Arctic Islands :D

On Tue, 20 Dec 2016 at 04:07 Bridgman, John <john.bridg...@amd.com> wrote:

> An upcoming GPU generation (Vega).
>
>
>
>
>
> *From:* amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] *On Behalf
> Of *Mike Lothian
> *Sent:* Monday, December 19, 2016 10:49 PM
> *To:* Liu, Monk; amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH 02/23] drm/amdgpu: add kiq into compiling
>
>
>
> I'd be curious to know what AI stands for in this context
>
> On Mon, 19 Dec 2016 at 07:28 Liu, Monk <monk@amd.com> wrote:
>
> Sorry, NAK for the KIQ implement patches.
>
> KIQ is just another compute queue, and each  generation of compute queue
> initialization is different, so there is no need of a amdgpu_kiq.c file to
> cover the function of kiq,
>
> Kiq is good enough to be in each gfx_x_x.c file .e.g :
> KIQ  for VI is in gfx_v8_0.c
> And KIQ for AI is in gfx_v9_0.c
>
> Most important is that the "queue_init" routine of above two chips on KIQ
> is different (MQD descriptor as well as registers need programing ... ),
> please just align with the previous patch style in amd-sriov-4.6 for KIQ
> part
>
> BR Monk
>
> -邮件原件-
> 发件人: Yu, Xiangliang
> 发送时间: Sunday, December 18, 2016 9:47 AM
> 收件人: dl.SRDC_SW_GPUVirtualization
> 主题: FW: [PATCH 02/23] drm/amdgpu: add kiq into compiling
>
>
>
> -Original Message-
> From: Xiangliang Yu [mailto:xiangliang...@amd.com]
> Sent: Sunday, December 18, 2016 12:16 AM
> To: amd-gfx@lists.freedesktop.org; dl.SRDC_SW_GPUVirtualization <
> dl.srdc_sw_gpuvirtualizat...@amd.com>
> Cc: Yu, Xiangliang <xiangliang...@amd.com>
> Subject: [PATCH 02/23] drm/amdgpu: add kiq into compiling
>
> Add support KIQ in Makefile to make it into module.
>
> Signed-off-by: Xiangliang Yu <xiangliang...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index dd0b6db..635ff94 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -30,7 +30,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
> amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> -   amdgpu_gtt_mgr.o amdgpu_vram_mgr.o
> +   amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_kiq.o
>
>  # add asic specific block
>  amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
> --
> 2.7.4
>
> ___
> 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/amdgpu: just suspend the hw on pci shutdown

[Mike Lothian]

Feel free to add a reported and tested by flag

Thanks for sorting this

On Tue, 6 Dec 2016 at 22:55 Alex Deucher  wrote:

> We can't just reuse pci_remove as there may be userspace still
> doing things.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98638
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97980
> Signed-off-by: Alex Deucher 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 5 -
>  3 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 946dfcc..123f8152 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1714,6 +1714,7 @@ void amdgpu_driver_postclose_kms(struct drm_device
> *dev,
>  struct drm_file *file_priv);
>  void amdgpu_driver_preclose_kms(struct drm_device *dev,
> struct drm_file *file_priv);
> +int amdgpu_suspend(struct amdgpu_device *adev);
>  int amdgpu_device_suspend(struct drm_device *dev, bool suspend, bool
> fbcon);
>  int amdgpu_device_resume(struct drm_device *dev, bool resume, bool fbcon);
>  u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int
> pipe);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 4701d94..8b39fd3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1530,7 +1530,7 @@ static int amdgpu_fini(struct amdgpu_device *adev)
> return 0;
>  }
>
> -static int amdgpu_suspend(struct amdgpu_device *adev)
> +int amdgpu_suspend(struct amdgpu_device *adev)
>  {
> int i, r;
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 3210081..6e4e3a1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -486,12 +486,15 @@ amdgpu_pci_remove(struct pci_dev *pdev)
>  static void
>  amdgpu_pci_shutdown(struct pci_dev *pdev)
>  {
> +   struct drm_device *dev = pci_get_drvdata(pdev);
> +   struct amdgpu_device *adev = dev->dev_private;
> +
> /* if we are running in a VM, make sure the device
>  * torn down properly on reboot/shutdown.
>  * unfortunately we can't detect certain
>  * hypervisors so just do this all the time.
>  */
> -   amdgpu_pci_remove(pdev);
> +   amdgpu_suspend(adev);
>  }
>
>  static int amdgpu_pmops_suspend(struct device *dev)
> --
> 2.5.5
>
> ___
> 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/2] drm/amdgpu: fix power state when port pm is unavailable

[Mike Lothian]

The attached patch allows my machine to boot also

Thanks

Mike

On Sat, 26 Nov 2016 at 14:14 Peter Wu <pe...@lekensteyn.nl> wrote:

> Found the problem.
>
> amdgpu_atpx_pci_probe_handle is used to detect the ATPX handle, but this
> does not necessarily have to be on the dGPU. In fact, on your machine it
> is located on the Intel iGPU (00:02.0):
>
> [  134.760509] vga_switcheroo: detected switching method
> \_SB_.PCI0.GFX0.ATPX handle
>
> The parent device of the iGPU (00:00.0) is the root port which has no
> PCIe capability, hence bridge_d3 evaluated to false.
>
> Can you try the attached patch?
>
> Kind regards,
> Peter
>
> On Sat, Nov 26, 2016 at 01:49:08PM +, Mike Lothian wrote:
> > I can confirm the patch allows my machine to boot again
> >
> > On Sat, 26 Nov 2016 at 11:39 Peter Wu <pe...@lekensteyn.nl> wrote:
> >
> > > Hi Mike,
> > >
> > > To grab console output, you could also try to blacklist amdgpu at
> > > startup and load it later.
> > >
> > > Can you provide your acpidump (and lspci -nn, especially if you do not
> > > have a dmesg).
> > >
> > > This is the call chain:
> > >
> > > + amdgpu_atpx_detect
> > >   + amdgpu_atpx_pci_probe_handle
> > > + return if ATPX ACPI handle cannot be found
> > > + set amdgpu_atpx_priv.bridge_pm_usable
> > >   + amdgpu_atpx_init
> > > + amdgpu_atpx_validate
> > >   + use amdgpu_atpx_priv.bridge_pm_usable
> > >
> > > I wonder whether newer devices remove ATPX completely. If that is the
> > > case (please provide acpidump!), can you try this hack:
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > > index 951addf..5c23382 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > > @@ -487,6 +487,7 @@ static bool amdgpu_atpx_pci_probe_handle(struct
> > > pci_dev *pdev)
> > > status = acpi_get_handle(dhandle, "ATPX", _handle);
> > > if (ACPI_FAILURE(status)) {
> > >     amdgpu_atpx_priv.other_handle = dhandle;
> > > +   amdgpu_atpx_priv.bridge_pm_usable = true;
> > > return false;
> > > }
> > > amdgpu_atpx_priv.dhandle = dhandle;
> > >
> > > This is not intended for merging, but just testing a hypothesis.
> > >
> > > Kind regards,
> > > Peter
> > >
> > > On Sat, Nov 26, 2016 at 11:20:28AM +, Mike Lothian wrote:
> > > > He's some screen shots of the booting screens, apologies they're not
> that
> > > > clear
> > > >
> > > > https://imgur.com/a/V7mRA
> > > >
> > > > On Sat, 26 Nov 2016 at 11:00 Mike Lothian <m...@fireburn.co.uk>
> wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > The previous working kernel, was the patch before this - reverting
> > > fixes it
> > > > >
> > > > > My bios date is quite new 08/05/2016
> > > > >
> > > > > Most of the messages fly straight off the screen, the journal isn't
> > > kept
> > > > > and the wifi driver also complains, will see if I can get a slow
> motion
> > > > > capture of the errors and screen shot them
> > > > >
> > > > > Regards
> > > > >
> > > > > Mike
> > > > >
> > > > > On Sat, 26 Nov 2016 at 10:20 Peter Wu <pe...@lekensteyn.nl> wrote:
> > > > >
> > > > > Hi Mike,
> > > > >
> > > > > On Sat, Nov 26, 2016 at 12:36:27AM +, Mike Lothian wrote:
> > > > > > This patch is preventing my laptop from booting, I'm getting D3
> error
> > > > > > messages and atom bios stuck messages
> > > > >
> > > > > Can you post a dmesg and acpidump? What was the previous working
> > > kernel?
> > > > > I suppose your BIOS date (/sys/class/dmi/id/bios_date) is pre-2015?
> > > > > Does booting with runpm=0 work?
> > > > >
> > > > > > I mistakenly saw the v2 patch and didn't realise it was for
> radeon
> > > not
> > > > > > amdgpu - this branch and Linus's tree are currently not booting
> for
> > > me
> > > > >
> 

Re: [PATCH 1/2] drm/amdgpu: fix power state when port pm is unavailable

[Mike Lothian]

I can confirm the patch allows my machine to boot again

On Sat, 26 Nov 2016 at 11:39 Peter Wu <pe...@lekensteyn.nl> wrote:

> Hi Mike,
>
> To grab console output, you could also try to blacklist amdgpu at
> startup and load it later.
>
> Can you provide your acpidump (and lspci -nn, especially if you do not
> have a dmesg).
>
> This is the call chain:
>
> + amdgpu_atpx_detect
>   + amdgpu_atpx_pci_probe_handle
> + return if ATPX ACPI handle cannot be found
> + set amdgpu_atpx_priv.bridge_pm_usable
>   + amdgpu_atpx_init
> + amdgpu_atpx_validate
>   + use amdgpu_atpx_priv.bridge_pm_usable
>
> I wonder whether newer devices remove ATPX completely. If that is the
> case (please provide acpidump!), can you try this hack:
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> index 951addf..5c23382 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> @@ -487,6 +487,7 @@ static bool amdgpu_atpx_pci_probe_handle(struct
> pci_dev *pdev)
> status = acpi_get_handle(dhandle, "ATPX", _handle);
> if (ACPI_FAILURE(status)) {
> amdgpu_atpx_priv.other_handle = dhandle;
> +   amdgpu_atpx_priv.bridge_pm_usable = true;
> return false;
> }
> amdgpu_atpx_priv.dhandle = dhandle;
>
> This is not intended for merging, but just testing a hypothesis.
>
> Kind regards,
> Peter
>
> On Sat, Nov 26, 2016 at 11:20:28AM +, Mike Lothian wrote:
> > He's some screen shots of the booting screens, apologies they're not that
> > clear
> >
> > https://imgur.com/a/V7mRA
> >
> > On Sat, 26 Nov 2016 at 11:00 Mike Lothian <m...@fireburn.co.uk> wrote:
> >
> > > Hi
> > >
> > > The previous working kernel, was the patch before this - reverting
> fixes it
> > >
> > > My bios date is quite new 08/05/2016
> > >
> > > Most of the messages fly straight off the screen, the journal isn't
> kept
> > > and the wifi driver also complains, will see if I can get a slow motion
> > > capture of the errors and screen shot them
> > >
> > > Regards
> > >
> > > Mike
> > >
> > > On Sat, 26 Nov 2016 at 10:20 Peter Wu <pe...@lekensteyn.nl> wrote:
> > >
> > > Hi Mike,
> > >
> > > On Sat, Nov 26, 2016 at 12:36:27AM +, Mike Lothian wrote:
> > > > This patch is preventing my laptop from booting, I'm getting D3 error
> > > > messages and atom bios stuck messages
> > >
> > > Can you post a dmesg and acpidump? What was the previous working
> kernel?
> > > I suppose your BIOS date (/sys/class/dmi/id/bios_date) is pre-2015?
> > > Does booting with runpm=0 work?
> > >
> > > > I mistakenly saw the v2 patch and didn't realise it was for radeon
> not
> > > > amdgpu - this branch and Linus's tree are currently not booting for
> me
> > >
> > > What do you mean by this?
> > >
> > > Kind regards,
> > > Peter
> > >
> > > > On Wed, 23 Nov 2016 at 17:16 Deucher, Alexander <
> > > alexander.deuc...@amd.com>
> > > > wrote:
> > > >
> > > > > > -Original Message-
> > > > > > From: Peter Wu [mailto:pe...@lekensteyn.nl]
> > > > > > Sent: Wednesday, November 23, 2016 12:13 PM
> > > > > > To: Alex Deucher
> > > > > > Cc: amd-gfx list; Deucher, Alexander; Nayan Deshmukh
> > > > > > Subject: Re: [PATCH 1/2] drm/amdgpu: fix power state when port
> pm is
> > > > > > unavailable
> > > > > >
> > > > > > On Wed, Nov 23, 2016 at 12:01:55PM -0500, Alex Deucher wrote:
> > > > > > >  On Tue, Nov 22, 2016 at 8:22 PM, Peter Wu <
> pe...@lekensteyn.nl>
> > > > > wrote:
> > > > > > > > When PCIe port PM is not enabled (system BIOS is pre-2015 or
> the
> > > > > > > > pcie_port_pm=off parameter is set), legacy ATPX PM should
> still
> > > be
> > > > > > > > marked as supported. Otherwise the GPU can fail to power on
> after
> > > > > > > > runtime suspend. This affected a Dell Inspiron 5548.
> > > > > > > >
> > > > > > > > Ideally the BIOS date in the PCI core is lowered to 2013 (the
> > > first
> > > > >

Re: [PATCH 1/2] drm/amdgpu: fix power state when port pm is unavailable

[Mike Lothian]

He's some screen shots of the booting screens, apologies they're not that
clear

https://imgur.com/a/V7mRA

On Sat, 26 Nov 2016 at 11:00 Mike Lothian <m...@fireburn.co.uk> wrote:

> Hi
>
> The previous working kernel, was the patch before this - reverting fixes it
>
> My bios date is quite new 08/05/2016
>
> Most of the messages fly straight off the screen, the journal isn't kept
> and the wifi driver also complains, will see if I can get a slow motion
> capture of the errors and screen shot them
>
> Regards
>
> Mike
>
> On Sat, 26 Nov 2016 at 10:20 Peter Wu <pe...@lekensteyn.nl> wrote:
>
> Hi Mike,
>
> On Sat, Nov 26, 2016 at 12:36:27AM +, Mike Lothian wrote:
> > This patch is preventing my laptop from booting, I'm getting D3 error
> > messages and atom bios stuck messages
>
> Can you post a dmesg and acpidump? What was the previous working kernel?
> I suppose your BIOS date (/sys/class/dmi/id/bios_date) is pre-2015?
> Does booting with runpm=0 work?
>
> > I mistakenly saw the v2 patch and didn't realise it was for radeon not
> > amdgpu - this branch and Linus's tree are currently not booting for me
>
> What do you mean by this?
>
> Kind regards,
> Peter
>
> > On Wed, 23 Nov 2016 at 17:16 Deucher, Alexander <
> alexander.deuc...@amd.com>
> > wrote:
> >
> > > > -Original Message-
> > > > From: Peter Wu [mailto:pe...@lekensteyn.nl]
> > > > Sent: Wednesday, November 23, 2016 12:13 PM
> > > > To: Alex Deucher
> > > > Cc: amd-gfx list; Deucher, Alexander; Nayan Deshmukh
> > > > Subject: Re: [PATCH 1/2] drm/amdgpu: fix power state when port pm is
> > > > unavailable
> > > >
> > > > On Wed, Nov 23, 2016 at 12:01:55PM -0500, Alex Deucher wrote:
> > > > >  On Tue, Nov 22, 2016 at 8:22 PM, Peter Wu <pe...@lekensteyn.nl>
> > > wrote:
> > > > > > When PCIe port PM is not enabled (system BIOS is pre-2015 or the
> > > > > > pcie_port_pm=off parameter is set), legacy ATPX PM should still
> be
> > > > > > marked as supported. Otherwise the GPU can fail to power on after
> > > > > > runtime suspend. This affected a Dell Inspiron 5548.
> > > > > >
> > > > > > Ideally the BIOS date in the PCI core is lowered to 2013 (the
> first
> > > year
> > > > > > where hybrid graphics platforms using power resources was
> > > introduced),
> > > > > > but that seems more risky at this point and would not solve the
> > > > > > pcie_port_pm=off issue.
> > > > > >
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505
> > > > > > Reported-and-tested-by: Nayan Deshmukh
> > > > <nayan26deshm...@gmail.com>
> > > > > > Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
> > > > > > ---
> > > > > > Hi,
> > > > > >
> > > > > > This patch is already three weeks old. One alternative idea was
> > > lowering
> > > > BIOS
> > > > > > date in PCI core, but as pcie_port_pm=force did not have the
> desired
> > > > effect, I
> > > > > > do not think that this would help though.
> > > > >
> > > > > Thanks for doing this.
> > > > >
> > > > > >
> > > > > > I have also not contacted linux-pci or Mika about lowering the
> year
> > > due to
> > > > the
> > > > > > lack of a good reason.  Might do it later though once ACPICA bug
> > > 1333 is
> > > > sorted
> > > > > > out such that lowering the year actually has benefits for a
> Nvidia
> > > laptop
> > > > (or if
> > > > > > some amdgpu problem can be solved by this).
> > > > > >
> > > > > > Both patches should probably be Cc stable (4.8+), fixing
> > > 2f5af82eeab2 and
> > > > > > b8c9fd5ad4b4 ("track whether if this is a hybrid graphics
> > > platform"). There
> > > > have
> > > > > > been some ifdef 0's and reverts in between, so I was not sure if
> > > adding
> > > > the
> > > > > > Fixes tag is appropriate.
> > > > >
> > > > > I don't think we need to cc stable.  In kernel 4.8 we don't
> attempt to
> > > > > do d3cold at all.  4.8 and older kernels have:
> > &

Re: [PATCH 1/2] drm/amdgpu: fix power state when port pm is unavailable

[Mike Lothian]

Hi

The previous working kernel, was the patch before this - reverting fixes it

My bios date is quite new 08/05/2016

Most of the messages fly straight off the screen, the journal isn't kept
and the wifi driver also complains, will see if I can get a slow motion
capture of the errors and screen shot them

Regards

Mike

On Sat, 26 Nov 2016 at 10:20 Peter Wu <pe...@lekensteyn.nl> wrote:

> Hi Mike,
>
> On Sat, Nov 26, 2016 at 12:36:27AM +0000, Mike Lothian wrote:
> > This patch is preventing my laptop from booting, I'm getting D3 error
> > messages and atom bios stuck messages
>
> Can you post a dmesg and acpidump? What was the previous working kernel?
> I suppose your BIOS date (/sys/class/dmi/id/bios_date) is pre-2015?
> Does booting with runpm=0 work?
>
> > I mistakenly saw the v2 patch and didn't realise it was for radeon not
> > amdgpu - this branch and Linus's tree are currently not booting for me
>
> What do you mean by this?
>
> Kind regards,
> Peter
>
> > On Wed, 23 Nov 2016 at 17:16 Deucher, Alexander <
> alexander.deuc...@amd.com>
> > wrote:
> >
> > > > -Original Message-
> > > > From: Peter Wu [mailto:pe...@lekensteyn.nl]
> > > > Sent: Wednesday, November 23, 2016 12:13 PM
> > > > To: Alex Deucher
> > > > Cc: amd-gfx list; Deucher, Alexander; Nayan Deshmukh
> > > > Subject: Re: [PATCH 1/2] drm/amdgpu: fix power state when port pm is
> > > > unavailable
> > > >
> > > > On Wed, Nov 23, 2016 at 12:01:55PM -0500, Alex Deucher wrote:
> > > > >  On Tue, Nov 22, 2016 at 8:22 PM, Peter Wu <pe...@lekensteyn.nl>
> > > wrote:
> > > > > > When PCIe port PM is not enabled (system BIOS is pre-2015 or the
> > > > > > pcie_port_pm=off parameter is set), legacy ATPX PM should still
> be
> > > > > > marked as supported. Otherwise the GPU can fail to power on after
> > > > > > runtime suspend. This affected a Dell Inspiron 5548.
> > > > > >
> > > > > > Ideally the BIOS date in the PCI core is lowered to 2013 (the
> first
> > > year
> > > > > > where hybrid graphics platforms using power resources was
> > > introduced),
> > > > > > but that seems more risky at this point and would not solve the
> > > > > > pcie_port_pm=off issue.
> > > > > >
> > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505
> > > > > > Reported-and-tested-by: Nayan Deshmukh
> > > > <nayan26deshm...@gmail.com>
> > > > > > Signed-off-by: Peter Wu <pe...@lekensteyn.nl>
> > > > > > ---
> > > > > > Hi,
> > > > > >
> > > > > > This patch is already three weeks old. One alternative idea was
> > > lowering
> > > > BIOS
> > > > > > date in PCI core, but as pcie_port_pm=force did not have the
> desired
> > > > effect, I
> > > > > > do not think that this would help though.
> > > > >
> > > > > Thanks for doing this.
> > > > >
> > > > > >
> > > > > > I have also not contacted linux-pci or Mika about lowering the
> year
> > > due to
> > > > the
> > > > > > lack of a good reason.  Might do it later though once ACPICA bug
> > > 1333 is
> > > > sorted
> > > > > > out such that lowering the year actually has benefits for a
> Nvidia
> > > laptop
> > > > (or if
> > > > > > some amdgpu problem can be solved by this).
> > > > > >
> > > > > > Both patches should probably be Cc stable (4.8+), fixing
> > > 2f5af82eeab2 and
> > > > > > b8c9fd5ad4b4 ("track whether if this is a hybrid graphics
> > > platform"). There
> > > > have
> > > > > > been some ifdef 0's and reverts in between, so I was not sure if
> > > adding
> > > > the
> > > > > > Fixes tag is appropriate.
> > > > >
> > > > > I don't think we need to cc stable.  In kernel 4.8 we don't
> attempt to
> > > > > do d3cold at all.  4.8 and older kernels have:
> > > > > c63695cc5e5f685e924e25a8f9555f6e846f1fc6 (drm/amdgpu: work around
> > > > lack
> > > > > of upstream ACPI support for D3cold)
> > > > > which was reverted for 4.9.
> > > >
> > > > That pa

Re: [PATCH 1/2] drm/amdgpu: fix power state when port pm is unavailable

[Mike Lothian]

This patch is preventing my laptop from booting, I'm getting D3 error
messages and atom bios stuck messages

I mistakenly saw the v2 patch and didn't realise it was for radeon not
amdgpu - this branch and Linus's tree are currently not booting for me

On Wed, 23 Nov 2016 at 17:16 Deucher, Alexander 
wrote:

> > -Original Message-
> > From: Peter Wu [mailto:pe...@lekensteyn.nl]
> > Sent: Wednesday, November 23, 2016 12:13 PM
> > To: Alex Deucher
> > Cc: amd-gfx list; Deucher, Alexander; Nayan Deshmukh
> > Subject: Re: [PATCH 1/2] drm/amdgpu: fix power state when port pm is
> > unavailable
> >
> > On Wed, Nov 23, 2016 at 12:01:55PM -0500, Alex Deucher wrote:
> > >  On Tue, Nov 22, 2016 at 8:22 PM, Peter Wu 
> wrote:
> > > > When PCIe port PM is not enabled (system BIOS is pre-2015 or the
> > > > pcie_port_pm=off parameter is set), legacy ATPX PM should still be
> > > > marked as supported. Otherwise the GPU can fail to power on after
> > > > runtime suspend. This affected a Dell Inspiron 5548.
> > > >
> > > > Ideally the BIOS date in the PCI core is lowered to 2013 (the first
> year
> > > > where hybrid graphics platforms using power resources was
> introduced),
> > > > but that seems more risky at this point and would not solve the
> > > > pcie_port_pm=off issue.
> > > >
> > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98505
> > > > Reported-and-tested-by: Nayan Deshmukh
> > 
> > > > Signed-off-by: Peter Wu 
> > > > ---
> > > > Hi,
> > > >
> > > > This patch is already three weeks old. One alternative idea was
> lowering
> > BIOS
> > > > date in PCI core, but as pcie_port_pm=force did not have the desired
> > effect, I
> > > > do not think that this would help though.
> > >
> > > Thanks for doing this.
> > >
> > > >
> > > > I have also not contacted linux-pci or Mika about lowering the year
> due to
> > the
> > > > lack of a good reason.  Might do it later though once ACPICA bug
> 1333 is
> > sorted
> > > > out such that lowering the year actually has benefits for a Nvidia
> laptop
> > (or if
> > > > some amdgpu problem can be solved by this).
> > > >
> > > > Both patches should probably be Cc stable (4.8+), fixing
> 2f5af82eeab2 and
> > > > b8c9fd5ad4b4 ("track whether if this is a hybrid graphics
> platform"). There
> > have
> > > > been some ifdef 0's and reverts in between, so I was not sure if
> adding
> > the
> > > > Fixes tag is appropriate.
> > >
> > > I don't think we need to cc stable.  In kernel 4.8 we don't attempt to
> > > do d3cold at all.  4.8 and older kernels have:
> > > c63695cc5e5f685e924e25a8f9555f6e846f1fc6 (drm/amdgpu: work around
> > lack
> > > of upstream ACPI support for D3cold)
> > > which was reverted for 4.9.
> >
> > That patch was already reverted in 4.8 as far as I can see:
> >
> > $ git tag --contains c39b487f195b93235ee76384427467786f7bf29f | grep v4.8
> > v4.8
> >
> > Can you double-check? v4.8 was the first kernel with D3cold support in
> > PCI core.
>
> You are right.  I was thinking d3cold went upstream in 4.9, so yes, we
> should apply this to 4.8.
>
> Alex
>
> >
> > > Series is:
> > > Reviewed-by: Alex Deucher 
> >
> > Thanks!
> >
> > Kind regards,
> > Peter
> >
> > >
> > > >
> > > > Kind regards,
> > > > Peter
> > > > ---
> > > >  drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 9 -
> > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > > > index 10b5ddf..951addf 100644
> > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
> > > > @@ -33,6 +33,7 @@ struct amdgpu_atpx {
> > > >
> > > >  static struct amdgpu_atpx_priv {
> > > > bool atpx_detected;
> > > > +   bool bridge_pm_usable;
> > > > /* handle for device - and atpx */
> > > > acpi_handle dhandle;
> > > > acpi_handle other_handle;
> > > > @@ -200,7 +201,11 @@ static int amdgpu_atpx_validate(struct
> > amdgpu_atpx *atpx)
> > > > atpx->is_hybrid = false;
> > > > if (valid_bits & ATPX_MS_HYBRID_GFX_SUPPORTED) {
> > > > printk("ATPX Hybrid Graphics\n");
> > > > -   atpx->functions.power_cntl = false;
> > > > +   /*
> > > > +* Disable legacy PM methods only when pcie port PM
> is usable,
> > > > +* otherwise the device might fail to power off or
> power on.
> > > > +*/
> > > > +   atpx->functions.power_cntl =
> > !amdgpu_atpx_priv.bridge_pm_usable;
> > > > atpx->is_hybrid = true;
> > > > }
> > > >
> > > > @@ -471,6 +476,7 @@ static int amdgpu_atpx_power_state(enum
> > vga_switcheroo_client_id id,
> > > >   */
> > > >  static bool amdgpu_atpx_pci_probe_handle(struct pci_dev *pdev)
> > > >  

Re: [AMDGPU][CIK] PRIME with DRI3 + stalls rendering

[Mike Lothian]

Alternatively you can switch to the modesetting driver - it works well here

On Wed, 16 Nov 2016 at 01:33 Mario Kleiner 
wrote:

> On 11/15/2016 09:25 AM, Shawn Starr wrote:
> > On Monday, November 14, 2016 3:40:17 PM EST Shawn Starr wrote:
> >> On Monday, November 14, 2016 10:40:17 AM EST Michel Dänzer wrote:
> >>> On 13/11/16 06:59 AM, Shawn Starr wrote:
>  I'm currently trying the new fence patches that prevent tearing in
> PRIME
>  on
>  Bonaire CIK, it works with no tearing with latest patches from Mario,
>  but
>  there is significant frame stalls, even though the performance is
> higher
>  than running the AMDGPU as dedicated.
> >>>
> >>> Please elaborate on what "frame stalls" means exactly.
> >>
> >> It looks like vsync issues, even though if I try vblank_mode=# it still
> >> shows stalling.
> >>
> >> I'll have to make a video to show the results and post link here.
> >>
> >> Thanks,
> >> Shawn
> >
> > So, It turns out to be KDE (Kwin) fault, if I start a GNOME session, and
> run
> > Valley, no such stalls. Even though I told KWIN to disable Vsync
> completely
> > and disable composite on full screen windows. Seems it doesn't work
> right.
> >
> > Consider the PRIME patches working for me.
> >
> > Thanks,
> > Shawn
> >
> >
>
> Glad it works for you with GNOME.
>
> Wrt. Kwin, KWin doesn't unredirect fullscreen windows if the display
> iGPU is Intel, apparently because sometime in the past there were bugs
> in the intel ddx related to switching between redirected and
> unredirected mode. That might explain the problem under KDE.
>
> You'd need to disable the compositor manually (SHIFT + ALT + F12 to
> toggle at runtime) while running a fullscreen app/game that way, or the
> application needs to set some NetWM hints on its window to ask for no
> composition, or some KWin rule needs to be set for the app. I tested the
> patches under KDE Plasma 5 (KUbuntu 16.04 LTS) with composition disabled
> this way and at least my tests worked fine then.
>
> -mario
> ___
> 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/amdgpu: Attach exclusive fence to prime exported bo's. (v5)

[Mike Lothian]

Hi

I've tested this version now - works great

Thanks

Mike

On Wed, 9 Nov 2016 at 01:26 Mario Kleiner <mario.kleiner...@gmail.com>
wrote:

> External clients which import our bo's wait only
> for exclusive dmabuf-fences, not on shared ones,
> ditto for bo's which we import from external
> providers and write to.
>
> Therefore attach exclusive fences on prime shared buffers
> if our exported buffer gets imported by an external
> client, or if we import a buffer from an external
> exporter.
>
> See discussion in thread:
> https://lists.freedesktop.org/archives/dri-devel/2016-October/122370.html
>
> Prime export tested on Intel iGPU + AMD Tonga dGPU as
> DRI3/Present Prime render offload, and with the Tonga
> standalone as primary gpu.
>
> v2: Add a wait for all shared fences before prime export,
> as suggested by Christian Koenig.
>
> v3: - Mark buffer prime_exported in amdgpu_gem_prime_pin,
> so we only use the exclusive fence when exporting a
> bo to external clients like a separate iGPU, but not
> when exporting/importing from/to ourselves as part of
> regular DRI3 fd passing.
>
> - Propagate failure of reservation_object_wait_rcu back
> to caller.
>
> v4: - Switch to a prime_shared_count counter instead of a
>   flag, which gets in/decremented on prime_pin/unpin, so
>   we can switch back to shared fences if all clients
>   detach from our exported bo.
>
> - Also switch to exclusive fence for prime imported bo's.
>
> v5: - Drop lret, instead use int ret -> long ret, as proposed
>   by Christian.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95472
> Tested-by: Mike Lothian <m...@fireburn.co.uk> (v1)
> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
> Reviewed-by: Christian König <christian.koe...@amd.com>.
> Cc: Christian König <christian.koe...@amd.com>
> Cc: Michel Dänzer <michel.daen...@amd.com>
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h |  1 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c   | 20 +++-
>  3 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 039b57e..496f72b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -459,6 +459,7 @@ struct amdgpu_bo {
> u64 metadata_flags;
> void*metadata;
> u32 metadata_size;
> +   unsignedprime_shared_count;
> /* list of all virtual address to which this bo
>  * is associated to
>  */
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> index 651115d..c02db01f6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
> @@ -132,7 +132,7 @@ static int amdgpu_bo_list_set(struct amdgpu_device
> *adev,
> entry->priority = min(info[i].bo_priority,
>   AMDGPU_BO_LIST_MAX_PRIORITY);
> entry->tv.bo = >robj->tbo;
> -   entry->tv.shared = true;
> +   entry->tv.shared = !entry->robj->prime_shared_count;
>
> if (entry->robj->prefered_domains == AMDGPU_GEM_DOMAIN_GDS)
> gds_obj = entry->robj;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index 7700dc2..3826d5a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -74,20 +74,36 @@ amdgpu_gem_prime_import_sg_table(struct drm_device
> *dev,
> if (ret)
> return ERR_PTR(ret);
>
> +   bo->prime_shared_count = 1;
> return >gem_base;
>  }
>
>  int amdgpu_gem_prime_pin(struct drm_gem_object *obj)
>  {
> struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> -   int ret = 0;
> +   long ret = 0;
>
> ret = amdgpu_bo_reserve(bo, false);
> if (unlikely(ret != 0))
> return ret;
>
> +   /*
> +* Wait for all shared fences to complete before we switch to
> future
> +* use of exclusive fence on this prime shared bo.
> +*/
> +   ret = reservation_object_wait_timeout_rcu(bo->tbo.resv, true,
> false,
> + MAX_SCHEDULE_TIMEOUT);
> +   if (unlikely(ret < 0)) {
> 

Re: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Mike Lothian]

Hi Mario

That fixes the tearing, it's been replaced with a strange stutter, like
it's only showing half the number of frames being reported - it's really
noticeable in tomb raider

Thanks for your work on this, the stutter is much more manageable than the
tearing was

I've attached the patch that applies cleanly to 4.10-wip



On Fri, 28 Oct 2016 at 18:37 Mario Kleiner <mario.kleiner...@gmail.com>
wrote:

>
>
> On 10/28/2016 03:34 AM, Michel Dänzer wrote:
> > On 27/10/16 10:33 PM, Mike Lothian wrote:
> >>
> >> Just another gentle ping to see where you are with this?
> >
> > I haven't got a chance to look into this any further.
> >
> >
>
> Fwiw., as a proof of concept, the attached experimental patch does work
> as tested on Intel HD Haswell + AMD R9 380 Tonga under amdgpu and
> DRI3/Present when applied to drm-next (updated from a few days ago).
> With DRI_PRIME=1 tearing for page-flipped fullscreen windows is gone
> under all loads. The tearing with "windowed" windows now looks as
> expected for regular tearing not related to Prime.
>
> ftrace confirms the i915 driver's pageflip function is waiting on the
> fence in reservation_object_wait_timeout_rcu() as it should.
>
> That entry->tv.shared needs to be set false for such buffers in
> amdgpu_bo_list_set() makes sense to me, as that is part of the buffer
> validation for command stream submission. There are other places in the
> driver where tv.shared is set, which i didn't check so far.
>
> I don't know which of these would need to be updated with a "exported
> bo" check as well, e.g., for video decoding or maybe gpu compute? Adding
> or removing the check to amdgpu_gem_va_update_vm(), e.g., made no
> difference. I assume that makes sense because that functions seems to
> deal with amdgpu internal vm page tables or page table entries for such
> a bo, not with something visible to external clients?
>
> All i can say is it fixes 3D rendering under DRI3 + Prime + pageflipping
> without causing any obvious new problems.
>
> -mario
>
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 217df24..6757b99 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -391,6 +391,7 @@ struct amdgpu_bo {
 	u64metadata_flags;
 	void*metadata;
 	u32metadata_size;
+	boolprime_exported;
 	/* list of all virtual address to which this bo
 	 * is associated to
 	 */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index 651115d..6e1d7b3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -132,7 +132,10 @@ static int amdgpu_bo_list_set(struct amdgpu_device *adev,
 		entry->priority = min(info[i].bo_priority,
   AMDGPU_BO_LIST_MAX_PRIORITY);
 		entry->tv.bo = >robj->tbo;
-		entry->tv.shared = true;
+		entry->tv.shared = !entry->robj->prime_exported;
+
+		if (entry->robj->prime_exported)
+		DRM_DEBUG_PRIME("Exclusive fence for exported prime bo %p\n", entry->robj);
 
 		if (entry->robj->prefered_domains == AMDGPU_GEM_DOMAIN_GDS)
 			gds_obj = entry->robj;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index cd62f6f..54099a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -504,6 +504,12 @@ static void amdgpu_gem_va_update_vm(struct amdgpu_device *adev,
 
 	tv.bo = _va->bo->tbo;
 	tv.shared = true;
+
+	if (bo_va->bo->prime_exported) {
+	DRM_DEBUG_PRIME("Update for exported prime bo %p\n", bo_va->bo);
+	/* tv.shared = false; */
+	}
+
 	list_add(, );
 
 	amdgpu_vm_get_pd_bo(bo_va->vm, , _pd);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 7700dc2..bfbfeb9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -121,5 +121,8 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
 	if (amdgpu_ttm_tt_get_usermm(bo->tbo.ttm))
 		return ERR_PTR(-EPERM);
 
+	bo->prime_exported = true;
+	DRM_DEBUG_PRIME("Exporting prime bo %p\n", bo);
+
 	return drm_gem_prime_export(dev, gobj, flags);
 }
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Mike Lothian]

Hi

Just another gentle ping to see where you are with this?

Cheers

Mike

On Wed, 12 Oct 2016 at 01:40 Michel Dänzer <mic...@daenzer.net> wrote:

> On 11/10/16 09:04 PM, Christian König wrote:
> > Am 11.10.2016 um 05:58 schrieb Michel Dänzer:
> >> On 07/10/16 09:34 PM, Mike Lothian wrote:
> >>> This has discussion has gone a little quiet
> >>>
> >>> Was there any agreement about what needed doing to get this working
> >>> for i965/amdgpu?
> >> Christian, do you see anything which could prevent the solution I
> >> outlined from working?
> >
> > I thought about that approach as well, but unfortunately it also has a
> > couple of downsides. Especially keeping the exclusive fence set while we
> > actually don't need it isn't really clean either.
>
> I was wondering if it's possible to have a singleton pseudo exclusive
> fence which is used for all BOs. That might keep the overhead acceptably
> low.
>
>
> > I'm currently a bit busy with other tasks and so put Nayan on a road to
> > get a bit into the kernel driver (he asked for that anyway).
> >
> > Implementing the simple workaround to sync when we export the DMA-buf
> > should be something like 20 lines of code and fortunately Nayan has an
> > I+A system and so can actually test it.
> >
> > If it turns out to be more problematic or somebody really starts to need
> > it I'm going to hack on that myself a bit more.
>
> If you mean only syncing when a DMA-buf is exported, that's not enough,
> as I explained before. The BOs being shared are long-lived, and
> synchronization between GPUs is required for every command stream
> submission.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.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] drm/i915: Before pageflip, also wait for shared dmabuf fences.

[Mike Lothian]

Hi

This has discussion has gone a little quiet

Was there any agreement about what needed doing to get this working
for i965/amdgpu?

Regards

Mike

On Mon, 26 Sep 2016 at 09:04 Daniel Vetter  wrote:
>
> On Mon, Sep 26, 2016 at 09:48:37AM +0900, Michel Dänzer wrote:
> > On 23/09/16 09:09 PM, Daniel Vetter wrote:
> > > On Fri, Sep 23, 2016 at 07:00:25PM +0900, Michel Dänzer wrote:
> > >> On 22/09/16 10:22 PM, Christian König wrote:
> > >>> Am 22.09.2016 um 15:05 schrieb Daniel Vetter:
> > 
> >  But the current approach in amdgpu_sync.c of declaring a fence as
> >  exclusive after the fact (if owners don't match) just isn't how
> >  reservation_object works. You can of course change that, but that
> >  means you must change all drivers implementing support for implicit
> >  fencing of dma-buf. Fixing amdgpu will be easier ;-)
> > >>>
> > >>> Well as far as I can see there is no way I can fix amdgpu in this case.
> > >>>
> > >>> The handling clearly needs to be changed on the receiving side of the
> > >>> reservation objects if I don't completely want to disable concurrent
> > >>> access to BOs in amdgpu.
> > >>
> > >> Anyway, we need a solution for this between radeon and amdgpu, and I
> > >> don't think a solution which involves those drivers using reservation
> > >> object semantics between them which are different from all other drivers
> > >> is a good idea.
> > >
> > > Afaik there's also amd+intel machines out there,
> >
> > Sure, what I meant was that even if we didn't care about those (which we
> > do), we'd still need a solution between our own drivers.
> >
> >
> > > so really the only option is to either fix amdgpu to correctly set
> > > exclusive fences on shared buffers (with the help of userspace hints).
> > > Or change all the existing drivers.
> >
> > I got some fresh perspective on the problem while taking a walk, and I'm
> > now fairly convinced that neither amdgpu userspace nor other drivers
> > need to be modified:
> >
> > It occurred to me that all the information we need is already there in
> > the exclusive and shared fences set by amdgpu. We just need to use it
> > differently to match the expectations of other drivers.
> >
> > We should be able to set some sort of "pseudo" fence as the exclusive
> > fence of the reservation object. When we are asked by another driver to
> > wait for this fence to signal, we take the current "real" exclusive
> > fence (which we can keep track of e.g. in our BO struct) and shared
> > fences, and wait for all of those to signal; then we mark the "pseudo"
> > exclusive fence as signalled.
> >
> > Am I missing anything which would prevent this from working?
>
> One thing to make sure is that you don't change the (real, private stored)
> fences you're waiting on over the lifetime of the public exclusive fence.
> That might lead to some hilarity wrt potentially creating fence depency
> loops. But I think as long as you guarantee that the private internal
> fences are always amdgpu ones, and never anything imported from a
> different driver even that should be fine. Not because this would break
> the loops, but since amgpud has a hangcheck it can still gurantee that the
> fence eventually fires even if there is a loop.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: VRAM manager

[Mike Lothian]

Hi Christian

It's working for me on my Tonga now, thanks for fixing those bugs

Feel free to add a testing by

Cheers

Mike

On 27 September 2016 at 10:49, Christian König  wrote:
> Hi guys,
>
> after fixing all those nasty little bugs this seems to be stable now.
>
> Anybody brave enough to give it an review?
>
> Cheers,
> Christian.
>
> ___
> 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/amdgpu: allocate GTT space for shadow VM page tables

[Mike Lothian]

Does this fix the issue I was seeing since the new memory manager went into
thr 4.9-wip branch?

On Fri, 16 Sep 2016, 10:48 am Christian König, 
wrote:

> From: Christian König 
>
> We need to access those with the system domain.
>
> Fixes fallout from only allocating GTT space on demand.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index a6a48ed..8928a2a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -552,6 +552,10 @@ static int amdgpu_vm_clear_bo(struct amdgpu_device
> *adev,
> if (r)
> goto error;
>
> +   r = amdgpu_ttm_bind(>tbo, >tbo.mem);
> +   if (r)
> +   goto error;
> +
> addr = amdgpu_bo_gpu_offset(bo);
> entries = amdgpu_bo_size(bo) / 8;
>
> @@ -625,6 +629,11 @@ static int amdgpu_vm_update_pd_or_shadow(struct
> amdgpu_device *adev,
>
> if (!pd)
> return 0;
> +
> +   r = amdgpu_ttm_bind(>tbo, >tbo.mem);
> +   if (r)
> +   return r;
> +
> pd_addr = amdgpu_bo_gpu_offset(pd);
> ring = container_of(vm->entity.sched, struct amdgpu_ring, sched);
>
> @@ -650,6 +659,14 @@ static int amdgpu_vm_update_pd_or_shadow(struct
> amdgpu_device *adev,
> if (bo == NULL)
> continue;
>
> +   if (bo->shadow) {
> +   struct amdgpu_bo *shadow = bo->shadow;
> +
> +   r = amdgpu_ttm_bind(>tbo,
> >tbo.mem);
> +   if (r)
> +   return r;
> +   }
> +
> pt = amdgpu_bo_gpu_offset(bo);
> if (!shadow) {
> if (vm->page_tables[pt_idx].addr == pt)
> --
> 2.5.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