- 20 Sep, 2023 13 commits
-
-
Ville Syrjälä authored
Implement low refresh rate (LRR) where we change the vblank length by hand as requested, but otherwise keep the timing generator running in non-VRR mode (ie. fixed refresh rate). The panel itself must support VRR for this to work, and only TGL+ has the double buffred TRANS_VTOTAL.VTOTAL that we need to make the switch properly. The double buffer latching happens at the start of transcoders undelayed vblank. The other thing that we change is TRANS_VBLANK.VBLANK_END but the hardware entirely ignores that in DP mode. But I decided to keep writing it anyway just to avoid more special cases in readout/state check. v2: Document that TRANS_VBLANK.VBLANK_END is ignored by the hardware v3: Reconcile with VRR fastset Adjust update_lrr flag behaviour Make sure timings stay within VRR range v4: Fix up update_m_n vs. update_lrr rebase fail (Manasi) Drop DOUBLE_BUFFER_VACTIVE define as it's not needed (Manasi) TODO: Hook LRR into the automatic DRRS downclocking stuff? Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230915103800.14218-1-ville.syrjala@linux.intel.comReviewed-by:
Manasi Navare <navaremanasi@chromium.org>
-
Ville Syrjälä authored
Whenever we change the actual transcoder timings (clock via seamless M/N, full modeset, (or soon) vtotal via LRR) we want the timing generator to be in non-VRR during the commit. Warn if we forgot to turn VRR off prior to vblank evasion. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
-
Ville Syrjälä authored
We should be able to change any of the VRR parameters during fastsets as long as we toggle VRR off at the start and then back on at the end. The transcoder will be running in non-VRR mode during the transition. Co-developed-by:
Sean Paul <seanpaul@chromium.org>
-
Ville Syrjälä authored
Make life less confusing by making sure VRR is disabled whenever we do any drastic changes to the display timings, such as seamless M/N changes. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Let's assume there are some crazy displays where the high end of the VRR range ends up being lower than the refresh rate as determined by the actual timings. In that case when we toggle VRR on/off we would step outside the VRR range when toggling VRR on/off. Let's just make sure that never happens by not using VRR in such cases. If the user really wants VRR they should then select the timings to land within the VRR range. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Move is_in_vrr_range() into intel_vrr.c in anticipation of more users, and rename it accordingly. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Don't perform a seamless M/N update if the values aren't actually changing. This avoids doing extra shenanigans during vblank evasion needlessly. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the flag will only be set if we need to do the seamless M/N update, and in all other cases the flag is cleared. Also rename the flag to update_m_n to make it more clear it's similar to update_pipe. I believe special casing seamless_m_n like this makes sense as it also affects eg. vblank evasion. We can potentially avoid some vblank evasion tricks, simplify some checks, and hopefully will help with the VRR vs. M/N mess. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
In order to reconcile seamless M/N updates with VRR we'll need to defer the fastset VRR enable to happen after the seamless M/N update (which happens during the vblank evade critical section). So just push the VRR enable to be the last thing during the update. This will also affect the vblank evasion as the transcoder will now still be running with the old VRR state during the vblank evasion. So just grab the timings always from the old crtc state during any non-modeset commit, and also grab the current state of VRR from the active timings (as we disable VRR before vblank evasion during fastsets). This also fixes vblank evasion for seamless M/N updates as we now properly account for the fact that the M/N update happens after vblank evasion. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Pull the vblank evasion scanline calculations into their own helper to declutter intel_pipe_update_start() a bit. Reviewed-by:
-
Ville Syrjälä authored
We'll need to also look at the old crtc state in intel_pipe_update_start() so change the calling convention to just plumb in the full atomic state instead. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
Do the PSR unlock after the vblank evade critcal section is fully over, not before. Cc: Manasi Navare <navaremanasi@chromium.org> Signed-off-by:
-
William Tseng authored
This change is to adjust TCLK-POST timing so DSI signaling can meet CTS specification. For clock lane, the TCLK-POST timing may be changed from 133.44 ns to 178.72 ns, which is greater than (60 ns+52*UI) and is conformed to the CTS standard. The computed UI is around 1.47 ns. v2: remove the change of HS-TRAIL. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
William Tseng <william.tseng@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230914095137.4132029-1-william.tseng@intel.com
-
- 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:
-
- 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ä 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 4 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:
-
