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

[Tvrtko Ursulin]

On 30/06/16 14:19, Chris Wilson wrote:
> 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.

Will you make it consistent then? R-b if you do. :)

>> 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.)

Hm, ok, don't know about those issues. Either way it is not too bad if 
kerneldoc is overly cautious.

Regards,

Tvrtko