#
f378ab78 |
|
26-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Stop doing double audio enable/disable on SDVO and g4x+ DP 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> (cherry picked from commit 315bd0a0825776d6c66d474bf572db64fa019ad8) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
bf7626f1 |
|
20-Feb-2024 |
Maxime Ripard <mripard@kernel.org> |
drm/i915/tv: Fix TV mode Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed to update all the users of the struct drm_tv_connector_state mode field, which resulted in a build failure in i915. However, a subsequent commit in the same series reintroduced a mode field in that structure, with a different semantic but the same type, with the assumption that all previous users were updated. Since that didn't happen, the i915 driver now compiles, but mixes accesses to the legacy_mode field and the newer mode field, but with the previous semantics. This obviously doesn't work very well, so we need to update the accesses that weren't in the legacy renaming commit. Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220131251.453060-1-mripard@kernel.org
|
#
3a86cb16 |
|
12-Feb-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Prevent HW access during init from connector get_modes hooks Prevent accessing the HW from the get_modes hooks of connectors deriving the mode list from the display's EDID. drm_edid_connector_add_modes() will return the mode list based on the EDID which was cached during a previous detection/get_modes call. This also fixes the NULL deref problem (10085) which was introduced/revealed by commit bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown") After the above change MST connectors will not change state during driver init/shutdown; thus some of these connectors with no I2C/DDC adapter registered for them (since the given MST port has no sink connected) may stay then in the 'unknown' connector status. The get_modes() hook should not try to use the I2C/DDC adapter in this state (which would lead to the above NULL deref) which this patch ensures. v2: - Remove the redundant check from intel_crt_ddc_get_modes(). - Rebase on latest drm-tip. - Add Fixes: line / related commit notes. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10085 Fixes: bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown") 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/20240212175237.2625812-2-imre.deak@intel.com
|
#
5c5a7fa6 |
|
12-Feb-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Prevent HW access during init from SDVO TV get_modes hook Prevent accessing the HW from the SDVO/TV get_modes connector hook. Returning 0 from the hook will make the caller - drm_helper_probe_single_connector_modes() - return a default/EDID override mode list to users. This matches the case where intel_sdvo_get_tv_modes() fails to retrieve the current mode list due to a HW access failure. v2: Clarify the commit message wrt. which modes get_modes() returns. (Jouni) 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/20240212175237.2625812-1-imre.deak@intel.com
|
#
ca93f9f3 |
|
08-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Fix up code alignment Realign a bunch of code that has become messy. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
dff8f3f8 |
|
08-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Convert to per-device debugs Use drm_dbg_kms() instead of DRM_DEBUG_KMS() in the sdvo code to get the device name into the debug prints. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
bab87ef4 |
|
04-Jan-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Disable hotplug detection handlers during driver init/shutdown As described in the previous two patches an unexpected connector detection can happen during the init/shutdown sequences. Prevent these by returning the connector's current status from the detection handlers. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-10-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
|
#
289d4180 |
|
04-Jan-2024 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Init DRM connector polled field early After an HPD IRQ storm on a connector intel_hpd_irq_storm_detect() will set the connector's HPD pin state to HPD_MARK_DISABLED and the IRQ gets disabled. Subsequently intel_hpd_irq_storm_switch_to_polling() will enable polling for these connectors, setting the pin state to HPD_DISABLED, but only if the connector's base.polled field is set to DRM_CONNECTOR_POLL_HPD. intel_hpd_irq_storm_reenable_work() will reenable the IRQ - after 2 minutes - if the pin state is HPD_DISABLED. The connectors will be created with their base.polled field set to 0, which gets initialized only later in i915_hpd_poll_init_work() (using intel_connector::polled). If a storm is detected on a connector after it's created and IRQs are enabled on it - by intel_hpd_init() - and before its bease.polled field is initialized in the above work, the connector's HPD pin will stay in the HPD_MARK_DISABLED state - leaving the IRQ disabled indefinitely - and polling will not get enabled on it as intended. I can't see a reason for initializing base.polled in a delayed manner, so do this already when creating the connector, to prevent the above race condition. Link: https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-2-imre.deak@intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com>
|
#
fb1e8812 |
|
20-Feb-2024 |
Maxime Ripard <mripard@kernel.org> |
drm/i915/tv: Fix TV mode Commit 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") failed to update all the users of the struct drm_tv_connector_state mode field, which resulted in a build failure in i915. However, a subsequent commit in the same series reintroduced a mode field in that structure, with a different semantic but the same type, with the assumption that all previous users were updated. Since that didn't happen, the i915 driver now compiles, but mixes accesses to the legacy_mode field and the newer mode field, but with the previous semantics. This obviously doesn't work very well, so we need to update the accesses that weren't in the legacy renaming commit. Fixes: 1fd4a5a36f9f ("drm/connector: Rename legacy TV property") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240220131251.453060-1-mripard@kernel.org (cherry picked from commit bf7626f19d6ff14b9722273e23700400cc4d78ba) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
#
e965a707 |
|
23-Nov-2023 |
Heiner Kallweit <hkallweit1@gmail.com> |
drm: remove I2C_CLASS_DDC support After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can remove this class completely now. Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org>
|
#
e0ef2daa |
|
27-Nov-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Skip some timing checks on BXT/GLK DSI transcoders Apparently some BXT/GLK systems have DSI panels whose timings don't agree with the normal cpu transcoder hblank>=32 limitation. This is perhaps fine as there are no specific hblank/etc. limits listed for the BXT/GLK DSI transcoders. Move those checks out from the global intel_mode_valid() into into connector specific .mode_valid() hooks, skipping BXT/GLK DSI connectors. We'll leave the basic [hv]display/[hv]total checks in intel_mode_valid() as those seem like sensible upper limits regardless of the transcoder used. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720 Fixes: 8f4b1068e7fc ("drm/i915: Check some transcoder timing minimum limits") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231127145028.4899-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
3654a48a |
|
20-Nov-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Convert audio enable/disable into encoder vfuncs 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
|
#
439590ac |
|
30-Oct-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/edid: include drm_eld.h only where required Reduce the dependencies on drm_eld.h. Some files might be able to drop the dependency on drm_edid.h too with the direct inclusion of drm_eld.h. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9f5963ce900d747f3279312c0cd1da599fd83f94.1698747331.git.jani.nikula@intel.com
|
#
20c2dbff |
|
27-Nov-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Skip some timing checks on BXT/GLK DSI transcoders Apparently some BXT/GLK systems have DSI panels whose timings don't agree with the normal cpu transcoder hblank>=32 limitation. This is perhaps fine as there are no specific hblank/etc. limits listed for the BXT/GLK DSI transcoders. Move those checks out from the global intel_mode_valid() into into connector specific .mode_valid() hooks, skipping BXT/GLK DSI connectors. We'll leave the basic [hv]display/[hv]total checks in intel_mode_valid() as those seem like sensible upper limits regardless of the transcoder used. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720 Fixes: 8f4b1068e7fc ("drm/i915: Check some transcoder timing minimum limits") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231127145028.4899-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit e0ef2daa8ca8ce4dbc2fd0959e383b753a87fd7d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
#
eebc1525 |
|
12-Oct-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/display: Clean up zero initializers Just use a simple {} to zero initialize arrays/structs instead of the hodgepodge of stuff we are using currently. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231012122442.15718-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
fe63ea7c |
|
03-Oct-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: convert INTEL_DISPLAY_ENABLED() into a function There's no need for this to be a macro. Add some documentation too. 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/480b9b697b2ffa0c8677115bd443ba633801c6c1.1696336887.git.jani.nikula@intel.com
|
#
998d2cd3 |
|
21-Sep-2023 |
Imre Deak <imre.deak@intel.com> |
drm/i915/fdi: Improve FDI BW sharing between pipe B and C At the moment modesetting pipe C on IVB will fail if pipe B uses 4 FDI lanes. Make the BW sharing more dynamic by trying to reduce pipe B's link bpp in this case, until pipe B uses only up to 2 FDI lanes. For this instead of the encoder compute config retry loop - which reduced link bpp only for the encoder's pipe - reduce the maximum link bpp for pipe B/C as required after all CRTC states are computed and recompute the CRTC states with the new bpp limit. Atm, all FDI encoder's compute config function returns an error if a BW constrain prevents increasing the pipe bpp value. The corresponding crtc_state->bw_constrained check can be replaced with checking crtc_state->max_link_bpp_x16, add TODO comments for this. SDVO is an exception where this case is only handled in the outer config retry loop, failing the modeset with a WARN, add a FIXME comment to handle this in the encoder code similarly to other encoders. v2: - Don't assume that a CRTC is already in the atomic state, while reducing its link bpp. - Add DocBook description to intel_fdi_atomic_check_link(). v3: - Enable BW management for FDI links in a separate patch. (Ville) v4: (Ville) - Fail the SDVO encoder config computation if it doesn't support the link bpp limit. - Add TODO: comments about checking link_bpp_x16 instead of bw_constrained. v5: - Replace link bpp limit check with a FIXME: comment in intel_sdvo_compute_config(). (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [Amended commit message wrt. changes in v5] Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921195159.2646027-11-imre.deak@intel.com
|
#
32c32155 |
|
29-Aug-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Constify mapping structs We aren't intending to mutate the SDVO device mapping structs, so make them const. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
e1039cde |
|
24-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: use drm_edid_is_digital() Reduce the use of struct edid and drm_edid_raw(). 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/dbc0269d34f3140aff410eefae8a2711c59299b3.1692884619.git.jani.nikula@intel.com
|
#
9c7e9db1 |
|
25-Aug-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Print out the i2c pin and slave address To reduce the guesswork a bit let's print out the SDVO device i2c bus and slave address during init. 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/20230825134431.24391-7-ville.syrjala@linux.intel.com
|
#
c0ff6c6e |
|
25-Aug-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Rework DDC bus handling Each SDVO device can have up to three sets of DDC pins. Currently we just register a single i2c_adapter for the entire SDVO device and semi-randomly pick the "correct" set of DDC pins during intel_sdvo_tmds_sink_detect(). This doesn't make any real sense especially if we have multiple outputs each with their own dedicated DDC bus. Let's clean up this mess and register a dedicated i2c_adapter for each of the possible pin pairs. Each output (ie. connector) can then pick the correct i2c_adapter to use for its DDC bus. And we can just switch over to drm_connector_init_with_ddc() to take care of the connector->ddc association, which also populates the "ddc" sysfs symlink as a bonus. And now that things are based on the actual connector we can also nuke the sketchy sdvo->controller_output 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/20230825134431.24391-6-ville.syrjala@linux.intel.com
|
#
5bb306b1 |
|
25-Aug-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Get rid of the per-connector i2c symlink We should switch over to the standard "ddc" per-connector symlink instead of rolling our own thing. The i2c specific symlink is also in the way of reworking the SDVO DDC handling (which is a mess atm) so get rid of it. 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/20230825134431.24391-5-ville.syrjala@linux.intel.com
|
#
c6eddd31 |
|
25-Aug-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Nuke the duplicate sdvo->port We already have encoder->port so get rid of the duplicate sdvo->port. 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/20230825134431.24391-4-ville.syrjala@linux.intel.com
|
#
0eb8252a |
|
25-Aug-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Initialize the encoder earlier Call drm_encoder_init() earlier so that we don't have to keep passing the i915/dev_priv around separately. v2: Reorder drm_encoder_cleanup() in the error path (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/20230825134431.24391-3-ville.syrjala@linux.intel.com
|
#
31ea7857 |
|
25-Aug-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Nuke attached_output tracking Instead of operating on the output the user specified (via the connector) the current code tends to operate on whichever outputs it has detected as attached. That is not how the kms uapi is supposed to work. So simply get rid of attached_outputs and instead directly operate on the output the user has specified. 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/20230825134431.24391-2-ville.syrjala@linux.intel.com
|
#
e83d12e0 |
|
05-Jul-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Fail gracefully if the TV dotclock is out of range Instead of warning and continuing with bogus state when the requested dotclock isn't acceptable just print some debug spew and fail gracefully. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
d320aaaa |
|
05-Jul-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Pick the TV dotclock from adjusted_mode port_clock is what the encoder/dpll code is supposed to calculate, it is not the input clock. Use the dotclock as the target we're trying to achieve instead. TODO: the SDVO TV clocking is a mess atm and needs further work Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-7-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
469c0962 |
|
05-Jul-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: s/sdvo_inputs_mask/sdvo_num_inputs/ The SDVO inputs are reported a simple number, not a bitmask. Adjust the code to match reality. Note that we don't actually support dual input SDVO devices, and we just always use the first input. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
a5d1d0a1 |
|
05-Jul-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Protect macro args Put parens around macro argument evaluation for safety. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
1d6f7b19 |
|
05-Jul-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Issue SetTargetOutput prior to GetAttachedDisplays I have at least one SDVO device (some Lenovo DVI-I ADD2 card, based on Conexant CX25904) where GetAttachedDisplays returns success but fails to report any attached displays unless we precede the command with a SetTargetOutput. Make it so. I wasn't able to spot anything in the SDVO spec stating that this should be necessary, but real world wins over spec. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705202122.17915-2-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
|
#
26e60294 |
|
03-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/sdvo: fix panel_type initialization Commit 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") started using -1 as the value for unset panel_type. It gets initialized in intel_panel_init_alloc(), but the SDVO code never calls it. Call intel_panel_init_alloc() to initialize the panel, including the panel_type. Reported-by: Tomi Leppänen <tomi@tomin.site> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8896 Fixes: 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.1+ Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Tomi Leppänen <tomi@tomin.site> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230803122706.838721-1-jani.nikula@intel.com
|
#
90c0756a |
|
03-Aug-2023 |
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> |
drm/i915/sdvo: ignore returned broken edid on intel_sdvo_tmds_sink_detect If drm_edid_raw returned NULL on error don't try accessing anything behind that NULL Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230803143530.27601-1-juhapekka.heikkila@gmail.com
|
#
39432640 |
|
16-Jun-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Beef up SDVO/HDMI port checks The SDVO code already warns when the port in question doesn't actually support SDVO. Let's make that also bail the encoder registration like the generic assert_port_valid() we added. And add a similar thing for g4x HDMI, mainly because on g4x itsefl port D only supports DP but not SDVO/HDMI. For the other platforms the generic port_mask check should actually be sufficient, but since we're here might as well list the ports. 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-6-ville.syrjala@linux.intel.com
|
#
679df6f1 |
|
16-Jun-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Assert that the port being initialized is valid 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
|
#
2002eb6d |
|
03-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/sdvo: fix panel_type initialization Commit 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") started using -1 as the value for unset panel_type. It gets initialized in intel_panel_init_alloc(), but the SDVO code never calls it. Call intel_panel_init_alloc() to initialize the panel, including the panel_type. Reported-by: Tomi Leppänen <tomi@tomin.site> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8896 Fixes: 3f9ffce5765d ("drm/i915: Do panel VBT init early if the VBT declares an explicit panel type") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v6.1+ Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Tomi Leppänen <tomi@tomin.site> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230803122706.838721-1-jani.nikula@intel.com (cherry picked from commit 26e60294e8eacedc8ebb33405b2c375fd80e0900) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
27cbdc6b |
|
29-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: switch the rest of the connectors to struct drm_edid Convert the remaining uses of struct edid based drm_get_edid(), drm_connector_update_edid_property() and drm_add_edid_modes() calls to the struct drm_edid based drm_edid_read_ddc(), drm_edid_connector_update() and drm_edid_connector_add_modes(). Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b1b53bb9004adaa402e061f7df2caf0eb4723a43.1685437501.git.jani.nikula@intel.com
|
#
dd9f377a |
|
29-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/sdvo: stop caching has_hdmi_audio in struct intel_sdvo Use the information stored in display info. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1e02f2f7381dfcee6e4160a5fc17aea6ff04baf9.1685437500.git.jani.nikula@intel.com
|
#
f2f9c8cb |
|
29-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/sdvo: stop caching has_hdmi_monitor in struct intel_sdvo Use the information stored in display info. Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3e9e1dcd554d470bdf474891a431b15e1880f9a0.1685437500.git.jani.nikula@intel.com
|
#
a04d27cd |
|
27-Apr-2023 |
Ankit Nautiyal <ankit.k.nautiyal@intel.com> |
drm/i915/display: Add new member to configure PCON color conversion 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
|
#
15d045fd |
|
25-Jan-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/panel: move panel fixed EDID to struct intel_panel It's a bit confusing to have two cached EDIDs in struct intel_connector with slightly different purposes. Make the distinction a bit clearer by moving the EDID cached for eDP and LVDS panels at connector init time to struct intel_panel, and name it fixed_edid. That's what it is, a fixed EDID for the panels. Cc: Ville Syrjälä <ville.syrjala@linux.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/328350ef918638928a8286cdbab3107c8258332d.1674643465.git.jani.nikula@intel.com
|
#
72715b54 |
|
24-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Do ELD hardware readout Read out the ELD from the hw so the state checker can verify it. v2: Check the "ELD valid" bit separately v3: Fix ELD tx rate handling during readout 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-10-ville.syrjala@linux.intel.com
|
#
b9c92d78 |
|
24-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Only use "presence detect" for has_audio readout Align the SDVO audio code with the native HDMI/DP audio and use just the "presence detect" bit for the has_audio readout. The "ELD valid" bit will be used for ELD readout soon. 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-9-ville.syrjala@linux.intel.com
|
#
8e10cd13 |
|
24-Jan-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Precompute the ELD Use the precomputed crtc_state->eld for audio setup on SDVO just like we do with native HDMI. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@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-8-ville.syrjala@linux.intel.com
|
#
3f9ffce5 |
|
25-Nov-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Do panel VBT init early if the VBT declares an explicit panel type Lots of ADL machines out there with bogus VBTs that declare two eDP child devices. In order for those to work we need to figure out which power sequencer to use before we try the EDID read. So let's do the panel VBT init early if we can, falling back to the post-EDID init otherwise. The post-EDID init panel_type=0xff approach of assuming the power sequencer should already be enabled doesn't really work with multiple eDP panels, and currently we just end up using the same power sequencer for both eDP ports, which at least confuses the wakeref tracking, and potentially also causes us to toggle the VDD for the panel when we should not. Cc: Animesh Manna <animesh.manna@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/20221125173156.31689-3-ville.syrjala@linux.intel.com
|
#
801543b2 |
|
09-Nov-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: stop including i915_irq.h from i915_trace.h 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
|
#
a6ebd538 |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Fix debug print Correctly indicate which outputs we support in the debug print. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
79708d14 |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Reduce copy-pasta in output setup Avoid having to call the output init function for each output type separately. We can just call the right one based on the "class" of the output. Technically we could just walk the bits of the bitmask but that could change the order in which we initialize the outputs. To avoid any behavioural changes keep to the same explicit probe order as before. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
739f8dbc |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Get rid of the output type<->device index stuff Get rid of this silly output type<->device index back and forth and just pass the output type directly to the corresponding output init function. This was already being done for TV outputs anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
5e52622e |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Don't add DDC modes for LVDS Stop enumerating the DDC modes for SDVO LVDS outputs (outside the initial fixed mode setup). intel_panel_mode_valid() will just reject most of them anyway, and any left over are entirely pointless as they'll match the fixed mode hdisp+vdisp+vrefresh so no user visible effect from using them instead of the fixed mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
aa7d827b |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Simplify output setup debugs Get rid of this funny byte based dumping of invalid output flags and just dump it as a single hex numbers. Also do that early since all the rest is going to get skipped anyway of the thing is zero. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
a3cd4f44 |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs drm_mode_probed_add() is unhappy about being called w/o mode_config.mutex. Grab it during LVDS fixed mode setup to silence the WARNs. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
64b7b557 |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Setup DDC fully before output init Call intel_sdvo_select_ddc_bus() before initializing any of the outputs. And before that is functional (assuming no VBT) we have to set up the controlled_outputs thing. Otherwise DDC won't be functional during the output init but LVDS really needs it for the fixed mode setup. Note that the whole multi output support still looks very bogus, and more work will be needed to make it correct. But for now this should at least fix the LVDS EDID fixed mode setup. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
cc1e6639 |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Filter out invalid outputs more sensibly We try to filter out the corresponding xxx1 output if the xxx0 output is not present. But the way that is being done is pretty awkward. Make it less so. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
8388eb06 |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Extract intel_sdvo_has_audio() Pull the SDVO audio state computation into a helper. This is almost identical to intel_hdmi_has_audio(), except the sink capabilities are stored under intel_sdvo rather than intel_hdmi. Might be nice to get rid of this duplication eventually... Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@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/20221026170150.2654-16-ville.syrjala@linux.intel.com
|
#
eb89e83c |
|
27-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes() Since commit a5810f551d0a ("drm/i915: Allow more varied alternate fixed modes for panels") intel_panel_add_edid_alt_fixed_modes() no longer considers vrr vs. drrs separately. So no reason to pass them as separate parameters either. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
8648c604 |
|
12-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up connector->*_allowed setup All the connectors are zero initialized so no need to clear the *_allowed flags we don't support. Only leave the ones we want to set. And while at it switch to booleans instead of ints. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220912111814.17466-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
12caf46c |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs drm_mode_probed_add() is unhappy about being called w/o mode_config.mutex. Grab it during LVDS fixed mode setup to silence the WARNs. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit a3cd4f447281c56377de2ee109327400eb00668d) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
d372ec94 |
|
27-Sep-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify intel_panel_add_edid_alt_fixed_modes() Since commit a5810f551d0a ("drm/i915: Allow more varied alternate fixed modes for panels") intel_panel_add_edid_alt_fixed_modes() no longer considers vrr vs. drrs separately. So no reason to pass them as separate parameters either. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220927180615.25476-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit eb89e83c152b122a94e79527d63cb7c79823c37e) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
e7976251 |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Setup DDC fully before output init Call intel_sdvo_select_ddc_bus() before initializing any of the outputs. And before that is functional (assuming no VBT) we have to set up the controlled_outputs thing. Otherwise DDC won't be functional during the output init but LVDS really needs it for the fixed mode setup. Note that the whole multi output support still looks very bogus, and more work will be needed to make it correct. But for now this should at least fix the LVDS EDID fixed mode setup. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301 Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 64b7b557dc8a96d9cfed6aedbf81de2df80c025d) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
3e206b6a |
|
26-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Filter out invalid outputs more sensibly We try to filter out the corresponding xxx1 output if the xxx0 output is not present. But the way that is being done is pretty awkward. Make it less so. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit cc1e66394daaa7e9f005e2487a84e34a39f9308b) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
|
#
a434689c |
|
29-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move vbt to display.vbt Move display VBT related members under drm_i915_private display sub-struct. v2: Rebase 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/db4b648b201ea0b79654fec2028120999a735db0.1661779055.git.jani.nikula@intel.com
|
#
6434cf63 |
|
19-Jun-2022 |
Animesh Manna <animesh.manna@intel.com> |
drm/i915/bios: calculate panel type as per child device index in VBT Each LFP may have different panel type which is stored in LFP data data block. Based on the child device index respective panel-type/ panel-type2 field will be used. v1: Initial rfc verion. v2: Based on review comments from Jani, - Used panel-type instead addition panel-index variable. - DEVICE_HANDLE_* name changed and placed before DEVICE_TYPE_* macro. v3: - passing intel_bios_encoder_data as argument of intel_bios_init_panel(). Passing NULL to indicate encoder is not initialized yet for dsi as current focus is to enable dual EDP. [Jani] v4: - encoder->devdata used which is initialized before from vbt structure. [Jani] Signed-off-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-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/20220620065138.5126-1-animesh.manna@intel.com
|
#
6e939738 |
|
31-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Accept more fixed modes with VRR panels It seem that when dealing with VRR capable eDP panels we need to accept fixed modes with variable vblank length (which is what VRR varies dynamically). Typically the preferred mode seems to be a non-VRR more (lowish dotclock/refresh rate + short vblank). We also have examples where it looks like even the hblank length is a bit different between the preferred mode vs. VRR mode(s). So let's just accept anything that has matching hdisp+vdisp+flags. v2: Document that is_alt_drrs_mode() is a subset of is_alt_vrr_mode() (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/125 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/20220531191844.11313-4-ville.syrjala@linux.intel.com
|
#
c518a775 |
|
10-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/bios: Determine panel type via PNPID match Apparently when the VBT panel_type==0xff we should trawl through the PNPID table and check for a match against the EDID. If a match is found the index gives us the panel_type. Tried to match the Windows behaviour here with first looking for an exact match, and if one isn't found we fall back to looking for a match w/o the mfg year/week. v2: Rebase due to vlv_dsi changes v3: Adjust to .get_panel_type() vfunc Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5545 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/20220510104242.6099-14-ville.syrjala@linux.intel.com
|
#
3cf05076 |
|
10-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/bios: Split VBT data into per-panel vs. global parts Move the panel specific VBT parsing to happen during the output probing stage. Needs to be done because the VBT parsing will need to look at the EDID to determine the correct panel_type on some machines. We split the parsed VBT data (i915->vbt) along the same boundary. For the moment we just hoist all the panel specific stuff into connector->panel.vbt since that seems like the most convenient place for eg. the backlight code. Note that we simply drop the drrs type check from intel_drrs_frontbuffer_update() since that operates on the whole device rather than a specific connector/encoder. But the check was just a micro optimization so removing it doesn't actually mattter for correctness. TODO: Lot's of cleanup to be done in the future. Eg. most of the DSI stuff could probably be eliminated entirely and just parsed on demand during DSI init. v2: Note the intel_drrs_frontbuffer_update() change Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
4fc8cb47 |
|
21-Apr-2022 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/display: Move HDMI helpers into display-helper module Move DRM's HMDI helpers into the display/ subdirectoy and add it to DRM's display helpers. Update all affected drivers. No functional changes. The HDMI helpers were implemented in the EDID and connector code, but are actually unrelated. With the move to the display-helper library, we can remove the dependency on drm_edid.{c,h} in some driver's HDMI source files. Several of the HDMI helpers remain in EDID code because both share parts of their implementation internally. With better refractoring of the EDID code, those HDMI helpers could be moved into the display-helper library as well. v3: * fix Kconfig dependencies (Javier) v2: * reduce HDMI helpers to avoid exporting functions (Jani) * fix include statements (Jani, Javier) * update Kconfig symbols Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-8-tzimmermann@suse.de
|
#
3a3c4ce9 |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Combine the EDID fixed_mode+downclock_mode lookup into one The intel_panel_add_edid_fixed_mode() vs. intel_panel_add_edid_downclock_mode() split is not really helpful. Let's just roll those into a single function so that the connector init code doesn't have to care too much about this. All we need to know is whether DRRS should be allowed or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331112822.11462-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
db10c14a |
|
31-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Put fixed modes directly onto the panel's fixed_modes list 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>
|
#
50203b94 |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Change SDVO fixed mode handling 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>
|
#
7a36980c |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use intel_panel_edid_fixed_mode() for sdvo 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>
|
#
14daee24 |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_panel_vbt_sdvo_fixed_mode() We have a function for duplicating the VBT LFP mode. Add the same for the VBT SDVO mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
5d2fd49d |
|
23-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass intel_connector to intel_panel_{init,fini}() All the other intel_panel functions take struct intel_connector, so might as well make init()/fini() take one as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220323182935.4701-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
008bd15c |
|
17-Mar-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/sdvo: prefer __packed over __attribute__((packed)) The kernel preference is to use the __packed macro instead of the direct __attribute__. 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/20220317173355.336835-1-jani.nikula@intel.com
|
#
345b7c4b |
|
14-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Convert fixed_mode/downclock_mode into a list Store the fixed_mode and downclock_mode as a real list, in preparation for exposing other supported modes as well. v2: Init the list in intel_sdvo_connector_alloc() too v3: Use list_first_entry_or_null() (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/20220314152737.9125-1-ville.syrjala@linux.intel.com
|
#
43af6743 |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_preferred_fixed_mode() There are a couple of cases where we essentially just want to get/check the preferred fixed mode of the panel. Add a small helper for that to abstract away the direct pointer lookup. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
09270678 |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_{fixed,downclock}_mode() Abstract away the details on where we store the fixed/downclock modes, and also how we select them. Will be useful for static DRRS (aka. allowing the user to select the refresh rate for the panel). We pass in the user requested mode to intel_panel_fixed_mode() so that in the future it may try to match the refresh rate. And intel_panel_downclock_mode() gets passed the adjusted_mode we actually chose to use so that it may find a suitable lower resresh rate variant. v2: Hook it up for all encoders s/fixed_mode/adjusted_mode/ in intel_panel_downclock_mode() (Jani) Elaborate on the choice or arguments for the functions (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
54b6af69 |
|
11-Mar-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Pass the requesed mode to intel_sdvo_create_preferred_input_timing() We want to stop using connector->panel.fixed_mode directtly. In order to look it up in the future we'll need to have the requested mode around, so pass that in fully (instead of just passing bits of it). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311172428.14685-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
7b06894b |
|
01-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: add intel_crtc_wait_for_next_vblank() and use it intel_wait_for_vblank() goes through a pipe to crtc lookup, while in most cases we already have the crtc available. Avoid the extra lookups by adding an intel_crtc based helper. v2: - Add intel_crtc_wait_for_next_vblank() helper (Ville) 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/90cfbd8c3e79a742b0ee9e3ae75493acb0785dbb.1638366969.git.jani.nikula@intel.com
|
#
cff4c2c6 |
|
27-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce intel_panel_compute_config() Let's introduce a compute_config() helper for fixed mode panels. For now all it does is the fixed_mode->adjusted_mode copy. Note that with sDVO we have to ask the external encoder chip to spit out our actual display timings for us, so the fixed_mode to adjusted_mode copy done by intel_panel_compute_config() is redundant, but we still want to use it to do other checks for us later. We'll be fine so long as we only call it before intel_sdvo_get_preferred_input_mode() overwrites adjusted_mode with the timings from the encoder. v2: Use intel_panel_compute_config() with sDVO Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210927185207.13620-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
8a567b11 |
|
23-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use intel_panel_mode_valid() for DSI/LVDS/(s)DVO All fixed mode panels should behave the same way when it comes to mode filtering. Reuse the intel_panel_mode_valid() for all of them. This changes the behaviour to match what we do for eDP, ie. reject anything that doesn't exactly match the fixed mode dimensions. Users can still manually provide different sized modes which will be handled by the panel fitter just as before. The difference is that we can no longer report funny modes in the connector's mode list. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210923200109.4459-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
f15f01a7 |
|
09-Jun-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/intel_crtc/crtc/ Clear out the straggler 'intel_crtc' variables. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609085632.22026-7-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
#
7785ae0b |
|
30-Apr-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Don't include intel_de.h from intel_display_types.h 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
|
#
7c53e628 |
|
27-Apr-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: move crtc and dpll declarations where they belong The definitions are in the crtc and dpll files; move the declarations to the corresponding headers. 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/20210427120315.12342-1-jani.nikula@intel.com
|
#
005e9537 |
|
19-Mar-2021 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915/display: Eliminate most usage of INTEL_GEN() Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN() in the display code to use DISPLAY_VER() comparisons instead. The following semantic patch was used: @@ expression dev_priv, E; @@ - INTEL_GEN(dev_priv) == E + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; @@ - INTEL_GEN(dev_priv) + DISPLAY_VER(dev_priv) @@ expression dev_priv; expression E; @@ - IS_GEN(dev_priv, E) + IS_DISPLAY_VER(dev_priv, E) @@ expression dev_priv; expression from, until; @@ - IS_GEN_RANGE(dev_priv, from, until) + IS_DISPLAY_RANGE(dev_priv, from, until) There are still some display-related uses of INTEL_GEN() in intel_pm.c (watermark code) and i915_irq.c. Those will be updated separately. v2: - Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
|
#
8ff5446a |
|
28-Jan-2021 |
Thomas Zimmermann <tzimmermann@suse.de> |
drm/i915: Remove references to struct drm_device.pdev Using struct drm_device.pdev is deprecated. Convert i915 to struct drm_device.dev. No functional changes. v6: * also remove assignment in selftests/ in a later patch (Chris) v5: * remove assignment in later patch (Chris) v3: * rebased v2: * move gt/ and gvt/ changes into separate patches Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210128133127.2311-2-tzimmermann@suse.de
|
#
b81dddb9 |
|
10-Sep-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Reduce INTEL_DISPLAY_ENABLED to just treat outputs as disconnected Since the display hardware is all there even when INTEL_DISPLAY_ENABLED return false we have to be capable of shutting it down cleanly so as to not anger the hw. To that end let's reduce the effect of !INTEL_DISPLAY_ENABLE to just treating all outputs as disconnected. Should prevent anyone from automagically enabling any of them, while still allowing us to cleanly shut them down. v2: Put the check into the right place for CRT Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200910164256.25983-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
df561f66 |
|
23-Aug-2020 |
Gustavo A. R. Silva <gustavoars@kernel.org> |
treewide: Use fallthrough pseudo-keyword Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
|
#
7407ec6e |
|
08-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Make .get_modes() return the number of modes .get_modes() is supposed to return the number of modes added to the probed_modes list (not that anyone actually checks for anything except zero vs. not zero). Let's do that. Also switch over to using intel_connector_update_modes() instead of hand rolling it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-8-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
d9757193 |
|
08-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Make SDVO deal with HDMI pixel repeat With SDVO the pipe config pixel_multiplier only concerns itself with the data on the SDVO bus. Any HDMI specific pixel repeat must be handled by the SDVO device itself. To do that simply configure the SDVO pixel replication factor appropriately. We already set up the infoframe PRB values correctly via the infoframe helpers. There is no cap we can check for this. The spec says that 1X,2X,4X are mandatory, anything else is optional. 1X and 2X are all we need so we should be able to assume they work. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-7-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
90f8ed85 |
|
08-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Implement limited color range for SDVO HDMI properly The SDVO/HDMI port register limited color range bit can only be used with TMDS encoding and not SDVO encoding, ie. to be used only when using the port as a HDMI port as opposed to a SDVO port. The SDVO spec does have a note that some GMCHs might allow that, but gen4 bspec vehemently disagrees. I suppose on ILK+ it might work since the color range handling is on the CPU side rather than on the PCH side, so there is no clear linkage between the TMDS vs. SDVO encoding and color range. Alas, I have no hardware to test that theory. To implement limited color range support for SDVO->HDMI we need to ask the SDVO device to do the range compression. Do so, but first check if the device even supports the colorimetry selection. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-5-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
cb7cbb4b |
|
04-May-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915/display/sdvo: Prefer drm_WARN* over WARN* struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN* over WARN* calls. changes since v1: - Added dev_priv local variable and used it in drm_WARN* calls (Jani) Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-4-pankaj.laxminarayan.bharadiya@intel.com
|
#
8c8919c7 |
|
29-Mar-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add a retry counter for hotplug detect retries On TypeC connectors we need to retry the detection after hotplug events for a longer time, so add a retry counter to support this. The next patch will add detection retries on TypeC ports needing this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200330095425.29113-1-imre.deak@intel.com
|
#
ede9771d |
|
13-Mar-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass atomic state to encoder hooks We're going to want access to the atomic state for iterating the slave crtcs when enabling the port sync master crtc. Pass the atomic state all the way down. The alternative would be yet another encoder hook which we'll have to call after all the normal modeset stuff is done. Not really a fan of yet another hook just for this. Note that during readout state sanitation we are now going to pass NULL as the atomic state since we don't have one. We need to change that and then we can also s/crtc_state/crtc/ and s/conn_state/conn/ for the encoder hooks as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200313164831.5980-13-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
#
83d2bdb6 |
|
25-Feb-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: significantly reduce the use of <drm/i915_drm.h> The #include has been splattered all over the place, but there are precious few places, all .c files, that actually need it. v2: remove leftover double newlines Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225133131.3301-1-jani.nikula@intel.com
|
#
5fb908eb |
|
05-Feb-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Mark all HPD capabled connectors as such Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT} bits in intel_connector->polled (the base setting), leading to some confusing looking code to reset drm_connector->polled (the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd capable connectors, and then we don't need so many special cases in the hotplug code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
c808c4ae |
|
30-Jan-2020 |
Wambui Karuga <wambui.karugax@gmail.com> |
drm/i915/sdvo: automatic conversion to drm_device based logging macros. Converts instances of the printk based drm logging macros to the new struct drm_device based logging macros in i915/display/intel_sdvo.c This was done automatically using the following coccinelle script that matches based on the existence of a drm_i915_private device pointer: @@ identifier fn, T; @@ fn(...) { ... struct drm_i915_private *T = ...; <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } @@ identifier fn, T; @@ fn(...,struct drm_i915_private *T,...) { <+... ( -DRM_INFO( +drm_info(&T->drm, ...) | -DRM_ERROR( +drm_err(&T->drm, ...) | -DRM_WARN( +drm_warn(&T->drm, ...) | -DRM_DEBUG( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_DRIVER( +drm_dbg(&T->drm, ...) | -DRM_DEBUG_KMS( +drm_dbg_kms(&T->drm, ...) | -DRM_DEBUG_ATOMIC( +drm_dbg_atomic(&T->drm, ...) ) ...+> } Checkpatch warnings were fixed manually. Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200130083229.12889-9-wambui.karugax@gmail.com
|
#
b4329a01 |
|
28-Jan-2020 |
Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> |
drm/i915/display/sdvo: Make WARN* drm specific where drm_priv ptr is available drm specific WARN* calls include device information in the backtrace, so we know what device the warnings originate from. Covert all the calls of WARN* with device specific drm_WARN* variants in functions where drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. @rule1@ identifier func, T; @@ func(...) { ... struct drm_i915_private *T = ...; <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } @rule2@ identifier func, T; @@ func(struct drm_i915_private *T,...) { <+... ( -WARN( +drm_WARN(&T->drm, ...) | -WARN_ON( +drm_WARN_ON(&T->drm, ...) | -WARN_ONCE( +drm_WARN_ONCE(&T->drm, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(&T->drm, ...) ) ...+> } Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128181603.27767-18-pankaj.laxminarayan.bharadiya@intel.com
|
#
d2afcc44 |
|
24-Jan-2020 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/sdvo: use intel_de_*() functions for register access The implicit "dev_priv" local variable use has been a long-standing pain point in the register access macros I915_READ(), I915_WRITE(), POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW(). Replace them with the corresponding new display engine register accessors intel_de_read(), intel_de_write(), intel_de_posting_read(), intel_de_read_fw(), and intel_de_write_fw(). No functional changes. Generated using the following semantic patch: @@ expression REG, OFFSET; @@ - I915_READ(REG) + intel_de_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - POSTING_READ(REG) + intel_de_posting_read(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE(REG, OFFSET) + intel_de_write(dev_priv, REG, OFFSET) @@ expression REG; @@ - I915_READ_FW(REG) + intel_de_read_fw(dev_priv, REG) @@ expression REG, OFFSET; @@ - I915_WRITE_FW(REG, OFFSET) + intel_de_write_fw(dev_priv, REG, OFFSET) Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b21dbc3c0f349345619590893c8ab96828c39103.1579871655.git.jani.nikula@intel.com
|
#
814df0ce |
|
08-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Consolidate SDVO HDMI force_dvi handling Move the force_dvi check to a single function that can be called from both mode validation and compute_config(). Note that currently we don't call it from mode validation, but that will change soon. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
cb70b713 |
|
08-Jan-2020 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Reduce the size of the on stack buffers The strings we want to print to the on stack buffers should be no more than 8 * 3 + strlen("(GET_SCALED_HDTV_RESOLUTION_SUPPORT)") + 1 = 61 bytes. So let's shrink the buffers down to 64 bytes. Also switch the BUG_ON()s to WARN_ON()s if I made a mistake in my arithmentic. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200108181242.13650-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
43a6d19c |
|
04-Dec-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Pass intel_connector to intel_attached_*() Life is usually easier when we pass around intel_ types instead of drm_ types. In this case it might not be, but I think being consistent is a good thing anyway. Also some of this might get cleaned up a bit more later as we keep propagating the intel_ types further. @find@ identifier F =~ "^intel_attached_.*"; identifier C; @@ F(struct drm_connector *C) { ... } @@ identifier find.F; identifier find.C; @@ F( - struct drm_connector *C + struct intel_connector *connector ) { <... - C + &connector->base ...> } @@ identifier find.F; expression C; @@ - F(C) + F(to_intel_connector(C)) @@ expression C; @@ - to_intel_connector(&C->base) + C Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-3-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
#
e5436206 |
|
20-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Drop redundant aspec ratio prop value initialization HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d so no need to initialize conn_state->picture_aspect_ratio with it. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-6-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
c504f4df |
|
20-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Do not override mode's aspect ratio with the prop value NONE HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that selected we should keep whatever aspect ratio the mode already has. Also no point in checking for connector->is_hdmi in the SDVO code since we only attach the property to HDMI connectors. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-5-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
|
#
2225f3c6 |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Perform automated conversions for crtc uapi/hw split, base -> uapi. Split up crtc_state->base to uapi. This is done using the following patch, ran after the previous commit that splits out any hw references: @@ struct intel_crtc_state *T; @@ -T->base +T->uapi Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-5-maarten.lankhorst@linux.intel.com
|
#
1326a92c |
|
30-Oct-2019 |
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> |
drm/i915: Perform automated conversions for crtc uapi/hw split, base -> hw. Split up crtc_state->base to hw where appropriate. This is done using the following patch: @@ struct intel_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -T->base.x +T->hw.x @@ struct drm_crtc_state *T; identifier x =~ "^(active|enable|degamma_lut|gamma_lut|ctm|mode|adjusted_mode)$"; @@ -to_intel_crtc_state(T)->base.x +to_intel_crtc_state(T)->hw.x Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-4-maarten.lankhorst@linux.intel.com
|
#
34053ee1 |
|
02-Oct-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify pipe_mask setup even further Just set pipe_mask=~0 for the non-special cases where any pipe will do. intel_encoder_possible_crtcs() will anyway drop out anything that doesn't exist. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-5-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
|
#
981329ce |
|
02-Oct-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/crtc_mask/pipe_mask/ Rename the encoder->crtc_mask to encoder->pipe_mask to better reflect what it actually contains. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191002162505.30716-3-ville.syrjala@linux.intel.com Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
|
#
0fbae9d2 |
|
08-Jul-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Clean up encoder->crtc_mask setup Use BIT(pipe) for better legibility when populating the crtc_mask for encoders. Also remove the redundant possible_crtcs setup for the TV encoder. 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/20190708162048.4286-11-ville.syrjala@linux.intel.com
|
#
1d455f8d |
|
06-Aug-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: rename intel_drv.h to display/intel_display_types.h Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the include guard name in the renamed file Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com
|
#
3944709d |
|
11-Jul-2019 |
Imre Deak <imre.deak@intel.com> |
drm/i915: Add support for retrying hotplug There is some scenarios that we are aware that sink probe can fail, so lets add the infrastructure to let hotplug() hook to request another probe after some time. v2: Handle shared HPD pins (Imre) v3: Rebased v4: Renamed INTEL_HOTPLUG_NOCHANGE to INTEL_HOTPLUG_UNCHANGED to keep it consistent(Rodrigo) v5: Making the working queue used explicit through all the callers to hotplug_work (Ville) Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712005343.24571-1-jose.souza@intel.com
|
#
5a5efbf4 |
|
19-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Fix handling if zero hbuf size The spec says: "A value of 0 indicates that this buffer does not exist" So we should not convert a hbuf_size of 0 into 1. Also pull the relevant code into a helper to avoid making the same mistake multiple times. And while at it fix the debug prints to not say "hbuf_len" twice. v2: s/%i/%u/ in the debug (Imre) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619180312.31817-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
|
#
a46f4e9e |
|
19-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Add helpers to get the cmd/status string Add sdvo_cmd_name() and sdvo_cmd_status() helpers to avoid bothering the callers with the implementation details of the storage for these strings. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619180312.31817-6-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
7b8062ea |
|
19-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Shrink sdvo_cmd_names[] strings Drop the redundant "SDVO_CMD_" prefix from the command name strings in sdvo_cmd_names[]. While at it throw away the unused struct name, and undef SDVO_CMD_NAME_ENTRY() when we're done. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619180312.31817-4-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
8a9c8028 |
|
19-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Remove duplicate SET_INPUT_TIMINGS_PART1 cmd name string sdvo_cmd_names[] contains two entries for SET_INPUT_TIMINGS_PART1. Remove one of them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619180312.31817-3-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
c598a664 |
|
19-Jun-2019 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/sdvo: Use named initializers for the SDVO command names Use named initializers to make it easier to associate the SDVO debug prints with the SDVO command defines. Also switch to using ARRAY_SIZE() instead of assuming that SDVO_CMD_STATUS_SCALING_NOT_SUPP is the last command type. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190619180312.31817-2-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
#
379bc100 |
|
13-Jun-2019 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: move modesetting output/encoder code under display/ Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-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/20190613084416.6794-2-jani.nikula@intel.com
|