All of lore.kernel.org
 help / color / mirror / Atom feed
From: rajeevny@codeaurora.org
To: Sam Ravnborg <sam@ravnborg.org>
Cc: dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org,
	freedreno@lists.freedesktop.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, thierry.reding@gmail.com,
	robdclark@gmail.com, dianders@chromium.org, lyude@redhat.com,
	jani.nikula@intel.com, robh@kernel.org,
	laurent.pinchart@ideasonboard.com, a.hajda@samsung.com,
	daniel.thompson@linaro.org, hoegsberg@chromium.org,
	abhinavk@codeaurora.org, seanpaul@chromium.org,
	kalyan_t@codeaurora.org, mkrishn@codeaurora.org,
	lee.jones@linaro.org, jingoohan1@gmail.com,
	linux-fbdev@vger.kernel.org
Subject: Re: [v7 1/5] drm/panel: add basic DP AUX backlight support
Date: Mon, 21 Jun 2021 14:08:17 +0530	[thread overview]
Message-ID: <ebf5581759daee9596c2f092ca836ecb@codeaurora.org> (raw)
In-Reply-To: <20210620093141.GA703072@ravnborg.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: rajeevny@codeaurora.org
To: Sam Ravnborg <sam@ravnborg.org>
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
	dianders@chromium.org, a.hajda@samsung.com,
	thierry.reding@gmail.com, laurent.pinchart@ideasonboard.com,
	hoegsberg@chromium.org, lee.jones@linaro.org,
	daniel.thompson@linaro.org, devicetree@vger.kernel.org,
	jani.nikula@intel.com, linux-arm-msm@vger.kernel.org,
	abhinavk@codeaurora.org, seanpaul@chromium.org,
	kalyan_t@codeaurora.org, mkrishn@codeaurora.org,
	jingoohan1@gmail.com, linux-kernel@vger.kernel.org,
	robdclark@gmail.com, freedreno@lists.freedesktop.org
Subject: Re: [v7 1/5] drm/panel: add basic DP AUX backlight support
Date: Mon, 21 Jun 2021 14:08:17 +0530	[thread overview]
Message-ID: <ebf5581759daee9596c2f092ca836ecb@codeaurora.org> (raw)
In-Reply-To: <20210620093141.GA703072@ravnborg.org>

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

  reply	other threads:[~2021-06-21  8:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-19 10:40 [v7 0/5] drm: Support basic DPCD backlight in panel-simple and add a new panel ATNA33XC20 Rajeev Nandan
2021-06-19 10:40 ` Rajeev Nandan
2021-06-19 10:40 ` [v7 1/5] drm/panel: add basic DP AUX backlight support Rajeev Nandan
2021-06-19 10:40   ` Rajeev Nandan
2021-06-20  9:31   ` Sam Ravnborg
2021-06-21  8:38     ` rajeevny [this message]
2021-06-21  8:38       ` rajeevny
2021-06-21 18:38       ` Sam Ravnborg
2021-06-22 18:33         ` Doug Anderson
2021-06-22 18:33           ` Doug Anderson
2021-06-23  6:15           ` rajeevny
2021-06-23  6:15             ` rajeevny
2021-06-19 10:40 ` [v7 2/5] drm/panel-simple: Support DP AUX backlight Rajeev Nandan
2021-06-19 10:40   ` Rajeev Nandan
2021-06-19 10:40 ` [v7 3/5] drm/panel-simple: Support for delays between GPIO & regulator Rajeev Nandan
2021-06-19 10:40   ` Rajeev Nandan
2021-06-19 10:40 ` [v7 4/5] dt-bindings: display: simple: Add Samsung ATNA33XC20 Rajeev Nandan
2021-06-19 10:40   ` Rajeev Nandan
2021-06-19 10:40 ` [v7 5/5] drm/panel-simple: " Rajeev Nandan
2021-06-19 10:40   ` Rajeev Nandan
2021-06-20 10:01   ` Sam Ravnborg
2021-06-21 15:34     ` Doug Anderson
2021-06-21 15:34       ` Doug Anderson
2021-06-21 18:41       ` Sam Ravnborg
2021-06-22 18:36         ` Doug Anderson
2021-06-22 18:36           ` Doug Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ebf5581759daee9596c2f092ca836ecb@codeaurora.org \
    --to=rajeevny@codeaurora.org \
    --cc=a.hajda@samsung.com \
    --cc=abhinavk@codeaurora.org \
    --cc=daniel.thompson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=hoegsberg@chromium.org \
    --cc=jani.nikula@intel.com \
    --cc=jingoohan1@gmail.com \
    --cc=kalyan_t@codeaurora.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=mkrishn@codeaurora.org \
    --cc=robdclark@gmail.com \
    --cc=robh@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=seanpaul@chromium.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.