GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 23:25 +0100, Markus Trippelsdorf wrote: > On 2012.12.17 at 17:00 -0500, Alex Deucher wrote: > > On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf > > wrote: > > > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > > >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > >

Fan control in nouveau driver with geforce 9600gt

rt -- A non-text attachment was scrubbed... Name: 0001-drm-nouveau-fan-handle-the-cases-where-we-are-outsid.patch Type: text/x-patch Size: 1153 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/ac6a3d9f/attachment.bin>

i915: GPU hang

Hi all Sorry, not sure what information is most appropriate here. GPU hangs from time to time on this laptop, typically when running firefox on graphics-intensive sites. Error log at the bottom. Distro is Debian 6.0.6 (squeeze), lspci 00:02.0 VGA compatible controller: Intel Corporation

GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 17:00 -0500, Alex Deucher wrote: > On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf > wrote: > > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > >> wrote: > >> > As soon as I open the following website: > >> >

[RFC v2 0/5] Common Display Framework

Hi Jani, On Monday 17 December 2012 18:53:37 Jani Nikula wrote: > On Mon, 17 Dec 2012, Laurent Pinchart wrote: > > On Friday 23 November 2012 16:51:37 Tomi Valkeinen wrote: > >> On 2012-11-22 23:45, Laurent Pinchart wrote: > >> > From: Laurent Pinchart

[PATCH] drm/ttm: move ttm_lock.c to drm/vmwgfx

On 12/14/12 7:50 PM, Daniel Vetter wrote: > Dude, you're seriously overshooting here. This patch isn't required > _at_ _all_ to do cross device sharing/reservations/whatever. We've > simply discussed TTM documentation in the context of Maartens work, > and I've suggested to include all the TTM

[RFC v2 0/5] Common Display Framework

Hi Vikas, On Friday 14 December 2012 10:27:12 Vikas Sajjan wrote: > > Hi All, > > I was thinking of porting samsung exynos 5250 display driver as per CDF, > > but i had certain doubts and wanted to discuss with you guys, > > 1. Samsung Exynos supports MIPI DSI based display panels, wondering

GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 22:48 +0100, Markus Trippelsdorf wrote: > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > > On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > > wrote: > > > As soon as I open the following website: > > >

GPU lockup CP stall for more than 10000msec on latest vanilla git

On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: > On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf > wrote: > > As soon as I open the following website: > > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html > > > > my Radeon RS780 stalls (GPU lockup) leaving the

[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset

On an (outdated) laptop the radeon driver (almost always) prints, during the first resume of each session: [drm] crtc 1 is connected to a TV This message is a bit puzzling as, as far as I know, no TV has ever been connected to this laptop. Anyhow, before v3.5, if that happened the radeon

[Bug 56634] r600g: fix abysmal performance in Reaction Quake : Huge slowdown

we forget about the 3 fps thing) -- 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/9e69477e/attachment.html>

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

[1462:3fe9] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/60dcebbd/attachment.html>

[Bug 57670] segfault with etqw.demo

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/fa3ff760/attachment.html>

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

ext part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/af1c74e2/attachment.html>

[Bug 44126] [r300g] 0ad: carpet textures "flash" and get hidden by ground texture.

org/archives/dri-devel/attachments/20121217/07202b36/attachment.html>

[PATCH 0/3] add mie driver for exynos

On Mon, Dec 17, 2012 at 7:59 PM, St?phane Marchesin wrote: > >> And >> fimd, as display controller, could be controlled by linux framebuffer or drm >> framework. >> > > I don't think it's a valid point. If the framebuffer is properly done > on top of the DRM, you don't need all of that at all.

[drm-intel:drm-intel-next-queued 120/120] drivers/gpu/drm/i915/intel_fb.c:163:17: sparse: incorrect type in argument 1 (different address spaces)

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:

[RFC] drm/lcdc: add TI LCD Controller DRM driver

