[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20211117224841.3442482-1-briannorris@chromium.org>
Date: Wed, 17 Nov 2021 14:48:39 -0800
From: Brian Norris <briannorris@...omium.org>
To: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>
Cc: "Kristian H . Kristensen" <hoegsberg@...gle.com>,
linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Doug Anderson <dianders@...omium.org>,
Andrzej Hajda <andrzej.hajda@...el.com>,
Rob Clark <robdclark@...il.com>, linux-input@...r.kernel.org,
Rob Clark <robdclark@...omium.org>,
Daniel Vetter <daniel@...ll.ch>,
David Airlie <airlied@...ux.ie>,
dri-devel@...ts.freedesktop.org,
Brian Norris <briannorris@...omium.org>
Subject: [PATCH v2 0/2] drm: Support input-boosted panel self-refresh exit
A variety of applications have found it useful to listen to
user-initiated input events to make decisions within a DRM driver, given
that input events are often the first sign that we're going to start
doing latency-sensitive activities:
* Panel self-refresh: software-directed self-refresh (e.g., with
Rockchip eDP) is especially latency sensitive. In some cases, it can
take 10s of milliseconds for a panel to exit self-refresh, which can
be noticeable. Rockchip RK3399 Chrome OS systems have always shipped
with an input_handler boost, that preemptively exits self-refresh
whenever there is input activity.
* GPU drivers: on GPU-accelerated desktop systems, we may need to
render new frames immediately after user activity. Powering up the
GPU can take enough time that it is worthwhile to start this process
as soon as there is input activity. Many Chrome OS systems also ship
with an input_handler boost that powers up the GPU.
I implement the first bullet in this series, and I also compared with
some out-of-tree patches for the second, to ensure this could be useful
there too.
Past work on upstreaming a variety of Chromebook display patches got
held up for this particular feature, as there was some desire to make it
a bit more generic, for one. See the latest here:
https://lore.kernel.org/all/20180405095000.9756-25-enric.balletbo@collabora.com/
[PATCH v6 24/30] drm/rockchip: Disable PSR on input events
I significantly rewrote this to adapt it to the new common
drm_self_refresh_helpers and to add a new drm_input_helper thin library,
so I only carry my own authorship on this series.
Admittedly, this "drm_input_helper" library is barely DRM-specific at
all, except that all display- and GPU-related input-watchers are likely
to want to watch similar device behavior (unlike, say, rfkill or led
input_handler code). The approximate consensus so far seems to be that
(a) this isn't much code; if we need it for other subsystems (like,
cpufreq-boost), it's easy to implement similar logic
(b) input subsystem maintainers think the existing input_handler
abstraction is good enough
So, I keep the thin input helper in drivers/gpu/drm/.
v1: https://lore.kernel.org/all/20211103234018.4009771-1-briannorris@chromium.org/
Changes in v2:
- Honor CONFIG_INPUT dependency, via new CONFIG_DRM_INPUT_HELPER
- Remove void*; users should use container_of()
- Document the callback context
- Delay PSR re-entry, when already disabled
- Allow default configuration via Kconfig and modparam
- really CC dri-devel@...ts.freedesktop.org (oops!)
Brian Norris (2):
drm/input_helper: Add new input-handling helper
drm/self_refresh: Disable self-refresh on input events
drivers/gpu/drm/Kconfig | 22 ++++
drivers/gpu/drm/Makefile | 2 +
drivers/gpu/drm/drm_input_helper.c | 143 ++++++++++++++++++++++
drivers/gpu/drm/drm_self_refresh_helper.c | 98 ++++++++++++---
include/drm/drm_input_helper.h | 41 +++++++
5 files changed, 292 insertions(+), 14 deletions(-)
create mode 100644 drivers/gpu/drm/drm_input_helper.c
create mode 100644 include/drm/drm_input_helper.h
--
2.34.0.rc1.387.gb447b232ab-goog
Powered by blists - more mailing lists