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 E642AC433DB for ; Fri, 22 Jan 2021 14:13:10 +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 0D73223A63 for ; Fri, 22 Jan 2021 14:13:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D73223A63 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 710BD1F01; Fri, 22 Jan 2021 15:12:17 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 710BD1F01 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1611324787; bh=iP2dlPgSQ0PMGGaouuTi8n2HcpfUi9h0BkGPXbLLFKM=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=N6fTSqswSy/8QZxKj52SdOdvNBt2h9QJGBbPzLnfJmsFzPIvHQKIg9VtvlJpFHAuY AmipV0ChspINnB3MNjrGUW2QFqmBoNtyrV8KhPazVOhOp7tanVt5TFiVI0DJBExTNU Hp8a3s0EXrzeL11MwUm9LkKFnQIwG+UA0Y8ALyng= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id CD4B0F80166; Fri, 22 Jan 2021 15:12:16 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 5B656F80166; Fri, 22 Jan 2021 15:12:15 +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 BBF29F80164 for ; Fri, 22 Jan 2021 15:12:12 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz BBF29F80164 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 A7A4BB750; Fri, 22 Jan 2021 14:12:11 +0000 (UTC) Date: Fri, 22 Jan 2021 15:12:11 +0100 Message-ID: From: Takashi Iwai To: Ranjani Sridharan Subject: Re: Question about hdac_ext_link ref_count management In-Reply-To: References: 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: alsa-devel@alsa-project.org, kai.vehmanen@linux.intel.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 Fri, 22 Jan 2021 00:23:53 +0100, Ranjani Sridharan wrote: > > Hi Takashi, > > While exploring some power optimizations on Intel platforms, I noticed > that the hdac_ext_link ref_count is incremented during codec probe > in hdac_hda_codec_probe() and the ref_count is held until the codec > device is removed. > > I was wondering if it would be possible to call the get/put for the > hdac_ext_link in the codec runtime suspend/resume callbacks so that the > link is powered up only when the link is in use. Are there any > downsides to doing this? Wouldn't the snd_hdac_ext_bus_link_power_up() / down() calls do the runtime PM stuff? Maybe we need to revisit those link power management. The ext stuff isn't well managed, I'm afraid. The get() and put() are obviously for fully enabling and disabling the device, hence it's not suitable for the runtime PM suspend/resume. The power_up() / down() should be adjusted to fit with the runtime PM call, if any. thanks, Takashi