If we being polled with a timeout of zero, a nonblocking busy query,
we don't need to install any fence callbacks as we will not be waiting.
As we only install the callback once, the overhead comes from the atomic
bit test that also causes serialisation between threads.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829181613.30722-1-chris@chris-wilson.co.uk

If userspace is running an synchronously atomic commit and interrupts the
atomic operation during fence_wait() it will hang until the timer expires,
so here we change the wait to be interruptible so it stop immediately when
userspace wants to quit.

Also adds the necessary error checking for fence_wait().

v2: Comment by Daniel Vetter
	- Add error checking for fence_wait()

v3: Rebase on top of new atomic noblocking support

v4: Comment by Maarten Lankhorst
	- remove 'swapped' bitfield as it was duplicating information

v5: Comments by Maarten Lankhorst
	- assign plane->state to plane_state if !intr
	- squash previous patch into this one

v6: Comment by Sean Paul
	- rename intr to pre_swap
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[seanpaul fixed a couple checkpatch warnings and moved the preswap comment]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473707291-14781-1-git-send-email-gustavo@padovan.org

Property lifetimes are equal to the device lifetime, so the separate
drm_property_find is not needed. The pointer can be retrieved from
the properties member, which saves us some locking and a extra lookup.
The lifetime for properties is until the device is destroyed, which
happens late in the device unload path.

kms_atomic is also testing for invalid properties which returns -ENOENT,
to be consistent return -ENOENT for valid properties that don't appear
on the object property list.

Changes since v1:
- Return -ENOENT for invalid properties to make kms_atomic pass.
- Change commit message slightly to take this into account.

Testcase: kms_atomic
Testcase: kms_properties
Fixes: 4e9951d9 ("drm/atomic: Reject properties not part of the object.")
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/599c7fa8-b6fd-a42b-c619-a9e4a9c5c244@linux.intel.com

The Renesas Wheat board has 2 ADV7513 chips on the same I2C bus, however
the ADV751x driver only supports 1 chip as it tries to assign the packet/
EDID/CEC memory I2C devices to the fixed I2C addresses. Assign these I2C
addresses at the fixed offsets (derived from the programming guide) from
the main register map address instead.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1580212.O1LYdJFM97@wasted.cogentembedded.com

This fixes the error path for platforms that don't define the new
page_flip_target() hook.

Fixes: c229bfbb ("drm: Add page_flip_target CRTC hook v2")
Testcase: igt/kms_flip/basic-flip-vs-dpms
CC: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473269025-16148-1-git-send-email-imre.deak@intel.com

This reverts commit 77953bd1.

This causes a kernel panic when trying to assign a blob to a property,
and has obviously never been tested.

Fixes: 77953bd1 ("drm: Unify handling of blob and object properties")
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: NLiu Ying <gnuiyl@gmail.com>
Acked-by: NDaniel Stone <daniels@collabora.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/8c0d3482-1bb5-6a15-b105-6bda2b31b5dc@linux.intel.com

The usb_driver suspend and resume function pointers must be populated
to prevent forced unbinding of USB interface driver. See usb/core/driver.c:
unbind_no_pm_drivers_interfaces().

Restore mode and damage the entire frame buffer upon resume.

TEST=suspend and resume with the same UDL device connected
TEST=suspend with UDL, unplug UDL and resume
TEST=suspend with UDL, unplug and connect another UDL device then resume
Signed-off-by: NHaixia Shi <hshi@chromium.org>
Reviewed-by: NStéphane Marchesin <marcheu@chromium.org>
[seanpaul fixed checkpatch warnings and gave marcheu his é back]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1472593821-38429-2-git-send-email-hshi@chromium.org

Use 1UL for unsigned long, or we'll meet a overflow issue with UBSAN.

