ASoC: Fix races on creation of SDCA jack detection
authorMark Brown <broonie@kernel.org>
Mon, 27 Jul 2026 17:47:11 +0000 (18:47 +0100)
committerMark Brown <broonie@kernel.org>
Mon, 27 Jul 2026 17:47:11 +0000 (18:47 +0100)
commitfc810085f6c8125866ffe04e6909107a539ee949
treebf3ff747a8f2270e7637dee0ca834aa4e8b6588f
parent52a3a0cc28bf6fd8b38ef6c81b21f948bf13996a
parentbf1b7821f85383a8804441f8fd5165be148f3ec8
ASoC: Fix races on creation of SDCA jack detection

Charles Keepax <ckeepax@opensource.cirrus.com> says:

Currently there exists a couple races that can result in the DAPM graph
coming up in a state that doesn't match the hardware with respect to
SDCA jack detection. This series fixes these up by adding a component
level fixup_controls helper into the asoc core and shuffling around the
IRQ requests from the SDCA side.

The core creates DAPM widgets/routes quite a long time before
it creates the associated ALSA control, and the jack detection
IRQ is currently registered in component probe. At the time of
component probe, the DAPM widgets exist, shortly after this the
DAPM routes are added. At the time the DAPM routes are added the
register value for the control is checked and the appropriate path
is connected. The existing handling in the SDCA jack IRQ handles
the case the control doesn't exist and updates the registers
directly, which works until the DAPM routes are added.  After the
routes are added the DAPM graph has already set connected on a
particular DAPM path, which will not be updated until an IRQ is
received when the control is present. Thus those updates are
usually not reflected in the resulting DAPM graph which can lead
to the audio path being erroneously powered on/off.

Link: https://patch.msgid.link/20260721143636.361814-1-ckeepax@opensource.cirrus.com
sound/soc/sdca/sdca_fdl.c