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:
> | 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.
> 
> | btw, probably OT, but made me curious somehow:
> 
> |   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  */
> 
> It's true, but those are different "registers" in the codec over i2c.

Yep, I thought it's OT.
But shouldn't this be direct reads of the *real* registers, for we don't 
use "2-wire"? Otherwise, i guess, ALSA has no idea of the changes that can be 
made to registers via your newly invented device. And maybe would restore the 
old register values whenever you change any of the alsamixer settings (Think 
I read sth about all regs being set in a batch, not only the changed one). 
Anyway, I don't like this, caching of regs where you could read actual value 
as well.

/jOERG
-------------- 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/6a910ba1/attachment.pgp