mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-10-14 05:55:17 +00:00
No description
- C 96.9%
- Assembly 0.9%
- Rust 0.6%
- Shell 0.6%
- Python 0.5%
- Other 0.3%
d470be3c4f
The pm_runtime usage in lpass-sc7280 was broken in quite a few ways. Specifically: 1. At the end of probe it called "put" twice. This is a no-no and will end us up with a negative usage count. Even worse than calling "put" twice, it never called "get" once. Thus after bootup it could be seen that the runtime usage of the devices managed by this driver was -2. 2. In some error cases it manually called pm_runtime_disable() even though it had previously used devm_add_action_or_reset() to set this up to be called automatically. This meant that in these error cases we'd double-call pm_runtime_disable(). 3. It forgot to call undo pm_runtime_use_autosuspend(), which can sometimes have subtle problems (and the docs specifically mention that you need to undo this function). Overall the above seriously calls into question how this driver is working. It seems like a combination of "it doesn't", "by luck", and "because of the weirdness of runtime_pm". Specifically I put a printout to the serial console every time the runtime suspend/resume was called for the two devices created by this driver (I wrapped the pm_clk calls). When I had serial console enabled, I found that the calls got resumed at bootup (when the clk core probed and before our double-put) and then never touched again. That's no good. [ 0.829997] DOUG: my_pm_clk_resume, usage=1 [ 0.835487] DOUG: my_pm_clk_resume, usage=1 When I disabled serial console (speeding up boot), I got a different pattern, which I guess (?) is better: [ 0.089767] DOUG: my_pm_clk_resume, usage=1 [ 0.090507] DOUG: my_pm_clk_resume, usage=1 [ 0.151885] DOUG: my_pm_clk_suspend, usage=-2 [ 0.151914] DOUG: my_pm_clk_suspend, usage=-2 [ 1.825747] DOUG: my_pm_clk_resume, usage=-1 [ 1.825774] DOUG: my_pm_clk_resume, usage=-1 [ 1.888269] DOUG: my_pm_clk_suspend, usage=-2 [ 1.888282] DOUG: my_pm_clk_suspend, usage=-2 These different patterns have to do with the fact that the core PM Runtime code really isn't designed to be robust to negative usage counts and sometimes may happen to stumble upon a behavior that happens to "work". For instance, you can see that __pm_runtime_suspend() will treat any non-zero value (including negative numbers) as if the device is in use. In any case, let's fix the driver to be correct. We'll hold a pm_runtime reference for the whole probe and then drop it (once!) at the end. We'll get rid of manual pm_runtime_disable() calls in the error handling. We'll also switch to devm_pm_runtime_enable(), which magically handles undoing pm_runtime_use_autosuspend() as of commit |
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 | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .rustfmt.toml | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.