[Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

Hi!

(Please cc me on replies).

Significant percentage of phones run Linux kernel today, but geting
mainline kernel to work on a phone is very hard to do. (So hard, that
newest device that is close to working on recent mainline was made in
2009.) There are multiple obstacles, including huge patches from
silicon vendors, missing GNU/Linux userspace support that makes kernel
testing hard, interfaces unsuitable for phones and power management
problems.

Interested people:

Sebastian Reichel <sre@kernel.org>
Pali Rohár <pali.rohar@gmail.com>


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

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Linus Walleij]

On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:

> Significant percentage of phones run Linux kernel today, but geting
> mainline kernel to work on a phone is very hard to do. (So hard, that
> newest device that is close to working on recent mainline was made in
> 2009.) There are multiple obstacles, including huge patches from
> silicon vendors, missing GNU/Linux userspace support that makes kernel
> testing hard, interfaces unsuitable for phones and power management
> problems.
>
> Interested people:
>
> Sebastian Reichel <sre@kernel.org>
> Pali Rohár <pali.rohar@gmail.com>

I'm adding Björn Andersson <bjorn.andersson@sonymobile.com> to this list.

Björn has as of yesterday booted a mainline kernel on the SONY
Xperia Z3 and his company has demonstrated strong interest in
getting the mainline kernel to run on their handsets.
https://plus.google.com/102276447148493441479/posts/amRvpE8piSw

Yours,
Linus Walleij

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
> On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
> 
> > Significant percentage of phones run Linux kernel today, but geting
> > mainline kernel to work on a phone is very hard to do. (So hard, that
> > newest device that is close to working on recent mainline was made in
> > 2009.) There are multiple obstacles, including huge patches from
> > silicon vendors, missing GNU/Linux userspace support that makes kernel
> > testing hard, interfaces unsuitable for phones and power management
> > problems.
> >
> > Interested people:
> >
> > Sebastian Reichel <sre@kernel.org>
> > Pali Rohár <pali.rohar@gmail.com>
> 
> I'm adding Björn Andersson <bjorn.andersson@sonymobile.com> to this list.
> 
> Björn has as of yesterday booted a mainline kernel on the SONY
> Xperia Z3 and his company has demonstrated strong interest in
> getting the mainline kernel to run on their handsets.
> https://plus.google.com/102276447148493441479/posts/amRvpE8piSw

Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-December/078428.html

Signed-off-by: HeungJun, Kim <riverful.kim at samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

									Pavel

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

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Steven Rostedt]

On Thu, 23 Jul 2015 14:14:41 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
> > On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > > Significant percentage of phones run Linux kernel today, but geting
> > > mainline kernel to work on a phone is very hard to do. (So hard, that
> > > newest device that is close to working on recent mainline was made in
> > > 2009.) There are multiple obstacles, including huge patches from
> > > silicon vendors, missing GNU/Linux userspace support that makes kernel
> > > testing hard, interfaces unsuitable for phones and power management
> > > problems.

> 
> Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.

Seems like a reasonable topic, especially since KS is being held in
South Korea this year.

Although is this something to be a core topic or a tech topic? Does
this affect all subsystems, or just a set of drivers? Note, a core
topic wont get as much time for discussion as a tech topic would.

Also, what is expected to be solved at KS?

-- Steve

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown]

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

On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:

> Although is this something to be a core topic or a tech topic? Does
> this affect all subsystems, or just a set of drivers? Note, a core
> topic wont get as much time for discussion as a tech topic would.

It's basically all subsystems that get impacted, at the minute I'd say
it's more a plan of action and process discussion than a technical one
though in the context of KS planning that's quite probably the same
thing.

> Also, what is expected to be solved at KS?

Tim Bird (Cced) has been running some sessions at other conferences
scoping the problem and discussing ways to move forward on this, another
similar session might be useful.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Tim Bird]

On 07/23/2015 08:40 AM, Mark Brown wrote:
> On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
> 
>> Although is this something to be a core topic or a tech topic? Does
>> this affect all subsystems, or just a set of drivers? Note, a core
>> topic wont get as much time for discussion as a tech topic would.
> 
> It's basically all subsystems that get impacted, at the minute I'd say
> it's more a plan of action and process discussion than a technical one
> though in the context of KS planning that's quite probably the same
> thing.
> 
>> Also, what is expected to be solved at KS?
> 
> Tim Bird (Cced) has been running some sessions at other conferences
> scoping the problem and discussing ways to move forward on this, another
> similar session might be useful.

As Mark says, I've been working on almost exactly this topic for several
months now.  Last year I conducted a survey investigating obstacles
that developers (mostly corporate product developers) have in mainlining.
There are lots of non-technical issues that are worth working on (version
gap, corporate incentives, training, etc.), but which are outside
the scope of the kernel summit.

There are also some technical areas where I think coordinated
effort might be useful, to identify deficiencies and collaborate on
progress.  These might be worth discussing at the summit.

In March of this year, I analysed code from several shipping phones
(representing a number of different SoCs, including both ARM and
Intel-architecture CPUs), and found that most products have between
1.2 and 3 million lines of code out-of-tree.  We are still in progress of
finding patterns of out-of-treeness, to inform decisions about technical
projects going forward.

There is now a wiki page at:
See http://elinux.org/Kernel_areas_of_focus_for_mainlining
In particular it has a table showing certain areas that tend to have
a lot of out-of-tree code (e.g. most phones have between 80K to
100K of lines of wireless driver support out-of-mainline)

IMHO it would be useful to discuss these areas, to see if there
are technical reasons for these deficiencies, and work to resolve
them.
 -- Tim
 

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Bjorn Andersson]

On Tue 28 Jul 15:09 PDT 2015, Tim Bird wrote:

> On 07/23/2015 08:40 AM, Mark Brown wrote:
> > On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
> > 
> >> Although is this something to be a core topic or a tech topic? Does
> >> this affect all subsystems, or just a set of drivers? Note, a core
> >> topic wont get as much time for discussion as a tech topic would.
> > 
> > It's basically all subsystems that get impacted, at the minute I'd say
> > it's more a plan of action and process discussion than a technical one
> > though in the context of KS planning that's quite probably the same
> > thing.
> > 
> >> Also, what is expected to be solved at KS?
> > 
> > Tim Bird (Cced) has been running some sessions at other conferences
> > scoping the problem and discussing ways to move forward on this, another
> > similar session might be useful.
> 
[..]
> In particular it has a table showing certain areas that tend to have
> a lot of out-of-tree code (e.g. most phones have between 80K to
> 100K of lines of wireless driver support out-of-mainline)
> 

In the Xperia Z3 we have a bcm4339 and I managed to get that up and
running with the brcmf driver on mainline last week - pending Qualcomm
regulator support and 1 pending patch in mmc.

For some of our other devices we have various Qualcomm based chips and
there's progress towards getting those up to speed on mainline as well
(wcn36xx).

Regards,
Bjorn

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rob Herring]

On Tue, Jul 28, 2015 at 6:07 PM, Bjorn Andersson
<bjorn.andersson@sonymobile.com> wrote:
> On Tue 28 Jul 15:09 PDT 2015, Tim Bird wrote:
>
>> On 07/23/2015 08:40 AM, Mark Brown wrote:
>> > On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
>> >
>> >> Although is this something to be a core topic or a tech topic? Does
>> >> this affect all subsystems, or just a set of drivers? Note, a core
>> >> topic wont get as much time for discussion as a tech topic would.
>> >
>> > It's basically all subsystems that get impacted, at the minute I'd say
>> > it's more a plan of action and process discussion than a technical one
>> > though in the context of KS planning that's quite probably the same
>> > thing.
>> >
>> >> Also, what is expected to be solved at KS?
>> >
>> > Tim Bird (Cced) has been running some sessions at other conferences
>> > scoping the problem and discussing ways to move forward on this, another
>> > similar session might be useful.
>>
> [..]
>> In particular it has a table showing certain areas that tend to have
>> a lot of out-of-tree code (e.g. most phones have between 80K to
>> 100K of lines of wireless driver support out-of-mainline)

Practically every vendor BSP I've looked at has Broadcom vendor driver
copied in.

> In the Xperia Z3 we have a bcm4339 and I managed to get that up and
> running with the brcmf driver on mainline last week - pending Qualcomm
> regulator support and 1 pending patch in mmc.

That's no small feat, but the real problem here are the feature gaps
with mainline. Things I've heard about are switching between AP and
client modes, P2P support, Android specific power optimized firmware,
etc. We do have to start somewhere, but as long as vendors are putting
new features in their vendor drivers first and not getting pushback
from customers to have mainline (or mainline + feature X) drivers it
is going to be a loosing battle.

The WiFi side is actually in better shape than BT. With BT, we have
Bluedroid vs. BlueZ, no real DT bindings to describe BT chips (plenty
of examples of how not to do it[1]), and chip specific userspace
initialization (firmware loading, baudrate setup, power mgt).

NFC is even worse. What's in the kernel for NFC is generally not used
by Android AFAIK.

Rob

[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg937944.html

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Bjorn Andersson]

On Fri 31 Jul 09:18 PDT 2015, Rob Herring wrote:

> On Tue, Jul 28, 2015 at 6:07 PM, Bjorn Andersson
> <bjorn.andersson@sonymobile.com> wrote:
> > On Tue 28 Jul 15:09 PDT 2015, Tim Bird wrote:
> >
> >> On 07/23/2015 08:40 AM, Mark Brown wrote:
> >> > On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
> >> >
> >> >> Although is this something to be a core topic or a tech topic? Does
> >> >> this affect all subsystems, or just a set of drivers? Note, a core
> >> >> topic wont get as much time for discussion as a tech topic would.
> >> >
> >> > It's basically all subsystems that get impacted, at the minute I'd say
> >> > it's more a plan of action and process discussion than a technical one
> >> > though in the context of KS planning that's quite probably the same
> >> > thing.
> >> >
> >> >> Also, what is expected to be solved at KS?
> >> >
> >> > Tim Bird (Cced) has been running some sessions at other conferences
> >> > scoping the problem and discussing ways to move forward on this, another
> >> > similar session might be useful.
> >>
> > [..]
> >> In particular it has a table showing certain areas that tend to have
> >> a lot of out-of-tree code (e.g. most phones have between 80K to
> >> 100K of lines of wireless driver support out-of-mainline)
> 
> Practically every vendor BSP I've looked at has Broadcom vendor driver
> copied in.
> 

Right, everyone inherits the bcmdhd driver from the android-common tree,
and uses that with some level of patching.

> > In the Xperia Z3 we have a bcm4339 and I managed to get that up and
> > running with the brcmf driver on mainline last week - pending Qualcomm
> > regulator support and 1 pending patch in mmc.
> 
> That's no small feat, but the real problem here are the feature gaps
> with mainline. Things I've heard about are switching between AP and
> client modes, P2P support, Android specific power optimized firmware,
> etc.

Right, I expect both a functional and a stability gap. But the my goal
is to get to the point where our WiFi team can work on these issues -
even if that's on the side of normal product development for the
foreseeable future.

> We do have to start somewhere, but as long as vendors are putting
> new features in their vendor drivers first and not getting pushback
> from customers to have mainline (or mainline + feature X) drivers it
> is going to be a loosing battle.
> 

Right, but we (Sony) are one of those customers' of Broadcomm and by
just having this running we are in a better state of pushing back.

For now I've only tested this on SDIO based bcm devices though, the
latest batch are PCIe; so we have to get back to that...

> The WiFi side is actually in better shape than BT. With BT, we have
> Bluedroid vs. BlueZ, no real DT bindings to describe BT chips (plenty
> of examples of how not to do it[1]), and chip specific userspace
> initialization (firmware loading, baudrate setup, power mgt).
> 

In other words, plenty of savings to be found :)

> NFC is even worse. What's in the kernel for NFC is generally not used
> by Android AFAIK.
> 

The NFC implementation used by Android is completely done in userspace.

The kernel parts looks promising, but last time I looked Android support
was only at the horizon of their todo list; with plenty of
not-so-android-compatible pieces put in before that (e.g DBUS)

Regards,
Bjorn

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Johannes Berg]

On Fri, 2015-07-31 at 09:56 -0700, Bjorn Andersson wrote:
> 
> For now I've only tested this on SDIO based bcm devices though, the
> latest batch are PCIe; so we have to get back to that...
> 

Are the PCIe ones also bcmdhd? Until recently, all I knew was that the
PCIe ones were softmac, i.e. bcmsmac (in mainline) or not supported at
all. Are there fullmac PCIe ones now?

johannes

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Tim Bird]

On 07/31/2015 09:18 AM, Rob Herring wrote:
> On Tue, Jul 28, 2015 at 6:07 PM, Bjorn Andersson
> <bjorn.andersson@sonymobile.com> wrote:
>> On Tue 28 Jul 15:09 PDT 2015, Tim Bird wrote:
>>
>>> On 07/23/2015 08:40 AM, Mark Brown wrote:
>>>> On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
>>>>
>>>>> Although is this something to be a core topic or a tech topic? Does
>>>>> this affect all subsystems, or just a set of drivers? Note, a core
>>>>> topic wont get as much time for discussion as a tech topic would.
>>>>
>>>> It's basically all subsystems that get impacted, at the minute I'd say
>>>> it's more a plan of action and process discussion than a technical one
>>>> though in the context of KS planning that's quite probably the same
>>>> thing.
>>>>
>>>>> Also, what is expected to be solved at KS?
>>>>
>>>> Tim Bird (Cced) has been running some sessions at other conferences
>>>> scoping the problem and discussing ways to move forward on this, another
>>>> similar session might be useful.
>>>
>> [..]
>>> In particular it has a table showing certain areas that tend to have
>>> a lot of out-of-tree code (e.g. most phones have between 80K to
>>> 100K of lines of wireless driver support out-of-mainline)
> 
> Practically every vendor BSP I've looked at has Broadcom vendor driver
> copied in.
> 
>> In the Xperia Z3 we have a bcm4339 and I managed to get that up and
>> running with the brcmf driver on mainline last week - pending Qualcomm
>> regulator support and 1 pending patch in mmc.
> 
> That's no small feat, but the real problem here are the feature gaps
> with mainline. Things I've heard about are switching between AP and
> client modes, P2P support, Android specific power optimized firmware,
> etc. We do have to start somewhere, but as long as vendors are putting
> new features in their vendor drivers first and not getting pushback
> from customers to have mainline (or mainline + feature X) drivers it
> is going to be a losing battle.

I agree completely.

I'm doing some research now on the usefulness of backporting the current
brcm80211 code to 3.18, which many of the next round of Android phones
will be using.  This at least exposes the stack to mobile device vendors
and device owners, who (with some luck) can test it in production settings
and find deficiencies.

If we do nothing, then we'll have another full generation of phones
which focus exclusively on out-of-tree wireless driver code.  This will
end up delaying the adoption of the mainline driver (in this product
area) by another few years, IMHO.

Feedback on the and sanity of this approach are welcome. :-)  If anyone knows
things about the broadcom driver or the wireless stack that would make this
backport particularly costly, please let me know.
 -- Tim

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[John W. Linville]

On Fri, Jul 31, 2015 at 10:25:47AM -0700, Tim Bird wrote:

<snip>

> I'm doing some research now on the usefulness of backporting the current
> brcm80211 code to 3.18, which many of the next round of Android phones
> will be using.  This at least exposes the stack to mobile device vendors
> and device owners, who (with some luck) can test it in production settings
> and find deficiencies.
> 
> If we do nothing, then we'll have another full generation of phones
> which focus exclusively on out-of-tree wireless driver code.  This will
> end up delaying the adoption of the mainline driver (in this product
> area) by another few years, IMHO.
> 
> Feedback on the and sanity of this approach are welcome. :-)  If anyone knows
> things about the broadcom driver or the wireless stack that would make this
> backport particularly costly, please let me know.

It probably goes without saying, but you should make sure that
brcm80211 actually supports the chips in use.  Broadcom has not done a
very good job at keeping brcm80211 up-to-date with the hardware that
they actually release for laptops.  Installing out-of-tree Broadcom
wireless drivers on laptops still seems to be a common requirement. :-(

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Linus Walleij]

On Fri, Jul 31, 2015 at 6:18 PM, Rob Herring <robherring2@gmail.com> wrote:

> The WiFi side is actually in better shape than BT. With BT, we have
> Bluedroid vs. BlueZ, no real DT bindings to describe BT chips (plenty
> of examples of how not to do it[1]), and chip specific userspace
> initialization (firmware loading, baudrate setup, power mgt).

I was looking at it at one point and couldn't wrap my head around how
the BT support was devised from a kernel point of view.

It seems BT chips more often than not sit on a UART connection
(often very high speed) and since there is no "uart bus" or "serial bus"
akin to what we have for I2C or SPI, it is actually impossible to
instantiate them properly in the driver model. Instead BT drivers
are poked and peeked from userspace using the line discipline as
if they were some kind of modem, just in-kernel.

The stuff going on up there may seem simple and intuitive for the
BT people but for a random kernel engineer like me it seems like
magic. This makes them hard to review and upstream for what I
can see.

Yours,
Linus Walleij

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rob Herring]

On Mon, Aug 3, 2015 at 2:42 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Jul 31, 2015 at 6:18 PM, Rob Herring <robherring2@gmail.com> wrote:
>
>> The WiFi side is actually in better shape than BT. With BT, we have
>> Bluedroid vs. BlueZ, no real DT bindings to describe BT chips (plenty
>> of examples of how not to do it[1]), and chip specific userspace
>> initialization (firmware loading, baudrate setup, power mgt).
>
> I was looking at it at one point and couldn't wrap my head around how
> the BT support was devised from a kernel point of view.
>
> It seems BT chips more often than not sit on a UART connection
> (often very high speed) and since there is no "uart bus" or "serial bus"
> akin to what we have for I2C or SPI, it is actually impossible to
> instantiate them properly in the driver model. Instead BT drivers
> are poked and peeked from userspace using the line discipline as
> if they were some kind of modem, just in-kernel.

Yes, but then there's always some side band signals for regulator
control, reset, clocks, wake-up, rf-kill, etc. that needs a glue
driver. There's been some work by Neil Brown to create a UART slave
bus[1] and I've gotten several other UART device bindings recently,
but they all suffer from being one off device bindings done in
different ways and I want to see something common here.

It also seems the BT folks are working on moving more of the setup
into the kernel and creating a proper subsystem. I'm not sure about
the details on that.

Rob

[1] https://lwn.net/Articles/643878/

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Marcel Holtmann]

Hi Rob,

>>> The WiFi side is actually in better shape than BT. With BT, we have
>>> Bluedroid vs. BlueZ, no real DT bindings to describe BT chips (plenty
>>> of examples of how not to do it[1]), and chip specific userspace
>>> initialization (firmware loading, baudrate setup, power mgt).
>> 
>> I was looking at it at one point and couldn't wrap my head around how
>> the BT support was devised from a kernel point of view.
>> 
>> It seems BT chips more often than not sit on a UART connection
>> (often very high speed) and since there is no "uart bus" or "serial bus"
>> akin to what we have for I2C or SPI, it is actually impossible to
>> instantiate them properly in the driver model. Instead BT drivers
>> are poked and peeked from userspace using the line discipline as
>> if they were some kind of modem, just in-kernel.
> 
> Yes, but then there's always some side band signals for regulator
> control, reset, clocks, wake-up, rf-kill, etc. that needs a glue
> driver. There's been some work by Neil Brown to create a UART slave
> bus[1] and I've gotten several other UART device bindings recently,
> but they all suffer from being one off device bindings done in
> different ways and I want to see something common here.
> 
> It also seems the BT folks are working on moving more of the setup
> into the kernel and creating a proper subsystem. I'm not sure about
> the details on that.

we are indeed moving a lot of the initialization and handling of the Bluetooth controller into the kernel. So that this can also be shared between USB and UART based controllers.

The work on UART slaves (or whatever it will be called eventually) is important for Bluetooth and most likely GPS and NFC in the future. It then allows to define all the nasty behind the curtain details of that UART via DT or ACPI in vendor drivers.

