From: Tony Lindgren <tony@atomide.com>
To: Dan Murphy <dmurphy@ti.com>
Cc: Pavel Machek <pavel@ucw.cz>,
jacek.anaszewski@gmail.com, sre@kernel.org, nekit1000@gmail.com,
mpartap@gmx.net, merlijn@wizzup.org, linux-leds@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode
Date: Tue, 27 Aug 2019 09:45:38 -0700 [thread overview]
Message-ID: <20190827164538.GB52127@atomide.com> (raw)
In-Reply-To: <56200c16-dcfe-3b14-6f22-80e5a387a66b@ti.com>
* Dan Murphy <dmurphy@ti.com> [190827 16:20]:
> Tony
>
> On 8/27/19 11:04 AM, Tony Lindgren wrote:
> > * Dan Murphy <dmurphy@ti.com> [190827 13:02]:
> > > Hello
> > >
> > > On 8/27/19 7:44 AM, Dan Murphy wrote:
> > > > Tony
> > > >
> > > > On 8/27/19 7:18 AM, Pavel Machek wrote:
> > > > > On Mon 2019-08-26 15:44:37, Tony Lindgren wrote:
> > > > > > * Pavel Machek <pavel@ucw.cz> [190826 22:14]:
> > > > > > > On Mon 2019-08-26 14:58:22, Tony Lindgren wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > * Dan Murphy <dmurphy@ti.com> [190820 19:53]:
> > > > > > > > > Fix the brightness control for I2C mode. Instead of
> > > > > > > > > changing the full scale current register update the ALS target
> > > > > > > > > register for the appropriate banks.
> > > > > > > > >
> > > > > > > > > In addition clean up some code errors and random misspellings found
> > > > > > > > > during coding.
> > > > > > > > >
> > > > > > > > > Tested on Droid4 as well as LM3532 EVM connected to
> > > > > > > > > a BeagleBoneBlack
> > > > > > > > >
> > > > > > > > > Fixes: e37a7f8d77e1 ("leds: lm3532: Introduce the
> > > > > > > > > lm3532 LED driver")
> > > > > > > > > Reported-by: Pavel Machek <pavel@ucw.cz>
> > > > > > > > > Signed-off-by: Dan Murphy <dmurphy@ti.com>
> > > > > > > > > ---
> > > > > > > > >
> > > > > > > > > v3 - Removed register define updates -
> > > > > > > > > https://lore.kernel.org/patchwork/patch/1114542/
> > > > > > > > Looks like starting with this patch in Linux next the LCD on droid4
> > > > > > > > is so dim it's unreadable even with brightness set to 255. Setting
> > > > > > > > brightness to 0 does blank it completely though.
> > > > > > > >
> > > > > > > > Did something maybe break with the various patch revisions or are
> > > > > > > > we now missing some dts patch?
> > > > > > > Maybe missing dts patch. We should provide maximum current the LED can
> > > > > > > handle...
> > > > > > Or i2c control is somehow broken and only als control now works?
> > > > With only setting CONFIG_LEDS_LM3532=m to the next branch I get full
> > > > brightness with 255.
> > > >
> > > > I also see half brightness at 128 with the ramp down working.
> > > >
> > > > I am not able to reproduce this issue on my device.
> > > >
> > > Just to make sure my data was right I did a clean rebuild on commit
> > > 1dbb9fb4082ce2a2f1cf9596881ddece062d15d0
> > >
> > > from the led-next branch.
> > >
> > > Just adding the above config flag. I still cannot reproduce the issue
> > >
> > > See attached pic
> > OK thanks for checking. Probably you can reproduce the issue if you
> > reset things to commit c4b8354e5341 ("leds: lm3532: Fix brightness
> > control for i2c mode"). There might now be something uninitialized
> > with that commit depending on the hardware state on boot if you
> > care to check that. Or maybe there's some interaction with other
> > patches not yet at commit c4b8354e5341 level.
>
> Ok the fix for that issue is in this patch
>
> leds: lm3532: Fixes for the driver for stability
>
> The fix for setting the brightness control register during the init forced
> the ALS mode to
>
> be enabled. The Fixes for driver stability patch then set the led->mode to
> the correct register setting.
OK yeah so that part starts to make sense now. I wonder if the reason
for my issues was caused by change in sysfs brightness level values
and I ended up chasing an already fixed issue. I think I was using
value of 30 recently, which is now very dim :)
> > I confirmed again that things fail at commit c4b8354e5341. But
> > now testing with the same Linux next as yesterday things works again.
> > Not sure what's going on as failures with Linux next yestreday
> > made me start narrowing down what commit causes the issues.
> >
> > Anyways, playing with loading and unloading the leds-lm3532.ko I
> > noticed we can also have unpaired regulator calls when using sysfs
> > brightness that the below patch attempts to fix. Not sure how I got
> > to the point of regulator warnings, but I was trying to enable
> > the brightness via sysfs. Maybe I had other patches too when
> > I got the regulator warnings.. But please check if the below
> > patch makes sense.
>
> Makes sense did you want me to push a patch?
No need to, I can send out a proper patch later today after typing up
the patch description if no other comments.
Regards,
Tony
next prev parent reply other threads:[~2019-08-27 16:45 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 19:53 [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode Dan Murphy
2019-08-20 19:53 ` [PATCH v3 2/5] leds: lm3532: Change the define for the fs current register Dan Murphy
2019-08-25 9:32 ` Pavel Machek
2019-08-27 21:33 ` Jacek Anaszewski
2019-08-27 21:37 ` Jacek Anaszewski
2019-08-20 19:53 ` [PATCH v3 3/5] leds: lm3532: Fixes for the driver for stability Dan Murphy
2019-08-20 19:53 ` [PATCH v3 4/5] dt: lm3532: Add property for full scale current Dan Murphy
2019-08-20 19:53 ` [PATCH v3 5/5] leds: lm3532: Add full scale current configuration Dan Murphy
2019-08-25 10:50 ` [PATCH v3 1/5] leds: lm3532: Fix brightness control for i2c mode Jacek Anaszewski
2019-08-26 21:58 ` Tony Lindgren
2019-08-26 22:14 ` Pavel Machek
2019-08-26 22:44 ` Tony Lindgren
2019-08-27 12:03 ` Dan Murphy
2019-08-27 12:18 ` Pavel Machek
2019-08-27 12:44 ` Dan Murphy
[not found] ` <9939e253-0c9e-5ef7-e160-c1e5fe99c453@ti.com>
2019-08-27 16:04 ` Tony Lindgren
2019-08-27 16:19 ` Dan Murphy
2019-08-27 16:45 ` Tony Lindgren [this message]
2019-08-27 21:14 ` Jacek Anaszewski
2019-08-28 15:28 ` Dan Murphy
2019-08-28 20:37 ` Jacek Anaszewski
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=20190827164538.GB52127@atomide.com \
--to=tony@atomide.com \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=merlijn@wizzup.org \
--cc=mpartap@gmx.net \
--cc=nekit1000@gmail.com \
--cc=pavel@ucw.cz \
--cc=sre@kernel.org \
/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).