[Gta04-owner] Updates for 3.2-gta04 kernel.

[Christoph Mair]

On Sun, Mar 4, 2012 at 11:34 PM, NeilBrown <neilb at suse.de> wrote:
> On Sun, 4 Mar 2012 23:15:37 +0100 Christoph Mair <christoph.mair at gmail.com>
> wrote:
>
>> On Sun, Mar 4, 2012 at 10:46 PM, NeilBrown <neilb at suse.de> wrote:
>> > On Fri, 02 Mar 2012 22:15:01 +0100 Lukas Märdian
>> > <lukasmaerdian at googlemail.com> wrote:
>> >
>> >> Hi,
>> >>
>> >> On 02.03.2012 22:03, NeilBrown wrote:
>> >> > On Mon, 27 Feb 2012 19:00:16 +1100 NeilBrown <neilb at suse.de> wrote:
>> >> >
>> >> >> On Mon, 27 Feb 2012 08:46:15 +1100 NeilBrown <neilb at suse.de> wrote:
>> >> >>
>> >> >>> On Sun, 26 Feb 2012 11:30:03 +0000 Neil Jerram <neil at ossau.homelinux.net>
>> >> >>> wrote:
>> >> >>
>> >> >>>> Any thoughts?  It's not urgent; I can always revert to the previous
>> >> >>>> kernel for the time being.
>> >> >>>
>> >> >>> If you find time for a bit of experimenting, it might be useful to know:
>> >> >>
>> >> >> Actually, don't bother.  I had a bit of a look my self and found something
>> >> >> very silly that almost certainly explains the problem.
>> >> >> I want to do a bit more exploring and testing before I push out a fix, so
>> >> >> just revert to the previous kernel for now.
>> >> >
>> >> > OK, you can try again.
>> >> >
>> >> > I've just pushed out a new 3.2-gta04 with a few fixes.
>> >> >
>> >> >   git://neil.brown.name/gta04 3.2-gta04
>> >> >
>> >> > The USB networking should work the same as before - I found what I broke and
>> >> > fixed it.
>> >> >
>> >> > I have a recurring problem where the GTA04 won't stay asleep.  It wakes
>> >> > immediately after suspending with no real indication why.  I spent a good
>> >> > deal of time trying to figure out why to little avail.  I've added a couple
>> >> > of patches which seemed to make a difference once, but not always.
>> >> >
>> >>
>> >> I had/have the same problem on SHR and learned today that the GPS chip
>> >> will wake the phone from suspend if it is powered on (which is somehow
>> >> randomly choosen at boot time). So you could check if it's the GPS chip
>> >> for you as well.
>> >
>> > Looks like we have a winner!!
>> >
>> > I added some code to my GUI so I can easily check the status of the GPS, and
>> > turn it on and off.  Every time since then that sleep hasn't worked, the GPS
>> > has been on.  Turning it off fixed it.
>> >
>> > Thanks.
>> >
>> > This means I really need to find a good way to make this all automatic -
>> > preferably in the kernel.  There must be a way ...
>>
>> What about this: Enable an interrupt on RX. If it fires multiple times
>> within one second (or maybe more) GPS is switched on. Check again
>> using the same trick after switching it off.
>
> The tty driver owns the RX interrupt (which is already enabled).
> Sure: I could hack the tty driver to do something specific for a certain
> port, but I really don't want to.  That sort of thing would never go upstream.

I didn't think about the serial RX interrupt. I would try to hijack
the PIN (as GPIO or so) from the serial driver and trigger on rising
or falling edges, not on RXed bytes. But this is probably as invasive
as hacking the serial driver and should not be done.

> I've been looking at "line disciplines".  You can register a line discipline
> for each tty - the default being 'N_TTY', others include PPP and SLIP and HCI
> (for bluetooth).
> I'm imagining a line discipline that passes everything through to N_TTY, but
> somehow allows ON/OFF switching (which is automatic at suspend) and
> effectively toggles the line until it reaches the desired state.
>
> You would need some process to open the tty at boot and set the line
> discipline. The process *might* need to stay running to keep the lidisc
> active - I'm not sure.

I've heard about these things once but never looked up what they
really do. Time to do it now.

Christoph