summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-07-22drm/i915/dg2: Don't read DRAM infoMatt Roper
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 <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-18-matthew.d.roper@intel.com
2021-07-22drm/i915/dg2: Don't program BW_BUDDY registersMatt Roper
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 <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-17-matthew.d.roper@intel.com
2021-07-22drm/i915/dg2: Add dbuf programmingMatt Roper
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 <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-16-matthew.d.roper@intel.com
2021-07-22drm/i915/dg2: Setup display outputsMatt Roper
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 <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-15-matthew.d.roper@intel.com
2021-07-22drm/i915/dg2: Don't wait for AUX power well enable ACKsMatt Roper
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 <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-14-matthew.d.roper@intel.com
2021-07-22drm/i915/dg2: Skip shared DPLL handlingMatt Roper
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 <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-13-matthew.d.roper@intel.com
2021-07-22drm/i915/dg2: Add cdclk table and reference clockMatt Roper
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: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-12-matthew.d.roper@intel.com
2021-07-22drm/i915/dg2: Add fake PCHMatt Roper
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: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-11-matthew.d.roper@intel.com
2021-07-22drm/i915: Fork DG1 interrupt handlerPaulo Zanoni
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-5-matthew.d.roper@intel.com
2021-07-22Merge branch 'topic/xehp-dg2-definitions-2021-07-21' into drm-intel-nextMatt Roper
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 <matthew.d.roper@intel.com>
2021-07-22drm/i915/dg2: add DG2 platform infoMatt Roper
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: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-4-matthew.d.roper@intel.com
2021-07-22drm/i915/xehpsdv: add initial XeHP SDV definitionsLucas De Marchi
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: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Stuart Summers <stuart.summers@intel.com> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-3-matthew.d.roper@intel.com
2021-07-22drm/i915: Add XE_HP initial definitionsLucas De Marchi
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 <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210721223043.834562-2-matthew.d.roper@intel.com
2021-07-22drm/i915: Add release id versionLucas De Marchi
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 <lucas.demarchi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707235921.2416911-2-lucas.demarchi@intel.com (cherry picked from commit ca6374e267e2735fe382fe95de2a8a9c30c6bdb3) Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2021-07-22drm/i915: do not abbreviate version in debugfsLucas De Marchi
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: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707235921.2416911-1-lucas.demarchi@intel.com (cherry picked from commit 0f9b145a0a0ab0d3d4143c20e2ca347d8a105e33) Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2021-07-21drm/i915: Make display workaround upper bounds exclusiveMatt Roper
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 <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717051426.4120328-8-matthew.d.roper@intel.com
2021-07-21drm/i915/rkl: Wa_1408330847 no longer applies to RKLMatt Roper
RKL doesn't have PSR2 support, so PSR2-related workarounds no longer apply. Bspec: 53273 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717051426.4120328-7-matthew.d.roper@intel.com
2021-07-21drm/i915/rkl: Wa_1409767108 also applies to RKLMatt Roper
Bspec: 53273 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717051426.4120328-6-matthew.d.roper@intel.com
2021-07-21drm/i915/adl_s: Wa_14011765242 is also needed on A1 display steppingMatt Roper
Extend the workaround bound to include A1 display. Bspec: 54370 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210717051426.4120328-5-matthew.d.roper@intel.com
2021-07-20drm/i915/display: Fix shared dpll mismatch for bigjoiner slaveManasi Navare
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
2021-07-20drm/i915/display: Disable FBC when PSR2 is enabled display 12 and newerJosé Roberto de Souza
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 <jose.souza@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210625235600.765677-2-jose.souza@intel.com
2021-07-20drm/i915/display/adl_p: Implement PSR changesJosé Roberto de Souza
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: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210625235600.765677-1-jose.souza@intel.com
2021-07-20drm/i915/display/dsc: Force dsc BPPVandita Kulkarni
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: Swati Sharma <swati2.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210720064907.9771-4-vandita.kulkarni@intel.com
2021-07-20drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enablePatnana Venkata Sai
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: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Patnana Venkata Sai <venkata.sai.patnana@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210720064907.9771-3-vandita.kulkarni@intel.com
2021-07-20drm/i915/display: Add write permissions for fec supportVandita Kulkarni
Though there is a write option available on fec_suport debugfs file, so far it has been registering with read permissions only. Suggested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210720064907.9771-2-vandita.kulkarni@intel.com
2021-07-14Merge branch 'topic/revid_steppings' into drm-intel-nextMatt Roper
The switch from old old IS_FOO_REVID() macros to the new table-based IS_FOO_{GT,DISP}_STEP() macros is needed on both drm-intel-next (for display-based DMC matching) and drm-intel-gt-next (for workaround guards). To avoid conflicts, we'll apply the patches to a topic branch and merge it to both intel branches to ensure the transition to the new macros is clean. Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2021-07-14drm/i915/icl: Drop workarounds that only apply to pre-production steppingsMatt Roper
We're past the point at which we usually drop workarounds that were never needed on production hardware. The driver will already print an error and apply taint if loaded on pre-production hardware. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-13-matthew.d.roper@intel.com
2021-07-14drm/i915/cnl: Drop all workaroundsMatt Roper
All of the Cannon Lake hardware that came out had graphics fused off, and our userspace drivers have already dropped their support for the platform; CNL-specific code in i915 that isn't inherited by subsequent platforms is effectively dead code. Let's remove all of the CNL-specific workarounds as a quick and easy first step. References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6899 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-12-matthew.d.roper@intel.com
2021-07-14drm/i915/dg1: Use revid->stepping tablesMatt Roper
Switch DG1 to use a revid->stepping table as we're trying to do on all platforms going forward. This removes the last use of IS_REVID() and REVID_FOREVER, so remove those now-unused macros as well to prevent their accidental use on future platforms. v2: - Use COMMON_STEP() macro in table. (Anusha) Bspec: 44463 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-11-matthew.d.roper@intel.com
2021-07-14drm/i915/rkl: Use revid->stepping tablesMatt Roper
Switch RKL to use a revid->stepping table as we're trying to do on all platforms going forward. Bspec: 44501 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-10-matthew.d.roper@intel.com
2021-07-14drm/i915/jsl_ehl: Use revid->stepping tablesMatt Roper
Switch JSL/EHL to use a revid->stepping table as we're trying to do on all platforms going forward. v2: - Use COMMON_STEP(). (Anusha) Bspec: 29153 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-9-matthew.d.roper@intel.com
2021-07-14drm/i915/icl: Use revid->stepping tablesMatt Roper
Switch ICL to use a revid->stepping table as we're trying to do on all platforms going forward. While we're at it, let's include some additional steppings that have popped up, even if we don't yet have any workarounds tied to those steppings (we probably need to audit our workaround list soon to see if any of the bounds have moved or if new workarounds have appeared). Note that the current bspec table is missing information about how to map PCI revision ID to GT/display steppings; it only provides an SoC stepping. The mapping to GT/display steppings (which aren't always the same as the SoC stepping) used to be in the bspec, but was apparently dropped during an update in Nov 2019; I've made my changes here based on an older bspec snapshot that still had the necessary information. We've requested that the missing information be restored. I'm only including the production revids in the table here since we're past the point at which we usually stop trying to support pre-production hardware. An appropriate check is added to intel_detect_preproduction_hw() to print an error and taint the kernel just in case someone still tries to load the driver on old pre-production hardware. v2: - Drop pre-production steppings and add error/taint at startup when loading on pre-production hardware. Bspec: 21141 # pre-Nov 2019 snapshot Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-8-matthew.d.roper@intel.com
2021-07-14drm/i915/glk: Use revid->stepping tablesMatt Roper
Switch GLK to use a revid->stepping table as we're trying to do on all platforms going forward. Pre-production and placeholder revisions are omitted. Although nothing in the code is using the data from this table at the moment, we expect some upcoming DMC patches to start utilizing it. Bspec: 19131 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-7-matthew.d.roper@intel.com
2021-07-14drm/i915/bxt: Use revid->stepping tablesMatt Roper
Switch BXT to use a revid->stepping table as we're trying to do on all platforms going forward. Note that the REVID macros we had before weren't being used anywhere in the code and weren't even correct; the table values come from the bspec (and omits all the placeholder and preproduction revisions). Although nothing in the code is using the data from this table at the moment, we expect some upcoming DMC patches to start utilizing it. Bspec: 13620 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-6-matthew.d.roper@intel.com
2021-07-14drm/i915/kbl: Drop pre-production revision from stepping tableMatt Roper
We're long past the point where we need to care about pre-production hardware, and we already warn the user and taint the kernel if we detect the driver is being loaded on pre-production hardware. Bspec: 18329 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-5-matthew.d.roper@intel.com
2021-07-14drm/i915/skl: Use revid->stepping tablesMatt Roper
Switch SKL to use a revid->stepping table as we're trying to do on all platforms going forward. Also drop the preproduction revisions and add the newer steppings we hadn't already handled. Note that SKL has a case where a newer revision ID corresponds to an older GT/disp stepping (0x9 -> STEP_J0, 0xA -> STEP_I1). Also, the lack of a revision ID 0x8 in the table is intentional and not an oversight. We'll re-write the KBL-specific comment to make it clear that these kind of quirks are expected. v2: - Since GT and display steppings are always identical on SKL use a macro to set both values at once in a more readable manner. (Anusha) - Drop preproduction steppings. Bspec: 13626 Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-4-matthew.d.roper@intel.com
2021-07-14drm/i915: Make pre-production detection use direct revid comparisonMatt Roper
Although we're converting our workarounds to use a revid->stepping lookup table, the function that detects pre-production hardware should continue to compare against PCI revision ID values directly. These are listed in the bspec as integers, so it's easier to confirm their correctness if we just use an integer literal rather than a symbolic name anyway. Bspec: 13620, 19131, 13626, 18329 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-3-matthew.d.roper@intel.com
2021-07-14drm/i915/step: s/<platform>_revid_tbl/<platform>_revidsAnusha Srivatsa
Simplify the stepping info array name. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713193635.3390052-2-matthew.d.roper@intel.com
2021-07-14drm/i915/debugfs: DISPLAY_VER 13 lpsp capabilityAnshuman Gupta
Extend i915_lpsp_capability debugfs to DG2,ADLP and future platforms. v2: commit log modification. Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713075738.23759-1-anshuman.gupta@intel.com
2021-07-13Merge drm/drm-next into drm-intel-nextRodrigo Vivi
Catching up with 5.14-rc1 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-07-13drm/i915/display/xelpd: Extend Wa_14011508470José Roberto de Souza
This workaround is also applicable to xelpd display so extending it. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-6-jose.souza@intel.com
2021-07-13drm/i915: Limit Wa_22010178259 to affected platformsJosé Roberto de Souza
This workaround is not needed for platforms with display 13. Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-5-jose.souza@intel.com
2021-07-13drm/i915/display: Settle on "adl-x" in WA commentsJosé Roberto de Souza
Most of the places are using this format so lets consolidate it. v2: - split patch in two: display and non-display because of conflicts between drm-intel-gt-next x drm-intel-next Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713003854.143197-1-jose.souza@intel.com
2021-07-11Linux 5.14-rc1v5.14-rc1Linus Torvalds
2021-07-11mm/rmap: try_to_migrate() skip zone_device !device_privateHugh Dickins
I know nothing about zone_device pages and !device_private pages; but if try_to_migrate_one() will do nothing for them, then it's better that try_to_migrate() filter them first, than trawl through all their vmas. Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/1241d356-8ec9-f47b-a5ec-9b2bf66d242@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-11mm/rmap: fix new bug: premature return from page_mlock_one()Hugh Dickins
In the unlikely race case that page_mlock_one() finds VM_LOCKED has been cleared by the time it got page table lock, page_vma_mapped_walk_done() must be called before returning, either explicitly, or by a final call to page_vma_mapped_walk() - otherwise the page table remains locked. Fixes: cd62734ca60d ("mm/rmap: split try_to_munlock from try_to_unmap") Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reported-by: kernel test robot <oliver.sang@intel.com> Link: https://lore.kernel.org/lkml/20210711151446.GB4070@xsang-OptiPlex-9020/ Link: https://lore.kernel.org/lkml/f71f8523-cba7-3342-40a7-114abc5d1f51@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-11mm/rmap: fix old bug: munlocking THP missed other mlocksHugh Dickins
The kernel recovers in due course from missing Mlocked pages: but there was no point in calling page_mlock() (formerly known as try_to_munlock()) on a THP, because nothing got done even when it was found to be mapped in another VM_LOCKED vma. It's true that we need to be careful: Mlocked accounting of pte-mapped THPs is too difficult (so consistently avoided); but Mlocked accounting of only-pmd-mapped THPs is supposed to work, even when multiple mappings are mlocked and munlocked or munmapped. Refine the tests. There is already a VM_BUG_ON_PAGE(PageDoubleMap) in page_mlock(), so page_mlock_one() does not even have to worry about that complication. (I said the kernel recovers: but would page reclaim be likely to split THP before rediscovering that it's VM_LOCKED? I've not followed that up) Fixes: 9a73f61bdb8a ("thp, mlock: do not mlock PTE-mapped file huge pages") Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Link: https://lore.kernel.org/lkml/cfa154c-d595-406-eb7d-eb9df730f944@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alistair Popple <apopple@nvidia.com> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-11mm/rmap: fix comments left over from recent changesHugh Dickins
Parallel developments in mm/rmap.c have left behind some out-of-date comments: try_to_migrate_one() also accepts TTU_SYNC (already commented in try_to_migrate() itself), and try_to_migrate() returns nothing at all. TTU_SPLIT_FREEZE has just been deleted, so reword the comment about it in mm/huge_memory.c; and TTU_IGNORE_ACCESS was removed in 5.11, so delete the "recently referenced" comment from try_to_unmap_one() (once upon a time the comment was near the removed codeblock, but they drifted apart). Signed-off-by: Hugh Dickins <hughd@google.com> Reviewed-by: Shakeel Butt <shakeelb@google.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://lore.kernel.org/lkml/563ce5b2-7a44-5b4d-1dfd-59a0e65932a9@google.com/ Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Jason Gunthorpe <jgg@nvidia.com> Cc: Ralph Campbell <rcampbell@nvidia.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Yang Shi <shy828301@gmail.com> Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2021-07-11Merge tag 'irq-urgent-2021-07-11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq fixes from Ingo Molnar: "Two fixes: - Fix a MIPS IRQ handling RCU bug - Remove a DocBook annotation for a parameter that doesn't exist anymore" * tag 'irq-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/mips: Fix RCU violation when using irqdomain lookup on interrupt entry genirq/irqdesc: Drop excess kernel-doc entry @lookup
2021-07-11Merge tag 'sched-urgent-2021-07-11' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fixes from Ingo Molnar: "Three fixes: - Fix load tracking bug/inconsistency - Fix a sporadic CFS bandwidth constraints enforcement bug - Fix a uclamp utilization tracking bug for newly woken tasks" * tag 'sched-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/uclamp: Ignore max aggregation if rq is idle sched/fair: Fix CFS bandwidth hrtimer expiry type sched/fair: Sync load_sum with load_avg after dequeue
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 09:36:27 +0000