Add connector handling functions. Start tracking is_implicity in
the connector state.  Eventually, this field should be tracked
exclusively in a connector state.

Now that plane and connector states have been created, we can also
activate the code that use CRTC state.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Add plane state handling functions.

We have to keep track of a few plane states so we cannot use the
DRM helper for this.

Created vmw_plane_state along with functions to reset, duplicate,
and destroty it.

v2
* Removed cursor clean up special case
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Acked-by: NDaniel Vetter <daniel@ffwll.ch>

Create and Add CRTC state.  We currently do not track any properties
or custom states so we can technically use the DRM helpers.  Creating
this code just to make potential future additions easier.

Most of the new code will be compiled but not enabled until
plane/connector state handling code is also in place.

This is the first of a series to enable atomic mode set for vmwgfx.

The atomic enabling effort was done in collaboration with Thomas
Hellstrom and the VMware Graphics Team.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Universal support is prerequisite for atomic mode set.

Explicitly create planes for the cursor and the primary FB.  With
a functional cursor plane, the DRM will no longer use the legacy
cursor_set2 and cursor_move entry points.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

This field is not being used anymore
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Found by coverity.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NCharmaine Lee <charmainel@vmware.com>

The uninitialized field is not currently used, but might be in the future,
and static analyzers complain.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NCharmaine Lee <charmainel@vmware.com>

Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can
populate fb->dev early. Will make it easier to use the fb before we
register it.

@@
identifier fb, mode_cmd;
@@
 void drm_helper_mode_fill_fb_struct(
+				     struct drm_device *dev,
				     struct drm_framebuffer *fb,
				     const struct drm_mode_fb_cmd2 *mode_cmd
				     );

@@
identifier fb, mode_cmd;
@@
 void drm_helper_mode_fill_fb_struct(
+				     struct drm_device *dev,
				     struct drm_framebuffer *fb,
				     const struct drm_mode_fb_cmd2 *mode_cmd
				     )
{ ... }

@@
function func;
identifier dev;
expression E1, E2;
@@
func(struct drm_device *dev, ...)
{
 ...
 drm_helper_mode_fill_fb_struct(
+				dev,
				E1, E2);
 ...
}

@@
expression E1, E2;
@@
 drm_helper_mode_fill_fb_struct(
+				dev,
				E1, E2);

v2: 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>
Link: http://patchwork.freedesktop.org/patch/msgid/1481748539-18283-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

The function's behaviour was changed in 90844f00, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.

Instead of having to allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory.

Fixes: 90844f00 ("drm: make drm_get_format_name thread-safe")
Cc: Rob Clark <robdclark@gmail.com>
Cc: Christian König <christian.koenig@amd.com>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NRob Clark <robdclark@gmail.com>
Acked-by: Sinclair Yeh <syeh@vmware.com> (vmwgfx)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NEric Engestrom <eric@engestrom.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161112011309.9799-1-eric@engestrom.ch

The driver is the last users of the drm_fb_get_bpp_depth() function. It
should ideally be converted to use struct drm_mode_fb_cmd2 instead of
the legacy struct drm_mode_fb_cmd internally, but that will require
broad changes across the code base. As a first step, replace
drm_fb_get_bpp_depth() with drm_format_info() in order to stop exporting
the function to drivers.

The new DRM_ERROR() message comes from the vmw_create_dmabuf_proxy(),
vmw_kms_new_framebuffer_surface() and vmw_kms_new_framebuffer_dmabuf()
functions that currently print an error if the pixel format is
unsupported.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-12-git-send-email-laurent.pinchart@ideasonboard.com

Offer an option for advanced users who want larger modes at 16bpp.

This becomes necessary after the fix: "Work around mode set
failure in 2D VMs."  Without this patch, there would be no way
for existing advanced users to get to a high res mode, and the
regression is they will likely get a black screen after a software
update on their current VM.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>

In a low-memory 2D VM, fbdev can take up a large percentage of
available memory, making them unavailable for other DRM clients.

Since we do not take fbdev into account when filtering modes,
we end up claiming to support more modes than we actually do.

As a result, users get a black screen when setting a mode too
large for current available memory.  In a low-memory VM
configuration, users can get a black screen for a mode as low
as 1024x768.

The current mode filtering mechanism keys off of
SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount
of surface memory we have.  Since this value is a performance
suggestion, not a hard limit, and since there should not be much
of a performance impact for a 2D VM, rather than filtering out
more modes, we will just allow ourselves to exceed the SVGA's
performance suggestion.

Also changed assumed bpp to 32 from 16 to make sure we can
actually support all the modes listed.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Cc: <stable@vger.kernel.org>

Change return value to int to propagate errors from gamma_set,
and remove start parameter. Updates always use the full size,
and some drivers even ignore the start parameter altogether.

This is needed for atomic drivers, where an atomic commit can
fail with -EINTR or -ENOMEM and should be restarted. This is already
and issue for drm_atomic_helper_legacy_set_gamma, which this patch
fixes up.

Changes since v1:
- Fix compiler warning. (Emil)
- Fix commit message (Daniel)

Cc: Alex Deucher <alexander.deucher@amd.com>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Eric Anholt <eric@anholt.net>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Mathieu Larouche <mathieu.larouche@matrox.com>
Cc: Thierry Reding <treding@nvidia.com>
Acked-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Improve commit message a bit more, mention that this fixes
the helper.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/742944bc-9f41-1acb-df4f-0fd4c8a10168@linux.intel.com

Some global KMS state that is elsewhere protected by the mode_config
mutex here needs to be protected with a local mutex. Remove corresponding
lockdep checks and introduce a new driver-private global_kms_state_mutex,
and make sure its locking order is *after* the crtc locks in order to
avoid having to release those when the new mutex is taken.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Cc: <stable@vger.kernel.org> # 4.6

