Ville Syrjälä [Thu, 4 Nov 2021 14:45:17 +0000 (16:45 +0200)]
drm/i915: Relocate FBC_LLC_READ_CTRL
In the case of FBC_LLC_READ_CTRL the "FBC" stands for
frame buffer _caching_, not frame buffer compression.
Move the register definition out from the middle of the
frame buffer compression register definitions. Let's
just stick it somewhere with similar looking register
offsets.
And while at it switch it over to REG_BIT().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-15-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:16 +0000 (16:45 +0200)]
drm/i915/fbc: Finish polishing FBC1 registers
Switch all the FBC1 registers over to REG_BTT()/etc.
And while at it add a few more registers/bits that
escaped the net previously.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-14-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:15 +0000 (16:45 +0200)]
drm/i915/fbc: Clean up all register defines
The FBC register defines are a mess:
- namespace changes between DPFC_, FBC_, and some platform
specific prefix at a whim
- ilk+ reuses most g4x bits but still has some separate bit
defines elsewhere
- it's not clear from the defines that the bit defines are
shared
So let's clean it up:
- both g4x and ilk register share the same defines now
- only defines which conflict have a _PLATFORM suffix, everyone
else just gets comments to indicate which platforms do what
- namespace is consistent DPFC_ now
- SNB system agent fence registers also get a consistent namespace
- REG_BIT() & co. for everything
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-13-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:14 +0000 (16:45 +0200)]
drm/i915/fbc: Nuke BDW_FBC_COMP_SEG_MASK
Just use a same mask for ivb/hsw as for bdw+. The extra bit
in the bdw mask is mbz on ivb/hsw anyway so this is just
pointless complexity.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-12-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:13 +0000 (16:45 +0200)]
drm/i915/fbc: Introduce intel_fbc_set_false_color()
Pull the direct FBC register frobbing out from the debugfs code
into the fbc code. Also add a vfunc for this so we don't need
extra platforms checks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-11-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:12 +0000 (16:45 +0200)]
drm/i915/fbc: Introduce .program_cfb() vfunc
Eliminate the last if-ladder by pulling the CFB/LLB programming
into a vfunc as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-10-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:11 +0000 (16:45 +0200)]
drm/i915/fbc: s/gen7/ivb/
"gen7" in display code is not really sensible. We shall call
these things "ivb".
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-9-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:10 +0000 (16:45 +0200)]
drm/i915/fbc: Introduce .nuke() vfunc
Eliminate yet another if-ladder by adding .nuke() vfunc.
We also rename all *_recompress() stuff to *_nuke() since
that's the terminology the spec uses. Also "recompress"
is a bit confusing by perhaps implying that this triggers
an immediate recompression. Depending on the hardware that
may definitely not be the case, and in general we don't
specifically know when the hardware decides to compress.
So all we do is "nuke" the current compressed framebuffer
and leave it up to the hardware to recompress later if it
so chooses.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-8-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:09 +0000 (16:45 +0200)]
drm/i915/fbc: Introduce intel_fbc_funcs
Replace the "if-ladders everywhere" approach with vfuncs.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-7-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:08 +0000 (16:45 +0200)]
drm/i915/fbc: Extract helpers to compute FBC control register values
Declutter the *_fbc_activate() functions by pulling all the
control register value computations into helpers.
I left the enable bit in *_fbc_activate() in the hopes of maybe
using the helpers in the *_fbc_deactivate() paths as well instead
of the current rmw approach. That won't be possible at least
quite yet since we clobber the fbc->params before deactivating
FBC so we could end up changing some of the values live, which
given FBC's lack of/poor double buffering would likely not go
so well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-6-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:07 +0000 (16:45 +0200)]
drm/i915/fbc: Introduce intel_fbc_is_compressing()
Move the direct FBC status register reads from the debugfs code
behind an abstract api.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-5-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:06 +0000 (16:45 +0200)]
drm/i915/fbc: Just use params->fence_y_offset always
No need to tiptoe around programming DPFC_FENCE_YOFF with
params->fence_y_offset vs. 0. If the fence is not enabled
it doesn't even matter what we program here.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-4-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:05 +0000 (16:45 +0200)]
drm/i915/fbc: Extract {skl,glk}_fbc_program_cfb_stride()
Declutter gen7_fbc_activate() by sucking the override
stride programming stuff into helpers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-3-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Ville Syrjälä [Thu, 4 Nov 2021 14:45:04 +0000 (16:45 +0200)]
drm/i915/fbc: Extract snb_fbc_program_fence()
We have two identical copies of the snb+ system agent
CPU fence programming code. Extract into a helper.
Also there's no real point in insisting that we
program 0 into DPFC_CPU_FENCE_OFFSET when the fence is
disabled. So just always stick the computed Y offset there
whether or not the fence is actually used or not.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-2-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
William Tseng [Wed, 10 Nov 2021 01:02:17 +0000 (09:02 +0800)]
drm/i915/dsi: transmit brightness command in HS state
In Video Mode, if DSI transcoder is set to transmit packets
in LP Escape mode, screen flickering would be obseved when
brightness commands are continuously and quickly transmitted
to a panel.
The problem may be resolved by changing the mode to transmit
packets from Low Power to HS.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: William Tseng <william.tseng@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211110010217.26759-1-william.tseng@intel.com
Ankit Nautiyal [Wed, 10 Nov 2021 07:29:47 +0000 (12:59 +0530)]
drm/i915/dp: For PCON TMDS mode set only the relavant bits in config DPCD
Currently we reset the whole PCON linkConfig DPCD to set the TMDS mode.
This also resets the Source control bit and HDMI link enable bit and
goes to autonomous mode of operation, which is seen to spoil the PCONs
internal state.
This patch avoids resetting the PCON link config register and sets only
the source control bit, with FRL Enable bit set to 0 (TMDS mode) in the
configuration DPCD. It then enables the HDMI Link Enable bit.
v2: Removed the redundant resetting of the bits as the buffer is already
initialized to 0. (Uma)
Updated comments and commit message.
v3: Rebase
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211110072947.171659-3-ankit.k.nautiyal@intel.com
Ankit Nautiyal [Wed, 10 Nov 2021 07:29:46 +0000 (12:59 +0530)]
drm/i915/dp: Optimize the FRL configuration for HDMI2.1 PCON
Currently the HDMI2.1 PCON's frl link config DPCD registers are
reset and configured even if they are already configured.
Also the HDMI Link Mode does not settle to FRL MODE immediately after
HDMI Link Status is active.
This patch:
-Checks if the PCON is already configured for FRL.
-Include HDMI Link Mode in wait for loop along with HDMI Link status DPCD.
v2: Rebase
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211110072947.171659-2-ankit.k.nautiyal@intel.com
Vandita Kulkarni [Tue, 9 Nov 2021 12:04:28 +0000 (17:34 +0530)]
Revert "drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping"
This reverts commit
991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks
after pll mapping"). The Bspec was updated recently with the pll ungate
sequence similar to that of icl dsi enable sequence. Hence reverting.
Bspec: 49187
Fixes:
991d9557b0c4 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping")
Cc: <stable@vger.kernel.org> # v5.4+
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211109120428.15211-1-vandita.kulkarni@intel.com
Dan Carpenter [Tue, 9 Nov 2021 11:48:50 +0000 (14:48 +0300)]
drm/i915: pin: delete duplicate check in intel_pin_and_fence_fb_obj()
The "ret" variable is checked on the previous line so we know it's
zero. No need to check again.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211109114850.GB16587@kili
Ville Syrjälä [Fri, 5 Nov 2021 21:21:56 +0000 (23:21 +0200)]
drm/i915: Call intel_update_active_dpll() for both bigjoiner pipes
Currently we're only calling intel_update_active_dpll() for the
bigjoiner master pipe but not for the slave. With TC ports this
leads to the two pipes end up trying to use different PLLs
(TC vs. TBT). What's worse we're enabling the PLL that didn't get
intel_update_active_dpll() called on it at the spot where we
need the clocks turned on. So we turn on the wrong PLL and the
DDI is now trying to source its clock from the other PLL which is
still disabled. Naturally that doesn't end so well and the DDI
fails to start up.
The state checker also gets a bit unhappy (which is a good thing)
when it notices that one of the pipes was using the wrong PLL.
Let's fix this by remembering to call intel_update_active_dpll()
for both pipes. That should get the correct PLL turned on when
we need it, and the state checker should also be happy.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4434
Fixes:
e12d6218fda2 ("drm/i915: Reduce bigjoiner special casing")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211105212156.5697-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Wed, 20 Oct 2021 22:33:39 +0000 (01:33 +0300)]
drm/i915: Use unlocked register accesses for LUT loads
We have to bash in a lot of registers to load the higher
precision LUT modes. The locking overhead is significant, especially
as we have to get this done as quickly as possible during vblank.
So let's switch to unlocked accesses for these. Fortunately the LUT
registers are mostly spread around such that two pipes do not have
any registers on the same cacheline. So as long as commits on the
same pipe are serialized (which they are) we should get away with
this without angering the hardware.
The only exceptions are the PREC_PIPEGCMAX registers on ilk/snb which
we don't use atm as they are only used in the 12bit gamma mode. If/when
we add support for that we may need to remember to still serialize
those registers, though I'm not sure ilk/snb are actually affected
by the same cacheline issue. I think ivb/hsw at least were, but they
use a different set of registers for the precision LUT.
I have a test case which is updating the LUTs on two pipes from a
single atomic commit. Running that in a loop for a minute I get the
following worst case with the locks in place:
intel_crtc_vblank_work_start: pipe B, frame=10037, scanline=1081
intel_crtc_vblank_work_start: pipe A, frame=12274, scanline=769
intel_crtc_vblank_work_end: pipe A, frame=12274, scanline=58
intel_crtc_vblank_work_end: pipe B, frame=10037, scanline=74
And here's the worst case with the locks removed:
intel_crtc_vblank_work_start: pipe B, frame=5869, scanline=1081
intel_crtc_vblank_work_start: pipe A, frame=7616, scanline=769
intel_crtc_vblank_work_end: pipe B, frame=5869, scanline=1096
intel_crtc_vblank_work_end: pipe A, frame=7616, scanline=777
The test was done on a snb using the 10bit 1024 entry LUT mode.
The vtotals for the two displays are 793 and 1125. So we can
see that with the locks ripped out the LUT updates are pretty
nicely confined within the vblank, whereas with the locks in
place we're routinely blasting past the vblank end which causes
visual artifacts near the top of the screen.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-5-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Wed, 20 Oct 2021 22:33:38 +0000 (01:33 +0300)]
drm/i915: Use vblank workers for gamma updates
The pipe gamma registers are single buffered so they should only
be updated during the vblank to avoid screen tearing. In fact they
really should only be updated between start of vblank and frame
start because that is the only time the pipe is guaranteed to be
empty. Already at frame start the pipe begins to fill up with
data for the next frame.
Unfortunately frame start happens ~1 scanline after the start
of vblank which in practice doesn't always leave us enough time to
finish the gamma update in time (gamma LUTs can be several KiB of
data we have to bash into the registers). However we must try our
best and so we'll add a vblank work for each pipe from where we
can do the gamma update. Additionally we could consider pushing
frame start forward to the max of ~4 scanlines after start of
vblank. But not sure that's exactly a validated configuration.
As it stands the ~100 first pixels tend to make it through with
the old gamma values.
Even though the vblank worker is running on a high prority thread
we still have to contend with C-states. If the CPU happens be in
a deep C-state when the vblank interrupt arrives even the irq
handler gets delayed massively (I've observed dozens of scanlines
worth of latency). To avoid that problem we'll use the qos mechanism
to keep the CPU awake while the vblank work is scheduled.
With all this hooked up we can finally enjoy near atomic gamma
updates. It even works across several pipes from the same atomic
commit which previously was a total fail because we did the
gamma updates for each pipe serially after waiting for all
pipes to have latched the double buffered registers.
In the future the DSB should take over this responsibility
which will hopefully avoid some of these issues.
Kudos to Lyude for finishing the actual vblank workers.
Works like the proverbial train toilet.
v2: Add missing intel_atomic_state fwd declaration
v3: Clean up properly when not scheduling the worker
v4: Clean up the rest and add tracepoints
v5: s/intel_wait_for_vblank_works/intel_wait_for_vblank_workers/ (Jani,Uma)
CC: Lyude Paul <lyude@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Ville Syrjälä [Wed, 20 Oct 2021 22:33:37 +0000 (01:33 +0300)]
drm/i915: Do vrr push before sampling the frame counter
Do the vrr push before we sample the frame counter to
know when the commit has been latched. Doing these in the
wrong order could lead us to complete the flip before it
has actually happened.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020223339.669-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
William Tseng [Tue, 9 Nov 2021 03:41:25 +0000 (11:41 +0800)]
drm/i915/dsi: disable lpdt if it is not enabled
Avoid setting LP_DATA_TRANSFER when enable_lpdt is false
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: William Tseng <william.tseng@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211109034125.11291-1-william.tseng@intel.com
Radhakrishna Sripada [Sat, 6 Nov 2021 00:37:14 +0000 (17:37 -0700)]
drm/i915: Fix Memory BW formulae for ADL-P
The earlier update to BW formulae broke ADL-P. Include
display 13 to use TGL path for BW parameters.
Fixes:
c64a9a7c05be ("drm/i915: Update memory bandwidth formulae")
Cc: Matt Roper <matthew.d.roper@intel.com>
Reported-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211106003714.17894-1-radhakrishna.sripada@intel.com
José Roberto de Souza [Thu, 4 Nov 2021 01:08:58 +0000 (18:08 -0700)]
drm/i915/display/adlp: Disable underrun recovery
It was also defeatured for ADL-P and other platforms.
BSpec: 55424
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104010858.43559-1-jose.souza@intel.com
Jani Nikula [Thu, 4 Nov 2021 16:18:58 +0000 (18:18 +0200)]
drm/i915/audio: rename intel_init_audio_hooks to intel_audio_hooks_init
Follow the filename based prefix naming.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104161858.21786-6-jani.nikula@intel.com
Jani Nikula [Thu, 4 Nov 2021 16:18:56 +0000 (18:18 +0200)]
drm/i915/audio: move intel_audio_funcs internal to intel_audio.c
It's all internal to intel_audio.c.
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104161858.21786-4-jani.nikula@intel.com
Jani Nikula [Thu, 4 Nov 2021 16:18:55 +0000 (18:18 +0200)]
drm/i915/audio: define the audio struct separately from drm_i915_private
Add a standalone definition of struct intel_audio_private, and note that
all of it is private to intel_audio.c.
v2: Rebase
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104161858.21786-3-jani.nikula@intel.com
Jani Nikula [Thu, 4 Nov 2021 16:18:54 +0000 (18:18 +0200)]
drm/i915/audio: name the audio sub-struct in drm_i915_private
Add name to the audio sub-struct in drm_i915_private, and remove the
tautologies and other inconsistencies in the member names.
v2: Call the mutex member mutex, not lock. (Ville)
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104161858.21786-2-jani.nikula@intel.com
Jani Nikula [Thu, 4 Nov 2021 16:18:53 +0000 (18:18 +0200)]
drm/i915/audio: group audio under anonymous struct in drm_i915_private
With an anonymous struct, this can be pure hierarchical organization
without code changes. We'll follow up with adding a name to the
sub-struct separately.
Cc: Dave Airlie <airlied@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104161858.21786-1-jani.nikula@intel.com
Radhakrishna Sripada [Fri, 15 Oct 2021 21:00:41 +0000 (14:00 -0700)]
drm/i915: Update memory bandwidth formulae
The formulae has been updated to include more variables. Make
sure the code carries the same.
Bspec: 64631, 54023
v2: Make GEN11 follow the default route and fix calculation of
maxdebw(RK)
v3: Fix div by zero on default case
Correct indent for fallthrough(Jani)
v4: Fix div by zero on gen11.
v5: Fix 0 max_numchannels case
v6:
- Split gen11/gen12 algorithms
- Fix RKL deburst value
- Fix difference b/ween ICL and TGL algorithms
- Protect deinterleave from being 0
- Warn when numchannels exceeds max_numchannels
- Fix scaling of clk_max from different units
- s/deinterleave/channelwidth/ in calculating peakbw
- Fix off by one for num_planes TGL+
- Fix SAGV check
v7: Fix div by zero error on gen11
v8: Even though the algorithm for gen11 says that we need to return
derated bw for a qgv point whose planes are less than no of active
planes, we return 0 for deratedbw when only one plane is allowed.
We modify the algorithm to accommodate the case where no of active
planes are same as the min no of planes supported by a qgv point.
v9: Fix dclk scaling for dg1
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211015210041.16858-1-radhakrishna.sripada@intel.com
Ville Syrjälä [Mon, 18 Oct 2021 11:50:30 +0000 (14:50 +0300)]
drm/i915: Split vlv/chv sprite plane update into noarm+arm pair
Chop vlv_sprite_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
Looks like most of the hardware logic was copied from the
pre-ctg sprite C, so SPSTRIDE/POS/SIZE are armed by SPSURF,
while the rest are self arming. SPCONSTALPHA is the one
entirely new register that didn't exist in the old sprite C,
and looks like that one is self arming. The CHV pipe B CSC
is also self arming, like the rest of the CHV pipe B
additions.
I didn't have time to capture i915_update_info numbers for
these, but since all the other platforms generally showed
improvements, and crucially no regression, I am fairly
confident this should behave similarly.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-10-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Mon, 18 Oct 2021 11:50:29 +0000 (14:50 +0300)]
drm/i915: Split ivb+ sprite plane update into noarm+arm pair
Chop ivb_sprite_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
Didn't bother with i915_update_info numbers for this one.
I expect the results to be pretty much identical to the snb
numbers from the corresponding g4x+ sprite modification.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-9-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Mon, 18 Oct 2021 11:50:28 +0000 (14:50 +0300)]
drm/i915: Split g4x+ sprite plane update into noarm+arm pair
Chop g4x_sprite_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
Not much of a change in i915_update_info on these older
platforms that don't have so many planes or registers to
begin with. Here are the numbers from snb (totally unpatched
vs. both primary plane and sprite patched applied) running
kms_atomic_transition --r plane-all-transition --extended:
w/o patch w/ patch
Updates: 5404 Updates: 5405
| |
1us |****** 1us |******
|********* |*********
4us |*********** 4us |***********
|********** |**********
16us |** 16us |**
| |
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 1400ns Min update: 1307ns
Max update: 19809ns Max update: 20194ns
Average update: 6957ns Average update: 6432ns
Overruns > 100us: 0 Overruns > 100us: 0
But there seems to be a slight improvement with
lockdep enabled:
w/o patch w/ patch
Updates: 17612 Updates: 16364
| |
1us | 1us |
|****** |******
4us |********** 4us |**********
|************ |*************
16us |************* 16us |************
|*** |*
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 3141ns Min update: 3562ns
Max update: 126450ns Max update: 73354ns
Average update: 16373ns Average update: 15153ns
Overruns > 250us: 0 Overruns > 250us: 0
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-8-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Wed, 20 Oct 2021 21:27:57 +0000 (00:27 +0300)]
drm/i915: Split pre-skl primary plane update into noarm+arm pair
Chop i9xx_plane_update() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
One slightly surprising fact was that the CHV pipe B PRIMPOS/SIZE
registers are self arming unlike their pre-ctg DSPPOS/SIZE
counterparts. In fact all the new CHV pipe B registers are
self arming.
Also we must remind ourselves that i830/i845 are a bit borked
in that all of their plane registers are self-arming.
I didn't do any i915_update_info measurements for this one
alone. I'll get total numbers with the corrsponding sprite
plane changes.
v2: Don't break my precious i830/i845
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020212757.13517-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Mon, 18 Oct 2021 11:50:26 +0000 (14:50 +0300)]
drm/i915: Split skl+ plane update into noarm+arm pair
Chop skl_program_plane() into two halves. Fist half becomes
the _noarm() variant, second part the _arm() variant.
Fortunately I have already previously grouped the register
writes into roughtly the correct order, so the split looks
surprisingly clean.
A few notable oddities I did not realize were self arming
are AUX_DIST and COLOR_CTL.
i915_update_info doesn't look too terrible on my cfl running
kms_atomic_transition --r plane-all-transition --extended:
w/o patch w/ patch
Updates: 2178 Updates: 2018
| |
1us | 1us |
| |
4us | 4us |*****
|********* |**********
16us |********** 16us |*******
|*** |
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 8332ns Min update: 6164ns
Max update: 48758ns Max update: 31808ns
Average update: 19959ns Average update: 13159ns
Overruns > 100us: 0 Overruns > 100us: 0
And with lockdep enabled:
w/o patch w/ patch
Updates: 2177 Updates: 2172
| |
1us | 1us |
| |
4us | 4us |
|******* |*********
16us |********** 16us |**********
|******* |*
66us | 66us |
| |
262us | 262us |
| |
1ms | 1ms |
| |
4ms | 4ms |
| |
17ms | 17ms |
| |
Min update: 12645ns Min update: 9980ns
Max update: 50153ns Max update: 33533ns
Average update: 25337ns Average update: 18245ns
Overruns > 250us: 0 Overruns > 250us: 0
TODO: On icl+ everything seems to be armed by PLANE_SURF, so we
can optimize this even further on modern platforms. But I
think there's a bit of refactoring to be done first to
figure out the best way to go about it (eg. just reusing
the current skl+ functions, or doing a lower level split).
TODO: Split scaler programming as well, but IIRC the scaler
has some oddball double buffering behaviour on some
platforms, so needs proper reverse engineering
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-6-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Mon, 18 Oct 2021 11:50:25 +0000 (14:50 +0300)]
drm/i915: Split update_plane() into update_noarm() + update_arm()
The amount of plane registers we have to write has been steadily
increasing, putting more pressure on the vblank evasion mechanism
and forcing us to increase its time budget. Let's try to take some
of the pressure off by splitting plane updates into two parts:
1) write all non-self arming plane registers, ie. the registers
where the write actually does nothing until a separate arming
register is also written which will cause the hardware to latch
the new register values at the next start of vblank
2) write all self arming plane registers, ie. registers which always
just latch at the next start of vblank, and registers which also
arm other registers to do so
Here we just provide the mechanism, but don't actually implement
the split on any platform yet. so everything stays now in the _arm()
hooks. Subsequently we can move a whole bunch of stuff into the
_noarm() part, especially in more modern platforms where the number
of registers we have to write is also the greatest. On older
platforms this is less beneficial probably, but no real reason
to deviate from a common behaviour.
And let's sprinkle some TODOs around the areas that will need
adapting.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Mon, 18 Oct 2021 11:50:24 +0000 (14:50 +0300)]
drm/i915: Fix up the sprite namespacing
Give all sprite exclusive functions/etc. a proper namespace.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-4-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Mon, 18 Oct 2021 11:50:23 +0000 (14:50 +0300)]
drm/i915: Fix async flip with decryption and/or DPT
We're currently forgetting to set the PLANE_SURF_DECRYPT
flag in the async flip path. So if the hardware were to
latch that bit despite this being an async flip we'd start
scanning out garbage. And if it doesn't latch it then I
guess we'd just end up with a weird register value that
doesn't actually match the hardware state, which isn't
great for anyone staring at register dumps.
Similarly the async flip path also forgets to call
skl_surf_address() which means the DPT address space to
GGTT address space downshift is not being applied to
the offset. Which means we are pointing PLANE_SURF
at some random location in GGTT instead of the correct
DPT page.
So let's fix two birds with one stone and extract the
PLANE_SURF calculation from skl_program_plane() into
a small helper and use it in the async flip path as well.
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Juston Li <juston.li@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-3-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Mon, 18 Oct 2021 11:50:22 +0000 (14:50 +0300)]
drm/i915: Reject planar formats when doing async flips
Async flips are only capable of changing PLANE_SURF, hence we
they can't easily be used with planar formats.
Older platforms could require updating AUX_DIST as well, which
is not possible. We'd have to make sure AUX_DIST doesn't change
before allowing the async flip through. If we could get async
flips with CCS then that might be interesting, but since the hw
doesn't allow async flips with CCS I don't see much point in
allowing this for planar formats either. No one renders their
game content in YUV anyway.
icl+ could in theory do this I suppose since each color plane
has its own PLANE_SURF register, but I don't know if there is
some magic to guarantee that both the Y and UV plane would
async flip synchronously if you will. Ie. beyond just a clean
tear we'd potentially get some kind of weird tear with some
random mix of luma and chroma from the old and new frames.
So let's just say no to async flips when scanning out planar
formats.
Cc: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:36 +0000 (23:49 +0300)]
drm/i915: Use intel_de_rmw() for icl combo phy programming
Streamline the code by using intel_de_rmw().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-16-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:35 +0000 (23:49 +0300)]
drm/i915: Use intel_de_rmw() for icl mg phy programming
Streamline the code by using intel_de_rmw().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-15-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:34 +0000 (23:49 +0300)]
drm/i915: Use intel_de_rmw() for tgl dkl phy programming
Streamline the code by using intel_de_rmw().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-14-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:33 +0000 (23:49 +0300)]
drm/i915: Enable per-lane drive settings for icl+
Now that the link buf_trans, link training, and the
combo/mg/dkl/snps phy programming are all fixed up we can
allow per-lane DP drive settings on icl+. Make it so.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-13-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:32 +0000 (23:49 +0300)]
drm/i915: Query the vswing levels per-lane for snps phy
Prepare for per-lane drive settings by querying the desired vswing
level per-lane.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-12-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:31 +0000 (23:49 +0300)]
drm/i915: Query the vswing levels per-lane for tgl dkl phy
Prepare for per-lane drive settings by querying the desired vswing
level per-lane.
Note that the code only does two loops, with each one writing the
levels for two TX lanes. The register offsets also look a bit funny
because each time through the loop we write to the exact same
register offsets. The crucial bit is the HIP_INDEX_REG
write that steers the same mmio window into different places.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-11-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:30 +0000 (23:49 +0300)]
drm/i915: Query the vswing levels per-lane for icl mg phy
Prepare for per-lane drive settings by querying the desired vswing
level per-lane.
Note that the code only does two loops, with each one writing the
levels for two TX lanes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-10-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:29 +0000 (23:49 +0300)]
drm/i915: Query the vswing levels per-lane for icl combo phy
Prepare for per-lane drive settings by querying the desired vswing
level per-lane.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-9-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:28 +0000 (23:49 +0300)]
drm/i915: Stop using group access when progrmming icl combo phy TX
Program each TX lane individually so that we can start to use per-lane
drive settings.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-8-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Javier Martinez Canillas [Wed, 3 Nov 2021 12:28:05 +0000 (13:28 +0100)]
drm/i915: Fix comment about modeset parameters
The comment mentions that the KMS is enabled by default unless either the
i915.modeset module parameter or vga_text_mode_force boot option are used.
But the latter does not exist and instead the nomodeset option was meant.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211103122809.1040754-2-javierm@redhat.com
Imre Deak [Mon, 1 Nov 2021 18:35:51 +0000 (20:35 +0200)]
drm/i915: Restore memory mapping for DPT FBs across system suspend/resume
At least during hibernation the DPT mappings are lost with all stolen
memory content, so suspend/resume these mappings similarly to GGTT
mappings.
This fixes a problem where the restoring modeset during system resume fails
with pipe faults if a tiled framebuffer was active before suspend.
v2: Clarify the way restore works in intel_dpt_resume()'s Docbook entry.
(Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Vunny Sodhi <vunny.sodhi@intel.com>
Reported-and-tested-by: Vunny Sodhi <vunny.sodhi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211101183551.3580546-2-imre.deak@intel.com
Imre Deak [Mon, 1 Nov 2021 18:35:50 +0000 (20:35 +0200)]
drm/i915: Factor out i915_ggtt_suspend_vm/i915_ggtt_resume_vm()
Factor out functions that are needed by the next patch to suspend/resume
the memory mappings for DPT FBs.
No functional change, except reordering during suspend the
ggtt->invalidate(ggtt) call wrt. atomic_set(&ggtt->vm.open, open) and
mutex_unlock(&ggtt->vm.mutex). This shouldn't matter due to the i915
suspend sequence being single threaded.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211101183551.3580546-1-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 22:51:05 +0000 (01:51 +0300)]
drm/i915/adlp/fb: Remove restriction on CCS AUX plane strides
As opposed to other GEN12 platforms ADLP provides a way to program the
stride of CCS surfaces independently of the main surface stride (within
the corresponding limit of the preceding and succeeding power-of-two
values of the main surface stride). Using this HW feature we can remove
the POT stride restriction on CCS surfaces, making the ADLP CCS FB uAPI
(FB modifiers) identical to that of TGL.
The HW makes the CCS stride flexible programming possible by deriving
the stride from the value programmed to the PLANE_STRIDE register. After
that the HW rounds up this value to the next power-of-two value and uses
this for walking the pages of the main surface mapped to GTT/DPT.
To align with the above scheme, introduce a scanout_stride view
parameter which will be programmed to the PLANE_STRIDE register and use
the mapping_stride view param to store the POT aligned value of the
same. By requiring userspace to pass in FBs with a CCS stride that
aligns with the main surface stride (matching the requirement of all
GEN12 platforms), the scanout_stride will be the userspace main surface
stride and the mapping_stride will be the POT rounded value of the same.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Nanley G Chery <nanley.g.chery@intel.com>
Cc: Sameer Lattannavar <sameer.lattannavar@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-8-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 22:51:04 +0000 (01:51 +0300)]
drm/i915/adlp/fb: Remove restriction on semiplanar UV plane offset
Since the surfaces of tiled FBs on ADLP are remapped it's pointless to
require an alignment in the allocated object. The necessary tile-row
alignment (to be programmed to the surface start register) will be
ensured later when flipping to the FB.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-7-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 22:51:03 +0000 (01:51 +0300)]
drm/i915/fb: Rename i915_color_plane_view::stride to mapping_stride
The next patch needs to distinguish between a view's mapping and scanout
stride. Rename the current stride parameter to mapping_stride with the
script below. mapping_stride will keep the same meaning as stride had
on all platforms so far, while the meaning of it will change on ADLP.
No functional changes.
@@
identifier intel_fb_view;
identifier i915_color_plane_view;
identifier color_plane;
expression e;
type T;
@@
struct intel_fb_view {
...
struct i915_color_plane_view {
...
- T stride;
+ T mapping_stride;
...
} color_plane[e];
...
};
@@
struct i915_color_plane_view pv;
@@
pv.
- stride
+ mapping_stride
@@
struct i915_color_plane_view *pvp;
@@
pvp->
- stride
+ mapping_stride
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-6-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 22:51:02 +0000 (01:51 +0300)]
drm/i915/adlp/fb: Fix remapping of linear CCS AUX surfaces
During remapping CCS FBs the CCS AUX surface mapped size and offset->x,y
coordinate calculations assumed a tiled layout. This works as long as
the CCS surface height is aligned to 64 lines (ensuring a 4k bytes CCS
surface tile layout). However this alignment is not required by the HW
(and the driver doesn't enforces it either).
Add the remapping logic required to remap the pages of CCS surfaces
without the above alignment, assuming the natural linear layout of the
CCS surface (vs. tiled main surface layout).
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes:
3d1adc3d64cf ("drm/i915/adlp: Add support for remapping CCS FBs")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-5-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 22:51:01 +0000 (01:51 +0300)]
drm/i915/fb: Factor out functions to remap contiguous FB obj pages
Factor out functions needed to map contiguous FB obj pages to a GTT/DPT
VMA view in the next patch.
While at it s/4096/I915_GTT_PAGE_SIZE/ in add_padding_pages().
No functional changes.
v2: s/4096/I915_GTT_PAGE_SIZE/ (Matthew)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-4-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 22:51:00 +0000 (01:51 +0300)]
drm/i915/adlp/fb: Prevent the mapping of redundant trailing padding NULL pages
So far the remapped view size in GTT/DPT was padded to the next aligned
offset unnecessarily after the last color plane with an unaligned size.
Remove the unnecessary padding.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Fixes:
3d1adc3d64cf ("drm/i915/adlp: Add support for remapping CCS FBs")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-3-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 22:50:59 +0000 (01:50 +0300)]
drm/i915/fb: Fix rounding error in subsampled plane size calculation
For NV12 FBs with odd main surface tile-row height the CCS surface
height was incorrectly calculated 1 less than the actual value. Fix this
by rounding up the result of divison. For consistency do the same for
the CCS surface width calculation.
Fixes:
b3e57bccd68a ("drm/i915/tgl: Gen-12 render decompression")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-2-imre.deak@intel.com
Kai Vehmanen [Thu, 21 Oct 2021 10:59:15 +0000 (13:59 +0300)]
drm/i915/display: program audio CDCLK-TS for keepalives
XE_LPD display adds support for display audio codec keepalive feature.
This feature works also when display codec is in D3 state and the audio
link is off (BCLK off). To enable this functionality, display driver
must update the AUD_TS_CDCLK_M/N registers whenever CDCLK is changed.
Actual timestamps are generated only when the audio codec driver
specifically enables the KeepAlive (KAE) feature.
This patch adds new hooks to intel_set_cdclk() in order to inform
display audio driver when CDCLK change is started and when it is
complete.
Bspec: 53679
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211021105915.4128635-1-kai.vehmanen@linux.intel.com
José Roberto de Souza [Fri, 29 Oct 2021 20:24:32 +0000 (13:24 -0700)]
drm/i915/display: Check async flip state of every crtc and plane once
For every crtc in state, intel_atomic_check_async() was checking all
the crtc and plane states again.
v2: comparing pipe ids instead of crtc pointers when iterating over
planes
Cc: Karthik B S <karthik.b.s@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211029202432.140745-1-jose.souza@intel.com
Ville Syrjälä [Fri, 29 Oct 2021 19:18:02 +0000 (22:18 +0300)]
drm/i915/hdmi: Turn DP++ TMDS output buffers back on in encoder->shutdown()
Looks like our VBIOS/GOP generally fail to turn the DP dual mode adater
TMDS output buffers back on after a reboot. This leads to a black screen
after reboot if we turned the TMDS output buffers off prior to reboot.
And if i915 decides to do a fastboot the black screen will persist even
after i915 takes over.
Apparently this has been a problem ever since commit
b2ccb822d376 ("drm/i915:
Enable/disable TMDS output buffers in DP++ adaptor as needed") if one
rebooted while the display was turned off. And things became worse with
commit
fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
since now we always turn the display off before a reboot.
This was reported on a RKL, but I confirmed the same behaviour on my
SNB as well. So looks pretty universal.
Let's fix this by explicitly turning the TMDS output buffers back on
in the encoder->shutdown() hook. Note that this gets called after irqs
have been disabled, so the i2c communication with the DP dual mode
adapter has to be performed via polling (which the gmbus code is
perfectly happy to do for us).
We also need a bit of care in handling DDI encoders which may or may
not be set up for HDMI output. Specifically ddc_pin will not be
populated for a DP only DDI encoder, in which case we don't want to
call intel_gmbus_get_adapter(). We can handle that by simply doing
the dual mode adapter type check before calling
intel_gmbus_get_adapter().
Cc: <stable@vger.kernel.org> # v5.11+
Fixes:
fe0f1e3bfdfe ("drm/i915: Shut down displays gracefully on reboot")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4371
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211029191802.18448-2-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Ville Syrjälä [Fri, 29 Oct 2021 19:18:01 +0000 (22:18 +0300)]
drm/i915: Don't request GMBUS to generate irqs when called while irqs are off
We will need to do some i2c poking from the encoder->shutdown() hook.
Currently that gets called after irqs have been turned off. We still
poll the gmbus status bits even if the interrupt never arrives so
things will work just fine. But seems like asking gmbus to generate
interrupts we will never see is a bit pointless, so don't.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211029191802.18448-1-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Anusha Srivatsa [Wed, 6 Oct 2021 20:45:47 +0000 (13:45 -0700)]
i915/display/dmc: Add Support for PipeC and PipeD DMC
So far we had support for main, PipeA and PipeB
DMC. If we find a binary from PipeA-D, lets load it.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204547.669464-1-anusha.srivatsa@intel.com
José Roberto de Souza [Thu, 28 Oct 2021 23:04:49 +0000 (16:04 -0700)]
drm/i915/adlp: Implement workaround
16013190616
New workaround added to specification, requiring bit 15 of
GEN8_CHICKEN_DCPR_1 to be programed before power well 1 is enabled.
BSpec: 54369
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211028230449.115832-1-jose.souza@intel.com
Jouni Högander [Thu, 21 Oct 2021 10:10:24 +0000 (13:10 +0300)]
Revert "drm/i915/display/psr: Do full fetch when handling multi-planar formats"
This reverts commit
1f61f0655b95d5b89589390e6f83c4a61d9b1e8d.
Now we are supporting selective fetch for biplanar formats.
We can revert WA patch which forced using full fetch for biplanar
formats.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211021101024.13112-3-jouni.hogander@intel.com
Jouni Högander [Thu, 21 Oct 2021 10:10:23 +0000 (13:10 +0300)]
drm/i915/display: Add initial selective fetch support for biplanar formats
Biplanar formats are using two planes (Y and UV). This patch adds handling
of Y selective fetch area by utilizing existing linked plane mechanism.
Also UV plane Y offset configuration is modified according to Bspec.
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211021101024.13112-2-jouni.hogander@intel.com
Imre Deak [Wed, 27 Oct 2021 12:51:50 +0000 (15:51 +0300)]
drm/i915/fb: Fold modifier CCS type/tiling attribute to plane caps
By using the modifier plane capability flags to encode the modifiers'
CCS type and tiling attributes, it becomes simpler to the check for
any of these capabilities when providing the list of supported
modifiers.
This also allows distinguishing modifiers on future platforms where
platforms with the same display version support different modifiers. An
example is DG2 and ADLP, both being D13, where DG2 supports only F and X
tiling, while ADLP supports only Y and X tiling. With the
INTEL_PLANE_CAP_TILING_* flags added in this patch we can provide
the correct modifiers for each platform.
v2:
- Define PLANE_HAS_* with macros instead of an enum. (Jani)
- Rename PLANE_HAS_*_ANY to PLANE_HAS_*_MASK. (Jani)
- Rename PLANE_HAS_* to INTEL_PLANE_CAP_*.
- Set the CCS_RC_CC cap only for DISPLAY_VER >= 12.
- Set the TILING_Y cap only for DISPLAY_VER < 13 || ADLP.
- Simplify the SKL plane cap display version checks and move them
to a separate function.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027125150.2891371-1-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 16:15:16 +0000 (19:15 +0300)]
drm/i915/fb: Don't store bitmasks in the intel_plane_caps enum
Variables of enum types can contain only the values listed at the enums
definition, so don't store bitmasks in intel_plane_caps enum variables.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026161517.2694067-3-imre.deak@intel.com
Imre Deak [Tue, 26 Oct 2021 16:15:15 +0000 (19:15 +0300)]
drm/i915/fb: Don't report MC CCS plane capability on GEN<12
Remove the MC CCS plane capability on GEN<12, since it's not present
there. This didn't cause a problem, since the display version check
filtered out the MC CCS modifiers before GEN12.
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026161517.2694067-2-imre.deak@intel.com
Jani Nikula [Fri, 29 Oct 2021 10:38:34 +0000 (13:38 +0300)]
Merge drm/drm-next into drm-intel-next
Backmerge to get the DP 2.0 MST changes merged to drm-next. This also
syncs us up to v5.15-rc7.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Wed, 6 Oct 2021 20:49:37 +0000 (23:49 +0300)]
drm/i915: Fix icl+ combo phy static lane power down setup
Our lane power down defines already include the necessary shift,
don't shift them a second time.
Fortunately we masked off the correct bits, so we accidentally
left all lanes powered up all the time.
Bits 8-11 where we end up writing our misdirected lane mask are
documented as MBZ, but looks like you can actually write there
so they're not read only bits. No idea what side effect the
bogus register write might have.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4151
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-17-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Mon, 25 Oct 2021 14:21:47 +0000 (17:21 +0300)]
drm/i915: Fix type1 DVI DP dual mode adapter heuristic for modern platforms
Looks like we never updated intel_bios_is_port_dp_dual_mode() when
the VBT port mapping became erratic on modern platforms. This
is causing us to look up the wrong child device and thus throwing
the heuristic off (ie. we might end looking at a child device for
a genuine DP++ port when we were supposed to look at one for a
native HDMI port).
Fix it up by not using the outdated port_mapping[] in
intel_bios_is_port_dp_dual_mode() and rely on
intel_bios_encoder_data_lookup() instead.
Cc: stable@vger.kernel.org
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4138
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025142147.23897-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
José Roberto de Souza [Wed, 27 Oct 2021 18:05:45 +0000 (11:05 -0700)]
drm/i915/adlp: Extend PSR2 support in transcoder B
PSR2 is supported in transcoder A and B on Alderlake-P.
v2:
- explicity checking for transcoder A and B to avoid invalid transcoder
BSpec: 49185
Reviewed-by: Jouni Högander <jouni.hogander@intel.com> # v1
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Jouni Hogander <jouni.hogander@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com> # v2
Link: https://patchwork.freedesktop.org/patch/msgid/20211027180545.55660-1-jose.souza@intel.com
Jani Nikula [Wed, 27 Oct 2021 13:59:00 +0000 (16:59 +0300)]
drm/i915/dsc: demote noisy drm_info() to drm_kms_dbg()
The PPS, RC_RANGE_PARAM, and RC_BUF_THRESH logging are clearly for
debugging, and should not be info level messages.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027135900.6329-1-jani.nikula@intel.com
Laurent Pinchart [Wed, 27 Oct 2021 23:31:40 +0000 (02:31 +0300)]
drm: Add R10 and R12 FourCC
Add FourCCs for 10- and 12-bit red formats with padding to 16 bits.
They correspond to the V4L2 10- and 12-bit greyscale (V4L2_PIX_FMT_Y10
and V4L2_PIX_FMT_Y12) formats, as well as the Bayer formats with the
same bit depth (V4L2_PIX_FMT_SBGGR{10,12} and all other Bayer pattern
permutations).
These formats are not used by any kernel driver at this point, but need
to be exposed to applications by libcamera, which uses DRM FourCCs for
pixel formats.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027233140.12268-1-laurent.pinchart@ideasonboard.com
Dave Airlie [Thu, 28 Oct 2021 05:01:25 +0000 (15:01 +1000)]
Merge tag 'drm-msm-next-2021-10-26' of https://gitlab.freedesktop.org/drm/msm into drm-next
* eDP support in DP sub-driver (for newer SoCs with native eDP output)
* dpu irq handling cleanup
* CRC support for making igt happy
* Support for NO_CONNECTOR bridges
* dsi: 14nm phy support for msm8953
* mdp5: support for msm8x53, sdm450, sdm632
* various smaller fixes and cleanups
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsH9EwcpqGNNRJeL99NvFFjHX3SUg+nTYu0dHG5U9+QuA@mail.gmail.com
Dave Airlie [Thu, 28 Oct 2021 04:59:38 +0000 (14:59 +1000)]
BackMerge tag 'v5.15-rc7' into drm-next
The msm next tree is based on rc3, so let's just backmerge rc7 before pulling it in.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Thu, 28 Oct 2021 00:36:26 +0000 (10:36 +1000)]
Merge tag 'topic/amdgpu-dp2.0-mst-2021-10-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
UAPI Changes:
Nope!
Cross-subsystem Changes:
drm_dp_update_payload_part1() takes a new argument for specifying what the
VCPI slot start is
Core Changes:
Make the DP MST helpers aware of the current starting VCPI slot/VCPI total
slot count...
Driver Changes:
...and then add support for taking advantage of this for 128b/132b links on DP
2.0 for amdgpu
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bf8e724cc0c8803d58a8d730fd6883c991376a76.camel@redhat.com
Alex Deucher [Wed, 27 Oct 2021 22:39:14 +0000 (18:39 -0400)]
drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not set
Need to guard some things with CONFIG_DRM_AMD_DC_DCN.
Fixes:
41724ea273cdda ("drm/amd/display: Add DP 2.0 MST DM Support")
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211027223914.1776061-1-alexander.deucher@amd.com
Ville Syrjälä [Fri, 22 Oct 2021 10:33:04 +0000 (13:33 +0300)]
drm/i915: Nuke PIPE_CONFIG_QUIRK_BIGJOINER_SLAVE
Now that the bigjoiner state readout/computation has been
made to do the right thing nuke the related state checker
quirk.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-10-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 22 Oct 2021 10:33:03 +0000 (13:33 +0300)]
drm/i915: Reduce bigjoiner special casing
Try to make bigjoiner pipes less special.
The main things here are that each pipe now does full
clock computation/readout with its own shared_dpll reference.
Also every pipe's cpu_transcoder always points correctly
at the master transcoder.
Due to the above changes state readout is now complete
and all the related hacks can go away. The actual modeset
sequence code is still a mess, but I think in order to clean
that up properly we're probably going to have to redesign
the modeset logic to treat transcoders vs. pipes separately.
That is going to require significant amounts of work.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-9-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 22 Oct 2021 10:33:02 +0000 (13:33 +0300)]
drm/i915: Perform correct cpu_transcoder readout for bigjoiner
Read out cpu_transcoder correctly for the bigjoiner slave pipes.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-8-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 22 Oct 2021 10:33:01 +0000 (13:33 +0300)]
drm/i915: Split PPS write from DSC enable
The PPS SDP is fed into the transcoder whereas the DSC
block is (or at least can be) per pipe. Let's split these
into two distinct operations in an effort to untagle the
bigjoiner mess where we have two pipes feeding a single
transcoder.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-7-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 22 Oct 2021 10:33:00 +0000 (13:33 +0300)]
drm/i915: Simplify intel_crtc_copy_uapi_to_hw_state_nomodeset()
Rewrite intel_crtc_copy_uapi_to_hw_state_nomodeset() in a
slightly more straightforward manner.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-6-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 22 Oct 2021 10:32:59 +0000 (13:32 +0300)]
drm/i915: Introduce intel_master_crtc()
Add a helper to determine the master crtc for bigjoiner usage.
Also name the variables consistently.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-5-ville.syrjala@linux.intel.com
Ville Syrjälä [Fri, 22 Oct 2021 10:32:58 +0000 (13:32 +0300)]
drm/i915: Disable all planes before modesetting any pipes
Let's disable planes on all pipes affected by the modeset before
we start doing the actual modeset. This means we have less
random planes enabled during the modeset, and it also mirrors
what we already do when enabling pipes on skl+ since we enable
planes on all pipes as the very last step. As a bonus we also
nuke a bunch og bigjoiner special casing.
I've occasionally pondered about going even furher here and
doing the pre_plane_update() stuff for all pipes first, then
actually disabling the planes, and finally running the rest
of the modeset sequence. This would potentially allow
parallelizing all the extra vblank waits across multiple pipes,
and would make the plane disable even more atomic. But let's
go one step a time here.
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 22 Oct 2021 10:32:57 +0000 (13:32 +0300)]
Revert "drm/i915/display: Disable audio, DRRS and PSR before planes"
Disabling planes in the middle of the modeset seuqnece does not make
sense since userspace can anyway disable planes before the modeset
even starts. So when the modeset seuqence starts the set of enabled
planes is entirely arbitrary. Trying to sprinkle the plane disabling
into the modeset sequence just means more randomness and potential
for hard to reproduce bugs.
So it makes most sense to just disable all planes first so that the
rest of the modeset sequence remains identical regardless of which
planes happen to be enabled by userspace at the time.
This reverts commit
84030adb9e27d202a66022488bf0349a8bd45213.
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Ville Syrjälä [Fri, 22 Oct 2021 10:32:56 +0000 (13:32 +0300)]
drm/i915/psr: Disable PSR before modesets turn off all planes
PSR2 apparently requires some planes to be enabled for some
silly reason, and so we are now trying to turn PSR off before
planes go off. Except during a full modeset that is handled
less clearly through reorganization of the modeset sequence.
That is not great as it makes the code mode complex, and
prevents us from doing nice things such as just turning off
all the planes at the very start of the modeset. So let's
move the PSR pre_plane_update() thing to a spot where it
will handle both full modesets and everything else.
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022103304.24164-2-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Mullati, Siva [Fri, 22 Oct 2021 19:27:56 +0000 (00:57 +0530)]
drm/i915: abstraction for iosf to compile on all archs
The asm/iosf_mbi.h header is x86-only. Let's make IOSF_MBI kconfig
selection conditional to x86 and provide a header with stubs for other
architectures. This helps getting i915 available for other
architectures in future.
Signed-off-by: Mullati, Siva <siva.mullati@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/20211022192756.1228354-1-siva.mullati@intel.com
Dave Airlie [Wed, 27 Oct 2021 00:38:38 +0000 (10:38 +1000)]
Merge tag 'amd-drm-next-5.16-2021-10-22' of https://gitlab.freedesktop.org/agd5f/linux into drm-next
amd-drm-next-5.16-2021-10-22:
amdgpu:
- PSP fix for resume
- XGMI fixes
- Interrupt fix in device tear down
- Renoir USB-C DP alt mode fix for resume
- DP 2.0 fixes
- Yellow Carp display fixes
- Misc display fixes
- RAS fixes
- IP Discovery enumeration fixes
- VGH fixes
- SR-IOV fixes
- Revert ChromeOS workaround in display code
- Cyan Skillfish fixes
amdkfd:
- Fix error handling in gpu memory allocation
- Fix build warnings with some configs
- SVM fixes
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022183112.4574-1-alexander.deucher@amd.com
José Roberto de Souza [Tue, 5 Oct 2021 23:18:51 +0000 (16:18 -0700)]
drm/i915/display: Wait PSR2 get out of deep sleep to update pipe
Alderlake-P was getting 'max time under evasion' messages when PSR2
is enabled, this is due PIPE_SCANLINE/PIPEDSL returning 0 over a
period of time longer than VBLANK_EVASION_TIME_US.
For PSR1 we had the same issue so intel_psr_wait_for_idle() was
implemented to wait for PSR1 to get into idle state but nothing was
done for PSR2.
For PSR2 we can't only wait for idle state as PSR2 tends to keep
into sleep state(ready to send selective updates).
Waiting for any state below deep sleep proved to be effective in
avoiding the evasion messages and also not wasted a lot of time.
v2:
- dropping the additional wait_for loops, only the _wait_for_atomic()
is necessary
- waiting for states below EDP_PSR2_STATUS_STATE_DEEP_SLEEP
v3:
- dropping intel_wait_for_condition_atomic() function
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005231851.67698-1-jose.souza@intel.com
Arnd Bergmann [Tue, 26 Oct 2021 08:32:41 +0000 (10:32 +0200)]
drm/msm/dp: fix missing #include
Some randconfig builds fail when drm/drm_bridge.h is not included
implicitly in this file:
drivers/gpu/drm/msm/dp/dp_parser.c:279:25: error: implicit declaration of function 'devm_drm_panel_bridge_add' [-Werror,-Wimplicit-function-declaration]
parser->panel_bridge = devm_drm_panel_bridge_add(dev, panel);
Fixes:
4b296d15b355 ("drm/msm/dp: Allow attaching a drm_panel")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211026083254.3396322-1-arnd@kernel.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Nathan Chancellor [Tue, 26 Oct 2021 14:24:36 +0000 (07:24 -0700)]
drm/msm/dpu: Remove commit and its uses in dpu_crtc_set_crc_source()
Clang warns:
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:162:6: error: variable 'commit' is uninitialized when used here [-Werror,-Wuninitialized]
if (commit)
^~~~~~
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c:106:32: note: initialize the variable 'commit' to silence this warning
struct drm_crtc_commit *commit;
^
= NULL
1 error generated.
The assignment and use of commit in the main body of
dpu_crtc_set_crc_source() were removed from v1 to v2 but the call to
drm_crtc_commit_put() at the end was not. Do that now so there is no
more warning.
Fixes:
78d9b458cc21 ("drm/msm/dpu: Add CRC support for DPU")
Link: https://github.com/ClangBuiltLinux/linux/issues/1493
Reported-by: "kernelci.org bot" <bot@kernelci.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20211026142435.3606413-1-nathan@kernel.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Jani Nikula [Tue, 26 Oct 2021 09:34:07 +0000 (12:34 +0300)]
drm/i915/dp: fix integer overflow in 128b/132b data rate calculation
The intermediate value 1000000 * 10 * 9671 overflows 32 bits, so force
promotion to a bigger type.
From the logs:
[drm:intel_dp_compute_config [i915]] DP link rate required 3657063 available -
580783288
v2: Use mul_u32_u32() (Ville)
Fixes:
48efd014f0ea ("drm/i915/dp: add max data rate calculation for UHBR rates")
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026093407.11381-1-jani.nikula@intel.com
Bhawanpreet Lakha [Mon, 25 Oct 2021 22:38:24 +0000 (18:38 -0400)]
drm/amd/display: Add DP 2.0 MST DM Support
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Reviewed-by: "Lin, Wayne" <Wayne.Lin@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-5-lyude@redhat.com
Fangzhi Zuo [Mon, 25 Oct 2021 22:38:23 +0000 (18:38 -0400)]
drm/amd/display: Add DP 2.0 MST DC Support
[Why]
configure/call DC interface for DP2 mst support. This is needed to make DP2
mst work.
[How]
- add encoding type, logging, mst update/reduce payload functions
Use the link encoding to determine the DP type (1.4 or 2.0) and add a
flag to dc_stream_update to determine whether to increase/reduce
payloads.
v2:
* add DP_UNKNOWN_ENCODING handling
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
Reviewed-by: "Lin, Wayne" <Wayne.Lin@amd.com>
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-4-lyude@redhat.com
Bhawanpreet Lakha [Mon, 25 Oct 2021 22:38:22 +0000 (18:38 -0400)]
drm: Update MST First Link Slot Information Based on Encoding Format
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission starts from
the first slot, with a total of 64 slots available.
v2:
* Move total/start slots to mst_state, and copy it to mst_mgr in
atomic_check
v3:
* Only keep the slot info on the mst_state
* add a start_slot parameter to the payload function, to facilitate non
atomic drivers (this is a temporary workaround and should be removed when
we are moving out the non atomic driver helpers)
v4:
*fixed typo and formatting
v5: (no functional changes)
* Fixed formatting in drm_dp_mst_update_slots()
* Reference mst_state instead of mst_state->mgr for debugging info
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Signed-off-by: Fangzhi Zuo <Jerry.Zuo@amd.com>
[v5 nitpicks]
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-3-lyude@redhat.com
Bhawanpreet Lakha [Mon, 25 Oct 2021 22:38:21 +0000 (18:38 -0400)]
drm: Remove slot checks in dp mst topology during commit
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211025223825.301703-2-lyude@redhat.com
projects / platform / kernel / linux-rpi.git / log