This makes it possible to use the same function for surface dirty and
present. Also fixes page flip without events.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

We need to make the dirty- and readback functions callable without a struct
drm_file pointer. We also need to unify the handling of dirty- and readback
cliprects that are now implemented in various places across the kms system,
som add helpers to facilitate this.
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>

This patch address the following underlying issues with SurfaceDMA

* SurfaceDMA command does not work in a 2D VM, but we can wrap a
  proxy surface around the same DMA buffer and use the SurfaceCopy
  command which does work in a 2D VM.

* Wrapping a DMA buffer with a proxy surface also gives us an
  added optimization path for the case when the DMA buf
  dimensions match the mode.  In this case, the DMA buf can
  be pinned as the display surface, saving an extra copy.
  This only works in a 2D VM because we won't be doing any
  rendering operations directly to the display surface.

v2
* Moved is_dmabuf_proxy field to vmw_framebuffer_surface
* Undone coding style changes
* Addressed other issues from review
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>

Add support for the screen target device interface.
Add a getparam parameter and bump minor to signal availability.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

For certain surface copies, we don't have a user space handle for
the destination surface.  In such cases, we are going to trust that
our caller is giving us the right surface ID.

To do this case, we created a quirk flag that may be useful
in the future for handling other cases.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NSinclair Yeh <syeh@vmware.com>

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

Refactored vmw_gb_surface_define_ioctl() and made the surface
definition part a separate function.  This way other parts of vmwgfx
can use it to allocate kernel-visible GB surfaces.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

Update device definition headers to support screen targets.
Signed-off-by: NSinclair Yeh <syeh@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>

For screen targets it appears we need to pin surfaces while they are bound
as screen targets, so add a small interface to do that.

v2: Always increase pin_count on pin.
v3: Add missing reservation sem.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Fix a circular locking dependency between
struct vmw_overlay::mutex and
struct vmw_private::reservation_sem
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NBrian Paul <brianp@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>

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

Don't fence and free the BO if command submission fails.
Signed-off-by: NThomas Hellstrom <thellstrom@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>

Two nice things here:
- drm_dev_register will truly register everything in the right order
  if the driver doesn't have a ->load callback. Before this we had to
  init the primary mode_group after the device nodes where already
  registered.

- Less things to keep track of when reworking the connector locking,
  yay!
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

It's been dead code since forever since mode groups haven't ever been
implemented. On top of that it's also been non-functional since we
only ever filtered the getresources ioctl and not any of the others
nor the mode object lookup code.

Given overwhelming evidence it looks like this isn't a feature we
need, hence remove it.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Remaining manual work in the drm core&helpers. Nothing special here,
no surprises.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This function takes two locks, both of them the wrong ones. This
wasn't an oversight from my fb locking rework since both patches
landed in parallel. We really only need fb_lock when walking that
list, since everything we can reach from that is refcounted properly
already.

v2: Drop unused dev spotted by 0day.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Now that we also grab the connection_mutex and so fixed the race with
atomic modeset we can use the iterator there too.

The other special case is drm_connector_unplug_all which would have a
locking inversion with the sysfs store/show functions if we'd grab the
mode_config.mutex around the unplug. We could just grab
connection_mutex instead, but that's a bit too much a dirty trick for
my taste. Also it's only used by udl, which doesn't do any other kind
of connector hotplugging, so should be race-free. Hence just stick
with a comment for now.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Similar with the i915 take all modeset locks for mst hotplug. This is
needed to make sure radeon holds both mode_config.mutex and
mode_config.connection_mutex when updating the connector_list, which
is the new (interim) locking regime we want for that.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

While auditing various users of the connector/encoder lists I realized
that the atomic code is a very prolific user of them. And it only ever
grabs the mode_config->connection_mutex, but not the
mode_config->mutex like all the other code walking encoder/connector
lists.

The problem is that we can't grab the mode_config.mutex late in atomic
code since that would lead to locking inversions. And we don't want to
grab it unconditionally like the legacy set_config modeset path since
that would render all the fine-grained locking moot.

Instead just grab more locks in the dp mst hotplug code. Note that
drm_connector_init (which is the one adding the connector to these
lists) already uses drm_modeset_lock_all.

The other reason for grabbing all locks is that the dpms off in the
unplug function amounts to a modeset, so better to take all required
locks for that.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Just so I have a user for this macro.

v2: Use the right macro - somehow I thought gcc should scream at me,
but list_for_each isn't really typesafe unfortunately. Spotted by
Ville.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This is now truly only duct-tape to keep locking checks happy since
calling this function when hpd or polling are already enabled is a
bug. The fbdev helper can't cope with hotplug changes yet at this
point, only after that.

Otoh a bit more robustness in this function can't hurt, and with this
fbdev can actually cope with hotplug changes. And it's also more
consistent with the connector hotadd/remove dp mst needs to do.
Therefore document this as new official behavior.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

So on first looks this seems superflous since drivers should ensure
correct ordering to not make this a problem. Otoh ordering constraints
between hdp, fbdev load and enabling polling are already tricky on
some hardware and it helps to be more robust.

But the real goal is to just shut up a locking WARN_ON I'd like to
add, which means init code gets some additional locks just for
uniformity.

v2: Also grab the lock for the public poll_enable, not just poll_init
which is used for resume, with the same justification.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

And roll them out across drm_* files. The point here isn't code
prettification (it helps with that too) but that some of these lists
aren't static any more. And having macros will gives us a convenient
place to put locking checks into.

I didn't add an iterator for props since that's only used by a
list_for_each_entry_safe in the driver teardown code.

Search&replace was done with the below cocci spatch. Note that there's
a bunch more places that didn't match and which would need some manual
changes, but I've intentially left these out for this mostly automated
patch.

iterator name drm_for_each_crtc;
struct drm_crtc *crtc;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
+ drm_for_each_crtc (crtc, dev) {
...
}

@@
iterator name drm_for_each_encoder;
struct drm_encoder *encoder;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+ drm_for_each_encoder (encoder, dev) {
...
}

@@
iterator name drm_for_each_fb;
struct drm_framebuffer *fb;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(fb, &dev->mode_config.fb_list, head) {
+ drm_for_each_fb (fb, dev) {
...
}

@@
iterator name drm_for_each_connector;
struct drm_connector *connector;
struct drm_device *dev;
expression head;
@@
- list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ drm_for_each_connector (connector, dev) {
...
}
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

No need to pass the planelist when everyone just uses
dev->mode_config.plane_list anyway.

I want to add a pile more of iterators with unified (obj, dev)
arguments. This is just prep.
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This is needed as the CRC PMIC has support for Panel
enable/diable as gpio which needs 'gpiod_add_lookup_table'
and 'gpiod_remove_lookup_table' from gpiolib. This patch
can be squashed with below commit in topic/crc-pmic branch

    commit 61dd2ca2
    Author: Shobhit Kumar <shobhit.kumar@intel.com>
    Date:   Fri Jun 26 14:32:05 2015 +0530

    mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO
    signal

    On some Intel SoC platforms, the panel enable/disable signals
    are controlled by CRC PMIC. Add those control as a new GPIO in a
    lookup table for gpio-crystalcove chip during CRC driver load

Cc: Lee Jones <lee.jones@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the CRC PWM device in intel_panel.c and add new MIPI backlight
specififc callbacks

v2: Modify to use pwm_config callback
v3: Addressed Jani's comments
    - Renamed all function as pwm_* instead of vlv_*
    - Call intel_panel_actually_set_backlight in enable function
    - Return -ENODEV in case pwm_get fails
    - in case pwm_config error return error cdoe from pwm_config
    - Cleanup pwm in intel_panel_destroy_backlight
v4: Removed unused #defines and initialized backlight with INVALID_PIPE (Ville)

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.

v2: Use the newer gpiod interface(Alexandre)
v3: Remove the redundant checks and unused code (Ville)
v4: Moved PWM vs SoC backlight #defines to intel_bios.h (Jani)

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Crystalcove PMIC provides three PWM signals and this driver exports
one of them on the BYT platform which is used to control backlight for
DSI panel. This is platform device implementation of the drivers/mfd
cell device for CRC PMIC.

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NVarka Bhadram <varkabhadram@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
entry for the same to be used by the consumer (Intel GFX)

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Needed for PWM control suuported by the PMIC

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On some Intel SoC platforms, the panel enable/disable signals are
controlled by CRC PMIC. Add those control as a new GPIO in a lookup
table for gpio-crystalcove chip during CRC driver load

CC: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In case we unload and load a driver module again that is registering a
lookup table, without this it will result in multiple entries. Provide
an option to remove the lookup table on driver unload

Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Reviewed-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NBen Goz <ben.goz@amd.com>
Reviewed-by: NYair Shachar <yair.shachar@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

This patch makes use of the new amd headers (that are part of the new
amdgpu driver), instead of private defines.
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

Signed-off-by: NBen Goz <ben.goz@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>

The MAP_QUEUES packet length for Carrizo is different than for Kaveri.
Therefore, we now need to calculate the runlist length with regard to the
underlying H/W.
Signed-off-by: NBen Goz <ben.goz@amd.com>
Signed-off-by: NOded Gabbay <oded.gabbay@gmail.com>