Add support for LTC7871 #2690
Add support for LTC7871 #2690
Conversation
adiceline
requested review from
nunojsa,
mhennerich,
dbogdan,
btogorean,
chegbeli,
buha,
amiclaus,
rbolboac,
danmois,
CiprianRegus and
machschmitt
as code owners
Documentation/devicetree/bindings/regulator/adi,ltc7871-regulator.yaml
Outdated
Show resolved
Hide resolved
Documentation/devicetree/bindings/regulator/adi,ltc7871-regulator.yaml
Outdated
Show resolved
Hide resolved
Documentation/devicetree/bindings/regulator/adi,ltc7871-regulator.yaml
Outdated
Show resolved
Hide resolved
adiceline
force-pushed
the
dev/ltc7871
branch
2 times, most recently
from
a87a3cb to
bfcb9d3
Compare
V2DT Bindings
Kconfig
Driver
|
adiceline
force-pushed
the
dev/ltc7871
branch
from
8978297 to
4fc46e3
Compare
Documentation/devicetree/bindings/regulator/adi,ltc7871-regulator.yaml
Outdated
Show resolved
Hide resolved
| divided to get the modulation frequency. | ||
| $ref: /schemas/types.yaml#/definitions/uint32 | ||
| enum: [512, 1024, 2048, 4096, 256, 128, 64] | ||
| default: 512 |
There was a problem hiding this comment.
can we somehow express this in frequency and do the math in the driver to get the actual divider?
There was a problem hiding this comment.
The switching frequency is set via another external resistor which is arbitrary which means that the modulation frequency cannot be computed without prior knowledge of this resistor. Thus, we cannot directly use the modulation frequency as a property because it doesn't have fixed values.
There was a problem hiding this comment.
An alternative would be to make the user input an integer for the modulation frequency, do the math in the driver, then round to the nearest valid value for the divisor. However, if we do this, the user will not be able to readback the actual value of the modulation frequency.
There was a problem hiding this comment.
However, if we do this, the user will not be able to readback the actual value of the modulation frequency.
Why not? But for the above to work you would need to know the controller switching frequency so that you would need another resistor property right? I mean, if an external clock is used on the SYNC pin, it would be trivial to get the frequency but if you have the resistor on the FREQ pin, you would need to know it in order to do the math. Maybe let's go with the divider and see if upstream accepts it. Divider properties are not that uncommon after all.
But one thing though... you're missing an optional clock property for the SYNC pin when an external clock is used (should also be enabled in the driver). You could also add some regulator properties for the chip supplies.
The LTC7871 is a bidirectional buck or boost switching regulator controller that operates in either buck or boost mode on demand. Add corresponding DT bindings. Signed-off-by: Celine Joy A. Capua <celinejoy.capua@analog.com>
Add ADI LTC7871 buck-boost controller driver support. Signed-off-by: Celine Joy A. Capua <celinejoy.capua@analog.com>
imply REGULATOR_LTC7871. Signed-off-by: Celine Joy A. Capua <celinejoy.capua@analog.com>
adiceline
force-pushed
the
dev/ltc7871
branch
from
4fc46e3 to
a2967e7
Compare
| divided to get the modulation frequency. | ||
| $ref: /schemas/types.yaml#/definitions/uint32 | ||
| enum: [512, 1024, 2048, 4096, 256, 128, 64] | ||
| default: 512 |
There was a problem hiding this comment.
However, if we do this, the user will not be able to readback the actual value of the modulation frequency.
Why not? But for the above to work you would need to know the controller switching frequency so that you would need another resistor property right? I mean, if an external clock is used on the SYNC pin, it would be trivial to get the frequency but if you have the resistor on the FREQ pin, you would need to know it in order to do the math. Maybe let's go with the divider and see if upstream accepts it. Divider properties are not that uncommon after all.
But one thing though... you're missing an optional clock property for the SYNC pin when an external clock is used (should also be enabled in the driver). You could also add some regulator properties for the chip supplies.
| return ret; | ||
| } else { | ||
| return -EINVAL; | ||
| } |
There was a problem hiding this comment.
Typical pattern is to check for errors first... Flip the logic:
if (chip->idac_setcur_uA < LTC7871_IDAC_MIN ||
chip->idac_setcur_uA > LTC7871_IDAC_MAX) {
return dev_err_probe();
ret = ...
if (ret)
return ret;
Makes the code neater. A log message with dev_err_probe() would also be nice so we know why we failed to probe (ditto for the other properties)
| ret = device_property_read_u32(&chip->spi->dev, "adi,ra-external-ohms", | ||
| &chip->ra_ext); | ||
| if (!ret) { | ||
| if (chip->ra_ext <= 0) |
There was a problem hiding this comment.
Just if (!chip->ra_ext). It's an unsigned value so checking for negative values is meaningless...
| static s64 _ltc7871_dac_to_uV(struct ltc7871 *ltc7871, u32 dac_val) | ||
| { | ||
| return 1200 * (1000 + (div_s64(ltc7871->r2 * 1000, ltc7871->r1))) - | ||
| dac_val * ltc7871->r2; |
There was a problem hiding this comment.
I would also add a tmp variable as in _ltc7871_dac_to_uV() to make the above a bit more readable
PR Description
Buck-Boost Converter.
PR Type
PR Checklist