On 1/11/25 4:34 PM, Jonathan Santos wrote:

On 01/07, David Lechner wrote:

quoted

On 1/7/25 9:24 AM, Jonathan Santos wrote:

quoted

Add adi,sync-in-spi property to enable synchronization over SPI.
This should be used in the case when the GPIO cannot provide a
pulse synchronous with the base MCLK signal.

User can choose between SPI, GPIO synchronization or neither of them,
but only if a external pulse can be provided, for example, by another
device in a multidevice setup.

While we are fixing up these bindings, we could add some more trivial things,
like power supplies.

Also, the interrupt property could use a description since the chip has multiple
output pins. I assume it means the /DRDY pin?

Right! Yes, the interrupt pin refers to the /DRDY.

quoted

quoted

Signed-off-by: Jonathan Santos <redacted>
---
 .../bindings/iio/adc/adi,ad7768-1.yaml        | 24 ++++++++++++++++++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
index 3ce59d4d065f..55cec27bfe60 100644
--- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml

@@ -47,6 +47,15 @@ properties:
       in any way, for example if the filter decimation rate changes.
       As the line is active low, it should be marked GPIO_ACTIVE_LOW.
 
+  adi,sync-in-spi:

If this is saying that SYNC_OUT is connected to SYNC_IN, then I think the name
should be something like adi,sync-in-sync-out. SPI seems irrelevant here since
we should just be describing how things are wired up, not how it is being used.

But if we also need to consider the case where SYNC_OUT of one chip is connected
to SYNC_IN of another chip, we might want to consider using trigger-source
bindings instead (recently standardized in dtschema).

Do you mean the trigger-sources used for LEDs?

Sort of. There is a more general version of this binding in dt-schema now [1].
But it is essentially the same binding.

[1]: https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/trigger/trigger-source.yaml

I can try to see if it works, but would it handle the non-GPIO case?

Since the ADC chip is both a trigger provider and a trigger consumer, it would
actually have both properties. A chip that has SYNC_OUT wired to SYNC_IN would
look something like this:

adc1: adc@0 {
  ...
  properties:
    #trigger-source-cells = <0>;
    trigger-sources = <&adc1>
}

While testing a multidevice setup, I found it simpler to 
have a single device to manage everything. It lets us toggle the GPIO or /SYNC_OUT
without referencing another device and makes simultaneous buffered reads easier.

Maybe we could stick to synchronization within the chip for now.

In the driver, sure. But for the DT bindings, we want to make sure it makes
sense for future use cases as well since it can't be changed later.