The Bluetooth driver in theory should not care at all and generally speaking it doesn't since the Bluetooth SIG has defined a Host Controller Interface (HCI) that is standard. Meaning all operation are well defined. Just the transport over UART has many vendor specific tweaks. The two most obvious ones are deep sleep modes and running the UART at high speeds.

In a perfect world I would prefer we are not using the Bluetooth HCI line discipline at all. The problem right now is that everybody wants to enable the UART as /dev/ttyFOO and then move on. However in reality they are not general purpose TTY devices. The only thing you can ever do with them is tell the Bluetooth subsystem that there is a TTY device and attach its line discipline to it.

The majority of these high speed UARTs in phones, tablets and also laptops with Bluetooth chips attached to it should just expose a special bus that we can then enumerate. Pretending to a general purpose UART is actually cumbersome and you will just see more and more of these.

While Bluetooth supports USB and SDIO as well, the most common other low power interface is the UART (using H:4 or 3-Wire Bluetooth transports). The usage of PCI or SPI or I2C as interface to Bluetooth never really happened.

Current Bluetooth/WiFi chips usually come in these flavors. WiFi on PCIe + Bluetooth on USB, WiFi + Bluetooth on USB, WiFi + Bluetooth on SDIO and WiFi on SDIO + Bluetooth on UART. Now if you are building a mobile phone, you can choose the low power version you like. And this often turns into SDIO for WiFi and UART for Bluetooth.

Or and did I mention that some manufactures actually put FM radio and GPS controls behind the Bluetooth chip. So access to these slave devices goes via the Bluetooth HCI. This means that you have this fun dependency:

FM radio -> Bluetooth HCI -> UART -> UART slave

Some nasty solution here are to double stack the line disciplines and have some sort of shared transport driver in between. I am trying to actually fix that so that Bluetooth drivers can expose proper platform buses with correctly assigned resources that the FM radio driver would just enumerate on. So that part is in the works as well.

We can also talk about A4WP and the corner cases where your battery is so drained that the Bluetooth Low Energy portion of your hardware is the only one that gets powered first before you get your device back to life. In case this is not obvious, the A4WP wireless charging technology using Bluetooth Low Energy for its communication.

Regards

Marcel

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Linus Walleij]

On Tue, Aug 4, 2015 at 12:36 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Rob,

>> There's been some work by Neil Brown to create a UART slave
>> bus[1] (...)

> The work on UART slaves (or whatever it will be called eventually) is important
> for Bluetooth and most likely GPS and NFC in the future. It then allows to define
> all the nasty behind the curtain details of that UART via DT or ACPI in vendor drivers.

I agree 100%, and I think I have a simple enough in-kernel usecase so I can
get testing these series.

It seems GPS and NFC and other code is being kept out of the kernel
because of the absense of a UART slave bus and all the hazzle of handling
this.

> In a perfect world I would prefer we are not using the Bluetooth HCI line discipline
> at all. The problem right now is that everybody wants to enable the UART as
> /dev/ttyFOO and then move on. However in reality they are not general purpose
> TTY devices. The only thing you can ever do with them is tell the Bluetooth
> subsystem that there is a TTY device and attach its line discipline to it.

This is done from userspace right? I never managed to wrap my head around
this because it seemed so odd and plainly hackish.

In this ST-Ericsson driver for CG2900:
http://marc.info/?l=linux-kernel&m=134873373526049&w=2
the HCI link is used to tunnel things that are not Bluetooth, also
GPS and FM radio is controlled over HCI. Yeah sorry, I didn't invent
it... the HCI is then run over a UART.

Yours,
Linus Walleij

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Linus Walleij]

On Wed, Aug 5, 2015 at 10:40 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Aug 4, 2015 at 12:36 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
(...)
>> In a perfect world I would prefer we are not using the Bluetooth HCI line discipline
>> at all. The problem right now is that everybody wants to enable the UART as
>> /dev/ttyFOO and then move on. However in reality they are not general purpose
>> TTY devices. The only thing you can ever do with them is tell the Bluetooth
>> subsystem that there is a TTY device and attach its line discipline to it.
>
> This is done from userspace right? I never managed to wrap my head around
> this because it seemed so odd and plainly hackish.
>
> In this ST-Ericsson driver for CG2900:
> http://marc.info/?l=linux-kernel&m=134873373526049&w=2
> the HCI link is used to tunnel things that are not Bluetooth, also
> GPS and FM radio is controlled over HCI. Yeah sorry, I didn't invent
> it... the HCI is then run over a UART.

Damned I snapped off the latter part of your message. Typing and
mailing to quickly. This was obviously in response to:

>> Or and did I mention that some manufactures actually put FM radio and GPS
>> controls behind the Bluetooth chip. So access to these slave devices goes
>> via the Bluetooth HCI. This means that you have this fun dependency:
>>
>> FM radio -> Bluetooth HCI -> UART -> UART slave

So what I wanted to ask is who else is doing this apart from
CG2900/STLC2690? Is it a common pattern?

>> Some nasty solution here are to double stack the line disciplines and have
>> some sort of shared transport driver in between. I am trying to actually fix
>> that so that Bluetooth drivers can expose proper platform buses with
>> correctly assigned resources that the FM radio driver would just
>> enumerate on. So that part is in the works as well.

IIRC that was also suggested to us by Vitaly Wool when my
colleagues tried to mainline CG2900/STLC2690, so very very nice
to see this happening! Put me on CC when you post something,
not that it's my expert area but would be happy to help if I can.

Yours,
Linus Walleij

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Samuel Ortiz]

On Wed, Aug 05, 2015 at 10:46:19AM +0200, Linus Walleij wrote:
> On Wed, Aug 5, 2015 at 10:40 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> > On Tue, Aug 4, 2015 at 12:36 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> (...)
> >> In a perfect world I would prefer we are not using the Bluetooth HCI line discipline
> >> at all. The problem right now is that everybody wants to enable the UART as
> >> /dev/ttyFOO and then move on. However in reality they are not general purpose
> >> TTY devices. The only thing you can ever do with them is tell the Bluetooth
> >> subsystem that there is a TTY device and attach its line discipline to it.
> >
> > This is done from userspace right? I never managed to wrap my head around
> > this because it seemed so odd and plainly hackish.
> >
> > In this ST-Ericsson driver for CG2900:
> > http://marc.info/?l=linux-kernel&m=134873373526049&w=2
> > the HCI link is used to tunnel things that are not Bluetooth, also
> > GPS and FM radio is controlled over HCI. Yeah sorry, I didn't invent
> > it... the HCI is then run over a UART.
> 
> Damned I snapped off the latter part of your message. Typing and
> mailing to quickly. This was obviously in response to:
> 
> >> Or and did I mention that some manufactures actually put FM radio and GPS
> >> controls behind the Bluetooth chip. So access to these slave devices goes
> >> via the Bluetooth HCI. This means that you have this fun dependency:
> >>
> >> FM radio -> Bluetooth HCI -> UART -> UART slave
> 
> So what I wanted to ask is who else is doing this apart from
> CG2900/STLC2690? Is it a common pattern?
Unfortunately it seems to be a common pattern. TI combos used to do
that at well.

Cheers,
Samuel.

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

Hi!

> >> Or and did I mention that some manufactures actually put FM radio and GPS
> >> controls behind the Bluetooth chip. So access to these slave devices goes
> >> via the Bluetooth HCI. This means that you have this fun dependency:
> >>
> >> FM radio -> Bluetooth HCI -> UART -> UART slave
> 
> So what I wanted to ask is who else is doing this apart from
> CG2900/STLC2690? Is it a common pattern?

The most important phone in the world (*) does it like that.

- it has extra GPIOs to handle power management

- GPS is connected to the GSM parts, not to bluetooth

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

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Samuel Ortiz]

On Wed, Aug 05, 2015 at 10:40:11AM +0200, Linus Walleij wrote:
> On Tue, Aug 4, 2015 at 12:36 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> > Hi Rob,
> 
> >> There's been some work by Neil Brown to create a UART slave
> >> bus[1] (...)
> 
> > The work on UART slaves (or whatever it will be called eventually) is important
> > for Bluetooth and most likely GPS and NFC in the future. It then allows to define
> > all the nasty behind the curtain details of that UART via DT or ACPI in vendor drivers.
> 
> I agree 100%, and I think I have a simple enough in-kernel usecase so I can
> get testing these series.
> 
> It seems GPS and NFC and other code is being kept out of the kernel
> because of the absense of a UART slave bus and all the hazzle of handling
> this.
Keeping it in userspace means vendors can provide their stacks under
the apache license, not the kernel GPL one.

Cheers,
Samuel.

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Marcel Holtmann]

Hi Linus,

>>> There's been some work by Neil Brown to create a UART slave
>>> bus[1] (...)
> 
>> The work on UART slaves (or whatever it will be called eventually) is important
>> for Bluetooth and most likely GPS and NFC in the future. It then allows to define
>> all the nasty behind the curtain details of that UART via DT or ACPI in vendor drivers.
> 
> I agree 100%, and I think I have a simple enough in-kernel usecase so I can
> get testing these series.
> 
> It seems GPS and NFC and other code is being kept out of the kernel
> because of the absense of a UART slave bus and all the hazzle of handling
> this.

we have NFC subsystem in the kernel with wide vendor support. We can discuss why Android is insisting on doing NFC in userspace, but that is a complete different off-topic ;)

GPS is a bit of a funky one. Historically the NMEA protocol is pretty much bound to an UART running at 4800 baud. So I can see a bit of reasoning behind it. These days NMEA is not the only protocol and a some GPS chip companies have developed their own ones.

Also GPS is found as Serial Port over Bluetooth, as USB-Serial, as actually serial port and so on. Then you have the really funky ones where it is hooked over a Bluetooth HCI interface, or as part a magic AT command port of a GSM modem. And if you want to get really funky then you have NMEA over Qualcomm QMI protocol.

These days LTE modems normally include the GPS and GLONASS chip. So you have to go through the LTE modem to access it.

With the oFono telephony stack, we actually added a location provider API for getting access to GPS. So you can request GPS access via D-Bus and it will then return you an fd. That fd might map to a physical TTY, or a virtual port on the GSM 07.11 multiplexer or via QMI.

And there are more odd ones out there.

>> In a perfect world I would prefer we are not using the Bluetooth HCI line discipline
>> at all. The problem right now is that everybody wants to enable the UART as
>> /dev/ttyFOO and then move on. However in reality they are not general purpose
>> TTY devices. The only thing you can ever do with them is tell the Bluetooth
>> subsystem that there is a TTY device and attach its line discipline to it.
> 
> This is done from userspace right? I never managed to wrap my head around
> this because it seemed so odd and plainly hackish.
> 
> In this ST-Ericsson driver for CG2900:
> http://marc.info/?l=linux-kernel&m=134873373526049&w=2
> the HCI link is used to tunnel things that are not Bluetooth, also
> GPS and FM radio is controlled over HCI. Yeah sorry, I didn't invent
> it... the HCI is then run over a UART.

Yes, pretty much. TI calls this shared transport aka TI-ST which is also pretty messy. It hacks around setup problems that should be solved a clean way.

For example one cumbersome details back in the days was that the Bluetooth chip comes without a persistent address in these embedded devices. So the address is stored in the host filesystem or in a dedicated one-time flash section.

Of course to program and address, you need HCI commands. For starting the Bluetooth stack, you need a valid address. We added support for handling this chicken and egg problem cleanly by abstracting the bringup into a setup stage. So you can start the HCI transport without starting the Bluetooth stack.

This in the end also resulted in the support of what is called HCI User Channel. Meaning you can drive a Bluetooth stack from userspace if you wanted to, but you would use the Bluetooth subsystem still for the transport abstraction to the hardware and the initial setup like firmware loading and address programming. This lead to the nice feature that we can run Android's Bluedroid stack on top of the Linux Bluetooth subsystem and avoid having to enable hardware for different stacks over and over again.

Regards

Marcel

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rob Herring]

On 08/03/2015 05:36 PM, Marcel Holtmann wrote:
> Hi Rob,
> 
>>>> The WiFi side is actually in better shape than BT. With BT, we
>>>> have Bluedroid vs. BlueZ, no real DT bindings to describe BT
>>>> chips (plenty of examples of how not to do it[1]), and chip
>>>> specific userspace initialization (firmware loading, baudrate
>>>> setup, power mgt).
>>> 
>>> I was looking at it at one point and couldn't wrap my head around
>>> how the BT support was devised from a kernel point of view.
>>> 
>>> It seems BT chips more often than not sit on a UART connection 
>>> (often very high speed) and since there is no "uart bus" or
>>> "serial bus" akin to what we have for I2C or SPI, it is actually
>>> impossible to instantiate them properly in the driver model.
>>> Instead BT drivers are poked and peeked from userspace using the
>>> line discipline as if they were some kind of modem, just
>>> in-kernel.
>> 
>> Yes, but then there's always some side band signals for regulator 
>> control, reset, clocks, wake-up, rf-kill, etc. that needs a glue 
>> driver. There's been some work by Neil Brown to create a UART
>> slave bus[1] and I've gotten several other UART device bindings
>> recently, but they all suffer from being one off device bindings
>> done in different ways and I want to see something common here.
>> 
>> It also seems the BT folks are working on moving more of the setup 
>> into the kernel and creating a proper subsystem. I'm not sure
>> about the details on that.
> 
> we are indeed moving a lot of the initialization and handling of the
> Bluetooth controller into the kernel. So that this can also be shared
> between USB and UART based controllers.
> 
> The work on UART slaves (or whatever it will be called eventually) is
> important for Bluetooth and most likely GPS and NFC in the future. It
> then allows to define all the nasty behind the curtain details of
> that UART via DT or ACPI in vendor drivers.
> 
> The Bluetooth driver in theory should not care at all and generally
> speaking it doesn't since the Bluetooth SIG has defined a Host
> Controller Interface (HCI) that is standard. Meaning all operation
> are well defined. Just the transport over UART has many vendor
> specific tweaks. The two most obvious ones are deep sleep modes and
> running the UART at high speeds.
> 
> In a perfect world I would prefer we are not using the Bluetooth HCI
> line discipline at all. The problem right now is that everybody wants
> to enable the UART as /dev/ttyFOO and then move on. However in
> reality they are not general purpose TTY devices. The only thing you
> can ever do with them is tell the Bluetooth subsystem that there is a
> TTY device and attach its line discipline to it.
> 
> The majority of these high speed UARTs in phones, tablets and also
> laptops with Bluetooth chips attached to it should just expose a
> special bus that we can then enumerate. Pretending to a general
> purpose UART is actually cumbersome and you will just see more and
> more of these.

Hardware-wise, the UARTs on SOCs I've seen are no different whether used
for console or BT device. Of course, running UARTs at 3-4Mbps means
things like hooking up external DMA controllers which are kind of
pointless for normal tty use.

Perhaps BT and other UART devices could interface directly to the
serial_core/uart_port layer rather than the tty layer? I've got no idea
if that would buy us anything though. I'm guessing part of the problem
here is the requirements for a character based interface are different
from a more packet based interface (HCI) even if the h/w is the same.


> While Bluetooth supports USB and SDIO as well, the most common other
> low power interface is the UART (using H:4 or 3-Wire Bluetooth
> transports). The usage of PCI or SPI or I2C as interface to Bluetooth
> never really happened.
> 
> Current Bluetooth/WiFi chips usually come in these flavors. WiFi on
> PCIe + Bluetooth on USB, WiFi + Bluetooth on USB, WiFi + Bluetooth on
> SDIO and WiFi on SDIO + Bluetooth on UART. Now if you are building a
> mobile phone, you can choose the low power version you like. And this
> often turns into SDIO for WiFi and UART for Bluetooth.

SDIO is such a pain. The hosts and devices have so many quirks as there
is no interoperability testing.

Do you ever see interdependencies between the BT and WiFi portions of
the combo chips which have different host interfaces? They seem to be
fairly well separated AFAICT. Some things like shared irq, clocks or
regulators can be dealt with easily, but if you had things like the WiFi
firmware has to be loaded and running before BT can work or vice-versa
that would be a pain to deal with. That would impact how we do DT
bindings as well.

> Or and did I mention that some manufactures actually put FM radio and
> GPS controls behind the Bluetooth chip. So access to these slave
> devices goes via the Bluetooth HCI. This means that you have this fun
> dependency:
> 
> FM radio -> Bluetooth HCI -> UART -> UART slave
> 
> Some nasty solution here are to double stack the line disciplines and
> have some sort of shared transport driver in between. I am trying to
> actually fix that so that Bluetooth drivers can expose proper
> platform buses with correctly assigned resources that the FM radio
> driver would just enumerate on. So that part is in the works as
> well.
> 
> We can also talk about A4WP and the corner cases where your battery
> is so drained that the Bluetooth Low Energy portion of your hardware
> is the only one that gets powered first before you get your device
> back to life. In case this is not obvious, the A4WP wireless charging
> technology using Bluetooth Low Energy for its communication.

Always something fun and new to deal with. :)

Rob

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Marcel Holtmann]

Hi Rob,

>>>>> The WiFi side is actually in better shape than BT. With BT, we
>>>>> have Bluedroid vs. BlueZ, no real DT bindings to describe BT
>>>>> chips (plenty of examples of how not to do it[1]), and chip
>>>>> specific userspace initialization (firmware loading, baudrate
>>>>> setup, power mgt).
>>>> 
>>>> I was looking at it at one point and couldn't wrap my head around
>>>> how the BT support was devised from a kernel point of view.
>>>> 
>>>> It seems BT chips more often than not sit on a UART connection 
>>>> (often very high speed) and since there is no "uart bus" or
>>>> "serial bus" akin to what we have for I2C or SPI, it is actually
>>>> impossible to instantiate them properly in the driver model.
>>>> Instead BT drivers are poked and peeked from userspace using the
>>>> line discipline as if they were some kind of modem, just
>>>> in-kernel.
>>> 
>>> Yes, but then there's always some side band signals for regulator 
>>> control, reset, clocks, wake-up, rf-kill, etc. that needs a glue 
>>> driver. There's been some work by Neil Brown to create a UART
>>> slave bus[1] and I've gotten several other UART device bindings
>>> recently, but they all suffer from being one off device bindings
>>> done in different ways and I want to see something common here.
>>> 
>>> It also seems the BT folks are working on moving more of the setup 
>>> into the kernel and creating a proper subsystem. I'm not sure
>>> about the details on that.
>> 
>> we are indeed moving a lot of the initialization and handling of the
>> Bluetooth controller into the kernel. So that this can also be shared
>> between USB and UART based controllers.
>> 
>> The work on UART slaves (or whatever it will be called eventually) is
>> important for Bluetooth and most likely GPS and NFC in the future. It
>> then allows to define all the nasty behind the curtain details of
>> that UART via DT or ACPI in vendor drivers.
>> 
>> The Bluetooth driver in theory should not care at all and generally
>> speaking it doesn't since the Bluetooth SIG has defined a Host
>> Controller Interface (HCI) that is standard. Meaning all operation
>> are well defined. Just the transport over UART has many vendor
>> specific tweaks. The two most obvious ones are deep sleep modes and
>> running the UART at high speeds.
>> 
>> In a perfect world I would prefer we are not using the Bluetooth HCI
>> line discipline at all. The problem right now is that everybody wants
>> to enable the UART as /dev/ttyFOO and then move on. However in
>> reality they are not general purpose TTY devices. The only thing you
>> can ever do with them is tell the Bluetooth subsystem that there is a
>> TTY device and attach its line discipline to it.
>> 
>> The majority of these high speed UARTs in phones, tablets and also
>> laptops with Bluetooth chips attached to it should just expose a
>> special bus that we can then enumerate. Pretending to a general
>> purpose UART is actually cumbersome and you will just see more and
>> more of these.
> 
> Hardware-wise, the UARTs on SOCs I've seen are no different whether used
> for console or BT device. Of course, running UARTs at 3-4Mbps means
> things like hooking up external DMA controllers which are kind of
> pointless for normal tty use.
> 
> Perhaps BT and other UART devices could interface directly to the
> serial_core/uart_port layer rather than the tty layer? I've got no idea
> if that would buy us anything though. I'm guessing part of the problem
> here is the requirements for a character based interface are different
> from a more packet based interface (HCI) even if the h/w is the same.

