Am 11.05.20 um 22:56 schrieb Al Dunsmuir:
Hello Dave,
On Monday, May 11, 2020, 4:43:01 PM, Dave Airlie wrote:
On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
[SNIP]
Maybe we can find some way to compartmentalise AGP further?
Dave.
Significantly reduced caching on memory accesses defin
On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> On Mon, May 11, 2020 at 1:17 PM Christian König
> wrote:
>>
>> AGP is deprecated for 10+ years now and not used any more on modern hardware.
>>
>> Old hardware should continue to work in PCI mode.
>
> Might want to clarify that there is no loss of f
This is a bit tricky, since ->notifier_lock is held while calling
dma_fence_wait we must ensure that also the read side (i.e.
dma_fence_begin_signalling) is on the same side. If we mix this up
lockdep complaints, and that's again why we want to have these
annotations.
A nice side effect of this is
I need a canary in a ttm-based atomic driver to make sure the
dma_fence_begin/end_signalling annotations actually work.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-r...@vger.kernel.org
Cc: amd-gfx@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: Chris
If the scheduler rt thread gets stuck on a mutex that we're holding
while waiting for gpu workloads to complete, we have a problem.
Add dma-fence annotations so that lockdep can check this for us.
I've tried to quite carefully review this, and I think it's at the
right spot. But obviosly no exper
Trying to grab dma_resv_lock while in commit_tail before we've done
all the code that leads to the eventual signalling of the vblank event
(which can be a dma_fence) is deadlock-y. Don't do that.
Here the solution is easy because just grabbing locks to read
something races anyway. We don't need to
i915 does tons of allocations from this worker, which lockdep catches.
Also generic infrastructure like this with big potential for how
dma_fence or other cross driver contracts work, really should be
reviewed on dri-devel. Implementing custom wheels for everything
within the driver is a classic c
But only for non-zero timeout, to avoid false positives.
One question here is whether the might_sleep should be unconditional,
or only for real timeouts. I'm not sure, so went with the more
defensive option. But in the interest of locking down the cross-driver
dma_fence rules we might want to be m
Hi all,
I've dragged my feet for years on this, hoping that cross-release lockdep
would do this for us, but well that never really happened unfortunately.
So here we are.
Cc'ed quite a pile of people since this is about the cross-driver contract
around dma_fences. Which is heavily used for dma_bu
In the face of unpriviledged userspace being able to submit bogus gpu
workloads the kernel needs gpu timeout and reset (tdr) to guarantee
that dma_fences actually complete. Annotate this worker to make sure
we don't have any accidental locking inversions or other problems
lurking.
Originally this
Not going to bother with a complete&pretty commit message, just
offending backtrace:
kvmalloc_node+0x47/0x80
dc_create_state+0x1f/0x60 [amdgpu]
dc_commit_state+0xcb/0x9b0 [amdgpu]
amdgpu_dm_atomic_commit_tail+0xd31/0x2010 [amdgpu]
commit_tail+0xa4/0x140 [drm
This is needed to signal the fences from page flips, annotate it
accordingly. We need to annotate entire timer callback since if we get
stuck anywhere in there, then the timer stops, and hence fences stop.
Just annotating the top part that does the vblank handling isn't
enough.
Cc: linux-me...@vge
Design is similar to the lockdep annotations for workers, but with
some twists:
- We use a read-lock for the execution/worker/completion side, so that
this explicit annotation can be more liberally sprinkled around.
With read locks lockdep isn't going to complain if the read-side
isn't neste
This is one from the department of "maybe play lottery if you hit
this, karma compensation might work". Or at least lockdep ftw!
This reverts commit 565d1941557756a584ac357d945bc374d5fcd1d0.
It's not quite as low-risk as the commit message claims, because this
grabs console_lock, which might be h
This is a bit disappointing since we need to split the annotations
over all the different parts.
I was considering just leaking the critical section into the
->atomic_commit_tail callback of each driver. But that would mean we
need to pass the fence_cookie into each driver (there's a total of 13
i
This is rather overkill since currently all drivers call this from
hardirq (or at least timers). But maybe in the future we're going to
have thread irq handlers and what not, doesn't hurt to be prepared.
Plus this is an easy start for sprinkling these fence annotations into
shared code.
Cc: linux-
To improve coverage also annotate the gpu reset code itself, since
that's called from other places than drm/scheduler (which is already
annotated). Annotations nests, so this doesn't break anything, and
allows easier testing.
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Cc: l
Two in one go:
- it is allowed to call dma_fence_wait() while holding a
dma_resv_lock(). This is fundamental to how eviction works with ttm,
so required.
- it is allowed to call dma_fence_wait() from memory reclaim contexts,
specifically from shrinker callbacks (which i915 does), and from mm
...
I think it's time to stop this little exercise.
The lockdep splat, for the record:
[ 132.583381] ==
[ 132.584091] WARNING: possible circular locking dependency detected
[ 132.584775] 5.7.0-rc3+ #346 Tainted: GW
[ 132.585461] ---
My dma-fence lockdep annotations caught an inversion because we
allocate memory where we really shouldn't:
kmem_cache_alloc+0x2b/0x6d0
amdgpu_fence_emit+0x30/0x330 [amdgpu]
amdgpu_ib_schedule+0x306/0x550 [amdgpu]
amdgpu_job_run+0x10f/0x260 [amdgpu]
drm_sched
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Quoting Daniel Vetter (2020-05-12 09:59:28)
> But only for non-zero timeout, to avoid false positives.
>
> One question here is whether the might_sleep should be unconditional,
> or only for real timeouts. I'm not sure, so went with the more
> defensive option. But in the interest of locking down
Quoting Daniel Vetter (2020-05-12 09:59:29)
> Design is similar to the lockdep annotations for workers, but with
> some twists:
>
> - We use a read-lock for the execution/worker/completion side, so that
> this explicit annotation can be more liberally sprinkled around.
> With read locks lockde
Am 12.05.20 um 10:59 schrieb Daniel Vetter:
But only for non-zero timeout, to avoid false positives.
One question here is whether the might_sleep should be unconditional,
or only for real timeouts. I'm not sure, so went with the more
defensive option. But in the interest of locking down the cros
On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2020-05-12 09:59:29)
> > Design is similar to the lockdep annotations for workers, but with
> > some twists:
> >
> > - We use a read-lock for the execution/worker/completion side, so that
> > this explicit ann
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
Quoting Daniel Vetter (2020-05-12 10:08:47)
> On Tue, May 12, 2020 at 10:04:22AM +0100, Chris Wilson wrote:
> > Quoting Daniel Vetter (2020-05-12 09:59:29)
> > > Design is similar to the lockdep annotations for workers, but with
> > > some twists:
> > >
> > > - We use a read-lock for the execution
There is no need to use amdgpu_mm_wreg_mmio_rlc()
during initialization time because this interface
is only designed for debugfs case to access the
registers which are only permitted by RLCG during
run-time. Therefore, turn back rlcg write for gfx_v10.
If we not turn back it, it will raise amdgpu l
There will be no further interrupt without proper ack
for current one.
Change-Id: Iad5adcaf7dd5c3a773b3d93ee0922a424dba8ac8
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/smu_v11_0.c
On Tue, May 12, 2020 at 10:59:29AM +0200, Daniel Vetter wrote:
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 6802125349fb..d5c0fd2efc70 100644
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -110,6 +110,52 @@ u64 dma_fence_context_alloc(unsigned num)
> }
> EXPORT_SYMBO
On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote:
>
> ...
>
> I think it's time to stop this little exercise.
>
> The lockdep splat, for the record:
>
> [ 132.583381] ==
> [ 132.584091] WARNING: possible circular locking dependency detected
On Tue, May 12, 2020 at 09:09:52AM -0300, Jason Gunthorpe wrote:
> On Tue, May 12, 2020 at 10:59:29AM +0200, Daniel Vetter wrote:
> > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> > index 6802125349fb..d5c0fd2efc70 100644
> > +++ b/drivers/dma-buf/dma-fence.c
> > @@ -110,
On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> On Tue, May 12, 2020 at 5:00 AM Daniel Vetter wrote:
> >
> > ...
> >
> > I think it's time to stop this little exercise.
> >
> > The lockdep splat, for the record:
> >
> > [ 132.583381] ===
On Tue, May 12, 2020 at 7:14 AM Evan Quan wrote:
>
> There will be no further interrupt without proper ack
> for current one.
>
> Change-Id: Iad5adcaf7dd5c3a773b3d93ee0922a424dba8ac8
> Signed-off-by: Evan Quan
> ---
> drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++
> 1 file changed, 6 inse
On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter
> > wrote:
> > >
> > > ...
> > >
> > > I think it's time to stop this little exercise.
> > >
> > > The lockdep splat, for the r
On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > > On Tue, May 12, 2020 at 5:00 AM Daniel Vetter
> > > wrote:
> > > >
> > > > ...
> > > >
> > > > I think it's ti
On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
> >
> > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> > >
> > > On Tue, May 12, 2020 at 08:54:45AM -0400, Alex Deucher wrote:
> > > > On Tue, May 12, 2020 at 5:00 AM Daniel Vette
From: Colin Ian King
The variable ret is being initializeed with a value that is never read
and it is being updated later with a new value. The initialization
is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdg
On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote:
>
> On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> > On Mon, May 11, 2020 at 1:17 PM Christian König
> > wrote:
> >>
> >> AGP is deprecated for 10+ years now and not used any more on modern
> >> hardware.
> >>
> >> Old hardware should continu
On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:12 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 8:58 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, May 12, 2020 at 08:54:45AM -0400, Ale
Ping...
-Original Message-
From: Yintian Tao
Sent: 2020年5月12日 18:17
To: Deucher, Alexander ; Liu, Monk
; Liu, Shaoyun
Cc: amd-gfx@lists.freedesktop.org; Tao, Yintian
Subject: [PATCH] drm/amdgpu: turn back rlcg write for gfx_v10
There is no need to use amdgpu_mm_wreg_mmio_rlc() during
On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
> >
> > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter
> > wrote:
> > >
> > > On Tue, May 12, 2020 at 3:12 PM Alex Deucher
> > > wrote:
> > > >
> > > > On Tue, May 12, 2020 at 8:58 AM D
[AMD Public Use]
Acked-by: Alex Deucher
From: Yintian Tao
Sent: Tuesday, May 12, 2020 6:17 AM
To: Deucher, Alexander ; Liu, Monk
; Liu, Shaoyun
Cc: amd-gfx@lists.freedesktop.org ; Tao, Yintian
Subject: [PATCH] drm/amdgpu: turn back rlcg write for gfx_v10
The
On Tue, May 12, 2020 at 8:48 AM Colin King wrote:
>
> From: Colin Ian King
>
> The variable ret is being initializeed with a value that is never read
> and it is being updated later with a new value. The initialization
> is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
>
Hui what? Of hand that doesn't looks correct to me.
Why the heck should this be an atomic context? If that's correct
allocating memory is the least of the problems we have.
Regards,
Christian.
Am 12.05.20 um 10:59 schrieb Daniel Vetter:
My dma-fence lockdep annotations caught an inversion be
On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote:
>
> On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
> >
> > On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
> > >
> > > On Tue, May 12, 2020 at 9:17 AM Daniel Vetter
> > > wrote:
> > > >
> > > > On Tue, May 12, 2020 at 3:12 PM Alex D
On Tue, May 12, 2020 at 5:56 PM Christian König
wrote:
>
> Hui what? Of hand that doesn't looks correct to me.
It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we
have to avoid direct reclaim. And direct reclaim might need to call
into your mmu notifier, which might need to wait
On Tue, May 12, 2020 at 6:20 PM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 5:56 PM Christian König
> wrote:
> >
> > Hui what? Of hand that doesn't looks correct to me.
>
> It's not GFP_ATOMIC, it's just that GFP_ATOMIC is the only shotgun we
> have to avoid direct reclaim. And direct reclai
[Why]
At bringup we want to be able to disable various power features.
[How]
These features are already exposed as dc_debug_options and exercised
on other OSes. Create a new dc_debug_mask module parameter and expose
relevant bits, in particular
* DC_DISABLE_PIPE_SPLIT
* DC_DISABLE_STUTTER
* DC_
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
1 file changed, 3 insertions(+), 3 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 bf347ca43064..9d833264 100
[Why & How]
One call was forcing stutter on instead of looking at the debug option.
Ensure we always check the debug option unless we want to force stutter
off.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubbub.c | 1 -
drivers/gpu/drm/amd/display/dc/dcn10
To facilitate bringup of new ASICs, debugging, and measuring of
various power features we would like the ability to disable them
as needed.
This differs from dcfeaturemask in that dcfeaturemask is a collection
of experimental features that can't be enabled by default, whereas
dcdebugmask is a coll
On 2020-05-12 12:45 p.m., Harry Wentland wrote:
[Why]
At bringup we want to be able to disable various power features.
[How]
These features are already exposed as dc_debug_options and exercised
on other OSes. Create a new dc_debug_mask module parameter and expose
relevant bits, in particular
*
[AMD Public Use]
[AMD Public Use]
Hi, YinTao
The write to CSIB register through RLCG requires RLCG firmware to support it.
This currently only implemented by nv12 . So you need to find a way to block it
for other GFX 10 asic like NV14 , nv21 if you want to revert the code.
On existing code
On 2020-05-12 12:54 p.m., Kazlauskas, Nicholas wrote:
> On 2020-05-12 12:45 p.m., Harry Wentland wrote:
>> [Why]
>> At bringup we want to be able to disable various power features.
>>
>> [How]
>> These features are already exposed as dc_debug_options and exercised
>> on other OSes. Create a new d
On 2020-05-12 12:54 p.m., Kazlauskas, Nicholas wrote:
> On 2020-05-12 12:45 p.m., Harry Wentland wrote:
>> [Why]
>> At bringup we want to be able to disable various power features.
>>
>> [How]
>> These features are already exposed as dc_debug_options and exercised
>> on other OSes. Create a new d
Ah!
So we can't allocate memory while scheduling anything because it could
be that memory reclaim is waiting for the scheduler to finish pushing
things to the hardware, right?
Indeed a nice problem, haven't noticed that one.
Christian.
Am 12.05.20 um 18:27 schrieb Daniel Vetter:
On Tue, Ma
Hi Christian
Am 11.05.20 um 19:17 schrieb Christian König:
> AGP is deprecated for 10+ years now and not used any more on modern hardware.
>
> Old hardware should continue to work in PCI mode.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/Makefile| 4 +-
> drivers
On Tue, May 12, 2020 at 2:20 PM Thomas Zimmermann wrote:
>
> Hi Christian
>
> Am 11.05.20 um 19:17 schrieb Christian König:
> > AGP is deprecated for 10+ years now and not used any more on modern
> > hardware.
> >
> > Old hardware should continue to work in PCI mode.
> >
> > Signed-off-by: Christ
Hi
Am 11.05.20 um 19:17 schrieb Christian König:
> Hi guys,
>
> Well let's face it AGP is a total headache to maintain and dead for at least
> 10+ years.
>
> We have a lot of x86 specific stuff in the architecture independent graphics
> memory management to get the caching right, abusing the D
On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 11.05.20 um 19:17 schrieb Christian König:
> > Hi guys,
> >
> > Well let's face it AGP is a total headache to maintain and dead for at
> > least 10+ years.
> >
> > We have a lot of x86 specific stuff in the architecture indepe
On Tue, May 12, 2020 at 7:31 PM Christian König
wrote:
>
> Ah!
>
> So we can't allocate memory while scheduling anything because it could
> be that memory reclaim is waiting for the scheduler to finish pushing
> things to the hardware, right?
Yup, that's my understanding. But like with all things
Hi Alex
Am 12.05.20 um 20:32 schrieb Alex Deucher:
> On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 11.05.20 um 19:17 schrieb Christian König:
>>> Hi guys,
>>>
>>> Well let's face it AGP is a total headache to maintain and dead for at
>>> least 10+ years.
>>>
>>> We h
On Tue, May 12, 2020 at 3:10 PM Thomas Zimmermann wrote:
>
> Hi Alex
>
> Am 12.05.20 um 20:32 schrieb Alex Deucher:
> > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 11.05.20 um 19:17 schrieb Christian König:
> >>> Hi guys,
> >>>
> >>> Well let's face it
On 2020-05-12 12:12 p.m., Daniel Vetter wrote:
On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 9:45 AM Daniel Vetter wrote:
On Tue, May 12, 2020 at 3:29 PM Alex Deucher wrote:
On Tue, May 12, 2020 at 9:17 AM Daniel Vetter wrote:
On Tue, May 12, 2020 at 3:12
Ping?
Alex
On Thu, May 7, 2020 at 12:09 PM Alex Deucher wrote:
>
> Ping?
>
> On Tue, May 5, 2020 at 3:48 PM Alex Deucher wrote:
> >
> > Just register the a pointer to the backlight device and use
> > that. Unifies the DC and non-DC handling.
> >
> > Signed-off-by: Alex Deucher
> > ---
> > dri
On Tue, May 12, 2020 at 4:52 PM Roy Spliet wrote:
>
> Op 12-05-2020 om 14:36 schreef Alex Deucher:
> > On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote:
> >>
> >> On 2020-05-11 10:12 p.m., Alex Deucher wrote:
> >>> On Mon, May 11, 2020 at 1:17 PM Christian König
> >>> wrote:
>
> AGP
Op 12-05-2020 om 14:36 schreef Alex Deucher:
On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote:
On 2020-05-11 10:12 p.m., Alex Deucher wrote:
On Mon, May 11, 2020 at 1:17 PM Christian König
wrote:
AGP is deprecated for 10+ years now and not used any more on modern hardware.
Old hardware
Hi Dave, Daniel,
More stuff for 5.8.
The following changes since commit b8020b0304c8f44e5e29f0b1a04d31e0bf68d26a:
drm/amdkfd: Enable over-subscription with >1 GWS queue (2020-04-28 16:20:30
-0400)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-d
[AMD Official Use Only - Internal Distribution Only]
Just setting the ACK bit is enough and no need to touch other bits.
It's aligned with windows and confirmed by my local test.
Thanks,
Evan
-Original Message-
From: Alex Deucher
Sent: Tuesday, May 12, 2020 9:05 PM
To: Quan, Evan
Cc: am
[AMD Official Use Only - Internal Distribution Only]
-Original Message-
From: Alex Deucher
Sent: Tuesday, May 12, 2020 9:05 PM
To: Quan, Evan
Cc: amd-gfx list ; Deucher, Alexander
Subject: Re: [PATCH] drm/amd/powerplay: ack the SMUToHost interrupt on receive
On Tue, May 12, 2020 at 7:
There will be no further interrupt without proper ack
for current one.
V2: fix typo to really set ACK bit only
Change-Id: Iad5adcaf7dd5c3a773b3d93ee0922a424dba8ac8
Signed-off-by: Evan Quan
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 6 ++
1 file changed, 6 ins
On Tue, May 12, 2020 at 10:10 PM Kazlauskas, Nicholas
wrote:
>
> On 2020-05-12 12:12 p.m., Daniel Vetter wrote:
> > On Tue, May 12, 2020 at 4:24 PM Alex Deucher wrote:
> >>
> >> On Tue, May 12, 2020 at 9:45 AM Daniel Vetter
> >> wrote:
> >>>
> >>> On Tue, May 12, 2020 at 3:29 PM Alex Deucher
73 matches
Mail list logo
