[RFC v3 0/2] Introduce DMA buffer sharing mechanism

Hello Everyone, This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU.

[RFC v3 0/2] Introduce DMA buffer sharing mechanism

Hello Everyone, This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU.

[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

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: - different devices to 'attach' themselves to this buffer, to facilitate backing

[RFC v3 2/2] dma-buf: Documentation for buffer sharing framework

Add documentation for dma buffer sharing framework, explaining the various operations, members and API of the dma buffer sharing framework. Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- Documentation/dma-buf-sharing.txt | 222

allow drivers to fix kexec bus mastering hole

kexec relies on disabling bus mastering on PCI devices to block wayward DMAs left set by the previous kernel. However the drm midlayer was enabling bus mastering for all PCI drivers before calling into them. This meant no matter what they did, there was always going to be a small race window. The

[PATCH 1/2] drm: move pci bus master enable into driver.

From: Dave Airlie airl...@redhat.com The current enabling of bus mastering in the drm midlayer allows a large race condition under kexec. When a kexec'ed kernel re-enables bus mastering for the GPU, previously setup dma blocks may cause writes to random pieces of memory. On radeon the writeback

[PATCH 2/2] drm/radeon/kms: move pci bus master enable further into driver.

From: Dave Airlie airl...@redhat.com This doesn't completely close the kexec hole for all drivers, but it fixes it for some cases, by enabling PCI bus mastering later. Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/radeon/evergreen.c |2 ++ drivers/gpu/drm/radeon/ni.c

[git pull] vmware fixes

Hi Linus, These are just vmware fixes, Thomas sent them a couple of weeks back and my brain misparsed them, they are all crucial correctness fixes for vmwgfx and I really should have sent them on earlier. Thanks, Dave. The following changes since commit

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883 --- Comment #2 from Alex Deucher ag...@yahoo.com 2011-12-19 06:39:32 PST --- Thread for reference: http://lists.freedesktop.org/archives/mesa-dev/2011-November/015286.html -- Configure bugmail:

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added AssignedTo|xorg-driver-...@lists.x.org

Re: [PATCH] drm_edid: support CEA video modes

On Tue, Dec 13, 2011 at 5:47 PM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Sun, 13 Nov 2011 01:31:35 +0100 Christian Schmidt schm...@digadd.de wrote: TFT/plasma televisions and projectors have become commonplace, and so has the use of PCs to drive them. Add the video modes specified by

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #11 from Michel Dänzer mic...@daenzer.net 2011-12-19 07:09:11 PST --- Created attachment 54573 -- https://bugs.freedesktop.org/attachment.cgi?id=54573 Use mdelay instead of msleep Does this patch fix the hang when switching back

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883 --- Comment #3 from Stefan kde...@vogtner.de 2011-12-19 07:17:37 PST --- (In reply to comment #2) Mesa Works again. Thx. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because:

[Bug 43861] Build error in Mesa with llvm = r145623

https://bugs.freedesktop.org/show_bug.cgi?id=43861 --- Comment #3 from Michel Dänzer mic...@daenzer.net 2011-12-19 07:21:05 PST --- I'd still argue it's not our bug, strictly speaking: llvm-config should only expose compiler flags absolutely necessary for building against LLVM, such as -I...

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #12 from Drago drago.iva...@gmail.com 2011-12-19 07:39:11 PST --- Thanks, I will test this, but it may take some time for MCE to happen again. I will report with the result here. -- Configure bugmail:

DVI/VGA/HDI mess on Radeon HD 6570

Hi, about two months ago I bought a Radeon HD 6570 with 2GB memory for my main computer and I have a single monitor connected to it, until now via VGA D-Sub. Last week our secondary TV died (it was 15 years old, R.I.P.) so I bought a nice 32 LED TV which has 3 external HDMI connectors. The HD

Re: DVI/VGA/HDI mess on Radeon HD 6570

about two months ago I bought a Radeon HD 6570 with 2GB memory for my main computer and I have a single monitor connected to it, until now via VGA D-Sub. Last week our secondary TV died (it was 15 years old, R.I.P.) so I bought a nice 32 LED TV which has 3 external HDMI connectors.

Re: DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:14 keltezéssel, David Airlie írta: about two months ago I bought a Radeon HD 6570 with 2GB memory for my main computer and I have a single monitor connected to it, until now via VGA D-Sub. Last week our secondary TV died (it was 15 years old, R.I.P.) so I bought a nice 32 LED

Re: DVI/VGA/HDI mess on Radeon HD 6570

On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote: Thanks. Is this setting permanent after reboot and applies to GDM, too? It's stored in the session, so if there's not a Make system default button in the UI, then no it won't affect gdm. - ajax signature.asc Description: This is a

Re: DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:42 keltezéssel, Adam Jackson írta: On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote: Thanks. Is this setting permanent after reboot and applies to GDM, too? It's stored in the session, so if there's not a Make system default button in the UI, then no it won't affect

Re: DVI/VGA/HDI mess on Radeon HD 6570

On Mon, 2011-12-19 at 18:56 +0100, Boszormenyi Zoltan wrote: Thanks. As I am logged in as my user, there's no such button. How can I set it as the system default? It was a long time ago when GNOME allowed a root login. Ideally, gnome would implement that button. Failing that you can set

Re: [PATCH] fixes to drm-next - TTM DMA code (v1)

On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote: On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote: On 12/13/2011 05:07 PM, Jerome Glisse wrote: On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: Jerome pointed me to some accounting

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

https://bugs.freedesktop.org/show_bug.cgi?id=43858 Valter valter.giovanne...@alice.it changed: What|Removed |Added Severity|normal |critical --

[PATCH 01/12] drm: Add a missing ')'

From: Ville Syrjälä ville.syrj...@linux.intel.com The code happened to compile because the flag wasn't actually used yet. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- include/drm/drm_mode.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

[PATCH 04/12] drm: plane: mutex_unlock() was missing

From: Ville Syrjälä ville.syrj...@linux.intel.com Unlock the mode_config mutex if drm_plane_init() fails. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH 05/12] drm: Fix __user sparse warnings

