linux/drivers/gpu, branch v4.15

Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes

2018-01-26T05:27:07Z

Single irq regression fix * 'linux-4.15' of git://github.com/skeggsb/linux: drm/nouveau: Move irq setup/teardown to pci ctor/dtor

drm/nouveau: Move irq setup/teardown to pci ctor/dtor

2018-01-25T23:44:39Z

For a while we've been having issues with seemingly random interrupts coming from nvidia cards when resuming them. Originally the fix for this was thought to be just re-arming the MSI interrupt registers right after re-allocating our IRQs, however it seems a lot of what we do is both wrong and not even nessecary. This was made apparent by what appeared to be a regression in the mainline kernel that started introducing suspend/resume issues for nouveau: a0c9259dc4e1 (irq/matrix: Spread interrupts on allocation) After this commit was introduced, we started getting interrupts from the GPU before we actually re-allocated our own IRQ (see references below) and assigned the IRQ handler. Investigating this turned out that the problem was not with the commit, but the fact that nouveau even free/allocates it's irqs before and after suspend/resume. For starters: drivers in the linux kernel haven't had to handle freeing/re-allocating their IRQs during suspend/resume cycles for quite a while now. Nouveau seems to be one of the few drivers left that still does this, despite the fact there's no reason we actually need to since disabling interrupts from the device side should be enough, as the kernel is already smart enough to know to disable host-side interrupts for us before going into suspend. Since we were tearing down our IRQs by hand however, that means there was a short period during resume where interrupts could be received before we re-allocated our IRQ which would lead to us getting an unhandled IRQ. Since we never handle said IRQ and re-arm the interrupt registers, this would cause us to miss all of the interrupts from the GPU and cause our init process to start timing out on anything requiring interrupts. So, since this whole setup/teardown every suspend/resume cycle is useless anyway, move irq setup/teardown into the pci subdev's ctor/dtor functions instead so they're only called at driver load and driver unload. This should fix most of the issues with pending interrupts on resume, along with getting suspend/resume for nouveau to work again. As well, this probably means we can also just remove the msi rearm call inside nvkm_pci_init(). But since our main focus here is to fix suspend/resume before 4.15, we'll save that for a later patch. Signed-off-by: Lyude Paul Cc: Karol Herbst Cc: Thomas Gleixner Cc: Mike Galbraith Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs

Merge tag 'drm-misc-fixes-2018-01-24' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

2018-01-25T02:28:15Z

Two vc4 fixes that were applied in the last day. One fixes a NULL dereference, and the other fixes a flickering bug. Cc: Eric Anholt Cc: Boris Brezillon * tag 'drm-misc-fixes-2018-01-24' of git://anongit.freedesktop.org/drm/drm-misc: drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state() drm/vc4: Flush the caches before the bin jobs, as well.

Merge tag 'drm-intel-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

2018-01-19T02:40:07Z

Display corruption regression bugfix with both a prep patch and a follow-up fix * tag 'drm-intel-fixes-2018-01-18' of git://anongit.freedesktop.org/drm/drm-intel: drm/i915: Fix deadlock in i830_disable_pipe() drm/i915: Redo plane sanitation during readout drm/i915: Add .get_hw_state() method for planes

Merge branch 'linux-4.15' of git://github.com/skeggsb/linux into drm-fixes

2018-01-19T02:12:31Z

Thought I'd try my luck getting one more in: - Two fixes for Tegra (one is to common code, but our userspace doesn't hit it). - One for NV5x-class MCPs * 'linux-4.15' of git://github.com/skeggsb/linux: drm/nouveau/mmu/mcp77: fix regressions in stolen memory handling drm/nouveau/bar/gk20a: Avoid bar teardown during init drm/nouveau/drm/nouveau: Pass the proper arguments to nvif_object_map_handle()

drm/nouveau/mmu/mcp77: fix regressions in stolen memory handling

2018-01-19T01:35:44Z

- Fixes addition of stolen memory base address to PTEs. - Removes support for compression. Signed-off-by: Ben Skeggs Tested-by: Pierre Moreau

drm/nouveau/bar/gk20a: Avoid bar teardown during init

2018-01-19T01:35:44Z

Commit bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") introduced add a teardown helper function for BAR1. During initialisation of the Nouveau, initially all the teardown helpers are called once, before calling their init counterparts. For gk20a, after the BAR1 teardown function is called, the device is hanging during the initialisation of the FB sub-device. At this point it is unclear why this is happening and this is still under investigation. However, this change is preventing Tegra124 devices from booting when Nouveau is enabled. To allow Tegra124 to boot, remove the teardown helper for gk20a. This is based upon a previous patch by Guillaume Tucker but limits the workaround to only gk20a GPUs. Fixes: bbb163e18960 ("drm/nouveau/bar: implement bar1 teardown") Reported-by: Guillaume Tucker Signed-off-by: Jon Hunter Signed-off-by: Ben Skeggs

drm/nouveau/drm/nouveau: Pass the proper arguments to nvif_object_map_handle()

2018-01-19T01:35:44Z

This is obviously wrong in the current code. Make sure to record the correct size of the arguments and pass the actual arguments to the nvif_object_map_handle() function. Suggested-by: Ben Skeggs Signed-off-by: Thierry Reding Signed-off-by: Ben Skeggs

drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state()

2018-01-18T20:17:03Z

When saving BOs in the hang state we skip one entry of the kernel_state->bo[] array, thus leaving it to NULL. This leads to a NULL pointer dereference when, later in this function, we iterate over all BOs to check their ->madv state. Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Cc: Signed-off-by: Boris Brezillon Signed-off-by: Eric Anholt Reviewed-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20180118145821.22344-1-boris.brezillon@free-electrons.com

drm/vc4: Flush the caches before the bin jobs, as well.

2018-01-18T20:17:03Z

If the frame samples from a render target that was just written, its cache flush during the binning step may have occurred before the previous frame's RCL was completed. Flush the texture caches again before starting each RCL job to make sure that the sampling of the previous RCL's output is correct. Fixes flickering in the top left of 3DMMES Taiji. Signed-off-by: Eric Anholt Fixes: ca26d28bbaa3 ("drm/vc4: improve throughput by pipelining binning and rendering jobs") Link: https://patchwork.freedesktop.org/patch/msgid/20171221221722.23809-1-eric@anholt.net Reviewed-by: Boris Brezillon