Skip to content

Commit 558f522

Browse files
charleskeepaxbroonie
authored andcommitted
ASoC: SDCA: Update text of FIXME
A couple of attempts to correct this FIXME have been sent upstream but the situation is not quite a simple as the FIXME implies. Update the FIXME to include a better description of the situation. Link: https://lore.kernel.org/linux-sound/20260408085607.3813488-1-shumingf@realtek.com/ Link: https://lore.kernel.org/linux-sound/20260324-sdca-function-status-init-irq-v1-1-bba49417a4e0@gmail.com/ Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260410104500.163337-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
1 parent 72dcd84 commit 558f522

1 file changed

Lines changed: 11 additions & 1 deletion

File tree

sound/soc/sdca/sdca_interrupts.c

Lines changed: 11 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -119,7 +119,17 @@ static irqreturn_t function_status_handler(int irq, void *data)
119119
for_each_set_bit(mask, &status, BITS_PER_BYTE) {
120120
switch (BIT(mask)) {
121121
case SDCA_CTL_ENTITY_0_FUNCTION_NEEDS_INITIALIZATION:
122-
//FIXME: Add init writes
122+
/*
123+
* FIXME: Should this do init writes?
124+
*
125+
* Currently init writes/cache sync are done from the suspend/resume
126+
* infrastructure. It is unclear in what situations one would receive this
127+
* IRQ outside of that flow. Presumably it would be something like the chip
128+
* crashing. In that case however doing the init writes and a cache sync might
129+
* not be sufficient, for example if the failure was during audio playback
130+
* there could be ordering constraints on the register writes to restore the
131+
* state that are not handled by a simple cache sync.
132+
*/
123133
break;
124134
case SDCA_CTL_ENTITY_0_FUNCTION_FAULT:
125135
dev_err(dev, "function fault\n");

0 commit comments

Comments
 (0)