Skip to content

iio: adc: Add initial driver support for MAX14001/MAX14002 #2848

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: rpi-6.6.y_GSOC_2025_MAX14001
Choose a base branch
from

Conversation

MarileneGarcia
Copy link

@MarileneGarcia MarileneGarcia commented Jul 13, 2025

The MAX14001/MAX14002 are configurable, isolated 10-bit ADCs for multi-range binary inputs.

Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX14001-MAX14002.pdf

PR Description

Basic IIO ADC max14001 driver features:

  • Definitions for register addresses and useful constants (if any).
  • Definitions for the IIO channels.
  • Device state struct.
  • read_raw and write_raw function implementations (just a mock for now).
  • iio_info struct populated with a reference to the read_raw and write_raw functions.
  • Probe function to initialize and make basic setup for the device.
  • SPI and device tree MODULE_DEVICE_TABLEs
  • Device tree overlay for Raspberry Pi 5
  • Basic max14001 SPI read and write functions

PR Type

  • New feature (a change that adds new functionality)

PR Checklist

  • I have conducted a self-review of my own code changes
  • I tested it on the Raspberry Pi, but without the max14001 board, I couldn't fully validate it yet.
  • Evidence of some basic features working
Screenshot from 2025-07-13 20-02-34

The MAX14001/MAX14002 are configurable, isolated 10-bit ADCs for
multi-range binary inputs.

Datasheet:
Link: https://www.analog.com/media/en/technical-documentation/data-sheets/MAX14001-MAX14002.pdf

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from 8e965dc to 0ecd86d Compare July 13, 2025 23:58
Copy link
Contributor

@machschmitt machschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @MarileneGarcia , a few comments about this initial driver version.
Note that, aside from the comments above, there are still some improvements that need to be made to make this driver usable (e.g. read ADC sample data, provide scale to convert output codes to mV). Those features shall be implemented next. Though, overall, this looks good to me as an initial driver version.

Copy link

@jonathanns jonathanns left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few more notes.

@MarileneGarcia
Copy link
Author

Hi @MarileneGarcia , a few comments about this initial driver version. Note that, aside from the comments above, there are still some improvements that need to be made to make this driver usable (e.g. read ADC sample data, provide scale to convert output codes to mV). Those features shall be implemented next. Though, overall, this looks good to me as an initial driver version.

Ok, thank you for the comments! I think I have address them. I will start working in the other needed features, like the read ADC sample data and provide scale to convert output codes to mV.

@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from d29debd to f6eaef5 Compare July 20, 2025 15:37
@MarileneGarcia
Copy link
Author

Just a few more notes.

Ok, thank you for the comments! I think I have address them. The ones related to the write_raw I am going to check in the next steps.

- Update the ovelay file to reflect the evaluation board name
- Add Vddl and Vrefin regulators to the overlay file
- Update the log print methods
- Remove unnecessary code
- Improve code style
- Add chip_info struct
- Add max14001_spi_write_single_reg method, which enables and
  disables the write register when writing data to another register

Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
@MarileneGarcia MarileneGarcia force-pushed the rpi-6.6.y_GSOC_2025_MAX14001 branch from f6eaef5 to b451319 Compare July 20, 2025 15:50
Copy link
Contributor

@machschmitt machschmitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

A few more comments.
The regulator thing can be done on a different PR (we might need to rebase or create another GSoC branch if updating to kernel 6.12).

Keep up the good work.

{
int ret;

//Enable register write
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use IIO subsystem preferred comment style:

-	//Enable register write
+	/* Enable register write */

if (ret < 0)
return ret;

//Write data into register
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

-	//Write data into register
+	/* Write data into register */

if (ret < 0)
return ret;

//Disable register write
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and here

indio_dev->name = st->chip_info->name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = &max14001_info;

Copy link
Contributor

@machschmitt machschmitt Jul 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missed it on my first review, but the driver needs to get the voltage regulators during probe.
IIRC, vdd and vddl are required while vrefin is not. If so, I'd suggest using devm_regulator_get_enable() to get vdd and vddl, and devm_regulator_get_enable_read_voltage() for vrefin. See drivers/regulator/devres.c, https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git/tree/drivers/iio/adc/ad7191.c#n130 , for example.

PS.: those regulator_get_... calls may not be available in kernel 6.6. If so, you can either (1) use devm_regulator_get(), regulator_enable(), and regulator_get_voltage(), or (2) update to a newer kernel and look for that API. We have a newer rpi branch now, https://github.com/analogdevicesinc/linux/tree/staging-rpi/rpi-6.12.y

Slight preference for (2), but option (1) is also fine for now.


/* TODO: Validate this line in the hw, could be le16_to_cpu */
reversed = bitrev16(be16_to_cpu(rx));
*val = FIELD_GET(MAX14001_MASK_ADDR, reversed);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why MAX14001_MASK_ADDR?
Isn't the intent to read the register data?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, my mistake. I am going to change that, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants