Fundamental issues for the ASU
Carsten Haitzler (The Rasterman)
raster at openmoko.org
Fri May 16 17:54:24 CEST 2008
On Fri, 16 May 2008 16:46:48 +0100 Andy Green <andy at openmoko.com> babbled:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Somebody in the thread at some point said:
> | | gah! waiting for the cmdq to flush and it never does. thats bad. too
> | | context switching - lets keep this filed for now?
> | Command queue handling in glamofb -- and it seems from what I saw xglamo
> | contains a cut and paste of it -- had a very bad issue with not having
> | locking around command queue stuff, which is AFAIK modal in the Glamo.
> | I added locking there and various kernel badness on boot went away. So
> | suggest eyeballing it with that in mind.
> |> x wont have any locks in it as its not threaded! :) but good advice in
> |> general! :)
> Did anyone tell glamofb about this :-) Because it can just come in and
> do what it feels like at any time regardless of "not threaded" X state
> or whatever modal juju it has put the glamo into. Dunno what would
> trigger it to do so though.
> I was surprised to see "kernel" code like setting pll rates in xglamo,
> if it is indeed anything to do with the problem maybe the answer is to
> make ioctls to do all that in glamofb under a single locking system.
hmm - this could be it if we suspend.resume - kernel fiddling while the glamo
is busy and cmdq is active... though this shouldnt happen.... as such x would
validly assume no one else is screwing with the glamo while it owns it.
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
Carsten Haitzler (The Rasterman) <raster at openmoko.org>
More information about the distro-devel