Linux Kernel 2.6 PCMCIA

Apologies for the bare nature of this web page. 8)

Last update: 21 October 2004.

* New Site *

This site has now moved to:

http://kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html

Please update your bookmarks and links to this site appropriately. This site will be taken off line on 20th April 2005.

Background

The core of the 2.6 PCMCIA subsystem is undergoing gradual evolution to improve its integration with the Linux kernel. This involves a series of clean-ups, code re-organisations, and even some rewrites of parts of the existing subsystem. Unfortunately, mistakes do creep in from time to time, and this page attempts to detail these, hopefully with either fixes or details describing what information is required to help track down the cause. I'm not intending to keep every single patch available indefinitely here; this will only cover about the last three months (or whenever I get to update it.)

I intend to document known problems with the core Linux 2.6 PCMCIA subsystem here, though I'm not tracking PCMCIA card driver problems. These are the responsibility of the individual driver maintainers.

There is also the 2.6 kernel bugzilla, which can be used for core PCMCIA bug reports (ie, socket driver bug reports, core pcmcia subsystem bug reports, and the like.) However, please do not enter PCMCIA card driver bugs under the "PCMCIA" category - they come my way; I don't have any real interest in sorting these out. These should be posted to the mailing list (see below.)

Mailing list

There is a mailing list for 2.6 PCMCIA, which can be found at "linux minus pcmcia at lists dot infradead dot org" (list address obfuscated to reduce spam.)

Known problems

cs: pcmcia_socket0: unable to apply power

It seems that some PCMCIA controllers refuse to apply power to the socket when we ask them to. The reason this occurs is presently a complete mystery - it just appears that some laptops with identical PCMCIA bridges have this problem and others do not. This has been seen on the following machines:

Machine Bridge Comment
Unknown machine Ricoh Co Ltd RL5c475 (rev 80) (went away after reboot)

Unknown machine TI PCI1225

Sony VAIO PCG-871L Ricoh Co Ltd RL5c476 II

JVC mininote Ricoh Co Ltd RL5c476 II (rev 88)

Toshiba Tecra 530CDT TOPIC95

Packard Bell "i go" TI PCI1250 We know that this bridge does work on other laptops.
VIA EPIA M-II 10K board Ricoh Co Ltd RL5c476 II (rev 80)

Machine	Bridge	Comment
Unknown machine	Ricoh Co Ltd RL5c475 (rev 80)	(went away after reboot)
Unknown machine	TI PCI1225
Sony VAIO PCG-871L	Ricoh Co Ltd RL5c476 II
JVC mininote	Ricoh Co Ltd RL5c476 II (rev 88)
Toshiba Tecra 530CDT	TOPIC95
Packard Bell "i go"	TI PCI1250	We know that this bridge does work on other laptops.
VIA EPIA M-II 10K board	Ricoh Co Ltd RL5c476 II (rev 80)

David Hinds does give a suggestion for TI1225-based PCI adapters:

Some TI 1225 PCI adapters require setting bit 27 (P2CCLK) of the
System Control Register (PCI configuration register at 0x80-0x83).  As
far as I know, there is no way for software to tell when this is
required.  In the pcmcia-cs package, the i28365 driver has a module
parameter for setting this; you could try just using "setpci".

In order to do this, use setpci, eg:

# setpci -s 0a.0 0x80.l
0044b060
# setpci -s 0a.0 0x80.l=0x0844b060

where "0a.0" is the PCI bus ID of the Cardbus bridge, and 0x0844b060 is the value reported for the register (0044b060 in the example above) bitwise orred with 0x08000000. Do NOT copy the number in this example verbatim - doing so may cause your laptop to crash.

If that doesn't work, please mail a report including:

the machine type
cardbus bridge type
the full lspci -vv output
cbdump output

to the mailing list (details given above). Hopefully a pattern can be spotted.

Also consider sending a report if you have one of the machines listed above and it does work - this is equally as important as the failure cases.

Thanks.

cs: pcmcia_socket0: *** DANGER *** unable to remove socket power

This is similar to the above problem - some PCMICA bridges refuse to remove socket power when we ask them to. Again, there doesn't seem to be any reasoning or pattern behind this. This has been seen on laptops:

Machine Bridge Comment
Compaq R3000Z notebook TI ???

IBM ThinkPad T23 Unknown cardbus bridge

Powerbook TI PCI1510

Toshiba A60-302 TI PCI1410

Machine	Bridge	Comment
Compaq R3000Z notebook	TI ???
IBM ThinkPad T23	Unknown cardbus bridge
Powerbook	TI PCI1510
Toshiba A60-302	TI PCI1410

Note: This problem may be caused by a resource clash between the PCMCIA socket and system RAM. If the PCMCIA bridge Memory resource (shown by lspci) is below the upper most address of system RAM, then that will cause various problems with PCMCIA. Eg, If you have 1GB of RAM, the PCMCIA bridge memory resource must be above 0x40000000.

