drm: Only update final vblank count when precise ts is available

Drivers without a hardware vblank counter simply can't account for the
vblanks that happened while the vblank interrupt was off. To check
this grab a vblank timestamp and if the result is dubious follow the
normal save-and-disable logic.

Drivers should prevent this by setting vblank_disable_allowed = false,
but since running vblank interrupts constantly is not good for power
consumption most drivers lie. Testing for precise vblank timestamps is
the next best thing we can check for.

Suggested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Really never disable vblank irqs for offdelay==0

With the new support for immediate vblank disabling we always disabled
the vblank interrupt right away, irrespective of the vblank offdelay
setting.

But being able to let vblanks run forever is fairly useful for
debugging, so restore that behaviour.

Suggested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

drm: Use vblank_disable_and_save in drm_vblank_cleanup()

Calling vblank_disable_fn() will cause that function to no-op
if !dev->vblank_disable_allowed for some kms drivers, e.g.,
on nouveau-kms. This can cause the gpu vblank irq's to not get
disabled before freeing the dev->vblank array, so if a
vblank irq fires and calls into drm_handle_vblank() after
drm_vblank_cleanup() completes, it will cause use-after-free
access to dev->vblank array.

Call vblank_disable_and_save unconditionally, so vblank irqs
are guaranteed to be off, before we delete the data structures
on which they operate.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Fix subsystem name in patch subject.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Remove drm_vblank_cleanup from drm_vblank_init error path.

drm_vblank_cleanup() would operate on non-existent dev->vblank
data structure, as failure to allocate that data structure is
what triggers the error path in the first place.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Store the vblank timestamp when adjusting the counter during disable

During vblank disable the code tries to guess based on the
timestamps whether we just missed one vblank or not. And if so
it increments the counter. However it forgets to store the new
timestamp to the approriate slot in our timestamp ring buffer.
So anyone querying the timestamp for the resulting sequence
number would get a stale timestamp. Fix it up by storing the
new timestamp.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fix confusing debug message in drm_update_vblank_count()

Now that drm_update_vblank_count() can be called even when we're not
about to enable the vblank interrupts we shouldn't print debug messages
stating otherwise.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Update scanline_offset only for active crtcs

update_scanline_offset() in intel_sanitize_crtc() was supposed to
be called only for active crtcs. But due to some underrun patches it
now gets updated for all crtcs on gmch platforms.

Move the update_scanline_offset() to the very beginning of
intel_sanitize_crtc() where we update the vblank state. This seems like
a better place anyway since the scanline offset ought to be up to date
before we might need to consult it. So before any vblanky stuff happens.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Kick start vblank interrupts at drm_vblank_on()

If the user is interested in getting accurate vblank sequence
numbers all the time they may disable the vblank disable timer
entirely. In that case it seems appropriate to kick start the
vblank interrupts already from drm_vblank_on().

v2: Adapt to the drm_vblank_offdelay ==0 vs <0 changes

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Opt out of vblank disable timer on >gen2

Now that the vblank races are plugged, we can opt out of using
the vblank disable timer and just let vblank interrupts get
disabled immediately when the last reference is dropped.

Gen2 is the exception since it has no hardware frame counter.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Add dev->vblank_disable_immediate flag

Add a flag to drm_device which will cause the vblank code to bypass the
disable timer and always disable the vblank interrupt immediately when
the last reference is dropped.

v2: Add some notes about the flag to the kernel doc

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Disable vblank interrupt immediately when drm_vblank_offdelay<0

Make drm_vblank_put() disable the vblank interrupt immediately when the
refcount drops to zero and drm_vblank_offdelay<0.

v2: Preserve the current drm_vblank_offdelay==0 'never disable' behaviur

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()

Currently it's possible that the following will happen:
1. drm_wait_vblank() calls drm_vblank_get()
2. drm_vblank_off() gets called
3. drm_wait_vblank() calls drm_queue_vblank_event() which
   adds the event to the queue event though vblank interrupts
   are currently disabled (and may not be re-enabled ever again).

To fix the problem, add another vblank->enabled check into
drm_queue_vblank_event().

drm_vblank_off() holds event_lock around the vblank disable,
so no further locking needs to be added to drm_queue_vblank_event().
vblank disable from another source is not possible since
drm_wait_vblank() already holds a vblank reference.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock

