> > Add the ATI Mach64 LT Pro on the Lombard Powerbooks (and some other
> > PowerMac HW IIRC) to that list of borken cards. In this case, we have a
> > MMIO region overlap the video mem region.
>
> Can you send me the vendor ID, device ID, which region it is and what
> is the correct size, please?
lspci --vv says:
00:11.0 VGA compatible controller: ATI Technologies Inc: Unknown device 4c49 (rev dc)
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: 8 min, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 24
Region 0: Memory at 81000000 (32-bit, non-prefetchable)
Region 1: I/O ports at 0c00 [disabled]
Region 2: Memory at 81fff000 (32-bit, non-prefetchable)
Capabilities: [5c] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
The problem is with the region overlap (region 2 MMIO at 81fff000 size
0x1000 overlaps memory region 0 81000000 size 0x1000000) not with the size
per se.
The workaround would be to either reduce the vram size to remove the
overlap (we've reduced the size used by fbdev anyway when we first
noticed the overlap by fbmem clear trashing the registers), or remap MMIO
someplace else (that's what I do now on 2.2.15pre9 but it's a sick hack).
81000000 is the big endian vram aperture, the little endian aperture is
at 80000000 and the MMIO region could be safely remapped to 80fff000 - the
registers are decoded there by the card even though there's no PCI mapping
set up, that might be yet another ATI quirk. I don't think it's safe to
assume no other device may claim that area, or is it?
Anyway on PPC any device using 80fff000 would trample over the
> > How do the 2.2.x kernels handle the bogus S3 sizes?
>
> They don't, but 2.4.x kernels do.
In the fbdev code, or in the PCI resource allocation?
> For XFree, the best solution is probably to choose according to kernel
> version:
...
> 2.2.x Use /proc/bus/pci to access PCI registers; do the work-arounds
That probably is what the current XFree attempts, the workaround is to
remove the offending region 0 mapping :-) I'm not sure if the X server
uses the /proc interface or scans the bus itself.
> > 2.2 Use /proc/bus/pci to access PCI registers, leave all work-arounds
> to the kernel.
If there's no resource conflicts, X won't attempt any workarounds. Hope
someone at xfree is listening.
Michael
-
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/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:26 EST