Re: [PATCH 07/15] drm/i915/guc: Flush directly in log unregister

[Sagar Arun Kamble <sagar.a.kamble@intel.com>]

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@intel.com>
>>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
>>> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>>> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
>> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
>>
>> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx