Reported by Intel's kbuild robot.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>
Reviewed-by: NBrian Paul <brianp@vmware.com>

When the size of dma_addr_t was 32 bits, the compiler warned
about the size of the 32 bit shift being larger than the size
of the data type.

Reported by Intel's kbuild robot.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@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>

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>

If the command buffer pool is out of space, the code waits until space is
available. However since the condition code tries to allocate a range manager
node while !TASK_RUNNING we get a kernel warning.

Avoid this by pre-allocating the mm node. This will also probably be more
efficient.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NSinclair Yeh <syeh@vmware.com>

Also implements the missing readback function and
fixes page flip in case of no event.

v2:
- Adapt to the work done for screen targets for 2d, in particular
Handle proxy surface updates.
- Remove execbuf quirks since we now use fifo reserve / commit.
- Revert the initial placement of vmw dma buffers.

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

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>

Merge tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-next

connector hotplug locking cleanup and fixes to make it save against
atomic. Note that because of depencies this is based on top of the
drm-intel-next pull, so that one needs to go in before this one.

I've also thrown in the mode_group removal on top since it's defunct,
never worked really, no one seems to care and the code can be resurrected
easily.

* tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
  drm: gc now dead mode_group code
  drm: Stop filtering according to mode_group in getresources
  drm: Roll out drm_for_each_{plane,crtc,encoder}
  drm/cma-helper: Fix locking in drm_fb_cma_debugfs_show
  drm: Roll out drm_for_each_connector more
  drm: Amend connector list locking rules
  drm/radeon: Take all modeset locks for DP MST hotplug
  drm/i915: Take all modeset locks for DP MST hotplug
  drm: Check locking in drm_for_each_fb
  drm/i915: Use drm_for_each_fb in i915_debugfs.c
  drm: Check locking in drm_for_each_connector
  drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors
  drm/probe-helper: Grab mode_config.mutex in poll_init/enable
  drm: Add modeset object iterators
  drm: Simplify drm_for_each_legacy_plane arguments

crystalcove pmic support from Shobhit. Patch series has all acks/r-bs from
other mainainers so ok to pull into drm-next. But I'm cc'ing all other
maintainers as fyi and in case they want to pull it into their trees too
to avoid conflicts.

* tag 'topic/crc-pmic-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
  mfd: Add GPIOLIB dependency if INTEL_SOC_PMIC is to be enabled
  drm/i915: Backlight control using CRC PMIC based PWM driver
  drm/i915: Use the CRC gpio for panel enable/disable
  pwm: crc: Add Crystalcove (CRC) PWM driver
  mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
  mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
  mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal
  gpiolib: Add support for removing registered consumer lookup table

- prelim hw support dropped for skl after Damien fixed an ABI issue around
  planes
- legacy modesetting is done using atomic infrastructure now (Maarten)!
- more gen9 workarounds (Arun&Nick)
- MOCS programming (cache control for better performance) for skl/bxt
- vlv/chv dpll improvements (Ville)
- PSR fixes from Rodrigo
- fbc improvements from Paulo
- plumb requests into execlist submit functions (Mika)
- opregion code cleanup from Jani
- resource streamer support from Abdiel for mesa
- final fixes for 12bpc hdmi + enabling support from Ville
drm-intel-next-2015-07-03:
- dsi improvements (Gaurav)
- bxt ddi dpll hw state readout (Imre)
- chv dvfs support and overall wm improvements for both vlv and chv (Ville)
- ppgtt polish from Mika and Michel
- cdclk support for bxt (Bob Pauwe)
- make frontbuffer tracking more precise
- OLR removal (John Harrison)
- per-ctx WA batch buffer support (Arun Siluvery)
- remvoe KMS Kconfig option (Chris)
- more hpd handling refactoring from Jani
- use atomic states throughout modeset code and integrate with atomic plane
  update (Maarten)
drm-intel-next-2015-06-19:
- refactoring hpd irq handlers (Jani)
- polish skl dpll code a bit (Damien)
- dynamic cdclk adjustement (Ville & Mika)
- fix up 12bpc hdmi and enable it for real again (Ville)
- extend hsw cmd parser to be useful for atomic configuration (Franscico Jerez)
- even more atomic conversion and rolling state handling out across modeset code
  from Maarten & Ander
- fix DRRS idleness detection (Ramalingam)
- clean up dsp address alignment handling (Ville)
- some fbc cleanup patches from Paulo
- prevent hard-hangs when trying to reset the gpu on skl (Mika)

