| Message ID | cover.1663926551.git.chiaen_wu@richtek.com |
|---|---|
| Headers | show |
| Series | Add MediaTek MT6370 PMIC support | expand |
On Fri, 23 Sep 2022 10:51:24 +0800 ChiaEn Wu <peterwu.pub@gmail.com> wrote: > From: ChiaEn Wu <chiaen_wu@richtek.com> > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > driver, display bias voltage supply, one general purpose LDO, and the > USB Type-C & PD controller complies with the latest USB Type-C and PD > standards. > > Add support for the MT6370 ADC driver for system monitoring, including > charger current, voltage, and temperature. > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> This will have to either wait for next cycle, or go through mfd because of the dt-bindings include which is in the mfd tree. Please make those dependencies clear in new versions. +CC Lee Thanks, Jonathan > --- > drivers/iio/adc/Kconfig | 12 ++ > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/mt6370-adc.c | 305 +++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 318 insertions(+) > create mode 100644 drivers/iio/adc/mt6370-adc.c > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index 7fe5930..995cbb5 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -736,6 +736,18 @@ config MEDIATEK_MT6360_ADC > is used in smartphones and tablets and supports a 11 channel > general purpose ADC. > > +config MEDIATEK_MT6370_ADC > + tristate "MediaTek MT6370 ADC driver" > + depends on MFD_MT6370 > + help > + Say yes here to enable MediaTek MT6370 ADC support. > + > + This ADC driver provides 9 channels for system monitoring (charger > + current, voltage, and temperature). > + > + This driver can also be built as a module. If so, the module > + will be called "mt6370-adc". > + > config MEDIATEK_MT6577_AUXADC > tristate "MediaTek AUXADC driver" > depends on ARCH_MEDIATEK || COMPILE_TEST > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > index 1772a54..c6bc35f 100644 > --- a/drivers/iio/adc/Makefile > +++ b/drivers/iio/adc/Makefile > @@ -68,6 +68,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o > obj-$(CONFIG_MCP3422) += mcp3422.o > obj-$(CONFIG_MCP3911) += mcp3911.o > obj-$(CONFIG_MEDIATEK_MT6360_ADC) += mt6360-adc.o > +obj-$(CONFIG_MEDIATEK_MT6370_ADC) += mt6370-adc.o > obj-$(CONFIG_MEDIATEK_MT6577_AUXADC) += mt6577_auxadc.o > obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o > obj-$(CONFIG_MESON_SARADC) += meson_saradc.o > diff --git a/drivers/iio/adc/mt6370-adc.c b/drivers/iio/adc/mt6370-adc.c > new file mode 100644 > index 0000000..2a46471 > --- /dev/null > +++ b/drivers/iio/adc/mt6370-adc.c > @@ -0,0 +1,305 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +/* > + * Copyright (C) 2022 Richtek Technology Corp. > + * > + * Author: ChiaEn Wu <chiaen_wu@richtek.com> > + */ > + > +#include <linux/bits.h> > +#include <linux/bitfield.h> > +#include <linux/iio/iio.h> > +#include <linux/kernel.h> > +#include <linux/mod_devicetable.h> > +#include <linux/module.h> > +#include <linux/mutex.h> > +#include <linux/platform_device.h> > +#include <linux/regmap.h> > +#include <linux/sysfs.h> > +#include <linux/units.h> > + > +#include <dt-bindings/iio/adc/mediatek,mt6370_adc.h> > + > +#define MT6370_REG_CHG_CTRL3 0x113 > +#define MT6370_REG_CHG_CTRL7 0x117 > +#define MT6370_REG_CHG_ADC 0x121 > +#define MT6370_REG_ADC_DATA_H 0x14C > + > +#define MT6370_ADC_START_MASK BIT(0) > +#define MT6370_ADC_IN_SEL_MASK GENMASK(7, 4) > +#define MT6370_AICR_ICHG_MASK GENMASK(7, 2) > + > +#define MT6370_AICR_100_mA 0x0 > +#define MT6370_AICR_150_mA 0x1 > +#define MT6370_AICR_200_mA 0x2 > +#define MT6370_AICR_250_mA 0x3 > +#define MT6370_AICR_300_mA 0x4 > +#define MT6370_AICR_350_mA 0x5 > + > +#define MT6370_ICHG_100_mA 0x0 > +#define MT6370_ICHG_200_mA 0x1 > +#define MT6370_ICHG_300_mA 0x2 > +#define MT6370_ICHG_400_mA 0x3 > +#define MT6370_ICHG_500_mA 0x4 > +#define MT6370_ICHG_600_mA 0x5 > +#define MT6370_ICHG_700_mA 0x6 > +#define MT6370_ICHG_800_mA 0x7 > + > +#define ADC_CONV_TIME_MS 35 > +#define ADC_CONV_POLLING_TIME_US 1000 > + > +struct mt6370_adc_data { > + struct device *dev; > + struct regmap *regmap; > + /* > + * This mutex lock is for preventing the different ADC channels > + * from being read at the same time. > + */ > + struct mutex adc_lock; > +}; > + > +static int mt6370_adc_read_channel(struct mt6370_adc_data *priv, int chan, > + unsigned long addr, int *val) > +{ > + unsigned int reg_val; > + __be16 be_val; > + int ret; > + > + mutex_lock(&priv->adc_lock); > + > + reg_val = MT6370_ADC_START_MASK | > + FIELD_PREP(MT6370_ADC_IN_SEL_MASK, addr); > + ret = regmap_write(priv->regmap, MT6370_REG_CHG_ADC, reg_val); > + if (ret) > + goto adc_unlock; > + > + msleep(ADC_CONV_TIME_MS); > + > + ret = regmap_read_poll_timeout(priv->regmap, > + MT6370_REG_CHG_ADC, reg_val, > + !(reg_val & MT6370_ADC_START_MASK), > + ADC_CONV_POLLING_TIME_US, > + ADC_CONV_TIME_MS * MILLI * 3); > + if (ret) { > + dev_err(priv->dev, "Failed to read ADC register (%d)\n", ret); > + goto adc_unlock; > + } > + > + ret = regmap_raw_read(priv->regmap, MT6370_REG_ADC_DATA_H, > + &be_val, sizeof(be_val)); > + if (ret) > + goto adc_unlock; > + > + *val = be16_to_cpu(be_val); > + ret = IIO_VAL_INT; > + > +adc_unlock: > + mutex_unlock(&priv->adc_lock); > + > + return ret; > +} > + > +static int mt6370_adc_read_scale(struct mt6370_adc_data *priv, > + int chan, int *val1, int *val2) > +{ > + unsigned int reg_val; > + int ret; > + > + switch (chan) { > + case MT6370_CHAN_VBAT: > + case MT6370_CHAN_VSYS: > + case MT6370_CHAN_CHG_VDDP: > + *val1 = 5; > + return IIO_VAL_INT; > + case MT6370_CHAN_IBUS: > + ret = regmap_read(priv->regmap, MT6370_REG_CHG_CTRL3, ®_val); > + if (ret) > + return ret; > + > + reg_val = FIELD_GET(MT6370_AICR_ICHG_MASK, reg_val); > + switch (reg_val) { > + case MT6370_AICR_100_mA: > + case MT6370_AICR_150_mA: > + case MT6370_AICR_200_mA: > + case MT6370_AICR_250_mA: > + case MT6370_AICR_300_mA: > + case MT6370_AICR_350_mA: > + *val1 = 3350; > + break; > + default: > + *val1 = 5000; > + break; > + } > + > + *val2 = 100; > + > + return IIO_VAL_FRACTIONAL; > + case MT6370_CHAN_IBAT: > + ret = regmap_read(priv->regmap, MT6370_REG_CHG_CTRL7, ®_val); > + if (ret) > + return ret; > + > + reg_val = FIELD_GET(MT6370_AICR_ICHG_MASK, reg_val); > + switch (reg_val) { > + case MT6370_ICHG_100_mA: > + case MT6370_ICHG_200_mA: > + case MT6370_ICHG_300_mA: > + case MT6370_ICHG_400_mA: > + *val1 = 2375; > + break; > + case MT6370_ICHG_500_mA: > + case MT6370_ICHG_600_mA: > + case MT6370_ICHG_700_mA: > + case MT6370_ICHG_800_mA: > + *val1 = 2680; > + break; > + default: > + *val1 = 5000; > + break; > + } > + > + *val2 = 100; > + > + return IIO_VAL_FRACTIONAL; > + case MT6370_CHAN_VBUSDIV5: > + *val1 = 25; > + return IIO_VAL_INT; > + case MT6370_CHAN_VBUSDIV2: > + *val1 = 50; > + return IIO_VAL_INT; > + case MT6370_CHAN_TS_BAT: > + *val1 = 25; > + *val2 = 10000; > + return IIO_VAL_FRACTIONAL; > + case MT6370_CHAN_TEMP_JC: > + *val1 = 2000; > + return IIO_VAL_FRACTIONAL; > + default: > + return -EINVAL; > + } > +} > + > +static int mt6370_adc_read_offset(struct mt6370_adc_data *priv, > + int chan, int *val) > +{ > + *val = -20; > + > + return IIO_VAL_INT; > +} > + > +static int mt6370_adc_read_raw(struct iio_dev *iio_dev, > + const struct iio_chan_spec *chan, > + int *val, int *val2, long mask) > +{ > + struct mt6370_adc_data *priv = iio_priv(iio_dev); > + > + switch (mask) { > + case IIO_CHAN_INFO_RAW: > + return mt6370_adc_read_channel(priv, chan->channel, > + chan->address, val); > + case IIO_CHAN_INFO_SCALE: > + return mt6370_adc_read_scale(priv, chan->channel, val, val2); > + case IIO_CHAN_INFO_OFFSET: > + return mt6370_adc_read_offset(priv, chan->channel, val); > + default: > + return -EINVAL; > + } > +} > + > +static const char * const mt6370_channel_labels[MT6370_CHAN_MAX] = { > + [MT6370_CHAN_VBUSDIV5] = "vbusdiv5", > + [MT6370_CHAN_VBUSDIV2] = "vbusdiv2", > + [MT6370_CHAN_VSYS] = "vsys", > + [MT6370_CHAN_VBAT] = "vbat", > + [MT6370_CHAN_TS_BAT] = "ts_bat", > + [MT6370_CHAN_IBUS] = "ibus", > + [MT6370_CHAN_IBAT] = "ibat", > + [MT6370_CHAN_CHG_VDDP] = "chg_vddp", > + [MT6370_CHAN_TEMP_JC] = "temp_jc", > +}; > + > +static int mt6370_adc_read_label(struct iio_dev *iio_dev, > + struct iio_chan_spec const *chan, char *label) > +{ > + return sysfs_emit(label, "%s\n", mt6370_channel_labels[chan->channel]); > +} > + > +static const struct iio_info mt6370_adc_iio_info = { > + .read_raw = mt6370_adc_read_raw, > + .read_label = mt6370_adc_read_label, > +}; > + > +#define MT6370_ADC_CHAN(_idx, _type, _addr, _extra_info) { \ > + .type = _type, \ > + .channel = MT6370_CHAN_##_idx, \ > + .address = _addr, \ > + .scan_index = MT6370_CHAN_##_idx, \ > + .indexed = 1, \ > + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \ > + BIT(IIO_CHAN_INFO_SCALE) | \ > + _extra_info, \ > +} > + > +static const struct iio_chan_spec mt6370_adc_channels[] = { > + MT6370_ADC_CHAN(VBUSDIV5, IIO_VOLTAGE, 1, 0), > + MT6370_ADC_CHAN(VBUSDIV2, IIO_VOLTAGE, 2, 0), > + MT6370_ADC_CHAN(VSYS, IIO_VOLTAGE, 3, 0), > + MT6370_ADC_CHAN(VBAT, IIO_VOLTAGE, 4, 0), > + MT6370_ADC_CHAN(TS_BAT, IIO_VOLTAGE, 6, 0), > + MT6370_ADC_CHAN(IBUS, IIO_CURRENT, 8, 0), > + MT6370_ADC_CHAN(IBAT, IIO_CURRENT, 9, 0), > + MT6370_ADC_CHAN(CHG_VDDP, IIO_VOLTAGE, 11, 0), > + MT6370_ADC_CHAN(TEMP_JC, IIO_TEMP, 12, BIT(IIO_CHAN_INFO_OFFSET)), > +}; > + > +static int mt6370_adc_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct mt6370_adc_data *priv; > + struct iio_dev *indio_dev; > + struct regmap *regmap; > + int ret; > + > + regmap = dev_get_regmap(pdev->dev.parent, NULL); > + if (!regmap) > + return dev_err_probe(dev, -ENODEV, "Failed to get regmap\n"); > + > + indio_dev = devm_iio_device_alloc(dev, sizeof(*priv)); > + if (!indio_dev) > + return -ENOMEM; > + > + priv = iio_priv(indio_dev); > + priv->dev = dev; > + priv->regmap = regmap; > + mutex_init(&priv->adc_lock); > + > + ret = regmap_write(priv->regmap, MT6370_REG_CHG_ADC, 0); > + if (ret) > + return dev_err_probe(dev, ret, "Failed to reset ADC\n"); > + > + indio_dev->name = "mt6370-adc"; > + indio_dev->info = &mt6370_adc_iio_info; > + indio_dev->modes = INDIO_DIRECT_MODE; > + indio_dev->channels = mt6370_adc_channels; > + indio_dev->num_channels = ARRAY_SIZE(mt6370_adc_channels); > + > + return devm_iio_device_register(dev, indio_dev); > +} > + > +static const struct of_device_id mt6370_adc_of_id[] = { > + { .compatible = "mediatek,mt6370-adc", }, > + {} > +}; > +MODULE_DEVICE_TABLE(of, mt6370_adc_of_id); > + > +static struct platform_driver mt6370_adc_driver = { > + .driver = { > + .name = "mt6370-adc", > + .of_match_table = mt6370_adc_of_id, > + }, > + .probe = mt6370_adc_probe, > +}; > +module_platform_driver(mt6370_adc_driver); > + > +MODULE_AUTHOR("ChiaEn Wu <chiaen_wu@richtek.com>"); > +MODULE_DESCRIPTION("MT6370 ADC Driver"); > +MODULE_LICENSE("GPL v2");
On Sat, 24 Sep 2022, Jonathan Cameron wrote: > On Fri, 23 Sep 2022 10:51:24 +0800 > ChiaEn Wu <peterwu.pub@gmail.com> wrote: > > > From: ChiaEn Wu <chiaen_wu@richtek.com> > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > > driver, display bias voltage supply, one general purpose LDO, and the > > USB Type-C & PD controller complies with the latest USB Type-C and PD > > standards. > > > > Add support for the MT6370 ADC driver for system monitoring, including > > charger current, voltage, and temperature. > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> > > This will have to either wait for next cycle, or go through mfd because > of the dt-bindings include which is in the mfd tree. > > Please make those dependencies clear in new versions. If the bindings come together in -next, then subsequently in Mainline, it shouldn't really matter. It's only your IIO tree that the DT tooling with complain about, right?
On Mon, Sep 26, 2022 at 2:46 AM Lee Jones <lee@kernel.org> wrote: > > On Sat, 24 Sep 2022, Jonathan Cameron wrote: > > > On Fri, 23 Sep 2022 10:51:24 +0800 > > ChiaEn Wu <peterwu.pub@gmail.com> wrote: > > > > > From: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > > > driver, display bias voltage supply, one general purpose LDO, and the > > > USB Type-C & PD controller complies with the latest USB Type-C and PD > > > standards. > > > > > > Add support for the MT6370 ADC driver for system monitoring, including > > > charger current, voltage, and temperature. > > > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> > > > > This will have to either wait for next cycle, or go through mfd because > > of the dt-bindings include which is in the mfd tree. > > > > Please make those dependencies clear in new versions. > > If the bindings come together in -next, then subsequently in Mainline, > it shouldn't really matter. Except that the bindings haven't come together and at this point may not for 6.1. linux-next has been warning for weeks because the child device schemas haven't been applied. I've said it before, all the schemas for MFD devices need to be applied together. Or at least the MFD schema needs to get applied last. Furthermore, subsequent versions of this don't get tested and we end up with more warnings[1]. It's only your IIO tree that the DT > tooling with complain about, right? And the MFD tree... Please apply the LED bindings (patches 1 and 2) so we can get the existing warnings fixed and address any new warnings. Rob [1] https://lore.kernel.org/all/CAL_Jsq+Zkgfq0q_XgpLEjHLPGSuG06L6y5YbzbiberNMWtAuJw@mail.gmail.com/
On Mon, 26 Sep 2022, Rob Herring wrote: > On Mon, Sep 26, 2022 at 2:46 AM Lee Jones <lee@kernel.org> wrote: > > > > On Sat, 24 Sep 2022, Jonathan Cameron wrote: > > > > > On Fri, 23 Sep 2022 10:51:24 +0800 > > > ChiaEn Wu <peterwu.pub@gmail.com> wrote: > > > > > > > From: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > > > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > > > > driver, display bias voltage supply, one general purpose LDO, and the > > > > USB Type-C & PD controller complies with the latest USB Type-C and PD > > > > standards. > > > > > > > > Add support for the MT6370 ADC driver for system monitoring, including > > > > charger current, voltage, and temperature. > > > > > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > This will have to either wait for next cycle, or go through mfd because > > > of the dt-bindings include which is in the mfd tree. > > > > > > Please make those dependencies clear in new versions. > > > > If the bindings come together in -next, then subsequently in Mainline, > > it shouldn't really matter. > > Except that the bindings haven't come together and at this point may > not for 6.1. linux-next has been warning for weeks because the child > device schemas haven't been applied. I've said it before, all the > schemas for MFD devices need to be applied together. Or at least the > MFD schema needs to get applied last. > > Furthermore, subsequent versions of this don't get tested and we end > up with more warnings[1]. > > It's only your IIO tree that the DT > > tooling with complain about, right? > > And the MFD tree... > > Please apply the LED bindings (patches 1 and 2) so we can get the > existing warnings fixed and address any new warnings. Who usually applies LED bindings? Looks as though they're good to go.
On Wed, Sep 28, 2022 at 10:23:42AM +0100, Lee Jones wrote: > On Mon, 26 Sep 2022, Rob Herring wrote: > > > On Mon, Sep 26, 2022 at 2:46 AM Lee Jones <lee@kernel.org> wrote: > > > > > > On Sat, 24 Sep 2022, Jonathan Cameron wrote: > > > > > > > On Fri, 23 Sep 2022 10:51:24 +0800 > > > > ChiaEn Wu <peterwu.pub@gmail.com> wrote: > > > > > > > > > From: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > > > > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > > > > > driver, display bias voltage supply, one general purpose LDO, and the > > > > > USB Type-C & PD controller complies with the latest USB Type-C and PD > > > > > standards. > > > > > > > > > > Add support for the MT6370 ADC driver for system monitoring, including > > > > > charger current, voltage, and temperature. > > > > > > > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > This will have to either wait for next cycle, or go through mfd because > > > > of the dt-bindings include which is in the mfd tree. > > > > > > > > Please make those dependencies clear in new versions. > > > > > > If the bindings come together in -next, then subsequently in Mainline, > > > it shouldn't really matter. > > > > Except that the bindings haven't come together and at this point may > > not for 6.1. linux-next has been warning for weeks because the child > > device schemas haven't been applied. I've said it before, all the > > schemas for MFD devices need to be applied together. Or at least the > > MFD schema needs to get applied last. > > > > Furthermore, subsequent versions of this don't get tested and we end > > up with more warnings[1]. > > > > It's only your IIO tree that the DT > > > tooling with complain about, right? > > > > And the MFD tree... > > > > Please apply the LED bindings (patches 1 and 2) so we can get the > > existing warnings fixed and address any new warnings. > > Who usually applies LED bindings? Looks as though they're good to go. Pavel. The issue would be I don't know if the driver side is ready and those usually go together. Other than my complaining here, how's he supposed to know that the bindings at least need to be applied? Again, the process here is not working. I've said before, all the bindings for an MFD need to go via 1 tree. You obviously don't agree, so propose something. The current process of no coordination doesn't work. Rob
On Thu, 29 Sep 2022, Rob Herring wrote: > On Wed, Sep 28, 2022 at 10:23:42AM +0100, Lee Jones wrote: > > On Mon, 26 Sep 2022, Rob Herring wrote: > > > > > On Mon, Sep 26, 2022 at 2:46 AM Lee Jones <lee@kernel.org> wrote: > > > > > > > > On Sat, 24 Sep 2022, Jonathan Cameron wrote: > > > > > > > > > On Fri, 23 Sep 2022 10:51:24 +0800 > > > > > ChiaEn Wu <peterwu.pub@gmail.com> wrote: > > > > > > > > > > > From: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > > > > > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > > > > > > driver, display bias voltage supply, one general purpose LDO, and the > > > > > > USB Type-C & PD controller complies with the latest USB Type-C and PD > > > > > > standards. > > > > > > > > > > > > Add support for the MT6370 ADC driver for system monitoring, including > > > > > > charger current, voltage, and temperature. > > > > > > > > > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > > > This will have to either wait for next cycle, or go through mfd because > > > > > of the dt-bindings include which is in the mfd tree. > > > > > > > > > > Please make those dependencies clear in new versions. > > > > > > > > If the bindings come together in -next, then subsequently in Mainline, > > > > it shouldn't really matter. > > > > > > Except that the bindings haven't come together and at this point may > > > not for 6.1. linux-next has been warning for weeks because the child > > > device schemas haven't been applied. I've said it before, all the > > > schemas for MFD devices need to be applied together. Or at least the > > > MFD schema needs to get applied last. > > > > > > Furthermore, subsequent versions of this don't get tested and we end > > > up with more warnings[1]. > > > > > > It's only your IIO tree that the DT > > > > tooling with complain about, right? > > > > > > And the MFD tree... > > > > > > Please apply the LED bindings (patches 1 and 2) so we can get the > > > existing warnings fixed and address any new warnings. > > > > Who usually applies LED bindings? Looks as though they're good to go. > > Pavel. The issue would be I don't know if the driver side is ready and > those usually go together. Other than my complaining here, how's he > supposed to know that the bindings at least need to be applied? > > Again, the process here is not working. I've said before, all the > bindings for an MFD need to go via 1 tree. You obviously don't agree, so > propose something. The current process of no coordination doesn't work. The solution would be for someone to create succinct immutable branches, like I do for real code. If someone would be happy to do that, I'd be more than happy to pull from them. I go to the effort of creating them to prevent actual build breakages, however doing so to keep a documentation helper script happy is a step too far for me personally, sorry.
On Thu, 29 Sep 2022 18:51:32 +0100 Lee Jones <lee@kernel.org> wrote: > On Thu, 29 Sep 2022, Rob Herring wrote: > > > On Wed, Sep 28, 2022 at 10:23:42AM +0100, Lee Jones wrote: > > > On Mon, 26 Sep 2022, Rob Herring wrote: > > > > > > > On Mon, Sep 26, 2022 at 2:46 AM Lee Jones <lee@kernel.org> wrote: > > > > > > > > > > On Sat, 24 Sep 2022, Jonathan Cameron wrote: > > > > > > > > > > > On Fri, 23 Sep 2022 10:51:24 +0800 > > > > > > ChiaEn Wu <peterwu.pub@gmail.com> wrote: > > > > > > > > > > > > > From: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > > > > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > > > > > > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > > > > > > > driver, display bias voltage supply, one general purpose LDO, and the > > > > > > > USB Type-C & PD controller complies with the latest USB Type-C and PD > > > > > > > standards. > > > > > > > > > > > > > > Add support for the MT6370 ADC driver for system monitoring, including > > > > > > > charger current, voltage, and temperature. > > > > > > > > > > > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > > > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > > > > > This will have to either wait for next cycle, or go through mfd because > > > > > > of the dt-bindings include which is in the mfd tree. > > > > > > > > > > > > Please make those dependencies clear in new versions. > > > > > > > > > > If the bindings come together in -next, then subsequently in Mainline, > > > > > it shouldn't really matter. > > > > > > > > Except that the bindings haven't come together and at this point may > > > > not for 6.1. linux-next has been warning for weeks because the child > > > > device schemas haven't been applied. I've said it before, all the > > > > schemas for MFD devices need to be applied together. Or at least the > > > > MFD schema needs to get applied last. > > > > > > > > Furthermore, subsequent versions of this don't get tested and we end > > > > up with more warnings[1]. > > > > > > > > It's only your IIO tree that the DT > > > > > tooling with complain about, right? > > > > > > > > And the MFD tree... > > > > > > > > Please apply the LED bindings (patches 1 and 2) so we can get the > > > > existing warnings fixed and address any new warnings. > > > > > > Who usually applies LED bindings? Looks as though they're good to go. > > > > Pavel. The issue would be I don't know if the driver side is ready and > > those usually go together. Other than my complaining here, how's he > > supposed to know that the bindings at least need to be applied? > > > > Again, the process here is not working. I've said before, all the > > bindings for an MFD need to go via 1 tree. You obviously don't agree, so > > propose something. The current process of no coordination doesn't work. > > The solution would be for someone to create succinct immutable branches, like > I do for real code. If someone would be happy to do that, I'd be more than > happy to pull from them. > > I go to the effort of creating them to prevent actual build breakages, > however doing so to keep a documentation helper script happy is a step > too far for me personally, sorry. > In this case the bindings include is included from the driver - not just the binding. Obviously there are dances to get around that by using the values and replacing in following cycle, but that's not the case here! Jonathan
On Sat, 01 Oct 2022, Jonathan Cameron wrote: > On Thu, 29 Sep 2022 18:51:32 +0100 > Lee Jones <lee@kernel.org> wrote: > > > On Thu, 29 Sep 2022, Rob Herring wrote: > > > > > On Wed, Sep 28, 2022 at 10:23:42AM +0100, Lee Jones wrote: > > > > On Mon, 26 Sep 2022, Rob Herring wrote: > > > > > > > > > On Mon, Sep 26, 2022 at 2:46 AM Lee Jones <lee@kernel.org> wrote: > > > > > > > > > > > > On Sat, 24 Sep 2022, Jonathan Cameron wrote: > > > > > > > > > > > > > On Fri, 23 Sep 2022 10:51:24 +0800 > > > > > > > ChiaEn Wu <peterwu.pub@gmail.com> wrote: > > > > > > > > > > > > > > > From: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > > > > > > > > > MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger > > > > > > > > with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight > > > > > > > > driver, display bias voltage supply, one general purpose LDO, and the > > > > > > > > USB Type-C & PD controller complies with the latest USB Type-C and PD > > > > > > > > standards. > > > > > > > > > > > > > > > > Add support for the MT6370 ADC driver for system monitoring, including > > > > > > > > charger current, voltage, and temperature. > > > > > > > > > > > > > > > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > > > > > > > > Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> > > > > > > > > Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> > > > > > > > > Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> > > > > > > > > > > > > > > This will have to either wait for next cycle, or go through mfd because > > > > > > > of the dt-bindings include which is in the mfd tree. > > > > > > > > > > > > > > Please make those dependencies clear in new versions. > > > > > > > > > > > > If the bindings come together in -next, then subsequently in Mainline, > > > > > > it shouldn't really matter. > > > > > > > > > > Except that the bindings haven't come together and at this point may > > > > > not for 6.1. linux-next has been warning for weeks because the child > > > > > device schemas haven't been applied. I've said it before, all the > > > > > schemas for MFD devices need to be applied together. Or at least the > > > > > MFD schema needs to get applied last. > > > > > > > > > > Furthermore, subsequent versions of this don't get tested and we end > > > > > up with more warnings[1]. > > > > > > > > > > It's only your IIO tree that the DT > > > > > > tooling with complain about, right? > > > > > > > > > > And the MFD tree... > > > > > > > > > > Please apply the LED bindings (patches 1 and 2) so we can get the > > > > > existing warnings fixed and address any new warnings. > > > > > > > > Who usually applies LED bindings? Looks as though they're good to go. > > > > > > Pavel. The issue would be I don't know if the driver side is ready and > > > those usually go together. Other than my complaining here, how's he > > > supposed to know that the bindings at least need to be applied? > > > > > > Again, the process here is not working. I've said before, all the > > > bindings for an MFD need to go via 1 tree. You obviously don't agree, so > > > propose something. The current process of no coordination doesn't work. > > > > The solution would be for someone to create succinct immutable branches, like > > I do for real code. If someone would be happy to do that, I'd be more than > > happy to pull from them. > > > > I go to the effort of creating them to prevent actual build breakages, > > however doing so to keep a documentation helper script happy is a step > > too far for me personally, sorry. > > > > In this case the bindings include is included from the driver - not just the > binding. Obviously there are dances to get around that by using the values > and replacing in following cycle, but that's not the case here! The paragraphs above to not pertain to the use of shared include files. Obviously that would be a good case for the use of IBs.
From: ChiaEn Wu <chiaen_wu@richtek.com> This patch series add MediaTek MT6370 PMIC support and add a index macro to <linear_range.h>. The MT6370 is a highly-integrated smart power management IC, which includes a single cell Li-Ion/Li-Polymer switching battery charger, a USB Type-C & Power Delivery (PD) controller, dual Flash LED current sources, a RGB LED driver, a backlight WLED driver, a display bias driver and a general LDO for portable devices. First, in this series of patches, - 'dt-binding: mfd' and 'mfd driver' have been applied by Lee in the v7. https://lore.kernel.org/all/YvJdpq0MWNPQZw5c@google.com/ https://lore.kernel.org/all/YvJdxEpC2cB58Bq9@google.com/ - 'tcpci driver' has been applied by Greg in the v8. https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=c2a8ea5997fdfeb43eda259d5533234c3cae05d7 - 'dt-binding: backlight' and 'backlight driver' have been applied by Lee in v9. https://lore.kernel.org/all/YxYSDSlnOELL2mPF@google.com/ https://lore.kernel.org/all/YxYS7%2FdZI69lMXeh@google.com/ - 'dt-binding: charger', 'charger driver' and 'linear_range.h' patch have been applied by Sebastian in v11. https://lore.kernel.org/all/20220920160857.6qfi66gtmgwesq7g@mercury.elektranox.org/ https://lore.kernel.org/all/20220920161218.dkkfvfomrruebahi@mercury.elektranox.org/ https://lore.kernel.org/all/20220920161238.dswtmyon462324dm@mercury.elektranox.org/ Second, the LED RGB driver is based on Andy's patch which moves led_init_default_state_get() to the global header. https://lore.kernel.org/all/20220805154907.32263-3-andriy.shevchenko@linux.intel.com/ In addition, we made some changes for MT6370 flash driver (see v12 section of the change log below). Thank you, ChiaEn Wu --- Change in v12: - In Patch 5/5 (MT6370 Flash): - Rename all 'led_flash_setting *s' --> 'led_flash_setting *setting' - Rename 'max_uA' --> 'max_ua' in mt6370_init_flash_properties() Change in v11: - In Patch 1/8 (dt-bindings: MT6370 Charger) - Add more detailed description of irqs. - Adujust the order of irqs Change in v10: - In Patch 6/8 (MT6370 Charger): - Add a feature (disable input current limit) in 'mt6370_chg_init_setting()' - Add the header file <linux/devm-helpers.h> for using 'devm_work_autocancel()' and 'devm_delayed_work_autocancel() - Rename 'pwr_rdy' to 'opposite_pwr_rdy' in 'mt6370_chg_pwr_rdy_check()' - Rename enum elements ('MT6370_ATTACH_STAT_ATTACH_BC12_NOT_DONE' --> 'MT6370_ATTACH_STAT_ATTACH_WAIT_FOR_BC12') - Revise the assignment value of 'val.intval' in 'mt6370_chg_pwr_rdy_check()' to make the code easy to read. - Revise the initialization of bc12_work (INIT_WORK() --> using devm_work_autocancel()) and mivr_dwork (INIT_DELAYED_WORK + devm_add_action_or_reset() --> devm_delayed_work_autocancel()) - In Patch 8/8 (MT6370 LED Flashlight): - Add the revert code when '__mt6370_flash_brightness_set()' return failed. - Revise type of 'led_no' (u32 -> u8) - Revise type of 'default_state' (u32 -> enum led_default_state) - Revise the return value of '_mt6370_flash_brightness_set()' - Remove the useless function 'mt6370_init_common_properties()' - Use 'led_init_default_state_get()' to init 'led->default_state' Changes in v9: - In Patch 05/10: - Revise LINEAR_RANGE() and LINEAR_RANGE_IDX() - In Patch 07/10: - Fix wrong 'F_IINLMTSEL' setting in 'mt6370_chg_init_setting()' - Revise the usage of LINEAR_RANGE_IDX() - In Patch 09/10: - Revise the format of the comments. - In Patch 10/10: - Revise the format of the comments. Changes in v8: - In Patch 06/12: - Add linear_range_idx macro for declaring the linear_range struct simply. - In Patch 09/12: - Remove MT6370_CHG_LINEAR_RANGE() macro, and change to use LINEAR_RANGE_IDX() macro - In Patch 10/12: - Add include header file <linux/leds.h> - Remove useless 'enum mt6370_state' because of using 'enum led_default_state' - Revise the calculation of 'val' in 'mt6370_gen_breath_pattern()' - Replace the medthod of getting default-state by using led_init_default_state_get() - In Patch 11/12: - Add missing 'dependency config' in Kconfig - Revise all multi-line comments - In Patch 12/12: - Add missing header file <linux/property.h> - Remove useledd header file <linux/of_device.h> - Revise the comment of 'mt6370_check_vendor_info()' Changes in v7: - In Patch 05/13: - Add the second compatible string for 'mt6372' - Add 'mediatek,bled-exponential-mode-enable' property for enable the exponential mode of backlight brightness - Add validation for the maximum value of 'default-brightness' and 'max-brightness' - In Patch 07/13: - Move '#define MT6370_REG_MAXADDR' to the next line of '#define MT6370_REG_CHG_MASK1' - Rename 'MT6370_REG_ADDRLEN' to 'MT6370_MAX_ADDRLEN' - In Patch 08/13: - Revise 'devm_add_action_or_reset(dev, ...)' to one line - Revise 'return regmap_update_bits(...)' with using positive conditional - In Patch 09/13: - Add AICR(100mA ~ 350mA), ICHG(100mA ~ 800mA) macros - Remove 400mA AICR and 900mA ICHG macros - Revise using 'if-else' to 'switch-case' in mt6370_adc_read_scale() where the adc channel is ibus or ibat - In Patch 10/13: - Revise the method to enable/disable irq - Revise all 'if (ret < 0)' to 'if (ret)' after using mt6370_chg_field_set/get() - Revise all 'OTG' text again - In Patch 11/13: - Add the comment for the union of 'struct mt6370_led' - Revise the wrong description of 'Authors' - Revise some typos (e.g. led --> LED) - Revise 'if (!fwnode_property_read_string())' to 'ret = fwnode_property_read_string()' - Replace 'memcpy(...)' with 'put_unaligned_be24()' in mt6370_gen_breath_pattern() - Replace all 'LED_OFF' with 0 - Remove the redundant assignment in mt6370_mc_pattern_clear() - In Patch 12/13: - Fix the indentation. - For the well defined macro, the parenthesis is needed for input parameters. - Replace some dev_warn to dev_info in 'init_flash_properties'. - Add sentinel comment for the terminator entry of of_device_id. - Use priv->fled_torch_used directly. - Delete 0 in {}. - Use _uA instead of _UA in definition. - Refine the description. - Use usleep_range instead of udelay. - Rename config to LEDS_MT6370_FLASH. - Add missing ">" in copyright. - Change the Kconfig order - In Patch 13/13: - Add support 'exponential mode' property parsing - Add 'return dev_err_probe()' after 'if (IS_ERR(priv->enable_gpio))' - Add 'mt6372' compatible string - Revise Kconfig help text - Revise update()/get() for supporting 16384 steps (MT6372) - Revise all shift usages form using 'ffs() and fls()' to defining the _SHIFT macros. - Revise 'brightness ? 1 : 0' to '!!brightness' in gpiod_set_value() Changes in v6: - In Patch 03/13: - Add 'reg' property of led of multi-led to prevent checking error. - In Patch 08/13: - Convert tcpci as device resource managed with 'devm_add_action_or_reset' api. - Refine remvoe callback. - Refine the commit text from 'this commit add' to 'add'. - In Patch 09/13: - Using 'struct device *dev = &pdev->dev' in probe() - Revise the sixth parameter of regmap_read_poll_timeout() by Replacing '1000' with 'MILLI' - Revise the units of three macros - MT6370_AICR_400MA --> MT6370_AICR_400_mA - MT6370_ICHG_500MA --> MT6370_ICHG_500_mA - MT6370_ICHG_900MA --> MT6370_ICHG_900_mA - In patch 10/13: - Remove the varable (*psy_desc) of struct mt6370_priv - Remove the deprecated usb type (POWER_SUPPLY_TYPE_USB_CDP and POWER_SUPPLY_TYPE_USB_DCP) - Remove useless remove() - Revise all units from mini- to micro- - Revise get/set power_supply_prop (change to directly return get/set regmap_field) - Revise probe() and use devm_add_action_or_reset() for handling of the workqueue/delayed_work/mutex - Revise mt6370_chg_psy_desc - Add '.name = "mt6370-charger"' - Use 'static const' - In patch 11/13: - Remove the 'ko' from mt6370 led Kconfig description. - Add both authors for Alice and ChiYuan. - Use pdata to distinguish the code from mt6370/71 to mt6372. - Instead of 'state' define, use the 'state' enum. - Fix the typo for 'MT6372_PMW_DUTY'. - For pwm_duty define, replace with bit macro - 1. - Refine all the labels from 'out' to 'out_unlock'. - Use struct 'dev' variable and 'dev_err_probe' to optimize the LOC. - Revise for the array initialization from {0} to {}. - Move into rgb folder and rename file name to 'leds-mt6370-rgb'. - Refine the 'comma' usage in struct/enum. - In patch 12/13: - Use 'GENMASK' instead of 'BIT'. - Use dev_err_probe to decrease LOC. - Use 'dev' variable to make probe function more clean. - Refine the return of _mt6370_flash_brightness_set function. - Refine the descriptions. - Use mt6370_clamp() instead of clamp_align(). - Use device resource managed API for v4l2 flash_release. Changes in v5: - In patch 07/13: - Add the comma in the last REGMAP_IRQ_REG_LINE(), DEFINE_RES_IRQ_NAMED() and MFD_CELL_RES() - Add the prefix in the first parameter of all mfd_cell - Move enum and struct mt6370_info to mt6370.h - Remove struct device *dev in struct mt6370_info - Revise the description of Kconfig help text - Revise MODULE_DESCRIPTION() - In patch 08/13: - Add comma for the last index of mt6370_reg_init. - Use dev_err_probe to decrease LOC. - Use 'dev' variable to make probe function more clean. - Refine kconfig text. - Remove both 'else' in set_vbus callback. - Remove comma for of_device_id if the assigned member is only one. - In patch 09/13: - Replace using snprintf() with sysfs_emit() in mt6370_adc_read_label() - Remove macro ADC_CONV_TIME_US - Revise all variable ordering - Revise the description of Kconfig help text - Revise MODULE_DESCRIPTION() - In patch 10/13: - Replace unsigned int type of pwr_rdy with bool in mt6370_chg_set_online() - Remove redundant 'else' in mt6370_chg_field_get() - Revise 'if-else' in mt6370_chg_field_set() - Revise 'if' condition in mt6370_chg_enable_irq() - Revise all text 'otg' --> 'OTG' - Revise MT6370_MIVR_IBUS_TH_100_MA --> MT6370_MIVR_IBUS_TH_100_mA - Revise the description of Kconfig help text - In patch 12/13: - Refine the coding style. - Use "dev" instead of "&pdev->dev". - In patch 13/13: - Add missed <mod_devicetable.h> - Add struct device *dev in probe() to make code cleaning - Remove useless including header file <gpio/driver.h>, <of.h> - Remove useless variable uasage in mt6370_init_backlight_properties() - Remove redundant checking enable_gpio in mt6370_bl_update_status() - Remove redundant parentheses in mt6370_bl_get_brightness() - Revise the description of Kconfig help text - Revise the calculation of hys_th_steps Changes in v4: - In patch 02/13: - Add minItems of "io-channel-names" - Replace text "Mediatek" with "MediaTek" - In patch 06/13: - Roll back all "$ref: " to v2 patch style (using "/schemas/...") - In patch 07/13: - Replace text "Mediatek" with "MediaTek" in Kconfig - Replace "first break and then return" with "return directly" in "mt6370_check_vendor_info()" - Add module name related description in Kconfig helptext - Add Copyright in the source code - Add header file "mt6370.h" for all "#define IRQ" - Adjust Makefile order of MT6370 - Refine "bank_idx" and "bank_addr" in "mt6375_regmap_read()" / "mt6375_regmap_write()" - Refine redundant "else if" in "mt6370_regmap_read()" - In patch 08/13: - Replace text "Mediatek" with "MediaTek" in Kconfig - Replace "first ret=regulator_(dis/en)able and then return" with "return directly" in "mt6370_tcpc_set_vbus()" - Replace header file <linux/of.h> with <linux/mod_devicetable.h> - Add Copyright in the source code - Add module name related description in Kconfig helptext - Remove header file <linux/of.h> - Refine all probe error by using dev_err_probe() - In patch 09/13: - Replace text "Mediatek" with "MediaTek" - Replace all "first dev_err() and then return" with "return dev_err_probe()" - Add Copyright in the source code - Add module name related description in Kconfig - Add unit suffix of macro "ADC_CONV_POLLING_TIME" - Add new macro "ADC_CONV_TIME_MS" - Adjust the position of include file <mediatek,mt6370_adc.h> - Adjust the postions between <linux/module.h> and <linux/mod_devicetable.h> - Fix some incorrect characters - In patch 10/13: - Replace text "Mediatek" with "MediaTek" in Kconfig and MODULE_DESCRIPTION() - Replace "mt6370_chg_val_to_reg" and "mt6370_chg_reg_to_val" with "linear_range" API - Replace "first break and then return" with "return directly" in all cases of get/set power_supply_property - Replace all "first dev_err() and then return" with "return dev_err_probe()" - Replace all "return IS_ERR(priv->rdev) ? PTR_ERR(priv->rdev) : 0" with "PTR_ERR_OR_ZERO()" - Replace "priv->dev->of_node" with "dev_of_node()" - Add Copyright in the source code - Add module name related description in Kconfig helptext - Add proper unit of "MT6370_MIVR_IBUS_TH" - Add error check in "mt6370_chg_get_status" - Remove including <mediatek,mt6370_adc.h> header file - Remove redundant comma of every enum terminator line - Remove unwanted blank lines - Remove the useless label (toggle_cfo_exit:) - Remove using atomic - Remove using of_match_ptr() - Fix some incorrect characters - Fix updating wrong bits when using ena_gpiod of OTG regulator - Adjust the probe order in probe() - In patch 11/13: - Replace text "Mediatek" with "MediaTek" in Kconfig - Replace text "const" with "constant" in Kconfig - Add Copyright in the source code - In patch 12/13: - Replace text "Mediatek" with "MediaTek" in Kconfig - Add Copyright in the source code - In patch 13/13: - Replace text "Mediatek" with "MediaTek" in Kconfig - Add Copyright in the source code - Revise the comment of "PWM HYS STEPS" Changes in v3: - Remove ADC ABI file, which is added in v2 Patch 7 - In patch 02/14: - Add items and remove maxItems of io-channels - Add io-channel-names and describe each item - Add "unevaluatedProperties: false" in "usb-otg-vbus-regulator" - Rename "enable-gpio" to "enable-gpios" in "usb-otg-vbus-regulator" - In patch 03/14: - Use leds-class-multicolor.yaml instead of common.yaml. - Split multi-led and led node. - Add subdevice "led" in "multi-led". - In patch 04/14: - Remove the description of enum. - In patch 05/14: - Rename "mediatek,bled-pwm-hys-input-threshold-steps" to "mediatek,bled-pwm-hys-input-th-steps" - Refine "bled-pwm-hys-input-th-steps", "bled-ovp-microvolt", "bled-ocp-microamp" enum values - In patch 06/14: - Use " in entire patchset - Refine ADC description - Rename "enable-gpio" to "enable-gpios" in "regualtor" - In patch 07/14: - Refine Kconfig help text - Refine error message of unknown vendor ID in mt6370_check_vendor_info() - Refine return value handling of mt6370_regmap_read() - Refine all probe error by using dev_err_probe() - Refine "bank_idx" and "bank_addr" in mt6370_regmap_read() and mt6370_regmap_write() - Add "#define VENID*" and drop the comments in mt6370_check_vendor_info() - Drop "MFD" in MODULE_DESCRIPTION() - In patch 09/14: - Refine Kconfig help text - In patch 10/14: - Refine Kconfig help text - Refine all channel value in read_scale() a. current: uA --> mA b. voltage: uV --> mV c. temperature: degrees Celsius --> milli degrees Celsius - Add "default:" condition of switch statement in read_scale() and read_raw() - Add error message for reading ADC register failed - Add the comment for adc_lock - Add <linux/mod_devicetable.h> header file for struct of_device_id - Replace "adc" text with "ADC" in all of the error messages - In patch 12/14: - Refine the grammer of the Kconfig. - Change reg mode to the const current mode. - In patch 14/14: - Refine bool properties parsing (pwm-enable, ovp-shutdown, ocp-shutdown) in DT parsing function - Refine u32 and u8 properties parsing (pwm-hys-input-th-steps, ovp-microvolt, ocp-microamp), from using register value to using actual value - Refine error string of "channle-use" parsing failed - Refine Kconfig help text Changes in v2: - In patch 01/15: - Add "unevaluatedProperties: false". - Delete "DT bindings". - Refine the description to fit in 80 columns. - Skip the connector description. - In patch 02/15: - Refine items description of interrupt-name - Rename "usb-otg-vbus" to "usb-otg-vbus-regulator" - Add constraint properties for ADC - In patch 03/15: - Skip not useful description of "^(multi-)?led@[0-3]$" and reg. - Due to the dependency, remove the mention of mfd document directory. - Delete Soft-start property. In design aspect, we think soft-restart should always be enabled, our new chip has deleted the related setting register , also, we don’t allow user adjust this parameter in this chip. - Refine the commit message. - In patch 04/15: - Skip not useful description of "^led@[0-1]$" and reg. - Add apace after '#'. - Refine the commit message. - In patch 05/15: - Remove "binding documentation" in subject title - Refine description of mt6370 backlight binding document - Refine properties name(bled-pwm-hys-input-bit, bled-ovp-microvolt, bled-ocp-microamp) and their description - In patch 06/15: - Refine ADC and Regulator descriptions - Refine include header usage in example - Refine node name to generic node name("pmic@34") - Refine led example indentation - Refine license of mediatek,mt6370_adc.h - Rename the dts example from IRQ define to number. - Remove mediatek,mt6370.h - In patch 07/15: - Add ABI documentation for mt6370 non-standard ADC sysfs interfaces. - In patch 08/15: - Add all IRQ define into mt6370.c. - Refine include header usage - In patch 09/15: - No changes. - In patch 10/15: - Use 'gpiod_get_from_of_node' to replace 'fwnode_gpiod_get_index'. - In patch 11/15: - Refine Kconfig mt6370 help text - Refine mask&shift to FIELD_PREP() - Refine mutex lock name ("lock" -> "adc_lock") - Refine mt6370_adc_read_scale() - Refine mt6370_adc_read_offset() - Refine mt6370_channel_labels[] by using enum to index chan spec - Refine MT6370_ADC_CHAN() - Refine indio_dev->name - Remove useless include header files - In patch 12/15: - Refine mt6370_chg_otg_rdesc.of_match ("mt6370,otg-vbus" -> "usb-otg-vbus-regulator") to match DT binding - In patch 13/15: - Refine Kconfig description. - Remove include "linux/of.h" and use "linux/mod_devicetable.h". - Place a comma for the last element of the const unsigned int array. - Add a comment line for the mutex 'lock'. - In probe function, use 'dev_err_probe' in some judgement to reduce the LOC. - Refine include header usage. BIT/GENMASK -> linux/bits.h FIELD_GET -> linux/bitfield.h - In patch 14/15: - Add blank line. - Replace container_of() with to_mt6370_led() . - Refine description of ramping. - Refine the mt6370_init_common_properties function. - Refine the probe return. - In patch 15/15: - Refine MT6370 help text in Kconfig - Refine DT Parse function - Remove useless enum - Add comment for 6372 backward compatible in bl_update_status() and check_vendor_info() - Using dev_err_probe(); insteads dev_err()&return; in the probe() Alice Chen (2): dt-bindings: leds: Add MediaTek MT6370 flashlight leds: flash: mt6370: Add MediaTek MT6370 flashlight support ChiYuan Huang (2): dt-bindings: leds: mt6370: Add MediaTek MT6370 current sink type LED indicator leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support ChiaEn Wu (1): iio: adc: mt6370: Add MediaTek MT6370 support .../bindings/leds/mediatek,mt6370-flashlight.yaml | 41 + .../bindings/leds/mediatek,mt6370-indicator.yaml | 81 ++ drivers/iio/adc/Kconfig | 12 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/mt6370-adc.c | 305 ++++++ drivers/leds/flash/Kconfig | 14 + drivers/leds/flash/Makefile | 1 + drivers/leds/flash/leds-mt6370-flash.c | 631 ++++++++++++ drivers/leds/rgb/Kconfig | 13 + drivers/leds/rgb/Makefile | 1 + drivers/leds/rgb/leds-mt6370-rgb.c | 1010 ++++++++++++++++++++ 11 files changed, 2110 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/mediatek,mt6370-flashlight.yaml create mode 100644 Documentation/devicetree/bindings/leds/mediatek,mt6370-indicator.yaml create mode 100644 drivers/iio/adc/mt6370-adc.c create mode 100644 drivers/leds/flash/leds-mt6370-flash.c create mode 100644 drivers/leds/rgb/leds-mt6370-rgb.c