PowerPC radeon KMS - is it possible?

[Michel Dänzer]

On Don, 2012-04-19 at 13:48 +0200, Gerhard Pircher wrote: 
> > Von: "Michel Dänzer" <michel at daenzer.net>
> > On Mit, 2012-04-18 at 18:23 +0200, Gerhard Pircher wrote: 
> > > > Von: "Michel Dänzer" <michel at 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