[Intel-gfx] [PATCH 01/18] drm/i915: Return more precise cdclk for gen2/3

Daniel Vetter daniel at ffwll.ch
Mon Nov 17 20:13:44 CET 2014


On Mon, Nov 17, 2014 at 09:02:11PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 17, 2014 at 07:44:30PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 17, 2014 at 04:43:35PM +0200, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > Fill out the lower three digits for gen2 and gen3 cdclk frqeuncy. It's
> > > not clear if these are accurate frquencies or just in the ballpark, but
> > > without docs this is the best we can do.
> > > 
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > Given that no one complained yet I'm not sure this is worth the trouble.
> > Otoh it's all below the 10% margin we have already anyway, so one big
> > wash ;-)
> 
> Yeah <1Mhz is a fairly small error here. But I still prefer to make the
> change, if only for consistency. Otherwise it'll keep bugging me and
> I'll have to keep fighting the urge to change it every time I see those
> numbers.

I fully approve of OCD urges ;-) Series overall looks really nifty, I
think it would be best to sign up a senior person from the vpg display
team for to review the details in this - maybe they remember some of the
old lore ...

And one aside for atomic: I guess we need a clocks_lock ww mutex to
protect any dynamic cdclock state. Same for shared dpll state too. This
will be fun to integrate, but since all the code that checks cdclock can
fail with -EINVAL already wiring up -EDEADLK shouldn't cause any fuzz.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list