[Gta04-owner] [PATCH 0/4] UART slave device support - version 4

[H. Nikolaus Schaller]

Hi Radek,

Am 21.01.2016 um 12:09 schrieb Radek Polak <psonek2 at seznam.cz>:

> On Thursday 21 of January 2016 11:19:28 H. Nikolaus Schaller wrote:
>  
> > Yes, sure it *can* be hacked differently for this single case (but raising a
> > different set of problems).
>  
> Which are?

You need make initramfs an additional requirement.

Which is some additional project that you have to run. With quite different user expectations. One wants this and the other one wants that included. You end up spending a lot of time in managing this.

Just to make GPS power on/off work.

So this is a different project.

>  
> > And I don't want to require users to use initramfs if everything else works
> > without. Just because of this chip (tail wakes the dog).
>  
> E.g. booting to multiple partitions never worked for my use case - this is solved by initramfs. I will never use stock goldelico kernel anyways, because it cant boot to my partition...

I never understood and still do not understand why it was not possible for you by using the standard boot system and kernel. We have Debian Jessie running. We have Replicant running. In different partitions if required so that you can choose by U-Boot (not initramfs). It is just a run of the ./makesd script away. What else do you need?

IMHO QtMoko should simply sit as apt-get install on top of Stock Debian. And not bundle its own kernel/boot system. This would make it useable for a much broader audience than the GTA04. Of course it must "know" the device it is running on and know how to peek and poke around. But that is not done by the boot process.

The same is what I expect for Replicant. Lukas is already quite succeesful to boot Replicant with the 4.4 kernel. He does not need many patches to the kernel. And the number of patches to Replicant is manageable (mostly with missing dynamic modprobe in Android user space).

>  
> > This does no exclude to use initramfs for other reasons and avoids
> > compatibility problems with different initramfs setups someone might want
> > to use/develop.
>  
> I am just wondering how much energy you put into this marginal problem.

Because the kernel should do what a kernel should do.

But you are right that the point has come where it does not make sense to put in more energy.
This is why I have already stopped the discussion on LKML at this point.

Which means that we simply keep these patches in our Letux kernel.

>  QtMoko in early days never had problems to manage GPS power - no support from kernel except the GPIO was needed. It's just few lines of code. I dont think any other userspace will have problem to implement it - just explain under gta04-kernel docs under GPS section what has to be done.

That would even be a step backwards. We have a set of patches for the Letux kernel where it simply works as I want to have it.

So there is no need to develop anything new. No need to introduce initramfs for the Letux-GTA04 kernels. No need to re-introduce the GPIO. No need to document anything new.

The problem is just that we don't get it into kernel.org this way. Getting it in would on the other side be a big benefit for the overall community. And I would be happy if we would not only focus on our small GTA04 world.

So we do not need to look for another technical solution.

>  
> The real problem is e.g. that my Nokia N900 eats 3mA in suspend and lasts 6day, while GTA04 eats 25mA and needs recharging every day. I personally dont care if turning GPS on/off is 10 lines of code in userspace or 40 lines of code in kernel.

It is more a decision between 0 and 20 lines.

But as we both agree, it is not the most urgent problem. But it is one of the problems to be solved long-run.

Regarding power demand we know what is eating energy:
a) twl4030-phy is not suspended
b) the gta04 hardware does not turn off the CPU XTAL - this is changed in GTA04A5
c) either IrDA or RS232 driver eats power - it is not yet possible to turn off both before the GTA04A5
d) power demand depends on base station sensitivity etc.
e) RAM in suspend (needs some mA for self-refresh)

3 mA is what the OPTION modem draws if we have good reception of base stations (>10 mA if it is weak). Assuming that Nokia does not have a better GSM modem technology than Qualcomm, this means the N900 goes to 0mA in suspend which means the RAM is turned off... I don't know how they do that without suspend to disk.

Could you please find out how they do that? This would help more than developing initramfs.

BR and thanks,
Nikolaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20160121/694567ff/attachment.html>