Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 May 2018 19:40:54 +0200
From:      Christian =?ISO-8859-1?Q?Kr=E4mer?= <uddka@student.kit.edu>
To:        soc-status@freebsd.org
Cc:        Chuck Tuffli <chuck@freebsd.org>, Luiz Otavio O Souza <loos.br@gmail.com>
Subject:   User space interface for GPIO interrupts / Status Report Week 2
Message-ID:  <20180528194054.b44df7621d933376ee686dde@student.kit.edu>

next in thread | raw e-mail | index | archive | help
Dear all,

since my last status report I implemented dynamic reconfiguration of the monitored pin and also started to write user space tools [1] to communicate with the gpiointr device driver [2].

Furthermore the gpiointr driver was moved away from simplebus, so that one instance of the gpiointr driver is now attached to each gpio controller. As a result no modified DTB file is needed any more and all GPIO pins can be configured in a consistent way like gpio(3) and gpioc.

The configuration of, for example, pin 5 on gpiobus0 looks like this:
$ gpiointr_config -f /dev/gpiointr0 5

Monitoring of the pin is still done by a read() syscall that will block until an interrupt on the pin is triggered.

During this week I am going to implement locking mechanisms in order to avoid race conditions and start to move forward to dynamic resource management to be able to register interrupts for multiple pins on a specific gpiobus. Additionally the trigger type will become runtime configurable.

Thanks,
Chris

[1] <https://github.com/ckraemer/gsoc2018-utils>;
[2] <https://github.com/ckraemer/freebsd/tree/gsoc2018>;



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