[PATCH] drm/amdgpu: nuke the ih reentrant lock
Daniel Vetter
daniel at ffwll.ch
Fri Mar 12 14:35:50 UTC 2021
On Fri, Mar 12, 2021 at 03:27:58PM +0100, Christian König wrote:
>
>
> Am 12.03.21 um 15:04 schrieb Daniel Vetter:
> > On Fri, Mar 12, 2021 at 02:59:06PM +0100, Christian König wrote:
> > > Interrupts on are non-reentrant on linux. This is just an ancient
> > > leftover from radeon where irq processing was kicked of from different
> > > places.
> > >
> > > Signed-off-by: Christian König <christian.koenig at amd.com>
> > Man you tricked me into grepping this on radeon and it looks horrible.
> > atomic_t is unordered in linux, so whatever was built there for radeon
> > does not wokr like a lock. It's missing all the barriers afiui. Good
> > riddance at least for amdgpu.
>
> Hui? atomic_xchg() is perfectly ordered as far as I know.
Oh right, if atomic_ returns a value it's fully ordered. Nice tour into
memory-barriers.txt. It's the atomic_t operations that don't return
anything which are fully unordered, and I mixed that up.
> IIRC Alex added this for R600 because we had boards where interrupts where
> sporadically swallowed during driver startup and we had to kick of ring
> buffer processing manually.
>
> Anyway we have a fence processing fallback timer in amdgpu instead and that
> stuff is probably unused on any modern hardware.
Ah yes that stuff. Kinda annoying we have these old dma_fence around where
dma_fence_wait doesn't really work that well, but oh well.
-Daniel
>
> > Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> Thanks,
> Christian.
>
> >
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c | 5 -----
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h | 1 -
> > > 3 files changed, 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > index a15f1b604733..886625fb464b 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > > @@ -3284,7 +3284,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> > > /* mutex initialization are all done here so we
> > > * can recall function without having locking issues */
> > > - atomic_set(&adev->irq.ih.lock, 0);
> > > mutex_init(&adev->firmware.mutex);
> > > mutex_init(&adev->pm.mutex);
> > > mutex_init(&adev->gfx.gpu_clock_mutex);
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
> > > index 1024065f1f03..faaa6aa2faaf 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.c
> > > @@ -228,10 +228,6 @@ int amdgpu_ih_process(struct amdgpu_device *adev, struct amdgpu_ih_ring *ih)
> > > wptr = amdgpu_ih_get_wptr(adev, ih);
> > > restart_ih:
> > > - /* is somebody else already processing irqs? */
> > > - if (atomic_xchg(&ih->lock, 1))
> > > - return IRQ_NONE;
> > > -
> > > DRM_DEBUG("%s: rptr %d, wptr %d\n", __func__, ih->rptr, wptr);
> > > /* Order reading of wptr vs. reading of IH ring data */
> > > @@ -244,7 +240,6 @@ int amdgpu_ih_process(struct amdgpu_device *adev, struct amdgpu_ih_ring *ih)
> > > amdgpu_ih_set_rptr(adev, ih);
> > > wake_up_all(&ih->wait_process);
> > > - atomic_set(&ih->lock, 0);
> > > /* make sure wptr hasn't changed while processing */
> > > wptr = amdgpu_ih_get_wptr(adev, ih);
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
> > > index 87ec6d20dbe0..0649b59830a5 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ih.h
> > > @@ -64,7 +64,6 @@ struct amdgpu_ih_ring {
> > > bool enabled;
> > > unsigned rptr;
> > > - atomic_t lock;
> > > struct amdgpu_ih_regs ih_regs;
> > > /* For waiting on IH processing at checkpoint. */
> > > --
> > > 2.25.1
> > >
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list