On Wed, Dec 10, 2014 at 10:35:37PM +0200, Ville Syrjälä wrote: > On Wed, Dec 10, 2014 at 12:16:05PM -0800, Jesse Barnes wrote: > > Should probably just init this in the GMbus code all the time, based on > > the cdclk and HPLL like we do on newer platforms. Ville has code for > > that in a rework branch, but until then we can fix this bug fairly > > easily. > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=76301 > > Signed-off-by: Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> > > My cdclk extraction code doesn't seem to agree with this register for > this particular bug reporter at least. So I think I need to go double > check my code. The other options are that GMBUS clock isn't derived from > cdclk on that platform, or that the HPLL/cdclk bits in configdb are > simply not valid for this particular chipset. > > In the meantime however, we can at least get some machines working with > this patch. I'm not entirely sure which platforms have this register, > but IS_GEN4() looks safe enough since my 946GZ has it and the reporter > has a G41. Yeah I really don't like the save/restore_state functions since they just bash registers without any regard to ordering constraints and stuff. I guess your cdclk series will address this? - At least we have the vlv_update_cdclk sprinkled all over already, probably better to call the intel_i2c_update_cdlk and move it to intel_i2c.c, too. -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
