At Fri, 03 May 2013 14:02:04 +0200, David Henningsson wrote:
On 05/03/2013 10:28 AM, Wang, Xingchao wrote:
Hi David,
Thank you very much for your draft patch. I have some more work on a new patchset, some ideas are from your patch.
Thanks.
Here's a brief introduction of attached patchset:
- a new bus type in /sound/had_bus.c, used to bind the single module and codec device
It looks like ac97_bus.c
I don't understand why this is needed. It does not look like it's used from the gfx side either, or anything like that?
add a new device node in "struct hda_codec", it's used to register for new bus type.
a new single module hdmi_i915, which compiled in only when DRM_I915 and CODEC_HDMI enabled.
It stores the private API for gfx part. There's no support to probe haswell hdmi codec only yet. Power well will be used only for haswell display audio.
- power well API implementation in gfx side.
Please feel free to add your idea and I will help test your patch too.
Ok. So the patch I wrote would (if it works) be combined with your patch 3, which implements the gfx side. The gfx side is not my area of expertise.
The proposed way in my patch would be more elegant since it does not introduce any i915 related code in hda_codec* files.
Still, Takashi is the boss here so he has the final say :-)
Indeed. If the reference to power well API is limited in a newly split snd-hda-codec-hdmi-i915 driver, we don't have to create yet another driver instance. The snd-hda-codec-hdmi-i915 can simply depend on i915, by referring to a symbol exported from i915 driver.
If we now touch the whole PM sequence in both gfx and audio drivers (i.e. it influences on the HD-audio controller code, hda_intel.c), then we may need a different management. But I thought it's not yet discussed here, right?
Takashi