[Ksummit-discuss] [TECH TOPIC] mobile phones

[Ksummit-discuss] [TECH TOPIC] mobile phones

[Pavel Machek]

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

Hi!

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?

2) How to handle GSM audio?

3) How to handle differences between GSM modems and between GPS
receivers? Is AT commands/NMEA good enough? What about AGPS upload?

4) How to handle accelerated RGB LEDs?

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?

6) Do we provide compatibility for old v4l2 apps on complex hardware,
or do we wait for libv4l to get support? How do we provide information
such as camera aperture to the userspace?

...and probably many more.

Plus of course, there's a lot of work to be done to get different
phones supported.

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 --]

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

[NeilBrown]

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

On Sun, Jun 25 2017, Pavel Machek wrote:

> Hi!
>
> 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.
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.

>
> 2) How to handle GSM audio?

What is the issue here?  Isn't GSM audio just another audio source/sink
which user-space can send where-ever it likes?

>
> 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.
An equivalent "gsmd" with pluggable back-ends seems like the right
approach.  I think there are several contenders already.

>
> 4) How to handle accelerated RGB LEDs?

This does sound like a kernel issue.   The hardware has limited
programmability so that different patterns and colors are possible.
Maybe we want to enhance the LED trigger mechanism to apply to
colour LEDs.
I guess that we need a concrete proposal so that it can be assessed.

>
> 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?

My feeling is that until someone proves otherwise, suspend-to-RAM should
be assumed necessary.  It should be possible to get the same power
saving with runtime suspend, but that requires all of user-space to
co-operated, which is like "herding wild cats".

I don't really know what "compatible with Unix" means in this context.

There are really two options:
1/ applications which specific cpu-availability needs explicitly
   after for the CPU to be kept available - i.e. "wake locks"
2/ applications that don't have specific cpu-availabilty needs
   don't use the cpu at all when they don't need it.

The first means we suspend-to-RAM, but have "wake lock" calls
in code.
The second means that all code is very careful not to be wasteful, and
we rely on runtime PM.
Neither are very "Unixy".

Is this a kernel issue at all?  User-space can take either approach, and
struggle with the difficulties.

>
> 6) Do we provide compatibility for old v4l2 apps on complex hardware,
> or do we wait for libv4l to get support? How do we provide information
> such as camera aperture to the userspace?

I cannot comment on this one.

>
> ...and probably many more.
>
> Plus of course, there's a lot of work to be done to get different
> phones supported.


Thanks,
NeilBrown

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

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

[Geert Uytterhoeven]

On Mon, Jun 26, 2017 at 1:55 AM, NeilBrown <neilb@suse.com> wrote:
>> 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?
>
> My feeling is that until someone proves otherwise, suspend-to-RAM should
> be assumed necessary.  It should be possible to get the same power
> saving with runtime suspend, but that requires all of user-space to
> co-operated, which is like "herding wild cats".

... and the firmware, on architectures where implementing this inside the
kernel is forbidden by policy.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Tony Lindgren]

* 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.

> > 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?

> 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.

Yes I agree. And for kernel, if the battery voltage is known to
device drivers, they can refuse to mount file system and whatever
needs to be done.

> > 2) How to handle GSM audio?
> 
> What is the issue here?  Isn't GSM audio just another audio source/sink
> which user-space can send where-ever it likes?

At least some modems output no audio data on signal dropouts :)

> > 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.
> An equivalent "gsmd" with pluggable back-ends seems like the right
> approach.  I think there are several contenders already.

Some of these might be using the old serial multiplexing protocol
27.010 that we have drivers/tty/n_gsm.c?

> > 4) How to handle accelerated RGB LEDs?
> 
> This does sound like a kernel issue.   The hardware has limited
> programmability so that different patterns and colors are possible.
> Maybe we want to enhance the LED trigger mechanism to apply to
> colour LEDs.
> I guess that we need a concrete proposal so that it can be assessed.
> 
> >
> > 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?
> 
> My feeling is that until someone proves otherwise, suspend-to-RAM should
> be assumed necessary.  It should be possible to get the same power
> saving with runtime suspend, but that requires all of user-space to
> co-operated, which is like "herding wild cats".

Well runtime suspend still works way better _if implemented_ :p
It does not leave out the option for suspend, it's just that nobody
cares to implement proper runtime suspend based power management
for a SoC that will be around for two years.

> I don't really know what "compatible with Unix" means in this context.

Timers don't run when a device is suspended :)

> There are really two options:
> 1/ applications which specific cpu-availability needs explicitly
>    after for the CPU to be kept available - i.e. "wake locks"
> 2/ applications that don't have specific cpu-availabilty needs
>    don't use the cpu at all when they don't need it.

3/ If proper runtime suspend based PM is implemented, it's possible to
   SIGSTOP non-critical apps when screen blanks or whatever the policy
   is :)

> The first means we suspend-to-RAM, but have "wake lock" calls
> in code.
> The second means that all code is very careful not to be wasteful, and
> we rely on runtime PM.
> Neither are very "Unixy".

Yeah these are needed for 1 & 2 above.

> Is this a kernel issue at all?  User-space can take either approach, and
> struggle with the difficulties.

Probably we have most of the pieces already in kernel, it's just a
quetion how much PM gets implemented for any give device.

> > 6) Do we provide compatibility for old v4l2 apps on complex hardware,
> > or do we wait for libv4l to get support? How do we provide information
> > such as camera aperture to the userspace?
> 
> I cannot comment on this one.
> 
> >
> > ...and probably many more.
> >
> > 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.

Regards,

Tony

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

[Pavel Machek]

[-- 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 --]

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

[Tony Lindgren]

* 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

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

[Pavel Machek]

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

Hi!

> > > > 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.

Do you have X running in useful configuration?

> > > 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.

Well, battery at 3.6V has < 1% of its capacity remaining. So even
aside from battery damage, your system will not run much longer if you
keep it running.

> > 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..

Well, I'm currently doing the same. On N900, I have X running (miss
right button on the touchscreen, and 800x480 is a bit small),
gprs/edge/umts data working, so I have usable ssh and web
browser. (But bufferbloat is ugly and reconnections are not handled
well). SMSes work. WIFI works (with exception of networkmanager). GPS
is usable. Camera is useful, including autofocus, but limited to
1.2MPix. It lasts for a "day" which is good enough.

Biggest problem I have now is poor quality of audio calls... Fixing
that would enable me to make it my primary phone...

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 --]

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

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [170626 06:14]:
> Hi!
> 
> > > > > 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.
> 
> Do you have X running in useful configuration?

Yeah for most part I'm using X with HDMI, LCD works but there are six
out of tree omapdrm patches that need more work similar to n950. Also
the LCD backlight patch is also still pending.

> > Personally I just stick to standard mainline kernel and standard
> > distros so problem solved for me by limiting my use cases..
> 
> Well, I'm currently doing the same. On N900, I have X running (miss
> right button on the touchscreen, and 800x480 is a bit small),
> gprs/edge/umts data working, so I have usable ssh and web
> browser. (But bufferbloat is ugly and reconnections are not handled
> well). SMSes work. WIFI works (with exception of networkmanager). GPS
> is usable. Camera is useful, including autofocus, but limited to
> 1.2MPix. It lasts for a "day" which is good enough.

OK to get to that point droid 4 still needs audio calls, camera,
and GPS at least. And PM needs more work. For reference, Sebastian
Reichel has pretty good mainline driver status matrix for both n900
and droid 4 on his website.

> Biggest problem I have now is poor quality of audio calls... Fixing
> that would enable me to make it my primary phone...

That's with HSI modems, right?

Regards,

Tony

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

[Pavel Machek]

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

Hi!

> > > > > > 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.
> > 
> > Do you have X running in useful configuration?
> 
> Yeah for most part I'm using X with HDMI, LCD works but there are six
> out of tree omapdrm patches that need more work similar to n950. Also
> the LCD backlight patch is also still pending.

HDMI is nice; that's a feature I'd like. And I guess you also have
real and working USB host?

