Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update to Linux 5.15 drivers #230

Merged
merged 868 commits into from Feb 16, 2023
Merged

Update to Linux 5.15 drivers #230

merged 868 commits into from Feb 16, 2023

Conversation

dumbbell
Copy link
Member

@dumbbell dumbbell commented Feb 8, 2023 •
edited

This is the backport of the DRM drivers from Linux 5.15.

Progress:

Changes in Linux 5.15

You can read this Phoronix article to learn about the changes in the DRM drivers in Linux 5.15:
https://www.phoronix.com/news/Linux-5.15-DRM-Pull

Patches to linuxkpi

This update depends on the following patches to linuxkpi in FreeBSD:

All patches are merged into main.

How to test

You need to run a recent FreeBSD 14-CURRENT to test it.

Here are some instructions:

  1. You need to checkout the FreeBSD main src branch, and compile a kernel from that branch:

    git clone https://github.com/freebsd/freebsd-src.git
cd freebsd-src
make -j8 buildkernel DEBUG_FLAGS=-g

# This installs the kernel under another name, `kernel.drm`. Thus, you keep the default kernel
# in case of trouble.
sudo make installkernel DEBUG_FLAGS=-g INSTKERNNAME=kernel.drm

  2. You need to checkout the branch referenced in this pull request and compile it:

    git clone -b update-to-v5.15 https://github.com/dumbbell/drm-kmod.git
