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>
The audio logic lives in the transcoder rather than the pipe,
so start tracking it like that.
This is only really important for bigjoiner cases where tracking
by pipe doesn't work at all since intel_audio_codec_{enable,disable}()
won't even be called for the slave pipe. This means the state
checker won't find the ELD for the slave pipe and gets upset.
The PD->has_audio readout does currently work since that gets
read out from the same transcoder for both pipes.
For other cases this doesn't actually matter since it's only
the normal pipe transcoders that are audio capable, whereas
the more special transcoders (EDP/DSI) are not.
v2: Fix kernel docs
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230222151454.24888-1-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8222
Since we use the audio component to transfer the ELD to the audio
driver on hsw+ platforms there is no point in even programming
the hardware ELD buffer. Stop doing so.
The one slight caveat here is that this is not strictly legal
according to the HDA spec. PD=1;ELD=0 is only documented as
an intermediate state during modeset. But if there is no hardware
that depends on that then I guess we're fine. Or we could
perhaps set ELD=1 without actually programming the buffer?
Note that the bspec sequence of PD=0;ELD=0 -> PD=1;ELD=0 ->
PD=1;ELD=1 is also not strictly correct according to the HDA
spec, as the only documented transition from PD=0;ELD=0 is
straight to PD=1;ELD=1.
Additionally on hsw/bdw the hardware buffer is tied in with the
dedicated display HDA controller's power state, so currently
we mostly fail at proramming the buffer anyway. When the HDA
side is not sufficiently powered up the ELD address bits get
stuck and the ELD data register accesses go nowhere.
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
References: https://lore.kernel.org/intel-gfx/20221012104936.30911-1-ville.syrjala@linux.intel.com/
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124144628.4649-3-ville.syrjala@linux.intel.com
Since we use the audio component to transfer the ELD to the audio
driver on ilk+ platforms there is no point in even programming
the hardware ELD buffer. Stop doing so.
The one slight caveat here is that this is not strictly legal
according to the HDA spec. PD=1;ELD=0 is only documented as
an intermediate state during modeset. But if there is no hardware
that depends on that then I guess we're fine. Or we could
perhaps set ELD=1 without actually programming the buffer?
Note that the bspec sequence of PD=0;ELD=0 -> PD=1;ELD=0 ->
PD=1;ELD=1 is also not strictly correct according to the HDA
spec, as the only documented transition from PD=0;ELD=0 is
straight to PD=1;ELD=1. But that is not even possible on
these platforms as the bits live in different registers.
Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230124144628.4649-2-ville.syrjala@linux.intel.com
Add display/intel_display_trace.[ch] for defining display
tracepoints. The main goal is to reduce cross-includes between gem and
display. It would be possible split up tracing even further, but that
would lead to more boilerplate.
We end up having to include intel_crtc.h in a few places because it was
pulled in implicitly via intel_de.h -> i915_trace.h -> intel_crtc.h, and
that's no longer the case.
There should be no changes to tracepoints.
v3:
- Rebase
v2:
- Define TRACE_INCLUDE_PATH relative to define_trace.h (Chris)
- Remove useless comments (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7862ad764fbd0748d903c76bc632d3d277874e5b.1638961423.git.jani.nikula@intel.com
XE_LPD display adds support for display audio codec keepalive feature.
This feature works also when display codec is in D3 state and the audio
link is off (BCLK off). To enable this functionality, display driver
must update the AUD_TS_CDCLK_M/N registers whenever CDCLK is changed.
Actual timestamps are generated only when the audio codec driver
specifically enables the KeepAlive (KAE) feature.
This patch adds new hooks to intel_set_cdclk() in order to inform
display audio driver when CDCLK change is started and when it is
complete.
Bspec: 53679
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211021105915.4128635-1-kai.vehmanen@linux.intel.com
DG1 and XE_PLD platforms has Audio MMIO/VERBS lies in PG0 power
well. Adjusting the power domain accordingly to
POWER_DOMAIN_AUDIO_MMIO for audio detection and
POWER_DOMAIN_AUDIO_PLAYBACK for audio playback.
While doing this it requires to use POWER_DOMAIN_AUDIO_MMIO
power domain instead of POWER_DOMAIN_AUDIO in crtc power domain mask
and POWER_DOMAIN_AUDIO_PLAYBACK with intel_display_power_{get, put}
to enable/disable display audio codec power.
It will save the power in use cases when DP/HDMI connectors
configured with PIPE_A without any audio playback.
v1: Changes since RFC
- changed power domain names. [Imre]
- Removed TC{3,6}, AUX_USBC{3,6} and TBT from DG1
power well and PW_3 power domains. [Imre]
- Fixed the order of powe wells , power domains and its
registration. [Imre]
v2:
- Not allowe DC states when AUDIO_MMIO domain enabled. [Imre]
v3:
- Squashes the commits of series to avoid build failure.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
[Fix typo in commit message and in AUDIO_PLAYBACK domain name]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210729121858.16897-2-anshuman.gupta@intel.com
Hoist the intel_de.h include from intel_display_types.h one
level up. I need this in order to untangle the include order
so that I can add tracepoints into intel_de.h.
This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
intel_de_read_fw(...)
|
intel_de_write(...)
|
intel_de_write_fw(...)
)
@has_include@
@@
(
#include "intel_de.h"
|
#include "display/intel_de.h"
)
@depends on find && !has_include@
@@
+ #include "intel_de.h"
#include "intel_display_types.h"
@depends on find && !has_include@
@@
+ #include "display/intel_de.h"
#include "display/intel_display_types.h"
Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
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/20210430143945.6776-1-ville.syrjala@linux.intel.com
While converting the rest of the driver to use GRAPHICS_VER() and
MEDIA_VER(), following what was done for display, some discussions went
back on what we did for display:
1) Why is the == comparison special that deserves a separate
macro instead of just getting the version and comparing directly
like is done for >, >=, <=?
2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for
brevity. If we remove the current users of IS_DISPLAY_VER(), we
could actually repurpose it for a range check
With (1) there could be an advantage if we used gen_mask since multiple
conditionals be combined by the compiler in a single and instruction and
check the result. However a) INTEL_GEN() doesn't use the mask since it
would make the code bigger everywhere else and b) in the cases it made
sense, it also made sense to convert to the _RANGE() variant.
So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range
like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER()
users to use == and != operators. Aside from the definition changes,
this was done by the following semantic patch:
@@ expression dev_priv, E1; @@
- !IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) != E1
@@ expression dev_priv, E1; @@
- IS_DISPLAY_VER(dev_priv, E1)
+ DISPLAY_VER(dev_priv) == E1
@@ expression dev_priv, from, until; @@
- IS_DISPLAY_RANGE(dev_priv, from, until)
+ IS_DISPLAY_VER(dev_priv, from, until)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
[Jani: Minor conflict resolve while applying.]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
Update logic to program AUD_FREQ_CNTRL register based on new guidance.
Earlier this register was configured by BIOS and driver discovered the
value at init. This is no longer recommended and instead driver should
set the values based on the hardware revision.
Add the recommended values for all supported hardware. This change applies
for all GEN12+ hardware. For TGL, some special case handling is needed
to not break existing systems.
Extend the debug print to also include values of the register as written
by BIOS. This can help debug rare cases where BIOS has configured the link
settings to incorrect values.
Bspec: 49279
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324123725.4170214-1-kai.vehmanen@linux.intel.com
