[Intel-gfx] [PATCH 3/3] drm/i915: go back to switch for VLV mem freq detection

Jesse Barnes jbarnes at virtuousgeek.org
Thu May 2 04:15:45 CEST 2013


Yeah, saw that too but was too ashamed... anyway it needs fixing. And apparently the docs are wrong on this anyway and 11 indicates 1333, while 0 or 1 is 800. Will post an updated one. 


--
Jesse Barnes, Intel Open Source Technology Center


-------- Original message --------
From: Kenneth Graunke <kenneth at whitecape.org> 
Date: 05/01/2013  6:38 PM  (GMT-08:00) 
To: Ben Widawsky <ben at bwidawsk.net> 
Cc: Jesse Barnes <jbarnes at virtuousgeek.org>,intel-gfx at lists.freedesktop.org 
Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915: go back to switch for VLV mem freq detection 
 
On 05/01/2013 06:26 PM, Ben Widawsky wrote:
> On Wed, May 01, 2013 at 04:09:22PM -0700, Jesse Barnes wrote:
>> We need to catch the invalid case and override it.
>>
>> Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>

Jesse, it's actually worse than that:

Your parenthesis were off in the previous version, causing it to do the 
multiplication by 266 before the bitwise-and:

    800 + ((266 * (val >> 6)) & 3)

This meant that you always got 800 or 802 Mhz.

Also, even when corrected, your previous formula would return 1332 Mhz 
instead of 1333 Mhz, which is slightly off and doesn't work since you 
use it in explicit switch statements.

It might be worth mentioning in the commit message.

>> ---
>>   drivers/gpu/drm/i915/intel_pm.c |   16 +++++++++++++++-
>>   1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>> index 0f4b46e..0a3b0b3 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -2902,7 +2902,21 @@ static void valleyview_enable_rps(struct drm_device *dev)
>>      GEN7_RC_CTL_TO_MODE);
>>
>>   valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS, &val);
>> -	dev_priv->mem_freq = 800 + (266 * (val >> 6) & 3);
>> +	switch ((val >> 6) & 3) {
>> +	case 0:
>> +	 dev_priv->mem_freq = 800;
>> +	 break;
>> +	case 1:
>> +	 dev_priv->mem_freq = 1066;
>> +	 break;
>> +	case 2:
>> +	 dev_priv->mem_freq = 1333;
>> +	 break;
>> +	case 3:
>> +	 DRM_ERROR("invalid mem freq, assuming 800MHz\n");
>> +	 dev_priv->mem_freq = 800;
>> +	 break;
>> +	}
>>   DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
>>
>>   DRM_DEBUG_DRIVER("GPLL enabled? %s\n", val & 0x10 ? "yes" : "no");
>
>
> I guess it doesn't handle the last case, but:
> dev_priv->mem_freq = 800 + (266 * (val))) + val/2

Don't use this method.  Presumably Ben meant (val >> 6) here, but even 
with that fix this formula returns 1067 rather than 1066, which is wrong.

> or
>
> u32 freqs[] = {800,1066,1333,800};
> dev_priv->mem_freq = freqs[(val >> 6) & 3];

I like this table based approach best.  It's much more succinct than the 
switch statement, and exact.  Might be worth preserving the DRM_ERROR.

> Are two ways I would have used before making a switch block :P
>
> Just a thought, but perhaps we don't want to enable RPS if we can't
> reliably figure out the memory freq. (case 3)
>
> Reviewed-by: Ben Widawsky <ben at bwidawsk.net>

For either the switch or Ben's table:
Reviewed-by: Kenneth Graunke <kenneth at whitecape.org>

Incidentally, my Punit returns 3 here, but I believe the memory is 
actually 1066.  Not sure what the deal is.

--Ken

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20130501/6f48cf52/attachment.html>


More information about the Intel-gfx mailing list