On 1/13/25 6:18 PM, Jonathan Santos wrote:

On 01/12, Jonathan Cameron wrote:

quoted

On Sat, 11 Jan 2025 19:34:14 -0300
Jonathan Santos [off-list ref] wrote:

quoted

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? I can try to see if it works, but would it
handle the non-GPIO case? 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.

Daisy-chain mode (figure 131)?  In that case we normally end up with a single presented device
with a 'lot' of channels. (See the electric car style battery charging chips, those can
be chained in very large numbers!)

Actually, it is more like Figure 133 , but the premise is similar. We
have here a Quad setup.

quoted

Probably similar for figure 133 (which is a dual SPI setup) as the SPI clock must
be shared so we still see it over a single interface.

We could view them as a single device with multiple channels, and since
the goal is to read them simultaneously with buffered reads, some parameters
such as sampling frequency should be equal to all devices.

However, there are some implications: If we do the above, we have
limitations in the customization of the "channels", they would have
the same filter, frequency modulator and scale (we plan to add support
for ADAQ776x-1 series, which include PGA and AAF gain).

To customize them separetely, we would need to assert only the
corresponding chip select, which is only possible with different
instances, as far as I know.

FYI, I've been discussing with the HDL folks at ADI about how we could make a
multi-bus SPI controller, similar to controllers used for parallel SPI flash
memories that are used as a single logical device. So that is the solution I
am hoping for here. It would would allow a single IIO device instance for
multiple chips. But the SPI controller would allow addressing individual chips
for configuration and addressing all chips at the same time for reading sample
data.

quoted

If those are the only two options then keeping this within the driver is fine.
For daisy chain there are examples in tree and it normally means we have to
have a DT parameter that says how long the chain is, though we maybe can
do that with per channel nodes as well if those make sense here.

Jonathan

Those are the options in the datasheet and in hardware so far. I was 
considering other scenarios in case the user combine them differently.
I believe keping within the driver covers the main cases.