On Wed, Jul 29, 2015 at 6:51 PM, Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx> wrote: > On Fri 24 Jul 08:29 PDT 2015, Rob Herring wrote: > >> On Thu, Jul 23, 2015 at 2:52 PM, Bjorn Andersson >> <bjorn.andersson@xxxxxxxxxxxxxx> wrote: >> > Add the possibility of specifying the default brightness in DT. >> > >> > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxxxxxx> >> > --- >> > >> > 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
