[Pkg-Mali-devel] Debian mali pckaging status

Wed Jul 18 13:28:53 BST 2018

On 18/07/18 12:08, Sumit Garg wrote:
> Hi Guillaume,
> 
> On Wed, 18 Jul 2018 at 12:57, Guillaume Tucker
> <guillaume.tucker at collabora.com> wrote:
>>
>> Hi Sumit,
>>
>> On 18/07/18 05:26, Sumit Garg wrote:
>>> Hi Wookey,
>>>
>>> On Tue, 3 Jul 2018 at 11:15, Sumit Garg <sumit.garg at linaro.org> wrote:
>>>>
>>>> On Thu, 28 Jun 2018 at 21:54, Wookey <wookey at wookware.org> wrote:
>>>>>
>>>>> OK. Welcome to the (currently quite exclusive) list :-)
>>>>>
>>>>> Let's start with the current status and what needs doing next.
>>>>>
>>>>> We have
>>>>>    * a midgard dkms kernel package (r16-midgard): mali-midgard
>>>>>    * a midgard binary package (r16-midgard): mali-midgard-driver
>>>>> Both in debian
>>>>>    * a bifrost binary package (r9-bifrost): mali-bifrost-driver
>>>>>    (only in git):
>>>>>
>>>>>    * utgard is not really catered for, but there is nothing stopping us
>>>>>      packing up the mali 400 (From freeelectons/allwinner) and 450 (from
>>>>>      arm) driver, and making a suitbaly vintage mali-utgard kernel driver
>>>>>      (but probably with a load of patches to make it build on current kernels)
>>>>>      In fact I have a mali-utgard-driver package (for 450 only) I made ages ago.
>>>>>      I should check that in so we can make it match the others.
>>>>>
>>>>> Wiki pages:
>>>>> https://wiki.debian.org/MaliGraphics
>>>>> https://wiki.debian.org/MaliMidgard
>>>>>
>>>>> Looks like r16-midgard is the same release as r4-bifrost.
>>>>>
>>>>> The r16-midgard dkms package now builds on armhf (firefly) and arm64
>>>>> (hilkey960), but does not build for me on arm64 (softiron) due to a
>>>>> mysterious tool exec-format error. I'll mail about that separately.
>>>>>
>>>>> Sumit reports that the r9-bifrost userspace driver does not run on the
>>>>> r16-midgard/r4-bifrost kernel driver: it needs a newer one. That makes sense.
>>>>>
>>>>> Because the midagard and bifrost kernel drivers are the same, and the
>>>>> release team tell me they expect that to remain true, it would make
>>>>> sense to use this for both midagard and bifrost. However, we can only
>>>>> do that by moving all the packages forward to much newer versions, and
>>>>> if we do that we lose X support. And all our actual/likely users use X
>>>>> so that's a massive pain.
>>>>>
>>>>> Thus I propose that we upload a separate mali-bifrost (dkms) package
>>>>> (which conflicts with the midgard one) with a current version of the
>>>>> kernel driver. That should work with the mali-bifrost-driver userspace
>>>>>
>>>>> This way we can support current X midgard users for a while (next
>>>>> debian stable release?) but also support newer userspace drivers.
>>>>>
>>>>> I guess if we are doing this the package-names are actually rather
>>>>> unhelpful, and the new one should be called something to indicate that
>>>>> it is newer, rather than specifically for bifrost. mali-current?
>>>>>
>>>>> This is all quite crap, but I don't have any better ideas for having
>>>>> something vaguely useful in the distro.
>>>>>
>>>>> What do you think? Is this a sensible plan? Any better ideas?
>>>>>
>>>>> Sumit - can you update us on the current state of upstream DTB info for hikey960.
>>>>
>>>> Currently we don't have GPU node added in upstream DTB for hikey960. I
>>>> am trying to work out with internal team to get patch [1] related to
>>>> GPU node in upstream.
>>>>
>>>> [1] https://github.com/96boards-hikey/linux/commit/65f19abf8b64cd4a9ad7b3da723b5c84cc07163b
>>>>
>>>
>>> We have added support for GPU node in DTB present in EDK2 [1]. With
>>> this updated EDK2 firmware, I am able to run r12-bitfrost kernel
>>> driver (out-of-tree) with out-of-box Debian on hikey960. So I think we
>>> can move forward with mali-bitfrost-driver packaging in Debian.
>>
>> This device tree node is not in the upstream kernel.  It needs to
>> be there in order to make a Debian package, as the Debian kernel
>> is based on upstream stable kernels.  Otherwise, the .dtb file
>> will not be part of the Debian packages.
>>
> 
> In case of hikey960, .dtb is part of edk2 (UEFI) firmware. I don't
> think we need to have it in Debian packages.
> 
>> The first thing that needs to be done in order to upstream this
>> node is to add a new binding for mali-bifrost, which at the
>> moment essentially is the same as mali-midgard but being a
>> different architecture it needs a different binding upstream (to
>> be confirmed by Rob Herring & Co, but at least that's my
>> understanding).  Then upstreaming this device node as a first one
>> to use it should be quite simple, with just a few tweaks to make
>> it match the upstream bindings (see the mali-midgard nodes
>> upstream for the reference).
>>
> 
> After having conversation with people from ARM, it seems there are
> quite a bit feature-wise differences among upstream bindings and
> Mali-ddk bindings. Also there are platform specific bindings too in
> Mali-ddk which I am not sure will be acceptable upstream. So I think
> it won't be much value-add to upstream bindings until we have upstream
> Mali driver as we can't control these differences in bindings.

