Post Go back to editing

ad9528 probe not bringing up vcc-supply on boot

Category: Software
Product Number: AD9528
Software Version: 2021_R1

Hello,

I have a ad9528 that is powered by a GPIO switched, fixed regulator.  The dts binding is shown below (note that regulator-boot-on and regulator-always-on were debugging attempts):

    vdda_3v3_2: vdda-3v3-2 {
        compatible = "regulator-fixed";
        regulator-name = "vdda_3v3_2";
        regulator-min-microvolt = <3300000>;
        regulator-max-microvolt = <3300000>;
        startup-delay-us = <150000>;
        gpio = <&gpio0 98 0>;
        enable-active-high;
        regulator-boot-on;
        regulator-always-on;
    };


The ad9528 has the following line in it:

    vcc-supply = <&vdda_3v3_2>;

When I boot the ad9528 tried to probe the device before the regulator comes online - this is, of course, problematic because the probe fails.  I have verified everything else in the devicetree is correct by manually enabling the GPIO in U-Boot, supplying power to the device before starting Linux.  When I do this the device probes successfully.

Is there something I am missing?  I looked at the driver code and it looks like it should be enabling the regulator before accessing the device.

Parents
  • This fixed it - Should I submit a patch?  This seems like a bug.

    diff --git a/drivers/iio/frequency/ad9528.c b/drivers/iio/frequency/ad9528.c
    index 5696cf191e35..e973f0f17452 100644
    --- a/drivers/iio/frequency/ad9528.c
    +++ b/drivers/iio/frequency/ad9528.c
    @@ -1642,12 +1642,18 @@ static int ad9528_probe(struct spi_device *spi)
            struct gpio_desc *status0_gpio;
            struct gpio_desc *status1_gpio;
            struct clk *clk;
    +       struct regulator *reg;
            int ret;
    
    +       reg = devm_regulator_get(&spi->dev, "vcc");
    +       if (PTR_ERR(reg) == -EPROBE_DEFER)
    +               return -EPROBE_DEFER;
    +
            clk = devm_clk_get(&spi->dev, NULL);
            if (PTR_ERR(clk) == -EPROBE_DEFER)
                    return -EPROBE_DEFER;
    
    +
            if (spi->dev.of_node)
                    pdata = ad9528_parse_dt(&spi->dev);
            else
    @@ -1670,7 +1676,7 @@ static int ad9528_probe(struct spi_device *spi)
    
            mutex_init(&st->lock);
    
    -       st->reg = devm_regulator_get(&spi->dev, "vcc");
    +       st->reg = reg;
            if (!IS_ERR(st->reg)) {
                    ret = regulator_enable(st->reg);
                    if (ret)
    

  • Should I submit a patch?

    No - I'll fix this slightly different using devm_regulator_get_optional().

    But thanks for pointing out!

    -Michael

  • I am not sure we are talking about the same issue - perhaps there are multiple issues around the "vcc" supply.

    The problem I had is that the "vcc" supply is not only required, but it must be enabled before the probe routine trying to communicate with the ad9528 as part of initialization. If the ad9528 is probed before the fixed-regulator then (I believe) all the regulator _get functions will return "EPROBE_DEFER" indicating that the fixed-regulator isn't available yet.  This means the ad9528 must defer until the regulator is available.

    It is entirely possible I am missing something here because this isn't a part of the kernel I am very familiar with. I took a quick glance at the code and I don't think this would correct my issue.

Reply
  • I am not sure we are talking about the same issue - perhaps there are multiple issues around the "vcc" supply.

    The problem I had is that the "vcc" supply is not only required, but it must be enabled before the probe routine trying to communicate with the ad9528 as part of initialization. If the ad9528 is probed before the fixed-regulator then (I believe) all the regulator _get functions will return "EPROBE_DEFER" indicating that the fixed-regulator isn't available yet.  This means the ad9528 must defer until the regulator is available.

    It is entirely possible I am missing something here because this isn't a part of the kernel I am very familiar with. I took a quick glance at the code and I don't think this would correct my issue.

Children