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

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

[Chon Ming Lee]

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.

Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index a5778e5..13fb7f8 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5328,12 +5328,7 @@ static void valleyview_init_clock_gating(struct drm_device *dev)
 		dev_priv->mem_freq = 1333;
 		break;
 	case 3:
-		/*
-		 * Probably a BIOS/Punit bug, or a new platform we don't
-		 * support yet.
-		 */
-		WARN(1, "invalid DDR freq detected, assuming 800MHz\n");
-		dev_priv->mem_freq = 800;
+		dev_priv->mem_freq = 1333;
 		break;
 	}
 	DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
-- 
1.7.7.6

[PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.

[Chon Ming Lee]

The max frequency reporting is not correct.  But there is already an existing
valleyview_rps_max_freq and valleyview_rps_min_freq to get the
frequency.  Use that for i915_cur_delayinfo.

Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
---
 drivers/gpu/drm/i915/i915_debugfs.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
index cae3e9c..5254d95 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -972,11 +972,11 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused)
 		seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts);
 		seq_printf(m, "DDR freq: %d MHz\n", dev_priv->mem_freq);
 
-		val = vlv_punit_read(dev_priv, PUNIT_FUSE_BUS1);
+		val = valleyview_rps_max_freq(dev_priv);
 		seq_printf(m, "max GPU freq: %d MHz\n",
 			   vlv_gpu_freq(dev_priv->mem_freq, val));
 
-		val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_LFM);
+		val = valleyview_rps_min_freq(dev_priv);
 		seq_printf(m, "min GPU freq: %d MHz\n",
 			   vlv_gpu_freq(dev_priv->mem_freq, val));
 
-- 
1.7.7.6

Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.

[Ville Syrjälä]

On Thu, Nov 07, 2013 at 03:23:27PM +0800, Chon Ming Lee wrote:
> The max frequency reporting is not correct.  But there is already an existing
> valleyview_rps_max_freq and valleyview_rps_min_freq to get the
> frequency.  Use that for i915_cur_delayinfo.
> 
> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index cae3e9c..5254d95 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -972,11 +972,11 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused)
>  		seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts);
>  		seq_printf(m, "DDR freq: %d MHz\n", dev_priv->mem_freq);
>  
> -		val = vlv_punit_read(dev_priv, PUNIT_FUSE_BUS1);
> +		val = valleyview_rps_max_freq(dev_priv);

I'm not actually sure about the NC freq stuff. Not sure where that is
even documented. The punit turbo HAS tells us to read the max and
guaranteed freqs from PUNIT_FUSE_BUS1. Maybe we should actually
change valleyview_rps_max_freq() and valleyview_rps_rpe_freq() to
read them from PUNIT_FUSE_BUS1?

>  		seq_printf(m, "max GPU freq: %d MHz\n",
>  			   vlv_gpu_freq(dev_priv->mem_freq, val));
>  
> -		val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_LFM);
> +		val = valleyview_rps_min_freq(dev_priv);

This one is the same register, just with masking, so this change looks
OK. And it matches the punit turbo HAS.

>  		seq_printf(m, "min GPU freq: %d MHz\n",
>  			   vlv_gpu_freq(dev_priv->mem_freq, val));
>  
> -- 
> 1.7.7.6
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.

[Lee, Chon Ming]

Cc back the the mailing list.

On 11/07 22:35, Lee, Chon Ming wrote:
> On 11/07 16:21, Ville Syrjälä wrote:
> > On Thu, Nov 07, 2013 at 03:23:27PM +0800, Chon Ming Lee wrote:
> > > The max frequency reporting is not correct.  But there is already an existing
> > > valleyview_rps_max_freq and valleyview_rps_min_freq to get the
> > > frequency.  Use that for i915_cur_delayinfo.
> > > 
> > > Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c |    4 ++--
> > >  1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index cae3e9c..5254d95 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -972,11 +972,11 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused)
> > >  		seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts);
> > >  		seq_printf(m, "DDR freq: %d MHz\n", dev_priv->mem_freq);
> > >  
> > > -		val = vlv_punit_read(dev_priv, PUNIT_FUSE_BUS1);
> > > +		val = valleyview_rps_max_freq(dev_priv);
> > 
> > I'm not actually sure about the NC freq stuff. Not sure where that is
> > even documented. The punit turbo HAS tells us to read the max and
> > guaranteed freqs from PUNIT_FUSE_BUS1. Maybe we should actually
> > change valleyview_rps_max_freq() and valleyview_rps_rpe_freq() to
> > read them from PUNIT_FUSE_BUS1?
> 
> The document is not correct.  I remember few months back during email exchange
> with the punit owner on how to get the max frequency, the correct way is to read
> from the NC Fuse.  Jesse is in the loop, which I believe he created the patch for
> valleyview_rps_max_freq.  
> 
> Regards,
> Chon Ming
> > 
> > >  		seq_printf(m, "max GPU freq: %d MHz\n",
> > >  			   vlv_gpu_freq(dev_priv->mem_freq, val));
> > >  
> > > -		val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_LFM);
> > > +		val = valleyview_rps_min_freq(dev_priv);
> > 
> > This one is the same register, just with masking, so this change looks
> > OK. And it matches the punit turbo HAS.
> > 
> > >  		seq_printf(m, "min GPU freq: %d MHz\n",
> > >  			   vlv_gpu_freq(dev_priv->mem_freq, val));
> > >  
> > > -- 
> > > 1.7.7.6
> > > 
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC

Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.

[Jesse Barnes]