Please take a look at the upstream mali-midgard bindings, they
are a subset of what's in the out-of-tree driver and it's not
hard to patch the out-of-tree kernel driver to make it work with
them.  I think what was done for Midgard can be done for Bifrost
too.  And it's always possible to upstream more bindings if
needed, to describe extra hardware properties.

>> Even if this board can have the .dtb as part of the
>> firmware (i.e. it's not technically needed to have it in Debian
>> itself), it follows the out-of-tree driver dt bindings and that's
>> not compatible with the package in Debian which follows the
>> upstream ones.
>>
> 
> AFAIK, earlier Mali packages in Debian are based on out-of-tree
> Mali-ddk (eg. r16-midgard). So these packages would be following
> bindings as per Mali-ddk. In similar manner out-of-tree bitfrost (eg.
> r13) could be packaged with platforms aligning to corresponding
> Mali-ddk bindings.

The mali-midgard dkms package follows the upstream dt bindings.
Debian is a distro about free software, so unless you want to
have a dkms package that is not in Debian and completely ignores
anything upstream, the same rules should be followed for a
mali-bifrost dkms package.

It's important from a principle point of view, to enable longer
term upstreaming of Mali support, but also for pure practical
reasons.  Other platforms will have their dtb coming from the
upstream kernel, and as the kernel driver is not tied to any SoC
there should be one package that works for all platforms, with
just the few patches required to align the out-of-tree kernel
driver with upstream bindings.

I don't think there's anything in the node from the commit you
mentioned that is not compatible with the upstream Midgard
bindings, so it should also be quite straightforward to have it
compatible with upstream Bifrost bindings.

Guillaume

>>> Also to build latest EDK2 firmware for hikey960, follow this doc [2].
>>>
>>> [1] https://github.com/96boards-hikey/OpenPlatformPkg/commit/102978d715570827643afb04b2edee5e9f81af22
>>> [2] https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/hikey960.rst
>>>
>>> Regards,
>>> Sumit
>>>
>>>>
>>>>> anyone: can we get some other DTB info upstreamed (juno? anything else useful)
>>>>>
>>>>> Wookey
>>>>> --
>>>>> Principal hats:  Linaro, Debian, Wookware, ARM
>>>>> http://wookware.org/
>>>>> _______________________________________________
>>>>> pkg-mali-devel mailing list
>>>>> pkg-mali-devel at alioth-lists.debian.net
>>>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mali-devel
>>>
>>> _______________________________________________
>>> pkg-mali-devel mailing list
>>> pkg-mali-devel at alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mali-devel
>>>
>>