Rather than having the connector init get the fixed mode back from
intel_panel and then feed it straight back into intel_panel_init()
let's just make the fixed mode lookup put the mode directly onto
the panel's fixed_modes list. Avoids the pointless round trip and
opens the door for further enhancements to the fixed mode handling.
v2: Make the debug message correct by using intel_panel_drrs_type() (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Only intel_dmc.c should be accessing dmc details directly.
Need to add an i915_error_printf() stub for
CONFIG_DRM_I915_CAPTURE_ERROR=n.
v2: Add the stub (kernel test robot <lkp@intel.com>)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> # v1
Link: https://patchwork.freedesktop.org/patch/msgid/20220330113417.220964-1-jani.nikula@intel.com
Update DG2 init bw info similar to other platforms even though
DG2 has constant bandwidh. This will avoid branching out DG2
specific max bw calls.
V3: Fix dg2_get_bw_info() and avoid handle special cases
for DG2 (Ville Syrjälä)
cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220328230000.215094-1-vinod.govindapillai@intel.com
PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being
enabled but that could potentially cause issues as it could have
mismatching values while pipes are being enabled.
So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be
executed before the function that enables all pipes, leaving all pipes
with a matching A_CREDIT value.
While at it, also moving it to intel_pm.c as we are trying to reduce
the gigantic size of intel_display.c and intel_pm.c have other MBUS
programing sequences.
v2:
- do not program PIPE_MBUS_DBOX_CTL if pipe will not be active or
when it do not needs modeset
- remove the checks to wait a vblank
v3:
- checking if dbuf state is present in state before using it
v4:
- removing redundant checks
- calling intel_atomic_get_new_dbuf_state instead of
intel_atomic_get_dbuf_state
BSpec: 49213
BSpec: 50343
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-3-jose.souza@intel.com
Alderlake-P has different MBUS DBOX BW and B credits than other
platforms, so here setting it properly.
BSpec: 49213
BSpec: 50343
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Caz Yokoyama <caz.yokoyama@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-2-jose.souza@intel.com
MBUS_DBOX_B2B_TRANSACTIONS_MAX, MBUS_DBOX_B2B_TRANSACTIONS_DELAY and
MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN were being programmed with
zeros while specification has different default values for this
registers in display 12 and newer.
While at it also converting all MBUS_DBOX macros to use REG_* macros.
BSpec: 50343
BSpec: 20231
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220330155724.255226-1-jose.souza@intel.com
Debug log when DSC is going to be used, and why, instead of
unconditionally logging the rarely used debug option setting, which
might not have any bearing on whether DSC is going to be used or not.
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/20220330093019.4150386-1-jani.nikula@intel.com
The audio codec enable/disable debug logging is spread around in callers
and the platform specific hooks. Put them all together in one place on
both the enable and disable paths.
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/20220330094109.4164326-1-jani.nikula@intel.com
Continuation of the effort to declutter i915_drv.h.
Also, component specific helpers which consult the iommu/virtualization
helpers moved to respective component source/header files as appropriate.
v2:
* s/dev_priv/i915/ in intel_scanout_needs_vtd_wa. (Lucas)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220329090204.2324499-1-tvrtko.ursulin@linux.intel.com
[tursulin: fixup conflict in i915_drv.h]
intel_dmc_load_program() is only ever called when
intel_dmc_has_payload() is true. Move the condition within
intel_dmc_load_program() to let it be called directly.
Also note that intel_dmc_has_payload() will always return false when
HAS_DMC() is false. Remove the redundant check.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c8ec46a44071f80b9c97617391b30e0c61ebc3e6.1647870374.git.jani.nikula@intel.com
ATS-M is a server platform based on Xe_HPG and Xe_HPM, but without
display support. From a driver point of view, it's easiest to just
handle it as DG2 (including identifying as PLATFORM_DG2), but with the
display disabled in the device info.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220329000822.1323195-1-matthew.d.roper@intel.com
SDVO is the only connector type currently returning the VBT
fixed mode directly from .get_modes(), everyone else just
adds it to the fixed_modes list and then returns that from
.get_modes(). Adjust SDVO to follow the common behaviour.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-10-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Despite the name intel_panel_edid_fixed_mode() doesn't actually
look in the EDID. All it does is dig out the preferred mode from
the connector's probed_modes list. That is also what the SDVO
LVDS code is doing by hand. Let's just call
intel_panel_edid_fixed_mode().
The slight difference in behaviour is that the SDVO code currently
bails if it can't find the preferred mode, whereas
intel_panel_edid_fixed_mode() will fall back to just returning
the first mode from the probed_modes list. Can't imagine why
such an LVDS panel would even exist, and also why would you have
a panel and be expected to not use it? So I'm going to assume
this is a total non-issue.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Apart from the EDID and VBT based mechanism we also sometimes
use the encoder's current mode as the panel fixed mode. We
currently have the same code for that duplicated in two places.
Let's unify.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Rename intel_panel_vbt_fixed_mode() to
intel_panel_vbt_lfp_fixed_mode() to be more descriptive.
We'll have another VBT fixed mode function soon and we
don't want to confuse the two.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Use intel_panel_preferred_fixed_mode() for all the orientation
quirk setup and compute_is_dual_link_lvds()). All of these
happen after intel_panel_init() so the panel fixed_mode list
is already in place.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Pull the drm_connector_set_panel_orientation_with_quirk()
into intel_edp_add_properties() to match how the DSI encoders
do it. Less clutter in intel_edp_init_connector() overall.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Replace all drm_mode_debug_printmodeline() calls with
DRM_MODE_FMT+DRM_MODE_ARG(). Makes the debug output a bit more
terse in places where we previously had a newline in the precedeing
drm_dbg_kms(), and avoids anything else sneaking in between the two
printk()s in all cases.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Move most of the pipe+output CSC programming to the
.color_commit_noarm() hook which runs before vblank evasion.
Only PIPE_CSC_MODE (the arming register) needs to remain in
inside the critical section.
A test case that just updates the CTM in a loop produces
the following i915_update_info numbers on ilk (w/o lockdep):
old new
Updates: 10012 Updates: 10008
| |
1us |** 1us |**********
|************* |*************
4us |********* 4us |*
|* |**
16us | 16us |
| |
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 1345ns Min update: 1268ns
Max update: 16672ns Max update: 15656ns
Average update: 3914ns Average update: 2185ns
Overruns > 100us: 0 Overruns > 100us: 0
And here is tgl (forced to update both pipe CSC and
output CSC, and with lockdep enabled):
old new
Updates: 10012 Updates: 10012
| |
1us | 1us |
| |
4us |* 4us |**
|** |**********
16us |************* 16us |*************
|* |
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 5204ns Min update: 5176ns
Max update: 176038ns Max update: 186685ns
Average update: 23931ns Average update: 16654ns
Overruns > 250us: 0 Overruns > 250us: 0
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
To reduce the amount of registers written during the vblank evade
critical section let's also split the .color_commit() hook to
noarm+arm pair. The noarm hook runs before the vblank evasion
with the arm hook staying inside the critical section.
Just the framework here, actually moving stuff out into the noarm
hook will follow.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
All the skl+ scaler registers are suitably confined to their own
cachelines so we don't need the uncore.lock to globally serialize
access to these registers. We actually already dropped some of this
in commit 14ad15296d ("drm/i915: Make skl+ universal plane
registers unlocked") as the plane scaler enabling/reconfiguration
became lockless. So let's complete that and remove the rest of
the locks from the scaler programming as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220224165103.15682-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
intel_drrs_enable() and intel_drrs_disable() were renamed to
intel_drrs_activate() and intel_drrs_deactivate() in commit
54903c7a6b ("drm/i915: s/enable/active/ for DRRS") and it is
causing warnings when generating the kernel documentation.
But as for a while DRRS has its own file, so here just let the tool
generate the documentation for all exported and documented functions
in intel_drrs.c.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220325183832.146472-1-jose.souza@intel.com
At least some DELL monitors (P2715Q) with DPCD_REV 1.2 return corrupted
DPCD register values when reading from the 0xF0000- LTTPR range with an
AUX transaction block size bigger than 1. The DP standard requires 0 to
be returned - as for any other reserved/invalid addresses - but these
monitors return the DPCD_REV register value repeated in each byte of the
read buffer. This will in turn corrupt the values returned by the LTTPRs
between the source and the monitor: LTTPRs must adjust the values they
read from the downstream DPRX, for instance right-shift/init the
downstream DP_PHY_REPEATER_CNT value. Since the value returned by the
monitor's DPRX is non-zero the adjusted values will be corrupt.
Reading the LTTPR registers one-by-one instead of reading all of them
with a single AUX transfer works around the issue.
According to the DP standard's 0xF0000 register description:
"LTTPR-related registers at DPCD Addresses F0000h through F02FFh are
valid only for DPCD r1.4 (or higher)." While it's unclear if DPCD r1.4
refers to the DPCD_REV or to the
LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV register (tickets filed
at the VESA site to clarify this haven't been addressed), one
possibility is that it's a restriction due to non-compliant monitors
described above. Disabling the non-transparent LTTPR mode for all such
monitors is not a viable solution: the transparent LTTPR mode has its
own issue causing link training failures and this would affect a lot of
monitors in use with DPCD_REV < 1.4. Instead this patch works around
the problem by reading the LTTPR common and PHY cap registers one-by-one
for any monitor with a DPCD_REV < 1.4.
The standard requires the DPCD capabilities to be read after the LTTPR
common capabilities are read, so re-read the DPCD capabilities after
the LTTPR common and PHY caps were read out.
v2:
- Use for instead of a while loop. (Ville)
- Add to code comment the monitor model with the problem.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4531
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220322143844.42616-1-imre.deak@intel.com
HSW+ platforms are able to send out HDR Metadata SDP DIP
packet as GMP. Hence, extending the support for HDR on DP
encoders for the same.
v2: Limited to non eDP ports on hsw/bdw and removed it for
lspcon as it is done separately (suggested by Ville)
v3: Added helper and limited eDP restriction to port A (Ville)
v4: Dropped some redundant checks (Ville)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5389
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220324120438.1876445-1-uma.shankar@intel.com
Print I/O voltage and process info for each combo phy ports.
v2: Used drm_dbg_kms for logs. (Jani)
Added names for different voltage levels. (Imre)
v3: Used const char * for names. (Jani)
v4: Dropped the procom values and changed commit msg (Imre)
Suggested-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220323094307.2439004-1-ankit.k.nautiyal@intel.com
Rename the DRRS functiosn to say "(de)activate" rather than
"enable/disable". This let's us differentiate between the
logically enabled vs. actually currently active cases.
v2: Fix kernel doc for intel_drrs_deactivate()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315132752.11849-10-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Make the dbuf bandwidth min cdclk calculations match the spec
more closely. Supposedly the arbiter can only guarantee an equal
share of the total bandwidth of the slice to each active plane
on that slice. So we take the max bandwidth of any of the planes
on each slice and multiply that by the number of active planes
on the slice to get a worst case estimate on how much bandwidth
we require.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-9-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
The current code also forgets to call intel_atomic_lock_global_state()
when other stuff besides the final min_cdlck changes in the state.
That means we may throw away data which actually has changed, and
thus we can't be at all sure what the code ends up doing during
subsequent commits. Do the write lock properly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-8-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is
somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no
(at least documented) dbuf min cdclk limit on pre-skl so let's just get
rid of all this confusion.
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-6-ville.syrjala@linux.intel.com
There's really no need to maintain these total[] arrays to
track the size of each plane's ddb allocation. We just stick
the results straight into the crtc_state ddb tracking structures.
The main annoyance with all this is the mismatch between
wm_uv vs. ddb_y on pre-icl. If only the hw was consistent in
what it considers the primary source of information we could
avoid some of the uglyness. But since that is not the case
we need a bit of special casing for planar formats.
v2: Keep the ddb entry zeroed when the plane is disabled
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-5-ville.syrjala@linux.intel.com
Handle the plane relative data rate in exactly the same
way as we already handle the real data rate. Ie. pre-calculate
it during intel_plane_atomic_check_with_state(), and assign/clear
it for the Y plane as needed. This should guarantee that the
tracking is 100% consistent, and makes me have to think less
when the same apporach is used by both types of data rate.
We might even want to consider replacing the relative
data rate with the real data rate entirely, but it's not
clear if that will produce less optimal plane ddb
allocations. So for now lets keep using the current approach.
v2: Rebase due to async flip wm optimization
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-4-ville.syrjala@linux.intel.com
Split the currently combined plane data_rate into the proper
Y vs. CbCr components. This matches how we now track the
plane dbuf allocations, and thus will make the dbuf bandwidth
calculations actually produce the correct numbers for each
dbuf slice.
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-3-ville.syrjala@linux.intel.com
Let's store the plane allocation in a manner which more closely
matches how the hw operates. That is, we store the packed/CbCr
ddb in one struct, and the Y ddb in another. Currently we're
storing packed/Y in one struct, CbCr in the other.
This also works pretty well for icl+ where the UV plane is
the main plane and the Y plane is subservient to it. Although
in this case we do not even use ddb_y as we do the ddb allocation
in terms of hw planes.
v2: Rebase
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220303191207.27931-2-ville.syrjala@linux.intel.com
A few more updates in the alderlake-P voltage swing tables.
eDP HBR3 table was the same as icelake one but now it has changes for
voltage 0 and pre-emphasis 2 line.
And DP tables also had one line change in each.
Bspec: 49291
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220315205122.202701-1-jose.souza@intel.com
