nvidia-340.108 with linux 5.15

[pv4]

The attached patch seems to fix building nvidia-340 driver with linux-5.15.1 on slackware64.

Is this a proper place to send the patch? I've seen https://www.if-not-true-then-false.com/2020/inttf-nvidia-patcher/ which takes patches from https://launchpad.net/~kelebek333/+archive/ubuntu/nvidia-legacy/+packages . But e.g. https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-340/+bug/1916640 references this repository as the source of patches.

1008-fix-5.15.patch.txt

[warpme]

Hi,

Thx for heads-up :-) I have plan to add 5.15 support on x86_64 when o finish aarch64 support (now WiP). Per your request: https://github.com/warpme/minimyth2/commit/a0514fc3e155db2ffe61040a5d2dc73d1e288a40 Thx for collaboration!

[pv4]

Hi.

I have two more MINOR comments/patches relating 1. 5.8+ kernel, 2. building nvidia-uvm module (both for 340.108). Would you like to see them? Should I open separate issues, or can I post them right here?

[warpme]

Oh sure. Pls post them here. I'll include code into current mm2 master

[pv4]

1. mmap_locking_api.patch.txt

The mmap_sem->mmap_lock rename was done in commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/mm_types.h?h=v5.15&id=da1c55f1b272f4bd54671d459b39ea7b54944ef9 .

The link there leads to the change discusson and the change itself: https://lore.kernel.org/all/20200520052908.204642-11-walken@google.com/T/#Z2e.:..:20200520052908.204642-11-walken::40google.com:1include:linux:mm_types.h (scroll to the beginning to see the change discription).

The important quote is

In the future, it may be a starting point for replacing the rwsem implementation with a different one, such as range locks.

So, simple renaming mmap_sem to mmap_lock can cause issues in the future kernel releases if some another locking mechanism is implemented. So a new "mmap locking API" is suggested. The conversion from the old to the new api can be done as simple find-and-replace e.g. (in the same patch series): https://lore.kernel.org/all/20200520052908.204642-11-walken@google.com/T/#Z2e.:..:20200520052908.204642-5-walken::40google.com:1arch:x86:mm:fault.c .

So, at the time of now it's ok to keep 004-fix-5.8.patch as is but it would be better to convert nvidia code to the new api. It's painless (only two lines are modified) and would probably cause less issues in the future.

2. nvidia_uvm.patch.txt

I use slackware64 and nvidia build script from slackbuilds.org which builds nvidia.ko and nvidia-uvm.ko modules. I do NOT know what the second module is for and I'm even not sure I use it at all. Previous version of your patches supported building it (by simple #define mmap_sem mmap_lock) but the newer ones lost this ability (btw why?).

I return the ability to build nvidia-uvm module by modifying 0004-fix-5.8.patch according to the "mmap locking API" changes above (it is now much longer than the previous #define mmap_sem mmap_lock implementation but is trivial to read and verify) and by modifying 0005-fix-5.9.patch to not include linux/ioctl32.h. These changes are applied to files in NVIDIA-Linux-*/kernel/uvm directory.

[warpme]

Many thx for heads-up. I already added fixes in 462edd31 and 255554e5

As finally i got 5.15 working nicely working 5.15 hw.video decode on rpi3/rpi4/amlogic/allwiner/rockchip - i can switch to update kernel to 5.15 on x86_64 (and test our nvidia changes).

update: i just tested on EB1033 (gt218) on 5.15.1 kernel and all seems work nicely :-) thx for your collaboration!

[pv4]

Great, thanks. I personally use (test on) 8600gts :)

Should I close the issue?

[warpme]

Oh yes. please!