https://bugs.freedesktop.org/show_bug.cgi?id=66738
--- Comment #12 from lh ---
(In reply to comment #11)
> Are you running the same userspace stack with both kernel 3.9 and kernel
> 3.10/3.11? If so, it sounds like this is UVD related.
Yes, I have two kernels: arch official kernel 3.9.9 and ker
On Thu, Aug 8, 2013 at 1:52 PM, Guennadi Liakhovetski
wrote:
> Hi Bryan,
>
> On Wed, 7 Aug 2013, Bryan Wu wrote:
>
>> Hi Guennadi and LMML,
>>
>> I'm working on a camera controller driver for Tegra, which is using
>> soc_camera. But we also need to use Tegra specific host1x interface
>> like syncp
Hi,
thanks for the explanation.
Do you know if this is a hardware limitation, or if an updated version of the
driver will come some day?
Regards,
Sam
> Date: Wed, 7 Aug 2013 18:06:05 -0400
> Subject: Re: [3.11-rc4] [HD2400] - radeon.dpm
> From: alexdeuc...@gmail.com
> To: miaous...@hotmail.com
From: Mark Brown
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
broke the build for platforms which do not have AGP since it moved the
AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
unconditionally in drm_drv.c. This causes build failures for embedded
S
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/221c52ed/attachment-0001.html>
Hi Bryan,
On Wed, 7 Aug 2013, Bryan Wu wrote:
> Hi Guennadi and LMML,
>
> I'm working on a camera controller driver for Tegra, which is using
> soc_camera. But we also need to use Tegra specific host1x interface
> like syncpt APIs.
>
> Since host1x is quite Tegra specific framework which is in
..
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/2e45e4b0/attachment.html>
to low.
--
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/20130808/8484eb91/attachment.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/fbb0c89c/attachment.html>
We currently rely on gcc dead-code elimination so the drm_agp_* helpers
are not called if drm_core_has_AGP() is false. That's ugly as hell so
provide "static inline" dummies for the case that AGP is disabled.
Fixes a build-regression introduced by:
commit 28ec711cd427f8b61f73712a43b8100ba8ca933
Hi
On Thu, Aug 8, 2013 at 9:21 PM, Stephen Warren wrote:
> On 08/08/2013 12:13 PM, David Herrmann wrote:
>> Hi
>>
>> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren
>> wrote:
>>> In next-20130808, building tegra_defconfig for ARM yields:
>>>
>&g
x27;s probably not dpm
related.
--
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/20130808/6e7e9467/attachment.html>
On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and
ktop.org/archives/dri-devel/attachments/20130808/a9febd0b/attachment.html>
Hi
On Thu, Aug 8, 2013 at 12:01 PM, Vincent Stehl?
wrote:
> Hi,
>
> Linux next-20130808 link breaks for me with ARM config multi_v7defconfig.
>
> It seems this is due to the following commit:
>
> 28ec711 drm/agp: move AGP cleanup paths to drm_agpsupport.c
>
> .
Hi
On Thu, Aug 8, 2013 at 12:20 PM, Mark Brown wrote:
> From: Mark Brown
>
> Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
> broke the build for platforms which do not have AGP since it moved the
> AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
> uncon
Hi
On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
> In next-20130808, building tegra_defconfig for ARM yields:
>
>> drivers/built-in.o: In function `drm_lastclose':
>> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198:
>> undefine
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/4d7c5e11/attachment.html>
separately.
--
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/20130808/d6955347/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/ccd32288/attachment.html>
Hi
On Thu, Aug 8, 2013 at 7:10 PM, David Herrmann wrote:
> Currently, both ranges overlap. Fix the limits so both ranges are mutually
> exclusive. Also use the occasion to convert whitespaces to tabs.
>
> Signed-off-by: Kristian H?gsberg
> (fixed up tabs and adjust commit-msg accordingly)
> Sign
Currently, both ranges overlap. Fix the limits so both ranges are mutually
exclusive. Also use the occasion to convert whitespaces to tabs.
Signed-off-by: Kristian H?gsberg
(fixed up tabs and adjust commit-msg accordingly)
Signed-off-by: David Herrmann
---
drivers/gpu/drm/drm_stub.c | 12 ++
From: Fabio Estevam
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) causes the
following link error on ARM (imx_v6_v7_defconfig):
drivers/built-in.o: In function `drm_lastclose':
:(.text+0x588a0): undefined reference to `drm_agp_clear'
make: *** [vmlinux] Error 1
drm_agp_c
https://bugzilla.kernel.org/show_bug.cgi?id=60709
--- Comment #17 from Torsten Krah ---
Done with bisect - did take some time but got it:
d3418eacad403033e95e49dc14afa37c2112c134 is the first bad commit
commit d3418eacad403033e95e49dc14afa37c2112c134
Author: Rafał Miłecki
Date: Thu Apr 18 09:
On Thu, Aug 8, 2013 at 5:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and
On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and
On Thu, Aug 8, 2013 at 5:36 PM, Daniel Vetter wrote:
> On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
>> This patch adds the notion of a drm_bridge. A bridge is a chained
>> device which hangs off an encoder. The drm driver using the bridge
>> should provide the association between encoder and
/
Patches 2, 6-11, 19, 21, 22, 24, 25 are:
Reviewed-by: Eric Anholt
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/5d231387/attachment.pgp>
On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote:
> This patch adds the notion of a drm_bridge. A bridge is a chained
> device which hangs off an encoder. The drm driver using the bridge
> should provide the association between encoder and bridge. Once a
> bridge is associated with an encoder, it
Hi
On Wed, Aug 7, 2013 at 7:41 PM, Rob Clark wrote:
> Variant of drm_gem_create_mmap_offset() which doesn't make the
> assumption that virtual size and physical size (obj->size) are the same.
> This is needed in omapdrm to deal with tiled buffers. And lets us get
> rid of a duplicated and slight
On 08/06/2013 08:03 PM, Daniel Vetter wrote:
> On Tue, Aug 6, 2013 at 7:42 PM, Toralf F?rster
> wrote:
>> On 07/26/2013 07:58 PM, Daniel Vetter wrote:
>>> On Wed, Jul 24, 2013 at 05:51:41PM +0200, Toralf F?rster wrote:
Realized this today while booting a ThinkPad T420 with integrated intel
Sebastian Hesselbarth wrote on Tue
[2013-Aug-06 00:20:10 +0200]:
> This patch set picks up several patches sent during the past months
> related with NXP TDA998x HDMI transmitter driver. The patches have
> been tested on Marvell Dove (Armada DRM) on several HDMI modes with
> audio playing on S/PD
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, dpms, and optionally connecti
https://bugs.freedesktop.org/show_bug.cgi?id=67927
Priority: medium
Bug ID: 67927
Assignee: dri-devel@lists.freedesktop.org
Summary: R600_DEBUG=sb: Celestia show 2 earths, one wrongly
rendered
Severity: major
Classificati
https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #15 from Alex Deucher ---
(In reply to comment #13)
> Resume from suspend only works when I have the power plug attached. It
> doesn't matter, if I suspended on AC or not as long I have attached it on
> resume.
Does resume work with
We kzalloc this structure, and for real kms devices we should never
loose track of things really.
But ums/legacy drivers rely on the drm core to clean up a bit of cruft
between lastclose and firstopen (i.e. when X is being restarted), so
keep this around. But give it a clear drm_legacy_ prefix and
So almost two years ago I've tried to nuke the procfs code already
once before:
http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html
The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging
The idr is protected with our spinlock, if we don't hold that nothing
prevents the gem objects from disappearing from under us.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_info.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_inf
Again only used by a tests in libdrm and by dristat. Nowadays we have
much better tracing tools to get detailed insights into what a drm
driver is doing. And for a simple "does it work" kind of question that
these stats could answer we have plenty of dmesg debug log spew.
So I don't see any use fo
We not only have debugfs files to do pretty much the equivalent of
lsof, we also have an ioctl. Not that compared to lsof this dumps a
wee bit more information, but we can still get at that from debugfs
easily.
I've dug around in mesa, libdrm and ddx histories and the only users
seem to be drm/tes
They're only used by the agpgart support code in drm_agpgart.c,
not by any drivers.
I think long-term we should create a drm_internal.h include file with
all the various functions only used by the drm core and not exported
to drivers, and remove them from drmP.h. Oh, and someone should kill
that u
We might as well have a real ioctl function which checks for the
callbacks. This seems to be a remnant from back in the days when each
drm driver had their own complete ioctl table, with no shared core
drm table at all.
To make really sure no mis-guided user in a kms driver pops up again
explicitl
I've forgotten this and shuffling all the little pieces into the
respective patches is rather cumbersome ...
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 29 -
1 file changed, 29 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Document
The new arch_phys_wc_add/del functions do the right thing both with
and without MTRR support in the kernel. So we can drop these
additional checks.
David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since
it's now unused, which spurred me to do a bit a better audit of the
affected driver
Signed-off-by: Daniel Vetter
---
include/drm/drmP.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index f526a7a9..914055e 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -165,13 +165,7 @@ int drm_err(const char *func, const char *f
The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since
there's no code at all to check for this we can kill it. The other two
are completely unused.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/gma500/psb_drv.c | 2 +-
include/drm/drmP.h | 3 ---
2 files changed, 1 in
No driver ever sets that flag, so good riddance!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 161 +
include/drm/drmP.h | 1 -
2 files changed, 2 insertions(+), 160 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/driv
So I've stumbled over drm_fasync and wondered what it does. Digging
that up is quite a story.
First I've had to read up on what this does and ended up being rather
bewildered why peopled loved signals so much back in the days that
they've created SIGIO just for that ...
Then I wondered how this e
It's kzalloced ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index cebd847..9c27d42 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/driv
So after a lot of digging around in git histories it looks like this
has only ever be used by dri1 render clients. Hence we can fully
disable the entire thing for modesetting drivers and so greatly reduce
the attack surface for potential exploits (or at least tools like
trinity ...).
Also add the
Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature
flag set, so strictly speaking the modesetting check is redundant. But
adding it has the upside that it makes it very clear that the dma
support is legacy stuff.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_bufs.c | 15 +
And hide the checks a bit better. This was already disallowed for
modesetting drivers, so no functinal change here.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_dma.c | 17 +++--
drivers/gpu/drm/drm_drv.c | 4 +---
drivers/gpu/drm/drm_fops.c | 12 +++-
include/drm/
Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup
was already only done for UMS drivers. Also a quick check of the ATI
ddx git history shows that only the UMS code ever used this facility.
So we can safely disallow these pair of ioctls for modesetting
drivers.
Signed-off-by:
I've decided that some clear markers for what's legacy dri1/non-gem
code is useful. I've opted to use the drm_legacy prefix and then hide
all the checks in that function for better readability in the common
code.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 6 +-
drivers
Totally unused, so just rip it out. Anyway, we want drivers to be
fully backwards compatible, allowing them to change behaviour is just
a recipe for them to break badly.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_ioctl.c | 3 ---
include/drm/drmP.h | 2 --
2 files changed, 5 d
It has way too much potential for driver writers to do stupid things
like delayed hw setup because the load sequence is somehow racy (e.g.
the imx driver in staging). So don't call it for modesetting drivers,
which reduces the complexity of the drm core -> driver interface a
notch.
v2: Don't forge
So if we survey kms drivers there's a bunch of things they commonly do
in ->lastclose
- delayed processing of vga switcheroo requests (i915, nouveau,
radeon)
- force-restoring the fbcon (most)
- resetting a bunch properties to make fbcon work better (omap)
- disabling all outputs (vmwgfx)
In sho
This thing seems to do some kind of delayed setup. Really, real kms
drivers shouldn't do that at all. Either stuff needs to be dynamically
hotplugged or the driver setup sequence needs to be fixed.
This patch here just moves the setup at the very end of the driver
load callback, with the locking a
Again, it does nothing.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/radeon/radeon_drv.c | 2 --
drivers/gpu/drm/radeon/radeon_kms.c | 13 -
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index fa7a7e1..3
KMS drivers really shouldn't need to do anything on firstopen, so kill
empty callbacks.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2f9
Hi all,
So a bunch of patches went in already, and a few of the ones here small fixups
(DocBook, compile fail for funny .configs and 1 unused variable). And slight
rebasing on top of David's drm_dev cleanup refactoring. The big change is that
the get_client ioclt isn't a complete noop now but fake
https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #14 from Bastian Triller ---
Created attachment 83867
--> https://bugs.freedesktop.org/attachment.cgi?id=83867&action=edit
dmesg
there was an error on the first suspend:
...
[drm:rv770_stop_dpm] *ERROR* Could not force DPM to low.
ass/drm/card0/device/power_dpm_state
> >> > balanced
> >> >
> >> > dmesg: radeon: dpm initialized
> >> >
> >> > No specific error in dmesg...
> >> >
> >> > Regards
> >> > Sam
> >> >
> >> > ___
> >> > dri-devel mailing list
> >> > dri-devel at lists.freedesktop.org
> >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> >> >
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/19251379/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=67187
--- Comment #13 from Bastian Triller ---
Resume from suspend only works when I have the power plug attached. It doesn't
matter, if I suspended on AC or not as long I have attached it on resume.
--
You are receiving this mail because:
You are th
On 08/08/2013 02:19 PM, David Herrmann wrote:
> We currently rely on gcc dead-code elimination so the drm_agp_* helpers
> are not called if drm_core_has_AGP() is false. That's ugly as hell so
> provide "static inline" dummies for the case that AGP is disabled.
>
> Fixes a build-regression introduc
Sebastian Hesselbarth wrote on Tue
[2013-Aug-06 00:20:10 +0200]:
> This patch set picks up several patches sent during the past months
> related with NXP TDA998x HDMI transmitter driver. The patches have
> been tested on Marvell Dove (Armada DRM) on several HDMI modes with
> audio playing on S/PD
From: Fabio Estevam
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) causes the
following link error on ARM (imx_v6_v7_defconfig):
drivers/built-in.o: In function `drm_lastclose':
:(.text+0x588a0): undefined reference to `drm_agp_clear'
make: *** [vmlinux] Error 1
drm_agp_c
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #89 from Alex Deucher ---
(In reply to comment #88)
> I've been using DPM in my rv635 for a few days now (intensive use, as this
> is my main machine) and had no issues yet.
> I can however, still tempt fate and try some nasty things
On 08/08/2013 02:19 PM, David Herrmann wrote:
> We currently rely on gcc dead-code elimination so the drm_agp_* helpers
> are not called if drm_core_has_AGP() is false. That's ugly as hell so
> provide "static inline" dummies for the case that AGP is disabled.
>
> Fixes a build-regression introduc
On Thu, Aug 8, 2013 at 1:52 PM, Guennadi Liakhovetski
wrote:
> Hi Bryan,
>
> On Wed, 7 Aug 2013, Bryan Wu wrote:
>
>> Hi Guennadi and LMML,
>>
>> I'm working on a camera controller driver for Tegra, which is using
>> soc_camera. But we also need to use Tegra specific host1x interface
>> like syncp
This patch adds the notion of a drm_bridge. A bridge is a chained
device which hangs off an encoder. The drm driver using the bridge
should provide the association between encoder and bridge. Once a
bridge is associated with an encoder, it will participate in mode
set, dpms, and optionally connecti
Hi Bryan,
On Wed, 7 Aug 2013, Bryan Wu wrote:
> Hi Guennadi and LMML,
>
> I'm working on a camera controller driver for Tegra, which is using
> soc_camera. But we also need to use Tegra specific host1x interface
> like syncpt APIs.
>
> Since host1x is quite Tegra specific framework which is in
Hi, Daniel. You can repost your patch set including the below my patch. And
my patch numbering is wrong. Sorry about that.
[PATCH 1/4] -> [PATCH 4/4]
Thanks,
Inki Dae
> -Original Message-
> From: Inki Dae [mailto:inki.dae at samsung.com]
> Sent: Thursday, August 08, 2013 1:40 PM
> To: d
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #88 from Francisco Pina Martins ---
I've been using DPM in my rv635 for a few days now (intensive use, as this is
my main machine) and had no issues yet.
I can however, still tempt fate and try some nasty things such as quick zoom
in/
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 3cd56e1..fd76449
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, August 08, 2013 8:21 AM
> To: Inki Dae
> Cc: Daniel Vetter; Intel Graphics Development; DRI Development
> Subject: Re: [PATCH 1/3] drm: use common drm_gem_dmabuf_re
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130808/637fd49a/attachment.html>
We currently rely on gcc dead-code elimination so the drm_agp_* helpers
are not called if drm_core_has_AGP() is false. That's ugly as hell so
provide "static inline" dummies for the case that AGP is disabled.
Fixes a build-regression introduced by:
commit 28ec711cd427f8b61f73712a43b8100ba8ca933
On 08/08/2013 12:13 PM, David Herrmann wrote:
> Hi
>
> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren
> wrote:
>> In next-20130808, building tegra_defconfig for ARM yields:
>>
>>> drivers/built-in.o: In function `drm_lastclose':
>>> /home/swarren/
ev ff)
--
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/20130808/246ce781/attachment.html>
Hi
On Thu, Aug 8, 2013 at 9:21 PM, Stephen Warren wrote:
> On 08/08/2013 12:13 PM, David Herrmann wrote:
>> Hi
>>
>> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
>>> In next-20130808, building tegra_defconfig for ARM yields:
>>>
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #87 from Hrvoje Senjan ---
(In reply to comment #86)
> Ingoring suspend/hibernate, is anyone getting hangs or gpu resets with dpm
> enabled under normal operation? If so, can you try disabling clockgating as
> per comment 84? Lets a
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #86 from Alex Deucher ---
Ingoring suspend/hibernate, is anyone getting hangs or gpu resets with dpm
enabled under normal operation? If so, can you try disabling clockgating as
per comment 84? Lets address suspend/hibernate issues s
vel/attachments/20130808/625394f3/attachment-0001.html>
https://bugs.freedesktop.org/show_bug.cgi?id=66963
--- Comment #85 from Sergey ---
> Does disabling clockgating avoid the hangs?
Caught hang after hibernate.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel maili
https://bugzilla.kernel.org/show_bug.cgi?id=60720
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 fr
On 08/08/2013 12:13 PM, David Herrmann wrote:
> Hi
>
> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
>> In next-20130808, building tegra_defconfig for ARM yields:
>>
>>> drivers/built-in.o: In function `drm_lastclose':
>>> /home/swarren/sha
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/9a24fc36/attachment.html>
On Thu, Aug 8, 2013 at 11:34 AM, miaou sami wrote:
> Hi,
>
> thanks for the explanation.
> Do you know if this is a hardware limitation, or if an updated version of
> the driver will come some day?
It's not a hardware limitation. The driver relies on what the OEM put
in the power tables as that
signee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/f75dd844/attachment.html>
> -Original Message-
> From: Rafa? Mi?ecki [mailto:zajec5 at gmail.com]
> Sent: Thursday, August 08, 2013 12:37 AM
> To: Alex Deucher
> Cc: dri-devel at lists.freedesktop.org; airlied at gmail.com; Deucher,
> Alexander
> Subject: Re: [pull] radeon drm-fixes-3.11
>
> 2013/8/8 Alex Deucher
https://bugzilla.kernel.org/show_bug.cgi?id=60720
Bug ID: 60720
Summary: System freeze randomly with latest kernel 3.10 (also
3.11-rc4)
Product: Drivers
Version: 2.5
Kernel Version: 3.10 to 3.11-rc4
Hardware: All
In next-20130808, building tegra_defconfig for ARM yields:
> drivers/built-in.o: In function `drm_lastclose':
> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198:
> undefined reference to `drm_agp_clear'
That's because drm_agp_clear() is called
Hi
On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote:
> In next-20130808, building tegra_defconfig for ARM yields:
>
>> drivers/built-in.o: In function `drm_lastclose':
>> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198:
>> undefine
Hi
On Thu, Aug 8, 2013 at 12:01 PM, Vincent Stehlé
wrote:
> Hi,
>
> Linux next-20130808 link breaks for me with ARM config multi_v7defconfig.
>
> It seems this is due to the following commit:
>
> 28ec711 drm/agp: move AGP cleanup paths to drm_agpsupport.c
>
> .
From: Mark Brown
Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
broke the build for platforms which do not have AGP since it moved the
AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
unconditionally in drm_drv.c. This causes build failures for embedded
S
On Wed, Aug 07, 2013 at 10:34:48PM -0400, Ilia Mirkin wrote:
> This makes it so that reloading a module does not cause all the
> connector ids to change, which are user-visible and sometimes used
> for configuration.
>
> Signed-off-by: Ilia Mirkin
> ---
>
> v2 -> v3:
> - rename ida struct name
Hi
On Thu, Aug 8, 2013 at 12:20 PM, Mark Brown wrote:
> From: Mark Brown
>
> Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c)
> broke the build for platforms which do not have AGP since it moved the
> AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced
> uncon
In next-20130808, building tegra_defconfig for ARM yields:
> drivers/built-in.o: In function `drm_lastclose':
> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198:
> undefined reference to `drm_agp_clear'
That's because drm_agp_clear() is called
On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart
wrote:
> Hi Dave,
>
> I've got a couple of arch/arm/ patches that depend on this series and that I
> would like to get merged in v3.12. They should go upstream through the arm-soc
> tree. Would you be able to provide a stable branch with this patch
1 - 100 of 182 matches
Mail list logo
