From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dan Murphy Subject: Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver Date: Mon, 7 Jan 2019 15:15:02 -0600 Message-ID: <0982f9c3-b5df-7131-8d5a-761adefd389d@ti.com> References: <8740cfd6-a6b5-ad27-313b-984a9febf18a@ti.com> <20181219201047.GA23448@amd> <54f28115-0a7d-8e9c-3bec-6e91fb3981ec@gmail.com>

<986b5105-2fdb-bd25-7c8a-ca8fd1ade821@gmail.com> <7f205102-e854-f1cb-cc03-1307d1cddc87@gmail.com>

<20190104201256.GA2931@amd> <90a2ed79-b437-af14-4538-430d8723cc6b@gmail.com> <38daf022-e4e4-799d-4c75-ee851315290d@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <38daf022-e4e4-799d-4c75-ee851315290d@gmail.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Jacek Anaszewski , =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= , Pavel Machek Cc: robh+dt@kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org List-Id: linux-leds@vger.kernel.org Jacek On 1/7/19 3:13 PM, Jacek Anaszewski wrote: > Hi Vesa, > > On 1/5/19 1:39 AM, Vesa Jääskeläinen wrote: >> Hi Jacek, >> >> On 04/01/2019 23.37, Jacek Anaszewski wrote: >>> But, aside from that hypothetic issue, we need a solution for >>> LEDn_BRIGHTNESS feature of lp5024, i.e. setting color intensity >>> via a single register write. How would you propose to address that? >> >> You could model it to something like this in device tree: >> >> led-module @ { >> compatible = "lp5024"; >> >> // There is in hardware setup to use either linear or >> // logarithmic scaling: >> //enable-logarithmic-brightness; >> >> led0 { >> // this will create led instance for LED0 in lp5024 >> label = "lp-led0"; >> >> // This specifies LED number within lp5024 >> led-index = <0>; // set output-base as 0*3 == 0 >> >> element-red { >> // refers to OUT0 >> output-offset = <0>; >> }; >> >> element-green { >> // refers to OUT1 >> output-offset = <1>; >> }; >> >> element-blue { >> // refers to OUT2 >> output-offset = <2>; >> }; >> >> }; >> >> led1 { >> // this will create led instance for LED1 in lp5024 >> label = "lp-led1"; >> >> // This specifies LED number within lp5024 >> led-index = <1>; // set output-base as 1*3 == 3 >> >> element-red { >> // refers to OUT3 >> output-offset = <0>; >> }; >> >> element-green { >> // refers to OUT4 >> output-offset = <1>; >> }; >> >> element-blue { >> // refers to OUT5 >> output-offset = <2>; >> }; >> >> }; >> >> bank-led { >> // this will create led instance for bank leds in lp5024 >> label = "lp-bank-led"; >> >> // configured bank led configuration >> led-index = <2 3 4 5 6 7>; >> // As here is list of led-indices this entry is >> // assumed to be bank configuration. Bank mode is enable >> // for the indices. >> >> // set output-base as BANK A >> >> element-red { >> // refers to BANK A >> output-offset = <0>; >> }; >> >> element-green { >> // refers to BANK B >> output-offset = <1>; >> }; >> >> element-blue { >> // refers to BANK C >> output-offset = <2>; >> }; >> }; >> }; >> >> This would then create three led instances and each led instance has brightness setting and that goes straight to hardware. >> >> If one would want to override hardware control for brightness then I suppose you would define in led node something like: >> >> brightness-model = "hsl" >> >> This would then pick red, green and blue elements for hsl calculations and others color elements for linear. LED specific hardware brightness would then be either 0 or 0xFF depending if all of LED color elements are zero or not. >> >> Would that kind of model work? > > I'd prefer to have single RGB LED device. And your DT design > is unnecessarily complex and a bit confusing. +1 to that comment > > Also, you provided scarce information about sysfs interface. > It would be nice to see the sequence of commands. > -- ------------------ Dan Murphy