I noticed that the VT switch doesn't work any longer with a Dell
laptop with 1366x768 eDP when the machine is connected with a DP
monitor.  It behaves as if VT were switched, but the graphics remain
frozen.  Actually the keyboard works, so I could switch back to VT7
again.

I tried to track down the problem, and encountered a long story until
we reach to this error:

- The machine is booted with video=1366x768 option (the distro
  installer seems to add it as default).
- Recently, drm_helper_probe_single_connector_modes() deals with
  cmdline modes, and it tries to create a new mode when no
  matching mode is found.
- The drm_mode_create_from_cmdline_mode() creates a mode based on
  either CVT of GFT according to the given cmdline mode; in our case,
  it's 1366x768.
- Since both CVT and GFT can't express the width 1366 due to
  alignment, the resultant mode becomes 1368x768, slightly larger than
  the given size.
- Later on, the atomic commit is performed, and in
  drm_atomic_check_only(), the size of each plane is checked.
- The size check of 1366x768 fails due to the above, and eventually
  the whole VT switch fails.

Back in the history, we've had a manual fix-up of 1368x768 in various
places via c09dedb7 ("drm/edid: Add a workaround for 1366x768 HD
panel"), but they have been all in drm_edid.c at probing the modes
from EDID.  For addressing the problem above, we need a similar hack
to the mode newly created from cmdline, manually adjusting the width
when the expected size is 1366 while we get 1368 instead.

Fixes: eaf99c74 ("drm: Perform cmdline mode parsing during...")
Cc: <stable@vger.kernel.org>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.deReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Instead of scheduling the work to handle the initial delayed event, use 1s
delay.

This delay should not be needed, but Optimus/nouveau will fail in a
mysterious way if the delayed event is handled as soon as possible like it
is done in drm_helper_probe_single_connector_modes() in case the poll
was enabled before.

Reverting 339fd362 would give back the 10 sec (!) delay to handle the
delayed event. Adding 1sec delay to the poll_work is enough to work around
the issue in Optimus setups and gives shorter response on handling the
initial delayed event.

Fixes: 339fd362 ("drm: drm_probe_helper: Fix output_poll_work scheduling")
Cc: stable@vger.kernel.org   # v4.9
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
[danvet: Add FIXME to the comment to make it stick out more.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170109143158.21917-1-peter.ujfalusi@ti.com

Analogix_dp_bind() can be called from component framework, which doesn't
guarantee proper runtime PM state of the device during bind operation,
so ensure that device is runtime active before doing any register access.
This ensures that the power domain, to which DP module belongs, is turned
on. While at it, also fix the unbalanced call to phy_power_on() in
analogix_dp_bind() function.

This patch solves the following kernel oops on Samsung Exynos5250 Snow
board:

Unhandled fault: imprecise external abort (0x406) at 0x00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: : 406 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 75 Comm: kworker/0:2 Not tainted 4.9.0 #1046
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
task: ee272300 task.stack: ee312000
PC is at analogix_dp_enable_sw_function+0x18/0x2c
LR is at analogix_dp_init_dp+0x2c/0x50
...
[<c03fcb38>] (analogix_dp_enable_sw_function) from [<c03fa9c4>] (analogix_dp_init_dp+0x2c/0x50)
[<c03fa9c4>] (analogix_dp_init_dp) from [<c03fab6c>] (analogix_dp_bind+0x184/0x42c)
[<c03fab6c>] (analogix_dp_bind) from [<c03fdb84>] (component_bind_all+0xf0/0x218)
[<c03fdb84>] (component_bind_all) from [<c03ed64c>] (exynos_drm_load+0x134/0x200)
[<c03ed64c>] (exynos_drm_load) from [<c03d5058>] (drm_dev_register+0xa0/0xd0)
[<c03d5058>] (drm_dev_register) from [<c03d66b8>] (drm_platform_init+0x58/0xb0)
[<c03d66b8>] (drm_platform_init) from [<c03fe0c4>] (try_to_bring_up_master+0x14c/0x188)
[<c03fe0c4>] (try_to_bring_up_master) from [<c03fe188>] (component_add+0x88/0x138)
[<c03fe188>] (component_add) from [<c0403a38>] (platform_drv_probe+0x50/0xb0)
[<c0403a38>] (platform_drv_probe) from [<c0402470>] (driver_probe_device+0x1f0/0x2a8)
[<c0402470>] (driver_probe_device) from [<c0400a54>] (bus_for_each_drv+0x44/0x8c)
[<c0400a54>] (bus_for_each_drv) from [<c04021f8>] (__device_attach+0x9c/0x100)
[<c04021f8>] (__device_attach) from [<c04018e8>] (bus_probe_device+0x84/0x8c)
[<c04018e8>] (bus_probe_device) from [<c0401d1c>] (deferred_probe_work_func+0x60/0x8c)
[<c0401d1c>] (deferred_probe_work_func) from [<c012fc14>] (process_one_work+0x120/0x318)
[<c012fc14>] (process_one_work) from [<c012fe34>] (process_scheduled_works+0x28/0x38)
[<c012fe34>] (process_scheduled_works) from [<c0130048>] (worker_thread+0x204/0x4ac)
[<c0130048>] (worker_thread) from [<c01352c4>] (kthread+0xd8/0xf4)
[<c01352c4>] (kthread) from [<c0107978>] (ret_from_fork+0x14/0x3c)
Code: e59035f0 e5935018 f57ff04f e3c55001 (f57ff04e)
---[ end trace 3d1d0d87796de344 ]---
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1483091866-1088-1-git-send-email-m.szyprowski@samsung.com

Port of radeon change to amdgpu.
Acked-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=98897
https://bugs.launchpad.net/bugs/1651981Acked-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Cc: Adrian Fiergolski <A.Fiergolski@gmail.com>

Use the appropriate smc firmware for each chip revision.
Using the wrong one can cause stability issues.
Acked-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Use the appropriate smc firmware for each chip revision.
Using the wrong one can cause stability issues.
Acked-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NFlora Cui <Flora.Cui@amd.com>
Reviewed-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

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

At two gpu core condition, static integer will cause that second gpu
core uvd state setting will be directly skipped due to the first one
setting
Signed-off-by: NYintian Tao <yttao@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NKen Wang  <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NKen Wang  <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

v2: agd: squash in various fixes
v3: agd: squash in:
drm/amdgpu: remove unnecessary smc sk firmware for polaris12
Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NKen Wang  <Qingqing.Wang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

So they can figure out what is the optimal number of pages
that can be contingously stitched together without fear of
bounce buffer.

We also expose an mechanism for sub-users of SWIOTLB API, such
as Xen-SWIOTLB to set the max segment value. And lastly
if swiotlb=force is set (which mandates we bounce buffer everything)
we set max_segment so at least we can bounce buffer one 4K page
instead of a giant 512KB one for which we may not have space.
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reported-and-Tested-by: NJuergen Gross <jgross@suse.com>

This commit fixes the VDAC disabling register write values.

Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

When the HDMI output is configured by the bootloader, there is mismatch is the
pipeline configuration and the Vsync interrupt fails to trigger.

This commit disables the HDMI blocks in the probe phase.

Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

If waiting for fences fails for blocking commits, planes must be cleaned
up before returning.

Cc: stable@vger.kernel.org
Fixes: f6ce410a ("drm/fence: allow fence waiting to be interrupted by userspace")
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170102231427.7192-1-laurent.pinchart@ideasonboard.com

Revision 2 of LCDC suffers from an issue where a SYNC_LOST error
caused by limited memory bandwidth may leave the picture shifted a
couple pixels to the right.

This issue has not been observed on revision 1, while the recovery
mechanism introduces a different issue, where the END_OF_FRAME
interrupt doesn't fire while drm is waiting for vblanks.

On rev1: recover from sync lost errors by simply clearing the
RASTER_ENABLE bit in the RASTER_CTRL register and re-enabling it
again as is suggested by the datasheet.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NJyri Sarha <jsarha@ti.com>

As the fence may be signaled concurrently from an interrupt on another
device, it is possible for the list of requests on the timeline to be
modified as we walk it. Take both (the context's timeline and the global
timeline) locks to prevent such modifications.

Fixes: 80b204bc ("drm/i915: Enable multiple timelines")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-10-chris@chris-wilson.co.uk
(cherry picked from commit 00c25e3f)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

As trimming the sg table is merely an optimisation that gracefully fails
if we cannot allocate a new table, we do not need to report the failure
either.

Fixes: 0c40ce13 ("drm/i915: Trim the object sg table")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-4-chris@chris-wilson.co.uk
(cherry picked from commit 8bfc478f)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we teardown the backing storage for the phys object, we copy from
the coherent contiguous block back to the shmemfs object, clflushing as
we go. Trying to clflush the invalid sg beforehand just oops and would
be redundant (due to it already being coherent, and clflushed
afterwards).
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161223145804.6605-3-chris@chris-wilson.co.uk
(cherry picked from commit e5facdf9)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The vma will be NULL if the overlay was previously off, so
dereferencing it will oops. Check for NULL before doing that.

Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Fixes: 9b3b7841 ("drm/i915/overlay: Use VMA as the primary tracker for images")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1481131693-27993-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 4a15cdbb)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The i915_gem_active stuff doesn't like a NULL ->retire hook, but
the overlay code can set it to NULL. That obviously ends up oopsing.
Fix it by introducing a new helper to assign the retirement callback
that will switch out the NULL function pointer with
i915_gem_retire_noop.

Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Fixes: 0d9bdd88 ("drm/i915: Convert intel_overlay to request tracking")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20161207175647.10018-1-chris@chris-wilson.co.uk
(cherry picked from commit ecd9caa0)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Initialize overlay->last_flip properly instead of leaving it zeroed.

Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: 0d9bdd88 ("drm/i915: Convert intel_overlay to request tracking")
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161221144547.27319-1-ville.syrjala@linux.intel.com
(cherry picked from commit 330afdb1)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Trying to determine the pixel rate of the pipe can't be done until we
know the clock, which means it can't be done until the encoder
.get_config() hooks have been called. So let's move the min_pixclk[]
stuff to the end of intel_modeset_readout_hw_state() when we actually
have gathered all the required infromation.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Fixes: 565602d7 ("drm/i915: Do not acquire crtc state to check clock during modeset, v4.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161220153902.15621-1-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
(cherry picked from commit aca1ebf4)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Apparently some VLV BIOSen like to leave the VDD force bit enabled
even for power seqeuncers that aren't properly hooked up to any
port. That will result in a imbalance in the AUX power domain
refcount when we stat to use said power sequencer as edp_panel_vdd_on()
will not grab the power domain reference if it sees that the VDD is
already on.

To fix this let's make sure we turn off the VDD force bit when we
initialize the power sequencer registers. That is, unless it's
being done from the init path since there we are actually
initializing the registers for the current power sequencer and
we don't want to turn VDD off needlessly as that would require
waiting for the power cycle delay before we turn it back on.

This fixes the following kind of warnings:
WARNING: CPU: 0 PID: 123 at ../drivers/gpu/drm/i915/intel_runtime_pm.c:1455 intel_display_power_put+0x13a/0x170 [i915]()
WARN_ON(!power_domains->domain_use_count[domain])
...

v2: Fix typos in comment (David)

Cc: stable@vger.kernel.org
Cc: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Tested-by: NMatwey V. Kornilov <matwey.kornilov@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98695Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161220165117.24801-1-ville.syrjala@linux.intel.comReviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
(cherry picked from commit 5d5ab2d2)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When no CRTC is associated with the plane, the meson_plane_atomic_check()
call breaks the kernel with an Oops.

Fixes: bbbe775e ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>

Abstract access to mdev_device so that we can define which interfaces
are public rather than relying on comments in the structure.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Reviewed-by: NJike Song <jike.song@intel.com>
Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>

Rather than hoping for good behavior by marking some elements
internal, enforce it by making the entire structure private and
creating an accessor function for the one useful external field.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Jike Song <jike.song@intel.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>

Add an mdev_ prefix so we're not poluting the namespace so much.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Jike Song <jike.song@intel.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Reviewed by: Kirti Wankhede <kwankhede@nvidia.com>

For every submission buffer object one of MSM_SUBMIT_BO_WRITE
and MSM_SUBMIT_BO_READ must be set (and nothing else). If we
allowed zero then the buffer object would never get queued to
be unreferenced.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The error cases in submit_reloc() need to put back the virtual
address of the bo before failling. Add a single failure path
for the function.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Currently the value written to CP_RB_WPTR is calculated on the fly as
(rb->next - rb->start). But as the code is designed rb->next is wrapped
before writing the commands so if a series of commands happened to
fit perfectly in the ringbuffer, rb->next would end up being equal to
rb->size / 4 and thus result in an out of bounds address to CP_RB_WPTR.

The easiest way to fix this is to mask WPTR when writing it to the
hardware; it makes the hardware happy and the rest of the ringbuffer
math appears to work and there isn't any point in upsetting anything.
Signed-off-by: NJordan Crouse <jcrouse@codeaurora.org>
[squash in is_power_of_2() check]
Signed-off-by: NRob Clark <robdclark@gmail.com>

PCI basic config space's size is 256 bytes. When check if access crosses
space range, should use "> 256".
Signed-off-by: NPei Zhang <pei.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

There's an issue in current cfg space emulation for PCI_COMMAND (offset
0x4): when guest changes some bits other than PCI_COMMAND_MEMORY, this
write operation will not be written to virutal cfg space successfully.

This patch is to fix the wrong behavior above.
Signed-off-by: NMin He <min.he@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Don't introduce local variables unless necessary.
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The release action might be triggered from either user's closing
mdev or the detaching event of kvm and vfio_group, so this patch
introduces an atomic to prevent double-release.
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

gfn_to_memslot() may return NULL if the gfn is mmio
or invalid. A malicious user might input a bad gfn
to panic the host if we don't check it.
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Though there is no issue exposed yet, it's possible that another
thread releases the entry while our trying to deref it out of the
lock. Fit it by moving the dereference within lock.
Signed-off-by: NJike Song <jike.song@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The GGTT space is partitioned between vGPUs, it could be reused by
next vGPU after previous one is release, the stale entries need
point to scratch page when vGPU created.

v2: Reset logic move to vGPU create.
v3: Correct the commit msg.
v4: Move the reset function to vGPU init gtt function, as result it's no
    need explicitly in vGPU reset logic as vGPU init gtt called during
    reset.
Signed-off-by: NPing Gao <ping.a.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

It should be vgpu_opregion(vgpu)->va, not vgpu_opregion(vgpu).
Signed-off-by: NMin He <min.he@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>