On Thu, Jun 30, 2016 at 02:04:43PM +0100, Tvrtko Ursulin wrote: > > On 30/06/16 12:30, Chris Wilson wrote: > >+ if (intel_wait_for_register(dev_priv, > >+ GEN6_PCODE_MAILBOX, GEN6_PCODE_READY, 0, > >+ 500)) { > > Why not the _fw version? No reason, just added the read half of this patch after doing the mass conversion so I had intel_wait_for_register() on my fingers. > Actually brings me to the point I glanced over in the previous patch > - why would intel_wait_for_register_fw be not suitable for long > waits? It looks like a concern for the calling code grabbing the fw > outside it for a long period and not for the function itself. This > call site being a case in point for that. The code here doesn't take a wakeref for its register reads (as they are through the MCHBAR and not our GT powerwell). My concern is that I don't want to encourage people to hold the wakeref for tens, even hundreds of milliseconds, waiting for random changes in the hardware. Another concern is that there are some instability issues in overusing the unlocked mmio accessors (due to bad hw) and there we need to be judicious in when we use them. (I keep wondering if we have sufficient contention issue to justify a hashed spinlock per mmio-cacheline.) -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx