We want to stop using connector->panel.fixed_mode directtly.
In order to look it up in the future we'll need to have the
requested mode around, so pass that in fully (instead of just
passing bits of it).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We want to eventually get rid of the connector->panel.fixed_mode
pointer so avoid using it during DSI property setup. Since this
all happens during the encoder init we already have the fixed_mode
around, just pass that in.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Up to now alderlake-p was using the same eDP voltage swing table for
frequencies up to HBR2 as icelake but now it has its own table.
BSpec: 49291
Cc: Clinton A Taylor <clinton.a.taylor@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220314152753.85081-1-jose.souza@intel.com
Rename the PIPECONF refresh rate select bits to be
less cryptic. Also nothing eDP specific about these as they
also select between FP0 vs. FP1 for the DPLL and thus can be
used to change the refresh rate on other output types as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220310004802.16310-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
struct dp_link_dpll is a pointless wrapper around struct dpll.
Just store the desired link rate into struct dpll::dot and
we're done.
v2: Document the full divider as a proper decimal number on chv
Nuke bogus eDP 1.4 comments for chv while at it
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220307233940.4161-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Remove the comment specifying the exact formulat for calculating
the DPLL frequency from the *_find_best_dpll() functions. Each
platform variant has its own way to calculate these and we have
the code already to do that. These comments are entirely redundant
and often even wrong so just get rid of them.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220307233940.4161-3-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Unify vlv/chv with earlier platforms so that the sturct dpll::dot
represents the /5 clock frequency (ie. DP symbol rate or HDMI
TMDS rate) rather than the *5 fast clock (/2 of the bitrate).
Makes life a little less confusing to get the same number back
in .dot which we fed into the DPLL algorithm.
v2: Actually just include the 5x in the final P divider
Do the same change to the hand rolled gvt code
v3: Missed a few *5 in *_find_best_dpll()
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/20220309214301.22899-1-ville.syrjala@linux.intel.com
When using bigjoiner it's useful to know the offset of each
individual pipe in the whole set of joined pipes. Let's include
that information in our PIPESRC rectangle. With this we can make
the plane clipping code blissfully unaware of bigjoiner usage, as
all we have to do is remove the pipe's offset from the final plane
destination coordinates.
v2: Use intel_bigjoiner_num_pipes()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-14-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@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>
(cherry picked from commit 2e08437160)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.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>
(cherry picked from commit b0b2bed2a1)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@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>
(cherry picked from commit cccc71b552)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Currently we are observing occasional screen flickering when
PSR2 selective fetch is enabled. More specifically glitch seems
to happen on full frame update when cursor moves to coords
x = -1 or y = -1.
According to Bspec SF Single full frame should not be set if
SF Partial Frame Enable is not set. This happened to be true for
ADLP as PSR2_MAN_TRK_CTL_ENABLE is always set and for ADL_P it's
actually "SF Partial Frame Enable" (Bit 31).
Setting "SF Partial Frame Enable" bit also on full update seems to
fix screen flickering.
Also make code more clear by setting PSR2_MAN_TRK_CTL_ENABLE
only if not on ADL_P. Bit 31 has different meaning in ADL_P.
Bspec: 49274
v2: Fix Mihai Harpau email address
v3: Modify commit message and remove unnecessary comment
Tested-by: Lyude Paul <lyude@redhat.com>
Fixes: 7f6002e580 ("drm/i915/display: Enable PSR2 selective fetch by default")
Reported-by: Lyude Paul <lyude@redhat.com>
Cc: Mihai Harpau <mharpau@gmail.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/5077
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220225070228.855138-1-jouni.hogander@intel.com
(cherry picked from commit 8d5516d18b)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Since we are actually mapping the object and not the vma, when dealing
with LMEM, we should be careful and use the backing store size here,
since the vma->node.size could have all kinds of funny padding
constraints, which could result in us writing to OOB address.
v2(Chris):
- Prefer vma->size here, which should be the backing store size. Some
more rework is needed here to stop using node.size in some other
places.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220304095934.925036-1-matthew.auld@intel.com
vms are not getting properly closed. Rather than fixing that,
Remove the vm open count and instead rely on the vm refcount.
The vm open count existed solely to break the strong references the
vmas had on the vms. Now instead make those references weak and
ensure vmas are destroyed when the vm is destroyed.
Unfortunately if the vm destructor and the object destructor both
wants to destroy a vma, that may lead to a race in that the vm
destructor just unbinds the vma and leaves the actual vma destruction
to the object destructor. However in order for the object destructor
to ensure the vma is unbound it needs to grab the vm mutex. In order
to keep the vm mutex alive until the object destructor is done with
it, somewhat hackishly grab a vm_resv refcount that is released late
in the vma destruction process, when the vm mutex is no longer needed.
v2: Address review-comments from Niranjana
- Clarify that the struct i915_address_space::skip_pte_rewrite is a hack
and should ideally be replaced in an upcoming patch.
- Remove an unneeded continue in clear_vm_list and update comment.
v3:
- Documentation update
- Commit message formatting
Co-developed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220304082641.308069-2-thomas.hellstrom@linux.intel.com
Replace the hardcoded 2 pipe assumptions when we're massaging
pipe_mode and the pipe_src rect to be suitable for bigjoiner.
Instead we can just count the number of pipes in the bitmask.
v2: Introduce intel_bigjoiner_num_pipes()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223131315.18016-13-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
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>
Toss a bunch if constants into .rodata drom the stack. Also
shrink the types of some of the arrays to reduce the size.
bloat-o-meter -c intel_dpll_mgr.o:
add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-86 (-86)
Function old new delta
icl_get_dplls 3393 3372 -21
skl_get_dpll 2069 2004 -65
Total: Before=28029, After=27943, chg -0.31%
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Data old new delta
Total: Before=17, After=17, chg +0.00%
add/remove: 2/0 grow/shrink: 0/2 up/down: 28/-129 (-101)
RO Data old new delta
dco_central_freq - 24 +24
div1_vals - 4 +4
odd_dividers 28 7 -21
even_dividers 144 36 -108
Total: Before=3600, After=3499, chg -2.81%
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220301173128.6988-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@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>
Changes since v2.14:
- Release Notes for v2.15
Fix for corruption issue when DC States are enabled.
- Release Notes for v2.16
Fix for cases with flip queue and DC6v are enabled.
Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220223222801.397632-2-madhumitha.tolakanahalli.pradeep@intel.com
Allocate the individual intel_gmbus structs dynamically. This lets us
hide struct intel_gmbus inside intel_gmbus.c completely. Also use the
cleanup function on the error path to avoid duplication.
Leave #include <linux/i2c.h> in i915_drv.h for now, as it pulls in a
bunch of implicit dependencies.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303181931.1661767-4-jani.nikula@intel.com
Combine the platform specific if ladders for array lookup and size
checks into one. This is cleaner and avoids duplication, but hopefully
also helps any static analyzers that seem to have trouble with the
bounds checks.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303181931.1661767-1-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>
