summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* drm/i915: Update DRIVER_DATE to 20150619Daniel Vetter2015-06-19
| | | | Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Reset request handling for gen8+Mika Kuoppala2015-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order for gen8+ hardware to guarantee that no context switch takes place during engine reset and that current context is properly saved, the driver needs to notify and query hw before commencing with reset. There are gpu hangs where the engine gets so stuck that it never will report to be ready for reset. We could proceed with reset anyway, but with some hangs with skl, the forced gpu reset will result in a system hang. By inspecting the unreadiness for reset seems to correlate with the probable system hang. We will only proceed with reset if all engines report that they are ready for reset. If root cause for system hang is found and can be worked around with another means, we can reconsider if we can reinstate full reset for unreadiness case. v2: -EIO, Recovery, gen8 (Chris, Tomas, Daniel) v3: updated commit msg v4: timeout_ms, simpler error path (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=89959 References: https://bugs.freedesktop.org/show_bug.cgi?id=90854 Testcase: igt/gem_concurrent_blit/prw-blt-overwrite-source-read-rcs-forked Testcase: igt/gem_concurrent_blit/gtt-blt-overwrite-source-read-rcs-forked Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tomas Elf <tomas.elf@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bxt: eDP Panel Power sequencingVandana Kannan2015-06-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changes for BXT - added a IS_BROXTON check to use the macro related to PPS registers for BXT. BXT does not have PP_DIV register. Making changes to handle this. Second set of PPS registers have been defined but will be used when VBT provides a selection between the 2 sets of registers. v2: [Jani] Added 2nd set of PPS registers and the macro Jani's review comments - remove reference in i915_suspend.c - Use BXT PP macro Squashing all PPS related patches into one. v3: Jani's review comments addressed - Use pp_ctl instead of pp - ironlake_get_pp_control() is not required for BXT - correct the use of && in the print statement - drop the shift in the print statement v4: Jani's comments - modify ironlake_get_pp_control() - dont set unlock key for bxt v5: Sonika's comments addressed - check alignment - move pp_ctrl_reg write (after ironlake_get_pp_control()) to !IS_BROXTON case. - check before subtracting 1 for t11_t12 Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use helper to set CRTC state's modeMatt Roper2015-06-17
| | | | | | | | | | | | | | | | | | | | | | We need to call drm_atomic_set_mode_for_crtc() rather than copying the mode in manually. As of commit commit 99cf4a29fa24461bbfe22125967188a18383eb5c Author: Daniel Stone <daniels@collabora.com> Date: Mon May 25 19:11:51 2015 +0100 drm/atomic: Add current-mode blob to CRTC state the helper now also takes care of setting up the mode property blob for us; if we don't use the helper and never setup the mode blob, this will also trigger a failure in drm_atomic_crtc_check() when we have the DRIVER_ATOMIC flag set (i.e., when using the nuclear pageflip support via i915.nuclear_pageflip kernel command line parameter). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Remove more ilk rc6 remnantsDaniel Vetter2015-06-15
| | | | | | | | | | | | | | | Leftover from the big purge commit a561165493e5fec2f74bd3ae0577ed659e44ab7f Author: John Harrison <John.C.Harrison@Intel.com> Date: Thu Mar 5 14:03:03 2015 +0000 drm/i915: Remove ironlake rc6 support Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rob Clark <robdclark@gmail.com> Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
* drm/i915: Limit CHV max cdclkMika Kahola2015-06-15
| | | | | | | | | | | Limit CHV maximum cdclk to 320MHz. v2: Rebase to the latest v3: Clean up of if-else tree Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't set the FBC plane select bits on HSW+Paulo Zanoni2015-06-15
| | | | | | | | | | | | | | | This commit is just to make the intentions explicit: on HSW+ these bits are MBZ, but since we only support plane A and the macro evaluates to zero when plane A is the parameter, we're not fixing any bug. v2: - Remove useless extra blank like (Chris). - Init dpfc_ctl in another place (Chris). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: unify no_fbc_reason message printingPaulo Zanoni2015-06-15
| | | | | | | | | | | | | This commit has two main advantages: simplify intel_fbc_update() and deduplicate the strings. v2: - Rebase due to changes on P1. - set_no_fbc_reason() can now return void (Chris). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add FBC_ROTATION to enum no_fbc_reasonPaulo Zanoni2015-06-15
| | | | | | | | | | | | Because we're currently using FBC_UNSUPPORTED_MODE for two different cases. This commit will also allow us to write the next one without hiding information from the user. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: print FBC compression status on debugfsPaulo Zanoni2015-06-15
| | | | | | | | | | | | | | | | We already had a few bugs in the past where FBC was compressing nothing when it was enabled, which makes the feature quite useless. Add this information to debugfs so the test suites can check for regressions in this piece of the code. Our igt/tests/kms_frontbuffer_tracking already has support for this message. v2: - Remove pointless VLV check (Ville). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Drop the 64k linear scanout alignment on gen2/3Ville Syrjälä2015-06-15
| | | | | | | | | | | | | | | | | | | The docs don't support the 64k linear scanout alignment we impose on gen2/3. And it really makes no sense since we have no DSPSURF register, so the only thing that the hardware will see is the linear offset which will be just pixel aligned anyway. There is one case where 64k comes into the picture, and that's FBC. The start of the line length buffer corresponds to a 64k aligned address of the uncompressed framebuffer. So if the uncompressed fb is not 64k aligned, the first actually used entry in the line length buffer will not be byte 0. There are 32 extra entries in the line length buffer to account for this extra alignment so we shouldn't have to worry about it when mapping the uncompressed fb to the GTT. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Align DSPSURF to 128k on VLV/CHVVille Syrjälä2015-06-15
| | | | | | | | | | | | | | | | | | | | | | VLV/CHV have problems with 4k aligned linear scanout buffers. The VLV docs got updated at some point to say that we need to align them to 128k, just like we do on gen4. So far I've seen the problem manifest when the stride is an odd multiple of 512 bytes, and the surface address meets the following pattern '(addr & 0xf000) == 0x1000' (also == 0x2000 is problematic on VLV). The result is a starcase effect (so some pages get dropped maybe?), with a few pages here and there clearly getting scannout out at the wrong position. I've not actually been able to reproduce this problem on gen4, so it's not clear of the issue is any way related to the 128k restrictions supposedly inherited from gen4. But let's hope the 128k alignment is sufficient to hide it all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Actually respect DSPSURF alignment restrictionsVille Syrjälä2015-06-15
| | | | | | | | | | | | | | | | | Currently intel_gen4_compute_page_offset() simply picks the closest page boundary below the linear offset. That however may not be suitably aligned to satisfy any hardware specific restrictions. So let's make sure the page boundary we choose is properly aligned. Also to play it a bit safer lets split the remaining linear offset into x and y values instead of just x. This should make no difference for most platforms since we convert the x and y offsets back into a linear offset before feeding them to the hardware. HSW+ are different however and use x and y offsets even with linear buffers, so they might have trouble if either the x or y get too big. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Delete duplicate #defines added for DCxChandra Konduru2015-06-15
| | | | | | | | | | | | | | Delete the duplicate #defines introduced by: commit 6b457d31ea0465fcadcf6d5044f5f71398954727 Author: A.Sunil Kamath <sunil.kamath@intel.com> Date: Thu Apr 16 14:22:09 2015 +0530 drm/i915/skl: Implement enable/disable for Display C5 state. Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Restarting the Idleness DRRS in drrs_flushRamalingam C2015-06-15
| | | | | | | | | | | | | | Corrected the documentation on the intel_edp_drrs_flush and intel_edp_drrs_invalidate. And accordingly edp_drrs_flush function is modified to restart the idleness detection after upclocking. v2: Update kerneldoc Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v1) Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'topic/atomic-conversion' into drm-intel-next-queuedDaniel Vetter2015-06-15
|\ | | | | | | | | | | | | | | The i915 atomic conversion is a real beast and it's not getting easier wrangling in a separate branch. I'm might be regretting this, but right after vacation nothing can burst my little bubble here! Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: Only enable cursor if it can be enabled.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cursor should only be enabled if it's visible. This fixes igt/kms_cursor_crc, which may otherwise produce the following warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 3425 at drivers/gpu/drm/i915/intel_display.c:9995 intel_crtc_update_cursor+0x14c/0x4d0 [i915]() Missing switch case (0) in i9xx_update_cursor Modules linked in: i915 CPU: 0 PID: 3425 Comm: kms_cursor_crc Tainted: G W 4.1.0-rc7-patser+ #4079 Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 ffffffffc01aad10 ffff8800b083faa8 ffffffff817f7827 0000000080000001 ffff8800b083faf8 ffff8800b083fae8 ffffffff81084955 ffff8800b083fad8 ffff8800c4931148 0000000001200000 ffff8800c48b0000 0000000000000000 Call Trace: [<ffffffff817f7827>] dump_stack+0x4f/0x7b [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0 [<ffffffff810849d1>] warn_slowpath_fmt+0x41/0x50 [<ffffffffc0139f2c>] intel_crtc_update_cursor+0x14c/0x4d0 [i915] [<ffffffffc01497f4>] __intel_set_mode+0x6c4/0x750 [i915] [<ffffffffc0150143>] intel_crtc_set_config+0x473/0x5c0 [i915] [<ffffffff81467da9>] drm_mode_set_config_internal+0x69/0x120 [<ffffffff8146c1b9>] drm_mode_setcrtc+0x189/0x540 [<ffffffff8145c7e0>] drm_ioctl+0x1a0/0x6a0 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50 [<ffffffff811e9c28>] do_vfs_ioctl+0x2f8/0x530 [<ffffffff810d0f7d>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff812e7746>] ? selinux_file_ioctl+0x56/0x100 [<ffffffff811e9ee1>] SyS_ioctl+0x81/0xa0 [<ffffffff81801617>] system_call_fastpath+0x12/0x6f ---[ end trace abf0f71163290a96 ]--- Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Set hwmode during readout.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | This was introduced after converting hw readout to atomic, so it should have been part of the revert too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929 Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: get rid of intel_plane_restore in intel_crtc_page_flipMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a full atomic call instead. intel_crtc_page_flip will still have to live until async updates are allowed. This doesn't seem to be a regression from the convert to atomic, part 3 patch. During GPU reset it fixes the following warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 752 at drivers/gpu/drm/drm_crtc.c:5337 drm_mode_page_flip_ioctl+0x27b/0x360() Modules linked in: i915 CPU: 0 PID: 752 Comm: Xorg Not tainted 4.1.0-rc7-patser+ #4090 Hardware name: NUC5i7RYB, BIOS RYBDWi35.86A.0246.2015.0309.1355 03/09/2015 ffffffff81c90866 ffff8800d87c3ca8 ffffffff817f7d87 0000000080000001 0000000000000000 ffff8800d87c3ce8 ffffffff81084955 ffff880000000000 ffff8800d87c3dc0 ffff8800d93d1208 0000000000000000 ffff8800b7d1f3e0 Call Trace: [<ffffffff817f7d87>] dump_stack+0x4f/0x7b [<ffffffff81084955>] warn_slowpath_common+0x85/0xc0 [<ffffffff81084a35>] warn_slowpath_null+0x15/0x20 [<ffffffff8146dffb>] drm_mode_page_flip_ioctl+0x27b/0x360 [<ffffffff8145ccb0>] drm_ioctl+0x1a0/0x6a0 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50 [<ffffffff812e5540>] ? avc_has_perm+0x20/0x280 [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50 [<ffffffff811ea0f8>] do_vfs_ioctl+0x2f8/0x530 [<ffffffff811f6001>] ? expand_files+0x261/0x270 [<ffffffff812e7c16>] ? selinux_file_ioctl+0x56/0x100 [<ffffffff811ea3b1>] SyS_ioctl+0x81/0xa0 [<ffffffff81801b97>] system_call_fastpath+0x12/0x6f ---[ end trace 9ce834560085bd64 ]--- Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Do not use atomic modesets in hw readout.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | This should fix fallout caused by making intel_crtc_control and update_dpms atomic, which became a problem after reverting the atomic hw readout patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90929 Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * Revert "drm/i915: Read hw state into an atomic state struct, v2."Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 3bae26eb2991c00670df377cf6c3bc2b0577e82a. Seems it introduces regressions for 3 different reasons, oh boy.. In bug #90868 as I can see the atomic state will be restored on resume without the planes being set up properly. Because plane setup here requires the atomic state, we'll have to settle for committing atomic planes first. In bug #90861 the failure appears to affect mostly DP devices, and happens because reading out the atomic state prevents a modeset on boot, which would require better hw state readout. In bug #90874 it's shown that cdclk should be part of the atomic state, so only performing a single modeset during resume excarbated the issue. It's better to fix those issues first, and then commit this patch, so do that temporarily. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90874 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * Revert "drm/i915: Make intel_display_suspend atomic, v2."Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 490f400db5d886fc28566af69b02f6497f31be4b. We're not ready yet to make it atomic, we calculate some state in advance, but without atomic plane support atomic the hw readout will fail. It's required to revert this commit to revert the atomic hw state readout patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: use calculated state for vblank evasionMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | crtc->active will be gone eventually, and this check should be just as good. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Use atomic state for calculating DVO_2X_MODE on i830.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a small behavioral change because it leaves DVO_2X_MODE set between crtc_disable and crtc_enable. This is probably harmless though and if not should be fixed by calculating 2x mode before enable/disable pll. This is needed because intel_crtc->active will be removed eventually. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Calculate haswell plane workaround, v5.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This needs to be done last after all modesets have been calculated. A modeset first disables all crtc's, so any crtc that undergoes a modeset counts as inactive. If no modeset's done, or > 1 crtc's stay w/a doesn't apply. Apply workaround on the first crtc if 1 crtc stays active. Apply workaround on the second crtc if no crtc was active. Changes since v1: - Use intel_crtc->atomic as a place to put hsw_workaround_pipe. - Make sure quirk only applies to haswell. - Use first loop to iterate over newly enabled crtc's only. This increases readability. Changes since v2: - Move hsw_workaround_pipe back to crtc_state. Changes since v3: - Return errors from haswell_mode_set_planes_workaround. Changes since v4: - Clean up commit message. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Remove use of crtc->config from i915_debugfs.cMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | crtc->config is updated to always contain to the active crtc_state and only differs from crtc_state during crtc_disable. It will eventually be removed, so start with some low hanging fruit. For crtc->active the situation is the same; it will be removed eventually. Instead use crtc->state->active. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Use crtc->hwmode for vblanks, v2.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | intel_crtc->config will be removed eventually, so use crtc->hwmode. drm_atomic_helper_update_legacy_modeset_state updates hwmode, but crtc->active will eventually be gone too. Set dotclock to zero to indicate the crtc is inactive. Changes since v1: - With the hwmode update in drm*update_legacy_modeset_state removed, intel_modeset_update_state has to assign it instead. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: move swap state to the right placeMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a preparation for passing crtc state to the helpers. When converting all users of crtc->config to use the old or new state it's easier to find regressions when swap_state is done first. If crtc->config is swapped at the same place as swap_state bugs will never be found. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Make intel_display_suspend atomic, v2.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calculate all state using a normal transition, but afterwards fudge crtc->state->active back to its old value. This should still allow state restore in setup_hw_state to work properly. Calling intel_set_mode will cause intel_display_set_init_power to be called, make sure init_power gets set again afterwards. Changes since v1: - Fix to compile with v2 of the patch that adds intel_display_suspend. - Add intel_display_set_init_power. - Set return value to int to allow error checking. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Implement intel_crtc_control using atomic state, v4Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Assume the callers lock everything with drm_modeset_lock_all. This change had to be done after converting suspend/resume to use atomic_state so the atomic state is preserved, otherwise all transitional state is erased. Now all callers of .crtc_enable and .crtc_disable go through atomic modeset! :-D Changes since v1: - Only check for crtc_state->active in valleyview_modeset_global_pipes. - Only check for crtc_state->active in modeset_update_crtc_power_domains. Changes since v2: - Rework on top of the changed patch order. Changes since v3: - Rename intel_crtc_toggle in description to *_control - Change return value to int. - Do not add plane state, should be done implicitly already. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Read hw state into an atomic state struct, v2.Ander Conselvan de Oliveira2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To make this work we load the new hardware state into the atomic_state, then swap it with the sw state. This lets us change the force restore path in setup_hw_state() to use a single call to intel_mode_set() to restore all the previous state. As a nice bonus this kills off encoder->new_encoder, connector->new_enabled and crtc->new_enabled. They were used only to restore the state after a modeset. Changes since v1: - Make sure all possible planes are added with their crtc set, so they will be turned off on first modeset. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Move cdclk and pll setup to intel_modeset_compute_config(), v2.Ander Conselvan de Oliveira2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It makes more sense there, since these are computation steps that can fail. Changes since v1: - Rename __intel_set_mode_checks to intel_modeset_checks (Matt Roper) - Move intel_modeset_checks to before check_planes, so it won't have to be moved later. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Swap planes on each crtc separately, v2.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repeated calls to begin_crtc_commit can cause warnings like this: [ 169.127746] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:616 [ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip [ 169.127840] 3 locks held by kms_flip/1947: [ 169.127843] #0: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff814774bc>] __drm_modeset_lock_all+0x9c/0x130 [ 169.127860] #1: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffff814774cd>] __drm_modeset_lock_all+0xad/0x130 [ 169.127870] #2: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffff81477178>] drm_modeset_lock+0x38/0x110 [ 169.127879] irq event stamp: 665690 [ 169.127882] hardirqs last enabled at (665689): [<ffffffff817ffdb5>] _raw_spin_unlock_irqrestore+0x55/0x70 [ 169.127889] hardirqs last disabled at (665690): [<ffffffffc0197a23>] intel_pipe_update_start+0x113/0x5c0 [i915] [ 169.127936] softirqs last enabled at (665470): [<ffffffff8108a766>] __do_softirq+0x236/0x650 [ 169.127942] softirqs last disabled at (665465): [<ffffffff8108ae75>] irq_exit+0xc5/0xd0 [ 169.127951] CPU: 1 PID: 1947 Comm: kms_flip Not tainted 4.1.0-rc4-patser+ #4039 [ 169.127954] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 [ 169.127957] ffff8800c49036f0 ffff8800cde5fa28 ffffffff817f6907 0000000080000001 [ 169.127964] 0000000000000000 ffff8800cde5fa58 ffffffff810aebed 0000000000000046 [ 169.127970] ffffffff81c5d518 0000000000000268 0000000000000000 ffff8800cde5fa88 [ 169.127981] Call Trace: [ 169.127992] [<ffffffff817f6907>] dump_stack+0x4f/0x7b [ 169.128001] [<ffffffff810aebed>] ___might_sleep+0x16d/0x270 [ 169.128008] [<ffffffff810aed38>] __might_sleep+0x48/0x90 [ 169.128017] [<ffffffff817fc359>] mutex_lock_nested+0x29/0x410 [ 169.128073] [<ffffffffc01635f0>] ? vgpu_write64+0x220/0x220 [i915] [ 169.128138] [<ffffffffc017fddf>] ? ironlake_update_primary_plane+0x2ff/0x410 [i915] [ 169.128198] [<ffffffffc0190e75>] intel_frontbuffer_flush+0x25/0x70 [i915] [ 169.128253] [<ffffffffc01831ac>] intel_finish_crtc_commit+0x4c/0x180 [i915] [ 169.128279] [<ffffffffc00784ac>] drm_atomic_helper_commit_planes+0x12c/0x240 [drm_kms_helper] [ 169.128338] [<ffffffffc0184264>] __intel_set_mode+0x684/0x830 [i915] [ 169.128378] [<ffffffffc018a84a>] intel_crtc_set_config+0x49a/0x620 [i915] [ 169.128385] [<ffffffff817fdd39>] ? mutex_unlock+0x9/0x10 [ 169.128391] [<ffffffff81467b69>] drm_mode_set_config_internal+0x69/0x120 [ 169.128398] [<ffffffff8119b547>] ? might_fault+0x57/0xb0 [ 169.128403] [<ffffffff8146bf93>] drm_mode_setcrtc+0x253/0x620 [ 169.128409] [<ffffffff8145c600>] drm_ioctl+0x1a0/0x6a0 [ 169.128415] [<ffffffff810b3b41>] ? get_parent_ip+0x11/0x50 [ 169.128424] [<ffffffff811e9ab8>] do_vfs_ioctl+0x2f8/0x530 [ 169.128429] [<ffffffff810d0fcd>] ? trace_hardirqs_on+0xd/0x10 [ 169.128435] [<ffffffff812e7676>] ? selinux_file_ioctl+0x56/0x100 [ 169.128439] [<ffffffff811e9d71>] SyS_ioctl+0x81/0xa0 [ 169.128445] [<ffffffff81800697>] system_call_fastpath+0x12/0x6f Solve it by using the newly introduced drm_atomic_helper_commit_planes_on_crtc. The problem here was that the drm_atomic_helper_commit_planes() helper we were using was basically designed to do begin_crtc_commit(crtc #1) begin_crtc_commit(crtc #2) ... commit all planes finish_crtc_commit(crtc #1) finish_crtc_commit(crtc #2) The problem here is that since our hardware relies on vblank evasion, our CRTC 'begin' function waits until we're out of the danger zone in which register writes might wind up straddling the vblank, then disables interrupts; our 'finish' function re-enables interrupts after the registers have been written. The expectation is that the operations between 'begin' and 'end' must be performed without sleeping (since interrupts are disabled) and should happen as quickly as possible. By clumping all of the 'begin' calls together, we introducing a couple problems: * Subsequent 'begin' invocations might sleep (which is illegal) * The first 'begin' ensured that we were far enough from the vblank that we could write our registers safely and ensure they all fell within the same frame. Adding extra delay waiting for subsequent CRTC's wasn't accounted for and could put us back into the 'danger zone' for CRTC #1. This commit solves the problem by using a new helper that allows an order of operations like: for each crtc { begin_crtc_commit(crtc) // sleep (maybe), then disable interrupts commit planes for this specific CRTC end_crtc_commit(crtc) // reenable interrupts } so that sleeps will only be performed while interrupts are enabled and we can be sure that registers for a CRTC will be written immediately once we know we're in the safe zone. The crtc->config->base.crtc update may seem unrelated, but the helper will use it to obtain the crtc for the state. Without the update it will dereference NULL and crash. Changes since v1: - Use Matt Roper's commit message. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Use drm_atomic_helper_swap_state in intel_atomic_commit.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | And update crtc->config to point to the new state. There is no point in swapping only part of the state when the rest of the state should be untouched. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Use global atomic state for staged pll, config, v3.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we can subclass drm_atomic_state we can also use it to keep track of all the pll settings. atomic_state is a better place to hold all shared state than keeping pll->new_config everywhere. Changes since v1: - Assert connection_mutex is held. Changes since v2: - Fix swapped arguments to kzalloc for intel_atomic_state_alloc. (Jani Nikula) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Zap call to drm_plane_helper_disable, v2.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | The primary plane can still be configured when crtc is off, furthermore this is also a noop now that affected planes are added on modesets. Changes since v1: - Move commit so no frontbuffer_bits warnings are generated. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Support modeset across multiple pipesAnder Conselvan de Oliveira2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | Compute new pipe_configs for all crtcs in the atomic state. The commit part of the mode set (__intel_set_mode()) is already enabled to support multiple pipes, the only thing missing was calculating a new pipe_config for every crtc. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: calculate primary visibility changes instead of calling from ↵Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | set_config This should be much cleaner, with the same effects. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: do not wait for vblank when crtc is offMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | This can happen when turning off a sprite plane. Because the crtc state is not yet always swapped correctly and transitional helpers are used the crtc state cannot be relied on. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: update plane state during initMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | Atomic planes updates rely on having a accurate plane_mask. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Make sure all planes and connectors are added on modeset.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | Add missing calls to drm_atomic_add_affected_*. This is needed to convert to atomic planes. When converting to atomic all planes are needed on modeset. For good measure make sure all connectors are added too. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Use crtc_state->active instead of crtc_state->enableMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | crtc_state->enable means a crtc is configured, but it may be turned off for dpms. Until the commit "use intel_crtc_control everywhere" crtc_state->active was not updated on crtc off, but now crtc_state->active should be used for tracking whether a crtc is scanning out or not. A few commits from now dpms will be handled by calling intel_set_mode with a different value for crtc_state->active, which causes a crtc to turn on or off. At this point crtc->active should mirror crtc_state->active, so some paranoia from the crtc_disable functions can be removed. intel_set_mode_setup_plls still checks for ->enable, because all resources that are needed have to be calculated, else dpms changes may not succeed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Set mode_changed for audio in intel_modeset_pipe_config()Ander Conselvan de Oliveira2015-06-12
| | | | | | | | | | | | | | | | | | | | | | A follow up patch will make intel_modeset_compute_config() deal with multiple crtcs, so move crtc specific stuff into the lower level crtc specific function. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Make __intel_set_mode() take only atomic state as argumentAnder Conselvan de Oliveira2015-06-12
| | | | | | | | | | | | | | | | | | | | With the use of drm_atomic_helper_update_legacy_modeset_state the last user of modeset_crtc is removed from this function. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Use drm_atomic_helper_update_legacy_modeset_state, v2.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | Now that the helper is exported there's no need to duplicate this code any more. Changes since v1: - move intel_modeset_update_staged_output_state call to the right place. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: use intel_crtc_control everywhere, v3.Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having a single path for everything makes it a lot easier to keep crtc_state->active in sync with intel_crtc->active. A crtc cannot be changed to active when not enabled, because it means no mode is set and no connectors are connected. This should also make intel_crtc->active match crtc_state->active. Changes since v1: - Reworded commit message, there's no intel_crtc_toggle. Changes since v2: - Change some callers of intel_crtc_control to intel_display_suspend. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: add intel_display_suspend, v2Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | This is a function used to disable all crtc's. This makes it clearer to distinguish between when mode needs to be preserved and when it can be trashed. Changes since v1: - Copy power changes from intel_crtc_control. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: get rid of intel_crtc_disable and related code, v3Maarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that the dpll updates are (mostly) atomic, the .off() code is a noop, and intel_crtc_disable does mostly the same as intel_modeset_update_state. Move all logic for connectors_active and setting dpms to that function. Changes since v1: - Move drm_atomic_helper_swap_state up. Changes since v2: - Split out intel_put_shared_dpll removal. Changes since v3: - Rebase on top of latest drm-intel. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: get rid of put_shared_dpllMaarten Lankhorst2015-06-12
| | | | | | | | | | | | | | | | | | | | | | | | | | Now that the pll updates are staged the put_shared_dpll function consists only of checks that are done in check_shared_dpll_state after a modeset too. The changes to pll->config are overwritten by intel_shared_dpll_commit, so this entire function is a noop. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Report to userspace if we have a (presumed) working GPU resetChris Wilson2015-06-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In igt, we want to test handling of GPU hangs, both for recovery purposes and for reporting. However, we don't want to inject a genuine GPU hang onto a machine that cannot recover and so be permenantly wedged. Rather than embed heuristics into igt, have the kernel report exactly when it expects the GPU reset to work. This can also be usefully extended in future to indicate different levels of fine-grained resets. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tim Gore <tim.gore@intel.com> Cc: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.25.1) at 2026-04-23 11:13:48 +0000