Re: [PATCH v2 RESEND] gpiolib: Add pin change notification
On Mon, 2008-10-27 at 12:46 -0700, David Brownell wrote: By the way ... I noticed some new use cases for this sort of mechanism. In the OMAP git tree, say the copy at http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git Have a look at arch/arm/plat-omap/gpio-switch.c ... current users include mach-omap2/board-n800.c and mach-omap1/board-palmte.c (in that tree), and report things like headphone jack insertion. Some of that fanciness seems like it shouldn't live in-kernel. I'll be glad to see the need for that driver vanish (except for the need to upgrade userspace, sigh), because of a more generic mechanism existing. :) Cool, I'll check it out. On Monday 20 October 2008, Ben Nizette wrote: 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. Which seems quite problematic to me, for a mechanism that will in most cases not be used and certainly doesn't have the same level of fast-path considerations as gpio get/set operations. How about using a linux/idr.h table to map GPIOs to some notification structure ... and only when such notifications have been configured? A busy system might have one IDR and a handful of 16 byte structs ... lots less than 4KB, and coming out of kmalloc heaps (and thus barely observable). Yeah since akpm's review a few days back, a few things have been rearranged resulting in this figure blowing out to 13k on AVR32. Obviously not acceptable so I'm looking for a nicer way around this. I've been looking at such an IDR, I think it's the way to go yeah. 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. I like poll() and friends working, and the rest seems like it's not something to worry about here. Have you thought about how to leverage the interrupt signals on chips like the pcf857x and pca953x, which have dedicated pin changed signals? They're nothing like the real interrupts, with per-pin irq status and disable masks, found in most SOC-integrated GPIO banks (and in fancier discrete ones). So they seem to me like bad matches for genirq... though I might be persuaded otherwise. Effectively, those IRQ are poll now advice ... advice that is not yet used. (The IRQs all seem to stay active until the GPIO bank status is read, FYI, so you can easily imagine how to fake out some IRQ-ish mechanism.) So long as I allow the interrupt to be shared that should work fine (assuming gpio_to_irq returns the irq of the chip-wide pin change signal for all pins on the chip). akpm pointed out that sysfs_notify() cannot be called from interrupt context so now all irqs are really taken as poll now advice. --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -529,6 +529,21 @@ and have the following read/write attrib 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. That 10 milliseconds seems a bit arbitrary. By analogy to the RTC framework's handling of periodic IRQs, maybe this should be a limit that a privileged user can change. Right. Should this be a sysfs attribute of the gpio class? That seems a sane place to stick it IMO. IMO it's worth noting that polling modes should not be used if IRQs could work ... and that polling *will* miss all changes that happen between polls. Right, changed. + 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. See below ... maybe writing those values to notify should be allowed, for IRQ-driven notification. Then this wouldn't be needed except when polling. And have this attribute appear and disappear? This would break the symmetry between irq and poll driven notification which I quite like. IMO how the change is sensed and whether the change is reported are fairly separate. Though I do agree with your point that we should probably cater for chips which don't support both edge notification, see below. + GPIO controllers have paths like /sys/class
Re: UIO - interrupt performance
On Tue, 2008-10-21 at 08:57 +0200, Wolfgang Grandegger wrote: Ben Nizette wrote: As in examples of the userspace half? Unfortunately uio-smx isn't ready to fly thanks to some significant production delays but the userspace half of the Hilscher CIF driver can be found at http://www.osadl.org/projects/downloads/UIO/user/ As I see it, mainly the license conditions attract people to use UIO. Performance is not that important. Ohw god I hope not. If people want to keep their stuff proprietary they can supply binary-only modules a la nvidia. Thankfully such nonsense is fairly uncommon these days. UIO is not a set of hooks for general userspace drivers, it can't replace 99% of kernel drivers. It exists to allow easy and high-performance interfacing to a particular family of devices - those which simply need to shift data around and have an interrupt telling you when they're done. --Ben. -- 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
On Tue, 2008-10-21 at 11:30 +0200, Marco Stornelli wrote: I could agree, but the facto due to UIO license condition, a company often uses UIO drivers, regardless performance, debug, etc, only as not to public the code under GPL. It sounds to me like you think that driver authors can sit down and decide whether they want to implement their driver in userspace or kernel space. For 99% of drivers that's simply not true. You *cannot* write userspace drivers for most hardware, the hooks just aren't available. UIO is Userspace I/O, not a set of general hooks for userspace drivers. If people want drivers not under the GPL then they can distribute a binary-only module (though thank $DEITY there aren't many of those left). Userspace I/O exists to provide good performance interfacing to a family of devices - those which exist just to shuffle data around and have an interrupt to tell you when they're done. Do you have any example of a userspace i/o driver which exists to get around licencing constraints? --Ben. -- 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: Atmel AT91SAM7S and AT91SAM7A3
On Wed, 2008-06-25 at 19:16 +0200, Michelle Konzack wrote: Hello, I have several projects where I have the need for a microcontroller and I considered to use 8051 compatibles but not it is not more possible because I need an USBHID-PDU device interface, which can only solved using Linux. I like to use the AT91SAM7S and the AT91SAM7A3 (it has 16 AD-Converters) and want to know, whether there is support for accessing the 8 and 16 AD-Converters directly via the Kernel. Also I like to know, which memory size for the AT91 you recommend. I would recommend posting this to a forum at http://www.at91.com. This is a list more for discussion of embedded issues in the kernel than SoC end-user support :-) The current projects are: 1) Solar-Volatge regulator (Uin =68V, Uout=30V) with USB interface to PC or Master controller) 2) 24V PbGel charger (Uin=30V and nearly the same hardware as above) 3) 24V DV modular ATX PSU (special for solarsystems and must support minimal features of an UPS to protect the computer) Q: I have downloaded nearly all stuff about specifications to USBHID and like to know, whether someone can point me to sample codes HOW to code the device stuff... which seems currently not availlable in the Kernel... (It seems, I am the first one WHO need this stuff, but I am not a genie in C programming) Note: eCosCentric sell USB stacks, but for an inacceptable price, since I build only small quantities for my projects. Thanks, Greetings and nice Day/Evening Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- 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: mainlining min-configs...
On Mon, 2008-06-09 at 18:37 -0700, Tim Bird wrote: Rob Landley wrote: On Friday 06 June 2008 18:47:47 Tim Bird wrote: At a minimum, it would be nice to have a few nice examples of really, really small configs for things like qemus for different architectures (just to give embedded developers who are working on size a starting point). That's more or less what I'm trying to do with my Firmware Linux project: creating cross compilers and minimal native build environments for every qemu target. Any chance of getting your minimal configs from Firmware Linux mainlined? allnoconfig? ;-) Does anyone else think this would be valuable? If not in mainline, it would be nice to collect them somewhere, to compare what options different developers decide turn on or off. Seriously though I maintain a bunch of AVR32 minimal configs. I keep them as a smallest-working-config baseline to build on; I'm sure others would get value from having easy access to that kind of thing. IMO It'd be nice to wire them to an automagic bloat-o-meter as well, but I suspect no-one would really take notice anyway. --Ben. -- 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: x11 fails with floating point exception
On Sun, 2008-06-08 at 15:37 +0530, mohammed shareef wrote: Hi, i am new to linux. when i compile x-windows, the xlib--X11 fails with a floating point exception. These are generally things like divide-by-zero. It is a problem with the makekeys script there, nothing to do with the linux kernel or embedded space in general so this isn't the right list :-) Try an X11 mailing list. --Ben. -- 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
