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@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
