On Wed, Feb 17, 2016 at 09:48:31AM -0800, Yu Dai wrote: > > > On 02/17/2016 08:04 AM, Daniel Vetter wrote: > >On Tue, Feb 16, 2016 at 08:47:07AM -0800, Yu Dai wrote: > >> > >> > >> 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. > > > >There should be a vmap function somewhere in the dma-buf code too iirc. > > Yes, i915_gem_dmabuf_vmap. Let me try to make a common helper function can be shared. I have sent such a patch many times. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
