From: Pavel Machek <pavel@ucw.cz>
To: Tony Lindgren <tony@atomide.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>,
ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] mobile phones
Date: Mon, 26 Jun 2017 13:12:07 +0200 [thread overview]
Message-ID: <20170626111207.GA11688@amd> (raw)
In-Reply-To: <20170626064947.GF23064@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 3514 bytes --]
Hi!
On Sun 2017-06-25 23:49:47, Tony Lindgren wrote:
> * NeilBrown <neilb@suse.com> [170625 16:56]:
> > On Sun, Jun 25 2017, 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.
>
> Also droid 4 should be getting there eventually too with 3G data working
> and audio driver in progress.
Yes, good luck with Droid 4 getting there.
> > > 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.
>
> Some of the battery monitors actually have a low battery and almost
> empty battery interrupts that can be used to do orderly_reboot().
>
> If no interrupts exist, we should probably have kernel based
> low voltage monitoring and batteryd/libbattery as documented in
> Documentation/power/power_supply_class.txt.
>
> The reason why I think we need kernel based voltage monitoring for is
> that some devices may need a higher voltage for the MMC file system
> for example while the rest of the system could still keep running with
> a lower voltage and file system corruption can happen.
>
> Maybe setting up the battery as a regulator for the drivers would
> be the simplest solution to allow drivers to do something when the
> battery voltage is low enough?
Well, I agree that kernel should handle this somehow, but I don't
believe drivers should monitor the voltage themselves. We are talking
about battery voltages below 3.6V, right? At that point, we are
already damaging the battery, and the battery is "soft" meaning
voltage will vary with load a lot. Just because voltage was 3.31V few
miliseconds before does not mean it is not be 3.1V now.
We are already damaging the battery, and I believe right solution is
to either shut down or put the machine into deep sleep, and wait for
power to be reapplied.
> > > Plus of course, there's a lot of work to be done to get different
> > > phones supported.
>
> Yeah it's the typical Linux kernel popularity contest where the devices
> that people use get (and should get) more support. We've already seen
> who little the vendors care about upstreaming support for their
> devices, probably no easy way around that.
Well, the problem seems to be two fold:
1) very few phones have usable kernel support
(and it is not even clear how the ideal kernel support should look,
because kernel/user interfaces are missing or inadequate)
2) normal distributions do not have support for phones
(-> testing is hard because you have to develop both kernel and
userland tests, and motivation is low).
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-06-26 11:12 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-25 10:48 Pavel Machek
2017-06-25 23:55 ` NeilBrown
2017-06-26 6:43 ` Geert Uytterhoeven
2017-06-26 6:49 ` Tony Lindgren
2017-06-26 11:12 ` Pavel Machek [this message]
2017-06-26 11:49 ` Tony Lindgren
2017-06-26 13:14 ` Pavel Machek
2017-06-26 13:49 ` Tony Lindgren
2017-06-26 20:49 ` Pavel Machek
2017-06-27 7:18 ` Tony Lindgren
2017-06-27 12:14 ` Sebastian Reichel
2017-06-27 21:57 ` Pavel Machek
2017-06-28 16:01 ` Sebastian Reichel
2017-06-28 20:27 ` Pavel Machek
2017-07-02 12:03 ` Sebastian Reichel
2017-06-27 21:57 ` Pavel Machek
2017-06-26 8:34 ` Pavel Machek
2017-06-26 11:20 ` Mark Brown
2017-06-26 12:22 ` Pavel Machek
2017-06-27 11:40 ` Mark Brown
2017-06-28 18:37 ` Pavel Machek
2017-07-02 12:11 ` Sebastian Reichel
2017-06-26 22:23 ` Alexandre Belloni
2017-06-27 7:06 ` Pavel Machek
2017-06-27 12:39 ` Sebastian Reichel
2017-06-27 21:57 ` Pavel Machek
2017-06-28 16:45 ` Sebastian Reichel
2017-06-28 21:10 ` Pavel Machek
2017-07-02 11:28 ` Sebastian Reichel
2017-07-02 18:14 ` Pavel Machek
2017-06-26 10:54 ` Mark Brown
2017-06-26 11:14 ` Pavel Machek
2017-06-26 11:49 ` Mark Brown
2017-06-26 12:38 ` Pavel Machek
2017-06-26 16:34 ` Mark Brown
2017-06-27 11:41 ` Sebastian Reichel
2017-06-28 14:38 ` Linus Walleij
2017-06-28 15:58 ` Arnd Bergmann
2017-06-28 16:04 ` Laurent Pinchart
2017-06-28 16:25 ` Pavel Machek
2017-06-28 18:26 ` Mark Brown
2017-06-28 17:01 ` Pavel Machek
2017-06-28 19:03 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170626111207.GA11688@amd \
--to=pavel@ucw.cz \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=sebastian.reichel@collabora.co.uk \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox