summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_atomic.c
AgeCommit message (Collapse)Author
2015-11-02drm/i915: Make wait_for_flips interruptible.Maarten Lankhorst
Move it from intel_crtc_atomic_commit to prepare_plane_fb. Waiting is done before committing, otherwise it's too late to undo the changes. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2015-10-21drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic checkMatt Roper
Determine whether we need to apply this workaround at atomic check time and just set a flag that will be used by the main watermark update routine. Moving this workaround into the atomic framework reduces ilk_update_sprite_wm() to just a standard watermark update, so drop it completely and just ensure that ilk_update_wm() is called whenever a sprite plane is updated in a way that would affect watermarks. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: Paulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60367/
2015-10-13drm/i915: revert a few more watermark commitsPaulo Zanoni
This is a squash of the following commits: Revert "drm/i915: Drop intel_update_sprite_watermarks" This reverts commit 47c99438b52d12df50e182583634a4cfede3c920. Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check" This reverts commit 7809e5ae35b9d8d0710f0874b2e3f10be144e38b. Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)" This reverts commit 3a05f5e2e78eab7ffe816abb59b6769e331a1957. With these reverts, SKL finally stops failing every single FBC test with FIFO underrun error messages. After some brief testing, it also seems that this commit prevents the machine from completely freezing when we run igt/kms_fbc_crc (see fd.o #92355). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-30drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic checkMatt Roper
Determine whether we need to apply this workaround at atomic check time and just set a flag that will be used by the main watermark update routine. Moving this workaround into the atomic framework reduces ilk_update_sprite_wm() to just a standard watermark update, so drop it completely and just ensure that ilk_update_wm() is called whenever a sprite plane is updated in a way that would affect watermarks. 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>
2015-09-14drm/i915: Make updating pipe without modeset atomic.Maarten Lankhorst
Instead of doing a hack during primary plane commit the state is updated during atomic evasion. It handles differences in pipe size and the panel fitter. This is continuing on top of Daniel's work to make faster modesets atomic, and not yet enabled by default. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: - simplify/future-proof if ladder that Jesse spotted - resolve conflict in pipe_config_check and don't spuriously move the code.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-10drm/i915: Use crtc->state for duplication.Maarten Lankhorst
In async mode crtc->config can be updated after the locks are released, resulting in the wrong state being duplicated. Note that this also removes a spurious assignment of crtc_state->crtc introduced in commit f0c60574eb1216b0904c0d696c64d5096d6e4913 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Tue Apr 21 17:12:58 2015 +0300 drm/i915: Call drm helpers when duplicating crtc and plane states Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-08-14drm/i915: remove excessive scaler debugging messagesJani Nikula
There's so much scaler debugging messages that it makes other debugging hard. Remove them. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Use full atomic modeset.Maarten Lankhorst
Huzzah! \o/ Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Rework plane readout.Maarten Lankhorst
All non-primary planes get disabled during hw readout, this reduces complexity and means not having to do some plane visibility checks during the first commit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Do not update pfit state when toggling crtc enabled.Maarten Lankhorst
There's not much point for calculating the changes for the old state. Instead just disable all scalers when disabling. It's probably good enough to just disable the crtc_scaler, but just in case there's a bug disable all scalers. This means intel_atomic_setup_scalers is only called in the crtc check function now, so all the transitional code can be removed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-06drm/i915: Don't dereference NULL plane while setting up scalersMatt Roper
intel_atomic_setup_scalers() dereferences 'plane' before the plane has been assigned. The plane ID assignment doing this dereference is only needed for debugging messages later in the function, so just move the assignment farther down the function to a point where plane will no longer be NULL. This was introduced in: commit 133b0d128be39e308ccd3b3d765c31ebdbf5380e Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Mon Jun 15 12:33:39 2015 +0200 drm/i915: Clean up intel_atomic_setup_scalers slightly. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Reported-by: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-22drm/i915: Make cdclk part of the atomic state.Maarten Lankhorst
The skylake scalers depend on the cdclk freq, but that frequency can change during a modeset. So when a modeset happens calculate the new cdclk in the atomic state. With the transitional helpers gone the cached value can be used in the scaler, and committed after all crtc's are disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90874 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-22drm/i915: Handle disabling planes better, v2.Maarten Lankhorst
Read out the initial state, and add a quirk to force add all planes to crtc_state->plane_mask during initial commit. This will disable all planes during the initial modeset. The initial plane quirk is temporary, and will go away when hardware readout is fully atomic, and the watermark updates in intel_sprite.c are removed. Changes since v1: - Unset state->visible on !primary planes. - Do not rely on the plane->crtc pointer in intel_atomic_plane, instead assume planes are invisible until modeset. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-22drm/i915: move detaching scalers to begin_crtc_commit, v2.Maarten Lankhorst
This is probably intended to be be done during vblank evasion. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-22drm/i915: Move scaler setup to check crtc function, v2.Maarten Lankhorst
The scaler setup may add planes, but since they're unchanged we only have to wait for primary flips. Also set planes_changed to indicate at least 1 plane is modified. Changes since v1: - Instead of removing planes, do minimal validation needed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-22drm/i915: Add a simple atomic crtc check function, v2.Maarten Lankhorst
Move the check for encoder cloning here. Changes since v1: - Remove was/is crtc_disabled. (mattrope) - Rename function to intel_crtc_atomic_check. (mattrope) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-22drm/i915: Clean up intel_atomic_setup_scalers slightly.Maarten Lankhorst
Get rid of a whole lot of ternary operators and assign the index in scaler_id, instead of the id. They're the same thing. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-12Revert "drm/i915: Read hw state into an atomic state struct, v2."Maarten Lankhorst
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>
2015-06-12drm/i915: Read hw state into an atomic state struct, v2.Ander Conselvan de Oliveira
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>
2015-06-12drm/i915: Swap planes on each crtc separately, v2.Maarten Lankhorst
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>
2015-06-12drm/i915: Use drm_atomic_helper_swap_state in intel_atomic_commit.Maarten Lankhorst
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>
2015-06-12drm/i915: Use global atomic state for staged pll, config, v3.Maarten Lankhorst
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>
2015-05-08drm/i915: Call drm helpers when duplicating crtc and plane statesAnder Conselvan de Oliveira
Use the helpers introduced by the commit below to properly initialize the duplicated states. commit f5e7840b0c4368f8cdbb055188c2a0eef50c3052 Author: Thierry Reding <treding@nvidia.com> Date: Wed Jan 28 14:54:32 2015 +0100 drm/atomic: Add helpers for state-subclassing drivers Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-08drm/i915: skylake primary plane scaling using shared scalersChandra Konduru
This patch enables skylake primary plane scaling using shared scalers atomic desgin. v2: -use single copy of scaler limits (Matt) v3: -move detach_scalers to crtc commit path (Matt) -use values in plane_state->src as regular integers (me) v4: -changes to align with updated scaler structures (Matt, me) -keep plane src rect in 16.16 format (Matt, Daniel) v5: -Rebased on top of 90/270 rotation changes (me) -Fixed an issue introduced by 90/270 changes where plane programming is using drm_plane->state rect instead of intel_plane->state rect. This change also required for scaling to work properly. (me) -With 90/270, updated limits to cover both portrait and landscape usages (me) -Refactored skylake_update_primary_plane to reduce its size (Daniel) Added helper functions for refactoring are comprehended enough to be used for skylake_update_plane (for sprite) too. One stop towards having single function for all planes. v6: -Added fixme note when checking plane_state->src width in update_plane (Daniel) -Release lock when failing to colorkey request with active scaler (Daniel) Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Reviewed-by: matthew.d.roper@intel.com Reviewed-by: sonika.jindal@intel.com (v5) Testcase: igt/kms_plane_scaling Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-13drm/i915: copy staged scaler state from drm state to crtc->config.Chandra Konduru
This is required for commit to perform as per staged assignment of scalers until atomic crtc commit function is available. As a place holder doing this copy from intel_atomic_commit for scaling to operate correctly. Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-13drm/i915: Ensure setting up scalers into staged crtc_stateChandra Konduru
From intel_atomic_check, call intel_atomic_setup_scalers() to assign scalers based on staged scaling requests. Fail the transaction if setup returns error. Setting up of scalers should be moved to atomic crtc check once atomic crtc is ready. v2: -updated parameter passing to setup_scalers (me) Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-13drm/i915: setup scalers for crtc_compute_configChandra Konduru
Added intel_atomic_setup_scalers to setup scalers based on staged scaling requests from a crtc and its planes. If staged requests are supportable, this function assigns scalers to requested planes and crtc. Note that the scaler assignement itself is staged into crtc_state and respective plane_states for later commit after all checks have been done. overall high level flow: - scaler requests are staged into crtc_state by planes/crtc - check whether staged scaling requests can be supported - add planes using scalers that aren't in current transaction - assign scalers to requested users - as part of plane commit, scalers will be committed (i.e., either attached or detached) to respective planes in hw - as part of crtc_commit, scaler will be either attached or detached to crtc in hw crtc_compute_config calls intel_atomic_setup_scalers() to start scaler assignments as per scaler state in crtc config. This call should be moved to atomic crtc once it is available. v2: -removed a log message (me) -changed input parameter to crtc_state (me) v3: -remove assigning plane_state returned by drm_atomic_get_plane_state (Matt) -fail if there is an error from drm_atomic_get_plane_state (Matt) v4: -changes to align with updated scaler structure (Matt, me) v5: -added addtional checks before enabling HQ mode (me) -added comments to enable HQ mode (Matt) Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-10drm/i915: Clear crtc atomic flags at beginning of transactionMatt Roper
Once we have full atomic modeset, these kind of flags should be in a real intel_crtc_state that's tracked properly. In the meantime, make sure we clear out any old flags at the beginning of a transaction so that we don't wind up seeing leftover flags from old transactions that were checked, but never went to the commit step. At the moment, a failed check or prepare could leave stale flags behind that interfere with the next atomic transaction. v2: Just do a memset; the series this patch was originally part of placed additional fields into the structure that shouldn't be cleared, but that's no longer the case. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-17drm/i915: Set crtc backpointer when duplicating crtc stateAnder Conselvan de Oliveira
In the path were there is no state to duplicate, the allocated crtc state wouldn't have the crtc backpointer initialized. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-02-24drm/atomic-helper: Rename commmit_post/pre_planesDaniel Vetter
These names only make sense because of backwards compatability with the order used by the crtc helper library. There's not really any real requirement in the ordering here. So rename them to something more descriptive and update the kerneldoc a bit. Motivated in a discussion with Laurent about how to restore plane state for dpms for drivers with runtime pm. v2: Squash in fixup from Stephen Rothwell to fix a conflict with tegra. Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Acked-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-01-27drm/i915: Add crtc state duplication/destruction functionsMatt Roper
The atomic helpers need these to prepare a new state object when starting a new atomic operation. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Add atomic_get_property entrypoint for connectors (v2)Matt Roper
Even though we only support atomic plane updates at the moment, we still need to add an .atomic_get_property() entrypoint for connectors before we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that bit gets set, the DRM core will start adding atomic connector properties (in addition to the plane properties we care about at the moment), so we need to be able to handle the new way the DRM core will interact with us. For simplicity, we just lookup driver-specific connector properties in the usual shadow array maintained by the core. Once we get real atomic modeset support for crtc's and planes, this code should be re-written to pull the data out of crtc/connector state structures. v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Add main atomic entrypoints (v2)Matt Roper
Add the top-level atomic entrypoints for check/commit. These won't get called yet; we still need to either enable the atomic ioctl or switch to using the non-transitional atomic helpers for legacy operations. v2: - Use plane->pipe rather than plane->possible_crtcs while ensuring that only a single CRTC is in use. Either way will work fine since i915 drm_plane's are always tied to a single CRTC, but plane->pipe is slightly more intuitive. (Ander) - Simplify crtc/connector checking logic. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>