[Intel-gfx] [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.

Jesse Barnes jbarnes at virtuousgeek.org
Thu Nov 7 17:43:55 CET 2013


On Thu, 7 Nov 2013 16:01:50 +0200
Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:

> On Thu, Nov 07, 2013 at 09:49:55PM +0800, Lee, Chon Ming wrote:
> > On 11/07 14:46, Ville Syrjälä wrote:
> > > On Thu, Nov 07, 2013 at 03:23:26PM +0800, Chon Ming Lee wrote:
> > > > For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual
> > > > data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333.
> > > > 
> > > > Some premium VLV sku will get the DDR_DATA_RATE set as 11.  As a result,
> > > > the turbo frequency reporting will be incorrect without this workaround.
> > > 
> > > Does that mean that the original encoding we used was in fact correct,
> > > and the new one is not?
> > > 
> > 
> > The spec documents the encoding is 00b=800, 01b=1066, 10b=1333, 11b=invalid  
> 
> There was another encoding in some older spec. And we just changed from
> that to the current one.
> 
> > 
> > But after check with the punit owner, the 11b is refer to 1333 as well.  It is
> > not invalid anymore.
> 
> OK. In that case:
> 
> Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com>

Yeah and just for the record books, the old encoding was listed as 00 =
800, 01=800, 10=1066, 11=1333.  But apparently it's been shifted left,
with 11 staying as 1333.  So Chon Ming's patch looks ok.

I don't understand 2/2 though; was there a Punit HAS or Punit turbo HAS
update we missed?

-- 
Jesse Barnes, Intel Open Source Technology Center



More information about the Intel-gfx mailing list