andy git 06/15 suspend/resume observations

Andy Green andy at
Mon Jun 16 11:41:30 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| On Mon, Jun 16, 2008 at 09:20:15AM +0100, Andy Green wrote:
|> Hash: SHA1
|> Somebody in the thread at some point said:
|> | On Sun, Jun 15, 2008 at 08:08:52PM -0700, Sean McNeil wrote:
|> |> Cons:
|> |> audio pop is still there for me. I don't know if you committed changes
|> |> that should affect it. When I do fully resume and write to the device
|> it
|> |> hangs. Perhaps they are both related to something with DMA? I get
|> around
|> |>
|> | I suspect this is
|> |
|> |
|> |
|> | Rearing its ugly head.
|> Thanks for the hint!
|> | Someone please tell me why I cant read that register successfully
|> | 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?
| Resume has finished by this point, we are in Unfreezing apps and
| user space code is running.
| I set the timeout to be insanely long of 5 minutes and still never got
| a l/r clock. But if you start a new stream within this same period
| l/r clock works fine.

Don't I recall that the timeout got changed to udelay() because it
borked resume?

It is presumably getting called in resume time then, apparently early
enough timers are not up yet.

- -Andy

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list