Currently, amdgpu_do_flip() spinlocks crtc->dev->event_lock and
releases it only after committing updates to the stream.

dc_commit_updates_for_stream() should be moved out of
spinlock for the below reasons:

1. event_lock is supposed to protect access to acrct->pflip_status _only_
2. dc_commit_updates_for_stream() has potential sleep's
   and also its not appropriate to be  in an atomic state
   for such long sequences of code.
Signed-off-by: NShirish S <shirish.s@amd.com>
Suggested-by: NAndrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Support new VCN FW version naming convention:
  [31, 28] for VEP interface major version if applicable
  [27, 24] for decode interface major version
  [23, 20] for encode interface major version
  [19, 12] for encode interface minor version
  [11, 0]  for firmware revision
Bit 20-23, it is encode major and non-zero for new naming convention.
This field is part of version minor and DRM_DISABLED_FLAG in old naming
convention. Since the latest version minor is 0x5B and DRM_DISABLED_FLAG
is zero in old naming convention, this field is always zero so far.
These four bits are used to tell which naming convention is present.
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NFang, Peter <Peter.Fang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Here is the UBSAN dump:

[    3.866656] index 2 is out of range for type 'amdgpu_uvd_inst [2]'
[    3.866693] Workqueue: events work_for_cpu_fn
[    3.866702] Call Trace:
[    3.866710]  dump_stack+0x85/0xc5
[    3.866719]  ubsan_epilogue+0x9/0x40
[    3.866727]  __ubsan_handle_out_of_bounds+0x89/0x90
[    3.866737]  ? rcu_read_lock_sched_held+0x58/0x60
[    3.866746]  ? __kmalloc+0x26c/0x2d0
[    3.866846]  amdgpu_fence_driver_start_ring+0x259/0x280 [amdgpu]
[    3.866896]  amdgpu_ring_init+0x12c/0x710 [amdgpu]
[    3.866906]  ? sprintf+0x42/0x50
[    3.866956]  amdgpu_gfx_kiq_init_ring+0x1bc/0x3a0 [amdgpu]
[    3.867009]  gfx_v8_0_sw_init+0x1ad3/0x2360 [amdgpu]
[    3.867062]  ? smu7_init+0xec/0x160 [amdgpu]
[    3.867109]  amdgpu_device_init+0x112c/0x1dc0 [amdgpu]

'ring->me' might be set as 2 with 'amdgpu_gfx_kiq_init_ring', that would
cause out of range for 'amdgpu_uvd_inst[2]'.

v2: simplified with ring type
Signed-off-by: NLeo Liu <leo.liu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

start / last / max_entries are numbers of GPU pages, pfn / count are
numbers of CPU pages. Convert between them accordingly.

Fixes badness on systems with > 4K page size.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/106258Reported-by: NMatt Corallo <freedesktop@bluematt.me>
Tested-by: foxbat@ruin.net
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This fixes a regression I accidentally reduced that was picked up by
kasan, where we were checking the CRTC atomic states after DRM's helpers
had already freed them. Example:

==================================================================
BUG: KASAN: use-after-free in amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
Read of size 1 at addr ffff8803a697b071 by task kworker/u16:0/7

