https://bugs.freedesktop.org/show_bug.cgi?id=58378
--- Comment #2 from Henrique Dias ---
Today messages from dmesg:
[ 4115.879007] nouveau E[ PGRAPH][:01:00.0] TRAP_MP_EXEC - TP 0 MP 0:
INVALID_OPCODE at 07ff00 warp 0, opcode
[ 4115.879007] nouveau [ PGRAPH][:01:00.0
On Mon, 2012-12-17 at 16:01 +0200, Terje Bergström wrote:
> Considering the amount of feedback I've received from the patches, they
> must be top notch quality!
Maybe.
Maybe no one else has the hardware.
___
dri-devel mailing list
dri-devel@lists.freede
On Mon, 2012-12-17 at 16:01 +0200, Terje Bergstr?m wrote:
> Considering the amount of feedback I've received from the patches, they
> must be top notch quality!
Maybe.
Maybe no one else has the hardware.
On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark wrote:
>> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
>> drivers. It's not really a big deal if it's only kernel code, but you
>> add device-tree bindings also, which is an external API that you need to
>> support after adding it.
>
Hi Laurent -
On Mon, 17 Dec 2012, Laurent Pinchart wrote:
> Hi Tomi,
>
> I finally have time to work on a v3 :-)
>
> On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
>> On 2012-11-22 23:45, Laurent Pinchart wrote:
>> > From: Laurent Pinchart
>> >
>> > Hi everybody,
>> >
>> > Here's t
On 2012-12-17 16:36, Laurent Pinchart wrote:
> Hi Tomi,
>
> I finally have time to work on a v3 :-)
>
> On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
>> On 2012-11-22 23:45, Laurent Pinchart wrote:
>>> From: Laurent Pinchart
>>>
>>> Hi everybody,
>>>
>>> Here's the second RFC of what
Hi Rob,
On Monday, December 17, 2012, Rob Clark wrote:
> On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark >
> wrote:
> >> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
> >> drivers. It's not really a big deal if it's only kernel code, but you
> >> add device-tree bindings also, whi
On 2012-12-14 02:04, Rob Clark wrote:
> A simple DRM/KMS driver for the TI LCD Controller found in various
> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
> CMA helpers. Currently only the TFP410 DVI encoder is supported
> (tested with beaglebone + DVI cape). There are also vari
On 17.12.2012 17:04, j.gli...@gmail.com wrote:
From: Jerome Glisse
radeon_fence_wait_empty_locked should not trigger GPU reset as no
place where it's call from would benefit from such thing and it
actually lead to a kernel deadlock in case the reset is triggered
from pm codepath. Instead force
On Mon, Dec 17, 2012 at 7:56 AM, Tomi Valkeinen
wrote:
> On 2012-12-14 02:04, Rob Clark wrote:
>> A simple DRM/KMS driver for the TI LCD Controller found in various
>> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
>> CMA helpers. Currently only the TFP410 DVI encoder is support
On Mon, Dec 17, 2012 at 9:26 AM, Sekhar Nori wrote:
> Hi Rob,
>
>
> On Monday, December 17, 2012, Rob Clark wrote:
>>
>> On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark wrote:
>> >> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
>> >> drivers. It's not really a big deal if it's onl
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #16 from Andre 2012-12-17 16:11:28 ---
Before i could crash X almost instantaneously by switching the kde (openGL)
screensaver back and forth.
Now the system runs for almost two hours without any problems so far.
--
Configure b
From: Jerome Glisse
radeon_fence_wait_empty_locked should not trigger GPU reset as no
place where it's call from would benefit from such thing and it
actually lead to a kernel deadlock in case the reset is triggered
from pm codepath. Instead force ring completion in place where it
makes sense or
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.
Signed-off-by: Daniel
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 da
Hi all,
So in the course of beating the pageflip paths senseless to test the new locking
scheme I've hunted down some bugs on g33. Sometimes we seemingly time out
waiting for the event - apparently the pageflip irq is lost somewhere. I've
tried to dig in, but lost myself completely in the rather f
On 17.12.2012 16:29, j.gli...@gmail.com wrote:
From: Jerome Glisse
Force all fence to signal if GPU reset failed so no process get stuck
on waiting fence.
Signed-off-by: Jerome Glisse
Seems to make sense.
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
https://bugs.freedesktop.org/show_bug.cgi?id=26345
--- Comment #153 from Chris Wilson ---
Now in kernel form as well:
commit b75e53bac7f4164e1c53a636352faa3d177b4beb
Author: Daniel Vetter
Date: Sun Dec 16 18:08:07 2012 +0100
drm/i915: Implement workaround for broken CS tlb on i830/845
From: Jerome Glisse
Force all fence to signal if GPU reset failed so no process get stuck
on waiting fence.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_device.c | 1 +
drivers/gpu/drm/radeon/radeon_fence.c | 19 +++
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121217/9e95bb5c/attachment.html>
On Mon, Dec 17, 2012 at 4:11 AM, Christian König
wrote:
> On 14.12.2012 21:33, Jerome Glisse wrote:
>>
>> On Fri, Dec 14, 2012 at 3:13 PM, Christian König
>> wrote:
>>>
>>> On 14.12.2012 18:39, j.gli...@gmail.com wrote:
From: Jerome Glisse
After lockup we need to resume fence
Hi Alan,
On Monday 26 November 2012 14:47:08 Alan Cox wrote:
> On Sat, 24 Nov 2012 09:15:51 +0200 Tomi Valkeinen wrote:
> > On 2012-11-23 21:56, Thierry Reding wrote:
> > > On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > > [...]
> > >
> > >> Display entities are accessed by
On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark wrote:
>> I'm not very enthusiastic about adding ti-lcdc specific panel/chip
>> drivers. It's not really a big deal if it's only kernel code, but you
>> add device-tree bindings also, which is an external API that you need to
>> support after adding it.
>
Hi Sascha,
On Friday 23 November 2012 22:41:58 Sascha Hauer wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> > From: Laurent Pinchart
> >
> > The CDF models this using a Russian doll's model. From the display
> > controller point of view only the first external entity
Hi Thierry,
On Friday 23 November 2012 20:56:07 Thierry Reding wrote:
> On Thu, Nov 22, 2012 at 10:45:31PM +0100, Laurent Pinchart wrote:
> [...]
>
> > Display entities are accessed by driver using notifiers. Any driver can
> > register a display entity notifier with the CDF, which then calls the
On Mon, Dec 17, 2012 at 7:56 AM, Tomi Valkeinen wrote:
> On 2012-12-14 02:04, Rob Clark wrote:
>> A simple DRM/KMS driver for the TI LCD Controller found in various
>> smaller TI parts (AM33xx, OMAPL138, etc). This driver uses the
>> CMA helpers. Currently only the TFP410 DVI encoder is supporte
Hi Tomi,
I finally have time to work on a v3 :-)
On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote:
> On 2012-11-22 23:45, Laurent Pinchart wrote:
> > From: Laurent Pinchart
> >
> > Hi everybody,
> >
> > Here's the second RFC of what was previously known as the Generic Panel
> > Framewo
On 13.12.2012 17:23, Joe Perches wrote:
> On Thu, 2012-12-13 at 16:04 +0200, Terje Bergstrom wrote:
>> Add support for host1x debugging. Adds debugfs entries, and dumps
>> channel state to UART in case of stuck job.
>
> trivial note:
>
> []
>
>> diff --git a/drivers/gpu/host1x/debug.h b/drivers/
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: 6ace91e648a327ebf98093b6d971a097c36cd46d
commit: 6ace91e648a327ebf98093b6d971a097c36cd46d [120/120] drm/i915: Clear the
stolen fb before enabling
sparse warnings:
+ drivers/gpu/drm/i915/intel_fb.c:163:17: s
Hi Linus,
This is the one and only next pull for 3.8, we had a regression we found
last week, so I was waiting for that to resolve itself, and I ended up
with some Intel fixes on top as well.
Highlights:
new driver: nvidia tegra 20/30/hdmi support
radeon: add support for previously unused DMA
>
> Hi Ozan,
>
> Please have a look at this documentation:
> http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/thermal/nouveau_thermal
> It will tell you how to use fan management on your card :)
>
> Please report back! I am interested in your results!
>
> Martin
Hey this is nice! I
Hi Nouveau enthusiasts,
One week ago was merged the thermal/fan management code for most nvidia
cards.
So far, no major issue arose but we would like to have more testing as
soon as possible to deliver a nice and solid support when Linux 3.8 is
released.
Thermal management is split into two p
From: Martin Peres
Signed-off-by: Martin Peres
---
src/gallium/state_trackers/egl/x11/x11_screen.c | 2 +-
src/glx/dri2.c | 6 +-
src/glx/dri2.h | 3 ++-
src/glx/dri2_glx.c | 20 +++
From: Martin Peres
Signed-off-by: Martin Peres
---
configure.ac | 2 +-
src/nouveau_dri2.c | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index ff9c337..61dfb01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -67,7 +67,7 @@ XO
From: Martin Peres
Signed-off-by: Martin Peres
---
glx/glxdri2.c | 3 ++-
hw/xfree86/dri2/dri2.c| 11 ++-
hw/xfree86/dri2/dri2.h| 8 ++--
hw/xfree86/dri2/dri2ext.c | 8 ++--
4 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/glx/glxdri2.c b/gl
From: Martin Peres
Signed-off-by: Martin Peres
---
dri2proto.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/dri2proto.h b/dri2proto.h
index 128b807..4d11ba7 100644
--- a/dri2proto.h
+++ b/dri2proto.h
@@ -35,7 +35,7 @@
#define DRI2_NAME "DRI2
From: Martin Peres
Signed-off-by: Martin Peres
---
configure.ac | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 0c19929..df56066 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63])
AC_INIT([libdrm],
-
From: Martin Peres
Signed-off-by: Martin Peres
---
nouveau/libdrm_nouveau.pc.in | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 6170613..f3b99cf 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_n
From: Martin Peres
Signed-off-by: Martin Peres
---
nouveau/nouveau.c | 11 +--
nouveau/nouveau.h | 2 ++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
index 940d933..1402852 100644
--- a/nouveau/nouveau.c
+++ b/nouveau/nouveau.c
@
From: Martin Peres
Signed-off-by: Martin Peres
---
.gitignore | 1 +
tests/Makefile.am| 1 +
tests/same_device_but_type.c | 52
xf86drm.c| 44 +
xf86drm.h
From: Martin Peres
Signed-off-by: Martin Peres
---
tests/name_from_fd.c | 19 ++
xf86drm.c| 105 ---
xf86drm.h| 7
3 files changed, 100 insertions(+), 31 deletions(-)
diff --git a/tests/name_from_fd.c b/tes
From: Martin Peres
Enable support for drm render nodes for nouveau by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Martin Peres
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --
From: Kristian H?gsberg
Enable support for drm render nodes for i915 by flagging the ioctls that
are safe and just needed for rendering.
Signed-off-by: Kristian H?gsberg
---
drivers/gpu/drm/i915/i915_dma.c | 36 ++--
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
2 f
From: Kristian H?gsberg
This patch introduces a new kind of drm device node: the render node.
A render node exposes a safe subset of the legacy drm device ioctls and can
only be used for rendering. The legacy node supports modesetting, DRI1
and global buffer sharing, while the render node only s
From: Kristian H?gsberg
We got the minor number base right, but limit is too big and causes the
minor numer ranges for the control and render nodes to overlap.
v2: fix a off-by-one overlap as suggested by ihadzic at research.bell-labs.com
Signed-off-by: Martin Peres
---
drivers/gpu/drm/drm_st
management on your card :)
Please report back! I am interested in your results!
Martin
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/e57587cf/attachment-0001.html>
m-next&id=dd54fee7d440c4a9756cce2c24a50c15e4c17ccb
Yea i have that commit.
--
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/20121217/1909bd31/attachment.html>
Hi,
Following to my shared talk with krh, danvet and Timoth?e Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in the
graphics stack.
Today, I would like to request your comments on the render node
patchset. Keep in mind that I am
not asking for inclus
Hi,
Following to my shared talk with krh, danvet and Timoth?e Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in the
graphics stack.
Today, I would like to request your comments on the render node
patchset. Keep in mind that I am
not asking for inclus
u 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/20121217/bbacb724/attachment.html>
On 14.12.2012 21:33, Jerome Glisse wrote:
On Fri, Dec 14, 2012 at 3:13 PM, Christian König
wrote:
On 14.12.2012 18:39, j.gli...@gmail.com wrote:
From: Jerome Glisse
After lockup we need to resume fence to last sync sequence and not
last received sequence so that all thread waiting on command
On 17 December 2012 14:25, Sumit Semwal wrote:
Apologies for re-sending, since the gmail ui 'decided' to set some
formatting options by default!
> Hi Maarten,
>
> On 14 December 2012 17:27, Maarten Lankhorst
> wrote:
>>
>> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
>> > From: Sumit Semwal
>
On 14 December 2012 16:04, Daniel Vetter wrote:
>
> Missed one ...
>
> On Fri, Dec 14, 2012 at 10:36 AM, wrote:
> > + list_for_each_entry(attach_obj, &buf_obj->attachments,
> > node) {
> > + seq_printf(s, "\t\t");
> > +
> > + seq_printf(
Hi Maarten,
On 14 December 2012 17:27, Maarten Lankhorst wrote:
> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
> > From: Sumit Semwal
> >
> > Add debugfs support to make it easier to print debug information
> > about the dma-buf buffers.
> >
> I like the idea, I don't know if it could be done
Hi,
Following to my shared talk with krh, danvet and Timothée Ravier @
XDC2012, I have
actually taken the time to start fixing some security holes found in the
graphics stack.
Today, I would like to request your comments on the render node
patchset. Keep in mind that I am
not asking for incl
Hi,
On 12/14/2012 10:36 AM, sumit.sem...@ti.com wrote:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Signed-off-by: Sumit Semwal
> ---
> drivers/base/dma-buf.c | 149
> +
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #15 from Alex Deucher 2012-12-17
00:34:33 ---
Does this patch fix the issue?
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next&id=bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a
--
Configure bugmail: https://bugzilla.kerne
ving 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/20121217/6eec764e/attachment.html>
101 - 158 of 158 matches
Mail list logo
