Re: [PATCH 2/4] drm/i915: Convert sandybridge_pcode_*() to use intel_wait_for_register()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux