This is a scripted split of the display related register macros from
i915_reg.h to display/intel_display_regs.h. As a starting point, move
all the macros that are only used in display code (or GVT). If there are
users in core i915 code or soc/, or no users anywhere, keep the macros
in i915_reg.h. This is done in groups of macros separated by blank
lines, moving the comments along with the groups.
Some manually picked macro groups are kept/moved regardless of the
heuristics above.
This is obviously a very crude approach. It's not perfect. But there are
4.2k lines in i915_reg.h, and its refactoring has ground to a halt. This
is the big hammer that splits the file to two, and enables further
cleanup.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> # v2
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250606102256.2080073-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Define the DP register contents using the REG_BIT, REG_GENMASK,
etc. macros. Ditch the unhelpful comments. Rename eDP related register
content macros to have EDP_ prefix.
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://lore.kernel.org/r/20250423100213.720585-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With the PCH macros switched to use struct intel_display, we have a
number of files that no longer need struct drm_i915_private or anything
else from i915_drv.h anymore. Remove the #include, and add the missing
includes that were previously implicit.
v2: Drop even more of the includes
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://lore.kernel.org/r/5dc9e6a98461c344febac4c645875d8688eba906.1744880985.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Now that INTEL_PCH_TYPE() and HAS_PCH_*() macros are under display, and
accept a struct intel_display pointer, use that instead of struct
drm_i915_private pointer in display code.
This is done naively by running:
$ sed -i 's/\(INTEL_PCH_TYPE\|HAS_PCH_[A-Z0-9_-]*\)([^)]*)/\1(display)/g' \
$(find drivers/gpu/drm/i915/display -name "*.c")
and fixing the fallout, i.e. removing unused local i915 variables and
adding display variables where needed.
v2: Rebase
Reviewed-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Link: https://lore.kernel.org/r/999f4d7b8ed11739b1c5ec8d6408fc39d5e3776b.1744880985.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Have chv_data_lane_soft_reset() get/put dpio internally, and use a
locked version of it within intel_dpio_phy.c. This drops the dependency
on vlv sideband from g4x_dp.c and g4x_hdmi.c, and makes that a DPIO PHY
implementation detail.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250411102715.613082-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The intel_dp::link_trained flag indicates whether the link is active,
regardless of whether the link training passed or failed. For clarity
rename the flag to 'active'. While at it move the flag under
intel_dp::link.
Suggested-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250404150310.1156696-2-imre.deak@intel.com
Move hdcp_mutex, num_hdcp_streams, hdcp_auth_status, hdcp_port_data, and
hdcp_mst_type1_capable members of struct intel_digital_port under an
hdcp sub-struct to group hdcp related things together.
Rename them mutex, num_streams, auth_status, port_data, and
mst_type1_capable for clarity.
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9da4be57b068acd06dec8b93977f0a70627103d4.1740746939.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Convert the remaining intel_display_power.h interfaces to
take struct intel_display instead of struct drm_i915_private.
intel_display_power.c still has some internal uses due to
i915->runtime_pm.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250211000135.6096-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Pass intel_display to the display power stuff. These are spread
all over the place so tend to hinder clean conversions of whole
files.
TODO: The gt part/unpark power domain shenanigans need some
kind of more abstract interface...
v2: Deal with cmtg
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/20250206185533.32306-7-ville.syrjala@linux.intel.com
Add to_intel_uncore() function to avoid the inclusion of i915_drv.h from
intel_de.h. This reveals a number of implicit dependencies on i915_drv.h
that need to be added.
For now, to_intel_uncore() can be an inline function, with all the
includes in compat intel_uncore.h, as long as i915_drv.h isn't
included. The implicit dependencies on i915_drv.h is a problem in
display code, but the same is not true for xe_device.h etc.
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/377e2b400d126776224fc49874ed9cb03ac3123c.1732104170.git.jani.nikula@intel.com
It does not look like anything in intel_dp_compute_config() after the
g4x_dp_set_clock() call depends on the changes it makes, namely setting
dpll and clock_set in crtc_state. Move the call one level higher to
g4x_dp_compute_config() to reduce the clutter in
intel_dp_compute_config().
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241211125431.680227-2-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Add g4x_dp_compute_config() instead of using intel_dp_compute_config()
directly, in order to slightly reduce the clutter in the latter wrt
->has_pch_encoder.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241211125431.680227-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
While updating the source OUI on the sink the driver should avoid
writing the OUI if it's already up-to-date to prevent the sink from
resetting itself in response to the update. On eDP - the only output
type where the OUI was updated so far - the driver ensured this by
comparing the current source OUI DPCD register values with the expected
Intel OUI value, skipping the update in case of a match. On some non-eDP
sinks - at least on Synaptics branch devices - this method doesn't work,
since the source OUI DPCD registers read back as all 0, even after
updating the registers.
Handle the above kind of sinks by tracking when the OUI was updated and
so should be valid, regardless of what the DPCD registers contain.
eDP sinks reset the written source OUI value when the panel power is
disabled, invalidate the OUI state accordingly.
This is required by a follow-up patch updating the source OUI for
non-eDP sink types as well.
v2: Fix setting intel_dp::oui_valid=true, if the DPCD register contains
already the expected value.
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/20241025160259.3088727-5-imre.deak@intel.com
struct intel_display will replace struct drm_i915_private as the main
device pointer for display code. Switch vlv_wait_port_ready() over to
it. The main motivation to do just one function is to stop passing i915
to intel_de_wait(), so its generic wrapper can be removed.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9505ea49dfc8c7a52cacd2749875a680b01e5bbd.1730146000.git.jani.nikula@intel.com
Convert I915_STATE_WARN() to struct intel_display *, and rename to
INTEL_DISPLAY_STATE_WARN(). Do some minor opportunistic struct
drm_i915_private to struct intel_display conversions while at it.
v2: crtc_state may be NULL in intel_connector_verify_state()
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241024162510.2410128-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Simplify things by retraining a DP link if a bad link is detected in the
hotplug handler from the encoder's check link state work, similarly to
how this is done after a modeset link training failure.
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/20240610164933.2947366-12-imre.deak@intel.com
The next patch adds sending a modeset-retry uevent after a link training
failure to all MST connectors on link. This requires the atomic state,
so pass it to intel_dp_start_link_train(). In case of SST where
retraining still happens by calling this function directly instead of a
modeset commit the atomic state is not available and NULL is passed
instead. This is ok, since in this case the encoder's only DP connector
is available from intel_dp->attached_connector not requiring the atomic
state.
v2: Add NOTE that the atomic state may not be valid for SST links and
assert that it's valid for MST links. (Ville)
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@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240610164933.2947366-10-imre.deak@intel.com
Recheck the link state after a passing link training, with a 2 sec delay
to account for cases where the link goes bad following the link training
and the sink doesn't report this via an HPD IRQ.
The delayed work added here will be also used by a later patch after a
failed link training to try to retrain the link with unchanged link
params before reducing the link params.
v2: Don't flush an uninitialized delayed work (on HDMI-only DDI ports).
v3:
- Move the helpers to a new intel_encoder.c file, rename them
accordingly. (Ville)
- Add the work to intel_encoder instead of intel_digital_port.
- Call the encoder specific link check function via an encoder hook.
- Flush the link check work during encoder destroy from
intel_dp_encoder_flush_work().
- Flush the link check work during encoder suspend as well.
v4: Call intel_encoder_link_check_init() with a valid encoder pointer.
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/20240610181428.2955658-1-imre.deak@intel.com
Looks like I misplaced a few hunks when I moved the audio
enable/disable out from the encoder enable/disable hooks.
So we are now doing a double audio enable/disable on SDVO
and g4x+ DP. Probably harmless as doing it twice shouldn't
really change anything, but let's do it just once, as intended.
Fixes: cff742cc68 ("drm/i915: Hoist the encoder->audio_{enable,disable}() calls higher up")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240226193251.29619-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Add encoder vfuncs for audio enable/disable. This will allow
audio to be enabled/disabled during fastsets. An encoder hook
is necessary as on pre-hsw platforms different encoder types
implement audio in different ways.
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/20231121054324.9988-9-ville.syrjala@linux.intel.com
Follow the hsw+ approach toggle the audio presence detect
when we set up the ELD, instead of doing it when turning the
port on/off.
This will facilitate audio enable/disable to happen during
fastsets instead of requiring a full modeset.
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/20231121054324.9988-7-ville.syrjala@linux.intel.com
Push the audio enable/disable to be the last/first thing
respectively that is done in the encoder enable/disable hooks.
The goal is to move it further out of these encoder hooks entirely.
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/20231121054324.9988-5-ville.syrjala@linux.intel.com
Track DP enhanced framing properly in the crtc state instead
of relying just on the cached DPCD everywhere, and hook it
up into the state check and dump.
v2: Actually set enhanced_framing in .compute_config()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230503113659.16305-1-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Stop with the VBT AUX CH sanitation, and instead just check
that the appropriate AUX CH is still available when initializing
a DP/TC port.
The reason being that we want to start initializing ports in
VBT order to deal with VBTs that declare child devices with
seemingly conflicting ports. As the encoder initialization can
fail for other reasons (at least for eDP+AUX) we can't know
upfront which way the conflicts should be resolved.
Note that the old way of sanitizing gave priority to the last
port declared in the VBT, but now we sort of do the opposite by
favoring the first encoder to successfully initialize. The reason
for the old "last port wins" preference was eg. Asrock B250M-HDV
where port A (eDP) and port E (DP->VGA) have an AUX CH conflict
and we need to prefer port E. However with the new way port A (eDP)
will be probed first, but will fail to probe due to HPD and thus
port E will still win in the end.
v2: Pimp the commit message (Jani)
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/20230630155846.29931-5-ville.syrjala@linux.intel.com
Sprinkle some asserts to catch any mishaps in the port_mask
vs. output init.
For DDI/DP/HDMI/SDVO I decided that we want to bail out for
an invalid port since those are the encoder types where
we might want consider driving the whole thing from the VBT
child device list, and bogus VBTs could be a real issue
(if for no other reason than the i915.vbt_firmware).
For DVO and HSW/BDW CRT port I just threw the assert in
there for good measure.
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/20230616140820.11726-5-ville.syrjala@linux.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 idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).
The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B live state it
sees the stuck live state of DP-D instead. If I hack
the driver to not register DP-D at all, and thus we never
enabe DP-D HPD, DP-B stops working as well.
Just to put some conclusive evidence into this mess,
here are the actual hotplug register values for each port:
Everything disconnected:
PORT_HOTPLUG_EN (0x00061110): 0x00000000
PORT_HOTPLUG_STAT (0x00061114): 0x00000000
PORT_HOTPLUG_EN (0x00061110): 0x08000000
PORT_HOTPLUG_STAT (0x00061114): 0x08000000
PORT_HOTPLUG_EN (0x00061110): 0x10000000
PORT_HOTPLUG_STAT (0x00061114): 0x00000000
PORT_HOTPLUG_EN (0x00061110): 0x20000000
PORT_HOTPLUG_STAT (0x00061114): 0x00000000
Only port B connected:
PORT_HOTPLUG_EN (0x00061110): 0x00000000
PORT_HOTPLUG_STAT (0x00061114): 0x00000000
PORT_HOTPLUG_EN (0x00061110): 0x08000000
PORT_HOTPLUG_STAT (0x00061114): 0x08000000
PORT_HOTPLUG_EN (0x00061110): 0x10000000
PORT_HOTPLUG_STAT (0x00061114): 0x00000000
PORT_HOTPLUG_EN (0x00061110): 0x20000000
PORT_HOTPLUG_STAT (0x00061114): 0x20000000
Only port C connected:
PORT_HOTPLUG_EN (0x00061110): 0x00000000
PORT_HOTPLUG_STAT (0x00061114): 0x00000000
PORT_HOTPLUG_EN (0x00061110): 0x08000000
PORT_HOTPLUG_STAT (0x00061114): 0x08000000
PORT_HOTPLUG_EN (0x00061110): 0x10000000
PORT_HOTPLUG_STAT (0x00061114): 0x10000000
PORT_HOTPLUG_EN (0x00061110): 0x20000000
PORT_HOTPLUG_STAT (0x00061114): 0x00000000
So the enable bit and live state bit always match 1:1.
Acked-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/20230302161013.29213-4-ville.syrjala@linux.intel.com
Restructure intel_bios_port_aux_ch() to resemble the ddc_pin
counterpart, where the intel_bios.c stuff only deals with the
child device definition, and the platform default will come from
elsewhere.
This requires the introduction of AUX_CH_NONE as the value 0
is already taken to mean AUX_CH_A.
v2: Sort includes alphabetically (Ankit)
vCould we ask them to do a BIOS fix for all of them so that
we wouldn't keep getting these bug reports for each model
separately?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230216231312.32664-1-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Currently intel_bios_port_aux_ch() digs out the devdata
(VBT child device info) from the vbt.ports[] array. We
need to get rid of that, so just pass in the correct
encoder->devdata (now that we have it also for g4x+ ports)
directly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
