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

Nicolas Ferre nicolas.ferre at atmel.com
Fri Aug 28 08:20:52 UTC 2015


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)


More information about the Ksummit-discuss mailing list