Re: radeon, apertures & memory mapping

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2005-03-12 at 22:55 -0500, Vladimir Dergachev wrote:
> Hi Ben,
> 
>    Hopefully simple question:
> 
>    If you were able to change configured aperture size - would you like to ? 
> I could possibly imaging situation where this is used to regular access to 
> the video memory, but you are the driver author..

You cannot change them. They are strapped on the mother board or in the
BIOS ROM. If I was able, I would probably set both apertures to cover
the entire VRAM, though ATI hints that you may have more flexibility
with tiled surfaces if using them split ...

>                       thank you !
> 
>                             Vladimir Dergachev
> 
> 
> On Sun, 13 Mar 2005, Benjamin Herrenschmidt wrote:
> 
> > Hi !
> >
> > I'm currently rewriting radeonfb to implement support for dual head, and
> > ultimately, to make it more friendly to be hooked on DRM for mesa-solo
> > style setups.
> >
> > I have some issues however related to the way memory is mapped and
> > dealing with apertures. Here is the story, suggestions welcome:
> >
> > The radeon card exposes to the system 2 separate apertures. That is, the
> > PCI region is actually cut by the hardware in two halves, each of them
> > beeing an "aperture". Each aperture can have different configuration for
> > the endian swappers (and possibly the surface tiling registers).
> >
> > I can configure the apertures to both map to the same bit of video
> > memory (both covering the framebuffer from 0), or to be "split", that is
> > aperture 0 covering the framebuffer from 0 to CONFIG_APER_SIZE (size of
> > an aperture, that is half of the PCI BAR allocation), and aperture 1
> > covering the framebuffer from CONFIG_APER_SIZE to CONFIG_APER_SIZE*2.
> >
> > However, I can't change anything to CONFIG_APER_SIZE itself, it's
> > decided by straps, either HW or in the ROM. So we end up with different
> > setups depending on how the BIOS has configured things. I know that
> > Apple chips are usually wired so that CONFIG_APER_SIZE is half the video
> > memory, so if I use the first mode, I can only access half of the video
> > RAM from PCI, if I use the second, each aperture maps a different half
> > of video memory with possibly different endian swapping.
> >
> > But I think the setups in real life are more diverse and some BIOSes
> > will have CONFIG_APER_SIZE at least as big as the entire video memory,
> > thus forcing me to use the "overlapped" setup. In fact, CONFIG_APER_SIZE
> > may even be smaller than half of the vram and thus limiting the CPU to
> > part of the VRAM anyway.
> >
> > I have toyed with all sort of setups, and I have +/- decided to not
> > bother, and always do this, please tell me what you think:
> >
> > Always setup HOST_PATH_CNTL.HDP_APER_CNTL to 0. That is, both apertures
> > are always overlapping. On Macs, or other machines that strap
> > CONFIG_APER_SIZE to half of VRAM, that means only half of vram can be
> > directly accessed by the CPU. I think this is fine because of these:
> >
> > - We only really need to bother about CPU access for the framebuffer
> > itself (and possibly the cursor). That is normal non-accelerated fbdev
> > operations an mmap'ing of the framebuffer in user space. This is not
> > really a problem if that is limited to some part of vram. It puts a
> > small constraint on the allocation of video memory: the framebuffer has
> > to be near the beginning. But my opinion is that a mode switch will
> > pretty much always invalidate everything that is cached in video memory,
> > so the whole allocation can be re-done at that point. Things like
> > texture uploads etc... should use the CP engine and DMA (from either
> > system or AGP memory).
> >
> > - It's actually making things easier for me since I can allocate both
> > framebuffers next to each other, and probably easier for the future
> > video memory allocator since it then gets a larger contiguous chunk of
> > memory to deal with.
> >
> > - It's also easier because If I wanted to take advantage of the "split"
> > setting, I would still need some fallback mecanism for cards who have
> > the aperture size set to all of vram size.
> >
> > Note that I also noticed rather inconsistent usage of memory size vs
> > aperture size in DRI/X. I'm not sure X actually deals with the 2
> > scenarios here (X always only uses aperture 0 for both heads and changes
> > the swapper control on each access).
> >
> > The only drawback is that on the kernel side, for the console, I end up
> > with the ioremap for the second crtc beeing twice as big as necessary
> > since I can't "dynamically" ioremap/iounmap on mode switches (that would
> > be guaranteed to fail after the system has been running for a while). It
> > would be nice if I could play mapping tricks by doing something like
> > allocating the 2 bits of virtual space at boot (get_vm_area), and just
> > remap the pages in them ((un)map_vm_area), but that wouldn't work with
> > architectures like MIPS who have limitations on where in virtual space
> > non-cacheable things are.
> >
> > I could maybe use a single ioremap though, that is use a single
> > aperture, and then switch the swapper on accesses. Though I should also
> > be careful not to end up conflicting with a userland process relying on
> > having the 2 separate aperture swappers stable for the mode on the 2
> > separate framebuffer mappings... Like X would use fb0 while console
> > would use fb1 with a different swapper setting. That would blow up for
> > sure unless fbcon arbitrates accesses with X, which I don't see
> > happening right away. I suppose we'll have to consider both heads linked
> > as far as console ownership is concerned, at least for now, until the
> > kernel console subsystem is overhauled significantly.
> >
> > Ben.
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > --
> > _______________________________________________
> > Dri-devel mailing list
> > Dri-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>