- 27 Jul, 2021 2 commits
-
-
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 <stanislav.lisovskiy@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210531064845.4389-2-stanislav.lisovskiy@intel.com
-
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 <jose.souza@intel.com> Reviewed-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:
Rodrigo Vivi <rodrigo.vivi@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:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210714031540.3539704-46-matthew.d.roper@intel.com
-
- 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 4 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:
-
Matt Roper authored
Extend the workaround bound to include A1 display. Bspec: 54370 Signed-off-by:
-
- 20 Jul, 2021 6 commits
-
-
Manasi Navare authored
Currently when we do the HW state readout, we dont set the shared dpll to NULL for the bigjoiner slave which should not have a DPLL assigned. So it has some garbage while the HW state readout is NULL. So explicitly reset the shared dpll for bigjoiner slave pipe. Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/3465 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Tested-by:
Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210714223414.9849-1-manasi.d.navare@intel.com
-
José Roberto de Souza authored
This is now a requirement for all display 12 and newer, not only for tigerlake. BSpec: 50422 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
José Roberto de Souza authored
Implements changes around PSR for alderlake-P: - EDP_SU_TRACK_ENABLE was removed and bit 30 now has other function - Some bits of PSR2_MAN_TRK_CTL moved and SF_PARTIAL_FRAME_UPDATE was removed setting SU_REGION_START/END_ADDR will do this job - SU_REGION_START/END_ADDR have now line granularity but will need to be aligned with DSC when the PSRS + DSC support lands BSpec: 50422 BSpec: 50424 Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
-
Vandita Kulkarni authored
Set DSC BPP to the value forced through debugfs. It can go from bpc to bpp-1. v2: Use default dsc bpp when we are just doing force_dsc_en, use default dsc bpp for invalid force_dsc_bpp values. (Jani) Signed-off-by:Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
Patnana Venkata Sai authored
This patch creates a per connector debugfs node to expose the Compressed BPP. The same node can be used from userspace to force DSC to a certain BPP(all accepted values). This is useful to verify all supported/requested compression bpp's through IGT v2: Remove unnecessary logic (Jani) v3: Drop pipe bpp in debugfs node (Vandita) v4: Minor cleanups (Vandita) v5: Fix NULL pointer dereference v6: Fix dim tool checkpatch errors Release the lock before return (Vandita) v7: Rename to file to dsc_bpp, remove unwanted dsc bpp range check from v6, permissions (Jani) Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Navare Manasi D <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:Patnana Venkata Sai <venkata.sai.patnana@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210720064907.9771-3-vandita.kulkarni@intel.com
-
Vandita Kulkarni authored
Though there is a write option available on fec_suport debugfs file, so far it has been registering with read permissions only. Suggested-by:
-
