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

[Mark Brown <broonie@kernel.org>]

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

On Thu, Mar 13, 2014 at 08:09:25AM +0100, Mike Looijmans wrote:
> On 03/13/2014 12:31 AM, Mark Brown wrote:

> >As a first order fix the driver should just refuse to reconfigure if the
> >clocks are active.

> Which would result in the driver often failing to work and the user having
> no clue why.

Print an error message.

> >The big problem with shutting down is disruption to other activity - if
> >there's something going on using the clocks.  For some devices that
> >don't have long startup times ignore_pmdow_time may help a lot.

> The bias level can remain where it is, it's just the DACSETUP or ADCSETUP
> bits that need toggling. They're independent, so only the affected parts
> need to stop. Using ignore_pmdow_time would result in the codec going to a
> lower bias state, and that is not what should happen here. Restarting the
> ADC or DAC is just a matter of milliseconds, but a complete power-down will
> result in reference voltage instability and capacitors recharging, and it
> may take several minutes for the system to completely recover from that.

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

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.

> I'm mostly asking to think about the "big picture" here. As a generic case,
> not specific to this codec.

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.

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

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