[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170407203649.GD15143@minitux>
Date: Fri, 7 Apr 2017 13:36:49 -0700
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Pavel Machek <pavel@....cz>
Cc: Jacek Anaszewski <jacek.anaszewski@...il.com>,
Rob Herring <robh@...nel.org>,
Richard Purdie <rpurdie@...ys.net>,
linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org,
linux-arm-msm@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
On Fri 07 Apr 06:32 PDT 2017, Pavel Machek wrote:
> > For the patterns I don't know how a trigger for this would look like,
> > how would setting the pattern of a trigger be propagated down to the
> > hardware?
>
> Well... I'm not sure if we _want_ to do triggers for
> patterns. LED triggers change rather quickly (100 times a second?) so
> doing them in kernel makes sense. Patterns take 10s of seconds, so we
> do not need to handle them in kernel.
>
On any current Qualcomm based phone (using the Qualcomm PMIC to drive
the RGB notification LED) the patterns are hard coded in DeviceTree and
the option you have in runtime is to enable/disable the usage of the
configured pattern and a few knobs of how to traverse the configured
pattern.
When you enter e.g. a low-battery scenario you trigger the red LED to
run its low-battery-pattern and you don't touch it until there's a
higher prio notification (e.g. someone connects the charger).
So in the current implementation patterns "never" changes and they are
triggered only every time you get some event/notification.
A benefit of not using triggers for patterns is that I can assign
patterns to triggered events, e.g. I can configure my LEDs to flash &
fade out when some trigger happens.
Regards,
Bjorn
Powered by blists - more mailing lists