Currently both drm_irq.c and several drivers call drm_vblank_put()
while holding event_lock. Now that drm_vblank_put() can disable the
vblank interrupt directly it may need to grab vbl_lock and
vblank_time_lock. That causes deadlocks since we take the locks
in the opposite order in two places in drm_irq.c. So let's make
sure the locking order is always event_lock->vbl_lock->vblank_time_lock.

In drm_vblank_off() pull up event_lock from underneath vbl_lock. Hold
the event_lock across the whole operation to make sure we only send
out the events that were on the queue when we disabled the interrupt,
and not ones that got added just after (assuming drm_vblank_on() already
managed to get called somewhere between).

To sort the other deadlock pull the event_lock out from
drm_handle_vblank_events() into drm_handle_vblank() to be taken outside
vblank_time_lock. Add the appropriate assert_spin_locked() to
drm_handle_vblank_events().

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Reduce the amount of dev->vblank[crtc] in the code

Declare a local struct drm_vblank_crtc * and use that
instead of having to do dig it out via 'dev->vblank[crtc]'
everywhere.

Performed with the following coccinelle incantation,
and a few manual whitespace cleanups:

@@
identifier func,member;
expression num_crtcs;
struct drm_device *dev;
unsigned int crtc;
@@
func (...) {
+ struct drm_vblank_crtc *vblank;
...
if (crtc >= num_crtcs)
   return ...;
+ vblank = &dev->vblank[crtc];
<+...
(
- dev->vblank[crtc].member
+ vblank->member
|
- &(dev->vblank[crtc])
+ vblank
)
...+>
}

@@
struct drm_device *dev;
int crtc;
identifier member;
expression num_crtcs;
@@
for (crtc = 0; crtc < num_crtcs; crtc++) {
+ struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
+
<+...
(
- dev->vblank[crtc].member
+ vblank->member
|
- &(dev->vblank[crtc])
+ vblank
)
...+>
}

@@
identifier func,member;
@@
func (struct drm_device *dev, int crtc, ...) {
+ struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
<+...
(
- dev->vblank[crtc].member
+ vblank->member
|
- &(dev->vblank[crtc])
+ vblank
)
...+>
}

v2: Rebased

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Avoid random vblank counter jumps if the hardware counter has been reset

When drm_vblank_on() is called the hardware vblank counter may have
been reset, so we can't trust that the old values sampled prior to
drm_vblank_off() have anything to do with the new values.

So update the .last count in drm_vblank_on() to make the first
drm_vblank_enable() consider that as the reference point. This
will correct the user space visible counter to account for the
time between drm_vblank_on() and the first drm_vblank_enable()
calls.

For extra safety subtract one from the .last count in drm_vblank_on()
to make sure that user space will never see the same counter value
before and after modeset.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off()

If the vblank irq has already been disabled (via the disable timer) when
we call drm_vblank_off() sample the counter and timestamp one last time.
This will make the sure that the user space visible counter will account
for time between vblank irq disable and drm_vblank_off().

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Move drm_update_vblank_count()

Move drm_update_vblank_count() to avoid forward a declaration.
No functional change.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Don't clear vblank timestamps when vblank interrupt is disabled

Clearing the timestamps causes us to send zeroed timestamps to userspace
if they get sent out in response to the drm_vblank_off(). It's better
to send the very latest timestamp and count instead.

Testcase: igt/kms_flip/modeset-vs-vblank-race
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()

v2: Drop the drm_vblank_off() (Daniel)
    Use drm_crtc_vblank_{get,put}()

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: Always reject drm_vblank_get() after drm_vblank_off()

Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().

When drm_vblank_get() encounters a >0 refcount and the vblank
interrupt is already disabled it will simply return -EINVAL.

Hopefully the use of inmodeset won't conflict badly with
drm_vblank_{pre,post}_modeset().

For i915 there's a window between drm_vblank_off() and marking the
crtc as inactive where the current code still allows drm_vblank_get().

v2: Describe what drm_vblank_get() does to explain how
    a simple refcount bump manages to fix things (Daniel)

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm: move drm_stub.c to drm_drv.c

Everyone agrees we should do this,

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-next' of git://people.freedesktop.org/~dvdhrm/linux into drm-next

bunch of cleanups
* 'drm-next' of git://people.freedesktop.org/~dvdhrm/linux:
  drm: mark drm_context support as legacy
  drm: make sysfs device always available for minors
  drm: make minor->index available early
  drm: merge drm_drv.c into drm_ioctl.c
  drm: move module initialization to drm_stub.c
  drm: don't de-authenticate clients on master-close
  drm: drop redundant drm_file->is_master
  drm: extract legacy ctxbitmap flushing

