From: Linus Walleij <linus.walleij@linaro.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] mobile phones
Date: Wed, 28 Jun 2017 16:38:44 +0200 [thread overview]
Message-ID: <CACRpkdYA6Tai+dAJ8Q2w_xEJonuDtHdUnTeJze_8JyX43KntPQ@mail.gmail.com> (raw)
In-Reply-To: <20170625104850.GA24717@amd>
Hi,
just annoying you all with my thoughts on $SUBJECT.
On Sun, Jun 25, 2017 at 12:48 PM, Pavel Machek <pavel@ucw.cz> 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).
I have been trying to get the Qualcomm original DragonBoard working
with the mainline kernel. It is nice in this sense, because it has a
mobile phone(-ish) form-factor.
https://dflund.se/~triad/krad/dragonboard/
The problem I have in general, is that I got this development board
at DesignWest in 2012, and already the Qualcomm people are sort of
indicating to me that they consider the product so ancient that it is
questionable whether it is worth supporting it. Five years is an
eternity for the
business it seems, and I can feel they sometimes could remove their
thumb from the fast-forward button. At least for development boards
given to the community. It's dual-core Cortex A9 and GPU surely can run
the very latest Android if they wanted it to.
It would be nice if the Android (etc) mobile industry as a whole would be
able to do what Apple has actually been doing to a large extent: support
the very latest OS even on very (or quite) old devices. Let the lack in hardware
performance be the motivator to get new hardware, not the lack of
availability of the latest operating system, as is more often than not
the case for Android devices. Having upstream drivers and using the
kernel ABI as the hardware abstraction is the key to achieving that,
and it's weird this is so hard for some to see. Google definitely have
a role to play here.
(The above is also a security-related kernel update factor FWIW.)
> Graphics acceleration is still
> missing.
The GPU vendor mexican-standoff-farce is bound to become the
laughing stock of history. I would put my hopes to the reverse-engineered
drivers like Freedreno or the fine work from the etnaviv people.
> 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.
I don't have the complete picture. It would be nice if vendors were at least
picking up the hardware abstraction we have. Like the IIO HAL for Android
that Intel has been developing for sensor support in Android. I don't understand
why this has simply not been picked up. The other Linux distros have picked
up Bastien Noceras work for IIO userspace integration (iio-sensor-proxy)
just fine.
> 1) Who is responsible for shutting machine down on low battery, and
> not bringing it up unless safe?
I guess this is discussed enough in the thread. But we have a bit of
maintenance problem in the battery framework: noone is working on
creating and/or maintaining a good framework for software-controlled
charging for what I can tell. There is a bunch of disparate hacky drivers
in the kernel for this purpose.
> 5) Do we need suspend-to-RAM to handle power management? If so, how
> can we handle automatic sleep an still be compatible with Unix?
There was some talk about using runtime PM. And runtime PM has improved
vastly recently.
When I tried using it with peripherals on simple slow buses like I2C or SPI
it turned out that noone had really even tried that before, because the core
concepts were wrong. But now it works.
c.f. the simple thing in drivers/iio/light/bh1780.c
I also used runtime PM in a whole slew of onchip peripherals and it works
fine. Ulf Hansson et al are working on improvements to use it also for
CPUs and clusters of CPUs IIRC.
> Plus of course, there's a lot of work to be done to get different
> phones supported.
I'd be happy if I could "just" compile and boot the latest kernel with
the latest AOSP (Android Open Source Project) on the Nokia n900 or
n950 and use it as a smartphone. I would even accept an out-of-tree
GPU driver since everything and its dog requires 3D acceleration these
days. Maybe it would nit even drain the battery in 5 minutes and that
would be GREAT.
As far as I know we not even close to anything like that. Or are there
people actually booting Android on these? Or any other phone form-factor
device running a mainline Linux+Android?
(Insert compulsory do-not-assume-Android, this other $MOBILE_OS
with 0.001% market share is so much more interesting-rant here.
I am talking about what mobile users realistically expects to be able
to run.)
Yours,
Linus Walleij
next prev parent reply other threads:[~2017-06-28 14:38 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
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 [this message]
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=CACRpkdYA6Tai+dAJ8Q2w_xEJonuDtHdUnTeJze_8JyX43KntPQ@mail.gmail.com \
--to=linus.walleij@linaro.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=pavel@ucw.cz \
/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