D assignments I realized the user will know quite quickly
that their configuration is messed up.
The suggestions actually simplified the code quite nicely which I am happier to
have
> Regardless of that - please find two nits below.
>
> On 08/16/2018 07:20 PM, Dan Murphy wr
Introduce the lm3697 LED driver for
backlighting and display.
Datasheet location:
http://www.ti.com/lit/ds/symlink/lm3697.pdf
Signed-off-by: Dan Murphy
---
v5 - Fix nitpick issues with code -
https://lore.kernel.org/patchwork/patch/975061/
v4 - Made modifications to the control bank routine
Add the device tree bindings for the lm3697
LED driver for backlighting and display.
Signed-off-by: Dan Murphy
---
v5 - Fix the comment for the example -
https://lore.kernel.org/patchwork/patch/975060/
v4 - Removed HVLED definition in favor of HVLED place definition -
https://lore.kernel.org
Jacek
On 08/17/2018 02:37 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 08/16/2018 10:44 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 08/16/2018 02:58 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> Thank you for the patch.
>>>
>>>
the overall brightness of the LED grouping.
Datasheet:
http://www.ti.com/lit/ds/symlink/lp5024.pdf
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/leds/leds-lp5024.txt | 63 +++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds
that patchset being
committed.
Dan
Dan Murphy (2):
dt: bindings: lp5024: Introduce the lp5024 and lp5018 RGB driver
leds: lp5024: Add the LP5024/18 RGB LED driver
.../devicetree/bindings/leds/leds-lp5024.txt | 63 ++
drivers/leds/Kconfig | 7 +
drivers/leds
with the same mixing and
brightness. Inversely the LEDs can also be controlled independently.
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 7 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp5024.c | 610 +
3 files changed, 618
On 12/16/2018 05:06 AM, Jonathan Cameron wrote:
> On Tue, 11 Dec 2018 13:12:06 -0600
> Dan Murphy wrote:
>
>> Per Jonathan Cameron, the buffer needs to allocate room for a
>> 64 bit timestamp as well as the channels. Change the buffer
>> to allocate this additional
On 12/19/2018 10:26 AM, Dan Murphy wrote:
> Introduce the LP5024 and LP5018 RGB LED driver.
> The difference in these 2 parts are only in the number of
> LED outputs where the LP5024 can control 24 LEDs the LP5018
> can only control 18.
>
> The device has the ability to gro
ry, we need documentation for them.
Sure I have no problem documenting them but where do I do that?
I am assuming Documentation/leds/leds-lp5024.txt
This looks to be where Milo did this before.
Dan
>
> Thanks,
> Pavel
>
--
--
Dan Murphy
Pavel
On 12/19/2018 02:10 PM, Pavel Machek wrote:
> On Wed 2018-12-19 13:41:18, Dan Murphy wrote:
>> Pavel
>>
>> Thanks for the review.
>>
>> On 12/19/2018 01:34 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>> +static DEVICE_ATTR_W
On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:
> Hi Dan and Pavel,
>
> On 12/19/18 9:41 PM, Dan Murphy wrote:
>> Pavel
>>
>> On 12/19/2018 02:10 PM, Pavel Machek wrote:
>>> On Wed 2018-12-19 13:41:18, Dan Murphy wrote:
>>>> Pavel
>>>>
urations it can report:
variable red
variable blue
variable green
or even simpler "static" or "dynamic" as a return to report the RGB
configuration.
The LED driver would just need to set the variable.
Dan
>
> Best regards,
> Pavel
>
--
--
Dan Murphy
olled by PWM
or an ALS.
>
> Anyway, if your 36 channels can be set independently, I believe you
> just want them to export as 36 LEDs.
I am not sure that is what the "customers" would want to have to set 36
different nodes or even declare those 36 nodes.
That is 36 independent user space to kernel space calls that are very expensive
just to set a LED color and brightness.
Now that is very unrealistic that there would be 36 calls happening. But for
this part it
would cut the calls to set the brightness to the kernel in runtime after init
to 1/3. Set the color and then only one call for the brightness.
Dan
>
> Thanks,
> Pavel
>
--
--
Dan Murphy
Jonathan
Thanks for the review
On 12/08/2018 05:56 AM, Jonathan Cameron wrote:
> On Tue, 4 Dec 2018 11:59:55 -0600
> Dan Murphy wrote:
>
>> Introduce the TI ADS124S08 and the ADS124S06 ADC
>> devices from TI. The ADS124S08 is the 12 channel ADC
>> and the ADS124S06
Introduce the TI ADS124S08 and the ADS124S06 ADC
devices from TI. The ADS124S08 is the 12 channel ADC
and the ADS124S06 is the 6 channel ADC device
These devices share a common datasheet:
http://www.ti.com/lit/gpn/ads124s08
Signed-off-by: Dan Murphy
---
v2 - Removed the fill_noop call
Adding binding documentation for Texas Instruments ADS124S08
and ADS124S06 ADC.
S08 is a 12 channel ADC
S06 is a 6 channel ADC
Datesheet can be found here:
http://www.ti.com/lit/gpn/ads124s08
Signed-off-by: Dan Murphy
---
v2 - Fixed incorrect compatible example and removed vref-supply
Per Jonathan Cameron, the buffer needs to allocate room for a
64 bit timestamp as well as the channels. Change the buffer
to allocate this additional space.
Signed-off-by: Dan Murphy
---
v2 - New patch suggested change by maintainer -
https://lore.kernel.org/patchwork/patch/1021048/
drivers
Migrate the driver to use the devm IIO calls as opposed to
the unmanaged calls.
Signed-off-by: Dan Murphy
---
v2 - New patch
drivers/iio/adc/ti-ads8688.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/adc/ti-ads8688.c b/drivers/iio/adc/ti
Vesa
On 12/20/2018 06:40 AM, Vesa Jääskeläinen wrote:
> Hi All,
>
> On 19/12/2018 23.50, Dan Murphy wrote:
>> On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:
>>> Hi Dan and Pavel,
>>> Some time ago we had discussion with Vesa Jääskeläinen about possible
>
ss register actually
controls the output and there are only 7 of these.
Dan
>
> Pavel
>
--
--
Dan Murphy
On 12/21/2018 01:32 AM, Jacek Anaszewski wrote:
> On 12/20/18 9:31 PM, Jacek Anaszewski wrote:
>> On 12/19/18 10:50 PM, Dan Murphy wrote:
>>> On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:
>>>> Hi Dan and Pavel,
>>>>
>>>> On 12/19/18 9:41
ies LED number within lp5024
> led-index = <1>; // set output-base as 1*3 == 3
>
Can we not use led-sources like I have done already?
I really like to keep the DT nodes simple and re-use nodes that exist if
possible.
My code already maps and groups the outputs into the associated banks
Dan
--
--
Dan Murphy
to linear
>>> relation, some use exponential relation. Human eyes percieve logarithm
>>> of lumens. RGB color model uses even more complex function.
>>>
>>> c) Except for white LEDs, LEDs are basically sources of single
>>> wavelength of light, while CRTs and LCDs produce broader
>>> spectrums.
>>>
>>> d) RG, RGBW and probably other LED combinations exist.
>>>
>>> e) Not all "red" LEDs will produce same wavelength. Similar
>>> differences will exist for other colors.
>>>
>>> f) We have existing RGB LEDs represented as three separate
>>> monochromatic LEDs in sysfs.
>>
>> One general question: do you have any solutions in store?
>>
>> [0] http://www.ti.com/lit/ug/tiduee6/tiduee6.pdf
>> [1] http://www.everlight.com/file/ProductFile/19-337-R6GHBHC-A01-2T.pdf
>>
>
I just wanted to point out that there are 4 total devices right now that use
the same mapping
LP5018, LP5024, LP5030 and the LP5036.
I can implement what ever we would like to I just need to know what to design
against.
But keep in mind I still need to invest my time in the other TI-lmu patches on
my list to complete.
Dan
--
--
Dan Murphy
Jacek
On 1/7/19 2:59 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 1/7/19 8:36 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 1/7/19 1:13 PM, Jacek Anaszewski wrote:
>>> On 1/6/19 4:52 PM, Jacek Anaszewski wrote:
>>>> Hi Pavel,
>>>>
>>>&
};
>>
>> 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
Rob
On 12/28/18 5:53 PM, Rob Herring wrote:
> On Wed, Dec 19, 2018 at 10:26:25AM -0600, Dan Murphy wrote:
>> Introduce the bindings for the Texas Instruments LP5024 and the LP5018
>> RGB LED device driver. The LP5024/18 can control RGB LEDs individually
>> or as part of
this device since there is no
reason to create a node for each LED output.
As the overall brightness of the cluster or bank is controlled by a single
brightness file.
Dan
>>
>>>> Our problem is how to set the color atomically. With HSV approach we
>>>> were to obviate the problem by mapping brightness file to the "V"
>>>> component of that color space, and write all H,S and V values to the
>>>> hardware only on write to brightness file.
>>>
>>> I'm not sure how realistic the "atomic color" problem is. Computers
>>> are way faster than human vision.
>>
>> With LEDn_BRIGHTNESS registers of lp5024 it seems that we need the
>> ability for grouping LEDs in triplets and be able to set their intensity
>> with a single write operation.
>>
>>> I believe problem to start with is the "white" problem. Setting
>>> R=G=B=255 will _not_ result in anything close to white light on
>>> hardware I have.
>>
>> RGBW LED controllers solve this problem. For the devices without
>> white/amber we cannot do more than the hardware allows for.
>>
>> [0] http://www.ti.com/lit/ds/symlink/lp5024.pdf
>>
>
--
--
Dan Murphy
Jacek
Thanks for the reply!
All
Happy New Year!
On 1/1/19 8:42 AM, Jacek Anaszewski wrote:
> On 12/31/18 8:15 PM, Dan Murphy wrote:
>> On 12/31/18 9:47 AM, Jacek Anaszewski wrote:
>>> On 12/31/18 4:43 PM, Jacek Anaszewski wrote:
>>>> On 12/30/18 6:35 PM, Pavel M
ow up here and let you know that I have not abandoned this.
I am trying to rework and fix up the ti lmu binding as asked by Pavel. Its
proving
to be a bit of a challenge based on looking forward to what will be the
implementation.
I also did go offline and speak with Tony. I have a Droid 4 so I can test all
of this on
production hardware as well.
Updated patchset will take some time to get out.
Dan
>
> Pavel
>
--
--
Dan Murphy
Jacek
On 10/15/2018 02:13 PM, Jacek Anaszewski wrote:
> On 10/15/2018 02:56 AM, Rob Herring wrote:
>> On Sat, Oct 13, 2018 at 1:46 PM Jacek Anaszewski
>> wrote:
>>>
>>> On 10/12/2018 08:03 PM, Pavel Machek wrote:
>>>> Hi!
>>>>
&
f how to do this. Since the 2 devices are part of the
current
binding there really is not a way to move them. Since there are still MFD
capable
devices available.
I would still need to remove the current active binding and create a new
binding in the LED
bindings directory.
I would have to remove and create in the same patch.
Dan
> Thanks,
> Pavel
>
--
--
Dan Murphy
ame" property.
>
> Two existing users of devm_of_led_classdev_registers() are modified
> to use devm_led_classdev_register(), which will not impact their
> operation since they in fact didn't need to pass struct device_node on
> registration from the beginning.
>
> Signed-off-by: Jac
Jacek
On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
> Introduce dedicated properties for conveying information about
> LED function and color. Mark old "label" property as deprecated.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
&
Jacek
On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
> Refer to new "function" and "color" properties and mark "label"
> as deprecated.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Dan Murphy
Acked-by: Dan Murphy
> ---
> Documen
t;
> In case none of the aformentioned properties was found, then, for OF
> nodes, the node name is adopted for LED class device name.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Baolin Wang
> Cc: Daniel Mack
> Cc: Dan Murphy
> Cc: Linus Walleij
> Cc: Oleh Kravche
On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
> Refer to new "function" and "color" properties and mark "label"
> as deprecated.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Dan Murphy
> ---
Acked-by: Dan Murphy
> Documentation/devicetre
On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
> Switch to using generic LED support for composing LED class
> device name.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Dan Murphy
> ---
> drivers/leds/leds-lm3692x.c | 39 ---
> 1 fil
On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
> Refer to new "function" and "color" properties and mark "label"
> as deprecated.
>
> Signed-off-by: Jacek Anaszewski
> Cc: Dan Murphy
> ---
Acked-by: Dan Murphy
> Documentation/devicetree/
On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
> Switch to using generic LED support for composing LED class
> device name.
>
> Signed-off-by: Jacek Anaszewski
> Signed-off-by: Dan Murphy
> ---
> drivers/leds/leds-lp8860.c | 38 +++---
Jacek
On 11/08/2018 02:47 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 11/08/2018 07:00 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
>>> Introduce dedicated properties for conveying information about
>>> LED fun
Jacek
On 11/08/2018 02:48 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 11/08/2018 07:14 PM, Dan Murphy wrote:
>> On 11/06/2018 04:07 PM, Jacek Anaszewski wrote:
>>> Switch to using generic LED support for composing LED class
>>> device name.
>>>
>&g
From: Pavel Machek
This adds backlight support for the following TI LMU
chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
It controls LEDs on Droid 4
smartphone, including keyboard and screen backlights.
Signed-off-by: Milo Kim
[add LED subsystem support for keyboard backlight and rewo
Remove support for the LM3633 from the ti-lmu
driver in favor of a dedicated LED driver.
Signed-off-by: Dan Murphy
---
drivers/mfd/Kconfig | 2 +-
drivers/mfd/ti-lmu.c | 21 -
2 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd
Introduce the LED LM3633 driver. This LED
driver has 9 total LED outputs with runtime
internal ramp configurations.
Data sheet:
http://www.ti.com/lit/ds/symlink/lm3633.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds
Add support for the TI LM3633 LED driver.
This device has 9 control banks 3 high voltage
LED channels and 6 low voltage LED channels.
Data sheet:
http://www.ti.com/lit/ds/symlink/lm3633.pdf
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/leds/leds-lm3633.txt | 102 ++
1
Remove support for the LM3697 LED device
from the ti-lmu. The LM3697 will be supported
via a stand alone LED driver.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/mfd/ti-lmu.txt| 26 +--
1 file changed, 1 insertion(+), 25 deletions(-)
diff --git a/Documentation
Remove support for the LM3697 from the ti-lmu
driver in favor of a dedicated LED driver.
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig| 2 +-
drivers/mfd/Kconfig | 2 +-
drivers/mfd/ti-lmu.c| 17 ---
include/linux/mfd/ti-lmu
Remove support for the LM3633 LED device
from the ti-lmu. The LM3633 will be supported
via a stand alone LED driver.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/mfd/ti-lmu.txt| 48 ---
1 file changed, 48 deletions(-)
diff --git a/Documentation/devicetree
well
as adding additional improvements to that driver.
Dan
Dan Murphy (8):
dt-bindings: ti-lmu: Remove LM3697
mfd: ti-lmu: Remove support for LM3697
dt-bindings: leds: Add bindings for lm3697 driver
leds: lm3697: Introduce the lm3697 driver
dt-bindings: ti-lmu: Remove LM3633
mfd: ti-lmu
Introduce the lm3697 LED driver for
backlighting and display.
Datasheet location:
http://www.ti.com/lit/ds/symlink/lm3697.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +-
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3697.c | 381
Add the device tree bindings for the lm3697
LED driver for backlighting and display.
Signed-off-by: Dan Murphy
---
.../devicetree/bindings/leds/leds-lm3697.txt | 98 +++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt
Pavel
On 10/11/2018 01:27 PM, Pavel Machek wrote:
> On Thu 2018-10-11 11:51:16, Dan Murphy wrote:
>> Remove support for the LM3697 LED device
>> from the ti-lmu. The LM3697 will be supported
>> via a stand alone LED driver.
>>
>> Signed-off-by: Dan Murphy
>
Jacek
On 10/03/2018 03:46 PM, Jacek Anaszewski wrote:
> On 10/03/2018 03:01 PM, Pavel Machek wrote:
>> On Wed 2018-10-03 07:24:23, Dan Murphy wrote:
>>> Hello
>>>
>>> On 10/02/2018 02:28 AM, Pavel Machek wrote:
>>>> On Fri 2018-09-28 13:29:47, Dan M
Pavel
On 10/07/2018 08:46 AM, Pavel Machek wrote:
> On Wed 2018-09-26 08:09:21, Dan Murphy wrote:
>> Add the dedicated TI LM3632 LED driver. This
>> LED device is capable of driving a backlight display.
>>
>> In addition to the backlight the device has control
>
Introduce the lm3697 LED driver for
backlighting and display.
Datasheet location:
http://www.ti.com/lit/ds/symlink/lm3697.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +-
drivers/leds/Makefile | 1 +
drivers/leds/leds-lm3697.c | 381
Introduce the LED LM3633 driver. This LED
driver has 9 total LED outputs with runtime
internal ramp configurations.
Data sheet:
http://www.ti.com/lit/ds/symlink/lm3633.pdf
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig | 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds
Remove support for the LM3633 from the ti-lmu
driver in favor of a dedicated LED driver.
Signed-off-by: Dan Murphy
---
drivers/mfd/Kconfig | 2 +-
drivers/mfd/ti-lmu.c | 21 -
2 files changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd
From: Pavel Machek
This adds backlight support for the following TI LMU
chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
It controls LEDs on Droid 4
smartphone, including keyboard and screen backlights.
Signed-off-by: Milo Kim
[add LED subsystem support for keyboard backlight and rewo
Remove support for the LM3697 from the ti-lmu
driver in favor of a dedicated LED driver.
Signed-off-by: Dan Murphy
---
drivers/leds/Kconfig| 2 +-
drivers/mfd/Kconfig | 2 +-
drivers/mfd/ti-lmu.c| 17 ---
include/linux/mfd/ti-lmu
needs to be moved from the ti-lmu.txt and a dedicated
LED dt binding needs to be added. The new LM3697 LED dt binding will then
reside in the Documentation/devicetree/bindings/leds directory and follow the
current LED and general bindings guidelines.
Signed-off-by: Dan Murphy
---
v4 - Squashed
needs to be moved from the ti-lmu.txt and a dedicated
LED dt binding needs to be added. The new LM3633 LED dt binding will then
reside in the Documentation/devicetree/bindings/leds directory and follow the
current LED and general bindings guidelines.
Signed-off-by: Dan Murphy
---
v4 - Squashed
ed properties:
>>- compatible: Should be one of:
>
> NAK. You can use existing binding.
Thank you for the consistency
Dan
>
> Pavel
>
--
--
Dan Murphy
Pavel
On 10/24/2018 04:14 AM, Pavel Machek wrote:
> On Tue 2018-10-23 12:06:17, Dan Murphy wrote:
>> From: Pavel Machek
>>
>> This adds backlight support for the following TI LMU
>> chips: LM3532, LM3631, LM3632, LM3633, LM3695 and LM3697.
>>
>> It
Rob
Thanks
On 10/24/2018 09:49 AM, Rob Herring wrote:
> On Tue, Oct 23, 2018 at 12:06:18PM -0500, Dan Murphy wrote:
>> The LM3697 is a single function LED driver. The single function LED
>> driver needs to reside in the LED directory as a dedicated LED driver
>> and not
Pavel
On 10/24/2018 04:23 AM, Pavel Machek wrote:
> On Tue 2018-10-23 12:06:21, Dan Murphy wrote:
>> The LM3633 is a single function LED driver. The single function LED
>> driver needs to reside in the LED directory as a dedicated LED driver
>> and not as a MFD device.
Rob
On 10/24/2018 09:54 AM, Rob Herring wrote:
> On Wed, Oct 24, 2018 at 07:07:57AM -0500, Dan Murphy wrote:
>> Pavel
>>
>> On 10/24/2018 04:04 AM, Pavel Machek wrote:
>>> Hi!
>>>
>>>> The LM3697 is a single function LED driver. The single
Jacek
On 10/25/2018 01:27 PM, Jacek Anaszewski wrote:
> On 10/25/2018 08:07 PM, Dan Murphy wrote:
>> Rob
>>
>> On 10/24/2018 09:54 AM, Rob Herring wrote:
>>> On Wed, Oct 24, 2018 at 07:07:57AM -0500, Dan Murphy wrote:
>>>> Pavel
>>>>
>
o bindings/leds pointing to mfd binding.
>
> Now... this is what I've suggested before. If you don't agree, you may
> want to contact Tony Lindgren, IIRC he works for TI, too, and might be
> willing to help.
I will ping Tony just to close the loop. I will be posting v4 today after
making the changes.
I was hoping to have some code review prior to posting v4 but have not received
any comments so
v4 will just be a patch rearrangement.
Dan
>
> Thank you,
> Pavel
>
--
--
Dan Murphy
Rob
Thanks for the review.
On 10/12/2018 11:27 AM, Rob Herring wrote:
> On Thu, Oct 11, 2018 at 11:51:18AM -0500, Dan Murphy wrote:
>> Add the device tree bindings for the lm3697
>> LED driver for backlighting and display.
>
> Bindings are for h/w, not drivers...
>
A
;>>> maintain" more than "binary size".
>>>
>>> Easy to maintain will be a dedicated LED class driver.
>>
>> You mean, 3 dedicated LED class drivers and 3 MFD drivers with LED
>> parts? We'll need complex driver anyway, and I'd really like to have
>> just one.
>
> In the LED subsystem we can wrap common functionalities
> into a library object. MFD driver will be able to reuse it then.
I am currently working on that code now. I expect a RFC on this this week.
Dan
>
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/commit/?h=droid4-pending-v4.19&id=d774c7e447ac911e73a1b3c775e6d89f0422218c
>
--
--
Dan Murphy
Jacek
On 09/17/2018 02:22 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 09/17/2018 05:24 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 09/15/2018 03:00 PM, Jacek Anaszewski wrote:
>>> Hi Pavel.
>>>
>>> On 09/14/2018 11:42 PM, Pavel Machek wrote:
>&g
Andy
On 05/21/2018 06:05 PM, Andy Shevchenko wrote:
> On Tue, May 22, 2018 at 12:44 AM, Dan Murphy wrote:
>
>
>>>> +child = device_get_next_child_node(&led->client->dev, child);
>>>> +if (!child) {
>>>> +dev_err(&led
found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy
---
v8 - Removed OF Kconfig dependency, change strobe to flash, updated label
generation,
fixed brightness calculation, added mutex_destroy and flash_unregister -
https
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Reviewed-by: Rob Herring
Signed-off-by: Dan Murphy
---
v8 - No changes - https://patchwork.kernel.org/patch/10416161/
v7 - Removed led-sources in favor of reg, fixed malformatted ranges -
https
On 05/22/2018 03:12 PM, Andy Shevchenko wrote:
> On Tue, May 22, 2018 at 5:24 PM, Dan Murphy wrote:
>> Introduce the family of LED devices that can
>> drive a torch, strobe or IR LED.
>>
>> The LED driver can be configured with a strobe
>> timer to ex
found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Reviewed-by: Andy Shevchenko
Signed-off-by: Dan Murphy
---
v9 - Changed "strobe" to flash in some cases, removed some redundant variable
assignments, updated a couple of line to make them more readable, co
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Reviewed-by: Rob Herring
Signed-off-by: Dan Murphy
---
v9 - No changes - https://patchwork.kernel.org/patch/10418729/
v8 - No changes - https://patchwork.kernel.org/patch/10416161/
v7 - Removed led
= LM3695_MAX_CHANNELS,
> + .max_brightness = MAX_BRIGHTNESS_11BIT,
> + .pwm_action = UPDATE_PWM_AND_BRT_REGISTER,
> + },
> + {
> + .reginfo = &lm3697_reg_info,
> + .num_channels = LM3697_MAX_CHANNELS,
> + .max_brightness = MAX_BRIGHTNESS_11BIT,
> + .pwm_action = UPDATE_PWM_AND_BRT_REGISTER,
> + .ramp_table = common_ramp_table,
> + .size_ramp = ARRAY_SIZE(common_ramp_table),
> + .fault_monitor_used = true,
> + },
> +};
> diff --git a/drivers/video/backlight/ti-lmu-backlight-data.h
> b/drivers/video/backlight/ti-lmu-backlight-data.h
> new file mode 100644
> index ..c64e8e6513e1
> --- /dev/null
> +++ b/drivers/video/backlight/ti-lmu-backlight-data.h
> @@ -0,0 +1,95 @@
> +/*
Inconsistent licensing here the core has
// SPDX-License-Identifier: GPL-2.0
> + * TI LMU (Lighting Management Unit) Backlight Device Data Definitions
> + *
> + * Copyright 2015 Texas Instruments
> + *
> + * Author: Milo Kim
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __TI_LMU_BACKLIGHT_H__
> +#define __TI_LMU_BACKLIGHT_H__
> +
> +#include
> +#include
> +
> +#define MAX_BRIGHTNESS_8BIT 255
> +#define MAX_BRIGHTNESS_11BIT 2047
> +
> +enum ti_lmu_bl_pwm_action {
> + /* Update PWM duty, no brightness register update is required */
> + UPDATE_PWM_ONLY,
> + /* Update not only duty but also brightness register */
> + UPDATE_PWM_AND_BRT_REGISTER,
> + /* Update max value in brightness registers */
> + UPDATE_MAX_BRT,
> +};
> +
> +struct lmu_bl_reg_data {
> + u8 reg;
> + u8 mask;
> + u8 val;
> +};
> +
> +/**
> + * struct ti_lmu_bl_reg
> + *
> + * @init:Device initialization registers
> + * @num_init:Numbers of initialization registers
> + * @channel: Backlight channel configuration registers
> + * @mode:Brightness control mode registers
> + * @ramp:Ramp registers for lighting effect
> + * @ramp_reg_offset: Ramp register offset.
> + * Only used for multiple ramp registers.
> + * @enable: Enable control register address
> + * @enable_usec: Delay time for updating enable register.
> + * Unit is microsecond.
> + * @brightness_msb: Brightness MSB(Upper 8 bits) registers.
> + * Concatenated with LSB in 11 bit dimming mode.
> + * In 8 bit dimming, only MSB is used.
> + * @brightness_lsb: Brightness LSB(Lower 3 bits) registers.
> + * Only valid in 11 bit dimming mode.
> + */
> +struct ti_lmu_bl_reg {
> + const struct lmu_bl_reg_data *init;
> + int num_init;
> + const struct lmu_bl_reg_data *channel;
> + const struct lmu_bl_reg_data *mode;
> + const struct lmu_bl_reg_data *ramp;
> + int ramp_reg_offset;
> + u8 *enable;
> + unsigned long enable_usec;
> + u8 *brightness_msb;
> + u8 *brightness_lsb;
> +};
> +
> +/**
> + * struct ti_lmu_bl_cfg
> + *
> + * @reginfo: Device register configuration
> + * @num_channels:Number of backlight channels
> + * @max_brightness: Max brightness value of backlight device
> + * @pwm_action: How to control brightness registers in PWM mode
> + * @ramp_table: [Optional] Ramp time table for lighting effect.
> + * It's used for searching approximate register index.
> + * @size_ramp: [Optional] Size of ramp table
> + * @fault_monitor_used: [Optional] Set true if the device needs to
> handle
> + * LMU fault monitor event.
> + *
> + * This structure is used for device specific data configuration.
> + */
> +struct ti_lmu_bl_cfg {
> + const struct ti_lmu_bl_reg *reginfo;
> + int num_channels;
> + int max_brightness;
> + enum ti_lmu_bl_pwm_action pwm_action;
> + int *ramp_table;
> + int size_ramp;
> + bool fault_monitor_used;
> +};
> +
> +extern const struct ti_lmu_bl_cfg lmu_bl_cfg[LMU_MAX_ID];
> +#endif
>
--
--
Dan Murphy
; struct ti_lmu {
> struct device *dev;
> struct regmap *regmap;
> struct gpio_desc *en_gpio;
> + struct pwm_device *pwm;
> struct blocking_notifier_head notifier;
> };
> #endif
>
--
--
Dan Murphy
The CAN error masks header file is in the
include/uapi directory.
Fix the path in the header to the correct location.
Signed-off-by: Dan Murphy
---
include/uapi/linux/can.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/can.h b/include/uapi/linux/can.h
found here:
http://www.ti.com/product/LM36010
http://www.ti.com/product/LM36011
Signed-off-by: Dan Murphy
---
v6 - This driver has been heavily modified from v5. There is no longer reading
of individual child nodes. There are too many changes to list here see -
https://patchwork.kernel.org
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
v6 - Removed multiple led child nodes, fixed example to display micro ranges
for corresponding child nodes and added led-sources to define the current
driver -
https
Jacek
On 05/15/2018 04:13 PM, Jacek Anaszewski wrote:
> Hi Dan,
>
> Thanks for the update.
>
> On 05/15/2018 05:43 PM, Dan Murphy wrote:
>> Introduce the device tree bindings for the lm3601x
>> family of LED torch, flash and IR drivers.
>>
>> Signed-off-by
Jacek
On 05/15/2018 04:24 PM, Jacek Anaszewski wrote:
> Dan,
>
> Thanks for the update. Please refer to my comments below.
>
> On 05/15/2018 05:43 PM, Dan Murphy wrote:
>> Introduce the family of LED devices that can
>> drive a torch, strobe or IR LED.
>>
&g
Andy
Thanks for the review
On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy wrote:
>> Introduce the family of LED devices that can
>> drive a torch, strobe or IR LED.
>>
>> The LED driver can be configured with a strobe
&
On 05/16/2018 03:10 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 05/15/2018 11:29 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 05/15/2018 04:13 PM, Jacek Anaszewski wrote:
>>> Hi Dan,
>>>
>>> Thanks for the update.
>>>
>>> On 05/15/
Andy
The first response is to Jacek the rest are addressed to you
On 05/15/2018 05:24 PM, Andy Shevchenko wrote:
> On Wed, May 16, 2018 at 1:08 AM, Dan Murphy wrote:
>> On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
>>> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy wrote:
>
ed up.
Dan
> On 05/16/2018 12:24 AM, Andy Shevchenko wrote:
>> On Wed, May 16, 2018 at 1:08 AM, Dan Murphy wrote:
>>> On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
>>>> On Tue, May 15, 2018 at 6:43 PM, Dan Murphy wrote:
>>
>>>>> + depends on
Jacek and Andy
On 05/16/2018 04:13 PM, Dan Murphy wrote:
> Jacek and Andy
>
> On 05/16/2018 04:02 PM, Jacek Anaszewski wrote:
>> Hi Andy and Dan,
>>
>
> I will make all the changes then. I don't want to go through and ack each
> one.
>
Let me clarify
Wolfgang
On 2/24/19 5:27 AM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> Am 22.02.19 um 18:05 schrieb Dan Murphy:
>> Wolfgang
>>
>> On 2/22/19 6:50 AM, Dan Murphy wrote:
>>> Wolfgang
>>>
>>> On 2/22/19 3:38 AM, Wolfgang Grandegger wrote:
Wolfgang
On 2/28/19 10:40 AM, Wolfgang Grandegger wrote:
> Hello,
>
> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>> Hello
>>
>> OK I did not give up on this patch series just got a little preoccupied with
>> some other kernel work. But here is the update per
Wolfgang
On 2/28/19 11:33 AM, Wolfgang Grandegger wrote:
> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>> Migrate the m_can code to use the m_can_platform framework
>> code.
>>
>> Signed-off-by: Dan Murphy
>> ---
>>
>> v5 - Updated copyright, chang
Wolfgang
On 2/28/19 11:50 AM, Wolfgang Grandegger wrote:
>
>
> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>> Add the TCAN4x5x SPI CAN driver. This device
>> uses the Bosch MCAN IP core along with a SPI
>> interface map. Leverage the MCAN common core
>> code
Hello
On 2/28/19 1:41 PM, Wolfgang Grandegger wrote:
> Hello Dan,
>
> Am 28.02.19 um 18:57 schrieb Dan Murphy:
>> Wolfgang
>>
>> On 2/28/19 11:33 AM, Wolfgang Grandegger wrote:
>>> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>>>> Migrate the m_can co
Wolfgang
On 2/28/19 2:07 PM, Wolfgang Grandegger wrote:
>
> Am 28.02.19 um 19:03 schrieb Dan Murphy:
>>
>> Wolfgang
>>
>> On 2/28/19 11:50 AM, Wolfgang Grandegger wrote:
>>>
>>>
>>> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>>>&
Wolfgang
On 2/28/19 2:12 PM, Wolfgang Grandegger wrote:
>
> Am 14.02.19 um 19:27 schrieb Dan Murphy:
>> Create a m_can platform framework that peripherial
>> devices can register to and use common code and register sets.
>> The peripherial devices may provide read
Rename the common m_can_priv class structure to
m_can_classdev as this is more descriptive.
Signed-off-by: Dan Murphy
---
v6 - No changes only rebase changes possibly can squash into the first patch -
https://lore.kernel.org/patchwork/patch/1042444/
drivers/net/can/m_can/m_can.c
DT binding documentation for TI TCAN4x5x driver.
Signed-off-by: Dan Murphy
---
v6 - No changes - https://lore.kernel.org/patchwork/patch/1042445/
.../devicetree/bindings/net/can/tcan4x5x.txt | 37 +++
1 file changed, 37 insertions(+)
create mode 100644 Documentation
Create a m_can platform framework that peripherial
devices can register to and use common code and register sets.
The peripherial devices may provide read/write and configuration
support of the IP.
Signed-off-by: Dan Murphy
---
v6 - Squashed platform patch to this patch for bissectablity, fixed
101 - 200 of 1837 matches
Mail list logo
