<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>JingWen - could you maybe give those patches a try on SRIOV XGMI
      system ? If you see issues maybe you could let me connect and
      debug. My SRIOV XGMI system which Shayun kindly arranged for me is
      not loading the driver with my drm-misc-next branch even without
      my patches.<br>
    </p>
    <p>Andrey<br>
    </p>
    <div class="moz-cite-prefix">On 2022-01-17 14:21, Andrey Grodzovsky
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:769b97dd-c6f9-88fe-a26b-34bfd617e257@amd.com">
      
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 2022-01-17 2:17 p.m., Christian
        König wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:096c0884-7e32-40ed-7570-b65f19104f5f@gmail.com">
        
        Am 17.01.22 um 20:14 schrieb Andrey Grodzovsky:<br>
        <blockquote type="cite" cite="mid:62f9f1c2-312b-760e-75f7-e86421333be3@amd.com">
          <p>Ping on the question</p>
        </blockquote>
        <br>
        Oh, my! That was already more than a week ago and is completely
        swapped out of my head again.<br>
        <br>
        <blockquote type="cite" cite="mid:62f9f1c2-312b-760e-75f7-e86421333be3@amd.com">
          <p>Andrey<br>
          </p>
          <div class="moz-cite-prefix">On 2022-01-05 1:11 p.m., Andrey
            Grodzovsky wrote:<br>
          </div>
          <blockquote type="cite" cite="mid:c64c933f-498d-a2d9-fe63-058c6f1bed9c@amd.com">
            <blockquote type="cite" style="color: #007cff;">
              <blockquote type="cite" style="color: #007cff;">Also, what
                about having the reset_active or in_reset flag in the
                reset_domain itself? <br>
              </blockquote>
              <br>
              Of hand that sounds like a good idea. <br>
            </blockquote>
            <br>
            <br>
            What then about the adev->reset_sem semaphore ? Should we
            also move this to reset_domain ?  Both of the moves have
            functional <br>
            implications only for XGMI case because there will be
            contention over accessing those single instance variables
            from multiple devices <br>
            while now each device has it's own copy. <br>
          </blockquote>
        </blockquote>
        <br>
        Since this is a rw semaphore that should be unproblematic I
        think. It could just be that the cache line of the lock then
        plays ping/pong between the CPU cores.<br>
        <br>
        <blockquote type="cite" cite="mid:62f9f1c2-312b-760e-75f7-e86421333be3@amd.com">
          <blockquote type="cite" cite="mid:c64c933f-498d-a2d9-fe63-058c6f1bed9c@amd.com"> <br>
            What benefit the centralization into reset_domain gives - is
            it for example to prevent one device in a hive trying to
            access through MMIO another one's <br>
            VRAM (shared FB memory) while the other one goes through
            reset ? <br>
          </blockquote>
        </blockquote>
        <br>
        I think that this is the killer argument for a centralized lock,
        yes.<br>
      </blockquote>
      <p><br>
      </p>
      <p>np, i will add a patch with centralizing both flag into reset
        domain and resend.</p>
      <p>Andrey</p>
      <p><br>
      </p>
      <blockquote type="cite" cite="mid:096c0884-7e32-40ed-7570-b65f19104f5f@gmail.com"> <br>
        Christian.<br>
        <br>
        <blockquote type="cite" cite="mid:62f9f1c2-312b-760e-75f7-e86421333be3@amd.com">
          <blockquote type="cite" cite="mid:c64c933f-498d-a2d9-fe63-058c6f1bed9c@amd.com"> <br>
            Andrey </blockquote>
        </blockquote>
        <br>
      </blockquote>
    </blockquote>
  </body>
</html>