Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756152AbdDGUg6 (ORCPT ); Fri, 7 Apr 2017 16:36:58 -0400 Received: from mail-pg0-f47.google.com ([74.125.83.47]:34303 "EHLO mail-pg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755546AbdDGUgx (ORCPT ); Fri, 7 Apr 2017 16:36:53 -0400 Date: Fri, 7 Apr 2017 13:36:49 -0700 From: Bjorn Andersson To: Pavel Machek Cc: Jacek Anaszewski , Rob Herring , Richard Purdie , linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org, linux-arm-msm@vger.kernel.org, Mark Rutland , devicetree@vger.kernel.org Subject: Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG Message-ID: <20170407203649.GD15143@minitux> References: <20170323055435.29197-1-bjorn.andersson@linaro.org> <20170323203749.GB8563@amd> <20170329021734.afhqmfpmbcjyv7bu@rob-hp-laptop> <20170329190725.GN20094@minitux> <20170329222301.GB7977@amd> <20170330000955.GP20094@minitux> <20170330074309.GA28533@amd> <20170403190032.GX20094@minitux> <20170407133223.GE4756@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170407133223.GE4756@amd> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1269 Lines: 32 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