[PATCH v4 1/1] Documentation: drm: describing plane alpha and color blending property

From: Sagar Kamble v2: Added description for "src-color" and "constant-alpha" property. [Review by Laurent Pinchart] v3: Fixed typos. [Review by David Herrmann] v4: Additional formatting and modified description. [Review by David Herrmann] Cc: rob at landley.net

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex

Hi On Wed, Mar 26, 2014 at 9:40 PM, Thomas Hellstrom wrote: >> - Why don't add a spin-lock to "drm_file" instead? Use that one to >> manage master contexts, but keep "struct_mutex" whenever calling into >> driver callbacks (set_master/drop_master) > > See above. We can't have a lock in the

[Bug 76659] Display does not return from DPMS off using ATI drivers

https://bugs.freedesktop.org/show_bug.cgi?id=76659 Tyler Brock changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG

[Bug 76659] Display does not return from DPMS off using ATI drivers

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/1813dda0/attachment.html>

[Bug 76659] Display does not return from DPMS off using ATI drivers

; dmesg.log" -- 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/20140328/96179c6f/attachment.html>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

Hi On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom wrote: > The master management was previously protected by the > drm_device::struct_mutex. > In order to avoid locking order violations in a reworked dropped master > security check in the vmwgfx driver, break it out into a separate >

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

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 > corrects that behaviour. > > See

[git pull] drm fixes

Hi Linus, didn't want these to wait for stable cycle, the nouveau and radeon ones are the same problem, where the runtime pm stuff broke non-runtime pm managed secondary GPUs, udl is an oops on unplug, and i915 is a regression fix on Sandybridge even though it may break haswell (regression

[Bug 42960] Display does not work when resuming from suspend

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/499d8348/attachment.html>

[PATCH 00/11] A few patches around DRM logging

On Tue, Mar 25, 2014 at 4:35 PM, Inki Dae wrote: > 2014-03-25 0:53 GMT+09:00 Damien Lespiau : >> As patch 8/11 explains, I noticed that we where evaluating the arguments to >> drm_ut_debug_printk() even when drm.debug was 0, doing some work for no good >> reason. By pulling the test on drm_debug

[Bug 76382] Mesa Gallium egllog _eglLog

problem exists in latest stable branch 10.0.4 -- 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/20140328/4bfbfd1d/attachment.html>

[PATCH] drm/i915: use __func__ instead of __FUNCTION__

On Fri, 28 Mar 2014, Christoph Jaeger wrote: > __FUNCTION__ is gcc specific; use __func__ instead. I acknowledge the patch is correct and functionally the same as before. However the correct fix would be to drop __FUNCTION__ and the corresponding "%s: " altogether as DRM_DEBUG_KMS includes

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

Hi, David. Thanks for reviewing. I'll try to address all your concerns and resend. /Thomas On 03/28/2014 01:19 AM, David Herrmann wrote: > Hi > > On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom > wrote: >> The master management was previously protected by the >> drm_device::struct_mutex.

[Intel-gfx] [PATCHv4 00/13] Universal plane preparation patches

On Thu, Mar 27, 2014 at 05:44:25PM -0700, Matt Roper wrote: > Previous series revisions & explanation at [1], [2], and [3] > > This version of the patch series focuses on isolating the DRM core changes > from > individual driver changes to (hopefully) make this a bit easier to merge. New >

[PATCHv4 09/13] drm: Add plane max width/height properties

On Thu, Mar 27, 2014 at 05:44:34PM -0700, Matt Roper wrote: > Some hardware has different size limits for different planes (e.g., > sprites/overlays can't always be as large as the upper bound for the > primary plane). Adding read-only plane properties allows userspace > to check these limits.

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

On Thu, Mar 27, 2014 at 05:44:31PM -0700, Matt Roper wrote: > 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

[PATCHv4 12/13] drm: Replace crtc fb with primary plane fb (v3)

On Thu, Mar 27, 2014 at 05:44:37PM -0700, Matt Roper wrote: > 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

[git pull] drm fixes

On Fri, Mar 28, 2014 at 02:46:11AM +, Dave Airlie wrote: > > Hi Linus, > > didn't want these to wait for stable cycle, the nouveau and radeon ones > are the same problem, where the runtime pm stuff broke non-runtime pm > managed secondary GPUs, udl is an oops on unplug, and i915 is a

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

Hi, again! I've looked through the code again and have some answers to your questions. Will post an updated patch soon. On 03/28/2014 01:19 AM, David Herrmann wrote: > Hi > > On Thu, Mar 27, 2014 at 9:23 PM, Thomas Hellstrom > wrote: >> The master management was previously protected by the >>

[PULL] drm-intel-next

Hi Dave, drm-intel-next-2014-03-21: - Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less flicker for fastbooting. - More flexible cloning for hdmi (Ville). - Some PPGTT fixes from Ben. - Ring init fixes from Naresh Kumar. - set_cache_level regression fixes for the vma

[PATCHv4 10/13] drm: Add drm_crtc_init_with_planes()

On Fri, Mar 28, 2014 at 1:44 AM, Matt Roper wrote: > 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

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

The master management was previously protected by the drm_device::struct_mutex. In order to avoid locking order violations in a reworked dropped master security check in the vmwgfx driver, break it out into a separate master_mutex. Locking order is master_mutex -> struct_mutex. Also remove

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v2

On 03/28/2014 01:19 AM, David Herrmann wrote: > Hi > > > > I also don't quite understand why you move the struct_mutex locking > into drm_master_destroy() instead of requiring callers to lock it as > before? I mean, the whole function is protected by the lock.. Before, struct_mutex was required

[PATCH] modetest: consider supported formats before selecting a DRM plane

This fixes an issue where the DRM planes do not support the same pixel formats. The current implementation selects a DRM plane without checking whether the pixel format is supported or not. As a consequence modetest may try to set up a plane not supporting the user request-format, which fails.

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

Hi Philipp, 2014-03-27 23:46 GMT+09:00 Philipp Zabel : > Hi Inki, > > Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae: >> 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

[PATCH] drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS

On Fri, 28 Mar 2014, Christoph Jaeger wrote: > DRM_DEBUG_KMS includes printing the function name. > > Signed-off-by: Christoph Jaeger Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/dvo_ns2501.c | 22 -- > 1 file changed, 8 insertions(+), 14 deletions(-) > > diff

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

Sorry for typo. 2014-03-28 19:46 GMT+09:00 Inki Dae : > Hi Philipp, > > > 2014-03-27 23:46 GMT+09:00 Philipp Zabel : >> Hi Inki, >> >> Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae: >>> This patch adds super device support to bind sub drivers >>> using device tree. >>> >>> For this,

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

Hi On Fri, Mar 28, 2014 at 10:34 AM, Thomas Hellstrom wrote: > The master management was previously protected by the > drm_device::struct_mutex. > In order to avoid locking order violations in a reworked dropped master > security check in the vmwgfx driver, break it out into a separate >

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

2014-03-27 23:46 GMT+09:00 Philipp Zabel : > Hi Inki, > > Am Donnerstag, den 27.03.2014, 21:43 +0900 schrieb Inki Dae: >> 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, >> >>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

On 03/28/2014 12:23 PM, David Herrmann wrote: > Hi > > On Fri, Mar 28, 2014 at 10:34 AM, Thomas Hellstrom > wrote: >> The master management was previously protected by the >> drm_device::struct_mutex. >> In order to avoid locking order violations in a reworked dropped master >> security check in

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

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. The patchset is based on exynos_drm_next branch. It is the 3rd iteration

[PATCH v3 01/12] drm/mipi_dsi: add flags to DSI messages

This patch adds flags field to mipi_dsi_msg structure and two flags: - MIPI_DSI_MSG_REQ_ACK - request ACK from peripheral for given message, - MIPI_DSI_MSG_USE_LPM - use Low Power Mode to transmit message. The first flag is usually helpful during DSI diagnostic, the second flag is required by some

[PATCH v3 03/12] drm/exynos: disallow fbdev initialization if no device is connected

This patch adds explicit check if there is a connector with connected status before fbdev initialization. It prevents creation of default fbdev 1024x768 which is unusable on panels with bigger resolutions. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 21

[PATCH v3 02/12] drm/mipi_dsi: create dsi devices only for nodes with reg property

MIPI DSI host node can contain child nodes which are not DSI devices. Checking for existence of reg property can be used to distinguish such nodes. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/drm_mipi_dsi.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH v3 04/12] exynos/dsim: add DT bindings

