Since we now have the bigjoiner_pipes bitmask the boolean
is redundant. Get rid of it.
Also, populating bigjoiner_pipes already during
encoder->compute_config() allows us to use it much earlier
during the state calculation as well. The initial aim is
to use it in intel_crtc_compute_config().
v2: Move the hweight(bigjoiner_pipes) stuff to a later patch
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> #v1
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-12-ville.syrjala@linux.intel.com
Instead of just having the pipe_src_{w,h} let's use a full
drm_rect for it. This will be particularly useful to astract
away some bigjoiner details.
v2: No hweight() stuff yet
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-11-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Now that we track framestart_delay in the crtc state with readout
and state checker support we can remove the explicit framestart_delay
sanitation code.
Also I'm not convinced reprogramming this while the pipe is running
is even valid. CHICKEN_TRANS (hsw+) and TRANS_CHICKEN2 (cpt+) docs
at least make no mention of double buffering which seems to imply
that live reprogramming is not supported. On older platforms
PIPECONF and PCH_TRANSCONF (ibx) are double buffered though, so
might be that we could do this on the older platforms. But doesn't
really make sense to special case old platforms for this.
So from now on if the BIOS has misprogrammed this we shall simply do
a full modeset at boot to fix it up. Such systems will of course lose
fastboot, but I think less code (and less uncertainty what
reprogramming this on a running pipe will even do) outweighs that.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221110356.5532-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We need to make framestart_delay dynamic for DRRS on PCH
ports. To that end move it into the crtc state. As a bonus
we get state check+dump for it. Will also allow us to get
rid of the somewhat questionable framestart_delay sanitation
code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220221110356.5532-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The current implementation of the async flip wm0/ddb optimization
does not work at all. The biggest problem is that we skip the
whole intel_pipe_update_{start,end}() dance and thus never actually
complete the commit that is trying to do the wm/ddb change.
To fix this we need to move the do_async_flip flag to the crtc
state since we handle commits per-pipe, not per-plane.
Also since all planes can now be included in the first/last
"async flip" (which gets converted to a sync flip to do the
wm/ddb mangling) we need to be more careful when checking if
the plane state is async flip comptatible. Only planes doing
the async flip should be checked and other planes are perfectly
fine not adhereing to any async flip related limitations.
However for subsequent commits which are actually going do the
async flip in hardware we want to make sure no other planes
are in the state. That should never happen assuming we did our
job correctly, so we'll toss in a WARN to make sure we catch
any bugs here.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: c3639f3be4 ("drm/i915: Use wm0 only during async flips for DG2")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Since the async flip state check is done very late and
thus it can see potentially all the planes in the state
(due to the wm/ddb optimization) we need to move the
"can the requested plane do async flips at all?" check
much earlier. For this purpose we introduce
intel_async_flip_check_uapi() that gets called early during
the atomic check.
And for good measure we'll throw in a couple of basic checks:
- is the crtc active?
- was a modeset flagged?
- is+was the plane enabled?
Though atm all of those should be guaranteed by the fact
that the async flip can only be requested through the legacy
page flip ioctl.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Fixes: c3639f3be4 ("drm/i915: Use wm0 only during async flips for DG2")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220214105532.13049-3-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Remove the local onoff() implementation and adopt the
str_on_off() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-4-lucas.demarchi@intel.com
Remove the local enableddisabled() implementation and adopt the
str_enabled_disabled() from linux/string_helpers.h.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-3-lucas.demarchi@intel.com
Remove the local yesno() implementation and adopt the str_yes_no() from
linux/string_helpers.h.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-1-lucas.demarchi@intel.com
When calculating pipe_mode and when doing readout we need
to order our steps correctly.
1. We start with adjusted_mode crtc timings being populated
with the transcoder timings (either via readout or
compute_config(). These will be per-segment for MSO.
2. For all other uses we want the full crtc timings so
we ask intel_splitter_adjust_timings() to expand
the per-segment numbers to their full glory
3. If bigjoiner is used we the divide the full numbers
down to per-pipe numbers using intel_bigjoiner_adjust_timings()
During readout we also have to reconstruct the adjusted_mode
normal timings (ie. not the crtc_ stuff). These are supposed
to reflect the full timings of the display. So we grab these
between steps 2 and 3.
The "user" mode readout (mainly done for fastboot purposes)
should be whatever mode the user would have used had they
asked us to do a modeset. We want the full timings for this
as the per-segment timings are not suppoesed to be user visible.
Also the user mode normal timings hdisplay/vdisplay need to
match PIPESRC (that is where we get our PIPESRC size
we doing a modeset with a user supplied mode).
And we end up with
- adjusted_mode normal timigns == full timings
- adjusted_mode crtc timings == transcoder timings
(per-segment timings for MSO, full timings otherwise)
- pipe_mode normal/crtc timings == pipe timings
(full timings divided by the number of bigjoiner pipes, if any)
- user mode normal timings == full timings with
hdisplay/vdisplay replaced with PIPESRC size
- user mode crtc timings == full timings
Yes, that is a lot of timings. One day we'll try to remove
some of the ones we don't actually need to keep around...
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-10-ville.syrjala@linux.intel.com
Pull intel_crtc_compute_pipe_mode() out from
intel_crtc_compute_config(). Since it's semi related
we'll suck in the max dotclock/double wide checks in
as well.
And we'll pimp the debugs while at it.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-9-ville.syrjala@linux.intel.com
Do the s/dev_priv/i915/ and s/pipe_config/crtc_state/ renames
to intel_crtc_compute_config(). I want to start splitting this
up a bit and doing the renames now avoids spreading these old
nameing conventions elsewhere. No functional changes.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-5-ville.syrjala@linux.intel.com
bigjoiner_pipes==0 leads bigjoiner_master_pipe() to
do BIT(ffs(0)-1) which is undefined behaviour. The code should
actually still work fine since the only place we provoke
that is intel_crtc_bigjoiner_slave_pipes() and it'll bitwise
AND the result with 0, so doesn't really matter what we get
out of bigjoiner_master_pipe(). But best not provoke undefined
behaviour anyway.
Reported-by: kernel test robot <oliver.sang@intel.com>
Fixes: a6e7a006f5 ("drm/i915: Change bigjoiner state tracking to use the pipe bitmask")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Tile4 in bspec format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.
v2: - Moved Tile4 associating struct for modifier/display to
the beginning(Imre Deak)
- Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
checks(Imre Deak)
- Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
(Imre Deak)
v3: - Rebased patch on top of new changes related to plane_caps.
- Added static assert to check that PLANE_CTL_TILING_YF
matches PLANE_CTL_TILING_4(Nanley Chery)
- Fixed naming and layout description for Tile 4 in drm uapi
header(Nanley Chery)
v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery)
Reviewed-by: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-3-stanislav.lisovskiy@intel.com
UAPI Changes:
- Weak parallel submission support for execlists
Minimal implementation of the parallel submission support for
execlists backend that was previously only implemented for GuC.
Support one sibling non-virtual engine.
Core Changes:
- Two backmerges of drm/drm-next for header file renames/changes and
i915_regs reorganization
Driver Changes:
- Add new DG2 subplatform: DG2-G12 (Matt R)
- Add new DG2 workarounds (Matt R, Ram, Bruce)
- Handle pre-programmed WOPCM registers for DG2+ (Daniele)
- Update guc shim control programming on XeHP SDV+ (Daniele)
- Add RPL-S C0/D0 stepping information (Anusha)
- Improve GuC ADS initialization to work on ARM64 on dGFX (Lucas)
- Fix KMD and GuC race on accessing PMU busyness (Umesh)
- Use PM timestamp instead of RING TIMESTAMP for reference in PMU with GuC (Umesh)
- Report error on invalid reset notification from GuC (John)
- Avoid WARN splat by holding RPM wakelock during PXP unbind (Juston)
- Fixes to parallel submission implementation (Matt B.)
- Improve GuC loading status check/error reports (John)
- Tweak TTM LRU priority hint selection (Matt A.)
- Align the plane_vma to min_page_size of stolen mem (Ram)
- Introduce vma resources and implement async unbinding (Thomas)
- Use struct vma_resource instead of struct vma_snapshot (Thomas)
- Return some TTM accel move errors instead of trying memcpy move (Thomas)
- Fix a race between vma / object destruction and unbinding (Thomas)
- Remove short-term pins from execbuf (Maarten)
- Update to GuC version 69.0.3 (John, Michal Wa.)
- Improvements to GT reset paths in GuC backend (Matt B.)
- Use shrinker_release_pages instead of writeback in shmem object hooks (Matt A., Tvrtko)
- Use trylock instead of blocking lock when freeing GEM objects (Maarten)
- Allocate intel_engine_coredump_alloc with ALLOW_FAIL (Matt B.)
- Fixes to object unmapping and purging (Matt A)
- Check for wedged device in GuC backend (John)
- Avoid lockdep splat by locking dpt_obj around set_cache_level (Maarten)
- Allow dead vm to unbind vma's without lock (Maarten)
- s/engine->i915/i915/ for DG2 engine workarounds (Matt R)
- Use to_gt() helper for GGTT accesses (Michal Wi.)
- Selftest improvements (Matt B., Thomas, Ram)
- Coding style and compiler warning fixes (Matt B., Jasmine, Andi, Colin, Gustavo, Dan)
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/Yg4i2aCZvvee5Eai@jlahtine-mobl.ger.corp.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Fixed conflicts while applying, using the fixups/drm-intel-gt-next.patch
from drm-rerere's 1f2b1742abdd ("2022y-02m-23d-16h-07m-57s UTC: drm-tip
rerere cache update")]
Currently we just leave the old gunk lying around in the crtc
state when userspace asks us to fully disable the crtc. That
doesn't match what the state would be had we never even enabled
the crtc in the first place. So let's make this consistent and
call intel_crtc_prepare_cleared_state() for disabled crtcs as well
(excluding bigjoiner slaves of course which have had their state
copied from the master).
I actually already did this once in commit fff13e63a1 ("drm/i915:
Clear most of crtc state when disabling the crtc") but then
commit 19f65a3dbf ("drm/i915: Try to make bigjoiner work in atomic
check") undid it all :(
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-5-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
For some reason we're flagging that we need to run through the
full modeset calculations (any_ms==true -> do cdclk/etc. checks)
if any crtc got initially flagged for a modeset and is not
enabled via the uapi. No idea why this is here since later on
(after all fastset handling) we do full run through the crtcs
and flag any_ms if anything still needs a full modeset. So let's
just throw out this early weirdo.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217103221.10405-4-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
The VLV (including CHV, BXT, and GLK) DSI registers have fairly isolated
usage. Split the register macros to separated files.
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-3-jani.nikula@intel.com
DG2 supports a 5th display output which the hardware refers to as "TC1,"
even though it isn't a Type-C output. This behaves similarly to the TC1
on past platforms with just a couple minor differences:
* DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on
ICP/TGP/ADP.
* DG2 doesn't need the hpd inversion setting that we had to use on DG1
v2:
intel_ddi_init(dev_priv, PORT_TC1); [Matt]
Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-3-lucas.demarchi@intel.com
Reading the PIPECONF enable bit out from the hardware
in i9xx_set_pipeconf() on i830 is pointless as the bit should
always be set since we keep both pipes constantly running on
i830. Drop the pointless read and just always keep the bit set.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-4-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
We don't want any RMWs in the part of the commit that happens
under vblank evasion. Eventually we want to use the DSB to
handle that and it can't read registers at all. Also reads
are just slowing us down needlessly.
Let's move the whole PIPE_CHICKEN stuff out from the critical
section since we don't have anything there that needs to be
syncrhonized with other plane/pipe registers. If we ever need
to add such things then we have to move it back, but without
doing any reads.
TODO: should look into eliminating the RMW anyway...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-1-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
A new programming step was added to combo and TC PLL sequences.
If override_AFC_startup is set in VBT, driver should overwrite
AFC_startup value to 0x0 or 0x7 in PLL's div0 register.
The current understating is that only TGL needs this and all other
display 12 and newer platforms will have a older VBT or a newer VBT
with override_AFC_startup set to 0 but in any case there is a
drm_warn_on_once() to let us know if this is not true.
v2:
- specification updated, now AFC can be override to 0x0 or 0x7
- not using a union for div0 (Imre)
- following previous wrong vbt naming: bits instead of bytes (Imre)
BSpec: 49204
BSpec: 20122
BSpec: 49968
BSpec: 71360
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220216134059.25348-1-jose.souza@intel.com
No reason the high level intel_update_crtc() needs to know
that there is something magical about the commit order of
planes between different platforms. So let's hide that
detail even better.
In order to keep to somewhat consistent naming between
things we shall call this intel_crtc_planes_update_arm()
to match the plane->update_arm() vfunc naming convention.
And let's rename the noarm counterpart to
intel_crtc_planes_update_noarm() to more clearly associate
it with the plane->update_noarm() vfunc.
v2: Change the naming convention a bit
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-2-ville.syrjala@linux.intel.com
Exfiltrate intel_plane_atomic_calc_changes() and its friends from
intel_display.c to intel_atomic_plane.c since that is a much better
fit.
While at it also nuke the official looking kernel docs for
intel_wm_need_update() and flag it for eventual destruction so
that people don't get any wrong ideas about using it in new code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220211090629.15555-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Get rid of the inflexible bigjoiner_linked_crtc pointer thing
and just track things as a bitmask of pipes instead. We can
also nuke the bigjoiner_slave boolean as the role of the pipe
can be determined from its position in the bitmask.
It might be possible to nuke the bigjoiner boolean as well
if we make encoder.compute_config() do the bitmask assignment
directly for the master pipe. But for now I left that alone so
that encoer.compute_config() will just flag the state as needing
bigjoiner, and the intel_atomic_check_bigjoiner() is still
responsible for determining the bitmask. But that may have to change
as the encoder may be in the best position to determine how
exactly we should populate the bitmask.
Most places that just looked at the single bigjoiner_linked_crtc
now iterate over the whole bitmask, eliminating the singular
slave pipe assumption.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-11-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Currently the bigjoiner state copy logic is kind of
a byzantine mess.
Clean it up to operate in the following manner during a full
modeset:
1) master uapi -> hw state copy
2) master hw -> slave hw state copy
And during a non-modeset update we do:
1) master uapi -> hw state light copy
2) master hw -> slave hw state light copy
I think that is now easier to reason about since we never do
any kind of master uapi -> slave hw state copy short circuit
that could happen previously.
Obviously this does now depend on the master uapi->hw copy
always happening before the master hw -> slave hw copy, but
that is guaranteed by the fact that we always add both crtcs
to the state early, the crtcs are registered in pipe
order (so the compute_config loop happens in pipe order),
and the hardware requires the master pipe has to be lower
than the slave pipe as well. And for good measure we shall
add a check+WARN for this before doing the bigjoiner crtc
assignment.
v2: Fix uapi.ctm vs. hw.ctm copy-paste fail
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204072049.1610-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
There's some weird junk in intel_atomic_check_bigjoiner()
that's trying to look at the old crtc state's bigjoiner
usage for some reason. That code is totally unnecessary,
and maybe even actively harmful. Not entirely sure which
since it's such a mess that I can't actually wrap my brain
around what it ends up doing.
Either way, thanks to intel_bigjoiner_add_affected_crtcs()
all of the old bigjoiner crtcs are guaranteed to be in the
state already if any one of them is in the state. Also if
any one of those crtcs got flagged for a modeset, then all
of them will have been flagged, and the bigjoiner links
will have been detached via kill_bigjoiner_slave().
So there is no need to look examing any old bigjoiner
usage in intel_atomic_check_bigjoiner(). All we have to care
about is whether bigjoiner is needed for the new state,
and whether we can get the slave crtc we need.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-4-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
We seem to be missing a few things from the bigjoiner state copy.
Namely hw.mode isn't getting copied (which probably causes PIPESRC
to be misconfigured), CTM/LUTs aren't getting copied (which could
cause the pipe to produced incorrect output), and we also forgot
to copy over the color_mgmt_changed flag so potentially we fail
to do the actual CTM/LUT programming (assuming we aren't doing
a full modeset or fastset). Fix it all.
v2: Fix uapi.ctm vs. hw.ctm copy-paste fail
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204072009.1546-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
The core doesn't flag scaling_filter prop changes as needing
a modeset. That doesn't work for us since we only reprogram the
pipe scaler during full modesets and fastsets. So we need to
flag the prop change as a modeset ourselves. Assuming nothing else
has changed the operation will get promoted (demoted?) to a fastset
later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
IPS must be disabled prior to disabling the last plane (excluding
the cursor). Make the code do that instead of assuming the primary
plane would be the last one. This is probably 100% theoretical
as the BIOS should never light up the other planes anyway. But
no harm in making the code totally consistent.
Also let's update the ips_enabled flag in the crtc state afterwards
so that the first atomic commit has accurate information about
the state of IPS.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-6-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
IPS is a pretty well isolated feature. Move the relevant code
to a separate file from polluting intel_display.c.
I stuck to the hsw_ips name since that's what the function were
already using, and also to avoid confusion with the ILK
"Intelligen Power Sharing"/intel_ips GPU turbo stuff.
And let's also do the s/dev_priv/i915/ rename while touching
most of the code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
No reason the caller of the IPS pre/post update hooks should
be responsible for the actual IPS enab/disable. Just pull those
calls into the pre/post update hooks themselves. And while
at it let's adjust the function naming a bit to have a consistent
namespace.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Hoist the IPS related vblank waits one level up. Later on we'll
want to consolidate all the potential pre-plane update vblank
waits into one so we can't be hiding any in low level code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220209113526.7595-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout
that doesn't match what the spec recommends. With a single active
pipe that is not going to be a problem, but with multiple pipes
active skl_commit_modeset_enables() goes into an infinite loop
since it can't figure out any order in which it can commit the
pipes without causing DBUF overlaps between the planes.
We'd need some kind of extra DBUF defrag stage in between to
make the transition possible. But that is clearly way too complex
a solution, so in the name of simplicity let's just sanitize the
DBUF state by simply turning off all planes when we detect a
pipe encroaching on its neighbours' DBUF slices. We only have
to disable the primary planes as all other planes should have
already been disabled (if they somehow were enabled) by
earlier sanitization steps.
And for good measure let's also sanitize in case the DBUF
allocations of the pipes already seem to overlap each other.
Cc: <stable@vger.kernel.org> # v5.14+
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4762
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-3-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
