ad4052-ardz: Remove TODO comment

docs/learning/converter_connectivity_tutorial/index.rst

@@ -8,45 +8,44 @@
 and example code as you are evaluating and prototyping with Analog Devices'
 data converters and converter-like products. Selection of an ADC, DAC, or
 sensor often starts by finding something that meets performance requirements
 (obviously). This may be followed with some experimentation with the device's
 evaluation board and accompanying software, but at some point you need to "take
 the next step". This "next step" could be any one of a wide array of things -
 wiring the eval board to a prototype of a larger system, deeper
 characterization using your own benchtop test equipment, or any one of a
 plethora of random requirements. This tutorial will arm you with a number of
 tools to this end
 
 .. NOTE::
 
    **Update:**
    The first version of this tutorial was published in early 2020, after test
    driving the setup with a few select field engineers. A lot has happened since
    then:
 
    - :ref:`kuiper` has matured considerably, with broad support for ADI devices
      and popular processor and FPGA development platforms
 
-   - The very popular :adi:`ADXL355 Pmod <eval-adxl355-pmdz>` would have been
-     used initially, but the Linux driver had not been upstreamed yet. It has since
-     been released, and is being added as an option for this tutorial. (The original
-     ADXL345 / Digilent Pmod-ACL is still included.)
+   - The :adi:`ADXL355 Pmod <eval-adxl355-pmdz>` has since been released, and
+     is being added as an option for this tutorial. (The original ADXL345 /
+     Digilent Pmod-ACL is still included.)
 
    -  LibIIO now supports HWMON devices (if these terms aren't familiar, you'll
       learn about them soon), enabling the use of the absolute **best** device to
       start learning about embedded Linux systems: the LM75 temperature sensor.
       It is an industry standard with several manufacturers, including the
       :adi:`Maxim LM75 <LM75>` and ADI's variant, :adi:`ADT75 <ADT75>`
 
    So while it's generally not a good idea to have too many options in a basic
    tutorial, we felt that having a couple was appropriate here, including one that
    is very low cost (the LM75)g
 
 Analog Devices provides an assortment of evaluation boards and reference
 designs for converters of various channel counts, bandwidths, and other
 functionality, whose drivers fit into the Industrial Input Output (IIO)
 framework. This framework facilitates robust data transfer to or from the
 converter into "userspace", where the user program could be a MATLAB script for
 device characterization, a Python script that talks to benchtop signal
 generators and spectrum analyzers via GPIB in addition to the ADI part under
 test, or a C program embedded in the end product. Most of these involve fairly
 costly reference design hardware installed on even more costly FPGA platform
@@ -91,7 +90,7 @@
 understand how to communicate with an LM74, ADXL345, or ADXL355, you're well
 over the initial learning curve to understanding much more complicated
 systems. The :dokuwiki:`ADALM-Pluto </university/tools/pluto>` is a great example -
 it contains an AD9363 RF Agile Transcieiver, Zynq SoC FPGA, Memory, USB interface,
 and much more. Even the simplified block diagram is pretty daunting:
 
 .. _fig-pluto_medium_block_diagram:
@@ -101,9 +100,9 @@
 
    Pluto Simplified Block Diagram
 
 If the Pluto wasn't scary enough, the :adi:`Phased Array (Phaser) Development
 Platform <cn0566>` might be a step in that direction. It incorporates two
 :adi:`ADAR1000 <adiADAR1000>` beamformers, an :adi:`ADF4159 <AF4159>` Fast
 Waveform Generating, 13 GHz, Fractional-N Frequency Synthesizer and uses the
 Pluto as its IF digitizer. It's also got a :adi:`AD7291 <AD7291>` 8-Channel,
 I2C, 12-Bit SAR ADC with Temperature Sensor for basic monitoring; a simple
@@ -115,9 +114,9 @@
 .. figure:: 2-23-2023_4-37-00_pm.png
    :width: 600
 
    Phaser System Overview
 
 But - all of the phaser's devices work together, and by the time you finish
 this tutorial you'll be able to chip away at understanding how the individual
 devices work, and eventually, how they whole system works.
 
@@ -194,7 +193,7 @@
 computers - Raspberry Pi, BeagleBone, Zedboard, Arrow SoCkit, or any machine
 that boots from an SD card. There are lots of ways to burn images, but the most
 straightforward way is to use the standard Raspberry Pi Imager, available here:
-`Raspberry Pi OS (including Raspbery Pi Imager  <https://www.raspberrypi.com/software/>`__
+`Raspberry Pi OS (including Raspbery Pi Imager)  <https://www.raspberrypi.com/software/>`__
 
 There are instructions for Windows, Mac, and Linux. The imager also works on
 machines that encrypt data being written to external drives since it's writing
@@ -310,27 +309,50 @@
 board, Linux doesn't know about it yet because UNlike USB, PCI, SCSI, Firewire,
 HDMI, etc, SPI and I2C devices do not support enumeration. How do we tell the
 Linux kernel what we've connected to the expansion header? The answer is the
-"Device Tree Overlay"g
+"Device Tree Overlay".
 
 While you won't have to do anything more than editing a couple of files in this
 tutorial, it helps to understand a bit about what is going on under the
 surface. A "Device Tree" contains information about a system's hardware - what
 peripherals exist (like displays, memory, USB, Ethernet controllers, GPIO pins,
 etc.) A "Device Tree Overlay" contains information about additional connected
-hardware, like our ADXL3x5/LM75. :numref:`fig-device_tree` shows a screenshot
-of the ADXL345's overlay source.
+hardware, like our ADXL3x5/LM75. :numref:`code-device-tree` shows the devicetree
+of the ADXL345's overlay targetting the Raspberry Pi.
 It shows that the ADXL345 is connected to the SPI port, using
 the first CS signal (CS0), the maximum SPI clock frequency is 1MHz, and the
 interrupt signal is connected to Pin 19 (as shown in the connection diagram
 above.)
 
-.. _fig-device_tree:
+.. _code-device-tree:
 
-.. figure:: device_tree.png
-   :align: center
-   :width: 600
+.. code-block:: dts
+   :caption: Partial ADXL345 overlay source (dts)
+
+   // SPDX-License-Identifier: GPL-2.0
+   /dts-v1/;
+   /plugin/;
+
+   #include <dt-bindings/interrupt-controller/irq.h>
+
+   &{/} {
+        compatible = "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";
+   };
+
+   &spi0 {
+           adxl345: adxl345@0 {
+                   compatible = "adi,adxl345";
+                   reg = <0>;
+                   spi-max-frequency = <1000000>;
+                   spi-cpha;
+                   spi-cpol;
+                   interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+                   interrupt-parent = <&gpio>;
+           };
+   };
 
-   Partial ADXL345 overlay source (dts)
+   &spidev0 {
+           status = "disabled";
+   };
 
 The device tree source is then compiled into a "flattened" device tree that the
 Linux kernel reads directly. While this process is fairly straightforward, it's
@@ -342,12 +364,11 @@
 require a corresponding modification to the overlay.)
 
 For reference, here are the overlay source files for the three devices in this
-tutorial. These are in the Linux rpi-5.15.y branch, used for Kuiper Linux
-2022_r2 release:
+tutorial. These are in the Linux rpi-6.12.y branch:
 
-- `LM75 Device Tree Overlay <https://github.com/analogdevicesinc/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/rpi-lm75-overlay.dts>`__
-- `ADXL345 Device Tree Overlay <https://github.com/analogdevicesinc/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/rpi-adxl345-overlay.dts>`__
-- `ADXL355 Device Tree Overlay <https://github.com/analogdevicesinc/linux/blob/rpi-5.15.y/arch/arm/boot/dts/overlays/rpi-adxl355-overlay.dts>`__
+- `LM75 Device Tree Overlay <https://github.com/analogdevicesinc/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/rpi-lm75-overlay.dts>`__
+- `ADXL345 Device Tree Overlay <https://github.com/analogdevicesinc/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/rpi-adxl345-overlay.dts>`__
+- `ADXL355 Device Tree Overlay <https://github.com/analogdevicesinc/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/rpi-adxl355-overlay.dts>`__
 
 .. NOTE::
 
@@ -431,6 +452,21 @@
 Hello, ADXL345, ADXL355, or LM75!
 ---------------------------------
 
+.. caution::
+
+   The ADXL345 has two drivers:
+
+   - :git-linux:`drivers/iio/accel/adxl345.h` (``ADXL345_I2C/SPI``)
+   - :git-linux:`drivers/input/misc/adxl34x.h` (``INPUT_ADXL34X``)
+
+   And the IIO driver ``ADXL345_I2C/SPI`` cannot be selected if the inputs
+   ``INPUT_ADXL34X`` driver is selected! Make sure to do ``make menufconfig`` to
+   disable ``INPUT_ADXL34X``, then enable ``ADXL345_I2C/SPI``.
+
+   Kuiper and RPI ships with ``INPUT_ADXL34X`` compiled as a module.
+   Make sure to `blacklist <https://wiki.debian.org/KernelModuleBlacklisting>`__
+   the one that won't be used before attaching the devicetree.
+
 If all went well, Linux should have booted, found the ADXL3x5 or LM75, and
 loaded its driver. Run IIO Oscilloscope again. locate the DMM screen, check the
 ADXL345, select all channels, and click the triangular "play" button. You

docs/solutions/reference-designs/ad4052-ardz/index.rst

@@ -166,12 +166,12 @@ The source code for baremetal projects can be found at:
      - Documentation
    * - NUCLEO-H503RB
      - no-OS
-     - :git-no-OS:`ad405x:projects/ad405x`
-     - TODO ``:external+no-OS:doc:`docs <projects/ad405x>```
+     - :git-no-OS:`projects/ad405x`
+     - :external+no-OS:doc:`docs <projects/adc/ad405x>`
    * - NUCLEO-H563ZI
      - no-OS
-     - :git-no-OS:`ad405x:projects/ad405x`
-     - TODO ``:external+no-OS:doc:`docs <projects/ad405x>```
+     - :git-no-OS:`projects/ad405x`
+     - :external+no-OS:doc:`docs <projects/adc/ad405x>`
    * - SDP-K1
      - precision-converters-firmware
      - :git-precision-converters-firmware:`projects/ad405x_iio`