* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-28 22:09 ` Tim Bird
@ 2015-07-28 23:07 ` Bjorn Andersson
2015-07-31 16:18 ` Rob Herring
2015-07-29 0:45 ` Krzysztof Kozlowski
` (3 subsequent siblings)
4 siblings, 1 reply; 84+ messages in thread
From: Bjorn Andersson @ 2015-07-28 23:07 UTC (permalink / raw)
To: Tim Bird
Cc: ksummit-discuss, riverful.kim, kyungmin.park, John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-28 23:07 ` Bjorn Andersson
@ 2015-07-31 16:18 ` Rob Herring
2015-07-31 16:56 ` Bjorn Andersson
` (2 more replies)
0 siblings, 3 replies; 84+ messages in thread
From: Rob Herring @ 2015-07-31 16:18 UTC (permalink / raw)
To: Bjorn Andersson
Cc: ksummit-discuss, riverful.kim, kyungmin.park, John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-31 16:18 ` Rob Herring
@ 2015-07-31 16:56 ` Bjorn Andersson
2015-08-11 9:34 ` Johannes Berg
2015-07-31 17:25 ` Tim Bird
2015-08-03 7:42 ` Linus Walleij
2 siblings, 1 reply; 84+ messages in thread
From: Bjorn Andersson @ 2015-07-31 16:56 UTC (permalink / raw)
To: Rob Herring
Cc: ksummit-discuss, riverful.kim, kyungmin.park, John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-31 16:56 ` Bjorn Andersson
@ 2015-08-11 9:34 ` Johannes Berg
0 siblings, 0 replies; 84+ messages in thread
From: Johannes Berg @ 2015-08-11 9:34 UTC (permalink / raw)
To: Bjorn Andersson, Rob Herring
Cc: riverful.kim, kyungmin.park, John Stultz, Pavel Machek, ksummit-discuss
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-31 16:18 ` Rob Herring
2015-07-31 16:56 ` Bjorn Andersson
@ 2015-07-31 17:25 ` Tim Bird
2015-08-03 15:29 ` John W. Linville
2015-08-03 7:42 ` Linus Walleij
2 siblings, 1 reply; 84+ messages in thread
From: Tim Bird @ 2015-07-31 17:25 UTC (permalink / raw)
To: Rob Herring, "Andersson, Björn"
Cc: riverful.kim, kyungmin.park, John Stultz, Pavel Machek, ksummit-discuss
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-31 17:25 ` Tim Bird
@ 2015-08-03 15:29 ` John W. Linville
0 siblings, 0 replies; 84+ messages in thread
From: John W. Linville @ 2015-08-03 15:29 UTC (permalink / raw)
To: Tim Bird
Cc: "Andersson, Björn",
ksummit-discuss, riverful.kim, kyungmin.park, John Stultz,
Pavel Machek
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.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-31 16:18 ` Rob Herring
2015-07-31 16:56 ` Bjorn Andersson
2015-07-31 17:25 ` Tim Bird
@ 2015-08-03 7:42 ` Linus Walleij
2015-08-03 21:34 ` Rob Herring
2 siblings, 1 reply; 84+ messages in thread
From: Linus Walleij @ 2015-08-03 7:42 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Pavel Machek, Greg KH
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-03 7:42 ` Linus Walleij
@ 2015-08-03 21:34 ` Rob Herring
2015-08-03 22:36 ` Marcel Holtmann
0 siblings, 1 reply; 84+ messages in thread
From: Rob Herring @ 2015-08-03 21:34 UTC (permalink / raw)
To: Linus Walleij
Cc: Bjorn Andersson, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Pavel Machek, Greg KH
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/
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-03 21:34 ` Rob Herring
@ 2015-08-03 22:36 ` Marcel Holtmann
2015-08-05 8:40 ` Linus Walleij
2015-08-05 16:02 ` Rob Herring
0 siblings, 2 replies; 84+ messages in thread
From: Marcel Holtmann @ 2015-08-03 22:36 UTC (permalink / raw)
To: Rob Herring
Cc: Pavel Machek, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Bjorn Andersson, Greg KH
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-03 22:36 ` Marcel Holtmann
@ 2015-08-05 8:40 ` Linus Walleij
2015-08-05 8:46 ` Linus Walleij
` (2 more replies)
2015-08-05 16:02 ` Rob Herring
1 sibling, 3 replies; 84+ messages in thread
From: Linus Walleij @ 2015-08-05 8:40 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Pavel Machek, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Bjorn Andersson, Greg KH
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-05 8:40 ` Linus Walleij
@ 2015-08-05 8:46 ` Linus Walleij
2015-08-05 9:11 ` Samuel Ortiz
2015-08-05 11:54 ` Pavel Machek
2015-08-05 9:09 ` Samuel Ortiz
2015-08-05 17:19 ` Marcel Holtmann
2 siblings, 2 replies; 84+ messages in thread
From: Linus Walleij @ 2015-08-05 8:46 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Pavel Machek, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Bjorn Andersson, Greg KH
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-05 8:46 ` Linus Walleij
@ 2015-08-05 9:11 ` Samuel Ortiz
2015-08-05 11:54 ` Pavel Machek
1 sibling, 0 replies; 84+ messages in thread
From: Samuel Ortiz @ 2015-08-05 9:11 UTC (permalink / raw)
To: Linus Walleij
Cc: Bjorn Andersson, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Pavel Machek, Greg KH
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.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-05 8:46 ` Linus Walleij
2015-08-05 9:11 ` Samuel Ortiz
@ 2015-08-05 11:54 ` Pavel Machek
1 sibling, 0 replies; 84+ messages in thread
From: Pavel Machek @ 2015-08-05 11:54 UTC (permalink / raw)
To: Linus Walleij
Cc: ksummit-discuss, riverful.kim, kyungmin.park, Bjorn Andersson,
Greg KH, John Stultz
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-05 8:40 ` Linus Walleij
2015-08-05 8:46 ` Linus Walleij
@ 2015-08-05 9:09 ` Samuel Ortiz
2015-08-05 17:19 ` Marcel Holtmann
2 siblings, 0 replies; 84+ messages in thread
From: Samuel Ortiz @ 2015-08-05 9:09 UTC (permalink / raw)
To: Linus Walleij
Cc: Bjorn Andersson, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Pavel Machek, Greg KH
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.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-05 8:40 ` Linus Walleij
2015-08-05 8:46 ` Linus Walleij
2015-08-05 9:09 ` Samuel Ortiz
@ 2015-08-05 17:19 ` Marcel Holtmann
2 siblings, 0 replies; 84+ messages in thread
From: Marcel Holtmann @ 2015-08-05 17:19 UTC (permalink / raw)
To: Linus Walleij
Cc: Pavel Machek, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, Bjorn Andersson, Greg KH
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-03 22:36 ` Marcel Holtmann
2015-08-05 8:40 ` Linus Walleij
@ 2015-08-05 16:02 ` Rob Herring
2015-08-05 17:00 ` Marcel Holtmann
1 sibling, 1 reply; 84+ messages in thread
From: Rob Herring @ 2015-08-05 16:02 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Bjorn Andersson, ksummit-discuss, Greg KH, kyungmin.park,
John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-05 16:02 ` Rob Herring
@ 2015-08-05 17:00 ` Marcel Holtmann
2015-08-07 12:40 ` Linus Walleij
0 siblings, 1 reply; 84+ messages in thread
From: Marcel Holtmann @ 2015-08-05 17:00 UTC (permalink / raw)
To: Rob Herring
Cc: Bjorn Andersson, ksummit-discuss, Greg KH, kyungmin.park,
John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-05 17:00 ` Marcel Holtmann
@ 2015-08-07 12:40 ` Linus Walleij
0 siblings, 0 replies; 84+ messages in thread
From: Linus Walleij @ 2015-08-07 12:40 UTC (permalink / raw)
To: Marcel Holtmann, Ulf Hansson
Cc: Bjorn Andersson, ksummit-discuss, Greg KH, kyungmin.park,
John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-28 22:09 ` Tim Bird
2015-07-28 23:07 ` Bjorn Andersson
@ 2015-07-29 0:45 ` Krzysztof Kozlowski
2015-07-29 6:12 ` Laurent Pinchart
` (2 more replies)
2015-07-29 0:56 ` Rafael J. Wysocki
` (2 subsequent siblings)
4 siblings, 3 replies; 84+ messages in thread
From: Krzysztof Kozlowski @ 2015-07-29 0:45 UTC (permalink / raw)
To: Tim Bird, Mark Brown, Steven Rostedt
Cc: kyungmin.park, "Andersson, Björn",
John Stultz, ksummit-discuss, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-29 0:45 ` Krzysztof Kozlowski
@ 2015-07-29 6:12 ` Laurent Pinchart
2015-07-29 7:40 ` Pavel Machek
2015-07-29 8:18 ` Heiko Stübner
2 siblings, 0 replies; 84+ messages in thread
From: Laurent Pinchart @ 2015-07-29 6:12 UTC (permalink / raw)
To: ksummit-discuss
Cc: Pavel Machek, kyungmin.park, John Stultz, Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-29 0:45 ` Krzysztof Kozlowski
2015-07-29 6:12 ` Laurent Pinchart
@ 2015-07-29 7:40 ` Pavel Machek
2015-08-25 18:59 ` Tim Bird
2015-07-29 8:18 ` Heiko Stübner
2 siblings, 1 reply; 84+ messages in thread
From: Pavel Machek @ 2015-07-29 7:40 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: ksummit-discuss, kyungmin.park, John Stultz, "Andersson,
Björn"
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-29 7:40 ` Pavel Machek
@ 2015-08-25 18:59 ` Tim Bird
2015-08-26 1:22 ` Krzysztof Kozlowski
0 siblings, 1 reply; 84+ messages in thread
From: Tim Bird @ 2015-08-25 18:59 UTC (permalink / raw)
To: Pavel Machek, Krzysztof Kozlowski
Cc: ksummit-discuss, kyungmin.park, John Stultz, "Andersson,
Björn"
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-25 18:59 ` Tim Bird
@ 2015-08-26 1:22 ` Krzysztof Kozlowski
2015-08-26 4:25 ` Sudip Mukherjee
` (2 more replies)
0 siblings, 3 replies; 84+ messages in thread
From: Krzysztof Kozlowski @ 2015-08-26 1:22 UTC (permalink / raw)
To: Tim Bird, Pavel Machek
Cc: ksummit-discuss, kyungmin.park, John Stultz, Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 1:22 ` Krzysztof Kozlowski
@ 2015-08-26 4:25 ` Sudip Mukherjee
2015-08-26 4:52 ` Krzysztof Kozlowski
2015-08-26 11:33 ` Mark Brown
2015-08-26 12:56 ` Jason Cooper
2 siblings, 1 reply; 84+ messages in thread
From: Sudip Mukherjee @ 2015-08-26 4:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Pavel Machek, ksummit-discuss, kyungmin.park, John Stultz,
Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 4:25 ` Sudip Mukherjee
@ 2015-08-26 4:52 ` Krzysztof Kozlowski
2015-08-26 5:30 ` Laurent Pinchart
0 siblings, 1 reply; 84+ messages in thread
From: Krzysztof Kozlowski @ 2015-08-26 4:52 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Pavel Machek, ksummit-discuss, kyungmin.park, John Stultz,
Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 4:52 ` Krzysztof Kozlowski
@ 2015-08-26 5:30 ` Laurent Pinchart
2015-08-26 5:33 ` Krzysztof Kozlowski
0 siblings, 1 reply; 84+ messages in thread
From: Laurent Pinchart @ 2015-08-26 5:30 UTC (permalink / raw)
To: ksummit-discuss
Cc: Pavel Machek, kyungmin.park, John Stultz, Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 5:30 ` Laurent Pinchart
@ 2015-08-26 5:33 ` Krzysztof Kozlowski
2015-08-26 6:15 ` Josh Triplett
0 siblings, 1 reply; 84+ messages in thread
From: Krzysztof Kozlowski @ 2015-08-26 5:33 UTC (permalink / raw)
To: Laurent Pinchart, ksummit-discuss
Cc: kyungmin.park, Andersson, Björn, John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 5:33 ` Krzysztof Kozlowski
@ 2015-08-26 6:15 ` Josh Triplett
2015-08-26 7:23 ` Heiko Stuebner
0 siblings, 1 reply; 84+ messages in thread
From: Josh Triplett @ 2015-08-26 6:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andersson, Björn, ksummit-discuss, kyungmin.park,
John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 6:15 ` Josh Triplett
@ 2015-08-26 7:23 ` Heiko Stuebner
2015-08-26 8:05 ` Krzysztof Kozlowski
0 siblings, 1 reply; 84+ messages in thread
From: Heiko Stuebner @ 2015-08-26 7:23 UTC (permalink / raw)
To: ksummit-discuss
Cc: Andersson, Björn, kyungmin.park, John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 7:23 ` Heiko Stuebner
@ 2015-08-26 8:05 ` Krzysztof Kozlowski
2015-08-28 8:20 ` Nicolas Ferre
0 siblings, 1 reply; 84+ messages in thread
From: Krzysztof Kozlowski @ 2015-08-26 8:05 UTC (permalink / raw)
To: Heiko Stuebner, ksummit-discuss
Cc: Pavel Machek, kyungmin.park, John Stultz, Andersson, Björn
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
>
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 8:05 ` Krzysztof Kozlowski
@ 2015-08-28 8:20 ` Nicolas Ferre
0 siblings, 0 replies; 84+ messages in thread
From: Nicolas Ferre @ 2015-08-28 8:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Heiko Stuebner, ksummit-discuss
Cc: kyungmin.park, John Stultz, Andersson, Björn, Pavel Machek
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)
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 1:22 ` Krzysztof Kozlowski
2015-08-26 4:25 ` Sudip Mukherjee
@ 2015-08-26 11:33 ` Mark Brown
2015-08-26 12:56 ` Jason Cooper
2 siblings, 0 replies; 84+ messages in thread
From: Mark Brown @ 2015-08-26 11:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andersson, Björn, ksummit-discuss, kyungmin.park,
John Stultz, Pavel Machek
[-- 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 --]
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 1:22 ` Krzysztof Kozlowski
2015-08-26 4:25 ` Sudip Mukherjee
2015-08-26 11:33 ` Mark Brown
@ 2015-08-26 12:56 ` Jason Cooper
2015-08-26 13:35 ` Geert Uytterhoeven
2015-08-26 13:58 ` Sudip Mukherjee
2 siblings, 2 replies; 84+ messages in thread
From: Jason Cooper @ 2015-08-26 12:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Pavel Machek, ksummit-discuss, kyungmin.park, John Stultz,
Andersson, Björn
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.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 12:56 ` Jason Cooper
@ 2015-08-26 13:35 ` Geert Uytterhoeven
2015-08-26 13:58 ` Sudip Mukherjee
1 sibling, 0 replies; 84+ messages in thread
From: Geert Uytterhoeven @ 2015-08-26 13:35 UTC (permalink / raw)
To: Jason Cooper
Cc: Pavel Machek, ksummit-discuss, kyungmin.park, John Stultz,
Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 12:56 ` Jason Cooper
2015-08-26 13:35 ` Geert Uytterhoeven
@ 2015-08-26 13:58 ` Sudip Mukherjee
2015-08-26 14:51 ` Jason Cooper
1 sibling, 1 reply; 84+ messages in thread
From: Sudip Mukherjee @ 2015-08-26 13:58 UTC (permalink / raw)
To: Jason Cooper
Cc: Pavel Machek, ksummit-discuss, kyungmin.park, John Stultz,
Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 13:58 ` Sudip Mukherjee
@ 2015-08-26 14:51 ` Jason Cooper
2015-08-26 17:13 ` Sudip Mukherjee
0 siblings, 1 reply; 84+ messages in thread
From: Jason Cooper @ 2015-08-26 14:51 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: kyungmin.park, Andersson, Björn, John Stultz,
ksummit-discuss, Pavel Machek
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.
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 14:51 ` Jason Cooper
@ 2015-08-26 17:13 ` Sudip Mukherjee
2015-08-26 20:09 ` Greg Kroah-Hartman
0 siblings, 1 reply; 84+ messages in thread
From: Sudip Mukherjee @ 2015-08-26 17:13 UTC (permalink / raw)
To: Jason Cooper, Greg Kroah-Hartman
Cc: kyungmin.park, Andersson, Björn, John Stultz,
ksummit-discuss, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 17:13 ` Sudip Mukherjee
@ 2015-08-26 20:09 ` Greg Kroah-Hartman
2015-08-28 7:44 ` Pavel Machek
0 siblings, 1 reply; 84+ messages in thread
From: Greg Kroah-Hartman @ 2015-08-26 20:09 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Jason Cooper, ksummit-discuss, Pavel Machek, kyungmin.park,
John Stultz, Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-26 20:09 ` Greg Kroah-Hartman
@ 2015-08-28 7:44 ` Pavel Machek
2015-08-28 8:42 ` Heiko Stuebner
0 siblings, 1 reply; 84+ messages in thread
From: Pavel Machek @ 2015-08-28 7:44 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jason Cooper, ksummit-discuss, kyungmin.park, John Stultz,
Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-28 7:44 ` Pavel Machek
@ 2015-08-28 8:42 ` Heiko Stuebner
2015-08-29 15:47 ` Sudip Mukherjee
0 siblings, 1 reply; 84+ messages in thread
From: Heiko Stuebner @ 2015-08-28 8:42 UTC (permalink / raw)
To: ksummit-discuss
Cc: Jason Cooper, Greg Kroah-Hartman, Pavel Machek, kyungmin.park,
John Stultz, Andersson, Björn
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-08-28 8:42 ` Heiko Stuebner
@ 2015-08-29 15:47 ` Sudip Mukherjee
0 siblings, 0 replies; 84+ messages in thread
From: Sudip Mukherjee @ 2015-08-29 15:47 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Jason Cooper, ksummit-discuss, Greg Kroah-Hartman, Andersson,
Björn, kyungmin.park, John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-29 0:45 ` Krzysztof Kozlowski
2015-07-29 6:12 ` Laurent Pinchart
2015-07-29 7:40 ` Pavel Machek
@ 2015-07-29 8:18 ` Heiko Stübner
2 siblings, 0 replies; 84+ messages in thread
From: Heiko Stübner @ 2015-07-29 8:18 UTC (permalink / raw)
To: ksummit-discuss
Cc: Pavel Machek, kyungmin.park, John Stultz, Andersson, Björn
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]
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-28 22:09 ` Tim Bird
2015-07-28 23:07 ` Bjorn Andersson
2015-07-29 0:45 ` Krzysztof Kozlowski
@ 2015-07-29 0:56 ` Rafael J. Wysocki
2015-07-29 6:43 ` Daniel Vetter
2015-07-29 7:14 ` Bintian
4 siblings, 0 replies; 84+ messages in thread
From: Rafael J. Wysocki @ 2015-07-29 0:56 UTC (permalink / raw)
To: ksummit-discuss
Cc: Andersson, Björn, riverful.kim, kyungmin.park, John Stultz,
Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-28 22:09 ` Tim Bird
` (2 preceding siblings ...)
2015-07-29 0:56 ` Rafael J. Wysocki
@ 2015-07-29 6:43 ` Daniel Vetter
2015-07-29 17:42 ` Tim Bird
2015-07-29 7:14 ` Bintian
4 siblings, 1 reply; 84+ messages in thread
From: Daniel Vetter @ 2015-07-29 6:43 UTC (permalink / raw)
To: Tim Bird
Cc: Andersson, Björn, ksummit-discuss, riverful.kim,
kyungmin.park, John Stultz, Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-29 6:43 ` Daniel Vetter
@ 2015-07-29 17:42 ` Tim Bird
0 siblings, 0 replies; 84+ messages in thread
From: Tim Bird @ 2015-07-29 17:42 UTC (permalink / raw)
To: Daniel Vetter
Cc: "Andersson, Björn",
ksummit-discuss, riverful.kim, kyungmin.park, John Stultz,
Pavel Machek
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-28 22:09 ` Tim Bird
` (3 preceding siblings ...)
2015-07-29 6:43 ` Daniel Vetter
@ 2015-07-29 7:14 ` Bintian
2015-07-29 18:07 ` Tim Bird
4 siblings, 1 reply; 84+ messages in thread
From: Bintian @ 2015-07-29 7:14 UTC (permalink / raw)
To: Tim Bird, Mark Brown, Steven Rostedt
Cc: Pavel Machek, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, "Andersson, Björn"
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
>
> .
>
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-29 7:14 ` Bintian
@ 2015-07-29 18:07 ` Tim Bird
2015-07-31 1:50 ` Bintian
0 siblings, 1 reply; 84+ messages in thread
From: Tim Bird @ 2015-07-29 18:07 UTC (permalink / raw)
To: Bintian, Mark Brown, Steven Rostedt
Cc: Pavel Machek, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, "Andersson, Björn"
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
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: [Ksummit-discuss] [CORE TOPIC] Mainline kernel on a cellphone
2015-07-29 18:07 ` Tim Bird
@ 2015-07-31 1:50 ` Bintian
0 siblings, 0 replies; 84+ messages in thread
From: Bintian @ 2015-07-31 1:50 UTC (permalink / raw)
To: Tim Bird, Mark Brown, Steven Rostedt
Cc: Pavel Machek, ksummit-discuss, riverful.kim, kyungmin.park,
John Stultz, "Andersson, Björn"
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
>
>
> .
>
^ permalink raw reply [flat|nested] 84+ messages in thread