[Intel-gfx] Power well issue could not be reproduced with drm-intel-next branch

Wang, Xingchao xingchao.wang at intel.com
Mon Apr 22 16:21:10 CEST 2013


Hi Daniel/Paulo,

In order to verify an RFC patch to fix the power well issue, I'm trying to reproduce it on my Haswell ULT C stepping board, with " drm-intel-next" branch, the last commit is:

commit 80ad9206c0d863832bc5f6008c4d1868d1df8e70
Author: Ville Syrjälä <ville.syrjala at linux.intel.com>
Date:   Fri Apr 19 14:36:51 2013 +0300

The test step is:
1) echo 1 > /sys/module/i915/parameters/disable_power_well
2) echo mem > /sys/power/state
3) press any key or power button to resume system
4) check Haswell hdmi codec status

At step 2), I cannot suspend the whole system successfully on Haswell ULT C stepping board, the CPU fan is always running.
At step 3), I could see resume message for i915 module, but there's one warning as below:
[  172.755762] [drm:intel_ddi_put_crtc_pll], Disabling WRPLL 1
[  172.755764] ------------[ cut here ]------------
[  172.755805] WARNING: at drivers/gpu/drm/i915/intel_ddi.c:781 intel_ddi_put_crtc_pll+0x293/0x2a0 [i915]()
[  172.755807] Hardware name: Shark Bay Client platform
[  172.755853] Modules linked in: rfcomm bnep bluetooth parport_pc ppdev snd_hda_codec_hdmi coretemp kvm_intel kvm i915 snd_hda_intel snd_hda_codec ghash_clmulni_intel aesni_intel snd_hwdep ablk_helper cryptd snd_pcm lrw aes_x86_64 drm_kms_helper xts gf128mul snd_seq_midi drm snd_rawmidi snd_seq_midi_event hid_generic snd_seq usbhid microcode e1000e asix snd_timer i2c_algo_bit hid snd_seq_device usbnet video snd serio_raw mac_hid lpc_ich ptp soundcore snd_page_alloc pps_core lp parport
[  172.755857] Pid: 2431, comm: kworker/u:13 Tainted: G        W    3.9.0-rc5-daniel-force-pin+ #195
[  172.755859] Call Trace:
[  172.755873]  [<ffffffff81058faf>] warn_slowpath_common+0x7f/0xc0
[  172.755881]  [<ffffffff8105900a>] warn_slowpath_null+0x1a/0x20
[  172.755907]  [<ffffffffa0274c03>] intel_ddi_put_crtc_pll+0x293/0x2a0 [i915]
[  172.755930]  [<ffffffffa0274c5e>] intel_ddi_pll_mode_set+0x4e/0x3c0 [i915]
[  172.755947]  [<ffffffffa023ec9c>] ? ivybridge_enable_vblank+0x2c/0x80 [i915]
[  172.755971]  [<ffffffffa026ae88>] haswell_crtc_mode_set+0x138/0x540 [i915]
[  172.755994]  [<ffffffffa0264d9b>] __intel_set_mode+0x68b/0xd50 [i915]
[  172.756017]  [<ffffffffa026f181>] intel_modeset_setup_hw_state+0x6f1/0xa30 [i915]
[  172.756031]  [<ffffffffa0237287>] __i915_drm_thaw+0x127/0x1c0 [i915]
[  172.756045]  [<ffffffffa02377ac>] i915_resume+0x7c/0xd0 [i915]
[  172.756059]  [<ffffffffa0237816>] i915_pm_resume+0x16/0x20 [i915]
[  172.756069]  [<ffffffff8136613e>] pci_pm_resume+0x7e/0xe0
[  172.756074]  [<ffffffff813660c0>] ? pci_pm_thaw+0x80/0x80
[  172.756083]  [<ffffffff81443bdb>] dpm_run_callback.isra.4+0x3b/0x80
[  172.756089]  [<ffffffff81443ed4>] device_resume+0xd4/0x1b0
[  172.756095]  [<ffffffff81443fd1>] async_resume+0x21/0x50
[  172.756102]  [<ffffffff8108476b>] async_run_entry_fn+0x3b/0x140
[  172.756108]  [<ffffffff8107792b>] process_one_work+0x16b/0x400
[  172.756113]  [<ffffffff810785b8>] worker_thread+0x118/0x360
[  172.756118]  [<ffffffff810784a0>] ? manage_workers+0x350/0x350
[  172.756124]  [<ffffffff8107db00>] kthread+0xc0/0xd0
[  172.756131]  [<ffffffff8107da40>] ? flush_kthread_worker+0xb0/0xb0
[  172.756137]  [<ffffffff816b60ec>] ret_from_fork+0x7c/0xb0
[  172.756143]  [<ffffffff8107da40>] ? flush_kthread_worker+0xb0/0xb0
[  172.756146] ---[ end trace e203505bded24940 ]---
[  172.756150] [drm:intel_ddi_pll_mode_set], Using WRPLL 1 on pipe A

Did you notice the same warning there? Does it has impact on the power well feature?

At step 4), the codec info still exist, means the power well issue could not reproduced. It seems power for display audio was not
removed during suspend. Could someone clarify me which commit do that?
If I revert commits back to Paulo's below commit:

commit 2124b72e6283c4e84a55e71077fee91793f4c801
Author: Paulo Zanoni <paulo.r.zanoni at intel.com>
Date:   Fri Mar 22 14:07:23 2013 -0300

Repeat same steps, at step 4), the codec info crashed and there're many spurious irq in audio part, that means the display audio
power was removed during suspend.

thanks
--xingchao





More information about the Intel-gfx mailing list