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. Henning
