[Bug 196379] Laptop loses performance at random bootups.

https://bugzilla.kernel.org/show_bug.cgi?id=196379 Chen Yu (yu.c.c...@intel.com) changed: What|Removed |Added Status|NEW |NEEDINFO

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #12 from Vedran Miletić --- Interestingly enough, not exactly the same result, amdgpu again: [39371/39371] skip: 3231, pass: 15458, warn: 13, fail: 20668, crash: 1 Then on the next try: [39371/39371] skip:

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

https://bugs.freedesktop.org/show_bug.cgi?id=101739 --- Comment #1 from Roland Scheidegger --- My naive conclusion from the description would be that the hw is doing earlyz optimizations when it shouldn't (so, the depth updates happen before the final sample mask modified by

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #11 from Vedran Miletić --- dmesg with radeon: [ 1443.752932] show_signal_msg: 8 callbacks suppressed [ 1443.752936] glslparsertest[31344]: segfault at 20 ip 7f10f2a45a25 sp 7ffd7c7b4ea0 error 4 in

[Bug 99353] Kaveri 7400K shows random colored noise instead of GUI in X or Wayland

https://bugs.freedesktop.org/show_bug.cgi?id=99353 --- Comment #10 from Vedran Miletić --- Fedora does not enable AMDGPU CIK, but I rebuilt the kernel manually. Same story with Xorg/Wayland with the amdgpu kernel driver. As for piglit, managed to run till the end this time

Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote: > Greetings, > > box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside > kernel: master.today (v4.12-11690-gccd5d1b91f22) > > lspci -nn -d 10de: > 01:00.0 VGA compatible controller [0300]: NVIDIA

Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

On Sat, Jul 15, 2017 at 12:14 PM, Ilia Mirkin wrote: > On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote: >> Greetings, >> >> box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside >> kernel: master.today (v4.12-11690-gccd5d1b91f22)

Re: [drm/nouveau] GeForce 8600 GT boot/suspend grumbling

On Sat, Jul 15, 2017 at 1:40 AM, Mike Galbraith wrote: > Greetings, > > box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside > kernel: master.today (v4.12-11690-gccd5d1b91f22) > > lspci -nn -d 10de: > 01:00.0 VGA compatible controller [0300]: NVIDIA

Re: [PATCH 1/5] drm: radeon: constify pci_device_id.

Am 15.07.2017 um 09:12 schrieb Arvind Yadav: pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex

Re: [PATCH 1/2] drm: Implement vm_operations_struct.access

Am 15.07.2017 um 05:32 schrieb Michel Dänzer: On 15/07/17 04:47 AM, Felix Kuehling wrote: On 17-07-13 11:26 PM, Michel Dänzer wrote: On 14/07/17 06:08 AM, Felix Kuehling wrote: Allows gdb to access contents of user mode mapped BOs. VRAM access requires the driver to implement a new callback

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, 2017-07-14 at 17:10 +0200, Karol Herbst wrote: > Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE > usage we could convert to WARN_ONCE? Shooting the messenger is generally considered uncool :) -Mike ___ dri-devel

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote: > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote: >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula >> wrote: >>> On Thu, 13 Jul 2017, Stéphane Marchesin

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, 2017-07-14 at 14:42 -0500, Josh Poimboeuf wrote: > > Does this fix it? Yup, both READONLY __bug_table and "extra stern" warning are gone. > diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h > index 39e702d..aa6b202 100644 > --- a/arch/x86/include/asm/bug.h > +++

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, 2017-07-14 at 18:10 +0200, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 05:58:18PM +0200, Mike Galbraith wrote: > > On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > > > > Urgh, is for some mysterious reason the __bug_table section of modules > > > ending up in RO memory? > >

[PATCH 4/5] drm: via: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. File size before: textdata bss dec hex filename 4931072 01565 61d

[PATCH] drm: arcpgu: Fix mmap() callback

Now that ARC properly supports DMA mmapping we can use the standard CMA helper to map dumb buffers. This makes ARC PGU works with standard DRM consumer applications like, for example, mpv via DRM. This fixes the use of dumb buffers. Signed-off-by: Jose Abreu Fixes:

[PATCH 3/5] drm: nouveau: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. File size before: textdata bss dec hex filename 12256 360 976 135923518

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

The conversion is a nice catch, but i'd like to have a bit more context, see below! With a better description: Tobias Klausmann On 7/14/17 5:10 PM, Karol Herbst wrote: Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we could

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula wrote: > On Thu, 13 Jul 2017, Stéphane Marchesin wrote: >> So, if you think this is wrong, can you fix this warning in a way that >> you'd like? > > As I replied previously [1], with more

[PATCH 2/5] drm: vmwgfx: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. File size before: textdata bss dec hex filename 13765 800 20 1458538f9

[PATCH 0/5] constify drm pci_device_id

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Arvind Yadav (5): [PATCH 1/5] drm: radeon: constify pci_device_id. [PATCH 2/5] drm: vmwgfx: constify pci_device_id.

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we could convert to WARN_ONCE? Reviewed-By: Karol Herbst On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann wrote: > On 7/14/17 3:41 PM, Mike Galbraith wrote:

[PATCH 1/5] drm: radeon: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. File size before: textdata bss dec hex filename 6560 23212 72 298447494

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, 2017-07-14 at 17:05 +0200, Tobias Klausmann wrote: > On 7/14/17 3:41 PM, Mike Galbraith wrote: > > On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote: > >>  All DRM did was to slip a > >> WARN_ON_ONCE() that nouveau triggers into a kernel module where such > >> things no longer warn,

[PATCH] drm/i915: Consistently use enum pipe for PCH transcoders

The current code uses two different enum types for PCH transcoders and performs implicit conversions between the two types. This is error prone and causes clang to raise warnings like this: drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion from enumeration type 'enum pipe'

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote: >  All DRM did was to slip a > WARN_ON_ONCE() that nouveau triggers into a kernel module where such > things no longer warn, they blow the box out of the water. BTW, turn that irksome WARN_ON_ONCE() in drivers/gpu/drm/drm_vblank.c into a

[PATCH 5/5] drm: hisilicon: constify pci_device_id.

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. File size before: textdata bss dec hex filename 2704 808 03512 db8

[PATCH] drm/vgem: add compat_ioctl support

DRM drivers should supply a compat version if they're going to provide an ioctl implementation at all. This can confuse 32-bit user space on a 64-bit system. Signed-off-by: Brian Norris --- drivers/gpu/drm/vgem/vgem_drv.c | 1 + 1 file changed, 1 insertion(+) diff

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Wed, 2017-07-12 at 07:37 -0400, Ilia Mirkin wrote: > On Wed, Jul 12, 2017 at 7:25 AM, Mike Galbraith wrote: > > On Wed, 2017-07-12 at 11:55 +0200, Mike Galbraith wrote: > >> On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote: > >> > > >> > Some display stuff did change for

[PATCH 0/5] constify drm pci_device_id

pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by work with const pci_device_id. So mark the non-const structs as const. Arvind Yadav (5): [PATCH 1/5] drm: radeon: constify pci_device_id. [PATCH 2/5] drm: vmwgfx: constify pci_device_id.

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On 7/14/17 3:41 PM, Mike Galbraith wrote: On Fri, 2017-07-14 at 15:36 +0200, Mike Galbraith wrote:  All DRM did was to slip a WARN_ON_ONCE() that nouveau triggers into a kernel module where such things no longer warn, they blow the box out of the water. BTW, turn that irksome WARN_ON_ONCE()

