Re: [PULL] drm-misc-fixes

On 26 May 2017 at 15:30, Lukas Wunner wrote: > On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote: >> The pull is noisy because it includes -rc2. > > Looks like I've caused another fine mess by fast-forwarding -fixes. :-( > > I followed the docs in drm-misc.rst which say:

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

On Fri, May 26, 2017 at 10:30:09AM +0800, jeffy wrote: > Hi sean, > > On 05/25/2017 11:30 PM, Sean Paul wrote: > > On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote: > > > The system would crash when trying to alloc zero sized gem buffer: > > > [6.712435] Unable to handle kernel NULL

Re: [PULL] drm-misc-fixes

On Thu, May 25, 2017 at 01:44:04PM -0400, Sean Paul wrote: > The pull is noisy because it includes -rc2. Looks like I've caused another fine mess by fast-forwarding -fixes. :-( I followed the docs in drm-misc.rst which say: * Fast-forward (when possible) `-fixes` to each released -rc kernel

Re: [PATCH 1/5] drm: introduce sync objects (v3)

On 25 May 2017 at 18:30, Chris Wilson wrote: > On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote: >> From: Dave Airlie >> >> Sync objects are new toplevel drm object, that contain a >> pointer to a fence. This fence can be updated via

[git pull] drm fixes for v4.12-rc3

Hi Linus, Not a whole lot happening here, a set of amdgpu fixes and one core deadlock fix, and some misc drivers fixes. Dave. The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d: Linux 4.12-rc2 (2017-05-21 19:30:23 -0700) are available in the git repository at:

Re: [PATCH v5 06/10] drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback

On 05/25/2017 07:49 PM, Jose Abreu wrote: Now that we have a callback to check if bridge supports a given mode we can use it in Analogix bridge so that we restrict the number of probbed modes to the ones we can actually display. Also, there is no need to use mode_fixup() callback as

Re: [PATCH v5 02/10] drm: Introduce drm_bridge_mode_valid()

On 05/25/2017 07:49 PM, Jose Abreu wrote: Introduce a new helper function which calls mode_valid() callback for all bridges in an encoder chain. Reviewed-by: Archit Taneja Signed-off-by: Jose Abreu Reviewed-by: Daniel Vetter

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

On 05/26/2017 09:46 AM, Archit Taneja wrote: Hi, On 05/25/2017 05:04 AM, Kuninori Morimoto wrote: Hi Mark Cc: DRM maintainer ALSA SoC needs to know connected DAI ID for probing. It is not a big problem if device/driver was only for sound, but getting DAI ID will be difficult if device

Re: [PATCH 5/5] drm: dw-hdmi-i2s: add .get_dai_id callback for ALSA SoC

Hi, On 05/25/2017 05:04 AM, Kuninori Morimoto wrote: Hi Mark Cc: DRM maintainer ALSA SoC needs to know connected DAI ID for probing. It is not a big problem if device/driver was only for sound, but getting DAI ID will be difficult if device includes both Video/Sound, like HDMI. As far as I

Re: [GIT PULL] exynos-drm-fixes

On 19 May 2017 at 19:33, Inki Dae wrote: > Hi Dave, > >a little bit big cleanups but this fixes some timeout issue >at wait-for-vblank, fixups to dt broken issue and trivial cleanups. > >Please kindly let me know if there is any problem. Can we make this

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

Hi sean, On 05/25/2017 11:30 PM, Sean Paul wrote: On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote: The system would crash when trying to alloc zero sized gem buffer: [6.712435] Unable to handle kernel NULL pointer dereference at virtual address 0010 <--ZERO_SIZE_PTR ... [

[Bug 194761] amdgpu driver breaks on Oland (SI)

https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #20 from Michel Dänzer (mic...@daenzer.net) --- Flora, why did you add me to Cc? I get notifications via the dri-devel mailing list. -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH v5 08/10] drm/arm: malidp: Use crtc->mode_valid() callback

Now that we have a callback to check if crtc supports a given mode we can use it in malidp so that we restrict the number of probbed modes to the ones we can actually display. Also, remove the mode_fixup() callback as this is no longer needed because mode_valid() will be called before. NOTE: Not

[PATCH v5 06/10] drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback

Now that we have a callback to check if bridge supports a given mode we can use it in Analogix bridge so that we restrict the number of probbed modes to the ones we can actually display. Also, there is no need to use mode_fixup() callback as mode_valid() will handle the mode validation. NOTE:

[PATCH v5 09/10] drm/atmel-hlcdc: Use crtc->mode_valid() callback

Now that we have a callback to check if crtc supports a given mode we can use it in atmel-hlcdc so that we restrict the number of probbed modes to the ones we can actually display. Also, remove the mode_fixup() callback as this is no longer needed because mode_valid() will be called before.

[PATCH v5 03/10] drm: Use new mode_valid() helpers in connector probe helper

This changes the connector probe helper function to use the new encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid() helper callbacks to validate the modes. The new callbacks are optional so the behaviour remains the same if they are not implemented. If they are, then the code loops

[PATCH v5 05/10] drm: arcpgu: Use crtc->mode_valid() callback

Now that we have a callback to check if crtc supports a given mode we can use it in arcpgu so that we restrict the number of probbed modes to the ones we can actually display. This is specially useful because arcpgu crtc is responsible to set a clock value in the commit() stage but unfortunatelly

[PATCH v5 01/10] drm: Add drm_{crtc/encoder/connector}_mode_valid()

Add a new helper to call crtc->mode_valid, connector->mode_valid and encoder->mode_valid callbacks. Suggested-by: Ville Syrjälä Signed-off-by: Jose Abreu Reviewed-by: Daniel Vetter Reviewed-by: Andrzej Hajda

Re: [PATCH] drm/i915: prevent generating unusable gvt build which no mpt module is selected

Hi, Jani, just relized you are in i915 team. :) > > +menu "Intel GVT-g graphics virtualization host support" > > + depends on DRM_I915 > > + depends on 64BIT > > + > > config DRM_I915_GVT > > -bool "Enable Intel GVT-g graphics virtualization host support" > > -depends on

[PATCH v5 00/10] Introduce new mode validation callbacks

NOTE: In this version I just did a rebase onto today's drm-next and added the tags we've collected plus the changelog plus the missing maintainers that I forgot to cc in previous version :/ This series is a follow up from the discussion at [1]. We start by introducing crtc->mode_valid(),

[PATCH v5 07/10] drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback

Now that we have a callback to check if bridge supports a given mode we can use it in Synopsys Designware HDMI bridge so that we restrict the number of probbed modes to the ones we can actually display. Also, there is no need to use mode_fixup() callback as mode_valid() will handle the mode

[PATCH v5 04/10] drm: Use mode_valid() in atomic modeset

This patches makes use of the new mode_valid() callbacks introduced previously to validate the full video pipeline when modesetting. This calls the connector->mode_valid(), encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid() so that we can make sure that the mode will be accepted

[PATCH v5 10/10] drm: vc4: Use crtc->mode_valid() and encoder->mode_valid() callbacks

Now that we have a callback to check if crtc and encoder supports a given mode we can use it in vc4 so that we restrict the number of probbed modes to the ones we can actually display. Also, remove the mode_fixup() calls as these are no longer needed because mode_valid() will be called before.

[PATCH v5 02/10] drm: Introduce drm_bridge_mode_valid()

Introduce a new helper function which calls mode_valid() callback for all bridges in an encoder chain. Signed-off-by: Jose Abreu Reviewed-by: Daniel Vetter Cc: Carlos Palminha Cc: Ville Syrjälä

Re: [PATCH v2] drm/exynos: dsi: Remove bridge node reference in removal

2017년 05월 26일 10:02에 Hoegeun Kwon 이(가) 쓴 글: > Since bridge node is referenced during in the probe, it should be > released on removal. > > Suggested-by: Andrzej Hajda > Signed-off-by: Hoegeun Kwon > --- > Hi Inki, > > This patch seems to have

[PATCH v2] drm/exynos: dsi: Remove bridge node reference in removal

Since bridge node is referenced during in the probe, it should be released on removal. Suggested-by: Andrzej Hajda Signed-off-by: Hoegeun Kwon --- Hi Inki, This patch seems to have been forgotten... :) Changes for V2: - Checked for rebase

[PATCH RESEND 3/6] drm/i915: remove intel_cursor_plane_funcs

From: Gustavo Padovan After converting legacy cursor updates to atomic async commits intel_cursor_plane_funcs just duplicates intel_plane_funcs now. Cc: Daniel Vetter Signed-off-by: Gustavo Padovan ---

[PATCH RESEND 1/6] drm/atomic: initial support for asynchronous plane update

From: Gustavo Padovan In some cases, like cursor updates, it is interesting to update the plane in an asynchronous fashion to avoid big delays. The current queued update could be still waiting for a fence to signal and thus block any subsequent update until its

[PATCH RESEND 4/6] drm/msm: update cursors asynchronously through atomic

From: Gustavo Padovan Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what mdp5_update_cursor_plane_legacy() did but through atomic. v4: add missing atomic async commit call to

[PATCH RESEND 5/6] drm/msm: remove mdp5_cursor_plane_funcs

From: Gustavo Padovan After converting legacy cursor updates to atomic async commits mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now. Cc: Rob Clark Cc: Archit Taneja Signed-off-by: Gustavo Padovan

[PATCH RESEND 6/6] drm/vc4: update cursors asynchronously through atomic

From: Gustavo Padovan Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what vc4_update_plane() did but through atomic. v3: move size checks back to drivers (Ville Syrjälä) v2: move fb

[PATCH RESEND 2/6] drm/i915: update cursors asynchronously through atomic

From: Gustavo Padovan Add support to async updates of cursors by using the new atomic interface for that. Basically what this commit does is do what intel_legacy_cursor_update() did but through atomic. v3: - set correct vma to new state for cleanup

[PATCH RESEND 0/6] drm/atomic: add async plane update

From: Gustavo Padovan Hi, Resending to include intel-gfx@ and get the patches picked up by CI. New version of the patches after the comments from Archit. Full details and the previous discussion can be found here:

Re: [PATCH 2/6] drm/i915: update cursors asynchronously through atomic

2017-05-25 Chris Wilson : > On Thu, May 25, 2017 at 01:41:33AM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Add support to async updates of cursors by using the new atomic > > interface for that. Basically what this

[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #38 from intermedi...@hotmail.com --- [ 12.980953] amdgpu :01:00.0: fb0: amdgpudrmfb frame buffer device [ 12.982746] [drm:.gfx_v6_0_ring_test_ib [amdgpu]] *ERROR* amdgpu: ib test failed

[PULL] drm-misc-fixes

Hi Dave, A handful of fixes for you this week, nothing overly complex. The pull is noisy because it includes -rc2. Due to some process miscommunications, Lukas fast-forwarded -fixes and merged the radeon patch without R-b. Patrik also merged the gma500 patch directly without review. Daniel has

Re: [Freedreno] [PATCH 10/13] drm/msm: Support multiple ringbuffers

On Thu, May 25, 2017 at 1:25 PM, Jordan Crouse wrote: > On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote: >> -#define rbmemptr(adreno_gpu, member) \ >> +#define _sizeof(member) \ >> + sizeof(((struct adreno_rbmemptrs *) 0)->member[0]) >> + >> +#define

[pull] radeon and amdgpu drm-fixes-4.12

Hi Dave, A bunch of bug fixes: - Fix display flickering on some chips at high refresh rates - suspend/resume fix - hotplug fix - a couple of segfault fixes for certain cases The following changes since commit d51aff16e821a755c242e14168f5d4601199eafd: Merge branch 'for-upstream/hdlcd' of

Re: [PATCH 10/13] drm/msm: Support multiple ringbuffers

On Mon, May 08, 2017 at 02:35:06PM -0600, Jordan Crouse wrote: > -#define rbmemptr(adreno_gpu, member) \ > +#define _sizeof(member) \ > + sizeof(((struct adreno_rbmemptrs *) 0)->member[0]) > + > +#define _base(adreno_gpu, member) \ > ((adreno_gpu)->memptrs_iova + offsetof(struct

[Bug 101190] building gallium/R600 fails due to missing amdgpu.h

https://bugs.freedesktop.org/show_bug.cgi?id=101190 Bug ID: 101190 Summary: building gallium/R600 fails due to missing amdgpu.h Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

[Bug 101189] Latest git fails to compile with radeon

https://bugs.freedesktop.org/show_bug.cgi?id=101189 Bug ID: 101189 Summary: Latest git fails to compile with radeon Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

Am 25.05.2017 um 10:47 schrieb Chris Wilson: On Wed, May 24, 2017 at 05:06:12PM +1000, Dave Airlie wrote: From: Dave Airlie This interface will allow sync object to be used to back Vulkan fences. This API is pretty much the vulkan fence waiting API, and I've ported the

Re: [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX

On 05/25/2017 05:30 PM, Mike Lothian wrote: > Hi > > Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C > connector and no displayport > > Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working > based on your testing? > > I've been putting off buying

Re: [PATCH] drm/rockchip: Don't allow zero sized gem buffer

On Tue, May 23, 2017 at 02:39:43PM +0800, Jeffy Chen wrote: > The system would crash when trying to alloc zero sized gem buffer: > [6.712435] Unable to handle kernel NULL pointer dereference at virtual > address 0010 <--ZERO_SIZE_PTR > ... > [6.757502] PC is at

Re: [RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX

Hi Sorry if this is off topic, I've got a Skylake Dell laptop with a USB-C connector and no displayport Which USB-C -> HDMI-2.0 connector do you recommend for stuff just working based on your testing? I've been putting off buying one until I knew 4K@60Hz would work, CEC would be nice to have

[RFC PATCH 6/7] drm: add support for DisplayPort CEC-Tunneling-over-AUX

From: Hans Verkuil This adds support for the DisplayPort CEC-Tunneling-over-AUX feature that is part of the DisplayPort 1.3 standard. Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a chip that has this capability actually hook up the CEC pin, so even

[RFC PATCH 4/7] cec: add cec_phys_addr_invalidate() helper function

From: Hans Verkuil Simplifies setting the physical address to CEC_PHYS_ADDR_INVALID. Signed-off-by: Hans Verkuil --- include/media/cec.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/media/cec.h b/include/media/cec.h index

[RFC PATCH 3/7] cec: add cec_s_phys_addr_from_edid helper function

From: Hans Verkuil This function simplifies the integration of CEC in DRM drivers. Signed-off-by: Hans Verkuil --- drivers/media/cec/cec-adap.c | 14 ++ include/media/cec.h | 9 + 2 files changed, 23 insertions(+)

[RFC PATCH 1/7] cec: add CEC_CAP_NEEDS_HPD

From: Hans Verkuil Add a new capability CEC_CAP_NEEDS_HPD. If this capability is set then the hardware can only use CEC if the HDMI Hotplug Detect pin is high. Such hardware cannot handle the corner case in the CEC specification where it is possible to transmit messages

[RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil Implement support for this DisplayPort feature. The cec device is created whenever it detects an adapter that has this feature. It is only removed when a new adapter is connected that does not support this. If a new adapter is connected that has

[RFC PATCH 5/7] drm/cec: Add CEC over Aux register definitions

From: Clint Taylor Adding DPCD register definitions from the DP 1.3 specification for CEC over AUX support. V2: Add DP_ prefix to all defines. V3: missed prefixes from the ESI1 defines Cc: Jani Nikula Reviewed-by: Jani Nikula

[RFC PATCH 2/7] cec-ioc-adap-g-caps.rst: document CEC_CAP_NEEDS_HPD

From: Hans Verkuil Document the new CEC_CAP_NEEDS_HPD capability. Signed-off-by: Hans Verkuil --- Documentation/media/uapi/cec/cec-ioc-adap-g-caps.rst | 8 1 file changed, 8 insertions(+) diff --git

[RFC PATCH 0/7] drm/i915: add support for DisplayPort CEC-Tunneling-over-AUX

From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX protocol. This patch series is based on v4.12-rc2. The first four patches add support for a new CEC capability which is needed for these devices and for two helper functions.

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

https://bugzilla.kernel.org/show_bug.cgi?id=195737 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC|

[Bug 101182] Reading amdgpu_pm_info causes stutter with Linux 4.12-rc

https://bugs.freedesktop.org/show_bug.cgi?id=101182 --- Comment #3 from Christoph Haag --- Can this be done asynchronously in the driver so it doesn't impact the rendering of 3D applications? -- You are receiving this mail because: You are the assignee for the

[Bug 101182] Reading amdgpu_pm_info causes stutter with Linux 4.12-rc

https://bugs.freedesktop.org/show_bug.cgi?id=101182 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 101185] System hang during piglit tests

https://bugs.freedesktop.org/show_bug.cgi?id=101185 Bug ID: 101185 Summary: System hang during piglit tests Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal

Re: [PATCH v2 3/5] drm/bridge/synopsys: Add MIPI DSI host controller bridge

Hi Philippe, Thanks a lot for creating a bridge driver for this. Copying some Hisilicon and Rockchip folks so that they can consider adapting to this. Some comments below. On 05/19/2017 08:50 PM, Philippe CORNU wrote: Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the

[Bug 99349] Failed to build shader (translation from TGSI)

https://bugs.freedesktop.org/show_bug.cgi?id=99349 --- Comment #6 from Gert Wollny --- The actual instruction failing is MUL TEMP[11], CONST[26], CONST[23] i.e. the multiplication of two constants. -- You are receiving this mail because: You are the assignee for the

[Bug 98874] amdgpu: [drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, [drm] IP block:5 is hang

https://bugs.freedesktop.org/show_bug.cgi?id=98874 Matthias Nagel changed: What|Removed |Added Summary|Desktop suddenly freezes, |amdgpu:

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

https://bugzilla.kernel.org/show_bug.cgi?id=195737 beta990 (francois5...@gmail.com) changed: What|Removed |Added Kernel Version|4.10.13 |4.11.2 -- You are

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

https://bugzilla.kernel.org/show_bug.cgi?id=195737 --- Comment #7 from beta990 (francois5...@gmail.com) --- Sorry for the delay. I've added the requested logs and provided a photo of what is happening on my screen atm. when using AMDGPU. Thanks and please let me know if more info is needed. :)

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

https://bugzilla.kernel.org/show_bug.cgi?id=195737 --- Comment #6 from beta990 (francois5...@gmail.com) --- Created attachment 256717 --> https://bugzilla.kernel.org/attachment.cgi?id=256717=edit Screen -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

https://bugzilla.kernel.org/show_bug.cgi?id=195737 --- Comment #5 from beta990 (francois5...@gmail.com) --- Created attachment 256715 --> https://bugzilla.kernel.org/attachment.cgi?id=256715=edit Xorg-log -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

https://bugzilla.kernel.org/show_bug.cgi?id=195737 --- Comment #4 from beta990 (francois5...@gmail.com) --- Created attachment 256713 --> https://bugzilla.kernel.org/attachment.cgi?id=256713=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.

Re: [PATCH 3/5] drm/syncobj: add sync_file interaction.

On Wed, May 24, 2017 at 05:06:13PM +1000, Dave Airlie wrote: > From: Dave Airlie > > This interface allows importing the fence from a sync_file into > an existing drm sync object, or exporting the fence attached to > an existing drm sync object into a new sync file object. >

Re: [PATCH 2/5] drm/syncobj: add sync obj wait interface. (v3)

On Wed, May 24, 2017 at 05:06:12PM +1000, Dave Airlie wrote: > From: Dave Airlie > > This interface will allow sync object to be used to back > Vulkan fences. This API is pretty much the vulkan fence waiting > API, and I've ported the code from amdgpu. > > v2: accept

Re: [PATCH 1/5] drm: introduce sync objects (v3)

On Wed, May 24, 2017 at 05:06:11PM +1000, Dave Airlie wrote: > From: Dave Airlie > > Sync objects are new toplevel drm object, that contain a > pointer to a fence. This fence can be updated via command > submission ioctls via drivers. > > There is also a generic wait obj API

Re: [PATCH 19/37] drm/fsl: Drop drm_vblank_cleanup

On 2017-05-24 07:51, Daniel Vetter wrote: > Again cleanup before irq disabling doesn't really stop the races, > so just drop it. Proper fix would be to put drm_atomic_helper_shutdown > before everything gets cleaned up. Hm, I already use the non-atomic drm_crtc_force_disable_all before, I think

[Bug 99349] Failed to build shader (translation from TGSI)

https://bugs.freedesktop.org/show_bug.cgi?id=99349 --- Comment #5 from Gert Wollny --- Adding yet more debugging output, and so far it seems that there is only one operation failing: a multiplication of two operands with a write mask of 0xF (see log below). I also tested

Re: [PATCH 08/37] drm/doc: Polish irq helper documentation

On 2017-05-24 07:51, Daniel Vetter wrote: > Pull a (much shorter) overview into drm_irq.c, and instead put the > callback documentation into in-line comments in drm_drv.h. Looks good and just found all I needed to know to fix IRQ registration in fsl dcu. Reviewed-by: Stefan Agner

[Bug 101182] Reading amdgpu_pm_info causes stutter with Linux 4.12-rc

https://bugs.freedesktop.org/show_bug.cgi?id=101182 --- Comment #1 from Christoph Haag --- Created attachment 131501 --> https://bugs.freedesktop.org/attachment.cgi?id=131501=edit screenshot showing the stuttering in the HUD -- You are receiving this mail because: You

[Bug 101182] Reading amdgpu_pm_info causes stutter with Linux 4.12-rc

https://bugs.freedesktop.org/show_bug.cgi?id=101182 Bug ID: 101182 Summary: Reading amdgpu_pm_info causes stutter with Linux 4.12-rc Product: DRI Version: DRI git Hardware: Other OS: All Status:

Re: [PATCH 2/6] drm/i915: update cursors asynchronously through atomic

On Thu, May 25, 2017 at 01:41:33AM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Add support to async updates of cursors by using the new atomic > interface for that. Basically what this commit does is do what > intel_legacy_cursor_update() did but