Re: [RFC] Runtime display PM for VLV/BYT

[Daniel Vetter <daniel@ffwll.ch>]

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