On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: > > Von: "Michel Dänzer" <mic...@daenzer.net> > > On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: > > > > Von: "Michel Dänzer" <mic...@daenzer.net> > > > > On Mit, 2012-04-18 at 17:49 +0200, Gerhard Pircher wrote: > > > > > > > > > > That may be a stupid question, but is it allowed (for a DRM client > > > > > or whatever does the mapping) to change the content of a page > > > > > mapped into the AGP GART or is it necessary to explicitly unmap > > > > > the page, change its content and map it again? > > > > > > > > The former. > > > I know that the uninorth AGPGART driver does a cache flushing for > > > newly mapped pages, but is there any code in the driver that handles > > > the former case (or isn't this necessary on PPC Macs)? > > > > If by 'former case' you mean userspace modifying memory mapped into the > > AGP GART, then no, this generally doesn't require special treatment on > > PowerMacs. (Ignoring the potential issue mentioned by Ben in this > > thread) > I guess you refer to the ordering issue here.
Yeah. > The "former case" is an explanation, why I see data corruption with my > AGPGART driver (more or less a copy of the uninorth driver) on my > non-coherent platform. There are no cache flushes done for writes to > already mapped pages. As I said, the radeon driver always maps AGP memory uncacheable for the CPU, so no such CPU cache flushes should be necessary. > I tested this with radeon.test=1, but I'm not even sure if this code > changes already mapped pages [...] It does. radeon_bo_pin(..., RADEON_GEM_DOMAIN_GTT, ...) binds the buffer memory into the AGP GART, and the test only maps it to the CPU after that. I take it the test fails for you? How exactly? -- 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