Linux Kernel 2.6 PCMCIA - socket power bugs

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.

Affected systems

This has been seen on the following machines:

Machine	Bridge	Comment
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.

Suggestion for TI1225-based PCI adapters:

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.

Bugreports

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

1. the machine type
2. cardbus bridge type
3. the full lspci -vv output
4. cbdump output (part of pcmciautils)

to the mailing list. 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.

This is similar to the above problem - some PCMICA bridges refuse to remove socket power when we ask them to.

This problem was tracked down to 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.

A fix which does automatically avoids the use of such areas was merged into 2.6.11. However, this automatic tweaking is not aware of shared video RAM. Therefore, on machines where such RAM isn't reported to the kernel, you may still need to pass a reserve= setting on 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.