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 444DEC678D5 for ; Tue, 7 Mar 2023 21:08:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231182AbjCGVIM (ORCPT ); Tue, 7 Mar 2023 16:08:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230445AbjCGVIH (ORCPT ); Tue, 7 Mar 2023 16:08:07 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DAEA630E97 for ; Tue, 7 Mar 2023 13:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678223284; x=1709759284; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=7IrEeKk0snZCSklr5bDVVFjLXU88F+WBESrvUTYCgG4=; b=H4Tbl2l0Kc/vhM07pVSF1jyr81P2Z0NbwLEVo7tEZktuJh/SkrX60q9D RO8BE3xxyYiTVw7fRnrgE3YNPrfX+PQU78Kb+y8wUBui6oAc4tA1YCAQq M4G5qdLS4MW8L0NFlTbwfk0iaMn4YsySv6ZWOOmy+brj4u5FybO2zrdEu YCFKeIEKe+2Hu/a7hCvKrq4DhF3DUrd21mpxuuv/C4nymjJJlMUFhv6AU GNXmuSe7EwDzdl45KzKji3Z6yFul2UM3MyMCydufDNc5L3Dft8XF2hhDK 9hvYZg7nGcWgpLyaYdjtK0x9AsXWQkbEM7+5/hbv8uuQG56Exjlg6Urjt g==; X-IronPort-AV: E=McAfee;i="6500,9779,10642"; a="400799542" X-IronPort-AV: E=Sophos;i="5.98,241,1673942400"; d="scan'208";a="400799542" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Mar 2023 13:08:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10642"; a="670070952" X-IronPort-AV: E=Sophos;i="5.98,241,1673942400"; d="scan'208";a="670070952" Received: from jyankelo-mobl.amr.corp.intel.com (HELO [10.255.32.245]) ([10.255.32.245]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Mar 2023 13:08:02 -0800 Message-ID: <9399110b-bbba-f96e-85ef-a317e8f4d518@linux.intel.com> Date: Tue, 7 Mar 2023 15:08:01 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.7.1 Subject: Re: [PATCH V6 8/8] soundwire: amd: add pm_prepare callback and pm ops support Content-Language: en-US To: "Mukunda,Vijendar" , vkoul@kernel.org Cc: alsa-devel@alsa-project.org, Basavaraj.Hiregoudar@amd.com, Sunil-kumar.Dommati@amd.com, Mario.Limonciello@amd.com, amadeuszx.slawinski@linux.intel.com, Mastan.Katragadda@amd.com, Arungopal.kondaveeti@amd.com, claudiu.beznea@microchip.com, Bard Liao , Sanyog Kale , open list References: <20230307133135.545952-1-Vijendar.Mukunda@amd.com> <20230307133135.545952-9-Vijendar.Mukunda@amd.com> <4330af6a-ce97-53ed-f675-6d3d0ac8f32f@linux.intel.com> From: Pierre-Louis Bossart 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 3/7/23 14:25, Mukunda,Vijendar wrote: > On 07/03/23 20:58, Pierre-Louis Bossart wrote: >>> +static int amd_resume_child_device(struct device *dev, void *data) >>> +{ >>> + struct sdw_slave *slave = dev_to_sdw_dev(dev); >>> + int ret; >>> + >>> + if (!slave->probed) { >>> + dev_dbg(dev, "skipping device, no probed driver\n"); >>> + return 0; >>> + } >>> + if (!slave->dev_num_sticky) { >>> + dev_dbg(dev, "skipping device, never detected on bus\n"); >>> + return 0; >>> + } >>> + if (!pm_runtime_suspended(dev)) >>> + return 0; >>> + ret = pm_request_resume(dev); >> I still don't get why the test above was needed. It's racy and brings >> limited benefits. > As explained below thread, > > https://lore.kernel.org/lkml/acd3a560-1218-9f1d-06ec-19e4d3d4e2c9@amd.com > > Our scenario is multiple peripheral devices are connected > over the same link. > > In our implementation, device_for_each_child() function invokes > amd_resume_child_device callback for each child. > When any one of the child device is active, It will break the > iteration, which results in failure resuming all child devices. Can you clarify the 'it will break the iteration' statement? Are you saying pm_request_resume() will return a negative error code if the device is already active? We've used an unconditional pm_request_resume() in the Intel code for quite some time, including with multiple amplifiers per link, and have never observed the issue you report, so I'd like to get to the root cause pretty please. You took the Intel code and added a test for AMD platforms, and I'd really like to understand if the Intel code was wrong in the first place, or if the test is not needed. Something does not add up here. > > If we skip , pm_suspended check , it will not resume all > peripheral devices when any one of the peripheral device is active. >> >>> + if (ret < 0) >>> + dev_err(dev, "pm_request_resume failed: %d\n", ret); >>> + >>> + return ret; >>> +} >