[parisc-linux] Matrox Millenium II in C240

[parisc-linux] Matrox Millenium II in C240

[Peter 'p2' De Schrijver]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

Hi,

I installed a matrox millenium 2 in my C240 box and try to get the
framebuffer device for it to work under linux. Unfortunately I get a
kernel panic at the first access to mmio space of the card. The card
resides in a 32bit PCI slot (it's a 5V only card, so it has to). I get
the impression there is something wrong with the resource assignment of
the card. Unfortunately I'm stuck at this point, since I don't have a
clear view on how all the busses in this system are interconnected and
which bus address translations are happening. Is this somewhere
documented ? Has anyone before succeeded in accessing mmio space of PCI
card attached to the 32bit PCI bus of the C240 ?

Thanks,

Peter.

[-- Attachment #2: lspci-output --]
[-- Type: text/plain, Size: 1476 bytes --]

00:01.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] (prog-if 00 [VGA])
	Subsystem: Matrox Graphics, Inc.: Unknown device 2003
	Flags: medium devsel, IRQ 97
	Memory at f9000000 (32-bit, prefetchable) [size=16M]
	Memory at f3ffc000 (32-bit, non-prefetchable) [size=16K]
	Memory at f2800000 (32-bit, non-prefetchable) [size=8M]
	Expansion ROM at f3f80000 [disabled] [size=64K]

00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR) 53c875 (rev 04)
	Flags: bus master, medium devsel, latency 255, IRQ 99
	I/O ports at fe00 [size=256]
	Memory at f3ff9000 (32-bit, non-prefetchable) [size=256]
	Memory at f3ffa000 (32-bit, non-prefetchable) [size=4K]

00:14.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
	Subsystem: Hewlett-Packard Company: Unknown device 104f
	Flags: bus master, medium devsel, latency 255, IRQ 96
	I/O ports at ff00 [size=128]
	Memory at f3ffb000 (32-bit, non-prefetchable) [size=1K]
	Expansion ROM at f3f80000 [disabled] [size=256K]

01:02.0 Ethernet controller: Netgear GA620 (rev 01)
	Subsystem: Netgear: Unknown device 0001
	Flags: fast Back2Back, 66Mhz, medium devsel, IRQ 130
	Memory at f1ffc000 (32-bit, non-prefetchable) [disabled] [size=16K]

01:04.0 Display controller: Hewlett-Packard Company: Unknown device 1008 (rev 02)
	Flags: 66Mhz, medium devsel, IRQ 128
	Memory at f6000000 (64-bit, non-prefetchable) [size=32M]
	Expansion ROM at f1c00000 [disabled] [size=2M]

Re: [parisc-linux] Matrox Millenium II in C240

[Grant Grundler]

On Thu, Jan 02, 2003 at 01:38:56PM +0100, Peter 'p2' De Schrijver wrote:
> I installed a matrox millenium 2 in my C240 box and try to get the
> framebuffer device for it to work under linux. Unfortunately I get a
> kernel panic at the first access to mmio space of the card.

Sounds like a driver problem.

> The card resides in a 32bit PCI slot (it's a 5V only card, so it has to).

Does it? are the 64-bit slots 3.3v only?
I've never had to pay much attention for how the slots are keyed
since I mostly use "universal" PCI cards (both 3.3 and 5v tolerant).

> I get
> the impression there is something wrong with the resource assignment of
> the card.

Doesn't look like it to me based on lspci output.

> Is this somewhere documented ?

hmm...sort of in the ioscan output in the HW DB.
Or look at the hw paths printed at boot time.

> Has anyone before succeeded in accessing mmio space of PCI
> card attached to the 32bit PCI bus of the C240 ?

SCSI is accessed that way. tulip driver can be tweaked to use MMIO
if you don't have any 100BT GSC (card-mode Dino) cards.

> 00:01.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] (prog-if 00 [VGA])
> 	Subsystem: Matrox Graphics, Inc.: Unknown device 2003
> 	Flags: medium devsel, IRQ 97
> 	Memory at f9000000 (32-bit, prefetchable) [size=16M]
> 	Memory at f3ffc000 (32-bit, non-prefetchable) [size=16K]
> 	Memory at f2800000 (32-bit, non-prefetchable) [size=8M]
> 	Expansion ROM at f3f80000 [disabled] [size=64K]

