[alsa-devel] ASoC: wm9712: Microphone doesn't work, "Capture Volume" inverted

[Mark Brown]

On Tue, May 01, 2012 at 10:07:57PM +0200, Hans J. Koch wrote:
> On Tue, May 01, 2012 at 06:12:07PM +0100, Mark Brown wrote:

> > The driver knows exactly which registers are volatile

> Then this is the first complex chip I've ever seen where the datasheet covers

That's...  horrifying, really.  The WM9712 really isn't at all complex
by modern standards for that matter, but the idea that it's common to
have devices with documented registers that might spontaneously change
in normal operation doesn't seem at all clever.  What happens if the
configuration that was set was important?

> all corner cases. And what about things like dirty supply voltages or EMI?

If you've got that sort of problem with supply quality or EMI there's
obviously a very serious system issue to contend with, one that
typically requires highly aggressive action to resolve - you're starting
to get into games like having to constantly poll the device and restart
it if you detect that it fell over which isn't pleasant and most likely
means you've already hit serious user visible consequences.  Things like
device initialisation will need to be redone, for example.  I can only
think of one driver that takes such measures, and it's actually relying
on restore from register cache for part of the recovery :)

That said, many devices will get a moderate degree of robustness against
this through power saving - the closer the device can get to cold during
idle the better from this point of view, and in many cases it's possible
to completely power down the device when idle.  A common idiom is to
take the device down to cold when idle then dump the setup changes that
don't need sequencing into the device from cache before doing the bits
that need sequencing, especially where many of the register settings can
be mapped direictly into userspace.

Indeed I'm not sure a cache isn't a bad plan for detecting this sort of
thing; if you find the cache values diverging from the physical values
for non-volatile registers you know something's up.

> Just to save a few clock cycles every now and then you happily accept the
> risk of the driver simply stop working after an unusual event, without
> any chances of recovery.

For the sort of devices we're talking about here it's way more than a
few clock cycles that are involved, you're talking about fairly slow
and at times congested buses like I2C here.  Never mind what happens
when someone decides to use a bigbanged controller, which is more common
than one might dream of.  Obviously if you're on a bus with trivial I/O
costs the tradeoffs vary but for the sort of buses we're talking about
it's much easier to see a win.

Indeed with many older devices readback just isn't physically supported
in the first place so if you want to do any kind of readback based thing
you're going to have to cache in some way.  This was true for the
majority of devices at the time WM9712 was new.

> Sound is not my usual playing ground, but at least I learned now why the
> sound system on my desktop refuses to work after a few days uptime...

I don't actually think desktop drivers bother with this much, though 
ICBW.  They relatively infrequently use the slow buses.  I'd suggest
reporting the issue, anyway - it's probably more constructive.

> Fortunately, most other subsystems would never accept such code for mainline.

This is actually a standard feature of the regmap API that drivers can
use if they want, there's a bunch of device classes where it can offer a
useful win (those that typically have slow control interfaces and not so
mnay volatile registers).