From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lee Jones Subject: Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot Date: Thu, 26 Feb 2015 11:06:59 +0000 Message-ID: <20150226110659.GO6688@x1> References: <1406806970-12561-1-git-send-email-thierry.reding@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <1406806970-12561-1-git-send-email-thierry.reding@gmail.com> Sender: linux-kernel-owner@vger.kernel.org To: Thierry Reding Cc: Jingoo Han , Bryan Wu , Rob Herring , Mark Rutland , Pawel Moll , Ian Campbell , Kumar Gala , Jean-Christophe Plagniol-Villard , Tomi Valkeinen , Russell King , Eric Miao , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org List-Id: devicetree@vger.kernel.org On Thu, 31 Jul 2014, Thierry Reding wrote: > From: Thierry Reding >=20 > The default for backlight devices is to be enabled immediately when > registering with the backlight core. This can be useful for setups th= at > use a simple framebuffer device and where the backlight cannot otherw= ise > be hooked up to the panel. >=20 > However, when dealing with more complex setups, such as those of rece= nt > ARM SoCs, this can be problematic. Since the backlight is usually set= up > separately from the display controller, the probe order is not usuall= y > deterministic. That can lead to situations where the backlight will b= e > powered up and the panel will show an uninitialized framebuffer. >=20 > Furthermore, subsystems such as DRM have advanced functionality to se= t > the power mode of a panel. In order to allow such setups to power up = the > panel at exactly the right moment, a way is needed to prevent the > backlight core from powering the backlight up automatically when it i= s > registered. >=20 > This commit introduces a new boot_off field in the platform data (and > also implements getting the same information from device tree). When = set > the initial backlight power mode will be set to "off". >=20 > Signed-off-by: Thierry Reding > --- > I've been meaning to send this for a while but was always holding bac= k > because of the indoctrination that this type of configuration shouldn= 't > be part of device tree. However this issue was recently raised again = in > the context of power up sequences for display panels. As described ab= ove > the issue is that panel datasheets recommend that the backlight attac= hed > to a panel be turned on at the very last step to avoid visual glitche= s > during the panel's power up sequence. With the current implementation= it > is typical for the backlight to be probed before the display panel. T= hat > has, in many cases, the side-effect of enabling the backlight, theref= ore > making the screen content visible before it's actually initialized. >=20 > Some panels come up with random garbage when uninitialized, others sh= ow > all white. With some luck the panel will be all black and users won't > really notice. >=20 > This patch is an attempt to enable boards to override the default of > turning on the backlight for the pwm-backlight driver. I'm not sure i= f > there was a specific reason to turn on the backlight by default when > this driver was initially written, but the fact is that since it has > pretty much always been like this we can't really go and change the > default, otherwise a lot of people may end up with no backlight and n= o > clue as to how to enable it. So the only reasonable thing we can do i= s > to keep the old behaviour and give new boards a way to override it if > they know that some other part of the stack will enable it at the rig= ht > moment. >=20 > .../devicetree/bindings/video/backlight/pwm-backlight.txt | = 1 + > drivers/video/backlight/pwm_bl.c | = 8 ++++++++ > include/linux/pwm_backlight.h | = 2 ++ > 3 files changed, 11 insertions(+) Some people on the list are talking about this again. What was the verdict? --=20 Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org =E2=94=82 Open source software for ARM SoCs =46ollow Linaro: Facebook | Twitter | Blog