Post Go back to editing

ADRV9002 module driver, Error (14 EFAULT Bad address) when loaded with insmod

Category: Software
Product Number: ADRV9002
Software Version: 14 Mar 2022

Hi, I am getting the mentioned error when loading the adrv9002_drv.ko module.

It looks like it goes in error when it tries to open the SPI driver.

I am using this dts :


&spi0 {
   status = "okay";

   adrv9002_clkin: clkgen@0 {
       compatible = "fixed-clock";
       reg = <0>;
       status = "okay";

      /* Clock specific properties */
      // Clock provider   
       #clock-cells = <0>;
      clock-frequency = <57850000>;
      clock-output-names = "adrv9002_ext_refclk";
   };

   adc0_adrv9002: adrv9002-phy@0 {
       compatible = "adi,adrv9002";
        reg = <0>;
        interrupt-parent = <&gpio>;
        //interrupts = <122 IRQ_TYPE_EDGE_RISING>;

        spi-max-frequency = <20000000>;

        clocks = <&adrv9002_clkin 0>;
        clock-names = "adrv9002_ext_refclk";
        clock-output-names = "rx1_sampl_clk", "tx1_sampl_clk", "tdd1_intf_clk",
        "rx2_sampl_clk";
        #clock-cells = <1>;

        adi,channels {
           #address-cells = <1>;
           #size-cells = <0>;

           rx@0 {
              reg = <0>;
              adi,port = <0>;
              //adi,agc = <&agc0>;
              //adi,pinctrl = <&rx_pinctrl0>;
          };

           rx@1 {
               reg = <1>;
               adi,port = <0>;
               //adi,agc = <&agc0>;
                //adi,pinctrl = <&rx_pinctrl1>;
           };

           tx@0 {
               reg = <0>;
               adi,port = <1>;
              //adi,pinctrl = <&tx_pinctrl0>;
           };
        };
    };
};

   &adc0_adrv9002 {
    reset-gpios = <&gpio 30 0>;

Top Replies

  • Hi,

    Which kernel version are you using? The master or the release branch?

    I'm also seeing you removed the tx1 node from your devicetree and also removed the interrupt. Any reason for this?

    At last, dou you see any useful logs when running dmesg?

    - Nuno Sá

  • Hi Nuno, 

    I am running this driver on a proprietary platform, the linux version is 5.10.0

    I just reput the interrupt as active, the only reason was to avoid a compiler error message...but I fixed it.

    To tell all the truth, the probe function does not give any error written as it is.

    The problem is that in the /dev/iio dir I can just see the  device0, nothing more.

    So I tried to call 

                     adrv9002_post_init(phy);
    at the end of 
            adrv9002_register_axi_converter(....)
    But the dmesg :


    [ 111.419178] adrv9002 spi0.0: adrv9002_init, 4197: failed with "Failed to reset device and set SPI Config" 
    [ 111.433850] adrv9002: probe of spi0.0 failed with error -14

    I see the problem in adi_adrv9001_HwOpenNoReset(..) when it calls the function

             adi_adrv9001_hal_open(device->common.devHalInfo);

    I am not expert in Linux kernel space env...so sorry for the dummy question : do I need to write any spi initialization code inside the following ?

    int32_t linux_hw_open(void *devHalCfg)

    {

       return ADI_COMMON_ERR_OK;

    }

  • Hi,

    So I tried to call 

                     adrv9002_post_init(phy);
    at the end of 
            adrv9002_register_axi_converter(....)

    No, this should not be needed... Unless, are you defining the hdl blocks in devicetree? Look here...

    The post_init() function will only be called after this device probes. Look here...

    If you are not using these devices, that would explain why you are not seeing any devices probed. Moreover, note that the driver was only developed and tested to be used together with those hdl HW (look at the devicetree I posted in the link).

    - Nuno Sá

  • Hi Nuno, I removed the tx1 node because my target chip is the ADRV9003, that has not that tx1, but only the tx0. Moreover my target board has of course a different fpga. The dma is not managed at this device tree level, but internally by our fpga , we have just to pass a memory portion to it.

    I have not  the CONFIG_CF_AXI_ADC option enabled... in this case the 

    adrv9002_register_axi_converter(..)
    just calls: 
       spi_set_drvdata(spi, phy); /* Take care here */
    that does not allocate anything...
    Any suggestions ?
    Fabio 
  • Hi Nuno, I removed the tx1 node because my target chip is the ADRV9003, that has not that tx1, but only the tx0. Moreover my target board has of course a different fpga. The dma is not managed at this device tree level, but internally by our fpga , we have just to pass a memory portion to it.

    I have not  the CONFIG_CF_AXI_ADC option enabled... in this case the 

    Hmm, I see... Note that there are a lot of if's in here since I never really tried the driver to be used without CONFIG_CF_AXI_ADC. So yeah, nothing will really happen as the post_init() function won't be called. So yes, you need to manually call it but I'm not sure how that will work. You mentioned an issue with SPI which might indicate some issue with your HW design or devicetree. You need to make sure that the adrv9002 node is under the right spi controller...

    Other potential issue is that ADRV9003 is still not officially supported by the driver (nor it was ever tested) so I'm not sure how things will work. One thing that might be problematic is that the default profile used when the device probes is using both TXs so that you might need to generate a profile (using TES) for your needs (i.e, disabling tx2).

    - Nuno Sá

  • One more information...

    I got this line

    #include <dt-bindings/iio/adc/adi,adrv9002.h>

    from 

    where this come from ?

  • Not sure what you mean... That's an header file with defines that are used in the devicetree. It's a file present in our linux tree.

    - Nuno Sá

  • I have another question : I am thrown away from the probe function because the

    adi_adrv9001_spi_Verify() is failing....it looks like the ADRV9003 is not answering, or answering all 0xFF. Could it be that the setting  of the tx2 channel would put the chip in a bad state in relation to the spi ? I have difficulties to reach the spi  pins with a  oscilloscope probe, but I can see  my clock reaching the ADRV9002, and I know from the schematics that it is always on, it cannot be shut down. All the registers Vendor_Id and Scratch pad look 0xFF... I guess the ADI chip is not answering. Do you have any hint ?
  • adi_adrv9001_spi_Verify() is failing....it looks like the ADRV9003 is not answering, or answering all 0xFF. Could it be that the setting  of the tx2 channel would put the chip in a bad state in relation to the spi ?

    Well, I don't think so because 'adi_adrv9001_spi_Verify()' is one of the very fist things to be done in the device initialization (prior to any configuration based on the profile). So my best bets here would be:

    1) An actual HW issue;

    2) A devicetree issue. You need to make sure that you place the adrv9002 node inside the right spi controller node.

    Hopefully your issue is more related with 2) as that can be fixed without any HW changes...

    - Nuno Sá