CPU: 7 PID: 7 Comm: kworker/u16:0 Tainted: G           O      4.18.0-rc1Lyude-Upstream+ #1
Hardware name: HP HP ZBook 15 G4/8275, BIOS P70 Ver. 01.21 05/02/2018
Workqueue: events_unbound commit_work [drm_kms_helper]
Call Trace:
 dump_stack+0xc1/0x169
 ? dump_stack_print_info.cold.1+0x42/0x42
 ? kmsg_dump_rewind_nolock+0xd9/0xd9
 ? printk+0x9f/0xc5
 ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
 print_address_description+0x6c/0x23c
 ? amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
 kasan_report.cold.6+0x241/0x2fd
 amdgpu_dm_atomic_commit_tail.cold.50+0x13d/0x15a [amdgpu]
 ? commit_planes_to_stream.constprop.45+0x13b0/0x13b0 [amdgpu]
 ? cpu_load_update_active+0x290/0x290
 ? finish_task_switch+0x2bd/0x840
 ? __switch_to_asm+0x34/0x70
 ? read_word_at_a_time+0xe/0x20
 ? strscpy+0x14b/0x460
 ? drm_atomic_helper_wait_for_dependencies+0x47d/0x7e0 [drm_kms_helper]
 commit_tail+0x96/0xe0 [drm_kms_helper]
 process_one_work+0x88a/0x1360
 ? create_worker+0x540/0x540
 ? __sched_text_start+0x8/0x8
 ? move_queued_task+0x760/0x760
 ? call_rcu_sched+0x20/0x20
 ? vsnprintf+0xcda/0x1350
 ? wait_woken+0x1c0/0x1c0
 ? mutex_unlock+0x1d/0x40
 ? init_timer_key+0x190/0x230
 ? schedule+0xea/0x390
 ? __schedule+0x1ea0/0x1ea0
 ? need_to_create_worker+0xe4/0x210
 ? init_worker_pool+0x700/0x700
 ? try_to_del_timer_sync+0xbf/0x110
 ? del_timer+0x120/0x120
 ? __mutex_lock_slowpath+0x10/0x10
 worker_thread+0x196/0x11f0
 ? flush_rcu_work+0x50/0x50
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x40/0x70
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x40/0x70
 ? __switch_to_asm+0x34/0x70
 ? __switch_to_asm+0x40/0x70
 ? __schedule+0x7d6/0x1ea0
 ? migrate_swap_stop+0x850/0x880
 ? __sched_text_start+0x8/0x8
 ? save_stack+0x8c/0xb0
 ? kasan_kmalloc+0xbf/0xe0
 ? kmem_cache_alloc_trace+0xe4/0x190
 ? kthread+0x98/0x390
 ? ret_from_fork+0x35/0x40
 ? ret_from_fork+0x35/0x40
 ? deactivate_slab.isra.67+0x3c4/0x5c0
 ? kthread+0x98/0x390
 ? kthread+0x98/0x390
 ? set_track+0x76/0x120
 ? schedule+0xea/0x390
 ? __schedule+0x1ea0/0x1ea0
 ? wait_woken+0x1c0/0x1c0
 ? kasan_unpoison_shadow+0x30/0x40
 ? parse_args.cold.15+0x17a/0x17a
 ? flush_rcu_work+0x50/0x50
 kthread+0x2d4/0x390
 ? kthread_create_worker_on_cpu+0xc0/0xc0
 ret_from_fork+0x35/0x40

Allocated by task 1124:
 kasan_kmalloc+0xbf/0xe0
 kmem_cache_alloc_trace+0xe4/0x190
 dm_crtc_duplicate_state+0x78/0x130 [amdgpu]
 drm_atomic_get_crtc_state+0x147/0x410 [drm]
 page_flip_common+0x57/0x230 [drm_kms_helper]
 drm_atomic_helper_page_flip+0xa6/0x110 [drm_kms_helper]
 drm_mode_page_flip_ioctl+0xc4b/0x10a0 [drm]
 drm_ioctl_kernel+0x1d4/0x260 [drm]
 drm_ioctl+0x433/0x920 [drm]
 amdgpu_drm_ioctl+0x11d/0x290 [amdgpu]
 do_vfs_ioctl+0x1a1/0x13d0
 ksys_ioctl+0x60/0x90
 __x64_sys_ioctl+0x6f/0xb0
 do_syscall_64+0x147/0x440
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 1124:
 __kasan_slab_free+0x12e/0x180
 kfree+0x92/0x1a0
 drm_atomic_state_default_clear+0x315/0xc40 [drm]
 __drm_atomic_state_free+0x35/0xd0 [drm]
 drm_atomic_helper_update_plane+0xac/0x350 [drm_kms_helper]
 __setplane_internal+0x2d6/0x840 [drm]
 drm_mode_cursor_universal+0x41e/0xbe0 [drm]
 drm_mode_cursor_common+0x49f/0x880 [drm]
 drm_mode_cursor_ioctl+0xd8/0x130 [drm]
 drm_ioctl_kernel+0x1d4/0x260 [drm]
 drm_ioctl+0x433/0x920 [drm]
 amdgpu_drm_ioctl+0x11d/0x290 [amdgpu]
 do_vfs_ioctl+0x1a1/0x13d0
 ksys_ioctl+0x60/0x90
 __x64_sys_ioctl+0x6f/0xb0
 do_syscall_64+0x147/0x440
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

