[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 th

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 apert

[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 with

[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 > mig

[RFC] Future TTM DMA direction

2012-01-10 Thread Konrad Rzeszutek Wilk
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 tran

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 with

Re: [RFC] Future TTM DMA direction

2012-01-10 Thread Konrad Rzeszutek Wilk
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 tran

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 > mig

[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 synch

[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 tran

[RFC] Future TTM DMA direction

2012-01-09 Thread Thomas Hellstrom
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 translation table was a simple one-step operation, and we needed to worry abou

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. The

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 tran

[RFC] Future TTM DMA direction

2012-01-09 Thread Thomas Hellstrom
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 translation table was a simple one-step operation, and we needed to worry abo