summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'drm-intel-fixes-2014-04-11' of ↵Dave Airlie2014-04-168-137/+122Star
|\ | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Some fixes from Intel. * tag 'drm-intel-fixes-2014-04-11' of git://anongit.freedesktop.org/drm-intel: drm/i915: Always use kref tracking for all contexts. drm/i915: do not setup backlight if not available according to VBT drm/i915: check VBT for supported backlight type drm/i915: Disable self-refresh for untiled fbs on i915gm drm/mm: Don't WARN if drm_mm_reserve_node
| * drm/i915: Always use kref tracking for all contexts.Chris Wilson2014-04-114-137/+93Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we always initialize kref for the context, even if we are using fake contexts for hangstats when there is no hw support, we can forgo the dance to dereference the ctx->obj and inspect whether we are permitted to use kref inside i915_gem_context_reference() and _unreference(). My ulterior motive here is to improve the debugging of a use-after-free of ctx->obj. This patch avoids the dereference here and instead forces the assertion checks associated with kref. v2: Refactor the fake contexts to being even more like the real contexts, so that there is much less duplicated and special case code. v3: Tweaks. v4: Tweaks, minor. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76671 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: lu hua <huax.lu@intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [Jani: tiny change to backport to drm-intel-fixes.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: do not setup backlight if not available according to VBTJani Nikula2014-04-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some machines use an external EC for controlling the backlight. Info about this is present in the VBT. Do not setup native backlight control if no PWM backlight is available or supported according to VBT. The acpi_backlight interface appears to work for the EC control. In most cases there has been no harm done, but it looks like there are machines out there that have both an EC and our PWM line connected to the same wire. This, obviously, does not end well. This should fix the regression caused by commit bc0bb9fd1c7810407ab810d204bbaecb255fddde Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:14:29 2013 +0200 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE AFAICT the quirk removed by the above commit effectively resulted in i915 not driving the backlight PWM output, thus not messing things up. Additionally this should fix the regression caused by commit fbc9fe1b4f222a7c575e3bd8e9defe59c6190a04 Author: Aaron Lu <aaron.lu@intel.com> Date: Fri Oct 11 21:27:45 2013 +0800 ACPI / video: Do not register backlight if win8 and native interface exists which left some machines without a functioning backlight interface. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76276 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=62281 CC: Aaron Lu <aaron.lu@intel.com> CC: Eric Griffith <EGriffith92@gmail.com> CC: Kent Baxley <kent.baxley@canonical.com> Tested-by: Kamal Mostafa <kamal@canonical.com> Tested-by: Martin <bugs@mrvanes.com> Tested-by: jrg.otte@gmail.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: check VBT for supported backlight typeJani Nikula2014-04-113-0/+14
| | | | | | | | | | | | | | | | | | | | | | The only supported types are none and PWM. Other values are obsolete or reserved, don't add them. Tested-by: Kamal Mostafa <kamal@canonical.com> Tested-by: Martin <bugs@mrvanes.com> Tested-by: jrg.otte@gmail.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Disable self-refresh for untiled fbs on i915gmDaniel Vetter2014-04-101-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently it doesn't work. X-tiled self-refresh works flawlessly otoh. Apparently X still works correctly with linear framebuffers, so might just be an issue with the initial modeset. It's unclear whether this just borked wm setup from our side or a hw restriction, but just disabling gets things going. Note that this regression was only brought to light with commit 3f2dc5ac05714711fc14f2bf0ee5e42d5c08c581 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Jan 10 14:06:47 2014 +0200 drm/i915: Fix 915GM self-refresh enable/disable before that self-refresh for i915GM didn't work at all. Kudos to Ville for spotting a little bug in the original patch I've attached to the bug. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76103 Tested-by: Krzysztof Mazur <krzysiek@podlesie.net> Cc: Krzysztof Mazur <krzysiek@podlesie.net> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: rebase on top of drm-next with primary plane support.] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2014-04-0848-4135/+8785
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "Highlights: - drm: Generic display port aux features, primary plane support, drm master management fixes, logging cleanups, enforced locking checks (instead of docs), documentation improvements, minor number handling cleanup, pseudofs for shared inodes. - ttm: add ability to allocate from both ends - i915: broadwell features, power domain and runtime pm, per-process address space infrastructure (not enabled) - msm: power management, hdmi audio support - nouveau: ongoing GPU fault recovery, initial maxwell support, random fixes - exynos: refactored driver to clean up a lot of abstraction, DP support moved into drm, LVDS bridge support added, parallel panel support - gma500: SGX MMU support, SGX irq handling, asle irq work fixes - radeon: video engine bringup, ring handling fixes, use dp aux helpers - vmwgfx: add rendernode support" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (849 commits) DRM: armada: fix corruption while loading cursors drm/dp_helper: don't return EPROTO for defers (v2) drm/bridge: export ptn3460_init function drm/exynos: remove MODULE_DEVICE_TABLE definitions ARM: dts: exynos4412-trats2: enable exynos/fimd node ARM: dts: exynos4210-trats: enable exynos/fimd node ARM: dts: exynos4412-trats2: add panel node ARM: dts: exynos4210-trats: add panel node ARM: dts: exynos4: add MIPI DSI Master node drm/panel: add S6E8AA0 driver ARM: dts: exynos4210-universal_c210: add proper panel node drm/panel: add ld9040 driver panel/ld9040: add DT bindings panel/s6e8aa0: add DT bindings drm/exynos: add DSIM driver exynos/dsim: add DT bindings drm/exynos: disallow fbdev initialization if no device is connected drm/mipi_dsi: create dsi devices only for nodes with reg property drm/mipi_dsi: add flags to DSI messages Skip intel_crt_init for Dell XPS 8700 ...
| * Merge tag 'drm-intel-fixes-2014-04-04' of ↵Dave Airlie2014-04-0526-405/+590
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Merge window -fixes pull request as usual. Well, I did sneak in Jani's drm_i915_private_t typedef removal, need to have fun with a big sed job too ;-) Otherwise: - hdmi interlaced fixes (Jesse&Ville) - pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but not cc: stable since only really relevant for igt runs) - large cursor wm fixes (Chris) - fix gpu turbo boost/throttle again, was getting stuck due to vlv rps patches (Chris+Imre) - fix runtime pm fallout (Paulo) - bios framebuffer inherit fix (Chris) - a few smaller things * tag 'drm-intel-fixes-2014-04-04' of git://anongit.freedesktop.org/drm-intel: (196 commits) Skip intel_crt_init for Dell XPS 8700 drm/i915: vlv: fix RPS interrupt mask setting Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec" drm/i915: move power domain init earlier during system resume drm/i915: Fix the computation of required fb size for pipe drm/i915: don't get/put runtime PM at the debugfs forcewake file drm/i915: fix WARNs when reading DDI state while suspended drm/i915: don't read cursor registers on powered down pipes drm/i915: get runtime PM at i915_display_info drm/i915: don't read pp_ctrl_reg if we're suspended drm/i915: get runtime PM at i915_reg_read_ioctl drm/i915: don't schedule force_wake_timer at gen6_read drm/i915: vlv: reserve the GT power context only once during driver init drm/i915: prefer struct drm_i915_private to drm_i915_private_t drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_t drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_t drm/i915/display: prefer struct drm_i915_private to drm_i915_private_t drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_t drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_t ...
| | * Skip intel_crt_init for Dell XPS 8700Giacomo Comes2014-04-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Dell XPS 8700 has a onboard Display port and HDMI port and no VGA port. The call intel_crt_init freeze the machine, so skip such call. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73559 Signed-off-by: Giacomo Comes <comes at naic.edu> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: vlv: fix RPS interrupt mask settingImre Deak2014-04-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This typo may lead to missed RPS interrupts and as a result a too low or too high frequency for the current workload. The interrupt mask will be set properly at a subsequent GPU idle event, but can get corrupted again at the next RPS up/down event. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"Deepak S2014-04-041-4/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per the inputs provided by hardware team we still use DDR Rates as 0,1=800, 2=1066, 3=1333. With this change, Turbo freqs used on current machines matches. This reverts commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6. commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Nov 4 16:07:00 2013 -0800 drm/i915/vlv: fixup DDR freq detection per Punit spec v2: Add reference to previous commit which changed this. (Daniel) Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: move power domain init earlier during system resumeImre Deak2014-04-041-14/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During resume the intel hda audio driver depends on the i915 driver reinitializing the audio power domain. Since the order of calling the i915 resume handler wrt. that of the audio driver is not guaranteed, move the power domain reinitialization step to the resume_early handler. This is guaranteed to run before the resume handler of any other driver. The power domain initialization in turn requires us to enable the i915 pci device first, so move that part earlier too. Accordingly disabling of the i915 pci device should happen after the audio suspend handler ran. So move the disabling later from the i915 resume handler to the resume_late handler. v2: - move intel_uncore_sanitize/early_sanitize earlier too, so they don't get reordered wrt. intel_power_domains_init_hw() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76152 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Cc: stable@vger.kernel.org [danvet: Add cc: stable and loud comments that this is just a hack.] [danvet: Fix "Should it be static?" sparse warning reported by Wu Fengguang's kbuilder.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Fix the computation of required fb size for pipeChris Wilson2014-04-021-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The computation of required framebuffer size in commit d978ef14456a38034f6c0e94a794129501f89200 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Mar 7 08:57:51 2014 -0800 drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12 is too optimistic, and would rely on the invariant fb being reconstructed to exactly fit each pipe (and probably ignore hardware limits). Instead, we want to compute the upper bound on what the display engine will access and ensure that is within the inherited framebuffer. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: don't get/put runtime PM at the debugfs forcewake filePaulo Zanoni2014-04-011-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | Because gen6_gt_force_wake_{get,put} should already be responsible for getting/putting runtime PM. If we keep these calls, debugfs will not be testing the get/put calls of the forcewake functions. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: fix WARNs when reading DDI state while suspendedPaulo Zanoni2014-04-012-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If runtime PM is enabled and we unset all modes, we will runtime suspend after __intel_set_mode() , then function intel_modeset_check_state() will try to read the HW state while it is suspended and trigger lots of WARNs because it shouldn't be reading registers. So on this patch we make intel_ddi_connector_get_hw_state() return false in case the power domain is disabled, and we also make intel_display_power_enabled() return false in case the device is suspended. Notice that we can't just use intel_display_power_enabled_sw() because while the driver is being initialized the power domain refcounts are not reflecting the real state of the hardware. Just for reference, I have previously published an alternate patch for this problem, called "drm/i915: get runtime PM at intel_set_mode". Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: don't read cursor registers on powered down pipesPaulo Zanoni2014-04-011-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At i915_display_info, don't call cursor_position() for a disabled CRTC, since the CRTC may be on a powered down pipe, and this will cause "Unclaimed register before interrupt" error messages. Testcase: igt/pm_pc8/debugfs-read Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: get runtime PM at i915_display_infoPaulo Zanoni2014-04-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we may get some WARNs complaining that we're reading a register while we're suspended. Testcase: igt/pm_pc8/debugfs-read Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: don't read pp_ctrl_reg if we're suspendedPaulo Zanoni2014-04-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... at edp_have_panel_vdd. Just return false, saying we don't have the panel VDD since the device is suspended. We started getting WARNs about this problem since the patch that started checking if we're suspended while reading registers. Example backtrace provided by Paulo: [ 63.572201] [drm:hsw_enable_pc8] Enabling package C8+ [ 63.581831] [drm:i915_runtime_suspend] Device suspended [ 63.664798] ------------[ cut here ]------------ [ 63.664824] WARNING: CPU: 3 PID: 828 at drivers/gpu/drm/i915/intel_uncore.c:47 assert_device_not_suspended.isra.7+0x32/0x40 [i915]() [ 63.664826] Device suspended [ 63.664828] Modules linked in: ccm fuse ip6table_filter ip6_tables ebtable_nat ebtables arc4 ath9k_htc ath9k_common ath9k_hw mac80211 ath cfg80211 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal coretemp microcode i2c_i801 e1000e pcspkr serio_raw lpc_ich ptp pps_core mei_me mei mfd_core dm_crypt i915 crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_algo_bit drm_kms_helper drm video [ 63.664867] CPU: 3 PID: 828 Comm: kworker/3:3 Not tainted 3.14.0+ #153 [ 63.664869] Hardware name: Intel Corporation Shark Bay Client platform/WhiteTip Mountain 1, BIOS HSWLPTU1.86C.0133.R00.1309172123 09/17/2013 [ 63.664887] Workqueue: events edp_panel_vdd_work [i915] [ 63.664889] 0000000000000009 ffff88009d745c28 ffffffff8167ec6f ffff88009d745c70 [ 63.664895] ffff88009d745c60 ffffffff8106c8ed ffff880036278000 00000000000c7204 [ 63.664900] ffff88014f2d3040 ffff880036278070 0000000000000001 ffff88009d745cc0 [ 63.664905] Call Trace: [ 63.664911] [<ffffffff8167ec6f>] dump_stack+0x4d/0x66 [ 63.664916] [<ffffffff8106c8ed>] warn_slowpath_common+0x7d/0xa0 [ 63.664920] [<ffffffff8106c95c>] warn_slowpath_fmt+0x4c/0x50 [ 63.664926] [<ffffffff810bd6be>] ? mark_held_locks+0xae/0x130 [ 63.664941] [<ffffffffa00d80d2>] assert_device_not_suspended.isra.7+0x32/0x40 [i915] [ 63.664956] [<ffffffffa00d99d2>] gen6_read32+0x32/0x120 [i915] [ 63.664969] [<ffffffffa00d99a0>] ? gen6_read8+0x120/0x120 [i915] [ 63.664985] [<ffffffffa0106f8f>] edp_have_panel_vdd+0x3f/0x50 [i915] [ 63.665000] [<ffffffffa01074e8>] edp_panel_vdd_off_sync+0x58/0x1c0 [i915] [ 63.665004] [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560 [ 63.665018] [<ffffffffa0107684>] edp_panel_vdd_work+0x34/0x50 [i915] [ 63.665022] [<ffffffff8108a0d7>] process_one_work+0x1f7/0x560 [ 63.665026] [<ffffffff8108a06c>] ? process_one_work+0x18c/0x560 [ 63.665031] [<ffffffff8108ae2b>] worker_thread+0x11b/0x3a0 [ 63.665035] [<ffffffff8108ad10>] ? manage_workers.isra.21+0x2a0/0x2a0 [ 63.665039] [<ffffffff810916fc>] kthread+0xfc/0x120 [ 63.665043] [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230 [ 63.665048] [<ffffffff8169082c>] ret_from_fork+0x7c/0xb0 [ 63.665052] [<ffffffff81091600>] ? kthread_create_on_node+0x230/0x230 [ 63.665054] ---[ end trace 1250bcc890af9999 ]--- [ 63.665060] [drm:edp_panel_vdd_off_sync] Turning eDP VDD off [ 63.665061] ------------[ cut here ]------------ Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: get runtime PM at i915_reg_read_ioctlPaulo Zanoni2014-04-011-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid WARNs when we call it. Testcase: igt/pm_pc8/reg-read-ioctl Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75693 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: don't schedule force_wake_timer at gen6_readPaulo Zanoni2014-04-011-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far force_wake_timer was only used by gen6_gt_force_wake_put. Since we always had balanced gen6_gt_force_wake_get/put calls, we could guarantee balanced calls to intel_runtime_pm_get/put. Commit 8232644ccf099548710843e97360a3fcd6d28e04, "drm/i915: Convert the forcewake worker into a timer func" started scheduling the force_wake_timer at gen6_read, which resulted in an unbalanced runtime_pm refcount. So this commit just reverts to the old behavior until we can find a proper way to used delayed force_wake from the register read/write macros without leaving the runtime_pm refcounts unbalanced and without runtime suspending the driver while forcewake is active. Testcase: igt/pm_pc8/rte Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76544 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: vlv: reserve the GT power context only once during driver initImre Deak2014-04-013-7/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm we reserve/allocate and free the power context during GT power enable/disable time. There is no need to do this, we can reserve/allocate the buffer once during driver loading and free it during driver cleanup. The re-reservation can also fail in case the driver previously manages to allocate something on the given fixed address. The buffer isn't exepected to move even if allocated by the BIOS, for safety add an assert to check this assumption. This also fixed a bug for Ville, where re-reserving the context failed during a GPU reset (I assume because something else got allocated on its fixed address). Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-319-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the rest of the references to drm_i915_private_t. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> [danvet: Drop hunk in i915_cmd_parser.c] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-311-12/+12
| | | | | | | | | | | | | | | | | | | | | No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-311-19/+19
| | | | | | | | | | | | | | | | | | | | | No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/display: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-311-11/+11
| | | | | | | | | | | | | | | | | | | | | No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-311-55/+55
| | | | | | | | | | | | | | | | | | | | | Also drop any unnecessary casts. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-311-23/+23
| | | | | | | | | | | | | | | | | | | | | No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-311-24/+24
| | | | | | | | | | | | | | | | | | | | | Also drop any unnecessary casts. No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/debugfs: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-311-23/+23
| | | | | | | | | | | | | | | | | | | | | No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Mask PM/RPS interrupt generation based on activityChris Wilson2014-03-311-16/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The speculation is that we can conserve more power by masking off the interrupts at source (PMINTRMSK) rather than filtering them by the up/down thresholds (RPINTLIM). We can select which events we know will be active based on the current frequency versus our imposed range, i.e. if at minimum, we know we will not want to generate any more down-interrupts and vice versa. v2: We only need the TIMEOUT when above min frequency. v3: Tweak VLV at the same time Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Deepak S <deepak.s@linux.intel.com> Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Refactor gen6_set_rpsChris Wilson2014-03-311-20/+14Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | What used to be a short-circuit now needs to adjust interrupt masking in response to user requests for changing the min/max allowed frequencies. This is currently done by a special case and early return, but the next patch adds another common action to take, so refactor the code to reduce duplication. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq."Chris Wilson2014-03-313-49/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 2754436913b94626a5414d82f0996489628c513d. Conflicts: drivers/gpu/drm/i915/i915_irq.c The partial application of interrupt masking without regard to other pathways for adjusting the RPS frequency results in completely disabling the PM interrupts. This leads to excessive power consumption as the GPU is kept at max clocks (until the failsafe mechanism fires of explicitly downclocking the GPU when all requests are idle). Or equally as bad for the UX, the GPU is kept at minimum clocks and prevented from upclocking in response to a requirement for more power. Testcase: pm_rps/blocking Cc: Deepak S <deepak.s@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Make sure vsyncshift is positiveVille Syrjälä2014-03-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If vsyncshift comes out as negative, add one htotal to it to get the corresponding positive value. This is rather theoretical as it would require a mode where the hsync+back porch is very long and the active+front porch very short. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Fix the interlace mode selection for gmch platformsVille Syrjälä2014-03-311-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PIPECONF_INTERLACE_W_FIELD_INDICATION is only meant to be used for sdvo since it implies a slightly weird vsync shift of htotal/2. For everything else we should use PIPECONF_INTERLACE_W_SYNC_SHIFT and let the value in the VSYNCSHIFT register take effect. The only exception is gen3 simply because VSYNCSHIFT didn't exist yet. Gen2 doesn't support interlaced modes at all, so we can drop the explicit gen2 checks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Program VSYNCSHIFT in a more consistent mannerVille Syrjälä2014-03-311-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When interlaced sdvo output is used, vsyncshift should supposedly be (htotal-1)/2. In reality PIPECONF/TRANSCONF will override it by using the legacy vsyncshift interlace mode which causes the hardware to ignore the VSYNCSHIFT register. The only odd thing here is that on PCH platforms we program the VSYNCSHIFT on both CPU and PCH, and it's not entirely clear if both sides have to agree on the value or not. On the CPU side there's no way to override the value via PIPECONF anymore, so if we want to make the CPU side agree with the PCH side, we should probably program the approriate value into VSYNCSHIFT manually. So let's do that, but for now leave the PCH side to still use the legacy interlace mode in TRANSCONF. We can also drop the gen2 check since gen2 doesn't support interlaced modes at all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915/vlv: use W_SYNC_SHIFT for interlaced modes on VLVJesse Barnes2014-03-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes HDMI testers happier on VLV platforms. It may be that we need it for any non-SVO platform, but I don't have any tests to back that up, so I'm leaving other pre-ILK platforms alone for now. Tested-by: "Clint Taylor <clinton.a.taylor@intel.com>" Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74964 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: restrict vt-d stolen memory workaround to pre-gen8Daniel Vetter2014-03-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We want future generations to at least attempt to use all features, so restrict the stolen memory disabling when vt-d is enabled to the latest generation we have reports for. Which is a HSW per the original report. Also once we get a bit a hold of some of the mysterious framebuffer in stolen memory issues that still haunt bugzilla, we should probably drop this hack again and see what happens. This was introduced in commit 0f4706d2740f2a221cd502922b22e522009041d9 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Mar 18 14:50:50 2014 +0200 drm/i915: Disable stolen memory when DMAR is active Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: David Woodhouse <dwmw2@infradead.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=68535 Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * Merge tag 'v3.14' into drm-intel-next-queuedDaniel Vetter2014-03-313-31/+49
| | |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.14 The vt-d w/a merged late in 3.14-rc needs a bit of fine-tuning, hence backmerge. Conflicts: drivers/gpu/drm/i915/i915_gem_gtt.c drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_dp.c All trivial adjacent lines changed type conflicts, so trivial git doesn't even show them in the merg commit. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/tv: fix gen4 composite s-video tv-outJani Nikula2014-03-281-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is *not* bisected, but the likely regression is commit c35614380d5c956bfda20eab2755b2f5a7d6f1e7 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Tue Nov 24 09:48:48 2009 +0800 drm/i915: Don't set up the TV port if it isn't in the BIOS table. The commit does not check for all TV device types that might be present in the VBT, disabling TV out for the missing ones. Add composite S-video. Reported-and-tested-by: Matthew Khouzam <matthew.khouzam@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73362 Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Split 64bit hexadecimal addresses to make them easier to readChris Wilson2014-03-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Broadwell introduces large address spaces, greater than 32bits in width. These require that we then store and print 64bit values. If we were to zero pad them out to 16 hexadecimal places, we have to carefully count the leading zeroes - which is easy to make a mistake. Conversely, if we do not zero pad out to 16, but keep it padding to 8 hexadecimal places, it is very easy to miss an address that is actually larger than 4GiB. A suggested compromise is to insert a space between the upper and lower dwords of the address so that we can continue with our accustom 32bit parser. (Alternatively, we could do the equivalent in our userspace decoder.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Broadwell expands ACTHD to 64bitChris Wilson2014-03-286-13/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As Broadwell has an increased virtual address size, it requires more than 32 bits to store offsets into its address space. This includes the debug registers to track the current HEAD of the individual rings, which may be anywhere within the per-process address spaces. In order to find the full location, we need to read the high bits from a second register. We then also need to expand our storage to keep track of the larger address. v2: Carefully read the two registers to catch wraparound between the reads. v3: Use a WARN_ON rather than loop indefinitely on an unstable register read. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Drop spurious hunk which conflicted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/bdw: Implement Wa4x4STCOptimizationDisable:bdwDamien Lespiau2014-03-282-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not implementing this W/A can lead to hangs. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Rafael Barbalho <rafael.barbalho@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Undo gtt scratch pte unmapping againDaniel Vetter2014-03-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It apparently blows up on some machines. This functionally reverts commit 828c79087cec61eaf4c76bb32c222fbe35ac3930 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Wed Oct 16 09:21:30 2013 -0700 drm/i915: Disable GGTT PTEs on GEN6+ suspend Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841 Reported-and-Tested-by: Brad Jackson <bjackson0971@gmail.com> Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Recompute WM when the cursor size changesChris Wilson2014-03-281-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the cursor width is changed, we may need to recompute our WM to prevent untold flickering. We hope that the registers are flushed on the same vblank to prevent underruns... Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Compute WM for current cursor sizeChris Wilson2014-03-281-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we can use different cursor size, we can not hardcode 64 pixels as the cursor width anymore. v2: Apply to 965gm/g4x paths as well Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Remove the enabling of VS_TIMER_DISPATCH bit in MI MODE regAkash Goel2014-03-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch Removes the VS_TIMER_DISPATCH bit enable in MI MODE reg for platforms > Gen6. VS_TIMER_DISPATCH bit enable was earlier required as a part of WA 'WaTimedSingleVertexDispatch', which is now applicable only to platforms < Gen7. v2: Enhancing the scope of the patch to full Gen7 (Chris) v3: Modifying the WA condition to the cover the applicable platforms, and adding the WA name in comments. (Ville) Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Sourab Gupta <sourab.gupta@intel.com> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # ivb, hsw -Chris Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Track the enabled PM interrupts in dev_priv.Deepak S2014-03-283-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we use different rps events for different platforms or due to wa, we might end up needing this logic in a lot of places. Instead of this let's use a variable in dev_priv to track the enabled PM interrupts. v2: Initialize pm_rps_events in intel_irq_init() (Ville). Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Frob the commit message a bit since the English was a bit too garbled ;-) ] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Fix initial pipe underrun state trackingDaniel Vetter2014-03-281-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 5c673b60a9b3b23486f4eda75c72e91d31d26a2b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Mar 7 20:34:46 2014 +0100 drm/i915: Don't enable display error interrupts from the start we don't enable underrun interrupts any more at takeover time. Unfortunately I've forgotten to also adjust the sw-side tracking. Since the code assumes that disabled pipes have underrun reporting enabled set the disable flag only on all pipes which are active at takeover time. Without this underrun reporting wasn't enabled correctly on the first modeset. Note that for fastboot this is another piece of state that needs to be fixed up by enabling the underrung reporting after watermarks have beend fixed up. On ivb/hsw an additional effect of this regression was that also all cpu crc reporting stopped working since the master error interrupt it shared across all pipes and sources. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76150 [danvet: Augment the code comment and polish the commit message a bit, as discussed with Jani.] Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: fix up semaphore_waits_forDaniel Vetter2014-03-281-12/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's an entire pile of issues in here: - Use the main RING_HEAD register, not ACTHD. ACTHD points at the gtt offset of the batch buffer when a batch is executed. Semaphores are always emitted to the main ring, so we always want to look at that. - Mask the obtained HEAD pointer with the actual ring size, which is much smaller. Together with the above issue this resulted us in trying to dereference a pointer way outside of the ring mmio mapping. The resulting invalid access in interrupt context (hangcheck is executed from timers) lead to a full blown kernel panic. The fbcon panic handler then tried to frob our driver harder, resulting in a full machine hang at least on my snb here where I've stumbled over this. - Handle ring wrapping correctly and be a bit more explicit about how many dwords we're scanning. We probably should also scan more than just 4 ... - Space out some of teh computations for readability. This reduces hard-hangs on my snb here. Mika and QA both say that it doesn't completel remove them, but at least for me it's a clear improvement in stability. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Chris Wilson <chris@chris-wilson.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=74100 Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: add locking to fixed panel edid probingDaniel Vetter2014-03-282-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the recent addition of locking checks in commit 62ff94a5492175759546f8bc61383189d6b49122 Author: Daniel Vetter <daniel.vetter@ffwll.ch> AuthorDate: Thu Jan 23 22:18:47 2014 +0100 drm/crtc-helper: remove LOCKING from kerneldoc drm_add_edid_modes started to WARN about the mode_config.mutex not being held in the lvds and dp initialization code. Now since this is init code locking is fairly redudant if it wouldn't be for the drm core registering sysfs files a bit early. And the locking WARNINGs nicely enforce that indeed all access to the mode lists are properly protected. And a full audit shows that only i915 and gma500 touch the modes lists at init time. Hence I've opted to wrap up this entire mode detection sequence for fixed panels with the mode_config mutex for both lvds and edp outputs. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm: Add support for two-ended allocation, v3Lauri Kasanen2014-04-042-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clients like i915 need to segregate cache domains within the GTT which can lead to small amounts of fragmentation. By allocating the uncached buffers from the bottom and the cacheable buffers from the top, we can reduce the amount of wasted space and also optimize allocation of the mappable portion of the GTT to only those buffers that require CPU access through the GTT. For other drivers, allocating small bos from one end and large ones from the other helps improve the quality of fragmentation. Based on drm_mm work by Chris Wilson. v3: Changed to use a TTM placement flag v2: Updated kerneldoc Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Christian König <deathsimple@vodafone.de> Signed-off-by: Lauri Kasanen <cand@gmx.com> Signed-off-by: David Airlie <airlied@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-21 10:08:46 +0200