summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-02-10drm/i915: Populate wm.max_level for everyoneVille Syrjälä3-27/+14
Switch ilk+ and skl+ platforms to also setting up wm.max_level and remove a bunch of if ladders as a result. There will be a tiny change in the debugfs on CHV machines that have DVFS disabled in the BIOS. Presviously debugfs would show the latency for the DVFS level as well, but that will no longer be the case. Which is arguably better as that number is absolutely meaningless when DVFS can't be enabled anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230209003251.32021-1-ville.syrjala@linux.intel.com
2023-02-09drm/i915/mtl: Initialize empty clockgating hooks for MTLRadhakrishna Sripada1-1/+3
Clock gating hooks to be initialized for MTL are yet to be implemented. Use a nop till we identify relevant WA's here. Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230111235531.3353815-3-radhakrishna.sripada@intel.com
2023-02-09drm/i915/dg2: Drop one PCI IDMatt Roper1-1/+0
The bspec was recently updated to remove PCI ID 0x5698; this ID is actually reserved for future use and should not be treated as DG2-G11. Bspec: 44477 Fixes: 8618b8489ba6 ("drm/i915: DG2 and ATS-M device ID updates") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208200905.680865-1-matthew.d.roper@intel.com
2023-02-08Revert "drm/i915/hwmon: Enable PL1 power limit"Ashutosh Dixit1-5/+0
This reverts commit 0349c41b05968befaffa5fbb7e73d0ee6004f610. 0349c41b0596 ("drm/i915/hwmon: Enable PL1 power limit") is incorrect and caused a major regression on ATSM. The change enabled the PL1 power limit but FW sets the default value of the PL1 limit to 0 which implies HW now works at minimum power and therefore the lowest effective frequency. This means all workloads now run slower resulting in even GuC FW load operations timing out, rendering ATSM unusable. A different solution to the original issue of the PL1 limit being disabled on ATSM is needed but till that is developed, revert 0349c41b0596. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8062 Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230208190312.1611335-1-ashutosh.dixit@intel.com
2023-02-08drm/i915/bios: set default backlight controller indexJani Nikula1-0/+1
With backlight controller set to -1 in intel_panel_init_alloc() to distinguish uninitialized values, and controller later being set only if it's present in VBT, we can end up with -1 for the controller: [drm:intel_bios_init_panel [i915]] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 0, level 255, controller 4294967295 There's no harm if it happens on platforms that ignore controller due to only one backlight controller being present, like on VLV above, but play it safe. Fixes: bf38bba3e7d6 ("drm/i915: Try to use the correct power sequencer intiially on bxt/glk") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207111626.1839645-1-jani.nikula@intel.com
2023-02-08drm/i915/uncore: cast iomem to avoid sparse warningJani Nikula1-2/+3
drmm_add_action_or_reset() is unaware of __iomem and the pointer needs to be a plain void *. Cast __iomem away and back while the pointer goes through drmm. drivers/gpu/drm/i915/intel_uncore.c:2463:17: warning: incorrect type in argument 1 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2463:17: expected void volatile [noderef] __iomem *addr drivers/gpu/drm/i915/intel_uncore.c:2463:17: got void *regs drivers/gpu/drm/i915/intel_uncore.c:2494:16: warning: incorrect type in argument 3 (different address spaces) drivers/gpu/drm/i915/intel_uncore.c:2494:16: expected void *data drivers/gpu/drm/i915/intel_uncore.c:2494:16: got void [noderef] __iomem *regs Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-2-jani.nikula@intel.com
2023-02-08drm/i915/dmc: drop "ucode" from function namesJani Nikula4-20/+20
The ucode part in the init, fini, suspend and resume function names is just unnecessary. Drop it. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207110619.1821992-1-jani.nikula@intel.com
2023-02-08drm/i915: Pick the backlight controller based on VBT on ICP+Ville Syrjälä1-3/+31
Use the second backlight controller on ICP+ if the VBT asks us to do so. On pre-MTP we also check the chicken bit to make sure the pins have been correctly muxed by the firmware. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-08drm/i915: Populate encoder->devdata for DSI on icl+Ville Syrjälä2-4/+14
We now have some eDP+DSI dual panel systems floating around where the DSI panel is the secondary LFP and thus needs to consult "panel type 2" in VBT in order to locate all the other panel type dependant stuff correctly. To that end we need to pass in the devdata to intel_bios_init_panel_late(), otherwise it'll just assume we want the primary panel type. So let's try to just populate the vbt.ports[] stuff and encoder->devdata for icl+ DSI panels as well. We can't do this on older platforms as there we risk a DSI port aliasing with a HDMI/DP port, which is a totally legal thing as the DSI ports live in their own little parallel universe. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-08drm/i915: Fix VBT DSI DVO port handlingVille Syrjälä1-10/+23
Turns out modern (icl+) VBTs still declare their DSI ports as MIPI-A and MIPI-C despite the PHYs now being A and B. Remap appropriately to allow the panels declared as MIPI-C to work. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8016 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207064337.18697-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-06drm/i915: Fix memory leaks in scatterlistMatt Atwood1-2/+6
This patch fixes memory leaks on error escapes in i915_scatterlist.c Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist creation") Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: Harish Chegondi <harish.chegondi@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230201232801.123684-1-matthew.s.atwood@intel.com
2023-02-06drm/i915: Add another EHL pci idJonathan Gray1-0/+1
described as "32 Execution Unit (EU) Super SKU" in: Intel Atom x6000E Series, and Intel Pentium and Celeron N and J Series Processors for IoT Applications Datasheet, Volume 1 Document Number: 636112-1.6 Signed-off-by: Jonathan Gray <jsg@jsg.id.au> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230206043727.46069-1-jsg@jsg.id.au
2023-02-06drm/i915/hwmon: Enable PL1 power limitAshutosh Dixit1-0/+5
Previous documentation suggested that PL1 power limit is always enabled. However we now find this not to be the case on some platforms (such as ATSM). Therefore enable PL1 power limit during hwmon initialization. Bspec: 51864 v2: Add Bspec reference (Gwan-gyeong) v3: Add Fixes tag Fixes: 99f55efb79114 ("drm/i915/hwmon: Power PL1 limit and TDP setting") Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230203155309.1042297-1-ashutosh.dixit@intel.com
2023-02-03drm/i915/dsb: Introduce intel_dsb_finish()Ville Syrjälä3-4/+9
Introduce a function to emits whatever commands we need at the end of the DSB command buffer. For the moment we only do the tail cacheline alignment there, but eventually we might want to eg. emit an interrupt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-5-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-03drm/i915/dsb: Split intel_dsb_wait() from intel_dsb_commit()Ville Syrjälä3-3/+13
Starting the DSB execution vs. waiting for it stop are two totally different things. Split intel_dsb_wait() from intel_dsb_commit() so that we can eventually allow the DSB to execute asynchronously. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-4-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-03drm/i915/dsb: Pimp debug/error printsVille Syrjälä1-4/+8
Print the crtc/DSB id information to make it clear which DSB engine we're talking about. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118163040.29808-3-ville.syrjala@linux.intel.com Reviewed-by: Animesh Manna <animesh.manna@intel.com>
2023-02-03drm/i915/fbdev: Implement fb_dirty for intel custom fb helperJouni Högander1-0/+12
After disconnecting damage worker from update logic it's left to fbdev emulation implementation to have fb_dirty function. Currently intel fbdev doesn't have it. This is causing problems to features (PSR, FBC, DRRS) relying on dirty callback. Implement simple fb_dirty callback to deliver notifications about updates in fb console. v4: Add proper Fixes tag and modify commit message v3: Check damage clip v2: Improved commit message and added Fixes tag Fixes: f231af498c29 ("drm/fb-helper: Disconnect damage worker from update logic") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230123074437.475103-1-jouni.hogander@intel.com
2023-02-02drm/i915/dmc: check incoming dmc id validityJani Nikula1-2/+6
Add validity checks for the dmc ids computed from pipe parameters in intel_dmc_enable_pipe() and intel_dmc_disable_pipe(). It's slightly difficult for humans and static analyzers alike to ensure the resulting dmc ids are within bounds. Just check them and reject invalid ones. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6a349c3a2b2def5fc31a48c9844ebd72ee55a22b.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: add is_valid_dmc_id() and use itJani Nikula1-1/+6
Add a name to the dmc id validity check. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/311213ce328575a95d793a219d4dac7d947086cc.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: remove unnecessary dmc_id validity checkJani Nikula1-5/+0
The dmc_id comes from for_each_dmc_id() in parse_dmc_fw() -> parse_dmc_fw_header() -> dmc_mmio_addr_sanity_check(). It's valid by definition. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b4e1c862687f79861a5fa4bfa6797ecda2136fab.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: add for_each_dmc_id() and use itJani Nikula1-6/+9
The loop is duplicated many times, with slightly different ways. Unify. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8dcaa716093e6fbe75bb69ee7ac715a3f007a523.1675339447.git.jani.nikula@intel.com
2023-02-02drm/i915/dmc: add proper name to dmc id enum and use itJani Nikula2-40/+39
Clarify DMC ID usage by adding enum intel_dmc_id name to the enum, and use dmc_id as the variable name for it throughout. Convert a switch-case to if-ladder to avoid warnings about not handling DMC_FW_MAX enumeration constant in the switch-case. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6912ccb411bb957c68c108b774745dbc7e0cbdc2.1675339447.git.jani.nikula@intel.com
2023-02-01drm/i915: Expose SAGV state via debugfsVille Syrjälä3-7/+28
Since SAGV is controlled via unidirectional pcode commands we have no way to query the current state. So instead let's expose the last programmed state via debugfs. This way we can at least know whether SAGV should be enabled or not (which can be important to know when dealing with underruns/etc.). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-01drm/i915: Keep sagv status updated on icl+Ville Syrjälä1-20/+29
On icl+ SAGV is controlled by masking of the QGV points. Reduce the QGV point mask to the same kind of enabled vs. disable information that we had on previous platforms. Will be useful in answering the question whether SAGV is actually enabled or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2023-02-01drm/i915: Introduce HAS_SAGV()Ville Syrjälä2-4/+5
Introuce a HAS_SAGV() macro to answer the question whether the platform in general supports SAGV. intel_has_sagv() will keep on giving us the more specific answer whether the current device supports SAGV or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-02-01drm/i915: Don't do the WM0->WM1 copy w/a if WM1 is already enabledVille Syrjälä1-1/+2
Due to a workaround we have to make sure the WM1 watermarks block/lines values are sensible even when WM1 is disabled. To that end we copy those values from WM0. However since we now keep each wm level enabled on a per-plane basis it doesn't seem necessary to do that copy when we already have an enabled WM1 on the current plane. That is, we might be in a situation where another plane can only do WM0 (and thus needs the copy) but the current plane's WM1 is still perfectly valid (ie. fits into the current DDB allocation). Skipping the copy could avoid reprogramming the plane's registers needlessly in some cases. Fixes: a301cb0fca2d ("drm/i915: Keep plane watermarks enabled more aggressively") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2023-01-31drm/i915/lvds: s/pipe_config/crtc_state/Ville Syrjälä1-23/+23
Call the crtc state 'crtc_state' rather than 'pipe_config', as is the modern style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: s/intel_encoder/encoder/ etc.Ville Syrjälä1-70/+64
Get rid of some of the annoying aliasing drm_ vs. intel_ encoder/connector variables. Just prefer the intel_ types. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: s/dev_priv/i915/Ville Syrjälä1-57/+54
Do the customary s/dev_priv/i915/ rename and aliasing 'dev' pointer removal. Though various register definitions still depend on the magic 'dev_priv' variable so not a 100% conversion. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Fix whitespaceVille Syrjälä1-14/+14
Replace some stray spaces with tabs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Extract intel_lvds_regs.hVille Syrjälä8-54/+71
Extract the integrated LVDS port register definitions into their own header file. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Use REG_BIT() & co.Ville Syrjälä2-26/+24
Use REG_BIT() & co. for the LVDS port register. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Use intel_de_rmw()Ville Syrjälä1-8/+4
Replace the hand rolled rmw stuff with intel_de_rmw(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915/lvds: Split long linesVille Syrjälä1-3/+7
Split some overly long lines. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130180540.8972-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2023-01-31drm/i915: Implement workaround for CDCLK PLL disable/enableStanislav Lisovskiy1-2/+13
It was reported that we might get a hung and loss of register access in some cases when CDCLK PLL is disabled and then enabled, while squashing is enabled. As a workaround it was proposed by HW team that SW should disable squashing when CDCLK PLL is being reenabled. v2: - Added WA number comment(Rodrigo Vivi) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130135836.12738-1-stanislav.lisovskiy@intel.com
2023-01-31drm/i915/hdmi: Go for scrambling only if platform supports TMDS clock > 340MHzAnkit Nautiyal1-1/+20
There are cases, where devices have an HDMI1.4 retimer, and TMDS clock rate is capped to 340MHz via VBT. In such cases scrambling might be supported by the platform and an HDMI2.0 sink for lower TMDS rates, but not supported by the retimer, causing blankouts. So avoid enabling scrambling, if the TMDS clock is capped to <= 340MHz. v2: Added comment, documenting the rationale to check for TMDS clock, before going for scrambling. (Arun) v3: Fixed the function name to check if source supports scrambling. (Jani) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221222040851.3029514-1-ankit.k.nautiyal@intel.com
2023-01-30drm/i915/dg1: Drop final use of IS_DG1_GRAPHICS_STEPMatt Roper2-4/+1
All production DG1 hardware has graphics stepping B0; there is no such thing as C0. As such, we can simplify IS_DG1_GRAPHICS_STEP(uncore->i915, STEP_A0, STEP_C0) to just match DG1 in general. Bspec: 44463 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-4-matthew.d.roper@intel.com
2023-01-30drm/i915/dg1: Drop support for pre-production steppingsMatt Roper5-59/+5
Several post-DG1 platforms have been brought up now, so we're well past the point where we usually drop the workarounds that are only applicable to internal/pre-production hardware. Production DG1 hardware always has a B0 stepping for both display and GT. Bspec: 44463 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-3-matthew.d.roper@intel.com
2023-01-30drm/i915/tgl: Drop support for pre-production steppingsMatt Roper7-83/+7
Several post-TGL platforms have been brought up now, so we're well past the point where we usually drop the workarounds that are only applicable to internal/pre-production hardware. Production TGL hardware always has display stepping C0 or later and GT stepping B0 or later (this is true for both the original TGL and the U/Y subplatform). Bspec 44455 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127224313.4042331-2-matthew.d.roper@intel.com
2023-01-30drm/i915: implement async_flip mode per plane trackingAndrzej Hajda5-4/+19
Current implementation of async flip w/a relies on assumption that previous atomic commit contains valid information if async_flip is still enabled on the plane. It is incorrect. If previous commit did not modify the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE errors can be observed: i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read NO_PASID] Request device [00:02.0] fault addr 0x0 [fault reason 0x06] PTE Read access is not set v2: update async_flip_planes in more reliable places (Ville) v3: reset async_flip_planes and do_async_flip in more scenarios (Ville) v4: move all resets to plane loops (Ville) Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230127153003.2225111-1-andrzej.hajda@intel.com
2023-01-30drm/i915/psr: Split sel fetch plane configuration into arm and noarmJouni Högander4-23/+42
SEL_FETCH_CTL registers are armed immediately when plane is disabled. SEL_FETCH_* instances of plane configuration are used when doing selective update and normal plane register instances for full updates. Currently all SEL_FETCH_* registers are written as a part of noarm plane configuration. If noarm and arm plane configuration are not happening within same vblank we may end up having plane as a part of selective update before it's PLANE_SURF register is written. Fix this by splitting plane selective fetch configuration into arm and noarm versions and call them accordingly. Write SEL_FETCH_CTL in arm version. v3: - add arm suffix into intel_psr2_disable_plane_sel_fetch v2: - drop color_plane parameter from arm part - dev_priv -> i915 in arm part Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Vinod Govindapillai <vinod.govindapillai@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130080651.3796929-1-jouni.hogander@intel.com
2023-01-30drm/i915/display/dsi: use intel_de_rmw if possibleAndrzej Hajda1-174/+82
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219130844.2914001-1-andrzej.hajda@intel.com
2023-01-30drm/i915/display/vlv: use intel_de_rmw if possibleAndrzej Hajda2-109/+41
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219092428.2515430-2-andrzej.hajda@intel.com
2023-01-30drm/i915/display/vlv: fix pixel overlap register updateAndrzej Hajda1-15/+9
To update properly bits in the register the mask should be used to clear old value and then the result should be or-ed with new value, for such updates there is separate helper intel_de_rmw. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219092428.2515430-1-andrzej.hajda@intel.com
2023-01-30drm/i915/display/fdi: use intel_de_rmw if possibleAndrzej Hajda1-104/+44
The helper makes the code more compact and readable. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221215125610.1161729-1-andrzej.hajda@intel.com
2023-01-30drm/i915/adlp: Fix typo for reference clockChaitanya Kumar Borah1-1/+1
Fix typo for reference clock from 24400 to 24000. Bspec: 55409 Fixes: 626426ff9ce4 ("drm/i915/adl_p: Add cdclk support for ADL-P") Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230112094131.550252-1-chaitanya.kumar.borah@intel.com
2023-01-27drm/i915/pxp: Pxp hw init should be in resume_completeAlan Previn3-6/+22
During suspend flow, i915 currently achors' on the pm_suspend_prepare callback as the location where we quiesce the entire GPU and perform all necessary cleanup in order to go into suspend. PXP is also called during this time to perform the arbitration session teardown (with the assurance no additional GEM IOCTLs will come after that could restart the session). However, if other devices or drivers fail their suspend_prepare, the system will not go into suspend and i915 will be expected to resume operation. In this case, we need to re-initialize the PXP hardware and this really should be done within the pm_resume_complete callback which is the correct opposing function in the resume sequence to match pm_suspend_prepare of the suspend sequence. Because this callback is the last thing at the end of resuming we expect little to no impact to the rest of the i915 resume sequence with this change. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-7-alan.previn.teres.alexis@intel.com
2023-01-27drm/i915/pxp: Trigger the global teardown for before suspendingAlan Previn5-13/+66
A driver bug was recently discovered where the security firmware was receiving internal HW signals indicating that session key expirations had occurred. Architecturally, the firmware was expecting a response from the GuC to acknowledge the event with the firmware side. However the OS was in a suspended state and GuC had been reset. Internal specifications actually required the driver to ensure that all active sessions be properly cleaned up in such cases where the system is suspended and the GuC potentially unable to respond. This patch adds the global teardown code in i915's suspend_prepare code path. v2 : Split __pxp_global_teardown_locked helper into two variants for teardown-with-restart vs teardown-for-suspend/shutdown. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Juston Li <justonli@chromium.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-6-alan.previn.teres.alexis@intel.com
2023-01-27drm/i915/pxp: Invalidate all PXP fw sessions during teardownAlan Previn5-0/+56
A gap was recently discovered where if an application did not invalidate all of the stream keys (intentionally or not), and the driver did a full PXP global teardown on the GT subsystem, we find that future session creation would fail on the security firmware's side of the equation. i915 is the entity that needs ensure the sessions' state across both iGT and security firmware are at a known clean point when performing a full global teardown. Architecturally speaking, i915 should inspect all active sessions and submit the invalidate-stream-key PXP command to the security firmware for each of them. However, for the upstream i915 driver we only support the arbitration session that can be created so that will be the only session we will cleanup. Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Juston Li <justonli@chromium.org> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-5-alan.previn.teres.alexis@intel.com
2023-01-27mei: clean pending read with vtag on busAlexander Usyskin1-1/+3
Client on bus have only one vtag map slot and should disregard the vtag value when cleaning pending read flag. Fixes read flow control message unexpectedly generated when clent on bus send messages with different vtags. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230125082637.118970-4-alan.previn.teres.alexis@intel.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-26 13:22:21 +0300