drm/i915: lock around link status and link training.

We need to take the connection mutex around the link status
check for non-MST case, but also around the MST link training
on short HPDs.

I suspect we actually should have a dpcd lock in the future as
well, that just lock the local copies of dpcd and flags stored
from that.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm-next-3.17' of git://people.freedesktop.org/~agd5f/linux into drm-next

- Additional Hawaii fixes
- Support for using the display scaler on non-fixed mode displays
- Support for new firmware format that makes it easier to update
- Enable dpm by default on additional asics
- GPUVM improvements
- Support for uncached and write combined gtt buffers
- Allow allocation of BOs larger than visible vram
- Various other small fixes and improvements

* 'drm-next-3.17' of git://people.freedesktop.org/~agd5f/linux: (57 commits)
  drm/radeon: Prevent hdmi deep color if max_tmds_clock is undefined.
  drm/radeon: Use pflip irqs for pageflip completion if possible. (v2)
  drm/radeon: tweak ACCEL_WORKING2 query for the new firmware for hawaii
  drm/radeon: use packet3 for nop on hawaii with new firmware
  drm/radeon: tweak ACCEL_WORKING2 query for hawaii
  drm/radeon: use packet2 for nop on hawaii with old firmware
  drm/radeon: update IB size estimation for VM
  drm/radeon: split PT setup in more functions
  drm/radeon: add VM GART copy optimization to NI as well
  drm/radeon: take a BO reference on VM cleanup
  drm/radeon: add radeon_bo_ref function
  drm/radeon: remove taking mclk_lock from radeon_bo_unref
  drm/radeon: adjust default radeon_vm_block_size v2
  drm/radeon: try to enable VM flushing once more
  drm/radeon: use an intervall tree to manage the VMA v2
  drm/radeon: remove radeon_bo_clear_va
  drm/radeon: invalidate moved BOs in the VM (v2)
  drm/radeon: re-enable dpm by default on BTC
  drm/radeon: re-enable dpm by default on cayman
  drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM
  ...

drm: mark drm_context support as legacy

This renames all drm-context helpers to drm_legacy_*() and moves the
internal definitions into the new drm_legacy.h header. This header is
local to DRM-core and drivers shouldn't access it.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/radeon: Prevent hdmi deep color if max_tmds_clock is undefined.

HDMI spec requires a valid max_tmds_clock from edid for hdmi
deep color modes. If a sink violates this, disable deep color.

Also add a hint to user about the deep_color module parameter if
deep color is disabled due to that.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm: make sysfs device always available for minors

For each minor we allocate a sysfs device as minor->kdev. Currently, this
is allocated and registered in drm_minor_register(). This makes it
impossible to add sysfs-attributes to the device before it is registered.
Therefore, they are not added atomically, nor can we move device_add()
*after* ->load() is called.

This patch makes minor->kdev available early, but only adds the device
during minor-registration. Note that the registration is still called
before ->load() as debugfs needs to be split, too. This will be fixed in
follow-ups.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: make minor->index available early

Instead of allocating the minor-index during registration, we now do this
during allocation. This way, debug-messages between minor-allocation and
minor-registration will now use the correct minor instead of 0. Same is
done for unregistration vs. free, so debug-messages between
device-shutdown and device-destruction show proper indices.

Even though minor-indices are allocated early, we don't enable minor
lookup early. Instead, we keep the entry set to NULL and replace it during
registration / unregistration. This way, the index is allocated but lookup
only works if registered.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: merge drm_drv.c into drm_ioctl.c

All that is left in drm_drv.c is ioctl management. Merge it into
drm_ioctl.c so we have all ioctl management in one file (and the name is
much more fitting).

Maybe we should now rename drm_stub.c to drm_drv.c again?

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: move module initialization to drm_stub.c

Most of the new DRM management functions are nowadays in drm_stub.c. By
moving the core module initialization to drm_stub.c we can make several
global variables static and keep the stub-open helper local.

The core files now look like this:
  drm_stub.c: Core management
   drm_drv.c: Ioctl dispatcher
 drm_ioctl.c: Actual ioctl backends
  drm_fops.c: Char-dev file-operations

A follow-up patch will move what is left from drm_drv.c into drm_ioctl.c.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: don't de-authenticate clients on master-close

