The atomic commit cannot easily undo and return an error once the
state is swapped. Change to uninterruptible wait, and ignore the
timeout error.
Signed-off-by: NWentao Xu <wentaox@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

mdp4_get_frame_format() can dereference a drm_framebuffer when it's NULL.
Call it in mdp4_plane_mode_set only when we know fb is non-NULL.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

We need to return a new sgt, since the caller takes ownership of it.
Reported-by: NStanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Merge tag 'drm-amdkfd-next-fixes-2015-08-05' of git://people.freedesktop.org/~gabbayo/linux into drm-next

Two small bug fixes for the code you pulled for 4.3:

- Used a SHIFT define instead of a MASK define to check if a bit is turned on
  when destroying hqd. Luckily, this is in gfx7 interface file with amdgpu,
  which was used only for bring-up purposes of amdgpu, so no real effect on
  a running system

- Used a logical AND instead of a bitwise AND operator, when initializing
  sdma virtual memory when using SDMA queues

* tag 'drm-amdkfd-next-fixes-2015-08-05' of git://people.freedesktop.org/~gabbayo/linux:
  drm/amdkfd: fix bug when initializing sdma vm
  drm/amdgpu: fix bug when amdkfd destroys hqd

Merge branch 'drm-sti-next-atomic-2015-08-11' of http://git.linaro.org/people/benjamin.gaignard/kernel into drm-next

This serie of patches fix minor bugs around how driver sub-components are
bind and planes z-ordering.
The main part is about atomic support: using more atomic helpers allow us
to simplify the code (~300 lines removed) and to ahve a better match between
drm concepts (planes and crtc) and hardware split.

[airlied: fixed up conflict in atomic code]

* 'drm-sti-next-atomic-2015-08-11' of http://git.linaro.org/people/benjamin.gaignard/kernel:
  drm/sti: atomic crtc/plane update
  drm/sti: rename files and functions
  drm/sti: code clean up
  drm/sti: fix dynamic z-ordering
  drm: sti: fix sub-components bind

Final drm-misc pull for 4.3:
- fbdev emulation Kconfig option for everyone thanks to Archit. It's not
  everything yet bit this is fairly tricky since it spawns all drivers.
- vgaarb & vgaswitcheroo polish from Thierry
- some drm_irq.c cleanups (Thierry)
- struct_mutex crusade from me
- more fbdev panic handling removal
- various things all over in drm core&helpers

* tag 'topic/drm-misc-2015-08-13' of git://anongit.freedesktop.org/drm-intel: (65 commits)
  drm/atomic: Use KMS VBLANK API
  drm/irq: Document return values more consistently
  drm/irq: Make pipe unsigned and name consistent
  drm/irq: Check for valid VBLANK before dereference
  drm/irq: Remove negative CRTC index special-case
  drm/plane: Remove redundant extern
  drm/plane: Use consistent data types for format count
  vga_switcheroo: Remove unnecessary checks
  vga_switcheroo: Wrap overly long lines
  vga_switcheroo: Use pr_fmt()
  vga_switcheroo: Cleanup header comment
  vga_switcheroo: Use pr_*() instead of printk()
  vgaarb: Fix a few checkpatch errors and warnings
  vgaarb: Use vgaarb: prefix consistently in messages
  vgaarb: Stop complaining about absent devices
  drm/atomic: fix null pointer access to mode_fixup callback
  drm/i915: Use CONFIG_DRM_FBDEV_EMULATION
  drm/core: Set mode to NULL when connectors in a set drops to 0.
  drm/atomic: Call ww_acquire_done after check phase is complete
  drm/atomic: Paper over locking WARN in default_state_clear
  ...

Instead of using the legacy VBLANK API, use the new KMS API. This is
part of an effort to convert all existing users so that the KMS API can
be changed to properly use per-CRTC data.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some of the functions are documented inconsistently. Add Returns:
sections where missing and use consistent style to describe the return
value.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Name all references to the pipe number (CRTC index) consistently to make
it easier to distinguish which is a pipe number and which is a pointer
to struct drm_crtc.

