- 08 Feb, 2023 7 commits
-
-
Ashutosh Dixit authored
This reverts commit 0349c41b. 0349c41b ("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 0349c41b. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8062Signed-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
-
Jani Nikula authored
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: bf38bba3 ("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
-
Jani Nikula authored
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:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207124026.2105442-2-jani.nikula@intel.com
-
Jani Nikula authored
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:
-
Ville Syrjälä authored
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/8016Signed-off-by:
-
Ville Syrjälä authored
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/8016Signed-off-by:
-
Ville Syrjälä authored
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/8016Signed-off-by:
-
- 06 Feb, 2023 3 commits
-
-
Matt Atwood authored
This patch fixes memory leaks on error escapes in i915_scatterlist.c Fixes: c3bfba9a ("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:
-
Jonathan Gray authored
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:
-
Ashutosh Dixit authored
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: 99f55efb ("drm/i915/hwmon: Power PL1 limit and TDP setting") Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
- 03 Feb, 2023 4 commits
-
-
Ville Syrjälä authored
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:
Animesh Manna <animesh.manna@intel.com>
-
Ville Syrjälä authored
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ä authored
Print the crtc/DSB id information to make it clear which DSB engine we're talking about. Signed-off-by:
-
Jouni Högander authored
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: f231af49 ("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:
-
- 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:
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ä 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 7 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 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:
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:
-
