On Wed, 9 Feb 2022, Mark Brown wrote: > > Isn't one consequence of caching that writing to a register which is known > > to already have the value to be written are simply skipped? > > No, look at the code for regmap_write(). Thanks. Good. Should have checked. I had the case previosly described deeply ingrained in my mind since it was an elusive issue at the time. > > I remember having that problem with a codec which did not have any means > > of resetting the codec other than power-on-reset (i.e. no reset pin or > > software controlled reset). If the system was rebooted without cycling the > > power, the registers would potentially contain non-default values, and > > this meant that for instance attempting to explicitly set the sample rate > > to the default value was not possible, as the regcache assumed that the > > default value was already set and thus skipped the corresponding register > > This is during a cache sync, a sync will only write out non-default > values if the device was flagged as having been reset in order to reduce > power on times. Your driver is not doing a cache sync at any point so > won't be affected by this, but in any case... > > > write. (A workaround was to write another sample rate and then default). > > If your driver has no way of ensuring that the device has default > register values your driver should just not specify any register > defaults, but in this case it sounds like you have some other bug going > on. If the device is getting suspended with a default value set in the > registers then comes out of suspend with a non-default value it's hard > to see how that could happen in the hardware, either the device will > retain the value it had or it will reset to power on default but either > way it's the same value. I have seen drivers bypassing the cache for a > shutdown sequence that wrote non-default values to the hardware without > updating the cache. 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. - 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. /Ricard -- Ricard Wolf Wanderlof ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30
