From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH RFC 0/4] HDA/i915 jack handling using component Date: Thu, 12 Nov 2015 17:55:48 +0100 Message-ID: References: <1447345214-7212-1-git-send-email-tiwai@suse.de> <5644C1D4.6060101@canonical.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 8D2272606B7 for ; Thu, 12 Nov 2015 17:55:49 +0100 (CET) In-Reply-To: <5644C1D4.6060101@canonical.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: David Henningsson Cc: alsa-devel@alsa-project.org, mengdong.lin@linux.intel.com, Libin Yang List-Id: alsa-devel@alsa-project.org On Thu, 12 Nov 2015 17:44:04 +0100, David Henningsson wrote: > > > > On 2015-11-12 17:20, Takashi Iwai wrote: > > Hi, > > > > after the previous discussion ([RFC PATCH 0/2] ALSA: hda - DP MST > > audio for Jack support), I thought it'd be even easier to give a > > concrete code for further discussion; so here we go, it's a patchset > > to implement the jack via audio component. > > > > In the end, I added a new audio component ops to fetch the current > > ELD, since the state is unknown at the time the audio driver starts. > > The other two patches are just a cleanup. > > > > This series is submitted just as an RFC, basically for a better > > understanding, not seriously considered to be merged as is. > > (That's why no intel-gfx is Cc'ed yet.) > > > > Note that the i915 patches are applied to the latest Linus tree, while > > patch_hdmi.c patch is to my for-linus branch. The patches are found > > in test/hdmi-jack branch of sound git tree. > > Right; maybe you got tired of waiting for me to make that patch set, > sorry. :-/ Don't worry, I was just bored at an afternoon coffee time, so started hacking quickly as a proof of concept. > I looked at it a while ago, but got a bit stuck in figuring out how to > properly lock things to ensure that the ELD info is not being written to > (by another kernel thread) at the same time as we read it. Yeah, the locking needs to be revised later in my patchset, too. > I'm not sure whether your patch resolves that or not. But if av_mutex is > always held whenever your audio_enabled flag is changed (and ELD is > never changed while audio_enabled=true), that might do it though. > > We might also need to send audio_enabled itself over too, not sure if we > can have audio enabled without valid ELD - in some cases when we have > monitors not giving us any ELD info. It's a good question. We currently allow playback even on a pin that didn't get ELD, indeed. So, yes, it might be worth to return both values. thanks, Takashi