This patchset intended to Add power-well api support for Haswell.
For Intel Haswell , “power well” in GPU has impact for both Display HD-A controller and codecs. Gfx driver has power well feature enaled but donot think much about audio side. The issue is if gfx driver disabled power well, audio side would lose power and crash.
David helped a initial patch to add external module patch_hdmi_i915, which built in only DRM_I915 and HDMI_CODEC enabled, This patchset was based on David’s work, thanks David!
As codec depends on controller’s power, so we removed the pm callback temporary. So only HDA controller driver would such need to request/release power, the codec will always be safe.
Gfx driver would shutdown power well in below cases, audio driver would be damaged as losing power totally without any notification. (There would be more cases not covered, welcome more comments here. i can verify the patchset under more cases) - Only eDP port active - HDMI monitor hot plug - System suspend
Also there’re some calling from i915 to disable power well from time to time, this patchset would reject those operations if audio using power well, but it will record i915 driver’s request and shut down power if audio release it.
Basically, here's the latest working status on my side:
I tested the power well feature on Haswell ULT board, there's only one eDP port used. Without this patch and we enabled power well feature, gfx driver will shutdown power well, audio driver will crash. Applied this patch, display audio driver will request power well on before initialize the card. In gfx side, it will enable power well.
Also power_save feature in audio side should be enabled, I set "5" second to let codec enter suspend when free for 5s long. Audio controller driver detects all codecs are suspended it will release power well and suspend too. Gfx driver will receive the request and shut down power well.
If user trigger some audio operations(cat codec# info), audio controller driver will request power well again...
If gfx side decided to disable power well now, while audio is in use, power well would be kept on.
(i will send out a documentation which has some logs and analysis there.)
Generally audio drvier will request power well on need and release it immediately after suspend. Gfx should make decision at his side.
The new introduced module "hda-i915" has dependency on i915, only built in when i915 enabled. So it's safe for call.
For non-Haswell platform, power well is no need atm. Even the module is built in wrongly, hda driver will not call the power well api. Also gfx will reject power well request at its side, so it's safe too.
This patch could make sure it would not cause damage when snd-hda-intel and i915 module loaded in any order. If i915 module loaded at first, it's safe to get the symbol. If snd-hda-intel loaded first, it will try to load i915 manually and get notification when the power-well api are exported.
Wang Xingchao (5): drm/915: Add private api for power well usage ALSA: hda - Add external module hda-i915 for power well ALSA: hda - Power well request/release for hda controller ALSA: hda - Fix module dependency with gfx i915 ALSA/i915: Check power well API existense before calling
drivers/gpu/drm/i915/i915_dma.c | 3 + drivers/gpu/drm/i915/intel_drv.h | 2 + drivers/gpu/drm/i915/intel_pm.c | 139 ++++++++++++++++++++++++++++++++++++-- include/drm/i915_powerwell.h | 40 +++++++++++ sound/pci/hda/Kconfig | 13 ++++ sound/pci/hda/Makefile | 6 ++ sound/pci/hda/hda_i915.c | 92 +++++++++++++++++++++++++ sound/pci/hda/hda_i915.h | 15 ++++ sound/pci/hda/hda_intel.c | 22 ++++++ 9 files changed, 325 insertions(+), 7 deletions(-) create mode 100644 include/drm/i915_powerwell.h create mode 100644 sound/pci/hda/hda_i915.c create mode 100644 sound/pci/hda/hda_i915.h