public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: Yauhen Kharuzhy <jekhor@gmail.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Sebastian Reichel <sre@kernel.org>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] bq25890: Add max input current limit property
Date: Mon, 8 Nov 2021 00:08:32 +0300	[thread overview]
Message-ID: <YYhAUH2nvj1b0uCW@jeknote.loshitsa1.net> (raw)
In-Reply-To: <85a4674a-9212-6f02-d351-72b2223cc4a9@redhat.com>

On Sun, Nov 07, 2021 at 09:41:55PM +0100, Hans de Goede wrote:
> Hi Yauhen,
> 
> On 11/7/21 21:19, Yauhen Kharuzhy wrote:
> > Add property 'ti,input-max-current' to define input current limit if
> > needed. It will be applied if automatic charger type detection is
> > disabled and using of ILIM pin is disabled or such pin defines greater
> > limit than IINLIM field.
> 
> Sorry, but this makes no sense, as the datasheet says the charger
> itself updates iinlim dynamically when it has done charger-type
> detection (for the bq25890 version) and for the bq25892 version
> which does not have the D+ + D- USB pins for BC1.2 detection,
> the iinlim should be updated based on the charger detection
> done elsewhere (by the Whiskey Cove PMIC in case of the Yoga Book).

For Yoga Book, charger detection in the bq25892 is disabled and done in
the extcon driver.

> My plan for this is to have drivers/extcon/extcon-intel-cht-wc.c
> also register a power_supply device which models the detected
> charger / negotiated external charger/power-brick settings and
> which is the supplier of the bq25892 charger.
> 
> Then an external_power_changed handler can be added to the
> bq25892_charger code using the
> power_supply_set_input_current_limit_from_supplier()
> helper to dynamically set iinlim based on the detected
> "power-brick"/external-charger.
> 
> This is also how this is done for (X86) devices with an
> full-featured USB Type-C port where this needs to be handled
> by the kernel (rather then it being done in firmware) in
> this case the current-max property of the Type-C power-supply
> class device gets set either based on the Type-C pull-up
> resistor in the charger (setting 0.5A / 1.5A / 3A), with
> a fallback to BC1.2 for the 0.5A case, or based on the
> USB-PD negotiated max-current.

Agree, looks reasonable.

> 
> Since we will need this mechanism to dynamically set
> iinlim based on the PMIC-s charger-detection it seems
> to me that setting it at boot is both unnecessary and a bad
> idea, since we don't know the correct value to set at boot.
> 
> The extcon code will start a charger-detection cycle
> as soon as it loads (if there is Vbus present) and then
> trigger the external_power_changed handler .
> 
> TL;DR: I don't really see a need for this ?

Hmm... I think you are rigth. The only case when such property can be
needed – if the device may be damaged by maximum current supported by
charging source. I use it to limit current by 2A when original Lenovo adapter
is connected because the linux kernel has default max current limit
5A for DCP (drivers/usb/phy/phy.c) but adapter supports only 2A.

> 
> 
> > ---
> >  drivers/power/supply/bq25890_charger.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/drivers/power/supply/bq25890_charger.c b/drivers/power/supply/bq25890_charger.c
> > index 34467bfb9537..1c43555d5bd8 100644
> > --- a/drivers/power/supply/bq25890_charger.c
> > +++ b/drivers/power/supply/bq25890_charger.c
> > @@ -85,6 +85,7 @@ struct bq25890_init_data {
> >  	u8 treg;	/* thermal regulation threshold */
> >  	u8 rbatcomp;	/* IBAT sense resistor value    */
> >  	u8 vclamp;	/* IBAT compensation voltage limit */
> > +	u8 iinlim_max;	/* maximum input current limit allowed */
> >  };
> >  
> >  struct bq25890_state {
> > @@ -657,6 +658,7 @@ static int bq25890_hw_init(struct bq25890_device *bq)
> >  		{F_TREG,	 bq->init_data.treg},
> >  		{F_BATCMP,	 bq->init_data.rbatcomp},
> >  		{F_VCLAMP,	 bq->init_data.vclamp},
> > +		{F_IINLIM,	 bq->init_data.iinlim_max},
> >  	};
> >  
> >  	ret = bq25890_chip_reset(bq);
> > @@ -870,11 +872,13 @@ static int bq25890_fw_read_u32_props(struct bq25890_device *bq)
> >  		{"ti,thermal-regulation-threshold", true, TBL_TREG, &init->treg},
> >  		{"ti,ibatcomp-micro-ohms", true, TBL_RBATCOMP, &init->rbatcomp},
> >  		{"ti,ibatcomp-clamp-microvolt", true, TBL_VBATCOMP, &init->vclamp},
> > +		{"ti,input-max-current", true, TBL_IINLIM, &init->iinlim_max},
> >  	};
> >  
> >  	/* initialize data for optional properties */
> >  	init->treg = 3; /* 120 degrees Celsius */
> >  	init->rbatcomp = init->vclamp = 0; /* IBAT compensation disabled */
> > +	init->iinlim_max = 0x3f;
> >  
> >  	for (i = 0; i < ARRAY_SIZE(props); i++) {
> >  		ret = device_property_read_u32(bq->dev, props[i].name,
> > 
> 

-- 
Yauhen Kharuzhy

  reply	other threads:[~2021-11-07 21:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-07 20:19 [PATCH 1/4] bq25890_charger: Rename IILIM field to IINLIM Yauhen Kharuzhy
2021-11-07 20:19 ` [PATCH 2/4] bq25890: Add max input current limit property Yauhen Kharuzhy
2021-11-07 20:41   ` Hans de Goede
2021-11-07 21:08     ` Yauhen Kharuzhy [this message]
2021-11-07 22:05       ` Hans de Goede
2021-11-07 20:20 ` [PATCH 3/4] power supply bq25890-charger: Handle temperature faults Yauhen Kharuzhy
2021-11-07 20:46   ` Hans de Goede
2021-11-07 20:20 ` [PATCH 4/4] bq25890_charger: Enable continuous conversion for ADC at charging Yauhen Kharuzhy
2021-11-07 20:48   ` Hans de Goede
2021-11-15 15:23     ` Sebastian Reichel
2021-11-15 15:40       ` Hans de Goede
2021-11-07 20:29 ` [PATCH 1/4] bq25890_charger: Rename IILIM field to IINLIM Hans de Goede

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=YYhAUH2nvj1b0uCW@jeknote.loshitsa1.net \
    --to=jekhor@gmail.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --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