Maybe I'm doing something wrong, but my cloned repo of drm-radeon-testing is giving build errors. What I'm seeing is
[...] CC drivers/gpu/drm/radeon/radeon_gem.o drivers/gpu/drm/radeon/radeon_gem.c: In function ‘radeon_gem_create_ioctl’: drivers/gpu/drm/radeon/radeon_gem.c:221:3: error: implicit declaration of function ‘radeon_mutex_lock’ [-Werror=implicit-function-declaration] drivers/gpu/drm/radeon/radeon_gem.c:221:26: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ drivers/gpu/drm/radeon/radeon_gem.c:222:3: error: implicit declaration of function ‘radeon_mutex_unlock’ [-Werror=implicit-function-declaration] drivers/gpu/drm/radeon/radeon_gem.c:222:28: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ drivers/gpu/drm/radeon/radeon_gem.c: In function ‘radeon_gem_set_domain_ioctl’: drivers/gpu/drm/radeon/radeon_gem.c:268:26: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ drivers/gpu/drm/radeon/radeon_gem.c:269:28: error: ‘struct radeon_device’ has no member named ‘cs_mutex’ cc1: some warnings being treated as errors make[6]: *** [drivers/gpu/drm/radeon/radeon_gem.o] Error 1
Looking around a bit, I find this commit
commit 36ff39c4045ee71cd306f8af5f8c2a1c6e998eba Author: Christian König deathsimple@vodafone.de Date: Wed May 9 10:07:08 2012 +0200
drm/radeon: replace cs_mutex with vm_mutex v3
replaces radeon_mutex_lock()/radeon_mutex_unlock() with mutex_lock()/mutex_unlock() in most places, eliminating it in others. A more recent commit
commit 0a01063d5fd7417175512f0f916629008c0a842e Author: Jerome Glisse jglisse@redhat.com Date: Wed Jun 27 14:14:21 2012 -0400
drm/radeon: disable any GPU activity after unrecovered lockup v5
introduces this hunk:
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c b/drivers/gpu/drm/radeon/radeon_gem.c index f28bd4b..74176c5 100644 --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -217,6 +217,22 @@ int radeon_gem_create_ioctl(struct drm_device *dev, void *data, uint32_t handle; int r;
+ /* if in middle of gpu reset wait on the mutex, if reset + * failed don't do anything, otherwise proceed. + */ + if (!rdev->accel_working) { + /* lockup situation wait for cs mutex to be droped */ + radeon_mutex_lock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); + /* we are after a gpu reset */ + if (!rdev->accel_working) { + /* gpu reset failed, don't create anymore GPU + * object + */ + return -EBUSY; + } + } +
If it's not just something stupid I've done on my local machine, then it looks like the 0a01063d patch was applied without noticing the changes made in 36ff39c4. (If the problem is really just me, sorry for the spam/ noise.)
Dave W.
On Tue, Jul 3, 2012 at 6:02 PM, David Witbrodt dawitbro@sbcglobal.net wrote:
Maybe I'm doing something wrong, but my cloned repo of drm-radeon-testing is giving build errors. What I'm seeing is
Oh I wasn't aware anyone still used it, I just pushed a branch for Jerome the other day to test something, its known broken.
Dave.
Oh I wasn't aware anyone still used it, I just pushed a branch for
Jerome the other day to test something, its known broken.
Oh, boy... sorry for the noise, then. This was caused by the way I am using git: I cloned the Linus Torvalds tree, and then used 'git add' to include several trees, like Ingo's "tip", Greg's stable kernels, and (of course) "drm-airlied".
When you added that patch to d-r-testing, then some output was caused when I ran 'git remote update', and I assumed there was something happening there that might be interesting. I cherry pick commits from drm-fixes and drm-next into my own branch off of the latest GregKH stable kernel; this prevents me from facing consequences in other areas due to merge window insanity, but gives me early warning if radeon-related stuff is going to cause me problems in the future.
Sorry about this, Dave! Dave Witbrodt
dri-devel@lists.freedesktop.org