- 30 Jul, 2021 21 commits
-
-
Lucas De Marchi authored
Cleanup remaining cases that we find CNL in the codebase. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-22-lucas.demarchi@intel.com
-
Lucas De Marchi authored
With the removal of CNL, let's consider ICL as the first platform using those constants. Signed-off-by:
-
Lucas De Marchi authored
Consider the new WOPCM size as starting in ICL rather than CNL since the latter is being removed from the driver. Signed-off-by:
-
Lucas De Marchi authored
Remove references for CNL from pch detection. Signed-off-by:
-
Lucas De Marchi authored
Remove support for CNL as it's highly untested, probably broken, and there is no real platform that requires this code. This is part of CNL removal from i915. Signed-off-by:
-
Lucas De Marchi authored
Remove special handling of PORT_F in i915_irq.c and only do it for DISPLAY_VER == 11. Signed-off-by:
-
Lucas De Marchi authored
With the removal of CNL, let's consider GLK as the first platform using those constants since GLK has DISPLAY_VER == 10. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_display_power.c. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in skl_universal_plane.c. Remove code and rename functions/macros accordingly to use ICL prefix. Signed-off-by:
-
Lucas De Marchi authored
Only one reference to CNL that is not needed, but code is the same for DISPLAY_VER >= 11, so leave the code around and just remove the special case for CNL. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_ddi.c. A lot of special code for CNL can be removed. There were some __cnl.*() functions that were created to share the implementation between ICL and CNL. Those are now embedded in the only caller, in ICL. Remove code and rename functions/macros accordingly to use ICL prefix for those that are still needed. Verified with: make EXTRA_CFLAGS=-Wunused drivers/gpu/drm/i915/display/intel_dpll_mgr.o Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_dp.c. Remove code and rename functions/macros accordingly to use ICL prefix. Signed-off-by:
-
Lucas De Marchi authored
Remove DMC firmware for CNL. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728215946.1573015-9-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Only one reference to CNL that is not needed, but code is the same for DISPLAY_VER >= 11, so leave the code around and just remove the special case for CNL. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK. We don't need to handle CNL explicitly in intel_ddi.c. Remove code and rename functions/macros accordingly to use ICL prefix. There's one leftover reference to cnl that comes from the struct intel_ddi_buf_trans. This will be renamed later when we get rid of the additional CNL tables. Signed-off-by:
-
Lucas De Marchi authored
No need for special CNL handling as there is no real platform with that configuration. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK, that doesn't have combo phys. We don't need to handle CNL explicitly in intel_combo_phy.c. Remove code and rename functions/macros accordingly to use ICL prefix. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK, so we don't need any checks and supporting code for CNL. For DISPLAY_VER >= 11, ilk_load_csc_matrix() is not used, so make it handle GLK only. Signed-off-by:
-
Lucas De Marchi authored
The only real platform with DISPLAY_VER == 10 is GLK, so we don't need any checks and supporting code for CNL. Remove code and rename functions/macros accordingly. Signed-off-by:
-
Lucas De Marchi authored
Explicit support for CNL is being removed from the driver as it's not expected to work. Remove the workaround for PORT_F from display/intel_bios.c so we can also remove the generic DISPLAY_VER == 10 calls to intel_ddi_init(): the only platform with that display version is already handled separately (GLK). Signed-off-by:
-
- 29 Jul, 2021 10 commits
-
-
Khaled Almahallawy authored
Source needs to write DPCD 103-106 after receiving a PHY request to change swing/pre-emphasis after reading DPCD 206-207. This is especially needed if there is a retimer between source and sink and the retimer implements AUX_CH interception scheme to manage DP PHY settings (e.g. adjusting Swing/Pre-emphasis equalization level) for DP output channel. If the source doesn't write to DPCD 103-106, the retimer may not output the requested swing/pre-emphasis and eventually we fail compliance. v2: Rebase and use crtc->lane_count (Imre) Signed-off-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210226081554.984307-1-khaled.almahallawy@intel.comReviewed-by:
-
Animesh Manna authored
In verify_mpllb_state() encoder is retrieved from best_encoder of connector_state. As there will be only one connector_state for bigjoiner and checking encoder may not be needed for bigjoiner-slave. This code path related to mpll is done on dg2 and need this fix to avoid null pointer dereference issue. Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723174239.1551352-30-matthew.d.roper@intel.com
-
Gwan-gyeong Mun authored
The PSR enable/disable sequences now require that we program an extra register in the PHY to adjust the lane disable power setting. Bspec: 49274 Bspec: 53885 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723174239.1551352-29-matthew.d.roper@intel.com
-
Matt Roper authored
Initialization of the PHY is handled by the hardware/firmware, but the driver should wait up to 25ms for the PHY to report that its calibration has completed. Bspec: 49189 Bspec: 50107 Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723174239.1551352-28-matthew.d.roper@intel.com
-
Matt Roper authored
DG2 has some changes to the expected modesetting sequences when compared to gen12. Adjust our driver logic accordingly. Although the DP sequence is pretty similar to TGL's, there are some steps that change, so let's split the handling for that out into a separate function. v2: - Switch wait_for_us() -> _wait_for() so that we can parameterize the timeout rather than duplicating the macro call. (Jani) Bspec: 54128 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Matt Roper authored
Vswing programming for SNPS PHYs is just a single step -- look up the value that corresponds to the voltage level from a table and program it into the SNPS_PHY_TX_EQ register. Bspec: 53920 Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Matt Roper authored
At the moment we don't have a proper algorithm that can be used to calculate PHY settings for arbitrary HDMI link rates. The PHY tables here should support the regular modes of real-world HDMI monitors. Bspec: 54032 Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Matt Roper authored
DG2's SNPS PHYs incorporate a dedicated port PLL called MPLLB which takes the place of the shared DPLLs we've used on past platforms. Let's add the MPLLB programming sequences; they'll be plugged into the rest of the code in future patches. Bspec: 54032 Bspec: 53881 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Nidhi Gupta <nidhi1.gupta@intel.com> Reviewed-by:
-
Matt Roper authored
ADL-P now has its own set of DDI buf translation tables (except for eDP which appears to be the same as TGL). Add the new values (last updated in bspec 2021-07-22) to the driver. v2: - Actually hook up the new tables via encoder->get_buf_trans() v3: - Create extra table wrapper structures for the tables from past platforms that we're re-using, with names that more accurately reflect the link rate they apply to on ADL-P specifically. (Jose) Bspec: 49291 Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210728221045.2363614-2-matthew.d.roper@intel.com
-
Matt Roper authored
The hardware team updates the translation tables on 2021-06-23. Let's update the driver accordingly. Bspec: 49291 Signed-off-by:
-
- 28 Jul, 2021 3 commits
-
-
Badal Nilawar authored
In discrete cards, the graphics driver shouldn't proceed with the probe or resume unless PCODE indicated everything is done, including memory training and gt bring up. For this reason, the driver probe and resume paths needs to be blocked until PCODE indicates it is done. Also, it needs to aborted if the notification never arrives. In general, the few miliseconds would be enough and the regular PCODE recommendation for the timeout was 10 seconds. However there are some rare cases where this initialization can take up to 1 minute. So, PCODE has increased the recommendation to 3 minutes so we don't fully block the device utilization when something just got delayed for whatever reason. To be on the safest side, let's accept this recommendation, since on the regular case it won't delay or block the driver initialization and resume flows Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Reviewed-by:
-
Imre Deak authored
The driver doesn't depend atm on the common mode timing generator functionality (it would be used for some power saving feature and panel timing synchronization), however DMC will corrupt the CMTG registers across DC5 entry/exit sequences unless the CMTG clock gating is disabled. This in turn can lead to at least the DPLL0/1 configuration getting stuck at their last state, which means we can't reprogram them to a new config. Add the corresponding Bspec workaround to prevent the above. v2: Fix checkpatch errors. (CI, Jose) Cc: Uma Shankar <uma.shankar@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Matt Roper authored
ADL_P requires that we disable underrun recovery when downscaling (or using the scaler for YUV420 pipe output), using DSC, or using PSR2. Otherwise we should be able to enable the underrun recovery. On DG2 we need to keep underrun recovery disabled at all times, but the chicken bit in PIPE_CHICKEN has an inverted meaning (it's an enable bit instead of disable). v2: - Reverse the condition (clear the disable bit when supported, set disable bit when not supported). Bspec: 50351 Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210727145056.2049720-1-matthew.d.roper@intel.com
-
- 27 Jul, 2021 3 commits
-
-
José Roberto de Souza authored
HDMI and DisplayPort sequences states that audio and PSR should be disabled before planes are disabled. Not following it did not caused any problems up to Alderlake-P but for this platform it causes underruns during the PSR2 disable sequence. Specification don't mention that DRRS should be disabled before planes but it looks safer to switch back to the default refresh rate before following with the rest of the pipe disable sequence. BSpec: 49191 BSpec: 49190 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
PSF GV points are an additional factor that can limit the bandwidth available to display, separate from the traditional QGV points. Whereas traditional QGV points represent possible memory clock frequencies, PSF GV points reflect possible frequencies of the memory fabric. Switching between PSF GV points has the advantage of incurring almost no memory access block time and thus does not need to be accounted for in watermark calculations. This patch adds support for those on top of regular QGV points. Those are supposed to be used simultaneously, i.e we are always at some QGV and some PSF GV point, based on the current video mode requirements. Bspec: 64631, 53998 v2: Seems that initial assumption made during ml conversation was wrong, PCode rejects any masks containing points beyond the ones returned, so even though BSpec says we have around 8 points theoretically, we can mask/unmask only those which are returned, trying to manipulate those beyond causes a failure from PCode. So switched back to generating mask from 1 - num_qgv_points, where num_qgv_points is the actual amount of points, advertised by PCode. v3: - Extended restricted qgv point mask to 0xf, as we have now 3:2 bits for PSF GV points(Matt Roper) - Replaced val2 with NULL from PCode request, since its not being used(Matt Roper) - Replaced %d to 0x%x for better readability(thanks for spotting) Signed-off-by: -
Stanislav Lisovskiy authored
According to BSpec there is now also a code 0x02, which corresponds to QGV point being rejected, this code so lets extend mask to check this. Signed-off-by:
-
- 26 Jul, 2021 2 commits
-
-
José Roberto de Souza authored
The fast path only updates cursor register what will not cause any updates in the screen when using PSR2 selective fetch. The only option that we have is to go through the slow patch that will do full atomic commit, that will trigger the PSR2 selective fetch compute and programing calls. Without this patch is possible to see a mouse movement lag in Gnome when PSR2 selective fetch is enabled. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Without this planes that were added by intel_psr2_sel_fetch_update() that intersect with pipe damaged area will not have skl_program_plane() and intel_psr2_program_plane_sel_fetch() called, causing panel to not be properly updated. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
- 25 Jul, 2021 1 commit
-
-
Lucas De Marchi authored
Commit 5a9d38b2 ("drm/i915/display: hide workaround for broken vbt in intel_bios.c") moved the workaround for broken or missing VBT to intel_bios.c. However is_port_valid() only protects the handling of different skus of the same display version. Since in intel_setup_outputs() we share the code path with version 9, this would also create port F for SKL/KBL, which does not exist. Missing VBT can be reproduced when starting a headless QEMU with no opregion available. Avoid the issue by splitting versions 9 and 10 in intel_setup_outputs(), which also makes it more clear what code path it's taking for each version. v2: move generic display version after Geminilake since that one has a different set of outputs Fixes: 5a9d38b2 ("drm/i915/display: hide workaround for broken vbt in intel_bios.c") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reported-by:
Christoph Hellwig <hch@infradead.org> Signed-off-by:
Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210722232922.3796835-1-lucas.demarchi@intel.com
-
