On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
> Hi All,
>
> The following is the state-of-the-art i.MX IPU (Image Processing Unit)
> DRM support.
>
> This code is around for quite some time now and has been posted several
> times with different APIs, first with plain old framebuff
On Mon, 2 Jul 2012 07:06:59 +0900
Mattia Dongili wrote:
> On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote:
> > On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote:
> > > On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote:
> > > > On Sun, Jun 17, 2012 at 12:
On 29.06.2012 18:50, alexdeuc...@gmail.com wrote:
From: Alex Deucher
Adds documentation to most of the functions in
radeon_device.c
v2: split out general descriptions as per Christian's
comments.
Signed-off-by: Alex Deucher
For the whole series:
Reviewed-by: Christian König
---
drive
https://bugs.freedesktop.org/show_bug.cgi?id=51652
Bug #: 51652
Summary: [6550D SUMO] problems with secondar monitor on VGA,
causing GPU lockups
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86
https://bugzilla.kernel.org/show_bug.cgi?id=28622
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Kernel Version|2.6.3
On Fri, Jun 29, 2012 at 07:17:23AM -0500, Rob Clark wrote:
> On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen wrote:
> > On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Use tiled buffers for rotated/reflected scanout, with CRTC and plane
> >> properties as the in
This patchset introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the drm gem CMA helper function.
Signed-off-by: Lars-Peter Clausen
---
Note: This patch depends on Sascha's "DRM: add drm gem CMA helper" patch
Changes since v2:
* Adapt to
On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer wrote:
> On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote:
>> On 29.06.2012 17:09, Michel Dänzer wrote:
>> > On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote:
>> >> Hold the ring lock the whole time the reset is in progress,
>> >> oth
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the semaphore as a writer ensuring that
no concurrent res
On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote:
> On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote:
> > On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote:
> > > On Sun, Jun 17, 2012 at 12:03 PM, Mattia Dongili
> > > wrote:
> ...
> > > If possible, add
On 02.07.2012 12:05, Sascha Hauer wrote:
On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
Hi All,
The following is the state-of-the-art i.MX IPU (Image Processing Unit)
DRM support.
This code is around for quite some time now and has been posted several
times with different APIs,
On 02.07.2012 17:41, Jerome Glisse wrote:
On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer wrote:
On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote:
On 29.06.2012 17:09, Michel Dänzer wrote:
On Fre, 2012-06-29 at 16:45 +0200, Christian König wrote:
Hold the ring lock the whole time the
On Mon, Jul 2, 2012 at 11:58 AM, Christian König
wrote:
> On 02.07.2012 17:41, Jerome Glisse wrote:
>>
>> On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer
>> wrote:
>>>
>>> On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote:
On 29.06.2012 17:09, Michel Dänzer wrote:
>
> On
Well,
V2 time! I was hinted to look at ttm_execbuf_util, and it does indeed contain
some nice code.
My goal was to extend dma-buf in a generic way now, some elements from v1 are
remaining,
most notably a dma-buf used for syncing. However it is expected now that
dma-buf syncing will
work in a ve
On Mon, Jul 2, 2012 at 11:58 AM, Christian König
wrote:
> On 02.07.2012 17:41, Jerome Glisse wrote:
>>
>> On Fri, Jun 29, 2012 at 12:15 PM, Michel Dänzer
>> wrote:
>>>
>>> On Fre, 2012-06-29 at 17:18 +0200, Christian König wrote:
On 29.06.2012 17:09, Michel Dänzer wrote:
>
> On
On Mon, Jul 2, 2012 at 11:39 AM, wrote:
> From: Jerome Glisse
>
> GPU reset need to be exclusive, one happening at a time. For this
> add a rw semaphore so that any path that trigger GPU activities
> have to take the semaphore as a reader thus allowing concurency.
>
> The GPU reset path take the
On 02.07.2012 17:39, j.gli...@gmail.com wrote:
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the sema
On Mon, Jul 2, 2012 at 12:26 PM, Christian König
wrote:
> On 02.07.2012 17:39, j.gli...@gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> GPU reset need to be exclusive, one happening at a time. For this
>> add a rw semaphore so that any path that trigger GPU activities
>> have to take the semapho
From: Jerome Glisse
In gem idle/busy ioctl the radeon object was derefenced after
drm_gem_object_unreference_unlocked which in case the object
have been destroyed lead to use of a possibly free pointer with
possibly wrong data.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_gem
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the semaphore as a writer ensuring that
no concurrent res
On 02.07.2012 18:41, Jerome Glisse wrote:
On Mon, Jul 2, 2012 at 12:26 PM, Christian König
wrote:
On 02.07.2012 17:39, j.gli...@gmail.com wrote:
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activiti
https://bugs.freedesktop.org/show_bug.cgi?id=51658
Bug #: 51658
Summary: r200 (& possibly radeon) DRI fixes for gnome shell on
Mesa 8.0.3
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: All
OS
On Mon, Jul 2, 2012 at 1:05 PM, Christian König wrote:
> On 02.07.2012 18:41, Jerome Glisse wrote:
>>
>> On Mon, Jul 2, 2012 at 12:26 PM, Christian König
>> wrote:
>>>
>>> On 02.07.2012 17:39, j.gli...@gmail.com wrote:
From: Jerome Glisse
GPU reset need to be exclusive, one h
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #1 from Eugene St Leger 2012-07-02 10:29:44 PDT
---
Created attachment 63712
--> https://bugs.freedesktop.org/attachment.cgi?id=63712
Essential patch to allow 2048 pixel blits.
Without this patch, gnome shell crashes. 2048 pixel b
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #2 from Eugene St Leger 2012-07-02 10:34:41 PDT
---
Created attachment 63713
--> https://bugs.freedesktop.org/attachment.cgi?id=63713
Essential patch to reapply dirtied texenv registers.
Without this patch, colour corruption happe
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #3 from Eugene St Leger 2012-07-02 10:37:47 PDT
---
Created attachment 63714
--> https://bugs.freedesktop.org/attachment.cgi?id=63714
Unessential fixes/enhancements patch.
Minor spelling fixes & enhancements.
--
Configure bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #4 from Eugene St Leger 2012-07-02 10:40:51 PDT
---
Created attachment 63715
--> https://bugs.freedesktop.org/attachment.cgi?id=63715
Proposed blit register dirtying patch.
It appears bliting dirties some registers without notifyi
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #5 from Eugene St Leger 2012-07-02 10:45:01 UTC
---
Created attachment 63716
--> https://bugs.freedesktop.org/attachment.cgi?id=63716
Optional patch to warn (once) when a blit with 2048 pixel dimension occurs on
r200.
If 2048 pixe
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #6 from Eugene St Leger 2012-07-02 10:49:07 PDT
---
Created attachment 63717
--> https://bugs.freedesktop.org/attachment.cgi?id=63717
Untested but probably essential patch to allow 2048 pixel blits on r100.
Without this patch, gno
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #7 from Eugene St Leger 2012-07-02 10:51:10 PDT
---
Created attachment 63718
--> https://bugs.freedesktop.org/attachment.cgi?id=63718
Optional untested patch to warn (once) when a blit with 2048 pixel dimension
occurs on r100.
If
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #8 from Eugene St Leger 2012-07-02 11:04:54 PDT
---
A summary of all of the patches follows.
r200 essential patches (1st 3 patches) for gnome shell:
"Essential patch to disable texture formats that are reported unrenderable
elsewher
On 6/26/12 3:21 AM, Takashi Iwai wrote:
From: Takashi Iwai
Subject: [PATCH] drm: edid: Don't add inferred modes with higher resolution
When a monitor EDID doesn't give the preferred bit, driver assumes
that the mode with the higest resolution and rate is the preferred
mode. Meanwhile the rece
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #28 from stefan 2012-07-02 13:13:59 PDT ---
Hi,
are there any news on this issue?
The 3.4 and 3.5-rc series seem stable wrt this issue,
but unfortunately something broke resume from s2ram badly,
the backlight stays off and the machine
https://bugzilla.kernel.org/show_bug.cgi?id=28622
--- Comment #11 from Alex Deucher 2012-07-02 20:21:02
---
Is this still an issue with a more recent kernel (3.x)?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
On Mon, Jul 2, 2012 at 12:40 PM, wrote:
> From: Jerome Glisse
>
> In gem idle/busy ioctl the radeon object was derefenced after
> drm_gem_object_unreference_unlocked which in case the object
> have been destroyed lead to use of a possibly free pointer with
> possibly wrong data.
>
> Signed-off-b
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #29 from Daniel Vetter 2012-07-02 13:29:18 PDT ---
(In reply to comment #28)
> are there any news on this issue?
> The 3.4 and 3.5-rc series seem stable wrt this issue,
> but unfortunately something broke resume from s2ram badly,
> th
On Sat, 30 Jun 2012 13:12:45 +0300
Lauri Kasanen wrote:
> Hi list
>
> The recently released libdrm 2.4.37 does not compile the Intel part:
>
> test_decode.c: In function 'compare_batch':
> test_decode.c:107: error: implicit declaration of function 'open_memstream'
>
> PS: Please CC me.
>
> Si
Adding dri-devel and a few others because an i915 patch contributed to
the regression.
On Mon, Jul 02, 2012 at 03:32:15PM +0100, Mel Gorman wrote:
> On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote:
> > > It increases the CPU overhead (dirty_inode can be called up to 4
> > > times
On Thu, Jun 28, 2012 at 3:45 AM, Dave Airlie wrote:
> On Wed, Jun 27, 2012 at 8:35 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> We need these for detecting the max link speed for drm drivers.
>
> Hi Bjorn,
>
> Can you ack this patch so I can carry it in the drm-next tree? we need
> these re
On Mon, Jul 02, 2012 at 11:43:04AM +0100, Alan Cox wrote:
> On Mon, 2 Jul 2012 07:06:59 +0900
> Mattia Dongili wrote:
...
> > a did put some printks here and there and psb_driver_init seems to
> > never return from gma_backlight_init.
>
> Is it ok if you just comment out gma_backlight_init (at wh
On Tue, Jul 03, 2012 at 07:11:31AM +0900, Mattia Dongili wrote:
> On Mon, Jul 02, 2012 at 11:43:04AM +0100, Alan Cox wrote:
> > On Mon, 2 Jul 2012 07:06:59 +0900
> > Mattia Dongili wrote:
> ...
> > > a did put some printks here and there and psb_driver_init seems to
> > > never return from gma_bac
On Mon, Jul 02, 2012 at 08:35:16PM +0100, Mel Gorman wrote:
> Adding dri-devel and a few others because an i915 patch contributed to
> the regression.
>
> On Mon, Jul 02, 2012 at 03:32:15PM +0100, Mel Gorman wrote:
> > On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote:
> > > > It i
On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
> Hi All,
>
> The following is the state-of-the-art i.MX IPU (Image Processing Unit)
> DRM support.
>
> This code is around for quite some time now and has been posted several
> times with different APIs, first with plain old framebuff
On Mon, 2 Jul 2012 07:06:59 +0900
Mattia Dongili wrote:
> On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote:
> > On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote:
> > > On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote:
> > > > On Sun, Jun 17, 2012 at 12:
On 29.06.2012 18:50, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> Adds documentation to most of the functions in
> radeon_device.c
>
> v2: split out general descriptions as per Christian's
> comments.
>
> Signed-off-by: Alex Deucher
For the whole series:
Reviewed-by: Christian K?nig
https://bugs.freedesktop.org/show_bug.cgi?id=51652
Bug #: 51652
Summary: [6550D SUMO] problems with secondar monitor on VGA,
causing GPU lockups
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: x86
https://bugzilla.kernel.org/show_bug.cgi?id=28622
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Kernel Version|2.
On Fri, Jun 29, 2012 at 07:17:23AM -0500, Rob Clark wrote:
> On Fri, Jun 29, 2012 at 5:46 AM, Tomi Valkeinen
> wrote:
> > On Wed, 2012-06-27 at 09:06 -0500, Rob Clark wrote:
> >> From: Rob Clark
> >>
> >> Use tiled buffers for rotated/reflected scanout, with CRTC and plane
> >> properties as the
This patchset introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the drm gem CMA helper function.
Signed-off-by: Lars-Peter Clausen
---
Note: This patch depends on Sascha's "DRM: add drm gem CMA helper" patch
Changes since v2:
* Adapt to
On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer wrote:
> On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote:
>> On 29.06.2012 17:09, Michel D?nzer wrote:
>> > On Fre, 2012-06-29 at 16:45 +0200, Christian K?nig wrote:
>> >> Hold the ring lock the whole time the reset is in progress,
>> >> oth
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the semaphore as a writer ensuring that
no concurrent res
On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote:
> On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote:
> > On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote:
> > > On Sun, Jun 17, 2012 at 12:03 PM, Mattia Dongili
> > > wrote:
> ...
> > > If possible, add
On 02.07.2012 12:05, Sascha Hauer wrote:
> On Thu, Jun 14, 2012 at 03:43:22PM +0200, Sascha Hauer wrote:
>> Hi All,
>>
>> The following is the state-of-the-art i.MX IPU (Image Processing Unit)
>> DRM support.
>>
>> This code is around for quite some time now and has been posted several
>> times wit
On 02.07.2012 17:41, Jerome Glisse wrote:
> On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer wrote:
>> On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote:
>>> On 29.06.2012 17:09, Michel D?nzer wrote:
On Fre, 2012-06-29 at 16:45 +0200, Christian K?nig wrote:
> Hold the ring lock the
On Mon, Jul 2, 2012 at 11:58 AM, Christian K?nig
wrote:
> On 02.07.2012 17:41, Jerome Glisse wrote:
>>
>> On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer
>> wrote:
>>>
>>> On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote:
On 29.06.2012 17:09, Michel D?nzer wrote:
>
> On
Well,
V2 time! I was hinted to look at ttm_execbuf_util, and it does indeed contain
some nice code.
My goal was to extend dma-buf in a generic way now, some elements from v1 are
remaining,
most notably a dma-buf used for syncing. However it is expected now that
dma-buf syncing will
work in a ve
On Mon, Jul 2, 2012 at 11:58 AM, Christian K?nig
wrote:
> On 02.07.2012 17:41, Jerome Glisse wrote:
>>
>> On Fri, Jun 29, 2012 at 12:15 PM, Michel D?nzer
>> wrote:
>>>
>>> On Fre, 2012-06-29 at 17:18 +0200, Christian K?nig wrote:
On 29.06.2012 17:09, Michel D?nzer wrote:
>
> On
On Mon, Jul 2, 2012 at 11:39 AM, wrote:
> From: Jerome Glisse
>
> GPU reset need to be exclusive, one happening at a time. For this
> add a rw semaphore so that any path that trigger GPU activities
> have to take the semaphore as a reader thus allowing concurency.
>
> The GPU reset path take the
On 02.07.2012 17:39, j.glisse at gmail.com wrote:
> From: Jerome Glisse
>
> GPU reset need to be exclusive, one happening at a time. For this
> add a rw semaphore so that any path that trigger GPU activities
> have to take the semaphore as a reader thus allowing concurency.
>
> The GPU reset path
On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig
wrote:
> On 02.07.2012 17:39, j.glisse at gmail.com wrote:
>>
>> From: Jerome Glisse
>>
>> GPU reset need to be exclusive, one happening at a time. For this
>> add a rw semaphore so that any path that trigger GPU activities
>> have to take the sema
From: Jerome Glisse
In gem idle/busy ioctl the radeon object was derefenced after
drm_gem_object_unreference_unlocked which in case the object
have been destroyed lead to use of a possibly free pointer with
possibly wrong data.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/radeon_gem
From: Jerome Glisse
GPU reset need to be exclusive, one happening at a time. For this
add a rw semaphore so that any path that trigger GPU activities
have to take the semaphore as a reader thus allowing concurency.
The GPU reset path take the semaphore as a writer ensuring that
no concurrent res
On 02.07.2012 18:41, Jerome Glisse wrote:
> On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig
> wrote:
>> On 02.07.2012 17:39, j.glisse at gmail.com wrote:
>>> From: Jerome Glisse
>>>
>>> GPU reset need to be exclusive, one happening at a time. For this
>>> add a rw semaphore so that any path that
https://bugs.freedesktop.org/show_bug.cgi?id=51658
Bug #: 51658
Summary: r200 (& possibly radeon) DRI fixes for gnome shell on
Mesa 8.0.3
Classification: Unclassified
Product: Mesa
Version: 8.0
Platform: All
OS
On Mon, Jul 2, 2012 at 1:05 PM, Christian K?nig
wrote:
> On 02.07.2012 18:41, Jerome Glisse wrote:
>>
>> On Mon, Jul 2, 2012 at 12:26 PM, Christian K?nig
>> wrote:
>>>
>>> On 02.07.2012 17:39, j.glisse at gmail.com wrote:
From: Jerome Glisse
GPU reset need to be exclusive, o
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #1 from Eugene St Leger 2012-07-02 10:29:44
PDT ---
Created attachment 63712
--> https://bugs.freedesktop.org/attachment.cgi?id=63712
Essential patch to allow 2048 pixel blits.
Without this patch, gnome shell crashes. 2048 pixel b
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #2 from Eugene St Leger 2012-07-02 10:34:41
PDT ---
Created attachment 63713
--> https://bugs.freedesktop.org/attachment.cgi?id=63713
Essential patch to reapply dirtied texenv registers.
Without this patch, colour corruption happe
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #3 from Eugene St Leger 2012-07-02 10:37:47
PDT ---
Created attachment 63714
--> https://bugs.freedesktop.org/attachment.cgi?id=63714
Unessential fixes/enhancements patch.
Minor spelling fixes & enhancements.
--
Configure bugmai
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #4 from Eugene St Leger 2012-07-02 10:40:51
PDT ---
Created attachment 63715
--> https://bugs.freedesktop.org/attachment.cgi?id=63715
Proposed blit register dirtying patch.
It appears bliting dirties some registers without notifyi
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #5 from Eugene St Leger 2012-07-02 10:45:01
UTC ---
Created attachment 63716
--> https://bugs.freedesktop.org/attachment.cgi?id=63716
Optional patch to warn (once) when a blit with 2048 pixel dimension occurs on
r200.
If 2048 pixe
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #6 from Eugene St Leger 2012-07-02 10:49:07
PDT ---
Created attachment 63717
--> https://bugs.freedesktop.org/attachment.cgi?id=63717
Untested but probably essential patch to allow 2048 pixel blits on r100.
Without this patch, gno
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #7 from Eugene St Leger 2012-07-02 10:51:10
PDT ---
Created attachment 63718
--> https://bugs.freedesktop.org/attachment.cgi?id=63718
Optional untested patch to warn (once) when a blit with 2048 pixel dimension
occurs on r100.
If
https://bugs.freedesktop.org/show_bug.cgi?id=51658
--- Comment #8 from Eugene St Leger 2012-07-02 11:04:54
PDT ---
A summary of all of the patches follows.
r200 essential patches (1st 3 patches) for gnome shell:
"Essential patch to disable texture formats that are reported unrenderable
elsewher
On 6/26/12 3:21 AM, Takashi Iwai wrote:
> From: Takashi Iwai
> Subject: [PATCH] drm: edid: Don't add inferred modes with higher resolution
>
> When a monitor EDID doesn't give the preferred bit, driver assumes
> that the mode with the higest resolution and rate is the preferred
> mode. Meanwhile
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #28 from stefan 2012-07-02 13:13:59 PDT
---
Hi,
are there any news on this issue?
The 3.4 and 3.5-rc series seem stable wrt this issue,
but unfortunately something broke resume from s2ram badly,
the backlight stays off and the machin
https://bugzilla.kernel.org/show_bug.cgi?id=28622
--- Comment #11 from Alex Deucher 2012-07-02
20:21:02 ---
Is this still an issue with a more recent kernel (3.x)?
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: --
On Mon, Jul 2, 2012 at 12:40 PM, wrote:
> From: Jerome Glisse
>
> In gem idle/busy ioctl the radeon object was derefenced after
> drm_gem_object_unreference_unlocked which in case the object
> have been destroyed lead to use of a possibly free pointer with
> possibly wrong data.
>
> Signed-off-b
https://bugs.freedesktop.org/show_bug.cgi?id=33309
--- Comment #29 from Daniel Vetter 2012-07-02 13:29:18 PDT
---
(In reply to comment #28)
> are there any news on this issue?
> The 3.4 and 3.5-rc series seem stable wrt this issue,
> but unfortunately something broke resume from s2ram badly,
> t
On Sat, 30 Jun 2012 13:12:45 +0300
Lauri Kasanen wrote:
> Hi list
>
> The recently released libdrm 2.4.37 does not compile the Intel part:
>
> test_decode.c: In function 'compare_batch':
> test_decode.c:107: error: implicit declaration of function 'open_memstream'
>
> PS: Please CC me.
>
> Si
Adding dri-devel and a few others because an i915 patch contributed to
the regression.
On Mon, Jul 02, 2012 at 03:32:15PM +0100, Mel Gorman wrote:
> On Mon, Jul 02, 2012 at 02:32:26AM -0400, Christoph Hellwig wrote:
> > > It increases the CPU overhead (dirty_inode can be called up to 4
> > > times
On Thu, Jun 28, 2012 at 3:45 AM, Dave Airlie wrote:
> On Wed, Jun 27, 2012 at 8:35 AM, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> We need these for detecting the max link speed for drm drivers.
>
> Hi Bjorn,
>
> Can you ack this patch so I can carry it in the drm-next tree? we need
> these re
81 matches
Mail list logo
