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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3FC97C4167B for ; Tue, 14 Nov 2023 10:26:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231161AbjKNK0i (ORCPT ); Tue, 14 Nov 2023 05:26:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44028 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjKNK0g (ORCPT ); Tue, 14 Nov 2023 05:26:36 -0500 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4292883; Tue, 14 Nov 2023 02:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1699957593; x=1731493593; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=zwarH7arzcy5tlAYIhd5KTccW/23+URY4RVmEqL6/kc=; b=jsqe4cRA97bTIuM5Lv6hxjlO8CdyD2lOlO46QYykB7H8WlydCZZYEtrR 11jdh4rBqFPtxIgdby6+Nmbzs16+sAoV7bemcTx0q+2IRnBC2M6Gz2TOG zM9ohEWUUExns3ONvmtpbyua1YmfH2nLnT5d5sVy1spgzAFs2LjDWba/2 eiVd0mY43opOn6KtbHMJSZZ+p99jG/NaTcrCR5j3SDu8yDpdUYgjWEBIS IrXcwRrXi1qombI5KXcrr/lVaP42mSyuwg1mxGs/f8Cyiact3Zf5KIcGB KTk/o+MjSdf9ygwHJcZKov6I99sT2yICt70gaMNEKz5kco3OmByA65stG A==; X-IronPort-AV: E=McAfee;i="6600,9927,10893"; a="3686984" X-IronPort-AV: E=Sophos;i="6.03,301,1694761200"; d="scan'208";a="3686984" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2023 02:26:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10893"; a="855240153" X-IronPort-AV: E=Sophos;i="6.03,301,1694761200"; d="scan'208";a="855240153" Received: from ahunter6-mobl1.ger.corp.intel.com (HELO [10.0.2.15]) ([10.252.39.179]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2023 02:26:29 -0800 Message-ID: Date: Tue, 14 Nov 2023 12:26:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mmc: sdhci-pci-gli: Disable LPM during initialization Content-Language: en-US To: Sven van Ashbrook , =?UTF-8?Q?Kornel_Dul=C4=99ba?= Cc: Ulf Hansson , Jason Lai , Victor Shih , Ben Chuang , =?UTF-8?Q?Stanis=C5=82aw_Kardach?= , linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, stable@vger.kernel.org, Rafael J Wysocki References: <20231109111934.4172565-1-korneld@chromium.org> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/11/23 18:58, Sven van Ashbrook wrote: > There's something happening in this driver that doesn't > make much sense to me. > > According to the pm runtime docs [1] the initial runtime pm > status of all devices is 'suspended'. Which I presume, means: > if the driver doesn't use any of the pm_runtime_*() functions > to tell the core "actually, I am active after probe", then the > device remains suspended until explicitly going active, at which > point the runtime_resume() callback is invoked. > > That's the theory. In practice, what do I see on a device > containing this bridge? > Intel SoC <-> PCIe bus <-> gl9763e bridge <-> eMMC bus <-> eMMC drive > > at probe() (does not exist in this driver so I stubbed it): > [ 0.601542] runtime pm is enabled = 1 (disable_depth == 0) > [ 0.601552] runtime pm is active = 2 (usage_count) > > at probe_slot(): > [ 0.602024] runtime pm is enabled = 1 > [ 0.602027] runtime pm is active = 2 > > At add_host(): > [ 0.602804] runtime pm is enabled = 1 > [ 0.602809] runtime pm is active = 3 > > It looks like: > - nowhere does the gl9763e driver inform runtime pm it's active PCI subsystem does it in pci_pm_init() > - the device is active in probe(), probe_slot() and add_host() > - the runtime_resume() callback did not get called before > probe(), probe_slot(), or add_host(). > > Why is the runtime_resume() callback not invoked? Most drivers expect the device to be active at probe(). How it gets that way is up to the bus. Note, the driver may call pm_runtime_set_active() but that doesn't call runtime_resume(). > Does the driver have a runtime_pm misconfiguration issue here? No > > Perhaps Rafael could clarify? > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/power/runtime_pm.rst?h=v6.6.1#n563