Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752249AbdC2C0z (ORCPT ); Tue, 28 Mar 2017 22:26:55 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:34906 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751734AbdC2C0w (ORCPT ); Tue, 28 Mar 2017 22:26:52 -0400 Date: Tue, 28 Mar 2017 21:26:49 -0500 From: Rob Herring To: Bjorn Andersson Cc: Richard Purdie , Jacek Anaszewski , Pavel Machek , Mark Rutland , linux-leds@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH 2/2] DT: leds: Add Qualcomm Light Pulse Generator binding Message-ID: <20170329022649.wp5uvt2akufgihwh@rob-hp-laptop> References: <20170323055435.29197-1-bjorn.andersson@linaro.org> <20170323055435.29197-2-bjorn.andersson@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170323055435.29197-2-bjorn.andersson@linaro.org> User-Agent: Mutt/1.6.2-neo (2016-08-21) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6751 Lines: 234 On Wed, Mar 22, 2017 at 10:54:35PM -0700, Bjorn Andersson wrote: > This adds the binding document describing the three hardware blocks > related to the Light Pulse Generator found in a wide range of Qualcomm > PMICs. > > Signed-off-by: Bjorn Andersson > --- > .../devicetree/bindings/leds/leds-qcom-lpg.txt | 194 +++++++++++++++++++++ > 1 file changed, 194 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt > > diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt > new file mode 100644 > index 000000000000..fb9edd89119d > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt > @@ -0,0 +1,194 @@ > +Binding for Qualcomm Light Pulse Generator > + > +The Qualcomm Light Pulse Generator consists of three different hardware blocks; > +a ramp generator with lookup table, the light pulse generator and a three > +channel current sink. These blocks are found in a wide range of Qualcomm PMICs. > +Each of these are described individually below. > + > += Lookup Table (LUT) > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be "qcom,spmi-lpg-lut" > + > +- reg: > + Usage: required > + Value type: > + Definition: base address of the LUT block > + > +- qcom,lut-size: > + Usage: required > + Value type: > + Definition: number of elements available in the lookup table > + > += Light Pulse Generator (LPG) > +The Light Pulse Generator can operate either as a standard PWM controller or in > +a more advanced lookup-table based mode. These are described separately below. > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be "qcom,spmi-lpg" > + > +- reg: > + Usage: required > + Value type: > + Definition: base address of the LPG block > + > +== PWM mode > + > +- #pwm-cells: > + Usage: required > + Value type: > + Definition: must be 1 > + > +== Lookup-table mode > + > +- cell-index: This is a standard though not used property name. Perhaps "reg" or a vendor property instead. > + Usage: required, when referencing a LUT > + Value type: > + Definition: id of the LPG, used to associate the LPG with a particular > + ramp generator in the LUT block > + > +- default-state: > + Usage: optional > + Value type: > + Definition: default state, as defined in common.txt > + > +- label: > + Usage: optional > + Value type: > + Definition: label of the LED, as defined in common.txt > + > +- linux,default-trigger: > + Usage: optional > + Value type: > + Definition: default trigger, as defined in common.txt > + > +- qcom,tri-led: > + Usage: optional > + Value type: > + Definition: a phandle of a TRILED node and a single u32 denoting which > + output channel to control > + > +- qcom,lut: > + Usage: optional > + Value type: > + Definition: phandle of a LUT node > + > +- qcom,dtest: > + Usage: optional > + Value type: > + Definition: configures the output into an internal test line of the > + pmic. A first u32 defines which test line to use and the > + second cell configures how the value should be outputed > + (available lines and configuration differs between PMICs) > + > +- qcom,pattern: > + Usage: optional > + Value type: > + Definition: list of 16 bit duty cycle values to make up the pattern to > + be programmed into the LUT. Values should be in the range > + [0,512). > + > +- qcom,pattern-length-ms: > + Usage: optional > + Value type: > + Definition: duration, in milliseconds, of the ramp generator running > + one pass over the defined pattern > + > +- qcom,pattern-pause-lo-ms: > + Usage: optional > + Value type: > + Definition: duration, in milliseconds, for the ramp generator to pause > + before iterating over the pattern > + > +- qcom,pattern-pause-hi-ms: > + Usage: optional > + Value type: > + Definition: duration, in milliseconds, for the ramp generator to pause > + after iterating over the pattern > + > +- qcom,pattern-ping-pong: > + Usage: optional > + Value type: > + Definition: denotes that the ramp generator should reverse direction > + when reaching the end of the pattern, instead of wrapping > + to the beginning > + > +- qcom,pattern-oneshot: > + Usage: optional > + Value type: > + Definition: denotes that the ramp generator should stop after a single > + pass over the pattern > + > +- qcom,pattern-reverse: > + Usage: optional > + Value type: > + Definition: denotes that the ramp generator should operate backwards > + over the pattern The pattern related properties should be common if we put them in DT which I think is debatable. > + > += LED Current Sink (TRILED) > + > +- compatible: > + Usage: required > + Value type: > + Definition: must be "qcom,spmi-tri-led" > + > +- reg: > + Usage: required > + Value type: > + Definition: base address of the TRILED block > + > +- qcom,power-source: > + Usage: required > + Value type: > + Definition: power-source used to drive the output, as defined in the > + datasheet > + > += EXAMPLE: > +The following example defines a single output of the PMI8994, sinking current > +into a LED in a natural pulsating pattern: > + > +&spmi_bus { > + pmic@3 { > + compatible = "qcom,pmi8994", "qcom,spmi-pmic"; typo. > + reg = <0x3 SPMI_USID>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + pmi8994_lpg_lut: lpg-lut@b000 { > + compatible = "qcom,spmi-lpg-lut"; > + reg = <0xb000>; > + > + qcom,lut-size = <24>; > + }; > + > + lpg@b200 { > + compatible = "qcom,spmi-lpg"; > + reg = <0xb200>; > + > + cell-index = <2>; > + > + label = "lpg:green:user0"; > + > + qcom,tri-led = <&pmi8994_tri_led 1>; > + qcom,lut = <&pmi8994_lpg_lut>; > + > + qcom,pattern = /bits/ 16 <9 20 42 86 158 256 353 > + 425 469 491 502 507>; > + qcom,pattern-length-ms = <1337>; > + qcom,pattern-ping-pong; > + > + default-state = "on"; > + }; > + > + pmi8994_tri_led: tri-led@d000 { It may make more sense to make the LED(s) and their properties a sub node of this. You could always use the PWM binding to link back to the LPG. The pattern/LUT is really just a queue of PWM settings. That's not all that different than a PWM based audio buzzer. There was a DMA based PWM binding the other day for audio. Rob > + compatible = "qcom,spmi-tri-led"; > + reg = <0xd000>; > + > + qcom,power-source = <1>; > + }; > + }; > +}; > -- > 2.12.0 >