lsof/crefs/somethings else?

[Tim Hardisty <ti...@jti.uk.com.INVALID>]

I have pretty much ironed out all the issues with the SAMA5 touchscreen (TSD) and ADC drivers, making sure they actually work correctly for the D2 variant and look like they should work for the D3 and D4 variants, and fixed bugs along the way. I will do a PR in due course but still have one high-level issue I am struggling to resolve, through inexperience.

The TSD relies on the ADC of course, but any given board may use either or both. And we can't know whether TSD or ADC will be opened first, nor which may be closed first, or at all.

Currently an ADC close disables interrupts and up disables them, and detaches them - but that kills the TSD of course.

For now, in the SAM ADC driver, I have #defined out the up disable and irq detach if the TSD is configured (CONFIG_SAMA5_TSD), and just make sure the ADC interrupts are disabled in the interrupt register, and similarly in the TSD driver. Each driver up enables the interrupt when first opened. This works, but does mean nothing ever up disables or detaches the interrupts, even if all TSD and ADC file instances are closed.

The ADC uses a cref count, managed by the higher and generic ADC code. The TSD code uses its own cref as it's SAMA5 specific, and I don't think the higher ADC code should be tampered with by me just to suit the obscure SAMA5 devices.

My thoughts are:

1) don't worry about it and just leave the interrupts attached and up enabled, but ensure the ADC interrupts are disabled at the register level on a close
2) Use something like lsof so the ADC driver can see if there's a TSD driver open, and vice versa, during a close. Is there an equivalent to lsof in NuttX?
3) Add a new flag to the SAMA5 ADC drivers that counts something that isn't an open as such but can be used by TSD and ADC drivers during a close. Number of calls to initialise the ADC perhaps, as the TSD board bringup code will call ADC init and vice versa.  That would mean exposing the relevant device structure(s) via the .h files - not sure if that's frowned upon?

Or something else I haven't thought of, of course!