linux-toradex.git/drivers/gpu, branch v4.9.107

drm/i915: Disable LVDS on Radiant P845

2018-06-06T14:44:38+00:00

commit b3fb22733ae61050f8d10a1d6a8af176c5c5db1a upstream.

Radiant P845 does not have LVDS, only VGA.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105468
Signed-off-by: Ondrej Zary 
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20180309222204.4771-1-linux@rainbow-software.org
(cherry picked from commit 7f7105f99b75aca4f8c2a748ed6b82c7f8be3293)
Signed-off-by: Joonas Lahtinen 
Signed-off-by: Greg Kroah-Hartman

drm/psr: Fix missed entry in PSR setup time table.

2018-06-06T14:44:38+00:00

commit bdcc02cf1bb508fc700df7662f55058f651f2621 upstream.

Entry corresponding to 220 us setup time was missing. I am not aware of
any specific bug this fixes, but this could potentially result in enabling
PSR on a panel with a higher setup time requirement than supported by the
hardware.

I verified the value is present in eDP spec versions 1.3, 1.4 and 1.4a.

Fixes: 6608804b3d7f ("drm/dp: Add drm_dp_psr_setup_time()")
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä 
Cc: Jose Roberto de Souza 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: José Roberto de Souza 
Reviewed-by: Tarun Vyas 
Signed-off-by: Dhinakaran Pandiyan 
Signed-off-by: Jani Nikula 
Link: https://patchwork.freedesktop.org/patch/msgid/20180511195145.3829-3-dhinakaran.pandiyan@intel.com
Signed-off-by: Greg Kroah-Hartman

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