summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/display/g4x_dp.c
AgeCommit message (Collapse)Author
2024-12-16drm/i915/uncore: add to_intel_uncore() and use itJani Nikula
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
2024-12-11drm/i915/dp: move g4x_dp_set_clock() call to g4x_dp_compute_config()Jani Nikula
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>
2024-12-11drm/i915/dp: add g4x_dp_compute_config()Jani Nikula
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>
2024-10-31drm/i915/dp: Track source OUI validity explicitlyImre Deak
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
2024-10-30drm/i915/display: convert vlv_wait_port_ready() to struct intel_displayJani Nikula
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
2024-10-29drm/i915/display: convert I915_STATE_WARN() to struct intel_displayJani Nikula
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>
2024-09-23drm/i915/dp: clean up intel_dp_test.[ch] interfaceJani Nikula
Conform to uniform function naming. Use intel_dp. Hide checks on intel_dp->compliance within intel_dp_test.[ch]. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c2905006d2d47040032153ca69052898529a95d5.1726833193.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-23drm/i915/dp: split out intel_dp_test.[ch] to a dedicated fileJani Nikula
intel_dp.c has become huge, over 7k lines. Split out the fairly well isolated chunk of DP test code to a dedicated file intel_dp_test.[ch]. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/262d565fe59715ba297702b67d4bcca81c736dc0.1726833193.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-19drm/i915/pps: move vlv_active_pipe() to intel_pps.cJani Nikula
All the users for vlv_active_pipe() are within intel_pps.c now, and there are already uses of g4x_dp_port_enabled() and intel_dp->output_reg in there, so seems fine to reduce interfaces and move vlv_active_pipe() to intel_pps.c too. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e12ae0a931f113f3bbbf1b4c66108b572a933efb.1726681620.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-19drm/i915/pps: rename vlv_pps_init() to vlv_pps_port_enable_unlocked()Jani Nikula
Follow the naming for vlv_pps_port_disable(), as these are counterparts, and add _unlocked suffix as it assumes the pps lock is held. v2: Add _unlocked suffix (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3b21141025a5e1e67f28bbe67a82a7008fd3f415.1726681620.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-19drm/i915/pps: add vlv_pps_port_disable()Jani Nikula
Add vlv_pps_port_disable() and move the VLV/CHV active pipe clear there from intel_dp_link_down(), hiding the PPS pipe details inside PPS code. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2546716a448205ca5af085cec9faeb5e5deac287.1726681620.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-19drm/i915/pps: add vlv_pps_pipe_reset()Jani Nikula
We need to track PPS also for non-eDP usage on VLV/CHV. Add new vlv_pps_pipe_reset() for resetting the related parts, hiding the PPS pipe details inside PPS code. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e1bae913533baea8e502d8c63c06f6852a1cdb93.1726681620.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-19drm/i915/pps: add vlv_ prefix to pps_pipe and active_pipe membersJani Nikula
The pps_pipe and active_pipe members of struct intel_pps are only relevant on VLV/CHV. Prefix them with vlv_. Note that there are still a few cases where they're accessed on non-VLV/CHV paths. We'll fix them separately. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0e9a8998fc37796eb6f32692977859807222ce0a.1726681620.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-09-03drm/i915/dp: convert g4x_dp.[ch] to struct intel_displayJani Nikula
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert g4x_dp.[ch] to struct intel_display. Some stragglers are left behind where needed. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b80ffb6373e9e3daaba0762ff7aebe168511b3a7.1725012870.git.jani.nikula@intel.com
2024-08-12drm/i915/bios: convert to struct intel_displayJani Nikula
Going forward, struct intel_display shall replace struct drm_i915_private as the main display device data pointer type. Convert intel_bios.[ch] to struct intel_display. Do one drive-by conversion of unnecessary hex usage to decimal. Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0d0261a53aff5f141b16b482222a5ffce78e176e.1723213547.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-06-13drm/i915/dp: Use check link state work in the hotplug handlerImre Deak
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
2024-06-13drm/i915/dp: Pass atomic state to link training functionImre Deak
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
2024-06-13drm/i915/dp: Recheck link state after modesetImre Deak
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
2024-06-07drm/i915: pass dev_priv explicitly to PORT_HOTPLUG_STATJani Nikula
Avoid the implicit dev_priv local variable use, and pass dev_priv explicitly to the PORT_HOTPLUG_STAT register macro. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9a47bba4ab8fa4b1a8e8ceea2ba5301bed54805d.1717514638.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-03-06drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DPVille Syrjälä
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: cff742cc6851 ("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>
2023-11-23drm/i915: Hoist the encoder->audio_{enable,disable}() calls higher upVille Syrjälä
Push the encoder->audio_{enable,disable}() calls out from the encoder->{enable,disable}() hooks. Moving towards audio fastset. 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-10-ville.syrjala@linux.intel.com
2023-11-23drm/i915: Convert audio enable/disable into encoder vfuncsVille Syrjälä
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
2023-11-23drm/i915: Split g4x+ DP audio presence detect from port enableVille Syrjälä
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
2023-11-23drm/i915: Wrap g4x+ DP/HDMI audio enable/disableVille Syrjälä
Put a wrapper around the intel_audio_codec_{enable,disable}() calls in the g4x+ DP/HDMI code. We shall move the presence detect enable/disable into the wrappers later. 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-6-ville.syrjala@linux.intel.com
2023-11-23drm/i915: Push audio enable/disable further outVille Syrjälä
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
2023-09-13drm/i915: Introduce crtc_state->enhanced_framingVille Syrjälä
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>
2023-07-06drm/i915: Remove AUX CH sanitationVille Syrjälä
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
2023-07-06drm/i915: Initialize dig_port->aux_ch to NONE to be sureVille Syrjälä
Make sure dig_port->aux_ch is trustworthy by initializing it to NONE (-1) at the start. The encoder init will later fill in the actual value, if appropriate. 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-2-ville.syrjala@linux.intel.com
2023-06-20drm/i915: Assert that the port being initialized is validVille Syrjälä
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
2023-05-15drm/i915/display: add i915 parameter to I915_STATE_WARN()Jani Nikula
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
2023-03-07drm/i915: Get rid of the gm45 HPD live state nonsenseVille Syrjälä
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
2023-02-17drm/i915: Restructure intel_bios_port_aux_ch()Ville Syrjälä
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>
2023-02-16drm/i915/display/misc: use intel_de_rmw if possibleAndrzej Hajda
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230110113656.4050491-1-andrzej.hajda@intel.com
2023-02-14drm/i915: Pass devdata to intel_bios_port_aux_ch()Ville Syrjälä
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>
2023-02-14drm/i915: Populate encoder->devdata for g4x+ DP/HDMI portsVille Syrjälä
Let's make encoder->devdata (the VBT information for the port) available on g4x+ platforms as well. Much easier when you can just grab it there instead of trying to find it from some global list array based on the port. Note that (unlike DDI platforms) we don't currently require that each DP/HDMI port is actually declared in VBT. Perhaps in the future we may want to rethink that, but for now just stick in a debug+FIXME as a reminder. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208015508.24824-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-25drm/i915/audio: Hardware ELD readoutVille Syrjälä
Read out the ELD from the hardware buffer, or from our stashed copy for the audio component, so that we can hook up the state checker to validate it. v2: Deal with the platforms using acomp Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 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-7-ville.syrjala@linux.intel.com
2022-12-08drm/i915: Fix VLV/CHV HDMI/DP audio enableVille Syrjälä
Despite what I claimed in commit c3c5dc1d9224 ("drm/i915/audio: Do the vblank waits") the vblank interrupts are in fact not enabled yet when we do the audio enable sequence on VLV/CHV (all other platforms are fine). Reorder the enable sequence on VLV/CHV to match that of the other platforms so that the audio enable happens after the pipe has been enabled. Fixes: c3c5dc1d9224 ("drm/i915/audio: Do the vblank waits") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221207225219.29060-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-11-11drm/i915: stop including i915_irq.h from i915_trace.hJani Nikula
Turns out many of the files that need i915_reg.h get it implicitly via {display/intel_de.h, gt/intel_context.h} -> i915_trace.h -> i915_irq.h -> i915_reg.h. Since i915_trace.h doesn't actually need i915_irq.h, makes sense to drop it, but that requires adding quite a few new includes all over the place. Prefer including i915_reg.h where needed instead of adding another implicit include, because eventually we'll want to split up i915_reg.h and only include the specific registers at each place. Also some places actually needed i915_irq.h too. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6e78a2e0ac1bffaf5af3b5ccc21dff05e6518cef.1668008071.git.jani.nikula@intel.com
2022-08-29drm/i915: move hotplug to display.hotplugJani Nikula
Move display hotplug related members under drm_i915_private display sub-struct. Rename struct i915_hotplug to intel_hotplug while at it. 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/c1c7562a31c115e9d6a131861e4ca9c97d4f7e09.1661346845.git.jani.nikula@intel.com
2022-05-27drm/i915: Extract intel_edp_fixup_vbt_bpp()Ville Syrjälä
We have the same "override eDP VBT bpp with the current bpp" code duplciated in two places. Extract it to a helper function. TODO: Having this in .get_config() is pretty ugly. Should probably try to move it somewhere else (setup_hw_state()/etc.)... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-04-20drm/i915: Sanitize the port -> DDI/AUX power domain mapping for each platformImre Deak
Atm the port -> DDI and AUX power domain mapping is specified by relying on the aliasing of the platform specific intel_display_power_domain enum values. For instance D12+ platforms refer to the 'D' port and power domain instances, which doesn't match the bspec terminology, on these platforms the corresponding port is TC1. To make it clear what port/domain the code refers to add a mapping between them which matches the bspec terms on different display versions. This also allows for removing the aliasing in enum values in a follow-up patch. v2: Add the functions to intel_display_power.c, use intel_display_power_ prefix. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220414210657.1785773-14-imre.deak@intel.com
2022-03-30drm/i915/audio: move has_audio checks to within codec enable/disableJani Nikula
Reduce duplication. 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-2-jani.nikula@intel.com
2022-03-30drm/i915/audio: unify audio codec enable/disable debug loggingJani Nikula
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
2022-03-10drm/i915: Remove struct dp_link_dpllVille Syrjälä
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>
2022-03-02drm/i915: Use str_on_off()Lucas De Marchi
Remove the local onoff() implementation and adopt the str_on_off() from linux/string_helpers.h. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220225234631.3725943-4-lucas.demarchi@intel.com
2022-02-01drm/i915: Program pch transcoder m2/n2Ville Syrjälä
Program the PCH transcoder M2/N2 values appropriately. We're still missing a few things for PCH port DRRS but at least this means we can do readout/state check for dp_m2_n2 unconditionally. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-15-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Move PCH transcoder M/N setup into the PCH codeVille Syrjälä
Do the PCH transcoder M/N setup next to where all the other PCH transcoder stuff is programmed. Matches the spec modeset sequence better. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Split intel_cpu_transcoder_get_m_n() into M1/N1 vs. M2/N2 variantsVille Syrjälä
As with intel_cpu_transcoder_set_m_n() let's split the readout counterpart into explicit M1/N1 vs. M2/N2 variants as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-02-01drm/i915: Nuke intel_dp_get_m_n()Ville Syrjälä
As with intel_dp_set_m_n() let's get rid of the wrapper and just call the relevant PCH vs. CPU transcoder functions directly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-12-09drm/i915/trace: split out display trace to a separate fileJani Nikula
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