On Wed, Feb 09, 2022 at 06:20:00PM +0100, Ricard Wanderlof wrote:
In this case it was the ADAU1761 driver and it was several years ago and I don't know if it still is an issue. Basically the sequence was something like:
- System boots up.
- Codec is configured (I think it was the sample rate, but it could have been the format or some other I2S parameter) to something that is non default.
- System reboots. Since the codec has no means of getting reset, it retains all its register values.
- This time, an attempt is made to configure the codec with the default sample rate. Since the driver believes the default is already set it does not attempt to write anything, although looking at regmap_write() now I'm not sure how this could be the case.
update_bits() could also trigger this if it thinks the value didn't change, but that's at a higher level before it ever gets as far as trying to do the write and unrelated to the cache (it will also suppress redundant writes with no cache present).
- When codec is started, the sample rate / format / whatever is wrong compared to what was allegedly set up.
It was all rather academic, because the above sequence only occurred in the lab under manual control; in the actual production code the same format and sample rate was used every time, so it wasn't an issue that was pressing to fix. It could as you said have been a bug somewhere else. I distinctly remember the last point about the codec running in seemingly the wrong mode after a (power-cycle-less) reboot at any rate.
A soft reboot could trigger something like that, the easiest fix would just be to not specify any register defaults so that there's no default values to compare with.