[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

https://bugzilla.kernel.org/show_bug.cgi?id=76761 --- Comment #10 from Alex Deucher --- 3.15 is we can make it in in time, otherwise 3.16. I've cc'ed stable so it will show up in older kernels as well too once it's applied upstream. -- You are receiving this mail because: You are watching the

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

https://bugzilla.kernel.org/show_bug.cgi?id=76761 --- Comment #9 from Vitaliy Filippov --- Yes, everything works with it, thanks! So, in which kernel version are you planning to include this fix? -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 79223] extra vsync when reading back pixels in xbmc

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

[Bug 79223] extra vsync when reading back pixels in xbmc

repeats. Ideas? -- 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/20140530/f4cd19c4/attachment.html>

CIK hangs with kernel 3.15, bisected

On 30.05.2014 13:46, Grigori Goronzy wrote: > On 30.05.2014 13:30, Marek Ol??k wrote: >> Grigori, >> >> you can git-checkout the commit before and after the memory management >> changes, compile both and test them. >> > > I was trying to revert the changes, but it looks like too much changed > in

Reminder: drm/crtc-helper patch

Wierd I can't see this in my dri-devel feed, Daniel any quick opinions? Dave. - Original Message - > From: "Sergei Antonov" > To: "Dave Airlie" > Cc: "Daniel Vetter" > Sent: Friday, 30 May, 2014 8:12:54 PM > Subject: Reminder: drm/crtc-helper patch > > Dave, > did you notice this

CIK hangs with kernel 3.15, bisected

Well the good news is that when I use the CP DMA instead of the SDMA everything seems to work fine. Unfortunately using the CP DMA has a completely different timing (because of the additional sync needed) and so I'm not sure if it's really fixed or just masked. Christian. Am 29.05.2014

[Bug 79417] r600-cayman: GPU lockup in Planetary Annihilation (PTE 66705) on HD6950

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/20140530/828251b3/attachment.html>

[PATCH] drm/radeon: Resume fbcon last

So a few people complained that commit 177cf92de4aa97ec1435987e91696ed8b5023130 Author: Daniel Vetter Date: Tue Apr 1 22:14:59 2014 +0200 drm/crtc-helpers: fix dpms on logic which was merged into 3.15-rc1, broke resume on radeons. Strangely git bisect lead everyone to commit

[PATCH] drm/radeon: Resume fbcon last

So a few people complained that commit 177cf92de4aa97ec1435987e91696ed8b5023130 Author: Daniel Vetter Date: Tue Apr 1 22:14:59 2014 +0200 drm/crtc-helpers: fix dpms on logic which was merged into 3.15-rc1, broke resume on radeons. Strangely git bisect lead everyone to commit

[PATCH] drm/gk20a/fb: use dma_alloc_coherent() for VRAM

GK20A's RAM driver was using CMA functions in order to allocate VRAM. This is wrong because these functions are not exported, which causes compilation to fail when CMA is enabled and Nouveau is built as a module. On top of that the driver was leaking (or rather bleeding) memory.

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

https://bugzilla.kernel.org/show_bug.cgi?id=76761 Alex Deucher changed: What|Removed |Added Attachment #137731|0 |1 is obsolete|

[Bug 76761] radeon DPM breaks suspend to disk and resume from RAM in 3.14

https://bugzilla.kernel.org/show_bug.cgi?id=76761 --- Comment #7 from Alex Deucher --- Created attachment 137731 --> https://bugzilla.kernel.org/attachment.cgi?id=137731=edit possible fix Does this patch help? -- You are receiving this mail because: You are watching the assignee of the bug.

[pull] radeon drm-fixes-3.15

Hi Dave, this is the next pull request for stashed up radeon fixes for 3.15. This is finally calming down with only four patches in this pull request. The following changes since commit efb27e73e12633a24dfdc67b8a6a58c4b427f3e4: Merge tag 'drm-intel-fixes-2014-05-27' of

CIK hangs with kernel 3.15, bisected

That's right. Also, you probably want to enable automatic addition of the git-sha1 to the kernel version in menuconfig, there is an option for it, so that you can have several kernels with the same version but different sha1 installed. Marek On Fri, May 30, 2014 at 1:46 PM, Grigori Goronzy

[Bug 79223] extra vsync when reading back pixels in xbmc

the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140530/a2964062/attachment.html>

CIK hangs with kernel 3.15, bisected

On 30.05.2014 13:30, Marek Ol??k wrote: > Grigori, > > you can git-checkout the commit before and after the memory management > changes, compile both and test them. > I was trying to revert the changes, but it looks like too much changed in the meantime. The suitable commits to check out should

[Bug 79223] extra vsync when reading back pixels in xbmc

cases) by disabling SwapBuffersWait. Have you tried that, just for testing? -- 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/20140

