[PATCH 3/3] drm/omap: DMM based hardware scrolling console

From: Rob Clark Add support for YWRAP scrolling by shuffling pages around in DMM instead of sw blits. Note that fbcon only utilizes this mode if the y resolution is divided evenly by the font height. So, for example, a 1920x1080 display using a 16 pixel tall font will not utilize

[PATCH 2/3] drm/omap: crtc/encoder/fb destroy cleanups

From: Rob Clark Signed-off-by: Rob Clark --- drivers/staging/omapdrm/omap_crtc.c|3 +-- drivers/staging/omapdrm/omap_encoder.c |3 +-- drivers/staging/omapdrm/omap_fb.c |6 ++ 3 files changed, 4 insertions(+), 8 deletions(-) diff --git

[PATCH 1/3] drm/omap: allocation fail check

From: Rob Clark Signed-off-by: Rob Clark --- drivers/staging/omapdrm/omap_gem.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index 1054da3..a451c57 100644 ---

ttm dma allocator issue ?

Hi Konrad i stumble on this after a long period of test : Dec 9 12:00:37 homer kernel: [ cut here ] Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894 check_unmap+0x262/0x7e0() Dec 9 12:00:37 homer kernel: Hardware name: GA-A75M-UD2H Dec 9 12:00:37 homer

[PATCH] drm/radeon/kms: bail on BTC parts if MC ucode is missing

On Fri, 9 Dec 2011 11:31:54 -0500, alexdeucher at gmail.com wrote: > From: Alex Deucher > > We already do this for cayman, need to also do it for > BTC parts. The default memory and voltage setup is not > adequate for advanced operation. Continuing will > result in an unusable display. > >

[PATCH 5/5] drm/exynos: Add plane support with fimd

From: Joonyoung Shim The exynos fimd supports 5 window overlays. Only one window overlay of fimd is used by the crtc, so we need plane feature to use the rest window overlays. This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it is the ioctl to decide

[PATCH 4/5] drm/exynos: add runtime pm feature for fimd

From: Joonyoung Shim This adds runtime PM feature for fimd. The runtime PM functions control clocks for fimd and prevent to access the register of fimd for vblank when clock is turned off by suspend of runtime PM. Signed-off-by: Joonyoung Shim Signed-off-by: Inki Dae

[PATCH 3/5] drm/exynos: updated crtc and encoder dpms framework.

With DPMS ON and OFF requests, crtc dpms would be in charge of just only device power such as fimd or hdmi and encoder dpms in charge of device setting(mode setting and register updating) and also lcd panel and digital TV power. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park ---

[PATCH 2/5] drm/exynos: Use struct drm_mode_fb_cmd2

From: Joonyoung Shim The exynos drm also should use struct drm_mode_fb_cmd2 by changes of 308e5bcbdb10452e8aba31aa21432fb67ee46d72 commit(drm: add an fb creation ioctl that takes a pixel format v5). Signed-off-by: Joonyoung Shim Signed-off-by: Inki Dae Signed-off-by:

[PATCH 1/5] drm/exynos: Fix compile errors

From: Joonyoung Shim This compile errors occur by changes of e08e96de986ceb2c6b683df0bd0c4ddd4f91dcfd commit, so exynos drm should apply this changes. CC drivers/gpu/drm/exynos/exynos_drm_drv.o drivers/gpu/drm/exynos/exynos_drm_drv.c:185: warning: braces around

[PATCH 0/5] update new features.

Hello, Dave. I'm so sorry but ignor previous patch sets I just sent please. they include new feature so I made patch sets based on drm-next again. with this patch, exynos also would support multi planer feature. this feature has been tested and worked fine. these patch sets are as the

[PATCH] drm: Change order to turn off the crtc and plane with fb cleanup

Ths plane is enabled after the crtc is setted first, so first turn off the plane than the crtc. If not, it can occur some side effects because it may have to use any information of crtc when turns off the plane. Signed-off-by: Joonyoung Shim Signed-off-by: Kyungmin Park ---

drm_framebuffer_cleanup cleanup..

On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark wrote: > On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter wrote: >>> +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) >>> +{ >>> + ? ? struct drm_device *dev = fb->dev; >>> + ? ? struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);

[PATCH 2/2] drm/exynos: add runtime pm feature for fimd

