[PATCH] drm: bochs: Prevent double-free of fb helper

If fbdev registration fails for whatever reason, the error path of bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev initialization error is not fatal to the probe function, a subsequent device removal will try to call bochs_fbdev_fini() again, hitting the Oops below. This was

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On 2017.03.23 14:43:44 +0100, Frans Klaver wrote: > On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > > From: Colin Ian King > > > > info is being checked to see if it is a null pointer, however, vpgu is > > dereferencing info before this

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

On 03/23/2017 02:26 PM, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote: We want to provide the vblank irq shadow for pageflip events as well as vblank queries. Such events are completed within the vblank interrupt handler, and so the current check for

Re: [PATCH v4 3/8] dt-bindings: Add Ampire AM-480272H3TMQW-T01H panel

On Wed, Mar 15, 2017 at 06:02:09PM +0100, Yannick Fertre wrote: > Signed-off-by: Yannick Fertre > --- > .../display/panel/ampire,am-480272h3tmqw-t01h.txt | 26 > ++ > 1 file changed, 26 insertions(+) > create mode 100644 >

[git pull] drm fixes for 4.11-rc4.

Hi Linus, This is the fixes pull request for rc4. It contains one core drm/fbdev regression fix. A set of i915 fixes including a few GVT related fixes, along with some reset fixes. One new PCI id for amdgpu, and some minor workaround regression fixes. A set of exynos fixes, dropping support for

[Bug 86351] HDMI audio garbled output on Radeon R9 280X

https://bugzilla.kernel.org/show_bug.cgi?id=86351 --- Comment #26 from Christian Birchinger (jo...@netswarm.net) --- Haven't used HDMI for almost a year now. The issue is still present and this time changing prealloc fixes nothing. 2048 used to work, but now all values i've tried from 64 to 4096

[PATCH v4 1/2] dt-bindings: Add INNOLUX P079ZCA panel bindings

The Innolux P079ZCA is a 7.85" panel with a 768X1024 resolution and connected to DSI using four lanes. Signed-off-by: Chris Zhong Reviewed-by: Brian Norris --- Changes in v4: None Changes in v3: None Changes in v2: None

[PATCH v4 2/2] drm/panel: add innolux,p079zca panel driver

Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI panel. Signed-off-by: Chris Zhong Reviewed-by: Sean Paul Tested-by: Brian Norris --- Changes in v4: - remove backlight check after probe - add bpc info

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

