[v7 0/5] drm: Support basic DPCD backlight in panel-simple and add a new panel ATNA33XC20
This series adds the support for the eDP panel that needs the backlight controlling over the DP AUX channel using DPCD registers of the panel as per the VESA's standard.
This series also adds support for the Samsung eDP AMOLED panel that needs DP AUX to control the backlight, and introduces new delays in the @panel_desc.delay to support this panel.
This patch series depends on the following two series: - Doug's series [1], exposed the DP AUX channel to the panel-simple. - Lyude's series [2], introduced new drm helper functions for DPCD backlight.
This series is the logical successor to the series [3].
Changes in v1: - Created dpcd backlight helper with very basic functionality, added backlight registration in the ti-sn65dsi86 bridge driver.
Changes in v2: - Created a new DisplayPort aux backlight driver and moved the code from drm_dp_aux_backlight.c (v1) to the new driver.
Changes in v3: - Fixed module compilation (kernel test bot).
Changes in v4: - Added basic DPCD backlight support in panel-simple. - Added support for a new Samsung panel ATNA33XC20 that needs DPCD backlight controlling and has a requirement of delays between enable GPIO and regulator.
Changes in v5: Addressed review suggestions from Douglas: - Created a new API drm_panel_dp_aux_backlight() in drm_panel.c - Moved DP AUX backlight functions from panel-simple.c to drm_panel.c - panel-simple probe() calls drm_panel_dp_aux_backlight() to create backlight when the backlight phandle is not specified in panel DT and DP AUX channel is present. - Added check for drm_edp_backlight_supported() before registering. - Removed the @uses_dpcd_backlight flag from panel_desc as this should be auto-detected. - Updated comments/descriptions.
Changes in v6: - Rebased - Updated wanrning messages, fixed word wrapping in comments. - Fixed ordering of memory allocation
Changes in v7: - Updated the disable_to_power_off and power_to_enable panel delays as discovered at https://crrev.com/c/2966167 (Douglas)
[1] https://lore.kernel.org/dri-devel/20210525000159.3384921-1-dianders@chromium... [2] https://lore.kernel.org/dri-devel/20210514181504.565252-1-lyude@redhat.com/ [3] https://lore.kernel.org/dri-devel/1619416756-3533-1-git-send-email-rajeevny@...
Rajeev Nandan (5): drm/panel: add basic DP AUX backlight support drm/panel-simple: Support DP AUX backlight drm/panel-simple: Support for delays between GPIO & regulator dt-bindings: display: simple: Add Samsung ATNA33XC20 drm/panel-simple: Add Samsung ATNA33XC20
.../bindings/display/panel/panel-simple.yaml | 2 + drivers/gpu/drm/drm_panel.c | 108 +++++++++++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 67 +++++++++++++ include/drm/drm_panel.h | 15 ++- 4 files changed, 188 insertions(+), 4 deletions(-)
Some panels support backlight control over DP AUX channel using VESA's standard backlight control interface. Using new DRM eDP backlight helpers, add support to create and register a backlight for those panels in drm_panel to simplify the panel drivers.
The panel driver with access to "struct drm_dp_aux" can create and register a backlight device using following code snippet in its probe() function:
err = drm_panel_dp_aux_backlight(panel, aux); if (err) return err;
Then drm_panel will handle backlight_(enable|disable) calls similar to the case when drm_panel_of_backlight() is used.
Currently, we are not supporting one feature where the source device can combine the backlight brightness levels set through DP AUX and the BL_PWM_DIM eDP connector pin. Since it's not required for the basic backlight controls, it can be added later.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org Reviewed-by: Lyude Paul lyude@redhat.com ---
(no changes since v6)
Changes in v5: - New
Changes in v6: - Fixed ordering of memory allocation (Douglas) - Updated word wrapping in a comment (Douglas)
drivers/gpu/drm/drm_panel.c | 108 ++++++++++++++++++++++++++++++++++++++++++++ include/drm/drm_panel.h | 15 ++++-- 2 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c index f634371..9e65342 100644 --- a/drivers/gpu/drm/drm_panel.c +++ b/drivers/gpu/drm/drm_panel.c @@ -26,12 +26,20 @@ #include <linux/module.h>
#include <drm/drm_crtc.h> +#include <drm/drm_dp_helper.h> #include <drm/drm_panel.h> #include <drm/drm_print.h>
static DEFINE_MUTEX(panel_lock); static LIST_HEAD(panel_list);
+struct dp_aux_backlight { + struct backlight_device *base; + struct drm_dp_aux *aux; + struct drm_edp_backlight_info info; + bool enabled; +}; + /** * DOC: drm panel * @@ -342,6 +350,106 @@ int drm_panel_of_backlight(struct drm_panel *panel) return 0; } EXPORT_SYMBOL(drm_panel_of_backlight); + +static int dp_aux_backlight_update_status(struct backlight_device *bd) +{ + struct dp_aux_backlight *bl = bl_get_data(bd); + u16 brightness = backlight_get_brightness(bd); + int ret = 0; + + if (brightness > 0) { + if (!bl->enabled) { + drm_edp_backlight_enable(bl->aux, &bl->info, brightness); + bl->enabled = true; + return 0; + } + ret = drm_edp_backlight_set_level(bl->aux, &bl->info, brightness); + } else { + if (bl->enabled) { + drm_edp_backlight_disable(bl->aux, &bl->info); + bl->enabled = false; + } + } + + return ret; +} + +static const struct backlight_ops dp_aux_bl_ops = { + .update_status = dp_aux_backlight_update_status, +}; + +/** + * drm_panel_dp_aux_backlight - create and use DP AUX backlight + * @panel: DRM panel + * @aux: The DP AUX channel to use + * + * Use this function to create and handle backlight if your panel + * supports backlight control over DP AUX channel using DPCD + * registers as per VESA's standard backlight control interface. + * + * When the panel is enabled backlight will be enabled after a + * successful call to &drm_panel_funcs.enable() + * + * When the panel is disabled backlight will be disabled before the + * call to &drm_panel_funcs.disable(). + * + * A typical implementation for a panel driver supporting backlight + * control over DP AUX will call this function at probe time. + * Backlight will then be handled transparently without requiring + * any intervention from the driver. + * + * drm_panel_dp_aux_backlight() must be called after the call to drm_panel_init(). + * + * Return: 0 on success or a negative error code on failure. + */ +int drm_panel_dp_aux_backlight(struct drm_panel *panel, struct drm_dp_aux *aux) +{ + struct dp_aux_backlight *bl; + struct backlight_properties props = { 0 }; + u16 current_level; + u8 current_mode; + u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; + int ret; + + if (!panel || !panel->dev || !aux) + return -EINVAL; + + ret = drm_dp_dpcd_read(aux, DP_EDP_DPCD_REV, edp_dpcd, + EDP_DISPLAY_CTL_CAP_SIZE); + if (ret < 0) + return ret; + + if (!drm_edp_backlight_supported(edp_dpcd)) { + DRM_DEV_INFO(panel->dev, "DP AUX backlight is not supported\n"); + return 0; + } + + bl = devm_kzalloc(panel->dev, sizeof(*bl), GFP_KERNEL); + if (!bl) + return -ENOMEM; + + bl->aux = aux; + + ret = drm_edp_backlight_init(aux, &bl->info, 0, edp_dpcd, + ¤t_level, ¤t_mode); + if (ret < 0) + return ret; + + props.type = BACKLIGHT_RAW; + props.brightness = current_level; + props.max_brightness = bl->info.max; + + bl->base = devm_backlight_device_register(panel->dev, "dp_aux_backlight", + panel->dev, bl, + &dp_aux_bl_ops, &props); + if (IS_ERR(bl->base)) + return PTR_ERR(bl->base); + + panel->backlight = bl->base; + + return 0; +} +EXPORT_SYMBOL(drm_panel_dp_aux_backlight); #endif
MODULE_AUTHOR("Thierry Reding treding@nvidia.com"); diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h index 33605c3..3ebfaa6 100644 --- a/include/drm/drm_panel.h +++ b/include/drm/drm_panel.h @@ -32,6 +32,7 @@ struct backlight_device; struct device_node; struct drm_connector; struct drm_device; +struct drm_dp_aux; struct drm_panel; struct display_timing;
@@ -64,8 +65,8 @@ enum drm_panel_orientation; * the panel. This is the job of the .unprepare() function. * * Backlight can be handled automatically if configured using - * drm_panel_of_backlight(). Then the driver does not need to implement the - * functionality to enable/disable backlight. + * drm_panel_of_backlight() or drm_panel_dp_aux_backlight(). Then the driver + * does not need to implement the functionality to enable/disable backlight. */ struct drm_panel_funcs { /** @@ -144,8 +145,8 @@ struct drm_panel { * Backlight device, used to turn on backlight after the call * to enable(), and to turn off backlight before the call to * disable(). - * backlight is set by drm_panel_of_backlight() and drivers - * shall not assign it. + * backlight is set by drm_panel_of_backlight() or + * drm_panel_dp_aux_backlight() and drivers shall not assign it. */ struct backlight_device *backlight;
@@ -208,11 +209,17 @@ static inline int of_drm_get_panel_orientation(const struct device_node *np, #if IS_ENABLED(CONFIG_DRM_PANEL) && (IS_BUILTIN(CONFIG_BACKLIGHT_CLASS_DEVICE) || \ (IS_MODULE(CONFIG_DRM) && IS_MODULE(CONFIG_BACKLIGHT_CLASS_DEVICE))) int drm_panel_of_backlight(struct drm_panel *panel); +int drm_panel_dp_aux_backlight(struct drm_panel *panel, struct drm_dp_aux *aux); #else static inline int drm_panel_of_backlight(struct drm_panel *panel) { return 0; } +static inline int drm_panel_dp_aux_backlight(struct drm_panel *panel, + struct drm_dp_aux *aux) +{ + return 0; +} #endif
#endif
Hi Rajeev
On Sat, Jun 19, 2021 at 04:10:26PM +0530, Rajeev Nandan wrote:
Some panels support backlight control over DP AUX channel using VESA's standard backlight control interface. Using new DRM eDP backlight helpers, add support to create and register a backlight for those panels in drm_panel to simplify the panel drivers.
The panel driver with access to "struct drm_dp_aux" can create and register a backlight device using following code snippet in its probe() function:
err = drm_panel_dp_aux_backlight(panel, aux); if (err) return err;
IT very good to have this supported by drm_panel, so we avoid bolierplate in various drivers.
Then drm_panel will handle backlight_(enable|disable) calls similar to the case when drm_panel_of_backlight() is used.
Currently, we are not supporting one feature where the source device can combine the backlight brightness levels set through DP AUX and the BL_PWM_DIM eDP connector pin. Since it's not required for the basic backlight controls, it can be added later.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org Reviewed-by: Lyude Paul lyude@redhat.com
(no changes since v6)
Changes in v5:
- New
Changes in v6:
- Fixed ordering of memory allocation (Douglas)
- Updated word wrapping in a comment (Douglas)
drivers/gpu/drm/drm_panel.c | 108 ++++++++++++++++++++++++++++++++++++++++++++ include/drm/drm_panel.h | 15 ++++-- 2 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c index f634371..9e65342 100644 --- a/drivers/gpu/drm/drm_panel.c +++ b/drivers/gpu/drm/drm_panel.c @@ -26,12 +26,20 @@ #include <linux/module.h>
#include <drm/drm_crtc.h> +#include <drm/drm_dp_helper.h> #include <drm/drm_panel.h> #include <drm/drm_print.h>
static DEFINE_MUTEX(panel_lock); static LIST_HEAD(panel_list);
+struct dp_aux_backlight {
- struct backlight_device *base;
- struct drm_dp_aux *aux;
- struct drm_edp_backlight_info info;
- bool enabled;
+};
/**
- DOC: drm panel
@@ -342,6 +350,106 @@ int drm_panel_of_backlight(struct drm_panel *panel) return 0; } EXPORT_SYMBOL(drm_panel_of_backlight);
+static int dp_aux_backlight_update_status(struct backlight_device *bd) +{
- struct dp_aux_backlight *bl = bl_get_data(bd);
- u16 brightness = backlight_get_brightness(bd);
backlight_get_brightness() returns an int, so using u16 seems wrong. But then drm_edp_backlight_enable() uses u16 for level - so I guess it is OK. We use unsigned long, int, u16 for brightness. Looks like something one could look at one day, but today is not that day.
- int ret = 0;
- if (brightness > 0) {
Use backlight_is_blank(bd) here, as this is really what you test for.
I cannot see why you need the extra check on ->enabled? Would it be sufficient to check backlight_is_blank() only?
if (!bl->enabled) {drm_edp_backlight_enable(bl->aux, &bl->info, brightness);bl->enabled = true;return 0;}ret = drm_edp_backlight_set_level(bl->aux, &bl->info, brightness);- } else {
if (bl->enabled) {drm_edp_backlight_disable(bl->aux, &bl->info);bl->enabled = false;}- }
- return ret;
+}
Sam
Hi Sam,
On 20-06-2021 15:01, Sam Ravnborg wrote:
Hi Rajeev
On Sat, Jun 19, 2021 at 04:10:26PM +0530, Rajeev Nandan wrote:
Some panels support backlight control over DP AUX channel using VESA's standard backlight control interface. Using new DRM eDP backlight helpers, add support to create and register a backlight for those panels in drm_panel to simplify the panel drivers.
The panel driver with access to "struct drm_dp_aux" can create and register a backlight device using following code snippet in its probe() function:
err = drm_panel_dp_aux_backlight(panel, aux); if (err) return err;
IT very good to have this supported by drm_panel, so we avoid bolierplate in various drivers.
Then drm_panel will handle backlight_(enable|disable) calls similar to the case when drm_panel_of_backlight() is used.
Currently, we are not supporting one feature where the source device can combine the backlight brightness levels set through DP AUX and the BL_PWM_DIM eDP connector pin. Since it's not required for the basic backlight controls, it can be added later.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org Reviewed-by: Lyude Paul lyude@redhat.com
(no changes since v6)
Changes in v5:
- New
Changes in v6:
- Fixed ordering of memory allocation (Douglas)
- Updated word wrapping in a comment (Douglas)
drivers/gpu/drm/drm_panel.c | 108 ++++++++++++++++++++++++++++++++++++++++++++ include/drm/drm_panel.h | 15 ++++-- 2 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c index f634371..9e65342 100644 --- a/drivers/gpu/drm/drm_panel.c +++ b/drivers/gpu/drm/drm_panel.c @@ -26,12 +26,20 @@ #include <linux/module.h>
#include <drm/drm_crtc.h> +#include <drm/drm_dp_helper.h> #include <drm/drm_panel.h> #include <drm/drm_print.h>
static DEFINE_MUTEX(panel_lock); static LIST_HEAD(panel_list);
+struct dp_aux_backlight {
- struct backlight_device *base;
- struct drm_dp_aux *aux;
- struct drm_edp_backlight_info info;
- bool enabled;
+};
/**
- DOC: drm panel
@@ -342,6 +350,106 @@ int drm_panel_of_backlight(struct drm_panel *panel) return 0; } EXPORT_SYMBOL(drm_panel_of_backlight);
+static int dp_aux_backlight_update_status(struct backlight_device *bd) +{
- struct dp_aux_backlight *bl = bl_get_data(bd);
- u16 brightness = backlight_get_brightness(bd);
backlight_get_brightness() returns an int, so using u16 seems wrong. But then drm_edp_backlight_enable() uses u16 for level - so I guess it is OK. We use unsigned long, int, u16 for brightness. Looks like something one could look at one day, but today is not that day.
- int ret = 0;
- if (brightness > 0) {
Use backlight_is_blank(bd) here, as this is really what you test for.
The backlight_get_brightness() used above has the backlight_is_blank() check and returns brightness 0 when the backlight_is_blank(bd) is true. So, instead of calling backlight_is_blank(bd), we are checking brightness value here. I took the reference from pwm_backlight_update_status() of the PWM backlight driver (drivers/video/backlight/pwm_bl.c)
Yes, we can change this _if_ condition to use backlight_is_blank(bd), as this is an inline function, and is more meaningful. With this, there would be one change in the behavior of _backlight_update_status function in the following case:
- Setting brightness=0 when the backlight is not blank: In the current case setting brightness=0 is disabling the backlight. In the new case, setting brightness=0 will set the brightness to 0 and will do nothing to backlight disable.
I think that should not be a problem?
I cannot see why you need the extra check on ->enabled? Would it be sufficient to check backlight_is_blank() only?
This extra check on bl->enabled flag is added to avoid enabling/disabling backlight again if it is already enabled/disabled. Using this flag way can know the transition between backlight blank and un-blank, and decide when to enable/disable the backlight.
if (!bl->enabled) {drm_edp_backlight_enable(bl->aux, &bl->info, brightness);bl->enabled = true;return 0;}ret = drm_edp_backlight_set_level(bl->aux, &bl->info, brightness);- } else {
if (bl->enabled) {drm_edp_backlight_disable(bl->aux, &bl->info);bl->enabled = false;}- }
- return ret;
+}
Sam
Thanks, Rajeev
Hi Rajeev,
On Mon, Jun 21, 2021 at 02:08:17PM +0530, rajeevny@codeaurora.org wrote:
Hi Sam,
On 20-06-2021 15:01, Sam Ravnborg wrote:
Hi Rajeev
On Sat, Jun 19, 2021 at 04:10:26PM +0530, Rajeev Nandan wrote:
Some panels support backlight control over DP AUX channel using VESA's standard backlight control interface. Using new DRM eDP backlight helpers, add support to create and register a backlight for those panels in drm_panel to simplify the panel drivers.
The panel driver with access to "struct drm_dp_aux" can create and register a backlight device using following code snippet in its probe() function:
err = drm_panel_dp_aux_backlight(panel, aux); if (err) return err;
IT very good to have this supported by drm_panel, so we avoid bolierplate in various drivers.
Then drm_panel will handle backlight_(enable|disable) calls similar to the case when drm_panel_of_backlight() is used.
Currently, we are not supporting one feature where the source device can combine the backlight brightness levels set through DP AUX and the BL_PWM_DIM eDP connector pin. Since it's not required for the basic backlight controls, it can be added later.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org Reviewed-by: Lyude Paul lyude@redhat.com
(no changes since v6)
Changes in v5:
- New
Changes in v6:
- Fixed ordering of memory allocation (Douglas)
- Updated word wrapping in a comment (Douglas)
drivers/gpu/drm/drm_panel.c | 108 ++++++++++++++++++++++++++++++++++++++++++++ include/drm/drm_panel.h | 15 ++++-- 2 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c index f634371..9e65342 100644 --- a/drivers/gpu/drm/drm_panel.c +++ b/drivers/gpu/drm/drm_panel.c @@ -26,12 +26,20 @@ #include <linux/module.h>
#include <drm/drm_crtc.h> +#include <drm/drm_dp_helper.h> #include <drm/drm_panel.h> #include <drm/drm_print.h>
static DEFINE_MUTEX(panel_lock); static LIST_HEAD(panel_list);
+struct dp_aux_backlight {
- struct backlight_device *base;
- struct drm_dp_aux *aux;
- struct drm_edp_backlight_info info;
- bool enabled;
+};
/**
- DOC: drm panel
@@ -342,6 +350,106 @@ int drm_panel_of_backlight(struct drm_panel *panel) return 0; } EXPORT_SYMBOL(drm_panel_of_backlight);
+static int dp_aux_backlight_update_status(struct backlight_device *bd) +{
- struct dp_aux_backlight *bl = bl_get_data(bd);
- u16 brightness = backlight_get_brightness(bd);
backlight_get_brightness() returns an int, so using u16 seems wrong. But then drm_edp_backlight_enable() uses u16 for level - so I guess it is OK. We use unsigned long, int, u16 for brightness. Looks like something one could look at one day, but today is not that day.
- int ret = 0;
- if (brightness > 0) {
Use backlight_is_blank(bd) here, as this is really what you test for.
The backlight_get_brightness() used above has the backlight_is_blank() check and returns brightness 0 when the backlight_is_blank(bd) is true. So, instead of calling backlight_is_blank(bd), we are checking brightness value here. I took the reference from pwm_backlight_update_status() of the PWM backlight driver (drivers/video/backlight/pwm_bl.c)
Yes, we can change this _if_ condition to use backlight_is_blank(bd), as this is an inline function, and is more meaningful. With this, there would be one change in the behavior of _backlight_update_status function in the following case:
- Setting brightness=0 when the backlight is not blank:
In the current case setting brightness=0 is disabling the backlight. In the new case, setting brightness=0 will set the brightness to 0 and will do nothing to backlight disable.
I think that should not be a problem?
Reading "ABI/stable/sysfs-class-backlight" does not say anything about any special bahaviour with brightness == 0. Some panels may not dim back to dark on brightness == 0, just barely readable. So in such cases doing something special on the brightness == 0 case is wrong.
I recall that some backlight drivets do not get this so it is easy to make it wrong. Unless one of the backlight people tell otherwise the safe choice is to avoid the specail handling of brightness here.
I cannot see why you need the extra check on ->enabled? Would it be sufficient to check backlight_is_blank() only?
This extra check on bl->enabled flag is added to avoid enabling/disabling backlight again if it is already enabled/disabled. Using this flag way can know the transition between backlight blank and un-blank, and decide when to enable/disable the backlight.
My point is that this should really not be needed, as it would cover up for some other bug whaere we try to do something twice that is not needed. But I am less certain here so if you think it is needed, keep it as is.
Sam
Hi,
On Mon, Jun 21, 2021 at 11:38 AM Sam Ravnborg sam@ravnborg.org wrote:
I cannot see why you need the extra check on ->enabled? Would it be sufficient to check backlight_is_blank() only?
This extra check on bl->enabled flag is added to avoid enabling/disabling backlight again if it is already enabled/disabled. Using this flag way can know the transition between backlight blank and un-blank, and decide when to enable/disable the backlight.
My point is that this should really not be needed, as it would cover up for some other bug whaere we try to do something twice that is not needed. But I am less certain here so if you think it is needed, keep it as is.
I haven't tested this myself, but I believe that it is needed. I don't think the backlight update_status() function is like an enable/disable function. I believe it can be called more than one time even while the backlight is disabled. For instance, you can see that backlight_update_status() just blindly calls through to update the status. That function can be called for a number of reasons. Perhaps Rajeev can put some printouts to confirm but I think that if the backlight is "blanked" for whatever reason and you write to sysfs and change the backlight level you'll still get called again even though the backlight is still "disabled".
-Doug
Hi,
On 23-06-2021 00:03, Doug Anderson wrote:
Hi,
On Mon, Jun 21, 2021 at 11:38 AM Sam Ravnborg sam@ravnborg.org wrote:
I cannot see why you need the extra check on ->enabled? Would it be sufficient to check backlight_is_blank() only?
This extra check on bl->enabled flag is added to avoid enabling/disabling backlight again if it is already enabled/disabled. Using this flag way can know the transition between backlight blank and un-blank, and decide when to enable/disable the backlight.
My point is that this should really not be needed, as it would cover up for some other bug whaere we try to do something twice that is not needed. But I am less certain here so if you think it is needed, keep it as is.
I haven't tested this myself, but I believe that it is needed. I don't think the backlight update_status() function is like an enable/disable function. I believe it can be called more than one time even while the backlight is disabled. For instance, you can see that backlight_update_status() just blindly calls through to update the status. That function can be called for a number of reasons. Perhaps Rajeev can put some printouts to confirm but I think that if the backlight is "blanked" for whatever reason and you write to sysfs and change the backlight level you'll still get called again even though the backlight is still "disabled".
Yes, sysfs write will always try to update the backlight even though the backlight is "blanked".
The "bl->enabled" check is also required to prevent unnecessary calls to drm_edp_backlight_enable() during every backlight level change.
To confirm this, I have added few prints in dp_aux_backlight_update_status() function and collected the logs. (Copying the code here to make the review easy)
static int dp_aux_backlight_update_status(struct backlight_device *bd) { struct dp_aux_backlight *bl = bl_get_data(bd); u16 brightness = backlight_get_brightness(bd); int ret = 0;
+ pr_err("%s: brightness %d, _is_blank %d, bl->enabled %d\n", __func__, + brightness, backlight_is_blank(bd), bl->enabled);
if (!backlight_is_blank(bd)) { if (!bl->enabled) { + pr_err("%s: enabling backlight\n", __func__); drm_edp_backlight_enable(bl->aux, &bl->info, brightness); bl->enabled = true; return 0; } ret = drm_edp_backlight_set_level(bl->aux, &bl->info, brightness); } else { if (bl->enabled) { + pr_err("%s: disabling backlight\n", __func__); drm_edp_backlight_disable(bl->aux, &bl->info); bl->enabled = false; } }
return ret; }
LOGS ====
During boot ----------- [ 4.752188] dp_aux_backlight_update_status: brightness 102, _is_blank 0, bl->enabled 0 [ 4.760447] dp_aux_backlight_update_status: enabling backlight [ 5.503866] dp_aux_backlight_update_status: brightness 102, _is_blank 0, bl->enabled 1 [ 6.897355] dp_aux_backlight_update_status: brightness 103, _is_blank 0, bl->enabled 1 [ 6.938617] dp_aux_backlight_update_status: brightness 104, _is_blank 0, bl->enabled 1 [ 6.980634] dp_aux_backlight_update_status: brightness 105, _is_blank 0, bl->enabled 1
Turning Panel OFF ----------------- localhost ~ # set_power_policy --ac_screen_dim_delay=5 --ac_screen_off_delay=10 localhost ~ #
[ 106.555140] dp_aux_backlight_update_status: brightness 145, _is_blank 0, bl->enabled 1 ... ... [ 111.679407] dp_aux_backlight_update_status: brightness 7, _is_blank 0, bl->enabled 1 [ 111.700302] dp_aux_backlight_update_status: brightness 4, _is_blank 0, bl->enabled 1 [ 111.720805] dp_aux_backlight_update_status: brightness 2, _is_blank 0, bl->enabled 1 [ 111.747486] dp_aux_backlight_update_status: brightness 0, _is_blank 1, bl->enabled 1 [ 111.755580] dp_aux_backlight_update_status: disabling backlight [ 111.792344] dp_aux_backlight_update_status: brightness 0, _is_blank 1, bl->enabled 0
Changing brightness from sysfs while panel is off -------------------------------------------------- (it will do nothing)
localhost ~ # echo 100 > /sys/class/backlight/dp_aux_backlight/brightness [ 352.754963] dp_aux_backlight_update_status: brightness 0, _is_blank 1, bl->enabled 0
localhost ~ # echo 200 > /sys/class/backlight/dp_aux_backlight/brightness [ 364.708048] dp_aux_backlight_update_status: brightness 0, _is_blank 1, bl->enabled 0
localhost ~ # echo 0 > /sys/class/backlight/dp_aux_backlight/brightness [ 378.850978] dp_aux_backlight_update_status: brightness 0, _is_blank 1, bl->enabled 0
Turning Panel ON ---------------- [ 553.381745] dp_aux_backlight_update_status: brightness 0, _is_blank 0, bl->enabled 0 [ 553.418133] dp_aux_backlight_update_status: enabling backlight [ 553.426397] dp_aux_backlight_update_status: brightness 159, _is_blank 0, bl->enabled 1
====
Thanks, Rajeev
If there is no backlight specified in the device tree and the panel has access to the DP AUX channel then create a DP AUX backlight if supported by the panel.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org ---
(no changes since v5)
This patch depends on the previous patch (2/5) of this series.
Changes in v4: - New
Changes in v5: - Address review comments and move backlight functions to drm_panel.c (Douglas) - Create and register DP AUX backlight if there is no backlight specified in the device tree and panel has the DP AUX channel. (Douglas) - The new drm_panel_dp_aux_backlight() will do the drm_edp_backlight_supported() check.
drivers/gpu/drm/panel/panel-simple.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index df6fbd1..26555ec 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -800,6 +800,12 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc, if (err) goto disable_pm_runtime;
+ if (!panel->base.backlight && panel->aux) { + err = drm_panel_dp_aux_backlight(&panel->base, panel->aux); + if (err) + goto disable_pm_runtime; + } + drm_panel_add(&panel->base);
return 0;
Some panels datasheets may specify a delay between the enable GPIO and the regulator. Support this in panel-simple.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org ---
(no changes since v6)
Changes in v4: - New
Changes in v5: - Update description (Douglas) - Warn if "power_to_enable" or "disable_to_power_off" is non-zero and panel->enable_gpio is NULL (Douglas)
Changes in v6: - Update warning message to make it more meaningful. (Douglas)
drivers/gpu/drm/panel/panel-simple.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 26555ec..86e5a45 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -133,6 +133,22 @@ struct panel_desc { unsigned int prepare_to_enable;
/** + * @delay.power_to_enable: Time for the power to enable the display on. + * + * The time (in milliseconds) to wait after powering up the display + * before asserting its enable pin. + */ + unsigned int power_to_enable; + + /** + * @delay.disable_to_power_off: Time for the disable to power the display off. + * + * The time (in milliseconds) to wait before powering off the display + * after deasserting its enable pin. + */ + unsigned int disable_to_power_off; + + /** * @delay.enable: Time for the panel to display a valid frame. * * The time (in milliseconds) that it takes for the panel to @@ -347,6 +363,10 @@ static int panel_simple_suspend(struct device *dev) struct panel_simple *p = dev_get_drvdata(dev);
gpiod_set_value_cansleep(p->enable_gpio, 0); + + if (p->desc->delay.disable_to_power_off) + msleep(p->desc->delay.disable_to_power_off); + regulator_disable(p->supply); p->unprepared_time = ktime_get();
@@ -407,6 +427,9 @@ static int panel_simple_prepare_once(struct panel_simple *p) return err; }
+ if (p->desc->delay.power_to_enable) + msleep(p->desc->delay.power_to_enable); + gpiod_set_value_cansleep(p->enable_gpio, 1);
delay = p->desc->delay.prepare; @@ -782,6 +805,11 @@ static int panel_simple_probe(struct device *dev, const struct panel_desc *desc, break; }
+ if (!panel->enable_gpio && desc->delay.disable_to_power_off) + dev_warn(dev, "Need a delay after disabling panel GPIO, but a GPIO wasn't provided\n"); + if (!panel->enable_gpio && desc->delay.power_to_enable) + dev_warn(dev, "Need a delay before enabling panel GPIO, but a GPIO wasn't provided\n"); + dev_set_drvdata(dev, panel);
/*
Add Samsung 13.3" FHD eDP AMOLED panel.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org Acked-by: Rob Herring robh@kernel.org ---
(no changes since v4)
Changes in v4: - New
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 4a0a5e1..f5acfd6 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -242,6 +242,8 @@ properties: - rocktech,rk101ii01d-ct # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel - rocktech,rk070er9427 + # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel + - samsung,atna33xc20 # Samsung 12.2" (2560x1600 pixels) TFT LCD panel - samsung,lsn122dl01-c01 # Samsung Electronics 10.1" WSVGA TFT LCD panel
Add Samsung 13.3" FHD eDP AMOLED panel.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org ---
Changes in v4: - New
Changes in v5: - Remove "uses_dpcd_backlight" property, not required now. (Douglas)
Changes in v7: - Update disable_to_power_off and power_to_enable delays. (Douglas)
drivers/gpu/drm/panel/panel-simple.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 86e5a45..4adc44a 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -3562,6 +3562,36 @@ static const struct panel_desc rocktech_rk101ii01d_ct = { .connector_type = DRM_MODE_CONNECTOR_LVDS, };
+static const struct drm_display_mode samsung_atna33xc20_mode = { + .clock = 138770, + .hdisplay = 1920, + .hsync_start = 1920 + 48, + .hsync_end = 1920 + 48 + 32, + .htotal = 1920 + 48 + 32 + 80, + .vdisplay = 1080, + .vsync_start = 1080 + 8, + .vsync_end = 1080 + 8 + 8, + .vtotal = 1080 + 8 + 8 + 16, + .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC, +}; + +static const struct panel_desc samsung_atna33xc20 = { + .modes = &samsung_atna33xc20_mode, + .num_modes = 1, + .bpc = 10, + .size = { + .width = 294, + .height = 165, + }, + .delay = { + .disable_to_power_off = 200, + .power_to_enable = 400, + .hpd_absent_delay = 200, + .unprepare = 500, + }, + .connector_type = DRM_MODE_CONNECTOR_eDP, +}; + static const struct drm_display_mode samsung_lsn122dl01_c01_mode = { .clock = 271560, .hdisplay = 2560, @@ -4563,6 +4593,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "rocktech,rk101ii01d-ct", .data = &rocktech_rk101ii01d_ct, }, { + .compatible = "samsung,atna33xc20", + .data = &samsung_atna33xc20, + }, { .compatible = "samsung,lsn122dl01-c01", .data = &samsung_lsn122dl01_c01, }, {
Hi Rajeev On Sat, Jun 19, 2021 at 04:10:30PM +0530, Rajeev Nandan wrote:
Add Samsung 13.3" FHD eDP AMOLED panel.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org
Changes in v4:
- New
Changes in v5:
- Remove "uses_dpcd_backlight" property, not required now. (Douglas)
Changes in v7:
- Update disable_to_power_off and power_to_enable delays. (Douglas)
drivers/gpu/drm/panel/panel-simple.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 86e5a45..4adc44a 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -3562,6 +3562,36 @@ static const struct panel_desc rocktech_rk101ii01d_ct = { .connector_type = DRM_MODE_CONNECTOR_LVDS, };
+static const struct drm_display_mode samsung_atna33xc20_mode = {
- .clock = 138770,
- .hdisplay = 1920,
- .hsync_start = 1920 + 48,
- .hsync_end = 1920 + 48 + 32,
- .htotal = 1920 + 48 + 32 + 80,
- .vdisplay = 1080,
- .vsync_start = 1080 + 8,
- .vsync_end = 1080 + 8 + 8,
- .vtotal = 1080 + 8 + 8 + 16,
- .flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+static const struct panel_desc samsung_atna33xc20 = {
- .modes = &samsung_atna33xc20_mode,
- .num_modes = 1,
- .bpc = 10,
- .size = {
.width = 294,.height = 165,- },
- .delay = {
.disable_to_power_off = 200,.power_to_enable = 400,.hpd_absent_delay = 200,.unprepare = 500,- },
- .connector_type = DRM_MODE_CONNECTOR_eDP,
+};
bus_format is missing. There should be a warning about this when you probe the display.
The bpc of 10 in unusual, the current code warns if bpc is neither 6 nor 8. If 10 is correct then update the code to accept bpc=10.
Sam
static const struct drm_display_mode samsung_lsn122dl01_c01_mode = { .clock = 271560, .hdisplay = 2560, @@ -4563,6 +4593,9 @@ static const struct of_device_id platform_of_match[] = { .compatible = "rocktech,rk101ii01d-ct", .data = &rocktech_rk101ii01d_ct, }, {
.compatible = "samsung,atna33xc20",.data = &samsung_atna33xc20,- }, { .compatible = "samsung,lsn122dl01-c01", .data = &samsung_lsn122dl01_c01, }, {
-- 2.7.4
Hi,
On Sun, Jun 20, 2021 at 3:01 AM Sam Ravnborg sam@ravnborg.org wrote:
Hi Rajeev On Sat, Jun 19, 2021 at 04:10:30PM +0530, Rajeev Nandan wrote:
Add Samsung 13.3" FHD eDP AMOLED panel.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org
Changes in v4:
- New
Changes in v5:
- Remove "uses_dpcd_backlight" property, not required now. (Douglas)
Changes in v7:
- Update disable_to_power_off and power_to_enable delays. (Douglas)
drivers/gpu/drm/panel/panel-simple.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 86e5a45..4adc44a 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -3562,6 +3562,36 @@ static const struct panel_desc rocktech_rk101ii01d_ct = { .connector_type = DRM_MODE_CONNECTOR_LVDS, };
+static const struct drm_display_mode samsung_atna33xc20_mode = {
.clock = 138770,.hdisplay = 1920,.hsync_start = 1920 + 48,.hsync_end = 1920 + 48 + 32,.htotal = 1920 + 48 + 32 + 80,.vdisplay = 1080,.vsync_start = 1080 + 8,.vsync_end = 1080 + 8 + 8,.vtotal = 1080 + 8 + 8 + 16,.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,+};
+static const struct panel_desc samsung_atna33xc20 = {
.modes = &samsung_atna33xc20_mode,.num_modes = 1,.bpc = 10,.size = {.width = 294,.height = 165,},.delay = {.disable_to_power_off = 200,.power_to_enable = 400,.hpd_absent_delay = 200,.unprepare = 500,},.connector_type = DRM_MODE_CONNECTOR_eDP,+};
bus_format is missing. There should be a warning about this when you probe the display.
Sam: I'm curious about the requirement of hardcoding bus_format like this for eDP panels. Most eDP panels support a variety of bits per pixel and do so dynamically. Ones I've poked at freely support 6bpp and 8bpp. Presumably this one supports both of those modes and also 10bpp. I haven't done detailed research on it, but it would also surprise me if the "bus format" for a given bpp needed to be specified for eDP. Presumably since eDP has most of the "autodetect" type features of DP then if the format needed to be accounted for that you could query the hardware?
Looking at the datasheet for the ti-sn65dsi86 MIPI-to-eDP bridge chip I see that it explicitly calls out the bus formats that it supports for the MIPI side but doesn't call out anything for eDP. That would tend to support my belief that there isn't variance on the eDP side...
Maybe the right fix is to actually change the check not to give a warning for eDP panels? ...or am I misunderstanding?
The bpc of 10 in unusual, the current code warns if bpc is neither 6 nor 8. If 10 is correct then update the code to accept bpc=10.
I'm pretty sure it's 10 based on this panel's datasheet, though this panel also accepts 8 bpc. Fixing the warning seems like a good idea to me--I wasn't aware of it.
-Doug
Hi Doug,
On Mon, Jun 21, 2021 at 08:34:51AM -0700, Doug Anderson wrote:
Hi,
On Sun, Jun 20, 2021 at 3:01 AM Sam Ravnborg sam@ravnborg.org wrote:
Hi Rajeev On Sat, Jun 19, 2021 at 04:10:30PM +0530, Rajeev Nandan wrote:
Add Samsung 13.3" FHD eDP AMOLED panel.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org
Changes in v4:
- New
Changes in v5:
- Remove "uses_dpcd_backlight" property, not required now. (Douglas)
Changes in v7:
- Update disable_to_power_off and power_to_enable delays. (Douglas)
drivers/gpu/drm/panel/panel-simple.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 86e5a45..4adc44a 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -3562,6 +3562,36 @@ static const struct panel_desc rocktech_rk101ii01d_ct = { .connector_type = DRM_MODE_CONNECTOR_LVDS, };
+static const struct drm_display_mode samsung_atna33xc20_mode = {
.clock = 138770,.hdisplay = 1920,.hsync_start = 1920 + 48,.hsync_end = 1920 + 48 + 32,.htotal = 1920 + 48 + 32 + 80,.vdisplay = 1080,.vsync_start = 1080 + 8,.vsync_end = 1080 + 8 + 8,.vtotal = 1080 + 8 + 8 + 16,.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,+};
+static const struct panel_desc samsung_atna33xc20 = {
.modes = &samsung_atna33xc20_mode,.num_modes = 1,.bpc = 10,.size = {.width = 294,.height = 165,},.delay = {.disable_to_power_off = 200,.power_to_enable = 400,.hpd_absent_delay = 200,.unprepare = 500,},.connector_type = DRM_MODE_CONNECTOR_eDP,+};
bus_format is missing. There should be a warning about this when you probe the display.
Sam: I'm curious about the requirement of hardcoding bus_format like this for eDP panels. Most eDP panels support a variety of bits per pixel and do so dynamically. Ones I've poked at freely support 6bpp and 8bpp. Presumably this one supports both of those modes and also 10bpp. I haven't done detailed research on it, but it would also surprise me if the "bus format" for a given bpp needed to be specified for eDP. Presumably since eDP has most of the "autodetect" type features of DP then if the format needed to be accounted for that you could query the hardware?
Looking at the datasheet for the ti-sn65dsi86 MIPI-to-eDP bridge chip I see that it explicitly calls out the bus formats that it supports for the MIPI side but doesn't call out anything for eDP. That would tend to support my belief that there isn't variance on the eDP side...
Maybe the right fix is to actually change the check not to give a warning for eDP panels? ...or am I misunderstanding?
I have never dived into the datasheets of eDP panels so I do not know. The checks were added based on what we had in-tree and it is no suprise if they need an update or are just plain wrong. I expect you to be in a better position to make the call here - but we should not add panels that triggers warnings so either fix the warnings or fix the panel description.
Sam
Hi,
On Mon, Jun 21, 2021 at 11:42 AM Sam Ravnborg sam@ravnborg.org wrote:
Hi Doug,
On Mon, Jun 21, 2021 at 08:34:51AM -0700, Doug Anderson wrote:
Hi,
On Sun, Jun 20, 2021 at 3:01 AM Sam Ravnborg sam@ravnborg.org wrote:
Hi Rajeev On Sat, Jun 19, 2021 at 04:10:30PM +0530, Rajeev Nandan wrote:
Add Samsung 13.3" FHD eDP AMOLED panel.
Signed-off-by: Rajeev Nandan rajeevny@codeaurora.org Reviewed-by: Douglas Anderson dianders@chromium.org
Changes in v4:
- New
Changes in v5:
- Remove "uses_dpcd_backlight" property, not required now. (Douglas)
Changes in v7:
- Update disable_to_power_off and power_to_enable delays. (Douglas)
drivers/gpu/drm/panel/panel-simple.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 86e5a45..4adc44a 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -3562,6 +3562,36 @@ static const struct panel_desc rocktech_rk101ii01d_ct = { .connector_type = DRM_MODE_CONNECTOR_LVDS, };
+static const struct drm_display_mode samsung_atna33xc20_mode = {
.clock = 138770,.hdisplay = 1920,.hsync_start = 1920 + 48,.hsync_end = 1920 + 48 + 32,.htotal = 1920 + 48 + 32 + 80,.vdisplay = 1080,.vsync_start = 1080 + 8,.vsync_end = 1080 + 8 + 8,.vtotal = 1080 + 8 + 8 + 16,.flags = DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC,+};
+static const struct panel_desc samsung_atna33xc20 = {
.modes = &samsung_atna33xc20_mode,.num_modes = 1,.bpc = 10,.size = {.width = 294,.height = 165,},.delay = {.disable_to_power_off = 200,.power_to_enable = 400,.hpd_absent_delay = 200,.unprepare = 500,},.connector_type = DRM_MODE_CONNECTOR_eDP,+};
bus_format is missing. There should be a warning about this when you probe the display.
Sam: I'm curious about the requirement of hardcoding bus_format like this for eDP panels. Most eDP panels support a variety of bits per pixel and do so dynamically. Ones I've poked at freely support 6bpp and 8bpp. Presumably this one supports both of those modes and also 10bpp. I haven't done detailed research on it, but it would also surprise me if the "bus format" for a given bpp needed to be specified for eDP. Presumably since eDP has most of the "autodetect" type features of DP then if the format needed to be accounted for that you could query the hardware?
Looking at the datasheet for the ti-sn65dsi86 MIPI-to-eDP bridge chip I see that it explicitly calls out the bus formats that it supports for the MIPI side but doesn't call out anything for eDP. That would tend to support my belief that there isn't variance on the eDP side...
Maybe the right fix is to actually change the check not to give a warning for eDP panels? ...or am I misunderstanding?
I have never dived into the datasheets of eDP panels so I do not know. The checks were added based on what we had in-tree and it is no suprise if they need an update or are just plain wrong. I expect you to be in a better position to make the call here - but we should not add panels that triggers warnings so either fix the warnings or fix the panel description.
Agreed. I'd support a patch that removes this warning for eDP panels unless someone knows that it makes sense. I haven't been able to find anything indicating that it does.
-Doug
dri-devel@lists.freedesktop.org
-
Doug Anderson -
Rajeev Nandan -
rajeevny＠codeaurora.org
-
Sam Ravnborg