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@xxxxxxxxx wrote:
> >> From: Alex Dai <yu.dai@xxxxxxxxx>
> >>
> >> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx