On Wed, Feb 09, 2022 at 03:53:28PM +0100, Ricard Wanderlof wrote:
On Tue, 8 Feb 2022, Mark Brown wrote:
On Mon, Feb 07, 2022 at 06:12:06PM +0100, Ricard Wanderlof wrote:
Other than resyncing the cache (and see below for that) a cache will affect reads not writes, writes should be affected unless the driver turns on cache only mode.
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().
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.