Skip to contentSkip to conversation

backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3

PATCH In review Brian Dodge 4 participants 14 messages Nov 7, 2018 – Jun 24, 2019

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

cover backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3

The vendor-prefix.txt file correctly uses the prefix arctic for ArcticSand. The ArcticSand driver and the device tree bindings for it incorreclty use just arc. This mismatch was an error in the original patchset for the driver and is fixed in the first two patches here.

ArcticSand has been purchased by Peregrine Semiconductor, now pSemi. The company wishes to continue using the ArcticSand name and arctic prefix for its LED backlight drivers.

There are two newer chips created by ArcticSand team. The chips are very similar to the arc2 chip supported by the current kernel driver. Support for the two new chips (arc1 family and arc3 family) is added here based on reading the chip id via i2c in probe and making minor adjustments to ranges and register addresses based on the id.

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#1 lore raw

PATCH 1/3 dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver bindings improperly abbreviated the prefix to arc. This was a mistake in the original patch

---
 .../bindings/leds/backlight/arcxcnn_bl.txt           | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)
Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt +10 -10
index 230abde..dcaa239 100644
@@ -1,8 +1,8 @@
-Binding for ArcticSand arc2c0608 LED driver
+Binding for ArcticSand arc family LED drivers
 
 Required properties:
-- compatible:		should be "arc,arc2c0608"
-- reg:			slave address
+- compatible:	"arctic,arc1c0608", "arctic,arc2c0608", "arctic,arc3c0845"
+- reg:		slave address
 
 Optional properties:
 - default-brightness:	brightness value on boot, value from: 0-4095
@@ -11,19 +11,19 @@ Optional properties:
 - led-sources:		List of enabled channels from 0 to 5.
 			See Documentation/devicetree/bindings/leds/common.txt
 
-- arc,led-config-0:	setting for register ILED_CONFIG_0
-- arc,led-config-1:	setting for register ILED_CONFIG_1
-- arc,dim-freq:		PWM mode frequence setting (bits [3:0] used)
-- arc,comp-config:	setting for register CONFIG_COMP
-- arc,filter-config:	setting for register FILTER_CONFIG
-- arc,trim-config:	setting for register IMAXTUNE
+- arctic,led-config-0:	setting for register ILED_CONFIG_0
+- arctic,led-config-1:	setting for register ILED_CONFIG_1
+- arctic,dim-freq:		PWM mode frequence setting (bits [3:0] used)
+- arctic,comp-config:	setting for register CONFIG_COMP
+- arctic,filter-config:	setting for register FILTER_CONFIG
+- arctic,trim-config:	setting for register IMAXTUNE
 
 Note: Optional properties not specified will default to values in IC EPROM
 
 Example:
 
 arc2c0608@30 {
-	compatible = "arc,arc2c0608";
+	compatible = "arctic,arc2c0608";
 	reg = <0x30>;
 	default-brightness = <500>;
 	label = "lcd-backlight";

--
2.7.4

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

maintainer
#2 lore raw

Re: [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings

Quoted 4 lines · Brian Dodge

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver bindings improperly abbreviated the prefix to arc. This was a mistake in the original patch

Are there any users and are they okay with this changing?

Quoted 10 lines
---
 .../bindings/leds/backlight/arcxcnn_bl.txt           | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)
Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt +0 -0
index 230abde..dcaa239 100644

Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt line 4

Quoted 7 lines
Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt +2 -3
@@ -1,8 +1,8 @@
-Binding for ArcticSand arc2c0608 LED driver
+Binding for ArcticSand arc family LED drivers
 
 Required properties:
-- compatible:		should be "arc,arc2c0608"
-- reg:			slave address
+- compatible:	"arctic,arc1c0608", "arctic,arc2c0608", "arctic,arc3c0845"

Format one per line please.

Quoted 32 lines
Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt +8 -8
+- reg:		slave address
 
 Optional properties:
 - default-brightness:	brightness value on boot, value from: 0-4095
@@ -11,19 +11,19 @@ Optional properties:
 - led-sources:		List of enabled channels from 0 to 5.
 			See Documentation/devicetree/bindings/leds/common.txt
 
-- arc,led-config-0:	setting for register ILED_CONFIG_0
-- arc,led-config-1:	setting for register ILED_CONFIG_1
-- arc,dim-freq:		PWM mode frequence setting (bits [3:0] used)
-- arc,comp-config:	setting for register CONFIG_COMP
-- arc,filter-config:	setting for register FILTER_CONFIG
-- arc,trim-config:	setting for register IMAXTUNE
+- arctic,led-config-0:	setting for register ILED_CONFIG_0
+- arctic,led-config-1:	setting for register ILED_CONFIG_1
+- arctic,dim-freq:		PWM mode frequence setting (bits [3:0] used)
+- arctic,comp-config:	setting for register CONFIG_COMP
+- arctic,filter-config:	setting for register FILTER_CONFIG
+- arctic,trim-config:	setting for register IMAXTUNE
 
 Note: Optional properties not specified will default to values in IC EPROM
 
 Example:
 
 arc2c0608@30 {
-	compatible = "arc,arc2c0608";
+	compatible = "arctic,arc2c0608";
 	reg = <0x30>;
 	default-brightness = <500>;
 	label = "lcd-backlight";
--
Quoted 2 lines

2.7.4

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#3 lore raw

PATCH 2/3 backlight/arcxcnn fix vendor prefix

In reply to Brian Dodge

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch

---
 drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)
drivers/video/backlight/arcxcnn_bl.c +11 -11
index dec790d..bebefc6 100644
@@ -1,8 +1,8 @@
 /*
- * Backlight driver for ArcticSand ARC_X_C_0N_0N Devices
+ * Backlight driver for pSemi (formerly ArcticSand) ARC_X_C_0N_0N Devices
  *
- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge <[email protected]>
+ * Copyright 2018 pSemi, Inc.
+ * Author : Brian Dodge <[email protected]>
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of the GNU General Public License version 2
@@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
 	if (ret == 0)
 		lp->pdata->initial_brightness = prog_val;
 
-	ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+	ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
 	if (ret == 0)
 		lp->pdata->led_config_0 = (u8)prog_val;
 
-	ret = of_property_read_u32(node, "arc,led-config-1", &prog_val);
+	ret = of_property_read_u32(node, "arctic,led-config-1", &prog_val);
 	if (ret == 0)
 		lp->pdata->led_config_1 = (u8)prog_val;
 
-	ret = of_property_read_u32(node, "arc,dim-freq", &prog_val);
+	ret = of_property_read_u32(node, "arctic,dim-freq", &prog_val);
 	if (ret == 0)
 		lp->pdata->dim_freq = (u8)prog_val;
 
-	ret = of_property_read_u32(node, "arc,comp-config", &prog_val);
+	ret = of_property_read_u32(node, "arctic,comp-config", &prog_val);
 	if (ret == 0)
 		lp->pdata->comp_config = (u8)prog_val;
 
-	ret = of_property_read_u32(node, "arc,filter-config", &prog_val);
+	ret = of_property_read_u32(node, "arctic,filter-config", &prog_val);
 	if (ret == 0)
 		lp->pdata->filter_config = (u8)prog_val;
 
-	ret = of_property_read_u32(node, "arc,trim-config", &prog_val);
+	ret = of_property_read_u32(node, "arctic,trim-config", &prog_val);
 	if (ret == 0)
 		lp->pdata->trim_config = (u8)prog_val;
 
@@ -392,7 +392,7 @@ static int arcxcnn_remove(struct i2c_client *cl)
 }
 
 static const struct of_device_id arcxcnn_dt_ids[] = {
-	{ .compatible = "arc,arc2c0608" },
+	{ .compatible = "arctic,arc2c0608" },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
@@ -415,5 +415,5 @@ static struct i2c_driver arcxcnn_driver = {
 module_i2c_driver(arcxcnn_driver);
 
 MODULE_LICENSE("GPL v2");
-MODULE_AUTHOR("Brian Dodge <[email protected]>");
+MODULE_AUTHOR("Brian Dodge <[email protected]>");
 MODULE_DESCRIPTION("ARCXCNN Backlight driver");

--
2.7.4

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#4 lore raw

Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

Hi!

Quoted 9 lines

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch

---
 drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)
Quoted 5 lines

*
- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge <[email protected]>
+ * Copyright 2018 pSemi, Inc.
+ * Author : Brian Dodge <[email protected]>

Ummm. Copyright 2016-2018?

drivers/video/backlight/arcxcnn_bl.c static void arcxcnn_parse_dt(struct arcxcnn *lp) · line 208

Quoted 9 lines
drivers/video/backlight/arcxcnn_bl.c +1 -1
@@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
 	if (ret == 0)
 		lp->pdata->initial_brightness = prog_val;
 
-	ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+	ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
 	if (ret == 0)
 		lp->pdata->led_config_0 = (u8)prog_val;
 

If there's a dts using this, you want to update it at the same time. You may want to support both names going forward.
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#5 lore raw

Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Quoted 22 lines · Pavel Machek

Hi!

Quoted 9 lines

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch

---
  drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
  1 file changed, 11 insertions(+), 11 deletions(-)
Quoted 5 lines
   *

- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge <[email protected]>
+ * Copyright 2018 pSemi, Inc.
+ * Author : Brian Dodge <[email protected]>

Ummm. Copyright 2016-2018?

Quoted 4 lines
drivers/video/backlight/arcxcnn_bl.c +0 -0
@@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
  	if (ret == 0)
  		lp->pdata->initial_brightness = prog_val;
 
Quoted 8 lines

drivers/video/backlight/arcxcnn_bl.c static void arcxcnn_parse_dt(struct arcxcnn *lp) · line 208

Quoted 5 lines
drivers/video/backlight/arcxcnn_bl.c +1 -1
-	ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+	ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
  	if (ret == 0)
  		lp->pdata->led_config_0 = (u8)prog_val;
 

If there's a dts using this, you want to update it at the same time. You may want to support both names going forward.
Pavel

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#6 lore raw

Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

Hi Brian

Quoted 6 lines · Brian Dodge

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Looks like this patch series has fallen into the cracks a little.

I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor.

Daniel.

Quoted 31 lines · Pavel Machek
Quoted 22 lines

Hi!

Quoted 9 lines

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch

---
  drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
  1 file changed, 11 insertions(+), 11 deletions(-)
Quoted 5 lines
   *

- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge <[email protected]>
+ * Copyright 2018 pSemi, Inc.
+ * Author : Brian Dodge <[email protected]>

Ummm. Copyright 2016-2018?

Quoted 4 lines
drivers/video/backlight/arcxcnn_bl.c +0 -0
@@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
     if (ret == 0)
             lp->pdata->initial_brightness = prog_val;
 
Quoted 8 lines

drivers/video/backlight/arcxcnn_bl.c static void arcxcnn_parse_dt(struct arcxcnn *lp) · line 208

Quoted 5 lines
drivers/video/backlight/arcxcnn_bl.c +1 -1
-    ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+    ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
     if (ret == 0)
             lp->pdata->led_config_0 = (u8)prog_val;
 

If there's a dts using this, you want to update it at the same time. You may want to support both names going forward.

Quoted 2 lines

Pavel

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#7 lore raw

Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

In reply to Brian Dodge

[Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer]

Quoted 3 lines · Brian Dodge

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Looks like this patch series has fallen into the cracks a little.

I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor.

Daniel.

Quoted 24 lines · Pavel Machek
Quoted 22 lines

Hi!

Quoted 7 lines

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch

---
  drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------

Quoted 7 lines
  1 file changed, 11 insertions(+), 11 deletions(-)

   *
- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge <[email protected]>
+ * Copyright 2018 pSemi, Inc.
+ * Author : Brian Dodge <[email protected]>

Ummm. Copyright 2016-2018?

Quoted 4 lines
drivers/video/backlight/arcxcnn_bl.c +0 -0
@@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
       if (ret == 0)
           lp->pdata->initial_brightness = prog_val;
 
Quoted 8 lines
Quoted 8 lines

drivers/video/backlight/arcxcnn_bl.c static void arcxcnn_parse_dt(struct arcxcnn *lp) · line 208

Quoted 5 lines
drivers/video/backlight/arcxcnn_bl.c +1 -1
-    ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+    ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val);
       if (ret == 0)
           lp->pdata->led_config_0 = (u8)prog_val;
 

If there's a dts using this, you want to update it at the same time. You may want to support both names going forward. Pavel

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#8 lore raw

Re: Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

Quoted 10 lines · Daniel Thompson

[Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer]

Quoted 3 lines · Brian Dodge

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Looks like this patch series has fallen into the cracks a little.

I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor.

In fact there's a publicly available example using this binding:
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/factory-gru-8652.B-chromeos-4.4/arch/arm64/boot/dts/rockchip/rk3399-gru-gru.dtsi

I'm not sure it could be changed without maintaining support for old names.

Daniel.

Quoted 39 lines

Daniel.

Quoted 33 lines · Pavel Machek
Quoted 31 lines

Hi!

Quoted 7 lines

The vendor-prefixes.txt file properly refers to ArcticSand as arctic but the driver improperly abbreviated the prefix to arc. This was a mistake in the original patch

---
  drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------

Quoted 7 lines
  1 file changed, 11 insertions(+), 11 deletions(-)

   *
- * Copyright 2016 ArcticSand, Inc.
- * Author : Brian Dodge <[email protected]>
+ * Copyright 2018 pSemi, Inc.
+ * Author : Brian Dodge <[email protected]>

Ummm. Copyright 2016-2018?

drivers/video/backlight/arcxcnn_bl.c static void arcxcnn_parse_dt(struct arcxcnn *lp) · line 209

Quoted 10 lines
drivers/video/backlight/arcxcnn_bl.c +1 -1
@@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
       if (ret == 0)
           lp->pdata->initial_brightness = prog_val;
 
-    ret = of_property_read_u32(node, "arc,led-config-0", &prog_val);
+    ret = of_property_read_u32(node, "arctic,led-config-0", 
 &prog_val);
       if (ret == 0)
           lp->pdata->led_config_0 = (u8)prog_val;
 

If there's a dts using this, you want to update it at the same time. You may want to support both names going forward. Pavel

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#9 lore raw

Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

In reply to Daniel Thompson

Hi!

Quoted 12 lines

[Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer]

Quoted 5 lines · Brian Dodge

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Looks like this patch series has fallen into the cracks a little.

Quoted 7 lines

I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor.

So in next email you give good reason not to apply this :-).

Anyway, this is Doc*/devicetree/, so not my area.
Pavel

Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#10 lore raw

Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

Quoted 22 lines · Pavel Machek

Hi!

Quoted 12 lines

[Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer]

Quoted 5 lines · Brian Dodge

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Looks like this patch series has fallen into the cracks a little.

Quoted 7 lines

I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor.

Quoted 1 line

So in next email you give good reason not to apply this :-).