The patch adds DT bindings for Exynos DSI Master. DSIM follows rules for DSI bus host bindings [1]. Properties describes its resources: memory, interrupt, clocks, phy, regulators, frequencies of clocks and video interfaces. [1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt

[PATCH v3 06/12] panel/s6e8aa0: add DT bindings

The patch adds bindings for s6e8aa0 panel. Bindings describes panel resources, boot delays, display timings, orientation and physical size. Signed-off-by: Andrzej Hajda --- v2 - removed samsung prefix from panel physical size props, - renamed file to follow convention of panel bindings v3 -

[PATCH v3 07/12] drm/panel: add S6E8AA0 driver

The patch adds MIPI-DSI based S6E8AA0 AMOLED LCD panel driver. Driver uses mipi_dsi bus to communicate with panel and exposes drm_panel interface. Signed-off-by: Andrzej Hajda --- v2 - added bus error handling, - set maxmimum DSI packet size on init, - removed unsupported brightness drm_panel

[PATCH v3 08/12] ARM: dts: exynos4: add MIPI DSI Master node

This is a common part of DSI node for all Exynos4 boards. Signed-off-by: Andrzej Hajda --- arch/arm/boot/dts/exynos4.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi index 08452e1..3d14cdb 100644 ---

[PATCH v3 05/12] drm/exynos: add DSIM driver

The patch adds driver for Exynos DSI master (DSIM). It is a platform driver which is registered as exynos_drm_display sub-driver of exynos_drm framework and implements DRM encoder/connector pair. It is also MIPI-DSI host driver and provides DSI bus for panels. It interacts with its panel(s) using

[PATCH v3 11/12] ARM: dts: exynos4210-trats: enable exynos/fimd node

The patch changes fimd node status to OK. Signed-off-by: Andrzej Hajda --- arch/arm/boot/dts/exynos4210-trats.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts index 996c7e3..02c6768 100644 ---

[PATCH v3 10/12] ARM: dts: exynos4412-trats2: add panel node

The patch adds s6e8aa0 panel node for trats2. It adds also trats2 specific properties for DSI and regulator required by panel. Signed-off-by: Andrzej Hajda --- arch/arm/boot/dts/exynos4412-trats2.dts | 66 + 1 file changed, 66 insertions(+) diff --git

[PATCH v3 12/12] ARM: dts: exynos4412-trats2: enable exynos/fimd node

The patch changes fimd node status to OK. Signed-off-by: Andrzej Hajda --- arch/arm/boot/dts/exynos4412-trats2.dts | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts index f7070e9..53c717b 100644 ---

[PATCH v3 09/12] ARM: dts: exynos4210-trats: add panel node

The patch adds s6e8aa0 panel node for trats. It adds also trats specific properties for DSI. Signed-off-by: Andrzej Hajda --- arch/arm/boot/dts/exynos4210-trats.dts | 57 ++ 1 file changed, 57 insertions(+) diff --git a/arch/arm/boot/dts/exynos4210-trats.dts

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

dri-devel/attachments/20140328/4c126adb/attachment.html>

[PATCH 06/16] drm: Protect the master management with a drm_device::master_mutex v3

Hi On Fri, Mar 28, 2014 at 12:52 PM, Thomas Hellstrom wrote: > Thanks. Want a Reviewed-By: or Acked-By: added? Oh, sure: Reviewed-by: David Herrmann Thanks David

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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/20140328/e851ec36/attachment.html>

[PATCH] drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH, HEIGHT} caps

Earlier this week, there was a bit of confusion about those new capabilities, to the point I think it's better to document the intention and API contract. The comment documents the current situation: - the radeon driver returns the only valid size for the hw - i915 returns the maximun cursor

[PATCH] drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH,HEIGHT} caps

On Fri, Mar 28, 2014 at 12:31:05PM +, Damien Lespiau wrote: > Earlier this week, there was a bit of confusion about those new > capabilities, to the point I think it's better to document the intention > and API contract. > > The comment documents the current situation: > - the radeon driver

[PATCH] drm: Specify a bit more the DRM_CAP_CURSOR_{WIDTH,HEIGHT} caps

> -Original Message- > From: Damien Lespiau [mailto:damien.lespiau at intel.com] > Sent: Friday, March 28, 2014 8:31 AM > To: dri-devel at lists.freedesktop.org > Cc: intel-gfx at lists.freedesktop.org; Sagar Kamble; Chris Wilson; Deucher, > Alexander; Imre Deak > Subject: [PATCH] drm:

[PULL] vmwgfx-next

Dave, vmwgfx render-node support and drm + ttm changes it depends upon. The following changes since commit 60f2b4af1258c05e6b037af866be81abc24438f7: drm/i915: fix build warning on 32-bit (v2) (2014-03-28 13:40:48 +1000) are available in the git repository at:

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

ck. -- 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/20140328/54a1fde8/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

<http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/9d429cd8/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

ues that are currently being used -- 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/20140328/423b2042/attachment-0001.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

and try to improve the numbers without toasting the hardware. -- 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/20140328/3f397ae9/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

asting the hardware. So that would mean for example using fb=29.7 Ref=2 post=10? Or would that fry the hardware? Why must it exactly match? Because for fgrlx it seems roughly 30% higher than needed -- 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/20140328/ab29126a/attachment.html>

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

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 planes to userspace, they will become > > accessible via standard userspace plane API's. We should be able to > > handle the standard plane operations

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

Hi Matt, Thank you for the patch. On Thursday 27 March 2014 17:44:29 Matt Roper wrote: > 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. > > Cc: Laurent Pinchart

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

