SP11: integrate 7.2.x platform, IPTS pen, audio, camera, and power support - #79
SP11: integrate 7.2.x platform, IPTS pen, audio, camera, and power support#79ooaklee wants to merge 2165 commits into
Conversation
QMP Combo PHYs default to USB3DP lane routing, which can break static setups like
DP-to-HDMI bridges by misallocating lanes to USB3.
Revive the optional "qcom,combo-initial-mode" DT property [1] to explicitly
set the initial mode ("usb3dp", "dp", "usb3"). In static configs (no mode-switch
or orientation-switch props), honor it and skip lane inference to avoid overrides.
This simplifies HDMI enablement on undocumented Snapdragon X laptops while
preserving dynamic Type-C behavior.
[1]: https://lore.kernel.org/r/20250821-topic-x1e80100-hdmi-v1-2-f14ad9430e88@linaro.org
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Microsoft Surface Pro 12 is using this (well, my definition of it), changed to Stephan Gerhold's one. Remove the edp0_hpd_default reference from Thinkbook 16 as TLMM 119 is used by the HDMI bridge as enable pin. Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-1-6310176239a6@linaro.org Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
…to dp controller, fix backlight" now duplicate template, therefore remove it Link: https://lore.kernel.org/r/20250822-x1e80100-add-edp-hpd-v2-1-6310176239a6@linaro.org This reverts commit 22f5ffacc9cd4f5a5074b863223f80bc0f0d6b33.
…lt pinctrl seems to be needed Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Relates-to commit 8c0b058. Signed-off-by: James Addison <jay@jp-hosting.net>
adding the remaining commits of 20251101-asus_usbc_dp-v1-0-9fd4eb9935e8@hotmail.com ... but on the generalized x1-asus-vivobook-s15.dtsi Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
this works with Ubuntu kernel builds that don't know the SPRCHRGD in QSEECOM Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
found in Lenovo Ideapad Slim 3 15Q8X10 raw EDID: 00 ff ff ff ff ff ff 00 09 e5 ea 0c 00 00 00 00 0c 22 01 04 a5 21 15 78 03 af e5 97 5e 58 92 28 1f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 9c 3e 80 c8 70 b0 3c 40 30 20 36 00 49 ce 10 00 00 1a 00 00 00 fd 00 28 3c 4c 4c 10 01 0a 20 20 20 20 20 20 00 00 00 fe 00 42 4f 45 20 43 51 0a 20 20 20 20 20 20 00 00 00 fc 00 4e 56 31 35 33 57 55 4d 2d 4e 34 31 0a 01 63 70 20 79 02 00 81 00 15 74 1a 00 00 03 01 28 3c 00 00 53 4a 53 4a 3c 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e3 90 Detailed Timing Descriptors: DTD 1: 1920x1200 60.002995 Hz 16:10 75.604 kHz 160.280000 MHz (329 mm x 206 mm) Hfront 48 Hsync 32 Hback 120 Hpol P Vfront 3 Vsync 6 Vback 51 Vpol N Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
…iants LCD: Panel is CMN N140JCE-EL1, selecting the odd backlight PWM like on ThinkBook 16 G7 QOY Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
like on Thinkbook 16 and Ideapad 5 Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
seem to be problematic Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
as tested out by Anthony Ruhier and Val Packett [1] [1]: https://lore.kernel.org/all/a5efb372-1a2a-4262-abc8-49bbeffa6961@packett.cool/ Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
name change from x1e80100 and x1p42100 Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
There is a small window where the device can suspend after pm_runtime_enable() and before pm_runtime_forbid(), causing an unnecessary suspend/resume cycle while the PHY is not yet registered. Move pm_runtime_forbid() before pm_runtime_enable() to eliminate this race. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
add Purwa-specific dts Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Put the firmware paths into the separate dts also correct the gpu firmware path to consistent naming. Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
…ible for older kernels Add this compatible to get efivars on kernels that are not aware of the sp11 in scm. Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
rfkill should be disabled according to the Surface Pro 11's DSDT. https://lore.kernel.org/all/20250113074810.29729-3-quic_lingbok@quicinc.com/ has added support to read the ACPI bitflag when ACPI is supported. Document the disable-rfkill property to expose one specific feature (DISABLE_RFKILL_BIT) for devices described with a DT, so that the feature can be disabled. Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Signed-off-by: Dale Whinham <daleyo@gmail.com>
Some devices (e.g. Microsoft Surface Pro 11) indicate that the rfkill feature should be disabled by means of an ACPI bitflag. If ACPI is not being used (i.e. booting using a devicetree) then this property will not be read and therefore rfkill may be enabled and the ath12k will be hard-blocked with no way to disable it. Add a devicetree property that allows us to disable the rfkill feature. Tested-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Signed-off-by: Dale Whinham <daleyo@gmail.com>
Disable rfkill as it is supposed to be according to the ath12k feature flags in the Microsoft Surface Pro 11 ACPI DSDT. Signed-off-by: Dale Whinham <daleyo@gmail.com> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Allows MAC address setting via dtbloader.
define PCI_VENDOR_ID_HP_BOGUS 0xffff Qualcomm FastConnect 6900 Wi-Fi 6E Dual Band Simultaneous (DBS) WiFiCx Network Adapter Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
For some devices, Wi-Fi is entirely hard blocked by default making the Wi-Fi radio unusable, except if rfkill is disabled as expected on those models. Commit c6a7c0b ("wifi: ath12k: Add Support for enabling or disabling specific features based on ACPI bitflag") added a way to support features set via ACPI, including the DISABLE_RFKILL bit. Add a disable-rfkill property to expose the DISABLE_RFKILL bit equivalent for devices described by a Devicetree instead of ACPI. Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Reference the ieee80211.yaml schema to allow disable-rfkill to be used for models that need to disable the rfkill feature, otherwise the Wi-Fi radio is unusable. This is required by the Surface Pro 11 with WCN7850. Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
in the spirit of sp12 Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
add rfkill, mac addresses, pcie4 pinctrl Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
previously was /usr/lib/, /usr/share/ Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Replace the earlier CCS-based bring-up with the validated standalone Sony IMX681 front-camera stack for the Surface Pro 11 OLED.\n\nAdd the 3840x2640 packed RAW10 sensor mode, 24-bit exposure and gain controls, Denali CCI1.1/MCLK4/supply/reset/privacy-LED wiring, and the CAMSS CSIPHY2 -> CSID0 -> VFE0 RDI0 route. Add the exact X1E80100 trio-0 C-PHY lifecycle at 2.406 Gsymbol/s, reject unvalidated C-PHY rates and topologies before hardware programming, and leave the existing D-PHY path unchanged.\n\nEnable CONFIG_VIDEO_IMX681 in the Ubuntu ARM64 package policy and record the result as 7.2.0-jg-0sp11v14.\n\nThe kernel-code state at 64999b9 was validated on target hardware with repeated and continuous raw capture, zero reported CSID ECC/CRC or VFE transport errors, working gain/exposure response, an IMX681-aware libcamera pipeline, PipeWire/WirePlumber publication, and Firefox Google Meet capture. The PR tip adds changelog metadata only.\n\nImplementation provenance includes turbineBMW's standalone sensor and receiver work, karsies-wq's SP11 camera bring-up, geocausa's Windows-parity analysis, and same-machine Windows/QTI traces.\n\nCloses ooaklee/linux-surface-pro-11-oe#43.\nFollow-up qualification and image-tuning work remains tracked in ooaklee/linux-surface-pro-11-oe#54.
The MSHW0485 controller exposes a native HID descriptor for pen input, but delivers stylus data as DFT reports that require signal processing. The existing touchscreen driver already owns the HID-SPI transport, panel mode, recovery, and direct multitouch path, while upstream iptsd expects a HIDRAW endpoint carrying those DFT reports. Cache the validated report descriptor and feature metadata, then register a private-group SPI HID sibling for the Surface Pro 11 X1P and X1E product IDs. Start the sibling with HID_CONNECT_HIDRAW only so it cannot create a second touchscreen or compete with the existing direct input device. Relay only the core 0x0b, 0x0c, 0x0d, and 0x1a reports as report ID plus content. Keep diagnostic report 0x07 and privacy-sensitive report 0x6e off the production HIDRAW path. Proxy and cache feature GET 0x06, acknowledge valid feature SET 0x05 mode writes locally, and reject other requests so the touchscreen driver remains the sole panel-mode owner. Tie the child HID device to transport generations. Perform registration and destruction in deferred work outside io_lock, bound failed rebind attempts, and quiesce recovery, IRQ, and HID work before suspend or remove. Recreate the sibling only after successful transport recovery. Require HID and HIDRAW in Kconfig and mirror the private HID group for HID-BPF. Enable MSHW0485 in the Ubuntu X1E configuration and record the integration as 7.2.0-jg-0sp11v16. Target-device and suspend/resume qualification remain required before merge. Signed-off-by: Leon Silcott <lnsilcott@gmail.com>
The SP11 X1E live run validated the complete Phase 84 profile with balanced level-low IRQ accounting, DFT pressure and two-axis tilt, the barrel button, unchanged normal multitouch, and no reset or transport failures. The userspace integration has no safe way to select the new parameters globally without also affecting an older fallback kernel. Make minimal IPTS initialization, one-response IRQ cadence, ready-line quiescing, and host-fault recovery the driver defaults. Keep the read-only module parameters as load-time opt-outs and leave the Windows paths disabled. This selects the exact runtime values used by the accepted v19 test while preserving v16 unchanged. Signed-off-by: Leon Silcott <lnsilcott@gmail.com>
The X1P/LCD MSHW0485 identity 045e:0c80 is already accepted by SP11 descriptor validation. The pen bridge has an exact X1P HID match, preserves the panel product ID, serves panel-provided metadata, and uses the shared level-low Denali touchscreen wiring. The Phase 84 defaults are module-wide, so no new behavior switch is needed. Document X1P as a supported target of the shared IPTS path and update the v19 changelog while keeping the live qualification boundary explicit: only X1E/OLED has passed the current pen run, and X1P hardware, forced recovery, and repeated suspend/resume remain pending. Signed-off-by: Leon Silcott <lnsilcott@gmail.com>
input: mshw0485: add SP11 HIDRAW bridge for iptsd pen processing
748e39e to
032e174
Compare
|
Harrumph. I'm afraid we need to structure this a bit. I will merge this (whole PR) into jg/ubuntu-qcom-x1e-7.2.y-sp11 and keep this PR open. To land in my release tip, this needs to be fed by topic, and with a few guardrails. I don't want to break the kernel for non-SP11 devices. I had a similar issue with my implementation of i2c-hid that is capable of polling a device on a shared interrupt (or no interrupt at all), also not in my release branch because it was not safe for other devices. This is the proposed split of code. In the best tradition of our times, prepared by Grok AI. I leave its snarky comments in.
This is cool work and in the right spirit. Needs to be tamed a bit to not break other working stuff. |
|
That qspi dma work... holy shite. I have kept your version of gpi.c and spi-geni-qcom.c. There are changes in 7.2.2, please re-evaluate how this needs to be lifted to 7.2.2. |
|
Compile-tested rebase is on https://github.com/jglathe/linux_ms_dev_kit/tree/jg/ubuntu-qcom-x1e-7.2.y-sp11 Diff vs the shared line: pre-built packages are on the Google Drive location. |
ooaklee
changed the title
|
Thanks for looking into this @jglathe . I will keep this PR as the integration record and focus on bringing the staging branch fully up to date. I will create a new branch from the current Once the staging branch is corrected and validated, I will resync from the latest I will isolate and submit these as smaller topics as requested:
Is this in line with what you wanted? |
|
When you do changes in drivers that are not exclusively written for the SP11 (and usually have a hardware /firmware detection in probe()), you need to gate your changes against the "common" use case, as you did in the qspi code for gpi DMA. The gating is easiest with check agaunst the dt, of_ compatible=microsoft,denali. The of_ structure is also in the device descriptor or can be easily reached. |
|
All current open PRs are drafts. That qspi patch is a big one, I don't have hardware that uses the spi at all (to my knowledge). Maybe a public call for testing on Ubuntu Discourse helps to verify the changes. There are quite a few people with Dell Laptops, they could help, probably. The sp11v21 pre-compiled package would be a good start. A bit of a testing dilemma. |
|
Also, I have set up a Matrix room for sp11/12 bringup: https://matrix.to/#/#sp11_12_linux:matrix.org |
|
@jglathe, it doesn't seem like I can join; I've tried the web and desktop. What account did you invite? Do you have Discord? If so, add me there, please:
|
The majority are ready to go; I only put them in draft to make sure we follow the order we agreed on
That's a shout; I'll make |
|
Do you have a user name on Matrix? I need this to invite you. Mine is @jglathe:matrix.org |
|
@jglathe, I've also made |
87bcf07 to
4943ee7
Compare
20 participants
Summary
Integrates the downstream Surface Pro 11 kernel and Ubuntu 7.2.x line for both supported Denali variants:
045e:0c83045e:0c80The branch now brings together SP11 device-tree, driver, packaging, configuration, and CI work for direct touch, iptsd-backed pen input, volume buttons, native audio and microphone capture, platform power profiles, battery-provider selection, and the IMX681 front camera.
This is intentionally a broad downstream integration line rather than an upstream-ready subsystem patch series.
Highlights
Touch, pen, and buttons
iptsdv3.1.0 stylus processing./dev/g6ts-heatexport for diagnostics; pressure, tilt, and button events use the DFT/iptsd path.Audio and microphones
microsoft,denali.Power and battery
platform_profileavailable on the DT-only SP11 through a non-ACPI kobject fallback while preserving the legacy sysfs path expected by power-profiles-daemon.FREQ_QOS_MAXCPU caps, late cpufreq-policy handling, and an SP11 low-power boot default.battmgrremains authoritative for both variants.Front camera
CCI1.1 -> CSIPHY2 -> CSID0 -> VFE0 RDI0and describes MCLK4, power rails, reset, and the privacy LED.Platform integration
jg/ubuntu-qcom-x1e-7.2.ykernel line, so the comparison also contains inherited QCOM arm64, DRM, media, networking, platform-driver, and core-kernel work.Additions after the original recorded tip
The previous description's validation section stopped at
5cf0b8835858. The current head adds the following SP11 integration work:b6ca0e494a9b537d1ac612253fc7c5249f4a58e36b1acb04d915d679423e2cbd1ec3e2daThat range contains 18 commits touching 61 files, with 8,520 insertions and 878 deletions.
Validation status
2cbd1ec3e2da385e7bd91fd65c63ba5a8fb5b865.7.2.0-jg-0sp11v19-qcom-x1e; hover, contact, pressure, tilt, barrel button, and concurrent one-/two-/three-finger touch worked with no transport errors, recovery failures, daemon restarts, or kernel taint in the acceptance run. X1P uses the same promoted profile, but separate X1P pen qualification remains outstanding.045e:0c80; descriptor validation and physical touch completed successfully.git diff --checkpassed in the constituent PR; Linux hardware capture and regression testing were still outstanding there.Integration state
The target and integration branches have advanced independently since this PR opened, and GitHub currently reports merge conflicts. The large comparison includes inherited kernel and Ubuntu history and is not a count of SP11-authored patches. The branch must be synchronized with the current target before merge.
Links