We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate
during atomic commits. This will continue to guarantee that we
deactivate FBC and it will also update the state checking structures
at the correct time. Then, later, at the point where we were calling
intel_fbc_update, we'll only need to call intel_fbc_post_update.
Also add the proper warnings in case we don't have the appropriate
locks. Daniel mentioned the warnings will have to be removed for async
commits, but let's keep them here while we can.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-12-git-send-email-paulo.r.zanoni@intel.com
We unconditionally disable/update FBC even during the page flip
IOCTLs, and an unconditional disable/update at every atomic commit
touching the primary plane shouldn't impact PC state residency
noticeably. Besides, the code that checks for rotation is a good hint
that we may be forgetting something else, so let's leave all the
decisions to intel_fbc.c, making the code much safer.
Once we have the code to properly make FBC enable/update decisions
based on atomic states, with proper locking, then we'll be able to
evaluate whether it will be worth trying to optimize the cases where a
disable isn't needed.
v2: Upstream moved and now our patch needs to remove dev_priv.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453406837-10511-1-git-send-email-paulo.r.zanoni@intel.com
Before this patch, page flips would call intel_frontbuffer_flip() and
intel_frontbuffer_flip_complete(), which would call intel_fbc_flush(),
which would call intel_fbc_update(). The problem is that drawing
operations also trigger intel_fbc_flush() calls, so it's not
guaranteed that we have the CRTC and FB locks grabbed when
intel_fbc_flush() happens, since the call trace may come from the
rendering path.
We're trying to make the FBC code grab the appropriate CRTC/FB locks,
so split the drawing and the flipping logic in order to achieve that
in later patches. So now the frontbuffer tracking code is just going
to be used for frontbuffer drawing, and intel_fbc_update() is going to
be used directly for actual page flips.
As a note, we don't need to call intel_fbc_flip() during the two
places where we call intel_frontbuffer_flip() since in one of them we
already have an intel_fbc_update() call, and in the other we have the
planes disabled.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453210558-7875-7-git-send-email-paulo.r.zanoni@intel.com
The fb_modifiers and cpp arguments passed to intel_tile_width() in
intel_fill_fb_ggtt_view() got accidentally swapped around. I'm pretty
sure I fixed this already, but could be I lost the fix accidentally
during some rebases or something. Anyway, fix it up for real.
Fixes: d9b3288ecf ("drm/i915: change intel_fill_fb_ggtt_view() to use the real tile size")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-8-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_rotation_crc/primary-rotation-90
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: drm-intel-fixes@lists.freedesktop.org
In the error-handling paths of i915_gem_do_execbuffer() and
intel_crtc_page_flip(), the local pointer-to-request variables
were expected to be either valid pointers or NULL. Since
2682708 drm/i915: simplify allocation of driver-internal requests
they could also be ERR_PTR() values, so the tests need to be
updated to accommodate this case.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453978089-29127-1-git-send-email-tvrtko.ursulin@linux.intel.com
There are a number of places where the driver needs a request, but isn't
working on behalf of any specific user or in a specific context. At
present, we associate them with the per-engine default context. A future
patch will abolish those per-engine context pointers; but we can already
eliminate a lot of the references to them, just by making the allocator
allow NULL as a shorthand for "an appropriate context for this ring",
which will mean that the callers don't need to know anything about how
the "appropriate context" is found (e.g. per-ring vs per-device, etc).
So this patch renames the existing i915_gem_request_alloc(), and makes
it local (static inline), and replaces it with a wrapper that provides
a default if the context is NULL, and also has a nicer calling
convention (doesn't require a pointer to an output parameter). Then we
change all callers to use the new convention:
OLD:
err = i915_gem_request_alloc(ring, user_ctx, &req);
if (err) ...
NEW:
req = i915_gem_request_alloc(ring, user_ctx);
if (IS_ERR(req)) ...
OLD:
err = i915_gem_request_alloc(ring, ring->default_context, &req);
if (err) ...
NEW:
req = i915_gem_request_alloc(ring, NULL);
if (IS_ERR(req)) ...
v4: Rebased
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453230175-19330-2-git-send-email-david.s.gordon@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Having this on stack triggers the -Wframe-larger-than=1024 and
is not nice to put such big things on the kernel stack anyway.
This required a little bit of refactoring to handle the new
failure path from vlv_force_pll_on.
v2: Corrected some whitespace.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453217117-26125-1-git-send-email-tvrtko.ursulin@linux.intel.com
This reverts commit 396e33ae20.
This commit was triggering some FIFO underrun warnings on ILK-IVB
platforms (but surprisingly not on HSW/BDW that share more or less the
same codepaths). These underruns were caught by the continuous
integration (CI) system and could be reproduced consistently when
running the basic acceptance tests (BAT) on the affected platforms.
Note that this revert will cause a visible regression for some
end-users; the "flicker when mouse moves between monitors in X" issue
that was reported before this patch was merged will now return. However
regressions that are visible to CI have higher priority since they
prevent proper testing of future patches on those platforms. Hopefully
we'll be able to figure out the cause of the underruns quickly and
remerge an improved version of this patch to fix the regression.
Cc: Daniel Vetter <daniel@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93640
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453232584-8543-1-git-send-email-matthew.d.roper@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler().
The former is a mask, the latter just the bit number.
Fortunately the only thing skl_update_scaler() does with the rotation
is check if it's 90/270 degrees or not, and so in this case it would
still do the right thing.
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1444917718-28495-1-git-send-email-ville.syrjala@linux.intel.com
Fixes: 6156a45602 ("drm/i915: skylake primary plane scaling using shared scalers")
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
On SKL+ plane scaling is mutually exclusive with color keying. The code
check for this, but during some refactoring the code got changed to
also reject primary plane windowing when color keying is used. There is
no such restriction in the hardware, so restore the original logic.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: 061e4b8d65 ("drm/i915: clean up atomic plane check functions, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452883613-28549-1-git-send-email-ville.syrjala@linux.intel.com
Cc: stable@vger.kernel.org
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Pull in Dave's drm-next pull request to have a clean base for 4.6.
Also, we need the various atomic state extensions Maarten recently
created.
Conflicts are just adjacent changes that all resolve to nothing in git
diff.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
misc i915 fixes all over the place.
* tag 'drm-intel-next-fixes-2016-01-14' of git://anongit.freedesktop.org/drm-intel:
drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page
drm/i915: Widen return value for reservation_object_wait_timeout_rcu to long.
drm/i915: intel_hpd_init(): Fix suspend/resume reprobing
drm/i915: shut up gen8+ SDE irq dmesg noise, again
drm/i915: Restore inhibiting the load of the default context
drm/i915: Tune down rpm wakelock debug checks
drm/i915: Avoid writing relocs with addresses in non-canonical form
drm/i915: Move Braswell stop_machine GGTT insertion workaround
Since your main drm-next pull isn't out of the door yet I figured I might
as well flush out drm-misc instead of delaying for 4.6. It's really just
random stuff all over, biggest thing probably connector_mask tracking from
Maarten.
* tag 'topic/drm-misc-2016-01-17' of git://anongit.freedesktop.org/drm-intel: (24 commits)
drm/fb_cma_helper: Remove implicit call to disable_unused_functions
drm/sysfs: use kobj_to_dev()
drm/i915: Init power domains early in driver load
drm: Do not set connector->encoder in drivers
apple-gmux: Add initial documentation
drm: move MODULE_PARM_DESC to other file
drm/edid: index CEA/HDMI mode tables using the VIC
drm/atomic: Remove drm_atomic_connectors_for_crtc.
drm/i915: Update connector_mask during readout, v2.
drm: Remove opencoded drm_gem_object_release_handle()
drm: Do not set outparam on error during GEM handle allocation
drm/docs: more leftovers from the big vtable documentation pile
drm/atomic-helper: Reject legacy flips on a disabled pipe
drm/atomic: add connector mask to drm_crtc_state.
drm/tegra: Use __drm_atomic_helper_reset_connector for subclassing connector state, v2.
drm/atomic: Add __drm_atomic_helper_connector_reset, v2.
drm/i915: Set connector_state->connector using the helper.
drm: Use a normal idr allocation for the obj->name
drm: Only bump object-reference count when adding first handle
drm: Balance error path for GEM handle allocation
...
Per DP spec, the source device should fall back to 18 bpp, VESA range
RGB when the sink capability is unknown. Fix the color depth
clamping. 18 bpp color depth should ensure full color range in automatic
mode.
The clamping has been HDMI specific since its introduction in
commit 996a2239f9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 19 11:24:34 2013 +0200
drm/i915: Disable high-bpc on pre-1.4 EDID screens
Cc: stable@vger.kernel.org
Reported-and-tested-by: Dihan Wickremasuriya <nayomal@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105331
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452695720-7076-1-git-send-email-jani.nikula@intel.com
Add a common function to return "on" or "off" string based on the
argument, and drop the local versions of it.
This is the onoff version of
commit 42a8ca4cb4
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Aug 27 16:23:30 2015 +0300
drm/i915: add yesno utility function
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452768814-29787-1-git-send-email-jani.nikula@intel.com
Pull the code to determine the surface alignment for both linear and
tiled surfaces into a separate function intel_surf_alignment(). This
will be used not only for the vma alignment but actually aligning
the plane SURF once SKL+ starts using intel_compute_page_offset()
(since SKL+ needs >4K alignment for tiled surfaces too).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-8-git-send-email-ville.syrjala@linux.intel.com
Since intel_gen4_compute_page_offset() can now handle tiling formats
all the way down to gen2, rename it to intel_compute_tile_offset().
Not that we actually use it on gen2/3 since there's no DSPSURF etc.
registers which would take a page aligned address.
v2: s/page/tile/ (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-7-git-send-email-ville.syrjala@linux.intel.com
Use the actual tile size as to compute stuff in
intel_fill_fb_ggtt_view() instead of assuming it's PAGE_SIZE. I suppose
it doesn't matter since we don't use the results on gen2 platforms
where the tile size is 2k.
v2: Update due to CbCr plane
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-5-git-send-email-ville.syrjala@linux.intel.com
I find more usual to think about tile widths than heights, so changing
the intel_tile_height() to calculate the tile height as
tile_size/tile_width is easier than the opposite to the poor brain.
v2: Reorder arguments for consistency
Constify dev_priv arguments
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-4-git-send-email-ville.syrjala@linux.intel.com
Pull the tile width calculations from intel_fb_stride_alignment() into a
new function intel_tile_width().
Also take the opportunity to pass aroun dev_priv instead of dev to
intel_fb_stride_alignment().
v2: Reorder argumnents to be more consistent with other functions
Change intel_fb_stride_alignment() to accept dev_priv instead of dev
v3: Deal with Y tilling (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-3-git-send-email-ville.syrjala@linux.intel.com
Since
commit ac9b823655
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Nov 27 18:55:26 2015 +0200
drm/i915: Introduce a gmbus power domain
gmbus also needs the power domain infrastructure right from the start,
since as soon as we register the i2c controllers someone can use them.
v2: Adjust cleanup paths too (Chris).
v3: Rebase onto -nightly (totally bogus tree I had lying around) and
also move dpio init head (Ville).
v4: Ville instead suggested to move gmbus setup later in the sequence,
since it's only needed by the modeset code.
v5: Move even close to the actual user, right next to the comment that
states where we really need gmbus (and interrupts!).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Meelis Roos <mroos@linux.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: ac9b823655 ("drm/i915: Introduce a gmbus power domain")
Cc: stable@vger.kernel.org
References: http://www.spinics.net/lists/intel-gfx/msg83075.html
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452682528-19437-1-git-send-email-daniel.vetter@ffwll.ch
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a spurious warning from an integer overflow on 64-bits systems.
The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1.
Explicitly handling this by casting to lret fixes it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-and-tested-by: Joseph Yasi <joe.yasi@gmail.com>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 3c28ff22f6 ("i915: wait for fence in prepare_plane_fb")
Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com
(cherry picked from commit bcf8be279c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
sanitize_watermarks() does not properly handle errors returned by
drm_atomic_helper_duplicate_state(). Make failures drop locks before
returning. We also change the lock of connection_mutex to a
drm_modeset_lock_all_ctx() to make sure any EDEADLK's are handled
earlier.
v2: Change call to lock connetion_mutex with a call to
drm_modeset_lock_all_ctx(). This ensures that any lock contention
is handled earlier and drm_atomic_helper_duplicate_state() won't
return EDEADLK. (Maarten)
v3: Drop locks properly in more error paths. (Maarten)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452611617-32144-1-git-send-email-matthew.d.roper@intel.com
We use the vblank timestamps to generate the vblank frame counter value
on gen2. That means we need the pipe scanout position to be accurate
when we call drm_crtc_vblank_on(), otherwise the frame counter
guesstimate may jump when the pipe actually start.
What I observed on my 85x is that the DSL initially reads 0, and when
the pipe actually starts DSL jumps to vblank_start. On gen2 DSL==0 means
actually vtotal-1 (see update_scanline_offset()), so if we initially
get vtotal-1, and then very quickly vblank_start (or thereabouts), the
scanout position will appear to jump backwards by approximately one
vblank length. Which means the frame counter guesstimate will also
jump backwards. That's no good, so let's make sure the pipe has
started before we call drm_crtc_vblank_on().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450110229-30450-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move the ddi buffer translation programming to occur from the encoder
.pre_enable() hook, for just the ddi port we are enabling. Previously
we used to reprogram the translations for all ddi ports during
init and during power well enabling.
v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel)
Resolve conflicts due to dev_priv->atomic_cdclk_freq
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a spurious warning from an integer overflow on 64-bits systems.
The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1.
Explicitly handling this by casting to lret fixes it.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-and-tested-by: Joseph Yasi <joe.yasi@gmail.com>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: 3c28ff22f6 ("i915: wait for fence in prepare_plane_fb")
Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com
We have done unclaimed register access check in normal
(mmio_debug=0) mode once per write. This adds probability
of finding the exact sequence where we did the bad access, but
also adds burden to each write.
As we have mmio_debug available for more fine grained analysis,
give up accuracy of detecting correct spot at the first occurrence
by doing the one shot detection and arming of mmio_debug in hangcheck
and in modeset. This removes the write path performance burden.
v2: Remove gratuitous DRM_DEBUG and return value, comments (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1450250808-14864-1-git-send-email-mika.kuoppala@intel.com
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means they can be programmed immediately when we commit the
atomic state (without waiting for a vblank). Once the vblank does
happen, we can then re-program watermarks to the more optimal final
value.
v2: Significant rebasing/rewriting.
v3:
- Move 'need_postvbl_update' flag to CRTC state (Daniel)
- Don't forget to check intermediate watermark values for validity
(Maarten)
- Don't due async watermark optimization; just do it at the end of the
atomic transaction, after waiting for vblanks. We do want it to be
async eventually, but adding that now will cause more trouble for
Maarten's in-progress work. (Maarten)
- Don't allocate space in crtc_state for intermediate watermarks on
platforms that don't need it (gen9+).
- Move WaCxSRDisabledForSpriteScaling:ivb into intel_begin_crtc_commit
now that ilk_update_wm is gone.
v4:
- Add a wm_mutex to cover updates to intel_crtc->active and the
need_postvbl_update flag. Since we don't have async yet it isn't
terribly important yet, but might as well add it now.
- Change interface to program watermarks. Platforms will now expose
.initial_watermarks() and .optimize_watermarks() functions to do
watermark programming. These should lock wm_mutex, copy the
appropriate state values into intel_crtc->active, and then call
the internal program watermarks function.
v5:
- Skip intermediate watermark calculation/check during initial hardware
readout since we don't trust the existing HW values (and don't have
valid values of our own yet).
- Don't try to call .optimize_watermarks() on platforms that don't have
atomic watermarks yet. (Maarten)
v6:
- Rebase
v7:
- Further rebase
v8:
- A few minor indentation and line length fixes
v9:
- Yet another rebase since Maarten's patches reworked a bunch of the
code (wm_pre, wm_post, etc.) that this was previously based on.
v10:
- Move wm_mutex to dev_priv to protect against racing commits against
disjoint CRTC sets. (Maarten)
- Drop unnecessary clearing of cstate->wm.need_postvbl_update (Maarten)
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452108870-24204-1-git-send-email-matthew.d.roper@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
drm/i915: Update connector_mask during readout, v2.
The connector_mask may be used any time during the non-atomic
.crtc_disable which is called before the full atomic state is
set up and needs to be accurate for that reason.
Changes since v1:
- Update connector_mask in readout_hw_state and add a comment.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/568D1C55.8010001@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This prevents a unnecessary modeset on a dell XPS 13 (2016).
N is always a power of 2, which means that for fuzzy matching we should
compare for inequality on the n values, then do fuzzy matching on the m
values.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/568D0E93.304@linux.intel.com
Although we can do a good job of reading out hardware state, the
graphics firmware may have programmed the watermarks in a creative way
that doesn't match how i915 would have chosen to program them. We
shouldn't trust the firmware's watermark programming, but should rather
re-calculate how we think WM's should be programmed and then shove those
values into the hardware.
We can do this pretty easily by creating a dummy top-level state,
running it through the check process to calculate all the values, and
then just programming the watermarks for each CRTC.
v2: Move watermark sanitization after our BIOS fb reconstruction; the
watermark calculations that we do here need to look at pstate->fb,
which isn't setup yet in intel_modeset_setup_hw_state(), even
though we have an enabled & visible plane.
v3:
- Don't move 'active = optimal' watermark assignment; we just undo
that change in the next patch anyway. (Ville)
- Move atomic helper locking fix to separate patch. (Maarten)
v4:
- Grab connection_mutex before calling atomic helper to duplicate
state. The connector loop inside the helper will throw a WARN
if we don't hold something to protect the connector list (and the
helper itself doesn't try to lock the list).
- Make failure to calculate watermarks for inherited state a WARN()
since it probably indicates a serious problem in either our state
readout code or our watermark code for this platform.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Plane state objects contain two copies of src/dest coordinates: the
original (requested by userspace) coordinates in the base
drm_plane_state object, and a second, clipped copy (i.e., what we
actually want to program to the hardware) in intel_plane_state. We've
only been setting up the former set of values during boot time FB
reconstruction, but we should really be initializing both.
Note that the code here probably still needs some more work since we
make a lot of assumptions about how the BIOS programmed the hardware
that may not always be true, especially on gen9+; e.g.,
* Primary plane might not be positioned at 0,0
* Primary plane could have been rotated by the BIOS
* Primary plane might be scaled
* The BIOS fb might be a single "extended mode" FB that spans
multiple displays.
* ...etc...
v2: Reword/expand commit message description of assumptions we make
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by(v1): Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449171462-30763-4-git-send-email-matthew.d.roper@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
- fix atomic watermark recomputation logic (Maarten)
- modeset sequence fixes for LPT (Ville)
- more kbl enabling&prep work (Rodrigo, Wayne)
- first bits for mst audio
- page dirty tracking fixes from Dave Gordon
- new get_eld hook from Takashi, also included in the sound tree
- fixup cursor handling when placed at address 0 (Ville)
- refactor VBT parsing code (Jani)
- rpm wakelock debug infrastructure ( Imre)
- fbdev is pinned again (Chris)
- tune the busywait logic to avoid wasting cpu cycles (Chris)
* tag 'drm-intel-next-2015-12-18' of git://anongit.freedesktop.org/drm-intel: (81 commits)
drm/i915: Update DRIVER_DATE to 20151218
drm/i915/skl: Default to noncoherent access up to F0
drm/i915: Only spin whilst waiting on the current request
drm/i915: Limit the busy wait on requests to 5us not 10ms!
drm/i915: Break busywaiting for requests on pending signals
drm/i915: don't enable autosuspend on platforms without RPM support
drm/i915/backlight: prefer dev_priv over dev pointer
drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2)
drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping
drm/i915: Set the map-and-fenceable flag for preallocated objects
drm/i915: mdelay(10) considered harmful
drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters
drm/i915: add support for checking RPM atomic sections
drm/i915: check that we hold an RPM wakelock ref before we put it
drm/i915: add support for checking if we hold an RPM reference
drm/i915: use assert_rpm_wakelock_held instead of opencoding it
drm/i915: add assert_rpm_wakelock_held helper
drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers
drm/i915: get a permanent RPM reference on platforms w/o RPM support
drm/i915: refactor RPM disabling due to RC6 being disabled
...
When the crtc is configured but not active we currently clip to (0,0)x(0,0).
This results in differences in calculations depending on dpms setting.
When the crtc is enabled but not active run check_plane as if it were on,
but afterwards set plane_state->visible = false for the checks.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-13-git-send-email-maarten.lankhorst@linux.intel.com
On skylake when calculating plane visibility with the crtc in
dpms off mode the real cdclk may be different from what it would be
if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock)
from skl_max_scale. The fix is to keep a atomic_cdclk that would be true
if all crtc's were active.
This is required to get the same calculations done correctly regardless
of dpms mode.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-12-git-send-email-maarten.lankhorst@linux.intel.com
Parallel modesets are still not allowed, but this will allow updating
a different crtc during a modeset if the clock is not changed.
Additionally when all pipes are DPMS off the cdclk will be lowered
to the minimum allowed.
Changes since v1:
- Add dev_priv->active_crtcs for tracking which crtcs are active.
- Rename min_cdclk to min_pixclk and move to dev_priv.
- Add a active_crtcs mask which is updated atomically.
- Add intel_atomic_state->modeset which is set on modesets.
- Commit new pixclk/active_crtcs right after state swap.
Changes since v2:
- Make the changes related to max_pixel_rate calculations more readable.
Changes since v3:
- Add cherryview and missing WARN_ON to readout.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
This fixes a warning when the crtc is turned off. In that case fb
will be NULL, and crtc_clock will be 0. Because the crtc is no longer
active this is not a bug, and shouldn't trigger the WARN_ON.
Also remove handling a null crtc_state, with all transitional helpers
gone this can no longer happen.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448360945-5723-2-git-send-email-maarten.lankhorst@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
