<div dir="ltr"><div>Hey Daniel,</div><div><br></div><div>Sorry for the long wait for a response, QE has been rather busy :)</div><div><br></div><div>This will be my first time contributing directly to an upstream project, so I may need some assistance with the whole process. I do think it would be good to write some tests explicitly for s2idle testing since some machines are shipped with both "deep" (this is S3, I believe) and "s2idle" supported as suspend states. s2idle is becoming more common on laptops being shipped so we do want to make sure this is covered. Some machines seem to support only s2idle and are dropping support for deep; I think that the regular suspend cases may still cover s2idle in this case specifically, so perhaps it makes sense to have some explicit cases for the alternate state on machines that support both, just some simple sanity checks to catch possible regressions and ensure suspend works in general.</div><div><br></div><div>I know we can blacklist tests when running IGT but I'm guessing under a typical use case, we don't want to blacklist anything by default in a regular test run, hence the worry about extra overhead. If this is incorrect & having some side set then we could blacklist the extra tests by default and only have them run as a set if the user chooses to specifically.</div><div><br></div><div>If you have any further advice or thoughts on this, please let me know! Just hoping to get working on this ASAP so I've got a solution in mind within the next few weeks.</div><div><br></div><div><br></div><div>Best regards,</div><div>-- Porygon<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 29, 2021 at 3:43 AM Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Jul 28, 2021 at 10:06 PM Lyude Paul <<a href="mailto:lyude@redhat.com" target="_blank">lyude@redhat.com</a>> wrote:<br>
> Hi! Recently one of my coworkers from QA (cc'd here) asked me about whether we<br>
> had any tests for s2idle in igt - to which I looked, didn't see anything that<br>
> looked like a match, and suggested that they consider contributing some tests<br>
> for it. Note that when I mention s2idle here, I'm thinking about systems which<br>
> support both s2idle and S3 - as I know that s2idle is already being used by<br>
> default for suspend/resume by igt on s2idle only systems.<br>
><br>
> This made me realize that we don't actually have any explicit suspend/resume<br>
> tests - we only have tests which handle testing other functionality across<br>
> suspend/resume. This seems like it makes sense for the most part, which brings<br>
> me to my real question here - would it be worth it to try adding s2idle<br>
> support for most igt tests, so that on s2idle/S3 hybrid systems both suspend<br>
> modes are tested individually for each suspend/resume test?<br>
<br>
If you really add it to all of them the runtime explosion is likely<br>
prohibitive. But a handful of explicit ones should be fine I guess.<br>
-Daniel<br>
<br>
> --<br>
> Cheers,<br>
>  Lyude Paul (she/her)<br>
>  Software Engineer at Red Hat<br>
><br>
> _______________________________________________<br>
> igt-dev mailing list<br>
> <a href="mailto:igt-dev@lists.freedesktop.org" target="_blank">igt-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/igt-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/igt-dev</a><br>
<br>
<br>
<br>
-- <br>
Daniel Vetter<br>
Software Engineer, Intel Corporation<br>
<a href="http://blog.ffwll.ch" rel="noreferrer" target="_blank">http://blog.ffwll.ch</a><br>
<br>
</blockquote></div>