Looks like PDC/IODC did it's thing.
Look at matrox drivers to make sure they are calling
"pci_device_enable()" and ioremap() before attempting to access
the device.

Check /proc/iomem to see which PCI bus controller
this is getting routed through and that the system
has correctly identified the MMIO resources.

It's interesting one device has MMIO at both 0xf2800000
and 0xf9000000 since it would imply one PCI controller is supposed
to forward the entire range of addresses. But Dino only forwards
(any number of) 8MB chunks between 0xf0800000 and 0xff800000 (except
the first and last 8MB chunks).

> 01:04.0 Display controller: Hewlett-Packard Company: Unknown device 1008 (rev 02)
> 	Flags: 66Mhz, medium devsel, IRQ 128
> 	Memory at f6000000 (64-bit, non-prefetchable) [size=32M]
> 	Expansion ROM at f1c00000 [disabled] [size=2M]

similar scenario but this device forces both PCI bus controllers
to "interleave" MMIO ranges they respond to. Looks ok though.

grant

Re: [parisc-linux] Matrox Millenium II in C240

[Matthew Wilcox]

On Thu, Jan 02, 2003 at 10:17:15PM -0700, Grant Grundler wrote:
> Does it? are the 64-bit slots 3.3v only?

Yep.  Thought that was part of the PCI spec, though maybe I'm confused with
66MHz.

> > Has anyone before succeeded in accessing mmio space of PCI
> > card attached to the 32bit PCI bus of the C240 ?
> 
> SCSI is accessed that way. tulip driver can be tweaked to use MMIO
> if you don't have any 100BT GSC (card-mode Dino) cards.

umm.. I thought cardmode MMIO was working now on B/C/J class machines.
I think D/K/R still have resource management issues.

> > 00:01.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] (prog-if 00 [VGA])
> > 	Subsystem: Matrox Graphics, Inc.: Unknown device 2003
> > 	Flags: medium devsel, IRQ 97
> > 	Memory at f9000000 (32-bit, prefetchable) [size=16M]
> > 	Memory at f3ffc000 (32-bit, non-prefetchable) [size=16K]
> > 	Memory at f2800000 (32-bit, non-prefetchable) [size=8M]
> > 	Expansion ROM at f3f80000 [disabled] [size=64K]
> 
> Looks like PDC/IODC did it's thing.
> Look at matrox drivers to make sure they are calling
> "pci_device_enable()" and ioremap() before attempting to access
> the device.
> 
> Check /proc/iomem to see which PCI bus controller
> this is getting routed through and that the system
> has correctly identified the MMIO resources.
> 
> It's interesting one device has MMIO at both 0xf2800000
> and 0xf9000000 since it would imply one PCI controller is supposed
> to forward the entire range of addresses. But Dino only forwards
> (any number of) 8MB chunks between 0xf0800000 and 0xff800000 (except
> the first and last 8MB chunks).

I think this may well be the problem.  I bet Dino hasn't been programmed
to forward the 16MB range at f900'0000, and Linux has just found an
unused bit of address space and allocated it to the Matrox card.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] Matrox Millenium II in C240

[Grant Grundler]

On Sun, Jan 05, 2003 at 01:10:37PM +0000, Matthew Wilcox wrote:
> Yep.  Thought that was part of the PCI spec, though maybe I'm confused with
> 66MHz.

I think you are. 66Mhz operation requires 3.3v signaling.
AFAIK, both dino and cujo only run at 33Mhz *OR SLOWER* (eg 30Mhz).

