On Mon, 2012-04-23 at 18:45 +0200, Gerhard Pircher wrote:
> > Von: "Michel Dänzer" <mic...@daenzer.net>
> > On Fre, 2012-04-20 at 18:14 +0200, Gerhard Pircher wrote:
> > > > Von: "Michel Dänzer" <mic...@daenzer.net>
> > > > On Fre, 2012-04-20 at 13:15 +0200, Gerhard Pircher wrote:
> > > > >
> > > > > What I didn't understand yet is how this uncacheable memory is
> > > > > allocated (well, I never took the time to look at this again). The
> > > > > functions in ttm_page_alloc.c seem to allocate normal cacheable
> > > > > memory and try to set the page flags with set_pages_array_uc(),
> > > > > which is more or less a no-op on powerpc. ttm_page_alloc_dma.c on
> > > > > the other side is only used with SWIOTLB!?
> > > > [...]
> > > > > Could it be that the memory is finally mapped uncacheable by
> > > > radeon_bo_kmap()/
> > > > > ttm_bo_kmap()/..some other TTM functions../vmap()?
> > > >
> > > > Yeah, AFAICT, basically ttm_io_prot() defines the mapping
> > > > attributes, and vmap() is used to enforce them for kernel mappings.
> > > Okay, that sounds like the approach used by arch/powerpc/mm/dma-
> > > noncoherent.c in my ("green") ears. What about the PCIGART mode?
> > > Is the driver free to use cached memory in this mode?
> >
> > Yes, it assumes PCI(e) GART to be CPU cache coherent.
> Okay. I guess it should be possible to modify it so that it makes use
> of uncacheable memory - just for testing!?
Sure. Just set man->available_caching and man->default_caching as in the
AGP case in radeon_init_mem_type().
> PCIGART was working "somehow" on my platform up to the ~2.6.39 kernel,
> i.e. I could login to GNOME and open a program until the machine
> locked-up. :-)
But it's worse with newer kernels?
> BTW: I see that the uninorth driver defines needs_scratch_page. What
> is this actually good for?
It causes the code in drivers/char/agp/backend.c to allocate a scratch
page (bridge->scratch_page) which the driver can use for unused GART
entries.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