This can occur if you pass the mem= parameter to the kernel, or you have a buggy BIOS. An example of a buggy BIOS is:

Kernel messages:

BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
 BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ce000 - 00000000000d0000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000f6f0000 (usable)
 BIOS-e820: 000000000f6f0000 - 000000000f700000 (reserved)
 BIOS-e820: 000000000f700000 - 000000003f6f0000 (usable)
 BIOS-e820: 000000003f6f0000 - 000000003f6f8000 (ACPI data)
 BIOS-e820: 000000003f6f8000 - 000000003f6fa000 (ACPI NVS)
 BIOS-e820: 000000003f700000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)

Note the hole between 000000003f6fa000 and 000000003f700000.

/proc/iomem reports:

3f6f8000-3f6f9fff : ACPI Non-volatile Storage
3f6fa000-3f6fa3ff : 0000:00:1f.1
3f6fb000-3f6fbfff : 0000:02:01.0
  3f6fb000-3f6fbfff : yenta_socket
3f700000-3fffffff : reserved

and lspci -vv reports:

02:01.0 CardBus bridge: Texas Instruments PCI1410 PC card Cardbus Controller (rev 02)
        Subsystem: IBM: Unknown device 054e
        Flags: bus master, medium devsel, latency 168, IRQ 11
        Memory at 3f6fb000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
        Memory window 0: 40000000-403ff000 (prefetchable)
        Memory window 1: 40400000-407ff000
        I/O window 0: 00004000-000040ff
        I/O window 1: 00004400-000044ff
        16-bit legacy interface ports at 0001

The solution is to manually reserve this memory region by adding reserve=0x3f6fb000,0x5000 to the kernel command line.

If this does not appear to be the case, or does not solve the problem, please mail the complete kernel messages to the mailing list (details given above).

Unable to suspend Thinkpad T.22 [Fix Pending]
This Thinkpad does not like us placing the Yenta bridge into PCI D3 state. See this patch for a possible fix.

Pending Patches

To download patches on this page, please right-click on the link and choose "Save Link Target As...". These patches and series should be applied in numerical order, and applied on top of Linux 2.6.8.1. Yes, the first patch series really does start at 14 (due to my internal patch numbering scheme).

Patch series 14 finishes off the major reworking of the resource handling in the PCMCIA code; there's still a few things which need doing, like properly sorting out how static-mapped sockets work. Merged into 2.6.9.
Patch series 15 and 16 are from Dominik Brodowski's patch sets which have previously appeared on the mailing list, but brought up to date. Now merged into the post-2.6.10 BK snapshots.
Patch series 17 and 18 are again from Dominik Brodowski's patch sets, and adds further device model support to PCMCIA. Unmerged, please test.
Patch series 19 contains gash bits and pieces which sort various problems remaining on ARM platforms. Patch series 20 contains other stuff which generally require further work before becoming mergable with mainline, and therefore are subject to complete reorganisation. You are advised NOT to apply these series unless you have a specific interest in them.

14-pcmcia-resource-3 patch series (.tar.gz) (.tar.bz2) (last updated: 23 Aug 2004 18:57:56 UTC)
15-pcmcia-obsolete patch series (.tar.gz) (.tar.bz2) (last updated: 23 Aug 2004 18:28:33 UTC)
16-pcmcia-nomaster patch series (.tar.gz) (.tar.bz2) (last updated: 23 Aug 2004 18:28:51 UTC)
17-pcmcia_device patch series (.tar.gz) (.tar.bz2) (last updated: 21 Oct 2004 20:43:12 UTC)
18-pcmcia_client_t patch series (.tar.gz) (.tar.bz2) (last updated: 21 Oct 2004 20:43:30 UTC)
19-pcmcia-arm patch series (.tar.gz) (.tar.bz2) (last updated: 23 Aug 2004 18:34:31 UTC)
20-pcmcia-misc patch series (.tar.gz) (.tar.bz2) (last updated: 23 Aug 2004 18:34:46 UTC)

Changes which affect card drivers

This section details changes in 2.6 which affect PCMCIA card driver authors.

Resource management. (as of 2.6.8)
Although the PCMCIA subsystem will allocate resources for cards, it no longer marks these resources busy. This means that driver authors are now responsible for claiming your resources as per other drivers in Linux. You should use request_region() to mark your IO regions in-use, and request_mem_region() to mark your memory regions in-use. The name argument should be a pointer to your driver name. Eg, for pcnet_cs, name should point to the string "pcnet_cs".

Useful programs

cbdump cbdump.c
This dumps the CardBus bridge registers. Currently, it only knows about Texas Instruments and some Ricoh CardBus bridges, but will dump the generic registers for all CardBus bridges.