Max22007 dev #3015

jansunil · 2025-11-07T16:33:39Z

PR Description

Please replace this comment with a summary of your changes, and add any context
necessary to understand them. List any dependencies required for this change.
To check the checkboxes below, insert a 'x' between square brackets (without
any space), or simply check them after publishing the PR.
If you changes include a breaking change, please specify dependent PRs in the
description and try to push all related PRs simultaneously.

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 compiled my changes, including the documentation
I have tested the changes on the relevant hardware
I have updated the documentation outside this repo accordingly
I have provided links for the relevant upstream lore

gastmaier

Hi @jansunil overall looks good, just some comments from my side.
I believe we can drop the crc feature and really streamline the driver reg access as a consequence.

Best regards,

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

drivers/iio/dac/max22007.c

nunojsa · 2025-11-12T09:05:17Z

I'll wait this getting out of draft to jump in :)

nunojsa

Here it goes my first round. Couple more points:

In the bindings patch do not day "...Add MAX22007 DAC bindings". I mean, dont mention "bindings". Its already obvious from the prefix. So instead say something like "Document MAX22007 DAC". Also refactor a bit the message and add a small description of the device.
Also refactor the driver patch commit message. See git log for other examples. Give a small description of the device. It is also a fairly simple driver so I do not think there is any meaningful to state about the implementation in the commit message.

Regarding process, note that I expect this PR to be opened against main (without the overlay). Then after merged with main, you can open a PR against the PI branch only with the overlay.

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

drivers/iio/dac/max22007.c

jansunil · 2025-11-14T10:50:58Z

Changelog V2:

    1) Remove description for spi max frequency in the yaml
2) Remove "|" character in the yaml
3) Add a default field in the properties wherever required
4) Add regmap in the Kconfig
5) Correct copyright year in the driver
6) Rearrange includes in alphabetical order and add  missing includes
7) Pass SPI buffers into state structure
8) Reformat code to meet 80 column limit
9) Remove redundant masking of buffer elements in max22007_spi_reg_write()
10) Remove locking within APIs
11) Remove explicit function for softreset and use regmap directly
12) Add macros for MAX value check for DAC Raw data
13) Implement custom regmap bus
14) Removed caching of channel configuration as it is not used again
15) Add validation for values passed from devicetree
16) Remove spi_setup
17) Add extra spaces at necessary lines of code
18) Parse CRC value from devicetree inside the max22007_configure_crc()
19) Return error code from max22007_parse_channel_cfg() and add an argument to capture the number of channels
20) Add RESET pin gpio support
21) Switch the CRC functionality to use adi,crc-disable instead of adi,crc-enable
22) Remove CRC from the Tx buffer during SPI read operations
    23) Add ABI documentation for per channel LDAC update

Document MAX22007 4-channel 12-bit DAC that drives a voltage or current output on each channel Signed-off-by: Janani Sunil <[email protected]>

Add support for the MAX22007 4 channel DAC that drives a voltage or current output on each channel. Signed-off-by: Janani Sunil <[email protected]>

Add documentation for MAX22007 driver which describes how the user can access the driver using dtoverlays Signed-off-by: Janani Sunil <[email protected]>

machschmitt

Hi @jansunil ,

Commenting mostly about the dt docs and proposed ABI. Only superficially looked into the driver code as that might change significantly depending on the discussion about the dt properties and IIO ABI.

machschmitt · 2025-11-19T12:41:37Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+  The driver supports runtime LDAC (Latch DAC) control via per-channel sysfs
+  attributes for precise output timing control.


sysfs is a Linux thing. Device tree is supposed to be project agnostic. Drop these last two lines.

machschmitt · 2025-11-19T12:49:43Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+  adi,crc-disable:
+    type: boolean
+    description:
+      Disable CRC8 error checking for SPI communications. By default, CRC8 is
+      enabled for data integrity verification. Set this property to disable it.


I see in the data sheet that SPI transfers can run with CRC disabled (set CRC_EN field to 0x0 within the configuration register (0x03) ). For max22007, CRC is a runtime configuration and has nothing to do with how hardware is set up. Drop this property.

machschmitt · 2025-11-19T12:56:20Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+allOf:
+  - $ref: /schemas/spi/spi-peripheral-props.yaml#


nitpicking: this can be simplified.
Drop allOf: and add $ref: /schemas/spi/spi-peripheral-props.yaml# after the general binding description.

machschmitt · 2025-11-19T13:57:31Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+
+patternProperties:
+  "^channel@[0-3]$":
+    type: object


we have bindings for common DAC properties (Documentation/devicetree/bindings/iio/dac/dac.yaml).
Can those simplify things ?
$ref: /schemas/iio/dac/dac.yaml#

I think you won't need

required: - reg

at least.

But I would argue that if reg is the only thing we take from it, kind of not sure if we should take it.

machschmitt · 2025-11-19T16:31:50Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+      adi,mode:
+        description:
+          Output mode for the channel.
+        $ref: /schemas/types.yaml#/definitions/string
+        enum: [voltage, current]
+        default: voltage


