drm-kmod
drm-kmod copied to clipboard
Update to Linux v6.6 drivers
Status:
Both Intel and AMD generally works. Tested on SkyLake, TigerLake, AlderLake, AMD780M, 7600M and GreenSardine
What is not done yet:
- Intel DG2 GUC/HUC support. Depends on MEI driver (not ported yet) and PXP
- Intel PXP. Depends on aggregate driver support
- AMD NUMA
- folio support
It is required to specify full path to linuxkpi_video.ko module as it conflicts with system one. This may be done e.g. with addition of following lines to rc.conf:
kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/i915kms.ko"
for i915kms or
kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/amdgpu.ko"
for amdgpu
I think that all the linuxkpi patches are in -CURRENT now ? What's the status of suspend/resume, iirc @emaste said he had problems on a intel laptop with this branch (while it worked with 6.1) ?
I think that all the linuxkpi patches are in -CURRENT now ?
I placed a bunch of remaining patches to phabricator just now. Except pci_iomap_range one which requires reworking to get proper meteorlake+ support.
What's the status of suspend/resume, iirc @emaste said he had problems on a intel laptop with this branch (while it worked with 6.1) ?
I don't know. Both of my S3-capable Intel laptops died recently. It is up to someone else now to bisect 6.6 branch.
I think that all the linuxkpi patches are in -CURRENT now ?
I placed a bunch of remaining patches to phabricator just now. Except pci_iomap_range one which requires reworking to get proper meteorlake+ support.
What's the status of suspend/resume, iirc @emaste said he had problems on a intel laptop with this branch (while it worked with 6.1) ?
I don't know. Both of my S3-capable Intel laptops died recently. It is up to someone else now to bisect 6.6 branch.
Ok thanks for the info, I'll do test/bisect once all the needed lkpi parts are commited then.
How much longer before we can expect these patches to be merged? What would be the goto way to try this right now?
All patches are in phabricator now. I expect them to be committed to current in 2 weeks and than MFC-ed to 14-stable 1 week later
How much longer before we can expect these patches to be merged? What would be the goto way to try this right now?
All patches are merged to CURRENT now. You may test them. Don't forget to add full path to linuxkpi_video.ko module as it conflicts with system one. This may be done e.g. with addition of following lines to rc.conf: kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/i915kms.ko" or kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/amdgpu.ko"
I tried it on a AlderLake system and while the driver can load, I get an error when starting Xorg:
intel(0): intel_uxa_set_pixmap_bo: size of buffer object does not match constraints: size=14680064, must be greater than 13860864, but less than 4194304
See attached logfile Xorg.0.log
My world and kernel is built from freebsd-src on main branch (dirty is just a patch to use a different ethernet driver):
FreeBSD marigold-dvt2 15.0-CURRENT FreeBSD 15.0-CURRENT #3 main-n271308-1cbd613f3343-dirty: Sun Jul 21 20:04:01 UTC 2024 root@marigold-dvt2:/usr/obj/home/zoid/freebsd-src/amd64.amd64/sys/GENERIC-NODEBUG amd64
intel driver does not work on AlderLake. delete xf86-video-intel and use modesetting
I have tested on Meteor Lake (thought it is unstable in v6.6) and it works fine when entering xorg. But there are problems happen at drmfb as the picture shows. (Not because of my bad photographing skill, what it shows is the real phenomena I saw.
What is sysctl hw.intel_graphics_stolen_size
and sysctl hw.intel_graphics_stolen_base
result? Is it non-zero?
All of the value are zeros.
Probably import of stolen area detection code for MeteorLake will fix the problem. It is on base system side rather then on drm-kmod.
I tested it on my AMD Ryzen 9 7950X (https://github.com/freebsd/drm-kmod/issues/305) but unfortunately it's not quite working yet.
Using the Display Port, when I load the driver something apparently works. I don't get any video output after that but the system doesn't hang. I can enter commands and access it via SSH.
When I use the HDMI output it seems to be hanging.
Hmm, I don't find the corresponding quirk in the original Linux kernel source. Maybe it is just unstable. I found intel says Meteor Lake Arc graphic is stable at 6.8.
Tested on my RX550, seems to work fine. Suspend-resume is working fine too.
I'll test on some intel devices next week I think. @wulf7 can you upstream the linuxkpi_video changes to src so we don't have to include this module anymore in drm-kmod ? Thanks
@wulf7 can you upstream the linuxkpi_video changes to src so we don't have to include this module anymore in drm-kmod
See https://reviews.freebsd.org/D46224
@wulf7 can you upstream the linuxkpi_video changes to src so we don't have to include this module anymore in drm-kmod
See https://reviews.freebsd.org/D46224
Thanks. Since we have (or will have) everything needed in base for linuxkpi_video I'm removed the module from the master branch. I've also tested on a few intel machine and didn't have any problems so once you've rebased for the linuxkpi_video conflict feel free to merge this into master and if there is any problems we can work from there instead of this PR.
Thanks again.
I compiled the drm-61-kmod port under FreeBSD CURRENT but I did not set kld_list="/boot/modules/linuxkpi_video.ko /boot/modules/amdgpu.ko" ... I used # sysrc kld_list+=amdgpu instead and I got another kernel panic :(
Is there a way to fix it from this point or should I reinstall FreeBSD? What do you think is the problem?
I bet you forget to install firmwares
Yeah 😅 I thought the port provided them
feel free to merge this into master and if there is any problems we can work from there instead of this PR.
done