When the QXL driver receives a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG interrupt,
we currently always notify userspace that there was some hotplug event.

However, gnome-shell/mutter is reacting to this event by attempting a
resolution change, which it does by issueing drmModeRmFB, drmModeAddFB,
and then drmModeSetCrtc. This has the side-effect of causing
qxl_crtc_mode_set() to tell the QXL virtual hardware that a primary
surface was destroyed and created. After going through QEMU and then the
remote SPICE client, a new identical monitors config message will be
sent, resulting in a QXL_INTERRUPT_CLIENT_MONITORS_CONFIG interrupt to
be emitted, and the same scenario occurring again.

As destroying/creating the primary surface causes a visible screen
flicker, this makes the guest hard to use (
https://bugzilla.redhat.com/show_bug.cgi?id=1266484 ).

This commit checks if the screen configuration we received is the same
one as the current one, and does not notify userspace about it if that's
the case.
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Acked-by: NFrediano Ziglio <fziglio@redhat.com>
Message-id: 20161108091209.25568-7-cfergeau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

It's always returning 0, and it's always ignored.
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Acked-by: NFrediano Ziglio <fziglio@redhat.com>
Message-id: 20161108091209.25568-6-cfergeau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

qdev->gem.objects was initialized directly in qxl_device_init() rather
than going through qxl_gem_init(), and qxl_gem_fini() was never called.
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Message-id: 20161108091209.25568-5-cfergeau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The message has to be terminated by a newline as it's not going to get
added automatically.
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Acked-by: NFrediano Ziglio <fziglio@redhat.com>
Message-id: 20161108091209.25568-4-cfergeau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

qxl_crtc_set_from_monitors_config() is defined in qxl_drv.h but never
implemented.
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Acked-by: NFrediano Ziglio <fziglio@redhat.com>
Message-id: 20161108091209.25568-3-cfergeau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

They are not used outside of their respective source file
Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com>
Acked-by: NFrediano Ziglio <fziglio@redhat.com>
Message-id: 20161108091209.25568-2-cfergeau@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

This reverts commit c2cbc38b.

Commit "drm/virtio: fix busid regression" is a better fix.

Created by commit a3257256.
busid changes and userspace is upset.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

We still need it, for virtio-gpu for example.
Partial revert of commit a742946a.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Thou shall not send control msg from the stack,
does that mean I can send it from the RO memory area?

and it looks like the answer is no, so here's
v2 which kmemdups.

Reported-by: poma
Tested-by: Npoma <poma@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

iceland use pptable v0.

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=185681
https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-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>

Only check if the tables exist in relevant configs.  This
fixes a failure on V0 tables.

v2: fix version check as suggested by Rex

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=185681
https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Was missing the handling for iceland.

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=185681
https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Missing for one case.

bugs:
https://bugzilla.kernel.org/show_bug.cgi?id=185681
https://bugs.freedesktop.org/show_bug.cgi?id=98357Reviewed-by: NRex Zhu <Rex.Zhu@amd.com>
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If the DC clock is disabled before the attached IDMACs are properly
stopped the IDMACs may hang the IPU or even the whole system.

Make sure the IDMACs are in safe state by disabling the planes before
removal of the DC clock.

Also set the atomic parameter to false to stop calling the atomic_begin
hook, which does nothing useful as we immediately afterwards turn off
vblank interrupts and possibly send the pending vblank event.

Fixes: 33f14235 (drm/imx: atomic phase 1: Use transitional atomic
                     CRTC and plane helpers)
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>

Returning -EINVAL from a bool-returning function
phm_check_smc_update_required_for_display_configuration has an unexpected
effect of returning true, which is probably not what was intended.
Replace -EINVAL by false.

The only place this function is called from is
psm_adjust_power_state_dynamic in
drivers/gpu/drm/amd/powerplay/eventmgr/psm.c:106:

	if (!equal || phm_check_smc_update_required_for_display_configuration(hwmgr)) {
		phm_apply_state_adjust_rules(hwmgr, requested, pcurrent);
		phm_set_power_state(hwmgr, &pcurrent->hardware, &requested->hardware);
		hwmgr->current_ps = requested;
	}

It seems to expect a boolean value here.

This issue has been found using the following Coccinelle semantic patch
written by Peter Senna Tschudin:
<smpl>
@@
identifier f;
constant C;
typedef bool;
@@
bool f (...){
<+...
* return -C;
...+>
}
</smpl>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAndrew Shadura <andrew.shadura@collabora.co.uk>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

A recent bugfix replaced an out-of-bounds access with direct
use of unintialized data:

drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c: In function 'smu7_patch_limits_vddc':
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2146:11: note: 'vddc' was declared here
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2033:6: error: 'vddci' may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c:2146:17: note: 'vddci' was declared here
  uint32_t vddc, vddci;

This initializes the data as before using the correct type.

Fixes: 77f7f71f ("drm/amdgpu/powerplay/smu7: fix static checker warning")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

On CZ/ST systems with AZ rather than ACP audio, we need to bail
early in hw_fini since there is nothing to do.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=98276Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Valleyview appears to be limited to only scanning out from the first 512MiB
of the Global GTT. Lets presume that this behaviour was inherited from the
display block copied from g4x (not Ironlake) and all earlier generations
are similarly affected, though testing suggests different symptoms. For
simplicity, impose that these platforms must scanout from the mappable
region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this
catches Cherryview which does not appear to be limited to the low
aperture for its scanout.)

