When a new pipe_config is calculated, the fields related to shared dplls
are reset, under the assumption that they will be recalculated as part
of the modeset, which is true with the current state of the code.
As we convert to atomic, however, it will be possible to calculate a new
pipe_config and skip the modeset. In that case, after the state swap we
still want the shared dplls to be preserved.
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>
Replace the drivers own logic for computing mode_changed, active_changed
and planes_changed flags with the check_modeset() atomic helper. Since
that function needs to compare the crtc's new mode with the current,
this patch also moves the set up of crtc_state->mode earlier in the call
chain.
Note that for the call to check_plane() to work properly, we need to
check new plane state against new crtc state. But since we still use the
plane update helper, which doesn't have a full atomic state, we need to
hack around that in intel_plane_atomic_check().
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>
In a follow up patch the function that computes mode changes will be
replaced with the one from the atomic helpers. To preserve the behavior
of legacy modeset forcing DPMS on, that function will need to detect a
change in the active state of the crtc, so that has to be kept up to
date.
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 is no longer necessary since we only update the staged config on
successfull modeset. The new configuration is stored in an atomic state
struct which is freed in case of failure.
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>
The logic that stages the state before the modeset was still updating
first the old staged config and then populating the atomic state based
on that. Change this to use only the atomic state.
Note that now the staged config is updated in the function
intel_modeset_commit_output_state(). This is done so that the modeset
check and the force restore path in the hw state read out code continue
to work.
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>
Call intel_set_mode() uncondionally from intel_crtc_set_config(), since
the former function is now properly wired to ignore all the modesets if
the mode_changed and active_changed flags are false in crtc_state.
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>
Add the primary plane state to the legacy modeset atomic state and use
it when configuring the primary plane in __intel_set_mode(). This is a
first step towards merging the flip path in intel_crtc_set_config() and
__intel_set_mode().
v2: Set crtc to NULL if fb is NULL. (Maarten)
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>
The modeset code is now properly divided in two phases, so that it only
changes hardware state if it succeeds, so there's no ill-effect that
needs to be undone on failure anymore.
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>
The remaining parts of the failure path could only be reached if the
allocation of crtc_state_copy would fail. In that case, there is nothing
to undo, so just get rid of the label for error handling and return an
error code immediately.
We also always allocate a pipe_config, even if the pipe is being
disabled, so the remaining part of what was the error/done case can be
simplified a little too.
v2: Ignore return value from drm_plane_helper_update(). (Ander)
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>
The first function calls done in that function can still cause changes
to the atomic state and may fail. This should eventually be part of our
atomic check function, while the rest of the code in __intel_set_mode()
is the commit hook. So this makes the legacy mode set more atomic-y.
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>
Set the mode_changed field on the crtc_states and use that instead.
Note that even though this patch doesn't completely replace the logic in
intel_modeset_affected_pipes(), that logic was never fully used to its
full extent. Since the commit mentioned below, modeset_pipes and
prepare_pipes would only contain at most the pipe for which the set_crtc
ioctl was called. We can grow back that logic when the time comes.
commit b6c5164d7b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 12 18:48:43 2013 +0200
drm/i915: Fixup Oops in the pipe config computation
v2: Don't set mode_changed unconditionally for modeset_crtc. (Ander)
Check for needs_modeset() before trying to allocate a PLL. (Ander)
Only call .crtc_enable() for pipes that were disabled. (Maarten)
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>
With the current implementation of intel_modeset_affected_pipes(), if a
pipe will be enabled then it is in modeset_pipes. We'll remove that mask
in a follow up patch, but want to preserve this behavior, so just make
that explicit.
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>
The code in intel_modeset_pipe_config() still needs changes before it
can calculate more than just one pipe_config, and pretending it can will
only make those changes more difficult.
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>
The function intel_modeset_compute_config() needs to eventually become
part of atomic_check(). At that point, all the affected crtcs need to be
in the atomic state with the new values. So move the logic of adding
crtc states out of that function.
v2: Set crtc_state->enable in all cases. (Ander)
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 was an optimization from way back before we had primary plane
support to be able to disable the primary plane. But with primary
plane support userspace can tell the kernel this directly, so there's
no big need for this any more. And it's getting in the way of the
atomic conversion.
If need be we can resurrect this later on properly again.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Explain why removing this is ok.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Do a POSTING_READ() between the DBUF_CTL register write and the
udelay() to make sure we really wait after the register write has
happened.
Spotted while reviewing Damien's SKL cdclk patch which had the
POSTING_READ()s.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@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>
drm-intel-next-2015-04-23:
- dither support for ns2501 dvo (Thomas Richter)
- some polish for the gtt code and fixes to finally enable the cmd parser on hsw
- first pile of bxt stage 1 enabling (too many different people to list ...)
- more psr fixes from Rodrigo
- skl rotation support from Chandra
- more atomic work from Ander and Matt
- pile of cleanups and micro-ops for execlist from Chris
drm-intel-next-2015-04-10:
- cdclk handling cleanup and fixes from Ville
- more prep patches for olr removal from John Harrison
- gmbus pin naming rework from Jani (prep for bxt)
- remove ->new_config from Ander (more atomic conversion work)
- rps (boost) tuning and unification with byt/bsw from Chris
- cmd parser batch bool tuning from Chris
- gen8 dynamic pte allocation (Michel Thierry, based on work from Ben Widawsky)
- execlist tuning (not yet all of it) from Chris
- add drm_plane_from_index (Chandra)
- various small things all over
* tag 'drm-intel-next-2015-04-23-fixed' of git://anongit.freedesktop.org/drm-intel: (204 commits)
drm/i915/gtt: Allocate va range only if vma is not bound
drm/i915: Enable cmd parser to do secure batch promotion for aliasing ppgtt
drm/i915: fix intel_prepare_ddi
drm/i915: factor out ddi_get_encoder_port
drm/i915/hdmi: check port in ibx_infoframe_enabled
drm/i915/hdmi: fix vlv infoframe port check
drm/i915: Silence compiler warning in dvo
drm/i915: Update DRIVER_DATE to 20150423
drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010
rm/i915: Move i915_get_ggtt_vma_pages into ggtt_bind_vma
drm/i915: Don't try to outsmart gcc in i915_gem_gtt.c
drm/i915: Unduplicate i915_ggtt_unbind/bind_vma
drm/i915: Move ppgtt_bind/unbind around
drm/i915: move i915_gem_restore_gtt_mappings around
drm/i915: Fix up the vma aliasing ppgtt binding
drm/i915: Remove misleading comment around bind_to_vm
drm/i915: Don't use atomics for pg_dirty_rings
drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt
drm/i915/skl: Support Y tiling in MMIO flips
drm/i915: Fixup kerneldoc for struct intel_context
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
Since the introduction of BIOS fb preservation, circa 3.17, we began
encountering a failure during boot when trying to use force-detect
before GEM was initialised. That bug is from
commit 7fad798e16
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jul 4 17:51:47 2012 +0200
drm/i915: ensure the force pipe A quirk is actually followed
but investigation of the affected machine revealed that it was using a
PIPE-A quirk even though it was a 945GSE and the quirk is only supposed
to be used to workaround a hardware issue on 830/845. That quirk was
added for this HP Mini in
commit 6b93afc564a5e74b0eaaa46c95f557449951b3b9
Author: Bryce Harrington <bryce@bryceharrington.org>
Date: Wed May 27 03:40:52 2009 -0700
add pipe a force quirk for Dell mini
in order to workaround an issue with the BIOS behaving strangely during
lid-close. Since then we have a much larger hammer to thwart the BIOS
after opening the lid and the PIPE-A quirk is no longer required.
Reported-and-tested-by: Apostolos B. <barz621@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=21960
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=87521
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The checks for PLL enabled state on CPU ports are valid only on GMCH
platforms but atm we'd also call them on non-PCH-split/non-GMCH
platforms like BXT, triggering false warnings. Until the proper check is
implented for these platforms simply disable the check.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Assign PLL for pipe (dependent on port attached to the pipe)
v2:
- fix incorrect encoder vs. new_encoder check for crtc (imre)
v3:
- warn and return error if no encoder is attached (imre)
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v2)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Don't move intel_ddi_get_crtc_new_encoder around.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since universal planes the primary plane might not be around, and it's
kinda silly to restrict the pipe bpp to the primary plane if we might
end up displaying a 10bpc video overlay. And with atomic we might very
well enable a pipe without a primary plane. So just use the platform
max as a starting point and then restrict appropriately.
Of course this is all still a bit moot as long as we artificially
compress everything to max 8bpc because we don't use the hi-bpc gamma
tables.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add CDCLK specific display clock initialization sequence as per BSpec.
Note that the CDCLK initialization/uninitialization are done at their
current place only for simplicity, in a future patch - when more of the
runtime PM features will be enabled - these will be moved to power
well#1 and modeset encoder enabling/disabling hooks respectively. This
also means that atm dynamic power gating power well #1 is effectively
disabled.
The call to uninitialize CDCLK during system/runtime suspend will be
added later in this patchset.
v1: Added function definitions in header files
v2: Imre's review comments addressed
- Moved CDCLK related definitions to i915_reg.h
- Removed defintions for CDCLK frequency
- Split uninit_cdclk() by adding a phy_uninit function
- Calculate freq and decimal based on input frequency
- Program SSA precharge based on input frequency
- Use wait_for 1ms instead 200us udelay for DE PLL locking
- Removed initial value for divider, freq, decimal, ratio.
- Replaced polling loops with wait_for
- Parameterized latency optim setting
- Fix the parts where DE PLL has to be disabled.
- Call CDCLK selection from mode set
v3: (imre)
- add note about the plan to move the cdclk/phy init to a better place
- take rps.hw_lock around pcode access
- move DE PLL register macros here from another patch since they are
used here first
- add BXT_ prefix to CDCLK flags
- add missing masking when programming CDCLK_FREQ_DECIMAL
v4: (ville)
- split the CDCLK/PHY parts into two patches, update commit message
accordingly
- s/DISPLAY_PCU_CONTROL/HSW_PCODE_DE_WRITE_FREQ_REQ/
- simplify BXT_DE_PLL_RATIO macros
- fix BXT_DE_PLL_RATIO_MASK
- s/bxt_select_cdclk_freq/broxton_set_cdclk_freq/
- move cdclk init/uninit/set code from intel_ddi.c to intel_display.c
- remove redundant code comments for broxton_set_cdclk_freq()
- sanitize fixed point<->integer frequency value conversion
- use DRM_ERROR instead of WARN
- do RMW when programming BXT_DE_PLL_CTL for safety
- add note about PLL lock timeout being exactly 200us
- make PCU error messages more descriptive
- instead of using 0 freq to mean PLL off/bypass freq use 19200
for clarity, as the latter one is the actual rate
- simplify pcode programming, removing duplicated
sandybridge_pcode_write() call
- sanitize code flow, remove unnecessary scratch vars in
broxton_set_cdclk() (imre)
- Remove bound check for maxmimum freq to match current code.
This check will be added later at a more proper platform
independent place once atomic support lands.
- add note to remove freq guard band which isn't needed on BXT
- add note to reduce freq to minimum if no pipe is enabled
- combine broxton_modeset_global_pipes() with
valleyview_modeset_global_pipes()
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Separate topic branch for bxt didn't work out since we needed to
refactor the gmbus code a bit to make it look decent. So backmerge.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The port detection register flags in SFUSE_STRAP and DDI_BUF_CTL_A are
not defined for BXT, so don't use them.
Suggested by Satheesh.
v2:
- DDI_BUF_CTL_A bit 0 is not useful on BXT. Making changes to use this
bit when simulator or BXT is not applicable. Code re-arranged as per
Damien's suggestion.
v3:
- clarify commit message, add code comment (imre)
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2)
Cc: M, Satheeshakrishna <satheeshakrishna.m@intel.com>
Cc: Lespiau, Damien <damien.lespiau@intel.com>
Cc: Shankar, Uma <uma.shankar@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Connector states were being allocated in intel_setup_outputs() in loop
over all connectors. That meant hot-added connectors would have a NULL
state. Since the change to use a struct drm_atomic_state for the legacy
modeset, connector states are necessary for the i915 driver to function
properly, so that would lead to oopses.
Broken by
commit 944b0c7657
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Fri Mar 20 16:18:07 2015 +0200
drm/i915: Copy the staged connector config to the legacy atomic state
v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
