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

Dr. H. Nikolaus Schaller hns at goldelico.com
Mon Mar 5 07:10:45 CET 2012


Am 04.03.2012 um 23:34 schrieb NeilBrown:

> 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

Hm. After boot it should be off by default through the internal power up reset.
But it may stay on through a reboot.

>>>> 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.

Or is it possible to write a tty wrapper driver (w2sg0004.ko)? I.e. a "daemon" sitting
in a driver module, that itself presents as another tty (/dev/GPS) and does check the
RX for incoming bytes + forwards this data. And maybe has a second rfkill interface?

I don't know if kernel drivers can "open" and claim a tty port, but maybe they can
since the console is just one of the ports.

> 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.

Interesting approach.

> 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.
> 
> Possibly gsmd could somehow do that for us.

If you need any user-space control, just do everything there and don't split
functionality.

As a shell script it is (with the 2.6.32 kernel) as simple as:

VDD=2800000
echo $VDD >/sys/devices/platform/reg-virt-consumer.5/max_microvolts 2>/dev/null &&
echo $VDD >/sys/devices/platform/reg-virt-consumer.5/min_microvolts 2>/dev/null &&
echo normal >/sys/devices/platform/reg-virt-consumer.5/mode 2>/dev/null &&	#  enable power supply

for i in 1 2 3 4 5
	do
	if read -t 2 </dev/ttyO1 LINE && echo $LINE | fgrep '$GP' >/dev/null
	then
		break
	fi
	echo 0 >/sys/devices/virtual/gpio/gpio145/value &&
	echo 1 >/sys/devices/virtual/gpio/gpio145/value	&& # trigger chip
 	stty 9600 </dev/ttyO1
	sleep 1
done

Nikolaus



More information about the Gta04-owner mailing list