Anyway I was interested... do you have useful X running on localhost?
I mean... finger is too big to control X applications, and you have
capacitive touchsreen, right?

> > > Personally I just stick to standard mainline kernel and standard
> > > distros so problem solved for me by limiting my use cases..
> > 
> > Well, I'm currently doing the same. On N900, I have X running (miss
> > right button on the touchscreen, and 800x480 is a bit small),
> > gprs/edge/umts data working, so I have usable ssh and web
> > browser. (But bufferbloat is ugly and reconnections are not handled
> > well). SMSes work. WIFI works (with exception of networkmanager). GPS
> > is usable. Camera is useful, including autofocus, but limited to
> > 1.2MPix. It lasts for a "day" which is good enough.
> 
> OK to get to that point droid 4 still needs audio calls, camera,
> and GPS at least. And PM needs more work. For reference, Sebastian
> Reichel has pretty good mainline driver status matrix for both n900
> and droid 4 on his website.

Well, camera is something I'm playing with, not a requirement. Can
live without GPS, but would prefer not to. But audio, audio is
mandatory :-).

Ah, thanks for the pointer. Built-in battery is very bad for
debugging, and very bad when PM is not quite finished. But I remember
droid4 was something that disqualified it for European use. Aha, LTE @
700MHz, which is not available here. Hmm, but GSM/UMTS works in v4.12
according to the table, so that's not too bad.

Does ofonod support the modems in an useful way?

Is GSM connected directly to the audio, or does it need real-time
task, similar to N900?

It looks like nice machine. OTOH N950 looks like a nice machine, too,
and N900 is actually nicer because of the resistive touch, battery,
and friendly bootloader...

> > Biggest problem I have now is poor quality of audio calls... Fixing
> > that would enable me to make it my primary phone...
> 
> That's with HSI modems, right?

Yes.

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 --]

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

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [170626 13:49]:
> HDMI is nice; that's a feature I'd like. And I guess you also have
> real and working USB host?

Yeah USB host works, so far only with battery VBUS so unable to power
all devices. I think there's a proper VBUS regulator too but I need to
look around more for it.

> Anyway I was interested... do you have useful X running on localhost?
> I mean... finger is too big to control X applications, and you have
> capacitive touchsreen, right?

I use i3 so I did not even note that right now atmel_mxt_ts no longer
works for me in next.. But yeah I can point to screens and activate
them. So far I have not needed anything more complex.

> Ah, thanks for the pointer. Built-in battery is very bad for
> debugging, and very bad when PM is not quite finished. But I remember
> droid4 was something that disqualified it for European use. Aha, LTE @
> 700MHz, which is not available here. Hmm, but GSM/UMTS works in v4.12
> according to the table, so that's not too bad.

Hmm the battery can be disconnected with t5.. And watchdog works.. But
we still need to somehow produce sysrq with power button + volume
down. In this case those are in separate drivers, gpio-keys for
volume down and then cpcap-pwrbutton. I'm also pretty sure the PMIC
supports powerdown on pressing down the power button some some seconds
but I have not found that bit so far :)

> Does ofonod support the modems in an useful way?

No idea, I've only used qmicli so far.

> Is GSM connected directly to the audio, or does it need real-time
> task, similar to N900?

The audio mixer is on CPCAP PMIC, and I think mdm6600 modem audio needs
help from the Linux kernel on the applications processor as it probably
goes to it first then to CPCAP PMIC. I guess it's possible that mdm6600
audio goes directly to CPCAP PMIC too.

I believe LTE modem is connected to the second SPI interface on the
CPCAP PMIC and can use it directly for audio depending on how Linux
kernel configures the PMIC secondary interface device access. What
seems to be a similar PMIC for the CPCAP internal devices is documented
in MC13783UG.pdf on NXP site so that might be worth looking at for
the audio overview.

> It looks like nice machine. OTOH N950 looks like a nice machine, too,
> and N900 is actually nicer because of the resistive touch, battery,
> and friendly bootloader...

Sure, my n950 just got so worn down I was afraid I don't have any
replacement. And we need some kind of potential community upgrade for
n900/n9/n950 anyways while waiting for better devices :)

Regards,

Tony

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

[Sebastian Reichel]

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

Hi,

On Tue, Jun 27, 2017 at 12:18:36AM -0700, Tony Lindgren wrote:
> > Does ofonod support the modems in an useful way?
> 
> No idea, I've only used qmicli so far.

There is a qmi plugin for ofono, but I also just used qmi utils [0]
so far.

[0] https://packages.debian.org/sid/libqmi-utils

> > Is GSM connected directly to the audio, or does it need real-time
> > task, similar to N900?
> 
> The audio mixer is on CPCAP PMIC, and I think mdm6600 modem audio needs
> help from the Linux kernel on the applications processor as it probably
> goes to it first then to CPCAP PMIC. I guess it's possible that mdm6600
> audio goes directly to CPCAP PMIC too.
> 
> I believe LTE modem is connected to the second SPI interface on the
> CPCAP PMIC and can use it directly for audio depending on how Linux
> kernel configures the PMIC secondary interface device access. What
> seems to be a similar PMIC for the CPCAP internal devices is documented
> in MC13783UG.pdf on NXP site so that might be worth looking at for
> the audio overview.

GSM audio is connected to the audio codec using digital audio
interface. The audio data normally does not flow through the CPU
(but as far as I can see it could be routed that way, if desired).
So no need for any low latency stuff on CPU side. Actually no need
to do anything except for proper setup of modem & audio codec :)

> > It looks like nice machine. OTOH N950 looks like a nice machine, too,
> > and N900 is actually nicer because of the resistive touch, battery,
> > and friendly bootloader...
> 
> Sure, my n950 just got so worn down I was afraid I don't have any
> replacement. And we need some kind of potential community upgrade for
> n900/n9/n950 anyways while waiting for better devices :)

I think Droid4 and N950 are almost on par regarding to mainline
support. N900 is has better hardware support in mainline - actually
once your camera bits land it reached basically 100% with just the
GPU missing. OTOH it's quite slow and has only 256MB of memory.

-- Sebastian

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

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

[Pavel Machek]

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

Hi!

> > > Is GSM connected directly to the audio, or does it need real-time
> > > task, similar to N900?
> > 
> > The audio mixer is on CPCAP PMIC, and I think mdm6600 modem audio needs
> > help from the Linux kernel on the applications processor as it probably
> > goes to it first then to CPCAP PMIC. I guess it's possible that mdm6600
> > audio goes directly to CPCAP PMIC too.
> > 
> > I believe LTE modem is connected to the second SPI interface on the
> > CPCAP PMIC and can use it directly for audio depending on how Linux
> > kernel configures the PMIC secondary interface device access. What
> > seems to be a similar PMIC for the CPCAP internal devices is documented
> > in MC13783UG.pdf on NXP site so that might be worth looking at for
> > the audio overview.
> 
> GSM audio is connected to the audio codec using digital audio
> interface. The audio data normally does not flow through the CPU
> (but as far as I can see it could be routed that way, if desired).
> So no need for any low latency stuff on CPU side. Actually no need
> to do anything except for proper setup of modem & audio codec :)

Thanks. Droid 4 just got more desirable ;-).

> > > It looks like nice machine. OTOH N950 looks like a nice machine, too,
> > > and N900 is actually nicer because of the resistive touch, battery,
> > > and friendly bootloader...
> > 
> > Sure, my n950 just got so worn down I was afraid I don't have any
> > replacement. And we need some kind of potential community upgrade for
> > n900/n9/n950 anyways while waiting for better devices :)
> 
> I think Droid4 and N950 are almost on par regarding to mainline
> support. N900 is has better hardware support in mainline - actually
> once your camera bits land it reached basically 100% with just the
> GPU missing. OTOH it's quite slow and has only 256MB of memory.

Well, the camera pieces only work with 1.2Mpix resolution... and still
need a ton of userland code to be useful. But yes, major pieces are
there, with exception of ... useful audio for voice calls (and tons of
little omissions and flakiness and bugs).

