Irregular GPIO Latency with DMA

[F5OEO]

rpitx (http://hackaday.com/2015/11/04/rpitx-turns-rasberry-pi-into-versatile-radio-transmitter/) is using DMA and access to GPIO and clock registers.

My config.txt

disable_l2cache=1
disable_pvt=1
force_turbo=1
arm_freq=700
gpu_freq=250
core_freq=250
sdram_freq=400
kernel=kernel.img

If start_x =1 : drift is about 2 to 3 us to acess to GPIO (camera is not used in parallel to the software)
if start_x=0 : drift is around 0.1 to 0.2 us

Any idea what is the reason ?
I could send a sourcecode to test.

Here is snapshots :

With start_x=1

With start_x=0

[popcornmix]

Is this Pi 1?
Why are you using disable_l2cache=1?
Note: that settings required the kernel to be rebuilt with a similar option.

What does vcgencmd version report?
disable_pvt wasn't working until a recent firmware update.

[F5OEO]

Sorry , I use effectively disable_l2cache=0 else I have timing issue
Thanks for information about rebuilding the kernel is disable_l2cache=1
These test are done on PI 2 / Wheezy (Jessie seems to have same issue)
vcgencmd version
Nov 21 2015 14:46:04
Copyright (c) 2012 Broadcom
version 08c8feab9898b610605c2610e19ffbd0df290f84 (clean) (release)

The firmware I guess I use is get from the fix #497
I see also that in this issue, @subspclr4 use start_x=0 which mean probably encounter the same Timing issue

[popcornmix]

disable_l2cache=0 is default for Pi1
disable_l2cache=1 is default for Pi2
You really shouldn't change this without rebuilding kernel with CONFIG_BCM2708_NOL2CACHE flipped. Crashes, sdcard, network, usb corruption are all possible without ensuring this.

Are you able to detect the problem with start_x=1 (without using a scope?)

[F5OEO]

OK for info about l2cache...
For now, I detect the drift issue with scope. I could maybe add a measure of the average timing using the realtime clock which could give you tendency of the latency. @popcornmix Let you know when I implement the measure and if it could be relevant to see the issue.

[popcornmix]

I can't see an obvious reason why the start_x firmware will have worse gpio latency.
If you could make a script that I can run (without extra hardware) that prints "good" or "bad" (for start.elf / start_x.elf) I could work through the differences of the two builds and track down exactly what makes the difference.

If that is not straightforward to do, I can make a number of test firmwares that you can test to narrow down the problem - but that will be a slower procedure.

[F5OEO]

After inspecting further, start_x is not directly the cause, but access to camera. Running raspivid makes the GPIO latency (or interfere with DMA) thus the drift is around 2us instead of 100 ns.

[popcornmix]

That is not surprising. Running raspivid will generate a lot of AXI traffic (mostly sdram) and that will increase latency of other users. We may be able to expose a method of changing priority of different AXI clients, but that only has limited effect. If an access ahead of you is in progress yours will have to wait (but the priority may ensure the next access is yours rather than another).

[popcornmix]

Obviously minimising the work done by raspivid will reduce the latency. e.g. lower resolutions/framerates/bitrates will generate less competing AXI traffic.

[popcornmix]

You can include AXI priority in DMA_CS register. Setting to 15 may help a little.

[F5OEO]

This is already done ...

2016-01-09 15:48 GMT+01:00 popcornmix notifications@github.com:

You can include AXI priority in DMA_CS register. Setting to 15 may help a
little.

—
Reply to this email directly or view it on GitHub
#516 (comment)
.

[popcornmix]

There is probably not more that can be done. When the roads are busy your journey takes longer.

[Philius]

When your task has to share resources there's gonna be some drift.
I reached that conclusion myself with v3c-raspi.
Of course it would be nice if your solution was code-only, but for hard-real-time you need external hardware.
Either a shift register that has it's own clock source, doing serial-to-parallel-gpio with polling via DMA,
or Cypress PSOC doing USB 2.0+ with its own clock source.

[popcornmix]

Closing as I'm not sure there is anything we can fix.