Having a single path for everything makes it a lot easier to keep
crtc_state->active in sync with intel_crtc->active.
A crtc cannot be changed to active when not enabled, because it means
no mode is set and no connectors are connected.
This should also make intel_crtc->active match crtc_state->active.
Changes since v1:
- Reworded commit message, there's no intel_crtc_toggle.
Changes since v2:
- Change some callers of intel_crtc_control to intel_display_suspend.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This is a function used to disable all crtc's. This makes it clearer
to distinguish between when mode needs to be preserved and when
it can be trashed.
Changes since v1:
- Copy power changes from intel_crtc_control.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that the dpll updates are (mostly) atomic, the .off() code is a noop,
and intel_crtc_disable does mostly the same as intel_modeset_update_state.
Move all logic for connectors_active and setting dpms to that function.
Changes since v1:
- Move drm_atomic_helper_swap_state up.
Changes since v2:
- Split out intel_put_shared_dpll removal.
Changes since v3:
- Rebase on top of latest drm-intel.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that the pll updates are staged the put_shared_dpll function
consists only of checks that are done in check_shared_dpll_state
after a modeset too.
The changes to pll->config are overwritten by
intel_shared_dpll_commit, so this entire function is a noop.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville's and Mika's cdclk series was in flight at the same time as the
SKL S3 patches so we were missing that update.
intel_update_max_cdclk() and intel_update_cdclk() had to be moved up a
bit to avoid forward declarations.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We can operate with DPLL0 off with CDCLK backed by the 24Mhz reference
clock, and that's a supported configuration. Don't warn when notice
DPLL0 is off then.
We still have a separate warn at boot if cdclk is disabled (because we
don't currently try to handle the case (that shouldn't happen on SKL as
far as I know) where we boot with display not initialized.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add support for changing cdclk frequency during runtime on BDW.
Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
so take that into account when computing the max pixel rate.
v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
v4: Rebased to the latest
v5: Rebased to the latest
v6: Patch order shuffle so that Broadwell CD clock change is
applied before the patch for Haswell CD clock change
v7: Fix for patch style problems
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
exceeds 95% of the core display clock. Apparently this can cause
underruns.
There's no similar restriction listed for HSW, so leave that one alone
for now.
v2: Add pipe_config_supports_ips() (Chris)
v3: Compare against the max cdclk insted of the current cdclk
v4: Rebased to the latest
v5: Rebased to the latest
v6: Fix for patch style problems
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83497
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Keep the cdclk maximum supported frequency around in dev_priv so that we
can verify certain things against it before actually changing the cdclk
frequency.
For now only VLV/CHV have support changing cdclk frequency, so other
plarforms get to assume cdclk is fixed.
v2: Rebased to the latest
v3: Rebased to the latest
v4: Fix for patch style problems
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Rather than reading out the current cdclk value use the cached value we
have tucked away in dev_priv.
v2: Rebased to the latest
v3: Rebased to the latest
v4: Fix for patch style problems
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Rather that extracting the current cdclk freuqncy every time someone
wants to know it, cache the current value and use that. VLV/CHV already
stored a cached value there so just expand that to cover all platforms.
v2: Rebased to the latest
v3: Rebased to the latest
v4: Rebased to the latest
v5: Removed spurious call to 'intel_update_cdclk(dev)' based on
Damien Lespiau's comment
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Silence the following -Wmaybe-uninitialized warnings and make the code
more clear.
drivers/gpu/drm/i915/intel_display.c: In function ‘__intel_set_mode’:
drivers/gpu/drm/i915/intel_display.c:11844:14: warning: ‘crtc_state’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return state->mode_changed || state->active_changed;
^
drivers/gpu/drm/i915/intel_display.c:11854:25: note: ‘crtc_state’ was declared here
struct drm_crtc_state *crtc_state;
^
drivers/gpu/drm/i915/intel_display.c:11868:6: warning: ‘crtc’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (crtc != intel_encoder->base.crtc)
^
drivers/gpu/drm/i915/intel_display.c:11853:19: note: ‘crtc’ was declared here
struct drm_crtc *crtc;
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Without this frontbuffer flip when enabling planes PSR got compromised
and wasn't being enabled waiting forever on the flush that never
arrived.
Another solution would to create a enable_cursor function and split this
frontbuffer flip among the different plane enable and disable functions.
But if necessary this can be done in a follow up work. For now let's
just fix the regression.
It was removed by:
commit 87d4300a7d
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Tue Apr 21 17:12:54 2015 +0300
drm/i915: Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use it there.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Print a warning if we fall through the .get_display_clock_speed() function
pointer setup. We end up assuming a 133MHz cdclk which should mean that
at least we avoid any 0 deivisions and whatnot. But this could at least
help remind people that they have to provide this function for new platforms.
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Implement cdclk extraction for g33, 965gm and g4x platforms. The details
came from configdb. Sadly there isn't anything there for other gen3/gen4
chipsets.
So far I've tested this on one ELK where it gave me a HPLL VCO of 5333
MHz and cdclk of 444 MHz which seems perfectly sane for this machine.
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems 852GM/GMV uses a different HPLLCC encoding than the other
85x platforms. For 852GM/GMV cdclk is always 133MHz. Try to detect that
using the PCI revision (sinc the device ID seems useless for that). I'm
not at all sure this is a good idea, but according to the specs it
should work.
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Actually read the HPLLCC register insted of assuming it's 0. Fix the
HPLLCC bit definitions and all the missing ones from the 852GME spec.
852GME, 854 and 855 all seem to match the same HPLLC encoding even
though only some of the values are valid is some of the platforms.
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
chv_enable_pll() doesn't need to hold sb_lock for the entire duration of
the function. Drop the lock as soon as possible.
valleyview_set_cdclk() does a potential lock+unlock+lock+unlock cycle
with sb_lock. Grab the lock a few lines earlier so we can make do
with a single lock+unlock cycle always.
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>
Rename dpio_lock to sb_lock to inform the reader that its primary
purpose is to protect the sideband mailbox rather than some DPIO
state.
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 primary plane frobbing was removed from the sprite code in
commit ecce87ea3a
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Tue Apr 21 17:12:50 2015 +0300
drm/i915: Remove implicitly disabling primary plane for now
but the intel_flush_primary_plane() calls were left behind. Replace them
with straight forward POSTING_READ() of the sprite surface address
register.
The other user of intel_flush_primary_plane() is g4x_disable_trickle_feed()
where we can just inline the steps directly.
This allows intel_flush_primary_plane() to be killed off.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is a mplayer video failure reported with xv.
This is because there is a request to do both plane scaling
and colorkey. Because skl hw doesn't support plane scaling
and colorkey at the same time, request is failed which is expected
behavior.
To make xv operate, this patch allows colorkey continue to work
without using scaler. Then behavior would be similar to platforms
without plane scaler support.
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90449
[danvet: change can_scale to bool as requested by Ville.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bspec says we should disable the FDI RX/TX before disabling the PCH
ports. Do so.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we're always enabling enhanced framing on CPT even if the sink
doesn't support it. Fix this up by actaully looking at what the sink
tells us.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to re-init the display hardware when going out of suspend. This
includes:
- Hooking the PCH to the reset logic
- Restoring CDCDLK
- Enabling the DDB power
Among those, only the CDCDLK one is a bit tricky. There's some
complexity in that:
- DPLL0 (which is the source for CDCLK) has two VCOs, each with a set
of supported frequencies. As eDP also uses DPLL0 for its link rate,
once DPLL0 is on, we restrict the possible eDP link rates the chosen
VCO.
- CDCLK also limits the bandwidth available to push pixels.
So, as a first step, this commit restore what the BIOS set, until I can
do more testing.
In case that's of interest for the reviewer, I've unit tested the
function that derives the decimal frequency field:
#include <stdio.h>
#include <stdint.h>
#include <assert.h>
#define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))
static const struct dpll_freq {
unsigned int freq;
unsigned int decimal;
} freqs[] = {
{ .freq = 308570, .decimal = 0b01001100111},
{ .freq = 337500, .decimal = 0b01010100001},
{ .freq = 432000, .decimal = 0b01101011110},
{ .freq = 450000, .decimal = 0b01110000010},
{ .freq = 540000, .decimal = 0b10000110110},
{ .freq = 617140, .decimal = 0b10011010000},
{ .freq = 675000, .decimal = 0b10101000100},
};
static void intbits(unsigned int v)
{
int i;
for(i = 10; i >= 0; i--)
putchar('0' + ((v >> i) & 1));
}
static unsigned int freq_decimal(unsigned int freq /* in kHz */)
{
return (freq - 1000) / 500;
}
static void test_freq(const struct dpll_freq *entry)
{
unsigned int decimal = freq_decimal(entry->freq);
printf("freq: %d, expected: ", entry->freq);
intbits(entry->decimal);
printf(", got: ");
intbits(decimal);
putchar('\n');
assert(decimal == entry->decimal);
}
int main(int argc, char **argv)
{
int i;
for (i = 0; i < ARRAY_SIZE(freqs); i++)
test_freq(&freqs[i]);
return 0;
}
v2:
- Rebase on top of -nightly
- Use (freq - 1000) / 500 for the decimal frequency (Ville)
- Fix setting the enable bit of HSW_NDE_RSTWRN_OPT (Ville)
- Rename skl_display_{resume,suspend} to skl_{init,uninit}_cdclk to
be consistent with the BXT code (Ville)
- Store boot CDCLK in ddi_pll_init (Ville)
- Merge dev_priv's skl_boot_cdclk into cdclk_freq
- Use LCPLL_PLL_LOCK instead of (1 << 30) (Ville)
- Replace various '0' by SKL_DPLL0 to be a bit more explicit that
we're programming DPLL0
- Busy poll the PCU before doing the frequency change. It takes about
3/4 cycles, each separated by 10us, to get the ACK from the CPU
(Ville)
v3:
- Restore dev_priv->skl_boot_cdclk, leaving unification with
dev_priv->cdclk_freq for a later patch (Daniel, Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we will often pageflip to an active surface, we will often have to
wait for the surface to be written before issuing the flip. Also we are
likely to wait on that surface in plenty of time before the vblank.
Since we have a mechanism for boosting when a flip misses the expected
vblank, curtain the number of times we RPS boost when simply waiting for
mmioflip.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: s/rq/req/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, we only track the last request globally across all engines.
This prevents us from issuing concurrent read requests on e.g. the RCS
and BCS engines (or more likely the render and media engines). Without
semaphores, we incur costly stalls as we synchronise between rings -
greatly impacting the current performance of Broadwell versus Haswell in
certain workloads (like video decode). With the introduction of
reference counted requests, it is much easier to track the last request
per ring, as well as the last global write request so that we can
optimise inter-engine read read requests (as well as better optimise
certain CPU waits).
v2: Fix inverted readonly condition for nonblocking waits.
v3: Handle non-continguous engine array after waits
v4: Rebase, tidy, rewrite ring list debugging
v5: Use obj->active as a bitfield, it looks cool
v6: Micro-optimise, mostly involving moving code around
v7: Fix retire-requests-upto for execlists (and multiple rq->ringbuf)
v8: Rebase
v9: Refactor i915_gem_object_sync() to allow the compiler to better
optimise it.
Benchmark: igt/gem_read_read_speed
hsw:gt3e (with semaphores):
Before: Time to read-read 1024k: 275.794µs
After: Time to read-read 1024k: 123.260µs
hsw:gt3e (w/o semaphores):
Before: Time to read-read 1024k: 230.433µs
After: Time to read-read 1024k: 124.593µs
bdw-u (w/o semaphores): Before After
Time to read-read 1x1: 26.274µs 10.350µs
Time to read-read 128x128: 40.097µs 21.366µs
Time to read-read 256x256: 77.087µs 42.608µs
Time to read-read 512x512: 281.999µs 181.155µs
Time to read-read 1024x1024: 1196.141µs 1118.223µs
Time to read-read 2048x2048: 5639.072µs 5225.837µs
Time to read-read 4096x4096: 22401.662µs 21137.067µs
Time to read-read 8192x8192: 89617.735µs 85637.681µs
Testcase: igt/gem_concurrent_blit (read-read and friends)
Cc: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [v8]
[danvet: s/\<rq\>/req/g]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The merged seqno->request conversion from John called request
variables req, but some (not all) of Chris' recent patches changed
those to just rq. We've had a lenghty (and inconclusive) discussion on
irc which is the more meaningful name with maybe at most a slight bias
towards req.
Given that the "don't change names without good reason to avoid
conflicts" rule applies, so lets go back to a req everywhere for
consistency. I'll sed any patches for which this will cause conflicts
before applying.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <John.C.Harrison@Intel.com>
[danvet: s/origina/merged/ as pointed out by Chris - the first
mass-conversion patch was from Chris, the merged one from John.]
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Since DRM_ROTATE is counter clockwise (which is compliant with Xrandr),
and HW rotation is clockwise, swapping 90/270 to work as expected from
userspace.
v2: Rebased
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Explain why a few fields of the new pipe_config have their values
preserved, while the others are zeroed.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ARGB8888 is used for cursors on all platforms so we need to allow it
everywhere.
ABGR8888 is currently only honoured:
- on VLV/CHV in sprite planes
- on SKL+ for primary and sprite planes
so only allow it for those platforms.
Note that we only support ARGB8888/ABGR8888 on the primary plane for
SKL/BXT because we have in line of sight the pipe bottom color on those
platforms and because the primary plane programming on VLV/CHV doesn't
anything different for those formats today.
v2: Fix the logic to forbid the creation ABGR2101010 fbs (Ville)
v3: Still allow the creation of ARGB8888 fbs now that cursor planes use
real fb objects (found by PRTS).
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We just have have VLV and CHV sprites programming the hardware
differently for the ABGR2101010 so keep them working.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That define makes it hard to figure out what is the actual list of
formats at a glance. Expand it then.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the modeset code is reached with a CRTC that only needs a flip, the
code that assigns PLLs is skipped. But since there is still a state swap
for that CRTC, the current PLL assignment needs to be preserved. I
missed the ddi_pll_sel field in the following commit, which causes
warnings in DDI platforms.
commit 4978cc93d9
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Tue Apr 21 17:13:21 2015 +0300
drm/i915: Preserve shared DPLL information in new pipe_config
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90410
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the following commit, the place where the contents of dpll_hw_state
in crtc_state where zeroed was changed. Prior to that commit, it
happened when the new state was allocated, but now that happens just
before the call the .crtc_compute_clock() hook. The DP code for SKL,
however, sets up the (private) PLL in the encoder compute config
function that has already run by the time that memset() is reached,
causing the previous value to be lost.
This patch fixes the issue by moving the memset() down the call chain,
so that it is only called if the values in dpll_hw_state are going to be
updated.
commit 4978cc93d9
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Tue Apr 21 17:13:21 2015 +0300
drm/i915: Preserve shared DPLL information in new pipe_config
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reported-and-tested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just so it is grouped logically in line with other data and makes a
rather verbose output a bit shorter.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville noticed in another patch we we didn't need them at all, so remove
them. It's worth saying that it makes no difference to code generated as
gcc is clever enough to optimize it out.
v2: Remove 'break' after 'return' in switches (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We now prefix our functions/enums/data with the first platform it has
been introduced. Do that for the primary plane formats.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: s/gen2/i8xx/ and s/gen4/i965/ ...]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We advertize C8 in the primary plane formats didn't have the
corresponding code to set PLANE_CTL accordingly.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's be consistent with the others skl_plane_ctl_*() functions and use
a MISSING_CASE(). Not only that, but it's a rude to BUG() the whole
machine here.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No reason to not follow the 80 chars rule, renaming the local variable
makes it easy.
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We usually use a new line before those kind of return statements. Also
the various skl_plane_ctl*() functions weren't consistent.
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During check_crtc_state, scaler_id mispatch is being reported for HSW.
This is applicable for skl+ and not for HSW. It is introduced by
commit id:
commit a1b2278e4d
Author: Chandra Konduru <chandra.konduru@intel.com>
Date: Tue Apr 7 15:28:45 2015 -0700
drm/i915: skylake panel fitting using shared scalers
This patch will make sure that we leave scaler_id as 0 for platforms
before skl and set for skl+ only. This way scaler_id check during
check_crtc_state will pass for both prior to skl and skl+ platforms.
v2:
-Leave scaler_id as 0 for gen < 9 (Daniel)
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
References: http://lists.freedesktop.org/archives/intel-gfx/2015-May/065741.html
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we perform the mmio-flip without any locking and then try to acquire
the struct_mutex prior to dereferencing the request, it is possible for
userspace to queue a new pageflip before the worker can finish clearing
the old state - and then it will clear the new flip request. The result
is that the new flip could be completed before the GPU has finished
rendering.
The bugs stems from removing the seqno checking in
commit 536f5b5e86
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Thu Nov 6 11:03:40 2014 +0200
drm/i915: Make mmio flip wait for seqno in the work function
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Synchronising to an object active on the same ring is a no-op, for the
benefit of execbuffer scheduler. However, for CS flips this means that
we can forgo checking whether the last write request of the object is
actually queued and more importantly whether the cache flush for the
write was emitted.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We no longer interpolate domains in the same manner, and even if we did,
we should trust setting either of the other write domains would trigger
an invalidation rather than force it. Remove the tweaking of the
read_domains since it serves no purpose and use
i915_gem_object_wait_rendering() directly.
Note that this goes back to
commit a8198eea15
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Apr 13 22:04:09 2011 +0100
drm/i915: Introduce i915_gem_object_finish_gpu()
and gpu domain tracking died in
commit cc889e0f6c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jun 13 20:45:19 2012 +0200
drm/i915: disable flushing_list/gpu_write_list
which is more than 1 year older.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add notes with information dug out of git history.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In skylake update plane functions, intel_tile_height() is called with
bits_per_pixel instead of pixel_format. Correcting it.
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
[danvet: Fixup alignment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the recent modeset internal rework, we wind up setting crtc_state->enable
to false, but leave crtc_state->active as true following a
drmModeSetCrtc(fb=0), which is incorrect. This mismatch gets caught by
drm_atomic_crtc_check() and causes subsequent atomic operations (such as plane
updates while the CRTC is disabled) to fail.
Bisect points to
commit dad9a7d6d96630182fb52aae7c3856e9e7285e13
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Tue Apr 21 17:13:19 2015 +0300
drm/i915: Use atomic helpers for computing changed flags
as the commit that actually triggers the regression.
The difference compared to (which this patch reverts)
commit 90d469067d
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Thu May 7 14:31:28 2015 -0700
drm/i915: Set crtc_state->active to false when CRTC is disabled (v2)
is that we know keep state->active/enable in sync for all legacy
modeset paths, as it should be.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reported-and-Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Directly squash in the revert and augment the commit
message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Revert "drm/i915: Set crtc_state->active to false when CRTC is disabled (v2)"
This reverts commit 90d469067d.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVWh3TAAoJEHm+PkMAQRiG/kwH/2c9irodp2+M9OUnX2bfsBb6
LnChiDpvkF5BB8jhP6d/XmvPp4NJzAbTxByhjdfb2E2HkorCUHCOIn2tI1TE2pUs
2qjkOVH+XCzoV0goGtQjzK1ht8f2IrtlDiEjyRekK5cJHzhggb22QPtWL4npyd0O
reDmG2jsRaF9POr9uLSFEv4CEnkksmRLUU0vuQX0TZeCJ41O7TXrkN/wKrLZ5mj4
IWpqXQaSlrffq/T5HnVbXBxk3/T8QmhrIoppiMpV1mUVj0uTqlFRNi5qwT2Nit1h
FVljWI4+WgOk3bf7fUlp+ahopjkTgu+GuXkiRP/pdgWNQO0cxCWSAzSndAlIIAE=
=uOoJ
-----END PGP SIGNATURE-----
Backmerge v4.1-rc4 into into drm-next
We picked up a silent conflict in amdkfd with drm-fixes and drm-next,
backmerge v4.1-rc5 and fix the conflicts
Signed-off-by: Dave Airlie <airlied@redhat.com>
Conflicts:
drivers/gpu/drm/drm_irq.c
Currently vlv_wait_port_ready() waits for all four lanes on the
appropriate channel. This no longer works on CHV when the unused
lanes may be power gated. So pass in a mask of lanes that the
caller is expecting to be ready.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the recent modeset internal rework, we wind up setting
crtc_state->enable to false, but leave crtc_state->active as true, which
is incorrect. This mismatch gets caught by drm_atomic_crtc_check() and
causes subsequent atomic operations (such as plane updates while the
CRTC is disabled) to fail.
Bisect points to
commit dad9a7d6d96630182fb52aae7c3856e9e7285e13
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Tue Apr 21 17:13:19 2015 +0300
drm/i915: Use atomic helpers for computing changed flags
as the commit that actually triggers the regression.
v2: Update to alter in-flight state rather than already-committed state
(first version was accidentally based on a midpoint of Ander's
modeset rework series, before his final patches that add proper
state swapping to the legacy modeset path).
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Testcase: igt/kms_universal_plane
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>
Now that we do proper state swaps, we don't depend on this function
anymore to keep the state in sync.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Replace the commit output state function with a simple swap of states.
Note that we still need to reconcile the legacy state after the swap,
since there are still code that relies on those.
Also note that even though changes to the state of a crtc different than
the one passed as an argument to __intel_set_mode() will be saved, the
modeset logic still deals with only one crtc.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use lower level calls to better integrate with the modeset code and
allow a full state swap in a follow up patch.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When a new pipe_config is calculated, the fields related to shared dplls
are reset, under the assumption that they will be recalculated as part
of the modeset, which is true with the current state of the code.
As we convert to atomic, however, it will be possible to calculate a new
pipe_config and skip the modeset. In that case, after the state swap we
still want the shared dplls to be preserved.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To match the behavior of ->atomic_commit().
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Replace the drivers own logic for computing mode_changed, active_changed
and planes_changed flags with the check_modeset() atomic helper. Since
that function needs to compare the crtc's new mode with the current,
this patch also moves the set up of crtc_state->mode earlier in the call
chain.
Note that for the call to check_plane() to work properly, we need to
check new plane state against new crtc state. But since we still use the
plane update helper, which doesn't have a full atomic state, we need to
hack around that in intel_plane_atomic_check().
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In a follow up patch the function that computes mode changes will be
replaced with the one from the atomic helpers. To preserve the behavior
of legacy modeset forcing DPMS on, that function will need to detect a
change in the active state of the crtc, so that has to be kept up to
date.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is no longer necessary since we only update the staged config on
successfull modeset. The new configuration is stored in an atomic state
struct which is freed in case of failure.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The logic that stages the state before the modeset was still updating
first the old staged config and then populating the atomic state based
on that. Change this to use only the atomic state.
Note that now the staged config is updated in the function
intel_modeset_commit_output_state(). This is done so that the modeset
check and the force restore path in the hw state read out code continue
to work.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a helper function to make the code slightly more readable.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Call intel_set_mode() uncondionally from intel_crtc_set_config(), since
the former function is now properly wired to ignore all the modesets if
the mode_changed and active_changed flags are false in crtc_state.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the atomic state instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use the similar fields in crtc_state instead, so that this code can be
moved to our future implementation of atomic_check().
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't need to pass it down the call chain anymore now that the plane
state is set up properly.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add the primary plane state to the legacy modeset atomic state and use
it when configuring the primary plane in __intel_set_mode(). This is a
first step towards merging the flip path in intel_crtc_set_config() and
__intel_set_mode().
v2: Set crtc to NULL if fb is NULL. (Maarten)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The modeset code is now properly divided in two phases, so that it only
changes hardware state if it succeeds, so there's no ill-effect that
needs to be undone on failure anymore.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The remaining parts of the failure path could only be reached if the
allocation of crtc_state_copy would fail. In that case, there is nothing
to undo, so just get rid of the label for error handling and return an
error code immediately.
We also always allocate a pipe_config, even if the pipe is being
disabled, so the remaining part of what was the error/done case can be
simplified a little too.
v2: Ignore return value from drm_plane_helper_update(). (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The first function calls done in that function can still cause changes
to the atomic state and may fail. This should eventually be part of our
atomic check function, while the rest of the code in __intel_set_mode()
is the commit hook. So this makes the legacy mode set more atomic-y.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no way that function can fail after it sets crtc->mode anymore,
so there's no need to save the old mode for the failure case.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Set the mode_changed field on the crtc_states and use that instead.
Note that even though this patch doesn't completely replace the logic in
intel_modeset_affected_pipes(), that logic was never fully used to its
full extent. Since the commit mentioned below, modeset_pipes and
prepare_pipes would only contain at most the pipe for which the set_crtc
ioctl was called. We can grow back that logic when the time comes.
commit b6c5164d7b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Apr 12 18:48:43 2013 +0200
drm/i915: Fixup Oops in the pipe config computation
v2: Don't set mode_changed unconditionally for modeset_crtc. (Ander)
Check for needs_modeset() before trying to allocate a PLL. (Ander)
Only call .crtc_enable() for pipes that were disabled. (Maarten)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the current implementation of intel_modeset_affected_pipes(), if a
pipe will be enabled then it is in modeset_pipes. We'll remove that mask
in a follow up patch, but want to preserve this behavior, so just make
that explicit.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The code in intel_modeset_pipe_config() still needs changes before it
can calculate more than just one pipe_config, and pretending it can will
only make those changes more difficult.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The function intel_modeset_compute_config() needs to eventually become
part of atomic_check(). At that point, all the affected crtcs need to be
in the atomic state with the new values. So move the logic of adding
crtc states out of that function.
v2: Set crtc_state->enable in all cases. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should make the conversion to atomic easier, by splitting the
initialization of the atomic state from the logic that decides if a
modeset is needed.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Simplifies looping over connector states a bit.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is not necessary after the below commit.
commit a0211bb482
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Mon Mar 30 14:05:43 2015 +0300
drm/atomic: Don't try to free a NULL state
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This makes disabling planes more explicit.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[anderco: fixed warning due to using drm_crtc instead of intel_crtc]
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To make it clear that it isn't called during crtc enable.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They're the same code, so why not?
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was an optimization from way back before we had primary plane
support to be able to disable the primary plane. But with primary
plane support userspace can tell the kernel this directly, so there's
no big need for this any more. And it's getting in the way of the
atomic conversion.
If need be we can resurrect this later on properly again.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Explain why removing this is ok.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows disabling all planes affecting a crtc without caring what type it is.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is used by the next commit to disable all planes on a crtc
without caring what type it is.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Do a POSTING_READ() between the DBUF_CTL register write and the
udelay() to make sure we really wait after the register write has
happened.
Spotted while reviewing Damien's SKL cdclk patch which had the
POSTING_READ()s.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch enables skylake primary plane scaling using shared
scalers atomic desgin.
v2:
-use single copy of scaler limits (Matt)
v3:
-move detach_scalers to crtc commit path (Matt)
-use values in plane_state->src as regular integers (me)
v4:
-changes to align with updated scaler structures (Matt, me)
-keep plane src rect in 16.16 format (Matt, Daniel)
v5:
-Rebased on top of 90/270 rotation changes (me)
-Fixed an issue introduced by 90/270 changes where plane programming
is using drm_plane->state rect instead of intel_plane->state rect.
This change also required for scaling to work properly. (me)
-With 90/270, updated limits to cover both portrait and landscape usages (me)
-Refactored skylake_update_primary_plane to reduce its size (Daniel)
Added helper functions for refactoring are comprehended enough to be
used for skylake_update_plane (for sprite) too. One stop towards
having single function for all planes.
v6:
-Added fixme note when checking plane_state->src width in update_plane (Daniel)
-Release lock when failing to colorkey request with active scaler (Daniel)
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: matthew.d.roper@intel.com
Reviewed-by: sonika.jindal@intel.com (v5)
Testcase: igt/kms_plane_scaling
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm-intel-next-2015-04-23:
- dither support for ns2501 dvo (Thomas Richter)
- some polish for the gtt code and fixes to finally enable the cmd parser on hsw
- first pile of bxt stage 1 enabling (too many different people to list ...)
- more psr fixes from Rodrigo
- skl rotation support from Chandra
- more atomic work from Ander and Matt
- pile of cleanups and micro-ops for execlist from Chris
drm-intel-next-2015-04-10:
- cdclk handling cleanup and fixes from Ville
- more prep patches for olr removal from John Harrison
- gmbus pin naming rework from Jani (prep for bxt)
- remove ->new_config from Ander (more atomic conversion work)
- rps (boost) tuning and unification with byt/bsw from Chris
- cmd parser batch bool tuning from Chris
- gen8 dynamic pte allocation (Michel Thierry, based on work from Ben Widawsky)
- execlist tuning (not yet all of it) from Chris
- add drm_plane_from_index (Chandra)
- various small things all over
* tag 'drm-intel-next-2015-04-23-fixed' of git://anongit.freedesktop.org/drm-intel: (204 commits)
drm/i915/gtt: Allocate va range only if vma is not bound
drm/i915: Enable cmd parser to do secure batch promotion for aliasing ppgtt
drm/i915: fix intel_prepare_ddi
drm/i915: factor out ddi_get_encoder_port
drm/i915/hdmi: check port in ibx_infoframe_enabled
drm/i915/hdmi: fix vlv infoframe port check
drm/i915: Silence compiler warning in dvo
drm/i915: Update DRIVER_DATE to 20150423
drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010
rm/i915: Move i915_get_ggtt_vma_pages into ggtt_bind_vma
drm/i915: Don't try to outsmart gcc in i915_gem_gtt.c
drm/i915: Unduplicate i915_ggtt_unbind/bind_vma
drm/i915: Move ppgtt_bind/unbind around
drm/i915: move i915_gem_restore_gtt_mappings around
drm/i915: Fix up the vma aliasing ppgtt binding
drm/i915: Remove misleading comment around bind_to_vm
drm/i915: Don't use atomics for pg_dirty_rings
drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt
drm/i915/skl: Support Y tiling in MMIO flips
drm/i915: Fixup kerneldoc for struct intel_context
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
Since the introduction of BIOS fb preservation, circa 3.17, we began
encountering a failure during boot when trying to use force-detect
before GEM was initialised. That bug is from
commit 7fad798e16
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jul 4 17:51:47 2012 +0200
drm/i915: ensure the force pipe A quirk is actually followed
but investigation of the affected machine revealed that it was using a
PIPE-A quirk even though it was a 945GSE and the quirk is only supposed
to be used to workaround a hardware issue on 830/845. That quirk was
added for this HP Mini in
commit 6b93afc564a5e74b0eaaa46c95f557449951b3b9
Author: Bryce Harrington <bryce@bryceharrington.org>
Date: Wed May 27 03:40:52 2009 -0700
add pipe a force quirk for Dell mini
in order to workaround an issue with the BIOS behaving strangely during
lid-close. Since then we have a much larger hammer to thwart the BIOS
after opening the lid and the PIPE-A quirk is no longer required.
Reported-and-tested-by: Apostolos B. <barz621@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=21960
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=87521
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The checks for PLL enabled state on CPU ports are valid only on GMCH
platforms but atm we'd also call them on non-PCH-split/non-GMCH
platforms like BXT, triggering false warnings. Until the proper check is
implented for these platforms simply disable the check.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Determine PLL attached to pipe (which is same as DDI PLL)
v2:
- rebased on upstream s/crtc_config/crtc_state/ (imre)
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Assign PLL for pipe (dependent on port attached to the pipe)
v2:
- fix incorrect encoder vs. new_encoder check for crtc (imre)
v3:
- warn and return error if no encoder is attached (imre)
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v2)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Don't move intel_ddi_get_crtc_new_encoder around.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Broxton has the same panel fitter registers as Skylake.
v2:
- add MISSING_CASE for future platforms (daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a separate patch to simplify conflict handling with other
ongoing atomic work.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since universal planes the primary plane might not be around, and it's
kinda silly to restrict the pipe bpp to the primary plane if we might
end up displaying a 10bpc video overlay. And with atomic we might very
well enable a pipe without a primary plane. So just use the platform
max as a starting point and then restrict appropriately.
Of course this is all still a bit moot as long as we artificially
compress everything to max 8bpc because we don't use the hi-bpc gamma
tables.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add CDCLK specific display clock initialization sequence as per BSpec.
Note that the CDCLK initialization/uninitialization are done at their
current place only for simplicity, in a future patch - when more of the
runtime PM features will be enabled - these will be moved to power
well#1 and modeset encoder enabling/disabling hooks respectively. This
also means that atm dynamic power gating power well #1 is effectively
disabled.
The call to uninitialize CDCLK during system/runtime suspend will be
added later in this patchset.
v1: Added function definitions in header files
v2: Imre's review comments addressed
- Moved CDCLK related definitions to i915_reg.h
- Removed defintions for CDCLK frequency
- Split uninit_cdclk() by adding a phy_uninit function
- Calculate freq and decimal based on input frequency
- Program SSA precharge based on input frequency
- Use wait_for 1ms instead 200us udelay for DE PLL locking
- Removed initial value for divider, freq, decimal, ratio.
- Replaced polling loops with wait_for
- Parameterized latency optim setting
- Fix the parts where DE PLL has to be disabled.
- Call CDCLK selection from mode set
v3: (imre)
- add note about the plan to move the cdclk/phy init to a better place
- take rps.hw_lock around pcode access
- move DE PLL register macros here from another patch since they are
used here first
- add BXT_ prefix to CDCLK flags
- add missing masking when programming CDCLK_FREQ_DECIMAL
v4: (ville)
- split the CDCLK/PHY parts into two patches, update commit message
accordingly
- s/DISPLAY_PCU_CONTROL/HSW_PCODE_DE_WRITE_FREQ_REQ/
- simplify BXT_DE_PLL_RATIO macros
- fix BXT_DE_PLL_RATIO_MASK
- s/bxt_select_cdclk_freq/broxton_set_cdclk_freq/
- move cdclk init/uninit/set code from intel_ddi.c to intel_display.c
- remove redundant code comments for broxton_set_cdclk_freq()
- sanitize fixed point<->integer frequency value conversion
- use DRM_ERROR instead of WARN
- do RMW when programming BXT_DE_PLL_CTL for safety
- add note about PLL lock timeout being exactly 200us
- make PCU error messages more descriptive
- instead of using 0 freq to mean PLL off/bypass freq use 19200
for clarity, as the latter one is the actual rate
- simplify pcode programming, removing duplicated
sandybridge_pcode_write() call
- sanitize code flow, remove unnecessary scratch vars in
broxton_set_cdclk() (imre)
- Remove bound check for maxmimum freq to match current code.
This check will be added later at a more proper platform
independent place once atomic support lands.
- add note to remove freq guard band which isn't needed on BXT
- add note to reduce freq to minimum if no pipe is enabled
- combine broxton_modeset_global_pipes() with
valleyview_modeset_global_pipes()
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rename vlv_cdclk_freq to cdclk_freq so that it can be used for all
platforms as required. Needed by the next patch.
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must be held without that lock.
This is a simplified version of the identically named patch by Chris Wilson.
Regression from commit ab8d66752a
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Mon Feb 2 15:44:15 2015 +0000
drm/i915: Track old framebuffer instead of object
v2: Bikeshedding.
References: https://bugs.freedesktop.org/show_bug.cgi?id=89166
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Separate topic branch for bxt didn't work out since we needed to
refactor the gmbus code a bit to make it look decent. So backmerge.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The port detection register flags in SFUSE_STRAP and DDI_BUF_CTL_A are
not defined for BXT, so don't use them.
Suggested by Satheesh.
v2:
- DDI_BUF_CTL_A bit 0 is not useful on BXT. Making changes to use this
bit when simulator or BXT is not applicable. Code re-arranged as per
Damien's suggestion.
v3:
- clarify commit message, add code comment (imre)
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2)
Cc: M, Satheeshakrishna <satheeshakrishna.m@intel.com>
Cc: Lespiau, Damien <damien.lespiau@intel.com>
Cc: Shankar, Uma <uma.shankar@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Connector states were being allocated in intel_setup_outputs() in loop
over all connectors. That meant hot-added connectors would have a NULL
state. Since the change to use a struct drm_atomic_state for the legacy
modeset, connector states are necessary for the i915 driver to function
properly, so that would lead to oopses.
Broken by
commit 944b0c7657
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Fri Mar 20 16:18:07 2015 +0200
drm/i915: Copy the staged connector config to the legacy atomic state
v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Enabling skylake panel fitting feature using shared scalers
v2:
-added force detach parameter for pfit disable purpose (me)
-read crtc scaler state from hw state (Daniel)
-replaced both skylake_pfit_enable and disable with skylake_pfit_update (me)
-added scaler id check to intel_pipe_config_compare (Daniel)
v3:
-updated function header to kerneldoc format (Matt)
-dropped need_scaling checks (Matt)
v4:
-move clearing of scaler id from commit path to check path (Matt)
-updated colorkey checks based on recent updates (me)
-squashed scaler check while enabling colorkey to here (me)
-use values in plane_state->src as regular integers (me)
-changes made not to modify state in commit path (Matt)
v5:
-squashed helper function to update scaler users to here (Matt)
-squashed helper function to detach scaler to here (Matt, me)
-changes to align with updated scaler structures (Matt, me)
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Added intel_atomic_setup_scalers to setup scalers based on
staged scaling requests from a crtc and its planes. If staged
requests are supportable, this function assigns scalers to
requested planes and crtc. Note that the scaler assignement
itself is staged into crtc_state and respective plane_states
for later commit after all checks have been done.
overall high level flow:
- scaler requests are staged into crtc_state by planes/crtc
- check whether staged scaling requests can be supported
- add planes using scalers that aren't in current transaction
- assign scalers to requested users
- as part of plane commit, scalers will be committed
(i.e., either attached or detached) to respective planes in hw
- as part of crtc_commit, scaler will be either attached or detached
to crtc in hw
crtc_compute_config calls intel_atomic_setup_scalers() to start
scaler assignments as per scaler state in crtc config. This call
should be moved to atomic crtc once it is available.
v2:
-removed a log message (me)
-changed input parameter to crtc_state (me)
v3:
-remove assigning plane_state returned by drm_atomic_get_plane_state (Matt)
-fail if there is an error from drm_atomic_get_plane_state (Matt)
v4:
-changes to align with updated scaler structure (Matt, me)
v5:
-added addtional checks before enabling HQ mode (me)
-added comments to enable HQ mode (Matt)
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
crtc_state is cleared during mode set which wipes out complete
scaler state too. This is causing issues. To fix, ensure scaler
state is preserved because it contains not only crtc
scaler usage, but also planes using scalers on this crtc.
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dumps scaler state as part of dumping crtc_state.
v2:
-use regular ints from plane_state->src (me)
v3:
-changes to align with updated scaler structures (Matt)
-interpret plane_state->src as 16.16 format (Matt, Daniel)
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Initializing scalers with supported values during crtc init.
v2:
-initialize single copy of min/max values (Matt)
v3:
-moved gen check to callsite (Matt)
v4:
-squashed planes begin with no scaler to here (me)
v5:
-updated init function with updated scaler state structure (Matt)
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch initializes plane colorkey to NONE.
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Connector states were being allocated in intel_setup_outputs() in loop
over all connectors. That meant hot-added connectors would have a NULL
state. Since the change to use a struct drm_atomic_state for the legacy
modeset, connector states are necessary for the i915 driver to function
properly, so that would lead to oopses.
v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_* for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the following commit, the PLL calculations are done earlier, so
the code following the comment doesn't do anything PLL or encoder
related. It only updates the primary plane now.
commit f3019a4d92
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Wed Oct 29 11:32:37 2014 +0200
drm/i915: Remove crtc_mode_set() hook
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Switch from our plane update/disable entrypoints to use the full atomic
helpers (which generate a top-level atomic transaction) rather than the
transitional helpers (which only create/manipulate orphaned plane states
independent of a top-level transaction). Various upcoming work (SKL
scalers, atomic watermarks, etc.) requires a full atomic transaction to
behave properly/cleanly.
Last time we tried this, we had to back out the change because we still
call the drm_plane vfuncs directly from within our legacy modesetting
code. This potentially results in nested atomic transactions, locking
collisions, and other failures. To avoid that problem again, we
sidestep the issue by calling the transitional helpers directly (rather
than through a vfunc) when we're nested inside of other legacy
modesetting code. However this does allow legacy SetPlane() ioctl's to
process an entire drm_atomic_state transaction, which is important for
upcoming patches.
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we hit a vblank and see that have a pageflip queue but not yet
processed, ensure that the GPU is running at maximum in order to clear
the backlog. Pageflips are only queued for the following vblank, if we
miss it, there will be a visible stutter. Boosting the GPU frequency
doesn't prevent us from missing the target vblank, but it should help
the subsequent frames hitting theirs.
v2: Reorder vblank vs flip-complete so that we only check for a missed
flip after processing the completion events, and avoid spurious boosts.
v3: Rename missed_vblank
v4: Rebase
v5: Cancel the outstanding work in runtime suspend
v6: Rebase
v7: Rebase required fixing
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Deepak S<deepak.s@linux.intel.com>
Reviewed-by: Deepak S<deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we emit semaphore synchronisation as if we were going to flip
using the target CS engine, but we then change our minds and do the flip
using the CPU. Consequently we write instructions to the ring but never
use them - even to the point of filling that ring up entirely and never
submitting a request.
The wrinkle in the ointment is that we have to tell a white lie to
pin-to-display for it to skip the synchronisation for mmioflips as we
will create a task specifically for that slow synchronisation. An oddity
of note is the discrepancy in requests that we tell to pin-display to
serialise to and that we then eventually wait upon. This is due to a
limitation in the i915_gem_object_sync() routine that will be lifted
later.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reduce dependency on the staged config by using the atomic state
instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reduce dependency on the staged config by using the atomic state
instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's not needed anymore, now that all the users were converted to using
an atomic state.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move towards atomic by using the atomic state instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we use a drm atomic state for the legacy modeset, it is
possible to get rid of the usage of intel_crtc->new_config in the
function intel_mode_max_pixclk().
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The best_encoder field of connector_state wasn't properly set when a
connector was being disabled, leading to an incosistent atomic state.
For now, this doesn't cause anything to blow up, because everywhere
we're using connector_state->best_encoder there is a check for
connector_state->crtc which is properly initialized. I reached the issue
while testing some patches I haven't sent out yet, that remove the usage
of intel_connector->new_encoder from check_digital_port_conflicts(). In
that case, it would be possible to trigger the converted version of the
WARN in that function.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Add commit message augmentation Ander supplied.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unify the HSW/BDW/SKL cdclk extraction code to conform to the same
.get_display_clock_speed() mold that all the other platforms
use.
v2: Update due to SKL code getting added
v3: Rebase on top of -nightly (introduction of intel_audio.c) (Mika Kahola)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Add v3 note as suggested by Damien.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't currently have cdclk extraction code for 965g,snb,ivb.
Let's assume 400 MHz until we know better. That seems to match hints
in various vague documents. Whether that's good enough is not
entirely clear.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on the BIOS DP A AUX 2x clock divider the cdclk frequency
on ILK is 450Mhz. At least that holds on my ILK and it matches
how we program the divider.
Supposedly cdclk is 400MHz on SNB and IVB, again based on the AUX 2x
clock divider. Note that I don't have a SNB or IVB machine with
eDP so I couldn't verify what the BIOS used, so this notion is
purely based on our current code,
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fill out the lower three digits for gen2 and gen3 cdclk frqeuncy. It's
not clear if these are accurate frquencies or just in the ballpark, but
without docs this is the best we can do.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Makes that code atomic ready.
v2: Acquire crtc_state for the "other" pipe only when needed. (Daniel)
v3: Really only acquire the other state if necessary. (Daniel)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The return value of one of the calls to drm_atomic_get_connector_state()
in intel_modeset_stage_output_state() wasn't checked for errors.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To allow for views where the view type is not defined by the view type only,
like it is in stereo or rotated 90 degree view, change the semantic to require
the whole view structure for comparison when we match a GGTT view.
This allows including parameters like offset to be included in the view which
is useful for eg. partial views.
v3:
- Rely on ggtt_view type being 0 for non-GGTT vma's, which equals to
I915_GGTT_VIEW_NORMAL. (Daniel Vetter)
- Do not use potentially slower comparison when we only want to know if
something is or is not a normal view.
- Rebase on top of rotated view patches. Add rotated view singleton.
- If one view is missing in comparison they're equal only if both are missing.
v4:
- Use comparison helper in obj_to_ggtt_view too. (Tvrtko Ursulin)
- Do WARN_ON if one view is NULL. (Tvrtko Ursulin)
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some of the crtc_compute_clock() still depended on encoder->new_crtc
since they didn't use intel_pipe_will_have_type() and used an open
coded version of that function instead. This patch replaces those with
the appropriate code that checks the atomic state intead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Separate the if (!connector) continue to facility easier
extraction of a loop iterator for all of these (there's lots more in
i915 and atomic helpers).]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pass a crtc_state to it and find whether the pipe has an encoder of a
given type by looking at the drm_atomic_state the crtc_state points to.
Until recently i9xx_get_refclk() used to be called indirectly from
vlv_force_pll_on() with a dummy crtc_state. That dummy crtc state is not
converted to be part of a full drm atomic state, so add a WARN in case
someone decides to call that again with a such dummy state. This was
removed in
commit 9cbe40c15a
Author: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Date: Thu Mar 5 19:33:08 2015 +0530
drm/i915: Update prop, int co-eff and gain threshold for CHV
v2: Warn if there is no connectors for a given crtc. (Daniel)
Replace comment i9xx_get_refclk() with a WARN_ON(). (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Add commit reference for when i9xx_get_refclk was removed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Follow up patches will convert some functions called from there to use
the atomic state, instead of directly accessing the new or current
config. This patch just changes the parameters, but shouldn't have any
functional changes.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Keep the if (!connector) continue; separate so that it's
easier to eventually extract a for_each_connector_in_state iterator.
And because of the upcast it's also safer.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move towards atomic by using the legacy modeset's drm_atomic_state
instead.
v2: Move call to drm_atomic_add_affected_connectors() to
intel_modeset_compute_config(). (Daniel)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Resurrect the ret local variable which I've dropped from an
earlier patch and which is now needed.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this in place, we can start converting pieces of the modeset code
to look at the connector atomic state instead of the staged config.
v2: Handle the load detect staged config changes too. (Ander)
Remove unnecessary blank line. (Daniel)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Keep that state updated so that we can write code that depends on it on
the follow up patches.
v2: Fix BUG due to stale connector_state->crtc value. (Chandra)
v3: Update comment about dummy state connectors. (Chandra)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For consistency, allocate a new crtc_state for a crtc that is being
disabled. Previously only the enabled value of the current state would
change.
v2: Rebase on v5 of previous patch. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Resolve rebase conflict.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For the atomic conversion, the mode set paths need to be changed to rely
on an atomic state instead of using the staged config. By using an
atomic state for the legacy code, we will be able to convert the code
base in small chunks.
v2: Squash patch that adds stat argument to intel_set_mode(). (Ander)
Make every caller of intel_set_mode() allocate state. (Daniel)
Call drm_atomic_state_clear() in set config's error path. (Daniel)
v3: Copy staged config to atomic state in force restore path. (Ander)
v4: Don't update ->new_config for disabled pipes in __intel_set_mode(),
since it is expected to be NULL in that case. (Ander)
v5: Don't change return type of intel_modeset_pipe_config(). (Chandra)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Remove spurious ret local variable due to changes in v5.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now this is not necessary since intel_set_mode() doesn't acquire any
new locks. However, once that function is converted to atomic, that will
change, since we'll pass an atomic state to it, and that needs to have
the right acquire context set.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we only set preserve_bios_swizzling when the initial fb is
shared and totally miss the single-screen case. Fix this by
consolidating all the logic for both cases.
This seems to go back to when swizzle preservation was originally
merged in
commit d9ceb81633
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Oct 9 12:57:43 2014 -0700
drm/i915: preserve swizzle settings if necessary v4
Cc: Kristian Høgsberg <hoegsberg@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
In spirit with
commit 5724dbd167
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Tue Jan 20 12:51:52 2015 +0000
drm/i915: Rename plane_config to initial_plane_config
to make it clear that this code is all special-purpose for the initial
plane takeover.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This is a very similar bug in the load detect code fixed in
commit 9128b040eb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Mar 3 17:31:21 2015 +0100
drm/i915: Fix modeset state confusion in the load detect code
But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This flag was being mostly used as a meta flag in some
cases and not covering other cases.
One of the risks is that it was masking some frontbuffer
trackings without disabling PSR.
So, better to kill this at once and avoid umbrella parameters.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Drop unused out: label to appease gcc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Or users can just spam the log all they want.
Issue introduced in
commit 9a8f0a1290
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Fri Feb 27 11:15:24 2015 +0000
drm/i915/skl: Allow Y (and Yf) frame buffer creation
References: https://bugs.freedesktop.org/show_bug.cgi?id=89628
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Pass in rotation info to sprite plane updates as well.
v3: Use helper to determine 90/270 rotation. (Michel Thierry)
v4: Rebased for fb modifiers and atomic changes.
For: VIZ-4546
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v3)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Need to do this in order to support 90/270 rotated display.
v2: Pass in drm_plane instead of plane index to intel_obj_display_address.
v3:
* Renamed intel_obj_display_address to intel_plane_obj_offset.
(Chris Wilson)
* Simplified rotation check to bitwise AND. (Chris Wilson)
v4:
* Extracted 90/270 rotation check into a helper function. (Michel Thierry)
v5:
* Rebased for ggtt view changes.
For: VIZ-4545
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
90/270 rotated scanout needs a rotated GTT view of the framebuffer.
This is put in a separate VMA with a dedicated ggtt view and wired such that
it is created when a framebuffer is pinned to a 90/270 rotated plane.
Rotation is only possible with Yb/Yf buffers and error is propagated to
user space in case of a mismatch.
Special rotated page view is constructed at the VMA creation time by
borrowing the DMA addresses from obj->pages.
v2:
* Do not bother with pages for rotated sg list, just populate the DMA
addresses. (Daniel Vetter)
* Checkpatch cleanup.
v3:
* Rebased on top of new plane handling (create rotated mapping when
setting the rotation property).
* Unpin rotated VMA on unpinning from display plane.
* Simplify rotation check using bitwise AND. (Chris Wilson)
v4:
* Fix unpinning of optional rotated mapping so it is really considered
to be optional.
v5:
* Rebased for fb modifier changes.
* Rebased for atomic commit.
* Only pin needed view for display. (Ville Syrjälä, Daniel Vetter)
v6:
* Rebased after preparatory work has been extracted out. (Daniel Vetter)
v7:
* Slightly simplified tiling geometry calculation.
* Moved rotated GGTT view implementation into i915_gem_gtt.c (Daniel Vetter)
v8:
* Do not use i915_gem_obj_size to get object size since that actually
returns the size of an VMA which may not exist.
* Rebased for ggtt view changes.
v9:
* Rebased after code review changes on the preceding patches.
* Tidy function definitions. (Joonas Lahtinen)
For: VIZ-4726
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v4)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For now only default implementation defaulting to normal view.
v2: Some code review cleanups. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Plane state carries the rotation information which is needed for determining
the appropriate GGTT view type.
This just adds the parameter with the actual usage coming in future patches.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To support frame buffer rotation we need to be able to pass on the information
on what kind of GGTT view is required for display.
This patch just adds the parameter and makes all the callers default to the
normal view.
v2: Rebased for ggtt view changes.
v3: Don't limit PIN_MAPPABLE to normal views just yet. (Joonas Lahtinen)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v3)
[danvet: s/BUG/WARN/ in the patch hunk because. At least where the
BUG_ON isn't fatal right away.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It will be used in a later patch and also convert all height parameters
from int to unsigned int.
v2: Rebased for fb modifiers.
v3: Fixed v2 rebase.
v4:
* Height should be unsigned int.
* Make it take pixel_format for consistency and simplicity.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com> (v1)
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (v4)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prepare chv_find_best_dpll to be used for BXT too, where we want to
consider the error between target and calculated frequency too when
choosing a better PLL configuration.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Factor out the logic to decide whether the newly calculated dividers are
better than the best found so far. Do this for clarity and to prepare
for the upcoming BXT helper needing the same.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
Backmerge because of numerous and interleaving conflicts and git
rerere getting confused a bit too often.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
All conflicts are because of -next patches backported to -fixes, so
just go with the code in -next.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
We don't want to end up in a state where we track that the pipe has its
primary plane enabled when primary plane registers are programmed with
values that look possible but the plane actually disabled.
Refuse to read out the fb state when the primary plane isn't enabled.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Matt Roper <matthew.d.roper@intel.com>
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>
Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Reported-by: Steven Rostedt <rostedt@goodmis.org>
Reference: http://mid.gmane.org/20150203191507.GA2374@crion86
Tested-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We accidentally pass 'pipe' instead of 'port' to CHV_PLL_DW8() and
with PIPE_C we end up at register offset 0x8320 which isn't the
0x8020 we wanted. Fix it.
The problem was fortunately caught by the sanity check in vlv_dpio_read():
WARNING: CPU: 1 PID: 238 at ../drivers/gpu/drm/i915/intel_sideband.c:200 vlv_dpio_read+0x77/0x80 [i915]()
DPIO read pipe C reg 0x8320 == 0xffffffff
The problem got introduced with this commit:
commit 71af07f91f12bbab96335e202c82525d31680960
Author: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Date: Thu Mar 5 19:33:08 2015 +0530
drm/i915: Update prop, int co-eff and gain threshold for CHV
Cc: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ignore the current state of the pipe and just check crtc_state->enable
and the number of FDI lanes required. This means we don't accidentally
mistake the FDI lanes as being available of one of the pipes just
happens to be disabled at the time of the check. Also we no longer
consider pipe C to require FDI lanes when it's driving the eDP
transcoder.
We also take the opportunity to make the code a bit nicer looking by
hiding the ugly bits in the new pipe_required_fdi_lanes() function.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The logic in the FDI lane checks is very hard for my poor brain to
grasp. Rewrite it in a more straightforward way.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remove the global modeset resource function that would disable the
bifurcation bit, and instead enable/disable it when enabling the pch
transcoder. The mode set consistency check should prevent us from
disabling the bit if pipe C is enabled so the change should be safe.
Note that this doens't affect the logic that prevents the bit being
set while a pipe is active, since the patch retains the behavior of
only chaging the bit if necessary. Because of the checks during mode
set, the first change would necessarily happen with both pipes B and
C disabled, and any subsequent write would be skipped.
v2: Only change the bit during pch trancoder enable. (Ville)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No need to go dig throguh intel_crtc->base.cursor when we already have
the same thing as 'plane' local variable.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These are now called from the plane commit hooks, so they really need to
be fast or else we risk atomic update failures. So kill the debug prints
which are slowing things down massively.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_user_framebuffer_destroy() requires the struct_mutex for its
object bookkeeping, so this means that all calls to
drm_framebuffer_unreference must not hold that lock.
Regression from commit ab8d66752a
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Mon Feb 2 15:44:15 2015 +0000
drm/i915: Track old framebuffer instead of object
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89166
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
[danvet: Clarify commit message slightly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PFI credit programming is required when CD clock (related to data flow from
display pipeline to end display) is greater than CZ clock (related to data
flow from memory to display plane). This programming should be done when all
planes are OFF to avoid intermittent hangs while accessing memory even from
different Gfx units (not just display).
If cdclk/czclk >=1, PFI credits could be set as any number. To get better
performance, larger PFI credit can be assigned to PND. Otherwise if
cdclk/czclk<1, the default PFI credit of 8 should be set.
v2:
- Change log to lower log level instead of DRM_ERROR
- Change function name to valleyview_program_pfi_credits
- Move program PFI credits to modeset_init instead of intel_set_mode
- Change magic numbers to logical constants
[vsyrjala v3:
- only program in response to cdclk update
- program the credits also when cdclk<czclk
- add CHV bits
v4:
- Change CHV cdclk<czclk credits to 12 (Vijay)]
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch implements latest PHY changes in Gain, prop and int co-efficients
based on the vco freq.
v2: Split the original changes into multiple smaller patches based on
review by Ville
v3: Addressed Ville's review comments. Fixed the error introduced in v2.
Clear the old bits before we modify those bits as part of RMW.
v4: TDC target cnt is 10 bits and not 8 bits (Ville)
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Initialize lock detect threshold and select coarse threshold for the
case where M2 fraction division is disabled.
v2: Split the changes into multiple smaller patches (Ville)
v3: Clear out the old bits before we modify those bits as RMW (Ville)
v4: Reset coarse threshold when M2 fraction is enabled (Ville)
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2 : Handle M2 frac division for both M2 frac and int cases
v3 : Addressed Ville's review comments. Cleared the old bits for RMW
v4 : Fix feedfwd gain (Ville)
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the switch to atomic plumbing for planes, some of our commit-time
work (e.g., watermarks) is done after the new atomic state is swapped
into the relevant DRM object, but before the DRM core has a chance to
update its legacy state values. Switch intel_crtc_active() to look at
the state objects rather than legacy fields to ensure we operate on the
proper values.
Note that we're continuing to use intel_crtc->active here for the time
being since crtc->state isn't really hooked up yet. Once CRTC states
are wired up properly, we'll want to switch this over to use
crtc->state->active instead.
v2: Switch back to intel_crtc->active for now; when Ander's work on CRTC
states is ready, we can flip this over to use crtc->state->active
instead. (Ville)
Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com>
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The specs seem to be full of misinformation wrt. the Punit register
0x36. Some versions still show the old VLV bit layout, some the new
layout, and all of them seem to tell us nonsense about the cdclk
value encoding.
Testing on actual hardware has shown that we simply need to program
the desired CCK divider into the Punit register using the new layout of
the bits. Doing that, the status bit change to indicate the same value,
and the CCK 0x6b register also changes accordingly to indicate that CCK
is now using the new divider.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Supposedly CHV can sustain a pixel clock of up to 95% of
cdclk, as opposed to the 90% limit that was used old older
platforms. Update the cdclk selection code to allow for this.
This will allow eg. HDMI 4k modes with their 297MHz pixel clock
while still respecting the 320 MHz cdclk limit on CHV.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Reviewed-by: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So try to enumerate eDP unconditionally in those cases.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add wa tag Damien dug out.]
Reviewed-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>
We need to disable all sprite planes when disabling the CRTC. We had
been using the top-level atomic 'disable' entrypoint to accomplish this,
which was wrong. Not only can this lead to various locking issues, it
also modifies the actual plane state, making it impossible to restore
the plane properly later. For example, a DPMS off followed by a DPMS on
will result in any sprite planes in use not being restored properly.
The proper solution here is to call directly into our 'commit plane'
hook with a copy of the plane's current state that has 'visible' set to
false. Committing this dummy state will turn off the plane, but will
not touch the actual plane->state pointer, allowing us to properly
restore the plane state later.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When logging that full mode switch is necessary, log which connector,
encoder or crtc has caused it, so it is easier to figure out what is
goind on by just looking at the log.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have similar macros for crtcs and encoders, and the pattern happens
often enough to justify the macro.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current minimum vco frequency leaves us with a gap in our supported
frequencies at 233-243 MHz. Your typical 2560x1440@60 display wants a
pixel clock of 241.5 MHz, which is just withing that gap. Reduce the
allowed vco min frequency to 4.8GHz to reduce the gap to 233-240 MHz,
and thus allow such displays to work.
4.8 GHz is actually the documented (at least in some docs) limit of the
PLL, and we just picked 4.86 GHz originally because that was the lowest
value produced by the PLL spreadsheet, which obviously didn't consider
2560x1440 displays.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Vijay Purushothaman <vijay.a.purushothaman@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 3f678c96ab.
We've been a bit too optimistic with this one here :(
The trouble is that internally we're still using these plane
update/disable hooks. Which was totally ok pre-atomic since the drm
core did all the book-keeping updating and these just mostly updated
hw state. But with atomic there's lots more going on, and it causes
heaps of trouble with the load detect code.
This one specifically cause a deadlock since both the load detect code
and the nested plane atomic helper functions tried to grab the same
locks. It only blows up because of the evil tricks though we play with
the implicit ww acquire context.
Applying this revert unearths the NULL deref on already freed
framebuffer objects reported as a regression in 4.0 by various people.
Fixing this will be fairly invasive, hence revert even for the
4.1-next queue.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Implicit usage of local variables in macros isn't exactly the greatest
thing in the world, especially when that variable is the drm device and
we want to move towards a broader use of the i915 device structure.
Let's make for_each_sprite() take dev_priv as its first argument then.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Implicit usage of local variables in macros isn't exactly the greatest
thing in the world, especially when that variable is the drm device and
we want to move towards a broader use of the i915 device structure.
Let's make for_each_plane() take dev_priv as its first argument then.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris-wilson.co.uk>
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>
plane->state->fb and plane->fb should always reference the same FB so
that atomic and legacy codepaths have the same view of display state.
However, there are some places in kernel code that directly set
plane->fb and neglect to update plane->state->fb. If we never do a
successful update through the atomic pipeline, the RmFB cleanup code
will look at the plane->state->fb pointer, which has never actually
been set to a legitimate value, and try to clean it up, leading to
BUG's.
Add a quick helper function to synchronize plane->state->fb with
plane->fb and call it everywhere the driver tries to manually set
plane->fb outside of the atomic pipeline. In this function, use
drm_atomic_set_fb_for_plane instead of writing plane->state->fb
directly to keep the reference count right.
This is modified from Matt Roper's patch to drm-intel-nightly with
commit id
commit afd65eb4cc
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Feb 3 13:10:04 2015 -0800
drm/i915: Ensure plane->state->fb stays in sync with plane->fb
However this bug exists in mainline kernel too, so I created this to fix
it in mainline kernel.
A minor change is to use drm_atomic_set_fb_for_plane instead of update
reference count manually.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93711
Signed-off-by: Xi Ruoyao <xry111@outlook.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
[Jani: included the patch notes in the commit message]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The kernel in_irq() function tests for hard-IRQ context only, so if a
system is run with the kernel 'threadirqs' option selected, the test in
intel_check_page_flip() generates lots of warnings, because then it gets
called in soft-IRQ context.
We can instead use in_interrupt() which allows for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
commit a8c6ecb3be
Merge: 8dd0eb359eccca0
Author: Dave Airlie <airlied@redhat.com>
Date: Mon Mar 9 19:58:30 2015 +1000
Merge tag 'v4.0-rc3' into drm-next
managed to pick the wrong code to resolve the conflict and left us with
a mutex_lock(struct_mutex) without the mutex_unlock(struct_mutex) leading
to a deadlock. Fix the problem by recovering the correct code which doesn't
need the lock.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJU/NacAAoJEHm+PkMAQRiGdUcIAJU5dHclwd9HRc7LX5iOwYN6
mN0aCsYjMD8Pjx2VcPCgJvkIoESQO5pkwYpFFWCwILup1bVEidqXfr8EPOdThzdh
kcaT0FwUvd19K+0jcKVNCX1RjKBtlUfUKONk6sS2x4RrYZpv0Ur8Gh+yXV8iMWtf
fAusNEYlxQJvEz5+NSKw86EZTr4VVcykKLNvj+/t/JrXEuue7IG8EyoAO/nLmNd2
V/TUKKttqpE6aUVBiBDmcMQl2SUVAfp5e+KJAHmizdDpSE80nU59UC1uyV8VCYdM
qwHXgttLhhKr8jBPOkvUxl4aSXW7S0QWO8TrMpNdEOeB3ZB8AKsiIuhe1JrK0ro=
=Xkue
-----END PGP SIGNATURE-----
Merge tag 'v4.0-rc3' into drm-next
Linux 4.0-rc3 backmerge to fix two i915 conflicts, and get
some mainline bug fixes needed for my testing box
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/intel_display.c
- 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>
This is a tricky story of the new atomic state handling and the legacy
code fighting over each another. The bug at hand is an underrun of the
framebuffer reference with subsequent hilarity caused by the load
detect code. Which is peculiar since the the exact same code works
fine as the implementation of the legacy setcrtc ioctl.
Let's look at the ingredients:
- Currently our code is a crazy mix of legacy modeset interfaces to
set the parameters and half-baked atomic state tracking underneath.
While this transition is going we're using the transitional plane
helpers to update the atomic side (drm_plane_helper_disable/update
and friends), i.e. plane->state->fb. Since the state structure owns
the fb those functions take care of that themselves.
The legacy state (specifically crtc->primary->fb) is still managed
by the old code (and mostly by the drm core), with the fb reference
counting done by callers (core drm for the ioctl or the i915 load
detect code). The relevant commit is
commit ea2c67bb4a
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Dec 23 10:41:52 2014 -0800
drm/i915: Move to atomic plane helpers (v9)
- drm_plane_helper_disable has special code to handle multiple calls
in a row - it checks plane->crtc == NULL and bails out. This is to
match the proper atomic implementation which needs the crtc to get
at the implied locking context atomic updates always need. See
commit acf24a395c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Jul 29 15:33:05 2014 +0200
drm/plane-helper: transitional atomic plane helpers
- The universal plane code split out the implicit primary plane from
the CRTC into it's own full-blown drm_plane object. As part of that
the setcrtc ioctl (which updated both the crtc mode and primary
plane) learned to set crtc->primary->crtc on modeset to make sure
the plane->crtc assignments statate up to date in
commit e13161af80
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Apr 1 15:22:38 2014 -0700
drm: Add drm_crtc_init_with_planes() (v2)
Unfortunately we've forgotten to update the load detect code. Which
wasn't a problem since the load detect modeset is temporary and
always undone before we drop the locks.
- Finally there is a organically grown history (i.e. don't ask) around
who sets the legacy plane->fb for the various driver entry points.
Originally updating that was the drivers duty, but for almost all
places we've moved that (plus updating the refcounts) into the core.
Again the exception is the load detect code.
Taking all together the following happens:
- The load detect code doesn't set crtc->primary->crtc. This is only
really an issue on crtcs never before used or when userspace
explicitly disabled the primary plane.
- The plane helper glue code short-circuits because of that and leaves
a non-NULL fb behind in plane->state->fb and plane->fb. The state
fb isn't a real problem (it's properly refcounted on its own), it's
just the canary.
- Load detect code drops the reference for that fb, but doesn't set
plane->fb = NULL. This is ok since it's still living in that old
world where drivers had to clear the pointer but the core/callers
handled the refcounting.
- On the next modeset the drm core notices plane->fb and takes care of
refcounting it properly by doing another unref. This drops the
refcount to zero, leaving state->plane now pointing at freed memory.
- intel_plane_duplicate_state still assume it owns a reference to that
very state->fb and bad things start to happen.
Fix this all by applying the same duct-tape as for the legacy setcrtc
ioctl code and set crtc->primary->crtc properly.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Paul Bolle <pebolle@tiscali.nl>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
By this patch all underlying bits have been implemented and this
patch actually enables the feature.
v2: Validate passed in fb modifiers to reject garbage. (Daniel Vetter)
v3: Rearrange validation checks per code review comments. (Daniel Vetter)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
We now need the bpp of the fb as Yf tiling has different tile widths
depending on it.
v2: Rebased for the new addfb2 interface. (Tvrtko Ursulin)
v3: Rebased for fb modifier changes. (Tvrtko Ursulin)
v4: Added missing case and 128-bit pixel warning. (Damien Lespiau)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> (v3)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
