From owner-freebsd-hackers@freebsd.org Thu May 30 15:35:55 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC03D15C59E2 for ; Thu, 30 May 2019 15:35:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 046729107D for ; Thu, 30 May 2019 15:35:54 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1559230552; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=VDb/nbPgNJzofDHjnRLrYNRcw8MEv/pESpTWnjZ/oejSJ4J/n/vCngonv/pE7FMXlwe1juyEzq2R9 MljPYDYcyexwQaGxboVIq48XerldimZyIwvOnvZnkiLA0PlwZBTwlFgBAqNHMyuMD0yYXDxFksOqWB 3Kq1Kl2ij4HXPyu7IqyNHUjfLbcDTRuwaRW6aK377tqYWUvMnQySLGyb7dmEMID6s6Rb5VNDZ6Y9P/ iAnrpDzimh79vgy2x0yef0Xa7OoLsOL9r4in4N1nEHivwY2dAjU43pbiOFPioZBDEG8ESi+iqB7SiQ JLYwWGomTBJyC+1UE2SvfgSntObjHrg== 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=KK2g/kryEA0Q0e/a9iE1JzDgLoQ2DTlz414B3QXWOO0=; b=px4GEWna6/d43z2/SrLhZMK94cpZACVfFT3LCE3cEd3BvXt/1w+Kanzz1JbvpGkI7J+EYc7uZbKCV wF+ygKkW+WsUAHhGjeuKIMwE3d+qd/S8OyO5cKSqxUKb4j7CHiD6EKMk5NFr7b3tGvJtd6wA+vx8s2 nTBRg7aISHV24pOV8CMSsFerFfi6znxR+p0OHGkcFLh3pt9gyOV/aln2yrfH7CDvdE1b31iTjiio8N 5GUA9PCcW/mA/BXz0HLpl2lrNwrbelaW4FVBl9E0tVltVDDwxB/lDAu3+iyM0c/LTSONuIV7DUCljR OFbHOvqgIPXkr6rs6XBJtXJa+OZMvOQ== ARC-Authentication-Results: i=1; outbound2.eu.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=KK2g/kryEA0Q0e/a9iE1JzDgLoQ2DTlz414B3QXWOO0=; b=gOsi7hK3qEmAGj0SlsAcfZSelHMZhaD4DfB1tGJBKxG8k7l2lo5SoFYBSwiCUbLt5DHuSMkjFejX/ k1MFSuhnzodaF33i4IGtszmslSsdCtDzPN9d3p6NF10iZvlUXF7LnSn02q/+BzfG5D4SHe3fedPKiG ai5Vhq6hXbhxk0pgh7QLS5fvaYb8l7PDtV+T6ubyKgJM61WahJlFNA66lVHUS72OVONcLrDuVYQ5c2 u1uMbezXXJWKqEWcqJp8S8o7J0sepkWH0B3PE1Xh2ByTRba1XVi4yxAxDE4ZX+VJC8JybupvcPTyuk +BboYr5zRc9zQAoO6l+PPTY/6QG3S4g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 997b1ff7-82f0-11e9-85c6-c97e5c048ed3 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 (unknown [67.177.211.60]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 997b1ff7-82f0-11e9-85c6-c97e5c048ed3; Thu, 30 May 2019 15:35:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x4UFZm5k039379; Thu, 30 May 2019 09:35:48 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: gpio interrupt on x86 From: Ian Lepore To: Andriy Gapon , FreeBSD Hackers Date: Thu, 30 May 2019 09:35:48 -0600 In-Reply-To: <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org> References: <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 046729107D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; ASN(0.00)[asn:16509, ipnet:52.58.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 15:35:56 -0000 On Mon, 2019-05-27 at 18:17 +0300, Andriy Gapon wrote: > I would like to run some code when an input pin changes its state. > A GPIO controller that handles that pin is capable of generating an interrupt. > I can configure the type of a signal change that would trigger the interrupt. > The GPIO controller would generate the interrupt on that change. > I would be able to query the controller for a specific pin (if interrupts for > multiple pins are enabled). > All is good. > > Now, the question is how to _properly_ hook my code to the gpiobus hanging off > the controller. > I see that embedded (or not so embedded) platforms typically define a "slave" > interrupt controller. I guess that it defines a new interrupt number (and > interrupt source, etc) for each interrupt capable pin. And then hooking to that > pin is a matter of just installing an interrupt handler for a specific interrupt > and enabling it. > > But I am not sure if the same approach would work on x86. > Is there any other alternative approach? > Perhaps even a more light-weight one? > Any code examples? > > Thank you. The way this works on modern embedded systems is via INTRNG, a framework that allows any number of interrupt controllers of differing types and capabilities to coexist. A gpio hardware driver registers itself as an interrupt controller, then the interrupts it provides (each gpio pin) are accessible as resources just like interrupts on the primary controller, and so drivers just use interrupts that originate from a gpio pin the same as they would any other interrupt. Of course, one required piece of magic to make all this work is metadata: something needs to make the connection between the gpio controller and pin, and the driver that wants to use changes on that pin as an interrupt indication. In the embedded world it's FDT data that describes those connections, so that when a driver asks for interrupt resource index N it reads the FDT data to find a cross- reference to which gpio device and pin to use for that. The connections between the gpiopin interrupt source and the resources allocated by other drivers are made in nexus. This is because typically there isn't a parent-child relationship between the device that manages the gpio pins and the devices that want to use those pins as a source of interrupts; nexus is the common ancestor of both. The x86 world doesn't use INTRNG (but it must have something similar, since all modern x86 hardware has multiple interrupt controllers). So I'm not sure how a gpio driver for x86 might be an interrupt source, but there should be a way for that to happen. The harder part, I think, will be coming up with the metadata to allow another driver which is not a [grand]child of the gpio controller to use those interrupts. -- Ian