interfacing directly with the serial / UART layer would be beneficial. For example ACPI already describes if the UART is used for Bluetooth operation and what settings it expects. That means that there is really no point in hooking it up as /dev/ttyFOO and then expect userspace to discover it again and attach a line discipline to it.

However for this to work, the UART layer would have to have some smarts to turn the extra ACPI provided information into a decision between /dev/ttyFOO and the creation of platform device. If such a platform device is present, we can then easily enumerate from a simple Bluetooth H:4 or 3-Wire driver. It just bind it it similar to what USB and SDIO is doing.

And of course exposing the same via DT instead of ACPI should be possible as well. I just know that ACPI has this since on Intel platforms it has been exposed like this for a while now. The main problem is that non of this is available easily to userspace to make the same smart decision on what TTY device node is for Bluetooth and what is the actual vendor of the Bluetooth chip. We need that as well to drive different firmware loading strategies.

Instead of a platform device, the TTY / UART layer could also turn into its own bus for these kind of things. I just don't know if bus vs platform device is the right solution here.

>> While Bluetooth supports USB and SDIO as well, the most common other
>> low power interface is the UART (using H:4 or 3-Wire Bluetooth
>> transports). The usage of PCI or SPI or I2C as interface to Bluetooth
>> never really happened.
>> 
>> Current Bluetooth/WiFi chips usually come in these flavors. WiFi on
>> PCIe + Bluetooth on USB, WiFi + Bluetooth on USB, WiFi + Bluetooth on
>> SDIO and WiFi on SDIO + Bluetooth on UART. Now if you are building a
>> mobile phone, you can choose the low power version you like. And this
>> often turns into SDIO for WiFi and UART for Bluetooth.
> 
> SDIO is such a pain. The hosts and devices have so many quirks as there
> is no interoperability testing.

What I have found is that the quirks are in the host controller for SDIO. Once that is working, the drivers have less quirks to handle. Then again, the number of Bluetooth based SDIO devices is limited. The majority of them are UART based in embedded devices.

> Do you ever see interdependencies between the BT and WiFi portions of
> the combo chips which have different host interfaces? They seem to be
> fairly well separated AFAICT. Some things like shared irq, clocks or
> regulators can be dealt with easily, but if you had things like the WiFi
> firmware has to be loaded and running before BT can work or vice-versa
> that would be a pain to deal with. That would impact how we do DT
> bindings as well.

In the combo chips the vendor normally has figured this out. So I have not heard about large. I can speak about some funky stuff from the past that never made it to the market, but lets not go there.

Regards

Marcel

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Linus Walleij]

On Wed, Aug 5, 2015 at 7:00 PM, Marcel Holtmann <marcel@holtmann.org> wrote:

>>> Current Bluetooth/WiFi chips usually come in these flavors. WiFi on
>>> PCIe + Bluetooth on USB, WiFi + Bluetooth on USB, WiFi + Bluetooth on
>>> SDIO and WiFi on SDIO + Bluetooth on UART. Now if you are building a
>>> mobile phone, you can choose the low power version you like. And this
>>> often turns into SDIO for WiFi and UART for Bluetooth.
>>
>> SDIO is such a pain. The hosts and devices have so many quirks as there
>> is no interoperability testing.
>
> What I have found is that the quirks are in the host controller for SDIO.
> Once that is working, the drivers have less quirks to handle

Yeah and SDIO is more common for WLAN than for BT indeed.
What we've seen (paging Ulf Hannson) is that SDIO has had a number
of quirks because of two things:

- Devices that are not cards require a non-power of two byte
  transfer, and often hardware quirks to even write say 1, 2 or
  3 bytes in the 32bit out FIFO registers.

- Power sequencing WRT the device on the outer side, which
  has been addressed in drivers/mmc/core/pwrseq.c

First is just basic driver features not uniformly implemented,
the second I think is addressed now, just tricksy to use.

Linus Walleij

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Krzysztof Kozlowski]

On 29.07.2015 07:09, Tim Bird wrote:
> On 07/23/2015 08:40 AM, Mark Brown wrote:
>> On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
>>
>>> Although is this something to be a core topic or a tech topic? Does
>>> this affect all subsystems, or just a set of drivers? Note, a core
>>> topic wont get as much time for discussion as a tech topic would.
>>
>> It's basically all subsystems that get impacted, at the minute I'd say
>> it's more a plan of action and process discussion than a technical one
>> though in the context of KS planning that's quite probably the same
>> thing.
>>
>>> Also, what is expected to be solved at KS?
>>
>> Tim Bird (Cced) has been running some sessions at other conferences
>> scoping the problem and discussing ways to move forward on this, another
>> similar session might be useful.
> 
> As Mark says, I've been working on almost exactly this topic for several
> months now.  Last year I conducted a survey investigating obstacles
> that developers (mostly corporate product developers) have in mainlining.
> There are lots of non-technical issues that are worth working on (version
> gap, corporate incentives, training, etc.), but which are outside
> the scope of the kernel summit.
> 
> There are also some technical areas where I think coordinated
> effort might be useful, to identify deficiencies and collaborate on
> progress.  These might be worth discussing at the summit.
> 
> In March of this year, I analysed code from several shipping phones
> (representing a number of different SoCs, including both ARM and
> Intel-architecture CPUs), and found that most products have between
> 1.2 and 3 million lines of code out-of-tree.  We are still in progress of
> finding patterns of out-of-treeness, to inform decisions about technical
> projects going forward.
> 
> There is now a wiki page at:
> See http://elinux.org/Kernel_areas_of_focus_for_mainlining
> In particular it has a table showing certain areas that tend to have
> a lot of out-of-tree code (e.g. most phones have between 80K to
> 100K of lines of wireless driver support out-of-mainline)

Did anyone see successful attempts of mainlining such vendor code? I
mean mainlining by individuals, not by vendor company itself.

It is a difficult task, especially without datasheets but it's possible.
At least for some drivers.

If there were such efforts, I would be curious what obstacles he/she
encountered (except a common one - missing datasheet/specs) and how he
can be helped?

Best regards,
Krzysztof

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Laurent Pinchart]

On Wednesday 29 July 2015 09:45:22 Krzysztof Kozlowski wrote:
> On 29.07.2015 07:09, Tim Bird wrote:
> > On 07/23/2015 08:40 AM, Mark Brown wrote:
> >> On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
> >>> Although is this something to be a core topic or a tech topic? Does
> >>> this affect all subsystems, or just a set of drivers? Note, a core
> >>> topic wont get as much time for discussion as a tech topic would.
> >> 
> >> It's basically all subsystems that get impacted, at the minute I'd say
> >> it's more a plan of action and process discussion than a technical one
> >> though in the context of KS planning that's quite probably the same
> >> thing.
> >> 
> >>> Also, what is expected to be solved at KS?
> >> 
> >> Tim Bird (Cced) has been running some sessions at other conferences
> >> scoping the problem and discussing ways to move forward on this, another
> >> similar session might be useful.
> > 
> > As Mark says, I've been working on almost exactly this topic for several
> > months now.  Last year I conducted a survey investigating obstacles
> > that developers (mostly corporate product developers) have in mainlining.
> > There are lots of non-technical issues that are worth working on (version
> > gap, corporate incentives, training, etc.), but which are outside
> > the scope of the kernel summit.
> > 
> > There are also some technical areas where I think coordinated
> > effort might be useful, to identify deficiencies and collaborate on
> > progress.  These might be worth discussing at the summit.
> > 
> > In March of this year, I analysed code from several shipping phones
> > (representing a number of different SoCs, including both ARM and
> > Intel-architecture CPUs), and found that most products have between
> > 1.2 and 3 million lines of code out-of-tree.  We are still in progress of
> > finding patterns of out-of-treeness, to inform decisions about technical
> > projects going forward.
> > 
> > There is now a wiki page at:
> > See http://elinux.org/Kernel_areas_of_focus_for_mainlining
> > In particular it has a table showing certain areas that tend to have
> > a lot of out-of-tree code (e.g. most phones have between 80K to
> > 100K of lines of wireless driver support out-of-mainline)
> 
> Did anyone see successful attempts of mainlining such vendor code? I
> mean mainlining by individuals, not by vendor company itself.
> 
> It is a difficult task, especially without datasheets but it's possible.
> At least for some drivers.
> 
> If there were such efforts, I would be curious what obstacles he/she
> encountered (except a common one - missing datasheet/specs) and how he
> can be helped?

Given the dubious (to remain polite) quality of most out-of-tree vendor code, 
mainlining such drivers requires kernel guru skills and that's a very scarce 
resource. One big issue in my opinion is that people who have the necessary 
skills just lack free time. We would need to find budget to make that happen.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

Hi!

> > There is now a wiki page at:
> > See http://elinux.org/Kernel_areas_of_focus_for_mainlining
> > In particular it has a table showing certain areas that tend to have
> > a lot of out-of-tree code (e.g. most phones have between 80K to
> > 100K of lines of wireless driver support out-of-mainline)
> 
> Did anyone see successful attempts of mainlining such vendor code? I
> mean mainlining by individuals, not by vendor company itself.

That is what is happening on Nokia N900. It took some time, but we
have almost usable phone at this point. We'll have usable one once
power management is working and once we get some more reasonable code
to control ofono.

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

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Tim Bird]

On 07/29/2015 12:40 AM, Pavel Machek wrote:
> Hi!
> 
>>> There is now a wiki page at:
>>> See http://elinux.org/Kernel_areas_of_focus_for_mainlining
>>> In particular it has a table showing certain areas that tend to have
>>> a lot of out-of-tree code (e.g. most phones have between 80K to
>>> 100K of lines of wireless driver support out-of-mainline)
>>
>> Did anyone see successful attempts of mainlining such vendor code? I
>> mean mainlining by individuals, not by vendor company itself.
> 
> That is what is happening on Nokia N900. It took some time, but we
> have almost usable phone at this point. We'll have usable one once
> power management is working and once we get some more reasonable code
> to control ofono.

Just an update on this thread.  We held a BOF at LinuxCon last week
on this topic.  I gave a presentation with some background, and
then we had a discussion.  Notes from the meeting (and a link to the
presentation) are at: 
http://elinux.org/LCNA_2015_Device_Mainlining_BOF_meeting_notes

We'll be doing more BOFs on this topic at Linaro Connect and ELC Europe.

I believe this would make a good discussion area for the kernel
summit.  The summit will likely include developers who have a
good idea of detailed technical problem areas that need attention in
order to make progress on this problem.

Thanks.
 -- Tim

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Krzysztof Kozlowski]

On 26.08.2015 03:59, Tim Bird wrote:
> On 07/29/2015 12:40 AM, Pavel Machek wrote:
>> Hi!
>>
>>>> There is now a wiki page at:
>>>> See http://elinux.org/Kernel_areas_of_focus_for_mainlining
>>>> In particular it has a table showing certain areas that tend to have
>>>> a lot of out-of-tree code (e.g. most phones have between 80K to
>>>> 100K of lines of wireless driver support out-of-mainline)
>>>
>>> Did anyone see successful attempts of mainlining such vendor code? I
>>> mean mainlining by individuals, not by vendor company itself.
>>
>> That is what is happening on Nokia N900. It took some time, but we
>> have almost usable phone at this point. We'll have usable one once
>> power management is working and once we get some more reasonable code
>> to control ofono.
> 
> Just an update on this thread.  We held a BOF at LinuxCon last week
> on this topic.  I gave a presentation with some background, and
> then we had a discussion.  Notes from the meeting (and a link to the
> presentation) are at: 
> http://elinux.org/LCNA_2015_Device_Mainlining_BOF_meeting_notes

Thanks for updated numbers. Interesting that for the same SoC vendor
(MSM) the difference between phone vendors is significant, e.g. 3.1M of
Samsung/MSM insertions, 2.6M of LG insertions and only 1.8M of Sony and
Motorola.

In the same time number of mainline contributors from LG, Sony and
Motorola is similar... so why LG and Samsung/MSM need more than 1M of
additional code out of tree?


I made also a diff with Tizen (developer) kernel source code. These are
kernel trees not used directly by end-market products, but for devices
released to developers. Sometimes these are the same as market-products,
but the kernel is developed in a more open-source way:

1. 4.0 kernel (for Odroid XU3):
   https://review.tizen.org/git/?p=platform/kernel/linux-exynos.git
   1404 files changed,
   4566 insertions(+),
   162026 deletions(-),
   1761 hunks

2. 3.10 kernel (for Gear2, Trats2/Galaxy S3, Odroid U3):
   https://review.tizen.org/git/?p=platform/kernel/linux-3.10.git
   5804 files changed,
   84175 insertions(+),
   536798 deletions(-),
   17917 hunks

I think the numbers are reversed (insertions <-> deletions) because
adding only Mali 400 should give ~50 000 of insertions.


Mali GPU drivers are an interesting case:
1. They are open (I believe Linux version is entirely under GPLv2).

2. They are developed for many OS-es.

3. They are present on may end-user products (using SoCs from Allwinner,
Mediatek, Rockchip, Samsung and more).

4. Their coding style is so different that I can't imagine mainlining
them into staging area... Recently I was digging into Mali400 and it was
literally hurting my eyes to see that coding style. It's like opposite
of kernel.


Best regards,
Krzysztof

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Sudip Mukherjee]

On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> On 26.08.2015 03:59, Tim Bird wrote:
> > On 07/29/2015 12:40 AM, Pavel Machek wrote:
<snip>
> 
> 4. Their coding style is so different that I can't imagine mainlining
> them into staging area... Recently I was digging into Mali400 and it was
> literally hurting my eyes to see that coding style. It's like opposite
> of kernel.
Hi,
I have seen Mali code once few months ago and true that the styling
there is exactly opposite of what we use. But anyway, I hope including
that in staging will be beneficial for all of you. And I can also guess
that it will be a waste of your time if you add it to staging and
refactor the code ultimately merging it to the main part of the kerel.

I am not an experienced Mali developer but if you all are ok with it then
I can take up the task of adding it to staging. But I will need to have
a board for that as without hardware Greg will not allow the code to be
added. And Krzysztof has suggested ODROID-U3 for this purpose.

Regards
Sudip

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Krzysztof Kozlowski]

On 26.08.2015 13:25, Sudip Mukherjee wrote:
> On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
>> On 26.08.2015 03:59, Tim Bird wrote:
>>> On 07/29/2015 12:40 AM, Pavel Machek wrote:
> <snip>
>>
>> 4. Their coding style is so different that I can't imagine mainlining
>> them into staging area... Recently I was digging into Mali400 and it was
>> literally hurting my eyes to see that coding style. It's like opposite
>> of kernel.
> Hi,
> I have seen Mali code once few months ago and true that the styling
> there is exactly opposite of what we use. But anyway, I hope including
> that in staging will be beneficial for all of you. 

Looking at the list of SoCs using Mali:
https://en.wikipedia.org/wiki/Mali_(GPU)
then clearly a lot of vendors could benefit from that. I would be happy
to see Mali in staging/mainline.

> And I can also guess
> that it will be a waste of your time if you add it to staging and
> refactor the code ultimately merging it to the main part of the kerel.
> 
> I am not an experienced Mali developer but if you all are ok with it then
> I can take up the task of adding it to staging. But I will need to have
> a board for that as without hardware Greg will not allow the code to be
> added. And Krzysztof has suggested ODROID-U3 for this purpose.

Right, I suggested Odroid-U3 (with Mali 400 and Exynos4412) because the
board works quite well with mainline. Most of stuff is upstreamed.
However I am using Tizen TV profile (public) on it with 4.0 kernel (not
entirely public).

There are a lot of more devices with Mali 400 or newer so the question
would be rather - which board would work the best (with less problems)
on mainline.

Anyway good luck :)

Best regards,
Krzysztof

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Laurent Pinchart]

On Wednesday 26 August 2015 13:52:23 Krzysztof Kozlowski wrote:
> On 26.08.2015 13:25, Sudip Mukherjee wrote:
> > On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> >> On 26.08.2015 03:59, Tim Bird wrote:
> >>> On 07/29/2015 12:40 AM, Pavel Machek wrote:
> > <snip>
> > 
> >> 4. Their coding style is so different that I can't imagine mainlining
> >> them into staging area... Recently I was digging into Mali400 and it was
> >> literally hurting my eyes to see that coding style. It's like opposite
> >> of kernel.
> > 
> > Hi,
> > I have seen Mali code once few months ago and true that the styling
> > there is exactly opposite of what we use. But anyway, I hope including
> > that in staging will be beneficial for all of you.
> 
> Looking at the list of SoCs using Mali:
> https://en.wikipedia.org/wiki/Mali_(GPU)
> then clearly a lot of vendors could benefit from that. I would be happy
> to see Mali in staging/mainline.
> 
> > And I can also guess
> > that it will be a waste of your time if you add it to staging and
> > refactor the code ultimately merging it to the main part of the kerel.
> > 
> > I am not an experienced Mali developer but if you all are ok with it then
> > I can take up the task of adding it to staging. But I will need to have
> > a board for that as without hardware Greg will not allow the code to be
> > added. And Krzysztof has suggested ODROID-U3 for this purpose.
> 
> Right, I suggested Odroid-U3 (with Mali 400 and Exynos4412) because the
> board works quite well with mainline. Most of stuff is upstreamed.
> However I am using Tizen TV profile (public) on it with 4.0 kernel (not
> entirely public).
> 
> There are a lot of more devices with Mali 400 or newer so the question
> would be rather - which board would work the best (with less problems)
> on mainline.
> 
> Anyway good luck :)

Given that DRM drivers can't be merged to mainline without an open-source 
userspace we're stuck until ARM decides to play fair (unlikely) or the Lima 
driver project rises back from the deaths.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Krzysztof Kozlowski]

On 26.08.2015 14:30, Laurent Pinchart wrote:
> On Wednesday 26 August 2015 13:52:23 Krzysztof Kozlowski wrote:
>> On 26.08.2015 13:25, Sudip Mukherjee wrote:
>>> On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
>>>> On 26.08.2015 03:59, Tim Bird wrote:
>>>>> On 07/29/2015 12:40 AM, Pavel Machek wrote:
>>> <snip>
>>>
>>>> 4. Their coding style is so different that I can't imagine mainlining
>>>> them into staging area... Recently I was digging into Mali400 and it was
>>>> literally hurting my eyes to see that coding style. It's like opposite
>>>> of kernel.
>>>
>>> Hi,
>>> I have seen Mali code once few months ago and true that the styling
>>> there is exactly opposite of what we use. But anyway, I hope including
>>> that in staging will be beneficial for all of you.
>>
>> Looking at the list of SoCs using Mali:
>> https://en.wikipedia.org/wiki/Mali_(GPU)
>> then clearly a lot of vendors could benefit from that. I would be happy
>> to see Mali in staging/mainline.
>>
>>> And I can also guess
>>> that it will be a waste of your time if you add it to staging and
>>> refactor the code ultimately merging it to the main part of the kerel.
>>>
>>> I am not an experienced Mali developer but if you all are ok with it then
>>> I can take up the task of adding it to staging. But I will need to have
>>> a board for that as without hardware Greg will not allow the code to be
>>> added. And Krzysztof has suggested ODROID-U3 for this purpose.
>>
>> Right, I suggested Odroid-U3 (with Mali 400 and Exynos4412) because the
>> board works quite well with mainline. Most of stuff is upstreamed.
>> However I am using Tizen TV profile (public) on it with 4.0 kernel (not
>> entirely public).
>>
>> There are a lot of more devices with Mali 400 or newer so the question
>> would be rather - which board would work the best (with less problems)
>> on mainline.
>>
>> Anyway good luck :)
> 
> Given that DRM drivers can't be merged to mainline without an open-source 
> userspace we're stuck until ARM decides to play fair (unlikely) or the Lima 
> driver project rises back from the deaths.

