Post Go back to editing

ad7785 device driver dts

I’m trying to use the ad7793 device driver to control an ad7785 that is connected to our custom board. When we use the spidev driver it seems to work fine and we get valid data although we get one strange behavior. The Device ID that is returned when requested is 3 yet the data sheet says we should get 0xb?

Below are the changes we’ve made to use the ad7793 driver but I’m unsure of some of the values needed. The driver loads but it always fails to return the correct device ID when requested. I was unsure what to put in for some of the values so could someone look over the changes and give us feedback. Thanks. Rob

changes to ad7793.c to add platform data

static int ad7793_probe(struct spi_device *spi)


  const struct ad7793_platform_data *pdata = spi->dev.platform_data;

  struct ad7793_state *st;

  struct iio_dev *indio_dev;

  int ret, vref_mv = 0;

  // added to use default platform data

  if (!pdata) {

    dev_err(&spi->dev, "no platform data? using default\n");

    pdata = &ad7793_default_pdata;



static struct ad7793_platform_data ad7793_default_pdata = {

  .clock_src = AD7793_CLK_SRC_EXT,

  //.burnout_current = false,

  //.boost_enable = false,

  .buffered = true,

  .unipolar = false,

  .refsel = AD7793_REFSEL_INTERNAL,

  //.bias_voltage = AD7793_BIAS_VOLTAGE_DISABLED,

  //.exitation_current = AD7793_IX_DISABLED,

  //.current_source_direction = AD7793_IEXEC1_IOUT2_IEXEC2_IOUT1


section our board am33xx.dtsi with spi master

    spi1: spi@481a0000 {

      compatible = "ti,omap4-mcspi";

      #address-cells = <1>;

      #size-cells = <0>;

      reg = <0x481a0000 0x400>;

      interrupts = <125>;

      ti,spi-num-cs = <2>;

      ti,hwmods = "spi1";

      dmas = <&edma 42

        &edma 43

        &edma 44

        &edma 45>;

      dma-names = "tx0", "rx0", "tx1", "rx1";

      status = "disabled";


section of ourboard.dts with spi updates to load the ad7793(ad7785) driver

&spi1 {

  status = "okay";

  pinctrl-names = "default", "sleep";

  pinctrl-0 = <&spi1_pins_default>;

  pinctrl-1 = <&spi1_pins_sleep>;


  spidev0: spi@0 {

    /*compatible = "spidev";*/

    compatible = "ad7785";

    interrupts = <1>; // not sure what this should be

    reg = <0>;

    spi-max-frequency = <500000>;



    //spi-lsb-first; // not sure what this should be, enabled or not


  spidev1: spi@1 {

    compatible = "spidev";

    reg = <1>;

    spi-max-frequency = <16000000>;



  • Hi,

    It's a bit strange that the ID register returns a incorrect value, but if the driver behaves correctly otherwise I'd recommend to remove the check for now.

    As for the configuration settings this depends on how the device is connected on your board. For a description of all the parameters and their possible values have a look at the documentation. If you have a specific question regarding one or more of the parameters let me know.

    The IRQ is used to indicate a conversion completion and is required when reading sample data from the device. The physical IRQ signal is multiplexed over the same pin as DOUT signal. Typically you'd connect that pin to two pins on your host side system. Once to the SPI MISO pin and once to a interrupt capable pin. You need to provide a reference to this interrupt pin to the driver so it can register itself as a consumer to that interrupt.

    - Lars

  • Thanks Lars,

    Looks like we are missing the second pin. Need to fix that before we can move on.

    Also, can you look at the doc for for the EVAL-AD7785 . We noticed that on page 8, figure 5 shows an ID register value of 0x83. This is the same (invalid) value we are getting when we read the device ID register via spidev. The driver and datasheet expects and says we should get an 0xB. More oddly the status register in the screenshot shows a 0xB which is what I expect the device ID to be. Can you explain this or is it just coincidence?


  • Hi,

    I've checked with the applications engineer for the part and they confirmed that the product ID in the datasheet is wrong.

    I've created a patch that fixes the driver. Let me know whether it works for you.

    Thanks for letting us know the issue.

    - Lars