Message-ID: <d03ec6a7-62c0-0a82-a0f0-d2030ed5723d@feldner-bv.de>
Date:   Wed, 1 Feb 2023 13:51:52 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.6.1
Subject: Re: [PATCH 1/2] iio: dht11: forked a driver version that polls
 sensor's signal from GPIO
To:     harald@ccbib.org
Cc:     jic23@kernel.org, lars@metafoo.de, linux-iio@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <Y9groXq2oI6lqFea@debian-qemu.internal.flying-snail.de>
 <ee14f0c8bfbae887d21f827baece8b6e@ccbib.org>
From:   pelzi@flying-snail.de
In-Reply-To: <ee14f0c8bfbae887d21f827baece8b6e@ccbib.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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@ccbib.org:
> 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.