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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
