[DNM] Px4 firmware nuttx 10.3.0+ serial fixes testing

[davids5]

The H7 fix c696d5e needs further testing from @niklaut etal. see

The other commits needs to be replicated to all NXP SoC's DMA, and serial and then unstreamed and back ported.

[niklaut]

This also solves the original problem, however, to make a more informed decision, I'm currently working of a DMA tracer to check the timing differences between these changes.

WIP example: drag this file into ui.perfetto.dev.

[niklaut]

Ok, so I have three trace files from FMUv6x (STM32H7) which you can all drag into ui.perfetto.dev to check for yourself.

1. orbetto_wait_txdma.perf.gz from just before the first change: 8eb962d.
2. orbetto_trywait_txdma.perf.gz where we tried to use trywait instead: ed4814f
3. orbetto_no_txdma.perf.gz without the TXDMA: eed5762

Some observations on DMA2 CH4, which is services an unconnected TELEM1:

1. is very fast to schedule transfers because it uses a semaphore, so the thread is scheduled in very quickly.
   
2. is very slow to schedule:
   
3. is slower than 1 but still faster than 2:
   

You can also see this in the summary view:

1. 420 transfers at 319ns average duration.
2. 209 transfers at 665ns average duration.
3. 353 transfers at 378ns average duration.

I instrumented the dma_disable, dma_setup, dma_interrupt, dma_start functions for this. Some of them are called in an interrupt context (so very fast), others from threads (when they wake up). That would explain why the transfers in 2 take "longer". Perhaps there is a better, tighter way to instrument this though.

[niklaut]

Yes, at least on STM32H7, this fixes the problem by removing the semaphore altogether and it schedules the next DMA transfer once the previous one has finished. Timing suggests similar throughput as before (if the transmit thread has a high priority).

[davids5]

@niklaut - Thank you for validating. I have the H7 change in a PR upstream and will backport it once merged.

I will continue in this PR the NXP changes.