| Message ID | a4d0951fccade0f8e086416e94c4a38e1a21eb81.1744325346.git.Jonathan.Santos@analog.com |
|---|---|
| State | New |
| Headers | show |
| Series | iio: adc: ad7768-1: Add features, improvements, and fixes | expand |
On 4/11/25 10:58 AM, Jonathan Santos wrote: > The synchronization method using GPIO requires the generated pulse to be > truly synchronous with the base MCLK signal. When it is not possible to > do that in hardware, the datasheet recommends using synchronization over > SPI, where the generated pulse is already synchronous with MCLK. This > requires the SYNC_OUT pin to be connected to SYNC_IN pin. > > Use trigger-sources property to enable device synchronization over SPI > and to replace sync-in-gpios property for a gpio-trigger node. > > Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> > --- > v5 Changes: > * Allow omitting trigger-sources property. I didn't see this possibility mentioned in the dt-bindings patch. Maybe I missed something? > * include gpio-trigger to trigger-sources to replace adi,sync-in-gpios > property. > * Read trigger-sources cell value to differentiate the trigger type. > ... > drivers/iio/adc/ad7768-1.c | 100 ++++++++++++++++++++++++++++++++++--- > 1 file changed, 92 insertions(+), 8 deletions(-) > > diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c > index 179806f821be..aa60c55afd24 100644 > --- a/drivers/iio/adc/ad7768-1.c > +++ b/drivers/iio/adc/ad7768-1.c > @@ -100,6 +100,11 @@ > > #define AD7768_VCM_OFF 0x07 > > +enum ad7768_trigger_type { > + AD7768_TRIGGER_TYPE_GPIO, > + AD7768_TRIGGER_TYPE_DEV > +}; I assume this is supposed to correspond to the #trigger-source-cells argument? It would make sense to put this in a dt-bindings/iio/adc/adi,ad7768-1.h file in the dt-bindings patch so that it can also be used in .dts files. > +static int ad7768_set_sync_source(struct device *dev, struct ad7768_state *st) > +{ > + struct fwnode_reference_args args; > + struct fwnode_handle *fwnode = NULL; > + const char *value; > + int trigger_type, ret; > + > + /* > + * The AD7768-1 allows two primary methods for driving the SYNC_IN pin > + * to synchronize one or more devices: > + * 1. Using a GPIO to directly drive the SYNC_IN pin. > + * 2. Using a SPI command, where the SYNC_OUT pin generates a > + * synchronization pulse that loops back to the SYNC_IN pin. > + */ > + ret = fwnode_property_get_reference_args(dev_fwnode(dev), > + "trigger-sources", > + "#trigger-source-cells", > + 0, 0, &args); Since we have more than one possible trigger-source index, it could be helpful to create macros or an enum instead of hard-coding 0 here for the index arg. > + if (ret) { This ignores errors other than the property just being missing. Probably better would be to use device_property_present() first for this check then call fwnode_property_get_reference_args() later and return any error. > + /* > + * In the absence of trigger-sources property, enable self > + * synchronziation via SPI command. s/synchronziation/synchronization/ > + */ > + st->en_spi_sync = true; > + return 0; > + } > + > + trigger_type = args.args[0]; This is accessing args.args without checking args.nargs, so could be reading out of bounds. Also, we need to inspect args.fwnode first to see what type of trigger it is since the meaning of the args will depend on the compatible string of args.fwnode. The "gpio-trigger" has #trigger-source-cells = <0>; so this really would be reading uninitialized memory. > + fwnode = args.fwnode; > + if (!fwnode) > + return dev_err_probe(dev, -ENOENT, > + "Invalid or missing fwnode in 'trigger-sources'\n"); Is it really possible for this to happen without an error being returned by fwnode_property_get_reference_args()? > + > + switch (trigger_type) { > + case AD7768_TRIGGER_TYPE_GPIO: As mentioned in the dt-bindings review, this isn't a valid value. We should just check the compatible string directly. > + ret = fwnode_property_read_string(fwnode, "compatible", &value); > + if (ret) > + goto out_put_node; > + > + if (strcmp("gpio-trigger", value)) > + goto err_not_supp; Ideally we would have a trigger subsystem where we could just call a devm_trigger_source_get_gpio() function instead of this. But that is a bit beyond the scope of this patch series. :-) > + > + st->gpio_sync_in = fwnode_gpiod_get_index(fwnode, NULL, 0, Should be devm_fwnode_gpiod_get_index() so that the gpiod is released on driver removal. > + GPIOD_OUT_LOW, > + "sync-in"); > + if (IS_ERR(st->gpio_sync_in)) > + ret = PTR_ERR(st->gpio_sync_in); > + > + goto out_put_node; > + case AD7768_TRIGGER_TYPE_DEV: As mentioned in the dt-bindings review, this isn't a valid value. We can just check fwnode->dev directly earlier in this function. Then it is only safe to do trigger_type = args.args[0]; after that. And we should be checking that trigger_type is SYNC_OUT since that is the only supported self trigger for now. > + /* Only self synchronization is supported for now */ > + if (fwnode->dev == dev) { > + st->en_spi_sync = true; > + goto out_put_node; > + } > + > + goto err_not_supp; > + default: > + goto err_not_supp; > + } > + > +err_not_supp: > + ret = -EOPNOTSUPP; > + dev_err(dev, "Trigger-sources type not supported\n"); > +out_put_node: > + fwnode_handle_put(args.fwnode); > + return ret; > +} > + > static int ad7768_setup(struct iio_dev *indio_dev) > { > struct ad7768_state *st = iio_priv(indio_dev); > @@ -699,10 +784,9 @@ static int ad7768_setup(struct iio_dev *indio_dev) > return ret; > } > > - st->gpio_sync_in = devm_gpiod_get(&st->spi->dev, "adi,sync-in", I don't see where this function is moved to. If we remove it, wouldn't that break existing users depending on it? We can't expect everyone to update their devicetree to the new bindings. We could change it to devm_gpiod_get_optional() instead and only call ad7768_set_sync_source() if (!st->gpio_sync_in). > - GPIOD_OUT_LOW); > - if (IS_ERR(st->gpio_sync_in)) > - return PTR_ERR(st->gpio_sync_in); > + ret = ad7768_set_sync_source(&st->spi->dev, st); > + if (ret) > + return ret; > > /* Only create a Chip GPIO if flagged for it */ > if (device_property_read_bool(&st->spi->dev, "gpio-controller")) {
diff --git a/drivers/iio/adc/ad7768-1.c b/drivers/iio/adc/ad7768-1.c index 179806f821be..aa60c55afd24 100644 --- a/drivers/iio/adc/ad7768-1.c +++ b/drivers/iio/adc/ad7768-1.c @@ -100,6 +100,11 @@ #define AD7768_VCM_OFF 0x07 +enum ad7768_trigger_type { + AD7768_TRIGGER_TYPE_GPIO, + AD7768_TRIGGER_TYPE_DEV +}; + enum ad7768_conv_mode { AD7768_CONTINUOUS, AD7768_ONE_SHOT, @@ -209,6 +214,7 @@ struct ad7768_state { struct iio_trigger *trig; struct gpio_desc *gpio_sync_in; struct gpio_desc *gpio_reset; + bool en_spi_sync; const char *labels[ARRAY_SIZE(ad7768_channels)]; /* * DMA (thus cache coherency maintenance) may require the @@ -295,6 +301,19 @@ static const struct regmap_config ad7768_regmap24_config = { .max_register = AD7768_REG24_COEFF_DATA, }; +static int ad7768_send_sync_pulse(struct ad7768_state *st) +{ + if (st->en_spi_sync) + return regmap_write(st->regmap, AD7768_REG_SYNC_RESET, 0x00); + + if (st->gpio_sync_in) { + gpiod_set_value_cansleep(st->gpio_sync_in, 1); + gpiod_set_value_cansleep(st->gpio_sync_in, 0); + } + + return 0; +} + static int ad7768_set_mode(struct ad7768_state *st, enum ad7768_conv_mode mode) { @@ -391,10 +410,7 @@ static int ad7768_set_dig_fil(struct ad7768_state *st, return ret; /* A sync-in pulse is required every time the filter dec rate changes */ - gpiod_set_value(st->gpio_sync_in, 1); - gpiod_set_value(st->gpio_sync_in, 0); - - return 0; + return ad7768_send_sync_pulse(st); } static int ad7768_gpio_direction_input(struct gpio_chip *chip, unsigned int offset) @@ -669,6 +685,75 @@ static const struct iio_info ad7768_info = { .debugfs_reg_access = &ad7768_reg_access, }; +static int ad7768_set_sync_source(struct device *dev, struct ad7768_state *st) +{ + struct fwnode_reference_args args; + struct fwnode_handle *fwnode = NULL; + const char *value; + int trigger_type, ret; + + /* + * The AD7768-1 allows two primary methods for driving the SYNC_IN pin + * to synchronize one or more devices: + * 1. Using a GPIO to directly drive the SYNC_IN pin. + * 2. Using a SPI command, where the SYNC_OUT pin generates a + * synchronization pulse that loops back to the SYNC_IN pin. + */ + ret = fwnode_property_get_reference_args(dev_fwnode(dev), + "trigger-sources", + "#trigger-source-cells", + 0, 0, &args); + if (ret) { + /* + * In the absence of trigger-sources property, enable self + * synchronziation via SPI command. + */ + st->en_spi_sync = true; + return 0; + } + + trigger_type = args.args[0]; + fwnode = args.fwnode; + if (!fwnode) + return dev_err_probe(dev, -ENOENT, + "Invalid or missing fwnode in 'trigger-sources'\n"); + + switch (trigger_type) { + case AD7768_TRIGGER_TYPE_GPIO: + ret = fwnode_property_read_string(fwnode, "compatible", &value); + if (ret) + goto out_put_node; + + if (strcmp("gpio-trigger", value)) + goto err_not_supp; + + st->gpio_sync_in = fwnode_gpiod_get_index(fwnode, NULL, 0, + GPIOD_OUT_LOW, + "sync-in"); + if (IS_ERR(st->gpio_sync_in)) + ret = PTR_ERR(st->gpio_sync_in); + + goto out_put_node; + case AD7768_TRIGGER_TYPE_DEV: + /* Only self synchronization is supported for now */ + if (fwnode->dev == dev) { + st->en_spi_sync = true; + goto out_put_node; + } + + goto err_not_supp; + default: + goto err_not_supp; + } + +err_not_supp: + ret = -EOPNOTSUPP; + dev_err(dev, "Trigger-sources type not supported\n"); +out_put_node: + fwnode_handle_put(args.fwnode); + return ret; +} + static int ad7768_setup(struct iio_dev *indio_dev) { struct ad7768_state *st = iio_priv(indio_dev); @@ -699,10 +784,9 @@ static int ad7768_setup(struct iio_dev *indio_dev) return ret; } - st->gpio_sync_in = devm_gpiod_get(&st->spi->dev, "adi,sync-in", - GPIOD_OUT_LOW); - if (IS_ERR(st->gpio_sync_in)) - return PTR_ERR(st->gpio_sync_in); + ret = ad7768_set_sync_source(&st->spi->dev, st); + if (ret) + return ret; /* Only create a Chip GPIO if flagged for it */ if (device_property_read_bool(&st->spi->dev, "gpio-controller")) {
The synchronization method using GPIO requires the generated pulse to be truly synchronous with the base MCLK signal. When it is not possible to do that in hardware, the datasheet recommends using synchronization over SPI, where the generated pulse is already synchronous with MCLK. This requires the SYNC_OUT pin to be connected to SYNC_IN pin. Use trigger-sources property to enable device synchronization over SPI and to replace sync-in-gpios property for a gpio-trigger node. Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> --- v5 Changes: * Allow omitting trigger-sources property. * include gpio-trigger to trigger-sources to replace adi,sync-in-gpios property. * Read trigger-sources cell value to differentiate the trigger type. v4 Changes: * None. v3 Changes: * Fixed args.fwnode leakage in the trigger-sources parsing. * Synchronization over spi is enabled when the trigger-sources references the own device. * Synchronization is kept within the device, and return error if the gpio is not defined and the trigger-sources reference does not match the current device. v2 Changes: * Synchronization via SPI is enabled when the Sync GPIO is not defined. * now trigger-sources property indicates the synchronization provider or main device. The main device will be used to drive the SYNC_IN when requested (via GPIO or SPI). --- drivers/iio/adc/ad7768-1.c | 100 ++++++++++++++++++++++++++++++++++--- 1 file changed, 92 insertions(+), 8 deletions(-)