Hi Jesse, > -----Original Message----- > From: Barnes, Jesse > Sent: Friday, May 10, 2013 2:30 AM > To: Takashi Iwai > Cc: Daniel Vetter; Wang, Xingchao; david.henningsson at canonical.com; > Girdwood, Liam R; Li, Jocelyn; Lin, Mengdong; Zanoni, Paulo R; Wang Xingchao; > intel-gfx; alsa-devel at alsa-project.org > Subject: Re: [RFC PATCH 1/3] drm/915: Add private api for power well usage > > On Thu, 9 May 2013 19:17:36 +0200 > Takashi Iwai <tiwai at suse.de> wrote: > > > At Thu, 9 May 2013 11:23:21 +0200, > > Daniel Vetter wrote: > > > > > > 2. On a quick read of the hda driver stuff I don't think the power > > > well enable/disable places are at the right spot: We force the power > > > well on whenever the hda codec is used, but we must only do that > > > when we want to output audio to external screens. And since that > > > state transition can only really happen due to a modeset change on > > > the gfx side I don't think we need any autosuspend delays either. > > > > > > The use-case I'm thinking of is media playback with just the panel > > > enabled: In that case we can switch off the power well on the > > > display side, and I don't think the power well is required for audio > > > play back on the integrated speakerrs/headphone-jack either. > > > > Well, in the case of Haswell, the audio controller/codec is dedicated > > to only HDMI audio, and in the audio driver level, the power saving of > > each codec/controller chip is managed individually. So, it's not that > > bad to handle power well on/off at that point. A sane power-conscious > > OS would open/close the audio device file in a fine grained way. > > So hda_intel and the azx_suspend/resume functions will only be called for > HDMI audio on HSW? If so, then I guess this patch has the calls in the right > places. Well not, hda_intel and azx_suspend/resume is more generic call. But it has no impact for non-HSW platform. Since power-well requirement must be done at very early stage for HD-audio controller, so it happened at very high level. For non-HSW platform, the external module should no built in at first. Given it could call into gfx side, no power-well change happen there. > > If it's going to force the power well on for non-HDMI audio, then I think we'll > need some additional changes. For non-HDMI audio, it's in non HSW HD-Audio controller, so it should be safe. So the patchset intend to work only for Haswell HD-audio controller and codecs. > > > > > > 3. The moduel depencies seem to still not work out dynamically, at > > > least I think we still have a hard chain between hda-intel and > > > i915.ko (just with one thing in between now). > > > > True. > > > > The question is in which level we need power_well_*() controls. > > If the initialization of HD-audio controller (e.g. PCI registers) > > requires the power well on, hda_intel.c requires the calls, as this > > patch does. OTOH, if it's only about the HD-audio verbs, basically we > > can push the power well calls into the codec driver, i.e. > > patch_hdmi.c. In the latter case, as David once suggested, we can > > split the Haswell codec driver from patch_hdmi.c so that only the new > > driver depends on i915. > > I think it's needed for the HDMI related MMIO regs as well, but I don't have a > platform to test and make sure. That's true. The probing sound card would fail if there's no power-well enabled, we say in such case: Boot up with no hdmi cable connected --> gfx disable power-well --> haswell audio probe fail. Thanks --xingchao