CIK hangs with kernel 3.15, bisected

Grigori, you can git-checkout the commit before and after the memory management changes, compile both and test them. Marek On Fri, May 30, 2014 at 2:30 AM, Grigori Goronzy wrote: > On 13.05.2014 22:27, Marek Ol??k wrote: >> >> I applied these two patches Christian sent to dri-devel: >> >>

[PATCH 7/7] drm: Fix up the atomic legacy paths so they work

From: Sean Paul BUG=chromium:336809 TEST=Tested on snow & peppy Change-Id: Icd864ac52da9c973202f3ac4629824ef5eec2ac9 Signed-off-by: Sean Paul Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_atomic.c | 4 drivers/gpu/drm/drm_crtc.c | 11 ---

[PATCH 6/7] drm/msm: add atomic support

Signed-off-by: Rob Clark --- drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 57 ++-- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 6 ++ drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 1 + drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 5 --

[PATCH 5/7] drm: convert crtc to properties/state

Break the mutable state of a crtc out into a separate structure and use atomic properties mechanism to set crtc attributes. This makes it easier to have some helpers for crtc->set_property() and for checking for invalid params. The idea is that individual drivers can wrap the state struct in

[PATCH 4/7] drm: convert plane to properties/state

Break the mutable state of a plane out into a separate structure and use atomic properties mechanism to set plane attributes. This makes it easier to have some helpers for plane->set_property() and for checking for invalid params. The idea is that individual drivers can wrap the state struct in

[PATCH 3/7] drm: Refactor object property check code

From: Ville Syrj?l? Refactor the code to check whether an object has a specific property to a new function. v1: original v2: rebase on atomic -- Rob Clark v3: EINVAL->ENOENT Signed-off-by: Ville Syrj?l? Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c |

[PATCH 2/7] drm: split propvals out and blob property support

Split property values out into a different struct, so we can later move property values into state structs. This will allow the property values to stay in sync w/ the state updates which are either discarded or atomically committed. And since we are touching all the same code, add support for

[PATCH 1/7] drm: add atomic fxns

