Am Sun, 8 Jul 2018 22:45:18 +0200 schrieb Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>: > Hi Henning, > > On 07/06/2018 09:22 AM, Henning Schild wrote: > > Am Thu, 5 Jul 2018 20:59:56 +0200 > > schrieb Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>: > > > >> Hi Henning, > >> > >> On 07/05/2018 01:12 PM, Henning Schild wrote: > >>> Hey, > >>> > >>> we are currently working on a led driver that we will eventually > >>> propose mainline. Our HW implies a kind of dominance where one LED > >>> can have multiple colors, but only one can be lid at once. > >> How does your hardware decide about LED color? Does it have e.g. > >> a group of three outputs that are intended to be connected to > >> a multicolor RGB LED component? > >> > >> Or maybe it has a group of outputs from each only one can be > >> active at a time? > > > > We control 2 bits per LED, each can have two colors. Visible would > > be the follwing: > > > > XY L1 L0 > > 11 off off > > 10 off on > > 01 on off > > 00 on off > > > > So X=0 makes L1 always on and L0 can not be seen anymore. > > > >>> Lighting the dominant effectively (visible) turns off the > >>> recessive. The question is whether that visible effect should be > >>> reflected in the code. Or in other words, should the "brightness" > >>> in sysfs always correspond to what is actually visible? > >>> > >>> Our first version does not try to do that, because that would > >>> complicate the code a lot. LEDs would have to set each other and > >>> possibly remember to reset each other when they get toggled again. > >>> > >>> I doubt that being the first example of such an LED, but could not > >>> find a good example in the kernel. Maybe you can point out a > >>> driver that handles this problem in the "correct" way. > >> > >> I don't have a full picture of your hw design, but as a first shot > >> please compare drivers/leds/leds-bd2802.c RGB LED driver. > > > > I had a quick look but did not fully understand it yet. > > > >> In your case, let's say when setting red LED brightness you should > >> set green and blue LEDs brightness to LED_OFF. It should not be > >> too complicated AFAICS. > > > > Looking at the above table we have two ledclass instances where > > every one returns in its get-function whether its bit is 0. Now in > > the 0b00 case we would return both-on while only one is visibly on. > > We could decide to not allow 0b00 at all. X=0 -> Y=1 but if you do > > that turning L1 on/off would always turn L0 off. > > To cover that L1 would need to remember that it turned off L0, and > > possibly reverse that when it gets turned off again. But while L1 > > remembers that other writers might have actually turned off L0, so > > that cached state might become invalid while L1 is on. > > > > Hope that explains it. Our current implementation uses the simple > > approach where we ignore all that. 0b00 will in SW say that both > > are on, while only L1 is visibly on. > > Thank you for the explanation. I tried to look at the problem from > the LED state side, and got the following truth table: > > (L0,L1 - LED class devices' brightness states, > state values: on=1, off=0) > > L0 L1 XY > 0 0 11 > 1 0 10 > 1 1 -- (return -EBUSY on attempt of setting) > 0 1 01 > > "--" signifies here the forbidden state. Since L0=0 L1=1 has > two possible XY combinations (01 and 00), then only one of them > is shown in this table, and the other one won't need to be ever > set. Ok, so EBUSY after all. I had the same idea but was afraid users of the LEDs would not really be prepared to handle errors. At the first glance i failed to find examples of setters returning errors. And the higher level abstractions are "void" again. > Did I get it right? Yes. regards, Henning
