Re: [Ksummit-discuss] [TECH TOPIC] mobile phones

[Sebastian Reichel <sre@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 4055 bytes --]

Hi,

On Mon, Jun 26, 2017 at 10:34:07AM +0200, Pavel Machek wrote:
> > > Situation around mobile phones is only improving very slowly. We now
> > > have hardware that is supported in the mainline kernel in useful way
> > > (Mitac Mio A701, Nokia N900, N9, N950). Graphics acceleration is still
> > > missing.
> > >
> > > But there are major pieces missing: first is userspace. That's not for
> > > us to solve. Then there's some kind of hardware abstraction layer;
> > > kernel currently does NOT provide enough information for userland to
> > > autoconfigure everything.
> > >
> > > There are big questions about kernel / user interface. We have whole
> > > subsystems missing. They include:
> > >
> > > 1) Who is responsible for shutting machine down on low battery, and
> > > not bringing it up unless safe?
> > 
> > My laptop hibernates when the battery level gets too low. Why should a
> > phone be any different?  User-space monitoring and policy seems a
> > suitable answer.
> 
> Phone is different... and I'm not talking orderly_shutdown here.
> 
> Boot your notebook with init=/bin/bash, and launch fsck on low
> battery. It will blink, it may beep, but in the end it will power off
> abruptly at maybe 3.6V per cell, before battery is damaged. Now try
> the same on N900. It will not blink, and it will run battery down to
> less then 3.0V; various components will fail, you'll get screen
> flicker, and presumably your MMC will be _really_ unhappy. Eventually,
> CPU fails, machine reboots, and machine will attempt to do _the same
> again_.
> 
> Basically we are missing one layer of protection here, compared to the
> PC case.

It should be fine to add something like Tony's orderly_poweroff to
the rx51 battery driver.

> > I think the "not bring up unless safe" decision needs to be made in
> > the boot-loader.  Once Linux boots, it tends to turn everything on,
> > then the unneeded things back off.  That is no good if all you want to
> > do is start the battery charging.  Changing this approach would need
> > a lot of work and buy-in from lots of people.  I doubt it will
> > happen.
> 
> Problem is that bootloader does not even know about battery charging,
> and is far from having required drivers. That's why I'd try to get
> buy-in ;-).

Actually Nokia Loader does know about battery charging and does so
for really empty batteries. Once the battery is full enough it tries
to boot operating system with better monitoring capabilities,
though.

> > > 3) How to handle differences between GSM modems and between GPS
> > > receivers? Is AT commands/NMEA good enough? What about AGPS upload?
> > 
> > My limited exposure to the different varieties of GSM and GPS protocols
> > that are supported suggests that this needs to be done in user-space.
> > There isn't any suitable abstract protocol that we could implement in a
> > kernel interface.
> > gpsd handles multiple GPS protocols and meets a lot of needs.  If it
> > isn't perfect, it can probably be improved.
> 
> It is not perfect, indeed.
> 
> So we currently have GPSes on serial, producing NMEA. Gpsd there may
> be good enough. But then we have different hardware, not producing
> NMEA (GPS on N900 is exposed as network packet over PHONET
> interface, there's drivers/usb/serial/garmin_gps.c with who-knows-what
> interface)... and it would be nice to have good, "native" GPS
> interface which would work in this case. (We'd like timestamps for
> incoming data and lat/long/alt + speed in lat/long/alt + error in
> lat/long/alt sampled at the same time, at the very least).
> 
> Its similar to mice, really. We used to have gpm, now we have real
> drivers.
> 
> Plus there's still issue of AGPS data upload.

On N950 there is an unsupported gps connected via i2c iirc (with
unknown protocol that needs to be RE'd) and TI's WiLink provides
GPS on a shared UART link with bluetooth-style header using yet
another protocol. I agree, that we should have a GPS subsystem.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]