Re: [V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch

Dear Thomas, your proposal will not lead to a satisfying solution for those people that suffer from monitors and other HW devices that provide wrong EDIDs. Oops, why not? Before fetching the display modes, all drm devices will try to detect the monitor. If EDID data is not correct

[V6 PATCH 0/1] Provide workarounds to use DRM/KMS with broken graphics hardware

Changes from V5 to V6: 1. The use of a particular EDID data set can now be restricted to a given connector using the syntax edid_firmware=[connector:]edid as suggested by Thomas Reim. 2. The patches to introduce a module parameter and a quirk to cope with an inverted brightness variable of

[V6 PATCH 1/1] drivers-gpu-drm-allow-to-load-edid-firmware.patch

Broken monitors and/or broken graphic boards may send erroneous or no EDID data. This also applies to broken KVM devices that are unable to correctly forward the EDID data of the connected monitor but invent their own fantasy data. This patch allows to specify an EDID data set to be used instead

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #6 from Jonathan Nieder jrnie...@gmail.com 2012-03-19 08:44:40 --- udev should cope fine with kernels 2.6.32 iirc as long as CONFIG_SYSFS_DEPRECATED is not set. -- Configure bugmail:

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #7 from Jonathan Nieder jrnie...@gmail.com 2012-03-19 08:54:19 --- The painful memories are coming back to me: udev also requires v2.6.28-rc6~45 (reintroduce accept4) and dup3 and friends from 2.6.27. -- Configure bugmail:

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622 --- Comment #5 from kowalski marcin yoshi...@gmail.com 2012-03-19 02:54:21 PDT --- the problem does not exist anymore on current mesa git and current stable kernel. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622 --- Comment #6 from kowalski marcin yoshi...@gmail.com 2012-03-19 02:56:24 PDT --- i'll try this on another set of hardware soon to make sure. i might have been a bit hasty with that comment. -- Configure bugmail:

[Bug 29842] Radeon runs very hot

https://bugzilla.kernel.org/show_bug.cgi?id=29842 --- Comment #15 from Igor Rudchenko i...@starrain.org 2012-03-19 10:50:43 --- Tested 3.3.0 kernel today and nothing changes. So I look deeper into ASPM registers: Windows XP and Linux kernel prior 2.6.38: root complex 00:01.0 0xB0 ==

Re: [Linaro-mm-sig] [PATCH 4/4] dma-buf: document fd flags and O_CLOEXEC requirement

On Sun, Mar 18, 2012 at 11:34 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: Otherwise subsystems will get this wrong and end up with and second export ioctl with the flag and O_CLOEXEC support added. Its not actually dma_buf_export that takes the O_CLOEXEC flag its dma_buf_fd I'm not sure

Re: [PATCH v2 09/14] drm/exynos: add G2D driver

On Fri, Mar 16, 2012 at 9:47 AM, Inki Dae inki@samsung.com wrote: From: Joonyoung Shim jy0922.s...@samsung.com The G2D is a 2D graphic accelerator that supports Bit Block Transfer. This G2D driver is exynos drm specific and supports only G2D(version 4.1) of later Exynos series from

Re: [PATCH 1/7] drm/radeon/kms: make some DRM errors more informative

On Sun, Mar 18, 2012 at 10:09 PM, Marek Olšák mar...@gmail.com wrote: Signed-off-by: Marek Olšák mar...@gmail.com For the series: Reviewed-by: Alex Deucher alexander.deuc...@amd.com ---  drivers/gpu/drm/radeon/evergreen_cs.c |    8  1 files changed, 4 insertions(+), 4 deletions(-)

[Bug 29842] Radeon runs very hot

https://bugzilla.kernel.org/show_bug.cgi?id=29842 Matthew Garrett mjg59-ker...@srcf.ucam.org changed: What|Removed |Added CC|

Regression: black screen on VGA w/ nouveau in Linux 3.3

Hi folks, Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output on my card w/ nouveau is totally black (both at the console and in X). Almost everything appears to work normally: DPMS works, modesetting works, DDC works... all messages indicate that things are working -- just

Why do flush page cache twice when change TT's cache attribute

In function ttm_tt_set_caching ,,, if (ttm-caching_state == tt_cached) drm_clflush_pages(ttm-pages, ttm-num_pages); for (i = 0; i ttm-num_pages; ++i) { cur_page = ttm-pages[i]; if (likely(cur_page != NULL)) { ret =

Re: [PATCH] drivers/gpu/drm/radeon/radeon_cs.c: eliminate possible double free

On Sat, Mar 17, 2012 at 1:03 PM, Julia Lawall julia.law...@lip6.fr wrote: From: Julia Lawall julia.law...@lip6.fr The function radeon_cs_parser_init is only called from two places, in drivers/gpu/drm/radeon/radeon_cs.c and drivers/gpu/drm/radeon/r600_cs.c. In each case, if the call fails

Re: Why do flush page cache twice when change TT's cache attribute

typo error. abundant=redundant 2012/3/19 Scott Fang donnie.f...@gmail.com In function ttm_tt_set_caching ,,, if (ttm-caching_state == tt_cached) drm_clflush_pages(ttm-pages, ttm-num_pages); for (i = 0; i ttm-num_pages; ++i) { cur_page = ttm-pages[i];

[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement

Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. v2: Fixup the function name and caution exporters to limit the flags to only O_CLOEXEC. Noted by Dave Airlie. Cc: Dave Airlie airl...@gmail.com Signed-Off-by: Daniel Vetter

Re: [PATCH] dma-buf: document fd flags and O_CLOEXEC requirement

On Mon, Mar 19, 2012 at 04:41:55PM +0100, Daniel Vetter wrote: Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. v2: Fixup the function name and caution exporters to limit the flags to only O_CLOEXEC. Noted by Dave

Re: i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

On Sat, 2012-03-17 at 14:14 -0700, Linus Torvalds wrote: On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie airl...@gmail.com wrote: I did however get a flashback in google to this: http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html Linus don't think we ever did work

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 Jérôme Glisse gli...@freedesktop.org changed: What|Removed |Added CC|

[Bug 29842] Radeon runs very hot

https://bugzilla.kernel.org/show_bug.cgi?id=29842 --- Comment #17 from Igor Rudchenko i...@starrain.org 2012-03-19 16:35:11 --- To Matthew Garrett: I agree about network cards, but current situation with video card worries me much. Prior 3.0.20, 3.2.5 and 3.3 kernels, users of ThinkPads T60

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #9 from Alex Deucher alexdeuc...@gmail.com 2012-03-19 16:42:50 --- Created an attachment (id=72654) -- (https://bugzilla.kernel.org/attachment.cgi?id=72654) possible fix Does this patch fix the issue? -- Configure bugmail:

RE: [PATCH] RFC: dma-buf: userspace mmap support

-Original Message- From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] Sent: 17 March 2012 20:17 To: Tom Cooksey Cc: 'Rob Clark'; linaro-mm-...@lists.linaro.org; dri- de...@lists.freedesktop.org; linux-me...@vger.kernel.org; rschu...@google.com; Rob Clark; sumit.sem...@linaro.org;

Re: [PATCH] RFC: dma-buf: userspace mmap support

If the API was to also be used for synchronization it would have to include an atomic prepare multiple ioctl which blocked until all the buffers listed by the application were available. In the same Too slow already. You are now serializing stuff while what we want to do really is

Re: hibernate random memory corruption, workaround i915.modeset=0

On Mon, Feb 27, 2012 at 01:42:43PM +0100, Stanislaw Gruszka wrote: I'm able to reproduce random memory corruption after hibernate. Corruption is not reproducible when I disable mode setting, what seems to blame i915 driver or generic DRM kernel code. I'm able to reproduce bug on Fedora 11

Re: [Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

On 03/19/2012 05:56 PM, Alan Cox wrote: display controller will be reading the front buffer, but the GPU might also need to read that front buffer. So perhaps adding read-only read-write access flags to prepare could also be interpreted as shared exclusive accesses, if we went down this

Re: hibernate random memory corruption, workaround i915.modeset=0

#part sign=pgpmime On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka sgrus...@redhat.com wrote: Keith, is there a chance that this bug can be fixed by i915 team? Yes, I'm working on figuring out how to actually reproduce this and then work on a few work-arounds. If not, can we disable

Re: Why do flush page cache twice when change TT's cache attribute

On Mon, 2012-03-19 at 23:11 +0800, Scott Fang wrote: In function ttm_tt_set_caching ,,, if (ttm-caching_state == tt_cached) drm_clflush_pages(ttm-pages, ttm-num_pages); for (i = 0; i ttm-num_pages; ++i) { cur_page = ttm-pages[i]; if (likely(cur_page

RE: [PATCH] RFC: dma-buf: userspace mmap support

-Original Message- From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] Sent: 19 March 2012 16:57 To: Tom Cooksey Cc: 'Rob Clark'; linaro-mm-...@lists.linaro.org; dri- de...@lists.freedesktop.org; linux-me...@vger.kernel.org; rschu...@google.com; Rob Clark; sumit.sem...@linaro.org;

[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement

From: Rob Clark r...@ti.com Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. Signed-off-by: Rob Clark r...@ti.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- Updated version of Daniel's original documentation

Re: i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

On Sat, 17 Mar 2012, Linus Torvalds wrote: On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins hu...@google.com wrote: I've got to go out for an hour: I'll digest more and think more about this when I get back.  If someone could explain the original problem with _MOVABLE, that would help me:

Re: i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

On Sun, 18 Mar 2012, Rafael J. Wysocki wrote: On Sunday, March 18, 2012, Hugh Dickins wrote: On Sat, 17 Mar 2012, Keith Packard wrote: On Sat, 17 Mar 2012 18:44:18 -0700 (PDT), Hugh Dickins hu...@google.com wrote: I keep worrying about the sequence when the machine is powered on

[PATCH] dma-buf: add support for kernel cpu access

Big differences to other contenders in the field (like ion) is that this also supports highmem, so we have to split up the cpu access from the kernel side into a prepare and a kmap step. Prepare is allowed to fail and should do everything required so that the kmap calls can succeed (like

Re: [PATCH v2 09/14] drm/exynos: add G2D driver

On 03/19/2012 09:25 PM, Dave Airlie wrote: On Fri, Mar 16, 2012 at 9:47 AM, Inki Daeinki@samsung.com wrote: From: Joonyoung Shimjy0922.s...@samsung.com The G2D is a 2D graphic accelerator that supports Bit Block Transfer. This G2D driver is exynos drm specific and supports only

Re: Why do flush page cache twice when change TT's cache attribute

Can I do the optimization like: if (ttm-caching_state == tt_cached) -drm_clflush_pages(ttm-pages, ttm-num_pages); +for (i = 0; i ttm-num_pages; ++i) + if (PageHighMem(ttm-pages[i])) +drm_clflush_pages(ttm-pages[i], 1); only do flush cache when high

[PATCH 1/4] dma-buf: don't hold the mutex around map/unmap calls

The mutex protects the attachment list and hence needs to be held around the callbakc to the exporters (optional) attach/detach functions. Holding the mutex around the map/unmap calls doesn't protect any dma_buf state. Exporters need to properly protect any of their own state anyway (to protect

[PATCH 2/4] dma-buf: add support for kernel cpu access

Big differences to other contenders in the field (like ion) is that this also supports highmem, so we have to split up the cpu access from the kernel side into a prepare and a kmap step. Prepare is allowed to fail and should do everything required so that the kmap calls can succeed (like

[PATCH 3/4] dma_buf: Add documentation for the new cpu access support

v2: Fix spelling issues noticed by Rob Clark. Signed-off-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt | 102 +++- 1 files changed, 99 insertions(+), 3 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt

[PATCH 4/4] dma-buf: document fd flags and O_CLOEXEC requirement

Otherwise subsystems will get this wrong and end up with and second export ioctl with the flag and O_CLOEXEC support added. Signed-Off-by: Daniel Vetter --- Documentation/dma-buf-sharing.txt |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git

[Bug 46323] RS480 is not capable of gles blur anymore after update to mesa 8.0

https://bugs.freedesktop.org/show_bug.cgi?id=46323 Ben Gouhier changed: What|Removed |Added Resolution|FIXED |WORKSFORME -- Configure bugmail:

[Bug 38471] Ryzom don´t works

https://bugs.freedesktop.org/show_bug.cgi?id=38471 Thomas Kowaliczek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[PATCH 3/7] drm/radeon/kms: optimize streamout checking for evergreen

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c | 37 ++-- 1 files changed, 21 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index b39a089..0427b96 100644 ---

[PATCH 4/7] drm/radeon/kms: skip db/cb/streamout checking when possible on evergreen

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c | 91 - 1 files changed, 66 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index 0427b96..7327bc7 100644 ---

[PATCH 6/7] drm/radeon/kms: compute GPU addresses correctly on r600

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c | 89 +- 1 files changed, 68 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index b3c40e0..d9ebec3 100644 ---

[PATCH 5/7] drm/radeon/kms: remove some unused variables in evergreen_cs_track

and document the other unused ones. Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/evergreen_cs.c | 58 +++-- drivers/gpu/drm/radeon/reg_srcs/cayman| 12 ++ drivers/gpu/drm/radeon/reg_srcs/evergreen | 12 ++ 3 files changed, 30 insertions(+),

[PATCH 7/7] drm/radeon/kms: skip db/cb/streamout checking when possible on r600

Signed-off-by: Marek Ol??k --- drivers/gpu/drm/radeon/r600_cs.c | 270 +- 1 files changed, 150 insertions(+), 120 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index d9ebec3..0ec3f20 100644 ---

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #6 from Jonathan Nieder 2012-03-19 08:44:40 --- udev should cope fine with kernels < 2.6.32 iirc as long as CONFIG_SYSFS_DEPRECATED is not set. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ---

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #7 from Jonathan Nieder 2012-03-19 08:54:19 --- The painful memories are coming back to me: udev also requires v2.6.28-rc6~45 ("reintroduce accept4") and dup3 and friends from 2.6.27. -- Configure bugmail:

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622 --- Comment #5 from kowalski marcin 2012-03-19 02:54:21 PDT --- the problem does not exist anymore on current mesa git and current stable kernel. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are

[Bug 42622] [r300g] mupen64plus invalid command stream

https://bugs.freedesktop.org/show_bug.cgi?id=42622 --- Comment #6 from kowalski marcin 2012-03-19 02:56:24 PDT --- i'll try this on another set of hardware soon to make sure. i might have been a bit hasty with that comment. -- Configure bugmail:

[Bug 29842] Radeon runs very hot

https://bugzilla.kernel.org/show_bug.cgi?id=29842 --- Comment #15 from Igor Rudchenko 2012-03-19 10:50:43 --- Tested 3.3.0 kernel today and nothing changes. So I look deeper into ASPM registers: Windows XP and Linux kernel prior 2.6.38: root complex 00:01.0 0xB0 == 0x03 (L1 and

[Linaro-mm-sig] [PATCH 4/4] dma-buf: document fd flags and O_CLOEXEC requirement

On Sun, Mar 18, 2012 at 11:34 PM, Daniel Vetter wrote: > Otherwise subsystems will get this wrong and end up with and second > export ioctl with the flag and O_CLOEXEC support added. Its not actually dma_buf_export that takes the O_CLOEXEC flag its dma_buf_fd I'm not sure how blindly we should

[PATCH v2 09/14] drm/exynos: add G2D driver

On Fri, Mar 16, 2012 at 9:47 AM, Inki Dae wrote: > From: Joonyoung Shim > > The G2D is a 2D graphic accelerator that supports Bit Block Transfer. > This G2D driver is exynos drm specific and supports only G2D(version > 4.1) of later Exynos series from Exynos4X12 because supporting DMA. So just

[PATCH 1/7] drm/radeon/kms: make some DRM errors more informative

On Sun, Mar 18, 2012 at 10:09 PM, Marek Ol??k wrote: > Signed-off-by: Marek Ol??k For the series: Reviewed-by: Alex Deucher > --- > ?drivers/gpu/drm/radeon/evergreen_cs.c | ? ?8 > ?1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git

[Bug 29842] Radeon runs very hot

https://bugzilla.kernel.org/show_bug.cgi?id=29842 Matthew Garrett changed: What|Removed |Added CC||mjg59-kernel at srcf.ucam.org ---

Regression: black screen on VGA w/ nouveau in Linux 3.3

Hi folks, Just upgraded to Linux 3.3 on my desktop and noticed that the VGA output on my card w/ nouveau is totally black (both at the console and in X). Almost everything appears to work normally: DPMS works, modesetting works, DDC works... all messages indicate that things are working -- just

[PATCH] drivers/gpu/drm/radeon/radeon_cs.c: eliminate possible double free

On Sat, Mar 17, 2012 at 1:03 PM, Julia Lawall wrote: > From: Julia Lawall > > The function radeon_cs_parser_init is only called from two places, in > drivers/gpu/drm/radeon/radeon_cs.c and drivers/gpu/drm/radeon/r600_cs.c. > In each case, if the call fails another function is called that frees

[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement

Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. v2: Fixup the function name and caution exporters to limit the flags to only O_CLOEXEC. Noted by Dave Airlie. Cc: Dave Airlie Signed-Off-by: Daniel Vetter ---

[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement

On Mon, Mar 19, 2012 at 04:41:55PM +0100, Daniel Vetter wrote: > Otherwise subsystems will get this wrong and end up with a second > export ioctl with the flag and O_CLOEXEC support added. > > v2: Fixup the function name and caution exporters to limit the flags > to only O_CLOEXEC. Noted by Dave

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

On Sat, 2012-03-17 at 14:14 -0700, Linus Torvalds wrote: > On Sat, Mar 17, 2012 at 1:23 PM, Dave Airlie wrote: > > > > I did however get a flashback in google to this: > > > > http://lists.fedoraproject.org/pipermail/scm-commits/2010-July/456636.html > > > > Linus don't think we ever did work out

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 J?r?me Glisse changed: What|Removed |Added CC||glisse at freedesktop.org ---

[Bug 29842] Radeon runs very hot

https://bugzilla.kernel.org/show_bug.cgi?id=29842 --- Comment #17 from Igor Rudchenko 2012-03-19 16:35:11 --- To Matthew Garrett: I agree about network cards, but current situation with video card worries me much. Prior 3.0.20, 3.2.5 and 3.3 kernels, users of ThinkPads T60 can simply add

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #9 from Alex Deucher 2012-03-19 16:42:50 --- Created an attachment (id=72654) --> (https://bugzilla.kernel.org/attachment.cgi?id=72654) possible fix Does this patch fix the issue? -- Configure bugmail:

[PATCH] RFC: dma-buf: userspace mmap support

> -Original Message- > From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk] > Sent: 17 March 2012 20:17 > To: Tom Cooksey > Cc: 'Rob Clark'; linaro-mm-sig at lists.linaro.org; dri- > devel at lists.freedesktop.org; linux-media at vger.kernel.org; > rschultz at google.com; Rob Clark;

[PATCH] RFC: dma-buf: userspace mmap support

> If the API was to also be used for synchronization it would have to > include an atomic "prepare multiple" ioctl which blocked until all > the buffers listed by the application were available. In the same Too slow already. You are now serializing stuff while what we want to do really is

hibernate random memory corruption, workaround i915.modeset=0

On Mon, Feb 27, 2012 at 01:42:43PM +0100, Stanislaw Gruszka wrote: > I'm able to reproduce random memory corruption after hibernate. > Corruption is not reproducible when I disable mode setting, what > seems to blame i915 driver or generic DRM kernel code. > > I'm able to reproduce bug on Fedora

[Linaro-mm-sig] [PATCH] RFC: dma-buf: userspace mmap support

On 03/19/2012 05:56 PM, Alan Cox wrote: >> display controller will be reading the front buffer, but the GPU >> > might also need to read that front buffer. So perhaps adding >> > "read-only"& "read-write" access flags to prepare could also be >> > interpreted as shared& exclusive accesses, if

hibernate random memory corruption, workaround i915.modeset=0

<#part sign=pgpmime> On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka wrote: > Keith, is there a chance that this bug can be fixed by i915 team? Yes, I'm working on figuring out how to actually reproduce this and then work on a few work-arounds. > If not, can we disable hibernate on i915

Why do flush page cache twice when change TT's cache attribute

On Mon, 2012-03-19 at 23:11 +0800, Scott Fang wrote: > In function ttm_tt_set_caching > ,,, > > if (ttm->caching_state == tt_cached) > drm_clflush_pages(ttm->pages, ttm->num_pages); > > for (i = 0; i < ttm->num_pages; ++i) { > cur_page = ttm->pages[i]; > if

[PATCH] RFC: dma-buf: userspace mmap support

> -Original Message- > From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk] > Sent: 19 March 2012 16:57 > To: Tom Cooksey > Cc: 'Rob Clark'; linaro-mm-sig at lists.linaro.org; dri- > devel at lists.freedesktop.org; linux-media at vger.kernel.org; > rschultz at google.com; Rob Clark;

[PATCH] dma-buf: document fd flags and O_CLOEXEC requirement

From: Rob Clark Otherwise subsystems will get this wrong and end up with a second export ioctl with the flag and O_CLOEXEC support added. Signed-off-by: Rob Clark Reviewed-by: Daniel Vetter --- Updated version of Daniel's original documentation patch with (hopefully) improved

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

On Sat, 17 Mar 2012, Linus Torvalds wrote: > On Sat, Mar 17, 2012 at 3:09 PM, Hugh Dickins wrote: > > > > I've got to go out for an hour: I'll digest more and think more about > > this when I get back. ?If someone could explain the original problem > > with _MOVABLE, that would help me: > > I do

i915 modeset memory corruption issues? (Fwd: Oops in ext3_block_to_path.isra.40+0x26/0x11b)

On Sun, 18 Mar 2012, Rafael J. Wysocki wrote: > On Sunday, March 18, 2012, Hugh Dickins wrote: > > On Sat, 17 Mar 2012, Keith Packard wrote: > > > On Sat, 17 Mar 2012 18:44:18 -0700 (PDT), Hugh Dickins > > google.com> wrote: > > > > I keep worrying about the sequence when the machine is powered