While at it also make all references to the pipe number unsigned because
there is no longer any reason why it should ever be negative.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When accessing the array of per-CRTC VBLANK structures we must always
check that the index into the array is valid before dereferencing to
avoid crashing.
Signed-off-by: NThierry Reding <treding@nvidia.com>
[danvet: Squash in my own whitespace ocd fixup in drm_vblank_count.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The drm_send_vblank_event() function treats negative CRTC indices as
meaning that a driver doesn't have proper VBLANK handling. This is the
only place where DRM needs negative CRTC indices, so in order to enable
subsequent cleanup, remove this special case and replace it by the more
obvious check for whether or not VBLANK support was initialized.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use of the extern keyword for function prototypes is unnecessary, so it
can be removed.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rather than a mix of the the sized uint32_t and signed integer, use an
unsized unsigned int to specify the format count.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

debugfs_remove() gracefully ignores NULL parameters, so the explicit
checks can be removed.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Wrap overly long lines to make checkpatch happy. While at it, also add
blank lines after declarations to eliminate additional problems flagged
by checkpatch.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use pr_fmt() to define the "vga_switcheroo: " prefix that is prepended
to all output messages emitted by pr_*() functions. This allows making
existing strings much shorter and eliminates a bunch of warnings from
checkpatch about lines being overly long.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The header comment uses a weird combination of formatting styles. Make
it consistent.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This silences a bunch of checkpatch warnings and makes the code shorter.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Wrap overly long lines (offending lines were mostly comments, so trivial
to fix up) and a number of other coding style issues pointed out by the
checkpatch tool.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Define the pr_fmt() macro to causes all messages emitted by pr_*()
functions to be prefixed with "vgaarb: ".
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some setups do not register a default VGA device, in which case the VGA
arbiter will still complain about the (non-existent) PCI device being a
non-VGA device.

Fix this by making the error message conditional on a default VGA device
having been set up. Note that the easy route of erroring out early isn't
going to work because otherwise priv->target won't be properly updated.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch fixes null pointer access incurred when
encoder driver didn't set its own mode_fixup callback.

mode_fixup callback shoudn't be called if the callback
of drm_encoder_helper_funcs is NULL.

Changelog v2:
- change it to else if
Signed-off-by: NInki Dae <inki.dae@samsung.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of our own duplicated one. This fixes a bug in the driver
unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
try to unregister the nonexistent fbdev drm_framebuffer.

Cc: Archit Taneja <architt@codeaurora.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Without this when a MST connector is removed drm_atomic_helper_set_config
can complain about set->mode && !set->num_connectors.

------------[ cut here ]------------
WARNING: CPU: 2 PID: 2403 at drivers/gpu/drm/drm_atomic_helper.c:1673 drm_atomic_helper_set_config+0x22e/0x420()
CPU: 2 PID: 2403 Comm: kms_flip Not tainted 4.2.0-rc5 #4233
Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015
 ffffffff81ac75e8 ffff88004e4ffbf8 ffffffff81714c34 0000000080000000
 0000000000000000 ffff88004e4ffc38 ffffffff8107bf81 ffff88004e4ffc48
 ffff8800d8ca0690 ffff8800d8d7a080 ffff8800d8cc2290 ffff8800d07bc9f0
Call Trace:
 [<ffffffff81714c34>] dump_stack+0x4f/0x7b
 [<ffffffff8107bf81>] warn_slowpath_common+0x81/0xc0
 [<ffffffff8107c065>] warn_slowpath_null+0x15/0x20
 [<ffffffff813d9e3e>] drm_atomic_helper_set_config+0x22e/0x420
 [<ffffffff813da174>] ? drm_atomic_helper_plane_set_property+0x84/0xc0
 [<ffffffff813ee101>] drm_mode_set_config_internal+0x61/0x100
 [<ffffffff813dc4ed>] restore_fbdev_mode+0xbd/0xe0
 [<ffffffff813de1e4>] drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x70
 [<ffffffffc0123d11>] intel_fbdev_restore_mode+0x21/0x80 [i915]
 [<ffffffffc014bf69>] i915_driver_lastclose+0x9/0x10 [i915]
 [<ffffffff813e2429>] drm_lastclose+0x29/0x130
 [<ffffffff813e2844>] drm_release+0x314/0x500
 [<ffffffff81194795>] __fput+0xe5/0x1f0
 [<ffffffff811948d9>] ____fput+0x9/0x10
 [<ffffffff810968d8>] task_work_run+0x88/0xb0
 [<ffffffff8107d53f>] do_exit+0x37f/0xa90
 [<ffffffff8127e258>] ? selinux_file_ioctl+0x48/0xc0
 [<ffffffff81277dfe>] ? security_file_ioctl+0x3e/0x60
 [<ffffffff8107ec80>] do_group_exit+0x40/0xa0
 [<ffffffff8107ecef>] SyS_exit_group+0xf/0x10
 [<ffffffff8171bdd7>] entry_SYSCALL_64_fastpath+0x12/0x6a
---[ end trace 0daf358c49351567 ]---
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to make sure that no one tries to acquire more locks and
states, and ww mutexes provide debug facilities for that. So use them.

v2: Only call acquire_done when ->atomic_check was successful to avoid
falling over an -EDEADLK (spotted by Maarten).

Cc: Rob Clark <robdclark@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

In

commit 6f75cea6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Nov 19 18:38:07 2014 +0100

    drm/atomic: Only destroy connector states with connection mutex held

I tried to fix races of atomic commits against connector
hot-unplugging. The idea is to ensure lifetimes by holding the
connection_mutex long enough. That works for synchronous commits, but
not for async ones.

For async atomic commit we really need to fix up connector lifetimes
for real. But that's a much bigger task, so just add more duct-tape:
For cleaning up connector states we currently don't need the connector
itself. So NULL it out and remove the locking check. Of course that
check was to protect the entire sequence, but the modeset itself
should be save since currently DP MST hot-removal does a dpms-off. And
that should synchronize with any outstanding async atomic commit.

Or at least that's my hope, this is all a giant mess.
Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Spotted while reading code for random reasons.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

It really doesn't protect anything which doesn't have other locks
already. It also doesn't seem to be wired up into the driver unload
code fwiw, but that's a different issue.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

This is only called in driver load/unload paths, no need to grab any
locks at all. Also, ttm takes care of itself anyway.

Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).

