Re: debugging nm256: some results, many questions

[Florian Schlichting <Florian.Schlichting@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Mon, Mar 13, 2006 at 12:58:46PM +0100, Takashi Iwai wrote:
> 
> The writes in snd_nm256_ac97_reset() break the PM resume.  You should
> check reg_accessed[] and use the cached value if already written.

Yes, I just noticed the broken PM resume... The following is just to
check that I don't misunderstand things:

I originally wanted to write the initial values in snd_nm256_mixer(),
but there ac97 is still an ac97_template_t and doesn't have a register
cache. Still, reg_accessed[] is set there, meaning "register may be
touched". Consequently, in snd_nm256_ac97_reset() all usable
reg_accessed[] are already set, which the first time means nothing (and
all registers should be written), but during a resume means the value
shouldn't be touched... So there needs to be another way to distinguish
between these two states.

(I couldn't find any documentation about reg_accessed[], which to me
seems to indicate both "register can be accessed" and later "register
value is cached" - which really are two different things and I wonder
whether they should be kept apart?)

Assuming that when first initialized, all cache registers are set to
0x0000, which is also a valid volume setting, I could probably test for
a non-zero value in AC97_VENDOR_ID1, which would mean I've already done
the initial writing to the cache and it's a resume; otherwise all
registers are to be written.

> Additionally, we may use a static resolution table to skip the volume
> resolution detection with the latest ac97_codec.

I couldn't find any indication of that in 1.0.11rc3. Can you give me a
hint?

Florian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]