Age | Commit message (Collapse) | Author |
|
commit c29c0876ec05d51a93508a39b90b92c29ba6423d upstream.
Otherwise the change isn't atomic.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 48afbd70ac7b6aa62e8d452091023941d8085f8a upstream.
Otherwise it is possible that we will have page table corruption
if we change a BOs address multiple times.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 26d4d129b6042197b4cbc8341c0618f99231af2f upstream.
If we unmap BOs before releasing them them the intervall tree locks
up because we try to remove an entry not inside the tree.
Based on a patch from Michel Dänzer.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit cd17e02ff4db58ec32d35cf331c705d295779930 upstream.
Seems to have problems with high mclks.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7fe04d6fa824ccea704535a597dc417c8687f990 upstream.
Fixes display problems with some monitors when audio
is not enabled.
Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=89505
https://bugzilla.kernel.org/show_bug.cgi?id=94171
Plus several reports on IRC.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b421ed15d2c3039eb724680e4de1e4b2bd196a9a upstream.
The number of relocs is passed in by userspace and can be large. It has
been observed to cause kcalloc failures in the wild.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 38aef1549b18539eaecd804383a6ccb6588a9ce1 upstream.
Selectively enable which packets we send based on monitor caps.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0f55db36d49d45b80eff0c0a2a498766016f458b upstream.
Otherwise the driver may try and send audio which may confuse the
monitor.
v2: set pin to NULL if no audio
v3: avoid crash with analog encoders
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 362ff251390f3d1f8fe94666f4fc4e5876381114 upstream.
Don't enable the audio and avi infoframes and audio stream
until all the state is set up.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 12428327bbd1180b5d8ef83fdf9482b878d0502a upstream.
It's mostly duplicated with evergreen_dp_enable. This
is a prerequisite for fix implemented in another patch.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 304f07e9c8d302cf3183248cbabb40598eb5b732 upstream.
Set the line first, then enable the stream. May fix
pink line problems on some displays.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream.
The hardware, according to the specs, is limited to 256 byte transfers,
and current driver has no protections in case users attempt to do larger
transfers. The code will just stomp over status register and mayhem
ensues.
Let's split larger transfers into digestable chunks. Doing this allows
Atmel MXT driver on Pixel 1 function properly (it hasn't since commit
9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts -
implement T44 message handling" which tries to consume multiple
touchscreen/touchpad reports in a single transaction).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b5f1c97f944482e98e6e39208af356630389d1ea upstream.
Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across
suspend/resume, so fix this.
This was introduced in
commit ddeea5b0c36f3665446518c609be91f9336ef674
Author: Imre Deak <imre.deak@intel.com>
Date: Mon May 5 15:19:56 2014 +0300
drm/i915: vlv: add runtime PM support
I noticed this only by reading the code. To my knowledge it shouldn't
cause any real problems at the moment, since the power well backing this
register remains on across a runtime s/r. This may change once
system-wide s0ix functionality is enabled in the kernel.
v2:
- resend after a missing git add -u :/
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a5241289c4139f0521b89e34a70f5f998463ae15 upstream.
The EDID read code waits for the read completion interrupt to occur
using wait_event_interruptible(). The condition passed to the macro
reads I2C registers. This results in sleeping with the task state set
to TASK_INTERRUPTIBLE, triggering a WARN_ON() introduced in commit
8eb23b9f35aae ("sched: Debug nested sleeps").
Fix this by reworking the EDID read code. Instead of checking whether
the read is complete through I2C reads, handle the interrupt registers
in the interrupt handler and update a new edid_read flag accordingly. As
a side effect both the IRQ and polling code paths now process the
interrupt sources through the same code path, simplifying the code.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2e96206c4f952295e11c311fbb2a7aa2105024af upstream.
The DDC error interrupt bit is located in REG_INT1, not REG_INT0. Update
both the interrupt wait code and the interrupt sources reset code
accordingly.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 37ef01ab5d24d1d520dc79f6a98099d451c2a901 upstream.
We stopped handling them in
commit aaecdf611a05cac26a94713bad25297e60225c29
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Nov 4 15:52:22 2014 +0100
drm/i915: Stop gathering error states for CS error interrupts
but just clearing is apparently not enough: A sufficiently dead gpu
left behind by firmware (*cough* coreboot *cough*) can keep the gpu in
an endless loop of such interrupts, eventually leading to the nmi
firing. And definitely to what looks like a machine hang.
Since we don't even enable these interrupts on gen5+ let's do the same
on earlier platforms.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171
Tested-by: Mono <mono-for-kernel-org@donderklumpen.de>
Tested-by: info@gluglug.org.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 1c363c7cccf64128087002b0779986ad16aff6dc upstream.
After adding display power domain for Exynos5250 in commit
2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.
The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Display Port and is enabled by bootloader.
However when FIMD driver probing was deferred, the display power domain
was turned off. This effectively reset the value of DP clock enable
register.
When exynos-dp is later probed, the clock is not enabled and display is
not properly configured:
exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
exynos-dp 145b0000.dp-controller: unable to config video
Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream.
Use the correct flags for atom.
v2: handle DRM_MODE_FLAG_DBLCLK
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
three commits, all cc: stable, to address Baytrail
suspend/resume issues.
* tag 'drm-intel-fixes-2015-04-08' of git://anongit.freedesktop.org/drm-intel:
drm/i915/vlv: remove wait for previous GFX clk disable request
drm/i915/chv: Remove Wait for a previous gfx force-off
drm/i915/vlv: save/restore the power context base reg
|
|
Regression in commit 2caa80e72b57c6216aec6f6a11fcfb4fec46daa0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Feb 22 11:38:36 2015 +0100
drm: Fix deadlock due to getconnector locking changes
If the drm_connector_find() call returns NULL, we should no longer
call drm_modeset_unlock() to avoid locking imbalance.
Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Looks like it was introduced in:
commit 650ad970a39f8b6164fe8613edc150f585315289
Author: Imre Deak <imre.deak@intel.com>
Date: Fri Apr 18 16:35:02 2014 +0300
drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of
but I'm not sure why. It has caused problems for us in the past (see
85250ddff7a6 "drm/i915/chv: Remove Wait for a previous gfx force-off"
and 8d4eee9cd7a1 "drm/i915: vlv: increase timeout when forcing on the
GFX clock") and doesn't seem to be required, so let's just drop it.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Darren Hart <dvhart@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Cc: stable@vger.kernel.org # c9c52e24194a: drm/i915/chv: Remove Wait ...
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this
reg. If it's unlocked, we can just restore the previous value, and if
it's locked (in case the BIOS re-programmed it for us) the write will be
ignored and we'll still have "did it move" sanity check in the PM code to
warn us if something is still amiss.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89611
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
into drm-fixes
Just two small fixes for radeon, both destined for stable.
* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: fix wait in radeon_mn_invalidate_range_start
drm/radeon: add extra check in radeon_ttm_tt_unpin_userptr
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
Fix display on issue to Exynos5250 based Snow(1366x768) board.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm: Exynos: Respect framebuffer pitch for FIMD/Mixer
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
one oops fixes and a 0-length allocation fix from next backported.
* tag 'drm-intel-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Reject the colorkey ioctls for primary and cursor planes
drm/i915: Skip allocating shadow batch for 0-length batches
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
Here's a single drm core fix, cc: stable, that affects i915
users.
* tag 'topic/drm-fixes-2015-04-02' of git://anongit.freedesktop.org/drm-intel:
drm/edid: set ELD for firmware and debugfs override EDIDs
|
|
We need to wait for all fences, not just the exclusive one.
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
We somehow try to free the SG table twice.
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734
Signed-off-by: Christian König <christian.koenig@amd.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
When performing a modeset, use the framebuffer pitch value to set FIMD
IMG_SIZE and Mixer SPAN registers. These are both defined as pitch - the
distance between contiguous lines (bytes for FIMD, pixels for mixer).
Fixes display on Snow (1366x768).
Signed-off-by: Daniel Stone <daniels@collabora.com>
Tested-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The legcy colorkey ioctls are only implemented for sprite planes, so
reject the ioctl for primary/cursor planes. If we want to support
colorkeying with these planes (assuming we have hw support of course)
we should just move ahead with the colorkey property conversion.
Testcase: kms_legacy_colorkey
Cc: Tommi Rantala <tt.rantala@gmail.com>
Cc: stable@vger.kernel.org
Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.com
Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Since
commit 17cabf571e50677d980e9ab2a43c5f11213003ae
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jan 14 11:20:57 2015 +0000
drm/i915: Trim the command parser allocations
we may then try to allocate a zero-sized object and attempt to extract
its pages. Understandably this fails.
Note that the real offender seems to be
commit b9ffd80ed659c559152c042e74741f4f60cac691
Author: Brad Volkin <bradley.d.volkin@intel.com>
Date: Thu Dec 11 12:13:10 2014 -0800
drm/i915: Use batch length instead of object size in command parser
Testcase: igt/gem_exec_nop #ivb,byt,hsw
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[cherry picked from commit 743e78c1d726d875b98ff9689cc77c4d3d5d9ae2
from drm-intel-next because 4.0 seems to be affected by this too,
despite that the obvious culprit is definitely not in 4.0. Whatever,
if fixes a bug.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
Otherwise the VCE firmware needs to be in the first 256MB of VRAM.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Dumping is still possible if a ring isn't ready, only when it
isn't allocated at all we need to abort here.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Use readb() and memcpy_fromio() accessors instead.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Need to expand the check to handle short circuiting
if the selected state is the same as current state.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=87796
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
If the user supplies EDID through firmware or debugfs override, the
driver callbacks are bypassed and the connector ELD does not get
updated, and audio fails. Set ELD for firmware and debugfs EDIDs too.
There should be no harm in gratuitously doing this for non HDMI/DP
connectors, as it's still up to the driver to use the ELD, if any.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691
Reported-by: Emil <emilsvennesson@gmail.com>
Reported-by: Rob Engle <grenoble@gmail.com>
Tested-by: Jolan Luff <jolan@gormsby.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
This is a very similar bug in the load detect code fixed in
commit 9128b040eb774e04bc23777b005ace2b66ab2a85
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Mar 3 17:31:21 2015 +0100
drm/i915: Fix modeset state confusion in the load detect code
But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Right now, we get a warning when taking over the firmware fb:
[drm:drm_atomic_plane_check] FB set but no CRTC
with the following backtrace:
[<ffffffffa010339d>] drm_atomic_check_only+0x35d/0x510 [drm]
[<ffffffffa0103567>] drm_atomic_commit+0x17/0x60 [drm]
[<ffffffffa00a6ccd>] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
[<ffffffffa00f1fed>] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
[<ffffffffa00a8a1b>] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
[<ffffffffa00aa969>] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
[<ffffffffa00aa9e2>] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
[<ffffffffa050a71a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff813ad444>] fbcon_init+0x4f4/0x580
That's because we update the plane state with the fb from the firmware, but we
never associate the plane to that CRTC.
We don't quite have the full DRM take over from HW state just yet, so
fake enough of the plane atomic state to pass the checks.
v2: Fix the state on which we set the CRTC in the case we're sharing the
initial fb with another pipe. (Matt)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com
Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
If we retire requests last, we may use a later seqno and so clear
the requests lists without clearing the active list, leading to
confusion. Hence we should retire requests first for consistency with
the early return. The order used to be important as the lifecycle for
the object on the active list was determined by request->seqno. However,
the requests themselves are now reference counted removing the
constraint from the order of retirement.
Fixes regression from
commit 1b5a433a4dd967b125131da42b89b5cc0d5b1f57
Author: John Harrison <John.C.Harrison@Intel.com>
Date: Mon Nov 24 18:49:42 2014 +0000
drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed
'
and a
WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140()
WARN_ON(!list_empty(&vm->active_list))
Identified by updating WATCH_LISTS:
[drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests
WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230()
WARN_ON(i915_verify_lists(ring->dev))
Note that this is only a problem in evict_vm where the following happens
after a retire_request has cleaned out all requests, but not all active
bo:
- intel_ring_idle called from i915_gpu_idle notices that no requests are
outstanding and immediately returns.
- i915_gem_retire_requests_ring called from i915_gem_retire_requests also
immediately returns when there's no request, still leaving the bo on the
active list.
- evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting
all active objects that there's still stuff left that shouldn't be
there.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Tvrtko noticed a new warning on boot:
WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]()
Call Trace:
[<ffffffff8161f10c>] dump_stack+0x4f/0x7b
[<ffffffff81052caa>] warn_slowpath_common+0xaa/0xd0
[<ffffffff81052d8a>] warn_slowpath_null+0x1a/0x20
[<ffffffffa00d035c>] drm_framebuffer_reference+0x6c/0x80 [drm]
[<ffffffffa01c0df7>] update_state_fb.isra.54+0x47/0x50 [i915]
[<ffffffffa01ccd5c>] skylake_get_initial_plane_config+0x93c/0x950 [i915]
[<ffffffffa01e8721>] intel_modeset_init+0x1551/0x17c0 [i915]
[<ffffffffa02476e0>] i915_driver_load+0xed0/0x11e0 [i915]
[<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70
[<ffffffffa00ca8b7>] drm_dev_register+0x77/0x110 [drm]
[<ffffffffa00cda3b>] drm_get_pci_dev+0x11b/0x1f0 [drm]
[<ffffffff81098e3d>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff81627aa1>] ? _raw_spin_unlock_irqrestore+0x51/0x70
[<ffffffffa0145276>] i915_pci_probe+0x56/0x60 [i915]
[<ffffffff813ad59c>] pci_device_probe+0x7c/0x100
[<ffffffff81466aad>] driver_probe_device+0x16d/0x380
We cannot take a reference at this point, not before
intel_framebuffer_init() and the underlying drm_framebuffer_init().
Introduced in:
commit 706dc7b549175e47f23e913b7f1e52874a7d0f56
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Feb 3 13:10:04 2015 -0800
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
v2: Don't move update_state_fb(). It was moved around because I
originally put update_state_fb() in intel_alloc_plane_obj() before
finding a better place. (Matt)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From drm-next:
(cherry picked from commit f55548b5af87ebfc586ca75748947f1c1b1a4a52)
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Originally it was impossible to be dropping the last refcount in this
function since there was always one around still from the idr. But in
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Aug 6 09:10:18 2014 +0200
drm: Don't grab an fb reference for the idr
we've switched to weak references, broke that assumption but forgot to
fix it up.
Since we still force-disable planes it's only possible to hit this
when racing multiple rmfb with fbdev restoring or similar evil things.
As long as userspace is nice it's impossible to hit the BUG_ON.
But the BUG_ON would most likely be hit from fbdev code, which usually
invovles the console_lock besides all modeset locks. So very likely
we'd never get the bug reports if this was hit in the wild, hence
better be safe than sorry and backport.
Spotted by Matt Roper while reviewing other patches.
[airlied: pull this back into 4.0 - the oops happens there]
Cc: stable@vger.kernel.org
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
git://anongit.freedesktop.org/drm-intel into drm-fixes
Backporting a couple of plane related fixes from drm-next to v4.0.
* tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Make sure the primary plane is enabled before reading out the fb state
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
|
|
git://people.freedesktop.org/~gabbayo/linux into drm-fixes
- Fixing SDMA initialization when in non-HWS mode (debug mode)
- Memory leak fix when destroying kernel queue
- Fix number of available compute pipelines according to new firmware
* tag 'drm-amdkfd-fixes-2015-03-19' of git://people.freedesktop.org/~gabbayo/linux:
drm/radeon: Changing number of compute pipe lines
drm/amdkfd: Fix SDMA queue init. in non-HWS mode
drm/amdkfd: destroy mqd when destroying kernel queue
|
|
into drm-fixes
single radeon fix.
* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: drop ttm two ended allocation
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
Some urgent regression fixes to booting failures Exynos DRM occured.
Summary:
- Fix two urgent null pointer dereference bugs in case of enabling
or disabling IOMMU. There was two cases to these issues.
One is that plane->crtc is accessed by exynos_disable_plane()
when device tree binding is broken so device driver tries
to release, which means that the mode set operation isn't invoked yet
so plane->crtc is still NULL and exynos_disable_plane() will access
NULL pointer. This issue is fixed by checking if the plane->crtc
is NULL or not in exynos_disable_plane()
Other is that fimd_wait_for_vblank() is called to avoid from page fault
with IOMMU before the ctx object is created. At this time,
fimd_wait_for_vblank() tries to access ctx->crtc but the ctx->crtc
is still NULL because exynos_drm_crtc_create() isn't called yet.
This issue is fixed by creating a crtc object and setting it to
ctx->crtc prior to fimd_wait_for_vblank() call.
For more details, you can refer to below an e-mail thread,
http://www.spinics.net/lists/linux-samsung-soc/msg42436.html
- Remove unnecessary file not used and fix trivial issues.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: fix the initialization order in FIMD
drm/exynos: fix typo config name correctly.
drm/exynos: Check for NULL dereference of crtc
drm/exynos: IS_ERR() vs NULL bug
drm/exynos: remove unused files
|
|
radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called. radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false. It only took effect when buffers
were validated later. It also seemed to regress suspend
and resume on some systems possibly due to it not
taking effect in radeon_bo_create().
radeon_bo_create() and radeon_ttm_placement_from_domain()
need to be reworked substantially for this to be optimally
effective. Re-enable it at that point.
Noticed-by: Oded Gabbay <oded.gabbay@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Since commit 0f04cf8df0b20a97369cb634663fef0578cbf273 ("drm/exynos:
fix wrong pipe calculation for crtc"), fimd_clear_channel() can be
called when is_drm_iommu_supported() returns true. In this case,
the kernel is going to be panicked because crtc is not set yet.
[ 1.211156] [drm] Initialized drm 1.1.0 20060810
[ 1.216785] Unable to handle kernel NULL pointer dereference at virtual address 00000350
[ 1.223415] pgd = c0004000
[ 1.226086] [00000350] *pgd=00000000
[ 1.229649] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 1.234940] Modules linked in:
[ 1.237982] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.0.0-rc1-00062-g7a7cc79-dirty #123
[ 1.246136] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1.252214] task: ee8c8000 ti: ee8d0000 task.ti: ee8d0000
[ 1.257606] PC is at fimd_wait_for_vblank+0x8/0xc8
[ 1.262370] LR is at fimd_bind+0x138/0x1a8
[ 1.266450] pc : [<c02fb63c>] lr : [<c02fb834>] psr: 20000113
[ 1.266450] sp : ee8d1d28 ip : 00000000 fp : 00000000
[ 1.277906] r10: 00000001 r9 : c09d693c r8 : c0a2d6a8
[ 1.283114] r7 : 00000034 r6 : 00000001 r5 : ee0bb400 r4 : ee244c10
[ 1.289624] r3 : 00000000 r2 : 00000000 r1 : 00000001 r0 : 00000000
[ 1.296135] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 1.303426] Control: 10c5387d Table: 4000404a DAC: 00000015
[ 1.309154] Process swapper/0 (pid: 1, stack limit = 0xee8d0210)
[ 1.315143] Stack: (0xee8d1d28 to 0xee8d2000)
[ 1.319486] 1d20: 00000000 c0113d18 ee0bb400 ee0bb400 ee245c30 eebbe210
[ 1.327645] 1d40: ee008a40 ee244c10 ee0bb400 00000001 00000034 c02fb834 00000000 c030a858
[ 1.335804] 1d60: ee244a10 eeb60780 ee008a40 eeb60740 ee0bb400 c03030d0 00000000 00000000
[ 1.343963] 1d80: ee244a10 ee0bb400 00000000 eeb60740 eeb60810 00000000 00000000 c02f6ba4
[ 1.352123] 1da0: ee0bb400 00000000 00000000 c02e0500 ee244a00 c0a04a14 ee0bb400 c02e1de4
[ 1.360282] 1dc0: 00000000 c030a858 00000002 eeb60820 eeb60820 00000002 eeb60780 c03033d4
[ 1.368441] 1de0: c06e9cec 00000000 ee244a10 eeb60780 c0a056f8 c03035fc c0a04b24 c0a04b24
[ 1.376600] 1e00: ee244a10 00000001 c0a049d0 c02f6d34 c0ad462c eeba0790 00000000 ee244a10
[ 1.384759] 1e20: ffffffed c0a049d0 00000000 c03090b0 ee244a10 c0ad462c c0a2d840 c03077a0
[ 1.392919] 1e40: eeb5e880 c024b738 000008db ee244a10 c0a049d0 ee244a44 00000000 c09e71d8
[ 1.401078] 1e60: 000000c6 c0307a6c c0a049d0 00000000 c03079e0 c0305ea8 ee826e5c ee1dc7b4
[ 1.409237] 1e80: c0a049d0 eeb5e880 c0a058a8 c0306e2c c0896204 c0a049d0 c06e9d10 c0a049d0
[ 1.417396] 1ea0: c06e9d10 c0ad4600 00000000 c0308360 00000000 00000003 c06e9d10 c02f6e14
[ 1.425555] 1ec0: 00000000 c0896204 ffffffff 00000000 00000000 00000000 00000000 00000000
[ 1.433714] 1ee0: 00000000 00000000 c02f6d5c c02f6d5c 00000000 eeb5d740 c09e71d8 c0008a30
[ 1.441874] 1f00: ef7fca5e 00000000 00000000 00000066 00000000 ee8d1f28 c003ff1c c02514e8
[ 1.450033] 1f20: 60000113 ffffffff c093906c ef7fca5e 000000c6 c004018c 00000000 c093906c
[ 1.458192] 1f40: c08a9690 c093840c 00000006 00000006 c09eb2ac c09c0d74 00000006 c09c0d54
[ 1.466351] 1f60: c0a3d680 c09745a0 c09d693c 000000c6 00000000 c0974db4 00000006 00000006
[ 1.474510] 1f80: c09745a0 ffffffff 00000000 c0692e00 00000000 00000000 00000000 00000000
[ 1.482669] 1fa0: 00000000 c0692e08 00000000 c000f040 00000000 00000000 00000000 00000000
[ 1.490828] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.498988] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[ 1.507159] [<c02fb63c>] (fimd_wait_for_vblank) from [<c02fb834>] (fimd_bind+0x138/0x1a8)
[ 1.515313] [<c02fb834>] (fimd_bind) from [<c03030d0>] (component_bind_all+0xc4/0x20c)
[ 1.523209] [<c03030d0>] (component_bind_all) from [<c02f6ba4>] (exynos_drm_load+0xa0/0x140)
[ 1.531632] [<c02f6ba4>] (exynos_drm_load) from [<c02e0500>] (drm_dev_register+0xa0/0xf4)
[ 1.539788] [<c02e0500>] (drm_dev_register) from [<c02e1de4>] (drm_platform_init+0x44/0xcc)
[ 1.548121] [<c02e1de4>] (drm_platform_init) from [<c03033d4>] (try_to_bring_up_master.part.1+0xc8/0x104)
[ 1.557668] [<c03033d4>] (try_to_bring_up_master.part.1) from [<c03035fc>] (component_master_add_with_match+0xd0/0x118)
[ 1.568431] [<c03035fc>] (component_master_add_with_match) from [<c02f6d34>] (exynos_drm_platform_probe+0xf0/0x118)
[ 1.578847] [<c02f6d34>] (exynos_drm_platform_probe) from [<c03090b0>] (platform_drv_probe+0x48/0x98)
[ 1.588052] [<c03090b0>] (platform_drv_probe) from [<c03077a0>] (driver_probe_device+0x140/0x380)
[ 1.596902] [<c03077a0>] (driver_probe_device) from [<c0307a6c>] (__driver_attach+0x8c/0x90)
[ 1.605321] [<c0307a6c>] (__driver_attach) from [<c0305ea8>] (bus_for_each_dev+0x54/0x88)
[ 1.613480] [<c0305ea8>] (bus_for_each_dev) from [<c0306e2c>] (bus_add_driver+0xec/0x200)
[ 1.621640] [<c0306e2c>] (bus_add_driver) from [<c0308360>] (driver_register+0x78/0xf4)
[ 1.629625] [<c0308360>] (driver_register) from [<c02f6e14>] (exynos_drm_init+0xb8/0x11c)
[ 1.637785] [<c02f6e14>] (exynos_drm_init) from [<c0008a30>] (do_one_initcall+0xac/0x1ec)
[ 1.645950] [<c0008a30>] (do_one_initcall) from [<c0974db4>] (kernel_init_freeable+0x194/0x268)
[ 1.654626] [<c0974db4>] (kernel_init_freeable) from [<c0692e08>] (kernel_init+0x8/0xe4)
[ 1.662699] [<c0692e08>] (kernel_init) from [<c000f040>] (ret_from_fork+0x14/0x34)
[ 1.670246] Code: eaffffd5 c09df884 e92d40f0 e24dd01c (e5905350)
[ 1.676408] ---[ end trace 804468492f306a6f ]---
[ 1.680948] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.680948]
[ 1.690035] CPU1: stopping
[ 1.692727] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123
[ 1.702097] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1.708192] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14)
[ 1.715908] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8)
[ 1.723108] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4)
[ 1.730485] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c)
[ 1.738036] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74)
[ 1.745498] Exception stack(0xee8fdf98 to 0xee8fdfe0)
[ 1.750533] df80: 00000000 00000000
[ 1.758695] dfa0: ee8fdfe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4
[ 1.766853] dfc0: c0a27a74 c09df940 01000000 ee8fdfe0 c00101c0 c00101c4 60000113 ffffffff
[ 1.775015] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c)
[ 1.782397] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324)
[ 1.790639] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764)
[ 1.797579] CPU0: stopping
[ 1.800272] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123
[ 1.809642] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1.815730] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14)
[ 1.823450] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8)
[ 1.830653] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4)
[ 1.838030] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c)
[ 1.845581] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74)
[ 1.853043] Exception stack(0xc09ddf60 to 0xc09ddfa8)
[ 1.858081] df60: 00000000 00000000 c09ddfb0 c0021780 c09df938 00000001 ffffffff c0a3d680
[ 1.866239] df80: c09c0dec c09df8d4 c0a27a74 c09df940 01000000 c09ddfa8 c00101c0 c00101c4
[ 1.874396] dfa0: 60000113 ffffffff
[ 1.877872] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c)
[ 1.885251] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324)
[ 1.893499] [<c005e804>] (cpu_startup_entry) from [<c0974bc8>] (start_kernel+0x324/0x37c)
[ 1.901655] [<c0974bc8>] (start_kernel) from [<40008074>] (0x40008074)
[ 1.908161] CPU3: stopping
[ 1.910855] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G D 4.0.0-rc1-00062-g7a7cc79-dirty #123
[ 1.920225] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 1.926313] [<c0016c84>] (unwind_backtrace) from [<c00129bc>] (show_stack+0x10/0x14)
[ 1.934034] [<c00129bc>] (show_stack) from [<c0696f58>] (dump_stack+0x78/0xc8)
[ 1.941237] [<c0696f58>] (dump_stack) from [<c0015020>] (handle_IPI+0x16c/0x2b4)
[ 1.948613] [<c0015020>] (handle_IPI) from [<c00086bc>] (gic_handle_irq+0x64/0x6c)
[ 1.956165] [<c00086bc>] (gic_handle_irq) from [<c00134c0>] (__irq_svc+0x40/0x74)
[ 1.963626] Exception stack(0xee901f98 to 0xee901fe0)
[ 1.968661] 1f80: 00000000 00000000
[ 1.976823] 1fa0: ee901fe8 c0021780 c09df938 00000015 10c0387d c0a3d988 4000406a c09df8d4
[ 1.984982] 1fc0: c0a27a74 c09df940 01000000 ee901fe0 c00101c0 c00101c4 60000113 ffffffff
[ 1.993143] [<c00134c0>] (__irq_svc) from [<c00101c4>] (arch_cpu_idle+0x30/0x3c)
[ 2.000522] [<c00101c4>] (arch_cpu_idle) from [<c005e804>] (cpu_startup_entry+0x180/0x324)
[ 2.008765] [<c005e804>] (cpu_startup_entry) from [<40008764>] (0x40008764)
[ 2.015710] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
This patch fixes DRM_EXYNOS7DECON to DRM_EXYNOS7_DECON.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|
|
The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the
use of the enabled flag, which means that the code may attempt to call
win_enable on a NULL crtc. This results in the following oops on
Arndale:
[ 1.673479] Unable to handle kernel NULL pointer dereference at virtual address 00000368
[ 1.681500] pgd = c0004000
[ 1.684154] [00000368] *pgd=00000000
[ 1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 1.693012] Modules linked in:
[ 1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted
3.19.0-07545-g57485fa #1907
[ 1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
(....)
[ 2.014803] [<c02f9cfc>] (exynos_plane_destroy) from [<c02e61b4>] (drm_mode_config_cleanup+0x168/0x20c)
[ 2.024178] [<c02e61b4>] (drm_mode_config_cleanup) from [<c02f66fc>] (exynos_drm_load+0xac/0x12c)
This patch adds in a check to ensure exynos_crtc is not NULL before it
is dereferenced.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
|