The buggy address belongs to the object at ffff8803a697b068
 which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 9 bytes inside of
 1024-byte region [ffff8803a697b068, ffff8803a697b468)
The buggy address belongs to the page:
page:ffffea000e9a5e00 count:1 mapcount:0 mapping:ffff88041e00efc0 index:0x0 compound_mapcount: 0
flags: 0x8000000000008100(slab|head)
raw: 8000000000008100 ffffea000ecbc208 ffff88041e000c70 ffff88041e00efc0
raw: 0000000000000000 0000000000170017 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8803a697af00: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8803a697af80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff8803a697b000: fc fc fc fc fc fc fc fc fc fc fc fc fc fb fb fb
                                                             ^
 ffff8803a697b080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff8803a697b100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

So, we fix this by counting the number of CRTCs this atomic commit disabled
early on in the function before their atomic states have been freed, then use
that count later to do the appropriate number of RPM puts at the end of the
function.
Acked-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Cc: stable@vger.kernel.org
Fixes: 97028037 ("drm/amdgpu: Grab/put runtime PM references in atomic_commit_tail()")
Signed-off-by: NLyude Paul <lyude@redhat.com>
Cc: Michel Dänzer <michel@daenzer.net>
Reported-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Fixes for v4.18-rc2:
- A reversion of a commit in drm/sun4i to fix a run-time fault.
- Various fixes to the sii8620 bridge.
- Small bugfix to correctly check stride in atmel-hlcdc.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/787d4bef-a579-4046-d0fc-f8c2c5b80c25@linux.intel.com

Merge tag 'drm-intel-fixes-2018-06-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

drm/i915 fixes for v4.18-rc2:
- Mostly cc: stable display fixes, including a DBLSCAN regression fix
- GEM fixes for this merge window
Signed-off-by: NDave Airlie <airlied@redhat.com>

Link: https://patchwork.freedesktop.org/patch/msgid/87d0wkuypy.fsf@intel.com

Currently packed pixel modes in MHL2 can't be displayed. The device
automatically recognizes output format, so setting format other than
RGB causes failure. Fix it by writing proper values to registers.

Tested on MHL1 and MHL2 using various vendors' dongles both in
DVI and HDMI mode.
Signed-off-by: NMaciej Purski <m.purski@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1516706239-9104-1-git-send-email-m.purski@samsung.com

Bunch of amdgpu fixes mostly all going to stable.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180620190021.2775-1-alexander.deucher@amd.com

Only a small qxl fix that was queued for v4.17.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/08dcbd63-ed18-6232-7bbd-547a3d63b90f@linux.intel.com

Merge tag 'drm-misc-next-fixes-2018-06-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Single fix for v4.18:
- Fix possible race conditions while unplugging DRM device.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1fd8b7d1-e60a-0105-dfb5-d36f99ea0239@linux.intel.com

Single nouveau regression fix.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv5VDDKaYKJShyVAGK0MJAHMZOJ02FKQ_aW5DnBCNVgRUw@mail.gmail.com