You mean that closed Mali DDK (the user-space interface) is major
obstacle for mainlining Mali kernel side? Why?

Best regards,
Krzysztof

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Josh Triplett]

On Wed, Aug 26, 2015 at 02:33:21PM +0900, Krzysztof Kozlowski wrote:
> On 26.08.2015 14:30, Laurent Pinchart wrote:
> > On Wednesday 26 August 2015 13:52:23 Krzysztof Kozlowski wrote:
> >> On 26.08.2015 13:25, Sudip Mukherjee wrote:
> >>> On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> >>>> On 26.08.2015 03:59, Tim Bird wrote:
> >>>>> On 07/29/2015 12:40 AM, Pavel Machek wrote:
> >>> <snip>
> >>>
> >>>> 4. Their coding style is so different that I can't imagine mainlining
> >>>> them into staging area... Recently I was digging into Mali400 and it was
> >>>> literally hurting my eyes to see that coding style. It's like opposite
> >>>> of kernel.
> >>>
> >>> Hi,
> >>> I have seen Mali code once few months ago and true that the styling
> >>> there is exactly opposite of what we use. But anyway, I hope including
> >>> that in staging will be beneficial for all of you.
> >>
> >> Looking at the list of SoCs using Mali:
> >> https://en.wikipedia.org/wiki/Mali_(GPU)
> >> then clearly a lot of vendors could benefit from that. I would be happy
> >> to see Mali in staging/mainline.
> >>
> >>> And I can also guess
> >>> that it will be a waste of your time if you add it to staging and
> >>> refactor the code ultimately merging it to the main part of the kerel.
> >>>
> >>> I am not an experienced Mali developer but if you all are ok with it then
> >>> I can take up the task of adding it to staging. But I will need to have
> >>> a board for that as without hardware Greg will not allow the code to be
> >>> added. And Krzysztof has suggested ODROID-U3 for this purpose.
> >>
> >> Right, I suggested Odroid-U3 (with Mali 400 and Exynos4412) because the
> >> board works quite well with mainline. Most of stuff is upstreamed.
> >> However I am using Tizen TV profile (public) on it with 4.0 kernel (not
> >> entirely public).
> >>
> >> There are a lot of more devices with Mali 400 or newer so the question
> >> would be rather - which board would work the best (with less problems)
> >> on mainline.
> >>
> >> Anyway good luck :)
> > 
> > Given that DRM drivers can't be merged to mainline without an open-source 
> > userspace we're stuck until ARM decides to play fair (unlikely) or the Lima 
> > driver project rises back from the deaths.
> 
> You mean that closed Mali DDK (the user-space interface) is major
> obstacle for mainlining Mali kernel side? Why?

Exactly as stated: in general, and particularly for graphics, a kernel
interface needs some Open Source userspace showing that it actually
works.  The graphics maintainers do not merge kernel drivers for which
only a proprietary userspace exists, for a variety of reasons, not least
of which an inability to test them, check for regressions, or otherwise
maintain them.

I haven't heard anything about Lima being defunct, though; as far as I
know, it's as functional as it ever was on the hardware it supports.
It's unlikely to ever be officially supported, but that hardly seems
like a requirement.  If you're running on a Mali 400, Lima should work.

- Josh Triplett

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Heiko Stuebner]

Am Dienstag, 25. August 2015, 23:15:14 schrieb Josh Triplett:
> On Wed, Aug 26, 2015 at 02:33:21PM +0900, Krzysztof Kozlowski wrote:
> > On 26.08.2015 14:30, Laurent Pinchart wrote:
> > > On Wednesday 26 August 2015 13:52:23 Krzysztof Kozlowski wrote:
> > >> On 26.08.2015 13:25, Sudip Mukherjee wrote:
> > >>> On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> > >>>> On 26.08.2015 03:59, Tim Bird wrote:
> > >>>>> On 07/29/2015 12:40 AM, Pavel Machek wrote:
> > >>> <snip>
> > >>> 
> > >>>> 4. Their coding style is so different that I can't imagine mainlining
> > >>>> them into staging area... Recently I was digging into Mali400 and it
> > >>>> was
> > >>>> literally hurting my eyes to see that coding style. It's like
> > >>>> opposite
> > >>>> of kernel.
> > >>> 
> > >>> Hi,
> > >>> I have seen Mali code once few months ago and true that the styling
> > >>> there is exactly opposite of what we use. But anyway, I hope including
> > >>> that in staging will be beneficial for all of you.
> > >> 
> > >> Looking at the list of SoCs using Mali:
> > >> https://en.wikipedia.org/wiki/Mali_(GPU)
> > >> then clearly a lot of vendors could benefit from that. I would be happy
> > >> to see Mali in staging/mainline.
> > >> 
> > >>> And I can also guess
> > >>> that it will be a waste of your time if you add it to staging and
> > >>> refactor the code ultimately merging it to the main part of the kerel.
> > >>> 
> > >>> I am not an experienced Mali developer but if you all are ok with it
> > >>> then
> > >>> I can take up the task of adding it to staging. But I will need to
> > >>> have
> > >>> a board for that as without hardware Greg will not allow the code to
> > >>> be
> > >>> added. And Krzysztof has suggested ODROID-U3 for this purpose.
> > >> 
> > >> Right, I suggested Odroid-U3 (with Mali 400 and Exynos4412) because the
> > >> board works quite well with mainline. Most of stuff is upstreamed.
> > >> However I am using Tizen TV profile (public) on it with 4.0 kernel (not
> > >> entirely public).
> > >> 
> > >> There are a lot of more devices with Mali 400 or newer so the question
> > >> would be rather - which board would work the best (with less problems)
> > >> on mainline.
> > >> 
> > >> Anyway good luck :)
> > > 
> > > Given that DRM drivers can't be merged to mainline without an
> > > open-source
> > > userspace we're stuck until ARM decides to play fair (unlikely) or the
> > > Lima
> > > driver project rises back from the deaths.
> > 
> > You mean that closed Mali DDK (the user-space interface) is major
> > obstacle for mainlining Mali kernel side? Why?
> 
> Exactly as stated: in general, and particularly for graphics, a kernel
> interface needs some Open Source userspace showing that it actually
> works.  The graphics maintainers do not merge kernel drivers for which
> only a proprietary userspace exists, for a variety of reasons, not least
> of which an inability to test them, check for regressions, or otherwise
> maintain them.

An additional point would be the possible (in-)stability of the userspace 
interface. While I could sucessfully use a r6 midgard kernel driver with a r5 
userspace lib yesterday on my Rockchip Chromebook using Debian, I don't think 
that is guaranteed to work everytime or that special care is taken for the 
kernel driver to prevent needing upgrades in lockstep.

And that is not even taking into account, that the mali userspace libs seem to 
be implementator-specific somehow too. For example for Rockchip I currently get 
my libs from the ChromeOS tree [0] which can talk to X11 [although not plasma5 
it seems] and ARM seems to provide a variant for the firefly board using the 
legacy fbdev interface of the 3.10-based Android kernel. And then there are 
different variants for Samsung, etc too.


> I haven't heard anything about Lima being defunct, though; as far as I
> know, it's as functional as it ever was on the hardware it supports.
> It's unlikely to ever be officially supported, but that hardly seems
> like a requirement.  If you're running on a Mali 400, Lima should work.

probably not entirely defunct, but still on life-support:

For one, if you click on the "Source"-link on limadriver.org you get the 
gitorious "we're migrating old projects to archive.org" page.

And secondly there is supposed to be an actual mesa driver for mali400 and 
even bits for the midgard gpus (Mali-T) around, but limited to Luc's harddrive 
for now [1].


[0] https://github.com/mmind/mali-driver
[1] http://libv.livejournal.com/27461.html

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Krzysztof Kozlowski]

On 26.08.2015 16:23, Heiko Stuebner wrote:
> Am Dienstag, 25. August 2015, 23:15:14 schrieb Josh Triplett:
>> On Wed, Aug 26, 2015 at 02:33:21PM +0900, Krzysztof Kozlowski wrote:
>>> On 26.08.2015 14:30, Laurent Pinchart wrote:
>>>> On Wednesday 26 August 2015 13:52:23 Krzysztof Kozlowski wrote:
>>>>> On 26.08.2015 13:25, Sudip Mukherjee wrote:
>>>>>> On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
>>>>>>> On 26.08.2015 03:59, Tim Bird wrote:
>>>>>>>> On 07/29/2015 12:40 AM, Pavel Machek wrote:
>>>>>> <snip>
>>>>>>
>>>>>>> 4. Their coding style is so different that I can't imagine mainlining
>>>>>>> them into staging area... Recently I was digging into Mali400 and it
>>>>>>> was
>>>>>>> literally hurting my eyes to see that coding style. It's like
>>>>>>> opposite
>>>>>>> of kernel.
>>>>>>
>>>>>> Hi,
>>>>>> I have seen Mali code once few months ago and true that the styling
>>>>>> there is exactly opposite of what we use. But anyway, I hope including
>>>>>> that in staging will be beneficial for all of you.
>>>>>
>>>>> Looking at the list of SoCs using Mali:
>>>>> https://en.wikipedia.org/wiki/Mali_(GPU)
>>>>> then clearly a lot of vendors could benefit from that. I would be happy
>>>>> to see Mali in staging/mainline.
>>>>>
>>>>>> And I can also guess
>>>>>> that it will be a waste of your time if you add it to staging and
>>>>>> refactor the code ultimately merging it to the main part of the kerel.
>>>>>>
>>>>>> I am not an experienced Mali developer but if you all are ok with it
>>>>>> then
>>>>>> I can take up the task of adding it to staging. But I will need to
>>>>>> have
>>>>>> a board for that as without hardware Greg will not allow the code to
>>>>>> be
>>>>>> added. And Krzysztof has suggested ODROID-U3 for this purpose.
>>>>>
>>>>> Right, I suggested Odroid-U3 (with Mali 400 and Exynos4412) because the
>>>>> board works quite well with mainline. Most of stuff is upstreamed.
>>>>> However I am using Tizen TV profile (public) on it with 4.0 kernel (not
>>>>> entirely public).
>>>>>
>>>>> There are a lot of more devices with Mali 400 or newer so the question
>>>>> would be rather - which board would work the best (with less problems)
>>>>> on mainline.
>>>>>
>>>>> Anyway good luck :)
>>>>
>>>> Given that DRM drivers can't be merged to mainline without an
>>>> open-source
>>>> userspace we're stuck until ARM decides to play fair (unlikely) or the
>>>> Lima
>>>> driver project rises back from the deaths.
>>>
>>> You mean that closed Mali DDK (the user-space interface) is major
>>> obstacle for mainlining Mali kernel side? Why?
>>
>> Exactly as stated: in general, and particularly for graphics, a kernel
>> interface needs some Open Source userspace showing that it actually
>> works.  The graphics maintainers do not merge kernel drivers for which
>> only a proprietary userspace exists, for a variety of reasons, not least
>> of which an inability to test them, check for regressions, or otherwise
>> maintain them.
> 
> An additional point would be the possible (in-)stability of the userspace 
> interface. While I could sucessfully use a r6 midgard kernel driver with a r5 
> userspace lib yesterday on my Rockchip Chromebook using Debian, I don't think 
> that is guaranteed to work everytime or that special care is taken for the 
> kernel driver to prevent needing upgrades in lockstep.

One could imagine also a situation where the closed user-space library
would not change API because it would care also about compatibility with
mainline driver, not only about ARM open driver. But that actually looks
like a job for ARM.

I see now also another reason for not accepting Mali mainline - putting
pressure on the ARM to open the DDK.

> 
> And that is not even taking into account, that the mali userspace libs seem to 
> be implementator-specific somehow too. For example for Rockchip I currently get 
> my libs from the ChromeOS tree [0] which can talk to X11 [although not plasma5 
> it seems] and ARM seems to provide a variant for the firefly board using the 
> legacy fbdev interface of the 3.10-based Android kernel. And then there are 
> different variants for Samsung, etc too.

Yes, indeed. They are customer-oriented, where SoC vendor is the customer.
This also means that the customer has an ability to influence on ARM
decisions...

Anyway thanks Josh and Heiko for explaining.

Best regards,
Krzysztof

>> I haven't heard anything about Lima being defunct, though; as far as I
>> know, it's as functional as it ever was on the hardware it supports.
>> It's unlikely to ever be officially supported, but that hardly seems
>> like a requirement.  If you're running on a Mali 400, Lima should work.
> 
> probably not entirely defunct, but still on life-support:
> 
> For one, if you click on the "Source"-link on limadriver.org you get the 
> gitorious "we're migrating old projects to archive.org" page.
> 
> And secondly there is supposed to be an actual mesa driver for mali400 and 
> even bits for the midgard gpus (Mali-T) around, but limited to Luc's harddrive 
> for now [1].
> 
> 
> [0] https://github.com/mmind/mali-driver
> [1] http://libv.livejournal.com/27461.html
> 
> 

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Nicolas Ferre]

Le 26/08/2015 10:05, Krzysztof Kozlowski a écrit :
> On 26.08.2015 16:23, Heiko Stuebner wrote:
>> Am Dienstag, 25. August 2015, 23:15:14 schrieb Josh Triplett:
>>> On Wed, Aug 26, 2015 at 02:33:21PM +0900, Krzysztof Kozlowski wrote:
>>>> On 26.08.2015 14:30, Laurent Pinchart wrote:
>>>>> On Wednesday 26 August 2015 13:52:23 Krzysztof Kozlowski wrote:
>>>>>> On 26.08.2015 13:25, Sudip Mukherjee wrote:
>>>>>>> On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
>>>>>>>> On 26.08.2015 03:59, Tim Bird wrote:
>>>>>>>>> On 07/29/2015 12:40 AM, Pavel Machek wrote:
>>>>>>> <snip>
>>>>>>>
>>>>>>>> 4. Their coding style is so different that I can't imagine mainlining
>>>>>>>> them into staging area... Recently I was digging into Mali400 and it
>>>>>>>> was
>>>>>>>> literally hurting my eyes to see that coding style. It's like
>>>>>>>> opposite
>>>>>>>> of kernel.
>>>>>>>
>>>>>>> Hi,
>>>>>>> I have seen Mali code once few months ago and true that the styling
>>>>>>> there is exactly opposite of what we use. But anyway, I hope including
>>>>>>> that in staging will be beneficial for all of you.
>>>>>>
>>>>>> Looking at the list of SoCs using Mali:
>>>>>> https://en.wikipedia.org/wiki/Mali_(GPU)
>>>>>> then clearly a lot of vendors could benefit from that. I would be happy
>>>>>> to see Mali in staging/mainline.
>>>>>>
>>>>>>> And I can also guess
>>>>>>> that it will be a waste of your time if you add it to staging and
>>>>>>> refactor the code ultimately merging it to the main part of the kerel.
>>>>>>>
>>>>>>> I am not an experienced Mali developer but if you all are ok with it
>>>>>>> then
>>>>>>> I can take up the task of adding it to staging. But I will need to
>>>>>>> have
>>>>>>> a board for that as without hardware Greg will not allow the code to
>>>>>>> be
>>>>>>> added. And Krzysztof has suggested ODROID-U3 for this purpose.
>>>>>>
>>>>>> Right, I suggested Odroid-U3 (with Mali 400 and Exynos4412) because the
>>>>>> board works quite well with mainline. Most of stuff is upstreamed.
>>>>>> However I am using Tizen TV profile (public) on it with 4.0 kernel (not
>>>>>> entirely public).
>>>>>>
>>>>>> There are a lot of more devices with Mali 400 or newer so the question
>>>>>> would be rather - which board would work the best (with less problems)
>>>>>> on mainline.
>>>>>>
>>>>>> Anyway good luck :)
>>>>>
>>>>> Given that DRM drivers can't be merged to mainline without an
>>>>> open-source
>>>>> userspace we're stuck until ARM decides to play fair (unlikely) or the
>>>>> Lima
>>>>> driver project rises back from the deaths.
>>>>
>>>> You mean that closed Mali DDK (the user-space interface) is major
>>>> obstacle for mainlining Mali kernel side? Why?
>>>
>>> Exactly as stated: in general, and particularly for graphics, a kernel
>>> interface needs some Open Source userspace showing that it actually
>>> works.  The graphics maintainers do not merge kernel drivers for which
>>> only a proprietary userspace exists, for a variety of reasons, not least
>>> of which an inability to test them, check for regressions, or otherwise
>>> maintain them.
>>
>> An additional point would be the possible (in-)stability of the userspace 
>> interface. While I could sucessfully use a r6 midgard kernel driver with a r5 
>> userspace lib yesterday on my Rockchip Chromebook using Debian, I don't think 
>> that is guaranteed to work everytime or that special care is taken for the 
>> kernel driver to prevent needing upgrades in lockstep.
> 
> One could imagine also a situation where the closed user-space library
> would not change API because it would care also about compatibility with
> mainline driver, not only about ARM open driver. But that actually looks
> like a job for ARM.
> 
> I see now also another reason for not accepting Mali mainline - putting
> pressure on the ARM to open the DDK.

I doubt that the moderated but constant pressure that ARM has gotten
from the community these latest years would produce any modification of
their model. It didn't happen in the past, if the same approach is
taken, I have the feeling that nothing will change...

Don't forget that MALI 400 is very old and outdated, so if any effort to
open its software suite had happened, it would have been done already.

>> And that is not even taking into account, that the mali userspace libs seem to 
>> be implementator-specific somehow too. For example for Rockchip I currently get 
>> my libs from the ChromeOS tree [0] which can talk to X11 [although not plasma5 
>> it seems] and ARM seems to provide a variant for the firefly board using the 
>> legacy fbdev interface of the 3.10-based Android kernel. And then there are 
>> different variants for Samsung, etc too.
> 
> Yes, indeed. They are customer-oriented, where SoC vendor is the customer.
> This also means that the customer has an ability to influence on ARM
> decisions...

Well... tried hard and failed :-(

Don't overestimate the ability of (some) SoC vendors to influence this
division of ARM.

Bye,

> Anyway thanks Josh and Heiko for explaining.
> 
> Best regards,
> Krzysztof
> 
>>> I haven't heard anything about Lima being defunct, though; as far as I
>>> know, it's as functional as it ever was on the hardware it supports.
>>> It's unlikely to ever be officially supported, but that hardly seems
>>> like a requirement.  If you're running on a Mali 400, Lima should work.
>>
>> probably not entirely defunct, but still on life-support:
>>
>> For one, if you click on the "Source"-link on limadriver.org you get the 
>> gitorious "we're migrating old projects to archive.org" page.
>>
>> And secondly there is supposed to be an actual mesa driver for mali400 and 
>> even bits for the midgard gpus (Mali-T) around, but limited to Luc's harddrive 
>> for now [1].
>>
>>
>> [0] https://github.com/mmind/mali-driver
>> [1] http://libv.livejournal.com/27461.html

-- 
Nicolas Ferre
(I only speak for myself)

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown]

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

On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:

> Thanks for updated numbers. Interesting that for the same SoC vendor
> (MSM) the difference between phone vendors is significant, e.g. 3.1M of
> Samsung/MSM insertions, 2.6M of LG insertions and only 1.8M of Sony and
> Motorola.

> In the same time number of mainline contributors from LG, Sony and
> Motorola is similar... so why LG and Samsung/MSM need more than 1M of
> additional code out of tree?

One thing that happens here is that there's a wide variation in how much
the hardware gets customized from the reference designs provided by the
SoC vendors which has knock on effect on the amount of additional work
that is needed in order to support a given board.  I know the Korean
manufacturers do tend to make quite a few modifications to their designs
so I'd not be surprised if that were contributing to the number of code
changes required.

> Mali GPU drivers are an interesting case:
> 1. They are open (I believe Linux version is entirely under GPLv2).

Well, there's the in kernel stubs and the actual driver...

> 2. They are developed for many OS-es.

