- 18 Sep, 2023 3 commits
-
-
Gustavo Sousa authored
There was a recent update in the BSpec adding an extra step to the PLL enable sequence, which is for programming the msgbus timer. Since we also touch PHY registers during hw readout, let's do the programming when starting a transaction rather than only when doing the PLL enable sequence. This might be the missing step that was causing the timeouts that we have recently seen during C20 SRAM register programming sequences. With this in place, we shouldn't need the logic to bump the timer thresholds, since now we have a documented value that should be set peform programming the registers. As such, let's also remove intel_cx0_bus_check_and_bump_timer(), but keep the part that checks if hardware really detected a timeout, which might be useful debugging information. v2: - Use debug level instead of warning for the message notifying that the hardware did not detect the timeout. (Mika) - Got a new BSpec update clarifying that we need to program the msgbus timer of both PHY lanes. Update the changes to reflect that. (Gustavo) BSpec: 64568 Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230912155923.39494-1-gustavo.sousa@intel.com
-
Imre Deak authored
If a sink is removed in the middle of payload addition drm_dp_add_payload_part1() will fail as expected, either not finding the payload's MST port or failing the payload-add AUX transaction. Based on the above tune the error message down to a debug messge. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230913223218.540365-4-imre.deak@intel.com
-
Jouni Högander authored
It's not necessary to carry separate suspended status information in intel_runtime_pm struct as this information is already in underlying device structure. Remove it and use pm_runtime_suspended() to obtain suspended status information when needed. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 15 Sep, 2023 19 commits
-
-
Jani Nikula authored
Don't hide display probe in device info code. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230912120537.2158209-3-jani.nikula@intel.com
-
Jani Nikula authored
Move gmdid selection one abstraction level higher. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jani Nikula authored
Initializing i915->display.info.__device_info and DISPLAY_RUNTIME_INFO() really belongs in display code. Move them there. Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid using GEM_BUG_ON() in display code. Signed-off-by:
-
Jani Nikula authored
Avoid using GEM_WARN_ON() in display code. Signed-off-by:
-
Jani Nikula authored
Avoid using GEM_BUG_ON() in display code. Signed-off-by:
-
Ville Syrjälä authored
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.comReviewed-by:
-
Ville Syrjälä authored
Remove the i915 specific i2c-N symlink from HDMI connectors. This was added to sort of mirror the DP connectors that alreayd had their aux ch based i2c adapter sitting beneath them in the sysfs hierarchy. But now that we have the standard "ddc" symlink approach provided by the core let's switch to that fully. I don't think anything beyond igt depends on this. Signed-off-by:
-
Ville Syrjälä authored
Remove the mostly redundant hdmi->ddc_bus. The only thing that needs it anymore is get_encoder_by_ddc_bus(), but that can be replaced with a slight detour through attached_connector+intel_gmbus_get_adapter(). Signed-off-by:
-
Ville Syrjälä authored
We already populate connector->ddc for HDMI ports, but so far we've not taken full advantage of it. Do that by eliminating a bunch of intel_gmbus_get_adapter() lookups. Signed-off-by:
-
Ville Syrjälä authored
Populate connector->ddc, and thus create the "ddc" symlink in sysfs for DP MST connectors. TODO: test that this actually works References: https://gitlab.freedesktop.org/drm/intel/-/issues/3605Signed-off-by:
-
Ville Syrjälä authored
Populate connector->ddc, and thus create the "ddc" symlink in sysfs for analog DP SST connectors. Let's also reorder intel_dp_aux_init() vs. drm_connector_init_with_ddc() a bit to make sure the i2c aux ch is at least somewhat populated before we pass it on, though drm_connector_init_with_ddc() does not actually do anything with it. Signed-off-by:
-
Ville Syrjälä authored
Populate connector->ddc, and thus create the "ddc" symlink in sysfs for DVO connectors. Signed-off-by:
-
Ville Syrjälä authored
Populate connector->ddc, and thus create the "ddc" symlink in sysfs for analog VGA connectors. As a bonus we can replace a bunch of intel_gmbus_get_adapter() lookups with just the connector->ddc pointer. Sadly one extra lookup still remains due to the g4x DVI-I shenanigans. We could perhaps consider borrowing the ddc proxy idea from SDVO to deal with that in a perhaps nicer way, but can't really be bothered right now at least. Also not sure exposing such a dual ddc bus to userspace would be quite wise. Signed-off-by:
-
Ville Syrjälä authored
Populate connector->ddc, and thus create the "ddc" symlink in sysfs for the LVDS port. Signed-off-by:
-
Ville Syrjälä authored
Rename the various names we've used for the DDC bus i2c adapter ("i2c", "adapter", etc.) to just "ddc". This differentiates it from the various other i2c busses we might have (DSI panel stuff, DVO control bus, etc.). v2: Don't add a bogus drm_get_edid() call (Jani) Reviewed-by: -
Ville Syrjälä authored
Currently drm_sysfs_connector_add() attempts to register the "ddc" symlink (based one connector->ddc) before the driver's .early_register() hook has been called. That is too early for i915 which only fully registers the aux ch and associated i2c bus from said hook (to prevent half initialized stuff getting exposed to userspace). This causes my attempt at using drm_connector_init_with_ddc() to fail, and the entire connector disappears from sysfs on account of sysfs_create_link() failing. To fix that split the sysfs symlink stuff into separate functions (drm_sysfs_connector_add_late() and drm_sysfs_connector_remove_early()) which are called on the opposite side of the .later_register() and .early_unregister() hooks. Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by:
-
Ville Syrjälä authored
Use the standard onion peeling approach and call drm_debugfs_connector_remove() and drm_sysfs_connector_remove() in the reverse order in drm_connector_unregister() than what we called their add counterpartse in drm_connector_register(). The error unwiding in drm_connector_register() is already doing this the correct way around. Signed-off-by:
-
Jani Nikula authored
Sync to v6.6-rc1. Signed-off-by:
-
- 14 Sep, 2023 1 commit
-
-
Suraj Kandpal authored
pic_width when written into the PPS register is divided by the no. of vdsc instances first but the actual variable that we compare it to does not change i.e vdsc_cfg->pic_width hence when reading the register back for pic_width it needs to be multiplied by num_vdsc_instances rather than being divided. Fixes: 8b70b569 ("drm/i915/vdsc: Fill the intel_dsc_get_pps_config function") Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230911193742.836063-1-suraj.kandpal@intel.com
-
- 13 Sep, 2023 7 commits
-
-
Ville Syrjälä authored
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:
Luca Coelho <luciano.coelho@intel.com>
-
Ville Syrjälä authored
We always check whether combo PHYs need to be re-initialized after disabling DC states, which leads to log spam. Switch things around so that we only log something when we actually have to re-initialized a PHY. The log spam was exacerbated by commit 41b4c7fe ("drm/i915: Disable DC states for all commits") since we now disable DC states far more often. Signed-off-by:
-
Ville Syrjälä authored
encoder->get_config() is not the place where the state should be dumped. Get rid of the spam. Signed-off-by:
-
Ville Syrjälä authored
Split some overly long lines in hsw_fdi_link_train(). Signed-off-by:
-
Ville Syrjälä authored
Stop dumping state while reading it out. We have a proper place for that stuff. Signed-off-by:
-
Ville Syrjälä authored
On pre-TGL FEC is a port level feature, not a transcoder level feature, and it's DDI A which doesn't have it, not trancoder A. Check for the correct thing when determining whether FEC is supported or not. Signed-off-by:
-
Ville Syrjälä authored
The MST codepath is missing FEC readout. Add it. Signed-off-by:
-
- 12 Sep, 2023 1 commit
-
-
Jani Nikula authored
intel_gtt.h is indirectly included absolutely everywhere in the driver. DBG() is too short a name. Rename it GTT_TRACE() after GEM_TRACE(). Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230911123305.1682554-1-jani.nikula@intel.com
-
- 11 Sep, 2023 9 commits
-
-
Jani Nikula authored
Use the register helper macros for PPS0 and PPS1 register contents. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Improve clarity by specifying the PPS number in the register content macros. It's easier to notice if macros are being used for the wrong register. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Unify comments to be the simple "PPS n" instead of all sorts of variants. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Directly assign the values instead of first assigning 0 and then |= the values. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Make the function name conform to existing style better. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Register read functions usually return the value instead of passing via pointer parameters. Return the multiple register verification results via a pointer parameter, which can also be NULL to skip the extra checks. Make the name conform to existing style better while at it. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Register read functions usually return the value instead of passing via pointer parameters. The calling code becomes easier to read. Make the name conform to existing style better while at it. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Jani Nikula authored
Make it clear what's the number of vdsc per pipe, and what's the number of registers to grab. Have intel_dsc_get_pps_reg() return the registers it knows even if the requested amount is bigger. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Apparently Acer Chromebook C740 (BDW-ULT) doesn't have the eDP HPD line properly connected, and thus fails the new HPD check during eDP probe. The result is that we lose the eDP output. I suspect all such machines would be Chromebooks or other Linux exclusive systems as the Windows driver likely wouldn't work either. I did check a few other BDW machines here and those do have eDP HPD connected, one of them even is a different Chromebook (Samus). To account for these funky machines let's skip the HPD check when it looks like the eDP port is the only one using that specific AUX channel. In case of multiple ports sharing the same AUX CH (eg. on Asrock B250M-HDV) we still do the check and thus should correctly ignore the eDP port in favor of the other DP port (usually a DP->VGA converter). v2: Don't oops during list iteration Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9264 Fixes: cfe5bdfb ("drm/i915: Check HPD live state during eDP probe") Signed-off-by:
-
