[Intel-gfx] [PATCH 4/4] ALSA: hda - Wake the codec up on pin/ELD notify events

[Takashi Iwai]

On Wed, 02 Sep 2015 10:00:44 +0200,
Daniel Vetter wrote:
> 
> On Fri, Aug 28, 2015 at 04:10:36PM +0300, Jani Nikula wrote:
> > On Thu, 20 Aug 2015, Takashi Iwai <tiwai at suse.de> wrote:
> > > On Thu, 20 Aug 2015 11:41:42 +0200,
> > > David Henningsson wrote:
> > >> 
> > >> 
> > >> 
> > >> On 2015-08-20 11:28, Takashi Iwai wrote:
> > >> > On Wed, 19 Aug 2015 10:48:58 +0200,
> > >> > David Henningsson wrote:
> > >> >>
> > >> >> Whenever there is an event from the i915 driver, wake the codec
> > >> >> and recheck plug/unplug + ELD status.
> > >> >>
> > >> >> This fixes the issue with lost unsol events in power save mode,
> > >> >> the codec and controller can now sleep in D3 and still know when
> > >> >> the HDMI monitor has been connected.
> > >> >>
> > >> >> Signed-off-by: David Henningsson <david.henningsson at canonical.com>
> > >> >
> > >> > This addition looks fine, but then we'll get double notification for
> > >> > the normal hotplug/unplug, one via component ops and another via unsol
> > >> > event?
> > >> 
> > >> Right, in case the unsol event actually works...
> > >> 
> > >> I would argue that the normal case would be that the controller and 
> > >> codec is in D3 which means that the unsol event never gets through - due 
> > >> to hw limitations - which is what triggered this patch set in the first 
> > >> place.
> > >> 
> > >> But yes, in some case we might get double notification, but this should 
> > >> not cause any trouble in practice. The unsol event could be turned off, 
> > >> but would it be okay to save that for a later patch set (so I don't miss 
> > >> the upcoming merge window)?
> > >
> > > In that case, it should be mentioned in the changelog at least.
> > >
> > > This series came a bit too late for the merge window, so I'm not sure
> > > whether this can get in.  I personally find it OK, so take my ack for
> > > ALSA parts (patch 3/4), but the rest need review and ack from i915
> > > guys.  And we don't know who to merge this, if any.  The changes are
> > > almost even to i915 and hda.  I don't mind either way, via drm or
> > > sound tree.
> > 
> > Personally I'm fine with this still going for v4.3 since to me it looks
> > like any regressions this might cause will be on your side. *grin*.
> 
> The only bit I want is some decent kerneldoc for the ad-hoc growing
> i915/hda-intel interfaces. But that can be done in follow-up patches and
> needs to be coordinated with the audio rate handling series anyway. So ack
> from my side for all getting merged through alsa trees too.

Are you going to merge Libin's patchset?  If yes, it's better to align
both patchsets through a single tree.  It'll make merges easier, as
both touch the similar place.


thanks,

Takashi