Lines Matching defs:device
59 \chapter{New device driver interface}
62 This document describes how we write device drivers in Barrelfish. It will walk
78 (typically a library) that contains the logic for a device driver.
94 typically started by Kaluga (device manager), and then continue to communicate
125 \item[\fnname{init}] Initialize driver an device.
126 \item[\fnname{detach}] Release ownership of the device temporarily.
127 \item[\fnname{attach}] Regain ownership of the device (after \fnname{detach}).
128 \item[\fnname{set\_sleep\_level}] Change power state of the device.
129 \item[\fnname{destroy}] Destruct the driver instance, release ownership of device.
157 \chapter{Legacy device drivers}
162 happy with this so we introduced some more rules of how a device driver is
164 device drivers are still legacy drivers. So in order to understand what is going
170 device used for face detection typically found on OMAP chips.
192 describing device registers. You can find an abundance of Mackerel files in
194 \keywname{omap44xx\_fdif} device mentioned in the Hakefile at the third
196 describe a particular device we use in Barrelfish to varying degrees of
211 finding, and mapping our device registers in the virtual memory space of the
215 for. Since we are currently using this device on ARM/OMAP4 platforms, this is
218 \begin{lstlisting}[caption={A Hakefile for a simple device driver}, label={lst:hakefile}]
233 device driver source code. If you open the file, aside from the comment
248 that are defined in these header files and use them to access device
253 \begin{lstlisting}[caption={Mapping device registers in virtual memory.}, label={lst:mapping}]
259 It takes the physical address of a device register (\varname{0x4A10A000}) the
262 our device drivers all run in user-space this function ensures that you can
263 access the device in your address space. There is also the issue of how, and
264 which programs we allow access to what device registers. We will discuss this
267 For the the FDIF device, we can receive an interrupt from the device in case
273 we register an interrupt for the device by using
285 glimpse of the user-level side on writing device drivers for ARM. It consists
286 of an interplay of the build system, mackerel device descriptions, mapping
287 device registers, interrupt registrations and your actual driver code. In the
292 teach students about the basic concepts of device drivers. However, if you
319 \section{Kaluga -- The device manager}
321 Kaluga is the device manager in Barrelfish. Its responsibility is to manage
323 once a device is discovered, in the right order and making sure that each driver
324 has the permissions (capabilities) to access the device' memory areas
326 rest of the system for device discovery and driver start-up.
331 automatic device discovery -- there are device trees, but we do not
349 driver and will start it, if it finds a suitable device. How Kaluga finds a
350 suitable device is explained in the following sections. Drivers are started in
358 will just spawn the binary and provide as arguments the PCI device identifiers
362 gain access to the device registers. For historical reasons, the way we
375 Configuration and Power Interface, is an open standard for device
385 Octopus and propagated to Kaluga which will start individual device drivers to
387 device record? We already discussed how Kaluga uses different start functions
391 new device. You will find the mapping database in
392 \pathname{usr/skb/programs/device\_db.pl}. If you want to start your PCI driver
394 corresponding device and vendor id.
414 control for a specific PCI device. The device is identified by using the
417 library once it has registered the device with the PCI domain.
419 device\_mem}. A description of the basic address registers (BAR) for this PCI
420 device and also permissions (capabilities) to map these address registers in
431 uint32_t vendor, uint32_t device,
436 uint32_t vendor, uint32_t device,
448 to push more of that complexity in Kaluga. The device registration with PCI
450 receives a list of capabilities for a particular device which it can map in
465 device trees at the moment. Therefore, if you look at the \fnname{main}
471 driver and pass the driver a list of memory capabilities to access the device
486 the first place. For that we have to look at the \fnname{device\_caps.c} file
491 of memory, in our case device memory. It allows you to request a smaller range
501 the one in ACPI (\pathname{usr/acpi}), it handles all device memory on x86 and
504 If you look at the function \fnname{init\_cap\_manager} in \pathname{usr/kaluga/device\_caps.c}
513 access the whole space of the device memory. We pass this capability on to the
514 device manager in the \fnname{mm\_add} call further down. Now, we are free to
519 pass on to the device drivers.
530 want to write user-level device drivers on a new, unsupported platform. We
532 interrupts to user-space and how we create capabilities for device memory.
556 series of smaller capabilities for device drivers from an initial, huge
559 create capabilities for device memory and how we can pass it on to user-space.
562 usually ask the BIOS to get a list of memory regions for RAM and device
564 the device regions to ACPI which is the domain that initializes the ACPI
566 platform, the device memory usually lives in a statically pre-defined range.
569 device memory range of the the OMAP4 platform. The relevant parts are
582 \varname{ObjType\_DevFrame}, a special type for device memory that makes sure
586 or one GiB, starting from address \varname{0x40000000} -- the device memory