msleep() can sleep for way too long, so switch wait_for() to use
usleep_range() instead. Following a totally unscientific method
I just picked the range as W-2W.
This cuts the i915 init time on my BSW to almost half:
- initcall i915_init+0x0/0xa8 [i915] returned 0 after 419977 usecs
+ initcall i915_init+0x0/0xa8 [i915] returned 0 after 238419 usecs
Note that I didn't perform any other benchmarks on this so far.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Store the colorkey in intel_plane and kill off all the RMW stuff
handling it.
This is just an intermediate step and eventually the colorkey needs to
be converted into some properties.
v2: Actually update the hardware state in the set_colorkey ioctl (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_plane->obj is not used anymore so kill it. Also don't pass both
the fb and obj to the sprite .update_plane() hook, as just passing the fb
is enough.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rewrite commit 31685c258e
Author: Deepak S <deepak.s@linux.intel.com>
Date: Thu Jul 3 17:33:01 2014 -0400
drm/i915/vlv: WA for Turbo and RC6 to work together.
Other than code clarity, the major improvement is to disable the extra
interrupts generated when idle. However, the reclocking remains rather
slow under the new manual regime, in particular it fails to downclock as
quickly as desired. The second major improvement is that for certain
workloads, like games, we need to combine render+media activity counters
as the work of displaying the frame is split across the engines and both
need to be taken into account when deciding the global GPU frequency as
memory cycles are shared.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Deepak S <deepak.s@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To keep things clear rename the intel_dp->supported_rates[] to
intel_dp->sink_rates[], and rename the supported_rates[] name we used
elsewhere for the intersection of source and sink rates to
common_rates[].
Cc: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that intel_dp_max_link_bw() no longer considers the source
restrictions we may try to enable MST with 5.4GHz even when the source
doesn't support it. To fix that switch the code over to handle the link
rate in the same way as the SST code handles it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Consider the link rates reported by the sink via
DP_SUPPORTED_LINK_RATES when checking modes against the max link
rate.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No point in converting from hardware format every single time, just
store the rates in the final format under intel_dp.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While we only need to restore pipe B/C interrupt registers on BDW when
enabling the power well, skylake a bit more flexible and we'll also need
to restore the pipe A registers as it has its own power well that can be
toggled.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Apparently, this has never worked reliably and is currently disabled. Also, the
gains are not particularly impressive. Thus rather than try to keep unused code
from decaying and having to update it for other driver changes, it was decided
to simply remove it.
For: VIZ-5115
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
eDp 1.4 supports custom frequencies.
Skylake supports following intermediate frequencies : 3.24 GHz, 2.16 GHz and
4.32 GHz along with usual LBR, HBR and HBR2 frequencies.
Read sink supported frequencies and get common frequencies from sink and
source and use these for link training.
v2: Rebased, removed calculation of min_clock since for edp it is taken as
max_clock (as per comment).
v3: Keeping single array for link rates (Satheesh)
v4: Setting LINK_BW_SET to 0 when setting LINK_RATE_SET (Satheesh)
v5: Some minor nits (Ville)
v6: Keeping separate arrays for source and sink rates (Ville)
v7: Remove redundant setting of DP_LINK_BW_SET to 0 (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Using DP_SUPPORTED_LINK_RATES macro for supported_rates array (Satheesh).
v3: Reading dpcd's supported link rates tables based upon edp version in the
same patch.
v4: Move version check under is_edp (Satheesh)
v5: Using le16 for rates, some naming, and removing nested if block (Ville)
v6: Correctly using DP_MAX_SUPPORTED_RATES and removing DP_SUPPORTED_LINK_RATES
(Ville)
v7: Incorrectly removed DP_SUPPORTED_LINK_RATES in v6, re-adding it
v8: Checking return value of intel_dp_dpcd_read_wake() (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Kill the blt/render tracking we currently have and use the frontbuffer
tracking infrastructure.
Don't enable things by default yet.
v2: (Rodrigo) Fix small conflict on rebase and typo at subject.
v3: (Paulo) Rebase on RENDER_CS change.
v4: (Paulo) Rebase.
v5: (Paulo) Simplify: flushes don't have origin (Daniel).
Also rebase due to patch order changes.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to port FBC to the frontbuffer tracking infrastructure, but
for that we need to know what caused the object invalidation so
we can react accordingly: CPU mmaps need manual, GTT mmaps and
flips don't need handling and ring rendering needs nukes.
v2: - s/ORIGIN_RENDER/ORIGIN_CS/ (Daniel, Rodrigo)
- Fix copy/pasted wrong documentation
- Rebase
v3: - Rebase
v4: - Don't pass the operation to flushes (Daniel).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The cursor size fields in intel_crtc just duplicate the data from
cursor->state.crtc_{w,h} so we don't need them any more. Worse, their
use in the watermark code actually introduces a subtle bug since they
don't get updated to mirror the state values until the plane commit
stage, which is *after* we've already used them to calculate new
watermark values. This happens because we had to move watermark updates
slightly earlier (outside vblank evasion) in commit
commit 32b7eeec4d
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Wed Dec 24 07:59:06 2014 -0800
drm/i915: Refactor work that can sleep out of commit (v7)
Dropping the intel_crtc fields and just using the state values (which
are properly updated by the time watermark updates happen) should solve
the problem.
Aside from the actual removal of the struct fields (which are formatted
in a way that I couldn't figure out how to match in Coccinelle), the
rest of this patch was generated via the following semantic patch:
// Drop assignment
@@
struct intel_crtc *C;
struct drm_plane_state S;
@@
(
- C->cursor_width = S.crtc_w;
|
- C->cursor_height = S.crtc_h;
)
// Replace usage
@@
struct intel_crtc *C;
expression E;
@@
(
- C->cursor_width
+ C->base.cursor->state->crtc_w
|
- C->cursor_height
+ C->base.cursor->state->crtc_h
|
- to_intel_crtc(E)->cursor_width
+ E->cursor->state->crtc_w
|
- to_intel_crtc(E)->cursor_height
+ E->cursor->state->crtc_h
)
v2: Rebase
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joe Konno <joe.konno@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89346
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- Y tiling support for scanout from Tvrtko&Damien
- Remove more UMS support
- some small prep patches for OLR removal from John Harrison
- first few patches for dynamic pagetable allocation from Ben Widawsky, rebased
by tons of other people
- DRRS support patches (Sonika&Vandana)
- fbc patches from Paulo
- make sure our vblank callbacks aren't called when the pipes are off
- various patches all over
* tag 'drm-intel-next-2015-02-27' of git://anongit.freedesktop.org/drm-intel: (61 commits)
drm/i915: Update DRIVER_DATE to 20150227
drm/i915: Clarify obj->map_and_fenceable
drm/i915/skl: Allow Y (and Yf) frame buffer creation
drm/i915/skl: Update watermarks for Y tiling
drm/i915/skl: Updated watermark programming
drm/i915/skl: Adjust get_plane_config() to support Yb/Yf tiling
drm/i915/skl: Teach pin_and_fence_fb_obj() about Y tiling constraints
drm/i915/skl: Adjust intel_fb_align_height() for Yb/Yf tiling
drm/i915/skl: Allow scanning out Y and Yf fbs
drm/i915/skl: Add new displayable tiling formats
drm/i915: Remove DRIVER_MODESET checks from modeset code
drm/i915: Remove regfile code&data for UMS suspend/resume
drm/i915: Remove DRIVER_MODESET checks from gem code
drm/i915: Remove DRIVER_MODESET checks in the gpu reset code
drm/i915: Remove DRIVER_MODESET checks from suspend/resume code
drm/i915: Remove DRIVER_MODESET checks in load/unload/close code
drm/i915: fix a printk format
drm/i915: Add media rc6 residency file to sysfs
drm/i915: Add missing description to parameter in alloc_pt_range
drm/i915: Removed the read of RP_STATE_CAP from sysfs/debugfs functions
...
Use cases like rotation require these hooks to have some context so they
know how to prepare and cleanup the frame buffer correctly.
For i915 specifically, object backing pages need to be mapped differently
for different rotation modes and the driver needs to know which mapping to
instantiate and which to tear down when transitioning between them.
v2: Made passed in states const. (Daniel Vetter)
[airlied: add mdp5 and atmel fixups]
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Display watermarks need different programming for different tiling
modes.
Set the relevant flag so this happens during the plane commit and
add relevant data into a structure made available to the watermark
computation code.
v2: Pass in tiling info to sprite plane updates as well.
v3: Rebased for plane handling changes.
v4: Handle fb == NULL when plane is disabled.
v5: Refactored for addfb2 interface.
v6: Refactored for fb modifier changes.
v7: Updated for atomic commit by only updating watermarks when tiling changes.
v8: BSpec watermark calculation updates.
v9: Restrict scope of y_tile_minimum variable. (Damien Lespiau)
v10: Get fb from plane state otherwise we are working on old state.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> (v9)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Skylake is able to scannout those tiling formats. We need to allow them
in the ADDFB ioctl and tell the harware about it.
v2: Rebased for addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Don't allow Y tiled fbs just yet. (Tvrtko Ursulin)
v5: Check for stride alignment and max pitch. (Tvrtko Ursulin)
v6: Simplify maximum pitch check. (Ville Syrjälä)
v7: Drop the gen9 check since requirements are no different. (Ville Syrjälä)
v8: Gen2 has different X tiling stride. (Ville Syrjälä)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> (v7)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Till Gen 7 we have two sets of M_N registers, but Gen 8 onwards
we have only one M_N register set. To support DRRS on both scenarios
a input parameter to intel_dp_set_m_n is added.
In case of DRRS, When platform provides two set of M_N registers for dp,
we can program them with two different dividers and switch between them.
But when only one such register set is provided, we have to program
the required divider M_N value on that registers itself.
Two enum members M1_N1 and M2_N2 are defined to represent the above
scenarios.
M1_N1 : Program dp_m_n on M1_N1 registers
dp_m2_n2 on M2_N2 registers (If supported)
M2_N2 : Program dp_m2_n2 on M1_N1 registers
M2_N2 registers are not supported
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function is not used outside of intel_display.c since;
commit cf4c7c1225
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Thu Dec 4 10:27:42 2014 -0800
drm/i915: Make all plane disables use 'update_plane' (v5)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was introduced in:
commit 0bc12bcb1b
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Fri Nov 14 08:52:28 2014 -0800
drm/i915: Introduce intel_psr.c
But the unpack function is unused at this date.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function is only used in intel_dp.c since:
commit 0e32b39cee
Author: Dave Airlie <airlied@redhat.com>
Date: Fri May 2 14:02:48 2014 +1000
drm/i915: add DP 1.2 MST support (v0.7)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There have been quite a bit of development lately, leaving behing lonely
protypes. Time to bid them farewell.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this we can treat the fb format modifier completely independently
from the fencing mode in obj->tiling_mode in the initial plane code.
Which means new tiling modes without any gtt fence are now fully
support in the core i915 driver code.
v2: Also add pixel_format while at it, we need this to compute the
height for the new tiling formats.
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
At the moment we use crtc->base.primary->fb to hold the initial
framebuffer allocation, disregarding if it's valid or not.
This lead to believe we were actually updating the fb at this point, but
it's not true and we haven't even called drm_framebuffer_init() on this
fb.
Instead, let's store the state in struct intel_initial_plane_config
until we know we can reuse that framebuffer.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter spotted a bug while reviewing some of my refactoring in this
are of the code. I'll quote:
"""
> @@ -9764,6 +9768,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> work->event = event;
> work->crtc = crtc;
> work->old_fb_obj = intel_fb_obj(old_fb);
> + work->old_tiling_mode = to_intel_framebuffer(old_fb)->tiling_mode;
Hm, that's actually an interesting bugfix - currently userspace could be
sneaky and destroy the old fb immediately after the flip completes and the
change the tiling of the underlying object before the unpin work had a
chance to run (needs some fudgin with rt prios to starve workers to make
this work though).
Imo the right fix is to hold a reference onto the fb and not the
underlying gem object. With that tiling is guaranteed not to change.
"""
This patch tries to implement the above proposed change.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
When we flip on the DRIVER_ATOMIC bit, the DRM core will start calling
this entrypoint to set and lookup driver-specific plane property values,
rather than maintaining a shadow copy in object->properties.
Note that although we add these functions to the plane vtable, they will
not yet be called. Future patches that switch our .set_property()
handler and/or enable full atomic functionality are required before
these code paths will be executed.
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>
All of the previous refactoring/consolidation of plane code has resulted
in intel_primary_plane_funcs, intel_cursor_plane_funcs, and
intel_sprite_plane_funcs being identical. Replace all of these with a
single 'intel_plane_funcs' vtable for simplicity.
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>
Runtime state that can be manipulated via properties should now go in
intel_plane_state/drm_plane_state so that it can be tracked as part of
an atomic transaction.
We add a new 'intel_create_plane_state' function so that the proper
initial value for this property (and future properties) doesn't have to
be repeated at each plane initialization site.
v2:
- Stick rotation in common drm_plane_state rather than
intel_plane_state. (Daniel)
- Add intel_create_plane_state() to consolidate the places where we
have to set initial state values. (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>
Calls have been added to invalidate/flush DRRS whenever invalidate/flush is
called as part of frontbuffer tracking.
Apart from calls as a result of GEM tracking to fb invalidate/flush, a
call has been added to invalidate fb obj from crtc_page_flip as well. This
is to track busyness through flip calls.
The call to fb_obj_invalidate (in flip) is placed before queuing flip for this
obj.
drrs_invalidate() and drrs_flush() check for drrs.dp which would be NULL if
it was setup in drrs_enable(). This covers for the condition when DRRS is
not supported.
v2: Removing the call to invalidate_drrs from page_flip.
This has not been tested on Android yet, but, in case DRRS transtions do not
work as expected, check by adding back this call in page_flip.
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Calling enable/disable DRRS when enable/disable DDI are called.
These functions are responsible for setup of drrs data (in enable) and
reset of drrs (in disable).
has_drrs is true when downclock_mode is found and SEAMLESS_DRRS is set in
the VBT. A check has been added for has_drrs in these functions, to make
sure the functions go through only if DRRS will work on the platform with
the attached panel.
V2: [By Ram]: WARN_ON is used when intel_edp_drrs_enable() is called more than
once [Rodrigo]
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Self-explanatory code is better code.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This vfunc and related structure are only used for fast boot, so let's
rename them to not take them as general purpose ones.
v2: Fix conflicts caused by the introduction of struct intel_crtc_state
Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1)
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we need to change the fb height constraints, it sounds like a good
idea to have to do it in one place only.
v2: v2: Rebase on top of Ander's "Make intel_crtc->config a pointer"
Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rather than having "tiled" meaning "is it X-tiled?" convert the field to
explicitely store the tiling mode. The code doesn't have to change much
as 1 is conveniently I915_TILING_X.
This is to accommodate future changes around tiling modes and scannout
buffers.
v2: Rebase on top of Ander's "Make intel_crtc->config a pointer"
Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The previous patch changed the config field in intel_crtc to a pointer,
but to keep the mechanical changes (done with spatch) separate from the
new code, the pointer was made to point to a new _config field with type
struct intel_crtc_state added to that struct. This patch improves that
code by getting rid of that field, allocating a state struct in
intel_crtc_init() a keeping it properly updated when a mode set
happens.
v2: Manual changes split from previous patch. (Matt)
Don't leak the current state when the crtc is destroyed (Matt)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
[danvet: Squash in fixup from Matt Roper for driver unload.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To match the semantics of drm_crtc->state, which this will eventually
become. The allocation of the memory for config will be fixed in a
followup patch. By adding the extra _config field to intel_crtc it was
possible to generate this entire patch with the cocci script below.
@@ @@
struct intel_crtc {
...
-struct intel_crtc_state config;
+struct intel_crtc_state _config;
+struct intel_crtc_state *config;
...
}
@@ struct intel_crtc *crtc; @@
-memset(&crtc->config, 0, sizeof(crtc->config));
+memset(crtc->config, 0, sizeof(*crtc->config));
@@ @@
__intel_set_mode(...) {
<...
-to_intel_crtc(crtc)->config = *pipe_config;
+(*(to_intel_crtc(crtc)->config)) = *pipe_config;
...>
}
@@ @@
intel_crtc_init(...) {
...
WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
+intel_crtc->config = &intel_crtc->_config;
return;
...
}
@@ struct intel_crtc *crtc; @@
-&crtc->config
+crtc->config
@@ struct intel_crtc *crtc; identifier member; @@
-crtc->config.member
+crtc->config->member
@@ expression E; @@
-&(to_intel_crtc(E)->config)
+to_intel_crtc(E)->config
@@ expression E; identifier member; @@
-to_intel_crtc(E)->config.member
+to_intel_crtc(E)->config->member
v2: Clarify manual changes by splitting them into another patch. (Matt)
Improve cocci script to generate even more of the changes. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reduces the number of direct users of crtc->new_config, opening up
the possibilty of removing it altogether.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The objective is to make this structure usable with the atomic helpers,
so let's start with the rename. Patch generated with coccinelle:
@@ @@
-struct intel_crtc_config {
+struct intel_crtc_state {
...
}
@@ @@
-struct intel_crtc_config
+struct intel_crtc_state
v2: Completely generate the patch with cocci. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Earlier, DRRS structures were specific to eDP (used only in intel_dp).
Since DRRS can be extended to other internal display types
(if the panel supports multiple RR), modifying structures
to be part of drm_i915_private and have a provision to add display related
structs like intel_dp.
Also, aligning with frontbuffer tracking mechanism, the new structure
contains data for busy frontbuffer bits.
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- refactor i915/snd-hda interaction to use the component framework (Imre)
- psr cleanups and small fixes (Rodrigo)
- a few perf w/a from Ken Graunke
- switch to atomic plane helpers (Matt Roper)
- wc mmap support (Chris Wilson & Akash Goel)
- smaller things all over
* tag 'drm-intel-next-2015-01-17' of git://anongit.freedesktop.org/drm-intel: (40 commits)
drm/i915: Update DRIVER_DATE to 20150117
i915: reuse %ph to dump small buffers
drm/i915: Ensure the HiZ RAW Stall Optimization is on for Cherryview.
drm/i915: Enable the HiZ RAW Stall Optimization on Broadwell.
drm/i915: PSR link standby at debugfs
drm/i915: group link_standby setup and let this info visible everywhere.
drm/i915: Add missing vbt check.
drm/i915: PSR HSW/BDW: Fix inverted logic at sink main_link_active bit.
drm/i915: PSR VLV/CHV: Remove condition checks that only applies to Haswell.
drm/i915: VLV/CHV PSR needs to exit PSR on every flush.
drm/i915: Fix kerneldoc for i915 atomic plane code
drm/i915: Don't pretend SDVO hotplug works on 915
drm/i915: Don't register HDMI connectors for eDP ports on VLV/CHV
drm/i915: Remove I915_HAS_HOTPLUG() check from i915_hpd_irq_setup()
drm/i915: Make hpd arrays big enough to avoid out of bounds access
Revert "drm/i915/chv: Use timeout mode for RC6 on chv"
drm/i915: Improve HiZ throughput on Cherryview.
drm/i915: Reset CSB read pointer in ring init
drm/i915: Drop unused position fields (v2)
drm/i915: Move to atomic plane helpers (v9)
...
Backmerge Linus tree after rc5 + drm-fixes went in.
There were a few amdkfd conflicts I wanted to avoid,
and Ben requested this for nouveau also.
Conflicts:
drivers/gpu/drm/amd/amdkfd/Makefile
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.c
drivers/gpu/drm/amd/amdkfd/kfd_priv.h
drivers/gpu/drm/amd/include/kgd_kfd_interface.h
drivers/gpu/drm/i915/intel_runtime_pm.c
drivers/gpu/drm/radeon/radeon_kfd.c
The userspace-requested plane coordinates are now always available via
plane->state.base (and the i915-adjusted values are stored in
plane->state), so we no longer use the coordinate fields in intel_plane
and can drop them.
Also, note that the error case for pageflip calls update_plane() to
program the values from plane->state; it's simpler to just call
intel_plane_restore() which does the same thing.
v2: Replace manual update_plane() with intel_plane_restore() in pageflip
error handler.
Reviewed-by(v1): Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Switch plane handling to use the atomic plane helpers. This means that
rather than provide our own implementations of .update_plane() and
.disable_plane(), we expose the lower-level check/prepare/commit/cleanup
entrypoints and let the DRM core implement update/disable for us using
those entrypoints.
The other main change that falls out of this patch is that our
drm_plane's will now always have a valid plane->state that contains the
relevant plane state (initial state is allocated at plane creation).
The base drm_plane_state pointed to holds the requested source/dest
coordinates, and the subclassed intel_plane_state holds the adjusted
values that our driver actually uses.
v2:
- Renamed file from intel_atomic.c to intel_atomic_plane.c (Daniel)
- Fix a copy/paste comment mistake (Bob)
v3:
- Use prepare/cleanup functions that we've already factored out
- Use newly refactored pre_commit/commit/post_commit to avoid sleeping
during vblank evasion
v4:
- Rebase to latest di-nightly requires adding an 'old_state' parameter
to atomic_update;
v5:
- Must have botched a rebase somewhere and lost some work. Restore
state 'dirty' flag to let begin/end code know which planes to
run the pre_commit/post_commit hooks for. This would have actually
shown up as broken in the next commit rather than this one.
v6:
- Squash kerneldoc patch into this one.
- Previous patches have now already taken care of most of the
infrastructure that used to be in this patch. All we're adding here
now is some thin wrappers.
v7:
- Check return of intel_plane_duplicate_state() for allocation
failures.
v8:
- Drop unused drm_plane_state -> intel_plane_state cast. (Ander)
- Squash in actual transition to plane helpers. Significant
refactoring earlier in the patchset has made the combined
prep+transition much easier to swallow than it was in earlier
iterations. (Ander)
v9:
- s/track_fbs/disabled_planes/ in the atomic crtc flags. The only fb's
we need to update frontbuffer tracking for are those on a plane about
to be disabled (since the atomic helpers never call prepare_fb() when
disabling a plane), so the new name more accurately describes what
we're actually tracking.
Testcase: igt/kms_plane
Testcase: igt/kms_universal_plane
Testcase: igt/kms_cursor_crc
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>
A few of the sprite-related function names in i915 are very similar
(e.g., intel_enable_planes() vs intel_crtc_enable_planes()) and don't
make it clear whether they only operate on sprite planes, or whether
they also apply to all universal plane types. Rename a few functions to
be more consistent with our function naming for primary/cursor planes or
to clarify that they apply specifically to sprite planes:
- s/intel_disable_planes/intel_disable_sprite_planes/
- s/intel_enable_planes/intel_enable_sprite_planes/
Also, drop the sprite-specific intel_destroy_plane() and just use
the type-agnostic intel_plane_destroy() function. The extra 'disable'
call that intel_destroy_plane() did is unnecessary since the plane will
already be disabled due to framebuffer destruction by the point it gets
called.
v2: Earlier consolidation patches have reduced the number of functions
we need to rename here.
v3: Also rename intel_plane_funcs vtable to intel_sprite_plane_funcs
for consistency with primary/cursor. (Ander)
v4: Convert comment for intel_plane_destroy() to kerneldoc now that it
is no longer a static function. (Ander)
Reviewed-by(v1): Bob Paauwe <bob.j.paauwe@intel.com>
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>
Move the vblank evasion up from the low-level, hw-specific
update_plane() handlers to the general plane commit operation.
Everything inside commit should now be non-sleeping, so this brings us
closer to how vblank evasion will behave once we move over to atomic.
v2:
- Restore lost intel_crtc->active check on vblank evasion
v3:
- Replace assert_pipe_enabled() in intel_disable_primary_hw_plane()
with an intel_crtc->active test; it turns out assert_pipe_enabled()
grabs some mutexes and can sleep, which we can't do with interrupts
disabled.
v4:
- Equivalent to v2; v3 change is now squashed into an earlier patch
of the series. (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>
Once we integrate our work into the atomic pipeline, plane commit
operations will need to happen with interrupts disabled, due to vblank
evasion. Our commit functions today include sleepable work, so those
operations need to be split out and run either before or after the
atomic register programming.
The solution here calculates which of those operations will need to be
performed during the 'check' phase and sets flags in an intel_crtc
sub-struct. New intel_begin_crtc_commit() and
intel_finish_crtc_commit() functions are added before and after the
actual register programming; these will eventually be called from the
atomic plane helper's .atomic_begin() and .atomic_end() entrypoints.
v2: Fix broken sprite code split
v3: Make the pre/post commit work crtc-based to match how we eventually
want this to be called from the atomic plane helpers.
v4: Some platforms that haven't had their watermark code reworked were
waiting for vblank, then calling update_sprite_watermarks in their
platform-specific disable code. These also need to be flagged out
of the critical section.
v5: Sprite plane test for primary show/hide should just set the flag to
wait for pending flips, not actually perform the wait. (Ander)
v6:
- Rebase onto latest di-nightly; picks up an important runtime PM fix.
- Handle 'wait_for_flips' flag in intel_begin_crtc_commit(). (Ander)
- Use wait_for_flips flag for primary plane update rather than
performing the wait in the check routine.
- Added kerneldoc to pre_disable/post_enable functions that are no
longer static. (Ander)
- Replace assert_pipe_enabled() in intel_disable_primary_hw_plane()
with an intel_crtc->active test; it turns out assert_pipe_enabled()
grabs some mutexes and can sleep, which we can't do with interrupts
disabled.
v7:
- Check for fb != NULL when deciding whether the sprite plane hides the
primary plane during a sprite update. (PRTS)
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>
Conflicts:
drivers/gpu/drm/i915/intel_runtime_pm.c
Separate branch so that Takashi can also pull just this refactoring
into sound-next.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In
commit dbea3cea69
Author: Imre Deak <imre.deak@intel.com>
Date: Mon Dec 15 18:59:28 2014 +0200
drm/i915: sanitize RPS resetting during GPU reset
we disable RPS interrupts during GPU resetting, but don't apply the
necessary GEN6 HW workaround. This leads to a HW lockup during a
subsequent "looping batchbuffer" workload. This is triggered by the
testcase that submits exactly this kind of workload after a simulated
GPU reset. I'm not sure how likely the bug would have triggered
otherwise, since we would have applied the workaround anyway shortly
after the GPU reset, when enabling GT powersaving from the deferred
work.
This may also fix unrelated issues, since during driver loading /
suspending we also disable RPS interrupts and so we also had a short
window during the rest of the loading / resuming where a similar
workload could run without the workaround applied.
v2:
- separate the fix to route RPS interrupts to the CPU on GEN9 too
to a separate patch (Daniel)
Bisected-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Testcase: igt/gem_reset_stats/ban-ctx-render
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87429
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Register a component to be used to interface with the snd_hda_intel
driver. This is meant to replace the same interface that is currently
based on module symbol lookup.
v2:
- change roles between the hda and i915 components (Daniel)
- add the implementation to a new file (Jani)
- use better namespacing (Jani)
v3:
- move the implementation to intel_audio.c (Daniel)
- rename display_component to audio_component (Daniel)
- add kerneldoc (Daniel)
v4:
- run forgotten git rm i915_component.c (Jani)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No functional changes. This is just the begin of a FBC rework.
v2 (Paulo):
- Revert intel_fbc_init() changed parameter.
- Revert set_no_fbc_reason() rename.
- Rebase.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remove the function intel_output_name() that is not used anywhere.
This was partially found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we extend the commit_plane handlers for each plane type to be able to
handle fb=0, then we can easily implement plane disable via the
update_plane handler. The cursor plane already works this way, and this
is the direction we need to go to integrate with the atomic plane
handler. We can now kill off the type-specific disable functions, as
well as the redundant intel_plane_disable() (not to be confused with
intel_disable_plane()).
Note that prepare_plane_fb() only gets called as part of update_plane
when fb!=NULL (by design, to match the semantics of the atomic plane
helpers); this means that our commit_plane handlers need to handle the
frontbuffer tracking for the disable case, even though they don't handle
it for normal updates.
v2:
- Change BUG_ON to WARN_ON (Ander/Daniel)
v3:
- Drop unnecessary plane->crtc check since a previous patch to plane
update ensures that plane->crtc will always be non-NULL, even for
disable calls that might pass NULL from userspace. (Ander)
- Drop a s/crtc/plane->crtc/ hunk that was unnecessary. (Ander)
v4:
- Fix missing whitespace (Ander)
v5:
- Use state's crtc rather than plane's crtc in
intel_check_primary_plane(). plane->crtc could be NULL, but we've
already fixed up state->crtc to ensure it's non-NULL (even if
userspace passed it as NULL during a disable call). (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our .update_plane() handlers do the same check/prepare/commit/cleanup
steps regardless of plane type. Consolidate them all into a single
function that calls check/commit through a vtable.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
All plane update functions need to unpin the old framebuffer when
flipping to a new one. Pull this logic into a separate function to ease
the integration with atomic plane helpers.
v2: Don't wait for vblank if we don't have an old fb to cleanup (Ander)
v3: Really don't wait for vblank if we don't have an old fb to cleanup.
Previous version only handled this for primary planes; we need the
same change on cursors/sprites too! (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The 'prepare' step for all types of planes are pretty similar;
consolidate the three 'prepare' functions into a single function. This
paves the way for future integration with the atomic plane handlers.
Note that we pull the 'wait for pending flips' functionality out of the
primary plane's prepare step and place it directly in the 'setplane'
code. When we move to the atomic plane handlers, this code will be in
the 'atomic begin' step.
v2: Update GEM fb tracking for physical cursors also (Ander)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Clear the video overlay state on GPU reset. Any pending overlay request
in the ring has been nuked, and the display itself gets reset. So we
pretty much lose all state here. Adjust the software state to match so
that the next "putimage" will restore things to working order.
v2: Ass a locking check into intel_overlay_release_old_vid() (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: s/0/NULL/ to appease sparse, reported by 0-day tester.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to the patch from John which removed obj->ring.
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Thomas Daniel <Thomas.Daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Converted the flip_queued_seqno value to be a request structure as part of the
on going seqno to request changes. This includes reference counting the request
being saved away to ensure it can not be retired and freed while the flip code
is still waiting on it.
For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Again get rid of the _irq request unref by simply moving that
into the unpin worker. Doesn't matter when we hang onto the request
for a bit longer, and in the unpin worker we already grab the
dev->struct_mutex anyway.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Converted the mmio_flip 'seqno' value to be a request structure as part of the
on going seqno to request changes. This includes reference counting the request
being saved away to ensure it can not be retired and freed while the flip code
is still waiting on it.
v2: Used the IRQ friendly request dereference call in the notify handler as that
code is called asynchronously without holding any useful mutex locks.
For: VIZ-4377
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Thomas Daniel <Thomas.Daniel@intel.com>
[danvet: Drop the _irq variant and use the normal reques unref,
wrapped in dev->struct_mutex per the discussion on the m-l.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function was in use to check if PSR feature got enabled.
However on HSW and BDW we currently force psr exit by disabling
EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually
returning the active/inactive state that is different from the enable/disable
meaning and had the risk of false negative.
But anyway this check with DRRS was dangerous, since DRRS could try to get enabled
before PSR gets there. So let's just remove it for now.
A proper synchronization mechanism must be implemented later probably
using pipe config.
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On gen4 and earlier the GPU reset also resets the display, so we should
protect against concurrent modeset operations. Grab all the modeset locks
around the entire GPU reset dance, remebering first ti dislogde any
pending page flip to make sure we don't deadlock. Any pageflip coming
in between these two steps should fail anyway due to reset_in_progress,
so this should be safe.
This fixes a lot of failed asserts in the modeset code when there's a
modeset racing with the reset. Naturally the asserts aren't happy when
the expected state has disappeared.
v2: Drop UMS checks, complete pending flips after the reset (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we first enable the RPS interrupts then we clear any pending ones.
By this we could lose an interrupt arriving after we unmasked it. This
may not be a problem as the caller should handle such a race, but logic
still calls for the opposite order. Also we can delay enabling the
interrupts until after all the RPS initialization is ready with the
following order:
1. disable left-over RPS (earlier via intel_uncore_sanitize)
2. clear any pending RPS interrupts
3. initialize RPS
4. enable RPS interrupts
This also allows us to do the 2. and 4. step the same way for all
platforms, so let's follow this order to simplifying things.
Also make sure any queued interrupts are also cleared.
v2:
- rebase on the GEN9 patches where we don't support RPS yet, so we
musn't enable RPS interrupts on it (Paulo)
v3:
- avoid enabling RPS interrupts on GEN>9 too (Paulo)
- clarify the RPS init sequence in the log message (Chris)
- add POSTING_READ to gen6_reset_rps_interrupts() (Paulo)
- WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts()
(Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No functional changes. Just cleaning and reorganizing it.
v2: Rebase it puting it to begin of psr rework. This helps to blame easily
at least latest changes.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Modify the implementation to query DPLL attached to a SKL port.
v2: Rebase on top of the run-time PM on DPMS series (Damien)
v3: Modified as per review comments from Paulo
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is useful for checking things later.
v2:
- fix hsw infoframe enabled check (Ander)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Add the missing PIPE_CONF_CHECK_I(has_infoframe); line to the
hw state cross-checker.]
[danet: Squash in fixup from Jesse to correctly compute has_infoframe
in the hdmi compute_config function.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we register the backlight device as soon as we register the
connector. That means we can get backlight requests from userspace
already before reading out the current modeset hardware state.
That means we don't yet know the current crtc->encoder->connector mapping,
which causes problems for VLV/CHV which need to know the current pipe in
order to figure out which BLC registers to poke. Currently we just
ignore such requests fairly deep in the backlight code which means the
backlight device brightness property will get out of sync with our
backlight.level and the actual hardware state.
Fix the problem by delaying the backlight device registration until the
entire modeset init has been performed. And we also move the
backlight unregisteration to happen as the first thing during the
modeset cleanup so that we also won't be bothered with userspace
backlight requested during teardown.
This is a real world problem on machines using systemd, because systemd,
for some reason, wants to restore the backlight to the level it used last
time. And that happens as soon as it sees the backlight device appearing
in the system. Sometimes the userspace access makes it through before
the modeset init, sometimes not.
v2: Do not lie to the user in the debug prints (Jani)
Include connector name in the prints (Jani)
Fix a typo in the commit message (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV/CHV both pipes A and B have their own backlight control
registers. In order to correctly read out the current hardware state at
init we need to know which pipe is driving the eDP port. Pass that
information down from the eDP init code into the backlight code.
To determine the correct pipe we first look at which pipe is currently
configured in the port control register, if that look invalid we look
at which pipe's PPS is currently controlling the port, and if that
too looks invalid we just assume pipe A.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The logical place for these functions is in i915_irq.c next to the rest of
PM interrupt handling functions.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The helpers to enable/disable PM IRQs for GEN6 and GEN8 are the same
except for the PM interrupt mask register, so abstract away this
register in the GEN6 versions and use these everywhere.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This simplifies the code quite a bit compared to iterating over all
rings during the ring interrupt.
Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip
struct is only accessed in two places. The first is when the flip is
queued and the other when the mmio writes are done. Since a flip cannot
be queued while there is a pending flip, the two paths shouldn't ever
run in parallel. We might need to revisit that if support for replacing
flips is implemented though.
v2: Don't hold dev->struct_mutext while waiting (Chris)
v3: Make the wait uninterruptable (Chris)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch provides the implementation for reading the pipe wm HW
state.
v2: Incorporated Damien's review comments and also made modifications
to incorporate the plane/cursor split.
v3: No need to ident a line that was fitting 80 chars
Return early instead of indenting the remaining of a function
(Damien)
v4: Rebase on top of nightly (minor conflict in intel_drv.h)
v5: Rebase on top of nightly (minor conflict in intel_drv.h)
v6: Rebase on top of nightly (minor conflict in intel_drv.h)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch defines the structures needed for computation of
watermarks of pipes and planes for SKL.
v2: Incorporated Damien's review comments and removed unused fields
in structs for future features like rotation, drrs and scaling.
The skl_wm_values struct is now made more generic across planes
and cursor planes for all pipes.
v3: implemented the plane/cursor split.
v4: Change the wm union back to a structure (Ville, Daniel)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we program just DPSCNTR and DSPSTRIDE directly from the ring
interrupt handler, which is fine since the hardware guarantees that
those are update atomically. When we have atomic page flips we'll want
to be able to update also the offset registers, and then we need to use
the vblank evade mechanism to guarantee atomicity. Since that mechanism
introduces a wait, we need to do the actual register write from a work
when it is triggered by the ring interrupt.
v2: Explain the need for mmio_flip.work in the commit message (Paulo)
Initialize the mmio_flip work in intel_crtc_init() (Paulo)
Prevent new flips the previous flip work finishes (Paulo)
Don't acquire modeset locks for mmio flip work
Note: Paulo had reservations about the work item leaking over a plane
disable. But insofar as we do lack these checks that issue is already
present with the existing code.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It will help future code if this function knows something about of the context
of the display setup object is being pinned for.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The function was removed in:
commit 0e32b39cee
Author: Dave Airlie <airlied@redhat.com>
Date: Fri May 2 14:02:48 2014 +1000
drm/i915: add DP 1.2 MST support (v0.7)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As Paulo said when introducing the enum, having more types is really
good to document what should go where (int foo(int, int, bool, bool).
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we suspend we turn everything off so the pps should be idle, and we
also (or at least should) disable all power wells which will reset the
power sequencer port assignment. So when we resume all power sequencers
should be in their reset state. However it's at least theoretically
possible that the BIOS would touch the power seuqencer(s), so to be safe
we ought to read out the current port assignment like we do at driver
init time.
To do that we can simply call vlv_initial_power_sequencer_setup() from
the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize().
There's no danger or clobbering the pps delays since we now have those
stored within intel_dp and we don't change them once initialized.
This will make sure that the vdd state gets correctly tracked post-resume
in case the BIOS enabled it.
We need to shuffle things around a bit to get the locking right, and
while at it, make intel_edp_panel_vdd_sanitize() static and move it
around a bit to avoid a forward declaration.
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>
Introduce functions to enable/disable the audio codec, incorporating the
ELD setup within enable. The disable is initially limited to HSW,
covering exactly what was done previously.
The only functional difference is that ELD valid is no longer set if
there is no connector with ELD, which should be the right thing to do
anyway. Otherwise the sequence remains the same, with warts and all, in
preparation for applying more sanity.
v2: add kernel doc.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The power seqeuencer kick procedure requires the DPLL to be running
in order to complete successfully. In case the DPLL isn't currently
running when we need to kick the power seqeuncer enable it
temporarily. This can happen eg. during ->detect() when the pipe is
not already active.
To avoid needlessly duplicating the DPLL programming re-use the already
existing functions by passing a temporary pipe config to them instead
of having them consult the current pipe config at crtc->config.
v2: Introduce vlv_force_pll_{on,off}() (Daniel)
v3: Rebase due to drm_crtc vs. intel_crtc changes
Fix a typo in commit msg (checkpatch)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v1)
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The power seqeuncer delays are fixed for a given panel, so we can keep
them around once computed.
Not that on VLV/CHV we still re-compute them every time we initialize
the power seqeuncer registers, but that will change soon enough.
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>
Because I got annoyed that I had to document what values "int
ddi_personality" is supposed to hold.
A good side-effect of this change is that now the compilers can do
some additional checks on our code, which may prevent some bugs in the
future. A bad side-effect of this change is that now the compilers do
some additional checks on our code and complain when a switch
statement doesn't check for all possible values, so we need to add
"default" cases to all those switches. Hopefully, this may help
preventing confusions against DRM_MODE_CONNECTOR_* and
DRM_MODE_ENCODER_*.
I guess that just by looking at the patch, some people will think this
change is not worth its benefits. In this case, I don't really mind
dropping the patch.
Also, there's probably still a few more places where we can
s/int/enum intel_output_type/, but we can change that later, when we
spot the places.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflict due to reordered patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Everything else can be derived from that. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In preparation for some additional cleanup. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This simplifies the code in the vlv irq handler. Also this now
means that we correctly filter underruns on gen2-4.
And as the real upshot I need to document one less function for
the fifo underrun code.
v2: Shorten one long line.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Way too much copypasta all over. And this also clarifies a bit what's
going on since it separates the "do we have an underrun irq" from the
"should we report the underrun" check.
v2: Fix excessively long lines.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Prep work for some nice documentation. Requires that we export the
display irq enable/disable functions on ilk/ibx. But we already export
them for vlv/i915. So not more inconsistency.
v2: Rebase on top of skl stage 1.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
So I've sent the first pull request to Dave and I expect his request
for a merge tree any second now ;-)
More seriously I have some pending patches for 3.19 that depend upon
both trees, hence backmerge. Conflicts are all trivial.
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/intel_display.c
v2: Of course I've forgotten the fixup script for the silent conflict.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Move the duplicated DIV_ROUND_CLOSEST_ULL macro into the intel_drv.h
header file so that it can be shared between intel_display.c
and intel_panel.c.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-By: Joe Konno <joe.konno@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's the new world order!
Not going full monty on these here and rolling this out throughout the
subsequent call chains since this is just for the kerneldoc. Later on
we can go more crazy, especially once we've embedded drm_device
correctly.
v2: Also frob the runtime_pm functions ...
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Double negations just parse harder. Also this allows us to ditch some
init code since clearing to 0 dtrt. Also ditch the assignment in
intel_pm_setup, that's not redundant since we do the assignement now
while setting up interrupts.
While at it do engage in a bit of OCD and wrap up the few lines of
setup/teardown code into little helper functions: intel_irq_fini for
cleanup and intel_irq_init_hw for hw setup.
v2: Use _install/_uninstall for the new wrapper function names as
Paulo suggested.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
