Am Mo 16. Juni 2008 schrieb Andy Green: > Somebody in the thread at some point said: > | Someone please tell me why I cant read that register successfully during > | resume??????? > | > | Its as though the kernel caches it. > > The only way it could "cache" it is if the iis memory mapped register > region of cpu space was literally marked as cacheable, because readl() > is just reading memory. So I think you can read from it OK. > > It doesn't necessarily follow that LRCK is actually toggling at that > time because nulling the test out get you working; something might be > done later that gets LRCK going subsequently. > > For example I notice we disable IIS clock in suspend, this is re-enabled > by the time we start looking? What if s3c24xx_i2s_trigger() -> > s3c24xx_snd_lrsync() happens before resume of IIS that re-enables the > unit clock? > > -Andy > >
btw, probably OT, but made me curious somehow:
1 /*
2 * wm8753.c -- WM8753 ALSA Soc Audio driver
90 /*
91 * wm8753 register cache
92 * We can't read the WM8753 register space when we
93 * are using 2 wire for device control, so we cache them instead.
94 */
95 static const u16 wm8753_reg[] = {
114 /*
115 * read wm8753 register cache
116 */
117 static inline unsigned int wm8753_read_reg_cache(struct snd_soc_codec
*codec,
118 unsigned int reg)
119 {
120 u16 *cache = codec->reg_cache;
121 if (reg < 1 || reg > (ARRAY_SIZE(wm8753_reg) + 1))
122 return -1;
123 return cache[reg - 1];
124 }
signature.asc
Description: This is a digitally signed message part.
