[Bug 2944] Cardbus cards not seen on ti1620 cardbus controler
Alex Kavanagh
alex at tinwood.homelinux.org
Thu Apr 20 05:21:49 EDT 2006
Hi
(I'm the one with the DV1448 laptop...)
I'd love to help debug this if only I knew where to start looking!
I've applied the cardbus patch to a 2.6.16-ck3 kernel with an additional patch
that adds the detection of the U630 Merlin G3 card I have.
I've also added some extra debug to try to work out what is going on:
dmesg now looks like this:
[4513461.770000] ACPI: PCI interrupt for device 0000:06:09.0 disabled
[4513524.668000] ACPI: PCI Interrupt 0000:06:09.0[A] -> GSI 20 (level, low) -> IRQ 16
[4513524.668000] Yenta: CardBus bridge found at 0000:06:09.0 [103c:3080]
[4513524.669000] Yenta: Using CSCINT to route CSC interrupts to PCI
[4513524.669000] Yenta: Routing CardBus interrupts to PCI
[4513524.669000] Yenta TI: socket 0000:06:09.0, mfunc 0x01a01b22, devctl 0x64
[4513524.893000] Yenta: ISA IRQ mask 0x0cf8, PCI irq 16
[4513524.893000] Socket status: 30000086
[4513524.893000] Yenta: Raising subordinate bus# of parent bus (#06) from #06 to #0a
[4513524.893000] cs: : pcmcia_register_socket(0xf05a0bf0)
[4513524.895000] pcmcia: parent PCI bridge I/O window: 0x3000 - 0x3fff
[4513524.895000] cs: IO port probe 0x3000-0x3fff: clean.
[4513524.896000] pcmcia: parent PCI bridge Memory window: 0xb0100000 - 0xb01fffff
[4513524.896000] pcmcia: parent PCI bridge Memory window: 0x50000000 - 0x51ffffff
[4513525.981000] cs: IO port probe 0x100-0x3af: clean.
[4513525.983000] cs: IO port probe 0x3e0-0x4ff: excluding 0x4d0-0x4d7
[4513525.986000] cs: IO port probe 0x820-0x8ff: clean.
[4513525.987000] cs: IO port probe 0xc00-0xcf7: clean.
[4513525.988000] cs: IO port probe 0xa00-0xaff: clean.
[4513542.723000] pccard: PCMCIA card inserted into slot 0
[4513542.723000] cs: pcmcia_socket0: send_event(event 4, pri 0, callback 0xf06bcbd0)
[4513542.723000] ds: ds_event(0x000004, 0, 0xc8161028)
[4513542.724000] cs: memory probe 0xb0100000-0xb01fffff: excluding 0xb0100000-0xb010ffff
[4513542.743000] ds: pcmcia_card_add, no_funcs = 2
[4513542.744000] pcmcia: registering new device pcmcia0.0
[4513542.750000] pcmcia: registering new device pcmcia0.1
[4513543.023000] serial_attach()
[4513543.023000] serial_config(0xc76b6a00)
[4513543.024000] info->multi 1
[4513543.024000] S is 0, try is 0
[4513543.024000] port was found: io.BasePort1(0x 3f8), io.IOAddrLines(16)
[4513543.065000] Going to setup the serial port...
[4513543.087000] No idea what the port is.
[4513543.089000] serial8250_register_port: iobase(0x 3f8), membase(0x00000000), irq(3), iotype(0), flags(0x11000040)
[4513543.089000] Didn't fail configuration
[4513543.089000] ds: Checking if it's a pseudo device.
[4513543.090000] serial_attach()
[4513543.090000] serial_config(0xdda16e00)
[4513543.091000] info->multi 1
[4513543.091000] S is 0, try is 0
[4513543.091000] port was found: io.BasePort1(0x 2f8), io.IOAddrLines(16)
[4513543.131000] Going to setup the serial port...
[4513543.149000] No idea what the port is.
[4513543.150000] serial8250_register_port: iobase(0x 2f8), membase(0x00000000), irq(3), iotype(0), flags(0x11000040)
[4513543.150000] Didn't fail configuration
[4513543.150000] ds: Checking if it's a pseudo device.
My problem is basically that the actual serial port uarts are not
being detected. Is this related to the Yenta issue? (Note the 'port
was found: ...' line is a debug line where the serial_cs *thinks* it
found a port), from this bit of code:
/* Two tries: without IO aliases, then with aliases */
for (s = 0; s < 2; s++) {
for (try = 0; try < 2; try++) {
i = first_tuple(handle, tuple, parse);
while (i != CS_NO_MORE_ITEMS) {
if (i != CS_SUCCESS)
goto next_entry;
if (cf->vpp1.present & (1 << CISTPL_POWER_VNOM))
link->conf.Vpp1 = link->conf.Vpp2 =
cf->vpp1.param[CISTPL_POWER_VNOM] / 10000;
if ((cf->io.nwin > 0) && (cf->io.win[0].len == size_table[s]) &&
(cf->io.win[0].base != 0)) {
link->conf.ConfigIndex = cf->index;
link->io.BasePort1 = cf->io.win[0].base;
link->io.IOAddrLines = (try == 0) ?
16 : cf->io.flags & CISTPL_IO_LINES_MASK;
i = pcmcia_request_io(link->handle, &link->io);
//ajk start
if (i == CS_SUCCESS) {
DEBUG(0, "S is %d, try is %d\n", s, try);
DEBUG(0, "port was found: io.BasePort1(0x%4x), io.IOAddrLines(%d)\n", link->io.BasePort1, link->io.IOAddrLines);
}
//ajk stop
if (i == CS_SUCCESS)
goto found_port;
}
My new lspci --v | grep sub is now:
Bus: primary=00, secondary=06, subordinate=0a, sec-latency=216
Bus: primary=06, secondary=07, subordinate=0a, sec-latency=176
Which I'm guessing is the appropriate fix up.
The additional debug lines are to try to work out what is going on
with the card.
My problem, and it's a lack of familiarity with how the kernel
schedules threads, is how the card insert event
(CS_EVENT_CARD_INSERTION) actually eventually runs the code that takes
the fact that the card has a function 2 (serial ?) and gets a driver
to locate the serial ports.
I've traced into serial_cs but only to do the debug lines above.
I'm scratching the surface a bit here and not sure where to look.
Any ideas on what I should be looking at to work out why the various
bits of code are not 'finding' the 16550A uarts on the card. (The
card works perfectly in another laptop running the same kernel).
Cheers
Alex.
At Wed, 19 Apr 2006 15:52:03 -0700,
bugme-daemon at bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=2944
>
> bk at suse.de changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |linux-
> | |pcmcia at lists.infradead.org
>
>
>
> ------- Additional Comments From bk at suse.de 2006-04-19 15:51 -------
> Bug #5557 is also about the same problem some related info can be found there.
>
> Looking thru the mail archives of February, March and April (until today) of
> linux-pcmcia on http://lists.infradead.org/pipermail/linux-pcmcia/ , I have
> found five additional laptops which should be fixed with this patch:
>
> Alex Kavanagh
> - HP DV1448:
> Bus: primary=00, secondary=06, subordinate=06, sec-latency=216
> Bus: primary=06, secondary=07, subordinate=0a, sec-latency=176
> http://lists.infradead.org/pipermail/linux-pcmcia/2006-April/003492.html
>
> Nicolas Bellido
> - Toshiba Satellite Pro A60 with TI PCI1440 Cardbus controller:
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
> Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
> http://lists.infradead.org/pipermail/linux-pcmcia/2006-March/003350.html
>
> Chris Lu
> - Unknown machine based on nVidia Corporation nForce3 Host Bridge (rev a4):
> Bus: primary=00, secondary=02, subordinate=02, sec-latency=128
> Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
> http://lists.infradead.org/pipermail/linux-pcmcia/2006-March/003356.html
>
> Jeremy Johnson
> - Kyocera KPC650:
> Bus: primary=00, secondary=05, subordinate=05, sec-latency=64
> Bus: primary=05, secondary=06, subordinate=09, sec-latency=176
> http://lists.infradead.org/pipermail/linux-pcmcia/2006-April/003459.html
>
> Diego Martín
> - Unkonwn ICH6 Machine without lspci -vv but fixed also with pci=assign-busses:
> 0000:02:04.0 CardBus bridge: ENE Technology Inc CB-710/2/4 Cardbus Controller
> http://lists.infradead.org/pipermail/linux-pcmcia/2006-March/003419.html
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
> _______________________________________________
> Linux PCMCIA reimplementation list
> http://lists.infradead.org/mailman/listinfo/linux-pcmcia
More information about the linux-pcmcia
mailing list