[alsa-devel] tlv320aic32x4 Codec ADC and DAC must shutdown to alter clocks

[Mike Looijmans]

On 03/13/2014 03:04 PM, Mark Brown wrote:
> 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,

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.

> 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.


>> 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.

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 
state. The current core does not even attempt to mute the DAC for example.

Well, custom hacks is 95% of what i've done to the driver (and I hacked a few 
lines in the core as well to get what I wanted). I was hoping to lower the 
"custom" part a bit in future.



Met vriendelijke groet / kind regards,

Mike Looijmans

TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) (0) 499 33 69 79
Telefax:  (+31) (0) 499 33 69 70
E-mail: mike.looijmans at topic.nl
Website: www.topic.nl

Please consider the environment before printing this e-mail