Re: [PATCH RFC 0/4] HDA/i915 jack handling using component

[Takashi Iwai <tiwai@suse.de>]

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