SP11: fix volume-down replay and preserve 7.2.2 GPI/SPI behavior

[ooaklee]

Summary

Follow-up to the review of #79:

• remove the obsolete &pon_resin override retained by the integration replay
• restore the DMA_PRIVATE capability in gpi.c
• restore the existing GENI SPI tracepoints while retaining the SP11 paired-QSPI implementation
• advance the staging package ABI to 0sp11v21 so the corrected test kernel can coexist with v20

Scope

This PR deliberately targets the existing -sp11 staging branch so it can serve as a consistent, testable SP11 reference. It is not intended to be applied wholesale to the shared release line. Mergeable pieces can be recreated as separate topic branches from jg/ubuntu-qcom-x1e-7.2.y, with shared-driver changes gated to microsoft,denali where needed.

This validation applies to the exact head of this PR. It does not make a qualification claim for the separate USB4 topic branches or PRs.

QSPI re-evaluation

The large driver diff in the replay initially looked like two stale complete files. A blob-level comparison showed that the phase55 preimages are byte-for-byte identical to the current 7.2.2 release-line driver blobs. The large diff is a consequence of replay order: the compact x1e-nixos QSPI implementation was applied first, then replaced by the different SP11 phase55 implementation.

Moving back to the compact path here would discard the paired TX/RX and event-completion behaviour used by the MSHW0485 path. This correction therefore retains the phase55 behaviour and restores only the two verified baseline regressions above. A clean QSPI topic split can be rebuilt from the release branch separately.

Validation

Validated at exact head 116cef4df36a03c1f81056521fdd7f1aa11ee347 (tree e00cbc28407c8e2279ab1722817becf521020f3c):

• scripts/checkpatch.pl --strict --git 4768136761aa..HEAD: no warnings or errors
• git diff --check 4768136761aa..HEAD
• ARM64 ubuntu_x1e_defconfig
• ARM64 W=1 builds of drivers/dma/qcom/gpi.o and drivers/spi/spi-geni-qcom.o
• ARM64 builds of qcom/x1e80100-microsoft-denali-oled.dtb and qcom/x1p64100-microsoft-denali.dtb
• clean full ARM64 v21 Debian package build with Lexr and no incremental reuse
• all recorded SHA-256 checks passed for the signed image, modules, ABI headers, and common headers
• Debian metadata confirms matching ABI/version/architecture and the ABI-header dependency on the common-header package
• both supported SP11 DTBs are present in the modules package
• the corrected Stubble-wrapped v21 image is 22,877,184 bytes and contains one .linux, one .hwids, 39 .dtbauto sections, and one exact embedded match for the packaged Denali OLED DTB
• all four packages were installed together; both DTBs and both installed header trees were verified, with 7.2.0-jg-0sp11v19-qcom-x1e retained as fallback
• the machine rebooted successfully into 7.2.2-jg-0sp11v21-qcom-x1e
• boot logs show SP11: QSPI using GPI DMA descriptor mode, the expected paired DMA sync mapping, touchscreen controller initialization, the IPTS HIDRAW bridge, and the IPTSD virtual stylus
• the user confirms the changes on this PR branch are working and good to go on Surface Pro 11 hardware

The earlier v21 black-screen/restart was traced to a raw, non-Stubble EFI image produced by the build path, not to this kernel head. The corrected build and installation policy is tracked in ooaklee/lexr.sh#6.

[jglathe]

Small change. These fixes are on top of the -sp11 branch (they would wreak havoc on 7.2.y alone). For the mergeable parts the partial PR needs to be based on 7.2.y. Why: The -sp11 branch is "working, but dirty" code. It isn't very different (although much more scrutiny) when upstreaming.

[ooaklee]

I was targeting these small corrections to the existing -sp11 staging branch so that we first have a consistent SP11 reference.

Then, once I can test -sp11 with these changes, I’ll recreate the mergeable pieces as separate topic branches to jg/ubuntu-qcom-x1e-7.2.y, with changes to shared drivers gated against microsoft,denali compatibility where needed.

I won’t carry this OR #81 wholesale onto the shared release line.

Are you saying that I shouldn't even attempt to introduce them in -sp11 at all? Sorry, I don't want to break anything

[jglathe]

No, all good. This is the right way, -sp11 is specifically there for this purpose to evolve the working code branch. May I ask how much energy you're putting in there? I mean, I am old an crazy, but this is quite the pace you are going.

[ooaklee]

May I ask how much energy you're putting in there?

Quite a bit, lol. I really just want to get it sorted and make it easier for the next Surface Pro 11 users to install Linux on their machines. Before I made a breakthrough and worked with you and the other guys, it was painful.

It also really annoyed me that people shared videos last month and earlier of Linux working (almost perfectly) on their SP11 but didn't want to share how they got it working, so yeah... I want to make this upstream (or at least accessible) and make it as easy as possible for others to get started with Linux on their SP11 and eventually Snapdragon X1E devices (which is why I am also working on https://github.com/ooaklee/lexr.sh).

With lexr, it brings together the work you're doing here and countless conversations about setting up images to work with X1E devices and making it as easy as possible to test different distros. It's still WIP, but I will give you access so you can look around and share your thoughts.

It makes it especially easy for people in the Ubuntu community who just want to be able to run one or a couple of commands and get their systems up to date with the latest kernel/fixes from you, me or selected repos live on their systems

[jglathe]

This is the way. I personally don't have the Surface Pro's, "only" 2x Windows Dev Kit 2023. One was the reason to take up this hobby, and the second one was testbed for the EL2 mode, and other things I didn't want to do with my daily driver. Only 3 years later, its a big zoo of x1 laptops (and an x13s), and desktops/devkits. Motto: Getting Shite Done. Learned a lot. And its almost orthogonal to my day job, which is a QoL improvement.

[ooaklee]

Learned a lot.

I hope I do as well working with you, refining support for the SP11, and making it easier for others to get started/get involved. I unfortunately only hve one X1E device so I'm doing a lot of testing on my daily driver so, it make me spot things and try and fix bugs (learning by fire is what I tell myself 😅)

Motto: Getting Shite Done.

Yeah, this is the way. You've been an inspiration and trendsetter. Honestly, if you gave up, then many of us with the Snapdragon X1* devices would have been left stranded

[ooaklee]

@jglathe, I've confirmed that this works as expected.

Once we merge this, I will start prepping the targeted PRs as we mentioned here and in #81

[jglathe]

Merged, and building the package for upload on Google Drive. Thanks!