All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikhil Mahale <nmahale@nvidia.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, martin@larkos.de,
	kai.vehmanen@linux.intel.com, aplattner@nvidia.com
Subject: Re: [alsa-devel] [PATCH] ALSA: hda - Fix DP-MST support for NVIDIA codecs
Date: Tue, 4 Feb 2020 16:01:48 +0530	[thread overview]
Message-ID: <1672c477-8795-8a37-4033-bb3982f64225@nvidia.com> (raw)
In-Reply-To: <s5hpneu7mi5.wl-tiwai@suse.de>

On 2/4/20 2:33 PM, Takashi Iwai wrote:
> External email: Use caution opening links or attachments
> 
> 
> On Tue, 04 Feb 2020 08:46:17 +0100,
> Takashi Iwai wrote:
>>
>> 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.
> 
> Scratch this.  The code is so complex and fuzzing me.  Oh well.
> 
> For dyn_pcm_assign, the snd_hda_jack stuff is used only for the unsol
> event notification but it's not bound with snd_jack object.  Hence
> snd_hda_jack_report_sync() is harmless -- but it's also useless for
> dyn_pcm_assign, too.
> 
> So basically the logic of your patch 4 is OK.  But it's still
> misleading in a few points.
> 
> - The snd_hda_jack state was already updated via
>   snd_hda_jack_pin_sense() call at the beginning of
>   hdmi_present_sense_via_verbs() before calling
>   snd_hda_jack_report_sync().
> 
>   That implies that what's jack->pinse_sense assignment at the end
>   of this function does is to override the jack->pin_sense value that
>   was already updated.
> 
> - snd_hda_jack_report_sync() is superfluous for dyn_pcm_assign case.
>   The jack update was already performed, as mentioned in the above,
>   and hda_jack->jack is NULL for dyn_pcm_assign.
> 
>   Moreover, snd_hda_jack_report_sync() can be replaced with the
>   individual snd_jack_report() call even for non-dyn_pcm_assign case,
>   too.  The difference is only how to get snd_jack object; for
>   dyn_pcm_assign, it's pin_idx_to_jack() while non-dyn_pcm_assign,
>   it's hda_jack->jack.  I guess the call of snd_jack_report() can be
>   unified in a helper (that can be called from sync_eld_via_acomp()
>   too).
The code is really complex and fuzzing me too. Anyways, I have send
out fresh patch for review, see that is exactly what we are
looking for. As you said earlier, cleanup change will go in separate
patch set.

Thanks,
Nikhil Mahale

> thanks,
> 
> Takashi
> 

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2020-02-04 10:32 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03 10:06 [alsa-devel] [PATCH] ALSA: hda - Fix DP-MST support for NVIDIA codecs Nikhil Mahale
2020-02-03 10:40 ` Takashi Iwai
2020-02-04  5:08   ` Nikhil Mahale
2020-02-04  7:46     ` Takashi Iwai
2020-02-04  9:03       ` Takashi Iwai
2020-02-04 10:31         ` Nikhil Mahale [this message]
2020-02-03 19:02 ` Martin Regner
2020-02-04 10:27 Nikhil Mahale
2020-02-04 11:18 ` Takashi Iwai
2020-02-04 16:10   ` Martin Regner
2020-02-04 16:18     ` Takashi Iwai
2020-02-04 13:11 ` Kai Vehmanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1672c477-8795-8a37-4033-bb3982f64225@nvidia.com \
    --to=nmahale@nvidia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=aplattner@nvidia.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=martin@larkos.de \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.