From: Tony Lindgren <tony@atomide.com>
To: Pavel Machek <pavel@ucw.cz>
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 04:49:31 -0700 [thread overview]
Message-ID: <20170626114931.GG23064@atomide.com> (raw)
In-Reply-To: <20170626111207.GA11688@amd>
* Pavel Machek <pavel@ucw.cz> [170626 04:12]:
> 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.
Well actually it's sort of already there for some use cases as it's been
usable for me for about a month as a low-power laptop/ssh terminal with
Linux next and lapdock or hdmi dock :) Typing away with kernel
4.12.0-rc6-next-20170622 right now.
> > > > 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.
Sure and yes below 3.6V in the MMC case.
> 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.
Yeah probably should be configurable based on some policy.
> > > > 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).
Yeah, there are use cases that are not handled that way
at all currently.
Personally I just stick to standard mainline kernel and standard
distros so problem solved for me by limiting my use cases..
Regards,
Tony
next prev parent reply other threads:[~2017-06-26 11:49 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
2017-06-26 11:49 ` Tony Lindgren [this message]
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=20170626114931.GG23064@atomide.com \
--to=tony@atomide.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=pavel@ucw.cz \
--cc=sebastian.reichel@collabora.co.uk \
/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