arm: dts: xilinx: add example for ADAQ4380-4 eval board

[dlech]

PR Description

Add an example for the EVAL-ADAQ4380-4 (FMCZ) evaluation board. These are similar to AD738x, but have different power supply requirements, so worth a separate example.

PR Type

Example DTS

PR Checklist

• I have conducted a self-review of my own code changes
• I have tested the changes on the relevant hardware
• I have updated the documentation outside this repo accordingly (if there is the case)

[machschmitt]

Interesting this one. We would normally assume GND supply pins connected to GND and not declare any GND supply in dt. Though, I see VS- may range from -5V to GND so I think it makes sense to explicitly provide the supply in this case.

[dlech]

Yes, that was the conclusion from upstream review as well.

[machschmitt]

Even if they are not used (yet), can't we have them anyway uncommented? So when the driver gets to use them, we may only remove the comment about they not being used (assuming interrupt parent and number doesn't change off course).

[dlech]

It also depends on an HDL compile option if the interrupt is there or not. The ALERT pin is shared with one of the SDO pins, so we can't use the pin for both at the same time. This .dts file is written with the assumption that we are using all of the pins as SDO (adi,num-sdi = <4>;).

And we don't have plans to add ALERT interrupt support to the driver. We tried this but because of the way the chip auto-resets the interrupt after each sample, it proved very difficult to come up with anything usable in Linux. And according to the applications engineers, this pin is generally hard-wired to some sort of safety shutdown, if it is used. We figured it would be better to wait for a real-world application that needs the interrupt in Linux first rather than trying to guess since there isn't an obvious "right way" to do it.

[machschmitt]

hmm, I would just drop (not add) the interrupt props then. If this dts is tailored to use all SDO for data and interrupts wouldn't work well that way, why to have them in dt?

[machschmitt]

Two things I would change (according to comments). Otherwise, LGTM.

[machschmitt]

adi,ad4030.yaml (upstream) documents spi-rx-bus-width and that is also intended to match a NUM_OF_SDI HDL build parameter (on the ad4630_fmc hdl project). On the ad4630_fmc project, the NUM_OF_SDI specifies how many SDO lines are used for each channel. Would it make sense to use the same property name here? If not, might be a good idea to add a comment telling how this is different from adi,ad4030.yaml spi-rx-bus-width (or add a TODO tag to remind this will need to be updated). Currently, ADI Linux adi,ad4630.yaml uses adi,lane-mode to tell what NUM_OF_SDI was the HDL built with, but I guess it's safe to assume that prop will also be updated at some point.

[dlech]

spi-rx-bus-width is not the same as multiple buses. spi-rx-bus-width lets you read multiple bits of the same word at one time. But multiple buses lets you read one bit each of multiple words at the same time. AD4630 has both actually (i.e. 8 SDO lines consisting of 2 buses and 4 bits per bus), but this chip only has multiple buses.

There is a proposed upstream binding for multiple buses currently on the mailing lists right now and I'm working with the HDL engineers to adapt the AXI SPI Engine to do something like that as well so that we can have proper upstream support.

[machschmitt]

hmm, I would just drop (not add) the interrupt props then. If this dts is tailored to use all SDO for data and interrupts wouldn't work well that way, why to have them in dt?

[dlech]

updated:

• dropped the commented-out interrupts property
• added REVIST to the adi,num-sdi property comment