kernel/linux.git/drivers/gpu, branch v4.9.104

drm/rockchip: Respect page offset for PRIME mmap calls

2018-05-30T05:50:50+00:00

[ Upstream commit 57de50af162b67612da99207b061ade3239e57db ] When mapping external DMA-bufs through the PRIME mmap call, we might be given an offset which has to be respected. However for the internal DRM GEM mmap path, we have to ignore the fake mmap offset used to identify the buffer only. Currently the code always zeroes out vma->vm_pgoff, which breaks the former. This patch fixes the problem by moving the vm_pgoff assignment to a function that is used only for GEM mmap path, so that the PRIME path retains the original offset. Cc: Daniel Kurtz Signed-off-by: Ørjan Eide Signed-off-by: Tomasz Figa Signed-off-by: Sean Paul Signed-off-by: Thierry Escande Tested-by: Heiko Stuebner Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20180130202913.28724-4-thierry.escande@collabora.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/panel: simple: Fix the bus format for the Ontat panel

2018-05-30T05:50:46+00:00

[ Upstream commit 5651e5e094591f479adad5830ac1bc45196a39b3 ] This fixes bad color output. When I was first testing the device I had the DPI hardware set to 666 mode, but apparently in the refactor to use the bus_format information from the panel driver, I failed to actually update the panel. Signed-off-by: Eric Anholt Fixes: e8b6f561b2ee ("drm/panel: simple: Add the 7" DPI panel from Adafruit") Cc: Thierry Reding Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20180309233332.1769-1-eric@anholt.net Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/imx: move arming of the vblank event to atomic_flush

2018-05-30T05:50:37+00:00

[ Upstream commit 6a055b92de15af987b4027826d43aa103c65a3c4 ] Right now the vblank event completion is racing with the atomic update, which is especially bad when the PRE is in use, as one of the hardware issue workaround might extend the atomic commit for quite some time. If the vblank IRQ happens to trigger during that time, we will prematurely signal the atomic commit completion to userspace, which causes tearing when userspace re-uses a framebuffer we haven't managed to flip away from yet. Signed-off-by: Lucas Stach Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/sun4i: Fix dclk_set_phase

2018-05-30T05:50:33+00:00

[ Upstream commit e64b6afa98f3629d0c0c46233bbdbe8acdb56f06 ] Phase value is not shifted before writing. Shift left of 28 bits to fit right bits Signed-off-by: Giulio Benetti Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/1519836413-35023-1-git-send-email-giulio.benetti@micronovasrl.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

virtio-gpu: fix ioctl and expose the fixed status to userspace.

2018-05-30T05:50:32+00:00

[ Upstream commit 9a191b114906457c4b2494c474f58ae4142d4e67 ] This exposes to mesa that it can use the fixed ioctl for querying later cap sets, cap set 1 is forever frozen in time. Signed-off-by: Dave Airlie Link: http://patchwork.freedesktop.org/patch/msgid/20180221015003.22884-1-airlied@gmail.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/exynos: fix comparison to bitshift when dealing with a mask

2018-05-30T05:50:28+00:00

[ Upstream commit 1293b6191010672c0c9dacae8f71c6f3e4d70cbe ] Due to a typo, the mask was destroyed by a comparison instead of a bit shift. Signed-off-by: Wolfram Sang Signed-off-by: Inki Dae Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/exynos: g2d: use monotonic timestamps

2018-05-30T05:50:28+00:00

[ Upstream commit a588a8bb7b25a3fb4f7fed00feb7aec541fc2632 ] The exynos DRM driver uses real-time 'struct timeval' values for exporting its timestamps to user space. This has multiple problems: 1. signed seconds overflow in y2038 2. the 'struct timeval' definition is deprecated in the kernel 3. time may jump or go backwards after a 'settimeofday()' syscall 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they can't be compared 5. exporting microseconds requires a division by 1000, which may be slow on some architectures. The code existed in two places before, but the IPP portion was removed in 8ded59413ccc ("drm/exynos: ipp: Remove Exynos DRM IPP subsystem"), so we no longer need to worry about it. Ideally timestamps should just use 64-bit nanoseconds instead, but of course we can't change that now. Instead, this tries to address the first four points above by using monotonic 'timespec' values. According to Tobias Jakobi, user space doesn't care about the timestamp at the moment, so we can change the format. Even if there is something looking at them, it will work just fine with monotonic times as long as the application only looks at the relative values between two events. Link: https://patchwork.kernel.org/patch/10038593/ Cc: Tobias Jakobi Signed-off-by: Arnd Bergmann Reviewed-by: Tobias Jakobi Signed-off-by: Inki Dae Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/nouveau/pmu/fuc: don't use movw directly anymore

2018-05-30T05:50:24+00:00

[ Upstream commit fe9748b7b41cee11f8db57fb8b20bc540a33102a ] Fixes failure to compile with recent envyas as a result of the 'movw' alias being removed for v5. A bit of history: v3 only has a 16-bit sign-extended immediate mov op. In order to set the high bits, there's a separate 'sethi' op. envyas validates that the value passed to mov(imm) is between -0x8000 and 0x7fff. In order to simplify macros that load both the low and high word, a 'movw' alias was added which takes an unsigned 16-bit immediate. However the actual hardware op still sign extends. v5 has a full 32-bit immediate mov op. The v3 16-bit immediate mov op is gone (loads 0 into the dst reg). However due to a bug in envyas, the movw alias still existed, and selected the no-longer-present v3 16-bit immediate mov op. As a result usage of movw on v5 is the same as mov with a 0x0 argument. The proper fix throughout is to only ever use the 'movw' alias in combination with 'sethi'. Anything else should get the sign-extended validation to ensure that the intended value ends up in the destination register. Changes in fuc3 binaries is the result of a different encoding being selected for a mov with an 8-bit value. v2: added commit message written by Ilia, thanks for that! v3: messed up rebasing, now it should apply Signed-off-by: Karol Herbst Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros

2018-05-30T05:50:17+00:00

commit 938ae7259c908ad031da35d551da297640bb640c upstream. Depending on whether the kernel is compiled with frame-pointer or not, the temporary memory location used for the bp parameter in these macros is referenced relative to the stack pointer or the frame pointer. Hence we can never reference that parameter when we've modified either the stack pointer or the frame pointer, because then the compiler would generate an incorrect stack reference. Fix this by pushing the temporary memory parameter on a known location on the stack before modifying the stack- and frame pointers. Cc: Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul Reviewed-by: Sinclair Yeh Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix drm:intel_enable_lvds ERROR message in kernel log

2018-05-16T08:08:43+00:00

commit e8f48f96db7e482995743f461b3e8a5c1a102533 upstream. Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to power on` in kernel log at boot time. Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power on its screen during Intel i915 DRM initialization. This currently results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to power on` message appearing in the kernel log during boot time and when stopping the machine. This change increases the timeout of the `intel_enable_lvds` function from 1 to 5 seconds, letting enough time for the Satellite 930 LCD screen to power on, and suppressing the error message from the kernel log. This patch has been successfully tested on Linux 4.14 running on a Toshiba Satellite Z930. [vsyrjala: bump the timeout from 2 to 5 seconds to match the DP code and properly cover the max hw timeout of ~4 seconds, and drop the comment about the specific machine since this is not a particulary surprising issue, nor specific to that one machine] Signed-off-by: Florent Flament Cc: stable@vger.kernel.org Cc: Pavel Petrovic Cc: Sérgio M. Basto Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414 References: https://bugzilla.kernel.org/show_bug.cgi?id=57591 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula (cherry picked from commit 280b54ade5914d3b4abe4f0ebe083ddbd4603246) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman