Mailing List Archive

I have an i82365-compatible PCMCIA PCI that is non-CardBus, I'd want that PCI detection for it was put back.
I have a PCMCIA controller Cirrus Logic CL 6729 that is PCCARD only,
not CardBus, *BUT* is PCI not ISA. Everywhere I seem to read that PCI
are all CardBus. There are some exceptions. I was locked to 2.3.36
because at first glance changes made in kernel didn't allow my
PCMCIA bridge to work and origin pcmcia-cs package doesn't compile
anymore (bridges, then later cards) modules for 2.3.37+.
I never compile the CARDBUS option since I don't have (and don't
want to include in kernel) the feature. Recently I read discussions
about PCMCIA & 2.3.46-pre2 and I decided to tell that there are
non-CardBus PCI bridges, in hope support for mine will not disappear ;)
blackhole:~# uname -a
Linux blackhole 2.3.36 #4 jeu fév 10 03:08:23 CET 2000 i586 unknown
blackhole:~# lspci -v
00:00.0 Host bridge: United Microelectronics [UMC] UM8891N (rev b0)
Flags: bus master, medium devsel, latency 0
00:11.0 VGA compatible controller: Trident Microsystems TGUI 9660/968x/968x (rev d3) (prog-if 00 [VGA])
Flags: medium devsel
Memory at c0000000 (32-bit, non-prefetchable) [size=4M]
Memory at c0400000 (32-bit, non-prefetchable) [size=64K]
Memory at c1400000 (32-bit, non-prefetchable) [size=4M]
Expansion ROM at 0c000000 [disabled] [size=64K]
00:12.0 ISA bridge: United Microelectronics [UMC] UM8886N (rev b2)
Flags: bus master, medium devsel, latency 0
00:12.1 IDE interface: United Microelectronics [UMC] UM8886BF (rev 10) (prog-if
8a [Master SecP PriP])
Flags: fast devsel
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
00:18.0 PCMCIA bridge: Cirrus Logic CL 6729 (rev 07)
Flags: stepping, slow devsel
I/O ports at 3000 [size=4]
blackhole:~# lspci -vv
[...]
00:18.0 PCMCIA bridge: Cirrus Logic CL 6729 (rev 07)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 0
Region 0: I/O ports at 3000 [size=4]
Till 2.3.36, I don't use kernel source's PCMCIA options
Using the pcmcia-cs sourceforce, my card is detected as:
Feb 26 16:30:17 blackhole kernel: Linux PCMCIA Card Services 3.1.11
Feb 26 16:30:17 blackhole kernel: kernel build: 2.3.36 unknown
Feb 26 16:30:17 blackhole kernel: options: [pci] [apm]
Feb 26 16:30:17 blackhole kernel: Intel PCIC probe:
Feb 26 16:30:17 blackhole kernel: Cirrus PD6729 PCI-to-PCMCIA at slot 00:18, port 0x3000
Feb 26 16:30:17 blackhole kernel: host opts [0]: [ring] [1/5/0] [1/20/0]
Feb 26 16:30:17 blackhole kernel: host opts [1]: [ring] [1/5/0] [1/20/0]
Feb 26 16:30:17 blackhole kernel: ISA irqs (default) = 3,4,5,10,11 polling interval = 1000 ms
Feb 26 16:30:18 blackhole cardmgr[5368]: starting, version is 3.1.11
Feb 26 16:30:18 blackhole cardmgr[5368]: watching 2 sockets
For later kernels I'm using these options:
CONFIG_ISA=y
CONFIG_PCI=y
CONFIG_PCMCIA=m
CONFIG_I82365=y
CONFIG_NET_PCMCIA=y
CONFIG_PCMCIA_PCNET=m
CONFIG_PCMCIA_SERIAL=m
CONFIG_PCMCIA_SERIAL_CS=m
I found that giving io=0x3000 to the i82365.o module made it
successfully detected (as ISA-to-PCMCIA device instead of
PCI-to-PCMCIA) on 2.3.46+ (surely before).
Using the kernel native code on 2.3.47 and option io=0x3000:
Feb 24 04:17:39 blackhole kernel: Linux PCMCIA Card Services 3.1.11
Feb 24 04:17:39 blackhole kernel: kernel build: 2.3.47 #9 jeu fév 24 04:09:58
CET 2000
Feb 24 04:17:39 blackhole kernel: options: [pci] [apm]
Feb 24 04:17:40 blackhole kernel: Intel PCIC probe:
Feb 24 04:17:40 blackhole kernel: Cirrus PD672x ISA-to-PCMCIA at port 0x3000 ofs 0x00, 2 sockets
Feb 24 04:17:40 blackhole kernel: host opts [0]: [ring] [65/5/0] [1/20/0]
Feb 24 04:17:40 blackhole kernel: host opts [1]: [ring] [65/5/0] [1/20/0]
Feb 24 04:17:40 blackhole kernel: ISA irqs (default) = 3,5,7,10,11 polling interval = 1000 ms
on 2.3.46 I even got:
Feb 20 20:52:46 blackhole kernel: kernel build: 2.3.46 #4 dim fév 20 19:27:57
CET 2000
Feb 20 20:52:46 blackhole kernel: options: [pci] [apm]
Feb 20 20:52:46 blackhole kernel: Intel PCIC probe: not found.
Feb 20 20:52:46 blackhole kernel: ds: no socket drivers loaded!
Feb 20 20:53:01 blackhole kernel: Intel PCIC probe: not found.
Feb 20 20:54:10 blackhole kernel: Intel PCIC probe:
Feb 20 20:54:10 blackhole kernel: Cirrus PD672x ISA-to-PCMCIA at port 0x3000 ofs 0x00, 2 sockets
[...]
Anyways it's not very interesting to have lost PCI autodetection.
By the way: linux/drivers/pcmcia/i82365.c still has:
printk(KERN_INFO "Intel PCIC probe: ");
but all PCI probe code is removed. So some people would think their
PCI card was really probed (it wasn't at all), but not correctly
detected.
On the origin code: ftp://sourceforge.org/pcmcia/pcmcia-cs-3.1.11.tar.gz,
in pcmcia-cs-3.1.11/modules/i82365.c the PCI detection code is still
here, and there's somewhere a line describing my controller as PCI:
{ "Cirrus PD6729", IS_CIRRUS|IS_PCI, ID(CIRRUS, 6729) },
(but not IS_CARDBUS)
On Tue, 15 Feb 2000 Linus Torvalds wrote:
> The only real reason is that pci_socket.c can handle any kind of PCI
> PCCARD controller, while yenta.c just implements one specific class of
> controllers (namely the true cardbus ones). Right now any non-cardbus
> controller (whether it is PCI or ISA) just falls back on the i82365 code.
I hope it is destined very soon to be independant from CardBus.
> In the future, there might be non-cardbus PCI PCCARD controllers. Although
> the way things are looking, that kind of hardware is getting pretty
> scarce..
Well my laptop (Clevo 862) is more than 2 years old.
that is past, not future hehe ;)
So would it be possible to reconsider the assertion that "today, PCI
PCMCIA is always CardBus" , and have functions in pci_socket.o used
by i82365.o if kernel has options CONFIG_PCI (CONFIG_PCMCIA_PCI?)
and CONFIG_82365 ?
Adel Belhouane <void@pipo.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Re: I have an i82365-compatible PCMCIA PCI that is non-CardBus, I'd want that PCI detection for it was put back. [ In reply to ]
> I have a PCMCIA controller Cirrus Logic CL 6729 that is PCCARD only,
> not CardBus, *BUT* is PCI not ISA. Everywhere I seem to read that PCI
> are all CardBus. There are some exceptions. I was locked to 2.3.36
> because at first glance changes made in kernel didn't allow my
> PCMCIA bridge to work and origin pcmcia-cs package doesn't compile
> anymore (bridges, then later cards) modules for 2.3.37+.
I have a Kiwi OpenNote 680T that I use at work. Crappy thing, but it works.
It has an omega micro pci-to-pcmcia controller. 2.3.47 locks solid when
trying to find it (and thinks it's an isa-to-pcmcia)
> 00:18.0 PCMCIA bridge: Cirrus Logic CL 6729 (rev 07)
> Flags: stepping, slow devsel
> I/O ports at 3000 [size=4]
>
> Feb 26 16:30:17 blackhole kernel: Linux PCMCIA Card Services 3.1.11
> Feb 26 16:30:17 blackhole kernel: kernel build: 2.3.36 unknown
> Feb 26 16:30:17 blackhole kernel: options: [pci] [apm]
> Feb 26 16:30:17 blackhole kernel: Intel PCIC probe:
> Feb 26 16:30:17 blackhole kernel: Cirrus PD6729 PCI-to-PCMCIA at slot 00:18, port 0x3000
> Feb 26 16:30:17 blackhole kernel: host opts [0]: [ring] [1/5/0] [1/20/0]
> Feb 26 16:30:17 blackhole kernel: host opts [1]: [ring] [1/5/0] [1/20/0]
This is where mine locks up in 2.3.47, but there's nothing after the : on
those last 2 lines on mine.
> Feb 26 16:30:17 blackhole kernel: ISA irqs (default) = 3,4,5,10,11 polling interval = 1000 ms
> Feb 26 16:30:18 blackhole cardmgr[5368]: starting, version is 3.1.11
> Feb 26 16:30:18 blackhole cardmgr[5368]: watching 2 sockets
> Anyways it's not very interesting to have lost PCI autodetection.
> By the way: linux/drivers/pcmcia/i82365.c still has:
>
> printk(KERN_INFO "Intel PCIC probe: ");
>
> but all PCI probe code is removed. So some people would think their
> PCI card was really probed (it wasn't at all), but not correctly
> detected.
I guess this is why it says mine's an ISA instead of PCI. Grrrr.
--
Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/