On Sat, 4 Jun 2005, Nicolai Haehnle wrote:
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.
My understanding is that AGP only does transfers system RAM -> video RAM
and all transfers in the opposite direction have to use plain PCI
transfers at least as far as the bus is concerned.
It could be that AGP GART can still decode addresses for writes to system
memory, I guess this depends on a particular architecture.
One of the reasons to look forward to PCI Express is that it is
bi-directional, unlike AGP.
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.
It could be anything. However, the recommended way to program the memory
controller is to set the BASE of video memory to its physical PCI address
and to put AGP memory where it is mirrored by the AGP GART, as,
presumably, this does not overlap with system RAM or any of other
sensitive areas.
My understanding is that dev->agp->base is the address where the AGP GART
mirrors the pieces of system RAM comprising AGP space.
Of course, these are somewhat bogus on 64 bit system.
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.
They are always programmed in rather large memory units.
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?
Eventually the DRM driver was able to reprogram memory controller on
request. So by default it used the usual setup (DISPLAY_BASE at 0) and it
switched to reasonable setup when requested.
The reasons for such behaviour are:
* older mesa drivers did not know about reprogramming (and drm is
separate from Mesa)
* framebuffer does not know about reprogramming
* *all* video BIOSes that I have seen always set DISPLAY_BASE to 0.
so this is a "safe" mode (which completely precludes DMA from/to the
first N megabytes of system memory where N is the size of video
aperture).
best
Vladimir Dergachev
cu,
Nicolai
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
