All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: DRI Development <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Jingoo Han <jingoohan1@gmail.com>,
	Meghana Madhyastha <meghana.madhyastha@gmail.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states
Date: Mon, 30 Apr 2018 13:21:02 +0300	[thread overview]
Message-ID: <87o9i19er5.fsf@intel.com> (raw)
In-Reply-To: <20180425174253.4616-1-daniel.vetter@ffwll.ch>

On Wed, 25 Apr 2018, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> The backlight power state handling is supremely confusing. We have:
> - props.power, using FB_BLANK_* defines
> - props.fb_blank, using the same, but deprecated int favour of
>   props.state
> - props.state, using the BL_CORE_* defines
> - and finally a bunch of backlight drivers treat brightness == 0 as
>   off. But of course not all of them.
>
> This is way too much confusion to fix in a simple patch, but at least
> prevent more hilarity from spreading by removing the unused BL_CORE_*
> defines. I have no idea why exactly anyone would need that.
>
> Wrt the ideal state, we really just want a boolean state. The 4 power
> saving states that the fbdev subsystem uses are overkill in todays hw
> (this was only relevant for VGA and similar analog circuits like
> TV-out), the new drm atomic modeset api simplified even the uapi to a
> simple bool. And there was never a valid technical reason to have the
> intermediate fbdev power states for backlights (those really only can
> be either off or on).
>
> Cleanup motivated by Meghana's questions about all this.
>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Meghana Madhyastha <meghana.madhyastha@gmail.com>
> Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Reviewed-by: Jani Nikula <jani.nikula@intel.com>

> ---
>  include/linux/backlight.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 2baab6f3861d..1db67662bfcb 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -84,9 +84,6 @@ struct backlight_properties {
>  
>  #define BL_CORE_SUSPENDED	(1 << 0)	/* backlight is suspended */
>  #define BL_CORE_FBBLANK		(1 << 1)	/* backlight is under an fb blank event */
> -#define BL_CORE_DRIVER4		(1 << 28)	/* reserved for driver specific use */
> -#define BL_CORE_DRIVER3		(1 << 29)	/* reserved for driver specific use */
> -#define BL_CORE_DRIVER2		(1 << 30)	/* reserved for driver specific use */
>  #define BL_CORE_DRIVER1		(1 << 31)	/* reserved for driver specific use */
>  
>  };

-- 
Jani Nikula, Intel Open Source Technology Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>,
	DRI Development <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Jingoo Han <jingoohan1@gmail.com>,
	Meghana Madhyastha <meghana.madhyastha@gmail.com>,
	Daniel Vetter <daniel.vetter@intel.com>,
	Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states
Date: Mon, 30 Apr 2018 13:21:02 +0300	[thread overview]
Message-ID: <87o9i19er5.fsf@intel.com> (raw)
In-Reply-To: <20180425174253.4616-1-daniel.vetter@ffwll.ch>

On Wed, 25 Apr 2018, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> The backlight power state handling is supremely confusing. We have:
> - props.power, using FB_BLANK_* defines
> - props.fb_blank, using the same, but deprecated int favour of
>   props.state
> - props.state, using the BL_CORE_* defines
> - and finally a bunch of backlight drivers treat brightness == 0 as
>   off. But of course not all of them.
>
> This is way too much confusion to fix in a simple patch, but at least
> prevent more hilarity from spreading by removing the unused BL_CORE_*
> defines. I have no idea why exactly anyone would need that.
>
> Wrt the ideal state, we really just want a boolean state. The 4 power
> saving states that the fbdev subsystem uses are overkill in todays hw
> (this was only relevant for VGA and similar analog circuits like
> TV-out), the new drm atomic modeset api simplified even the uapi to a
> simple bool. And there was never a valid technical reason to have the
> intermediate fbdev power states for backlights (those really only can
> be either off or on).
>
> Cleanup motivated by Meghana's questions about all this.
>
> Cc: Lee Jones <lee.jones@linaro.org>
> Cc: Daniel Thompson <daniel.thompson@linaro.org>
> Cc: Jingoo Han <jingoohan1@gmail.com>
> Cc: Meghana Madhyastha <meghana.madhyastha@gmail.com>
> Acked-by: Daniel Thompson <daniel.thompson@linaro.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Reviewed-by: Jani Nikula <jani.nikula@intel.com>

> ---
>  include/linux/backlight.h | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index 2baab6f3861d..1db67662bfcb 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -84,9 +84,6 @@ struct backlight_properties {
>  
>  #define BL_CORE_SUSPENDED	(1 << 0)	/* backlight is suspended */
>  #define BL_CORE_FBBLANK		(1 << 1)	/* backlight is under an fb blank event */
> -#define BL_CORE_DRIVER4		(1 << 28)	/* reserved for driver specific use */
> -#define BL_CORE_DRIVER3		(1 << 29)	/* reserved for driver specific use */
> -#define BL_CORE_DRIVER2		(1 << 30)	/* reserved for driver specific use */
>  #define BL_CORE_DRIVER1		(1 << 31)	/* reserved for driver specific use */
>  
>  };

-- 
Jani Nikula, Intel Open Source Technology Center

  parent reply	other threads:[~2018-04-30 10:21 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 17:42 [PATCH 1/6] backlight: Nuke unused backlight.props.state states Daniel Vetter
2018-04-25 17:42 ` Daniel Vetter
2018-04-25 17:42 ` [PATCH 2/6] backlight/generic-bl: remove DRIVER1 state Daniel Vetter
2018-04-25 17:42   ` Daniel Vetter
2018-04-30 10:21   ` Jani Nikula
2018-04-30 10:21     ` Jani Nikula
2018-04-25 17:42 ` [PATCH 3/6] backlight/pandora: Stop using BL_CORE_DRIVER1 Daniel Vetter
2018-04-25 17:42   ` Daniel Vetter
2018-04-30 10:22   ` Jani Nikula
2018-04-30 10:22     ` Jani Nikula
2018-04-25 17:42 ` [PATCH 4/6] staging/fbtft: " Daniel Vetter
2018-04-25 17:42   ` Daniel Vetter
2018-04-30  9:54   ` Lee Jones
2018-04-30  9:54     ` Lee Jones
2018-04-30 10:59     ` Greg KH
2018-04-30 10:59       ` Greg KH
2018-04-30 10:22   ` Jani Nikula
2018-04-30 10:22     ` Jani Nikula
2018-04-25 17:42 ` [PATCH 5/6] backlight: Also nuke BL_CORE_DRIVER1 Daniel Vetter
2018-04-25 17:42   ` Daniel Vetter
2018-04-30 10:24   ` Jani Nikula
2018-04-30 10:24     ` Jani Nikula
2018-04-30 12:14     ` Lee Jones
2018-04-30 12:14       ` Lee Jones
2018-04-25 17:42 ` [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches Daniel Vetter
2018-04-25 19:43   ` Jingoo Han
2018-04-25 19:43     ` Jingoo Han
2018-04-25 19:42 ` [PATCH 1/6] backlight: Nuke unused backlight.props.state states Jingoo Han
2018-04-25 19:42   ` Jingoo Han
2018-04-30 10:21 ` Jani Nikula [this message]
2018-04-30 10:21   ` Jani Nikula
2018-04-30 12:27 ` Lee Jones
2018-04-30 12:27   ` Lee Jones
  -- strict thread matches above, loose matches on Subject: below --
2018-01-17 14:01 Daniel Vetter
2018-01-17 14:56 ` Daniel Thompson
2018-01-18  8:32   ` Lee Jones

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=87o9i19er5.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=daniel.thompson@linaro.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel.vetter@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=meghana.madhyastha@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.