dt-bindings: trivial: add ti,lm3630a binding

Add a trivial binding for the Texas Instruments LM3630A Backlight Chip.

Signed-off-by: Brian Masney <redacted>
---
 Documentation/devicetree/bindings/trivial-devices.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt
index 6ab001fa1ed4..86486368dc35 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt

@@ -182,6 +182,7 @@ taos,tsl2550		Ambient Light Sensor with SMBUS/Two Wire Serial Interface
 ti,ads7828		8-Channels, 12-bit ADC
 ti,ads7830		8-Channels, 8-bit ADC
 ti,amc6821		Temperature Monitoring and Fan Control
+ti,lm3630a		Texas Instruments LM3630A Backlight Chip
 ti,tsc2003		I2C Touch-Screen Controller
 ti,tmp102		Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
 ti,tmp103		Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface

-- 
2.17.2

From: Jonathan Marek <redacted>

Add device tree support to the lm3630a driver.

Signed-off-by: Jonathan Marek <redacted>
[masneyb@onstation.org: checkpatch fixes; add 'a' to compatible string]
Signed-off-by: Brian Masney <redacted>
---
This is part of upstreaming various components of the LG Nexus 5
(hammerhead) phone.

 drivers/video/backlight/lm3630a_bl.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/video/backlight/lm3630a_bl.c b/drivers/video/backlight/lm3630a_bl.c
index 2030a6b77a09..159d4013d9c2 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c

@@ -470,11 +470,18 @@ static const struct i2c_device_id lm3630a_id[] = {
 	{}
 };
 
+static const struct of_device_id lm3630a_match_table[] = {
+	{ .compatible = "ti,lm3630a", },
+	{ },
+};
+
+
 MODULE_DEVICE_TABLE(i2c, lm3630a_id);
 
 static struct i2c_driver lm3630a_i2c_driver = {
 	.driver = {
 		   .name = LM3630A_NAME,
+		   .of_match_table = lm3630a_match_table,
 		   },
 	.probe = lm3630a_probe,
 	.remove = lm3630a_remove,

-- 
2.17.2

On Sat, Nov 24, 2018 at 09:17:02AM -0500, Brian Masney wrote:

Add a trivial binding for the Texas Instruments LM3630A Backlight Chip.

It's quite unusual for a backlight device to have a trivial binding.

The driver supports fairly extensive parametrization via struct
lm3530a_platform_data. It is really the case that none of these
properties should ever be set via DT?


Daniel.

On Sat, Nov 24, 2018 at 09:17:03AM -0500, Brian Masney wrote:

Similar to my reply to the DT bindings: I would have expected there
to be code to handle DT properties here.


Daniel.

 
+static const struct of_device_id lm3630a_match_table[] = {
+	{ .compatible = "ti,lm3630a", },
+	{ },
+};
+
+
 MODULE_DEVICE_TABLE(i2c, lm3630a_id);
 
 static struct i2c_driver lm3630a_i2c_driver = {
 	.driver = {
 		   .name = LM3630A_NAME,
+		   .of_match_table = lm3630a_match_table,
 		   },
 	.probe = lm3630a_probe,
 	.remove = lm3630a_remove,
-- 
2.17.2

On Tue, Nov 27, 2018 at 10:56:42AM +0000, Daniel Thompson wrote:

On Sat, Nov 24, 2018 at 09:17:02AM -0500, Brian Masney wrote:

quoted

Add a trivial binding for the Texas Instruments LM3630A Backlight Chip.

It's quite unusual for a backlight device to have a trivial binding.

The driver supports fairly extensive parametrization via struct
lm3530a_platform_data. It is really the case that none of these
properties should ever be set via DT?

Hi Daniel,

I initially assumed that we would let user space configure these values
once the system has booted, but you are right that these should be
available in device tree.
 
The driver has two different LED banks that can be configured
independently. How do you feel about having a single property in
device tree populate the initial values for both banks? I propose that
we could use the property default-brightness-level for leda_init_brt
and ledb_init_brt in struct lm3630a_platform_data. The max-brightness
property can populate leda_max_brt and ledb_max_brt.

I need to look at other bindings this weekend to see if there are any
standard properties that I can use for leda_ctrl/ledb_ctrl, pwm_ctrl,
and pwm_period.

Brian

quoted

Signed-off-by: Brian Masney <redacted>
---
 Documentation/devicetree/bindings/trivial-devices.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/trivial-devices.txt b/Documentation/devicetree/bindings/trivial-devices.txt
index 6ab001fa1ed4..86486368dc35 100644
--- a/Documentation/devicetree/bindings/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/trivial-devices.txt

@@ -182,6 +182,7 @@ taos,tsl2550		Ambient Light Sensor with SMBUS/Two Wire Serial Interface
 ti,ads7828		8-Channels, 12-bit ADC
 ti,ads7830		8-Channels, 8-bit ADC
 ti,amc6821		Temperature Monitoring and Fan Control
+ti,lm3630a		Texas Instruments LM3630A Backlight Chip
 ti,tsc2003		I2C Touch-Screen Controller
 ti,tmp102		Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
 ti,tmp103		Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface

-- 
2.17.2

+Dan M

On Fri, Nov 30, 2018 at 7:59 AM Brian Masney [off-list ref] wrote:

On Tue, Nov 27, 2018 at 10:56:42AM +0000, Daniel Thompson wrote:

quoted

On Sat, Nov 24, 2018 at 09:17:02AM -0500, Brian Masney wrote:

quoted

Add a trivial binding for the Texas Instruments LM3630A Backlight Chip.

How does this chip relate to ones Dan has been working on?

quoted

It's quite unusual for a backlight device to have a trivial binding.

The driver supports fairly extensive parametrization via struct
lm3530a_platform_data. It is really the case that none of these
properties should ever be set via DT?

Hi Daniel,

I initially assumed that we would let user space configure these values
once the system has booted, but you are right that these should be
available in device tree.

The driver has two different LED banks that can be configured
independently.

That is usually represented with child nodes which makes this anything
but trivial. Plus, given that we have bindings for LEDs/backlights, no
LED/backlight controller is a trivial device.

How do you feel about having a single property in
device tree populate the initial values for both banks? I propose that
we could use the property default-brightness-level for leda_init_brt
and ledb_init_brt in struct lm3630a_platform_data. The max-brightness
property can populate leda_max_brt and ledb_max_brt.

I need to look at other bindings this weekend to see if there are any
standard properties that I can use for leda_ctrl/ledb_ctrl, pwm_ctrl,
and pwm_period.

Brian

On Fri, Nov 30, 2018 at 08:13:04AM -0600, Rob Herring wrote:

quoted

quoted

It's quite unusual for a backlight device to have a trivial binding.

The driver supports fairly extensive parametrization via struct
lm3530a_platform_data. It is really the case that none of these
properties should ever be set via DT?

Hi Daniel,

I initially assumed that we would let user space configure these values
once the system has booted, but you are right that these should be
available in device tree.

The driver has two different LED banks that can be configured
independently.

That is usually represented with child nodes which makes this anything
but trivial. Plus, given that we have bindings for LEDs/backlights, no
LED/backlight controller is a trivial device.

Hi Rob,

I agree and I'm not going to use a trivial binding for v2. See below for
some questions that I have from my last email.

quoted

How do you feel about having a single property in
device tree populate the initial values for both banks? I propose that
we could use the property default-brightness-level for leda_init_brt
and ledb_init_brt in struct lm3630a_platform_data. The max-brightness
property can populate leda_max_brt and ledb_max_brt.

I need to look at other bindings this weekend to see if there are any
standard properties that I can use for leda_ctrl/ledb_ctrl, pwm_ctrl,
and pwm_period.

Brian

Rob/Brian

On 11/30/2018 08:13 AM, Rob Herring wrote:

+Dan M

On Fri, Nov 30, 2018 at 7:59 AM Brian Masney [off-list ref] wrote:

quoted

On Tue, Nov 27, 2018 at 10:56:42AM +0000, Daniel Thompson wrote:

quoted

On Sat, Nov 24, 2018 at 09:17:02AM -0500, Brian Masney wrote:

quoted

Add a trivial binding for the Texas Instruments LM3630A Backlight Chip.

How does this chip relate to ones Dan has been working on?

This is a standard 8-bit white LED driver.  It looks like Brian is just adding DT
support to load the driver.

I would expect that the bindings need to be updated to be able to register one string or
another using the led-sources property.  There are a couple of examples in the kernel and
a couple of them in patch form.

This driver and binding need to be updated to the latest spec, as you pointed out with child nodes.

And Jacek has some new proposed bindings for the LED class so we may want to adopt those standards here
as well.  This is what I am waiting on for agreement so I can update my patch set.

Dan

quoted

quoted

It's quite unusual for a backlight device to have a trivial binding.

The driver supports fairly extensive parametrization via struct
lm3530a_platform_data. It is really the case that none of these
properties should ever be set via DT?

Hi Daniel,

I initially assumed that we would let user space configure these values
once the system has booted, but you are right that these should be
available in device tree.

The driver has two different LED banks that can be configured
independently.

That is usually represented with child nodes which makes this anything
but trivial. Plus, given that we have bindings for LEDs/backlights, no
LED/backlight controller is a trivial device.

quoted

How do you feel about having a single property in
device tree populate the initial values for both banks? I propose that
we could use the property default-brightness-level for leda_init_brt
and ledb_init_brt in struct lm3630a_platform_data. The max-brightness
property can populate leda_max_brt and ledb_max_brt.

I need to look at other bindings this weekend to see if there are any
standard properties that I can use for leda_ctrl/ledb_ctrl, pwm_ctrl,
and pwm_period.

Brian

-- 
------------------
Dan Murphy