linux-stable/drivers/gpu/drm/i915/display/intel_dp.c

6621 lines
192 KiB
C
Raw Normal View History

/*
* Copyright © 2008 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*
* Authors:
* Keith Packard <keithp@keithp.com>
*
*/
#include <linux/export.h>
#include <linux/i2c.h>
#include <linux/notifier.h>
#include <linux/slab.h>
#include <linux/string_helpers.h>
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
2021-11-30 21:29:09 +00:00
#include <linux/timekeeping.h>
#include <linux/types.h>
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
#include <asm/byteorder.h>
#include <drm/display/drm_dp_helper.h>
#include <drm/display/drm_dsc_helper.h>
#include <drm/display/drm_hdmi_helper.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_crtc.h>
#include <drm/drm_edid.h>
drm: Split out drm_probe_helper.h Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically v5: Actually try to sort them, and while at it, sort all the ones I touch. v6: Rebase onto i915 changes. v7: Rebase once more. Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: CK Hu <ck.hu@mediatek.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etnaviv@lists.freedesktop.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-tegra@vger.kernel.org Cc: xen-devel@lists.xen.org Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
2019-01-17 21:03:34 +00:00
#include <drm/drm_probe_helper.h>
#include "g4x_dp.h"
#include "i915_drv.h"
drm/i915: Check HPD live state during eDP probe We need to untangle the mess where some SKL machines (at least) declare both DDI A and DDI E to be present in their VBT, and both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a real DP->VGA converter. Currently that is handled by checking the VBT child devices for conflicts before output probing. But that kind of solution will not work for the ADL phantom dual eDP VBTs. I think on those we just have to probe the eDP first. And would be nice to use the same probe scheme for everything. On these SKL systems if we probe DDI A first (which is only natural given it's declared by VBT first) we will get an answer via AUX, but it came from the DP->VGA converter hooked to the DDI E, not DDI A. Thus we mistakenly register eDP on DDI A and screw up the real DP device in DDI E. To fix this let's check the HPD live state during the eDP probe. If we got an answer via DPCD but HPD is still down let's assume we got the answer from someone else. Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and I also tested turning off all HPD hardware prior to loading i915 to make sure it all comes up properly. And I simulated the failure path too by not turning on HPD sense and that correctly gave up on eDP. I *think* Windows might just fully depend on HPD here. I couldn't really find any other way they probe displays. And I did find code where they also check the live state prior to AUX transfers (something Imre and I have also talked about perhaps doing). That would also solve this as we'd not succeed in the eDP probe DPCD reads. Other solutions I've considered: - Reintrduce DDI strap checks on SKL. Unfortunately we just don't have any idea how reliable they are on real production hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A") does suggest that not very. Sadly that commit is very poor in details :/ Also the systems (Asrock B250M-HDV at least) fixed by commit 41e35ffb380b ("drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin") might still not work since we don't know what their straps indicate. Stupid me for not asking the reporter to check those at the time :( We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k both MS-7B54/Z370M) that also declare both DDI A and DDI E in VBT to use AUX A, and on these the DDI A strap is also set. There doesn't seem to be anything hooked up to either DDI however. But given the DDI A strap is wrong on these it might well be wrong on the Asrock too. Most other CI machines seem to have straps that generally match the VBT. fi-kbl-soraka is an exception though as DDI D strap is not set, but it is declared in VBT as a DP++ port. No idea if there's a real physical port to go with it or not. - Some kind of quirk just for the cases where both DDI A and DDI E are present in VBT. Might be feasible given we've ignored DDI A in these cases up to now successfully. But feels rather unsatisfactory, and not very future proof against funny VBTs. References: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com
2023-04-17 13:17:27 +00:00
#include "i915_irq.h"
#include "i915_reg.h"
#include "intel_atomic.h"
#include "intel_audio.h"
#include "intel_backlight.h"
#include "intel_combo_phy_regs.h"
#include "intel_connector.h"
#include "intel_crtc.h"
#include "intel_cx0_phy.h"
#include "intel_ddi.h"
#include "intel_de.h"
#include "intel_display_types.h"
#include "intel_dp.h"
#include "intel_dp_aux.h"
#include "intel_dp_hdcp.h"
#include "intel_dp_link_training.h"
#include "intel_dp_mst.h"
#include "intel_dpio_phy.h"
#include "intel_dpll.h"
#include "intel_fifo_underrun.h"
#include "intel_hdcp.h"
#include "intel_hdmi.h"
#include "intel_hotplug.h"
#include "intel_hotplug_irq.h"
#include "intel_lspcon.h"
#include "intel_lvds.h"
#include "intel_panel.h"
#include "intel_pch_display.h"
#include "intel_pps.h"
#include "intel_psr.h"
#include "intel_tc.h"
#include "intel_vdsc.h"
#include "intel_vrr.h"
#include "intel_crtc_state_dump.h"
/* DP DSC throughput values used for slice count calculations KPixels/s */
#define DP_DSC_PEAK_PIXEL_RATE 2720000
#define DP_DSC_MAX_ENC_THROUGHPUT_0 340000
#define DP_DSC_MAX_ENC_THROUGHPUT_1 400000
/* DP DSC FEC Overhead factor in ppm = 1/(0.972261) = 1.028530 */
#define DP_DSC_FEC_OVERHEAD_FACTOR 1028530
drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 14:48:20 +00:00
/* Compliance test status bits */
#define INTEL_DP_RESOLUTION_SHIFT_MASK 0
#define INTEL_DP_RESOLUTION_PREFERRED (1 << INTEL_DP_RESOLUTION_SHIFT_MASK)
#define INTEL_DP_RESOLUTION_STANDARD (2 << INTEL_DP_RESOLUTION_SHIFT_MASK)
#define INTEL_DP_RESOLUTION_FAILSAFE (3 << INTEL_DP_RESOLUTION_SHIFT_MASK)
/* Constants for DP DSC configurations */
static const u8 valid_dsc_bpp[] = {6, 8, 10, 12, 15};
/* With Single pipe configuration, HW is capable of supporting maximum
* of 4 slices per line.
*/
static const u8 valid_dsc_slicecount[] = {1, 2, 4};
/**
* intel_dp_is_edp - is the given port attached to an eDP panel (either CPU or PCH)
* @intel_dp: DP struct
*
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
*
* This function is not safe to use prior to encoder type being set.
*/
bool intel_dp_is_edp(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
return dig_port->base.type == INTEL_OUTPUT_EDP;
}
static void intel_dp_unset_edid(struct intel_dp *intel_dp);
/* Is link rate UHBR and thus 128b/132b? */
bool intel_dp_is_uhbr(const struct intel_crtc_state *crtc_state)
{
return drm_dp_is_uhbr_rate(crtc_state->port_clock);
}
/**
* intel_dp_link_symbol_size - get the link symbol size for a given link rate
* @rate: link rate in 10kbit/s units
*
* Returns the link symbol size in bits/symbol units depending on the link
* rate -> channel coding.
*/
int intel_dp_link_symbol_size(int rate)
{
return drm_dp_is_uhbr_rate(rate) ? 32 : 10;
}
/**
* intel_dp_link_symbol_clock - convert link rate to link symbol clock
* @rate: link rate in 10kbit/s units
*
* Returns the link symbol clock frequency in kHz units depending on the
* link rate and channel coding.
*/
int intel_dp_link_symbol_clock(int rate)
{
return DIV_ROUND_CLOSEST(rate * 10, intel_dp_link_symbol_size(rate));
}
drm/i915/dp: Ensure sink rate values are always valid Atm, there are no sink rate values set for DP (vs. eDP) sinks until the DPCD capabilities are successfully read from the sink. During this time intel_dp->num_common_rates is 0 which can lead to a intel_dp->common_rates[-1] (*) access, which is an undefined behaviour, in the following cases: - In intel_dp_sync_state(), if the encoder is enabled without a sink connected to the encoder's connector (BIOS enabled a monitor, but the user unplugged the monitor until the driver loaded). - In intel_dp_sync_state() if the encoder is enabled with a sink connected, but for some reason the DPCD read has failed. - In intel_dp_compute_link_config() if modesetting a connector without a sink connected on it. - In intel_dp_compute_link_config() if modesetting a connector with a a sink connected on it, but before probing the connector first. To avoid the (*) access in all the above cases, make sure that the sink rate table - and hence the common rate table - is always valid, by setting a default minimum sink rate when registering the connector before anything could use it. I also considered setting all the DP link rates by default, so that modesetting with higher resolution modes also succeeds in the last two cases above. However in case a sink is not connected that would stop working after the first modeset, due to the LT fallback logic. So this would need more work, beyond the scope of this fix. As I mentioned in the previous patch, I don't think the issue this patch fixes is user visible, however it is an undefined behaviour by definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. v2: Clear the default sink rates, before initializing these for eDP. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com
2021-10-18 14:34:17 +00:00
static void intel_dp_set_default_sink_rates(struct intel_dp *intel_dp)
{
intel_dp->sink_rates[0] = 162000;
intel_dp->num_sink_rates = 1;
}
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
/* update sink rates from dpcd */
static void intel_dp_set_dpcd_sink_rates(struct intel_dp *intel_dp)
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
{
static const int dp_rates[] = {
162000, 270000, 540000, 810000
};
int i, max_rate;
drm/i915: Switch to LTTPR non-transparent mode link training The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
2020-10-07 17:09:17 +00:00
int max_lttpr_rate;
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
drm/dp: Revert "drm/dp: Introduce EDID-based quirks" This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally these quirks were added because of the issues with using the eDP backlight interfaces on certain laptop panels, which made it impossible to properly probe for DPCD backlight support without having a whitelist for panels that we know have working VESA backlight control interfaces over DPCD. As well, it should be noted it was impossible to use the normal sink OUI for recognizing these panels as none of them actually filled out their OUIs, hence needing to resort to checking EDIDs. At the time we weren't really sure why certain panels had issues with DPCD backlight controls, but we eventually figured out that there was a second interface that these problematic laptop panels actually did work with and advertise properly: Intel's proprietary backlight interface for HDR panels. So far the testing we've done hasn't brought any panels to light that advertise this interface and don't support it properly, which means we finally have a real solution to this problem. As a result, we now have no need for the force DPCD backlight quirk, and furthermore this also removes the need for any kind of EDID quirk checking in DRM. So, let's just revert it for now since we were the only driver using this. v3: * Rebase v2: * Fix indenting error picked up by checkpatch in intel_edp_init_connector() Signed-off-by: Lyude Paul <lyude@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: thaytan@noraisin.net Cc: Vasily Khoruzhick <anarsoul@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-6-lyude@redhat.com
2020-09-15 16:49:13 +00:00
if (drm_dp_has_quirk(&intel_dp->desc, DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS)) {
/* Needed, e.g., for Apple MBP 2017, 15 inch eDP Retina panel */
static const int quirk_rates[] = { 162000, 270000, 324000 };
memcpy(intel_dp->sink_rates, quirk_rates, sizeof(quirk_rates));
intel_dp->num_sink_rates = ARRAY_SIZE(quirk_rates);
return;
}
/*
* Sink rates for 8b/10b.
*/
max_rate = drm_dp_bw_code_to_link_rate(intel_dp->dpcd[DP_MAX_LINK_RATE]);
drm/i915: Switch to LTTPR non-transparent mode link training The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
2020-10-07 17:09:17 +00:00
max_lttpr_rate = drm_dp_lttpr_max_link_rate(intel_dp->lttpr_common_caps);
if (max_lttpr_rate)
max_rate = min(max_rate, max_lttpr_rate);
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
for (i = 0; i < ARRAY_SIZE(dp_rates); i++) {
if (dp_rates[i] > max_rate)
break;
intel_dp->sink_rates[i] = dp_rates[i];
}
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
/*
* Sink rates for 128b/132b. If set, sink should support all 8b/10b
* rates and 10 Gbps.
*/
if (intel_dp->dpcd[DP_MAIN_LINK_CHANNEL_CODING] & DP_CAP_ANSI_128B132B) {
u8 uhbr_rates = 0;
BUILD_BUG_ON(ARRAY_SIZE(intel_dp->sink_rates) < ARRAY_SIZE(dp_rates) + 3);
drm_dp_dpcd_readb(&intel_dp->aux,
DP_128B132B_SUPPORTED_LINK_RATES, &uhbr_rates);
if (drm_dp_lttpr_count(intel_dp->lttpr_common_caps)) {
/* We have a repeater */
if (intel_dp->lttpr_common_caps[0] >= 0x20 &&
intel_dp->lttpr_common_caps[DP_MAIN_LINK_CHANNEL_CODING_PHY_REPEATER -
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV] &
DP_PHY_REPEATER_128B132B_SUPPORTED) {
/* Repeater supports 128b/132b, valid UHBR rates */
uhbr_rates &= intel_dp->lttpr_common_caps[DP_PHY_REPEATER_128B132B_RATES -
DP_LT_TUNABLE_PHY_REPEATER_FIELD_DATA_STRUCTURE_REV];
} else {
/* Does not support 128b/132b */
uhbr_rates = 0;
}
}
if (uhbr_rates & DP_UHBR10)
intel_dp->sink_rates[i++] = 1000000;
if (uhbr_rates & DP_UHBR13_5)
intel_dp->sink_rates[i++] = 1350000;
if (uhbr_rates & DP_UHBR20)
intel_dp->sink_rates[i++] = 2000000;
}
intel_dp->num_sink_rates = i;
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
}
static void intel_dp_set_sink_rates(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = &intel_dig_port->base;
intel_dp_set_dpcd_sink_rates(intel_dp);
if (intel_dp->num_sink_rates)
return;
drm_err(&dp_to_i915(intel_dp)->drm,
"[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD with no link rates, using defaults\n",
connector->base.base.id, connector->base.name,
encoder->base.base.id, encoder->base.name);
intel_dp_set_default_sink_rates(intel_dp);
}
static void intel_dp_set_default_max_sink_lane_count(struct intel_dp *intel_dp)
{
intel_dp->max_sink_lane_count = 1;
}
static void intel_dp_set_max_sink_lane_count(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = &intel_dig_port->base;
intel_dp->max_sink_lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
switch (intel_dp->max_sink_lane_count) {
case 1:
case 2:
case 4:
return;
}
drm_err(&dp_to_i915(intel_dp)->drm,
"[CONNECTOR:%d:%s][ENCODER:%d:%s] Invalid DPCD max lane count (%d), using default\n",
connector->base.base.id, connector->base.name,
encoder->base.base.id, encoder->base.name,
intel_dp->max_sink_lane_count);
intel_dp_set_default_max_sink_lane_count(intel_dp);
}
/* Get length of rates array potentially limited by max_rate. */
static int intel_dp_rate_limit_len(const int *rates, int len, int max_rate)
{
int i;
/* Limit results by potentially reduced max rate */
for (i = 0; i < len; i++) {
if (rates[len - i - 1] <= max_rate)
return len - i;
}
return 0;
}
/* Get length of common rates array potentially limited by max_rate. */
static int intel_dp_common_len_rate_limit(const struct intel_dp *intel_dp,
int max_rate)
{
return intel_dp_rate_limit_len(intel_dp->common_rates,
intel_dp->num_common_rates, max_rate);
}
static int intel_dp_common_rate(struct intel_dp *intel_dp, int index)
{
if (drm_WARN_ON(&dp_to_i915(intel_dp)->drm,
index < 0 || index >= intel_dp->num_common_rates))
return 162000;
return intel_dp->common_rates[index];
}
/* Theoretical max between source and sink */
static int intel_dp_max_common_rate(struct intel_dp *intel_dp)
{
return intel_dp_common_rate(intel_dp, intel_dp->num_common_rates - 1);
}
static int intel_dp_max_source_lane_count(struct intel_digital_port *dig_port)
{
int vbt_max_lanes = intel_bios_dp_max_lane_count(dig_port->base.devdata);
int max_lanes = dig_port->max_lanes;
if (vbt_max_lanes)
max_lanes = min(max_lanes, vbt_max_lanes);
return max_lanes;
}
/* Theoretical max between source and sink */
static int intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
int source_max = intel_dp_max_source_lane_count(dig_port);
int sink_max = intel_dp->max_sink_lane_count;
int lane_max = intel_tc_port_max_lane_count(dig_port);
drm/i915: Switch to LTTPR non-transparent mode link training The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
2020-10-07 17:09:17 +00:00
int lttpr_max = drm_dp_lttpr_max_lane_count(intel_dp->lttpr_common_caps);
if (lttpr_max)
sink_max = min(sink_max, lttpr_max);
return min3(source_max, sink_max, lane_max);
}
int intel_dp_max_lane_count(struct intel_dp *intel_dp)
{
switch (intel_dp->max_link_lane_count) {
case 1:
case 2:
case 4:
return intel_dp->max_link_lane_count;
default:
MISSING_CASE(intel_dp->max_link_lane_count);
return 1;
}
}
/*
* The required data bandwidth for a mode with given pixel clock and bpp. This
* is the required net bandwidth independent of the data bandwidth efficiency.
2023-11-17 15:09:29 +00:00
*
* TODO: check if callers of this functions should use
* intel_dp_effective_data_rate() instead.
*/
int
intel_dp_link_required(int pixel_clock, int bpp)
{
/* pixel_clock is in kHz, divide bpp by 8 for bit to Byte conversion */
return DIV_ROUND_UP(pixel_clock * bpp, 8);
}
2023-11-17 15:09:29 +00:00
/**
* intel_dp_effective_data_rate - Return the pixel data rate accounting for BW allocation overhead
* @pixel_clock: pixel clock in kHz
* @bpp_x16: bits per pixel .4 fixed point format
* @bw_overhead: BW allocation overhead in 1ppm units
*
* Return the effective pixel data rate in kB/sec units taking into account
* the provided SSC, FEC, DSC BW allocation overhead.
*/
int intel_dp_effective_data_rate(int pixel_clock, int bpp_x16,
int bw_overhead)
{
return DIV_ROUND_UP_ULL(mul_u32_u32(pixel_clock * bpp_x16, bw_overhead),
1000000 * 16 * 8);
}
/*
* Given a link rate and lanes, get the data bandwidth.
*
* Data bandwidth is the actual payload rate, which depends on the data
* bandwidth efficiency and the link rate.
*
* For 8b/10b channel encoding, SST and non-FEC, the data bandwidth efficiency
* is 80%. For example, for a 1.62 Gbps link, 1.62*10^9 bps * 0.80 * (1/8) =
* 162000 kBps. With 8-bit symbols, we have 162000 kHz symbol clock. Just by
* coincidence, the port clock in kHz matches the data bandwidth in kBps, and
* they equal the link bit rate in Gbps multiplied by 100000. (Note that this no
* longer holds for data bandwidth as soon as FEC or MST is taken into account!)
*
* For 128b/132b channel encoding, the data bandwidth efficiency is 96.71%. For
* example, for a 10 Gbps link, 10*10^9 bps * 0.9671 * (1/8) = 1208875
* kBps. With 32-bit symbols, we have 312500 kHz symbol clock. The value 1000000
* does not match the symbol clock, the port clock (not even if you think in
* terms of a byte clock), nor the data bandwidth. It only matches the link bit
* rate in units of 10000 bps.
*/
int
intel_dp_max_data_rate(int max_link_rate, int max_lanes)
{
int ch_coding_efficiency =
drm_dp_bw_channel_coding_efficiency(drm_dp_is_uhbr_rate(max_link_rate));
int max_link_rate_kbps = max_link_rate * 10;
/*
* UHBR rates always use 128b/132b channel encoding, and have
* 97.71% data bandwidth efficiency. Consider max_link_rate the
* link bit rate in units of 10000 bps.
*/
/*
* Lower than UHBR rates always use 8b/10b channel encoding, and have
* 80% data bandwidth efficiency for SST non-FEC. However, this turns
* out to be a nop by coincidence:
*
* int max_link_rate_kbps = max_link_rate * 10;
* max_link_rate_kbps = DIV_ROUND_DOWN_ULL(max_link_rate_kbps * 8, 10);
* max_link_rate = max_link_rate_kbps / 8;
*/
return DIV_ROUND_DOWN_ULL(mul_u32_u32(max_link_rate_kbps * max_lanes,
ch_coding_efficiency),
1000000 * 8);
}
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
bool intel_dp_can_bigjoiner(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = &intel_dig_port->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
return DISPLAY_VER(dev_priv) >= 12 ||
drm/i915/display: rename display version macros While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
2021-04-13 05:09:53 +00:00
(DISPLAY_VER(dev_priv) == 11 &&
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
encoder->port != PORT_A);
}
static int dg2_max_source_rate(struct intel_dp *intel_dp)
{
return intel_dp_is_edp(intel_dp) ? 810000 : 1350000;
}
static int icl_max_source_rate(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
enum phy phy = intel_port_to_phy(dev_priv, dig_port->base.port);
if (intel_phy_is_combo(dev_priv, phy) && !intel_dp_is_edp(intel_dp))
return 540000;
return 810000;
}
static int ehl_max_source_rate(struct intel_dp *intel_dp)
{
if (intel_dp_is_edp(intel_dp))
return 540000;
return 810000;
}
static int mtl_max_source_rate(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
if (intel_is_c10phy(i915, phy))
return 810000;
return 2000000;
}
static int vbt_max_link_rate(struct intel_dp *intel_dp)
{
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
int max_rate;
max_rate = intel_bios_dp_max_link_rate(encoder->devdata);
if (intel_dp_is_edp(intel_dp)) {
struct intel_connector *connector = intel_dp->attached_connector;
int edp_max_rate = connector->panel.vbt.edp.max_link_rate;
if (max_rate && edp_max_rate)
max_rate = min(max_rate, edp_max_rate);
else if (edp_max_rate)
max_rate = edp_max_rate;
}
return max_rate;
}
static void
intel_dp_set_source_rates(struct intel_dp *intel_dp)
{
/* The values must be in increasing order */
static const int mtl_rates[] = {
162000, 216000, 243000, 270000, 324000, 432000, 540000, 675000,
810000, 1000000, 1350000, 2000000,
};
static const int icl_rates[] = {
162000, 216000, 270000, 324000, 432000, 540000, 648000, 810000,
1000000, 1350000,
};
static const int bxt_rates[] = {
162000, 216000, 243000, 270000, 324000, 432000, 540000
};
static const int skl_rates[] = {
162000, 216000, 270000, 324000, 432000, 540000
};
static const int hsw_rates[] = {
162000, 270000, 540000
};
static const int g4x_rates[] = {
162000, 270000
};
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
const int *source_rates;
int size, max_rate = 0, vbt_max_rate;
/* This should only be done once */
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
drm_WARN_ON(&dev_priv->drm,
intel_dp->source_rates || intel_dp->num_source_rates);
if (DISPLAY_VER(dev_priv) >= 14) {
source_rates = mtl_rates;
size = ARRAY_SIZE(mtl_rates);
max_rate = mtl_max_source_rate(intel_dp);
} else if (DISPLAY_VER(dev_priv) >= 11) {
source_rates = icl_rates;
size = ARRAY_SIZE(icl_rates);
if (IS_DG2(dev_priv))
max_rate = dg2_max_source_rate(intel_dp);
else if (IS_ALDERLAKE_P(dev_priv) || IS_ALDERLAKE_S(dev_priv) ||
IS_DG1(dev_priv) || IS_ROCKETLAKE(dev_priv))
max_rate = 810000;
else if (IS_JASPERLAKE(dev_priv) || IS_ELKHARTLAKE(dev_priv))
max_rate = ehl_max_source_rate(intel_dp);
else
max_rate = icl_max_source_rate(intel_dp);
} else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) {
source_rates = bxt_rates;
size = ARRAY_SIZE(bxt_rates);
drm/i915/display: rename display version macros While converting the rest of the driver to use GRAPHICS_VER() and MEDIA_VER(), following what was done for display, some discussions went back on what we did for display: 1) Why is the == comparison special that deserves a separate macro instead of just getting the version and comparing directly like is done for >, >=, <=? 2) IS_DISPLAY_RANGE() is weird in that it omits the "_VER" for brevity. If we remove the current users of IS_DISPLAY_VER(), we could actually repurpose it for a range check With (1) there could be an advantage if we used gen_mask since multiple conditionals be combined by the compiler in a single and instruction and check the result. However a) INTEL_GEN() doesn't use the mask since it would make the code bigger everywhere else and b) in the cases it made sense, it also made sense to convert to the _RANGE() variant. So here we repurpose IS_DISPLAY_VER() to work with a [ from, to ] range like was the IS_DISPLAY_RANGE() and convert the current IS_DISPLAY_VER() users to use == and != operators. Aside from the definition changes, this was done by the following semantic patch: @@ expression dev_priv, E1; @@ - !IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) != E1 @@ expression dev_priv, E1; @@ - IS_DISPLAY_VER(dev_priv, E1) + DISPLAY_VER(dev_priv) == E1 @@ expression dev_priv, from, until; @@ - IS_DISPLAY_RANGE(dev_priv, from, until) + IS_DISPLAY_VER(dev_priv, from, until) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> [Jani: Minor conflict resolve while applying.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210413051002.92589-4-lucas.demarchi@intel.com
2021-04-13 05:09:53 +00:00
} else if (DISPLAY_VER(dev_priv) == 9) {
source_rates = skl_rates;
size = ARRAY_SIZE(skl_rates);
} else if ((IS_HASWELL(dev_priv) && !IS_HASWELL_ULX(dev_priv)) ||
IS_BROADWELL(dev_priv)) {
source_rates = hsw_rates;
size = ARRAY_SIZE(hsw_rates);
} else {
source_rates = g4x_rates;
size = ARRAY_SIZE(g4x_rates);
}
vbt_max_rate = vbt_max_link_rate(intel_dp);
if (max_rate && vbt_max_rate)
max_rate = min(max_rate, vbt_max_rate);
else if (vbt_max_rate)
max_rate = vbt_max_rate;
if (max_rate)
size = intel_dp_rate_limit_len(source_rates, size, max_rate);
intel_dp->source_rates = source_rates;
intel_dp->num_source_rates = size;
}
static int intersect_rates(const int *source_rates, int source_len,
const int *sink_rates, int sink_len,
int *common_rates)
{
int i = 0, j = 0, k = 0;
while (i < source_len && j < sink_len) {
if (source_rates[i] == sink_rates[j]) {
if (WARN_ON(k >= DP_MAX_SUPPORTED_RATES))
return k;
common_rates[k] = source_rates[i];
++k;
++i;
++j;
} else if (source_rates[i] < sink_rates[j]) {
++i;
} else {
++j;
}
}
return k;
}
/* return index of rate in rates array, or -1 if not found */
static int intel_dp_rate_index(const int *rates, int len, int rate)
{
int i;
for (i = 0; i < len; i++)
if (rate == rates[i])
return i;
return -1;
}
static void intel_dp_set_common_rates(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
drm_WARN_ON(&i915->drm,
!intel_dp->num_source_rates || !intel_dp->num_sink_rates);
intel_dp->num_common_rates = intersect_rates(intel_dp->source_rates,
intel_dp->num_source_rates,
intel_dp->sink_rates,
intel_dp->num_sink_rates,
intel_dp->common_rates);
/* Paranoia, there should always be something in common. */
if (drm_WARN_ON(&i915->drm, intel_dp->num_common_rates == 0)) {
intel_dp->common_rates[0] = 162000;
intel_dp->num_common_rates = 1;
}
}
static bool intel_dp_link_params_valid(struct intel_dp *intel_dp, int link_rate,
u8 lane_count)
drm/i915/dp: Validate cached link rate and lane count before retraining Currently intel_dp_check_link_status() tries to retrain the link if Clock recovery or Channel EQ for any of the lanes indicated by intel_dp->lane_count is not set. However these values cached in intel_dp structure can be stale if link training has failed for these values during previous modeset. Or these values can get stale since we have now re read the DPCD registers or it can be 0 in case of connected boot case. This patch validates these values against the max link rate and max lane count values. This is absolutely required incase the common_rates or max lane count are now different due to link fallback. v2: * Include the FIXME commnet inside the function (Ville Syrjala) * Remove the redundant parenthesis (Ville Syrjala) v3 by Jani: * rebase on the DP refactoring series * rename intel_dp_link_params_is_valid to intel_dp_link_params_valid * minor stylistic changes v4: * Compare the link rate against max link rate not the common_rates since common_rates does not account for the lowered fallback link rate value. (Ville Syrjala) v5: * Fixed a warning for unused variable (Manasi) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491512412-30016-1-git-send-email-manasi.d.navare@intel.com
2017-04-06 21:00:12 +00:00
{
/*
* FIXME: we need to synchronize the current link parameters with
* hardware readout. Currently fast link training doesn't work on
* boot-up.
*/
if (link_rate == 0 ||
link_rate > intel_dp->max_link_rate)
drm/i915/dp: Validate cached link rate and lane count before retraining Currently intel_dp_check_link_status() tries to retrain the link if Clock recovery or Channel EQ for any of the lanes indicated by intel_dp->lane_count is not set. However these values cached in intel_dp structure can be stale if link training has failed for these values during previous modeset. Or these values can get stale since we have now re read the DPCD registers or it can be 0 in case of connected boot case. This patch validates these values against the max link rate and max lane count values. This is absolutely required incase the common_rates or max lane count are now different due to link fallback. v2: * Include the FIXME commnet inside the function (Ville Syrjala) * Remove the redundant parenthesis (Ville Syrjala) v3 by Jani: * rebase on the DP refactoring series * rename intel_dp_link_params_is_valid to intel_dp_link_params_valid * minor stylistic changes v4: * Compare the link rate against max link rate not the common_rates since common_rates does not account for the lowered fallback link rate value. (Ville Syrjala) v5: * Fixed a warning for unused variable (Manasi) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491512412-30016-1-git-send-email-manasi.d.navare@intel.com
2017-04-06 21:00:12 +00:00
return false;
if (lane_count == 0 ||
lane_count > intel_dp_max_lane_count(intel_dp))
drm/i915/dp: Validate cached link rate and lane count before retraining Currently intel_dp_check_link_status() tries to retrain the link if Clock recovery or Channel EQ for any of the lanes indicated by intel_dp->lane_count is not set. However these values cached in intel_dp structure can be stale if link training has failed for these values during previous modeset. Or these values can get stale since we have now re read the DPCD registers or it can be 0 in case of connected boot case. This patch validates these values against the max link rate and max lane count values. This is absolutely required incase the common_rates or max lane count are now different due to link fallback. v2: * Include the FIXME commnet inside the function (Ville Syrjala) * Remove the redundant parenthesis (Ville Syrjala) v3 by Jani: * rebase on the DP refactoring series * rename intel_dp_link_params_is_valid to intel_dp_link_params_valid * minor stylistic changes v4: * Compare the link rate against max link rate not the common_rates since common_rates does not account for the lowered fallback link rate value. (Ville Syrjala) v5: * Fixed a warning for unused variable (Manasi) Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1491512412-30016-1-git-send-email-manasi.d.navare@intel.com
2017-04-06 21:00:12 +00:00
return false;
return true;
}
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
static bool intel_dp_can_link_train_fallback_for_edp(struct intel_dp *intel_dp,
int link_rate,
u8 lane_count)
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
{
/* FIXME figure out what we actually want here */
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
const struct drm_display_mode *fixed_mode =
intel_panel_preferred_fixed_mode(intel_dp->attached_connector);
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
int mode_rate, max_rate;
mode_rate = intel_dp_link_required(fixed_mode->clock, 18);
max_rate = intel_dp_max_data_rate(link_rate, lane_count);
if (mode_rate > max_rate)
return false;
return true;
}
int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
int link_rate, u8 lane_count)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int index;
drm/i915/dp_mst: Disable link training fallback on MST links During the initial probing of an MST sink, MST core will determine the sink's link bandwidth based on its own version of the sink link rate/lane count caps it reads from the DPCD. At a later point (after probing and 1 or more modesets) i915 may limit the link parameters wrt. the original source/sink common caps above due to link training failures during a modeset and the resulting link training fallback logic. Based on the above a modeset following another modeset with a link training error will compute the i915 HW specific and DP protocol timing parameters (data/link M/N and MST TU values) taking into account only the unlimited source/sink common caps, but not taking into account the fallback limits. This will also let DRM core oversubscribe the actual link bandwidth during the MST payload allocation. Prevent the above problem by disabling the link training fallback on MST links for now, until the MST probe time initialization and the MST compute config logic can deal with changing link parameters. The misconfigured timings lead at least to a 'Timed out waiting for DP idle patterns' error. v2: (Ville) - Print link training error message on the MST path too. - Clarify the problem in the commit log. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> 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/20200616211146.23027-2-imre.deak@intel.com
2020-06-16 21:11:45 +00:00
/*
* TODO: Enable fallback on MST links once MST link compute can handle
* the fallback params.
*/
if (intel_dp->is_mst) {
drm_err(&i915->drm, "Link Training Unsuccessful\n");
return -1;
}
drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Some new eDP panels don't like to operate at the max parameters, and instead we need to go for an optimal confiugration. That unfortunately doesn't work with older eDP panels which are generally only guaranteed to work at the max parameters. To solve these two conflicting requirements let's start with the optimal setup, and if that fails we start again with the max parameters. The downside is probably an extra modeset when we switch strategies but I don't see a good way to avoid that. For a bit of history we first tried to go for the fast+narrow in commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow"). but that had to be reverted due to regression on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"). So now we try to get the best of both worlds by using both strategies. v2: Deal with output_bpp and uapi vs. hw state split Reword some comments v3: Rebase Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267 References: https://bugs.freedesktop.org/show_bug.cgi?id=109959 References: https://gitlab.freedesktop.org/drm/intel/issues/272 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
2021-01-07 18:20:25 +00:00
if (intel_dp_is_edp(intel_dp) && !intel_dp->use_max_params) {
drm_dbg_kms(&i915->drm,
"Retrying Link training for eDP with max parameters\n");
intel_dp->use_max_params = true;
return 0;
}
index = intel_dp_rate_index(intel_dp->common_rates,
intel_dp->num_common_rates,
link_rate);
if (index > 0) {
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
if (intel_dp_is_edp(intel_dp) &&
!intel_dp_can_link_train_fallback_for_edp(intel_dp,
intel_dp_common_rate(intel_dp, index - 1),
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
lane_count)) {
drm_dbg_kms(&i915->drm,
"Retrying Link training for eDP with same parameters\n");
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
return 0;
}
intel_dp->max_link_rate = intel_dp_common_rate(intel_dp, index - 1);
intel_dp->max_link_lane_count = lane_count;
} else if (lane_count > 1) {
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
if (intel_dp_is_edp(intel_dp) &&
!intel_dp_can_link_train_fallback_for_edp(intel_dp,
intel_dp_max_common_rate(intel_dp),
lane_count >> 1)) {
drm_dbg_kms(&i915->drm,
"Retrying Link training for eDP with same parameters\n");
drm/i915/dp: Link train Fallback on eDP only if fallback link BW can fit panel's native mode This patch fixes the original commit c0cfb10d9e1de49 ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") that causes a blank screen in case of certain eDP panels (Eg: seen on Dell XPS13 9350) where first link training fails and a retraining is required by falling back to lower link rate/lane count. In case of some panels they advertise higher link rate/lane count than whats required for supporting the panel's native mode. But we always link train at highest link rate/lane count for eDP and if that fails we can still fallback to lower link rate/lane count as long as the fallback link BW still fits the native mode to avoid pruning the panel's native mode yet retraining at fallback values to recover from a blank screen. v3: * Add const for fixed_mode (Ville) v2: * Send uevent if link failure on eDP unconditionally Fixes: c0cfb10d9e1d ("drm/i915/edp: Do not do link training fallback or prune modes on EDP") Cc: Clinton Taylor <clinton.a.taylor@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v4.17+ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107489 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105338 Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Tested-by: Alexander Wilson <alexander.wilson@ncf.edu> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009212804.702-1-manasi.d.navare@intel.com
2018-10-09 21:28:04 +00:00
return 0;
}
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->max_link_lane_count = lane_count >> 1;
} else {
drm_err(&i915->drm, "Link Training Unsuccessful\n");
return -1;
}
return 0;
}
u32 intel_dp_mode_to_fec_clock(u32 mode_clock)
{
return div_u64(mul_u32_u32(mode_clock, DP_DSC_FEC_OVERHEAD_FACTOR),
1000000U);
}
int intel_dp_bw_fec_overhead(bool fec_enabled)
{
/*
* TODO: Calculate the actual overhead for a given mode.
* The hard-coded 1/0.972261=2.853% overhead factor
* corresponds (for instance) to the 8b/10b DP FEC 2.4% +
* 0.453% DSC overhead. This is enough for a 3840 width mode,
* which has a DSC overhead of up to ~0.2%, but may not be
* enough for a 1024 width mode where this is ~0.8% (on a 4
* lane DP link, with 2 DSC slices and 8 bpp color depth).
*/
return fec_enabled ? DP_DSC_FEC_OVERHEAD_FACTOR : 1000000;
}
static int
small_joiner_ram_size_bits(struct drm_i915_private *i915)
{
if (DISPLAY_VER(i915) >= 13)
return 17280 * 8;
else if (DISPLAY_VER(i915) >= 11)
return 7680 * 8;
else
return 6144 * 8;
}
u32 intel_dp_dsc_nearest_valid_bpp(struct drm_i915_private *i915, u32 bpp, u32 pipe_bpp)
{
u32 bits_per_pixel = bpp;
int i;
/* Error out if the max bpp is less than smallest allowed valid bpp */
if (bits_per_pixel < valid_dsc_bpp[0]) {
drm_dbg_kms(&i915->drm, "Unsupported BPP %u, min %u\n",
bits_per_pixel, valid_dsc_bpp[0]);
return 0;
}
/* From XE_LPD onwards we support from bpc upto uncompressed bpp-1 BPPs */
if (DISPLAY_VER(i915) >= 13) {
bits_per_pixel = min(bits_per_pixel, pipe_bpp - 1);
drm/i915: Ensure DSC has enough BW and stays within HW limits We currently have an issue with some BPPs when using DSC. According to the HW team, the reason is that a single VDSC engine instance has some BW limitations that must be accounted for. So, whenever we approach around 90% of the CDCLK, a second VDSC engine has to be used. This always means using two slices. However, in our current code, the amount of slices is calculated independently of whether we need to enable the second VDSC engine or not. This leads to some logical issues when, according to the pixel clock needs, we need to enable the second VDSC engine. But as we calculated previously that we can only use a single slice, we can't do that and fail. So, we need to fix that so that the number of VDSC engines enabled should depend on the number of slices, and the number of slices should also depend on BW requirements. Lastly, we didn't have BPP limitation for ADLP/MTL/DG2 implemented, which says that DSC output BPPs can only be chosen within the range of 8 to 27 (BSpec 49259). All of this applied together allows us to fix existing FIFO underruns, which we have in many DSC tests. v2: - Replace min with clamp_t(Jani Nikula) - Fix commit message(Swati Sharma) - Added "Closes"(Swati Sharma) BSpec: 49259 HSDES: 18027167222 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8231 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230306080401.22552-1-stanislav.lisovskiy@intel.com
2023-03-06 08:04:01 +00:00
/*
* According to BSpec, 27 is the max DSC output bpp,
* 8 is the min DSC output bpp.
* While we can still clamp higher bpp values to 27, saving bandwidth,
* if it is required to oompress up to bpp < 8, means we can't do
* that and probably means we can't fit the required mode, even with
* DSC enabled.
drm/i915: Ensure DSC has enough BW and stays within HW limits We currently have an issue with some BPPs when using DSC. According to the HW team, the reason is that a single VDSC engine instance has some BW limitations that must be accounted for. So, whenever we approach around 90% of the CDCLK, a second VDSC engine has to be used. This always means using two slices. However, in our current code, the amount of slices is calculated independently of whether we need to enable the second VDSC engine or not. This leads to some logical issues when, according to the pixel clock needs, we need to enable the second VDSC engine. But as we calculated previously that we can only use a single slice, we can't do that and fail. So, we need to fix that so that the number of VDSC engines enabled should depend on the number of slices, and the number of slices should also depend on BW requirements. Lastly, we didn't have BPP limitation for ADLP/MTL/DG2 implemented, which says that DSC output BPPs can only be chosen within the range of 8 to 27 (BSpec 49259). All of this applied together allows us to fix existing FIFO underruns, which we have in many DSC tests. v2: - Replace min with clamp_t(Jani Nikula) - Fix commit message(Swati Sharma) - Added "Closes"(Swati Sharma) BSpec: 49259 HSDES: 18027167222 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8231 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230306080401.22552-1-stanislav.lisovskiy@intel.com
2023-03-06 08:04:01 +00:00
*/
if (bits_per_pixel < 8) {
drm_dbg_kms(&i915->drm, "Unsupported BPP %u, min 8\n",
bits_per_pixel);
return 0;
}
bits_per_pixel = min_t(u32, bits_per_pixel, 27);
} else {
/* Find the nearest match in the array of known BPPs from VESA */
for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp) - 1; i++) {
if (bits_per_pixel < valid_dsc_bpp[i + 1])
break;
}
drm_dbg_kms(&i915->drm, "Set dsc bpp from %d to VESA %d\n",
bits_per_pixel, valid_dsc_bpp[i]);
bits_per_pixel = valid_dsc_bpp[i];
}
return bits_per_pixel;
}
static
u32 get_max_compressed_bpp_with_joiner(struct drm_i915_private *i915,
u32 mode_clock, u32 mode_hdisplay,
bool bigjoiner)
{
u32 max_bpp_small_joiner_ram;
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joiner_ram = small_joiner_ram_size_bits(i915) / mode_hdisplay;
if (bigjoiner) {
int bigjoiner_interface_bits = DISPLAY_VER(i915) >= 14 ? 36 : 24;
/* With bigjoiner multiple dsc engines are used in parallel so PPC is 2 */
int ppc = 2;
u32 max_bpp_bigjoiner =
i915->display.cdclk.max_cdclk_freq * ppc * bigjoiner_interface_bits /
intel_dp_mode_to_fec_clock(mode_clock);
max_bpp_small_joiner_ram *= 2;
return min(max_bpp_small_joiner_ram, max_bpp_bigjoiner);
}
return max_bpp_small_joiner_ram;
}
u16 intel_dp_dsc_get_max_compressed_bpp(struct drm_i915_private *i915,
u32 link_clock, u32 lane_count,
u32 mode_clock, u32 mode_hdisplay,
bool bigjoiner,
enum intel_output_format output_format,
u32 pipe_bpp,
u32 timeslots)
{
u32 bits_per_pixel, joiner_max_bpp;
/*
* Available Link Bandwidth(Kbits/sec) = (NumberOfLanes)*
* (LinkSymbolClock)* 8 * (TimeSlots / 64)
* for SST -> TimeSlots is 64(i.e all TimeSlots that are available)
* for MST -> TimeSlots has to be calculated, based on mode requirements
*
* Due to FEC overhead, the available bw is reduced to 97.2261%.
* To support the given mode:
* Bandwidth required should be <= Available link Bandwidth * FEC Overhead
* =>ModeClock * bits_per_pixel <= Available Link Bandwidth * FEC Overhead
* =>bits_per_pixel <= Available link Bandwidth * FEC Overhead / ModeClock
* =>bits_per_pixel <= (NumberOfLanes * LinkSymbolClock) * 8 (TimeSlots / 64) /
* (ModeClock / FEC Overhead)
* =>bits_per_pixel <= (NumberOfLanes * LinkSymbolClock * TimeSlots) /
* (ModeClock / FEC Overhead * 8)
*/
bits_per_pixel = ((link_clock * lane_count) * timeslots) /
(intel_dp_mode_to_fec_clock(mode_clock) * 8);
/* Bandwidth required for 420 is half, that of 444 format */
if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
bits_per_pixel *= 2;
/*
* According to DSC 1.2a Section 4.1.1 Table 4.1 the maximum
* supported PPS value can be 63.9375 and with the further
* mention that for 420, 422 formats, bpp should be programmed double
* the target bpp restricting our target bpp to be 31.9375 at max.
*/
if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
bits_per_pixel = min_t(u32, bits_per_pixel, 31);
drm_dbg_kms(&i915->drm, "Max link bpp is %u for %u timeslots "
"total bw %u pixel clock %u\n",
bits_per_pixel, timeslots,
(link_clock * lane_count * 8),
intel_dp_mode_to_fec_clock(mode_clock));
joiner_max_bpp = get_max_compressed_bpp_with_joiner(i915, mode_clock,
mode_hdisplay, bigjoiner);
bits_per_pixel = min(bits_per_pixel, joiner_max_bpp);
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
bits_per_pixel = intel_dp_dsc_nearest_valid_bpp(i915, bits_per_pixel, pipe_bpp);
return bits_per_pixel;
}
u8 intel_dp_dsc_get_slice_count(const struct intel_connector *connector,
int mode_clock, int mode_hdisplay,
bool bigjoiner)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
u8 min_slice_count, i;
int max_slice_width;
if (mode_clock <= DP_DSC_PEAK_PIXEL_RATE)
min_slice_count = DIV_ROUND_UP(mode_clock,
DP_DSC_MAX_ENC_THROUGHPUT_0);
else
min_slice_count = DIV_ROUND_UP(mode_clock,
DP_DSC_MAX_ENC_THROUGHPUT_1);
drm/i915: Ensure DSC has enough BW and stays within HW limits We currently have an issue with some BPPs when using DSC. According to the HW team, the reason is that a single VDSC engine instance has some BW limitations that must be accounted for. So, whenever we approach around 90% of the CDCLK, a second VDSC engine has to be used. This always means using two slices. However, in our current code, the amount of slices is calculated independently of whether we need to enable the second VDSC engine or not. This leads to some logical issues when, according to the pixel clock needs, we need to enable the second VDSC engine. But as we calculated previously that we can only use a single slice, we can't do that and fail. So, we need to fix that so that the number of VDSC engines enabled should depend on the number of slices, and the number of slices should also depend on BW requirements. Lastly, we didn't have BPP limitation for ADLP/MTL/DG2 implemented, which says that DSC output BPPs can only be chosen within the range of 8 to 27 (BSpec 49259). All of this applied together allows us to fix existing FIFO underruns, which we have in many DSC tests. v2: - Replace min with clamp_t(Jani Nikula) - Fix commit message(Swati Sharma) - Added "Closes"(Swati Sharma) BSpec: 49259 HSDES: 18027167222 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8231 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230306080401.22552-1-stanislav.lisovskiy@intel.com
2023-03-06 08:04:01 +00:00
/*
* Due to some DSC engine BW limitations, we need to enable second
* slice and VDSC engine, whenever we approach close enough to max CDCLK
*/
if (mode_clock >= ((i915->display.cdclk.max_cdclk_freq * 85) / 100))
min_slice_count = max_t(u8, min_slice_count, 2);
max_slice_width = drm_dp_dsc_sink_max_slice_width(connector->dp.dsc_dpcd);
if (max_slice_width < DP_DSC_MIN_SLICE_WIDTH_VALUE) {
drm_dbg_kms(&i915->drm,
"Unsupported slice width %d by DP DSC Sink device\n",
max_slice_width);
return 0;
}
/* Also take into account max slice width */
min_slice_count = max_t(u8, min_slice_count,
DIV_ROUND_UP(mode_hdisplay,
max_slice_width));
/* Find the closest match to the valid slice count values */
for (i = 0; i < ARRAY_SIZE(valid_dsc_slicecount); i++) {
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
u8 test_slice_count = valid_dsc_slicecount[i] << bigjoiner;
if (test_slice_count >
drm_dp_dsc_sink_max_slice_count(connector->dp.dsc_dpcd, false))
break;
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
/* big joiner needs small joiner to be enabled */
if (bigjoiner && test_slice_count < 4)
continue;
if (min_slice_count <= test_slice_count)
return test_slice_count;
}
drm_dbg_kms(&i915->drm, "Unsupported Slice Count %d\n",
min_slice_count);
return 0;
}
static bool source_can_output(struct intel_dp *intel_dp,
enum intel_output_format format)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
switch (format) {
case INTEL_OUTPUT_FORMAT_RGB:
return true;
case INTEL_OUTPUT_FORMAT_YCBCR444:
/*
* No YCbCr output support on gmch platforms.
* Also, ILK doesn't seem capable of DP YCbCr output.
* The displayed image is severly corrupted. SNB+ is fine.
*/
return !HAS_GMCH(i915) && !IS_IRONLAKE(i915);
case INTEL_OUTPUT_FORMAT_YCBCR420:
/* Platform < Gen 11 cannot output YCbCr420 format */
return DISPLAY_VER(i915) >= 11;
default:
MISSING_CASE(format);
return false;
}
}
static bool
dfp_can_convert_from_rgb(struct intel_dp *intel_dp,
enum intel_output_format sink_format)
{
if (!drm_dp_is_branch(intel_dp->dpcd))
return false;
if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
return intel_dp->dfp.rgb_to_ycbcr;
if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
return intel_dp->dfp.rgb_to_ycbcr &&
intel_dp->dfp.ycbcr_444_to_420;
return false;
}
static bool
dfp_can_convert_from_ycbcr444(struct intel_dp *intel_dp,
enum intel_output_format sink_format)
{
if (!drm_dp_is_branch(intel_dp->dpcd))
return false;
if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
return intel_dp->dfp.ycbcr_444_to_420;
return false;
}
static bool
dfp_can_convert(struct intel_dp *intel_dp,
enum intel_output_format output_format,
enum intel_output_format sink_format)
{
switch (output_format) {
case INTEL_OUTPUT_FORMAT_RGB:
return dfp_can_convert_from_rgb(intel_dp, sink_format);
case INTEL_OUTPUT_FORMAT_YCBCR444:
return dfp_can_convert_from_ycbcr444(intel_dp, sink_format);
default:
MISSING_CASE(output_format);
return false;
}
return false;
}
static enum intel_output_format
intel_dp_output_format(struct intel_connector *connector,
2023-04-27 12:56:00 +00:00
enum intel_output_format sink_format)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
enum intel_output_format force_dsc_output_format =
intel_dp->force_dsc_output_format;
enum intel_output_format output_format;
if (force_dsc_output_format) {
if (source_can_output(intel_dp, force_dsc_output_format) &&
(!drm_dp_is_branch(intel_dp->dpcd) ||
sink_format != force_dsc_output_format ||
dfp_can_convert(intel_dp, force_dsc_output_format, sink_format)))
return force_dsc_output_format;
drm_dbg_kms(&i915->drm, "Cannot force DSC output format\n");
}
if (sink_format == INTEL_OUTPUT_FORMAT_RGB ||
dfp_can_convert_from_rgb(intel_dp, sink_format))
output_format = INTEL_OUTPUT_FORMAT_RGB;
else if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
dfp_can_convert_from_ycbcr444(intel_dp, sink_format))
output_format = INTEL_OUTPUT_FORMAT_YCBCR444;
else
output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
drm_WARN_ON(&i915->drm, !source_can_output(intel_dp, output_format));
return output_format;
}
int intel_dp_min_bpp(enum intel_output_format output_format)
{
if (output_format == INTEL_OUTPUT_FORMAT_RGB)
return 6 * 3;
else
return 8 * 3;
}
int intel_dp_output_bpp(enum intel_output_format output_format, int bpp)
{
/*
* bpp value was assumed to RGB format. And YCbCr 4:2:0 output
* format of the number of bytes per pixel will be half the number
* of bytes of RGB pixel.
*/
if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
bpp /= 2;
return bpp;
}
static enum intel_output_format
intel_dp_sink_format(struct intel_connector *connector,
const struct drm_display_mode *mode)
{
const struct drm_display_info *info = &connector->base.display_info;
if (drm_mode_is_420_only(info, mode))
return INTEL_OUTPUT_FORMAT_YCBCR420;
return INTEL_OUTPUT_FORMAT_RGB;
}
static int
intel_dp_mode_min_output_bpp(struct intel_connector *connector,
const struct drm_display_mode *mode)
{
2023-04-27 12:56:00 +00:00
enum intel_output_format output_format, sink_format;
sink_format = intel_dp_sink_format(connector, mode);
2023-04-27 12:56:00 +00:00
output_format = intel_dp_output_format(connector, sink_format);
return intel_dp_output_bpp(output_format, intel_dp_min_bpp(output_format));
}
static bool intel_dp_hdisplay_bad(struct drm_i915_private *dev_priv,
int hdisplay)
{
/*
* Older platforms don't like hdisplay==4096 with DP.
*
* On ILK/SNB/IVB the pipe seems to be somewhat running (scanline
* and frame counter increment), but we don't get vblank interrupts,
* and the pipe underruns immediately. The link also doesn't seem
* to get trained properly.
*
* On CHV the vblank interrupts don't seem to disappear but
* otherwise the symptoms are similar.
*
* TODO: confirm the behaviour on HSW+
*/
return hdisplay == 4096 && !HAS_DDI(dev_priv);
}
static int intel_dp_max_tmds_clock(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
const struct drm_display_info *info = &connector->base.display_info;
int max_tmds_clock = intel_dp->dfp.max_tmds_clock;
/* Only consider the sink's max TMDS clock if we know this is a HDMI DFP */
if (max_tmds_clock && info->max_tmds_clock)
max_tmds_clock = min(max_tmds_clock, info->max_tmds_clock);
return max_tmds_clock;
}
static enum drm_mode_status
intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
int clock, int bpc,
enum intel_output_format sink_format,
bool respect_downstream_limits)
{
int tmds_clock, min_tmds_clock, max_tmds_clock;
if (!respect_downstream_limits)
return MODE_OK;
tmds_clock = intel_hdmi_tmds_clock(clock, bpc, sink_format);
min_tmds_clock = intel_dp->dfp.min_tmds_clock;
max_tmds_clock = intel_dp_max_tmds_clock(intel_dp);
if (min_tmds_clock && tmds_clock < min_tmds_clock)
return MODE_CLOCK_LOW;
if (max_tmds_clock && tmds_clock > max_tmds_clock)
return MODE_CLOCK_HIGH;
return MODE_OK;
}
static enum drm_mode_status
intel_dp_mode_valid_downstream(struct intel_connector *connector,
const struct drm_display_mode *mode,
int target_clock)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
const struct drm_display_info *info = &connector->base.display_info;
enum drm_mode_status status;
enum intel_output_format sink_format;
/* If PCON supports FRL MODE, check FRL bandwidth constraints */
if (intel_dp->dfp.pcon_max_frl_bw) {
int target_bw;
int max_frl_bw;
int bpp = intel_dp_mode_min_output_bpp(connector, mode);
target_bw = bpp * target_clock;
max_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
/* converting bw from Gbps to Kbps*/
max_frl_bw = max_frl_bw * 1000000;
if (target_bw > max_frl_bw)
return MODE_CLOCK_HIGH;
return MODE_OK;
}
if (intel_dp->dfp.max_dotclock &&
target_clock > intel_dp->dfp.max_dotclock)
return MODE_CLOCK_HIGH;
sink_format = intel_dp_sink_format(connector, mode);
/* Assume 8bpc for the DP++/HDMI/DVI TMDS clock check */
status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
8, sink_format, true);
if (status != MODE_OK) {
if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
!connector->base.ycbcr_420_allowed ||
!drm_mode_is_420_also(info, mode))
return status;
sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
8, sink_format, true);
if (status != MODE_OK)
return status;
}
return MODE_OK;
}
bool intel_dp_need_bigjoiner(struct intel_dp *intel_dp,
int hdisplay, int clock)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
if (!intel_dp_can_bigjoiner(intel_dp))
return false;
return clock > i915->max_dotclk_freq || hdisplay > 5120;
}
static enum drm_mode_status
intel_dp_mode_valid(struct drm_connector *_connector,
struct drm_display_mode *mode)
{
struct intel_connector *connector = to_intel_connector(_connector);
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
const struct drm_display_mode *fixed_mode;
int target_clock = mode->clock;
int max_rate, mode_rate, max_lanes, max_link_clock;
int max_dotclk = dev_priv->max_dotclk_freq;
u16 dsc_max_compressed_bpp = 0;
u8 dsc_slice_count = 0;
enum drm_mode_status status;
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
bool dsc = false, bigjoiner = false;
status = intel_cpu_transcoder_mode_valid(dev_priv, mode);
if (status != MODE_OK)
return status;
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
fixed_mode = intel_panel_fixed_mode(connector, mode);
if (intel_dp_is_edp(intel_dp) && fixed_mode) {
status = intel_panel_mode_valid(connector, mode);
if (status != MODE_OK)
return status;
target_clock = fixed_mode->clock;
}
if (mode->clock < 10000)
return MODE_CLOCK_LOW;
if (intel_dp_need_bigjoiner(intel_dp, mode->hdisplay, target_clock)) {
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
bigjoiner = true;
max_dotclk *= 2;
}
if (target_clock > max_dotclk)
return MODE_CLOCK_HIGH;
if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
return MODE_H_ILLEGAL;
max_link_clock = intel_dp_max_link_rate(intel_dp);
max_lanes = intel_dp_max_lane_count(intel_dp);
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock,
intel_dp_mode_min_output_bpp(connector, mode));
if (HAS_DSC(dev_priv) &&
drm_dp_sink_supports_dsc(connector->dp.dsc_dpcd)) {
enum intel_output_format sink_format, output_format;
int pipe_bpp;
sink_format = intel_dp_sink_format(connector, mode);
output_format = intel_dp_output_format(connector, sink_format);
/*
* TBD pass the connector BPC,
* for now U8_MAX so that max BPC on that platform would be picked
*/
pipe_bpp = intel_dp_dsc_compute_max_bpp(connector, U8_MAX);
/*
* Output bpp is stored in 6.4 format so right shift by 4 to get the
* integer value since we support only integer values of bpp.
*/
if (intel_dp_is_edp(intel_dp)) {
dsc_max_compressed_bpp =
drm_edp_dsc_sink_output_bpp(connector->dp.dsc_dpcd) >> 4;
dsc_slice_count =
drm_dp_dsc_sink_max_slice_count(connector->dp.dsc_dpcd,
true);
} else if (drm_dp_sink_supports_fec(connector->dp.fec_capability)) {
dsc_max_compressed_bpp =
intel_dp_dsc_get_max_compressed_bpp(dev_priv,
max_link_clock,
max_lanes,
target_clock,
mode->hdisplay,
bigjoiner,
output_format,
pipe_bpp, 64);
dsc_slice_count =
intel_dp_dsc_get_slice_count(connector,
target_clock,
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
mode->hdisplay,
bigjoiner);
}
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
dsc = dsc_max_compressed_bpp && dsc_slice_count;
}
/*
* Big joiner configuration needs DSC for TGL which is not true for
* XE_LPD where uncompressed joiner is supported.
*/
if (DISPLAY_VER(dev_priv) < 13 && bigjoiner && !dsc)
return MODE_CLOCK_HIGH;
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
if (mode_rate > max_rate && !dsc)
return MODE_CLOCK_HIGH;
status = intel_dp_mode_valid_downstream(connector, mode, target_clock);
if (status != MODE_OK)
return status;
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
return intel_mode_valid_max_plane_size(dev_priv, mode, bigjoiner);
}
bool intel_dp_source_supports_tps3(struct drm_i915_private *i915)
{
return DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915) || IS_HASWELL(i915);
}
bool intel_dp_source_supports_tps4(struct drm_i915_private *i915)
{
return DISPLAY_VER(i915) >= 10;
}
static void snprintf_int_array(char *str, size_t len,
const int *array, int nelem)
{
int i;
str[0] = '\0';
for (i = 0; i < nelem; i++) {
int r = snprintf(str, len, "%s%d", i ? ", " : "", array[i]);
if (r >= len)
return;
str += r;
len -= r;
}
}
static void intel_dp_print_rates(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
char str[128]; /* FIXME: too big for stack? */
if (!drm_debug_enabled(DRM_UT_KMS))
return;
snprintf_int_array(str, sizeof(str),
intel_dp->source_rates, intel_dp->num_source_rates);
drm_dbg_kms(&i915->drm, "source rates: %s\n", str);
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
snprintf_int_array(str, sizeof(str),
intel_dp->sink_rates, intel_dp->num_sink_rates);
drm_dbg_kms(&i915->drm, "sink rates: %s\n", str);
snprintf_int_array(str, sizeof(str),
intel_dp->common_rates, intel_dp->num_common_rates);
drm_dbg_kms(&i915->drm, "common rates: %s\n", str);
}
int
intel_dp_max_link_rate(struct intel_dp *intel_dp)
{
int len;
len = intel_dp_common_len_rate_limit(intel_dp, intel_dp->max_link_rate);
return intel_dp_common_rate(intel_dp, len - 1);
}
int intel_dp_rate_select(struct intel_dp *intel_dp, int rate)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int i = intel_dp_rate_index(intel_dp->sink_rates,
intel_dp->num_sink_rates, rate);
if (drm_WARN_ON(&i915->drm, i < 0))
i = 0;
return i;
}
void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock,
u8 *link_bw, u8 *rate_select)
{
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
/* eDP 1.4 rate select method. */
if (intel_dp->use_rate_select) {
*link_bw = 0;
*rate_select =
intel_dp_rate_select(intel_dp, port_clock);
} else {
*link_bw = drm_dp_link_rate_to_bw_code(port_clock);
*rate_select = 0;
}
}
bool intel_dp_has_hdmi_sink(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
return connector->base.display_info.is_hdmi;
}
i915/dp/fec: Add fec_enable to the crtc state. For DP 1.4 and above, Display Stream compression can be enabled only if Forward Error Correctin can be performed. Add a crtc state for FEC. Currently, the state is determined by platform, DP and DSC being enabled. Moving forward we can use the state to have error correction on other scenarios too if needed. v2: - Control compression_enable with the fec_enable parameter in crtc state and with intel_dp_supports_fec() (Ville) - intel_dp_can_fec()/intel_dp_supports_fec()(manasi) v3: Check for FEC support along with setting crtc state. v4: add checks to intel_dp_source_supports_dsc.(manasi) - Move intel_dp_supports_fec() closer to intel_dp_supports_dsc() (Anusha) v5: Move fec check to intel_dp_supports_dsc(Ville) v6: Remove warning. rebase. v7: change crtc state to include DP sink and fec capability of source.(Manasi) v8: Set fec_enable in crtc in intel_dp_compute_config(). v9 (From Manasi): * Combine the !edp and !fec_support check * Derive dev_priv from intel_dp directly v10 (From Manasi): * Rebase Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.comk> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-14-manasi.d.navare@intel.com
2018-11-28 20:26:25 +00:00
static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp,
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
const struct intel_crtc_state *pipe_config)
{
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
if (DISPLAY_VER(dev_priv) >= 12)
return true;
if (DISPLAY_VER(dev_priv) == 11 && encoder->port != PORT_A &&
!intel_crtc_has_type(pipe_config, INTEL_OUTPUT_DP_MST))
return true;
return false;
i915/dp/fec: Add fec_enable to the crtc state. For DP 1.4 and above, Display Stream compression can be enabled only if Forward Error Correctin can be performed. Add a crtc state for FEC. Currently, the state is determined by platform, DP and DSC being enabled. Moving forward we can use the state to have error correction on other scenarios too if needed. v2: - Control compression_enable with the fec_enable parameter in crtc state and with intel_dp_supports_fec() (Ville) - intel_dp_can_fec()/intel_dp_supports_fec()(manasi) v3: Check for FEC support along with setting crtc state. v4: add checks to intel_dp_source_supports_dsc.(manasi) - Move intel_dp_supports_fec() closer to intel_dp_supports_dsc() (Anusha) v5: Move fec check to intel_dp_supports_dsc(Ville) v6: Remove warning. rebase. v7: change crtc state to include DP sink and fec capability of source.(Manasi) v8: Set fec_enable in crtc in intel_dp_compute_config(). v9 (From Manasi): * Combine the !edp and !fec_support check * Derive dev_priv from intel_dp directly v10 (From Manasi): * Rebase Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.comk> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-14-manasi.d.navare@intel.com
2018-11-28 20:26:25 +00:00
}
bool intel_dp_supports_fec(struct intel_dp *intel_dp,
const struct intel_connector *connector,
const struct intel_crtc_state *pipe_config)
i915/dp/fec: Add fec_enable to the crtc state. For DP 1.4 and above, Display Stream compression can be enabled only if Forward Error Correctin can be performed. Add a crtc state for FEC. Currently, the state is determined by platform, DP and DSC being enabled. Moving forward we can use the state to have error correction on other scenarios too if needed. v2: - Control compression_enable with the fec_enable parameter in crtc state and with intel_dp_supports_fec() (Ville) - intel_dp_can_fec()/intel_dp_supports_fec()(manasi) v3: Check for FEC support along with setting crtc state. v4: add checks to intel_dp_source_supports_dsc.(manasi) - Move intel_dp_supports_fec() closer to intel_dp_supports_dsc() (Anusha) v5: Move fec check to intel_dp_supports_dsc(Ville) v6: Remove warning. rebase. v7: change crtc state to include DP sink and fec capability of source.(Manasi) v8: Set fec_enable in crtc in intel_dp_compute_config(). v9 (From Manasi): * Combine the !edp and !fec_support check * Derive dev_priv from intel_dp directly v10 (From Manasi): * Rebase Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.comk> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-14-manasi.d.navare@intel.com
2018-11-28 20:26:25 +00:00
{
return intel_dp_source_supports_fec(intel_dp, pipe_config) &&
drm_dp_sink_supports_fec(connector->dp.fec_capability);
i915/dp/fec: Add fec_enable to the crtc state. For DP 1.4 and above, Display Stream compression can be enabled only if Forward Error Correctin can be performed. Add a crtc state for FEC. Currently, the state is determined by platform, DP and DSC being enabled. Moving forward we can use the state to have error correction on other scenarios too if needed. v2: - Control compression_enable with the fec_enable parameter in crtc state and with intel_dp_supports_fec() (Ville) - intel_dp_can_fec()/intel_dp_supports_fec()(manasi) v3: Check for FEC support along with setting crtc state. v4: add checks to intel_dp_source_supports_dsc.(manasi) - Move intel_dp_supports_fec() closer to intel_dp_supports_dsc() (Anusha) v5: Move fec check to intel_dp_supports_dsc(Ville) v6: Remove warning. rebase. v7: change crtc state to include DP sink and fec capability of source.(Manasi) v8: Set fec_enable in crtc in intel_dp_compute_config(). v9 (From Manasi): * Combine the !edp and !fec_support check * Derive dev_priv from intel_dp directly v10 (From Manasi): * Rebase Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.comk> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-14-manasi.d.navare@intel.com
2018-11-28 20:26:25 +00:00
}
static bool intel_dp_supports_dsc(const struct intel_connector *connector,
const struct intel_crtc_state *crtc_state)
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
{
if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP) && !crtc_state->fec_enable)
i915/dp/fec: Add fec_enable to the crtc state. For DP 1.4 and above, Display Stream compression can be enabled only if Forward Error Correctin can be performed. Add a crtc state for FEC. Currently, the state is determined by platform, DP and DSC being enabled. Moving forward we can use the state to have error correction on other scenarios too if needed. v2: - Control compression_enable with the fec_enable parameter in crtc state and with intel_dp_supports_fec() (Ville) - intel_dp_can_fec()/intel_dp_supports_fec()(manasi) v3: Check for FEC support along with setting crtc state. v4: add checks to intel_dp_source_supports_dsc.(manasi) - Move intel_dp_supports_fec() closer to intel_dp_supports_dsc() (Anusha) v5: Move fec check to intel_dp_supports_dsc(Ville) v6: Remove warning. rebase. v7: change crtc state to include DP sink and fec capability of source.(Manasi) v8: Set fec_enable in crtc in intel_dp_compute_config(). v9 (From Manasi): * Combine the !edp and !fec_support check * Derive dev_priv from intel_dp directly v10 (From Manasi): * Rebase Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.comk> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-14-manasi.d.navare@intel.com
2018-11-28 20:26:25 +00:00
return false;
return intel_dsc_source_support(crtc_state) &&
connector->dp.dsc_decompression_aux &&
drm_dp_sink_supports_dsc(connector->dp.dsc_dpcd);
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
}
static int intel_dp_hdmi_compute_bpc(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
int bpc, bool respect_downstream_limits)
{
int clock = crtc_state->hw.adjusted_mode.crtc_clock;
/*
* Current bpc could already be below 8bpc due to
* FDI bandwidth constraints or other limits.
* HDMI minimum is 8bpc however.
*/
bpc = max(bpc, 8);
/*
* We will never exceed downstream TMDS clock limits while
* attempting deep color. If the user insists on forcing an
* out of spec mode they will have to be satisfied with 8bpc.
*/
if (!respect_downstream_limits)
bpc = 8;
for (; bpc >= 8; bpc -= 2) {
if (intel_hdmi_bpc_possible(crtc_state, bpc,
intel_dp_has_hdmi_sink(intel_dp)) &&
intel_dp_tmds_clock_valid(intel_dp, clock, bpc, crtc_state->sink_format,
respect_downstream_limits) == MODE_OK)
return bpc;
}
return -EINVAL;
}
static int intel_dp_max_bpp(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
bool respect_downstream_limits)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
struct intel_connector *intel_connector = intel_dp->attached_connector;
int bpp, bpc;
bpc = crtc_state->pipe_bpp / 3;
if (intel_dp->dfp.max_bpc)
bpc = min_t(int, bpc, intel_dp->dfp.max_bpc);
if (intel_dp->dfp.min_tmds_clock) {
int max_hdmi_bpc;
max_hdmi_bpc = intel_dp_hdmi_compute_bpc(intel_dp, crtc_state, bpc,
respect_downstream_limits);
if (max_hdmi_bpc < 0)
return 0;
bpc = min(bpc, max_hdmi_bpc);
}
bpp = bpc * 3;
if (intel_dp_is_edp(intel_dp)) {
/* Get bpp from vbt only for panels that dont have bpp in edid */
if (intel_connector->base.display_info.bpc == 0 &&
intel_connector->panel.vbt.edp.bpp &&
intel_connector->panel.vbt.edp.bpp < bpp) {
drm_dbg_kms(&dev_priv->drm,
"clamping bpp for eDP panel to BIOS-provided %i\n",
intel_connector->panel.vbt.edp.bpp);
bpp = intel_connector->panel.vbt.edp.bpp;
}
}
return bpp;
}
/* Adjust link config limits based on compliance test requests. */
void
intel_dp_adjust_compliance_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct link_config_limits *limits)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
/* For DP Compliance we override the computed bpp for the pipe */
if (intel_dp->compliance.test_data.bpc != 0) {
int bpp = 3 * intel_dp->compliance.test_data.bpc;
limits->pipe.min_bpp = limits->pipe.max_bpp = bpp;
pipe_config->dither_force_disable = bpp == 6 * 3;
drm_dbg_kms(&i915->drm, "Setting pipe_bpp to %d\n", bpp);
}
/* Use values requested by Compliance Test Request */
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
int index;
/* Validate the compliance test data since max values
* might have changed due to link train fallback.
*/
if (intel_dp_link_params_valid(intel_dp, intel_dp->compliance.test_link_rate,
intel_dp->compliance.test_lane_count)) {
index = intel_dp_rate_index(intel_dp->common_rates,
intel_dp->num_common_rates,
intel_dp->compliance.test_link_rate);
if (index >= 0)
limits->min_rate = limits->max_rate =
intel_dp->compliance.test_link_rate;
limits->min_lane_count = limits->max_lane_count =
intel_dp->compliance.test_lane_count;
}
}
}
static bool has_seamless_m_n(struct intel_connector *connector)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
/*
* Seamless M/N reprogramming only implemented
* for BDW+ double buffered M/N registers so far.
*/
return HAS_DOUBLE_BUFFERED_M_N(i915) &&
intel_panel_drrs_type(connector) == DRRS_TYPE_SEAMLESS;
}
static int intel_dp_mode_clock(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct intel_connector *connector = to_intel_connector(conn_state->connector);
const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
/* FIXME a bit of a mess wrt clock vs. crtc_clock */
if (has_seamless_m_n(connector))
return intel_panel_highest_mode(connector, adjusted_mode)->clock;
else
return adjusted_mode->crtc_clock;
}
/* Optimize link config in order: max bpp, min clock, min lanes */
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
static int
intel_dp_compute_link_config_wide(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
const struct drm_connector_state *conn_state,
const struct link_config_limits *limits)
{
int bpp, i, lane_count, clock = intel_dp_mode_clock(pipe_config, conn_state);
int mode_rate, link_rate, link_avail;
for (bpp = to_bpp_int(limits->link.max_bpp_x16);
bpp >= to_bpp_int(limits->link.min_bpp_x16);
bpp -= 2 * 3) {
int link_bpp = intel_dp_output_bpp(pipe_config->output_format, bpp);
mode_rate = intel_dp_link_required(clock, link_bpp);
for (i = 0; i < intel_dp->num_common_rates; i++) {
link_rate = intel_dp_common_rate(intel_dp, i);
if (link_rate < limits->min_rate ||
link_rate > limits->max_rate)
continue;
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count;
lane_count <<= 1) {
link_avail = intel_dp_max_data_rate(link_rate,
lane_count);
if (mode_rate <= link_avail) {
pipe_config->lane_count = lane_count;
pipe_config->pipe_bpp = bpp;
pipe_config->port_clock = link_rate;
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return 0;
}
}
}
}
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return -EINVAL;
}
static
u8 intel_dp_dsc_max_src_input_bpc(struct drm_i915_private *i915)
{
/* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
if (DISPLAY_VER(i915) >= 12)
return 12;
if (DISPLAY_VER(i915) == 11)
return 10;
return 0;
}
int intel_dp_dsc_compute_max_bpp(const struct intel_connector *connector,
u8 max_req_bpc)
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
int i, num_bpc;
u8 dsc_bpc[3] = {};
u8 dsc_max_bpc;
dsc_max_bpc = intel_dp_dsc_max_src_input_bpc(i915);
if (!dsc_max_bpc)
return dsc_max_bpc;
dsc_max_bpc = min_t(u8, dsc_max_bpc, max_req_bpc);
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
num_bpc = drm_dp_dsc_sink_supported_input_bpcs(connector->dp.dsc_dpcd,
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
dsc_bpc);
for (i = 0; i < num_bpc; i++) {
if (dsc_max_bpc >= dsc_bpc[i])
return dsc_bpc[i] * 3;
}
return 0;
}
static int intel_dp_source_dsc_version_minor(struct drm_i915_private *i915)
{
return DISPLAY_VER(i915) >= 14 ? 2 : 1;
}
static int intel_dp_sink_dsc_version_minor(const u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
{
return (dsc_dpcd[DP_DSC_REV - DP_DSC_SUPPORT] & DP_DSC_MINOR_MASK) >>
DP_DSC_MINOR_SHIFT;
}
static int intel_dp_get_slice_height(int vactive)
{
int slice_height;
/*
* VDSC 1.2a spec in Section 3.8 Options for Slices implies that 108
* lines is an optimal slice height, but any size can be used as long as
* vertical active integer multiple and maximum vertical slice count
* requirements are met.
*/
for (slice_height = 108; slice_height <= vactive; slice_height += 2)
if (vactive % slice_height == 0)
return slice_height;
/*
* Highly unlikely we reach here as most of the resolutions will end up
* finding appropriate slice_height in above loop but returning
* slice_height as 2 here as it should work with all resolutions.
*/
return 2;
}
static int intel_dp_dsc_compute_params(const struct intel_connector *connector,
struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct drm_dsc_config *vdsc_cfg = &crtc_state->dsc.config;
u8 line_buf_depth;
int ret;
/*
* RC_MODEL_SIZE is currently a constant across all configurations.
*
* FIXME: Look into using sink defined DPCD DP_DSC_RC_BUF_BLK_SIZE and
* DP_DSC_RC_BUF_SIZE for this.
*/
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
vdsc_cfg->pic_height = crtc_state->hw.adjusted_mode.crtc_vdisplay;
vdsc_cfg->slice_height = intel_dp_get_slice_height(vdsc_cfg->pic_height);
ret = intel_dsc_compute_params(crtc_state);
if (ret)
return ret;
vdsc_cfg->dsc_version_major =
(connector->dp.dsc_dpcd[DP_DSC_REV - DP_DSC_SUPPORT] &
DP_DSC_MAJOR_MASK) >> DP_DSC_MAJOR_SHIFT;
vdsc_cfg->dsc_version_minor =
min(intel_dp_source_dsc_version_minor(i915),
intel_dp_sink_dsc_version_minor(connector->dp.dsc_dpcd));
if (vdsc_cfg->convert_rgb)
vdsc_cfg->convert_rgb =
connector->dp.dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] &
DP_DSC_RGB;
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(connector->dp.dsc_dpcd);
if (!line_buf_depth) {
drm_dbg_kms(&i915->drm,
"DSC Sink Line Buffer Depth invalid\n");
return -EINVAL;
}
if (vdsc_cfg->dsc_version_minor == 2)
vdsc_cfg->line_buf_depth = (line_buf_depth == DSC_1_2_MAX_LINEBUF_DEPTH_BITS) ?
DSC_1_2_MAX_LINEBUF_DEPTH_VAL : line_buf_depth;
else
vdsc_cfg->line_buf_depth = (line_buf_depth > DSC_1_1_MAX_LINEBUF_DEPTH_BITS) ?
DSC_1_1_MAX_LINEBUF_DEPTH_BITS : line_buf_depth;
vdsc_cfg->block_pred_enable =
connector->dp.dsc_dpcd[DP_DSC_BLK_PREDICTION_SUPPORT - DP_DSC_SUPPORT] &
DP_DSC_BLK_PREDICTION_IS_SUPPORTED;
return drm_dsc_compute_rc_parameters(vdsc_cfg);
}
static bool intel_dp_dsc_supports_format(const struct intel_connector *connector,
enum intel_output_format output_format)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
u8 sink_dsc_format;
switch (output_format) {
case INTEL_OUTPUT_FORMAT_RGB:
sink_dsc_format = DP_DSC_RGB;
break;
case INTEL_OUTPUT_FORMAT_YCBCR444:
sink_dsc_format = DP_DSC_YCbCr444;
break;
case INTEL_OUTPUT_FORMAT_YCBCR420:
if (min(intel_dp_source_dsc_version_minor(i915),
intel_dp_sink_dsc_version_minor(connector->dp.dsc_dpcd)) < 2)
return false;
sink_dsc_format = DP_DSC_YCbCr420_Native;
break;
default:
return false;
}
return drm_dp_dsc_sink_supports_format(connector->dp.dsc_dpcd, sink_dsc_format);
}
static bool is_bw_sufficient_for_dsc_config(u16 compressed_bppx16, u32 link_clock,
u32 lane_count, u32 mode_clock,
enum intel_output_format output_format,
int timeslots)
{
u32 available_bw, required_bw;
available_bw = (link_clock * lane_count * timeslots * 16) / 8;
required_bw = compressed_bppx16 * (intel_dp_mode_to_fec_clock(mode_clock));
return available_bw > required_bw;
}
static int dsc_compute_link_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct link_config_limits *limits,
u16 compressed_bppx16,
int timeslots)
{
const struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
int link_rate, lane_count;
int i;
for (i = 0; i < intel_dp->num_common_rates; i++) {
link_rate = intel_dp_common_rate(intel_dp, i);
if (link_rate < limits->min_rate || link_rate > limits->max_rate)
continue;
for (lane_count = limits->min_lane_count;
lane_count <= limits->max_lane_count;
lane_count <<= 1) {
if (!is_bw_sufficient_for_dsc_config(compressed_bppx16, link_rate,
lane_count, adjusted_mode->clock,
pipe_config->output_format,
timeslots))
continue;
pipe_config->lane_count = lane_count;
pipe_config->port_clock = link_rate;
return 0;
}
}
return -EINVAL;
}
static
u16 intel_dp_dsc_max_sink_compressed_bppx16(const struct intel_connector *connector,
struct intel_crtc_state *pipe_config,
int bpc)
{
u16 max_bppx16 = drm_edp_dsc_sink_output_bpp(connector->dp.dsc_dpcd);
if (max_bppx16)
return max_bppx16;
/*
* If support not given in DPCD 67h, 68h use the Maximum Allowed bit rate
* values as given in spec Table 2-157 DP v2.0
*/
switch (pipe_config->output_format) {
case INTEL_OUTPUT_FORMAT_RGB:
case INTEL_OUTPUT_FORMAT_YCBCR444:
return (3 * bpc) << 4;
case INTEL_OUTPUT_FORMAT_YCBCR420:
return (3 * (bpc / 2)) << 4;
default:
MISSING_CASE(pipe_config->output_format);
break;
}
return 0;
}
int intel_dp_dsc_sink_min_compressed_bpp(struct intel_crtc_state *pipe_config)
{
/* From Mandatory bit rate range Support Table 2-157 (DP v2.0) */
switch (pipe_config->output_format) {
case INTEL_OUTPUT_FORMAT_RGB:
case INTEL_OUTPUT_FORMAT_YCBCR444:
return 8;
case INTEL_OUTPUT_FORMAT_YCBCR420:
return 6;
default:
MISSING_CASE(pipe_config->output_format);
break;
}
return 0;
}
int intel_dp_dsc_sink_max_compressed_bpp(const struct intel_connector *connector,
struct intel_crtc_state *pipe_config,
int bpc)
{
return intel_dp_dsc_max_sink_compressed_bppx16(connector,
pipe_config, bpc) >> 4;
}
static int dsc_src_min_compressed_bpp(void)
{
/* Min Compressed bpp supported by source is 8 */
return 8;
}
static int dsc_src_max_compressed_bpp(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
/*
* Max Compressed bpp for Gen 13+ is 27bpp.
* For earlier platform is 23bpp. (Bspec:49259).
*/
if (DISPLAY_VER(i915) < 13)
return 23;
else
return 27;
}
/*
* From a list of valid compressed bpps try different compressed bpp and find a
* suitable link configuration that can support it.
*/
static int
icl_dsc_compute_link_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct link_config_limits *limits,
int dsc_max_bpp,
int dsc_min_bpp,
int pipe_bpp,
int timeslots)
{
int i, ret;
/* Compressed BPP should be less than the Input DSC bpp */
dsc_max_bpp = min(dsc_max_bpp, pipe_bpp - 1);
for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp); i++) {
if (valid_dsc_bpp[i] < dsc_min_bpp)
continue;
if (valid_dsc_bpp[i] > dsc_max_bpp)
break;
ret = dsc_compute_link_config(intel_dp,
pipe_config,
limits,
valid_dsc_bpp[i] << 4,
timeslots);
if (ret == 0) {
pipe_config->dsc.compressed_bpp_x16 =
to_bpp_x16(valid_dsc_bpp[i]);
return 0;
}
}
return -EINVAL;
}
/*
* From XE_LPD onwards we supports compression bpps in steps of 1 up to
* uncompressed bpp-1. So we start from max compressed bpp and see if any
* link configuration is able to support that compressed bpp, if not we
* step down and check for lower compressed bpp.
*/
static int
xelpd_dsc_compute_link_config(struct intel_dp *intel_dp,
const struct intel_connector *connector,
struct intel_crtc_state *pipe_config,
struct link_config_limits *limits,
int dsc_max_bpp,
int dsc_min_bpp,
int pipe_bpp,
int timeslots)
{
u8 bppx16_incr = drm_dp_dsc_sink_bpp_incr(connector->dp.dsc_dpcd);
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u16 compressed_bppx16;
u8 bppx16_step;
int ret;
if (DISPLAY_VER(i915) < 14 || bppx16_incr <= 1)
bppx16_step = 16;
else
bppx16_step = 16 / bppx16_incr;
/* Compressed BPP should be less than the Input DSC bpp */
dsc_max_bpp = min(dsc_max_bpp << 4, (pipe_bpp << 4) - bppx16_step);
dsc_min_bpp = dsc_min_bpp << 4;
for (compressed_bppx16 = dsc_max_bpp;
compressed_bppx16 >= dsc_min_bpp;
compressed_bppx16 -= bppx16_step) {
if (intel_dp->force_dsc_fractional_bpp_en &&
!to_bpp_frac(compressed_bppx16))
continue;
ret = dsc_compute_link_config(intel_dp,
pipe_config,
limits,
compressed_bppx16,
timeslots);
if (ret == 0) {
pipe_config->dsc.compressed_bpp_x16 = compressed_bppx16;
if (intel_dp->force_dsc_fractional_bpp_en &&
to_bpp_frac(compressed_bppx16))
drm_dbg_kms(&i915->drm, "Forcing DSC fractional bpp\n");
return 0;
}
}
return -EINVAL;
}
static int dsc_compute_compressed_bpp(struct intel_dp *intel_dp,
const struct intel_connector *connector,
struct intel_crtc_state *pipe_config,
struct link_config_limits *limits,
int pipe_bpp,
int timeslots)
{
const struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int dsc_src_min_bpp, dsc_sink_min_bpp, dsc_min_bpp;
int dsc_src_max_bpp, dsc_sink_max_bpp, dsc_max_bpp;
int dsc_joiner_max_bpp;
dsc_src_min_bpp = dsc_src_min_compressed_bpp();
dsc_sink_min_bpp = intel_dp_dsc_sink_min_compressed_bpp(pipe_config);
dsc_min_bpp = max(dsc_src_min_bpp, dsc_sink_min_bpp);
dsc_min_bpp = max(dsc_min_bpp, to_bpp_int_roundup(limits->link.min_bpp_x16));
dsc_src_max_bpp = dsc_src_max_compressed_bpp(intel_dp);
dsc_sink_max_bpp = intel_dp_dsc_sink_max_compressed_bpp(connector,
pipe_config,
pipe_bpp / 3);
dsc_max_bpp = dsc_sink_max_bpp ? min(dsc_sink_max_bpp, dsc_src_max_bpp) : dsc_src_max_bpp;
dsc_joiner_max_bpp = get_max_compressed_bpp_with_joiner(i915, adjusted_mode->clock,
adjusted_mode->hdisplay,
pipe_config->bigjoiner_pipes);
dsc_max_bpp = min(dsc_max_bpp, dsc_joiner_max_bpp);
dsc_max_bpp = min(dsc_max_bpp, to_bpp_int(limits->link.max_bpp_x16));
if (DISPLAY_VER(i915) >= 13)
return xelpd_dsc_compute_link_config(intel_dp, connector, pipe_config, limits,
dsc_max_bpp, dsc_min_bpp, pipe_bpp, timeslots);
return icl_dsc_compute_link_config(intel_dp, pipe_config, limits,
dsc_max_bpp, dsc_min_bpp, pipe_bpp, timeslots);
}
static
u8 intel_dp_dsc_min_src_input_bpc(struct drm_i915_private *i915)
{
/* Min DSC Input BPC for ICL+ is 8 */
return HAS_DSC(i915) ? 8 : 0;
}
static
bool is_dsc_pipe_bpp_sufficient(struct drm_i915_private *i915,
struct drm_connector_state *conn_state,
struct link_config_limits *limits,
int pipe_bpp)
{
u8 dsc_max_bpc, dsc_min_bpc, dsc_max_pipe_bpp, dsc_min_pipe_bpp;
dsc_max_bpc = min(intel_dp_dsc_max_src_input_bpc(i915), conn_state->max_requested_bpc);
dsc_min_bpc = intel_dp_dsc_min_src_input_bpc(i915);
dsc_max_pipe_bpp = min(dsc_max_bpc * 3, limits->pipe.max_bpp);
dsc_min_pipe_bpp = max(dsc_min_bpc * 3, limits->pipe.min_bpp);
return pipe_bpp >= dsc_min_pipe_bpp &&
pipe_bpp <= dsc_max_pipe_bpp;
}
static
int intel_dp_force_dsc_pipe_bpp(struct intel_dp *intel_dp,
struct drm_connector_state *conn_state,
struct link_config_limits *limits)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int forced_bpp;
if (!intel_dp->force_dsc_bpc)
return 0;
forced_bpp = intel_dp->force_dsc_bpc * 3;
if (is_dsc_pipe_bpp_sufficient(i915, conn_state, limits, forced_bpp)) {
drm_dbg_kms(&i915->drm, "Input DSC BPC forced to %d\n", intel_dp->force_dsc_bpc);
return forced_bpp;
}
drm_dbg_kms(&i915->drm, "Cannot force DSC BPC:%d, due to DSC BPC limits\n",
intel_dp->force_dsc_bpc);
return 0;
}
static int intel_dp_dsc_compute_pipe_bpp(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
struct link_config_limits *limits,
int timeslots)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
const struct intel_connector *connector =
to_intel_connector(conn_state->connector);
u8 max_req_bpc = conn_state->max_requested_bpc;
u8 dsc_max_bpc, dsc_max_bpp;
u8 dsc_min_bpc, dsc_min_bpp;
u8 dsc_bpc[3] = {};
int forced_bpp, pipe_bpp;
int num_bpc, i, ret;
forced_bpp = intel_dp_force_dsc_pipe_bpp(intel_dp, conn_state, limits);
if (forced_bpp) {
ret = dsc_compute_compressed_bpp(intel_dp, connector, pipe_config,
limits, forced_bpp, timeslots);
if (ret == 0) {
pipe_config->pipe_bpp = forced_bpp;
return 0;
}
}
dsc_max_bpc = intel_dp_dsc_max_src_input_bpc(i915);
if (!dsc_max_bpc)
return -EINVAL;
dsc_max_bpc = min_t(u8, dsc_max_bpc, max_req_bpc);
dsc_max_bpp = min(dsc_max_bpc * 3, limits->pipe.max_bpp);
dsc_min_bpc = intel_dp_dsc_min_src_input_bpc(i915);
dsc_min_bpp = max(dsc_min_bpc * 3, limits->pipe.min_bpp);
/*
* Get the maximum DSC bpc that will be supported by any valid
* link configuration and compressed bpp.
*/
num_bpc = drm_dp_dsc_sink_supported_input_bpcs(connector->dp.dsc_dpcd, dsc_bpc);
for (i = 0; i < num_bpc; i++) {
pipe_bpp = dsc_bpc[i] * 3;
if (pipe_bpp < dsc_min_bpp)
break;
if (pipe_bpp > dsc_max_bpp)
continue;
ret = dsc_compute_compressed_bpp(intel_dp, connector, pipe_config,
limits, pipe_bpp, timeslots);
if (ret == 0) {
pipe_config->pipe_bpp = pipe_bpp;
return 0;
}
}
return -EINVAL;
}
static int intel_edp_dsc_compute_pipe_bpp(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
struct link_config_limits *limits)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
int pipe_bpp, forced_bpp;
int dsc_src_min_bpp, dsc_sink_min_bpp, dsc_min_bpp;
int dsc_src_max_bpp, dsc_sink_max_bpp, dsc_max_bpp;
forced_bpp = intel_dp_force_dsc_pipe_bpp(intel_dp, conn_state, limits);
if (forced_bpp) {
pipe_bpp = forced_bpp;
} else {
int max_bpc = min(limits->pipe.max_bpp / 3, (int)conn_state->max_requested_bpc);
/* For eDP use max bpp that can be supported with DSC. */
pipe_bpp = intel_dp_dsc_compute_max_bpp(connector, max_bpc);
if (!is_dsc_pipe_bpp_sufficient(i915, conn_state, limits, pipe_bpp)) {
drm_dbg_kms(&i915->drm,
"Computed BPC is not in DSC BPC limits\n");
return -EINVAL;
}
}
pipe_config->port_clock = limits->max_rate;
pipe_config->lane_count = limits->max_lane_count;
dsc_src_min_bpp = dsc_src_min_compressed_bpp();
dsc_sink_min_bpp = intel_dp_dsc_sink_min_compressed_bpp(pipe_config);
dsc_min_bpp = max(dsc_src_min_bpp, dsc_sink_min_bpp);
dsc_min_bpp = max(dsc_min_bpp, to_bpp_int_roundup(limits->link.min_bpp_x16));
dsc_src_max_bpp = dsc_src_max_compressed_bpp(intel_dp);
dsc_sink_max_bpp = intel_dp_dsc_sink_max_compressed_bpp(connector,
pipe_config,
pipe_bpp / 3);
dsc_max_bpp = dsc_sink_max_bpp ? min(dsc_sink_max_bpp, dsc_src_max_bpp) : dsc_src_max_bpp;
dsc_max_bpp = min(dsc_max_bpp, to_bpp_int(limits->link.max_bpp_x16));
/* Compressed BPP should be less than the Input DSC bpp */
dsc_max_bpp = min(dsc_max_bpp, pipe_bpp - 1);
pipe_config->dsc.compressed_bpp_x16 =
to_bpp_x16(max(dsc_min_bpp, dsc_max_bpp));
pipe_config->pipe_bpp = pipe_bpp;
return 0;
}
int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
struct link_config_limits *limits,
int timeslots,
bool compute_pipe_bpp)
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
const struct intel_connector *connector =
to_intel_connector(conn_state->connector);
const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
int ret;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
pipe_config->fec_enable = pipe_config->fec_enable ||
(!intel_dp_is_edp(intel_dp) &&
intel_dp_supports_fec(intel_dp, connector, pipe_config));
if (!intel_dp_supports_dsc(connector, pipe_config))
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return -EINVAL;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
if (!intel_dp_dsc_supports_format(connector, pipe_config->output_format))
return -EINVAL;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
/*
* compute pipe bpp is set to false for DP MST DSC case
* and compressed_bpp is calculated same time once
* vpci timeslots are allocated, because overall bpp
* calculation procedure is bit different for MST case.
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
*/
if (compute_pipe_bpp) {
if (intel_dp_is_edp(intel_dp))
ret = intel_edp_dsc_compute_pipe_bpp(intel_dp, pipe_config,
conn_state, limits);
else
ret = intel_dp_dsc_compute_pipe_bpp(intel_dp, pipe_config,
conn_state, limits, timeslots);
if (ret) {
drm_dbg_kms(&dev_priv->drm,
"No Valid pipe bpp for given mode ret = %d\n", ret);
return ret;
}
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
}
/* Calculate Slice count */
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
if (intel_dp_is_edp(intel_dp)) {
pipe_config->dsc.slice_count =
drm_dp_dsc_sink_max_slice_count(connector->dp.dsc_dpcd,
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
true);
if (!pipe_config->dsc.slice_count) {
drm_dbg_kms(&dev_priv->drm, "Unsupported Slice Count %d\n",
pipe_config->dsc.slice_count);
return -EINVAL;
}
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
} else {
u8 dsc_dp_slice_count;
dsc_dp_slice_count =
intel_dp_dsc_get_slice_count(connector,
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
adjusted_mode->crtc_clock,
drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid(), v3. Small changes to intel_dp_mode_valid(), allow listing modes that can only be supported in the bigjoiner configuration, which is not supported yet. v13: * Allow bigjoiner if hdisplay >5120 v12: * slice_count logic simplify (Ville) * Fix unnecessary changes in downstream_mode_valid (Ville) v11: * Make intel_dp_can_bigjoiner non static so it can be used in intel_display (Manasi) v10: * Simplify logic (Ville) * Allow bigjoiner on edp (Ville) v9: * Restric Bigjoiner on PORT A (Ville) v8: * use source dotclock for max dotclock (Manasi) v7: * Add can_bigjoiner() helper (Ville) * Pass bigjoiner to plane_size validation (Ville) v6: * Rebase after dp_downstream mode valid changes (Manasi) v5: * Increase max plane width to support 8K with bigjoiner (Maarten) v4: * Rebase (Manasi) Changes since v1: - Disallow bigjoiner on eDP. Changes since v2: - Rename intel_dp_downstream_max_dotclock to intel_dp_max_dotclock, and split off the downstream and source checking to its own function. (Ville) v3: * Rebase (Manasi) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [vsyrjala: * Keep bigjoiner disabled until everything is ready * Appease checkpatch] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-3-manasi.d.navare@intel.com
2020-11-17 19:47:05 +00:00
adjusted_mode->crtc_hdisplay,
pipe_config->bigjoiner_pipes);
if (!dsc_dp_slice_count) {
drm_dbg_kms(&dev_priv->drm,
"Compressed Slice Count not supported\n");
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return -EINVAL;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
}
pipe_config->dsc.slice_count = dsc_dp_slice_count;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
}
/*
* VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
* is greater than the maximum Cdclock and if slice count is even
* then we need to use 2 VDSC instances.
*/
drm/i915: Ensure DSC has enough BW and stays within HW limits We currently have an issue with some BPPs when using DSC. According to the HW team, the reason is that a single VDSC engine instance has some BW limitations that must be accounted for. So, whenever we approach around 90% of the CDCLK, a second VDSC engine has to be used. This always means using two slices. However, in our current code, the amount of slices is calculated independently of whether we need to enable the second VDSC engine or not. This leads to some logical issues when, according to the pixel clock needs, we need to enable the second VDSC engine. But as we calculated previously that we can only use a single slice, we can't do that and fail. So, we need to fix that so that the number of VDSC engines enabled should depend on the number of slices, and the number of slices should also depend on BW requirements. Lastly, we didn't have BPP limitation for ADLP/MTL/DG2 implemented, which says that DSC output BPPs can only be chosen within the range of 8 to 27 (BSpec 49259). All of this applied together allows us to fix existing FIFO underruns, which we have in many DSC tests. v2: - Replace min with clamp_t(Jani Nikula) - Fix commit message(Swati Sharma) - Added "Closes"(Swati Sharma) BSpec: 49259 HSDES: 18027167222 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8231 Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230306080401.22552-1-stanislav.lisovskiy@intel.com
2023-03-06 08:04:01 +00:00
if (pipe_config->bigjoiner_pipes || pipe_config->dsc.slice_count > 1)
pipe_config->dsc.dsc_split = true;
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
ret = intel_dp_dsc_compute_params(connector, pipe_config);
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
if (ret < 0) {
drm_dbg_kms(&dev_priv->drm,
"Cannot compute valid DSC parameters for Input Bpp = %d"
"Compressed BPP = " BPP_X16_FMT "\n",
pipe_config->pipe_bpp,
BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16));
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return ret;
drm/i915/dsc: Define & Compute VESA DSC params This patches does the following: 1. This patch defines all the DSC parameters as per the VESA DSC specification. These are stored in the encoder and used to compute the PPS parameters to be sent to the Sink. 2. Compute all the DSC parameters which are derived from DSC state of intel_crtc_state. 3. Compute all parameters that are VESA DSC specific This computation happens in the atomic check phase during compute_config() to validate if display stream compression can be enabled for the requested mode. v8 (From Manasi): * DEBUG_KMS instead of DRM_ERROR for user triggerable errors (Ville) v7: (From Manasi) * Dont use signed int for rc_range_params (Manasi) * Mask the range_bpg_offset to use only 6 bits * Add SPDX identifier (Chris Wilson) v6 (From Manasi): * Add a check for line_buf_depth return value (Anusha) * Remove DRM DSC constants to different patch (Manasi) v5 (From Manasi): * Add logic to limit the max line buf depth for DSC 1.1 to 13 as per DSC 1.1 spec * Fix dim checkpatch warnings/checks v4 (From Gaurav): * Rebase on latest drm tip * rename variable name(Manasi) * Populate linebuf_depth variable(Manasi) v3 (From Gaurav): * Rebase my previous patches on top of Manasi's latest patch series * Using >>n rather than /2^n (Manasi) * Change the commit message to explain what the patch is doing(Gaurav) Fixed review comments from Ville: * Don't use macro TWOS_COMPLEMENT * Mention in comment about the source of RC params * Return directly from case statements * Using single asssignment for assigning rc_range_params * Using <<n rather than *2^n and removing the comments about the fixed point numbers v2 (From Manasi): * Update logic for minor version to consider the dpcd value and what supported by the HW platform * Use DRM DSC config struct instead of intel_dp struct * Move the DSC constants to DRM DSC header file * Use u16, u8 where bigger data types not needed * * Compute the DSC parameters as part of DSC compute config since the computation can fail (Manasi) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Co-developed-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181129193827.7914-1-manasi.d.navare@intel.com
2018-11-29 19:38:27 +00:00
}
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
pipe_config->dsc.compression_enable = true;
drm_dbg_kms(&dev_priv->drm, "DP DSC computed with Input Bpp = %d "
"Compressed Bpp = " BPP_X16_FMT " Slice Count = %d\n",
pipe_config->pipe_bpp,
BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16),
pipe_config->dsc.slice_count);
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return 0;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
}
/**
* intel_dp_compute_config_link_bpp_limits - compute output link bpp limits
* @intel_dp: intel DP
* @crtc_state: crtc state
* @dsc: DSC compression mode
* @limits: link configuration limits
*
* Calculates the output link min, max bpp values in @limits based on the
* pipe bpp range, @crtc_state and @dsc mode.
*
* Returns %true in case of success.
*/
bool
intel_dp_compute_config_link_bpp_limits(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
bool dsc,
struct link_config_limits *limits)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
const struct drm_display_mode *adjusted_mode =
&crtc_state->hw.adjusted_mode;
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
const struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
int max_link_bpp_x16;
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
2023-09-21 19:51:58 +00:00
max_link_bpp_x16 = min(crtc_state->max_link_bpp_x16,
to_bpp_x16(limits->pipe.max_bpp));
if (!dsc) {
max_link_bpp_x16 = rounddown(max_link_bpp_x16, to_bpp_x16(2 * 3));
if (max_link_bpp_x16 < to_bpp_x16(limits->pipe.min_bpp))
return false;
limits->link.min_bpp_x16 = to_bpp_x16(limits->pipe.min_bpp);
} else {
/*
* TODO: set the DSC link limits already here, atm these are
* initialized only later in intel_edp_dsc_compute_pipe_bpp() /
* intel_dp_dsc_compute_pipe_bpp()
*/
limits->link.min_bpp_x16 = 0;
}
limits->link.max_bpp_x16 = max_link_bpp_x16;
drm_dbg_kms(&i915->drm,
"[ENCODER:%d:%s][CRTC:%d:%s] DP link limits: pixel clock %d kHz DSC %s max lanes %d max rate %d max pipe_bpp %d max link_bpp " BPP_X16_FMT "\n",
encoder->base.base.id, encoder->base.name,
crtc->base.base.id, crtc->base.name,
adjusted_mode->crtc_clock,
dsc ? "on" : "off",
limits->max_lane_count,
limits->max_rate,
limits->pipe.max_bpp,
BPP_X16_ARGS(limits->link.max_bpp_x16));
return true;
}
static bool
intel_dp_compute_config_limits(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
bool respect_downstream_limits,
bool dsc,
struct link_config_limits *limits)
{
limits->min_rate = intel_dp_common_rate(intel_dp, 0);
limits->max_rate = intel_dp_max_link_rate(intel_dp);
/* FIXME 128b/132b SST support missing */
limits->max_rate = min(limits->max_rate, 810000);
limits->min_lane_count = 1;
limits->max_lane_count = intel_dp_max_lane_count(intel_dp);
limits->pipe.min_bpp = intel_dp_min_bpp(crtc_state->output_format);
limits->pipe.max_bpp = intel_dp_max_bpp(intel_dp, crtc_state,
respect_downstream_limits);
drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Some new eDP panels don't like to operate at the max parameters, and instead we need to go for an optimal confiugration. That unfortunately doesn't work with older eDP panels which are generally only guaranteed to work at the max parameters. To solve these two conflicting requirements let's start with the optimal setup, and if that fails we start again with the max parameters. The downside is probably an extra modeset when we switch strategies but I don't see a good way to avoid that. For a bit of history we first tried to go for the fast+narrow in commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow"). but that had to be reverted due to regression on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"). So now we try to get the best of both worlds by using both strategies. v2: Deal with output_bpp and uapi vs. hw state split Reword some comments v3: Rebase Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267 References: https://bugs.freedesktop.org/show_bug.cgi?id=109959 References: https://gitlab.freedesktop.org/drm/intel/issues/272 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
2021-01-07 18:20:25 +00:00
if (intel_dp->use_max_params) {
/*
* Use the maximum clock and number of lanes the eDP panel
drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Some new eDP panels don't like to operate at the max parameters, and instead we need to go for an optimal confiugration. That unfortunately doesn't work with older eDP panels which are generally only guaranteed to work at the max parameters. To solve these two conflicting requirements let's start with the optimal setup, and if that fails we start again with the max parameters. The downside is probably an extra modeset when we switch strategies but I don't see a good way to avoid that. For a bit of history we first tried to go for the fast+narrow in commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow"). but that had to be reverted due to regression on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"). So now we try to get the best of both worlds by using both strategies. v2: Deal with output_bpp and uapi vs. hw state split Reword some comments v3: Rebase Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267 References: https://bugs.freedesktop.org/show_bug.cgi?id=109959 References: https://gitlab.freedesktop.org/drm/intel/issues/272 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
2021-01-07 18:20:25 +00:00
* advertizes being capable of in case the initial fast
* optimal params failed us. The panels are generally
* designed to support only a single clock and lane
drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure Some new eDP panels don't like to operate at the max parameters, and instead we need to go for an optimal confiugration. That unfortunately doesn't work with older eDP panels which are generally only guaranteed to work at the max parameters. To solve these two conflicting requirements let's start with the optimal setup, and if that fails we start again with the max parameters. The downside is probably an extra modeset when we switch strategies but I don't see a good way to avoid that. For a bit of history we first tried to go for the fast+narrow in commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow"). but that had to be reverted due to regression on older panels in commit f11cb1c19ad0 ("drm/i915/dp: revert back to max link rate and lane count on eDP"). So now we try to get the best of both worlds by using both strategies. v2: Deal with output_bpp and uapi vs. hw state split Reword some comments v3: Rebase Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Albert Astals Cid <aacid@kde.org> # v5.0 backport Cc: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport Cc: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=105267 References: https://bugs.freedesktop.org/show_bug.cgi?id=109959 References: https://gitlab.freedesktop.org/drm/intel/issues/272 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210107182026.24848-1-ville.syrjala@linux.intel.com
2021-01-07 18:20:25 +00:00
* configuration, and typically on older panels these
* values correspond to the native resolution of the panel.
*/
limits->min_lane_count = limits->max_lane_count;
limits->min_rate = limits->max_rate;
}
intel_dp_adjust_compliance_config(intel_dp, crtc_state, limits);
return intel_dp_compute_config_link_bpp_limits(intel_dp,
crtc_state,
dsc,
limits);
}
static int
intel_dp_compute_link_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state,
bool respect_downstream_limits)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
const struct intel_connector *connector =
to_intel_connector(conn_state->connector);
const struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct link_config_limits limits;
bool joiner_needs_dsc = false;
bool dsc_needed;
int ret = 0;
if (pipe_config->fec_enable &&
!intel_dp_supports_fec(intel_dp, connector, pipe_config))
return -EINVAL;
if (intel_dp_need_bigjoiner(intel_dp, adjusted_mode->crtc_hdisplay,
adjusted_mode->crtc_clock))
pipe_config->bigjoiner_pipes = GENMASK(crtc->pipe + 1, crtc->pipe);
/*
* Pipe joiner needs compression up to display 12 due to bandwidth
* limitation. DG2 onwards pipe joiner can be enabled without
* compression.
*/
joiner_needs_dsc = DISPLAY_VER(i915) < 13 && pipe_config->bigjoiner_pipes;
dsc_needed = joiner_needs_dsc || intel_dp->force_dsc_en ||
!intel_dp_compute_config_limits(intel_dp, pipe_config,
respect_downstream_limits,
false,
&limits);
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
if (!dsc_needed) {
/*
* Optimize for slow and wide for everything, because there are some
* eDP 1.3 and 1.4 panels don't work well with fast and narrow.
*/
ret = intel_dp_compute_link_config_wide(intel_dp, pipe_config,
conn_state, &limits);
if (ret)
dsc_needed = true;
}
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
if (dsc_needed) {
drm_dbg_kms(&i915->drm, "Try DSC (fallback=%s, joiner=%s, force=%s)\n",
str_yes_no(ret), str_yes_no(joiner_needs_dsc),
str_yes_no(intel_dp->force_dsc_en));
if (!intel_dp_compute_config_limits(intel_dp, pipe_config,
respect_downstream_limits,
true,
&limits))
return -EINVAL;
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
conn_state, &limits, 64, true);
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
if (ret < 0)
return ret;
drm/i915/dp: optimize eDP 1.4+ link config fast and narrow We've opted to use the maximum link rate and lane count for eDP panels, because typically the maximum supported configuration reported by the panel has matched the native resolution requirements of the panel, and optimizing the link has lead to problems. With eDP 1.4 rate select method and DSC features, this is decreasingly the case. There's a need to optimize the link parameters. Moreover, already eDP 1.3 states fast link with fewer lanes is preferred over the wide and slow. (Wide and slow should still be more reliable for longer cable lengths.) Additionally, there have been reports of panels failing on arbitrary link configurations, although arguably all configurations they claim to support should work. Optimize eDP 1.4+ link config fast and narrow. Side note: The implementation has a near duplicate of the link config function, with just the two inner for loops turned inside out. Perhaps there'd be a way to make this, say, more table driven to reduce the duplication, but seems like that would lead to duplication in the table generation. We'll also have to see how the link config optimization for DSC turns out. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: "Lee, Shawn C" <shawn.c.lee@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105267 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905095321.13843-1-jani.nikula@intel.com
2018-09-05 09:53:21 +00:00
}
if (pipe_config->dsc.compression_enable) {
drm_dbg_kms(&i915->drm,
"DP lane count %d clock %d Input bpp %d Compressed bpp " BPP_X16_FMT "\n",
pipe_config->lane_count, pipe_config->port_clock,
pipe_config->pipe_bpp,
BPP_X16_ARGS(pipe_config->dsc.compressed_bpp_x16));
drm_dbg_kms(&i915->drm,
"DP link rate required %i available %i\n",
intel_dp_link_required(adjusted_mode->crtc_clock,
to_bpp_int_roundup(pipe_config->dsc.compressed_bpp_x16)),
intel_dp_max_data_rate(pipe_config->port_clock,
pipe_config->lane_count));
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
} else {
drm_dbg_kms(&i915->drm, "DP lane count %d clock %d bpp %d\n",
pipe_config->lane_count, pipe_config->port_clock,
pipe_config->pipe_bpp);
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
drm_dbg_kms(&i915->drm,
"DP link rate required %i available %i\n",
intel_dp_link_required(adjusted_mode->crtc_clock,
pipe_config->pipe_bpp),
intel_dp_max_data_rate(pipe_config->port_clock,
pipe_config->lane_count));
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
}
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return 0;
}
bool intel_dp_limited_color_range(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
const struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(conn_state);
const struct drm_display_mode *adjusted_mode =
&crtc_state->hw.adjusted_mode;
/*
* Our YCbCr output is always limited range.
* crtc_state->limited_color_range only applies to RGB,
* and it must never be set for YCbCr or we risk setting
* some conflicting bits in TRANSCONF which will mess up
* the colors on the monitor.
*/
if (crtc_state->output_format != INTEL_OUTPUT_FORMAT_RGB)
return false;
if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) {
/*
* See:
* CEA-861-E - 5.1 Default Encoding Parameters
* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
*/
return crtc_state->pipe_bpp != 18 &&
drm_default_rgb_quant_range(adjusted_mode) ==
HDMI_QUANTIZATION_RANGE_LIMITED;
} else {
return intel_conn_state->broadcast_rgb ==
INTEL_BROADCAST_RGB_LIMITED;
}
}
static bool intel_dp_port_has_audio(struct drm_i915_private *dev_priv,
enum port port)
{
if (IS_G4X(dev_priv))
return false;
if (DISPLAY_VER(dev_priv) < 12 && port == PORT_A)
return false;
return true;
}
static void intel_dp_compute_vsc_colorimetry(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state,
struct drm_dp_vsc_sdp *vsc)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
drm/i915/panelreplay: Initializaton and compute config for panel replay Modify existing PSR implementation to enable panel replay feature of DP 2.0 which is similar to PSR feature of EDP panel. There is different DPCD address to check panel capability compare to PSR and vsc sdp header is different. v1: Initial version. v2: - Set source_panel_replay_support flag under HAS_PANEL_REPLAY() condition check. [Jouni] - Code restructured around intel_panel_replay_init and renamed to intel_panel_replay_init_dpcd. [Jouni] - Remove the initial code modification around has_psr2 flag. [Jouni] - Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to enable in intel_psr_post_plane_update. [Jouni] v3: - Initialize both psr and panel-replay. [Jouni] - Initialize both panel replay and psr if detected. [Jouni] - Refactoring psr function by introducing _psr_compute_config(). [Jouni] - Add check for !is_edp while deriving source_panel_replay_support. [Jouni] - Enable panel replay dpcd initialization in a separate patch. [Jouni] v4: - HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni] - Set either panel replay source support or psr. [Jouni] v5: - HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni] - Move psr related code to intel_psr.c. [Jani] - Reset sink_panel_replay_support flag during disconnection. [Jani] v6: return statement restored which is removed by misatke. [Jouni] v7: cosmetic changes. [Arun] Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108072303.3414118-4-animesh.manna@intel.com
2023-11-08 07:23:00 +00:00
if (crtc_state->has_panel_replay) {
/*
* Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
* VSC SDP supporting 3D stereo, Panel Replay, and Pixel
* Encoding/Colorimetry Format indication.
*/
vsc->revision = 0x7;
} else {
/*
* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
* VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
* Colorimetry Format indication.
*/
vsc->revision = 0x5;
}
vsc->length = 0x13;
/* DP 1.4a spec, Table 2-120 */
switch (crtc_state->output_format) {
case INTEL_OUTPUT_FORMAT_YCBCR444:
vsc->pixelformat = DP_PIXELFORMAT_YUV444;
break;
case INTEL_OUTPUT_FORMAT_YCBCR420:
vsc->pixelformat = DP_PIXELFORMAT_YUV420;
break;
case INTEL_OUTPUT_FORMAT_RGB:
default:
vsc->pixelformat = DP_PIXELFORMAT_RGB;
}
switch (conn_state->colorspace) {
case DRM_MODE_COLORIMETRY_BT709_YCC:
vsc->colorimetry = DP_COLORIMETRY_BT709_YCC;
break;
case DRM_MODE_COLORIMETRY_XVYCC_601:
vsc->colorimetry = DP_COLORIMETRY_XVYCC_601;
break;
case DRM_MODE_COLORIMETRY_XVYCC_709:
vsc->colorimetry = DP_COLORIMETRY_XVYCC_709;
break;
case DRM_MODE_COLORIMETRY_SYCC_601:
vsc->colorimetry = DP_COLORIMETRY_SYCC_601;
break;
case DRM_MODE_COLORIMETRY_OPYCC_601:
vsc->colorimetry = DP_COLORIMETRY_OPYCC_601;
break;
case DRM_MODE_COLORIMETRY_BT2020_CYCC:
vsc->colorimetry = DP_COLORIMETRY_BT2020_CYCC;
break;
case DRM_MODE_COLORIMETRY_BT2020_RGB:
vsc->colorimetry = DP_COLORIMETRY_BT2020_RGB;
break;
case DRM_MODE_COLORIMETRY_BT2020_YCC:
vsc->colorimetry = DP_COLORIMETRY_BT2020_YCC;
break;
case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
vsc->colorimetry = DP_COLORIMETRY_DCI_P3_RGB;
break;
default:
/*
* RGB->YCBCR color conversion uses the BT.709
* color space.
*/
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
vsc->colorimetry = DP_COLORIMETRY_BT709_YCC;
else
vsc->colorimetry = DP_COLORIMETRY_DEFAULT;
break;
}
vsc->bpc = crtc_state->pipe_bpp / 3;
/* only RGB pixelformat supports 6 bpc */
drm_WARN_ON(&dev_priv->drm,
vsc->bpc == 6 && vsc->pixelformat != DP_PIXELFORMAT_RGB);
/* all YCbCr are always limited range */
vsc->dynamic_range = DP_DYNAMIC_RANGE_CTA;
vsc->content_type = DP_CONTENT_TYPE_NOT_DEFINED;
}
static void intel_dp_compute_vsc_sdp(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct drm_dp_vsc_sdp *vsc = &crtc_state->infoframes.vsc;
/* When a crtc state has PSR, VSC SDP will be handled by PSR routine */
if (crtc_state->has_psr)
return;
if (!intel_dp_needs_vsc_sdp(crtc_state, conn_state))
return;
crtc_state->infoframes.enable |= intel_hdmi_infoframe_enable(DP_SDP_VSC);
vsc->sdp_type = DP_SDP_VSC;
intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
&crtc_state->infoframes.vsc);
}
void intel_dp_compute_psr_vsc_sdp(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state,
struct drm_dp_vsc_sdp *vsc)
{
vsc->sdp_type = DP_SDP_VSC;
if (crtc_state->has_psr2) {
drm/i915/display: Support PSR Multiple Instances It is a preliminary work for supporting multiple EDP PSR and DP PanelReplay. And it refactors singleton PSR to Multi Transcoder supportable PSR. And this moves and renames the i915_psr structure of drm_i915_private's to intel_dp's intel_psr structure. It also causes changes in PSR interrupt handling routine for supporting multiple transcoders. But it does not change the scenario and timing of enabling and disabling PSR. And it not support multiple pipes with a single transcoder PSR case yet. v2: Fix indentation and add comments v3: Remove Blank line v4: Rebased v5: Rebased and Addressed Anshuman's review comment. - Move calling of intel_psr_init() to intel_dp_init_connector() v6: Address Anshuman's review comments - Remove wrong comments and add comments for a limit of supporting of a single pipe PSR v7: Update intel_psr_compute_config() for supporting multiple transcoder PSR on BDW+ v8: Address Anshuman's review comments - Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn() v9: Fix commit message v10: Rebased v11: Address Jose's review comment. - Reorder calling order of intel_psr2_program_trans_man_trk_ctl(). - In order to reduce changes keep the old name for drm_i915_private. - Change restrictions of multiple instances of PSR. v12: Address Jose's review comment. - Change the calling of intel_psr2_program_trans_man_trk_ctl() into commit_pipe_config(). - Change a checking order of CAN_PSR() and connector_status to original on i915_psr_sink_status_show(). - Drop unneeded intel_dp_update_pipe() function. - In order to wait a specific encoder which belong to crtc_state on intel_psr_wait_for_idle(), add checking of encoder. - Add an whitespace to comments. v13: Rebased and Address Jose's review comment. - Add and use for_each_intel_psr_enabled_encoder() macro. - In order to use correct frontbuffer_bit for each pipe, fix intel_psr_invalidate() and intel_psr_flush(). - Remove redundant or unneeded codes. - Update comments. v14: Address Jose's review comment - Add and use for_each_intel_encoder_can_psr() macro and for_each_intel_encoder_mask_can_psr() macro. - Add source_support member variable into intel_psr structure. - Update CAN_PSR() macro that checks source_support. - Move encoder's PSR availity check to psr_init() from psr_compute_config(). - Remove redundant or unneeded codes. v15: Remove wrong mutex lock/unlock of PSR from intel_psr2_program_trans_man_trk_ctl() Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204134015.419036-1-gwan-gyeong.mun@intel.com
2021-02-04 13:40:14 +00:00
if (intel_dp->psr.colorimetry_support &&
intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
/* [PSR2, +Colorimetry] */
intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
vsc);
} else {
/*
* [PSR2, -Colorimetry]
* Prepare VSC Header for SU as per eDP 1.4 spec, Table 6-11
* 3D stereo + PSR/PSR2 + Y-coordinate.
*/
vsc->revision = 0x4;
vsc->length = 0xe;
}
drm/i915/panelreplay: Initializaton and compute config for panel replay Modify existing PSR implementation to enable panel replay feature of DP 2.0 which is similar to PSR feature of EDP panel. There is different DPCD address to check panel capability compare to PSR and vsc sdp header is different. v1: Initial version. v2: - Set source_panel_replay_support flag under HAS_PANEL_REPLAY() condition check. [Jouni] - Code restructured around intel_panel_replay_init and renamed to intel_panel_replay_init_dpcd. [Jouni] - Remove the initial code modification around has_psr2 flag. [Jouni] - Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to enable in intel_psr_post_plane_update. [Jouni] v3: - Initialize both psr and panel-replay. [Jouni] - Initialize both panel replay and psr if detected. [Jouni] - Refactoring psr function by introducing _psr_compute_config(). [Jouni] - Add check for !is_edp while deriving source_panel_replay_support. [Jouni] - Enable panel replay dpcd initialization in a separate patch. [Jouni] v4: - HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni] - Set either panel replay source support or psr. [Jouni] v5: - HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni] - Move psr related code to intel_psr.c. [Jani] - Reset sink_panel_replay_support flag during disconnection. [Jani] v6: return statement restored which is removed by misatke. [Jouni] v7: cosmetic changes. [Arun] Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108072303.3414118-4-animesh.manna@intel.com
2023-11-08 07:23:00 +00:00
} else if (crtc_state->has_panel_replay) {
if (intel_dp->psr.colorimetry_support &&
intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
/* [Panel Replay with colorimetry info] */
intel_dp_compute_vsc_colorimetry(crtc_state, conn_state,
vsc);
} else {
/*
* [Panel Replay without colorimetry info]
* Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
* VSC SDP supporting 3D stereo + Panel Replay.
*/
vsc->revision = 0x6;
vsc->length = 0x10;
}
} else {
/*
* [PSR1]
* Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
* VSC SDP supporting 3D stereo + PSR (applies to eDP v1.3 or
* higher).
*/
vsc->revision = 0x2;
vsc->length = 0x8;
}
}
static void
intel_dp_compute_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
int ret;
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
struct hdmi_drm_infoframe *drm_infoframe = &crtc_state->infoframes.drm.drm;
if (!conn_state->hdr_output_metadata)
return;
ret = drm_hdmi_infoframe_set_hdr_metadata(drm_infoframe, conn_state);
if (ret) {
drm_dbg_kms(&dev_priv->drm, "couldn't set HDR metadata in infoframe\n");
return;
}
crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(HDMI_PACKET_TYPE_GAMUT_METADATA);
}
static bool cpu_transcoder_has_drrs(struct drm_i915_private *i915,
enum transcoder cpu_transcoder)
{
if (HAS_DOUBLE_BUFFERED_M_N(i915))
return true;
return intel_cpu_transcoder_has_m2_n2(i915, cpu_transcoder);
}
static bool can_enable_drrs(struct intel_connector *connector,
const struct intel_crtc_state *pipe_config,
const struct drm_display_mode *downclock_mode)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
if (pipe_config->vrr.enable)
return false;
/*
* DRRS and PSR can't be enable together, so giving preference to PSR
* as it allows more power-savings by complete shutting down display,
* so to guarantee this, intel_drrs_compute_config() must be called
* after intel_psr_compute_config().
*/
if (pipe_config->has_psr)
return false;
/* FIXME missing FDI M2/N2 etc. */
if (pipe_config->has_pch_encoder)
return false;
if (!cpu_transcoder_has_drrs(i915, pipe_config->cpu_transcoder))
return false;
return downclock_mode &&
intel_panel_drrs_type(connector) == DRRS_TYPE_SEAMLESS;
}
static void
intel_dp_drrs_compute_config(struct intel_connector *connector,
struct intel_crtc_state *pipe_config,
int link_bpp_x16)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
const struct drm_display_mode *downclock_mode =
intel_panel_downclock_mode(connector, &pipe_config->hw.adjusted_mode);
int pixel_clock;
/*
* FIXME all joined pipes share the same transcoder.
* Need to account for that when updating M/N live.
*/
if (has_seamless_m_n(connector) && !pipe_config->bigjoiner_pipes)
pipe_config->update_m_n = true;
if (!can_enable_drrs(connector, pipe_config, downclock_mode)) {
if (intel_cpu_transcoder_has_m2_n2(i915, pipe_config->cpu_transcoder))
intel_zero_m_n(&pipe_config->dp_m2_n2);
return;
}
if (IS_IRONLAKE(i915) || IS_SANDYBRIDGE(i915) || IS_IVYBRIDGE(i915))
pipe_config->msa_timing_delay = connector->panel.vbt.edp.drrs_msa_timing_delay;
pipe_config->has_drrs = true;
pixel_clock = downclock_mode->clock;
if (pipe_config->splitter.enable)
pixel_clock /= pipe_config->splitter.link_count;
intel_link_compute_m_n(link_bpp_x16, pipe_config->lane_count, pixel_clock,
pipe_config->port_clock,
intel_dp_bw_fec_overhead(pipe_config->fec_enable),
&pipe_config->dp_m2_n2);
/* FIXME: abstract this better */
if (pipe_config->splitter.enable)
pipe_config->dp_m2_n2.data_m *= pipe_config->splitter.link_count;
}
static bool intel_dp_has_audio(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
const struct intel_digital_connector_state *intel_conn_state =
to_intel_digital_connector_state(conn_state);
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST) &&
!intel_dp_port_has_audio(i915, encoder->port))
return false;
if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
return connector->base.display_info.has_audio;
else
return intel_conn_state->force_audio == HDMI_AUDIO_ON;
}
static int
intel_dp_compute_output_format(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
struct drm_connector_state *conn_state,
bool respect_downstream_limits)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_connector *connector = intel_dp->attached_connector;
const struct drm_display_info *info = &connector->base.display_info;
const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
bool ycbcr_420_only;
int ret;
ycbcr_420_only = drm_mode_is_420_only(info, adjusted_mode);
2023-04-27 12:56:00 +00:00
if (ycbcr_420_only && !connector->base.ycbcr_420_allowed) {
drm_dbg_kms(&i915->drm,
"YCbCr 4:2:0 mode but YCbCr 4:2:0 output not possible. Falling back to RGB.\n");
2023-04-27 12:56:00 +00:00
crtc_state->sink_format = INTEL_OUTPUT_FORMAT_RGB;
} else {
crtc_state->sink_format = intel_dp_sink_format(connector, adjusted_mode);
}
2023-04-27 12:56:00 +00:00
crtc_state->output_format = intel_dp_output_format(connector, crtc_state->sink_format);
ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
respect_downstream_limits);
if (ret) {
2023-04-27 12:56:00 +00:00
if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
!connector->base.ycbcr_420_allowed ||
!drm_mode_is_420_also(info, adjusted_mode))
return ret;
2023-04-27 12:56:00 +00:00
crtc_state->sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
crtc_state->output_format = intel_dp_output_format(connector,
crtc_state->sink_format);
ret = intel_dp_compute_link_config(encoder, crtc_state, conn_state,
respect_downstream_limits);
}
return ret;
}
void
intel_dp_audio_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
pipe_config->has_audio =
intel_dp_has_audio(encoder, pipe_config, conn_state) &&
intel_audio_compute_config(encoder, pipe_config, conn_state);
pipe_config->sdp_split_enable = pipe_config->has_audio &&
intel_dp_is_uhbr(pipe_config);
}
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
int
intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode;
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
const struct drm_display_mode *fixed_mode;
struct intel_connector *connector = intel_dp->attached_connector;
int ret = 0, link_bpp_x16;
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && encoder->port != PORT_A)
pipe_config->has_pch_encoder = true;
fixed_mode = intel_panel_fixed_mode(connector, adjusted_mode);
if (intel_dp_is_edp(intel_dp) && fixed_mode) {
ret = intel_panel_compute_config(connector, adjusted_mode);
if (ret)
return ret;
}
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return -EINVAL;
if (!connector->base.interlace_allowed &&
adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return -EINVAL;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return -EINVAL;
if (intel_dp_hdisplay_bad(dev_priv, adjusted_mode->crtc_hdisplay))
return -EINVAL;
/*
* Try to respect downstream TMDS clock limits first, if
* that fails assume the user might know something we don't.
*/
ret = intel_dp_compute_output_format(encoder, pipe_config, conn_state, true);
if (ret)
ret = intel_dp_compute_output_format(encoder, pipe_config, conn_state, false);
if (ret)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return ret;
if ((intel_dp_is_edp(intel_dp) && fixed_mode) ||
pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
ret = intel_panel_fitting(pipe_config, conn_state);
if (ret)
return ret;
}
pipe_config->limited_color_range =
intel_dp_limited_color_range(pipe_config, conn_state);
pipe_config->enhanced_framing =
drm_dp_enhanced_frame_cap(intel_dp->dpcd);
if (pipe_config->dsc.compression_enable)
link_bpp_x16 = pipe_config->dsc.compressed_bpp_x16;
drm/i915/dp: Compute DSC pipe config in atomic check DSC params like the enable, compressed bpp, slice count and dsc_split are added to the intel_crtc_state. These parameters are set based on the requested mode and available link parameters during the pipe configuration in atomic check phase. These values are then later used to populate the remaining DSC and RC parameters before enbaling DSC in atomic commit. v15: * Rebase over drm-tip v14: Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville) v13: * Compute DSC bpc only when DSC is req to be enabled (Ville) v12: * Override bpp with dsc dpcd color depth (Manasi) v11: * Const crtc_state, reject DSC on DP without FEC (Ville) * Dont set dsc_split to false (Ville) v10: * Add a helper for dp_dsc support (Ville) * Set pipe_config to max bpp, link params for DSC for now (Ville) * Compute bpp - use dp dsc support helper (Ville) v9: * Rebase on top of drm-tip that now uses fast_narrow config for edp (Manasi) v8: * Check for DSC bpc not 0 (manasi) v7: * Fix indentation in compute_m_n (Manasi) v6 (From Gaurav): * Remove function call of intel_dp_compute_dsc_params() and invoke intel_dp_compute_dsc_params() in the patch where it is defined to fix compilation warning (Gaurav) v5: Add drm_dsc_cfg in intel_crtc_state (Manasi) v4: * Rebase on refactoring of intel_dp_compute_config on tip (Manasi) * Add a comment why we need to check PSR while enabling DSC (Gaurav) v3: * Check PPR > max_cdclock to use 2 VDSC instances (Ville) v2: * Add if-else for eDP/DP (Gaurav) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Gaurav K Singh <gaurav.k.singh@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com
2018-11-28 21:36:21 +00:00
else
link_bpp_x16 = to_bpp_x16(intel_dp_output_bpp(pipe_config->output_format,
pipe_config->pipe_bpp));
if (intel_dp->mso_link_count) {
int n = intel_dp->mso_link_count;
int overlap = intel_dp->mso_pixel_overlap;
pipe_config->splitter.enable = true;
pipe_config->splitter.link_count = n;
pipe_config->splitter.pixel_overlap = overlap;
drm_dbg_kms(&dev_priv->drm, "MSO link count %d, pixel overlap %d\n",
n, overlap);
adjusted_mode->crtc_hdisplay = adjusted_mode->crtc_hdisplay / n + overlap;
adjusted_mode->crtc_hblank_start = adjusted_mode->crtc_hblank_start / n + overlap;
adjusted_mode->crtc_hblank_end = adjusted_mode->crtc_hblank_end / n + overlap;
adjusted_mode->crtc_hsync_start = adjusted_mode->crtc_hsync_start / n + overlap;
adjusted_mode->crtc_hsync_end = adjusted_mode->crtc_hsync_end / n + overlap;
adjusted_mode->crtc_htotal = adjusted_mode->crtc_htotal / n + overlap;
adjusted_mode->crtc_clock /= n;
}
intel_dp_audio_compute_config(encoder, pipe_config, conn_state);
intel_link_compute_m_n(link_bpp_x16,
pipe_config->lane_count,
adjusted_mode->crtc_clock,
pipe_config->port_clock,
intel_dp_bw_fec_overhead(pipe_config->fec_enable),
&pipe_config->dp_m_n);
/* FIXME: abstract this better */
if (pipe_config->splitter.enable)
pipe_config->dp_m_n.data_m *= pipe_config->splitter.link_count;
if (!HAS_DDI(dev_priv))
g4x_dp_set_clock(encoder, pipe_config);
intel_vrr_compute_config(pipe_config, conn_state);
intel_psr_compute_config(intel_dp, pipe_config, conn_state);
intel_dp_drrs_compute_config(connector, pipe_config, link_bpp_x16);
intel_dp_compute_vsc_sdp(intel_dp, pipe_config, conn_state);
intel_dp_compute_hdr_metadata_infoframe_sdp(intel_dp, pipe_config, conn_state);
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-15 20:08:00 +00:00
return 0;
}
void intel_dp_set_link_params(struct intel_dp *intel_dp,
int link_rate, int lane_count)
{
memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp->link_trained = false;
intel_dp->link_rate = link_rate;
intel_dp->lane_count = lane_count;
}
static void intel_dp_reset_max_link_params(struct intel_dp *intel_dp)
{
intel_dp->max_link_lane_count = intel_dp_max_common_lane_count(intel_dp);
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
}
/* Enable backlight PWM and backlight PP control. */
void intel_edp_backlight_on(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(conn_state->best_encoder));
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
if (!intel_dp_is_edp(intel_dp))
return;
drm_dbg_kms(&i915->drm, "\n");
intel_backlight_enable(crtc_state, conn_state);
intel_pps_backlight_on(intel_dp);
}
/* Disable backlight PP control and backlight PWM. */
void intel_edp_backlight_off(const struct drm_connector_state *old_conn_state)
{
struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(old_conn_state->best_encoder));
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
if (!intel_dp_is_edp(intel_dp))
return;
drm_dbg_kms(&i915->drm, "\n");
intel_pps_backlight_off(intel_dp);
intel_backlight_disable(old_conn_state);
}
static bool downstream_hpd_needs_d0(struct intel_dp *intel_dp)
{
/*
* DPCD 1.2+ should support BRANCH_DEVICE_CTRL, and thus
* be capable of signalling downstream hpd with a long pulse.
* Whether or not that means D3 is safe to use is not clear,
* but let's assume so until proven otherwise.
*
* FIXME should really check all downstream ports...
*/
return intel_dp->dpcd[DP_DPCD_REV] == 0x11 &&
drm_dp_is_branch(intel_dp->dpcd) &&
intel_dp->downstream_ports[0] & DP_DS_PORT_HPD;
}
static int
write_dsc_decompression_flag(struct drm_dp_aux *aux, u8 flag, bool set)
{
int err;
u8 val;
err = drm_dp_dpcd_readb(aux, DP_DSC_ENABLE, &val);
if (err < 0)
return err;
if (set)
val |= flag;
else
val &= ~flag;
return drm_dp_dpcd_writeb(aux, DP_DSC_ENABLE, val);
}
static void
intel_dp_sink_set_dsc_decompression(struct intel_connector *connector,
bool enable)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
if (write_dsc_decompression_flag(connector->dp.dsc_decompression_aux,
DP_DECOMPRESSION_EN, enable) < 0)
drm_dbg_kms(&i915->drm,
"Failed to %s sink decompression state\n",
str_enable_disable(enable));
}
static void
intel_dp_sink_set_dsc_passthrough(const struct intel_connector *connector,
bool enable)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct drm_dp_aux *aux = connector->port ?
connector->port->passthrough_aux : NULL;
if (!aux)
return;
if (write_dsc_decompression_flag(aux,
DP_DSC_PASSTHROUGH_EN, enable) < 0)
drm_dbg_kms(&i915->drm,
"Failed to %s sink compression passthrough state\n",
str_enable_disable(enable));
}
static int intel_dp_dsc_aux_ref_count(struct intel_atomic_state *state,
const struct intel_connector *connector,
bool for_get_ref)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
struct drm_connector *_connector_iter;
struct drm_connector_state *old_conn_state;
struct drm_connector_state *new_conn_state;
int ref_count = 0;
int i;
/*
* On SST the decompression AUX device won't be shared, each connector
* uses for this its own AUX targeting the sink device.
*/
if (!connector->mst_port)
return connector->dp.dsc_decompression_enabled ? 1 : 0;
for_each_oldnew_connector_in_state(&state->base, _connector_iter,
old_conn_state, new_conn_state, i) {
const struct intel_connector *
connector_iter = to_intel_connector(_connector_iter);
if (connector_iter->mst_port != connector->mst_port)
continue;
if (!connector_iter->dp.dsc_decompression_enabled)
continue;
drm_WARN_ON(&i915->drm,
(for_get_ref && !new_conn_state->crtc) ||
(!for_get_ref && !old_conn_state->crtc));
if (connector_iter->dp.dsc_decompression_aux ==
connector->dp.dsc_decompression_aux)
ref_count++;
}
return ref_count;
}
static bool intel_dp_dsc_aux_get_ref(struct intel_atomic_state *state,
struct intel_connector *connector)
{
bool ret = intel_dp_dsc_aux_ref_count(state, connector, true) == 0;
connector->dp.dsc_decompression_enabled = true;
return ret;
}
static bool intel_dp_dsc_aux_put_ref(struct intel_atomic_state *state,
struct intel_connector *connector)
{
connector->dp.dsc_decompression_enabled = false;
return intel_dp_dsc_aux_ref_count(state, connector, false) == 0;
}
/**
* intel_dp_sink_enable_decompression - Enable DSC decompression in sink/last branch device
* @state: atomic state
* @connector: connector to enable the decompression for
* @new_crtc_state: new state for the CRTC driving @connector
*
* Enable the DSC decompression if required in the %DP_DSC_ENABLE DPCD
* register of the appropriate sink/branch device. On SST this is always the
* sink device, whereas on MST based on each device's DSC capabilities it's
* either the last branch device (enabling decompression in it) or both the
* last branch device (enabling passthrough in it) and the sink device
* (enabling decompression in it).
*/
void intel_dp_sink_enable_decompression(struct intel_atomic_state *state,
struct intel_connector *connector,
const struct intel_crtc_state *new_crtc_state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
if (!new_crtc_state->dsc.compression_enable)
return;
if (drm_WARN_ON(&i915->drm,
!connector->dp.dsc_decompression_aux ||
connector->dp.dsc_decompression_enabled))
return;
if (!intel_dp_dsc_aux_get_ref(state, connector))
return;
intel_dp_sink_set_dsc_passthrough(connector, true);
intel_dp_sink_set_dsc_decompression(connector, true);
}
/**
* intel_dp_sink_disable_decompression - Disable DSC decompression in sink/last branch device
* @state: atomic state
* @connector: connector to disable the decompression for
* @old_crtc_state: old state for the CRTC driving @connector
*
* Disable the DSC decompression if required in the %DP_DSC_ENABLE DPCD
* register of the appropriate sink/branch device, corresponding to the
* sequence in intel_dp_sink_enable_decompression().
*/
void intel_dp_sink_disable_decompression(struct intel_atomic_state *state,
struct intel_connector *connector,
const struct intel_crtc_state *old_crtc_state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
if (!old_crtc_state->dsc.compression_enable)
return;
if (drm_WARN_ON(&i915->drm,
!connector->dp.dsc_decompression_aux ||
!connector->dp.dsc_decompression_enabled))
return;
if (!intel_dp_dsc_aux_put_ref(state, connector))
return;
intel_dp_sink_set_dsc_decompression(connector, false);
intel_dp_sink_set_dsc_passthrough(connector, false);
}
static void
intel_edp_init_source_oui(struct intel_dp *intel_dp, bool careful)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 oui[] = { 0x00, 0xaa, 0x01 };
u8 buf[3] = {};
/*
* During driver init, we want to be careful and avoid changing the source OUI if it's
* already set to what we want, so as to avoid clearing any state by accident
*/
if (careful) {
if (drm_dp_dpcd_read(&intel_dp->aux, DP_SOURCE_OUI, buf, sizeof(buf)) < 0)
drm_err(&i915->drm, "Failed to read source OUI\n");
if (memcmp(oui, buf, sizeof(oui)) == 0)
return;
}
if (drm_dp_dpcd_write(&intel_dp->aux, DP_SOURCE_OUI, oui, sizeof(oui)) < 0)
drm_err(&i915->drm, "Failed to write source OUI\n");
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
2021-11-30 21:29:09 +00:00
intel_dp->last_oui_write = jiffies;
}
void intel_dp_wait_source_oui(struct intel_dp *intel_dp)
{
drm/i915: Get HDR DPCD refresh timeout from VBT Grab the HDR DPCD refresh timeout (time we need to wait after writing the sourc OUI before the HDR DPCD registers are ready) from the VBT. Windows doesn't even seem to have any default value for this, which is perhaps a bit weird since the VBT value is documented as TGL+ and I thought the HDR backlight stuff might already be used on earlier platforms. To play it safe I left the old hardcoded 30ms default in place. Digging through some internal stuff that seems to have been a number given by the vendor for one particularly slow TCON. Although I did see 50ms mentioned somewhere as well. Let's also include the value in the debug print to ease debugging, and toss in the customary connector id+name as well. The TGL Thinkpad T14 I have sets this to 0 btw. So the delay is now gone on this machine: [CONNECTOR:308:eDP-1] Detected Intel HDR backlight interface version 1 [CONNECTOR:308:eDP-1] Using Intel proprietary eDP backlight controls [CONNECTOR:308:eDP-1] SDR backlight is controlled through PWM [CONNECTOR:308:eDP-1] Using native PCH PWM for backlight control (controller=0) [CONNECTOR:308:eDP-1] Using AUX HDR interface for backlight control (range 0..496) [CONNECTOR:308:eDP-1] Performing OUI wait (0 ms) Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230220164718.23117-1-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-02-20 16:47:18 +00:00
struct intel_connector *connector = intel_dp->attached_connector;
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
2021-11-30 21:29:09 +00:00
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
drm/i915: Get HDR DPCD refresh timeout from VBT Grab the HDR DPCD refresh timeout (time we need to wait after writing the sourc OUI before the HDR DPCD registers are ready) from the VBT. Windows doesn't even seem to have any default value for this, which is perhaps a bit weird since the VBT value is documented as TGL+ and I thought the HDR backlight stuff might already be used on earlier platforms. To play it safe I left the old hardcoded 30ms default in place. Digging through some internal stuff that seems to have been a number given by the vendor for one particularly slow TCON. Although I did see 50ms mentioned somewhere as well. Let's also include the value in the debug print to ease debugging, and toss in the customary connector id+name as well. The TGL Thinkpad T14 I have sets this to 0 btw. So the delay is now gone on this machine: [CONNECTOR:308:eDP-1] Detected Intel HDR backlight interface version 1 [CONNECTOR:308:eDP-1] Using Intel proprietary eDP backlight controls [CONNECTOR:308:eDP-1] SDR backlight is controlled through PWM [CONNECTOR:308:eDP-1] Using native PCH PWM for backlight control (controller=0) [CONNECTOR:308:eDP-1] Using AUX HDR interface for backlight control (range 0..496) [CONNECTOR:308:eDP-1] Performing OUI wait (0 ms) Cc: Lyude Paul <lyude@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230220164718.23117-1-ville.syrjala@linux.intel.com Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
2023-02-20 16:47:18 +00:00
drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s] Performing OUI wait (%u ms)\n",
connector->base.base.id, connector->base.name,
connector->panel.vbt.backlight.hdr_dpcd_refresh_timeout);
wait_remaining_ms_from_jiffies(intel_dp->last_oui_write,
connector->panel.vbt.backlight.hdr_dpcd_refresh_timeout);
}
/* If the device supports it, try to set the power state appropriately */
void intel_dp_set_power(struct intel_dp *intel_dp, u8 mode)
{
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
int ret, i;
/* Should have a valid DPCD by this point */
if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
return;
if (mode != DP_SET_POWER_D0) {
if (downstream_hpd_needs_d0(intel_dp))
return;
ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, mode);
} else {
struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp);
lspcon_resume(dp_to_dig_port(intel_dp));
/* Write the source OUI as early as possible */
if (intel_dp_is_edp(intel_dp))
intel_edp_init_source_oui(intel_dp, false);
/*
* When turning on, we need to retry for 1ms to give the sink
* time to wake up.
*/
for (i = 0; i < 3; i++) {
ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, mode);
if (ret == 1)
break;
msleep(1);
}
if (ret == 1 && lspcon->active)
lspcon_wait_pcon_mode(lspcon);
}
if (ret != 1)
drm_dbg_kms(&i915->drm, "[ENCODER:%d:%s] Set power to %s failed\n",
encoder->base.base.id, encoder->base.name,
mode == DP_SET_POWER_D0 ? "D0" : "D3");
}
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp);
/**
* intel_dp_sync_state - sync the encoder state during init/resume
* @encoder: intel encoder to sync
* @crtc_state: state for the CRTC connected to the encoder
*
* Sync any state stored in the encoder wrt. HW state during driver init
* and system resume.
*/
void intel_dp_sync_state(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state)
{
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
drm/i915/dp: Skip the HW readout of DPCD on disabled encoders Reading out the DP encoders' DPCD during booting or resume is only required for enabled encoders: such encoders may be modesetted during the initial commit and the link training this involves depends on an initialized DPCD. For DDI encoders reading out the DPCD is skipped, do the same on pre-DDI platforms. Atm, the first DPCD readout without a sink connected - which is a likely scneario if the encoder is disabled - leaves intel_dp->num_common_rates at 0, which resulted in intel_dp_sync_state()->intel_dp_max_common_rate() in a intel_dp->common_rates[-1] access. This by definition results in an undefined behaviour, though to my best knowledge in all HW/compiler configurations it actually results in accessing the array item type value preceding the array. In this case the preceding value happens to be intel_dp->num_common_rates, which is 0, so this issue - by luck - didn't cause a user visible problem. Nevertheless it's still an undefined behaviour and in CONFIG_UBSAN builds leads to a kernel BUG() (which revealed this problem for us), hence CC:stable. A related problem in case the encoder is enabled but the sink is not connected or the DPCD readout fails is fixed by the next patch. v2: Amend the commit message describing the root cause of the CONFIG_UBSAN BUG(). Fixes: a532cde31de3 ("drm/i915/tc: Fix TypeC port init/resume time sanitization") References: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 Reported-and-tested-by: Mat Jonczyk <mat.jonczyk@o2.pl> Cc: Mat Jonczyk <mat.jonczyk@o2.pl> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-2-imre.deak@intel.com
2021-10-18 09:41:49 +00:00
if (!crtc_state)
return;
/*
* Don't clobber DPCD if it's been already read out during output
* setup (eDP) or detect.
*/
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
intel_dp_get_dpcd(intel_dp);
intel_dp_reset_max_link_params(intel_dp);
}
bool intel_dp_initial_fastset_check(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
bool fastset = true;
/*
* If BIOS has set an unsupported or non-standard link rate for some
* reason force an encoder recompute and full modeset.
*/
if (intel_dp_rate_index(intel_dp->source_rates, intel_dp->num_source_rates,
crtc_state->port_clock) < 0) {
drm_dbg_kms(&i915->drm, "[ENCODER:%d:%s] Forcing full modeset due to unsupported link rate\n",
encoder->base.base.id, encoder->base.name);
crtc_state->uapi.connectors_changed = true;
fastset = false;
}
/*
* FIXME hack to force full modeset when DSC is being used.
*
* As long as we do not have full state readout and config comparison
* of crtc_state->dsc, we have no way to ensure reliable fastset.
* Remove once we have readout for DSC.
*/
if (crtc_state->dsc.compression_enable) {
drm_dbg_kms(&i915->drm, "[ENCODER:%d:%s] Forcing full modeset due to DSC being enabled\n",
encoder->base.base.id, encoder->base.name);
crtc_state->uapi.mode_changed = true;
fastset = false;
}
if (CAN_PSR(intel_dp)) {
drm_dbg_kms(&i915->drm, "[ENCODER:%d:%s] Forcing full modeset to compute PSR state\n",
encoder->base.base.id, encoder->base.name);
crtc_state->uapi.mode_changed = true;
fastset = false;
}
return fastset;
}
static void intel_dp_get_pcon_dsc_cap(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
/* Clear the cached register set to avoid using stale values */
memset(intel_dp->pcon_dsc_dpcd, 0, sizeof(intel_dp->pcon_dsc_dpcd));
if (drm_dp_dpcd_read(&intel_dp->aux, DP_PCON_DSC_ENCODER,
intel_dp->pcon_dsc_dpcd,
sizeof(intel_dp->pcon_dsc_dpcd)) < 0)
drm_err(&i915->drm, "Failed to read DPCD register 0x%x\n",
DP_PCON_DSC_ENCODER);
drm_dbg_kms(&i915->drm, "PCON ENCODER DSC DPCD: %*ph\n",
(int)sizeof(intel_dp->pcon_dsc_dpcd), intel_dp->pcon_dsc_dpcd);
}
static int intel_dp_pcon_get_frl_mask(u8 frl_bw_mask)
{
int bw_gbps[] = {9, 18, 24, 32, 40, 48};
int i;
for (i = ARRAY_SIZE(bw_gbps) - 1; i >= 0; i--) {
if (frl_bw_mask & (1 << i))
return bw_gbps[i];
}
return 0;
}
static int intel_dp_pcon_set_frl_mask(int max_frl)
{
switch (max_frl) {
case 48:
return DP_PCON_FRL_BW_MASK_48GBPS;
case 40:
return DP_PCON_FRL_BW_MASK_40GBPS;
case 32:
return DP_PCON_FRL_BW_MASK_32GBPS;
case 24:
return DP_PCON_FRL_BW_MASK_24GBPS;
case 18:
return DP_PCON_FRL_BW_MASK_18GBPS;
case 9:
return DP_PCON_FRL_BW_MASK_9GBPS;
}
return 0;
}
static int intel_dp_hdmi_sink_max_frl(struct intel_dp *intel_dp)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
int max_frl_rate;
int max_lanes, rate_per_lane;
int max_dsc_lanes, dsc_rate_per_lane;
max_lanes = connector->display_info.hdmi.max_lanes;
rate_per_lane = connector->display_info.hdmi.max_frl_rate_per_lane;
max_frl_rate = max_lanes * rate_per_lane;
if (connector->display_info.hdmi.dsc_cap.v_1p2) {
max_dsc_lanes = connector->display_info.hdmi.dsc_cap.max_lanes;
dsc_rate_per_lane = connector->display_info.hdmi.dsc_cap.max_frl_rate_per_lane;
if (max_dsc_lanes && dsc_rate_per_lane)
max_frl_rate = min(max_frl_rate, max_dsc_lanes * dsc_rate_per_lane);
}
return max_frl_rate;
}
static bool
intel_dp_pcon_is_frl_trained(struct intel_dp *intel_dp,
u8 max_frl_bw_mask, u8 *frl_trained_mask)
{
if (drm_dp_pcon_hdmi_link_active(&intel_dp->aux) &&
drm_dp_pcon_hdmi_link_mode(&intel_dp->aux, frl_trained_mask) == DP_PCON_HDMI_MODE_FRL &&
*frl_trained_mask >= max_frl_bw_mask)
return true;
return false;
}
static int intel_dp_pcon_start_frl_training(struct intel_dp *intel_dp)
{
#define TIMEOUT_FRL_READY_MS 500
#define TIMEOUT_HDMI_LINK_ACTIVE_MS 1000
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int max_frl_bw, max_pcon_frl_bw, max_edid_frl_bw, ret;
u8 max_frl_bw_mask = 0, frl_trained_mask;
bool is_active;
max_pcon_frl_bw = intel_dp->dfp.pcon_max_frl_bw;
drm_dbg(&i915->drm, "PCON max rate = %d Gbps\n", max_pcon_frl_bw);
max_edid_frl_bw = intel_dp_hdmi_sink_max_frl(intel_dp);
drm_dbg(&i915->drm, "Sink max rate from EDID = %d Gbps\n", max_edid_frl_bw);
max_frl_bw = min(max_edid_frl_bw, max_pcon_frl_bw);
if (max_frl_bw <= 0)
return -EINVAL;
max_frl_bw_mask = intel_dp_pcon_set_frl_mask(max_frl_bw);
drm_dbg(&i915->drm, "MAX_FRL_BW_MASK = %u\n", max_frl_bw_mask);
if (intel_dp_pcon_is_frl_trained(intel_dp, max_frl_bw_mask, &frl_trained_mask))
goto frl_trained;
ret = drm_dp_pcon_frl_prepare(&intel_dp->aux, false);
if (ret < 0)
return ret;
/* Wait for PCON to be FRL Ready */
wait_for(is_active = drm_dp_pcon_is_frl_ready(&intel_dp->aux) == true, TIMEOUT_FRL_READY_MS);
if (!is_active)
return -ETIMEDOUT;
ret = drm_dp_pcon_frl_configure_1(&intel_dp->aux, max_frl_bw,
DP_PCON_ENABLE_SEQUENTIAL_LINK);
if (ret < 0)
return ret;
ret = drm_dp_pcon_frl_configure_2(&intel_dp->aux, max_frl_bw_mask,
DP_PCON_FRL_LINK_TRAIN_NORMAL);
if (ret < 0)
return ret;
ret = drm_dp_pcon_frl_enable(&intel_dp->aux);
if (ret < 0)
return ret;
/*
* Wait for FRL to be completed
* Check if the HDMI Link is up and active.
*/
wait_for(is_active =
intel_dp_pcon_is_frl_trained(intel_dp, max_frl_bw_mask, &frl_trained_mask),
TIMEOUT_HDMI_LINK_ACTIVE_MS);
if (!is_active)
return -ETIMEDOUT;
frl_trained:
drm_dbg(&i915->drm, "FRL_TRAINED_MASK = %u\n", frl_trained_mask);
intel_dp->frl.trained_rate_gbps = intel_dp_pcon_get_frl_mask(frl_trained_mask);
intel_dp->frl.is_trained = true;
drm_dbg(&i915->drm, "FRL trained with : %d Gbps\n", intel_dp->frl.trained_rate_gbps);
return 0;
}
static bool intel_dp_is_hdmi_2_1_sink(struct intel_dp *intel_dp)
{
if (drm_dp_is_branch(intel_dp->dpcd) &&
intel_dp_has_hdmi_sink(intel_dp) &&
intel_dp_hdmi_sink_max_frl(intel_dp) > 0)
return true;
return false;
}
static
int intel_dp_pcon_set_tmds_mode(struct intel_dp *intel_dp)
{
int ret;
u8 buf = 0;
/* Set PCON source control mode */
buf |= DP_PCON_ENABLE_SOURCE_CTL_MODE;
ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
if (ret < 0)
return ret;
/* Set HDMI LINK ENABLE */
buf |= DP_PCON_ENABLE_HDMI_LINK;
ret = drm_dp_dpcd_writeb(&intel_dp->aux, DP_PCON_HDMI_LINK_CONFIG_1, buf);
if (ret < 0)
return ret;
return 0;
}
void intel_dp_check_frl_training(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
/*
* Always go for FRL training if:
* -PCON supports SRC_CTL_MODE (VESA DP2.0-HDMI2.1 PCON Spec Draft-1 Sec-7)
* -sink is HDMI2.1
*/
if (!(intel_dp->downstream_ports[2] & DP_PCON_SOURCE_CTL_MODE) ||
!intel_dp_is_hdmi_2_1_sink(intel_dp) ||
intel_dp->frl.is_trained)
return;
if (intel_dp_pcon_start_frl_training(intel_dp) < 0) {
int ret, mode;
drm_dbg(&dev_priv->drm, "Couldn't set FRL mode, continuing with TMDS mode\n");
ret = intel_dp_pcon_set_tmds_mode(intel_dp);
mode = drm_dp_pcon_hdmi_link_mode(&intel_dp->aux, NULL);
if (ret < 0 || mode != DP_PCON_HDMI_MODE_TMDS)
drm_dbg(&dev_priv->drm, "Issue with PCON, cannot set TMDS mode\n");
} else {
drm_dbg(&dev_priv->drm, "FRL training Completed\n");
}
}
static int
intel_dp_pcon_dsc_enc_slice_height(const struct intel_crtc_state *crtc_state)
{
int vactive = crtc_state->hw.adjusted_mode.vdisplay;
return intel_hdmi_dsc_get_slice_height(vactive);
}
static int
intel_dp_pcon_dsc_enc_slices(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
int hdmi_throughput = connector->display_info.hdmi.dsc_cap.clk_per_slice;
int hdmi_max_slices = connector->display_info.hdmi.dsc_cap.max_slices;
int pcon_max_slices = drm_dp_pcon_dsc_max_slices(intel_dp->pcon_dsc_dpcd);
int pcon_max_slice_width = drm_dp_pcon_dsc_max_slice_width(intel_dp->pcon_dsc_dpcd);
return intel_hdmi_dsc_get_num_slices(crtc_state, pcon_max_slices,
pcon_max_slice_width,
hdmi_max_slices, hdmi_throughput);
}
static int
intel_dp_pcon_dsc_enc_bpp(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state,
int num_slices, int slice_width)
{
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
int output_format = crtc_state->output_format;
bool hdmi_all_bpp = connector->display_info.hdmi.dsc_cap.all_bpp;
int pcon_fractional_bpp = drm_dp_pcon_dsc_bpp_incr(intel_dp->pcon_dsc_dpcd);
int hdmi_max_chunk_bytes =
connector->display_info.hdmi.dsc_cap.total_chunk_kbytes * 1024;
return intel_hdmi_dsc_get_bpp(pcon_fractional_bpp, slice_width,
num_slices, output_format, hdmi_all_bpp,
hdmi_max_chunk_bytes);
}
void
intel_dp_pcon_dsc_configure(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
u8 pps_param[6];
int slice_height;
int slice_width;
int num_slices;
int bits_per_pixel;
int ret;
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct drm_connector *connector;
bool hdmi_is_dsc_1_2;
if (!intel_dp_is_hdmi_2_1_sink(intel_dp))
return;
if (!intel_connector)
return;
connector = &intel_connector->base;
hdmi_is_dsc_1_2 = connector->display_info.hdmi.dsc_cap.v_1p2;
if (!drm_dp_pcon_enc_is_dsc_1_2(intel_dp->pcon_dsc_dpcd) ||
!hdmi_is_dsc_1_2)
return;
slice_height = intel_dp_pcon_dsc_enc_slice_height(crtc_state);
if (!slice_height)
return;
num_slices = intel_dp_pcon_dsc_enc_slices(intel_dp, crtc_state);
if (!num_slices)
return;
slice_width = DIV_ROUND_UP(crtc_state->hw.adjusted_mode.hdisplay,
num_slices);
bits_per_pixel = intel_dp_pcon_dsc_enc_bpp(intel_dp, crtc_state,
num_slices, slice_width);
if (!bits_per_pixel)
return;
pps_param[0] = slice_height & 0xFF;
pps_param[1] = slice_height >> 8;
pps_param[2] = slice_width & 0xFF;
pps_param[3] = slice_width >> 8;
pps_param[4] = bits_per_pixel & 0xFF;
pps_param[5] = (bits_per_pixel >> 8) & 0x3;
ret = drm_dp_pcon_pps_override_param(&intel_dp->aux, pps_param);
if (ret < 0)
drm_dbg_kms(&i915->drm, "Failed to set pcon DSC\n");
}
void intel_dp_configure_protocol_converter(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
bool ycbcr444_to_420 = false;
bool rgb_to_ycbcr = false;
u8 tmp;
if (intel_dp->dpcd[DP_DPCD_REV] < 0x13)
return;
if (!drm_dp_is_branch(intel_dp->dpcd))
return;
tmp = intel_dp_has_hdmi_sink(intel_dp) ? DP_HDMI_DVI_OUTPUT_CONFIG : 0;
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_PROTOCOL_CONVERTER_CONTROL_0, tmp) != 1)
drm_dbg_kms(&i915->drm, "Failed to %s protocol converter HDMI mode\n",
str_enable_disable(intel_dp_has_hdmi_sink(intel_dp)));
if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR420) {
switch (crtc_state->output_format) {
case INTEL_OUTPUT_FORMAT_YCBCR420:
break;
case INTEL_OUTPUT_FORMAT_YCBCR444:
ycbcr444_to_420 = true;
break;
case INTEL_OUTPUT_FORMAT_RGB:
rgb_to_ycbcr = true;
ycbcr444_to_420 = true;
break;
default:
MISSING_CASE(crtc_state->output_format);
break;
}
} else if (crtc_state->sink_format == INTEL_OUTPUT_FORMAT_YCBCR444) {
switch (crtc_state->output_format) {
case INTEL_OUTPUT_FORMAT_YCBCR444:
break;
case INTEL_OUTPUT_FORMAT_RGB:
rgb_to_ycbcr = true;
break;
default:
MISSING_CASE(crtc_state->output_format);
break;
}
}
tmp = ycbcr444_to_420 ? DP_CONVERSION_TO_YCBCR420_ENABLE : 0;
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_PROTOCOL_CONVERTER_CONTROL_1, tmp) != 1)
drm_dbg_kms(&i915->drm,
"Failed to %s protocol converter YCbCr 4:2:0 conversion mode\n",
str_enable_disable(intel_dp->dfp.ycbcr_444_to_420));
tmp = rgb_to_ycbcr ? DP_CONVERSION_BT709_RGB_YCBCR_ENABLE : 0;
if (drm_dp_pcon_convert_rgb_to_ycbcr(&intel_dp->aux, tmp) < 0)
drm_dbg_kms(&i915->drm,
"Failed to %s protocol converter RGB->YCbCr conversion mode\n",
str_enable_disable(tmp));
}
drm/i915/dp: Add a config function for YCBCR420 outputs This patch checks a support of YCBCR420 outputs on an encoder level. If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420 output, else it continues with RGB output mode. It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using a pipe scaler as RGB to YCbCr 4:4:4. v2: Addressed review comments from Ville. Style fixed with few naming. %s/config/crtc_state/ %s/intel_crtc/crtc/ If lscon is active, it makes not to call intel_dp_ycbcr420_config() to avoid to clobber of lspcon_ycbcr420_config() routine. And it move the 420_only check into the intel_dp_ycbcr420_config(). v3: Fix uninitialized return value and it is reported by Dan Carpenter. v4: Addressed review comments from Ville. In order to avoid the extra indentation, it inverts if-clause on intel_dp_ycbcr420_config(). Remove the error print where no errors print are allowed. v6: Rebase v7: Move intel_dp_get_colorimetry_status() to intel_dp from intel_psr. intel_dp_get_colorimetry_status() checks VSC_SDP_EXTENSION_FOR_COLORIMETRY_SUPPORTED bit in the DPRX_FEATURE_ENUMERATION_LIST register. And intel_dp_ycbcr420_config() uses intel_dp_get_colorimetry_status(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190521121721.32010-2-gwan-gyeong.mun@intel.com
2019-05-21 12:17:16 +00:00
bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp)
{
u8 dprx = 0;
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
&dprx) != 1)
return false;
return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
}
static void intel_dp_read_dsc_dpcd(struct drm_dp_aux *aux,
u8 dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
2018-10-31 00:19:19 +00:00
{
if (drm_dp_dpcd_read(aux, DP_DSC_SUPPORT, dsc_dpcd,
DP_DSC_RECEIVER_CAP_SIZE) < 0) {
drm_err(aux->drm_dev,
"Failed to read DPCD register 0x%x\n",
DP_DSC_SUPPORT);
return;
}
drm_dbg_kms(aux->drm_dev, "DSC DPCD: %*ph\n",
DP_DSC_RECEIVER_CAP_SIZE,
dsc_dpcd);
}
void intel_dp_get_dsc_sink_cap(u8 dpcd_rev, struct intel_connector *connector)
2018-10-31 00:19:19 +00:00
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
2018-10-31 00:19:19 +00:00
/*
* Clear the cached register set to avoid using stale values
* for the sinks that do not support DSC.
*/
memset(connector->dp.dsc_dpcd, 0, sizeof(connector->dp.dsc_dpcd));
2018-10-31 00:19:19 +00:00
/* Clear fec_capable to avoid using stale values */
connector->dp.fec_capability = 0;
2018-10-31 00:19:19 +00:00
if (dpcd_rev < DP_DPCD_REV_14)
return;
intel_dp_read_dsc_dpcd(connector->dp.dsc_decompression_aux,
connector->dp.dsc_dpcd);
if (drm_dp_dpcd_readb(connector->dp.dsc_decompression_aux, DP_FEC_CAPABILITY,
&connector->dp.fec_capability) < 0) {
drm_err(&i915->drm, "Failed to read FEC DPCD register\n");
return;
2018-10-31 00:19:19 +00:00
}
drm_dbg_kms(&i915->drm, "FEC CAPABILITY: %x\n",
connector->dp.fec_capability);
}
static void intel_edp_get_dsc_sink_cap(u8 edp_dpcd_rev, struct intel_connector *connector)
{
if (edp_dpcd_rev < DP_EDP_14)
return;
intel_dp_read_dsc_dpcd(connector->dp.dsc_decompression_aux, connector->dp.dsc_dpcd);
2018-10-31 00:19:19 +00:00
}
static void intel_edp_mso_mode_fixup(struct intel_connector *connector,
struct drm_display_mode *mode)
{
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
int n = intel_dp->mso_link_count;
int overlap = intel_dp->mso_pixel_overlap;
if (!mode || !n)
return;
mode->hdisplay = (mode->hdisplay - overlap) * n;
mode->hsync_start = (mode->hsync_start - overlap) * n;
mode->hsync_end = (mode->hsync_end - overlap) * n;
mode->htotal = (mode->htotal - overlap) * n;
mode->clock *= n;
drm_mode_set_name(mode);
drm_dbg_kms(&i915->drm,
"[CONNECTOR:%d:%s] using generated MSO mode: " DRM_MODE_FMT "\n",
connector->base.base.id, connector->base.name,
DRM_MODE_ARG(mode));
}
void intel_edp_fixup_vbt_bpp(struct intel_encoder *encoder, int pipe_bpp)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_connector *connector = intel_dp->attached_connector;
if (connector->panel.vbt.edp.bpp && pipe_bpp > connector->panel.vbt.edp.bpp) {
/*
* This is a big fat ugly hack.
*
* Some machines in UEFI boot mode provide us a VBT that has 18
* bpp and 1.62 GHz link bandwidth for eDP, which for reasons
* unknown we fail to light up. Yet the same BIOS boots up with
* 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
* max, not what it tells us to use.
*
* Note: This will still be broken if the eDP panel is not lit
* up by the BIOS, and thus we can't get the mode at module
* load.
*/
drm_dbg_kms(&dev_priv->drm,
"pipe has %d bpp for eDP panel, overriding BIOS-provided max %d bpp\n",
pipe_bpp, connector->panel.vbt.edp.bpp);
connector->panel.vbt.edp.bpp = pipe_bpp;
}
}
static void intel_edp_mso_init(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
struct drm_display_info *info = &connector->base.display_info;
u8 mso;
if (intel_dp->edp_dpcd[0] < DP_EDP_14)
return;
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_MSO_LINK_CAPABILITIES, &mso) != 1) {
drm_err(&i915->drm, "Failed to read MSO cap\n");
return;
}
/* Valid configurations are SST or MSO 2x1, 2x2, 4x1 */
mso &= DP_EDP_MSO_NUMBER_OF_LINKS_MASK;
if (mso % 2 || mso > drm_dp_max_lane_count(intel_dp->dpcd)) {
drm_err(&i915->drm, "Invalid MSO link count cap %u\n", mso);
mso = 0;
}
if (mso) {
drm_dbg_kms(&i915->drm, "Sink MSO %ux%u configuration, pixel overlap %u\n",
mso, drm_dp_max_lane_count(intel_dp->dpcd) / mso,
info->mso_pixel_overlap);
if (!HAS_MSO(i915)) {
drm_err(&i915->drm, "No source MSO support, disabling\n");
mso = 0;
}
}
intel_dp->mso_link_count = mso;
intel_dp->mso_pixel_overlap = mso ? info->mso_pixel_overlap : 0;
}
static bool
intel_edp_init_dpcd(struct intel_dp *intel_dp, struct intel_connector *connector)
{
struct drm_i915_private *dev_priv =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
drm/i915: Read sink_count dpcd always Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse interrupts. This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd. SINK_COUNT denotes if a display is attached, while DOWNSTREAM_PORT_PRESET indicates how many ports are available in the dongle where display can be attached. so it is possible for sink count to change irrespective of value in downstream port dpcd. Here is a table of possible values and scenarios sink_count downstream_port present 0 0 no display is attached 0 1 dongle is connected without display 1 0 display connected directly 1 1 display connected through dongle v2: Storing value of intel_dp->sink_count that is ready for consumption. (Ander) Squashing two commits into one. (Ander) v3: Added comment to explain the need of early return when sink count is 0. (Ander) Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-4-git-send-email-shubhangi.shrivastava@intel.com
2016-03-30 12:35:25 +00:00
/* this function is meant to be called only once */
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
drm_WARN_ON(&dev_priv->drm, intel_dp->dpcd[DP_DPCD_REV] != 0);
drm/i915: Read sink_count dpcd always Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse interrupts. This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd. SINK_COUNT denotes if a display is attached, while DOWNSTREAM_PORT_PRESET indicates how many ports are available in the dongle where display can be attached. so it is possible for sink count to change irrespective of value in downstream port dpcd. Here is a table of possible values and scenarios sink_count downstream_port present 0 0 no display is attached 0 1 dongle is connected without display 1 0 display connected directly 1 1 display connected through dongle v2: Storing value of intel_dp->sink_count that is ready for consumption. (Ander) Squashing two commits into one. (Ander) v3: Added comment to explain the need of early return when sink count is 0. (Ander) Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-4-git-send-email-shubhangi.shrivastava@intel.com
2016-03-30 12:35:25 +00:00
if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd) != 0)
drm/i915: Read sink_count dpcd always Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse interrupts. This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd. SINK_COUNT denotes if a display is attached, while DOWNSTREAM_PORT_PRESET indicates how many ports are available in the dongle where display can be attached. so it is possible for sink count to change irrespective of value in downstream port dpcd. Here is a table of possible values and scenarios sink_count downstream_port present 0 0 no display is attached 0 1 dongle is connected without display 1 0 display connected directly 1 1 display connected through dongle v2: Storing value of intel_dp->sink_count that is ready for consumption. (Ander) Squashing two commits into one. (Ander) v3: Added comment to explain the need of early return when sink count is 0. (Ander) Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-4-git-send-email-shubhangi.shrivastava@intel.com
2016-03-30 12:35:25 +00:00
return false;
drm_dp_read_desc(&intel_dp->aux, &intel_dp->desc,
drm_dp_is_branch(intel_dp->dpcd));
drm/i915/edp: read edp display control registers unconditionally Per my reading of the eDP spec, DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in DP_EDP_CONFIGURATION_CAP should be set if the eDP display control registers starting at offset DP_EDP_DPCD_REV are "enabled". Currently we check the bit before reading the registers, and DP_EDP_DPCD_REV is the only way to detect eDP revision. Turns out there are (likely buggy) displays that require eDP 1.4+ features, such as supported link rates and link rate select, but do not have the bit set. Read the display control registers unconditionally. They are supposed to read zero anyway if they are not supported, so there should be no harm in this. This fixes the referenced bug by enabling the eDP version check, and thus reading of the supported link rates. The panel in question has 0 in DP_MAX_LINK_RATE which is only supported in eDP 1.4+. Without the supported link rates method we default to RBR which is insufficient for the panel native mode. As a curiosity, the panel also has a bogus value of 0x12 in DP_EDP_DPCD_REV, but that passes our check for >= DP_EDP_14 (which is 0x03). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103400 Reported-and-tested-by: Nicolas P. <issun.artiste@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> 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/20171026142932.17737-1-jani.nikula@intel.com (cherry picked from commit 0501a3b0eb01ac2209ef6fce76153e5d6b07034e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2017-10-26 14:29:31 +00:00
/*
* Read the eDP display control registers.
*
* Do this independent of DP_DPCD_DISPLAY_CONTROL_CAPABLE bit in
* DP_EDP_CONFIGURATION_CAP, because some buggy displays do not have it
* set, but require eDP 1.4+ detection (e.g. for supported link rates
* method). The display control registers should read zero if they're
* not supported anyway.
*/
if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_DPCD_REV,
intel_dp->edp_dpcd, sizeof(intel_dp->edp_dpcd)) ==
sizeof(intel_dp->edp_dpcd)) {
drm_dbg_kms(&dev_priv->drm, "eDP DPCD: %*ph\n",
(int)sizeof(intel_dp->edp_dpcd),
intel_dp->edp_dpcd);
intel_dp->use_max_params = intel_dp->edp_dpcd[0] < DP_EDP_14;
}
/*
* This has to be called after intel_dp->edp_dpcd is filled, PSR checks
* for SET_POWER_CAPABLE bit in intel_dp->edp_dpcd[1]
*/
intel_psr_init_dpcd(intel_dp);
drm/i915/dp: Ensure sink rate values are always valid Atm, there are no sink rate values set for DP (vs. eDP) sinks until the DPCD capabilities are successfully read from the sink. During this time intel_dp->num_common_rates is 0 which can lead to a intel_dp->common_rates[-1] (*) access, which is an undefined behaviour, in the following cases: - In intel_dp_sync_state(), if the encoder is enabled without a sink connected to the encoder's connector (BIOS enabled a monitor, but the user unplugged the monitor until the driver loaded). - In intel_dp_sync_state() if the encoder is enabled with a sink connected, but for some reason the DPCD read has failed. - In intel_dp_compute_link_config() if modesetting a connector without a sink connected on it. - In intel_dp_compute_link_config() if modesetting a connector with a a sink connected on it, but before probing the connector first. To avoid the (*) access in all the above cases, make sure that the sink rate table - and hence the common rate table - is always valid, by setting a default minimum sink rate when registering the connector before anything could use it. I also considered setting all the DP link rates by default, so that modesetting with higher resolution modes also succeeds in the last two cases above. However in case a sink is not connected that would stop working after the first modeset, due to the LT fallback logic. So this would need more work, beyond the scope of this fix. As I mentioned in the previous patch, I don't think the issue this patch fixes is user visible, however it is an undefined behaviour by definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. v2: Clear the default sink rates, before initializing these for eDP. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com
2021-10-18 14:34:17 +00:00
/* Clear the default sink rates */
intel_dp->num_sink_rates = 0;
/* Read the eDP 1.4+ supported link rates. */
if (intel_dp->edp_dpcd[0] >= DP_EDP_14) {
__le16 sink_rates[DP_MAX_SUPPORTED_RATES];
int i;
drm_dp_dpcd_read(&intel_dp->aux, DP_SUPPORTED_LINK_RATES,
sink_rates, sizeof(sink_rates));
for (i = 0; i < ARRAY_SIZE(sink_rates); i++) {
int val = le16_to_cpu(sink_rates[i]);
if (val == 0)
break;
/* Value read multiplied by 200kHz gives the per-lane
* link rate in kHz. The source rates are, however,
* stored in terms of LS_Clk kHz. The full conversion
* back to symbols is
* (val * 200kHz)*(8/10 ch. encoding)*(1/8 bit to Byte)
*/
intel_dp->sink_rates[i] = (val * 200) / 10;
}
intel_dp->num_sink_rates = i;
}
/*
* Use DP_LINK_RATE_SET if DP_SUPPORTED_LINK_RATES are available,
* default to DP_MAX_LINK_RATE and DP_LINK_BW_SET otherwise.
*/
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
if (intel_dp->num_sink_rates)
intel_dp->use_rate_select = true;
else
intel_dp_set_sink_rates(intel_dp);
intel_dp_set_max_sink_lane_count(intel_dp);
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
2018-10-31 00:19:19 +00:00
/* Read the eDP DSC DPCD registers */
if (HAS_DSC(dev_priv))
intel_edp_get_dsc_sink_cap(intel_dp->edp_dpcd[0],
connector);
2018-10-31 00:19:19 +00:00
/*
* If needed, program our source OUI so we can make various Intel-specific AUX services
* available (such as HDR backlight controls)
*/
intel_edp_init_source_oui(intel_dp, true);
return true;
}
static bool
intel_dp_has_sink_count(struct intel_dp *intel_dp)
{
if (!intel_dp->attached_connector)
return false;
return drm_dp_read_sink_count_cap(&intel_dp->attached_connector->base,
intel_dp->dpcd,
&intel_dp->desc);
}
static bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
int ret;
if (intel_dp_init_lttpr_and_dprx_caps(intel_dp) < 0)
return false;
/*
* Don't clobber cached eDP rates. Also skip re-reading
* the OUI/ID since we know it won't change.
*/
if (!intel_dp_is_edp(intel_dp)) {
drm_dp_read_desc(&intel_dp->aux, &intel_dp->desc,
drm_dp_is_branch(intel_dp->dpcd));
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
intel_dp_set_sink_rates(intel_dp);
intel_dp_set_max_sink_lane_count(intel_dp);
intel_dp_set_common_rates(intel_dp);
}
drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4 There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4 like before, but generate it based on DP_MAX_LINK_RATE on others. This reduces code complexity when we need to use the sink rates; they are all always in the sink_rates array. 2) Update the sink rate array whenever we read DPCD, and use the information from there. This increases code readability when we need the sink rates. 3) Disentangle fallback rate limiting from sink rates. In the code, the max rate is a dynamic property of the *link*, not of the *sink*. Do the limiting after intersecting the source and sink rates, which are static properties of the devices. This paves the way for follow-up refactoring that I've refrained from doing here to keep this change as simple as it possibly can. v2: introduce use_rate_select and handle non-confirming eDP (Ville) v3: don't clobber cached eDP rates on short pulse (Ville) Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/071bad76467f8ab2e73f3f61ad52d5a468004c71.1490712890.git.jani.nikula@intel.com
2017-03-28 14:59:05 +00:00
if (intel_dp_has_sink_count(intel_dp)) {
ret = drm_dp_read_sink_count(&intel_dp->aux);
if (ret < 0)
return false;
/*
* Sink count can change between short pulse hpd hence
* a member variable in intel_dp will track any changes
* between short pulse interrupts.
*/
intel_dp->sink_count = ret;
/*
* SINK_COUNT == 0 and DOWNSTREAM_PORT_PRESENT == 1 implies that
* a dongle is present but no display. Unless we require to know
* if a dongle is present or not, we don't need to update
* downstream port information. So, an early return here saves
* time from performing other operations which are not required.
*/
if (!intel_dp->sink_count)
return false;
}
drm/i915/dp: Extract drm_dp_read_downstream_info() We're going to be doing the same probing process in nouveau for determining downstream DP port capabilities, so let's deduplicate the work by moving i915's code for handling this into a shared helper: drm_dp_read_downstream_info(). Note that when we do this, we also do make some functional changes while we're at it: * We always clear the downstream port info before trying to read it, just to make things easier for the caller * We skip reading downstream port info if the DPCD indicates that we don't support downstream port info * We only read as many bytes as needed for the reported number of downstream ports, no sense in reading the whole thing every time v2: * Fixup logic for calculating the downstream port length to account for the fact that downstream port caps can be either 1 byte or 4 bytes long. We can actually skip fixing the max_clock/max_bpc helpers here since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway. * Fix ret code check for drm_dp_dpcd_read v5: * Change name from drm_dp_downstream_read_info() to drm_dp_read_downstream_info() * Also, add "See Also" sections for the various downstream info functions (drm_dp_read_downstream_info(), drm_dp_downstream_max_clock(), drm_dp_downstream_max_bpc()) Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826182456.322681-14-lyude@redhat.com
2020-08-26 18:24:49 +00:00
return drm_dp_read_downstream_info(&intel_dp->aux, intel_dp->dpcd,
intel_dp->downstream_ports) == 0;
}
static bool
intel_dp_can_mst(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
return i915->display.params.enable_dp_mst &&
intel_dp_mst_source_support(intel_dp) &&
drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
}
static void
intel_dp_configure_mst(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_encoder *encoder =
&dp_to_dig_port(intel_dp)->base;
bool sink_can_mst = drm_dp_read_mst_cap(&intel_dp->aux, intel_dp->dpcd);
drm_dbg_kms(&i915->drm,
"[ENCODER:%d:%s] MST support: port: %s, sink: %s, modparam: %s\n",
encoder->base.base.id, encoder->base.name,
str_yes_no(intel_dp_mst_source_support(intel_dp)),
str_yes_no(sink_can_mst),
str_yes_no(i915->display.params.enable_dp_mst));
if (!intel_dp_mst_source_support(intel_dp))
return;
intel_dp->is_mst = sink_can_mst &&
i915->display.params.enable_dp_mst;
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
2014-05-02 04:02:48 +00:00
}
static bool
intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8 *esi)
2014-05-02 04:02:48 +00:00
{
return drm_dp_dpcd_read(&intel_dp->aux, DP_SINK_COUNT_ESI, esi, 4) == 4;
2014-05-02 04:02:48 +00:00
}
static bool intel_dp_ack_sink_irq_esi(struct intel_dp *intel_dp, u8 esi[4])
{
int retry;
for (retry = 0; retry < 3; retry++) {
if (drm_dp_dpcd_write(&intel_dp->aux, DP_SINK_COUNT_ESI + 1,
&esi[1], 3) == 3)
return true;
}
return false;
}
drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA When BT.2020 Colorimetry output is used for DP, we should program BT.2020 Colorimetry to MSA and VSC SDP. In order to handle colorspace of drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp(). And it also rename intel_ddi_set_pipe_settings() to intel_ddi_set_dp_msa(). As per DP 1.4a spec section 2.2.4 [MSA Data Transport] The MSA data that the DP Source device transports for reproducing the main video stream. Attribute data is sent once per frame during the main video stream’s vertical blanking period. In order to distinguish needed colorimetry for VSC SDP, it adds intel_dp_needs_vsc_sdp function. If the output colorspace requires vsc sdp or output format is YCbCr 4:2:0, it uses MSA with VSC SDP. As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color Encoding Format and Content Color Gamut] while sending BT.2020 Colorimetry signals we should program MSA MISC1 fields which indicate VSC SDP for the Pixel Encoding/Colorimetry Format. v2: Remove useless parentheses v3: Addressed review comments from Ville - In order to checking output format and output colorspace on intel_dp_needs_vsc_sdp(), it passes entire intel_crtc_state struct value. - Remove a pointless variable. v9: Addressed review comments from Ville - Remove a duplicated output color space from intel_crtc_state. - In order to handle colorspace of drm_connector_state, it moves a calling of intel_ddi_set_pipe_settings() function into intel_ddi_pre_enable_dp(). Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919195311.13972-3-gwan-gyeong.mun@intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2019-09-19 19:53:05 +00:00
bool
intel_dp_needs_vsc_sdp(const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
/*
* As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication
* of Color Encoding Format and Content Color Gamut], in order to
* sending YCBCR 420 or HDR BT.2020 signals we should use DP VSC SDP.
*/
if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
return true;
switch (conn_state->colorspace) {
case DRM_MODE_COLORIMETRY_SYCC_601:
case DRM_MODE_COLORIMETRY_OPYCC_601:
case DRM_MODE_COLORIMETRY_BT2020_YCC:
case DRM_MODE_COLORIMETRY_BT2020_RGB:
case DRM_MODE_COLORIMETRY_BT2020_CYCC:
return true;
default:
break;
}
return false;
}
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
static ssize_t intel_dp_vsc_sdp_pack(const struct drm_dp_vsc_sdp *vsc,
struct dp_sdp *sdp, size_t size)
{
size_t length = sizeof(struct dp_sdp);
if (size < length)
return -ENOSPC;
memset(sdp, 0, size);
/*
* Prepare VSC Header for SU as per DP 1.4a spec, Table 2-119
* VSC SDP Header Bytes
*/
sdp->sdp_header.HB0 = 0; /* Secondary-Data Packet ID = 0 */
sdp->sdp_header.HB1 = vsc->sdp_type; /* Secondary-data Packet Type */
sdp->sdp_header.HB2 = vsc->revision; /* Revision Number */
sdp->sdp_header.HB3 = vsc->length; /* Number of Valid Data Bytes */
drm/i915/panelreplay: Initializaton and compute config for panel replay Modify existing PSR implementation to enable panel replay feature of DP 2.0 which is similar to PSR feature of EDP panel. There is different DPCD address to check panel capability compare to PSR and vsc sdp header is different. v1: Initial version. v2: - Set source_panel_replay_support flag under HAS_PANEL_REPLAY() condition check. [Jouni] - Code restructured around intel_panel_replay_init and renamed to intel_panel_replay_init_dpcd. [Jouni] - Remove the initial code modification around has_psr2 flag. [Jouni] - Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to enable in intel_psr_post_plane_update. [Jouni] v3: - Initialize both psr and panel-replay. [Jouni] - Initialize both panel replay and psr if detected. [Jouni] - Refactoring psr function by introducing _psr_compute_config(). [Jouni] - Add check for !is_edp while deriving source_panel_replay_support. [Jouni] - Enable panel replay dpcd initialization in a separate patch. [Jouni] v4: - HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni] - Set either panel replay source support or psr. [Jouni] v5: - HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni] - Move psr related code to intel_psr.c. [Jani] - Reset sink_panel_replay_support flag during disconnection. [Jani] v6: return statement restored which is removed by misatke. [Jouni] v7: cosmetic changes. [Arun] Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108072303.3414118-4-animesh.manna@intel.com
2023-11-08 07:23:00 +00:00
if (vsc->revision == 0x6) {
sdp->db[0] = 1;
sdp->db[3] = 1;
}
/*
drm/i915/panelreplay: Initializaton and compute config for panel replay Modify existing PSR implementation to enable panel replay feature of DP 2.0 which is similar to PSR feature of EDP panel. There is different DPCD address to check panel capability compare to PSR and vsc sdp header is different. v1: Initial version. v2: - Set source_panel_replay_support flag under HAS_PANEL_REPLAY() condition check. [Jouni] - Code restructured around intel_panel_replay_init and renamed to intel_panel_replay_init_dpcd. [Jouni] - Remove the initial code modification around has_psr2 flag. [Jouni] - Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to enable in intel_psr_post_plane_update. [Jouni] v3: - Initialize both psr and panel-replay. [Jouni] - Initialize both panel replay and psr if detected. [Jouni] - Refactoring psr function by introducing _psr_compute_config(). [Jouni] - Add check for !is_edp while deriving source_panel_replay_support. [Jouni] - Enable panel replay dpcd initialization in a separate patch. [Jouni] v4: - HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni] - Set either panel replay source support or psr. [Jouni] v5: - HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni] - Move psr related code to intel_psr.c. [Jani] - Reset sink_panel_replay_support flag during disconnection. [Jani] v6: return statement restored which is removed by misatke. [Jouni] v7: cosmetic changes. [Arun] Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108072303.3414118-4-animesh.manna@intel.com
2023-11-08 07:23:00 +00:00
* Revision 0x5 and revision 0x7 supports Pixel Encoding/Colorimetry
* Format as per DP 1.4a spec and DP 2.0 respectively.
*/
drm/i915/panelreplay: Initializaton and compute config for panel replay Modify existing PSR implementation to enable panel replay feature of DP 2.0 which is similar to PSR feature of EDP panel. There is different DPCD address to check panel capability compare to PSR and vsc sdp header is different. v1: Initial version. v2: - Set source_panel_replay_support flag under HAS_PANEL_REPLAY() condition check. [Jouni] - Code restructured around intel_panel_replay_init and renamed to intel_panel_replay_init_dpcd. [Jouni] - Remove the initial code modification around has_psr2 flag. [Jouni] - Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to enable in intel_psr_post_plane_update. [Jouni] v3: - Initialize both psr and panel-replay. [Jouni] - Initialize both panel replay and psr if detected. [Jouni] - Refactoring psr function by introducing _psr_compute_config(). [Jouni] - Add check for !is_edp while deriving source_panel_replay_support. [Jouni] - Enable panel replay dpcd initialization in a separate patch. [Jouni] v4: - HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni] - Set either panel replay source support or psr. [Jouni] v5: - HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni] - Move psr related code to intel_psr.c. [Jani] - Reset sink_panel_replay_support flag during disconnection. [Jani] v6: return statement restored which is removed by misatke. [Jouni] v7: cosmetic changes. [Arun] Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108072303.3414118-4-animesh.manna@intel.com
2023-11-08 07:23:00 +00:00
if (!(vsc->revision == 0x5 || vsc->revision == 0x7))
goto out;
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
/* VSC SDP Payload for DB16 through DB18 */
/* Pixel Encoding and Colorimetry Formats */
sdp->db[16] = (vsc->pixelformat & 0xf) << 4; /* DB16[7:4] */
sdp->db[16] |= vsc->colorimetry & 0xf; /* DB16[3:0] */
switch (vsc->bpc) {
case 6:
/* 6bpc: 0x0 */
break;
case 8:
sdp->db[17] = 0x1; /* DB17[3:0] */
break;
case 10:
sdp->db[17] = 0x2;
break;
case 12:
sdp->db[17] = 0x3;
break;
case 16:
sdp->db[17] = 0x4;
break;
default:
MISSING_CASE(vsc->bpc);
break;
}
/* Dynamic Range and Component Bit Depth */
if (vsc->dynamic_range == DP_DYNAMIC_RANGE_CTA)
sdp->db[17] |= 0x80; /* DB17[7] */
/* Content Type */
sdp->db[18] = vsc->content_type & 0x7;
out:
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
return length;
}
static ssize_t
intel_dp_hdr_metadata_infoframe_sdp_pack(struct drm_i915_private *i915,
const struct hdmi_drm_infoframe *drm_infoframe,
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
struct dp_sdp *sdp,
size_t size)
{
size_t length = sizeof(struct dp_sdp);
const int infoframe_size = HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE;
unsigned char buf[HDMI_INFOFRAME_HEADER_SIZE + HDMI_DRM_INFOFRAME_SIZE];
ssize_t len;
if (size < length)
return -ENOSPC;
memset(sdp, 0, size);
len = hdmi_drm_infoframe_pack_only(drm_infoframe, buf, sizeof(buf));
if (len < 0) {
drm_dbg_kms(&i915->drm, "buffer size is smaller than hdr metadata infoframe\n");
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
return -ENOSPC;
}
if (len != infoframe_size) {
drm_dbg_kms(&i915->drm, "wrong static hdr metadata size\n");
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
return -ENOSPC;
}
/*
* Set up the infoframe sdp packet for HDR static metadata.
* Prepare VSC Header for SU as per DP 1.4a spec,
* Table 2-100 and Table 2-101
*/
/* Secondary-Data Packet ID, 00h for non-Audio INFOFRAME */
sdp->sdp_header.HB0 = 0;
/*
* Packet Type 80h + Non-audio INFOFRAME Type value
* HDMI_INFOFRAME_TYPE_DRM: 0x87
* - 80h + Non-audio INFOFRAME Type value
* - InfoFrame Type: 0x07
* [CTA-861-G Table-42 Dynamic Range and Mastering InfoFrame]
*/
sdp->sdp_header.HB1 = drm_infoframe->type;
/*
* Least Significant Eight Bits of (Data Byte Count 1)
* infoframe_size - 1
*/
sdp->sdp_header.HB2 = 0x1D;
/* INFOFRAME SDP Version Number */
sdp->sdp_header.HB3 = (0x13 << 2);
/* CTA Header Byte 2 (INFOFRAME Version Number) */
sdp->db[0] = drm_infoframe->version;
/* CTA Header Byte 3 (Length of INFOFRAME): HDMI_DRM_INFOFRAME_SIZE */
sdp->db[1] = drm_infoframe->length;
/*
* Copy HDMI_DRM_INFOFRAME_SIZE size from a buffer after
* HDMI_INFOFRAME_HEADER_SIZE
*/
BUILD_BUG_ON(sizeof(sdp->db) < HDMI_DRM_INFOFRAME_SIZE + 2);
memcpy(&sdp->db[2], &buf[HDMI_INFOFRAME_HEADER_SIZE],
HDMI_DRM_INFOFRAME_SIZE);
/*
* Size of DP infoframe sdp packet for HDR static metadata consists of
* - DP SDP Header(struct dp_sdp_header): 4 bytes
* - Two Data Blocks: 2 bytes
* CTA Header Byte2 (INFOFRAME Version Number)
* CTA Header Byte3 (Length of INFOFRAME)
* - HDMI_DRM_INFOFRAME_SIZE: 26 bytes
*
* Prior to GEN11's GMP register size is identical to DP HDR static metadata
* infoframe size. But GEN11+ has larger than that size, write_infoframe
* will pad rest of the size.
*/
return sizeof(struct dp_sdp_header) + 2 + HDMI_DRM_INFOFRAME_SIZE;
}
static void intel_write_dp_sdp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
unsigned int type)
{
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct dp_sdp sdp = {};
ssize_t len;
if ((crtc_state->infoframes.enable &
intel_hdmi_infoframe_enable(type)) == 0)
return;
switch (type) {
case DP_SDP_VSC:
len = intel_dp_vsc_sdp_pack(&crtc_state->infoframes.vsc, &sdp,
sizeof(sdp));
break;
case HDMI_PACKET_TYPE_GAMUT_METADATA:
len = intel_dp_hdr_metadata_infoframe_sdp_pack(dev_priv,
&crtc_state->infoframes.drm.drm,
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
&sdp, sizeof(sdp));
break;
default:
MISSING_CASE(type);
return;
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
}
if (drm_WARN_ON(&dev_priv->drm, len < 0))
return;
dig_port->write_infoframe(encoder, crtc_state, type, &sdp, len);
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
}
void intel_write_dp_vsc_sdp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_dp_vsc_sdp *vsc)
{
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct dp_sdp sdp = {};
ssize_t len;
len = intel_dp_vsc_sdp_pack(vsc, &sdp, sizeof(sdp));
if (drm_WARN_ON(&dev_priv->drm, len < 0))
return;
dig_port->write_infoframe(encoder, crtc_state, DP_SDP_VSC,
&sdp, len);
}
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
void intel_dp_set_infoframes(struct intel_encoder *encoder,
bool enable,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
u32 dip_enable = VIDEO_DIP_ENABLE_AVI_HSW | VIDEO_DIP_ENABLE_GCP_HSW |
VIDEO_DIP_ENABLE_VS_HSW | VIDEO_DIP_ENABLE_GMP_HSW |
VIDEO_DIP_ENABLE_SPD_HSW | VIDEO_DIP_ENABLE_DRM_GLK;
u32 val = intel_de_read(dev_priv, reg) & ~dip_enable;
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
/* TODO: Sanitize DSC enabling wrt. intel_dsc_dp_pps_write(). */
if (!enable && HAS_DSC(dev_priv))
val &= ~VDIP_ENABLE_PPS;
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
/* When PSR is enabled, this routine doesn't disable VSC DIP */
if (!crtc_state->has_psr)
val &= ~VIDEO_DIP_ENABLE_VSC_HSW;
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
intel_de_write(dev_priv, reg, val);
intel_de_posting_read(dev_priv, reg);
if (!enable)
return;
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
/* When PSR is enabled, VSC SDP is handled by PSR routine */
if (!crtc_state->has_psr)
drm/i915/dp: Add writing of DP SDPs It adds routines that write DP VSC SDP and DP HDR Metadata Infoframe SDP. In order to pack DP VSC SDP, it adds intel_dp_vsc_sdp_pack() function. It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Bytes] and [Table 2-117: VSC SDP Payload for DB16 through DB18] In order to pack DP HDR Metadata Infoframe SDP, it adds intel_dp_hdr_metadata_infoframe_sdp_pack() function. And it follows DP 1.4a spec. ([Table 2-125: INFOFRAME SDP v1.2 Header Bytes] and [Table 2-126: INFOFRAME SDP v1.2 Payload Data Bytes - DB0 through DB31]) and CTA-861-G spec. [Table-42 Dynamic Range and Mastering InfoFrame]. A mechanism and a naming rule of intel_dp_set_infoframes() function references intel_encoder->set_infoframes() of intel_hdmi.c . VSC SDP is used for PSR and Pixel Encoding and Colorimetry Formats cases. Because PSR routine has its own routine of writing a VSC SDP, when the PSR is enabled, intel_dp_set_infoframes() does not write a VSC SDP. v3: - Explicitly disable unused DIPs (AVI, GCP, VS, SPD, DRM. They will be used for HDMI), when intel_dp_set_infoframes() function will be called. - Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp. v4: Use struct drm_device logging macros v5: - use intel_de_*() functions for register access - Addressed review comments from Uma Polish commit message and comments Add 6bpc to packing of VSC SDP Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211074657.231405-5-gwan-gyeong.mun@intel.com
2020-02-11 07:46:43 +00:00
intel_write_dp_sdp(encoder, crtc_state, DP_SDP_VSC);
intel_write_dp_sdp(encoder, crtc_state, HDMI_PACKET_TYPE_GAMUT_METADATA);
}
static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp *vsc,
const void *buffer, size_t size)
{
const struct dp_sdp *sdp = buffer;
if (size < sizeof(struct dp_sdp))
return -EINVAL;
memset(vsc, 0, sizeof(*vsc));
if (sdp->sdp_header.HB0 != 0)
return -EINVAL;
if (sdp->sdp_header.HB1 != DP_SDP_VSC)
return -EINVAL;
vsc->sdp_type = sdp->sdp_header.HB1;
vsc->revision = sdp->sdp_header.HB2;
vsc->length = sdp->sdp_header.HB3;
if ((sdp->sdp_header.HB2 == 0x2 && sdp->sdp_header.HB3 == 0x8) ||
(sdp->sdp_header.HB2 == 0x4 && sdp->sdp_header.HB3 == 0xe)) {
/*
* - HB2 = 0x2, HB3 = 0x8
* VSC SDP supporting 3D stereo + PSR
* - HB2 = 0x4, HB3 = 0xe
* VSC SDP supporting 3D stereo + PSR2 with Y-coordinate of
* first scan line of the SU region (applies to eDP v1.4b
* and higher).
*/
return 0;
} else if (sdp->sdp_header.HB2 == 0x5 && sdp->sdp_header.HB3 == 0x13) {
/*
* - HB2 = 0x5, HB3 = 0x13
* VSC SDP supporting 3D stereo + PSR2 + Pixel Encoding/Colorimetry
* Format.
*/
vsc->pixelformat = (sdp->db[16] >> 4) & 0xf;
vsc->colorimetry = sdp->db[16] & 0xf;
vsc->dynamic_range = (sdp->db[17] >> 7) & 0x1;
switch (sdp->db[17] & 0x7) {
case 0x0:
vsc->bpc = 6;
break;
case 0x1:
vsc->bpc = 8;
break;
case 0x2:
vsc->bpc = 10;
break;
case 0x3:
vsc->bpc = 12;
break;
case 0x4:
vsc->bpc = 16;
break;
default:
MISSING_CASE(sdp->db[17] & 0x7);
return -EINVAL;
}
vsc->content_type = sdp->db[18] & 0x7;
} else {
return -EINVAL;
}
return 0;
}
static int
intel_dp_hdr_metadata_infoframe_sdp_unpack(struct hdmi_drm_infoframe *drm_infoframe,
const void *buffer, size_t size)
{
int ret;
const struct dp_sdp *sdp = buffer;
if (size < sizeof(struct dp_sdp))
return -EINVAL;
if (sdp->sdp_header.HB0 != 0)
return -EINVAL;
if (sdp->sdp_header.HB1 != HDMI_INFOFRAME_TYPE_DRM)
return -EINVAL;
/*
* Least Significant Eight Bits of (Data Byte Count 1)
* 1Dh (i.e., Data Byte Count = 30 bytes).
*/
if (sdp->sdp_header.HB2 != 0x1D)
return -EINVAL;
/* Most Significant Two Bits of (Data Byte Count 1), Clear to 00b. */
if ((sdp->sdp_header.HB3 & 0x3) != 0)
return -EINVAL;
/* INFOFRAME SDP Version Number */
if (((sdp->sdp_header.HB3 >> 2) & 0x3f) != 0x13)
return -EINVAL;
/* CTA Header Byte 2 (INFOFRAME Version Number) */
if (sdp->db[0] != 1)
return -EINVAL;
/* CTA Header Byte 3 (Length of INFOFRAME): HDMI_DRM_INFOFRAME_SIZE */
if (sdp->db[1] != HDMI_DRM_INFOFRAME_SIZE)
return -EINVAL;
ret = hdmi_drm_infoframe_unpack_only(drm_infoframe, &sdp->db[2],
HDMI_DRM_INFOFRAME_SIZE);
return ret;
}
static void intel_read_dp_vsc_sdp(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
struct drm_dp_vsc_sdp *vsc)
{
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
unsigned int type = DP_SDP_VSC;
struct dp_sdp sdp = {};
int ret;
/* When PSR is enabled, VSC SDP is handled by PSR routine */
if (crtc_state->has_psr)
return;
if ((crtc_state->infoframes.enable &
intel_hdmi_infoframe_enable(type)) == 0)
return;
dig_port->read_infoframe(encoder, crtc_state, type, &sdp, sizeof(sdp));
ret = intel_dp_vsc_sdp_unpack(vsc, &sdp, sizeof(sdp));
if (ret)
drm_dbg_kms(&dev_priv->drm, "Failed to unpack DP VSC SDP\n");
}
static void intel_read_dp_hdr_metadata_infoframe_sdp(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
struct hdmi_drm_infoframe *drm_infoframe)
{
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
unsigned int type = HDMI_PACKET_TYPE_GAMUT_METADATA;
struct dp_sdp sdp = {};
int ret;
if ((crtc_state->infoframes.enable &
intel_hdmi_infoframe_enable(type)) == 0)
return;
dig_port->read_infoframe(encoder, crtc_state, type, &sdp,
sizeof(sdp));
ret = intel_dp_hdr_metadata_infoframe_sdp_unpack(drm_infoframe, &sdp,
sizeof(sdp));
if (ret)
drm_dbg_kms(&dev_priv->drm,
"Failed to unpack DP HDR Metadata Infoframe SDP\n");
}
void intel_read_dp_sdp(struct intel_encoder *encoder,
struct intel_crtc_state *crtc_state,
unsigned int type)
{
switch (type) {
case DP_SDP_VSC:
intel_read_dp_vsc_sdp(encoder, crtc_state,
&crtc_state->infoframes.vsc);
break;
case HDMI_PACKET_TYPE_GAMUT_METADATA:
intel_read_dp_hdr_metadata_infoframe_sdp(encoder, crtc_state,
&crtc_state->infoframes.drm.drm);
break;
default:
MISSING_CASE(type);
break;
}
}
static u8 intel_dp_autotest_link_training(struct intel_dp *intel_dp)
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
int status = 0;
int test_link_rate;
u8 test_lane_count, test_link_bw;
/* (DP CTS 1.2)
* 4.3.1.11
*/
/* Read the TEST_LANE_COUNT and TEST_LINK_RTAE fields (DP CTS 3.1.4) */
status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_LANE_COUNT,
&test_lane_count);
if (status <= 0) {
drm_dbg_kms(&i915->drm, "Lane count read failed\n");
return DP_TEST_NAK;
}
test_lane_count &= DP_MAX_LANE_COUNT_MASK;
status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_LINK_RATE,
&test_link_bw);
if (status <= 0) {
drm_dbg_kms(&i915->drm, "Link Rate read failed\n");
return DP_TEST_NAK;
}
test_link_rate = drm_dp_bw_code_to_link_rate(test_link_bw);
/* Validate the requested link rate and lane count */
if (!intel_dp_link_params_valid(intel_dp, test_link_rate,
test_lane_count))
return DP_TEST_NAK;
intel_dp->compliance.test_lane_count = test_lane_count;
intel_dp->compliance.test_link_rate = test_link_rate;
return DP_TEST_ACK;
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
}
static u8 intel_dp_autotest_video_pattern(struct intel_dp *intel_dp)
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 test_pattern;
u8 test_misc;
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
__be16 h_width, v_height;
int status = 0;
/* Read the TEST_PATTERN (DP CTS 3.1.5) */
status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_PATTERN,
&test_pattern);
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
if (status <= 0) {
drm_dbg_kms(&i915->drm, "Test pattern read failed\n");
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
return DP_TEST_NAK;
}
if (test_pattern != DP_COLOR_RAMP)
return DP_TEST_NAK;
status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_H_WIDTH_HI,
&h_width, 2);
if (status <= 0) {
drm_dbg_kms(&i915->drm, "H Width read failed\n");
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
return DP_TEST_NAK;
}
status = drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_V_HEIGHT_HI,
&v_height, 2);
if (status <= 0) {
drm_dbg_kms(&i915->drm, "V Height read failed\n");
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
return DP_TEST_NAK;
}
status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_MISC0,
&test_misc);
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
if (status <= 0) {
drm_dbg_kms(&i915->drm, "TEST MISC read failed\n");
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
return DP_TEST_NAK;
}
if ((test_misc & DP_TEST_COLOR_FORMAT_MASK) != DP_COLOR_FORMAT_RGB)
return DP_TEST_NAK;
if (test_misc & DP_TEST_DYNAMIC_RANGE_CEA)
return DP_TEST_NAK;
switch (test_misc & DP_TEST_BIT_DEPTH_MASK) {
case DP_TEST_BIT_DEPTH_6:
intel_dp->compliance.test_data.bpc = 6;
break;
case DP_TEST_BIT_DEPTH_8:
intel_dp->compliance.test_data.bpc = 8;
break;
default:
return DP_TEST_NAK;
}
intel_dp->compliance.test_data.video_pattern = test_pattern;
intel_dp->compliance.test_data.hdisplay = be16_to_cpu(h_width);
intel_dp->compliance.test_data.vdisplay = be16_to_cpu(v_height);
/* Set test active flag here so userspace doesn't interrupt things */
intel_dp->compliance.test_active = true;
drm/i915: Add support for DP Video pattern compliance tests The intel_dp_autotest_video_pattern() function gets invoked through the compliance test handler on a HPD short pulse if the test type is set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers reads to read the requested test pattern, video pattern resolution, frame rate and bits per color value. The results of this analysis are handed off to userspace so that the userspace app can set the video pattern mode appropriately for the test result/response. When the test is requested with specific BPC value, we read the BPC value from the DPCD register. If this BPC value in intel_dp structure has a non-zero value and we're on a display port connector, then we use the value to calculate the bpp for the pipe. Also in this case if its a 18bpp video pattern request, then we force the dithering on pipe to be disabled since it causes CRC mismatches. The compliance_test_active flag is set at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. v5: * Remove test_result variable * Populate the compliance test data at the end of the function (Jani Nikula) v4: *Return TEST_NAK on read failures and invalid values (Jani Nikula) * Address CRC mismatch errors v3: * Use the updated properly shifted bit definitions (Jani Nikula) * Force dithering to be disabled on 18bpp compliance test request (Manasi Navare) v2: * Updated the DPCD Register reads based on proper defines in header (Jani Nikula) * Squahsed the patch that forced the pipe bpp to compliance test bpp (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1485274909-17470-1-git-send-email-manasi.d.navare@intel.com
2017-01-24 16:21:49 +00:00
return DP_TEST_ACK;
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
}
static u8 intel_dp_autotest_edid(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 test_result = DP_TEST_ACK;
drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 14:48:20 +00:00
struct intel_connector *intel_connector = intel_dp->attached_connector;
struct drm_connector *connector = &intel_connector->base;
if (intel_connector->detect_edid == NULL ||
connector->edid_corrupt ||
drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 14:48:20 +00:00
intel_dp->aux.i2c_defer_count > 6) {
/* Check EDID read for NACKs, DEFERs and corruption
* (DP CTS 1.2 Core r1.1)
* 4.2.2.4 : Failed EDID read, I2C_NAK
* 4.2.2.5 : Failed EDID read, I2C_DEFER
* 4.2.2.6 : EDID corruption detected
* Use failsafe mode for all cases
*/
if (intel_dp->aux.i2c_nack_count > 0 ||
intel_dp->aux.i2c_defer_count > 0)
drm_dbg_kms(&i915->drm,
"EDID read had %d NACKs, %d DEFERs\n",
intel_dp->aux.i2c_nack_count,
intel_dp->aux.i2c_defer_count);
intel_dp->compliance.test_data.edid = INTEL_DP_RESOLUTION_FAILSAFE;
drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 14:48:20 +00:00
} else {
/* FIXME: Get rid of drm_edid_raw() */
const struct edid *block = drm_edid_raw(intel_connector->detect_edid);
/* We have to write the checksum of the last block read */
block += block->extensions;
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_EDID_CHECKSUM,
block->checksum) <= 0)
drm_dbg_kms(&i915->drm,
"Failed to write EDID checksum\n");
drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 14:48:20 +00:00
test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE;
intel_dp->compliance.test_data.edid = INTEL_DP_RESOLUTION_PREFERRED;
drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 14:48:20 +00:00
}
/* Set test active flag here so userspace doesn't interrupt things */
intel_dp->compliance.test_active = true;
drm/i915: Implement the intel_dp_autotest_edid function for DP EDID complaince tests Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-05-04 14:48:20 +00:00
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
return test_result;
}
static void intel_dp_phy_pattern_update(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv =
to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
struct drm_dp_phy_test_params *data =
&intel_dp->compliance.test_data.phytest;
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
enum pipe pipe = crtc->pipe;
u32 pattern_val;
switch (data->phy_pattern) {
case DP_PHY_TEST_PATTERN_NONE:
drm_dbg_kms(&dev_priv->drm, "Disable Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
break;
case DP_PHY_TEST_PATTERN_D10_2:
drm_dbg_kms(&dev_priv->drm, "Set D10.2 Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
break;
case DP_PHY_TEST_PATTERN_ERROR_COUNT:
drm_dbg_kms(&dev_priv->drm, "Set Error Count Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE |
DDI_DP_COMP_CTL_SCRAMBLED_0);
break;
case DP_PHY_TEST_PATTERN_PRBS7:
drm_dbg_kms(&dev_priv->drm, "Set PRBS7 Phy Test Pattern\n");
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
break;
case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
/*
* FIXME: Ideally pattern should come from DPCD 0x250. As
* current firmware of DPR-100 could not set it, so hardcoding
* now for complaince test.
*/
drm_dbg_kms(&dev_priv->drm,
"Set 80Bit Custom Phy Test Pattern 0x3e0f83e0 0x0f83e0f8 0x0000f83e\n");
pattern_val = 0x3e0f83e0;
intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
pattern_val = 0x0f83e0f8;
intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
pattern_val = 0x0000f83e;
intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE |
DDI_DP_COMP_CTL_CUSTOM80);
break;
case DP_PHY_TEST_PATTERN_CP2520:
/*
* FIXME: Ideally pattern should come from DPCD 0x24A. As
* current firmware of DPR-100 could not set it, so hardcoding
* now for complaince test.
*/
drm_dbg_kms(&dev_priv->drm, "Set HBR2 compliance Phy Test Pattern\n");
pattern_val = 0xFB;
intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
pattern_val);
break;
default:
WARN(1, "Invalid Phy Test Pattern\n");
}
}
static void intel_dp_process_phy_request(struct intel_dp *intel_dp,
const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct drm_dp_phy_test_params *data =
&intel_dp->compliance.test_data.phytest;
u8 link_status[DP_LINK_STATUS_SIZE];
drm/i915: Switch to LTTPR non-transparent mode link training The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
2020-10-07 17:09:17 +00:00
if (drm_dp_dpcd_read_phy_link_status(&intel_dp->aux, DP_PHY_DPRX,
link_status) < 0) {
drm_dbg_kms(&i915->drm, "failed to get link status\n");
return;
}
/* retrieve vswing & pre-emphasis setting */
drm/i915: Switch to LTTPR non-transparent mode link training The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
2020-10-07 17:09:17 +00:00
intel_dp_get_adjust_train(intel_dp, crtc_state, DP_PHY_DPRX,
link_status);
intel_dp_set_signal_levels(intel_dp, crtc_state, DP_PHY_DPRX);
intel_dp_phy_pattern_update(intel_dp, crtc_state);
drm_dp_dpcd_write(&intel_dp->aux, DP_TRAINING_LANE0_SET,
intel_dp->train_set, crtc_state->lane_count);
drm_dp_set_phy_test_pattern(&intel_dp->aux, data,
intel_dp->dpcd[DP_DPCD_REV]);
}
static u8 intel_dp_autotest_phy_pattern(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct drm_dp_phy_test_params *data =
&intel_dp->compliance.test_data.phytest;
if (drm_dp_get_phy_test_pattern(&intel_dp->aux, data)) {
drm_dbg_kms(&i915->drm, "DP Phy Test pattern AUX read failure\n");
return DP_TEST_NAK;
}
/* Set test active flag here so userspace doesn't interrupt things */
intel_dp->compliance.test_active = true;
return DP_TEST_ACK;
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
}
static void intel_dp_handle_test_request(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 response = DP_TEST_NAK;
u8 request = 0;
int status;
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
status = drm_dp_dpcd_readb(&intel_dp->aux, DP_TEST_REQUEST, &request);
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
if (status <= 0) {
drm_dbg_kms(&i915->drm,
"Could not read test request from sink\n");
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
goto update_status;
}
switch (request) {
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
case DP_TEST_LINK_TRAINING:
drm_dbg_kms(&i915->drm, "LINK_TRAINING test requested\n");
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
response = intel_dp_autotest_link_training(intel_dp);
break;
case DP_TEST_LINK_VIDEO_PATTERN:
drm_dbg_kms(&i915->drm, "TEST_PATTERN test requested\n");
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
response = intel_dp_autotest_video_pattern(intel_dp);
break;
case DP_TEST_LINK_EDID_READ:
drm_dbg_kms(&i915->drm, "EDID test requested\n");
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
response = intel_dp_autotest_edid(intel_dp);
break;
case DP_TEST_LINK_PHY_TEST_PATTERN:
drm_dbg_kms(&i915->drm, "PHY_PATTERN test requested\n");
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
response = intel_dp_autotest_phy_pattern(intel_dp);
break;
default:
drm_dbg_kms(&i915->drm, "Invalid test request '%02x'\n",
request);
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
break;
}
if (response & DP_TEST_ACK)
intel_dp->compliance.test_type = request;
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
update_status:
status = drm_dp_dpcd_writeb(&intel_dp->aux, DP_TEST_RESPONSE, response);
drm/i915: Add automated testing support for Displayport compliance testing Add the skeleton framework for supporting automation for Displayport compliance testing. This patch adds the necessary framework for the source device to appropriately respond to test automation requests from a sink device. V2: - Addressed previous mailing list feedback - Fixed compilation issue (struct members declared in a later patch) - Updated debug messages to be more accurate - Added status checks for the DPCD read/write calls - Removed excess comments and debug messages - Fixed debug message compilation warnings - Fixed compilation issue with missing variables - Updated link training autotest to ACK V3: - Fixed the checks on the DPCD return code to be <= 0 rather than != 0 - Removed extraneous assignment of a NAK return code in the DPCD read failure case - Changed the return in the DPCD read failure case to a goto to the exit point where the status code is written to the sink - Removed FAUX test case since it's deprecated now - Removed the compliance flag assignment in handle_test_request V4: - Moved declaration of type_type here - Removed declaration of test_data (moved to a later patch) - Added reset to 0 for compliance test variables V5: - Moved test_active variable declaration and initialization out of this patch and into the patch where it's used - Changed variable name compliance_testing_active to compliance_test_active to unify the naming convention - Added initialization for compliance_test_type variable Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-15 15:38:38 +00:00
if (status <= 0)
drm_dbg_kms(&i915->drm,
"Could not write test response to sink\n");
}
static bool intel_dp_link_ok(struct intel_dp *intel_dp,
u8 link_status[DP_LINK_STATUS_SIZE])
{
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
bool uhbr = intel_dp->link_rate >= 1000000;
bool ok;
if (uhbr)
ok = drm_dp_128b132b_lane_channel_eq_done(link_status,
intel_dp->lane_count);
else
ok = drm_dp_channel_eq_ok(link_status, intel_dp->lane_count);
if (ok)
return true;
intel_dp_dump_link_status(intel_dp, DP_PHY_DPRX, link_status);
drm_dbg_kms(&i915->drm,
"[ENCODER:%d:%s] %s link not ok, retraining\n",
encoder->base.base.id, encoder->base.name,
uhbr ? "128b/132b" : "8b/10b");
return false;
}
static void
intel_dp_mst_hpd_irq(struct intel_dp *intel_dp, u8 *esi, u8 *ack)
{
bool handled = false;
drm/dp_mst: Clear MSG_RDY flag before sending new message [Why] The sequence for collecting down_reply from source perspective should be: Request_n->repeat (get partial reply of Request_n->clear message ready flag to ack DPRX that the message is received) till all partial replies for Request_n are received->new Request_n+1. Now there is chance that drm_dp_mst_hpd_irq() will fire new down request in the tx queue when the down reply is incomplete. Source is restricted to generate interveleaved message transactions so we should avoid it. Also, while assembling partial reply packets, reading out DPCD DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be wrapped up as a complete operation for reading out a reply packet. Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might be risky. e.g. If the reply of the new request has overwritten the DPRX DOWN_REP Sideband MSG buffer before source writing one to clear DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply for the new request. Should handle the up request in the same way. [How] Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might trigger drm_dp_mst_kick_tx() only when there is no on going message transaction. Changes since v1: * Reworked on review comments received -> Adjust the fix to let driver explicitly kick off new down request when mst irq event is handled and acked -> Adjust the commit message Changes since v2: * Adjust the commit message * Adjust the naming of the divided 2 functions and add a new input parameter "ack". * Adjust code flow as per review comments. Changes since v3: * Update the function description of drm_dp_mst_hpd_irq_handle_event Changes since v4: * Change ack of drm_dp_mst_hpd_irq_handle_event() to be an array align the size of esi[] Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-17 09:08:12 +00:00
drm_dp_mst_hpd_irq_handle_event(&intel_dp->mst_mgr, esi, ack, &handled);
if (esi[1] & DP_CP_IRQ) {
intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
ack[1] |= DP_CP_IRQ;
}
}
static bool intel_dp_mst_link_status(struct intel_dp *intel_dp)
{
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
u8 link_status[DP_LINK_STATUS_SIZE] = {};
const size_t esi_link_status_size = DP_LINK_STATUS_SIZE - 2;
if (drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS_ESI, link_status,
esi_link_status_size) != esi_link_status_size) {
drm_err(&i915->drm,
"[ENCODER:%d:%s] Failed to read link status\n",
encoder->base.base.id, encoder->base.name);
return false;
}
return intel_dp_link_ok(intel_dp, link_status);
}
/**
* intel_dp_check_mst_status - service any pending MST interrupts, check link status
* @intel_dp: Intel DP struct
*
* Read any pending MST interrupts, call MST core to handle these and ack the
* interrupts. Check if the main and AUX link state is ok.
*
* Returns:
* - %true if pending interrupts were serviced (or no interrupts were
* pending) w/o detecting an error condition.
* - %false if an error condition - like AUX failure or a loss of link - is
* detected, which needs servicing from the hotplug work.
*/
static bool
2014-05-02 04:02:48 +00:00
intel_dp_check_mst_status(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
bool link_ok = true;
drm_WARN_ON_ONCE(&i915->drm, intel_dp->active_mst_links < 0);
for (;;) {
u8 esi[4] = {};
u8 ack[4] = {};
if (!intel_dp_get_sink_irq_esi(intel_dp, esi)) {
drm_dbg_kms(&i915->drm,
"failed to get ESI - device may have failed\n");
link_ok = false;
break;
}
2014-05-02 04:02:48 +00:00
drm_dbg_kms(&i915->drm, "DPRX ESI: %4ph\n", esi);
if (intel_dp->active_mst_links > 0 && link_ok &&
esi[3] & LINK_STATUS_CHANGED) {
if (!intel_dp_mst_link_status(intel_dp))
link_ok = false;
ack[3] |= LINK_STATUS_CHANGED;
}
2014-05-02 04:02:48 +00:00
intel_dp_mst_hpd_irq(intel_dp, esi, ack);
if (!memchr_inv(ack, 0, sizeof(ack)))
break;
if (!intel_dp_ack_sink_irq_esi(intel_dp, ack))
drm_dbg_kms(&i915->drm, "Failed to ack ESI\n");
drm/dp_mst: Clear MSG_RDY flag before sending new message [Why] The sequence for collecting down_reply from source perspective should be: Request_n->repeat (get partial reply of Request_n->clear message ready flag to ack DPRX that the message is received) till all partial replies for Request_n are received->new Request_n+1. Now there is chance that drm_dp_mst_hpd_irq() will fire new down request in the tx queue when the down reply is incomplete. Source is restricted to generate interveleaved message transactions so we should avoid it. Also, while assembling partial reply packets, reading out DPCD DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be wrapped up as a complete operation for reading out a reply packet. Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might be risky. e.g. If the reply of the new request has overwritten the DPRX DOWN_REP Sideband MSG buffer before source writing one to clear DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply for the new request. Should handle the up request in the same way. [How] Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might trigger drm_dp_mst_kick_tx() only when there is no on going message transaction. Changes since v1: * Reworked on review comments received -> Adjust the fix to let driver explicitly kick off new down request when mst irq event is handled and acked -> Adjust the commit message Changes since v2: * Adjust the commit message * Adjust the naming of the divided 2 functions and add a new input parameter "ack". * Adjust code flow as per review comments. Changes since v3: * Update the function description of drm_dp_mst_hpd_irq_handle_event Changes since v4: * Change ack of drm_dp_mst_hpd_irq_handle_event() to be an array align the size of esi[] Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2023-04-17 09:08:12 +00:00
if (ack[1] & (DP_DOWN_REP_MSG_RDY | DP_UP_REQ_MSG_RDY))
drm_dp_mst_hpd_irq_send_new_request(&intel_dp->mst_mgr);
2014-05-02 04:02:48 +00:00
}
return link_ok;
2014-05-02 04:02:48 +00:00
}
static void
intel_dp_handle_hdmi_link_status_change(struct intel_dp *intel_dp)
{
bool is_active;
u8 buf = 0;
is_active = drm_dp_pcon_hdmi_link_active(&intel_dp->aux);
if (intel_dp->frl.is_trained && !is_active) {
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PCON_HDMI_LINK_CONFIG_1, &buf) < 0)
return;
buf &= ~DP_PCON_ENABLE_HDMI_LINK;
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_PCON_HDMI_LINK_CONFIG_1, buf) < 0)
return;
drm_dp_pcon_hdmi_frl_link_error_count(&intel_dp->aux, &intel_dp->attached_connector->base);
intel_dp->frl.is_trained = false;
/* Restart FRL training or fall back to TMDS mode */
intel_dp_check_frl_training(intel_dp);
}
}
static bool
intel_dp_needs_link_retrain(struct intel_dp *intel_dp)
{
u8 link_status[DP_LINK_STATUS_SIZE];
if (!intel_dp->link_trained)
return false;
/*
* While PSR source HW is enabled, it will control main-link sending
* frames, enabling and disabling it so trying to do a retrain will fail
* as the link would or not be on or it could mix training patterns
* and frame data at the same time causing retrain to fail.
* Also when exiting PSR, HW will retrain the link anyways fixing
* any link status error.
*/
if (intel_psr_enabled(intel_dp))
return false;
drm/i915: Switch to LTTPR non-transparent mode link training The DP Standard's recommendation is to use the LTTPR non-transparent mode link training if LTTPRs are detected, so let's do this. Besides power-saving, the advantages of this are that the maximum number of LTTPRs can only be used in non-transparent mode (the limit is 5-8 in transparent mode), and it provides a way to narrow down the reason for a link training failure to a given link segment. Non-transparent mode is probably also the mode that was tested the most by the industry. The changes in this patchset: - Pass the DP PHY that is currently link trained to all LT helpers, so that these can access the correct LTTPR/DPRX DPCD registers. - During LT take into account the LTTPR common lane rate/count and the per LTTPR-PHY vswing/pre-emph limits. - Switch to LTTPR non-transparent LT mode and train each link segment according to the sequence in DP Standard v2.0 (complete CR/EQ for each segment before continuing with the next segment). v2: - Switch to non-transparent mode during connector detection, which is required before reading the per-PHY LTTPR capabilities. - Move the DP_PHY_LTTPR() macro to drm_dp_helper.h (Ville) - Use the new drm_dp_dpcd_read_phy_link_status() instead of adding the same logic to intel_dp_get_link_status(). (Ville) - Make intel_dp_lttpr_phy_caps() return a pointer to the whole array instead of a pointer to its first element. (Ville) - Add the intel_dp_phy_is_downstream_of_source() helper. (Ville) - Add a code comment about the disable->enable quirk of non-transparent mode. - Add the intel_dp_training_pattern_set_reg() helper. - Fix checkpatch/sparse warns. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201007170917.1764556-7-imre.deak@intel.com
2020-10-07 17:09:17 +00:00
if (drm_dp_dpcd_read_phy_link_status(&intel_dp->aux, DP_PHY_DPRX,
link_status) < 0)
return false;
/*
* Validate the cached values of intel_dp->link_rate and
* intel_dp->lane_count before attempting to retrain.
*
* FIXME would be nice to user the crtc state here, but since
* we need to call this from the short HPD handler that seems
* a bit hard.
*/
if (!intel_dp_link_params_valid(intel_dp, intel_dp->link_rate,
intel_dp->lane_count))
return false;
/* Retrain if link not ok */
return !intel_dp_link_ok(intel_dp, link_status);
}
static bool intel_dp_has_connector(struct intel_dp *intel_dp,
const struct drm_connector_state *conn_state)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_encoder *encoder;
enum pipe pipe;
if (!conn_state->best_encoder)
return false;
/* SST */
encoder = &dp_to_dig_port(intel_dp)->base;
if (conn_state->best_encoder == &encoder->base)
return true;
/* MST */
for_each_pipe(i915, pipe) {
encoder = &intel_dp->mst_encoders[pipe]->base;
if (conn_state->best_encoder == &encoder->base)
return true;
}
return false;
}
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
2023-05-12 19:55:13 +00:00
int intel_dp_get_active_pipes(struct intel_dp *intel_dp,
struct drm_modeset_acquire_ctx *ctx,
u8 *pipe_mask)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct drm_connector_list_iter conn_iter;
struct intel_connector *connector;
int ret = 0;
*pipe_mask = 0;
drm_connector_list_iter_begin(&i915->drm, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
struct drm_connector_state *conn_state =
connector->base.state;
struct intel_crtc_state *crtc_state;
struct intel_crtc *crtc;
if (!intel_dp_has_connector(intel_dp, conn_state))
continue;
crtc = to_intel_crtc(conn_state->crtc);
if (!crtc)
continue;
ret = drm_modeset_lock(&crtc->base.mutex, ctx);
if (ret)
break;
crtc_state = to_intel_crtc_state(crtc->base.state);
drm_WARN_ON(&i915->drm, !intel_crtc_has_dp_encoder(crtc_state));
if (!crtc_state->hw.active)
continue;
if (conn_state->commit &&
!try_wait_for_completion(&conn_state->commit->hw_done))
continue;
*pipe_mask |= BIT(crtc->pipe);
}
drm_connector_list_iter_end(&conn_iter);
return ret;
}
static bool intel_dp_is_connected(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
return connector->base.status == connector_status_connected ||
intel_dp->is_mst;
}
int intel_dp_retrain_link(struct intel_encoder *encoder,
struct drm_modeset_acquire_ctx *ctx)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_crtc *crtc;
u8 pipe_mask;
int ret;
if (!intel_dp_is_connected(intel_dp))
return 0;
ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
ctx);
if (ret)
return ret;
if (!intel_dp_needs_link_retrain(intel_dp))
return 0;
ret = intel_dp_get_active_pipes(intel_dp, ctx, &pipe_mask);
if (ret)
return ret;
if (pipe_mask == 0)
return 0;
if (!intel_dp_needs_link_retrain(intel_dp))
return 0;
drm_dbg_kms(&dev_priv->drm, "[ENCODER:%d:%s] retraining link\n",
encoder->base.base.id, encoder->base.name);
for_each_intel_crtc_in_pipe_mask(&dev_priv->drm, crtc, pipe_mask) {
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
/* Suppress underruns caused by re-training */
intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, false);
if (crtc_state->has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev_priv,
intel_crtc_pch_transcoder(crtc), false);
}
for_each_intel_crtc_in_pipe_mask(&dev_priv->drm, crtc, pipe_mask) {
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
/* retrain on the MST master transcoder */
if (DISPLAY_VER(dev_priv) >= 12 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST) &&
!intel_dp_mst_is_master_trans(crtc_state))
continue;
intel_dp_check_frl_training(intel_dp);
intel_dp_pcon_dsc_configure(intel_dp, crtc_state);
intel_dp_start_link_train(intel_dp, crtc_state);
intel_dp_stop_link_train(intel_dp, crtc_state);
break;
}
for_each_intel_crtc_in_pipe_mask(&dev_priv->drm, crtc, pipe_mask) {
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
/* Keep underrun reporting disabled until things are stable */
intel_crtc_wait_for_next_vblank(crtc);
intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe, true);
if (crtc_state->has_pch_encoder)
intel_set_pch_fifo_underrun_reporting(dev_priv,
intel_crtc_pch_transcoder(crtc), true);
}
return 0;
}
static int intel_dp_prep_phy_test(struct intel_dp *intel_dp,
struct drm_modeset_acquire_ctx *ctx,
u8 *pipe_mask)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct drm_connector_list_iter conn_iter;
struct intel_connector *connector;
int ret = 0;
*pipe_mask = 0;
drm_connector_list_iter_begin(&i915->drm, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
struct drm_connector_state *conn_state =
connector->base.state;
struct intel_crtc_state *crtc_state;
struct intel_crtc *crtc;
if (!intel_dp_has_connector(intel_dp, conn_state))
continue;
crtc = to_intel_crtc(conn_state->crtc);
if (!crtc)
continue;
ret = drm_modeset_lock(&crtc->base.mutex, ctx);
if (ret)
break;
crtc_state = to_intel_crtc_state(crtc->base.state);
drm_WARN_ON(&i915->drm, !intel_crtc_has_dp_encoder(crtc_state));
if (!crtc_state->hw.active)
continue;
if (conn_state->commit &&
!try_wait_for_completion(&conn_state->commit->hw_done))
continue;
*pipe_mask |= BIT(crtc->pipe);
}
drm_connector_list_iter_end(&conn_iter);
return ret;
}
static int intel_dp_do_phy_test(struct intel_encoder *encoder,
struct drm_modeset_acquire_ctx *ctx)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
struct intel_crtc *crtc;
u8 pipe_mask;
int ret;
ret = drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex,
ctx);
if (ret)
return ret;
ret = intel_dp_prep_phy_test(intel_dp, ctx, &pipe_mask);
if (ret)
return ret;
if (pipe_mask == 0)
return 0;
drm_dbg_kms(&dev_priv->drm, "[ENCODER:%d:%s] PHY test\n",
encoder->base.base.id, encoder->base.name);
for_each_intel_crtc_in_pipe_mask(&dev_priv->drm, crtc, pipe_mask) {
const struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
/* test on the MST master transcoder */
if (DISPLAY_VER(dev_priv) >= 12 &&
intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST) &&
!intel_dp_mst_is_master_trans(crtc_state))
continue;
intel_dp_process_phy_request(intel_dp, crtc_state);
break;
}
return 0;
}
void intel_dp_phy_test(struct intel_encoder *encoder)
{
struct drm_modeset_acquire_ctx ctx;
int ret;
drm_modeset_acquire_init(&ctx, 0);
for (;;) {
ret = intel_dp_do_phy_test(encoder, &ctx);
if (ret == -EDEADLK) {
drm_modeset_backoff(&ctx);
continue;
}
break;
}
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
drm_WARN(encoder->base.dev, ret,
"Acquiring modeset locks failed with %i\n", ret);
}
static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
u8 val;
if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
return;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_DEVICE_SERVICE_IRQ_VECTOR, &val) != 1 || !val)
return;
drm_dp_dpcd_writeb(&intel_dp->aux, DP_DEVICE_SERVICE_IRQ_VECTOR, val);
if (val & DP_AUTOMATED_TEST_REQUEST)
intel_dp_handle_test_request(intel_dp);
if (val & DP_CP_IRQ)
intel_hdcp_handle_cp_irq(intel_dp->attached_connector);
if (val & DP_SINK_SPECIFIC_IRQ)
drm_dbg_kms(&i915->drm, "Sink specific irq unhandled\n");
}
static void intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
{
u8 val;
if (intel_dp->dpcd[DP_DPCD_REV] < 0x11)
return;
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_LINK_SERVICE_IRQ_VECTOR_ESI0, &val) != 1 || !val)
return;
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_LINK_SERVICE_IRQ_VECTOR_ESI0, val) != 1)
return;
if (val & HDMI_LINK_STATUS_CHANGED)
intel_dp_handle_hdmi_link_status_change(intel_dp);
}
/*
* According to DP spec
* 5.1.2:
* 1. Read DPCD
* 2. Configure link according to Receiver Capabilities
* 3. Use Link Training from 2.5.3.3 and 3.5.1.3
* 4. Check link status on receipt of hot-plug interrupt
*
* intel_dp_short_pulse - handles short pulse interrupts
* when full detection is not required.
* Returns %true if short pulse is handled and full detection
* is NOT required and %false otherwise.
*/
static bool
drm/i915: Reorganizing intel_dp_check_link_status When created originally intel_dp_check_link_status() was supposed to handle only link training for short pulse but has grown into handler for short pulse itself. This patch cleans up this function by splitting it into two halves. First intel_dp_short_pulse() is called, which will be entry point and handle all logic for short pulse handling while intel_dp_check_link_status() will retain its original purpose of only doing link status related work. intel_dp_short_pulse: All existing code other than link status read and link training upon error status. intel_dp_check_link_status: The link status should be read on short pulse irrespective of panel being enabled or not so intel_dp_get_link_status() performs dpcd read first then based on crtc active / enabled it will perform the link training. This is because short pulse is a generic interrupt which should always be handled, because it may mean: 1. Hotplug/unplug of MST panel 2. Hotplug/unplug of dongle 3. Link status change for other DP panels v2: Added WARN_ON to intel_dp_check_link_status() Removed a call to intel_dp_get_link_status() (Ander) v3: Changed commit message to explain need of link status being read before performing encoder checks (Daniel) v4: Changed commit message to explain need of reading link status on short pulse (Ander) Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> [anderco: fix parenthesis alignment] Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-3-git-send-email-shubhangi.shrivastava@intel.com
2016-03-30 12:35:24 +00:00
intel_dp_short_pulse(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
u8 old_sink_count = intel_dp->sink_count;
bool ret;
/*
* Clearing compliance test variables to allow capturing
* of values for next automated test request.
*/
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
/*
* Now read the DPCD to see if it's actually running
* If the current value of sink count doesn't match with
* the value that was stored earlier or dpcd read failed
* we need to do full detection
*/
ret = intel_dp_get_dpcd(intel_dp);
if ((old_sink_count != intel_dp->sink_count) || !ret) {
/* No need to proceed if we are going to do full detect */
return false;
}
intel_dp_check_device_service_irq(intel_dp);
intel_dp_check_link_service_irq(intel_dp);
/* Handle CEC interrupts, if any */
drm_dp_cec_irq(&intel_dp->aux);
/* defer to the hotplug work for link retraining if needed */
if (intel_dp_needs_link_retrain(intel_dp))
return false;
intel_psr_short_pulse(intel_dp);
switch (intel_dp->compliance.test_type) {
case DP_TEST_LINK_TRAINING:
drm_dbg_kms(&dev_priv->drm,
"Link Training Compliance Test requested\n");
/* Send a Hotplug Uevent to userspace to start modeset */
drm_kms_helper_hotplug_event(&dev_priv->drm);
break;
case DP_TEST_LINK_PHY_TEST_PATTERN:
drm_dbg_kms(&dev_priv->drm,
"PHY test pattern Compliance Test requested\n");
/*
* Schedule long hpd to do the test
*
* FIXME get rid of the ad-hoc phy test modeset code
* and properly incorporate it into the normal modeset.
*/
return false;
}
return true;
}
/* XXX this is probably wrong for multiple downstream ports */
static enum drm_connector_status
intel_dp_detect_dpcd(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
u8 *dpcd = intel_dp->dpcd;
u8 type;
if (drm_WARN_ON(&i915->drm, intel_dp_is_edp(intel_dp)))
return connector_status_connected;
lspcon_resume(dig_port);
if (!intel_dp_get_dpcd(intel_dp))
return connector_status_disconnected;
/* if there's no downstream port, we're done */
if (!drm_dp_is_branch(dpcd))
return connector_status_connected;
/* If we're HPD-aware, SINK_COUNT changes dynamically */
if (intel_dp_has_sink_count(intel_dp) &&
intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
drm/i915: Read sink_count dpcd always Sink count can change between short pulse hpd hence this patch adds a member variable to intel_dp so we can track any changes between short pulse interrupts. This patch reads sink_count dpcd always and removes its read operation based on values in downstream port dpcd. SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd. SINK_COUNT denotes if a display is attached, while DOWNSTREAM_PORT_PRESET indicates how many ports are available in the dongle where display can be attached. so it is possible for sink count to change irrespective of value in downstream port dpcd. Here is a table of possible values and scenarios sink_count downstream_port present 0 0 no display is attached 0 1 dongle is connected without display 1 0 display connected directly 1 1 display connected through dongle v2: Storing value of intel_dp->sink_count that is ready for consumption. (Ander) Squashing two commits into one. (Ander) v3: Added comment to explain the need of early return when sink count is 0. (Ander) Tested-by: Nathan D Ciobanu <nathan.d.ciobanu@intel.com> Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-4-git-send-email-shubhangi.shrivastava@intel.com
2016-03-30 12:35:25 +00:00
return intel_dp->sink_count ?
connector_status_connected : connector_status_disconnected;
}
if (intel_dp_can_mst(intel_dp))
return connector_status_connected;
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(&intel_dp->aux.ddc))
return connector_status_connected;
/* Well we tried, say unknown for unreliable port types */
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
if (type == DP_DS_PORT_TYPE_VGA ||
type == DP_DS_PORT_TYPE_NON_EDID)
return connector_status_unknown;
} else {
type = intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] &
DP_DWN_STRM_PORT_TYPE_MASK;
if (type == DP_DWN_STRM_PORT_TYPE_ANALOG ||
type == DP_DWN_STRM_PORT_TYPE_OTHER)
return connector_status_unknown;
}
/* Anything else is out of spec, warn and ignore */
drm_dbg_kms(&i915->drm, "Broken DP branch device, ignoring\n");
return connector_status_disconnected;
}
static enum drm_connector_status
edp_detect(struct intel_dp *intel_dp)
{
return connector_status_connected;
}
/*
* intel_digital_port_connected - is the specified port connected?
* @encoder: intel_encoder
*
drm/i915/icl: implement the tc/legacy HPD {dis,}connect flows Unlike the other ports, TC ports are not available to use as soon as we get a hotplug. The TC PHYs can be shared between multiple controllers: display, USB, etc. As a result, handshaking through FIA is required around connect and disconnect to cleanly transfer ownership with the controller and set the type-C power state. This patch implements the flow sequences described by our specification. We opt to grab ownership of the ports as soon as we get the hotplugs in order to simplify the interactions and avoid surprises in the user space side. We may consider changing this in the future, once we improve our testing capabilities on this area. v2: * This unifies the DP and HDMI patches so we can discuss everything at once so people looking at random single patches can actually understand the direction. * I found out the spec was updated a while ago. There's a small difference in the connect flow and the patch was updated for that. * Our spec also now gives a good explanation on what is really happening. As a result, comments were added. * Add some more comments as requested by Rodrigo (Rodrigo). v3: * Downgrade a DRM_ERROR that shouldn't ever happen but we can't act on in case it does (Chris). BSpec: 21750, 4250. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180801173441.9789-1-paulo.r.zanoni@intel.com
2018-08-01 17:34:41 +00:00
* In cases where there's a connector physically connected but it can't be used
* by our hardware we also return false, since the rest of the driver should
* pretty much treat the port as disconnected. This is relevant for type-C
* (starting on ICL) where there's ownership involved.
*
* Return %true if port is connected, %false otherwise.
*/
bool intel_digital_port_connected(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
bool is_connected = false;
intel_wakeref_t wakeref;
with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref)
is_connected = dig_port->connected(encoder);
return is_connected;
}
static const struct drm_edid *
intel_dp_get_edid(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
const struct drm_edid *fixed_edid = connector->panel.fixed_edid;
/* Use panel fixed edid if we have one */
if (fixed_edid) {
/* invalid edid */
if (IS_ERR(fixed_edid))
return NULL;
return drm_edid_dup(fixed_edid);
}
return drm_edid_read_ddc(&connector->base, &intel_dp->aux.ddc);
}
static void
intel_dp_update_dfp(struct intel_dp *intel_dp,
const struct drm_edid *drm_edid)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
intel_dp->dfp.max_bpc =
drm_dp_downstream_max_bpc(intel_dp->dpcd,
intel_dp->downstream_ports, drm_edid);
intel_dp->dfp.max_dotclock =
drm_dp_downstream_max_dotclock(intel_dp->dpcd,
intel_dp->downstream_ports);
intel_dp->dfp.min_tmds_clock =
drm_dp_downstream_min_tmds_clock(intel_dp->dpcd,
intel_dp->downstream_ports,
drm_edid);
intel_dp->dfp.max_tmds_clock =
drm_dp_downstream_max_tmds_clock(intel_dp->dpcd,
intel_dp->downstream_ports,
drm_edid);
intel_dp->dfp.pcon_max_frl_bw =
drm_dp_get_pcon_max_frl_bw(intel_dp->dpcd,
intel_dp->downstream_ports);
drm_dbg_kms(&i915->drm,
"[CONNECTOR:%d:%s] DFP max bpc %d, max dotclock %d, TMDS clock %d-%d, PCON Max FRL BW %dGbps\n",
connector->base.base.id, connector->base.name,
intel_dp->dfp.max_bpc,
intel_dp->dfp.max_dotclock,
intel_dp->dfp.min_tmds_clock,
intel_dp->dfp.max_tmds_clock,
intel_dp->dfp.pcon_max_frl_bw);
intel_dp_get_pcon_dsc_cap(intel_dp);
}
static bool
intel_dp_can_ycbcr420(struct intel_dp *intel_dp)
{
if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR420) &&
(!drm_dp_is_branch(intel_dp->dpcd) || intel_dp->dfp.ycbcr420_passthrough))
return true;
if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_RGB) &&
dfp_can_convert_from_rgb(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR420))
return true;
if (source_can_output(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR444) &&
dfp_can_convert_from_ycbcr444(intel_dp, INTEL_OUTPUT_FORMAT_YCBCR420))
return true;
return false;
}
static void
intel_dp_update_420(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
intel_dp->dfp.ycbcr420_passthrough =
drm_dp_downstream_420_passthrough(intel_dp->dpcd,
intel_dp->downstream_ports);
/* on-board LSPCON always assumed to support 4:4:4->4:2:0 conversion */
intel_dp->dfp.ycbcr_444_to_420 =
dp_to_dig_port(intel_dp)->lspcon.active ||
drm_dp_downstream_444_to_420_conversion(intel_dp->dpcd,
intel_dp->downstream_ports);
intel_dp->dfp.rgb_to_ycbcr =
drm_dp_downstream_rgb_to_ycbcr_conversion(intel_dp->dpcd,
intel_dp->downstream_ports,
DP_DS_HDMI_BT709_RGB_YCBCR_CONV);
connector->base.ycbcr_420_allowed = intel_dp_can_ycbcr420(intel_dp);
drm_dbg_kms(&i915->drm,
"[CONNECTOR:%d:%s] RGB->YcbCr conversion? %s, YCbCr 4:2:0 allowed? %s, YCbCr 4:4:4->4:2:0 conversion? %s\n",
connector->base.base.id, connector->base.name,
str_yes_no(intel_dp->dfp.rgb_to_ycbcr),
str_yes_no(connector->base.ycbcr_420_allowed),
str_yes_no(intel_dp->dfp.ycbcr_444_to_420));
}
static void
intel_dp_set_edid(struct intel_dp *intel_dp)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_connector *connector = intel_dp->attached_connector;
const struct drm_edid *drm_edid;
bool vrr_capable;
intel_dp_unset_edid(intel_dp);
drm_edid = intel_dp_get_edid(intel_dp);
connector->detect_edid = drm_edid;
/* Below we depend on display info having been updated */
drm_edid_connector_update(&connector->base, drm_edid);
vrr_capable = intel_vrr_is_capable(connector);
drm_dbg_kms(&i915->drm, "[CONNECTOR:%d:%s] VRR capable: %s\n",
connector->base.base.id, connector->base.name, str_yes_no(vrr_capable));
drm_connector_set_vrr_capable_property(&connector->base, vrr_capable);
intel_dp_update_dfp(intel_dp, drm_edid);
intel_dp_update_420(intel_dp);
drm_dp_cec_attach(&intel_dp->aux,
connector->base.display_info.source_physical_address);
}
static void
intel_dp_unset_edid(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
drm_dp_cec_unset_edid(&intel_dp->aux);
drm_edid_free(connector->detect_edid);
connector->detect_edid = NULL;
intel_dp->dfp.max_bpc = 0;
intel_dp->dfp.max_dotclock = 0;
intel_dp->dfp.min_tmds_clock = 0;
intel_dp->dfp.max_tmds_clock = 0;
intel_dp->dfp.pcon_max_frl_bw = 0;
intel_dp->dfp.ycbcr_444_to_420 = false;
connector->base.ycbcr_420_allowed = false;
drm_connector_set_vrr_capable_property(&connector->base,
false);
}
static void
intel_dp_detect_dsc_caps(struct intel_dp *intel_dp, struct intel_connector *connector)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
/* Read DP Sink DSC Cap DPCD regs for DP v1.4 */
if (!HAS_DSC(i915))
return;
if (intel_dp_is_edp(intel_dp))
intel_edp_get_dsc_sink_cap(intel_dp->edp_dpcd[0],
connector);
else
intel_dp_get_dsc_sink_cap(intel_dp->dpcd[DP_DPCD_REV],
connector);
}
static int
intel_dp_detect(struct drm_connector *connector,
struct drm_modeset_acquire_ctx *ctx,
bool force)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_connector *intel_connector =
to_intel_connector(connector);
struct intel_dp *intel_dp = intel_attached_dp(intel_connector);
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = &dig_port->base;
enum drm_connector_status status;
drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
drm_WARN_ON(&dev_priv->drm,
!drm_modeset_is_locked(&dev_priv->drm.mode_config.connection_mutex));
if (!intel_display_device_enabled(dev_priv))
return connector_status_disconnected;
/* Can't disconnect eDP */
if (intel_dp_is_edp(intel_dp))
status = edp_detect(intel_dp);
else if (intel_digital_port_connected(encoder))
status = intel_dp_detect_dpcd(intel_dp);
else
status = connector_status_disconnected;
if (status == connector_status_disconnected) {
memset(&intel_dp->compliance, 0, sizeof(intel_dp->compliance));
memset(intel_connector->dp.dsc_dpcd, 0, sizeof(intel_connector->dp.dsc_dpcd));
drm/i915/panelreplay: Initializaton and compute config for panel replay Modify existing PSR implementation to enable panel replay feature of DP 2.0 which is similar to PSR feature of EDP panel. There is different DPCD address to check panel capability compare to PSR and vsc sdp header is different. v1: Initial version. v2: - Set source_panel_replay_support flag under HAS_PANEL_REPLAY() condition check. [Jouni] - Code restructured around intel_panel_replay_init and renamed to intel_panel_replay_init_dpcd. [Jouni] - Remove the initial code modification around has_psr2 flag. [Jouni] - Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to enable in intel_psr_post_plane_update. [Jouni] v3: - Initialize both psr and panel-replay. [Jouni] - Initialize both panel replay and psr if detected. [Jouni] - Refactoring psr function by introducing _psr_compute_config(). [Jouni] - Add check for !is_edp while deriving source_panel_replay_support. [Jouni] - Enable panel replay dpcd initialization in a separate patch. [Jouni] v4: - HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni] - Set either panel replay source support or psr. [Jouni] v5: - HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni] - Move psr related code to intel_psr.c. [Jani] - Reset sink_panel_replay_support flag during disconnection. [Jani] v6: return statement restored which is removed by misatke. [Jouni] v7: cosmetic changes. [Arun] Cc: Jouni Högander <jouni.hogander@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108072303.3414118-4-animesh.manna@intel.com
2023-11-08 07:23:00 +00:00
intel_dp->psr.sink_panel_replay_support = false;
if (intel_dp->is_mst) {
drm_dbg_kms(&dev_priv->drm,
"MST device may have disappeared %d vs %d\n",
intel_dp->is_mst,
intel_dp->mst_mgr.mst_state);
intel_dp->is_mst = false;
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
intel_dp->is_mst);
}
goto out;
}
if (!intel_dp_is_edp(intel_dp))
intel_psr_init_dpcd(intel_dp);
intel_dp_detect_dsc_caps(intel_dp, intel_connector);
drm/i915/dp_mst: Disable link training fallback on MST links During the initial probing of an MST sink, MST core will determine the sink's link bandwidth based on its own version of the sink link rate/lane count caps it reads from the DPCD. At a later point (after probing and 1 or more modesets) i915 may limit the link parameters wrt. the original source/sink common caps above due to link training failures during a modeset and the resulting link training fallback logic. Based on the above a modeset following another modeset with a link training error will compute the i915 HW specific and DP protocol timing parameters (data/link M/N and MST TU values) taking into account only the unlimited source/sink common caps, but not taking into account the fallback limits. This will also let DRM core oversubscribe the actual link bandwidth during the MST payload allocation. Prevent the above problem by disabling the link training fallback on MST links for now, until the MST probe time initialization and the MST compute config logic can deal with changing link parameters. The misconfigured timings lead at least to a 'Timed out waiting for DP idle patterns' error. v2: (Ville) - Print link training error message on the MST path too. - Clarify the problem in the commit log. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> 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/20200616211146.23027-2-imre.deak@intel.com
2020-06-16 21:11:45 +00:00
intel_dp_configure_mst(intel_dp);
/*
* TODO: Reset link params when switching to MST mode, until MST
* supports link training fallback params.
*/
if (intel_dp->reset_link_params || intel_dp->is_mst) {
intel_dp_reset_max_link_params(intel_dp);
intel_dp->reset_link_params = false;
}
intel_dp_print_rates(intel_dp);
if (intel_dp->is_mst) {
/*
* If we are in MST mode then this connector
* won't appear connected or have anything
* with EDID on it
*/
2014-05-02 04:02:48 +00:00
status = connector_status_disconnected;
goto out;
}
/*
* Some external monitors do not signal loss of link synchronization
* with an IRQ_HPD, so force a link status check.
*/
if (!intel_dp_is_edp(intel_dp)) {
int ret;
ret = intel_dp_retrain_link(encoder, ctx);
if (ret)
return ret;
}
2014-05-02 04:02:48 +00:00
/*
* Clearing NACK and defer counts to get their exact values
* while reading EDID which are required by Compliance tests
* 4.2.2.4 and 4.2.2.5
*/
intel_dp->aux.i2c_nack_count = 0;
intel_dp->aux.i2c_defer_count = 0;
intel_dp_set_edid(intel_dp);
if (intel_dp_is_edp(intel_dp) ||
to_intel_connector(connector)->detect_edid)
status = connector_status_connected;
intel_dp_check_device_service_irq(intel_dp);
drm/i915: Move Displayport test request and sink IRQ logic to intel_dp_detect() Due to changes in the driver and to support Displayport compliance testing, the test request and sink IRQ logic has been relocated from intel_dp_check_link_status to intel_dp_detect. This is because the bulk of the compliance tests that set the TEST_REQUEST bit in the DEVICE_IRQ field of the DPCD issue a long pulse / hot plug event to signify the start of the test. Currently, for a long pulse, intel_dp_check_link_status is not called for a long HPD pulse, so if test requests come in, they cannot be detected by the driver. Once located in the intel_dp_detect, in the regular hot plug event path, proper detection of Displayport compliance test requests occurs which then invokes the test handler to support them. Additionally, this places compliance testing in the normal operational paths, eliminating as much special case code as possible. The only change in intel_dp_check_link_status with this patch is that when the IRQ is the result of a test request from the sink, the test handler is not invoked during the short pulse path. Short pulse test requests are for a particular variety of tests (mainly link training) that will be implemented in the future. Once those tests are available, the test request handler will be called from here as well. V2: - Rewored the commit message to be more clear about the content and intent of this patch - Restore IRQ detection logic to intel_dp_check_link_status(). Continue to detect and clear sink IRQs in the short pulse case. Ignore test requests in the short pulses for now since they are for future test implementations. Signed-off-by: Todd Previte <tprevite@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-20 22:27:34 +00:00
out:
if (status != connector_status_connected && !intel_dp->is_mst)
intel_dp_unset_edid(intel_dp);
if (!intel_dp_is_edp(intel_dp))
drm_dp_set_subconnector_property(connector,
status,
intel_dp->dpcd,
intel_dp->downstream_ports);
return status;
}
static void
intel_dp_force(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(to_intel_connector(connector));
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *intel_encoder = &dig_port->base;
struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
intel_dp_unset_edid(intel_dp);
if (connector->status != connector_status_connected)
return;
intel_dp_set_edid(intel_dp);
}
static int intel_dp_get_modes(struct drm_connector *connector)
{
struct intel_connector *intel_connector = to_intel_connector(connector);
int num_modes;
/* drm_edid_connector_update() done in ->detect() or ->force() */
num_modes = drm_edid_connector_add_modes(connector);
/* Also add fixed mode, which may or may not be present in EDID */
if (intel_dp_is_edp(intel_attached_dp(intel_connector)))
num_modes += intel_panel_get_modes(intel_connector);
if (num_modes)
return num_modes;
if (!intel_connector->detect_edid) {
struct intel_dp *intel_dp = intel_attached_dp(intel_connector);
struct drm_display_mode *mode;
mode = drm_dp_downstream_mode(connector->dev,
intel_dp->dpcd,
intel_dp->downstream_ports);
if (mode) {
drm_mode_probed_add(connector, mode);
num_modes++;
}
}
return num_modes;
}
static int
intel_dp_connector_register(struct drm_connector *connector)
{
struct drm_i915_private *i915 = to_i915(connector->dev);
struct intel_dp *intel_dp = intel_attached_dp(to_intel_connector(connector));
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_lspcon *lspcon = &dig_port->lspcon;
int ret;
ret = intel_connector_register(connector);
if (ret)
return ret;
drm_dbg_kms(&i915->drm, "registering %s bus for %s\n",
intel_dp->aux.name, connector->kdev->kobj.name);
intel_dp->aux.dev = connector->kdev;
ret = drm_dp_aux_register(&intel_dp->aux);
if (!ret)
drm_dp_cec_register_connector(&intel_dp->aux, connector);
if (!intel_bios_encoder_is_lspcon(dig_port->base.devdata))
return ret;
/*
* ToDo: Clean this up to handle lspcon init and resume more
* efficiently and streamlined.
*/
if (lspcon_init(dig_port)) {
lspcon_detect_hdr_capability(lspcon);
if (lspcon->hdr_supported)
drm_connector_attach_hdr_output_metadata_property(connector);
}
return ret;
}
static void
intel_dp_connector_unregister(struct drm_connector *connector)
{
struct intel_dp *intel_dp = intel_attached_dp(to_intel_connector(connector));
drm_dp_cec_unregister_connector(&intel_dp->aux);
drm_dp_aux_unregister(&intel_dp->aux);
intel_connector_unregister(connector);
}
void intel_dp_connector_sync_state(struct intel_connector *connector,
const struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
if (crtc_state && crtc_state->dsc.compression_enable) {
drm_WARN_ON(&i915->drm, !connector->dp.dsc_decompression_aux);
connector->dp.dsc_decompression_enabled = true;
} else {
connector->dp.dsc_decompression_enabled = false;
}
}
drm/i915/icl: Fix HPD handling for TypeC legacy ports Atm HPD disconnect events on TypeC ports will break things, since we'll switch the TypeC mode (between legacy and disconnected modes as well as among USB DP alternate, Thunderbolt alternate and disconnected modes) on the fly from the HPD disconnect interrupt work while the port may be still active. Even if the port happens to be not active during the disconnect we'd still have a problem during a subsequent modeset or AUX transfer that could happen regardless of the port's connected state. For instance the system resume display mode restore code and userspace could perform a modeset on the port or userspace could start an AUX transfer even if the port is in disconnected state. To fix this keep TypeC legacy ports in legacy mode whenever we're not suspended. This mode is a static configuration as opposed to the Thunderbolt and USB DP alternate modes between which we can switch dynamically. We determine if a TypeC port is legacy (wired to a legacy HDMI or a legacy DP connector) via the VBT DDI port specific USB-TypeC and Thunderbolt flags. If both these flags are cleared then the port is configured for legacy mode. On such legacy ports we'll run the TypeC PHY connect sequence explicitly during driver loading and system resume (vs. running the sequence during HPD processing). The connect will succeed even if the display is not connected to begin with (or disappears during the suspended state) since for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB DP alternate mode where it gets set only when a display is connected). Correspondingly run the TypeC PHY disconnect sequence during system suspend and driver unloading. For the unloading case I had to split up intel_dp_encoder_destroy() to be able to have the 1. flush any pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and kfree on the encoder object. For now run the PHY disconnect during suspend only for TypeC legacy ports. We will need to disconnect even in USB DP alternate mode in the future, but atm we don't have a way to reconnect the port in this mode during resume if the display disappears while being suspended. So for now punt on this case. Note that we do not disconnect the port during runtime suspend; in legacy mode there are no shared HW resources (PHY lanes) with other HW blocks (USB), so no need to release / reacquire these resources as with USB DP alternate mode. The only reason to disconnect legacy ports during system suspend is that the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be connected again during system resume. We'll also have to turn the check for this flag into a poll, after figuring out what's the proper timeout value for it. v2: - Remove the redundant special casing of legacy mode when doing a disconnect in icl_tc_port_connected(). It's guaranteed already that we won't disconnect legacy ports in that function. - Add a note about the new intel_ddi_encoder_destroy() hook. - Reword the commit message after switching to the VBT based detection. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-4-imre.deak@intel.com
2018-12-14 18:27:02 +00:00
void intel_dp_encoder_flush_work(struct drm_encoder *encoder)
{
struct intel_digital_port *dig_port = enc_to_dig_port(to_intel_encoder(encoder));
struct intel_dp *intel_dp = &dig_port->dp;
intel_dp_mst_encoder_cleanup(dig_port);
intel_pps_vdd_off_sync(intel_dp);
drm/i915/edp: wait power off delay at driver remove to optimize probe Panel power off delay is the time the panel power needs to remain off after being switched off, before it can be switched on again. For the purpose of respecting panel power off delay at driver probe, assuming the panel was last switched off at driver probe is overly pessimistic. If the panel was never on, we'd end up waiting for no reason. We don't know what has happened before kernel boot, but we can make some assumptions: - The panel may have been switched off right before kernel boot by some pre-os environment. - After kernel boot, the panel may only be switched off by i915. - At i915 driver probe, only a previously loaded and removed i915 may have switched the panel power off. With these assumptions, we can initialize the last power off time to kernel boot time, if we also ensure i915 driver remove waits for the panel power off delay after switching panel power off. This shaves off the time it takes from kernel boot to i915 probe from the first panel enable, if (and only if) the panel was not already enabled at boot. The encoder destroy hook is pretty much the last place where we can wait, right after we've ensured the panel power has been switched off, and before the whole encoder is destroyed. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7417 Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Lee Shawn C <shawn.c.lee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221116150657.1347504-1-jani.nikula@intel.com
2022-11-16 15:06:57 +00:00
/*
* Ensure power off delay is respected on module remove, so that we can
* reduce delays at driver probe. See pps_init_timestamps().
*/
intel_pps_wait_power_cycle(intel_dp);
intel_dp_aux_fini(intel_dp);
drm/i915/icl: Fix HPD handling for TypeC legacy ports Atm HPD disconnect events on TypeC ports will break things, since we'll switch the TypeC mode (between legacy and disconnected modes as well as among USB DP alternate, Thunderbolt alternate and disconnected modes) on the fly from the HPD disconnect interrupt work while the port may be still active. Even if the port happens to be not active during the disconnect we'd still have a problem during a subsequent modeset or AUX transfer that could happen regardless of the port's connected state. For instance the system resume display mode restore code and userspace could perform a modeset on the port or userspace could start an AUX transfer even if the port is in disconnected state. To fix this keep TypeC legacy ports in legacy mode whenever we're not suspended. This mode is a static configuration as opposed to the Thunderbolt and USB DP alternate modes between which we can switch dynamically. We determine if a TypeC port is legacy (wired to a legacy HDMI or a legacy DP connector) via the VBT DDI port specific USB-TypeC and Thunderbolt flags. If both these flags are cleared then the port is configured for legacy mode. On such legacy ports we'll run the TypeC PHY connect sequence explicitly during driver loading and system resume (vs. running the sequence during HPD processing). The connect will succeed even if the display is not connected to begin with (or disappears during the suspended state) since for legacy ports the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag is always set (as opposed to the USB DP alternate mode where it gets set only when a display is connected). Correspondingly run the TypeC PHY disconnect sequence during system suspend and driver unloading. For the unloading case I had to split up intel_dp_encoder_destroy() to be able to have the 1. flush any pending encoder work, 2. disconnect TC PHY, 3. call DRM core cleanup and kfree on the encoder object. For now run the PHY disconnect during suspend only for TypeC legacy ports. We will need to disconnect even in USB DP alternate mode in the future, but atm we don't have a way to reconnect the port in this mode during resume if the display disappears while being suspended. So for now punt on this case. Note that we do not disconnect the port during runtime suspend; in legacy mode there are no shared HW resources (PHY lanes) with other HW blocks (USB), so no need to release / reacquire these resources as with USB DP alternate mode. The only reason to disconnect legacy ports during system suspend is that the PORT_TX_DFLEXDPPMS / DP_PHY_MODE_STATUS_COMPLETED flag must be rechecked and the port must be connected again during system resume. We'll also have to turn the check for this flag into a poll, after figuring out what's the proper timeout value for it. v2: - Remove the redundant special casing of legacy mode when doing a disconnect in icl_tc_port_connected(). It's guaranteed already that we won't disconnect legacy ports in that function. - Add a note about the new intel_ddi_encoder_destroy() hook. - Reword the commit message after switching to the VBT based detection. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108924 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181214182703.18865-4-imre.deak@intel.com
2018-12-14 18:27:02 +00:00
}
void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
intel_pps_vdd_off_sync(intel_dp);
}
void intel_dp_encoder_shutdown(struct intel_encoder *intel_encoder)
{
struct intel_dp *intel_dp = enc_to_intel_dp(intel_encoder);
intel_pps_wait_power_cycle(intel_dp);
}
static int intel_modeset_tile_group(struct intel_atomic_state *state,
int tile_group_id)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct drm_connector_list_iter conn_iter;
struct drm_connector *connector;
int ret = 0;
drm_connector_list_iter_begin(&dev_priv->drm, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
struct drm_connector_state *conn_state;
struct intel_crtc_state *crtc_state;
struct intel_crtc *crtc;
if (!connector->has_tile ||
connector->tile_group->id != tile_group_id)
continue;
conn_state = drm_atomic_get_connector_state(&state->base,
connector);
if (IS_ERR(conn_state)) {
ret = PTR_ERR(conn_state);
break;
}
crtc = to_intel_crtc(conn_state->crtc);
if (!crtc)
continue;
crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
crtc_state->uapi.mode_changed = true;
ret = drm_atomic_add_affected_planes(&state->base, &crtc->base);
if (ret)
break;
}
drm_connector_list_iter_end(&conn_iter);
return ret;
}
static int intel_modeset_affected_transcoders(struct intel_atomic_state *state, u8 transcoders)
{
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
struct intel_crtc *crtc;
if (transcoders == 0)
return 0;
for_each_intel_crtc(&dev_priv->drm, crtc) {
struct intel_crtc_state *crtc_state;
int ret;
crtc_state = intel_atomic_get_crtc_state(&state->base, crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
if (!crtc_state->hw.enable)
continue;
if (!(transcoders & BIT(crtc_state->cpu_transcoder)))
continue;
crtc_state->uapi.mode_changed = true;
ret = drm_atomic_add_affected_connectors(&state->base, &crtc->base);
if (ret)
return ret;
ret = drm_atomic_add_affected_planes(&state->base, &crtc->base);
if (ret)
return ret;
transcoders &= ~BIT(crtc_state->cpu_transcoder);
}
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
drm_WARN_ON(&dev_priv->drm, transcoders != 0);
return 0;
}
static int intel_modeset_synced_crtcs(struct intel_atomic_state *state,
struct drm_connector *connector)
{
const struct drm_connector_state *old_conn_state =
drm_atomic_get_old_connector_state(&state->base, connector);
const struct intel_crtc_state *old_crtc_state;
struct intel_crtc *crtc;
u8 transcoders;
crtc = to_intel_crtc(old_conn_state->crtc);
if (!crtc)
return 0;
old_crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
if (!old_crtc_state->hw.active)
return 0;
transcoders = old_crtc_state->sync_mode_slaves_mask;
if (old_crtc_state->master_transcoder != INVALID_TRANSCODER)
transcoders |= BIT(old_crtc_state->master_transcoder);
return intel_modeset_affected_transcoders(state,
transcoders);
}
static int intel_dp_connector_atomic_check(struct drm_connector *conn,
struct drm_atomic_state *_state)
{
struct drm_i915_private *dev_priv = to_i915(conn->dev);
struct intel_atomic_state *state = to_intel_atomic_state(_state);
drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions There's another kind of situation where we could potentially race with nonblocking modesets and MST, especially if we were to only use the locking provided by atomic modesetting: * Display 1 begins as enabled on DP-1 in SST mode * Display 1 switches to MST mode, exposes one sink in MST mode * Userspace does non-blocking modeset to disable the SST display * Userspace does non-blocking modeset to enable the MST display with a different CRTC, but the SST display hasn't been fully taken down yet * Execution order between the last two commits isn't guaranteed since they share no drm resources We can fix this however, by ensuring that we always pull in the atomic topology state whenever a connector capable of driving an MST display performs its atomic check - and then tracking CRTC commits happening on the SST connector in the MST topology state. So, let's add some simple helpers for doing that and hook them up in various drivers. v2: * Use intel_dp_mst_source_support() to check for MST support in i915, fixes CI failures Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-14-lyude@redhat.com
2022-08-17 19:38:42 +00:00
struct drm_connector_state *conn_state = drm_atomic_get_new_connector_state(_state, conn);
struct intel_connector *intel_conn = to_intel_connector(conn);
struct intel_dp *intel_dp = enc_to_intel_dp(intel_conn->encoder);
int ret;
ret = intel_digital_connector_atomic_check(conn, &state->base);
if (ret)
return ret;
drm/display/dp_mst: Add helpers for serializing SST <-> MST transitions There's another kind of situation where we could potentially race with nonblocking modesets and MST, especially if we were to only use the locking provided by atomic modesetting: * Display 1 begins as enabled on DP-1 in SST mode * Display 1 switches to MST mode, exposes one sink in MST mode * Userspace does non-blocking modeset to disable the SST display * Userspace does non-blocking modeset to enable the MST display with a different CRTC, but the SST display hasn't been fully taken down yet * Execution order between the last two commits isn't guaranteed since they share no drm resources We can fix this however, by ensuring that we always pull in the atomic topology state whenever a connector capable of driving an MST display performs its atomic check - and then tracking CRTC commits happening on the SST connector in the MST topology state. So, let's add some simple helpers for doing that and hook them up in various drivers. v2: * Use intel_dp_mst_source_support() to check for MST support in i915, fixes CI failures Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Wayne Lin <Wayne.Lin@amd.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Fangzhi Zuo <Jerry.Zuo@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sean Paul <sean@poorly.run> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220817193847.557945-14-lyude@redhat.com
2022-08-17 19:38:42 +00:00
if (intel_dp_mst_source_support(intel_dp)) {
ret = drm_dp_mst_root_conn_atomic_check(conn_state, &intel_dp->mst_mgr);
if (ret)
return ret;
}
/*
* We don't enable port sync on BDW due to missing w/as and
* due to not having adjusted the modeset sequence appropriately.
*/
if (DISPLAY_VER(dev_priv) < 9)
return 0;
if (!intel_connector_needs_modeset(state, conn))
return 0;
if (conn->has_tile) {
ret = intel_modeset_tile_group(state, conn->tile_group->id);
if (ret)
return ret;
}
return intel_modeset_synced_crtcs(state, conn);
}
static void intel_dp_oob_hotplug_event(struct drm_connector *connector,
enum drm_connector_status hpd_state)
{
struct intel_encoder *encoder = intel_attached_encoder(to_intel_connector(connector));
struct drm_i915_private *i915 = to_i915(connector->dev);
bool hpd_high = hpd_state == connector_status_connected;
unsigned int hpd_pin = encoder->hpd_pin;
bool need_work = false;
spin_lock_irq(&i915->irq_lock);
if (hpd_high != test_bit(hpd_pin, &i915->display.hotplug.oob_hotplug_last_state)) {
i915->display.hotplug.event_bits |= BIT(hpd_pin);
__assign_bit(hpd_pin, &i915->display.hotplug.oob_hotplug_last_state, hpd_high);
need_work = true;
}
spin_unlock_irq(&i915->irq_lock);
if (need_work)
queue_delayed_work(i915->unordered_wq, &i915->display.hotplug.hotplug_work, 0);
}
static const struct drm_connector_funcs intel_dp_connector_funcs = {
.force = intel_dp_force,
.fill_modes = drm_helper_probe_single_connector_modes,
.atomic_get_property = intel_digital_connector_atomic_get_property,
.atomic_set_property = intel_digital_connector_atomic_set_property,
.late_register = intel_dp_connector_register,
.early_unregister = intel_dp_connector_unregister,
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
.oob_hotplug_event = intel_dp_oob_hotplug_event,
};
static const struct drm_connector_helper_funcs intel_dp_connector_helper_funcs = {
.detect_ctx = intel_dp_detect,
.get_modes = intel_dp_get_modes,
.mode_valid = intel_dp_mode_valid,
.atomic_check = intel_dp_connector_atomic_check,
};
enum irqreturn
intel_dp_hpd_pulse(struct intel_digital_port *dig_port, bool long_hpd)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_dp *intel_dp = &dig_port->dp;
if (dig_port->base.type == INTEL_OUTPUT_EDP &&
(long_hpd || !intel_pps_have_panel_power_or_vdd(intel_dp))) {
/*
* vdd off can generate a long/short pulse on eDP which
* would require vdd on to handle it, and thus we
* would end up in an endless cycle of
* "vdd off -> long/short hpd -> vdd on -> detect -> vdd off -> ..."
*/
drm_dbg_kms(&i915->drm,
"ignoring %s hpd on eDP [ENCODER:%d:%s]\n",
long_hpd ? "long" : "short",
dig_port->base.base.base.id,
dig_port->base.base.name);
return IRQ_HANDLED;
}
drm_dbg_kms(&i915->drm, "got hpd irq on [ENCODER:%d:%s] - %s\n",
dig_port->base.base.base.id,
dig_port->base.base.name,
long_hpd ? "long" : "short");
if (long_hpd) {
intel_dp->reset_link_params = true;
return IRQ_NONE;
}
if (intel_dp->is_mst) {
if (!intel_dp_check_mst_status(intel_dp))
return IRQ_NONE;
} else if (!intel_dp_short_pulse(intel_dp)) {
return IRQ_NONE;
2014-05-02 04:02:48 +00:00
}
return IRQ_HANDLED;
}
static bool _intel_dp_is_port_edp(struct drm_i915_private *dev_priv,
const struct intel_bios_encoder_data *devdata,
enum port port)
{
/*
* eDP not supported on g4x. so bail out early just
* for a bit extra safety in case the VBT is bonkers.
*/
if (DISPLAY_VER(dev_priv) < 5)
return false;
if (DISPLAY_VER(dev_priv) < 9 && port == PORT_A)
return true;
return devdata && intel_bios_encoder_supports_edp(devdata);
}
bool intel_dp_is_port_edp(struct drm_i915_private *i915, enum port port)
{
const struct intel_bios_encoder_data *devdata =
intel_bios_encoder_data_lookup(i915, port);
return _intel_dp_is_port_edp(i915, devdata, port);
}
static bool
has_gamut_metadata_dip(struct intel_encoder *encoder)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
enum port port = encoder->port;
if (intel_bios_encoder_is_lspcon(encoder->devdata))
return false;
if (DISPLAY_VER(i915) >= 11)
return true;
if (port == PORT_A)
return false;
if (IS_HASWELL(i915) || IS_BROADWELL(i915) ||
DISPLAY_VER(i915) >= 9)
return true;
return false;
}
static void
intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
enum port port = dp_to_dig_port(intel_dp)->base.port;
if (!intel_dp_is_edp(intel_dp))
drm_connector_attach_dp_subconnector_property(connector);
if (!IS_G4X(dev_priv) && port != PORT_A)
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
if (HAS_GMCH(dev_priv))
drm_connector_attach_max_bpc_property(connector, 6, 10);
else if (DISPLAY_VER(dev_priv) >= 5)
drm_connector_attach_max_bpc_property(connector, 6, 12);
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_encoder_is_lspcon(dp_to_dig_port(intel_dp)->base.devdata)) {
drm_connector_attach_content_type_property(connector);
intel_attach_hdmi_colorspace_property(connector);
} else {
intel_attach_dp_colorspace_property(connector);
}
if (has_gamut_metadata_dip(&dp_to_dig_port(intel_dp)->base))
drm_connector_attach_hdr_output_metadata_property(connector);
if (HAS_VRR(dev_priv))
drm_connector_attach_vrr_capable_property(connector);
}
static void
intel_edp_add_properties(struct intel_dp *intel_dp)
{
struct intel_connector *connector = intel_dp->attached_connector;
struct drm_i915_private *i915 = to_i915(connector->base.dev);
const struct drm_display_mode *fixed_mode =
intel_panel_preferred_fixed_mode(connector);
intel_attach_scaling_mode_property(&connector->base);
drm_connector_set_panel_orientation_with_quirk(&connector->base,
i915->display.vbt.orientation,
fixed_mode->hdisplay,
fixed_mode->vdisplay);
}
static void intel_edp_backlight_setup(struct intel_dp *intel_dp,
struct intel_connector *connector)
{
struct drm_i915_private *i915 = dp_to_i915(intel_dp);
enum pipe pipe = INVALID_PIPE;
if (IS_VALLEYVIEW(i915) || IS_CHERRYVIEW(i915)) {
/*
* Figure out the current pipe for the initial backlight setup.
* If the current pipe isn't valid, try the PPS pipe, and if that
* fails just assume pipe A.
*/
pipe = vlv_active_pipe(intel_dp);
if (pipe != PIPE_A && pipe != PIPE_B)
pipe = intel_dp->pps.pps_pipe;
if (pipe != PIPE_A && pipe != PIPE_B)
pipe = PIPE_A;
}
intel_backlight_setup(connector, pipe);
}
static bool intel_edp_init_connector(struct intel_dp *intel_dp,
struct intel_connector *intel_connector)
{
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
struct drm_connector *connector = &intel_connector->base;
struct drm_display_mode *fixed_mode;
struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
bool has_dpcd;
const struct drm_edid *drm_edid;
if (!intel_dp_is_edp(intel_dp))
return true;
/*
* On IBX/CPT we may get here with LVDS already registered. Since the
* driver uses the only internal power sequencer available for both
* eDP and LVDS bail out early in this case to prevent interfering
* with an already powered-on LVDS power sequencer.
*/
if (intel_get_lvds_encoder(dev_priv)) {
drm_WARN_ON(&dev_priv->drm,
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
!(HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv)));
drm_info(&dev_priv->drm,
"LVDS was detected, not registering eDP\n");
return false;
}
intel_bios_init_panel_early(dev_priv, &intel_connector->panel,
encoder->devdata);
if (!intel_pps_init(intel_dp)) {
drm_info(&dev_priv->drm,
"[ENCODER:%d:%s] unusable PPS, disabling eDP\n",
encoder->base.base.id, encoder->base.name);
/*
* The BIOS may have still enabled VDD on the PPS even
* though it's unusable. Make sure we turn it back off
* and to release the power domain references/etc.
*/
goto out_vdd_off;
}
drm/i915: Check HPD live state during eDP probe We need to untangle the mess where some SKL machines (at least) declare both DDI A and DDI E to be present in their VBT, and both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a real DP->VGA converter. Currently that is handled by checking the VBT child devices for conflicts before output probing. But that kind of solution will not work for the ADL phantom dual eDP VBTs. I think on those we just have to probe the eDP first. And would be nice to use the same probe scheme for everything. On these SKL systems if we probe DDI A first (which is only natural given it's declared by VBT first) we will get an answer via AUX, but it came from the DP->VGA converter hooked to the DDI E, not DDI A. Thus we mistakenly register eDP on DDI A and screw up the real DP device in DDI E. To fix this let's check the HPD live state during the eDP probe. If we got an answer via DPCD but HPD is still down let's assume we got the answer from someone else. Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and I also tested turning off all HPD hardware prior to loading i915 to make sure it all comes up properly. And I simulated the failure path too by not turning on HPD sense and that correctly gave up on eDP. I *think* Windows might just fully depend on HPD here. I couldn't really find any other way they probe displays. And I did find code where they also check the live state prior to AUX transfers (something Imre and I have also talked about perhaps doing). That would also solve this as we'd not succeed in the eDP probe DPCD reads. Other solutions I've considered: - Reintrduce DDI strap checks on SKL. Unfortunately we just don't have any idea how reliable they are on real production hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A") does suggest that not very. Sadly that commit is very poor in details :/ Also the systems (Asrock B250M-HDV at least) fixed by commit 41e35ffb380b ("drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin") might still not work since we don't know what their straps indicate. Stupid me for not asking the reporter to check those at the time :( We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k both MS-7B54/Z370M) that also declare both DDI A and DDI E in VBT to use AUX A, and on these the DDI A strap is also set. There doesn't seem to be anything hooked up to either DDI however. But given the DDI A strap is wrong on these it might well be wrong on the Asrock too. Most other CI machines seem to have straps that generally match the VBT. fi-kbl-soraka is an exception though as DDI D strap is not set, but it is declared in VBT as a DP++ port. No idea if there's a real physical port to go with it or not. - Some kind of quirk just for the cases where both DDI A and DDI E are present in VBT. Might be feasible given we've ignored DDI A in these cases up to now successfully. But feels rather unsatisfactory, and not very future proof against funny VBTs. References: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com
2023-04-17 13:17:27 +00:00
/*
* Enable HPD sense for live status check.
* intel_hpd_irq_setup() will turn it off again
* if it's no longer needed later.
*
* The DPCD probe below will make sure VDD is on.
*/
intel_hpd_enable_detection(encoder);
/* Cache DPCD and EDID for edp. */
has_dpcd = intel_edp_init_dpcd(intel_dp, intel_connector);
if (!has_dpcd) {
/* if this fails, presume the device is a ghost */
drm_info(&dev_priv->drm,
"[ENCODER:%d:%s] failed to retrieve link info, disabling eDP\n",
encoder->base.base.id, encoder->base.name);
goto out_vdd_off;
}
drm/i915: Check HPD live state during eDP probe We need to untangle the mess where some SKL machines (at least) declare both DDI A and DDI E to be present in their VBT, and both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a real DP->VGA converter. Currently that is handled by checking the VBT child devices for conflicts before output probing. But that kind of solution will not work for the ADL phantom dual eDP VBTs. I think on those we just have to probe the eDP first. And would be nice to use the same probe scheme for everything. On these SKL systems if we probe DDI A first (which is only natural given it's declared by VBT first) we will get an answer via AUX, but it came from the DP->VGA converter hooked to the DDI E, not DDI A. Thus we mistakenly register eDP on DDI A and screw up the real DP device in DDI E. To fix this let's check the HPD live state during the eDP probe. If we got an answer via DPCD but HPD is still down let's assume we got the answer from someone else. Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and I also tested turning off all HPD hardware prior to loading i915 to make sure it all comes up properly. And I simulated the failure path too by not turning on HPD sense and that correctly gave up on eDP. I *think* Windows might just fully depend on HPD here. I couldn't really find any other way they probe displays. And I did find code where they also check the live state prior to AUX transfers (something Imre and I have also talked about perhaps doing). That would also solve this as we'd not succeed in the eDP probe DPCD reads. Other solutions I've considered: - Reintrduce DDI strap checks on SKL. Unfortunately we just don't have any idea how reliable they are on real production hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A") does suggest that not very. Sadly that commit is very poor in details :/ Also the systems (Asrock B250M-HDV at least) fixed by commit 41e35ffb380b ("drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin") might still not work since we don't know what their straps indicate. Stupid me for not asking the reporter to check those at the time :( We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k both MS-7B54/Z370M) that also declare both DDI A and DDI E in VBT to use AUX A, and on these the DDI A strap is also set. There doesn't seem to be anything hooked up to either DDI however. But given the DDI A strap is wrong on these it might well be wrong on the Asrock too. Most other CI machines seem to have straps that generally match the VBT. fi-kbl-soraka is an exception though as DDI D strap is not set, but it is declared in VBT as a DP++ port. No idea if there's a real physical port to go with it or not. - Some kind of quirk just for the cases where both DDI A and DDI E are present in VBT. Might be feasible given we've ignored DDI A in these cases up to now successfully. But feels rather unsatisfactory, and not very future proof against funny VBTs. References: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com
2023-04-17 13:17:27 +00:00
/*
* VBT and straps are liars. Also check HPD as that seems
* to be the most reliable piece of information available.
*
* ... expect on devices that forgot to hook HPD up for eDP
* (eg. Acer Chromebook C710), so we'll check it only if multiple
* ports are attempting to use the same AUX CH, according to VBT.
drm/i915: Check HPD live state during eDP probe We need to untangle the mess where some SKL machines (at least) declare both DDI A and DDI E to be present in their VBT, and both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a real DP->VGA converter. Currently that is handled by checking the VBT child devices for conflicts before output probing. But that kind of solution will not work for the ADL phantom dual eDP VBTs. I think on those we just have to probe the eDP first. And would be nice to use the same probe scheme for everything. On these SKL systems if we probe DDI A first (which is only natural given it's declared by VBT first) we will get an answer via AUX, but it came from the DP->VGA converter hooked to the DDI E, not DDI A. Thus we mistakenly register eDP on DDI A and screw up the real DP device in DDI E. To fix this let's check the HPD live state during the eDP probe. If we got an answer via DPCD but HPD is still down let's assume we got the answer from someone else. Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and I also tested turning off all HPD hardware prior to loading i915 to make sure it all comes up properly. And I simulated the failure path too by not turning on HPD sense and that correctly gave up on eDP. I *think* Windows might just fully depend on HPD here. I couldn't really find any other way they probe displays. And I did find code where they also check the live state prior to AUX transfers (something Imre and I have also talked about perhaps doing). That would also solve this as we'd not succeed in the eDP probe DPCD reads. Other solutions I've considered: - Reintrduce DDI strap checks on SKL. Unfortunately we just don't have any idea how reliable they are on real production hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A") does suggest that not very. Sadly that commit is very poor in details :/ Also the systems (Asrock B250M-HDV at least) fixed by commit 41e35ffb380b ("drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin") might still not work since we don't know what their straps indicate. Stupid me for not asking the reporter to check those at the time :( We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k both MS-7B54/Z370M) that also declare both DDI A and DDI E in VBT to use AUX A, and on these the DDI A strap is also set. There doesn't seem to be anything hooked up to either DDI however. But given the DDI A strap is wrong on these it might well be wrong on the Asrock too. Most other CI machines seem to have straps that generally match the VBT. fi-kbl-soraka is an exception though as DDI D strap is not set, but it is declared in VBT as a DP++ port. No idea if there's a real physical port to go with it or not. - Some kind of quirk just for the cases where both DDI A and DDI E are present in VBT. Might be feasible given we've ignored DDI A in these cases up to now successfully. But feels rather unsatisfactory, and not very future proof against funny VBTs. References: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com
2023-04-17 13:17:27 +00:00
*/
if (intel_bios_dp_has_shared_aux_ch(encoder->devdata)) {
drm/i915: Check HPD live state during eDP probe We need to untangle the mess where some SKL machines (at least) declare both DDI A and DDI E to be present in their VBT, and both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a real DP->VGA converter. Currently that is handled by checking the VBT child devices for conflicts before output probing. But that kind of solution will not work for the ADL phantom dual eDP VBTs. I think on those we just have to probe the eDP first. And would be nice to use the same probe scheme for everything. On these SKL systems if we probe DDI A first (which is only natural given it's declared by VBT first) we will get an answer via AUX, but it came from the DP->VGA converter hooked to the DDI E, not DDI A. Thus we mistakenly register eDP on DDI A and screw up the real DP device in DDI E. To fix this let's check the HPD live state during the eDP probe. If we got an answer via DPCD but HPD is still down let's assume we got the answer from someone else. Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and I also tested turning off all HPD hardware prior to loading i915 to make sure it all comes up properly. And I simulated the failure path too by not turning on HPD sense and that correctly gave up on eDP. I *think* Windows might just fully depend on HPD here. I couldn't really find any other way they probe displays. And I did find code where they also check the live state prior to AUX transfers (something Imre and I have also talked about perhaps doing). That would also solve this as we'd not succeed in the eDP probe DPCD reads. Other solutions I've considered: - Reintrduce DDI strap checks on SKL. Unfortunately we just don't have any idea how reliable they are on real production hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A") does suggest that not very. Sadly that commit is very poor in details :/ Also the systems (Asrock B250M-HDV at least) fixed by commit 41e35ffb380b ("drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin") might still not work since we don't know what their straps indicate. Stupid me for not asking the reporter to check those at the time :( We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k both MS-7B54/Z370M) that also declare both DDI A and DDI E in VBT to use AUX A, and on these the DDI A strap is also set. There doesn't seem to be anything hooked up to either DDI however. But given the DDI A strap is wrong on these it might well be wrong on the Asrock too. Most other CI machines seem to have straps that generally match the VBT. fi-kbl-soraka is an exception though as DDI D strap is not set, but it is declared in VBT as a DP++ port. No idea if there's a real physical port to go with it or not. - Some kind of quirk just for the cases where both DDI A and DDI E are present in VBT. Might be feasible given we've ignored DDI A in these cases up to now successfully. But feels rather unsatisfactory, and not very future proof against funny VBTs. References: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com
2023-04-17 13:17:27 +00:00
/*
* If this fails, presume the DPCD answer came
* from some other port using the same AUX CH.
*
* FIXME maybe cleaner to check this before the
* DPCD read? Would need sort out the VDD handling...
*/
if (!intel_digital_port_connected(encoder)) {
drm_info(&dev_priv->drm,
"[ENCODER:%d:%s] HPD is down, disabling eDP\n",
encoder->base.base.id, encoder->base.name);
goto out_vdd_off;
}
/*
* Unfortunately even the HPD based detection fails on
* eg. Asus B360M-A (CFL+CNP), so as a last resort fall
* back to checking for a VGA branch device. Only do this
* on known affected platforms to minimize false positives.
*/
if (DISPLAY_VER(dev_priv) == 9 && drm_dp_is_branch(intel_dp->dpcd) &&
(intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_TYPE_MASK) ==
DP_DWN_STRM_PORT_TYPE_ANALOG) {
drm_info(&dev_priv->drm,
"[ENCODER:%d:%s] VGA converter detected, disabling eDP\n",
encoder->base.base.id, encoder->base.name);
goto out_vdd_off;
}
drm/i915: Check HPD live state during eDP probe We need to untangle the mess where some SKL machines (at least) declare both DDI A and DDI E to be present in their VBT, and both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a real DP->VGA converter. Currently that is handled by checking the VBT child devices for conflicts before output probing. But that kind of solution will not work for the ADL phantom dual eDP VBTs. I think on those we just have to probe the eDP first. And would be nice to use the same probe scheme for everything. On these SKL systems if we probe DDI A first (which is only natural given it's declared by VBT first) we will get an answer via AUX, but it came from the DP->VGA converter hooked to the DDI E, not DDI A. Thus we mistakenly register eDP on DDI A and screw up the real DP device in DDI E. To fix this let's check the HPD live state during the eDP probe. If we got an answer via DPCD but HPD is still down let's assume we got the answer from someone else. Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and I also tested turning off all HPD hardware prior to loading i915 to make sure it all comes up properly. And I simulated the failure path too by not turning on HPD sense and that correctly gave up on eDP. I *think* Windows might just fully depend on HPD here. I couldn't really find any other way they probe displays. And I did find code where they also check the live state prior to AUX transfers (something Imre and I have also talked about perhaps doing). That would also solve this as we'd not succeed in the eDP probe DPCD reads. Other solutions I've considered: - Reintrduce DDI strap checks on SKL. Unfortunately we just don't have any idea how reliable they are on real production hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A") does suggest that not very. Sadly that commit is very poor in details :/ Also the systems (Asrock B250M-HDV at least) fixed by commit 41e35ffb380b ("drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin") might still not work since we don't know what their straps indicate. Stupid me for not asking the reporter to check those at the time :( We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k both MS-7B54/Z370M) that also declare both DDI A and DDI E in VBT to use AUX A, and on these the DDI A strap is also set. There doesn't seem to be anything hooked up to either DDI however. But given the DDI A strap is wrong on these it might well be wrong on the Asrock too. Most other CI machines seem to have straps that generally match the VBT. fi-kbl-soraka is an exception though as DDI D strap is not set, but it is declared in VBT as a DP++ port. No idea if there's a real physical port to go with it or not. - Some kind of quirk just for the cases where both DDI A and DDI E are present in VBT. Might be feasible given we've ignored DDI A in these cases up to now successfully. But feels rather unsatisfactory, and not very future proof against funny VBTs. References: https://bugs.freedesktop.org/show_bug.cgi?id=111966 Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com
2023-04-17 13:17:27 +00:00
}
mutex_lock(&dev_priv->drm.mode_config.mutex);
drm_edid = drm_edid_read_ddc(connector, connector->ddc);
if (!drm_edid) {
/* Fallback to EDID from ACPI OpRegion, if any */
drm_edid = intel_opregion_get_edid(intel_connector);
if (drm_edid)
drm_dbg_kms(&dev_priv->drm,
"[CONNECTOR:%d:%s] Using OpRegion EDID\n",
connector->base.id, connector->name);
}
if (drm_edid) {
if (drm_edid_connector_update(connector, drm_edid) ||
!drm_edid_connector_add_modes(connector)) {
drm_edid_connector_update(connector, NULL);
drm_edid_free(drm_edid);
drm_edid = ERR_PTR(-EINVAL);
}
} else {
drm_edid = ERR_PTR(-ENOENT);
}
intel_bios_init_panel_late(dev_priv, &intel_connector->panel, encoder->devdata,
IS_ERR(drm_edid) ? NULL : drm_edid);
intel_panel_add_edid_fixed_modes(intel_connector, true);
/* MSO requires information from the EDID */
intel_edp_mso_init(intel_dp);
/* multiply the mode clock and horizontal timings for MSO */
list_for_each_entry(fixed_mode, &intel_connector->panel.fixed_modes, head)
intel_edp_mso_mode_fixup(intel_connector, fixed_mode);
/* fallback to VBT if available for eDP */
if (!intel_panel_preferred_fixed_mode(intel_connector))
intel_panel_add_vbt_lfp_fixed_mode(intel_connector);
mutex_unlock(&dev_priv->drm.mode_config.mutex);
if (!intel_panel_preferred_fixed_mode(intel_connector)) {
drm_info(&dev_priv->drm,
"[ENCODER:%d:%s] failed to find fixed mode for the panel, disabling eDP\n",
encoder->base.base.id, encoder->base.name);
goto out_vdd_off;
}
intel_panel_init(intel_connector, drm_edid);
intel_edp_backlight_setup(intel_dp, intel_connector);
intel_edp_add_properties(intel_dp);
intel_pps_init_late(intel_dp);
return true;
out_vdd_off:
intel_pps_vdd_off_sync(intel_dp);
return false;
}
drm/i915: Implement Link Rate fallback on Link training failure If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the modes. It will redo the modeset on the current mode at lower link rate or if the current mode gets pruned due to lower link constraints then, it will send a hotplug uevent for userspace to handle it. This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4, 4.3.1.6. This patch is a resend of the original commit id (233ce881dd91fb "drm/i915: Implement Link Rate fallback on Link training failure") which got reverted in this commit id (afc1ebf4562a14 Revert "drm/i915: Implement Link Rate fallback on Link training failure") due to CI failures. After investigating the CI failures it was found that these were essentially the failures which were always there but hidden because they used to be DRM_DEBUG_KMS messages for link failures so never got caught by CI. But now this patch actually throws DRM_ERROR if the link training fails at RBR and 1 lane. So it caught these link train failures. There were two failures: 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop without eDP on Port A. But our VBT initialization code in the driver writes VBT defaults in a way that it always sets DP flag on Port A and this does not get cleared after parsing the VBT outputs. This has been fixed in commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate errors from intel_bios_init()) 2. On ILK-650 desktop - This was happening because of a bad monitor desktop combination. I switched the monitor in the CI lab and that helped get rid of the link failures on ILK system. v10: * Rebase on drm-tip and resend after revert v9: * Use the trimmed max values of link rate/lane count based on link train fallback (Daniel Vetter) v8: * Set link_status to BAD first and then call mode_valid (Jani Nikula) v7: Remove the redundant variable in previous patch itself v6: * Obtain link rate index from fallback_link_rate using the helper intel_dp_link_rate_index (Jani Nikula) * Include fallback within intel_dp_start_link_train (Jani Nikula) v5: * Move set link status to drm core (Daniel Vetter, Jani Nikula) v4: * Add fallback support for non DDI platforms too * Set connector->link status inside set_link_status function (Jani Nikula) v3: * Set link status property to BAd unconditionally (Jani Nikula) * Dont use two separate variables link_train_failed and link_status to indicate same thing (Jani Nikula) v2: * Squashed a few patches (Jani Nikula) Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <Harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
2017-04-06 13:44:19 +00:00
static void intel_dp_modeset_retry_work_fn(struct work_struct *work)
{
struct intel_connector *intel_connector;
struct drm_connector *connector;
intel_connector = container_of(work, typeof(*intel_connector),
modeset_retry_work);
connector = &intel_connector->base;
drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s]\n", connector->base.id,
connector->name);
drm/i915: Implement Link Rate fallback on Link training failure If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the modes. It will redo the modeset on the current mode at lower link rate or if the current mode gets pruned due to lower link constraints then, it will send a hotplug uevent for userspace to handle it. This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4, 4.3.1.6. This patch is a resend of the original commit id (233ce881dd91fb "drm/i915: Implement Link Rate fallback on Link training failure") which got reverted in this commit id (afc1ebf4562a14 Revert "drm/i915: Implement Link Rate fallback on Link training failure") due to CI failures. After investigating the CI failures it was found that these were essentially the failures which were always there but hidden because they used to be DRM_DEBUG_KMS messages for link failures so never got caught by CI. But now this patch actually throws DRM_ERROR if the link training fails at RBR and 1 lane. So it caught these link train failures. There were two failures: 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop without eDP on Port A. But our VBT initialization code in the driver writes VBT defaults in a way that it always sets DP flag on Port A and this does not get cleared after parsing the VBT outputs. This has been fixed in commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate errors from intel_bios_init()) 2. On ILK-650 desktop - This was happening because of a bad monitor desktop combination. I switched the monitor in the CI lab and that helped get rid of the link failures on ILK system. v10: * Rebase on drm-tip and resend after revert v9: * Use the trimmed max values of link rate/lane count based on link train fallback (Daniel Vetter) v8: * Set link_status to BAD first and then call mode_valid (Jani Nikula) v7: Remove the redundant variable in previous patch itself v6: * Obtain link rate index from fallback_link_rate using the helper intel_dp_link_rate_index (Jani Nikula) * Include fallback within intel_dp_start_link_train (Jani Nikula) v5: * Move set link status to drm core (Daniel Vetter, Jani Nikula) v4: * Add fallback support for non DDI platforms too * Set connector->link status inside set_link_status function (Jani Nikula) v3: * Set link status property to BAd unconditionally (Jani Nikula) * Dont use two separate variables link_train_failed and link_status to indicate same thing (Jani Nikula) v2: * Squashed a few patches (Jani Nikula) Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <Harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
2017-04-06 13:44:19 +00:00
/* Grab the locks before changing connector property*/
mutex_lock(&connector->dev->mode_config.mutex);
/* Set connector link status to BAD and send a Uevent to notify
* userspace to do a modeset.
*/
drm_connector_set_link_status_property(connector,
DRM_MODE_LINK_STATUS_BAD);
drm/i915: Implement Link Rate fallback on Link training failure If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the modes. It will redo the modeset on the current mode at lower link rate or if the current mode gets pruned due to lower link constraints then, it will send a hotplug uevent for userspace to handle it. This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4, 4.3.1.6. This patch is a resend of the original commit id (233ce881dd91fb "drm/i915: Implement Link Rate fallback on Link training failure") which got reverted in this commit id (afc1ebf4562a14 Revert "drm/i915: Implement Link Rate fallback on Link training failure") due to CI failures. After investigating the CI failures it was found that these were essentially the failures which were always there but hidden because they used to be DRM_DEBUG_KMS messages for link failures so never got caught by CI. But now this patch actually throws DRM_ERROR if the link training fails at RBR and 1 lane. So it caught these link train failures. There were two failures: 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop without eDP on Port A. But our VBT initialization code in the driver writes VBT defaults in a way that it always sets DP flag on Port A and this does not get cleared after parsing the VBT outputs. This has been fixed in commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate errors from intel_bios_init()) 2. On ILK-650 desktop - This was happening because of a bad monitor desktop combination. I switched the monitor in the CI lab and that helped get rid of the link failures on ILK system. v10: * Rebase on drm-tip and resend after revert v9: * Use the trimmed max values of link rate/lane count based on link train fallback (Daniel Vetter) v8: * Set link_status to BAD first and then call mode_valid (Jani Nikula) v7: Remove the redundant variable in previous patch itself v6: * Obtain link rate index from fallback_link_rate using the helper intel_dp_link_rate_index (Jani Nikula) * Include fallback within intel_dp_start_link_train (Jani Nikula) v5: * Move set link status to drm core (Daniel Vetter, Jani Nikula) v4: * Add fallback support for non DDI platforms too * Set connector->link status inside set_link_status function (Jani Nikula) v3: * Set link status property to BAd unconditionally (Jani Nikula) * Dont use two separate variables link_train_failed and link_status to indicate same thing (Jani Nikula) v2: * Squashed a few patches (Jani Nikula) Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <Harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
2017-04-06 13:44:19 +00:00
mutex_unlock(&connector->dev->mode_config.mutex);
/* Send Hotplug uevent so userspace can reprobe */
drm_kms_helper_connector_hotplug_event(connector);
drm/i915: Implement Link Rate fallback on Link training failure If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the modes. It will redo the modeset on the current mode at lower link rate or if the current mode gets pruned due to lower link constraints then, it will send a hotplug uevent for userspace to handle it. This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4, 4.3.1.6. This patch is a resend of the original commit id (233ce881dd91fb "drm/i915: Implement Link Rate fallback on Link training failure") which got reverted in this commit id (afc1ebf4562a14 Revert "drm/i915: Implement Link Rate fallback on Link training failure") due to CI failures. After investigating the CI failures it was found that these were essentially the failures which were always there but hidden because they used to be DRM_DEBUG_KMS messages for link failures so never got caught by CI. But now this patch actually throws DRM_ERROR if the link training fails at RBR and 1 lane. So it caught these link train failures. There were two failures: 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop without eDP on Port A. But our VBT initialization code in the driver writes VBT defaults in a way that it always sets DP flag on Port A and this does not get cleared after parsing the VBT outputs. This has been fixed in commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate errors from intel_bios_init()) 2. On ILK-650 desktop - This was happening because of a bad monitor desktop combination. I switched the monitor in the CI lab and that helped get rid of the link failures on ILK system. v10: * Rebase on drm-tip and resend after revert v9: * Use the trimmed max values of link rate/lane count based on link train fallback (Daniel Vetter) v8: * Set link_status to BAD first and then call mode_valid (Jani Nikula) v7: Remove the redundant variable in previous patch itself v6: * Obtain link rate index from fallback_link_rate using the helper intel_dp_link_rate_index (Jani Nikula) * Include fallback within intel_dp_start_link_train (Jani Nikula) v5: * Move set link status to drm core (Daniel Vetter, Jani Nikula) v4: * Add fallback support for non DDI platforms too * Set connector->link status inside set_link_status function (Jani Nikula) v3: * Set link status property to BAd unconditionally (Jani Nikula) * Dont use two separate variables link_train_failed and link_status to indicate same thing (Jani Nikula) v2: * Squashed a few patches (Jani Nikula) Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <Harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
2017-04-06 13:44:19 +00:00
}
bool
intel_dp_init_connector(struct intel_digital_port *dig_port,
struct intel_connector *intel_connector)
{
struct drm_connector *connector = &intel_connector->base;
struct intel_dp *intel_dp = &dig_port->dp;
struct intel_encoder *intel_encoder = &dig_port->base;
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
drm/i915: Nuke intel_digital_port->port Remove intel_digital_port->port and replace its users with intel_encoder->port. intel_encoder->port is a superset of intel_digital_port->port, and it works correctly even for MST encoders. v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK) Performed with cocci: @@ @@ struct intel_digital_port { ... - enum port port; ... } @@ struct intel_digital_port *D; expression E; @@ - D->port = E; @@ struct intel_digital_port *D; @@ - D->port + D->base.port @ expression E; @@ ( - dp_to_dig_port(E)->port + dp_to_dig_port(E)->base.port | - enc_to_dig_port(E)->port + to_intel_encoder(E)->port ) @@ expression E; @@ - to_intel_encoder(&E->base) + E @@ struct intel_digital_port *D; identifier I, M; @@ I = &D->base <... ( - D->base.M + I->M | - &D->base + I ) ...> @@ identifier D; expression E; identifier M; @@ D = enc_to_dig_port(&E->base) <... ( - D->base.M + E->M | - &D->base + E ) ...> @@ identifier D, DP; expression E; identifier M; @@ DP = enc_to_intel_dp(&E->base) <... ( - dp_to_dig_port(DP)->base.M + E->M | - &dp_to_dig_port(DP)->base + E ) ...> @@ expression E; identifier M; @@ ( - enc_to_dig_port(&E->base)->base.M + E->M | - enc_to_dig_port(&E->base)->base + E | - enc_to_mst(&E->base)->primary->base.port + E->port ) @@ expression E; identifier D; @@ - struct intel_digital_port *D = E; ... when != D Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> 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/20171109152434.32074-1-ville.syrjala@linux.intel.com
2017-11-09 15:24:34 +00:00
enum port port = intel_encoder->port;
enum phy phy = intel_port_to_phy(dev_priv, port);
int type;
drm/i915: Implement Link Rate fallback on Link training failure If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the modes. It will redo the modeset on the current mode at lower link rate or if the current mode gets pruned due to lower link constraints then, it will send a hotplug uevent for userspace to handle it. This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4, 4.3.1.6. This patch is a resend of the original commit id (233ce881dd91fb "drm/i915: Implement Link Rate fallback on Link training failure") which got reverted in this commit id (afc1ebf4562a14 Revert "drm/i915: Implement Link Rate fallback on Link training failure") due to CI failures. After investigating the CI failures it was found that these were essentially the failures which were always there but hidden because they used to be DRM_DEBUG_KMS messages for link failures so never got caught by CI. But now this patch actually throws DRM_ERROR if the link training fails at RBR and 1 lane. So it caught these link train failures. There were two failures: 1. On SKL 6700k this was because the machine in CI lab is a SKL desktop without eDP on Port A. But our VBT initialization code in the driver writes VBT defaults in a way that it always sets DP flag on Port A and this does not get cleared after parsing the VBT outputs. This has been fixed in commit id (bb1d132935c2f8 "drm/i915/vbt: split out defaults that are set when there is no VBT) and (665788572c6410b "drm/i915/vbt: don't propagate errors from intel_bios_init()) 2. On ILK-650 desktop - This was happening because of a bad monitor desktop combination. I switched the monitor in the CI lab and that helped get rid of the link failures on ILK system. v10: * Rebase on drm-tip and resend after revert v9: * Use the trimmed max values of link rate/lane count based on link train fallback (Daniel Vetter) v8: * Set link_status to BAD first and then call mode_valid (Jani Nikula) v7: Remove the redundant variable in previous patch itself v6: * Obtain link rate index from fallback_link_rate using the helper intel_dp_link_rate_index (Jani Nikula) * Include fallback within intel_dp_start_link_train (Jani Nikula) v5: * Move set link status to drm core (Daniel Vetter, Jani Nikula) v4: * Add fallback support for non DDI platforms too * Set connector->link status inside set_link_status function (Jani Nikula) v3: * Set link status property to BAd unconditionally (Jani Nikula) * Dont use two separate variables link_train_failed and link_status to indicate same thing (Jani Nikula) v2: * Squashed a few patches (Jani Nikula) Acked-by: Tony Cheng <tony.cheng@amd.com> Acked-by: Harry Wentland <Harry.wentland@amd.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
2017-04-06 13:44:19 +00:00
/* Initialize the work for modeset in case of link train failure */
INIT_WORK(&intel_connector->modeset_retry_work,
intel_dp_modeset_retry_work_fn);
if (drm_WARN(dev, dig_port->max_lanes < 1,
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
"Not enough lanes (%d) for DP on [ENCODER:%d:%s]\n",
dig_port->max_lanes, intel_encoder->base.base.id,
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
intel_encoder->base.name))
return false;
intel_dp->reset_link_params = true;
intel_dp->pps.pps_pipe = INVALID_PIPE;
intel_dp->pps.active_pipe = INVALID_PIPE;
/* Preserve the current hw state. */
intel_dp->DP = intel_de_read(dev_priv, intel_dp->output_reg);
intel_dp->attached_connector = intel_connector;
if (_intel_dp_is_port_edp(dev_priv, intel_encoder->devdata, port)) {
/*
* Currently we don't support eDP on TypeC ports, although in
* theory it could work on TypeC legacy ports.
*/
drm/i915/display/dp: Make WARN* drm specific where drm_device 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_device or drm_i915_private struct pointer is readily available. The conversion was done automatically with below coccinelle semantic patch. checkpatch errors/warnings are fixed manually. @rule1@ identifier func, T; @@ func(...) { ... struct drm_device *T = ...; <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule2@ identifier func, T; @@ func(struct drm_device *T,...) { <... ( -WARN( +drm_WARN(T, ...) | -WARN_ON( +drm_WARN_ON(T, ...) | -WARN_ONCE( +drm_WARN_ONCE(T, ...) | -WARN_ON_ONCE( +drm_WARN_ON_ONCE(T, ...) ) ...> } @rule3@ 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, ...) ) ...+> } @rule4@ 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/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
2020-02-20 16:55:04 +00:00
drm_WARN_ON(dev, intel_phy_is_tc(dev_priv, phy));
type = DRM_MODE_CONNECTOR_eDP;
intel_encoder->type = INTEL_OUTPUT_EDP;
/* eDP only on port B and/or C on vlv/chv */
if (drm_WARN_ON(dev, (IS_VALLEYVIEW(dev_priv) ||
IS_CHERRYVIEW(dev_priv)) &&
port != PORT_B && port != PORT_C))
return false;
} else {
type = DRM_MODE_CONNECTOR_DisplayPort;
}
drm/i915/dp: Ensure sink rate values are always valid Atm, there are no sink rate values set for DP (vs. eDP) sinks until the DPCD capabilities are successfully read from the sink. During this time intel_dp->num_common_rates is 0 which can lead to a intel_dp->common_rates[-1] (*) access, which is an undefined behaviour, in the following cases: - In intel_dp_sync_state(), if the encoder is enabled without a sink connected to the encoder's connector (BIOS enabled a monitor, but the user unplugged the monitor until the driver loaded). - In intel_dp_sync_state() if the encoder is enabled with a sink connected, but for some reason the DPCD read has failed. - In intel_dp_compute_link_config() if modesetting a connector without a sink connected on it. - In intel_dp_compute_link_config() if modesetting a connector with a a sink connected on it, but before probing the connector first. To avoid the (*) access in all the above cases, make sure that the sink rate table - and hence the common rate table - is always valid, by setting a default minimum sink rate when registering the connector before anything could use it. I also considered setting all the DP link rates by default, so that modesetting with higher resolution modes also succeeds in the last two cases above. However in case a sink is not connected that would stop working after the first modeset, due to the LT fallback logic. So this would need more work, beyond the scope of this fix. As I mentioned in the previous patch, I don't think the issue this patch fixes is user visible, however it is an undefined behaviour by definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. v2: Clear the default sink rates, before initializing these for eDP. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com
2021-10-18 14:34:17 +00:00
intel_dp_set_default_sink_rates(intel_dp);
intel_dp_set_default_max_sink_lane_count(intel_dp);
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
intel_dp->pps.active_pipe = vlv_active_pipe(intel_dp);
intel_dp_aux_init(intel_dp);
intel_connector->dp.dsc_decompression_aux = &intel_dp->aux;
drm_dbg_kms(&dev_priv->drm,
"Adding %s connector on [ENCODER:%d:%s]\n",
type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
intel_encoder->base.base.id, intel_encoder->base.name);
drm_connector_init_with_ddc(dev, connector, &intel_dp_connector_funcs,
type, &intel_dp->aux.ddc);
drm_connector_helper_add(connector, &intel_dp_connector_helper_funcs);
if (!HAS_GMCH(dev_priv) && DISPLAY_VER(dev_priv) < 12)
connector->interlace_allowed = true;
intel_connector->polled = DRM_CONNECTOR_POLL_HPD;
intel_connector_attach_encoder(intel_connector, intel_encoder);
if (HAS_DDI(dev_priv))
intel_connector->get_hw_state = intel_ddi_connector_get_hw_state;
else
intel_connector->get_hw_state = intel_connector_get_hw_state;
drm/i915/dp: Fix DSC state HW readout for SST connectors [ Upstream commit d725ce9d7c78fb4e22c6c7676106e135ade14fa8 ] Commit 0848814aa296 ("drm/i915/dp: Fix connector DSC HW state readout") moved the DSC HW state readout to a connector specific hook, however only added the hook for DP MST connectors, not for DP SST ones. Fix adding the hook for SST connectors as well. This fixes the following warn on platforms where BIOS enables DSC: [ 66.208601] i915 0000:00:02.0: drm_WARN_ON(!connector->dp.dsc_decompression_aux || !connector->dp.dsc_decompression_enabled) ... [ 66.209024] RIP: 0010:intel_dp_sink_disable_decompression+0x76/0x110 [i915] ... [ 66.209333] ? intel_dp_sink_disable_decompression+0x76/0x110 [i915] ... [ 66.210068] intel_disable_ddi+0x135/0x1d0 [i915] [ 66.210302] intel_encoders_disable+0x9b/0xc0 [i915] [ 66.210565] hsw_crtc_disable+0x153/0x170 [i915] [ 66.210823] intel_old_crtc_state_disables+0x52/0xb0 [i915] [ 66.211107] intel_atomic_commit_tail+0x5cf/0x1330 [i915] [ 66.211366] intel_atomic_commit+0x39d/0x3f0 [i915] [ 66.211612] ? intel_atomic_commit+0x39d/0x3f0 [i915] [ 66.211872] drm_atomic_commit+0x9d/0xd0 [drm] [ 66.211921] ? __pfx___drm_printfn_info+0x10/0x10 [drm] [ 66.211975] intel_initial_commit+0x1a8/0x260 [i915] [ 66.212234] intel_display_driver_probe+0x2a/0x80 [i915] [ 66.212479] i915_driver_probe+0x7c6/0xc60 [i915] [ 66.212664] ? drm_privacy_screen_get+0x168/0x190 [drm] [ 66.212711] i915_pci_probe+0xe2/0x1c0 [i915] Fixes: 0848814aa296 ("drm/i915/dp: Fix connector DSC HW state readout") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10410 Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240311145626.2454923-1-imre.deak@intel.com (cherry picked from commit 7a51a2aa2384ea8bee76698ae586a2bea5b8ddb5) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-03-11 14:56:26 +00:00
intel_connector->sync_state = intel_dp_connector_sync_state;
if (!intel_edp_init_connector(intel_dp, intel_connector)) {
intel_dp_aux_fini(intel_dp);
goto fail;
}
intel_dp_set_source_rates(intel_dp);
intel_dp_set_common_rates(intel_dp);
intel_dp_reset_max_link_params(intel_dp);
/* init MST on ports that can support it */
intel_dp_mst_encoder_init(dig_port,
intel_connector->base.base.id);
intel_dp_add_properties(intel_dp, connector);
if (is_hdcp_supported(dev_priv, port) && !intel_dp_is_edp(intel_dp)) {
int ret = intel_dp_hdcp_init(dig_port, intel_connector);
if (ret)
drm_dbg_kms(&dev_priv->drm,
"HDCP init failed, skipping.\n");
}
intel_dp->frl.is_trained = false;
intel_dp->frl.trained_rate_gbps = 0;
drm/i915/display: Support PSR Multiple Instances It is a preliminary work for supporting multiple EDP PSR and DP PanelReplay. And it refactors singleton PSR to Multi Transcoder supportable PSR. And this moves and renames the i915_psr structure of drm_i915_private's to intel_dp's intel_psr structure. It also causes changes in PSR interrupt handling routine for supporting multiple transcoders. But it does not change the scenario and timing of enabling and disabling PSR. And it not support multiple pipes with a single transcoder PSR case yet. v2: Fix indentation and add comments v3: Remove Blank line v4: Rebased v5: Rebased and Addressed Anshuman's review comment. - Move calling of intel_psr_init() to intel_dp_init_connector() v6: Address Anshuman's review comments - Remove wrong comments and add comments for a limit of supporting of a single pipe PSR v7: Update intel_psr_compute_config() for supporting multiple transcoder PSR on BDW+ v8: Address Anshuman's review comments - Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn() v9: Fix commit message v10: Rebased v11: Address Jose's review comment. - Reorder calling order of intel_psr2_program_trans_man_trk_ctl(). - In order to reduce changes keep the old name for drm_i915_private. - Change restrictions of multiple instances of PSR. v12: Address Jose's review comment. - Change the calling of intel_psr2_program_trans_man_trk_ctl() into commit_pipe_config(). - Change a checking order of CAN_PSR() and connector_status to original on i915_psr_sink_status_show(). - Drop unneeded intel_dp_update_pipe() function. - In order to wait a specific encoder which belong to crtc_state on intel_psr_wait_for_idle(), add checking of encoder. - Add an whitespace to comments. v13: Rebased and Address Jose's review comment. - Add and use for_each_intel_psr_enabled_encoder() macro. - In order to use correct frontbuffer_bit for each pipe, fix intel_psr_invalidate() and intel_psr_flush(). - Remove redundant or unneeded codes. - Update comments. v14: Address Jose's review comment - Add and use for_each_intel_encoder_can_psr() macro and for_each_intel_encoder_mask_can_psr() macro. - Add source_support member variable into intel_psr structure. - Update CAN_PSR() macro that checks source_support. - Move encoder's PSR availity check to psr_init() from psr_compute_config(). - Remove redundant or unneeded codes. v15: Remove wrong mutex lock/unlock of PSR from intel_psr2_program_trans_man_trk_ctl() Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204134015.419036-1-gwan-gyeong.mun@intel.com
2021-02-04 13:40:14 +00:00
intel_psr_init(intel_dp);
return true;
fail:
intel_display_power_flush_work(dev_priv);
drm_connector_cleanup(connector);
return false;
}
void intel_dp_mst_suspend(struct drm_i915_private *dev_priv)
2014-05-02 04:02:48 +00:00
{
struct intel_encoder *encoder;
if (!HAS_DISPLAY(dev_priv))
return;
for_each_intel_encoder(&dev_priv->drm, encoder) {
struct intel_dp *intel_dp;
2014-05-02 04:02:48 +00:00
if (encoder->type != INTEL_OUTPUT_DDI)
continue;
intel_dp = enc_to_intel_dp(encoder);
if (!intel_dp_mst_source_support(intel_dp))
2014-05-02 04:02:48 +00:00
continue;
if (intel_dp->is_mst)
drm_dp_mst_topology_mgr_suspend(&intel_dp->mst_mgr);
2014-05-02 04:02:48 +00:00
}
}
void intel_dp_mst_resume(struct drm_i915_private *dev_priv)
2014-05-02 04:02:48 +00:00
{
struct intel_encoder *encoder;
2014-05-02 04:02:48 +00:00
if (!HAS_DISPLAY(dev_priv))
return;
for_each_intel_encoder(&dev_priv->drm, encoder) {
struct intel_dp *intel_dp;
int ret;
2014-05-02 04:02:48 +00:00
if (encoder->type != INTEL_OUTPUT_DDI)
continue;
intel_dp = enc_to_intel_dp(encoder);
if (!intel_dp_mst_source_support(intel_dp))
continue;
2014-05-02 04:02:48 +00:00
drm/dp_mst: Add basic topology reprobing when resuming Finally! For a very long time, our MST helpers have had one very annoying issue: They don't know how to reprobe the topology state when coming out of suspend. This means that if a user has a machine connected to an MST topology and decides to suspend their machine, we lose all topology changes that happened during that period. That can be a big problem if the machine was connected to a different topology on the same port before resuming, as we won't bother reprobing any of the ports and likely cause the user's monitors not to come back up as expected. So, we start fixing this by teaching our MST helpers how to reprobe the link addresses of each connected topology when resuming. As it turns out, the behavior that we want here is identical to the behavior we want when initially probing a newly connected MST topology, with a couple of important differences: - We need to be more careful about handling the potential races between events from the MST hub that could change the topology state as we're performing the link address reprobe - We need to be more careful about handling unlikely state changes on ports - such as an input port turning into an output port, something that would be far more likely to happen in situations like the MST hub we're connected to being changed while we're suspend Both of which have been solved by previous commits. That leaves one requirement: - We need to prune any MST ports in our in-memory topology state that were present when suspending, but have not appeared in the post-resume link address response from their parent branch device Which we can now handle in this commit by modifying drm_dp_send_link_address(). We then introduce suspend/resume reprobing by introducing drm_dp_mst_topology_mgr_invalidate_mstb(), which we call in drm_dp_mst_topology_mgr_suspend() to traverse the in-memory topology state to indicate that each mstb needs it's link address resent and PBN resources reprobed. On resume, we start back up &mgr->work and have it reprobe the topology in the same way we would on a hotplug, removing any leftover ports that no longer appear in the topology state. Changes since v4: * Split indenting changes in drm_dp_mst_topology_mgr_resume() into a separate patch * Only fire hotplugs when something has actually changed after a link address probe * Don't try to change port->connector at all on ports, just throw out ports that need their connectors removed to make things easier. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sean Paul <sean@poorly.run> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-14-lyude@redhat.com
2019-06-17 23:57:33 +00:00
ret = drm_dp_mst_topology_mgr_resume(&intel_dp->mst_mgr,
true);
if (ret) {
intel_dp->is_mst = false;
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr,
false);
}
2014-05-02 04:02:48 +00:00
}
}