PowerPC radeon KMS - is it possible?

On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote: 
> On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: 
> > 
> > I suspect there's a fundamental design issue with apple bridge in that
> > the CPU to memory path isn't coherent at all with the GPU to memory path
> > ie. even vs. cache flush instructions (ie buffers in the memory
> > controllers can still be out of sync).
> > 
> > Darwin does some gross hacks to work around that, some of them visible
> > in the AGP drivers, some burried in the Apple driver, I don't know for
> > sure. It's possible that they end up mapping all AGP memory as cache
> > inhibited, but we can't do that because of our linear mapping.
> 
> We are doing that though...

This reminded me, I've been running with the patch below, but I'm not
sure it makes any difference. Maybe Andreas or Jordan can try it.

On Wed, 2012-04-18 at 12:44 +0200, Michel Dänzer wrote:
> On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote: 
> > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: 
> > > 
> > > I suspect there's a fundamental design issue with apple bridge in that
> > > the CPU to memory path isn't coherent at all with the GPU to memory path
> > > ie. even vs. cache flush instructions (ie buffers in the memory
> > > controllers can still be out of sync).
> > > 
> > > Darwin does some gross hacks to work around that, some of them visible
> > > in the AGP drivers, some burried in the Apple driver, I don't know for
> > > sure. It's possible that they end up mapping all AGP memory as cache
> > > inhibited, but we can't do that because of our linear mapping.
> > 
> > We are doing that though...
> 
> This reminded me, I've been running with the patch below, but I'm not
> sure it makes any difference. Maybe Andreas or Jordan can try it.

It certainly is something we need to do, provided we also know there
will be no subsequent access to that page via a cachable mapping until
it's removed from AGP.

Cheers,
Ben.
> 
> diff --git a/arch/powerpc/include/asm/agp.h b/arch/powerpc/include/asm/agp.h
> index 416e12c..eb34fa5 100644
> --- a/arch/powerpc/include/asm/agp.h
> +++ b/arch/powerpc/include/asm/agp.h
> @@ -2,9 +2,12 @@
>  #define _ASM_POWERPC_AGP_H
>  #ifdef __KERNEL__
>  
> +#include <asm/cacheflush.h>
>  #include <asm/io.h>
>  
> -#define map_page_into_agp(page)
> +#define map_page_into_agp(page)	\
> +	flush_dcache_range((unsigned long)page_address(page), \
> +			   (unsigned long)page_address(page) + PAGE_SIZE)
>  #define unmap_page_from_agp(page)
>  #define flush_agp_cache() mb()
>  
> 
>

Michel Dänzer <michel@daenzer.net> writes:

> -#define map_page_into_agp(page)
> +#define map_page_into_agp(page)	\
> +	flush_dcache_range((unsigned long)page_address(page), \
> +			   (unsigned long)page_address(page) + PAGE_SIZE)

That didn't help.

Andreas.

On Mit, 2012-04-18 at 21:19 +1000, Benjamin Herrenschmidt wrote: 
> On Wed, 2012-04-18 at 12:44 +0200, Michel Dänzer wrote:
> > On Mit, 2012-04-18 at 12:34 +0200, Michel Dänzer wrote: 
> > > On Mit, 2012-04-18 at 20:20 +1000, Benjamin Herrenschmidt wrote: 
> > > > 
> > > > I suspect there's a fundamental design issue with apple bridge in that
> > > > the CPU to memory path isn't coherent at all with the GPU to memory path
> > > > ie. even vs. cache flush instructions (ie buffers in the memory
> > > > controllers can still be out of sync).
> > > > 
> > > > Darwin does some gross hacks to work around that, some of them visible
> > > > in the AGP drivers, some burried in the Apple driver, I don't know for
> > > > sure. It's possible that they end up mapping all AGP memory as cache
> > > > inhibited, but we can't do that because of our linear mapping.
> > > 
> > > We are doing that though...
> > 
> > This reminded me, I've been running with the patch below, but I'm not
> > sure it makes any difference. Maybe Andreas or Jordan can try it.
> 
> It certainly is something we need to do, provided we also know there
> will be no subsequent access to that page via a cachable mapping until
> it's removed from AGP.

TTM should take care of that.