On Tue, Dec 01, 2020 at 11:01:21PM +0530, Srinivasa Rao Mandadapu wrote: > On 11/30/2020 6:16 PM, Mark Brown wrote: > > Part of this commit message says that the problem was making the registers > > non-volatile but both the change and the rest of the commit message say > > that the issue was that the registers were made volatile. I'm also > > still unclear as to what the issue is either way - how does reading the > > state of the registers from the hardware instead of the cache affect > > things? > Initial problem was, during playback if device suspended, I2S and DMA > control registers > are getting reset and unable to recover playback after resume. > As these registers were non volatile registers, driver is not getting actual > register value > and unable to report error state to application. Due to this application > keeps on polling for HW current pointer state and not exited from PCM > running state. > Later from review comments by Srinivas kandagatla, I got to know > > about regcache sync APIs, which can be used to sync cache after resume and > > HW registers can be updated with original values. With that playback can be > continued. > > So is the reason, I am reverting partial changes in the commit b1824968221c. I don't understand why a fix for the register cache not being in sync with the hardware doesn't involve syncing the register cache with the hardware.
Attachment:
signature.asc
Description: PGP signature
