On Fri, Jul 05, 2013 at 12:51:54PM -0700, Ben Widawsky wrote: > On Fri, Jul 05, 2013 at 04:48:18PM +0300, ville.syrjala at linux.intel.com wrote: > > I was going over the workaround database with VLV mainly in mind, but I > > ended up stumbling on quite a few others as well. > > > > This series adds the workarounds names in a bunch of places where we > > missed them, adds a few workarounds we seem to have missed, drops some > > that were never supposed to be there, and drops quite a few pre-production > > workarounds. > > > > I'm not sure we want to drop some of the VLV workarounds quite yet. I know > > Jani will hate me when he comes back from vacation since his current machine > > would be affected. > > > > I've run these on my VLV and IVB machines, and didn't spot any problems. > > The SNB and HSW ones I've not actually tested. > > I have a sneaking suspicion at least a few of these will blow up once > their in the wild. You're trusting the docs an awful lot. At least the > patches seem quite bisectable though, so that's a saving grace. Yeah I wanted to keep them as isolated as possible just for that reason. > One thing which might be interesting/compelling is some performance data > (especially around places where you've removed unneeded workarounds). Some power consumption numbers migth be nice, since quite a few are clock gating related. There are plenty of options to deal with the risk: - Throw the patches away and pretend they never existed - Merge them all and watch out for fireworks - Drop a few of them into every kernel release to avoid too many regressions at once. I guess it'll take a few years get through the list this way. -- Ville Syrj?l? Intel OTC
