Merlin U630 problems, HP1448 with pcixx21 (was Re: [Bug 2944] Cardbus cards not seen on ti1620 cardbus controller)

Tue Apr 25 06:37:13 EDT 2006

At Sun, 23 Apr 2006 21:24:44 +0200 (CEST),
Bernhard Kaindl wrote:
> 
> On Fri, 21 Apr 2006, Alex Kavanagh wrote:
> 
> > > > 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.
> > 
> > Well, I think so, but I'm not convinced, because the serial uart
> > detection code bails out without finding the 16650 that is supposed to
> > be on the card.
> 
> At least it printed the port numbers and gave you a device.

Indeed.  However, it doesn't actually find the port!

> 
> Did you check the list on 
> http://www.linux-on-laptops.com/hp.html
> for similar laptops than yours for known issues?

Yes.

> 
> Did you try setserial to set the uart type?

Yes, no luck.

> 
> If it works then, it would be a detection issue only, otherwise
> something else is broken. That would be valuable to know...

It's the 'something else is broken issue'.

> 
> BTW, do you have still access to the other laptop where it works?
> 
> What I sometimes do - if I have two setups, one working, one not, is
> to compare the debug outputs from the two systems and look for the
> place where the differences start to emerge...

I tried to do that.  Although bus numbers are different, I/O ranges
are different the basic set-up between the two laptops is the same.
The glaring difference is that mine has a TI pcixx21/x515 cardbus
bridge and the other one doesn't (it has an ENE bridge).

> 
> It may well be a bug which may have been introduced since 2.6.12
> (I guess that was the kernel version on the working setup) or
> some problem with setting up the hardware on your system.

I expect it is the latter.

> But I have no idea how (it seems I missed that somehow) you
> came to the conclusion that the card needs a CIS override
> on your notebook.

It was very minor (an offset of 4d instead of 4c) and I don't think it
has any effect.  Still, I've learnt how to do that on the system ...

> 
> As you said that the card is working with 2.6.12 on a different
> Linux laptop, I would not see the card or something which comes
> with the card (like it's CIS) at fault.

I tend to agree with you but I didn't know whether it was 2.6.16 being
more picky about what it would support.  However, I don't think that
this is the issue at all - the CIS stuff is simply a red-herring.

My latest thoughts on what *could* be going on now come down to the
interaction between the PCI-to-PCI bridge (an Intel 82801BAM in CH6)
and the TI PCIxx21/x515 cardbus bridge.

Here's what gets set up:

 - The G3 card is an R2 16-bit I/O card (serial)
 - The PCI-to-PCI bridge has allocations as per:

0000:00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3) (prog-if 01 [Subtractive decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=05, sec-latency=216
        I/O behind bridge: 00003000-00003fff
        Memory behind bridge: b0100000-b01fffff
        Prefetchable memory behind bridge: 0000000050000000-0000000051f00000
        BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capabilities: [50] #0d [0000]

i.e. the I/O behind the bridge is 0x3000-0x3fff

 - The cardbus bridge has allocations as:

0000:01:09.0 CardBus bridge: Texas Instruments PCIxx21/x515 Cardbus Controller
        Subsystem: Hewlett-Packard Company: Unknown device 3080
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 168, Cache Line Size: 0x20 (128 bytes)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at b0109000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=01, secondary=02, subordinate=05, sec-latency=176
        Memory window 0: 50000000-51fff000 (prefetchable)
        Memory window 1: 54000000-55fff000
        I/O window 0: 00003400-000034ff
        I/O window 1: 00003800-000038ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001

i.e. I/O window 0 and I/O window 1 are inside 0x3000-0x3fff

However, and this is the bit I don't understand, the I/O ports on the
3G card that want to be allocated are:

  I365_IO0_START                 [08] : 0x03f8
  I365_IO0_STOP                  [0a] : 0x03ff
  I365_IO1_START                 [0c] : 0x02f8
  I365_IO1_STOP                  [0e] : 0x02ff

e.g. at 0x02f8-0x3ff.

But this is outside of the I/O window on the PCI-to-PCI bus
(0x3000-0x3fff).

Is this the problem?  How, I asked myself, can an I/O read of 0x3f8
actually reach the PCMCIA card which is behind the PCI-to-PCI bus
ranges?  I got the 82801 datasheet and found the following line in it
regarding I/O ranges:

"I/O Space Enable (IOE) R/W. The ICH2 provides this bit as
read/writable for software only.  However, the ICH2 ignores the
programming of this bit and runs hub interface I/O cycles to PCI that
are not intended for USB, IDE, or AC'97."

As a sidenote, my revision of the 82801 is a 'D3' which I think
belongs to the ICH6 chipset.  Maybe this doesn't forward I/O cycles??
Anyone know?

I think this means that the PCI-to-PCI bus will at least forward it to
the pcixx21/x515 bus?  Can anyone confirm this??  Is the PCI-to-PCI
bus in subtractive mode rather than positive-decode?

So, assuming that the pci-to-pci bus forwards those I/O requests, I
then looked at the pcixx21 ExCA registers.  And, as noted above, they
are okay.

So on the face of it, the CPU *ought* to be able to read/write the
card's registers at 0x03f8.  But the error from the serial.c code is:

[4477129.111000] ttyS0: autoconf (0x03f8, 0x00000000): IER test failed (ff, ff) type=unknown

This, as I understand the code, means that the hardware simply isn't
there when it is probed for.

My conclusion is thus:

1. The configuration space for the pcixx21 can be reached via the
   pci-to-pci bus because we can read/write its registers.
2. The actual card itself can't be reached.  It definitely powers up
   (little lights flash).  Thus, for some reason, when I/O 0x03f8 is
   accessed, the actual card doesn't get read - the pcixx21 never
   selects the card.
3. Is this because the pci-to-pci bus won't forward the I/O requests.
   Is my ICH6 different in functionality to the ICH2.  (I'm still
   hunting down the datasheet for the ICH6).

Question:

Does the actual PCMCIA card live on numbered bus?  i.e. when the PCI
I/O request is initiated, does it target the PCMCIA card device
(pcmcia0.0) and what PCI dev/bus would this be, or does it target the
bus/dev of the Cardbus bridge and that simply forwards it?  Am I
looking at a subordinate bus numbering problem or a completely
separate piece of hardware not being configured properly.

Thanks for any help that you can provide.  Apologies for the long
post.  Sometimes it helps just to 'talk' the issues out loud ... :-)

Cheers
Alex.
-- 
Alex Kavanagh