[Bug 98513] [REGRESSION][drm-next-4.10-wip][AMDGPU][CIK] Unable to suspend, hangs on hibernation bad commit 86f8c599b09c916f9aad30563271440dbd79213a

||1440dbd79213a -- You are receiving 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/20161108/873fa136/attachment.html>

[Bug 98513] [REGRESSION][4.9-rc3 w/ drm-next-4.10-wip][AMDGPU][CIK] Unable to suspend, hangs on hibernation

: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/d15beebc/attachment.html>

[drm-intel:topic/drm-misc 1/14] warning: (KMEMCHECK && ..) selects STACKTRACE which has unmet direct dependencies (STACKTRACE_SUPPORT)

<https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/2a5ff0b1/attachment-0001.gz>

BUG: 'list_empty(>free_vbufs)' is true!

On Mon, Nov 07, 2016 at 09:43:24AM +0100, Jiri Slaby wrote: > Hi, > > I can relatively easily reproduce this bug: > BUG: 'list_empty(>free_vbufs)' is true! > [ cut here ] > kernel BUG at /home/latest/linux/drivers/gpu/drm/virtio/virtgpu_vq.c:130! > invalid opcode:

[PATCH] drm/sun4i: Fix error handling

gt; -struct sun4i_layer *layer = layers[i]; > +struct sun4i_layer *layer; > > layer = sun4i_layer_init_one(drm, plane); > if (IS_ERR(layer)) { > dev_err(drm->dev, "Couldn't initialize %s plane\n", > i ?

[PATCH v2 0/5] ARM: da850: new drivers for better LCDC support

+ Arnd, Olof On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote: > This series adds two new drivers in order to better support the LCDC > rev1 present on the da850 boards. > > The first patch adds a new memory driver which allows to write to the > DDR2/mDDR memory controller present

[PATCH 4/4] drm/tegra: Set sgt pointer in BO pin

Fix tegra_bo_pin to set the parameter sgt pointer. Host1x job pinning requires the sgt to determine physical memory addresses of gathers. Signed-off-by: Mikko Perttunen --- drivers/gpu/drm/tegra/gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/tegra/gem.c

[PATCH 3/4] drm/tegra: Support kernel mappings with IOMMU

From: Arto Merilainen Host1x command buffer patching requires that the buffer object can be mapped into kernel address space, however, the recent addition of IOMMU did not account to this requirement. Therefore Host1x engines cannot be used if IOMMU is enabled. This

[PATCH 2/4] gpu: host1x: Add locking to syncpt

From: Arto Merilainen Currently syncpoints are not locked by mutex and this causes races if we are aggressively freeing and allocating syncpoints. This patch adds missing mutex protection to syncpoint structures. Signed-off-by: Arto Merilainen Reviewed-by: Shridhar

[PATCH 1/4] gpu: host1x: Store device address to all bufs

From: Arto Merilainen Currently job pinning is optimized to handle only the first buffer using a certain host1x_bo object and all subsequent buffers using the same host1x_bo are considered done. In most cases this is correct, however, in case the same host1x_bo is used

[PATCH 1/2] drm/imx: disable planes before DC

Am Dienstag, den 08.11.2016, 17:04 +0100 schrieb Lucas Stach: > If the DC clock is disabled before the attached IDMACs are properly > stopped the IDMACs may hang the IPU or even the whole system. > > Make sure the IDMACs are in safe state by disabling the planes before > removal of the DC clock.

[drm-intel:topic/drm-misc 1/13] ERROR: "depot_save_stack" [drivers/gpu/drm/drm.ko] undefined!

n-text attachment was scrubbed... Name: .config.gz Type: application/gzip Size: 33705 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/953192f4/attachment-0001.gz>

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 8 November 2016 at 18:36, Mauro Santos wrote: > On 08-11-2016 18:08, Mauro Santos wrote: >> On 08-11-2016 17:13, Emil Velikov wrote: >>> On 8 November 2016 at 16:57, Mauro Santos >>> wrote: On 08-11-2016 15:57, Emil Velikov wrote: > On 8 November 2016 at 15:27, Mauro Santos >

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 08-11-2016 18:08, Mauro Santos wrote: > On 08-11-2016 17:13, Emil Velikov wrote: >> On 8 November 2016 at 16:57, Mauro Santos >> wrote: >>> On 08-11-2016 15:57, Emil Velikov wrote: On 8 November 2016 at 15:27, Mauro Santos wrote: > On 08-11-2016 15:00, Emil Velikov wrote:

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 05:20:36PM +, Jon Medhurst (Tixy) wrote: > On Tue, 2016-11-08 at 13:34 +, Russell King - ARM Linux wrote: > > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: > > > Unfortunately, my drm-tda998x-devel branch is slightly out of date with > >

[PATCH] drm/tegra: add tiling FB modifiers

On 11/08/2016 06:07 PM, Erik Faye-Lund wrote: > On Tue, Nov 8, 2016 at 8:50 AM, Alexandre Courbot > wrote: >> Add FB modifiers to allow user-space to specify that a surface is in one >> of the two tiling formats supported by Tegra chips, and add support in >> the tegradrm driver to handle them

[PATCH 04/20] drm/ast: use DRM_FB_HELPER_DEFAULT_OPS for fb_ops

On Wed, Oct 26, 2016 at 09:15:15PM +0200, Daniel Vetter wrote: > On Wed, Oct 26, 2016 at 8:47 PM, Stefan Lengfeld > wrote: > > > > On Tue, Oct 25, 2016 at 04:57:37PM +0200, Daniel Vetter wrote: > >> On Thu, Sep 29, 2016 at 10:48:40PM +0200, Stefan Christ wrote: > >> > Cc: Dave Airlie > >> >

[Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 06:04:15PM +0100, Peter Zijlstra wrote: > On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > > Now, I know you're working on getting rid of this entirely for i915, but > > > what about that MSM driver? Will we continue to need it there, is > > > anybody

[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

On 08/11/16 15:56, Arnd Bergmann wrote: > The newly introduced LED handling for nouveau fails to link when the > driver is built-in but the LED subsystem is a loadable module: > > drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': > tvnv17.c:(.text.nouveau_do_suspend+0x10):

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 08-11-2016 17:13, Emil Velikov wrote: > On 8 November 2016 at 16:57, Mauro Santos > wrote: >> On 08-11-2016 15:57, Emil Velikov wrote: >>> On 8 November 2016 at 15:27, Mauro Santos >>> wrote: On 08-11-2016 15:00, Emil Velikov wrote: > On 8 November 2016 at 13:38, Mauro Santos

[Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > Now, I know you're working on getting rid of this entirely for i915, but > > what about that MSM driver? Will we continue to need it there, is > > anybody actually maintaining that thing? > > Rob Clark is, and since he's a one-man

[Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 05:09:16PM +0100, Daniel Vetter wrote: > > You're talking about: > > > > lkml.kernel.org/r/20161007154351.GL3117 at twins.programming.kicks-ass.net > > > > ? I got no feedback from you DRM guys on that so I kinda forgot about > > that in the hope we'd not have to do

[PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

On Tue, 2016-11-08 at 03:47 -0800, Robert Bragg wrote: > > > On Tue, Nov 8, 2016 at 6:19 AM, sourab gupta > wrote: > On Mon, 2016-11-07 at 11:49 -0800, Robert Bragg wrote: > > The maximum OA sampling frequency is now configurable via a > > dev.i915.oa_max_sample_rate

[GIT PULL] drm/fsl-dcu: fixes for v4.9-rc5

Hi Dave, Yet antoher small batch of fixes. Two of the patches I had prepared since quite some time, but they did not seem to affect operation in a visible manner so far. Until recently, when I discovered the third issue (disable planes before disabling CRTC), which made the two previous fixes

[Intel-gfx] [PATCH] drm/i915: avoid harmless empty-body warning

On Tue, Nov 08, 2016 at 02:49:05PM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote: > > The newly added assert_kernel_context_is_current introduces a warning > > when built with W=1: > > > > drivers/gpu/drm/i915/i915_gem.c: In function > >

[PATCH] drm/vmwgfx : Fix NULL pointer comparison

From: Ravikant B Sharma Replace direct comparisons to NULL i.e. 'x == NULL' with '!x'. As per coding standard. Signed-off-by: Ravikant B Sharma --- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf_res.c|4 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_context.c |2 +-

[Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

2016-11-08 17:12 GMT+01:00 Arnd Bergmann : > On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: >> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: >> > The underlying problem is that we already have a number of other >> > symbols that either have "depends on LEDS_CLASS"

[PATCH RFC 00/12] tda998x updates

On Tue, 2016-11-08 at 13:34 +, Russell King - ARM Linux wrote: > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: > > Unfortunately, my drm-tda998x-devel branch is slightly out of date with > > these patches it's the original set of 10 patches. I've not pushed > >

[PATCH] drm: mali-dp: Add support for setting plane's rotation property from userspace.

On Tue, Nov 08, 2016 at 01:43:25PM +, Liviu Dudau wrote: > In order to support DRM_IOCTL_MODE_OBJ_SETPROPERTY for the rotation property > we need to have a ->set_property hook defined for the planes. Set the > plane's ->set_property hook to drm_atomic_helper_plane_set_property() > >

[Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

2016-11-08 16:46 GMT+01:00 Ilia Mirkin : > On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote: >> The newly introduced LED handling for nouveau fails to link when the >> driver is built-in but the LED subsystem is a loadable module: >> >> drivers/gpu/drm/nouveau/nouveau.o: In function

[GIT PULL][drm-next] drm/mali-dp fixes and updates

On Tue, Nov 08, 2016 at 01:41:08PM +, Liviu Dudau wrote: > On Tue, Nov 08, 2016 at 01:49:55PM +0100, Daniel Vetter wrote: > > On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote: > > > Hi Dave, > > > > > > Here is the list of fixes that I have for drm/mali-dp. They've been on > > >

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 8 November 2016 at 16:57, Mauro Santos wrote: > On 08-11-2016 15:57, Emil Velikov wrote: >> On 8 November 2016 at 15:27, Mauro Santos >> wrote: >>> On 08-11-2016 15:00, Emil Velikov wrote: On 8 November 2016 at 13:38, Mauro Santos wrote: > On 08-11-2016 11:06, Emil Velikov

[Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: > On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: > > The underlying problem is that we already have a number of other > > symbols that either have "depends on LEDS_CLASS" or > > "select LEDS_CLASS". To clean that up

[PATCH v7 1/3] drm/fence: add in-fences support

On Tue, Nov 08, 2016 at 03:27:14PM +, Brian Starkey wrote: > Hi Gustavo, > > On Tue, Nov 08, 2016 at 03:54:48PM +0900, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > There is now a new property called IN_FENCE_FD attached to every plane > > state that receives sync_file fds from

[Intel-gfx] linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 02:24:48PM +0100, Peter Zijlstra wrote: > On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote: > > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote: > > > Hi all, > > > > > > FIXME: Add owner of second tree to To: > > >Add author(s)/SOB of

imx-drm hang issue with etnaviv (GC3000)

Am Freitag, den 28.10.2016, 10:18 +0200 schrieb Lucas Stach: > Am Donnerstag, den 27.10.2016, 19:26 +0200 schrieb Wladimir J. van der > Laan: > > Hello, > > > > After running kmscube (or another KMS executable) on a i.MX6 QuadPlus > > (etnaviv, > > GC3000) a few times on I get the below crash in

[Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: > The underlying problem is that we already have a number of other > symbols that either have "depends on LEDS_CLASS" or > "select LEDS_CLASS". To clean that up properly, we should either > make the symbol itself hidden and only select

[PATCH 2/2] gpu: ipu-v3: remove IRQ dance on DC channel disable

This has never worked properly, as the IRQ got retriggered immediately on unmask. Remove the IRQ wait dance, as it is apparently safe to disable the DC channel at any point in time. Signed-off-by: Lucas Stach --- drivers/gpu/ipu-v3/ipu-dc.c | 61 +++-- 1

[PATCH 1/2] drm/imx: disable planes before DC

If the DC clock is disabled before the attached IDMACs are properly stopped the IDMACs may hang the IPU or even the whole system. Make sure the IDMACs are in safe state by disabling the planes before removal of the DC clock. Fixes: 33f14235302f (drm/imx: atomic phase 1: Use transitional atomic

[PATCH] gpu: ipu-di: silence videomode logspam

Adapting the videomode to the hardware constraints is something that can and must happen during normal operation and isn't something that the user can avoid. So printing a warning each time it happens isn't helpful. Demote this message to the debug level. Signed-off-by: Lucas Stach ---

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 08-11-2016 15:57, Emil Velikov wrote: > On 8 November 2016 at 15:27, Mauro Santos > wrote: >> On 08-11-2016 15:00, Emil Velikov wrote: >>> On 8 November 2016 at 13:38, Mauro Santos >>> wrote: On 08-11-2016 11:06, Emil Velikov wrote: > On 1 November 2016 at 18:47, Mauro Santos

[GIT PULL] bridge/dw-hdmi: I2C master controller support

Hi Dave, On 2016-09-19 00:16, Philipp Zabel wrote: > Hi Dave, > > this tag contains support for the I2C master controller contained in the > HDMI TX IP core, for those boards that don't allow to mux their DDC pins > to SoC I2C controllers. This will make the dw-hdmi driver register its >

[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

On Tuesday, November 8, 2016 10:46:07 AM CET Ilia Mirkin wrote: > > diff --git a/drivers/gpu/drm/nouveau/Kconfig > > b/drivers/gpu/drm/nouveau/Kconfig > > index 78631fb61adf..715cd6f4dc31 100644 > > --- a/drivers/gpu/drm/nouveau/Kconfig > > +++ b/drivers/gpu/drm/nouveau/Kconfig > > @@ -46,6

[PATCH] drm/tegra: add tiling FB modifiers

Add FB modifiers to allow user-space to specify that a surface is in one of the two tiling formats supported by Tegra chips, and add support in the tegradrm driver to handle them properly. This is necessary for the display controller to directly display buffers generated by the GPU. This feature

[PATCH v2] drm/udl: Ensure channel is selected before using the device.

On 8 November 2016 at 16:40, Dave Airlie wrote: >> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed >> udl 1-2:1.0: fb1: udldrmfb frame buffer device >> [drm] Initialized udl on minor 1 >> usbcore: registered new interface driver udl >> >> >> Is this expected WARN? > > I've just

[PATCH] drm/udl: make control msg static const. (v2)

From: Dave Airlie Thou shall not send control msg from the stack, does that mean I can send it from the RO memory area? and it looks like the answer is no, so here's v2 which kmemdups. Reported-by: poma Signed-off-by: Dave Airlie --- drivers/gpu/drm/udl/udl_main.c | 16

[PATCH] drm: mali-dp: Add support for setting plane's rotation property from userspace.

On Tue, Nov 08, 2016 at 05:16:41PM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 01:43:25PM +, Liviu Dudau wrote: > > In order to support DRM_IOCTL_MODE_OBJ_SETPROPERTY for the rotation property > > we need to have a ->set_property hook defined for the planes. Set the > > plane's

[PATCH v2] drm/udl: Ensure channel is selected before using the device.

> [drm:udl_driver_load [udl]] *ERROR* Selecting channel failed > udl 1-2:1.0: fb1: udldrmfb frame buffer device > [drm] Initialized udl on minor 1 > usbcore: registered new interface driver udl > > > Is this expected WARN? I've just posted a patch in theory to fix it, please test if oyu have

[PATCH 0/7] drm: add atomic state logging and debugfs

On Sat, Nov 5, 2016 at 11:08 AM, Rob Clark wrote: > I realized that I had not re-sent this after updating from review > comments, and adding kerneldoc. > > The drm/msm bits I can include in my msm-next pull-req for 4.10. Just > including them here to show example usage. > > There will be a minor

[PATCH] drm/udl: make control msg static const.

From: Dave Airlie Thou shall not send control msg from the stack, does that mean I can send it from the RO memory area? Reported-by: poma Signed-off-by: Dave Airlie --- drivers/gpu/drm/udl/udl_main.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

On 8 November 2016 at 16:21, Karol Herbst wrote: > 2016-11-08 17:12 GMT+01:00 Arnd Bergmann : >> On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: >>> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: >>> > The underlying problem is that we already have a number of

Enable AMDGPU for CIK by default

On 07/11/16 11:25 PM, Bridgman, John wrote: >> From: dri-devel [mailto:dri-devel-bounces at lists.freedesktop.org] On Behalf >> Of Michel Dänzer >> Sent: Monday, November 07, 2016 2:24 AM >> On 07/11/16 03:56 AM, Sandeep wrote: >>> >>> I was wondering when DRM_AMDGPU_CIK would be turned on by

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 8 November 2016 at 15:27, Mauro Santos wrote: > On 08-11-2016 15:00, Emil Velikov wrote: >> On 8 November 2016 at 13:38, Mauro Santos >> wrote: >>> On 08-11-2016 11:06, Emil Velikov wrote: On 1 November 2016 at 18:47, Mauro Santos wrote: > On 01-11-2016 18:13, Emil Velikov

[PATCH v7 3/3] drm/fence: add out-fences support

From: Gustavo Padovan Support DRM out-fences by creating a sync_file with a fence for each CRTC that sets the OUT_FENCE_PTR property. We use the out_fence pointer received in the OUT_FENCE_PTR prop to send the sync_file fd back to userspace. The sync_file and

[PATCH v7 2/3] drm/fence: add fence timeline to drm_crtc

From: Gustavo Padovan Create one timeline context for each CRTC to be able to handle out-fences and signal them. It adds a few members to struct drm_crtc: fence_context, where we store the context we get from fence_context_alloc(), the fence seqno and the fence

[PATCH v7 1/3] drm/fence: add in-fences support

From: Gustavo Padovan There is now a new property called IN_FENCE_FD attached to every plane state that receives sync_file fds from userspace via the atomic commit IOCTL. The fd is then translated to a fence (that may be a fence_array subclass or just a normal

[PATCH v7 0/3] drm: add explict fencing

From: Gustavo Padovan Hi, This is yet another version of the DRM fences patches. Please refer to the cover letter[1] in a previous version to check for more details. In v7 we now have split most of the out_fences code into prepare_crtc_signaling() and

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 03:25:45PM +, Robin Murphy wrote: > On 08/11/16 13:34, Russell King - ARM Linux wrote: > > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: > >> Unfortunately, my drm-tda998x-devel branch is slightly out of date with > >> these patches it's the

[PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2

On Mon, 7 Nov 2016 23:37:41 +0100 Maxime Ripard wrote: > Hi, > > On Fri, Oct 28, 2016 at 07:34:20PM +0200, Jean-Francois Moine wrote: > > On Fri, 28 Oct 2016 00:03:16 +0200 > > Maxime Ripard wrote: [snip] > > > > > We've been calling them bus and mod. > > > > > > > > I can understand

[PATCH v7 3/3] drm/fence: add out-fences support

On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote: >From: Gustavo Padovan > >+static struct dma_fence *get_crtc_fence(struct drm_crtc *crtc, >+ struct drm_crtc_state *crtc_state) >+{ >+ struct dma_fence *fence; >+ >+ fence =

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 08-11-2016 15:00, Emil Velikov wrote: > On 8 November 2016 at 13:38, Mauro Santos > wrote: >> On 08-11-2016 11:06, Emil Velikov wrote: >>> On 1 November 2016 at 18:47, Mauro Santos >>> wrote: On 01-11-2016 18:13, Emil Velikov wrote: > From: Emil Velikov > > Parsing config

[PATCH v7 1/3] drm/fence: add in-fences support

Hi Gustavo, On Tue, Nov 08, 2016 at 03:54:48PM +0900, Gustavo Padovan wrote: >From: Gustavo Padovan > >There is now a new property called IN_FENCE_FD attached to every plane >state that receives sync_file fds from userspace via the atomic commit >IOCTL. > >The fd is then translated to a fence

[PATCH RFC 00/12] tda998x updates

On 08/11/16 13:34, Russell King - ARM Linux wrote: > On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: >> Unfortunately, my drm-tda998x-devel branch is slightly out of date with >> these patches it's the original set of 10 patches. I've not pushed >> these ones out to that

linux-next: manual merge of the tip tree with the drm-intel tree

Hi all, FIXME: Add owner of second tree to To: Add author(s)/SOB of conflicting commits. Today's linux-next merge of the tip tree got a conflict in: drivers/gpu/drm/i915/i915_gem_shrinker.c between commits: 1233e2db199d ("drm/i915: Move object backing storage manipulation to its

[PATCH 2/2] drm/edid: Consider alternate cea timings to be the same VIC

On Tue, Nov 08, 2016 at 12:43:55PM +0100, Andrzej Hajda wrote: > On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote: > > From: Ville Syrjälä > > > > CEA-861 specifies that the vertical front porch may vary by one or two > > lines for specific VICs. Up to now we've only considered a

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 8 November 2016 at 13:38, Mauro Santos wrote: > On 08-11-2016 11:06, Emil Velikov wrote: >> On 1 November 2016 at 18:47, Mauro Santos >> wrote: >>> On 01-11-2016 18:13, Emil Velikov wrote: From: Emil Velikov Parsing config sysfs file wakes up the device. The latter of which

[PATCH] drm/i915: avoid harmless empty-body warning

The newly added assert_kernel_context_is_current introduces a warning when built with W=1: drivers/gpu/drm/i915/i915_gem.c: In function ‘assert_kernel_context_is_current’: drivers/gpu/drm/i915/i915_gem.c:4417:63: error: suggest braces around empty body in an ‘else’ statement

[PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

The newly introduced LED handling for nouveau fails to link when the driver is built-in but the LED subsystem is a loadable module: drivers/gpu/drm/nouveau/nouveau.o: In function `nouveau_do_suspend': tvnv17.c:(.text.nouveau_do_suspend+0x10): undefined reference to `nouveau_led_suspend'

[PATCH] drm/amdgpu/powerplay/smu7: fix unintialized data usage

A recent bugfix replaced an out-of-bounds access with direct use of unintialized data: drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c: In function 'smu7_patch_limits_vddc': drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddc' may be used uninitialized in this function

[PATCH] drm/i915: avoid harmless empty-body warning

On Tue, Nov 08, 2016 at 02:58:17PM +0100, Arnd Bergmann wrote: > The newly added assert_kernel_context_is_current introduces a warning > when built with W=1: > > drivers/gpu/drm/i915/i915_gem.c: In function > ‘assert_kernel_context_is_current’: > drivers/gpu/drm/i915/i915_gem.c:4417:63:

linux-next: manual merge of the tip tree with the drm-intel tree

On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > FIXME: Add owner of second tree to To: > >Add author(s)/SOB of conflicting commits. > > > > Today's linux-next merge of the tip tree got

[PATCH v7 0/3] drm: add explict fencing

On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > This is yet another version of the DRM fences patches. Please refer > to the cover letter[1] in a previous version to check for more details. > > In v7 we now have split most of the out_fences

[PATCH v7 3/3] drm/fence: add out-fences support

On Tue, Nov 08, 2016 at 03:54:50PM +0900, Gustavo Padovan wrote: > From: Gustavo Padovan > > Support DRM out-fences by creating a sync_file with a fence for each CRTC > that sets the OUT_FENCE_PTR property. > > We use the out_fence pointer received in the OUT_FENCE_PTR prop to send > the

[Bug 98523] Can't run without "nomodeset" on MacPro6,1 with two AMD R9 280X Tahiti video cards

tps://lists.freedesktop.org/archives/dri-devel/attachments/20161108/650e3675/attachment.html>

[PATCH v3 08/11] drm/edid: Remove drm_select_eld

The only user was i915, which is now gone. Signed-off-by: Maarten Lankhorst Reviewed-by: Ville Syrjälä Acked-by: Dave Airlie #irc Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_edid.c | 26 -- include/drm/drm_edid.h | 1 - 2 files changed, 27

[PATCH v7 0/3] drm: add explict fencing

On Tue, Nov 08, 2016 at 01:44:34PM +0100, Christian König wrote: > Am 08.11.2016 um 12:45 schrieb Chris Wilson: > > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote: > > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote: > > > > On Tue, Nov 08, 2016 at 03:54:47PM +0900,

[GIT PULL][drm-next] drm/mali-dp fixes and updates

On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote: > Hi Dave, > > Here is the list of fixes that I have for drm/mali-dp. They've been on the > mailing > lists for a while and merged into linux-next for a few weeks, but due to > holiday and > travel to Linux Plumbers I did not send the

[PATCH] drm: Add stackdepot include for DRM_DEBUG_MM

On Tue, Nov 08, 2016 at 11:56:01AM +, Chris Wilson wrote: > 0day found that stackdepot.h doesn't get automatically included on all > architectures, so remember to add our #include. > > Reported-by: kbuild test robot > Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on >

[PATCH] drm: Add stackdepot include for DRM_DEBUG_MM

Am 08.11.2016 um 12:56 schrieb Chris Wilson: > 0day found that stackdepot.h doesn't get automatically included on all > architectures, so remember to add our #include. > > Reported-by: kbuild test robot > Fixes: 5705670d0463 ("drm: Track drm_mm allocators and show leaks on > shutdown") >

[PATCH] drm: mali-dp: Clear CVAL when leaving config mode

It's possible for CVAL to get set whilst we are in config mode. If this happens, afer we leave config mode the HW will latch whatever configuration is in the registers at the next vsync. Most likely this will be a partial configuration, as we'll be racing against the ongoing atomic_commit. To

[PATCH v7 0/3] drm: add explict fencing

Am 08.11.2016 um 12:45 schrieb Chris Wilson: > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote: >> On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote: >>> On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote: From: Gustavo Padovan Hi,

[PATCH v7 0/3] drm: add explict fencing

On Tue, Nov 08, 2016 at 11:45:51AM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote: > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote: > > > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote: > > > > From: Gustavo Padovan > >

[PATCH] drm: mali-dp: Add support for setting plane's rotation property from userspace.

In order to support DRM_IOCTL_MODE_OBJ_SETPROPERTY for the rotation property we need to have a ->set_property hook defined for the planes. Set the plane's ->set_property hook to drm_atomic_helper_plane_set_property() Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/malidp_planes.c | 1 + 1

[GIT PULL][drm-next] drm/mali-dp fixes and updates

On Tue, Nov 08, 2016 at 01:49:55PM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 12:26:19PM +, Liviu Dudau wrote: > > Hi Dave, > > > > Here is the list of fixes that I have for drm/mali-dp. They've been on the > > mailing > > lists for a while and merged into linux-next for a few

[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

On 08-11-2016 11:06, Emil Velikov wrote: > On 1 November 2016 at 18:47, Mauro Santos > wrote: >> On 01-11-2016 18:13, Emil Velikov wrote: >>> From: Emil Velikov >>> >>> Parsing config sysfs file wakes up the device. The latter of which may >>> be slow and isn't required to begin with. >>> >>>

[Bug 95306] Random Blank(black) screens on "Carrizo"

;> hours without blanking. >> >> -- >> You are receiving this mail because: >> >>- You are on the CC list for the bug. >> >> -- You are receiving this mail because: You are the assignee for the bug. -- next p

[Bug 95306] Random Blank(black) screens on "Carrizo"

he bug. > > -- You are receiving 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/20161108/337c2123/attachment.html>

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 01:32:15PM +, Russell King - ARM Linux wrote: > Unfortunately, my drm-tda998x-devel branch is slightly out of date with > these patches it's the original set of 10 patches. I've not pushed > these ones out to that branch yet, as I've three additional patches on > top

[PATCH RFC 00/12] tda998x updates

On Tue, Nov 08, 2016 at 01:19:51PM +, Robin Murphy wrote: > Hi Russell, > > On 08/11/16 12:24, Russell King - ARM Linux wrote: > > As no one responded to the previous round, I'm not spending soo much > > time writing up a description of these changes again. It's also been > > quite a long

[PATCH RFC 00/12] tda998x updates

Hi Russell, On 08/11/16 12:24, Russell King - ARM Linux wrote: > As no one responded to the previous round, I'm not spending soo much > time writing up a description of these changes again. It's also been > quite a long time, so I've forgotten all the details of the changes, > so I'll do my

[PATCH 2/2] drm: Restrict stackdepot usage to builtin drm.ko

I misread the kbuild result thinking that we had missed the include (which we had for completeness anyway), what kbuild was actually warning me about was that depot_save_stack was not exported. Temporarily fix this by only selecting STACKDEPOT iff drm.ko is builtin Reported-by: kbuild test robot

[PATCH 1/2] drm/i915: Restrict DRM_DEBUG_MM automatic selection

DRM_DEBUG_MM is only valid if the DRM.ko is builtin as currently depot_save_stack is not exported. Fixes: 5c7fcf2db027 ("drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUG") Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] drm: Add stackdepot include for DRM_DEBUG_MM

On Tue, Nov 08, 2016 at 01:46:15PM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 11:56:01AM +, Chris Wilson wrote: > > 0day found that stackdepot.h doesn't get automatically included on all > > architectures, so remember to add our #include. > > > > Reported-by: kbuild test robot > >

[v2] drm/rockchip: Use an enum to identify Rockchip VOPs

On Thu, Nov 03, 2016 at 12:46:48PM -0700, Kristian Høgsberg wrote: > We used to call drm_of_encoder_active_endpoint_id() from > rockchip_dp_drm_encoder_atomic_check() to determine the endpoint for the > active encoder. However, the encoder isn't necessarily active at this > point or it may be

[PATCH v7 0/3] drm: add explict fencing

On Tue, Nov 08, 2016 at 01:43:40PM +0100, Daniel Vetter wrote: > On Tue, Nov 08, 2016 at 11:45:51AM +, Chris Wilson wrote: > > On Tue, Nov 08, 2016 at 12:32:56PM +0100, Daniel Vetter wrote: > > > On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote: > > > > On Tue, Nov 08, 2016 at

[PATCH v2] drm/i915: don't whitelist oacontrol in cmd parser

This v2 patch bumps the command parser version so it can be referenced in corresponding i-g-t gem_exec_parse changes. --- >8 --- Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable

[PATCH 2/2] drm/edid: Consider alternate cea timings to be the same VIC

On 03.11.2016 13:53, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > CEA-861 specifies that the vertical front porch may vary by one or two > lines for specific VICs. Up to now we've only considered a mode to match > the VIC if it matched the shortest possible vertical front

[PATCH v7 0/3] drm: add explict fencing

On Tue, Nov 08, 2016 at 10:35:08AM +, Chris Wilson wrote: > On Tue, Nov 08, 2016 at 03:54:47PM +0900, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Hi, > > > > This is yet another version of the DRM fences patches. Please refer > > to the cover letter[1] in a previous version to

[PATCH] drm: panel: simple-panel: get the enable gpio as-is

-cases, but it would at least allow basic hand-over. Also, if leaving the GPIO configured as-is causes glitches or other issues, then these are observable with the current code as well, until the panel driver takes over and disables everything. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161108/e0f3dae7/attachment.sig>

[PATCH] drm: tda998x: mali-dp: hdlcd: refactor connector registration

On Tue, Nov 08, 2016 at 10:59:43AM +, Russell King - ARM Linux wrote: > On Tue, Nov 08, 2016 at 10:25:52AM +0100, Daniel Vetter wrote: > > Hm, I entirely missed that part of the troubles. Anyway, if you all agree > > on a patch I certainly won't block it, feel free to merge through suitable >

  1   2   >