rs without toasting the hardware. > > So that would mean for example using fb=29.7 Ref=2 post=10? > > Or would that fry the hardware? That should work. You aren't likely to fry the hw. You just don't want to set a 400 Mhz clock as you monitor properly won't like it. The hard part

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

gt;pll_out_min. I think the problem is that we don't try to choose a good value to match the target frequency as close as possible in avivo_get_post_div, but just a value that either matches the maximum or minimum VCO frequency. -- You are receiving this mail because: You are the assignee for the bu

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

If I know which values for fb,ref and post to use for 23.976fps I can hard code these In a patch and test if it indeed works. So which values are save to get a clock of 74.2MHz? -- 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/20140328/dba7afc7/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

hives/dri-devel/attachments/20140328/99e01759/attachment.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

g/archives/dri-devel/attachments/20140328/4a92064c/attachment.html>

[PATCH] drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS

On Fri, Mar 28, 2014 at 12:49:26PM +0200, Jani Nikula wrote: > On Fri, 28 Mar 2014, Christoph Jaeger wrote: > > DRM_DEBUG_KMS includes printing the function name. > > > > Signed-off-by: Christoph Jaeger > > Reviewed-by: Jani Nikula Queued for -next, thanks for the patch. -Daniel > > > > ---

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

On Fri, Mar 28, 2014 at 04:50:13PM +0100, Laurent Pinchart wrote: > Hi Matt, > > Thank you for the patch. > > On Thursday 27 March 2014 17:44:29 Matt Roper wrote: > > Ensure that existing driver loops over all planes do not change behavior > > when we begin adding new types of planes (primary

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

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: > > Hi Matt, > > > > Thank you for the patch. > > > > On Thursday 27 March 2014 17:44:29 Matt Roper wrote: > > > Ensure that existing driver loops over all planes do

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

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 planes to userspace, they will become > > > accessible via standard userspace

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

[PATCHv4 10/13] drm: Add drm_crtc_init_with_planes()

On Thu, Mar 27, 2014 at 05:44:35PM -0700, Matt Roper wrote: > 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

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/a6196b96/attachment-0001.html>

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

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

[Bug 75992] Display freezes & corruption with an r7 260x on 3.14-rc6

ext part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140328/ed9afd8f/attachment.html>

[RFCv3 12/14] drm: Specify cursor plane at CRTC initialization

On Tue, Mar 18, 2014 at 05:22:57PM -0700, Matt Roper wrote: > Add cursor plane as a parameter to drm_crtc_init() and update all > existing DRM drivers to use a helper-provided primary plane. Passing > NULL for this parameter indicates that there is no hardware cursor > supported by the driver and

[PATCH v2] drm/omap: Don't dereference list head when the connectors list is empty

Hi Rob, On Tuesday 24 December 2013 12:58:01 Laurent Pinchart wrote: > The connectors list iterator returns the list head when the list is > empty. Fix it by returning NULL in that case. > > Signed-off-by: Laurent Pinchart Could you please take this patch in your tree ? > --- >

[PATCH v2] drm/omap: Don't dereference list head when the connectors list is empty

On Fri, Mar 28, 2014 at 5:56 PM, Laurent Pinchart wrote: > Hi Rob, > > On Tuesday 24 December 2013 12:58:01 Laurent Pinchart wrote: >> The connectors list iterator returns the list head when the list is >> empty. Fix it by returning NULL in that case. >> >> Signed-off-by: Laurent Pinchart > >

[PATCH] drm: Add 800x600 (SVGA) screen resolution to the built-in EDIDs

The 800x600 (SVGA) screen resolution was lacking in the set of built-in selectable EDID screen resolutions that can be used to repair misbehaving monitor firmware. This patch adds the related data set and expands the documentation. Note that the SVGA bit occupies a different byte to all the

[PATCH] drm/i915: use __func__ instead of __FUNCTION__

__FUNCTION__ is gcc specific; use __func__ instead. Signed-off-by: Christoph Jaeger --- drivers/gpu/drm/i915/dvo_ns2501.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c b/drivers/gpu/drm/i915/dvo_ns2501.c index

[PATCH] drm/i915: drop __FUNCTION__ as argument to DRM_DEBUG_KMS

DRM_DEBUG_KMS includes printing the function name. Signed-off-by: Christoph Jaeger --- drivers/gpu/drm/i915/dvo_ns2501.c | 22 -- 1 file changed, 8 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c b/drivers/gpu/drm/i915/dvo_ns2501.c index

[PATCH] drm/i915: use __func__ instead of __FUNCTION__

Thanks for review. This patch obsoletes patch "drm/i915: use __func__ instead of __FUNCTION__". Best, Chris