From: Thomas Hellstrom <thomas@shipmail.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
thellstrom@vmware.com, airlied@redhat.com,
xen-devel@lists.xensource.com, j.glisse@redhat.com,
bskeggs@redhat.com
Subject: Re: [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool.
Date: Mon, 24 Oct 2011 19:42:25 +0200 [thread overview]
Message-ID: <4EA5A381.1050100@shipmail.org> (raw)
In-Reply-To: <20111024172728.GD2320@phenom.dumpdata.com>
On 10/24/2011 07:27 PM, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
>
>> Konrad,
>>
>> I was hoping that we could get rid of the dma_address shuffling into
>> core TTM,
>> like I mentioned in the review. From what I can tell it's now only
>> used in the backend and
>> core ttm doesn't care about it.
>>
>> Is there a particular reason we're still passing it around?
>>
> Yes - and I should have addressed that in the writeup but forgot, sorry about that.
>
> So initially I thought you meant this:
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 360afb3..06ef048 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -662,8 +662,7 @@ out:
>
> /* Put all pages in pages list to correct pool to wait for reuse */
> static void __ttm_put_pages(struct list_head *pages, unsigned page_count,
> - int flags, enum ttm_caching_state cstate,
> - dma_addr_t *dma_address)
> + int flags, enum ttm_caching_state cstate)
> {
> unsigned long irq_flags;
> struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
> @@ -707,8 +706,7 @@ static void __ttm_put_pages(struct list_head *pages, unsigned page_count,
> * cached pages.
> */
> static int __ttm_get_pages(struct list_head *pages, int flags,
> - enum ttm_caching_state cstate, unsigned count,
> - dma_addr_t *dma_address)
> + enum ttm_caching_state cstate, unsigned count)
> {
> struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
> struct page *p = NULL;
> @@ -864,7 +862,7 @@ int ttm_get_pages(struct ttm_tt *ttm, struct list_head *pages,
> if (ttm->be&& ttm->be->func&& ttm->be->func->get_pages)
> return ttm->be->func->get_pages(ttm, pages, count, dma_address);
> return __ttm_get_pages(pages, ttm->page_flags, ttm->caching_state,
> - count, dma_address);
> + count)
> }
> void ttm_put_pages(struct ttm_tt *ttm, struct list_head *pages,
> unsigned page_count, dma_addr_t *dma_address)
> @@ -873,5 +871,5 @@ void ttm_put_pages(struct ttm_tt *ttm, struct list_head *pages,
> ttm->be->func->put_pages(ttm, pages, page_count, dma_address);
> else
> __ttm_put_pages(pages, page_count, ttm->page_flags,
> - ttm->caching_state, dma_address);
> + ttm->caching_state)
> }
> which is trivial (thought I have not compile tested it), but it should do it.
>
> But I think you mean eliminate the dma_address handling completly in
> ttm_page_alloc.c and ttm_tt.c.
>
> For that there are couple of architectural issues I am not sure how to solve.
>
> There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> to say: "here is a 'struct page *', give me the bus address". Currently
> this is solved by keeping an array of DMA addresses along with the list
> of pages. And passing the list and DMA address up the stack (and down)
> from TTM up to the driver (when ttm->be->func->populate is called and they
> are handed off) does it. It does not break any API layering .. and the internal
> TTM pool (non-DMA) can just ignore the dma_address altogether (see patch above).
>
>
I actually had something more simple in mind, but when tinking a bit
deeper into it, it seems more complicated than I initially thought.
Namely that when we allocate pages from the ttm_backend, we actually
populated it at the same time. be::populate would then not take a page
array as an argument, and would actually be a no-op on many
drivers.
This makes us move towards struct ttm_tt consisting almost only of its
backend, so that whole API should perhaps be looked at with new eyes.
So anyway, I'm fine with high level things as they are now, and the
dma_addr issue can be looked at at a later time. If we could get a
couple of extra eyes to review the code for style etc. would be great,
because I have very little time the next couple of weeks.
/Thomas
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Hellstrom <thomas@shipmail.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: thellstrom@vmware.com, xen-devel@lists.xensource.com,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
j.glisse@redhat.com, airlied@redhat.com, bskeggs@redhat.com
Subject: Re: [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool.
Date: Mon, 24 Oct 2011 19:42:25 +0200 [thread overview]
Message-ID: <4EA5A381.1050100@shipmail.org> (raw)
In-Reply-To: <20111024172728.GD2320@phenom.dumpdata.com>
On 10/24/2011 07:27 PM, Konrad Rzeszutek Wilk wrote:
> On Sat, Oct 22, 2011 at 11:40:54AM +0200, Thomas Hellstrom wrote:
>
>> Konrad,
>>
>> I was hoping that we could get rid of the dma_address shuffling into
>> core TTM,
>> like I mentioned in the review. From what I can tell it's now only
>> used in the backend and
>> core ttm doesn't care about it.
>>
>> Is there a particular reason we're still passing it around?
>>
> Yes - and I should have addressed that in the writeup but forgot, sorry about that.
>
> So initially I thought you meant this:
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 360afb3..06ef048 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -662,8 +662,7 @@ out:
>
> /* Put all pages in pages list to correct pool to wait for reuse */
> static void __ttm_put_pages(struct list_head *pages, unsigned page_count,
> - int flags, enum ttm_caching_state cstate,
> - dma_addr_t *dma_address)
> + int flags, enum ttm_caching_state cstate)
> {
> unsigned long irq_flags;
> struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
> @@ -707,8 +706,7 @@ static void __ttm_put_pages(struct list_head *pages, unsigned page_count,
> * cached pages.
> */
> static int __ttm_get_pages(struct list_head *pages, int flags,
> - enum ttm_caching_state cstate, unsigned count,
> - dma_addr_t *dma_address)
> + enum ttm_caching_state cstate, unsigned count)
> {
> struct ttm_page_pool *pool = ttm_get_pool(flags, cstate);
> struct page *p = NULL;
> @@ -864,7 +862,7 @@ int ttm_get_pages(struct ttm_tt *ttm, struct list_head *pages,
> if (ttm->be&& ttm->be->func&& ttm->be->func->get_pages)
> return ttm->be->func->get_pages(ttm, pages, count, dma_address);
> return __ttm_get_pages(pages, ttm->page_flags, ttm->caching_state,
> - count, dma_address);
> + count)
> }
> void ttm_put_pages(struct ttm_tt *ttm, struct list_head *pages,
> unsigned page_count, dma_addr_t *dma_address)
> @@ -873,5 +871,5 @@ void ttm_put_pages(struct ttm_tt *ttm, struct list_head *pages,
> ttm->be->func->put_pages(ttm, pages, page_count, dma_address);
> else
> __ttm_put_pages(pages, page_count, ttm->page_flags,
> - ttm->caching_state, dma_address);
> + ttm->caching_state)
> }
> which is trivial (thought I have not compile tested it), but it should do it.
>
> But I think you mean eliminate the dma_address handling completly in
> ttm_page_alloc.c and ttm_tt.c.
>
> For that there are couple of architectural issues I am not sure how to solve.
>
> There has to be some form of TTM<->[Radeon|Nouveau] lookup mechanism
> to say: "here is a 'struct page *', give me the bus address". Currently
> this is solved by keeping an array of DMA addresses along with the list
> of pages. And passing the list and DMA address up the stack (and down)
> from TTM up to the driver (when ttm->be->func->populate is called and they
> are handed off) does it. It does not break any API layering .. and the internal
> TTM pool (non-DMA) can just ignore the dma_address altogether (see patch above).
>
>
I actually had something more simple in mind, but when tinking a bit
deeper into it, it seems more complicated than I initially thought.
Namely that when we allocate pages from the ttm_backend, we actually
populated it at the same time. be::populate would then not take a page
array as an argument, and would actually be a no-op on many
drivers.
This makes us move towards struct ttm_tt consisting almost only of its
backend, so that whole API should perhaps be looked at with new eyes.
So anyway, I'm fine with high level things as they are now, and the
dma_addr issue can be looked at at a later time. If we could get a
couple of extra eyes to review the code for style etc. would be great,
because I have very little time the next couple of weeks.
/Thomas
next prev parent reply other threads:[~2011-10-24 17:44 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-19 22:19 [PATCH] TTM DMA pool v2.1 Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 01/11] swiotlb: Expose swiotlb_nr_tlb function to modules Konrad Rzeszutek Wilk
2011-10-22 4:49 ` FUJITA Tomonori
2011-10-22 4:49 ` FUJITA Tomonori
2011-10-19 22:19 ` [PATCH 02/11] nouveau/radeon: Set coherent DMA mask Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 03/11] ttm/radeon/nouveau: Check the DMA address from TTM against known value Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 04/11] ttm: Wrap ttm_[put|get]_pages and extract GFP_* and caching states from 'struct ttm_tt' Konrad Rzeszutek Wilk
2011-10-19 22:19 ` Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 05/11] ttm: Get rid of temporary scaffolding Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool Konrad Rzeszutek Wilk
2011-10-22 9:40 ` Thomas Hellstrom
2011-10-22 9:40 ` Thomas Hellstrom
2011-10-24 17:27 ` Konrad Rzeszutek Wilk
2011-10-24 17:27 ` Konrad Rzeszutek Wilk
2011-10-24 17:42 ` Thomas Hellstrom [this message]
2011-10-24 17:42 ` Thomas Hellstrom
2011-10-24 18:18 ` Konrad Rzeszutek Wilk
2011-10-24 18:18 ` Konrad Rzeszutek Wilk
2011-11-01 14:37 ` Jerome Glisse
2011-11-01 14:48 ` Thomas Hellstrom
2011-10-19 22:19 ` [PATCH 07/11] ttm: Do not set the ttm->be to NULL before calling the TTM page pool to free pages Konrad Rzeszutek Wilk
2011-10-19 22:19 ` Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 08/11] ttm: Provide DMA aware TTM page pool code Konrad Rzeszutek Wilk
2011-10-31 19:37 ` Jerome Glisse
2011-11-01 13:51 ` Konrad Rzeszutek Wilk
2011-11-01 13:51 ` Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 09/11] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 10/11] nouveau/ttm/dma: Enable the TTM DMA pool if device can only do 32-bit DMA Konrad Rzeszutek Wilk
2011-10-19 22:19 ` Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 11/11] radeon/ttm/dma: Enable the TTM DMA pool if the device can only do 32-bit Konrad Rzeszutek Wilk
2011-10-20 1:38 ` [PATCH] TTM DMA pool v2.1 Konrad Rzeszutek Wilk
2011-10-31 22:05 ` Jerome Glisse
-- strict thread matches above, loose matches on Subject: below --
2011-11-01 18:47 [PATCH] TTM DMA pool v2.2 or [GIT PULL] (stable/ttm.dma_pool.v2.3) for 3.3 Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool Konrad Rzeszutek Wilk
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=4EA5A381.1050100@shipmail.org \
--to=thomas@shipmail.org \
--cc=airlied@redhat.com \
--cc=bskeggs@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=j.glisse@redhat.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thellstrom@vmware.com \
--cc=xen-devel@lists.xensource.com \
/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.