mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Zhang <nvmarkzhang@gmail.com>
To: "Terje Bergström" <tbergstrom@nvidia.com>
Cc: "thierry.reding@avionic-design.de"
	<thierry.reding@avionic-design.de>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"dev@lynxeye.de" <dev@lynxeye.de>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCHv4 0/8] Support for Tegra 2D hardware
Date: Thu, 03 Jan 2013 13:55:43 +0800	[thread overview]
Message-ID: <50E51D5F.6090009@gmail.com> (raw)
In-Reply-To: <50E51C08.1020603@nvidia.com>

On 01/03/2013 01:50 PM, Terje Bergström wrote:
> On 03.01.2013 05:31, Mark Zhang wrote:
>> Sorry I didn't get it. Yes, in current design, you can pin all mem
>> handles in one time but I haven't found anything related with "locking
>> only once per submit".
>>
>> My idea is:
>> - remove "job->addr_phys"
>> - assign "job->reloc_addr_phys" & "job->gather_addr_phys" separately
>> - In "pin_job_mem", just call "host1x_memmgr_pin_array_ids" twice to
>> fill the "reloc_addr_phy" & "gather_addr_phys".
>>
>> Anything I misunderstood?
> 
> The current design uses CMA, which makes pinning basically a no-op. When
> we have IOMMU support, pinning requires calling into IOMMU. Updating
> SMMU tables requires locking, and probably maintenance before SMMU code
> also requires its own locked data tables. For example, preventing
> duplicate pinning might require a global table of handles.
> 
> Putting all of the handles in one table allows doing duplicate detection
> across cmdbuf and reloc tables. This allows pinning each buffer exactly
> once, which reduces number of calls to IOMMU.
> 

Thanks Terje. Yes, I understand IOMMU will bring in more operations. But
I'm not convinced that separating 2 arrays have lots of overheads than
putting them into one array.

But it doesn't matter, after the IOMMU support version released, I can
read this part of codes again. Let's talk about this at that time.

>> "host1x_cma_pin_array_ids" doesn't return negative value right now, so
>> maybe you need to take a look at it.
> 
> True, and also a consequence of using CMA: pinning can never fail. With
> IOMMU, pinning can fail.

Got it. Agree.

> 
> Terje
> 

      reply	other threads:[~2013-01-03  5:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-21 11:39 Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 1/8] gpu: host1x: Add host1x driver Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 2/8] gpu: host1x: Add syncpoint wait and interrupts Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 3/8] gpu: host1x: Add channel support Terje Bergstrom
2012-12-22  4:17   ` Steven Rostedt
2013-01-02  9:31     ` Terje Bergström
2013-01-02  7:40   ` Mark Zhang
2013-01-02  9:31     ` Terje Bergström
2013-01-02  9:31       ` Mark Zhang
2013-01-02  9:43         ` Terje Bergström
2012-12-21 11:39 ` [PATCHv4 4/8] gpu: host1x: Add debug support Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 5/8] drm: tegra: Remove redundant host1x Terje Bergstrom
2012-12-21 14:36   ` Thierry Reding
2012-12-22  6:50     ` Terje Bergström
2012-12-25  5:25       ` Stephen Warren
2012-12-28 21:21         ` Thierry Reding
2012-12-31  6:43           ` Terje Bergström
2013-01-03 17:58     ` Terje Bergström
2012-12-21 11:39 ` [PATCHv4 6/8] ARM: tegra: Add board data and 2D clocks Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 7/8] drm: tegra: Add gr2d device Terje Bergstrom
2012-12-21 11:39 ` [PATCHv4 8/8] gpu: host1x: Register DRM dummy device Terje Bergstrom
2012-12-21 13:53   ` Lucas Stach
2012-12-21 14:09     ` Thierry Reding
2012-12-21 13:50 ` [PATCHv4 0/8] Support for Tegra 2D hardware Lucas Stach
2012-12-21 13:57   ` Terje Bergström
2012-12-21 13:59     ` Lucas Stach
2013-01-03  6:14   ` Terje Bergström
2012-12-26  9:42 ` Mark Zhang
2013-01-02  9:25   ` Terje Bergström
2013-01-03  2:36     ` Mark Zhang
2012-12-28  9:14 ` Mark Zhang
2013-01-02  9:42   ` Terje Bergström
2013-01-03  3:31     ` Mark Zhang
2013-01-03  5:50       ` Terje Bergström
2013-01-03  5:55         ` Mark Zhang [this message]

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=50E51D5F.6090009@gmail.com \
    --to=nvmarkzhang@gmail.com \
    --cc=airlied@linux.ie \
    --cc=dev@lynxeye.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=tbergstrom@nvidia.com \
    --cc=thierry.reding@avionic-design.de \
    /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

Powered by JetHome