mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-10 20:48:12 +00:00
No description
- C 96.8%
- Assembly 0.9%
- Rust 0.7%
- Shell 0.6%
- Python 0.5%
- Other 0.3%
fc56d1e687Andrey Golovko <andrey.golovko@gmail.com> says: v1 was a single patch that powered the SDCA Function up in the port PRE_PREP callback: https://lore.kernel.org/all/20260813001500.9218-1-andrey.golovko@gmail.com/ Mark asked whether that does the right thing when userspace restarts the stream with SNDRV_PCM_IOCTL_RESUME instead of preparing it, and pointed out that a stream can also be suspended while prepared; Vijendar agreed. The answer to the first question is no, and it is reproducible on this machine, so v2 adds a patch to fix that path. The second case turns out to be a wider gap that neither patch closes; it is described at the end. Measured on an ASUS ProArt PX13 HN7306EAC (AMD ACP7.0, two TAS2783 on SDW1). A test program plays a 440/660 Hz tone straight to the hw device, the machine goes through an s2idle cycle, and on -ESTRPIPE the program calls snd_pcm_resume() only - never snd_pcm_prepare(). The tone is measured through the internal microphone against the noise floor of the same run, and the peripheral registers are read out of band. With v1 alone (broonie/sound for-next + v1): before suspend after snd_pcm_resume() DP1 PrepareCtrl 0x1 / 0x2 0x0 / 0x0 PDE23 req / act 0x0 / 0x0 0x3 / 0x3 tone 440 / 660 Hz +65.5 / +75.2 dB -1.7 / +1.8 dB snd_pcm_resume() returned 0 and the PCM stayed RUNNING, so nothing in the stack reported a failure - the speakers were simply silent. The ports were never prepared again, so the PRE_PREP callback v1 relies on was never reached. With this series: before suspend after snd_pcm_resume() DP1 PrepareCtrl 0x1 / 0x2 0x1 / 0x2 PDE23 req / act 0x0 / 0x0 0x0 / 0x0 tone 440 / 660 Hz +73.7 / +88.3 dB +73.7 / +88.5 dB ChannelEn also moved to the other bank across the cycle, as it should when the ports are prepared afresh. The ordinary path is unaffected. The same test recovering with snd_pcm_prepare() instead of snd_pcm_resume(), on the same build, gives +79.8 / +86.9 dB after the cycle with the ports prepared and the bank switched back. This also explains the negative test Robin Everaars reported for v1 on the same board earlier today: playback opened without an error, both amplifiers stayed attached, and the speakers were silent - which is what this path looks like from userspace. The case this series does not cover =================================== A stream that is suspended while merely PREPARED never sees a trigger at all: snd_pcm_do_suspend() returns early when the stream is not running, and snd_pcm_do_resume() returns early unless the suspended state was RUNNING or DRAINING. Userspace then calls snd_pcm_start(), the ports are enabled, and the peripheral has lost its port state without anything in the path noticing. Patch 1 cannot help there - the SoundWire stream is still SDW_STREAM_PREPARED, so sdw_prepare_stream() is a no-op by design - and neither can the codec, which has no way to tell the core that its ports went away. The bus does know: the peripheral goes UNATTACHED and comes back uninitialized. Making that invalidate the prepared state of the streams it takes part in looks like the right place to me, but it is a core change and I have not written it. Say if it belongs in this series. Link: https://patch.msgid.link/20260813194000.10412-1-andrey.golovko@gmail.com |
History
|
|
|---|---|---|
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| Documentation | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| io_uring | ||
| ipc | ||
| kernel | ||
| lib | ||
| LICENSES | ||
| mm | ||
| net | ||
| rust | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .clippy.toml | ||
| .cocciconfig | ||
| .editorconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .pylintrc | ||
| .rustfmt.toml | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel ============ The Linux kernel is the core of any Linux operating system. It manages hardware, system resources, and provides the fundamental services for all other software. Quick Start ----------- * Report a bug: See Documentation/admin-guide/reporting-issues.rst * Get the latest kernel: https://kernel.org * Build the kernel: See Documentation/admin-guide/quickly-build-trimmed-linux.rst * Join the community: https://lore.kernel.org/ Essential Documentation ----------------------- All users should be familiar with: * Building requirements: Documentation/process/changes.rst * Code of Conduct: Documentation/process/code-of-conduct.rst * License: See COPYING Documentation can be built with make htmldocs or viewed online at: https://www.kernel.org/doc/html/latest/ Who Are You? ============ Find your role below: * New Kernel Developer - Getting started with kernel development * Academic Researcher - Studying kernel internals and architecture * Security Expert - Hardening and vulnerability analysis * Backport/Maintenance Engineer - Maintaining stable kernels * System Administrator - Configuring and troubleshooting * Maintainer - Leading subsystems and reviewing patches * Hardware Vendor - Writing drivers for new hardware * Distribution Maintainer - Packaging kernels for distros * AI Coding Assistant - LLMs and AI-powered development tools For Specific Users ================== New Kernel Developer -------------------- Welcome! Start your kernel development journey here: * Getting Started: Documentation/process/development-process.rst * Your First Patch: Documentation/process/submitting-patches.rst * Coding Style: Documentation/process/coding-style.rst * Build System: Documentation/kbuild/index.rst * Development Tools: Documentation/dev-tools/index.rst * Kernel Hacking Guide: Documentation/kernel-hacking/hacking.rst * Core APIs: Documentation/core-api/index.rst Academic Researcher ------------------- Explore the kernel's architecture and internals: * Researcher Guidelines: Documentation/process/researcher-guidelines.rst * Memory Management: Documentation/mm/index.rst * Scheduler: Documentation/scheduler/index.rst * Networking Stack: Documentation/networking/index.rst * Filesystems: Documentation/filesystems/index.rst * RCU (Read-Copy Update): Documentation/RCU/index.rst * Locking Primitives: Documentation/locking/index.rst * Power Management: Documentation/power/index.rst Security Expert --------------- Security documentation and hardening guides: * Security Documentation: Documentation/security/index.rst * LSM Development: Documentation/security/lsm-development.rst * Self Protection: Documentation/security/self-protection.rst * Reporting Vulnerabilities: Documentation/process/security-bugs.rst * CVE Procedures: Documentation/process/cve.rst * Embargoed Hardware Issues: Documentation/process/embargoed-hardware-issues.rst * Security Features: Documentation/userspace-api/seccomp_filter.rst Backport/Maintenance Engineer ----------------------------- Maintain and stabilize kernel versions: * Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst * Backporting Guide: Documentation/process/backporting.rst * Applying Patches: Documentation/process/applying-patches.rst * Subsystem Profile: Documentation/maintainer/maintainer-entry-profile.rst * Git for Maintainers: Documentation/maintainer/configure-git.rst System Administrator -------------------- Configure, tune, and troubleshoot Linux systems: * Admin Guide: Documentation/admin-guide/index.rst * Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst * Sysctl Tuning: Documentation/admin-guide/sysctl/index.rst * Tracing/Debugging: Documentation/trace/index.rst * Performance Security: Documentation/admin-guide/perf-security.rst * Hardware Monitoring: Documentation/hwmon/index.rst Maintainer ---------- Lead kernel subsystems and manage contributions: * Maintainer Handbook: Documentation/maintainer/index.rst * Pull Requests: Documentation/maintainer/pull-requests.rst * Managing Patches: Documentation/maintainer/modifying-patches.rst * Rebasing and Merging: Documentation/maintainer/rebasing-and-merging.rst * Development Process: Documentation/process/maintainer-handbooks.rst * Maintainer Entry Profile: Documentation/maintainer/maintainer-entry-profile.rst * Git Configuration: Documentation/maintainer/configure-git.rst Hardware Vendor --------------- Write drivers and support new hardware: * Driver API Guide: Documentation/driver-api/index.rst * Driver Model: Documentation/driver-api/driver-model/driver.rst * Device Drivers: Documentation/driver-api/infrastructure.rst * Bus Types: Documentation/driver-api/driver-model/bus.rst * Device Tree Bindings: Documentation/devicetree/bindings/ * Power Management: Documentation/driver-api/pm/index.rst * DMA API: Documentation/core-api/dma-api.rst Distribution Maintainer ----------------------- Package and distribute the kernel: * Stable Kernel Rules: Documentation/process/stable-kernel-rules.rst * ABI Documentation: Documentation/ABI/README * Kernel Configuration: Documentation/kbuild/kconfig.rst * Module Signing: Documentation/admin-guide/module-signing.rst * Kernel Parameters: Documentation/admin-guide/kernel-parameters.rst * Tainted Kernels: Documentation/admin-guide/tainted-kernels.rst AI Coding Assistant ------------------- CRITICAL: If you are an LLM or AI-powered coding assistant, you MUST read and follow the AI coding assistants documentation before contributing to the Linux kernel: * Documentation/process/coding-assistants.rst This documentation contains essential requirements about licensing, attribution, and the Developer Certificate of Origin that all AI tools must comply with. Communication and Support ========================= * Mailing Lists: https://lore.kernel.org/ * IRC: #kernelnewbies on irc.oftc.net * Bugzilla: https://bugzilla.kernel.org/ * MAINTAINERS file: Lists subsystem maintainers and mailing lists * Email Clients: Documentation/process/email-clients.rst