RFC: GSM flowcontrol handling, GTA01 and GTA02
andy at openmoko.com
Wed May 28 09:12:54 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
|> didn't (yet) have the patches in the form they should have been. To be
|> honest, I was expecting a few go-rounds of discussions and changes
|> before they would be committed!
Well beauty and functionality are two different things... if we got
feedback about functionality of the patches that is very valuable and
independent of how we might have to rearrange the code for "beauty"
reasons. Since it all remains patches just in "andy" branch we can swap
them out for updated versions real easy.
|> And there is an organization issue I'd like comments on -- I think if we
|> pull the GSM IRQ handler out of mach-gta0x.c and into neo1973_pm_gsm.c,
|> it'll clean up some things. Also, perhaps some of this stuff will be
|> more palatable if it were enabled via Kconfig.
|> I agree with the general principle on keeping GTA-specific things out of
|> the serial driver... but the problem is that issues of one sort or
|> another keep dragging me back into that code. Dealing with some of the
|> GSM issues and requirements from code outside the serial driver is
|> rather like repairing one's roof -- from across the street :-) If there
|> are generic ways we can solve problems instead, we should definitely
|> explore those ways.
The same thing happened in the pcf50xxx drivers, it does not live in its
own little world and blobs out all over the place. But the serial
driver is already upstream, I just imagine Ben Dooks' head exploding
seeing we propose to turn his nice generic s3c24xx serial driver into a
GTAxx serial driver. The most we can expect him to accept in there is
some function pointer hooks in the platform stuff, maybe any true
s3c-specific handshake management functions. (That way if as we suspect
it is a 2410 errata issue we can sell that to Ben).
It doesn't mean changing the functionality of the patches much, just
pouring ALL GTAxx code out from the serial driver into mach-gtaxx.c and
having a tunnel into that from upstream stuff via callbacks or variables
in platform data.
Also the Neospy stuff seems to invade a few places and would be best
conditional on a Kconfig option too as you suggested.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel