From: "Christian König" <christian.koenig@amd.com>
To: Maarten Lankhorst <maarten.lankhorst@canonical.com>, airlied@linux.ie
Cc: thellstrom@vmware.com, nouveau@lists.freedesktop.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
bskeggs@redhat.com, alexander.deucher@amd.com
Subject: Re: [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2
Date: Mon, 4 Aug 2014 16:45:28 +0200 [thread overview]
Message-ID: <53DF9C88.6060107@amd.com> (raw)
In-Reply-To: <53DF9B58.8000403@canonical.com>
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
> op 04-08-14 16:37, Christian König schreef:
>>> It'a pain to deal with gpu reset.
>> Yeah, well that's nothing new.
>>
>>> I've now tried other solutions but that would mean reverting to the old style during gpu lockup recovery, and only running the delayed work when !lockup.
>>> But this meant that the timeout was useless to add. I think the cleanest is keeping the v2 patch, because potentially any waiting code can be called during lockup recovery.
>> The lockup code itself should never call any waiting code and V2 doesn't seem to handle a couple of cases correctly either.
>>
>> How about moving the fence waiting out of the reset code?
> What cases did I miss then?
>
> I'm curious how you want to move the fence waiting out of reset, when there are so many places that could potentially wait, like radeon_ib_get can call radeon_sa_bo_new which can do a wait, or radeon_ring_alloc that can wait on radeon_fence_wait_next, etc.
The IB test itself doesn't needs to be protected by the exclusive lock.
Only everything between radeon_save_bios_scratch_regs and
radeon_ring_restore.
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-08-04 14:45 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 15:32 [PATCH 01/19] fence: add debugging lines to fence_is_signaled for the callback Maarten Lankhorst
2014-07-31 15:32 ` [PATCH 02/19] drm/ttm: add interruptible parameter to ttm_eu_reserve_buffers Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 03/19] drm/ttm: kill off some members to ttm_validate_buffer Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 04/19] drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 05/19] drm/nouveau: require reservations for nouveau_fence_sync and nouveau_bo_fence Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 06/19] drm/ttm: call ttm_bo_wait while inside a reservation Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 07/19] drm/ttm: kill fence_lock Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 08/19] drm/nouveau: rework to new fence interface Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 09/19] drm/radeon: handle lockup in delayed work, v2 Maarten Lankhorst
2014-08-01 16:35 ` Christian König
2014-08-01 17:46 ` Maarten Lankhorst
2014-08-04 8:36 ` Christian König
[not found] ` <53DF462B.2060102-5C7GfCeVMHo@public.gmane.org>
2014-08-04 8:55 ` Maarten Lankhorst
2014-08-04 11:57 ` Christian König
2014-08-04 13:34 ` Maarten Lankhorst
2014-08-04 14:37 ` Christian König
2014-08-04 14:40 ` Maarten Lankhorst
2014-08-04 14:45 ` Christian König [this message]
2014-08-04 14:58 ` Maarten Lankhorst
2014-08-04 15:04 ` Christian König
2014-08-04 15:09 ` Maarten Lankhorst
2014-08-04 17:04 ` Christian König
[not found] ` <53DFBD2E.5070001-5C7GfCeVMHo@public.gmane.org>
2014-08-05 8:16 ` Daniel Vetter
2014-08-05 9:34 ` Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 10/19] drm/radeon: add timeout argument to radeon_fence_wait_seq Maarten Lankhorst
2014-07-31 15:33 ` [PATCH 11/19] drm/radeon: use common fence implementation for fences, v2 Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 12/19] drm/qxl: rework to new fence interface Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 13/19] drm/vmwgfx: get rid of different types of fence_flags entirely Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 14/19] drm/vmwgfx: rework to new fence interface Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 15/19] drm/ttm: flip the switch, and convert to dma_fence Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 16/19] drm/nouveau: use rcu in nouveau_gem_ioctl_cpu_prep Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 17/19] drm/radeon: use rcu waits in some ioctls Maarten Lankhorst
2014-08-01 8:27 ` Michel Dänzer
2014-08-01 10:12 ` Maarten Lankhorst
2014-08-01 14:13 ` Michel Dänzer
2014-08-01 17:07 ` Maarten Lankhorst
2014-08-04 8:42 ` Michel Dänzer
2014-08-04 8:56 ` Maarten Lankhorst
2014-08-04 9:25 ` Michel Dänzer
2014-08-04 9:30 ` Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 18/19] drm/vmwgfx: use rcu in vmw_user_dmabuf_synccpu_grab Maarten Lankhorst
2014-07-31 15:34 ` [PATCH 19/19] drm/ttm: use rcu in core ttm Maarten Lankhorst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DF9C88.6060107@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@linux.ie \
--cc=alexander.deucher@amd.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@canonical.com \
--cc=nouveau@lists.freedesktop.org \
--cc=thellstrom@vmware.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).