[lkp-robot] [drm/fb] a583bc678d: WARNING:at_kernel/workqueue.c:#flush_workqueue

FYI, we noticed the following commit: commit: a583bc678d0a5e54844d3380e242dd9bb5fb0b00 ("drm/fb-helper: Allocate a drm_file") url: https://github.com/0day-ci/linux/commits/Noralf-Tr-nnes/drm-fb-helper-Use-drm_file-to-get-a-dumb-framebuffer/20170914-132818 base:

[PATCH v2] gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

From: Fabio Estevam The 'di' variable is never used inside ipu_dc_enable_channel(), so just remove it. This fixes the following build warning with W=1: drivers/gpu/ipu-v3/ipu-dc.c: In function 'ipu_dc_enable_channel': drivers/gpu/ipu-v3/ipu-dc.c:252:6: warning: variable

[PATCH] gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

From: Fabio Estevam The 'di' variable is never used inside lipu_dc_enable_channel(), so just remove it. This fixes the following build warning with W=1: drivers/gpu/ipu-v3/ipu-dc.c: In function 'ipu_dc_enable_channel': drivers/gpu/ipu-v3/ipu-dc.c:252:6: warning: variable

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #12 from Justin Mitzel --- Created attachment 134285 --> https://bugs.freedesktop.org/attachment.cgi?id=134285=edit New Xorg Log -- You are receiving this mail because: You are the assignee for the

[Bug 102646] Screen flickering under amdgpu-experimental (buffer corruptions?)

https://bugs.freedesktop.org/show_bug.cgi?id=102646 --- Comment #11 from Justin Mitzel --- The problem also happens in Kernel 4.13.2. Although it does not seem as bad. -- You are receiving this mail because: You are the assignee for the

Re: drm: Why shmem?

Noralf Trønnes writes: > Den 15.09.2017 02.45, skrev Eric Anholt: >> Noralf Trønnes writes: >> >>> Den 30.08.2017 09.40, skrev Daniel Vetter: On Tue, Aug 29, 2017 at 10:40:04AM -0700, Eric Anholt wrote: > Daniel Vetter writes:

GC2000 series support GLES3

Hi guys, when i reading through the (somewhen) upcoming iMX8 and its GC7000 series i stumbled over this one: http://www.vivantecorp.com/index.php/en/technology/3d.html at the very end it is stating the the GC2000 series support GLES3. However when i am looking at my device on the hummingboard

Re: [PATCH] drm/amdgpu: revert tile table update for oland

On Thu, 14 Sep 2017 12:31:29 -0400, Alex Deucher wrote: > On Thu, Sep 14, 2017 at 12:21 PM, Marek Olšák wrote: > > Reviewed-by: Marek Olšák > > Applied. thanks. > > Alex Thanks. I forgot the tag but this is obviously a candidate for stable trees. I

[PATCH v1 2/3] drm: rcar-du: Add suspend resume helpers

The pipeline needs to ensure that the hardware is idle for suspend and resume operations. Implement suspend and resume functions using the DRM atomic helper functions. CC: dri-devel@lists.freedesktop.org Signed-off-by: Kieran Bingham ---

[PATCH v1 0/3] drm/media: Implement DU Suspend and Resume on VSP pipelines

This short series covers two subsystems and implements support for suspend and resume operations on the DU pipelines on Gen3 Rcar platforms. Patch 1: Prevent resuming DRM pipelines, - Ensures that the VSP does not incorrectly start DU pipelines. Patch 2: Add suspend resume helpers - Makes

Re: [PATCH v1 2/3] drm: rcar-du: Add suspend resume helpers

Hi Laurent, Thanks for your speedy review! On 15/09/17 18:02, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Friday, 15 September 2017 19:42:06 EEST Kieran Bingham wrote: >> The pipeline needs to ensure that the hardware is idle for suspend and >> resume operations. >

[PATCH v1 1/3] media: vsp1: Prevent resuming DRM pipelines

