|
Almost all Linux kernel device drivers work on more than just one type of processor. This only happens because device-driver writers adhere to a few important rules. These rules include using the proper variable types, not relying on specific memory page sizes, being aware of endian issues with external data, setting up proper data alignment and accessing device memory locations through the proper interface. This article explains these rules, shows why it is important that they be followed and gives examples of them in use. Internal Kernel Data Types（内置内核数据类型） One of the most basic rules to remember when writing portable code is to be aware of how big you need to make your variables. Different processors define different variable sizes for int and long data types. They also differ in specifying whether a variable size is signed or unsigned. Because of this, if you know your variable size has to be a specific number of bits, and it has to be signed or unsigned, then you need to use the built-in data types. The following typedefs can be used anywhere in kernel code and are defined in the linux/types.h header file: u8 unsigned byte (8 bits) For example, the i2c driver subsystem has a number of functions that are used to send and receive data on the i2c bus: s32 i2c_smbus_write_byte(struct i2c_client All of these functions return a signed 32-bit value and take an unsigned 8-bit value for either a value or command parameter. Because these data types are used, this code is portable to any processor type. If your variables are going to be used in any code that can be seen by user-space programs, then you need to use the following exportable data types. Examples of this are data structures that get passed through ioctl() calls. Once again they are defined in the linux/types.h header file: __u8 unsigned byte (8 bits) For example, the usbdevice_fs.h header file defines a number of different structures that are used to talk to USB devices directly from user-space programs. Here is the definition of the ioctl that is used to send a USB control message to the device: struct usbdevfs_ctrltransfer {One thing that has caused a lot of problems, as 64-bit machines are getting more popular, is the fact that the size of a pointer is not the same as the size of an unsigned integer. The size of a pointer is equal to the size of an unsigned long. This can be seen in the prototype for get_zeroed_page(): extern unsigned long FASTCALL get_zeroed_page() returns a free memory page that has already been wiped clean with zeros. It returns an unsigned long that should be cast to the specific data type that you need. The following code snippet from the drivers/char/serial.c file in the rs_open() function shows how this is done: static unsigned char *tmp_buf; There are some native kernel data types that you should use instead of trying to use an unsigned long. Some of these are: pid_t, key_t, gid_t, size_t, ssize_t, ptrdiff_t, time_t, clock_t and caddr_t. If you need to use any of these types in your code, please use the given data types; it will prevent a lot of problems. Memory Issues As we saw above in the example taken from drivers/char/serial.c, you can ask the kernel for a memory page. The size of a memory page is not always 4KB of data (as it is on i386). If you are going to be referencing memory pages, you need to use the PAGE_SHIFT and PAGE_SIZE defines. PAGE_SHIFT is the number of bits to shift one bit left to get the PAGE_SIZE value. Different architectures define this to different values. Table 1 shows a short list of some architectures and the values of PAGE_SHIFT and the resulting value for PAGE_SIZE. Table 1. Some Architectures and the Values of PAGE_SHIFT and the Resulting Value for PAGE_SIZE
Some Architectures and the Values of PAGE_SHIFT and the Resulting Value for PAGE_SIZE Even on the same base architecture type, you can have different page sizes. This depends sometimes on a configuration option (like IA-64) or is due to different variants of the processor type (like on ARM). The code snippet from drivers/usb/audio.c in Listing 1 shows how PAGE_SHIFT and PAGE_SIZE are used when accessing memory directly. Listing 1. Accessing Memory Directly（直接内存访问）static int dmabuf_mmap(...)
{
size >>= PAGE_SHIFT;
for (nr = 0; nr < size; nr++)
if (!db->sgbuf[nr])
return -EINVAL;
db->mapped = 1;
for (nr = 0; nr < size; nr++) {
if (remap_page_range (start,
virt_to_phys(db->sgbuf[nr]),
PAGE_SIZE, prot))
return -EAGAIN;
start += PAGE_SIZE;
}
return 0;
}
Accessing Memory Directly Endian Issues Processors store internal data in one of two ways: little-endian or big-endian. Little-endian processors store data with the right-most bytes (those with a higher address value) being the most significant, while big-endian processors store data with the left-most bytes (those with a lower address value) being the most significant. For example, Table 2 shows how the decimal value 684686 is stored in a 4-byte integer on the two different processor types (684686 decimal = a72be hex = 00000000 00001010 01110010 10001110 binary). Table 2. How the Decimal Value 684686 is Stored in a 4-Byte Integer
How the Decimal Value 684686 is Stored in a 4-Byte Integer Intel processors, for example the i386 and IA-64 series, are little-endian machines, whereas the SPARC processors are big-endian. The PowerPC processors can be run in either little- or big-endian mode, but for Linux, they are defined as running in big-endian mode. The ARM processor can be either, depending on the specific ARM chip being used, but usually it also runs in big-endian mode. Because of the different endian types of processors, you need to be aware of data you receive from external sources and the order in which it appears. For example, the USB specification dictates that all multibyte data fields are in little-endian form. So if you have a USB driver that reads a multibyte field from the USB connection, you need to convert that data into the processor's native format. Code that assumes the processor is little-endian could ignore the data format coming from the USB connection successfully. But this same code would not work on PowerPC or ARM processors and is the leading cause of drivers that are broken on different platforms. Thankfully, there are a number of helpful macros that have been created to make this an easy task. All of the following macros can be found in the asm/byteorder.h header file. To convert from the processor's native format into little-endian form you can use the following functions: u64 cpu_to_le64 (u64); To convert from little-endian format into the processor's native format you should use these functions: u64 le64_to_cpu (u64); For big-endian forms, the following functions are available: u64 cpu_to_be64 (u64); If you have a pointer to the value to convert, then you should use the following functions: u64 cpu_to_le64p (u64 *); If you want to convert the value within a variable and store the modified value in the same variable (in situ), then you should use the following functions: void cpu_to_le64s (u64 *); As stated before, the USB protocol is in little-endian format. The code snippet from drivers/usb/serial/visor.c presented in Listing 2 shows how a structure is read from the USB connection and then converted into the proper CPU format. Listing 2. How a structure is read from the USB connection and converted into the proper CPU format.struct visor_connection_info *connection_info;
/* send a get connection info request */
usb_control_msg (serial->dev,
usb_rcvctrlpipe(serial->dev, 0),
VISOR_GET_CONNECTION_INFORMATION,
0xc2, 0x0000, 0x0000,
transfer_buffer, 0x12, 300);
connection_info = (struct visor_connection_info *)
transfer_buffer;
le16_to_cpus(&connection_info->num_ports);
How a structure is read from the USB connection and converted into the proper CPU format. Data Alignment The gcc compiler typically aligns individual fields of a structure on whatever byte boundary it likes in order to provide faster execution. For example, consider the code and resulting output shown in Listing 3. Listing 3. Alignment of Individual Fields of a Structure#include <stdio.h>
#include <stddef.h>
struct foo {
char a;
short b;
int c;
};
#define OFFSET_A offsetof(struct foo, a)
#define OFFSET_B offsetof(struct foo, b)
#define OFFSET_C offsetof(struct foo, c)
int main ()
{
printf ("offset A = %d\n", OFFSET_A);
printf ("offset B = %d\n", OFFSET_B);
printf ("offset C = %d\n", OFFSET_C);
return 0;
}
offset A = 0
offset B = 2
offset C = 4
Alignment of Individual Fields of a Structure The output shows that the compiler aligned fields b and c in the struct foo on even byte boundaries. This is not a good thing when we want to overlay a structure on top of a memory location. Typically driver data structures do not have even byte padding for the individual fields. Because of this, the gcc attribute (packed) is used to tell the compiler not to place any "memory holes" within a structure. If we change the struct foo structure to use the packed attribute like this: struct foo {Then the output of the program changes to: offset A = 0 Now there are no more memory holes in the structure. This packed attribute can be used to pack an entire structure, as shown above, or it can be used only to pack a number of specific fields within a structure. For example, the struct usb_ctrlrequest is defined in include/usb.h as the following: struct usb_ctrlrequest {This ensures that the entire structure is packed, so that it can be used to write data directly to a USB connection. But the definition of the struct usb_endpoint_descriptor looks like: struct usb_endpoint_descriptor {This ensures that the first part of the structure is packed and can be used to read directly from a USB connection, but the extra and extralen fields of the structure can be aligned to whatever the compiler thinks will be fastest to access. I/O Memory Access Unlike on most typical embedded systems, accessing I/O memory on Linux cannot be done directly. This is due to the wide range of different memory types and maps present on the wide range of processors on which Linux runs. To access I/O memory in a portable manner, you must call ioremap() to gain access to a memory region and iounmap() to release access. ioremap() is defined as: void * ioremap (unsigned long offset, You pass in a starting offset of the region you wish to access and the size of the region in bytes. You cannot just use the return value as a memory location to read and write from directly, but rather it is a token that must be passed to different functions to read and write data. The functions to read and write data using memory mapped by ioremap() are: u8 readb (unsigned long token); /* read 8 bits */ After you are finished accessing memory, you must call iounmap() to free up the memory so that others can use it if they want to. The code example in Listing 4 from the Compaq PCI Hot Plug driver in drivers/hotplug/cpqphp_core.c shows how to access a PCI device's resource memory properly. Listing 4. Accessing a PCI Device's Resource Memory/* get access to our device's memory */
location = pci_resource_start (pdev, 0);
size = pci_resource_len (pdev, 0);
ctrl->hpc_reg = ioremap(location, size);
if (!ctrl->hpc_reg) {
err("cannot remap MMIO region %lx @ %lx\n",
location, size);
rc = -ENODEV;
goto err_free_mem_region;
}
/* get the device number */
dev_num = readb(ctrl->hpc_reg + SLOT_MASK) >> 4;
/* Mask all general input interrupts */
writel(0xFFFFFFFF, ctrl->hpc_reg + INT_MASK);
....
/* release our memory */
iounmap (ctrl->hpc_reg);
Accessing a PCI Device's Resource Memory Accessing PCI Memory To access the PCI memory of a device, you again must use some general functions and not try to access the memory directly. This is due to the different ways the PCI bus can be accessed, depending on the type of hardware you have. If you use the general functions, then your PCI driver will be able to work on any type of Linux system that has a PCI bus. To read data from the PCI bus use the following functions: int pci_read_config_byte(struct pci_dev *dev, and to write data, use these functions: int pci_write_config_byte(struct pci_dev *dev, Where are the pci_read_config_* and pci_write_config_* functions actually declared? If you look closely in the file drivers/pci/pci.c, you will see the following code: #define PCI_OP(rw,size,type) \ This bit of macro fun creates the six pci_read_config_* and pci_write_config_* functions by abusing the C preprocessor #define of PCI_OP(). These functions allow you to write 8, 16 or 32 bits to a specific location that is assigned to a specific PCI device. If you wish to access the memory location of a specific PCI device that has not been initialized by the Linux PCI core yet, you can use the following functions that are present in the pci_hotplug core code: int pci_read_config_byte_nodev(struct pci_ops *ops, An example of reading and writing to PCI memory by a driver can be seen in the USB OHCI driver at drivers/usb/usb-ohci.c (see Listing 5). Listing 5. Reading and Writing to PCI Memorypci_read_config_byte (dev, PCI_LATENCY_TIMER,
&latency);
if (latency) {
pci_read_config_byte (dev, PCI_MAX_LAT, &limit);
if (limit && limit < latency) {
dbg ("PCI latency reduced to max %d", limit);
pci_write_config_byte (dev, PCI_LATENCY_TIMER,
limit);
ohci->pci_latency = limit;
} else {
/* it might already have been reduced */
ohci->pci_latency = latency;
}
}
Reading and Writing to PCI Memory Conclusion If you follow these different rules when creating a new Linux kernel device driver, or when modifying an existing one, the resulting code will run successfully on a wide range of processors. These rules are also good to remember when debugging a driver that only works on one platform (remember those endian issues). The most important resource to remember is to look at existing kernel drivers that are known to work on different platforms. One of Linux's strengths is the open access of its code, which provides a powerful learning tool for aspiring driver authors. |
|
|
