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
Linus Torvalds [Mon, 25 Oct 2021 18:30:31 +0000 (11:30 -0700)]
Linux 5.15-rc7
Matthew Wilcox (Oracle) [Mon, 25 Oct 2021 18:16:34 +0000 (19:16 +0100)]
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 17:28:52 +0000 (10:28 -0700)]
Merge tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm
Pull ARM fixes from Russell King:
- Fix clang-related relocation warning in futex code
- Fix incorrect use of get_kernel_nofault()
- Fix bad code generation in __get_user_check() when kasan is enabled
- Ensure TLB function table is correctly aligned
- Remove duplicated string function definitions in decompressor
- Fix link-time orphan section warnings
- Fix old-style function prototype for arch_init_kprobes()
- Only warn about XIP address when not compile testing
- Handle BE32 big endian for keystone2 remapping
* tag 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: 9148/1: handle CONFIG_CPU_ENDIAN_BE32 in arch/arm/kernel/head.S
ARM: 9141/1: only warn about XIP address when not compile testing
ARM: 9139/1: kprobes: fix arch_init_kprobes() prototype
ARM: 9138/1: fix link warning with XIP + frame-pointer
ARM: 9134/1: remove duplicate memcpy() definition
ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B aligned
ARM: 9132/1: Fix __get_user_check failure with ARM KASAN images
ARM: 9125/1: fix incorrect use of get_kernel_nofault()
ARM: 9122/1: select HAVE_FUTEX_CMPXCHG
Linus Torvalds [Mon, 25 Oct 2021 16:57:28 +0000 (09:57 -0700)]
Merge tag 'libata-5.15-rc7' of git://git./linux/kernel/git/dlemoal/libata
Pull libata fix from Damien Le Moal:
"A single fix in this pull request addressing an invalid error code
return in the sata_mv driver (from Zheyu)"
* tag 'libata-5.15-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata:
ata: sata_mv: Fix the error handling of mv_chip_id()
Linus Torvalds [Mon, 25 Oct 2021 16:47:18 +0000 (09:47 -0700)]
Merge tag 'pinctrl-v5.15-3' of git://git./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().
Signed-off-by: He Ying <heying24@huawei.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211022022243.138860-1-heying24@huawei.com
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>
Zheyu Ma [Fri, 22 Oct 2021 09:12:26 +0000 (09:12 +0000)]
ata: sata_mv: Fix the error handling of mv_chip_id()
mv_init_host() propagates the value returned by mv_chip_id() which in turn
gets propagated by mv_pci_init_one() and hits local_pci_probe().
During the process of driver probing, the probe function should return < 0
for failure, otherwise, the kernel will treat value > 0 as success.
Since this is a bug rather than a recoverable runtime error we should
use dev_alert() instead of dev_err().
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Linus Torvalds [Sun, 24 Oct 2021 19:48:33 +0000 (09:48 -1000)]
Revert "mm/secretmem: use refcount_t instead of atomic_t"
This reverts commit
110860541f443f950c1274f217a1a3e298670a33.
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>
Linus Torvalds [Sun, 24 Oct 2021 19:36:06 +0000 (09:36 -1000)]
Merge branch 'fixes' of git://git./linux/kernel/git/viro/vfs
Pull autofs fix from Al Viro:
"Fix for a braino of mine (in getting rid of open-coded
dentry_path_raw() in autofs a couple of cycles ago).
Mea culpa... Obvious -stable fodder"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
autofs: fix wait name hash calculation in autofs_wait()
Linus Torvalds [Sun, 24 Oct 2021 17:04:21 +0000 (07:04 -1000)]
Merge tag 'sched_urgent_for_v5.15_rc7' of git://git./linux/kernel/git/tip/tip
Pull scheduler fix from Borislav Petkov:
"Reset clang's Shadow Call Stack on hotplug to prevent it from
overflowing"
* tag 'sched_urgent_for_v5.15_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/scs: Reset the shadow stack when idle_task_exit
Linus Torvalds [Sun, 24 Oct 2021 17:00:15 +0000 (07:00 -1000)]
Merge tag 'x86_urgent_for_v5.15_rc7' of git://git./linux/kernel/git/tip/tip
Pull x86 fix from Borislav Petkov:
"A single change adding Dave Hansen to our maintainers team"
* tag 'x86_urgent_for_v5.15_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
MAINTAINERS: Add Dave Hansen to the x86 maintainer team
Linus Torvalds [Sun, 24 Oct 2021 16:43:59 +0000 (06:43 -1000)]
Merge tag '5.15-rc6-ksmbd-fixes' of git://git.samba.org/ksmbd
Pull ksmbd fixes from Steve French:
"Ten fixes for the ksmbd kernel server, for improved security and
additional buffer overflow checks:
- a security improvement to session establishment to reduce the
possibility of dictionary attacks
- fix to ensure that maximum i/o size negotiated in the protocol is
not less than 64K and not more than 8MB to better match expected
behavior
- fix for crediting (flow control) important to properly verify that
sufficient credits are available for the requested operation
- seven additional buffer overflow, buffer validation checks"
* 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./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()
Rob Clark [Sat, 23 Oct 2021 16:00:13 +0000 (09:00 -0700)]
drm/msm/dpu: Remove dynamic allocation from atomic context
We know the upper bound on # of mixers (ie. two), so lets just allocate
this on the stack.
Fixes:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:201
in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 0, name: swapper/0
INFO: lockdep is turned off.
irq event stamp: 43642
hardirqs last enabled at (43641): [<
ffffffe24dd276bc>] cpuidle_enter_state+0x158/0x25c
hardirqs last disabled at (43642): [<
ffffffe24dfff450>] enter_el1_irq_or_nmi+0x10/0x1c
softirqs last enabled at (43620): [<
ffffffe24d4103fc>] __do_softirq+0x1e4/0x464
softirqs last disabled at (43615): [<
ffffffe24d48bd90>] __irq_exit_rcu+0x104/0x150
CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.15.0-rc3-debug+ #105
Hardware name: Google Lazor (rev1 - 2) with LTE (DT)
Call trace:
dump_backtrace+0x0/0x18c
show_stack+0x24/0x30
dump_stack_lvl+0xa0/0xd4
dump_stack+0x18/0x34
___might_sleep+0x1e0/0x1f0
__might_sleep+0x78/0x8c
slab_pre_alloc_hook.constprop.0+0x48/0x6c
__kmalloc+0xc8/0x21c
dpu_crtc_vblank_callback+0x158/0x1f8
dpu_encoder_vblank_callback+0x70/0xc4
dpu_encoder_phys_vid_vblank_irq+0x50/0x12c
dpu_core_irq+0x1bc/0x1d0
dpu_irq+0x1c/0x28
msm_irq+0x34/0x40
__handle_irq_event_percpu+0x15c/0x308
handle_irq_event_percpu+0x3c/0x90
handle_irq_event+0x54/0x98
handle_level_irq+0xa0/0xd0
handle_irq_desc+0x2c/0x44
generic_handle_domain_irq+0x28/0x34
dpu_mdss_irq+0x90/0xe8
handle_irq_desc+0x2c/0x44
handle_domain_irq+0x54/0x80
gic_handle_irq+0xd4/0x148
call_on_irq_stack+0x2c/0x54
do_interrupt_handler+0x4c/0x64
el1_interrupt+0x30/0xd0
el1h_64_irq_handler+0x18/0x24
el1h_64_irq+0x78/0x7c
arch_local_irq_enable+0xc/0x14
cpuidle_enter+0x44/0x5c
do_idle+0x248/0x268
cpu_startup_entry+0x30/0x48
rest_init+0x188/0x19c
arch_call_rest_init+0x1c/0x28
start_kernel+0x704/0x744
__primary_switched+0xc0/0xc8
Fixes:
78d9b458cc21 ("drm/msm/dpu: Add CRC support for DPU")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Link: https://lore.kernel.org/r/20211023160016.3322052-2-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Rob Clark [Sat, 23 Oct 2021 16:00:12 +0000 (09:00 -0700)]
drm/msm/dpu: Remove impossible NULL check
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Jessica Zhang <jesszhan@codeaurora.org>
Link: https://lore.kernel.org/r/20211023160016.3322052-1-robdclark@gmail.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
Linus Torvalds [Sat, 23 Oct 2021 03:42:13 +0000 (17:42 -1000)]
Merge tag 'block-5.15-2021-10-22' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Fix for the cgroup code not ussing irq safe stats updates, and one fix
for an error handling condition in add_partition()"
* tag 'block-5.15-2021-10-22' of git://git.kernel.dk/linux-block:
block: fix incorrect references to disk objects
blk-cgroup: blk_cgroup_bio_start() should use irq-safe operations on blkg->iostat_cpu
Linus Torvalds [Sat, 23 Oct 2021 03:34:31 +0000 (17:34 -1000)]
Merge tag 'io_uring-5.15-2021-10-22' of git://git.kernel.dk/linux-block
Pull io_uring fixes from Jens Axboe:
"Two fixes for the max workers limit API that was introduced this
series: one fix for an issue with that code, and one fixing a linked
timeout regression in this series"
* tag 'io_uring-5.15-2021-10-22' of git://git.kernel.dk/linux-block:
io_uring: apply worker limits to previous users
io_uring: fix ltimeout unprep
io_uring: apply max_workers limit to all future users
io-wq: max_worker fixes
Linus Torvalds [Fri, 22 Oct 2021 20:39:47 +0000 (10:39 -1000)]
Merge tag 'fuse-fixes-5.15-rc7' of git://git./linux/kernel/git/mszeredi/fuse
Pull fuse fixes from Miklos Szeredi:
"Syzbot discovered a race in case of reusing the fuse sb (introduced in
this cycle).
Fix it by doing the s_fs_info initialization at the proper place"
* tag 'fuse-fixes-5.15-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
fuse: clean up error exits in fuse_fill_super()
fuse: always initialize sb->s_fs_info
fuse: clean up fuse_mount destruction
fuse: get rid of fuse_put_super()
fuse: check s_root when destroying sb
Linus Torvalds [Fri, 22 Oct 2021 20:31:32 +0000 (10:31 -1000)]
Merge tag 'hyperv-fixes-signed-
20211022' of git://git./linux/kernel/git/hyperv/linux
Pull hyper-v fix from Wei Liu:
- Fix vmbus ARM64 build (Arnd Bergmann)
* tag 'hyperv-fixes-signed-
20211022' of git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux:
hyperv/vmbus: include linux/bitops.h
Arnd Bergmann [Mon, 18 Oct 2021 13:19:08 +0000 (15:19 +0200)]
hyperv/vmbus: include linux/bitops.h
On arm64 randconfig builds, hyperv sometimes fails with this
error:
In file included from drivers/hv/hv_trace.c:3:
In file included from drivers/hv/hyperv_vmbus.h:16:
In file included from arch/arm64/include/asm/sync_bitops.h:5:
arch/arm64/include/asm/bitops.h:11:2: error: only <linux/bitops.h> can be included directly
In file included from include/asm-generic/bitops/hweight.h:5:
include/asm-generic/bitops/arch_hweight.h:9:9: error: implicit declaration of function '__sw_hweight32' [-Werror,-Wimplicit-function-declaration]
include/asm-generic/bitops/atomic.h:17:7: error: implicit declaration of function 'BIT_WORD' [-Werror,-Wimplicit-function-declaration]
Include the correct header first.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20211018131929.2260087-1-arnd@kernel.org
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Linus Torvalds [Fri, 22 Oct 2021 19:08:08 +0000 (09:08 -1000)]
Merge tag 'acpi-5.15-rc7' of git://git./linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix two regressions, one related to ACPI power resources
management and one that broke ACPI tools compilation.
Specifics:
- Stop turning off unused ACPI power resources in an unknown state to
address a regression introduced during the 5.14 cycle (Rafael
Wysocki).
- Fix an ACPI tools build issue introduced recently when the minimal
stdarg.h was added (Miguel Bernal Marin)"
* tag 'acpi-5.15-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: PM: Do not turn off power resources in unknown state
ACPI: tools: fix compilation error
Linus Torvalds [Fri, 22 Oct 2021 19:02:15 +0000 (09:02 -1000)]
Merge tag 'for-linus' of git://git./virt/kvm/kvm
Pull more x86 kvm fixes from Paolo Bonzini:
- Cache coherency fix for SEV live migration
- Fix for instruction emulation with PKU
- fixes for rare delaying of interrupt delivery
- fix for SEV-ES buffer overflow
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: SEV-ES: go over the sev_pio_data buffer in multiple passes if needed
KVM: SEV-ES: keep INS functions together
KVM: x86: remove unnecessary arguments from complete_emulator_pio_in
KVM: x86: split the two parts of emulator_pio_in
KVM: SEV-ES: clean up kvm_sev_es_ins/outs
KVM: x86: leave vcpu->arch.pio.count alone in emulator_pio_in_out
KVM: SEV-ES: rename guest_ins_data to sev_pio_data
KVM: SEV: Flush cache on non-coherent systems before RECEIVE_UPDATE_DATA
KVM: MMU: Reset mmu->pkru_mask to avoid stale data
KVM: nVMX: promptly process interrupts delivered while in guest mode
KVM: x86: check for interrupts before deciding whether to exit the fast path
Rafael J. Wysocki [Fri, 22 Oct 2021 18:45:10 +0000 (20:45 +0200)]
Merge branch 'acpi-tools'
Merge a fix for a recent ACPI tools bild regresson.
* acpi-tools:
ACPI: tools: fix compilation error
Simon Ser [Thu, 14 Oct 2021 15:35:13 +0000 (15:35 +0000)]
amd/display: remove ChromeOS workaround
This reverts commits
ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication
when using overlay") and
e7d9560aeae5 ("Revert "drm/amd/display: Fix overlay
validation by considering cursors"").
tl;dr ChromeOS uses the atomic interface for everything except the cursor. This
is incorrect and forces amdgpu to disable some hardware features. Let's revert
the ChromeOS-specific workaround in mainline and allow the Chrome team to keep
it internally in their own tree.
See [1] for more details. This patch is an alternative to [2], which added
ChromeOS detection.
[1]: https://lore.kernel.org/amd-gfx/JIQ_93_cHcshiIDsrMU1huBzx9P9LVQxucx8hQArpQu7Wk5DrCl_vTXj_Q20m_L-8C8A5dSpNcSJ8ehfcCrsQpfB5QG_Spn14EYkH9chtg0=@emersion.fr/
[2]: https://lore.kernel.org/amd-gfx/
20211011151609.452132-1-contact@emersion.fr/
Signed-off-by: Simon Ser <contact@emersion.fr>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Sean Paul <seanpaul@chromium.org>
Fixes:
ddab8bd788f5 ("drm/amd/display: Fix two cursor duplication when using overlay")
Fixes:
e7d9560aeae5 ("Revert "drm/amd/display: Fix overlay validation by considering cursors"")
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Lijo Lazar [Fri, 22 Oct 2021 07:35:25 +0000 (15:35 +0800)]
drm/amd/pm: Disable fan control if not supported
On arcturus, not all platforms use PMFW based fan control. On such
ASICs fan control by PMFW will be disabled in PPTable. Disable hwmon
knobs for fan control also as it is not possible to report or control
fan speed on such platforms through driver.
Signed-off-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Fri, 22 Oct 2021 04:14:11 +0000 (00:14 -0400)]
drm/amdgpu/nbio7.4: use original HDP_FLUSH bits
The extended bits were not available for use on vega20 and
presumably arcturus as well.
Fixes:
a0f9f854666834 ("drm/amdgpu/nbio7.4: don't use GPU_HDP_FLUSH bit 12")
Reviewed-and-tested-by: Guchun Chen <guchun.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Alex Deucher [Tue, 19 Oct 2021 15:28:18 +0000 (11:28 -0400)]
drm/amdgpu/smu11.0: add missing IP version check
Add missing check in smu_v11_0_init_display_count(),
Fixes:
af3b89d3a639d5 ("drm/amdgpu/smu11.0: convert to IP version checking")
Reviewed-by: Guchun Chen <guchun.chen@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Paolo Bonzini [Tue, 12 Oct 2021 15:33:03 +0000 (11:33 -0400)]
KVM: SEV-ES: go over the sev_pio_data buffer in multiple passes if needed
The PIO scratch buffer is larger than a single page, and therefore
it is not possible to copy it in a single step to vcpu->arch/pio_data.
Bound each call to emulator_pio_in/out to a single page; keep
track of how many I/O operations are left in vcpu->arch.sev_pio_count,
so that the operation can be restarted in the complete_userspace_io
callback.
For OUT, this means that the previous kvm_sev_es_outs implementation
becomes an iterator of the loop, and we can consume the sev_pio_data
buffer before leaving to userspace.
For IN, instead, consuming the buffer and decreasing sev_pio_count
is always done in the complete_userspace_io callback, because that
is when the memcpy is done into sev_pio_data.
Cc: stable@vger.kernel.org
Fixes:
7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest")
Reported-by: Felix Wilhelm <fwilhelm@google.com>
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 12 Oct 2021 15:25:45 +0000 (11:25 -0400)]
KVM: SEV-ES: keep INS functions together
Make the diff a little nicer when we actually get to fixing
the bug. No functional change intended.
Cc: stable@vger.kernel.org
Fixes:
7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest")
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 12 Oct 2021 16:35:20 +0000 (12:35 -0400)]
KVM: x86: remove unnecessary arguments from complete_emulator_pio_in
complete_emulator_pio_in can expect that vcpu->arch.pio has been filled in,
and therefore does not need the size and count arguments. This makes things
nicer when the function is called directly from a complete_userspace_io
callback.
No functional change intended.
Cc: stable@vger.kernel.org
Fixes:
7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest")
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 13 Oct 2021 16:32:02 +0000 (12:32 -0400)]
KVM: x86: split the two parts of emulator_pio_in
emulator_pio_in handles both the case where the data is pending in
vcpu->arch.pio.count, and the case where I/O has to be done via either
an in-kernel device or a userspace exit. For SEV-ES we would like
to split these, to identify clearly the moment at which the
sev_pio_data is consumed. To this end, create two different
functions: __emulator_pio_in fills in vcpu->arch.pio.count, while
complete_emulator_pio_in clears it and releases vcpu->arch.pio.data.
Because this patch has to be backported, things are left a bit messy.
kernel_pio() operates on vcpu->arch.pio, which leads to emulator_pio_in()
having with two calls to complete_emulator_pio_in(). It will be fixed
in the next release.
While at it, remove the unused void* val argument of emulator_pio_in_out.
The function currently hardcodes vcpu->arch.pio_data as the
source/destination buffer, which sucks but will be fixed after the more
severe SEV-ES buffer overflow.
No functional change intended.
Cc: stable@vger.kernel.org
Fixes:
7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest")
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Tue, 12 Oct 2021 14:51:55 +0000 (10:51 -0400)]
KVM: SEV-ES: clean up kvm_sev_es_ins/outs
A few very small cleanups to the functions, smushed together because
the patch is already very small like this:
- inline emulator_pio_in_emulated and emulator_pio_out_emulated,
since we already have the vCPU
- remove the data argument and pull setting vcpu->arch.sev_pio_data into
the caller
- remove unnecessary clearing of vcpu->arch.pio.count when
emulation is done by the kernel (and therefore vcpu->arch.pio.count
is already clear on exit from emulator_pio_in and emulator_pio_out).
No functional change intended.
Cc: stable@vger.kernel.org
Fixes:
7ed9abfe8e9f ("KVM: SVM: Support string IO operations for an SEV-ES guest")
Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
projects / platform / kernel / linux-starfive.git / log