Searched hist:"3235 b0f2" (Results 1 – 2 of 2) sorted by relevance
| /openbmc/linux/drivers/gpu/drm/panel/ |
| H A D | Kconfig | 3235b0f2 Fri Apr 16 17:39:30 CDT 2021 Douglas Anderson <dianders@chromium.org> drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare
Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms before the panel will assert HPD
(AKA "panel ready"). The above means that we should avoid turning a
panel off if we're going to turn it on again shortly.
The above becomes a problem when we want to read the EDID of a
panel. The way that ordering works is that userspace wants to read the
EDID of the panel _before_ fully enabling it so that it can set the
initial mode correctly. However, we can't read the EDID until we power
it up. This leads to code that does this dance (like
ps8640_bridge_get_edid()):
1. When userspace requests EDID / the panel modes (through an ioctl),
we power on the panel just enough to read the EDID and then power
it off.
2. Userspace then turns the panel on.
There's likely not much time between step #1 and #2 and so we want to
avoid powering the panel off and on again between those two steps.
Let's use Runtime PM to help us. We'll move the existing prepare() and
unprepare() to be runtime resume() and runtime suspend(). Now when we
want to prepare() or unprepare() we just increment or decrement the
refcount. We'll default to a 1 second autosuspend delay which seems
sane given the typical delays we see for panels.
A few notes:
- It seems the existing unprepare() and prepare() are defined to be
no-ops if called extra times. We'll preserve that behavior but may
try to remove it in a future patch.
- This is a slight change in the ABI of simple panel. If something was
absolutely relying on the unprepare() to happen instantly that
simply won't be the case anymore. I'm not aware of anyone relying on
that behavior, but if there is someone then we'll need to figure out
how to enable (or disable) this new delayed behavior selectively.
- In order for this to work we now have a hard dependency on
"PM". From memory this is a legit thing to assume these days and we
don't have to find some fallback to keep working if someone wants to
build their system without "PM".
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid
|
| H A D | panel-simple.c | 3235b0f2 Fri Apr 16 17:39:30 CDT 2021 Douglas Anderson <dianders@chromium.org> drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare
Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms before the panel will assert HPD
(AKA "panel ready"). The above means that we should avoid turning a
panel off if we're going to turn it on again shortly.
The above becomes a problem when we want to read the EDID of a
panel. The way that ordering works is that userspace wants to read the
EDID of the panel _before_ fully enabling it so that it can set the
initial mode correctly. However, we can't read the EDID until we power
it up. This leads to code that does this dance (like
ps8640_bridge_get_edid()):
1. When userspace requests EDID / the panel modes (through an ioctl),
we power on the panel just enough to read the EDID and then power
it off.
2. Userspace then turns the panel on.
There's likely not much time between step #1 and #2 and so we want to
avoid powering the panel off and on again between those two steps.
Let's use Runtime PM to help us. We'll move the existing prepare() and
unprepare() to be runtime resume() and runtime suspend(). Now when we
want to prepare() or unprepare() we just increment or decrement the
refcount. We'll default to a 1 second autosuspend delay which seems
sane given the typical delays we see for panels.
A few notes:
- It seems the existing unprepare() and prepare() are defined to be
no-ops if called extra times. We'll preserve that behavior but may
try to remove it in a future patch.
- This is a slight change in the ABI of simple panel. If something was
absolutely relying on the unprepare() to happen instantly that
simply won't be the case anymore. I'm not aware of anyone relying on
that behavior, but if there is someone then we'll need to figure out
how to enable (or disable) this new delayed behavior selectively.
- In order for this to work we now have a hard dependency on
"PM". From memory this is a legit thing to assume these days and we
don't have to find some fallback to keep working if someone wants to
build their system without "PM".
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.7.I9e8bd33b49c496745bfac58ea9ab418bd3b6f5ce@changeid
|