[Pkg-Mali-devel] Debian mali pckaging status

[Guillaume Tucker]

On 18/07/18 13:31, Wookey wrote:
> On 2018-07-18 16:38 +0530, Sumit Garg wrote:
>> On Wed, 18 Jul 2018 at 12:57, Guillaume Tucker <guillaume.tucker at collabora.com> wrote:
> 
>>>> 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.
> 
> Hmm. Can someone explain to me how DTB info supplied by UEFI and/or
> kernel works?  Does one override the other, do they get 'merged' (so
> some devices supplied by firmward, some more by kernel?). Is
> overriding/merging done on a per-device basis, or per-item? (sorry I
> don't know the right terminology for dsicussing this in detail, but I
> hope you understand what I mean).

If I'm not mistaken, this is just the UEFI firmware loading the
dtb in memory instead of say, U-Boot.  But it's not like on a PC
where the information is read directly from UEFI - the driver
won't know the difference.  So it's only a matter of where the
dtb data is stored and how it's made available to the kernel.

>>> 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.
> 
> A packaged kernel module could get its info from UEFI rather than the
> kernel, however if I understand correctly we do not yet have agreement
> on what info is actually supplied. The kernel module must work for
> _all_ supported devices in debian so there has to be sufficient
> consitency in the info. That means agreeing what mali bindings should
> look like for the general case and using those. We can't sensibly have
> different bodges coming from firmware on different boards.

If I'm correct in what I explained above, then this shouldn't
really be an issue as the same device tree bindings would be used
regardless of where the dtb came from (U-Boot partition, UEFI
firmware, built-in with kernel image...).

>>> The first thing that needs to be done in order to upstream this
>>> node is to add a new binding for mali-bifrost,
>>
>> 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.
> 
> We have to sort this out and agree one set of bindings. We can't have
> the kernel and UEFI differing about it. How would the _generic_ kernel
> module know which to use?
> 
> I clearly need to understand these differences properly, but I agree
> with Guillaume that the debian packaged module should use upstream
> bindings. If I understand correctly these could be supplied by UEFI
> rather than the kernel on some boards, but they must still match up
> sufficiently. Some 'extra' platform-specific info could be provided by
> firmware if need be (assuming that one can 'merge' sub-device info
> from EUFI and kernel?)

I know that UEFI on Juno overrides some device tree things, esp
with memory regions ("mem" entries).  But I don't think anything
like this is being done for the Mali GPU, is it?

>>> 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.
> 
> No. The existing kernel module uses upstream kernel bindings. That's
> obviously correct to me and we need to agree and upstream said
> bindings.
> 
> I am proposing a Connect session about the mali drivers, and it looks
> like this bindings issue is one that needs to be discussed.

I won't be there but will be watching on YouTube hopefully :)

Guillaume