On Sat, 23 Sep 2017 14:23:06 +0200, Sagar Arun Kamble
wrote:
Apart from configuring interrupts, we need to update the ggtt invalidate
interface and GuC communication on suspend/resume. This functionality
can be reused for other suspend and reset paths.
v2: Rebase w.r.t removal of GuC code re
== Series Details ==
Series: GEM/GuC Suspend/Resume/Reset fixes and restructuring
URL : https://patchwork.freedesktop.org/series/30802/
State : warning
== Summary ==
Series 30802v1 GEM/GuC Suspend/Resume/Reset fixes and restructuring
https://patchwork.freedesktop.org/api/1.0/series/30802/revis
Before i915 reset, we need to disable GuC submission and suspend GuC
operations as it is recreated during intel_uc_init_hw. We can't reuse the
intel_uc_suspend functionality as reset path already holds struct_mutex.
v2: Rebase w.r.t removal of GuC code restructuring. Updated reset_prepare
function
We ensure that GuC is completely suspended and client is destroyed
in i915_gem_suspend during i915_driver_unload. So now intel_uc_fini_hw
should just take care of cleanup,
hence s/intel_uc_fini_hw/intel_uc_cleanup. Correspondingly
we also updated as s/i915_guc_submission_fini/i915_guc_submission_cl
With this patch we disable GuC submission in i915_drm_suspend path.
This will destroy the client which will be setup back again. We also
reuse the complete sanitization done via intel_uc_runtime_suspend in
this path. Post i915_drm_resume, this state is recreated by
intel_uc_init_hw hence we need no
Currently GPU is reset at the end of suspend via i915_gem_sanitize.
On resume, GuC will not be loaded until intel_uc_init_hw happens
during GEM resume flow but action to exit sleep wll be send to GuC
considering the FW load status. To make sure we don't invoke that
action update GuC FW load status
Apart from configuring interrupts, we need to update the ggtt invalidate
interface and GuC communication on suspend/resume. This functionality
can be reused for other suspend and reset paths.
v2: Rebase w.r.t removal of GuC code restructuring.
v3: Removed GuC specific helpers as tasks other than
This patch moves GuC suspend/resume handlers to corresponding GEM handlers
and orders them properly in the runtime and system suspend/resume flows.
It also adds documentation for GEM suspend/resume handlers.
i915_gem_restore_fences is GEM resumption task hence it is moved to
i915_gem_resume from i9
These eight patches are derived from series
https://patchwork.freedesktop.org/series/30715/.
First four patches adjust the GEM/GuC suspend/resume flows and last four patches
fix GuC functionality along those paths.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Imre Deak
Cc: Paulo Zanoni
Cc: Rodrig
Prepared generic helpers intel_uc_suspend, intel_uc_resume,
intel_uc_runtime_suspend, intel_uc_runtime_resume. These are
called from respective GEM functions.
v2: Rebase w.r.t removal of GuC code restructuring.
v3: Calling intel_uc_resume from i915_gem_resume post resuming
i915 gem setup. This is
Prepared helper i915_gem_runtime_resume to recreate gem setup.
Returning status from i915_gem_runtime_suspend and i915_gem_resume.
This will be placeholder for handling any errors from uC suspend/resume
in upcoming patches. Restructured the suspend/resume routines w.r.t setup
creation and rollback
== Series Details ==
Series: Add missing BXT/CNL DPLL debugging/checking code
URL : https://patchwork.freedesktop.org/series/30790/
State : success
== Summary ==
Test kms_flip:
Subgroup plain-flip-ts-check:
pass -> FAIL (shard-hsw) fdo#100368
Test kms_setmod
Quoting Matthew Auld (2017-09-22 18:32:52)
> For gen8+ platforms which support the 48b PPGTT, enable platform level
> support for 2M pages. Also enable for mock testing.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
__
Quoting Matthew Auld (2017-09-22 18:32:51)
> For gen9+ enable platform level support for 64K pages. Also enable for
> mock testing.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
___
Intel-gf
Quoting Matthew Auld (2017-09-22 18:32:50)
> Currently gvt gtt handling doesn't support huge page entries, so disable
> for now.
>
> v2: remove useless 48b PPGTT check
>
> Suggested-by: Zhenyu Wang
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> Cc: Zhenyu Wang
Revie
Quoting Matthew Auld (2017-09-22 18:32:49)
> Try to mix sg page sizes for 4K, 64K and 2M pages.
>
> v2: s/BIT(x) >> 12/BIT(x) >> PAGE_SHIFT/
>
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
Quoting Matthew Auld (2017-09-22 18:32:47)
> Good to know, mostly for debugging purposes.
>
> v2: some improvements from Chris
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx ma
Quoting Matthew Auld (2017-09-22 18:32:46)
> Now that we support multiple page sizes for the ppgtt, it would be
> useful to track the real usage for debugging purposes.
Now? I kind of think knowing as we add the different support is
interesting.
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtin
Quoting Matthew Auld (2017-09-22 18:32:45)
> Support inserting 64K pages into the 48b PPGTT.
>
> v2: check for 64K scratch
>
> v3: we should only have to re-adjust maybe_64K at every sg interval
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
Quoting Matthew Auld (2017-09-22 18:32:44)
> Before we can fully enable 64K pages, we need to first support a 64K
> scratch page if we intend to support the case where we have object sizes
> < 2M, since any scratch PTE must also point to a 64K region. Without
> this our 64K usage is limited to obj
Quoting Matthew Auld (2017-09-22 18:32:43)
> Support inserting 2M gtt pages into the 48b PPGTT.
>
> v2: sanity check sg->length against page_size
>
> v3: don't recalculate rem on each loop
> whitespace breakup
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Chris Wilson
> ---
Quoting Matthew Auld (2017-09-22 18:32:40)
> We can't mix 64K and 4K pte's in the same page-table, so for now we
> align 64K objects to 2M to avoid any potential mixing. This is
> potentially wasteful but in reality shouldn't be too bad since this only
> applies to the virtual address space of a 48
Quoting Matthew Auld (2017-09-22 18:32:39)
> For the 48b PPGTT try to align the vma start address to the required
> page size boundary to guarantee we use said page size in the gtt. If we
> are dealing with multiple page sizes, we can't guarantee anything and
> just align to the largest. For soft p
Quoting Matthew Auld (2017-09-22 18:32:37)
> In preparation for supporting huge gtt pages for the ppgtt, we introduce
> page size members for gem objects. We fill in the page sizes by
> scanning the sg table.
>
> v2: pass the sg_mask to set_pages
>
> v3: calculate the sg_mask inline with populat
Quoting Matthew Auld (2017-09-22 18:32:38)
> Move the setting/clearing of the vma->pages to a vm operation. Doing so
> neatens things up a little, but more importantly gives us a sane place
> to also set/clear the vma->pages_sizes, which we introduce later in
> preparation for supporting huge-pages
Quoting Matthew Auld (2017-09-22 18:32:36)
> Each backend is now responsible for calling __i915_gem_object_set_pages
> upon successfully gathering its backing storage. This eliminates the
> inconsistency between the async and sync paths, which stands out even
> more when we start throwing around an
Quoting Matthew Auld (2017-09-22 18:32:35)
> In preparation for huge gtt pages expose page_sizes as part of the
> device info, to indicate the page sizes supported by the HW. Currently
> only 4K is supported.
>
> v2: s/page_size_mask/page_sizes/
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Laht
Quoting Matthew Auld (2017-09-22 18:32:33)
> +static int i915_gem_object_create_shmem(struct drm_device *dev,
> + struct drm_gem_object *obj,
> + size_t size)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> +
Quoting Matthew Auld (2017-09-22 18:32:48)
> +static int igt_write_huge(struct drm_i915_gem_object *obj)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct i915_gem_context *ctx = i915->kernel_context;
> + struct i915_address_space *vm = ctx->ppgtt ? &ctx-
== Series Details ==
Series: Add missing BXT/CNL DPLL debugging/checking code
URL : https://patchwork.freedesktop.org/series/30790/
State : success
== Summary ==
Series 30790v1 Add missing BXT/CNL DPLL debugging/checking code
https://patchwork.freedesktop.org/api/1.0/series/30790/revisions/1/m
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Ville Syrjälä
> Sent: perjantai 22. syyskuuta 2017 18.48
> To: Srinivas, Vidya
> Cc: intel-gfx@lists.freedesktop.org; Syrjala, Ville
> Subject: Re: [Intel-gfx] [PATCH v5] drm/i915:
31 matches
Mail list logo
