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@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. 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
