linux: bump SM8250/SM8550/SM8650 to 7.2 - #3209
Open
loki666 wants to merge 4 commits into
Open
Conversation
Contributor
Author
loki666
force-pushed
the
linux-7.2-qcom
branch
3 times, most recently
from
August 23, 2026 19:56
a7708a7 to
09e937d
Compare
7.2 removes two APIs we use and takes over two of our patches, so
the version bump, the patch rework and the DTS migration have to
land together.
Absorbed upstream, deleted here rather than carried:
0101 sm8550 DDR/LLCC/L3 CPU bandwidth scaling - landed verbatim,
all 11 hunks read as already applied.
0061 sgm3804 panel-power regulator - landed as a rewrite with an
incompatible binding: two rails from pos/neg child nodes
each carrying enable-gpios, where ours was one rail with
both GPIOs in reset-gpios on the parent. Same compatible,
same file path, same Kconfig symbol, so keeping both was
not an option and the binding is migrated across all six
board nodes.
API removals handled:
drm_panel_init() is now static; devm_drm_panel_alloc() allocates
the container struct and initialises the panel in one call. All
13 panel drivers converted.
wsa881x now requests its powerdown GPIO GPIOD_OUT_LOW, so
0062_wsa881x is rebased onto that.
The panels fed by the sgm3804 take the negative rail as well: 0051,
0052, 0062 and 0063 gain an avee supply, and 0063 wt0600-1k moves
from a single regulator to a bulk get. The Pocket DS lower panel is
an st7703, which knows only vcc/iovcc, so 0053 adds an optional
avee-supply to that driver; the other st7703 boards do not declare
it and are unaffected.
The rails are pinned to 5200000 uV, not the 5000000 the old DTS
asked for. The old driver ignored the DT constraint and wrote
selector 0x0c, which is 5.2V on upstream's linear range, so asking
for 5.0V would be a silent voltage change dressed up as a no-op.
The SM8650 node listed four reset-gpios (59, 58, 163, 164) but the
old driver only ever fetched index 0 and 1; 163/164 are dropped and
panel_pwr_active still drives all four output-high.
READ_ONLY_THP_FOR_FS is dropped from the three configs: upstream
removed the Kconfig option and file THP is unconditional now.
Verified: all patches apply with zero rejects on all three SoCs
(35/56/25 patches), and all 21 board dtbs compile with the rails
resolving to the right GPIOs. NOT hardware validated - panel power
changed on Pocket ACE/DMG/DS/S1K/S2K, PS2 and konkr-pf, where a
wrong migration shows as a lit backlight over a black panel.
7.2 drops the strncpy() declaration from <linux/string.h>, so the generated-MAC patches no longer build on the three SoCs now on 7.2: ath11k/mac.c:209:9: error: implicit declaration of function 'strncpy' Both call sites copy exactly 6 bytes from a serial number already checked to be at least 6 characters long into a zero-initialised 7-byte buffer, so strncpy() never padded and never wrote the NUL. memcpy() is byte-for-byte identical here. SM6115 and SM8750 carry the same code on 7.1.x where strncpy() still exists; left alone to avoid a kernel rebuild, they need the same fix when they bump.
Pocket Max on 7.2 comes up with no sound card at all. va_macro's probe enables its "macro" clock, which is LPASS_HW_MACRO_VOTE - an APR vote to the ADSP. Built in, that fires ~17ms after the APR AFE service device appears and the ADSP is not ready to serve it: [1.127449] apr: Adding APR/GPR dev: aprsvc:service:4:4 [1.144345] qcom-q6afe: cmd = 0x100f4 returned error = 0x16 [1.144353] qcom-q6afe: Unknown cmd 0x100f4 [4.318952] qcom-q6afe: AFE failed to vote (3) [4.318960] va_macro 3370000.codec: probe failed with error -110 q6afe's callback has no case for an error response to 0x100f4, so the waiter is never woken and sleeps out its full 3.17s timeout. Probe then returns -110, a hard failure rather than -EPROBE_DEFER, so nothing ever retries and rx/tx/wsa macros, all three soundwire controllers and the machine driver queue behind it forever. Nothing in the audio path regressed: q6afe.c, q6afe-clocks.c, q6core.c, apr.c, sm8250.c and sm8250.dtsi are byte-identical 7.1.2 -> 7.2, and lpass-va-macro.c changed only for sc7280. 7.2 just shifted boot timing enough to lose a race that =y was always exposed to. Confirmed on hardware by forcing a late re-probe - same kernel, same DT, same firmware - which bound immediately and brought up card 0 PocketMax: echo 3370000.codec > /sys/bus/platform/drivers_probe So build the stack as modules, loaded from the rootfs long after the ADSP is up. This is what SM8550 already does here, and what Nova-Deck does for its own SM8250 boards. QCOM_APR, QCOM_Q6V5_PAS, QCOM_Q6V5_COMMON and PINCTRL_LPASS_LPI stay =y: Q6V5_PAS also boots CDSP for GPU zap and SLPI, and the ADSP coming up early is wanted - only the audio drivers need to arrive late. The symbols left =y now match SM8550's exactly, so no built-in code is left linking against module symbols (REGMAP_SOUNDWIRE=y against SOUNDWIRE=m would not have linked). NOT boot-tested. Card enumeration is proven via the manual re-probe; sound actually coming out is not. Playback after that forced probe still failed with wsa881x-codec ASoC error (-22) at snd_soc_pcm_component_pm_runtime_get(), which may be an artifact of rebinding into a userspace that had already given up on the card, or a second WSA runtime-PM problem behind this one.
The Pocket Max boots silent: the card, UCM, routing and ADSP all come up
fine, but both WSA881x speaker amps sit at UNATTACHED and the first PCM
open fails.
wsa881x-codec sdw:1:0:0217:2010:00:1: Initialization not complete
WSA Playback: ASoC error (-110): at __soc_pcm_open()
MANGMI wires BOTH amps to one powerdown line, declared twice in the DTS
(&tlmm 127 on speaker@0,1 and speaker@0,2); every other wsa881x board
gives each amp its own pin. gpiolib auto-scans that and hands each
consumer a gpiolib_shared proxy over the single line, and a shared line
aggregates its consumers, so one amp left in runtime-suspend keeps the
line asserted and holds the other in powerdown too. The stuck amp never
completes SoundWire enumeration, wsa881x_runtime_resume() times out
after 1s waiting on initialization_complete, runtime PM then latches
the device in the error state and it never retries. The amps do
enumerate correctly at probe - it is the first autosuspend, 3s later,
that strands them.
Pin both amps active from bind so the line is never asserted. Matched
on the wsa881x SoundWire part ID, which in this tree is the Pocket Max
only, and mirrors the existing 99-wcd938x-nosleep.rules.
Confirmed on hardware across a cold boot: both amps Attached and
runtime_status=active, gpio127 reads out high on an ACTIVE_LOW line,
zero wsa881x timeouts in the log (was 4), and still attached after 40s
idle. NovaDeck carries the same fix for the same board.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
7.2 removes two APIs we use and takes over two of our patches, so the version bump, the patch rework and the DTS migration have to land together.
Absorbed upstream, deleted here rather than carried:
0101 sm8550 DDR/LLCC/L3 CPU bandwidth scaling - landed verbatim,
all 11 hunks read as already applied.
0061 sgm3804 panel-power regulator - landed as a rewrite with an
incompatible binding: two rails from pos/neg child nodes
each carrying enable-gpios, where ours was one rail with
both GPIOs in reset-gpios on the parent. Same compatible,
same file path, same Kconfig symbol, so keeping both was
not an option and the binding is migrated across all six
board nodes.
API removals handled:
drm_panel_init() is now static; devm_drm_panel_alloc() allocates
the container struct and initialises the panel in one call. All
13 panel drivers converted.
wsa881x now requests its powerdown GPIO GPIOD_OUT_LOW, so
0062_wsa881x is rebased onto that.
The panels fed by the sgm3804 take the negative rail as well: 0051, 0052, 0062 and 0063 gain an avee supply, and 0063 wt0600-1k moves from a single regulator to a bulk get. The Pocket DS lower panel is an st7703, which knows only vcc/iovcc, so 0053 adds an optional avee-supply to that driver; the other st7703 boards do not declare it and are unaffected.
The rails are pinned to 5200000 uV, not the 5000000 the old DTS asked for. The old driver ignored the DT constraint and wrote selector 0x0c, which is 5.2V on upstream's linear range, so asking for 5.0V would be a silent voltage change dressed up as a no-op.
The SM8650 node listed four reset-gpios (59, 58, 163, 164) but the old driver only ever fetched index 0 and 1; 163/164 are dropped and panel_pwr_active still drives all four output-high.
0006-hid-playstation is upstream in 7.2 under ds->is_edge, so it moves to a new patches/pre-7.2 bucket that only devices still below 7.2 opt into. READ_ONLY_THP_FOR_FS is dropped from the three configs: upstream removed the Kconfig option and file THP is unconditional now.
Verified: all patches apply with zero rejects on all three SoCs (35/56/25 patches), and all 21 board dtbs compile with the rails resolving to the right GPIOs. NOT hardware validated - panel power changed on Pocket ACE/DMG/DS/S1K/S2K, PS2 and konkr-pf, where a wrong migration shows as a lit backlight over a black panel.
AI Usage
While ROCKNIX doesn't have restrictions on AI tools in contributing, please be transparent about their usage as it
helps set the right context for reviewers.
Did you use AI tools to help write this code? YES