[PATCH] drm/exynos: fimd: Get signal polarities from device tree

On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Figa wrote: > This patch modifies the driver to perform two stage parsing of video > timings from device tree, to get timing information as struct videomode, > which contains more data than struct fb_videomode. > > Thanks to this change,

[Bug 50941] Kernel does not compile

https://bugzilla.kernel.org/show_bug.cgi?id=50941 JP Pozzi changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[PATCH] drm/exynos: fimd: Get signal polarities from device tree

This patch modifies the driver to perform two stage parsing of video timings from device tree, to get timing information as struct videomode, which contains more data than struct fb_videomode. Thanks to this change, information about polarity of control signals (VSYNC, HSYNC, VDEN, VCLK) can be

[PATCH 4/4] drm/exynos: fimd: Add support for S3C64xx SoCs

The FIMD block present on S3C6400/S3C6410 SoCs is compatible with this driver, so it can be supported by it as well. This patch adds appropriate device IDs and driver data to enable this driver for S3C64xx SoCs. Signed-off-by: Tomasz Figa --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10

[PATCH 3/4] drm/exynos: fimd: Add support for FIMD variants with clock selection

Some platforms that can be supported this driver has additional clock source selection bits in VIDCON0 register that allows to select which clock should be used to drive the pixel clock: bus clock or special clock. Since this driver assumes that special clock always drives the pixel clock, this

[PATCH 2/4] drm/exynos: fimd: Add support for FIMD versions without SHADOWCON register

Some platforms that can be supported with this driver have PRTCON register instead of SHADOWCON, which requires slightly different handling. This patch factors out all register shadow control code from the driver and adds a function to control register shadowing appropriately, depending on driver

[PATCH 1/4] drm/exynos: fimd: Hold pointer to driver data in context struct

This patch adds pointer to driver data to fimd_context structure, to remove the need to call drm_fimd_get_driver_data() each time access to driver data is necessary. Signed-off-by: Tomasz Figa --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[PATCH 0/4] drm/exynos: fimd: Add support for S3C6400/S3C6410

Much of the code in Exynos DRM subsystem is generic enough to use it for older (non-Exynos) Samsung SoCs as well, after minor modifications. This series starts adding support for previous SoCs to Exynos DRM by introducing S3C64xx support to exynos_drm_fimd driver. Adding support for remaining

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/047df5dd/attachment-0001.html>

[GIT PULL]: dma-buf updates for 3.10

Hi Linus, The 3.10 pull request for dma-buf framework updates: small one, could you please pull? Thanks and best regards, ~Sumit. The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f: Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700) are

MultiSeat and GPU Acceleration

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/fb4b704a/attachment.html>

[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup

https://bugzilla.kernel.org/show_bug.cgi?id=42678 Laurent Bonnaud changed: What|Removed |Added CC||Laurent.Bonnaud at inpg.fr ---

[PATCH v4 17/31] drivers: convert shrinkers to new count/scan API

On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman wrote: > On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote: >> diff --git a/drivers/gpu/drm/i915/i915_gem.c >> b/drivers/gpu/drm/i915/i915_gem.c >> index 6be940e..2e44733 100644 >> --- a/drivers/gpu/drm/i915/i915_gem.c >> +++

[Bug 64124] [r600g] aruba crash with 32bit applications on 64bit kernel

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/2c3c9291/attachment.html>

[Bug 64124] New: [r600g] aruba crash with 32bit applications on 64bit kernel

You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/8e992416/attachment.html>

[Bug 48694] radeonsi_pipe.c:322:7: error: ‘PIPE_CAP_DUAL_SOURCE_BLEND’ undeclared

sktop.org/archives/dri-devel/attachments/20130501/77edf240/attachment.html>

[Bug 64091] piglit glean/readPixSanity testcase fails on ppc64 with Radeon adapter

: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/7624f36c/attachment.html>

[Bug 48694] radeonsi_pipe.c:322:7: error: ‘PIPE_CAP_DUAL_SOURCE_BLEND’ undeclared

are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/1dbe4161/attachment.html>

[PATCH] drm/radeon: fix handling of v6 power tables

From: Alex Deucher The code was mis-handling variable sizes arrays. Reported-by: Sylvain BERTRAND Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_atombios.c | 11 +-- 1 files changed, 5 insertions(+), 6

linux-next: manual merge of the drm-intel tree with the drm tree

ion/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/ca132d1f/attachment.pgp>

[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

Since we ask the dmabuf owner to map the dma-buf into our device address space, but for udl at present that is the CPU address space, since we don't DMA directly from the mapped buffer. However if we don't set a dma mask on the usb device, the mapping ends up using swiotlb on machines that have

[PATCH] drm/i915: fix dmabuf vmap support

From: Dave Airlie Sometimes that extra semicolon can really be hard to spot. Cc: Imre Deak Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c

[Bug 64096] LLVM RV790 etqw regression since R600: Packetize instructions

org/archives/dri-devel/attachments/20130501/aedfe730/attachment.html>

radeon pm bug?

On Tue, Apr 30, 2013 at 7:22 PM, Sylvain BERTRAND wrote: > Hi, > > In radeon_atombios.c file, radeon_atombios_parse_power_table_6 > function, the power state is selected using the state array index: > > power_state = (union pplib_power_state *)_array->states[i]; > > The state array has variable

[Bug 48694] radeonsi_pipe.c:322:7: error: ‘PIPE_CAP_DUAL_SOURCE_BLEND’ undeclared

on the targets/components that truly matter for the scons/autotools users. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130

[Bug 38856] [i915g] SIGSEGV src/gallium/drivers/i915/i915_state.c:511

|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/51edd7d7/attachment.html>

[Linaro-mm-sig] RFC: Unified DMA allocation algorithms

On Wed, Apr 24, 2013 at 11:35 PM, Laura Abbott wrote: > Hi all, > > I've been looking at a better way to do custom dma allocation algorithms in > a similar style to Ion heaps. Most drivers/clients have come up with a > series of semi-standard ways to get memory (CMA, memblock_reserve, >

[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

On Wed, May 1, 2013 at 6:30 AM, Dave Airlie wrote: > Since we ask the dmabuf owner to map the dma-buf into our device > address space, but for udl at present that is the CPU address space, > since we don't DMA directly from the mapped buffer. > > However if we don't set a dma mask on the usb

[PATCH 7/7] drm/nouveau: complain loudly if buffer is pinned during destruction

Shouldn't happen, and we invert the struct_mutex with reservation here, potentially leading to deadlocks. Once reservations become lockdep annotated, lockdep will go splat on this. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++- 1 file changed, 2

[PATCH 6/7] drm/nouveau: fixup fbcon failure paths

Add missing calls, and fix a leak from forgetting to call the unpin function. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 ++- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c

[PATCH 5/7] drm/nouveau: unpin notify object in chan_fini

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index 3b6dc88..9750bb9 100644 --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c +++

[PATCH 4/7] drm/nouveau: implement prime helper unpin function

--- drivers/gpu/drm/nouveau/nouveau_drm.c | 1 + drivers/gpu/drm/nouveau/nouveau_gem.h | 1 + drivers/gpu/drm/nouveau/nouveau_prime.c | 9 - 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c

[PATCH 3/7] drm/radeon: implement unpin function, v2

Changes since v1: - Fixup compiler warning in unpin function. Signed-off-by: Maarten Lankhorst Reviewed-by: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_drv.c | 2 ++ drivers/gpu/drm/radeon/radeon_prime.c | 18 +- 2 files changed, 15 insertions(+), 5 deletions(-) diff

[PATCH 2/7] drm: move pinning/unpinning to buffer attach

This allows importing bo's to own device to work without requiring that the buffer is pinned in GART. Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_prime.c | 41 ++--- 1 file changed, 26 insertions(+), 15 deletions(-)

[PATCH 1/7] drm: add unpin function to prime helpers

Prevents buffers from being pinned forever. Signed-off-by: Maarten Lankhorst Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_prime.c | 13 +++-- include/drm/drmP.h | 1 + 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c

linux-next: manual merge of the drm-intel tree with the drm tree

On Wed, May 1, 2013 at 6:37 AM, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-intel tree got a conflict in > drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 ("drm/i915: > Make data/link N value power of two") from the drm tree and commit > 72419203cab9

[Bug 57281] Radeon: Bad performance and power consumption

https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #9 from Michel D?nzer 2013-05-01 07:49:06 --- (In reply to comment #8) > According to powertop it saves about 0.5W or a little bit more. That's just from not enabling backing store? Not bad, considering backing store is

[Bug 57281] Radeon: Bad performance and power consumption

https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #8 from Nick 2013-05-01 07:32:39 --- According to powertop it saves about 0.5W or a little bit more. Not a break-thru but still useful. Thanks! -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ---

[Bug 64091] piglit glean/readPixSanity testcase fails on ppc64 with Radeon adapter

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130501/3ad58474/attachment.html>

abuse of dumb ioctls in exynos

>> Except in the cases where it doesn't do what you want, and possibly in >> the future where it does less of what you want. You've started on a >> slippery slope, and I'm stopping you before you make things worse. >> >> You are going to have to get SoC kernel drivers to add an ioctl that >> you

[Bug 64099] New: Mesa 9.0.3 implementation error: In _mesa_DeleteHashTable, found non-freed data

eInsertARB during my application. If you need any more information, please ask. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachm

radeon pm bug?

Hi, In radeon_atombios.c file, radeon_atombios_parse_power_table_6 function, the power state is selected using the state array index: power_state = (union pplib_power_state *)_array->states[i]; The state array has variable sized states which size should be computed as said in the atombios.h

abuse of dumb ioctls in exynos

On Tue, Apr 30, 2013 at 10:19 PM, Dave Airlie wrote: >>> Except in the cases where it doesn't do what you want, and possibly in >>> the future where it does less of what you want. You've started on a >>> slippery slope, and I'm stopping you before you make things worse. >>> >>> You are going to

[Bug 64099] New: Mesa 9.0.3 implementation error: In _mesa_DeleteHashTable, found non-freed data

https://bugs.freedesktop.org/show_bug.cgi?id=64099 Priority: medium Bug ID: 64099 Assignee: dri-devel@lists.freedesktop.org Summary: Mesa 9.0.3 implementation error: In _mesa_DeleteHashTable, found non-freed data Severity:

[PATCH] drm/i915: fix dmabuf vmap support

From: Dave Airlie airl...@redhat.com Sometimes that extra semicolon can really be hard to spot. Cc: Imre Deak imre.d...@intel.com Signed-off-by: Dave Airlie airl...@redhat.com --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

Since we ask the dmabuf owner to map the dma-buf into our device address space, but for udl at present that is the CPU address space, since we don't DMA directly from the mapped buffer. However if we don't set a dma mask on the usb device, the mapping ends up using swiotlb on machines that have

[Bug 64091] piglit glean/readPixSanity testcase fails on ppc64 with Radeon adapter

https://bugs.freedesktop.org/show_bug.cgi?id=64091 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop.

[Bug 57281] Radeon: Bad performance and power consumption

https://bugzilla.kernel.org/show_bug.cgi?id=57281 --- Comment #9 from Michel Dänzer mic...@daenzer.net 2013-05-01 07:49:06 --- (In reply to comment #8) According to powertop it saves about 0.5W or a little bit more. That's just from not enabling backing store? Not bad, considering backing

Re: linux-next: manual merge of the drm-intel tree with the drm tree

On Wed, May 1, 2013 at 6:37 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Today's linux-next merge of the drm-intel tree got a conflict in drivers/gpu/drm/i915/i915_reg.h between commit a65851af5938 (drm/i915: Make data/link N value power of two) from the drm tree and commit

[PATCH 1/7] drm: add unpin function to prime helpers

Prevents buffers from being pinned forever. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/drm_prime.c | 13 +++-- include/drm/drmP.h | 1 + 2 files changed, 12 insertions(+), 2 deletions(-)

[PATCH 4/7] drm/nouveau: implement prime helper unpin function

--- drivers/gpu/drm/nouveau/nouveau_drm.c | 1 + drivers/gpu/drm/nouveau/nouveau_gem.h | 1 + drivers/gpu/drm/nouveau/nouveau_prime.c | 9 - 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c

[PATCH 5/7] drm/nouveau: unpin notify object in chan_fini

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c b/drivers/gpu/drm/nouveau/nouveau_abi16.c index 3b6dc88..9750bb9 100644 ---

[PATCH 7/7] drm/nouveau: complain loudly if buffer is pinned during destruction

Shouldn't happen, and we invert the struct_mutex with reservation here, potentially leading to deadlocks. Once reservations become lockdep annotated, lockdep will go splat on this. Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com --- drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-

Re: [PATCH] drm/udl: avoid swiotlb for imported vmap buffers.

On Wed, May 1, 2013 at 6:30 AM, Dave Airlie airl...@gmail.com wrote: Since we ask the dmabuf owner to map the dma-buf into our device address space, but for udl at present that is the CPU address space, since we don't DMA directly from the mapped buffer. However if we don't set a dma mask on

Re: [Linaro-mm-sig] RFC: Unified DMA allocation algorithms

On Wed, Apr 24, 2013 at 11:35 PM, Laura Abbott lau...@codeaurora.org wrote: Hi all, I've been looking at a better way to do custom dma allocation algorithms in a similar style to Ion heaps. Most drivers/clients have come up with a series of semi-standard ways to get memory (CMA,

[Bug 38856] [i915g] SIGSEGV src/gallium/drivers/i915/i915_state.c:511

https://bugs.freedesktop.org/show_bug.cgi?id=38856 José Fonseca jfons...@vmware.com changed: What|Removed |Added Status|NEW |RESOLVED

[GIT PULL]: dma-buf updates for 3.10

Hi Linus, The 3.10 pull request for dma-buf framework updates: small one, could you please pull? Thanks and best regards, ~Sumit. The following changes since commit 5f56886521d6ddd3648777fae44d82382dd8c87f: Merge branch 'akpm' (incoming from Andrew) (2013-04-30 17:37:43 -0700) are

[Bug 48694] radeonsi_pipe.c:322:7: error: ‘PIPE_CAP_DUAL_SOURCE_BLEND’ undeclared

https://bugs.freedesktop.org/show_bug.cgi?id=48694 --- Comment #2 from José Fonseca jfons...@vmware.com --- I'm fine droping radeon from scons build. Neither of the two build systems (scons / autotools) will go away any time soon, so instead of trying to build evertyhing with both, it makes more

[Bug 64096] LLVM RV790 etqw regression since R600: Packetize instructions

https://bugs.freedesktop.org/show_bug.cgi?id=64096 --- Comment #2 from vincent v...@ovi.com --- Created attachment 78720 -- https://bugs.freedesktop.org/attachment.cgi?id=78720action=edit Disable bank_swizzle Hi, there is a bug that makes mesa change bank_swizzle if they are provided by

[Bug 48694] radeonsi_pipe.c:322:7: error: ‘PIPE_CAP_DUAL_SOURCE_BLEND’ undeclared

https://bugs.freedesktop.org/show_bug.cgi?id=48694 --- Comment #3 from Marek Olšák mar...@gmail.com --- FWIW, I made patches which remove radeon drivers from the scons build 2 years ago and some people weren't very happy about it. I think we shouldn't support 2 build systems for Linux-only

[Bug 64091] piglit glean/readPixSanity testcase fails on ppc64 with Radeon adapter

https://bugs.freedesktop.org/show_bug.cgi?id=64091 Jerome Glisse gli...@freedesktop.org changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop

Re: [PATCH v4 17/31] drivers: convert shrinkers to new count/scan API

On Tue, Apr 30, 2013 at 11:53 PM, Mel Gorman mgor...@suse.de wrote: On Sat, Apr 27, 2013 at 03:19:13AM +0400, Glauber Costa wrote: diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 6be940e..2e44733 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++

[Bug 48694] radeonsi_pipe.c:322:7: error: ‘PIPE_CAP_DUAL_SOURCE_BLEND’ undeclared

https://bugs.freedesktop.org/show_bug.cgi?id=48694 --- Comment #4 from Michel Dänzer mic...@daenzer.net --- (In reply to comment #3) FWIW, I made patches which remove radeon drivers from the scons build 2 years ago and some people weren't very happy about it. At the time, the make based build

[Bug 64124] New: [r600g] aruba crash with 32bit applications on 64bit kernel

https://bugs.freedesktop.org/show_bug.cgi?id=64124 Priority: medium Bug ID: 64124 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g] aruba crash with 32bit applications on 64bit kernel Severity: normal

[Bug 64124] [r600g] aruba crash with 32bit applications on 64bit kernel

https://bugs.freedesktop.org/show_bug.cgi?id=64124 --- Comment #1 from Alan Swanson swan...@ukfsn.org --- Created attachment 78730 -- https://bugs.freedesktop.org/attachment.cgi?id=78730action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug.

Re: radeon pm bug?

On Tue, Apr 30, 2013 at 7:22 PM, Sylvain BERTRAND sylw...@legeek.net wrote: Hi, In radeon_atombios.c file, radeon_atombios_parse_power_table_6 function, the power state is selected using the state array index: power_state = (union pplib_power_state *)state_array-states[i]; The state array

[Bug 42678] [3.3-rc1] radeon stuck in kernel after lockup

https://bugzilla.kernel.org/show_bug.cgi?id=42678 Laurent Bonnaud laurent.bonn...@inpg.fr changed: What|Removed |Added CC|

[PATCH] drm/radeon: fix handling of v6 power tables

From: Alex Deucher alexander.deuc...@amd.com The code was mis-handling variable sizes arrays. Reported-by: Sylvain BERTRAND sylw...@legeek.net Signed-off-by: Alex Deucher alexander.deuc...@amd.com Cc: sta...@vger.kernel.org --- drivers/gpu/drm/radeon/radeon_atombios.c | 11 +-- 1

[PATCH 0/4] drm/exynos: fimd: Add support for S3C6400/S3C6410

Much of the code in Exynos DRM subsystem is generic enough to use it for older (non-Exynos) Samsung SoCs as well, after minor modifications. This series starts adding support for previous SoCs to Exynos DRM by introducing S3C64xx support to exynos_drm_fimd driver. Adding support for remaining

[PATCH 1/4] drm/exynos: fimd: Hold pointer to driver data in context struct

This patch adds pointer to driver data to fimd_context structure, to remove the need to call drm_fimd_get_driver_data() each time access to driver data is necessary. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 5 +++-- 1 file changed, 3

[PATCH 2/4] drm/exynos: fimd: Add support for FIMD versions without SHADOWCON register

Some platforms that can be supported with this driver have PRTCON register instead of SHADOWCON, which requires slightly different handling. This patch factors out all register shadow control code from the driver and adds a function to control register shadowing appropriately, depending on driver

[PATCH 3/4] drm/exynos: fimd: Add support for FIMD variants with clock selection

Some platforms that can be supported this driver has additional clock source selection bits in VIDCON0 register that allows to select which clock should be used to drive the pixel clock: bus clock or special clock. Since this driver assumes that special clock always drives the pixel clock, this

[PATCH 4/4] drm/exynos: fimd: Add support for S3C64xx SoCs

The FIMD block present on S3C6400/S3C6410 SoCs is compatible with this driver, so it can be supported by it as well. This patch adds appropriate device IDs and driver data to enable this driver for S3C64xx SoCs. Signed-off-by: Tomasz Figa tomasz.f...@gmail.com ---

[PATCH] drm/exynos: fimd: Get signal polarities from device tree

This patch modifies the driver to perform two stage parsing of video timings from device tree, to get timing information as struct videomode, which contains more data than struct fb_videomode. Thanks to this change, information about polarity of control signals (VSYNC, HSYNC, VDEN, VCLK) can be

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled

https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #12 from Chris Rankin ranki...@googlemail.com --- Created attachment 78735 -- https://bugs.freedesktop.org/attachment.cgi?id=78735action=edit dmesg output showing GPU lockup No, it doesn't appear to. I compiled this version of Mesa

Re: [PATCH] drm/exynos: fimd: Get signal polarities from device tree

On Wed, May 01, 2013 at 09:06:09PM +0200, Tomasz Figa wrote: This patch modifies the driver to perform two stage parsing of video timings from device tree, to get timing information as struct videomode, which contains more data than struct fb_videomode. Thanks to this change, information

[Bug 50941] Kernel does not compile

https://bugzilla.kernel.org/show_bug.cgi?id=50941 JP Pozzi jp.po...@izzop.net changed: What|Removed |Added Status|NEW |RESOLVED

Re: WARNING: at drivers/gpu/drm/drm_crtc.c:82 drm_warn_on_modeset_not_all_locked+0x8d/0xc0()

On Thu, May 2, 2013 at 2:02 AM, Borislav Petkov b...@alien8.de wrote: Hi, I'm seeing this when booting latest Linus tree + tip/master in kvm. Config is attached. Looks like it cannot find root fs and panics and calls the panic notifier which screams in drm_crtc.c because not all modeset

Re: WARNING: at drivers/gpu/drm/drm_crtc.c:82 drm_warn_on_modeset_not_all_locked+0x8d/0xc0()

On Thu, May 2, 2013 at 10:41 AM, Daniel Vetter dan...@ffwll.ch wrote: On Thu, May 2, 2013 at 2:02 AM, Borislav Petkov b...@alien8.de wrote: Hi, I'm seeing this when booting latest Linus tree + tip/master in kvm. Config is attached. Looks like it cannot find root fs and panics and calls the

MultiSeat and GPU Acceleration

Hi ! Yes, I'm a newbie, so to introduce myself. I have some programming knowledge from long ago and have dealt with databases, C, Assembler, Pascal and others.  I've noticed lately, as I'm sure as you all have,  about the dramatic  increase in GPU processing capability. Cuda, openGL, openCL etc. 

server gpus: fix race between buffer evict and fbdev updates

This stores up dirty updates to the fbdev until the next update after the buffer has finished moving, otherwise you'd see a lot of failed to reserve bo during bootup with plymouth was starting. Dave. ___ dri-devel mailing list

[PATCH 1/3] drm/mgag200: deal with bo reserve fail in dirty update path

From: Dave Airlie airl...@redhat.com On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of migrating, so it makes sense we can't reserve it. In order to deal with it, this

[PATCH 2/3] drm/ast: deal with bo reserve fail in dirty update path

From: Dave Airlie airl...@redhat.com Port over the mgag200 fix to ast as it suffers the same issue. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of

[PATCH 3/3] drm/cirrus: deal with bo reserve fail in dirty update path

From: Dave Airlie airl...@redhat.com Port over the mgag200 fix to cirrus as it suffers the same issue. On F19 testing, it was noticed we get a lot of errors in dmesg about being unable to reserve the buffer when plymouth starts, this is due to the buffer being in the process of

[Bug 63865] radeon_atombios_get_power_modes oops with E-350

https://bugs.freedesktop.org/show_bug.cgi?id=63865 --- Comment #9 from Christian Heinz c...@nainokami.net --- (In reply to comment #8) It looks like you are using a bogus unposted vbios image. I think you'll need to bisect. If I had to guess, I'd say it's related to some change in how the