cd drm-kmod
make -j8 DEBUG_FLAGS=-g
sudo make install DEBUG_FLAGS=-g KMODDIR=/boot/kernel.drm

    This will need access to the FreeBSD src tree cloned above. I don't remember the name of the variable to point the build to it. You can link /usr/src to your clone and it will be enough.

  3. You will need GPU firmwares in the kernel.drm directory as well (drm-kmod-firmware#26). To compile and install them:

    git clone -b drm-5.14 https://github.com/dumbbell/drm-kmod-firmware.git
cd drm-kmod-firmware
make -j8 DEBUG_FLAGS=-g OSVERSION=1400000
sudo make install DEBUG_FLAGS=-g KMODDIR=/boot/kernel.drm OSVERSION=1400000

  4. Load the relevant driver(s) as you usually do.

@dumbbell dumbbell mentioned this pull request Feb 8, 2023
Closed
@dumbbell dumbbell force-pushed the update-to-v5.15 branch 2 times, most recently from 7936e69 to fef2a16 Compare February 10, 2023 15:37
@dumbbell
Copy link
Member Author

The backport is complete. It works fine so far with my Radeon RX 6700 XT. However, the i915 driver is broken. I need to bisect and locate the regression.

@andreaf74
Copy link

The backport is complete. It works fine so far with my Radeon RX 6700 XT. However, the i915 driver is broken. I need to bisect and locate the regression.

It works fine (so far) also with my AMD Radeon RX 6500 XT.

Thanks!

@dumbbell
Copy link
Member Author

I pushed a bug fix to the freebsd-src branch which fixes the i915 driver.

I also pushed updated firmwares to drm-kmod-firmware. This includes the firmwares for Intel Alder Lake. The driver starts to attach to my 12th gen Intel GPU, but crashes in the way with a green screen with nothing on it. Anyway, Alder Lake support is still beta in Linux 5.15.

@dumbbell dumbbell marked this pull request as ready for review February 11, 2023 12:18
@JustAnotherHumanBeing
Copy link

It doesn't seem to me that the i915 driver issue has been fixed. I checked out the latest linuxkpi-updates-for-drm sources, set SYSDIR to those sources, and compiled drm-kmod-5.15. But after loading sway, I experienced a flickering issue on my display. By the way, it wasn't even possible for me to compile the linuxkpi-updates-for-drm kernel because I got a compilation error. So, as I said, I simply compiled v5.15 drm-kmod using the linuxkpi-updates-for-drm sources and after installing it, I loaded i915kms under a kernel from the main branch. I didn't experience problems before loading sway, but as I said, after loading sway, I experienced the flickering issue.

@JustAnotherHumanBeing
Copy link

Oh, never mind. I succeeded in compiling the linuxkpi-updates-for-drm kernel after dealing with that WERROR thing. Under this kernel, I no longer experience any flickering issues. Good work!

@orbitz
Copy link

orbitz commented Feb 11, 2023

I'm unable to build with the following error:

/usr/home/orbitz/projects/drm-kmod/drivers/gpu/drm/drm_auth.c:66:2: error: implicit declaration of function 'lockdep_assert_once' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        lockdep_assert_once(lockdep_is_held(&fpriv->master_lookup_lock) ||
        ^
1 error generated.
*** Error code 1

I think I setup everything correctly...

@JustAnotherHumanBeing
Copy link

I'm unable to build with the following error:

/usr/home/orbitz/projects/drm-kmod/drivers/gpu/drm/drm_auth.c:66:2: error: implicit declaration of function 'lockdep_assert_once' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        lockdep_assert_once(lockdep_is_held(&fpriv->master_lookup_lock) ||
        ^
1 error generated.
*** Error code 1

I think I setup everything correctly...

Are you sure your SYSDIR points to the linuxkpi-updates-for-drm kernel sources?

@orbitz
Copy link

orbitz commented Feb 11, 2023

This was my mistake. I missed a step, but I have corrected it. I'm at the point where it crashes and I get a green screen, like @dumbbell , so I'll take that as a positive step.

@lwhsu
Copy link
Member

lwhsu commented Feb 11, 2023

Works fine on my i7-8550U's UHD Graphics 620. Suspend/resume tested. Thanks!

@dumbbell
Copy link
Member Author

I submitted a pull request for the firmwares update (freebsd/drm-kmod-firmware#26) as well as all freebsd-src patches to Phabricator. The description at the top is updated with this information.

@JustAnotherHumanBeing
Copy link

This was my mistake. I missed a step, but I have corrected it. I'm at the point where it crashes and I get a green screen, like @dumbbell , so I'll take that as a positive step.

What do you mean? Dumbbell no longer gets a green or "nightclub" screen and neither do any of us because as he already mentioned, he corrected the issue.

@dumbbell
Copy link
Member Author

This was my mistake. I missed a step, but I have corrected it. I'm at the point where it crashes and I get a green screen, like @dumbbell , so I'll take that as a positive step.

What do you mean? Dumbbell no longer gets a green or "nightclub" screen and neither do any of us because as he already mentioned, he corrected the issue.

There are/were two different problems:

  1. The one you saw, meaning squares flickering all over the place instead of an application window. This was caused by a limitation in our implementation of Linux XArray in the kernel (linuxkpi). This one is fixed. You had to have a fully support GPU for this to happen.
  2. The green screen is another issue: this is beta support for newer 12th gen Intel GPU. In this Linux 5.15 backport, support for GPUs inside AlderLake-S and -P CPUs is still a work in progress. This was even turned off by default on Linux. The driver is marked as stable in Linux 5.16 for AlderLake-S, and in Linux 5.17 for AlderLake-P.

I have two laptops to test: one with a 9th gen Intel CPU (the one where I experienced the flickering squares) and one with a 12th gen CPU (the one with the green screen). @orbitz must have a 12th gen too.

@JustAnotherHumanBeing
Copy link

This was my mistake. I missed a step, but I have corrected it. I'm at the point where it crashes and I get a green screen, like @dumbbell , so I'll take that as a positive step.

What do you mean? Dumbbell no longer gets a green or "nightclub" screen and neither do any of us because as he already mentioned, he corrected the issue.

There are/were two different problems:

  1. The one you saw, meaning squares flickering all over the place instead of an application window. This was caused by a limitation in our implementation of Linux XArray in the kernel (linuxkpi). This one is fixed. You had to have a fully support GPU for this to happen.
  2. The green screen is another issue: this is beta support for newer 12th gen Intel GPU. In this Linux 5.15 backport, support for GPUs inside AlderLake-S and -P CPUs is still a work in progress. This was even turned off by default on Linux. The driver is marked as stable in Linux 5.16 for AlderLake-S, and in Linux 5.17 for AlderLake-P.

I have two laptops to test: one with a 9th gen Intel CPU (the one where I experienced the flickering squares) and one with a 12th gen CPU (the one with the green screen). @orbitz must have a 12th gen too.

Oh, I see.

@orbitz
Copy link

orbitz commented Feb 12, 2023

@dumbbell Thank you for the great work. Looking forward to testing the next iteration!

@dumbbell dumbbell mentioned this pull request Feb 13, 2023
Merged
@mekanix
Copy link

mekanix commented Feb 14, 2023

On amdgpu based laptop I get black screen after resume. I can ssh to it, but Xorg can not be stopped, not even with killall -9 Xorg. I'll try to bisect and report the offending commit.

@mekanix
Copy link

mekanix commented Feb 15, 2023 •
edited

I didn't bisect this time, as with previous two versions I learned that sometimes bug introduced in one version is fixed in the next, so this time I tested with 5.16 before bisect and my problems with suspend/resume are gone.

@dumbbell
Copy link
Member Author

I didn't bisect this time, as with previous two versions I learned that sometimes bug introduced in one version is fixed in the next, so this time I tested with 5.16 before bisect and my problems with suspend/resume are gone.

@evadot saw the same regression and the same fix in 5.16. Thank you for taking the time to test!

vsbelgaum and others added 6 commits February 15, 2023 23:24
@vsbelgaum @dumbbell
drm/i915/guc/rc: Setup and enable GuCRC feature
f6690a2 
This feature hands over the control of HW RC6 to the GuC.
GuC decides when to put HW into RC6 based on it's internal
busyness algorithms.

GuCRC needs GuC submission to be enabled, and only
supported on Gen12+ for now.

When GuCRC is enabled, do not set HW RC6. Use a H2G message
to tell GuC to enable GuCRC. When disabling RC6, tell GuC to
revert RC6 control back to KMD. KMD is still responsible for
enabling everything related to Coarse Power Gating though.

v2: Address comments (Michal W)
v3: Don't set hysterisis values when GuCRC is used (Matt Roper)
v4: checkpatch()

Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210730202119.23810-15-vinay.belgaumkar@intel.com
@zehortigoza @dumbbell
drm/i915/display/adl_p: Correctly program MBUS DBOX A credits
09b7036 
Alderlake-P have different values for MBUS DBOX A credits depending
if MBUS join is enabled or not.

BSpec: 50343
BSpec: 54369
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210708211827.288601-6-jose.souza@intel.com
@mattrope @dumbbell
drm/i915/dg2: Add forcewake table
e76521a 
The DG2 forcewake table is very similar to the one used by XeHP SDV (and
both platforms are even presented as a single table in the bspec).  For
the most part DG2 starts using a few additional ranges that were
'reserved' on XeHP SDV and stops using some others.  However there is a
single range (0xd800-0xd87f) that needs to be handled differently
between the two platforms (it needs GT wake on XeHP SDV, but render wake
on DG2) so unless we want to wake both domains (which could waste power)
or define new types of forcewake domains for this special case we need
to have separate tables for the two platforms.  Let's define the ranges
for both platforms with a parameterized macro so that we don't actually
need to duplicate everything in the code.

It should be fine for DG2 to re-use the Xe_HP shadow register list so we
can continue to use the 'xehpsdv' MMIO write functions and don't need to
spin up a separate DG2 instance.

Bspec: 66534
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210729170008.2836648-4-matthew.d.roper@intel.com
@matt-auld @dumbbell
drm/i915/xehp: Changes to ss/eu definitions
e58af2d 
Xe_HP no longer has "slices" in the same way that old platforms did.
There are new concepts (gslices, cslices, mslices) that apply in various
contexts, but for the purposes of fusing slices no longer exist and we
just have one large pool of dual-subslices (DSS) to work with.
Furthermore, the meaning of the DSS fuse is inverted compared to past
platforms --- it now specifies which DSS are enabled rather than which
ones are disabled.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Stuart Summers <stuart.summers@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Prasad Nallani <prasad.nallani@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210729170008.2836648-9-matthew.d.roper@intel.com
@mattrope @dumbbell
drm/i915/xehpsdv: Add maximum sseu limits
7b3abbd 
Due to the removal of legacy slices and the transition to a
gslice/cslice/mslice/etc. design, we'll internally store all DSS under
"slice0."

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210729170008.2836648-10-matthew.d.roper@intel.com
@mattrope @dumbbell
drm/i915/dg2: DG2 uses the same sseu limits as XeHP SDV
ff6b469 
DG2 supports compute DSS and has the same maximum number of DSS and EU
as XeHP SDV.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210729170008.2836648-12-matthew.d.roper@intel.com
Hansen and others added 26 commits February 15, 2023 23:25
@dumbbell
drm/amd/display: Fix detection of 4 lane for DPALT
7e37ccd 
[Why]
DPALT detection for B0 PHY has its own set of RDPCSPIPE registers

[How]
Use RDPCSPIPE registers to detect if DPALT lane is 4 lane

Reviewed-by: Charlene Liu <Charlene.Liu@amd.com>
Acked-by: Solomon Chiu <solomon.chiu@amd.com>
Signed-off-by: Hansen <Hansen.Dsouza@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@matt-auld @dumbbell
drm/i915: remember to call i915_sw_fence_fini
c60a467 
Seems to fix some object-debug splat which appeared while debugging
something unrelated.

v2: s/guc_blocked/guc_state.blocked/

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Link: https://patchwork.freedesktop.org/patch/msgid/20210924144646.4096402-1-matthew.auld@intel.com
(cherry picked from commit d576b31bdece7b5034047cbe21170e948198d32f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
@mbrost05 @dumbbell
drm/i915: Fix bug in user proto-context creation that leaked contexts
747dc4e 
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.

v2:
 (Tvrtko)
  - Send as stand alone patch
 (John Harrison)
  - Check for alloc_engines returning NULL
v3:
 (Checkpatch / Tvrtko)
  - Remove braces around single line if statement

Cc: Jason Ekstrand <jason@jlekstrand.net>
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create parameters (v5)")
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211001155825.6762-1-matthew.brost@intel.com
(cherry picked from commit 84edf53776343d6b5bf5fa59a6f600a22ca23c40)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
@dianders @dumbbell
drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks read
4dd2344 
In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid
corruption test") the function connector_bad_edid() started assuming
that the memory for the EDID passed to it was big enough to hold
`edid[0x7e] + 1` blocks of data (1 extra for the base block). It
completely ignored the fact that the function was passed `num_blocks`
which indicated how much memory had been allocated for the EDID.

Let's fix this by adding a bounds check.

This is important for handling the case where there's an error in the
first block of the EDID. In that case we will call
connector_bad_edid() without having re-allocated memory based on
`edid[0x7e]`.

Fixes: e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test")
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeid
Signed-off-by: Dave Airlie <airlied@redhat.com>
@dumbbell
drm/fbdev: Clamp fbdev surface size if too large
0f28ef2 
Clamp the fbdev surface size of the available maximumi height to avoid
failing to init console emulation. An example error is shown below.

  bad framebuffer height 2304, should be >= 768 && <= 768
  [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
  simple-framebuffer simple-framebuffer.0: [drm] *ERROR* fbdev: Failed to setup generic emulation (ret=-22)

This is especially a problem with drivers that have very small screen
sizes and cannot over-allocate at all.

v2:
	* reduce warning level (Ville)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Fixes: 11e8f5fd223b ("drm: Add simpledrm driver")
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reported-by: Amanoel Dawod <kernel@amanoeldawod.com>
Reported-by: Zoltán Kővágó <dirty.ice.hu@gmail.com>
Reported-by: Michael Stapelberg <michael+lkml@stapelberg.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.14+
Link: https://patchwork.freedesktop.org/patch/msgid/20211005070355.7680-1-tzimmermann@suse.de
Signed-off-by: Dave Airlie <airlied@redhat.com>
@zehortigoza @dumbbell
drm/i915: Remove memory frequency calculation
7efe6cb 
This memory frequency calculated is only used to check if it is zero,
what is not useful as it will never actually be zero.

Also the calculation is wrong, we should be checking other bit to
select the appropriate frequency multiplier while this code is stuck
with a fixed multiplier.

So here dropping it as whole.

v2:
- Also remove memory frequency calculation for gen9 LP platforms

Cc: Yakui Zhao <yakui.zhao@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Fixes: 5d0c938ec9cc ("drm/i915/gen11+: Only load DRAM information from pcode")
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211013010046.91858-1-jose.souza@intel.com
(cherry picked from commit 83f52364b15265aec47d07e02b0fbf4093ab8554)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
@docfate111 @dumbbell
drm/amdgpu: fix out of bounds write
7ebf24c 
Size can be any value and is user controlled resulting in overwriting the
40 byte array wr_buf with an arbitrary length of data from buf.

Signed-off-by: Thelford Williams <tdwilliamsiv@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: Limit display scaling to up to true 4k for DCN 3.1
78897a9 
[why]
The requirement is that image width up to 4096 shall be supported

Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Acked-by: Agustin Gutierrez Sanchez <agustin.gutierrez@amd.com>
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: Fix prefetch bandwidth calculation for DCN3.1
a290b11 
[Why]
Prefetch BW calculated is lower than the DML reference because of a
porting error that's excluding cursor and row bandwidth from the
pixel data bandwidth.

[How]
Change the dml_max4 to dml_max3 and include cursor and row bandwidth
in the same calculation as the rest of the pixel data during vactive.

Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Agustin Gutierrez Sanchez <agustin.gutierrez@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: Require immediate flip support for DCN3.1 planes
11c462e 
[Why]
Immediate flip can be enabled dynamically and has higher BW requirements
when validating which voltage mode to use.

If we validate when it's not set then potentially DCFCLK will be too low
and we will underflow.

[How]
DM always requires support so always require it as part of DML input
parameters.

This can't be enabled unconditionally on older ASIC because it blocks
some expected modes so only target DCN3.1 for now.

Reviewed-by: Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com>
Acked-by: Agustin Gutierrez Sanchez <agustin.gutierrez@amd.com>
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: increase Z9 latency to workaround underflow in Z9
f63471c 
[Why]
Z9 latency is higher than when we originally tuned the watermark
parameters, causing underflow. Increasing the value until the latency
issues is resolved.

Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com>
Acked-by: Agustin Gutierrez Sanchez <agustin.gutierrez@amd.com>
Signed-off-by: Eric Yang <Eric.Yang2@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: Increase watermark latencies for DCN3.1
7a00a5e 
[why]
The original latencies were causing underflow in some modes

[how]
Replace with the up-to-date watermark values based on new measurments

Reviewed-by: Ahmad Othman <ahmad.othman@amd.com>
Acked-by: Agustin Gutierrez Sanchez <agustin.gutierrez@amd.com>
Signed-off-by: Nikola Cornij <nikola.cornij@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: Moved dccg init to after bios golden init
9b9c518 
[Why]
bios_golden_init will override dccg_init during init_hw.

[How]
Move dccg_init to after bios_golden_init.

Reviewed-by: Aric Cyr <Aric.Cyr@amd.com>
Reviewed-by: Eric Yang <eric.yang2@amd.com>
Acked-by: Agustin Gutierrez Sanchez <agustin.gutierrez@amd.com>
Signed-off-by: Jake Wang <haonan.wang2@amd.com>
Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@aaliuamd @dumbbell
drm/amdgpu: support B0&B1 external revision id for yellow carp
4daf562 
B0 internal rev_id is 0x01, B1 internal rev_id is 0x02.
The external rev_id for B0 and B1 is 0x20.
The original expression is not suitable for B1.

v2: squash in fix for display code (Alex)

Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@ChristianKoenigAMD @dumbbell
drm/ttm: fix memleak in ttm_transfered_destroy
936e621 
We need to cleanup the fences for ghost objects as well.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reported-by: Erhard F. <erhard_f@mailbox.org>
Tested-by: Erhard F. <erhard_f@mailbox.org>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214029
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214447
CC: <stable@vger.kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211020173211.2247-1-christian.koenig@amd.com
@Susurrus @dumbbell
drm: panel-orientation-quirks: Add quirk for Aya Neo 2021
5d12190 
Fixes screen orientation for the Aya Neo 2021 handheld gaming console.

Signed-off-by: Bryant Mairs <bryant@mai.rs>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019142433.4295-1-bryant@mai.rs
@vsyrjala @dumbbell
drm/i915: Convert unconditional clflush to drm_clflush_virt_range()
09e5b2c 
This one is apparently a "clflush for good measure", so bit more
justification (if you can call it that) than some of the others.
Convert to drm_clflush_virt_range() again so that machines without
clflush will survive the ordeal.

Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thomas Hellström <thomas.hellstrom@intel.com> #v1
Fixes: 12ca695d2c1e ("drm/i915: Do not share hwsp across contexts any more, v8.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014090941.12159-3-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit af7b6d234eefa30c461cc16912bafb32b9e6141c)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
@vsyrjala @dumbbell
drm/i915: Catch yet another unconditioal clflush
3cac381 
Replace the unconditional clflush() with drm_clflush_virt_range()
which does the wbinvd() fallback when clflush is not available.

This time no justification is given for the clflush in the
offending commit.

Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Fixes: 2c8ab3339e39 ("drm/i915: Pin timeline map after first timeline pin, v4.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014090941.12159-4-ville.syrjala@linux.intel.com
Reviewed-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 9ced12182d0d8401d821e9602e56e276459900fc)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
@ideak @dumbbell
drm/i915/dp: Skip the HW readout of DPCD on disabled encoders
2720d28 
Reading out the DP encoders' DPCD during booting or resume is only
required for enabled encoders: such encoders may be modesetted during
the initial commit and the link training this involves depends on an
initialized DPCD. For DDI encoders reading out the DPCD is skipped, do
the same on pre-DDI platforms.

Atm, the first DPCD readout without a sink connected - which is a likely
scneario if the encoder is disabled - leaves intel_dp->num_common_rates
at 0, which resulted in

intel_dp_sync_state()->intel_dp_max_common_rate()

in a

intel_dp->common_rates[-1]

access. This by definition results in an undefined behaviour, though to
my best knowledge in all HW/compiler configurations it actually results
in accessing the array item type value preceding the array. In this
case the preceding value happens to be intel_dp->num_common_rates,
which is 0, so this issue - by luck - didn't cause a user visible
problem.

Nevertheless it's still an undefined behaviour and in CONFIG_UBSAN
builds leads to a kernel BUG() (which revealed this problem for us),
hence CC:stable.

A related problem in case the encoder is enabled but the sink is not
connected or the DPCD readout fails is fixed by the next patch.

v2: Amend the commit message describing the root cause of the
    CONFIG_UBSAN BUG().

Fixes: a532cde31de3 ("drm/i915/tc: Fix TypeC port init/resume time sanitization")
References: https://gitlab.freedesktop.org/drm/intel/-/issues/4297
Reported-and-tested-by: Mat Jonczyk <mat.jonczyk@o2.pl>
Cc: Mat Jonczyk <mat.jonczyk@o2.pl>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-2-imre.deak@intel.com
(cherry picked from commit 4ec5ffc341cecbea060739aea1d53398ac2ec3f8)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
@dumbbell
drm: panel-orientation-quirks: Add quirk for GPD Win3
268ab29 
Fixes screen orientation for GPD Win 3 handheld gaming console.

Signed-off-by: Mario Risoldi <awxkrnl@gmail.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20211026112737.9181-1-awxkrnl@gmail.com
@patjak @dumbbell
drm/amdgpu: Fix even more out of bound writes from debugfs
3c030dc 
CVE-2021-42327 was fixed by:

commit f23750b5b3d98653b31d4469592935ef6364ad67
Author: Thelford Williams <tdwilliamsiv@gmail.com>
Date:   Wed Oct 13 16:04:13 2021 -0400

    drm/amdgpu: fix out of bounds write

but amdgpu_dm_debugfs.c contains more of the same issue so fix the
remaining ones.

v2:
	* Add missing fix in dp_max_bpc_write (Harry Wentland)

Fixes: 918698d5c2b5 ("drm/amd/display: Return the number of bytes parsed than allocated")
Signed-off-by: Patrik Jakobsson <pjakobsson@suse.de>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: Fallback to clocks which meet requested voltage on D…
6d2b07c 
…CN31

[WHY]
On certain configs, SMU clock table voltages don't match which cause parser
to behave incorrectly by leaving dcfclk and socclk table entries unpopulated.

[HOW]
Currently the function that finds the corresponding clock for a given voltage
only checks for exact voltage level matches. In the case that no match gets
found, parser now falls back to searching for the max clock which meets the
requested voltage (i.e. its corresponding voltage is below requested).

Signed-off-by: Michael Strauss <michael.strauss@amd.com>
Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
drm/amd/display: Fix deadlock when falling back to v2 from v3
74331a6 
[Why]
A deadlock in the kernel occurs when we fallback from the V3 to V2
add_topology_to_display or remove_topology_to_display because they
both try to acquire the dtm_mutex but recursive locking isn't
supported on mutex_lock().

[How]
Make the mutex_lock/unlock more fine grained and move them up such that
they're only required for the psp invocation itself.

Fixes: bf62221e9d0e ("drm/amd/display: Add DCN3.1 HDCP support")

Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Aric Cyr <aric.cyr@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
@dumbbell
Reduce diff with Linux 5.15
81a95d3 
Differences were reviewed using e.g.:

    diff -Naur -pX diffignore \
      drm-kmod/drivers/gpu/drm/i915/ \
      linux/drivers/gpu/drm/i915/

Where `diffignore` contains:

    Kconfig
    Kconfig.*
    Makefile

    drm_bridge_connector.h
    drm_fb_cma_helper.h
    drm_gem_atomic_helper.h
    drm_lease.h
    drm_managed.h
    drm_mipi_dbi.h
    drm_mipi_dsi.h
    drm_of.h
    bridge

    amdkfd
    amdgpu_atpx_handler.c
    amdgpu_trace_freebsd.h
    amdgpu_dm_trace_freebsd.h

    i915_trace.h
    i915_trace_points.c
    intel_acpi.c
    intel_freebsd.c
    selftests
    selftest_*.c
    selftest_*.h
    st_shmem_utils.c
@dumbbell
linuxkpi: Fix warning from Clang
54d36fc 
"declaration without a prototype is deprecated in all versions of C clang static inline"
@dumbbell
Silence warning in amdgpu_smu.c
595c686
@evadot evadot merged commit 595c686 into freebsd:master Feb 16, 2023
@dumbbell dumbbell deleted the update-to-v5.15 branch February 16, 2023 18:44
@ghost ghost mentioned this pull request Mar 29, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet