From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2862CC2D0B1 for ; Tue, 4 Feb 2020 09:04:13 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A87E82087E for ; Tue, 4 Feb 2020 09:04:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="kE8t8655" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A87E82087E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id F3E3D1662; Tue, 4 Feb 2020 10:03:20 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz F3E3D1662 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1580807051; bh=hgzqv2j3U8KzOh84WqLOJijUy8xMQyPxA0X8n++LKOg=; h=Date:From:To:In-Reply-To:References:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kE8t8655iTo+S0eyDKGv71yYs9el6W19m6N2QX2MUY03FZMdiIGUs1ykYlH1EfOVf wDu6fy1VufCjRR2rIEXPO/by7TXP5WdJc4DQYdDknx1uz5YAUY5FD0RulmR2YmspLQ nAEpE1hD/27WV8Ksh+Ql3JL7YmG3mwp4UT3soCwc= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 74287F8015B; Tue, 4 Feb 2020 10:03:20 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id DCB49F80162; Tue, 4 Feb 2020 10:03:18 +0100 (CET) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 4D87FF80051 for ; Tue, 4 Feb 2020 10:03:15 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 4D87FF80051 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 5788BAFE1; Tue, 4 Feb 2020 09:03:14 +0000 (UTC) Date: Tue, 04 Feb 2020 10:03:14 +0100 Message-ID: From: Takashi Iwai To: Nikhil Mahale In-Reply-To: References: <20200203100617.3856-1-nmahale@nvidia.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") 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 X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" 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). thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel