by Andy Shevchenko

[permalink] [raw]

Subject: Re: [PATCH 10/13] power: supply: bq25890: Add support for registering the Vbus boost converter as a regulator

On Sat, Oct 30, 2021 at 9:28 PM Hans de Goede <[email protected]> wrote:
>
> The bq25890_charger code supports enabling/disabling the boost converter
> based on usb-phy notifications. But the usb-phy framework is not used on
> all boards/platforms. At support for registering the Vbus boost converter
> as a standard regulator when there is no usb-phy on the board.
>
> Also add support for providing regulator_init_data through platform_data
> for use on boards where device-tree is not used and the platform code must
> thus provide the regulator_init_data.

...

> @@ -1018,6 +1059,21 @@ static int bq25890_probe(struct i2c_client *client,
> INIT_WORK(&bq->usb_work, bq25890_usb_work);
> bq->usb_nb.notifier_call = bq25890_usb_notifier;
> usb_register_notifier(bq->usb_phy, &bq->usb_nb);
> +#ifdef CONFIG_REGULATOR
> + } else {
> + struct bq25890_platform_data *pdata = dev_get_platdata(dev);
> + struct regulator_config cfg = { };
> + struct regulator_dev *reg;
> +
> + cfg.dev = dev;
> + cfg.driver_data = bq;
> + if (pdata)
> + cfg.init_data = pdata->regulator_init_data;
> +
> + reg = devm_regulator_register(dev, &bq25890_vbus_desc, &cfg);
> + if (IS_ERR(reg))
> + return dev_err_probe(dev, PTR_ERR(reg), "registering regulator");
> +#endif
> }

}
#ifdef
else {
...
}
#endif

is a bit better to maintain (less error prone in case of new code).

...

> +#ifndef _BQ25890_CHARGER_H_
> +#define _BQ25890_CHARGER_H_

> +#include <linux/regulator/machine.h>

struct regulator_init_data;

should be sufficient, no header is needed.

> +struct bq25890_platform_data {
> + const struct regulator_init_data *regulator_init_data;
> +};
> +
> +#endif

--
With Best Regards,
Andy Shevchenko

2021-10-31 18:01:08

by Wolfram Sang

[permalink] [raw]

Subject: Re: [PATCH 11/13] i2c: cht-wc: Add support for devices using a bq25890 charger

Attachments:

(No filename) (1.83 kB)
signature.asc (849.00 B)
Download all attachments

2021-11-02 16:38:12

by Sebastian Reichel

[permalink] [raw]

Subject: Re: [PATCH 04/13] power: supply: bq25890: Fix initial setting of the F_CONV_RATE field

Hi,

On Sat, Oct 30, 2021 at 08:28:04PM +0200, Hans de Goede wrote:
> The code doing the initial setting of the F_CONV_RATE field based
> on the bq->state.online flag. In order for this to work properly,
> this must be done after the initial bq25890_get_chip_state() call.
>
> Signed-off-by: Hans de Goede <[email protected]>
> ---

Thanks, queued.

-- Sebastian

> drivers/power/supply/bq25890_charger.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/power/supply/bq25890_charger.c b/drivers/power/supply/bq25890_charger.c
> index 491d36a3811a..99497fdc73da 100644
> --- a/drivers/power/supply/bq25890_charger.c
> +++ b/drivers/power/supply/bq25890_charger.c
> @@ -682,16 +682,16 @@ static int bq25890_hw_init(struct bq25890_device *bq)
> }
> }
>
> - /* Configure ADC for continuous conversions when charging */
> - ret = bq25890_field_write(bq, F_CONV_RATE, !!bq->state.online);
> + ret = bq25890_get_chip_state(bq, &bq->state);
> if (ret < 0) {
> - dev_dbg(bq->dev, "Config ADC failed %d\n", ret);
> + dev_dbg(bq->dev, "Get state failed %d\n", ret);
> return ret;
> }
>
> - ret = bq25890_get_chip_state(bq, &bq->state);
> + /* Configure ADC for continuous conversions when charging */
> + ret = bq25890_field_write(bq, F_CONV_RATE, !!bq->state.online);
> if (ret < 0) {
> - dev_dbg(bq->dev, "Get state failed %d\n", ret);
> + dev_dbg(bq->dev, "Config ADC failed %d\n", ret);
> return ret;
> }
>
> --
> 2.31.1
>

Attachments:

(No filename) (1.50 kB)
signature.asc (849.00 B)
Download all attachments

2021-11-02 16:39:06

Hi Andy,

Thank you for your feedback.

On 10/30/21 23:56, Andy Shevchenko wrote:
> On Sat, Oct 30, 2021 at 9:28 PM Hans de Goede <[email protected]> wrote:
>>
>> Add a new "intel,cht-wc-setup" string property to the "INT34D3:00"
>> i2c_client for the Whiskey Cove PMIC found on several Cherry Trail
>> based devices. At least 3 setups are known:
>>
>> 1. The WC PMIC is connected to a TI BQ24292i charger, paired with
>> a Maxim MAX17047 fuelgauge + a FUSB302 USB Type-C Controller +
>> a PI3USB30532 USB switch, for a fully functional Type-C port
>>
>> 2. The WC PMIC is connected to a TI BQ25890 charger, paired with
>> a TI BQ27520 fuelgauge, for a USB-2 only Type-C port without PD
>>
>> 3. The WC PMIC is connected to a TI BQ25890 charger, paired with
>> a TI BQ27542 fuelgauge, for a micro-USB port
>>
>> Which setup is in use cannot be determined reliably from the ACPI tables
>> and various drivers (extcon-intel-cht-wc.c, i2c-cht-wc.c, ...) need
>> to know which setup they are dealing with.
>
> If it's internal property only, I would rather expect it to start with
> 'linux,' as DWC3 does. And it's also USB related.
>
> ...
>
>> + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq24292i,max17047,fusb302,pi3usb30532"),
>
>> + PROPERTY_ENTRY_STRING("intel,cht-wc-setup", "bq25890,bq27520"),
>
> Besides that I'm not sure about the name of the property, maybe
> 'linux,cht-wc-usb-chips' or alike? And since it's a list, can we make
> it a string array?
>

So now that I also have a yogabook to test on it has become clear that
we really need to treat each device-model/board with a cht-wc PMIC
differently in the various cht-wc MFD cell drivers.

So instead of using device-properties (patch 1 + 2 from this series)
I've chosen to add a intel_cht_wc_get_model( helper to:
drivers/mfd/intel_soc_pmic_chtwc.c

Which uses DMI matching (in a shared place so that we need the DMI
table only once) and returns an enum value which represents all
known boards.

Regards,

Hans