mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2025-01-01 10:42:11 +00:00
The linux-next integration testing tree
8afe816b0c
MediaTek found an issue with display HW registers configuration, and located the reason in the CMDQ Mailbox driver; reporting the original comment with the analysis of this problem by Jason-JH Lin: GCE should config HW in every vblanking duration. The stream done event is the start signal of vblanking. If stream done event is sent between GCE clk_disable and clk_enable. After GCE clk_enable the stream done event may not appear immediately and have about 3us delay. Normal case: clk_disable -> get EventA -> clk_enable -> clear EventA -> wait EventB -> get EventB -> config HW Abnormal case: clk_disable -> get EventA -> clk_enable -> EventA delay appear -> clear EventA fail -> wait EventB but get EventA -> config HW This abnormal case may configure display HW in the vactive or non-vblanking duration. From his analysis we get that the GCE may finish its event processing after some amount of time (and not immediately after sending commands to it); since the GCE is used for more than just display, and it gets used frequently, solve this issue by implementing Runtime PM handlers with autosuspend: this allows us to overcome to the remote processor delay issues and reduce the clock enable()/disable() calls, while also still managing to save some power, which is something that we wouldn't be able to do if we just enable the GCE clocks at probe. Speaking of which: if Runtime PM is not available there will obviously be no way to get this power saving action so, in this case, the clocks will be enabled at probe() time, kept enabled for the entire driver's life and disabled at remove(). Reported-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org> |
||
|---|---|---|
| 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.