Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 May 2019 09:35:48 -0600
From:      Ian Lepore <ian@freebsd.org>
To:        Andriy Gapon <avg@FreeBSD.org>, FreeBSD Hackers <freebsd-hackers@FreeBSD.org>
Subject:   Re: gpio interrupt on x86
Message-ID:  <cca176e63c8ea40f9f49602f7b5ad977b9ae8e6d.camel@freebsd.org>
In-Reply-To: <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org>
References:  <2c99a77c-a423-c2ea-1b2c-b2eefbae13c1@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cca176e63c8ea40f9f49602f7b5ad977b9ae8e6d.camel>