On Tue, Apr 17, 2018 at 05:42:04PM -0700, abhinavk@xxxxxxxxxxxxxx wrote: > Adding another point. > > On 2018-04-17 17:04, abhinavk@xxxxxxxxxxxxxx wrote: > > Hi Bjorn > > > > Apologies if the prev reply wasnt clear. > > > > Hope this one is. > > > > reply inline. > > > > On 2018-04-17 14:29, Bjorn Andersson wrote: > > > On Tue 17 Apr 11:21 PDT 2018, abhinavk@xxxxxxxxxxxxxx wrote: > > > > On 2018-04-16 23:13, Bjorn Andersson wrote: > > > [..] > > > > > If the panel isn't actually a piece of backlight hardware then it should > > > > > not register a backlight device. Why do you need your own sysfs? > > > > > > > > > > Regards, > > > > > Bjorn > > > > [Abhinav] This particular panel isnt a piece of backlight hardware. > > > > But, we want to have our own sysfs to give flexibility to our > > > > userspace > > > > to write and read stuff for its proprietary uses. > > > > > > Please be more specific in your replies, no one will accept code that > > > "does stuff" and expecting a reviewer to spend time guessing or > > > pulling > > > the information out of you is a sure way to get your patches ignored. > > > > > > Exactly what kind of stuff are you talking about here and exactly > > > which > > > problem are you solving. > > > > > > > Thats how our downstream has been working so far and hence to > > > > maintain > > > > the compatibility would like to have it. > > > > > > Make your proprietary code work with the upstream kernel and you > > > shouldn't ever have to modify it. > > > > > > Regards, > > > Bjorn > > > > [Abhinav] We have a few userspace clients today for the backlight sysfs > > node > > which read/write directly to > > "/sys/class/backlight/panel0-backlight/brightness" > > When I said "stuff" I was only referring to the brightness value. > > This separate sysfs node allows us to validate those userspace features > > of ours > > which directly edit the backlight value on our reference platform. > > Since our reference platform uses this panel,hence having our own > > sysfs alias helps. > > Otherwise, whenever we try to use this panel with upstream code we > > will have to end up > > changing all those places in our userspace/framework to change the sysfs > > path. > > Hence we wanted to preserve that sysfs node name. > > The wled device is not created under /sys/class/backlight but under > > /sys/class/leds/wled. > > So we will have to change the name of this node across all our > > userspace. > > > > If this isnt a convincing reason enough to have its own sysfs node > > path, I will use > > your approach. > > > > Let me know your comments or if this is still not clear. > > > [Abhinav] We also might not be using the brightness value "as-it-is". > > We will potentially scale it up/down based on some requirements. > > If we do not have our own sysfs alias for this, how do we account for > providing this interface for our chipset specific backlight dependent > feature. > > Can you please comment on this? Not easily. It's rather unclear what this chipset specific backlight dependent feature you have alluded to is so how can we suggest how to control or model it in the upstream kernel? I can make a guess that is might be to do with brightness curves... but I'd really prefer not to have to guess. There are some problems with the current interface because it is not well defined with the brightness control is linear or logarithmic/perceptual (patches welcome) but for other common embedded backlights (pwm_bl particularly) we expect calibration of the brightness curve to be a job for the device tree (because it is a property of the hardware it can be described in the DT) and there are patches pending to improve this. Daniel. -- 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
