linux-toradex.git/drivers/gpu/drm, branch v4.9.34

drm/vc4: Fix OOPSes from trying to cache a partially constructed BO.

2017-06-24T05:11:14+00:00

commit ca39b449f6d03e8235969f12f5dd25b8eb4304d6 upstream.

If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache.  If we then reused it before it expired from the cache,
the kernel would OOPS.

Signed-off-by: Eric Anholt 
Fixes: c826a6e10644 ("drm/vc4: Add a BO cache.")
Reviewed-by: Boris Brezillon 
Link: http://patchwork.freedesktop.org/patch/msgid/20170301185602.6873-2-eric@anholt.net
Signed-off-by: Greg Kroah-Hartman

drm/mediatek: fix mtk_hdmi_setup_vendor_specific_infoframe mistake

2017-06-24T05:11:14+00:00

commit 014580ffab654bb83256783a2b185cf6c06dffaa upstream.

mtk_hdmi_setup_vendor_specific_infoframe will return before handle
mtk_hdmi_hw_send_info_frame.Because hdmi_vendor_infoframe_pack
returns the number of bytes packed into the binary buffer or
a negative error code on failure.
So correct it.

Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Signed-off-by: Nickey Yang 
Signed-off-by: CK Hu 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Fix GVT-g PVINFO version compatibility check

2017-06-24T05:11:13+00:00

commit c380f681245d7ae57f17d9ebbbe8f8f1557ee1fb upstream.

Current it's strictly checked if PVINFO version matches 1.0
for GVT-g i915 guest which doesn't help for compatibility at
all and forces GVT-g host can't extend PVINFO easily with version
bump for real compatibility check.

This fixes that to check minimal required PVINFO version instead.

v2:
- drop unneeded version macro
- use only major version for sanity check

v3:
- fix up PVInfo value with kernel type
- one indent fix

Reviewed-by: Joonas Lahtinen 
Cc: Chuanxiao Dong 
Cc: Joonas Lahtinen 
Signed-off-by: Zhenyu Wang 
Signed-off-by: Joonas Lahtinen 
Link: http://patchwork.freedesktop.org/patch/msgid/20170609074805.5101-1-zhenyuw@linux.intel.com
(cherry picked from commit 0c8792d00d38de85b6ceb1dd67d3ee009d7c8e42)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Fix overflow of watermark calcs at > 4k resolutions.

2017-06-24T05:11:13+00:00

commit bea10413934dcf98cb9b2dfcdc56e1d28f192897 upstream.

Commit d63c277dc672e0
("drm/amdgpu: Make display watermark calculations more accurate")
made watermark calculations more accurate, but not for > 4k
resolutions on 32-Bit architectures, as it introduced an integer
overflow for those setups and resolutions.

Fix this by proper u64 casting and division.

Signed-off-by: Mario Kleiner 
Reported-by: Ben Hutchings 
Fixes: d63c277dc672 ("drm/amdgpu: Make display watermark calculations more accurate")
Cc: Ben Hutchings 
Cc: Alex Deucher 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Always recompute watermarks when distrust_bios_wm is set, v2.

2017-06-17T04:41:58+00:00

commit 4e3aed844547f63614363a386de126e6304e55fb upstream.

On some systems there can be a race condition in which no crtc state is
added to the first atomic commit. This results in all crtc's having a
null DDB allocation, causing a FIFO underrun on any update until the
first modeset.

Changes since v1:
- Do not take the connection_mutex, this is already done below.

Reported-by: Maarten Lankhorst 
Inspired-by: Mahesh Kumar 
Signed-off-by: Maarten Lankhorst 
Fixes: 98d39494d375 ("drm/i915/gen9: Compute DDB allocation at atomic
check time (v4)")
Cc: Mahesh Kumar 
Cc: Matt Roper 
Link: http://patchwork.freedesktop.org/patch/msgid/20170531154236.27180-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Mahesh Kumar 
Reviewed-by: Matt Roper 
Signed-off-by: Greg Kroah-Hartman 

(cherry picked from commit 367d73d2806085bb507ab44c1f532640917fd5ca)
Signed-off-by: Jani Nikula

drm/i915: Workaround VLV/CHV DSI scanline counter hardware fail

2017-06-17T04:41:58+00:00

commit 8f4d38099b3098eae75f7755e1801931f8141350 upstream.

The scanline counter is bonkers on VLV/CHV DSI. The scanline counter
increment is not lined up with the start of vblank like it is on
every other platform and output type. This causes problems for
both the vblank timestamping and atomic update vblank evasion.

On my FFRD8 machine at least, the scanline counter increment
happens about 1/3 of a scanline ahead of the start of vblank (which
is where all register latching happens still). That means we can't
trust the scanline counter to tell us whether we're in vblank or not
while we're on that particular line. In order to keep vblank
timestamping in working condition when called from the vblank irq,
we'll leave scanline_offset at one, which means that the entire
line containing the start of vblank is considered to be inside
the vblank.

For the vblank evasion we'll need to consider that entire line
to be bad, since we can't tell whether the registers already
got latched or not. And we can't actually use the start of vblank
interrupt to get us past that line as the interrupt would fire
too soon, and then we'd up waiting for the next start of vblank
instead. One way around that would using the frame start
interrupt instead since that wouldn't fire until the next
scanline, but that would require some bigger changes in the
interrupt code. So for simplicity we'll just poll until we get
past the bad line.

v2: Adjust the comments a bit

Cc: Jonas Aaberg 
Tested-by: Jonas Aaberg 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99086
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/20161215174734.28779-1-ville.syrjala@linux.intel.com
Tested-by: Mika Kahola 
Reviewed-by: Mika Kahola 
(cherry picked from commit ec1b4ee2834e66884e5b0d3d465f347ff212e372)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/ast: Fixed system hanged if disable P2A

2017-06-17T04:41:54+00:00

[ Upstream commit 6c971c09f38704513c426ba6515f22fb3d6c87d5 ]

The original ast driver will access some BMC configuration through P2A bridge
that can be disabled since AST2300 and after.
It will cause system hanged if P2A bridge is disabled.
Here is the update to fix it.

Signed-off-by: Y.C. Chen 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Fix drm poll_helper handling

2017-06-17T04:41:54+00:00

[ Upstream commit 9a2eba337cacefc95b97c2726e3efdd435b3460e ]

Commit cae9ff036eea effectively disabled the drm poll_helper by checking
the wrong flag to see if the driver should enable the poll or not:
mode_config.poll_enabled is only set to true by poll_init and it is not
indicating if the poll is enabled or not.
nouveau_display_create() will initialize the poll and going to disable it
right away. After poll_init() the mode_config.poll_enabled will be true,
but the poll itself is disabled.

To avoid the race caused by calling the poll_enable() from different paths,
this patch will enable the poll from one place, in the
nouveau_display_hpd_work().

In case the pm_runtime is disabled we will enable the poll in
nouveau_drm_load() once.

Fixes: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on runtime resume")
Signed-off-by: Peter Ujfalusi 
Reviewed-by: Lyude 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Don't enabling polling twice on runtime resume

2017-06-17T04:41:54+00:00

[ Upstream commit cae9ff036eea577856d5b12860b4c79c5e71db4a ]

As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.

This fixes hangs observed on the ThinkPad W541

Signed-off-by: Lyude 
Cc: Hans de Goede 
Cc: Kilian Singer 
Cc: Lukas Wunner 
Cc: David Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau: Handle fbcon suspend/resume in seperate worker

2017-06-17T04:41:54+00:00

[ Upstream commit 15266ae38fe09dae07bd8812cb7a7717b1e1d992 ]

Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.

This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:

 - Get a machine with both optimus and a nvidia card with connectors
   attached to it
 - Wait for the nvidia GPU to suspend
 - Attempt to manually reprobe any of the connectors on the nvidia GPU
   using sysfs
 - *deadlock*

[airlied: use READ_ONCE to address Hans's comment]

Signed-off-by: Lyude 
Cc: Hans de Goede 
Cc: Kilian Singer 
Cc: Lukas Wunner 
Cc: David Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman