Based on the datasheet [1] (Block Diagram) PVIN[1-4] and LVIN
represent the input voltage supply for each BUCKs respective LDOs.
Update the driver to align with the datasheet [1].
[1]: https://ww1.microchip.com/downloads/en/DeviceDoc/MCP16502-High-Performance-PMIC-for-SAMA5DX-SAM9X6-MPUs-Data-Sheet-DS20006275A.pdf
Co-developed-by: Mihai Sain <mihai.sain@microchip.com>
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Signed-off-by: Andrei Simion <andrei.simion@microchip.com>
---
drivers/regulator/mcp16502.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
index 5de9d4fa5113..b34ae0bbba6f 100644
--- a/drivers/regulator/mcp16502.c
+++ b/drivers/regulator/mcp16502.c
@@ -107,9 +107,10 @@ static unsigned int mcp16502_of_map_mode(unsigned int mode)
return REGULATOR_MODE_INVALID;
}
-#define MCP16502_REGULATOR(_name, _id, _ranges, _ops, _ramp_table) \
+#define MCP16502_REGULATOR(_name, _id, _sn, _ranges, _ops, _ramp_table) \
[_id] = { \
.name = _name, \
+ .supply_name = #_sn, \
.regulators_node = "regulators", \
.id = _id, \
.ops = &(_ops), \
@@ -467,18 +468,18 @@ static const struct linear_range b234_ranges[] = {
};
static const struct regulator_desc mcp16502_desc[] = {
- /* MCP16502_REGULATOR(_name, _id, ranges, regulator_ops, ramp_table) */
- MCP16502_REGULATOR("VDD_IO", BUCK1, b1l12_ranges, mcp16502_buck_ops,
+ /* MCP16502_REGULATOR(_name, _id, _sn, _ranges, _ops, _ramp_table) */
+ MCP16502_REGULATOR("VDD_IO", BUCK1, pvin1, b1l12_ranges, mcp16502_buck_ops,
mcp16502_ramp_b1l12),
- MCP16502_REGULATOR("VDD_DDR", BUCK2, b234_ranges, mcp16502_buck_ops,
+ MCP16502_REGULATOR("VDD_DDR", BUCK2, pvin2, b234_ranges, mcp16502_buck_ops,
mcp16502_ramp_b234),
- MCP16502_REGULATOR("VDD_CORE", BUCK3, b234_ranges, mcp16502_buck_ops,
+ MCP16502_REGULATOR("VDD_CORE", BUCK3, pvin3, b234_ranges, mcp16502_buck_ops,
mcp16502_ramp_b234),
- MCP16502_REGULATOR("VDD_OTHER", BUCK4, b234_ranges, mcp16502_buck_ops,
+ MCP16502_REGULATOR("VDD_OTHER", BUCK4, pvin4, b234_ranges, mcp16502_buck_ops,
mcp16502_ramp_b234),
- MCP16502_REGULATOR("LDO1", LDO1, b1l12_ranges, mcp16502_ldo_ops,
+ MCP16502_REGULATOR("LDO1", LDO1, lvin, b1l12_ranges, mcp16502_ldo_ops,
mcp16502_ramp_b1l12),
- MCP16502_REGULATOR("LDO2", LDO2, b1l12_ranges, mcp16502_ldo_ops,
+ MCP16502_REGULATOR("LDO2", LDO2, lvin, b1l12_ranges, mcp16502_ldo_ops,
mcp16502_ramp_b1l12)
};
--
2.34.1On Fri, Aug 02, 2024 at 11:44:28AM +0300, Andrei Simion wrote: > Based on the datasheet [1] (Block Diagram) PVIN[1-4] and LVIN > represent the input voltage supply for each BUCKs respective LDOs. > Update the driver to align with the datasheet [1]. > > [1]: https://ww1.microchip.com/downloads/en/DeviceDoc/MCP16502-High-Performance-PMIC-for-SAMA5DX-SAM9X6-MPUs-Data-Sheet-DS20006275A.pdf I'd expect to see a matching update to the bindings.
> On Fri, Aug 02, 2024 at 11:44:28AM +0300, Andrei Simion wrote: >> Based on the datasheet [1] (Block Diagram) PVIN[1-4] and LVIN >> represent the input voltage supply for each BUCKs respective LDOs. >> Update the driver to align with the datasheet [1]. >> >> [1]: https://ww1.microchip.com/downloads/en/DeviceDoc/MCP16502-High-Performance-PMIC-for-SAMA5DX-SAM9X6-MPUs-Data-Sheet-DS20006275A.pdf > I'd expect to see a matching update to the bindings. In regulator.yaml exists .*-supply [1] which practically allows every char sequence before -supply. In the binding microchip,mcp16502.yaml [2] each node under the regulators includes all the rules/documentation from regulator.yaml , so I supposed that it is unnecessary to add in the binding of those new property. What is your opinion? Let me know any thoughts. [1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/regulator/regulator.yaml#L244 [2] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/regulator/microchip%2Cmcp16502.yaml#L39 Best Regards, Andrei Simion
On Fri, Aug 02, 2024 at 02:25:15PM +0000, Andrei.Simion@microchip.com wrote: > In regulator.yaml exists .*-supply [1] which practically allows every > char sequence before -supply. In the binding microchip,mcp16502.yaml [2] > each node under the regulators includes all the rules/documentation > from regulator.yaml , so I supposed that it is unnecessary to add > in the binding of those new property. > What is your opinion? Let me know any thoughts. The specific names for a given device are supposed to be specified, there's a bunch of existing bindings that appear to do that.
On 02.08.2024 20:58, Mark Brown wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Sorry for this noise . My e-mails does not arrive on linux-arm-kernel mailing list. It is a problem with rDNS, PTR I guess. PS: I apologize for the spam BR, Andrei Simion
On 02.08.2024 20:58, Mark Brown wrote: > > On Fri, Aug 02, 2024 at 02:25:15PM +0000, Andrei.Simion@microchip.com wrote: > >> In regulator.yaml exists .*-supply [1] which practically allows every >> char sequence before -supply. In the binding microchip,mcp16502.yaml [2] >> each node under the regulators includes all the rules/documentation >> from regulator.yaml , so I supposed that it is unnecessary to add >> in the binding of those new property. >> What is your opinion? Let me know any thoughts. > The specific names for a given device are supposed to be specified, > there's a bunch of existing bindings that appear to do th OK, I understand. Thank you for the clarification. I will update the binding in patch set V2. Also, I will update all the dts and dtsi files according to the modification. Best regards, Andrei Simion
On 02.08.2024 20:58, Mark Brown wrote: >> In regulator.yaml exists .*-supply [1] which practically allows every >> char sequence before -supply. In the binding microchip,mcp16502.yaml [2] >> each node under the regulators includes all the rules/documentation >> from regulator.yaml , so I supposed that it is unnecessary to add >> in the binding of those new property. >> What is your opinion? Let me know any thoughts. > The specific names for a given device are supposed to be specified, > there's a bunch of existing bindings that appear to do that. Ok, I will sent V2 with binding update. Best Regards, Andrei Simion
> The specific names for a given device are supposed to be specified, > there's a bunch of existing bindings that appear to do that. OK, I understand. Thank you for the clarification. I will update the binding in patch set V2. Also, I will update all the dts and dtsi files according to the modification. Best regards, Andrei Simion
© 2016 - 2026 Red Hat, Inc.