- 02 Feb, 2023 5 commits
-
-
Jani Nikula authored
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
-
Jani Nikula authored
Add a name to the dmc id validity check. Signed-off-by:
-
Jani Nikula authored
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 authored
The loop is duplicated many times, with slightly different ways. Unify. Signed-off-by:
-
Jani Nikula authored
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:
-
- 01 Feb, 2023 4 commits
-
-
Ville Syrjälä authored
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.comReviewed-by:
-
Ville Syrjälä authored
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:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
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ä authored
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: a301cb0f ("drm/i915: Keep plane watermarks enabled more aggressively") Signed-off-by:
-
- 31 Jan, 2023 10 commits
-
-
Ville Syrjälä authored
Call the crtc state 'crtc_state' rather than 'pipe_config', as is the modern style. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
Replace some stray spaces with tabs. Signed-off-by:
-
Ville Syrjälä authored
Extract the integrated LVDS port register definitions into their own header file. Signed-off-by:
-
Ville Syrjälä authored
Use REG_BIT() & co. for the LVDS port register. Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled rmw stuff with intel_de_rmw(). Signed-off-by:
-
Ville Syrjälä authored
Split some overly long lines. Signed-off-by:
-
Stanislav Lisovskiy authored
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:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130135836.12738-1-stanislav.lisovskiy@intel.com
-
Ankit Nautiyal authored
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
-
- 30 Jan, 2023 10 commits
-
-
Matt Roper authored
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
-
Matt Roper authored
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 authored
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:
-
Andrzej Hajda authored
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:
-
Jouni Högander authored
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
-
Andrzej Hajda authored
The helper makes the code more compact and readable. Signed-off-by:
-
Andrzej Hajda authored
The helper makes the code more compact and readable. Signed-off-by:
-
Andrzej Hajda authored
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 authored
The helper makes the code more compact and readable. Signed-off-by:
-
Chaitanya Kumar Borah authored
Fix typo for reference clock from 24400 to 24000. Bspec: 55409 Fixes: 626426ff ("drm/i915/adl_p: Add cdclk support for ADL-P") Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
-
- 27 Jan, 2023 11 commits
-
-
Alan Previn authored
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:
-
Alan Previn authored
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:Juston Li <justonli@chromium.org> Acked-by:
-
Alan Previn authored
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:
-
Alexander Usyskin authored
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alexander Usyskin authored
Add device link with i915 as consumer and mei_pxp as supplier to ensure proper ordering of power flows. V2: condition on absence of heci_pxp to filter out DG Signed-off-by:
-
Alexander Usyskin authored
Asynchronous runtime resume is not possible while the system is suspending. The power management subsystem resumes the device only in the suspend phase, not in the prepare phase. Force resume device in prepare to allow drivers on mei bus to communicate in their prepare callbacks. Signed-off-by:
-
Lucas De Marchi authored
PALETTE() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the size and is safer. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa<anusha.srivatsa@intel.com> Acked-by:
-
Lucas De Marchi authored
MBUS_ABOX_CTL() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the size and is safer. Signed-off-by:
-
Lucas De Marchi authored
_FIA() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the size and is safer. Signed-off-by:
-
Lucas De Marchi authored
Like done for when __var_args__ were used, but size-wise it's also benefitial to avoid _PICK() used for 3 ports/pipes: $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new} text data bss dec hex filename 4026288 185703 6984 4218975 40605f build64/drivers/gpu/drm/i915/i915.o.old 4025496 185703 6984 4218183 405d47 build64/drivers/gpu/drm/i915/i915.o.new Signed-off-by: -
Lucas De Marchi authored
As done previously for pll, also convert users of _PHY3() to _PICK_EVEN_2RANGES(). Size comparison of i915.o: $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new} text data bss dec hex filename 4026997 185703 6984 4219684 406324 build64/drivers/gpu/drm/i915/i915.o.old 4026288 185703 6984 4218975 40605f build64/drivers/gpu/drm/i915/i915.o.new Signed-off-by:
-
