Re: [PATCH] backlight: pm8941-wled: Add default-brightness property
From: Rob Herring <hidden>
Date: 2015-07-30 15:26:41
Also in:
linux-arm-msm, linux-devicetree, lkml
On Wed, Jul 29, 2015 at 6:51 PM, Bjorn Andersson [off-list ref] wrote:
On Fri 24 Jul 08:29 PDT 2015, Rob Herring wrote:quoted
On Thu, Jul 23, 2015 at 2:52 PM, Bjorn Andersson [off-list ref] wrote:quoted
Add the possibility of specifying the default brightness in DT. Signed-off-by: Bjorn Andersson <redacted> --- This depends on the patch moving pm8941-wled to backlight [1]. The dt property is used by several other backlight drivers, so I considered this to be a "common" property and it's hence not prefixed with "qcom,".Well, we have "default-brightness" and "default-brightness-level" used by 1 driver each. But default-brightness-level is much more commonly used (in dts files) since it is in the pwm backlight binding, so we should go with it. I'd like to see this moved to a common backlight doc.As I looked at these, the default-brightness used in tps65217 is a value between 0 and 100, so that can be interpreted as a percentage. The pwm binding however uses a separate array of "brightness-levels" and then default-brightness-level is supposed to be an index into that array.
Uggg. I missed that minor detail...
As we're trying to specify a default brightness within the range [0, max_brightness) the latter doesn't make much sense. Therefor my suggestion is that we make the "default-brightness" the common property and we define it as a percentage of [0,max_brightness).
Okay. I wonder if we should have units such as "default-brightness-percentage" or "default-brightness-%" so it is clear. Otherwise, we might have some people doing a range of [0,max]. The former is a bit long and the latter is a bit unusual.
quoted
Really, I think all the backlight documentation should be merged with LEDs docs. Things like "default-on" are common. But I won't ask to do that here.I think the backlight framework should be merged with the LED framework. There's several hw blocks that are split between the two, with an mfd tying them together...
Fully agree. BTW, doing that doesn't have to be in sync between the bindings and drivers. Of course, if we've designed the bindings with sub devices to fit the MFD structure, then that is another problem. Rob