Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <ef05d550-c2aa-e256-58ec-612c2a3294ca@amd.com>
Date:   Mon, 16 Jan 2023 14:05:45 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: [PATCH 19/19] ASoC: amd: ps: increase runtime suspend delay
Content-Language: en-US
To:     Mark Brown <broonie@kernel.org>,
        Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc:     "Limonciello, Mario" <mario.limonciello@amd.com>, vkoul@kernel.org,
        alsa-devel@alsa-project.org, Mastan.Katragadda@amd.com,
        Sunil-kumar.Dommati@amd.com, Basavaraj.Hiregoudar@amd.com,
        Takashi Iwai <tiwai@suse.com>,
        Liam Girdwood <lgirdwood@gmail.com>,
        open list <linux-kernel@vger.kernel.org>,
        Syed Saba Kareem <Syed.SabaKareem@amd.com>,
        arungopal.kondaveeti@amd.com
References: <20230111090222.2016499-1-Vijendar.Mukunda@amd.com>
 <20230111090222.2016499-20-Vijendar.Mukunda@amd.com>
 <c7f018e3-c8be-6819-0ece-244bfb943c62@linux.intel.com>
 <0aaf3fa5-bcf1-ec06-8f78-c61e8809398e@amd.com>
 <5a34e6f7-eaf1-8128-81e4-81f65541d9a8@linux.intel.com>
 <1a14e117-4216-b98d-f972-c9a02cf79d1e@amd.com>
 <eb12ed5d-a9f9-cb8d-28f5-ac84c75cf441@linux.intel.com>
 <90782037-109b-b197-ca17-b7d199931f7d@amd.com>
 <e73032b1-ac5b-4a3a-e2a0-8ac121853dee@linux.intel.com>
 <Y8G3mPUDWWUu/3ZR@sirena.org.uk>
From:   "Mukunda,Vijendar" <vijendar.mukunda@amd.com>
In-Reply-To: <Y8G3mPUDWWUu/3ZR@sirena.org.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Y1dKdjdsR1ZCNXZKU1NNdzgrTGNMaUpQWENlK1ZPSVljMG4zVm12L0hWcTND?=
 =?utf-8?B?TDFoWk8zbFc0MUhDaFM4YnlqU3phcjFBTDh3TGd1UXhpb21jV00wZjVTR2tw?=
 =?utf-8?B?VEw4Q0dvRW1RVGNqSU82cTlyaXJySEpXQ0VNNTJ5aVNRTzhPL1RXdFZ2Z2gx?=
 =?utf-8?B?NnVrZFZzV2pHaDRkOUdIWGhWRlZiVitUT1E0djB0VDAzWFFnQ25mVnlUL0or?=
 =?utf-8?B?ZFFBMkM1U0kweFlHRDZFL3E5Yy80SEFRT0JHOGZsL2tOa1Arb0FvZ3pjVXFj?=
 =?utf-8?B?NWRlSjNLd0RSbk12anlSUTlCbmRGWDBOVFgrNnR4SGJmR0pBNlpkQjVmOG1x?=
 =?utf-8?B?dkRrNnluTERaSnhSS0I2WFR2SmhkVDNKMTh3UmtjVXErUTBiZlFSTEZrZUY3?=
 =?utf-8?B?OVJsUGFuSDhJOHl3d3oxU3gwMjZzdXA4a0NUT2paZFdiNEhlQmdwWlZSZ0ha?=
 =?utf-8?B?MVlSdkxGN21SMmJGUjNKOWxheGNleTNnTDNEVkdPMFhQa3lMUEFPNUhacHAv?=
 =?utf-8?B?L1hIVVIxQlNPQkhIZVVaOGFUeTloZFI1RnlGWGYvUXpqYjBscTJBV1d4d1M1?=
 =?utf-8?B?NUhRSFk1MjJOVnBwN1VhUXA2bmE3MlN2Y2p0MVRQOGtZRklNYVBKbWVhQ0xk?=
 =?utf-8?B?cFlsekY3V3VaU0FGWUkwUFdZY0pHN3JIeXllV1lXamdUcHNxQjhJb0VjWGM3?=
 =?utf-8?B?blErczQycFZSUW1JWmlZc0VNWlpYWkJSb3pOcGwvK2NWZUdDZDAveDkyNk9W?=
 =?utf-8?B?SXgxaExobktQWldSVUc2MlBXVHZVZ1dtd3FqcUxjWFVOc3prclZiUHVvcTN4?=
 =?utf-8?B?VlVjMWl6cmNFNkl5cGxDSFNDMTV2RGNRTzVJN0NDOWFHdGdVdmNsYTRHQ0xF?=
 =?utf-8?B?MHZVUmxvVU0xaVBhbkdNTkR4Tkw5VExyTUNPWGxUR0E1WWZVemVDQU4yZEpW?=
 =?utf-8?B?S0d0Y0I0R0VkTng0UlVYenV5WFZVYWVaMjRLWVgrSy9OeW1pSTFWOWgwbFNZ?=
 =?utf-8?B?VEdaREZ4UTkvbS91U3V0NU5JeS9IRk5IRkRieEo5VkprbkRUTG8yajFjdmJv?=
 =?utf-8?B?Z0JBY1JDSVgzbHRmcTBJMHpMUG1NakVUZFRuRnpqaDlnVkt5NExnZTcvVWlH?=
 =?utf-8?B?M1JPcTZlb3NNdHJ6QlNLRGVTUUduUUhDRzNXZnZNMWdldXZrS0dOYVdPQ1Fq?=
 =?utf-8?B?TXozdDBpMzJ2b09QOGtvdUZTZkh0UkpIR1h5ejBUNUJMZmY5YWRBZUNHNStG?=
 =?utf-8?B?Z1RvclNJYVFFMDlQaUxxcUFpTnFjbVB3NlNpS3lheUErdHJST3lDVGR4YSsx?=
 =?utf-8?B?RURKeDdrMUJ1dFhKd3E3dGVsVi9kSElzbHdIb29oMFhyUjl3K0tZTktKV0ZW?=
 =?utf-8?B?OHRqTHpVWXpvOWhKVXllTnJ0ZXRRRytpZ0tlZ2lQd3JNQzVvU1pqN1FIWmJK?=
 =?utf-8?B?Y0JUYUJlb2h0ZkVYQkRwcnlzNUJjbGxKLy9ZUzJyQ09rTjRraVluMkZDM2JV?=
 =?utf-8?B?NUE3TlU3d1VIZVRJSENPZWhXS2YzbDk3cXZ5QWVmbmtzT1RkSWV6QXE4SVV6?=
 =?utf-8?B?UGh2d3lpMUh3cXIzWUwrZVNERVJaV3p2SmQvT1NnNHM0U3hjbXlYNElRdERv?=
 =?utf-8?B?dCs0eFVWUUQwMDdGc3pYKzR5enl0ZEVaRlNUZVd0RURJeElvSE1TTVoyUWRw?=
 =?utf-8?B?ZGVQaDNTaFdZQ0dkeTZ6YTI0ODZNcHhVblhTR3B3Mit0U1VVWDRPa2EzVlJk?=
 =?utf-8?B?dTQwbVNXaTlWbTBvRFR0ckVteUlmMW1iZDMzaFh0S2c1WkNpaCtYNmFRdVhM?=
 =?utf-8?B?Qk1KVTg3QW5mbmUyTjA4N1I0RGtVa2hsZklxZzFLbUxGLzVkSnlNalNqYTBO?=
 =?utf-8?B?Y0JNTkRtdGhvVHZmMFp1TU92UzQxYjVtUFM5NlRSVkZic0ptdllHLy9zZWRZ?=
 =?utf-8?B?Sk8rcm5mbm13MmZuamtOalZuS3g4RW5sSkx4L1cvUklvUGV2OEFuNGw1cXRJ?=
 =?utf-8?B?cUFFbk14T2xwTTk2dG85dHlFWTBRSGhEdWFhSkhmeWFLMzdxOGtWL1l6bVFu?=
 =?utf-8?B?WGk4MFF5RGp3VnpFOHpPMjFySTFOdHY5ZnNPd2tYL0U1MW45OVZ0RlF0aXcy?=
 =?utf-8?Q?xyL1lXU5O2IlDJJuz63GC0f9B?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a962f92c-2794-4ce8-aeaf-08daf79c3793
X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB4123.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Jan 2023 08:32:34.9335
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: u+/fBRou7qMF2DObyyoVKLHoDXBj6bkB8AhrvKfRMIckWKGYejsqmePdygz/Hv0JmDc2GrFwtRbSYsLKeRoAeg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4483
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 14/01/23 01:27, Mark Brown wrote:
> On Fri, Jan 13, 2023 at 11:33:09AM -0600, Pierre-Louis Bossart wrote:
>
>> I do recall some issues with the codec jacks, where if the card
>> registration happens too late the codec might have suspended. But we
>> added pm_runtime_resume_and_get in the set_jack_detect callbacks, so
>> that was solved.
> Right, I would expect that whatever needs the device to be powered on
> would be explicitly ensuring that this is done rather than tweaking
> timeouts - the timeouts should be more of a performance thing to avoid
> bouncing power too much, not a correctness thing.
Machine driver probe is executed in parallel with Manager driver
probe sequence. Because of it, before completion of all peripherals
enumeration across the multiple links, if card registration is
completed, codec register writes will fail as Codec device numbers
are not assigned.

If we understood correctly, as per your suggestion, We shouldn't use any
time bounds in machine driver probe sequence and before registering the
sound card, need to traverses through all peripheral initialization completion
status for all the managers.