All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Hellstrom <thomas@shipmail.org>
Cc: linux-kernel@vger.kernel.org, Dave Airlie <airlied@redhat.com>,
	dri-devel@lists.freedesktop.org,
	Alex Deucher <alexdeucher@gmail.com>,
	Jerome Glisse <j.glisse@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: Tue, 22 Mar 2011 10:31:37 -0400	[thread overview]
Message-ID: <20110322143137.GA25113@dumpdata.com> (raw)
In-Reply-To: <4D769726.2030307@shipmail.org>

On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
> 
> Is passing a struct device to the DMA api really *strictly* necessary?

Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
this.
> 
> I'd like to avoid that at all cost, since we don't want pages that
> are backing buffer objects
> (coherent pages) to be associated with a specific device.
> 
> The reason for this is that we probably soon will want to move ttm
> buffer objects between devices, and that should ideally be a simple
> operation: If the memory type the buffer object currently resides in
> is not shared between two devices, then move it out to system memory
> and change its struct bo_device pointer.

I was thinking about this a bit after I found that the PowerPC requires
the 'struct dev'. But I got a question first, what do you with pages
that were allocated to a device that can do 64-bit DMA and then
move it to a device than can 32-bit DMA? Obviously the 32-bit card would
set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
process then? Allocate a new page from the 32-bit device and then copy over the
page from the 64-bit TTM and put the 64-bit TTM page?

> 
> If pages are associated with a specific device, this will become
> much harder. Basically we need to change backing pages and copy all

what if you track it. Right now you need to track two things:
'struct page *' and 'dma_addr_t'. What if you had also to track
'struct dev *' with the page in question? Something like this:

diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index efed082..1986761 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -158,9 +158,14 @@ enum ttm_caching_state {
  * memory.
  */
 
+struct ttm_tt_page {
+	struct page *page;
+	dma_addr_t *dma_addr;
+	struct dev *dev;
+}
 struct ttm_tt {
 	struct page *dummy_read_page;
-	struct page **pages;
+	struct ttm_tt_page **pages;
 	long first_himem_page;
 	long last_lomem_page;
 	uint32_t page_flags;
@@ -176,7 +181,6 @@ struct ttm_tt {
 		tt_unbound,
 		tt_unpopulated,
 	} state;
-	dma_addr_t *dma_address;
 };
 
 #define TTM_MEMTYPE_FLAG_FIXED         (1 << 0)	/* Fixed (on-card) PCI memory */

could do it. And when you pass the 'page' to the other TTM, it is just the matter
of passing in the 'struct ttm_tt_page' now.

WARNING: multiple messages have this Message-ID (diff)
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Thomas Hellstrom <thomas@shipmail.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Konrad Rzeszutek Wilk <konrad@kernel.org>,
	Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH] cleanup: Add 'struct dev' in the TTM layer to be passed in for DMA API calls.
Date: Tue, 22 Mar 2011 10:31:37 -0400	[thread overview]
Message-ID: <20110322143137.GA25113@dumpdata.com> (raw)
In-Reply-To: <4D769726.2030307@shipmail.org>

On Tue, Mar 08, 2011 at 09:52:54PM +0100, Thomas Hellstrom wrote:
> Hi, Konrad,
> 
> Is passing a struct device to the DMA api really *strictly* necessary?

Soo.. it seems it is on PowerPC, which I sadly didn't check for, does require
this.
> 
> I'd like to avoid that at all cost, since we don't want pages that
> are backing buffer objects
> (coherent pages) to be associated with a specific device.
> 
> The reason for this is that we probably soon will want to move ttm
> buffer objects between devices, and that should ideally be a simple
> operation: If the memory type the buffer object currently resides in
> is not shared between two devices, then move it out to system memory
> and change its struct bo_device pointer.

I was thinking about this a bit after I found that the PowerPC requires
the 'struct dev'. But I got a question first, what do you with pages
that were allocated to a device that can do 64-bit DMA and then
move it to a device than can 32-bit DMA? Obviously the 32-bit card would
set the TTM_PAGE_FLAG_DMA32 flag, but the 64-bit would not. What is the
process then? Allocate a new page from the 32-bit device and then copy over the
page from the 64-bit TTM and put the 64-bit TTM page?

> 
> If pages are associated with a specific device, this will become
> much harder. Basically we need to change backing pages and copy all

what if you track it. Right now you need to track two things:
'struct page *' and 'dma_addr_t'. What if you had also to track
'struct dev *' with the page in question? Something like this:

diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index efed082..1986761 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -158,9 +158,14 @@ enum ttm_caching_state {
  * memory.
  */
 
+struct ttm_tt_page {
+	struct page *page;
+	dma_addr_t *dma_addr;
+	struct dev *dev;
+}
 struct ttm_tt {
 	struct page *dummy_read_page;
-	struct page **pages;
+	struct ttm_tt_page **pages;
 	long first_himem_page;
 	long last_lomem_page;
 	uint32_t page_flags;
@@ -176,7 +181,6 @@ struct ttm_tt {
 		tt_unbound,
 		tt_unpopulated,
 	} state;
-	dma_addr_t *dma_address;
 };
 
 #define TTM_MEMTYPE_FLAG_FIXED         (1 << 0)	/* Fixed (on-card) PCI memory */

could do it. And when you pass the 'page' to the other TTM, it is just the matter
of passing in the 'struct ttm_tt_page' now.

  parent reply	other threads:[~2011-03-22 14:31 UTC|newest]

Thread overview: 34+ 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 ` 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   ` 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 15:39   ` 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-09  0:47     ` Konrad Rzeszutek Wilk
2011-03-22 14:31   ` Konrad Rzeszutek Wilk [this message]
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 12:51         ` Konrad Rzeszutek Wilk
2011-03-23 13:17         ` Thomas Hellstrom
2011-03-23 14:52           ` Konrad Rzeszutek Wilk
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 14:25                 ` Konrad Rzeszutek Wilk
2011-03-24 16:06                 ` Jerome Glisse
2011-03-24 16:21                   ` Konrad Rzeszutek Wilk
2011-03-24 16:21                     ` Konrad Rzeszutek Wilk
2011-03-25 20:00                     ` Thomas Hellstrom
2011-03-31 15:49                       ` Konrad Rzeszutek Wilk
2011-03-31 15:49                         ` Konrad Rzeszutek Wilk
2011-04-08 14:57                         ` Thomas Hellstrom
2011-04-08 14:58                           ` Thomas Hellstrom
2011-04-08 15:12                           ` Konrad Rzeszutek Wilk
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
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=20110322143137.GA25113@dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=airlied@redhat.com \
    --cc=alexdeucher@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    --cc=konrad@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas@shipmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.