linux-kernel.vger.kernel.org archive mirror
 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:58:33 +0200	[thread overview]
Message-ID: <4D9F2299.5030503@shipmail.org> (raw)
In-Reply-To: <4D9F224A.60902@shipmail.org>

On 04/08/2011 04:57 PM, Thomas Hellstrom wrote:
> 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
>
>
Oh, I forgot, I'll be on vacation for a week with limited possibilities 
to read mail, but after that I can prototype the ttm backend api changes 
if necessary.

/Thomas



  reply	other threads:[~2011-04-08 14:59 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
2011-04-08 14:58                           ` Thomas Hellstrom [this message]
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=4D9F2299.5030503@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;
as well as URLs for NNTP newsgroup(s).