Pi4 gpio timing experiment

[ledvinap]

(for discussion, do not merge)

This PR uses DSB memory barrier that forces AXI transaction to complete before next instruction.

Pros:

• You get very accurate timing, RGB data and clock are almost perfectly synchronized. Absolutely no ghosting
• possibly slightly lower power consumption (5% ? core is stalled, not busy waiting)

Cons:

• Clock frequency si limited, to about 6MHz on non-overclocked PI4
  • about half vs using --led-gpio-slowdown.
  • Overclocking does change timing, but I did not investigate it yet.
• Memory access from other threads will slow serial speed down a bit (but timing is not degraded as in --led-gpio-slowdown case)

It may be very useful with long/noisy cables or slow matrices. Timing margins are much beter

[ledvinap]

@hzeller : BTW: Did you consider/invvestigate using videocore for data generation? It may be possible with great performance ...

[ledvinap]

I've changed PR a bit. Now either dummy writes or DSB is used for slowdown.

Appending dummy writes works better than old code - register value is updated first, then delay is inserted.
Old code did: clear bits, delay, set bits, delay (set clock, delay) - wasting half of delay time after pushing column data to IO ports. This should result in about 30% increase of clock speed with no negative side effects.

DSB is used with --led-gpio-slowdown=-1. Code must be compiled for ARM7 or ARM8, -march=native handles this now.

It may be better to emit 'DSB ST' opcode directly (so assembler won't complain) and test for supported CPU on runtime.