[Intel-gfx] [PATCH v3 07/15] drm/i915: Add functions to allocate / release gem obj for GuC

[Chris Wilson]

On Mon, Apr 20, 2015 at 01:09:18PM -0700, Yu Dai wrote:
> 
> 
> On 04/20/2015 12:52 PM, Chris Wilson wrote:
> >On Mon, Apr 20, 2015 at 09:02:20AM -0700, Yu Dai wrote:
> >>
> >>
> >> On 04/18/2015 06:47 AM, Chris Wilson wrote:
> >> >On Fri, Apr 17, 2015 at 02:21:12PM -0700, yu.dai at intel.com wrote:
> >> >> From: Alex Dai <yu.dai at intel.com>
> >> >>
> >> >> All gem objects used by GuC are pinned to ggtt space out of range
> >> >> [0, WOPCM size]. In GuC address space mapping, [0, WPOCM size] is
> >> >> used internally for its Boot ROM, SRAM etc. Currently this WPOCM
> >> >> size is 512K. This is done by using of PIN_OFFSET_BIAS.
> >> >
> >> >If the region is reserved, remove that region from the GGTT drm_mm range
> >> >manager. Then the restriction is applied to all objects and not in a
> >> >hodge-podge fashion like this.
> >> >
> >> I don't think I have clearly explained this. GTT range [0, WPOCM
> >> size] can't be used by GuC firmware, but still others can use it
> >> without any issue. PIN_OFFSET_BIAS is great for such use case.
> >
> >You mean that the GuC redirects the [0, WOPCM] range to an internal set
> >of preallocated PTEs?
> >
> There is no preallocated PTEs. But GuC treats address within that
> range as the Boot ROM or micro-kernel code / data that resides in
> its own SRAM. Only when it receives address above WPOCM, it will go
> through GGTT to access DRAM memory.

Then I agree your original explanation was very confusing. :)

For the actual code, can you allocate from stolen memory rather than
system memory? Also the call to get_pages() is redundant, and by itself
misleading since the pages will only be valid whilst pinned which is
only done indirectly here.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre