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

On Wed, 25 Apr 2018, Daniel Vetter 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.

All applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

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

On Wed, 25 Apr 2018, Daniel Vetter 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.

All applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2018-04-30 12:27 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
2018-04-30 10:21   ` Jani Nikula
2018-04-30 12:27 ` Lee Jones [this message]
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=20180430122712.GG5147@dell \
    --to=lee.jones@linaro.org \
    --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=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.