On Mon, Oct 14, 2013 at 04:07:44PM -0700, Jesse Barnes wrote: > 5) more testing - I think the load time ref is still busted here and > on HSW I've chatted quite a bit yesterday with Paulo about how we can test runtime pm better, since he wanted to get started with testing D3 while vpg is cooking up the kernel support for this. For general tests that stuff works I've suggested to pimp the existing pc8.c testcase and duplicate all the subtests we have there over all the fancy runtime pm features we'll get. So for (pm_method in pc8, vlv_power_well, D3, ..) for (subtest) do_subtest(pm_method) The pm_method would encapsulate stuff like getting in/out of that state and checking that we indeed have residency. All the functional tests could then be shared (i2c, gpu workloads, ...). Even more important once we stumble over bugs and need new test scenarios. The other thing is static register setup. Atm we set up registers after boot, on resume and (in parts at least) after gpu reset, and we already have bug reports to prove that this is too complicated for us to get right. Adding D3 and tons other things will make it even more fun. The problem isn't really the static set of w/as in the ->init_clock_gating vfuncs, but all the bits and pieces splattered all over the driver: - w/a which are someplace else due to ordering constraints (e.g. the ring specific w/a can't be done in init_clock_gating since the ring enabling will clear them again) - static register setup which is someplace else for better code structure (e.g. the ddi buffer translation table setup) Paulo's idea is to convert the w/a list in init_clock_gating into a table and also add all the other registers in there but marked with a special bit saying that those workarounds/settings shouldn't be applied in in the init_clock_gating code. Then we could scan this table at the usual places and check the hw state (e.g. after each modeset with all the other modeset state). The upshot compared to doing this in userspace (Eric started such a tool in i-g-t/tools/intel_reg_checker) is that we won't have a synchronization problem between two codebases. Imo the more dynamic state is already sufficiently locked down with all our asserts and state cross-checks plus the functional checks from pc8.c Cheers, 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
