From: neo <prag.in...@gmail.com> Reply-To: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> Date: Wednesday, September 10, 2014 at 5:13 AM To: "beagleboard@googlegroups.com" <beagleboard@googlegroups.com> Subject: Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space
> Hi Brandon > > Thanks for the reply. > I will summarize here what i found about controlling a GPIO and about using > interrupts. > 1. Using sysfs one can easily control the gpio and using threading can > re-create pseudo-interrupt from user space. Found a useful project called > libsoc https://github.com/jackmitch/libsoc. They use threading along with > polling using poll(2) > 2. Using mmap() one can import the memory space of the GPIO peripheral and > with a combination of threads can re-create pseudo-interrupt from user space. > Found useful project called BBBIOlib > https://github.com/VegetableAvenger/BBBIOlib. > 3. Using /dev/input/event for controlling GPIO from user space. > 4. Using an LKM from kernel space where one can use request_irq() or > request_threaded_irq() and using some kind of buffering to transfer the data > to userspace. Here one will be writing actual interrupts. Some bits can be > found here > http://processors.wiki.ti.com/index.php/GPIO_Driver_Guide#Sysfs_entries_config > uration > I have very good idea about 1 and 2. > > I am still working on 3-> /dev/input and also on 4-> about writing a real ISR. > > Although the above methods enable GPIO control I am not sure which will give > me the highest performance. > > I read that using mmap() method gives faster switching on forums and the using > sysfs gives the slowest switching rate. I am not sure about /dev/input method. > The LKM method gives faster ISR and i am guessing that LKM in combination with > mmap() will give faster response timings. > > Any thoughts on the above... You are on the right path. One thing to remember, whenever you are doing any I/O from user space, you are dealing with context switching and thread scheduling, which means that your application won¹t respond to a GPIO event for anywhere from a few ms to 100mS. This is true because of both the interrupt latency in Linux and thread scheduler. In most cases, this is fine, because the user doesn¹t know the difference. However, if you are attempting to do some sort of control, then you may want to consider the PRU. The PRU can still send events to your user space app. Another solution might be Xenomai which reduces to interrupt latency to about 50uS on the BBB, but you still have the context switch delay. Regards, John > > On Wednesday, September 10, 2014 8:20:18 AM UTC+5:30, Brandon I wrote: >> Before you jump into the kernel hole, is there a reason that you're not using >> the existing sysfs gpio interface >> (https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) for the interrupts? >> >> Using this, if you set the gpio up as an interrupt with the sysfs interface, >> you poll() the value file and it will block until there's an interrupt. When >> it unblocks, you can read the current value. >> >> Or, you can make the gpio look like an event/button: >> http://bec-systems.com/site/281/how-to-implement-an-interrupt-driven-gpio-inp >> ut-in-linux >> >> Any sane way you do it will be the same at the low level. You'll have a read >> or ioctl function on the kernel device file that blocks in the kernel using a >> completion/semaphore, putting your process/thread to sleep. When the >> interrupt fires, the interrupt handler function is called to release the >> completion/semaphore, unblocking your process/thread and allowing it to >> continue executing. This unblocking is how the userspace program is signaled. >> >> So, if you *want* to reinvent the wheel, for understanding, then that's fine. >> But, there's an existing interface that exists, only a few lines of code >> away. >> >> --Brandon >> >> On Tue, Sep 9, 2014 at 7:10 PM, neo star <prag....@gmail.com <javascript:> > >> wrote: >>> Hi Brandon >>> >>> I read through the link, very informative thanks.I can create a thread to do >>> the polling and signal me when its ready. >>> But how to really write an ISR in arm. I see a lot of guides but they say >>> that it will work in Intel processors but they are not sure about ARM. >>> For sure from my readings i see that i need a kernel object to handle an >>> ISR, But how to really do that. >>> One example about how to handle interrupts is in >>> http://stackoverflow.com/questions/15245626/simple-interrupt-handler-request >>> -irq-returns-error-code-22 >>> The other one is request_threaded_irq() as mentioned by Kavita in the above >>> post. >>> Is there any How to and guide to writing one. Any links. >>> Thanks. >>> >>> >>> On Wednesday, September 10, 2014 12:59:08 AM UTC+5:30, Brandon I wrote: >>>> See UIO: https://www.kernel.org/doc/htmldocs/uio-howto/ >>>> <https://www.kernel.org/doc/htmldocs/uio-howto/> >>>> >>>> The uio_pruss.c driver that comes with the pru package is a good example. >>>> >>>>> > I have written a kernel module that registers interrupts on the rising >>>>> edge on a GPIO pin and want to relay this message to user space. >>>> >>>> The sysfs gpio interface already does this. Check out the code. >>>> >>>> On Thursday, August 28, 2014 2:44:12 AM UTC-7, sid...@gmail.com wrote: >>>>> I have read online that we can't handle interrupts from user space. >>>>> Instead - >>>>> 1) We can write a kernel thread and have that thread wait on an event. >>>>> 2) Once the interrupt occurs, send one asynchronous event from the kernel >>>>> module/driver to user space where we will have one signal handler with >>>>> FASYNC to tackle this >>>>> >>>>> I have written a kernel module that registers interrupts on the rising >>>>> edge on a GPIO pin and want to relay this message to user space. How do I >>>>> go about implementing the above? >>>>> >>>>> Thanks! >>> -- >>> For more options, visit http://beagleboard.org/discuss >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "BeagleBoard" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/beagleboard/eNX0CU7-noE/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> beagleboard...@googlegroups.com <javascript:> . >>> For more options, visit https://groups.google.com/d/optout. >> > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
