* [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.
@ 2013-11-07 7:23 Chon Ming Lee
2013-11-07 7:23 ` [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value Chon Ming Lee
2013-11-07 12:46 ` [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333 Ville Syrjälä
0 siblings, 2 replies; 11+ messages in thread
From: Chon Ming Lee @ 2013-11-07 7:23 UTC (permalink / raw)
To: intel-gfx
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.
2013-11-07 7:23 [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333 Chon Ming Lee
@ 2013-11-07 7:23 ` Chon Ming Lee
2013-11-07 14:21 ` Ville Syrjälä
2013-11-07 16:54 ` Jesse Barnes
2013-11-07 12:46 ` [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333 Ville Syrjälä
1 sibling, 2 replies; 11+ messages in thread
From: Chon Ming Lee @ 2013-11-07 7:23 UTC (permalink / raw)
To: intel-gfx
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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.
2013-11-07 7:23 [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333 Chon Ming Lee
2013-11-07 7:23 ` [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value Chon Ming Lee
@ 2013-11-07 12:46 ` Ville Syrjälä
2013-11-07 13:49 ` Lee, Chon Ming
1 sibling, 1 reply; 11+ messages in thread
From: Ville Syrjälä @ 2013-11-07 12:46 UTC (permalink / raw)
To: Chon Ming Lee; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.
2013-11-07 12:46 ` [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333 Ville Syrjälä
@ 2013-11-07 13:49 ` Lee, Chon Ming
2013-11-07 14:01 ` Ville Syrjälä
0 siblings, 1 reply; 11+ messages in thread
From: Lee, Chon Ming @ 2013-11-07 13:49 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.
2013-11-07 13:49 ` Lee, Chon Ming
@ 2013-11-07 14:01 ` Ville Syrjälä
2013-11-07 14:19 ` Daniel Vetter
2013-11-07 16:43 ` Jesse Barnes
0 siblings, 2 replies; 11+ messages in thread
From: Ville Syrjälä @ 2013-11-07 14:01 UTC (permalink / raw)
To: Lee, Chon Ming; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.
2013-11-07 14:01 ` Ville Syrjälä
@ 2013-11-07 14:19 ` Daniel Vetter
2013-11-07 16:43 ` Jesse Barnes
1 sibling, 0 replies; 11+ messages in thread
From: Daniel Vetter @ 2013-11-07 14:19 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.
2013-11-07 7:23 ` [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value Chon Ming Lee
@ 2013-11-07 14:21 ` Ville Syrjälä
[not found] ` <20131107143506.GF2637@clee30-mobl2.gar.corp.intel.com>
2013-11-07 16:54 ` Jesse Barnes
1 sibling, 1 reply; 11+ messages in thread
From: Ville Syrjälä @ 2013-11-07 14:21 UTC (permalink / raw)
To: Chon Ming Lee; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.
[not found] ` <20131107143506.GF2637@clee30-mobl2.gar.corp.intel.com>
@ 2013-11-07 14:36 ` Lee, Chon Ming
0 siblings, 0 replies; 11+ messages in thread
From: Lee, Chon Ming @ 2013-11-07 14:36 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.
2013-11-07 14:01 ` Ville Syrjälä
2013-11-07 14:19 ` Daniel Vetter
@ 2013-11-07 16:43 ` Jesse Barnes
1 sibling, 0 replies; 11+ messages in thread
From: Jesse Barnes @ 2013-11-07 16:43 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.
2013-11-07 7:23 ` [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value Chon Ming Lee
2013-11-07 14:21 ` Ville Syrjälä
@ 2013-11-07 16:54 ` Jesse Barnes
2013-11-07 16:55 ` Daniel Vetter
1 sibling, 1 reply; 11+ messages in thread
From: Jesse Barnes @ 2013-11-07 16:54 UTC (permalink / raw)
To: Chon Ming Lee; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value.
2013-11-07 16:54 ` Jesse Barnes
@ 2013-11-07 16:55 ` Daniel Vetter
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Vetter @ 2013-11-07 16:55 UTC (permalink / raw)
To: Jesse Barnes; +Cc: intel-gfx
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2013-11-07 16:55 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-07 7:23 [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333 Chon Ming Lee
2013-11-07 7:23 ` [PATCH 2/2] drm/i915/vlv: For i915_cur_delayinfo, the max frequency reporting wrong value Chon Ming Lee
2013-11-07 14:21 ` Ville Syrjälä
[not found] ` <20131107143506.GF2637@clee30-mobl2.gar.corp.intel.com>
2013-11-07 14:36 ` Lee, Chon Ming
2013-11-07 16:54 ` Jesse Barnes
2013-11-07 16:55 ` Daniel Vetter
2013-11-07 12:46 ` [PATCH 1/2] drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333 Ville Syrjälä
2013-11-07 13:49 ` Lee, Chon Ming
2013-11-07 14:01 ` Ville Syrjälä
2013-11-07 14:19 ` Daniel Vetter
2013-11-07 16:43 ` Jesse Barnes
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.