Re: [PATCH 3/4] ASoC: SDCA: Add basic SDCA class driver

[Charles Keepax <ckeepax@opensource.cirrus.com>]

On Tue, Jan 13, 2026 at 11:05:31PM +0100, Pierre-Louis Bossart wrote:
> On 1/13/26 18:27, Charles Keepax wrote:
> > On Tue, Jan 06, 2026 at 06:10:06PM +0100, Pierre-Louis Bossart wrote:
> >> On 1/6/26 13:58, Charles Keepax wrote:
> >>> On Sat, Dec 20, 2025 at 12:04:47PM +0100, Pierre-Louis Bossart wrote:
> >>>> On 12/10/25 10:55, Charles Keepax wrote:
> >>>>> On Tue, Dec 09, 2025 at 12:47:06PM +0000, Pierre-Louis Bossart wrote:
> >> That means the drivers need to deal with cases where accesses
> >> to devices might be delayed due to slow sync or sync loss. As
> >> long as everything recovers we are good to go.
> > 
> > Yeah that is a point we slightly disagree on, I really am not
> > a huge fan of auto-recovery stuff. Been involved in too many
> > situations where the auto-recovery recovers *most* of the time
> > and takes a 1/10 fail to a 1/10000 fail.
> > 
> > Taking this case, if the device loses sync during audio that
> > is gonna glitch the audio, which makes it a problem I will be
> > expected to fix. I would rather get a report the audio stopped
> > with a log up to that point, than get reports of audio glitches.
> 
> I don't disagree about audio glitches, my main problem is
> with sync loss during initialization or suspend-resume.

I think we are in agreement then, I would consider dropping off
the bus during init or suspend-resume to be times we expect this
to happen and the driver can take care of it.

> Maybe a tangent but if a device loses sync while audio
> is playing, there would be no xrun signaled to the upper
> layers. The bus allocation reserves specific slots for specific
> streams, and the data will be written/read whether there's a
> device or not. That's how we tested the 'virtual' devices to
> create pretend master-only audio cards with no actual codecs
> attached.
> If we really want to report glitches due to sync loss during
> audio playback, we have some plumbing to do. I tested with
> a couple of years ago by forcing a device to reset with a
> debugfs command, it wasn't detected by any ALSA layers.

Slight tangent, my concern is less about where the glitch gets
reported and more that I don't want them to happen.

> >>> Yeah these can be fairly annoying. But both of these can be
> >>> tackled with either handling the situation in probe, or if that
> >>> makes boot too slow, moving to a similar child driver approach.
> >>
> >> Both options are not so good IMHO...
> > 
> > What is it you dislike about them? Just the slower boot, or
> > something more fundamental?
> 
> The slower boot isn't going to be accepted by anyone, and
> in the specific case of HDaudio I don't think anyone has an
> appetite for changing the probe/workqueue approach that's been
> around for many many years.

I mean there is certainly an argument for not mucking around with
HDaudio, it would seem bold at this point. We have been managing with
how things are and its a bus that is coming to the end of its life.

> I don't think creating a child device is much better than
> using a workqueue, in both cases errors during the two-step
> probe can't be handled, you end-up with zoombie devices that
> are probed but not functional.

No more than you end up with a zombie device using a workqueue
system. If the bits in the workqueue don't succeed you have a
device that has probed but is not functional as well. I really
don't see what the difference is there.

As for error propogation seems better with the two devices
setup, everything that is waiting for the child devices knows
they haven't probed yet, so can fail itself.

> The only benefit you get with the child device is that if it
> provides the resources required by the deferred probe you have
> nothing to do. the open is what happens when those resources
> are not present due to sync loss.

I just don't really see why the sync loss thing is different
either. You need to decide in either approach how to handle when
the device loses sync, things depend on functionality provided
regardless of how you structure the driver.

Thanks,
Charles