enabling ad9144 as a module

Hi, 

I'm trying to debug a setup with an ad9136 and to help with this, we're trying to build all the drivers associated with this chip as modules.

I was wondering if this has been tried before and if there are things I should be careful about.

At the moment, it looks like I might have an issue with the order in which the modules are loaded.

Thanks for your time, 

Liam

Top Replies

Parents
  • 0
    •  Analog Employees 
    on Aug 14, 2020 8:06 AM

    Hi Liam,

    We usually test the drivers by statically linking in the kernel. As you say some issues might arise with the order that you load the drivers. What drivers are you trying as a module and what is your exact order ?

    Regards,

    Mircea

  • Hi Mircea,

    At the moment, we're trying to boot with all drivers loaded as modules. Since we are using an AD9136-FMC-EBZ, this also includes the drivers for the ad9516-1.

    here is a list of the module names:

    - ad9517

    - ad9144

    - cf_axi_dds_drv

    axi_jesd204_tx

    - axi_adxcvr_drv

    - dma_axi_dmac

    As for the loading order, I'm relying on the devicetree to load everything automatically.

    Thanks,

    Liam

  • 0
    •  Analog Employees 
    on Aug 18, 2020 6:57 AM in reply to lvb

    Hi Liam,

    I saw that you said that you are using 2018.2 kernel. What HDL version are you using ? Is it the same 2018.2 ?

    You have to match both versions to be the same release otherwise you could have issues as the ones that you described.

    What device tree are you using ?

    Maybe the answer to these questions will point us in the right direction.

    Regards,

    Mircea

  • Hi Mircea,

    Yes, we are using the 2018.2 kernel along with the 2018.2 HDL and devicetree.

    This same setup was initially tested on a ZCU102 (all the same software/HDL versions) and we never encountered the boot hanging issue.

    Thanks,

    Liam

  • 0
    •  Analog Employees 
    on Aug 19, 2020 8:57 AM in reply to lvb

    With which version was this working before?

    Also, We're debugging using modules because the kernel seems to hang when accessing some AXI IP cores. Is that something you've seen before?

    It's not unheard of that in some setups the probe order can influence behavior.

    Usually for the IP cores to be able to read regs, the axi-clk needs to be enabled. This can be done in the driver, or the core can have this enabled by default.

    Maybe check that the clock is enabled (clk_prepare_enable() called) before reading anything from the IP core.

    One example is:

    https://github.com/analogdevicesinc/linux/commit/d78a31ef3583d58f8af9a6a385bc6308f897496c#diff-4024e54ca1569d5a29c5abc04ffbb1a2

    Someone else had some issue with a kernel hang (with our spi-axi-engine), because in some setups, the clock isn't enabled early in the probe.

    No idea if this also fixes this for you, but maybe do a check for this.

  • Hi FormerMember,

    With which version was this working before?

    Sorry for the confusion, I was initially testing on a ZCU102 with the default configuration (with all drivers builtin). With this setup, we managed to get everything working and were able to test using `jesd_status` and other custom test scripts.

    We then switched to a custom board (which has been tested extensively on other setups) and we noticed the kernel seems to hang when the axi-clkgen driver attempts its first AXI read. I disabled most PL nodes in the devicetree and got the board to boot into rootfs.

    As an attempt to debug the setup, we decided to build the drivers as modules and have them loaded automatically at boot. This effectively works around the boot hanging issue but lead us to a different set of issues, the order in which the drivers are loaded sometimes prevent the DAC from being initialized properly.

    To fix this I'm testing a patch of the cf_axi_dds where we check if the converter is setup earlier in the probe and return -EPROBE_DEFER if not.

    NOTE: all this was tested on our version of the kernel (based on adi's 2018.2 kernel) and vivado 2018.2.

    Maybe check that the clock is enabled (clk_prepare_enable() called) before reading anything from the IP core.

    Thanks for pointing that out, I'll give that a try as soon as possible.

    As another attempt to fix this, I was going to try to change the initcall priority of the driver setting up the axi-clk, would that make sense?

    Thanks again for your suggestions, I'll post the results as soon as possible,

    Liam 

  • Hi FormerMember,

    Maybe check that the clock is enabled (clk_prepare_enable() called) before reading anything from the IP core.

    Thanks for this suggestion, it seems to have fixed my issue! I've submitted a draft pull request to fix this in the axi-clkgen driver.

    Simply adding a reference to the axi_clk in the axi_quad_spi node fixed the issue with that driver too.

    Thanks again for your help,

    Liam

Reply Children