On Saturday 04 June 2005 15:01, Vladimir Dergachev wrote: > I just wanted to contribute the following piece of information that might > help with R300 lockups. I do not know whether it applies or not in this > case, but just something to be aware about. > > Radeon has a memory controller which translates internal address space of > the chip into accesses of different memory - framebuffer, agp, system ram. > > So from the point of view of Radeon chip there is a single flat 32 bit > address space which contains everything. This is nice because you can > simply set texture offset to a particular number and the chip will pull it > from appropriate memory - be it video memory, agp or system ram. (albeit > system ram access is done via PCI, not AGP commands and thus is much > slower). > > It used to be that Radeon DRM driver had two modes for usage of scratch > registers - a mode when it polled Radeon chip directly and a mode when the > contents of the registers were "mirrored" in the system RAM. The driver > would try mirroring during startup and if it fails uses polling method. > > The mirroring works as follows: each time scratch register is written the > radeon controller uses PCI to write their value to a specific location in > system memory.
Are you sure it uses PCI? I'm assuming that the destination address for scratch writeback is controlled by the RADEON_SCRATCH_ADDR register. This register is programmed to a value that falls within the AGP area (as defined by RADEON_MC_AGP_LOCATION) if I understand the code correctly. > This, of course, would not work if the memory controller is misprogrammed > - which was the cause of failures. > > Which way can memory controller be misprogrammed ? The part that concerns > us are positions of Video RAM, AGP and System Ram in Radeon address space. > (these are specified by RADEON_MC_AGP_LOCATION, RADEON_MC_FB_LOCATION). What's the meaning of RADEON_AGP_BASE, by the way? It is programmed to dev->agp->base, which is AFAIK an address from the kernel's address space. That doesn't make much sense to me. > The memory controller *always* assumes that system RAM (accessible via > PCI) starts at 0. So, if RADEON_MC_FB_LOCATION, for example, is set to 0 > then we have video RAM overlapping system RAM. However, the size of video > RAM is usually much smaller than the size of system RAM. So if the scratch > registers image in system memory had small physical address you might get > a lockup and if it was high you don't. You also would be more likely to get > a lockup when load on system memory increased. Hmm. The way RADEON_MC_(FB|AGP)_LOCATION are programmed, it seems to be like they actually consist of two 16 bit fields, one indicating the start of the FB/AGP area, the other indicating the end. Do you know what happens when the programmed size of the FB area is larger than the physical size of video RAM? What happens when the programmed size of the AGP area is larger than the size of the AGP aperture? > This problem has been fixed for plain Radeon drivers, but it could be > that something similar is manifesting again on R300.. How did that fix work? cu, Nicolai
pgpNmZIBoEWgy.pgp
Description: PGP signature
