Tải bản đầy đủ
Chapter 9. PCMCIA and Compact Flash

Chapter 9. PCMCIA and Compact Flash

Tải bản đầy đủ

Today's popular technologies such as wireless and wired Ethernet, General Packet Radio Service
(GPRS), Global Positioning System (GPS), miniature storage, and modems are ubiquitous in the
form factor of PCMCIA (an acronym for Personal Computer Memory Card International Association)
or CF (Compact Flash) cards. Most laptops and many embedded devices support PCMCIA or CF
interfaces, thus instantly enabling them to take advantage of these technologies. On embedded
systems, PCMCIA/CF slots offer a technology upgrade path without the need to re-spin the board.
A cost-reduced version of an Internet-enabled device can, for example, use a PCMCIA dialup
modem, while a higher-end flavor can have WiFi.
The Linux kernel supports PCMCIA devices on a variety of architectures. In this chapter, let's
explore the support present in the kernel for PCMCIA/CF host adapters and client devices.

What's PCMCIA/CF?
PCMCIA is a 16-bit data-transfer interface specification originally used by memory cards. CF cards are smaller,
but compatible with PCMCIA, and are frequently used in handheld devices such as PDAs and digital cameras. CF
cards have only 50 pins but can be slipped into your laptop's 68-pin PCMCIA slot using a passive CF-to-PCMCIA
adapter. PCMCIA and CF have been confined to the laptop and handheld space and have not made inroads into
desktops and higher-end machines.
The PCMCIA specification has now grown to include support for higher speeds in the form of 32-bit CardBus
cards. The term PC Card is used while referring to either PCMCIA or CardBus devices. CardBus is closer to the
PCI bus, so the kernel has moved support for CardBus devices from the PCMCIA layer to the PCI layer. The
latest technology specification from the PCMCIA industry standards group is the ExpressCard, which is
compatible with PCI Express, a new bus technology based on PCI concepts. We look at CardBus and
ExpressCard when we discuss PCI in the next chapter.
PC cards come in three flavors in the increasing order of thickness: Type I (3.3mm), Type II (5mm), and Type
III (10.5mm).
Figure 9.1 shows PCMCIA bus connection on a laptop, and Figure 9.2 illustrates PCMCIA on an embedded device.
As you might have noticed, the PCMCIA host controller bridges the PCMCIA card with the system bus. Laptops
and their derivatives generally have a PCMCIA host controller chip connected to the PCI bus, while several
embedded controllers have a PCMCIA host controller built in to their silicon. The controller maps card memory
to host I/O and memory windows and routes interrupts generated by the card to a suitable processor interrupt
line.

Figure 9.1. PCMCIA on a laptop.

Figure 9.2. PCMCIA on an embedded system.

Chapter 9. PCMCIA and Compact Flash
In This Chapter
258
What's PCMCIA/CF?
260
Linux-PCMCIA Subsystem
262
Host Controller Drivers
263
PCMCIA Core
263
Driver Services
264
Client Drivers
271
Tying the Pieces Together
272
PCMCIA Storage
272
Serial PCMCIA
273
Debugging
275
Looking at the Sources

Today's popular technologies such as wireless and wired Ethernet, General Packet Radio Service
(GPRS), Global Positioning System (GPS), miniature storage, and modems are ubiquitous in the
form factor of PCMCIA (an acronym for Personal Computer Memory Card International Association)
or CF (Compact Flash) cards. Most laptops and many embedded devices support PCMCIA or CF
interfaces, thus instantly enabling them to take advantage of these technologies. On embedded
systems, PCMCIA/CF slots offer a technology upgrade path without the need to re-spin the board.
A cost-reduced version of an Internet-enabled device can, for example, use a PCMCIA dialup
modem, while a higher-end flavor can have WiFi.
The Linux kernel supports PCMCIA devices on a variety of architectures. In this chapter, let's
explore the support present in the kernel for PCMCIA/CF host adapters and client devices.

What's PCMCIA/CF?
PCMCIA is a 16-bit data-transfer interface specification originally used by memory cards. CF cards are smaller,
but compatible with PCMCIA, and are frequently used in handheld devices such as PDAs and digital cameras. CF
cards have only 50 pins but can be slipped into your laptop's 68-pin PCMCIA slot using a passive CF-to-PCMCIA
adapter. PCMCIA and CF have been confined to the laptop and handheld space and have not made inroads into
desktops and higher-end machines.
The PCMCIA specification has now grown to include support for higher speeds in the form of 32-bit CardBus
cards. The term PC Card is used while referring to either PCMCIA or CardBus devices. CardBus is closer to the
PCI bus, so the kernel has moved support for CardBus devices from the PCMCIA layer to the PCI layer. The
latest technology specification from the PCMCIA industry standards group is the ExpressCard, which is
compatible with PCI Express, a new bus technology based on PCI concepts. We look at CardBus and
ExpressCard when we discuss PCI in the next chapter.
PC cards come in three flavors in the increasing order of thickness: Type I (3.3mm), Type II (5mm), and Type
III (10.5mm).
Figure 9.1 shows PCMCIA bus connection on a laptop, and Figure 9.2 illustrates PCMCIA on an embedded device.
As you might have noticed, the PCMCIA host controller bridges the PCMCIA card with the system bus. Laptops
and their derivatives generally have a PCMCIA host controller chip connected to the PCI bus, while several
embedded controllers have a PCMCIA host controller built in to their silicon. The controller maps card memory
to host I/O and memory windows and routes interrupts generated by the card to a suitable processor interrupt
line.

Figure 9.1. PCMCIA on a laptop.

Figure 9.2. PCMCIA on an embedded system.

