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@xxxxxxxxxx>
> > > ---
> > >
> > > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
