andy git 06/15 suspend/resume observations

[Joerg Reisenweber]

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 }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-kernel/attachments/20080616/a47c65a8/attachment.pgp