On Thu,  7 Nov 2013 15:23:27 +0800
Chon Ming Lee <chon.ming.lee@intel.com> wrote:

> The max frequency reporting is not correct.  But there is already an existing
> valleyview_rps_max_freq and valleyview_rps_min_freq to get the
> frequency.  Use that for i915_cur_delayinfo.
> 
> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> index cae3e9c..5254d95 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -972,11 +972,11 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused)
>  		seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts);
>  		seq_printf(m, "DDR freq: %d MHz\n", dev_priv->mem_freq);
>  
> -		val = vlv_punit_read(dev_priv, PUNIT_FUSE_BUS1);
> +		val = valleyview_rps_max_freq(dev_priv);
>  		seq_printf(m, "max GPU freq: %d MHz\n",
>  			   vlv_gpu_freq(dev_priv->mem_freq, val));
>  
> -		val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_LFM);
> +		val = valleyview_rps_min_freq(dev_priv);
>  		seq_printf(m, "min GPU freq: %d MHz\n",
>  			   vlv_gpu_freq(dev_priv->mem_freq, val));
>  

Ok yeah this is just ancient.  It never got fixed up when the other
bits were added.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.

[Daniel Vetter]

On Thu, Nov 07, 2013 at 08:54:00AM -0800, Jesse Barnes wrote:
> On Thu,  7 Nov 2013 15:23:27 +0800
> Chon Ming Lee <chon.ming.lee@intel.com> wrote:
> 
> > The max frequency reporting is not correct.  But there is already an existing
> > valleyview_rps_max_freq and valleyview_rps_min_freq to get the
> > frequency.  Use that for i915_cur_delayinfo.
> > 
> > Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c
> > index cae3e9c..5254d95 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -972,11 +972,11 @@ static int i915_cur_delayinfo(struct seq_file *m, void *unused)
> >  		seq_printf(m, "PUNIT_REG_GPU_FREQ_STS: 0x%08x\n", freq_sts);
> >  		seq_printf(m, "DDR freq: %d MHz\n", dev_priv->mem_freq);
> >  
> > -		val = vlv_punit_read(dev_priv, PUNIT_FUSE_BUS1);
> > +		val = valleyview_rps_max_freq(dev_priv);
> >  		seq_printf(m, "max GPU freq: %d MHz\n",
> >  			   vlv_gpu_freq(dev_priv->mem_freq, val));
> >  
> > -		val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_LFM);
> > +		val = valleyview_rps_min_freq(dev_priv);
> >  		seq_printf(m, "min GPU freq: %d MHz\n",
> >  			   vlv_gpu_freq(dev_priv->mem_freq, val));
> >  
> 
> Ok yeah this is just ancient.  It never got fixed up when the other
> bits were added.
> 
> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Ville Syrjälä]

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?

> 
> Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_pm.c |    7 +------
>  1 files changed, 1 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index a5778e5..13fb7f8 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5328,12 +5328,7 @@ static void valleyview_init_clock_gating(struct drm_device *dev)
>  		dev_priv->mem_freq = 1333;
>  		break;
>  	case 3:
> -		/*
> -		 * Probably a BIOS/Punit bug, or a new platform we don't
> -		 * support yet.
> -		 */
> -		WARN(1, "invalid DDR freq detected, assuming 800MHz\n");
> -		dev_priv->mem_freq = 800;
> +		dev_priv->mem_freq = 1333;
>  		break;
>  	}
>  	DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
> -- 
> 1.7.7.6
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

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

[Lee, Chon Ming]

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  

But after check with the punit owner, the 11b is refer to 1333 as well.  It is
not invalid anymore.

> > 
> > Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c |    7 +------
> >  1 files changed, 1 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index a5778e5..13fb7f8 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5328,12 +5328,7 @@ static void valleyview_init_clock_gating(struct drm_device *dev)
> >  		dev_priv->mem_freq = 1333;
> >  		break;
> >  	case 3:
> > -		/*
> > -		 * Probably a BIOS/Punit bug, or a new platform we don't
> > -		 * support yet.
> > -		 */
> > -		WARN(1, "invalid DDR freq detected, assuming 800MHz\n");
> > -		dev_priv->mem_freq = 800;
> > +		dev_priv->mem_freq = 1333;
> >  		break;
> >  	}
> >  	DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
> > -- 
> > 1.7.7.6
> > 
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC

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

[Ville Syrjälä]

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@linux.intel.com>

> 
> > > 
> > > Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_pm.c |    7 +------
> > >  1 files changed, 1 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > > index a5778e5..13fb7f8 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -5328,12 +5328,7 @@ static void valleyview_init_clock_gating(struct drm_device *dev)
> > >  		dev_priv->mem_freq = 1333;
> > >  		break;
> > >  	case 3:
> > > -		/*
> > > -		 * Probably a BIOS/Punit bug, or a new platform we don't
> > > -		 * support yet.
> > > -		 */
> > > -		WARN(1, "invalid DDR freq detected, assuming 800MHz\n");
> > > -		dev_priv->mem_freq = 800;
> > > +		dev_priv->mem_freq = 1333;
> > >  		break;
> > >  	}
> > >  	DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
> > > -- 
> > > 1.7.7.6
> > > 
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC

-- 
Ville Syrjälä
Intel OTC

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

[Daniel Vetter]

On Thu, Nov 07, 2013 at 04:01:50PM +0200, Ville Syrjälä 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@linux.intel.com>

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

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

[Jesse Barnes]

On Thu, 7 Nov 2013 16:01:50 +0200
Ville Syrjälä <ville.syrjala@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@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx