Hi:
Machine Mode: Dell Latitude V740.
PCMCIA card: OPTION (GLOBETROTTER)
Kernel : 2.5.70-mm4 #29 ?? 6?? 14 18:57:13 CST 2003
Cardctl -V : cardctl version 3.1.33
The cards is works fine in windows, How can I let it works in linux, Any information is welcome.
Thanks.
--daemon.log---
Jun 15 10:29:48 hugang cardmgr[361]: executing: 'modprobe -r 8250_cs'
Jun 15 10:31:27 hugang cardmgr[361]: exiting
Jun 15 10:31:27 hugang cardmgr[3484]: starting, version is 3.1.33
Jun 15 10:31:27 hugang cardmgr[3484]: watching 1 sockets
Jun 15 10:31:27 hugang cardmgr[3484]: Card Services release does not match
Jun 15 10:31:38 hugang cardmgr[3484]: socket 0: EE828
Jun 15 10:31:39 hugang cardmgr[3484]: executing: 'modprobe 8250_cs'
Jun 15 10:31:40 hugang cardmgr[3484]: get dev info on socket 0 failed: Resource temporarily unavailable
--dmesg---
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x3c0-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
serial_cs: RequestConfiguration: Bad Vcc
---/proc/ioport---
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-10ff : PCI CardBus #03
1400-14ff : PCI CardBus #03
1800-181f : PCI device 8086:2482
1800-181f : uhci-hcd
1820-183f : PCI device 8086:2484
1820-183f : uhci-hcd
1840-184f : PCI device 8086:248a
1840-1847 : ide0
1848-184f : ide1
1860-187f : PCI device 8086:2483
1880-18bf : PCI device 8086:2485
1880-18bf : Intel 82801CA-ICH3 - Controller
1c00-1cff : PCI device 8086:2485
1c00-1cff : Intel 82801CA-ICH3 - AC'97
2000-207f : PCI device 8086:2486
2400-24ff : PCI device 8086:2486
3000-307f : PCI device 10b7:9200
--/proc/interrupt---
CPU0
0: 6653619 XT-PIC timer
1: 6948 XT-PIC i8042
2: 0 XT-PIC cascade
5: 2162 XT-PIC uhci-hcd
8: 3 XT-PIC rtc
9: 2 XT-PIC acpi
10: 19 XT-PIC PCI device 1217:6972, uhci-hcd, Intel 82801CA-ICH3
12: 7191 XT-PIC i8042
14: 9436 XT-PIC ide0
15: 1 XT-PIC ide1
NMI: 0
ERR: 0
--dump_cis -vSocket 0:
offset 0x02, tuple 0x01, link 0x03
00 00 ff
dev_info
NULL 0ns, 512b
offset 0x07, tuple 0x1c, link 0x04
02 00 00 ff
offset 0x0d, tuple 0x15, link 0x13
04 01 45 26 45 00 45 45 38 32 38 00 30 30 31 00
41 00 ff
vers_1 4.1, "E&E", "EE828", "001", "A"
offset 0x22, tuple 0x20, link 0x04
13 00 00 00
manfid 0x0013, 0x0000
offset 0x28, tuple 0x21, link 0x02
02 00
funcid serial_port
offset 0x2c, tuple 0x22, link 0x04
00 02 00 18
serial_interface
uart 16550 [8] [1]
offset 0x32, tuple 0x22, link 0x09
05 1f 0f 00 03 00 00 03 00
serial_modem_cap_data
flow [XON/XOFF xmit] [XON/XOFF rcv] [hw xmit] [hw rcv] [transparent]
cmd_buf 64 rcv_buf 768 xmit_buf 768
offset 0x3d, tuple 0x22, link 0x0d
02 06 00 2e 04 03 03 0f 07 00 01 b5 ff
serial_data_services
data_rate 115200
modulation [V.21] [V.23] [V.22] [V.22bis] [V.32]
error_control [MNP2-4] [V.42/LAPM]
compression [V.42bis] [MNP5]
cmd_protocol [AT1] [AT2] [AT3] [MNP_AT]
offset 0x4c, tuple 0x1a, link 0x05
01 31 00 04 01
config base 0x0400 mask 0x0001 last_index 0x31
offset 0x53, tuple 0x1b, link 0x0a
f0 01 19 01 b5 1e 24 30 ff ff
cftable_entry 0x30 [default]
Vcc Vnom 3300mV
io 0x0000-0x000f [lines=4] [8bit]
irq mask 0xffff [level]
offset 0x5f, tuple 0x1b, link 0x09
f1 01 19 01 55 24 30 ff ff
cftable_entry 0x31 [default]
Vcc Vnom 5V
io 0x0000-0x000f [lines=4] [8bit]
irq mask 0xffff [level]
offset 0x6a, tuple 0x14, link 0x00
no_long_link
--
Hu Gang / Steve
Email : [email protected], [email protected]
GPG FinePrint: 4099 3F1D AE01 1817 68F7 D499 A6C2 C418 86C8 610E
http://soulinfo.com/~hugang/HuGang.asc
ICQ# : 205800361
Registered Linux User : 204016
On Sun, Jun 15, 2003 at 10:43:22AM +0800, hugang wrote:
> Machine Mode: Dell Latitude V740.
> PCMCIA card: OPTION (GLOBETROTTER)
> Kernel : 2.5.70-mm4 #29 ?? 6?? 14 18:57:13 CST 2003
> Cardctl -V : cardctl version 3.1.33
>
> The cards is works fine in windows, How can I let it works in linux, Any
> information is welcome.
Could you include the information below and the output of cardctl
status please?
I think I can tell you what's happening. Your card contains two
configuration table entries (0x30 and 0x31). The first, 0x30,
tells us that the card supports 3.3V in this configuration. The
second indicates that the card supports 5V with this configuration.
I suspect that the card voltage sense pins are indicating that the
card requires 5V, but we're trying to use the 0x30 configuration.
Since we don't allow the socket voltage to be altered, we error out
and never try the second configuration.
David, I think it would make sense to allow the PCMCIA subsystem to
lower VCC in these circumstances, but obviously never allow it to be
raised above the value reported by the voltage sense pins?
> --dmesg---
> cs: IO port probe 0x0c00-0x0cff: clean.
> cs: IO port probe 0x0800-0x08ff: clean.
> cs: IO port probe 0x0100-0x04ff: excluding 0x3c0-0x3df 0x4d0-0x4d7
> cs: IO port probe 0x0a00-0x0aff: clean.
> Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
> serial_cs: RequestConfiguration: Bad Vcc
> --dump_cis -vSocket 0:
> offset 0x02, tuple 0x01, link 0x03
> 00 00 ff
> dev_info
> NULL 0ns, 512b
>
> offset 0x07, tuple 0x1c, link 0x04
> 02 00 00 ff
>
> offset 0x0d, tuple 0x15, link 0x13
> 04 01 45 26 45 00 45 45 38 32 38 00 30 30 31 00
> 41 00 ff
> vers_1 4.1, "E&E", "EE828", "001", "A"
>
> offset 0x22, tuple 0x20, link 0x04
> 13 00 00 00
> manfid 0x0013, 0x0000
>
> offset 0x28, tuple 0x21, link 0x02
> 02 00
> funcid serial_port
>
> offset 0x2c, tuple 0x22, link 0x04
> 00 02 00 18
> serial_interface
> uart 16550 [8] [1]
>
> offset 0x32, tuple 0x22, link 0x09
> 05 1f 0f 00 03 00 00 03 00
> serial_modem_cap_data
> flow [XON/XOFF xmit] [XON/XOFF rcv] [hw xmit] [hw rcv] [transparent]
> cmd_buf 64 rcv_buf 768 xmit_buf 768
>
> offset 0x3d, tuple 0x22, link 0x0d
> 02 06 00 2e 04 03 03 0f 07 00 01 b5 ff
> serial_data_services
> data_rate 115200
> modulation [V.21] [V.23] [V.22] [V.22bis] [V.32]
> error_control [MNP2-4] [V.42/LAPM]
> compression [V.42bis] [MNP5]
> cmd_protocol [AT1] [AT2] [AT3] [MNP_AT]
>
> offset 0x4c, tuple 0x1a, link 0x05
> 01 31 00 04 01
> config base 0x0400 mask 0x0001 last_index 0x31
>
> offset 0x53, tuple 0x1b, link 0x0a
> f0 01 19 01 b5 1e 24 30 ff ff
> cftable_entry 0x30 [default]
> Vcc Vnom 3300mV
> io 0x0000-0x000f [lines=4] [8bit]
> irq mask 0xffff [level]
>
> offset 0x5f, tuple 0x1b, link 0x09
> f1 01 19 01 55 24 30 ff ff
> cftable_entry 0x31 [default]
> Vcc Vnom 5V
> io 0x0000-0x000f [lines=4] [8bit]
> irq mask 0xffff [level]
>
> offset 0x6a, tuple 0x14, link 0x00
> no_long_link
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sun, 15 Jun 2003 10:34:56 +0100
Russell King <[email protected]> wrote:
> Could you include the information below and the output of cardctl
> status please?
>
Thank you very much.
> I think I can tell you what's happening. Your card contains two
> configuration table entries (0x30 and 0x31). The first, 0x30,
> tells us that the card supports 3.3V in this configuration. The
> second indicates that the card supports 5V with this configuration.
Your are right. With this patch it works fine.
--- cs.c.old Sun Jun 15 19:46:26 2003
+++ cs.c Sun Jun 15 19:52:51 2003
@@ -1765,8 +1765,10 @@
return CS_CONFIGURATION_LOCKED;
/* Do power control. We don't allow changes in Vcc. */
- if (s->socket.Vcc != req->Vcc)
- return CS_BAD_VCC;
+ printk("VCC: %d, %d\n", s->socket.Vcc, req->Vcc);
+ /*if (s->socket.Vcc != req->Vcc)
+ return CS_BAD_VCC;*/
+ printk("Vpp1: %d, %d\n", req->Vpp1, req->Vpp2);
if (req->Vpp1 != req->Vpp2)
return CS_BAD_VPP;
s->socket.Vpp = req->Vpp1;
---2.5.71-------without-hacker
hugang:/home/hugang/download/module-init# uname -a
Linux hugang 2.5.71 #4 ?? 6?? 15 11:44:04 CST 2003 i686 unknown
hugang:/home/hugang/download/module-init# cardctl config
Socket 0:
Vcc 3.3V Vpp1 3.3V Vpp2 3.3V
hugang:/home/hugang/download/module-init# cardctl status
Socket 0:
3.3V 16-bit PC Card
function 0: [ready], [wp], [bat low]
--with-hacker--
VCC: 33, 50
Vpp1: 0, 0
ttyS0 at I/O 0x100 (irq = 3) is a 16550A
hugang:~# cardctl status
Socket 0:
3.3V 16-bit PC Card
function 0: [ready]
hugang:~# cardctl config
Socket 0:
Vcc 5.0V Vpp1 0.0V Vpp2 0.0V
interface type is "memory and I/O"
irq 3 [exclusive] [level]
speaker output is enabled
function 0:
config base 0x0400
option 0x70
io 0x0100-0x010f [8bit]
--
Hu Gang / Steve
Email : [email protected], [email protected]
GPG FinePrint: 4099 3F1D AE01 1817 68F7 D499 A6C2 C418 86C8 610E
http://soulinfo.com/~hugang/HuGang.asc
ICQ# : 205800361
Registered Linux User : 204016
On Sun, Jun 15, 2003 at 10:34:56AM +0100, Russell King wrote:
>
> I suspect that the card voltage sense pins are indicating that the
> card requires 5V, but we're trying to use the 0x30 configuration.
> Since we don't allow the socket voltage to be altered, we error out
> and never try the second configuration.
>
> David, I think it would make sense to allow the PCMCIA subsystem to
> lower VCC in these circumstances, but obviously never allow it to be
> raised above the value reported by the voltage sense pins?
Changing Vcc on the fly turns out to be pretty complicated: you are
required to power down the socket, and power it up again from scratch,
which takes several seconds. In practice it is essentially never
useful since the card should always be operable at the voltage it
indicated at power-up time.
The pcmcia-cs package and the 2.4 kernel PCMCIA subsystem already do
the right thing. The 2.5 8250_cs driver had been sufficiently altered
(reindented, line breaks moved around, etc) that applying patches is
quite inconvenient and I had not gotten around to going through line
by line and figuring out what changes needed to be applied.
Probably, the best thing would be for cs.c in the kernel to do what
the pcmcia-cs package now does: just print a warning and ignore Vcc
values that don't match the power-up voltage.
The only useful case I could come up with for changing the power-up
voltage, is that some cards (compact flash I know, perhaps more) run
faster at 5V than at 3.3V, and the user might want to choose between
higher performance or better battery life.
-- Dave
On Sun, Jun 15, 2003 at 08:40:19PM -0700, David Hinds wrote:
> The pcmcia-cs package and the 2.4 kernel PCMCIA subsystem already do
> the right thing. The 2.5 8250_cs driver had been sufficiently altered
> (reindented, line breaks moved around, etc) that applying patches is
> quite inconvenient and I had not gotten around to going through line
> by line and figuring out what changes needed to be applied.
I've just updated 8250_cs.c with the changes found in pcmcia-cs 3.1.32
and 3.1.34, and updated the revision IDs to match that. This includes
both the changes to ignore the Vcc in the CIS (and use the detected
voltages) and the "buggy uart" business.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html