* tag 'drm-intel-next-2015-07-17' of git://anongit.freedesktop.org/drm-intel: (386 commits)
  drm/i915: Update DRIVER_DATE to 20150717
  drm/i915/skl: Drop the preliminary_hw_support flag
  drm/i915/skl: Don't expose the top most plane on gen9 display
  drm/i915: Fix divide by zero on watermark update
  drm/i915: Invert fastboot check
  drm/i915: Clarify logic for initial modeset
  drm/i915: Unconditionally check gmch pfit state
  drm/i915: always disable irqs in intel_pipe_update_start
  drm/i915: Remove use of runtime pm in atomic commit functions
  drm/i915: Call plane update functions directly from intel_atomic_commit.
  drm/i915: Use full atomic modeset.
  drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken
  drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaround
  drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaround
  drm/i915: Enable WA batch buffers for Gen9
  drm/i915/gen9: Implement WaDisableKillLogic for gen 9
  drm/i915: Use expcitly fixed type in compat32 structs
  drm/i915: Fix noatomic crtc disabling, v2.
  drm/i915: fill in more mode members
  drm/i915: Added BXT check in HAS_CORE_RING_FREQ macro
  ...

Update drm-misc pull request since the first one didn't go in yet. Few
atomic helper patches, rejecting some old dri1 crap for modern drivers and
a few trivial things on top.

* tag 'topic/drm-misc-2015-07-23' of git://anongit.freedesktop.org/drm-intel:
  drm/mgag200: remove unneeded variable
  drm/mgag200: remove unused variables
  drm/atomic: Only update crtc->x/y if it's part of the state, v2.
  drm/fb: drop panic handling
  drm: Fix warning with make xmldocs caused by drm_irq.c
  drm/gem: rip out drm vma accounting for gem mmaps
  drm/fourcc: Add formats R8, RG88, GR88
  drm/atomic: Cleanup on error properly in the atomic ioctl.
  drm: Update plane->fb also for page_flip
  drm: remove redundant code form drm_ioc32.c
  drm: reset empty state in transitional helpers
  drm/crtc-helper: Fixup error handling in drm_helper_crtc_mode_set
  drm/atomic: Update old_fb after setting a property.
  drm: Remove useless blank line
  drm: Reject DRI1 hw lock ioctl functions for kms drivers
  drm: Convert drm_legacy_ctxbitmap_init to void return type
  drm: Turn off Legacy Context Functions

- Add Carrizo support for amdkfd, using the new amdgpu driver as the relevant
  kgd. The support includes interfaces with amdgpu both for gfx7 (Kaveri) and
  gfx8 (Carrizo). However, gfx7 interface is used for debugging purposes only,
  so amdkfd defaults to using radeon when Kaveri is installed.

I would like to note that no new IOCTLs are being introduced, and there is no
change in the current IOCTLs, as they are suited both for gfx7 and gfx8.

* tag 'drm-amdkfd-next-2015-07-20' of git://people.freedesktop.org/~gabbayo/linux:
  drm/amdkfd: Set correct doorbell packet type for Carrizo
  drm/amdkfd: Use generic defines in new amd headers
  drm/amdkfd: Implement create_map_queues() for Carrizo
  drm/amdkfd: fix runlist length calculation
  drm/amdkfd: Add support for VI in DQM
  drm/amdkfd: add support for VI in MQD manager
  drm/amdkfd: add CP HWS packet headers for VI
  drm/amdkfd: add supported CZ devices PCI IDs to amdkfd
  drm/amdkfd: Add dependency of DRM_AMDGPU to Kconfig
  drm/amdgpu: Add amdgpu <--> amdkfd gfx8 interface
  drm/amdgpu: add amdgpu <--> amdkfd gfx7 interface
  drm/amdgpu: Add H/W agnostic amdgpu <--> amdkfd interface
  drm/radeon: Modify kgd_engine_type enum to match CZ

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>

Now that dp mst hotplug takes all locks we can amend the locking rules
for the iterators. This is needed before we can roll these out in the
atomic code to avoid getting burried in WARNINGs.

v2: Rebase onto the extracted list locking assert and add a comment to
explain the rules.

v3: Fixup German->English translation fail in the comment.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
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>

Ever since framebuffers are reference counted we have a special lock
for the global fb list. Make sure users of that list do hold that
lock when using the new iterators.
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>