From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: "Mukunda,Vijendar" <vijendar.mukunda@amd.com>, 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 <yung-chuan.liao@linux.intel.com>,
Sanyog Kale <sanyog.r.kale@intel.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH V6 8/8] soundwire: amd: add pm_prepare callback and pm ops support
Date: Tue, 7 Mar 2023 15:08:01 -0600 [thread overview]
Message-ID: <9399110b-bbba-f96e-85ef-a317e8f4d518@linux.intel.com> (raw)
In-Reply-To: <d5a75826-d762-27fc-5820-6826debdecd9@amd.com>
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;
>>> +}
>
next prev parent reply other threads:[~2023-03-07 21:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20230307133135.545952-1-Vijendar.Mukunda@amd.com>
2023-03-07 13:31 ` [PATCH V6 1/8] soundwire: export sdw_compute_slave_ports() function Vijendar Mukunda
2023-03-07 13:31 ` [PATCH V6 2/8] soundwire: amd: Add support for AMD Manager driver Vijendar Mukunda
2023-03-07 15:25 ` Pierre-Louis Bossart
2023-03-07 20:36 ` Mukunda,Vijendar
2023-03-15 9:42 ` Vinod Koul
2023-03-16 13:58 ` Mukunda,Vijendar
2023-03-17 13:34 ` Vinod Koul
2023-03-17 14:04 ` Mukunda,Vijendar
2023-03-07 13:31 ` [PATCH V6 3/8] soundwire: amd: register SoundWire manager dai ops Vijendar Mukunda
2023-03-15 9:58 ` Vinod Koul
2023-03-16 3:32 ` Mukunda,Vijendar
2023-03-07 13:31 ` [PATCH V6 4/8] soundwire: amd: enable build for AMD SoundWire manager driver Vijendar Mukunda
2023-03-15 9:59 ` Vinod Koul
2023-03-16 3:29 ` Mukunda,Vijendar
2023-03-07 13:31 ` [PATCH V6 5/8] soundwire: amd: add SoundWire manager interrupt handling Vijendar Mukunda
2023-03-15 10:06 ` Vinod Koul
2023-03-16 17:04 ` Mukunda,Vijendar
2023-03-17 13:36 ` Vinod Koul
2023-03-17 14:46 ` Mukunda,Vijendar
2023-03-07 13:31 ` [PATCH V6 6/8] soundwire: amd: add runtime pm ops for AMD SoundWire manager driver Vijendar Mukunda
2023-03-07 13:31 ` [PATCH V6 7/8] soundwire: amd: handle SoundWire wake enable interrupt Vijendar Mukunda
2023-03-07 13:31 ` [PATCH V6 8/8] soundwire: amd: add pm_prepare callback and pm ops support Vijendar Mukunda
2023-03-07 15:28 ` Pierre-Louis Bossart
2023-03-07 20:25 ` Mukunda,Vijendar
2023-03-07 21:08 ` Pierre-Louis Bossart [this message]
2023-03-08 4:32 ` Mukunda,Vijendar
2023-03-08 13:58 ` Pierre-Louis Bossart
2023-03-08 14:19 ` Mukunda,Vijendar
2023-03-08 14:23 ` Pierre-Louis Bossart
2023-03-08 15:05 ` Mukunda,Vijendar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9399110b-bbba-f96e-85ef-a317e8f4d518@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=Arungopal.kondaveeti@amd.com \
--cc=Basavaraj.Hiregoudar@amd.com \
--cc=Mario.Limonciello@amd.com \
--cc=Mastan.Katragadda@amd.com \
--cc=Sunil-kumar.Dommati@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=claudiu.beznea@microchip.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sanyog.r.kale@intel.com \
--cc=vijendar.mukunda@amd.com \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox