> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
> Sent: Tuesday, July 1, 2025 6:33 PM
> To: Liao, Bard <bard.liao@intel.com>; Bard Liao <yung-
> chuan.liao@linux.intel.com>; broonie@kernel.org; tiwai@suse.de; linux-
> sound@vger.kernel.org; vkoul@kernel.org
> Cc: vinod.koul@linaro.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 00/15] ASoC/soundwire: Realtek codecs: wait codec init
> in hw_params
> 
> 
> >> The main issue is that the codec could be attached after the codec resume.
> >> Sometimes, it could take 100 ms or longer.
> >
> > I don't really see the problem here. The codec device (in the Linux sense) is
> trying to resume, and you want to wait until the hardware device is fully
> configured, no?
> >
> > Moving the waiting part is asking for trouble: the device will be reported as
> pm_runtime active, but it may not even be attached on the bus, and thus any
> register access will lead to invalid read/writes.
> >
> > For example, starting a register dump via debugfs would fail if the codec is
> not attached. The machine driver could also set jack status that would fail as
> well.
> 
> exhibit A for the last part: see rt700_set_jack_detect(). We absolutely want to
> make sure the device is attached *before* configuring the jack, that means
> waiting until pm_runtime_resume_and_get() is done.
> 
> So at at minimum, you would need to keep a wait_for_completion() in the
> resume method, but it could be demoted to a wait for the enumeration only.
> We do have to complete() for end of enumeration and end of initialization.
> 
> If it's the initialization that takes time, it could indeed be handled in a more
> asynchronous way, but I don't think you want to even think of a case where
> the codec finishes successfully its resume routine before the device is
> enumerated and can be used for register read/writes.


Thanks Pierre. Fair point. You convinced me. Let's drop this series.