> The issue is that if the regression is reproducible it means that the broadcast > mask is no longer correct (or never was, one or the other ;) And another w/a > is going astray because it depends on the previous undefined value of the > mcr. [Chiou, Cooper] I think we might focus on this w/a WaProgramMgsrForCorrectSliceSpecificMmioReads, this w/a is not only for CNL/ICL/TGL, but need to be applied in Gen9 as well. I'm ok to add wa_init_mcr() in gen9_gt_workarounds_init() as patch v1 to make it simple, and this patch can resolve Chrome VP8 hw encoding issue and no performance regression as well. > > Which raises the question as to whether the hang prevention seen here is > also because some other w/a (or other mmio) is not being applied to the > relevant units. Or vice versa. > > Either way there remains an underlying issue in that some register writes for > gen9 require mcr being set that were are not handling correctly. Changing the > mask here changing results elsewhere indicate that the issues are fully > addressed, and the fear that undoing some other mmio is going to introduce > other subtle hangs. And we are all blindly poking at the issue as no one has > access to the affected skus. > > What would be useful is if we print the value before changing it so that we > can see if we have any machines in CI where we are making significant > changes to the broadcast mask. > -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