The 'atomic' mechanism allows for multiple properties to be updated, checked, and commited atomically. This will be the basis of atomic- modeset and nuclear-pageflip. The basic flow is: state = dev->atomic_begin(); for (... one or more ...) obj->set_property(obj, state, prop,

[PATCH 0/7] prepare for atomic/nuclear modeset/pageflip (vN+1)

Based on top of the 'prepare for preparing for atomic (v2)' series. Since previous version posted, reshuffled a few things to pull some changes ahead of atomic (in 'prepare for preparing..' patchset), and few little fixes. This patchset may be a bit more controversial for merging 3.16, but I

[Bug 79223] extra vsync when reading back pixels in xbmc

vel/attachments/20140530/f7ef49b7/attachment.html>

[Bug 79223] extra vsync when reading back pixels in xbmc

lications, shouldn't glXGetSwapIntervalMESA() return 1 when those settings are on? -- 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/20140530/851cd7d0/attachment-0001.html>

[PATCH 8/8] drm: add drm_fb_helper_restore_fbdev_mode_unlocked()

All drm_fb_helper_restore_fbdev_mode() call sites, save one, do the same locking. Simplify this into drm_fb_helper_restore_fbdev_mode_unlocked(). Signed-off-by: Rob Clark --- drivers/gpu/drm/armada/armada_fbdev.c | 4 +-- drivers/gpu/drm/drm_fb_cma_helper.c | 9 ++

[PATCH 7/8] drm: convert crtc and connection_mutex to ww_mutex (v3)

For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to

[PATCH 6/8] drm: Split connection_mutex out of mode_config.mutex (v3)

From: Daniel Vetter After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from

[PATCH 5/8] drm: spiff out FB refcnting traces

I find myself making this change locally whenever debugging FB reference counting. Which seems a bit silly. Signed-off-by: Rob Clark Reviewed-by: David Herrmann --- drivers/gpu/drm/drm_crtc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH 4/8] drm: add signed-range property type

Like range, but values are signed. Signed-off-by: Rob Clark Reviewed-by: David Herrmann --- drivers/gpu/drm/drm_crtc.c | 45 + include/drm/drm_crtc.h | 12 include/uapi/drm/drm_mode.h | 1 + 3 files changed, 46 insertions(+), 12

[PATCH 3/8] drm: add object property type

An object property is an id (idr) for a drm mode object. This will allow a property to be used set/get a framebuffer, CRTC, etc. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c | 61 +++-- include/drm/drm_crtc.h | 5

[PATCH 2/8] drm: add extended property types

If we continue to use bitmask for type, we will quickly run out of room to add new types. Split this up so existing part of bitmask range continues to function as before, but reserve a chunk of the remaining space for an integer type-id. Wrap this all up in some type-check helpers to keep the

[PATCH 1/8] drm: helpers to find mode objects

Add a few more useful helpers to find mode objects. Signed-off-by: Rob Clark --- drivers/gpu/drm/drm_crtc.c | 90 +++--- include/drm/drm_crtc.h | 33 + 2 files changed, 61 insertions(+), 62 deletions(-) diff --git

[PATCH 0/8] prepare for preparing for atomic (v2)

As suggested by Daniel, splitting out ww_mutex conversion and a few other bits out. Updated connection_mutex which fixes a few things, plus split up addition of extended property types from adding object property and pull in addition of _restore_fbdev_mode_unlocked() as it does not depend on

[PATCH] drm: move debugfs init after dev->load()

On Fri, May 30, 2014 at 12:46 PM, Daniel Vetter wrote: > On Fri, May 30, 2014 at 12:37 AM, Rob Clark wrote: >> Avoids ugly hacks in drivers debugfs code, if it depends on >> dev->dev_private having already been initialized. >> >> Signed-off-by: Rob Clark > > So what I had in mind: > - stop

[PATCH] drm: move debugfs init after dev->load()

On Fri, May 30, 2014 at 12:37 AM, Rob Clark wrote: > Avoids ugly hacks in drivers debugfs code, if it depends on > dev->dev_private having already been initialized. > > Signed-off-by: Rob Clark So what I had in mind: - stop using drm_platform_init, instead roll your own copy of

[PATCH] drm/radeon/dpm: resume fixes for some systems

Setting the power state prior to restoring the display hardware leads to blank screens on some systems. Drop the power state set from dpm resume. The power state will get set as part of the mode set sequence. Also add an explicit power state set after mode set resume to cover PX and headless

[Bug 77001] Radeon R9 270X GPU lockup and resume failure after all night inactivity [drm,radeonsi]

https://bugzilla.kernel.org/show_bug.cgi?id=77001 --- Comment #3 from Grzegorz Kowal --- This morning at 6:27am it happened again. The computer was idle during the whole night, even during the hang. When I touched the keyboard around 8am, the monitor turned on, but I saw dark flickering screen

[drm] INFO: possible recursive locking detected

