On Tue, 04 Feb 2020 06:08:19 +0100,
Nikhil Mahale wrote:
>
> On 2/3/20 4:10 PM, Takashi Iwai wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, 03 Feb 2020 11:06:17 +0100,
> > Nikhil Mahale wrote:
> >>
> >> If dyn_pcm_assign is set, different jack objects are being created
> >> for pcm and pins.
> >>
> >> If dyn_pcm_assign is set, generic_hdmi_build_jack() calls into
> >> add_hdmi_jack_kctl() to create and track separate jack object for
> >> pcm. Like sync_eld_via_acomp(), hdmi_present_sense_via_verbs() also
> >> need to report status change of the pcm jack.
> >>
> >> Rename pin_idx_to_jack() to pin_idx_to_pcm_jack(). The code to
> >> report status change of pcm jack, move it to update_eld() which is
> >> common for acomp and !acomp code paths.
> >
> > Thanks, that's the cause of the regression.
> > However, this needs yet more careful handling, I'm afraid.
> >
> > - hdmi_present_sense_via_verbs() may return true, and its callers
> > (both check_presence_and_report() and hdmi_repoll_eld()) do call
> > snd_hda_jack_report_sync() again.
> >
> > - For non-dyn_pcm_assign case, we shouldn't call jack report there,
> > but rather simply return true for calling report sync.
> >
> > - There is another workaround to block the jack report in
> > hdmi_present_sense_via_verbs() which is applied after update_eld(),
> > and this will be ignored.
> >
> > So, I guess that we need the conditional application of the individual
> > snd_jack_report() only for spec->dyn_pcm_assign==true, and assure that
> > hdmi_present() returns false.
> Yeah, you are right. But I don't think we should return false from
> hdmi_present().
>
> Before dyn_pcm_assign support for non-acomp drivers:
> 1) pcm and pin plug detection were controlled by same jack object, and
> 2) change in plug status was reported from snd_hda_jack_report_sync().
>
> If dyn_pcm_assign support is enabled for non-acomp drivers, then pcm
> and pin detection are controlled by different jack object. Now, report
> for plug status change of both jack object, requires to be in sync.
That's my concern. Basically we're seeing two different jacks for a
single hotplug. OTOH, from the user-space POV, it must be one jack
that should report back. IOW, with dyn_pcm_assign, you should ignore
the jack triggered from the unsol handler but report back only for the
jack that is assigned to the PCM.
> snd_hda_jack_report_sync() reports change in plug status of pin jack
> object.
>
> I think after snd_hda_jack_report_sync() we should loop over
> all pins, detect change in plug status, and report change in plug
> status of pcm jack.
This is what snd_hda_jack_report_sync() does; it loops over all
registered jacks and report the changes.
So, I think that in dyn_pcm_assign=true without acomp, we need to
clear jack->dirty for the originally reported jack in addition to the
translation to the PCM jack and reporting. FWIW, the dirty flag is
set in hdmi_intrinsic_event() and hdmi_repoll_eld().
And if you call snd_jack_report() for the necessary jack, there is no
need to call snd_jack_report_sync() at all. This is utterly
superfluous. Hence, if the repoll isn't needed and dyn_pcm_assign=1,
the function should return false.
> > The last item (the jack report block) is still unclear to me; it's a
> > workaround that was needed for Nvidia drivers in the past due to
> > instability. If this is still needed for DP-MST case, we have to
> > reconsider how to deal with it. Otherwise, this can be applied only
> > for non-dyn_pcm_assign case.
> The jack report block, was added by commit 464837a7bc0a (ALSA: hda -
> block HDMI jack reports while repolling), to avoid race condition
> with repolling. That is not NVIDIA specific.
Ah yes, that was for some unstable state handling. I thought the same
workaround applied to some old Nvidia driver, too, though.
> > BTW, the condition for jack->block_report and return value in
> > hdmi_present_sense_via_verbs() looks currently complicated, but it
> > could have been simplified like:
> >
> > -- 8< --
> > --- a/sound/pci/hda/patch_hdmi.c
> > +++ b/sound/pci/hda/patch_hdmi.c
> > @@ -1569,7 +1569,6 @@ static bool hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin,
> > * the unsolicited response to avoid custom WARs.
> > */
> > int present;
> > - bool ret;
> > bool do_repoll = false;
> >
> > present = snd_hda_jack_pin_sense(codec, pin_nid, dev_id);
> > @@ -1603,16 +1602,14 @@ static bool hdmi_present_sense_via_verbs(struct hdmi_spec_per_pin *per_pin,
> > else
> > update_eld(codec, per_pin, eld);
> >
> > - ret = !repoll || !eld->monitor_present || eld->eld_valid;
> > -
> > jack = snd_hda_jack_tbl_get_mst(codec, pin_nid, per_pin->dev_id);
> > if (jack) {
> > - jack->block_report = !ret;
> > + jack->block_report = do_repoll;
> > jack->pin_sense = (eld->monitor_present && eld->eld_valid) ?
> > AC_PINSENSE_PRESENCE : 0;
> > }
> > mutex_unlock(&per_pin->lock);
> > - return ret;
> > + return !do_repoll;
> > }
> >
> > static struct snd_jack *pin_idx_to_jack(struct hda_codec *codec,
> > -- 8< --
> Yeah, this is simple to understand.
>
> I am sending fresh patches, see if they make sense.
The cleanup like the above shouldn't be applied before the critical
fix. That is, we have to fix the regression at the very first patch
with Cc to stable. This must be applicable cleanly and working on 5.5
kernel as is. After the fix, we may apply the remaining cleanups like
the above.
So, let's concentrate on one (or split if needed) fix patch for now.
thanks,
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
