commit c2d311553855395764e2e5bf401d987ba65c2056 upstream.

When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing
'old_mode' in favor of using par->set_mode directly fixes the problem.

Cc: <stable@vger.kernel.org>
Fixes: a278724a ("drm/vmwgfx: Implement fbdev on kms v2")
Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It makes more sense to have all the buffer object related code in
a single file rather than splitting it up between the resource code
and buffer object pinning utilities.

Place all buffer object related code in vmwgfx_bo.c. Fix up headers
and export resource functionality when needed in the buffer object
code.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

Initially vmware buffer objects were only used as DMA buffers, so the name
DMA buffer was a natural one. However, currently they are used also as
dumb buffers and MOBs backing guest backed objects so renaming them to
buffer objects is logical. Particularly since there is a dmabuf subsystem
in the kernel where a dma buffer means something completely different.

This also renames user-space api structures and IOCTL names
correspondingly, but the old names remain defined for now and the ABI
hasn't changed.

There are a couple of minor style changes to make checkpatch happy.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

plane->fb/old_fb/crtc should no longer be used by atomic
drivers. Stop messing about with them.

Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-7-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

We have had problems displaying fbdev after a resume and as a
workaround we have had to call vmw_fb_refresh(). This has had
a number of unwanted side-effects. The root of the problem was,
however that the coalesced fbdev dirty region was not empty on
the first dirty_mark() after a resume, so a flush was never
scheduled.

Fix this by force scheduling an fbdev flush after resume, and
remove the workaround.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

At least since the atomic port, the vmwgfx fbdev code is taking
a number of unnecessary modeset locks. In particular the
kms_set_config() function will grab its own locks, leading to
locking retries. So avoid drm_modeset_lock_all() and instead
provide a local acquire context for kms_set_config(). Also have the
vmw_kms_fbdev_init data itself grab the lock that it needs.

This also fixed a long standing problem that vmw_fb_close() didn't
provide an acquire context for kms_set_config(), causing potential
warnings and hangs during driver unload. This problem was uncovered by the
recent commit "drm/vmwgfx: Improve on hibernation"

Testing done:
Repeated driver load and unload on Ubuntu 16.04.2

Fixes: c3b9b165 ("drm/vmwgfx: Improve on hibernation")
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

It was used to early block fbdev dirty processing. Replace it with an
unprotected check of the par->dirty.active field. While this might
race with the vmw_fb_off() function, we do a protected check later so
the race will at worst lead to grabbing and releasing a couple of locks.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Make it possible to hibernate also with masters that don't switch VT at
hibernation time. We save and restore modesetting state unless fbdev is
active and enabled at hibernation time.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

fbdev framebuffers were previously pinned to be able to keep them mapped
across updates.

This commit introduces a mechanism that instead revalidates the map on
each update, keeping the map cached across updates. The cached map is torn
down if the underlying pages change. Typically on buffer object moves and
swapouts.

This should be nicer to the system when we have resource contention.

Testing done: Basic fbdev functionality under Fedora 27.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>

This patch replace instances of drm_framebuffer_unreference with _put()
suffix, because it is shorter and consistent with the kernel use of
*_get/put() suffixes.
This was done with the following Coccinelle script:

@r@
expression e;
@@

(
-drm_framebuffer_reference(e);
+drm_framebuffer_get(e);
|
-drm_framebuffer_unreference(e);
+drm_framebuffer_put(e);
)
Signed-off-by: NHaneen Mohammed <hamohammed.sa@gmail.com>
Acked-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180311233313.GA19721@Haneen

- FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed&removed
  the entire panic handling code in our fbdev emulation. We might
  restore kms panic output, but not through the bazillion of legacy
  code layers called fbdev/fbcon, there's just no way to make that
  work safely.

- With the module check change FBINFO_DEFAULT is always 0, so can be
  removed too.

That removes another change to cargo-cult stuff in kms drivers, yay!
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170706125735.28299-5-daniel.vetter@ffwll.chSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I've broken this by removing the backoff handling from the
set_config2atomic helper in

commit 38b6441e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 22 22:50:58 2017 +0100

    drm/atomic-helper: Remove the backoff hack from set_config

Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to look into refactoring the
entire code to use the helpers, but since that's not a viable
long-term solution fix the issue by open-coding a vmwgfx version of
set_config, that does the legacy backoff dance internally.

