From: Andreas Dannenberg <dannenberg@ti.com>
To: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Sebastian Reichel <sre@kernel.org>,
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Laurentiu Palcu <laurentiu.palcu@intel.com>,
Ramakrishna Pallala <ramakrishna.pallala@intel.com>,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v4 04/10] power: bq24257: Allow manual setting of input current limit
Date: Wed, 16 Sep 2015 14:23:15 -0500 [thread overview]
Message-ID: <20150916192257.GB27772@beast> (raw)
In-Reply-To: <55F8BACD.6090402@samsung.com>
On Wed, Sep 16, 2015 at 09:41:49AM +0900, Krzysztof Kozlowski wrote:
> On 16.09.2015 02:58, Andreas Dannenberg wrote:
> > A new optional device property called "ti,current-limit" is introduced
> > to allow disabling the D+/D- USB signal-based charger type auto-
> > detection algorithm used to set the input current limit and instead to
> > use a fixed input current limit.
> >
> > Signed-off-by: Andreas Dannenberg <dannenberg@ti.com>
> > ---
> > drivers/power/bq24257_charger.c | 102 +++++++++++++++++++++++++++++++---------
> > 1 file changed, 81 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
> > index fdfe855..55e4ee4 100644
> > --- a/drivers/power/bq24257_charger.c
> > +++ b/drivers/power/bq24257_charger.c
> > @@ -74,6 +74,7 @@ struct bq24257_init_data {
> > u8 ichg; /* charge current */
> > u8 vbat; /* regulation voltage */
> > u8 iterm; /* termination current */
> > + u8 in_ilimit; /* input current limit */
> > };
> >
> > struct bq24257_state {
> > @@ -100,6 +101,8 @@ struct bq24257_device {
> > struct bq24257_state state;
> >
> > struct mutex lock; /* protect state data */
> > +
> > + bool in_ilimit_autoset_disable;
> > };
> >
> > static bool bq24257_is_volatile_reg(struct device *dev, unsigned int reg)
> > @@ -188,6 +191,12 @@ static const u32 bq24257_iterm_map[] = {
> >
> > #define BQ24257_ITERM_MAP_SIZE ARRAY_SIZE(bq24257_iterm_map)
> >
> > +static const u32 bq24257_iilimit_map[] = {
>
> Too many ii? bq24257_ilimit_map? Or is it a shortcut for "in_ilimit"?
> New fields have pattern like "in_ilimit*".
> Anyway it's a confusing so maybe use everywhere the same pattern?
Yes that's supposed to be a shortcut for this internal variable. It's a
low-risk refactor so let me tweak this.
> > + 100000, 150000, 500000, 900000, 1500000, 2000000
> > +};
> > +
> > +#define BQ24257_IILIMIT_MAP_SIZE ARRAY_SIZE(bq24257_iilimit_map)
>
> ditto: ILIMIT_MAP_SIZE?
Ditto :)
> > +
> > static int bq24257_field_read(struct bq24257_device *bq,
> > enum bq24257_fields field_id)
> > {
> > @@ -479,24 +488,35 @@ static void bq24257_handle_state_change(struct bq24257_device *bq,
> > old_state = bq->state;
> > mutex_unlock(&bq->lock);
> >
> > - if (!new_state->power_good) { /* power removed */
> > - cancel_delayed_work_sync(&bq->iilimit_setup_work);
> > -
> > - /* activate D+/D- port detection algorithm */
> > - ret = bq24257_field_write(bq, F_DPDM_EN, 1);
> > - if (ret < 0)
> > - goto error;
> > + /*
> > + * Handle BQ2425x state changes observing whether the D+/D- based input
> > + * current limit autoset functionality is enabled.
> > + */
> > + if (!new_state->power_good) {
> > + dev_dbg(bq->dev, "Power removed\n");
> > + if (!bq->in_ilimit_autoset_disable) {
> > + cancel_delayed_work_sync(&bq->iilimit_setup_work);
> >
> > - reset_iilimit = true;
> > - } else if (!old_state.power_good) { /* power inserted */
> > - config_iilimit = true;
> > - } else if (new_state->fault == FAULT_NO_BAT) { /* battery removed */
> > - cancel_delayed_work_sync(&bq->iilimit_setup_work);
> > + /* activate D+/D- port detection algorithm */
> > + ret = bq24257_field_write(bq, F_DPDM_EN, 1);
> > + if (ret < 0)
> > + goto error;
> >
> > - reset_iilimit = true;
> > - } else if (old_state.fault == FAULT_NO_BAT) { /* battery connected */
> > - config_iilimit = true;
> > - } else if (new_state->fault == FAULT_TIMER) { /* safety timer expired */
> > + reset_iilimit = true;
> > + }
> > + } else if (!old_state.power_good) {
> > + dev_dbg(bq->dev, "Power inserted\n");
> > + config_iilimit = !bq->in_ilimit_autoset_disable;
> > + } else if (new_state->fault == FAULT_NO_BAT) {
> > + dev_warn(bq->dev, "Battery removed\n");
>
> dev_warn? This wasn't here before... It's a bit too serious. Is removing
> a battery an error condition? Maybe user just unplugged it?
> dev_dbg or dev_info should be sufficient.
>
> BTW, it is useful to quickly find boot regressions with "dmesg -l
> warn,err". Removing a battery probably is not an error?
I would argue that most devices that use a Li-Ion battery have the
battery built-in and it's not user removable. Therefore, if the battery
would ever go disconnected I figured it'll most likely be something
serious such as a contact breaking loose or something else dramatic,
warranting at least a warning. Plus, many devices with built in Li-Ion
batteries are actually designed in a way that they don't really function
properly with the battery taken out as the HW is often designed to draw
supplemental current from the battery during times of load in addition
to the A/C supply (key feature of many charger chips).
>
> > + if (!bq->in_ilimit_autoset_disable) {
> > + cancel_delayed_work_sync(&bq->iilimit_setup_work);
> > + reset_iilimit = true;
> > + }
> > + } else if (old_state.fault == FAULT_NO_BAT) {
> > + dev_warn(bq->dev, "Battery connected\n");
>
> Definitely not a warn. Inserting a battery is not an error condition.
Same as above.
> > + config_iilimit = !bq->in_ilimit_autoset_disable;
> > + } else if (new_state->fault == FAULT_TIMER) {
> > dev_err(bq->dev, "Safety timer expired! Battery dead?\n");
> > }
>
> Don't you have a schedule_delayed_work() call here which now will be
> executed always? Even when work was not INIT and nothing will cancel it?
It'll be more obvious when looking at the merged code but the schedule_
delayed_work() call only happens if config_iilimit==true which only
happens when the input limit current autoset functionality is not
disabled. If that's the case (autoset functionality is enabled) the INIT
for that work is executed during probe.
> >
> > @@ -581,7 +601,16 @@ static int bq24257_hw_init(struct bq24257_device *bq)
> > bq->state = state;
> > mutex_unlock(&bq->lock);
> >
> > - if (!state.power_good)
> > + if (bq->in_ilimit_autoset_disable) {
> > + dev_dbg(bq->dev, "manually setting iilimit = %d\n",
> > + bq->init_data.in_ilimit);
>
> Nit, no actual difference but makes more sense to me because field is
> u8: "%u".
Yes that should be changed.
> > +
> > + /* program fixed input current limit */
> > + ret = bq24257_field_write(bq, F_IILIMIT,
> > + bq->init_data.in_ilimit);
> > + if (ret < 0)
> > + return ret;
> > + } else if (!state.power_good)
> > /* activate D+/D- detection algorithm */
> > ret = bq24257_field_write(bq, F_DPDM_EN, 1);
> > else if (state.fault != FAULT_NO_BAT)
> > @@ -659,6 +688,7 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
> > int ret;
> > u32 property;
> >
> > + /* Required properties */
> > ret = device_property_read_u32(bq->dev, "ti,charge-current", &property);
> > if (ret < 0)
> > return ret;
> > @@ -682,6 +712,24 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
> > bq->init_data.iterm = bq24257_find_idx(property, bq24257_iterm_map,
> > BQ24257_ITERM_MAP_SIZE);
> >
> > + /* Optional properties. If not provided use reasonable default. */
> > + ret = device_property_read_u32(bq->dev, "ti,current-limit",
> > + &property);
> > + if (ret < 0)
> > + /*
> > + * Explicitly set a default value which will be needed for
> > + * devices that don't support the automatic setting of the input
> > + * current limit through the charger type detection mechanism.
> > + */
> > + bq->init_data.in_ilimit = IILIMIT_500;
> > + else {
> > + bq->in_ilimit_autoset_disable = true;
> > + bq->init_data.in_ilimit =
> > + bq24257_find_idx(property,
> > + bq24257_iilimit_map,
> > + BQ24257_IILIMIT_MAP_SIZE);
> > + }
> > +
> > return 0;
> > }
> >
> > @@ -740,8 +788,6 @@ static int bq24257_probe(struct i2c_client *client,
> >
> > i2c_set_clientdata(client, bq);
> >
> > - INIT_DELAYED_WORK(&bq->iilimit_setup_work, bq24257_iilimit_setup_work);
> > -
> > if (!dev->platform_data) {
> > ret = bq24257_fw_probe(bq);
> > if (ret < 0) {
> > @@ -752,6 +798,18 @@ static int bq24257_probe(struct i2c_client *client,
> > return -ENODEV;
> > }
> >
> > + /*
> > + * The BQ24250 doesn't support the D+/D- based charger type detection
> > + * used for the automatic setting of the input current limit setting so
> > + * explicitly disable that feature.
> > + */
> > + if (bq->chip == BQ24250)
> > + bq->in_ilimit_autoset_disable = true;
> > +
> > + if (!bq->in_ilimit_autoset_disable)
>
> In most places you have quite obfuscated negation of
> "autoset_disable"... So maybe just "bq->in_ilimit_autoset" or
> "bq->in_ilimit_autoset_enable" and the negation won't be needed? It
> could be more readable.
This stems from the fact that this was initially tied to a boolean DT
property with the same name which is no longer there. The other reason
was setting this property to non-zero changes the default behavior of
the driver (that used to have autoset always enabled) so I wanted to
reflect this behavior in the logic. The driver was tested pretty well so
unless you feel strongly about this I would rather leave it as-is.
Thanks for the feedback btw. I know it's a lot of work.
Regards,
--
Andreas Dannenberg
Texas Instruments Inc
next prev parent reply other threads:[~2015-09-16 19:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-15 17:58 [PATCH v4 00/10] power: bq24257: Add support for bq24250/bq24251 Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 02/10] power: bq24257: Add basic " Andreas Dannenberg
2015-09-16 0:19 ` Krzysztof Kozlowski
2015-09-16 19:02 ` Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 03/10] power: bq24257: Add bit definition for temp sense enable Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 04/10] power: bq24257: Allow manual setting of input current limit Andreas Dannenberg
2015-09-16 0:41 ` Krzysztof Kozlowski
2015-09-16 19:23 ` Andreas Dannenberg [this message]
2015-09-17 0:10 ` Krzysztof Kozlowski
[not found] ` <1442339914-25843-1-git-send-email-dannenberg-l0cyMroinI0@public.gmane.org>
2015-09-15 17:58 ` [PATCH v4 01/10] dt: power: bq24257-charger: Cover additional devices Andreas Dannenberg
2015-09-16 0:10 ` Krzysztof Kozlowski
2015-09-15 17:58 ` [PATCH v4 05/10] power: bq24257: Add SW-based approach for Power Good determination Andreas Dannenberg
2015-09-16 5:41 ` Krzysztof Kozlowski
2015-09-18 21:28 ` Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 06/10] power: bq24257: Add over voltage protection setting support Andreas Dannenberg
2015-09-16 5:55 ` Krzysztof Kozlowski
2015-09-16 19:34 ` Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 07/10] power: bq24257: Add input DPM voltage threshold " Andreas Dannenberg
2015-09-16 6:06 ` Krzysztof Kozlowski
2015-09-16 19:40 ` Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 08/10] power: bq24257: Allow input current limit sysfs access Andreas Dannenberg
2015-09-16 6:31 ` Krzysztof Kozlowski
2015-09-16 19:45 ` Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 09/10] power: bq24257: Add various device-specific sysfs properties Andreas Dannenberg
2015-09-16 8:10 ` Krzysztof Kozlowski
2015-09-16 19:54 ` Andreas Dannenberg
2015-09-18 19:08 ` Andreas Dannenberg
2015-09-15 17:58 ` [PATCH v4 10/10] power: bq24257: Add platform data based initialization Andreas Dannenberg
2015-09-16 8:31 ` Krzysztof Kozlowski
2015-09-16 20:11 ` Andreas Dannenberg
2015-09-17 0:16 ` Krzysztof Kozlowski
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=20150916192257.GB27772@beast \
--to=dannenberg@ti.com \
--cc=dbaryshkov@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=k.kozlowski@samsung.com \
--cc=laurentiu.palcu@intel.com \
--cc=linux-pm@vger.kernel.org \
--cc=ramakrishna.pallala@intel.com \
--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).