On Wed, 02 Sep 2015 10:32:34 +0200, Daniel Vetter wrote: > > On Wed, Sep 02, 2015 at 10:03:55AM +0200, Takashi Iwai wrote: > > 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 <ti...@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.hennings...@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. > > Oh that was an ack for merging it all through your tree. If you punt it to > 4.4 I might ask you for a stable tree to pull in in case I get conflicts.
OK, then I'll merge David's patchset now for the upcoming pull request for 4.3-rc1. thanks, Takashi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