However, HP did support only 3.3v for quite a while (at least on paper)
and I'm never quite sure which slots are 5v vs 3.3v.

> > SCSI is accessed that way. tulip driver can be tweaked to use MMIO
> > if you don't have any 100BT GSC (card-mode Dino) cards.
> 
> umm.. I thought cardmode MMIO was working now on B/C/J class machines.
> I think D/K/R still have resource management issues.

I don't recall all the details for card-mode.
My main point was the default is IO port space (CONFIG_TULIP_MMIO).

...
> > It's interesting one device has MMIO at both 0xf2800000
> > and 0xf9000000 since it would imply one PCI controller is supposed
> > to forward the entire range of addresses. But Dino only forwards
> > (any number of) 8MB chunks between 0xf0800000 and 0xff800000 (except
> > the first and last 8MB chunks).
> 
> I think this may well be the problem.  I bet Dino hasn't been programmed
> to forward the 16MB range at f900'0000, and Linux has just found an
> unused bit of address space and allocated it to the Matrox card.

Hmmm. /proc/iomem should tell us which ranges dino/cujo are forwarding.

But looking at dino.c, it's clear the code is not handling multiple
ranges correctly even if firmware did program it right.

        res = &dino_dev->hba.lmmio_space;

lmmio_space needs to be an array.
In HP speak, this is an "unsupported configuration". 

Elroy (lba_pci.c) suffers a similar problem with "directed ranges"
(code currently only handles "distributed ranges"). At some point
I'll get back to working on the lba code since it has a few other
minor oustanding issues as well.

grant

Re: [parisc-linux] Matrox Millenium II in C240

[Peter 'p2' De Schrijver]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

Hi,

> 
> Hmmm. /proc/iomem should tell us which ranges dino/cujo are forwarding.
> 

/proc/iomem in attachement.

> But looking at dino.c, it's clear the code is not handling multiple
> ranges correctly even if firmware did program it right.
> 
>         res = &dino_dev->hba.lmmio_space;
> 
> lmmio_space needs to be an array.
> In HP speak, this is an "unsupported configuration". 
> 
> Elroy (lba_pci.c) suffers a similar problem with "directed ranges"
> (code currently only handles "distributed ranges"). At some point
> I'll get back to working on the lba code since it has a few other
> minor oustanding issues as well.
> 

So, this basically means it won't work for now ?

Cheers,

Peter.

[-- Attachment #2: iomem-parisc --]
[-- Type: text/plain, Size: 941 bytes --]

00000000-1fffffff : System RAM
  00000000-000009ff : PDC data (Page Zero)
  00100000-002bffff : Kernel code
  002c0000-003b5c1b : Kernel data
f0190001-f0190001 : led_data
f1000000-f1ffffff : GSC Bus [10/]
  f1000000-f1000fff : Cujo
  f1800000-f1ffffff : Cujo LMMIO
f2000000-f5ffffff : GSC Bus [8/]
  f2000000-f2000fff : Dino
  f2003000-f2003fff : Serial RS232
  f2800000-f2ffffff : Dino LMMIO
  f3ffb000-f3ffb3ff : tulip
f6000000-f7ffffff : GSC Bus [10/]
f8000000-fff7ffff : GSC Bus [8/]
  ffd00000-ffdfffff : Lasi
    ffd00000-ffd00fff : Lasi
    ffd02000-ffd02fff : Parallel
    ffd04000-ffd04fff : Lasi Harmony
    ffd05000-ffd05fff : Serial RS232
    ffd06000-ffd06fff : Lasi SCSI
    ffd08000-ffd0800f : keyboard
    ffd08100-ffd0810f : psaux
fff80000-fffaffff : Central Bus
  fff88000-fff88fff : U2/Uturn
  fff8a000-fff8afff : U2/Uturn
  fffa0000-fffa0fff : CPU
fffb0000-fffdffff : Local Broadcast
fffe0000-ffffffff : Global Broadcast