From: Ville Syrjälä ville.syrj...@linux.intel.com Several pointers and casts were missing __user annotations. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc.c | 30 +++--- 1 files changed, 15 insertions(+), 15 deletions(-) diff

[PATCH 06/12] drm: plane: Clear plane.crtc and plane.fb after disable_plane()

From: Ville Syrjälä ville.syrj...@linux.intel.com These are the only indication to user space that the plane was disabled. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com Acked-by: Jesse Barnes jbar...@virtuousgeek.org --- drivers/gpu/drm/drm_crtc.c |2 ++ 1 files changed, 2

[PATCH 07/12] drm: plane: Check source coordinates

From: Ville Syrjälä ville.syrj...@linux.intel.com Make sure the source coordinates stay within the buffer. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc.c | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git

Rebased drm_plane patches

I rebased this set on top of drm-next. I updated some of the error values based on what Jesse suggested. I also added a few patches to fix various issues that came up since I last posted the patches. Since the patch to drop the planar formats with YVU plane order wasn't applied to drm-next, I

[PATCH 02/12] drm: Install drm_fourcc.h

From: Ville Syrjälä ville.syrj...@linux.intel.com Userspace needs this header. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- include/drm/Kbuild |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/drm/Kbuild b/include/drm/Kbuild index

[PATCH 03/12] drm: fourcc: Use __u32 instead of u32

From: Ville Syrjälä ville.syrj...@linux.intel.com drm_fourcc.h can be included from user space so use the appropriate types. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- include/drm/drm_fourcc.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 08/12] drm: plane: Check crtc coordinates against integer overflows in setplane ioctl

From: Ville Syrjälä ville.syrj...@linux.intel.com Help drivers a little by guaranteeing that crtc_x+crtc_w and crtc_y+crtc_h don't overflow. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc.c | 12 1 files changed, 12 insertions(+), 0

[PATCH 09/12] drm: plane: Make 'formats' parameter to drm_plane_init() const

From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc.c |2 +- include/drm/drm_crtc.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH 10/12] drm: plane: Check that the fb pixel format is supported by the plane

From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc.c | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index

[PATCH 11/12] drm: Check that the requested pixel format is valid

From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc.c | 75 1 files changed, 75 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c

[PATCH 12/12] drm: Replace pitch with pitches[] in drm_framebuffer

From: Ville Syrjälä ville.syrj...@linux.intel.com Otherwise each driver would need to keep the information inside their own framebuffer object structure. Also add offsets[]. BOs on the other hand are driver specific, so those can be kept in driver specific structures. Signed-off-by: Ville

