2013-08-30 11:36:43 +00:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2013, NVIDIA Corporation. All rights reserved.
|
|
|
|
|
*
|
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sub license,
|
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
|
*
|
|
|
|
|
* The above copyright notice and this permission notice (including the
|
|
|
|
|
* next paragraph) shall be included in all copies or substantial portions
|
|
|
|
|
* of the Software.
|
|
|
|
|
*
|
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
|
|
|
|
|
* DEALINGS IN THE SOFTWARE.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef __DRM_PANEL_H__
|
|
|
|
|
#define __DRM_PANEL_H__
|
|
|
|
|
|
2019-07-18 16:14:57 +00:00
|
|
|
#include <linux/err.h>
|
2017-04-24 04:50:19 +00:00
|
|
|
#include <linux/errno.h>
|
2013-08-30 11:36:43 +00:00
|
|
|
#include <linux/list.h>
|
drm/panel: Add a way for other devices to follow panel state
These days, it's fairly common to see panels that have touchscreens
attached to them. The panel and the touchscreen can somewhat be
thought of as totally separate devices and, historically, this is how
Linux has treated them. However, treating them as separate isn't
necessarily the best way to model the two devices, it was just that
there was no better way. Specifically, there is little practical
reason to have the touchscreen powered on when the panel is turned
off, but if we model the devices separately we have no way to keep the
two devices' power states in sync with each other.
The issue described above makes it sound as if the problem here is
just about efficiency. We're wasting power keeping the touchscreen
powered up when the screen is off. While that's true, the problem can
go deeper. Specifically, hardware designers see that there's no reason
to have the touchscreen on while the screen is off and then build
hardware assuming that software would never turn the touchscreen on
while the screen is off.
In the very simplest case of hardware designs like this, the
touchscreen and the panel share some power rails. In most cases, this
turns out not to be terrible and is, again, just a little less
efficient. Specifically if we tell Linux that the touchscreen and the
panel are using the same rails then Linux will keep the rails on when
_either_ device is turned on. That ends to work OK-ish, but now if you
turn the panel off not only will the touchscreen remain powered, but
the power rails for the panel itself won't be switched off, burning
extra power.
The above two inefficiencies are _extra_ minor when you consider the
fact that laptops rarely spend much time with the screen off. The main
use case would be when an external screen (and presumably a power
supply) is attached.
Unfortunately, it gets worse from here. On sc7180-trogdor-homestar,
for instance, the display's TCON (timing controller) sometimes crashes
if you don't power cycle it whenever you stop and restart the video
stream (like during a modeset). The touchscreen keeping the power
rails on causes real problems. One proposal in the homestar timeframe
was to move the touchscreen to an always-on rail, dedicating the main
power rail to the panel. That caused _different_ problems as talked
about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the
reset line to the regulator"). The end result of all of this was to
add an extra regulator to the board, increasing cost.
Recently, Cong Yang posted a patch [1] where things are even worse.
The panel and touch controller on that system seem even more
intimately tied together and really can't be thought of separately.
To address this issue, let's start allowing devices to register
themselves as "panel followers". These devices will get called after a
panel has been powered on and before a panel is powered off. This
makes the panel the primary device in charge of the power state, which
matches how userspace uses it.
The panel follower API should be fairly straightforward to use. The
current code assumes that panel followers are using device tree and
have a "panel" property pointing to the panel to follow. More
flexibility and non-DT implementations could be added as needed.
Right now, panel followers can follow the prepare/unprepare functions.
There could be arguments made that, instead, they should follow
enable/disable. I've chosen prepare/unprepare for now since those
functions are guaranteed to power up/power down the panel and it seems
better to start the process earlier.
A bit of explaining about why this is a roll-your-own API instead of
using something more standard:
1. In standard APIs in Linux, parent devices are automatically powered
on when a child needs power. Applying that here, it would mean that
we'd force the panel on any time someone was listening to the
touchscreen. That, unfortunately, would have broken homestar's need
(if we hadn't changed the hardware, as per above) where the panel
absolutely needs to be able to power cycle itself. While one could
argue that homestar is broken hardware and we shouldn't have the
API do backflips for it, _officially_ the eDP timing guidelines
agree with homestar's needs and the panel power sequencing diagrams
show power going off. It's nice to be able to support this.
2. We could, conceibably, try to add a new flag to device_link causing
the parent to be in charge of power. Then we could at least use
normal pm_runtime APIs. This sounds great, except that we run into
problems with initial probe. As talked about in the later patch
("HID: i2c-hid: Support being a panel follower") the initial power
on of a panel follower might need to do things (like add
sub-devices) that aren't allowed in a runtime_resume function.
The above complexities explain why this API isn't using common
functions. That being said, this patch is very small and
self-contained, so if someone was later able to adapt it to using more
common APIs while solving the above issues then that could happen in
the future.
[1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid
2023-07-27 17:16:30 +00:00
|
|
|
#include <linux/mutex.h>
|
2013-08-30 11:36:43 +00:00
|
|
|
|
2019-12-07 14:03:30 +00:00
|
|
|
struct backlight_device;
|
2022-02-05 00:13:41 +00:00
|
|
|
struct dentry;
|
2017-04-24 04:50:19 +00:00
|
|
|
struct device_node;
|
2013-08-30 11:36:43 +00:00
|
|
|
struct drm_connector;
|
|
|
|
|
struct drm_device;
|
drm/panel: Add a way for other devices to follow panel state
These days, it's fairly common to see panels that have touchscreens
attached to them. The panel and the touchscreen can somewhat be
thought of as totally separate devices and, historically, this is how
Linux has treated them. However, treating them as separate isn't
necessarily the best way to model the two devices, it was just that
there was no better way. Specifically, there is little practical
reason to have the touchscreen powered on when the panel is turned
off, but if we model the devices separately we have no way to keep the
two devices' power states in sync with each other.
The issue described above makes it sound as if the problem here is
just about efficiency. We're wasting power keeping the touchscreen
powered up when the screen is off. While that's true, the problem can
go deeper. Specifically, hardware designers see that there's no reason
to have the touchscreen on while the screen is off and then build
hardware assuming that software would never turn the touchscreen on
while the screen is off.
In the very simplest case of hardware designs like this, the
touchscreen and the panel share some power rails. In most cases, this
turns out not to be terrible and is, again, just a little less
efficient. Specifically if we tell Linux that the touchscreen and the
panel are using the same rails then Linux will keep the rails on when
_either_ device is turned on. That ends to work OK-ish, but now if you
turn the panel off not only will the touchscreen remain powered, but
the power rails for the panel itself won't be switched off, burning
extra power.
The above two inefficiencies are _extra_ minor when you consider the
fact that laptops rarely spend much time with the screen off. The main
use case would be when an external screen (and presumably a power
supply) is attached.
Unfortunately, it gets worse from here. On sc7180-trogdor-homestar,
for instance, the display's TCON (timing controller) sometimes crashes
if you don't power cycle it whenever you stop and restart the video
stream (like during a modeset). The touchscreen keeping the power
rails on causes real problems. One proposal in the homestar timeframe
was to move the touchscreen to an always-on rail, dedicating the main
power rail to the panel. That caused _different_ problems as talked
about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the
reset line to the regulator"). The end result of all of this was to
add an extra regulator to the board, increasing cost.
Recently, Cong Yang posted a patch [1] where things are even worse.
The panel and touch controller on that system seem even more
intimately tied together and really can't be thought of separately.
To address this issue, let's start allowing devices to register
themselves as "panel followers". These devices will get called after a
panel has been powered on and before a panel is powered off. This
makes the panel the primary device in charge of the power state, which
matches how userspace uses it.
The panel follower API should be fairly straightforward to use. The
current code assumes that panel followers are using device tree and
have a "panel" property pointing to the panel to follow. More
flexibility and non-DT implementations could be added as needed.
Right now, panel followers can follow the prepare/unprepare functions.
There could be arguments made that, instead, they should follow
enable/disable. I've chosen prepare/unprepare for now since those
functions are guaranteed to power up/power down the panel and it seems
better to start the process earlier.
A bit of explaining about why this is a roll-your-own API instead of
using something more standard:
1. In standard APIs in Linux, parent devices are automatically powered
on when a child needs power. Applying that here, it would mean that
we'd force the panel on any time someone was listening to the
touchscreen. That, unfortunately, would have broken homestar's need
(if we hadn't changed the hardware, as per above) where the panel
absolutely needs to be able to power cycle itself. While one could
argue that homestar is broken hardware and we shouldn't have the
API do backflips for it, _officially_ the eDP timing guidelines
agree with homestar's needs and the panel power sequencing diagrams
show power going off. It's nice to be able to support this.
2. We could, conceibably, try to add a new flag to device_link causing
the parent to be in charge of power. Then we could at least use
normal pm_runtime APIs. This sounds great, except that we run into
problems with initial probe. As talked about in the later patch
("HID: i2c-hid: Support being a panel follower") the initial power
on of a panel follower might need to do things (like add
sub-devices) that aren't allowed in a runtime_resume function.
The above complexities explain why this API isn't using common
functions. That being said, this patch is very small and
self-contained, so if someone was later able to adapt it to using more
common APIs while solving the above issues then that could happen in
the future.
[1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid
2023-07-27 17:16:30 +00:00
|
|
|
struct drm_panel_follower;
|
2013-08-30 11:36:43 +00:00
|
|
|
struct drm_panel;
|
2014-12-11 17:32:44 +00:00
|
|
|
struct display_timing;
|
2013-08-30 11:36:43 +00:00
|
|
|
|
2020-08-13 21:56:06 +00:00
|
|
|
enum drm_panel_orientation;
|
|
|
|
|
|
2014-07-17 20:43:48 +00:00
|
|
|
/**
|
|
|
|
|
* struct drm_panel_funcs - perform operations on a given panel
|
|
|
|
|
*
|
|
|
|
|
* The .prepare() function is typically called before the display controller
|
|
|
|
|
* starts to transmit video data. Panel drivers can use this to turn the panel
|
|
|
|
|
* on and wait for it to become ready. If additional configuration is required
|
|
|
|
|
* (via a control bus such as I2C, SPI or DSI for example) this is a good time
|
|
|
|
|
* to do that.
|
|
|
|
|
*
|
|
|
|
|
* After the display controller has started transmitting video data, it's safe
|
|
|
|
|
* to call the .enable() function. This will typically enable the backlight to
|
|
|
|
|
* make the image on screen visible. Some panels require a certain amount of
|
|
|
|
|
* time or frames before the image is displayed. This function is responsible
|
|
|
|
|
* for taking this into account before enabling the backlight to avoid visual
|
|
|
|
|
* glitches.
|
|
|
|
|
*
|
|
|
|
|
* Before stopping video transmission from the display controller it can be
|
|
|
|
|
* necessary to turn off the panel to avoid visual glitches. This is done in
|
|
|
|
|
* the .disable() function. Analogously to .enable() this typically involves
|
|
|
|
|
* turning off the backlight and waiting for some time to make sure no image
|
|
|
|
|
* is visible on the panel. It is then safe for the display controller to
|
|
|
|
|
* cease transmission of video data.
|
|
|
|
|
*
|
|
|
|
|
* To save power when no video data is transmitted, a driver can power down
|
|
|
|
|
* the panel. This is the job of the .unprepare() function.
|
2019-12-07 14:03:30 +00:00
|
|
|
*
|
|
|
|
|
* Backlight can be handled automatically if configured using
|
2021-06-26 16:51:03 +00:00
|
|
|
* drm_panel_of_backlight() or drm_panel_dp_aux_backlight(). Then the driver
|
|
|
|
|
* does not need to implement the functionality to enable/disable backlight.
|
2014-07-17 20:43:48 +00:00
|
|
|
*/
|
2013-08-30 11:36:43 +00:00
|
|
|
struct drm_panel_funcs {
|
2019-08-04 20:16:33 +00:00
|
|
|
/**
|
|
|
|
|
* @prepare:
|
|
|
|
|
*
|
|
|
|
|
* Turn on panel and perform set up.
|
2019-12-07 14:03:29 +00:00
|
|
|
*
|
|
|
|
|
* This function is optional.
|
2019-08-04 20:16:33 +00:00
|
|
|
*/
|
2014-07-17 20:43:48 +00:00
|
|
|
int (*prepare)(struct drm_panel *panel);
|
2019-08-04 20:16:33 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @enable:
|
|
|
|
|
*
|
|
|
|
|
* Enable panel (turn on back light, etc.).
|
2019-12-07 14:03:29 +00:00
|
|
|
*
|
|
|
|
|
* This function is optional.
|
2019-08-04 20:16:33 +00:00
|
|
|
*/
|
2013-08-30 11:36:43 +00:00
|
|
|
int (*enable)(struct drm_panel *panel);
|
2019-08-04 20:16:33 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @disable:
|
|
|
|
|
*
|
|
|
|
|
* Disable panel (turn off back light, etc.).
|
2019-12-07 14:03:29 +00:00
|
|
|
*
|
|
|
|
|
* This function is optional.
|
2019-08-04 20:16:33 +00:00
|
|
|
*/
|
|
|
|
|
int (*disable)(struct drm_panel *panel);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @unprepare:
|
|
|
|
|
*
|
|
|
|
|
* Turn off panel.
|
2019-12-07 14:03:29 +00:00
|
|
|
*
|
|
|
|
|
* This function is optional.
|
2019-08-04 20:16:33 +00:00
|
|
|
*/
|
|
|
|
|
int (*unprepare)(struct drm_panel *panel);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @get_modes:
|
|
|
|
|
*
|
2019-12-07 14:03:29 +00:00
|
|
|
* Add modes to the connector that the panel is attached to
|
|
|
|
|
* and returns the number of modes added.
|
|
|
|
|
*
|
|
|
|
|
* This function is mandatory.
|
2019-08-04 20:16:33 +00:00
|
|
|
*/
|
2019-12-07 14:03:33 +00:00
|
|
|
int (*get_modes)(struct drm_panel *panel,
|
|
|
|
|
struct drm_connector *connector);
|
2019-08-04 20:16:33 +00:00
|
|
|
|
2022-06-09 07:27:15 +00:00
|
|
|
/**
|
|
|
|
|
* @get_orientation:
|
|
|
|
|
*
|
|
|
|
|
* Return the panel orientation set by device tree or EDID.
|
|
|
|
|
*
|
|
|
|
|
* This function is optional.
|
|
|
|
|
*/
|
|
|
|
|
enum drm_panel_orientation (*get_orientation)(struct drm_panel *panel);
|
|
|
|
|
|
2019-08-04 20:16:33 +00:00
|
|
|
/**
|
|
|
|
|
* @get_timings:
|
|
|
|
|
*
|
|
|
|
|
* Copy display timings into the provided array and return
|
|
|
|
|
* the number of display timings available.
|
2019-12-07 14:03:29 +00:00
|
|
|
*
|
|
|
|
|
* This function is optional.
|
2019-08-04 20:16:33 +00:00
|
|
|
*/
|
2014-12-11 17:32:44 +00:00
|
|
|
int (*get_timings)(struct drm_panel *panel, unsigned int num_timings,
|
|
|
|
|
struct display_timing *timings);
|
2022-02-05 00:13:41 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @debugfs_init:
|
|
|
|
|
*
|
|
|
|
|
* Allows panels to create panels-specific debugfs files.
|
|
|
|
|
*/
|
|
|
|
|
void (*debugfs_init)(struct drm_panel *panel, struct dentry *root);
|
2013-08-30 11:36:43 +00:00
|
|
|
};
|
|
|
|
|
|
drm/panel: Add a way for other devices to follow panel state
These days, it's fairly common to see panels that have touchscreens
attached to them. The panel and the touchscreen can somewhat be
thought of as totally separate devices and, historically, this is how
Linux has treated them. However, treating them as separate isn't
necessarily the best way to model the two devices, it was just that
there was no better way. Specifically, there is little practical
reason to have the touchscreen powered on when the panel is turned
off, but if we model the devices separately we have no way to keep the
two devices' power states in sync with each other.
The issue described above makes it sound as if the problem here is
just about efficiency. We're wasting power keeping the touchscreen
powered up when the screen is off. While that's true, the problem can
go deeper. Specifically, hardware designers see that there's no reason
to have the touchscreen on while the screen is off and then build
hardware assuming that software would never turn the touchscreen on
while the screen is off.
In the very simplest case of hardware designs like this, the
touchscreen and the panel share some power rails. In most cases, this
turns out not to be terrible and is, again, just a little less
efficient. Specifically if we tell Linux that the touchscreen and the
panel are using the same rails then Linux will keep the rails on when
_either_ device is turned on. That ends to work OK-ish, but now if you
turn the panel off not only will the touchscreen remain powered, but
the power rails for the panel itself won't be switched off, burning
extra power.
The above two inefficiencies are _extra_ minor when you consider the
fact that laptops rarely spend much time with the screen off. The main
use case would be when an external screen (and presumably a power
supply) is attached.
Unfortunately, it gets worse from here. On sc7180-trogdor-homestar,
for instance, the display's TCON (timing controller) sometimes crashes
if you don't power cycle it whenever you stop and restart the video
stream (like during a modeset). The touchscreen keeping the power
rails on causes real problems. One proposal in the homestar timeframe
was to move the touchscreen to an always-on rail, dedicating the main
power rail to the panel. That caused _different_ problems as talked
about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the
reset line to the regulator"). The end result of all of this was to
add an extra regulator to the board, increasing cost.
Recently, Cong Yang posted a patch [1] where things are even worse.
The panel and touch controller on that system seem even more
intimately tied together and really can't be thought of separately.
To address this issue, let's start allowing devices to register
themselves as "panel followers". These devices will get called after a
panel has been powered on and before a panel is powered off. This
makes the panel the primary device in charge of the power state, which
matches how userspace uses it.
The panel follower API should be fairly straightforward to use. The
current code assumes that panel followers are using device tree and
have a "panel" property pointing to the panel to follow. More
flexibility and non-DT implementations could be added as needed.
Right now, panel followers can follow the prepare/unprepare functions.
There could be arguments made that, instead, they should follow
enable/disable. I've chosen prepare/unprepare for now since those
functions are guaranteed to power up/power down the panel and it seems
better to start the process earlier.
A bit of explaining about why this is a roll-your-own API instead of
using something more standard:
1. In standard APIs in Linux, parent devices are automatically powered
on when a child needs power. Applying that here, it would mean that
we'd force the panel on any time someone was listening to the
touchscreen. That, unfortunately, would have broken homestar's need
(if we hadn't changed the hardware, as per above) where the panel
absolutely needs to be able to power cycle itself. While one could
argue that homestar is broken hardware and we shouldn't have the
API do backflips for it, _officially_ the eDP timing guidelines
agree with homestar's needs and the panel power sequencing diagrams
show power going off. It's nice to be able to support this.
2. We could, conceibably, try to add a new flag to device_link causing
the parent to be in charge of power. Then we could at least use
normal pm_runtime APIs. This sounds great, except that we run into
problems with initial probe. As talked about in the later patch
("HID: i2c-hid: Support being a panel follower") the initial power
on of a panel follower might need to do things (like add
sub-devices) that aren't allowed in a runtime_resume function.
The above complexities explain why this API isn't using common
functions. That being said, this patch is very small and
self-contained, so if someone was later able to adapt it to using more
common APIs while solving the above issues then that could happen in
the future.
[1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid
2023-07-27 17:16:30 +00:00
|
|
|
struct drm_panel_follower_funcs {
|
|
|
|
|
/**
|
|
|
|
|
* @panel_prepared:
|
|
|
|
|
*
|
|
|
|
|
* Called after the panel has been powered on.
|
|
|
|
|
*/
|
|
|
|
|
int (*panel_prepared)(struct drm_panel_follower *follower);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @panel_unpreparing:
|
|
|
|
|
*
|
|
|
|
|
* Called before the panel is powered off.
|
|
|
|
|
*/
|
|
|
|
|
int (*panel_unpreparing)(struct drm_panel_follower *follower);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct drm_panel_follower {
|
|
|
|
|
/**
|
|
|
|
|
* @funcs:
|
|
|
|
|
*
|
|
|
|
|
* Dependent device callbacks; should be initted by the caller.
|
|
|
|
|
*/
|
|
|
|
|
const struct drm_panel_follower_funcs *funcs;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @list
|
|
|
|
|
*
|
|
|
|
|
* Used for linking into panel's list; set by drm_panel_add_follower().
|
|
|
|
|
*/
|
|
|
|
|
struct list_head list;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @panel
|
|
|
|
|
*
|
|
|
|
|
* The panel we're dependent on; set by drm_panel_add_follower().
|
|
|
|
|
*/
|
|
|
|
|
struct drm_panel *panel;
|
|
|
|
|
};
|
|
|
|
|
|
2016-05-06 14:01:37 +00:00
|
|
|
/**
|
|
|
|
|
* struct drm_panel - DRM panel object
|
|
|
|
|
*/
|
2013-08-30 11:36:43 +00:00
|
|
|
struct drm_panel {
|
2019-08-04 20:16:33 +00:00
|
|
|
/**
|
|
|
|
|
* @dev:
|
|
|
|
|
*
|
|
|
|
|
* Parent device of the panel.
|
|
|
|
|
*/
|
2013-08-30 11:36:43 +00:00
|
|
|
struct device *dev;
|
|
|
|
|
|
2019-12-07 14:03:30 +00:00
|
|
|
/**
|
|
|
|
|
* @backlight:
|
|
|
|
|
*
|
|
|
|
|
* Backlight device, used to turn on backlight after the call
|
|
|
|
|
* to enable(), and to turn off backlight before the call to
|
|
|
|
|
* disable().
|
2021-06-26 16:51:03 +00:00
|
|
|
* backlight is set by drm_panel_of_backlight() or
|
|
|
|
|
* drm_panel_dp_aux_backlight() and drivers shall not assign it.
|
2019-12-07 14:03:30 +00:00
|
|
|
*/
|
|
|
|
|
struct backlight_device *backlight;
|
|
|
|
|
|
2019-08-04 20:16:33 +00:00
|
|
|
/**
|
|
|
|
|
* @funcs:
|
|
|
|
|
*
|
|
|
|
|
* Operations that can be performed on the panel.
|
|
|
|
|
*/
|
2013-08-30 11:36:43 +00:00
|
|
|
const struct drm_panel_funcs *funcs;
|
|
|
|
|
|
2019-09-04 13:28:03 +00:00
|
|
|
/**
|
|
|
|
|
* @connector_type:
|
|
|
|
|
*
|
|
|
|
|
* Type of the panel as a DRM_MODE_CONNECTOR_* value. This is used to
|
|
|
|
|
* initialise the drm_connector corresponding to the panel with the
|
|
|
|
|
* correct connector type.
|
|
|
|
|
*/
|
|
|
|
|
int connector_type;
|
|
|
|
|
|
2019-08-04 20:16:33 +00:00
|
|
|
/**
|
|
|
|
|
* @list:
|
|
|
|
|
*
|
|
|
|
|
* Panel entry in registry.
|
|
|
|
|
*/
|
2013-08-30 11:36:43 +00:00
|
|
|
struct list_head list;
|
2022-12-05 17:33:27 +00:00
|
|
|
|
drm/panel: Add a way for other devices to follow panel state
These days, it's fairly common to see panels that have touchscreens
attached to them. The panel and the touchscreen can somewhat be
thought of as totally separate devices and, historically, this is how
Linux has treated them. However, treating them as separate isn't
necessarily the best way to model the two devices, it was just that
there was no better way. Specifically, there is little practical
reason to have the touchscreen powered on when the panel is turned
off, but if we model the devices separately we have no way to keep the
two devices' power states in sync with each other.
The issue described above makes it sound as if the problem here is
just about efficiency. We're wasting power keeping the touchscreen
powered up when the screen is off. While that's true, the problem can
go deeper. Specifically, hardware designers see that there's no reason
to have the touchscreen on while the screen is off and then build
hardware assuming that software would never turn the touchscreen on
while the screen is off.
In the very simplest case of hardware designs like this, the
touchscreen and the panel share some power rails. In most cases, this
turns out not to be terrible and is, again, just a little less
efficient. Specifically if we tell Linux that the touchscreen and the
panel are using the same rails then Linux will keep the rails on when
_either_ device is turned on. That ends to work OK-ish, but now if you
turn the panel off not only will the touchscreen remain powered, but
the power rails for the panel itself won't be switched off, burning
extra power.
The above two inefficiencies are _extra_ minor when you consider the
fact that laptops rarely spend much time with the screen off. The main
use case would be when an external screen (and presumably a power
supply) is attached.
Unfortunately, it gets worse from here. On sc7180-trogdor-homestar,
for instance, the display's TCON (timing controller) sometimes crashes
if you don't power cycle it whenever you stop and restart the video
stream (like during a modeset). The touchscreen keeping the power
rails on causes real problems. One proposal in the homestar timeframe
was to move the touchscreen to an always-on rail, dedicating the main
power rail to the panel. That caused _different_ problems as talked
about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the
reset line to the regulator"). The end result of all of this was to
add an extra regulator to the board, increasing cost.
Recently, Cong Yang posted a patch [1] where things are even worse.
The panel and touch controller on that system seem even more
intimately tied together and really can't be thought of separately.
To address this issue, let's start allowing devices to register
themselves as "panel followers". These devices will get called after a
panel has been powered on and before a panel is powered off. This
makes the panel the primary device in charge of the power state, which
matches how userspace uses it.
The panel follower API should be fairly straightforward to use. The
current code assumes that panel followers are using device tree and
have a "panel" property pointing to the panel to follow. More
flexibility and non-DT implementations could be added as needed.
Right now, panel followers can follow the prepare/unprepare functions.
There could be arguments made that, instead, they should follow
enable/disable. I've chosen prepare/unprepare for now since those
functions are guaranteed to power up/power down the panel and it seems
better to start the process earlier.
A bit of explaining about why this is a roll-your-own API instead of
using something more standard:
1. In standard APIs in Linux, parent devices are automatically powered
on when a child needs power. Applying that here, it would mean that
we'd force the panel on any time someone was listening to the
touchscreen. That, unfortunately, would have broken homestar's need
(if we hadn't changed the hardware, as per above) where the panel
absolutely needs to be able to power cycle itself. While one could
argue that homestar is broken hardware and we shouldn't have the
API do backflips for it, _officially_ the eDP timing guidelines
agree with homestar's needs and the panel power sequencing diagrams
show power going off. It's nice to be able to support this.
2. We could, conceibably, try to add a new flag to device_link causing
the parent to be in charge of power. Then we could at least use
normal pm_runtime APIs. This sounds great, except that we run into
problems with initial probe. As talked about in the later patch
("HID: i2c-hid: Support being a panel follower") the initial power
on of a panel follower might need to do things (like add
sub-devices) that aren't allowed in a runtime_resume function.
The above complexities explain why this API isn't using common
functions. That being said, this patch is very small and
self-contained, so if someone was later able to adapt it to using more
common APIs while solving the above issues then that could happen in
the future.
[1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid
2023-07-27 17:16:30 +00:00
|
|
|
/**
|
|
|
|
|
* @followers:
|
|
|
|
|
*
|
|
|
|
|
* A list of struct drm_panel_follower dependent on this panel.
|
|
|
|
|
*/
|
|
|
|
|
struct list_head followers;
|
|
|
|
|
|
|
|
|
|
/**
|
2023-08-02 14:47:27 +00:00
|
|
|
* @follower_lock:
|
drm/panel: Add a way for other devices to follow panel state
These days, it's fairly common to see panels that have touchscreens
attached to them. The panel and the touchscreen can somewhat be
thought of as totally separate devices and, historically, this is how
Linux has treated them. However, treating them as separate isn't
necessarily the best way to model the two devices, it was just that
there was no better way. Specifically, there is little practical
reason to have the touchscreen powered on when the panel is turned
off, but if we model the devices separately we have no way to keep the
two devices' power states in sync with each other.
The issue described above makes it sound as if the problem here is
just about efficiency. We're wasting power keeping the touchscreen
powered up when the screen is off. While that's true, the problem can
go deeper. Specifically, hardware designers see that there's no reason
to have the touchscreen on while the screen is off and then build
hardware assuming that software would never turn the touchscreen on
while the screen is off.
In the very simplest case of hardware designs like this, the
touchscreen and the panel share some power rails. In most cases, this
turns out not to be terrible and is, again, just a little less
efficient. Specifically if we tell Linux that the touchscreen and the
panel are using the same rails then Linux will keep the rails on when
_either_ device is turned on. That ends to work OK-ish, but now if you
turn the panel off not only will the touchscreen remain powered, but
the power rails for the panel itself won't be switched off, burning
extra power.
The above two inefficiencies are _extra_ minor when you consider the
fact that laptops rarely spend much time with the screen off. The main
use case would be when an external screen (and presumably a power
supply) is attached.
Unfortunately, it gets worse from here. On sc7180-trogdor-homestar,
for instance, the display's TCON (timing controller) sometimes crashes
if you don't power cycle it whenever you stop and restart the video
stream (like during a modeset). The touchscreen keeping the power
rails on causes real problems. One proposal in the homestar timeframe
was to move the touchscreen to an always-on rail, dedicating the main
power rail to the panel. That caused _different_ problems as talked
about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the
reset line to the regulator"). The end result of all of this was to
add an extra regulator to the board, increasing cost.
Recently, Cong Yang posted a patch [1] where things are even worse.
The panel and touch controller on that system seem even more
intimately tied together and really can't be thought of separately.
To address this issue, let's start allowing devices to register
themselves as "panel followers". These devices will get called after a
panel has been powered on and before a panel is powered off. This
makes the panel the primary device in charge of the power state, which
matches how userspace uses it.
The panel follower API should be fairly straightforward to use. The
current code assumes that panel followers are using device tree and
have a "panel" property pointing to the panel to follow. More
flexibility and non-DT implementations could be added as needed.
Right now, panel followers can follow the prepare/unprepare functions.
There could be arguments made that, instead, they should follow
enable/disable. I've chosen prepare/unprepare for now since those
functions are guaranteed to power up/power down the panel and it seems
better to start the process earlier.
A bit of explaining about why this is a roll-your-own API instead of
using something more standard:
1. In standard APIs in Linux, parent devices are automatically powered
on when a child needs power. Applying that here, it would mean that
we'd force the panel on any time someone was listening to the
touchscreen. That, unfortunately, would have broken homestar's need
(if we hadn't changed the hardware, as per above) where the panel
absolutely needs to be able to power cycle itself. While one could
argue that homestar is broken hardware and we shouldn't have the
API do backflips for it, _officially_ the eDP timing guidelines
agree with homestar's needs and the panel power sequencing diagrams
show power going off. It's nice to be able to support this.
2. We could, conceibably, try to add a new flag to device_link causing
the parent to be in charge of power. Then we could at least use
normal pm_runtime APIs. This sounds great, except that we run into
problems with initial probe. As talked about in the later patch
("HID: i2c-hid: Support being a panel follower") the initial power
on of a panel follower might need to do things (like add
sub-devices) that aren't allowed in a runtime_resume function.
The above complexities explain why this API isn't using common
functions. That being said, this patch is very small and
self-contained, so if someone was later able to adapt it to using more
common APIs while solving the above issues then that could happen in
the future.
[1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid
2023-07-27 17:16:30 +00:00
|
|
|
*
|
|
|
|
|
* Lock for followers list.
|
|
|
|
|
*/
|
|
|
|
|
struct mutex follower_lock;
|
|
|
|
|
|
2022-12-05 17:33:27 +00:00
|
|
|
/**
|
|
|
|
|
* @prepare_prev_first:
|
|
|
|
|
*
|
|
|
|
|
* The previous controller should be prepared first, before the prepare
|
|
|
|
|
* for the panel is called. This is largely required for DSI panels
|
|
|
|
|
* where the DSI host controller should be initialised to LP-11 before
|
|
|
|
|
* the panel is powered up.
|
|
|
|
|
*/
|
|
|
|
|
bool prepare_prev_first;
|
drm/panel: Check for already prepared/enabled in drm_panel
In a whole pile of panel drivers, we have code to make the
prepare/unprepare/enable/disable callbacks behave as no-ops if they've
already been called. It's silly to have this code duplicated
everywhere. Add it to the core instead so that we can eventually
delete it from all the drivers. Note: to get some idea of the
duplicated code, try:
git grep 'if.*>prepared' -- drivers/gpu/drm/panel
git grep 'if.*>enabled' -- drivers/gpu/drm/panel
NOTE: arguably, the right thing to do here is actually to skip this
patch and simply remove all the extra checks from the individual
drivers. Perhaps the checks were needed at some point in time in the
past but maybe they no longer are? Certainly as we continue
transitioning over to "panel_bridge" then we expect there to be much
less variety in how these calls are made. When we're called as part of
the bridge chain, things should be pretty simple. In fact, there was
some discussion in the past about these checks [1], including a
discussion about whether the checks were needed and whether the calls
ought to be refcounted. At the time, I decided not to mess with it
because it felt too risky.
Looking closer at it now, I'm fairly certain that nothing in the
existing codebase is expecting these calls to be refcounted. The only
real question is whether someone is already doing something to ensure
prepare()/unprepare() match and enabled()/disable() match. I would say
that, even if there is something else ensuring that things match,
there's enough complexity that adding an extra bool and an extra
double-check here is a good idea. Let's add a drm_warn() to let people
know that it's considered a minor error to take advantage of
drm_panel's double-checking but we'll still make things work fine.
We'll also add an entry to the official DRM todo list to remove the
now pointless check from the panels after this patch lands and,
eventually, fixup anyone who is triggering the new warning.
[1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid
2023-07-27 17:16:29 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @prepared:
|
|
|
|
|
*
|
|
|
|
|
* If true then the panel has been prepared.
|
|
|
|
|
*/
|
|
|
|
|
bool prepared;
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @enabled:
|
|
|
|
|
*
|
|
|
|
|
* If true then the panel has been enabled.
|
|
|
|
|
*/
|
|
|
|
|
bool enabled;
|
2013-08-30 11:36:43 +00:00
|
|
|
};
|
|
|
|
|
|
2019-08-23 19:32:43 +00:00
|
|
|
void drm_panel_init(struct drm_panel *panel, struct device *dev,
|
2019-09-04 13:28:03 +00:00
|
|
|
const struct drm_panel_funcs *funcs,
|
|
|
|
|
int connector_type);
|
2013-08-30 11:36:43 +00:00
|
|
|
|
2020-08-01 12:02:13 +00:00
|
|
|
void drm_panel_add(struct drm_panel *panel);
|
2013-08-30 11:36:43 +00:00
|
|
|
void drm_panel_remove(struct drm_panel *panel);
|
|
|
|
|
|
2019-08-04 20:16:32 +00:00
|
|
|
int drm_panel_prepare(struct drm_panel *panel);
|
|
|
|
|
int drm_panel_unprepare(struct drm_panel *panel);
|
|
|
|
|
|
|
|
|
|
int drm_panel_enable(struct drm_panel *panel);
|
|
|
|
|
int drm_panel_disable(struct drm_panel *panel);
|
|
|
|
|
|
2019-12-07 14:03:34 +00:00
|
|
|
int drm_panel_get_modes(struct drm_panel *panel, struct drm_connector *connector);
|
2019-08-04 20:16:32 +00:00
|
|
|
|
2017-03-22 13:26:04 +00:00
|
|
|
#if defined(CONFIG_OF) && defined(CONFIG_DRM_PANEL)
|
2016-11-19 03:28:05 +00:00
|
|
|
struct drm_panel *of_drm_find_panel(const struct device_node *np);
|
2020-08-13 21:56:06 +00:00
|
|
|
int of_drm_get_panel_orientation(const struct device_node *np,
|
|
|
|
|
enum drm_panel_orientation *orientation);
|
2013-08-30 11:36:43 +00:00
|
|
|
#else
|
2016-11-19 03:28:05 +00:00
|
|
|
static inline struct drm_panel *of_drm_find_panel(const struct device_node *np)
|
2013-08-30 11:36:43 +00:00
|
|
|
{
|
2018-05-09 13:00:39 +00:00
|
|
|
return ERR_PTR(-ENODEV);
|
2013-08-30 11:36:43 +00:00
|
|
|
}
|
2020-08-13 21:56:06 +00:00
|
|
|
|
|
|
|
|
static inline int of_drm_get_panel_orientation(const struct device_node *np,
|
|
|
|
|
enum drm_panel_orientation *orientation)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
2013-08-30 11:36:43 +00:00
|
|
|
#endif
|
|
|
|
|
|
drm/panel: Add a way for other devices to follow panel state
These days, it's fairly common to see panels that have touchscreens
attached to them. The panel and the touchscreen can somewhat be
thought of as totally separate devices and, historically, this is how
Linux has treated them. However, treating them as separate isn't
necessarily the best way to model the two devices, it was just that
there was no better way. Specifically, there is little practical
reason to have the touchscreen powered on when the panel is turned
off, but if we model the devices separately we have no way to keep the
two devices' power states in sync with each other.
The issue described above makes it sound as if the problem here is
just about efficiency. We're wasting power keeping the touchscreen
powered up when the screen is off. While that's true, the problem can
go deeper. Specifically, hardware designers see that there's no reason
to have the touchscreen on while the screen is off and then build
hardware assuming that software would never turn the touchscreen on
while the screen is off.
In the very simplest case of hardware designs like this, the
touchscreen and the panel share some power rails. In most cases, this
turns out not to be terrible and is, again, just a little less
efficient. Specifically if we tell Linux that the touchscreen and the
panel are using the same rails then Linux will keep the rails on when
_either_ device is turned on. That ends to work OK-ish, but now if you
turn the panel off not only will the touchscreen remain powered, but
the power rails for the panel itself won't be switched off, burning
extra power.
The above two inefficiencies are _extra_ minor when you consider the
fact that laptops rarely spend much time with the screen off. The main
use case would be when an external screen (and presumably a power
supply) is attached.
Unfortunately, it gets worse from here. On sc7180-trogdor-homestar,
for instance, the display's TCON (timing controller) sometimes crashes
if you don't power cycle it whenever you stop and restart the video
stream (like during a modeset). The touchscreen keeping the power
rails on causes real problems. One proposal in the homestar timeframe
was to move the touchscreen to an always-on rail, dedicating the main
power rail to the panel. That caused _different_ problems as talked
about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the
reset line to the regulator"). The end result of all of this was to
add an extra regulator to the board, increasing cost.
Recently, Cong Yang posted a patch [1] where things are even worse.
The panel and touch controller on that system seem even more
intimately tied together and really can't be thought of separately.
To address this issue, let's start allowing devices to register
themselves as "panel followers". These devices will get called after a
panel has been powered on and before a panel is powered off. This
makes the panel the primary device in charge of the power state, which
matches how userspace uses it.
The panel follower API should be fairly straightforward to use. The
current code assumes that panel followers are using device tree and
have a "panel" property pointing to the panel to follow. More
flexibility and non-DT implementations could be added as needed.
Right now, panel followers can follow the prepare/unprepare functions.
There could be arguments made that, instead, they should follow
enable/disable. I've chosen prepare/unprepare for now since those
functions are guaranteed to power up/power down the panel and it seems
better to start the process earlier.
A bit of explaining about why this is a roll-your-own API instead of
using something more standard:
1. In standard APIs in Linux, parent devices are automatically powered
on when a child needs power. Applying that here, it would mean that
we'd force the panel on any time someone was listening to the
touchscreen. That, unfortunately, would have broken homestar's need
(if we hadn't changed the hardware, as per above) where the panel
absolutely needs to be able to power cycle itself. While one could
argue that homestar is broken hardware and we shouldn't have the
API do backflips for it, _officially_ the eDP timing guidelines
agree with homestar's needs and the panel power sequencing diagrams
show power going off. It's nice to be able to support this.
2. We could, conceibably, try to add a new flag to device_link causing
the parent to be in charge of power. Then we could at least use
normal pm_runtime APIs. This sounds great, except that we run into
problems with initial probe. As talked about in the later patch
("HID: i2c-hid: Support being a panel follower") the initial power
on of a panel follower might need to do things (like add
sub-devices) that aren't allowed in a runtime_resume function.
The above complexities explain why this API isn't using common
functions. That being said, this patch is very small and
self-contained, so if someone was later able to adapt it to using more
common APIs while solving the above issues then that could happen in
the future.
[1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid
2023-07-27 17:16:30 +00:00
|
|
|
#if defined(CONFIG_DRM_PANEL)
|
|
|
|
|
bool drm_is_panel_follower(struct device *dev);
|
|
|
|
|
int drm_panel_add_follower(struct device *follower_dev,
|
|
|
|
|
struct drm_panel_follower *follower);
|
|
|
|
|
void drm_panel_remove_follower(struct drm_panel_follower *follower);
|
|
|
|
|
int devm_drm_panel_add_follower(struct device *follower_dev,
|
|
|
|
|
struct drm_panel_follower *follower);
|
|
|
|
|
#else
|
|
|
|
|
static inline bool drm_is_panel_follower(struct device *dev)
|
|
|
|
|
{
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int drm_panel_add_follower(struct device *follower_dev,
|
|
|
|
|
struct drm_panel_follower *follower)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void drm_panel_remove_follower(struct drm_panel_follower *follower) { }
|
|
|
|
|
static inline int devm_drm_panel_add_follower(struct device *follower_dev,
|
|
|
|
|
struct drm_panel_follower *follower)
|
|
|
|
|
{
|
|
|
|
|
return -ENODEV;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2020-01-07 20:32:19 +00:00
|
|
|
#if IS_ENABLED(CONFIG_DRM_PANEL) && (IS_BUILTIN(CONFIG_BACKLIGHT_CLASS_DEVICE) || \
|
|
|
|
|
(IS_MODULE(CONFIG_DRM) && IS_MODULE(CONFIG_BACKLIGHT_CLASS_DEVICE)))
|
2019-12-07 14:03:30 +00:00
|
|
|
int drm_panel_of_backlight(struct drm_panel *panel);
|
|
|
|
|
#else
|
|
|
|
|
static inline int drm_panel_of_backlight(struct drm_panel *panel)
|
|
|
|
|
{
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
|
2013-08-30 11:36:43 +00:00
|
|
|
#endif
|