Dennboy

The frequency scaling seems to be working a bit better on OrangePI zeroplus2 H3 / H5 and NanoPi now (kernel 4.14.39). We discovered however that the frequency scaling severely impacts the SPI communication, resulting in SPI failures during the frequency change. It could be that SPI communication fails because it uses the same clock as the CPU. In certain cases you may want to pre-set the frequency to a conservative fixed frequency for better reliability of especially SPI communication ( sudo cpufreq-set -f 816MHz) and add a heat-sink.

Attached is the kernel patch for sunxi-pinctrl.c on the 4.14.13 kernel, created in the cache/sources/linux-mainline/linux-4.14.y/drivers/pinctrl/sunxi directory from the armbian cached source. pinctrl-sunxi.c.patch

I just updated my test program with the patch to verify its workings, the main change is: if (debounce<=16) { writel((((debounce-1)/2)<<4)+1,sunxi_irq_debounce_reg_from_bank(i,pctl->desc->irq_bank_base)); continue; } Here is a further zoomed plot of the previous test program, showing the devicetree input-debounce for a pinctrl bank on x-axis versus the calculated debounce register entry. Here is the plot for the new test program (see attached source), showing the devicetree input-debounce for the pinctrl bank on x

A small update. The proposed fix removes low frequenty timer with prescaling 2^0. Probably better to mainly change the first 9 register values, so low frequenty timer stays mostly the same as before. if (debounce<=16) { writel(((debounce/2-1))<<4+1,sunxi_irq_debounce_reg_from_bank(i,pctl->desc->irq_bank_base)); continue; }

I have done some tests with the input-debounce devicetree settings under the pinctrl on H5 (nanopi, kernel Linux nplus2 4.14.12-sunxi64). I discovered the following behaviour: when I set the input-debounce to <0x1 0x3 0x4>, I read back the following with devmem2: Value at address 0x1C20A18 (0xffff90bf6a18): 0x51, debounce on prescale=2^5, using HOSC timer Value at address 0x1C20A38 (0xffffbc512a38): 0x61, debounce on prescale=2^6, using HOSC timer Value at address 0x1C20A58 (0xffff9cbb4a58): 0x71, debounce on prescale=2^7, using HOSC timer Ho

Looks like nanopi neo plus2 is almost there, great work! I also stumbled on this Ethernet issue with the next kernel, in the Armbian_5.37_Nanopineoplus2_Debian_stretch_next_4.14.5.img I build yesterday with the Armbian build script. I need custom kernel to get some more Industrial I/O features like standalone triggers enabled, so the older 4.13.14 packages are unfortunately not enough. I guess I have to use wifi until there is a fix. If there is anything I can do to help (e.g. testing an initial fix), please let me know. I also noticed some other minor issues in the image, otherwi

When I understand correctly, the interrupts you are sending have a rather short duration, i.e. within a microsecond. It could be that the interrupt is polled by the Allwinner and/or kernel. Are you using the right clock source, I read somewhere that there is also a higher precision clock. Not sure how to set that up, hopefully someone in this forum can help you with that. Another issue could be the input-debouncer, that is mainly useful when you attach a key/switch to the GPIO pin not with fast hardware. When this is set to a long value, it may average your interrupt si