[PATCH 04/10] drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info

From: Ville Syrjälä We have the drm_display_info for storing information about the sink, so let's move dvi_dual and max_tmds_clock in there. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syrjälä ---

[PATCH 03/10] drm/edid: Make max_tmds_clock kHz instead of MHz

From: Ville Syrjälä We generally store clocks in kHz, so let's do that for the HDMI max TMDS clock value as well. Less surpising. Cc: Alex Deucher Cc: "Christian König" Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 2 +-

[PATCH 02/10] drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID

From: Ville Syrjälä Clear out old max_tmds_clock and dvi_dual information (possibly from a previous EDID) before parsing the current EDID. Tne current EDID might not even have these in its HDMI VSDB, which would mean that we'd leave the old stale values in place.

[PATCH 01/10] drm/edid: Clear old audio latency values before parsing the new EDID

From: Ville Syrjälä Clear out stale audio latency information (potentially from a previous EDID) before constructing the ELD from the EDID. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 7 +++ 1 file changed, 7 insertions(+) diff --git

[PATCH 00/10] drm/edid: Clean up display_info stuff

From: Ville Syrjälä This series aims to clean up the way we fill out the display_info structure a bit. Mainly doing a clean separation of the audio and video related bits. My aim is getting i915 to respect the HDMI sink TMDS clock limit (currently we respect

[PATCH 5/7] drm/mediatek: plane: Merge mtk_plane_enable into mtk_plane_atomic_update

On Tue, 2016-08-02 at 13:04 -0400, Sean Paul wrote: > On Tue, Aug 2, 2016 at 1:02 PM, Sean Paul wrote: > > On Fri, Jul 29, 2016 at 5:04 AM, Bibby Hsieh > > wrote: > >> From: Daniel Kurtz > >> > >> The mtk_plane_enable is just called once by mtk_plane_atomic_update. > >> So, merge

[Bug 97174] Assault Android Cactus freezing on Mesa 12

//lists.freedesktop.org/archives/dri-devel/attachments/20160803/857de4ed/attachment.html>

[PATCH 04/10] drm: make drm_vblank_{get,put}() static

On Tue, Aug 02, 2016 at 11:30:21PM -0700, Rodrigo Vivi wrote: > I was going to remove the legacy get/put versions right now, but > decided to check if there were any pending patch in mailing lists and > found this. > > What about deleting the functions at all instead of having it internally?

[PATCH 4/5] drm/intel/dp: Try harder to get bpc of a DP sink if EDID doesn't tell.

On Wed, Aug 03, 2016 at 01:07:12PM +1000, Dave Airlie wrote: > On 6 July 2016 at 20:05, Mario Kleiner wrote: > > For DP sinks which don't expose color depth via EDID, use > > the drm_dp_sink_bpc() helper to derive the bpc of the sink. > > > > This should handle DP native sinks with the "Assume 6

[PATCH v7] drm/i915/skl: Add support for the SAGV, fix underrun hangs

On Wed, Aug 03, 2016 at 09:50:23AM -0400, Lyude wrote: ... > +int > +skl_disable_sagv(struct drm_i915_private *dev_priv) > +{ > + int ret, result; > + > + if (IS_BROXTON(dev_priv)) > + return 0; > + if (!dev_priv->skl_sagv_enabled) > + return 0; > + > +

[PATCH libdrm] Make sure the second argument to container_of() is initialized

On Wed, Aug 3, 2016 at 4:56 AM, Michel Dänzer wrote: > On 03.08.2016 02:49, Nicolai Hähnle wrote: >> On 02.08.2016 12:08, Michel Dänzer wrote: >>> From: Michel Dänzer >>> >>> Fixes warnings and miscompilation resulting in crashes with clang. >> >> How annoying. Seems like this would affect

RFC: hardware accelerated bitblt using dma engine

On 03.08.2016 05:47, Dave Airlie wrote: > Because no hw is the same once you go beyond that. hmm, it doesn't seem to be so extremly different, that we cant at least abstract some common aspects. > Video memory size means what? VRAM, GPU accessible system RAM, > amount of CPU visible VRAM?

[Bug 151341] New: AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait

https://bugzilla.kernel.org/show_bug.cgi?id=151341 Bug ID: 151341 Summary: AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait Product: Drivers Version: 2.5 Kernel Version: 4.7.0 Hardware: x86-64

RFC: hardware accelerated bitblt using dma engine

On 03.08.2016 01:12, Rob Clark wrote: Hi, >> Well, if it already does buffer allocation and mapping (which might >> also involve copying around phyisical buffers), why not also add >> copy-between-buffers ? > > except "dumb" buffers exist *only* for CPU rendered content, you > cannot assume

[git pull] drm zpos property support

Hi Linus, This tree was waiting on some media stuff I hadn't had time to get a stable branchpoint off, so I just waited until it was all in your tree first, it's been around a bit on the list and shouldn't affect anything outside adding the generic API and moving some ARM drivers to using it.

[Bug 97174] Assault Android Cactus freezing on Mesa 12

tps://lists.freedesktop.org/archives/dri-devel/attachments/20160803/3fe9482a/attachment.html>

[PATCH 2/2 v2][resend] drm: bridge: add DesignWare HDMI I2S audio support

From: Kuninori Morimoto Current dw-hdmi is supporting sound via AHB bus, but it has I2S audio feature too. This patch adds I2S audio support to dw-hdmi. This HDMI I2S is supported by using ALSA SoC common HDMI encoder driver. Tested-by: Jose Abreu

[PATCH 1/2 v2][resend] ASoC: hdmi-codec: enable multi probe for same device

From: Kuninori Morimoto hdmi-codec driver is common HDMI sound driver, but it doesn't care about multi sound ports. For example, hdmi-codec driver is supporting 1 I2S and 1 SPDIF ports, so, we can't use this driver if HDMI has 2 or more I2S ports. And we would

[PATCH 0/2 v2][resend] DesignWare HDMI I2S suport

Hi Archit, Mark Cc Thierry, Russell These are resend of v2 of DesignWare HDMI I2S support patches. (I added drm-bridge maintainer Archit on To:) It will use ALSA SoC hdmi-codec driver, but we can't use it as-is at this point. 1) patch tidyup hdmi-codec driver to enable dw-hdmi I2S support. 2)

[PATCH 1/3] drm: bridge: add DesignWare HDMI I2S audio support

Hi Daniel > > > > Mark, Thierry, Daniel > > > > I wonder who can be maintainer for this patch ?? > > > > > > It's a DRM patch so I'd expect someone in the DRM subsystem. > > > > OK, I see. > > But, I will keep Cc to you for this patch-set. > > Archit Tajena is the maintainer of last resort

[Bug 97179] After launching games based on Source engine windows titles and borders are corrupted and sometimes frequently flicker

this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/4a53c8ed/attachment.html>

[Bug 97174] Assault Android Cactus freezing on Mesa 12

L: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160803/3144cf32/attachment-0001.html>

libdrm-armada repository

On Tue, Aug 02, 2016 at 04:09:58PM -0700, Joshua Clayton wrote: > Greetings Russell, > I'm publishing an etnaviv yocto layer on github. > One of the components is libdrm-armada, which we get from > git://ftp.arm.linux.org.uk/~rmk/libdrm-armada.git > > I don't want to put an unwanted extra burden

RFC: hardware accelerated bitblt using dma engine

On 02.08.2016 16:04, Daniel Vetter wrote: > If you mean "add a generic hw-accelerated bitblt operation": This is not > hw drm works. The generic kms stuff is about display only, with just very > basic (hence "dumb") buffer allocation support in a generic way. Well, if it already does buffer

<    1   2