lkml.org 
[lkml]   [2017]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 1/3] leds: core: Introduce generic pattern interface
On Mon 20 Nov 15:20 PST 2017, Pavel Machek wrote:

> On Wed 2017-11-15 08:36:42, Greg KH wrote:
> > On Tue, Nov 14, 2017 at 11:13:43PM -0800, Bjorn Andersson wrote:
> > > Some LED controllers have support for autonomously controlling
> > > brightness over time, according to some preprogrammed pattern or
> > > function.
> > >
> > > This adds a new optional operator that LED class drivers can implement
> > > if they support such functionality as well as a new device attribute to
> > > configure the pattern for a given LED.
> > >
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> > >
> > > Changes since v2:
> > > - None
> > >
> > > Changes since v1:
> > > - New patch, based on discussions following v1
> > >
> > > Documentation/ABI/testing/sysfs-class-led | 20 ++++
> > > drivers/leds/led-class.c | 150 ++++++++++++++++++++++++++++++
> > > include/linux/leds.h | 21 +++++
> > > 3 files changed, 191 insertions(+)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
> > > index 5f67f7ab277b..74a7f5b1f89b 100644
> > > --- a/Documentation/ABI/testing/sysfs-class-led
> > > +++ b/Documentation/ABI/testing/sysfs-class-led
> > > @@ -61,3 +61,23 @@ Description:
> > > gpio and backlight triggers. In case of the backlight trigger,
> > > it is useful when driving a LED which is intended to indicate
> > > a device in a standby like state.
> > > +
> > > +What: /sys/class/leds/<led>/pattern
> > > +Date: July 2017
> >
> > That was many months ago :)
> >
> > > +KernelVersion: 4.14
> >
> > And that kernel version is long since released :)
>
> Yeah, the other problem is it has some interesting format with ":|"
> marking repeat,

So what would you prefer?

We can either add another file ("pattern_repeat"?) that allows you to
describe this separately or some other symbol.

> and is not really suitable for RGB LEDs...
>

I can think of two ways to support patterns for a RGB LED;
1) Provide N files for the N channels
2) Make each entry in the suggested pattern file be N brightness values
followed by the duration - if we wrap each N-tuple in some symbol
(e.g. <>) this would transparently support "set all channels to same
brightness value" and per-channel values.

The latter being fully compatible with the proposed interface.

> I'd really prefer to get driver in first, and add pattern interface
> later.
>

Sure, I can move all the pattern-related code from the driver into a
separate patch.

Regards,
Bjorn

\
 
 \ /
  Last update: 2017-11-21 01:22    [W:0.057 / U:1.836 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site