According to the register ref. (p.4-26), "GB" means "BGA package, AGP:
both 1x and 2x)." I have an LT Pro, which has "LB" in the device ID.
This is in the CFG_CHIP_TYPE in CONFIG_CHIP_ID. There's also a class,
foundry ID, and major/minor numbers in CONFIG_CHIP_ID.
At any rate, I just looked at the dri trunk and it looks like there was a
change here. The 'else' (mentioned in my previous mail) is now:
else if (Chip < ATI_CHIP_264VT4)
I checked, and all other references to these regs in the code work the
same way, so if the code is correct it seems that:
BUS_FIFO_ERR_INT_EN, BUS_FIFO_ERR_INT are used for chips < ATI_CHIP_264VT=
BUS_HOST_ERR_INT_EN, BUS_HOST_ERR_INT are used for chips < ATI_CHIP_264VT=
(Note: ATI_CHIP_264VTB < ATI_CHIP_264VT4)
The full list of chips is in the 'ATIChipType' enum in 'atichip.h', if yo=
want to see which chips this encompasses. So perhaps it's the programmer'=
guide that is out of date? (again assuming the code is correct). Anyway,
I've tried removing the part of the engine reset that sets 0x00a00000 in
BUS_CNTL and it doesn't seem to make a difference in the dma test.
On Sat, 22 Sep 2001, Carl Busjahn wrote:
> Hi all,
> I've looked at the documentation, and it's odd, it seems like nobody is
> mentioning the Mach64 GB. It might be this is simply named wrong in my
> bios, and it seems to run the same as other cards.
> Here's my PCI entry: pci bus 0x1 cardnum 0x00 function 0x0000: vendor
> 0x1002 device 0x4742 ATI Mach64 GB
> This is a All in Wonder model but this may all be irrelevant.
> Carl Busjahn
> Manuel Teira wrote:
> >El Dom 23 Sep 2001 00:28, escribiste:
> >>On Sat, 22 Sep 2001, Manuel Teira wrote:
> >>>El S=E1b 22 Sep 2001 19:08, escribiste:
> >>>And now, the results:
> >>>1.-When the new bm_dma_test is called from the dma_init it fails as =
> >>>Then, if I try to run the 'gears' demo, it hangs the machine.
> >>>2.-When the bm_dma_test is called from the dma_cleanout, the gears d=
> >>>runs, showing only garbage on the screen. So, it seems that we shoul=
> >>>blame the DMA test for the locks.
> >>>3.-Finally, and in the same environment than (2), I've tried to run =
> >>>isosurf demo. Against all the bets, it worked. Well, it's able to re=
> >>>the figures as good as in software mode (with the software GL librar=
> >>>but with some problems:
> >>> - There's garbage in the background of the window.
> >>> - The window is not cleaned for each frame, so, all the shapes are =
> >>>on the screen after some key strokes.
> >>I've tried out the changes and I got the same results with glxheads. =
> >>garbage in the background for me is part of the KDE splash screen and=
> >>of my desktop background. Again, the shapes are drawn and rotated, b=
> >>the window is not cleared for each frame.
> >Exactly the same I'm experimenting (part of the KDE splash screen).
> >>I'm a bit confused about something in the engine reset code. The sam=
> >>engine reset code in the programmer's guide mentions setting
> >>BUS_FIFO_ERR_ACK and BUS_HOST_ERR_ACK in BUS_CNTL (0x00a00000), but t=
> >>register guide shows these bits as BUS_MSTR_RD_LINE and LAT16X
> >>respectively, with LAT16X being read-only. The 2D driver (atiregs.h)=
> >>these defines:
> >>#define BUS_FIFO_ERR_INT_EN 0x00100000ul
> >>#define BUS_MSTR_RD_MULT 0x00100000ul /* VTB/GTB/LT=
> >>#define BUS_FIFO_ERR_INT 0x00200000ul
> >>#define BUS_MSTR_RD_LINE 0x00200000ul /* VTB/GTB/LT=
> >>#define BUS_HOST_ERR_INT_EN 0x00400000ul
> >>#define BUS_SUSPEND 0x00400000ul /* GTPro */
> >>#define BUS_HOST_ERR_INT 0x00800000ul
> >>#define BUS_LAT16X 0x00800000ul /* GTPro */
> >Yes, it's really weird. Comparing the Programmers Guide and the Regist=
> >Reference guide, I see the following:
> >and after reading the Register Reference Guide,
> >0x00a00000=3DBUS_MSTR_RD_LINE | BUS_LAT16X
> >while in the Programmers Guide, they are talking about setting:
> >BUS_FIFO_ERR_ACK@... and BUS_HOST_ERR_ACK@....
> >It seems that the register bits have different meanings regarding the =
> >Model, as you can see in the define comments. Anyway, it's not clear f=
> >- GTPro. I assume, they're talking about a GT Model (Rage I, RageII, I=
> >IIC, Rage PRO). If we trust the Mach64 Programmers Guide, these models=
> >3D acceleration (3D RAGE)
> >- VTB/GTB/LT. This is strange. Assuming they're talking about VT and=
> >models (but the GT model is the same as the GTPro). And what about the=
> >Perhaps a RAGE LT-Pro (actually a LB/GM model).
> >>..and there is code like this in atiprobe.c:
> >>/* Make sure any Mach64 is not in some weird state */
> >> bus_cntl =3D inr(BUS_CNTL);
> >> if (Chip < ATI_CHIP_264VTB)
> >> outr(BUS_CNTL,
> >> (bus_cntl & ~(BUS_HOST_ERR_INT_EN | BUS_FIFO_ERR_INT_EN)=
> >> (BUS_HOST_ERR_INT | BUS_FIFO_ERR_INT));
> >> else
> >> outr(BUS_CNTL, (bus_cntl & ~BUS_HOST_ERR_INT_EN) |
> >After reading this, I suppose that with GTPro they're talking about an=
> >model than the VT, that is, a Mach64GX Family model (if Chip <
> >ATI_CHIP_264VTB) .
> >And there's something wrong, assuming that the 'else' is for the GTPro=
> >they are trying to set the BUS_LAT16X =3D=3D BUS_HOST_ERR_INT, a read =
only bit in
> >the BUS_CNTL register.
> >Perhaps the Register Reference is not updated or have some bugs. I don=
> >know. Could be a good idea to take a look at the XFree 3.x version to =
> >is it setting up the card, allowing Utah-GLX to work.
> >>Does anyone know what's going on here?
> >Dri-devel mailing list
> Dri-devel mailing list