Add the register definitions for a bunch of flip queue related
PIPEDMC registers.
v2: The layout of flip queue entries changed on PTL
Bump the DMC_FQ_W2_PTS_CFG_SEL bitfields sizes (Uma)
Reduce the scanlines to 21 bits for now (Uma)
v3: Also define some undocumented DMC variables we need on PTL
v3: Drop PIPEDMC_FQ_CTRL_BUSY as it seems to no longer exist
on LNL+
Fix up some typos
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250624170049.27284-4-ville.syrjala@linux.intel.com
Instead of hardcoding the event handler indices (for runtime
event handler enable/disable) we can simply look for the handler
with the appropriate event type. This isolates us from the firmware
details a bit better.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250512103358.15724-8-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Hook up PIPEDMC interrupts. We'll need these for:
- flip queue signalling
- GTT/ATS faults on LNL+
- unclaimed register access errors (supposedly that is what
the error interrupt indicated according to Windows code).
On LNL+ we get a new level of interrupts registers PIPEDMC_INTERRUPT*.
On earlier platforms we only have the INT_VECTOR field in the
PIPEDMC_STATUS registers, whose values are defined by the firmware.
For now we'll enable the interrupts on LNL+ only. For earlier platforms
it's not clear that there is any use for these interrupts, and some
ADL machines have exhibited spurious DE_PIPE interrupts with the
PIPEDMC interrupts unmasked/enabled. We can revisit enabling these
for earlier platforms in the future.
For some unknown reason LNL pipe B triggers the error interrupt
during the first DC state transition (subsequent transitions are
maybe OK?). No clear idea what's going on here yet, so keep the
error interrupt disabled for now.
Similar to DSB interrupt registers, the unused bits in
PIPEDMC_INTERRUPT* seem to act like randomg r/w bits (instead
of being hardwired to 0 like one would expect), and so we'll try
to avoid setting them so that we don't mistake them for real
interrupts.
v2: Only enable/unmask for LNL+
Keep the flip queue interrupt masked off for now since
we don't have a use for it yet
v3: Also keep the error interrupt masked off for now due to
LNL pipe B triggering it
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250514174257.8708-1-ville.syrjala@linux.intel.com
We need PIPEDMC_BLOCK_PKGC_SW definitions to implement workaround for
underrun on idle PSR HW issue (Wa_16025596647). Add PIPEDMC_BLOCK_PKGC_SW
register definitions.
Bspec: 71265
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250414100508.1208774-5-jouni.hogander@intel.com
To implement workaround for underrun on idle PSR HW issue (Wa_16025596647)
we need PIPEDMC_EVT_CTL_4 register. Add PIPEDMC_EVT_CTL_4 register
definitions.
Bspec: 67576
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://lore.kernel.org/r/20250414100508.1208774-4-jouni.hogander@intel.com
In order to reduce the DC5->DC2 restore time, wakelocks have been
introduced in DMC so the driver can tell it when registers and other
memory areas are going to be accessed and keep their respective blocks
awake.
Implement this in the driver by adding the concept of DMC wakelocks.
When the driver needs to access memory which lies inside pre-defined
ranges, it will tell DMC to set the wakelock, access the memory, then
wait for a while and clear the wakelock.
The wakelock state is protected in the driver with spinlocks to
prevent concurrency issues.
BSpec: 71583
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240412094148.808179-2-luciano.coelho@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Unlike later platforms TGL/ADLS has the half refresh rate (HRR) event
on the main DMC (as opposed to the pipe DMC). Since we're disabling
that event on all later platforms already let's do the same on
TGL/ADLS as well.
There is supposedly a bit somewhere (DMC_CHICKEN on TGL) to make
the handler not do anything, but we don't currently have code
to frob it. Though that bit should be off by default, the ADL+
experience has shown us that trusting any of this isn't a good
idea. So seems safer to just disable all event handlers we know
that we don't need.
Also the TGL/ADLS DMC firmware is apparently using the wrong event
(undelayed vblank) here anyway. It should be using the delayed
vblank event instead (like ADL+ firmware does), but they didn't
release a firmware fix for this and instead just hacked around
this in the Windows driver code :/
v2: Also disable the event on ADLS (Imre)
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231213150807.21331-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Make sure that PIPEDMCs are enabled whenever the corresponding pipe is
enabled.
This is required at least by the latest ADLP v2.18 firmware, which adds
a new handler enabled by default and running whenever the pipe is
enabled at the vertical referesh rate.
Bspec: 50344, 67620
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230102183324.862279-1-imre.deak@intel.com
Disable the DMC event handlers before loading the firmware and after
uninitializing the display, to make sure the firmware is inactive. This
matches the Bspec "Sequences for Display C5 and C6" page for GEN12+.
Add a TODO comment for doing the same on pre-GEN12 platforms.
v2:
- Add a macro for the number of event handlers.
- Disable the event handlers only on GEN12+.
- s/dev_priv/i915/ in docbook comment.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20220728081440.1676857-1-imre.deak@intel.com
Based on a bspec update the DMC firmware's flip queue handling events
need to be disabled before enabling DC5/6. i915 doesn't use the flip
queue feature atm, so disable it already after loading the firmware.
This removes some overhead of the event handler which runs at a 1 kHz
frequency.
Bspec: 49193, 72486, 72487
v2:
- Fix the DMC pipe A register offsets for GEN12.
- Disable the events on DG2 only on pipe A..D .
v3: (Lucas)
- Add TODO: to clarify the disabling sequence on all D13+
- s/intel_dmc_has_fw_payload/has_dmc_id_fw/
- s/simple_flipq/flipq/
- s/_GEN12,_GEN13/TGL_,ADLP_/
- s/MAINDMC/DMC/
v4:
- Only disable flip queues on TGL/DG2, as on other platforms the
corresponding event handlers don't exist.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> # v1
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220521130808.637449-1-imre.deak@intel.com
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
v4: s/_PICK/_PICK_EVEN and use it only for Pipe DMC scenario.
- clean up sanity check logic.(Lucas)
- Add MMIO range for RKL as well.(Anusha)
v5: Use DISPLAY_VER instead of per platform check (Lucas)
BSpec: 49193
Cc: stable@vger.kernel.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220511000847.1068302-1-anusha.srivatsa@intel.com