Afraid so... it was on page 2 of my google search so I did a quick search, sent the first mail and then went back to my web browser.

It was at that moment that I decided a quick search wasn't enough and decided to got a little deeper!

Daniel.
_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#11 lore raw

Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

This sure did fall through the cracks.

I confirmed with the vendor that there are no existing embedded DTS with the wrong name(s) in them before submitting this patch.

The new owner of this chip family, pSemi, just wanted me to wrap things up and support all of there chips (3) in a single driver and that was the extent of the work for me.  Since then the manager of the program there has also changed.  I assume they'd still want these changes in for completeness.

AFAIK, there were just some quibbles about the copyright date range.  Can you please help me push these patches in? It'll take me some time to get back in to where I left things  since its been so long.  I know its a bit messy but the DTS and driver changes need to be together to make sense so I couldn't really do an incremental patch sequence.

What is the next step?

Brian

Quoted 22 lines · Daniel Thompson
Quoted 13 lines · Pavel Machek

Hi!

Quoted 11 lines

[Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer]

Quoted 5 lines · Brian Dodge

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Looks like this patch series has fallen into the cracks a little.

Quoted 8 lines
Quoted 7 lines

I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor.

So in next email you give good reason not to apply this :-).

Quoted 8 lines

Afraid so... it was on page 2 of my google search so I did a quick search, sent the first mail and then went back to my web browser.

