Filter
Top Products
SEC 2.0 Reference Device Driver User’s Guide, Rev. 0
Freescale Semiconductor PRELIMINARY—SUBJECT TO CHANGE WITHOUT NOTICE 39
Linux Environment
6Linux Environment
This section describes the driver's adaptation to and interaction with the Linux operating system as applied to PPC
processors
6.1 Installation
6.1.1 Driver Source
The SEC2 driver installs into Linux as a loadable module. To build the driver as a module, it must be installed into
the kernel source tree to be included in the kernel build process. The makefile included with the distribution assumes
this inclusion. As delivered, this directory is defined as
[kernelroot]/drivers/sec2.
Once the driver source is installed, and the kernel source (and modules) are built, module dependency lists updated,
and the built objects are installed in the target filesystem, the driver, (named
sec2drv.o) is ready for loading when
needed.
6.1.2 Device Inode
Kernel processes may call the driver's functionality directly. On the other hand, user processes must use the kernel's
I/O interface to make driver requests. The only way for user processes to do this it to open the device as a file with
the open() system call to get a file descriptor, and then make requests through ioctl(). Thus the system will need
a device file created to assign a name to the device.
The driver functions as a
char device in the target system. As shipped, the driver assumes that the device major
number will be assigned dynamically, and that the minor number will always be zero, since only one instance of the
driver is supported.
Creation of the device's naming inode may be done manually in a development setting, or may be driven by a script
that runs after the driver module loads, and before any user attempts to open a path to the driver. Assuming the
module loaded with a dynamically assigned major number of 254 (look for
sec2 in /proc/devices), then the
shell command to accomplish this would normally appear as:
$ mknod c 254 0 /dev/sec2
Once this is done, user tasks can make requests to the driver under the device name /dev/sec2.
6.2 Operation
6.2.1 Driver Operation in Kernel Mode
Operation of the SEC2 device under kernel mode is relatively straightforward. Once the driver module has loaded,
which will initialize the device, direct calls to the
ioctl() entry (named SEC2_ioctl in the driver) can be made,
the first two arguments may effectively be ignored.
In kernel mode, request completion may be handled through the standard use of notification callbacks in the request.
The example suite available with the driver shows how this may be accomplished; this suite uses a mutex that the
callback will release in order to allow the request to complete, although the caller may make use of any other type
of event mechanism that suits their preference.
Logical to physical memory space translation is handled internal to the driver.