Oh, another major piece is DSP coprocessor that is there. Unlike
graphics, we don't even know how support for it should like.

And actually, N950 has working Bluetooth, which gives some interesting
possibilities, too.

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 --]

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

[Sebastian Reichel]

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

Hi,

On Tue, Jun 27, 2017 at 11:57:27PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > > Is GSM connected directly to the audio, or does it need real-time
> > > > task, similar to N900?
> > > 
> > > The audio mixer is on CPCAP PMIC, and I think mdm6600 modem audio needs
> > > help from the Linux kernel on the applications processor as it probably
> > > goes to it first then to CPCAP PMIC. I guess it's possible that mdm6600
> > > audio goes directly to CPCAP PMIC too.
> > > 
> > > I believe LTE modem is connected to the second SPI interface on the
> > > CPCAP PMIC and can use it directly for audio depending on how Linux
> > > kernel configures the PMIC secondary interface device access. What
> > > seems to be a similar PMIC for the CPCAP internal devices is documented
> > > in MC13783UG.pdf on NXP site so that might be worth looking at for
> > > the audio overview.
> > 
> > GSM audio is connected to the audio codec using digital audio
> > interface. The audio data normally does not flow through the CPU
> > (but as far as I can see it could be routed that way, if desired).
> > So no need for any low latency stuff on CPU side. Actually no need
> > to do anything except for proper setup of modem & audio codec :)
> 
> Thanks. Droid 4 just got more desirable ;-).
>
> > > > It looks like nice machine. OTOH N950 looks like a nice machine, too,
> > > > and N900 is actually nicer because of the resistive touch, battery,
> > > > and friendly bootloader...
> > > 
> > > Sure, my n950 just got so worn down I was afraid I don't have any
> > > replacement. And we need some kind of potential community upgrade for
> > > n900/n9/n950 anyways while waiting for better devices :)
> > 
> > I think Droid4 and N950 are almost on par regarding to mainline
> > support. N900 is has better hardware support in mainline - actually
> > once your camera bits land it reached basically 100% with just the
> > GPU missing. OTOH it's quite slow and has only 256MB of memory.
> 
> Well, the camera pieces only work with 1.2Mpix resolution... and still
> need a ton of userland code to be useful. But yes, major pieces are
> there, with exception of ... useful audio for voice calls (and tons of
> little omissions and flakiness and bugs).
> 
> Oh, another major piece is DSP coprocessor that is there. Unlike
> graphics, we don't even know how support for it should like.

https://www.kernel.org/doc/Documentation/remoteproc.txt

config OMAP_REMOTEPROC
	tristate "OMAP remoteproc support"
	[...]
	help
	  Say y here to support OMAP's remote processors (dual M3
	  and DSP on OMAP4) via the remote processor framework.

	  Currently only supported on OMAP4.

	  Usually you want to say Y here, in order to enable multimedia
	  use-cases to run on your platform (multimedia codecs are
	  offloaded to remote DSP processors using this framework).

	  It's safe to say N here if you're not interested in multimedia
	  offloading or just want a bare minimum kernel.

I have been told by some Nokia people (I do not remember who it
was, possibly Sakari), that the DSP is not that powerful and any
calculation should also be possible on CPU (wasting a bit of energy).

> And actually, N950 has working Bluetooth, which gives some
> interesting possibilities, too.

Patches for bluetooth on Droid4 are in -next :)

-- Sebastian

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

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

[Pavel Machek]

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

Hi!

> > Oh, another major piece is DSP coprocessor that is there. Unlike
> > graphics, we don't even know how support for it should like.
> 
> https://www.kernel.org/doc/Documentation/remoteproc.txt
> 
> config OMAP_REMOTEPROC
> 	tristate "OMAP remoteproc support"
> 	[...]
> 	help
> 	  Say y here to support OMAP's remote processors (dual M3
> 	  and DSP on OMAP4) via the remote processor framework.
> 
> 	  Currently only supported on OMAP4.
> 
> 	  Usually you want to say Y here, in order to enable multimedia
> 	  use-cases to run on your platform (multimedia codecs are
> 	  offloaded to remote DSP processors using this framework).
> 
> 	  It's safe to say N here if you're not interested in multimedia
> 	  offloading or just want a bare minimum kernel.
> 
> I have been told by some Nokia people (I do not remember who it
> was, possibly Sakari), that the DSP is not that powerful and any
> calculation should also be possible on CPU (wasting a bit of
> energy).

Ok, we probably don't care about DSP, but lets say we had really
fast DSP or really cared about power.

We'd need remoteproc. Sure. But that has no interface for userland,
right?

So we'd need to introduce interface for userland... fine.

And then we'd need cross-compilers for the DSP used. Ok.

And then we'd need to split mpg123 to CPU and DSP parts, and modify it
so that it can run the DSP parts using remoteproc, when available?

That starts to be ... complex, with changes all over the system :-(.

								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 --]

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

[Sebastian Reichel]

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

Hi,

On Wed, Jun 28, 2017 at 10:27:22PM +0200, Pavel Machek wrote:
> > > Oh, another major piece is DSP coprocessor that is there. Unlike
> > > graphics, we don't even know how support for it should like.
> > 
> > https://www.kernel.org/doc/Documentation/remoteproc.txt
> > 
> > config OMAP_REMOTEPROC
> > 	tristate "OMAP remoteproc support"
> > 	[...]
> > 	help
> > 	  Say y here to support OMAP's remote processors (dual M3
> > 	  and DSP on OMAP4) via the remote processor framework.
> > 
> > 	  Currently only supported on OMAP4.
> > 
> > 	  Usually you want to say Y here, in order to enable multimedia
> > 	  use-cases to run on your platform (multimedia codecs are
> > 	  offloaded to remote DSP processors using this framework).
> > 
> > 	  It's safe to say N here if you're not interested in multimedia
> > 	  offloading or just want a bare minimum kernel.
> > 
> > I have been told by some Nokia people (I do not remember who it
> > was, possibly Sakari), that the DSP is not that powerful and any
> > calculation should also be possible on CPU (wasting a bit of
> > energy).
> 
> Ok, we probably don't care about DSP, but lets say we had really
> fast DSP or really cared about power.
> 
> We'd need remoteproc. Sure. But that has no interface for userland,
> right?

remoteproc is only for start/stop + fw loading. The actual
communication is done using rpmsg, which does not yet have a
userspace API afaik.

> So we'd need to introduce interface for userland... fine.
> 
> And then we'd need cross-compilers for the DSP used. Ok.

Yes. As far as I know there is currently no open source toolchain
for the TI DSP.

> And then we'd need to split mpg123 to CPU and DSP parts, and modify it
> so that it can run the DSP parts using remoteproc, when available?
> 
> That starts to be ... complex, with changes all over the system :-(.

With little gain expected on N900...

-- Sebastian

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

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

[Pavel Machek]

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

Hi!

> > It looks like nice machine. OTOH N950 looks like a nice machine, too,
> > and N900 is actually nicer because of the resistive touch, battery,
> > and friendly bootloader...
> 
> Sure, my n950 just got so worn down I was afraid I don't have any
> replacement. And we need some kind of potential community upgrade for
> n900/n9/n950 anyways while waiting for better devices :)

Well yes, upgrade path is important. Thanks for doing that :-).
									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 --]

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

[Pavel Machek]

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

Hi!

> > 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.

> 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 ;-).

> > 2) How to handle GSM audio?
> 
> What is the issue here?  Isn't GSM audio just another audio source/sink
> which user-space can send where-ever it likes?

It is somehow packetized, and has timestamps and gaps in it, I was
told. That's why we use /dev/cmt_speech, not ALSA. Probably ALSA
should be improved.

> > 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.

> An equivalent "gsmd" with pluggable back-ends seems like the right
> approach.  I think there are several contenders already.

ofono is actually quite usable. But we are putting driver in
userspace; bye-bye hardware abstraction, bye-bye using old distro on
new phone.

> > 4) How to handle accelerated RGB LEDs?
> 
> This does sound like a kernel issue.   The hardware has limited
> programmability so that different patterns and colors are possible.
> Maybe we want to enhance the LED trigger mechanism to apply to
> colour LEDs.
> I guess that we need a concrete proposal so that it can be assessed.

Plus there's an issue of color; all three channels on max will not
produce white color.

> > 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?
> 
> My feeling is that until someone proves otherwise, suspend-to-RAM should
> be assumed necessary.  It should be possible to get the same power
> saving with runtime suspend, but that requires all of user-space to
> co-operated, which is like "herding wild cats".

Well, N900 proves otherwise.

> I don't really know what "compatible with Unix" means in this context.
> 
> There are really two options:
> 1/ applications which specific cpu-availability needs explicitly
>    after for the CPU to be kept available - i.e. "wake locks"
> 2/ applications that don't have specific cpu-availabilty needs
>    don't use the cpu at all when they don't need it.
> 
> The first means we suspend-to-RAM, but have "wake lock" calls
> in code.
> The second means that all code is very careful not to be wasteful, and
> we rely on runtime PM.
> Neither are very "Unixy".
> 
> Is this a kernel issue at all?  User-space can take either approach, and
> struggle with the difficulties.

Well, I believe 2/ is the way to go. But if we decide 1/ is ok, would
not it be nice to have some reasonable interface? After all, your fsck
will need to use it... as will for example trivial program for
computing prime numbers. And what do we do when program exits with
wakelock held? What if it is OOM killed?

Yes, Android has some answers here, I just don't think they are any
good. (As in ... not very Unixy).

In desktop case, we do hardware abstraction right; you can keep old
distro as your hardware is supported by kernel. Would not it be nice
to do the same for phones?

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 --]

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

[Mark Brown]

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

On Mon, Jun 26, 2017 at 10:34:07AM +0200, Pavel Machek wrote:

> > > 2) How to handle GSM audio?

> > What is the issue here?  Isn't GSM audio just another audio source/sink
> > which user-space can send where-ever it likes?

> It is somehow packetized, and has timestamps and gaps in it, I was
> told. That's why we use /dev/cmt_speech, not ALSA. Probably ALSA
> should be improved.

No, such systems can and do work absolutely fine with the existing
frameworks.  You just have non-upstream drivers that don't make any
effort to work within existing frameworks.  Most of the vendors came
round to doing the right thing on this some years ago.

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

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

[Pavel Machek]

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

Hi!

> > > > 2) How to handle GSM audio?
> 
> > > What is the issue here?  Isn't GSM audio just another audio source/sink
> > > which user-space can send where-ever it likes?
> 
> > It is somehow packetized, and has timestamps and gaps in it, I was
> > told. That's why we use /dev/cmt_speech, not ALSA. Probably ALSA
> > should be improved.
> 
> No, such systems can and do work absolutely fine with the existing
> frameworks.  You just have non-upstream drivers that don't make any
> effort to work within existing frameworks.  Most of the vendors came
> round to doing the right thing on this some years ago.

Take a look at ./drivers/hsi/clients/cmt_speech.c in your favourite
kernel. It was merged in 2010 AFAICT.

									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 --]

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

[Mark Brown]

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

On Mon, Jun 26, 2017 at 02:22:24PM +0200, Pavel Machek wrote:

> > No, such systems can and do work absolutely fine with the existing
> > frameworks.  You just have non-upstream drivers that don't make any
> > effort to work within existing frameworks.  Most of the vendors came
> > round to doing the right thing on this some years ago.

> Take a look at ./drivers/hsi/clients/cmt_speech.c in your favourite
> kernel. It was merged in 2010 AFAICT.

That looks like it went in in 2015, not 2010 - the commit date is in
March 2015, I suspect the 2010 date comes from whatever vendor tree it
came from.  The code isn't super clear but it looks like a fairly
standard DSP streaming interface which should be supportable as a
compressed audio stream in ALSA (or regular one if the data is
uncompressed), there's no reason I can see for it to be done outside of
the standard audio framework.

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

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

[Pavel Machek]

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

Hi!

On Tue 2017-06-27 12:40:26, Mark Brown wrote:
> On Mon, Jun 26, 2017 at 02:22:24PM +0200, Pavel Machek wrote:
> 
> > > No, such systems can and do work absolutely fine with the existing
> > > frameworks.  You just have non-upstream drivers that don't make any
> > > effort to work within existing frameworks.  Most of the vendors came
> > > round to doing the right thing on this some years ago.
> 
> > Take a look at ./drivers/hsi/clients/cmt_speech.c in your favourite
> > kernel. It was merged in 2010 AFAICT.
> 
> That looks like it went in in 2015, not 2010 - the commit date is in
> March 2015, I suspect the 2010 date comes from whatever vendor tree it
> came from.  The code isn't super clear but it looks like a fairly
> standard DSP streaming interface which should be supportable as a
> compressed audio stream in ALSA (or regular one if the data is
> uncompressed), there's no reason I can see for it to be done outside of
> the standard audio framework.

Ok, I guess I was wrong with 2010.

And yes, it is uncompressed. I actually tried to convert it to ALSA
some time ago, but could not get it to work.

Right now, first priority is to get useful quality of the voice
calls. If Nokia is the only one, then this is perhaps not a big
problem.

I'd like to know how Pyra handles this (
https://pyra-handheld.com/boards/pages/pyra/ ).

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 --]

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

[Sebastian Reichel]

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

Hi,

On Wed, Jun 28, 2017 at 08:37:56PM +0200, Pavel Machek wrote:
> Right now, first priority is to get useful quality of the voice
> calls. If Nokia is the only one, then this is perhaps not a big
> problem.
> 
> I'd like to know how Pyra handles this (
> https://pyra-handheld.com/boards/pages/pyra/ ).

It provides a normal PCM interface, check
20161116-DragonFly-MAIN-4G-sch.pdf, page 11 from here:

https://pyra-handheld.com/boards/threads/power-memory-and-schematics.78631/

The Nokia phones are really special in this regard.

-- Sebastian

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

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

[Alexandre Belloni]

On 26/06/2017 at 10:34:07 +0200, Pavel Machek wrote:
> 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).
> 

garmin_gps is actually not desirable and is better handled in
userspace, see:
http://wiki.openstreetmap.org/wiki/USB_Garmin_on_GNU/Linux



-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Pavel Machek]

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

On Tue 2017-06-27 00:23:14, Alexandre Belloni wrote:
> On 26/06/2017 at 10:34:07 +0200, Pavel Machek wrote:
> > 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).
> 
> garmin_gps is actually not desirable and is better handled in
> userspace, see:
> http://wiki.openstreetmap.org/wiki/USB_Garmin_on_GNU/Linux

Well, yes, you can put usb drivers in userspace. And in garmin_gps
case, userspace driver currently works better than kernel one.

But in case of GPS not connected on simple serial bus (USB, serial),
that will mean two drivers, one in kernel, and one in userspace, and
that's wrong.

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 --]

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

[Sebastian Reichel]

[-- 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 --]

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

[Pavel Machek]

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

Hi!

> > 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.

Yep, I actually have a patch for that. Needs some cleanups, but if it
is basically acceptable, there's no problem doing them. Aha, and
probably breaks boot or something, that's why I disable it. But you
should get the idea...

> > 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.

So to be exact... u-boot does not know about battery charging. And
NoLo can only do very, very slow charging.

Yes, unfortunately that does not work quite well here. Voltage goes
too low before Linux can boot, so it resets, but it is still high
enough for the bootloader, so it attempts to boot Linux one more time,
but battery is empty and voltage goes too low before Linux can boot, ...

> > 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.

Two GPSes in one box, interesting design. Are both of them connected
to useful antenna?

Best regards,
								Pavel


diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
index 398801a..db9c69e 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -52,6 +52,7 @@
 #include <linux/delay.h>
 #include <linux/platform_device.h>
 #include <linux/power_supply.h>