> 3. They are present on may end-user products (using SoCs from Allwinner,
> Mediatek, Rockchip, Samsung and more).

> 4. Their coding style is so different that I can't imagine mainlining
> them into staging area... Recently I was digging into Mali400 and it was
> literally hurting my eyes to see that coding style. It's like opposite
> of kernel.

The other thing here is that they don't (AIUI) offer a stable ABI, the
ABI can change between IP revisions.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Jason Cooper]

On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> Mali GPU drivers are an interesting case:
...
> 4. Their coding style is so different that I can't imagine mainlining
> them into staging area... Recently I was digging into Mali400 and it was
> literally hurting my eyes to see that coding style. It's like opposite
> of kernel.

iirc, gregkh's requirement for staging/ is that it compile.  Nothing
more.  If you're interested, I wrote a script a while back to automate
confirming that massive code cleanup (such as changing coding style)
doesn't change the resulting object code.  It's scripts/objdiff, I used
it for the initial import of skein and threefish crypto algorithms into
staging.

hth,

Jason.

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Geert Uytterhoeven]

Hi Jason,

On Wed, Aug 26, 2015 at 2:56 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> iirc, gregkh's requirement for staging/ is that it compile.  Nothing
> more.  If you're interested, I wrote a script a while back to automate
> confirming that massive code cleanup (such as changing coding style)
> doesn't change the resulting object code.  It's scripts/objdiff, I used
> it for the initial import of skein and threefish crypto algorithms into
> staging.

Cool, I didn't know about this tool.
Now I can stop doing this manually...

Thanks!

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] [CORE TOPIC] Mainline kernel on a cellphone

[Sudip Mukherjee]

On Wed, Aug 26, 2015 at 12:56:30PM +0000, Jason Cooper wrote:
> On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> > Mali GPU drivers are an interesting case:
> ...
> > 4. Their coding style is so different that I can't imagine mainlining
> > them into staging area... Recently I was digging into Mali400 and it was
> > literally hurting my eyes to see that coding style. It's like opposite
> > of kernel.
> 
> iirc, gregkh's requirement for staging/ is that it compile.  Nothing
> more.

Yes. But Greg will also say that we should be modifying the code with
the ultimate goal of moving it out of staging into the main part of the
kernel. And if all of us know that it can not be merged into the main part
because of closed userspace then will Greg accept it?

regards
sudip

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Jason Cooper]

Hi Sudip,

On Wed, Aug 26, 2015 at 07:28:35PM +0530, Sudip Mukherjee wrote:
> On Wed, Aug 26, 2015 at 12:56:30PM +0000, Jason Cooper wrote:
> > On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> > > Mali GPU drivers are an interesting case:
> > ...
> > > 4. Their coding style is so different that I can't imagine mainlining
> > > them into staging area... Recently I was digging into Mali400 and it was
> > > literally hurting my eyes to see that coding style. It's like opposite
> > > of kernel.
> > 
> > iirc, gregkh's requirement for staging/ is that it compile.  Nothing
> > more.
> 
> Yes. But Greg will also say that we should be modifying the code with
> the ultimate goal of moving it out of staging into the main part of the
> kernel. And if all of us know that it can not be merged into the main part
> because of closed userspace then will Greg accept it?

Well, this seems to me to be a case of chicken-and-the-egg, which came
first?  fwiw, I think there's benefit in putting the driver in staging/
to see if it ignites development efforts on the userspace side.  If it
doesn't, I know Greg isn't shy about removing drivers from staging.  ;-)

thx,

Jason.

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Sudip Mukherjee]

On Wed, Aug 26, 2015 at 02:51:29PM +0000, Jason Cooper wrote:
> Hi Sudip,
> 
> On Wed, Aug 26, 2015 at 07:28:35PM +0530, Sudip Mukherjee wrote:
> > On Wed, Aug 26, 2015 at 12:56:30PM +0000, Jason Cooper wrote:
> > > On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> > > > Mali GPU drivers are an interesting case:
> > > ...
> > > > 4. Their coding style is so different that I can't imagine mainlining
> > > > them into staging area... Recently I was digging into Mali400 and it was
> > > > literally hurting my eyes to see that coding style. It's like opposite
> > > > of kernel.
> > > 
> > > iirc, gregkh's requirement for staging/ is that it compile.  Nothing
> > > more.
> > 
> > Yes. But Greg will also say that we should be modifying the code with
> > the ultimate goal of moving it out of staging into the main part of the
> > kernel. And if all of us know that it can not be merged into the main part
> > because of closed userspace then will Greg accept it?
> 
> Well, this seems to me to be a case of chicken-and-the-egg, which came
> first?  fwiw, I think there's benefit in putting the driver in staging/
> to see if it ignites development efforts on the userspace side.  If it
> doesn't, I know Greg isn't shy about removing drivers from staging.  ;-)
Adding Greg in the To: list for his comments.

Hi Greg,
Incase you have not seen the previous mails in the thread, we were
discussing if mali driver code can be added to staging. Many benefits,
but the problem is that the userspace is closed and unless we have an
open userspace this cannot be merged with the main part of the kernel.

regards
sudip

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Greg Kroah-Hartman]

On Wed, Aug 26, 2015 at 10:43:31PM +0530, Sudip Mukherjee wrote:
> On Wed, Aug 26, 2015 at 02:51:29PM +0000, Jason Cooper wrote:
> > Hi Sudip,
> > 
> > On Wed, Aug 26, 2015 at 07:28:35PM +0530, Sudip Mukherjee wrote:
> > > On Wed, Aug 26, 2015 at 12:56:30PM +0000, Jason Cooper wrote:
> > > > On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> > > > > Mali GPU drivers are an interesting case:
> > > > ...
> > > > > 4. Their coding style is so different that I can't imagine mainlining
> > > > > them into staging area... Recently I was digging into Mali400 and it was
> > > > > literally hurting my eyes to see that coding style. It's like opposite
> > > > > of kernel.
> > > > 
> > > > iirc, gregkh's requirement for staging/ is that it compile.  Nothing
> > > > more.
> > > 
> > > Yes. But Greg will also say that we should be modifying the code with
> > > the ultimate goal of moving it out of staging into the main part of the
> > > kernel. And if all of us know that it can not be merged into the main part
> > > because of closed userspace then will Greg accept it?
> > 
> > Well, this seems to me to be a case of chicken-and-the-egg, which came
> > first?  fwiw, I think there's benefit in putting the driver in staging/
> > to see if it ignites development efforts on the userspace side.  If it
> > doesn't, I know Greg isn't shy about removing drivers from staging.  ;-)
> Adding Greg in the To: list for his comments.
> 
> Hi Greg,
> Incase you have not seen the previous mails in the thread, we were
> discussing if mali driver code can be added to staging. Many benefits,
> but the problem is that the userspace is closed and unless we have an
> open userspace this cannot be merged with the main part of the kernel.

staging is not for dumping crap that the owners don't want to do the
work to get it merged "properly".  So I will not take DRM drivers in
staging that violate the existing DRM rules of requiring an open
userspace as that would mean I would be adding code that can never be
merged out of the staging tree.

sorry, go kick the Mali authors to do this correctly.  They know what
they have to do, their management just doesn't want to let them do it.

good luck,

greg k-h

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

Hi!
On Wed 2015-08-26 15:09:11, Greg Kroah-Hartman wrote:
> On Wed, Aug 26, 2015 at 10:43:31PM +0530, Sudip Mukherjee wrote:
> > On Wed, Aug 26, 2015 at 02:51:29PM +0000, Jason Cooper wrote:
> > > Hi Sudip,
> > > 
> > > On Wed, Aug 26, 2015 at 07:28:35PM +0530, Sudip Mukherjee wrote:
> > > > On Wed, Aug 26, 2015 at 12:56:30PM +0000, Jason Cooper wrote:
> > > > > On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski wrote:
> > > > > > Mali GPU drivers are an interesting case:
> > > > > ...
> > > > > > 4. Their coding style is so different that I can't imagine mainlining
> > > > > > them into staging area... Recently I was digging into Mali400 and it was
> > > > > > literally hurting my eyes to see that coding style. It's like opposite
> > > > > > of kernel.
> > > > > 
> > > > > iirc, gregkh's requirement for staging/ is that it compile.  Nothing
> > > > > more.
> > > > 
> > > > Yes. But Greg will also say that we should be modifying the code with
> > > > the ultimate goal of moving it out of staging into the main part of the
> > > > kernel. And if all of us know that it can not be merged into the main part
> > > > because of closed userspace then will Greg accept it?
> > > 
> > > Well, this seems to me to be a case of chicken-and-the-egg, which came
> > > first?  fwiw, I think there's benefit in putting the driver in staging/
> > > to see if it ignites development efforts on the userspace side.  If it
> > > doesn't, I know Greg isn't shy about removing drivers from staging.  ;-)
> > Adding Greg in the To: list for his comments.
> > 
> > Hi Greg,
> > Incase you have not seen the previous mails in the thread, we were
> > discussing if mali driver code can be added to staging. Many benefits,
> > but the problem is that the userspace is closed and unless we have an
> > open userspace this cannot be merged with the main part of the kernel.
> 
> staging is not for dumping crap that the owners don't want to do the
> work to get it merged "properly".  So I will not take DRM drivers in
> staging that violate the existing DRM rules of requiring an open
> userspace as that would mean I would be adding code that can never be
> merged out of the staging tree.
> 
> sorry, go kick the Mali authors to do this correctly.  They know what
> they have to do, their management just doesn't want to let them do
it.

Well, you still can get it working with http://limadriver.org/ , then
merge it to staging/ , then clean the horrible coding style in tree...

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] [CORE TOPIC] Mainline kernel on a cellphone

[Heiko Stuebner]

Am Freitag, 28. August 2015, 09:44:39 schrieb Pavel Machek:
> Hi!
> 
> On Wed 2015-08-26 15:09:11, Greg Kroah-Hartman wrote:
> > On Wed, Aug 26, 2015 at 10:43:31PM +0530, Sudip Mukherjee wrote:
> > > On Wed, Aug 26, 2015 at 02:51:29PM +0000, Jason Cooper wrote:
> > > > Hi Sudip,
> > > > 
> > > > On Wed, Aug 26, 2015 at 07:28:35PM +0530, Sudip Mukherjee wrote:
> > > > > On Wed, Aug 26, 2015 at 12:56:30PM +0000, Jason Cooper wrote:
> > > > > > On Wed, Aug 26, 2015 at 10:22:11AM +0900, Krzysztof Kozlowski 
wrote:
> > > > > > > Mali GPU drivers are an interesting case:
> > > > > > ...
> > > > > > 
> > > > > > > 4. Their coding style is so different that I can't imagine
> > > > > > > mainlining
> > > > > > > them into staging area... Recently I was digging into Mali400
> > > > > > > and it was
> > > > > > > literally hurting my eyes to see that coding style. It's like
> > > > > > > opposite
> > > > > > > of kernel.
> > > > > > 
> > > > > > iirc, gregkh's requirement for staging/ is that it compile. 
> > > > > > Nothing
> > > > > > more.
> > > > > 
> > > > > Yes. But Greg will also say that we should be modifying the code
> > > > > with
> > > > > the ultimate goal of moving it out of staging into the main part of
> > > > > the
> > > > > kernel. And if all of us know that it can not be merged into the
> > > > > main part
> > > > > because of closed userspace then will Greg accept it?
> > > > 
> > > > Well, this seems to me to be a case of chicken-and-the-egg, which came
> > > > first?  fwiw, I think there's benefit in putting the driver in
> > > > staging/
> > > > to see if it ignites development efforts on the userspace side.  If it
> > > > doesn't, I know Greg isn't shy about removing drivers from staging. 
> > > > ;-)
> > > 
> > > Adding Greg in the To: list for his comments.
> > > 
> > > Hi Greg,
> > > Incase you have not seen the previous mails in the thread, we were
> > > discussing if mali driver code can be added to staging. Many benefits,
> > > but the problem is that the userspace is closed and unless we have an
> > > open userspace this cannot be merged with the main part of the kernel.
> > 
> > staging is not for dumping crap that the owners don't want to do the
> > work to get it merged "properly".  So I will not take DRM drivers in
> > staging that violate the existing DRM rules of requiring an open
> > userspace as that would mean I would be adding code that can never be
> > merged out of the staging tree.
> > 
> > sorry, go kick the Mali authors to do this correctly.  They know what
> > they have to do, their management just doesn't want to let them do
> 
> it.
> 
> Well, you still can get it working with http://limadriver.org/ ,

except the old public code has vanished with the gitorious shutdown (somebody 
having a copy should maybe upload it to github or somewhere, so it doesn't get 
lost completely?) and of course the rumored already existing mesa driver is 
still in hiding.


> then
> merge it to staging/ , then clean the horrible coding style in tree...
> 
> Best regards,
> 									Pavel

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Sudip Mukherjee]

On Fri, Aug 28, 2015 at 10:42:01AM +0200, Heiko Stuebner wrote:
> Am Freitag, 28. August 2015, 09:44:39 schrieb Pavel Machek:
> > 
> > Well, you still can get it working with http://limadriver.org/ ,
> 
> except the old public code has vanished with the gitorious shutdown (somebody 
> having a copy should maybe upload it to github or somewhere, so it doesn't get 
> lost completely?) and of course the rumored already existing mesa driver is 
> still in hiding.
I managed to find a clone and have put that up in github. Can anyone
please check if the copy at https://github.com/sudipm-mukherjee/lima.git
is a valid and the latest one...

regards
sudip

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Heiko Stübner]

Am Mittwoch, 29. Juli 2015, 09:45:22 schrieb Krzysztof Kozlowski:
> On 29.07.2015 07:09, Tim Bird wrote:
> > On 07/23/2015 08:40 AM, Mark Brown wrote:
> >> On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
> >>> Although is this something to be a core topic or a tech topic? Does
> >>> this affect all subsystems, or just a set of drivers? Note, a core
> >>> topic wont get as much time for discussion as a tech topic would.
> >> 
> >> It's basically all subsystems that get impacted, at the minute I'd say
> >> it's more a plan of action and process discussion than a technical one
> >> though in the context of KS planning that's quite probably the same
> >> thing.
> >> 
> >>> Also, what is expected to be solved at KS?
> >> 
> >> Tim Bird (Cced) has been running some sessions at other conferences
> >> scoping the problem and discussing ways to move forward on this, another
> >> similar session might be useful.
> > 
> > As Mark says, I've been working on almost exactly this topic for several
> > months now.  Last year I conducted a survey investigating obstacles
> > that developers (mostly corporate product developers) have in mainlining.
> > There are lots of non-technical issues that are worth working on (version
> > gap, corporate incentives, training, etc.), but which are outside
> > the scope of the kernel summit.
> > 
> > There are also some technical areas where I think coordinated
> > effort might be useful, to identify deficiencies and collaborate on
> > progress.  These might be worth discussing at the summit.
> > 
> > In March of this year, I analysed code from several shipping phones
> > (representing a number of different SoCs, including both ARM and
> > Intel-architecture CPUs), and found that most products have between
> > 1.2 and 3 million lines of code out-of-tree.  We are still in progress of
> > finding patterns of out-of-treeness, to inform decisions about technical
> > projects going forward.
> > 
> > There is now a wiki page at:
> > See http://elinux.org/Kernel_areas_of_focus_for_mainlining
> > In particular it has a table showing certain areas that tend to have
> > a lot of out-of-tree code (e.g. most phones have between 80K to
> > 100K of lines of wireless driver support out-of-mainline)
> 
> Did anyone see successful attempts of mainlining such vendor code? I
> mean mainlining by individuals, not by vendor company itself.

I started the Rockchip ARM support in this manner ;-) . My main job is hacking 
on the mentioned vendor kernels, Finding the quirks after everybody put their 
out-of-tree stuff into it, so doing mainline is for me always a means of 
balance in terms of clean code, having a nice process to follow and a lot of 
great people to learn from. So I'm doing mainline as a means to learn and 
grow.


> It is a difficult task, especially without datasheets but it's possible.
> At least for some drivers.
> 
> If there were such efforts, I would be curious what obstacles he/she
> encountered (except a common one - missing datasheet/specs) and how he
> can be helped?

The dubious code quality Laurent already mentioned in another mail - aka you 
normally cannot upstream vendor-drivers directly.

For example in the vendor kernel, the clock tree was 150K of C code per soc 
and hard to read at all. So in a first step I did "reverse-engineer" the code 
from the GPL'ed source release and built a register map out of it [0].

So getting the clock tree right to what it is today was one of the biggest 
obstacles. Another was pinctrl, which in retrospect is sub-optimal.


So I guess the big issues are the big core systems which you essentially _need 
to get right_ from the start, as everything else builds on it. And with dt-
bindings you get issues if stuff needs to be redone later.


On the other hand, Rockchip SoCs have the benefit of seeming to use a lot of 
external IPs (dw-uart, dw-mmc, dw-hdmi, etc), so a lot of the later drivers 
get comparatively easy.



[0] 
https://docs.google.com/document/d/1voaR9Xk3lisCQIG3ThySOSnSHBUequljQYnceFlr53w/edit
[Public and linked to already way before any involvement from Rockchip itself, 
so does not fall under an NDA, but also unchanged since then]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rafael J. Wysocki]

On Tuesday, July 28, 2015 03:09:06 PM Tim Bird wrote:
> On 07/23/2015 08:40 AM, Mark Brown wrote:
> > On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
> > 
> >> Although is this something to be a core topic or a tech topic? Does
> >> this affect all subsystems, or just a set of drivers? Note, a core
> >> topic wont get as much time for discussion as a tech topic would.
> > 
> > It's basically all subsystems that get impacted, at the minute I'd say
> > it's more a plan of action and process discussion than a technical one
> > though in the context of KS planning that's quite probably the same
> > thing.
> > 
> >> Also, what is expected to be solved at KS?
> > 
> > Tim Bird (Cced) has been running some sessions at other conferences
> > scoping the problem and discussing ways to move forward on this, another
> > similar session might be useful.
> 
> As Mark says, I've been working on almost exactly this topic for several
> months now.  Last year I conducted a survey investigating obstacles
> that developers (mostly corporate product developers) have in mainlining.
> There are lots of non-technical issues that are worth working on (version
> gap, corporate incentives, training, etc.), but which are outside
> the scope of the kernel summit.
> 
> There are also some technical areas where I think coordinated
> effort might be useful, to identify deficiencies and collaborate on
> progress.  These might be worth discussing at the summit.
> 
> In March of this year, I analysed code from several shipping phones
> (representing a number of different SoCs, including both ARM and
> Intel-architecture CPUs), and found that most products have between
> 1.2 and 3 million lines of code out-of-tree.  We are still in progress of
> finding patterns of out-of-treeness, to inform decisions about technical
> projects going forward.
> 
> There is now a wiki page at:
> See http://elinux.org/Kernel_areas_of_focus_for_mainlining
> In particular it has a table showing certain areas that tend to have
> a lot of out-of-tree code (e.g. most phones have between 80K to
> 100K of lines of wireless driver support out-of-mainline)
> 
> IMHO it would be useful to discuss these areas, to see if there
> are technical reasons for these deficiencies, and work to resolve
> them.

Fully agreed!

Thanks,
Rafael

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Daniel Vetter]

On Wed, Jul 29, 2015 at 12:09 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
> There is now a wiki page at:
> See http://elinux.org/Kernel_areas_of_focus_for_mainlining
> In particular it has a table showing certain areas that tend to have
> a lot of out-of-tree code (e.g. most phones have between 80K to
> 100K of lines of wireless driver support out-of-mainline)

Quick question on your table: Is "Video" drivers/video i.e. all the
legacy fbdev horror-show? If so you probably want to rename that to
"GPU (legacy)" or similar since for upstream all that stuff really
should end up as a drm gpu driver. Especially now that atomic
modesetting is merged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Tim Bird]

On 07/28/2015 11:43 PM, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 12:09 AM, Tim Bird <tim.bird@sonymobile.com> wrote:
>> There is now a wiki page at:
>> See http://elinux.org/Kernel_areas_of_focus_for_mainlining
>> In particular it has a table showing certain areas that tend to have
>> a lot of out-of-tree code (e.g. most phones have between 80K to
>> 100K of lines of wireless driver support out-of-mainline)
> 
> Quick question on your table: Is "Video" drivers/video i.e. all the
> legacy fbdev horror-show? If so you probably want to rename that to
> "GPU (legacy)" or similar since for upstream all that stuff really
> should end up as a drm gpu driver. Especially now that atomic
> modesetting is merged.

It is.  Thanks for the feedback.
 -- Tim

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Bintian]

Hi All,

I am also very interested in this topic, and now I am focusing on
Huawei cellphone kernel development.

One month ago, I submitted the basic system and clock driver of HiKey
to linux kernel, and HiKey is the prototype of Huawei Honor 4X
cellphone.

We really hope people can download the latest kernel code and run well
on HiKey(or other mobile products) at some future date, and now we try
to submit the rest drivers to kernel maillist.

On 2015/7/29 6:09, Tim Bird wrote:
> On 07/23/2015 08:40 AM, Mark Brown wrote:
>> On Thu, Jul 23, 2015 at 08:42:51AM -0400, Steven Rostedt wrote:
>>
>>> Although is this something to be a core topic or a tech topic? Does
>>> this affect all subsystems, or just a set of drivers? Note, a core
>>> topic wont get as much time for discussion as a tech topic would.
>>
>> It's basically all subsystems that get impacted, at the minute I'd say
>> it's more a plan of action and process discussion than a technical one
>> though in the context of KS planning that's quite probably the same
>> thing.
>>
>>> Also, what is expected to be solved at KS?
>>
>> Tim Bird (Cced) has been running some sessions at other conferences
>> scoping the problem and discussing ways to move forward on this, another
>> similar session might be useful.
>
> As Mark says, I've been working on almost exactly this topic for several
> months now.  Last year I conducted a survey investigating obstacles
> that developers (mostly corporate product developers) have in mainlining.
> There are lots of non-technical issues that are worth working on (version
> gap, corporate incentives, training, etc.), but which are outside
> the scope of the kernel summit.
>
> There are also some technical areas where I think coordinated
> effort might be useful, to identify deficiencies and collaborate on
> progress.  These might be worth discussing at the summit.
>
> In March of this year, I analysed code from several shipping phones
> (representing a number of different SoCs, including both ARM and
> Intel-architecture CPUs), and found that most products have between
> 1.2 and 3 million lines of code out-of-tree.  We are still in progress of
> finding patterns of out-of-treeness, to inform decisions about technical
> projects going forward.
>
> There is now a wiki page at:
> See http://elinux.org/Kernel_areas_of_focus_for_mainlining
> In particular it has a table showing certain areas that tend to have
> a lot of out-of-tree code (e.g. most phones have between 80K to
> 100K of lines of wireless driver support out-of-mainline)
Very glad to see Huawei P6 is also in your investigation list :)

For HiKey, the original display driver is based on Framebuffer, but we
need to reconstruct this driver based on DRM framework when do the
upstream work, one lesson we learned here is trying to develop drivers
based on the requirements of current linux sub-system.

>
> IMHO it would be useful to discuss these areas, to see if there
> are technical reasons for these deficiencies, and work to resolve
> them.
Agree.

Thanks,

Bintian

>   -- Tim
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
> .
>

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Tim Bird]

On 07/29/2015 12:14 AM, Bintian wrote:
> Hi All,
> 
> I am also very interested in this topic, and now I am focusing on
> Huawei cellphone kernel development.
> 
> One month ago, I submitted the basic system and clock driver of HiKey
> to linux kernel, and HiKey is the prototype of Huawei Honor 4X
> cellphone.
> 
> We really hope people can download the latest kernel code and run well
> on HiKey(or other mobile products) at some future date, and now we try
> to submit the rest drivers to kernel maillist.

That's great!  Thanks for your efforts on this!

...

> For HiKey, the original display driver is based on Framebuffer, but we
> need to reconstruct this driver based on DRM framework when do the
> upstream work, one lesson we learned here is trying to develop drivers
> based on the requirements of current linux sub-system.

Thanks for sharing that.

I'd be interested in hearing from different people about what
their big areas of concern are (or what they anticipate will
be their large areas of work).

>> IMHO it would be useful to discuss these areas, to see if there
>> are technical reasons for these deficiencies, and work to resolve
>> them.
> Agree.
> 
> Thanks,

I'm not trying to gin up attendees for LinuxFoundation or
Linaro events, but if you happen to be there, we are planning on
hosting BOFs about this topic at the following upcoming events:
  LinuxCon NA - August 19, 12:45, Seattle, WA, USA
  Linaro Connect - (probably) September 22, Burlingame, CA, USA
  ELC Europe - October 7, 11:30, Dublin, Ireland

Please drop by if you are interested, or send me an e-mail
if you want more details about the current work.
 -- Tim

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Bintian]

On 2015/7/30 2:07, Tim Bird wrote:
> On 07/29/2015 12:14 AM, Bintian wrote:
[...]
>
> I'm not trying to gin up attendees for LinuxFoundation or
> Linaro events, but if you happen to be there, we are planning on
> hosting BOFs about this topic at the following upcoming events:
>    LinuxCon NA - August 19, 12:45, Seattle, WA, USA
>    Linaro Connect - (probably) September 22, Burlingame, CA, USA
>    ELC Europe - October 7, 11:30, Dublin, Ireland
I am interested in this topic and your current work, the hosting places
of above three events are far from China, I am afraid I cannot attend.
But Korea is very close to Beijing :)

Thank you Tim,

BR,

Bintian

>
> Please drop by if you are interested, or send me an e-mail
> if you want more details about the current work.
>   -- Tim
>
>
> .
>

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Thu 2015-07-23 08:42:51, Steven Rostedt wrote:
> On Thu, 23 Jul 2015 14:14:41 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
> > > On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > > 
> > > > Significant percentage of phones run Linux kernel today, but geting
> > > > mainline kernel to work on a phone is very hard to do. (So hard, that
> > > > newest device that is close to working on recent mainline was made in
> > > > 2009.) There are multiple obstacles, including huge patches from
> > > > silicon vendors, missing GNU/Linux userspace support that makes kernel
> > > > testing hard, interfaces unsuitable for phones and power management
> > > > problems.
> 
> > 
> > Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.
> 
> Seems like a reasonable topic, especially since KS is being held in
> South Korea this year.
> 
> Although is this something to be a core topic or a tech topic? Does
> this affect all subsystems, or just a set of drivers? Note, a core
> topic wont get as much time for discussion as a tech topic would.
> 
> Also, what is expected to be solved at KS?

Questions I had in mind:

1) RGB leds. They are not same as 3 leds. Plus there' hw acceleration
on them. How to support them?

2) HW damage: is it kernel's job to protect hardware from user? We
currently have no battery over-discharge protection (and its tricky).

3) HW abstraction: do we want to keep the model where kernel hides
differences between different machines, so that same userland can run
on all of them? Currently that is broken, for example we have 3
"chargers" on N900, and userland gets very confused; or we have 100
mixers, that are pretty much imposible to set up by user..

4) voice link to modem: Nokia people tell us that ALSA is not suitable
interface to modem audio. What is the right interface, then?

5) where do we get userland for testing?

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] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Thu 2015-07-23 22:29:02, Pavel Machek wrote:
> On Thu 2015-07-23 08:42:51, Steven Rostedt wrote:
> > On Thu, 23 Jul 2015 14:14:41 +0200
> > Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > > On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
> > > > On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > > > 
> > > > > Significant percentage of phones run Linux kernel today, but geting
> > > > > mainline kernel to work on a phone is very hard to do. (So hard, that
> > > > > newest device that is close to working on recent mainline was made in
> > > > > 2009.) There are multiple obstacles, including huge patches from
> > > > > silicon vendors, missing GNU/Linux userspace support that makes kernel
> > > > > testing hard, interfaces unsuitable for phones and power management
> > > > > problems.
> > 
> > > 
> > > Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.
> > 
> > Seems like a reasonable topic, especially since KS is being held in
> > South Korea this year.
> > 
> > Although is this something to be a core topic or a tech topic? Does
> > this affect all subsystems, or just a set of drivers? Note, a core
> > topic wont get as much time for discussion as a tech topic would.
> > 
> > Also, what is expected to be solved at KS?
> 
> Questions I had in mind:
> 
> 1) RGB leds. They are not same as 3 leds. Plus there' hw acceleration
> on them. How to support them?
> 
> 2) HW damage: is it kernel's job to protect hardware from user? We
> currently have no battery over-discharge protection (and its tricky).
> 
> 3) HW abstraction: do we want to keep the model where kernel hides
> differences between different machines, so that same userland can run
> on all of them? Currently that is broken, for example we have 3
> "chargers" on N900, and userland gets very confused; or we have 100
> mixers, that are pretty much imposible to set up by user..
> 
> 4) voice link to modem: Nokia people tell us that ALSA is not suitable
> interface to modem audio. What is the right interface, then?
> 
> 5) where do we get userland for testing?

and the big one... for Android people (not me):

6) do we need to use s2ram (and then pretend phone is not suspended)
to save power on cellphones? If so, do we need new interface for
applications to signal "I'd really like to run"?

									Pavel

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

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[NeilBrown]

On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:

> On Thu 2015-07-23 22:29:02, Pavel Machek wrote:
> > On Thu 2015-07-23 08:42:51, Steven Rostedt wrote:
> > > On Thu, 23 Jul 2015 14:14:41 +0200
> > > Pavel Machek <pavel@ucw.cz> wrote:
> > > 
> > > > On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
> > > > > On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > > > > 
> > > > > > Significant percentage of phones run Linux kernel today, but geting
> > > > > > mainline kernel to work on a phone is very hard to do. (So hard, that
> > > > > > newest device that is close to working on recent mainline was made in
> > > > > > 2009.) There are multiple obstacles, including huge patches from
> > > > > > silicon vendors, missing GNU/Linux userspace support that makes kernel
> > > > > > testing hard, interfaces unsuitable for phones and power management
> > > > > > problems.
> > > 
> > > > 
> > > > Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.
> > > 
> > > Seems like a reasonable topic, especially since KS is being held in
> > > South Korea this year.
> > > 
> > > Although is this something to be a core topic or a tech topic? Does
> > > this affect all subsystems, or just a set of drivers? Note, a core
> > > topic wont get as much time for discussion as a tech topic would.
> > > 
> > > Also, what is expected to be solved at KS?
> > 
> > Questions I had in mind:
> > 
> > 1) RGB leds. They are not same as 3 leds. Plus there' hw acceleration
> > on them. How to support them?
> > 
> > 2) HW damage: is it kernel's job to protect hardware from user? We
> > currently have no battery over-discharge protection (and its tricky).
> > 
> > 3) HW abstraction: do we want to keep the model where kernel hides
> > differences between different machines, so that same userland can run
> > on all of them? Currently that is broken, for example we have 3
> > "chargers" on N900, and userland gets very confused; or we have 100
> > mixers, that are pretty much imposible to set up by user..
> > 
> > 4) voice link to modem: Nokia people tell us that ALSA is not suitable
> > interface to modem audio. What is the right interface, then?
> > 
> > 5) where do we get userland for testing?
> 
> and the big one... for Android people (not me):
> 
> 6) do we need to use s2ram (and then pretend phone is not suspended)
> to save power on cellphones? If so, do we need new interface for
> applications to signal "I'd really like to run"?
> 

For the first half of this question, the answer is:
 Probably not.  runtime-pm should be able to put all devices to sleep,
  and cgroup freezer should be able to freeze untrusted processes.
 But I suspect runtime-pm doesn't provide as much power saving as
 system suspend, and using the cgroup freezer means lots of changes to
 userspace.
 So lots of work would be needed to meet this goal, if it is a
 worthwhile goal.

For the second half - it is really a user-space problem.  User-space
decides when to enter suspend.
(or CONFIG_PM_WAKELOCKS can enable a kernel interface
via /sys/power/wake_lock).

NeilBrown

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Tony Lindgren]

* NeilBrown <neilb@suse.com> [150723 21:37]:
> On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > and the big one... for Android people (not me):
> > 
> > 6) do we need to use s2ram (and then pretend phone is not suspended)
> > to save power on cellphones? If so, do we need new interface for
> > applications to signal "I'd really like to run"?
> > 
> 
> For the first half of this question, the answer is:
>  Probably not.  runtime-pm should be able to put all devices to sleep,
>   and cgroup freezer should be able to freeze untrusted processes.

Yes s2ram is just an additional tool. PM runtime alone can
already provide a reasonable battery life for a phone as long as
it's properly implemented and the hardware supports it. With
reasonable battery life in this case I mean over 10 days in idle
mode with system running and timers working.

>  But I suspect runtime-pm doesn't provide as much power saving as
>  system suspend, and using the cgroup freezer means lots of changes to
>  userspace.
>  So lots of work would be needed to meet this goal, if it is a
>  worthwhile goal.

And with s2ram the difference is that then the system is not running
and timers don't work so it really needs to be optional.
 
> For the second half - it is really a user-space problem.  User-space
> decides when to enter suspend.
> (or CONFIG_PM_WAKELOCKS can enable a kernel interface
> via /sys/power/wake_lock).

Yeah agreed.

Regards,

Tony

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rafael J. Wysocki]

On Thursday, July 23, 2015 11:00:49 PM Tony Lindgren wrote:
> * NeilBrown <neilb@suse.com> [150723 21:37]:
> > On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:
> > > 
> > > and the big one... for Android people (not me):
> > > 
> > > 6) do we need to use s2ram (and then pretend phone is not suspended)
> > > to save power on cellphones? If so, do we need new interface for
> > > applications to signal "I'd really like to run"?
> > > 
> > 
> > For the first half of this question, the answer is:
> >  Probably not.  runtime-pm should be able to put all devices to sleep,
> >   and cgroup freezer should be able to freeze untrusted processes.
> 
> Yes s2ram is just an additional tool. PM runtime alone can
> already provide a reasonable battery life for a phone as long as
> it's properly implemented and the hardware supports it. With
> reasonable battery life in this case I mean over 10 days in idle
> mode with system running and timers working.
> 
> >  But I suspect runtime-pm doesn't provide as much power saving as
> >  system suspend, and using the cgroup freezer means lots of changes to
> >  userspace.
> >  So lots of work would be needed to meet this goal, if it is a
> >  worthwhile goal.
> 
> And with s2ram the difference is that then the system is not running
> and timers don't work so it really needs to be optional.

Right.

Even with suspend-to-idle we can get less energy usage with respect to
runtime idle (device runtime PM plus cpuidle) just because timer events
are disabled then.

> > For the second half - it is really a user-space problem.  User-space
> > decides when to enter suspend.
> > (or CONFIG_PM_WAKELOCKS can enable a kernel interface
> > via /sys/power/wake_lock).
> 
> Yeah agreed.

Right.

Thanks,
Rafael

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[NeilBrown]

On Sat, 25 Jul 2015 00:26:03 +0200 "Rafael J. Wysocki"
<rjw@rjwysocki.net> wrote:

> On Thursday, July 23, 2015 11:00:49 PM Tony Lindgren wrote:
> > * NeilBrown <neilb@suse.com> [150723 21:37]:
> > > On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:
> > > > 
> > > > and the big one... for Android people (not me):
> > > > 
> > > > 6) do we need to use s2ram (and then pretend phone is not suspended)
> > > > to save power on cellphones? If so, do we need new interface for
> > > > applications to signal "I'd really like to run"?
> > > > 
> > > 
> > > For the first half of this question, the answer is:
> > >  Probably not.  runtime-pm should be able to put all devices to sleep,
> > >   and cgroup freezer should be able to freeze untrusted processes.
> > 
> > Yes s2ram is just an additional tool. PM runtime alone can
> > already provide a reasonable battery life for a phone as long as
> > it's properly implemented and the hardware supports it. With
> > reasonable battery life in this case I mean over 10 days in idle
> > mode with system running and timers working.
> > 
> > >  But I suspect runtime-pm doesn't provide as much power saving as
> > >  system suspend, and using the cgroup freezer means lots of changes to
> > >  userspace.
> > >  So lots of work would be needed to meet this goal, if it is a
> > >  worthwhile goal.
> > 
> > And with s2ram the difference is that then the system is not running
> > and timers don't work so it really needs to be optional.
> 
> Right.
> 
> Even with suspend-to-idle we can get less energy usage with respect to
> runtime idle (device runtime PM plus cpuidle) just because timer events
> are disabled then.
> 

Is this just the timer interrupt which keeps the clock up to date, or
are there other timer events which keep ticking?

Would it be possible for the wall-clock timer to stop if the system
has been idle for a while, and for the RTC to be used to recover the
correct time when activity restarts?

Thanks,
NeilBrown
 

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rafael J. Wysocki]

On Wednesday, July 29, 2015 08:03:50 AM NeilBrown wrote:
> On Sat, 25 Jul 2015 00:26:03 +0200 "Rafael J. Wysocki"
> <rjw@rjwysocki.net> wrote:
> 
> > On Thursday, July 23, 2015 11:00:49 PM Tony Lindgren wrote:
> > > * NeilBrown <neilb@suse.com> [150723 21:37]:
> > > > On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:
> > > > > 
> > > > > and the big one... for Android people (not me):
> > > > > 
> > > > > 6) do we need to use s2ram (and then pretend phone is not suspended)
> > > > > to save power on cellphones? If so, do we need new interface for
> > > > > applications to signal "I'd really like to run"?
> > > > > 
> > > > 
> > > > For the first half of this question, the answer is:
> > > >  Probably not.  runtime-pm should be able to put all devices to sleep,
> > > >   and cgroup freezer should be able to freeze untrusted processes.
> > > 
> > > Yes s2ram is just an additional tool. PM runtime alone can
> > > already provide a reasonable battery life for a phone as long as
> > > it's properly implemented and the hardware supports it. With
> > > reasonable battery life in this case I mean over 10 days in idle
> > > mode with system running and timers working.
> > > 
> > > >  But I suspect runtime-pm doesn't provide as much power saving as
> > > >  system suspend, and using the cgroup freezer means lots of changes to
> > > >  userspace.
> > > >  So lots of work would be needed to meet this goal, if it is a
> > > >  worthwhile goal.
> > > 
> > > And with s2ram the difference is that then the system is not running
> > > and timers don't work so it really needs to be optional.
> > 
> > Right.
> > 
> > Even with suspend-to-idle we can get less energy usage with respect to
> > runtime idle (device runtime PM plus cpuidle) just because timer events
> > are disabled then.
> > 
> 
> Is this just the timer interrupt which keeps the clock up to date, or
> are there other timer events which keep ticking?

The other events mostly.

> Would it be possible for the wall-clock timer to stop if the system
> has been idle for a while, and for the RTC to be used to recover the
> correct time when activity restarts?

We use that mechanism in suspend-to-idle, but it requires the timekeeping
to be frozen.  I don't think it would be possible to do that for runtime
idle without races, though.

Thanks,
Rafael

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rafael J. Wysocki]

