linux-stable.git/drivers/gpu, branch v3.18.133

drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock

2019-01-26T08:44:26+00:00

commit 66a8d5bfb518f9f12d47e1d2dce1732279f9451e upstream.

Strict requirement of pixclock to be zero breaks support of SDL 1.2
which contains hardcoded table of supported video modes with non-zero
pixclock values[1].

To better understand which pixclock values are considered valid and how
driver should handle these values, I briefly examined few existing fbdev
drivers and documentation in Documentation/fb/. And it looks like there
are no strict rules on that and actual behaviour varies:

	* some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
	* some treat (pixclock == 0) as invalid value which leads to
	  -EINVAL (clps711x-fb.c);
	* some pass converted pixclock value to hardware (uvesafb.c);
	* some are trying to find nearest value from predefined table
          (vga16fb.c, video_gx.c).

Given this, I believe that it should be safe to just ignore this value if
changing is not supported. It seems that any portable fbdev application
which was not written only for one specific device working under one
specific kernel version should not rely on any particular behaviour of
pixclock anyway.

However, while enabling SDL1 applications to work out of the box when
there is no /etc/fb.modes with valid settings, this change affects the
video mode choosing logic in SDL. Depending on current screen
resolution, contents of /etc/fb.modes and resolution requested by
application, this may lead to user-visible difference (not always):
image will be displayed in a right way, but it will be aligned to the
left instead of center. There is no "right behaviour" here as well, as
emulated fbdev, opposing to old fbdev drivers, simply ignores any
requsts of video mode changes with resolutions smaller than current.

The easiest way to reproduce this problem is to install sdl-sopwith[2],
remove /etc/fb.modes file if it exists, and then try to run sopwith
from console without X. At least in Fedora 29, sopwith may be simply
installed from standard repositories.

