I understand that the first priority is in finding out if there is
actually a proper
use case for a polling implementation at all. Only then, it might be
worth to extend
the existing dht11 module by an polling alternative.
Am 31.01.23 um 11:18 schrieb harald@xxxxxxxxx:
On 2023-01-30 21:42, Andreas Feldner wrote:
On a BananaPi M2 Zero, the existing, IRQ based dht11 driver is not
working,
but missing most IRQs.
That's quite surprising as the driver works well on many similar systems
based on Allwinner SoCs. I suspect the problem is with your setup. Maybe
some other (polling?) driver is slowing everything down.
Can you give me a hint how to look for signs of such a situation?
BTW I took some pride in building the board's system image from
reproduceable sources: Debian kernel package
linux-image-5.10.0-20-armmp-lpae, and the device tree from
arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
So the setup should be reproducible, unlike other approaches advertised
in the BananaPi forum...
What I did is
- check /proc/interrupts. The highest volume interrupts there are two
instances of sunxi-mmc, one generating about 50 interrupts per second,
the other about 25. Those (and most) interrupts are GICv2, but the GPIO
releated are sunxi-pio-{level,edge}
- check dmesg: literally no messages apart from dht11_poll itself
- check top: sugov:0 is reported to eat 10% of one cpu, but I understand
that's expected and an artifact anyway. Changing the scaling governor to
"performance" eliminates this, but does not help in making the irq
driven dht11 work.
- check vmstat: ir is between 50 and 200 apart from short spikes, those
probably related to a certain cron job
- check sysstat cpu, mem, threads, mutex: each of the 4 cores has a low
performance (a factor of 15 lower than a Raspberrypi 3), but constant,
low stddev, etc. No surprises running e.g. 8 threads instead of 4.
So, apart from the fact that it is missing about 3/4 of the IRQs the
dht11 driver should get, I have no indication that something might be
wrong with the board or its setup. Where else should I look?
Some additional remarks of questionable relevance:
Prior to attempt to put the logic into a kernel module, I implemented a
polling PoC in userspace using libgpiod by nailing together parts of
gpioset, gpiomon, and the dht11 kernel module:
https://github.com/pelzvieh/banana_resources/blob/main/poll_dht11.c
This works "reasonably", once in a few shots, but the diagnostics show
that there are only typically 5 to 7 samples for a high pulse
corresponding to a zero bit (26-28 µs). My naive interpretation was that
the board is just quite slow for this task.
BTW the constant timing of the low pulse of 50 µs was confirmed by that
experiment as well. It seems to work as given in the DHT22 datasheet
floating arount in internet (e.g. for download at
https://www.mikrocontroller-elektronik.de/dht22-am2302-luftfeuchte-und-temperatursensor/).
Following the hints in Harald Geyer's comments I
tried to implement a version of the driver that is polling the GPIO
sensor in a busy loop, not using IRQ altogether.
IIRC one readout takes about 80 milliseconds. That's a very long time for
a busy loop. I doubt this is acceptable for inclusion in the kernel. Of
course also Jonathan's comments apply.
Seems to be a bit less, just in case that matters. Given the timing
chart I'd expect
on average: 200µs + 40 * 100µs = 4,2ms
worst case (device trying to send all one-bits): 200µs + 40 * 120µs = 5,0ms
Yours,
Andreas.
