[PATCH 0/3] backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3

[PATCH 0/3] backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3

[Brian Dodge]

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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[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

Signed-off-by: Brian Dodge <bdodge09@gmail.com>
---
 .../bindings/leds/backlight/arcxcnn_bl.txt           | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
index 230abde..dcaa239 100644
--- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
@@ -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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[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

Signed-off-by: Brian Dodge <bdodge09@gmail.com>
---
 drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/video/backlight/arcxcnn_bl.c b/drivers/video/backlight/arcxcnn_bl.c
index dec790d..bebefc6 100644
--- a/drivers/video/backlight/arcxcnn_bl.c
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -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 <bdodge@arcticsand.com>
+ * Copyright 2018 pSemi, Inc.
+ * Author : Brian Dodge <bdodge@psemi.com>
  *
  * 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 <bdodge@arcticsand.com>");
+MODULE_AUTHOR("Brian Dodge <bdodge@psemi.com>");
 MODULE_DESCRIPTION("ARCXCNN Backlight driver");
--
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[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

Signed-off-by: Brian Dodge <bdodge09@gmail.com>
---
 drivers/video/backlight/arcxcnn_bl.c | 261 +++++++++++++++++++++++++----------
 1 file changed, 190 insertions(+), 71 deletions(-)

diff --git a/drivers/video/backlight/arcxcnn_bl.c b/drivers/video/backlight/arcxcnn_bl.c
index bebefc6..30c07cb 100644
--- a/drivers/video/backlight/arcxcnn_bl.c
+++ b/drivers/video/backlight/arcxcnn_bl.c
@@ -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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 1217 bytes --]

Hi!

> 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
> 
> Signed-off-by: Brian Dodge <bdodge09@gmail.com>
> ---
>  drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
>   *
> - * Copyright 2016 ArcticSand, Inc.
> - * Author : Brian Dodge <bdodge@arcticsand.com>
> + * Copyright 2018 pSemi, Inc.
> + * Author : Brian Dodge <bdodge@psemi.com>

Ummm. Copyright 2016-2018?

> @@ -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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Rob Herring]

On Wed, Nov 07, 2018 at 07:10:38AM -0500, Brian Dodge wrote:
> 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?

> Signed-off-by: Brian Dodge <bdodge09@gmail.com>
> ---
>  .../bindings/leds/backlight/arcxcnn_bl.txt           | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> index 230abde..dcaa239 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/arcxcnn_bl.txt
> @@ -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.

> +- 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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[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.

On 11/11/18 6:30 AM, Pavel Machek wrote:
> Hi!
>
>> 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
>>
>> Signed-off-by: Brian Dodge <bdodge09@gmail.com>
>> ---
>>   drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
>>   1 file changed, 11 insertions(+), 11 deletions(-)
>>
>>    *
>> - * Copyright 2016 ArcticSand, Inc.
>> - * Author : Brian Dodge <bdodge@arcticsand.com>
>> + * Copyright 2018 pSemi, Inc.
>> + * Author : Brian Dodge <bdodge@psemi.com>
> Ummm. Copyright 2016-2018?
>
>> @@ -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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Thompson]

[-- Attachment #1.1: Type: text/plain, Size: 2123 bytes --]

Hi Brian

On Tue, 27 Nov 2018 at 00:44, Brian Dodge <bdodge09@gmail.com> wrote:

> 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.




> On 11/11/18 6:30 AM, Pavel Machek wrote:
> > Hi!
> >
> >> 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
> >>
> >> Signed-off-by: Brian Dodge <bdodge09@gmail.com>
> >> ---
> >>   drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
> >>   1 file changed, 11 insertions(+), 11 deletions(-)
> >>
> >>    *
> >> - * Copyright 2016 ArcticSand, Inc.
> >> - * Author : Brian Dodge <bdodge@arcticsand.com>
> >> + * Copyright 2018 pSemi, Inc.
> >> + * Author : Brian Dodge <bdodge@psemi.com>
> > Ummm. Copyright 2016-2018?
> >
> >> @@ -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
>

[-- Attachment #1.2: Type: text/html, Size: 3331 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[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]

On 27/11/2018 00:44, Brian Dodge wrote:
> 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.


> 
> On 11/11/18 6:30 AM, Pavel Machek wrote:
>> Hi!
>>
>>> 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
>>>
>>> Signed-off-by: Brian Dodge <bdodge09@gmail.com>
>>> ---
>>>   drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
>>>   1 file changed, 11 insertions(+), 11 deletions(-)
>>>
>>>    *
>>> - * Copyright 2016 ArcticSand, Inc.
>>> - * Author : Brian Dodge <bdodge@arcticsand.com>
>>> + * Copyright 2018 pSemi, Inc.
>>> + * Author : Brian Dodge <bdodge@psemi.com>
>> Ummm. Copyright 2016-2018?
>>
>>> @@ -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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Thompson]

On 21/06/2019 14:46, Daniel Thompson wrote:
> [Sorry to those receiving this twice... had to dig this out from the 
> archives and sent it to the lists from the wrong mailer]
> 
> On 27/11/2018 00:44, Brian Dodge wrote:
>> 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.


> 
> 
> Daniel.
> 
> 
>>
>> On 11/11/18 6:30 AM, Pavel Machek wrote:
>>> Hi!
>>>
>>>> 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
>>>>
>>>> Signed-off-by: Brian Dodge <bdodge09@gmail.com>
>>>> ---
>>>>   drivers/video/backlight/arcxcnn_bl.c | 22 +++++++++++-----------
>>>>   1 file changed, 11 insertions(+), 11 deletions(-)
>>>>
>>>>    *
>>>> - * Copyright 2016 ArcticSand, Inc.
>>>> - * Author : Brian Dodge <bdodge@arcticsand.com>
>>>> + * Copyright 2018 pSemi, Inc.
>>>> + * Author : Brian Dodge <bdodge@psemi.com>
>>> Ummm. Copyright 2016-2018?
>>>
>>>> @@ -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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 1317 bytes --]

Hi!

> [Sorry to those receiving this twice... had to dig this out from the
> archives and sent it to the lists from the wrong mailer]
> 
> On 27/11/2018 00:44, Brian Dodge wrote:
> >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.

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

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

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

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Thompson]

