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

[Yu Dai <yu.dai@intel.com>]

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@intel.com wrote:
> > >> From: Alex Dai <yu.dai@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.

Thanks,
Alex
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx