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.
Attachment:
signature.asc
Description: PGP signature
