[GitHub] [incubator-nuttx] TimJTi commented on issue #7586: ATSAMA5Dx TSD support incorrect, and doesn't ADC support breaks when using TSD

[GitBox <gi...@apache.org>]

TimJTi commented on issue #7586:
URL: https://github.com/apache/incubator-nuttx/issues/7586#issuecomment-1312703781

   I have working, fixed, code for 1. and 2. above but am unsure how to resolve 3)
   
   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!


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org