Even BOs with AMDGPU_GEM_CREATE_NO_CPU_ACCESS may end up at least
partially in CPU visible VRAM, in particular when all VRAM is visible.

v2:
* Don't take VRAM mgr spinlock, not needed (Christian König)
* Make loop logic simpler and clearer.

Cc: stable@vger.kernel.org
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Preparation for the following fix, no functional change intended.

Cc: stable@vger.kernel.org
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

At least in theory, ttm_bo_validate may move the BO, in which case the
pin_size accounting would be inconsistent with when the BO was pinned.

Cc: stable@vger.kernel.org
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

All UVD instanses have only one dpm control, so it is better
to share one idle_work handle.
Signed-off-by: NJames Zhu <James.Zhu@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Tested-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

We've had a number of users report failures to detect and light up
display with DC with LVDS and VGA. These connector types are not
currently supported with DC. I'd like to add support but unfortunately
don't have a system with LVDS or VGA available.

In order not to cause regressions we should probably fallback to the
non-DC driver for ASICs that support VGA and LVDS.

These ASICs are:
 * Bonaire
 * Kabini
 * Kaveri
 * Mullins

ASIC support can always be force enabled with amdgpu.dc=1

v2: Keep Hawaii on DC
v3: Added Mullins to the list

Cc: stable@vger.kernel.org
Signed-off-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

It can be quite big, and there's no need for it to be physically
contiguous. This is less likely to fail under memory pressure (has
actually happened while running piglit).

Cc: stable@vger.kernel.org
Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Initialize variable to 0 before performing logical OR operation.
Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Signed-off-by: NRajan Vaja <rajan.vaja@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

The SF and clipper units mishandle the provoking vertex in some cases,
which can cause misrendering with shaders that use flat shaded inputs.

There are chicken bits in 3D_CHICKEN3 (for SF) and FF_SLICE_CHICKEN
(for the clipper) that work around the issue.  These registers are
unfortunately not part of the logical context (even the power context),
and so we must reload them every time we start executing in a context.

Bugzilla: https://bugs.freedesktop.org/103047Signed-off-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615190605.16238-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
(cherry picked from commit b77422f8)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If client is smart or lucky enough to create a new context
after each hang, our context banning mechanism will never
catch up, and as a result of that it will be saved from
client banning. This can result in a never ending streak of
gpu hangs caused by bad or malicious client, preventing
access from other legit gpu clients.

Fix this by always incrementing per client ban score if
it hangs in short successions regardless of context ban
scoring. The exception are non bannable contexts. They remain
detached from client ban scoring mechanism.

v2: xchg timestamp, tidyup (Chris)
v3: comment, bannable & banned together (Chris)

Fixes: b083a087 ("drm/i915: Add per client max context ban limit")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615104429.31477-1-mika.kuoppala@linux.intel.com
(cherry picked from commit 14921f3c)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

While Bspec doesn't list a specific sequence for turning off the DP port
on g4x we are getting an underrun if the port is disabled in the
.disable() hook. Looks like the pipe stops when the port stops, and by
that time the plane disable may not have completed yet. Also the plane(s)
seem to end up in some wonky state when this happens as they also signal
another underrun immediately after we turn them back on during the next
enable sequence.

We could add a vblank wait in .disable() to avoid wedging the planes,
but I assume we're still tripping up the pipe in some way. So it seems
better to me to just follow the ILK+ sequence and turn off the DP port
in .post_disable() instead. This sequence doesn't seem to suffer from
this problem. Could be it was always the intended sequence for DP and
the gen4 bspec was just never updated to include it.

Originally we used the bad sequence even on ilk+, but I changed that
in commit 08aff3fe ("drm/i915: Move DP port disable to post_disable
for pch platforms") as it was causing issues on those platforms as well.
I left out g4x then only because I didn't have the hardware to test it.
Now that I do it's fairly clear that the ilk+ sequence is also the
right choice for g4x.

v2: Fix whitespace fail (Jani)
    Mention the ilk+ commit (Jani)

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-2-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
(cherry picked from commit 51a9f6df)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Looks like interlaced DP output doesn't work on g4x either. Not all
that surprising considering we already established that interlaced
DP output is busted on VLV/CHV.

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613160553.11664-1-ville.syrjala@linux.intel.com
(cherry picked from commit 929168c5)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On i965/g4x IIR is edge triggered. So in order for IIR to notice that
there is still a pending interrupt we have to force and edge in ISR.
For the ISR/IIR pipe event bits we can do that by temporarily
clearing all the PIPESTAT enable bits when we ack the status bits.
This will force the ISR pipe event bit low, and it can then go back
high when we restore the PIPESTAT enable bits.

This avoids the following race:
1. stat = read(PIPESTAT)
2. an enabled PIPESTAT status bit goes high
3. write(PIPESTAT, enable|stat);
4. write(IIR, PIPE_EVENT)

The end result is IIR==0 and ISR!=0. This can lead to nasty
vblank wait/flip_done timeouts if another interrupt source
doesn't trick us into looking at the PIPESTAT status bits despite
the IIR PIPE_EVENT bit being low.

Before i965 IIR was level triggered so this problem can't actually
happen there. And curiously VLV/CHV went back to the level triggered
scheme as well. But for simplicity we'll use the same i965/g4x
compatible code for all platforms.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 132c27c9)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When encountering a connector with the scaling mode property both
intel and modesetting ddxs sometimes add tons of DBLSCAN modes
to the output's mode list. The idea presumably being that since the
output will be going through the panel fitter anyway we can pretend
to use any kind of mode.

Sadly that means we can't reject user modes with the DBLSCAN flag
until we know whether we're going to be using the panel's native
mode or the user mode directly. Doing otherwise means X clients using
xf86vidmode/xrandr will get a protocol error (and often self
terminate as a result) when the kernel refuses to use the requested
mode with the DBLSCAN flag.

To undo the regression we'll move the DBLSCAN checks into the
connector->mode_valid() and encoder->compute_config() hooks.

Cc: stable@vger.kernel.org
Cc: Vito Caputo <vcaputo@pengaru.com>
Reported-by: NVito Caputo <vcaputo@pengaru.com>
Fixes: e995ca0b ("drm/i915: Provide a device level .mode_valid() hook")
References: https://lkml.org/lkml/2018/5/21/715Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524125403.23445-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106804Tested-by: NArkadiusz Miskiewicz <arekm@maven.pl>
(cherry picked from commit e4dd27aa)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On allocation error, do not jump to the unwind handler that tries to
free the error pointer.
Reported-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: a89d1f92 ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611153332.14824-1-chris@chris-wilson.co.uk
(cherry picked from commit 467d3578)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We special case the position of the batch within the GTT to prevent
negative self-relocation deltas from underflowing. However, that
restriction is being applied after a trial pin of the batch in its
current position. Thus we are not rejecting an invalid location if the
batch has been used before, leading to an assertion if we happen to need
to rearrange the entire payload. In the worst case, this may cause a GPU
hang on gen7 or perhaps missing state.

References: https://bugs.freedesktop.org/show_bug.cgi?id=105720
Fixes: 2889caa9 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Martin Peres <martin.peres@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180610194325.13467-2-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 746c8f14)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Ctxdmas for cursors from all heads are setup in the core channel, and due
to us tracking allocated handles per-window, we were failing with -EEXIST
on multiple-head setups trying to allocate duplicate handles.

The cursor code is hardcoded to use the core channel vram ctxdma already,
so just skip ctxdma allocation for cursor fbs to fix the issue.

Fixes: 5bca1621 ("drm/nouveau/kms/nv50-: move fb ctxdma tracking into windows")
Reported-by: NAdam Borowski <kilobyte@angband.pl>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This reverts commit 2c17a436.

The offending commit triggers a run-time fault when accessing the panel
element of the sun4i_tcon structure when no such panel is attached.