+#include <linux/reboot.h>
 #include <linux/slab.h>
 #include <linux/of.h>
 
@@ -808,11 +809,9 @@ static inline int bq27xxx_read(struct bq27xxx_device_info *di, int reg_index,
 static int bq27xxx_battery_read_soc(struct bq27xxx_device_info *di)
 {
 	int soc;
+	bool single = di->chip == BQ27000 || di->chip == BQ27010;
 
-	if (di->chip == BQ27000 || di->chip == BQ27010)
-		soc = bq27xxx_read(di, BQ27XXX_REG_SOC, true);
-	else
-		soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
+	soc = bq27xxx_read(di, BQ27XXX_REG_SOC, single);
 
 	if (soc < 0)
 		dev_dbg(di->dev, "error reading State-of-Charge\n");
@@ -876,11 +875,9 @@ static inline int bq27xxx_battery_read_fcc(struct bq27xxx_device_info *di)
 static int bq27xxx_battery_read_dcap(struct bq27xxx_device_info *di)
 {
 	int dcap;
+	bool single = di->chip == BQ27000 || di->chip == BQ27010;
 
-	if (di->chip == BQ27000 || di->chip == BQ27010)
-		dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, true);
-	else
-		dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
+	dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, single);
 
 	if (dcap < 0) {
 		dev_dbg(di->dev, "error reading initial last measured discharge\n");
@@ -1061,10 +1058,10 @@ static int bq27xxx_battery_read_health(struct bq27xxx_device_info *di)
 	/* Unlikely but important to return first */
 	if (unlikely(bq27xxx_battery_overtemp(di, flags)))
 		return POWER_SUPPLY_HEALTH_OVERHEAT;
-	if (unlikely(bq27xxx_battery_undertemp(di, flags)))
-		return POWER_SUPPLY_HEALTH_COLD;
 	if (unlikely(bq27xxx_battery_dead(di, flags)))
 		return POWER_SUPPLY_HEALTH_DEAD;
+	if (unlikely(bq27xxx_battery_undertemp(di, flags)))
+		return POWER_SUPPLY_HEALTH_COLD;
 
 	return POWER_SUPPLY_HEALTH_GOOD;
 }
@@ -1122,6 +1119,49 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
 }
 EXPORT_SYMBOL_GPL(bq27xxx_battery_update);
 
+static void shutdown(char *reason)
+{
+	pr_alert("%s Forcing shutdown\n", reason);
+	orderly_poweroff(true);
+}
+
+static int generic_protect(struct power_supply *psy)
+{
+	union power_supply_propval val;
+	int res;
+	int mV, mA, mOhm = 430, mVadj = 0;
+
+	res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_HEALTH, &val);
+	if (res)
+		return res;
+
+	if (val.intval == POWER_SUPPLY_HEALTH_OVERHEAT)
+		shutdown("Battery overheat.");
+	if (val.intval == POWER_SUPPLY_HEALTH_DEAD)
+		shutdown("Battery dead.");
+
+	res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_VOLTAGE_NOW, &val);
+	if (res)
+		return res;
+	mV = val.intval / 1000;
+
+	if (mV < 2950)
+		shutdown("Battery below 2.95V.");
+
+	res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_CURRENT_NOW, &val);
+	if (res)
+		return res;
+	mA = val.intval / 1000;
+	mVadj = mV + (mA * mOhm) / 1000;
+
+	if (mVadj < 3150)
+		shutdown("Battery internal voltage below 3.15V.");
+	
+	printk(KERN_INFO "Main battery %d mV, internal voltage %d mV\n",
+	       mV, mVadj);
+	return 0;
+}
+
 static void bq27xxx_battery_poll(struct work_struct *work)
 {
 	struct bq27xxx_device_info *di =
@@ -1129,6 +1169,7 @@ static void bq27xxx_battery_poll(struct work_struct *work)
 				     work.work);
 
 	bq27xxx_battery_update(di);
+	//generic_protect(di->bat);
 
 	if (poll_interval > 0)
 		schedule_delayed_work(&di->work, poll_interval * HZ);
@@ -1226,8 +1267,8 @@ static int bq27xxx_battery_capacity_level(struct bq27xxx_device_info *di,
 }
 
 /*
- * Return the battery Voltage in millivolts
- * Or < 0 if something fails.
+ * Set val->intval to the battery Voltage in millivolts.
+ * Return < 0 if something fails.
  */
 static int bq27xxx_battery_voltage(struct bq27xxx_device_info *di,
 				   union power_supply_propval *val)


-- 
(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 --]

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

[Sebastian Reichel]

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

On Tue, Jun 27, 2017 at 11:57:55PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > 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.
> 
> Yep, I actually have a patch for that. Needs some cleanups, but if it
> is basically acceptable, there's no problem doing them. Aha, and
> probably breaks boot or something, that's why I disable it. But you
> should get the idea...
> 
> > > 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.
> 
> So to be exact... u-boot does not know about battery charging. And
> NoLo can only do very, very slow charging.

Yes. The idea is, that normally NoLo only charges far enough, that
Linux can be booted.

> Yes, unfortunately that does not work quite well here. Voltage goes
> too low before Linux can boot, so it resets, but it is still high
> enough for the bootloader, so it attempts to boot Linux one more time,
> but battery is empty and voltage goes too low before Linux can boot, ...

I guess your battery is not the fittest anymore?

> > > 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.
> 
> Two GPSes in one box, interesting design. Are both of them connected
> to useful antenna?

Actually there are probably 3 GPS implementations in Droid 4:

 * WL1285
 * MDM6600 modem
 * LTE modem

As far as I understand it modems are required to have GPS access in
US. I'm not yet sure which of the implementations is used by Droid 4's
stock system, but Motorola explicitly added a driver for the WL1285 GPS
making it a likely candidate (The userspace part is a closed source
shared object used by Android).