[   15.589489] UBSAN: Undefined behaviour in drivers/gpu/drm/drm_hashtab.c:145:35
[   15.589500] signed integer overflow:
[   15.589999] -2147483648 - 1 cannot be represented in type 'int'
[   15.590434] CPU: 2 PID: 294 Comm: plymouthd Not tainted 3.10.0-327.28.3.el7.x86_64 #1
[   15.590653] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 01/07/2011
[   15.591001]  1ffff1000670fe83 000000000d6b385e ffff88003387f3e0 ffffffff81ee3140
[   15.591028]  ffff88003387f3f8 ffffffff81ee31fd ffffffffa032f460 ffff88003387f560
[   15.591044]  ffffffff81ee46e2 0000002d00000009 0000000000000001 0000000041b58ab3
[   15.591059] Call Trace:
[   15.591078]  [<ffffffff81ee3140>] dump_stack+0x1e/0x20
[   15.591093]  [<ffffffff81ee31fd>] ubsan_epilogue+0x12/0x55
[   15.591109]  [<ffffffff81ee46e2>] handle_overflow+0x1ba/0x215
[   15.591126]  [<ffffffff81ee4528>] ? __ubsan_handle_negate_overflow+0x162/0x162
[   15.591146]  [<ffffffff8103416c>] ? print_context_stack+0x9c/0x160
[   15.591163]  [<ffffffff81031df2>] ? dump_trace+0x252/0x750
[   15.591181]  [<ffffffff81739023>] ? __list_add+0x93/0x160
[   15.591197]  [<ffffffff81ee4798>] __ubsan_handle_sub_overflow+0x2a/0x31
[   15.591261]  [<ffffffffa0282140>] drm_ht_just_insert_please+0x1e0/0x200 [drm]
[   15.591290]  [<ffffffffa0528c7a>] ttm_base_object_init+0x10a/0x270 [ttm]
[   15.591316]  [<ffffffffa052a34c>] ttm_vt_lock+0x28c/0x3a0 [ttm]
[   15.591343]  [<ffffffffa052a0c0>] ? ttm_write_lock+0x180/0x180 [ttm]
[   15.591362]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591379]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591396]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591413]  [<ffffffff81419526>] ? kasan_unpoison_shadow+0x36/0x50
[   15.591442]  [<ffffffffa061cbe1>] vmw_master_set+0x121/0x470 [vmwgfx]
[   15.591459]  [<ffffffff811773a5>] ? __init_waitqueue_head+0x45/0x70
[   15.591487]  [<ffffffffa061cac0>] ? vmw_master_drop+0x310/0x310 [vmwgfx]
[   15.591535]  [<ffffffffa026946a>] drm_open+0x92a/0xc00 [drm]
[   15.591563]  [<ffffffffa0619ff0>] ? vmw_driver_open+0x170/0x170 [vmwgfx]
[   15.591610]  [<ffffffffa0268b40>] ? drm_poll+0xe0/0xe0 [drm]
[   15.591661]  [<ffffffffa02797b4>] drm_stub_open+0x224/0x330 [drm]
[   15.591711]  [<ffffffffa0279590>] ? drm_minor_acquire+0x240/0x240 [drm]
[   15.591727]  [<ffffffff8145fa8a>] chrdev_open+0x1fa/0x3f0
[   15.591742]  [<ffffffff8145f890>] ? cdev_put+0x50/0x50
[   15.591761]  [<ffffffff814f6dc3>] ? __fsnotify_parent+0x53/0x210
[   15.591778]  [<ffffffff8144fde1>] do_dentry_open+0x351/0x670
[   15.591792]  [<ffffffff8145f890>] ? cdev_put+0x50/0x50
[   15.591807]  [<ffffffff814503c2>] vfs_open+0xa2/0x170
[   15.591824]  [<ffffffff8147b5df>] do_last+0xccf/0x2c80
[   15.591842]  [<ffffffff8147a910>] ? filename_create+0x320/0x320
[   15.591858]  [<ffffffff81472549>] ? path_init+0x1b9/0xa90
[   15.591875]  [<ffffffff81472390>] ? mountpoint_last+0x9a0/0x9a0
[   15.591894]  [<ffffffff815f9ccf>] ? selinux_file_alloc_security+0xcf/0x130
[   15.591911]  [<ffffffff8147d777>] path_openat+0x1e7/0xcc0
[   15.591927]  [<ffffffff81031df2>] ? dump_trace+0x252/0x750
[   15.591943]  [<ffffffff8147d590>] ? do_last+0x2c80/0x2c80
[   15.591959]  [<ffffffff81739023>] ? __list_add+0x93/0x160
[   15.591974]  [<ffffffff8104b48d>] ? save_stack_trace+0x7d/0xb0
[   15.591989]  [<ffffffff81480824>] do_filp_open+0xa4/0x160
[   15.592004]  [<ffffffff81480780>] ? user_path_mountpoint_at+0x50/0x50
[   15.592022]  [<ffffffff8149d755>] ? __alloc_fd+0x175/0x300
[   15.592039]  [<ffffffff81453127>] do_sys_open+0x1b7/0x3f0
[   15.592054]  [<ffffffff81452f70>] ? filp_open+0x80/0x80
[   15.592070]  [<ffffffff81453392>] SyS_open+0x32/0x40
[   15.592088]  [<ffffffff81f08989>] system_call_fastpath+0x16/0x1b
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>
[seanpaul tweaked subject to remove "gpu/"]
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473152138-25335-1-git-send-email-xiexiuqi@huawei.com

The legacy setprop ioctl doesn't attempt to set properties
that are not enumerated on the object. The atomic ioctl does,
fix this by validating first.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1473062773-5045-1-git-send-email-maarten.lankhorst@linux.intel.com

