The sentence just prior I stated that it was dozens of CPU cycles to access GPIO blocks. Your citation is consistent with my statements. And BTW, the problem

The sentence just prior I stated that it was dozens of CPU cycles to access GPIO blocks. Your citation is consistent with my statements. And BTW, the problem isn't slow clocking from the GPIO. It runs at about half CPU clock depending on the RPi model, which doesn't account for the latency you're seeing. It's actually spending most of the time simply propagating unchached accesses across the fabric, taking a long time for the same reason that an uncached read from DRAM takes a lot of cycles. But at the end of the day, my whole argument was that the hardware is capable of about equivalent to an Arduino in terms of wiggling lines. However, from Linux you can't consistently meet deadlines without writing a kernel module because of the IPIs the kernel uses internally for bookkeeping. At that point you're comparing the developer UX between writing a kernel module with that of an Arduino sketch, and there's a pretty clear winner for productivity. That's why I welcome alternative software stacks.