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.
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.
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)
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.
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
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.
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
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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: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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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
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
secretmem: Prevent secretmem_users from wrapping to zero
Commit 110860541f44 ("mm/secretmem: use refcount_t instead of atomic_t")
attempted to fix the problem of secretmem_users wrapping to zero and
allowing suspend once again.
But it was reverted in commit 87066fdd2e30 ("Revert 'mm/secretmem: use
refcount_t instead of atomic_t'") because of the problems it caused - a
refcount_t was not semantically the right type to use.
Instead prevent secretmem_users from wrapping to zero by forbidding new
users if the number of users has wrapped from positive to negative.
This stops a long way short of reaching the necessary 4 billion users
where it wraps to zero again, so there's no need to be clever with
special anti-wrap types or checking the return value from atomic_inc().
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Jordy Zomer <jordy@pwning.systems> Cc: Kees Cook <keescook@chromium.org>, Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Mon, 25 Oct 2021 17:46:41 +0000 (10:46 -0700)]
spi: Fix tegra20 build with CONFIG_PM=n once again
Commit efafec27c565 ("spi: Fix tegra20 build with CONFIG_PM=n") already
fixed the build without PM support once. There was an alternative fix
by Guenter in commit 2bab94090b01 ("spi: tegra20-slink: Declare runtime
suspend and resume functions conditionally"), and Mark then merged the
two correctly in ffb1e76f4f32 ("Merge tag 'v5.15-rc2' into spi-5.15").
But for some inexplicable reason, Mark then merged things _again_ in
commit 59c4e190b10c ("Merge tag 'v5.15-rc3' into spi-5.15"), and screwed
things up at that point, and the __maybe_unused attribute on
tegra_slink_runtime_resume() went missing.
Reinstate it, so that alpha (and other architectures without PM support)
builds cleanly again.
Btw, this is another prime example of how random back-merges are not
good. Just don't do them. Subsystem developers should not merge my
tree in any normal circumstances. Both of those merge commits pointed
to above are bad: even the one that got the merge result right doesn't
even mention _why_ it was done, and the one that got it wrong is
obviously broken.
Reported-by: Guenter Roeck <linux@roeck-us.net> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Linus Torvalds [Mon, 25 Oct 2021 16:47:18 +0000 (09:47 -0700)]
Merge tag 'pinctrl-v5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Some late pin control fixes, the most generally annoying will probably
be the AMD IRQ storm fix affecting the Microsoft surface.
Summary:
- Three fixes pertaining to Broadcom DT bindings. Some stuff didn't
work out as inteded, we need to back out
- A resume bug fix in the STM32 driver
- Disable and mask the interrupts on probe in the AMD pinctrl driver,
affecting Microsoft surface"
* tag 'pinctrl-v5.15-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: amd: disable and mask interrupts on probe
pinctrl: stm32: use valid pin identifier in stm32_pinctrl_resume()
Revert "pinctrl: bcm: ns: support updated DT binding as syscon subnode"
dt-bindings: pinctrl: brcm,ns-pinmux: drop unneeded CRU from example
Revert "dt-bindings: pinctrl: bcm4708-pinmux: rework binding to use syscon"
He Ying [Fri, 22 Oct 2021 02:22:43 +0000 (22:22 -0400)]
drm: Small optimization to intel_dp_mst_atomic_master_trans_check
If we want to return from for_each_intel_connector_iter(), one
way is calling drm_connector_list_iter_end() before returning
to avoid memleak. The other way is just breaking from the bracket
and then returning after the outside drm_connector_list_iter_end().
Obviously, the second way makes code smaller and more clear.
Apply it to the function intel_dp_mst_atomic_master_trans_check().
LABBE Corentin [Thu, 21 Oct 2021 09:26:57 +0000 (10:26 +0100)]
ARM: 9148/1: handle CONFIG_CPU_ENDIAN_BE32 in arch/arm/kernel/head.S
My intel-ixp42x-welltech-epbx100 no longer boot since 4.14.
This is due to commit 463dbba4d189 ("ARM: 9104/2: Fix Keystone 2 kernel
mapping regression")
which forgot to handle CONFIG_CPU_ENDIAN_BE32 as possible BE config.
Suggested-by: Krzysztof Hałasa <khalasa@piap.pl> Fixes: 463dbba4d189 ("ARM: 9104/2: Fix Keystone 2 kernel mapping regression") Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Converting the "secretmem_users" counter to a refcount is incorrect,
because a refcount is special in zero and can't just be incremented (but
a count of users is not, and "no users" is actually perfectly valid and
not a sign of a free'd resource).
Reported-by: syzbot+75639e6a0331cd61d3e2@syzkaller.appspotmail.com Cc: Jordy Zomer <jordy@pwning.systems> Cc: Kees Cook <keescook@chromium.org>, Cc: Jordy Zomer <jordy@jordyzomer.github.io> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* tag '5.15-rc6-ksmbd-fixes' of git://git.samba.org/ksmbd:
ksmbd: add buffer validation in session setup
ksmbd: throttle session setup failures to avoid dictionary attacks
ksmbd: validate OutputBufferLength of QUERY_DIR, QUERY_INFO, IOCTL requests
ksmbd: validate credit charge after validating SMB2 PDU body size
ksmbd: add buffer validation for smb direct
ksmbd: limit read/write/trans buffer size not to exceed 8MB
ksmbd: validate compound response buffer
ksmbd: fix potencial 32bit overflow from data area check in smb2_write
ksmbd: improve credits management
ksmbd: add validation in smb2_ioctl
Linus Torvalds [Sun, 24 Oct 2021 16:23:48 +0000 (06:23 -1000)]
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Ten fixes, seven of which are in drivers.
The core fixes are one to fix a potential crash on resume, one to sort
out our reference count releases to avoid releasing in-use modules and
one to adjust the cmd per lun calculation to avoid an overflow in
hyper-v"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: ufs: ufs-pci: Force a full restore after suspend-to-disk
scsi: qla2xxx: Fix unmap of already freed sgl
scsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()
scsi: qla2xxx: Return -ENOMEM if kzalloc() fails
scsi: sd: Fix crashes in sd_resume_runtime()
scsi: mpi3mr: Fix duplicate device entries when scanning through sysfs
scsi: core: Put LLD module refcnt after SCSI device is released
scsi: storvsc: Fix validation for unsolicited incoming packets
scsi: iscsi: Fix set_param() handling
scsi: core: Fix shost->cmd_per_lun calculation in scsi_add_host_with_dma()
projects / kernel.git / log