Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 06:34 AM, Ben Skeggs wrote: From: Ben Skeggsbske...@redhat.com Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was originally able to presume that bo-mem is the old node, and new_mem is the new node. The

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote: On 01/25/2012 06:34 AM, Ben Skeggs wrote: From: Ben Skeggsbske...@redhat.com Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was originally able to

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs skeg...@gmail.com wrote: From: Ben Skeggs bske...@redhat.com Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was originally able to presume that bo-mem is the old node, and

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, 2012-01-25 at 08:24 +, Dave Airlie wrote: On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs skeg...@gmail.com wrote: From: Ben Skeggs bske...@redhat.com Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 09:05 AM, Ben Skeggs wrote: On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote: On 01/25/2012 06:34 AM, Ben Skeggs wrote: From: Ben Skeggsbske...@redhat.com Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver.

[Bug 44919] Wayland clients segfault

https://bugs.freedesktop.org/show_bug.cgi?id=44919 Benjamin Franzke benjaminfran...@googlemail.com changed: What|Removed |Added Status|NEW

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, 2012-01-25 at 09:39 +0100, Thomas Hellstrom wrote: On 01/25/2012 09:05 AM, Ben Skeggs wrote: On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote: On 01/25/2012 06:34 AM, Ben Skeggs wrote: From: Ben Skeggsbske...@redhat.com Both changes in

Re: [next] Null pointer dereference in nouveau_vm_map_sg

On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse j.gli...@gmail.com wrote: Can you please both test if attached patch fix it for you ? Thanks. It looks good too me, but it crashes a little later due to vma-node being invalid: Jan 25 00:54:21 callisto kernel: [ 119.038357] [drm]

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed symbols can be used by the binary blobs, possibly with an open-sourced shim which provides the buffer-sharing interface to the binary blobs? Are there any reasons to not consider this approach? The GPL requires all the code of

Re: [PATCH 1/2] omap2+: add drm device

On Tue, Jan 24, 2012 at 8:32 PM, Rob Clark rob.cl...@linaro.org wrote: On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.cl...@linaro.org wrote: On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras

