RE: [PATCH] ASoC: rt1320: make SRAM registers readable to stop being cached

[Jack Yu <jack.yu@realtek.com>]

> -----Original Message-----
> From: Mark Brown <broonie@kernel.org>
> Sent: Monday, September 21, 2026 5:11 PM
> To: Jack Yu <jack.yu@realtek.com>
> Cc: lgirdwood@gmail.com; alsa-devel@alsa-project.org; lars@metafoo.de;
> Flove(HsinFu) <flove@realtek.com>; Oder Chiou <oder_chiou@realtek.com>;
> Shuming [范書銘] <shumingf@realtek.com>; Derek [方德義]
> <derek.fang@realtek.com>
> Subject: Re: [PATCH] ASoC: rt1320: make SRAM registers readable to stop being
> cached
> 
> On Mon, Sep 21, 2026 at 03:28:47PM +0800, jack.yu@realtek.com wrote:
> > From: Jack Yu <jack.yu@realtek.com>
> >
> > rt1320_volatile_register() lists the SRAM ranges 0x10000000-0x10008fff
> > and 0x1000c000-0x1000dfff as volatile, so they should never be cached.
> > But regmap only honors the volatile flag for a readable register, and
> > these ranges were missing from rt1320_readable_register().
> > They were therefore cached at probe and replayed over SoundWire on
> > every runtime resume, delaying the first PCM open after autosuspend by
> > about a second.
> >
> > Add the two ranges to rt1320_readable_register() so the volatile flag
> > takes effect and the SRAM is no longer cached or replayed.
> > The removed lines are already covered by the  new
> > 0x1000c000-0x1000dfff range, so no register loses readability.
> 
> The RAE loader seems to expect that 0x1000d000-0x1000d7ff is cached, or at
Thanks for reminding this, I'll exclude this range 0x1000d000-0x1000d7ff out of the volatile registers.

> least it's fiddling with the cache bypass for that range.