It was at that moment that I decided a quick search wasn't enough and decided to got a little deeper!

Daniel.

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#12 lore raw

Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix

Quoted 10 lines · Brian Dodge

This sure did fall through the cracks.

I confirmed with the vendor that there are no existing embedded DTS with the wrong name(s) in them before submitting this patch.

The new owner of this chip family, pSemi, just wanted me to wrap things up and support all of there chips (3) in a single driver and that was the extent of the work for me.  Since then the manager of the program there has also changed.  I assume they'd still want these changes in for completeness.

Quoted 7 lines

AFAIK, there were just some quibbles about the copyright date range.  Can you please help me push these patches in? It'll take me some time to get back in to where I left things  since its been so long.  I know its a bit messy but the DTS and driver changes need to be together to make sense so I couldn't really do an incremental patch sequence.

What is the next step?

The next step is getting the changes to DT bindings agreed. Until that happens the patchset cannot move and right now now the thread for that patch has feedback that was not replies to:
https://patchwork.kernel.org/patch/10675451/

The explanation of why it is safe to accept the change to the DT bindings really should end up in the patch description rather than the mail thread. It would probably also help to have a link to
https://lkml.org/lkml/2018/9/25/726 where it looks like arc versus arctic was previously discussed.

The following might also be convenient for you:

A quick web search for "arc,arc2c0608" suggests that the only public user is the Samsung Chromebook Plus and it is likely that this device will remain on the v4.4 kernel. For this reason we do not provide any deprecated fallback names based on "arc".

Daniel.

Quoted 34 lines

Brian

Quoted 30 lines · Daniel Thompson
Quoted 13 lines · Pavel Machek

Hi!

Quoted 11 lines

[Sorry to those receiving this twice... had to dig this out from the archives and sent it to the lists from the wrong mailer]

Quoted 5 lines · Brian Dodge

Thank you Pavel, that is a good point.

The chip vendor has indicated that there is no reason to maintain the old/improper prefix and wishes to go forward (only) with the "arctic" prefix and any existing dts files are or will be updated.

Looks like this patch series has fallen into the cracks a little.

Quoted 8 lines
Quoted 7 lines

I think I assumed this info would end in the description of patch v2 1/3 (in order to answer Rob's feedback) and I sat and waited for a respin. On the other hand... I didn't actually say that explicitly anywhere! So... I'd recommend a respin perhaps with a small bit of text explaining how the vendor can state that any existing dts files will be updated. This is a peripheral device so these strings are probably embedded into OEM devicetrees rather than exclusively under the control of the vendor.

So in next email you give good reason not to apply this :-).

Afraid so... it was on page 2 of my google search so I did a quick search, sent the first mail and then went back to my web browser.

It was at that moment that I decided a quick search wasn't enough and decided to got a little deeper!

Daniel.

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel

#13 lore raw

PATCH 3/3 backlight/arcxcnn add support for arc1 an arc3 chip families

In reply to Brian Dodge

Support for newer ArcticSand LED drivers is added. The i2c device id is used to modify some limits and set some device specific register addresses

---
 drivers/video/backlight/arcxcnn_bl.c | 261 +++++++++++++++++++++++++----------
 1 file changed, 190 insertions(+), 71 deletions(-)
drivers/video/backlight/arcxcnn_bl.c +190 -71
index bebefc6..30c07cb 100644
@@ -25,7 +25,9 @@
 #include <linux/slab.h>
 
 enum arcxcnn_chip_id {
-	ARC2C0608
+	ARC1C0608,
+	ARC2C0608,
+	ARC3C0845
 };
 
 /**
@@ -64,42 +66,77 @@ struct arcxcnn_platform_data {
 #define ARCXCNN_CMD_EXT_COMP	0x01	/*   part (0) or full (1) ext. comp */
 
 #define ARCXCNN_CONFIG		0x01	/* Configuration */
-#define ARCXCNN_STATUS1		0x02	/* Status 1 */
-#define ARCXCNN_STATUS2		0x03	/* Status 2 */
+
+#define ARCXCNN_STATUS1		0x02	/* Status 1 (6 str) */
+#define ARCXCNN_STATUS2		0x03	/* Status 2 (6 str)*/
 #define ARCXCNN_FADECTRL	0x04	/* Fading Control */
+#define ARC3CNN_FADECTRL	0x02	/* Fading Control */
 #define ARCXCNN_ILED_CONFIG	0x05	/* ILED Configuration */
+#define ARC3CNN_ILED_CONFIG	0x03	/* ILED Configuration */
 #define ARCXCNN_ILED_DIM_PWM	0x00	/*   config dim mode pwm */
-#define ARCXCNN_ILED_DIM_INT	0x04	/*   config dim mode internal */
-#define ARCXCNN_LEDEN		0x06	/* LED Enable Register */
+#define ARCXCNN_ILED_DIM_INT	0x44	/*   config dim mode int+iset (6 str) */
+#define ARC3CNN_ILED_DIM_INT	0x20	/*   config dim mode internal (8 str) */
+#define ARCXCNN_LEDEN		0x06	/* LED Enable Register (6 str) */
+#define ARC3CNN_LEDEN		0x04	/* LED Enable Register (8 str) */
+
 #define ARCXCNN_LEDEN_ISETEXT	0x80	/*   Full-scale current set extern */
-#define ARCXCNN_LEDEN_MASK	0x3F	/*   LED string enables mask */
-#define ARCXCNN_LEDEN_BITS	0x06	/*   Bits of LED string enables */
+
+#define ARCXCNN_LEDEN_MASK	0x3F	/*   LED string enables mask (6 str) */
+#define ARCXCNN_LEDEN_BITS	0x06	/*   Bits of string enables (6 str) */
+#define ARC3CNN_LEDEN_MASK	0xFF	/*   LED string enables mask (8 str) */
+#define ARC3CNN_LEDEN_BITS	0x08	/*   Bits of string enables (8 str) */
 #define ARCXCNN_LEDEN_LED1	0x01
 #define ARCXCNN_LEDEN_LED2	0x02
 #define ARCXCNN_LEDEN_LED3	0x04
 #define ARCXCNN_LEDEN_LED4	0x08
 #define ARCXCNN_LEDEN_LED5	0x10
 #define ARCXCNN_LEDEN_LED6	0x20
+#define ARCXCNN_LEDEN_LED7	0x40
+#define ARCXCNN_LEDEN_LED8	0x80
+
+#define ARCXCNN_WLED_ISET_LSB		0x07	/* LED ISET LSB */
+#define ARCXCNN_WLED_ISET_LSB_SHIFT	0x04	/* ISET LSB Left Shift */
+#define ARCXCNN_WLED_ISET_MSB		0x08	/* LED ISET MSB (8 bits) */
+#define ARC3CNN_WLED_ISET_LSB		0x05	/* LED ISET LSB */
+#define ARC3CNN_WLED_ISET_LSB_SHIFT	0x01	/* ISET LSB Left Shift */
+#define ARC3CNN_WLED_ISET_MSB		0x06	/* LED ISET MSB (8 bits) */
 
-#define ARCXCNN_WLED_ISET_LSB	0x07	/* LED ISET LSB (in upper nibble) */
-#define ARCXCNN_WLED_ISET_LSB_SHIFT 0x04  /* ISET LSB Left Shift */
-#define ARCXCNN_WLED_ISET_MSB	0x08	/* LED ISET MSB (8 bits) */
+#define ARC2CNN_DIMFREQ		0x09
+
+/* NO COMP CONFIG OR FILT CONFIG IN ARC1CNN */
+#define ARC2CNN_COMP_CONFIG	0x0A
+#define ARC3CNN_COMP_CONFIG	0x08
+#define ARC2CNN_FILT_CONFIG	0x0B
+#define ARC3CNN_FILT_CONFIG	0x09
+
+#define ARC3CNN_FILT_DIMCODE    0x60	/* Force DITHER_ENABLE and code 01 */
+
+#define ARC2CNN_IMAXTUNE	0x0C
+#define ARC3CNN_IMAXTUNE	0x0A
 
-#define ARCXCNN_DIMFREQ		0x09
-#define ARCXCNN_COMP_CONFIG	0x0A
-#define ARCXCNN_FILT_CONFIG	0x0B
-#define ARCXCNN_IMAXTUNE	0x0C
 #define ARCXCNN_ID_MSB		0x1E
 #define ARCXCNN_ID_LSB		0x1F
+#define ARC3CNN_ID_MSB		0xFE
+#define ARC3CNN_ID_LSB		0xFF
 