If an active DRM-Master closes its device, we deauthenticate all clients
on that master. However, if an inactive DRM-Master closes its device, we
do nothing. This is quite inconsistent and breaks several scenarios:

 1) If this was used as security mechanism, it fails horribly if a master
    closes a device while VT switched away. Furthermore, none of the few
    drivers using ->master_*() callbacks seems to require it, anyway.

 2) If you spawn weston (or any other non-UMS compositor) in background
    while another compositor is active, both will get assigned to the
    same "drm_master" object. If the foreground compositor now exits, all
    clients of both the foreground AND background compositor will be
    de-authenticated leading to unexpected behavior.

Stop this non-sense and keep clients authenticated. We don't do this when
dropping DRM-Master (i.e., switching VTs) so don't do it on active-close
either!

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: drop redundant drm_file->is_master

The drm_file->is_master field is redundant as it's equivalent to:
    drm_file->master && drm_file->master == drm_file->minor->master

1) "=>"
  Whenever we set drm_file->is_master, we also set:
      drm_file->minor->master = drm_file->master;

  Whenever we clear drm_file->is_master, we also call:
      drm_master_put(&drm_file->minor->master);
  which implicitly clears it to NULL.

2) "<="
  minor->master cannot be set if it is non-NULL. Therefore, it stays as
  is unless a file drops it.

  If minor->master is NULL, it is only set by places that also adjust
  drm_file->is_master.

Therefore, we can safely drop is_master and replace it by an inline helper
that matches:
    drm_file->master && drm_file->master == drm_file->minor->master

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm: extract legacy ctxbitmap flushing

The ctxbitmap code is only used by legacy drivers so lets try to keep it
as separated as possible. Furthermore, the locking is non-obvious and
kinda weird with ctxlist_mutex *and* struct_mutex. Keeping all ctxbitmap
access in one file is much easier to review and makes drm_release() more
readable.

Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>

drm/radeon: Use pflip irqs for pageflip completion if possible. (v2)

Skip the "manual" pageflip completion checks via polling and
guessing in the vblank handler radeon_crtc_handle_vblank() on
asics which are known to reliably support hw pageflip completion
irqs. Those pflip irqs are a more reliable and race-free method
of handling pageflip completion detection, whereas the "classic"
polling method has some small races in combination with dpm on,
and with the reworked pageflip implementation since Linux 3.16.

On old asics without pflip irqs, the classic method is used.

On asics with known good pflip irqs, only pflip irqs are used
by default, but a new module parameter "use_pflipirqs" allows to
override this in case we encounter asics in the wild with
unreliable or faulty pflip irqs. A module parameter of 0 allows
to use the classic method only in such a case. A parameter of 1
allows to use both classic method and pflip irqs as additional
band-aid to avoid some small races which could happen with the
classic method alone. The setting 1 gives Linux 3.16 behaviour.

Hw pflip irqs are available since R600.

Tested on DCE-4, AMD Cedar - FirePro 2270.

v2:  agd5f: only enable pflip interrupts on DCE4+ as they are not
reliable on older asics.

Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: tweak ACCEL_WORKING2 query for the new firmware for hawaii

Adjust the previous tweak for hawaii to return 3 if the new firmware is used.

Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: use packet3 for nop on hawaii with new firmware

Older firmware didn't support the new nop packet.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>

drm/radeon: tweak ACCEL_WORKING2 query for hawaii

Return 2 so we can be sure the kernel has the necessary
changes for acceleration to work.

Note: This patch depends on these two commits:
 - drm/radeon: fix cut and paste issue for hawaii.
 - drm/radeon: use packet2 for nop on hawaii with old firmware

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Cc: stable@vger.kernel.org

drm/radeon: use packet2 for nop on hawaii with old firmware

Older firmware didn't support the new nop packet.

v2 (Andreas Boll):
 - Drop usage of packet3 for new firmware

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com> (v1)
Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com>
Cc: stable@vger.kernel.org

drm/radeon: update IB size estimation for VM

That should allow us to allocate bigger BOs.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: split PT setup in more functions

Move the decision what to use into the common VM code.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add VM GART copy optimization to NI as well

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: take a BO reference on VM cleanup

This closes a small window where the GPU might have accessed freed up memory.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add radeon_bo_ref function

To be consistent with radeon_bo_unref, needed in the following patch.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: remove taking mclk_lock from radeon_bo_unref

It's causing lockdep warnings and why should
we access the memory that is freed up?

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: adjust default radeon_vm_block_size v2

v2: rebase on vm_size scale change. Adjust vm_size default to 8,
    Better handle the default and smaller values.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: try to enable VM flushing once more