> 
> Best regards,
> 								Pavel
> 
> 
> diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c
> index 398801a..db9c69e 100644
> --- a/drivers/power/supply/bq27xxx_battery.c
> +++ b/drivers/power/supply/bq27xxx_battery.c
> @@ -52,6 +52,7 @@
>  #include <linux/delay.h>
>  #include <linux/platform_device.h>
>  #include <linux/power_supply.h>
> +#include <linux/reboot.h>
>  #include <linux/slab.h>
>  #include <linux/of.h>
>  
> @@ -808,11 +809,9 @@ static inline int bq27xxx_read(struct bq27xxx_device_info *di, int reg_index,
>  static int bq27xxx_battery_read_soc(struct bq27xxx_device_info *di)
>  {
>  	int soc;
> +	bool single = di->chip == BQ27000 || di->chip == BQ27010;
>  
> -	if (di->chip == BQ27000 || di->chip == BQ27010)
> -		soc = bq27xxx_read(di, BQ27XXX_REG_SOC, true);
> -	else
> -		soc = bq27xxx_read(di, BQ27XXX_REG_SOC, false);
> +	soc = bq27xxx_read(di, BQ27XXX_REG_SOC, single);
>  
>  	if (soc < 0)
>  		dev_dbg(di->dev, "error reading State-of-Charge\n");
> @@ -876,11 +875,9 @@ static inline int bq27xxx_battery_read_fcc(struct bq27xxx_device_info *di)
>  static int bq27xxx_battery_read_dcap(struct bq27xxx_device_info *di)
>  {
>  	int dcap;
> +	bool single = di->chip == BQ27000 || di->chip == BQ27010;
>  
> -	if (di->chip == BQ27000 || di->chip == BQ27010)
> -		dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, true);
> -	else
> -		dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, false);
> +	dcap = bq27xxx_read(di, BQ27XXX_REG_DCAP, single);
>  
>  	if (dcap < 0) {
>  		dev_dbg(di->dev, "error reading initial last measured discharge\n");
> @@ -1061,10 +1058,10 @@ static int bq27xxx_battery_read_health(struct bq27xxx_device_info *di)
>  	/* Unlikely but important to return first */
>  	if (unlikely(bq27xxx_battery_overtemp(di, flags)))
>  		return POWER_SUPPLY_HEALTH_OVERHEAT;
> -	if (unlikely(bq27xxx_battery_undertemp(di, flags)))
> -		return POWER_SUPPLY_HEALTH_COLD;
>  	if (unlikely(bq27xxx_battery_dead(di, flags)))
>  		return POWER_SUPPLY_HEALTH_DEAD;
> +	if (unlikely(bq27xxx_battery_undertemp(di, flags)))
> +		return POWER_SUPPLY_HEALTH_COLD;
>  
>  	return POWER_SUPPLY_HEALTH_GOOD;
>  }
> @@ -1122,6 +1119,49 @@ void bq27xxx_battery_update(struct bq27xxx_device_info *di)
>  }
>  EXPORT_SYMBOL_GPL(bq27xxx_battery_update);
>  
> +static void shutdown(char *reason)
> +{
> +	pr_alert("%s Forcing shutdown\n", reason);
> +	orderly_poweroff(true);
> +}
> +
> +static int generic_protect(struct power_supply *psy)
> +{
> +	union power_supply_propval val;
> +	int res;
> +	int mV, mA, mOhm = 430, mVadj = 0;

430 mOhm?

> +	res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_HEALTH, &val);
> +	if (res)
> +		return res;
> +
> +	if (val.intval == POWER_SUPPLY_HEALTH_OVERHEAT)
> +		shutdown("Battery overheat.");
> +	if (val.intval == POWER_SUPPLY_HEALTH_DEAD)
> +		shutdown("Battery dead.");
> +
> +	res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_VOLTAGE_NOW, &val);
> +	if (res)
> +		return res;
> +	mV = val.intval / 1000;
> +
> +	if (mV < 2950)
> +		shutdown("Battery below 2.95V.");
> +
> +	res = psy->desc->get_property(psy, POWER_SUPPLY_PROP_CURRENT_NOW, &val);
> +	if (res)
> +		return res;
> +	mA = val.intval / 1000;
> +	mVadj = mV + (mA * mOhm) / 1000;
> +
> +	if (mVadj < 3150)
> +		shutdown("Battery internal voltage below 3.15V.");
> +	
> +	printk(KERN_INFO "Main battery %d mV, internal voltage %d mV\n",
> +	       mV, mVadj);

s/internal voltage/open circuit voltage/g?

> +	return 0;
> +}
> +
>  static void bq27xxx_battery_poll(struct work_struct *work)
>  {
>  	struct bq27xxx_device_info *di =
> @@ -1129,6 +1169,7 @@ static void bq27xxx_battery_poll(struct work_struct *work)
>  				     work.work);
>  
>  	bq27xxx_battery_update(di);
> +	//generic_protect(di->bat);
>  
>  	if (poll_interval > 0)
>  		schedule_delayed_work(&di->work, poll_interval * HZ);
> @@ -1226,8 +1267,8 @@ static int bq27xxx_battery_capacity_level(struct bq27xxx_device_info *di,
>  }
>  
>  /*
> - * Return the battery Voltage in millivolts
> - * Or < 0 if something fails.
> + * Set val->intval to the battery Voltage in millivolts.
> + * Return < 0 if something fails.
>   */
>  static int bq27xxx_battery_voltage(struct bq27xxx_device_info *di,
>  				   union power_supply_propval *val)
> 

-- Sebastian

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

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

[Pavel Machek]

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

Hi!

> > So to be exact... u-boot does not know about battery charging. And
> > NoLo can only do very, very slow charging.
> 
> Yes. The idea is, that normally NoLo only charges far enough, that
> Linux can be booted.
> 
> > Yes, unfortunately that does not work quite well here. Voltage goes
> > too low before Linux can boot, so it resets, but it is still high
> > enough for the bootloader, so it attempts to boot Linux one more time,
> > but battery is empty and voltage goes too low before Linux can boot, ...
> 
> I guess your battery is not the fittest anymore?

I guess that's one issue. (One of my batteries is actually so bad that
GSM modem fails with it.)

Well, I guess Debian boots a little longer than Maemo. Plus, I believe
we should charge the battery from kernel by default; it will enable
running fsck etc, and it will mean slow userspace boot will not
break...

> > > 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.
> > 
> > Two GPSes in one box, interesting design. Are both of them connected
> > to useful antenna?
> 
> Actually there are probably 3 GPS implementations in Droid 4:
> 
>  * WL1285
>  * MDM6600 modem
>  * LTE modem
> 
> As far as I understand it modems are required to have GPS access in
> US. I'm not yet sure which of the implementations is used by Droid 4's
> stock system, but Motorola explicitly added a driver for the WL1285 GPS
> making it a likely candidate (The userspace part is a closed source
> shared object used by Android).

Interesting :-). I guess you could do really fair comparison of the
chipsets.

(Binary driver -- bad Motorola :-( )

> > +static int generic_protect(struct power_supply *psy)
> > +{
> > +	union power_supply_propval val;
> > +	int res;
> > +	int mV, mA, mOhm = 430, mVadj = 0;
> 
> 430 mOhm?

Yes, 0.43 Ohm.

> > +	if (mVadj < 3150)
> > +		shutdown("Battery internal voltage below 3.15V.");
> > +	
> > +	printk(KERN_INFO "Main battery %d mV, internal voltage %d mV\n",
> > +	       mV, mVadj);
> 
> s/internal voltage/open circuit voltage/g?

Will do.

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 --]

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

[Sebastian Reichel]

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

Hi,

On Wed, Jun 28, 2017 at 11:10:08PM +0200, Pavel Machek wrote:
> > > So to be exact... u-boot does not know about battery charging. And
> > > NoLo can only do very, very slow charging.
> > 
> > Yes. The idea is, that normally NoLo only charges far enough, that
> > Linux can be booted.
> > 
> > > Yes, unfortunately that does not work quite well here. Voltage goes
> > > too low before Linux can boot, so it resets, but it is still high
> > > enough for the bootloader, so it attempts to boot Linux one more time,
> > > but battery is empty and voltage goes too low before Linux can boot, ...
> > 
> > I guess your battery is not the fittest anymore?
> 
> I guess that's one issue. (One of my batteries is actually so bad that
> GSM modem fails with it.)
> 
> Well, I guess Debian boots a little longer than Maemo. Plus, I believe
> we should charge the battery from kernel by default; it will enable
> running fsck etc, and it will mean slow userspace boot will not
> break...

That sounds like really bad battery :)

> > > > 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.
> > > 
> > > Two GPSes in one box, interesting design. Are both of them connected
> > > to useful antenna?
> > 
> > Actually there are probably 3 GPS implementations in Droid 4:
> > 
> >  * WL1285
> >  * MDM6600 modem
> >  * LTE modem
> > 
> > As far as I understand it modems are required to have GPS access in
> > US. I'm not yet sure which of the implementations is used by Droid 4's
> > stock system, but Motorola explicitly added a driver for the WL1285 GPS
> > making it a likely candidate (The userspace part is a closed source
> > shared object used by Android).
> 
> Interesting :-). I guess you could do really fair comparison of the
> chipsets.
> 
> (Binary driver -- bad Motorola :-( )

Yeah :( Note, that Nokia also has binary driver for the N900 (which
had been reverse engineered) and a different on on N950 (which has
not been reverse engineered so far).

> > > +static int generic_protect(struct power_supply *psy)
> > > +{
> > > +	union power_supply_propval val;
> > > +	int res;
> > > +	int mV, mA, mOhm = 430, mVadj = 0;
> > 
> > 430 mOhm?
> 
> Yes, 0.43 Ohm.

What's the source of this value?

-- Sebastian

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

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

[Pavel Machek]

Hi!

> > > I guess your battery is not the fittest anymore?
> > 
> > I guess that's one issue. (One of my batteries is actually so bad that
> > GSM modem fails with it.)
> > 
> > Well, I guess Debian boots a little longer than Maemo. Plus, I believe
> > we should charge the battery from kernel by default; it will enable
> > running fsck etc, and it will mean slow userspace boot will not
> > break...
> 
> That sounds like really bad battery :)

Yes, fortunately I have two others :-).

> > Interesting :-). I guess you could do really fair comparison of the
> > chipsets.
> > 
> > (Binary driver -- bad Motorola :-( )
> 
> Yeah :( Note, that Nokia also has binary driver for the N900 (which
> had been reverse engineered) and a different on on N950 (which has
> not been reverse engineered so far).

Yes... and another reason to keep N900.

> > > > +	int mV, mA, mOhm = 430, mVadj = 0;
> > > 
> > > 430 mOhm?
> > 
> > Yes, 0.43 Ohm.
> 
> What's the source of this value?

Estimate on one of my batteries. Real value differs with temperature and battery
age (among other things) but this is already significantly better than assuming
internal resistance is zero.

Best regards,
									Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Mark Brown]

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

On Sun, Jun 25, 2017 at 12:48:50PM +0200, Pavel Machek wrote:

> 2) How to handle GSM audio?

Do you have some more specific concern?  This already works basically
fine upstream, we happily support off-SoC audio paths.  The digital
configuration could do with being more flexible but it works and people
ship it.  It would be awfully nice to have some control/visibility of
the modem side but that's just a missing driver problem.

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

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

[Pavel Machek]

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

On Mon 2017-06-26 11:54:51, Mark Brown wrote:
> On Sun, Jun 25, 2017 at 12:48:50PM +0200, Pavel Machek wrote:
> 
> > 2) How to handle GSM audio?
> 
> Do you have some more specific concern?  This already works basically
> fine upstream, we happily support off-SoC audio paths.  The digital
> configuration could do with being more flexible but it works and people
> ship it.  It would be awfully nice to have some control/visibility of
> the modem side but that's just a missing driver problem.

Well, I was told gsm audio is different, because it is packetized, has
additional timing info, and does not transmit silence.

So we have /dev/cmtspeech instead of second sound card.

Is there any GSM audio driver that actually uses sound framework
properly?

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 --]

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

[Mark Brown]

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

On Mon, Jun 26, 2017 at 01:14:22PM +0200, Pavel Machek wrote:

> > Do you have some more specific concern?  This already works basically
> > fine upstream, we happily support off-SoC audio paths.  The digital
> > configuration could do with being more flexible but it works and people
> > ship it.  It would be awfully nice to have some control/visibility of
> > the modem side but that's just a missing driver problem.

> Well, I was told gsm audio is different, because it is packetized, has
> additional timing info, and does not transmit silence.

Those things are true, however this is all handled inside the modem so
nothing else in the system sees anything there.  Even if we were to see
things this is pretty much just VoIP over a funny carrier (some of the
4G standards are just SIP AIUI) which isn't too hard.

> So we have /dev/cmtspeech instead of second sound card.

That's just whatever random thing you're working on.  It really
shouldn't be a second sound card on a well designed system, the phone
audio generally doesn't go anywhere near the CPU for latency reasons so
the whole system is one sound card.

> Is there any GSM audio driver that actually uses sound framework
> properly?

The modems tend to just be stub drivers to Linux as the audio port
doesn't vary configuration at runtime but I'd be a bit surprised if a
modern phone wasn't broadly aiming towards the right thing, this stuff
started appearing in flagship devices in about 2012.  The speyside
system in mainline isn't actually a phone but models what's going on.

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

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

[Pavel Machek]

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

On Mon 2017-06-26 12:49:46, Mark Brown wrote:
> On Mon, Jun 26, 2017 at 01:14:22PM +0200, Pavel Machek wrote:
> 
> > > Do you have some more specific concern?  This already works basically
> > > fine upstream, we happily support off-SoC audio paths.  The digital
> > > configuration could do with being more flexible but it works and people
> > > ship it.  It would be awfully nice to have some control/visibility of
> > > the modem side but that's just a missing driver problem.
> 
> > Well, I was told gsm audio is different, because it is packetized, has
> > additional timing info, and does not transmit silence.
> 
> Those things are true, however this is all handled inside the modem so
> nothing else in the system sees anything there.  Even if we were to see
> things this is pretty much just VoIP over a funny carrier (some of the
> 4G standards are just SIP AIUI) which isn't too hard.

I'm still asking for one example of system that's properly designed
according to you.

It may be "VoIP over funny carrier" -- but how do you suggest we
handle it? ALSA is for soundcards, not for VoIP so maybe
/dev/cmtspeech is okay after all?

> > So we have /dev/cmtspeech instead of second sound card.
> 
> That's just whatever random thing you're working on.  It really
> shouldn't be a second sound card on a well designed system, the phone
> audio generally doesn't go anywhere near the CPU for latency reasons so
> the whole system is one sound card.

First, where can I buy example of such well-designed system?

Second, no I can't agree. I certainly don't want baseband CPU to talk
directly to my speakers/microphone, for security reasons. Then there's
an option to process the sound between sending it over GSM, record
calls, etc. I quite like the flexibility, too. Latency problems are
solveable in software -- N900 with Maemo has reasonable call quality.

Third, I already have the system, I'm asking how to support it cleanly.

> > Is there any GSM audio driver that actually uses sound framework
> > properly?
> 
> The modems tend to just be stub drivers to Linux as the audio port
> doesn't vary configuration at runtime but I'd be a bit surprised if a
> modern phone wasn't broadly aiming towards the right thing, this stuff
> started appearing in flagship devices in about 2012.  The speyside
> system in mainline isn't actually a phone but models what's going on.

Well, the flagship devices are have 1000000+ lines of diffs relative
to mainline, due to Qualcomm, right? :-(.

								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 --]

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

[Mark Brown]

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

On Mon, Jun 26, 2017 at 02:38:53PM +0200, Pavel Machek wrote:
> On Mon 2017-06-26 12:49:46, Mark Brown wrote:

> > Those things are true, however this is all handled inside the modem so
> > nothing else in the system sees anything there.  Even if we were to see
> > things this is pretty much just VoIP over a funny carrier (some of the
> > 4G standards are just SIP AIUI) which isn't too hard.

> I'm still asking for one example of system that's properly designed
> according to you.

To repeat what I said previously most modern phones are in roughly the
right ballpark.  Off the top of my head any Galaxy S from the S3 on
except possibly some of the earlier Qualcomm variants.

> It may be "VoIP over funny carrier" -- but how do you suggest we
> handle it? ALSA is for soundcards, not for VoIP so maybe
> /dev/cmtspeech is okay after all?

Whatever is going on we shouldn't have some random driver specific bodge
in there, I don't have time right now to look at it.

> > > So we have /dev/cmtspeech instead of second sound card.

> > That's just whatever random thing you're working on.  It really
> > shouldn't be a second sound card on a well designed system, the phone
> > audio generally doesn't go anywhere near the CPU for latency reasons so
> > the whole system is one sound card.

> First, where can I buy example of such well-designed system?

Pretty much any phone shop.

> Second, no I can't agree. I certainly don't want baseband CPU to talk
> directly to my speakers/microphone, for security reasons. Then there's
> an option to process the sound between sending it over GSM, record
> calls, etc. I quite like the flexibility, too. Latency problems are
> solveable in software -- N900 with Maemo has reasonable call quality.

Your desired system design unfortunately does not reflect the reality of
how handsets are physically built.  It is standard for the audio from
the baseband to be wired directly to the main audio subsystem, typically
either a DSP that's part of the SoC or to an external audio CODEC.  The
physical routing of the audio is generally managed by the application
processor (I guess your security thing is worrying about people
recording audio, honestly I'd be more worried about attacks on the AP
than on the baseband) but the actual data flow bypasses it.  You can
normally set up a recording path easily enough if you want one but the
intention is that the active audio path bypasses the application
processor as it would have done when this was all analog.

