[Bug 2944] Cardbus cards not seen on ti1620 cardbus controler

[Bernhard Kaindl]

On Thu, 20 Apr 2006, Alex Kavanagh wrote:

> 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.
...
> [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

Indeed, this is the message which I expected, that part is fine as you also found.

> [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?
 
No, my Yenta fixup patch is a PCI-bus-configuration-level fixup of the
parent PCI bride thru which the Cardbus controller is connected to the
PCI bus of your CPU.

That level has nothing to do (is far far away) from the kind of UART chip
which is on your cardbus card. What the my Yenta fixup patch does is
only that it reconfigures the parent PCI bridge of the all CardBus
controllers supported by Linux.

Yenta obvoisly stands for match-maker, it's is integrated driver which
suppors all the Linux-supported CardBus controllers, and "matches" the
System with the Cards :-) : http://en.wikipedia.org/wiki/Yenta

My Yenta patch just helps the Yenta to fix the system to make the
CPU actually "see" CardBus card so they can get married :)

> was found: ...' line is a debug line where the serial_cs *thinks* it
> found a port), from this bit of code:

> DEBUG(0, "port was found: io.BasePort1(0x%4x), io.IOAddrLines(%d)\n", link->io.BasePort1, link->io.IOAddrLines);

Good, so it at least finds the IO address port of the UART, it seems.

> 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.

Yes, that's the fixed PCI bus setup, the first subordinate number had
to be raised from 06 to 0a to match the subordinate number of the second
line shows how linix configured is the CardBus bridge.

> 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.

Not knowing how CS_EVENT_CARD_INSERTION actually runs the code does
not appear to be a problem, your debug messages reaches the right place:

> 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.

It always starts on the surface...

> 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).

This message (I assume, you added it) looks like pointing at a problem spot:

> [4513543.149000] No idea what the port is.

your setserial output was:

/dev/ttyS0, Line 0, UART: unknown, Port: 0x03f8, IRQ: 20
        Baud_base: 115200, close_delay: 50, divisor: 0
        closing_wait: 3000
        Flags: spd_normal skip_test

You could try to use setserial to tell the serial port driver which UART
type shall use for this port. From man setserial:

    uart uart_type
              This option is used to set the UART type.  The permitted
types  are  none,  8250,  16450,  16550, 16550A,  16650, 16650V2, 16654,
16750, 16850, 16950, and 16954.  Using UART type none will disable the port.

Bernhard