[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
[2] http://sdl-sopwith.sourceforge.net/

Signed-off-by: Ivan Mironov 
Cc: stable@vger.kernel.org
Fixes: 79e539453b34e ("DRM: i915: add mode setting support")
Fixes: 771fe6b912fca ("drm/radeon: introduce kernel modesetting for radeon hardware")
Fixes: 785b93ef8c309 ("drm/kms: move driver specific fb common code to helper functions (v2)")
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20190108072353.28078-3-mironov.ivan@gmail.com
Signed-off-by: Greg Kroah-Hartman

drm/ast: fixed reading monitor EDID not stable issue

2018-12-17T09:07:11+00:00

[ Upstream commit 300625620314194d9e6d4f6dda71f2dc9cf62d9f ]

v1: over-sample data to increase the stability with some specific monitors
v2: refine to avoid infinite loop
v3: remove un-necessary "volatile" declaration

[airlied: fix two checkpatch warnings]

Signed-off-by: Y.C. Chen 
Signed-off-by: Dave Airlie 
Link: https://patchwork.freedesktop.org/patch/msgid/1542858988-1127-1-git-send-email-yc_chen@aspeedtech.com
Signed-off-by: Sasha Levin

drm/ast: Fix incorrect free on ioregs

2018-12-13T08:22:29+00:00

commit dc25ab067645eabd037f1a23d49a666f9e0b8c68 upstream.

If the platform has no IO space, ioregs is placed next to the already
allocated regs. In this case, it should not be separately freed.

This prevents a kernel warning from __vunmap "Trying to vfree()
nonexistent vm area" when unloading the driver.

Fixes: 0dd68309b9c5 ("drm/ast: Try to use MMIO registers when PIO isn't supported")

Signed-off-by: Sam Bobroff 
Cc: 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm: gma500: fix logic error

2018-12-13T08:22:29+00:00

commit 67a3b63a54cbe18944191f43d644686731cf30c7 upstream.

gcc-8 points out a condition that almost certainly doesn't
do what the author had in mind:

drivers/gpu/drm/gma500/mdfld_intel_display.c: In function 'mdfldWaitForPipeEnable':
drivers/gpu/drm/gma500/mdfld_intel_display.c:102:37: error: bitwise comparison always evaluates to false [-Werror=tautological-compare]

This changes it to a simple bit mask operation to check
whether the bit is set.

Fixes: 026abc333205 ("gma500: initial medfield merge")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20170905074741.435324-1-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman

drm/ast: Remove existing framebuffers before loading driver

2018-12-01T08:48:05+00:00

commit 5478ad10e7850ce3d8b7056db05ddfa3c9ddad9a upstream.

If vesafb attaches to the AST device, it configures the framebuffer memory
for uncached access by default. When ast.ko later tries to attach itself to
the device, it wants to use write-combining on the framebuffer memory, but
vesefb's existing configuration for uncached access takes precedence. This
results in reduced performance.

Removing the framebuffer's configuration before loding the AST driver fixes
the problem. Other DRM drivers already contain equivalent code.

Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963
Signed-off-by: Thomas Zimmermann 
Cc: 
Tested-by: Y.C. Chen 
Reviewed-by: Jean Delvare 
Tested-by: Jean Delvare 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ast: change resolution may cause screen blurred

2018-12-01T08:47:59+00:00

commit 1a37bd823891568f8721989aed0615835632d81a upstream.

The value of pitches is not correct while calling mode_set.
The issue we found so far on following system:
- Debian8 with XFCE Desktop
- Ubuntu with KDE Desktop
- SUSE15 with KDE Desktop

Signed-off-by: Y.C. Chen 
Cc: 
Tested-by: Jean Delvare 
Reviewed-by: Jean Delvare 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/ast: fixed cursor may disappear sometimes

2018-12-01T08:47:59+00:00

commit 7989b9ee8bafe5cc625381dd0c3c4586de27ca26 upstream.

Signed-off-by: Y.C. Chen 
Cc: 
Reviewed-by: Dave Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

Revert "Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES""

2018-11-27T15:05:37+00:00

This reverts commit bc07ee33284ac6e6872d5efad1b321ec0b7b46a4. Which is
upstream commit a50940510e94f5fb65ffd79877a60592d85598a9.

This revert relies on upstream commit a63b03e2d24 ("mutex: Always clear
owner field upon mutex_unlock()") being in the tree, but that commit
should not be backported.

Signed-off-by: Sasha Levin

drm/omap: fix memory barrier bug in DMM driver

2018-11-22T06:32:46+00:00

[ Upstream commit 538f66ba204944470a653a4cccc5f8befdf97c22 ]

A DMM timeout "timed out waiting for done" has been observed on DRA7
devices. The timeout happens rarely, and only when the system is under
heavy load.

Debugging showed that the timeout can be made to happen much more
frequently by optimizing the DMM driver, so that there's almost no code
between writing the last DMM descriptors to RAM, and writing to DMM
register which starts the DMM transaction.

The current theory is that a wmb() does not properly ensure that the
data written to RAM is observable by all the components in the system.

This DMM timeout has caused interesting (and rare) bugs as the error
handling was not functioning properly (the error handling has been fixed
in previous commits):

 * If a DMM timeout happened when a GEM buffer was being pinned for
   display on the screen, a timeout error would be shown, but the driver
   would continue programming DSS HW with broken buffer, leading to
   SYNCLOST floods and possible crashes.

 * If a DMM timeout happened when other user (say, video decoder) was
   pinning a GEM buffer, a timeout would be shown but if the user
   handled the error properly, no other issues followed.

 * If a DMM timeout happened when a GEM buffer was being released, the
   driver does not even notice the error, leading to crashes or hang
   later.

This patch adds wmb() and readl() calls after the last bit is written to
RAM, which should ensure that the execution proceeds only after the data
is actually in RAM, and thus observable by DMM.

The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.

Signed-off-by: Tomi Valkeinen 
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"

2018-11-10T15:39:13+00:00

[ Upstream commit a50940510e94f5fb65ffd79877a60592d85598a9 ]

The core fix was applied in

commit a63b03e2d2477586440741677ecac45bcf28d7b1
Author: Chris Wilson 
Date:   Tue Jan 6 10:29:35 2015 +0000

    mutex: Always clear owner field upon mutex_unlock()

(note the absence of stable@ tag)

so we can now revert our band-aid commit 226e5ae9e5f910 for -next.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Daniel Vetter 
Signed-off-by: Sasha Levin