From: joe j. <joe...@qi...> - 2011-04-04 20:02:35
|
Is there a standard method for a user space application to be notified when the kernel receives an interrupt? For example, whenever an external device sends an interrupt to the Gumstix to communicate with it via UART or SPI. I am wondering if there's known methods for my user-space application to be notified so that it can handle the incoming message as soon as possible. The method that comes to mind is dedicating a thread for polling the driver for interrupts via an ioctl blocking call and return once an interrupt is received, however this seems inefficient. Please advice if you know a more efficient way for doing this. -- View this message in context: http://old.nabble.com/Interrupt-notifications-tp31318042p31318042.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-04-04 20:12:48
|
Linux Device Drivers 3rd edition has something about this. http://www.makelinux.net/ldd3/chp-6-sect-4.shtml -- Sent from my Linux box |
From: joe j. <joe...@qi...> - 2011-04-05 13:48:26
|
Yeah, so this section does suggest one could signal interrupts to a user-process with Asynchronous Notification. This is uncharted territory for me, can anyone point me to some sample code for doing this? The Linux Device Drivers section only provides the driver side implementation perspective, but I would like to see something from the user-space perspective. jumpnowdev wrote: > > Linux Device Drivers 3rd edition has something about this. > > http://www.makelinux.net/ldd3/chp-6-sect-4.shtml > > > -- > Sent from my Linux box > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Interrupt-notifications-tp31318042p31324355.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Chris D. <chr...@gm...> - 2011-04-05 14:11:23
|
Check out Dave H.'s gpio-event driver. I know it used to be in the gumstix verdex repository, but might also be in the overo one. It contains a driver and user space program that is pretty easy to follow, especially if you reference back to the LDD book. Chris On Tue, Apr 5, 2011 at 7:48 AM, joe joe <joe...@qi...> wrote: > > Yeah, so this section does suggest one could signal interrupts to a > user-process with Asynchronous Notification. This is uncharted territory > for me, can anyone point me to some sample code for doing this? The Linux > Device Drivers section only provides the driver side implementation > perspective, but I would like to see something from the user-space > perspective. > > > jumpnowdev wrote: > > > > Linux Device Drivers 3rd edition has something about this. > > > > http://www.makelinux.net/ldd3/chp-6-sect-4.shtml > > > > > > -- > > Sent from my Linux box > > > > > > > ------------------------------------------------------------------------------ > > Xperia(TM) PLAY > > It's a major breakthrough. An authentic gaming > > smartphone on the nation's most reliable network. > > And it wants your games. > > http://p.sf.net/sfu/verizon-sfdev > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > -- > View this message in context: > http://old.nabble.com/Interrupt-notifications-tp31318042p31324355.html > Sent from the Gumstix mailing list archive at Nabble.com. > > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Scott E. <sc...@ju...> - 2011-04-05 15:56:17
|
The user side for that LDD3 example is shown in the article. It's this block --- signal(SIGIO, &input_handler); fcntl(STDIN_FILENO, F_SETOWN, getpid()); oflags = fcntl(STDIN_FILENO, F_GETFL); fcntl(STDIN_FILENO, F_SETFL, oflags | FASYNC); --- You just need to implement a standard signal_handler callback (input_handler). Something like this. void input_handler(int sig) { // do something that won't sleep } STDIN_FILENO, refers to the file handle (fh) you would get on opening the device driver which is expected to have a char device interface. fh = open("/dev/mydevice", O_RDWR); So user side is easy. The harder part is the device driver side. If you have an existing driver you should be able to patch in the pieces you need from the article. What you are asking to do isn't trivial since kernel processes don't generally know about user processes unless they are being explicitly invoked to do something on their behalf via a system call. Scott -- Sent from my Linux box |
From: joe j. <joe...@qi...> - 2011-04-07 18:01:59
|
Is it possible to the test async notification feature with the UART, /dev/ttyS0? After setting up my process as described by jumpnowdev: fh = open("/dev/ttyS0", O_RDWR); signal(SIGIO, &input_handler); fcntl(fh, F_SETOWN, getpid()); oflags = fcntl(fh, F_GETFL); fcntl(fh, F_SETFL, oflags | FASYNC); I would expect my process to be notified with a SIGIO signal when there's activity on the port (rx line). Is this a correct assumption? Or is the UART tty driver not prepared for this kind of signalling. I'm just trying to figure out a way to prove this feature with an off-the-shelve driver before I move on to my custom char drivers (SPI, GPMC). jumpnowdev wrote: > > The user side for that LDD3 example is shown in the article. > > It's this block > --- > signal(SIGIO, &input_handler); > > fcntl(STDIN_FILENO, F_SETOWN, getpid()); > > oflags = fcntl(STDIN_FILENO, F_GETFL); > > fcntl(STDIN_FILENO, F_SETFL, oflags | FASYNC); > --- > > You just need to implement a standard signal_handler callback > (input_handler). Something like this. > > void input_handler(int sig) > { > // do something that won't sleep > } > > STDIN_FILENO, refers to the file handle (fh) you would get on opening > the device driver which is expected to have a char device interface. > > fh = open("/dev/mydevice", O_RDWR); > > So user side is easy. > > The harder part is the device driver side. If you have an existing > driver you should be able to patch in the pieces you need from the > article. > > What you are asking to do isn't trivial since kernel processes don't > generally know about user processes unless they are being explicitly > invoked to do something on their behalf via a system call. > > Scott > > -- > Sent from my Linux box > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Interrupt-notifications-tp31318042p31344942.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Scott E. <sc...@ju...> - 2011-04-07 22:24:15
|
It's not my code. It's the authors from the Linux Device Driver book's code. I think it is unlikely the tty driver has implemented this feature in the stock implementation. You'll probably have to write your own test driver. Stepping back a bit. Do you have a specific problem or are you prematurely optimizing? ;-) Remember, it's not like any driver is going to be calling userland code directly from within an interrupt. Your code probably won't even be 'running' when the interrupt occurs. So what is going to happen is the irq handler is going to set some sort of flag and then request to the kernel to schedule another kernel thread to run the non-interrupt portion of the driver code at a later time. When that later time happens, then the driver could send a signal to your userland app if that LDD3 code was implemented. But even when you get that signal, it's not like you can do anything you want in your userland code. About all you can do is set a flag too and then wait for your normally scheduled time-slice from the kernel. Will you really be saving that much over a standard fop 'select' implementation? You said you are going to be writing some modules anyway. Can you architect your application so all the """real-time""" stuff stays in the driver? Just an idea. Scott -- Sent from my Linux box |
From: joe j. <joe...@qi...> - 2011-04-08 02:53:55
|
At this point, I'm just trying to get smart on the mechanisms I think I'll be needing. First, I was able to get the "Asynchronous Notification" mechanism to work and I was able to send a signal from my kernel driver to my user-space application. Now, I'm trying to address how to notify the application when the UART receives data (from some external device) so it can start receiving data from it immediately. I was planning to use the included off-the-shelve ttyS0,S1, etc drivers for this. Other than a "async notify, I don't know how I would go about notifying my application about UART activity. I don't know of a way for the kernel driver to handle the UART data without the application. I'll listens to any suggestions, I'll be doing a similar thing with my own drivers, which I've implemented char drivers for (SPI, GPMC), I'd like these drivers to have the capability to notify the application when an external device is requesting some communication. All this will eventually be running in a multi-process and/or multi-threaded application. jumpnowdev wrote: > > It's not my code. It's the authors from the Linux Device Driver book's > code. > > I think it is unlikely the tty driver has implemented this feature in > the stock implementation. You'll probably have to write your own test > driver. > > Stepping back a bit. > > Do you have a specific problem or are you prematurely optimizing? ;-) > > Remember, it's not like any driver is going to be calling userland code > directly from within an interrupt. Your code probably won't even be > 'running' when the interrupt occurs. > > So what is going to happen is the irq handler is going to set some sort > of flag and then request to the kernel to schedule another kernel thread > to run the non-interrupt portion of the driver code at a later time. > > When that later time happens, then the driver could send a signal to > your userland app if that LDD3 code was implemented. > > But even when you get that signal, it's not like you can do anything you > want in your userland code. About all you can do is set a flag too and > then wait for your normally scheduled time-slice from the kernel. > > Will you really be saving that much over a standard fop 'select' > implementation? > > You said you are going to be writing some modules anyway. Can you > architect your application so all the """real-time""" stuff stays in the > driver? > > Just an idea. > > Scott > > -- > Sent from my Linux box > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Interrupt-notifications-tp31318042p31348222.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Markus S. <msv...@ae...> - 2011-04-08 05:09:05
|
It sounds like you could use the open() system call to open a file descriptor to the serial port device, and then use the poll() or select() system calls in a loop to receive a notification when some data is received. This is about as efficient and and fast a response as you can get from a user space application. I have been doing it this way to read data from all kinds of serial devices, and have had no problems with the approach. Unless your needs are very special, I think you should be able to get good results with the same approach. Some info and example code snippets to get you started: http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html Regards, Markus On 07-Apr-2011 22:53, joe joe wrote: > At this point, I'm just trying to get smart on the mechanisms I think I'll be > needing. > > First, I was able to get the "Asynchronous Notification" mechanism to work > and I was able to send a signal from my kernel driver to my user-space > application. > > Now, I'm trying to address how to notify the application when the UART > receives data (from some external device) so it can start receiving data > from it immediately. I was planning to use the included off-the-shelve > ttyS0,S1, etc drivers for this. Other than a "async notify, I don't know > how I would go about notifying my application about UART activity. I don't > know of a way for the kernel driver to handle the UART data without the > application. I'll listens to any suggestions, > > I'll be doing a similar thing with my own drivers, which I've implemented > char drivers for (SPI, GPMC), I'd like these drivers to have the capability > to notify the application when an external device is requesting some > communication. > > All this will eventually be running in a multi-process and/or multi-threaded > application. > > > > jumpnowdev wrote: >> It's not my code. It's the authors from the Linux Device Driver book's >> code. >> >> I think it is unlikely the tty driver has implemented this feature in >> the stock implementation. You'll probably have to write your own test >> driver. >> >> Stepping back a bit. >> >> Do you have a specific problem or are you prematurely optimizing? ;-) >> >> Remember, it's not like any driver is going to be calling userland code >> directly from within an interrupt. Your code probably won't even be >> 'running' when the interrupt occurs. >> >> So what is going to happen is the irq handler is going to set some sort >> of flag and then request to the kernel to schedule another kernel thread >> to run the non-interrupt portion of the driver code at a later time. >> >> When that later time happens, then the driver could send a signal to >> your userland app if that LDD3 code was implemented. >> >> But even when you get that signal, it's not like you can do anything you >> want in your userland code. About all you can do is set a flag too and >> then wait for your normally scheduled time-slice from the kernel. >> >> Will you really be saving that much over a standard fop 'select' >> implementation? >> >> You said you are going to be writing some modules anyway. Can you >> architect your application so all the """real-time""" stuff stays in the >> driver? >> >> Just an idea. >> >> Scott >> >> -- >> Sent from my Linux box >> >> >> ------------------------------------------------------------------------------ >> Xperia(TM) PLAY >> It's a major breakthrough. An authentic gaming >> smartphone on the nation's most reliable network. >> And it wants your games. >> http://p.sf.net/sfu/verizon-sfdev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> |
From: Dave H. <dhy...@gm...> - 2011-04-08 13:41:20
|
Hi guys, On Fri, Apr 8, 2011 at 6:08 AM, Markus Svilans <msv...@ae...> wrote: > It sounds like you could use the open() system call to open a file > descriptor to the serial port device, and then use the poll() or > select() system calls in a loop to receive a notification when some data > is received. This is about as efficient and and fast a response as you > can get from a user space application. I have been doing it this way to > read data from all kinds of serial devices, and have had no problems > with the approach. Unless your needs are very special, I think you > should be able to get good results with the same approach. I normally launch a thread which is dedicated to reading the serial port. You can issue a read for multiple characters, but set it up so that the read will return when at least 1 character shows up. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com |
From: Markus S. <msv...@ae...> - 2011-04-08 20:15:08
|
Kevyn, Can you share some code, showing how you would use inotify with a serial port, to detect when data is received on the port? Why is that approach better/simpler than using just plain select() or poll()? Markus On 11-04-08 04:00 PM, Kevyn-Alexandre Paré wrote: > Why not using simple inotify with select ! > > http://www.linuxjournal.com/article/8478 > > http://en.wikipedia.org/wiki/Inotify > > http://lxr.linux.no/linux+v2.6.38/Documentation/filesystems/inotify.txt > > > Best Regards > > Kevyn-Alexandre Paré > > On Fri, 2011-04-08 at 14:41 +0100, Dave Hylands wrote: >> Hi guys, >> >> On Fri, Apr 8, 2011 at 6:08 AM, Markus Svilans<msv...@ae...> wrote: >>> It sounds like you could use the open() system call to open a file >>> descriptor to the serial port device, and then use the poll() or >>> select() system calls in a loop to receive a notification when some data >>> is received. This is about as efficient and and fast a response as you >>> can get from a user space application. I have been doing it this way to >>> read data from all kinds of serial devices, and have had no problems >>> with the approach. Unless your needs are very special, I think you >>> should be able to get good results with the same approach. >> I normally launch a thread which is dedicated to reading the serial port. >> >> You can issue a read for multiple characters, but set it up so that >> the read will return when at least 1 character shows up. >> > > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Kevyn-Alexandre P. <ka...@ro...> - 2011-04-08 21:41:19
|
Markus, Scott have written "Do you have a specific problem or are you prematurely optimizing? ;-) " And Joe seem to be interested in being notify when data as been write. But it's not clear at what level? Since It require to have access to it from userland inotify have a flag to only watch this (IN_MODIFY). I think that there is enough userland API already provided by Kernel to check this. Mixing kernel and userland should be done if no API are already fulfilling is needs. This is why I suggest this. I was building, last year, a software with the possibility of having multiple Input and one Output involving serial communication other type of files. inotify API was what I used because it fulfil my needs. My inspiration came from previous article and my search also found that udev and avahi was using this and inspired my self from it. Using inotify for device notification & file changes (Since udev138: Device nodes can be watched for changes with inotify with OPTIONS="watch".) git clone git://git.kernel.org/pub/scm/linux/hotplug/udev.git Using file changes if file change ex: /etc/avahi/services/ git clone git://git.0pointer.de/avahi.git Reading the article Linux Journal is good starting point! Best Regards Kevyn-Alexandre Paré On Fri, 2011-04-08 at 16:14 -0400, Markus Svilans wrote: > aeonyx.ca> |
From: Dave H. <dhy...@gm...> - 2011-04-10 23:32:29
|
Hi Markus, On Fri, Apr 8, 2011 at 9:14 PM, Markus Svilans <msv...@ae...> wrote: > Kevyn, > > Can you share some code, showing how you would use inotify with a serial > port, to detect when data is received on the port? Why is that approach > better/simpler than using just plain select() or poll()? When using select or poll, there may be some latency since your thread which does the select or poll may be off doing something else when the new data arrive son the serial port. When you use inotify, I see 2 choices: 1 - you process the data in the signal handler - which reduces the latency, or 2 - you just set a flag which causes the data to be processed later - which is essentially the same as select/poll. inotify will still have slightly higher latency than using a separate thread, since signal handlers are only called when the user code does system calls. Using a separate thread gives the best responsiveness, but has a slightly higher complexity to setup than using inotify or select/poll. Using a separate thread should also require less kernel-to-user transitions. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com |
From: Kevyn-Alexandre P. <ka...@ro...> - 2011-04-11 18:38:35
|
Hi Dave, Markus, Instead of signals, inotify communicates with applications via a single file descriptor. This file descriptor is select-, poll-, epoll- and read-able. Simple and fast. Also, On Mon, 2011-04-11 at 00:32 +0100, Dave Hylands wrote: > Hi Markus, > > On Fri, Apr 8, 2011 at 9:14 PM, Markus Svilans <msv...@ae...> wrote: > > Kevyn, > > > > Can you share some code, showing how you would use inotify with a serial > > port, to detect when data is received on the port? Why is that approach > > better/simpler than using just plain select() or poll()? > > When using select or poll, there may be some latency since your thread > which does the select or poll may be off doing something else when the > new data arrive son the serial port. > > When you use inotify, I see 2 choices: 1 - you process the data in the > signal handler - which reduces the latency, The old version, called dnotify, interface to user space is signals. Not inotify the new version. > or 2 - you just set a flag > which causes the data to be processed later - which is essentially the > same as select/poll. A call to inotify_add_watch() adds a watch for the one or more events given by the bitmask mask on the file path to the inotify instance associated with the file descriptor fd. > inotify will still have slightly higher latency > than using a separate thread, since signal handlers are only called > when the user code does system calls. > > Using a separate thread gives the best responsiveness, but has a > slightly higher complexity to setup than using inotify or select/poll. > > Using a separate thread should also require less kernel-to-user transitions. > Blocking on a read() system call does not give nice responsiveness, unless your application is multi thread, You will need to add that new thread! Like Robert says: "Thankfully, the inotify file descriptor can be polled or selected on, allowing inotify to be multiplexed along with other I/O and optionally integrated into an application's mainloop." You can found advantages / disadvantages on internet about select / poll (Poll have been design to fix problem of select, but this one is sometimes even use for a reason of compatibility). Epoll is there to improve poll / select limitations, when hundreds of file descriptors have to be polled. Concerning the latency, it depends on your needs. Inotify events are queued asynchronously, in real time as the events happen. It's to you to decide how you will read these event if latency is a real issue and not early optimization. Best Regards, Kevyn-Alexandre Paré |
From: Jeff D. <je...@gr...> - 2011-05-09 22:59:20
|
I've implemented the simple poll interface in drivers that work on serial data but aren't real serial ports, based on other examples I've seen (kernel 2.6.32/33). select/pselect probably use the poll interface internally, or a similar one. Each driver has a standard poll hook that adds a wait queue to a standard poll list. When new data is available (or there's an error), the hardware event handlers signal the wait queue, and the kernel poll system handles the blocking, unblocking, and timeouts for you. The driver sets the POLL* flags before you exit the poll hook. The driver read hooks can block on the same wait queue, if desired. unsigned int driver_poll(struct file *file, struct poll_table_struct *pt) { unsigned int mask = 0; poll_wait(file, &read_wait_queue, pt); if (data_available) mask |= POLLIN | POLLRDNORM; else if (read_error) mask |= POLLERR; return mask; } You should be able to find many examples of this in the kernel. Jeff DeFouw <je...@gr...> Programmer Grand Rapids Technologies On 5/9/2011 5:45 PM, joe joe wrote: > > I am trying to use pselect() now for detecting and handling driver file > descriptor activity and signals. So far I have been successful at proving > out the file descriptor activity by having pselect() check the packaged > Linux serial drivers (/dev/ttyS0 and ttyS1). The pselec() returns when I > write to the ttySX port from an external device (from my Linux workstation) > and tells me which of the two ports I actually wrote to and has data for me > to handle. > > Next, I was trying to incorporate signal handling with pselect(), this is > one thing that pselect can do that select() does not. I was wondering if > anyone knew of an easy way to check out the pselect() signal handling > functionality? I was trying to do this with the serial port drivers, but > failed short since I don't know how to trigger the driver to send a signal > to the user-space process. > > I mentioned earlier in this thread that I have been successful in > implementing an asynchronous notification signal from one of my custom > kernel drivers to user-space. Then I figured I would use this custom driver > to send my signal to prove out my pselect() functionality but ran into an > issue where it doesn't play nice with pselect() or select(). My driver > causes the pselect() to not block and instead immediately return with > erroneous non-existing notifications. Seems like I would have to add logic > in my driver to explicitly block the calling task until there was data > available or some event occurs. Does anyone have any idea what logic I need > to incorporate in my custom driver to handle pselec()? > > > > Markus Svilans-2 wrote: >> >> It sounds like you could use the open() system call to open a file >> descriptor to the serial port device, and then use the poll() or >> select() system calls in a loop to receive a notification when some data >> is received. This is about as efficient and and fast a response as you >> can get from a user space application. I have been doing it this way to >> read data from all kinds of serial devices, and have had no problems >> with the approach. Unless your needs are very special, I think you >> should be able to get good results with the same approach. >> >> Some info and example code snippets to get you started: >> http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html >> >> Regards, >> Markus >> >> >> On 07-Apr-2011 22:53, joe joe wrote: >>> At this point, I'm just trying to get smart on the mechanisms I think >>> I'll be >>> needing. >>> >>> First, I was able to get the "Asynchronous Notification" mechanism to >>> work >>> and I was able to send a signal from my kernel driver to my user-space >>> application. >>> >>> Now, I'm trying to address how to notify the application when the UART >>> receives data (from some external device) so it can start receiving data >>> from it immediately. I was planning to use the included off-the-shelve >>> ttyS0,S1, etc drivers for this. Other than a "async notify, I don't know >>> how I would go about notifying my application about UART activity. I >>> don't >>> know of a way for the kernel driver to handle the UART data without the >>> application. I'll listens to any suggestions, >>> >>> I'll be doing a similar thing with my own drivers, which I've implemented >>> char drivers for (SPI, GPMC), I'd like these drivers to have the >>> capability >>> to notify the application when an external device is requesting some >>> communication. >>> >>> All this will eventually be running in a multi-process and/or >>> multi-threaded >>> application. >>> >>> >>> >>> jumpnowdev wrote: >>>> It's not my code. It's the authors from the Linux Device Driver book's >>>> code. >>>> >>>> I think it is unlikely the tty driver has implemented this feature in >>>> the stock implementation. You'll probably have to write your own test >>>> driver. >>>> >>>> Stepping back a bit. >>>> >>>> Do you have a specific problem or are you prematurely optimizing? ;-) >>>> >>>> Remember, it's not like any driver is going to be calling userland code >>>> directly from within an interrupt. Your code probably won't even be >>>> 'running' when the interrupt occurs. >>>> >>>> So what is going to happen is the irq handler is going to set some sort >>>> of flag and then request to the kernel to schedule another kernel thread >>>> to run the non-interrupt portion of the driver code at a later time. >>>> >>>> When that later time happens, then the driver could send a signal to >>>> your userland app if that LDD3 code was implemented. >>>> >>>> But even when you get that signal, it's not like you can do anything you >>>> want in your userland code. About all you can do is set a flag too and >>>> then wait for your normally scheduled time-slice from the kernel. >>>> >>>> Will you really be saving that much over a standard fop 'select' >>>> implementation? >>>> >>>> You said you are going to be writing some modules anyway. Can you >>>> architect your application so all the """real-time""" stuff stays in the >>>> driver? >>>> >>>> Just an idea. >>>> >>>> Scott >>>> >>>> -- >>>> Sent from my Linux box >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Xperia(TM) PLAY >>>> It's a major breakthrough. An authentic gaming >>>> smartphone on the nation's most reliable network. >>>> And it wants your games. >>>> http://p.sf.net/sfu/verizon-sfdev >>>> _______________________________________________ >>>> gumstix-users mailing list >>>> gum...@li... >>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>> >>>> >> >> ------------------------------------------------------------------------------ >> Xperia(TM) PLAY >> It's a major breakthrough. An authentic gaming >> smartphone on the nation's most reliable network. >> And it wants your games. >> http://p.sf.net/sfu/verizon-sfdev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > |
From: joe j. <joe...@qi...> - 2011-05-10 04:06:04
|
Is it possible for you post one of your driver implementations which uses this poll interface you speak of? Seeing in context might make more sense to me. I also just realized that I could generate a SIGINT signals using ctrl-C from my keyboard and be able to cause an interrupt on pselect() during the blocking period. With this I was able to prove that my pselect() signal handling routine at least works. I would ultimately like to generate these types of signals from my own custom driver. I guess that means I have to solve my original issue of making my driver handle pselect() calls first. Jeff DeFouw-2 wrote: > > I've implemented the simple poll interface in drivers that work on serial > data > but aren't real serial ports, based on other examples I've seen (kernel > 2.6.32/33). select/pselect probably use the poll interface internally, or > a > similar one. Each driver has a standard poll hook that adds a wait queue > to a > standard poll list. When new data is available (or there's an error), the > hardware event handlers signal the wait queue, and the kernel poll system > handles the blocking, unblocking, and timeouts for you. The driver sets > the > POLL* flags before you exit the poll hook. The driver read hooks can > block on > the same wait queue, if desired. > > unsigned int driver_poll(struct file *file, struct poll_table_struct *pt) > { > unsigned int mask = 0; > poll_wait(file, &read_wait_queue, pt); > if (data_available) > mask |= POLLIN | POLLRDNORM; > else if (read_error) > mask |= POLLERR; > return mask; > } > > You should be able to find many examples of this in the kernel. > > > Jeff DeFouw <je...@gr...> > Programmer > Grand Rapids Technologies > > On 5/9/2011 5:45 PM, joe joe wrote: >> >> I am trying to use pselect() now for detecting and handling driver file >> descriptor activity and signals. So far I have been successful at >> proving >> out the file descriptor activity by having pselect() check the packaged >> Linux serial drivers (/dev/ttyS0 and ttyS1). The pselec() returns when I >> write to the ttySX port from an external device (from my Linux >> workstation) >> and tells me which of the two ports I actually wrote to and has data for >> me >> to handle. >> >> Next, I was trying to incorporate signal handling with pselect(), this is >> one thing that pselect can do that select() does not. I was wondering if >> anyone knew of an easy way to check out the pselect() signal handling >> functionality? I was trying to do this with the serial port drivers, but >> failed short since I don't know how to trigger the driver to send a >> signal >> to the user-space process. >> >> I mentioned earlier in this thread that I have been successful in >> implementing an asynchronous notification signal from one of my custom >> kernel drivers to user-space. Then I figured I would use this custom >> driver >> to send my signal to prove out my pselect() functionality but ran into an >> issue where it doesn't play nice with pselect() or select(). My driver >> causes the pselect() to not block and instead immediately return with >> erroneous non-existing notifications. Seems like I would have to add >> logic >> in my driver to explicitly block the calling task until there was data >> available or some event occurs. Does anyone have any idea what logic I >> need >> to incorporate in my custom driver to handle pselec()? >> >> >> >> Markus Svilans-2 wrote: >>> >>> It sounds like you could use the open() system call to open a file >>> descriptor to the serial port device, and then use the poll() or >>> select() system calls in a loop to receive a notification when some data >>> is received. This is about as efficient and and fast a response as you >>> can get from a user space application. I have been doing it this way to >>> read data from all kinds of serial devices, and have had no problems >>> with the approach. Unless your needs are very special, I think you >>> should be able to get good results with the same approach. >>> >>> Some info and example code snippets to get you started: >>> http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html >>> >>> Regards, >>> Markus >>> >>> >>> On 07-Apr-2011 22:53, joe joe wrote: >>>> At this point, I'm just trying to get smart on the mechanisms I think >>>> I'll be >>>> needing. >>>> >>>> First, I was able to get the "Asynchronous Notification" mechanism to >>>> work >>>> and I was able to send a signal from my kernel driver to my user-space >>>> application. >>>> >>>> Now, I'm trying to address how to notify the application when the UART >>>> receives data (from some external device) so it can start receiving >>>> data >>>> from it immediately. I was planning to use the included off-the-shelve >>>> ttyS0,S1, etc drivers for this. Other than a "async notify, I don't >>>> know >>>> how I would go about notifying my application about UART activity. I >>>> don't >>>> know of a way for the kernel driver to handle the UART data without the >>>> application. I'll listens to any suggestions, >>>> >>>> I'll be doing a similar thing with my own drivers, which I've >>>> implemented >>>> char drivers for (SPI, GPMC), I'd like these drivers to have the >>>> capability >>>> to notify the application when an external device is requesting some >>>> communication. >>>> >>>> All this will eventually be running in a multi-process and/or >>>> multi-threaded >>>> application. >>>> >>>> >>>> >>>> jumpnowdev wrote: >>>>> It's not my code. It's the authors from the Linux Device Driver book's >>>>> code. >>>>> >>>>> I think it is unlikely the tty driver has implemented this feature in >>>>> the stock implementation. You'll probably have to write your own test >>>>> driver. >>>>> >>>>> Stepping back a bit. >>>>> >>>>> Do you have a specific problem or are you prematurely optimizing? ;-) >>>>> >>>>> Remember, it's not like any driver is going to be calling userland >>>>> code >>>>> directly from within an interrupt. Your code probably won't even be >>>>> 'running' when the interrupt occurs. >>>>> >>>>> So what is going to happen is the irq handler is going to set some >>>>> sort >>>>> of flag and then request to the kernel to schedule another kernel >>>>> thread >>>>> to run the non-interrupt portion of the driver code at a later time. >>>>> >>>>> When that later time happens, then the driver could send a signal to >>>>> your userland app if that LDD3 code was implemented. >>>>> >>>>> But even when you get that signal, it's not like you can do anything >>>>> you >>>>> want in your userland code. About all you can do is set a flag too and >>>>> then wait for your normally scheduled time-slice from the kernel. >>>>> >>>>> Will you really be saving that much over a standard fop 'select' >>>>> implementation? >>>>> >>>>> You said you are going to be writing some modules anyway. Can you >>>>> architect your application so all the """real-time""" stuff stays in >>>>> the >>>>> driver? >>>>> >>>>> Just an idea. >>>>> >>>>> Scott >>>>> >>>>> -- >>>>> Sent from my Linux box >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Xperia(TM) PLAY >>>>> It's a major breakthrough. An authentic gaming >>>>> smartphone on the nation's most reliable network. >>>>> And it wants your games. >>>>> http://p.sf.net/sfu/verizon-sfdev >>>>> _______________________________________________ >>>>> gumstix-users mailing list >>>>> gum...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>>>> >>>>> >>> >>> ------------------------------------------------------------------------------ >>> Xperia(TM) PLAY >>> It's a major breakthrough. An authentic gaming >>> smartphone on the nation's most reliable network. >>> And it wants your games. >>> http://p.sf.net/sfu/verizon-sfdev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> >> > > ------------------------------------------------------------------------------ > Achieve unprecedented app performance and reliability > What every C/C++ and Fortran developer should know. > Learn how Intel has extended the reach of its next-generation tools > to help boost performance applications - inlcuding clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Interrupt-notifications-tp31318042p31582588.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2011-05-10 05:25:33
|
Hi Joe, On Mon, May 9, 2011 at 9:05 PM, joe joe <joe...@qi...> wrote: > > Is it possible for you post one of your driver implementations which uses > this poll interface you speak of? Seeing in context might make more sense > to me. I have an example over here: <http://svn.hylands.org/linux/gpio-event/module/gpio-event-drv.c> Search for the function gpio_event_poll. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com |
From: joe j. <joe...@qi...> - 2011-07-22 20:04:46
|
I had previously mentioned I was successful implementing an Asynchronous Notification mechanism from my kernel-space driver to my user-space application. I'm now using this mechanism to notify my application when my driver has data ready to be processed. Does anyone know if there's a way to send some data along with this async notification signal. I'd like to send some driver state info to the application in this same signal, is this possible? I'd hate to do a separate Ioctl call to my driver just to access this state information I need. joe joe wrote: > > At this point, I'm just trying to get smart on the mechanisms I think I'll > be needing. > > First, I was able to get the "Asynchronous Notification" mechanism to work > and I was able to send a signal from my kernel driver to my user-space > application. > > Now, I'm trying to address how to notify the application when the UART > receives data (from some external device) so it can start receiving data > from it immediately. I was planning to use the included off-the-shelve > ttyS0,S1, etc drivers for this. Other than a "async notify, I don't know > how I would go about notifying my application about UART activity. I > don't know of a way for the kernel driver to handle the UART data without > the application. I'll listens to any suggestions, > > I'll be doing a similar thing with my own drivers, which I've implemented > char drivers for (SPI, GPMC), I'd like these drivers to have the > capability to notify the application when an external device is requesting > some communication. > > All this will eventually be running in a multi-process and/or > multi-threaded application. > > > > jumpnowdev wrote: >> >> It's not my code. It's the authors from the Linux Device Driver book's >> code. >> >> I think it is unlikely the tty driver has implemented this feature in >> the stock implementation. You'll probably have to write your own test >> driver. >> >> Stepping back a bit. >> >> Do you have a specific problem or are you prematurely optimizing? ;-) >> >> Remember, it's not like any driver is going to be calling userland code >> directly from within an interrupt. Your code probably won't even be >> 'running' when the interrupt occurs. >> >> So what is going to happen is the irq handler is going to set some sort >> of flag and then request to the kernel to schedule another kernel thread >> to run the non-interrupt portion of the driver code at a later time. >> >> When that later time happens, then the driver could send a signal to >> your userland app if that LDD3 code was implemented. >> >> But even when you get that signal, it's not like you can do anything you >> want in your userland code. About all you can do is set a flag too and >> then wait for your normally scheduled time-slice from the kernel. >> >> Will you really be saving that much over a standard fop 'select' >> implementation? >> >> You said you are going to be writing some modules anyway. Can you >> architect your application so all the """real-time""" stuff stays in the >> driver? >> >> Just an idea. >> >> Scott >> >> -- >> Sent from my Linux box >> >> >> ------------------------------------------------------------------------------ >> Xperia(TM) PLAY >> It's a major breakthrough. An authentic gaming >> smartphone on the nation's most reliable network. >> And it wants your games. >> http://p.sf.net/sfu/verizon-sfdev >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users >> >> > > -- View this message in context: http://old.nabble.com/Interrupt-notifications-tp31318042p32118062.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Dave H. <dhy...@gm...> - 2011-07-22 20:59:30
|
Hi Joe, On Fri, Jul 22, 2011 at 2:04 PM, joe joe <joe...@qi...> wrote: > > > I had previously mentioned I was successful implementing an Asynchronous > Notification mechanism from my kernel-space driver to my user-space > application. I'm now using this mechanism to notify my application when my > driver has data ready to be processed. Does anyone know if there's a way to > send some data along with this async notification signal. I'd like to send > some driver state info to the application in this same signal, is this > possible? > > I'd hate to do a separate Ioctl call to my driver just to access this state > information I need. To the best of my knowledge, there isn't any way to send data along with a signal. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com |
From: Philip B. <ph...@ba...> - 2011-04-04 20:19:58
|
On 04/04/2011 04:02 PM, joe joe wrote: > > Is there a standard method for a user space application to be notified when > the kernel receives an interrupt? For example, whenever an external device > sends an interrupt to the Gumstix to communicate with it via UART or SPI. I > am wondering if there's known methods for my user-space application to be > notified so that it can handle the incoming message as soon as possible. > > The method that comes to mind is dedicating a thread for polling the driver > for interrupts via an ioctl blocking call and return once an interrupt is > received, however this seems inefficient. Please advice if you know a more > efficient way for doing this. This might be helpful: http://lwn.net/Articles/232575/ Philip |
From: Kevyn-Alexandre P. <ka...@ro...> - 2011-04-08 20:01:08
|
Why not using simple inotify with select ! http://www.linuxjournal.com/article/8478 http://en.wikipedia.org/wiki/Inotify http://lxr.linux.no/linux+v2.6.38/Documentation/filesystems/inotify.txt Best Regards Kevyn-Alexandre Paré On Fri, 2011-04-08 at 14:41 +0100, Dave Hylands wrote: > Hi guys, > > On Fri, Apr 8, 2011 at 6:08 AM, Markus Svilans <msv...@ae...> wrote: > > It sounds like you could use the open() system call to open a file > > descriptor to the serial port device, and then use the poll() or > > select() system calls in a loop to receive a notification when some data > > is received. This is about as efficient and and fast a response as you > > can get from a user space application. I have been doing it this way to > > read data from all kinds of serial devices, and have had no problems > > with the approach. Unless your needs are very special, I think you > > should be able to get good results with the same approach. > > I normally launch a thread which is dedicated to reading the serial port. > > You can issue a read for multiple characters, but set it up so that > the read will return when at least 1 character shows up. > |
From: joe j. <joe...@qi...> - 2011-05-09 21:46:04
|
I am trying to use pselect() now for detecting and handling driver file descriptor activity and signals. So far I have been successful at proving out the file descriptor activity by having pselect() check the packaged Linux serial drivers (/dev/ttyS0 and ttyS1). The pselec() returns when I write to the ttySX port from an external device (from my Linux workstation) and tells me which of the two ports I actually wrote to and has data for me to handle. Next, I was trying to incorporate signal handling with pselect(), this is one thing that pselect can do that select() does not. I was wondering if anyone knew of an easy way to check out the pselect() signal handling functionality? I was trying to do this with the serial port drivers, but failed short since I don't know how to trigger the driver to send a signal to the user-space process. I mentioned earlier in this thread that I have been successful in implementing an asynchronous notification signal from one of my custom kernel drivers to user-space. Then I figured I would use this custom driver to send my signal to prove out my pselect() functionality but ran into an issue where it doesn't play nice with pselect() or select(). My driver causes the pselect() to not block and instead immediately return with erroneous non-existing notifications. Seems like I would have to add logic in my driver to explicitly block the calling task until there was data available or some event occurs. Does anyone have any idea what logic I need to incorporate in my custom driver to handle pselec()? Markus Svilans-2 wrote: > > It sounds like you could use the open() system call to open a file > descriptor to the serial port device, and then use the poll() or > select() system calls in a loop to receive a notification when some data > is received. This is about as efficient and and fast a response as you > can get from a user space application. I have been doing it this way to > read data from all kinds of serial devices, and have had no problems > with the approach. Unless your needs are very special, I think you > should be able to get good results with the same approach. > > Some info and example code snippets to get you started: > http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html > > Regards, > Markus > > > On 07-Apr-2011 22:53, joe joe wrote: >> At this point, I'm just trying to get smart on the mechanisms I think >> I'll be >> needing. >> >> First, I was able to get the "Asynchronous Notification" mechanism to >> work >> and I was able to send a signal from my kernel driver to my user-space >> application. >> >> Now, I'm trying to address how to notify the application when the UART >> receives data (from some external device) so it can start receiving data >> from it immediately. I was planning to use the included off-the-shelve >> ttyS0,S1, etc drivers for this. Other than a "async notify, I don't know >> how I would go about notifying my application about UART activity. I >> don't >> know of a way for the kernel driver to handle the UART data without the >> application. I'll listens to any suggestions, >> >> I'll be doing a similar thing with my own drivers, which I've implemented >> char drivers for (SPI, GPMC), I'd like these drivers to have the >> capability >> to notify the application when an external device is requesting some >> communication. >> >> All this will eventually be running in a multi-process and/or >> multi-threaded >> application. >> >> >> >> jumpnowdev wrote: >>> It's not my code. It's the authors from the Linux Device Driver book's >>> code. >>> >>> I think it is unlikely the tty driver has implemented this feature in >>> the stock implementation. You'll probably have to write your own test >>> driver. >>> >>> Stepping back a bit. >>> >>> Do you have a specific problem or are you prematurely optimizing? ;-) >>> >>> Remember, it's not like any driver is going to be calling userland code >>> directly from within an interrupt. Your code probably won't even be >>> 'running' when the interrupt occurs. >>> >>> So what is going to happen is the irq handler is going to set some sort >>> of flag and then request to the kernel to schedule another kernel thread >>> to run the non-interrupt portion of the driver code at a later time. >>> >>> When that later time happens, then the driver could send a signal to >>> your userland app if that LDD3 code was implemented. >>> >>> But even when you get that signal, it's not like you can do anything you >>> want in your userland code. About all you can do is set a flag too and >>> then wait for your normally scheduled time-slice from the kernel. >>> >>> Will you really be saving that much over a standard fop 'select' >>> implementation? >>> >>> You said you are going to be writing some modules anyway. Can you >>> architect your application so all the """real-time""" stuff stays in the >>> driver? >>> >>> Just an idea. >>> >>> Scott >>> >>> -- >>> Sent from my Linux box >>> >>> >>> ------------------------------------------------------------------------------ >>> Xperia(TM) PLAY >>> It's a major breakthrough. An authentic gaming >>> smartphone on the nation's most reliable network. >>> And it wants your games. >>> http://p.sf.net/sfu/verizon-sfdev >>> _______________________________________________ >>> gumstix-users mailing list >>> gum...@li... >>> https://lists.sourceforge.net/lists/listinfo/gumstix-users >>> >>> > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > -- View this message in context: http://old.nabble.com/Interrupt-notifications-tp31318042p31580917.html Sent from the Gumstix mailing list archive at Nabble.com. |