-#define MAX_BRIGHTNESS		4095
-#define INIT_BRIGHT		60
+#define ARC_MAX_BRIGHTNESS_1	4095
+#define ARC_MAX_BRIGHTNESS_2	4095
+#define ARC_MAX_BRIGHTNESS_3	32767
+#define ARC_INIT_BRIGHT		60
 
 struct arcxcnn {
 	struct i2c_client *client;
 	struct backlight_device *bl;
 	struct device *dev;
 	struct arcxcnn_platform_data *pdata;
+	u8 chipid;
+	u16 max_brightness;
+	u8 rst_reg;
+	u8 fade_reg;
+	u8 iled_config_reg, dim_mode_bits;
+	u8 iset_lsb_reg, iset_msb_reg, iset_shift;
+	u8 leden_reg, leden_mask, leden_bits;
+	u8 comp_config_reg, filter_reg, maxtune_reg;
 };
 
 static int arcxcnn_update_field(struct arcxcnn *lp, u8 reg, u8 mask, u8 data)
@@ -125,17 +162,16 @@ static int arcxcnn_set_brightness(struct arcxcnn *lp, u32 brightness)
 	int ret;
 	u8 val;
 
-	/* lower nibble of brightness goes in upper nibble of LSB register */
-	val = (brightness & 0xF) << ARCXCNN_WLED_ISET_LSB_SHIFT;
+	/* brightness is split across two registers */
+	val = brightness << lp->iset_shift;
 	ret = i2c_smbus_write_byte_data(lp->client,
-		ARCXCNN_WLED_ISET_LSB, val);
+		lp->iset_lsb_reg, val);
 	if (ret < 0)
 		return ret;
 
-	/* remaining 8 bits of brightness go in MSB register */
-	val = (brightness >> 4);
+	val = (u8)(brightness >> (8 - lp->iset_shift));
 	return i2c_smbus_write_byte_data(lp->client,
-		ARCXCNN_WLED_ISET_MSB, val);
+		lp->iset_msb_reg, val);
 }
 
 static int arcxcnn_bl_update_status(struct backlight_device *bl)
@@ -152,7 +188,7 @@ static int arcxcnn_bl_update_status(struct backlight_device *bl)
 		return ret;
 
 	/* set power-on/off/save modes */
-	return arcxcnn_update_field(lp, ARCXCNN_CMD, ARCXCNN_CMD_STDBY,
+	return arcxcnn_update_field(lp, lp->rst_reg, ARCXCNN_CMD_STDBY,
 		(bl->props.power == 0) ? 0 : ARCXCNN_CMD_STDBY);
 }
 
@@ -171,7 +207,7 @@ static int arcxcnn_backlight_register(struct arcxcnn *lp)
 		return -ENOMEM;
 
 	props->type = BACKLIGHT_PLATFORM;
-	props->max_brightness = MAX_BRIGHTNESS;
+	props->max_brightness = lp->max_brightness;
 
 	if (lp->pdata->initial_brightness > props->max_brightness)
 		lp->pdata->initial_brightness = props->max_brightness;