brightness = <100>; > }; > }; > > display-timings is based on the of-videomode helpers patch.. > panel-info probably needs to be made to be something more generic, but > we need something to know how to configure the crtc properly.. > > but I'm not quite sure what to do with the backlight.. > > BR, > -R > > ___ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org <javascript:;> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/4154d6df/attachment-0001.html>

GPU lockup CP stall for more than 10000msec on latest vanilla git

As soon as I open the following website: http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html my Radeon RS780 stalls (GPU lockup) leaving the machine unusable: Dec 17 17:41:39 x4 kernel: [drm] Initialized drm 1.1.0 20060810 Dec 17 17:41:39 x4 kernel: [drm] radeon

[Intel-gfx] [PATCH 2/2] drm/i915: wake up all pageflip waiters

On Mon, 17 Dec 2012 16:59:00 +0100, 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

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121217/dc0ea3eb/attachment.html>

[RFC v2 0/5] Common Display Framework

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

[PATCH] drm/radeon: avoid deadlock in pm path when waiting for fence

On 17.12.2012 17:04, j.glisse at 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.

[RFC v2 0/5] Common Display Framework

display. So omapfb does calls both to the DSS side and to the panel side of the pipeline. I agree that making calls to both ends is a bit silly, but then again, I think it also happens in your model, it's just hidden there. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/900c825d/attachment-0001.pgp>

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/1bf307f2/attachment.html>

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121217/9deb383b/attachment.html>

GPU lockup CP stall for more than 10000msec on latest vanilla git

On Mon, Dec 17, 2012 at 4:48 PM, Markus Trippelsdorf wrote: > On 2012.12.17 at 16:32 -0500, Alex Deucher wrote: >> On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf >> wrote: >> > As soon as I open the following website: >> >

[PATCH 2/2] 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. Signed-off-by: Daniel

[PATCH 1/2] 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 0/2] Two patches for pageflips

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

[PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

On 17.12.2012 16:29, j.glisse at 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

[PATCH] drm/radeon: avoid deadlock in pm path when waiting for fence

Added to fixes and stable. Thanks! On Mon, Dec 17, 2012 at 11:41 AM, Christian K?nig wrote: > On 17.12.2012 17:04, j.glisse at 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

[PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

Applied to my fixes branch. Thanks! 2012/12/17 Christian K?nig : > Reviewed-by: Christian K?nig

GPU lockup CP stall for more than 10000msec on latest vanilla git

On Mon, Dec 17, 2012 at 1:27 PM, Markus Trippelsdorf wrote: > As soon as I open the following website: > http://www.boston.com/bigpicture/2012/12/2012_year_in_pictures_part_i.html > > my Radeon RS780 stalls (GPU lockup) leaving the machine unusable: Is this a regression? Most likely a 3D driver

[RFC v2 0/5] Common Display Framework

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

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

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

[RFC v2 0/5] Common Display Framework

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 > >

[PATCHv3 4/7] gpu: host1x: Add debug support

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

[RFC v2 0/5] Common Display Framework

similar fashion, DT bindings needs to reference the panel through a phandle, even though in some cases they could technically just be children of the display controller. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/132907d3/attachment-0001.pgp>

[RFC] drm/lcdc: add TI LCD Controller DRM driver

panel/chip driver issue solved in a generic manner. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/8d319cc7/attachment-0001.pgp>

[Bug 26345] [845G] CPU/GPU incoherency

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/5654dae3/attachment.html>

[RFC v2 0/5] Common Display Framework

What is missing in your proposal is an explanation of how the panel is controlled. What does your register_display() function register the display with, and what then calls the display operations ? -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/a62b7de6/attachment.pgp>

Fan control in nouveau driver with geforce 9600gt

> > 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!

[Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

t. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121217/15bff657/attachment.html>

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

On 12/16/2012 09:37 AM, Terje Bergstr?m wrote: ... > ... Sure we could tell DC to ask its parent > (host1x), and call host1x driver with platform_device pointer found that > way, and host1x would return a pointer to tegradrm's data. Hanging the > data onto host1x driver is just a more complicated

[PATCH] drm/radeon: avoid deadlock in pm path when waiting for fence

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

[PATCH 0/3] add mie driver for exynos

On Tue, Dec 11, 2012 at 8:01 PM, Inki Dae wrote: > > > 2012/12/12 St?phane Marchesin >> >> On Mon, Dec 10, 2012 at 1:27 AM, Inki Dae wrote: >> > >> > >> > 2012/12/10 St?phane Marchesin >> >> >> >> On Sun, Dec 9, 2012 at 10:26 PM, Inki Dae wrote: >> >> > >> >> > >> >> > 2012/12/6 R.

[PATCH resend] drm: nouveau: Fix build warning seen if HWMON is undefined

Fix: nouveau_pm.c: In function ?nouveau_hwmon_init?: nouveau_pm.c:703:24: warning: unused variable ?therm? [-Wunused-variable] Signed-off-by: Guenter Roeck --- drivers/gpu/drm/nouveau/nouveau_pm.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[RFC] drm/lcdc: add TI LCD Controller DRM driver

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

[PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

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

[PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

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.glisse at gmail.com wrote: From: Jerome Glisse After lockup we need to resume

[PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

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.glisse at 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

[PATCHv3 4/7] gpu: host1x: Add debug support

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.

[RFC] drm/lcdc: add TI LCD Controller DRM driver

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.

[RFC] drm/lcdc: add TI LCD Controller DRM driver

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

[Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121217/9e95bb5c/attachment.html>

[git pull] drm next

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

Request for nv40-c0 testing thermal/fan management

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

[PATCH] dri2: add support for render nodes

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

[PATCH] add support for render nodes

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 +++

[PATCH] dri2: add support for render nodes

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

[PATCH] dri2proto: add device_requires_auth in xDRI2ConnectReply to support render nodes

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

[PATCH 4/5] nouveau: bump version to 2.4.34 for release

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 ---

[PATCH 3/5] nouveau: Allow opening a specific type of drm device

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

[PATCH 2/5] drm: generate the path of a different device type for the same drm device

From: Martin Peres Signed-off-by: Martin Peres --- .gitignore | 1 + tests/Makefile.am| 1 + tests/same_device_but_type.c | 52 xf86drm.c| 44

[PATCH 4/4] drm/nouveau: Support render nodes

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(+),

[PATCH 3/4] drm/i915: Support render nodes

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 ++--

[PATCH 2/4] drm: Add support for render nodes

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

[PATCH 1/4] drm: Fix DRM_MINOR limits for control and render nodes

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 ---

Fan control in nouveau driver with geforce 9600gt

gement 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>

[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

=drm-next=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>

[RFC] Complete experimental render node implementation

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

[RFC] Complete experimental render node implementation

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

[Bug 57350] [nouveau, linux-3.7-rc] Broken cursor and kernel log swamped with "PAGE_NOT_PRESENT" errors

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>

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

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=bd25f0783dc3fb72e1e2779c2b99b2d34b67fa8a -- Configure bugmail:

[Bug 58372] [KMS][Cayman] Garbled screen and gpu crash with 6950 with drm-next

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>

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Hi, On 12/14/2012 10:36 AM, sumit.sem...@ti.com wrote: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- drivers/base/dma-buf.c | 149

[RFC] Complete experimental render node implementation

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

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

Hi Maarten, On 14 December 2012 17:27, Maarten Lankhorst m.b.lankho...@gmail.comwrote: Op 14-12-12 10:36, sumit.sem...@ti.com schreef: From: Sumit Semwal sumit.sem...@linaro.org Add debugfs support to make it easier to print debug information about the dma-buf buffers. I like the

Re: [PATCH] dma-buf: Add debugfs support

On 14 December 2012 16:04, Daniel Vetter dan...@ffwll.ch wrote: Missed one ... On Fri, Dec 14, 2012 at 10:36 AM, sumit.sem...@ti.com wrote: + list_for_each_entry(attach_obj, buf_obj-attachments, node) { + seq_printf(s, \t\t); + +

Re: [Linaro-mm-sig] [PATCH] dma-buf: Add debugfs support

On 17 December 2012 14:25, Sumit Semwal sumit.sem...@linaro.org 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 m.b.lankho...@gmail.com wrote: Op 14-12-12 10:36,

Re: [PATCH] drm/radeon: resume fence driver to last sync sequence on lockup

On 14.12.2012 21:33, Jerome Glisse wrote: On Fri, Dec 14, 2012 at 3:13 PM, Christian König deathsim...@vodafone.de wrote: On 14.12.2012 18:39, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com After lockup we need to resume fence to last sync sequence and not last received

Re: Fan control in nouveau driver with geforce 9600gt

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'll try

[drm-intel:drm-intel-next-queued 120/120] drivers/gpu/drm/i915/intel_fb.c:163:17: sparse: incorrect type in argument 1 (different address spaces)

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:

Re: [PATCHv3 4/7] gpu: host1x: Add debug support

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

Re: [RFC v2 0/5] Common Display Framework

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 laurent.pinchart+rene...@ideasonboard.com Hi everybody, Here's the second RFC of what was previously known

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

On Mon, Dec 17, 2012 at 7:56 AM, Tomi Valkeinen tomi.valkei...@ti.com 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

Re: [RFC v2 0/5] Common Display Framework

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

Re: [RFC v2 0/5] Common Display Framework

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 laurent.pinchart+rene...@ideasonboard.com The CDF models this using a Russian doll's model. From the display controller point of

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark robdcl...@gmail.com 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

Re: [RFC v2 0/5] Common Display Framework

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 driver using

[PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

From: Jerome Glisse jgli...@redhat.com Force all fence to signal if GPU reset failed so no process get stuck on waiting fence. Signed-off-by: Jerome Glisse jgli...@redhat.com --- drivers/gpu/drm/radeon/radeon.h| 1 + drivers/gpu/drm/radeon/radeon_device.c | 1 +

[Bug 26345] [845G] CPU/GPU incoherency

https://bugs.freedesktop.org/show_bug.cgi?id=26345 --- Comment #153 from Chris Wilson ch...@chris-wilson.co.uk --- Now in kernel form as well: commit b75e53bac7f4164e1c53a636352faa3d177b4beb Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Sun Dec 16 18:08:07 2012 +0100 drm/i915:

Re: [PATCH] drm/radeon: don't leave fence blocked process on failed GPU reset

On 17.12.2012 16:29, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Force all fence to signal if GPU reset failed so no process get stuck on waiting fence. Signed-off-by: Jerome Glisse jgli...@redhat.com Seems to make sense. Reviewed-by: Christian König

[PATCH 0/2] Two patches for pageflips

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

[PATCH 1/2] 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 2/2] 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. Signed-off-by: Daniel

[PATCH] drm/radeon: avoid deadlock in pm path when waiting for fence

From: Jerome Glisse jgli...@redhat.com 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

[Bug 47481] Random blank screen: radeon_cs_ib_chunk Failed to schedule IB on AMD PALM

https://bugzilla.kernel.org/show_bug.cgi?id=47481 --- Comment #16 from Andre and...@all-ein.net 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

Re: [RFC] drm/lcdc: add TI LCD Controller DRM driver

On Mon, Dec 17, 2012 at 9:26 AM, Sekhar Nori nori.sek...@gmail.com wrote: Hi Rob, On Monday, December 17, 2012, Rob Clark wrote: On Mon, Dec 17, 2012 at 8:39 AM, Rob Clark robdcl...@gmail.com wrote: I'm not very enthusiastic about adding ti-lcdc specific panel/chip drivers. It's not

  1   2   >