Message ID | 20190613212553.10541-2-jeffrey.l.hugo@gmail.com (mailing list archive) |
---|---|
State | Superseded |
Headers | show |
Series | PM8005 and PMS405 regulator support | expand |
On Thu, Jun 13, 2019 at 02:25:53PM -0700, Jeffrey Hugo wrote: > +static int spmi_regulator_ftsmps426_set_voltage(struct regulator_dev *rdev, > + unsigned selector) > +{ > + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); > + u8 buf[2]; > + int mV; > + > + mV = spmi_regulator_common_list_voltage(rdev, selector) / 1000; > + > + buf[0] = mV & 0xff; > + buf[1] = mV >> 8; > + return spmi_vreg_write(vreg, SPMI_FTSMPS426_REG_VOLTAGE_LSB, buf, 2); > +} This could just be a set_voltage_sel(), no need for it to be a set_voltage() operation.... > +static int spmi_regulator_ftsmps426_get_voltage(struct regulator_dev *rdev) > +{ > + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); > + u8 buf[2]; > + > + spmi_vreg_read(vreg, SPMI_FTSMPS426_REG_VOLTAGE_LSB, buf, 2); > + > + return (((unsigned int)buf[1] << 8) | (unsigned int)buf[0]) * 1000; > +} ...or if the conversion is this trivial why do the list_voltage() lookup above? > +spmi_regulator_ftsmps426_set_mode(struct regulator_dev *rdev, unsigned int mode) > +{ > + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); > + u8 mask = SPMI_FTSMPS426_MODE_MASK; > + u8 val; > + > + switch (mode) { > + case REGULATOR_MODE_NORMAL: > + val = SPMI_FTSMPS426_MODE_HPM_MASK; > + break; > + case REGULATOR_MODE_FAST: > + val = SPMI_FTSMPS426_MODE_AUTO_MASK; > + break; > + default: > + val = SPMI_FTSMPS426_MODE_LPM_MASK; > + break; > + } This should validate, it shouldn't just translate invalid values into valid ones.
On Mon, Jun 17, 2019 at 9:05 AM Mark Brown <broonie@kernel.org> wrote: > > On Thu, Jun 13, 2019 at 02:25:53PM -0700, Jeffrey Hugo wrote: > > > +static int spmi_regulator_ftsmps426_set_voltage(struct regulator_dev *rdev, > > + unsigned selector) > > +{ > > + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); > > + u8 buf[2]; > > + int mV; > > + > > + mV = spmi_regulator_common_list_voltage(rdev, selector) / 1000; > > + > > + buf[0] = mV & 0xff; > > + buf[1] = mV >> 8; > > + return spmi_vreg_write(vreg, SPMI_FTSMPS426_REG_VOLTAGE_LSB, buf, 2); > > +} > > This could just be a set_voltage_sel(), no need for it to be a > set_voltage() operation.... This is a set_voltage_sel() in spmi_ftsmps426_ops. Is the issue because this function is "spmi_regulator_ftsmps426_set_voltage" and not "spmi_regulator_ftsmps426_set_voltage_sel"? > > > +static int spmi_regulator_ftsmps426_get_voltage(struct regulator_dev *rdev) > > +{ > > + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); > > + u8 buf[2]; > > + > > + spmi_vreg_read(vreg, SPMI_FTSMPS426_REG_VOLTAGE_LSB, buf, 2); > > + > > + return (((unsigned int)buf[1] << 8) | (unsigned int)buf[0]) * 1000; > > +} > > ...or if the conversion is this trivial why do the list_voltage() lookup > above? We already have code in the driver to convert a selector to the voltage. Why duplicate that inline in spmi_regulator_ftsmps426_set_voltage? > > > +spmi_regulator_ftsmps426_set_mode(struct regulator_dev *rdev, unsigned int mode) > > +{ > > + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); > > + u8 mask = SPMI_FTSMPS426_MODE_MASK; > > + u8 val; > > + > > + switch (mode) { > > + case REGULATOR_MODE_NORMAL: > > + val = SPMI_FTSMPS426_MODE_HPM_MASK; > > + break; > > + case REGULATOR_MODE_FAST: > > + val = SPMI_FTSMPS426_MODE_AUTO_MASK; > > + break; > > + default: > > + val = SPMI_FTSMPS426_MODE_LPM_MASK; > > + break; > > + } > > This should validate, it shouldn't just translate invalid values into > valid ones. Validate what? The other defines are REGULATOR_MODE_IDLE and REGULATOR_MODE_STANDBY which correspond to the LPM mode. Or are you suggesting that regulator framework is going to pass REGULATOR_MODE_INVALID to this operation?
On Mon, Jun 17, 2019 at 09:17:21AM -0600, Jeffrey Hugo wrote: > On Mon, Jun 17, 2019 at 9:05 AM Mark Brown <broonie@kernel.org> wrote: > > > +static int spmi_regulator_ftsmps426_set_voltage(struct regulator_dev *rdev, > > > + unsigned selector) > > > +{ > > > + mV = spmi_regulator_common_list_voltage(rdev, selector) / 1000; > > This could just be a set_voltage_sel(), no need for it to be a > > set_voltage() operation.... > This is a set_voltage_sel() in spmi_ftsmps426_ops. Is the issue because this > function is "spmi_regulator_ftsmps426_set_voltage" and not > "spmi_regulator_ftsmps426_set_voltage_sel"? Well, that's certainly confusing naming and there's some confusion in the code about what a selector is - it's supposed to be a raw register value so if you're having to convert it into a voltage something is going wrong. Just implement a set_voltage() operation? > We already have code in the driver to convert a selector to the > voltage. Why duplicate > that inline in spmi_regulator_ftsmps426_set_voltage? Either work with selectors or work with voltages, don't mix and match the two. > > > + switch (mode) { > > > + case REGULATOR_MODE_NORMAL: > > > + val = SPMI_FTSMPS426_MODE_HPM_MASK; > > > + break; > > > + case REGULATOR_MODE_FAST: > > > + val = SPMI_FTSMPS426_MODE_AUTO_MASK; > > > + break; > > > + default: > > > + val = SPMI_FTSMPS426_MODE_LPM_MASK; > > > + break; > > > + } > > This should validate, it shouldn't just translate invalid values into > > valid ones. > Validate what? The other defines are REGULATOR_MODE_IDLE > and REGULATOR_MODE_STANDBY which correspond to the LPM > mode. Or are you suggesting that regulator framework is going to pass > REGULATOR_MODE_INVALID to this operation? You should be validating that the argument passed in is one that the driver understands, your assumption will break if we add any new modes and in any case there should be a 1:1 mapping between hardware and API modes so you shouldn't be translating two different API modes into the same hardware mode.
On Mon, Jun 17, 2019 at 10:04 AM Mark Brown <broonie@kernel.org> wrote: > > On Mon, Jun 17, 2019 at 09:17:21AM -0600, Jeffrey Hugo wrote: > > On Mon, Jun 17, 2019 at 9:05 AM Mark Brown <broonie@kernel.org> wrote: > > > > > +static int spmi_regulator_ftsmps426_set_voltage(struct regulator_dev *rdev, > > > > + unsigned selector) > > > > +{ > > > > > + mV = spmi_regulator_common_list_voltage(rdev, selector) / 1000; > > > > This could just be a set_voltage_sel(), no need for it to be a > > > set_voltage() operation.... > > > This is a set_voltage_sel() in spmi_ftsmps426_ops. Is the issue because this > > function is "spmi_regulator_ftsmps426_set_voltage" and not > > "spmi_regulator_ftsmps426_set_voltage_sel"? > > Well, that's certainly confusing naming and there's some confusion in > the code about what a selector is - it's supposed to be a raw register > value so if you're having to convert it into a voltage something is > going wrong. Just implement a set_voltage() operation? No. Is what a selector is documented anywhere? I just looked again and I haven't found documentation explaining that a selector is the raw register value. Now I understand why this driver has the hardware to software selector translation. The selector being the raw register value seems to be a very limited assumption that I don't see working for more than very basic implementations. We've already figured out a virtualized selector mapping, I don't want to reimplement the complicated math to correctly map a requested voltage range to what the regulator can provide, and possibly get it wrong, or at the very least have two duplicate implementations. The naming is consistent with the rest of the driver, and the name seems long enough already. Lets just keep this. > > > We already have code in the driver to convert a selector to the > > voltage. Why duplicate > > that inline in spmi_regulator_ftsmps426_set_voltage? > > Either work with selectors or work with voltages, don't mix and match > the two. Fine. I'll fix up the get() to return the selector, and not the voltage since that works better with everything else that is implemented. Again, it would be nice if the documentation for regulator_ops indicated that a driver should only implement the voltage operations or the selector operations, not mix and match if that is your expectation. > > > > > + switch (mode) { > > > > + case REGULATOR_MODE_NORMAL: > > > > + val = SPMI_FTSMPS426_MODE_HPM_MASK; > > > > + break; > > > > + case REGULATOR_MODE_FAST: > > > > + val = SPMI_FTSMPS426_MODE_AUTO_MASK; > > > > + break; > > > > + default: > > > > + val = SPMI_FTSMPS426_MODE_LPM_MASK; > > > > + break; > > > > + } > > > > This should validate, it shouldn't just translate invalid values into > > > valid ones. > > > Validate what? The other defines are REGULATOR_MODE_IDLE > > and REGULATOR_MODE_STANDBY which correspond to the LPM > > mode. Or are you suggesting that regulator framework is going to pass > > REGULATOR_MODE_INVALID to this operation? > > You should be validating that the argument passed in is one that the > driver understands, your assumption will break if we add any new modes > and in any case there should be a 1:1 mapping between hardware and API > modes so you shouldn't be translating two different API modes into the > same hardware mode. Fine. I'll fix this per what you've stated. Again, would be nice if the documentation for the API modes clearly indicated they should match to one specific HW setting incases where the HW doesn't match the API 1:1.
On Mon, Jun 17, 2019 at 11:07:18AM -0600, Jeffrey Hugo wrote: > On Mon, Jun 17, 2019 at 10:04 AM Mark Brown <broonie@kernel.org> wrote: > > On Mon, Jun 17, 2019 at 09:17:21AM -0600, Jeffrey Hugo wrote: Something really weird is going on with the word wrapping in your mail, it looks like you're writing lines longer than 80 characters (120?) and they're getting a newline added in the middle of the line to wrap them without reflowing the paragraph. > > > This is a set_voltage_sel() in spmi_ftsmps426_ops. Is the issue because this > > > function is "spmi_regulator_ftsmps426_set_voltage" and not > > > "spmi_regulator_ftsmps426_set_voltage_sel"? > > Well, that's certainly confusing naming and there's some confusion in > > the code about what a selector is - it's supposed to be a raw register > > value so if you're having to convert it into a voltage something is > > going wrong. Just implement a set_voltage() operation? > No. > Is what a selector is documented anywhere? I just looked again and I > haven't found > documentation explaining that a selector is the raw register value. Well, it doesn't *have* to be the raw register value, more accurately it's some token which is useful for passing to and from the hardware; The documentation such as it is is in the documentation of the list_voltage() operation (which is what defines the selector values for a given driver). > Now I understand why this driver has the hardware to software selector > translation. > The selector being the raw register value seems to be a very limited > assumption that > I don't see working for more than very basic implementations. Your idea of very basic implementations is how the overwhelming majority of hardware is implemented. Regulators with register maps will tend to just have a bitfield where you set the voltage with each valid value in that bitfield mapped to a single voltage, the exceptions tend to use direct voltage values instead (and not support enumeration at all). Looking at the driver I think it's got what the helpers are terming pickable linear ranges (naming is hard) and could use those helpers. > We've already figured out a virtualized selector mapping, I don't want > to reimplement > the complicated math to correctly map a requested voltage range to > what the regulator > can provide, and possibly get it wrong, or at the very least have two duplicate > implementations. I don't know what a "virtualized selector mapping" is... We do have an extensive range of helper implementations which cover the majority of cases, are you sure that none of these cover what the hardware is doing? > The naming is consistent with the rest of the driver, and the name > seems long enough > already. Lets just keep this. I appreciate that the existing code is a bit of a mess but as you can see it's making it difficult to maintain so I'd rather push towards making it cleaner, it looks like we're getting more and more devices added to the driver so it's actually an issue. > Again, it would be nice if the documentation for regulator_ops > indicated that a driver > should only implement the voltage operations or the selector > operations, not mix and > match if that is your expectation. Please add whatever documentation you're looking for here. I genuinely don't know where people would look for that and TBH I'm having a hard time figuring out why you'd implement the operations asymmetrically. It's not an issue that ever comes up.
On Mon, Jun 17, 2019 at 1:24 PM Mark Brown <broonie@kernel.org> wrote: > > On Mon, Jun 17, 2019 at 01:06:42PM -0600, Jeffrey Hugo wrote: > > On Mon, Jun 17, 2019 at 12:37 PM Mark Brown <broonie@kernel.org> wrote: > > > > Something really weird is going on with the word wrapping in your mail, > > > it looks like you're writing lines longer than 80 characters (120?) and > > > they're getting a newline added in the middle of the line to wrap them > > > without reflowing the paragraph. > > > Doh. Hopefully this one is better. > > Yes, thanks! Though now it's off-list :/ Doh. Added everyone back. > > > > Well, it doesn't *have* to be the raw register value, more accurately > > > it's some token which is useful for passing to and from the hardware; > > > The documentation such as it > > > is is in the documentation of the list_voltage() operation (which is > > > what defines the selector values for a given driver). > > > Ok, so this one bit - > > Selectors range from zero to one less than regulator_desc.n_voltages. > > Voltages may be reported in any order. > > Yes. > > > So, I understand that. Its an indexing of the supported voltages. > > From my perspective, that has nothing to do with hardware. Its just a > > remapping of the values to a different set. Voltages X, Y, and Z map > > to 0, 1, and 2. Its a token so that the driver and the framework can > > use a common value. > > > I really think we are on the same page here, its just I was getting > > confused by how you were describing it in your replies. > > Yes, I was just coming from the perspective that for almost all hardware > the selectors are chosen to be the values that are in the bitfield that > the hardware uses to specify the voltage since that's the most common > thing and tends to make things simpler for people, it's also the primary > place where the concept came from. > > > > Your idea of very basic implementations is how the overwhelming majority > > > of hardware is implemented. Regulators with register maps will tend to > > > just have a bitfield where you set the voltage with each valid value in > > > that bitfield mapped to a single voltage, the exceptions tend to use > > > direct voltage values instead (and not support enumeration at all). > > > > Looking at the driver I think it's got what the helpers are terming > > > pickable linear ranges (naming is hard) and could use those helpers. > > > I'm pretty sure Stephen Boyd and Bjorn just investigated that a few > > weeks ago, and came to the conclusion that it can't because of things > > like the hardware really wants to stay in the same range if at all > > possible, which is not behavior the pickable linear ranges seems to > > support. > > Sounds like it just needs a custom map_voltage() function? Though > thinking about it it's possibly worth just making the standard map try > to keep things in the same range as that will if nothing else reduce the > number of I/O operations. Probably also reduce glitches if there's > overlapping ranges. I didn't think so when I was paying attention to their discussion. However maybe I missed something. I think I'll take another look. Might make for a nice cleanup, but if its just in the driver, or if it involves updating the framework, it seems to be outside scope for this series of changes.
diff --git a/drivers/regulator/qcom_spmi-regulator.c b/drivers/regulator/qcom_spmi-regulator.c index 1b3383a24c9d..c8791b036c53 100644 --- a/drivers/regulator/qcom_spmi-regulator.c +++ b/drivers/regulator/qcom_spmi-regulator.c @@ -104,6 +104,7 @@ enum spmi_regulator_logical_type { SPMI_REGULATOR_LOGICAL_TYPE_ULT_LO_SMPS, SPMI_REGULATOR_LOGICAL_TYPE_ULT_HO_SMPS, SPMI_REGULATOR_LOGICAL_TYPE_ULT_LDO, + SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS426, }; enum spmi_regulator_type { @@ -150,6 +151,7 @@ enum spmi_regulator_subtype { SPMI_REGULATOR_SUBTYPE_5V_BOOST = 0x01, SPMI_REGULATOR_SUBTYPE_FTS_CTL = 0x08, SPMI_REGULATOR_SUBTYPE_FTS2p5_CTL = 0x09, + SPMI_REGULATOR_SUBTYPE_FTS426_CTL = 0x0a, SPMI_REGULATOR_SUBTYPE_BB_2A = 0x01, SPMI_REGULATOR_SUBTYPE_ULT_HF_CTL1 = 0x0d, SPMI_REGULATOR_SUBTYPE_ULT_HF_CTL2 = 0x0e, @@ -170,6 +172,18 @@ enum spmi_common_regulator_registers { SPMI_COMMON_REG_STEP_CTRL = 0x61, }; +/* + * Second common register layout used by newer devices starting with ftsmps426 + * Note that some of the registers from the first common layout remain + * unchanged and their definition is not duplicated. + */ +enum spmi_ftsmps426_regulator_registers { + SPMI_FTSMPS426_REG_VOLTAGE_LSB = 0x40, + SPMI_FTSMPS426_REG_VOLTAGE_MSB = 0x41, + SPMI_FTSMPS426_REG_VOLTAGE_ULS_LSB = 0x68, + SPMI_FTSMPS426_REG_VOLTAGE_ULS_MSB = 0x69, +}; + enum spmi_vs_registers { SPMI_VS_REG_OCP = 0x4a, SPMI_VS_REG_SOFT_START = 0x4c, @@ -229,6 +243,14 @@ enum spmi_common_control_register_index { #define SPMI_COMMON_MODE_FOLLOW_HW_EN0_MASK 0x01 #define SPMI_COMMON_MODE_FOLLOW_ALL_MASK 0x1f +#define SPMI_FTSMPS426_MODE_BYPASS_MASK 3 +#define SPMI_FTSMPS426_MODE_RETENTION_MASK 4 +#define SPMI_FTSMPS426_MODE_LPM_MASK 5 +#define SPMI_FTSMPS426_MODE_AUTO_MASK 6 +#define SPMI_FTSMPS426_MODE_HPM_MASK 7 + +#define SPMI_FTSMPS426_MODE_MASK 0x07 + /* Common regulator pull down control register layout */ #define SPMI_COMMON_PULL_DOWN_ENABLE_MASK 0x80 @@ -274,6 +296,23 @@ enum spmi_common_control_register_index { #define SPMI_FTSMPS_STEP_MARGIN_NUM 4 #define SPMI_FTSMPS_STEP_MARGIN_DEN 5 +#define SPMI_FTSMPS426_STEP_CTRL_DELAY_MASK 0x03 +#define SPMI_FTSMPS426_STEP_CTRL_DELAY_SHIFT 0 + +/* Clock rate in kHz of the FTSMPS426 regulator reference clock. */ +#define SPMI_FTSMPS426_CLOCK_RATE 4800 + +/* Minimum voltage stepper delay for each step. */ +#define SPMI_FTSMPS426_STEP_DELAY 2 + +/* + * The ratio SPMI_FTSMPS426_STEP_MARGIN_NUM/SPMI_FTSMPS426_STEP_MARGIN_DEN is + * used to adjust the step rate in order to account for oscillator variance. + */ +#define SPMI_FTSMPS426_STEP_MARGIN_NUM 10 +#define SPMI_FTSMPS426_STEP_MARGIN_DEN 11 + + /* VSET value to decide the range of ULT SMPS */ #define ULT_SMPS_RANGE_SPLIT 0x60 @@ -447,6 +486,10 @@ static struct spmi_voltage_range ftsmps2p5_ranges[] = { SPMI_VOLTAGE_RANGE(1, 160000, 1360000, 2200000, 2200000, 10000), }; +static struct spmi_voltage_range ftsmps426_ranges[] = { + SPMI_VOLTAGE_RANGE(0, 0, 320000, 1352000, 1352000, 4000), +}; + static struct spmi_voltage_range boost_ranges[] = { SPMI_VOLTAGE_RANGE(0, 4000000, 4000000, 5550000, 5550000, 50000), }; @@ -480,6 +523,7 @@ static DEFINE_SPMI_SET_POINTS(ln_ldo); static DEFINE_SPMI_SET_POINTS(smps); static DEFINE_SPMI_SET_POINTS(ftsmps); static DEFINE_SPMI_SET_POINTS(ftsmps2p5); +static DEFINE_SPMI_SET_POINTS(ftsmps426); static DEFINE_SPMI_SET_POINTS(boost); static DEFINE_SPMI_SET_POINTS(boost_byp); static DEFINE_SPMI_SET_POINTS(ult_lo_smps); @@ -747,6 +791,23 @@ spmi_regulator_common_set_voltage(struct regulator_dev *rdev, unsigned selector) return spmi_vreg_write(vreg, SPMI_COMMON_REG_VOLTAGE_RANGE, buf, 2); } +static int spmi_regulator_common_list_voltage(struct regulator_dev *rdev, + unsigned selector); + +static int spmi_regulator_ftsmps426_set_voltage(struct regulator_dev *rdev, + unsigned selector) +{ + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); + u8 buf[2]; + int mV; + + mV = spmi_regulator_common_list_voltage(rdev, selector) / 1000; + + buf[0] = mV & 0xff; + buf[1] = mV >> 8; + return spmi_vreg_write(vreg, SPMI_FTSMPS426_REG_VOLTAGE_LSB, buf, 2); +} + static int spmi_regulator_set_voltage_time_sel(struct regulator_dev *rdev, unsigned int old_selector, unsigned int new_selector) { @@ -778,6 +839,16 @@ static int spmi_regulator_common_get_voltage(struct regulator_dev *rdev) return spmi_hw_selector_to_sw(vreg, voltage_sel, range); } +static int spmi_regulator_ftsmps426_get_voltage(struct regulator_dev *rdev) +{ + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); + u8 buf[2]; + + spmi_vreg_read(vreg, SPMI_FTSMPS426_REG_VOLTAGE_LSB, buf, 2); + + return (((unsigned int)buf[1] << 8) | (unsigned int)buf[0]) * 1000; +} + static int spmi_regulator_single_map_voltage(struct regulator_dev *rdev, int min_uV, int max_uV) { @@ -923,6 +994,23 @@ static unsigned int spmi_regulator_common_get_mode(struct regulator_dev *rdev) } } +static unsigned int spmi_regulator_ftsmps426_get_mode(struct regulator_dev *rdev) +{ + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); + u8 reg; + + spmi_vreg_read(vreg, SPMI_COMMON_REG_MODE, ®, 1); + + switch (reg) { + case SPMI_FTSMPS426_MODE_HPM_MASK: + return REGULATOR_MODE_NORMAL; + case SPMI_FTSMPS426_MODE_AUTO_MASK: + return REGULATOR_MODE_FAST; + default: + return REGULATOR_MODE_IDLE; + } +} + static int spmi_regulator_common_set_mode(struct regulator_dev *rdev, unsigned int mode) { @@ -945,6 +1033,28 @@ spmi_regulator_common_set_mode(struct regulator_dev *rdev, unsigned int mode) return spmi_vreg_update_bits(vreg, SPMI_COMMON_REG_MODE, val, mask); } +static int +spmi_regulator_ftsmps426_set_mode(struct regulator_dev *rdev, unsigned int mode) +{ + struct spmi_regulator *vreg = rdev_get_drvdata(rdev); + u8 mask = SPMI_FTSMPS426_MODE_MASK; + u8 val; + + switch (mode) { + case REGULATOR_MODE_NORMAL: + val = SPMI_FTSMPS426_MODE_HPM_MASK; + break; + case REGULATOR_MODE_FAST: + val = SPMI_FTSMPS426_MODE_AUTO_MASK; + break; + default: + val = SPMI_FTSMPS426_MODE_LPM_MASK; + break; + } + + return spmi_vreg_update_bits(vreg, SPMI_COMMON_REG_MODE, val, mask); +} + static int spmi_regulator_common_set_load(struct regulator_dev *rdev, int load_uA) { @@ -1274,6 +1384,21 @@ static struct regulator_ops spmi_ult_ldo_ops = { .set_soft_start = spmi_regulator_common_set_soft_start, }; +static struct regulator_ops spmi_ftsmps426_ops = { + .enable = regulator_enable_regmap, + .disable = regulator_disable_regmap, + .is_enabled = regulator_is_enabled_regmap, + .set_voltage_sel = spmi_regulator_ftsmps426_set_voltage, + .set_voltage_time_sel = spmi_regulator_set_voltage_time_sel, + .get_voltage = spmi_regulator_ftsmps426_get_voltage, + .map_voltage = spmi_regulator_single_map_voltage, + .list_voltage = spmi_regulator_common_list_voltage, + .set_mode = spmi_regulator_ftsmps426_set_mode, + .get_mode = spmi_regulator_ftsmps426_get_mode, + .set_load = spmi_regulator_common_set_load, + .set_pull_down = spmi_regulator_common_set_pull_down, +}; + /* Maximum possible digital major revision value */ #define INF 0xFF @@ -1309,6 +1434,7 @@ static const struct spmi_regulator_mapping supported_regulators[] = { SPMI_VREG(BOOST, 5V_BOOST, 0, INF, BOOST, boost, boost, 0), SPMI_VREG(FTS, FTS_CTL, 0, INF, FTSMPS, ftsmps, ftsmps, 100000), SPMI_VREG(FTS, FTS2p5_CTL, 0, INF, FTSMPS, ftsmps, ftsmps2p5, 100000), + SPMI_VREG(FTS, FTS426_CTL, 0, INF, FTSMPS426, ftsmps426, ftsmps426, 100000), SPMI_VREG(BOOST_BYP, BB_2A, 0, INF, BOOST_BYP, boost, boost_byp, 0), SPMI_VREG(ULT_BUCK, ULT_HF_CTL1, 0, INF, ULT_LO_SMPS, ult_lo_smps, ult_lo_smps, 100000), @@ -1446,6 +1572,34 @@ static int spmi_regulator_init_slew_rate(struct spmi_regulator *vreg) return ret; } +static int spmi_regulator_init_slew_rate_ftsmps426(struct spmi_regulator *vreg) +{ + int ret; + u8 reg = 0; + int delay, slew_rate; + const struct spmi_voltage_range *range = &vreg->set_points->range[0]; + + ret = spmi_vreg_read(vreg, SPMI_COMMON_REG_STEP_CTRL, ®, 1); + if (ret) { + dev_err(vreg->dev, "spmi read failed, ret=%d\n", ret); + return ret; + } + + delay = reg & SPMI_FTSMPS426_STEP_CTRL_DELAY_MASK; + delay >>= SPMI_FTSMPS426_STEP_CTRL_DELAY_SHIFT; + + /* slew_rate has units of uV/us */ + slew_rate = SPMI_FTSMPS426_CLOCK_RATE * range->step_uV; + slew_rate /= 1000 * (SPMI_FTSMPS426_STEP_DELAY << delay); + slew_rate *= SPMI_FTSMPS426_STEP_MARGIN_NUM; + slew_rate /= SPMI_FTSMPS426_STEP_MARGIN_DEN; + + /* Ensure that the slew rate is greater than 0 */ + vreg->slew_rate = max(slew_rate, 1); + + return ret; +} + static int spmi_regulator_init_registers(struct spmi_regulator *vreg, const struct spmi_regulator_init_data *data) { @@ -1585,6 +1739,12 @@ static int spmi_regulator_of_parse(struct device_node *node, ret = spmi_regulator_init_slew_rate(vreg); if (ret) return ret; + break; + case SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS426: + ret = spmi_regulator_init_slew_rate_ftsmps426(vreg); + if (ret) + return ret; + break; default: break; } @@ -1741,7 +1901,16 @@ static const struct spmi_regulator_data pmi8994_regulators[] = { { } }; +static const struct spmi_regulator_data pm8005_regulators[] = { + { "s1", 0x1400, "vdd_s1", }, + { "s2", 0x1700, "vdd_s2", }, + { "s3", 0x1a00, "vdd_s3", }, + { "s4", 0x1d00, "vdd_s4", }, + { } +}; + static const struct of_device_id qcom_spmi_regulator_match[] = { + { .compatible = "qcom,pm8005-regulators", .data = &pm8005_regulators }, { .compatible = "qcom,pm8841-regulators", .data = &pm8841_regulators }, { .compatible = "qcom,pm8916-regulators", .data = &pm8916_regulators }, { .compatible = "qcom,pm8941-regulators", .data = &pm8941_regulators },