[PULL] drm-amdkfd-next

s, a) pull request from ssh:// please fix scripts to generate git:// URLs, b) ioctls with bool in them make me worry, four packed bool's even more, 4 packed bools with a 64-bit straight after them put me over the not pulling this edge. I don't trust bools in ioctl defintions, please use exp

[Bug 90481] Radeon R9 270X gpu lockup in game spec ops: the line.

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

[Bug 90484] LLVM >=r237140 causes gpu lockups Spec Ops: The Line

L: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/87e179f5/attachment.html>

[PATCH] drm/exynos: dp: Lower level of EDID read success message

> Don't pollute the dmesg with EDID read success message as an error. > Printing as debug should be fine. > > Signed-off-by: Krzysztof Kozlowski Right, dev_err() is not right. Thank you for sending the patch. Acked-by: Jingoo Han Best regards, Jingoo Han > --- >

[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver

ng 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/20150519/fd8d5605/attachment.html>

[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds

On 19.05.2015 01:24, Alex Deucher wrote: > > @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct *work) > struct drm_connector *connector; > > /* this should take a mutex */ > + mutex_lock(_config->mutex); This comment can be removed? -- Earthling Michel

[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds

On 19 May 2015 at 12:27, Michel Dänzer wrote: > On 19.05.2015 01:24, Alex Deucher wrote: >> >> @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct *work) >> struct drm_connector *connector; >> >> /* this should take a mutex */ >> + mutex_lock(_config->mutex); >

[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds

On Mon, May 18, 2015 at 11:24 PM, Dave Airlie wrote: > On 19 May 2015 at 12:27, Michel Dänzer wrote: >> On 19.05.2015 01:24, Alex Deucher wrote: >>> >>> @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct >>> *work) >>> struct drm_connector *connector; >>> >>> /*

[PULL] drm-amdkfd-next

put me over the not pulling this edge. > > I don't trust bools in ioctl defintions, please use explicitly sized types. > > Dave. Thanks Dave, No problem, I'll fix and resend it today. Oded -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/69a311fc/attachment.html>

radeon: ring 0 stalled for more than 10480msec

May 18 21:38:55 arcadia kernel: [0.00] Linux version 4.0.0-1-amd64 (debian-kernel at lists.debian.org) (gcc version 4.9.2 (Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11) May 18 21:38:55 arcadia kernel: [3.467818] [drm] radeon/VERDE_mc2.bin: 31500 bytes May 19 00:06:08 arcadia

[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction

Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Use this to simplify the driver. Furthermore this is one caller less that stops

[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction

Hello, the subject is missing "ps8622" before the :. Should I resend for that? On Tue, May 19, 2015 at 09:03:49AM +0200, Uwe Kleine-König wrote: > drivers/gpu/drm/bridge/ps8622.c | 20 +--- > 1 file changed, 5 insertions(+), 15 deletions(-) Best regards Uwe -- Pengutronix

[PATCH] drm/bridge/ptn3460: use flags argument of devm_gpiod_get to set direction

Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Use this to simplify the driver. Furthermore this is one caller less that stops

[PATCH v2] drm/i915: fix screen flickering

On Thu, 14 May 2015, Matt Roper wrote: > On Thu, May 14, 2015 at 09:16:39AM +0200, Thomas Gummerer wrote: >> Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are >> always on for wm calculation (v4)") fixes a null pointer dereference. >> Setting the primary and cursor panes to false

[PATCH] drm/msm: use devm_gpiod_get_optional for optional reset gpio

Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Also there is a variant to find optional gpios that returns NULL if there is no

[Bug 90484] LLVM >=r237140 causes gpu lockups Spec Ops: The Line

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

[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds

On Mon, May 18, 2015 at 11:28:47PM -0400, Alex Deucher wrote: > On Mon, May 18, 2015 at 11:24 PM, Dave Airlie wrote: > > On 19 May 2015 at 12:27, Michel Dänzer wrote: > >> On 19.05.2015 01:24, Alex Deucher wrote: > >>> > >>> @@ -96,10 +98,12 @@ static void radeon_dp_work_func(struct work_struct

[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction

as scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/f53621bb/attachment.sig>

[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction

-- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/5d4f030c/attachment.sig>

[PATCH] drm/bridge/ptn3460: use flags argument of devm_gpiod_get to set direction

ignature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/dddba69a/attachment.sig>

[PATCH] drm/bridge: use flags argument of devm_gpiod_get to set direction

Hello, On Tue, May 19, 2015 at 10:06:54AM +0200, Thierry Reding wrote: > On Tue, May 19, 2015 at 09:03:49AM +0200, Uwe Kleine-König wrote: > > Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) > > which appeared in v3.17-rc1, the gpiod_get* functions take an additional > >

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

Allow drm_bridge objects to link to each other in order to form an encoder chain. The requirement for creating a chain of bridges comes because the MSM drm driver uses up its encoder and bridge objects for blocks within the SoC itself. There isn't anything left to use if the SoC display output is

[PATCH v3 2/2] drm: bridge: Add missing headerdocs for older bridge functions

Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and of_drm_find_bridge. Signed-off-by: Archit Taneja --- drivers/gpu/drm/drm_bridge.c | 28 1 file changed, 28 insertions(+) diff --git a/drivers/gpu/drm/drm_bridge.c

[Bug 89713] [radeon]GPU lockup in World of Tanks with gallium nine

начинает уменьшаться и игра вылетает -- 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/20

[Bug 89713] [radeon]GPU lockup in World of Tanks with gallium nine

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/0c4de147/attachment.html>

[Bug 90515] memory use increase with vdpau

with two different drawables, each call destroying the previous drawable. -- 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/20150

[Bug 89713] [radeon]GPU lockup in World of Tanks with gallium nine

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/65abb551/attachment-0001.html>

[Bug 87856] Driver load fails with no error on ppc64 host

efore) Regards, Kristof -- 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/20150519/69bd7f8c/attachment.html>

gma500: initial medfield merge

Hello Kirill A. Shutemov, The patch 026abc333205: "gma500: initial medfield merge" from Mar 8, 2012, leads to the following static checker warning: drivers/gpu/drm/gma500/mdfld_intel_display.c:102 mdfldWaitForPipeEnable() warn: masked condition '(temp & (1 << 30)) == 1' is

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote: > Allow drm_bridge objects to link to each other in order to form an encoder > chain. The requirement for creating a chain of bridges comes because the > MSM drm driver uses up its encoder and bridge objects for blocks within > the SoC

[PATCH v3 2/2] drm: bridge: Add missing headerdocs for older bridge functions

On Tue, May 19, 2015 at 02:05:05PM +0530, Archit Taneja wrote: > Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and > of_drm_find_bridge. > > Signed-off-by: Archit Taneja You also need to pull in the kerneldoc into the drm.tmpl DocBook template to include into the drm

[PATCH 1/2] drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name

Hi Vladimir, Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy: > I2CM_ADDRESS became a MESS, fix it, also change guarding define > to __DW_HDMI_H__ , since the driver is not IMX specific. > > Signed-off-by: Vladimir Zapolskiy Acked-by: Philipp Zabel regards Philipp

[PULL resend] drm-amdkfd-next

Hi Dave, Resending the pull request of amdkfd for 4.2 after fixing what you requested (bool -> uint32_t and using git:// instead of ssh://) drm-amdkfd-next-2015-05-19: - Add the interrupts & events modules, including new IOCTLs to create and wait on events. The HSA RT open source stack is

[PATCH 1/2] drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name

Hi Vladimir, Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy: > I2CM_ADDRESS became a MESS, fix it, also change guarding define > to __DW_HDMI_H__ , since the driver is not IMX specific. > > Signed-off-by: Vladimir Zapolskiy Acked-by: Philipp Zabel regards Philipp

[PATCH v2 2/2] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

Hi Vladimir, Am Montag, den 18.05.2015, 15:32 +0300 schrieb Vladimir Zapolskiy: > The change adds support of internal HDMI I2C master controller, this > subdevice is used by default, if "ddc-i2c-bus" DT property is omitted. > > The main purpose of this functionality is to support reading EDID

[PATCH v6 06/11] cec: add HDMI CEC framework

Hi Sean, I'm taking over this patch series from Kamil for the time being with his permission (he's switching jobs and moving house so he can't spend any time on this for a while). On 05/13/15 13:10, Sean Young wrote: > On Mon, May 04, 2015 at 07:32:59PM +0200, Kamil Debski wrote: >> From: Hans

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

Hi, On 05/19/2015 03:04 PM, Daniel Vetter wrote: > On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote: >> Allow drm_bridge objects to link to each other in order to form an encoder >> chain. The requirement for creating a chain of bridges comes because the >> MSM drm driver uses up its

[PATCH v3 2/2] drm: bridge: Add missing headerdocs for older bridge functions

On 05/19/2015 03:07 PM, Daniel Vetter wrote: > On Tue, May 19, 2015 at 02:05:05PM +0530, Archit Taneja wrote: >> Add headerdocs for drm_bridge_add, drm_bridge_remove, drm_bridge_attach and >> of_drm_find_bridge. >> >> Signed-off-by: Archit Taneja > > You also need to pull in the kerneldoc into

Experiencing FIFO underruns on Intel Skylake platform

Hi, I'm testing the vanilla kernel on prototype boards for Intel Skylake. The graphics adapter on those boards identifies like this: 00:02.0 0300: 8086:1912 (rev 04) (prog-if 00 [VGA controller]) Subsystem: 1734:121c Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-

[PATCH] drm/ttm: dma: Don't crash on memory in the vmalloc range

On 05/16/2015 04:55 AM, Konrad Rzeszutek Wilk wrote: > On Fri, May 15, 2015 at 04:09:54PM +0900, Alexandre Courbot wrote: >> dma_alloc_coherent() can return memory in the vmalloc range. >> virt_to_page() cannot handle such addresses and crashes. This >> patch detects such cases and obtains the

Experiencing FIFO underruns on Intel Skylake platform

+intel-gfx On Tue, 19 May 2015, Rainer Koenig wrote: > Hi, > > I'm testing the vanilla kernel on prototype boards for Intel Skylake. > The graphics adapter on those boards identifies like this: > > 00:02.0 0300: 8086:1912 (rev 04) (prog-if 00 [VGA controller]) > Subsystem: 1734:121c >

[PATCH] drm: drop drm_property_unreference_blob_locked()

drm_property_unreference_blob_locked() is static and unused, drop it. Signed-off-by: Sergey Senozhatsky --- drivers/gpu/drm/drm_crtc.c | 19 --- 1 file changed, 19 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 4059f06..6e60f71 100644

Experiencing FIFO underruns on Intel Skylake platform

Am 19.05.2015 um 13:41 schrieb Jani Nikula: > > For brand new platforms you should be running drm-intel-nightly branch > from http://cgit.freedesktop.org/drm-intel. Thanks, will try out next. > Double check that you have either i915.preliminary_hw_support=1 module > parameter set or

[PATCH] drm/nouveau/platform: add IOMMU dependency

The recently added iommu code in the nouveau driver fails to build when the IOMMU support is disabled: drivers/gpu/drm/nouveau/nouveau_platform.c: In function 'nouveau_platform_probe_iommu': drivers/gpu/drm/nouveau/nouveau_platform.c:113:41: error: 'const struct iommu_ops' has no mem To avoid

[PATCH] drm/nouveau/platform: add IOMMU dependency

IOMMU if present") Acked-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/b896fe1c/attachment.sig>

drm/exynos: Add atomic modesetting support

Hello, On 2015-05-18 23:02, Gustavo Padovan wrote: > 2015-05-18 Daniel Stone : > >> Hi, >> >> On Monday, May 18, 2015, Gustavo Padovan wrote: >> >> > Hi Tobias, >> > >> > 2015-05-15 Tobias Jakobi >: >> > > I did another run with drm.debug=0xff and also tried to figure out where >> > the >> >

[PATCH] drm/amdkfd: fix topology bug with capability attr.

From: Alexey Skidanov This patch fixes a bug where the number of watch points was shown before it was actually calculated Signed-off-by: Alexey Skidanov Cc: stable at vger.kernel.org Signed-off-by: Oded Gabbay --- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 4 ++-- 1

drm/exynos: Add atomic modesetting support

Hi Tobias, On 19 May 2015 at 14:53, Tobias Jakobi wrote: > On 2015-05-18 23:02, Gustavo Padovan wrote: >> So better try this. Ideally fimd_mode_fixup should go away too, I'll do a >> proper >> patch once we know this works. >> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c >>

[PULL] topic/drm-misc

Hi Dave, Scattering of random drm core patches. Bunch of atomic prep work too, but the final bits for blob properties, atomic modesets and lifting the experimental tag on the atomic ioctl are still blocked on Daniel Stone finalizing and testing the weston support for it. I hope that we can get it

[PATCH] drm/imx: parallel-display: fix drm_panel support

The parallel-display driver used an undocumented, non-standard property "fsl,panel" to optionally associate with a drm_panel device. This patch fixes the driver to use the same OF graph bindings as the LDB driver instead: parallel-display { compatible = "fsl,imx-parallel-display";

[PATCH v2 0/3] drm_of_encoder_active_endpoint helpers

Hi, this patch factors out the mostly identical imx_drm_encoder_get_mux_id and rockchip_drm_encoder_get_mux_id functions into a common helper to parse the active endpoint and two inline functions to return its id or port id. All prerequisites are now upstream. I'd like to get an Acked-by from

[PATCH v2 3/3] drm/rockchip: remove rockchip_drm_encoder_get_mux_id

It is replaced by drm_of_encoder_active_endpoint_id. Suggested-by: Daniel Kurtz Reviewed-by: Daniel Kurtz Signed-off-by: Philipp Zabel --- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 30 -

[PATCH v2 1/3] drm: add drm_of_encoder_active_endpoint helpers

This patch adds a helper to parse the encoder endpoint connected to the encoder's crtc and two helpers to return its id and port id. This can be used to determine input mux setting from endpoint or port ids. Suggested-by: Daniel Kurtz Reviewed-by: Daniel Kurtz Signed-off-by: Philipp Zabel ---

[PATCH v2 2/3] drm/imx: remove imx_drm_encoder_get_mux_id

It is replaced by drm_of_encoder_active_port_id. Suggested-by: Daniel Kurtz Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/dw_hdmi-imx.c | 2 +- drivers/gpu/drm/imx/imx-drm-core.c | 30 -- drivers/gpu/drm/imx/imx-drm.h | 2 --

[PATCH 2/3] drm/atomic: add drm_atomic_add_affected_planes

This is a convenience function to add all planes for a crtc, similar to add_affected_connectors. This will be used in drm_atomic_helper_check_modeset, but drivers can call it too when they need to recalculate all state. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic.c | 32

[PATCH 3/3] drm/atomic: add all affected planes in drm_atomic_helper_check_modeset

Drivers may need to recalculate plane state when a modeset occurs, not reliably adding them might cause hard to debug bugs. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c

[PATCH 1/3] drm/atomic: add commit_planes_on_crtc helper

drm_atomic_helper_commit_planes calls all atomic_begin's first, then updates all planes, finally calling atomic_flush. Some drivers may want to things like disabling irq's from their atomic_begin, in which case a second call to atomic_begin will splat. By using commit_planes_on_crtc on each crtc

drm/exynos: Add atomic modesetting support

Hey Daniel, On 2015-05-19 16:06, Daniel Stone wrote: > Hi Tobias, > > On 19 May 2015 at 14:53, Tobias Jakobi > wrote: >> On 2015-05-18 23:02, Gustavo Padovan wrote: >>> So better try this. Ideally fimd_mode_fixup should go away too, I'll >>> do a >>> proper >>> patch once we know this works.

[RFC PATCH 00/11] drm/i915: Expose OA metrics via perf PMU

On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote: > On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra > wrote: > > On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote: > > > >> I've changed the uapi for configuring the i915_oa specific attributes > >> when calling

[PATCH] drm/msm: use devm_gpiod_get_optional for optional reset gpio

On Tue, May 19, 2015 at 9:40 AM, Uwe Kleine-König wrote: > Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) > which appeared in v3.17-rc1, the gpiod_get* functions take an additional > parameter that allows to specify direction and initial value for output. > > Also there

[PATCH v3 1/2] drm: bridge: Allow daisy chaining of bridges

On Tue, May 19, 2015 at 04:37:44PM +0530, Archit Taneja wrote: > On 05/19/2015 03:04 PM, Daniel Vetter wrote: > >On Tue, May 19, 2015 at 02:05:04PM +0530, Archit Taneja wrote: > >>+void drm_bridge_post_disable(struct drm_bridge *bridge) > >>+{ > >>+ if (!bridge) > >>+ return; > >>+ >

[PATCH 6/7] drm: add RGB formats with separate alpha plane

Some hardware can read the alpha components separately and then conditionally fetch color components only for non-zero alpha values. This patch adds fourcc definitions for two-plane RGB formats with an 8-bit alpha channel on a second plane. Signed-off-by: Philipp Zabel ---

[PATCH 1/7] gpu: ipu-v3: Add support for 15-bit RGB with 1-bit alpha formats

This patch adds support for ARGB1555, ABGR1555, RGBA5551, and BGRA5551 in-memory formats. Signed-off-by: Philipp Zabel --- drivers/gpu/ipu-v3/ipu-common.c | 4 drivers/gpu/ipu-v3/ipu-cpmem.c | 44 + 2 files changed, 48 insertions(+) diff --git

[PATCH 5/7] drm/imx: ipuv3-plane: enable support for RGBX8888 and RGBA8888 pixel formats

This patch allows to use the RGBX and RGBA 8:8:8:8 formats. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/ipuv3-plane.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index d13dbb6..d030990 100644 ---

[PATCH 0/7] imx-drm: additional alpha transparency formats

Hi, this series adds support for more alpha transpancy formats such as RGBA 8:8:8:8, ARGB 1:5:5:5, and the more esoteric formats with 8-bit alpha on a separate plane. For the latter, new 2-plane RGB formats are added: DRM_FORMAT_XRGB_A8 DRM_FORMAT_XBGR_A8

[PATCH 3/7] gpu: ipu-v3: add support for RGBX8888 and RGBA8888 pixel formats

Signed-off-by: Philipp Zabel --- drivers/gpu/ipu-v3/ipu-cpmem.c | 32 1 file changed, 28 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-cpmem.c b/drivers/gpu/ipu-v3/ipu-cpmem.c index d26b8be..0e6b868 100644 --- a/drivers/gpu/ipu-v3/ipu-cpmem.c

[PATCH 4/7] gpu: ipu-v3: add support for separate alpha channels

The IPUv3 can read 8-bit alpha values from a separate IDMAC channel driven by the Alpha Transparency Controller (ATC) for the graphics IDMAC channels. This allows to reduce memory bandwidth via a conditional read mechanism or to support planar YUV formats with alpha transparency. Signed-off-by:

[PATCH 2/7] drm/imx: Add support for 15-bit RGB with 1-bit alpha formats

Signed-off-by: Philipp Zabel --- drivers/gpu/drm/imx/ipuv3-plane.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c b/drivers/gpu/drm/imx/ipuv3-plane.c index 878a643..d13dbb6 100644 --- a/drivers/gpu/drm/imx/ipuv3-plane.c +++

[PATCH 7/7] drm/imx: ipuv3-plane: add support for separate alpha planes

The IPUv3 can read 8-bit alpha values from a separate plane buffer using a companion IDMAC channel driven by the Alpha Transparency Controller (ATC) for the graphics channels. The conditional read mechanism allows to reduce memory bandwidth by skipping reads of color data for completely

[PATCH] drm/radeon: take the mode_config mutex when dealing with hpds (v2)

Since we are messing with state in the worker. v2: drop the changes in the mst worker Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_irq_kms.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c

[PATCH] drm/radeon: properly select encoder in radeon_audio_detect (v2)

Need to handle DVI where we way end up with an analog encoder in some cases. v2: rework checks. always set use_digital for DVI-D, HDMI-A Reported-by: Julian Margetson Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/radeon_audio.c | 20

[PATCH 6/7] drm: add RGB formats with separate alpha plane

On Tue, May 19, 2015 at 06:06:00PM +0200, Philipp Zabel wrote: > Some hardware can read the alpha components separately and then > conditionally fetch color components only for non-zero alpha values. > This patch adds fourcc definitions for two-plane RGB formats with an > 8-bit alpha channel on a

[PATCH 7/7] drm/imx: ipuv3-plane: add support for separate alpha planes

On Tue, May 19, 2015 at 06:06:01PM +0200, Philipp Zabel wrote: > The IPUv3 can read 8-bit alpha values from a separate plane buffer using a > companion IDMAC channel driven by the Alpha Transparency Controller (ATC) > for the graphics channels. The conditional read mechanism allows to reduce >

[Intel-gfx] [PATCH 1/3] drm/atomic: add commit_planes_on_crtc helper

On Tue, May 19, 2015 at 04:41:01PM +0200, Maarten Lankhorst wrote: > drm_atomic_helper_commit_planes calls all atomic_begin's first, > then updates all planes, finally calling atomic_flush. > > Some drivers may want to things like disabling irq's > from their atomic_begin, in which case a second

drm/exynos: Add atomic modesetting support

OK, so Daniel helped me track down this issue. It came from an incorrect 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended 7060 which works 'fine' (and according to modetest produces a 59Hz mode). I say 'fine' because I can't confirm that FIMD is actually working.

drm/exynos: Add atomic modesetting support

Hi Tobias, 2015-05-19 Tobias Jakobi : > OK, > > so Daniel helped me track down this issue. It came from an incorrect > 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended > 7060 which works 'fine' (and according to modetest produces a 59Hz > mode). I say 'fine'

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux

ow. -- 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/20150519/4e95d716/attachment-0001.html>

drm/exynos: Add atomic modesetting support

Hi, On 19 May 2015 at 19:43, Gustavo Padovan wrote: > 2015-05-19 Tobias Jakobi : >> so Daniel helped me track down this issue. It came from an incorrect >> 'clock-frequency' entry in my DTS. The freq was 50. Daniel recommended >> 7060 which works 'fine' (and according to modetest

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux

ML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150519/75a91ff4/attachment.html>

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

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/20150519/19246e8c/attachment.html>

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

) OS|All |Linux (All) -- 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/20150519/b4ffac45/attachment.html>

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150519/37896446/attachment.html>

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

tachments/20150519/c36d5bd5/attachment.html>

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

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

[Bug 90523] Easily reproducible GPU lockup (verde) with any mesa 10.5.x

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

[PATCH] Do not loop on ERESTARTSYS using interruptible waits

This problem happens using KMS surfaces and QXL driver. To easy reproduce use KDE Plasma (which use surfaces a lot) and assure you are using KMS surfaces (QXL driver on Fedora/RedHat has a patch to stop using them). Open some complex application like LibreOffice and after a while your machine get

[PATCH 1/2] drm: bridge/dw_hdmi: fix register I2CM_ADDRESS register name

Hi Vladimir, Thanks for you patch. On 2015年05月18日 20:32, Vladimir Zapolskiy wrote: > I2CM_ADDRESS became a MESS, fix it, also change guarding define > to __DW_HDMI_H__ , since the driver is not IMX specific. > > Signed-off-by: Vladimir Zapolskiy Acked-by: Andy Yan > --- >

[PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype

On 05/16, Mikko Perttunen wrote: > On 05/15/2015 06:40 PM, Boris Brezillon wrote: > >Hi Stephen, > > > >Adding Mikko in the loop (after all, he was the one complaining about > >this signed long limitation in the first place, and I forgot to add > >him in the Cc list :-/). > > I think I got it

[EDT][PATCh 1/1]mdfld_dsi_pkg_sender.c : Fix Possible NULL Pointer dereference

EP-AA9D1F29B02341529D96C06444D8471D Hi, There is NULL pointer check for sender after dereferencing sender in __read_panel_data as below:- struct drm_device *dev = sender->dev; ... if (!sender || !data || !len) And from codeflow mdfld_dsi_get_panel_status --> mdfld_dsi_read_mcs -->

[PATCH 00/12] treewide: Use DECLARE_BITMAP

Use the standard method to declare a bitmap array. Joe Perches (12): ARM: mach-imx: iomux-imx31: Use DECLARE_BITMAP dmaengine: rcar-dmac: Use DECLARE_BITMAP drm/amdkfd: Use DECLARE_BITMAP drm/radeon: Use DECLARE_BITMAP IB/ehca: Use DECLARE_BITMAP bcache: Use DECLARE_BITMAP

[PATCH 04/12] drm/radeon: Use DECLARE_BITMAP

Use the generic mechanism to declare a bitmap instead of unsigned long. Signed-off-by: Joe Perches --- drivers/gpu/drm/radeon/radeon.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 46eb0fa..d556733

[PATCH 03/12] drm/amdkfd: Use DECLARE_BITMAP

Use the generic mechanism to declare a bitmap instead of unsigned long. It seems that "struct kfd_process.allocated_queue_bitmap" is unused. Maybe it could be deleted instead. Signed-off-by: Joe Perches --- drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 5 ++--- 1 file changed, 2 insertions(+), 3