<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Lucas - Ping on my question and also I attached this temporary
      solution for etnaviv to clarify my point. If that something
      acceptable for now at least i can do the same for v3d where it
      requires a bit more code changes.</p>
    <p>Andrey<br>
    </p>
    <div class="moz-cite-prefix">On 2/6/20 10:49 AM, Andrey Grodzovsky
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:90de1234-a103-a695-4ad7-83b1486e15ee@amd.com">
      <blockquote type="cite" style="color: #000000;">Well a revert
        would break our driver.
        <br>
        <br>
        The real solution is that somebody needs to sit down, gather ALL
        the requirements and then come up with a solution which is clean
        and works for everyone.
        <br>
        <br>
        Christian.
        <br>
      </blockquote>
      <br>
      <br>
      I can to take on this as indeed our general design on this becomes
      more and more entangled as GPU reset scenarios grow in complexity
      (at least in AMD driver). Currently I am on a high priority
      internal task which should take me around a week or 2 to finish
      and after that I can get to it.
      <br>
      <br>
      Regarding temporary solution  - I looked into v3d and etnaviv use
      cases and we in AMD actually face the same scenario where we
      decide to skip HW reset if the guilty job did finish by the time
      we are processing the timeout  (see amdgpu_device_gpu_recover and
      skip_hw_reset goto) - the difference is we always call
      drm_sched_stop/start irrespectively of whether we are going to
      actually HW reset or not (same as extend timeout). I wonder if
      something like this can be done also for ve3 and etnaviv ?
      <br>
      <br>
      Andrey
    </blockquote>
  </body>
</html>