* [PATCH 0/3] backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3
@ 2018-11-07 12:10 Brian Dodge
2018-11-07 12:10 ` [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings Brian Dodge
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Brian Dodge @ 2018-11-07 12:10 UTC (permalink / raw)
To: lee.jones, daniel.thompson, jingoohan1, jacek.anaszewski, pavel,
robh+dt, mark.rutland, dri-devel, linux-leds, devicetree
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings
2018-11-07 12:10 [PATCH 0/3] backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3 Brian Dodge
@ 2018-11-07 12:10 ` Brian Dodge
2018-11-12 18:42 ` Rob Herring
2018-11-07 12:10 ` [PATCH 2/3] backlight/arcxcnn fix vendor prefix Brian Dodge
2018-11-07 12:10 ` [PATCH 3/3] backlight/arcxcnn add support for arc1 an arc3 chip families Brian Dodge
2 siblings, 1 reply; 14+ messages in thread
From: Brian Dodge @ 2018-11-07 12:10 UTC (permalink / raw)
To: lee.jones, daniel.thompson, jingoohan1, jacek.anaszewski, pavel,
robh+dt, mark.rutland, dri-devel, linux-leds, devicetree
Cc: 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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2018-11-07 12:10 [PATCH 0/3] backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3 Brian Dodge
2018-11-07 12:10 ` [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings Brian Dodge
@ 2018-11-07 12:10 ` Brian Dodge
2018-11-11 11:30 ` Pavel Machek
2018-11-07 12:10 ` [PATCH 3/3] backlight/arcxcnn add support for arc1 an arc3 chip families Brian Dodge
2 siblings, 1 reply; 14+ messages in thread
From: Brian Dodge @ 2018-11-07 12:10 UTC (permalink / raw)
To: lee.jones, daniel.thompson, jingoohan1, jacek.anaszewski, pavel,
robh+dt, mark.rutland, dri-devel, linux-leds, devicetree
Cc: 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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH 3/3] backlight/arcxcnn add support for arc1 an arc3 chip families
2018-11-07 12:10 [PATCH 0/3] backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3 Brian Dodge
2018-11-07 12:10 ` [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings Brian Dodge
2018-11-07 12:10 ` [PATCH 2/3] backlight/arcxcnn fix vendor prefix Brian Dodge
@ 2018-11-07 12:10 ` Brian Dodge
2 siblings, 0 replies; 14+ messages in thread
From: Brian Dodge @ 2018-11-07 12:10 UTC (permalink / raw)
To: lee.jones, daniel.thompson, jingoohan1, jacek.anaszewski, pavel,
robh+dt, mark.rutland, dri-devel, linux-leds, devicetree
Cc: 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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2018-11-07 12:10 ` [PATCH 2/3] backlight/arcxcnn fix vendor prefix Brian Dodge
@ 2018-11-11 11:30 ` Pavel Machek
2018-11-27 0:44 ` Brian Dodge
0 siblings, 1 reply; 14+ messages in thread
From: Pavel Machek @ 2018-11-11 11:30 UTC (permalink / raw)
To: Brian Dodge
Cc: mark.rutland, devicetree, daniel.thompson, jingoohan1, dri-devel,
robh+dt, jacek.anaszewski, lee.jones, linux-leds
[-- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings
2018-11-07 12:10 ` [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings Brian Dodge
@ 2018-11-12 18:42 ` Rob Herring
0 siblings, 0 replies; 14+ messages in thread
From: Rob Herring @ 2018-11-12 18:42 UTC (permalink / raw)
To: Brian Dodge
Cc: mark.rutland, devicetree, daniel.thompson, jingoohan1, dri-devel,
jacek.anaszewski, pavel, lee.jones, linux-leds
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2018-11-11 11:30 ` Pavel Machek
@ 2018-11-27 0:44 ` Brian Dodge
2019-06-21 13:39 ` Daniel Thompson
2019-06-21 13:46 ` Daniel Thompson
0 siblings, 2 replies; 14+ messages in thread
From: Brian Dodge @ 2018-11-27 0:44 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland, devicetree, daniel.thompson, jingoohan1, dri-devel,
robh+dt, jacek.anaszewski, Peter Bacon, lee.jones, linux-leds
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2018-11-27 0:44 ` Brian Dodge
@ 2019-06-21 13:39 ` Daniel Thompson
2019-06-21 13:46 ` Daniel Thompson
1 sibling, 0 replies; 14+ messages in thread
From: Daniel Thompson @ 2019-06-21 13:39 UTC (permalink / raw)
To: Brian Dodge
Cc: Mark Rutland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Jingoo Han, DRI Development, Rob Herring, Jacek Anaszewski,
Pavel Machek, Peter Bacon, Lee Jones, Linux LED Subsystem
[-- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2018-11-27 0:44 ` Brian Dodge
2019-06-21 13:39 ` Daniel Thompson
@ 2019-06-21 13:46 ` Daniel Thompson
2019-06-21 13:48 ` Daniel Thompson
2019-06-21 22:13 ` Pavel Machek
1 sibling, 2 replies; 14+ messages in thread
From: Daniel Thompson @ 2019-06-21 13:46 UTC (permalink / raw)
To: Brian Dodge, Pavel Machek
Cc: mark.rutland, devicetree, jingoohan1, dri-devel, robh+dt,
jacek.anaszewski, Peter Bacon, lee.jones, linux-leds
[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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2019-06-21 13:46 ` Daniel Thompson
@ 2019-06-21 13:48 ` Daniel Thompson
2019-06-21 22:13 ` Pavel Machek
1 sibling, 0 replies; 14+ messages in thread
From: Daniel Thompson @ 2019-06-21 13:48 UTC (permalink / raw)
To: Brian Dodge, Pavel Machek
Cc: mark.rutland, devicetree, jingoohan1, dri-devel, robh+dt,
jacek.anaszewski, Peter Bacon, lee.jones, linux-leds
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2019-06-21 13:46 ` Daniel Thompson
2019-06-21 13:48 ` Daniel Thompson
@ 2019-06-21 22:13 ` Pavel Machek
2019-06-24 10:24 ` Daniel Thompson
1 sibling, 1 reply; 14+ messages in thread
From: Pavel Machek @ 2019-06-21 22:13 UTC (permalink / raw)
To: Daniel Thompson
Cc: mark.rutland, devicetree, Brian Dodge, jingoohan1, dri-devel,
robh+dt, jacek.anaszewski, Peter Bacon, lee.jones, linux-leds
[-- 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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2019-06-21 22:13 ` Pavel Machek
@ 2019-06-24 10:24 ` Daniel Thompson
2019-06-24 11:29 ` Brian Dodge
0 siblings, 1 reply; 14+ messages in thread
From: Daniel Thompson @ 2019-06-24 10:24 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland, devicetree, Brian Dodge, jingoohan1, dri-devel,
robh+dt, jacek.anaszewski, Peter Bacon, lee.jones, linux-leds
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2019-06-24 10:24 ` Daniel Thompson
@ 2019-06-24 11:29 ` Brian Dodge
2019-06-24 13:59 ` Daniel Thompson
0 siblings, 1 reply; 14+ messages in thread
From: Brian Dodge @ 2019-06-24 11:29 UTC (permalink / raw)
To: Daniel Thompson, Pavel Machek
Cc: mark.rutland, devicetree, jingoohan1, dri-devel, robh+dt,
jacek.anaszewski, Peter Bacon, lee.jones, linux-leds
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
2019-06-24 11:29 ` Brian Dodge
@ 2019-06-24 13:59 ` Daniel Thompson
0 siblings, 0 replies; 14+ messages in thread
From: Daniel Thompson @ 2019-06-24 13:59 UTC (permalink / raw)
To: Brian Dodge
Cc: mark.rutland, devicetree, jingoohan1, dri-devel, robh+dt,
jacek.anaszewski, Pavel Machek, Peter Bacon, lee.jones,
linux-leds
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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2019-06-24 13:59 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-07 12:10 [PATCH 0/3] backlight/arcxcnn fix vendor prefix in driver and bindings and add support for arc1, arc3 Brian Dodge
2018-11-07 12:10 ` [PATCH 1/3] dt-bindings: backlight: fix vendor prefix for ArcticSand arcxcnn driver bindings Brian Dodge
2018-11-12 18:42 ` Rob Herring
2018-11-07 12:10 ` [PATCH 2/3] backlight/arcxcnn fix vendor prefix Brian Dodge
2018-11-11 11:30 ` Pavel Machek
2018-11-27 0:44 ` Brian Dodge
2019-06-21 13:39 ` Daniel Thompson
2019-06-21 13:46 ` Daniel Thompson
2019-06-21 13:48 ` Daniel Thompson
2019-06-21 22:13 ` Pavel Machek
2019-06-24 10:24 ` Daniel Thompson
2019-06-24 11:29 ` Brian Dodge
2019-06-24 13:59 ` Daniel Thompson
2018-11-07 12:10 ` [PATCH 3/3] backlight/arcxcnn add support for arc1 an arc3 chip families Brian Dodge
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).