Add support for ADP5055 #2668

actorreno · 2024-12-06T08:17:19Z

PR Description

This adds driver support and device tree bindings for ADP5055 triple buck regulator.
Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/adp5055.pdf
Tested on RPI4 on the eval board: https://www.analog.com/media/en/technical-documentation/user-guides/adp5055-evalz-ug-1930.pdf

PR Type

Bug fix (a change that fixes an issue)
New feature (a change that adds new functionality)
Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

I have conducted a self-review of my own code changes
I have tested the changes on the relevant hardware
I have updated the documentation outside this repo accordingly (if there is the case)

nunojsa · 2024-12-06T13:11:18Z

Please, fix first the valid CI errors you have...

actorreno · 2024-12-09T06:27:26Z

It seems the checks returns some errors I couldn't capture when locally running commit check scripts like "./scripts/checkpatch <driver_file>"

I have fixed them except 1 last error which I am confused about since the error is not related to my files.
Screenshot below.

Edit: was fixed by rebasing to latest main

kister-jimenez

ADP5055 is PMBUS compatible, should this be under hwmon/pmbus?

actorreno · 2025-01-17T08:36:34Z

The datasheet did say "pmbus compatible" but it didn't have any pmbus commands the other typical pmbus dataseet contain
it also doesn't have an eeprom for the usual "pages" I see in other pmbus codes.

some colleagues agreed with me that it was just an i2c interface and decided it is better off in the regulator subsystem

nunojsa · 2025-01-20T11:09:38Z

ADP5055 is PMBUS compatible, should this be under hwmon/pmbus?

Hmm, I do think this is a pertinent question... Looking at the description:

"The ADP5055 is a power management unit that combines three high performance buck regulators with a PMBus interface..."

So this looks like a typical power management device that fits in HWMON/PMBUs. Note that the pmbus subsystem also has an interface with the regulator subsystem and it will also check what standard PMbus registers are supported by the device. On top of that, you can pretty much bypass the standard registers and control the device as you want. Example, I see the VIDx_LOW/HIGH registers that could fit in the standard HWMON ABI and you totally support it even not using standard pmbus commands. There's also power good and overcurrent stuff that could very likely be made to work.

All the above to say that pmbus might be doable and allows you to better support this device (meaning, more features). You can also internally reach the apps engineer for this part and try to understand the actual PMBUS commands supported. Looking at the datasheet, I can see STATUS_CML to be supported.

nunojsa

I'm still not convinced on the location of the driver but i'm already doing some comments on the DT bindings

nunojsa · 2025-01-20T11:16:59Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

+      0 - Physical EN pin is used for enabling.
+      1 - Internal Register is used for enabling.
+      2 - Both register and physical pin needed.
+      3 - Either register or physical pin.


This looks custom implementation of a subset of the ON_OFF_CONFIG command. Moreover, DT maintainers do not like much of properties like this where you just give the register code. You should have a string property and do the mapping in the driver (for register values). On top of that, you should likely control 3 gpios that should be mandatory for options 0 and 3.

nunojsa · 2025-01-20T11:18:14Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

+      Enables or disables over current protection
+      blanking (OCP) for all channels.
+      0 = Disabled
+      1 = Enabled


no need for the 0/1 description. Should encode the state in the property name. Simply adi,ocp-blanking and if the property is enabled, then it's pretty clear we're enabling the feature.

nunojsa · 2025-01-20T11:20:32Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

+    items:
+      minimum: 0
+      maximum: 3
+    default: 3, 3, 3


You have a lot properties for the channels so I think it might be a good idea to create channel child nodes and have the properties per channel instead of this.

actorreno · 2025-02-03T04:29:28Z

ADP5055 is PMBUS compatible, should this be under hwmon/pmbus?

Hmm, I do think this is a pertinent question... Looking at the description:

"The ADP5055 is a power management unit that combines three high performance buck regulators with a PMBus interface..."

So this looks like a typical power management device that fits in HWMON/PMBUs. Note that the pmbus subsystem also has an interface with the regulator subsystem and it will also check what standard PMbus registers are supported by the device. On top of that, you can pretty much bypass the standard registers and control the device as you want. Example, I see the VIDx_LOW/HIGH registers that could fit in the standard HWMON ABI and you totally support it even not using standard pmbus commands. There's also power good and overcurrent stuff that could very likely be made to work.

