Update to Linux 6.8 drivers #344
Conversation
|
As of this writing, the |
The blank scrren with i915 goes away for me after changing DIV_ROUND_DOWN_ULL(x, n) to ((unsigned long long)(x) / (n)) |
Hrm, indeed the current Fixes: c4e0746e7d5bd ("LinuxKPI: Add helper macros IS_ALIGNED and DIV_ROUND_DOWN_ULL.") |
From freebsd/drm-kmod#344 (comment) Fixes: c4e0746 ("LinuxKPI: Add helper macros IS_ALIGNED and DIV_ROUND_DOWN_ULL.")
Indeed, looking at the two newly used macros was my next step on Saturday but you beat me to it.
No objections from me! |
|
I referenced this pull request from the change in my WIP testing tree. @lutzbichler if you submit a pull request I'll land that (so that it has proper author attribution), otherwise I'll edit the commit message to add a |
From freebsd/drm-kmod#344 (comment) Fixes: c4e0746 ("LinuxKPI: Add helper macros IS_ALIGNED and DIV_ROUND_DOWN_ULL.")
|
With this applied to my work tree I get a panic, reproduced below. Looking. |
|
I’m running with that fix in my tree since last night and everything is stable so far. Note that I only load the i915 driver, I don’t actually use it most of the time, my external monitors are connected to the AMD GPU, it that makes a difference. I also use ZFS on root FTR. |
|
For better or worse this is trivially reproducible for me -- |
The attempt is here: freebsd/freebsd-src#1612 |
Was just fine and I have landed it already. Thank you for tracking it down! |
|
@dumbbell are you building w/ INVARIANTS? |
|
I observed the panic on Meteor Lake (8086:7dd5 f111:0009). Same image seems to be functional on Tiger Lake (8086:9a49 f111:0001). |
Yes, I’m using a GENERIC kernel. |
|
@aokblast check the patch referenced in #332 (comment), I had similar corruption when testing 6.7 solved by that change |
|
@dumbbell can you add to the instructions the steps for building and installing the firmware? On my test Raptor Lake Dell kldload gets stuck (waiting in |
Good idea, I updated the instructions for both the 6.7 and 6.8 updates. |
@emaste: Is this a new behaviour comparer to 6.7 or before? |
[Why] DMCUB can be in idle when we attempt to interface with the HW through the GPINT mailbox resulting in a system hang. [How] Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep sequence. If the GPINT executes successfully then DMCUB will be put back into sleep after the optional response is returned. It functions similar to the inbox command interface. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Reviewed-by: Hansen Dsouza <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Nicholas Kazlauskas <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
[WHY?] Part of the dc_state interface that deals with adding streams and planes should remain public, while others that deal with internal status' and subvp should be private to DC. [HOW?] Move and rename the public functions to dc_state.h and private functions to dc_state_priv.h. Also add some additional functions for extracting subvp meta data from the state. Reviewed-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
[WHY?] Phantom streams and planes were previously not referenced explcitly on creation. [HOW?] To reduce memory management complexity, add an additional phantom streams and planes reference into dc_state, and move mall_stream_config to stream_status inside the state to make it safe to modify in shallow copies. Also consildates any logic that is affected by this change to dc_state. Reviewed-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Jun Lei <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
[WHY&HOW] Need to provide valid pointer to dc_state when getting subvp pipe type. Reviewed-by: Alvin Lee <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
[WHY&HOW] After refactoring dc_state, it is always constructed at the time of its creation. Construction can only happen after dc resources are initialized, so move creation to be after this. Reviewed-by: George Shen <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
[WHY&HOW] dml2_context should be deep copied from src to dst dc_state. Reviewed-by: George Shen <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Dillon Varone <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
[WHY] Previous fix for multiple displays downstream of DP2 MST hub caused regression [HOW] Match sink IDs instead of sink struct addresses Reviewed-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Charlene Liu <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Michael Strauss <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
[Description] There is a corner case where the symclk otg flag is cleared when disabling the phantom pipe for subvp (because the phantom and main pipe share the same link). This is undesired because we need the maintain the correct symclk otg flag state for the main pipe. For now only clear the flag only for HDMI signal type, since it's only set for HDMI signal type (phantom is virtual). The ideal solution is to not clear it if the stream is phantom but currently there's a bug that doesn't allow us to do this. Once this issue is fixed the proper fix can be implemented. Reviewed-by: Samson Tam <[email protected]> Acked-by: Wayne Lin <[email protected]> Signed-off-by: Alvin Lee <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Likely not a big deal for real users, but for consistency we should respect the min_page_size here. Main issue is that bias allocations turns into normal range allocation if the range and size matches exactly, and in the next patch we want to add some unit tests for this part of the api. Signed-off-by: Matthew Auld <[email protected]> Cc: Arunpravin Paneer Selvam <[email protected]> Cc: Christian König <[email protected]> Reviewed-by: Arunpravin Paneer Selvam <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Christian König <[email protected]>
[WHY] Some eDP panels' ext caps don't write initial values. The value of dpcd_addr (0x317) can be random and the backlight control interface will be incorrect. [HOW] Add new panel patches to remove sink ext caps. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] # 6.5.x Cc: Tsung-hua Lin <[email protected]> Cc: Chris Chi <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Ryan Lin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
Error in mmu_interval_notifier_insert() can leave a NULL
notifier.mm pointer. Catch that and return early.
Fixes: ed29c2691188 ("drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.")
Cc: <[email protected]> # v5.13+
[tursulin: Added Fixes and cc stable.]
Cc: Andi Shyti <[email protected]>
Cc: Shawn Lee <[email protected]>
Signed-off-by: Nirmoy Das <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Tvrtko Ursulin <[email protected]>
(cherry picked from commit db7bbd13f08774cde0332c705f042e327fe21e73)
Signed-off-by: Joonas Lahtinen <[email protected]>
If drm_kms_helper_poll=n the output poll work will only get scheduled from drm_helper_probe_single_connector_modes() to handle a delayed hotplug event. Since polling is disabled the work in this case should just call drm_kms_helper_hotplug_event() w/o detecting the state of connectors and rescheduling the work. After commit d33a54e3991d after a delayed hotplug event above the connectors did get re-detected in the poll work and the work got re-scheduled periodically (since poll_running is also false if drm_kms_helper_poll=n), in effect ignoring the drm_kms_helper_poll=n kernel param. Fix the above by calling only drm_kms_helper_hotplug_event() for a delayed hotplug event if drm_kms_helper_hotplug_event=n, as was done before d33a54e3991d. Cc: Dmitry Baryshkov <[email protected]> Reported-by: Ville Syrjälä <[email protected]> Fixes: d33a54e3991d ("drm/probe_helper: sort out poll_running vs poll_enabled") Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
The icl+ power well code currently assumes that every AUX power
well maps to an encoder which is using said power well. That is
by no menas guaranteed as we:
- only register encoders for ports declared in the VBT
- combo PHY HDMI-only encoder no longer get an AUX CH since
commit 9856308c94ca ("drm/i915: Only populate aux_ch if really needed")
However we have places such as intel_power_domains_sanitize_state()
that blindly traverse all the possible power wells. So these bits
of code may very well encounbter an aux power well with no associated
encoder.
In this particular case the BIOS seems to have left one AUX power
well enabled even though we're dealing with a HDMI only encoder
on a combo PHY. We then proceed to turn off said power well and
explode when we can't find a matching encoder. As a short term fix
we should be able to just skip the PHY related parts of the power
well programming since we know this situation can only happen with
combo PHYs.
Another option might be to go back to always picking an AUX CH for
all encoders. However I'm a bit wary about that since we might in
theory end up conflicting with the VBT AUX CH assignment. Also
that wouldn't help with encoders not declared in the VBT, should
we ever need to poke the corresponding power wells.
Longer term we need to figure out what the actual relationship
is between the PHY vs. AUX CH vs. AUX power well. Currently this
is entirely unclear.
Cc: [email protected]
Fixes: 9856308c94ca ("drm/i915: Only populate aux_ch if really needed")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10184
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Imre Deak <[email protected]>
(cherry picked from commit 6a8c66bf0e565c34ad0a18f820e0bb17951f7f91)
Signed-off-by: Joonas Lahtinen <[email protected]>
The DSC HW state of DP connectors is read out during driver loading and
system resume in intel_modeset_update_connector_atomic_state(). This
function is called for all connectors though and so the state of DSI
connectors will also get updated incorrectly, triggering a WARN there
wrt. the DSC decompression AUX device.
Fix the above by moving the DSC state readout to a new DP connector
specific sync_state() hook. This is anyway the logical place to update
the connector object's state vs. the connector's atomic state.
Fixes: b2608c6b3212 ("drm/i915/dp_mst: Enable MST DSC decompression for all streams")
Reported-and-tested-by: Drew Davenport <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]
Reviewed-by: Ankit Nautiyal <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit a62e145981500996ea76af3d740ce0c0d74c5be0)
Signed-off-by: Joonas Lahtinen <[email protected]>
Move psr_init_dpcd() from init-connector to connector-detect function. The dpcd probe for checking panel replay capability for external dp connector is causing delay during boot which can be optimized by moving dpcd probe to connector specific detect(). v1: Initial version. v2: Add details in commit description. [Jani] Suggested-by: Ville Syrjälä <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10284 Signed-off-by: Animesh Manna <[email protected]> Fixes: cceeaa312d39 ("drm/i915/panelreplay: Enable panel replay dpcd initialization for DP") Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1cca19bf296fae0636a637b48d195ac6b4d430c9) Signed-off-by: Joonas Lahtinen <[email protected]>
Add an if condition for gfx activity because the scaling has been changed after smu fw version 5d4600. And remove a warning log. Signed-off-by: Li Ma <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.7.x
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6683 amdgpu_dm_connector_funcs_force()
warn: variable dereferenced before check 'dc_link' (see line 6663)
Fixes: 967176179215 ("drm/amd/display: fix null-pointer dereference on edid reading")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Melissa Wen <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Need to check the offset bits for values greater than 255. v2: also update amdgpu_dm_connector values. Suggested-by: Mano Ségransan <[email protected]> Tested-by: Mano Ségransan <[email protected]> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3203 Reviewed-by: Harry Wentland <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
Fix the pwm_mode value error which used for pwm1_enable setting Signed-off-by: Ma Jun <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
Differences were reviewed using e.g.:
diff -Nau -pX scripts/diffignore \
drm-kmod/drivers/gpu/drm/ \
linux/drivers/gpu/drm/
diff -Naur -pX scripts/diffignore \
drm-kmod/drivers/gpu/drm/amd/amdgpu/ \
linux/drivers/gpu/drm/amd/amdgpu/
diff -Naur -pX scripts/diffignore \
drm-kmod/drivers/gpu/drm/i915/ \
linux/drivers/gpu/drm/i915/
diff -Naur -pX scripts/diffignore \
drm-kmod/include/drm/ \
linux/include/drm/
dumbbell
force-pushed
the
update-to-linux-6.8
branch
from
18b3846 to
b3074b8
Compare
Tried it. The screen is teared without firmware. With firmware, the screen goes blank. |
|
I am try this on ThinkBook 14 G6+ IM after try kldload i915kms I am got dmesg and kldload stuck on |
|
no luck: blank screen or crash. kldload stuck: in dmesg: Config: ( CPU Hyper-threading: off ) |
helps, but there is no acceleration |
I believe I saw this with 6.7 on this machine as well, but will have to double-check. |
|
I haven't been able to reproduce the panic again. I do have an interesting update on the corruption (on |
I think I may have confused myself about the issues that appeared on various machines. The Dell laptop (Raptor Lake) has the video corruption and no panic. The Framework Core Ultra (Meteor Lake) is the one that panicked, and still does. |
|
I'm now running this on my daily driver, with I saw corruption like @aokblast reported when first starting X, but it stopped after switching to vty0 and back and it has been "fine" since. |
|
hw.i915kms.enable_guc=0 and kldload i915kms got a panic. core.txt attached |
|
@slw I saw that panic ( |
yes, this Meteor Lake too |
I'm pretty sure that GuC is mandatory for this GPU. |
enable_guc=3 core attached |
|
Noting all patches are now struckout as complete, does this mean https://github.com/freebsd/freebsd-src main can now be used as apposed to the drm-related-linuxkpi-changes branch of dumbell's repo? |
No, because freebsd-src patches for DRM in Linux 6.7 are still being reviewed and improved (see #332). This pull request depends on them too. |
|
With 6.6 crashing sometimes multiple times daily due to (#333) and hence failing the WIFE factor. I decided to give 6.8 a try, results so far are pretty good. This box is a daily media server, inet router and mythtv frontend using vaapi and opengl. I'm running: on Alderlake hardware: I do get the corrupted color space issue that emaste had in #332 (comment)_ but not at boot. Vt is clean, Xorg starts, the colorspace becomes corrupted. Switching to VT, colorspace is still broken, switch back to Xorg it's initially corrupt then restores correctly. Crash was:
So far seems very stable - nice work! |
This is the backport of the DRM drivers from Linux 6.8.
Progress:
Changes in Linux 6.8
You can read this Phoronix article to learn about the changes in the DRM drivers in Linux 6.8:
https://www.phoronix.com/news/Linux-6.8-DRM
Patches to linuxkpi
This update depends on the following patches to linuxkpi in FreeBSD.
These patches are maintained in the following repository and branch:
https://github.com/dumbbell/freebsd-src/tree/drm-related-linuxkpi-changes
Patches were submitted for review:
https://reviews.freebsd.org/D49067https://reviews.freebsd.org/D49068https://reviews.freebsd.org/D49069https://reviews.freebsd.org/D49374https://reviews.freebsd.org/D49375https://reviews.freebsd.org/D49376https://reviews.freebsd.org/D49377https://reviews.freebsd.org/D49378https://reviews.freebsd.org/D49379https://reviews.freebsd.org/D49380https://reviews.freebsd.org/D49381(superseded byhttps://reviews.freebsd.org/D49637)https://reviews.freebsd.org/D49382https://reviews.freebsd.org/D49383https://reviews.freebsd.org/D49384https://reviews.freebsd.org/D49385https://reviews.freebsd.org/D49386https://reviews.freebsd.org/D49387https://reviews.freebsd.org/D49388Firmware updates
There is an associated firmware update:
How to test
You need to run a recent FreeBSD 15-CURRENT to test it.
Here are some instructions:
You need to checkout the FreeBSD src branch I mentionned,
drm-related-linuxkpi-changes, and compile a kernel from that branch:You need to checkout the branch referenced in this pull request and compile it:
You need to checkout the drm-kmod-firmware associated update and compile the firmwares (yes, this is the same firmware update as for the Linux 6.7 update):
Load the relevant driver(s) as you usually do.