* [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
* 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
* [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
* 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 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
* [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
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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.