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

[Heiko Stuebner <heiko@sntech.de>]

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