[Pkg-Mali-devel] Debian mali pckaging status

[Wookey]

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).

> > 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.

> > 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?)

> > 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.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-mali-devel/attachments/20180718/8442aff8/attachment.sig>