Let's try to fix bugs related to this instead of just disabling it.

Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: use an intervall tree to manage the VMA v2

Scales much better than scanning the address range linearly.

v2: store pfn instead of address

Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: remove radeon_bo_clear_va

Won't work anyway, instead WARN_ON if the VA list isn't
empty when we free the BO.

Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: invalidate moved BOs in the VM (v2)

Don't wait for the BO to be used again, just
update the PT on the next VM use.

v2: remove stray semicolon.

Signed-off-by: Christian König <christian.koenig@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: re-enable dpm by default on BTC

This patch depends on:
e07929810f0a19ddd756558290c7d72827cbfcd9
(drm/radeon/dpm: fix typo in vddci setup for eg/btc)

bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=73053
https://bugzilla.kernel.org/show_bug.cgi?id=68571

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: re-enable dpm by default on cayman

This patch depends on:
b0880e87c1fd038b84498944f52e52c3e86ebe59
(drm/radeon/dpm: fix vddci setup typo on cayman)

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=69723

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: Only flush HDP cache from idle ioctl if BO is in VRAM

The HDP cache only applies to CPU access to VRAM.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/dpm: handle voltage info fetching on hawaii

Some hawaii cards use a different method to fetch the
voltage info from the vbios.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=74250

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon/atom: add new voltage fetch function for hawaii

Some hawaii boards use a different method for fetching the
voltage information from the vbios.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: Always flush the HDP cache before submitting a CS to the GPU

This ensures the GPU sees all previous CPU writes to VRAM, which makes it
safe:

* For userspace to stream data from CPU to GPU via VRAM instead of GTT
* For IBs to be stored in VRAM instead of GTT
* For ring buffers to be stored in VRAM instead of GTT, if the HPD flush
  is performed via MMIO

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: s/ioctl_wait_idle/mmio_hpd_flush/

And clean up the function comment a little.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: separate ring and IB handling

Both on their own are complex enough.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix reversed logic in evergreen_mc_resume

Need to unblank the display when resuming the MC.  No
functional change as this code path is not currently
hit.  We always disable the displays entirely rather
than just blanking them.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: set VM base addr using the PFP v2

Seems to make VM flushes more stable on SI and CIK.

v2: only use the PFP on the GFX ring on CIK

Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/cik: Read back SDMA WPTR register after writing it

For symmetry with other *_set_wptr hooks.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Use write-combined CPU mappings of IBs on >= CIK

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Use write-combined CPU mappings of ring buffers with PCIe

PCI GART doesn't support unsnooped access. AGP GART already uses
write-combined CPU mappings.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: load the lm63 driver for an lm64 thermal chip.

Looks like the lm63 driver supports the lm64 as well.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: make radeon_connector_encoder_is_hbr2 static

It's only used in radeon_connectors.c.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add trace_radeon_vm_flush

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: fix R600_PTE_GART handling

That didn't worked correctly any more and opened up a security problem.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: remove discardable flag from radeon_gem_object_create

Unused and unimplemented. Also fix specifying the
kernel flag incorrectly at one occasion.

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add a PX quirk list

Some PX laptops seems to have problems turning the dGPU on/off.
Add a quirk list to disable runpm by default on those systems.
Also convert the current PX d3 delay handling to a quirk.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=51381
https://bugzilla.kernel.org/show_bug.cgi?id=74551

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: remove visible vram size limit on bo allocation (v4)

Now that fallback to gtt is fixed for cpu access, we can
remove this limit.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78717

v2: use new gart_pin_size to accurately track available gtt.
v3: fix comment
v4: clarify comment

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

drm/radeon: use vram/gart pinned size in radeon_do_test_moves

Gives more accurate count and prevents failures when we can't
allocate memory for the tests.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

drm/radeon: use vram/gart pinned size in radeon_gem_info_ioctl

Gives a more accurate limit than the previous code.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

drm/radeon: track pinned memory (v2)

So we know how large an allocation we can allow.

v2: incorporate Michel's comments

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>

drm/radeon: Allow write-combined CPU mappings of BOs in GTT (v2)

v2: fix rebase onto drm-fixes

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Pass GART page flags to radeon_gart_set_page() explicitly

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Remove radeon_gart_restore()

Doesn't seem necessary, the GART table memory should be persistent.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Demote 'BO allocation size too large' message to debug only

These clutter up dmesg during piglit runs. Userspace generally deals
gracefully with this failure.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: use a fetch function to get the edid

