Hook up the display fault irq handlers for VLV/CHV.
Unfortunately the actual hardware doesn't agree with the
spec on how DPINVGTT should behave. The docs claim that
the status bits can be cleared by writing '1' to them,
but in reality there doesn't seem to be any way to clear
them. So we must disable and ignore any fault we've already
seen in the past. The entire register does reset when
the display power well goes down, so we can just always
re-enable all the bits in irq postinstall without having
to track the state beyond that.
v2: Use intel_display instead of dev_priv
Move xe gen2_error_{init,reset}() out
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250217070047.953-9-ville.syrjala@linux.intel.com
Most of MMIO accesses from intel_display_irq.c are currently done via
uncore_*() functions instead of the display-specific ones, namely
intel_de_*(). Because of that, DMC wakelock ends up being ignored and
some invalid MMIO accesses are performed while display is in dynamic DC
states. Thus, update the display IRQ code to use the intel_de_*() MMIO
functions.
After this change, we are left with some IRQ-specific functions that
still use the unwrapped uncore_*() functions (i.e. gen2_irq_init,
gen3_irq_reset and gen2_assert_iir_is_zero). We will deal with them in
an upcoming change.
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250113204306.112266-2-gustavo.sousa@intel.com
From LNL onwards there is a new hardware feature, which
allows to detect if the driver wrongly allocated DBuf
entries and they happen to overlap. If enabled this will
cause a specific interrupt to occur.
We now handle it in the driver, by writing correspondent
error message to kernel log.
v2: Initialize dbuf overlap flag in runtime_defaults (Jani Nikula)
v3: Unmask the overlap detection interrupt (Uma)
v4: use display over i915 (Jani Nikula)
v5: Use display instead of dev_priv (Jani Nikula)
v6: rebased to resolve merge conflicts
Bspec: 69450, 69464
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241030103319.207235-1-vinod.govindapillai@intel.com
Underrun recovery was defeatured and was never brought into usage.
Thus we can remove the underrun recovery interrupt/reporting
register bits and related logic introduced to detect/report soft,
hard, port underruns.
Essentially this is a revert of the commit 8bcc0840cf
("drm/i915/xelpd: Enhanced pipe underrun reporting") which originally
added this functionality. Also note that PIPE_STATUS_UNDERRUN bit in
PIPESTATUS still stays relevant but we would move back to not
clearing this sticky bit as we are not using any information from
this register.
v2: Extend commit message to add more details (Matt Roper)
v3: Fix the old commit mention in commit message
Signed-off-by: Sai Teja Pottumuttu <sai.teja.pottumuttu@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241015080503.3521063-1-sai.teja.pottumuttu@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Turns out CRC interrupts also fail to wake up i915gm/i945gm from
C2+. I suppose this is a generic problem, but for most other
interrupts the system will be busy enough already prior to
the irq being issued. But CRC interrupts are like vblank interrupts
and only fire once per frame, so plenty of time to fall asleep
in between them.
Apply the same core clock gating trick to CRC interrupts
that we use for vblank interrupts.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20241001195803.3371-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
The only real reason why we have the gen2 vs. gen3+ split
in irq handling is that bspec claims that IIR/IMR/IER/ISR
and EMR are only 16 bits on gen2, as opposed to being 32
bits on gen3+. That doesn't seem to be a meaningful
distinction as 32bit access to these registers works
perfectly fine on gen2
Interestingly the 16 msbs of IMR are in fact hardcoded
to 1 on gen2, which to me indicates that 32bit access
was the plan all along, and perhaps someone just forgot
to update the spec.
Nuke the special 16bit gen2 irq code and switch over to
the gen3 code.
Gen2 doesn't have the ASLE interrupt, which just needs
a small tweak in i915_irq_postinstall().
And so far we've not had a codepath that could enable the
legacy BLC interrupt on gen2. Now we do, but we'll never
actually do it since gen2 machines don't have OpRegion.
(and neither do i915/i945 machines btw). On these older
platforms the legacy BLC interrupt is meant to be used
in conjunction with the LBPC backlight stuff, but we
never actually switch off the legacy/combination mode
and thus don't use the interrupt either.
This was quickly smoke tested on all gen2 variants.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240927143545.8665-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
i915_has_asle() is a bit of a mess. It does some kind of
partial check whether the platform has the legacy BLC
interrupt or not, and then it checks whether OpRegion
ASLE is present.
Let's split the legacy BLC interrupt check into its
own thing, and while at it let's make it accurate.
Currently it misses i85x (not a problem since gen2
never has OpRegion, nor do we currently call
i915_enable_asle_pipestat() on gen2), and it
doesn't reject ILK-M (not that anyone should call
this on ILK). The exlusion of VLV/CHV (where one
might even consider calling this, being gmch
platforms) only happens due to .is_mobile==false.
List the platforms that actually do have the legacy
BLC interrupt in a bit more explicit fashion.
i915gm/i945gm/i965gm/gm45 we can cover with a
display_ver+is_mobile check, pnv needs an exception
due to having a variant with is_mobile==false, and
i85x is the only relevant gen2 platform so easier to
handle on its own.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240927143545.8665-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We need to block DC6 entry in case of Panel Replay as enabling VBI doesn't
prevent DC6 in case of Panel Replay. This causes problems if user-space is
polling for vblank events.
Fix this by setting target DC state as DC_STATE_EN_UPTO_DC5 when both
source and sink are supporting eDP Panel Replay and VBI is enabled.
v4:
- s/vblank_work/vblank_dc_work/
- changed type of block_dc_for_vblank to bool
v3:
- do flush_work for vblank_work on intel_crtc_vblank_off
- no need to use READ_ONCE in bdw_enable_vblank
- check crtc->block_dc_for_vblank in bdw_disable_vblank as well
- move adding block_dc_for_vblank into this patch
v2:
- use READ_ONCE in intel_display_vblank_work
- use DC_STATE_DISABLE instead of DC_STATE_EN_UPTO_DC6
- use intel_crtc->block_dc6_needed
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/2296
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240920062340.1333777-3-jouni.hogander@intel.com
On hsw+ we only have one CRC result register, instead of the
five we have on ivb, and some of the others have been repurposed
to serve other CRC related purposes.
Since the hsw+ vs. pre-hsw register operate quite differently
let's add a separate definition for the hsw+ variant to make the
situation a bit more clear. Also since we only use this from a
hsw+ codepath there is no real benefit to be had with reusing
the ivb register definition.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240531115342.2763-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
