Re: [RFC] Future TTM DMA direction

2012-01-25 Thread Thomas Hellstrom
OK, revisiting this again, please see inline below, On 01/10/2012 06:46 PM, Jerome Glisse wrote: On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote: On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: Hi! When TTM was originally written, it was assumed that GPU

Re: [RFC] Future TTM DMA direction

2012-01-10 Thread Daniel Vetter
Hi Thomas, On Mon, Jan 09, 2012 at 12:01:28PM +0100, Thomas Hellstrom wrote: Thanks for your input. I think this is mostly orthogonal to dma_buf, and really a way to adapt TTM to be DMA-api aware. That's currently done within the TTM backends. CMA was mearly included as an example that might

Re: [RFC] Future TTM DMA direction

2012-01-10 Thread Jerome Glisse
On Mon, Jan 09, 2012 at 11:11:06AM +0100, Daniel Vetter wrote: On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: Hi! When TTM was originally written, it was assumed that GPU apertures could address pages directly, and that the CPU could access those pages without

Re: [RFC] Future TTM DMA direction

2012-01-09 Thread Daniel Vetter
On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: Hi! When TTM was originally written, it was assumed that GPU apertures could address pages directly, and that the CPU could access those pages without explicit synchronization. The process of binding a page to a GPU

Re: [RFC] Future TTM DMA direction

2012-01-09 Thread Thomas Hellstrom
On 01/09/2012 11:11 AM, Daniel Vetter wrote: On Mon, Jan 09, 2012 at 10:37:28AM +0100, Thomas Hellstrom wrote: Hi! When TTM was originally written, it was assumed that GPU apertures could address pages directly, and that the CPU could access those pages without explicit synchronization.