We keep a cached version of the edid in radeon_connector which
we use for determining connectedness and when to enable certain
features like hdmi audio, etc.  When the user uses the firmware
interface to override the driver with some other edid the driver's
copy is never updated.  The fetch function will check if there
is a user supplied edid and update the driver's copy if there
is.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80691

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: restructure edid fetching

Split radeon_ddc_get_modes() and move it into
radeon_connectors.c since that is the only place
that uses it.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/audio: break out of loops once we match connector

No need to continue with the loops once we've matched
the appropriate connector.
See commit 8a992ee14551eae53fd3ab6c2dc8e06ba6fff174

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Use correct value for unknown audio/video latency

Valid values are 1 to 251 for 0 to 500 ms latency, 0 for unknown
and 255 for audio/video unsupported by sink, according to HDMI 1.3 spec.
Also matches Radeon HDA verb 0xf7b documentation.

Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: Inline r100_mm_rreg, -wreg, v3

This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, a first attempt at inlining it grew radeon.ko by 7%.

However, 2% of cpu is spent in this function. Simply inlining it gave 1% more fps
in Urban Terror.

v2: We know the minimum MMIO size. Adding it to the if allows the compiler to
optimize the branch out, improving both performance and size.

The v2 patch decreases radeon.ko size by 2%. I didn't re-benchmark, but common sense
says perf is now more than 1% better.

v3: Also change _wreg, make the threshold a define.

Inlining _wreg increased the size a bit compared to v2, so now radeon.ko
is only 1% smaller.

Signed-off-by: Lauri Kasanen <cand@gmx.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: consolidate vga and dvi get_modes functions (v2)

They are identical.

v2: rebase

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: enable display scaling on all connectors (v2)

This enables the display scaler on all connectors for r5xx
and newer asics.  Previously we only enabled the scaler for
fixed mode displays (eDP or LVDS) since they have to use the
scaler to support non-native modes.  Most other displays
are multi-sync or have a built in scaler to support non-native
modes.  The default scaling mode for non-fixed displays is
none which will use the scaler in the monitor.  Note that
we do not populate any fake modes like we do for fixed
displays so it will only use the modes in the edid.  For
other modes, you'll need to populate them manually.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=80868

v2: properly handle scaling with no modes defined

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: remove null test before kfree

Fix checkpatch warning:
WARNING: kfree(NULL) is safe this check is probably not required

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/cik: Add support for new ucode format (v5)

This adds CIK support for the new ucode format.

v2: add size validation, integrate debug info
v3: add support for MEC2 on KV
v4: fix typos
v4: update to latest format

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/si: Add support for new ucode format (v3)

This adds SI support for the new ucode format.

v2: add size validation, integrate debug info
v3: update to latest version

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: add new firmware header definitions (v3)

These are needed to properly handle more frequently
updated firmware.

v2: add new firmware helper functions as well.
v3: update to latest format

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon: disable gfx cgcg on cik

This needs some tweaking to be stable with newer
ucode versions.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/radeon/dpm: add support for SVI2 voltage for SI

Some newer boards use SVI2 for voltage control rather
than GPIO.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm: Fix race when checking for fb in the generic kms obj lookup

In my review of

commit 98f75de40e9d83c3a90d294b8fd25fa2874212a9
Author: Rob Clark <robdclark@gmail.com>
Date:   Fri May 30 11:37:03 2014 -0400

    drm: add object property typ

I asked for a check to make sure that we never leak an fb from the
generic mode object lookup since those have completely different
lifetime rules. Rob added it, but outside of the idr mutex, which
means that our dereference of obj->type can already chase free'd
memory.

Somehow I didn't spot this, so fix this asap.

v2: Simplify the conditionals as suggested by Chris.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Unlink dead file_priv from list of active files first

In order to prevent external observers walking the list of open DRM
files from seeing an invalid drm_file_private in the process of being
torndown, the first operation we need to take is to unlink the
drm_file_private from that list.

