On Fri, 16 Feb 2024 18:12:37 -0800 Jeremy Mattfeld <jmmattfeld@xxxxxxxxx> wrote: Hi Jeremy, The answer will get a bit complex because there are various things you could do - but the simple one is that you use the dataready trigger from one device (don't describe interrupt line for the others in DT) and then set the current_trigger value for all of them to point to that single trigger. The rest of my reply should give more detail + talk about other options. > I have a hardware design using a TI-AM335x cpu connected over a SPI > bus to 4 AD7779 adc's. Is this a new driver? Also I note the device supports SPI daisy chaining which typically makes a set of devices behave more or less like one bigger device - so that might be worth considering. >I want to use the DRDY_N signal (I have it > connected to the GPIO on the AM335x) from one of the adc's to generate > an interrupt to trigger reads on all four. I have seen several places > in the documentation that states that this is possible (common even) > but I have not seen examples of it in the kernel tree. With a few caveats most IIO drivers that support buffers do this and it should work with most triggers. Note though that there is a config variable controlling how many devices can use a single trigger: CONFIG_IIO_CONSUMERS_PER_TRIGGER so for you case case that would need to be at least 4. Drivers that don't support this will have *validate* callbacks (in either or both directions - triggers can be limited to only triggering one device, often when the signal is internal, devices can be limited to only their own triggers, often when there is some complex interaction that makes a more independent model complex). If you only had one interrupt actually wired then what you do is simply set iio\:device0/current_trigger to the trigger and iio\:device1/current_trigger etc to the same trigger. For each the pollfunc would then be called to collect the data and push it to the independent buffers for each driver instance. Then you would need to align the resulting data in userspace. > Most of the > drivers from ADI request an IRQ along with allocating and registering > their own iio_trigger. When binding multiple instances of the same > iio device driver, the first IRQ request succeeds, while subsequent > requests will return EBUSY. So on to the other options: A driver can support a shared interrupt (grep IRQF_SHARED). There are some drivers in IIO that do this - usually because someone had a board where mutiple different devices were wired up to a shared interrupt pin. Modifying a driver to do this isn't that hard as long as the device has a register that indicates new data (in addition to the dataready interrupt). Otherwise we have no idea if it was our interrupt or not. I took a quick look at the datasheet and can't see that here. Given there is also no way to disable the drdy line that I can see you definitely want to only register the interrupt for one of them (or not share lines but then this question would be odd :) > > Is the correct way to accomplish this to define all my SPI slave nodes > in my devicetree with just one having an interrupts and use > conditional logic in the driver to only have that one request the IRQ? Yes, just describe the interrupt once (and hopefully that is valid as you only wired one up - otherwise you are likely to get spurious interrupts given we can't turn off the drdy interrupt - or at least a quick search didn't show me how). > Another method would be to use the standalone trigger driver (I have > enabled in Kconfig) but I have not been able to find documentation > that shows the devicetree binding for standalone triggers for GPIO > interrupts. There isn't a DT binding for the standalone GPIO trigger. We'd welcome one though if you want to add support but I don't think you need to here and generally we don't want to do that if a it's not coming from independent hardware. So might work, but it's not a clean solution. Hopefully that gives you an idea where to start. Jonathan > > Any guidance would be appreciated. > > Thanks, > > Jeremy >
