Re: [PATCH v5 1/2] leds: core: Introduce LED pattern trigger

[Bjorn Andersson]

On Sat 25 Aug 00:51 PDT 2018, Baolin Wang wrote:

> On 25 August 2018 at 04:44, Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx> wrote:
> > On 08/24/2018 10:12 PM, Pavel Machek wrote:
> >> On Fri 2018-08-24 21:49:50, Jacek Anaszewski wrote:
> >>> Hi Pavel,
> >>>
> >>> On 08/24/2018 12:11 PM, Pavel Machek wrote:
[..]
> >>> +    if (led_cdev->pattern_set) {
> >>> +            return led_cdev->pattern_set(led_cdev, data->patterns,
> >>> +                                         data->npatterns, data->repeat);
> >>> +    }
> >>
> >> Yeah, that sounds wrong. (Sorry I did not pay enough attention).
> >>
> >> It pattern_set() returns special error code, it should just continue
> >> and use software pattern fallback.
> >
> > And now we can get back to the issue I was concerned about in the
> > email you replied to, i.e. what series of [brightness delta_t] tuples
> > should be written to the pattern file to enable hardware breathing
> > engine.
> 
> OK. So now we've made a consensus to use the software pattern fallback
> if failed to set hardware pattern. How about introduce one interface
> to convert hardware patterns to software patterns if necessary?
> 

I do not agree that a silent fallback mechanism is the way to go here.
There is a enormous difference in power consumption between letting a
dedicated piece of hardware drive a pulse on a LED or using a general
purpose ARM core running at hundreds of MHz.


Note that the most common use case for the driver I'm trying to upstream
is to pulse the LED when you have a notification pending on your Android
device, in which case you want all the CPUs are completely powered down.

Regards,
Bjorn