<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - [CI][BAT] igt@pm_rpm@(module-reload|basic-rte) - fail - Failed assertion: setup_environment()"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=108800#c7">Comment # 7</a>
              on <a class="bz_bug_link 
          bz_status_ASSIGNED "
   title="ASSIGNED - [CI][BAT] igt@pm_rpm@(module-reload|basic-rte) - fail - Failed assertion: setup_environment()"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=108800">bug 108800</a>
              from <span class="vcard"><a class="email" href="mailto:vanshidhar.r.konda@intel.com" title="Vanshidhar Konda <vanshidhar.r.konda@intel.com>"> <span class="fn">Vanshidhar Konda</span></a>
</span></b>
        <pre>Is there something that (In reply to Imre Deak from <a href="show_bug.cgi?id=108800#c5">comment #5</a>)
<span class="quote">> (In reply to Vanshidhar Konda from <a href="show_bug.cgi?id=108800#c4">comment #4</a>)
> > This test seems to fail mostly on the BSW and BYT systems. Here's the
> > observations I've made so far:
> > 
> > 1) The kernel device usage count for suspending the device is higher (+1) in
> > the failed execution of the test than the successful execution.
> > 
> > 2) When the test disables all screens (through modeset) power-wells in the
> > display domain are being turned off - except the display and always-on
> > power-wells.
> > 
> > 3) In the failed case, there is a difference in the wakeref acquire/release
> > log. The following wakerefs don't happen for the successful executions.
> > Wakeref last acquired:
> >    intel_display_power_get+0x18/0x50 [i915]
> >    intel_power_domains_init_hw+0x90/0x500 [i915]
> >    intel_power_domains_resume+0x3d/0x70 [i915]
> >    i915_pm_resume_early+0x9d/0x130 [i915]
> >    dpm_run_callback+0x64/0x280
> >    device_resume_early+0xa6/0xe0
> >    async_resume_early+0x14/0x40
> >    async_run_entry_fn+0x34/0x160
> > Wakeref last released:
> >    i915_drm_suspend_late+0xad/0x120 [i915]
> >    dpm_run_callback+0x64/0x280
> >    __device_suspend_late+0xad/0x140
> >    async_suspend_late+0x15/0x90
> >    async_run_entry_fn+0x34/0x160
> >    process_one_work+0x245/0x610
> >    worker_thread+0x37/0x380
> >    kthread+0x119/0x130
> > 
> > Possible reasons for failure:
> > The display and always-on power-wells have a higher reference count than the
> > rest of the power-wells in the display domain.
> > 
> > Next steps:
> > 1) Confirm that the reference count on display and always-on power-wells is
> > different between test fail/success case.
> > 2) If confirmed, try to figure out the reason for extra reference count on
> > the power-wells in question.

> This could be due to the audio driver not suspending.

> Could you provide the contents of
> /sys/kernel/debug/dri/0/i915_power_domain_info after all screen gets
> disabled (with runtime PM enabled for both the i915 and the audio driver)?</span >

On the CI systems it seems like runtime PM is enabled for i915. How can I
setup/check if runtime PM is enabled for the audio driver?</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>