Message ID | 1453896059-44589-2-git-send-email-blogic@openwrt.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
On Wed, Jan 27, 2016 at 01:00:59PM +0100, John Crispin wrote: > + /* Constrain board-specific capabilities according to what > + * this driver and the chip itself can actually do. > + */ > + c = rdev->constraints; > + c->valid_modes_mask |= REGULATOR_MODE_NORMAL | > + REGULATOR_MODE_STANDBY; > + c->valid_ops_mask |= REGULATOR_CHANGE_MODE; No, drivers should *never* enable things that weren't explictly enabled by the machine constraints. This misses the whole point of having constraints. They are there so that the system integrator can enable the functionality that is safe on a given board. The comment is also inaccurate, it claims it's imposing constraints but in fact it's adding additional permissions.
Hi Mark, On Wed, 2016-01-27 at 14:41 +0000, Mark Brown wrote: > On Wed, Jan 27, 2016 at 01:00:59PM +0100, John Crispin wrote: > > > + /* Constrain board-specific capabilities according to what > > + * this driver and the chip itself can actually do. > > + */ > > + c = rdev->constraints; > > + c->valid_modes_mask |= REGULATOR_MODE_NORMAL | > > + REGULATOR_MODE_STANDBY; > > + c->valid_ops_mask |= REGULATOR_CHANGE_MODE; > > No, drivers should *never* enable things that weren't explictly enabled > by the machine constraints. This misses the whole point of having > constraints. They are there so that the system integrator can enable > the functionality that is safe on a given board. Okay..the constrains should be define on device tree. But which optional properties was suitable to fill on device tree if consumers want to call regulator_set_mode directly ? I have check the of_regulator.c and not found the suitable property name which can set valid_modes_mask & valid_ops_mask. Thanks, Henry > > The comment is also inaccurate, it claims it's imposing constraints but > in fact it's adding additional permissions. > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek
On Thu, Jan 28, 2016 at 03:16:41PM +0800, Henry Chen wrote: > On Wed, 2016-01-27 at 14:41 +0000, Mark Brown wrote: > > No, drivers should *never* enable things that weren't explictly enabled > > by the machine constraints. This misses the whole point of having > > constraints. They are there so that the system integrator can enable > > the functionality that is safe on a given board. > Okay..the constrains should be define on device tree. > But which optional properties was suitable to fill on device tree if consumers want to call > regulator_set_mode directly ? > I have check the of_regulator.c and not found the suitable property name which can set valid_modes_mask & valid_ops_mask. If you need to change the mode at runtime you will need to develop a binding for that, there isn't one at present.
On 27/01/2016 15:41, Mark Brown wrote: > On Wed, Jan 27, 2016 at 01:00:59PM +0100, John Crispin wrote: > >> + /* Constrain board-specific capabilities according to what >> + * this driver and the chip itself can actually do. >> + */ >> + c = rdev->constraints; >> + c->valid_modes_mask |= REGULATOR_MODE_NORMAL | >> + REGULATOR_MODE_STANDBY; >> + c->valid_ops_mask |= REGULATOR_CHANGE_MODE; > > No, drivers should *never* enable things that weren't explictly enabled > by the machine constraints. This misses the whole point of having > constraints. They are there so that the system integrator can enable > the functionality that is safe on a given board. > > The comment is also inaccurate, it claims it's imposing constraints but > in fact it's adding additional permissions. > Hi Mark would the following two bindings be ok ? I would create patches to add them. * regulator-allow-mode; or regulator-allow-change-mode; * regulator-modes = <REGULATOR_MODE_NORMAL REGULATOR_MODE_STANDBY>; John
On Thu, Jan 28, 2016 at 07:13:48PM +0100, John Crispin wrote: > would the following two bindings be ok ? I would create patches to add them. > * regulator-allow-mode; or regulator-allow-change-mode; This seems redundant, if we have a list of valid modes presumably they can be used - same idea as with voltage setting. > * regulator-modes = <REGULATOR_MODE_NORMAL REGULATOR_MODE_STANDBY>; I'm not convinced this binding makes sense, how would a user of the API (currently there are none in tree) know what the modes mean? It's a bit different when the user is supplying configuration for a specific regulator but this needs to be something that can be used by consumers. What are you actually trying to do with this?
On Fri, 2016-01-29 at 00:13 +0100, Mark Brown wrote: > On Thu, Jan 28, 2016 at 07:13:48PM +0100, John Crispin wrote: > > > would the following two bindings be ok ? I would create patches to add them. > > > * regulator-allow-mode; or regulator-allow-change-mode; > > This seems redundant, if we have a list of valid modes presumably they > can be used - same idea as with voltage setting. > > > * regulator-modes = <REGULATOR_MODE_NORMAL REGULATOR_MODE_STANDBY>; > > I'm not convinced this binding makes sense, how would a user of the API > (currently there are none in tree) know what the modes mean? It's a bit > different when the user is supplying configuration for a specific > regulator but this needs to be something that can be used by consumers. > > What are you actually trying to do with this? Hi Mark, Per documentation in regulator/consumer.h, I think user should be able to know the behavior of each mode(fast, normal, idle, standby). In this patch, we want to support both normal/standby modes for mt6323 regulators due to mt6323 regulators support low power mode which provides better power efficiency for standby case. We expect user of mt6323 regulators could dynamically change power mode by regulator_set_mode(). -EINVAL is returned if the given mode is not supported. The regulator_set_mode() API looks very straightforward and possible modes are already defined in consumer.h. It looks like we don't have to list possible modes for mt6323 additionally in binding document. MengHui
On Fri, Jan 29, 2016 at 05:52:14PM +0800, menghui lin wrote: > On Fri, 2016-01-29 at 00:13 +0100, Mark Brown wrote: > > I'm not convinced this binding makes sense, how would a user of the API > > (currently there are none in tree) know what the modes mean? It's a bit > > different when the user is supplying configuration for a specific > > regulator but this needs to be something that can be used by consumers. > > What are you actually trying to do with this? > In this patch, we want to support both normal/standby modes for mt6323 > regulators due to mt6323 regulators support low power mode which > provides better power efficiency for standby case. > We expect user of mt6323 regulators could dynamically change power mode > by regulator_set_mode(). -EINVAL is returned if the given mode is not > supported. > The regulator_set_mode() API looks very straightforward and possible > modes are already defined in consumer.h. It looks like we don't have to > list possible modes for mt6323 additionally in binding document. None of this is answering my question - I know what the current API is, describing it doesn't tell me about actual users or how they are able to sensibly use the interface. Bear in mind that the definitions of the various modes are all relative and what one device thinks is high usage may be low usage for another device.
On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote: > On Fri, Jan 29, 2016 at 05:52:14PM +0800, menghui lin wrote: > > On Fri, 2016-01-29 at 00:13 +0100, Mark Brown wrote: > > > > I'm not convinced this binding makes sense, how would a user of the API > > > (currently there are none in tree) know what the modes mean? It's a bit > > > different when the user is supplying configuration for a specific > > > regulator but this needs to be something that can be used by consumers. > > > > What are you actually trying to do with this? > > > In this patch, we want to support both normal/standby modes for mt6323 > > regulators due to mt6323 regulators support low power mode which > > provides better power efficiency for standby case. > > > We expect user of mt6323 regulators could dynamically change power mode > > by regulator_set_mode(). -EINVAL is returned if the given mode is not > > supported. > > > The regulator_set_mode() API looks very straightforward and possible > > modes are already defined in consumer.h. It looks like we don't have to > > list possible modes for mt6323 additionally in binding document. > > None of this is answering my question - I know what the current API is, > describing it doesn't tell me about actual users or how they are able to > sensibly use the interface. Bear in mind that the definitions of the > various modes are all relative and what one device thinks is high usage > may be low usage for another device. Assuming valid_modes_mask and initial_mode are specified, a possible way to modify regulator_set_mode() is to allow mode change only if the regulator is controlled exclusively by a certain consumer or the requested mode provides stronger power capability than current mode. Here I assume that power capability fast > normal > idle > standby.
On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote: > On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote: > > None of this is answering my question - I know what the current API is, > > describing it doesn't tell me about actual users or how they are able to > > sensibly use the interface. Bear in mind that the definitions of the > > various modes are all relative and what one device thinks is high usage > > may be low usage for another device. > Assuming valid_modes_mask and initial_mode are specified, a possible > way to modify regulator_set_mode() is to allow mode change only if the > regulator is controlled exclusively by a certain consumer or the > requested mode provides stronger power capability than current mode. > Here I assume that power capability fast > normal > idle > standby. How does the driver know if it needs to change the mode (ie, how can it tell if the current mode is inadequate) and surely if we can only change in one direction this isn't terribly useful?
On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote: > On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote: > > None of this is answering my question - I know what the current API is, > > describing it doesn't tell me about actual users or how they are able to > > sensibly use the interface. Bear in mind that the definitions of the > > various modes are all relative and what one device thinks is high usage > > may be low usage for another device. > Assuming valid_modes_mask and initial_mode are specified, a possible > way to modify regulator_set_mode() is to allow mode change only if the > regulator is controlled exclusively by a certain consumer or the > requested mode provides stronger power capability than current mode. > Here I assume that power capability fast > normal > idle > standby. ...and I also note that the above *still* doesn't answer my questions above.
On Tue, 2016-02-02 at 19:38 +0000, Mark Brown wrote: > On Fri, Jan 29, 2016 at 08:11:19PM +0800, menghui lin wrote: > > On Fri, 2016-01-29 at 12:27 +0100, Mark Brown wrote: > > > > None of this is answering my question - I know what the current API is, > > > describing it doesn't tell me about actual users or how they are able to > > > sensibly use the interface. Bear in mind that the definitions of the > > > various modes are all relative and what one device thinks is high usage > > > may be low usage for another device. > > > Assuming valid_modes_mask and initial_mode are specified, a possible > > way to modify regulator_set_mode() is to allow mode change only if the > > regulator is controlled exclusively by a certain consumer or the > > requested mode provides stronger power capability than current mode. > > Here I assume that power capability fast > normal > idle > standby. > > How does the driver know if it needs to change the mode (ie, how can it > tell if the current mode is inadequate) and surely if we can only change > in one direction this isn't terribly useful? Hi Mark, I think the datasheet of buck/ldo could provide information about power capability of each mode. The driver should adjust regulator mode per its device's power requirement. Below are some actual scenarios we have now. I provide them for your reference. If unfortunately below cases are not the actual users you ask, please kindly let me know more about your suggestion. Thank you. :) case 1: We have a USB typeC micro-controller, which has two modes - standby and normal. It requires 1.8V and 3.3V to operate (both powers are always on). The device stays in standby mode when there is no cable in. When cable in, we got an interrupt and change device into normal mode. The standby mode power consumption is quite small, so we would like the change mode of regulator into STANDBY to save more power. And we change into NORMAL when we receive cable-in interrupt. case 2: About buck regulator for CPU, it usually provides PWM mode, PWM/PFM Auto mode, PFM mode. I think it could map to FAST, NORMAL, IDLE mode respectively. Most of time we would use just normal mode. However, we would change regulator into PWM mode time to time to test buck output performance on the tested board.
On Wed, Feb 03, 2016 at 01:39:02PM +0800, menghui lin wrote: > On Tue, 2016-02-02 at 19:38 +0000, Mark Brown wrote: > > How does the driver know if it needs to change the mode (ie, how can it > > tell if the current mode is inadequate) and surely if we can only change > > in one direction this isn't terribly useful? > I think the datasheet of buck/ldo could provide information about power > capability of each mode. The driver should adjust regulator mode per its > device's power requirement. That's of no help for a consumer driver which doesn't know what regulator is supplying it. > case 1: > We have a USB typeC micro-controller, which has two modes - standby and > normal. It requires 1.8V and 3.3V to operate (both powers are always > on). The device stays in standby mode when there is no cable in. When > cable in, we got an interrupt and change device into normal mode. > The standby mode power consumption is quite small, so we would like the > change mode of regulator into STANDBY to save more power. And we change > into NORMAL when we receive cable-in interrupt. This seems like something that we ought to be doing via runtime PM anyway which should be going through the suspend mode bindings, though that would need some plumbing in. > case 2: > About buck regulator for CPU, it usually provides PWM mode, PWM/PFM Auto > mode, PFM mode. I think it could map to FAST, NORMAL, IDLE mode > respectively. Most of time we would use just normal mode. However, we > would change regulator into PWM mode time to time to test buck output > performance on the tested board. That's a test use that doesn't seem a good fit for upstream at all.
On Wed, 2016-02-03 at 12:29 +0000, Mark Brown wrote: > On Wed, Feb 03, 2016 at 01:39:02PM +0800, menghui lin wrote: > > On Tue, 2016-02-02 at 19:38 +0000, Mark Brown wrote: > > > > How does the driver know if it needs to change the mode (ie, how can it > > > tell if the current mode is inadequate) and surely if we can only change > > > in one direction this isn't terribly useful? > > > I think the datasheet of buck/ldo could provide information about power > > capability of each mode. The driver should adjust regulator mode per its > > device's power requirement. > > That's of no help for a consumer driver which doesn't know what > regulator is supplying it. > > > case 1: > > > We have a USB typeC micro-controller, which has two modes - standby and > > normal. It requires 1.8V and 3.3V to operate (both powers are always > > on). The device stays in standby mode when there is no cable in. When > > cable in, we got an interrupt and change device into normal mode. > > > The standby mode power consumption is quite small, so we would like the > > change mode of regulator into STANDBY to save more power. And we change > > into NORMAL when we receive cable-in interrupt. > > This seems like something that we ought to be doing via runtime PM > anyway which should be going through the suspend mode bindings, though > that would need some plumbing in. > > > case 2: > > > About buck regulator for CPU, it usually provides PWM mode, PWM/PFM Auto > > mode, PFM mode. I think it could map to FAST, NORMAL, IDLE mode > > respectively. Most of time we would use just normal mode. However, we > > would change regulator into PWM mode time to time to test buck output > > performance on the tested board. > > That's a test use that doesn't seem a good fit for upstream at all. Hi Mark, Thanks for your response. It seems more work is required for dynamic mode switch. For MT6323 regulator patch, we would remove mode-switch related code for now to provide basic regulator support first.
Hi Chen, [auto build test ERROR on regulator/for-next] [also build test ERROR on v4.5-rc3 next-20160208] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/John-Crispin/regulator-Add-document-for-MT6323-regulator/20160127-200434 base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-next config: frv-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=frv All errors (new ones prefixed by >>): >> drivers/regulator/mt6323-regulator.c:15:40: fatal error: linux/mfd/mt6323/registers.h: No such file or directory #include <linux/mfd/mt6323/registers.h> ^ compilation terminated. vim +15 drivers/regulator/mt6323-regulator.c 9 10 #include <linux/module.h> 11 #include <linux/of.h> 12 #include <linux/platform_device.h> 13 #include <linux/regmap.h> 14 #include <linux/mfd/mt6397/core.h> > 15 #include <linux/mfd/mt6323/registers.h> 16 #include <linux/regulator/driver.h> 17 #include <linux/regulator/machine.h> 18 #include <linux/regulator/mt6323-regulator.h> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig index 8155e80..5e49568 100644 --- a/drivers/regulator/Kconfig +++ b/drivers/regulator/Kconfig @@ -462,6 +462,15 @@ config REGULATOR_MT6311 This driver supports the control of different power rails of device through regulator interface. +config REGULATOR_MT6323 + tristate "MediaTek MT6323 PMIC" + depends on MFD_MT6397 + help + Say y here to select this option to enable the power regulator of + MediaTek MT6323 PMIC. + This driver supports the control of different power rails of device + through regulator interface. + config REGULATOR_MT6397 tristate "MediaTek MT6397 PMIC" depends on MFD_MT6397 diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile index 980b194..8fb55640 100644 --- a/drivers/regulator/Makefile +++ b/drivers/regulator/Makefile @@ -61,6 +61,7 @@ obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o obj-$(CONFIG_REGULATOR_MC13XXX_CORE) += mc13xxx-regulator-core.o obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o +obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o diff --git a/drivers/regulator/mt6323-regulator.c b/drivers/regulator/mt6323-regulator.c new file mode 100644 index 0000000..998a7bb --- /dev/null +++ b/drivers/regulator/mt6323-regulator.c @@ -0,0 +1,441 @@ +/* + * Copyright (c) 2016 MediaTek Inc. + * Author: Chen Zhong <chen.zhong@mediatek.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/module.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/regmap.h> +#include <linux/mfd/mt6397/core.h> +#include <linux/mfd/mt6323/registers.h> +#include <linux/regulator/driver.h> +#include <linux/regulator/machine.h> +#include <linux/regulator/mt6323-regulator.h> +#include <linux/regulator/of_regulator.h> + +#define MT6323_LDO_MODE_NORMAL 0 +#define MT6323_LDO_MODE_LP 1 + +/* + * MT6323 regulators' information + * + * @desc: standard fields of regulator description. + * @qi: Mask for query enable signal status of regulators + * @vselon_reg: Register sections for hardware control mode of bucks + * @vselctrl_reg: Register for controlling the buck control mode. + * @vselctrl_mask: Mask for query buck's voltage control mode. + */ +struct mt6323_regulator_info { + struct regulator_desc desc; + u32 qi; + u32 vselon_reg; + u32 vselctrl_reg; + u32 vselctrl_mask; + u32 modeset_reg; + u32 modeset_mask; +}; + +#define MT6323_BUCK(match, vreg, min, max, step, volt_ranges, enreg, \ + vosel, vosel_mask, voselon, vosel_ctrl) \ +[MT6323_ID_##vreg] = { \ + .desc = { \ + .name = #vreg, \ + .of_match = of_match_ptr(match), \ + .ops = &mt6323_volt_range_ops, \ + .type = REGULATOR_VOLTAGE, \ + .id = MT6323_ID_##vreg, \ + .owner = THIS_MODULE, \ + .n_voltages = (max - min)/step + 1, \ + .linear_ranges = volt_ranges, \ + .n_linear_ranges = ARRAY_SIZE(volt_ranges), \ + .vsel_reg = vosel, \ + .vsel_mask = vosel_mask, \ + .enable_reg = enreg, \ + .enable_mask = BIT(0), \ + }, \ + .qi = BIT(13), \ + .vselon_reg = voselon, \ + .vselctrl_reg = vosel_ctrl, \ + .vselctrl_mask = BIT(1), \ +} + +#define MT6323_LDO(match, vreg, ldo_volt_table, enreg, enbit, vosel, \ + vosel_mask, _modeset_reg, _modeset_mask) \ +[MT6323_ID_##vreg] = { \ + .desc = { \ + .name = #vreg, \ + .of_match = of_match_ptr(match), \ + .ops = &mt6323_volt_table_ops, \ + .type = REGULATOR_VOLTAGE, \ + .id = MT6323_ID_##vreg, \ + .owner = THIS_MODULE, \ + .n_voltages = ARRAY_SIZE(ldo_volt_table), \ + .volt_table = ldo_volt_table, \ + .vsel_reg = vosel, \ + .vsel_mask = vosel_mask, \ + .enable_reg = enreg, \ + .enable_mask = BIT(enbit), \ + }, \ + .qi = BIT(15), \ + .modeset_reg = _modeset_reg, \ + .modeset_mask = _modeset_mask, \ +} + +#define MT6323_REG_FIXED(match, vreg, enreg, enbit, volt, \ + _modeset_reg, _modeset_mask) \ +[MT6323_ID_##vreg] = { \ + .desc = { \ + .name = #vreg, \ + .of_match = of_match_ptr(match), \ + .ops = &mt6323_volt_fixed_ops, \ + .type = REGULATOR_VOLTAGE, \ + .id = MT6323_ID_##vreg, \ + .owner = THIS_MODULE, \ + .n_voltages = 1, \ + .enable_reg = enreg, \ + .enable_mask = BIT(enbit), \ + .min_uV = volt, \ + }, \ + .qi = BIT(15), \ + .modeset_reg = _modeset_reg, \ + .modeset_mask = _modeset_mask, \ +} + +static const struct regulator_linear_range buck_volt_range1[] = { + REGULATOR_LINEAR_RANGE(700000, 0, 0x7f, 6250), +}; + +static const struct regulator_linear_range buck_volt_range2[] = { + REGULATOR_LINEAR_RANGE(1400000, 0, 0x7f, 12500), +}; + +static const struct regulator_linear_range buck_volt_range3[] = { + REGULATOR_LINEAR_RANGE(500000, 0, 0x3f, 50000), +}; + +static const u32 ldo_volt_table1[] = { + 3300000, 3400000, 3500000, 3600000, +}; + +static const u32 ldo_volt_table2[] = { + 1500000, 1800000, 2500000, 2800000, +}; + +static const u32 ldo_volt_table3[] = { + 1800000, 3300000, +}; + +static const u32 ldo_volt_table4[] = { + 3000000, 3300000, +}; + +static const u32 ldo_volt_table5[] = { + 1200000, 1300000, 1500000, 1800000, 2000000, 2800000, 3000000, 3300000, +}; + +static const u32 ldo_volt_table6[] = { + 1200000, 1300000, 1500000, 1800000, 2500000, 2800000, 3000000, 2000000, +}; + +static const u32 ldo_volt_table7[] = { + 1200000, 1300000, 1500000, 1800000, +}; + +static const u32 ldo_volt_table8[] = { + 1800000, 3000000, +}; + +static const u32 ldo_volt_table9[] = { + 1200000, 1350000, 1500000, 1800000, +}; + +static const u32 ldo_volt_table10[] = { + 1200000, 1300000, 1500000, 1800000, +}; + +static int mt6323_get_status(struct regulator_dev *rdev) +{ + int ret; + u32 regval; + struct mt6323_regulator_info *info = rdev_get_drvdata(rdev); + + ret = regmap_read(rdev->regmap, info->desc.enable_reg, ®val); + if (ret != 0) { + dev_err(&rdev->dev, "Failed to get enable reg: %d\n", ret); + return ret; + } + + return (regval & info->qi) ? REGULATOR_STATUS_ON : REGULATOR_STATUS_OFF; +} + +static int mt6323_ldo_set_mode(struct regulator_dev *rdev, unsigned int mode) +{ + int ret, val = 0; + struct mt6323_regulator_info *info = rdev_get_drvdata(rdev); + + if (!info->modeset_mask) { + dev_err(&rdev->dev, "regulator %s doesn't support set_mode\n", + info->desc.name); + return -EINVAL; + } + + switch (mode) { + case REGULATOR_MODE_STANDBY: + val = MT6323_LDO_MODE_LP; + break; + case REGULATOR_MODE_NORMAL: + val = MT6323_LDO_MODE_NORMAL; + break; + default: + return -EINVAL; + } + + val <<= ffs(info->modeset_mask) - 1; + + ret = regmap_update_bits(rdev->regmap, info->modeset_reg, + info->modeset_mask, val); + + return ret; +} + +static unsigned int mt6323_ldo_get_mode(struct regulator_dev *rdev) +{ + unsigned int val; + unsigned int mode; + int ret; + struct mt6323_regulator_info *info = rdev_get_drvdata(rdev); + + if (!info->modeset_mask) { + dev_err(&rdev->dev, "regulator %s doesn't support get_mode\n", + info->desc.name); + return -EINVAL; + } + + ret = regmap_read(rdev->regmap, info->modeset_reg, &val); + if (ret < 0) + return ret; + + val &= info->modeset_mask; + val >>= ffs(info->modeset_mask) - 1; + + if (val & 0x1) + mode = REGULATOR_MODE_STANDBY; + else + mode = REGULATOR_MODE_NORMAL; + + return mode; +} + +static struct regulator_ops mt6323_volt_range_ops = { + .list_voltage = regulator_list_voltage_linear_range, + .map_voltage = regulator_map_voltage_linear_range, + .set_voltage_sel = regulator_set_voltage_sel_regmap, + .get_voltage_sel = regulator_get_voltage_sel_regmap, + .set_voltage_time_sel = regulator_set_voltage_time_sel, + .enable = regulator_enable_regmap, + .disable = regulator_disable_regmap, + .is_enabled = regulator_is_enabled_regmap, + .get_status = mt6323_get_status, +}; + +static struct regulator_ops mt6323_volt_table_ops = { + .list_voltage = regulator_list_voltage_table, + .map_voltage = regulator_map_voltage_iterate, + .set_voltage_sel = regulator_set_voltage_sel_regmap, + .get_voltage_sel = regulator_get_voltage_sel_regmap, + .set_voltage_time_sel = regulator_set_voltage_time_sel, + .enable = regulator_enable_regmap, + .disable = regulator_disable_regmap, + .is_enabled = regulator_is_enabled_regmap, + .get_status = mt6323_get_status, + .set_mode = mt6323_ldo_set_mode, + .get_mode = mt6323_ldo_get_mode, +}; + +static struct regulator_ops mt6323_volt_fixed_ops = { + .list_voltage = regulator_list_voltage_linear, + .enable = regulator_enable_regmap, + .disable = regulator_disable_regmap, + .is_enabled = regulator_is_enabled_regmap, + .get_status = mt6323_get_status, + .set_mode = mt6323_ldo_set_mode, + .get_mode = mt6323_ldo_get_mode, +}; + +/* The array is indexed by id(MT6323_ID_XXX) */ +static struct mt6323_regulator_info mt6323_regulators[] = { + MT6323_BUCK("buck_vproc", VPROC, 700000, 1493750, 6250, + buck_volt_range1, MT6323_VPROC_CON7, MT6323_VPROC_CON9, 0x7f, + MT6323_VPROC_CON10, MT6323_VPROC_CON5), + MT6323_BUCK("buck_vsys", VSYS, 1400000, 2987500, 12500, + buck_volt_range2, MT6323_VSYS_CON7, MT6323_VSYS_CON9, 0x7f, + MT6323_VSYS_CON10, MT6323_VSYS_CON5), + MT6323_BUCK("buck_vpa", VPA, 500000, 3650000, 50000, + buck_volt_range3, MT6323_VPA_CON7, MT6323_VPA_CON9, + 0x3f, MT6323_VPA_CON10, MT6323_VPA_CON5), + MT6323_REG_FIXED("ldo_vtcxo", VTCXO, MT6323_ANALDO_CON1, 10, 2800000, + MT6323_ANALDO_CON1, 0x2), + MT6323_REG_FIXED("ldo_vcn28", VCN28, MT6323_ANALDO_CON19, 12, 2800000, + MT6323_ANALDO_CON20, 0x2), + MT6323_LDO("ldo_vcn33_bt", VCN33_BT, ldo_volt_table1, + MT6323_ANALDO_CON16, 7, MT6323_ANALDO_CON16, 0xC, + MT6323_ANALDO_CON21, 0x2), + MT6323_LDO("ldo_vcn33_wifi", VCN33_WIFI, ldo_volt_table1, + MT6323_ANALDO_CON17, 12, MT6323_ANALDO_CON16, 0xC, + MT6323_ANALDO_CON21, 0x2), + MT6323_REG_FIXED("ldo_va", VA, MT6323_ANALDO_CON2, 14, 2800000, + MT6323_ANALDO_CON2, 0x2), + MT6323_LDO("ldo_vcama", VCAMA, ldo_volt_table2, + MT6323_ANALDO_CON4, 15, MT6323_ANALDO_CON10, 0x60, -1, 0), + MT6323_REG_FIXED("ldo_vio28", VIO28, MT6323_DIGLDO_CON0, 14, 2800000, + MT6323_DIGLDO_CON0, 0x2), + MT6323_REG_FIXED("ldo_vusb", VUSB, MT6323_DIGLDO_CON2, 14, 3300000, + MT6323_DIGLDO_CON2, 0x2), + MT6323_LDO("ldo_vmc", VMC, ldo_volt_table3, + MT6323_DIGLDO_CON3, 12, MT6323_DIGLDO_CON24, 0x10, + MT6323_DIGLDO_CON3, 0x2), + MT6323_LDO("ldo_vmch", VMCH, ldo_volt_table4, + MT6323_DIGLDO_CON5, 14, MT6323_DIGLDO_CON26, 0x80, + MT6323_DIGLDO_CON5, 0x2), + MT6323_LDO("ldo_vemc3v3", VEMC3V3, ldo_volt_table4, + MT6323_DIGLDO_CON6, 14, MT6323_DIGLDO_CON27, 0x80, + MT6323_DIGLDO_CON6, 0x2), + MT6323_LDO("ldo_vgp1", VGP1, ldo_volt_table5, + MT6323_DIGLDO_CON7, 15, MT6323_DIGLDO_CON28, 0xE0, + MT6323_DIGLDO_CON7, 0x2), + MT6323_LDO("ldo_vgp2", VGP2, ldo_volt_table6, + MT6323_DIGLDO_CON8, 15, MT6323_DIGLDO_CON29, 0xE0, + MT6323_DIGLDO_CON8, 0x2), + MT6323_LDO("ldo_vgp3", VGP3, ldo_volt_table7, + MT6323_DIGLDO_CON9, 15, MT6323_DIGLDO_CON30, 0x60, + MT6323_DIGLDO_CON9, 0x2), + MT6323_REG_FIXED("ldo_vcn18", VCN18, MT6323_DIGLDO_CON11, 14, 1800000, + MT6323_DIGLDO_CON11, 0x2), + MT6323_LDO("ldo_vsim1", VSIM1, ldo_volt_table8, + MT6323_DIGLDO_CON13, 15, MT6323_DIGLDO_CON34, 0x20, + MT6323_DIGLDO_CON13, 0x2), + MT6323_LDO("ldo_vsim2", VSIM2, ldo_volt_table8, + MT6323_DIGLDO_CON14, 15, MT6323_DIGLDO_CON35, 0x20, + MT6323_DIGLDO_CON14, 0x2), + MT6323_REG_FIXED("ldo_vrtc", VRTC, MT6323_DIGLDO_CON15, 8, 2800000, + -1, 0), + MT6323_LDO("ldo_vcamaf", VCAMAF, ldo_volt_table5, + MT6323_DIGLDO_CON31, 15, MT6323_DIGLDO_CON32, 0xE0, + MT6323_DIGLDO_CON31, 0x2), + MT6323_LDO("ldo_vibr", VIBR, ldo_volt_table5, + MT6323_DIGLDO_CON39, 15, MT6323_DIGLDO_CON40, 0xE0, + MT6323_DIGLDO_CON39, 0x2), + MT6323_REG_FIXED("ldo_vrf18", VRF18, MT6323_DIGLDO_CON45, 15, 1825000, + MT6323_DIGLDO_CON45, 0x2), + MT6323_LDO("ldo_vm", VM, ldo_volt_table9, + MT6323_DIGLDO_CON47, 14, MT6323_DIGLDO_CON48, 0x30, + MT6323_DIGLDO_CON47, 0x2), + MT6323_REG_FIXED("ldo_vio18", VIO18, MT6323_DIGLDO_CON49, 14, 1800000, + MT6323_DIGLDO_CON49, 0x2), + MT6323_LDO("ldo_vcamd", VCAMD, ldo_volt_table10, + MT6323_DIGLDO_CON51, 14, MT6323_DIGLDO_CON52, 0x60, + MT6323_DIGLDO_CON51, 0x2), + MT6323_REG_FIXED("ldo_vcamio", VCAMIO, MT6323_DIGLDO_CON53, 14, 1800000, + MT6323_DIGLDO_CON53, 0x2), +}; + +static int mt6323_set_buck_vosel_reg(struct platform_device *pdev) +{ + struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent); + int i; + u32 regval; + + for (i = 0; i < MT6323_MAX_REGULATOR; i++) { + if (mt6323_regulators[i].vselctrl_reg) { + if (regmap_read(mt6323->regmap, + mt6323_regulators[i].vselctrl_reg, + ®val) < 0) { + dev_err(&pdev->dev, + "Failed to read buck ctrl\n"); + return -EIO; + } + + if (regval & mt6323_regulators[i].vselctrl_mask) { + mt6323_regulators[i].desc.vsel_reg = + mt6323_regulators[i].vselon_reg; + } + } + } + + return 0; +} + +static int mt6323_regulator_probe(struct platform_device *pdev) +{ + struct mt6397_chip *mt6323 = dev_get_drvdata(pdev->dev.parent); + struct regulator_config config = {}; + struct regulator_dev *rdev; + struct regulation_constraints *c; + int i; + u32 reg_value; + + /* Query buck controller to select activated voltage register part */ + if (mt6323_set_buck_vosel_reg(pdev)) + return -EIO; + + /* Read PMIC chip revision to update constraints and voltage table */ + if (regmap_read(mt6323->regmap, MT6323_CID, ®_value) < 0) { + dev_err(&pdev->dev, "Failed to read Chip ID\n"); + return -EIO; + } + dev_info(&pdev->dev, "Chip ID = 0x%x\n", reg_value); + + for (i = 0; i < MT6323_MAX_REGULATOR; i++) { + config.dev = &pdev->dev; + config.driver_data = &mt6323_regulators[i]; + config.regmap = mt6323->regmap; + rdev = devm_regulator_register(&pdev->dev, + &mt6323_regulators[i].desc, &config); + if (IS_ERR(rdev)) { + dev_err(&pdev->dev, "failed to register %s\n", + mt6323_regulators[i].desc.name); + return PTR_ERR(rdev); + } + + /* Constrain board-specific capabilities according to what + * this driver and the chip itself can actually do. + */ + c = rdev->constraints; + c->valid_modes_mask |= REGULATOR_MODE_NORMAL | + REGULATOR_MODE_STANDBY; + c->valid_ops_mask |= REGULATOR_CHANGE_MODE; + } + return 0; +} + +static const struct platform_device_id mt6323_platform_ids[] = { + {"mt6323-regulator", 0}, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(platform, mt6323_platform_ids); + +static const struct of_device_id mt6323_of_match[] = { + { .compatible = "mediatek,mt6323-regulator", }, + { /* sentinel */ }, +}; +MODULE_DEVICE_TABLE(of, mt6323_of_match); + +static struct platform_driver mt6323_regulator_driver = { + .driver = { + .name = "mt6323-regulator", + .of_match_table = of_match_ptr(mt6323_of_match), + }, + .probe = mt6323_regulator_probe, + .id_table = mt6323_platform_ids, +}; + +module_platform_driver(mt6323_regulator_driver); + +MODULE_AUTHOR("Chen Zhong <chen.zhong@mediatek.com>"); +MODULE_DESCRIPTION("Regulator Driver for MediaTek MT6397 PMIC"); +MODULE_LICENSE("GPL v2"); diff --git a/include/linux/regulator/mt6323-regulator.h b/include/linux/regulator/mt6323-regulator.h new file mode 100644 index 0000000..67011cd --- /dev/null +++ b/include/linux/regulator/mt6323-regulator.h @@ -0,0 +1,52 @@ +/* + * Copyright (c) 2016 MediaTek Inc. + * Author: Chen Zhong <chen.zhong@mediatek.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __LINUX_REGULATOR_MT6323_H +#define __LINUX_REGULATOR_MT6323_H + +enum { + MT6323_ID_VPROC = 0, + MT6323_ID_VSYS, + MT6323_ID_VPA, + MT6323_ID_VTCXO, + MT6323_ID_VCN28, + MT6323_ID_VCN33_BT, + MT6323_ID_VCN33_WIFI, + MT6323_ID_VA, + MT6323_ID_VCAMA, + MT6323_ID_VIO28 = 9, + MT6323_ID_VUSB, + MT6323_ID_VMC, + MT6323_ID_VMCH, + MT6323_ID_VEMC3V3, + MT6323_ID_VGP1, + MT6323_ID_VGP2, + MT6323_ID_VGP3, + MT6323_ID_VCN18, + MT6323_ID_VSIM1, + MT6323_ID_VSIM2, + MT6323_ID_VRTC, + MT6323_ID_VCAMAF, + MT6323_ID_VIBR, + MT6323_ID_VRF18, + MT6323_ID_VM, + MT6323_ID_VIO18, + MT6323_ID_VCAMD, + MT6323_ID_VCAMIO, + MT6323_ID_RG_MAX, +}; + +#define MT6323_MAX_REGULATOR MT6323_ID_RG_MAX + +#endif /* __LINUX_REGULATOR_MT6323_H */