v2: Use HAS_GMCH_DISPLAY() to more clearly convey my intent about
limiting this workaround to the old style of display engine.

v3: Update changelog to reflect testing by Ville Syrjälä
v4: Include the changes to the comments as well
Reported-by: NLuis Botello <luis.botello.ortega@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98036
Fixes: 2efb813d ("drm/i915: Fallback to using unmappable memory for scanout")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20161107110128.28762-1-chris@chris-wilson.co.ukReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 767a222e)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

When we split a large object up into chunks for GTT faulting (because we
can't fit the whole object into the aperture) we have to align our cuts
with the fence registers. Each partial VMA must cover a complete set of
tile rows or the offset into each partial VMA is not aligned with the
whole image. Currently we enforce a minimum size on each partial VMA,
but this minimum size itself was not aligned to the tile row causing
distortion.
Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Reported-by: NChris Clayton <chris2553@googlemail.com>
Reported-by: NNorbert Preining <preining@logic.at>
Tested-by: NNorbert Preining <preining@logic.at>
Tested-by: NChris Clayton <chris2553@googlemail.com>
Fixes: 03af84fe ("drm/i915: Choose partial chunksize based on tile row size")
Fixes: a61007a8 ("drm/i915: Fix partial GGTT faulting") # enabling patch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98402
Testcase: igt/gem_mmap_gtt/medium-copy-odd
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20161107105443.27855-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit 0ef723cb)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.

Let's apply this work around to GEN9 platforms too, as it fixes the same
issue.

v2: Move drm_device to drm_i915_private conversion

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
Cc: stable@vger.kernel.org
Cc: Libin Yang <libin.yang@linux.intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478117601-19122-1-git-send-email-dhinakaran.pandiyan@intel.com
(cherry picked from commit 9c754024)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.

From BSpec:
"Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)]
Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio
enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may
be audio corruption or screen corruption."

Since, some DP configurations (e.g., MST) use port width x4 and HBR2
link rate, let's increase the cdclk to >= 432 MHz to enable audio for those
cases.

v4: Changed commit message
v3: Combine BDW pixel rate adjustments into a function (Jani)
v2: Restrict fix to BDW
    Retain the set cdclk across modesets (Ville)
Cc: stable@vger.kernel.org
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1478026080-2925-1-git-send-email-dhinakaran.pandiyan@intel.com

(cherry picked from commit b30ce9e0)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

One of the CI machines began to run into issues with the hpd poller
suddenly waking up in the midst of the late suspend phase. It looks like
this is getting caused by the fact we now deinitialize power wells in
late suspend, which means that intel_hpd_poll_init() gets called in late
suspend causing polling to get re-enabled. So, when deinitializing power
wells on valleyview we now refrain from enabling polling in the midst of
suspend.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98040
Fixes: 19625e85 ("drm/i915: Enable polling when we don't have hpd")
Signed-off-by: NLyude <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Saarinen <jani.saarinen@intel.com>
Cc: Petry Latvala <petri.latvala@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477499769-1966-1-git-send-email-lyude@redhat.com
(cherry picked from commit b64b5409)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The VBT provides the platform a way to mix and match the DDI ports vs.
GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
has no standard GMBUS pin assignment. However, there are machines out
there that use a non-standard mapping for the other ports as well.
Let's start trusting the VBT on this one for all ports on DDI platforms.

I've structured the code such that other platforms could easily start
using this as well, by simply filling in the ddi_port_info. IIRC there
may be CHV system that might actually need this.

v2: Include a commit message, include a debug message during init

Cc: stable@vger.kernel.org
Cc: Maarten Maathuis <madman2003@gmail.com>
Tested-by: NMaarten Maathuis <madman2003@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJim Bride <jim.bride@linux.intel.com>
(cherry picked from commit e4ab73a1)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If VRAM allocation fails, the error handling path crashes in
msm_drm_uninit(). The following changes are made to fix this:

msm_gem_shrinker_cleanup() is fixed to unregister the shrinker only
if it was init-ed in the first place.

Before calling kms->funcs->destroy(), we check if kms->funcs is also
non-NULL. This is needed for MDP5, since during msm_drm_int(), priv->kms
becomes non-NULL early, but msm_kms_init() is called on it only later
in mdp5_kms_init().
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NAndy Gross <andy.gross@linaro.org>

virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and
because of that it must be called for disabled planes too.  Ask
drm_atomic_helper_commit_planes to do that.

v2: update to use new drm_atomic_helper_commit_planes() API.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRob Clark <robdclark@gmail.com>

Looks like cut/paste error from the other device cfgs (which do support
scaling on RGBn pipes).
Signed-off-by: NRob Clark <robdclark@gmail.com>

If the bottom-most layer is not fullscreen, we need to use the BASE
mixer stage for solid fill (ie. MDP5_CTL_BLEND_OP_FLAG_BORDER_OUT).  The
blend_setup() code pretty much handled this already, we just had to
figure this out in _atomic_check() and assign the stages appropriately.

Also fix the case where there are zero enabled planes, where we also
need to enable BORDER_OUT.
Signed-off-by: NRob Clark <robdclark@gmail.com>

The DSI/HDMI PLLs in MSM require resources like interface clocks, power
domains to be enabled before we can access their registers.

The clock framework doesn't have a mechanism at the moment where we can
tie such resources to a clock, so we make sure that the KMS driver enables
these resources whenever a PLL is expected to be in use.

One place where we can't ensure the resource dependencies are met is when
the clock framework tries to disable unused clocks. The KMS driver doesn't
know when the clock framework calls the is_enabled clk_op, and hence can't
enable interface clocks/power domains beforehand.

We set the CLK_IGNORE_UNUSED flag for PLL clocks for now. This needs to be
revisited, since bootloaders can enable display, and we would want to
disable the PLL clocks if there isn't a display driver using them.

Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Acked-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

The msm/dsi host drivers calls drm_helper_hpd_irq_event in the
mipi_dsi_host attach/detatch callbacks.

mipi_dsi_attach()/mipi_dsi_detach() from a panel/bridge
driver could be called from a context where the drm_device's
mode_config.mutex is already held, resulting in a deadlock.
Queue it as work instead.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

Check whether the kernel really supports power resources for a device,
otherwise the power might not be removed when the device is runtime
suspended (DSM should still work in these cases where PR does not).

This is a workaround for a problem where ACPICA and Windows 10 differ in
behavior. ACPICA does not correctly enumerate power resources within a
conditional block (due to delayed execution of such blocks) and as a
result power_resources is set to false even if _PR3 exists.

Fixes: 692a17dc ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398Reported-and-tested-by: NRick Kerkhof <rick.2889@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: NPeter Wu <peter@lekensteyn.nl>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just to be clean should we ever run into -ENOMEM during module init.

v2: fix typo in commit message
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Some fences might be alive even after we have stopped the scheduler leading
to warnings about leaked objects from the SLUB allocator.

Fix this by allocating/freeing the SLUB allocator from the module
init/fini functions just like we do it for hw fences.

v2: make variable static, add link to bug

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97500Reported-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1)
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Otherwise callers end up using uninitialized data.
Reviewed-by: NEdward O'Callaghan <funfunctor@folklore1984.net>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

This should only happen on boards TV connectors which do not
have a ddc bus for those connectors.  None of the asics supported
by amdgpu support tv, so we shouldn't hit this, but check
to be on the safe side (e.g., bios bug for example).
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

Since commit a481daa8 ("drm/radeon: always apply pci shutdown
callbacks"), a Dell Latitude D600 laptop has crashed on shutdown. The
PCI Identification of the graphics adapter is "VGA compatible controller
[0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV250/M9 GL [Mobility
FireGL 9000/Radeon 9000] [1002:4c66] (rev 01)".

Prior to commit b0c80bd5 ("drm/radeon: fix up dp aux tear down (v2)"),
I have no idea where the panic happened as the screen was blanked before
the crash.  Since that more recent change, the panic has been in routine
radeon_connector_unregister(), and has been shown to be due to a NULL
value in the ddc_bus member of struct drm_connector.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=178421
Fixes: a481daa8 ("drm/radeon: always apply pci shutdown callbacks")
Signed-off-by: NLarry Finger <Larry.Finger@lwfinger.net>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

If the platform does not support hybrid graphics or ATPX dGPU
power control.
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

If the platform does not support hybrid graphics or ATPX dGPU
power control.

bug: https://bugzilla.kernel.org/show_bug.cgi?id=51381Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Newer iceland parts require new smc firmware.
Reviewed-by: NHuang Rui <ray.huang@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org