[Intel-gfx] [PATCH 07/15] drm/i915/guc: Flush directly in log unregister

[Sagar Arun Kamble]

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 at intel.com>
>>> Cc: Chris Wilson <chris at chris-wilson.co.uk>
>>> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio at intel.com>
>>> Cc: Sagar Arun Kamble <sagar.a.kamble at intel.com>
>>> Cc: Michal Wajdeczko <michal.wajdeczko at intel.com>
>> Reviewed-by: Sagar Arun Kamble <sagar.a.kamble at 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