On 2018-07-09 10:15, Henning Schild wrote: > 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. EBUSY seems pointless. Even the sysfs interface does not let you know about it. Jan > >> Did I get it right? > > Yes. > > regards, > Henning > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux
