- 30 Jul, 2021 10 commits
-
-
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 <lucas.demarchi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210729233934.2059489-1-lucas.demarchi@intel.com
-
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 2 commits
-
-
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
-
Lucas De Marchi authored
We were using GRAPHICS_VER() to handle SKL_DFSM register, which means we were not handling GLK correctly since that has GRAPHICS_VER == 9, but DISPLAY_VER == 10. Switch the entire branch to check DISPLAY_VER which makes it more in line with Bspec. Even though the Bspec has an exception for RKL in TGL_DFSM_PIPE_D_DISABLE, we don't have to do anything as the bit has disable semantic and RKL doesn't have pipe D. Bspec: 50075, 7548 Fixes: 2b5a4562 ("drm/i915/display: Simplify GLK display version tests") Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 24 Jul, 2021 1 commit
-
-
Matt Roper authored
A new step has been added to the DP modeset sequences for all platforms with display version 12 and beyond: if enabling DP MST with FEC, we need to set a chicken bit before enabling the transcoder. The chicken bit should be disabled again before disabling the transcoder (which we can do unconditionally since it shouldn't be set anyway in non-MST cases). Bspec: 49190, 54128, 55424 Signed-off-by:
-
- 23 Jul, 2021 3 commits
-
-
Rodrigo Vivi authored
PORT_A to PORT_F are regular integers defined in the enum port, while for_each_port_masked requires a bit mask for the ports. Current given mask: 0b111 Desired mask: 0b111111 I noticed this while Christoph was reporting a bug found on headless GVT configuration which bisect blamed commit 3ae04c0c ("drm/i915/bios: limit default outputs to ports A through F") v2: Avoid unnecessary line continuations as pointed by CI and Christoph Cc: Christoph Hellwig <hch@infradead.org> Fixes: 3ae04c0c ("drm/i915/bios: limit default outputs to ports A through F") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
José Roberto de Souza authored
PSR2 is not supported on DG2. Cc: Caz Yokoyama <Caz.Yokoyama@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Matt Roper authored
Although the bspec labels four of DG2's outputs as "combo PHY," the underlying PHYs in both cases are actually Synopsys PHYs that are programmed completely differently than the traditional Intel "combo" PHY units. As such, we don't want intel_phy_is_combo to take us down legacy programming paths, so just return false from it on DG2. Instead add a new intel_phy_is_snps() that will return true for all DG2 PHYs. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
- 22 Jul, 2021 6 commits
-
-
Anusha Srivatsa authored
Add support to load latest DMC version. The Release Notes mentions that this version fixes timeout issues. Cc: Madhumitha Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by:
Madhumitha Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721215238.24980-4-anusha.srivatsa@intel.com
-
Anusha Srivatsa authored
Add support to the latest DMC firmware. Cc: Madhunitha Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Signed-off-by:
-
Anusha Srivatsa authored
Lets use RUNTIME_INFO->step since all platforms now have their stepping info in intel_step.c. This makes intel_get_stepping_info() a lot simpler. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Anusha Srivatsa authored
With the addition of stepping info for all platforms, lets use macros for handling them and autogenerating code for all steps at a time. Suggested-by:
-
Matt Roper authored
DG2 doesn't have a SAGV or QGV points that determine memory bandwidth. Instead it has a constant amount of memory bandwidth available to display that does not need to be reduced based on the number of active planes. For simplicity, we'll just modify driver initialization to create a single dummy QGV point with the proper amount of memory bandwidth, rather than trying to query the pcode for this information. Bspec: 64631 Signed-off-by:
-
Matt Roper authored
DG2 does not use system DRAM information for BW_BUDDY programming or watermark workarounds, so there's no need to read this out at startup. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
