Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2154283imu; Thu, 24 Jan 2019 08:05:14 -0800 (PST) X-Google-Smtp-Source: ALg8bN7esB4bZp6N2d1LtkXwZ498tQOx2IIQlFOEYDL/Iq+ZZA/S1f/cnVzKkcqobYs7/gi22uPB X-Received: by 2002:a62:ca9c:: with SMTP id y28mr6970755pfk.236.1548345913936; Thu, 24 Jan 2019 08:05:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548345913; cv=none; d=google.com; s=arc-20160816; b=OG/8tLijhYLtGGZJSsNfA311XtqVNYG0hCTz4hF3n18tyvT+Kx/SAB8IOHEO7VO+ts yYj1vPNZuTfpLZlMuczR3bm7AjmXlSfOt4vZpi/wE/1Qr2sm3XpIG+3wJCXiYNOHOHeI H8c4bBav4LZYHxYQycRo+keFXVhjBzhp3oXiBZrcL43akeYydZjFE6seREEYWl8O5NRX ZIzBKDo3GhZckFn28oxjm6F8c0cTAGTbxYH2arfyeTJHOrDTgxt1VXgYm6PhvtetTQk1 Fn09SYJ87TAsi0arn5CnqIaeIfr+9qajIoPBvxK3i/cBnn7wxeb+LabdFw0ehU3tEw4n ndbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=MQ22Y+kOt+nQjlbhdydAUpO+BDIo9eCz95ukCnfTnvA=; b=oWcxMEOmA7C2dYNsOWZR4eG/T3A5Z2PHM4DsHPunhEnhHFJHZk/u84n5qARaIdLXJW 28h5dHguYSE5u3qJv2HMuoxXw70WgJ/6Jp3ocOhKFs7xv0hzQiYTq6YXDno9owYcLGQj qGb6SAkuvuGKK0UfCH60zel1/eoGXY+IHZ52D0eHdsjc35v/s+sthzFsVE+t6eIqCIpN B+5PYTSWaqoo+l4Rs/IZz5xSjUGQPvy3Au5C2l1Lx/yVx4GyXuJTQ2w6lkaFcAvUZRsL adzLDnehIDy3abB/y25isGx/PTijjh0H2zPK3iQDtnNX8wb8hEMxVWa6bsN3esnaL4bW FFSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l3si17325184pld.229.2019.01.24.08.04.52; Thu, 24 Jan 2019 08:05:13 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728794AbfAXQEk (ORCPT + 99 others); Thu, 24 Jan 2019 11:04:40 -0500 Received: from mx2.suse.de ([195.135.220.15]:33778 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727980AbfAXQEi (ORCPT ); Thu, 24 Jan 2019 11:04:38 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 95B4CAC2C; Thu, 24 Jan 2019 16:04:37 +0000 (UTC) Date: Thu, 24 Jan 2019 17:04:37 +0100 Message-ID: From: Takashi Iwai To: "Sameer Pujar" Cc: , , , Subject: Re: [PATCH] ALSA: hda: runtime PM is always active In-Reply-To: <1548345432-11449-1-git-send-email-spujar@nvidia.com> References: <1548345432-11449-1-git-send-email-spujar@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") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 Jan 2019 16:57:11 +0100, Sameer Pujar wrote: > > The runtime PM count is incremented and set to active during hda codec > device init, but it is decremented and set to suspend during exit only. > Hence the runtime PM status is always active and hda device cannot be > put to runtime suspend. Keeping device usage active for entire period, > though nothing really happening on the device, seems unnecessary. > > This patch avoides incrementing runtime PM usage count of the device. > > Signed-off-by: Sameer Pujar > Reviewed-by: Ravindra Lokhande > Reviewed-by: Mohan Kumar D This breaks the existing things, I'm afraid. Did you really test and verify the behavior...? The runtime PM refcount is decremented at snd_hda_codec_register(), and that's the place to let runtime suspend of the codec really effective. (It's not about the controller, though.) thanks, Takashi > --- > sound/hda/hdac_device.c | 6 ------ > 1 file changed, 6 deletions(-) > > diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c > index 95b073e..72aa342 100644 > --- a/sound/hda/hdac_device.c > +++ b/sound/hda/hdac_device.c > @@ -31,9 +31,6 @@ static void default_release(struct device *dev) > * > * Returns zero for success or a negative error code. > * > - * This function increments the runtime PM counter and marks it active. > - * The caller needs to turn it off appropriately later. > - * > * The caller needs to set the device's release op properly by itself. > */ > int snd_hdac_device_init(struct hdac_device *codec, struct hdac_bus *bus, > @@ -55,8 +52,6 @@ int snd_hdac_device_init(struct hdac_device *codec, struct hdac_bus *bus, > codec->bus = bus; > codec->addr = addr; > codec->type = HDA_DEV_CORE; > - pm_runtime_set_active(&codec->dev); > - pm_runtime_get_noresume(&codec->dev); > atomic_set(&codec->in_pm, 0); > > err = snd_hdac_bus_add_device(bus, codec); > @@ -123,7 +118,6 @@ EXPORT_SYMBOL_GPL(snd_hdac_device_init); > */ > void snd_hdac_device_exit(struct hdac_device *codec) > { > - pm_runtime_put_noidle(&codec->dev); > snd_hdac_bus_remove_device(codec->bus, codec); > kfree(codec->vendor_name); > kfree(codec->chip_name); > -- > 2.7.4 > >