Not used any more.
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Base the cursor position on the coordinate of the crtc origin in the
gui coordinate system rather than in the framebuffer coordinate system.

With explicit placement, these may differ (for example when two crtcs
scan out of the same framebuffer location).
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Introduced by qxl, add these properties as a generic way to tell a
display manager about the GUI layout.

Also add the hotplug_mode_update_property which advises display managers to
reread the mode list on a hotplug event.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJakob Bornecrantz <jakob@vmware.com>

Preparation for supporting explicit fbs for screen objects and screen
targets.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

For page flips the framebuffer may be much larger than the crtc
scanout area and may be attached to multiple crtcs.
When flipping a crtc, make sure we dirty only that crtc's area of the
framebuffer.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

When the framebuffer is a vmwgfx dma buffer and a proxy surface is
created, the vmw_kms_update_proxy() function requires that the proxy
surface width and the framebuffer pitch are compatible, otherwise
display corruption occurs as seen in gnome-shell/native with software
3D. Since the framebuffer pitch is determined by user-space, allocate
a proxy surface the width of which is based on the framebuffer pitch
rather than on the framebuffer width.

Cc: <stable@vger.kernel.org>
Reported-by: NRaphael Hertzog <buxy@kali.org>
Tested-by: NMati Aharoni <muts@kali.org>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Moves a bunch of junk to .rodata from .data.

 drivers/gpu/drm/vmwgfx/vmwgfx.ko:
-.text                       132244
+.text                       132240
-.rodata                      18296
+.rodata                      18680
-.data                         5096
+.data                         4712
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450178476-26284-28-git-send-email-boris.brezillon@free-electrons.comSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that the mode type bit merge logic is fixed to only merge
between new probed modes, hopefully we can eliminat the special
case for qxl and virtio. That is make the merge the mode type
bits from all matching new probed modes, just like every other
driver.

qxl and virtio got excluded from the merging in
commit 3fbd6439 ("drm: copy mode type in drm_mode_connector_list_update()")
commit abce1ec9 ("Revert "drm: copy mode type in drm_mode_connector_list_update()"")
commit b87577b7 ("drm: try harder to avoid regression when merging mode bits")

Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflicts with doc updates.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These hooks will be gone soon.

Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449218769-16577-12-git-send-email-daniel.vetter@ffwll.chReviewed-by: NThierry Reding <treding@nvidia.com>

Fixes native drm clients like Fedora 23 Wayland which now appears to
be able to use cursor hotspots without strange cursor offsets.
Also fixes a couple of ignored error paths.

Since the core drm cursor hotspot is incompatible with the legacy vmwgfx
hotspot (the core drm hotspot is reset when the drm_mode_cursor ioctl
is used), we need to keep track of both and add them when the device
hotspot is set. We assume that either is always zero.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Drivers shouldn't clobber the passed in addfb ioctl parameters.
i915 was doing just that. To prevent it from happening again,
pass the struct around as const, starting all the way from
internal_framebuffer_create().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the introduction of the new command buffer mechanism,
proper care wasn't taken to flush cursor image updates and
event-less screen-target page-flips.

Fix this by introducing explicit flush points.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

Now that we use memremap instead of ioremap, Use WRITE_ONCE / READ_ONCE
instead of iowrite / ioread.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

This continues the pattern started in commit cc1ef118 ("drm/irq:
Make pipe unsigned and name consistent"). This is applied to the public
APIs and driver callbacks, so pretty much all drivers need to be updated
to match the new prototypes.

Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Jianwei Wang <jianwei.wang.chn@gmail.com>
Cc: Alison Wang <alison.wang@freescale.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Yao <mark.yao@rock-chips.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Function vmw_kms_helper_dirty() uses the uninitialized variable ret as
return value. Make the result deterministic and directly return as the
variable is unused anyway. Detected by Coverity CID 1324255.
Signed-off-by: NChristian Engelmayer <cengelma@gmx.at>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@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>

Initial DX support.
Co-authored with Sinclair Yeh, Charmaine Lee and Jakob Bornecrantz.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NCharmaine Lee <charmainel@vmware.com>

This patch fixes two issues.  One, when a surface is a proxy for a DMA
buffer, it holds an extra reference that needs to be cleared.

Two, when fbdev is enabled, we need to unpin the framebuffer before
unloading the driver.  This is done by a call to vmw_fb_off().

v2
Moved unreferencing surface to from vmw_framebuffer_surface_destroy()
to vmw_kms_new_framebuffer()

Added "struct vmw_framebuffer *vfb = NULL;" to silence a compiler
warning.

Removed error checking after calling vmw_surface/dmabuf_reference()
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

For a Screen Target capable display device, the display topology is
limited by SVGA_REG_MAX_PRIMARY_BOUNDING_BOX_MEM.  Two values are
checked against this limit:
  1.  Size of the bounding box enclosing all the displays, and
  2.  Size of the total number of displays, e.g. framebuffers

The limitations above mean we do not have exact max width and
height for the topology.  The best current option is to set those to
the maximum texture width/height.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@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>

The preferred mode typically didn't end up first, since the function
drm_mode_connector_list_update() reordered the modes.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

It somehow got lost in a rewrite.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@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>

The kernel interface is needed for fbdev, and needs to be free from
a file_priv member. To accomplish this, remove the fb surface mutex
and list which isn't used anymore, anyway.

Finally, make the pin() and unpin() pin the framebuffer for all display
system backends, so that fbdev can pin its framebuffer before mapping it.

v2: Address review comments:
- Fix vmw_framebuffer_unpin() to handle also the surface framebuffer case.
- Fix vmw_kms_new_framebuffer() to actually use the only_2d parameter.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>