[Bug 93615] Tonga does not recover from standby

major improvement to the drm-next-4.5 branch! -- 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/20160107/0d6c5b33/attachment.html>

[Bug 93614] Tonga general protection fault in libdrm_amdgpu at di.fm

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20160107/b5add0db/attachment.html>

[Bug 93614] Tonga general protection fault in libdrm_amdgpu at di.fm

rubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160107/5be9089e/attachment.html>

[RFC PATCH v1 0/2] Add RK3229 HDMI support

RK3229 have integrated an DesignedWare HDMI controller and an INNO HDMI phy, so we can still reuse the dw-hdmi driver for RK3229 HDMI controller, but we need to create an separate driver for RK3229 HDMI PHY. Yakir Yang (2): drm: rockchip: hdmi: add RK3229 HDMI support dt-bindings: add

[RFC PATCH v1 1/2] drm: rockchip: hdmi: add RK3229 HDMI support

RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy, the max output resolution is 4K. Signed-off-by: Yakir Yang --- drivers/gpu/drm/bridge/dw-hdmi.c| 33 ++- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 380 +---

[RFC PATCH v1 2/2] dt-bindings: add document for rk3229-hdmi

Signed-off-by: Yakir Yang --- .../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt

[PATCH v2 1/2] drm: bridge: sil902x

On 01/06/2016 05:55 PM, Boris Brezillon wrote: > Add basic support for the sil902x RGB -> HDMI bridge. > This driver does not support audio output yet. > > Signed-off-by: Boris Brezillon > --- > Hello, > > This patch is only adding basic support for the sil9022 chip. > As stated in the commit

[RFC PATCH v1 1/2] drm: rockchip: hdmi: add RK3229 HDMI support

Thanks for "Kbuild test robot" reminding, I forget to update "mode_valid" function define in imx-hdmi side, would send new version out, -- >> drivers/gpu/drm/imx/dw_hdmi-imx.c:181:2: warning: initialization from >> incompatible pointer type .mode_valid = imx6q_hdmi_mode_valid, ^

[PATCH 1/2] drm: bridge: sil902x

On Wed, Jan 06, 2016 at 10:35:37AM -0500, Ilia Mirkin wrote: > On Wed, Jan 6, 2016 at 10:26 AM, Sascha Hauer > wrote: > > On Wed, Jan 06, 2016 at 02:53:30PM +0100, Boris Brezillon wrote: > >> Hi Sascha, > >> > >> On Wed, 6 Jan 2016 14:47:36 +0100 > >> Sascha Hauer wrote: > >> > >> > Hi Boris, >

[Bug 103561] unable to handle kernel paging request with csgo in wine+nine, ttm_bo_del_from_lru

https://bugzilla.kernel.org/show_bug.cgi?id=103561 --- Comment #6 from Michel Dänzer --- This is the same as bug 96721, isn't it? https://bugs.freedesktop.org/show_bug.cgi?id=92258 might be related. -- You are receiving this mail because: You are watching the assignee of the bug.

[alsa-devel] [PATCH 0/9] dw-hdmi audio support

Hi Russell, 2016-01-05 17:04 GMT+01:00 Russell King - ARM Linux : > On Tue, Jan 05, 2016 at 04:40:54PM +0100, Jean-Michel Hautbois wrote: >> Hi Russell, >> >> 2015-08-27 10:42 GMT+02:00 Philipp Zabel : >> > >> > Am Samstag, den 08.08.2015, 17:09 +0100 schrieb Russell King - ARM >> > Linux: >> > >

bisected: i915 modeset broken in ac9b8236551d1177fd07b56aef9b565d1864420d

On Wed, 06 Jan 2016, Meelis Roos wrote: >> On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote: >> > Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC. >> >> That would seem to be SNB. > > Yes. > >> > Instead of seeing the new dense graphics mode, I see the last VGA

[RFC PATCH v2 0/4] Add RK3229 HDMI support

RK3229 have integrated an DesignedWare HDMI controller and an INNO HDMI phy, so we can still reuse the dw-hdmi driver for RK3229 HDMI controller, but we need to create an separate driver for RK3229 HDMI PHY. This series is based on Mark Yao's drm-next branch

[Bug 93594] Flickering Shadows in The Talos Principle

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160107/5c35d9e2/attachment-0001.html>

[RFC PATCH v2 1/4] drm: dw-hdmi: make it easy to recovery the platform data for platform driver

Signed-off-by: Yakir Yang --- Changes in v2: None drivers/gpu/drm/imx/dw_hdmi-imx.c | 7 --- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 7 --- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c