@@ -187,7 +223,7 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
 {
 	struct device *dev = lp->dev;
 	struct device_node *node = dev->of_node;
-	u32 prog_val, num_entry, entry, sources[ARCXCNN_LEDEN_BITS];
+	u32 prog_val, num_entry, entry, sources[ARC3CNN_LEDEN_BITS];
 	int ret;
 
 	/* device tree entry isn't required, defaults are OK */
@@ -228,11 +264,11 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp)
 
 	ret = of_property_count_u32_elems(node, "led-sources");
 	if (ret < 0) {
-		lp->pdata->leden = ARCXCNN_LEDEN_MASK; /* all on is default */
+		lp->pdata->leden = lp->leden_mask; /* all on is default */
 	} else {
 		num_entry = ret;
-		if (num_entry > ARCXCNN_LEDEN_BITS)
-			num_entry = ARCXCNN_LEDEN_BITS;
+		if (num_entry > lp->leden_bits)
+			num_entry = lp->leden_bits;
 
 		ret = of_property_read_u32_array(node, "led-sources", sources,
 					num_entry);
@@ -266,14 +302,84 @@ static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
 
 	lp->client = cl;
 	lp->dev = &cl->dev;
-	lp->pdata = dev_get_platdata(&cl->dev);
+
+	/* read device id (class) */
+	lp->chipid = i2c_smbus_read_byte_data(cl, ARCXCNN_ID_MSB);
+	if (lp->chipid > 2) {
+		lp->chipid = i2c_smbus_read_byte_data(cl, ARC3CNN_ID_MSB);
+		if (lp->chipid != 3) {
+			dev_err(lp->dev,
+				"Unknown device Id %02X\n", lp->chipid);
+			ret = -ENODEV;
+			goto probe_err;
+		}
+	}
+
+	if (lp->chipid == 0) {
+		/* treat id 0 as older class 1 chips */
+		lp->chipid = 1;
+	}
+
+	switch (lp->chipid) {
+	case 3:
+		/* class 3 device, 8 strings */
+		lp->max_brightness = ARC_MAX_BRIGHTNESS_3;
+		lp->rst_reg = ARC3CNN_COMP_CONFIG;
+		lp->fade_reg = ARC3CNN_FADECTRL;
+		lp->iled_config_reg = ARC3CNN_ILED_CONFIG;
+		lp->dim_mode_bits = ARC3CNN_ILED_DIM_INT;
+		lp->leden_reg = ARC3CNN_LEDEN;
+		lp->leden_mask = ARC3CNN_LEDEN_MASK;
+		lp->leden_bits = ARC3CNN_LEDEN_BITS;
+		lp->iset_lsb_reg = ARC3CNN_WLED_ISET_LSB;
+		lp->iset_msb_reg = ARC3CNN_WLED_ISET_MSB;
+		lp->iset_shift = ARC3CNN_WLED_ISET_LSB_SHIFT;
+		lp->comp_config_reg = ARC3CNN_COMP_CONFIG;
+		lp->filter_reg = ARC3CNN_FILT_CONFIG;
+		lp->maxtune_reg = ARC3CNN_IMAXTUNE;
+		break;
+	case 2:
+		/* class 2 device, 6 strings */
+		lp->max_brightness = ARC_MAX_BRIGHTNESS_2;
+		lp->rst_reg = ARCXCNN_CMD;
+		lp->fade_reg = ARCXCNN_FADECTRL;
+		lp->iled_config_reg = ARCXCNN_ILED_CONFIG;
+		lp->dim_mode_bits = ARCXCNN_ILED_DIM_INT;
+		lp->leden_reg = ARCXCNN_LEDEN;
+		lp->leden_mask = ARCXCNN_LEDEN_MASK;
+		lp->leden_bits = ARCXCNN_LEDEN_BITS;
+		lp->iset_lsb_reg = ARCXCNN_WLED_ISET_LSB;
+		lp->iset_msb_reg = ARCXCNN_WLED_ISET_MSB;
+		lp->iset_shift = ARCXCNN_WLED_ISET_LSB_SHIFT;
+		lp->comp_config_reg = ARC2CNN_COMP_CONFIG;
+		lp->filter_reg = ARC2CNN_FILT_CONFIG;
+		lp->maxtune_reg = ARC2CNN_IMAXTUNE;
+		break;
+	case 1:
+	default:
+		/* class 1 device, 6 strings */
+		lp->max_brightness = ARC_MAX_BRIGHTNESS_1;
+		lp->rst_reg = ARCXCNN_CMD;
+		lp->fade_reg = ARCXCNN_FADECTRL;
+		lp->iled_config_reg = ARCXCNN_ILED_CONFIG;
+		lp->dim_mode_bits = ARCXCNN_ILED_DIM_INT;
+		lp->leden_reg = ARCXCNN_LEDEN;
+		lp->leden_mask = ARCXCNN_LEDEN_MASK;
+		lp->leden_bits = ARCXCNN_LEDEN_BITS;
+		lp->iset_lsb_reg = ARCXCNN_WLED_ISET_LSB;
+		lp->iset_msb_reg = ARCXCNN_WLED_ISET_MSB;
+		lp->iset_shift = ARCXCNN_WLED_ISET_LSB_SHIFT;
+		break;
+	}
 
 	/* reset the device */
 	ret = i2c_smbus_write_byte_data(lp->client,
-		ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+		lp->rst_reg, ARCXCNN_CMD_RESET);
 	if (ret)
 		goto probe_err;
 
+	lp->pdata = dev_get_platdata(&cl->dev);
+
 	if (!lp->pdata) {
 		lp->pdata = devm_kzalloc(lp->dev,
 				sizeof(*lp->pdata), GFP_KERNEL);
@@ -282,29 +388,31 @@ static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
 
 		/* Setup defaults based on power-on defaults */
 		lp->pdata->name = NULL;
-		lp->pdata->initial_brightness = INIT_BRIGHT;
-		lp->pdata->leden = ARCXCNN_LEDEN_MASK;
+		lp->pdata->initial_brightness = ARC_INIT_BRIGHT;
+		lp->pdata->leden = lp->leden_mask;
 
 		lp->pdata->led_config_0 = i2c_smbus_read_byte_data(
-			lp->client, ARCXCNN_FADECTRL);
+			lp->client, lp->fade_reg);
 
 		lp->pdata->led_config_1 = i2c_smbus_read_byte_data(
-			lp->client, ARCXCNN_ILED_CONFIG);
+			lp->client, lp->iled_config_reg);
 		/* insure dim mode is not default pwm */
-		lp->pdata->led_config_1 |= ARCXCNN_ILED_DIM_INT;
-
-		lp->pdata->dim_freq = i2c_smbus_read_byte_data(
-			lp->client, ARCXCNN_DIMFREQ);
+		lp->pdata->led_config_1 |= lp->dim_mode_bits;
 
-		lp->pdata->comp_config = i2c_smbus_read_byte_data(
-			lp->client, ARCXCNN_COMP_CONFIG);
+		if (lp->chipid == 2)
+			lp->pdata->dim_freq = i2c_smbus_read_byte_data(
+				lp->client, ARC2CNN_DIMFREQ);
 
