From owner-freebsd-arm@freebsd.org Fri Nov 27 17:32:52 2020 Return-Path: Delivered-To: freebsd-arm@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6C5874ACFB7 for ; Fri, 27 Nov 2020 17:32:52 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CjMCS1J74z3nZ4 for ; Fri, 27 Nov 2020 17:32:52 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1606498370; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=RKIgf3eb+8BLi2mtn3EjUTuniuxl5wtydr2x96rY5sQZSGStQjgxwt6qEXOXjtlis2kLMM3vmxir1 /LtkngGK/ynZVdq8zZ7l5PIBQlfyqTZMEoEPcXIvellFUyT6Qfin1FtPIBSzWaV0C6wJnfrf2wCXkU Bs+WvGb1beOc75jUR114pCvbYpfOO8hMg1+eq8gm9CX5ggd1eh04y1FWlomFGxKiooVEu1v/2RGxPs Gd6w7DnasGKh5NV+XpXAmRWFKqxNK5g+wb/1SbGgj64f3bINbW58BqoJj9/1di10T00nPLznO6PvHd RKDvAXtqvelINNc8DPOso1CLJp5hqyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=PbV8VbxIjgp43QmUGb8hyKoLtG7rU3EEqFSMyivzegk=; b=sTX2Ya3S9mGli6q9p0u8iDZaxMRU/6QRFPK72lOPqDrGDp3gVX+Kle5+8PSdmpBB8L6CR37s0c3Iy l/oigAJnVxZ/f8R8rCdHcn5cMfCumBiHIQB1hIrryZZyhDYjJlp8Ljp9hHAq/VS8SGDpELKnVpsT5R fXoM6ki3gWrnt1pwGSUOKWYcQglLFfaU9jbFuwSKoiMoi1vJ+aAe4EfmnN80rU1H4LkXb0VwJMDON0 9IRwKd7pvaHzFF4qGhzrXW6on8ERKj7ljpubpycshM/GGRI8wz7o6Qbc9jJi7EmCMABUtw9utjhiJT bClSZj8YPzaRyCLVe9kJAK5LGvadWxQ== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=PbV8VbxIjgp43QmUGb8hyKoLtG7rU3EEqFSMyivzegk=; b=hFweL3qVsul30tJNf7cH+xYbbIYuxaVC2tnWhw+eFot2o+gZ/6bzhLPJmYIGqQHLLigXPjpq43IxZ 52DHlQDg7AKyf0084rUTROuAInm7Qb0BrVzflSw9r8fo6tG1kRECVuHhN08LFvwiQYeczZWhX8VUAP IUnZJS0l9rDGQDqM8jKiNY+cdWvY4f0V2f0Lb82TehkISz8uLsnc+rkugGKU90Zwz5rsOe5WN1fAsp 8XA8lDLLvgn7/Usjx8IvFVnIZ+JeOwdbySrgJVgN2Zk4lktYRGEfv2Odum4SbnyjTfjdORPOOs5qeK j3vIVdD8BdUONPhSEEKDjAOjoSIM+CA== X-MHO-RoutePath: aGlwcGll X-MHO-User: 905ca3ae-30d6-11eb-9e13-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 905ca3ae-30d6-11eb-9e13-df46ed8f892f; Fri, 27 Nov 2020 17:32:48 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0ARHWkir080472; Fri, 27 Nov 2020 10:32:46 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: User Space GPIO Interrupt programming - GSoC-2018 From: Ian Lepore To: "Dr. Rolf Jansen" Cc: freebsd-arm@freebsd.org Date: Fri, 27 Nov 2020 10:32:46 -0700 In-Reply-To: References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> Content-Type: text/plain; charset="iso-2022-jp" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CjMCS1J74z3nZ4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 17:32:52 -0000 On Thu, 2020-11-26 at 22:18 -0300, Dr. Rolf Jansen wrote: > > Am 26.11.2020 um 16:56 schrieb Ian Lepore : > > > > On Tue, 2020-11-24 at 17:14 -0300, Dr. Rolf Jansen wrote: > > > Hello > > > > > > Has anything of the GSoC-2018 efforts made it into the current > > > code > > > base? > > > > > > > > > > https://wiki.freebsd.org/SummerOfCode2018Projects/UserSpaceGPIOinterrupts > > > > > > I installed the recent 13.0-CURRENT snapshot (2020-11-19) on a > > > BeagleBone Black which was one of the implementation targets of > > > said > > > project, but when running the test tools, I either see cannot > > > read/kevent/poll/aio_read - Operation not supported by device or > > > Inappropriate ioctl for device. > > > > > > Perhaps I need to pull the project´s changes into the kernel by > > > myself. However, before this I would like to ask whether it is > > > worth > > > the effort. > > > > > > Please, can anyone shed some light on this. > > > > > > Best regards > > > > > > Rolf > > > > > > > I made some time this morning to review the gsoc2018 code. It > > turns > > out this code is very high quality, nearly ready to commit as- > > is. The > > main thing it needs is some style cleanup in its comment blocks, > > and > > documentation. I'd be inclined to commit the code first and write > > the > > documentation over the next little while and commit it separately. > > > > If you'd like to give it a try, here's a diff that should apply and > > build cleanly on freebsd 12 or 13: > > > > https://people.freebsd.org/~ian/gpio_gsoc2018.diff > > > > While there isn't any documentation yet, there is a test program (I > > haven't run it yet) that demonstrates all the features: > > > > https://github.com/ckraemer/gsoc2018-utils/blob/master/src/gpioc_intr_test.c > > > > Right now the code will let you block waiting for a pin-change > > event > > using select(), poll() or kevents, or to be notified via SIGIO, but > > after being notified that something happened, you still have to > > call > > read() to see which pin changed. I think if the pin changes state > > multiple times between calls to read(), you'll lose track of some > > changes (I'm not positive of that, I don't understand the kevent > > stuff > > well). > > > > I'd like to add some features so that you can configure it to track > > pin > > changes in counting-mode and timestamping-mode. In counting mode, > > when > > you do a read() you would get back a pair of values, the pin number > > and > > how many times its interrupt fired since the last read. In > > timestamping mode, every read would return a pin number and an > > associated timespec giving the exact time the interrupt happened > > (there > > would need to be a way to configure how many events it could > > buffer, > > but I think even allowing a thousand buffered events would only use > > a > > few kbytes of memory). > > I got it working as well, please see my other post from yesterday. I > used gpioc_intr_test.c. > > I see hundreds of warning messages when I press the test button a few > times. May these warnings be safely ignored. The kernel module of > Oskar Holmund works quite nice as well (for what I need), and with > that one, I don’t see warnings. > > The counting- and timestamping-mode for sure would be very useful. > Perhaps by implementing this, there won’t be no unhandled interrupts > anymore, and hence there won’t be any warnings either. > > Best regards > > Rolf I'm sorry, I somehow overlooked your previous message about using gpioc_intr_test.c. Those warning messages are definitely not a good thing, in some changes I've made to the original patches they are changed to debugging-only output that won't normally show up. Printing messages from within an interrupt handler is pretty much always a bad idea. :) I was thinking about the various interrupt options and realized we cannot support level-triggered interrupts in this code without a ton of work. It's just a recipe for an interrupt storm (which will happen at the rate of tens of thousands of interrupts per second once the printfs aren't there to slow things down to console IO speed). To use level- triggered interrupts from userland, the gpioc would have to mask the interrupt from within the interrupt handler (we don't have an internal API for doing that with gpio interrupts right now), and provide some sort of EOI (end-of-interrupt) acknowledgement interface to userland to unmask them once it had done something to make the interrupt stop asserting. Basically this would extend the way device drivers handle level-triggered interrupts into userland, and I just don't see much value in all the work that would be involved to make that happen. I think instead we should just run in counting-mode by default, and add new code similar to what Vladimir Goncharov has proposed to handle detailed reporting of each event if the app requests it. I can't make up my mind on the issue of debouncing. My gut tells me that building in some kind of debounce logic as a per-pin configurable option would be nice, but it might also get really complicated. An app could handle debouncing for itself if it requested detailed event reporting, because the timestamps on the events could help it decide what to do. -- Ian