<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Am 17.01.22 um 20:14 schrieb Andrey Grodzovsky:<br>
    <blockquote type="cite"
      cite="mid:62f9f1c2-312b-760e-75f7-e86421333be3@amd.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <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>
    <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>
  </body>
</html>