blob: 5eb5d3ab3c817491fe9ef9a2b5f95e07d757ac4f [file] [log] [blame]
Kernel Low-Level PCMCIA Interface Documentation
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
John G Dorsey <john+@cs.cmu.edu>
Updated: 30 June, 2000
Note: this interface has not been finalized!
See also: http://www.cs.cmu.edu/~wearable/software/pcmcia-arm.html
Introduction
Early versions of PCMCIA Card Services for StrongARM were designed to
permit a single socket driver to run on a variety of SA-1100 boards by
using a userland configuration process. During the conversion to the 2.3
kernel series, all of the configuration has moved into sub-drivers in the
kernel proper (see linux/drivers/pcmcia/sa1100*). This document describes
the low-level interface between those sub-drivers and the sa1100 socket
driver module.
Presently, there are six operations which must be provided by the
board-specific code. Only functions whose implementation is likely to
differ across board designs are required at this level. Some examples
include:
- configuring card detect lines to generate interrupts
- sensing the legal voltage levels for inserted cards
- asserting the reset signal for a card
Functions which are assumed to be the same across all designs are
performed within the generic socket driver itself. Some examples of these
kinds of operations include:
- configuring memory access times based on the core clock frequency
- reads/writes on memory, byte swizzling, ...
The current implementation allows the specific per-board set of low-level
operations to be determined at run time. For each specific board, the
following structure should be filled in:
struct pcmcia_low_level {
int (*init)(struct pcmcia_init *);
int (*shutdown)(void);
int (*socket_state)(struct pcmcia_state_array *);
int (*get_irq_info)(struct pcmcia_irq_info *);
int (*configure_socket)(const struct pcmcia_configure *);
};
The component functions are described in detail below. Using the
machine_is_*() tests, the pointer `pcmcia_low_level' should be assigned to
the location of the table for your board.
0. init(struct pcmcia_init *init)
This operation has three responsibilities:
- perform any board-specific initialization tasks
- associate the given handler with any interrupt-generating signals
such as card detection, or battery voltage detection
- set up any necessary edge detection for card ready signals
Argument passing for this operation is implemented by the following
structure:
struct pcmcia_init {
void (*handler)(int irq, void *dev, struct pt_regs *regs);
struct pcmcia_maps *maps;
};
Here, `handler' is provided by the socket driver, and `maps' must be
modified if the default mapping isn't appropriate. This operation should
return one of two values:
- the highest-numbered socket available, plus one
- a negative number, indicating an error in configuration
Note that the former case is _not_ the same as "the number of sockets
available." In particular, if your design uses SA-1100 slot "one" but
not slot "zero," you MUST report "2" to the socket driver.
1. shutdown(void)
This operation takes no arguments, and will be called during cleanup for
the socket driver module. Any state associated with the socket controller,
including allocated data structures, reserved IRQs, etc. should be
released in this routine.
The return value for this operation is not examined.
2. socket_state(struct pcmcia_state_array *state_array)
This operation will be invoked from the interrupt handler which was set up
in the earlier call to init(). Note, however, that it should not include
any side effects which would be inappropriate if the operation were to
occur when no interrupt is pending. (An extra invocation of this operation
currently takes place to initialize state in the socket driver.)
Argument passing for this operation is handled by a structure which
contains an array of the following type:
struct pcmcia_state {
unsigned detect: 1,
ready: 1,
bvd1: 1,
bvd2: 1,
wrprot: 1,
vs_3v: 1,
vs_Xv: 1;
};
Upon return from the operation, a struct pcmcia_state should be filled in
for each socket available in the hardware. For every array element (up to
`size' in the struct pcmcia_state_saarray) which does not correspond to an
available socket, zero the element bits. (This includes element [0] if
socket zero is not used.)
Regardless of how the various signals are routed to the SA-1100, the bits
in struct pcmcia_state always have the following semantics:
detect - 1 if a card is fully inserted, 0 otherwise
ready - 1 if the card ready signal is asserted, 0 otherwise
bvd1 - the value of the Battery Voltage Detect 1 signal
bvd2 - the value of the Battery Voltage Detect 2 signal
wrprot - 1 if the card is write-protected, 0 otherwise
vs_3v - 1 if the card must be operated at 3.3V, 0 otherwise
vs_Xv - 1 if the card must be operated at X.XV, 0 otherwise
A note about the BVD signals: if your board does not make both lines
directly observable to the processor, just return reasonable values. The
standard interpretation of the BVD signals is:
BVD1 BVD2
0 x battery is dead
1 0 battery warning
1 1 battery ok
Regarding the voltage sense flags (vs_3v, vs_Xv), these bits should be set
based on a sampling of the Voltage Sense pins, if available. The standard
interpretation of the VS signals (for a "low-voltage" socket) is:
VS1 VS2
0 0 X.XV, else 3.3V, else none
0 1 3.3V, else none
1 0 X.XV, else none
1 1 5V, else none
More information about the BVD and VS conventions is available in chapter
5 of "PCMCIA System Architecture," 2nd ed., by Don Anderson.
This operation should return 1 if an IRQ is actually pending for the
socket controller, 0 if no IRQ is pending (but no error condition exists,
such as an undersized state array), or -1 on any error.
3. get_irq_info(struct pcmcia_irq_info *info)
This operation obtains the IRQ assignment which is legal for the given
socket. An argument of the following type is passed:
struct pcmcia_irq_info {
unsigned int sock;
unsigned int irq ;
};
The `sock' field contains the socket index being queried. The `irq' field
should contain the IRQ number corresponding to the card ready signal from
the device.
This operation should return 0 on success, or -1 on any error.
4. configure_socket(const struct pcmcia_configure *configure)
This operation allows the caller to apply power to the socket, issue a
reset, or enable various outputs. The argument is of the following type:
struct pcmcia_configure {
unsigned sock: 8,
vcc: 8,
vpp: 8,
output: 1,
speaker: 1,
reset: 1;
};
The `sock' field contains the index of the socket to be configured. The
`vcc' and `vpp' fields contain the voltages to be applied for Vcc and Vpp,
respectively, in units of 0.1V. (Note that vpp==120 indicates that
programming voltage should be applied.)
The two output enables, `output' and `speaker', refer to the card data
signal enable and the card speaker enable, respectively. The `reset' bit,
when set, indicates that the card reset should be asserted.
This operation should return 0 on success, or -1 on any error.
Board-Specific Notes
The following information is known about various SA-11x0 board designs
which may be used as reference while adding support to the kernel.
Carnegie Mellon Itsy/Cue (http://www.cs.cmu.edu/~wearable/itsy/)
Itsy Chip Select 3 (CS3) Interface
("ITSY MEMORY/PCMCIA ADD-ON BOARD with BATTERY and CHARGER CIRCUITRY,"
memo dated 5-20-99, from Tim Manns to Richard Martin, et. al)
Read:
ABVD2 (SS)D0 A slot, Battery Voltage Detect
ABVD1 (SS)D1
AVSS2 (SS)D2 A slot, Voltage Sense
AVSS1 (SS)D3
GND (SS)D4
GND (SS)D5
GND (SS)D6
GND (SS)D7
BBVD2 (SS)D8 B slot, Battery Voltage Detect
BBVD1 (SS)D9
BVSS2 (SS)D10 B slot, Voltage Sense
BVSS1 (SS)D11
GND (SS)D12
GND (SS)D13
GND (SS)D14
GND (SS)D15
Write:
(SS)D0 A_VPP_VCC LTC1472 VPPEN1
(SS)D1 A_VPP_PGM LTC1472 VPPEN0
(SS)D2 A_VCC_3 LTC1472 VCCEN0
(SS)D3 A_VCC_5 LTC1472 VCCEN1
(SS)D4 RESET (A SLOT)
(SS)D5 GND
(SS)D6 GND
(SS)D7 GND
(SS)D8 B_VPP_VCC LTC1472 VPPEN1
(SS)D9 B_VPP_PGM LTC1472 VPPEN0
(SS)D10 B_VCC_3 LTC1472 VCCEN0
(SS)D11 B_VCC_5 LTC1472 VCCEN1
(SS)D12 RESET (B SLOT)
(SS)D13 GND
(SS)D14 GND
(SS)D15 GND
GPIO pin assignments are as follows: (from schematics)
GPIO 10 Slot 0 Card Detect
GPIO 11 Slot 1 Card Detect
GPIO 12 Slot 0 Ready/Interrupt
GPIO 13 Slot 1 Ready/Interrupt
Intel SA-1100 Multimedia Board (http://developer.intel.com/design/strong/)
CPLD Registers
SA-1100 Multimedia Development Board with Companion SA-1101 Development
Board User's Guide, p.4-42
This SA-1100/1101 development package uses only one GPIO pin (24) to
signal changes in card status, and requires software to inspect a
PCMCIA status register to determine the source.
Read: (PCMCIA Power Sense Register - 0x19400000)
S0VS1 0 Slot 0 voltage sense
S0VS2 1
S0BVD1 2 Slot 0 battery voltage sense
S0BVD2 3
S1VS1 4 Slot 1 voltage sense
S1VS2 5
S1BVD1 6 Slot 1 battery voltage sense
S1BVD2 7
Read/Write: (PCMCIA Power Control Register - 0x19400002)
S0VPP0 0 Slot 0 Vpp
S0VPP1 1
S0VCC0 2 Slot 0 Vcc
S0VCC1 3
S1VPP0 4 Slot 1 Vpp
S1VPP1 5
S1VCC0 6 Slot 1 Vcc
S1VCC1 7
Read: (PCMCIA Status Register - 0x19400004)
S0CD1 0 Slot 0 Card Detect 1
S0RDY 1 Slot 0 Ready/Interrupt
S0STSCHG 2 Slot 0 Status Change
S0Reset 3 Slot 0 Reset (RW)
S1CD1 4 Slot 1 Card Detect 1
S1RDY 5 Slot 1 Ready/Interrupt
S1STSCHG 6 Slot 1 Status Change
S1Reset 7 Slot 1 Reset (RW)
Intel SA-1100 Evaluation Platform (http://developer.intel.com/design/strong/)
Brutus I/O Pins and Chipselect Register
pcmcia-brutus.c, by Ivo Clarysse
(What's the official reference for this info?)
This SA-1100 development board uses more GPIO pins than say, the Itsy
or the SA-1100/1101 multimedia package. The pin assignments are as
follows:
GPIO 2 Slot 0 Battery Voltage Detect 1
GPIO 3 Slot 0 Ready/Interrupt
GPIO 4 Slot 0 Card Detect
GPIO 5 Slot 1 Battery Voltage Detect 1
GPIO 6 Slot 1 Ready/Interrupt
GPIO 7 Slot 1 Card Detect
Like the Itsy, Brutus uses a chipselect register in static memory
bank 3 for the other signals, such as voltage sense or reset:
Read:
P0_VS1 8 Slot 0 Voltage Sense
P0_VS2 9
P0_STSCHG 10 Slot 0 Status Change
P1_VS1 12 Slot 1 Voltage Sense
P1_VS2 13
P1_STSCHG 14 Slot 1 Status Change
Read/Write:
P0_ 16 Slot 0 MAX1600EAI control line
P0_ 17 Slot 0 MAX1600EAI control line
P0_ 18 Slot 0 MAX1600EAI control line
P0_ 19 Slot 0 MAX1600EAI control line
P0_ 20 Slot 0 12V
P0_ 21 Slot 0 Vpp to Vcc (CONFIRM?)
P0_ 22 Slot 0 enable fan-out drivers & xcvrs
P0_SW_RST 23 Slot 0 Reset
P1_ 24 Slot 1 MAX1600EAI control line
P1_ 25 Slot 1 MAX1600EAI control line
P1_ 26 Slot 1 MAX1600EAI control line
P1_ 27 Slot 1 MAX1600EAI control line
P1_ 28 Slot 1 12V
P1_ 29 Slot 1 Vpp to Vcc (CONFIRM?)
P1_ 30 Slot 1 enable fan-out drivers & xcvrs
P1_SW_RST 31 Slot 1 Reset
For each slot, the bits labelled "MAX1600EAI" should (apparently)
be written with the value 0101 for Vcc 3.3V, and 1001 for Vcc 5V.
Intel SA-1110 Development Platform (http://developer.intel.com/design/strong/)
GPIO Pin Descriptions and Board Control Register
SA-1110 Microprocessor Development Board User's Guide, p.4-7, 4-10
The Assabet board contains only a single Compact Flash slot,
attached to slot 1 on the SA-1110. Card detect, ready, and BVD
signals are routed through GPIO, with power and reset placed in a
control register. Note that the CF bus must be enabled before use.
GPIO 21 Slot 1 Compact Flash interrupt
GPIO 22 Slot 1 card detect (CD1 NOR CD2)
GPIO 24 Slot 1 Battery Voltage Detect 2
GPIO 25 Slot 1 Battery Voltage Detect 1
Write-only: (Board Control Register - 0x12000000)
CF_PWR 0 CF bus power (3.3V)
CF_RST 1 CF reset
CF_Bus_On 7 CF bus enable