Linux-PCMCIA Subsystem
Linux-PCMCIA support is available on Intel-based laptops as well as on architectures such as ARM, MIPS, and
PowerPC. The PCMCIA subsystem consists of device drivers for PCMCIA host controllers, client drivers for
different cards, a daemon that aids hotplugging, user mode utilities, and a Card Services module that interacts
with all of these.
Figure 9.3 illustrates the interaction between the modules that constitute the Linux-PCMCIA subsystem.

Figure 9.3. The Linux-PCMCIA subsystem.

[View full size image]

The Old Linux-PCMCIA Subsystem
The Linux-PCMCIA subsystem has recently undergone an overhaul. To get PCMCIA working with
2.6.13 and newer kernels, you need the pcmciautils package
(http://kernel.org/pub/linux/utils/kernel/pcmcia/howto.html), which obsoletes the pcmcia-cs
package (http://pcmcia-cs.sourceforge.net) used with earlier kernels. Internal kernel
programming interfaces and data structures have also changed. Earlier kernels relied on a user
space daemon called cardmgr to support hotplugging, but the new PCMCIA implementation
handles hotplug using udev, just as other bus subsystems do. So with new setups, you don't need
cardmgr and should make sure that it is not started. There is a migration guide at
http://kernel.org/pub/linux/utils/kernel/pcmcia/cardmgr-to-pcmciautils.html.

Figure 9.3 contains the following components:

Host controller device drivers that implement low-level routines for communicating with the PCMCIA host
controller. Your handheld and laptop have different host controllers and, hence, use different host
controller drivers. Each PCMCIA slot that the host controller supports is called a socket.

PCMCIA client drivers (XX_cs in Figure 9.3) that respond to socket events such as card insertion and
ejection. This is the driver that you are most likely to implement when you attempt to Linux-enable a
PCMCIA card. The XX_cs driver usually works in tandem with a generic driver (XX in Figure 9.3) that is not
PCMCIA-specific. In relation to Figure 9.3, if your device is a PCMCIA IDE disk, XX is the IDE disk driver,
XX_cs is the ide_cs driver, XX-dependent layers are filesystem layers, and XX-applications are programs
that access data files. XX_cs configures the generic driver (XX) with resources such as IRQs, I/O base
addresses, and memory windows.

The PCMCIA core that provides services to host controller drivers and client drivers. The core provides an
infrastructure that makes driver implementations simpler and adds a level of indirection that renders client
drivers independent of host controllers. Irrespective of whether you are using your Bluetooth CF card on
an XScale-based handheld or an x86-based laptop, the same client drivers can be pressed into service.

A driver services module (ds) that offers registration interfaces and bus services to client drivers.

The pcmciautils package, which contains tools such as pccardctl that control the state of PCMCIA sockets
and select between different card-configuration schemes.

Figure 9.4 glues kernel modules on top of Figure 9.1 to illustrate how the Linux-PCMCIA subsystem interacts
with hardware on a PC-compatible system.

Figure 9.4. Relating PCMCIA driver components with PC hardware.

[View full size image]

In the following sections, let's take a closer look at the components constituting the Linux-PCMCIA subsystem.
To better understand the role of these components and their interaction, we will insert a PCMCIA WiFi card into
a laptop and trace the code flow in the section "Tying the Pieces Together."

Host Controller Drivers
Whereas the generic card driver (XX) is responsible for handling interrupts generated by the card function (say,
receive interrupts when a PCMCIA network card receives data packets), the host controller driver is responsible
for handling bus-specific interrupts triggered by events such as card insertion and ejection.
Figure 9.2 shows the block diagram of an embedded device designed around an embedded controller that has
built-in PCMCIA support. Even if you are using a controller supported by the kernel PCMCIA layer, you might
need to tweak the host controller driver (for example, to configure GPIO lines used for detecting card insertion
events or switching power to the socket) depending on your board's design. If you are porting the kernel to a
StrongARM-based handheld, for example, tailor drivers/pcmcia/sa1100_assabet.c to suit your hardware.
This chapter does not cover the implementation of host controller device drivers.

PCMCIA Core
Card Services is the main constituent of the PCMCIA core. It offers a set of services to client drivers and host
controller drivers. It contains a kernel thread called pccardd that polls for socket-related events. Pccardd notifies
the Driver Services event handler (discussed in the next section) when the host controller reports events such
as card insertion and card removal.
Another component of the PCMCIA core is a library that manipulates the Card Information Structure (CIS) that
is part of PCMCIA cards. PCMCIA/CF cards have two memory spaces: Attribute memory and Common memory.
Attribute memory contains the CIS and card configuration registers. Attribute memory of a PCMCIA IDE disk, for
example, contains its CIS and registers that specify the sector count and the cylinder number. Common memory
in this case contains the memory array that holds disk data. The PCMCIA core offers CIS manipulation routines
such as pccard_get_first_tuple(), pccard_get_next_tuple(), and pccard_parse_tuple() to client drivers.
Listing 9.2 uses the assistance of some of these functions.
The PCMCIA core passes CIS information to user space via sysfs and udev. Utilities such as pccardctl, part of the
pcmciautils package, depend on sysfs and udev for their operation. This simplifies the earlier design approach
that relied on a custom infrastructure when these facilities were absent in the kernel.

Driver Services
Driver Services provides an infrastructure that offers the following:

A handler that catches event alerts dispatched by the pccardd kernel thread. The handler scans and
validates the card's CIS space and triggers the load of an appropriate client driver.

A layer that has the task of communicating with the kernel's bus core. To this end, Driver Services
implements the pcmcia_bus_type and related bus operations.

Service routines such as pcmcia_register_driver() that client drivers use to register themselves with
the PCMCIA core. The example driver in Listing 9.1 uses some of these routines.