Hi Radek,
Am 21.01.2016 um 12:09 schrieb Radek Polak <[email protected]>:
> 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
_______________________________________________
Gta04-owner mailing list
[email protected]
http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
