<?xml version="1.0" encoding="ANSI_X3.4-1968" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968" /><title>Chapter 2. About UIO</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="The Userspace I/O HOWTO" /><link rel="up" href="index.html" title="The Userspace I/O HOWTO" /><link rel="prev" href="ch01s04.html" title="Feedback" /><link rel="next" href="custom_kernel_module.html" title="Chapter 3. Writing your own kernel module" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 2. About UIO</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch01s04.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="custom_kernel_module.html">Next</a></td></tr></table><hr /></div><div class="chapter" title="Chapter 2. About UIO"><div class="titlepage"><div><div><h2 class="title"><a id="about"></a>Chapter 2. About UIO</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="about.html#how_uio_works">How UIO works</a></span></dt></dl></div><p>If you use UIO for your card's driver, here's what you get:</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>only one small kernel module to write and maintain.</p></li><li class="listitem"><p>develop the main part of your driver in user space, with all the tools and libraries you're used to.</p></li><li class="listitem"><p>bugs in your driver won't crash the kernel.</p></li><li class="listitem"><p>updates of your driver can take place without recompiling the kernel.</p></li></ul></div><div class="sect1" title="How UIO works"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="how_uio_works"></a>How UIO works</h2></div></div></div><p> Each UIO device is accessed through a device file and several sysfs attribute files. The device file will be called <code class="filename">/dev/uio0</code> for the first device, and <code class="filename">/dev/uio1</code>, <code class="filename">/dev/uio2</code> and so on for subsequent devices. </p><p><code class="filename">/dev/uioX</code> is used to access the address space of the card. Just use <code class="function">mmap()</code> to access registers or RAM locations of your card. </p><p> Interrupts are handled by reading from <code class="filename">/dev/uioX</code>. A blocking <code class="function">read()</code> from <code class="filename">/dev/uioX</code> will return as soon as an interrupt occurs. You can also use <code class="function">select()</code> on <code class="filename">/dev/uioX</code> to wait for an interrupt. The integer value read from <code class="filename">/dev/uioX</code> represents the total interrupt count. You can use this number to figure out if you missed some interrupts. </p><p> For some hardware that has more than one interrupt source internally, but not separate IRQ mask and status registers, there might be situations where userspace cannot determine what the interrupt source was if the kernel handler disables them by writing to the chip's IRQ register. In such a case, the kernel has to disable the IRQ completely to leave the chip's register untouched. Now the userspace part can determine the cause of the interrupt, but it cannot re-enable interrupts. Another cornercase is chips where re-enabling interrupts is a read-modify-write operation to a combined IRQ status/acknowledge register. This would be racy if a new interrupt occurred simultaneously. </p><p> To address these problems, UIO also implements a write() function. It is normally not used and can be ignored for hardware that has only a single interrupt source or has separate IRQ mask and status registers. If you need it, however, a write to <code class="filename">/dev/uioX</code> will call the <code class="function">irqcontrol()</code> function implemented by the driver. You have to write a 32-bit value that is usually either 0 or 1 to disable or enable interrupts. If a driver does not implement <code class="function">irqcontrol()</code>, <code class="function">write()</code> will return with <code class="varname">-ENOSYS</code>. </p><p> To handle interrupts properly, your custom kernel module can provide its own interrupt handler. It will automatically be called by the built-in handler. </p><p> For cards that don't generate interrupts but need to be polled, there is the possibility to set up a timer that triggers the interrupt handler at configurable time intervals. This interrupt simulation is done by calling <code class="function">uio_event_notify()</code> from the timer's event handler. </p><p> Each driver provides attributes that are used to read or write variables. These attributes are accessible through sysfs files. A custom kernel driver module can add its own attributes to the device owned by the uio driver, but not added to the UIO device itself at this time. This might change in the future if it would be found to be useful. </p><p> The following standard attributes are provided by the UIO framework: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> <code class="filename">name</code>: The name of your device. It is recommended to use the name of your kernel module for this. </p></li><li class="listitem"><p> <code class="filename">version</code>: A version string defined by your driver. This allows the user space part of your driver to deal with different versions of the kernel module. </p></li><li class="listitem"><p> <code class="filename">event</code>: The total number of interrupts handled by the driver since the last time the device node was read. </p></li></ul></div><p> These attributes appear under the <code class="filename">/sys/class/uio/uioX</code> directory. Please note that this directory might be a symlink, and not a real directory. Any userspace code that accesses it must be able to handle this. </p><p> Each UIO device can make one or more memory regions available for memory mapping. This is necessary because some industrial I/O cards require access to more than one PCI memory region in a driver. </p><p> Each mapping has its own directory in sysfs, the first mapping appears as <code class="filename">/sys/class/uio/uioX/maps/map0/</code>. Subsequent mappings create directories <code class="filename">map1/</code>, <code class="filename">map2/</code>, and so on. These directories will only appear if the size of the mapping is not 0. </p><p> Each <code class="filename">mapX/</code> directory contains four read-only files that show attributes of the memory: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> <code class="filename">name</code>: A string identifier for this mapping. This is optional, the string can be empty. Drivers can set this to make it easier for userspace to find the correct mapping. </p></li><li class="listitem"><p> <code class="filename">addr</code>: The address of memory that can be mapped. </p></li><li class="listitem"><p> <code class="filename">size</code>: The size, in bytes, of the memory pointed to by addr. </p></li><li class="listitem"><p> <code class="filename">offset</code>: The offset, in bytes, that has to be added to the pointer returned by <code class="function">mmap()</code> to get to the actual device memory. This is important if the device's memory is not page aligned. Remember that pointers returned by <code class="function">mmap()</code> are always page aligned, so it is good style to always add this offset. </p></li></ul></div><p> From userspace, the different mappings are distinguished by adjusting the <code class="varname">offset</code> parameter of the <code class="function">mmap()</code> call. To map the memory of mapping N, you have to use N times the page size as your offset: </p><pre class="programlisting"> offset = N * getpagesize(); </pre><p> Sometimes there is hardware with memory-like regions that can not be mapped with the technique described here, but there are still ways to access them from userspace. The most common example are x86 ioports. On x86 systems, userspace can access these ioports using <code class="function">ioperm()</code>, <code class="function">iopl()</code>, <code class="function">inb()</code>, <code class="function">outb()</code>, and similar functions. </p><p> Since these ioport regions can not be mapped, they will not appear under <code class="filename">/sys/class/uio/uioX/maps/</code> like the normal memory described above. Without information about the port regions a hardware has to offer, it becomes difficult for the userspace part of the driver to find out which ports belong to which UIO device. </p><p> To address this situation, the new directory <code class="filename">/sys/class/uio/uioX/portio/</code> was added. It only exists if the driver wants to pass information about one or more port regions to userspace. If that is the case, subdirectories named <code class="filename">port0</code>, <code class="filename">port1</code>, and so on, will appear underneath <code class="filename">/sys/class/uio/uioX/portio/</code>. </p><p> Each <code class="filename">portX/</code> directory contains four read-only files that show name, start, size, and type of the port region: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> <code class="filename">name</code>: A string identifier for this port region. The string is optional and can be empty. Drivers can set it to make it easier for userspace to find a certain port region. </p></li><li class="listitem"><p> <code class="filename">start</code>: The first port of this region. </p></li><li class="listitem"><p> <code class="filename">size</code>: The number of ports in this region. </p></li><li class="listitem"><p> <code class="filename">porttype</code>: A string describing the type of port. </p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch01s04.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="custom_kernel_module.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Feedback </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 3. Writing your own kernel module</td></tr></table></div></body></html>
