public inbox for dri-devel@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Thomas Hellstrom <thomas@shipmail.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jerome Glisse <j.glisse@gmail.com>,
	linux-kernel@vger.kernel.org, Dave Airlie <airlied@redhat.com>,
	dri-devel@lists.freedesktop.org,
	Alex Deucher <alexdeucher@gmail.com>,
	Konrad Rzeszutek Wilk <konrad@kernel.org>
Subject: Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
Date: Fri, 08 Apr 2011 16:57:14 +0200	[thread overview]
Message-ID: <4D9F224A.60902@shipmail.org> (raw)
In-Reply-To: <20110331154954.GA7695@dumpdata.com>

Konrad,

Sorry for waiting so long to answer. Workload is quite heavy ATM.
Please see inline.


On 03/31/2011 05:49 PM, Konrad Rzeszutek Wilk wrote:
>>> I can start this next week if you guys are comfortable with this idea.
>>>
>>>
>>>        
>> Konrad,
>>
>> 1) A couple of questions first. Where are the memory pools going to
>> end up in this design. Could you draft an API? How is page
>> accounting going to be taken care of? How do we differentiate
>> between running on bare metal and running on a hypervisor?
>>      
> My thought was that the memory pool's wouldn't be affected. Instead
> of all of the calls to alloc_page/__free_page (and dma_alloc_coherent/
> dma_free_coherent) would go through this API calls.
>
> What I thought off are three phases:
>
>   1). Get in the patch that passed in 'struct dev' to the dma_alloc_coherent
>    for 2.6.39 so that PowerPC folks can use the it with radeon cards. My
>    understanding is that the work you plan on to isn't going in 2.6.39
>    but rather in 2.6.40 - and if get my stuff ready (the other phases)
>    we can work out the kinks together. This way also the 'struct dev'
>    is passed in the TTM layer.
>    

I'm not happy with this solution. If something goes in, it should be 
complete, otherwise future work need to worry about not breaking 
something that's already broken. Also it adds things to TTM api's that 
are not really necessary.


I'd like to see a solution that  encapsulates all device-dependent stuff 
(including the dma adresses) in the ttm backend, so the TTM backend code 
is the only code that needs to worry about device dependent stuff. Core 
ttm should only need to worry about whether pages can be transferrable 
to other devices, and whether pages can be inserted into the page cache.

This change should be pretty straightforward. We move the ttm::pages 
array into the backend, and add ttm backend functions to allocate pages 
and to free pages. The backend is then completely free to keep track of 
page types and dma addresses completely hidden from core ttm, and we 
don't need to shuffle those around. This opens up both for completely 
device-private coherent memory and for "dummy device" coherent memory.

In the future, when TTM needs to move a ttm to another device, or when 
it needs to insert pages into the page cache, pages that are device 
specific will be copied and then freed. "Dummy device" pages can be 
transferred to other devices, but not inserted into the page cache.

/Thomas

  reply	other threads:[~2011-04-08 14:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-08 15:39 [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls Konrad Rzeszutek Wilk
2011-03-08 15:39 ` [PATCH 1/2] ttm: Include the 'struct dev' when using the DMA API Konrad Rzeszutek Wilk
2011-03-08 15:39 ` [PATCH 2/2] ttm: Pass in 'struct device' to TTM so it can do DMA API on behalf of device Konrad Rzeszutek Wilk
2011-03-08 20:52 ` [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls Thomas Hellstrom
2011-03-09  0:47   ` Konrad Rzeszutek Wilk
2011-03-22 14:31   ` Konrad Rzeszutek Wilk
2011-03-23  8:13     ` Thomas Hellstrom
2011-03-23 12:51       ` Konrad Rzeszutek Wilk
2011-03-23 13:17         ` Thomas Hellstrom
2011-03-23 14:52           ` Konrad Rzeszutek Wilk
2011-03-24  7:52             ` Thomas Hellstrom
2011-03-24 14:25               ` Konrad Rzeszutek Wilk
2011-03-24 16:06                 ` Jerome Glisse
2011-03-24 16:21                   ` Konrad Rzeszutek Wilk
2011-03-25 20:00                     ` Thomas Hellstrom
2011-03-31 15:49                       ` Konrad Rzeszutek Wilk
2011-04-08 14:57                         ` Thomas Hellstrom [this message]
2011-04-08 14:58                           ` Thomas Hellstrom
2011-04-08 15:12                           ` Konrad Rzeszutek Wilk
2011-04-08 15:29                             ` Thomas Hellstrom
2011-03-23 16:19         ` Alex Deucher
2011-03-22 17:39   ` Paul Mundt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D9F224A.60902@shipmail.org \
    --to=thomas@shipmail.org \
    --cc=airlied@redhat.com \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    --cc=konrad.wilk@oracle.com \
    --cc=konrad@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox