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
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.
cause:
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>
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>
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 t
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 [
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 18:52,
iving 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>
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 25f397a429df
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 25f397a429df
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.
dma_alloc_coherent
https://bugzilla.kernel.org/show_bug.cgi?id=76761
Alex Deucher changed:
What|Removed |Added
Attachment #137731|0 |1
is obsolete|
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&action=edit
possible fix
Does this patch help?
--
You are receiving this mail because:
You are watching the assignee of th
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
git://anongit.freedes
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 wrot
u are 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>
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 b
some 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/
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:
>>
>> drm/r
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 ---
include/drm/drm_crtc.h | 1 +
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 --
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 thei
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 t
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 | 25 ++---
1
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 mut
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, value);
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
thin
vel/attachments/20140530/f7ef49b7/attachment.html>
to applications, 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>
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 ++
drivers/gpu/d
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
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 connector->encoder and encoder->
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 b
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 de
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
include/uapi/drm/d
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 bac
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 a/drivers/gpu/drm/drm
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 atomi
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 using
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
drm_get_platform_
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 sys
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 on
mi_watchdog=panic prompt_ramdisk=0 console=ttyS0,115200
console=tty0 vga=normal root=/dev/ram0 rw
link=/kbuild-tests/run-queue/kvm/i386-randconfig-r3-0530/linux-devel:devel-roam-i386-201405300201:b739c9982801e5f76097311b67dfd76891b10988:bisect-linux/.vmlinuz-b739c9982801e5f76097311b67dfd76
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
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
> > > > use
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 +0
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 mutex_lock_killabl
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 d
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 resum
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:
> >
> > https://patchwork.kernel
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140530/55191219/attachment.html>
f wholes 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>
> > 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 de
> 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(-)
> de
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&action=edit
resume fbcon later
Hm, somehow forgotten to attach this yesterday. Please test this patch instead
of any rever
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,
>> +
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.
>>>
>>> Signe
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
58 matches
Mail list logo
