From owner-freebsd-arm@freebsd.org Fri Nov 27 01:18:29 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 867B0477611 for ; Fri, 27 Nov 2020 01:18:29 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.20]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Chxb81zWFz3tjq; Fri, 27 Nov 2020 01:18:27 +0000 (UTC) (envelope-from freebsd-rj@obsigna.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1606439905; s=strato-dkim-0002; d=obsigna.com; h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=pmTSEB62gZ02zhyngwx8MIQfI5mL0QpL61AyB7+j130=; b=VcjI1lUtqXLv/72dUOeMtSwzG8yO8cFwT01ezOftUzkvp8moKNZD7jv0adK6AxnT/d STQaXJQAQUDKnCb8WcBbs9XVzCr2j8TNJ1BzimPQFAFGAgenbNLM7NaPqd4JhalZ7B/r dgi/23AVykPRfdz7HtzYFQudKhcZJJ8uK0yBuPIGcDewMvwfuy2LxOHk7WF70rBVvWOm u+LwAZos/mWagXPpeJSR73PK5eevwR7lIPdns0j7mAOr6b3N8H5LxZjrqFI8q2AH6kY7 ey1lQ+Eejr81Izk/NmzH0LFfFd0HDp1ZF+XS0VwKqJ1DmUeDP3KtL4kLnFRphPvp6ALr R/3A== X-RZG-AUTH: ":O2kGeEG7b/pS1F2rRHW2isrKl4DV03XBEi+I6ZuztdvN9wS3wFGySS4Lw+ldTBio0dVbInGjc9RnD7rYRqs=" X-RZG-CLASS-ID: mo00 Received: from mail.obsigna.com by smtp.strato.de (RZmta 47.3.3 DYNA|AUTH) with ESMTPSA id U0af7bwAR1IPKa1 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Fri, 27 Nov 2020 02:18:25 +0100 (CET) Received: from rolf-mini.obsigna.com (rolf-mini.obsigna.com [192.168.222.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.obsigna.com (Postfix) with ESMTPSA id C07DA1350F91D; Thu, 26 Nov 2020 22:18:22 -0300 (-03) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Subject: Re: User Space GPIO Interrupt programming - GSoC-2018 From: "Dr. Rolf Jansen" In-Reply-To: Date: Thu, 26 Nov 2020 22:18:22 -0300 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> To: Ian Lepore X-Mailer: Apple Mail (2.3445.104.15) X-Rspamd-Queue-Id: 4Chxb81zWFz3tjq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obsigna.com header.s=strato-dkim-0002 header.b=VcjI1lUt; dmarc=none; spf=pass (mx1.freebsd.org: domain of freebsd-rj@obsigna.com designates 85.215.255.20 as permitted sender) smtp.mailfrom=freebsd-rj@obsigna.com X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:85.215.255.0/24]; RWL_MAILSPIKE_GOOD(0.00)[85.215.255.20:from]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[obsigna.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[85.215.255.20:from]; ASN(0.00)[asn:6724, ipnet:85.215.255.0/24, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[obsigna.com:s=strato-dkim-0002]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[obsigna.com]; SPAMHAUS_ZRD(0.00)[85.215.255.20:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[85.215.255.20:from]; FROM_NAME_HAS_TITLE(1.00)[dr]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm] 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 01:18:29 -0000 > Am 26.11.2020 um 16:56 schrieb Ian Lepore : >=20 > On Tue, 2020-11-24 at 17:14 -0300, Dr. Rolf Jansen wrote: >> Hello >>=20 >> Has anything of the GSoC-2018 efforts made it into the current code >> base? >>=20 >>=20 > = https://wiki.freebsd.org/SummerOfCode2018Projects/UserSpaceGPIOinterrupts >>=20 >> 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. >>=20 >> Perhaps I need to pull the project=C2=B4s changes into the kernel by >> myself. However, before this I would like to ask whether it is worth >> the effort. >>=20 >> Please, can anyone shed some light on this. >>=20 >> Best regards >>=20 >> Rolf >>=20 >=20 > 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. >=20 > If you'd like to give it a try, here's a diff that should apply and > build cleanly on freebsd 12 or 13: >=20 > https://people.freebsd.org/~ian/gpio_gsoc2018.diff >=20 > While there isn't any documentation yet, there is a test program (I > haven't run it yet) that demonstrates all the features: >=20 > = https://github.com/ckraemer/gsoc2018-utils/blob/master/src/gpioc_intr_test= .c >=20 > 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). >=20 > 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=E2=80=99t see warnings. The counting- and timestamping-mode for sure would be very useful. = Perhaps by implementing this, there won=E2=80=99t be no unhandled = interrupts anymore, and hence there won=E2=80=99t be any warnings = either. Best regards Rolf