Re: [PATCH v1 1/3] dt-bindings: iio: adc: Add AD4134

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3798 bytes --]

On Thu, Nov 13, 2025 at 06:56:26PM -0300, Marcelo Schmitt wrote:
> On 11/10, Conor Dooley wrote:
> > On Mon, Nov 10, 2025 at 09:45:18AM -0300, Marcelo Schmitt wrote:
> > 
> > > +  adi,control-mode:
> > > +    $ref: /schemas/types.yaml#/definitions/string
> > > +    description:
> > > +      Describes whether the device is wired to an SPI interface or not. The
> > 
> > Can you explain how you don't automagically know this from what bus
> > you're on?
> 
> No. I mean, I should have realized we can imply SPI control mode from the bus node.
> That's one fewer dt property :)
> 
> > 
> > > +      PIN/SPI pin on the device must be set accordingly, i.e., PIN/SPI must be
> > > +      set to logic high for SPI Control Mode, low for Pin Control Mode. When
> > > +      absent, implies the SPI interface configuration.
> > > +    enum: [ spi-control-mode, pin-control-mode ]
> > > +    default: spi-control-mode
> > > +
> > > +  adi,asrc-mode:
> > > +    $ref: /schemas/types.yaml#/definitions/string
> > > +    description:
> > > +      Asynchronous Sample Rate Converter (ASRC) operation mode control input.
> > > +      Describes whether the MODE pin is set to a high level (for master mode
> > > +      operation) or to a low level (for slave mode operation).
> > 
> > I don't really get this one. If this is an input to the device that
> > controls behaviour (master v slave) why is an option needed too? Clearly
> > this is not a gpio but it seems like it could be one, in which case you'd
> > need some sort of asrc-gpios property. Is it not possible to read the
> > value of this setting out of the device's registers (maybe it's not when
> > there's no spi interface connected?)?
> > It's not used in your driver, so I can't look there easily to see what's
> > going on.
> 
> The MODE pin defines whether the ODR pin will behave as input or output.
> Currently, there are no plans for supporting ODR as output but, software would
> need to do different things to control the output data rate in that case.
> Though, the MODE pin state can indeed be read from a register. Same for DCLK pin
> I/O direction and DCLK mode. They are also readable from device's registers.
> So, that would be 4 fewer dt props total. Well, yeah, if the device is not
> connected to an SPI host (pin control mode) then we can't read those. There are
> no plans for supporting this device outside an SPI bus, but we would then
> need these properties (or a separate binding). Not sure what to do here. 
> Do I drop or keep adi,asrc-mode?

If you need it when not in spi mode, then keep it. For all of those
kinds of things, you probably can use the property to set things in spi
mode and to know they're set that way in !spi mode? In spi mode you
probably still need to be able to change the asrc mode, right? Or does
the device not permit being tristate (n/c I guess), and it has to be tied
low or high, and therefore software must just follow the pin setting?

> The MODE pin is sampled only when the AD4134 is powered on so I don't think we
> would benefit from having a GPIO connected to that (if we keep a property to
> describe the MODE pin state).

As in, it gets sampled once at power on, not continuously while powered
on? Technically, you can still do that with gpios, if you have
controllable supplies. Depends on use case I suppose and could be added
as an alternative later on if needed, so I wouldn't worry too much about
it when you're seemingly not even using what you have here in the driver.

Actually it might be worth actually checking for it in your driver, to
make sure that it is not being set to high, since you don't currently
support that?

I hope all that made sense, prob shouldn't be sending mails at 0145,
Conor.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]