[RFC PATCH v2 2/4] drm: dw-hdmi: passing the "plat_data" when calling platform mode_valid

Make it easy for platform driver could recovery the private data that would help to valid the display mode. Signed-off-by: Yakir Yang --- Changes in v2: None drivers/gpu/drm/bridge/dw-hdmi.c| 5 +++-- drivers/gpu/drm/imx/dw_hdmi-imx.c | 10 ++

[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy, the max output resolution is 4K. Signed-off-by: Yakir Yang --- Changes in v2: - Split some dw-hdmi driver changes into separate patches [01/04] & [02/04] drivers/gpu/drm/bridge/dw-hdmi.c| 27 +-

[RFC PATCH v2 4/4] dt-bindings: add document for rk3229-hdmi

Signed-off-by: Yakir Yang --- Changes in v2: None .../devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt

[PATCH] drm/i915: Init power domains early in driver load

Since commit ac9b8236551d1177fd07b56aef9b565d1864420d Author: Ville Syrjälä Date: Fri Nov 27 18:55:26 2015 +0200 drm/i915: Introduce a gmbus power domain gmbus also needs the power domain infrastructure right from the start, since as soon as we register the i2c controllers someone can

[Intel-gfx] [PATCH] drm/i915: Init power domains early in driver load

On Thu, Jan 07, 2016 at 10:10:56AM +0100, Daniel Vetter wrote: > Since > > commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure

[PATCH v2 1/2] drm: bridge: sil902x

Hi Archit, On Thu, 7 Jan 2016 11:12:47 +0530 Archit Taneja wrote: > > > On 01/06/2016 05:55 PM, Boris Brezillon wrote: > > Add basic support for the sil902x RGB -> HDMI bridge. > > This driver does not support audio output yet. > > > > Signed-off-by: Boris Brezillon > > --- > > Hello, > > >

[PATCH 0/5] Add encoder_mask to crtc_state, v2.

Another attempt at adding encoder_mask, with some behavioral fixes. Maarten Lankhorst (5): drm/core: Add drm_encoder_index. drm/core: Add drm_for_each_encoder_mask, v2. drm/i915: Do not touch best_encoder for load detect. drm/atomic: Do not unset crtc when an encoder is stolen

[PATCH 3/5] drm/i915: Do not touch best_encoder for load detect.

This should only be touched by drm_atomic_helper. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 391cc7f000da..d77968092ce4 100644

[PATCH 4/5] drm/atomic: Do not unset crtc when an encoder is stolen

While we steal the encoder away from the connector the connector may be updated to use a different encoder. Without this change if 2 connectors swap encoders one of them will end up without a crtc. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_atomic_helper.c | 4 1 file

[PATCH 2/5] drm/core: Add drm_for_each_encoder_mask, v2.

This is similar to the other drm_for_each_*_mask functions. Changes since v1: - Use for_each_if Signed-off-by: Maarten Lankhorst --- include/drm/drm_crtc.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index

[PATCH 1/5] drm/core: Add drm_encoder_index.

This is useful for adding encoder_mask in crtc_state. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/drm_crtc.c | 23 +++ include/drm/drm_crtc.h | 1 + 2 files changed, 24 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index

[PATCH 5/5] drm/atomic: Add encoder_mask to crtc_state, v2.

This allows iteration over encoders using drm_for_each_encoder_mask without inspecting all connector_states, which requires connection_mutex. Changes since v1: - Add a set_best_encoder helper function and update encoder_mask inside it. Signed-off-by: Maarten Lankhorst ---

[PATCH v2 0/2] Introduce Innosilicon HDMI driver on Rockchip platforms

Here are a brief introduction to Innosilicon HDMI IP: - Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter - Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec - Digital video interface supports a pixel size of 24, 30, 36, 48bits color depth in RGB - S/PDIF

[PATCH v2 1/2] drm: rockchip/hdmi: add Innosilicon HDMI support

The Innosilicon HDMI is a low power HDMI 1.4 transmitter IP, and it have been integrated on some rockchip CPUs (like RK3036, RK312x). Signed-off-by: Yakir Yang --- Changes in v2: - Using DRM atomic helper functions for connector init (Mark) - Remove "hdmi->connector.encoder = encoder;" (Mark)

[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang: > RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy, > the max output resolution is 4K. > > Signed-off-by: Yakir Yang It sounds like the INNO HDMI2.0 phy is not necessarily specific to RK3229 but might also

[PATCH v2 2/2] dt-bindings: add document for Innosilicon HDMI on Rockchip platform

Signed-off-by: Yakir Yang Acked-by: Rob Herring --- Changes in v2: - Correct the misspell "rk3036-dw-hdmi" (Heiko) .../display/rockchip/inno_hdmi-rockchip.txt| 50 ++ 1 file changed, 50 insertions(+) create mode 100644

[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

Hi Philipp, Thanks for your fast respond :) On 01/07/2016 06:04 PM, Philipp Zabel wrote: > Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang: >> RK3229 integrate an DesignedWare HDMI2.0 controller and an INNO HDMI2.0 phy, >> the max output resolution is 4K. >> >> Signed-off-by: Yakir

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote: > During testing we observed that the last cacheline was not being flushed > from a > > mb() > for (addr = addr & -clflush_size; addr < end; addr += clflush_size) > clflushopt(); > mb() > > loop (where

[PATCH] drm/i915: Init power domains early in driver load

> commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure right from the start, > since as soon as we register the i2c controllers

bisected: i915 modeset broken in ac9b8236551d1177fd07b56aef9b565d1864420d

On Thu, 07 Jan 2016, Jani Nikula wrote: > On Wed, 06 Jan 2016, Meelis Roos wrote: >>> On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote: >>> > Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC. >>> >>> That would seem to be SNB. >> >> Yes. >> >>> > Instead of

[Bug 80868] Support screen scaling modes for external monitors

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

[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors

) (prog-if 00 [VGA controller]) Dual DVI using DVI-I and DVI-D works fine. -- 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/20160

bisected: i915 modeset broken in ac9b8236551d1177fd07b56aef9b565d1864420d

> > intel_setup_gmbus registers the i2c adapters, which does transfers on > > the i2c bus on probe, and this happens before intel_power_domains_init > > which initializes the power domain lock. > > > > The bisect and backtrace make sense and are not mysterious at all. > > > > Not sure of the fix

[PATCH] drm/i915: Init power domains early in driver load

Since commit ac9b8236551d1177fd07b56aef9b565d1864420d Author: Ville Syrjälä Date: Fri Nov 27 18:55:26 2015 +0200 drm/i915: Introduce a gmbus power domain gmbus also needs the power domain infrastructure right from the start, since as soon as we register the i2c controllers someone can

[PATCH] drm/i915: Init power domains early in driver load

On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote: > Since > > commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure

[Intel-gfx] [PATCH] drm/i915: Init power domains early in driver load

/drm-i915-Init-power-domains-early-in-driver-load/20160107-194542 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-randconfig-x007-01060743 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new

[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors

xt-4.5 geafbbd9 and drm-next-4.5-wip gbc48ef9, although only the trivial cases. -- 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

[PATCH] drm/i915: Init power domains early in driver load

On Thu, 07 Jan 2016, Daniel Vetter wrote: > Since > > commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure right from the start, >

[PATCH] drm/i915: Init power domains early in driver load

On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote: > Since > > commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure

[PATCH] drm/i915: Init power domains early in driver load

On Thu, Jan 7, 2016 at 1:52 PM, Ville Syrjälä wrote: > On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote: >> Since >> >> commit ac9b8236551d1177fd07b56aef9b565d1864420d >> Author: Ville Syrjälä >> Date: Fri Nov 27 18:55:26 2015 +0200 >> >> drm/i915: Introduce a gmbus power

[PATCH] drm/i915: Init power domains early in driver load

Since commit ac9b8236551d1177fd07b56aef9b565d1864420d Author: Ville Syrjälä Date: Fri Nov 27 18:55:26 2015 +0200 drm/i915: Introduce a gmbus power domain gmbus also needs the power domain infrastructure right from the start, since as soon as we register the i2c controllers someone can

[PATCH] MAINTAINERS: update for Freescale DCU DRM driver

Acked-by: Jianwei Wang On Thu, Jan 7, 2016 at 2:02 PM, Stefan Agner wrote: > Promote myself as new maintainer of the Freescale DCU DRM driver. > > Signed-off-by: Stefan Agner > --- > This has been previously discussed privately. The original driver > author and maintainer Jianwei does not work

[PATCH] drm/i915: Init power domains early in driver load

On Thu, 07 Jan 2016, Daniel Vetter wrote: > On Thu, Jan 7, 2016 at 1:52 PM, Ville Syrjälä > wrote: >> On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote: >>> Since >>> >>> commit ac9b8236551d1177fd07b56aef9b565d1864420d >>> Author: Ville Syrjälä >>> Date: Fri Nov 27 18:55:26

[PATCH] drm/i915: Init power domains early in driver load

On Thu, Jan 07, 2016 at 02:15:50PM +0100, Daniel Vetter wrote: > On Thu, Jan 7, 2016 at 1:52 PM, Ville Syrjälä > wrote: > > On Thu, Jan 07, 2016 at 12:44:21PM +0100, Daniel Vetter wrote: > >> Since > >> > >> commit ac9b8236551d1177fd07b56aef9b565d1864420d > >> Author: Ville Syrjälä > >>

[PATCH 0/5] sti fix to enable atomic modesetting

Those patches fix the issues found by using atomictest on sti driver. After testing we are confident to enable atomic modesetting so we decide to set DRIVER_ATOMIC flag. Benjamin Gaignard (4): drm: sti: fix potential crash in gdp drm: sti: add atomic get/set properties for planes drm: sti:

[PATCH 1/5] drm: sti: fix potential crash in gdp

In some cases last_close() could be called before sti_gdp_disable() and make kernel crash because mixer structure has been destroy. Let's gdp keep a reference on vtg to fix that (like it is already done in HQVDP) Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_gdp.c | 13

[PATCH 2/5] drm: sti: add atomic get/set properties for planes

Without those function zpos property isn't displayed in atomic mode. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_plane.c | 40 1 file changed, 40 insertions(+) diff --git a/drivers/gpu/drm/sti/sti_plane.c

[PATCH 3/5] drm: sti: set CRTC modesetting parameters

Set CRTC modesetting parameters to avoid warnings in atomic mode. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_crtc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c index de11c7c..505620c 100644 ---

[PATCH 4/5] drm: sti: fix cursor coordinates

From: Fabien Dessenne x/y typo. Change-Id: I1ddc0a7e59090a10471db45d862e76756b967236 Signed-off-by: Fabien Dessenne Reviewed-on: https://gerrit.st.com/47166 Reviewed-by: Denis HUMEAU Tested-by: Denis HUMEAU Reviewed-by: Romuald JEANNE ---

[PATCH 5/5] drm: sti: set DRIVER_ATOMIC for sti

sti now support of atomic modesetting so set the flag to enable it. Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c index 1469987..a6f9ff2 100644

[PATCH 2/5] drm: sti: add atomic get/set properties for planes

On Thu, Jan 07, 2016 at 02:30:38PM +0100, Benjamin Gaignard wrote: > Without those function zpos property isn't displayed in atomic mode. > > Signed-off-by: Benjamin Gaignard Oh, another iteration of a driver-private zpos property. This _really_ should be generic, with some consistent

[PATCH] drm/i915: Init power domains early in driver load

Since commit ac9b8236551d1177fd07b56aef9b565d1864420d Author: Ville Syrjälä Date: Fri Nov 27 18:55:26 2015 +0200 drm/i915: Introduce a gmbus power domain gmbus also needs the power domain infrastructure right from the start, since as soon as we register the i2c controllers someone can

[PATCH 4/5] drm: sti: fix cursor coordinates

fix x/y typo while setting cursor coordinates Signed-off-by: Fabien Dessenne --- drivers/gpu/drm/sti/sti_cursor.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_cursor.c b/drivers/gpu/drm/sti/sti_cursor.c index 8078631..a19693a 100644 ---

[PATCH 3/5] drm: sti: set CRTC modesetting parameters

On Thu, Jan 07, 2016 at 02:30:39PM +0100, Benjamin Gaignard wrote: > Set CRTC modesetting parameters to avoid warnings in atomic mode. Hm, should we extend the documentation for the mode_fixup hooks that this should be done? Care to submit a patch against drm-misc/linux-next (since there's more

[PATCH 2/5] drm: sti: add atomic get/set properties for planes

> > > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > -- Benjamin Gaignard Graphic Working Group Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter <http://twitter.com/#!/linaroorg> | Blog <http://www.linaro.org/linaro-blog/> -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160107/3abdde43/attachment-0001.html>

[PATCH] drm/i915: Init power domains early in driver load

On Thu, Jan 07, 2016 at 02:51:05PM +0100, Daniel Vetter wrote: > Since > > commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure

[PATCH v11 2/4] PM / Domains: add setter for dev.pm_domain

On 10 November 2015 at 10:33, Daniel Kurtz wrote: [snip] > > The problem appears to be that: > * On boot, platform_drv_probe() calls dev_pm_domain_attach() before > drv->probe(); thus, it calls dev_pm_domain_attach() while the device > is unbound. > > * However, for a platform_device, the

[PATCH 2/5] drm: sti: add atomic get/set properties for planes

On Thu, Jan 07, 2016 at 03:05:02PM +0100, Benjamin Gaignard wrote: > zpos property isn't new in sti driver only the atomic set/get functions are > new. > Without those functions atomictest failed to discover any of the other > atomic planes properties. > > I agree with you, zpos should be generic

[PATCH v3] drm/i915: intel_hpd_init(): Fix suspend/resume reprobing

This fixes reprobing of display connectors on resume. After some talking with danvet on IRC, I learned that calling drm_helper_hpd_irq_event() does actually trigger a full reprobe of each connector's status. It turns out this is the actual reason reprobing on resume hasn't been working (this was

[PATCH v12 0/4] Allow USB devices to remain runtime-suspended when sleeping

Hi, this is v12 of an attempt to make it easier for devices to remain in runtime PM when the system goes to sleep, mainly to reduce the time spent resuming devices. For this, we interpret the absence of all PM callback implementations as it being safe to do direct_complete, so their ancestors

[PATCH v12 2/4] PM / Domains: add setter for dev.pm_domain

Adds a function that sets the pointer to dev_pm_domain in struct device and that warns if the device has already finished probing. The reason why we want to enforce that is because in the general case that can cause problems and also that we can simplify code quite a bit if we can always assume

[PATCH] drm/i915: Init power domains early in driver load

> commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure right from the start, > since as soon as we register the i2c controllers

[Intel-gfx] [PATCH v3] drm/i915: intel_hpd_init(): Fix suspend/resume reprobing

On Thu, Jan 07, 2016 at 10:43:28AM -0500, Lyude wrote: > This fixes reprobing of display connectors on resume. After some > talking with danvet on IRC, I learned that calling > drm_helper_hpd_irq_event() does actually trigger a full reprobe of each > connector's status. It turns out this is the

[GIT PULL] drm-etnaviv-fixes for current -next

Hi Dave, 2 small fixes for the etnaviv driver, both noticed by the smatch checker and reported/fixed by Dan Carpenter. Regards, Lucas The following changes since commit c11b8989635166c5a1e6aac1853a847bd664f8db: Merge tag 'omapdrm-4.5-resolved' of

[RFC PATCH v2 3/4] drm: rockchip: hdmi: add RK3229 HDMI support

Hi Yakir, Am Donnerstag, den 07.01.2016, 18:15 +0800 schrieb Yakir Yang: > Hi Philipp, > > Thanks for your fast respond :) > > On 01/07/2016 06:04 PM, Philipp Zabel wrote: > > Am Donnerstag, den 07.01.2016, 17:02 +0800 schrieb Yakir Yang: > >> RK3229 integrate an DesignedWare HDMI2.0 controller

DRM support in Android

wn path ( https://android.googlesource.com/platform/frameworks/native/+/android-6.0.1_r5/opengl/libs/EGL/Loader.cpp#41). This can be Mesa or a proprietary library. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/at

[PATCH libdrm] Fix memory leak with drmModeGetConnectorCurrent()

On Tue, Dec 15, 2015 at 02:05:45PM +, Chris Wilson wrote: > On Tue, Dec 15, 2015 at 03:59:28PM +0200, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > drmModeGetConnectorCurrent() must provide temporary storage for the > > kernel to fill in at least one mode

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Thu, Jan 7, 2016 at 2:16 AM, Chris Wilson wrote: > On Mon, Oct 19, 2015 at 10:58:55AM +0100, Chris Wilson wrote: >> During testing we observed that the last cacheline was not being flushed >> from a >> >> mb() >> for (addr = addr & -clflush_size; addr < end; addr += clflush_size)

[Bug 108561] nouveau: external monitor can not be enabled with hindsight

https://bugzilla.kernel.org/show_bug.cgi?id=108561 --- Comment #6 from Elmar Stellnberger --- It is really a pity that my NVIDIA Corporation G96M [GeForce 9600M GT] has been crossed out of the list of supported cards since an update to kernel 4.3.3-2. It has worked well with the nouveau driver

[PATCH] drm/i915: Init power domains early in driver load

> commit ac9b8236551d1177fd07b56aef9b565d1864420d > Author: Ville Syrjälä > Date: Fri Nov 27 18:55:26 2015 +0200 > > drm/i915: Introduce a gmbus power domain > > gmbus also needs the power domain infrastructure right from the start, > since as soon as we register the i2c controllers

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Thu, Jan 07, 2016 at 09:55:51AM -0800, Andy Lutomirski wrote: > On Thu, Jan 7, 2016 at 2:16 AM, Chris Wilson > wrote: > >> + /* GCC (4.9.1 and 5.2.1 at least) appears to be very confused when > >> + * meeting this alternative() and demonstrably miscompiles loops > >> + *

[Bug 108561] nouveau: external monitor can not be enabled with hindsight

https://bugzilla.kernel.org/show_bug.cgi?id=108561 --- Comment #7 from Elmar Stellnberger --- Comment #6 is now resolved: Please excuse the panic; I think that there was just a temporary configuration issue with Arch Linux (see also: https://bugs.freedesktop.org/show_bug.cgi?id=93405); i.e.

[Bug 78987] black screen when trying to enable external VGA screen on Trinity APU laptop

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20160107/9bde0936/attachment.html>

drm/amd/powerplay: show gpu load when print gpu performance for Cz. (v2)

Hello Rex Zhu, The patch 605ed21929fe: "drm/amd/powerplay: show gpu load when print gpu performance for Cz. (v2)" from Dec 17, 2015, leads to the following static checker warning: drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1545 cz_print_current_perforce_level()

[git pull] drm fixes

Hi Linus, still not back to work, but I decided to forward this fix. Dave. The following changes since commit b06f3a168cdcd80026276898fd1fee443ef25743: Merge tag 'for-linus-20160106' of git://git.infradead.org/linux-mtd (2016-01-06 20:32:08 -0800) are available in the git repository at:

[PATCH] x86: Add an explicit barrier() to clflushopt()

On 01/07/16 11:44, Chris Wilson wrote: > > Now I feel silly. Looking at the .s, there is no difference with the > addition of the barrier to clflush_cache_range(). And sure enough > letting the test run for longer, we see a failure. I fell for a placebo. > > The failing assertion is always on

[PATCH] x86: Add an explicit barrier() to clflushopt()

On Thu, Jan 07, 2016 at 01:05:35PM -0800, H. Peter Anvin wrote: > On 01/07/16 11:44, Chris Wilson wrote: > > > > Now I feel silly. Looking at the .s, there is no difference with the > > addition of the barrier to clflush_cache_range(). And sure enough > > letting the test run for longer, we see a

[PATCH] x86: Add an explicit barrier() to clflushopt()

On 01/07/16 13:54, Chris Wilson wrote: > > Whilst you are looking at this asm, note that we reload > boot_cpu_data.x86_cflush_size everytime around the loop. That's a small > but noticeable extra cost (especially when we are only flushing a single > cacheline). > I did notice that; I don't know

[PATCH] x86: Add an explicit barrier() to clflushopt()

On 01/07/16 14:29, H. Peter Anvin wrote: > > I would be very interested in knowing if replacing the final clflushopt > with a clflush would resolve your problems (in which case the last mb() > shouldn't be necessary either.) > Nevermind. CLFLUSH is not ordered with regards to CLFLUSHOPT to the

[pull] radeon and amdgpu drm-next-4.5

Hi Dave, Misc fixes for amdgpu and radeon for 4.5. The bulk of the changes are smatch fixes and cleanups. This also includes the DP MST fixes from Mykola. Beyond that some fixes from Christian to avoid -ENOMEM errors in some corner cases in the CS ioctl, some suspend and resume fixes, and some

[Bug 93594] Flickering Shadows in The Talos Principle

p://lists.freedesktop.org/archives/dri-devel/attachments/20160107/0bd741db/attachment.html>

[Bug 93594] Flickering Shadows in The Talos Principle

/lists.freedesktop.org/archives/dri-devel/attachments/20160107/17b79612/attachment.html>

[PATCH] drm/radeon: fix trivial typo in warning message

Signed-off-by: Alexandre Demers --- drivers/gpu/drm/radeon/radeon_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index c566993..4197ca1 100644 ---

[PATCH v4.4-rc8] radeon: r100: Silence 'may be used uninitialized' warnings

From: Tim Gardner CC [M] drivers/gpu/drm/radeon/r100.o In file included from drivers/gpu/drm/radeon/radeon_mode.h:37:0, from drivers/gpu/drm/radeon/radeon.h:80, from drivers/gpu/drm/radeon/r100.c:33: drivers/gpu/drm/radeon/r100.c: