- 01 Feb, 2023 1 commit
-
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230131002127.29305-1-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
- 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:
Jani Nikula <jani.nikula@intel.com>
-
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 14 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: -
Lucas De Marchi authored
Avoid the array lookup, converting the PLL macros after ICL to _PICK_EVEN_RANGES. This provides the following reduction in code size: $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new} text data bss dec hex filename 4027456 185703 6984 4220143 4064ef build64/drivers/gpu/drm/i915/i915.o.old 4026997 185703 6984 4219684 406324 build64/drivers/gpu/drm/i915/i915.o.new At the same time it's safer, avoiding out-of-bounds array access. This allows to remove _MMIO_PLL3() that is now unused. Signed-off-by: -
Lucas De Marchi authored
Abide by the rules in the top of the header: 2 spaces for bitfield, prefix offsets with underscore and prefer the use of REG_BIT(). Signed-off-by:
-
Lucas De Marchi authored
It's a constant pattern in the driver to need to use 2 ranges of MMIOs based on port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged due to some reasons like: 1) It increases the code size since the array is declared in each call site 2) Developers need to be careful not to incur an out-of-bounds array access 3) Developers need to be careful that the indexes match the table. For that it may be that the table needs to contain holes, making (1) even worse. Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one to use depending on the index value. v2: Fix the address expansion in the example (Anusha) v3: Also rename macro to _PICK_EVEN_2RANGES() in the documentation and reword it to clarify what ranges are chosen based on the index (Jani) Signed-off-by:
-
- 26 Jan, 2023 5 commits
-
-
Jouni Högander authored
Wa_14013475917 has to be applied for all MTL steppings. Bspec: 66624 Cc: Mika Kahola <mika.kahola@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Jouni Högander authored
Implement Wa_14014971492 and apply it for affected platforms. Bspec: 52890, 54369, 55378, 66624 v2: Adjust platforms where applied Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Jani Nikula authored
It's a bit confusing to have two cached EDIDs in struct intel_connector with slightly different purposes. Make the distinction a bit clearer by moving the EDID cached for eDP and LVDS panels at connector init time to struct intel_panel, and name it fixed_edid. That's what it is, a fixed EDID for the panels. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Simplify validation and use by converting to drm_edid. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Try to use struct drm_edid where possible, even if having to fall back to looking into struct edid down low via drm_edid_raw(). v2: Rebase Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
