Creates a function that given an sync file descriptor returns a
fence containing all fences in the sync_file.

v2: Comments by Daniel Vetter
	- Adapt to new version of fence_collection_init()
	- Hold a reference for the fence we return

v3:
	- Adapt to use fput() directly
	- rename to sync_file_get_fence() as we always return one fence

v4: Adapt to use fence_array

v5: set fence through fence_get()
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>

Create sync_file->fence to abstract the type of fence we are using for
each sync_file. If only one fence is present we use a normal struct fence
but if there is more fences to be added to the sync_file a fence_array
is created.

This change cleans up sync_file a bit. We don't need to have sync_file_cb
array anymore. Instead, as we always have  one fence, only one fence
callback is registered per sync_file.

v2: Comments from Chris Wilson and Christian König
	- Not using fence_ops anymore
	- fence_is_array() was created to differentiate fence from fence_array
	- fence_array_teardown() is now exported and used under fence_is_array()
	- struct sync_file lost num_fences member

v3: Comments from Chris Wilson and Christian König
	- struct sync_file lost status member in favor of fence_is_signaled()
	- drop use of fence_array_teardown()
	- use sizeof(*fence) to allocate only an array on fence pointers

v4: Comments from Chris Wilson
	- use sizeof(*fence) to reallocate array
	- fix typo in comments
	- protect num_fences sum against overflows
	- use array->base instead of casting the to struct fence

v5: fixes checkpatch warnings

v6: fix case where all fences are signaled.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NChristian König <christian.koenig@amd.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>

Add helper to check if fence is array.

v2: Comments from Chris Wilson
	- remove ternary if from ops comparison
	- add EXPORT_SYMBOL(fence_array_ops)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christian König <christian.koenig@amd.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>

Timeouts can be errors, but timeouts are also usually normal behavior
and happen a lot. Since the kernel already lets us know when we're
suppressing messages due to rate limiting, rate limit timeout errors so
we don't make too much noise in the kernel log.
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470443443-27252-8-git-send-email-cpaul@redhat.com

Since we always retry in drm_dp_dpcd_access() regardless of the error,
we're going to make a lot of noise if the aux->transfer function prints
it's own errors (as is the case with radeon). If we can print the error
code here, this reduces the need for drivers to do this. So instead of
having to print "dp_aux_ch timed out" over 32 times we can just print
once.
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470443443-27252-2-git-send-email-cpaul@redhat.com

There's a couple of places where this would be useful for drivers (such
as reporting DP aux transaction timeouts).
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470443443-27252-7-git-send-email-cpaul@redhat.com

Shouldn't be possible since everyone kzallocs this, but better safe
than sorry. Random drive-by-idea really.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NRodrigo Vivi <rdorigo.vivi@intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470673493-14304-1-git-send-email-daniel.vetter@ffwll.ch

To properly implement atomic w/ runtime pm, we move
drm_atomic_helper_commit_modeset_enables() above
drm_atomic_helper_commit_planes() to ensure CRTCs are enabled before
modifying plane registers, and set active_only to true to filter out
plane update notifications when the CRTC is disabled.

According to the document from linux kernel:
Set the active_only parameters to true in order not to receive plane
update notifications related to a disabled CRTC. This avoids the need
to manually ignore plane updates in driver code when the driver and/or
hardware can't or just don't need to deal with updates on disabled
CRTCs, for example when supporting runtime PM.
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470279597-60453-8-git-send-email-bibby.hsieh@mediatek.com

Use the framebuffer's format to compute its cpp, and use it when
calculating the address shift value.
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470279597-60453-7-git-send-email-bibby.hsieh@mediatek.com

The mtk_plane_enable is just called once by mtk_plane_atomic_update.
So, merge mtk_plane_enable into mtk_plane_atomic_update.

While we are here, also clean up the function a bit by using an fb local
variables.
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470279597-60453-6-git-send-email-bibby.hsieh@mediatek.com

Use the core destroy_state helpers to destroy core state to ensure we don't
leak if/when more fields get added later.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470279597-60453-5-git-send-email-bibby.hsieh@mediatek.com

Now that mtk_drm_plane just contains its base struct drm_plane, we can
just remove it and use struct drm_plane everywhere.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470279597-60453-4-git-send-email-bibby.hsieh@mediatek.com

It is not actually useful to a mtk plane to know its zpos/index, so just
remove this field.

