- 12 Jun, 2015 40 commits
-
-
Maarten Lankhorst authored
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=90874Signed-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>
-
Maarten Lankhorst authored
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=90861Signed-off-by:
-
Maarten Lankhorst authored
crtc->active will be gone eventually, and this check should be just as good. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Ander Conselvan de Oliveira authored
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:
-
Ander Conselvan de Oliveira authored
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:
-
Maarten Lankhorst authored
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 authored
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 authored
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:
-
Maarten Lankhorst authored
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:
-
Ander Conselvan de Oliveira authored
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:
-
Maarten Lankhorst authored
This should be much cleaner, with the same effects. Signed-off-by:
-
Maarten Lankhorst authored
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 authored
Atomic planes updates rely on having a accurate plane_mask. Signed-off-by:
-
Maarten Lankhorst authored
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 authored
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:
-
Ander Conselvan de Oliveira authored
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 authored
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:
-
Maarten Lankhorst authored
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 authored
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 authored
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 authored
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 authored
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:
-
Imre Deak authored
According to bspec the DDI PHY vswing scale value is "don't care" in case the scale enable bit [27] is clear. But this doesn't seem to be correct. The scale value seems to also matter if the scale mode bit [26] is set. So both bit 26 and 27 depend on the value. Setting the scale value to 0 while either bit is set results in a failed modeset on HDMI (sink reports no signal). After reset the scale value is 0x98, but according to the spec we have to program it to 0x9a. So for consistency program it always to 0x9a regardless of the scale enable bit. Signed-off-by:
Imre Deak <imre.deak@intel.com> Tested-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Damien Lespiau authored
Ville's and Mika's cdclk series was in flight at the same time as the SKL S3 patches so we were missing that update. intel_update_max_cdclk() and intel_update_cdclk() had to be moved up a bit to avoid forward declarations. Signed-off-by:
-
Damien Lespiau authored
intel_update_cdclk() will already display the boot CDCLK for DDI platforms, no need to repeat there. Signed-off-by:
-
Damien Lespiau authored
We can operate with DPLL0 off with CDCLK backed by the 24Mhz reference clock, and that's a supported configuration. Don't warn when notice DPLL0 is off then. We still have a separate warn at boot if cdclk is disabled (because we don't currently try to handle the case (that shouldn't happen on SKL as far as I know) where we boot with display not initialized. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Ville Syrjälä authored
Add support for changing cdclk frequency during runtime on BDW. Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk, so take that into account when computing the max pixel rate. v2: Grab rps.hw_lock around sandybridge_pcode_write() v3: Rebase due to power well vs. .global_resources() reordering v4: Rebased to the latest v5: Rebased to the latest v6: Patch order shuffle so that Broadwell CD clock change is applied before the patch for Haswell CD clock change v7: Fix for patch style problems Signed-off-by:Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Ville Syrjälä authored
We need to tell BDW ULT and ULX apart. v2: Rebased to the latest v3: Rebased to the latest v4: Fix for patch style problems Signed-off-by:
-