All the above to say that pmbus might be doable and allows you to better support this device (meaning, more features). You can also internally reach the apps engineer for this part and try to understand the actual PMBUS commands supported. Looking at the datasheet, I can see STATUS_CML to be supported.

Hi,

I understand the reason on why pmbus should be reconsidered and I have been trying to learn how regulators are incorporated in the subsystem. However, it seems that when using "pmbus_do_probe" it calls a function called "pmbus_init_common" that looks for specific registers mainly PMBUS_STATUS_BYTE or PMBUS_STATUS_WORD (address 0x78 and 0x79) and this doesn't exist in the device hence the driver cannot properly load.

A manual i2c transaction does yield a read error

Keeping it under the regulator subsystem still seems appropriate due to this.

Will yet to address dt-bindings feedbacks.

Add documentation for devicetree bindings for ADP5055. Signed-off-by: Alexis Czezar Torreno <[email protected]>

Add ADI ADP5055 triple buck regulator driver support. Signed-off-by: Alexis Czezar Torreno <[email protected]>

imply REGULATOR_ADP5055. Signed-off-by: Alexis Czezar Torreno <[email protected]>

actorreno · 2025-02-05T07:23:23Z

v2

yaml:

adjusted to include child nodes for some properties.
added string properties where needed

.c:

adjusted to read the new types of properties like from int to string, from array to child nodes
added gpios to include the behavior of those during enable and the mode is HW en

nunojsa · 2025-02-05T09:27:40Z

that looks for specific registers mainly PMBUS_STATUS_BYTE or PMBUS_STATUS_WORD

Yeah that looks to be the case yes... We would need to change the pmbus core to not check for these registers or a way to use driver specific stuff but yes, at this point I would not bother for that. Let's keep it under the regulator subsystem and hope no one asks for the monitoring features 😅

nunojsa · 2025-02-07T07:43:55Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

@@ -0,0 +1,227 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2024 Analog Devices, Inc.


I do not think it's typical to have Copyright in bindings?! (anyways the year is not ok)

nunojsa · 2025-02-07T07:44:21Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

+  reg:
+    description:
+      I2C address of the device. LSB depends on value of
+      hardware pin CFG2.


I do not think the description is needed here

nunojsa · 2025-02-07T07:44:57Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

+    description:
+      Asserted during driver probe. Acts as the hardware enable
+      for channel 2. Should be marked 0 for active low.
+    maxItems: 1


The above are custom properties so you need the vendor prefix on them

nunojsa · 2025-02-07T07:46:53Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

+      Configure how channels are enabled. Whether only via
+      hardware, software, both, or either.
+    enum: [only_hw_en, only_sw_en, both_hw_sw_en, either_hw_sw_en]
+    default: only_hw_en


Do we really need the above property? Would a user really care for this? I would likely just use (at leas for now) the first two options. I would use SW if we do not have any GPIO and use HW in case the GPIOs are present

nunojsa · 2025-02-07T07:55:11Z

Documentation/devicetree/bindings/regulator/adi,adp5055-regulator.yaml

+      0 - No delay.
+      1 - Delay timer = Tset.
+      See datasheet for values of Tset.
+    type: boolean


No need for the 0, 1 description. It's a boolean so its already clear that if the property is present we have a delay. You could also mentioned that the delay is set to TSET (which can be 2.6 or 20.0ms). Just two values so you could mention them here.

nunojsa · 2025-02-07T08:21:58Z

drivers/regulator/adp5055-regulator.c

+
+static struct i2c_driver adp5055_driver = {
+	.driver	= {
+		.name	= "adp5055",


please add an of_id_table

nunojsa · 2025-02-07T08:22:11Z

drivers/regulator/adp5055-regulator.c

+	.probe		= adp5055_probe,
+	.id_table	= adp5055_ids,
+};
+


nit: no need for new line

nunojsa · 2025-02-07T08:22:48Z

drivers/regulator/adp5055-regulator.c

+		}
+	}
+
+	i2c_set_clientdata(client, adp5055);