Plane helpers and a new plane options ioctl

Here are the utility functions again. Rebased and updated slightly. I adapted drm_framebuffer_check() to handle multiple handles, and I changed some of the error values it returns. The plane options ioctl is a bit of an open question. I started by adding separate ioctls for some subsets of the

[RFC PATCH 1/8] drm: Add drm_format_num_planes() utility function

From: Ville Syrjälä ville.syrj...@linux.intel.com This function returns the number of planes used by a specific pixel format. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc_helper.c | 33 + include/drm/drm_crtc_helper.h

[RFC PATCH 4/8] drm: Add drm_framebuffer_check() utility function

From: Ville Syrjälä ville.syrj...@linux.intel.com This function performs a battery of sanity checks on the requested framebuffer layout. Drivers can call it from their fb_create hook. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc_helper.c | 85

[RFC PATCH 6/8] drm: Add drm_calc_{hscale, vscale}() utility functions

From: Ville Syrjälä ville.syrj...@linux.intel.com Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc_helper.c | 102 + include/drm/drm_crtc_helper.h |4 ++ 2 files changed, 106 insertions(+), 0 deletions(-) diff

[RFC PATCH 7/8] drm: plane: Add plane options ioctl

From: Ville Syrjälä ville.syrj...@linux.intel.com Add a new ioctl DRM_IOCTL_MODE_PLANE_OPTS which is used to configure various settings for the plane. I left out gamma correction thinking that it could be added using a separate ioctl, since there's already a gamma ioctl for CRTCs.

[RFC PATCH 5/8] drm: Add struct drm_region and assorted utility functions

From: Ville Syrjälä ville.syrj...@linux.intel.com struct drm_region represents a two dimensional region. The utility functions are there to help driver writers. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc_helper.c | 156

[RFC PATCH 8/8] drm: Add drm_chroma_phase_offsets() utility function

From: Ville Syrjälä ville.syrj...@linux.intel.com This function is is there to help driver writers. Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com --- drivers/gpu/drm/drm_crtc_helper.c | 47 + include/drm/drm_crtc_helper.h |3 ++ 2 files

[Bug 43964] A script fail to build in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964 Laurent carlier lordhea...@gmail.com changed: What|Removed |Added AssignedTo|i...@freedesktop.org

