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

[Radek Polak]

On Thursday 21 of January 2016 13:05:27 Andreas Kemnade wrote:

> I must admit that I have never used qtmoko kernels because of that 
initramfs
> because I do not want to /dev/mmcblk0p1 to be touched by anything
> automatically. Just because power might end at a bad moment and there 
might
> be no bootable kernel.

Well i dont think it's the case. The gta04-init mounts only the partition that 
you tell it to mount (e.g. via config file, or touch screen) and boots into it. 
Just the mount command is done from userspace and can be very nicely 
customized compared to "stupid" root kernel option.

Btw there was talk about "daemon" but daemon is IMO not needed at all, 
just single check during init that GPS is powered off.

> Well the problem is solved in some way. It is just about getting the
> solutions accepted. That takes energy and if successful not only solves
> GTA04 stuff but also other solutions. But that is the general problem of
> upstreaming. You have your working solution and then put extra energy 
into
> it which does often not give anything as reward (in short term).

Yup understand. But i could understand if the upstreaming is rejected.  
Growing general kernel code because of 100 users while there is simple 
userspace 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.
> 
> Well, I prefer working, standard interfaces. If the general rule is that
> kernel is powering down things which are not used, than I want that.
> Another solution I could life if rfkill can at least do everything.

Agree that toggling rfkill during init should be easily doable for any 
userspace. 

BR

Radek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.goldelico.com/pipermail/gta04-owner/attachments/20160121/89e43190/attachment.html>