On Mon, Jun 15, 2015 at 04:18:22PM +0100, Chris Wilson wrote:
> On Mon, Jun 15, 2015 at 05:14:17PM +0200, Daniel Vetter wrote:
> > It's simply a bit too scary on pre-gen6 and imo not worth the bother
> > really until someone starts to implement all the hacks an w/a required
> > on these platforms. On later platforms the issues are just with
> > correctness and performance hence no risk for hanging machines.
> >
> > Cc: Paulo Zanoni <przanoni@xxxxxxxxx>
> > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
> > ---
> > tests/kms_fbc_crc.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
> > index d9642243465c..f2a86a690767 100644
> > --- a/tests/kms_fbc_crc.c
> > +++ b/tests/kms_fbc_crc.c
> > @@ -562,7 +562,8 @@ igt_main
> > igt_require_f(!strstr(buf, "unsupported on this chipset"),
> > "FBC not supported\n");
> >
> > - igt_set_module_param_int("enable_fbc", 1);
> > + if (intel_gen(data.devid) >= 6)
> > + igt_set_module_param_int("enable_fbc", 1);
>
> That reminds me, using these module params causes lots of "dangerous
> module option" spew. Which I think is justified! However, the
> alternatives would be either a SETPARAM ioctl or debugfs.
Hm right. I guess Paulo's module option support should be changed to not
touch the module option if it already has the desired value. Otherwise the
testcases will always have dmesg-warn as their result state, even when the
support is enabled and the test works correctly. But we can't just look at
the current setting since -1 doesn't tell us whether fbc is enabled or
not. And adding debugfs knobs for all of these is exactly what Paulo's
tried to avoid here.
I guess we need to reconsider this all a bit more :(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
