[DNM] Px4 firmware nuttx 10.3.0+ serial fixes testing

[davids5]

The H7 fix c696d5e1b0a98f1d976467576f6d93ff8ce61423 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.

[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.