On 6/17/22 14:05, Pierre-Louis Bossart wrote: > >>>> What this patch does it make sure that the bus is operation when the >>>> card is created. In usual cases, this is a no-op, this just helps with >>>> corner test cases. It's not plugging a major hole in the pm_runtime >>>> support, just fixing a programming sequence that was not tested before. >>> >>>> One possible objection is that we don't keep the reference and the bus >>>> active until all components are probed. I tried doing this at the ASoC >>>> core level, but that breaks all kinds of devices that have their own >>>> quirky way of dealing with pm_runtime - specifically HDaudio and HDMI. >>>> That's why I added this resume here. >>> >>>> Makes sense? >>> >>> Ish. Ugh, right. So it's not fixing anything really, it's mainly >>> papering over cracks where things are being missed. In any case it's >>> not doing any harm and it helps things for now. >> >> You got it right. There are additional patches that were sent to use >> pm_runtime_resume_and_get() on set_jack, and other clear cases that were >> missed, but this is more of a blanket "do not harm" resume in case codec >> drivers are missing something. > > please wait for merges, we're chasing two regressions with nonsensical > mixer values > > numid=5,iface=MIXER,name='PGA4.0 4 Master Capture Volume' > ; type=BOOLEAN,access=rw---R--,values=2 > : values=on,on > | dBscale-min=-50.00dB,step=1.00dB,mute=1 > > and a spurious log that we missed: > > snd-soc-dummy snd-soc-dummy: Runtime PM usage count underflow! The two regressions are not caused by this series. The mixer issue already exists and is fixed with Sameer Pujar's "ASoC: ops: Fix multiple value control type" patch. The "Runtime PM usage count underflow" is a mistake on my side, the patch "ASoC: soc-component: use pm_runtime_resume_and_get()" is invalid and shall not be merged. No other problem detected.
