[alsa-devel] [PATCH 0/5] Power-well API implementation for Haswell

[Wang Xingchao]

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

-- 
1.7.9.5