diff mbox series

[1/6] regulator: mcp16502: Add supplier for regulators

Message ID 20240802084433.20958-2-andrei.simion@microchip.com (mailing list archive)
State New, archived
Headers show
Series Add input voltage suppliers for PMIC MCP16502 regulators | expand

Commit Message

Andrei Simion Aug. 2, 2024, 8:44 a.m. UTC 
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(-)

Comments

Mark Brown Aug. 2, 2024, 12:56 p.m. UTC | #1 
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.
Andrei Simion Aug. 2, 2024, 2:25 p.m. UTC | #2 
> 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
Mark Brown Aug. 2, 2024, 5:58 p.m. UTC | #3 
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.
diff mbox series

Patch

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)
 };