Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31 |
|
#
7ffa2f27 |
| 30-May-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: stop caching has_hdmi_sink in struct intel_dp
Use the information stored in display info. Add intel_dp_has_hdmi_sink() helper to access it.
v2: Rebased
Reviewed-by: Ankit Nautiyal <an
drm/i915/dp: stop caching has_hdmi_sink in struct intel_dp
Use the information stored in display info. Add intel_dp_has_hdmi_sink() helper to access it.
v2: Rebased
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/748103fda572b3552e5bbdafb300d8508d4eeaf4.1685437500.git.jani.nikula@intel.com
show more ...
|
Revision tags: v6.1.30, v6.1.29 |
|
#
c598c335 |
| 12-May-2023 |
Imre Deak <imre.deak@intel.com> |
drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects
If the output on a DP-alt link with its sink disconnected is kept enabled for too long (about 20 sec), then some
drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects
If the output on a DP-alt link with its sink disconnected is kept enabled for too long (about 20 sec), then some IOM/TCSS firmware timeout will cause havoc on the PCI bus, at least for other GFX devices on it which will stop powering up. Since user space is not guaranteed to do a disabling modeset in time, switch such disconnected but active links to TBT mode - which is without such shortcomings - with a 2 second delay.
If the above condition is detected already during the driver load/system resume sanitization step disable the output instead, as at that point no user space or kernel client depends on a consistent output state yet and because subsequent atomic modeset on such connectors - without the actual sink capabilities available - can fail.
An active/disconnected port as above will also block the HPD status of other active/disconnected ports to get updated (stuck in the connected state), until the former port is disabled, its PHY is disconnected and a ~10 ms delay has elapsed. This means the link state for all TypeC ports/CRTCs must be rechecked after a CRTC is disabled due to the above reason. For this disconnect the PHY synchronously after the CRTC/port is disabled and recheck all CRTCs for the above condition whenever such a port is disabled.
To account for a race condition during driver loading where the sink is disconnected after the above sanitization step and before the HPD interrupts get enabled, do an explicit check/link reset if needed from the encoder's late_register hook, which is called after the HPD interrupts are enabled already.
v2: - Handle an active/disconnected port blocking the HPD state update of another active/disconnected port. - Cancel the delayed work resetting the link also from the encoder enable/suspend/shutdown hooks. - Rebase on the earlier intel_modeset_lock_ctx_retry() addition, fixing here the missed atomic state reset in case of a retry. - Fix handling of an error return from intel_atomic_get_crtc_state(). - Recheck if the port needs to be reset after all the atomic state is locked and async commits are waited on.
v3: - Add intel_crtc_needs_link_reset(), instead of open-coding it, keep intel_crtc_has_encoders(). (Ville) - Fix state dumping and use a bitmask to track disabled CRTCs in intel_sanitize_all_crtcs(). (Ville) - Set internal in intel_atomic_state right after allocating it. (Ville) - Recheck all CRTCs (not yet force-disabled) after a CRTC is force-disabled for any reason (not only due to a link state) in intel_sanitize_all_crtcs(). - Reduce delay after CRTC disabling to 20ms, and use the simpler msleep(). - Clarify code comment about HPD behaviour in intel_sanitize_all_crtcs(). - Move all the TC link reset logic to intel_tc.c . - Cancel the link reset work synchronously during system suspend, driver unload and shutdown.
v4: - Rebased on previous patch, which allows calling the TC port suspend/cleanup handlers without modeset locks held; remove the display driver suspended assert from the link reset work accordingly.
v5: (Ville) - Remove reset work canceling from intel_ddi_pre_pll_enable(). - Track a crtc vs. pipe mask in intel_sanitize_all_crtcs(). - Add reset_link_commit() to clarify the intel_modeset_lock_ctx_retry loop.
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5860 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512195513.2699-2-imre.deak@intel.com
show more ...
|
Revision tags: v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80 |
|
#
52f14682 |
| 23-Nov-2022 |
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> |
drm/i915: Bpp/timeslot calculation fixes for DP MST DSC
Fix intel_dp_dsc_compute_config, previously timeslots parameter was used in fact not as a timeslots, but more like a ratio timeslots/64, which
drm/i915: Bpp/timeslot calculation fixes for DP MST DSC
Fix intel_dp_dsc_compute_config, previously timeslots parameter was used in fact not as a timeslots, but more like a ratio timeslots/64, which of course didn't have any effect for SST DSC, but causes now issues for MST DSC. Secondly we need to calculate pipe_bpp using intel_dp_dsc_compute_bpp only for SST DSC case, while for MST case it has been calculated earlier already with intel_dp_dsc_mst_compute_link_config. Third we also were wrongly determining sink min bpp/max bpp, those limites should be intersected with our limits to find common acceptable bpp's, plus on top of that we should align those with VESA bpps and only then calculate required timeslots amount. Some MST hubs started to work only after third change was made.
v2: Make kernel test robot happy(claimed there was unitialzed use, while there is none) v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp (Manasi Navare)
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123100718.29130-1-stanislav.lisovskiy@intel.com
show more ...
|
#
d797f67d |
| 23-Nov-2022 |
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> |
drm/i915: Extract VESA DSC bpp alignment to separate function
We might to use that function separately from intel_dp_dsc_compute_config for DP DSC over MST case, because allocating bandwidth in that
drm/i915: Extract VESA DSC bpp alignment to separate function
We might to use that function separately from intel_dp_dsc_compute_config for DP DSC over MST case, because allocating bandwidth in that case can be a bit more tricky. So in order to avoid code copy-pasta lets extract this to separate function and reuse it for both SST and MST cases.
v2: Removed multiple blank lines v3: Rename intel_dp_dsc_nearest_vesa_bpp to intel_dp_dsc_nearest_valid_bpp to reflect its meaning more properly. (Manasi Navare)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221123100551.29080-1-stanislav.lisovskiy@intel.com
show more ...
|
Revision tags: v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77 |
|
#
d51f25eb |
| 01-Nov-2022 |
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> |
drm/i915: Add DSC support to MST path
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST.
v2: Removed intel_dp_
drm/i915: Add DSC support to MST path
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST.
v2: Removed intel_dp_mst_dsc_compute_config and refactored intel_dp_dsc_compute_config to support timeslots as a parameter(Ville Syrjälä)
v3: - Rebased - Added a debug to see that we at least try reserving VCPI slots using DSC, because currently its not visible from the logs, thus making debugging more tricky. - Moved timeslots to numerator, where it should be.
v4: - Call drm_dp_mst_atomic_check already during link config computation, because we need to know already by this moment if uncompressed amount of VCPI slots needed can fit, otherwise we need to use DSC. (thanks to Vinod Govindapillai for pointing this out)
v5: - Put pipe_config->bigjoiner_pipes back to original condition in intel_dp_dsc_compute_config (don't remember when I lost it)
v6: - Removed unnecessary drm_dp_mst_atomic_check as it is now always called in a newly introduced intel_dp_mst_find_vcpi_slots_for_bpp function (Vinod Govindapillai)
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-5-stanislav.lisovskiy@intel.com
show more ...
|
Revision tags: v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66 |
|
#
cc6b2ba2 |
| 06-Sep-2022 |
Jani Nikula <jani.nikula@intel.com> |
Revert "drm/i915: Add DSC support to MST path"
This reverts commit e1a84ba850128b3984973786829e610ae4ee0e2e.
Part of a series where patches were modified while applying to resolve conflicts, leadin
Revert "drm/i915: Add DSC support to MST path"
This reverts commit e1a84ba850128b3984973786829e610ae4ee0e2e.
Part of a series where patches were modified while applying to resolve conflicts, leading to further conflicts between drm-misc-next and drm-intel-next, resulting in build failures in drm-tip. To be applied again on a baseline with drm-misc-next and drm-intel-next in sync.
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
show more ...
|
#
e1a84ba8 |
| 05-Sep-2022 |
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> |
drm/i915: Add DSC support to MST path
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST.
v2: Removed intel_dp_
drm/i915: Add DSC support to MST path
Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST.
v2: Removed intel_dp_mst_dsc_compute_config and refactored intel_dp_dsc_compute_config to support timeslots as a parameter(Ville Syrjälä)
v3: - Rebased - Added a debug to see that we at least try reserving VCPI slots using DSC, because currently its not visible from the logs, thus making debugging more tricky. - Moved timeslots to numerator, where it should be.
v4: - Call drm_dp_mst_atomic_check already during link config computation, because we need to know already by this moment if uncompressed amount of VCPI slots needed can fit, otherwise we need to use DSC. (thanks to Vinod Govindapillai for pointing this out)
v5: - Put pipe_config->bigjoiner_pipes back to original condition in intel_dp_dsc_compute_config (don't remember when I lost it)
v6: - Removed unnecessary drm_dp_mst_atomic_check as it is now always called in a newly introduced intel_dp_mst_find_vcpi_slots_for_bpp function (Vinod Govindapillai)
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220905085744.29637-5-stanislav.lisovskiy@intel.com
show more ...
|
Revision tags: v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39 |
|
#
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 loo
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>
show more ...
|
#
822e5ae7 |
| 10-May-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Extract intel_edp_fixup_vbt_bpp()
We have the same "override eDP VBT bpp with the current bpp" code duplciated in two places. Extract it to a helper function.
TODO: Having this in .get_co
drm/i915: Extract intel_edp_fixup_vbt_bpp()
We have the same "override eDP VBT bpp with the current bpp" code duplciated in two places. Extract it to a helper function.
TODO: Having this in .get_config() is pretty ugly. Should probably try to move it somewhere else (setup_hw_state()/etc.)...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220510104242.6099-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
show more ...
|
Revision tags: v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18 |
|
#
ce2fce25 |
| 27-Jan-2022 |
Matt Roper <matthew.d.roper@intel.com> |
drm/i915: Only include i915_reg.h from .c files
Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much
drm/i915: Only include i915_reg.h from .c files
Several of our i915 header files, have been including i915_reg.h. This means that any change to i915_reg.h will trigger a full rebuild of pretty much every file of the driver, even those that don't have any kind of register access. Let's delete the i915_reg.h include from all headers and add an explicit include from the .c files that truly need the register definitions; those that need a definition of i915_reg_t for a function definition can get it from i915_reg_defs.h instead.
We also remove two non-register #define's (VLV_DISPLAY_BASE and GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the i915_reg.h include from a couple of headers.
There's probably a lot more header dependency optimization possible, but the changes here roughly cut the number of files compiled after 'touch i915_reg.h' in half --- a good first step.
Cc: Jani Nikula <jani.nikula@intel.com> 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/20220127234334.4016964-7-matthew.d.roper@intel.com
show more ...
|
Revision tags: v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6 |
|
#
a44f42ba |
| 30-Nov-2021 |
Lyude Paul <lyude@redhat.com> |
drm/i915/dp: Perform 30ms delay after source OUI write
While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot
drm/i915/dp: Perform 30ms delay after source OUI write
While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot up without detecting Intel HDR backlight support - even though it's supported on the system. One example of such a laptop is the Lenovo P17 1st generation.
Following some investigation Ville Syrjälä did through the docs they have available to them, they discovered that there's actually supposed to be a 30ms wait after writing the source OUI before we begin setting up the rest of the backlight interface.
This seems to be correct, as adding this 30ms delay seems to have completely fixed the probing issues I was previously seeing. So - let's start performing a 30ms wait after writing the OUI, which we do in a manner similar to how we keep track of PPS delays (e.g. record the timestamp of the OUI write, and then wait for however many ms are left since that timestamp right before we interact with the backlight) in order to avoid waiting any longer then we need to. As well, this also avoids us performing this delay on systems where we don't end up using the HDR backlight interface.
V3: * Move last_oui_write into intel_dp V2: * Move panel delays into intel_pps
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211130212912.212044-1-lyude@redhat.com (cherry picked from commit c7c90b0b8418a97d3aa8b39aae1992908948efad) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
show more ...
|
#
c7c90b0b |
| 30-Nov-2021 |
Lyude Paul <lyude@redhat.com> |
drm/i915/dp: Perform 30ms delay after source OUI write
While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot
drm/i915/dp: Perform 30ms delay after source OUI write
While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot up without detecting Intel HDR backlight support - even though it's supported on the system. One example of such a laptop is the Lenovo P17 1st generation.
Following some investigation Ville Syrjälä did through the docs they have available to them, they discovered that there's actually supposed to be a 30ms wait after writing the source OUI before we begin setting up the rest of the backlight interface.
This seems to be correct, as adding this 30ms delay seems to have completely fixed the probing issues I was previously seeing. So - let's start performing a 30ms wait after writing the OUI, which we do in a manner similar to how we keep track of PPS delays (e.g. record the timestamp of the OUI write, and then wait for however many ms are left since that timestamp right before we interact with the backlight) in order to avoid waiting any longer then we need to. As well, this also avoids us performing this delay on systems where we don't end up using the HDR backlight interface.
V3: * Move last_oui_write into intel_dp V2: * Move panel delays into intel_pps
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211130212912.212044-1-lyude@redhat.com
show more ...
|
Revision tags: v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9 |
|
#
1e39da5a |
| 29-Sep-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Enable TPS3/4 on all platforms that support them
Stop using HBR2/3 support as a proxy for TPS3/4 support. The two are no longer 1:1 in the hardware, arguably they never were due to HSW ULX
drm/i915: Enable TPS3/4 on all platforms that support them
Stop using HBR2/3 support as a proxy for TPS3/4 support. The two are no longer 1:1 in the hardware, arguably they never were due to HSW ULX which does support TPS3 while being limited to HBR1.
In more recent times GLK gained support for TPS4 while being limited to HBR2. And on CNL+ some ports support HBR3 while others are limited to HBR2, but all ports support TPS4.
v2: s/INTEL_GEN/DISPLAY_VER/
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929162404.6717-1-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
show more ...
|
Revision tags: v5.14.8 |
|
#
9ce5884e |
| 22-Sep-2021 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Only keep PSR enabled if there is active planes
PSR always had a requirement to only be enabled if there is active planes but not following that never caused any issues. But that c
drm/i915/display: Only keep PSR enabled if there is active planes
PSR always had a requirement to only be enabled if there is active planes but not following that never caused any issues. But that changes in Alderlake-P, leaving PSR enabled without active planes causes transcoder/port underruns.
Similar behavior was fixed during the pipe disable sequence by commit 84030adb9e27 ("drm/i915/display: Disable audio, DRRS and PSR before planes").
intel_dp_compute_psr_vsc_sdp() had to move from intel_psr_enable_locked() to intel_psr_compute_config() because we need to be able to disable/enable PSR from atomic states without connector and encoder state.
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210922215242.66683-3-jose.souza@intel.com
show more ...
|
Revision tags: v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64 |
|
#
4e718a0e |
| 09-Sep-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: add helper for checking for UHBR link rate
Helpful abstraction to avoid duplication.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@
drm/i915/dp: add helper for checking for UHBR link rate
Helpful abstraction to avoid duplication.
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/fe9a222ad900da797c989de9f7fa13928d2c9861.1631191763.git.jani.nikula@intel.com
show more ...
|
Revision tags: v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14 |
|
#
a1b63119 |
| 27-Aug-2021 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Move DRRS code its own file
intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce some lines from it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Ni
drm/i915/display: Move DRRS code its own file
intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce some lines from it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210827174253.51122-2-jose.souza@intel.com
show more ...
|
Revision tags: v5.10.61 |
|
#
48efd014 |
| 23-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: add max data rate calculation for UHBR rates
DP 2.0 UHBR link rates always use 128b/132b channel encoding, which has a different data bandwidth efficiency from 8b/10b. The computation i
drm/i915/dp: add max data rate calculation for UHBR rates
DP 2.0 UHBR link rates always use 128b/132b channel encoding, which has a different data bandwidth efficiency from 8b/10b. The computation is slightly convoluted due to the units we use; this is all explained in the added comment.
v2: Clarified comment (Manasi)
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8afd8d97a04c2d86c2dcadfed9f8e1f84272a13c.1629735412.git.jani.nikula@intel.com
show more ...
|
#
f5b21c2e |
| 23-Aug-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/dp: use actual link rate values in struct link_config_limits
The MST code uses actual link rates in the limits struct, while the DP code in general uses indexes to the ->common_rates[] arra
drm/i915/dp: use actual link rate values in struct link_config_limits
The MST code uses actual link rates in the limits struct, while the DP code in general uses indexes to the ->common_rates[] array. Fix the confusion by using actual link rate values everywhere. This is a better abstraction than some obscure index.
Rename the struct members while at it to ensure all the places are covered.
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/d70ab7261abacd367d3a6a47102575eb88a55cd4.1629735412.git.jani.nikula@intel.com
show more ...
|
#
e2b3d1bf |
| 27-Aug-2021 |
José Roberto de Souza <jose.souza@intel.com> |
drm/i915/display: Move DRRS code its own file
[ Upstream commit a1b63119ee839c8ff622407aab25c9723943638a ]
intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce some lines from it.
drm/i915/display: Move DRRS code its own file
[ Upstream commit a1b63119ee839c8ff622407aab25c9723943638a ]
intel_dp.c is a 5k lines monster, so moving DRRS out of it to reduce some lines from it.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210827174253.51122-2-jose.souza@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
24524182 |
| 30-Nov-2021 |
Lyude Paul <lyude@redhat.com> |
drm/i915/dp: Perform 30ms delay after source OUI write
commit a44f42ba7f1ad7d3c17bc7d91013fe814a53c5dc upstream.
While working on supporting the Intel HDR backlight interface, I noticed that there'
drm/i915/dp: Perform 30ms delay after source OUI write
commit a44f42ba7f1ad7d3c17bc7d91013fe814a53c5dc upstream.
While working on supporting the Intel HDR backlight interface, I noticed that there's a couple of laptops that will very rarely manage to boot up without detecting Intel HDR backlight support - even though it's supported on the system. One example of such a laptop is the Lenovo P17 1st generation.
Following some investigation Ville Syrjälä did through the docs they have available to them, they discovered that there's actually supposed to be a 30ms wait after writing the source OUI before we begin setting up the rest of the backlight interface.
This seems to be correct, as adding this 30ms delay seems to have completely fixed the probing issues I was previously seeing. So - let's start performing a 30ms wait after writing the OUI, which we do in a manner similar to how we keep track of PPS delays (e.g. record the timestamp of the OUI write, and then wait for however many ms are left since that timestamp right before we interact with the backlight) in order to avoid waiting any longer then we need to. As well, this also avoids us performing this delay on systems where we don't end up using the HDR backlight interface.
V3: * Move last_oui_write into intel_dp V2: * Move panel delays into intel_pps
Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Fixes: 4a8d79901d5b ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211130212912.212044-1-lyude@redhat.com (cherry picked from commit c7c90b0b8418a97d3aa8b39aae1992908948efad) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33 |
|
#
b23109c5 |
| 27-Apr-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/hdcp: add intel_dp_hdcp.h and rename init accordingly
Add separate intel_dp_hdcp.h to go with intel_dp_hdcp.c, and rename the init function intel_dp_hdcp_init() to follow naming where funct
drm/i915/hdcp: add intel_dp_hdcp.h and rename init accordingly
Add separate intel_dp_hdcp.h to go with intel_dp_hdcp.c, and rename the init function intel_dp_hdcp_init() to follow naming where function prefix matches the file name.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210427114520.4740-1-jani.nikula@intel.com
show more ...
|
Revision tags: v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25 |
|
#
917c2899 |
| 18-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Introduce g4x_dp.c
Move the g4x+ DP code into a new file. This will leave mostly platform agnostic code in intel_dp.c. Well, the misplaced phy test stuff pretty much ruins that, but let's
drm/i915: Introduce g4x_dp.c
Move the g4x+ DP code into a new file. This will leave mostly platform agnostic code in intel_dp.c. Well, the misplaced phy test stuff pretty much ruins that, but let's squint real hard for now.
v2: Add comment exlaining which platforms are covered (Daniel) Leave intel_dp_unused_lane_mask() be since it is pretty generic
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-6-ville.syrjala@linux.intel.com
show more ...
|
#
764f6729 |
| 18-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split intel_ddi_encoder_reset() from intel_dp_encoder_reset()
Most of intel_dp_encoder_reset() is for pre-ddi platforms. Make a clean split.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwl
drm/i915: Split intel_ddi_encoder_reset() from intel_dp_encoder_reset()
Most of intel_dp_encoder_reset() is for pre-ddi platforms. Make a clean split.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-5-ville.syrjala@linux.intel.com
show more ...
|
#
b2ef0661 |
| 18-Mar-2021 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Relocate intel_dp_program_link_training_pattern()
intel_dp_program_link_training_pattern() clearly belongs in intel_dp_link_training.c. Make it so.
Reviewed-by: Daniel Vetter <daniel.vett
drm/i915: Relocate intel_dp_program_link_training_pattern()
intel_dp_program_link_training_pattern() clearly belongs in intel_dp_link_training.c. Make it so.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-4-ville.syrjala@linux.intel.com
show more ...
|
Revision tags: v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
2051c890 |
| 29-Dec-2020 |
Imre Deak <imre.deak@intel.com> |
drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c
intel_dp_set_signal_levels() is needed for link training, so move it to intel_dp_link_training.c.
Signed-off-by: Imre Deak
drm/i915/dp: Move intel_dp_set_signal_levels() to intel_dp_link_training.c
intel_dp_set_signal_levels() is needed for link training, so move it to intel_dp_link_training.c.
Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com (cherry picked from commit 1c6e527d6947ea77bebabe15bbeaa765a87b70ca) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
show more ...
|