Aside: I stumbled over the mmap handler which directly does a
dma_mmap_attrs. But totally fails to grab a reference on the
underlying object and hence looks like it happily just leaks the ptes
since there's no guarantee the mmap isn't still around when
gem_free_object is called. Which the kerneldoc of dma_mmap_attrs
explicitly forbids.

v2: Fixup compile fail 0-day spotted.

Cc: Mark Yao <mark.yao@rock-chips.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).

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

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Looking up an obj, immediate dropping the acquired reference and then
continuing to use it isn't how this is supposed to work. Fix this by
holding a reference for the entire function.

While at it stop grabbing dev->struct_mutex, it doesn't protect
anything here.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Since David Herrmann's mmap vma manager rework we don't need to grab
dev->struct_mutex any more to prevent races when looking up the mmap
offset. Drop it and instead don't forget to use the unref_unlocked
variant (since the drm core still cares).
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

BUG_ON kills the driver, WARN_ON is much friendlier. And usually nothing
bad happens when the locking is slightly busted.

v2: Fix typos in commit message Thierry spotted.
Reviewed-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

The Direct Rendering Manager Kconfig option is already a separate menu,
so remove the extra level to make it easier to navigate.
Signed-off-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Legacy fbdev emulation support via DRM is achieved through KMS FB helpers.
Most modesetting drivers enable provide fbdev emulation by default by
selecting KMS FB helpers. A few provide a separate Kconfig option for the
user to enable or disbale fbdev emulation.

Enabling fbdev emulation is finally a distro-level decision. Having a top
level Kconfig option for fbdev emulation helps by providing a uniform way
to enable/disable fbdev emulation for any modesetting driver. It also lets
us remove unnecessary driver specific Kconfig options that causes bloat.

With a top level Kconfig in place, we can stub out the fb helper functions
when not needed without breaking functionality. Having stub functions also
prevents drivers to require wrapping fb helper function calls with #ifdefs.

DRM_FBDEV_EMULATION defaults to y since many drivers enable fbdev
emulation by default and majority of distributions expect the fbdev
interface in the kernel.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If CONFIG_MAGIC_SYSRQ is not set:

    drivers/gpu/drm/drm_fb_helper.c:390:13: warning: 'drm_fb_helper_force_kernel_mode' defined but not used [-Wunused-function]
     static bool drm_fb_helper_force_kernel_mode(void)
		 ^

Move drm_fb_helper_force_kernel_mode() inside the existing #ifdef to fix
this.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>