general protection fault: 0000 [#1] PREEMPT SMP
Modules linked in: i915 i2c_algo_bit drm_kms_helper drm lpc_ich mfd_core nls_iso8859_1 i2c_hid video hid_generic usbhid hid e1000e ahci ptp libahci pps_core
CPU: 3 PID: 8220 Comm: cat Not tainted 3.16.0-rc6+ #4
Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0119.R00.1303230105 03/23/2013
task: ffff8800219642c0 ti: ffff880047024000 task.ti: ffff880047024000
RIP: 0010:[<ffffffffa0137c70>]  [<ffffffffa0137c70>] per_file_stats+0x110/0x160 [i915]
RSP: 0018:ffff880047027d48  EFLAGS: 00010246
RAX: 6b6b6b6b6b6b6b6b RBX: ffff880047027e30 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff88003a05cd00
RBP: ffff880047027d58 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8800219642c0 R11: 0000000000000000 R12: ffff88003a05cd00
R13: 0000000000000000 R14: ffff88003a05cd00 R15: ffff880047027d88
FS:  00007f5f73a13740(0000) GS:ffff88014e380000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000023ff038 CR3: 0000000021a4b000 CR4: 00000000001407e0
Stack:
 0000000000000001 000000000000ffff ffff880047027dc8 ffffffff813438e4
 ffff880047027e30 ffffffffa0137b60 ffff880021a8af58 ffff880021a8f1a0
 ffff8800a2061fb0 ffff8800a2062048 ffff8800a2061fb0 ffff8800a1e23478
Call Trace:
 [<ffffffff813438e4>] idr_for_each+0xf4/0x180
 [<ffffffffa0137b60>] ? i915_gem_stolen_list_info+0x1f0/0x1f0 [i915]
 [<ffffffffa013a17a>] i915_gem_object_info+0x5ca/0x6a0 [i915]
 [<ffffffff81193ec5>] seq_read+0xf5/0x3a0
 [<ffffffff8116d950>] vfs_read+0x90/0x150
 [<ffffffff8116e509>] SyS_read+0x49/0xb0
 [<ffffffff815d8622>] tracesys+0xd0/0xd5
Code: 01 00 00 49 39 84 24 08 01 00 00 74 55 49 8b 84 24 b8 00 00 00 48 01 43 18 31 c0 5b 41 5c 5d c3 0f 1f 00 49 8b 44 24 08 4c 89 e7 <48> 8b 70 28 48 81 c6 48 80 00 00 e8 80 14 01 00 84 c0 74 bc 49
RIP  [<ffffffffa0137c70>] per_file_stats+0x110/0x160 [i915]
RSP <ffff880047027d48>

Reported-by: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81712
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: Pass GFP flags in order to avoid deadlock.

Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added
deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free()
are currently doing GFP_KERNEL allocation.

But these functions did not get updated to receive gfp_t argument.
This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions,
and removes the deadlock warning.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: Fix possible stack overflow by recursive shrinker calls.

While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL
allocation, ttm_pool_shrink_scan() does not do it. This can result in stack
overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to
memory pressure.

  shrink_slab()
  => ttm_pool_shrink_scan()
     => ttm_page_pool_free()
        => kmalloc(GFP_KERNEL)
           => shrink_slab()
              => ttm_pool_shrink_scan()
                 => ttm_page_pool_free()
                    => kmalloc(GFP_KERNEL)

Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [2.6.35+]
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.

I can observe that RHEL7 environment stalls with 100% CPU usage when a
certain type of memory pressure is given. While the shrinker functions
are called by shrink_slab() before the OOM killer is triggered, the stall
lasts for many minutes.

One of reasons of this stall is that
ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and
are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with
_manager->lock held causes someone (including kswapd) to deadlock when
these functions are called due to memory pressure. This patch changes
"mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to
avoid deadlock.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan().

We can use "unsigned int" instead of "atomic_t" by updating start_pool
variable under _manager->lock. This patch will make it possible to avoid
skipping when choosing a pool to shrink in round-robin style, after next
patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork).

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan().

list_empty(&_manager->pools) being false before taking _manager->lock
does not guarantee that _manager->npools != 0 after taking _manager->lock
because _manager->npools is updated under _manager->lock.

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.3+]
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/tda998x: update for new drm connector APIs.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/sti: fix warning in build.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

This series of patches add the support of DRM/KMS drivers for STMicroelectronics
chipsets stih416 and stih407.

Hardware is split in two main blocks: Compositor and TVout. Each of them
includes specific hardware IPs and the display timing are controlled by a specific
Video Timing Generator hardware IP (VTG).

Compositor is made of the follow hardware IPs:
 - GDP (Generic Display Pipeline) which is an entry point for graphic (RGB)
   buffers
 - VDP (Video Diplay Pipeline) which is an entry point for video (YUV) buffers
 - HQVDP (High Quality Video Display Processor) that supports scaling,
   deinterlacing and some miscellaneous image quality improvements.
   It fetches the Video decoded buffers from memory, processes them and pushes
   them to the Compositor through a HW dedicated bus.
 - Mixer is responsible of mixing all the entries depending of their
   respective z-order and layout

