Lines Matching full:you
14 If you know of any translations for this document, or you are interested
57 would love to hear from you. Please email me at hjk@hansjkoch.de.
62 If you use UIO for your card's driver, here's what you get:
67 tools and libraries you're used to.
86 interrupt occurs. You can also use :c:func:`select()` on
88 ``/dev/uioX`` represents the total interrupt count. You can use this
89 number to figure out if you missed some interrupts.
104 interrupt source or has separate IRQ mask and status registers. If you
106 :c:func:`irqcontrol()` function implemented by the driver. You have
173 memory of mapping N, you have to use N times the page size as your
228 - ``struct uio_mem mem[ MAX_UIO_MAPS ]``: Required if you have memory
229 that can be mapped with :c:func:`mmap()`. For each mapping you
233 - ``struct uio_port port[ MAX_UIO_PORTS_REGIONS ]``: Required if you
235 region you need to fill one of the ``uio_port`` structures. See the
240 If you don't have a hardware generated interrupt but want to trigger
242 ``UIO_IRQ_CUSTOM``. If you had no interrupt at all, you could set
245 - ``unsigned long irq_flags``: Required if you've set ``irq`` to a
250 Optional. If you need a special :c:func:`mmap()`
251 function, you can set it here. If this pointer is not NULL, your
255 Optional. You might want to have your own :c:func:`open()`,
259 Optional. If you define your own :c:func:`open()`, you will
263 Optional. If you need to be able to enable or disable interrupts
264 from userspace by writing to ``/dev/uioX``, you can implement this
269 mapped to user space. For each region, you have to set up a
277 ``UIO_MEM_PHYS`` if you have physical memory on your card to be
288 unused. Note that you *must* initialize ``size`` with zero for all
291 - ``void *internal_addr``: If you have to access this memory region
292 from within your kernel module, you will want to map it internally by
294 this function cannot be mapped to user space, so you must not store
305 about the ports available in sysfs. For each region, you have to set up
317 If ``size`` is zero, the region is considered unused. Note that you
327 What you need to do in your interrupt handler depends on your hardware
328 and on how you want to handle it. You should try to keep the amount of
330 action that you *have* to perform after each interrupt, then your
334 after each interrupt, then you *must* do it in your kernel module. Note
335 that you cannot rely on the userspace part of your driver. Your
339 There might also be applications where you want to read data from your
341 you've allocated for that purpose. With this technique you could avoid
354 If you decide not to support shared interrupts, your card won't work in
356 platform, you can save yourself a lot of trouble by supporting interrupt
363 generic way. In the same place where you define your
364 ``struct platform_device``, you simply also implement your interrupt
369 You also need to set up an array of ``struct resource`` containing
374 You now have to set the ``.name`` element of ``struct platform_device``
379 The advantage of this approach is that you only have to edit a file you
380 need to edit anyway. You do not have to create an extra driver.
385 Especially in embedded devices, you frequently find chips where the irq
387 you can be really sure the interrupt is not shared, we can take the
392 ``uio_pdrv``, except that you do not implement an interrupt handler. The
396 You will set the ``.name`` element of ``struct platform_device`` to
403 :c:func:`irq_control()` to make this possible, you must not
407 handler code. You also do not need to know anything about the chip's
408 internal registers to create the kernel part of the driver. All you need
462 Once you have a working kernel module for your hardware, you can write
463 the userspace part of your driver. You don't need any special libraries,
464 your driver can be written in any reasonable language, you can use
465 floating point numbers and so on. In short, you can use all the tools
466 and libraries you'd normally use for writing a userspace application.
472 you should do in your driver is check ``name`` and ``version`` to make
473 sure you're talking to the right device and that its kernel driver has
474 the version you expect.
476 You should also make sure that the memory mapping you need exists and
477 has the size you expect.
484 With ``lsuio`` you can quickly check if your kernel module is loaded and
489 lot of functions you could use in your userspace driver code.
494 After you made sure you've got the right device with the memory mappings
495 you need, all you have to do is to call :c:func:`mmap()` to map the
500 device you want to map. To map the memory of mapping N, you have to use
505 N starts from zero, so if you've got only one memory range to map, set
512 After you successfully mapped your devices memory, you can access it
513 like an ordinary array. Usually, you will perform some initialization.
524 you read the last time, everything is OK. If the difference is greater
525 than one, you missed interrupts.
527 You can also use :c:func:`select()` on ``/dev/uioX``.
534 PCI Express device. Using this, you only need to write the userspace
541 automatically and will not automatically bind to any devices, you must
548 the generic driver still won't bind to it, in this case if you want to
549 use the generic driver (why would you?) you'll have to manually unbind
555 You can verify that the device has been bound to the driver by looking
675 loaded automatically and will not automatically bind to any devices, you
683 the generic driver still won't bind to it, in this case if you want to
684 use the generic driver for a userspace library you'll have to manually unbind
691 You can verify that the device has been bound to the driver by looking