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 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 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 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
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
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
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
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: --
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
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
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
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
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 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
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 #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 #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 #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 #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 #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
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 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 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
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=28622
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Kernel Version|2.
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 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
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://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: --
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
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
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
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
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 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
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
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 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 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, 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, 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 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
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
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 #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 #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 #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 #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 #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 #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 #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
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
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 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
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
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
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
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 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 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 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 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 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
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 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
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 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 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
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
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
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
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 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
81 matches
Mail list logo
