VLV has a so called "wide gamut color correction" unit (WGC).
What it is is a 3x3 matrix similar to the later CHV CGM
CSC, with less precisions/range. In fact CHV also has the WGC
but using it there doesn't really make sense when you have the
superior CGM CSC around.
Hook up the necessary stuff to expose the WGC as the CTM
crtc property.
One additional crazy idea that came to mind would be to use
the WGC as an output CSC on CHV for YCbCr output. But it
would be incompatible with the legacy LUT usage. In fact
since the WGC lacks post-offsets we'd probably have to
use the legacy LUT to do that final part of the RGB->YCbCr
conversion. Sounds doable, but perhaps not worth the hassle.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413164916.4221-6-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Clang warns:
drivers/gpu/drm/i915/display/intel_display.c:6012:3: error: unannotated fall-through between switch labels [-Werror,-Wimplicit-fallthrough]
case I915_FORMAT_MOD_X_TILED:
^
drivers/gpu/drm/i915/display/intel_display.c:6012:3: note: insert 'break;' to avoid fall-through
case I915_FORMAT_MOD_X_TILED:
^
break;
1 error generated.
Clang is a little more pedantic than GCC, which does not warn when
falling through to a case that is just break or return. Clang's version
is more in line with the kernel's own stance in deprecated.rst, which
states that all switch/case blocks must end in either break,
fallthrough, continue, goto, or return. Add the missing break to silence
the warning.
Fixes: 937859485a ("drm/i915: Support Async Flip on Linear buffers")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/202305241902.UvHtMoxa-lkp@intel.com/
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Closes: https://lore.kernel.org/CA+G9fYv68V3ewK0Qj-syQj7qX-hQr0H1MFL=QFNuDoE_J2Zu-g@mail.gmail.com/
Reported-by: Tom Rix <trix@redhat.com>
Closes: https://lore.kernel.org/all/20230523125116.1669057-1-trix@redhat.com/
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230524-intel_async_flip_check_hw-implicit-fallthrough-v1-1-83de89e376a1@kernel.org
Move the runtime info specific to display into display-specific
structures as has already been done with the constant display info.
v2:
- Rename __runtime to __runtime_defaults for more clarity on the
purpose. (Andrzej)
- Move introduction of DISPLAY_INFO() to previous patch. (Andrzej)
- Drop NO_DISPLAY macro. (Andrzej)
v3:
- Use "{}" instead of "{ 0 }" for empty struct init. (Jani)
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230523195609.73627-4-matthew.d.roper@intel.com
Starting from Gen12 Async Flip is supported on linear buffers.
This patch enables support for async on linear buffer.
UseCase: In Hybrid graphics, for hardware unsupported pixel formats it
will be converted to linear memory and then composed.
v2: Added use case
v3: Added FIXME for ICL indicating the restrictions
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220906041806.4095575-1-arun.r.murthy@intel.com
The "fastset mismatch" debug logging has been slightly confusing,
leading people to believe some error happened. Change it to the more
informative "fastset requirement not met", and add a final message about
this leading to full modeset.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230516094406.2675307-1-jani.nikula@intel.com
During HW readout/sanitization CRTCs can be disabled only if they don't
have an attached encoder (and so the encoder disable hooks don't need to
be called). An upcoming patch will need to disable CRTCs also with an
attached encoder, so add support for this.
For bigjoiner configs the encoder disabling hooks require the slave CRTC
states, so add these too to the atomic state. Since the connector atomic
state is already up-to-date when the CRTC is disabled the connector
state needs to be updated (reset) after the CRTC is disabled, make this
so. Follow the proper order of disabling first all bigjoiner slaves,
then any port synced CRTC slaves followed by the CRTC originally
requested to be disabled.
v2:
- Fix calculating the bigjoiner_masters mask in a port sync config,
(Ville)
- Keep _noatomic suffix in intel_crtc_disable_noatomic(). (Ville)
- Rebase on full CRTC state reset in this patchset, not requiring
resetting the bigjoiner state separately and (instead) resetting
the full atomic CRTC and related global state after all linked
pipes got disabled.
- Disable portsync slaves before a portsync master.
- Disable a portsync master if a linked portsync slave is disabled.
v3: (Ville)
- Use s/u32/u8 for transcoder and pipe masks.
- Use is_power_of_2() instead of hweight()==1.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-8-imre.deak@intel.com
For a bigjoiner configuration display->crtc_disable() will be called
first for the slave CRTCs and then for the master CRTC. However slave
CRTCs will be actually disabled only after the master CRTC is disabled
(from the encoder disable hooks called with the master CRTC state).
Hence the slave PIPEDMCs can be disabled only after the master CRTC is
disabled, make this so.
intel_encoders_post_pll_disable() must be called only for the master
CRTC, as for the other two encoder disable hooks. While at it fix this
up as well. This didn't cause a problem, since
intel_encoders_post_pll_disable() will call the corresponding hook only
for an encoder/connector connected to the given CRTC, however slave
CRTCs will have no associated encoder/connector.
Fixes: 3af2ff0840 ("drm/i915: Enable a PIPEDMC whenever its corresponding pipe is enabled")
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230510103131.1618266-2-imre.deak@intel.com
Add i915 parameter to I915_STATE_WARN() and use device based logging.
Done using cocci + hand edited where there was no i915 local variable
ready.
v2: avoid null deref in verify_connector_state()
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230512181658.1735594-1-jani.nikula@intel.com
The decision to use DFP output format conversion capabilities should be
during compute_config phase.
This patch adds new member to crtc_state to represent the final
output_format to the sink. In case of a DFP this can be different than
the output_format, as per the format conversion done via the PCON.
This will help to store only the format conversion capabilities of the
DP device in intel_dp->dfp, and use crtc_state to compute and store the
configuration for color/format conversion for a given mode.
v2: modified the new member to crtc_state to represent the final
output_format that eaches the sink, after possible conversion by
PCON kind of devices. (Ville)
v3: Addressed comments from Ville:
-Added comments to clarify difference between sink_format and
output_format.
-Corrected the order of setting sink_format and output_format.
-Added readout for sink_format in get_pipe_config hooks.
v4: Set sink_format for intel_sdvo too. (Ville)
v5: Rebased.
v6: Fixed condition to go for YCbCr420 format for dp and hdmi. (Ville)
v7: Fix the condition to set sink_format for HDMI.
Set hdmi output_format simply as sink_format. (Ville)
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v3)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230427125605.487769-2-ankit.k.nautiyal@intel.com
Define and use the bitmasks for the x/y components
of the ilk+ panel filter window pos/size registers.
Note that we stick to the full 16 bit mask even though
the actual hardware limits are lower (and somewhat
platform dependent). BDW is actually limited to
13 bits horizontal and 12 bits vertical, with the high
bits being hardwired to zero. HSW should have the same
limits as BDW. And pre-HSW should be limited to 12bits
in both directions as that's already the limit of the
transcoder timing registers. Curiously on HSW and earlier
platforms all 16 bits can actually be set, but presumably
the hardware ignores the high bits.
v2: Switch back to full 16bit masks since that's what
we use transcoder timign regs and PIPESRC as well
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230426135019.7603-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add register writes to enable powering up Type-C subsystem i.e. TCSS.
For MeteorLake we need to request TCSS to power up and check the TCSS
power state after 500 us.
In addition, for PICA we need to set/clear the Type-C PHY ownnership
bit when Type-C device is connected/disconnected.
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-11-mika.kahola@intel.com
The only way to truly clean up intel_display.[ch] is to move stuff out
of them until there's absolutely nothing left.
Start moving the high level display driver entry points, i.e. functions
called from top level driver code only, to a new file, which we'll call
intel_display_driver.c. The intention is that there's no low-level
display code or details here. This is an in-between layer.
Initially, move intel_display_driver_register() and
intel_display_driver_unregister() there.
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e42cc037881a4c6042948a34bd4a9698f9e8487c.1681465222.git.jani.nikula@intel.com
The point of the WARN was to print something, not oops
straight up. Currently that is precisely what happens
if we can't find the connector for the crtc in the atomic
state. Get the dev pointer from the atomic state instead
of the potentially NULL encoder to avoid that.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413200602.6037-2-ville.syrjala@linux.intel.com
Fixes: 3a47ae201e ("drm/i915/display: Make WARN* drm specific where encoder ptr is available")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Initialization sequences and C10 phy are in place to be able to enable
the first 2 ports of MTL. The other ports use C20 phy that still need
to be properly added. Enable the first ports for now, keeping a TODO
comment about the others.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-10-radhakrishna.sripada@intel.com
If we have to force the hardware to go through a full modeset
due to eg. cdclk reprogramming, we need to preserve
crtc_state->inherited for all crtcs that have not otherwise
gone through the whole compute_config() stuff after connectors
have been detected.
Otherwise eg. cdclk induced modeset glk_force_audio_cdclk()
will clear the inherited flag, and thus the first real commit
coming from userspace later on will not be forced through
the full .compute_config() path and so eg. audio state may
not get properly recomputed.
But instead of adding all kinds of ad-hoc crtc_state->inherited
preservation hacks all over, let's change things so that we
only clear it for the crtcs directly included in userspace/client
initiated commits.
Should be far less fragile since now we just need to remember
to flag the internal commits, and not worry about where new
crtcs might get pulled in.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5260
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230328122357.1697-1-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Move VRR enabling/disabling into a place where it also works
for fastsets.
With this we always start the transcoder up in non-VRR mode.
Granted we already did that but for a very short period of
time. But now that we might end up doing a bit more with the
transcoder in non-VRR mode it seems prudent to also update
the active timings as the transcoder changes its operating
mode.
crtc_state->vrr.enable still tracks whether VRR is actually
enabled or not, but now we configure all the other VRR timing
registers whenever VRR is possible (whether we actually enable
it or not). crtc_state->vrr.flipline can now serve as our
"is VRR possible" bit of state.
I decided to leave the MSA timing ignore bit set all the time
whether VRR is actually enabled or not. If the sink can figure
out the timings with that information when VRR is active then
surely it can also do it when VRR is inactive.
v2: Protect intel_vrr_set_transcoder_timings() with HAS_VRR()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230321135615.27338-1-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
In order to move VRR enable/disable to a place where it's also
applicable to fastsets we need to be prepared to configure
the pipe into non-VRR mode initially, and then later switch
to VRR mode. To that end allow the active timings to be configured
in non-VRR mode temporarily even when the crtc_state says we're
going to be using VRR.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-5-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Read out the pipe/output csc matrices on ilk+ and stash the results
(in the hardware specific format) into the appropriate place
in the crtc state.
Note that on skl/glk/icl the pipe csc unit suffers from an issue
where *reads* of the coefficient/offset registers also disarm
the double buffer update (if currently armed via CSC_MODE write).
So it's rather important that the readout only happens after the
csc registers have been latched. Fortunately the state checker
only runs after the start of vblank where the latching happens.
And on skl/glk the DMC + CSC register read has the potential to
corrupt the latched CSC register values, so let's add a comment
reminding us that the DC states should remain off until the
readout has been completed.
TODO: maybe we could somehow check to make sure PSR has in fact
latched the new register values already, and that DC states
have been off all along?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-9-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Observe that intel_pm.[ch] is now purely about clock gating, so rename
them to intel_clock_gating.[ch]. Rename the functions to
intel_clock_gating_*() to follow coding conventions.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230403122428.3526263-1-jani.nikula@intel.com
The encoder update_prepare()/complete() hooks were added to hold a
TC port link reference for all outputs in the atomic state around the
whole modeset enable sequence - thus locking the ports' TC mode - and
set the TBT/DP-alt PLL type corresponding to the current TC mode.
Since nothing depends on the PLL selection before/after then encoder's
pre_pll_enable/post_pll_disable hooks are called, the above steps can be
moved to these hooks, so do that and remove the
update_prepare()/complete() hooks.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-30-imre.deak@intel.com
Bspec requires disabling the DPLLs on TC ports before disconnecting the
port's PHY. Add a post_pll_disable encoder hook and move the call to
disconnect the port's PHY from the post_disable hook to the new hook.
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-28-imre.deak@intel.com
The spec requires disabling the PLL on TC ports before disconnecting the
port's PHY. Prepare for that by moving the PLL disabling to the CRTC
disable hook, while disconnecting the PHY will be moved to the
post_pll_disable() encoder hook in the next patch.
v2: Move the call from intel_crtc_disable_noatomic() as well.
Reviewed-by: Mika Kahola <mika.kahola@intel.com> # v1
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230323142035.1432621-27-imre.deak@intel.com
Add i915.enable_dpt modparam to allow disabling the DPT
usage in hardware via the chicken bit. Useful when debugging
potential DPT issues.
Quickly smoke tested on ADL.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320090522.9909-6-ville.syrjala@linux.intel.com
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Keeping DC states enabled is incompatible with the _noarm()/_arm()
split we use for writing pipe/plane registers. When DC5 and PSR
are enabled, all pipe/plane registers effectively become self-arming
on account of DC5 exit arming the update, and PSR exit latching it.
What probably saves us most of the time is that (with PIPE_MISC[21]=0)
all pipe register writes themselves trigger PSR exit, and then
we don't re-enter PSR until the idle frame count has elapsed.
So it may be that the PSR exit happens already before we've
updated the state too much.
Also the PSR1 panel (at least on this KBL) seems to discard the first
frame we trasmit, presumably still scanning out from its internal
framebuffer at that point. So only the second frame we transmit is
actually visible. But I suppose that could also be panel specific
behaviour. I haven't checked out how other PSR panels behave, nor
did I bother to check what the eDP spec has to say about this.
And since this really is all about DC states, let's switch from
the MODESET domain to the DC_OFF domain. Functionally they are
100% identical. We should probably remove the MODESET domain...
And for good measure let's toss in an assert to the place where
we do the _noarm() register writes to make sure DC states are
in fact off.
v2: Just use intel_display_power_is_enabled() (Imre)
Cc: <stable@vger.kernel.org> #v5.17+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Fixes: d13dde4495 ("drm/i915: Split pipe+output CSC programming to noarm+arm pair")
Fixes: f8a005eb89 ("drm/i915: Optimize icl+ universal plane programming")
Fixes: 890b6ec4a5 ("drm/i915: Split skl+ plane update into noarm+arm pair")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320183532.17727-1-ville.syrjala@linux.intel.com
We're going to need stuff after the color management
register latching has happened. Add a corresponding hook.
Cc: <stable@vger.kernel.org> #v5.19+
Cc: Manasi Navare <navaremanasi@google.com>
Cc: Drew Davenport <ddavenport@chromium.org>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320095438.17328-4-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Move intel_crtc_update_active_timings() into intel_vblank.c
where it more properly belongs.
Also do the s/dev_priv/i915/ modernization rename while at it.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230310235828.17439-3-ville.syrjala@linux.intel.com
Add some (probably overkill) locking to protect the vblank
timestamping constants updates during seamless M/N fastsets.
As everything should be naturally aligned I think the individual
pieces should probably end up updating atomically enough. So this
is only really meant to guarantee everyone sees a consistent whole.
All the drm_vblank.c usage is covered by vblank_time_lock,
and uncore.lock will take care of __intel_get_crtc_scanline()
that can also be called from outside the core vblank functionality.
Currently only crtc_clock and framedur_ns can change, but in
the future might fastset also across eg. vtotal/vblank_end
changes, so let's just grab the locks across the whole thing.
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/20230310235828.17439-2-ville.syrjala@linux.intel.com
