Quoting Michel Thierry (2017-11-10 23:42:31) > On 11/10/2017 12:51 PM, Chris Wilson wrote: > > Quoting Michel Thierry (2017-11-10 19:01:16) > >> Until Haswell/Baytrail, the hardware used to have a per engine fault > >> register (e.g. 0x4094 - render fault register, 0x4194 - media fault > >> register and so on). But since Broadwell, all these registers were > >> combined into a singe one and the engine id stored in bits 14:12. > >> > >> Not only we should not been reading (and writing to) registers that do > >> not exist, in platforms with VCS2 (SKL), the address that would belong > >> this engine (0x4494, VCS2_HW = 4) is already assigned to other register. > >> > >> References: IHD-OS-BDW-Vol 2c-11.15, page 75. > >> References: IHD-OS-SKL-Vol 2c-05.16, page 350. > >> Signed-off-by: Michel Thierry <michel.thierry@xxxxxxxxx> > >> --- > >> drivers/gpu/drm/i915/i915_gem_gtt.c | 38 ++++++++++++++++++++++++++++++----- > >> drivers/gpu/drm/i915/i915_gpu_error.c | 8 +++++--- > >> drivers/gpu/drm/i915/i915_reg.h | 2 ++ > >> 3 files changed, 40 insertions(+), 8 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c > >> index 1e40eeb31f9d..66a907330ad2 100644 > >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > >> @@ -2256,16 +2256,13 @@ static bool needs_idle_maps(struct drm_i915_private *dev_priv) > >> return IS_GEN5(dev_priv) && IS_MOBILE(dev_priv) && intel_vtd_active(); > >> } > >> > >> -void i915_check_and_clear_faults(struct drm_i915_private *dev_priv) > >> +void __check_and_clear_faults(struct drm_i915_private *dev_priv) > > > > I am amazed that -Wextra doesn't complain. Try with sparse. > > > > Hmm, no they didn't... gen6_check_and_clear_faults and > gen8_check_and_clear_faults are less controversial. The missing static and lack of extern declaration. I know sparse catches it, I guess for K&R the order is just right for it not to complain. > > There's an old thread where this was raised and how we are not clearing > > the faults early enough. > > Ah, I found that thread [1], and as you said there, right now the > for_each_engine is a nop (with this patch at least gen8+ would do the > right thing). > > Since gen6/gen7 engines are well known and can't change, do we really > need for_each_engine? For consistency, yeah it would be nice to keep for_each_engine. We should be ok to do the clear around i915_driver_init_mmio (it's mmio, it has to be there ;), maybe worth pulling it into intel_engines_init_mmio() or i915_gem_init_mmio(). I'm learning towards sanitization from within intel_engines_init_mmio() -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx