- 29 Jul, 2021 3 commits
-
-
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:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Nidhi Gupta <nidhi1.gupta@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210723174239.1551352-24-matthew.d.roper@intel.com
-
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:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-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:
Imre Deak <imre.deak@intel.com> Reviewed-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:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210726181559.80855-1-jose.souza@intel.com
-
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:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717011227.204494-3-jose.souza@intel.com
-
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:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-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 20 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:
-
Matt Roper authored
Although the BW_BUDDY registers still exist, they are not used for anything on DG2. This change is expected to hold true for future dgpu's too. Bspec: 49218 Signed-off-by:
-
Matt Roper authored
DG2 extends our DDB to four DBuf slices; pipes A+B only have access to the first two slices, whereas pipes C+D only have access to the second two. Confusingly, our bspec decided to switch from 1-based numbering of dbuf slices (S1, S2) to 0-based numbering (S0, S1, S2, S3) in Display13. At the moment we're using the 0-based number scheme for the DBUF_CTL_S() register addressing, but the 1-based number scheme in the actual slice assignment tables. We may want to consider switching the assignment over to 0-based numbering too at some point... Bspec: 49255 Bspec: 50057 Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Matt Roper authored
DG2 has outputs on DDI A-D attached to what the bspec diagram shows as "Combo PHY A-D." Note that despite being labelled "combo" the PHYs on these outputs are Synopsys PHYs rather than traditional Intel combo PHY technology. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Matt Roper authored
On DG2 we're supposed to just wait 600us after programming the well before moving on; there won't be an ack from the hardware. Bspec: 49296 Signed-off-by:
-
Matt Roper authored
DG2 has no shared DPLL's or DDI clock muxing. The Port PLL is embedded within the PHY. Bspec: 54032 Bspec: 54034 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
Note that DG2 only has a single possible refclk frequency (38.4 MHz). v2: - Drop two now-unused cdclk entries Bspec: 54034 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Matt Roper authored
As with DG1, DG2 has an ICL-style south display interface provided on the same PCI device. Add a fake PCH to ensure DG2 takes the appropriate codepaths for south display handling. Bspec: 54871, 50062, 49961, 53673 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Aditya Swarup <aditya.swarup@intel.com> Signed-off-by:
-
Paulo Zanoni authored
The current interrupt handler is getting increasingly complicated and Xe_HP changes will bring even more complexity. Let's split off a new interrupt handler starting with DG1 (i.e., when the master tile interrupt register was added to the design) and use that as the basis for the new Xe_HP changes. Now that we track the hardware IP's release number as well as the version number, we can also properly define DG1 has version "12.10" and replace the has_master_unit_irq feature flag with an IP version test. Bspec: 50875 Cc: Daniele Spurio Ceraolo <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Tomasz Lis <tomasz.lis@intel.com> Signed-off-by:
-
Matt Roper authored
As we begin applying XeHP and DG2 patches, the basic platform definitions and macros (like IS_DG2()) will be needed in both drm-intel-next and drm-intel-gt-next. Those initial definition patches are applied to a topic branch and merged to both trees. Signed-off-by: -
Matt Roper authored
DG2 has Xe_LPD display (version 13) and Xe_HPG (version 12.55) graphics. There are two variants (treated as subplatforms in the code): DG2-G10 and DG2-G11 that require independent programming in some areas (e.g., workarounds). Bspec: 44472, 44474, 46197, 48028, 48077 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Lucas De Marchi authored
XeHP SDV is a Intel
® dGPU without display. This is just the definition of some basic platform macros, by large a copy of current state of Tigerlake which does not reflect the end state of this platform. v2: - Switch to intel_step infrastructure for stepping matches. (Jani) v3: - Bring earlier in patch series and leave addition of new media engines to the engine mask for a later patch. Bspec: 44467, 48077 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Our _FEATURES macro went back to GEN7, extending each other, making it difficult to grasp what was really enabled/disabled. Take the opportunity of the GEN -> XE_HP name break and also break with the feature inheritance. For XE_HP this basically goes from GEN12 back to GEN7 coalescing the features making sure the overrides remain, remove all the display-specific features and sort it. Then also remove the definitions that would be overridden by DGFX_FEATURES and those that were 0 (since that is the default). Exception here is has_master_unit_irq: although it is a feature that started with DG1 and is true for all DGFX platforms, it's also true for XE_HP in general. Signed-off-by:
-
Lucas De Marchi authored
Besides the arch version returned by GRAPHICS_VER(), new platforms contain a "release id" to make clear the difference from one platform to another. The release id number is not formally defined by hardware until future platforms that will expose it via a new GMD_ID register. For the platforms we support before that register becomes available we will set the values in software and we can set them as we please. So the plan is to set them so we can group different features under a single GRAPHICS_VER_FULL() check. After GMD_ID is used, the usefulness of a "full version check" will be greatly reduced and will be mostly used for deciding workarounds and a few code paths. So it makes sense to keep it as a separate field from graphics_ver. Also, as a platform with `release == n` may be closer feature-wise to `n - 2` than to `n - 1`, use the word "release" rather than the more common "minor" for this This is a mix of 2 independent changes: one by me and the other by Matt Roper. v2: - Reword commit message to make it clearer why we don't call it "minor" (Matt Roper and Tvrtko) - Rename variables s/*_ver_release/*_rel/ and print them in a single line formatted as {ver}.{rel:2} (Jani and Matt Roper) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: -
Lucas De Marchi authored
Brevity is not needed here, so just spell out "* version" in the string. Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 21 Jul, 2021 3 commits
-
-
Matt Roper authored
Workarounds are documented in the bspec with an exclusive upper bound (i.e., a "fixed" stepping that no longer needs the workaround). This makes our driver's use of an inclusive upper bound for stepping ranges confusing; the differing notation between code and bspec makes it very easy for mistakes to creep in. Let's switch the upper bound of our IS_{GT,DISP}_STEP macros over to use an exclusive upper bound like the bspec does. This also has the benefit of helping make sure workarounds are properly handled for new minor steppings that show up (e.g., an A1 between the A0 and B0 we already knew about) --- if the new intermediate stepping pulls in hardware fixes early, there will be an update to the workaround definition which lets us know we need to change our code. If the new stepping does not pull a hardware fix earlier, then the new stepping will already be captured properly by the "[begin, fix)" range in the code. We'll probably need to be extra vigilant in code review of new workarounds for the near future to make sure developers notice the new semantics of workaround bounds. But we just migrated a bunch of our platforms from the IS_REVID bounds over to IS_{GT,DISP}_STEP, so people are already adjusting to the new macros and now is a good time to make this change too. [mattrope: Split out display changes to apply through intel-next tree] Signed-off-by: -
Matt Roper authored
RKL doesn't have PSR2 support, so PSR2-related workarounds no longer apply. Bspec: 53273 Signed-off-by:
-
Matt Roper authored
Bspec: 53273 Signed-off-by:
-