On Wednesday, July 29, 2015 02:51:22 AM Rafael J. Wysocki wrote:
> On Wednesday, July 29, 2015 08:03:50 AM NeilBrown wrote:
> > On Sat, 25 Jul 2015 00:26:03 +0200 "Rafael J. Wysocki"
> > <rjw@rjwysocki.net> wrote:
> > 
> > > On Thursday, July 23, 2015 11:00:49 PM Tony Lindgren wrote:
> > > > * NeilBrown <neilb@suse.com> [150723 21:37]:
> > > > > On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:
> > > > > > 
> > > > > > and the big one... for Android people (not me):
> > > > > > 
> > > > > > 6) do we need to use s2ram (and then pretend phone is not suspended)
> > > > > > to save power on cellphones? If so, do we need new interface for
> > > > > > applications to signal "I'd really like to run"?
> > > > > > 
> > > > > 
> > > > > For the first half of this question, the answer is:
> > > > >  Probably not.  runtime-pm should be able to put all devices to sleep,
> > > > >   and cgroup freezer should be able to freeze untrusted processes.
> > > > 
> > > > Yes s2ram is just an additional tool. PM runtime alone can
> > > > already provide a reasonable battery life for a phone as long as
> > > > it's properly implemented and the hardware supports it. With
> > > > reasonable battery life in this case I mean over 10 days in idle
> > > > mode with system running and timers working.
> > > > 
> > > > >  But I suspect runtime-pm doesn't provide as much power saving as
> > > > >  system suspend, and using the cgroup freezer means lots of changes to
> > > > >  userspace.
> > > > >  So lots of work would be needed to meet this goal, if it is a
> > > > >  worthwhile goal.
> > > > 
> > > > And with s2ram the difference is that then the system is not running
> > > > and timers don't work so it really needs to be optional.
> > > 
> > > Right.
> > > 
> > > Even with suspend-to-idle we can get less energy usage with respect to
> > > runtime idle (device runtime PM plus cpuidle) just because timer events
> > > are disabled then.
> > > 
> > 
> > Is this just the timer interrupt which keeps the clock up to date, or
> > are there other timer events which keep ticking?
> 
> The other events mostly.
> 
> > Would it be possible for the wall-clock timer to stop if the system
> > has been idle for a while, and for the RTC to be used to recover the
> > correct time when activity restarts?
> 
> We use that mechanism in suspend-to-idle, but it requires the timekeeping
> to be frozen.  I don't think it would be possible to do that for runtime
> idle without races, though.

Moreover, the "if the system has been idle for a while" condition is not really
in line with how runtime idle works.  Namely, it works by predicting how much
time the given CPU will be idle (on the basis of when the next timer event
for it is scheduled among other things) and selecting an idle state for it
to go to in accordance with that.  So we know upfront how much time the CPU
will be idle (at least roughly) and we rely on timer events to wake up CPUs
from idle states.

In the suspend-to-idle case we only need to care about events from devices
explicitly enabled to wake up the system from sleep and that's why we can safely
suspend the timekeeping then.

Thanks,
Rafael

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[NeilBrown]

On Thu, 30 Jul 2015 01:23:21 +0200 "Rafael J. Wysocki"
<rjw@rjwysocki.net> wrote:

> On Wednesday, July 29, 2015 02:51:22 AM Rafael J. Wysocki wrote:
> > On Wednesday, July 29, 2015 08:03:50 AM NeilBrown wrote:
> > > On Sat, 25 Jul 2015 00:26:03 +0200 "Rafael J. Wysocki"
> > > <rjw@rjwysocki.net> wrote:
> > > 
> > > > On Thursday, July 23, 2015 11:00:49 PM Tony Lindgren wrote:
> > > > > * NeilBrown <neilb@suse.com> [150723 21:37]:
> > > > > > On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:
> > > > > > > 
> > > > > > > and the big one... for Android people (not me):
> > > > > > > 
> > > > > > > 6) do we need to use s2ram (and then pretend phone is not suspended)
> > > > > > > to save power on cellphones? If so, do we need new interface for
> > > > > > > applications to signal "I'd really like to run"?
> > > > > > > 
> > > > > > 
> > > > > > For the first half of this question, the answer is:
> > > > > >  Probably not.  runtime-pm should be able to put all devices to sleep,
> > > > > >   and cgroup freezer should be able to freeze untrusted processes.
> > > > > 
> > > > > Yes s2ram is just an additional tool. PM runtime alone can
> > > > > already provide a reasonable battery life for a phone as long as
> > > > > it's properly implemented and the hardware supports it. With
> > > > > reasonable battery life in this case I mean over 10 days in idle
> > > > > mode with system running and timers working.
> > > > > 
> > > > > >  But I suspect runtime-pm doesn't provide as much power saving as
> > > > > >  system suspend, and using the cgroup freezer means lots of changes to
> > > > > >  userspace.
> > > > > >  So lots of work would be needed to meet this goal, if it is a
> > > > > >  worthwhile goal.
> > > > > 
> > > > > And with s2ram the difference is that then the system is not running
> > > > > and timers don't work so it really needs to be optional.
> > > > 
> > > > Right.
> > > > 
> > > > Even with suspend-to-idle we can get less energy usage with respect to
> > > > runtime idle (device runtime PM plus cpuidle) just because timer events
> > > > are disabled then.
> > > > 
> > > 
> > > Is this just the timer interrupt which keeps the clock up to date, or
> > > are there other timer events which keep ticking?
> > 
> > The other events mostly.
> > 
> > > Would it be possible for the wall-clock timer to stop if the system
> > > has been idle for a while, and for the RTC to be used to recover the
> > > correct time when activity restarts?
> > 
> > We use that mechanism in suspend-to-idle, but it requires the timekeeping
> > to be frozen.  I don't think it would be possible to do that for runtime
> > idle without races, though.
> 
> Moreover, the "if the system has been idle for a while" condition is not really
> in line with how runtime idle works.  Namely, it works by predicting how much
> time the given CPU will be idle (on the basis of when the next timer event
> for it is scheduled among other things) and selecting an idle state for it
> to go to in accordance with that.  So we know upfront how much time the CPU
> will be idle (at least roughly) and we rely on timer events to wake up CPUs
> from idle states.
> 
> In the suspend-to-idle case we only need to care about events from devices
> explicitly enabled to wake up the system from sleep and that's why we can safely
> suspend the timekeeping then.
> 

Thanks ... this actually helps me understand the point of
suspend-to-idle which didn't really make a lot of sense to me before
(though it entirely possible that I'm still missing some bits).

A while ago (years?) there was a debate about whether it was really
sensible/necessary to use system suspend to save power.  This was in
the context of Android and suspend-blocker/wake-locks.  One school of
thought was that with sufficient runtime-PM and appropriate controls of
user-space processes, system-wide suspend was not necessary.

You seem to be saying that timer-interrupts are the deal-breaker.  The
only way to stop timer interrupts indefinitely is using some sort of
system-wide suspend, whether suspend-to-RAM or suspend-to-idle.

While it may be possible to achieve significant power savings without
using system-wide suspend, there is a limit and system-wide suspend
will always allow better savings.

Would that be correct?  If so: it is nice to have a clear answer -
thanks.

NeilBrown

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rafael J. Wysocki]

On Thursday, July 30, 2015 09:59:03 AM NeilBrown wrote:
> On Thu, 30 Jul 2015 01:23:21 +0200 "Rafael J. Wysocki"
> <rjw@rjwysocki.net> wrote:
> 
> > On Wednesday, July 29, 2015 02:51:22 AM Rafael J. Wysocki wrote:
> > > On Wednesday, July 29, 2015 08:03:50 AM NeilBrown wrote:
> > > > On Sat, 25 Jul 2015 00:26:03 +0200 "Rafael J. Wysocki"
> > > > <rjw@rjwysocki.net> wrote:
> > > > 
> > > > > On Thursday, July 23, 2015 11:00:49 PM Tony Lindgren wrote:
> > > > > > * NeilBrown <neilb@suse.com> [150723 21:37]:
> > > > > > > On Thu, 23 Jul 2015 22:34:29 +0200 Pavel Machek <pavel@ucw.cz> wrote:
> > > > > > > > 
> > > > > > > > and the big one... for Android people (not me):
> > > > > > > > 
> > > > > > > > 6) do we need to use s2ram (and then pretend phone is not suspended)
> > > > > > > > to save power on cellphones? If so, do we need new interface for
> > > > > > > > applications to signal "I'd really like to run"?
> > > > > > > > 
> > > > > > > 
> > > > > > > For the first half of this question, the answer is:
> > > > > > >  Probably not.  runtime-pm should be able to put all devices to sleep,
> > > > > > >   and cgroup freezer should be able to freeze untrusted processes.
> > > > > > 
> > > > > > Yes s2ram is just an additional tool. PM runtime alone can
> > > > > > already provide a reasonable battery life for a phone as long as
> > > > > > it's properly implemented and the hardware supports it. With
> > > > > > reasonable battery life in this case I mean over 10 days in idle
> > > > > > mode with system running and timers working.
> > > > > > 
> > > > > > >  But I suspect runtime-pm doesn't provide as much power saving as
> > > > > > >  system suspend, and using the cgroup freezer means lots of changes to
> > > > > > >  userspace.
> > > > > > >  So lots of work would be needed to meet this goal, if it is a
> > > > > > >  worthwhile goal.
> > > > > > 
> > > > > > And with s2ram the difference is that then the system is not running
> > > > > > and timers don't work so it really needs to be optional.
> > > > > 
> > > > > Right.
> > > > > 
> > > > > Even with suspend-to-idle we can get less energy usage with respect to
> > > > > runtime idle (device runtime PM plus cpuidle) just because timer events
> > > > > are disabled then.
> > > > > 
> > > > 
> > > > Is this just the timer interrupt which keeps the clock up to date, or
> > > > are there other timer events which keep ticking?
> > > 
> > > The other events mostly.
> > > 
> > > > Would it be possible for the wall-clock timer to stop if the system
> > > > has been idle for a while, and for the RTC to be used to recover the
> > > > correct time when activity restarts?
> > > 
> > > We use that mechanism in suspend-to-idle, but it requires the timekeeping
> > > to be frozen.  I don't think it would be possible to do that for runtime
> > > idle without races, though.
> > 
> > Moreover, the "if the system has been idle for a while" condition is not really
> > in line with how runtime idle works.  Namely, it works by predicting how much
> > time the given CPU will be idle (on the basis of when the next timer event
> > for it is scheduled among other things) and selecting an idle state for it
> > to go to in accordance with that.  So we know upfront how much time the CPU
> > will be idle (at least roughly) and we rely on timer events to wake up CPUs
> > from idle states.
> > 
> > In the suspend-to-idle case we only need to care about events from devices
> > explicitly enabled to wake up the system from sleep and that's why we can safely
> > suspend the timekeeping then.
> > 
> 
> Thanks ... this actually helps me understand the point of
> suspend-to-idle which didn't really make a lot of sense to me before
> (though it entirely possible that I'm still missing some bits).
> 
> A while ago (years?) there was a debate about whether it was really
> sensible/necessary to use system suspend to save power.  This was in
> the context of Android and suspend-blocker/wake-locks.  One school of
> thought was that with sufficient runtime-PM and appropriate controls of
> user-space processes, system-wide suspend was not necessary.
> 
> You seem to be saying that timer-interrupts are the deal-breaker.

Yes, they are.

> The only way to stop timer interrupts indefinitely is using some sort of
> system-wide suspend, whether suspend-to-RAM or suspend-to-idle.

Right.

> While it may be possible to achieve significant power savings without
> using system-wide suspend, there is a limit and system-wide suspend
> will always allow better savings.
> 
> Would that be correct?  If so: it is nice to have a clear answer -
> thanks.

Yes, that's correct.

Essentially, what happens is that runtime PM allows us to reach the state
in which the system draws as little power as in suspend-to-idle, but it
simply doesn't allow the system to stay in that state long enough in one
go due to timer interrupts (and possibly other types of interrupt noice
that is suppressed by suspending all devices).

Since energy is the power drawn in a given state times the time spent in that
state (on the average), that's why the system in suspend-to-idle uses less
energy than it would with runtime idle during the same period (modulo the
energy spent on suspending and resuming devices etc, of course).

Thanks,
Rafael

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown]

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

On Thu, Jul 30, 2015 at 02:57:17AM +0200, Rafael J. Wysocki wrote:

> Essentially, what happens is that runtime PM allows us to reach the state
> in which the system draws as little power as in suspend-to-idle, but it
> simply doesn't allow the system to stay in that state long enough in one
> go due to timer interrupts (and possibly other types of interrupt noice
> that is suppressed by suspending all devices).

> Since energy is the power drawn in a given state times the time spent in that
> state (on the average), that's why the system in suspend-to-idle uses less
> energy than it would with runtime idle during the same period (modulo the
> energy spent on suspending and resuming devices etc, of course).

We could in theory work to reduce the number of these additional timer
and other interrupts further - there was a lot of focus on this in the
past (partly for desktop use cases where suspend isn't such a quick out)
though with the advent of Android and the wide deployment of suspend to
idle that resulted people stopped bothering on the embedded side since
suspend to idle is both simple and effective.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Rafael J. Wysocki]

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

On Friday, July 31, 2015 06:55:47 PM Mark Brown wrote:
> On Thu, Jul 30, 2015 at 02:57:17AM +0200, Rafael J. Wysocki wrote:
> 
> > Essentially, what happens is that runtime PM allows us to reach the state
> > in which the system draws as little power as in suspend-to-idle, but it
> > simply doesn't allow the system to stay in that state long enough in one
> > go due to timer interrupts (and possibly other types of interrupt noice
> > that is suppressed by suspending all devices).
> 
> > Since energy is the power drawn in a given state times the time spent in that
> > state (on the average), that's why the system in suspend-to-idle uses less
> > energy than it would with runtime idle during the same period (modulo the
> > energy spent on suspending and resuming devices etc, of course).
> 
> We could in theory work to reduce the number of these additional timer
> and other interrupts further - there was a lot of focus on this in the
> past (partly for desktop use cases where suspend isn't such a quick out)
> though with the advent of Android and the wide deployment of suspend to
> idle that resulted people stopped bothering on the embedded side since
> suspend to idle is both simple and effective.

In addition to that, while we can reduce the number of those in the kernel,
user space can still do things that increase the number of them and we can't
really control it.  That only depends on what applications are running and
users may not be aware of all of the consequences of running them.

By freezing user space during suspend we effectively prevent it from
scheduling more timer events in the future.

Thanks,
Rafael

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[josh]

On Thu, Jul 23, 2015 at 10:29:02PM +0200, Pavel Machek wrote:
> Questions I had in mind:
> 
> 1) RGB leds. They are not same as 3 leds. Plus there' hw acceleration
> on them. How to support them?

Seems like internally we should treat them as 3 LEDs, but the interface
to userspace or to the LED trigger mechanism should group the three
brightness values together rather than handling them separately.

Is the hardware acceleration something more than PWM?

- Josh Triplett

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Thu 2015-07-23 14:00:18, josh@joshtriplett.org wrote:
> On Thu, Jul 23, 2015 at 10:29:02PM +0200, Pavel Machek wrote:
> > Questions I had in mind:
> > 
> > 1) RGB leds. They are not same as 3 leds. Plus there' hw acceleration
> > on them. How to support them?
> 
> Seems like internally we should treat them as 3 LEDs, but the interface
> to userspace or to the LED trigger mechanism should group the three
> brightness values together rather than handling them separately.

Yes. It should me "make it show magenta" not "set red to x, blue to y,
green to z"...

> Is the hardware acceleration something more than PWM?

Yes. It can do quite complex patterns autonomously. "Blink red three
times, then slowly go to full brightness and back". It can do as
complex stuff as blink n times, then delay, for n is prime
number.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown]

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

On Thu, Jul 23, 2015 at 10:29:02PM +0200, Pavel Machek wrote:

> 4) voice link to modem: Nokia people tell us that ALSA is not suitable
> interface to modem audio. What is the right interface, then?

ALSA is the right interface for this, this is going to be some
misunderstanding on their part about how to use it or limitations in
the drivers for their particular system (and possibly some unfortunate
hardware design, it sounds like they may still be bouncing the voice
call through the AP which isn't the most wonderful idea ever).  There
are rather a lot of production phones using ALSA out there without undue
complaints.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Wed 2015-07-29 14:32:44, Mark Brown wrote:
> On Thu, Jul 23, 2015 at 10:29:02PM +0200, Pavel Machek wrote:
> 
> > 4) voice link to modem: Nokia people tell us that ALSA is not suitable
> > interface to modem audio. What is the right interface, then?
> 
> ALSA is the right interface for this, this is going to be some
> misunderstanding on their part about how to use it or limitations in

That's what I was arguing, but see https://lkml.org/lkml/2015/3/5/606
.

kai> Our take was that ALSA is not the right interface for cmt_speech. The
kai> cmt_speech interface in the modem is _not_ a PCM interface as modelled
kai> by
kai> ALSA. Specifically:
kai>
kai>- the interface is lossy in both directions
kai>- data is sent in packets, not a stream of samples (could be other
kai>- things
kai>   than PCM samples), with timing and meta-data
kai>   - timing of uplink is of utmost importance
   

> the drivers for their particular system (and possibly some unfortunate
> hardware design, it sounds like they may still be bouncing the voice
> call through the AP which isn't the most wonderful idea ever).
> There

Actually, sending data through AP is _very_ good idea from security
perspective. You don't want hacked baseband to eavesdrop on you, do
you?

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] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown]

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

On Fri, Jul 31, 2015 at 02:22:27PM +0200, Pavel Machek wrote:
> On Wed 2015-07-29 14:32:44, Mark Brown wrote:
> > On Thu, Jul 23, 2015 at 10:29:02PM +0200, Pavel Machek wrote:

> > ALSA is the right interface for this, this is going to be some
> > misunderstanding on their part about how to use it or limitations in

> That's what I was arguing, but see https://lkml.org/lkml/2015/3/5/606

I can't view that link since lkml.org was down earlier today when I was
working online and now I'm working offline.

> kai> Our take was that ALSA is not the right interface for cmt_speech. The
> kai> cmt_speech interface in the modem is _not_ a PCM interface as modelled
> kai> by
> kai> ALSA. Specifically:
> kai>
> kai>- the interface is lossy in both directions

Yay.

> kai>- data is sent in packets, not a stream of samples (could be other
> kai>- things
> kai>   than PCM samples), with timing and meta-data

This is what the copy() operation in the driver is for, there are other
DSP based devices out there as well as things like USB.

> kai>   - timing of uplink is of utmost importance

Well, ALSA doesn't impose any latency of its own so there should be no
issue there - the overheads should be minimal.

> > the drivers for their particular system (and possibly some unfortunate
> > hardware design, it sounds like they may still be bouncing the voice
> > call through the AP which isn't the most wonderful idea ever).
> > There

> Actually, sending data through AP is _very_ good idea from security
> perspective. You don't want hacked baseband to eavesdrop on you, do
> you?

Given that the baseband is a key part of the data path it's not like
you're gaining anything there as far as I can see?   I suppose you could
argue that the AP is actually an additional attack surface here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Fri 2015-07-31 18:52:15, Mark Brown wrote:
> On Fri, Jul 31, 2015 at 02:22:27PM +0200, Pavel Machek wrote:
> > On Wed 2015-07-29 14:32:44, Mark Brown wrote:
> > > On Thu, Jul 23, 2015 at 10:29:02PM +0200, Pavel Machek wrote:
> 
> > > ALSA is the right interface for this, this is going to be some
> > > misunderstanding on their part about how to use it or limitations in
> 
> > That's what I was arguing, but see https://lkml.org/lkml/2015/3/5/606
> 
> I can't view that link since lkml.org was down earlier today when I was
> working online and now I'm working offline.

It works for me now.

> > kai> Our take was that ALSA is not the right interface for cmt_speech. The
> > kai> cmt_speech interface in the modem is _not_ a PCM interface as modelled
> > kai> by
> > kai> ALSA. Specifically:
> > kai>
> > kai>- the interface is lossy in both directions
> 
> Yay.
> 
> > kai>- data is sent in packets, not a stream of samples (could be other
> > kai>- things
> > kai>   than PCM samples), with timing and meta-data
> 
> This is what the copy() operation in the driver is for, there are other
> DSP based devices out there as well as things like USB.
> 
> > kai>   - timing of uplink is of utmost importance
> 
> Well, ALSA doesn't impose any latency of its own so there should be no
> issue there - the overheads should be minimal.

The interface Nokia has is pretty strange. I believe you send
timestamp with buffer, and it means "I'd like this packet of data to
be sent at that time", or something like that.

Anyway, no need to argue with me, I believe ALSA should be suitable.

> > > the drivers for their particular system (and possibly some unfortunate
> > > hardware design, it sounds like they may still be bouncing the voice
> > > call through the AP which isn't the most wonderful idea ever).
> > > There
> 
> > Actually, sending data through AP is _very_ good idea from security
> > perspective. You don't want hacked baseband to eavesdrop on you, do
> > you?
> 
> Given that the baseband is a key part of the data path it's not like
> you're gaining anything there as far as I can see?   I suppose you could
> argue that the AP is actually an additional attack surface here.

Actually yes, I believe I'm gaining a lot.

If baseband is directly connected to the microphone, it can eavesdrop
on me while the phone appears to be idle.

If data is being sent through the AP, yes, it can eavesdrop on calls
(but there are probably easier ways to eavesdrop on calls), but it
won't be able to do something funny when the phone appears to be idle.

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] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown]

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