It was apparently assumed in said commit that a panel is always used with
the TCON. Although it is often the case, this is not always true.
For instance a bridge might be used instead of a panel.

This issue was discovered using an A13-OLinuXino, that uses the TCON
in RGB mode for a simple DAC-based VGA bridge.

Cc: stable@vger.kernel.org
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180613081647.31183-1-paul.kocialkowski@bootlin.com

The statement always evaluates to true since the struct fields
are arrays. This has shown up as a warning when compiling with
clang:
  warning: address of array 'desc->layout.xstride' will always
      evaluate to 'true' [-Wpointer-bool-conversion]

Check for values in the first plane instead.

Fixes: 1a396789 ("drm: add Atmel HLCDC Display Controller support")
Cc: <stable@vger.kernel.org>
Signed-off-by: NStefan Agner <stefan@agner.ch>
Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180617084826.31885-1-stefan@agner.ch

Pull block fixes from Jens Axboe:
 "A collection of fixes that should go into -rc1. This contains:

   - bsg_open vs bsg_unregister race fix (Anatoliy)

   - NVMe pull request from Christoph, with fixes for regressions in
     this window, FC connect/reconnect path code unification, and a
     trace point addition.

   - timeout fix (Christoph)

   - remove a few unused functions (Christoph)

   - blk-mq tag_set reinit fix (Roman)"

* tag 'for-linus-20180616' of git://git.kernel.dk/linux-block:
  bsg: fix race of bsg_open and bsg_unregister
  block: remov blk_queue_invalidate_tags
  nvme-fabrics: fix and refine state checks in __nvmf_check_ready
  nvme-fabrics: handle the admin-only case properly in nvmf_check_ready
  nvme-fabrics: refactor queue ready check
  blk-mq: remove blk_mq_tagset_iter
  nvme: remove nvme_reinit_tagset
  nvme-fc: fix nulling of queue data on reconnect
  nvme-fc: remove reinit_request routine
  blk-mq: don't time out requests again that are in the timeout handler
  nvme-fc: change controllers first connect to use reconnect path
  nvme: don't rely on the changed namespace list log
  nvmet: free smart-log buffer after use
  nvme-rdma: fix error flow during mapping request data
  nvme: add bio remapping tracepoint
  nvme: fix NULL pointer dereference in nvme_init_subsystem
  blk-mq: reinit q->tag_set_list entry only after grace period

Pull documentation fixes from Mauro Carvalho Chehab:
 "This solves a series of broken links for files under Documentation,
  and improves a script meant to detect such broken links (see
  scripts/documentation-file-ref-check).

  The changes on this series are:

   - can.rst: fix a footnote reference;

   - crypto_engine.rst: Fix two parsing warnings;

   - Fix a lot of broken references to Documentation/*;

   - improve the scripts/documentation-file-ref-check script, in order
     to help detecting/fixing broken references, preventing
     false-positives.

  After this patch series, only 33 broken references to doc files are
  detected by scripts/documentation-file-ref-check"

* tag 'docs-broken-links' of git://linuxtv.org/mchehab/experimental: (26 commits)
  fix a series of Documentation/ broken file name references
  Documentation: rstFlatTable.py: fix a broken reference
  ABI: sysfs-devices-system-cpu: remove a broken reference
  devicetree: fix a series of wrong file references
  devicetree: fix name of pinctrl-bindings.txt
  devicetree: fix some bindings file names
  MAINTAINERS: fix location of DT npcm files
  MAINTAINERS: fix location of some display DT bindings
  kernel-parameters.txt: fix pointers to sound parameters
  bindings: nvmem/zii: Fix location of nvmem.txt
  docs: Fix more broken references
  scripts/documentation-file-ref-check: check tools/*/Documentation
  scripts/documentation-file-ref-check: get rid of false-positives
  scripts/documentation-file-ref-check: hint: dash or underline
  scripts/documentation-file-ref-check: add a fix logic for DT
  scripts/documentation-file-ref-check: accept more wildcards at filenames
  scripts/documentation-file-ref-check: fix help message
  media: max2175: fix location of driver's companion documentation
  media: v4l: fix broken video4linux docs locations
  media: dvb: point to the location of the old README.dvb-usb file
  ...

