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

From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org,
	Mika Kuoppala <mika.kuoppala@intel.com>
Subject: Re: [PATCH 2/4] drm/i915: Convert sandybridge_pcode_*() to use intel_wait_for_register()
Date: Thu, 30 Jun 2016 14:39:25 +0100	[thread overview]
Message-ID: <5775210D.1070000@linux.intel.com> (raw)
In-Reply-To: <20160630131930.GZ28577@nuc-i3427.alporthouse.com>

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

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx