From: Dan Murphy <dmurphy@ti.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: <linux-omap@vger.kernel.org>, <tony@atomide.com>,
<sre@kernel.org>, <nekit1000@gmail.com>, <mpartap@gmx.net>,
<merlijn@wizzup.org>, <jacek.anaszewski@gmail.com>,
<linux-kernel@vger.kernel.org>, <linux-leds@vger.kernel.org>
Subject: Re: Backlight in motorola Droid 4
Date: Wed, 24 Jul 2019 10:10:12 -0500 [thread overview]
Message-ID: <fdcab21e-dd5e-1f7e-6927-16597a94c1a2@ti.com> (raw)
In-Reply-To: <20190724124530.GA30211@amd>
Pavel
On 7/24/19 7:45 AM, Pavel Machek wrote:
> Hi!
>
>>> So now the backlight LED can be controlled. Good. (And thanks!)
>>>
>>> But I seem to remember that backlight had range from "is it really on?"
>>> to "very bright"; now it seems to have range from "bright" to "very
>>> bright".
>>>
>>> Any ideas what goes on there?
>> In the LM3552 driver we are changing the Full scale brightness registers for
>> the
>>
>> specific control bank.
>>
>> #define LM3532_REG_CTRL_A_BRT 0x17
>> #define LM3532_REG_CTRL_B_BRT 0x19
>> #define LM3532_REG_CTRL_C_BRT 0x1b
>>
>> In the ti-lmu code the ALS zones were being modified not the control bank
>> brightness.
>>
>> #define LM3532_REG_BRT_A 0x70 /* zone 0 */
>> #define LM3532_REG_BRT_B 0x76 /* zone 1 */
>> #define LM3532_REG_BRT_C 0x7C /* zone 2 */
>>
>> Not sure how the ALS is attached in the system if it reports to the host and
>> the host manages
>>
>> the back light or if the the ALS is connected directly to the LM3532.
>>
>> Maybe the ALS zone targets need to be updated to allow a fuller range. The
>> LM3532 may be stuck
>>
>> in a certain zone.
>>
>> Probably should set up the ALS properties in the device tree.
> I came with this so far.
OK I guess you will remove the commentary in the driver once you submit
the patch
> Pavel
>
> diff --git a/arch/arm/boot/dts/omap4-droid4-xt894.dts b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> index 62af1b8..752952e 100644
> --- a/arch/arm/boot/dts/omap4-droid4-xt894.dts
> +++ b/arch/arm/boot/dts/omap4-droid4-xt894.dts
> @@ -422,6 +422,7 @@
> led-sources = <2>;
> ti,led-mode = <0>;
> label = ":backlight";
> + default-state = "on";
> linux,default-trigger = "backlight";
> };
>
> diff --git a/drivers/base/regmap/regmap-debugfs.c b/drivers/base/regmap/regmap-debugfs.c
> index e5e1b3a..2baeacd 100644
> --- a/drivers/base/regmap/regmap-debugfs.c
> +++ b/drivers/base/regmap/regmap-debugfs.c
> @@ -288,7 +288,7 @@ static ssize_t regmap_map_read_file(struct file *file, char __user *user_buf,
> count, ppos);
> }
>
> -#undef REGMAP_ALLOW_WRITE_DEBUGFS
> +#define REGMAP_ALLOW_WRITE_DEBUGFS
> #ifdef REGMAP_ALLOW_WRITE_DEBUGFS
> /*
> * This can be dangerous especially when we have clients such as
> diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
> index bdc98dd..db6e382 100644
> --- a/drivers/leds/leds-gpio.c
> +++ b/drivers/leds/leds-gpio.c
> @@ -172,6 +172,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev)
> led.default_state = LEDS_GPIO_DEFSTATE_ON;
> else
> led.default_state = LEDS_GPIO_DEFSTATE_OFF;
> + /* FIXME: else ... warn about bad device tree */
> }
>
> if (fwnode_property_present(child, "retain-state-suspended"))
> diff --git a/drivers/leds/leds-lm3532.c b/drivers/leds/leds-lm3532.c
> index 180895b..365a22a5 100644
> --- a/drivers/leds/leds-lm3532.c
> +++ b/drivers/leds/leds-lm3532.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0
> // TI LM3532 LED driver
> // Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> +// http://www.ti.com/lit/ds/symlink/lm3532.pdf
I don't put symlinks in drivers as they are subject to change.
This link is in the patch history anyway
>
> #include <linux/i2c.h>
> #include <linux/leds.h>
> @@ -23,7 +24,7 @@
> #define LM3532_REG_PWM_B_CFG 0x14
> #define LM3532_REG_PWM_C_CFG 0x15
> #define LM3532_REG_ZONE_CFG_A 0x16
> -#define LM3532_REG_CTRL_A_BRT 0x17
> +#define LM3532_REG_CTRL_A_BRT 0x17 /* Called "Control A Full-Scale Current " in documentation */
> #define LM3532_REG_ZONE_CFG_B 0x18
> #define LM3532_REG_CTRL_B_BRT 0x19
> #define LM3532_REG_ZONE_CFG_C 0x1a
> @@ -38,6 +39,7 @@
> #define LM3532_REG_ZN_2_LO 0x65
> #define LM3532_REG_ZN_3_HI 0x66
> #define LM3532_REG_ZN_3_LO 0x67
> +#define LM3532_REG_ZN_TARGET 0x70
> #define LM3532_REG_MAX 0x7e
>
> /* Contorl Enable */
> @@ -302,7 +304,7 @@ static int lm3532_led_disable(struct lm3532_led *led_data)
> int ret;
>
> ret = regmap_update_bits(led_data->priv->regmap, LM3532_REG_ENABLE,
> - ctrl_en_val, ~ctrl_en_val);
> + ctrl_en_val, 0);
> if (ret) {
> dev_err(led_data->priv->dev, "Failed to set ctrl:%d\n", ret);
> return ret;
> @@ -321,6 +323,7 @@ static int lm3532_brightness_set(struct led_classdev *led_cdev,
>
> mutex_lock(&led->priv->lock);
>
> + /* Actually, I don't think this is acceptable */
> if (led->mode == LM3532_BL_MODE_ALS) {
> if (brt_val > LED_OFF)
> ret = lm3532_led_enable(led);
> @@ -339,11 +342,23 @@ static int lm3532_brightness_set(struct led_classdev *led_cdev,
> if (ret)
> goto unlock;
>
> + /* This driver is sick. It manipulates maximum current register (5-bit),
> + but fails to control 8-bit brightness register... which is exponential
> + so it allows >8 bit of control */
> +
> brightness_reg = LM3532_REG_CTRL_A_BRT + led->control_bank * 2;
The appropriate target register can be programmed in the control bank
config register bits[4:2]
Default is 0x1xx which is 0x74.
The target register should be set in the config as well and then stored
as a register offset.
Or just set the CTRL_A_BRT to 0x74 and take the default config
> - brt_val = brt_val / LM3532_BRT_VAL_ADJUST;
> + brt_val = 255 / LM3532_BRT_VAL_ADJUST;
>
Don't need this if we have 8 bit control. This was only needed for the
max current control.
> ret = regmap_write(led->priv->regmap, brightness_reg, brt_val);
>
> + brightness_reg = 0x70 + led->control_bank * 5;
> +
> + ret = regmap_write(led->priv->regmap, brightness_reg, brt_val);
> + ret = regmap_write(led->priv->regmap, brightness_reg+1, brt_val);
> + ret = regmap_write(led->priv->regmap, brightness_reg+2, brt_val);
> + ret = regmap_write(led->priv->regmap, brightness_reg+3, brt_val);
> + ret = regmap_write(led->priv->regmap, brightness_reg+4, brt_val);
> +
You don't need to write all the target registers.
Dan
<snip>
next prev parent reply other threads:[~2019-07-24 15:10 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-19 16:26 [PATCH 0/2] LP5024/18 LED introduction Dan Murphy
2018-12-19 16:26 ` [PATCH 1/2] dt: bindings: lp5024: Introduce the lp5024 and lp5018 RGB driver Dan Murphy
2018-12-28 23:53 ` Rob Herring
2018-12-31 18:54 ` Dan Murphy
2019-01-08 20:33 ` Jacek Anaszewski
2019-01-08 20:53 ` Dan Murphy
2019-01-08 21:16 ` Jacek Anaszewski
2019-01-08 21:22 ` Dan Murphy
2019-01-09 20:12 ` Jacek Anaszewski
2019-01-09 21:12 ` Dan Murphy
2019-01-09 21:28 ` Jacek Anaszewski
2019-01-09 21:31 ` Dan Murphy
2019-01-10 18:44 ` Jacek Anaszewski
2019-01-10 19:22 ` Dan Murphy
2019-01-10 19:57 ` Jacek Anaszewski
2019-01-10 20:43 ` Dan Murphy
2019-01-10 22:03 ` Jacek Anaszewski
2019-01-10 23:51 ` Dan Murphy
2019-01-11 12:38 ` Dan Murphy
2019-01-11 21:52 ` Jacek Anaszewski
2019-01-12 17:09 ` Dan Murphy
2019-01-12 19:48 ` Jacek Anaszewski
2019-01-14 12:27 ` Dan Murphy
2019-01-14 20:11 ` Jacek Anaszewski
2019-01-14 20:14 ` Dan Murphy
2019-01-14 20:28 ` Jacek Anaszewski
2019-01-14 20:29 ` Dan Murphy
2018-12-19 16:26 ` [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver Dan Murphy
2018-12-19 19:04 ` Dan Murphy
2018-12-19 19:34 ` Pavel Machek
2018-12-19 19:41 ` Dan Murphy
2018-12-19 20:10 ` Pavel Machek
2018-12-19 20:41 ` Dan Murphy
2018-12-19 21:36 ` Jacek Anaszewski
2018-12-19 21:50 ` Dan Murphy
2018-12-20 12:40 ` Vesa Jääskeläinen
2018-12-20 13:56 ` Dan Murphy
2019-01-01 13:45 ` Vesa Jääskeläinen
2019-01-03 22:05 ` Jacek Anaszewski
2019-01-03 23:19 ` Vesa Jääskeläinen
2019-01-03 23:34 ` Pavel Machek
2019-01-04 19:49 ` Vesa Jääskeläinen
2019-01-04 20:43 ` Pavel Machek
2019-01-04 19:12 ` Jacek Anaszewski
2019-01-04 20:12 ` Pavel Machek
2019-01-04 21:37 ` Jacek Anaszewski
2019-01-04 22:07 ` Pavel Machek
2019-01-05 12:16 ` Jacek Anaszewski
2019-01-05 12:31 ` Pavel Machek
2019-01-05 13:16 ` Jacek Anaszewski
2019-01-05 22:12 ` Generic RGB LED support was " Pavel Machek
2019-01-06 15:52 ` Jacek Anaszewski
2019-01-07 19:13 ` Jacek Anaszewski
2019-01-07 19:36 ` Dan Murphy
2019-01-07 20:59 ` Jacek Anaszewski
2019-01-07 21:14 ` Dan Murphy
2019-01-08 21:18 ` Jacek Anaszewski
2019-01-08 21:25 ` Dan Murphy
2019-01-10 12:46 ` Dan Murphy
2019-01-10 19:23 ` Jacek Anaszewski
2019-01-10 19:58 ` Dan Murphy
2019-01-10 21:02 ` Jacek Anaszewski
2019-01-10 21:07 ` Dan Murphy
2019-01-08 22:59 ` Pavel Machek
2019-01-09 7:11 ` Vesa Jääskeläinen
2019-01-13 16:37 ` Jacek Anaszewski
2019-01-05 0:39 ` Vesa Jääskeläinen
2019-01-07 19:34 ` Dan Murphy
2019-01-09 6:20 ` Vesa Jääskeläinen
2019-01-07 21:13 ` Jacek Anaszewski
2019-01-07 21:15 ` Dan Murphy
2019-01-09 6:46 ` Vesa Jääskeläinen
2019-01-13 16:36 ` Jacek Anaszewski
2018-12-20 20:31 ` Jacek Anaszewski
2018-12-21 7:32 ` Jacek Anaszewski
2018-12-21 13:05 ` Dan Murphy
2018-12-29 18:28 ` Jacek Anaszewski
2018-12-29 19:07 ` Pavel Machek
2018-12-30 17:09 ` Jacek Anaszewski
2018-12-30 17:35 ` Pavel Machek
2018-12-31 15:43 ` Jacek Anaszewski
2018-12-31 15:47 ` Jacek Anaszewski
2018-12-31 19:15 ` Dan Murphy
2019-01-01 14:42 ` Jacek Anaszewski
2019-01-01 18:11 ` Dan Murphy
2019-01-01 22:06 ` Jacek Anaszewski
2018-12-31 16:28 ` Pavel Machek
2019-01-01 14:26 ` Jacek Anaszewski
2018-12-19 22:03 ` Pavel Machek
2018-12-19 22:08 ` Dan Murphy
2018-12-19 22:27 ` Pavel Machek
2018-12-20 1:31 ` Dan Murphy
2018-12-20 9:06 ` Pavel Machek
2018-12-20 14:03 ` Dan Murphy
2019-01-08 21:10 ` Jacek Anaszewski
2019-01-08 21:17 ` Dan Murphy
2019-07-22 20:59 ` Backlight in motorola Droid 4 Pavel Machek
2019-07-23 15:53 ` Dan Murphy
2019-07-24 8:22 ` Pavel Machek
2019-07-24 12:45 ` Pavel Machek
2019-07-24 15:10 ` Dan Murphy [this message]
2019-07-24 15:22 ` Dan Murphy
2019-07-26 14:38 ` Dan Murphy
2019-07-29 22:00 ` Pavel Machek
2019-07-30 18:21 ` Dan Murphy
2019-07-30 21:52 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fdcab21e-dd5e-1f7e-6927-16597a94c1a2@ti.com \
--to=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=mpartap@gmx.net \
--cc=nekit1000@gmail.com \
--cc=pavel@ucw.cz \
--cc=sre@kernel.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).