29 Aug, 2016
1 commit
-
Due to assigning the 'replaced' value instead of or'ing it,
if drm_atomic_crtc_set_property() gets called multiple times,
the last call will define the color_mgmt_changed flag, so
a non-updating call to a property can reset the flag and
prevent actual hw state updates required by preceding
property updates.Signed-off-by: Mario Kleiner
Cc: Daniel Vetter
Cc: # v4.6+
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
26 Aug, 2016
2 commits
-
i915 fixes queue.
* tag 'drm-intel-fixes-2016-08-25' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix botched merge that downgrades CSR versions.
drm/i915/skl: Ensure pipes with changed wms get added to the state
drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
drm/i915/skl: Add support for the SAGV, fix underrun hangs
drm/i915/gen6+: Interpret mailbox error flags
drm/i915: Reattach comment, complete type specification
drm/i915: Unconditionally flush any chipset buffers before execbuf
drm/i915/gen9: Drop invalid WARN() during data rate calculation
drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization (v2) -
For reasons that entirely elude me fb.h exposes all the structures,
even when it is not enabled. Except for special stuff like fb_defio.Which means all the drivers which haven't yet switched over to the
defio support in the helpers and still roll their own, will fail
to compile when fbdev emulation is disabled. Protect just those
bits, as a gnarly reminder that conversion to the core defio helpers
would be good.Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1470847958-28465-6-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Dave Airlie
25 Aug, 2016
4 commits
-
radeon and amdgpu fixes for 4.8. Nothing major:
- fix a performance regression due to the LRU changes in 4.7
- 32 bit fixes
- fix a PLL regression
- misc bug fixes* 'drm-fixes-4.8' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: skip TV/CV in display parsing
drm/amdgpu: avoid a possible array overflow
drm/amdgpu: fix lru size grouping v2
drm/amdgpu: fix timeout value check in amd_sched_job_recovery
drm/amdgpu: fix sdma_v2_4_ring_test_ib
drm/amdgpu: fix amdgpu_move_blit on 32bit systems
drm/radeon: fix radeon_move_blit on 32bit systems
drm/radeon: only apply the SS fractional workaround to RS[78]80 -
drm/tegra: Fixes for v4.8-rc4
This contains one fix for DSI runtime power management support that was
introduced in v4.8-rc1. This is slightly more elaborate than I would've
wished, but there are a few corner cases that needed fixing.* tag 'drm/tegra/for-4.8-rc4' of git://anongit.freedesktop.org/tegra/linux:
drm/tegra: dsi: Enhance runtime power management -
No asics supported by amdgpu support analog TV.
Workaround for bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97460Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
When looking up the connector type make sure the index
is valid. Avoids a later crash if we read past the end
of the array.Workaround for bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97460Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
24 Aug, 2016
2 commits
-
Adding a BO can make it the insertion point for larger sizes as well.
v2: add a comment about the guard structure.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Felix Kuehling
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
The MIPI DSI output on Tegra SoCs requires some external logic to
calibrate the MIPI pads before a video signal can be transmitted. This
MIPI calibration logic requires to be powered on while the MIPI pads are
being used, which is currently done as part of the DSI driver's probe
implementation.This is suboptimal because it will leave the MIPI calibration logic
powered up even if the DSI output is never used.On Tegra114 and earlier this behaviour also causes the driver to hang
while trying to power up the MIPI calibration logic because the power
partition that contains the MIPI calibration logic will be powered on
by the display controller at output pipeline configuration time. Thus
the power up sequence for the MIPI calibration logic happens before
it's power partition is guaranteed to be enabled.Fix this by splitting up the API into a request/free pair of functions
that manage the runtime dependency between the DSI and the calibration
modules (no registers are accessed) and a set of enable, calibrate and
disable functions that program the MIPI calibration logic at points in
time where the power partition is really enabled.While at it, make sure that the runtime power management also works in
ganged mode, which is currently also broken.Reported-by: Jonathan Hunter
Tested-by: Jonathan Hunter
Signed-off-by: Thierry Reding
22 Aug, 2016
10 commits
-
Merge commit 5e580523d9128a4d8 reverts the version bumping parts of
commit 4aa7fb9c3c4fa0. Bump the versions again and request the specific
firmware version.The currently recommended versions are: SKL 1.26, KBL 1.01 and BXT 1.07.
Cc: Patrik Jakobsson
Cc: Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97242
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 5e580523d912 ("Backmerge tag 'v4.7' into drm-next")
Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/1471266567-22443-1-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Imre Deak
(cherry picked from commit 536ab3ca19ef856e84389a155c5832c68559a28a)
Signed-off-by: Jani Nikula -
If we're enabling a pipe, we'll need to modify the watermarks on all
active planes. Since those planes won't be added to the state on
their own, we need to add them ourselves.Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-6-git-send-email-cpaul@redhat.com
(cherry picked from commit 05a76d3d6ad1ee9f9814f88949cc9305fc165460)
Signed-off-by: Jani Nikula -
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0. Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes. Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).Changes since v1:
- Add a function for copying a pipe's wm values
(skl_copy_wm_for_pipe()) so we can reuse this laterFixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check' (v2)")
Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: Matt Roper
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-4-git-send-email-cpaul@redhat.com
(cherry picked from commit 2722efb90b3420dee54b4cb3cdc7917efacc2dce)
Signed-off-by: Jani Nikula -
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full system hangs. An easy way to reproduce this with
a skylake system:- Get a laptop with a skylake GPU, and hook up two external monitors to
it
- Move the cursor from the built-in LCD to one of the external displays
as quickly as you can
- You'll get a few pipe underruns, and eventually the entire system will
just freeze.After doing a lot of investigation and reading through the bspec, I
found the existence of the SAGV, which is responsible for adjusting the
system agent voltage and clock frequencies depending on how much power
we need. According to the bspec:"The display engine access to system memory is blocked during the
adjustment time. SAGV defaults to enabled. Software must use the
GT-driver pcode mailbox to disable SAGV when the display engine is not
able to tolerate the blocking time."The rest of the bspec goes on to explain that software can simply leave
the SAGV enabled, and disable it when we use interlaced pipes/have more
then one pipe active.Sure enough, with this patchset the system hangs resulting from pipe
underruns on Skylake have completely vanished on my T460s. Additionally,
the bspec mentions turning off the SAGV with more then one pipe enabled
as a workaround for display underruns. While this patch doesn't entirely
fix that, it looks like it does improve the situation a little bit so
it's likely this is going to be required to make watermarks on Skylake
fully functional.This will still need additional work in the future: we shouldn't be
enabling the SAGV if any of the currently enabled planes can't enable WM
levels that introduce latencies >= 30 µs.Changes since v11:
- Add skl_can_enable_sagv()
- Make sure we don't enable SAGV when not all planes can enable
watermarks >= the SAGV engine block time. I was originally going to
save this for later, but I recently managed to run into a machine
that was having problems with a single pipe configuration + SAGV.
- Make comparisons to I915_SKL_SAGV_NOT_CONTROLLED explicit
- Change I915_SAGV_DYNAMIC_FREQ to I915_SAGV_ENABLE
- Move printks outside of mutexes
- Don't print error messages twice
Changes since v10:
- Apparently sandybridge_pcode_read actually writes values and reads
them back, despite it's misleading function name. This means we've
been doing this mostly wrong and have been writing garbage to the
SAGV control. Because of this, we no longer attempt to read the SAGV
status during initialization (since there are no helpers for this).
- mlankhorst noticed that this patch was breaking on some very early
pre-release Skylake machines, which apparently don't allow you to
disable the SAGV. To prevent machines from failing tests due to SAGV
errors, if the first time we try to control the SAGV results in the
mailbox indicating an invalid command, we just disable future attempts
to control the SAGV state by setting dev_priv->skl_sagv_status to
I915_SKL_SAGV_NOT_CONTROLLED and make a note of it in dmesg.
- Move mutex_unlock() a little higher in skl_enable_sagv(). This
doesn't actually fix anything, but lets us release the lock a little
sooner since we're finished with it.
Changes since v9:
- Only enable/disable sagv on Skylake
Changes since v8:
- Add intel_state->modeset guard to the conditional for
skl_enable_sagv()
Changes since v7:
- Remove GEN9_SAGV_LOW_FREQ, replace with GEN9_SAGV_IS_ENABLED (that's
all we use it for anyway)
- Use GEN9_SAGV_IS_ENABLED instead of 0x1 for clarification
- Fix a styling error that snuck past me
Changes since v6:
- Protect skl_enable_sagv() with intel_state->modeset conditional in
intel_atomic_commit_tail()
Changes since v5:
- Don't use is_power_of_2. Makes things confusing
- Don't use the old state to figure out whether or not to
enable/disable the sagv, use the new one
- Split the loop in skl_disable_sagv into it's own function
- Move skl_sagv_enable/disable() calls into intel_atomic_commit_tail()
Changes since v4:
- Use is_power_of_2 against active_crtcs to check whether we have > 1
pipe enabled
- Fix skl_sagv_get_hw_state(): (temp & 0x1) indicates disabled, 0x0
enabled
- Call skl_sagv_enable/disable() from pre/post-plane updates
Changes since v3:
- Use time_before() to compare timeout to jiffies
Changes since v2:
- Really apply minor style nitpicks to patch this time
Changes since v1:
- Added comments about this probably being one of the requirements to
fixing Skylake's watermark issues
- Minor style nitpicks from Matt Roper
- Disable these functions on Broxton, since it doesn't have an SAGVSigned-off-by: Lyude
Cc: Matt Roper
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: stable@vger.kernel.org
Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-3-git-send-email-cpaul@redhat.com
[mlankhorst: ENOSYS -> ENXIO, whitespace fixes](cherry picked from commit 656d1b89e5ffb83036ab0e2a24be7558f34365c7)
Signed-off-by: Jani Nikula -
In order to add proper support for the SAGV, we need to be able to know
what the cause of a failure to change the SAGV through the pcode mailbox
was. The reasoning for this is that some very early pre-release Skylake
machines don't actually allow you to control the SAGV on them, and
indicate an invalid mailbox command was sent.This also might come in handy in the future for debugging.
Changes since v1:
- Add functions for interpreting gen6 mailbox error codes along with
gen7+ error codes, and actually interpret those codes properly
- Renamed patch to reflect new behaviorSigned-off-by: Lyude
Cc: Matt Roper
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: stable@vger.kernel.org
Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/1471463761-26796-2-git-send-email-cpaul@redhat.com
[mlankhorst: -ENOSYS -> -ENXIO for checkpatch](cherry picked from commit 87660502f1a4d51fb043e89a45d30c9917787c22)
Signed-off-by: Jani Nikula -
In the recent patch
bc3d674 drm/i915: Allow userspace to request no-error-capture upon ...
the final version moved the flags and the associated #defines around
so they were adjacent; unfortunately, they ended up between a comment
and the thing (hw_id) to which the comment applies :(So this patch reshuffles the comment and subject back together.
Also, as we're touching 'hw_id', let's change it from just 'unsigned'
to a fully-specified 'unsigned int', because some code checking tools
(including checkpatch) object to plain 'unsigned'.Fixes: bc3d674462e5 ("drm/i915: Allow userspace to request no-error-capture...")
Signed-off-by: Dave Gordon
Cc: Chris Wilson
Link: http://patchwork.freedesktop.org/patch/msgid/1471616622-6919-1-git-send-email-david.s.gordon@intel.com
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
(cherry picked from commit 0be81156b3fb4d4e8e2c94177e5222dc21c3ff10)
Signed-off-by: Jani Nikula -
If userspace is asynchronously streaming into the batch or other
execobjects, we may not flush those writes along with a change in cache
domain (as there is no change). Therefore those writes may end up in
internal chipset buffers and not visible to the GPU upon execution. We
must issue a flush command or otherwise we encounter incoherency in the
batchbuffers and the GPU executing invalid commands (i.e. hanging) quite
regularly.v2: Throw a paranoid wmb() into the general flush so that we remain
consistent with before.Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90841
Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user...")
Signed-off-by: Chris Wilson
Cc: Akash Goel
Cc: Daniel Vetter
Cc: Tvrtko Ursulin
Tested-by: Matti Hämäläinen
Cc: stable@vger.kernel.org
Reviewed-by: Mika Kuoppala
Link: http://patchwork.freedesktop.org/patch/msgid/20160818161718.27187-1-chris@chris-wilson.co.uk
(cherry picked from commit 600f436801deae65e48404847b61c89b4944e355)
Signed-off-by: Jani Nikula -
It's possible to have a non-zero plane mask and still wind up with a
total data rate of zero. There are two cases where this can happen:* planes are active (from the KMS point of view), but are
all fully clipped (positioned offscreen)
* the only active plane on a CRTC is the cursor (which is handled
independently and not counted into the general data rate computationsThese are both valid display setups (although unusual), so we need to
drop the WARN().Signed-off-by: Matt Roper
Reviewed-by: Maarten Lankhorst
Testcase: kms_universal_planes.cursor-only-pipe-*
Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/1466196140-16336-4-git-send-email-matthew.d.roper@intel.com
Cc: stable@vger.kernel.org #v4.7+
(cherry picked from commit 43aa7e87507f519b0b2497b6fac1e894554eaef2)
Signed-off-by: Jani Nikula -
intel_state->active_crtcs is usually only initialized when doing a
modeset. During our first atomic commit after boot, we're effectively
faking a modeset to sanitize the DDB/wm setup, so ensure that this field
gets initialized before use.v2:
- Don't clobber active_crtcs if our first commit really is a modeset
(Maarten)
- Grab connection_mutex when faking a modeset during sanitization
(Maarten)Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Cc: Maarten Lankhorst
Signed-off-by: Matt Roper
Tested-by: Tvrtko Ursulin
Signed-off-by: Maarten Lankhorst
Link: http://patchwork.freedesktop.org/patch/msgid/1466196140-16336-2-git-send-email-matthew.d.roper@intel.com
Cc: stable@vger.kernel.org #v4.7+
(cherry picked from commit 1b54a880b250acc226b13cea221b90aa1b3e37dd)
Signed-off-by: Jani Nikula -
Somehow this one slipped through, which means drivers without modeset
support can be oopsed (since those also don't call
drm_mode_config_init, which means the crtc lookup will chase an
uninitalized idr).Reported-by: Alexander Potapenko
Cc: Alexander Potapenko
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
Signed-off-by: Dave Airlie
20 Aug, 2016
4 commits
-
Could be that we don't actually have a timeout set.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Reviewed-by: Chunming Zhou
Signed-off-by: Alex Deucher -
Typo in checking the return code.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Chunming Zhou
Signed-off-by: Alex Deucher -
This bug seems to be present for a very long time.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
This bug seems to be present for a very long time.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
19 Aug, 2016
4 commits
-
Pull more drm fixes from Dave Airlie:
"Daniel pointed out I'd missed some i915 fixes, and I also found a
single etnaviv fix I missed.So here they are"
* tag 'drm-fixes-for-4.8-rc3-2' of git://people.freedesktop.org/~airlied/linux:
drm/etnaviv: take GPU lock later in the submit process
drm/i915: Fix modeset handling during gpu reset, v5.
drm/i915: fix aliasing_ppgtt leak
drm/i915: fix WaInsertDummyPushConstPs
drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2
drm/i915/gen9: Give one extra block per line for SKL plane WM calculations
drm/i915: Acquire audio powerwell for HD-Audio registers
drm/i915: Add missing rpm wakelock to GGTT pread
drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake
drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0
drm/i915: Program iboost settings for HDMI/DVI on SKL
drm/i915: Fix iboost setting for DDI with 4 lanes on SKL
drm/i915: Handle ENOSPC after failing to insert a mappable node
drm/i915: Flush GT idle status upon reset -
Collection of i915 fixes.
* tag 'drm-intel-fixes-2016-08-15' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix modeset handling during gpu reset, v5.
drm/i915: fix aliasing_ppgtt leak
drm/i915: fix WaInsertDummyPushConstPs
drm/i915: Fix iboost setting for SKL Y/U DP DDI buffer translation entry 2
drm/i915/gen9: Give one extra block per line for SKL plane WM calculations
drm/i915: Acquire audio powerwell for HD-Audio registers
drm/i915: Add missing rpm wakelock to GGTT pread
drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake
drm/i915: Clean up the extra RPM ref on CHV with i915.enable_rc6=0
drm/i915: Program iboost settings for HDMI/DVI on SKL
drm/i915: Fix iboost setting for DDI with 4 lanes on SKL
drm/i915: Handle ENOSPC after failing to insert a mappable node
drm/i915: Flush GT idle status upon reset -
Single GPU recovery fix
* 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux:
drm/etnaviv: take GPU lock later in the submit process -
Pull locking fixes from Ingo Molnar:
"Two lockless_dereference() related fixes"* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/barriers: Suppress sparse warnings in lockless_dereference()
Revert "drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference"
18 Aug, 2016
2 commits
-
Looks like some RV6xx have problems with that.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=97099Reviewed-by: Alex Deucher
Signed-off-by: Christian König
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org -
This reverts commit:
fa7d81bb3c269 ("drm/fb-helper: Reduce READ_ONCE(master) to lockless_dereference")
As Peter explained:
[...] lockless_dereference() is _stronger_ than READ_ONCE(), not weaker.
[...]
Also, clue is in the name: 'dereference', you don't actually dereference
the pointer here, only load it.My next patch breaks the compile without this revert, because it assumes
you want to deference and thus also need the struct type visible (which
it isn't here), so revert it.Tested-by: Paul E. McKenney
Signed-off-by: Johannes Berg
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Daniel Vetter
Cc: Andrew Morton
Cc: Chris Wilson
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1470909022-687-1-git-send-email-johannes@sipsolutions.net
Signed-off-by: Ingo Molnar
16 Aug, 2016
1 commit
-
The GART aperture size can be bigger than 4GB. Therefore the offset
used in amdgpu_gart_bind and amdgpu_gart_unbind must be 64-bit.Reviewed-by: Christian König
Signed-off-by: Felix Kuehling
Reviewed-by: Alex Deucher
Signed-off-by: Alex Deucher
Cc: stable@vger.kernel.org
15 Aug, 2016
2 commits
-
Both the fence and event alloc are safe to be done without holding the GPU
lock, as they either don't need any locking (fences) or are protected by
their own lock (events).This solves a bad locking interaction between the submit path and the
recover worker. If userspace manages to exhaust all available events while
the GPU is hung, the submit will wait for events to become available
holding the GPU lock. The recover worker waits for this lock to become
available before trying to recover the GPU which frees up the allocated
events. Essentially both paths are deadlocked until the submit path
times out waiting for available events, failing the submit that could
otherwise be handled just fine if the recover worker had the chance to
bring the GPU back in a working state.Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner -
mediatek-drm build dependency fixes
- add COMMON_CLK dependency for mipi-tx PLL
- add OF dependency for mtk_drm_drv
- add ARM_SMCCC dependency for mtk-hdmi* tag 'mediatek-drm-fixes-2016-08-12' of git://git.pengutronix.de/git/pza/linux:
drm/mediatek: add ARM_SMCCC dependency
drm/mediatek: add CONFIG_OF dependency
drm/mediatek: add COMMON_CLK dependency
12 Aug, 2016
1 commit
-
Some AMD fixes and remove workaround now we have pcieport pm.
* 'drm-fixes-4.8' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: Fix memory trashing if UVD ring test fails
drm/amdgpu: fix vm init error path
Revert "drm/radeon: work around lack of upstream ACPI support for D3cold"
Revert "drm/amdgpu: work around lack of upstream ACPI support for D3cold"
11 Aug, 2016
7 commits
-
ARM SMCCC is only set for ARMv7 and ARMv8 CPUs, but we currently
allow the driver to be build for older architecture levels as
well, which results in a link failure:drivers/gpu/built-in.o: In function `mtk_hdmi_hw_make_reg_writable':
:(.text+0x1e737c): undefined reference to `arm_smccc_smc'This adds a Kconfig dependency. The patch applies on my two
previous fixes that are not yet applied, so please apply all
three to get randconfig builds to work correctly.Signed-off-by: Arnd Bergmann
Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
Reviewed-by: Matthias Brugger
Signed-off-by: Philipp Zabel -
The mediatek DRM driver can be configured for compile testing with
CONFIG_OF disabled, but then fails to link:drivers/gpu/built-in.o: In function `mtk_drm_bind':
analogix_dp_reg.c:(.text+0x52888): undefined reference to `of_find_device_by_node'
analogix_dp_reg.c:(.text+0x52930): undefined reference to `of_find_device_by_node'This adds an explicit Kconfig dependency.
Signed-off-by: Arnd Bergmann
Link: https://patchwork.kernel.org/patch/9120871/
Signed-off-by: Philipp Zabel -
On kernel builds without COMMON_CLK, the newly added mediatek drm
driver fails to build:drivers/gpu/drm/mediatek/mtk_mipi_tx.c:130:16: error: field 'pll_hw' has incomplete type
struct clk_hw pll_hw;
^~~~~~
In file included from ../include/linux/clk.h:16:0,
from ../drivers/gpu/drm/mediatek/mtk_mipi_tx.c:14:
drivers/gpu/drm/mediatek/mtk_mipi_tx.c: In function 'mtk_mipi_tx_from_clk_hw':
include/linux/kernel.h:831:48: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
^
/drivers/gpu/drm/mediatek/mtk_mipi_tx.c:136:9: note: in expansion of macro 'container_of'
return container_of(hw, struct mtk_mipi_tx, pll_hw);
^~~~~~~~~~~~
drivers/gpu/drm/mediatek/mtk_mipi_tx.c: At top level:
drivers/gpu/drm/mediatek/mtk_mipi_tx.c:302:21: error: variable 'mtk_mipi_tx_pll_ops' has initializer but incomplete type
static const struct clk_ops mtk_mipi_tx_pll_ops = {This adds the required Kconfig dependency.
Signed-off-by: Arnd Bergmann
Acked-by: Philipp Zabel
Link: https://patchwork.kernel.org/patch/9069061/
Signed-off-by: Philipp Zabel -
This function would call drm_modeset_lock_all, while the suspend/resume
functions already have their own locking. Fix this by factoring out
__intel_display_resume, and calling the atomic helpers for duplicating
atomic state and disabling all crtc's during suspend.Changes since v1:
- Deal with -EDEADLK right after lock_all and clean up calls
to hw readout.
- Always take all modeset locks so updates during gpu reset are blocked.
Changes since v2:
- Fix deadlock in intel_update_primary_planes.
- Move WARN_ON(EDEADLK) to __intel_display_resume.
- pctx -> ctx
- only call __intel_display_resume on success in intel_display_resume.
Changes since v3:
- Rebase on top of dev_priv -> dev change.
- Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
Changes since v4 [by vsyrjala]:
- Deal with skip_intermediate_wm
- Update comment w.r.t. mode_config.mutex vs. ->detect()
- Rebase due to INTEL_GEN() etc.Signed-off-by: Maarten Lankhorst
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: stable@vger.kernel.org
Tested-by: Ville Syrjälä
Signed-off-by: Ville Syrjälä
Link: http://patchwork.freedesktop.org/patch/msgid/1470428910-12125-2-git-send-email-ville.syrjala@linux.intel.com
(cherry picked from commit 739748939974791b84629a8790527a16f76873a4)
Signed-off-by: Jani Nikula -
In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This
fixes the following kmemleak message:unreferenced object 0xffff880213cca000 (size 8192):
comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] kmemleak_alloc+0x4e/0xb0
[] kmem_cache_alloc_trace+0x142/0x1d0
[] i915_gem_init_ggtt+0x10f/0x210 [i915]
[] i915_gem_init+0x5b/0xd0 [i915]
[] i915_driver_load+0x97a/0x1460 [i915]
[] i915_pci_probe+0x4f/0x70 [i915]
[] local_pci_probe+0x45/0xa0
[] pci_device_probe+0x103/0x150
[] driver_probe_device+0x22c/0x440
[] __driver_attach+0xd1/0xf0
[] bus_for_each_dev+0x6c/0xc0
[] driver_attach+0x1e/0x20
[] bus_add_driver+0x1c3/0x280
[] driver_register+0x60/0xe0
[] __pci_register_driver+0x4c/0x50
[] 0xffffffffa013605bSigned-off-by: Matthew Auld
Reviewed-by: Chris Wilson
Fixes: b18b6bde300e ("drm/i915/bdw: Free PPGTT struct")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter
Link: http://patchwork.freedesktop.org/patch/msgid/1470420280-21417-1-git-send-email-matthew.auld@intel.com
(cherry picked from commit cb7f27601c81a1e0454e9461e96f65b31fafbea0)
Signed-off-by: Jani Nikula -
As pointed out by Chris Harris, we are using the wrong WA name, it
should in fact be WaToEnableHwFixForPushConstHWBug, also it should be
applied from C0 onwards for both BXT and KBL.Fixes: 7b9005cd45f3 ("drm/i915: Add WaInsertDummyPushConstP for bxt and kbl")
Cc: Chris Harris
Cc: Mika Kuoppala
Reported-by: Chris Harris
Signed-off-by: Matthew Auld
Reviewed-by: Arun Siluvery
Signed-off-by: Joonas Lahtinen
Link: http://patchwork.freedesktop.org/patch/msgid/1470127013-29653-1-git-send-email-matthew.auld@intel.com
(cherry picked from commit 575e3ccbce4582395d57612b289178bad4af3be8)
Signed-off-by: Jani Nikula -
The spec was recently fixed to have the correct iboost setting for the
SKL Y/U DP DDI buffer translation table entry 2. Update our tables
to match.Cc: David Weinehall
Signed-off-by: Ville Syrjälä
Link: http://patchwork.freedesktop.org/patch/msgid/1470140517-13011-1-git-send-email-ville.syrjala@linux.intel.com
Cc: stable@vger.kernel.org
Reviewed-by: David Weinehall
(cherry picked from commit 5ac9056753e79ac5ad1ccc3c99b311688e46e8c9)
Signed-off-by: Jani Nikula
