Hi Andre,
Am 07.02.23 um 02:16 schrieb Andre Przywara:
On Mon, 6 Feb 2023 20:51:50 +0100
Andreas Feldner <pelzi@xxxxxxxxxxxxxxx> wrote:
Hi Andreas,
thanks for taking care about this board and sending patches!
Thank YOU for maintaining it!
The SoC features debounce logic for external interrupts. Per default,
this is based on a 32kHz oscillator, in effect filtering away multiple
interrupts separated by less than roughly 100�s.
This patch sets different defaults for this filter for this board:
PG is connected to non-mechanical components, without any risk for
showing bounces. PA is mostly exposed to GPIO pins, however the
existence of a debounce filter is undesirable as well if electronic
components are connected.
So how do you know if that's the case? It seems to be quite normal to
just connect mechanical switches to GPIO pins.
If you are trying to fix a particular issue you encountered, please
describe that here, and say how (or at least that) the patch fixes it.
And I would suggest to treat port G and port A differently. If you
need a lower debounce threshold for port A, you can apply a DT overlay
in U-Boot, just for your board.
Fair enough. You run into problems when you connect (electronic)
devices to bank A (typically by the 40pin CON2 connector), where
the driver requires fast IRQs to work. In my case this has been a
DHT22 sensor, and the default debounce breaking the dht11.ko
driver.
Now, what kind of problem is this - I'm no way sure:
a) is it an unlucky default, because whoever connects a mechanical
switch will know about the problem of bouncing and be taking
care to deal with it (whereas at least I was complete unsuspecting
when connecting an electronic device that a debounce function
might be in place), or
b) is it a bug in the devicetree for (at least) the BananaPi M2 Zero,
because the IRQ bank G is hard wired to electronic devices that
should not be fenced by a debouncing function, or
c) is it missing dt binding documentation of the input-debounce
attribute?
Anyway, the combination of these is quite irritating. To me it
seems a sufficiently elegant solution to explicitly include the
setting in the devicetree and leave it to whoever is unhappy
with it, to create a better suited device tree overlay.
Additionally, the clock-frequency attribute is added for each of
the 4 cores to eliminate the kernel error message on boot, that
the attribute is missing.
Signed-off-by: Andreas Feldner <pelzi@xxxxxxxxxxxxxxx>
---
.../dts/sun8i-h2-plus-bananapi-m2-zero.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
index d729b7c705db..1fc0d5d1e51a 100644
--- a/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
+++ b/arch/arm/boot/dts/sun8i-h2-plus-bananapi-m2-zero.dts
@@ -113,6 +113,22 @@ wifi_pwrseq: wifi_pwrseq {
&cpu0 {
cpu-supply = <®_vdd_cpux>;
+ clock-frequency = <1296000000>;
I see where you are coming from, this is really an unnecessary warning
message. However this message should be really removed from the kernel
instead of adding some rather meaningless value here.
The current DT spec marks this property as required, though, so I added
a PR there to get this fixed:
https://github.com/devicetree-org/devicetree-specification/pull/61
Once this is through, we can try to remove the kernel message.
OK, so I'll take care to have this change removed from my patch.
I thought so, but then it was the configuration I'd been testing with...
+};
+
+&cpu1 {
+ cpu-supply = <®_vdd_cpux>;
I don't think we need this for every core?
I came across a discussion that this was marked required on the
cpu@... level whereas it would make sense on the cpus level. I did
not check if this suggestion was implemented in the meantime,
sorry!
+ clock-frequency = <1296000000>;
+};
+
+&cpu2 {
+ cpu-supply = <®_vdd_cpux>;
+ clock-frequency = <1296000000>;
+};
+
+&cpu3 {
+ cpu-supply = <®_vdd_cpux>;
+ clock-frequency = <1296000000>;
};
&de {
@@ -193,6 +209,8 @@ bluetooth {
};
&pio {
+ /* 1�s debounce filter on both IRQ banks */
Is that supposed to be <micro> in UTF-8? It seems to have got lost in
translation, or is that just me?
O yes, the Greek character slipped into the comment.
+ input-debounce = <1 1>;
As mentioned above, I am not so sure this is generic enough to put it
here for PA. And what is the significance of "1 us", in particular? Is
that just the smallest value?
Yes indeed it's a bit more complicated than I feel it needs to be. The
configuration is taken as microseconds and translated into the best
matching clock and divider by the driver. However, 0 is not translated
to the lowest divider of the high speed clock as would be logical if
you ask for zero microseconds, but to "leave at default". The default
of the board is 0 in the register, translating to lowest divider on the
_low_ speed clock.
To me this is mindboggling.
If you want to keep IRQ bank A as it is today and switch off the
definitely unnecessary (and _potentially_ IRQ eating) debounce off
for bank G only, I'd suggest the following setting:
input-debounce = <31 1>;
This is because 31 Microseconds is exactly the time that is best
matched by the low speed clock with low divider and translated
to a 0 in the config register by the driver.
The absolutely equivalent setting, with the only drawback that it
would have confused me to death is:
input-debounce = <0 1>;
(because it skips setting IRQ bank A debouncing, leaving it at 31.25 us)
Or, and that was my suggestion, you set both correctly for
electronic devices and leave the task of switching on debouncing
to the implementors of applications with mechanical switches:
input-debounce = <1 1>;
To me, any of these being present in the devicetree would have been
of great help, because I would have seen that there is something
to set.
One final question: how would you like this change:
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -1467,6 +1467,10 @@ static int sunxi_pinctrl_setup_debounce(struct
sunxi_pinctrl *pctl,
writel(src | div << 4,
pctl->membase +
sunxi_irq_debounce_reg_from_bank(pctl->desc, i));
+
+ pr_info("Debounce filter for IRQ bank %d configured to "
+ "%d us (reg %x)\n",
+ i, debounce, src | div << 4);
}
return 0;
It helped me to cross-check what the driver is really doing, and it
again would have helped me with me DHT problem to learn about
the existence of a debouncing filter.
Yours,
Andreas.