Pull fsnotify updates from Jan Kara:
 "fsnotify cleanups unifying handling of different watch types.

  This is the shortened fsnotify series from Amir with the last five
  patches pulled out. Amir has modified those patches to not change
  struct inode but obviously it's too late for those to go into this
  merge window"

* tag 'fsnotify_for_v4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  fsnotify: add fsnotify_add_inode_mark() wrappers
  fanotify: generalize fanotify_should_send_event()
  fsnotify: generalize send_to_group()
  fsnotify: generalize iteration of marks by object type
  fsnotify: introduce marks iteration helpers
  fsnotify: remove redundant arguments to handle_event()
  fsnotify: use type id to identify connector object type

Pull fbdev updates from Bartlomiej Zolnierkiewicz:
 "There is nothing really major here, few small fixes, some cleanups and
  dead drivers removal:

   - mark omapfb drivers as orphans in MAINTAINERS file (Tomi Valkeinen)

   - add missing module license tags to omap/omapfb driver (Arnd
     Bergmann)

   - add missing GPIOLIB dependendy to omap2/omapfb driver (Arnd
     Bergmann)

   - convert savagefb, aty128fb & radeonfb drivers to use msleep & co.
     (Jia-Ju Bai)

   - allow COMPILE_TEST build for viafb driver (media part was reviewed
     by media subsystem Maintainer)

   - remove unused MERAM support from sh_mobile_lcdcfb and shmob-drm
     drivers (drm parts were acked by shmob-drm driver Maintainer)

   - remove unused auo_k190xfb drivers

   - misc cleanups (Souptick Joarder, Wolfram Sang, Markus Elfring, Andy
     Shevchenko, Colin Ian King)"

* tag 'fbdev-v4.18' of git://github.com/bzolnier/linux: (26 commits)
  fb_omap2: add gpiolib dependency
  video/omap: add module license tags
  MAINTAINERS: make omapfb orphan
  video: fbdev: pxafb: match_string() conversion fixup
  video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling"
  video: fbdev: fix spelling mistake: "frambuffer" -> "framebuffer"
  video: fbdev: pxafb: Convert to use match_string() helper
  video: fbdev: via: allow COMPILE_TEST build
  video: fbdev: remove unused sh_mobile_meram driver
  drm: shmobile: remove unused MERAM support
  video: fbdev: sh_mobile_lcdcfb: remove unused MERAM support
  video: fbdev: remove unused auo_k190xfb drivers
  video: omap: Improve a size determination in omapfb_do_probe()
  video: sm501fb: Improve a size determination in sm501fb_probe()
  video: fbdev-MMP: Improve a size determination in path_init()
  video: fbdev-MMP: Delete an error message for a failed memory allocation in two functions
  video: auo_k190x: Delete an error message for a failed memory allocation in auok190x_common_probe()
  video: sh_mobile_lcdcfb: Delete an error message for a failed memory allocation in two functions
  video: sh_mobile_meram: Delete an error message for a failed memory allocation in sh_mobile_meram_probe()
  video: fbdev: sh_mobile_meram: Drop SUPERH platform dependency
  ...

Pull AFS updates from Al Viro:
 "Assorted AFS stuff - ended up in vfs.git since most of that consists
  of David's AFS-related followups to Christoph's procfs series"

