On 02/15/2016 07:23 AM, Dave Gordon wrote:
On 12/02/16 13:03, Tvrtko Ursulin wrote:
>
> On 11/02/16 23:09, yu.dai@xxxxxxxxx wrote:
>> From: Alex Dai <yu.dai@xxxxxxxxx>
>>
>> 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 ...
Yes, there is a vmap_obj we can use but it is static. Actually two,
vmap_batch() in i915_cmd_parser.c and vmap_obj() in intel_ringbuffer.c.
Maybe it is a good idea to make it global, so GuC can use it too.
Thanks,
Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
