Re: [PATCH v1 08/13] dt-bindings: iio: adc: adi,ad4134: Document SPI connection mode

[Jonathan Cameron <jic23@kernel.org>]

On Wed, 9 Sep 2026 12:17:37 -0300
Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:

> On 09/06, Jonathan Cameron wrote:
> > On Fri, 4 Sep 2026 19:06:44 -0300
> > Marcelo Schmitt <marcelo.schmitt1@gmail.com> wrote:
> >   
> > > On 09/04, Marcelo Schmitt wrote:  
> > > > On 09/03, Conor Dooley wrote:    
> > > > > On Wed, Sep 02, 2026 at 02:24:02PM -0300, Marcelo Schmitt wrote:    
> > > > > > Document how AD4134 chips are connected to the host SPI controller
> > > > > > according to different wiring configurations.
> > > > > > 
> > > > > > Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
> > > > > > ---
> > > > > >  .../bindings/iio/adc/adi,ad4134.yaml          | 22 +++++++++++++++++++
> > > > > >  1 file changed, 22 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad4134.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad4134.yaml
> > > > > > index ea6d7e026419..d843c02a394a 100644
> > > > > > --- a/Documentation/devicetree/bindings/iio/adc/adi,ad4134.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad4134.yaml
> > > > > > @@ -131,6 +131,28 @@ properties:
> > > > > >      enum: [ free-running, gated ]
> > > > > >      default: gated
> > > > > >  
> > > > > > +  adi,spi-mode:
> > > > > > +    $ref: /schemas/types.yaml#/definitions/string
> > > > > > +    enum: [ no-cs, 4-wire, one-channel-chain, two-channel-chain ]
> > > > > > +    description: |
> > > > > > +      This property indicates the SPI wiring configuration.
> > > > > > +
> > > > > > +      When this property is omitted, it is assumed that the device is using
> > > > > > +      'no-cs' wiring. When this property is present, it indicates that the
> > > > > > +      device is using one of the following wiring configurations:    
> > > > ...    
> > > > > I'd also really appreciate a dts example for a system
> > > > > with one-channel-chain or two-channel-chain looks, given the second
> > > > > device may require different supplies etc. I have no impression in my
> > > > > head of how the dt would be constructed, so I'd like to see wht you have
> > > > > in mind.    
> > > >     
> > > ...
> > > 
> > > Realized what I said doesn't make much sense. The peripherals can all have
> > > the same configuration and thus share CS, SCLK, and controller SDO. The wiring
> > > would be like the following  
> > 
> > That mux in the middle is controlled how?  
> 
> The mux is controlled by a GPIO. I ended up drawing the GPIO among SPI lines in the
> connection diagram but the mux controll signal is not part of the SPI controller.

Ok. So we are effectively making that mux part of of the ad4134 controlled hardware.
I guess I don't mind that but shout about it a lot in the driver as anyone coming
in will wonder where the magic mux appeared from :)

> 
> > I'd assume we still have separate chip selects and SDO/SDI shared. So I'd expect
> > those to be on one SPI bus and the data to be going into separate buses
> > (maybe all that can be hidden in the backend, not sure).
> > 
> > Or are you suggesting we are just letting all the chained devices see the
> > same register writes?  That might work I guess with no ability to read any register
> > state back other than for first device.  
> Correct, that's the proposed configuration for daisy-chaining. Since all
> peripherals will receive the same write commands they shall all retain the same
> register configurations (except maybe for error indication registers). Reading
> from the topmost device in the chain would be enough to figure out the status
> of the other chained devices.

It's errors that concern me about this.  Maybe it's the best we can do.
 
> 
> > If you want to do the
> > mux magic below you are going to need to treat it as an SPI mux - just with
> > some lines shared. That means this device ends up split into multiple device
> > (even if only one ad4134 which is messy).  
> You mean spi-mux.yaml/spi-mux.c? So the goal/intent would be to have one IIO
> device for each peripheral in the chain? I think that would also work. Though,
> the only device bringing ADC sample data is the topmost one so that would be
> the only one buffer capable.

We went through that discussion IIRC for the original chaining devices and it
ends up too odd as there is no way for userspace to know that we have this
strange interacting set of devices.

> 
> > 
> > So to me this has a simple SPI bus, potentially connected to multiple devices
> > and an IIO backend that deals with DOUT0 etc and the chaining.  
> Yeah, the benefit of having the mux is being able to connect both AD4134
> interfaces to a single bus while being able to have ADC sample data on all SDI
> lines as the diagrams in patch 13.
> 
> Alternatively, we could have something like
> 
>                                                               +-------------+
>   +----------------------+                                    |  DATA HOST  |
>   |       AD4134         |                                    |             |
>   |                      |                                    |             |
>   |Data interface  DOUT0 |----------------------------------->| SDI1        |
>   |for ADC data    DOUT1 |----------------------------------->| SDI2        |
>   |sample read     DOUT2 |----------------------------------->| SDI3        |
>   |                DOUT3 |----------------------------------->| SDI4        |
>   |                DCLK  |<--------------+        +---------->| CS          |
>   |                ODR   |<------------+ |        | +-------->| SCLK        |
>   |                      |             | |        | | +------>| SDO         |
>   |                      |             | |        | | | +---->| SDI         |
>   | SPI interface   CS   |<-------+    | +--------|-|-|-|-----| DCLK        |
>   | for register    SCLK |<-----+ |    |          | | | |     |             |
>   | access          SDI  |<---+ | |    |          | | | |     | TRIGGER     |
>   |                 SDO  |--+ | | |    |          | | | |     +-------------+
>   +----------------------+  | | | |    +----------|-|-|-|---------+
>                             | | | +---------------+ | | |
>                             | | +-------------------+ | |
>                             | +-----------------------+ |
>                             +---------------------------+
> 
> The downside of the above is we would need an SPI_MULTI_LANE_MODE_STRIPE to read
> only from SDI1 to SDI4.

I don't totally follow that detail, but indeed the control SPI plane would be independent
and so we'd need to do something to get that from the binding in a way that distinguishes
it from other spi controllers.  The device would be sitting on two SPI busses, one
of which had the multi channel properties.

To me this one is more natural but I can see both might get built and the complexity
of representing that as an SPI mux would be you'd be using part of a wider spi controller.
Hence I guess maybe the hidden (ish) mux is the way to go.

Jonathan
> 
> > 
> > Jonathan
> >   
> > > 
> > > ::
> > > 
> > >   +-----------------------+                               +-----------------+
> > >   |         AD4134        |                               | SPI Controller  |
> > >   |                       |                               |                 |
> > >   |                       |                               |                 |
> > >   | SPI interface    SCLK |<--------------------+---------| SCLK            |
> > >   | for register       CS |<--------------------|-+-------| CS              |
> > >   | access            SDI |<--------------------|-|-+-----| SDO             |
> > >   |                   SDO |------->|¯¯¯¯\       | | |     |                 |
> > >   |                       |        |MUX  >------|-|-|---->| SDI0            |
> > >   | Data interface  DOUT0 |------->|____/<------|-|-|---- | GPIO            |
> > >   | for ADC sample  DOUT1 |---------------------|-|-|---->| SDI1            |
> > >   | data read        DCLK |<-------------+------|-|-|-----| DCLK            |
> > >   |                 DOUT2 |<-+           |      | | |     |                 |
> > >   |                 DOUT3 |<-|-+         |      | | |     |                 |
> > >   |                   ODR |<-|-|---------|--+   | | |  +->| Offload Trigger |
> > >   +-----------------------+  | |         |  |   | | |  |  +-----------------+
> > >                              | |         |  |   | | |  +--| PWM1            |
> > >                              | |         |  +---| | | ----| PWM0            |
> > >                              | |         |  |   | | |    +-----------------+
> > >                              | |         |  |   | | |
> > >   +-----------------------+  | |         |  |   | | |
> > >   |         AD4134        |  | |         |  |   | | |
> > >   |                       |  | |         |  |   | | |
> > >   | SPI interface         |  | |         |  |   | | |
> > >   | for register     SCLK |<-|-|---------|--|---+ | |
> > >   | access             CS |<-|-|---------|--|---|-+ |
> > >   |                   SDI |<-|-|---------|--|---|-|-+
> > >   |                   SDO |  | |         |  |   | | |
> > >   | Data interface        |  | |         |  |   | | |
> > >   | for ADC sample  DOUT0 |--+ |         |  |   | | |
> > >   | data read       DOUT1 |----+         |  |   | | |
> > >   |                 DOUT2 |<-+           |  |   | | |
> > >   |                 DOUT3 |<-|-+         |  |   | | |
> > >   |                  DCLK |<-|-|---------+  |   | | |
> > >   |                   ODR |<-|-|---------|--+   | | |
> > >   +-----------------------+  | |         |  |   | | |
> > >                              | |         |  |   | | |
> > >                              | |         |  |   | | |
> > >                              | |         |  |   | | |
> > >   +-----------------------+  | |         |  |   | | |
> > >   |         AD4134        |  | |         |  |   | | |
> > >   |                       |  | |         |  |   | | |
> > >   |                       |  | |         |  |   | | |
> > >   | SPI interface    SCLK |<-|-|---------|--|---+ | |
> > >   | for register       CS |<-|-|---------|--|-----+ |
> > >   | access            SDI |<-|-|---------|--|-------+
> > >   |                       |  | |         |  |
> > >   | Data interface        |  | |         |  |
> > >   | for ADC sample  DOUT0 |--+ |         |  |
> > >   | data read       DOUT1 |----+         |  |
> > >   |                 DOUT2 |              |  |
> > >   |                 DOUT3 |              |  |
> > >   |                  DCLK |<-------------+  |
> > >   |                   ODR |<----------------+
> > >   +-----------------------+
> > > 
> > > 
> > > So we would set them as only one daisy-chained device.
> > > 
> > >     spi {
> > >         ...
> > >         adc@0 {
> > >             compatible = "adi,ad4134";
> > >             reg = <0>;
> > >             spi-rx-bus-width = <1>, <1>; /* 2 lanes of 1 bit each */
> > > 
> > >             <supplies, clock, and other properties ...> 
> > > 
> > >             #daisy-chained-devices = <2>;
> > > 
> > >             adi,spi-mode = "two-channel-chain";
> > >         };
> > >     };
> > > 
> > > Thanks,
> > > Marcelo  
> >