* 'afs-proc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  afs: Optimise callback breaking by not repeating volume lookup
  afs: Display manually added cells in dynamic root mount
  afs: Enable IPv6 DNS lookups
  afs: Show all of a server's addresses in /proc/fs/afs/servers
  afs: Handle CONFIG_PROC_FS=n
  proc: Make inline name size calculation automatic
  afs: Implement network namespacing
  afs: Mark afs_net::ws_cell as __rcu and set using rcu functions
  afs: Fix a Sparse warning in xdr_decode_AFSFetchStatus()
  proc: Add a way to make network proc files writable
  afs: Rearrange fs/afs/proc.c to remove remaining predeclarations.
  afs: Rearrange fs/afs/proc.c to move the show routines up
  afs: Rearrange fs/afs/proc.c by moving fops and open functions down
  afs: Move /proc management functions to the end of the file

Pull compat updates from Al Viro:
 "Some biarch patches - getting rid of assorted (mis)uses of
  compat_alloc_user_space().

  Not much in that area this cycle..."

* 'work.compat' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  orangefs: simplify compat ioctl handling
  signalfd: lift sigmask copyin and size checks to callers of do_signalfd4()
  vmsplice(): lift importing iovec into vmsplice(2) and compat counterpart

Pull aio fixes from Al Viro:
 "Assorted AIO followups and fixes"

* 'work.aio' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  eventpoll: switch to ->poll_mask
  aio: only return events requested in poll_mask() for IOCB_CMD_POLL
  eventfd: only return events requested in poll_mask()
  aio: mark __aio_sigset::sigmask const

Pull networking fixes from David Miller:

 1) Various netfilter fixlets from Pablo and the netfilter team.

 2) Fix regression in IPVS caused by lack of PMTU exceptions on local
    routes in ipv6, from Julian Anastasov.

 3) Check pskb_trim_rcsum for failure in DSA, from Zhouyang Jia.

 4) Don't crash on poll in TLS, from Daniel Borkmann.

 5) Revert SO_REUSE{ADDR,PORT} change, it regresses various things
    including Avahi mDNS. From Bart Van Assche.

 6) Missing of_node_put in qcom/emac driver, from Yue Haibing.

 7) We lack checking of the TCP checking in one special case during SYN
    receive, from Frank van der Linden.

 8) Fix module init error paths of mac80211 hwsim, from Johannes Berg.

 9) Handle 802.1ad properly in stmmac driver, from Elad Nachman.

10) Must grab HW caps before doing quirk checks in stmmac driver, from
    Jose Abreu.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (81 commits)
  net: stmmac: Run HWIF Quirks after getting HW caps
  neighbour: skip NTF_EXT_LEARNED entries during forced gc
  net: cxgb3: add error handling for sysfs_create_group
  tls: fix waitall behavior in tls_sw_recvmsg
  tls: fix use-after-free in tls_push_record
  l2tp: filter out non-PPP sessions in pppol2tp_tunnel_ioctl()
  l2tp: reject creation of non-PPP sessions on L2TPv2 tunnels
  mlxsw: spectrum_switchdev: Fix port_vlan refcounting
  mlxsw: spectrum_router: Align with new route replace logic
  mlxsw: spectrum_router: Allow appending to dev-only routes
  ipv6: Only emit append events for appended routes
  stmmac: added support for 802.1ad vlan stripping
  cfg80211: fix rcu in cfg80211_unregister_wdev
  mac80211: Move up init of TXQs
  mac80211_hwsim: fix module init error paths
  cfg80211: initialize sinfo in cfg80211_get_station
  nl80211: fix some kernel doc tag mistakes
  hv_netvsc: Fix the variable sizes in ipsecv2 and rsc offload
  rds: avoid unenecessary cong_update in loop transport
  l2tp: clean up stale tunnel or session in pppol2tp_connect's error path
  ...

Pull module updates from Jessica Yu:
 "Minor code cleanup and also allow sig_enforce param to be shown in
  sysfs with CONFIG_MODULE_SIG_FORCE"

* tag 'modules-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux:
  module: Allow to always show the status of modsign
  module: Do not access sig_enforce directly