Re: multiple iio_devices, one shared GPIO iio_trigger

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.


> Any guidance would be appreciated.
> Thanks,
> Jeremy

[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     []

  Powered by Linux