Re: [Linaro-mm-sig] [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

On Fri, Jan 20, 2012 at 6:53 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Summit, Sorry for the late review. I know that this code is now in mainline, but I still have a couple of comments. I'll send patches if you agree with them. Hi Laurent, Thanks for your review;

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

Em 25-01-2012 10:30, Alan Cox escreveu: Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed symbols can be used by the binary blobs, possibly with an open-sourced shim which provides the buffer-sharing interface to the binary blobs? Are there any reasons to not consider this

Re: [PATCH] dma-buf: Use EXPORT_SYMBOL

Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu: Em 25-01-2012 10:30, Alan Cox escreveu: Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed symbols can be used by the binary blobs, possibly with an open-sourced shim which provides the buffer-sharing interface to the binary

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 10:41 AM, Ben Skeggs wrote: My main concern is that we blindly and unnecessarily set up GPU bindings and end up with unnecessary code in TTM, and furthermore that we communicate that bad practice to future driver writers. This unnecessary code is like 5 lines of cleanup if

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: On 01/25/2012 10:41 AM, Ben Skeggs wrote: My main concern is that we blindly and unnecessarily set up GPU bindings and end up with unnecessary code in TTM, and furthermore that we communicate that bad practice to future driver

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs skeg...@gmail.com wrote: On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: On 01/25/2012 10:41 AM, Ben Skeggs wrote: My main concern is that we blindly and unnecessarily set up GPU bindings and end up with unnecessary code in TTM,

[PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

It is never correct to use intel_crtc-bpp in intel_dp_link_required, so instead pass an explicit bpp in to this function. This patch only supports 18bpp and 24bpp modes, which means that 10bpc modes will be computed incorrectly. Fixing that will require more extensive changes, and so must be

[PATCH 2/2] drm/i915: Select DP BPC at mode set, rather than mode validate

The DP configuration must match the pipe configuration, and until mode set we don't know what BPC will be used. Delay all decisions about BPC until mode set, computing the target BPC in both intel_dp_mode_fixup and either i9xx_crtc_mode_set or ironlake_crtc_mode_set. It might be slightly better to

[PATCH 0/2] drm/i915: Use correct bpc computations for DisplayPort

Here's a couple of patches that fix some bpc (bits per component) computation issues with DisplayPort. The problem was that the DisplayPort code tried to figure out the 'current' bpc by looking at the bpp stored in an associated crtc, but that was never right (as described in the message for the

Re: [next] Null pointer dereference in nouveau_vm_map_sg

On Tue, Jan 24, 2012 at 7:12 PM, Martin Nyhus martin.ny...@gmx.com wrote: On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse j.gli...@gmail.com wrote: Can you please both test if attached patch fix it for you ? Thanks. It looks good too me, but it crashes a little later due to vma-node being

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 04:37 PM, Jerome Glisse wrote: On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.com wrote: On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: On 01/25/2012 10:41 AM, Ben Skeggs wrote: My main concern is that we blindly and unnecessarily set up GPU bindings and

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #33 from Camaleón noela...@gmail.com 2012-01-25 09:16:12 PST --- (In reply to comment #32) (In reply to comment #31) bugzilla-dae...@freedesktop.org wrote: The user reported that system crashed after a while. Interesting

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #34 from Camaleón noela...@gmail.com 2012-01-25 09:17:55 PST --- Created attachment 56153 -- https://bugs.freedesktop.org/attachment.cgi?id=56153 Syslog with drm.debug=6 + call trace -- Configure bugmail:

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 04:37 PM, Jerome Glisse wrote: On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.com wrote: On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: On 01/25/2012 10:41 AM, Ben Skeggs wrote: My main concern is that we blindly and unnecessarily set up GPU bindings and

Re: [PATCH] drm: Fix authentication kernel crash

On 01/24/2012 03:47 PM, Daniel Vetter wrote: On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote: If the master tries to authenticate a client using drm_authmagic and that client has already closed its drm file descriptor, either wilfully or because it was terminated, the call to

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 06:34 AM, Ben Skeggs wrote: From: Ben Skeggsbske...@redhat.com Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was originally able to presume that bo-mem is the old node, and new_mem is the new node. The

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #35 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 09:37:29 PST --- bugzilla-dae...@freedesktop.org wrote: Syslog with drm.debug=6 + call trace Summary follows. Log is from 25 January. 15:55 bootup 15:55 [after 22 seconds]

Re: [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

Hi Sumit, On 12/26/2011 10:23 AM, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - creation of a buffer

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #36 from Alex Deucher ag...@yahoo.com 2012-01-25 09:54:47 PST --- It's a GPU lockup. Unfortunately, they tend to be really hard to track down. You might try a newer ddx or mesa. -- Configure bugmail:

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 Alexandre Demers alexandre.f.dem...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #37 from Camaleón noela...@gmail.com 2012-01-25 10:10:06 PST --- (In reply to comment #36) It's a GPU lockup. Unfortunately, they tend to be really hard to track down. You might try a newer ddx or mesa. We're open to test

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom tho...@shipmail.org wrote: On 01/25/2012 04:37 PM, Jerome Glisse wrote: On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.com  wrote: On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: On 01/25/2012 10:41 AM, Ben Skeggs

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #38 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 10:17:22 PST --- bugzilla-dae...@freedesktop.org wrote: How could we test a new ddx (sorry to ask but, what's that? :-?) or an udpated mesa without breaking many things?

Re: [RFC] Future TTM DMA direction

OK, revisiting this again, please see inline below, On 01/10/2012 06:46 PM, Jerome Glisse wrote: On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote: On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: Hi! When TTM was originally written, it was assumed that GPU

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 07:12 PM, Dave Airlie wrote: On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstromtho...@shipmail.org wrote: On 01/25/2012 04:37 PM, Jerome Glisse wrote: On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggsskeg...@gmail.comwrote: On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #39 from Camaleón noela...@gmail.com 2012-01-25 10:35:48 PST --- (In reply to comment #38) bugzilla-dae...@freedesktop.org wrote: How could we test a new ddx (sorry to ask but, what's that? :-?) or an udpated mesa without

[Bug 33376] [RADEON:KMS:R600C] screen damage during kde fade-out on logout.

https://bugs.freedesktop.org/show_bug.cgi?id=33376 --- Comment #7 from Thomas Lindroth thomas.lindr...@gmail.com 2012-01-25 10:39:33 PST --- I think this problem was fixed in a recent update. I've been experiencing it for a long time but not any longer. The fix probably went in some time during

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #40 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 10:41:38 PST --- bugzilla-dae...@freedesktop.org wrote: Thanks! But... ... the use runs wheezy which I guess includes an updated version of the packages (btw, what are the

Re: [PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 1:21 PM, Thomas Hellstrom tho...@shipmail.org wrote: On 01/25/2012 07:12 PM, Dave Airlie wrote: On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstromtho...@shipmail.org  wrote: On 01/25/2012 04:37 PM, Jerome Glisse wrote: On Wed, Jan 25, 2012 at 10:21 AM, Ben

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #41 from Camaleón noela...@gmail.com 2012-01-25 10:56:22 PST --- (In reply to comment #40) Mesa is libgl1-mesa-dri and libgl1-mesa-glx. The DDX driver is[1] xserver-xorg-video-radeon and libdrm-radeon1, I suppose. One can get

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #42 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 10:57:27 PST --- Jonathan Nieder wrote: One can get fairly recent versions of most packages from sid or experimental.

[git pull] drm fixes

Hi Linus, bunch of regression fixes since TTM rework and radeon initialisation, modesetting fixes for Alex to fix some black screens on kms start type issues, and two radeon ACPI fixes that make some laptops no oops on startup. I think Intel have some -fixes coming soon which I'll send in a

Re: [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

On Wed, Jan 25, 2012 at 06:02:41PM +0100, Tomasz Stanislawski wrote: Hi Sumit, On 12/26/2011 10:23 AM, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer

[PULL] drm-intel-fixes

A bunch of patches which fix IVB-specific troubles: * A selection of code which was labeled for SNB, but needs to be run on IVB as well. * A replacement for the quick-hack IVB lost-IRQ issue. This appears to help on SNB as well, but for now it's only enabled on IVB in case we

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #43 from Jonathan Nieder jrnie...@gmail.com 2012-01-25 12:39:49 PST --- bugzilla-dae...@freedesktop.org wrote: I have finally to surrender. If anyone thinks on anything we can try, you can contact directly to me or add the

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

On Wed, 25 Jan 2012 08:16:25 -0800 Keith Packard kei...@keithp.com wrote: It is never correct to use intel_crtc-bpp in intel_dp_link_required, so instead pass an explicit bpp in to this function. This patch only supports 18bpp and 24bpp modes, which means that 10bpc modes will be computed

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Yeah, looks like I got this wrong when I added the pipe bpp field. Wonder if there's a good way to catch this sort of bug with an assert so we don't get the order mixed up again... Ideally, we'd figure out a way

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

On Wed, Jan 25, 2012 at 01:17:51PM -0800, Keith Packard wrote: On Wed, 25 Jan 2012 12:51:16 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Yeah, looks like I got this wrong when I added the pipe bpp field. Wonder if there's a good way to catch this sort of bug with an assert so we

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

On Wed, Jan 25, 2012 at 08:16:25AM -0800, Keith Packard wrote: It is never correct to use intel_crtc-bpp in intel_dp_link_required, so instead pass an explicit bpp in to this function. This patch only supports 18bpp and 24bpp modes, which means that 10bpc modes will be computed incorrectly.

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Select DP BPC at mode set, rather than mode validate

On Wed, Jan 25, 2012 at 08:16:26AM -0800, Keith Packard wrote: The DP configuration must match the pipe configuration, and until mode set we don't know what BPC will be used. Delay all decisions about BPC until mode set, computing the target BPC in both intel_dp_mode_fixup and either

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

On Wed, 25 Jan 2012 22:50:55 +0100, Daniel Vetter dan...@ffwll.ch wrote: I think we could compute this in crtc-mode_fixup (crtc-prepare doesn't have the mode and adjusted_mode arguments). We could then store the computed bpc and dithering in one of the private fields. We'd still have to loop

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Select DP BPC at mode set, rather than mode validate

On Wed, 25 Jan 2012 23:11:00 +0100, Daniel Vetter dan...@ffwll.ch wrote: I'm a bit unhappy how generic code in intel_display.c calls function out of intel_dp.c. And choose_pipe_bpp_dither already has special cases for quite a few other encoders ... Could we add an -adjust_bpc function to

Re: [git pull] drm fixes

On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie airl...@linux.ie wrote: bunch of regression fixes since TTM rework and radeon initialisation, modesetting fixes for Alex to fix some black screens on kms start type issues, and two radeon ACPI fixes that make some laptops no oops on startup. Does

Re: [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

On Thu, Jan 26, 2012 at 1:37 AM, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Jan 25, 2012 at 06:02:41PM +0100, Tomasz Stanislawski wrote: Hi Sumit, On 12/26/2011 10:23 AM, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. [snip] +struct sg_table

Re: [git pull] drm fixes

On Wed, Jan 25, 2012 at 6:31 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Jan 25, 2012 at 11:05 AM, Dave Airlie airl...@linux.ie wrote: bunch of regression fixes since TTM rework and radeon initialisation, modesetting fixes for Alex to fix some black screens on kms start

Re: [git pull] drm fixes

bunch of regression fixes since TTM rework and radeon initialisation, modesetting fixes for Alex to fix some black screens on kms start type issues, and two radeon ACPI fixes that make some laptops no oops on startup. Does that include for the nvidia (?) suspend/resume issue? You were

[Bug 33376] [RADEON:KMS:R600C] screen damage during kde fade-out on logout.

https://bugs.freedesktop.org/show_bug.cgi?id=33376 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #44 from Camaleón noela...@gmail.com 2012-01-25 23:41:02 PST --- (In reply to comment #42) Ok, just to fill in the blanks: was this a regression? Was there a kernel or X or GNOME upgrade before which the system worked fine and

[PATCH] drm/radeon/kms: add support for streamout v4

Sorry Jerome, I didn't have time to properly finish the patch and update the CS checker properly. Also evergreen_cs_track_check has been a no-op for a long time and this patch doesn't make it any more exploitable. Marek On Wed, Jan 25, 2012 at 12:43 AM, Jerome Glisse wrote: > On Tue, Jan 24,

[PATCH 1/2] omap2+: add drm device

On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark wrote: > On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras > wrote: >> On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark wrote: >>> On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras >>> wrote: On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark wrote: > On

[PATCH] drm/ttm: fix two regressions since move_notify changes

From: Ben Skeggs Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was originally able to presume that bo->mem is the old node, and new_mem is the new node. The above commit moves the call to

[PATCH] dma-buf: Use EXPORT_SYMBOL

On Sat, Jan 21, 2012 at 11:02 PM, Daniel Vetter wrote: > On Fri, Jan 20, 2012 at 10:04:57AM -0800, Robert Morell wrote: >> On Wed, Jan 18, 2012 at 01:10:04AM -0800, Semwal, Sumit wrote: >> > On Wed, Jan 18, 2012 at 5:38 AM, Robert Morell >> > wrote: >> > > EXPORT_SYMBOL_GPL is intended to be

[PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 06:34 AM, Ben Skeggs wrote: > From: Ben Skeggs > > Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious > regressions in the nouveau driver. > > move_notify() was originally able to presume that bo->mem is the old node, > and new_mem is the new node. The above

[PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote: > On 01/25/2012 06:34 AM, Ben Skeggs wrote: > > From: Ben Skeggs > > > > Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious > > regressions in the nouveau driver. > > > > move_notify() was originally able to presume

[PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs wrote: > From: Ben Skeggs > > Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious > regressions in the nouveau driver. > > move_notify() was originally able to presume that bo->mem is the old node, > and new_mem is the new node. ?The

[PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, 2012-01-25 at 08:24 +, Dave Airlie wrote: > On Wed, Jan 25, 2012 at 5:34 AM, Ben Skeggs wrote: > > From: Ben Skeggs > > > > Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious > > regressions in the nouveau driver. > > > > move_notify() was originally able to

[PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 09:05 AM, Ben Skeggs wrote: > On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote: >> On 01/25/2012 06:34 AM, Ben Skeggs wrote: >>> From: Ben Skeggs >>> >>> Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious >>> regressions in the nouveau driver. >>> >>>

[Bug 44919] Wayland clients segfault

https://bugs.freedesktop.org/show_bug.cgi?id=44919 Benjamin Franzke changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, 2012-01-25 at 09:39 +0100, Thomas Hellstrom wrote: > On 01/25/2012 09:05 AM, Ben Skeggs wrote: > > On Wed, 2012-01-25 at 08:43 +0100, Thomas Hellstrom wrote: > >> On 01/25/2012 06:34 AM, Ben Skeggs wrote: > >>> From: Ben Skeggs > >>> > >>> Both changes in

[next] Null pointer dereference in nouveau_vm_map_sg

On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse wrote: > Can you please both test if attached patch fix it for you ? Thanks. It looks good too me, but it crashes a little later due to vma->node being invalid: Jan 25 00:54:21 callisto kernel: [ 119.038357] [drm] nouveau_vm_unmap vma

[PATCH] dma-buf: Use EXPORT_SYMBOL

> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed > symbols can be used by the binary blobs, possibly with an open-sourced > shim which provides the buffer-sharing interface to the binary blobs? > Are there any reasons to not consider this approach? The GPL requires all the

[PATCH 1/2] omap2+: add drm device

On Tue, Jan 24, 2012 at 8:32 PM, Rob Clark wrote: > On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras > wrote: >> On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark wrote: >>> On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras >>> wrote: On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark wrote:

[Linaro-mm-sig] [PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

On Fri, Jan 20, 2012 at 6:53 PM, Laurent Pinchart wrote: > Hi Summit, > > Sorry for the late review. I know that this code is now in mainline, but I > still have a couple of comments. I'll send patches if you agree with them. Hi Laurent, Thanks for your review; apologies for being late in

[PATCH] dma-buf: Use EXPORT_SYMBOL

Em 25-01-2012 10:30, Alan Cox escreveu: >> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed >> symbols can be used by the binary blobs, possibly with an open-sourced >> shim which provides the buffer-sharing interface to the binary blobs? >> Are there any reasons to not consider

[PATCH] dma-buf: Use EXPORT_SYMBOL

Em 25-01-2012 11:46, Mauro Carvalho Chehab escreveu: > Em 25-01-2012 10:30, Alan Cox escreveu: >>> Technically speaking, is there no way that the EXPORT_SYMBOL_GPLed >>> symbols can be used by the binary blobs, possibly with an open-sourced >>> shim which provides the buffer-sharing interface to

[PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 10:41 AM, Ben Skeggs wrote: > > My main concern is that we blindly and unnecessarily set up GPU bindings and > end up with unnecessary code in TTM, and furthermore that we communicate > that bad practice to future driver writers. > This "unnecessary code" is like 5 lines of cleanup

[PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs wrote: > On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: >> On 01/25/2012 10:41 AM, Ben Skeggs wrote: >> > >> > My main concern is that we blindly and unnecessarily set up GPU bindings >> > and >> > end up with unnecessary code in TTM, and

[PATCH 1/2] drm/i915: Force explicit bpp selection for intel_dp_link_required

It is never correct to use intel_crtc->bpp in intel_dp_link_required, so instead pass an explicit bpp in to this function. This patch only supports 18bpp and 24bpp modes, which means that 10bpc modes will be computed incorrectly. Fixing that will require more extensive changes, and so must be

[PATCH 2/2] drm/i915: Select DP BPC at mode set, rather than mode validate

The DP configuration must match the pipe configuration, and until mode set we don't know what BPC will be used. Delay all decisions about BPC until mode set, computing the target BPC in both intel_dp_mode_fixup and either i9xx_crtc_mode_set or ironlake_crtc_mode_set. It might be slightly better to

[PATCH 0/2] drm/i915: Use correct bpc computations for DisplayPort

Here's a couple of patches that fix some bpc (bits per component) computation issues with DisplayPort. The problem was that the DisplayPort code tried to figure out the 'current' bpc by looking at the bpp stored in an associated crtc, but that was never right (as described in the message for the

[next] Null pointer dereference in nouveau_vm_map_sg

On Tue, Jan 24, 2012 at 7:12 PM, Martin Nyhus wrote: > On Tue, 24 Jan 2012 17:33:19 -0500 Jerome Glisse > wrote: >> Can you please both test if attached patch fix it for you ? > > Thanks. It looks good too me, but it crashes a little later due to vma->node > being invalid: > > Jan 25 00:54:21

[PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 04:37 PM, Jerome Glisse wrote: > On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs wrote: >> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: >>> On 01/25/2012 10:41 AM, Ben Skeggs wrote: My main concern is that we blindly and unnecessarily set up GPU bindings and

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #33 from Camale?n 2012-01-25 09:16:12 PST --- (In reply to comment #32) > (In reply to comment #31) > > bugzilla-daemon at freedesktop.org wrote: > > > > > The user reported that system crashed after a while. > > > > Interesting

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #34 from Camale?n 2012-01-25 09:17:55 PST --- Created attachment 56153 --> https://bugs.freedesktop.org/attachment.cgi?id=56153 Syslog with "drm.debug=6" + call trace -- Configure bugmail:

[PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 04:37 PM, Jerome Glisse wrote: > On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs wrote: >> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: >>> On 01/25/2012 10:41 AM, Ben Skeggs wrote: My main concern is that we blindly and unnecessarily set up GPU bindings and

[PATCH] drm: Fix authentication kernel crash

On 01/24/2012 03:47 PM, Daniel Vetter wrote: > On Tue, Jan 24, 2012 at 10:31:46AM +0100, Thomas Hellstrom wrote: >> If the master tries to authenticate a client using drm_authmagic and >> that client has already closed its drm file descriptor, >> either wilfully or because it was terminated, the

[PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 06:34 AM, Ben Skeggs wrote: > From: Ben Skeggs > > Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious > regressions in the nouveau driver. > > move_notify() was originally able to presume that bo->mem is the old node, > and new_mem is the new node. The above

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #35 from Jonathan Nieder 2012-01-25 09:37:29 PST --- bugzilla-daemon at freedesktop.org wrote: > Syslog with "drm.debug=6" + call trace Summary follows. Log is from 25 January. 15:55 bootup 15:55 [after 22 seconds] drm driver

[PATCH 1/3] dma-buf: Introduce dma buffer sharing mechanism

Hi Sumit, On 12/26/2011 10:23 AM, Sumit Semwal wrote: > This is the first step in defining a dma buffer sharing mechanism. > > A new buffer object dma_buf is added, with operations and API to allow easy > sharing of this buffer object across devices. > > The framework allows: > - creation of a

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #36 from Alex Deucher 2012-01-25 09:54:47 PST --- It's a GPU lockup. Unfortunately, they tend to be really hard to track down. You might try a newer ddx or mesa. -- Configure bugmail:

[Bug 45018] [bisected] rendering regression since added support for virtual address space on cayman v11

https://bugs.freedesktop.org/show_bug.cgi?id=45018 Alexandre Demers changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #37 from Camale?n 2012-01-25 10:10:06 PST --- (In reply to comment #36) > It's a GPU lockup. Unfortunately, they tend to be really hard to track down. > You might try a newer ddx or mesa. We're open to test anything, whatever...

[PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom wrote: > On 01/25/2012 04:37 PM, Jerome Glisse wrote: >> >> On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs ?wrote: >>> >>> On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: On 01/25/2012 10:41 AM, Ben Skeggs wrote: > > My

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #38 from Jonathan Nieder 2012-01-25 10:17:22 PST --- bugzilla-daemon at freedesktop.org wrote: > How could we test a new ddx (sorry to ask but, what's that? :-?) or an udpated > mesa without breaking many things?

[RFC] Future TTM DMA direction

OK, revisiting this again, please see inline below, On 01/10/2012 06:46 PM, Jerome Glisse wrote: > On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote: >> On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: >>> Hi! >>> >>> When TTM was originally written, it was assumed

[PATCH] drm/ttm: fix two regressions since move_notify changes

On 01/25/2012 07:12 PM, Dave Airlie wrote: > On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom > wrote: >> On 01/25/2012 04:37 PM, Jerome Glisse wrote: >>> On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggswrote: On Wed, 2012-01-25 at 15:33 +0100, Thomas Hellstrom wrote: > On 01/25/2012

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #39 from Camale?n 2012-01-25 10:35:48 PST --- (In reply to comment #38) > bugzilla-daemon at freedesktop.org wrote: > > > How could we test a new ddx (sorry to ask but, what's that? :-?) or an > > udpated > > mesa without breaking

[Bug 33376] [RADEON:KMS:R600C] screen damage during kde fade-out on logout.

https://bugs.freedesktop.org/show_bug.cgi?id=33376 --- Comment #7 from Thomas Lindroth 2012-01-25 10:39:33 PST --- I think this problem was fixed in a recent update. I've been experiencing it for a long time but not any longer. The fix probably went in some time during the past few months. --

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

https://bugs.freedesktop.org/show_bug.cgi?id=43835 --- Comment #40 from Jonathan Nieder 2012-01-25 10:41:38 PST --- bugzilla-daemon at freedesktop.org wrote: > Thanks! But... ... the use runs "wheezy" which I guess includes an updated > version of the packages (btw, what are the packages

[PATCH] drm/ttm: fix two regressions since move_notify changes

On Wed, Jan 25, 2012 at 1:21 PM, Thomas Hellstrom wrote: > On 01/25/2012 07:12 PM, Dave Airlie wrote: >> >> On Wed, Jan 25, 2012 at 5:19 PM, Thomas Hellstrom >> ?wrote: >>> >>> On 01/25/2012 04:37 PM, Jerome Glisse wrote: On Wed, Jan 25, 2012 at 10:21 AM, Ben Skeggs ?wrote: >

  1   2   >