Re: tlv320aic32x4 Codec ADC and DAC must shutdown to alter clocks

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2943 bytes --]

On Fri, Mar 14, 2014 at 10:47:50AM +0100, Mike Looijmans wrote:

Don't drop CCs on kernel lists if you want people to read replies - the
bit about always CCing maintainers applies too...

> >*Any* glitch in an active digital audio path will be noticable to users,

> The reconfiguration only occurs when switching from say 44100 to 48000
> sampling rates (but not when going from 24 to 16 bits, for example). I don't
> think users will actually expect a switch from one sampling rate to another
> to proceed without any glitch or delay.

This has a wider effect than just the digital playback path though
doesn't it - the capture path for example, and if this is a modern
device there's doubtless charge pumps in play.

> >If you're taking several minutes to do a bias level transition there's
> >something seriously wrong with either the hardware or with the way it's
> >being managed by the driver.

> Good enough for human ears, but this project uses codecs for measurement and
> is sensitive to microvolt changes in reference voltages and such. The
> audible effects are gone in less than a second, but the measurable effects
> last a lot longer.

Less than a second still sounds like an awfully long time here and if
you've got constraints like this it sounds like you need to force the
device to be always running anyway.  Glancing at the code we're only
managing clocks in the bias level operations...

> >The general solution here is essentially don't do that; if the hardware
> >is fragile on reconfiguration you will tend to end up hitting cases
> >where trying to do a reconfiguration will glitch or fail so the sound
> >server will generally fix the configuration and handle things in
> >software.  Otherwise pmdown_time is the general solution for modern
> >devices with quick startup/shutdown times, older devices probably need
> >some custom hacks.

> It's not about "fragile", it's about managing codec power states. For some
> transistions, like clock changes, a codec will likely need to go to a lower

It certainly sounds a lot like it's fragile - there seem to be fairly
tight constraints on reconfiguring, you're saying it's hard to implement
something that bounces the power around reconfiguration, the device
requires symmetric rates so it won't cope if there's capture activity
too and who knows what happens with the analogue bypass paths.

Equally well you've not been specific about anything so it's possible
that the restrictions and/or what needs doing are looser than you're
making them sound; looking at the code I'm not seeing anything except
clocks being managed as part of the bias level management and there's no
effort to selectively manage the clocks.

> state. The current core does not even attempt to mute the DAC for example.

Yes it does - you can only reconfigure the sample rate for the audio
stream when it's not running and we mute (if the device supports it)
whenever the audio stream is halted.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]