aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu (follow)
AgeCommit message (Collapse)AuthorFilesLines
2015-03-04drm/i915: Check for driver readyness before handling an underrun interruptChris Wilson1-11/+7
When we takeover from the BIOS and install our interrupt handler, the BIOS may have left us a few surprises in the form of spontaneous interrupts. (This is especially likely on hardware like 965gm where display fifo underruns are continuous and the GMCH cannot filter that interrupt souce.) As we enable our IRQ early so that we can use it during hardware probing, our interrupt handler must be prepared to handle a few sources prior to being fully configured. As such, we need to add a simple is-ready check prior to dereferencing our KMS state for reporting underruns. Reported-by: Rob Clark <rclark@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org [Jani: dropped the extra !] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-03-03drm/radeon: fix interlaced modes on DCE8Alex Deucher1-0/+3
Need to double the viewport height. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: fix DRM_IOCTL_RADEON_CS oopsTommi Rantala1-1/+3
Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the following oops. Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort(). ---------------------------------- #include <stdint.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <drm/radeon_drm.h> static const struct drm_radeon_cs cs; int main(int argc, char **argv) { return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs); } ---------------------------------- [ttrantal@test2 ~]$ ./main /dev/dri/card0 [ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null) [ 46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] PGD 68f29067 PUD 688b5067 PMD 0 [ 46.905022] Oops: 0002 [#1] SMP [ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58 [ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007 [ 46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000 [ 46.905022] RIP: 0010:[<ffffffff814d6df2>] [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP: 0018:ffff880058e67998 EFLAGS: 00010246 [ 46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58 [ 46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000 [ 46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410 [ 46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0 [ 46.905022] FS: 00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000 [ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0 [ 46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [ 46.905022] Stack: [ 46.905022] ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] Call Trace: [ 46.905022] [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220 [ 46.905022] [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960 [ 46.905022] [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640 [ 46.905022] [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 46.905022] [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10 [ 46.905022] [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80 [ 46.905022] [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570 [ 46.905022] [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110 [ 46.905022] [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0 [ 46.905022] [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17 [ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85 [ 46.905022] RIP [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP <ffff880058e67998> [ 46.905022] CR2: 0000000000000000 [ 47.149253] ---[ end trace 09576b4e8b2c20b8 ]--- Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in cik_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in si_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in evergreen_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in r600_set_irqAlex Deucher1-0/+3
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in rs600_set_irqAlex Deucher1-0/+4
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03drm/radeon: do a posting read in r100_set_irqAlex Deucher1-0/+4
To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-03-03radeon/audio: fix DP audio on DCE6Slava Grigorev2-4/+12
Split DCE6 and DCE8 programming of DCCG_AUDIO_DTO1 registers to properly enable DP audio for both DCE revisions. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03radeon/audio: fix whitespaceSlava Grigorev1-16/+16
Use proper tabs. Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: adjust audio callback orderAlex Deucher1-14/+16
- Move it out of the UNIPHY case to handle older DCE blocks. - set audio dpms before video dpms Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: properly set dto for dp on DCE4/5Alex Deucher2-3/+10
If DCPLL or ext PLL is used, use the disp clk. If PPLL is used, use the dp clock. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon/audio: update EDID derived fields in modesetAlex Deucher1-5/+6
We don't necessarily have an EDID at this point when audio detect gets called. Ideally we'd update these fields in detect, but that requires a larger rework of the display detect code. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: don't toggle audio state in modesetAlex Deucher1-12/+1
Should be done only at detect time to avoid spurious state changes on the audio side. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon/audio: set mute around state setupAlex Deucher1-1/+2
To avoid possible sound artifacts while setting up audio. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: assign pin in detectAlex Deucher1-3/+3
We need the pin from detect on, it's too late in dpms. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/radeon: fix the audio dpms callbacksAlex Deucher4-70/+32
Don't touch the audio enable bits as these are already handled in display detection. Enable the hdmi secondary streams in hdmi enable to match dp. Rename dp dpms callback to be consistent with hdmi. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89327 https://bugzilla.kernel.org/show_bug.cgi?id=93921 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-03-03drm/i915: Fix modeset state confusion in the load detect codeDaniel Vetter1-0/+1
This is a tricky story of the new atomic state handling and the legacy code fighting over each another. The bug at hand is an underrun of the framebuffer reference with subsequent hilarity caused by the load detect code. Which is peculiar since the the exact same code works fine as the implementation of the legacy setcrtc ioctl. Let's look at the ingredients: - Currently our code is a crazy mix of legacy modeset interfaces to set the parameters and half-baked atomic state tracking underneath. While this transition is going we're using the transitional plane helpers to update the atomic side (drm_plane_helper_disable/update and friends), i.e. plane->state->fb. Since the state structure owns the fb those functions take care of that themselves. The legacy state (specifically crtc->primary->fb) is still managed by the old code (and mostly by the drm core), with the fb reference counting done by callers (core drm for the ioctl or the i915 load detect code). The relevant commit is commit ea2c67bb4affa84080c616920f3899f123786e56 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) - drm_plane_helper_disable has special code to handle multiple calls in a row - it checks plane->crtc == NULL and bails out. This is to match the proper atomic implementation which needs the crtc to get at the implied locking context atomic updates always need. See commit acf24a395c5a9290189b080383564437101d411c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 29 15:33:05 2014 +0200 drm/plane-helper: transitional atomic plane helpers - The universal plane code split out the implicit primary plane from the CRTC into it's own full-blown drm_plane object. As part of that the setcrtc ioctl (which updated both the crtc mode and primary plane) learned to set crtc->primary->crtc on modeset to make sure the plane->crtc assignments statate up to date in commit e13161af80c185ecd8dc4641d0f5df58f9e3e0af Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Apr 1 15:22:38 2014 -0700 drm: Add drm_crtc_init_with_planes() (v2) Unfortunately we've forgotten to update the load detect code. Which wasn't a problem since the load detect modeset is temporary and always undone before we drop the locks. - Finally there is a organically grown history (i.e. don't ask) around who sets the legacy plane->fb for the various driver entry points. Originally updating that was the drivers duty, but for almost all places we've moved that (plus updating the refcounts) into the core. Again the exception is the load detect code. Taking all together the following happens: - The load detect code doesn't set crtc->primary->crtc. This is only really an issue on crtcs never before used or when userspace explicitly disabled the primary plane. - The plane helper glue code short-circuits because of that and leaves a non-NULL fb behind in plane->state->fb and plane->fb. The state fb isn't a real problem (it's properly refcounted on its own), it's just the canary. - Load detect code drops the reference for that fb, but doesn't set plane->fb = NULL. This is ok since it's still living in that old world where drivers had to clear the pointer but the core/callers handled the refcounting. - On the next modeset the drm core notices plane->fb and takes care of refcounting it properly by doing another unref. This drops the refcount to zero, leaving state->plane now pointing at freed memory. - intel_plane_duplicate_state still assume it owns a reference to that very state->fb and bad things start to happen. Fix this all by applying the same duct-tape as for the legacy setcrtc ioctl code and set crtc->primary->crtc properly. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: Rob Clark <robdclark@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Matt Roper <matthew.d.roper@intel.com> Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-03-03Revert "drm/rockchip: Flip select/depends in Kconfig"Dave Airlie1-1/+1
This reverts commit 9c58e8dbd3bfe7197323c88a784617afeffa9f87. This doesn't seem to fully fix this, Kbuild who knows. Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-03-03drm/rockchip: Flip select/depends in KconfigDaniel Vetter1-1/+1
Otherwise Kconfig gets confused and somehow ends up creating a 2nd drm submenu. I couldn't find i915 because of this any more at first. Cc: Andy Yan <andy.yan@rock-chips.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: linux-kbuild@vger.kernel.or Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
2015-03-03Merge tag 'imx-drm-fixes-2015-02-24' of git://git.pengutronix.de/git/pza/linux into drm-fixesDave Airlie4-21/+50
imx-drm fixes for mode fixup, dw_hdmi/imx, and parallel-display - A clock fix for too large pixel clocks depending on the DI clock flag simplification patch - Pruning of unsupported modes and a missing end of array element for dw_hdmi-imx - LVDS modeset fix for mode fixup - Fix parallel-display deferred probing if drm_panel is used * tag 'imx-drm-fixes-2015-02-24' of git://git.pengutronix.de/git/pza/linux: DRM: i.MX: parallel display: Support probe deferral for finding DRM panel drm/imx: imx-ldb: enable DI clock in encoder_mode_set drm/imx: dw_hdmi-imx: add end of array element to current control array drm/imx: dw_hdmi-imx: add mode_valid callback prune unsupported modes gpu: ipu-v3: do not divide by zero if the pixel clock is too large
2015-02-27Merge branch 'drm-atmel-hlcdc-fixes' of git://github.com/bbrezillon/linux-at91 into drm-fixesDave Airlie3-4/+3
minor atmel hclcdc fixes. * 'drm-atmel-hlcdc-fixes' of git://github.com/bbrezillon/linux-at91: drm: atmel-hlcdc: remove clock polarity from crtc driver drm: atmel-hlcdc: remove useless pm_runtime_put_sync in probe drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when disabling it
2015-02-27Merge tag 'drm-intel-fixes-2015-02-26' of git://anongit.freedesktop.org/drm-intel into drm-fixesDave Airlie7-23/+71
First batch of fixes for v4.0-rc, plenty of cc: stable material. * tag 'drm-intel-fixes-2015-02-26' of git://anongit.freedesktop.org/drm-intel: drm/i915: Fix frontbuffer false positve. drm/i915: Align initial plane backing objects correctly drm/i915: avoid processing spurious/shared interrupts in low-power states drm/i915: Check obj->vma_list under the struct_mutex drm/i915: Fix a use after free, and unbalanced refcounting drm/i915: Dell Chromebook 11 has PWM backlight drm/i915/skl: handle all pixel formats in skylake_update_primary_plane() drm/i915/bdw: PCI IDs ending in 0xb are ULT.
2015-02-26drm: atmel-hlcdc: remove clock polarity from crtc driverNicolas Ferre1-1/+1
Remove this configuration bit in crtc driver as the rising edge clock is widely used. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-02-25drm/radeon: only enable DP audio if the monitor supports itAlex Deucher1-6/+15
We were enabling DP secondary streams even if the monitor didn't support them. Fixes display problems on some DP monitors. Tested-by: Jim Boz <jim876@xs4all.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-02-25drm/radeon: fix atom aux payload size check for writes (v2)Alex Deucher1-0/+7
The atom aux param interface only supports 4 bits for the total write transfer size (header + payload). This limits us to 12 bytes of payload rather than 16. Add a check for this. Reads are not affected. v2: switch to WARN_ON_ONCE Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-02-25drm/radeon: fix 1 RB harvest config setup for TN/RLAlex Deucher1-4/+4
The logic was reversed from what the hw actually exposed. Fixes graphics corruption in certain harvest configurations. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-02-25drm/radeon: enable SRBM timeout interrupt on EG/NIChristian König4-0/+17
Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-02-25drm/radeon: enable SRBM timeout interrupt on SIChristian König2-0/+11
Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-02-25drm/radeon: enable SRBM timeout interrupt on CIK v2Leo Liu2-0/+12
v2: disable it on suspend Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-02-25drm/radeon: dump full IB if we hit a packet errorAlex Deucher2-9/+22
Dump the whole IB if we run into an invalid packet. This makes things much easier to debug. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89148 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2015-02-25drm/radeon: disable mclk switching with 120hz+ monitorsAlex Deucher1-0/+6
These tend to be problematic even if the vblank period is long enough. This needs more investigation across a wider range of displays. Disable for now. bugs: https://bugs.freedesktop.org/show_bug.cgi?id=87796 https://bugs.freedesktop.org/show_bug.cgi?id=89198 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-02-25drm/radeon: use drm_mode_vrefresh() rather than mode->vrefreshAlex Deucher1-1/+1
Just in case it hasn't been calculated for the mode. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-02-25drm/radeon: enable native backlight control on old macsNathan-J. Hirschauer1-0/+3
Commit b7bc596ebbe0 ("drm/radeon: disable native backlight control on pre-r6xx asics (v2)") accidently broke backlight control on old mac laptops that use the on-GPU backlight controller. Signed-off-by: Nathan-J. Hirschauer <nathanhi@deepserve.info> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2015-02-25drm/i915: Fix frontbuffer false positve.Rodrigo Vivi1-3/+0
This return 0 without setting atomic bits on fb == crtc->cursor->fb where causing frontbuffer false positives. According to Daniel: The original regression seems to have been introduced in the original check/commit split: commit 757f9a3e5b8a812af0c213099a5b31cb423f4d3c Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 24 14:20:24 2014 -0300 drm/i915: move check of intel_crtc_cursor_set_obj() out Which already cause other trouble, resulting in the check getting moved in commit e391ea882b1a04fb3f559287ac694652a3cd9da9 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 24 14:20:25 2014 -0300 drm/i915: Fix not checking cursor and object sizes The frontbuffer tracking itself only was broken when we shifted it into the check/commit logic with: commit 32b7eeec4d1e861230b09d437e95d76c86ff4a68 Author: Matt Roper <matthew.d.roper@intel.com> Date: Wed Dec 24 07:59:06 2014 -0800 drm/i915: Refactor work that can sleep out of commit (v7) v2: When putting more debug prints I notice the solution was simpler than I thought. AMS design is solid, just this return was wrong. Sorry for the noise. v3: Remove the entire chunck that would probably be removed by gcc anyway. (by Daniel) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-02-24drm/i915: Align initial plane backing objects correctlyDaniel Vetter2-10/+14
Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: stable@vger.kernel.org Cc: Johannes W <jargon@molb.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Johannes W <jargon@molb.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-02-24drm/i915: avoid processing spurious/shared interrupts in low-power statesImre Deak1-0/+22
Atm, it's possible that the interrupt handler is called when the device is in D3 or some other low-power state. It can be due to another device that is still in D0 state and shares the interrupt line with i915, or on some platforms there could be spurious interrupts even without sharing the interrupt line. The latter case was reported by Klaus Ethgen using a Lenovo x61p machine (gen 4). He noticed this issue via a system suspend/resume hang and bisected it to the following commit: commit e11aa362308f5de467ce355a2a2471321b15a35c Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jun 18 09:52:55 2014 -0700 drm/i915: use runtime irq suspend/resume in freeze/thaw This is a problem, since in low-power states IIR will always read 0xffffffff resulting in an endless IRQ servicing loop. Fix this by handling interrupts only when the driver explicitly enables them and so it's guaranteed that the interrupt registers return a valid value. Note that this issue existed even before the above commit, since during runtime suspend/resume we never unregistered the handler. v2: - clarify the purpose of smp_mb() vs. synchronize_irq() in the code comment (Chris) v3: - no need for an explicit smp_mb(), we can assume that synchronize_irq() and the mmio read/writes in the install hooks provide for this (Daniel) - remove code comment as the remaining synchronize_irq() is self explanatory (Daniel) v4: - drm_irq_uninstall() implies synchronize_irq(), so no need to call it explicitly (Daniel) Reference: https://lkml.org/lkml/2015/2/11/205 Reported-and-bisected-by: Klaus Ethgen <Klaus@Ethgen.ch> Cc: stable@vger.kernel.org Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-02-24drm/i915: Check obj->vma_list under the struct_mutexChris Wilson1-3/+4
When we walk the list of vma, or even for protecting against concurrent framebuffer creation, we must hold the struct_mutex or else a second thread can corrupt the list as we walk it. Fixes regression from commit d7f46fc4e7323887494db13f063a8e59861fefb0 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA References: https://bugs.freedesktop.org/show_bug.cgi?id=89085 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-02-24drm/i915: Fix a use after free, and unbalanced refcountingNick Hoath3-7/+18
When converting from implicitly tracked execlist queue items to ref counted requests, not all frees of requests were replaced with unrefs, and extraneous refs/unrefs of contexts were added. Correct the unbalanced refcount & replace the frees. Remove a noisy warning when hitting the request creation path. drm_i915_gem_request and intel_context are both kref reference counted structures. Upon allocation, drm_i915_gem_request's ref count should be bumped using kref_init. When a context is assigned to the request, the context's reference count should be bumped using i915_gem_context_reference. i915_gem_request_reference will reduce the context reference count when the request is freed. Problem introduced in commit 6d3d8274bc45de4babb62d64562d92af984dd238 Author: Nick Hoath <nicholas.hoath@intel.com> AuthorDate: Thu Jan 15 13:10:39 2015 +0000 drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request v2: Added comments explaining how the ctx pointer and the request object should be ref-counted. Removed noisy warning. v3: Cleaned up the language used in the commit & the header description (Thanks David Gordon) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652 Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> Reviewed-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-02-24drm: atmel-hlcdc: remove useless pm_runtime_put_sync in probeBoris Brezillon1-2/+0
Remove a useless pm_runtime_put_sync leading to unbalanced usage_count. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by: Sylvain Rochet <sylvain.rochet@finsecur.com>
2015-02-24drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when disabling itBoris Brezillon1-1/+2
The A2Q (Add To Queue) and UPDATE bits are left in their previous state when resetting the layer. This lead to weird behavior when enabling the plane again: the framebuffer previously queued is dequeued and we end up with access to an old memory region. Reset those bits when resetting the channel. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2015-02-24Merge tag 'drm-amdkfd-fixes-2015-02-23' of git://people.freedesktop.org/~gabbayo/linux into drm-fixesDave Airlie3-9/+11
- Fix a bug that caused 15% CPU performance drop in Kaveri. This was caused because we overwritten the initialization of the first pipe (out of eight), which is dedicated to radeon operation. The fix was tested by Michel Dänzer. This bug was introduced by a patch I prepared (yeah, my bad) and was merged to 3.19-rc6. Therefore, I also marked it as Cc:stable. - Fix sparse warning * tag 'drm-amdkfd-fixes-2015-02-23' of git://people.freedesktop.org/~gabbayo/linux: drm/amdkfd: don't set get_pipes_num() as inline drm/amdkfd: Initialize only amdkfd's assigned pipelines
2015-02-24Merge tag 'drm/tegra/for-3.20-rc1-fixes' of git://anongit.freedesktop.org/tegra/linux into drm-fixesDave Airlie2-39/+48
drm/tegra: Fixes for v3.20-rc1 This fixes a bit of fallout that was caused by the atomic modesetting driver conversion and some last-minute changes in the DRM atomic core. It also fixes a bug exposed by recent changes in the clock framework which results in non-working HDMI. * tag 'drm/tegra/for-3.20-rc1-fixes' of git://anongit.freedesktop.org/tegra/linux: drm/tegra: dc: Move more code into ->init() drm/tegra: dc: Wire up CRTC parent of atomic state drm/tegra: dc: Reset state's active_changed field drm/tegra: hdmi: Explicitly set clock rate
2015-02-24drm: Fix deadlock due to getconnector locking changesDaniel Vetter1-1/+2
In commit ccfc08655d5fd5076828f45fb09194c070f2f63a Author: Rob Clark <robdclark@gmail.com> Date: Thu Dec 18 16:01:48 2014 -0500 drm: tweak getconnector locking We need to extend the locking to cover connector->state reading for atomic drivers, but the above commit was a bit too eager and also included the fill_modes callback. Which on i915 on old platforms using load detection needs to acquire modeset locks, resulting in a deadlock on output probing. Reported-by: Marc Finet <m.dreadlock@gmail.com> Cc: Marc Finet <m.dreadlock@gmail.com> Cc: robdclark@gmail.com Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-02-23DRM: i.MX: parallel display: Support probe deferral for finding DRM panelLiu Ying1-1/+4
Signed-off-by: Liu Ying <Ying.Liu@freescale.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-02-23drm/imx: imx-ldb: enable DI clock in encoder_mode_setPhilipp Zabel1-15/+13
Commit eb10d6355532 ("imx-drm: encoder prepare/mode_set must use adjusted mode") broke the first LVDS modeset by using crtc->hwmode before crtc mode_set is called. In fact, encoder prepare is not supposed to prepare the display clock at all. Rather encoder mode_set should be used to set the DI clock rate, before it is enabled by crtc commit. Reported-by: Liu Ying <Ying.Liu@freescale.com> Tested-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-02-23drm/imx: dw_hdmi-imx: add end of array element to current control arrayPhilipp Zabel1-1/+3
The loop iterating over curr_ctrl in dw_hdmi terminates on mpixelclock == ~0UL, so there needs to be an end of list element here in case a mode with a pixel clock larger than 216 MHz is set. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-02-23drm/imx: dw_hdmi-imx: add mode_valid callback prune unsupported modesPhilipp Zabel1-4/+28
This patch limits the pixel clock to 13.4 MHz - 266 MHz for i.MX6Q and 13.5 MHz - 270 MHz for i.MX6DL, which is the range documented in the HDMI Transmitter chapter of the respective reference manuals. Without this patch, when connected to a monitor capable of 2160p60 modes, dw_hdmi will happily report this mode and the IPU code will cause a division by zero in ipu_di_config_clock when trying to figure out how to divide the 264 MHz HSP clock down to ~600 MHz. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2015-02-23gpu: ipu-v3: do not divide by zero if the pixel clock is too largePhilipp Zabel1-0/+2
Even if an unsupported mode with a pixel clock larger than two times the 264 MHz IPU HSP clock is set, don't divide by zero. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.