high_memory address in /proc/dri/*/vma

[Re-sent to the right address, I hope.] Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not leak kernel addresses via /proc/dri/*/vma) you changed the logging of high_memory: - seq_printf(m, vma use count: %d, high_memory = %p, 0x%08llx\n, + seq_printf(m, vma use

Re: high_memory address in /proc/dri/*/vma

On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote: On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote: Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not leak kernel addresses via /proc/dri/*/vma) you changed the logging of high_memory: -

[Bug 43771] [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap: Assertion `img_filter == 1' failed.

https://bugs.freedesktop.org/show_bug.cgi?id=43771 Stephane Marchesin marche...@icps.u-strasbg.fr changed: What|Removed |Added Status|NEW |RESOLVED

Re: high_memory address in /proc/dri/*/vma

On Mon, 2011-12-19 at 18:35 -0800, Kees Cook wrote: On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote: On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote: Kees, in commit

Re: high_memory address in /proc/dri/*/vma

On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote: Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not leak kernel addresses via /proc/dri/*/vma) you changed the logging of high_memory: -       seq_printf(m, vma use count: %d, high_memory = %p,

Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote: On Monday 12 December 2011, Robert Morell wrote: Doing a buffer sharing with something that is not GPL is not fun, as, if any issue rises there, it would be impossible to discover if the problem is either at the

Re: high_memory address in /proc/dri/*/vma

On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings b...@decadent.org.uk wrote: On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote: On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings b...@decadent.org.uk wrote: Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 (drm: do not leak kernel

high_memory address in /proc/dri/*/vma

gs; they are rationalising beings. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 828 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111219/11639bef/attachment.pgp>

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622 --- Comment #3 from Scott Moreau 2011-12-18 21:43:34 PST --- Created attachment 54566 --> https://bugs.freedesktop.org/attachment.cgi?id=54566 patch I went ahead and bisected mesa. Here's what I came up with:

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622 --- Comment #4 from Scott Moreau 2011-12-18 21:48:12 PST --- (In reply to comment #2) > Which kernel version do you have? I've tested on 2.6.38 and 3.0.0 both 32bit. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

Hi Arnd, Daniel, On Mon, Dec 12, 2011 at 10:18 PM, Arnd Bergmann wrote: > On Saturday 10 December 2011, Daniel Vetter wrote: >> If userspace (through some driver calls) >> tries to do stupid things, it'll just get garbage. See >> Message-ID: > mail.gmail.com> >> for my reasons why it think this

[RFC v3 0/2] Introduce DMA buffer sharing mechanism

Hello Everyone, This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU.

[RFC v3 0/2] Introduce DMA buffer sharing mechanism

Hello Everyone, This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU.

[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism

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: - different devices to 'attach' themselves to this buffer, to facilitate backing

[RFC v3 2/2] dma-buf: Documentation for buffer sharing framework

Add documentation for dma buffer sharing framework, explaining the various operations, members and API of the dma buffer sharing framework. Signed-off-by: Sumit Semwal Signed-off-by: Sumit Semwal --- Documentation/dma-buf-sharing.txt | 222 + 1 files

allow drivers to fix kexec bus mastering hole

kexec relies on disabling bus mastering on PCI devices to block wayward DMAs left set by the previous kernel. However the drm midlayer was enabling bus mastering for all PCI drivers before calling into them. This meant no matter what they did, there was always going to be a small race window. The

[PATCH 1/2] drm: move pci bus master enable into driver.

From: Dave Airlie The current enabling of bus mastering in the drm midlayer allows a large race condition under kexec. When a kexec'ed kernel re-enables bus mastering for the GPU, previously setup dma blocks may cause writes to random pieces of memory. On radeon the writeback

[PATCH 2/2] drm/radeon/kms: move pci bus master enable further into driver.

From: Dave Airlie This doesn't completely close the kexec hole for all drivers, but it fixes it for some cases, by enabling PCI bus mastering later. Signed-off-by: Dave Airlie --- drivers/gpu/drm/radeon/evergreen.c |2 ++ drivers/gpu/drm/radeon/ni.c |2 ++

[git pull] vmware fixes

Hi Linus, These are just vmware fixes, Thomas sent them a couple of weeks back and my brain misparsed them, they are all crucial correctness fixes for vmwgfx and I really should have sent them on earlier. Thanks, Dave. The following changes since commit

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883 --- Comment #2 from Alex Deucher 2011-12-19 06:39:32 PST --- Thread for reference: http://lists.freedesktop.org/archives/mesa-dev/2011-November/015286.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941 Michel D?nzer changed: What|Removed |Added AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop

[PATCH] drm_edid: support CEA video modes

On Tue, Dec 13, 2011 at 5:47 PM, Jesse Barnes wrote: > On Sun, 13 Nov 2011 01:31:35 +0100 > Christian Schmidt wrote: > >> TFT/plasma televisions and projectors have become commonplace, and so >> has the use of PCs to drive them. Add the video modes specified by an >> EDID's CEA extension to the

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #11 from Michel D?nzer 2011-12-19 07:09:11 PST --- Created attachment 54573 --> https://bugs.freedesktop.org/attachment.cgi?id=54573 Use mdelay instead of msleep Does this patch fix the hang when switching back to console after

[Bug 42883] Firefox crashes in state_tracker/st_cb_blit.c:87

https://bugs.freedesktop.org/show_bug.cgi?id=42883 --- Comment #3 from Stefan 2011-12-19 07:17:37 PST --- (In reply to comment #2) Mesa Works again. Thx. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the

[Bug 43861] Build error in Mesa with llvm >= r145623

https://bugs.freedesktop.org/show_bug.cgi?id=43861 --- Comment #3 from Michel D?nzer 2011-12-19 07:21:05 PST --- I'd still argue it's not our bug, strictly speaking: llvm-config should only expose compiler flags absolutely necessary for building against LLVM, such as -I<...> -D<...>, certainly

[Bug 43941] 'BUG: scheduling while atomic' after: 'panic occurred, switching back to text console'

https://bugs.freedesktop.org/show_bug.cgi?id=43941 --- Comment #12 from Drago 2011-12-19 07:39:11 PST --- Thanks, I will test this, but it may take some time for MCE to happen again. I will report with the result here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[PATCH 2/2] drm/radeon/kms: move pci bus master enable further into driver.

On Mon, Dec 19, 2011 at 9:16 AM, Dave Airlie wrote: > From: Dave Airlie > > This doesn't completely close the kexec hole for all drivers, but it fixes > it for some cases, by enabling PCI bus mastering later. > > Signed-off-by: Dave Airlie > --- > ?drivers/gpu/drm/radeon/evergreen.c ?| ? ?2 ++

DVI/VGA/HDI mess on Radeon HD 6570

Hi, about two months ago I bought a Radeon HD 6570 with 2GB memory for my main computer and I have a single monitor connected to it, until now via VGA D-Sub. Last week our secondary TV died (it was 15 years old, R.I.P.) so I bought a nice 32" LED TV which has 3 external HDMI connectors. The HD

DVI/VGA/HDI mess on Radeon HD 6570

> > about two months ago I bought a Radeon HD 6570 with > 2GB memory for my main computer and I have a single > monitor connected to it, until now via VGA D-Sub. > > Last week our secondary TV died (it was 15 years old, R.I.P.) > so I bought a nice 32" LED TV which has 3 external HDMI >

DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:14 keltez?ssel, David Airlie ?rta: >> about two months ago I bought a Radeon HD 6570 with >> 2GB memory for my main computer and I have a single >> monitor connected to it, until now via VGA D-Sub. >> >> Last week our secondary TV died (it was 15 years old, R.I.P.) >> so I bought a

DVI/VGA/HDI mess on Radeon HD 6570

-- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111219/3d77ea5a/attachment.pgp>

DVI/VGA/HDI mess on Radeon HD 6570

2011-12-19 18:42 keltez?ssel, Adam Jackson ?rta: > On Mon, 2011-12-19 at 18:19 +0100, Boszormenyi Zoltan wrote: > >> Thanks. >> Is this setting permanent after reboot and applies to GDM, too? > It's stored in the session, so if there's not a "Make system default" > button in the UI, then no it

[Bug 43954] New: Some textures are not correctly rendered on HD 6950

https://bugs.freedesktop.org/show_bug.cgi?id=43954 Bug #: 43954 Summary: Some textures are not correctly rendered on HD 6950 Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All)

DVI/VGA/HDI mess on Radeon HD 6570

ge part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111219/4f62497b/attachment.pgp>

[PATCH] fixes to drm-next - TTM DMA code (v1)

On 12/13/2011 05:40 PM, Konrad Rzeszutek Wilk wrote: > On Tue, Dec 13, 2011 at 05:23:30PM +0100, Thomas Hellstrom wrote: > >> On 12/13/2011 05:07 PM, Jerome Glisse wrote: >> >>> On Mon, Dec 12, 2011 at 03:09:26PM -0500, Konrad Rzeszutek Wilk wrote: >>> Jerome pointed me to

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

https://bugs.freedesktop.org/show_bug.cgi?id=43858 Valter changed: What|Removed |Added Severity|normal |critical -- Configure bugmail:

[Bug 43964] A script fail to build in Penumbra Overture game

https://bugs.freedesktop.org/show_bug.cgi?id=43964 Laurent carlier changed: What|Removed |Added AssignedTo|idr at freedesktop.org |dri-devel at lists.freedesktop

high_memory address in /proc/dri/*/vma

On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings wrote: > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not > leak kernel addresses via /proc/dri/*/vma") you changed the logging of > high_memory: > > - ? ? ? seq_printf(m, "vma use count: %d, high_memory = %p, 0x%08llx\n", > + ?

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote: > On Monday 12 December 2011, Robert Morell wrote: > > > > > > Doing a buffer sharing with something that is not GPL is not fun, as, if > > > any > > > issue rises there, it would be impossible to discover if the problem is > > >

high_memory address in /proc/dri/*/vma

On Mon, Dec 19, 2011 at 6:18 PM, Ben Hutchings wrote: > On Mon, 2011-12-19 at 16:14 -0800, Kees Cook wrote: >> On Mon, Dec 19, 2011 at 4:09 PM, Ben Hutchings >> wrote: >> > Kees, in commit 01e2f533a234dc62d16c0d3d4fb9d71cf1ce50c3 ("drm: do not >> > leak kernel addresses via /proc/dri/*/vma")