5f76097311b67dfd76891b10988:bisect-linux/.vmlinuz-b739c9982801e5f76097311b67dfd76891b10988-20140530033701-10-ivb43 branch=linux-devel/devel-roam-i386-201405300201 BOOT_IMAGE=/kernel/i386-randconfig-r3-0530/b739c9982801e5f76097311b67dfd76891b10988/vmlinuz-3.15.0-rc5-00087-gb739c99 drbd.minor_count

[Intel-gfx] [PATCH 5/5] drm/i915: Allow vblank interrupts during modeset and eliminate some vblank races

On 29.05.2014 19:56, Daniel Vetter wrote: > On Thu, May 29, 2014 at 6:11 AM, Michel D?nzer wrote: >> >>> We could rename the off/on to pre/post_modeset if you like, but then >>> someone gets to audit all the other drivers. That someone isn't >>> going to be me. >> >> I appreciate your caution wrt

[PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.

On Thu, May 29, 2014 at 11:34:59PM +0900, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Konrad Rzeszutek Wilk wrote: > > > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote: > > > > Hello. > > > > > > > > I tried to test whether it is OK (from point of view of reentrant) to > > > >

[PATCH v2 13/18] ARM: dts: s6e3fa0: add DT bindings

Hi ALL, On 05/28/2014 03:44 PM, Andrzej Hajda wrote: > On 05/28/2014 06:50 AM, Inki Dae wrote: >> On 2014? 05? 28? 05:21, Thierry Reding wrote: >>> On Tue, May 27, 2014 at 11:24:49PM +0900, Inki Dae wrote: 2014-05-27 16:53 GMT+09:00 Thierry Reding : > On Tue, May 27, 2014 at 08:28:52AM

[PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.

On Thu, May 29, 2014 at 06:47:49AM +0900, Tetsuo Handa wrote: > Konrad Rzeszutek Wilk wrote: > > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote: > > > Hello. > > > > > > I tried to test whether it is OK (from point of view of reentrant) to use > > > mutex_lock() or

[PATCH] drm/exynos: remove unnecessary exynos_hdmi.h file

The exynos_hdmi.h has been used for the dedicated i2c drivers that were already removed. Thus, the unnecessary exynos_hdmi.h should be removed. Signed-off-by: Jingoo Han --- drivers/gpu/drm/exynos/exynos_hdmi.h | 23 --- 1 file changed, 23 deletions(-) delete mode 100644

[PATCH] drm/radeon: Resume fbcon last

On Fri, May 30, 2014 at 10:37 AM, Daniel Vetter wrote: > So a few people complained that > > commit 177cf92de4aa97ec1435987e91696ed8b5023130 > Author: Daniel Vetter > Date: Tue Apr 1 22:14:59 2014 +0200 > > drm/crtc-helpers: fix dpms on logic > > which was merged into 3.15-rc1, broke

[PATCH] drm/exynos: hdmi: remove the i2c drivers and use devtree - continued

On Friday, May 30, 2014 1:42 AM, Tomasz Figa wrote: > On 29.05.2014 18:36, Lee Jones wrote: > > There appears to have been a merge error on commit: > > > > 2b76813: drm/exynos: hdmi: remove the i2c drivers and use > > > > The original submission can be found at: > > > >

[Bug 79431] OpenGL OpenCL interop results in corrupted renderbuffer object image

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140530/55191219/attachment.html>

[PATCH 1/8] drm: add object property type

les in the number space and we need to be careful to introduce new types only in the upper range, but it has the advantage of not requiring special handling. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140530/55292113/attachment.sig>

[PATCH] drm/exynos: remove unnecessary exynos_hdmi.h file

> > The exynos_hdmi.h has been used for the dedicated i2c drivers > > that were already removed. Thus, the unnecessary exynos_hdmi.h > > should be removed. > > > > Signed-off-by: Jingoo Han > > --- > > drivers/gpu/drm/exynos/exynos_hdmi.h | 23 --- > > 1 file changed, 23

[PATCH] drm/exynos: remove unnecessary exynos_hdmi.h file

> The exynos_hdmi.h has been used for the dedicated i2c drivers > that were already removed. Thus, the unnecessary exynos_hdmi.h > should be removed. > > Signed-off-by: Jingoo Han > --- > drivers/gpu/drm/exynos/exynos_hdmi.h | 23 --- > 1 file changed, 23 deletions(-) >

[Bug 74751] resume from suspend broken with 3.15-rc1 and rc2 kernels

https://bugzilla.kernel.org/show_bug.cgi?id=74751 --- Comment #25 from Daniel Vetter --- Created attachment 137721 --> https://bugzilla.kernel.org/attachment.cgi?id=137721=edit resume fbcon later Hm, somehow forgotten to attach this yesterday. Please test this patch instead of any reverts.

[PATCH 1/8] drm: add object property type

On Fri, May 30, 2014 at 3:57 AM, Thierry Reding wrote: > On Wed, May 28, 2014 at 07:57:18PM -0400, Rob Clark wrote: > [...] >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > [...] >> +struct drm_property *drm_property_create_object(struct drm_device *dev, >> +

[PATCH] drm: move debugfs init after dev->load()

On Fri, May 30, 2014 at 6:49 AM, Daniel Vetter wrote: > On Fri, May 30, 2014 at 12:46 PM, Daniel Vetter wrote: >> On Fri, May 30, 2014 at 12:37 AM, Rob Clark wrote: >>> Avoids ugly hacks in drivers debugfs code, if it depends on >>> dev->dev_private having already been initialized. >>> >>>

CIK hangs with kernel 3.15, bisected

On 13.05.2014 22:27, Marek Ol??k wrote: > I applied these two patches Christian sent to dri-devel: > > drm/radeon: fix page directory update size estimation > drm/radeon: fix buffer placement under memory pressure v2 > > on top of torvalds's master branch. > With latest kernel master (a991639c) I

[PATCH 3/3] exynos: fix g2d_copy_with_scale

--- exynos/exynos_fimg2d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index a565910..fc281b6 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -451,7 +451,7 @@ int g2d_copy_with_scale(struct g2d_context

[PATCH 2/3] exynos: fix G2D_DOUBLE_TO_FIXED

--- exynos/fimg2d.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exynos/fimg2d.h b/exynos/fimg2d.h index 1aac378..bc45ab5 100644 --- a/exynos/fimg2d.h +++ b/exynos/fimg2d.h @@ -25,7 +25,7 @@ #define G2D_MAX_CMD_LIST_NR64 #define G2D_PLANE_MAX_NR 2 -#define

[PATCH 1/3] exynos: fix g2d_copy

--- exynos/exynos_fimg2d.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c index 0b14618..a565910 100644 --- a/exynos/exynos_fimg2d.c +++ b/exynos/exynos_fimg2d.c @@ -382,7 +382,7 @@ int g2d_copy(struct g2d_context *ctx, struct

[PATCH] drm: Split connection_mutex out of mode_config.mutex (v2)

After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from connector->encoder and encoder->crtc and other

[Bug 79431] New: OpenGL OpenCL interop results in corrupted renderbuffer object image

https://bugs.freedesktop.org/show_bug.cgi?id=79431 Priority: medium Bug ID: 79431 Assignee: dri-devel at lists.freedesktop.org Summary: OpenGL OpenCL interop results in corrupted renderbuffer object image Severity: normal

[PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.

Tetsuo Handa wrote: > Konrad Rzeszutek Wilk wrote: > > On Sat, May 24, 2014 at 11:22:09PM +0900, Tetsuo Handa wrote: > > > Hello. > > > > > > I tried to test whether it is OK (from point of view of reentrant) to use > > > mutex_lock() or mutex_lock_killable() inside shrinker functions when > > >