On Sat, Jun 22, 2019 at 12:13:25AM +0200, Pavel Machek wrote:
> Hi!
> 
> > [Sorry to those receiving this twice... had to dig this out from the
> > archives and sent it to the lists from the wrong mailer]
> > 
> > On 27/11/2018 00:44, Brian Dodge wrote:
> > >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.
> 
> 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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[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.

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

On 6/24/19 6:24 AM, Daniel Thompson wrote:
> On Sat, Jun 22, 2019 at 12:13:25AM +0200, Pavel Machek wrote:
>> Hi!
>>
>>> [Sorry to those receiving this twice... had to dig this out from the
>>> archives and sent it to the lists from the wrong mailer]
>>>
>>> On 27/11/2018 00:44, Brian Dodge wrote:
>>>> 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.
>> 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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Daniel Thompson]

On Mon, Jun 24, 2019 at 07:29:20AM -0400, Brian Dodge wrote:
> 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?

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.

> 
> Brian
> 
> On 6/24/19 6:24 AM, Daniel Thompson wrote:
> > On Sat, Jun 22, 2019 at 12:13:25AM +0200, Pavel Machek wrote:
> > > Hi!
> > > 
> > > > [Sorry to those receiving this twice... had to dig this out from the
> > > > archives and sent it to the lists from the wrong mailer]
> > > > 
> > > > On 27/11/2018 00:44, Brian Dodge wrote:
> > > > > 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.
> > > 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
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel