Andy Green wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Somebody in the thread at some point said: > | Andy Green wrote: > | Hi folks - > | > | I brought over a ton of patches that had accumulated in andy branch into > | stable tonight. Because I had Mike Westerhof's neospy patchset in andy > | but I don't think it belongs in stable, and that patchset is very > | invasive, a lot of patches needed meddling when neospy was removed from > | the picture. So it's possible there might be some breakage in stable, > | but I built it and it seemed OK, audio worked, bluetooth, was able to > | make a test call, etc. > | > |> (I'm still hopelessly busy at my real job, but I did find a bit of time > |> to examine this quickly; hopefully I'll have more time to commit to work > |> on stuff starting this weekend.) > | > |> It looks like more than the neospy stuff got yanked; there's a few > |> vestigial fragments of some of the various changes left (declarations > |> mainly) but nothing that looks like it will change anything from the old > |> behavior. So from my point of view, the new stable has absolutely no > |> improvements for GSM handling on the GTA01 nor does it have any of the > |> GSM flow-control stuff for both 01 and 02. > | > |> Is this intended? If so, what do we need to do to get any improvements > |> into stable? > > First I like it and am willing to have it if it is going to lead to > serial stability. That's why it's in andy branch so anyone can have it > from there.
Yes, but nobody but a couple of developers builds that, so no images actually use the kernel. Honestly, developers don't need the fixes because they're not trying to make the phone work as a phone -- it's the users who need this, and if we're not going to make these changes available in the base kernel built and distributed with each image, then there's really no point, is there? > Second hopefully the patchbomb into stable was the last time we do it > like that. Stuff can go into stable every day unless there is some > reason we choose to freeze it. So there is no window missed here. > > The issues I have with taking it completely in are > > ~ - preprocessor based. It's a bit heavy given how many spy actions > there are. Again, the nspy part is but 3 of the entire patchset that got dumped out. I think it's rather useful, but if this all it takes to keep it out, then, fine, remove it. For goodness sake, it's *DEBUG* code! And it's a very small part of the entire set of changes! (Which, I'll note, were originally packaged at a very fine granularity -- down to the file level -- for exactly the ability to pick and choose what goes in and what goes out!) > ~ - All or nothing. It's not in Kconfig, and it's not enabled or > disabled at runtime. (It needs to be in Kconfig). Again, nspy part -- you can't be serious that the flow-control should be Kconfig? > ~ - forces s3c24xx serial code to know about "gta" (should never appear > in there) Sorry, there's no other way to do it. The GTA console code MUST know that it is suppressed, for reasons I have covered, over -- and over -- and over -- and over again. We can probably implement some horrible awful hackery with callbacks and obscure structs so that we can put a conditional in the console code to prevent the resume race condition from puking all over the GSM, but a simple extern set/cleared by neo1973_pm_gsm code is clearly the simple and obvious way to do it. If this sort of objection is going to prevent the thousands of GTA01's shipped by Openmoko from working correctly, then this is simply shortsighted wrongheaded thinking. Sorry, the GTA01's design was BROKEN and to expect that we can put a patch together to work around it that can be covertly slipped upstream under the guise of something generally useful for all S3c24xx users isn't realistic; OM will have to maintain this patch themselves. > ~ - forces s3c24xx serial code to know about gta GSM port index selection > (needs to be an attribute of the port that it needs the GSM style > handling, and that attribute set in the machine init code) See previous comment. > So these things can be fixed, but overall what I am thinking about is > what Ben Dooks would say about what we are doing to s3c24xx serial code, > particularly if "gta" has leaked anywhere it shouldn't. Again, I repeat this because it's the whole point -- to think that Ben Dooks is going to accept code who's sole function is to work around the botched GTA01 mux and the broken flow control on the GSM chosen for these devices. And honestly, is the resume ordering callback stuff that was added any less obtrusive? Not only is it difficult to read and figure out, it really doesn't do anything to solve any problems. I have no idea why that was added, but I would think that the 2 or 3 lines to suppress the console is no less obtrusive. > The stuff in neo1973_pm_gsm.c is skeletons in our closet so it doesn't > matter so much. But we need to be "gta clean" in platform code, using > callbacks or flag attributes so that we can explain to Ben that we added > cool new support and bugfixes in there that are generic (and there is > some optional instrumentation code in another patch he can take or > leave, and if he takes it the users can Kconfig it out). > > So I am hoping you have time to look at these angles because it seems we > need all the help we can get with the deadly handshaking problems. As you can tell, I'm both extremely busy right now with my real job, and I'm about out of patience. I've reworked this stuff several times now, and repackaged it -- and written dissertations on all of this on my web site and on this list. Honestly, it's not that hard to sort out which patches are debug, which are functional, and which ones we just need to accept as they are because their ugliness reflects the horrors of the hardware beneath. As I said, I'll maintain my own tree for the moment, and be done with it. IMO, the problem is that OM has abandoned the GTA01 entirely, and hasn't run into the problems this stuff will address on the GTA02. When that happens, perhaps that's a better time to get the right attention to this matter. Or perhaps someone else can re-invent the wheel in a manner that they prefer. I grow weary. > - -Andy > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkhsnTUACgkQOjLpvpq7dMoNAQCeIGEOlHnfXfdznW+By/DbGipH > LHgAnRppg1YU7BiVMef5Y4jVIuSHnOgz > =eqqe > -----END PGP SIGNATURE----- > Regards, Mike (mwester)