TVout is divided in 3 parts:
 - HDMI to generate HDMI signals, depending of chipset version HDMI phy can
   change.
 - HDA to generate signals for HD analog TV
 - VIP to control/switch data path coming from Compositor

On stih416 compositor and Tvout are on different dies so a Video Trafic Advance
inter-die Communication mechanism (VTAC) is needed.

+---------------------------------------------+   +----------------------------------------+
| +-------------------------------+   +----+  |   |  +----+   +--------------------------+ |
| |                               |   |    |  |   |  |    |   |  +---------+     +----+  | |
| | +----+              +------+  |   |    |  |   |  |    |   |  | VIP     |---->|HDMI|  | |
| | |GPD +------------->|      |  |   |    |  |   |  |    |   |  |         |     +----+  | |
| | +----+              |Mixer |--|-->|    |  |   |  |    |---|->| switcher|             | |
| |                     |      |  |   |    |  |   |  |    |   |  |         |     +----+  | |
| |                     |      |  |   |    |  |   |  |    |   |  |         |---->|HDA |  | |
| |                     +------+  |   |VTAC|========>|VTAC|   |  +---------+     +----+  | |
| |                               |   |    |  |   |  |    |   |                          | |
| |         Compositor            |   |    |  |   |  |    |   |           TVout          | |
| +-------------------------------+   |    |  |   |  |    |   +--------------------------+ |
|                      ^              |    |  |   |  |    |             ^                  |
|                      |              |    |  |   |  |    |             |                  |
|               +--------------+      |    |  |   |  |    |      +-------------+           |
|               | VTG (master) |----->|    |  |   |  |    |----->| VTG (slave) |           |
|               +--------------+      +----+  |   |  +----+      +-------------+           |
|Digital die                                  |   |                              Analog Die|
+---------------------------------------------+   +----------------------------------------+

On stih407 Compositor and Tvout are on the same die

+-----------------------------------------------------------------+
| +-------------------------------+  +--------------------------+ |
| |                               |  |  +---------+     +----+  | |
| | +----+              +------+  |  |  | VIP     |---->|HDMI|  | |
| | |GPD +------------->|      |  |  |  |         |     +----+  | |
| | +----+              |Mixer |--|--|->| switcher|             | |
| | +----+   +-----+    |      |  |  |  |         |     +----+  | |
| | |VDP +-->+HQVDP+--->|      |  |  |  |         |---->|HDA |  | |
| | +----+   +-----+    +------+  |  |  +---------+     +----+  | |
| |                               |  |                          | |
| |         Compositor            |  |           TVout          | |
| +-------------------------------+  +--------------------------+ |
|                              ^        ^                         |
|                              |        |                         |
|                           +--------------+                      |
|                           |     VTG      |                      |
|                           +--------------+                      |
|Digital die                                                      |
+-----------------------------------------------------------------+

In addition of the drivers for the IPs listed before a thin I2C driver (hdmiddc) is used
by HDMI driver to retrieve EDID for monitor.

To unify interfaces of GDP and VDP we create a "layer" interface called by
compositor to control both GPD and VDP.

Hardware have memory contraints (alignment, contiguous) so we use CMA drm helpers functions
to allocate frame buffer.

File naming convention is:
 - sti_* for IPs drivers
 - sti_drm_* for drm functions implementation.

* 'drm_kms_for_next-v8' of git://git.linaro.org/people/benjamin.gaignard/kernel:
  drm: sti: Add DRM driver itself
  drm: sti: add Compositor
  drm: sti: add Mixer
  drm: sti: add VID layer
  drm: sti: add GDP layer
  drm: sti: add TVOut driver
  drm: sti: add HDA driver
  drm: sti: add HDMI driver
  drm: sti: add VTAC drivers
  drm: sti: add VTG driver
  drm: sti: add bindings for DRM driver

Merge branch 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-next

This builds upon the previous set of fixes which were pulled on 6th July.
Included in this set are:
- an update from Jean-Francois to add the missing reg documentation entry
  to the device tree documentation.
- conversion of the tda998x driver to the component helpers.

* 'tda998x-devel' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox:
  drm/i2c: tda998x: add component support
  drm/i2c: tda998x: allow re-use of tda998x support code
  drm/i2c: tda998x: fix lack of required reg in DT documentation

Conflicts:
drivers/gpu/drm/i2c/tda998x_drv.c