Marek On 3/29/19 6:42 AM, Jacek Anaszewski wrote: > On 3/29/19 3:29 AM, Marek Behun wrote: >>> ( >>> The last two control "global brightness" for all LEDs. The >>> resulting brigthness of LED X channel C is (i dont know if this is >>> really linear, but suppose it is): >>> global_brightness * X_C_brightness * X_enabled >>> >>> So for example the resulting brightness of the red channel of WAN >>> LED is >>> global_brightness * WAN_red_brightness * WAN_enabled >>> >>> This "global brightness" can be set via command 7, or by hardware >>> when user presses a button (hardware cycles through 8 levels of >>> hardcoded values each time the button is pressed). >>> ) >> >> Jacek, Pavel, >> >> should I, and if, then how, expose to the user this global_brightness? >> >> I thought about merging this with classic led brightness and writing a >> ->brightness_get method which would query the global brightness and >> then multiply it with the ->brightness which was set, but there is no >> way for setting brightness this way, because changing brightness of one >> LED could change brightnesses of other LEDs... > > This "global_brightness" seems to be similar to LEDn_BRIGHTNESS of > TI lp50xx [0] devices that led us to that whole concept of LED multi > color class. > > In short words it assumed incorporating underlaying color channels > into single LED multi color device with the following interface > for setting particular color channels: > > colors // not limited to these ones, it's just an example > red > brightness > max_brightenss > green > brightness > max_brihgntess > blue > brightness > max_brightness > > There were also other files proposed for atomic setting of all these > channels, but I skip them here. > > In addition to that we would have main brightness file as it is > in current LED class, and brightness-model file that would allow > to map brightness file to the counterpart of lp50xx LEDn_BRIGHTNESS > registers or your global brightness. It would be also possible > to define different brightness models in Device Tree by mapping > certain configurations of channel brightnesses to a range of > global brightness levels. > > Dan Murphy has a fair piece of that implemented already > on his private branch as a proof of concept. As Jacek pointed out I have been working on the multi-color class framework that would help with this device, I think. I say "I think" because I cannot find the public data sheet for the device to take a look at how the LEDs are connected. 1. Your patch order is incorrect. DT bindings first and then code. 2. Is this driver for the end product or for a LED device driver? (I cannot find a public reference for either) 3. I do have a lot of comments on the code but without the data sheet or understanding of what is being implemented they may not be worth while. For the framework I have the color sysfs nodes and basic registration completed. I am continuing to work on the available brightness models. https://patches.linaro.org/project/linux-leds/list/?series=18022 I do have some local code somewhere that initializes the LP50XX colors. Dan > > So, depending on the amount of time you have for your disposal, > you could either try to continue that work or ignore that > global brightness for now. > > http://www.ti.com/lit/ds/symlink/lp5024.pdf > -- ------------------ Dan Murphy