The latency budgets on phones are very tight, you're looking at about
50-70ms for the full path latency before you start to see a falloff in
reported audio quality scores.  Since most of that budget is burned in
the network you end up with basically no room to add anything locally,
trying to do anything with the main application processor CPU is very
painful, even the overhead of putting things into and out of a buffer
of the size CPUs typically use is probably going to burn your entire
budget.  You'd need to make the buffer very small and have hard real
time constraints on handling that which doesn't seem like an especially
good idea.

Extra processing is typically done in a dedicated audio DSP that has
hardware intended for low latency operation and doesn't have the
constraints of having to deal with scheduling in a general purpose
operating system.  Modern requirements for things like noise
cancellation mean there'll generally be at least one available
somewhere.

> Third, I already have the system, I'm asking how to support it cleanly.

Off the top of my head reimplement the driver you're using as a standard
ALSA driver and take it from there - I've not actually looked at it yet
(and don't have time to right now).

> > > Is there any GSM audio driver that actually uses sound framework
> > > properly?

> > The modems tend to just be stub drivers to Linux as the audio port
> > doesn't vary configuration at runtime but I'd be a bit surprised if a
> > modern phone wasn't broadly aiming towards the right thing, this stuff
> > started appearing in flagship devices in about 2012.  The speyside
> > system in mainline isn't actually a phone but models what's going on.

> Well, the flagship devices are have 1000000+ lines of diffs relative
> to mainline, due to Qualcomm, right? :-(.

Sure, but in the audio part of that it's very rare to find anything
that's completely off piste - usually it's just drivers that haven't
been upstreamed yet for the most part.  We don't seem to have any
fundamental problem with getting basic phone audio working, it's fancier
stuff.  There's a bunch of stuff we could do a lot better with but
that's pretty much well understood and nothig at the basic "make it work
at all" level.

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

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

[Sebastian Reichel]

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

Hi,

On Mon, Jun 26, 2017 at 11:54:51AM +0100, Mark Brown wrote:
> On Sun, Jun 25, 2017 at 12:48:50PM +0200, Pavel Machek wrote:
> 
> > 2) How to handle GSM audio?
> 
> Do you have some more specific concern?  This already works basically
> fine upstream, we happily support off-SoC audio paths.  The digital
> configuration could do with being more flexible but it works and people
> ship it.  It would be awfully nice to have some control/visibility of
> the modem side but that's just a missing driver problem.

This is not a general problem, but only with the Nokia phones,
which sends raw audio data to the CPU. Nokia's userspace did
postprocessing on DSP and then played the audio via pulseaudio.
As you mentioned this requires a low latency setup of ~20ms.

@Pavel: The Nokia phones are the only ones I'm aware of, that
are implemented this way. Basically all other phones provide
a normal digital audio interface. On those systems you only
have to configure soundcard correctly and will have working
audio.

And as Mark mentioned modern 4G basically uses VoIP, so if some
vendor decides to drop audio handling from modem again it can
simply be done in userspace using normal VoIP application.

-- Sebastian

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

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

[Linus Walleij]

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

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

[Arnd Bergmann]

On Wed, Jun 28, 2017 at 4:38 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>> 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.

I agree this is still the fundamental issue, and that Freedreno is our best
hope at the moment, but aside from that, things have changed a lot over
the past few years, just not entirely the way we had hoped for:

* Nvidia, Vivante and Broadcom GPUs now all have open drivers, and
  are all still around in their respective niche markets, but have completely
  disappeared from products that are used in phones a few years ago.

* PowerVR still has a small market share in phones (ignoring the iPhone),
  but it's mostly used in other markets (TI and Renesas seem to be the
  only loyal customers but have exited the phone market, some others do
  both PowerVR and Mali, with a trend to more of the latter).
  We'll see what happens when someone buys the company.

* This leaves ARM Mali as the only GPU that still matters for phones
  other than Qualcomm's chips. The only ways to solve this are either
  a management change at ARM making it happen officially, or someone
  starting a serious effort to reverse-engineer the Midgard and/or Bifrost
  GPU architectures. At least we have a very clear idea of what would
  need to happen, just nobody who is qualified to do it, willing to spend
  the resources and not already under NDA.

       Arnd

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

[Laurent Pinchart]

Hi Arnd,

On Wednesday 28 Jun 2017 17:58:27 Arnd Bergmann wrote:
> On Wed, Jun 28, 2017 at 4:38 PM, Linus Walleij wrote:
> >> 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.
> 
> I agree this is still the fundamental issue, and that Freedreno is our best
> hope at the moment, but aside from that, things have changed a lot over
> the past few years, just not entirely the way we had hoped for:
> 
> * Nvidia, Vivante and Broadcom GPUs now all have open drivers, and
>   are all still around in their respective niche markets, but have
>   completely disappeared from products that are used in phones a few years
>   ago.
> 
> * PowerVR still has a small market share in phones (ignoring the iPhone),
>   but it's mostly used in other markets (TI and Renesas seem to be the
>   only loyal customers but have exited the phone market, some others do
>   both PowerVR and Mali, with a trend to more of the latter).
>   We'll see what happens when someone buys the company.
> 
> * This leaves ARM Mali as the only GPU that still matters for phones
>   other than Qualcomm's chips. The only ways to solve this are either
>   a management change at ARM making it happen officially, or someone
>   starting a serious effort to reverse-engineer the Midgard and/or Bifrost
>   GPU architectures. At least we have a very clear idea of what would
>   need to happen, just nobody who is qualified to do it, willing to spend
>   the resources and not already under NDA.

Could we split the problem by finding developers qualified to do it and not 
under NDA on one side, people or companies willing to finance the project on 
the other side, and put them together ?

-- 
Regards,

Laurent Pinchart

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

[Pavel Machek]

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

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

The problem is called "Qualcomm". Other vendors actually care about
mainline and support their boards longer. (TI).

And yes, that means I'm running hardware from 2009. And yes, TI
probably regrets me getting that hardware :-).

> 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.

Well, Android already has ABI abstraction layer, even projects like
Jolla and Ubuntu phone use it, IIRC, basically running Android in
chroot.

I agree that's not the way to go... but I don't think Google is going
to help us here. Community will have to do it "itself", and then maybe
Google + hw vendors will join.

> > 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?

Well, people are running N900 + old Android. And there are maintained
patches to keep original Maemo running on recent kernels (Pali Rohar
has them). I will _not_ touch Android, not with 10 foot pole, but
latest AOSP on N900 should be doable for someone with Android
experience and some free time..

> (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.)

How does Debian sound? Because that's what I run on N900. And most of
the stuff works, with voice calls being too poor quality...

									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 --]

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

[Mark Brown]

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

On Wed, Jun 28, 2017 at 06:25:03PM +0200, Pavel Machek wrote:

> > 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

> The problem is called "Qualcomm". Other vendors actually care about
> mainline and support their boards longer. (TI).

> And yes, that means I'm running hardware from 2009. And yes, TI
> probably regrets me getting that hardware :-).

It's hardly just Qualcomm here, by and by large it's everyone outside of
the general market embedded and verticals that care about long shelf
lives.

> > 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.

> Well, Android already has ABI abstraction layer, even projects like
> Jolla and Ubuntu phone use it, IIRC, basically running Android in
> chroot.

That's not exactly a stable ABI...

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

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

[Pavel Machek]

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

Hi!

> 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?

Actually, you may want to check out the Motorola Droid 4. Pretty new,
so still supported with LineageOS IIRC and hardware support in the
mainline is pretty complete (as mentioned elsewhere in this
thread). You may still have some work to do, but likely easier than
N900/N950.

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 --]

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

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [170628 10:03]:
> Hi!
> 
> > 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?
> 
> Actually, you may want to check out the Motorola Droid 4. Pretty new,
> so still supported with LineageOS IIRC and hardware support in the
> mainline is pretty complete (as mentioned elsewhere in this
> thread). You may still have some work to do, but likely easier than
> N900/N950.

Clearly we just need to get something usable going ourselves that works
with whatever people want to use. Waiting for some corporate solution
that's usable with mainline kernel has proven to be a waste of time.
And then maybe other usable products will follow.

Regards,

Tony