On 2017-03-23 01:53, Michel Dänzer wrote: > From: Michel Dänzer > > Otherwise this can also prevent modesets e.g. for switching VTs, when > multiple monitors with different native resolutions are connected. When changing resolution a regular fbdev driver also changes

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 18:14, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 17:42, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:43,

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote: > On 03/22/2017 02:48 PM, Rob Clark wrote: >> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote: >>> >>> Quoting Rob Clark (2017-03-22 10:07:54) I guess an interesting question (from

[PATCH] drm: omapdrm: Fix oops on rmmod

Looks like in Linux next we can now get an oops when unloading omapdrm: Unable to handle kernel NULL pointer dereference at virtual address ... LR is at omap_drm_irq_uninstall+0xb0/0xe0 [omapdrm] ... [] (omap_drm_irq_uninstall [omapdrm]) from [] (pdev_remove+0x50/0x88 [omapdrm]) []

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

Hi Ville, On 23-03-2017 19:00, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 15:16, Ville Syrjälä wrote: >>> On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote: Add the HDMI 2.0 aspect ratio flags (64:27 and

Re: [RFC 5/5] drm: Do not expose HDMI 2.0+ modes to userspace/drivers unless asked to

Hi Daniel, Thanks for the feedback! On 23-03-2017 07:25, Daniel Vetter wrote: > On Wed, Mar 22, 2017 at 05:36:01PM +, Jose Abreu wrote: >> Perform sanity checks so that HDMI 2.0+ modes are not exported to >> drivers or userspace unless asked to. > Why? They're just normal modes, this

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

Hi Andrzej, On 23-03-2017 11:17, Andrzej Hajda wrote: > On 23.03.2017 12:04, Jose Abreu wrote: >> Hi Andrzej, >> >> >> Thanks for the feedback! >> >> On 23-03-2017 08:11, Andrzej Hajda wrote: >>> On 22.03.2017 18:35, Jose Abreu wrote: This patch completes CEA table of video modes so that

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Thu, Mar 23, 2017 at 10:54:53PM +0100, Linus Walleij wrote: > Hm, I certainly want it... but it would be unreasonable of me to expect > Eric to cold-code a big upfront design for systems he can't even test > this on. > > What I would request would rather be: please do not put in any >

[lkp-robot] [drm] f04f7e3e04: general_protection_fault:#[##]

FYI, we noticed the following commit: commit: f04f7e3e041aab12abbf3ed7b854446af5a624a9 ("drm: bochs: Don't remove uninitialized fbdev framebuffer") url: https://github.com/0day-ci/linux/commits/Gabriel-Krisman-Bertazi/drm-bochs-Don-t-remove-uninitialized-fbdev-framebuffer/20170318-164722 base:

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On Thu, Mar 23, 2017 at 1:22 PM, Colin King wrote: > From: Colin Ian King > > info is being checked to see if it is a null pointer, however, vpgu is > dereferencing info before this check, leading to a potential null > pointer dereference. If

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:57 PM, Jose Abreu wrote: >> Hi Ville, >> >> >> On 23-03-2017 15:45, Ville Syrjälä wrote: >>> On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

Hi Ville, On 23-03-2017 15:16, Ville Syrjälä wrote: > On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote: >> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new >> flag which will signal userspace that this is a HDMI 2.0+ mode. It >> is expected that these new flags will

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 15:36, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >> For any other mode, the VIC filed in AVI infoframes should be 0. >> HDMI 2.0 sinks, support

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > extended to (VIC

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 15:14, Shashank Sharma wrote: >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). >>> For any other mode, the VIC

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Shashank, On 23-03-2017 16:43, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:08, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville,

Re: [PATCH v3 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge

On Wed, Mar 22, 2017 at 08:26:07AM -0500, Rob Herring wrote: > Similar to the previous commit, convert drivers open coding OF graph > parsing to use drm_of_find_panel_or_bridge instead. > > This changes some error messages to debug messages (in the graph core). > Graph connections are often "no

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Thu, Mar 23, 2017 at 4:56 PM, Dylan Baker wrote: > Quoting Colin Cross (2017-03-23 15:14:16) >> On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote: >> > On 03/22/2017 02:48 PM, Rob Clark wrote: >> >> >> >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Hi Michel, When it happens, the main thread of our gl based app is stuck on a ioctl(RADEON_CS). I set RADEON_THREAD=false to ease the debugging but same thing happens if true. Other threads are only si_shader:0,1,2,3 and are doing nothing, just waiting for jobs. I can also do sudo gdb -p $(pidof

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

Hi Shashank, On 22-03-2017 18:57, Sharma, Shashank wrote: > Hi Jose, > I can't find the other patches of this series in dri patchwork, am I missing > something ? You can find them now in patchwork (I don't know what happened). > > Also, I am planning to publish a series for YUV 420 handling,

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Hi Ville, On 23-03-2017 17:42, Ville Syrjälä wrote: > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: >> Hi Shashank, >> >> >> On 23-03-2017 16:43, Sharma, Shashank wrote: >>> Regards >>> >>> Shashank >>> >>> >>> On 3/23/2017 6:33 PM, Jose Abreu wrote: Hi Shashank,

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

Hi Andrzej, Thanks for the feedback! On 23-03-2017 08:11, Andrzej Hajda wrote: > On 22.03.2017 18:35, Jose Abreu wrote: >> This patch completes CEA table of video modes so that VIC 1-107 >> are now available. Use the HDMI 2.0+ flag to signal these are >> modes for HDMI 2.0 onwards. >

Re: [RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

Hi Daniel, On 23-03-2017 07:22, Daniel Vetter wrote: > On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote: >> We can't expect userspace to have full support for all HDMI 2.0+ >> features. Instead of expecting/waiting for userspace to support >> the new features add a knob, much like the

Re: [PATCH v4 8/8] ARM: configs: Add STM32 panel simple support in STM32 defconfig

Hi, On 03/15/2017 06:02 PM, Yannick Fertre wrote: Signed-off-by: Yannick Fertre --- Same remarks than patch7 arch/arm/configs/stm32_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/stm32_defconfig b/arch/arm/configs/stm32_defconfig

Re: [PATCH v4 7/8] ARM: configs: Add STM32 LTDC support in STM32 defconfig

Hi On 03/15/2017 06:02 PM, Yannick Fertre wrote: Signed-off-by: Yannick Fertre --- Can you change commit header by:" ARM: config: stm32: Add LTDC support" and can you fill a commit message please ? arch/arm/configs/stm32_defconfig | 1 + 1 file changed, 1

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Quoting Colin Cross (2017-03-23 15:14:16) > On Thu, Mar 23, 2017 at 2:56 PM, Greg Hackmann wrote: > > On 03/22/2017 02:48 PM, Rob Clark wrote: > >> > >> On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote: > >>> > >>> Quoting Rob Clark (2017-03-22

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

https://bugs.freedesktop.org/show_bug.cgi?id=100364 John Brooks changed: What|Removed |Added See Also|

[Bug 90320] Lenovo ThinkPad E455 (Kaveri A10-7300): Blank built-in screen with radeon kms driver

https://bugs.freedesktop.org/show_bug.cgi?id=90320 John Brooks changed: What|Removed |Added See Also|

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

https://bugs.freedesktop.org/show_bug.cgi?id=100364 --- Comment #1 from John Brooks --- Created attachment 130407 --> https://bugs.freedesktop.org/attachment.cgi?id=130407=edit Fix for display not waking -- You are receiving this mail because: You are the

[Bug 100364] DisplayPort hotplug warning and monitor sometimes stays blank

https://bugs.freedesktop.org/show_bug.cgi?id=100364 Bug ID: 100364 Summary: DisplayPort hotplug warning and monitor sometimes stays blank Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 03/22/2017 02:48 PM, Rob Clark wrote: On Wed, Mar 22, 2017 at 4:10 PM, Dylan Baker wrote: Quoting Rob Clark (2017-03-22 10:07:54) I guess an interesting question (from someone who doesn't know meson yet) would be whether meson could slurp in the Makefile.sources type

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Sat, Mar 18, 2017 at 12:09 AM, Russell King - ARM Linux wrote: > On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote: >> This is a modesetting driver for the pl111 CLCD display controller >> found on various ARM platforms such as the Versatile Express. The >>

Re: [PATCH v3 2/2] drm/panel: add innolux,p079zca panel driver

can you add bps here too? On Tue, Mar 21, 2017 at 6:53 PM, Chris Zhong wrote: > Support Innolux P079ZCA 7.85" 768x1024 TFT LCD panel, it is a MIPI DSI > panel. > > Signed-off-by: Chris Zhong > Reviewed-by: Sean Paul > Tested-by:

[Bug 79431] OpenGL OpenCL interop results in corrupted renderbuffer object image

https://bugs.freedesktop.org/show_bug.cgi?id=79431 Jan Vesely changed: What|Removed |Added Resolution|NOTABUG |---

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on|79431 | Referenced Bugs:

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #6 from omegap...@startmail.com --- Ah sorry I was supposed to xrandr it when it broke - will happen again tomorrow I'm sure ;) -- You are receiving this mail because: You are the assignee for the

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #5 from omegap...@startmail.com --- Ah, happened again after leaving it off for ~2 hours... -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

On Thu, Mar 23, 2017 at 06:54:52PM +, Jose Abreu wrote: > Hi Ville, > > > On 23-03-2017 15:16, Ville Syrjälä wrote: > > On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote: > >> Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new > >> flag which will signal userspace

[Bug 100304] [bisected] Kernel oops on startup

https://bugs.freedesktop.org/show_bug.cgi?id=100304 Alex Deucher changed: What|Removed |Added Resolution|--- |FIXED

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 21 March 2017 at 05:00, Jonathan Gray wrote: > On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote: >> >> >> On 21/03/17 06:39, Emil Velikov wrote: >> > On 20 March 2017 at 18:30, Matt Turner wrote: >> > > On Mon, Mar 20, 2017 at 6:55 AM, Emil

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:53:34PM +, Jose Abreu wrote: > Hi Ville, > > > On 23-03-2017 17:42, Ville Syrjälä wrote: > > On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:43, Sharma, Shashank wrote: > >>> Regards > >>> > >>> Shashank

[Bug 100067] [OpenCL] const int in argument list crashes build

https://bugs.freedesktop.org/show_bug.cgi?id=100067 --- Comment #6 from Vedran Miletić --- (In reply to Mig from comment #5) > minimal.cpp compiled with > > gcc -c minimal.cpp -g -o minimal.o > > [miguel@antergos-mig extra]$ gdb > GNU gdb (GDB) 7.12.1 > Copyright (C) 2017

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

Quoting Emil Velikov (2017-03-23 04:39:50) > On 22 March 2017 at 20:10, Dylan Baker wrote: > > The more frustrating part is that atm autotools build is "bug-free" > and with meson will have to go through the same route again :-\ Sure, but if it's easier to get right (which

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:11:44PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 16:43, Sharma, Shashank wrote: > > Regards > > > > Shashank > > > > > > On 3/23/2017 6:33 PM, Jose Abreu wrote: > >> Hi Shashank, > >> > >> > >> On 23-03-2017 16:08, Sharma, Shashank wrote: > >>>

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 06:31:33PM +0200, Sharma, Shashank wrote: > Regards > > Shashank > > > On 3/23/2017 5:52 PM, Jose Abreu wrote: > > Hi Ville, > > > > > > On 23-03-2017 15:36, Ville Syrjälä wrote: > >> On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: > >>> HDMI 1.4b

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

> > No, I've requested reverting the patch for now because it causes an > obviously and rather severe problem. If you guys can quickly find how to > fix it feel free to use that instead. > > My mistake! That makes sense. Thanks again. ___ dri-devel

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 6:33 PM, Jose Abreu wrote: Hi Shashank, On 23-03-2017 16:08, Sharma, Shashank wrote: Regards Shashank On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote:

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:28 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank wrote: On 3/23/2017 5:17 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: HDMI 1.4b support

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:52 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:36, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:57 PM, Jose Abreu wrote: Hi Ville, On 23-03-2017 15:45, Ville Syrjälä wrote: On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: Hi Shashank, On 23-03-2017 15:14, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

Understood -- I thought you might not want to take this patch, but I went ahead and sent it out because Christian requested it, and it seems like he doesn't think VRAM bos should ever evict back to VRAM at all? No, I've requested reverting the patch for now because it causes an obviously and

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

Christian, - Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? - Should we restore PCI configuration if amdgpu will be unloaded? - In function amdgpu_resize_bar0(): If resizing for "max" size failed

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

- Are we going to support resizing BAR when kernel modesetting is not enabled and we are running in console under VBIOS control (VESA/VGA)? No, initial I've tried to resize the PCI BAR during probing without the help of the driver at all. But the VESA/EFI/VBIOS don't seem to be able to handle

[Bug 69728] Radeon Redwood (5670) GPU Lockup

https://bugs.freedesktop.org/show_bug.cgi?id=69728 --- Comment #12 from pablow.1...@gmail.com --- (In reply to Vedran Miletić from comment #11) > Is this still an issue? Hi! I no longer have that video card, so no idea if it's still an issue. -- You are receiving this mail because: You are the

[PULL] drm-misc-fixes

Hi Dave, drm-misc-fixes-2017-03-23: One fbdev regression fix from Michel Cheers, Daniel The following changes since commit 97da3854c526d3a6ee05c849c96e48d21527606c: Linux 4.11-rc3 (2017-03-19 19:09:39 -0700) are available in the git repository at:

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 --- Comment #4 from omegap...@startmail.com --- Just 'Invalid argument' currently. I just did 10 tests turning the monitor off for just over 30 seconds, and on turning it back on, the display layout did not break (but I got the usual flip queue

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 03:28:29PM +, Jose Abreu wrote: > Hi Shashank, > > > On 23-03-2017 15:14, Shashank Sharma wrote: > > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > > For any other mode, the VIC filed in AVI infoframes should be 0. > > HDMI 2.0 sinks,

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 05:14:19PM +0200, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is > extended

Re: [PATCH] Revert "drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first"

> > Was userspace maybe performing concurrent CPU access to the BOs in > question? As far as I know Julien has demonstrated that this is not the case. > I hope we can find a better solution. Understood -- I thought you might not want to take this patch, but I went ahead and sent it out

[Bug 100304] [bisected] Kernel oops on startup

https://bugs.freedesktop.org/show_bug.cgi?id=100304 --- Comment #6 from Mike Lothian --- Thanks, that's working great for me -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 11:22 AM, Sharma, Shashank wrote: > On 3/23/2017 5:17 PM, Ilia Mirkin wrote: >> >> On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma >> wrote: >>> >>> HDMI 1.4b support the CEA video modes as per range of CEA-861-D

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

You guys might wanna use this series, to solve this problem. https://patchwork.freedesktop.org/series/21773/ Patch 1: completes the CEA modes 1-107 Patch 2: Protects HDMI 1.4 monitors from HDMI 2.0 VICs Regards Shashank On 3/23/2017 1:07 PM, Sharma, Shashank wrote: Regards Shashank On

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

Regards Shashank On 3/23/2017 5:17 PM, Ilia Mirkin wrote: On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0

Re: [PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Thu, Mar 23, 2017 at 11:14 AM, Shashank Sharma wrote: > HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). > For any other mode, the VIC filed in AVI infoframes should be 0. > HDMI 2.0 sinks, support video modes range as per CEA-861-F spec,

Re: [RFC 2/5] drm: uapi: Add HDMI 2.0 aspect ratio flags and HDMI 2.0+ mode flag

On Wed, Mar 22, 2017 at 05:35:58PM +, Jose Abreu wrote: > Add the HDMI 2.0 aspect ratio flags (64:27 and 256:135) and a new > flag which will signal userspace that this is a HDMI 2.0+ mode. It > is expected that these new flags will not be exported to userspace > unless client asks to. W.r.t.

[PATCH v4 2/2] drm: Add HDMI 2.0 VIC support for AVI info-frames

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if

[PATCH v4 1/2] drm/edid: Complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65

vsps DT property (was: Re: [PATCH 10/22] drm: rcar-du: Expose the VSP1 compositor through KMS planes)

Hi Laurent, On Mon, Sep 14, 2015 at 12:50 AM, Laurent Pinchart wrote: > Signed-off-by: Laurent Pinchart > --- /dev/null > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c > +int rcar_du_vsp_init(struct

[Bug 100304] [bisected] Kernel oops on startup

https://bugs.freedesktop.org/show_bug.cgi?id=100304 --- Comment #5 from Alex Deucher --- Created attachment 130399 --> https://bugs.freedesktop.org/attachment.cgi?id=130399=edit possible fix This should fix the issue. -- You are receiving this mail because: You are

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

On 23.03.2017 12:35, Jose Abreu wrote: > Hi Andrzej, > > > On 23-03-2017 11:17, Andrzej Hajda wrote: >> On 23.03.2017 12:04, Jose Abreu wrote: >>> Hi Andrzej, >>> >>> >>> Thanks for the feedback! >>> >>> On 23-03-2017 08:11, Andrzej Hajda wrote: On 22.03.2017 18:35, Jose Abreu wrote: >

[PATCH] drm/sti: fix GDP size to support up to UHD resolution

On stih407-410 chip family the GDP layers are able to support up to UHD resolution (3840 x 2160). Signed-off-by: Vincent Abriou --- drivers/gpu/drm/sti/sti_gdp.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/sti/sti_gdp.c

[PATCH 2/2] drm/etnaviv: add lockdep assert to fence allocation

Make sure the GPU lock is taken, so that fence completion order matches seqno order. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c

[PATCH 1/2] drm/etnaviv: (re-)protect fence allocation with GPU mutex

The fence allocation needs to be protected by the GPU mutex, otherwise the fence seqnos of concurrent submits might not match the insertion order of the jobs in the kernel ring. This breaks the assumption that jobs complete with monotonically increasing fence seqnos. Fixes: d9853490176c

Re: [Intel-gfx] [PATCH v3 0/5] drm/i915: SKL+ render decompression support

Hi Ville, On 21 March 2017 at 18:12, wrote: > Another iteration of the i915 CCS support. Main change is lifting the > fb dimensions hsub/vsub alignment restrictions from the core. Without that > userspace would have to align the fb size be a multiple of 8x16

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote: > Hi Michel, > > On 23 March 2017 at 08:53, Michel Dänzer wrote: > > Otherwise this can also prevent modesets e.g. for switching VTs, when > > multiple monitors with different native resolutions are connected. > >

Re: [PATCH] drm: Make the decision to keep vblank irq enabled earlier

On Thu, Mar 23, 2017 at 07:51:06AM +, Chris Wilson wrote: > We want to provide the vblank irq shadow for pageflip events as well as > vblank queries. Such events are completed within the vblank interrupt > handler, and so the current check for disabling the irq will disable it > from with the

Re: [PATCH] drm/scdc: declare drm_scdc_get_scrambling_status

On Wed, 22 Mar 2017, "Sharma, Shashank" wrote: > Thanks for this patch, Jani. > > Reviewed-by: Shashank Sharma And pushed to drm-misc-next, thanks for the review. BR, Jani. > > > Regards > Shashank > On 3/22/2017 4:33 PM, Jani Nikula

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On Thu, Mar 23, 2017 at 11:32:49AM +0100, Thomas Hellstrom wrote: > On 03/23/2017 11:10 AM, Daniel Vetter wrote: > > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote: > >> Hi, Daniel, > >> > >> On 03/23/2017 08:31 AM, Daniel Vetter wrote: > >>> On Thu, Mar 23, 2017 at 08:28:32AM

Re: [PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

On Thu, Mar 23, 2017 at 12:22:30PM +, Colin King wrote: > From: Colin Ian King > > info is being checked to see if it is a null pointer, however, vpgu is > dereferencing info before this check, leading to a potential null > pointer dereference. If info is null,

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Tue, Mar 21, 2017 at 04:00:37PM +1100, Jonathan Gray wrote: > On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote: > > > > > > On 21/03/17 06:39, Emil Velikov wrote: > > > On 20 March 2017 at 18:30, Matt Turner wrote: > > > > On Mon, Mar 20, 2017 at 6:55 AM,

[PATCH] drm/i915/kvmgt: avoid dereferencing a potentially null info pointer

From: Colin Ian King info is being checked to see if it is a null pointer, however, vpgu is dereferencing info before this check, leading to a potential null pointer dereference. If info is null, then the error message being printed by macro gvt_vgpu_err and this

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

Hi Michel, On 23 March 2017 at 08:53, Michel Dänzer wrote: > Otherwise this can also prevent modesets e.g. for switching VTs, when > multiple monitors with different native resolutions are connected. > > The depths must match though, so keep the != test for that. > > Also

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 22 March 2017 at 20:10, Dylan Baker wrote: > On Wed, Mar 22, 2017 at 12:40 PM, Alex Deucher wrote: >> I guess I'm a little late to the party here, but I haven't had time to >> really let all of this sink in and actually look at meson. It doesn't >>

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

On 23.03.2017 12:04, Jose Abreu wrote: > Hi Andrzej, > > > Thanks for the feedback! > > On 23-03-2017 08:11, Andrzej Hajda wrote: >> On 22.03.2017 18:35, Jose Abreu wrote: >>> This patch completes CEA table of video modes so that VIC 1-107 >>> are now available. Use the HDMI 2.0+ flag to signal

Re: [RFC 3/5] drm: edid: Add HDMI 2.0 CEA video modes

Regards Shashank On 3/23/2017 10:11 AM, Andrzej Hajda wrote: On 22.03.2017 18:35, Jose Abreu wrote: This patch completes CEA table of video modes so that VIC 1-107 are now available. Use the HDMI 2.0+ flag to signal these are modes for HDMI 2.0 onwards. edid_cea_modes array is used in

Re: [RFC 1/5] drm: Add HDMI 2.0+ features exposing knob

On Thu, Mar 23, 2017 at 10:44:16AM +, Jose Abreu wrote: > Hi Daniel, > > > On 23-03-2017 07:22, Daniel Vetter wrote: > > On Wed, Mar 22, 2017 at 05:35:57PM +, Jose Abreu wrote: > >> We can't expect userspace to have full support for all HDMI 2.0+ > >> features. Instead of

Re: [RFC 0/5] HDMI 2.0+ video modes handling in DRM core

I realized it was too early to search that in dri-devel last night, I guess it takes some time to sync. Now I can see them all :) On 3/23/2017 12:37 PM, Jose Abreu wrote: Hi Shashank, On 22-03-2017 18:57, Sharma, Shashank wrote: Hi Jose, I can't find the other patches of this series in

Re: [PATCH 06/19] drm/vmwgfx: Drop the cursor locking hack

On 03/23/2017 11:10 AM, Daniel Vetter wrote: > On Thu, Mar 23, 2017 at 09:35:25AM +0100, Thomas Hellstrom wrote: >> Hi, Daniel, >> >> On 03/23/2017 08:31 AM, Daniel Vetter wrote: >>> On Thu, Mar 23, 2017 at 08:28:32AM +0100, Daniel Vetter wrote: On Thu, Mar 23, 2017 at 07:22:31AM +0100,

[PATCH 23/24] drm/msm/mdp5: Reset CTL blend registers before configuring them

Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that isn't used by our CTL instance anymore. Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM instances. The ones that need to be configured are

[PATCH 22/24] drm/msm/mdp5: Assign 'right' mixer to CRTC state

Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's atomic_check path. Assigning the right mixer has some constraints, i.e, only a few LMs can be paired together. Update mdp5_mixer_assign to handle these constraints. Firstly, we need to identify whether we need a right mixer or not.

[PATCH 24/24] drm/msm/mdp5: Enable 3D mux in mdp5_ctl

3D mux is a small block placed after the DSPPs in MDP5. It can merge 2 LM/DSPP outputs and feed it to a single interface. Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check will need to be made more specific later when we add Dual DSI support with source split enabled. In that use

[PATCH 18/24] drm/msm/mdp5: Configure 'right' hwpipe

Now that we have a right hwpipe in mdp5_plane_state, configure it mdp5_plane_mode_set(). The only parameters that vary between the left and right hwpipes are the src_w, src_img_w, src_x and crtc_x as we just even chop the fb into left and right halves. Add a mdp5_plane_right_pipe() which will be

  1   2   >