[PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Apr-01-2014 12:35 AM, Daniel Vetter wrote: > On Fri, Mar 21, 2014 at 08:31:29AM +0530, Vandana Kannan wrote: >> Populate PAR in infoframe structure. If there is a user setting for PAR, then >> that value is set. Else, value is taken from CEA mode list if VIC is found. >> Else, PAR is calculated

[Bug 66963] Rv6xx dpm problems

sktop.org/archives/dri-devel/attachments/20140401/a4c6a45b/attachment.html>

[PATCH] drm: Prefer noninterlace cmdline mode unless explicitly specified

At Wed, 19 Mar 2014 15:17:50 +0100, Daniel Vetter wrote: > > On Wed, Mar 19, 2014 at 02:53:13PM +0100, Takashi Iwai wrote: > > Currently drm_pick_cmdline_mode() doesn't care about the interlace > > when the given mode line has no "i" suffix. That is, when there are > > multiple entries for the

[PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Tue, Apr 01, 2014 at 08:06:04AM +0530, Vandana Kannan wrote: > On Apr-01-2014 12:35 AM, Daniel Vetter wrote: > > On Fri, Mar 21, 2014 at 08:31:29AM +0530, Vandana Kannan wrote: > >> Populate PAR in infoframe structure. If there is a user setting for PAR, > >> then > >> that value is set. Else,

[Bug 76884] New: Dithering not enabled on 6-bit per channel display

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/20140401/c85844f5/attachment.html>

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

On Mon, Mar 31, 2014 at 06:03:24PM -0700, Matt Roper wrote: > On Fri, Mar 28, 2014 at 09:32:06AM +0100, Daniel Vetter wrote: > > On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote: > ... > > > + * N.B., we call set_config() directly here rather than using > > > + *

[RFC 2/4] drm: exynos: add MDNIE post processor

Hi Ajay, Thanks for the patch. On 03/19/2014 03:22 PM, Ajay Kumar wrote: > Add post processor ops for MDNIE and their support functions. > Expose an interface for the FIMD to register MDNIE PP. > > Signed-off-by: Ajay Kumar > Signed-off-by: Shirish S > Signed-off-by: Rahul Sharma > --- >

crtc ganging in KMS, "large" displays, etc

On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote: > I thought I'd kick off a thread to better discuss how to deal with > "large" displays which need multiple crtcs/planes merged to deal > without output larger than a certain width. > > What I have in mind basically amounts to

[RFC 3/4] drm: exynos: add IELCD post processor

Hi, Thanks for the patch. On 03/19/2014 03:22 PM, Ajay Kumar wrote: > Add post processor ops for IELCD and their support functions. > Expose an interface for the FIMD to register IELCD PP. > > Signed-off-by: Ajay Kumar > Signed-off-by: Shirish S > Signed-off-by: Rahul Sharma > --- >

[Bug 65761] HD 7970M Hybrid - hangs and errors and rmmod causes crash

https://bugzilla.kernel.org/show_bug.cgi?id=65761 Mike Cloaked changed: What|Removed |Added CC||mike.cloaked at gmail.com --- Comment #56

[RFC 4/4] drm: exynos: add MDNIE and IELCD to FIMD pp list

Hi Ajay, Thanks for the patch. On 03/19/2014 03:22 PM, Ajay Kumar wrote: > This patch adds code to add MDNIE and IELCD onto the > list of FIMD PP. > > Signed-off-by: Ajay Kumar > Signed-off-by: Shirish S > Signed-off-by: Rahul Sharma > --- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 17

[RFC 0/4] drm: exynos: Add drivers for MDNIE and IELCD

Hi Ajay, Thanks for the patchset. On 03/19/2014 03:22 PM, Ajay Kumar wrote: > This series is based on exynos-drm-next-todo branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > On Exynos SOC, FIMD supports various post processors > like MIE,

[PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Apr-01-2014 12:57 PM, Daniel Vetter wrote: > On Tue, Apr 01, 2014 at 08:06:04AM +0530, Vandana Kannan wrote: >> On Apr-01-2014 12:35 AM, Daniel Vetter wrote: >>> On Fri, Mar 21, 2014 at 08:31:29AM +0530, Vandana Kannan wrote: Populate PAR in infoframe structure. If there is a user setting

[PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Tue, Apr 1, 2014 at 11:26 AM, Vandana Kannan wrote: > Ok, I will modify the patch (which adds aspect ratio property) to move > the property to drm and resend separately. > This patch as it is unblocks AVI infoframe compliance test, so can this > patch be considered for acceptance now? Without

[PATCH v2] drm: Make drm_clflush_virt_range() void*

From: Ville Syrj?l? Currently drm_cflush_virt_rage() takes a char* so the caller probably has to do pointless casting to avoid compiler warnings. Make the argument void* instead to avoid such issues. v2: Use void* arithmetic (Chris) Signed-off-by: Ville Syrj?l?

[PATCH 1/1] drm/vmwgfx: correct fb_fix_screeninfo.line_length

On 03/28/2014 02:45 AM, Dave Airlie wrote: > On Fri, Mar 28, 2014 at 10:45 AM, Christopher Friedt > wrote: >> Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, >> but it would not adjust >> the FINFO properly, resulting in distorted screen rendering. The patch >>

[PATCH v2] drm: Make drm_clflush_virt_range() void*

On Tue, Apr 01, 2014 at 12:59:08PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Currently drm_cflush_virt_rage() takes a char* so the caller probably > has to do pointless casting to avoid compiler warnings. Make the > argument void* instead to avoid such issues. >

[PATCH v2] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

Populate PAR in infoframe structure. If there is a user setting for PAR, then that value is set. Else, value is taken from CEA mode list if VIC is found. Else, PAR is calculated from resolution. If none of these conditions are satisfied, PAR is NONE as per initialization. v2: Removed the part

[PATCH v2] drm: Make drm_clflush_virt_range() void*

On Tue, Apr 01, 2014 at 11:08:59AM +0100, Chris Wilson wrote: > On Tue, Apr 01, 2014 at 12:59:08PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > Currently drm_cflush_virt_rage() takes a char* so the caller probably > > has to do pointless casting to avoid

[PATCH] drm/rcar-du: Handle encoder initialization failures

The rcar_du_encoder_init() function can fail and return an error code. Don't ignore it. Signed-off-by: Laurent Pinchart --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git

[PATCH v2] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Tue, Apr 01, 2014 at 04:26:59PM +0530, Vandana Kannan wrote: > Populate PAR in infoframe structure. If there is a user setting for PAR, then > that value is set. Else, value is taken from CEA mode list if VIC is found. > Else, PAR is calculated from resolution. If none of these conditions are >

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

On Tue, Apr 1, 2014 at 3:45 AM, Daniel Vetter wrote: > On Mon, Mar 31, 2014 at 06:03:24PM -0700, Matt Roper wrote: >> On Fri, Mar 28, 2014 at 09:32:06AM +0100, Daniel Vetter wrote: >> > On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote: >> ... >> > > + * N.B., we call set_config()

[PATCH v3 00/12] Add DSI display support for Exynos based boards

Hi Andrzej, 2014-03-28 20:52 GMT+09:00 Andrzej Hajda : > Hi, > > This patchset adds drivers and bindings to the following devices: > - Exynos DSI master, > - S6E8AA0 DSI panel, > > It adds also display support in DTS files for the following boards: > - Exynos4210/Trats, > - Exynos4412/Trats2. >

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

On Tue, Apr 1, 2014 at 1:45 PM, Rob Clark wrote: > On Tue, Apr 1, 2014 at 3:45 AM, Daniel Vetter wrote: >> On Mon, Mar 31, 2014 at 06:03:24PM -0700, Matt Roper wrote: >>> On Fri, Mar 28, 2014 at 09:32:06AM +0100, Daniel Vetter wrote: >>> > On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper

[PATCH v2 0/7] drm/exynos: more cleanup with super device support

This patch series cleans up exynos drm framework and kms sub drivers using the component framework[1]. And this patch series had been posted for RFC[2]. Thanks, Inki Dae [1] http://lists.freedesktop.org/archives/dri-devel/2014-January/051249.html [2]

[PATCH v2 3/7] drm/exynos: register platform driver at each kms sub drivers

This patch removes platform_driver_register() calls from exynos_drm_drv module, and calls module_platform_driver() at each kms sub drivers instead. Previous RFC patch, http://www.spinics.net/lists/dri-devel/msg54672.html Changelog since RFC patch: - remove unnecessary platform_driver

[PATCH 7/7] exynos/drm: add DT bindings

This patch adds bindings for Exynos drm display subsystem. The bindings describes ports containing a list of phandles pointing to display controller, image enhancer, and display interfaces nodes. Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park ---

[PATCH 5/7] ARM: dts: exynos4210-trats: add super device node for exynos drm

Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4210-trats.dts |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts index 02c6768..a41c109 100644 ---

[PATCH v2 1/7] drm/exynos: add super device support

This patch adds super device support to bind sub drivers using device tree. For this, you should add a super device node to each machine dt files like belows, In case of using MIPI-DSI, display-subsystem { compatible = "samsung,exynos-display-subsystem";

[PATCH 2/7] drm/exynos: dpi: fix hotplug fail issue

When connector is created, if connector->polled is DRM_CONNECTOR_POLL_CONNECT then drm_kms_helper_hotplug_event function isn't called at drm_helper_hpd_irq_event because the function will be called only in case of DRM_CONNECTOR_POLL_HPD. So this patch sets always DRM_CONNECTOR_POLL_HPD flag to

[PATCH 4/7] ARM: dts: exynos4210-universal: add super device node for exynos drm

Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4210-universal_c210.dts |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts index 0a80a72..5351ac4 100644

[PATCH 6/7] ARM: dts: exynos4412-trats2: add super device node for exynos drm

Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- arch/arm/boot/dts/exynos4412-trats2.dts |5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts index 53c717b..115b9ed 100644 ---

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 1, 2014 at 4:04 AM, Daniel Vetter wrote: > On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote: >> I thought I'd kick off a thread to better discuss how to deal with >> "large" displays which need multiple crtcs/planes merged to deal >> without output larger than a certain

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 1, 2014 at 8:40 AM, Rob Clark wrote: > On Tue, Apr 1, 2014 at 4:04 AM, Daniel Vetter wrote: >> On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote: >>> I thought I'd kick off a thread to better discuss how to deal with >>> "large" displays which need multiple crtcs/planes

[PATCH v2] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Apr-01-2014 5:04 PM, Ville Syrj?l? wrote: > On Tue, Apr 01, 2014 at 04:26:59PM +0530, Vandana Kannan wrote: >> Populate PAR in infoframe structure. If there is a user setting for PAR, then >> that value is set. Else, value is taken from CEA mode list if VIC is found. >> Else, PAR is calculated

[PATCH] drm/qxl: unset a pointer in sync_obj_unref

This fixes a BUG_ON(bo->sync_obj != NULL); in ttm_bo_release_list. Cc: stable at vger.kernel.org #v3.10+ Signed-off-by: Maarten Lankhorst --- diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c index c7e7e6590c2b..c82c1d6a965a 100644 --- a/drivers/gpu/drm/qxl/qxl_ttm.c

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote: > No, not really. I was just trying to get away with pushing some > complexity (for case #1) up to userspace instead of doing it in the > kernel. To clarify: I don't think it makes sense to fully abstract this away in the kernel,

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter wrote: > On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote: >> No, not really. I was just trying to get away with pushing some >> complexity (for case #1) up to userspace instead of doing it in the >> kernel. > > To clarify: I don't think it

[PATCH v2] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Tue, Apr 01, 2014 at 06:43:42PM +0530, Vandana Kannan wrote: > On Apr-01-2014 5:04 PM, Ville Syrj?l? wrote: > > On Tue, Apr 01, 2014 at 04:26:59PM +0530, Vandana Kannan wrote: > >> Populate PAR in infoframe structure. If there is a user setting for PAR, > >> then > >> that value is set. Else,

[PATCH v3] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

Populate PAR in infoframe structure. If there is a user setting for PAR, then that value is set. Else, value is taken from CEA mode list if VIC is found. Else, PAR is calculated from resolution. If none of these conditions are satisfied, PAR is NONE as per initialization. v2: Removed the part

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote: > On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter wrote: > > On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote: > >> No, not really. I was just trying to get away with pushing some > >> complexity (for case #1) up to userspace

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrj?l? wrote: > On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote: >> On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter wrote: >> > On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote: >> >> No, not really. I was just trying to get away with

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 01, 2014 at 10:22:07AM -0400, Rob Clark wrote: > On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrj?l? > wrote: > > On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote: > >> On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter wrote: > >> > On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark

crtc ganging in KMS, "large" displays, etc

On Tue, Apr 1, 2014 at 10:42 AM, Ville Syrj?l? wrote: > On Tue, Apr 01, 2014 at 10:22:07AM -0400, Rob Clark wrote: >> On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrj?l? >> wrote: >> > On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote: >> >> On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter

[PATCH v4] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

Populate PAR in infoframe structure. PAR is taken from CEA mode list if VIC is found. Else, PAR is NONE as per initialization. v2: Removed the part which sets PAR according to user input, based on Daniel's review comments. v3: Removed calculation of PAR for non-CEA modes as per discussion with

[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)

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/20140401/e6da4372/attachment-0001.html>

[Bug 41086] Screen update problems when scrolling to the right in many (any?) java apps

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

[Intel-gfx] [PATCH v3] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Tue, Apr 01, 2014 at 07:52:21PM +0530, Vandana Kannan wrote: > Populate PAR in infoframe structure. If there is a user setting for PAR, then > that value is set. Else, value is taken from CEA mode list if VIC is found. > Else, PAR is calculated from resolution. If none of these conditions are >

[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen

https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #12 from Mike Cloaked --- Is this bug related to https://bugzilla.kernel.org/show_bug.cgi?id=65761 -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen

https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #13 from Alex Deucher --- (In reply to Mike Cloaked from comment #12) > Is this bug related to https://bugzilla.kernel.org/show_bug.cgi?id=65761 I don't think so. In your case you seem to lose the display before the radeon card is

[Bug 73291] Kernel 3.13.7 boots with hybrid Intel/ATI but to blank graphical screen

https://bugzilla.kernel.org/show_bug.cgi?id=73291 --- Comment #14 from Mike Cloaked --- Yes prior to blacklisting the radeon module I tried booting with radeon.runpm=0 and I still got the blank screen for graphical boot. -- You are receiving this mail because: You are watching the assignee of

[PATCH v4] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

On Tue, Apr 01, 2014 at 09:07:50PM +0530, Vandana Kannan wrote: > Populate PAR in infoframe structure. PAR is taken from CEA mode list if > VIC is found. Else, PAR is NONE as per initialization. > > v2: Removed the part which sets PAR according to user input, based on > Daniel's review comments.

[PATCHv4 04/13] drm/shmobile: Restrict plane loops to only operate on legacy planes

Hi Daniel, On Friday 28 March 2014 18:53:40 Daniel Vetter wrote: > On Fri, Mar 28, 2014 at 06:52:50PM +0100, Daniel Vetter wrote: > > On Fri, Mar 28, 2014 at 04:50:13PM +0100, Laurent Pinchart wrote: > > > On Thursday 27 March 2014 17:44:29 Matt Roper wrote: > > > > Ensure that existing driver

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

Hi Jean-Fran?ois, Sorry for the late reply. On Thursday 27 March 2014 12:34:49 Jean-Francois Moine wrote: > On Wed, 26 Mar 2014 18:33:09 +0100 Laurent Pinchart wrote: > > That could work in your case, but I don't really like that. > > > > We need to describe the hardware topology, that might be

[PATCHv4 06/13] drm: Add primary plane helpers (v2)

Hi Daniel, On Friday 28 March 2014 18:54:49 Daniel Vetter wrote: > On Fri, Mar 28, 2014 at 04:48:42PM +0100, Laurent Pinchart wrote: > > On Friday 28 March 2014 09:32:06 Daniel Vetter wrote: > > > On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote: > > > > When we expose non-overlay

[Bug 72701] Screen freeze when using radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=72701 --- Comment #7 from klod --- I think those patches are applied in 3.14 and 3.13.8, but i still need to use radeon.runpm=0 in order to boot with my discrete card. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 72701] Screen freeze when using radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=72701 --- Comment #8 from Alex Deucher --- (In reply to klod from comment #7) > I think those patches are applied in 3.14 and 3.13.8, but i still need to > use radeon.runpm=0 in order to boot with my discrete card. You have a PX system so those

[Bug 76919] New: Random junk at the bottom of non-multiple-of-4 compressed textures (original or mipmapped)

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/20140401/cf3d427c/attachment.html>

[Bug 76919] Random junk at the bottom of non-multiple-of-4 compressed textures (original or mipmapped)

vel/attachments/20140401/91d99836/attachment.html>

[PATCH 1/2] drm/crtc-helpers: fix dpms on logic

This was introduced in commit 25f397a429dfa43f22c278d0119a60a343aa568f Author: Daniel Vetter Date: Fri Jul 19 18:57:11 2013 +0200 drm/crtc-helper: explicit DPMS on after modeset but due to a bit of rebase fail on my side the patch actually merged put one hunk on the wrong side of a break

[PATCH 2/2] drm/crtc-helper: don't disable disconnected outputs

This is the equivalent change in the crtc helpers as done to the i915 modeset infrastructure in commit b0a2658acb5bf9ca86b4aab011b7106de3af0add Author: Daniel Vetter Date: Tue Dec 18 09:37:54 2012 +0100 drm/i915: don't disable disconnected outputs This was originally introduced to make

[PATCH] gpu: host1x: handle the correct # of syncpt regs

From: Stephen Warren BIT_WORD() truncates rather than rounds, so the loops in syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <= rather than < in an attempt to process the correct number of registers when rounding of the conversion of count of bits to

X.org doesn't start with 3.14: [KMS] drm report modesetting isn't supported

Hi Justin, CC-ing dri-devel as more KMS/radeon people will see it there. On Mon, 31 March 2014 "Justin Piszcz" wrote: > Do I need some updated ATI firmware (I believe this might have happened in > the past)..? > I booted back to 3.13.6, Xorg starts up fine, but with 3.14 it does not > start.

[Bug 73911] Color Banding on radeon

|(7660G + 7670M) | -- 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/20140401/fb9eabce/attachment.html>

[Bug 76884] Dithering not enabled on 6-bit per channel display

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140401/c5e7e9c9/attachment.html>

[Bug 73911] Color Banding on radeon

nts/20140401/8628383e/attachment.html>

[Bug 73911] Color Banding on radeon

TML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140401/3fed4b8f/attachment.html>

[Bug 72701] Screen freeze when using radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=72701 --- Comment #9 from klod --- Well, it seems so. What can I do to find what the problem is? -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCHv5 00/14] Universal plane preparation patches

Previous series revisions & explanation at [1], [2], [3], and [4] Just a few minor changes in this revision based on Daniel's feedback; I think this should be pretty close to being ready for merging: * Docbook integration for primary plane helpers and new functions (and a few minor updates to

[PATCHv5 07/14] drm: Add drm_universal_plane_init()

Add a new plane initialization interface for universal plane support that allows a specific plane type (primary, cursor, or overlay) to be specified. drm_plane_init() remains as a compatibility API to reduce churn in existing drivers. The 'bool priv' parameter has been changed to 'bool

[PATCHv5 09/14] drm: Add drm_crtc_init_with_planes() (v2)

Add a new drm_crtc_init_with_planes() to allow drivers to provide specific primary and cursor planes at CRTC initialization. The existing drm_crtc_init() interface remains to avoid driver churn in existing drivers; it will initialize the CRTC with a plane helper-created primary plane and no

[PATCHv5 01/14] drm: Add support for multiple plane types (v2)

The DRM core currently only tracks "overlay"-style planes. Start refactoring the plane handling to allow other plane types (primary and cursor) to also be placed on the DRM plane list. v2: Add drm_for_each_legacy_plane() iterator to smooth transition of drivers with plane loops.

[PATCHv5 08/14] drm: Add plane type property (v2)

Add a plane type property to allow userspace to distinguish plane types. v2: Driver-specific churn eliminated now that drm_plane_init() and drm_universal_plane_init() were separated out in a previous patch. Signed-off-by: Matt Roper --- drivers/gpu/drm/drm_crtc.c | 23

[PATCHv5 02/14] drm/exynos: Restrict plane loops to only operate on overlay planes (v2)

Ensure that existing driver loops over all planes do not change behavior when we begin adding new types of planes (primary and cursor) to the DRM plane list in future patches. v2: Switch to using drm_for_each_legacy_plane() Cc: Inki Dae Signed-off-by: Matt Roper ---

[PATCHv5 05/14] drm: Make drm_crtc_check_viewport non-static

This function will be used by the universal plane helpers and may also be useful for individual drivers. Signed-off-by: Matt Roper --- drivers/gpu/drm/drm_crtc.c | 20 +--- include/drm/drm_crtc.h | 4 2 files changed, 17 insertions(+), 7 deletions(-) diff --git

[PATCHv5 03/14] drm/i915: Restrict plane loops to only operate on overlay planes (v2)

Ensure that existing driver loops over all planes do not change behavior when we begin adding new types of planes (primary and cursor) to the DRM plane list in future patches. v2: Switch to using drm_for_each_legacy_plane() Cc: Intel Graphics Development Signed-off-by: Matt Roper ---

[PATCHv5 12/14] drm: Remove unused drm_crtc->fb

Signed-off-by: Matt Roper --- include/drm/drm_crtc.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index f147a84..c061bb3 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -311,9 +311,6 @@ struct drm_crtc { struct

[PATCHv5 13/14] drm: Allow userspace to ask for universal plane list (v2)

Userspace clients which wish to receive all DRM planes (primary and cursor planes in addition to the traditional overlay planes) may set the DRM_CLIENT_CAP_UNIVERSAL_PLANES capability. v2: Hide behind drm.universal_planes module option [suggested by Daniel Vetter] Signed-off-by: Matt Roper

[PATCHv5 14/14] drm/doc: Update plane documentation and add plane helper library

Signed-off-by: Matt Roper --- Documentation/DocBook/drm.tmpl | 50 -- 1 file changed, 43 insertions(+), 7 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 9f5457a..702c4474 100644 ---

[PATCHv5 06/14] drm: Add primary plane helpers (v3)

When we expose non-overlay planes to userspace, they will become accessible via standard userspace plane API's. We should be able to handle the standard plane operations against primary planes in a generic way via the modeset handler. Drivers that can program primary planes more efficiently,

[PATCHv5 10/14] drm/msm: Switch to universal plane API's

Use drm_universal_plane_init() and drm_crtc_init_with_planes() rather than the legacy drm_plane_init() / drm_crtc_init(). This will ensure that the proper primary plane is registered with the DRM (and eventually exposed to userspace in future patches). Cc: Rob Clark Signed-off-by: Matt Roper

[PATCHv5 11/14] drm: Replace crtc fb with primary plane fb (v3)

Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. This patch was generated by the Coccinelle semantic patching tool using the following rules: @@ struct drm_crtc C; @@ -

[PATCHv5 04/14] drm/shmobile: Restrict plane loops to only operate on legacy planes

Ensure that existing driver loops over all planes do not change behavior when we begin adding new types of planes (primary and cursor) to the DRM plane list in future patches. Acked-by: Laurent Pinchart Signed-off-by: Matt Roper --- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +- 1 file

[Bug 72701] Screen freeze when using radeon driver

https://bugzilla.kernel.org/show_bug.cgi?id=72701 --- Comment #10 from Alex Deucher --- Did manually powering on/off the dGPU via debugfs ever work on your system? See the "Forcing the power state of the devices" section of this page: http://nouveau.freedesktop.org/wiki/Optimus/ for how to test

[PULL] Universal plane support

Hi, Here's the latest iteration of the universal planes work, which I believe is finally ready for merging. Aside from the minor driver patches to use the new drm_for_each_legacy_plane() macro for plane loops, these should all have an r-b from Rob Clark now. Actual userspace-visibility is

Framebuffer corruption in QEMU or Linux's cirrus driver

On Tue, Apr 1, 2014 at 3:09 PM, Andy Lutomirski wrote: > Running: > > ./virtme-run --installed-kernel > > from this virtme commit: > > https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git/commit/?id=2b409a086d15b7a878c7d5204b1f44a6564a341f > > results in a bunch of missing lines of text

linux-next: Tree for Apr 1 (drivers/gpu/drm/i915)

On 04/01/2014 12:39 AM, Stephen Rothwell wrote: > Hi all, > > Please do not add material intended for v3.16 to your linux-next included > branches until after v3.15-rc1 is released. > > This tree still fails (more than usual) the powerpc allyesconfig build. > > Changes since 20140331: > for