This reverts commit d10571fc.

This isn't how we get to do this unfortunately.
Signed-off-by: NDave Airlie <airlied@redhat.com>

drm_kms_helper_poll_enable_locked() should check if we have delayed event
pending and if we have, schedule the work to run without delay.

Currently the output_poll_work is only scheduled if any of the connectors
have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with
DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event
already registered to be handled. The detection will be delayd by
DRM_OUTPUT_POLL_PERIOD in any case.
Furthermore if none of the connectors are marked as POLL_CONNECT or
POLL_DISCONNECT because all connectors are either POLL_HPD or they are
always connected: the output_poll_work will not run at all even if we
have delayed event marked.

When none of the connectors require polling, their initial status change
from unknown to connected/disconnected is not going to be handled until
the first kms application starts or if we have fb console enabled.

Note that in general the output poll work should be enabled already
when this happens, but at driver load usually the first probe happens
before the output polling is enabled. This patch fixes this case.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
[danvet: Note when exactly this is an issue, since the probe code
schedules the poll work itself already.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160831110905.31289-1-peter.ujfalusi@ti.com

Colorspace and scan information values were being written in wrong
offsets. This patch corrects this and writes the values at the
offsets specified in the databook.
Signed-off-by: NJose Abreu <joabreu@synopsys.com>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/96fd0f06b7ebc2ee5cb8239a99648f3107e24497.1471530573.git.joabreu@synopsys.com

- remove kerneldoc for drm-internal functions
- drm_property_replace_global_blob isn't actually atomic, and doesn't
  need to be. Update docs&comments to match
- document all the types and try to link things a bit better
- nits all over

v2: Appease checkpatch in the moved code (Archit)
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-9-daniel.vetter@ffwll.ch

They work exactly the same now, after the refcounting unification a bit
ago. The only reason they're distinct is backwards compat with existing
userspace.

Cc: Daniel Stone <daniels@collabora.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-8-daniel.vetter@ffwll.ch

This just contains the base property classes and all the code to
handle blobs. I think for any kind of standardized/shared properties
it's better to have separate files - this is fairly big already as-is.

v2: resurrect misplaced hunk (Daniel Stone)

Cc: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-7-daniel.vetter@ffwll.ch

It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-6-daniel.vetter@ffwll.ch

I figured an overview section here is overkill, and better
to just document the 2 structures themselves well enough.

v2: Review from Archit:
- Appease checkpatch in moved code.
- Spelling fixes in the kerneldoc.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-5-daniel.vetter@ffwll.ch

It's only used in drm_mode_object_get_properties, and we can compute
it there directly with a bit of code shuffling.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-4-daniel.vetter@ffwll.ch

Just for the struct drm_mode_object base class. The header file was
already partially extracted to help untangle the include loops.

v2:
- Also move the generic get/set property ioctls. At first this seemed
  like a bad idea since it requires making drm_mode_crtc_set_obj_prop
  non-static. But eventually that will get split away too (like
  the connector version already is) for both crtc and planes. Hence I
  reconsidered.

- drm_mode_object.[hc] instead of drm_modeset.[hc], which requires
  renaming the drm_modeset.h header I already started building up.
  This is more consistent (matches the name of the main structure),
  and I want to be able to use drm_modeset.[hc] for the basic modeset
  init/cleanup functionality like drm_mode_config_init.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-3-daniel.vetter@ffwll.ch

- Move missing bits into struct drm_encoder docs.
- Explain that encoders are 95% internal and only 5% uapi, and that in
  general the uapi part is broken.
- Remove verbose comments for functions not exposed to drivers.

v2: Review from Archit:
- Appease checkpatch in the moved code.
- Make it clearer that bridges are not exposed to userspace.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-2-daniel.vetter@ffwll.ch

Same treatment as before. Only hiccup is drm_crtc_mask, which
unfortunately can't be resolved until drm_crtc.h is less of a monster.
Untangle the header loop with a forward declaration for that static
inline.
Reviewed-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-1-daniel.vetter@ffwll.ch

Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter
of the helper drm_atomic_helper_commit_planes() if the relevant display
controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes
when the CRTC is disabled. The helper would skip the ->atomic_disable
call for a plane if the CRTC of the old plane state needs a modesetting
operation. Of course, the drivers need to disable the planes in their CRTC
disable callbacks since no one else would do that.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Peter Senna Tschudin <peter.senna@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: NLiu Ying <gnuiyl@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1472461923-14364-1-git-send-email-gnuiyl@gmail.com

Currently, the helper drm_atomic_helper_disable_planes_on_crtc() calls
->atomic_disable for all planes _to be_ enabled on a particular CRTC.
This is obviously wrong for those planes which are not scanning out frames
when the helper is called.  Instead, it's sane to disable active planes
of old_crtc_state in the helper.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Peter Senna Tschudin <peter.senna@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: NLiu Ying <gnuiyl@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1472196644-30563-3-git-send-email-gnuiyl@gmail.com

Some display controllers need plane(s) to be disabled together with
the relevant CRTC, e.g., the IPUv3 display controller for imx-drm.
This patch adds atomic_disable CRTC helper callback so that
old_crtc_state(as a parameter of the callback) could be used
to get the active plane(s) of the old CRTC state for disable operation.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: David Airlie <airlied@linux.ie>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Peter Senna Tschudin <peter.senna@gmail.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: NLiu Ying <gnuiyl@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1472196644-30563-2-git-send-email-gnuiyl@gmail.com

Introduce drm_simple_display_pipe_attach_bridge() and
drm_simple_display_pipe_detach_bridge() in order to make it possible to use
drm encoders with the simple display pipes managed by simple_kms_helpers
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1472115874-6219-3-git-send-email-andrea.merello@gmail.com

drm_simple_display_pipe_init() pretends to attach a connector
to the display pipe.

In case a drm bridge has to be used, then it's the bridge that
takes care of connectors.

This patch makes the connector parameter optional for
drm_simple_display_pipe_init(), so that a drm bridge could
handle connector by itself later.
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1472115874-6219-2-git-send-email-andrea.merello@gmail.com

Up to now, once a bridge has been attached to a DRM device, it cannot
be undone.

In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
because the bridge would remain bound to the first (dead) driver instance.

This patch fixes this by introducing drm_encoder_detach() and a ->detach
callback in drm_bridge_funcs for the bridge to be notified about detaches.

It's DRM/KMS driver responsibility to call drm_encoder_detach().

While adding the bridge detach callback, with its kerneldoc, I also added
kerneldoc for attach callback.

Few other kerneldocs fixes around there are included.
Suggested-by: NDaniel Vetter <daniel@ffwll.ch>
Suggested-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NAndrea Merello <andrea.merello@gmail.com>
Cc: Archit Taneja <architt@codeaurora.org>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1472115874-6219-1-git-send-email-andrea.merello@gmail.com

Our update function is hooked to the single plane, which might not get
called for crtc-only updates. Which is surprising, so fix this by
always adding the plane.

While at it document how&when the event should be sent out better in
the kerneldoc.

Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: andrea.merello@gmail.com
Tested-and-Reported-by: andrea.merello@gmail.com
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1471933540-31131-1-git-send-email-daniel.vetter@ffwll.ch

The *only* known user of GETCLIENT is libva, which uses it to check
whether its own context is authenticated. It used to iterate all clients,
look for one that matches its own pid and then check its state.

The entire purpose for us to still have a GETCLIENT implementation is to
serve libva. So lets not pretend we do anything else: Make this function
return information on the caller's context only, fake the PID to the
caller's pid so they always match, and just fill in the "authenticated"
bit, nothing else.

This patch reduces the complexity of GETCLIENT to a bare minimum, avoids
any dependency on priv->uid or priv->pid (allows us to get rid of them),
and makes libva happy by always *exactly* returning the information it
wants.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160825143505.7447-1-dh.herrmann@gmail.com

The legacy DRI1 drivers expose highly broken interfaces to user-space. No
modern system should enable them, or you will effectively allow user-space
to circumvent most of your kernel security measures. The DRI1 kernel APIs
are simply broken.

User-space can always use vesafb/efifb/simplefb and friends to get working
graphics.

Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
be still used (really?), we can easily revert this and figure out a way to
move them out of sight (e.g., moving all DRI1 drivers to
drivers/gpu/dri1/).
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160804080657.9664-2-dh.herrmann@gmail.com

Lets move forward and hide the remaining DRI1 drivers behind a config
option, so we have a central place to disable them all. Furthermore, we
can provide a clear warning to anyone enabling them.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160804080657.9664-1-dh.herrmann@gmail.com

Try to be clean here, even when it's a noop on x86.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Also use the firmware size from the header instead of calculating it.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Replace packet2's with packet0 writes to UVD_NO_OP.  The
value written to UVD_NO_OP does not matter.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Replace packet2's with packet0 writes to UVD_NO_OP.  The
value written to UVD_NO_OP does not matter.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Writes to this register are the preferred way to do NOPs.

Bump the driver version as well.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Writes to this register are the preferred way to do NOPs.

Bump the driver version as well.
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The VCE rings only require single dword alignment.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

According to the hw team, it should be 16, not 8.

Cc: Peter Fang <peter.fang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org