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>
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>
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>
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>
Use the helpers introduced by the commit below to properly initialize
the duplicated states.
commit f5e7840b0c
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Ander Conselvan de Oliveira