UIO - interrupt performance
We are contemplating porting a large number of device drivers to Linux. The pragmatic solution is to keep them in user mode (using the UIO framework) where possible ... they are written in C++ for a start. The obvious disadvantages of user mode device drivers are security / isolation. The main benefit is ease of development. Do you know what the *technical* disadvantages of this approach might be? I am most concerned about possible impact on interrupt handling. For example, I assume the context switching overhead is higher, and that interrupt latency is more difficult to predict? --jim douglas Avaya UK, Registered in England and Wales under Registered Number 3049861, Registered Address: Avaya House, Cathedral Hill, Guildford, Surrey, GU2 7YL. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
I quite agree with Ben and Christian. I think UIO drivers are usable for simple devices, I think they aren't mature (will it ever be?) to use it with complicated devices or with strict requirement. Regards, Douglas, Jim (Jim) ha scritto: We are contemplating porting a large number of device drivers to Linux. The pragmatic solution is to keep them in user mode (using the UIO framework) where possible ... they are written in C++ for a start. The obvious disadvantages of user mode device drivers are security / isolation. The main benefit is ease of development. Do you know what the *technical* disadvantages of this approach might be? I am most concerned about possible impact on interrupt handling. For example, I assume the context switching overhead is higher, and that interrupt latency is more difficult to predict? --jim douglas Avaya UK, Registered in England and Wales under Registered Number 3049861, Registered Address: Avaya House, Cathedral Hill, Guildford, Surrey, GU2 7YL. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Marco Stornelli Embedded Software Engineer CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni http://www.coritel.it [EMAIL PROTECTED] +39 06 72582838 -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: UIO - interrupt performance
Thomas Petazzoni wrote: There was a presentation on UIO in embedded systems at the latest Embedded Linux Conference in April. The presentation includes a small analysis of UIO's overhead with regard to interrupt latency. See http://www.celinux.org/elc08_presentations/uio080417celfelc08.pdf Bummer, on p. 20 it doesn't describe how the latency was measured. It also doesn't compare in-kernel measurements with equivalent UIO measurements. I don't particularly care what the interrupt latency is, if what is being measured is the time between when the interrupt is signaled to the CPU and the point at which the request_irq()-registered handler runs. Rather, most of the time I care more about how long it takes the kernel to wake up the process that's blocked in a wait_for_completion(), because I do most of my work outside of interrupt handlers (a characteristic of the devices and workloads I deal with, ymmv). In that case, the difference between in-kernel and UIO gets pretty small because the kernel activities at each interrupt are very similar, perhaps differing only by some cache activity. Glad they mention SCHED_[FIFO|RR], though. Without those, you're in for a pretty unpleasant UIO experience. b.g. -- Bill Gatliff [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 RESEND] gpiolib: Add pin change notification
This adds pin change notification to the gpiolib sysfs interface. It
requires 16 extra bytes in gpio_desc iff CONFIG_GPIO_SYSFS which in turn
means, eg, 4k of .bss usage on AVR32. Due to limitations in sysfs, this
patch makes poll(2) and friends work as expected on the value
attribute, though reads on value will never block and there is no
facility for async reads and writes.
Signed-off-by: Ben Nizette [EMAIL PROTECTED]
---
Right, there seems to be a new outgoing mail server between me and you
which viciously attacks tabulations. Until I find the monkey
responsible please accept the patch as an attachment along with my
apologies.
Documentation/gpio.txt | 48 +
drivers/gpio/gpiolib.c | 246 -
2 files changed, 289 insertions(+), 5 deletions(-)
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index b1b9887..998a40f 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -529,6 +529,21 @@ and have the following read/write attributes:
is configured as an output, this value may be written;
any nonzero value is treated as high.
+ notify ... Selects a method for the detection of pin change
+ events. This can be written or read as one of none,
+ irq or a number. If none, no detection will be
+ done, if irq then the change detection will be done
+ by registering an interrupt handler on the line given
+ by gpio_to_irq for that gpio. If a number is written,
+ the gpio will be polled for a state change every n
+ milliseconds where n is the number written. The
+ minimum interval is 10 milliseconds.
+
+ notify_filter ... This can be written and read as one of
+ rising, falling or both. If rising, only
+ rising edges will be reported, similarly for falling
+ and both.
+
GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the
controller implementing GPIOs starting at #42) and have the following
read-only attributes:
@@ -549,6 +564,39 @@ gpiochip nodes (possibly in conjunction with schematics) to determine
the correct GPIO number to use for a given signal.
+Pin Change Notification
+---
+The value attribute of a gpio is pollable. For this to work, you
+must have set up the notify attribute of that gpio to the type of
+detection suitable for the underlying hardware.
+
+If the hardware supports interrupts on both edges and the gpio to
+interrupt line mapping is unique, you should write irq to the notify
+attribute.
+
+If the hardware doesn't support this, or you're unsure, you can write
+a number to the notify attribute. This number is the delay between
+successive polls of the gpio state in milliseconds. You may not poll
+more often than 10ms intervals.
+
+You must use poll mode if communication with the gpio's chip requires
+sleeping. This is the case if, for example, the gpio is part of a
+I2C or SPI GPIO expander.
+
+By default, both rising and falling edges are reported. To filter
+this, you can write one of rising or falling to the notify_filter
+attribute. To go back to being notified of both edge changes, write
+both to this attribute.
+
+Once the notification has been set up, you may use poll(2) and friends
+on the value attribute. This attribute will register as having new
+data ready to be read if and only if there has been a state change
+since the last read(2) to the value attribute.
+
+Note that unlike a regular device file, a read on the value attribute
+will never block whether or not there's new data to be read.
+
+
Exporting from Kernel code
--
Kernel code can explicitly manage exports of GPIOs which have already been
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 9112830..f43f231 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1,6 +1,7 @@
#include linux/kernel.h
#include linux/module.h
#include linux/irq.h
+#include linux/interrupt.h
#include linux/spinlock.h
#include linux/device.h
#include linux/err.h
@@ -49,13 +50,35 @@ struct gpio_desc {
#define FLAG_RESERVED 2
#define FLAG_EXPORT 3 /* protected by sysfs_lock */
#define FLAG_SYSFS 4 /* exported via /sys/class/gpio/control */
+#define ASYNC_MODE_IRQ 5 /* using interrupts for async notification */
+#define ASYNC_MODE_POLL 6 /* using polling for async notification */
+#define ASYNC_RISING 7 /* will notify on rising edges */
+#define ASYNC_FALLING 8 /* will notify on falling edges */
#ifdef CONFIG_DEBUG_FS
const char *label;
#endif
+
+#ifdef CONFIG_GPIO_SYSFS
+ struct device *dev;
+ struct poll_desc *poll;
+
+ /* Poll interval in jiffies, here (rather than in struct poll_desc
+ * so the user can change the value no matter what their current
+ * notification mode is */
+ long timeout;
+
+ /* Last known value */
+ int val;
+#endif
};
static struct gpio_desc gpio_desc[ARCH_NR_GPIOS];
+struct poll_desc {
+ struct delayed_work work;
+ unsigned gpio;
+};
+
static inline void desc_set_label(struct gpio_desc
Re: Subject: [PATCH 01/16] Squashfs: inode operations
Jörn Engel wrote: None of the comments below are a reason against mainline inclusion, imo. They should get handled, but whether that happens before or after a merge doesn't really matter. Yeah you're right regarding your comments. That's where code-review comes in handy, to spot things you don't see because you're too used to the code. I'm working on a re-spin incorporating your comments, and it should be ready tomorrow. Thanks for the code-review. Phillip -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
David P. Quigley wrote: Looking through the code I see two references to xattrs, one is the index of the xattr table in the superblock and there seems to be struct member in one of the inode structures that is an index into this table. Looking through the code I don't see either of these used at all. Do you intend to add xattr support at some point? I saw reference to the desire to add xattr support in an email from 2004 but you said that the code has been rewritten since then. If you are going to add xattr support you probably want to add it to more than just regular files. In SELinux and other LSMs symlinks and directories are also labeled so they will need xattr entries. Yes and yes. I am intending to add xattr support, something that's been on my to-do list for a long time (since 2004 as you said), but it's been something which I've never got the time to do. Once (if) Squashfs is mainlined, it will be the next thing. The xattr references in the layout is my attempt at forward planning to avoid making an incompatible layout change when I finally get around to implementing it. My plan is to put xattrs in a table (referenced by the superblock), and then put indexes in extended inodes which index into the table (as you noticed). The general idea in Squashfs is that inodes get optimised for normally occurring cases, and less common cases (that would need a bigger inode) get to use an extended inode. Squashfs currently has an extended regular file inode, which is where the xattr index will sit, and so this has had an xattr index added. The other inodes don't currently have extended inodes, these will be defined when I implement xattrs (which is why they're missing). Having said that, I've fscked up and forgotten to add an xattr field to the extended directory inode which is currently defined :) Thanks for spotting this. Phillip Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Subject: [PATCH 00/16] Squashfs: compressed read-only filesystem
David P. Quigley wrote: In SELinux and other LSMs symlinks and directories are also labeled so they will need xattr entries. BTW you don't mention device, fifo and socket inodes... Do they ever get labelled? It's something I was going to look into closer to an implementation, but it would be interesting to know. Phillip Dave -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