On Sat, Aug 01, 2015 at 12:03:06AM +0200, Pavel Machek wrote:
> On Fri 2015-07-31 18:52:15, Mark Brown wrote:

> > Given that the baseband is a key part of the data path it's not like
> > you're gaining anything there as far as I can see?   I suppose you could
> > argue that the AP is actually an additional attack surface here.

> Actually yes, I believe I'm gaining a lot.

> If baseband is directly connected to the microphone, it can eavesdrop
> on me while the phone appears to be idle.

Oh, right.  That's not an issue since there's generally routing control
in the rest of the system (within the CODEC and sometimes elsewhere
also) so you can isolate the baseband from the local audio sources and
only connect it in call.  When not in use the CODEC will be powered down
and even when in use by the AP you'd usually not route to the baseband.

The baseband normally doesn't have sufficient physical access to
relevant control interfaces to get any input.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Sat 2015-08-01 11:55:23, Mark Brown wrote:
> On Sat, Aug 01, 2015 at 12:03:06AM +0200, Pavel Machek wrote:
> > On Fri 2015-07-31 18:52:15, Mark Brown wrote:
> 
> > > Given that the baseband is a key part of the data path it's not like
> > > you're gaining anything there as far as I can see?   I suppose you could
> > > argue that the AP is actually an additional attack surface here.
> 
> > Actually yes, I believe I'm gaining a lot.
> 
> > If baseband is directly connected to the microphone, it can eavesdrop
> > on me while the phone appears to be idle.
> 
> Oh, right.  That's not an issue since there's generally routing control
> in the rest of the system (within the CODEC and sometimes elsewhere
> also) so you can isolate the baseband from the local audio sources and
> only connect it in call.  When not in use the CODEC will be powered down
> and even when in use by the AP you'd usually not route to the baseband.
> 
> The baseband normally doesn't have sufficient physical access to
> relevant control interfaces to get any input.

Ok, on many systems you are right, I guess.

That still leaves these reasons to route it though the CPU:

* ability to record calls

* ability to do signal processing on the data, like echo cancel for
  speakerphone (or perhaps changing your voice to female one)

* ability to do advanced stuff like GSM-to-VOIP gateway.

But yes, connecting baseband directly to audio is simpler...

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

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Mark Brown]

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

On Sat, Aug 01, 2015 at 09:03:57PM +0200, Pavel Machek wrote:

> That still leaves these reasons to route it though the CPU:

> * ability to record calls

This is usually done by routing the audio to both the baseband and CPU
simultaneously - this gives you the recording without taking the
latency hit in the call data path which makes life a lot easier.  

It's not that the hardware *can't* route audio to the CPU usually, it's
that call quality is extremely sensitive to any additional latency in
the path and mobile communications are inherently at the high end of
what's acceptable so system designs generally pay attention to ensuring
that no additional latency is introduced (like will tend to happen if
you have a general purpose OS pushing data around, or in general extra
copies).

> * ability to do signal processing on the data, like echo cancel for
>   speakerphone (or perhaps changing your voice to female one)

Right, typically if the system was intended to have these things (I'd be
surprised to see something ship without at least echo cancellation)
there would be some dedicated DSP in the data path implementing them
already.  Some of the applications really need extremely low latency
sample by sample operation which requires a dedicated processor anyway.
This is often part of the baseband, though there can be audio DSPs
elsewhere instead or as well.

> * ability to do advanced stuff like GSM-to-VOIP gateway.

Yes, though that's a completely different use case and is going to have
latency problems anyway.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Tony Lindgren]

* Pavel Machek <pavel@ucw.cz> [150731 15:06]:
> On Fri 2015-07-31 18:52:15, Mark Brown wrote:
> > On Fri, Jul 31, 2015 at 02:22:27PM +0200, Pavel Machek wrote:
> > > On Wed 2015-07-29 14:32:44, Mark Brown wrote:
> > > > On Thu, Jul 23, 2015 at 10:29:02PM +0200, Pavel Machek wrote:
> > 
> > > > ALSA is the right interface for this, this is going to be some
> > > > misunderstanding on their part about how to use it or limitations in
> > 
> > > That's what I was arguing, but see https://lkml.org/lkml/2015/3/5/606
> > 
> > I can't view that link since lkml.org was down earlier today when I was
> > working online and now I'm working offline.
> 
> It works for me now.
> 
> > > kai> Our take was that ALSA is not the right interface for cmt_speech. The
> > > kai> cmt_speech interface in the modem is _not_ a PCM interface as modelled
> > > kai> by
> > > kai> ALSA. Specifically:
> > > kai>
> > > kai>- the interface is lossy in both directions
> > 
> > Yay.

Well at the point when the audio gets played out of the speaker it's
a stream :) I think the issues above are related to reading raw data
from the modem before it gets processed further for noise cancellation
by the DSP and so on. Eventually it should be just audio stream though.

> > > kai>- data is sent in packets, not a stream of samples (could be other
> > > kai>- things
> > > kai>   than PCM samples), with timing and meta-data
> > 
> > This is what the copy() operation in the driver is for, there are other
> > DSP based devices out there as well as things like USB.
> > 
> > > kai>   - timing of uplink is of utmost importance
> > 
> > Well, ALSA doesn't impose any latency of its own so there should be no
> > issue there - the overheads should be minimal.

I believe the fact that that ALSA fifo size could not be changed
dynamically between what the modem needs and what should be used for
audio playback from PM point of view used to be a problem. Maybe
that's already fixed, now I don't know. Just FYI.
 
> The interface Nokia has is pretty strange. I believe you send
> timestamp with buffer, and it means "I'd like this packet of data to
> be sent at that time", or something like that.
> 
> Anyway, no need to argue with me, I believe ALSA should be suitable.

Yes ALSA is suitable for sure. It's the raw modem data to audio
stream processing part that's weird but that's not ALSA's problem.

Regards,

Tony

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Krzysztof Kozlowski]

2015-07-23 21:14 GMT+09:00 Pavel Machek <pavel@ucw.cz>:
> On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
>> On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>
>> > Significant percentage of phones run Linux kernel today, but geting
>> > mainline kernel to work on a phone is very hard to do. (So hard, that
>> > newest device that is close to working on recent mainline was made in
>> > 2009.) There are multiple obstacles, including huge patches from
>> > silicon vendors, missing GNU/Linux userspace support that makes kernel
>> > testing hard, interfaces unsuitable for phones and power management
>> > problems.
>> >
>> > Interested people:
>> >
>> > Sebastian Reichel <sre@kernel.org>
>> > Pali Rohár <pali.rohar@gmail.com>
>>
>> I'm adding Björn Andersson <bjorn.andersson@sonymobile.com> to this list.
>>
>> Björn has as of yesterday booted a mainline kernel on the SONY
>> Xperia Z3 and his company has demonstrated strong interest in
>> getting the mainline kernel to run on their handsets.
>> https://plus.google.com/102276447148493441479/posts/amRvpE8piSw
>
> Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-December/078428.html
>
> Signed-off-by: HeungJun, Kim <riverful.kim at samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

Interesting topic also for me. We were (and still are) spending
significant effort so Trats (~Galaxy S 2 for Tizen) and Trats2 devices
(Galaxy S III released for Tizen) would be fully supported by
mainline. The same we did more recently for Gear 2 smartwatch.
Although it is not a cellphone but fits to a mobile device category.

Standard Debian works fine on them. With a mobile operating system -
like Tizen - it gets more difficult.

Most of the drivers are there but few important SoC components are
missing (for example camera for Gear 2). One of the obstacles here was
lack of public firmware which prevented mainlining some of the drivers
(e.g. FIMC - the camera).

Best regards,
Krzysztof

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Thu 2015-07-23 22:23:53, Krzysztof Kozlowski wrote:
> 2015-07-23 21:14 GMT+09:00 Pavel Machek <pavel@ucw.cz>:
> > On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
> >> On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
> >> I'm adding Björn Andersson <bjorn.andersson@sonymobile.com> to this list.
> >>
> >> Björn has as of yesterday booted a mainline kernel on the SONY
> >> Xperia Z3 and his company has demonstrated strong interest in
> >> getting the mainline kernel to run on their handsets.
> >> https://plus.google.com/102276447148493441479/posts/amRvpE8piSw
> >
> > Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.
> >
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2011-December/078428.html
> >
> > Signed-off-by: HeungJun, Kim <riverful.kim at samsung.com>
> > Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
> 
> Interesting topic also for me. We were (and still are) spending
> significant effort so Trats (~Galaxy S 2 for Tizen) and Trats2 devices
> (Galaxy S III released for Tizen) would be fully supported by
> mainline. The same we did more recently for Gear 2 smartwatch.
> Although it is not a cellphone but fits to a mobile device category.

Can I get Galaxy S III and use mainline or that? If not... can I get
Trats or Trats2 device somehow?

> Standard Debian works fine on them. With a mobile operating system -
> like Tizen - it gets more difficult.

What do you use for desktop in Debian? I'm using MATE on n900, and it
is almost usable. I have cellular calls working (but audio quality is
awful). But MATE is so usable thanks to n900's keyboard and
stylus... (and I'm still searching for web browser that works within
256MB ram).

> Most of the drivers are there but few important SoC components are
> missing (for example camera for Gear 2). One of the obstacles here was
> lack of public firmware which prevented mainlining some of the drivers
> (e.g. FIMC - the camera).

You mean.. there is not even redistributable firmware binary?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Krzysztof Kozlowski]

On 24.07.2015 06:56, Pavel Machek wrote:
> On Thu 2015-07-23 22:23:53, Krzysztof Kozlowski wrote:
>> 2015-07-23 21:14 GMT+09:00 Pavel Machek <pavel@ucw.cz>:
>>> On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
>>>> On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>>> I'm adding Björn Andersson <bjorn.andersson@sonymobile.com> to this list.
>>>>
>>>> Björn has as of yesterday booted a mainline kernel on the SONY
>>>> Xperia Z3 and his company has demonstrated strong interest in
>>>> getting the mainline kernel to run on their handsets.
>>>> https://plus.google.com/102276447148493441479/posts/amRvpE8piSw
>>>
>>> Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-December/078428.html
>>>
>>> Signed-off-by: HeungJun, Kim <riverful.kim at samsung.com>
>>> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>
>>
>> Interesting topic also for me. We were (and still are) spending
>> significant effort so Trats (~Galaxy S 2 for Tizen) and Trats2 devices
>> (Galaxy S III released for Tizen) would be fully supported by
>> mainline. The same we did more recently for Gear 2 smartwatch.
>> Although it is not a cellphone but fits to a mobile device category.
> 
> Can I get Galaxy S III and use mainline or that? If not... can I get
> Trats or Trats2 device somehow?

(--riverful.kim@samsung.com, email bounces)

You can try with Galaxy S III after uploading mainline uboot.
Essentially this is exactly the same device as Trats2 so everything
should work... but debugging would be hard if you don't have the Anyway JIG.

If anything goes wrong then maybe you could restore original image... or
not. :)

The Trats devices were given to developers during Tizen Developer
Conferences and some time after. I remember that some division in
Samsung America was providing these to individual application developers
few years ago. I don't think they do now.

Anyway Samsung was releasing (and was giving away) new devices on each
Tizen Developer Conference. Last year it was Gear 2:
https://www.tizen.org/ko/events/tizen-developer-conference/2014/great-tizen-developer-conference-2014-giveaway-gear2-nuc

This year the conference is in China:
https://www.tizen.org/ko/events/tizen-developer-conference/2015


> 
>> Standard Debian works fine on them. With a mobile operating system -
>> like Tizen - it gets more difficult.
> 
> What do you use for desktop in Debian? I'm using MATE on n900, and it
> is almost usable. I have cellular calls working (but audio quality is
> awful). But MATE is so usable thanks to n900's keyboard and
> stylus... (and I'm still searching for web browser that works within
> 256MB ram).

The Debian was chosen for a testing platform. It is not a usable phone
with Debian but a usable 4-core device :) .

> 
>> Most of the drivers are there but few important SoC components are
>> missing (for example camera for Gear 2). One of the obstacles here was
>> lack of public firmware which prevented mainlining some of the drivers
>> (e.g. FIMC - the camera).
> 
> You mean.. there is not even redistributable firmware binary?

There was a reluctance on LKML to accept camera drivers without
releasing the firmware. Samsung never released the firmware on any
website however you can download it from the device and find it on
unofficial website:
www.sammobile.com/firmwares
(this website is not related to Samsung)

Some drivers were not even upstreamed (like touchscreen driver for
Gear2) but you can find the sources on vendor's site or on tizen.org.
Again you will have to get the firmware from unofficial site or from
device image directly (maybe here:
https://download.tizen.org/snapshots/tizen/mobile/latest/images ?)

Best regards,
Krzysztof

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Kyungmin Park]

On Thu, Jul 23, 2015 at 10:23 PM, Krzysztof Kozlowski
<k.kozlowski@samsung.com> wrote:
> 2015-07-23 21:14 GMT+09:00 Pavel Machek <pavel@ucw.cz>:
>> On Thu 2015-07-23 13:21:19, Linus Walleij wrote:
>>> On Thu, Jul 23, 2015 at 12:57 PM, Pavel Machek <pavel@ucw.cz> wrote:
>>>
>>> > Significant percentage of phones run Linux kernel today, but geting
>>> > mainline kernel to work on a phone is very hard to do. (So hard, that
>>> > newest device that is close to working on recent mainline was made in
>>> > 2009.) There are multiple obstacles, including huge patches from
>>> > silicon vendors, missing GNU/Linux userspace support that makes kernel
>>> > testing hard, interfaces unsuitable for phones and power management
>>> > problems.
>>> >
>>> > Interested people:
>>> >
>>> > Sebastian Reichel <sre@kernel.org>
>>> > Pali Rohár <pali.rohar@gmail.com>
>>>
>>> I'm adding Björn Andersson <bjorn.andersson@sonymobile.com> to this list.
>>>
>>> Björn has as of yesterday booted a mainline kernel on the SONY
>>> Xperia Z3 and his company has demonstrated strong interest in
>>> getting the mainline kernel to run on their handsets.
>>> https://plus.google.com/102276447148493441479/posts/amRvpE8piSw
>>
>> Yes. Plus, there seems to be group at Samsung. Trats is a cellphone iirc.
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2011-December/078428.html
>>
>> Signed-off-by: HeungJun, Kim <riverful.kim at samsung.com>
>> Signed-off-by: Kyungmin Park <kyungmin.park at samsung.com>

Already Krzysztof mentioned. Our team tried to support mainline kernel
for product and it's still on-going.
see gear 2 support with exysno3250.

I'm interested in this topic. Moreover KS is held at Korea. so It's
good chance to attend and discuss this topic.

Thank you,
Kyungmin Park
>
> Interesting topic also for me. We were (and still are) spending
> significant effort so Trats (~Galaxy S 2 for Tizen) and Trats2 devices
> (Galaxy S III released for Tizen) would be fully supported by
> mainline. The same we did more recently for Gear 2 smartwatch.
> Although it is not a cellphone but fits to a mobile device category.
>
> Standard Debian works fine on them. With a mobile operating system -
> like Tizen - it gets more difficult.
>
> Most of the drivers are there but few important SoC components are
> missing (for example camera for Gear 2). One of the obstacles here was
> lack of public firmware which prevented mainlining some of the drivers
> (e.g. FIMC - the camera).
>
> Best regards,
> Krzysztof
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Shuah Khan]

On Thu, Jul 23, 2015 at 4:57 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> (Please cc me on replies).
>
> Significant percentage of phones run Linux kernel today, but geting
> mainline kernel to work on a phone is very hard to do. (So hard, that
> newest device that is close to working on recent mainline was made in
> 2009.) There are multiple obstacles, including huge patches from
> silicon vendors, missing GNU/Linux userspace support that makes kernel
> testing hard, interfaces unsuitable for phones and power management
> problems.
>
> Interested people:
>
> Sebastian Reichel <sre@kernel.org>
> Pali Rohár <pali.rohar@gmail.com>
>

I am interested in this topic. Please add me to the list.

Shuah Khan <shuahkh@osg.samsung.com>

You probably already know
the CE Workgroup Device Mainlining Project. Goes over some of the reasons why
mainline kernels don't run on phones. Adding Tim Bird to the thread.
He did a talk
at ELC back in March of this year about this effort and more information.

http://elinux.org/CE_Workgroup_Device_Mainlining_Project

Very often phone vendors have to make decisions to get the product out
and they might not have the resources to upstream and ensure upstream
kernels continue to run on their devices.

thanks,
-- Shuah

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Heiko Stübner]

Am Donnerstag, 23. Juli 2015, 12:57:26 schrieb Pavel Machek:
> Significant percentage of phones run Linux kernel today, but geting
> mainline kernel to work on a phone is very hard to do. (So hard, that
> newest device that is close to working on recent mainline was made in
> 2009.) There are multiple obstacles, including huge patches from
> silicon vendors, missing GNU/Linux userspace support that makes kernel
> testing hard, interfaces unsuitable for phones and power management
> problems.

>From work I know some MSM8916 phones which came to market over half a year ago 
ad just now seem to get basic clock support in mainline.

But I guess the problem is not limited to cellphones but to all mobile 
consumer electronics, where the development model is based on hacking on some 
fork of an old kernel.


But I do think the ChromeOS people do quite a lot things right in terms of 
development model, as I can run a Debian (including 3d-acceleration) on the 
just released Rockchip Chromebooks with only a minimal number of additional 
patches against 4.2-rc ;-)


> Interested people:
> 
> Sebastian Reichel <sre@kernel.org>
> Pali Rohár <pali.rohar@gmail.com>

The Openmoko Freerunner brought me into the embedded world in the first place, 
so I'd definitly be interested ;-)

Heiko Stuebner <heiko@sntech.de>

Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone

[Pavel Machek]

On Thu 2015-07-23 12:57:26, Pavel Machek wrote:
> Hi!
> 
> (Please cc me on replies).
> 
> Significant percentage of phones run Linux kernel today, but geting
> mainline kernel to work on a phone is very hard to do. (So hard, that
> newest device that is close to working on recent mainline was made in
> 2009.) There are multiple obstacles, including huge patches from
> silicon vendors, missing GNU/Linux userspace support that makes kernel
> testing hard, interfaces unsuitable for phones and power management
> problems.

I'd like to nominate myself for this topic (and the FPGA topic, but I
guess Alan is more suitable there).

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] [CORE TOPIC] Mainline kernel on a cellphone

[Bintian]

On 2015/8/5 3:39, Pavel Machek wrote:
> On Thu 2015-07-23 12:57:26, Pavel Machek wrote:
>> Hi!
>>
>> (Please cc me on replies).
>>
>> Significant percentage of phones run Linux kernel today, but geting
>> mainline kernel to work on a phone is very hard to do. (So hard, that
>> newest device that is close to working on recent mainline was made in
>> 2009.) There are multiple obstacles, including huge patches from
>> silicon vendors, missing GNU/Linux userspace support that makes kernel
>> testing hard, interfaces unsuitable for phones and power management
>> problems.
> I'd like to nominate myself for this topic (and the FPGA topic, but I
> guess Alan is more suitable there).
>
> Best regards,									Pavel
I 'd like to nominate myself for this topic.

Thanks and Best regards,