I am attempting to use the ADC on the SAMA5D2 device. I have 3.3V connected to the ADVREF and both VDDANA. There is nothing else currently giving me any trouble. I'm quickly running out of idea for where to look for a solution. Any suggestions would be greatly appreciated.

CONFIG_IIO=y
CONFIG_IIO_BUFFER=y
# CONFIG_IIO_BUFFER_CB is not set
CONFIG_IIO_KFIFO_BUF=y
CONFIG_IIO_TRIGGERED_BUFFER=y
# CONFIG_IIO_CONFIGFS is not set
CONFIG_IIO_TRIGGER=y
CONFIG_IIO_CONSUMERS_PER_TRIGGER=2
# CONFIG_IIO_SW_DEVICE is not set
# CONFIG_IIO_SW_TRIGGER is not set
CONFIG_AT91_ADC=y
CONFIG_AT91_SAMA5D2_ADC=y

(note: linux compilation fails if I disable CONFIG_AT91_ADC)

I have the following entries in my dts at the path /ahb/apb/
(stock SAMA5D2 include)

PeterT wrote:(lsmod only shows that line when I include the driver as a module instead of builtin)

Of course, because that command only reports loadable modules.
The sensible places to look for driver status are the system log (e.g. the `dmesg` command) (for any messages from the driver), the /proc/iomem file (for registration of the (well-behaved) device's register space), the /proc/interrupts file (for registration of the device's interrupt), and the /proc/devices file.

Thank you for the reply, blue_z. This is a custom board. Your suggestions gave me more places to look. dmesg makes no mention of the driver and neither do any of the other locations you suggested looking. I'm assuming that even if the hardware device isn't responding, there should be some message to that effect because I declare the device in the DTS. This would lead me to believe there is a problem with the device tree, the driver, or the kernel. Certainly the most likely is the device tree. Did I miss something obvious?

A quick inspection of the ADC driver indicates that there are about a dozen possibly silent error returns from probe().
You could hack the driver, and make every return from probe() verbose with a dev_err() output.
Or the Q&D hack is to boot with "initcall_debug" and "ignore_loglevel" in the kernel command line (e.g. the bootargs environment variable in U-Boot). This should indicate whether the init (and probe) of the ADC driver was executed or not, and reveal any return code.

Using your recommendations, blue_z, (ultimately adding dev_err calls to the driver) I found that the pmic was not getting initialized properly and so the ADC driver was failing due to unsuccessful returns from requesting regulator information. Thank you very much for your help on this issue.