Re: [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

On Fri, 2017-07-14 at 17:50 +0200, Peter Zijlstra wrote: > On Fri, Jul 14, 2017 at 03:36:08PM +0200, Mike Galbraith wrote: > > Ok, a network outage gave me time to go hunting.  Indeed it is a bad > > interaction with the tree DRM merged into.  All DRM did was to slip a > > WARN_ON_ONCE() that

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

El Fri, Jul 14, 2017 at 03:43:35PM -0700 Grant Grundler ha dit: > On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote: > > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler > > wrote: > >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula > >>

Re: [PATCH] drm/etnaviv: select CMA and DMA_CMA if available

On Friday, July 14, 2017 7:38:01 AM PDT Lucas Stach wrote: > While this is no build dependency, etnaviv will only work correctly on most > systems if CMA and DMA_CMA are enabled. Select both options if available to > avoid users ending up with a non-working GPU due to a lacking kernel config. > >

[drm/nouveau] GeForce 8600 GT boot/suspend grumbling

Greetings, box: bog standard [tc]rusty old Nvidia equipped Q6600 Medion (Aldi) deskside kernel: master.today (v4.12-11690-gccd5d1b91f22) lspci -nn -d 10de: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G84 [GeForce 8600 GT] [10de:0402] (rev a1) abreviated dmesg: ... [

[PATCH 3/4] tegra-cec: add Tegra HDMI CEC driver

From: Hans Verkuil This driver adds support for the Tegra CEC IP. It is based on the NVIDIA drivers/misc/tegra-cec driver in their 3.10 kernel. This has been converted to the CEC framework and cleaned up. Tested with my Jetson TK1 board. It has also been tested with the

[PATCH 4/4] drm/tegra: add cec-notifier support

From: Hans Verkuil In order to support CEC the HDMI driver has to inform the CEC driver whenever the physical address changes. So when the EDID is read the CEC driver has to be informed and whenever the hotplug detect goes away. This is done through the cec-notifier

[PATCH 2/4] ARM: tegra: add CEC support to tegra124.dtsi

From: Hans Verkuil Add support for the Tegra CEC IP to tegra124.dtsi and enable it on the Jetson TK1. Signed-off-by: Hans Verkuil --- arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 arch/arm/boot/dts/tegra124.dtsi | 12

[PATCH 1/4] dt-bindings: document the tegra CEC bindings

From: Hans Verkuil This documents the binding for the Tegra CEC module. Signed-off-by: Hans Verkuil --- .../devicetree/bindings/media/tegra-cec.txt| 26 ++ 1 file changed, 26 insertions(+) create mode 100644

[PATCH 0/4] tegra-cec: add Tegra HDMI CEC support

From: Hans Verkuil This patch series adds support for the Tegra CEC functionality. It has two prerequisites: this cec-notifier patch: https://patchwork.linuxtv.org/patch/42521/ and this workaround: http://www.spinics.net/lists/dri-devel/msg147038.html A proper fix

Re: [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

On Sat, Jul 15, 2017 at 11:10:07AM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-14 23:46:54) > > @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct > > drm_atomic_state *state, > > struct drm_connector_state *new_conn_state; > > struct

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

Quoting Daniel Vetter (2017-07-15 10:53:28) > For modern drivers the DRM core doesn't use struct_mutex at all, which > means it's defacto a driver-private lock. But since we still need it > for legacy drivers we can't initialize it in drivers, which means all > the different instances share one

[PATCH] drm/rockchip: cdn-dp: send audio infoframe to sink

Some DP/HDMI sink need to receive the audio infoframe to play sound, especially some multi-channel AV receiver, they need the channel_allocation from infoframe to config the speakers. Send the audio infoframe via SDP will make them work properly. Signed-off-by: Chris Zhong

Re: [PATCH, RESEND 02/14] ata: avoid gcc-7 warning in ata_timing_quantize

On Fri, Jul 14, 2017 at 11:25:14AM +0200, Arnd Bergmann wrote: > gcc-7 warns about the result of a constant multiplication used as > a boolean: > > drivers/ata/libata-core.c: In function 'ata_timing_quantize': > drivers/ata/libata-core.c:3164:30: warning: '*' in boolean context, suggest > '&&'

Re: [PATCH 1/3] drm/atomic-helper: Fix leak in disable_all

Quoting Daniel Vetter (2017-07-14 23:46:54) > @@ -2902,6 +2907,8 @@ int drm_atomic_helper_commit_duplicated_state(struct > drm_atomic_state *state, > struct drm_connector_state *new_conn_state; > struct drm_crtc *crtc; > struct drm_crtc_state *new_crtc_state; > +

Re: [Intel-gfx] [PATCH] drm: Don't complain too much about struct_mutex.

Quoting Daniel Vetter (2017-07-15 10:53:28) > For modern drivers the DRM core doesn't use struct_mutex at all, which > means it's defacto a driver-private lock. But since we still need it > for legacy drivers we can't initialize it in drivers, which means all > the different instances share one

[PATCH] drm: Don't complain too much about struct_mutex.

For modern drivers the DRM core doesn't use struct_mutex at all, which means it's defacto a driver-private lock. But since we still need it for legacy drivers we can't initialize it in drivers, which means all the different instances share one lockdep key. Despite that they might be placed in

[PATCH] drm/atomic-helper: Fix leak in disable_all

The legacy plane->fb pointer is refcounted by calling drm_atomic_clean_old_fb(). In practice this isn't a real problem because: - The caller in the i915 gpu reset code restores the original state again, which means the plane->fb pointer won't change, hence can't leak. - Drivers using