batch of scattered i915 fixes.
* tag 'drm-intel-fixes-2016-11-01' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation
drm/i915: Remove two invalid warns
drm/i915: Rotated view does not need a fence
drm/i915/fbc: fix CFB size calculation for gen8+
drm: i915: Wait for fences on new fb, not old
drm/i915: Clean up DDI DDC/AUX CH sanitation
drm/i915: Respect alternate_aux_channel for all DDI ports
drm/i915/gen9: fix watermarks when using the pipe scaler
drm/i915: Fix mismatched INIT power domain disabling during suspend
drm/i915: fix a read size argument
drm/i915: Use fence_write() from rpm resume
drm/i915/gen9: fix DDB partitioning for multi-screen cases
drm/i915: workaround sparse warning on variable length arrays
drm/i915: keep declarations in i915_drv.h
- some fixes for active plane reconfiguration support
- hide unused label in case of disabled CONFIG_DRM_FBDEV_EMULATION,
which caused a build warning
- fixed error handling in imx_drm_bind
- disallow odd x/y plane offsets for chroma subsampled formats
- disable local alpha when switching from a format with alpha
channel to an opaque format
-----BEGIN PGP SIGNATURE-----
iQI0BAABCAAeBQJYCbk/FxxwLnphYmVsQHBlbmd1dHJvbml4LmRlAAoJEFDCiBxw
nmDrGMYQAJMx6LoCTJ7hfr59R4IvmST0tRcVTKO4Grux8JPfu7WtDaFNhfew4ltA
Nt38lbawzBBJ3jmbayGzpHmeEDdZh8T0LbYqzqWNRjergQ5V0qCXcxLKuvrRW9NC
H0QmJmbiZm9EDani7Xh1yOF51n1g37FVq7+qROr9J7oHz/xjJw523XwSiLAR9pgs
QMmw5zrPNqu93pRCLtm5/4puVMOYQfHmE8l8WYV2zIvjck1D+rkRFv5+DJwpDZjO
jpvq3ZrHSFHM12wk0S5jsLUwFs2cqHb16ETitGP9gB7MnkPZ7qwgTTfio3JDpuL8
orKpTcjDPVxPfVmbS5Hv/iNNq8YMz1VrJNp7y/ZCgTqNl/877f9nmeHKXdolMWMc
xN5gDrd0atzHJKhsxp6bOYDhp861C1Nm+gtuNs2lRHsKANUa9SKh+gcyEC+CfqaU
PdKx0E0lQcjjWjW2UYseQmjePjIclPzgCw1V6PHJOkOFBz8wQm8EHH4BcqBsx2zP
v/ew3s/dk00IWi6e6/M7/hDM2vgXGIvw1AV8FHqMcBgSs/4GqVbGxJF+HIDqTX5s
257nDdm+23eA8yvg+XbtYqlP0G7r7XV1KQLiMoFNJEj8+OjFfHPotphhX0kh8eWu
quhY4yKlrOrzrm7wrCEOXhfwSfKhO4BF1lgh3jzqKzfWYtckgXOh
=lgaf
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-20161021' of git://git.pengutronix.de/pza/linux into drm-fixes
imx-drm plane, build warning, and error handling fixes
- some fixes for active plane reconfiguration support
- hide unused label in case of disabled CONFIG_DRM_FBDEV_EMULATION,
which caused a build warning
- fixed error handling in imx_drm_bind
- disallow odd x/y plane offsets for chroma subsampled formats
- disable local alpha when switching from a format with alpha
channel to an opaque format
* tag 'imx-drm-fixes-20161021' of git://git.pengutronix.de/pza/linux:
drm/imx: ipuv3-plane: disable local alpha for planes without alpha channel
drm/imx: ipuv3-plane: make sure x/y offsets are even in case of chroma subsampling
drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12
drm/imx: drm_dev_alloc() returns error pointers
drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't need modeset
drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset
gpu: ipu-v3: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
drm/imx: hide an unused label
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: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.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: 692a17dcc2 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398
Reported-and-tested-by: Rick Kerkhof <rick.2889@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pass the framebuffer size in .16 fixed point coordinates to
drm_rect_rotate() since that's what the source coordinates are as well
at this stage. We used to do this part of the computation in integer
coordinates, but that got changed when moving the computation to
happen in the check phase of the operation. Unfortunately I forgot
to shift up the fb width and height appropriately.
With the bogus size we ended up with some negative fb offset, which when
added to the vma offset caused out scanout to start at an offset earlier
than we inteded. Eg. when testing on my SKL I saw a row of incorrect
tiles at the top of my screen.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: b63a16f6cd ("drm/i915: Compute display surface offset in the plane check hook for SKL+")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477325584-23679-1-git-send-email-ville.syrjala@linux.intel.com
Tested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit da064b47c0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Objects can have multiple VMAs used for display in which
case assertion that objects must not be pinned for display
more times than the current VMA is incorrect.
v2: Commit message update. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 058d88c433 ("drm/i915: Track pinned VMA")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1477413635-3876-1-git-send-email-tvrtko.ursulin@linux.intel.com
(cherry picked from commit 3299e7e434)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We do not need to set up a fence for the rotated view.
Display does not need it and no one can access it.
v2: Move code to __i915_vma_set_map_and_fenceable. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 05a20d098d ("drm/i915: Move map-and-fenceable tracking to the VMA")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 07ee2bce6a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Broadwell and newer actually compress up to 2560 lines instead of 2048
(as documented in the FBC_CTL page). If we don't take this into
consideration we end up reserving too little stolen memory for the
CFB, so we may allocate something else (such as a ring) right after
what we reserved, and the hardware will overwrite it with the contents
of the CFB when FBC is active, causing GPU hangs. Another possibility
is that the CFB may be allocated at the very end of the available
space, so the CFB will overlap the reserved stolen area, leading to
FIFO underruns.
This bug has always been a problem on BDW (the only affected platform
where FBC is enabled by default), but it's much easier to reproduce
since the following commit:
commit c58b735fc7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Aug 18 17:16:57 2016 +0100
drm/i915: Allocate rings from stolen
Of course, you can only reproduce the bug if your screen is taller
than 2048 lines.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98213
Fixes: a98ee79317 ("drm/i915/fbc: enable FBC by default on HSW and BDW")
Cc: <stable@vger.kernel.org> # v4.6+
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1477065346-13736-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit 79f2624b1b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The previous code would wait for fences on the framebuffer from the old
plane state to complete, rather than the new, so you would see tearing
everywhere. Fix this to wait on the new state before we make it active.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes: 94f050246b ("drm/i915: nonblocking commit")
Cc: stable@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161021144454.6288-1-daniels@collabora.com
(cherry picked from commit 2d2c5ad83f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that we use the AUX and GMBUS assignment from VBT for all ports,
let's clean up the sanitization of the port information a bit.
Previosuly we only did this for port E, and only complained about a
non-standard assignment for the other ports. But as we know that
non-standard assignments are a fact of life, let's expand the
sanitization to all the ports.
v2: Include a commit message, fix up the comments a bit
v3: Don't clobber other ports if the current port has no alternate aux ch/ddc pin
Cc: stable@vger.kernel.org
Cc: Maarten Maathuis <madman2003@gmail.com>
Tested-by: Maarten Maathuis <madman2003@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (v2)
(cherry picked from commit 9454fa871e)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The VBT provides the platform a way to mix and match the DDI ports vs.
AUX channels. Currently we only trust the VBT for DDI E, which has no
corresponding AUX channel of its own. However it is possible that some
board might use some non-standard DDI vs. AUX port routing even for
the other ports. Perhaps for signal routing reasons or something,
So let's generalize this and trust the VBT for all ports.
For now we'll limit this to DDI platforms, as we trust the VBT a bit
more there anyway when it comes to the DDI ports. I've structured
the code in a way that would allow us to easily expand this to
other platforms as well, by simply filling in the ddi_port_info.
v2: Drop whitespace changes, keep MISSING_CASE() for unknown
aux ch assignment, include a commit message, include debug
message during init
Cc: stable@vger.kernel.org
Cc: Maarten Maathuis <madman2003@gmail.com>
Tested-by: Maarten Maathuis <madman2003@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
(cherry picked from commit 8f7ce038f1)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Luckily, the necessary adjustments for when we're using the scaler are
exactly the same as the ones needed on ILK+, so just reuse the
function we already have.
v2: Invert the patch order so stable backports get easier.
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475872138-16194-1-git-send-email-paulo.r.zanoni@intel.com
(cherry picked from commit cfd7e3a202)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently the display INIT power domain disabling/enabling happens in a
mismatched way in the suspend/resume_early hooks respectively. This can
leave display power wells incorrectly disabled in the resume hook if the
suspend sequence is aborted for some reason resulting in the
suspend/resume hooks getting called but the suspend_late/resume_early
hooks being skipped. In particular this change fixes "Unclaimed read
from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()->
intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set
to devices.
Fixes: 85e9067933 ("drm/i915: disable power wells on suspend")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: David Weinehall <david.weinehall@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476358446-11621-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 4c494a5769)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We want to read 3 bytes here, but because the parenthesis are in the
wrong place we instead read:
sizeof(intel_dp->edp_dpcd) == sizeof(intel_dp->edp_dpcd)
which is one byte.
Fixes: fe5a66f91c ("drm/i915: Read PSR caps/intermediate freqs/etc. only once on eDP")
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <drm-intel-fixes@lists.freedesktop.org>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161013085508.GJ16198@mwanda
(cherry picked from commit f7170e2eb8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix sparse warning:
drivers/gpu/drm/i915/intel_device_info.c:195:31: warning: Variable
length array is used.
In truth the array does have constant length, but sparse is too dumb to
realize. This is a bit ugly, but silence the warning no matter what.
Fixes: 91bedd34ab ("drm/i915/bdw: Check for slice, subslice and EU count for BDW")
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475574853-4178-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit ff64aa1e63)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix sparse warnings:
drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol
'i915_driver_load' was not declared. Should it be static?
drivers/gpu/drm/i915/i915_drv.c:1267:6: warning: symbol
'i915_driver_unload' was not declared. Should it be static?
drivers/gpu/drm/i915/i915_drv.c:2444:25: warning: symbol 'i915_pm_ops'
was not declared. Should it be static?
Fixes: 42f5551d27 ("drm/i915: Split out the PCI driver interface to i915_pci.c")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1473946137-1931-3-git-send-email-jani.nikula@intel.com
(cherry picked from commit efab0698f9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Two sets of amdgpu fixes as I missed one set.
* 'drm-fixes-4.9' of git://people.freedesktop.org/~agd5f/linux: (23 commits)
drm/amd/powerplay: fix bug get wrong evv voltage of Polaris.
drm/amdgpu/si_dpm: workaround for SI kickers
drm/radeon/si_dpm: workaround for SI kickers
drm/amdgpu: fix s3 resume back, uvd dpm randomly can't disable.
drm/radeon: drop register readback in cayman_cp_int_cntl_setup
drm/amdgpu/vce3: only enable 3 rings on new enough firmware (v2)
drm/amdgpu: fix fence slab teardown
drm/amdgpu: update kernel-doc for some functions
drm/amdgpu: fix a vm_flush fence leak
drm/amdgpu: fix sched fence slab teardown
Revert "drm/radeon: fix DP link training issue with second 4K monitor"
drm/amdgpu/dpm: flush any thermal work on fini
drm/amdgpu: cancel reset work on fini
drm/amd/powerplay: don't give up if DPM is already running
drm/amd/powerplay: fix static checker warning in process_pptables_v1_0.c
drm/amdgpu: avoid drm error log during S3 on RHEL7.3
drm/amdgpu: explicitly set pg_flags for ST
drm/amdgpu/st: move ATC CG golden init from gfx to mc
drm/amd/amdgpu: expose max engine and memory clock for powerplay enabled case
drm/amdgpu: move atom scratch register save/restore to common code
...
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Consolidate existing quirks. Fixes stability issues
on some kickers.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
the value of last_mclk_dpm_enable_mask will be changed if
other clients(vce,dal) trigger set power state between enable
and disable uvd dpm.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The i2c adapter is only relevant for some peer device types, so
let's clear the pdt if it's still the same as the old_pdt when we
tear down the i2c adapter.
I don't really like this design pattern of updating port->whatever
before doing the accompanying changes and passing around old_whatever
to figure stuff out. Would make much more sense to me to the pass the
new value around and only update the port->whatever when things are
consistent. But let's try to work with what we have right now.
Quoting a follow-up from Ville:
"And naturally I forgot to amend the commit message w.r.t. this guy
[the change in drm_dp_destroy_port]. We don't really need to do this
here, but I figured I'd try to be a bit more consistent by having it,
just to avoid accidental mistakes if/when someone changes this stuff
again later."
v2: Clear port->pdt in the caller, if needed (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com> (v1)
Tested-by: Kirill A. Shutemov <kirill@shutemov.name> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477488633-16544-1-git-send-email-ville.syrjala@linux.intel.com
The fbdev helper code keeps around two lists of connectors. One is the
list of all connectors it could use, and that list already holds
references for all the connectors. However the other list, or rather
lists, is the one actively being used. That list is tracked per-crtc
and currently doesn't hold any extra references. Let's grab those
extra references to avoid oopsing when the connector vanishes. The
list of all possible connectors should get updated when the hpd happens,
but the list of actively used connectors would not get updated until
the next time the fb-helper picks through the set of possible connectors.
And so we need to hang on to the connectors until that time.
Since we need to clean up in drm_fb_helper_crtc_free() as well,
let's pull the code to a common place. And while at it let's
pull in up the modeset->mode cleanup in there as well. The case
of modeset->fb is a bit less clear. I'm thinking we should probably
hold a reference to it, but for now I just slapped on a FIXME.
v2: Cleanup things drm_fb_helper_crtc_free() too (Chris)
v3: Don't leak modeset->connectors (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com> (v1)
Tested-by: Kirill A. Shutemov <kirill@shutemov.name> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477492878-4990-1-git-send-email-ville.syrjala@linux.intel.com
We don't want all planes to be added to the state whenever a
plane with fixed zpos gets enabled/disabled. This is true
especially for eg. cursor planes on i915, as we want cursor
updates to go through w/o throttling. Same holds for drivers
that don't support zpos at all (i915 actually falls into this
category right now since we've not yet added zpos support).
Allow drivers more freedom by letting them deal with zpos
themselves instead of doing it in drm_atomic_helper_check_planes()
unconditionally. Let's just inline the required calls into all
the driver that currently depend on this.
v2: Inline the stuff into the drivers instead of adding another
helper, document things better (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Lyude <cpaul@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: stable@vger.kernel.org
Fixes: 44d1240d00 ("drm: add generic zpos property")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1476111056-12734-1-git-send-email-ville.syrjala@linux.intel.com
We need to drop the connector references already taken when we
abort in the middle of drm_fb_helper_single_add_all_connectors()
Cc: stable@vger.kernel.org
Cc: Carlos Santa <carlos.santa@intel.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Tested-by: Carlos Santa <carlos.santa@intel.com>
Tested-by: Kirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-2-git-send-email-ville.syrjala@linux.intel.com
Since 4.7 kernel, we've seen the error messages like
kernel: [TTM] Buffer eviction failed
kernel: qxl 0000:00:02.0: object_init failed for (4026540032, 0x00000001)
kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed to allocate VRAM BO
on QXL when switching and accessing on VT. The culprit was the
generic deferred_io code (qxl driver switched to it since 4.7).
There is a race between the dirty clip update and the call of
callback.
In drm_fb_helper_dirty(), the dirty clip is updated in the spinlock,
while it kicks off the update worker outside the spinlock. Meanwhile
the update worker clears the dirty clip in the spinlock, too. Thus,
when drm_fb_helper_dirty() is called concurrently, schedule_work() is
called after the clip is cleared in the first worker call.
This patch addresses it by validating the clip before calling the
dirty fb callback.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98322
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1003298
Fixes: eaa434defa ('drm/fb-helper: Add fb_deferred_io support')
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161020150530.5787-1-tiwai@suse.de
drm_property_lookup_blob() returns a reference to the returned blob, and
drm_atomic_replace_property_blob() takes a references to the blob it
stores, so afterwards we are left owning a reference to the new_blob that
we never release, and thus leak memory every time we update a property
such as during drm_atomic_helper_legacy_gamma_set().
v2: update credentials, drm_property_unreference_blob() is NULL safe and
NULL is passed consistently to it throughout drm_atomic.c so do so here.
Reported-by: Felix Monninger <felix.monninger@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98420
Signed-off-by: Felix Monninger <felix.monninger@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Fixes: 5488dc16fd ("drm: introduce pipe color correction properties")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161025212808.3908-1-chris@chris-wilson.co.uk
This fixes a regression in all these drivers since the cache
mode tracking was fixed for mixed mappings. It uses the new
arch API to add the VRAM range to the PAT mapping tracking
tables.
Fixes: 87744ab383 (mm: fix cache mode tracking in vm_insert_mixed())
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The read is taking a considerable amount of time (about 50us on this
machine). The register does not ever hold anything other than the ring
ID that is updated in this exact function, so there is no need for
the read modify write cycle.
This chops off a big chunk of the time spent in hardirq disabled
context, as this function is called multiple times in the interrupt
handler. With this change applied radeon won't show up in the list
of the worst IRQ latency offenders anymore, where it was a regular
before.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Older firmware versions don't support 3 rings.
fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=98016
v2: use define for fw version
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To free fences, call_rcu() is used, which calls amdgpu_fence_free()
after a grace period. During teardown, there is no guarantee all
callbacks have finished, so amdgpu_fence_slab may be destroyed before
all fences have been freed. If we are lucky, this results in some slab
warnings, if not, we get a crash in one of rcu threads because callback
is called after amdgpu has already been unloaded.
Fix it with a rcu_barrier().
Fixes: b44135351a ("drm/amdgpu: RCU protected amdgpu_fence_release")
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The names were wrong.
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Looks like .last_flush reference is left at teardown.
Leak reported by CONFIG_SLUB_DEBUG.
Fixes: 41d9eb2c5a ("drm/amdgpu: add a fence after the VM flush")
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
To free fences, call_rcu() is used, which calls amd_sched_fence_free()
after a grace period. During teardown, there is no guarantee all
callbacks have finished, so sched_fence_slab may be destroyed before
all fences have been freed. If we are lucky, this results in some slab
warnings, if not, we get a crash in one of rcu threads because callback
is called after amdgpu has already been unloaded.
Fix it with a rcu_barrier().
Fixes: 189e0fb763 ("drm/amdgpu: RCU protected amd_sched_fence_release")
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 1a738347df.
It caused at least some Kaveri laptops to incorrectly report DisplayPort
connectors as connected.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97857
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Flush any outstanding thermal work before tearing down
the dpm driver.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cancel any pending reset work when we tear down the driver.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Currently the driver crashes if smu7_enable_dpm_tasks() returns early,
which it does if DPM is already active. It seems to be better just to
continue anyway, at least I haven't noticed any ill effects. It's also
unclear at what state the hardware was left by the previous driver, so
IMO it's better to always fully initialize.
Way to reproduce:
with GPU passthrough.
forced power off the VM or forced reset the VM
without shutting down the Os.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Reviewed-by: Edward O'Callaghan <funfunctor@folklore1984.net>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
No need to retain previous settings as this is the first time
we set pg_flags. Probably a copy/paste typo from the CZ code.
Avoids confusion.
No change in behavior as adev is kzallocated.
Reviewed-by: Tom St Denis <tom.stdenis@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's technically an MC register so make sure we initialize it
in the MC module rather than the gfx module. Since other bits
in the same register are used to enable ATC CG features make
sure we apply the golden setting first.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need this for more than just DCE. Move it out of the DCE modules
and into the device code. This way we can be sure the scratch registers
are initialized properly before we run asic_init which happens before
DCE IPs are restored.
Fixes atombios hangs in asic_init.
Reviewed-by: JimQu <Jim.Qu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is already handled by the dce IP modules in their
suspend and resume code. No need to do it again.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Limit clocks on a specific HD86xx part to avoid
crashes (while awaiting an appropriate PP fix).
Signed-off-by: Tom St Denis <tom.stdenis@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