-		lp->pdata->filter_config = i2c_smbus_read_byte_data(
-			lp->client, ARCXCNN_FILT_CONFIG);
+		if (lp->chipid > 1) {
+			lp->pdata->comp_config = i2c_smbus_read_byte_data(
+				lp->client, lp->comp_config_reg);
 
-		lp->pdata->trim_config = i2c_smbus_read_byte_data(
-			lp->client, ARCXCNN_IMAXTUNE);
+			lp->pdata->filter_config = i2c_smbus_read_byte_data(
+				lp->client, lp->filter_reg);
 
+			lp->pdata->trim_config = i2c_smbus_read_byte_data(
+				lp->client, lp->maxtune_reg);
+		}
 		if (IS_ENABLED(CONFIG_OF))
 			arcxcnn_parse_dt(lp);
 	}
@@ -312,48 +420,55 @@ static int arcxcnn_probe(struct i2c_client *cl, const struct i2c_device_id *id)
 	i2c_set_clientdata(cl, lp);
 
 	/* constrain settings to what is possible */
-	if (lp->pdata->initial_brightness > MAX_BRIGHTNESS)
-		lp->pdata->initial_brightness = MAX_BRIGHTNESS;
+	if (lp->pdata->initial_brightness > lp->max_brightness)
+		lp->pdata->initial_brightness = lp->max_brightness;
 
 	/* set initial brightness */
 	ret = arcxcnn_set_brightness(lp, lp->pdata->initial_brightness);
 	if (ret)
 		goto probe_err;
 
-	/* set other register values directly */
-	ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_FADECTRL,
-		lp->pdata->led_config_0);
+	/* set other register values directly from platform data */
+	ret = i2c_smbus_write_byte_data(lp->client,
+		lp->fade_reg, lp->pdata->led_config_0);
 	if (ret)
 		goto probe_err;
 
-	ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_ILED_CONFIG,
-		lp->pdata->led_config_1);
+	ret = i2c_smbus_write_byte_data(lp->client,
+		lp->iled_config_reg, lp->pdata->led_config_1);
 	if (ret)
 		goto probe_err;
 
-	ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_DIMFREQ,
-		lp->pdata->dim_freq);
-	if (ret)
-		goto probe_err;
+	if (lp->chipid == 2) {
+		ret = i2c_smbus_write_byte_data(lp->client, ARC2CNN_DIMFREQ,
+			lp->pdata->dim_freq);
+		if (ret)
+			goto probe_err;
+	}
 
-	ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_COMP_CONFIG,
-		lp->pdata->comp_config);
-	if (ret)
-		goto probe_err;
+	if (lp->chipid > 1) {
+		ret = i2c_smbus_write_byte_data(lp->client,
+			lp->comp_config_reg, lp->pdata->comp_config);
+		if (ret)
+			goto probe_err;
 
-	ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_FILT_CONFIG,
-		lp->pdata->filter_config);
-	if (ret)
-		goto probe_err;
+		if (lp->chipid == 3)
+			lp->pdata->filter_config = ARC3CNN_FILT_DIMCODE;
 
-	ret = i2c_smbus_write_byte_data(lp->client, ARCXCNN_IMAXTUNE,
-		lp->pdata->trim_config);
-	if (ret)
-		goto probe_err;
+		ret = i2c_smbus_write_byte_data(lp->client,
+			lp->filter_reg, lp->pdata->filter_config);
+		if (ret)
+			goto probe_err;
+
+		ret = i2c_smbus_write_byte_data(lp->client,
+			lp->maxtune_reg, lp->pdata->trim_config);
+		if (ret)
+			goto probe_err;
+	}
 
 	/* set initial LED Enables */
-	arcxcnn_update_field(lp, ARCXCNN_LEDEN,
-		ARCXCNN_LEDEN_MASK, lp->pdata->leden);
+	arcxcnn_update_field(lp, lp->leden_reg,
+		lp->leden_mask, lp->pdata->leden);
 
 	ret = arcxcnn_backlight_register(lp);
 	if (ret)
@@ -379,10 +494,10 @@ static int arcxcnn_remove(struct i2c_client *cl)
 
 	/* disable all strings (ignore errors) */
 	i2c_smbus_write_byte_data(lp->client,
-		ARCXCNN_LEDEN, 0x00);
+		lp->leden_reg, 0x00);
 	/* reset the device (ignore errors) */
 	i2c_smbus_write_byte_data(lp->client,
-		ARCXCNN_CMD, ARCXCNN_CMD_RESET);
+		lp->rst_reg, ARCXCNN_CMD_RESET);
 
 	lp->bl->props.brightness = 0;
 
@@ -392,13 +507,17 @@ static int arcxcnn_remove(struct i2c_client *cl)
 }
 
 static const struct of_device_id arcxcnn_dt_ids[] = {
+	{ .compatible = "arctic,arc1c0608" },
 	{ .compatible = "arctic,arc2c0608" },
+	{ .compatible = "arctic,arc3c0845" },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, arcxcnn_dt_ids);
 
 static const struct i2c_device_id arcxcnn_ids[] = {
+	{"arc1c0608", ARC1C0608},
 	{"arc2c0608", ARC2C0608},
+	{"arc3c0845", ARC3C0845},
 	{ }
 };
 MODULE_DEVICE_TABLE(i2c, arcxcnn_ids);

--
2.7.4

_______________________________________________
dri-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/dri-devel