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: > > > > 1. 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? > > > 2. add a new device node in "struct hda_codec", it's used to register for new bus type. > > > > 3. 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. > > > > 4. 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
