On Thu, Apr 07, 2016 at 01:37:35PM +0100, Chris Wilson wrote:
> On Thu, Apr 07, 2016 at 03:13:51PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 07, 2016 at 12:24:13PM +0100, Chris Wilson wrote:
> > > +static unsigned long calc_overflow_jiffies(struct drm_device *dev)
> > > {
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > + u32 overflow_ms;
> > > +
> > > + /* How many ticks per millisecond? */
> > > + if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > > + overflow_ms = ~0u / dev_priv->czclk_freq;
> >
> > Needs to account for the high range bit.
>
> This was the bit I was uncertain about. Does the high range bit imply
> that is a 24-bit register? Or that the freq is measured differently?
The hardware apparently has a 40bit counter internally. In low range
mode the register exposes bits [31:0] of the counter, in high range
you get to see bits [39:8].
>
> Judging by calc_residency() and assuming that the counter wraps at
> UINT32_MAX, this is still the right calcuations of when it does wrap
> irrespective of that bit. Hopefully just needs a tweak to freq?
>
> I hope we can just ignore the timer aspect of this patch, and if so then
> handling the 64bit emulation ourselves is also pointless...
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
