<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 16, 2017 at 9:53 AM, Christian König <span dir="ltr"><<a href="mailto:christian.koenig@amd.com" target="_blank">christian.koenig@amd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div class="gmail_quote">
      <blockquote type="cite">[SNIP]<span class=""><br>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div dir="ltr">
            <div class="gmail_extra">
              <div class="gmail_quote">
                <div>
                  <div class="m_-2078583563625928927h5">
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      See a wait_queue is a callback mechanism anyway,
                      so you are wrapping a callback mechanism inside
                      another callback mechanism and that makes not
                      really much sense.<br>
                    </blockquote>
                    <div><br>
                    </div>
                  </div>
                </div>
                <div>Fair enough.  There is one little snag though:  We
                  need to wait on sync objects and fences at the same
                  time in order for WAIT_ANY | WAIT_FOR_SUBMIT to work. 
                  I see two options here:<br>
                  <br>
                </div>
                <div> 1) Convert dma-fence to use waitqueue instead of
                  its callback mechanism and add a wait_queue_any.  A
                  quick grep for dma_fence_add_callback says that this
                  would affect four drivers.<br>
                </div>
              </div>
            </div>
          </div>
        </blockquote>
        <div><br>
        </div>
        The more I think about it, the less sense using waitqueues
        makes.  The fundamental problem here is that the event we are
        waiting on is actually the concatenation of two events: submit
        and signal.  Since we are waiting on several of these pairs of
        concatenated events simultaneously, the only two options we have
        are to either combine them into one event (the proxy approach)
        or to implement a wait which is capable of handling both at the
        same time.  I don't see a way to do the latter with wait queues.<br>
      </span></blockquote>
      <br>
      <div>Agree completely.<br>
        <br>
        Essentially we would need to enable wait_event_* to wait for
        multiple events and then convert all the fence callback stuff to
        wait_event structures.<br>
        <br>
        But that is certainly outside the scope of this patchset, so
        feel free to go ahead with the approach of waiting manually (but
        please without the bugs).<br>
      </div>
    </div>
  </div>

</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Well, the patches I sent last night should do just that.  It's mostly the original approach but with the bugfixes from versions 3 and 4.  Modulo finding additional bugs, I think they should be good to go.</div><div class="gmail_extra"><br></div><div class="gmail_extra">--Jason<br></div></div>