From: Dave Gordon <david.s.gordon@intel.com>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>,
yu.dai@intel.com, intel-gfx@lists.freedesktop.org
Cc: daniel.vetter@ffwll.ch
Subject: Re: [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object
Date: Mon, 15 Feb 2016 15:23:55 +0000 [thread overview]
Message-ID: <56C1ED8B.9090307@intel.com> (raw)
In-Reply-To: <56BDD80C.40908@linux.intel.com>
On 12/02/16 13:03, Tvrtko Ursulin wrote:
>
> On 11/02/16 23:09, yu.dai@intel.com wrote:
>> From: Alex Dai <yu.dai@intel.com>
>>
>> GuC client object is always pinned during its life cycle. We cache
>> the kmap of its first page, which includes guc_process_desc and
>> doorbell. By doing so, we can simplify the code where we read from
>> this page to get where GuC is progressing on work queue; and the
>> code where driver program doorbell to send work queue item to GuC.
There's still one k(un)map_atomic() pair, in guc_add_workqueue_item().
Maybe we could get rid of that one too? So instead of kmapping only the
first page of the client, we could vmap() all three pages and so not
need to kmap_atomic() the WQ pages on the fly.
There's a handy vmap_obj() function we might use, except it's currently
static ...
.Dave.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-02-15 15:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-11 23:09 [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object yu.dai
2016-02-12 13:03 ` Tvrtko Ursulin
2016-02-15 14:39 ` Dave Gordon
2016-02-16 16:27 ` Yu Dai
2016-02-15 15:23 ` Dave Gordon [this message]
2016-02-16 16:47 ` Yu Dai
2016-02-17 16:04 ` Daniel Vetter
2016-02-17 17:48 ` Yu Dai
2016-02-18 9:51 ` Chris Wilson
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=56C1ED8B.9090307@intel.com \
--to=david.s.gordon@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=tvrtko.ursulin@linux.intel.com \
--cc=yu.dai@intel.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 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).