DRM pipelines utilising the VSP must stop all frame processing as part of the suspend operation to ensure the hardware is idle. Upon resume, the pipeline must not be started until the DU performs an atomic flush to restore the hardware configuration and state. Therefore the vsp1_pipeline_resume()

[PATCH v1 3/3] drm: rcar-du: Remove unused CRTC suspend/resume functions

An early implementation of suspend-resume helpers are available in the CRTC module, however they are unused and no longer needed. With suspend and resume handled by the core DRM atomic helpers, we can remove the unused functions. CC: dri-devel@lists.freedesktop.org Signed-off-by: Kieran Bingham

[PATCH v2] drm/rockchip: Replace dev_* with DRM_DEV_*

This patch replace instances of dev_info/err/debug with DRM_DEV_INFO/ERROR/WARN respectively inorder to use a drm-formatted specific log messages. Issue corrected with the help of the following Coccinelle script: @r@ @@ ( -dev_info +DRM_DEV_INFO | -dev_err +DRM_DEV_ERROR | -dev_dbg

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

https://bugs.freedesktop.org/show_bug.cgi?id=102389 --- Comment #6 from jeremi.jasin...@gmail.com --- Created attachment 134275 --> https://bugs.freedesktop.org/attachment.cgi?id=134275=edit dmesg log from kde neon -- You are receiving this mail because: You are the assignee for the

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

https://bugs.freedesktop.org/show_bug.cgi?id=102389 --- Comment #5 from jeremi.jasin...@gmail.com --- Created attachment 134274 --> https://bugs.freedesktop.org/attachment.cgi?id=134274=edit xorg log from kde neon -- You are receiving this mail because: You are the assignee for the

[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz

https://bugs.freedesktop.org/show_bug.cgi?id=102389 --- Comment #4 from jeremi.jasin...@gmail.com --- I've changed system to Kde Neon, with stock kernel: 4.10.0-33 and amdgpu-pro driver, but the problem is persistent. I'm attaching new dmesg and Xorg log files. I don't know if errors in dmesg

Re: [git pull] amdkfd next 4.14

On Mon, Sep 4, 2017 at 10:50 AM, Daniel Vetter wrote: > Hi Alex, > > Since Dave is out, can you just pull that into the amd pile? > -Daniel > Hi Alex, Did you take the patches to your pile ? If not, I'll ping Dave again as it seems he is back to work (at least partially). Oded

Re: [PATCH 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

Den 16.09.2017 14.37, skrev Noralf Trønnes: Den 15.09.2017 18.37, skrev Noralf Trønnes: Den 15.09.2017 00.29, skrev Laurent Pinchart: Hi Noralf, On Wednesday, 13 September 2017 18:19:22 EEST Noralf Trønnes wrote: Den 13.09.2017 07.09, skrev Laurent Pinchart: On Monday, 11 September 2017

[PATCHv5 3/5] dt-bindings: document the CEC GPIO bindings

From: Hans Verkuil Document the bindings for the cec-gpio module for hardware where the CEC line and optionally the HPD line are connected to GPIO lines. Signed-off-by: Hans Verkuil --- .../devicetree/bindings/media/cec-gpio.txt | 29

[PATCHv5 2/5] cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events

From: Hans Verkuil Document these new CEC events. Signed-off-by: Hans Verkuil --- Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git

[PATCHv5 5/5] MAINTAINERS: add cec-gpio entry

From: Hans Verkuil Add an entry for the CEC GPIO driver. Signed-off-by: Hans Verkuil --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index eb930ebecfcb..5ef0d34ef502 100644 --- a/MAINTAINERS

[PATCHv5 4/5] cec-gpio: add HDMI CEC GPIO driver

From: Hans Verkuil Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework. While I have heard of SoCs that use the GPIO pin for CEC (apparently an early RockChip SoC used that), the main use-case of this driver is to function as a debugging tool. By

[PATCHv5 0/5] cec-gpio: add HDMI CEC GPIO-based driver

From: Hans Verkuil This driver adds support for CEC implementations that use a pull-up GPIO line. While SoCs exist that do this, the primary use-case is to turn a single-board computer into a cheap CEC debugger. Together with 'cec-ctl --monitor-pin' you can do low-level

[PATCHv5 1/5] cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events

From: Hans Verkuil Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH. This is specifically meant for use with the upcoming cec-gpio driver and makes it possible to trace when the HPD pin changes. Some HDMI sinks do strange things with the HPD and

[PATCHv4 3/3] 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

[PATCHv4 1/3] 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

[PATCHv4 2/3] drm-kms-helpers.rst: document the DP CEC helpers

From: Hans Verkuil Document the Display Port CEC helper functions. Signed-off-by: Hans Verkuil --- Documentation/gpu/drm-kms-helpers.rst | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/gpu/drm-kms-helpers.rst

[PATCHv4 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

From: Hans Verkuil This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX feature. This patch series is based on the current pre-4.14-rc1 mainline which has all the needed cec 4.14 patches merged. This patch series has been tested with my NUC7i5BNK and

Re: [PATCH 0/8] drm/fb-helper: Use drm_file to get a dumb framebuffer

Den 15.09.2017 18.37, skrev Noralf Trønnes: Den 15.09.2017 00.29, skrev Laurent Pinchart: Hi Noralf, On Wednesday, 13 September 2017 18:19:22 EEST Noralf Trønnes wrote: Den 13.09.2017 07.09, skrev Laurent Pinchart: On Monday, 11 September 2017 17:31:54 EEST Noralf Trønnes wrote: Hi, I

Re: [PATCH] drm/radeon: properly initialize r600_audio_status() data

Am 15.09.2017 um 22:06 schrieb Arnd Bergmann: The structure returned from r600_audio_status() is only partially initialized, and older gcc versions (4.3 and 4.4) warn about this: drivers/gpu/drm/radeon/r600_hdmi.c: In function 'r600_audio_status': drivers/gpu/drm/radeon/r600_hdmi.c:108: error:

Re: [PATCH v2 07/11] drm/tinydrm: Drop driver registered message

Den 09.09.2017 23.33, skrev David Lechner: On 09/08/2017 10:07 AM, Noralf Trønnes wrote: No need to put out a driver registered message since drm_dev_register() does that now. SPI speed is an important metric when dealing with display problems, so retain that info. Cc: David Lechner

Re: [PATCH v2 2/2] drm/gem-fb-helper: Use debug message on gem lookup failure

Den 13.09.2017 04.44, skrev Laurent Pinchart: Hi Noralf, Thank you for the patch. On Monday, 11 September 2017 19:37:45 EEST Noralf Trønnes wrote: GEM lookup failure can easily be triggered by userspace so make it a debug message, not an error message. Also remove unnecessary inner

Re: [PATCH v3 10/22] drm/imx: Use drm_gem_fb_create() and drm_gem_fb_prepare_fb()

Den 11.09.2017 09.57, skrev Philipp Zabel: Hi Noralf, On Sun, 2017-08-13 at 15:31 +0200, Noralf Trønnes wrote: drm_fb_cma_create() and drm_fb_cma_prepare_fb() are just wrappers now, use drm_gem_fb_create() and drm_gem_fb_prepare_fb() directly. Cc: Philipp Zabel

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #77 from Emma Stott --- I've just given this another try and unfortunately it's still happening for me, even with the latest kernel: uname -a: Linux winters-pc 4.12.13-1-ARCH #1 SMP PREEMPT Fri Sep 15 06:36:43

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

https://bugs.freedesktop.org/show_bug.cgi?id=93826 Emma Stott changed: What|Removed |Added Resolution|FIXED |---

[Bug 102796] steam not rendering correctly on VEGA 56

https://bugs.freedesktop.org/show_bug.cgi?id=102796 --- Comment #2 from Tom Englund --- using LIBGL_ALWAYS_SOFTWARE=true steam , makes it render just like it should, so i would assume the issue is somewhere in mesa with vega. -- You are receiving this mail because: You