From owner-freebsd-arm@freebsd.org Thu Nov 26 19:56:40 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 64D2B46EBBE for ; Thu, 26 Nov 2020 19:56:40 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound5a.ore.mailhop.org (outbound5a.ore.mailhop.org [44.233.67.66]) (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 4ChpRq6lc5z3F9F for ; Thu, 26 Nov 2020 19:56:39 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1606420592; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=pmekxssqFMSbqutgQ3oefBR1795zQ3GeXXUOv1gEBDIJCwuw0/QFjsKGSW+xYR6mRRb6gPAA/j50m 5IHfhcFAkphMnwZIlkhXX46KbuEHwJ+ZIDEbKxHpwcri3RmSvTYHgz3/BvpU2BCMepqCbdsIvuhBQO zt4bkh/nrwx1hbelwHqH5hDj4/uFtW1HU4Ah+RqN3mY95YsKP8P6XeBQlqXkY8INCrj0THi6Hw5Ere YfaRbmW7SZig/UoRvTaP1l3ah+MHFiVTT2JIXsG8U4dY/xD9wCbFZAaJlPgnC2siczwgV496S5veHn 7Twcax8LH5xpv0Ax8RNcJXNWx0U0TWQ== 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:to:from:subject:message-id:dkim-signature:from; bh=38J47AFKNw6YDuz/GRBSOrjLXTyFhwzaVQHq+9Uyzgs=; b=lrhiQ+Fc6euYcBeR6Fiip7rdZRW1cSuPVmXciLiUmoFLgwBh/qBq7t7khmmZtB0wDoqVRFbBPgEHG owB10S0Da652Zzz7Ug4y6HFb4sqaQzj3Def+v7MUwSo8EycswyJ5+XM1qIfPzzjEmEpNmH1jFNjx3p UilF3E7azvvH33XWjQggijo81ZB3hUGCx/liDdRV+4XzySceWYF2FyE52UIBZUZ5Xx7DMWbB2ZFJqo rKawaGzB6XWDPPzT2pZA8v+t9sallTnjCMv5KZjYOnN2trp01aOlqUNZgIE8HULrtP9sFzUqUUhiHs +gW0UOpGf6zOAadKilR9SvZp2hFRydA== ARC-Authentication-Results: i=1; outbound3.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:to:from:subject:message-id:from; bh=38J47AFKNw6YDuz/GRBSOrjLXTyFhwzaVQHq+9Uyzgs=; b=ZBTYQxULr3VVPSGsjg5M1Vmc1X/tKZ6Y4NLDnj+xYnQZSmuLab4Lev8clP0eUlzYzeVNp9WyblZ0k EhXePKqLynqEExoLpYD2zzOZC0T24tWQJdF3jeNJH0W4cJjOisVT9JqnZSeceQ+pk/qe87uMBsQgGG mS0rhmNOsMH1E6V95QFS1koaNS52kpJwRF1TzvSby47KvOLfRbdgp1uu+U5fstJXtsUbea9pIp2DvG cET648PoumpYPhSyfOKxWYC3I4avKCCNFa/4cGLGwCz26zUugI9S3dHDFG7tpYA2jFATVbhfvyoOka ZzX7MJVzd/vlXnZJi7Bg28FKjQdwIFg== X-MHO-RoutePath: aGlwcGll X-MHO-User: 7911ea84-3021-11eb-8b39-614106969e8d 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 outbound3.ore.mailhop.org (Halon) with ESMTPSA id 7911ea84-3021-11eb-8b39-614106969e8d; Thu, 26 Nov 2020 19:56:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0AQJuSip077139; Thu, 26 Nov 2020 12:56:28 -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" , freebsd-arm@freebsd.org Date: Thu, 26 Nov 2020 12:56:28 -0700 In-Reply-To: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> References: <2B01780F-D367-48A3-A827-B479030A496D@obsigna.com> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4ChpRq6lc5z3F9F X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:44.224.0.0/11, country:US]; local_wl_from(0.00)[freebsd.org] 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: Thu, 26 Nov 2020 19:56:40 -0000 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). -- Ian