[Intel-gfx] [PATCH 05/12] drm/i915: Cache current cdclk frequency in dev_priv

[Ville Syrjälä]

On Thu, Apr 16, 2015 at 12:05:12PM +0100, Chris Wilson wrote:
> On Thu, Apr 16, 2015 at 01:51:43PM +0300, Mika Kahola wrote:
> > On Thu, 2015-04-16 at 09:02 +0100, Chris Wilson wrote:
> > > On Thu, Apr 16, 2015 at 10:40:51AM +0300, Mika Kahola wrote:
> > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > Rather that extracting the current cdclk freuqncy every time someone
> > > > wants to know it, cache the current value and use that. VLV/CHV already
> > > > stored a cached value there so just expand that to cover all platforms.
> > > > 
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > V2: Rebased to the latest
> > > > 
> > > > Signed-off-by: Mika Kahola <mika.kahola at intel.com>
> > > 
> > > Which debugfs file shows this? Do we have one for the similar clock freqs?
> > > -Chris
> > > 
> > 
> > I don't think we have one for cdclk. Then again, should we add this to
> > debugfs?
> 
> Is it useful to know? Yes, it people have added it to userspace tools.
> It it derived, or variable state that we may get wrong, or are other
> calculations dependent on it such that we will want to know its value to
> check the results? Yes.

Such a file should probably show the pch/hrawclk, czclk, and perhaps
memory clock too (or maybe we have that somewhere already?).

I've had plans to clean up the rawclk stuff too to resemble the cdclk
handling a bit more. The rawclk shouldn't change at runtime though,
so it should be mostly a search and replaec operation. Though we might
want to extract it for real on VLV/CHV from CCK rather than just
assuming the 100MHz (which it will be though). Similar thing could be
done for czclk as well.

-- 
Ville Syrjälä
Intel OTC