This let's completely remove struct mtk_drm_plane in a follow up patch.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470279597-60453-3-git-send-email-bibby.hsieh@mediatek.com

This function no longer exists.
Signed-off-by: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470279597-60453-2-git-send-email-bibby.hsieh@mediatek.com

Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.

I don't see any actual users of drm_simple_kms_helper yet, so
no actual plane clipping bugs to fix.

Cc: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-10-git-send-email-ville.syrjala@linux.intel.com

Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.

This also eliminates the double clipping the driver was doing
in both check and commit phases). And it should fix src coordinate
addr adjustement. Previously the driver was expecting negative dst
coordinates after clipping, which is not going happen, so any clipping
induced addr adjustment simply didn't happen. Neither did the driver
respect any user configured src coordinates, so panning and such would
have been totally broken. It should be all good now.

Cc: CK Hu <ck.hu@mediatek.com>
Cc: linux-mediatek@lists.infradead.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Tested-by: NBibby Hsieh <bibby.hsieh@mediatek.com>
Acked-by: NCK Hu <ck.hu@mediatek.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-9-git-send-email-ville.syrjala@linux.intel.com

Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.

Rockchip looks to handling plane clipping rather well already
(unlikje most arm drm drivers) so there are no function changes
here.

Cc: Yao <mark.yao@rock-chips.com>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-8-git-send-email-ville.syrjala@linux.intel.com

Replace the private drm_rects in vop_plane_state with
the ones now living in drm_plane_state.

Cc: Yao <mark.yao@rock-chips.com>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NMark Yao <mark.yao@rock-chips.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-7-git-send-email-ville.syrjala@linux.intel.com

Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-6-git-send-email-ville.syrjala@linux.intel.com

Replace the private drm_rects/flags in intel_plane_state
with the ones now living in drm_plane_state.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-5-git-send-email-ville.syrjala@linux.intel.com

Add a version of drm_plane_helper_check_update() which takes a plane
state instead of having the caller pass in everything.

And to reduce code duplication, let's reimplement
drm_plane_helper_check_update() in terms of the new function, by
having a tempororary plane state on the stack.

v2: Add a note that the functions modifies the state (Chris)
v3: Fix drm_plane_helper_check_update() y coordinates (Daniel Kurtz)

Cc: Daniel Kurtz <djkurtz@chromium.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org> (v2)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1470642910-14073-1-git-send-email-ville.syrjala@linux.intel.com

Pretty much all driver will have need for the clipped plane
coordinates, so let's stuff then into drm_plane_state.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-3-git-send-email-ville.syrjala@linux.intel.com

Passing negative width/hight to scale factor calculations is not
legal. Let's WARN if that happens.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469549224-1860-2-git-send-email-ville.syrjala@linux.intel.com

Only property creation uses the rotation as an index, so convert the
to figure the index when needed.

v2: Use the new defines to build the _MASK defines (Sean)

Cc: intel-gfx@lists.freedesktop.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: malidp@foss.arm.com
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1469771405-17653-1-git-send-email-joonas.lahtinen@linux.intel.com

When reconfiguring a plane position (as in moving the cursor), the
frame buffer for the cursor isn't changing, so don't call the prepare
or cleanup driver functions.

This avoids making cursor position updates block on all pending rendering.

v3: use drm_atomic_helper_framebuffer_changed in both prepare and
    cleanup phases instead of keeping state in the plane.

cc: dri-devel@lists.freedesktop.org
cc: David Airlie <airlied@linux.ie>
cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NKeith Packard <keithp@keithp.com>
[danvet: Rebase onto 4.8]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Except for nouveau, only legacy drivers need this really. And nouveau
is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special
case.

I've tried to be careful to leave everything related to modeset still
using the DRIVER_MODESET flag. Otherwise it's a direct replacement of
!DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability
since fewer negative checks overall.
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NFrank Binns <frank.binns@imgtec.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch

It's super confusing that new drivers need to be marked with
DRIVER_MODESET when really it means DRIVER_MODERN. Much better to
invert the meaning and rename it to something that's suitably
off-putting.

Since there's over 100 places using DRIVER_MODESET we need to roll out
this change without a flag day.

v2: Update docs.
Reviewed-by: NFrank Binns <frank.binns@imgtec.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-1-git-send-email-daniel.vetter@ffwll.ch

