In addition to GPIO synchronization, The AD7768-1 also supports
synchronization over SPI, which use is recommended when the GPIO
cannot provide a pulse synchronous with the base MCLK signal. It
consists of looping back the SYNC_OUT to the SYNC_IN pin and send
a command via SPI to trigger the synchronization.
Introduce the 'trigger-sources' property to support SPI-based
synchronization, along with additional optional entries for the SPI
offload trigger and the START signal via GPIO3.
While at it, add description to the interrupts property.
Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com>
---
v5 Changes:
* Include START pin and DRDY in the trigger-sources description.
* Fixed "#trigger-source-cells" value and description.
* sync-in-gpios is represented in the trigger-sources property.
v4 Changes:
* none
v3 Changes:
* Fixed dt-bindings errors.
* Trigger-source is set as an alternative to sync-in-gpios, so we
don't break the previous ABI.
* increased maxItems from trigger-sources to 2.
v2 Changes:
* Patch added as replacement for adi,sync-in-spi patch.
* addressed the request for a description to interrupts property.
---
.../bindings/iio/adc/adi,ad7768-1.yaml | 38 +++++++++++++++++--
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
index 3ce59d4d065f..4c58dbe8f749 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
@@ -26,7 +26,30 @@ properties:
clock-names:
const: mclk
+ trigger-sources:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ minItems: 1
+ maxItems: 3
+ description: |
+ A list of phandles referencing trigger source devices or GPIOs.
+ Supports up to three entries, each representing a different type of
+ trigger:
+
+ - First entry specifies the device responsible for driving the
+ synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios.
+ This can be a `gpio-trigger` or another `ad7768-1` device. If the
+ device's own SYNC_OUT pin is internally connected to its SYNC_IN pin,
+ reference the device itself or omit this property.
+ - Second entry optionally defines a GPIO3 pin used as a START signal trigger.
+ - Third entry specifies a GPIO line to act as a trigger for SPI offload.
+
+ Use the accompanying trigger source cell to identify the type of each entry.
+
interrupts:
+ description:
+ Specifies the interrupt line associated with the ADC. This refers
+ to the DRDY (Data Ready) pin, which signals when conversion results are
+ available.
maxItems: 1
'#address-cells':
@@ -57,6 +80,15 @@ properties:
"#io-channel-cells":
const: 1
+ "#trigger-source-cells":
+ description: |
+ Indicates the trigger source type for each entry:
+ 0 = Synchronization GPIO-based trigger
+ 1 = Synchronization device trigger (e.g., another ad7768-1)
+ 2 = GPIO3 pin acting as START signal
+ 3 = DRDY pin acting as SPI offload trigger
+ const: 1
+
required:
- compatible
- reg
@@ -65,7 +97,6 @@ required:
- vref-supply
- spi-cpol
- spi-cpha
- - adi,sync-in-gpios
patternProperties:
"^channel@([0-9]|1[0-5])$":
@@ -99,7 +130,7 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- adc@0 {
+ adc0: adc@0 {
compatible = "adi,ad7768-1";
reg = <0>;
spi-max-frequency = <2000000>;
@@ -108,7 +139,8 @@ examples:
vref-supply = <&adc_vref>;
interrupts = <25 IRQ_TYPE_EDGE_RISING>;
interrupt-parent = <&gpio>;
- adi,sync-in-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&adc0 1>;
+ #trigger-source-cells = <1>;
reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
clocks = <&ad7768_mclk>;
clock-names = "mclk";
--
2.34.1On 4/11/25 10:56 AM, Jonathan Santos wrote: > In addition to GPIO synchronization, The AD7768-1 also supports > synchronization over SPI, which use is recommended when the GPIO > cannot provide a pulse synchronous with the base MCLK signal. It > consists of looping back the SYNC_OUT to the SYNC_IN pin and send > a command via SPI to trigger the synchronization. > > Introduce the 'trigger-sources' property to support SPI-based > synchronization, along with additional optional entries for the SPI > offload trigger and the START signal via GPIO3. > > While at it, add description to the interrupts property. > > Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> > --- ... > @@ -57,6 +80,15 @@ properties: > "#io-channel-cells": > const: 1 > > + "#trigger-source-cells": > + description: | > + Indicates the trigger source type for each entry: > + 0 = Synchronization GPIO-based trigger > + 1 = Synchronization device trigger (e.g., another ad7768-1) > + 2 = GPIO3 pin acting as START signal > + 3 = DRDY pin acting as SPI offload trigger > + const: 1 > + 0 and 1 don't sound like trigger outputs that this ADC is providing, so don't seem appropriate here. But the SYNC_OUT pin is missing from this list. Also, outputs could be used to trigger anything, not just SPI offload, so don't need to mention that.
On 04/11, David Lechner wrote:
> On 4/11/25 10:56 AM, Jonathan Santos wrote:
> > In addition to GPIO synchronization, The AD7768-1 also supports
> > synchronization over SPI, which use is recommended when the GPIO
> > cannot provide a pulse synchronous with the base MCLK signal. It
> > consists of looping back the SYNC_OUT to the SYNC_IN pin and send
> > a command via SPI to trigger the synchronization.
> >
> > Introduce the 'trigger-sources' property to support SPI-based
> > synchronization, along with additional optional entries for the SPI
> > offload trigger and the START signal via GPIO3.
> >
> > While at it, add description to the interrupts property.
> >
> > Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com>
> > ---
>
> ...
>
> > @@ -57,6 +80,15 @@ properties:
> > "#io-channel-cells":
> > const: 1
> >
> > + "#trigger-source-cells":
> > + description: |
> > + Indicates the trigger source type for each entry:
> > + 0 = Synchronization GPIO-based trigger
> > + 1 = Synchronization device trigger (e.g., another ad7768-1)
> > + 2 = GPIO3 pin acting as START signal
> > + 3 = DRDY pin acting as SPI offload trigger
> > + const: 1
> > +
>
> 0 and 1 don't sound like trigger outputs that this ADC is providing, so don't
> seem appropriate here. But the SYNC_OUT pin is missing from this list.
>
> Also, outputs could be used to trigger anything, not just SPI offload, so don't
> need to mention that.
You mean like this:
...
"#trigger-source-cells":
description: |
Cell indicates the trigger output signal: 0 = SYNC_OUT, 1 = GPIO3,
2 = DRDY.
const: 1
...
It would be like interfacing those output pins for a generic trigger
usage?
>
On 4/16/25 7:22 PM, Jonathan Santos wrote: > On 04/11, David Lechner wrote: >> On 4/11/25 10:56 AM, Jonathan Santos wrote: >>> In addition to GPIO synchronization, The AD7768-1 also supports >>> synchronization over SPI, which use is recommended when the GPIO >>> cannot provide a pulse synchronous with the base MCLK signal. It >>> consists of looping back the SYNC_OUT to the SYNC_IN pin and send >>> a command via SPI to trigger the synchronization. >>> >>> Introduce the 'trigger-sources' property to support SPI-based >>> synchronization, along with additional optional entries for the SPI >>> offload trigger and the START signal via GPIO3. >>> >>> While at it, add description to the interrupts property. >>> >>> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> >>> --- >> >> ... >> >>> @@ -57,6 +80,15 @@ properties: >>> "#io-channel-cells": >>> const: 1 >>> >>> + "#trigger-source-cells": >>> + description: | >>> + Indicates the trigger source type for each entry: >>> + 0 = Synchronization GPIO-based trigger >>> + 1 = Synchronization device trigger (e.g., another ad7768-1) >>> + 2 = GPIO3 pin acting as START signal >>> + 3 = DRDY pin acting as SPI offload trigger >>> + const: 1 >>> + >> >> 0 and 1 don't sound like trigger outputs that this ADC is providing, so don't >> seem appropriate here. But the SYNC_OUT pin is missing from this list. >> >> Also, outputs could be used to trigger anything, not just SPI offload, so don't >> need to mention that. > > You mean like this: > > ... > "#trigger-source-cells": > description: | > Cell indicates the trigger output signal: 0 = SYNC_OUT, 1 = GPIO3, > 2 = DRDY. > > const: 1 > ... > > It would be like interfacing those output pins for a generic trigger > usage? > >> Yes this looks correct now. I don't think this is the case, but in general, if GPIO3 could be programmed to have different trigger signals, then we would need a 2nd cell. But IIRC, it can only be the START signal, so 1 cell should be sufficient in this case.
On 4/11/25 10:56 AM, Jonathan Santos wrote: > In addition to GPIO synchronization, The AD7768-1 also supports > synchronization over SPI, which use is recommended when the GPIO > cannot provide a pulse synchronous with the base MCLK signal. It > consists of looping back the SYNC_OUT to the SYNC_IN pin and send > a command via SPI to trigger the synchronization. > > Introduce the 'trigger-sources' property to support SPI-based > synchronization, along with additional optional entries for the SPI > offload trigger and the START signal via GPIO3. > > While at it, add description to the interrupts property. > > Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> > --- > v5 Changes: > * Include START pin and DRDY in the trigger-sources description. > * Fixed "#trigger-source-cells" value and description. > * sync-in-gpios is represented in the trigger-sources property. > > v4 Changes: > * none > > v3 Changes: > * Fixed dt-bindings errors. > * Trigger-source is set as an alternative to sync-in-gpios, so we > don't break the previous ABI. > * increased maxItems from trigger-sources to 2. > > v2 Changes: > * Patch added as replacement for adi,sync-in-spi patch. > * addressed the request for a description to interrupts property. > --- > .../bindings/iio/adc/adi,ad7768-1.yaml | 38 +++++++++++++++++-- > 1 file changed, 35 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml > index 3ce59d4d065f..4c58dbe8f749 100644 > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml > @@ -26,7 +26,30 @@ properties: > clock-names: > const: mclk > > + trigger-sources: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + minItems: 1 > + maxItems: 3 > + description: | > + A list of phandles referencing trigger source devices or GPIOs. I don't think a gpio phandle should be directly allowed. Only a trigger source provider (something with #trigger-source-cells). > + Supports up to three entries, each representing a different type of > + trigger: > + > + - First entry specifies the device responsible for driving the > + synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios. > + This can be a `gpio-trigger` or another `ad7768-1` device. If the > + device's own SYNC_OUT pin is internally connected to its SYNC_IN pin, > + reference the device itself or omit this property. > + - Second entry optionally defines a GPIO3 pin used as a START signal trigger. > + - Third entry specifies a GPIO line to act as a trigger for SPI offload. SPI offload is part of the SPI controller, not the ADC chip, so doesn't make sense to have that binding here. In that case, the ADC is the trigger-source provider, not consumer.
On 04/11, David Lechner wrote:
> On 4/11/25 10:56 AM, Jonathan Santos wrote:
> > In addition to GPIO synchronization, The AD7768-1 also supports
> > synchronization over SPI, which use is recommended when the GPIO
> > cannot provide a pulse synchronous with the base MCLK signal. It
> > consists of looping back the SYNC_OUT to the SYNC_IN pin and send
> > a command via SPI to trigger the synchronization.
> >
> > Introduce the 'trigger-sources' property to support SPI-based
> > synchronization, along with additional optional entries for the SPI
> > offload trigger and the START signal via GPIO3.
> >
> > While at it, add description to the interrupts property.
> >
> > Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com>
> > ---
> > v5 Changes:
> > * Include START pin and DRDY in the trigger-sources description.
> > * Fixed "#trigger-source-cells" value and description.
> > * sync-in-gpios is represented in the trigger-sources property.
> >
> > v4 Changes:
> > * none
> >
> > v3 Changes:
> > * Fixed dt-bindings errors.
> > * Trigger-source is set as an alternative to sync-in-gpios, so we
> > don't break the previous ABI.
> > * increased maxItems from trigger-sources to 2.
> >
> > v2 Changes:
> > * Patch added as replacement for adi,sync-in-spi patch.
> > * addressed the request for a description to interrupts property.
> > ---
> > .../bindings/iio/adc/adi,ad7768-1.yaml | 38 +++++++++++++++++--
> > 1 file changed, 35 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
> > index 3ce59d4d065f..4c58dbe8f749 100644
> > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
> > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
> > @@ -26,7 +26,30 @@ properties:
> > clock-names:
> > const: mclk
> >
> > + trigger-sources:
> > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > + minItems: 1
> > + maxItems: 3
> > + description: |
> > + A list of phandles referencing trigger source devices or GPIOs.
>
> I don't think a gpio phandle should be directly allowed. Only a trigger
> source provider (something with #trigger-source-cells).
>
Sorry, I meant gpio-trigger, but I phrased it incorrectly.
> > + Supports up to three entries, each representing a different type of
> > + trigger:
> > +
> > + - First entry specifies the device responsible for driving the
> > + synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios.
> > + This can be a `gpio-trigger` or another `ad7768-1` device. If the
> > + device's own SYNC_OUT pin is internally connected to its SYNC_IN pin,
> > + reference the device itself or omit this property.
> > + - Second entry optionally defines a GPIO3 pin used as a START signal trigger.
> > + - Third entry specifies a GPIO line to act as a trigger for SPI offload.
>
> SPI offload is part of the SPI controller, not the ADC chip, so doesn't
> make sense to have that binding here. In that case, the ADC is the
> trigger-source provider, not consumer.
Right! Maybe a silly question, but this means we would have then two trigger-sources
defined, one in the spi controller node and other in the adc node, right? like
this:
spi_controller: spi@44a00000 {
...
trigger-sources = <&offload_trigger_source>;
...
adc0@ {
...
trigger-sources = <&sync_trigger_source>;
#trigger-source-cells = <1>;
...
}
}
>
>
>
On 4/16/25 7:08 PM, Jonathan Santos wrote:
> On 04/11, David Lechner wrote:
>> On 4/11/25 10:56 AM, Jonathan Santos wrote:
>>> In addition to GPIO synchronization, The AD7768-1 also supports
>>> synchronization over SPI, which use is recommended when the GPIO
>>> cannot provide a pulse synchronous with the base MCLK signal. It
>>> consists of looping back the SYNC_OUT to the SYNC_IN pin and send
>>> a command via SPI to trigger the synchronization.
>>>
>>> Introduce the 'trigger-sources' property to support SPI-based
>>> synchronization, along with additional optional entries for the SPI
>>> offload trigger and the START signal via GPIO3.
>>>
>>> While at it, add description to the interrupts property.
>>>
>>> Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com>
>>> ---
...
>>> + Supports up to three entries, each representing a different type of
>>> + trigger:
>>> +
>>> + - First entry specifies the device responsible for driving the
>>> + synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios.
>>> + This can be a `gpio-trigger` or another `ad7768-1` device. If the
>>> + device's own SYNC_OUT pin is internally connected to its SYNC_IN pin,
>>> + reference the device itself or omit this property.
>>> + - Second entry optionally defines a GPIO3 pin used as a START signal trigger.
>>> + - Third entry specifies a GPIO line to act as a trigger for SPI offload.
>>
>> SPI offload is part of the SPI controller, not the ADC chip, so doesn't
>> make sense to have that binding here. In that case, the ADC is the
>> trigger-source provider, not consumer.
>
> Right! Maybe a silly question, but this means we would have then two trigger-sources
> defined, one in the spi controller node and other in the adc node, right? like
> this:
>
> spi_controller: spi@44a00000 {
> ...
> trigger-sources = <&offload_trigger_source>;
> ...
> adc0@ {
> ...
> trigger-sources = <&sync_trigger_source>;
> #trigger-source-cells = <1>;
> ...
> }
> }
Yes, this looks correct. And for the case of SYNC_OUT connected to SYNC_IN on
the ADC itself, we could omit trigger-sources = <&sync_trigger_source>;.
On Fri, Apr 11, 2025 at 12:56:17PM -0300, Jonathan Santos wrote: > In addition to GPIO synchronization, The AD7768-1 also supports > synchronization over SPI, which use is recommended when the GPIO > cannot provide a pulse synchronous with the base MCLK signal. It > consists of looping back the SYNC_OUT to the SYNC_IN pin and send > a command via SPI to trigger the synchronization. > > Introduce the 'trigger-sources' property to support SPI-based > synchronization, along with additional optional entries for the SPI > offload trigger and the START signal via GPIO3. > > While at it, add description to the interrupts property. > > Signed-off-by: Jonathan Santos <Jonathan.Santos@analog.com> > --- > v5 Changes: > * Include START pin and DRDY in the trigger-sources description. > * Fixed "#trigger-source-cells" value and description. > * sync-in-gpios is represented in the trigger-sources property. > > v4 Changes: > * none > > v3 Changes: > * Fixed dt-bindings errors. > * Trigger-source is set as an alternative to sync-in-gpios, so we > don't break the previous ABI. > * increased maxItems from trigger-sources to 2. > > v2 Changes: > * Patch added as replacement for adi,sync-in-spi patch. > * addressed the request for a description to interrupts property. > --- > .../bindings/iio/adc/adi,ad7768-1.yaml | 38 +++++++++++++++++-- > 1 file changed, 35 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml > index 3ce59d4d065f..4c58dbe8f749 100644 > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml > @@ -26,7 +26,30 @@ properties: > clock-names: > const: mclk > > + trigger-sources: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + minItems: 1 > + maxItems: 3 > + description: | > + A list of phandles referencing trigger source devices or GPIOs. > + Supports up to three entries, each representing a different type of > + trigger: > + > + - First entry specifies the device responsible for driving the > + synchronization (SYNC_IN) pin, as an alternative to adi,sync-in-gpios. > + This can be a `gpio-trigger` or another `ad7768-1` device. If the > + device's own SYNC_OUT pin is internally connected to its SYNC_IN pin, > + reference the device itself or omit this property. > + - Second entry optionally defines a GPIO3 pin used as a START signal trigger. > + - Third entry specifies a GPIO line to act as a trigger for SPI offload. > + > + Use the accompanying trigger source cell to identify the type of each entry. > + > interrupts: > + description: > + Specifies the interrupt line associated with the ADC. This refers > + to the DRDY (Data Ready) pin, which signals when conversion results are > + available. > maxItems: 1 > > '#address-cells': > @@ -57,6 +80,15 @@ properties: > "#io-channel-cells": > const: 1 > > + "#trigger-source-cells": > + description: | > + Indicates the trigger source type for each entry: > + 0 = Synchronization GPIO-based trigger > + 1 = Synchronization device trigger (e.g., another ad7768-1) > + 2 = GPIO3 pin acting as START signal > + 3 = DRDY pin acting as SPI offload trigger I think the description here makes little sense, when the value is required to be 1 by the following line. If these are permitted values for things consuming this adc as a trigger source, you should specify that IMO.
© 2016 - 2025 Red Hat, Inc.