is the above needed? does not looks like it is

nunojsa · 2025-02-07T08:23:01Z

drivers/regulator/adp5055-regulator.c

+
+		rdev = devm_regulator_register(dev, desc, &config);
+		if (IS_ERR(rdev)) {
+			dev_err(dev, "Failed to register %s\n", desc->name);


dev_err_probe()

nunojsa · 2025-02-07T08:23:57Z

drivers/regulator/adp5055-regulator.c

+	if (!adp5055)
+		return -ENOMEM;
+
+	adp5055->regmap = devm_regmap_init_i2c(client, regmap_config);


why not passing directly adp5055_regmap_config?

actorreno requested review from nunojsa, mhennerich, dbogdan, btogorean, chegbeli, buha, amiclaus, rbolboac, danmois, CiprianRegus and machschmitt as code owners December 6, 2024 08:17

actorreno force-pushed the dev/adp5055-regulator branch 9 times, most recently from 5d77901 to 36d5ba8 Compare December 9, 2024 02:38

actorreno force-pushed the dev/adp5055-regulator branch from 36d5ba8 to 03486f9 Compare December 18, 2024 04:25

kister-jimenez reviewed Jan 17, 2025

View reviewed changes

nunojsa reviewed Jan 20, 2025

View reviewed changes

actorreno force-pushed the dev/adp5055-regulator branch 2 times, most recently from 8e79e38 to bdc82e1 Compare February 5, 2025 01:46

actorreno force-pushed the dev/adp5055-regulator branch 8 times, most recently from 329cb3b to 4c5811a Compare February 5, 2025 05:20

actorreno added 3 commits February 5, 2025 14:49

dt-bindings: regulator: add adi,adp5055-regulator.yaml

ac397b6

Add documentation for devicetree bindings for ADP5055. Signed-off-by: Alexis Czezar Torreno <[email protected]>

regulator: adp5055: Add driver for adp5055

1a24f36

Add ADI ADP5055 triple buck regulator driver support. Signed-off-by: Alexis Czezar Torreno <[email protected]>

kconfig.adi: Add ADP5055

154c066

imply REGULATOR_ADP5055. Signed-off-by: Alexis Czezar Torreno <[email protected]>

actorreno force-pushed the dev/adp5055-regulator branch from 4c5811a to 154c066 Compare February 5, 2025 06:50

actorreno requested review from nunojsa and kister-jimenez February 5, 2025 08:03

nunojsa reviewed Feb 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for ADP5055 #2668

Add support for ADP5055 #2668

actorreno commented Dec 6, 2024

nunojsa commented Dec 6, 2024

actorreno commented Dec 9, 2024 •

edited

Loading

kister-jimenez left a comment

actorreno commented Jan 17, 2025

nunojsa commented Jan 20, 2025

nunojsa left a comment

nunojsa Jan 20, 2025

nunojsa Jan 20, 2025

nunojsa Jan 20, 2025

actorreno commented Feb 3, 2025

actorreno commented Feb 5, 2025 •

edited

Loading

nunojsa commented Feb 5, 2025 •

edited

Loading

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

nunojsa Feb 7, 2025

		@@ -0,0 +1,227 @@
		# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
		# Copyright (c) 2024 Analog Devices, Inc.

Add support for ADP5055 #2668

Are you sure you want to change the base?

Add support for ADP5055 #2668

Conversation

actorreno commented Dec 6, 2024

PR Description

PR Type

PR Checklist

nunojsa commented Dec 6, 2024

actorreno commented Dec 9, 2024 • edited Loading

kister-jimenez left a comment

Choose a reason for hiding this comment

actorreno commented Jan 17, 2025

nunojsa commented Jan 20, 2025

nunojsa left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

actorreno commented Feb 3, 2025

actorreno commented Feb 5, 2025 • edited Loading

nunojsa commented Feb 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

actorreno commented Dec 9, 2024 •

edited

Loading

actorreno commented Feb 5, 2025 •

edited

Loading

nunojsa commented Feb 5, 2025 •

edited

Loading