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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 44563C433DB for ; Wed, 24 Mar 2021 15:08:00 +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 89BBE619A4 for ; Wed, 24 Mar 2021 15:07:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 89BBE619A4 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 D4CBC1682; Wed, 24 Mar 2021 16:07:06 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz D4CBC1682 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1616598476; bh=2y0H8+WbPuWwSgk8jMWps3spXMdcPuTqQhnluEr49gU=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=RiOHHMKI9fnBswCTP+WXTgjQkRAx/qZQJVXkdnsOloWIuXLraPOOpisf8CowzkfKs TaIl8EP6C8fscRQCKaCDWJBDp6YEJ+x7o72Bkz0qCwCscBN2uNI4+PtIeqbkSKF870 d3sLohclurUCL8nNORa5y+23+f074RNzP6pIbKoU= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 55BC5F80156; Wed, 24 Mar 2021 16:07:06 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 18225F8016B; Wed, 24 Mar 2021 16:07:05 +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 A5B09F80104 for ; Wed, 24 Mar 2021 16:06:53 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz A5B09F80104 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 727D0AD9F; Wed, 24 Mar 2021 15:06:48 +0000 (UTC) Date: Wed, 24 Mar 2021 16:06:48 +0100 Message-ID: From: Takashi Iwai To: Andrey Grodzovsky Subject: Re: Adding movable PCIe BARs support in snd_hda_intel In-Reply-To: References: <30b36220-ff0f-d04c-1fca-349b3ff3a19b@amd.com> <9758cd4c-1246-a4ab-74eb-0e060248a00b@amd.com> <06b2dae2-a5ea-0cc8-891f-2aaff64ae260@amd.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") Content-Type: text/plain; charset=US-ASCII Cc: "Alexander.Deucher@amd.com" , alsa-devel@alsa-project.org, Sergei Miroshnichenko , "Christian.Koenig@amd.com" 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: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, 24 Mar 2021 15:53:33 +0100, Andrey Grodzovsky wrote: > > Appreciate you investing the effort in helping on this. > I will start to merge it now as it doesn't apply cleanly on my branch. > > If I understand correctly your main HW access prevention mechanism during > the PCI prepare-rescan period is by bailing out on IOCTLs with the check > of power state == SNDRV_CTL_POWER_D0 or waiting when a user process closes > it's device file descriptor in patches 2 and 5. For command submission > prevention you use the freeze flag from patch 6. > If I haven't missed anything I don't see how those all protect when > new device is plugged while any of those operations are already in > flight. What prevents concurrent HW access from an IOCTL already > running > and HW suspend and MMIO unampping in rescan_preapre which starts after > IOCTL began ? The call of snd_pcm_suspend_all() is the key. That puts all PCM streams in the stopped and suspended state. And the codec devices as well as the controller device will be put into the suspended state. So, for the PCM side, this should be fine with it, I guess. However, after sending the patches, I noticed that they won't suffice for the pending control calls. For the control get/put callbacks that have been pending before setting the power_state=D3hot, they would still kick off the runtime PM and bad things may happen. Due to that, the bus.frozen flag won't work reliably, I'm afraid. So, in that part, we need the code to sync the execution of the pending get/put calls in addition. Maybe refcounting the control ioctls that are involved with get/put calls (SNDRV_CTL_IOCTL_ELEM_READ, _WRITE, maybe with _TLV_READ, too) and wait for those ioctls finishing before actually starting the codec suspend procedure. Takashi