Dan, Jacek and Pavel, Let me also describe blinking effect for Screen Frame LED tube, because looks like blink_set() doesn't support smooth blinking. > brightness > ^ > | *** *** ** > > ** ** ** ** ** > | * * * * * > > * * * * * > | ** ** ** ** ** > >** *** *** > | > +----^----^----^----^----^----^----^----^----^----> time So it's actually never go to OFF state, when effect is set. It is always in ON state, just brightness is smoothly changed from min to max. It all handled by LEDs board itself, there are no way to control it from SPI master. Please advice how it can be implemented to pass review? 11.06.19 22:52, Jacek Anaszewski пише:> On 6/11/19 2:01 PM, Pavel Machek wrote: >> Hi! >> >>>> I just want to clerify - for now LEDs board has 2 from 3 LEDs with effect function. >>>> >>>> 1. Screen frame led is just blinking, so blink_set() is fit well to this. >>>> 2. Pipe led actually consist from 3 leds and when effect is enabled next pattern is used: >>>> >>>> ^ >>>> | >>>> LED1 > OFF ON ON ON >>>> | >>>> LED2 > OFF OFF ON ON >>>> | >>>> LED3 > OFF OFF OFF ON >>>> | >>>> +----^----^----^----^----> time >>> >>> Pattern trigger applies to a single LED so it won't fit for this >>> pattern. >>> >>> Currently we don't support patterns spanning on multiple LEDs, >>> so you would have to come up with your own solution. >>> >>> What I can recommend is a trigger that would be created by your driver >>> and would activate this sequence. >> >> Yes, please. >> >> While adding custom files to sysfs may appear easier, we'll need >> "led-specific-triggers" for other reasons. > > For what reasons exactly? > > This is similar to the generic hw trigger support proposed by > Marek Behun. In the reply to that patch I asked some questions [0]. > So far the mechanism looks too me awkward and not introducing any > novelty besides requiring one more step - setting the trigger. > >> And for the record... Handling 3 LEDs as one is not something usual in >> the LED subsystem; I guess it makes sense in your specific case, but >> hopefully noone will copy that design. >> >> (I guess they are not individually controllable?) >> >> Pavel >> > > [0] https://www.spinics.net/lists/linux-leds/msg12269.html > -- Best regards, Oleh Kravchenko
Attachment:
signature.asc
Description: OpenPGP digital signature