From: Joonyoung Shim This adds runtime PM feature for fimd. The runtime PM functions control clocks for fimd and prevent to access the register of fimd for vblank when clock is turned off by suspend of runtime PM. Signed-off-by: Joonyoung Shim Signed-off-by: Inki Dae

[PATCH 1/2] drm/exynos: updated crtc and encoder dpms framework.

With DPMS ON and OFF requests, crtc dpms would be in charge of just only device power such as fimd or hdmi and encoder dpms in charge of device setting(mode setting and register updating) and also lcd panel and digital TV power. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park ---

[PATCH 0/2] update exynos drm driver.

this patch sets are as the following: - consolidate dpms framework. - add runtime pm feature for fimd driver. this patch is based on git repository below: git://people.freedesktop.org/~airlied/linux.git branch name: drm-fixes commit-id: 24bb5a0ce39c51a2e2602c947f218a19e4b26d7d and you can pull

[PATCH] Patch to enable reading the EDID information of a 3D capable HDMI monitor. This EDID information would be used to enable a user space application to switch the mode of the monitor to a specifi

-- Signed-off=by: sateesh.kavuri at intel.com --- drivers/gpu/drm/drm_edid.c | 109 include/drm/drm_crtc.h | 25 ++ 2 files changed, 134 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c

[PATCH 2/2] drm/i915: By default, enable RC6 on IVB and SNB when reasonable

RC6 should always work on IVB, and should work on SNB whenever IO remapping is disabled. RC6 never works on Ironlake. Make the default value for the parameter follow these guidelines. Setting the value to either 0 or 1 will force the specified behavior. Signed-off-by: Keith Packard Reviewed-by:

[PATCH 1/2] iommu: Export intel_iommu_enabled to signal when iommu is in use

From: Eugeni Dodonov In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar is enabled. The new 'intel_iommu_enabled' variable signals when the iommu code is in operation. Cc: Ted Phelps Cc: Peter Cc: Lukas Hejtmanek Cc: Andrew Lutomirski CC:

drm/i915: Enabling RC6 where possible

Ok, here's a "final" patch set to enable RC6 where possible on SNB and IVB machines. The first patch creates a new variable, intel_iommu_enabled, that is exported by the intel iommu code and set when that code has successfully initialized itself. The old plan of using no_iommu || dmar_disabled

[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901

https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #17 from Chris Wilson 2011-12-09 07:25:13 PST --- No, we don't buffer cursors. A single cursor bo is updated every time its image changes. (Whilst possible, I don't it is an interesting optimisation to cache the bo for a variety of

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #6 from Alex Deucher 2011-12-09 06:58:19 PST --- argh, the output from the function I wanted it TRACE level only. Can you attach the output of this patch: diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c

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

On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: > On Friday 02 December 2011, Sumit Semwal wrote: > > This is the first step in defining a dma buffer sharing mechanism. > [...] > > > + return dmabuf; > > +} > > +EXPORT_SYMBOL(dma_buf_export); > > I agree with Konrad, this

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 Marco Albanese changed: What|Removed |Added Attachment #54269|stdout and stderr from |output from banshee session

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #5 from Marco Albanese 2011-12-09 06:47:01 PST --- Created attachment 54269 --> https://bugs.freedesktop.org/attachment.cgi?id=54269 stdout and stderr from banshee session with a crash The step I've done to reproduce the crash:

[Bug 35460] [855GM] Corruptions with linux-2.6.38 & xf-video-intel-2.14.901

https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #16 from Bruno 2011-12-09 06:46:26 PST --- (In reply to comment #15 and comment #14 with attachment 53954) > > use wmb to flush the wc cache > > Running for a week now with this patch instead of the other one and have not > seen

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

> I still don't think that's possible. Please explain how you expect > to change the semantics of the streaming mapping API to allow multiple > mappers without having explicit serialization points that are visible > to all users. For simplicity, let's assume a cache coherent system I would agree.

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #4 from Alex Deucher 2011-12-09 06:20:08 PST --- Can you try running it with the RADEON_DEBUG=tex env var set and attach the output? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are

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

On Thursday 08 December 2011, Daniel Vetter wrote: > > c) only allowing streaming mappings, even if those are non-coherent > > (requiring strict serialization between CPU (in-kernel) and dma users of > > the buffer) > > I think only allowing streaming access makes the most sense: > - I don't see

[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #1 from Alex Deucher 2011-12-09 06:00:10 PST --- Can you bisect? Did you update any other components (mesa, xf86-video-ati) or just the kernel? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ---

drm_framebuffer_cleanup cleanup..

On Fri, Dec 9, 2011 at 11:44 AM, Dave Airlie wrote: > On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark wrote: >> On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter wrote: +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) +{ + ? ? struct drm_device *dev = fb->dev; + ? ?

[PATCH] drm: Enable reading 3D capabilities of 3D monitor

This is first of the patches to enable reading the 3D capabilities of a connected monitor on HDMI. Similar functionality would also be implemented for other interface, eDP, DP The idea is to read the 3D capabilities via EDID and provide this to a user space application that would want to

drm_framebuffer_cleanup cleanup..

On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter wrote: >> +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) >> +{ >> + ? ? struct drm_device *dev = fb->dev; >> + ? ? struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb); >> + >> + ? ? DBG("destroy: FB ID: %d (%p)",

[PATCH] drm/i915: Clean up multi-threaded forcewake patch

We learned that the ECOBUS register was inside the GT power well, and so *did* need force wake to be read, so it gets removed from the list of 'doesn't need force wake' registers. That means the code reading ECOBUS after forcing the mt_force_wake function to be called needs to use

[PATCH] drm/radeon/kms: bail on BTC parts if MC ucode is missing

From: Alex Deucher We already do this for cayman, need to also do it for BTC parts. The default memory and voltage setup is not adequate for advanced operation. Continuing will result in an unusable display. Signed-off-by: Alex Deucher Cc: stable at kernel.org Cc:

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #3 from Marco Albanese 2011-12-09 02:37:09 PST --- Sorry, I forget to say, I'm using Mesa 7.11.1 on an updated Debian Testing with Gnome3.2 fallback and compiz. -- Configure bugmail:

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #2 from Marco Albanese 2011-12-09 02:35:24 PST --- I've the same bug when using ClutterFlow extension on banshee on my Radeon Mobility 7500 ( RV200, R100 chip). It make the application crash when I hide the ClutterFlow interface,

[Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a

On Fri, Dec 9, 2011 at 6:32 AM, Bobby Powers wrote: > On Thu, Dec 8, 2011 at 11:05 PM, Bobby Powers > wrote: >> On Tue, Dec 6, 2011 at 12:43 PM, Ben Widawsky wrote: >>> On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: The recursion loop goes

[Intel-gfx] [PATCH] drm/i915: fix infinite recursion on unbind due to ilk vt-d w/a

On Thu, Dec 8, 2011 at 11:05 PM, Bobby Powers wrote: > On Tue, Dec 6, 2011 at 12:43 PM, Ben Widawsky wrote: >> On Tue, Dec 06, 2011 at 12:12:33PM +0100, Daniel Vetter wrote: >>> The recursion loop goes retire_requests->unbind->gpu_idle->retire_reqeusts. >>> >>> Every time we go through this we

[Bug 43655] New: Latest radeon dri driver on HD6950 with kernel 3.2 flickers

https://bugs.freedesktop.org/show_bug.cgi?id=43655 Bug #: 43655 Summary: Latest radeon dri driver on HD6950 with kernel 3.2 flickers Classification: Unclassified Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64)

[PATCH 0/2] update exynos drm driver.

this patch sets are as the following: - consolidate dpms framework. - add runtime pm feature for fimd driver. this patch is based on git repository below: git://people.freedesktop.org/~airlied/linux.git branch name: drm-fixes commit-id: 24bb5a0ce39c51a2e2602c947f218a19e4b26d7d and you can pull

[PATCH 2/2] drm/exynos: add runtime pm feature for fimd

From: Joonyoung Shim jy0922.s...@samsung.com This adds runtime PM feature for fimd. The runtime PM functions control clocks for fimd and prevent to access the register of fimd for vblank when clock is turned off by suspend of runtime PM. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com

[PATCH 1/2] drm/exynos: updated crtc and encoder dpms framework.

With DPMS ON and OFF requests, crtc dpms would be in charge of just only device power such as fimd or hdmi and encoder dpms in charge of device setting(mode setting and register updating) and also lcd panel and digital TV power. Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #2 from Marco Albanese deli...@gmail.com 2011-12-09 02:35:24 PST --- I've the same bug when using ClutterFlow extension on banshee on my Radeon Mobility 7500 ( RV200, R100 chip). It make the application crash when I hide the

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #3 from Marco Albanese deli...@gmail.com 2011-12-09 02:37:09 PST --- Sorry, I forget to say, I'm using Mesa 7.11.1 on an updated Debian Testing with Gnome3.2 fallback and compiz. -- Configure bugmail:

[PATCH] drm: Change order to turn off the crtc and plane with fb cleanup

Ths plane is enabled after the crtc is setted first, so first turn off the plane than the crtc. If not, it can occur some side effects because it may have to use any information of crtc when turns off the plane. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com Signed-off-by: Kyungmin Park

[PATCH 0/5] update new features.

Hello, Dave. I'm so sorry but ignor previous patch sets I just sent please. they include new feature so I made patch sets based on drm-next again. with this patch, exynos also would support multi planer feature. this feature has been tested and worked fine. these patch sets are as the

[PATCH 1/5] drm/exynos: Fix compile errors

From: Joonyoung Shim jy0922.s...@samsung.com This compile errors occur by changes of e08e96de986ceb2c6b683df0bd0c4ddd4f91dcfd commit, so exynos drm should apply this changes. CC drivers/gpu/drm/exynos/exynos_drm_drv.o drivers/gpu/drm/exynos/exynos_drm_drv.c:185: warning: braces around

[PATCH 3/5] drm/exynos: updated crtc and encoder dpms framework.

With DPMS ON and OFF requests, crtc dpms would be in charge of just only device power such as fimd or hdmi and encoder dpms in charge of device setting(mode setting and register updating) and also lcd panel and digital TV power. Signed-off-by: Inki Dae inki@samsung.com Signed-off-by: Kyungmin

[PATCH 2/5] drm/exynos: Use struct drm_mode_fb_cmd2

From: Joonyoung Shim jy0922.s...@samsung.com The exynos drm also should use struct drm_mode_fb_cmd2 by changes of 308e5bcbdb10452e8aba31aa21432fb67ee46d72 commit(drm: add an fb creation ioctl that takes a pixel format v5). Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com Signed-off-by: Inki

[PATCH 4/5] drm/exynos: add runtime pm feature for fimd

From: Joonyoung Shim jy0922.s...@samsung.com This adds runtime PM feature for fimd. The runtime PM functions control clocks for fimd and prevent to access the register of fimd for vblank when clock is turned off by suspend of runtime PM. Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com

[PATCH 5/5] drm/exynos: Add plane support with fimd

From: Joonyoung Shim jy0922.s...@samsung.com The exynos fimd supports 5 window overlays. Only one window overlay of fimd is used by the crtc, so we need plane feature to use the rest window overlays. This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it is the ioctl to decide

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

On Thursday 08 December 2011, Daniel Vetter wrote: c) only allowing streaming mappings, even if those are non-coherent (requiring strict serialization between CPU (in-kernel) and dma users of the buffer) I think only allowing streaming access makes the most sense: - I don't see much (if

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #4 from Alex Deucher ag...@yahoo.com 2011-12-09 06:20:08 PST --- Can you try running it with the RADEON_DEBUG=tex env var set and attach the output? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ---

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

I still don't think that's possible. Please explain how you expect to change the semantics of the streaming mapping API to allow multiple mappers without having explicit serialization points that are visible to all users. For simplicity, let's assume a cache coherent system I would agree.

[Bug 35460] [855GM] Corruptions with linux-2.6.38 xf-video-intel-2.14.901

https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #16 from Bruno bonbon...@internet.lu 2011-12-09 06:46:26 PST --- (In reply to comment #15 and comment #14 with attachment 53954) use wmb to flush the wc cache Running for a week now with this patch instead of the other one and

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #5 from Marco Albanese deli...@gmail.com 2011-12-09 06:47:01 PST --- Created attachment 54269 -- https://bugs.freedesktop.org/attachment.cgi?id=54269 stdout and stderr from banshee session with a crash The step I've done to

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 Marco Albanese deli...@gmail.com changed: What|Removed |Added Attachment #54269|stdout and stderr from |output from banshee

[Bug 41170] [RV250Lf] Unexpected texture format in radeon_update_wrapper()

https://bugs.freedesktop.org/show_bug.cgi?id=41170 --- Comment #6 from Alex Deucher ag...@yahoo.com 2011-12-09 06:58:19 PST --- argh, the output from the function I wanted it TRACE level only. Can you attach the output of this patch: diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c

[Bug 35460] [855GM] Corruptions with linux-2.6.38 xf-video-intel-2.14.901

https://bugs.freedesktop.org/show_bug.cgi?id=35460 --- Comment #17 from Chris Wilson ch...@chris-wilson.co.uk 2011-12-09 07:25:13 PST --- No, we don't buffer cursors. A single cursor bo is updated every time its image changes. (Whilst possible, I don't it is an interesting optimisation to cache

[PATCH] drm/radeon/kms: bail on BTC parts if MC ucode is missing

From: Alex Deucher alexander.deuc...@amd.com We already do this for cayman, need to also do it for BTC parts. The default memory and voltage setup is not adequate for advanced operation. Continuing will result in an unusable display. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Cc:

drm_framebuffer_cleanup cleanup..

On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter dan...@ffwll.ch wrote: +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) +{ +     struct drm_device *dev = fb-dev; +     struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb); + +     DBG(destroy: FB ID: %d (%p), fb-base.id,

Re: drm_framebuffer_cleanup cleanup..

On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark rob.cl...@linaro.org wrote: On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter dan...@ffwll.ch wrote: +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) +{ +     struct drm_device *dev = fb-dev; +     struct omap_framebuffer *omap_fb =

Re: drm_framebuffer_cleanup cleanup..

On Fri, Dec 9, 2011 at 11:44 AM, Dave Airlie airl...@gmail.com wrote: On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark rob.cl...@linaro.org wrote: On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter dan...@ffwll.ch wrote: +static void omap_framebuffer_destroy(struct drm_framebuffer *fb) +{ +     struct

[PATCH] drm/i915: Clean up multi-threaded forcewake patch

We learned that the ECOBUS register was inside the GT power well, and so *did* need force wake to be read, so it gets removed from the list of 'doesn't need force wake' registers. That means the code reading ECOBUS after forcing the mt_force_wake function to be called needs to use

[PATCH 1/2] iommu: Export intel_iommu_enabled to signal when iommu is in use

From: Eugeni Dodonov eugeni.dodo...@intel.com In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar is enabled. The new 'intel_iommu_enabled' variable signals when the iommu code is in operation. Cc: Ted Phelps phe...@gnusto.com Cc: Peter pab1...@gmail.com Cc: Lukas

drm/i915: Enabling RC6 where possible

Ok, here's a final patch set to enable RC6 where possible on SNB and IVB machines. The first patch creates a new variable, intel_iommu_enabled, that is exported by the intel iommu code and set when that code has successfully initialized itself. The old plan of using no_iommu || dmar_disabled

[Bug 31213] [RADEON:KMS:RV370:INIT] [drm] cp init fail (any kernels 2.6.3x.x)

https://bugs.freedesktop.org/show_bug.cgi?id=31213 --- Comment #2 from Jonathan Nieder jrnie...@gmail.com 2011-12-09 16:25:16 PST --- (In reply to comment #0) when loading the 'radeon' driver with modeset=1 (KMS enabled) the following error appears in dmesg | grep drm [drm:r100_ring_test]

[Bug 31213] [RADEON:KMS:RV370:INIT] [drm] cp init fail (any kernels 2.6.3x.x)

https://bugs.freedesktop.org/show_bug.cgi?id=31213 Jonathan Nieder jrnie...@gmail.com changed: What|Removed |Added Status|NEW |NEEDINFO --

[PATCH 1/3] drm/omap: allocation fail check

From: Rob Clark r...@ti.com Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_gem.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/staging/omapdrm/omap_gem.c b/drivers/staging/omapdrm/omap_gem.c index 1054da3..a451c57 100644 ---

[PATCH 2/3] drm/omap: crtc/encoder/fb destroy cleanups

From: Rob Clark r...@ti.com Signed-off-by: Rob Clark r...@ti.com --- drivers/staging/omapdrm/omap_crtc.c|3 +-- drivers/staging/omapdrm/omap_encoder.c |3 +-- drivers/staging/omapdrm/omap_fb.c |6 ++ 3 files changed, 4 insertions(+), 8 deletions(-) diff --git

[PATCH 3/3] drm/omap: DMM based hardware scrolling console

From: Rob Clark r...@ti.com Add support for YWRAP scrolling by shuffling pages around in DMM instead of sw blits. Note that fbcon only utilizes this mode if the y resolution is divided evenly by the font height. So, for example, a 1920x1080 display using a 16 pixel tall font will not utilize