Kernel Low-Level PCMCIA Interface Documentation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ John G Dorsey 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