dri-devel November 2011

dri-devel@lists.freedesktop.org

110 participants
555 discussions

Start a nNew thread

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator V4
by j.glisse＠gmail.com 11 Nov '11

11 Nov '11

So squeezed all to avoid any memory accouting messing, seems to work ok so far. Cheers, Jerome

2 16

[PATCH] drm: avoid switching to text console if there is no panic timeout
by Mandeep Singh Baines 10 Nov '11

10 Nov '11

From: Hugh Dickins <hughd(a)chromium.org> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if we're going to reboot immediately, the user will not be able to see the messages anyway, and messing with the video mode may display artifacts, and certainly get into several layers of complexity (including mutexes and memory allocations) which we shall be much safer to avoid. Signed-off-by: Hugh Dickins <hughd(a)google.com> [ Edited commit message and modified to … [View More]

6 10

[PATCH] drm: Ensure string is null terminated.
by Vinson Lee 10 Nov '11

10 Nov '11

Fixes Coverity buffer not null terminated defect. Signed-off-by: Vinson Lee <vlee(a)vmware.com> --- drivers/gpu/drm/drm_crtc.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index f3ef654..40a3a14 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -2117,8 +2117,10 @@ struct drm_property *drm_property_create(struct drm_device *dev, int flags, property->num_values = … [View More]

1 0

[PATCH v3] drm/radeon: Make sure CS mutex is held across GPU reset.
by Michel Dänzer 10 Nov '11

10 Nov '11

From: Michel Dänzer <michel.daenzer(a)amd.com> This was only the case if the GPU reset was triggered from the CS ioctl, otherwise other processes could happily enter the CS ioctl and wreak havoc during the GPU reset. This is a little complicated because the GPU reset can be triggered from the CS ioctl, in which case we're already holding the mutex, or from other call paths, in which case we need to lock the mutex. AFAICT the mutex API doesn't allow recursive locking or finding out the … [View More]mutex owner, so we need to handle this with helper functions which allow recursive locking from the same process. Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Jerome Glisse <jglisse(a)redhat.com> --- v3: Drop spurious whitespace-only hunk, thanks Jerome for catching that. drivers/gpu/drm/radeon/radeon.h | 44 +++++++++++++++++++++++++++++++- drivers/gpu/drm/radeon/radeon_cs.c | 14 +++++----- drivers/gpu/drm/radeon/radeon_device.c | 16 ++++++++--- 3 files changed, 62 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index c1e056b..fa2ef96 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -1151,6 +1151,48 @@ struct r700_vram_scratch { volatile uint32_t *ptr; }; + +/* + * Mutex which allows recursive locking from the same process. + */ +struct radeon_mutex { + struct mutex mutex; + struct task_struct *owner; + int level; +}; + +static inline void radeon_mutex_init(struct radeon_mutex *mutex) +{ + mutex_init(&mutex->mutex); + mutex->owner = NULL; + mutex->level = 0; +} + +static inline void radeon_mutex_lock(struct radeon_mutex *mutex) +{ + if (mutex_trylock(&mutex->mutex)) { + /* The mutex was unlocked before, so it's ours now */ + mutex->owner = current; + } else if (mutex->owner != current) { + /* Another process locked the mutex, take it */ + mutex_lock(&mutex->mutex); + mutex->owner = current; + } + /* Otherwise the mutex was already locked by this process */ + + mutex->level++; +} + +static inline void radeon_mutex_unlock(struct radeon_mutex *mutex) +{ + if (--mutex->level > 0) + return; + + mutex->owner = NULL; + mutex_unlock(&mutex->mutex); +} + + /* * Core structure, functions and helpers. */ @@ -1206,7 +1248,7 @@ struct radeon_device { struct radeon_gem gem; struct radeon_pm pm; uint32_t bios_scratch[RADEON_BIOS_NUM_SCRATCH]; - struct mutex cs_mutex; + struct radeon_mutex cs_mutex; struct radeon_wb wb; struct radeon_dummy_page dummy_page; bool gpu_lockup; diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index fae00c0..ccaa243 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -222,7 +222,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) struct radeon_cs_chunk *ib_chunk; int r; - mutex_lock(&rdev->cs_mutex); + radeon_mutex_lock(&rdev->cs_mutex); /* initialize parser */ memset(&parser, 0, sizeof(struct radeon_cs_parser)); parser.filp = filp; @@ -233,14 +233,14 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) if (r) { DRM_ERROR("Failed to initialize parser !\n"); radeon_cs_parser_fini(&parser, r); - mutex_unlock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); return r; } r = radeon_ib_get(rdev, &parser.ib); if (r) { DRM_ERROR("Failed to get ib !\n"); radeon_cs_parser_fini(&parser, r); - mutex_unlock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); return r; } r = radeon_cs_parser_relocs(&parser); @@ -248,7 +248,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) if (r != -ERESTARTSYS) DRM_ERROR("Failed to parse relocation %d!\n", r); radeon_cs_parser_fini(&parser, r); - mutex_unlock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); return r; } /* Copy the packet into the IB, the parser will read from the @@ -260,14 +260,14 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) if (r || parser.parser_error) { DRM_ERROR("Invalid command stream !\n"); radeon_cs_parser_fini(&parser, r); - mutex_unlock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); return r; } r = radeon_cs_finish_pages(&parser); if (r) { DRM_ERROR("Invalid command stream !\n"); radeon_cs_parser_fini(&parser, r); - mutex_unlock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); return r; } r = radeon_ib_schedule(rdev, parser.ib); @@ -275,7 +275,7 @@ int radeon_cs_ioctl(struct drm_device *dev, void *data, struct drm_file *filp) DRM_ERROR("Failed to schedule IB !\n"); } radeon_cs_parser_fini(&parser, r); - mutex_unlock(&rdev->cs_mutex); + radeon_mutex_unlock(&rdev->cs_mutex); return r; } diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index b51e157..b632d57 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -716,7 +716,7 @@ int radeon_device_init(struct radeon_device *rdev, /* mutex initialization are all done here so we * can recall function without having locking issues */ - mutex_init(&rdev->cs_mutex); + radeon_mutex_init(&rdev->cs_mutex); mutex_init(&rdev->ib_pool.mutex); mutex_init(&rdev->cp.mutex); mutex_init(&rdev->dc_hw_i2c_mutex); @@ -954,6 +954,9 @@ int radeon_gpu_reset(struct radeon_device *rdev) int r; int resched; + /* Prevent CS ioctl from interfering */ + radeon_mutex_lock(&rdev->cs_mutex); + radeon_save_bios_scratch_regs(rdev); /* block TTM */ resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev); @@ -966,10 +969,15 @@ int radeon_gpu_reset(struct radeon_device *rdev) radeon_restore_bios_scratch_regs(rdev); drm_helper_resume_force_mode(rdev->ddev); ttm_bo_unlock_delayed_workqueue(&rdev->mman.bdev, resched); - return 0; } - /* bad news, how to tell it to userspace ? */ - dev_info(rdev->dev, "GPU reset failed\n"); + + radeon_mutex_unlock(&rdev->cs_mutex); + + if (r) { + /* bad news, how to tell it to userspace ? */ + dev_info(rdev->dev, "GPU reset failed\n"); + } + return r; } -- 1.7.7.2 [View Less]

1 0

[PATCH] drm/radeon/kms: fix use of vram scratch page on evergreen/ni
by alexdeucher＠gmail.com 10 Nov '11

10 Nov '11

From: Alex Deucher <alexander.deucher(a)amd.com> This hunk seems to have gotten lost when I rebased the patch. Reported-by: Sylvain Bertrand <sylvain.bertrand(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> --- drivers/gpu/drm/radeon/evergreen.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index c6761e8..0067f11 100644 --- a/drivers/gpu/drm/radeon/… [View More]

1 0

Re: Linux 3.2-rc1
by Linus Torvalds 10 Nov '11

10 Nov '11

Hmm, I don't know what caused this to trigger, but I'm adding both the i915 people and the HDA people to the cc, and they can fight to the death about this in the HDMI Thunderdome. Guys: One.. Two.. Three.. FIGHT! Linus On Tue, Nov 8, 2011 at 6:55 AM, Nick Bowler <nbowler(a)elliptictech.com> wrote: > > Mode switches are very noisy on an Intel G45 in 3.2-rc1: > > HDMI hot plug event: Codec=3 Pin=3 Presence_Detect=1 ELD_Valid=1 > HDMI status: … [View More]

3 3

r600 hdmi sound issue
by Greg Dietsche 09 Nov '11

09 Nov '11

Hi, I have a ASUS M4A89GTD motherboard and when I play back music in Rhythmbox, there is no sound (hdmi connection). Also, the playback speed is in a sort of fast forward (for example, after a few seconds of real time, rhythmbox shows something like 30 seconds into the song). This seems to be a kernel regression. I know that it started with 3.0, is present in 3.1, and is not working in 3.2-rc1, so it is still a problem. I bisected and found my self here: … [View More]

2 3

Isolate dma information from ttm_tt
by j.glisse＠gmail.com 09 Nov '11

09 Nov '11

This apply on top of the ttm_tt & backend merge patchset. Cheers, Jerome

1 1

[PATCH] drm: serialize access to debugs_nodes.list
by Marcin Slusarz 09 Nov '11

09 Nov '11

Nouveau, when configured with debugfs, creates debugfs files for every channel, so structure holding list of files needs to be protected from simultaneous changes by multiple threads. Without this patch it's possible to hit kernel oops in drm_debugfs_remove_files just by running a couple of xterms with looped glxinfo. Signed-off-by: Marcin Slusarz <marcin.slusarz(a)gmail.com> --- drivers/gpu/drm/drm_debugfs.c | 5 +++++ include/drm/drmP.h | 1 + 2 files changed, 6 … [View More]

2 5

ttm: merge ttm_backend & ttm_tt, introduce ttm dma allocator [FULL]
by j.glisse＠gmail.com 09 Nov '11

09 Nov '11

Ok so here is full patchset, including nouveau support, Ben if you could review (if change to nouveau in patch 7 are correct then others change to nouveau are more than likely 100% correct :)). So been tested on R7XX,EVERGREEN,CAICOS,CAYMAN with SWIOTLB. Also tested on NV50. I still need to test AGP configuration but i am quite confident that there is no regression for PCIE/PCI. Cheers, Jerome

4 26

← Newer
1
...
47
48
49
50
51
52
53
...
56
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2011