Note: Just compile-tested. The idea is to take
drm_mode_set_config_internal(), remove the "is this a legacy driver"
check, and whack the drm_atomic_legacy_backoff trickery at the end.
Since drm_atomic_legacy_backoff is for atomic commits only we need to
open-code it.

Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406200256.26040-1-daniel.vetter@ffwll.ch

Pinning fbdev's FB at the start of VRAM prevents X from pinning
its FB.  Since for ldu, the fb would be pinned anyway during a
mode set, just skip pinning it in fbdev.

This is not the best solution, but since ldu is not used much
anymore, it seems like a reasonable workaround.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

1.  When unsetting a mode, num_connector should be set to zero
2.  The pixel_format field needs to be initialized as newer DRM internal
    functions checks this field
3.  Take the drm_modeset_lock_all() because vmw_fb_kms_detach() can
    change current mode
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Currently the pitch is passed in as depth.  This causes
drm_mode_legacy_fb_format() to return the wrong pixel format.

The wrong pixel format will be rejected by vmw_kms_new_framebuffer(),
thus leaving par->set_fb to NULL.

This eventually causes a crash in vmw_fb_setcolreg() when the code
tries to dereference par->set_fb.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Currently the pitch is passed in as depth.  This causes
drm_mode_legacy_fb_format() to return the wrong pixel format.

The wrong pixel format will be rejected by vmw_kms_new_framebuffer(),
thus leaving par->set_fb to NULL.

This eventually causes a crash in vmw_fb_setcolreg() when the code
tries to dereference par->set_fb.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Replace uses of fb->pixel_format with fb->format->format.
Less duplicated information is a good thing.

Note that coccinelle failed to eliminate the
"/* fourcc format */" comment from drm_framebuffer.h, so I had
to do that part manually.

@@
struct drm_framebuffer *FB;
expression E;
@@
 drm_helper_mode_fill_fb_struct(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 i9xx_get_initial_plane_config(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 ironlake_get_initial_plane_config(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 skylake_get_initial_plane_config(...) {
	...
-	FB->pixel_format = E;
	...
 }

@@
struct drm_framebuffer *a;
struct drm_framebuffer b;
@@
(
- a->pixel_format
+ a->format->format
|
- b.pixel_format
+ b.format->format
)

@@
struct drm_plane_state *a;
struct drm_plane_state b;
@@
(
- a->fb->pixel_format
+ a->fb->format->format
|
- b.fb->pixel_format
+ b.fb->format->format
)

@@
struct drm_crtc *CRTC;
@@
(
- CRTC->primary->fb->pixel_format
+ CRTC->primary->fb->format->format
|
- CRTC->primary->state->fb->pixel_format
+ CRTC->primary->state->fb->format->format
)

@@
struct drm_mode_set *set;
@@
(
- set->fb->pixel_format
+ set->fb->format->format
|
- set->crtc->primary->fb->pixel_format
+ set->crtc->primary->fb->format->format
)

@@
@@
 struct drm_framebuffer {
	 ...
-	 uint32_t pixel_format;
	 ...
 };

v2: Fix commit message (Laurent)
    Rebase due to earlier removal of many fb->pixel_format uses,
    including the 'fb->format = drm_format_info(fb->format->format);'
    snafu
v3: Adjusted the semantic patch a bit and regenerated due to code
    changes

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481751175-18463-1-git-send-email-ville.syrjala@linux.intel.com

Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8.
Less duplicated information is a good thing.

Note that I didn't put parens around the cpp*8 in the below cocci script,
on account of not wanting spurious parens all over the place. Instead I
did the unsafe way, and tried to look over the entire diff to spot if
any dangerous expressions were produced. I didn't see any.

There are some cases where previously the code did X*bpp/8, so the
division happened after the multiplication. Those are now just X*cpp
so the division effectively happens before the multiplication,
but that is perfectly fine since bpp is always a multiple of 8.

@@
struct drm_framebuffer *FB;
expression E;
@@
 drm_helper_mode_fill_fb_struct(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 i9xx_get_initial_plane_config(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 ironlake_get_initial_plane_config(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer *FB;
expression E;
@@
 skylake_get_initial_plane_config(...) {
	...
-	FB->bits_per_pixel = E;
	...
 }

@@
struct drm_framebuffer FB;
expression E;
@@
(
- E * FB.bits_per_pixel / 8
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel / 8
+ FB.format->cpp[0]
|
- E * FB.bits_per_pixel >> 3
+ E * FB.format->cpp[0]
|
- FB.bits_per_pixel >> 3
+ FB.format->cpp[0]
|
- (FB.bits_per_pixel + 7) / 8
+ FB.format->cpp[0]
|
- FB.bits_per_pixel
+ FB.format->cpp[0] * 8
|
- FB.format->cpp[0] * 8 != 8
+ FB.format->cpp[0] != 1
)

@@
struct drm_framebuffer *FB;
expression E;
@@
(
- E * FB->bits_per_pixel / 8
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel / 8
+ FB->format->cpp[0]
|
- E * FB->bits_per_pixel >> 3
+ E * FB->format->cpp[0]
|
- FB->bits_per_pixel >> 3
+ FB->format->cpp[0]
|
- (FB->bits_per_pixel + 7) / 8
+ FB->format->cpp[0]
|
- FB->bits_per_pixel
+ FB->format->cpp[0] * 8
|
- FB->format->cpp[0] * 8 != 8
+ FB->format->cpp[0] != 1
)

@@
struct drm_plane_state *state;
expression E;
@@
(
- E * state->fb->bits_per_pixel / 8
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel / 8
+ state->fb->format->cpp[0]
|
- E * state->fb->bits_per_pixel >> 3
+ E * state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel >> 3
+ state->fb->format->cpp[0]
|
- (state->fb->bits_per_pixel + 7) / 8
+ state->fb->format->cpp[0]
|
- state->fb->bits_per_pixel
+ state->fb->format->cpp[0] * 8
|
- state->fb->format->cpp[0] * 8 != 8
+ state->fb->format->cpp[0] != 1
)

@@
@@
- (8 * 8)
+ 8 * 8

@@
struct drm_framebuffer FB;
@@
- (FB.format->cpp[0])
+ FB.format->cpp[0]

@@
struct drm_framebuffer *FB;
@@
- (FB->format->cpp[0])
+ FB->format->cpp[0]

@@
@@
 struct drm_framebuffer {
	 ...
-	 int bits_per_pixel;
	 ...
 };

v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent)
v3: Adjusted the semantic patch a bit and regenerated due to code
    changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1481751140-18352-1-git-send-email-ville.syrjala@linux.intel.com

Replace uses of fb->depth with fb->format->depth. Less duplicate
information is a good thing.

@@
struct drm_framebuffer *fb;
expression E;
@@
 drm_helper_mode_fill_fb_struct(...) {
	...
-	fb->depth = E;
	...
 }

@@
struct nouveau_framebuffer *fb;
@@
- fb->base.depth
+ fb->base.format->depth

@@
struct drm_framebuffer fb;
@@
- fb.depth
+ fb.format->depth

@@
struct drm_framebuffer *fb;
@@
- fb->depth
+ fb->format->depth

@@
struct drm_framebuffer fb;
@@
- (fb.format->depth)
+ fb.format->depth

@@
struct drm_framebuffer *fb;
@@
- (fb->format->depth)
+ fb->format->depth

@@
@@
 struct drm_framebuffer {
	 ...
-	 unsigned int depth;
	 ...
 };

v2: Drop the vmw stuff (Daniel)
    Rerun spatch due to code changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1481751095-18249-1-git-send-email-ville.syrjala@linux.intel.com

Surprisingly few changes needed to make it happen. Compile-tested
only. The idea is that this replaces the 2 patches from Ville's big
fb->format patch series as a prep patch. Only impact to later patches
should be the one instace added in this patch where we look at
fb->pixel_format (instead of fb->bpp and fb->depth), so minor
adjustements in the cocci-generated patches needed.

v2: Restore pitch computation in vmw_fb_kms_framebuffer (Sinclair).

Cc: ville.syrjala@linux.intel.com
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: linux-graphics-maintainer@vmware.com
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161202070740.31689-1-daniel.vetter@ffwll.ch

Rather than returning immediately, make sure to unlock the
mutexes first.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NCharmaine Lee <charmainel@vmware.com>
Reported-by: NEmil Velikov <emil.l.velikov@gmail.com>
Cc: <stable@vger.kernel.org>

For the Screen Object display unit, we need to reserve a
guest-invisible region equal to the size of the framebuffer for
the host.  This region can only be reserved in VRAM, whereas
the guest-visible framebuffer can be reserved in either VRAM or
GMR.

As such priority should be given to the guest-invisible
region otherwise in a limited VRAM situation, we can fail to
allocate this region.

This patch makes it so that vmw_sou_backing_alloc() is called
before the framebuffer is pinned.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>
---
This is the last patch of a 3-patch series to fix console black
screen issue on Ubuntu 16.04 server

mode->hdisplay * (var->bits_per_pixel + 7) gets evaluated before
the division, potentially making the pitch larger than it should
be.

Since the original intention is to do a div-round-up, just use
the macro instead.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

When a user-space process writes directly to the fbdev framebuffer,
we hit a circular locking dependency. Fix this by introducing a local
delayed work callback so that the defio lock can be released before
calling into the modesetting code for a dirty update.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Updating and fixing copyright headers.
Bump version minor to signal vgpu10 support.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

We're giving up all attempts to keep cpu- and device byte ordering separate.

This silences sparse when compiled using
make C=2 CF="-D__CHECK_ENDIAN__"
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

With screen targets the old legacy display system fbdev doesn't work
satisfactory anymore. At best the resolution is severely restricted.
Therefore implement fbdev on top of the kms system. With this change, fbdev
will be using whatever KMS backend is chosen.

There are helpers available for this, so in the future we'd probably want
to implement the helper callbacks instead of calling into our KMS
implementation directly.

v2: Make sure we take the mode_config mutex around modesetting,
Also clear the initial framebuffer using vzalloc instead of vmalloc.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

v2: Fix dma buffer validation on resource pinning.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Add command buffer support.
Currently we don't implement preemption or fancy error handling.
Tested with a couple of mesa-demos, compiz/unity and viewperf maya-03.

v2:
- Synchronize with pending work at command buffer manager takedown.
- Add an interface to flush the current command buffer for latency-critical
  command batches and apply it to framebuffer dirtying.

v3:
- Minor fixes of definitions and typos to address reviews.
- Removed new or moved branch predictor hints.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

This commit reworks device initialization so that we always enable the
FIFO at driver load, deferring SVGA enable until either first modeset
or fbdev enable.
This should always leave the fifo properly enabled for render- and
control nodes.
In addition,
*) We disable the use of VRAM when SVGA is not enabled.
*) We simplify PM support so that we only throw out resources on hibernate,
not on suspend, since the device keeps its state on suspend.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

A regression introduced when the master ttm lock was split into two.
Reported-and-tested-by: NBrian Paul <brianp@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

This allows us to more fine grained specify where to place the buffer object.

v2: rebased on drm-next, add bochs changes as well
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>

Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a
vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register:
SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to
SVGA_REG_PITCHLOCK.

This patch is Cc'd stable because of the unknown effects writing to this
register might have, particularly on older device versions.

v2: Updated log message.

Cc: stable@vger.kernel.org
Cc: Christopher Friedt <chrisfriedt@gmail.com>
Tested-by: NChristopher Friedt <chrisfriedt@gmail.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>

Previously, the vmwgfx_fb driver would allow users to call FBIOSET_VINFO, but it would not adjust
the FINFO properly, resulting in distorted screen rendering. The patch corrects that behaviour.

See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples.

Cc: stable@vger.kernel.org
Signed-off-by: NChristopher Friedt <chrisfriedt@gmail.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Don't use a per-master semaphore (ttm lock) for reservation protection, but
rather a per-device semaphore. This is needed since clients connecting using
render nodes aren't master aware.

The ttm lock used should probably be replaced with a reader-write semaphore
once the function down_xx_interruptible() is available.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

Convert #include "..." to #include <path/...> in drivers/gpu/.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NDave Jones <davej@redhat.com>

flush[_delayed]_work_sync() are now spurious.  Mark them deprecated
and convert all users to flush[_delayed]_work().

If you're cc'd and wondering what's going on: Now all workqueues are
non-reentrant and the regular flushes guarantee that the work item is
not pending or running on any CPU on return, so there's no reason to
use the sync flushes at all and they're going away.

This patch doesn't make any functional difference.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Mattia Dongili <malattia@linux.it>
Cc: Kent Yoder <key@linux.vnet.ibm.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: Sangbeom Kim <sbkim73@samsung.com>
Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Petr Vandrovec <petr@vandrovec.name>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Avi Kivity <avi@redhat.com> 

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm drivers set the fb_info->pixmap fields without setting
fb_info->pixmap.addr. If this is not set the fb core will overwrite
these all fb_info->pixmap fields anyway, so there is not much point
in setting them in the first place.

[airlied: dropped nvidiafb piece - not mine]
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

They need this to get all the EXPORT_SYMBOL variants and THIS_MODULE
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>