Re: [PATCH RFC 1/8] dt-bindings: iio: frequency: add ad9910

[David Lechner]

On 2/22/26 4:47 AM, Rodrigo Alencar wrote:
> On 26/02/21 02:43PM, David Lechner wrote:
>> On 2/20/26 10:46 AM, Rodrigo Alencar via B4 Relay wrote:
>>> From: Rodrigo Alencar <rodrigo.alencar@xxxxxxxxxx>
> 

...

>>> +
>>> +  reset-gpios:
>>> +    maxItems: 2
>>> +    description:
>>> +      GPIOs controlling the device reset and the I/O_RESET pins. This is only
>>> +      used if resets property is not defined.
>>> +
>>> +  powerdown-gpios:
>>> +    maxItems: 1
>>> +    description:
>>> +      GPIO controlling the EXT_PWR_DWN pin.
>>> +
>>> +  update-gpios:
>>> +    maxItems: 1
>>> +    description:
>>> +      GPIO controlling the I/O_UPDATE pin.
>>> +
>>> +  profile-gpios:
>>> +    minItems: 3
>>> +    maxItems: 3
>>> +    description:
>>> +      GPIOs controlling the PROFILE[2:0] pins for profile selection.
>>> +
>>
>> Looks like possibly some interrupts as well: RAM_SWP_OVR and SYNC_SMP_ERR
> 
> Interrupts are not handled by the driver at this point, so they were not added
> here. The device is meant to have some features exposed through SPI, but to
> extract the most of it needs to interface with an FPGA. For that, an IIO
> backend is in the works.


DT bindings should aim to be complete. It doesn't matter what the driver
implements or not.

We make exceptions for things that haven't been seen before where the
bindings might not be obvious, but output pins like this (at least the
error one) are pretty much always connected to interrupts.

Also, the interrupt properties should not be required. So if the output
line is connected to an io-backend instead of an interrupt, that is fine.
The bindings should cover all ways this could possibly be wired up.



>>> +
>>> +  adi,sync-clk-disable:
>>> +    type: boolean
>>> +    description:
>>> +      Disable the SYNC_CLK output pin. SYNC_CLK runs at one quarter
>>> +      of the system clock frequency.
>>
>> Clock outputs should be described as clock-controller and #clock-cells.
>> The actual enabling/disabling can be done at runtime.
> 
> I thought of that, but when interfacing with an FPGA, the clock consumer
> will be the IIO backend itself, which this device driver would depend on.
> It would create a cyclic dependency during the probe of the drivers:
> - This device being a clock provider and an IIO backend consumer
> - The FPGA IP being a IIO backend provider and a clock consumer.

As above, the binding should not depend on what the driver does. There is
a standard binding for this, so we should use it. I'm sure we could find
a way to make it work in the driver even if it is just manually parsing the
properties instead of going through the clock framework. I.e. if the
clock-controller property is present, turn on the clock output, otherwise
turn off the clock output.

> 
> This would be just save some power when not interfacing with an FPGA,
> there would not be a clock consumer to get the clock disabled.
> Normally, clock consumers would want to have clock enabled, which is
> already the case by default.
> 
> I would add the FPGA/IIO backend support in a separate patch series,
> as it would bring more stuff here.
>