linux-tegra.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Zhang <nvmarkzhang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Terje Bergström" <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: "dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org"
	<dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>,
	Thierry Reding
	<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
Subject: Re: First version of host1x intro
Date: Fri, 07 Dec 2012 15:05:20 +0800	[thread overview]
Message-ID: <50C19530.2030106@gmail.com> (raw)
In-Reply-To: <50C1903C.8040608-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

On 12/07/2012 02:44 PM, Terje Bergström wrote:
> On 07.12.2012 07:38, Mark Zhang wrote:
>> On 12/06/2012 07:36 PM, Terje Bergström wrote:
>>> This is about the hardware, and the correct verb is "copy". HOST1X
>>> hardware pre-fetches opcodes from push buffer and contents of GATHERs to
>>> a FIFO to overcome memory latencies. The execution happens from FIFO.
>> Okay, so the command FIFO is not a part of memory we need to allocate.
>> It's inside in every host1x clients.
> 
> Almost - it's part of HOST1X itself, not clients.

Got it.

> 
>> Yeah, I have known the idea. What I'm confused before is that why we
>> need this reloc table because all mem are allocated from us(I mean,
>> tegradrm/nvhost) so ideally we can find out all buffer related infos in
>> the driver while userspace doesn't need to provide such informations.
> 
> For lots of buffers, there's no need to map them to user space at all,
> so user space can treat the buffer as just an abstract region. For
> example, getting handle to frame buffer and passing it to 2D for
> rendering doesn't require user space to map the memory.
> 
> Second point is that as long as we haven't pinned memory, there's a
> possibility to move the pages around to do defragmenting etc. As soon as
> you get a device virtual address to a page, you need to pin it and can't
> move it anymore. So we want to build the APIs and sequences so that the
> pages can be pinned as late as possible.
> 

Great, these are another two strong evidences. Big thanks. :)

> Naturally, in CMA, the second point isn't that relevant, but I want the
> API to tolerate IOMMU support, too.
> 
> Terje
> 

      parent reply	other threads:[~2012-12-07  7:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-05  9:47 First version of host1x intro Terje Bergström
     [not found] ` <50BF1831.3060606-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-06  7:06   ` Mark Zhang
     [not found]     ` <50C0440D.3000702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-06  7:20       ` Lucas Stach
2012-12-06  7:49         ` Mark Zhang
     [not found]           ` <50C04E1D.1050702-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-06  8:00             ` Lucas Stach
2012-12-06  8:13               ` Mark Zhang
     [not found]                 ` <50C053AD.2000802-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-06 11:17                   ` Lucas Stach
2012-12-07  5:26                     ` Mark Zhang
2012-12-06 18:46                   ` Stephen Warren
     [not found]                     ` <50C0E7F4.2090802-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-12-07  5:49                       ` Mark Zhang
2012-12-06 11:36       ` Terje Bergström
     [not found]         ` <50C08338.3070408-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-07  5:38           ` Mark Zhang
     [not found]             ` <50C180DA.508-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-12-07  6:44               ` Terje Bergström
     [not found]                 ` <50C1903C.8040608-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-12-07  7:05                   ` 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=50C19530.2030106@gmail.com \
    --to=nvmarkzhang-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.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).