I wonder if it could use output-range-microamp and/or output-range-microvolt instead (see 1). If a channel has output-range-microamp in dt, then set 0x1 for the specific channel within CHNL_MODE field. With that, adi,mode becomes unneeded.

machschmitt · 2025-11-19T16:54:00Z

Documentation/ABI/testing/sysfs-bus-iio-dac-max22007

+What:		/sys/bus/iio/devices/iio:deviceX/out_voltageY_ldac_update
+KernelVersion:	6.13
+Contact:	[email protected]
+Description:
+		Trigger LDAC (Load DAC) update for the specified channel. Write 1 to update DAC outputs.
+
+What:		/sys/bus/iio/devices/iio:deviceX/out_currentY_ldac_update
+KernelVersion:	6.13
+Contact:	[email protected]
+Description:
+		Trigger LDAC (Load DAC) update for the specified channel.
+		Writing 1 will transfer the DAC register value to the actual
+		DAC output, effectively updating the analog output current.
+		Writing 0 has no effect. This is useful when using the
+		transparent latch mode is disabled, allowing manual control
+		over when DAC register changes take effect on the output.


I'm not getting the use case for this DAC latch control feature. Why not always driving the device in 'transparent' mode? We already have out_voltageY_raw for each channel. Why make the user write to out_voltageY_raw and to out_currentY_ldac_update to get the DAC output updated? I'd just always write the proper bits to LD_CTRL whenever the user writes to out_voltageY_raw.

With that, I think adi,dac-latch-mode will no longer be needed.

Being it a per channel thing, I'm also not buying it (at least yet). AFAIR, typical case for this sort of thing is to for the latch mode to update all the channels at once which might be useful (in IIO) when buffering and update all channels at once. If we are only supporting raw writes I would (at least for now) just support transparent mode. Or do you have an actual request for this?

machschmitt · 2025-11-19T17:01:02Z

Documentation/ABI/testing/sysfs-bus-iio-dac-max22007

+What:		/sys/bus/iio/devices/iio:deviceX/out_voltageY_powermode
+What:		/sys/bus/iio/devices/iio:deviceX/out_currentY_powermode
+KernelVersion:	6.13
+Contact:	[email protected]
+Description:
+		Control the power state of the specified channel. Write "on" to
+		enable the channel output, or "off" to disable it. Reading
+		returns the current power state.


Why can't this be supported with out_voltageY_powerdown 1?

Agreed. With the above, I guess we do not need any custom ABI

machschmitt · 2025-11-19T17:09:00Z

drivers/iio/dac/max22007.c

+	case IIO_CHAN_INFO_SCALE:
+		if (chan->type == IIO_VOLTAGE) {
+			*val = 5 * 2500;  /* 5 * Vref(2.5V) in mV */
+			*val2 = 4096 * 1000;  /* 12-bit DAC resolution * 1000 to convert mV to V */


this looks pretty odd. You probably want to use IIO_VAL_FRACTIONAL_LOG2 here. See how other drivers do it.

machschmitt · 2025-11-19T17:21:08Z

drivers/iio/dac/max22007.c

+		iio_chan->type = IIO_VOLTAGE;
+		iio_chan->output = 1;
+		iio_chan->indexed = 1;
+		iio_chan->channel = reg;
+		iio_chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE);
+		iio_chan->ext_info = max22007_ext_info;


I'd be tempted to create a channel template (like ad4130 or ad4170-4) to update only what's different for each channel here.

machschmitt · 2025-11-19T17:28:39Z

drivers/iio/dac/max22007.c

+		ret = gpiod_direction_output(reset_gpio, 1);
+		if (ret) {
+			dev_err(&spi->dev, "Failed to set GPIO as output: %d\n", ret);
+			return ret;
+		}


is this really needed? We already asked for output GPIO (GPIOD_OUT_LOW) above.

Nope. We just want gpiod_set_value_cansleep()

nunojsa

Some more comments from me. An additional note regarding commits. Your git subject for the bindings is nok. Please run git log --oneline Documentation/devicetree/bindings/ and follow the sytle.

nunojsa · 2025-11-20T08:45:41Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+    maxItems: 1
+    description:
+      GPIO used for hardware reset of the device. If not specified, the driver
+      will use software reset via SPI register.


As mentioned by @machschmitt, don't mention things "the driver will....". Bindings is about HW description and we should not talk about any implementation specifics. Hence, I would drop the description in here.

nunojsa · 2025-11-20T08:46:32Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+
+patternProperties:
+  "^channel@[0-3]$":
+    type: object


But I would argue that if reg is the only thing we take from it, kind of not sure if we should take it.

nunojsa · 2025-11-20T08:49:38Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+
+      adi,dac-latch-mode:
+        description:
+          DAC latch control mode for the channel.


Here the description does not add much when compared to the property name. If you're used to these chips, you know what this is about but if you are not... Please add brief description of what is this about (and remember, just in terms of HW)

nunojsa · 2025-11-20T08:50:53Z

Documentation/devicetree/bindings/iio/dac/adi,max22007.yaml

+  - required: [channel@0]
+  - required: [channel@1]
+  - required: [channel@2]
+  - required: [channel@3]


At least vdd should be also required. If the other regulators are not optional, they should be also required

nunojsa · 2025-11-20T08:54:58Z

arch/arm/boot/dts/overlays/rpi-max22007-overlay.dts

+/*
+ * Analog Devices MAX22007
+ *
+ * hdl_project: <max22007_rpi>


Do we need an hdl tag in here?!

nunojsa · 2025-11-20T09:24:42Z

drivers/iio/dac/max22007.c

+		if (ret)
+			return ret;
+		*val = reg_val;
+		return IIO_VAL_INT;


Don't use any temp variable. Pass val directly and handle things inside max22007_read_channel_data(). Then, here it becomes return max22007_read_channel_data() which looks much better

nunojsa · 2025-11-20T09:25:39Z

drivers/iio/dac/max22007.c

+
+	state->crc_en = crc;
+
+	return 0;


No sure I would support this for now. I would assume CRC always on and have this if and when someone asks for it

nunojsa · 2025-11-20T09:26:38Z

drivers/iio/dac/max22007.c

+
+		iio_chan = &st->iio_chan[i];
+
+		iio_chan->type = IIO_VOLTAGE;


Drop the above given that you're doing it again down below

nunojsa · 2025-11-20T09:27:22Z

drivers/iio/dac/max22007.c

+	state->regmap = devm_regmap_init(&spi->dev, &max22007_regmap_bus, state,
+					 &max22007_regmap_config);
+	if (IS_ERR(state->regmap)) {
+		dev_err(&spi->dev, "Failed to initialize regmap\n");


dev_err_probe()

nunojsa · 2025-11-20T09:27:32Z

drivers/iio/dac/max22007.c

+	if (reset_gpio) {
+		ret = gpiod_direction_output(reset_gpio, 1);
+		if (ret) {
+			dev_err(&spi->dev, "Failed to set GPIO as output: %d\n", ret);


jansunil requested review from amiclaus and gastmaier November 7, 2025 16:33

jansunil force-pushed the max22007-dev branch from 4ab9538 to bd8314f Compare November 10, 2025 05:41

gastmaier requested changes Nov 10, 2025

View reviewed changes

gastmaier reviewed Nov 10, 2025

View reviewed changes

drivers/iio/dac/max22007.c Outdated Show resolved Hide resolved

gastmaier reviewed Nov 11, 2025

View reviewed changes

drivers/iio/dac/max22007.c Show resolved Hide resolved

jansunil force-pushed the max22007-dev branch from bd8314f to 39b2409 Compare November 12, 2025 13:10

jansunil marked this pull request as ready for review November 12, 2025 13:55

jansunil requested review from CiprianRegus, btogorean, buha, chegbeli, danmois, dbogdan, machschmitt, mhennerich, nunojsa and rbolboac as code owners November 12, 2025 13:55

nunojsa reviewed Nov 12, 2025

View reviewed changes

gastmaier reviewed Nov 13, 2025

View reviewed changes

drivers/iio/dac/max22007.c Outdated Show resolved Hide resolved

jansunil force-pushed the max22007-dev branch 2 times, most recently from ae84b9d to bb72180 Compare November 14, 2025 10:42

jansunil added 3 commits November 14, 2025 11:51

Documentation: iio: dac: Add MAX22007

c3d7cc9

Document MAX22007 4-channel 12-bit DAC that drives a voltage or current output on each channel Signed-off-by: Janani Sunil <[email protected]>

iio: dac: Add MAX22007 DAC driver support

b14bf32

Add support for the MAX22007 4 channel DAC that drives a voltage or current output on each channel. Signed-off-by: Janani Sunil <[email protected]>

docs: iio: Add documentation for MAX22007 driver

6e82321

Add documentation for MAX22007 driver which describes how the user can access the driver using dtoverlays Signed-off-by: Janani Sunil <[email protected]>

jansunil force-pushed the max22007-dev branch from bb72180 to 6e82321 Compare November 14, 2025 10:52

machschmitt reviewed Nov 19, 2025

View reviewed changes

nunojsa reviewed Nov 20, 2025

View reviewed changes

		The driver supports runtime LDAC (Latch DAC) control via per-channel sysfs
		attributes for precise output timing control.

Max22007 dev #3015

Are you sure you want to change the base?

Max22007 dev #3015

Uh oh!

Conversation

jansunil commented Nov 7, 2025

PR Description

PR Type

PR Checklist

Uh oh!

gastmaier left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

nunojsa commented Nov 12, 2025

Uh oh!

nunojsa left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jansunil commented Nov 14, 2025

Uh oh!

machschmitt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nunojsa left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nunojsa left a comment •

edited

Loading