[Bug 52491] radeon massive screen corruption BARTS HD6870

https://bugzilla.kernel.org/show_bug.cgi?id=52491 --- Comment #2 from Bruno J. 2013-01-10 23:00:51 --- Still happening in rc3 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the

[Bug 59219] [radeon BUG] Sleeping function called from invalid context

mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/09c2a755/attachment.html>

[Bug 59219] New: [radeon BUG] Sleeping function called from invalid context

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/0bd551a8/attachment-0001.html>

[PATCH 12/35] drm/gma500: use drm_modeset_lock_all

On Thu, 10 Jan 2013 21:47:53 +0100 Daniel Vetter wrote: > Only two places: > - suspend/resume > - Some really strange mode validation tool with too much funny-lucking > hand-rolled conversion code. > - The recently-added lastclose fbdev restore code. > > Better safe than sorry, so convert

[PATCH libdrm 0/4] Manpages for libdrm

Hi Jesse On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes wrote: > On Fri, 28 Sep 2012 23:44:18 +0200 > David Herrmann wrote: > >> Hi >> >> This is revision 2 of the manpages for libdrm. I converted everything to >> docbook >> XML. This makes it easier to write them (troff is really hard to

[git pull] drm intel fixes

Hi Linus, Just intel fixes, including getting the Ironlake systems back to the state they were in for 3.6. Dave. The following changes since commit ecf02a607bd801e742d7bb35c6e40f7ca15edf03: Merge branch 'for_linus' of git://cavan.codon.org.uk/platform-drivers-x86 (2013-01-10 09:09:41

[PATCH 36/36] drm/i915: wake up all pageflip waiters

On Thu, Jan 10, 2013 at 9:48 PM, Daniel Vetter wrote: > Otherwise it seems like we can get stuck with concurrent waiters. > Right now this /shouldn't/ be a problem, since all pending pageflip > waiters are serialized by the one mode_config.mutex, so there's at > most on waiter. But better

[PATCH 36/36] drm/i915: wake up all pageflip waiters

Otherwise it seems like we can get stuck with concurrent waiters. Right now this /shouldn't/ be a problem, since all pending pageflip waiters are serialized by the one mode_config.mutex, so there's at most on waiter. But better paranoid than sorry, since this is tricky code. v2:

[PATCH 35/35] drm/fb_helper: check whether fbcon is bound

We need to make sure that the fbcon is still bound when touching the hw, since otherwise we might corrupt the modeset state of kms clients. X mostly works around that with VT switching and setting the VT into raw mode, which disables most fbcon events. Raw kms test programs though don't do that

[PATCH 34/35] drm/doc: updates for new framebuffer lifetime rules

Now that framebuffer are reference-counted for all use-sites, update the documentation accordingly to stress the new rules for initialization and teardown. Also add a short paragraph about the implications for drivers of the new locking rules. Signed-off-by: Daniel Vetter ---

[PATCH 33/35] drm: don't hold crtc mutexes for connector ->detect callbacks

The coup de grace of the entire journey. No more dropped frames every 10s on my testbox! I've tried to audit all ->detect and ->get_modes callbacks, but things became a bit fuzzy after trying to piece together the umpteenth implemenation. Afaict most drivers just have bog-standard output register

[PATCH 32/35] drm: only grab the crtc lock for pageflips

The pagelip ioctl itself is rather simply, so the hard work for this patch is auditing all the drivers: - exynos: Pageflip is protect with dev->struct_mutex and ... synchronous. But nothing fancy going on, besides a check whether the crtc is enabled, which should probably be somewhere in the

[PATCH 31/35] drm: optimize drm_framebuffer_remove

Now that all framebuffer usage is properly refcounted, we are no longer required to hold the modeset locks while dropping the last reference. Hence implemented a fastpath which avoids the potential stalls associated with grabbing mode_config.lock for the case where there's no other reference

[PATCH 30/35] drm/vmwgfx: add proper framebuffer refcounting

Afact vmwgfx already has all the right refcounting implemented on the backing storage, and we only need to ensure that the drm fb doesn't disappear untimely. So holding onto the fb reference from _lookup until vmw_kms_present has completed should be enough. Signed-off-by: Daniel Vetter ---

[PATCH 29/35] drm/i915: dump refcount into framebuffer debugfs file

Useful for checking whether the new refcounting works as advertised. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c

[PATCH 28/35] drm: refcounting for crtc framebuffers

With the prep patch to encapsulate ->set_crtc calls, this is now rather easy. Hooray for inconsistent semantics between ->set_crtc and ->page_flip, where the driver callback is supposed to update the fb pointer, and ->update_plane, where the drm core does the same. Also, since the drm core

[PATCH 27/35] drm: refcounting for sprite framebuffers

Now plane->fb holds a reference onto it's framebuffer. Nothing too fancy going on here: - Extract __drm_framebuffer_unreference to be called when we know we're not dropping the last reference, e.g. useful in the fb cleanup code. - Reduce the locked sections in the set_plane ioctl to only

[PATCH 26/35] drm: fb refcounting for dirtyfb_ioctl

We only need to ensure that the fb stays around for long enough. While at it, only grab the modeset locks when we need them (since most drivers don't implement the dirty callback, this should help jitter and stalls when using the generic modeset driver). Signed-off-by: Daniel Vetter ---

[PATCH 25/35] drm: don't take modeset locks in getfb ioctl

We only need to push the fb unreference a bit down. While at it, properly pass the return value from ->create_handle back to userspace. Most drivers either return -ENODEV if they don't have a concept of buffer objects (ast, cirrus, ...) or just install a handle for the underlying gem object

[PATCH 24/35] drm: push modeset_lock_all into ->fb_create driver callbacks

And drop it where it's not needed. Most driver just lookup the gem object, allocate an fb struct, fill in all the useful fields and then register it with drm_framebuffer_init. All of these operations are already separately locked, and since we only put the fb into the fpriv->fbs list _after_

[PATCH 23/35] drm: nest modeset locks within fpriv->fbs_lock

Atm we still need to unconditionally take the modeset locks in the rmfb paths. But eventually we only want to take them if there are other users around as a slow-path. This way sane userspace avoids blocking on edid reads and other stuff in rmfb if it ensures that the fb isn't used anywhere by a

[PATCH 22/35] drm: reference framebuffers which are on the idr

Since otherwise looking and reference-counting around drm_framebuffer_lookup will be an unmanageable mess. With this change, an object can either be found in the idr and will stay around once we incremented the reference counter. Or it will be gone for good and can't be looked up using its id any

[PATCH 21/35] drm: revamp framebuffer cleanup interfaces

We have two classes of framebuffer - Created by the driver (atm only for fbdev), and the driver holds onto the last reference count until destruction. - Created by userspace and associated with a given fd. These framebuffers will be reaped when their assoiciated fb is closed. Now these two

[PATCH 20/35] drm: create drm_framebuffer_lookup

And replace all fb lookups with it. Also add a WARN to drm_mode_object_find since that is now no longer the blessed interface to look up an fb. And add kerneldoc to both functions. This only updates all callsites, but immediately drops the acquired refence again. Hence all callers still rely on

[PATCH 19/35] drm: revamp locking around fb creation/destruction

Well, at least step 1. The goal here is that framebuffer objects can survive outside of the mode_config lock, with just a reference held as protection. The first step to get there is to introduce a special fb_lock which protects fb lookup, creation and destruction, to make them appear atomic.

[PATCH 18/35] drm: only take the crtc lock for ->cursor_move

->cursor_move uses mostly the same facilities in drivers as ->cursor_set, so pretty much nothing to fix up: - ast/gma500/i915: They all use per-crtc registers to update the cursor position. ast again touches the global cursor cache, but that's ok since there's only one crtc. - nouveau: nv50+

[PATCH 17/35] drm: only take the crtc lock for ->cursor_set

First convert ->cursor_set to only take the crtc lock, since that seems to be the function with the least amount of state - the core ioctl function doesn't check anything which can change at runtime, so we don't have any object lifetime issues to contend. The only thing which is important is that

[PATCH 16/35] drm: add per-crtc locks

*drumroll* The basic idea is to protect per-crtc state which can change without touching the output configuration with separate mutexes, i.e. all the input side state to a crtc like framebuffers, cursor settings or plane configuration. Holding such a crtc lock gives a read-lock on all the other

[PATCH 15/35] drm/vmgfx: use drm_modeset_lock_all

Ok, this one here is a bit more complicated, but for an RFC I've figured I can be a bit sloppy. So just convert ever mutex_lock call, including the interruptible one. Since other places (e.g. in the execbuf ioctl) take the mode_config.mutex without bothering with interruptible handling, I've

[PATCH 14/35] drm/shmobile: use drm_modeset_lock_all

Only a resume method to account for. v2: Fixup compilation. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/shmobile/shmob_drm_drv.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c b/drivers/gpu/drm/shmobile/shmob_drm_drv.c

[PATCH 13/35] drm/ast: use drm_modeset_lock_all

Just a call to drm_helper_resume_force_mode, obviously wants full locking for that. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/ast/ast_drv.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index

[PATCH 12/35] drm/gma500: use drm_modeset_lock_all

Only two places: - suspend/resume - Some really strange mode validation tool with too much funny-lucking hand-rolled conversion code. - The recently-added lastclose fbdev restore code. Better safe than sorry, so convert both places to keep the locking semantics as much as possible.

[PATCH 11/35] drm/i915: use drm_modeset_lock_all

Two exceptions: - debugfs files only read information which is not related to crtc, so can stay on the modeset_config lock. - Same holds for the edp vdd work in intel_dp.c. Add a corresponding WARN_ON and a comment next to the intel_dp struct fields for documentation. Signed-off-by: Daniel

[PATCH 10/35] drm: add drm_modeset_lock|unlock_all

This is the first step towards introducing the new modeset locking scheme. The plan is to put helper functions into place at all the right places step-by-step, so that the final patch to switch on the new locking scheme doesn't need to touch every single driver. This helper here will serve as the

[PATCH 09/35] drm: encapsulate crtc->set_config calls

With refcounting we need to adjust framebuffer refcounts at each callsite - much easier to do if they all call the same little helper function. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 19 +-- drivers/gpu/drm/drm_fb_helper.c|6

[PATCH 08/35] drm/: Unified handling of unimplemented fb->create_handle

Some drivers don't have real ->create_handle callbacks. - cirrus/ast/mga200: Returns either 0 or -EINVAL. - udl: Didn't even bother with a callback, leading to a nice userspace-triggerable OOPS. - vmwgfx: This driver bothered with an implementation to return 0 as the handle (which is the

[PATCH 07/35] drm/nouveau: try to protect nbo->pin_refcount

... by moving the bo_pin/bo_unpin manipulation of the pin_refcount under the protection of the ttm reservation lock. pin/unpin seems to get called from all over the place, so atm this is completely racy. After this patch there are only a few places in cleanup functions left which access

[PATCH 06/35] drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex

With per-crtc locks modeset operations can run in parallel, and the cursor code uses the device-global evo master channel for hw frobbing. But the pageflip code can also sync with the master under some circumstances. Hence just wrap things up in a mutex to ensure that pushbuf access doesn't

[PATCH 05/35] drm/gma500: move fbcon restore to lastclose

Doing this within the fb->destroy callback leads to a locking nightmare. And all other drm drivers that restore the fbcon do it in lastclose, too. With this adjustments all fb->destroy callbacks optionally drop references to any gem objects used as backing storage, call drm_framebuffer_cleanup

[PATCH 04/35] drm/vmwgfx: reorder framebuffer init sequence

vmwgfx has an oddity, when failing to reference the surface it'll return 0, since that's what the successfull drm_framebuffer_init will leave behind in ret. Fix this up by returning -EINVAL. Split out from all the other driver updates due to the above tiny semantic change. Shouldn't matter though

[PATCH 03/35] drm/: reorder framebuffer init sequence

With more fine-grained locking we can no longer rely on the big mode_config lock to prevent concurrent access to mode resources like framebuffers. Instead a framebuffer becomes accessible to other threads as soon as it is added to the relevant lookup structures. Hence it needs to be fully set up

[PATCH 02/35] drm/doc: integrate drm_crtc.c kerneldoc

And do a quick pass to adjust them to the last few (years?) of changes ... This time actually compile-tested ;-) Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl |4 ++ drivers/gpu/drm/drm_crtc.c | 92 +++- 2 files changed, 48

[PATCH 01/35] drm: review locking rules in drm_crtc.c

- config_cleanup was confused: It claimed that callers need to hold the modeset lock, but the connector|encoder_cleanup helpers grabbed that themselves (note that crtc_cleanup did _not_ grab the modeset lock). Which resulted in all drivers _not_ hodling the lock. Since this is for

[PATCH 00/36] kms locking rework

Hi all, Concurrent EDID reads and pageflips ftw! Changes since the rfc: - radeon/ttm/exynos prep patches/fixes merged. - arm driver patches at least compile-tested. - error handling fixed in a few cases, all spotted by Richard Wilbur, - radeon/nouveau tested on one card each, didn't blow up

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote: > I'm assuming you didn't also update your userspace gfx stack? By that you mean x.org etc, right? Or GPU microcode too? In any case, I haven't touched any of those deliberately, AFAICR at least. > Does disabling the new DMA ring for

[RFC 0/4] TI LCDC DRM driver

On Thu, Jan 10, 2013 at 6:05 PM, Laurent Pinchart wrote: > On Thursday 10 January 2013 10:16:10 Dave Airlie wrote: >> On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark wrote: >> > Updated version of DRM driver for TI LCD Controller. Since the initial >> > version of the patch, which only supported

[pull] drm-intel-next for 3.9

Hi Dave, We're already at -rc3, so imo time to annoy you with a -next pull request. Highlights: - seqno wrap fixes and debug infrastructure from Mika Kuoppala and Chris Wilson - some leftover kill-agp on gen6+ patches from Ben - hotplug improvements from Damien - clear fb when allocated from

[PATCH] drm/exynos: added validation of edid for vidi connection

If edid of vidi from user is invalid, size calculated from a number of cea extensions can be wrong. So, validation should be checked. Signed-off-by: Seung-Woo Kim Signed-off-by: Kyungmin.park --- drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 +++--- 1 files changed, 3 insertions(+), 3

[PATCH 1/1] drm: Fix comment about drm_exit which has been replaced by drm_platform_exit in 2.6.39

Hello Dave, On 10/01/13 02:57, Dave Airlie wrote: >> /** >> - * Called via drm_exit() at module unload time or when pci device is >> + * Called via drm_platform_exit() at module unload time or when pci device >> is >>* unplugged. > > Not really correct, its called from drm_pci_exit,

[pull] drm-intel-fixes

Hi Dave, Pretty much all just major fixes: - 2 pieces of duct-tape for the ilk bug. - Sprite regression fixes from Chris. - OOPS fix for a div-by-zero from Chris, regression due to the modeset rework in 3.7, now brought to light by a benign change in 3.8. - Fix interrupted bo pinning, used to

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/2a897145/attachment.html>

[pull] radeon drm-fixes-3.8

From: Alex Deucher Hi Dave, Fixes for UMS mode which has been broken for a while plus an rn50 fix and a dma fix. The following changes since commit 82ba789f48de669fd0bbc84c326f07571d078572: Merge branch 'drm-intel-fixes' of

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

2013/1/10 Laurent Pinchart : > Hi Vikas, > > Thank you for the patch. > > On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote: >> On 3 January 2013 16:29, Tomasz Figa wrote: >> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote: >> >> From: Vikas Sajjan >> >> >> >> Signed-off-by:

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Thu, Jan 10, 2013 at 3:32 PM, Borislav Petkov wrote: > On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote: >> I'm assuming you didn't also update your userspace gfx stack? > > By that you mean x.org etc, right? Or GPU microcode too? In any case, I > haven't touched any of those

[PATCH v4] drm/exynos: let drm handle edid allocations

Applied. Thanks, Inki Dae 2013/1/4 Rahul Sharma : > There's no need to allocate edid twice and do a memcpy when drm helpers > exist to do just that. This patch cleans that interaction up, and > doesn't keep the edid hanging around in the connector. > > v4: > - removed error check for

[Bug 59194] [r300g] sauerbraten corrupted with MSAA

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130110/0b0008cf/attachment.html>

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

On Thu, 10 Jan 2013, Inki Dae wrote: > 2013/1/10 Laurent Pinchart : >> Hi Vikas, >> >> Thank you for the patch. >> >> On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote: >>> On 3 January 2013 16:29, Tomasz Figa wrote: >>> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote: >>> >>

[PATCH libdrm 0/4] Manpages for libdrm

On Thu, 10 Jan 2013 22:00:20 +0100 David Herrmann wrote: > Hi Jesse > > On Thu, Jan 10, 2013 at 1:22 AM, Jesse Barnes > wrote: > > On Fri, 28 Sep 2012 23:44:18 +0200 > > David Herrmann wrote: > > > >> Hi > >> > >> This is revision 2 of the manpages for libdrm. I converted everything to > >>

[Bug 59194] New: [r300g] sauerbraten corrupted with MSAA

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/3452a451/attachment.html>

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Thu, Jan 10, 2013 at 4:38 AM, Borislav Petkov wrote: > [ deliberately breaking the thread because it got too long] > > On Sat, Dec 22, 2012 at 09:35:47PM +0100, Borislav Petkov wrote: >> Hi Alex, >> >> got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere >> down

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

Hi Laurent, On 10 January 2013 05:05, Laurent Pinchart wrote: > Hi Vikas, > > Thank you for the patch. > > On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote: >> On 3 January 2013 16:29, Tomasz Figa wrote: >> > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote: >> >> From: Vikas

[PATCH 1/1] drm: Fix comment about drm_exit which has been replaced by drm_platform_exit in 2.6.39

On Tue, Jan 8, 2013 at 12:10 AM, Philippe De Swert wrote: > Trivial comment fix. Since drm_exit() was removed in 2.6.39 (commit 8410ea3b > ). As such the comment > is incorrect. drm_put_dev() is now called from drm_platform_exit() or when > the pci device is "unplugged". > > Signed-off-by:

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[ deliberately breaking the thread because it got too long] On Sat, Dec 22, 2012 at 09:35:47PM +0100, Borislav Petkov wrote: > Hi Alex, > > got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere > down radeon_fence_wait_seq, judging by the error messages. > > And this doesn't

BUG: sleeping function called from invalid context at mm/slab.c:3179

Hi, not sure this is addressed by airlied's last pull request (will test when I have the chance to reboot), but here it goes: [ 7382.923361] Restarting tasks ... done. [ 7382.943648] BUG: sleeping function called from invalid context at mm/slab.c:3179 [ 7382.951048] in_atomic(): 1,

[RFC 0/4] TI LCDC DRM driver

On Wed, Jan 9, 2013 at 2:11 PM, Rob Clark wrote: > Updated version of DRM driver for TI LCD Controller. Since the initial > version of the patch, which only supported TFP410 DVI output, I've added > an output driver for LCD panels (for example, LCD3 or LCD7 cape for the > beagle-bone), and

[PATCH 2/2] radeon: add support for forcing off lvds when mux switched away

On Thu, Jan 10, 2013 at 12:16 AM, Alex Deucher wrote: > On Mon, Jan 7, 2013 at 11:53 PM, Dave Airlie wrote: >> From: Dave Airlie >> >> otherwise userspace can get very confused > > > Thinking about this more, we probably want to check whether we have a > muxed to mux-less system otherwise we'll

[PATCHv16 0/7] of: add display helper

Hi Steffen, On Thu, Jan 10, 2013 at 1:45 AM, Steffen Trumtrar wrote: > > On Tue, Dec 18, 2012 at 06:04:09PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > Finally, right in time before the end of the world on friday, v16 of the > > display helpers. > > > > So, any more criticism on the series?

[PATCHv16 0/7] of: add display helper

Hi Steffen, On Thu, Jan 10, 2013 at 01:45:41, Steffen Trumtrar wrote: > I think the series was tested at least with > - imx6q: sabrelite, sabresd > - imx53: tqma53/mba53 > - omap: DA850 EVM, AM335x EVM, EVM-SK To clarify, This series was tested with DT boot (making use of the

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130110/8e422d7f/attachment-0001.html>

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

Hi Vikas, Thank you for the patch. On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote: > On 3 January 2013 16:29, Tomasz Figa wrote: > > On Wednesday 02 of January 2013 18:47:22 Vikas C Sajjan wrote: > >> From: Vikas Sajjan > >> > >> Signed-off-by: Vikas Sajjan > >> --- > >> > >>

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

[ deliberately breaking the thread because it got too long] On Sat, Dec 22, 2012 at 09:35:47PM +0100, Borislav Petkov wrote: Hi Alex, got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere down radeon_fence_wait_seq, judging by the error messages. And this doesn't happen

[PATCH] drm/exynos: added validation of edid for vidi connection

If edid of vidi from user is invalid, size calculated from a number of cea extensions can be wrong. So, validation should be checked. Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Kyungmin.park kyungmin.p...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_vidi.c |6

Re: [PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

On Thu, 10 Jan 2013, Inki Dae inki@samsung.com wrote: 2013/1/10 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Vikas, Thank you for the patch. On Friday 04 January 2013 10:24:04 Vikas Sajjan wrote: On 3 January 2013 16:29, Tomasz Figa t.f...@samsung.com wrote: On Wednesday 02

[Bug 59194] New: [r300g] sauerbraten corrupted with MSAA

https://bugs.freedesktop.org/show_bug.cgi?id=59194 Priority: medium Bug ID: 59194 Assignee: dri-devel@lists.freedesktop.org Summary: [r300g] sauerbraten corrupted with MSAA Severity: normal Classification: Unclassified OS:

[Bug 59194] [r300g] sauerbraten corrupted with MSAA

https://bugs.freedesktop.org/show_bug.cgi?id=59194 Marek Olšák mar...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Thu, Jan 10, 2013 at 4:38 AM, Borislav Petkov b...@alien8.de wrote: [ deliberately breaking the thread because it got too long] On Sat, Dec 22, 2012 at 09:35:47PM +0100, Borislav Petkov wrote: Hi Alex, got the sickest bug on 3.8-rc1, see below. The GPU locks up somewhere down

[pull] drm-intel-fixes

Hi Dave, Pretty much all just major fixes: - 2 pieces of duct-tape for the ilk bug. - Sprite regression fixes from Chris. - OOPS fix for a div-by-zero from Chris, regression due to the modeset rework in 3.7, now brought to light by a benign change in 3.8. - Fix interrupted bo pinning, used to

[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics

https://bugs.freedesktop.org/show_bug.cgi?id=58354 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #72013|0 |1 is obsolete|

Re: [PATCH 1/1] drm: Fix comment about drm_exit which has been replaced by drm_platform_exit in 2.6.39

Hello Dave, On 10/01/13 02:57, Dave Airlie wrote: /** - * Called via drm_exit() at module unload time or when pci device is + * Called via drm_platform_exit() at module unload time or when pci device is * unplugged. Not really correct, its called from drm_pci_exit, drm_usb_exit and

[pull] drm-intel-next for 3.9

Hi Dave, We're already at -rc3, so imo time to annoy you with a -next pull request. Highlights: - seqno wrap fixes and debug infrastructure from Mika Kuoppala and Chris Wilson - some leftover kill-agp on gen6+ patches from Ben - hotplug improvements from Damien - clear fb when allocated from

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote: I'm assuming you didn't also update your userspace gfx stack? By that you mean x.org etc, right? Or GPU microcode too? In any case, I haven't touched any of those deliberately, AFAICR at least. Does disabling the new DMA ring for

Re: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Thu, Jan 10, 2013 at 3:32 PM, Borislav Petkov b...@alien8.de wrote: On Thu, Jan 10, 2013 at 11:21:21AM -0500, Alex Deucher wrote: I'm assuming you didn't also update your userspace gfx stack? By that you mean x.org etc, right? Or GPU microcode too? In any case, I haven't touched any of

[PATCH 00/36] kms locking rework

Hi all, Concurrent EDID reads and pageflips ftw! Changes since the rfc: - radeon/ttm/exynos prep patches/fixes merged. - arm driver patches at least compile-tested. - error handling fixed in a few cases, all spotted by Richard Wilbur, - radeon/nouveau tested on one card each, didn't blow up

[PATCH 01/35] drm: review locking rules in drm_crtc.c

- config_cleanup was confused: It claimed that callers need to hold the modeset lock, but the connector|encoder_cleanup helpers grabbed that themselves (note that crtc_cleanup did _not_ grab the modeset lock). Which resulted in all drivers _not_ hodling the lock. Since this is for

[PATCH 02/35] drm/doc: integrate drm_crtc.c kerneldoc

And do a quick pass to adjust them to the last few (years?) of changes ... This time actually compile-tested ;-) Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- Documentation/DocBook/drm.tmpl |4 ++ drivers/gpu/drm/drm_crtc.c | 92 +++- 2

[PATCH 03/35] drm/drivers: reorder framebuffer init sequence

With more fine-grained locking we can no longer rely on the big mode_config lock to prevent concurrent access to mode resources like framebuffers. Instead a framebuffer becomes accessible to other threads as soon as it is added to the relevant lookup structures. Hence it needs to be fully set up

[PATCH 04/35] drm/vmwgfx: reorder framebuffer init sequence

vmwgfx has an oddity, when failing to reference the surface it'll return 0, since that's what the successfull drm_framebuffer_init will leave behind in ret. Fix this up by returning -EINVAL. Split out from all the other driver updates due to the above tiny semantic change. Shouldn't matter though

[PATCH 05/35] drm/gma500: move fbcon restore to lastclose

Doing this within the fb-destroy callback leads to a locking nightmare. And all other drm drivers that restore the fbcon do it in lastclose, too. With this adjustments all fb-destroy callbacks optionally drop references to any gem objects used as backing storage, call drm_framebuffer_cleanup and

[PATCH 06/35] drm/nouveau: protect evo_wait/evo_kick sections with a channel mutex

With per-crtc locks modeset operations can run in parallel, and the cursor code uses the device-global evo master channel for hw frobbing. But the pageflip code can also sync with the master under some circumstances. Hence just wrap things up in a mutex to ensure that pushbuf access doesn't

[PATCH 07/35] drm/nouveau: try to protect nbo-pin_refcount

... by moving the bo_pin/bo_unpin manipulation of the pin_refcount under the protection of the ttm reservation lock. pin/unpin seems to get called from all over the place, so atm this is completely racy. After this patch there are only a few places in cleanup functions left which access

[PATCH 08/35] drm/drivers: Unified handling of unimplemented fb-create_handle

Some drivers don't have real -create_handle callbacks. - cirrus/ast/mga200: Returns either 0 or -EINVAL. - udl: Didn't even bother with a callback, leading to a nice userspace-triggerable OOPS. - vmwgfx: This driver bothered with an implementation to return 0 as the handle (which is the

[PATCH 09/35] drm: encapsulate crtc-set_config calls

With refcounting we need to adjust framebuffer refcounts at each callsite - much easier to do if they all call the same little helper function. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/drm_crtc.c | 19 +--

[PATCH 10/35] drm: add drm_modeset_lock|unlock_all

This is the first step towards introducing the new modeset locking scheme. The plan is to put helper functions into place at all the right places step-by-step, so that the final patch to switch on the new locking scheme doesn't need to touch every single driver. This helper here will serve as the

[PATCH 11/35] drm/i915: use drm_modeset_lock_all

Two exceptions: - debugfs files only read information which is not related to crtc, so can stay on the modeset_config lock. - Same holds for the edp vdd work in intel_dp.c. Add a corresponding WARN_ON and a comment next to the intel_dp struct fields for documentation. Signed-off-by: Daniel

[PATCH 12/35] drm/gma500: use drm_modeset_lock_all

Only two places: - suspend/resume - Some really strange mode validation tool with too much funny-lucking hand-rolled conversion code. - The recently-added lastclose fbdev restore code. Better safe than sorry, so convert both places to keep the locking semantics as much as possible.

[PATCH 13/35] drm/ast: use drm_modeset_lock_all

Just a call to drm_helper_resume_force_mode, obviously wants full locking for that. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/ast/ast_drv.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_drv.c

[PATCH 14/35] drm/shmobile: use drm_modeset_lock_all

Only a resume method to account for. v2: Fixup compilation. Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/shmobile/shmob_drm_drv.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c

[PATCH 16/35] drm: add per-crtc locks

*drumroll* The basic idea is to protect per-crtc state which can change without touching the output configuration with separate mutexes, i.e. all the input side state to a crtc like framebuffers, cursor settings or plane configuration. Holding such a crtc lock gives a read-lock on all the other

[PATCH 15/35] drm/vmgfx: use drm_modeset_lock_all

Ok, this one here is a bit more complicated, but for an RFC I've figured I can be a bit sloppy. So just convert ever mutex_lock call, including the interruptible one. Since other places (e.g. in the execbuf ioctl) take the mode_config.mutex without bothering with interruptible handling, I've

[PATCH 17/35] drm: only take the crtc lock for -cursor_set

First convert -cursor_set to only take the crtc lock, since that seems to be the function with the least amount of state - the core ioctl function doesn't check anything which can change at runtime, so we don't have any object lifetime issues to contend. The only thing which is important is that

  1   2   >