At a higher level, all objects are created with definite size i.e. 0 is
illegal. In forthcoming patches, this assumption is dependent upon in
the drm_mm range manager, i.e. trying to create a drm_mm node with size
0 will have undefined behaviour. Add a couple of WARNs upon creating the
drm_mm node to prevent later bugs.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470248788-30873-1-git-send-email-chris@chris-wilson.co.uk

The minor referred to by "DRM_MINOR_LEGACY" is called 'dev->primary' and
gets 'cardX' as name assigned. Lets reduce this magnificent number of
names for the same concept by one and rename DRM_MINOR_LEGACY to
DRM_MINOR_PRIMARY (to match the actual struct-member name).

Furthermore, this is in no way a legacy node, so lets not call it that.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NFrank Binns <frank.binns@imgtec.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160803180432.1341-2-dh.herrmann@gmail.com

As we always add this to the drm_mm->hole_stack as our first operation,
we do not need to initialise the list node.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-3-git-send-email-chris@chris-wilson.co.uk

Having added an interval-tree to struct drm_mm, we can replace the
auxiliary rb-tree inside the drm_vma_manager with it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-2-git-send-email-chris@chris-wilson.co.uk

In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the number of nodes in the range manager as opposed to O(N).
Insertion however gains an extra O(lg(N)) step for all nodes
irrespective of whether the interval tree is in use. For future i915
patches, eliminating the linear walk is a significant improvement.

v2: Use generic interval-tree template for u64 and faster insertion.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-1-git-send-email-chris@chris-wilson.co.uk

It was really strange to see negative vblank seqs on debug
messages. It is rare to have that big number, but when it
happens it is confusing and misleading.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470243226-2750-1-git-send-email-rodrigo.vivi@intel.com

Pull more block fixes from Jens Axboe:
 "As mentioned in the pull the other day, a few more fixes for this
  round, all related to the bio op changes in this series.

  Two fixes, and then a cleanup, renaming bio->bi_rw to bio->bi_opf.  I
  wanted to do that change right after or right before -rc1, so that
  risk of conflict was reduced.  I just rebased the series on top of
  current master, and no new ->bi_rw usage has snuck in"

* 'for-linus' of git://git.kernel.dk/linux-block:
  block: rename bio bi_rw to bi_opf
  target: iblock_execute_sync_cache() should use bio_set_op_attrs()
  mm: make __swap_writepage() use bio_set_op_attrs()
  block/mm: make bdev_ops->rw_page() take a bool for read/write

Pull drm zpos property support from Dave Airlie:
 "This tree was waiting on some media stuff I hadn't had time to get a
  stable branchpoint off, so I just waited until it was all in your tree
  first.

  It's been around a bit on the list and shouldn't affect anything
  outside adding the generic API and moving some ARM drivers to using
  it"

* tag 'drm-for-v4.8-zpos' of git://people.freedesktop.org/~airlied/linux:
  drm: rcar: use generic code for managing zpos plane property
  drm/exynos: use generic code for managing zpos plane property
  drm: sti: use generic zpos for plane
  drm: add generic zpos property

Since commit 63a4cc24, bio->bi_rw contains flags in the lower
portion and the op code in the higher portions. This means that
old code that relies on manually setting bi_rw is most likely
going to be broken. Instead of letting that brokeness linger,
rename the member, to force old and out-of-tree code to break
at compile time instead of at runtime.

No intended functional changes in this commit.
Signed-off-by: NJens Axboe <axboe@fb.com>

The original commit missed this function, it needs to mark it a
write flush.

Cc: Mike Christie <mchristi@redhat.com>
Fixes: e742fc32 ("target: use bio op accessors")
Signed-off-by: NJens Axboe <axboe@fb.com>

Cleaner than manipulating bio->bi_rw flags directly.
Signed-off-by: NJens Axboe <axboe@fb.com>

Commit abf54548 changed it from an 'rw' flags type to the
newer ops based interface, but now we're effectively leaking
some bdev internals to the rest of the kernel. Since we only
care about whether it's a read or a write at that level, just
pass in a bool 'is_write' parameter instead.

Then we can also move op_is_write() and friends back under
CONFIG_BLOCK protection.
Reviewed-by: NMike Christie <mchristi@redhat.com>
Signed-off-by: NJens Axboe <axboe@fb.com>