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@xxxxxxxxxxxxxxx> > > > > > > > > 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@xxxxxxxxxxxxxxx> > > > > > > > > V2: Rebased to the latest > > > > > > > > Signed-off-by: Mika Kahola <mika.kahola@xxxxxxxxx> > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
