On 3/5/2018 5:40 PM, Michał Winiarski wrote:
On Mon, Mar 05, 2018 at 05:28:33PM +0530, Sagar Arun Kamble wrote:
On 2/27/2018 6:22 PM, Michał Winiarski wrote:
Having both guc_flush_logs and guc_log_flush functions is confusing.
While we could just rename things, guc_flush_logs implementation is
quite simple. Let's get rid of it and move its content to unregister.
Signed-off-by: Michał Winiarski <michal.winiarski@xxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@xxxxxxxxx>
Cc: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx>
Cc: Michal Wajdeczko <michal.wajdeczko@xxxxxxxxx>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@xxxxxxxxx>
this patch reminds me of need to do guc_log_flush in capture_uc_state prior
to reset in case user wants to read
updated log vma from error state. is this need valid?
I don't think so - force flush Host to GuC is related to "bookkeeping" (think
metadata describing log buffer state - HEAD/TAIL pointers etc).
In error state we don't care - we're dumping the whole log vma.
But while decoding from log vma in error state we will need up to date
read/write pointers.
Or is the error handling logic requires not to invoke any H2G post hang.
Agree that this change has to be taken up later based on consensus on
requirement but just wanted
understand the scenario more.
Thanks,
Sagar
In case of relay - we're moving data around, and we need to know what data to
move.
-Michał
---
drivers/gpu/drm/i915/intel_guc_log.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)
--
Thanks,
Sagar
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
