Add ad7606x_pi driver
Supported AD7606x family devices in this driver:
Digital interface mode - Parallel:
Eval boards - digital interface mode - parallel:
HDL project and control module for parallel interface - link-project, link-control_module;
V2:
- changed the commits' order;
- solved issues from the checkpatch part, related to code warnings;
V3:
- Updated indentation for gpio array [adi,adc_os (dts, bindings)];
- Updated properties to a vendor-based version [driver, dts files];
Driver has been reworked to integrate with the AXI ADC IP core 1 in linked mode.
First patches update the AXI ADC core driver itself to enable it to link with platform device drivers. Then we add device tree doc, AD7606C-16/-18 support, and dts files.
The AXI ADC interface update was driven by a spatch semantic patch 2 with a few manual tweaks to pass checkpatch.
This set provides support for AD7606C-16/-18 as converter frontend ADCs integrated with the AXI ADC IP core Linux driver.
The semantic patch can be applied over ongoing/unmerged work to update code to the new interface.
Hey Alexandru, thank you for your review.
This is sort of unusual set. It only uses the parallel interface so we don't probe it as an SPI device. Though it uses the AXI bus so it made sense to use the AXI ADI ADC core module. By the way, AXI ADI ADC is almost a tong twister. Sometimes I think of it like a mantra. You go repeating AXI ADI ADC ADI ADC AXI ...
Change log V4 -> V5:
- Locked before updating device registers
- Corrected dts to declare reset gpio as active high
- Removed unused gpios from dts
- Reworked ad7606_conv_full_reset() to be like upstream ad7606
- Handled function return values
- Removed unused includes
- Removed unused state fields
- Some variable renames and minor neats
The latest push has changes to make it pass dt_binding_check (at least locally, I don't understand why it's not passing dt_binding_check pipeline). There is a checkpatch CHECK: Macro argument reuse which doesn't seem to be a problem but Azure pipeline complains anyway.
Change log V5 -> V6:
- Added of compatible string "adi,axi-ad7606-1.0" in cf_axi_adc_core.c
- Updated dt binding doc and dts files to match the new compatible string
@alin724 I tried building this branch as you suggested here
I got kernel build errors from the ad7606_conv.c file, about undefined reference to axiadc_read/axiadc_write calls. I resolved those errors by adding the CF_AXI_ADC symbol to the kernel .config. It adds the Analog Devices High-Speed AXI driver core. Once added the kernel is built successfully. Perhaps you overlooked it because IIO_ALL_ADI_DRIVERS was selected in your configuration. Anyway it should be selected also if AD7606_CONV=y
Thanks Roy
Wondering what is blocking this PR at the moment. Mainline work? Did we start sending it, I don't think I have seen anything on the mailing list.
Applied all suggested changes. The first patch(es) update the AXI ADC core driver to enable it to link with platform device drivers which required a lot of collateral changes in other ADC drivers. If possible, I think it would be sensible to check at least a few of them in case I have missed anything. If everything is ok, I can work on upstreaming it.
Change log v6 -> v7:
- Dropped MAINTAINERS file changes
- Assigned axiadc_dev->owner
- Merged GPIO and reset into a single function and released GPIO after use
- Code style tidy up
- Device tree doc nits
Hi What is the correlated HDL branch for testing this PR? Is it https://github.com/analogdevicesinc/hdl/tree/update_ad7606_spi_engine ? Should I use it only in parallel mode? (with the AD7606c-16).
Hi @bspguy,
From PR description, it looks like the HDL branch for the parallel interface is ad7606x_fmc.
I think this PR uses the spi engine which this https://github.com/analogdevicesinc/hdl/tree/master/projects/ad7606x_fmc hdl design doesn't. The https://github.com/analogdevicesinc/hdl/tree/update_ad7606_spi_engine does use the spi engine. Am I wrong and the PR description is correct? @alin724
I think this PR uses the spi engine which this https://github.com/analogdevicesinc/hdl/tree/master/projects/ad7606x_fmc hdl design doesn't. The https://github.com/analogdevicesinc/hdl/tree/update_ad7606_spi_engine does use the spi engine. Am I wrong and the PR description is correct? @alin724
Hi @bspguy, This PR supports only the parallel interface that is present in the ad7606x project from the HDL repository. [this driver and related devicetrees for 16/18b will have the support for the parallel interface and different configurations using the device's regmap
-
using the commands indicated in the https://wiki.analog.com/resources/fpga/docs/axi_adc_ip
-
ADC_CONFIG_CTRL register for read/write operations and ADC_CONFIG_WR for data that will be written to the device's register using the parallel interface's data pins).
Thanks @alin724 ! I would appreciate your assistance on this issue - https://ez.analog.com/data_converters/precision_adcs/f/q-a/575949/ad7606c-16-device-tree-for-zcu102
Or perhaps refer me to someone who could help.
Thanks!
Hi, if there are no more suggestions about this patch series maybe we could merge it into master. @nunojsa, would you like me to make any other change to this?
Hi, if there are no more suggestions about this patch series maybe we could merge it into master. @nunojsa, would you like me to make any other change to this?
Maybe this one can wait on the backend stuff I'm working on. Then, we don't need more unnecessary changes in the cf drivers. Plus, we can upstream it
Maybe this one can wait on the backend stuff I'm working on. Then, we don't need more unnecessary changes in the cf drivers. Plus, we can upstream it
Sure, I've worked with these converter front ends enough to not be willing to rework the drivers again after the iio-backend framework gets accepted upstream :)
For note, AD3552R (CN0585 project) (PR #2194) is another driver that shall benefit from the iio-backend fw (the DDS backend part of it).
For note, AD3552R (CN0585 project) (PR https://github.com/analogdevicesinc/linux/pull/2194) is another driver that shall benefit from the iio-backend fw (the DDS backend part of it).
Yeps, I noticed we have some pending PRs that can use it. So better wait for it and rework those PULLs afterwards
I have tested @alin724's PR on the Xilinx ZCU102 board with the EVAL-ad7606CFMCZ. The driver works as expected :100: If you wish I can prepare a PR for the HDL project and the device-tree modifications needed for it to work on the Xilinx board. Thanks!
I have tested @alin724's PR on the Xilinx ZCU102 board with the EVAL-ad7606CFMCZ. The driver works as expected 💯 If you wish I can prepare a PR for the HDL project and the device-tree modifications needed for it to work on the Xilinx board. Thanks!
Hi @bspguy, that's great. Though, if you made any changes to files included in the PR (e.g. devicetree files) you should comment here (do a review) and tell what the changes/fixes are so we can have it all in this PR (not spamming PRs about the same project).
Thanks for reviewing/testing ad7606 parallel interface project.
Hi @machschmitt
I have not made any changes to files in this PR but actually made a new separate dts file for the AD7606c-16 to support the ZCU102, which should be placed under /arch/arm64/boot/dts/xilinx/ in the kernel tree.
Shouldn't that be on a separate PR?
Thanks
Roy
Hi @machschmitt
I have not made any changes to files in this PR but actually made a new separate dts file for the AD7606c-16 to support the ZCU102, which should be placed under
/arch/arm64/boot/dts/xilinx/in the kernel tree.Shouldn't that be on a separate PR?
Thanks
Roy
Waiting for you guys to answer.. Thanks Roy
Hello @bspguy,
I have not made any changes to files in this PR but actually made a new separate dts file for the AD7606c-16 to support the ZCU102, which should be placed under /arch/arm64/boot/dts/xilinx/ in the kernel tree. Shouldn't that be on a separate PR?
Oh, okay. Yes, device tree and device tree overlay files are often submitted in separate PRs. Although, it looks like this PR is not going to be merged because we are going to have new kernel interfaces between the DAC IP core and DAC devices upstream. We (I) must update the ad3552r driver to use the new DAC IP interface (adi-axi-dac) and submit the changes upstream. Because of this update, the device tree nodes for these devices might change a little bit and so I would recommend waiting until the changes get upstream to then update the additional dts files and create a PR with them.
Hi @machschmitt @alin724. What is blocking this PR? I would like to add device-tree support for the Xilinx board. Thanks.
Hi @bspguy,
Hi @machschmitt @alin724. What is blocking this PR? I would like to add device-tree support for the Xilinx board.
The fact that there are newer upstream kernel interfaces for integrating ADCs with the AXI bus (namely, the iio-backend framework). The code in this PR is stale and I'm pretty sure it won't be merged into ADI Linux. The iio-backend framework should be used for AD7606 parallel interface. The device tree will be different too. Please, have a look at the current work for AD7606 parallel interface https://lore.kernel.org/linux-iio/20240920-ad7606_add_iio_backend_support-v2-0-0e78782ae7d0@baylibre.com/.
I'm closing this PR since this will not be merged.